Menu Close

UR3 for SCOM 2019 – Step by Step


KB Article for OpsMgr

List of New Features

Download Update Rollup from the Catalog

Download the NEW Simplified Management Server Update EXE

Download Updated UNIX/Linux Management Packs

Recommended hotfix page

New Features:

  • Updates to the new change tracking feature
  • Additional view options in web console widgets
  • Resolved issues with orphaned alerts
  • Performance Improvement in load time for Windows computer view
  • Performance Improvement in load time while changing user role privileges
  • Performance Improvement in SDK service queries
  • Performance Improvement in grooming of maintenance mode staging table
  • UNIX/Linux – Reliability and performance improvement in Xplat agent
  • UNIX/Linux – Support for RHEL 6
  • UNIX/Linux – Disabled SSL renegotiation for Linux agent
  • UNIX/Linux – TLS 1.2 support for Solaris 10 SPARC
  • UNIX/Linux – Dynamic changes in log-level settings without agent restart

Key fixes:

  • See the KB article.  There are too many fixes to list here.


NOTE:  I get this question every time we release an update rollup:  ALL SCOM Update Rollups are CUMULATIVE.  This means you do not need to apply them in order, you can always just apply the latest update.  If you have deployed SCOM 2019 and never applied an update rollup – you can go straight to the latest one available.

Let’s get started

From reading the KB article – the order of operations is:

  1. Install the update rollup package on the following server infrastructure:
    • Management Servers
    • Web Console Servers
    • Gateway Servers
    • Operations Console Servers
    • Reporting Server
  2. Apply Agent Updates
  3. Update Unix/Linux MP’s and Agents


Management Servers


Updates in SCOM 2019 have CHANGED.  There is a new process for updating management servers that differs from previous versions of SCOM.  Download the single file management server update, and this will ensure that your Management Server Role is updated, as well as any SQL updates, and Management Pack updates.

It doesn’t matter which management server I start with.  I simply make sure I only patch one management server at a time to allow for agent failover without overloading any single management server.

I have 2 management servers  My first management server holds 3 roles, and each must be patched:  Management Server, Web Console, and Console.

The first thing I do when I download the updates from the catalog, is copy the cab files for my language to a single location, and then extract the contents. 


Notice the new EXE file, and a MSP file exist for the Server update.  The EXE is the new simplified update file, but we included the older MSP for customers who want to continue to use the old process, or use silent installs for patching.  I will ONLY demonstrate and recommend the EXE file for the Management Server role update.

Once I have the EXE and MSP files, I am ready to start applying the update to each server by role.

  • ***Note:  One of the changes in SCOM 2019 Update Rollups, is that you no longer need to have “Sysadmin” role level rights to SQL.  The SCOM Update Rollup simply updates SCOM, and then uses your existing RunAs accounts to deploy the updated SQL script files to modify the SQL databases.  You simply need to log into your SCOM management servers as a Local Administrator and SCOM Admin.

My first server is a Management Server, Web Console server, and has the SCOM console installed, so I copy those update files locally, and execute them per the KB, from an elevated command prompt.

I will start with KB4594078-AMD64-Server.exe

This is a self-extracting executable, that kicks off a simple update tool.  Accept the license terms, and click “Install

This will update the management server role, update the databases with SQL scripts, and then import any Management Pack updates.


If you have an issue – you can review the setup logs:

  • Setup Log: C:\Users\<UserName>\Appdata\Local\SCOM\Logs
  • SQL Logs: <SCOM install directory>\Server\SQL Script for Update Rollups\SqlExceptions_{version}.log
  • MP Import Logs: <SCOM install directory>\Server\Management Packs for Update Rollups\ManualMPImport_{version}.log

Next up – since this management server also runs a SCOM Web Console, I will run the Web Console update: KB4594078-AMD64-WebConsole.msp

Lastly – install the Console Update (make sure your console is closed):   KB4594078-AMD64-Console.msp

You can reboot the server at this time if you were prompted to in order to complete the update.  If you were not prompted to, you do not need to. 


Additional Management Servers:


Apply the UR updates for Server, Web Console, and Console roles as needed for all additional management servers.  You should only patch one management server at a time to allow for graceful failover of agents and to keep resource pools stable.

You can use the same EXE file and MSP files (where applicable) you used for the first management server.  The setup program will detect if the SQL scripts are already completed, and if the MP’s are already imported, and skip those if needed.  


Updating Gateways:


Open an elevated command prompt, and run the update:   KB4594078-AMD64-Gateway.msp

The update launches a UI and quickly finishes.


Updating Reporting:


On your server that hosts the SCOM Reporting role, run the update:   KB4594078-AMD64-Reporting.msp


