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:
- Install the update rollup package on the following server infrastructure:
- Management Servers
- Web Console Servers
- Gateway Servers
- Operations Console Servers
- Reporting Server
- Apply Agent Updates
- Update Unix/Linux MP’s and Agents
Management Servers
Updates in SCOM 2019 have CHANGED. There is a new process for updating management servers that differs from previous versions of SCOM. Download the single file management server update, and this will ensure that your Management Server Role is updated, as well as any SQL updates, and Management Pack updates.
It doesn’t matter which management server I start with. I simply make sure I only patch one management server at a time to allow for agent failover without overloading any single management server.
I have 2 management servers My first management server holds 3 roles, and each must be patched: Management Server, Web Console, and Console.
The first thing I do when I download the updates from the catalog, is copy the cab files for my language to a single location, and then extract the contents.
Notice the new EXE file, and a MSP file exist for the Server update. The EXE is the new simplified update file, but we included the older MSP for customers who want to continue to use the old process, or use silent installs for patching. I will ONLY demonstrate and recommend the EXE file.
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.
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:
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:
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:
Updating Reporting:
On your server that hosts the SCOM Reporting role, run the update: KB4533415-AMD64-Reporting.msp
Update Agents:
Agents should be placed into pending actions by this update for any agent that was not manually installed (remotely manageable = yes):
***NOTE: For this to work, you MUST run the server update from an elevated command 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:
***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.
Now we will show the “REAL” agent number in the Administration –> Agent Managed view console:
And my SCOM Management Group Management MP, which will help show you REAL UR levels based on a better discovery. This has long been a pain point in SCOM:
https://kevinholman.com/2017/05/09/scom-management-mp-making-a-scom-admins-life-a-little-easier/
Update UNIX/Linux MPs and Agents:
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:
In my environment – I only monitor RedHat and Universal Linux distributions, so this is my pared down list of MP’s to update:
This will take a considerable amount of time to import, and consume a lot of CPU on the management servers and SQL server until complete.
Once it has completed, and before you attempt to update your Linux Agents – verify the updated files are dropped at \Program Files\Microsoft System Center 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:
Now you can deploy the Linux agent updates:
If you have any issues, make sure your SUDOERS file has the correct information pertaining to agent upgrade:
https://kevinholman.com/2016/11/11/monitoring-unix-linux-with-opsmgr-2016/
Update the remaining deployed consoles
This is an important step. I have consoles deployed around my infrastructure – on my Orchestrator server, SCVMM server, on my personal workstation, on all the other SCOM admins on my team, on a Terminal Server we use as a tools machine, etc. These should all get the matching update version.
Verifying the update
There are new views in the SCOM console to help with this and make this process MUCH easier. You do need to wait long enough for the discoveries to run in order for these to update the views.
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:
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.”
- 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'
Will there be any full fledged web console for SCOM in future, with more features on likes other monitoring solutions.
If we have removed the Advisor management packs from SCOM, will this UR1 re-imports the Advisor management packs?
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.
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.
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.
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.
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.
Thanks Kevin,
that indeed I have missed. Now everything looks back in order
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”
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
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.
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.
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.
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
Please see the updated “Known Issues” section of the post.
I don’t see anything referencing a way to fix the 1603 error that is appearing in the installer log under “known issues”
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.”
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.
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.
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
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\Server\SQL Script for Update Rollups\SqlExceptions_{version}.log \Server\Management Packs for Update Rollups\ManualMPImport_{version}.log
SQL Logs:
MP Import Logs:
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?
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\Server\SQL Script for Update Rollups\SqlExceptions_{version}.log \Server\Management Packs for Update Rollups\ManualMPImport_{version}.log
SQL Logs:
MP Import Logs:
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.
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.
My AD integrated clients upgraded fine and do not have any issues.
Pingback:SCOM 2019 with UR1: Service Account Password Freedom at Last – blog.johnjoyner.net
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.
Please see the updated “Known Issues” section of the post.
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!
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.
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
We do not support, and never have supported separation of the MS and the DB with latency. You have an unsupported design. There is no reason to place management servers in remote locations. In our design documentation we state the the maximum latency is 10ms: https://docs.microsoft.com/en-us/system-center/scom/plan-mgmt-group-design?view=sc-om-2019#management-server
Even that is a stretch and would only work for smaller environments. As you scale, and the load grows on SCOM, latency becomes even more critical. I recommend you move your agents to report remotely, or deploy a Gateway if you feel you must have some piece of SCOM infrastructure across the pond.
Thanks for the quick answer,
i’ll correct our design by adding Gateway server instead.
Regards
Pingback:System Center Şubat 2020 Bülten – Sertaç Topal
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?
Hi Eric,
have a look here:
https://social.technet.microsoft.com/Forums/systemcenter/en-US/8b26f51a-bad8-47d2-8284-7ed35f367dd5/an-item-with-the-same-key-has-already-been-added-when-scom-2019-upgrade-to-ur1?forum=operationsmanagerunixandlinux
That has solved it for me.
Thorsten
Sorry, posted the wrong link:
https://social.technet.microsoft.com/Forums/systemcenter/en-US/5a4be487-9472-4be0-afe6-df7bc7168465/scom-2019-universal-linux-monitoring-mp-duplicate-items?forum=operationsmanagermgmtpacks#3ae44fc7-aef5-4e43-849f-f837068a845f
Thorsten is spot on here. This issue is caused by using the old RHEL MP’s to support older RHEL versions, but also using the new Universal (Version Agnostic) MP’s for Linux, so we end up with two computers. We need to disable the discovery of one or the other, then run Remove-SCOMDisabledClassInstance
Hi Kevin, out of interest is there a way to determine what the Remove-SCOMDisabledClassInstance is actually going to remove before running it? I’ve never run it before in my environment however it would be handy to use in a few scenarios, but I’m worried about what it is potentially going to remove.
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
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
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?
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.
hi
aside from sudo, can scom be run using powerbroker rule for unix hosts
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
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.
Had to install a new management server without UR1 to get reporting server installed.
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.
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.
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.
Any word on support for backend to be on SQL 2019?
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.
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.
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?
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.
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.
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?
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.
Kevin,
Indeed we have been upgrading in place. MS Support confirmed and provided the code to adjust the SP and did say it would be included in UR2.
Thanks!
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?
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.
[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
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.
WIJNAND – how did you resolve your SQL errors? I get the exact errors trying to do UR4
I’d be curious about this one too please – as I am getting the same error while trying to apply UR1 to SCOM2022
We are having the same issue on one of our environments.
Started occurring when we applied the hotfix for SCOM 2022 UR1.
Tried installing the recently released UR2 but we get the same error as WIJNAND followed by the error below for three attempts:
UpdateSQLScripts|DB updation failed|Exception In UpdateSQLScriptsMicrosoft.EnterpriseManagement.Common.ServiceNotRunningException: The Data Access service is either not running or not yet initialized. Check the event log for more information. —> System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://localhost:5724/DispatcherService. The connection attempt lasted for a time span of 00:00:02.0088709. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:5724. —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:5724
Which then results to the following error and ending in a 1603 failed install event.
CustomAction _UpdateSql.1451A536_2C9B_42F2_A37A_C9C6460E7EEA returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Are you guys receiving the same errors?
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
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.
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?
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.
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
+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.
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.
UR1 also breaks Powershell (or any other language) scripts that interact with the (really poorly documented) REST API. It enforces CSRF for all interactions. There is no documentation for how to do this at all. At https://stelianposteablog.wordpress.com/2020/04/, he documented how to do it.
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.
Pingback:So, can I monitor RedHat 6 with SCOM 2019 UR1's Universal UNIX/Linux management pack? | TopQore Blog
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
1603 is a generic error for failure. You need to look up higher in the logs for root cause.
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.
Yep. If you send me your log (zipped) in email I could tell you for sure.
done! ty sir
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.
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
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/
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
Hi,
Also having this issue with the Services view under sharepoint 2013 and 2016 folder.
Correction! Should say “Microsoft SQL Server> Summary” !!
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.
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.
No. What do you need?
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!
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.
Wow, thanks 😉
So our old way, is pretty much the best practice way then, and i’ll stick with that.
Thanks for the advice
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.
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.
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
Is Microsoft.SystemCenter.2007.mp and Microsoft.SystemCenter.OperationsManager.Reports.2007.mp Required to be installed with UR1?
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.
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
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
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.
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
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.
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.
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?
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?
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.
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.
We had a situation when a repair of the web console rolled back and removed the web console installation on one of our management servers. Now that we try to re-install it, the setup simply crashes when selecting the web site to use. UR2 is installed on all other Components on this server, so I guess this is similar to the reporting issues.
Do you know of any way to install a web console after UR2 has been applied?
I have uninstalled and reinstalled the web console post UR2 many times.
You might consider uninstalling IIS, rebooting, reinstalling IIS, rebooting, then attempting to reinstall the web console.
bonjour M. KEVIN,
Dite moi sur quel serveur dois-je exécuter la mise à jour automatique des agent Scom
Pingback:Coffee Break: SCOM Update Rollup 1 | SquaredUp
Morning, after installing the KB4551468 from the article https://support.microsoft.com/en-us/topic/system-center-operations-manager-2019-hotfix-for-alert-management-951c3816-b9de-21a7-5a3f-55525de3aca2 it has placed all of my servers (~1000) into pending mgmt for an upgrade. They are all at 2019 UR3.. Do I need to reapply UR3 to fix the issue?
Thanks as always.
Tony
Hi Tony – Why did you apply KB4551468 ?
That was a post UR1 update that was included in UR2 and later. This should NOT be applied to a SCOM 2019 UR3 infrastructure. These updates are fully included in SCOM 2019 UR3. If that is what happened, you are sort of in a corrupt state I think. I would reject everything in pending, then re-apply UR3, or wait shortly for UR4 to release, and apply that to correct the situation you are currently in.
Afternoon,
Thank you very much. I think I will try your recommendation for UR3, if that does not resolve the issue, will wait for UR4.
Regards,
Tony