Menu Close

UR1 for SCOM 2019 – Step by Step

image

KB Article for OpsMgr: https://support.microsoft.com/en-us/help/4533415/update-rollup-1-for-system-center-operations-manager-2019

Download catalog site: http://www.catalog.update.microsoft.com/Search.aspx?q=4533415

Download for the NEW Simplified Management Server Update: HERE

Updated UNIX/Linux Management Packs: https://www.microsoft.com/en-us/download/details.aspx?id=58208

Recommended hotfix page: https://kevinholman.com/2009/01/27/which-scom-hotfixes-should-i-apply/

 

New Features:

  • Support for using Group Managed Service Accounts (gMSA).  LINK
  • Simplified management server patching – a new management server update process which will manage the SQL script updates and Management Pack imports automatically, resolving this common issue with inconsistent Update Rollup application.  LINK
  • Distro-Agnostic management pack for Linux.  New Linux platforms will not require distro-specific MP’s, making monitoring Linux platforms simpler.  LINK
  • Support for RHEL 8
  • Performance improvements in Linux for Heartbeat issues, separating Heartbeat from Performance processes.
  • Multi-Language installers.  Removing the need for language specific update files making the UR download process simpler.

Key fixes:

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

 

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

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.

  • Download: LINK
  • High level install:  LINK

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.

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.

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.
  • ***Note:  There is ONE EXCEPTION to the above statement.  In order for agents to be placed into “Pending Management” view to allow approval of agent patching from the console, you must still have Sysadmin level rights to the SQL server hosting the OperationsManager database.  This flip of agents to pending is a process called on the management server, but it directly communicates with the database.  If you care about this feature, then you will still need Sysadmin to SQL as you did in previous updates. 

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

***Note:  If you get an error here on the Management Pack Import – see “Known Issues” at the bottom of this post before continuing.

 

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

Lastly – install the Console Update (make sure your console is closed):   KB4533415-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 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:

image

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

The update launches a UI and quickly finishes.

 

I can spot-check the \AgentManagement folder, and make sure my agent update files are dropped here correctly:

image

    

Updating Reporting:

image

On your server that hosts the SCOM Reporting role, run the update:   KB4533415-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 prompts, and the user account must be a local admin, SCOM Admin, and have Sysadmin SQL permissions to the instance hosting the OperationsManager database.  The Agents MUST have “Remotely Manageable” set to “Yes”.

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

image

  ***IMPORTANT:  There is a new MP that shipped out of band, available for UR1, that will fix the long known issue that the Agent Version is not correctly displayed on Agent Managed screen.  You can download this new MP separately from the KB article and I am posting the link HERE.

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:

image

You can get the current Unix/Linux MP updates here: https://www.microsoft.com/en-us/download/details.aspx?id=58208

If you have trouble getting the latest updated files, here is a direct LINK

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:

image

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 2016\Operations Manager\Server\AgentManagement\UnixAgents.   If they are not present, sometimes you must restart the Microsoft Monitoring Agent service on the management servers after an update.

You should see the new files dropped with new timestamps:

image

Now you can deploy the Linux agent updates:

image

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

https://kevinholman.com/2016/11/11/monitoring-unix-linux-with-opsmgr-2016/  

 

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. You may see an Error (1603) during the Management Import stage of the update, similar to this in the logs:

  • CustomAction _ImportMpFromPath.1451A536_2C9B_42F2_A37A_C9C6460E7EEA returned actual error code 1603
  • “System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> Microsoft.EnterpriseManagement.Common.ManagementPackException: Cannot load the management pack from the specified sealed assembly file.  Microsoft.EnterpriseManagement.Common.ManagementPackException: This assembly is not fully signed. Cannot verify the strong name signature of the file”
  • This fails due to a dependency on .NET 3.5 which is missing.  UR1 requires .NET 3.5 to be installed on the Management Server in order to attempt MP Import.  However, .NET 3.5 is not required to install nor support SCOM 2019.  This will be fixed in UR2 and we will not require .NET 3.5 anymore for Update Rollups.
  • You have two workarounds.
  • Workaround 1:  Simply ignore the error, continue patching, then MANUALLY import the management packs updating only the ones you already have imported, from \Program Files\Microsoft System Center\Operations Manager\Server\Management Packs for Update Rollups\
  • Workaround 2:  Install .NET 3.5 on the management server, and re-run the Update Rollup.

2.  In the Console, “Help > About” does not reflect that the update was applied to the Console.  UR1 does not update the version in Help/About like previous update rollups for SCOM did. 

  • You have two workarounds:
  • Workaround 1:  Use the Console views: Administration  > Operations Manager Products > Operations Consoles  to verify patch level.
  • Workaround 2:  Inspect the file version of: \Program Files\Microsoft System Center\Operations Manager\Console\Microsoft.MOM.UI.Components.dll to be 10.19.10311.0

3.  The “Operations Manager” Event log on SCOM servers is forced back to the default value of 16MB after you apply the Update Rollup. 

  • If you customized this value on Management Servers (and I recommend doing this) to a larger value such as 60-100MB, this value will be set back to 16MB.  This will result in a Management Server event log that is too small for best practices, and you should set this back to your previously modified value.

4.  Customized registry values might be wiped out by the Update Rollup and reset to default values. 

  • For instance, one of the things I change on SCOM *Management servers*, is the registry value at “HKLM\SYSTEM\CurrentControlSet\services\HealthService\Parameters\Persistence Checkpoint Depth Maximum”.  This is forced back to a default value of 20971520 after you apply the Update Rollup.  I recommend this value be set to 104857600 on SCOM management servers.  There could be others.  If you customize Registry settings on SCOM Agents or Management Servers, you should verify them after applying any Update Rollup as part of your testing, and make a plan to automate fixing them if necessary.  For more details, see https://kevinholman.com/2017/03/08/recommended-registry-tweaks-for-scom-2016-management-servers/

