OpsMgr 2016 – QuickStart Deployment Guide




There is already a very good deployment guide posted on TechNet here:   https://technet.microsoft.com/en-us/system-center-docs/om/deploy/deploying-system-center-2016-operations-manager

The TechNet deployment guide provides an excellent walkthrough of installing OpsMgr 2016 for the “all in one” scenario, where all roles are installed on a single server.  That is a very good method for doing simple functionality testing and lab exercises.

The following article will cover a basic install of System Center Operations Manager 2016.   The concept is to perform a limited deployment of OpsMgr, only utilizing as few servers as possible, but enough to demonstrate the roles and capabilities in OM2016.  For this reason, this document will cover a deployment on 3 servers. A dedicated SQL server, and two management servers will be deployed.  This will allow us to show the benefits of high availability for agent failover, and the highly available resource pool concepts.  This is to be used as a template only, for a customer to implement as their own pilot or POC, or customized deployment guide. It is intended to be general in nature and will require the customer to modify it to suit their specific data and processes.

This also happens to be a very typical scenario for small environments for a production deployment.  This is not an architecture guide or intended to be a design guide in any way. This is provided “AS IS” with no warranties, and confers no rights. Use is subject to the terms specified in the Terms of Use.


Server Names\Roles:

  • SQL1             SQL Database Services, Reporting Services
  • SCOM1         Management Server Role, Web Console Role, Console
  • SCOM2         Management Server Role, Web Console Role, Console


Windows Server 2016 will be installed as the base OS for all platforms.  All servers will be a member of the AD domain.

SQL 2016  will be the base standard for all database and SQL reporting services.


High Level Deployment Process:

1.  In AD, create the following accounts and groups, according to your naming convention:

  • DOMAIN\OMAA                 OM Server Action Account
  • DOMAIN\OMDAS               OM Config and Data Access Account
  • DOMAIN\OMREAD             OM Datawarehouse Reader Account
  • DOMAIN\OMWRITE            OM Datawarehouse Write Account
  • DOMAIN\SQLSVC               SQL Service Account
  • DOMAIN\OMAdmins          OM Administrators security group

2.  Add the OMAA, OMDAS, OMREAD, and OMWRITE accounts to the “OMAdmins” global group.

3.  Add the domain user accounts for yourself and your team to the “OMAdmins” group.

4.  Install Windows Server 2016 to all server role servers.

5.  Install Prerequisites and SQL 2016.

6.  Install the Management Server and Database Components

7.  Install the Reporting components.

8.  Deploy Agents

9.  Import Management packs

10.  Set up security (roles and run-as accounts)




1.  Install Windows Server 2016 to all Servers

2.  Join all servers to domain.

3.  Install the Report Viewer controls to any server that will receive a SCOM console.  Install them from https://www.microsoft.com/en-us/download/details.aspx?id=45496  There is a prereq for the Report View controls which is the “Microsoft System CLR Types for SQL Server 2014” (ENU\x64\SQLSysClrTypes.msi) available here:   https://www.microsoft.com/en-us/download/details.aspx?id=42295

4.  Install all available Windows Updates.

5.  Add the “OMAdmins” domain global group to the Local Administrators group on each server.

6. Install IIS on any management server that will also host a web console:

Open PowerShell (as an administrator) and run the following:

Add-WindowsFeature NET-WCF-HTTP-Activation45,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Request-Monitor,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,Web-Metabase,Web-Asp-Net,Web-Windows-Auth –Restart


Note:  The server needs to be restarted at this point, even if you are not prompted to do so.  If you do not reboot, you will get false failures about prerequisites missing for ISAPI/CGI/ASP.net registration.