Update Agents:


Agents should be placed into pending actions by this update for any agent that was not manually installed (remotely manageable = yes):

***NOTE: For this to work, you MUST run the server update from an elevated command prompt, and the user account running the update must be a Local Admin, and SCOM Admin.  The Agents MUST have “Remotely Manageable” set to “Yes”.


You can approve these – which will result in a success or failure message once complete:


Now we will show the “REAL” agent number in the Administration –> Agent Managed view console:


And my SCOM Management Group Management MP, which will help show you REAL UR levels based on a better discovery.  This has long been a pain point in SCOM:



Update UNIX/Linux MPs and Agents:


You can get the current Unix/Linux MP updates HERE.  

Download, extract, and import ONLY the updated Linux/UNIX MP’s that are relevant to the OS versions that you want to monitor.  Here is the FULL list:


In my environment – I only monitor RedHat and Universal Linux distributions, so this is my pared down list of MP’s to update:


This will take a considerable amount of time to import, and consume a lot of CPU on the management servers and SQL server until complete.

Once it has completed, and before you attempt to update your Linux Agents – verify the updated files are dropped at \Program Files\Microsoft System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits.   If they are not present, sometimes you must restart the Microsoft Monitoring Agent service on the management servers after an MP Import to get them to show up.

After restarting my Microsoft Monitoring Agent service on my management server, I see the new files dropped with new timestamps:


Now you can deploy the Linux agent updates:





If you have any issues, make sure your SUDOERS file has the correct information pertaining to agent upgrade:


Update the remaining deployed consoles


This is an important step.  I have consoles deployed around my infrastructure – on my Orchestrator server, SCVMM server, on my personal workstation, on all the other SCOM admins on my team, on a Terminal Server we use as a tools machine, etc.  These should all get the matching update version.  


Verifying the update

There are new views in the SCOM console to help with this and make this process MUCH easier.  You do need to wait long enough for the discoveries to run in order for these to update the views. 











Now at this point, we would check the OpsMgr event logs on our management servers, review the Management Group Health dashboard, check for any new or strange alerts coming in, and ensure that there are no issues after the update.  


Known Issues:


1.  The Web Console views may not work (500 error) for scoped users who are not SCOM Admins.  These same views work fine for SCOM Admins.

  • This primarily affects Web Console roles installed using Network Authentication.  This does not appear to impact Web Console servers installed using Windows Authentication.
  • On the web console server – find the folder:   \Program Files\Microsoft System Center\Operations Manager\WebConsole\MonitoringView\TempImages
  • Change the security on this folder for Authenticated Users – and add “Write” capability:



2.  Once you apply an update rollup, you cannot install, or re-install SCOM reporting Role.

  • You will see an error in the setup UI (when you supply a management server name) that states “Unable to connect to the Data Access service for this management server. Ensure the Data Access service is running and that the service, the management group, and setup are all the same version.”


  • In the setup log, located at C:\Users\<username>\AppData\Local\SCOM\LOGS\OpsMgrSetupWizard.log – the last line will appear similar to:   Error:The management server is a different version than the current setup build. Please use a different management server or the correct version of setup. Server Version: 10.19.10311.0
  • SCOM Reporting Setup looks for a very specific value in the SQL database, which has been updated by the UR1 and setup now rejects continuing.
  • Apply the following workaround to install/reinstall SCOM Reporting role:
  • QUERY the OPERATIONSMANAGER database, and record the VERSION number that is returned.  You will need this value later.  You need to change the PrincipalName to your SCOM Management server that you point the reporting install to.

-- 10.19.10050.0 - 2019 RTM -- 10.19.10311.0 - 2019 UR1 -- 10.19.10349.0 - 2019 UR1 with post UR1 Hotfix -- 10.19.10407.0 - 2019 UR2

-- 10.19.10505.0 – 2019 UR3 USE OperationsManager SELECT PrincipalName, Version FROM MTV_HealthService WHERE IsManagementServer = 1 AND PrincipalName = ''

UPDATE the VERSION entry in the OpsDB to match the RTM version number which is 10.19.10050.0 just for this management server.

UPDATE MTV_HealthService SET Version = '10.19.10050.0' -- 2019 RTM WHERE PrincipalName = ''

Install SCOM 2019 Reporting, and choose this same Management Server.  Reporting install will work now.

REVERT the VERSION entry in the OpsDB to match the original value you recorded