5. The Update Rollup will overwrite the registry path at “HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\InstallDirectory” and modify this path to the C: drive, even when the SCOM Agent is installed to some other drive letter, such as the E: drive. 

  • This can break some automations that read this registry path to determine the agent file location.  You should correct this registry entry manually or via MP automation if this affects you.

6.  Once you apply UR1, 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.”

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

106 Comments

    • Kevin Holman

      No it won’t! The UR’s will now only update an MP if you already have it imported, unless it is special… like the new MP which manages updating the SQL DBs.

  1. Thorsten Schneider

    We’ve run through the installation in our test environment and everything has worked ok. However, I’m confused by the version numbers:
    * The updated SCOM console shows version 10.19.10050.0 in Help/About which is the same as 2019 RTM. The “Operations Consoles” view in SCOM itself shows the correct version (10.19.10311.0)
    * An upgraded agent shows in “Add/Remove programs” still version 10.19.10014.0, while the DLLs have 10.19.10140.0.

    • Kevin Holman

      You are correct. I have reported to the PG that “Help/About” in the console doesn’t show the update and that customers would expect that. However, its good in the Admin section of the console…. but that doesnt help people who run the console on their non-managed desktops, they need an easy way to check their UR level. I hope they will fix this.

      I am not sure we ever updated add/remove programs agent version in any version of SCOM.

      • Thorsten Schneider

        Now that is really confusing:
        I’ve got a multi-homed agent between our test environment (2019 UR1) and our normal environment (2019 RTM). The agent has the UR1 patch installed and shows the new file versions (10.19.10140.0).

        In the updated test environment I see that new version and patch ONLY in the Administration / Agent view. The Monitoring / Operations Manager / Agents by Version still show 10.19.10014.0 and no patch installed).
        Interestingly enough the 2019 RTM environment shows that correct version and patch level in that view.

        Even worse:
        the same problem is in the Administration / Agent Managed view. 2019 UR1 shows the agent as 10014. So how should one find out which agents need to be updated ? That view would be my first choice to check and then to do a right-click Repair.

        Something seems to be broken here.

        • Kevin Holman

          You might be missing the step I called out above, where you need to import the out of band released MP, which fixes the “version” problem in the “Agent Managed” view. I got the product group to add that, and it will be included in UR2 and forward. It will show the correct agent version in “Agent Managed” so you can easily find/update agents that need it.

          On the “Agents by Version” view, it works fine, and shows the correct version and Patchlist shows UR1 as well.

  2. Max Friedrich

    Hi Kevin,
    thanks again for the very good post!

    In our testing enviroment i got the following error by installing UR1 on the first MP and didn’t find anything. The certificate status of the file is shown as “ok” at the server. Maybe you have an idea.

    “Exception thrown by custom action:
    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> Microsoft.EnterpriseManagement.Common.ManagementPackException: Cannot load the management pack from the specified sealed assembly file: F:\Program Files\Microsoft System Center\Operations Manager\Server\Management Packs for Update Rollups\Microsoft.SystemCenter.2007.mp. —> Microsoft.EnterpriseManagement.Common.ManagementPackException: This assembly is not fully signed. Cannot verify the strong name signature of the file: F:\Program Files\Microsoft System Center\Operations Manager\Server\Management Packs for Update Rollups\Microsoft.SystemCenter.2007.mp”

    • Dev Ramdin

      Hi Kevin,

      I have the same issue and happen to be installing to a different drive as well.

      The existing version is 10.19.10050.0

    • Max Friedrich

      The “System Center Core Monitoring” MP was version 10.19.10050.0 from the RTM install process.

      I tried to install it with the “old” way; now it works. The error still appears in the log file with every installation on an additional MP.

      We use Windows Server 2019 with english language and only the german keyboard layout.

    • frederik

      I am experiencing exactly the same issue with the .exe install method.
      When trying the old way, no issues occur, and the installation completes successfully.

    • Brent

      I am also experiencing the exact same 1603 error, specifically pointing to the System.Center.2007.mp. If I remove that MP before the installing fails on it, then it fails with the same error on the next management pack. Install the old way also works; but when installing the MPs manually I run into errors on the Microsoft System Center Adviser and Microsoft System Center Advisor Internal MPs (however the System Center Advisor ENU MP works).Here is the MP import error:

      Database error. MPInfra_p_ManagementPackInstall failed with exception:
      [MP ID: 8ddaefd0-64c9-ce4e-c19c-a39313587353][MP Version: 10.19.10311.0][MP PKT: 31bf3856ad364e35] Database error. MPInfra_p_ManagementPackInstall failed with exception:
      Invalid column name ‘DisplayName’.
      Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 2, current count = 0.

    • Andres

      Same error: “System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> Microsoft.EnterpriseManagement.Common.ManagementPackException: Cannot load the management pack from the specified sealed assembly file: C:\Program Files\Microsoft System Center\Operations Manager\Server\Management Packs for Update Rollups\Microsoft.SystemCenter.2007.mp. —> Microsoft.EnterpriseManagement.Common.ManagementPackException: This assembly is not fully signed. Cannot verify the strong name signature of the file: C:\Program Files\Microsoft System Center\Operations Manager\Server\Management Packs for Update Rollups\Microsoft.SystemCenter.2007.mp”

      There arent log files in “Operations Manager\Server\SQL Script for Update Rollups” nor “\Server\Management Packs for Update Rollups”

      Installation on C drive, EN-US system + Estonian Keyboard

        • Karen

          I don’t see anything referencing a way to fix the 1603 error that is appearing in the installer log under “known issues”

          • Karen

            I get the following in the logs: does this mean the install was successful or error 1603?

            “MSI (s) (C4:B4) [10:02:25:546]: Windows Installer reconfigured the product. Product Name: System Center Operations Manager Server. Product Version: 10.19.10050.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Reconfiguration success or error status: 1603.”

          • Kevin Holman

            1603 is a generic failure. It simply means something went wrong. You have to review the logs more deeplyo to find out specifically what failed. If you search the logs from the top, the root cause will show up very near the first reference to the 1603 generic event.

          • karen

            thanks for the info. it appears that the issue is not having .NET 3.5 installed. I used the exe to upgrade and the scom management server and db upgrades appeared to be successful. it was the MP part of the install. i will review the doc upgrade notes for that issue. thx for replying so soon.

  3. Anu

    Hello Kevin,

    While trying to install we are receiving the below error.

    KB4533415-AMD64-Server. An error occurred. Please view the setup log and try again later.

    When i checked the log files. i am able to see the below error. and am not able to find any mp is imported with today’s date
    [04:42:38]: Info: :Install Progress – (ImportManagementPacksFromPatch) Install Path = E:\Program Files\Microsoft System Center\Operations Manager\Server\
    [04:42:43]: Debug: :ApplyQuickFixEngineering: Return value was 1603. Check the log at C:\Users\\AppData\Local\Temp\KB4533415-AMD64-Server.msp.0.log for more detailed information.
    [04:42:43]: Error: :ApplyQfe: FAILED: We did not successfuly install QFE KB4533415-AMD64-Server.msp.
    [04:42:43]: Debug: :ProcessInstalls: Patcher returned error 1603:Fatal error during installation

    Error 3: -2147287038

    • Kevin Holman

      ANU, can you grab these logs, zip them up, and email them to me. We’d like to take a deeper look.

      kevin.holman@live.com

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

  4. maca

    UR1 installation failed with Error code 1603. User is local administrator on Windows 2019 and does have sysadmin role in SQL2017. Could you please help?

    • Kevin Holman

      MACA, can you grab these logs, zip them up, and email them to me. We’d like to take a deeper look.

      kevin.holman@live.com

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

  5. MTEC

    Hi Kevin,

    If you guys are using Active Directory integration, do not update your agents just yet… the update strips the AD INT configuration leaving the agent not connected to any MGT group. MS have been informed.

  6. Mitesh

    Hi Guy’s
    ,
    If you are using Active Directory integration, do not update your agents just yet… the update strips the AD INT configuration leaving the agent not connected to any MGT group. MS have been informed, and currently investigating.

  7. Pingback:SCOM 2019 with UR1: Service Account Password Freedom at Last – blog.johnjoyner.net

  8. Raoul

    Simplified Management Server Update didn’t work for me. Like many others here I got a “KB4533415-AMD64-Server. An error occurred. Please view the setup log and try again later.”

    The old method works flawless.

  9. FredR

    I did not see anything about stopping services on management servers that have not been updated yet. Is that not necessary with the update rollup? If the services can stay up, it makes change approvals a bit easier. Thanks!

    • Kevin Holman

      That’s correct, there is not need to proactively stop services on all your SCOM management servers. You can update one server at a time and not require an outage anymore. Technically SCOM 2012R2 was the worst about this issue, getting the SQL scripts to deploy. However since SCOM 2016 the SQL scripts don’t make any big changes that get deadlocked. I carried over those recommendations from SCOM 2012R2, but most customers would not have an issue with SCOM 2016 either.

  10. Jonathan

    Hi Kevin,

    Since the update to UR1, my management server in Europe is not able to access the database with the error :
    System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

    I have a latency between 80 to 120 ms

    Note that my Database is in america.

    Regards

  11. Pingback:System Center Şubat 2020 Bülten – Sertaç Topal

  12. Eric

    Hi Kevin,

    After upgrading to UR1 and installed the latest Unix Linux MP I´m getting an error when opening the Unix/Linux Computers view.

    System.ArgumentException: An item with the same key has already been added.
    at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
    at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)

    have you every come across this error when upgrading the MP?

  13. Thorsten Schneider

    Hi Kevin,

    over the last couple of days I was investigating a strange behaviour of SCOM when updating Linux agents. The update succeeded and the new version (1.6.4) was shown in the console. Using rpm -q scx I still would see the old version (1.6.3).

    I’ve posted this on TechNet forum as well:

    https://social.technet.microsoft.com/Forums/systemcenter/en-US/78401412-2e4e-470c-ac6e-c821bd5fcc87/scom-2019-ur1-unix-agents-show-wrong-version-number

    The bottom line is, that the sudoers rules need to be adjusted to accommodate the filename of the new agent package.

    This is what Microsoft has on their page it should look like:
    scomadm ALL=(root) NOPASSWD: /bin/sh -c sh /tmp/scx-scomadm/scx-1.[5-9].[0-9]-[0-9][0-9][0-9].sles.1[[\:digit\:]].x[6-8][4-6].sh –install –enable-opsmgr; EC=$?; cd /tmp; rm -rf /tmp/scx-scomadm; exit $EC

    And the new filename of the agent is:
    scx-1.6.4-7.sles.12.x64.sh

    The regex doesn’t match as it expects a three-digit number, e.g. 1.6.4-999

    I yet don’t know how to change the regex to match one-digit and three-digit numbers as the sudoers file won’t accept something like {1,3}. Didn’t had success with [0-9]* either.

    Can you help and also ask Microsoft to provide a solution and/or change the agent package version number

    The disturbing thing is, that the upgrade of the agent package does not throw an error. Howeve, the installation seems to happen very quickly (basically because it doesn’t do anything). With the adjusted sudoers file for the upgrade command, the installation takes much longer.
    Also strange is that the SCOM console reports the new version number of the agent package although still the old version is installed

    • Thorsten Schneider

      Update: In my previous comment I mentioned that [0-9]* hasn’t worked. Not sure, what I did wrong. This time I got it working for both agent versions by changing sudoers to this:
      scx-1.[5-9].[0-9]-[0-9]*.sles.1[[\:digit\:]].x[6-8][4-6].sh

      That needs to be changed to both the –install and the –upgrade string of all different distributions

  14. Larry

    The update for the reporting server does not work for me. I am having an issue where my reporting server was upgraded to 2019 but it looks like the old version is also installed. If I look in the SCOM console under reporting servers, it shows SCOM 1807 installed. If I check add remove programs on the server it shows : System Center Operations manager version 7.3.13142 and Microsoft System Center Operations manager version 10.19.10050.0 . Furthermore if I run the SCOM 2019 Disc, it only allows a repair and does not allow me to install the reporting. Any ideas on how to fix this?

    • Larry

      I tried uninstalling the 1807 and of course it uninstalled the whole thing. Thankfully I had backups and was able to install 2019 UR1 and restore everything.

  15. Charlez

    Hi All,

    Just installed 2019 UR1 and after that i wanted to install reporting server. In the logs i see this one.
    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

    How to solve this?

    Br

    • Kevin Holman

      Please see the updated “Known Issues” section of the post. I added step 6 with instructions on how to install SCOM reporting after UR1 or later is applied.

    • Kevin Holman

      Please see the updated “Known Issues” section of the post. I added step 6 with instructions on how to install SCOM reporting after UR1 or later is applied.

      • Tetris38

        Hi Kevin, Do you know if internaly, at Microsoft, they already work on a fix ? I’m in the same case, but installing a new MS is really a mess in my secure environment. I’ll try a procmon to see if the installer or
        a service request access to a reqistry kee during the installation. Will update here if I found something.

        • Kevin Holman

          Please see the updated “Known Issues” section of the post. I added step 6 with instructions on how to install SCOM reporting after UR1 or later is applied.

    • Kevin Holman

      It’s on the agenda for adding support – but no timeline has been set. Right now, I’d not expect it to be included in the next Update Rollup.

  16. Mace

    The simplified setup is pretty useless for me as the db update task part “runs forever” on setups with healthservice SID low priv scenarios where no runas accounts are needed/used. The Update MP creates and runs the task, it succeeds but the results are empty and it uses no runas account. The setup doesn’t notice that and waits forever. I have to use the old msp way.

    • Kevin Holman

      To be honest, that doesn’t make sense. The SQL DB update totally ignores HS SID, it executes as specific RunAs accounts:

      For the OpsDB update, it uses the Microsoft.SystemCenter.DatabaseWriteActionAccount (Operational Database Account) PROFILE. This profile has no associations by default, and therefore this update runs as the Management Server Action Account in most deployments. This account does indeed have rights to update and execute a stored proc.

      For the DW update, it uses the Microsoft.SystemCenter.DataWarehouse.ActionAccount (Data Warehouse Account) account PROFILE. This profile is associated with the “Data Warehouse Action Account” which is whatever you provided during setup for the Data Warehouse Write account. The DW Write account has db_owner permission to the DW database, so updates are not an issue.

      If this step does not work for you, it would be interesting to see: what account is it attempting to use, and why? Most likely cause is possibly a misconfiguration during setup, a customization that was not accounted for, or something atypical about your environment. Can you examine these profiles and see what might be happening?

    • Rob

      Check the database permissions. In SQL Management Studio open the database (e.g. OperationsManager), open Security – Users and open the dbo user. There must be a valid user in the login name field.
      That was my problem. After i entered a valid domain user, setup runs without any problems.

  17. Richard

    I’ve tried the simplified methode of updating. It was going rather well it only had issues importing the Advisor management packs. Which resulted in (according to the log):
    System.ArgumentException: The requested management pack is not valid. See inner exception for details.
    Parameter name: managementPack —> Microsoft.EnterpriseManagement.Common.ManagementPackException: Database error. MPInfra_p_ManagementPackInstall failed with exception:
    Database error. MPInfra_p_ManagementPackInstall failed with exception:
    Invalid column name ‘DisplayName’.
    Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 2, current count = 0.

    After restarting console and trying again I got the same error message while trying to import them manually. So I tried removing the old versions of those management packs and then tried importing the new management packs again this time with no issues.

    However when I now try to upgrade the Linux management packs I get the same error message. I’ve removed nearly all linux/unix mps (what a job) and am left with only UNIX/Linux Core Library (and the other UNIX/Linux mps). Trying to get this one to upgrade is a no go, same error. So I’m starting to think there’s something more going on here. And I’m not really looking forward to removing this management pack seeing the number of management packs depend on this one. And I think it shouldn’t have to be this hard to update/upgrade mps.

    Any suggestions on what to check / adjust / redo / where to look would be greatly appreciated.

    • David

      UR1 seems to have modified the Column “DisplayName” field on all tables to a format that include a UID
      “DisplayName_xxxxxxxxxxx”

      This is breaking imports of MPs with updates not just those included with UR1

      They ALL throw the same error

      Database error. MPInfra_p_ManagementPackInstall failed with exception:
      Invalid column name ‘DisplayName’.
      Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 2, current count = 0

      Removing the MP and all dependent MPs will allows you to get the updated MP installed, but I do NOT believe this is correct / intended functionality. Removing and Re-installing 100s of management packs again seems like a fix is needed.

      Doing this for a few MPs that came with the UR1 is not an issue… but trying to update SQL MPs and others will be problematic.

      Kevin… You have any additional wisdom or possible contact on the Product team that can help?

      • Kevin Holman

        We are tracking this issue – it seems to come up in customer environments where they did in place upgrades. We have seen in SCOM 2016 post UR8 as well. I believe we only see in SCOM environments that began as SCOM 2007 and have been continuously upgraded. It is planned to be resolved in the next Update Rollup.

        If you are affected – anytime you import a MP with a Group definition or a Singleton class definition, this happens.

        This happens inside of p_ManagementPackFinishInstall here on these lines:

        SET @StatementForMT = N’UPDATE MT’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’SET MT.DisplayName’ + N’ = LT.LTValue’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’FROM dbo.’ + @TableNameForMT + N’ MT’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’JOIN dbo.LocalizedText LT’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’ ON (MT.BaseManagedEntityId = LT.LTStringId AND LT.LanguageCode = dbo.fn_GetInstallationLocale() AND LT.LTStringType = 1)’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’WHERE MT.DisplayName <> LT.LTValue’ + NCHAR(13);

        The problem as said, is that in environments that were upgraded from 2007 R2, the column name is not be simply “DisplayName”, but in fact, it will be called “DisplayName_55270A70_AC47_C853_C617_236B0CFF9B4C” (exact same GUID all the time).

        Inside that stored proc, you’d have to edit it and do something like:

        DECLARE @DisplayNameColumnName VARCHAR(256)
        SELECT @DisplayNameColumnName = ColumnName
        FROM ManagedTypeProperty
        WHERE ManagedTypeId = dbo.fn_ManagedTypeId_SystemEntity()

        SET @StatementForMT = N’UPDATE MT’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’SET MT.’ + @DisplayNameColumnName + N’ = LT.LTValue’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’FROM dbo.’ + @TableNameForMT + N’ MT’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’JOIN dbo.LocalizedText LT’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’ ON (MT.BaseManagedEntityId = LT.LTStringId AND LT.LanguageCode = dbo.fn_GetInstallationLocale() AND LT.LTStringType = 1)’ + NCHAR(13);
        SET @StatementForMT = @StatementForMT + N’WHERE MT.’ + @DisplayNameColumnName + ‘ <> LT.LTValue’ + NCHAR(13);

        If you open a support case, they will guide any customer through this.

  18. Wijnand

    I have the 1603 error on the UR1 update also. I installed a fresh SCOM2019 environment for testing purposes. One day later I wanted to install the UR1 update which ended in error 1603 as some others mentioned before. Any progress on this error?

    • Kevin Holman

      1603 is a generic error/failure. You’d need to look in the log file itself and find the root cause of the issue which led to the 1603 to understand what specifically caused it to fail in your environment.

      • Wijnand

        [15:41:34]: Debug: :ApplyQuickFixEngineering: Return value was 1603. Check the log at C:\Users\*****\AppData\Local\Temp\KB4533415-AMD64-Server.msp.4.log for more detailed information.
        [15:41:34]: Error: :ApplyQfe: FAILED: We did not successfuly install QFE KB4533415-AMD64-Server.msp.
        [15:41:34]: Debug: :ProcessInstalls: Patcher returned error 1603:Fatal error during installation
        [15:41:34]: Info: :SetProgressScreen: FinishMinorStep.
        [15:41:43]: Info: :Starting C:\Users\******\AppData\Local\Temp\KB4533415-AMD64-Server.msp.4.log

  19. Wijnand

    Calling custom action CAManaged!Microsoft.MOMv3.Setup.MOMv3ManagedCAs.InsertAgentPendingUpdateActions
    MSI (s) (BC:94) [15:40:52:351]: NOTE: custom action _InsertAgentsIntoPendingUpdate_OM12_Mode.1451A536_2C9B_42F2_A37A_C9C6460E7EEA unexpectedly closed the hInstall handle (type MSIHANDLE) provided to it. The custom action should be fixed to not close that handle.
    CustomAction _InsertAgentsIntoPendingUpdate_OM12_Mode.1451A536_2C9B_42F2_A37A_C9C6460E7EEA returned actual error code 1603 but will be translated to success due to continue marking

    at Microsoft.MOMv3.Setup.MOMv3ManagedCAs.UpdateSQLScripts(Session session)
    MSI (s) (BC:E0) [15:41:34:615]: NOTE: custom action _UpdateSql.1451A536_2C9B_42F2_A37A_C9C6460E7EEA unexpectedly closed the hInstall handle (type MSIHANDLE) provided to it. The custom action should be fixed to not close that handle.
    CustomAction _UpdateSql.1451A536_2C9B_42F2_A37A_C9C6460E7EEA returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
    MSI (s) (BC:DC) [15:41:34:616]: Transforming table InstallExecuteSequence.

    MSI (s) (BC:DC) [15:41:34:616]: Transforming table InstallExecuteSequence.

    MSI (s) (BC:DC) [15:41:34:616]: Note: 1: 2262 2: InstallExecuteSequence 3: -2147287038
    Action ended 15:41:34: _UpdateSql.1451A536_2C9B_42F2_A37A_C9C6460E7EEA. Return value 3.
    Action ended 15:41:34: INSTALL. Return value 3.

  20. Mikael

    Hi Kevin, thanks for this post !

    I have a question please.. the update of the agent doesn’t work (task failed) for some servers like my DCs. I would like to update the agent manually but how can I do that without agent.exe ?

    Thanks for your help,

    Mikael

    • Kevin Holman

      The agent update can be downloaded with all the other updates in a UR, and it is also extracted to your server, in the \Program Files\Microsoft System Center 2016\Operations Manager\Server\AgentManagement directories.

  21. Paul

    Just like Charlez; I installed SCOM 2019 UR1 and after that I want to install a reporting server.
    Got the error: 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.
    I tried to uninstall UR1 with: msiexec /uninstall D2E044CF-67FA-4863-A179-D79E6FC232E6 /package 5016D727-313F-451D-9990-4DB326D00F06, but it fails.
    Does anyone know a sollution?

    • Kevin Holman

      Please see the updated “Known Issues” section of the post. I added step 6 with instructions on how to install SCOM reporting after UR1 or later is applied.

      • Paul

        Hi Kevin, can you please send me the workaround per e-mail? I need to setup SCOM Reporting as soon as possible. Thanks! Kind regards Paul

  22. Alexey Degotkov

    +1 to the problem with installation/upgrade Reporting after management servers were upgraded to 2019 UR1. Our production configuration includes 4 management servers. SQL SSRS and SCOM Reporting are installed on the separate database server. Management servers were updated from 2016 to 2019, then UR1 + KB4551468 (hotfix with build 10.19.10349.0) was installed on all management servers. After this we tried to upgrade SCOM reporting and got 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.10349.0.
    Indeed installer’s version is 10.19.10050 however the same upgrade procedure was performed without any errors in dev environment (two management servers and single database servers (all databases + SSRS + SCOM reporting) – a log contains a record that version of installer and management server are matched though conditions were almost same for dev and prod).
    I hope it is a bug and MS will release a fix soon.

    • Kevin Holman

      Please see the updated “Known Issues” section of the post. I added step 6 with instructions on how to install SCOM reporting after UR1 or later is applied.

  23. Kevin Holman

    Please see the updated “Known Issues” section of the post. I added step 6 with instructions on how to install SCOM reporting after UR1 or later is applied.

  24. Pingback:So, can I monitor RedHat 6 with SCOM 2019 UR1's Universal UNIX/Linux management pack? | TopQore Blog

  25. dave

    Hello. Did anyone ever find out how to resolve the 1603 error with the following entries in the setup logs. ive tried both running the exe and the msp and getting the same results.

    Debug: :ApplyQuickFixEngineering: Return value was 1603. Check the log at C:\Users\\AppData\Local\Temp\KB4533415-AMD64-Server.msp.0.log for more detailed information.
    Error: :ApplyQfe: FAILED: We did not successfuly install QFE KB4533415-AMD64-Server.msp.
    Debug: :ProcessInstalls: Patcher returned error 1603:Fatal error during installation

  26. dave

    so i think it might be related to the first entry in ur blog…..i do see it erroring out at the MP import but when i did chk the mgmt console on the 1st mgmt server, i do see it listing Update Rollup 1 Patch. Could the error simply be related to the .net 3.5 issue as i do not that 3.5 is not installed on my mgmt servers. Im assuming i can ignore it and manually import the MPs after the fact.

  27. Kevin Holman

    Just for clarity – if you want to know WHY your update is failing with a 1603 generic error, search your update logfile for “1603”. You will find the section where this is thrown, and better understand why.

    For the issue where the MP’s fail to import because we are missing .NET 3.5 on the management server, you will find something similar to this: (the key is “This assembly is not fully signed. Cannot verify the strong name signature of the file”)

    Calling custom action CAManaged!Microsoft.MOMv3.Setup.MOMv3ManagedCAs.ImportManagementPacksFromPatch
    –snip–
    Exception thrown by custom action:
    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> Microsoft.EnterpriseManagement.Common.ManagementPackException: Cannot load the management pack from the specified sealed assembly file: D:\Program Files\Microsoft System Center\Operations Manager\Server\Management Packs for Update Rollups\Microsoft.SystemCenter.2007.mp. —> Microsoft.EnterpriseManagement.Common.ManagementPackException: This assembly is not fully signed. Cannot verify the strong name signature of the file: D:\Program Files\Microsoft System Center\Operations Manager\Server\Management Packs for Update Rollups\Microsoft.SystemCenter.2007.mp
    –snip–
    MSI (s) (10:1C) [21:07:42:355]: NOTE: custom action _ImportMpFromPath.1451A536_2C9B_42F2_A37A_C9C6460E7EEA unexpectedly closed the hInstall handle (type MSIHANDLE) provided to it. The custom action should be fixed to not close that handle.
    CustomAction _ImportMpFromPath.1451A536_2C9B_42F2_A37A_C9C6460E7EEA returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
    –snip–
    MSI (s) (10:98) [21:07:42:360]: Note: 1: 2262 2: InstallExecuteSequence 3: -2147287038
    Action ended 21:07:42: _ImportMpFromPath.1451A536_2C9B_42F2_A37A_C9C6460E7EEA. Return value 3.
    Action ended 21:07:42: INSTALL. Return value 3.

  28. Simon Jäggi

    Hey Kevin,

    Thanks for the post! I’ve managed to update the SCOM servers and push installed agents. Now the following question is presenting itself to me:
    If I use the original SCOM files (file export by scom2019.exe) to manually install a new agent, the new agent won’t be installed with the UR1, right? If so, is it possible to update the installer, so that the agent update is integrated? I haven’t found anything on this (probably because I use some wrong formulation), so I’m asking you (or anyone who might see this comment).

    Thanks in advance

    Regards,
    Simon

    • Kevin Holman

      There is no slipstream capability to integrate the agent update into a new installer file. You deploy the agent, then you install the update. When you do an agent “push” from the console, this happens automatically, because MOMAgentinstaller.exe manages this process from the management server. For manually installed agents, you need to manually update them (or use WSUS, SCCM, etc)

      You could also create a management pack with a script to install the agent update. https://kevinholman.com/2019/11/18/advanced-mp-authoring-mpu-nov-2019/

  29. Davy

    Thanks Kevin, successfully installed UR1 today across our SCOM landscape, including updating the consoles, agents etc. I’m assuming your out-of-band MP has been rolled in now as I’m getting the correct agent versions displayed across the board?

    I just have two outstanding issues with the web console though, the first relates to our previously installed SP 2013 MP which is generally working great, however there is a single view “Services” that doesn’t render and I get…

    “Server Error
    500 – Internal server error.
    There is a problem with the resource you are looking for, and it cannot be displayed.”

    The other issue is in, for example, the “Microsoft Server> Summary” dashboard view where a box pops up with…

    “An embedded page on this page says error!”

    …the state tiles don’t update properly, nor can I drill down through them.

    These issues occur in both Chrome and IE.

    Any guidance greatly appreciated.

    Cheers

    • Kevin Holman

      The error in some dashboards is a known issue and this is being addressed in future updates of SCOM and some MP’s, such as SQL.

  30. Talvinder

    Hi Kevin, Is there an article or documentation regarding the ‘system center internal library’ version 7.0.8445.6 please? I did a search but couldn’t find anything.

  31. Ronan

    Hi Kevin and thank you for this and a number of other posts that were very handy during my SCOM 2019 upgrade all the way from SCOM 2012 R2.

    Traditionally we’ve imported MPs from disk having manually downloaded them. I’m playing with the catalog to see if it’s easier as in theory it should one would think know about the “latest” for any given pack.

    I am however stumped – i’m finding instances where the management pack isn’t in the catalog at all. For example Dynamics CRM 2016 and Sharepoint Server 2016 – neither appear in the catalog that i can see, but both are available through direct download links.

    Am i missing something?

    Do people generally use the catalog? The other drawback it seems to have in my book is, no links to the associated management pack guide or documentation.

    thanks!

    • Kevin Holman

      You aren’t missing anything.

      I hate the catalog. I wish we didn’t have it. If it ONLY served as a notification of updated MP’s available, I’d like it OK. In my opinion, using the catalog to direct import/update is a worst practice and I recommend to my customers to NOT use it.

      The problem is…. sometimes there is a disconnect in developing “cool features”/”trying to make things easier” in conflict with operational best practices. Here are the issues with the MP catalog, in my opinion:

      1. We don’t keep it up to date. Historically, we never really have. There have always been and continue to be inconsistencies with when a MP releases and if/when it shows up in the catalog.
      2. The catalog recommends MP’s you DONT need. Just because we detect there is a MP you don’t have, doesn’t mean you should import it. All MP’s should have a business need, and an internal owner. If you don’t, then all you have is noise. (which happens to be to top complaint in SCOM…. customers can be their own worst enemy at times)
      3. The catalog can create/recommend unsupported situations. It often will show you have an update available for a SQL MP, but only because that updated individual MP is shared across multiple downloads, and ONE of them was updated. If you upgrade ONLY that one MP, you technically create an unsupported mismatch of MP’s that was not intended, nor tested in that manner.
      4. The “Updates and Recommendations” MP creates a large number of classes, and instances where we “discover” if you might software in your network, that you don’t have an MP for. These discoveries and large instances needlessly bloat the instance space, which is already limited. Over time, instance space bloat creates performance issues and slower consoles. For this reason, I recommend to my customers to delete the “Updates and Recommendations” MP.
      5. When you import MP’s directly from the catalog, you create a worst practice. All customers should download MP’s as a unit, and store them in a highly available file share on their network. Then, you should keep previous versions of MP’s and store them by version. This allows for two best practices: (1) In the event of a disaster, you can get back up and running quickly as you have all the MP’s you depend on in a single location. (2) if you discover a major issue in an MP, you can remove it and go back to your previous version because you have it on disk! When Microsoft releases a new MP, all previous versions are unavailable.
      6. The catalog recommends MP’s that are no longer supported. Just look, at how many Windows Server 2008/2008R2 MP’s are still being recommended, SharePoint 2010… really?
      7. The catalog complains your MP’s are partially installed. For instance, in the base OS MP, I never import the “Windows Server 2008 R2 Best Practice Analyzer Monitoring” Management pack. This MP was a bad idea, and just generated noise, for very little value. I do not import it in any customer environment. The catalog still complains that I don’t have it…. which is noise.

      • Ronan

        Wow, thanks 😉

        So our old way, is pretty much the best practice way then, and i’ll stick with that.

        Thanks for the advice

  32. Roger

    Hi Kevin, I’ve been running 2019 in production for a few days now. Before that, in test for a while.
    I seem to have missed out on something regarding the agents requiring upgrade.
    I had a load of agents in my Console, when upgrading to UR1;
    And after the upgrade, those agents showed up in Pending Management requiring an upgrade.
    But now, I’m importing more agents from our old 2016 env. with 1807 agents, these agents don’t show up in Pending Management. I have set these agents to Manually Installed=False

    Please don’t tell me I have to upgrade those manually.

    • Kevin Holman

      Hi Roger,

      This is how SCOM has always worked. Agents are placed into pending *one* time, at the moment you run an Update Rollup, for all agents that are not set to Manually installed, at that moment. We do not “discover” that an agent needs an update, and individual move that agent into pending.

      That said, you can use a “repair” action to upgrade those new stragglers. Or, you can bring them all in, ensure they are not set to manually installed, and re-apply only the server update UR1 file. This will re-trigger EVERYONE to go into pending, whether it needs 2019 UR1 or not.

  33. SCOMGuy

    Hi Kevin,

    I have a requirement to monitor Linux agents via gateway server. Scenario is SCOM MS in Domain-A, GW in Domain-B, Unix agent in Domain-B. Can I monitor Unix agent in Domain-B with SCOM MS in Domain-A using Kerberoes authentication via GW in Domain-B? GW in Domain-B is connected to SCOM MS in Domain-A and already monitors lots of Windows agents in Domain-B without any issues.

    Do you know if SCOM 2019 also supports Kerberos authentication for WSMAN to monitor a Linux agent via gateway server? MS site https://docs.microsoft.com/en-us/system-center/scom/manage-linux-kerberos-auth?view=sc-om-2019#steps-to-enable-kerberos-authentication-on-a-management-server says the registry key needs to be created on Management server but doesn’t say gateway?

    Thanks,
    SCOMGuy

  34. Karen

    Is Microsoft.SystemCenter.2007.mp and Microsoft.SystemCenter.OperationsManager.Reports.2007.mp Required to be installed with UR1?

  35. Anthony Ashmead

    Hi Kevin, Just an FYI that may help others.
    When using KB4533415-AMD64-Server.exe to update my MGMT servers, 2 out the 8 I patched automatically rebooted with no warning once this completed. App Evt log showed the “msinstaller” finishing and then initiating the reboot automatically
    Regards, Anthony.

  36. ROBERT DAVIGNON

    Hi Kevin,
    Before UR1 and KB4551468, if someone resets manually the health of a monitor, in the Alert History we saw “Alert Resolved by Domain\UserID”. Sometime it was pretty usefull for diagnostic. Now it’s always “Alert Resolved by the System”. It’s hard now to tell if it was auto-resolved or if it was manually done.
    Regards, Robert

  37. Tony Strother

    Morning Kevin, I installed the “hotfix” for 2019 UR1, KB4551468. The functionality to be able to close alerts that still have the underlying issue is not working. Any fix for this?
    Thank you,
    TS

    • Kevin Holman

      If the monitor is unhealthy, you will not be able to close the alert. That has not changed, by design. This is a key differentiator of SCOM 2019. You must solve the root cause (which drives monitor state) or reset the monitor, to close the alert.

      If you have alerts from monitors that will not close, but the monitor is healthy – this is a different scenario. This should only happen when a monitor doesn’t alert by default, but you have overridden it to generate an alert. If this is the case, make sure there is an override present for the “Alert On State” property. Even if you do not change the default setting. Once this override is present, you will be able to close alerts from this specific scenario, where the monitor is healthy, but the alert will not close.

  38. Tony Strother

    Morning and thank you. I was only concerned because the page said this “hotfix” corrects not being able to close monitor alerts that still have the underlying issue. When I tried it still would not let me. Perhaps I read it wrong? I do not ever close those monitors, even in our 2012R2 environment, just asking.

    Thanks, as always,
    TS

  39. Ajay Pawar

    Hi Kevin,

    We recently upgraded to UR1 successfully, all existing agents got moved to pending management and we approved them to update. however now new agents that we install using MOMAgent.msi file shows 10.19.10041 version.
    Is there setup available for MOMAgent.msi version 10.19.10140.0? OR We have to install 10.19.10041 and patch it with KB4533415-AMD64-Agent.msp on each new agent afterwards.

    • Kevin Holman

      SCOM does not provide new MSI’s for install. You deploy the SCOM 2019 RTM agent (10.19.10014.0) then update it using the latest UR file, or use Windows Updates to patch it. So if you are deploying agents using something like SCCM, you should deploy another package in SCCM to find any agents that don’t have whatever UR is current, and patch them.

      • Tony

        Hi Kevin,

        I’m facing the same issue after running manually the MOMAgent.msi setup on the agent server with the admin user, the agent still shows (10.19.10014.0) version.
        Also, my MG server is upgraded to 2019 UR2. Inside amd64 I’ve found a new file named KB4558752-amd64-Agent.msp but unfortunately I can’t run it. Tried to open it using msiexec.exe /p “C:\Users\****\Desktop\amd64\KB4558752-AMD64-Console.msp command with no luck, its showing “this patch package cannot be opened. Contact the application vendor..” Is there a specific way to update the agent using the latest UR file?

  40. Tony

    Hi Kevin,

    I’m facing the same issue after running manually the MOMAgent.msi setup on the agent server with the admin user, the agent still shows (10.19.10014.0) version.
    Also, my MG server is upgraded to 2019 UR2. Inside amd64 I’ve found a new file named KB4558752-amd64-Agent.msp but unfortunately I can’t run it. Tried to open it using msiexec.exe /p “C:\Users\****\Desktop\amd64\KB4558752-AMD64-Console.msp command with no luck, its showing “this patch package cannot be opened. Contact the application vendor..” Is there a specific way to update the agent using the latest UR file?

    • Kevin Holman

      You can use that MSP file to update an agent, or you can download the Agent update file from the catalog, the same place you downloaded the updates from.

  41. Bala

    Hi Kevin,

    We upgraded SCOM 2019 to SCOM 2019 UR1 in test environment and everything has worked ok. but in the Console, “Help > About” does not reflect the update was applied to the Console and further understood its a bug in SCOM 2019 UR1.

    At the same time I ran Operation manager powershell in Management Server to know what is the SCOM build version, Unfortunately, it also shows build version of SCOM 2019 (10.19.10050.0) in Operation manager powershell and not the upgraded SCOM 2019 UR1 build number (10.19.10311.0). Any idea why it is showing SCOM 2019 version. I imported “SCOM managemment pack” for knowing versions of SCOM components and it shows correct version and KB number of SCOM 2019 UR1. Anything I missed here??

    And also I ran the SQL scripts located under %SystemDrive%\Program Files\Microsoft System Center 2016\Operations Manager\Server\SQL Script for Update Rollups on Operations Database & Data Warehouse database. It ran successfully. But I tried running SQLpatch version and can see two values as(10.19.10050.0 as completed), (10.19.10311.0 as completed) as output. Please suggest how to identify and confirm via SQL that SCOM 2019 UR1 is updated in Ops DB and Ops DW DB tables with updated SCOM 2019 UR1 Update rollup 1.

Leave a Reply

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