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.

 

Known Issues in SCOM 2019 UR4:

  • STOP!!!!  Read this and make sure you are prepared to resolve these issues before applying UR4.
  • Normally I just put this section at the end, but I need to call out THREE serious issues, one of which might require action to prepare the SCOM SQL environment before you apply UR4, and another where you MUST check for a bad MP before upgrading.
  • There is an issue with the console, when viewing groups after you apply UR4.  We have released a Post-UR4 Hotfix which you should apply immediately after applying UR4.  Download here
  • There are new indexes in UR4 that can consume a lot of transaction log space and TempDB space.  Customers might run out of transaction log space.  Please see further guidance at the end of this article.
  • There is a new restriction on Management Packs, where we do not allow a MP to have duplicate Aliases starting with SCOM 2019UR4 and SCOM 2022.  If you upgrade without resolving this first, your console will not be able to be used until you resolve this.  Please see further guidance including scripts at the end of this article in the Known Issues section.

 

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

Next – 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.  There is a Post-UR4 Hotfix for this available HERE.  After you apply the Console UR4 update, plase download and apply the Post-UR4 console update.

Next – install the Post-UR4 Console Update:   KB5016576-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:

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

 

2.  Transaction logs fill up on the Data Warehouse database. 

  • There are some new indexes created in UR4 to improve Data Warehouse performance.
  • The creation of these indexes on existing tables can consume a LOT of transaction log and possibly TempDB space, especially when the database is not set for SIMPLE recovery model.
  • This can cause the transaction logs to grow and fill the available space on the log.  You must have a significant amount of space available on the volume that contains the transaction log for this to be able to complete.  This will vary widely per customer, depending on how long you retain data, how large your Data Warehouse has grown, number of Agents, and number of Management Packs, and then your TLOG sizing and disk Volume sizing.  I wish I could give a fixed value to ensure you have free, but I cannot.  I will say I have seen customers with 100GB of TLOG size allocated and they ran out of space.
  • You can also consider significantly reducing the retention for state hourly data in the warehouse, and allowing this to groom before applying UR4, to reduce the space needed to apply the new indexes.

 

3.  You MUST check for duplicate aliases.  If you have any MP’s with duplicate aliases the SDK will throw errors after the upgrade 

  • In previous versions of SCOM, duplicate aliases (with different case) was allowed.  This is no longer allowed.  However, we do not check for this condition as part of UR4.  Please run the PowerShell or SQL scripts below to check for this condition and resolve this.
  • If impacted, your SCOM console might be stuck while “connecting”.
  • SDK powershell commands might return an error with “An object of class ManagementPackClass with ID <GUID> was not found”
  • Event 27000 In the OpsManager event log : “ An Item with the same key has already been added”
  • Failed setup/upgrade installation with messages in the log:” An Item with the same key has already been added”

Example of a bad MP:

image

To detect MPs with this issue, you can use the following PowerShell or SQL query.  After detection, you will need to export these MP’s and re-label one of the duplicate Aliases, and re-label it anywhere it was used in the body of the XML.

############################################
#Identify MPs imported with duplicate Aliases
$mps = Get-SCOMManagementPack
foreach ($mp in $mps)
{
  $hashTable = @{}
  foreach ($ref in $mp.References)
  {
    try {$hashTable.Add($ref.Key, $ref.Value)}
    catch
    {
      $MPName = $mp.Name
      $MPDisplayName = $mp.DisplayName
      $MPVersion = $mp.Version
      "MP contains duplicate aliases: Name=($MPName) DiplayName=($MPDisplayName) Version=($MPVersion)"
    }
  }
}
############################################

SQL query:

-- LIST ALL MPs that have a duplicate Alias reference
declare
       @mpFriendlyName nvarchar(255),
       @mpName nvarchar(255),
       @mpId uniqueidentifier,
       @mpXml as xml

create table #badMPTable (
       mpId uniqueidentifier,
       mpName nvarchar(255),
       mpFriendlyName nvarchar(255)
)

declare mp_cursor cursor local forward_only read_only for
       select 
              MPFriendlyName,
              MPName,
              ManagementPackId,
              convert(xml, MPXML)
       from ManagementPack