7. Install SQL 2016 to the DB server role

  • Setup is fairly straightforward. This document will not go into details and best practices for SQL configuration. Consult your DBA team to ensure your SQL deployment is configured for best practices according to your corporate standards.
  • Run setup, choose Installation > New SQL Server stand-alone installation…



  • When prompted for feature selection, install ALL of the following:
    • Database Engine Services
    • Full-Text and Semantic Extractions for Search
    • Reporting Services – Native



  • On the Instance configuration, choose a default instance, or a named instance. Default instances are fine for testing, labs, and production deployments. Production clustered instances of SQL will generally be a named instance. For the purposes of the POC, choose default instance to keep things simple.
  • On the Server configuration screen, set SQL Server Agent to Automatic.  You can accept the defaults for the service accounts, but I recommend using a Domain account for the service account.  Input the DOMAIN\sqlsvc account and password for Agent, Engine, and Reporting.  Set the SQL Agent to AUTOMATIC.
  • Check the box to grant Volume Maintenance Task to the service account for the DB engine.  This will help performance when autogrow is needed.




  • On the Collation Tab – you can use the default which is SQL_Latin1_General_CP1_CI_AS
  • On the Account provisioning tab – add your personal domain user account and/or a group you already have set up for SQL admins. Alternatively, you can use the OMAdmins global group here. This will grant more rights than is required to all OMAdmin accounts, but is fine for testing purposes of the POC.
  • On the Data Directories tab – set your drive letters correctly for your SQL databases, logs, TempDB, and backup.
  • On the Reporting Services Configuration – choose to Install and Configure. This will install and configure SRS to be active on this server, and use the default DBengine present to house the reporting server databases. This is the simplest configuration. If you install Reporting Services on a stand-alone (no DBEngine) server, you will need to configure this manually.
  • Choose Install, and setup will complete.
  • You will need to disable Windows Firewall on the SQL server, or make the necessary modifications to the firewall to allow all SQL traffic.  See http://msdn.microsoft.com/en-us/library/ms175043.aspx
  • When you complete the installation – you might consider also downloading and installing SQL Server Management Studio Tools from the installation setup page, or https://msdn.microsoft.com/en-us/library/mt238290.aspx           


    SCOM Step by step deployment guide:


    1.  Install the Management Server role on SCOM1.

    • Log on using your personal domain user account that is a member of the OMAdmins group, and has System Administrator (SA) rights over the SQL instances.
    • Run Setup.exe
    • Click Install
    • Select the following, and then click Next:
      • Management Server
      • Operations Console
      • Web Console
    • Accept or change the default install path and click Next.
    • You might see an error from the Prerequisites here. If so – read each error and try to resolve it.
    • On the Proceed with Setup screen – click Next.
    • On the specify an installation screen – choose to create the first management server in a new management group.  Give your management group a name. Don’t use any special or Unicode characters, just simple text.  KEEP YOUR MANAGEMENT GROUP NAME SIMPLE, and don’t put version info in there.  Click Next.
    • Accept the license.  Next.
    • On the Configure the Operational Database screen, enter in the name of your SQL database server name and instance. In my case this is “DB01”. Leave the port at default unless you are using a special custom fixed port.  If necessary, change the database locations for the DB and log files. Leave the default size of 1000 MB for now. Click Next.
    • On the Configure the Data Warehouse Database screen, enter in the name of your SQL database server name and instance. In my case this is “DB01”. Leave the port at default unless you are using a special custom fixed port.  If necessary, change the database locations for the DB and log files. Leave the default size of 1000 MB for now. Click Next.  
    • On the Web Console screen, choose the Default Web Site, and leave SSL unchecked. If you have already set up SSL for your default website with a certificate, you can choose SSL.  Click Next.
    • On the Web Console authentication screen, choose Mixed authentication and click Next.
    • On the accounts screen, change the accounts to Domain Account for ALL services, and enter in the unique DOMAIN\OMAA, DOMAIN\OMDAS, DOMAIN\OMREAD, DOMAIN\OMWRITE accounts we created previously. It is a best practice to use separate accounts for distinct roles in OpsMgr, although you can also just use the DOMAIN\OMDAS account for all SQL Database access roles to simplify your installation (Data Access, Reader, and Writer accounts). Click Next.
    • On the Microsoft Update screen – choose to use updates or not.  Next.
    • Click Install.
    • Close when complete.
    • The Management Server will be very busy (CPU) for several minutes after the installation completes. Before continuing it is best to give the Management Server time to complete all post install processes, complete discoveries, database sync and configuration, etc. 10 minutes is typically sufficient.


    2.  (Optional)  Install the second Management Server on SCOM2.

    • Log on using your domain user account that is a member of the OMAdmins group, and has System Administrator (SA) rights over the SQL instances.  
    • Run Setup.exe
    • Click Install
    • Select the following, and then click Next:
      • Management Server
      • Operations Console
      • Web Console
    • Accept or change the default install path and click Next.
    • Resolve any issues with prerequisites, and click Next.
    • Choose “Add a management server to an existing management group” and click Next.
    • Accept the license terms and click Next.
    • Input the servername\instance hosting the Ops DB. Select the correct database from the drop down and click Next.
    • Accept the Default Web Site on the Web Console page and click Next.
    • Use Mixed Authentication and click Next.
    • On the accounts screen, choose Domain Account for ALL services, and enter in the unique DOMAIN\OMAA, DOMAIN\OMDAS accounts we created previously.  Click Next.
    • On the Diagnostic Data screen – click Next.
    • Turn Microsoft Updates on or off for SCOM, Next.
    • Click Install.
    • Close when complete.


    3.  Install SCOM Reporting Role on the SQL server.

    • Log on using your domain user account that is a member of the OMAdmins group, and has System Administrator (SA) rights over the SQL instances.
    • Locate the SCOM media. Run Setup.exe. Click Install.
    • Select the following, and then click Next:
      • Reporting Server
    • Accept or change the default install path and click Next.
    • Resolve any issues with prerequisites, and click Next.
    • Accept the license and click Next.
    • Type in the name of a management server, and click Next.
    • Choose the correct local SQL reporting instance and click Next.
    • Enter in the DOMAIN\OMREAD account when prompted. It is a best practice to use separate accounts for distinct roles in OpsMgr, although you can also just use the DOMAIN\OMDAS account for all SQL Database access roles to simplify your installation. You MUST input the same account here that you used for the OM Reader account when you installed the first management server.  Click Next.
    • On the Diagnostic Data screen – click Next.
    • Turn Microsoft Updates on or off for SCOM, Next.
    • Click Install.
    • Close when complete.


    You have a fully deployed SCOM Management group at this point.


    What’s next?


    Once you have SCOM up and running, these are some good next steps to consider for getting some use out of it and keep it running smoothly:


    1.  Apply the latest Update Rollup.  At the time of this blog posting that is UR2.  But you should always find and apply the most current CUMULATIVE update rollup.  Note: Wait at LEAST one hour after installing SCOM 2016, before you attempt applying an update rollup.  SCOM continues to deploy components after installation, and we want to allow those to fully deploy before updating.


    2.  Optimize SQL Server

    • When we installed each database, we used the default of 1GB (1000MB). This is not a good setting for steady state as our databases will need to grow larger than that very soon.  We need to pre-grow these to allow for enough free space for maintenance operations, and to keep from having lots of auto-growth activities which impact performance during normal operations.
    • A good rule of thumb for most deployments of OpsMgr is to set the OpsDB to 50GB for the data file and 25GB for the transaction log file. This can be smaller for POC’s but generally you never want to have an OpsDB set less than 10GB/5GB.  Setting the transaction log to 50% of the DB size for the OpsDB is a good rule of thumb.
    • For the Warehouse – you will need to plan for the space you expect to need using the sizing tools available and pre-size this from time to time so that lots of autogrowths do not occur.  The sizing helper is available at:   http://www.microsoft.com/en-us/download/details.aspx?id=29270
    • Limit SQL memory reserving some memory for the OS.
    • Set Power Management plan in OS to “High Performance”
    • (Optional) Create a high performance TempDB:  https://technet.microsoft.com/en-us/library/ms175527(v=sql.105).aspx
    • (Optional) Optimize MAXDOP:  https://support.microsoft.com/en-us/help/2806535/recommendations-and-guidelines-for-the-max-degree-of-parallelism-configuration-option-in-sql-server


    3.  Optimize your management servers registry


    4.  Deploy an agent to the SQL DB server.


    5.  Import management packs. Also refer to: https://technet.microsoft.com/en-us/system-center-docs/om/manage/using-management-packs

    • Using the console – you can import MP’s using the catalog, or directly importing from disk.  I recommend always downloading MP’s and importing from disk.  You should keep a MP repository of all MP’s both current and previous, both for disaster recovery and in the case you need to revert to an older MP at any time.
    • Import the Base OS and SQL MP’s at a minimum.


    6.  Enable Agent Proxy


    7.  Configure your OpsMgr environment to accept manually installed agents.

    • The default is to block manually installed agents.  I recommend setting this to “Review new manual agent installations”


    8.  Configure Notifications:


    9.  Deploy Unix and Linux Agents


    10.  Configure Network Monitoring


    11.  Configure SQL MP RunAs Security:


    12.  Create a dashboard view:


    13.  Continue with optional activities from the Quick Start guide on TechNet:


    14.  Configure your management group to support APM monitoring.


    15.  Deploy Audit Collection Services


    16.  Learn MP authoring.

    Comments (23)

    1. Thanks for sharing this !

    2. Gordon says:

      Trying to install second management server I am getting the following error:
      (SQL is on AlwaysOn 2014)

      SCOM\Setup\AMD64\Server\OMServer.msi returned error 1603
      :ProcessInstalls: Install Item Management Server failed to install. We did not launch the post process delegate.

    3. Steve says:

      Does the 2016 operations console support connecting to a 2012 R2 UR11 management group?

    4. Kevin Holman says:

      I don’t know if Microsoft officially “supports” that – but it certainly works.

    5. Leonardo says:

      Hi Kevin,

      What account must have the privileges for to install agents, the Action Account?


      1. Kevin Holman says:

        I do not recommend making the action account have rights on all your agents.

        Generally speaking – you type in YOUR credential that has rights to the agent managed machines that you want to deploy agents to. The only reason to grant this to the management server action account, would be if you DON’T have rights – and you restrict individuals, but grant rights to shared service accounts (which from a security and audit perspective is archaic)

    6. Jay Prakesh says:

      Can we install Ops DB & DWH & Reporting on same SQL 2014 server with Always ON all under same named instance or there are any challenges?

      1. Kevin Holman says:

        @Jay –

        OpsDB and DWDB, and reporting *DB’s* are all fine in the same AlwaysOn availability group (assuming you fit the scale model per the sizer to be 500 agents or less)

        Any more than 500 agents, we recommend dedicated servers and instances for each database (OpsDB and DW).

        As to where to install the SRS instance, I recommend that to be on a dedicated server and not part of the always on SQL DB engine servers, because it is not redundant…. it is a stand alone web instance of SSRS.

        1. Rob B-W says:

          Hi Kevin,

          Do you have any advice you can give as to what SQL Licenses are covered under Microsoft statement that “SQL Server runtime” Licenses are included? I’ve read all available documentation, and the only detailed statement I’ve read is that “SQL Server Standard” runtime is eligible. I’ve not read anything about the number of licenses covered (i.e. are multiple instances on different servers, but all SCOM related, supported?) nor do MS state whether license mobility rights are included if deploying to a host-floating VM? I’ve attempted to get this information indirectly from MS in the past, but information has not been forthcoming.

          Ideally, I’d like to form a 2 host SQL cluster for the DB and DW and a separate host for the Reporting instance as per our existing model. Now that SQL standard edition supports clustering this could save some serious cash if its all included under the SQL runtime entitlement.


          1. Kevin Holman says:

            I am not a licensing expert – so always check with your Microsoft rep/TAM. However, historically speaking – SQL Standard Edition licensing is included in your System Center licensing. This means as long as you ONLY use SQL standard, for System Center deployments, and that SQL instance will ONLY support system center databases (and DB’s that support SC deployments such as the reportserver DB’s, then this is included. This means you could have a two node failover cluster housing a single instance, or two instances of SQL standard edition, and as long as you only use it for System Center product back ends, that would be included in your system center licensing.

            Additionally, there is no limit to the number of SQL database instances or SQL reporting instances to support system center. If you deployed one cluster for SCOM, and one for SCCM, one for SCSM, one for SCDPM, and one for SCORCH, etc…. Again – the limitation is they must be Standard edition of SQL, and ONLY support System Center deployments.

    7. Sergio M says:

      Hi Kevin, thanks for the guide.

      Does SCOM 2016 run any AD scripts during installation? I’m planning for a temporary test environment and I don’t want to make any permanent changes to the AD.

      1. Kevin Holman says:

        SCOM does not make any changes to AD, and the user account installing SCOM should not need any rights to the domain. Only the local administrator and SQL rights as defined by the deployment guide.

    8. Dominique says:

      Hello Kevin,

      Thank you for this excellent post as usual you are terrific!!!

      The installation on new server is working fine but for an upgrade it seems there are hurdles …

      I am trying to upgrade SQL 2012 to SQL 2016 (Both enterprise Edition) and I am getting two errors during the setup:

      SQL Enterprise to SQL Standard Failed
      Rule “No Custonm Security Extensions”
      The Report Server has some custom security extensions configured
      Rule “No Custom Authentication Extensions” failed
      The Report Server has some custom authentication extensions configured

      The only steps I found so far are:


      This seems heavy for an upgrade!!! and also risky…

      Any other idea?



    9. Birdal says:

      Hi Kevin,
      thank you for your very good article!
      I have some questions about planning of SCOM server roles.
      We will deploy SCOM 2016 and have 5 server in the 1.Active Directory domain, and 2 servers in 2.Active Direcrory domain. All server OS (Windows Server 2012 R2) are deployed on the VMWARE virtual machines.

      We planned following server roles and want to know your opinion / feedback about these role distribution:

      In the 1.Active Directory domain


      Server1: Management Server, Operations Console

      Server 2: Management Server, Operations Console, Web Console

      Server3: Management Server, Operations Console, Web Console, SQL Server Reporting Services & DB

      Server4: SQL Server Operations Manager Instance & DB

      Server5: SQL Server Datawarehouse Instance & DB

      In the 2.Active Directory domain (untrusted)


      Server6: Gateway Server, Operations Console, Web Console

      Server7: Gateway Server, Operations Console, Web Console

      We want to deploy two Gateway Servers in the 2.Active Directory domain because of availability. Is it perhaps better, these both server (Server6 and Server7) also deploying as Management Server in this untrusted domain?

      Can I deploy all Web Console in the 1.Active Directory domain with only one FQDN (load balancing? availability?), and in the 2.Active directory domain with another one FQDN? Is there any references/documentation about Web Console deployment?

      I will be very glad to hear from you.
      Best Regards

      1. Kevin Holman says:

        @Birdal –

        I am afraid these conversations are far too complex to be handled over this forum. Please send me an email via the contact page with any questions like this.

        But basic holes I’d point out:

        1. We dont support management servers in untrusted domains. So that’s not an option. Management servers should be in the same domain and in the same datacenter, on the same network preferred.
        2. You should not install the Console or Web Console on your gateway servers.

        1. Birdal says:

          Hi Kevin,
          thank you for your feedback.
          Can you give me please the link for the “contact page”? I could not see this link in this page.
          Best Regards

    10. Amier says:

      Hi Kevin

      I am upgrading from SCOM 2012 Sp1 to SCOM 2016.
      and since there is no upgrade path from 2012 Sp1 to 2016.
      I want to go for Alongside Migration.
      I have new servers for SCOM 2016, I will install a new copy of SCOM 2016 on the new servers.
      but now the trick is how to move the current data from 2012 Sp1 on the old servers to 2016 on the new servers.
      I know I can’t backup the operations manager DB from 2012 Sp1 and restore it in 2016 because the DB structure is different.
      So is there is any Scenario I can use to move the Data From SCOM 2012 Sp1 to SCOM 2016 without a need for going to the upgrade operation ?

    11. philippe augras says:

      Hello Kevin,
      I’m planning a migration from SCOM 2012 SP1 to SCOM 2016 and I thought about side by side migration. Can I deploy SCOM 2016 agent to my SCOM 2012 SP1 monitored servers so that their SCOM 2012 SP1 agent is upgraded to SCOM 2016 and multihomed between the SCOM 2012 SP1 management group and the SCOM 2016 management group ?

      1. Kevin Holman says:

        We did not test nor support a SCOM 2016 agent reporting to a SCOM 2012 SP1 management group, that I am aware of. We did test and support a SCOM 2016 agent reporting to a SCOM 2012R2 management group. It will likely work just fine, however…. but you’d need to verify that.

    12. SCOM-PHL says:

      If I just have a dedicated SQL server and another server for the rest of the SCOM functions does it mean that I have to install the web console on the SQL server too based on the below? I also see an error in SCOM stating that the reporting console is unavailable, but I can browse to the directories. “The Reporting Console is unavailable. This was detected by pinging the reporting URL from the reporting server. By default, this monitor pings the reporting URL every 15 minutes”

      “Although SQL Server Reporting Services is installed on the stand-alone server, Operations Manager reports are not accessed on this server; instead, they are accessed in the Reporting work-space in the Operations console. If you want to access published reports through the web console, you must install the Operations Manager web console on the same computer as Operations Manager Reporting server.”

    13. Alfred Nims says:

      After upgrading from SCOM2012R2 to SCOM2016, how soon must I upgrade the agents? Will SCOM2016 still monitor 2012r2 agents?

      1. Kevin Holman says:

        When doing an *in-place* upgrade from SCOM 2012R2 to SCOM 2016, we support the SCOM 2012R2 agents communicating with a SCOM 2016 infrastructure ONLY for the purposes of upgrade. This was not intended for a long term support. We expect the agents to be updated in this scenario as soon as possible. We also call out some known issues of running SCOM 2012R2 agents with SCOM 2016 infrastructure, during this upgrade process: https://technet.microsoft.com/en-us/system-center-docs/om/deploy/how-to-upgrade-a-management-server-to-system-center-2016-operations-manager-upgrading-a-distributed-management-group

    14. Rob Czymoch says:

      This is a great little guide. However and perhaps I missed this you do not seem to go over the SPN registrations needed for action accounts? I found another article that you posted on your blog

      This article helped clear up some issues I had with my deployment.
      I now have some event ID 7016’s on some of my agents installed on RODC’s in child domains, strangely its not happening on all of them. It has been mentioned that for cross domain boundaries I need to setspn for these runas accounts as well?

    Skip to main content