UPDATE MTV_HealthService SET Version = '10.19.10505.0' -- 2019 UR3 WHERE PrincipalName = ''





    • Kevin Holman

      Not sure why they didnt include that in the KB article. However, I tested it and it was included.

      • Abhishek

        Hi Kevin,

        Many thanks for the confirmation.
        Another important feedback. The UR3 upgrade with exe file went well for the first management server, but my other managment servers were restared without giving any imtimation.
        So if you dont have a reboot approval, you have to be careful.

        Log Name: Application
        Source: MsiInstaller

        Event ID: 1005
        Task Category: None
        Level: Information
        Keywords: Classic

        The Windows Installer initiated a system restart to complete or continue the configuration of ‘System Center Operations Manager Server’.

  1. Stclair

    I previously had the issues with some Management server continuing to try to deploy warehouse components. Still occurs after this update although it says it was addressed in the patch. I tried both the simple installer then manually installing the UR on the affected servers. Weirdly this only occurs on management servers at a remote site but not on the local. Thanks:

    Failed to deploy Data Warehouse component. The operation will be retried.
    Exception ‘DeploymentException’: Failed to perform Data Warehouse component deployment operation: Install; Component: Script, Id: ‘4173391e-ce71-1369-c358-17030bb09b41’, Management Pack Version-dependent Id: ‘73695800-a0e6-5cc8-6a66-9f8bbe722d7f’; Target: Database, Server name: ‘ServerA’, Database name: ‘OperationsManagerDW’. Sql execution failed. Error 777971002, Level 16, State 1, Procedure DeploymentOperationValidate, Line 278, Message: Sql execution failed. Error 777971104, Level 16, State 1, Procedure DeploymentOperationValidate, Line 170, Message: Deployment operation validation failed. Component alrady installed. Operation: ‘Install/Upgrade’; Component type: ‘Script’; Component id: ‘4173391E-CE71-1369-C358-17030BB09B41’; Management pack version: ‘73695800-A0E6-5CC8-6A66-9F8BBE722D7F’; Target: ‘Server name: ServerA; Database name: OperationsManagerDW; Dataset ID: [null]’

    One or more workflows were affected by this.

    Workflow name: Microsoft.SystemCenter.DataWarehouse.Deployment.Component
    Instance name: 8a9be2d2-02de-4f28-85a8-2ebf425c9dbb
    Instance ID: {40D8D96F-675F-D7D0-019D-6E0E8C6CF9E2}

  2. Nodar

    Hi Kevin, first of all many thanks for your solutions and recommendations, usually use them for my SCOM.

    UR3 done successfully except agents, some of them were not updated from console and still have old versions 10.19.10014.0 and 8.0.13053.0

    Do I need to update them manually (one by one) or better to find issue and update them using console?

    Thanks in advance.

    • Kevin Holman

      You can try to do a “repair” using the console. Then go investigate the ones that failed and see what is wrong/failing, then address it. If the number is manageable then yes, I’d expect you would fix those manually.

      A UR update generally will not work on old agents, you need to upgrade them first…. I’d expect those to fail.

  3. Thomas Rummerstorfer

    Hi Kevin,

    do you have any news about the Ubuntu 2004 LTS support?
    It has been a full year since the release, but there it’s still not supported by SCOM.

    • Kevin Holman

      I recommend you open a request at (or a support case) for this. I am not sure why we have not added this support to SCOM 2019.

  4. Martin

    First, many thanks for a great UR3 guide…

    After we upgrading Scom agents to UR3 on our DC:s, they been consuming almost all of the CPU rersources. 99-100%. It is not only one, theres all of the DC:s…
    IT is the “System Center Management Service Process” —> MonitoringHost who takes it all.
    When we rolling back agents to UR1 there back to normal CPU consuming again. No problem at all…

    We scanned the processes on a DC with Ur3 agent installed and there seems to be alot of Cscript activity going on.

    Anyone else who has facing this issues with the UR3 agent?

    • Kevin Holman

      That’s very concerning. Can you open a support case on that?

      What Active Directory management pack are you using – the “new/current” on or the old one?

      • Martin

        Yes thats is very concerning.
        The Active Directory Management Pack we use is version, i guess thats the newest one?

        Is there no changes for the AV exclusions with UR3?, same exclusions as before?
        Well we have something to work with here and we will surely open a case on this, if we not find any solution. If anyone else also have this problem please confirm…

      • Martin

        We found the root issue now. It is the “Security Monitoring MP” in combination with “SCOM UR 3 Agent” who is the problem. Security Monitoring MP created floods in the eventlog on the DC:s and when we uninstalled the Security MP everything went back to normal and the UR3 agent on the DC working just fine. It was Security Monitoring MP had installed… Maybe Nathan Gau can knows or can find out what can be wrong here…

          • Martin

            We made a test to install the Security Monitoring MP 1.0.7.x again. This time completely (vanilla), no overrides. The CPU consuming directly rised again.

            When i looked trough the Eventlog under Operations Manager there is a lot of errors associated to Security Monitoring MP rules. For an example:


            There is also warnings that rules/monitors failed and got unloaded. 1 of them reached the failure limit that prevents automatic reload.

            I dont really know but the feeling i have is that something is stucked in loop because the errors and warnings come intermittently. Considering reload and intermittently errors.

            Hope this can give something…

          • Kevin Holman

            I am seeing a LOT of handle count leaks and high CPU on all agents (especially DC’s) when the Security Monitoring MP is imported. I’d recommend removing this MP until Nathan has time to review what’s going on. It is a VERY intense MP with regard to the security event log, which is very difficult to monitor because of the number of events per second typical on DC’s.

  5. Stoyan Chalakov

    Hi Guys, Hi Kevin,

    I am currently installing the UR3 in two different, independant environments. Unfortunately I am facing in both of them an issue, which should have been resolved with UR2:

    – Setup stalling at the “Removing backup files” stage.

    I am currently running UR2 in both environments and the UR2 setup went nice and smooth, but the UR2 stales at this phase, waiting for 45 Min. now, pretty sure it won’t continue.

    Anyone else experiencing this? Any advices? Thanks in advance!

    • Stoyan Chalakov

      Ok, seems to be false alaram. It was just the update, taking very, very long (about 55 Min.) to get from “Removing Backup Files” to the next stage!

  6. Isak Fernqvist

    Thanks for the post, always a joy to read and follow.
    A comment to STOYAN CHALAKOV above. Removing Backup Files took at least 1h before it continued.
    The next step, updating database, I received error 1603 during DataWarehouseUpdateTask and the process stopped.
    Found an old post stating that that error is nothing to be concerned of, just continue to install the MPs manually, which I did. The databases has the right version number in the consol. Anyone else experience this? Any comment?

  7. Kiwifulla

    Had a fail on the 2nd MS on the “Database Configuration” stage when using the server.exe. Rebooted it and still did the same thing. Tried a 3rd MS and it was good. Went back to the 2nd one and used the old .msp method. Everything looks ok but looks like this issue is still around:

    As the 1st MS completed the Database Configuration and MP sections cleanly, I assume that it doesn’t matter it failed on the 2nd one anyway, but ran the .msp just incase (even though the “Management Server” section completed OK from the initial attempts using the server.exe.

    Has anyone else had this issue and do I need to do anything else?! Thanks

  8. David Y

    After updating to UR3 we noticed that Alert Monitor “Processing Backlogged Events Taking a Long Time” would go in to a warning state for a few servers, and a critical state for our domain controllers. We never had this issue before with blacklogged events. We would see the alert, but it would automatically correct easily. It’s been in a critical state on our DCs for several hours today. We’ve been troubleshooting, looking at the source of the logs, trying to find out why this is suddenly an issue. We even flushed the Health Service State and Cache and rebooted our SCOM servers (we have 2). We don’t monitor workstations, and the total of our monitored clients is roughly 300-400. We believe we have narrowed it down to UR3, as we just updated. Is anyone else having this issue after updating to UR3?

    • Martin

      Hi David!

      In earlier comments in this thread, i have been reporting problems with DC:s and very high CPU Consuming with the UR3 agent. Maybe you already have read it. That issue seems to be a problem with the UR3 agent and the Security Monitoring MP. We have uninstalled the Security Monitoring MP and the CPU Consuming went back to more normal consuming…


      We have also seen the Processing Backlogged Events Taking a Long Time. We get that alert often for one of ur Management Server. Before UR3 we never had this. So my guess is that Security Monitoring is not the only problem with UR3. The feeling that i have is that UR3 consuming more resources, both cpu and memory.
      So i would not be suprised if there soon will be a hotfix for UR3. Hope they working on it….

      • David Y


        Thank you! I must have missed it. We do use the security monitoring MP. It’s one of our most valuable MPs. Our cpu utilization on the DCs has come down after overriding the monitor. We left it on for all of our other servers. I’ll have to turn those overrides off to see the results of the next patch.

      • Rodrigo

        Hi Martin

        How are you doing?
        Did you notice any problems with the agent on servers with SQL Server in your environment? Or only in DC’s?

        • Martin

          Hi Rodrigo!

          Thanks, I’m feeling very well and i wish the same for you.

          No generel SQL Server problems what I’ve seen for so long. But the SQL servers dedicated for SCOM are definitely using more resources than before. This can possibly be a consequence of the other problems, feel insecure about this.

          Except the DC´s, one of our Management Server has problem with “Processing Backlogged Events Taking a Long Time” and are also consuming more resources then before. it feels like it is increasing gradually. Before UR3 we did not have this.

Leave a Reply

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