Menu Close

OpsMgr 2016 – QuickStart Deployment Guide



There is already a very good deployment guide posted on Microsoft Docs here:

The 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  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:

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/ 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
  • When you complete the installation – you might consider also downloading and installing SQL Server Management Studio Tools from the installation setup page, or          


    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.  Fix the Database permissions for Scheduled Maintenance Mode


    2.  Set the Operations Manager Administrators User Role

    • Add your OMAdmins Global Group.  Ensure you, your team, and the SCOM DAS and Action accounts are members of this group FIRST.
    • Remove BUILTIN\Administrators from the Operations Manager Administrators User Role, to secure your SCOM installation.


    3.  Apply the latest Update Rollup. 

    • At the time of this blog posting that is UR6.  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.


    4.  Set SCOM License.


    5.  Optimize SQL Server for growth and performance


    6.  Set up SQL maintenance jobs.


    7.  Configure Data Warehouse Retention.


    8.  Optimize your management servers registry


    9.  Enable Agent Proxy as a default setting


    10.  Configure Administration Settings per your requirements:

    • Database Grooming
    • Automatic Alert Resolution
    • Heartbeat configuration (modify only if required)
    • Manual Agent Installs (Reject, Review, or Accept)


    11.  Backup Unsealed Management packs

    • You need to set this up so that in case of a disaster, or an unplanned change, you will have a simple back-out or recovery plan that wont require a brute force restore of your databases.  I have seen this save many a customer’s bacon when they had this available, and cause them great pain when it wasn’t.


    12.  Deploy an agent to the SQL DB server.


    13.  Import 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.


    14.  Configure Notifications:


    15.  Deploy Unix and Linux Agents


    16.  Configure Network Monitoring


    17.  Configure SQL MP RunAs Security:


    18.  Continue with optional activities from the Quick Reference guide:


    19.  (Optional) Configure your management group to support APM monitoring.


    20.  (Optional) Deploy Audit Collection Services


    21.  Learn MP authoring.


    1. Jose Huerta

      Kevin, I’m just starting to get more familiar with setting up SCOM monitoring for Linux/UNIX servers and don’t see many Fragments to help with some custom configs for monitoring Processes and Filesystems.
      interested in a simple fragment to help identify certain processes by an owner or type (java) and since they are different number of processes on each APP server, I’m not sure how to best setup the logic so that it knows the count on the server and alerts if one process is unavailable. Also for Filesystems we need to identify certain APP related filesystems and alert the APP team when they are reaching predetermined thresholds. any help with these would be greatly appreciated.

    2. James

      I’m a little confused, when installing SCOM with our personal domain account as per the instructions above, all the databases will be owned by this user after the install. What if this user leaves? Should the article be corrected to mention login with an account dedicated for the SCOM install and start the install from there. That way the account will never be tied to a user and the databases will be owned by it? Thanks!

      • Kevin Holman

        Your first part is correct. However, a dedicated install account is not required. I’ll update the instructions to include a step to switch the database owner to the SDK/DAS account…. which is preferred since that will never go away.

        • James

          Sounds good – Thanks.

          p.s. When installing agents, there is no mention of the domain account to use. For security I’m assuming a temporary domain admin account could be used for doing a -mass discovery agent install-? or is there another preferred method?

          Thanks again!

          • Kevin Holman

            I am a fan of least priv. I don’t use Domain Admin for anything, except domain administration. I use an administrative account that has local admin rights on the servers to be monitored. If you don’t have accounts that have rights to servers, then using a domain admin account is ok. Most customers who administer SCOM do not have access to a Domain Admin account because those should be highly restricted and protected.

    3. Andy

      Hello Kevin,

      Thanks for sharing these steps!
      I’d like your advice if possible…

      I am planning to migrate to SCOM 2016 from SCOM 2012R2 in preparation for SCOM 2019.
      In your model, you have 1 SQL server and 2 Management Servers…

      Would you recommend the lightweight version from your example or would it make more sense for me to Build the new 2016 Servers to mimic my current configuration described below?

      I’ve used the Sizing Tool and if I select the 1000/100 version, Its Minimum Hardware recommendation:
      > 2 Management servers (1 for HA).
      > 3 SQL Servers. (Operations Database, Operations Data Warehouse, Web Console/SQL Reporting Services)

      Any advice you can share is very much appreciated, Thanks!

      My current environment goes as follows:

      > 1 Virtual SCOM Reporting Server
      > 3 Virtual SCOM Management Servers
      > 3 Physical SCOM SQL Servers (OperationalDB; DataWarehouse; ACS)

      We have approximately,
      1000 Agent Monitored Windows devices.
      60 Agentless Monitored devices.
      25 Unix/Linux devices.
      15 Network Devices
      100 Active Subscriptions

      • Andy

        A follow up to this question… The end goal is to be on SCOM 2019.
        From my understanding, I would need to migrate to SCOM 2016 before upgrading to SCOM 2019.
        With that said, ‘could I’ or ‘would it make more sense’ to install SCOM 2016 on Windows Server 2019 then Upgrade to SCOM 2019.
        Thanks again!

        • Kevin Holman

          Andy, these questions are far too complex for a blog chat. Feel free to use the contact form which will start an email thread with me – and ask specific direct questions.

    4. Kash S

      Hello Kevin,

      Thank you for your blogs, they are very helpful. quick question regarding Windows Servers monitoring in SCOM2016, is there a single management, just like you wrote for SQL, to monitor all windows servers(2008, 2012, 2016, 2019) ?



    5. Martijn

      We are preparing an inplace upgrade to SCOM2019, but for now – the first step is to have all OS versions compatible with the new SCOM. So we are first preparing the OSses, as some of them are now still 2012R2. I would prefer to upgrade these to Server 2019, but is this supported with SCOM2016?

    6. shweta chougule

      Hi Kevin,

      I’m huge fan, learned so much..Thanks a lot.

      We are upgrading our SCOM 2012r2 to 2019. (2012 R2 >2016 > 2019)

      Since we are not allowed to do an in-place upgrade we are introducing new 2016 servers in existing SCOM
      Then we add them as additional MS and once all the agent routing is configured we will decommission the old ones.
      However I have a few challenges.
      All our MS’s and DB servers are hosted in x domain which is going to be decommissioned
      We would like to add new MS’s from Y domain, however we don’t have trust between these 2.
      So when i’m trying to add the MS we are getting access denied error.
      Kindly suggest a workaround for this.
      I guess we will need to use mixed mode authentication to add the servers from y domain.
      However, I’m confused about how to use the SQL account to takeover when we are trying to connect to the SQL DB using the setup. Cause when i’m launching the setup its taking my creds from Y domain, which has no access in X domain.

      • Kevin Holman

        What you were attempting to do is unsupported. We do not support changing the domain of a management group. You need to build a new SCOM 2019 management group with a new management group name in the new domain.

    Leave a Reply

    Your email address will not be published.