Menu Close

SCOM 2019 – QuickStart Deployment Guide

image

There is already a very good deployment guide posted on Microsoft Docs here:  https://docs.microsoft.com/en-us/system-center/scom/deploy-overview

The following article will cover a basic install of System Center Operations Manager 2019.   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 SCOM.  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 2019 will be installed as the base OS for all platforms.  All servers will be a member of the AD domain.

SQL 2017 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 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 2019 to all server role servers.

5.  Install Prerequisites and SQL 2017.

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)

 

Prerequisites:

1.  Install Windows Server 2019 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 Viewer 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.  OPTIONAL:  If you enforce TLS 1.2, you must ensure the prerequisites for TLS 1.2 have been met on all Management Servers.  https://kevinholman.com/2018/05/06/implementing-tls-1-2-enforcement-with-scom/ 

5.  Install all available Windows Updates to ensure the servers are patched and secure.

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

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

8. Install SQL 2017 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…

image

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

image

  • Note:  Reporting Services is not part of SQL 2017 base SQL install.  This is a separate download, we will cover that later.
  • 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 generally recommend using a Domain account for the service account.  You should do whatever your DBA standards are here.  Input the DOMAIN\sqlsvc account and password for SQL Server Agent, and SQL Server Database Engine. 
  • Check the box to grant Volume Maintenance Task to the service account for the DB engine.  This will help performance when auto-grow is needed.

image

  • On the Collation Tab – you can use the default which is SQL_Latin1_General_CP1_CI_AS
  • On the Server Configuration tab – add your personal domain user account and/or a group you already have set up for SQL admins.
  • On the Data Directories tab – set your drive letters correctly for your SQL databases, logs, TempDB, and backup.
  • On the TempDB tab, notice that a high performance TempDB is being created, with a DB file for each CPU detected.  Adjust sizes and autogrowth per your standards.
  • 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 “sysadmin” role level rights over the SQL instance.
  • 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 “SQL1.domain.com”. 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 “SQL1.domain.com”. 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, or configure this later.  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 OFFNext.
  • 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.
  • On the Microsoft Update screen – choose OFFNext.
  • 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 ”sysadmin” role level rights over the SQL instance.
  • Install SQL 2017 Reporting Services
    • Download SQL Reporting Services 2017 from https://www.microsoft.com/en-us/download/details.aspx?id=55252
    • Run SQLServerReportingServices.exe
    • Select “Install Reporting Services
    • Input a product key for your license.  (You can get your key by running setup from your SQL database media)
    • Accept the License agreement
    • Install Reporting Services Only
    • Choose a Path, and select Install
    • When completed, select “Restart” to reboot the computer.  If required, manually reboot.
  • Configure SQL 2017 Reporting Services
    • Open Report Server Configuration Manager
    • Connect to the local server
    • Select “Web Service URL” and click Apply
    • Select “Database” and click “Change Database
    • Action:  Create a new report server database and click Next
    • Database Server:  Click Test Connection then click Next
    • Database: Accept “ReportServer” for default name and click Next
    • Credentials: Accept default Service Credentials and click Next
    • Summary:  Click Next, then Finish when completed.
    • Select “Web Portal URL” and click Apply
    • Select “Email Settings” and configure your SMTP server in order to be able to use emailed reports in SCOM, and click Apply.
    • Now that configuration is done, click Exit
  • Validate SSRS is working:
    • Open a Web Browser on the server.
    • Browse to http://localhost/reports/
    • You MUST see a “Home” screen before continuing to install SCOM reporting role.
  • Install SCOM Reporting Role on the SSRS SQL server 
    • Locate the SCOM media. Run Setup.exe. Click Install.
    • Select 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.  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. 

Open/Reopen the SCOM consoles, ensure you have a Reporting tab now, and within an hour you should see reports populated in the console. 

Look for any health issues or alerts, and review the OpsMgr event logs on both management servers for errors or warnings.

 

Common issues:

1.  Management Server installation fails. 

  • On the first management server being installed, the UI will return a failure, and in the OpsMgrSetupWizard.log (found at C:\Users\<username>\AppData\Local\SCOM\LOGS), you see the following:

[09:41:56]:    Info:    :Info:GetLocalizedAdminGroupName: Administrators Group Name is: BUILTIN\Administrators
[09:42:12]:    Error:    :PopulateUserRoles: failed : Threw Exception.Type: System.ArgumentException, Exception Error Code: 0x80070057

  • On the any additional management servers being installed, this will show up by hanging on “Registering Management Server” and never completing.
  • This is caused by having TLS 1.0 disabled on the SCOM management server or SQL server. If TLS 1.2 is enforced or TLS 1.0 disabled, you must install the software prerequisites for TLS 1.2 for SCOM.

 

