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.

 

Known / Common issues:

1.  Management Server installation fails when TLS 1.0 is disabled, and prerequisites for TLS 1.2 are missing. 

  • 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 FIRST install the software prerequisites for TLS 1.2 for SCOM.

2.  When using an older version of SSRS 2017 for SCOM reporting, you are unable to browse directly to http://yourreportserver.yourdomain.com/Reports  This returns an HTTP 500 error.  This is an issue in SQL 2017 Reporting Services and is resolved using build 14.0.600.1274 or later at https://www.microsoft.com/en-us/download/details.aspx?id=55252

3.  When using SSRS 2017, you might see errors on a management server for event ID 31567 with description “Failed to deploy reporting component to the SQL Server Reporting Services server” and “extension is not allowed”.  This is apparently because of a new security restriction in later builds of SSRS 2017.  The workaround is to open SQL Management Studio, connect to your Reporting Services instance, open the Properties of the instance, Advanced, and add *.* to the list for “AllowedResourceExtensionsForUpload

    4.  When using a scoped user profile, you might see a “500 – Internal server error” when using a state view in the Web Console.  You also will see the same bug that was in SCOM 2016 UR6 where state views may throw an error: Incorrect syntax near the keyword ‘CREATE’. This bug was fixed in SCOM 2016 UR7 and is scheduled to be resolved for SCOM 2019 in SCOM 2019 UR1.

     

    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.

    65 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

    14. E Z

      Hey Kevin,

      This is a great guide!

      After installing SSRS 2017, you mention “Browse to http://localhost/reports/“. Did you mean “http://localhost/reportserver”?

      I’m asking because “http://localhost/reports/” does not appear to work. It gives me “HTTP 404 Not Found”.

      Navigating to “http://localhost/reportserver” shows “servername/ReportServer – /, Microsoft SQL Server Reporting Services Version 14.0.600.1109”

      I’m staging a POC of SCOM 2019 on Server 2016.

      • E Z

        Ignore this.. I missed a step and am able to navigate to the URL “http://localhost/reports/”.

        Would like to mention that the web console is not being installed as it’s not required.

        After running the SCOM Reporting role on the SQL server, it fails and rolls back.

    15. Matt

      Kevin-
      Thanks so much for this!
      I’m getting the following error in the Application log in Event Viewer on some of my my test SCCM servers (source is Perflib): “Windows cannot open the 64-bit extensible counter DLL MOMConnector in a 32-bit environment.” Any ideas? It’s puzzling as they are 64 bit scom agents and 64 bit OS systems..

    16. Howard Brown

      Is there a current .inf file for requesting certificates for SCOM communications?

      I’m finding older ones, but I’m not sure if these are the best choice for settings, for TLS 1.2, etc… for best security.

    17. Markus Faleij

      Thanks for a great guide Kevin

      I have installed SCOM2019 with a new management group and shall now remove the old one from Active Directory. When but I receive this error executing ” .\MomADAdmin.exe -d SKANDIKON SKANDIKON” with my domain admin user.

      MomADAdmin failed to delete the container for SKANDIKON with the following exception:
      Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

      Can I delete the old management group under OU OperationsManager manually from Active Directory?

    18. Mark Brown

      Hi Kevin,

      I have upgraded 2 Win2016 MS from v1807 to 2019 and everything seems to be reporting the correctly upgraded version except the database and data warehouse (7.3.13142.0). The SQL server is SQL 2016 Std. on Win2016 as well, is this normal and if not what might I have done to not have this update correctly?

      Thanks for your time

    19. FER

      Hi Kevin,
      thank you so much for your blog. It is very useful!!

      We have installed everything and we are suffering the “Known Issues number 2”: We can browse reports ever but not Reports. We have updated the SQL from 17 to 17 with CU14. But the problem persists.

      Do you know which version we need to solve the issue? Or do we need to change the SQL version?

      Thank you again!

    20. keith Jarrell

      HI Kevin,
      We were able to install the 2019 SCOM Management Server using a remote instance of SQL.. When trying to install Reporting Services I am not able to select a remote instance on the “SQL Server instance for Reporting Services”. It’s grayed out and I am not able to type in the box.. We went back to the “Select Features to install” page and noticed at the bottom of the page under Requires: “This Feature requires a local SQL Reporting Services instance to be installed. Refer to the Operations Manager Supported Configuration document for the full list of system requirements”. Is there a way to install 2019 SCOM reporting services with a remote SQL instance or does it truly have to have SQL installed locally for reporting services?

      • Kevin Holman

        SCOM Reporting Role must be installed on a local SQL Reporting Server. It has always been this way. The SCOM Reporting role is very minimal. Most customers just install this role and SSRS on their Data Warehouse server, or in larger environments, they install SSRS and the SCOM Reporting role on a dedicated server.

    21. Keith Jarrell

      Some more back ground… We have a remote SQL server. I have installed a separate instance of SQL and reporting services on the remote instances specifically for reporting services. The ReportServer and ReportServerTempDB exist.. I used the Report Server Configuration manager on the Scom server and have connected to the database and web service url and web portal url by modifying the url’s and pointing to the the sql server and SSRS instance. While I can’t find anywhere that specifically states that says the SSRS instance must be local to the SCOM server it seems this needs to be the case. I’m looking for a confirmation.

      Thanks

    22. keith Jarrell

      You replied as I was typing up my follow up note. This is my first go around with SCOM.. I think I get it now..

      Thanks

    23. Andy P

      Hi Kevin,

      Just wanted to check on the Power Settings. Is High Performance Power only needed for the SQL Server, or does this also apply to all Management Servers?

      In a past company, which was very large…8 management groups… we were advised about this during a PS case, and at that time it was implied that it was all MS’s too, which we did, and we did see improvements. However, whilst implementing this elsewhere it was queried and I see that on this article, it is only mentioned within the SQL section.

      So, I guess I am asking is it really necessary/safe to apply this to the Management Servers, or could there be another issue lurking.

      Thanks

      • Kevin Holman

        My understanding is that this setting has no effect on VM’s at the guest level, so it really doesnt matter, since management servers are always VM’s in my experience. It matters much more when SQL servers are deployed on physical hardware.

    24. John

      Hi Kevin,

      How about upgrading the other SCOM management servers in a distributed environment. The first one did the upgrade with success from 1807, but the other three management servers will not be upgraded. How can I force that process? By the way, that are 2016 Core servers. Setup program is not supported on a Server Core installation.

      • Kevin Holman

        What does “will not be upgraded” mean? Does it fail? If so – look in the log to see where it s failing.

        On server core – you need to use the command line. I have never tested using server core and doing a SCOM version upgrade.

        • John

          Thx Kevin for your quick response.

          I’ve got also OpsMgr Management Configuration events:29112 ‘Service failed to execute bootstrap work item ‘ . So a bootstrap upgrade procedure will start at the other management servers, but fail with
          ‘Microsoft.EnterpriseManagement.ManagementConfiguration.DataAccessLayer.DataAccessException: Service binaries (cscmdbops.dll) version of 7.3.13142.0 is lower than minimum required Cmdb support version of 10.19.10050.0 recorded in Cmdb. Service binaries must be updated to version no lower than version of the Cmdb support objects. Alternatively Cmdb support objects may be rebuilt to match the version of binaries at Microsoft.EnterpriseManagement.ManagementConfiguration.CmdbOperations.StoreInitializationOperataion.StoreVersionObtained(Object sender, DataAccessOperationCompletedEventArgs args)’

          Our Management Configuration Service runs with the same Log On account as the Data Access Service

        • John

          (SOLVED)
          This command will do the job:

          Start-Process -FilePath “C:\Temp\SCOM2019\setup.exe” -ArgumentList ‘/Upgrade /InstallPath:”D:\Program Files\Microsoft System Center\Operations Manager” /components:OMServer /ManagementGroupName:XXXX /SqlServerInstance:XXXX /DatabaseName:OperationsManager /DWSqlServerInstance:XXXX /DWDatabaseName:OperationsManagerDW /ActionAccountUser:Domain\XXXX /ActionAccountPassword:******* /DASAccountUser:Domain\XXXXX /DASAccountPassword:****** /EnableErrorReporting:Never /SendCEIPReports:0 /UseMicrosoftUpdate:0 /AcceptEndUserLicenseAgreement:1 /silent’

    25. Mario

      Hello Kevin.
      Until SCOM 1807 Solaris 11 x86 was supported (https://docs.microsoft.com/en-us/system-center/scom/plan-supported-crossplat-os-1807?view=sc-om-1807)
      On the SCOM 2019 page I only see Solaris 11 SPARC Version, not x86 anymore. Do you know if this is an error or if it is correct (“by Design”)?
      https://docs.microsoft.com/en-us/system-center/scom/plan-supported-crossplat-os?view=sc-om-2019
      Indeed, if I try to add a Solaris 11 x86 System that worked with SCOM 2012R2, in SCOM 2019 I get a Message “not supported”.
      I’m just wondering why?

      • Kevin Holman

        Great question. I don’t know. My guess would be lack of customer adoption of Solaris 11 on x86…. but I’m not sure the criteria used by the product group to choose which UNIX/Linux versions got support moving forward and which didn’t.

    26. Rasmus

      Hi Kevin,

      Thanks for a great article.
      I have deployed many OPS managers from 2007 to 2016, but this is the first 2019, and no matter how many times i have re-installed this installation ( i thing i have installed it 6-7 times now – no matter what installation guide i follow ore have installede like i used to do) and for some reason i keep getting the same error and can’t figure out why.
      Maby you know why our can guide me in the right direction?

      Data Warehouse failed to deploy reports for a management pack to SQL Reporting Services Server

      Data Warehouse failed to deploy reports for a management pack to SQL Reporting Services Server. Failed to deploy reporting component to the SQL Server Reporting Services server. The operation will be retried.
      Exception ‘DeploymentException’: Failed to deploy reports for management pack with version dependent id ’84a5e876-f9eb-a3b1-e566-b7f7c2fe9dcf’. Uploading or saving files with .Settings extension is not allowed. Contact your administrator if you have any questions. —> Microsoft.ReportingServices.Diagnostics.Utilities.ResourceFileFormatNotAllowedException: Uploading or saving files with .Settings extension is not allowed. Contact your administrator if you have any questions.

      One or more workflows were affected by this.

      Workflow name: Microsoft.SystemCenter.DataWarehouse.Deployment.Report

      Instance name: Data Warehouse Synchronization Service

      Instance ID: {2D8188D5-F0F4-6A12-FD7F-0FCDD6E6B445}

      Management group: XXXXXXXXXXXX

    Leave a Reply

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