open mp_cursor
fetch next from mp_cursor
into @mpFriendlyName, @mpName, @mpId, @mpXml

while @@FETCH_STATUS = 0 begin
       select
       n.value('@Alias','nvarchar(255)') as mpRef
       into #tempRefs
       from @mpXml.nodes('/ManagementPack/Manifest/References/Reference') as a(n)

       if exists(
              select count(*)
              from #tempRefs
              group by mpRef
              having count(*) > 1
       ) begin
              insert into #badMPTable (
                     mpId,
                     mpName,
                     mpFriendlyName
              ) values (
                     @mpId,
                     @mpName,
                     @mpFriendlyName
              )
       end

       drop table #tempRefs

       fetch next from mp_cursor
       into @mpFriendlyName, @mpName, @mpId, @mpXml
end

close mp_cursor  
deallocate mp_cursor

select *
from #badMPTable

drop table #badMPTable
--End

 

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

image

 

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

 

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

59 Comments

  1. Trond
    Reply

    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
    Reply

    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
    Reply

    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.

  4. AUREL
    Reply

    Hi Kevin,
    I just installed the UR4 on my SCOM.
    It works well on all MS, Console, etc.

    But it seems that the creation of indexes in the DW database fills the logs very quickly !
    I have a 600GB AO database with 380GB used.
    The logs were 30GB, usually 95% free. (I have a backup task every hour)
    The transaction log is filled until it is full and blocks the ingestion.
    Then the index query rolls back.
    I was able to increase the size of the logs to 120GB, but soon I will have no more space on the disk to increase it..
    At this time the creation of the indexes is not finished and takes 80Go.
    Did you have this problem ?

    • Aleksei Degotkov
      Reply

      I can confirm the issue with all symptoms on my production DW DB (~600GB). Creating indexes was rolled back. Applicaiton log had multiple events “The transaction log for database ‘OperationsManagerDW’ is full due to ‘ACTIVE_TRANSACTION’.”
      I had no this issue on my test environment (DW DB size is about 157 GB) so I think it is capacity issue and we need to have more space in log files and on drives.

      • Kevin Holman Post author
        Reply

        How much space did you have available on your disk for the TLOG? How big did it grow to before it failed?

        • ALEKSEI DEGOTKOV
          Reply

          The log file was filling about 50GB/hour.
          I had TLOG with fixed size = 102 GB, this size allowed me to have >25% of free space in the log file (the log is backed up every 1 hour). My problem was I couldn’t set another size for the log file or to make it unlimited due it was impossible to open database’s properties while creating index or rolling back a transaction:
          “Property SpaceAvailabable is not available for Database ‘[OperationsManagerDW]’. This property may not exist for this object, or may not be retrievable due to insufficient access rights (Microsoft.SqlServer.Smo)”
          Finally I’ve blocked all SQL conenction by firewall, put the database into Single user mode with rollback of transaction and set log file to grow without limits.
          After I removed the firewall rule SCOM initiated creating index again and in this time it was finished successfully. The log file was expanded up to 146 GB.
          The most expensive queries were related to creating indexes in StateHourly tables:
          “CREATE INDEX [IX_CUSTOM_33BC65C4DC4A421582115211C25E808F] ON [State].[StateHourly_CB3B0C14AB7B4DB98197C95B05F0DB49](DateTime, ManagedEntityMonitorRowId) INCLUDE (InRedStateMilliseconds, InYellowStateMilliseconds, InDisabledStateMilliseconds, InPlannedMaintenanceMilliseconds, InUnplannedMaintenanceMilliseconds, HealthServiceUnavailableMilliseconds) ON [default]”.
          My db has 60 StateHourly tables. I think it can be tuned before the operation if reporting is not important https://kevinholman.com/2010/01/05/understanding-and-modifying-data-warehouse-retention-and-grooming/

          • Kevin Holman Post author

            Thanks – this is great info. Most customers do not heavily use reporting and availability reporting even less than that. I agree – might have to be proactive for customers who are not using simple recovery model, and reduce the state-hourly retention before applying UR4.

  5. Michiel Rens
    Reply

    I’ve experienced the same issue that Aurel describes: it takes a LOT of transaction log to create the new indexes. And if they fill up before the transaction is finished, it obviously takes a long time to rollback. In my environment it took 36 GB of transaction log to be successful.

  6. SoehnelS
    Reply

    Hi at all!
    We stuck at the server update:
    Using the simplified exe: stuck forever at “Removing backup files…”
    Using the server.msp: stuck at “44 seconds…”

    As I read at other places I also tried to set the recovery options to “Do nothing” instead of “Automatic restart”.
    During the setup these settings are reverted to “Automatic restart”

    Did anybody had this issues with UR4 also?

    I will setup another test environment and try again.

  8. Bassma
    Reply

    I tried to install the .msp file and .cab “using DISM” file on Windows server 2012R2 and Windows server 2019 and i got error below,

    File name: KB5013427-AMD64-Agent.msp

    “The upgrade patch cannot be installed the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer and that you have correct upgrade patch”.

    • Kevin M
      Reply

      I’m having this same issue. Does anyone know why someone would get this error when running the agent update on the management server? I’m assuming this update should be run on the management server and it’s this update that will allow you to push the latest agent to servers. I ran this on a server that’s being monitored just to see what happens and it did update the agent on that server. So this update should be run on the management server but can also be run on managed servers to manually update the agent?

  9. George S.
    Reply

    Make sure you tweak the sudoers regex to support the new agent versions 1.6.10-1 since it is the first version to include 2 digit numbers.

    • Bassma
      Reply

      Hi George

      Would you give me more details? what us Sudoers regex ? i am trying to install the roll up on windows servers not Unix .

      Thanks

      • George S
        Reply

        Hi Bassma, this only concerns UNIX/Linux agent installations. The sudoers file on Unix/Linux machines determines what commands users are allowed run. These commands are needed by the SCOM MS to maintain the UNIX/Linux agent. The regex tweak allows for the agent file with version 1.6.10 onwards to work as intended.

        • Jav
          Reply

          Hi, Please could you advise what the Regex tweak is, because the UNIX installs are now failing to install from the SCOM console since we updated to UR4?

          • GEORGE S

            Hi Jav, you can replace the existing regex in the existing sudoers config to cover both single and double digit version numbers for backwards compatibility as below:

            –POSIX style–

            scx-1.[5-9].[[:digit:]]{1,2}-[0-9]

            –“Regular” style–

            scx-1.[5-9].[0-9]{1,2}-[0-9]

            P.S. if these don’t work you may try the simpler regex just know that it only covers double digit version numbers:

            scx-1.[5-9].[0-9][0-9]-[0-9]

          • TheSilverCanuck

            Hey Jav,
            Were you able to figure out the problem? For some strange reason, SQL Service Broker was disabled on my OperationsManager DB since I last successfully pushed the XPlat agent in my lab, which was about 8-9 months ago (i.e. pre-UR4). The strange thing is that such as change (i.e. ALTER DATABASE OperationsManager SET ENABLE_BROKER) cannot normally be made to databases in an AO configuration, which is it configuration?!?! Re-enabling it solved the issue for me.

  10. Nick M
    Reply

    Running into an error when trying to update the agent on ubuntu servers. The new agent upgrade fails to install and the error says it cant find a file to copy. The path in the error does indeed not exist. Running a uninstall and reinstall does work however. Would like to avoid uninstalling and reinstalling all our linux agents, seen anything like this? Full error below.

    Failed to update the cross platform agent. Exit code: 1
    Standard Output: Sudo path: /etc/opt/microsoft/scx/conf/sudodir/

    Standard Error: cp: cannot create regular file ‘/etc/opt/microsoft/omsagent/scom/conf/omsadmin.conf’: No such file or directory
    /opt/microsoft/omsagent/bin/service_control: line 160: /etc/opt/microsoft/omsagent/scom/conf/omsadmin.conf: No such file or directory

    Exception Message:

    ‘/etc/opt/microsoft/omsagent/scom/conf/omsadmin.conf’ does not exist, but it does back a directory. There is no ‘scom’ directory in that path.

    • Nick M
      Reply

      As an update to this, about half the servers I tried to upgrade eventually started showing the new version despite the upgrade wizard stating they all failed. Getting on some of the servers that are not reflecting that version, I can see in apt list –installed that they have the new version running as well but the console seemingly cannot tell that.

    • Kevin Holman Post author
      Reply

      We simply updated UR4 to be offered as “recommended” in Windows Update – this process temporarily removes it from the catalog. 🙁 It should be back up very soon.

  14. JAV
    Reply

    Hi, The UNIX installs are now failing to install from the SCOM console since we updated to UR4? Please could you advise what the Regex tweak is to the Sudoer file?

  15. Martin
    Reply

    Hi Kevin!

    If “SIMPLE Recovery Model” is choosen for the DW database and retention for state hourly data in the warehouse are reduced from lets say 400 to 180, (state hourly data size approx 100GB data)

    1. Is there still a risk of large transaction log and TempDB?
    2. I’m guessing that the increase in the transaction log is temporary until new indexes are created?

    • Kevin Holman Post author
      Reply

      Yes, these is still a risk, it depends on how large the individual transactions are when creating the indexes. I am not hearing about this from all customers, so I assume it impacts customers with very large retention and using FULL recovery models the most. However, it is always good to have plenty of disk space for temporary needs. I haven’t seen this enough to know guidance for “how much space we will need”.

  16. Marlon
    Reply

    I just want to get your thoughts on having to apply the UR4 without stopping the MS healthservice, cshost, and OMSDK services versus doing one MS at a time using the simplified management server updater. I’m just concerned because we have a large environment and if we did not close any connections to MS, we might have a longer time to complete the update.

    Thanks.

    • Kevin Holman Post author
      Reply

      I don’t really understand your question. We do not recommend stopping any services manually. Where are you reading that?

      If an update needs to bounce a service (and they often do) then it handles that as part of the update.

      Whether you use the MSP or the EXE for the server update is irrelevant. Both will try to run SQL scripts and import management packs. The EXE simply gives you a UI to watch the progress of all 3 actions and calls out the log location if there is a problem.

  17. Marcello Rosenberg
    Reply

    Hi Kevin

    Thanks once again for the Step-by-Step guide! 🙂

    We’re currently facing the issue that the console remains blank after installing UR4. We openend a case at Microsoft and the reason for that is the following change in UR4:

    “The MP Reference Alias generator is case-sensitive now and will create only unique Aliases for Management packs.”

    So it seems as we have some references in custom or 3rd party management packs which need to be corrected. The issue is also described here: https://docs.microsoft.com/en-us/answers/questions/898520/scom-2019-ur4-console-problems.html

    Does anyone who had the same issue, found a solution to identify the management packs which need to be corrected, without checking them manually? The script mentioned in the support article and which was also provided during our support case don’t work.

    Thank you in advance and best regards
    Marcello

    • Kevin Holman Post author
      Reply

      I’ll update my SCOM 2019 UR4 article to cover this soon.

      #Identify MPs imported with duplicate Aliases
      $mps = Get-SCOMManagementPack
      foreach ($mp in $mps)
      {
      $hashTable = @{}
      foreach ($ref in $mp.References)
      {
      try {$hashTable.Add($ref.Key, $ref.Value)}
      catch
      {
      $MPName = $mp.Name
      $MPDisplayName = $mp.DisplayName
      $MPVersion = $mp.Version
      “MP contains duplicate aliases: Name=($MPName) DiplayName=($MPDisplayName) Version=($MPVersion)”
      }
      }
      }

  18. Marcello Rosenberg
    Reply

    Hi Kevin

    Thank you very much for your support. The script worked perfect and I was able to get SCOM running with UR4.

    Have a nice day and best regards
    Marcello

  20. Bill Watts
    Reply

    Kevin,
    I recently upgraded from SCOM 2019 to 2022, but it was prior to UR4, so I wasn’t seeing the addition of the “Members” column in the Authoring/Groups portion of the console. Since I didn’t update to UR4, I also didn’t run the updated hotfix to remove that column. In 2022, the column is there – is there a hotfix available to remove it from SCOM 2022, or will it be addressed in UR1 for 2022?
    Thanks,
    Bill

  21. Ron
    Reply

    Anyone encountered the SCOM Linux agent version update issue similar to what the following article described:
    https://social.technet.microsoft.com/Forums/en-US/78401412-2e4e-470c-ac6e-c821bd5fcc87/scom-2019-ur1-unix-agents-show-wrong-version-number?forum=operationsmanagerunixandlinux
    We are experiencing this issue in UR4 linux agent installation where the SCOM console seemed to report the SCOM linux agent was updated to UR4 successfully and even showed 1.6.10-1 as SCOM version after the update in the SCOM console. However, if we login and check the SCOM linux agent version in the server with command line, it is still showing the UR3 version number as if the update was never done. Then a few days later, the SCOM console reversed back to 1.6.8.1 (UR3) by itself. Is there a hot fix we missed or is Microsoft aware of the issue?

  22. Nic
    Reply

    Hi Kevin, i have a Problem with updating with the KB5013427-AMD64-Server.exe file. I have a distributed environment. That means the SQL Server is in another Win VM as the SCOM OpsMgr.

    I opened the Firewalls and even added the SCOM Admin to my SQL Server Instances. but I always run into this failure: Database Configuration => An error is occured while configuring OperationsManagerDW database.

    In the Logs I see some Error Code 1603, but I dont have any clue why this is happening.

    The SCOM2019 Installation is a new one.

    • Nic
      Reply

      Found a solution to my Problem. The User I used to install the update on SCOM Server needs to have Log on as a Service Right at the SQL Server. Otherwise its not possible to deploy the Updates from SCOM Server to SQL Server.

      In flat environments this can be no problem. In our (with lots of GPOs in place) it is a little bit different.

  23. Yasar
    Reply

    I have followed this blog and tried to upgrade SCOM 2019 UR3 to UR4 but reporting server and web server shows previous version of patch as UR3 only did reboot still looks same have i missed anything here ??

    all done from elevated cmd only

  24. Naveen Kumar
    Reply

    Hi kevin,

    I have upgraged scom 2019 to ur4,post upgrade temp log space filled and then we have added more space. But we have checked that create index job is still running for last 1 month. can anyone help in this.

  25. Sreega
    Reply

    Hi Kevin,

    I have upgraded our SCOM 2019 Management servers from UR3 to UR4, in console under Administration–> Operations Manager Products, the management server version is 10.19.10569.0 but I have noticed the MMA agent component on the management server (if I check via Control Panel, MMA Properties–>Properties tab) is 10.19.10050.0. I know the agent update should NOT be installed on a management server but why is this agent component still showing old version? The issue is we are using MMA agent for Log Analytics Workspace and there is a recent update on MS site https://learn.microsoft.com/en-us/services-hub/health/setup-config-log-analytics-scom, which says the below:-
    From 14 April 2023, System Center Operations Manager version lower than 2019 UR3 will stop sending data to Log Analytics workspace. Ensure your agents are on SCOM Agent version 10.19.10177.0 (2019 UR3 or later) or 10.22.10056.0 (2022 RTM) and SCOM Management Group version is SCOM 2022 & 2019 UR3 or later version.

    In such a scenario how do we go about updating the agent component that gets installed on SCOM management server? The log anaytics team says the SCOM management server is reporting its MMA agent component is running version 10.19.10050.0 even though the management server is upgraded to SCOM 2019 UR4. Is this the case of incorrect reporting of MMA agent component of is this agent component not touched with UR updates? Any help would be highly appreciated.

  26. Bas
    Reply

    We haven upgraded to SCOM 2019 UR4 in Januari, also having trouble with a growing transaction log.
    Also we have an issue with the agents, it seems the agents are upgrading but the service is set to disabled.
    Servers with agent version 10.19.10185.0 are still online but UpdateFailed status in PendingManagement(powershell). Agents with the latest version(10.19.10200.0) are set to disabled. When we do a agent repair, the service is set to automatic again and agent is online. Is this a known issue/normal behaviour?

  27. Pascal Verdieu
    Reply

    Has anybody noted a logic bug in GetOpsMgrDBPercentFreeSpace.vbs which feeds the “Operational Database Space Free (%)” Monitor? It will add the space used by the OpsManager log files in addition to the data files in order to make the calculations. For me, it ended up with alerts that I’m -147.59% free…

    • Kevin Holman Post author
      Reply

      Yes I have been meaning to write about this. We fixed the OpsDB free space calculations in UR4, but a new permission is required on the database. I’ll get this added to the known issues soon.

Leave a Reply

Your email address will not be published.