I was recently working with a customer who had 40 Gateway servers in SCOM.
They also recently upgraded their SCOM version. Upgrading each of these gateways is a big pain for them, as they are in firewalled environments, and they have to request temporary administrative access just to do maintenance.
After upgrading each Gateway they also had to then apply an Update Rollup.
In this article – we will show how to use a Management Pack to distribute the Gateway Upgrade files and the Gateway Update Rollup files, then use a task to initiate the upgrade/updates. This greatly reduces the impact of keeping these servers updated, and there is no need to even log on to the Gateway nor have administrative access to the VM.
The Management Packs:
Upgrade SCOM 2012R2 Gateway to SCOM 2016
Upgrade SCOM 2016 Gateway to SCOM 2019
Upgrade SCOM 2019 Gateway to SCOM 2022
Apply UR10 to SCOM 2016 Gateway
Apply UR3 to SCOM 2019 Gateway
Apply UR4 to SCOM 2019 Gateway
Apply UR1 to SCOM 2022 Gateway
Here is an example of a SCOM 2012R2 to SCOM 2016 Gateway upgrade in place:
If you have upgraded to SCOM 2016 from SCOM 2012R2 – and still have SCOM 2012R2 Gateways, you can import the SCOM.GatewayUpgrade.2012R2to2016.mpb Management Pack.
This MP will create a new folder on all Gateway servers and copy the SCOM 2016 Gateway upgrade files locally:
This MP will display a new Folder/View in the console – called “Gateway Upgrade”
Select the Gateway(s) you wish to upgrade, and run the upgrade task:
Look at the output of the task:
You can check the version in the console after about 10 minutes, or you can use my SCOM Management MP to verify the upgrade worked. You must allow sufficient time for the discoveries to run and update the views:
Next, we can use a Management Pack to apply the update rollup.
Import the SCOM.GatewayUpdate.2016UR10.mpb Management Pack.
This MP will create a new folder on all Gateway servers and copy the SCOM 2016 Gateway Update Rollup files locally:
This MP will display a new Folder/View in the console – called “Gateway Update”
Select the Gateway(s) you wish to upgrade, and run the update task:
Look at the output of the task:
You can check the version in the console after about 10 minutes using my SCOM Management MP to verify the upgrade worked. You must allow sufficient time for the discoveries to run and update the views:
If you’d like to see how to create management packs that can contain files and distribute them to SCOM agents using the SCOM communication channel – watch my video here where I build one from scratch:
Advanced MP Authoring -MPU Nov 2019 – Kevin Holman’s Blog
Let me know in the comments if you have other ideas where a MP like this can help you administer and maintain your SCOM infrastructures!
This is awesome. Going to give it a try for 2012-2022 upgrade. Thanks Kevin.
Great post! So much easier then visiting each GW.
I’m using the same mechanism to also upgrade and/or update the SCOM Agents on Windows servers.
I’d love to hear how that works for you. My only reservation about doing this for agents, is that the INSTANT you import an Agent targeted MP, you will distribute the binary agent upgrade files inside the MP (either Agent or Update Rollup) immediately to ALL agents.
Agent version upgrade file is around 30mb.
Agent update rollup can vary, but lately around 7MB.
My concern was if I had 5000 agents, SCOM would immediately distribute 5000 x 30mb = 150GB across the network, all at once. This might saturate slow, remote links or cause some network congestion. We do not have a throttling mechanism. And we do not have very many MP’s that are this large to compare to.
I do think performing in-place agent upgrades inside a MP is a super easy way to ensure your agents are all up to date, but it sure makes me nervous on the network side.
I am using the same MP as Michiel does (he once shared it with me and I am maintaining it myself since then). It works great for me. No issues regarding to the network performance with distributing the agents UR and it so much easier for agents that are not remotely manageable for example.
Love it. How many Windows agents in the management group total?
I work with two totally separate SCOM environments. (Also different networks)
One Management Group has 800 Windows agents. The other Management Group has almost 700 Windows agents.
Obviously your concern regarding network saturation/congestion is completely valid!
So it is advised to carefully plan the import of the Agent targeted MP (.mpb) that includes the Agent and/or Update Rollup binary. As we do not have slow links we did not find any problems distributing a 40 MB .mpb file to about 250 Agents at once.
Wow. This is great.
Thanks Kevin. 🙂
Hi Kevin, after UR4 update to my gateway, I have a warning:
Obsolete aliases found in unsealed management packs.
Total nunber of obsolete aliases: 1
MP: “SCOM.GatewayUpdate.2019UR4”, Alias: ()
Nothing to be worried of, I think but, any idea of the reason ?
Where does this alert come from? Something custom that looks for bad references?
There are some unused references – like Health and Performance aliases – but this should not be cause for any alarm.
Thank You Kevin. I have same kind need for my Console servers to update UR4.
This package is for Gateways. Consoles would not apply. You can apply UR4 console update directly, along with the Post-UR4 console update. I’m not sure why you would want a management pack to help with this?
I’m new with SCOM and trying to build a lab but im having some troubles with
Web application – Transaction Monitoring:
Windows server 2016
when I click capture it runs IE put without web recorder pane
I tried :
change the registry value for
but still not open.
thank you for your time.
I tried Windows Server 2012r2 still negative status.
I tried Windows Server 2016 still negative status.
I tried Windows 10×64 still negative status.
Hi Kevin, will you release a management pack for updating gateways from 2022 RTM to 2022 UR1?
Ok, I added that one. Is this useful for you?
Excellent! Thanks 🙂
A question regarding deploy of files to gatewayserver by the MP. Does it use the same folder as prevoius upgraddes – ie 2019 to 2022 RTM (C:\SCOM2022GatewayFiles)? It seems to not be able to replace files in an already existing folder with the new 2022UR1 mp. Could it be a tip to make location for files as an overridable value?
Why would it need to replace files?
Previous files in the folder prevents new from files being copied – most importantly the UR1-file. Then the UR1-task is not possible to run from the console.