Menu Close

UR4 for SCOM 2019 – Step by Step

image

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:

  • Support for Windows 11
  • Support for .NET 4.8
  • UI improvements in Operations console
  • Support for sort option by column, in Overrides Summary.
  • Management Pack label text is selectable in the workflow Properties window for Monitors, Rules, Task and Discoveries.
  • Added new fields for Class Technical Name in the State Views. Added the same in the wizard for creating a new Alert, Event, Performance or State View.
  • Added Target Class Display Name to help identify the target of a rule while selecting rules during the creation of a new Performance View.
  • Added 3 new columns Management Pack, Sealed and Members in the Authoring pane > Groups.
  • Added new column for Management Pack Display Name in the Authoring pane > Create Group wizard.

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
    • Audit Collection 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

image

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 multiple management servers  My first two management servers hold 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.

image

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

image

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: KB5013427-AMD64-WebConsole.msp

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

***NOTE:  There is an issue with the console update with the new feature for the groups view.  This is causing the groups view to be very slow and unresponsive.  You can consider not updating the console to UR4 and leaving it at UR3 to avoid this issue.

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:

image

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 they are not needed. 

 

ACS Update: (Audit Collection Services)

image

One of my management servers is also my ACS Audit Collection Server role.  I will apply the update for that:

image

image

 

Updating Gateways:

image

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

The update launches a UI and quickly finishes.

 

Updating Reporting:

image

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

 

Update Agents:

image

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

image

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

image

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

image

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:

https://kevinholman.com/2017/05/09/scom-management-mp-making-a-scom-admins-life-a-little-easier/

image

 

 

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:

image

In my environment – I only monitor RedHat and Universal Linux distributions, so this is my pared down list of MP’s to update.  Yours may vary, depending on what previous versions you are upgrading from:

image

These can 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 or not updated after import, 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:

image

Now you can deploy the Linux agent updates:

image

image

image

image

image

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

https://social.technet.microsoft.com/wiki/contents/articles/7375.scom-configuring-sudo-elevation-for-unix-and-linux-monitoring.aspx

 

Update the remaining deployed consoles

image

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. 

image

image

image

image

image

image

image

image

 

Review:

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:

image

1.  Slow and unresponsive console when viewing Authoring > Groups screen.  Ur4 added new fieds to this view for the management pack, sealed status, and member count, and this is causing the view to be very slow to load, use, and navigate.

  • You can consider not updating the console to UR4 and leaving it at UR3 to avoid this issue.

 

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

image

 

3.  Once you apply an update rollup, you cannot install, or re-install SCOM WEB CONSOLE, or SCOM REPORTING roles.

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

image

  • 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.10505.0
  • SCOM Reporting Setup looks for a very specific value in the SQL database, which has been updated by the Update Rollup and setup is now blocked.
  • Apply the following workaround to install/reinstall SCOM WebConsole or 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 -- 10.19.10569.0 – 2019 UR4 USE OperationsManager SELECT PrincipalName, Version FROM MTV_HealthService WHERE IsManagementServer = 1 AND PrincipalName = 'OMMS1.opsmgr.net'

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 = 'OMMS1.opsmgr.net'

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.10569.0' -- 2019 UR4 WHERE PrincipalName = 'OMMS1.opsmgr.net'

 

4.  When you run the KB5013427-AMD64-Server.exe server update, sometimes the tasks fail to update the SQL databases, or perform the Agent Pending Management task.

This can happen when your permissions are not set correctly for your RunAs accounts.  There are 3 tasks that get deployed from the Management Pack included in the Update Rollup:

MP:  Microsoft.SystemCenter.DBUpdateTask

  • Database update task
  • Datawarehouse update task
  • Agent pending management task

The “Database update task” runs as whatever action account is associated with the RunAs Profile:  “Operational Database Account”.   By default there are no RunAs accounts associated with this profile, so any workflow that attempts to use this RunAs profile while it is unassociated will execute as the Management Server Action Account.  Since the MSAA has a high level of privilege to the OperationsManager database, this will be successful.  It will fail if someone has restricted the rights of this account on the management server or the SQL database/instance.

The “Datawarehouse update task” runs as whatever action account is associated with the RunAs Profile: “Data Warehouse Account”.  By default the RunAs account “Data Warehouse Action Account” is associated with this profile, so the task will execute as the credential configured in the “Data Warehouse Action Account” RunAs account, which should be the Data Warehouse Write Action account you specified when you installed SCOM.  This credential has a very high privilege to the OperationsManagerDW database (db_owner) so it can modify anything necessary.  It will fail if someone has restricted the rights of this account on the management server or the SQL database/instance.

The “Agent pending management task” runs as whatever action account is associated with the RunAs Profile:  “Operational Database Account”.   By default there are no RunAs accounts associated with this profile, so any workflow that attempts to use this RunAs profile while it is unassociated will execute as the Management Server Action Account.  Since the MSAA has a high level of privilege to the OperationsManager database, this will be successful.  It will fail if someone has restricted the rights of this account on the management server or the SQL database/instance.

If any of these fail, it is likely that someone has modified the default permissions for your action accounts to the SQL databases, or someone has incorrectly modified the default RunAs profile associations.  Please review your permissions against:  SCOM 2019 Security Account Matrix – Kevin Holman’s Blog

You can always just run the SQL script update tasks manually, by using the method shown in previous versions of SCOM as seen here:  UR10 for SCOM 2016 – Step by Step – Kevin Holman’s Blog

 

Done!

image

4 Comments

  1. Trond

    Appreciate the awesome work you always do for SCOM the community, thanks Kevin!

    “Added 3 new columns Management Pack, Sealed and Members in the Authoring pane > Groups”

    We are experiencing console freeze/hang in the groups view now after implementing UR4. This probably do to many groups and recalculation of the amount of members in each group. Unfortunately there is no way to not display this and we actually had to reinstalled our consoles back to UR3 to get it working again. Also tried disabled the auto refresh/polling.

    Anyone else have this issue? Thanks again.

  2. Raoul

    Same here, the added group columns are nice. But it’s SO slow. In fact, I decided to rollback to UR3 for my consoles.
    For all the other components UR4 behaves fine.

  3. Michiel

    We do experience the same, unfortunately Even scrolling the list of Groups after is has been populated is way too slow now.

    Will backout the UR4 patch on our Consoles, waiting for a fix in a future 2019 UR and/or version 2022.

Leave a Reply

Your email address will not be published.