image

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.  Configure SCOM Security

  • You must add your OMAdmins Global group to allow “Log on as a service” right on Management Servers, in order to push agents.  https://kevinholman.com/2019/03/14/security-changes-in-scom-2019-log-on-as-a-service/
  • Add your OMAdmins Global Group to the SCOM Administrators User Role.  Ensure you, your team, and the SCOM DAS and Action accounts are members of this group FIRST.  Then, remove BUILTIN\Administrators from the Operations Manager Administrators – User Role, to secure your SCOM installation.

2.  Apply the latest Update Rollup.

  • At the time of this blog posting there is no update rollup for SCOM 2019.  But you should always find and apply the most current CUMULATIVE update rollup.

3.  Set SCOM License.

4.  Optimize SQL Server for growth and performance

5.  Set up SQL maintenance jobs.

6.  Configure Data Warehouse Retention.

7.  Optimize your management servers registry

8.  Enable Agent Proxy as a default setting

9.  Configure Administration Settings per your requirements:

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

10.  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.
  • https://kevinholman.com/2017/07/07/scom-2012-and-2016-unsealed-mp-backup/

11.  Deploy an agent to the SQL DB server.

12.  Import management packs.

  • https://docs.microsoft.com/en-us/system-center/scom/manage-mp-import-remove-delete
  • 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.

13.  Configure Notifications:

14.  Deploy Unix and Linux Agents

15.  Configure Network Monitoring

16.  Configure SQL MP RunAs Security:

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

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

19.  (Optional) Deploy Audit Collection Services

20.  Learn MP authoring.

