You probably have a lot of agents that are not up to date. Perhaps you recently did a side by side migration and have a lot of older SCOM agents that need an upgrade. Perhaps you are just way behind on getting the latest update rollup out?
Did you know that you can use tasks in SCOM to perform the agent upgrades?
First – Download and import my SCOM Management MP:
SCOM Management – MP – Making a SCOM Admin’s life a little easier – Kevin Holman’s Blog
Next, once all the SCOM Agents are discovered – use the SCOM Agent view to see the task for “Execute Software From Share”
We can use this task to install software on agents, as long as the agent action account (Local System) has rights to the share, and can connect to it.
So – let’s prepare our share first.
On one of your management servers, browse to the location that you installed SCOM. We are going to share the amd64 folder.
Example: \Program Files\Microsoft System Center\Operations Manager\Server\AgentManagement\amd64
Right click amd64 and choose properties. Choose “Sharing” and select “Advanced Sharing”
Select the box to “Share this folder” and provide a share name.
Select “permissions” and ensure that “Everyone” has read:
You just need to ensure that the Computer Accounts in the domain can read the share. Use “Authenticated Users” instead of Everyone if your organization doesn’t allow the Everyone group.
Next, we need to grant NTFS permissions to the files in the share.
Select the Security tab of the amd64 folder, and click “Edit”.
Add the “Authenticated Users” group to have Read, List folder contents, and Read & Execute permissions.
Note: You don’t have to share from the SCOM server. You can just as easily copy the agent files to an existing share if permissions are sufficient as above.
Now that our share is complete – we can use the task and start upgrading agents.
I have several SCOM 2012 agents in this example that I need to get upgraded to SCOM 2019:
I need to override the command line with the following:
"msiexec.exe /i \\omms1\SCOMAgent\MOMAgent.msi NOAPM=1 AcceptEndUserLicenseAgreement=1"
This command line also installs without APM (per the NOAPM=1). You can leave this out if your organization uses APM.
By default I use the built in RunAs account, which is Local System. You theoretically could input a user account here to perform the install. This would require:
1. The user has “Log on as a service” right on the agent machine (for SCOM 2019 and later) or “Log on locally” right (for SCOM 2016 and earlier)
2. The user has rights to read and execute from the share.
3. The user has local administrator rights on the agent machine (to be able to install software).
This task will always report “Success” – EVEN if the task is NOT successful. Because the task simply calls the command line. It does not wait nor understand if the software actually installed.
Next, you can log on to a targeted agent and review the Application Event Log:
And soon your SCOM Agents view will show the upgrade worked:
Next – we can use the same method – to update the agents to UR3:
"msiexec.exe /p \\omms1\SCOMAgent\KB4594078-amd64-Agent.msp /qn"
Check the application event log on the agent:
And in a few minutes – the SCOM Agent view shows the update was a success!
In summary – we can execute and install software from a share using SCOM tasks.
We can even upgrade or update the agents as long as we can provide a command line to the task.
Some examples of those command lines are below:
Upgrade an existing agent: "msiexec.exe /i \\omms1\SCOMAgent\MOMAgent.msi NOAPM=1 AcceptEndUserLicenseAgreement=1" Apply an Update Rollup patch file to an agent: "msiexec.exe /p \\omms1\SCOMAgent\KB4594078-amd64-Agent.msp /qn"
If you want to get REALLY fancy – you can skip the task and share, and EMBED the agent upgrade/update files into a Management Pack, and use scripts to apply the updates automatically. This is an advanced authoring exercise to embed binary files into your MP’s, but if interested check out my video on doing this:
Pingback:Top 5 SCOM community recommendations: April SCOMathon Newsletter - SCOMathon
How to get the list of scom agent upgrade pending servers in excel format
Could using this method to upgrade agents cause them to refresh or recalculate which in turn could potentially send out alerts as if they were new alerts?
I suppose it could, if the task reinstalled the agent, and it re-initialized monitors, and then sent up a new state change event. But that seems like it would be rare. What kind of monitors did it cause a re-alerting on?
Hi Kevin
Thanks as always with your great articles
Interesting view on parameters for MSP upgrade, where you are not using the REINSTALL=ALL
Where I can read:
/p – install an MSP patch. When installing a patch silently, you need to set REINSTALLMODE property to “ecmus” and REINSTALL to “ALL”. Otherwise the patch will simply update the MSI cached on the target machine.
The funny part of using REINSTALL=ALL (Which Pending update Management in console also use” is the UR1 for SCOM 2022 comes with on local server application log
“Product: Microsoft Monitoring Agent — Error 1923.Service ‘@C:\Windows\system32\AdtAgent.exe,-500’ (AdtAgent) could not be installed. Verify that you have sufficient privileges to install system services.” on servers, even the console (or manually run on server) says it is succesfull
sorry, under wrong thread, but hope you will look at it a new one
This may be the wrong thread for this post, but it’s my only hit result that gives me a lead to my issue. @Peter did you get an answer in the ‘right’ thread? Can you tell me where to find it?
Potentially one hell of a security risk; it is really important to tie down permissions on the task and on the share and audit access to the share and use of the task.
The code is great to learn from but I wouldn’t risk putting anything like this anywhere near a SCOM environment I was responsible for.
Good afternoon, some points I noticed:
1 – Going into Administration >> agent managed and clicking on the migrated and updated machine, the options to reinstall, uninstall… are grayed out and dont work.
2 – and the remote Manageable option set to NO.
3 – Even if I put NOAPM=1 in the installation line, it remains enabled.
4 – Installed By appears as unknown.
Would you be able to settle these options in the Novo Management Group?
Thanks a lot if you can help me.
https://kevinholman.com/2010/02/20/how-to-get-your-agents-back-to-remotely-manageable-in-scom/
Pingback:Upgrade from SCOM 2019 to SCOM 2022 Checklist – Kevin Holman's Blog
My entire environment is using the OMS Agent, which has a higher version than the current SCOM 2019 version.
Now that the OMS Agent is out of support, I need to uninstall it from all servers and install the older SCOM 2019 agent to ensure all servers report exclusively to SCOM. How can I automate this process?