36 Comments

  1. Patrick

    Will other System Center products need to be updated before I can move to SCOM 2019, or could I potentially update right away?

  2. Edwio

    But could it be, that SCOM 2019 supported agent platform is only Windows Server 2016 and above?
    What about Windows Server 2008 – 2012 R2, are they going to be left out for SCOM 2019?

    • Kevin Holman

      Windows 2012R2 is supported as an agent. We are updating documentation. I am trying to get clear confirmation if Windows Server 2012 (non-R2) is truly unsupported or a documentation oversight. As to Windows Server 2008 and 2008R2, those are not supported with a SCOM 2019 agent. Those OS versions will fall out of Extended Support by Microsoft in Jan 2020, so they were not included in this release.

      • Doug

        Hey Kevin,

        Server 2008R2 is not supported with a SCOM 2019 agent, but is it supported with the current 2012 MMA connected to a SCOM 2019 management group? If I recall Server 2003 was supported in a SCOM 2012R2 management group with the old agent version, but not on the new (at the time) MMA.

        • Kevin Holman

          We don’t have any support statements for connecting 2008R2 to a SCOM 2019 management group, with any MMA. So the assumption is, that is something is not clearly defined as supported, then it isnt. This is similar to SCOM 2016 dropping support for 2003. You could still connect 2003 servers to SCOM 2016 using a SCOM 2012R2 agent, but it wasn’t a “supported configuration” according to our documentation. It worked fine. We just didn’t test/support it, because WS 2003 extended support expired, and we generally do not test or develop new products to work with unsupported products. I think the heartache is that WS2008/2008R2 is not expired yet, although it will expire soon, in Jan 2020. Why they dropped WS2012 OS, I don’t have a good answer, and we are pushing them to change on that one. The challenge with all of this, is that the Log Analytics MMA supports WS2008R2 and later, AND supports connecting to SCOM 2012 SP1 UR6 and later.

  3. Grega Perko

    Hello, I want to update Audit Collection Services for UNIX/Linux, but after removing old version (1807) I can’t install new. Setup is stuck at Prerequisite Check Did Not Pass: Operations Manager is required to be installed prior to the installation of this product. SCOM 2019 is installed and running on this machine, and also Audit collection services for Windows.

    Any idea?

    • Kevin Holman

      Ugh. This is a bug. To work around this – change the reg key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\CurrentVersion TEMPORARILY from “10.19.10050.0” to “7.2.11719.0” Then run setup. This should work around the installer prereq check. Make sure you change this value back after you install this.

      • Grega Perko

        Setup went OK. But I still get alert:
        Event Description: Loading managed module type in assembly “Microsoft.SystemCenter.CrossPlatform.ACS” with type name “Microsoft.SystemCenter.CrossPlatform.ACS.ACSWriteAction” failed with error “The module assembly “Microsoft.SystemCenter.CrossPlatform.ACS” could not be loaded. The exception was: \nCould not load file or assembly ‘Microsoft.SystemCenter.CrossPlatform.ACS’ or one of its dependencies. The system cannot find the file specified..”.
        This may be because the type or assembly could not be found or the type does not have the MonitoringModuleAttribute.
        Workflow: Microsoft.ACS.Linux.RHEL.6.Su.Failed

        Is this because support for RHEL 6 was removed? This alert has 50 repeats.

        Grega

    • Thorsten

      My bad… I should have thought twice before posting 🙂 Of course they are in the installation folder of SCOM 2019
      All good now 🙂

  4. Michiel

    Kevin, again an excellent piece of work! Run into an issue with SQL 2017 reporting services. Everything is working fine except http://localhost/reports/ gives a HTTP 500 Internal Server Error after installing. Seems more people run into this issue.

    • Kevin Holman

      Yes – this is a known issue. It did not repro with the early builds of SSRS 2017, but it evolved in newer versions. The PG is looking into resolving this.

    • Michiel

      I also ran into the HTTP 500 error problem on installing the SSRS 2017 and SCOM Reporting on a Windows Server 2019. The quick fix was removing SSRS 2017 and install SSRS 2016, which worked fine.
      Later, trying to reproduce this problem I saw that SSRS 2017 is working fine on Windows Server 2016. So it seems to me that the combination SSRS 2017 and Server 2019 is causing the HTTP 500 error.

  5. Jim

    We face an issue that once install SCOM(2019) web service in the same server with the SQL(2016) service, the web service can’t access properly. Not sure is SCOM, SQL or IIS issue, any idea to fix ? Thanks.

  6. TOM

    Hi Kevin,

    If I am upgrading the SCOM management servers from 1807 to 2019 in a distributed environment, do I have to repeat this pre-upgrade task on each management server or just on the first MS? “7.Stop the Microsoft Monitoring Agent, System Center Data Access Service, System Center Configuration Management, and Microsoft Monitoring Agent services on all management servers except the one being upgraded.” Any plans on posting a guide for the upgrade process? Thanks!

  7. Adam Mizicko

    So, to prepare for upgrading our 1807 deployment to SCOM 2019, I had our DBAs restore the OpMgr and DW DBs from our LAB MG to a new SQL 2017 server (from current SQL 2014). The DBA migrated all permissions as well, and afaik, they are identical and meet all documented requirements. After following all the MS steps to edit the registry keys and configservice.config file on each MS, and editing the listed tables on the DB server for both the OpsMgr and DW DBs, SCOM appears to be running, all MS are talking to SQL, with a fairly robust amount of data being exchanged for our LAB MG, but I can’t launch a console on any MS. Data Access Service fails, with Application Log Errors 1000 and 1026, System Log Error 7034 (OMSDK keeps restarting and failing) , and OpsManager Errors 26340 and 26380. If I restore the previous registry keys values and old configservice.config values, Management servers have no problem talking to the old DB. Any ideas? I’ve Googled for two days and found nothing, even looking at SCSM stuff.

  8. Adam Mizicko

    Two of my DBAs swear up and down that logins, perms, ports (default on both old and new servers), firewall, etc. are all configured the same. And the management servers and SQL are talking. Traffic on all of them, and OpsMgr log files show that agents are available. Just no console and the DAS keeps failing, restarting, failing, etc. I notice that in Microsoft’s “How to configure Operations Manager to communicate with SQL Server” page, the database edits specify using (computer\instance,portNumber). On the old server, only SQL server name is used. Since we’re using default ports, my DBAs don’t think this should be an issue, but did this maybe change in SQL 2017? Grasping at straws here (at least it’s in the lab MG). Thanks.

  9. Casimir

    Hi, Kevin if I try to discover a Windows computer (Advanced discovery, Browse for) it doesn’t function. SCOM tries to discover it but it never ends. And it doesn’t matter if I use the Action Account or the other account with the admin rights. Any idea?

    Thanks,
    Casimir

  10. casimir

    Hi Kevin, one thing more: the discover never ends and I see the info that the Discovery is the SQL Broker necessary.

  11. Sylvain

    I was wondering how much SCOM will complain if I do not install the reporting role ? We never really used the reporting in the past and I’m ok if we do not have this piece. However, I suspect I will have tons of msg in the logs about it.

    • Kevin Holman

      None at all. It is completely optional. The DW is mandatory, and created during setup. However, there is zero requirement for a reporting role if you dont want it.

  12. Steve

    Hi Kevin,

    I’ve run the 2019 upgrade on two 1807 management servers so far and in both cases the old and new versions of SCOM are shown in appwiz.cpl . In “operations manager products” the consoles on the management servers are detected as 10.19.10050.0 and the management servers are still detected as 7.3.13142.0 – is this expected/a known issue or is it something specific to my environment do you think?

    Cheers

    Steve

    • Kevin Holman

      I cannot. The reason is – I do not recommend every using that for downloading MP’s. I consider that a worst practice, as I recommend downloading each MP, extracting it – saving it into a repository, testing it in your lab/test environments, then migrating it to production. Sucking in MP’s from the web breaks that change control process, and removes your ability for a proper disaster recovery and rollback capability, in my opinion. I’m sure someone knows the answer to your question, however, but it isnt something I use with my customers.

  13. tony strother

    Afternoon, I understand your position and generally agree. I want to enable it for the feature “show updates for currently installed management packs” since it also provides version info. I do follow the process you recommend, I think it is the safest route to go. We have a good change management process that requires us to document that updates have been tested and properly configured in “lower tiers” prior to migrating/moving on.
    Thanks as always, for your time and assistance.
    Regards,
    Tony

Leave a Reply

Your email address will not be published. Required fields are marked *