Not too long ago, the OMS team introduced the Update Management solution. This solution has definitely made the patch management process a lot easier, however at the same time, has raised some questions, such as:
- What’s the future of SCCM (Configuration Manager) with OMS now deploying patches?
- Can this be used concurrently/dual-homed with SCCM for on-premises environments?
- Is OMS essentially System Center in the cloud?
- Is OMS the future?
For the most part, SCCM will still be required for on-premises environments. When it comes to application deployments, computer/server images, granularity with patch/hotfix selection, etc. Microsoft has explicitly stated SCCM configured machines cannot be tagged to OMS with respect to patching, so at the current time, OMS and SCCM cannot/will not work together, whereas OMS and SCOM work hand-in-hand (for now?).
It also seems OMS is slowly becoming System Center in the cloud. It has absorbed the monitoring capabilities from SCOM, and now the patch management process from WSUS and SCCM.
So, is OMS the future, in my opinion, no, it is not the future, it is very much the present! I think OMS/Azure will soon welcome the demise of System Center.
Getting started with OMS Update Management is very easy. For starters, you will need the following:
- OMS Workspace
- Update Management Solution added to OMS
- Automation account (create in Azure first)
- Machines to manage
Once we have taken care of these steps, the rest is pretty easy.
Clicking on the Update Management title, here is an overview.
Update Management Overview
As we can see, I have a few machines that need some updates. I haven’t introduce a Linux machine to OMS yet (had to create a new workspace recently… Maybe I will get to that in another blog post, until then..)
If we move over to the right, and click on Manage Update Deployments, we can then see our current configuration and schedules, and create new ones.
Create an Update Deployment
Creating a deployment schedule is very, very easy!
Name your deployment, and select some computers to manage in this group.
Notice the big red box, we cannot couple machines with OMS Update and System Center Configuration Manager!
Next, create a schedule, for example deploy patches on the Last Sunday of the month, and run the schedule for 5 hours (300 minutes). If a machine is unable to complete the patching cycle within the 300 minutes, it will resume with patches at the next scheduled deployment.
We can also choose to run this schedule 1-time, or reoccur weekly. Once happy with the schedule and computers, hit Save.
Once saved, we can now see our Scheduled Update Deployment.
Post Update Deployment
Once the Update Deployment has executed, let’s take a quick look at the updates that were applied.
If go back to OMS and select the results, we can see what patches were applied, what failed, etc.
We can also expand further, by seeing the KB for the patch, and the exact patch that was applied, or failed, or missed, etc.
If we go back to the Update Deployments, we can see our deployment ran as planned, and patched the 4 servers in the group (one of the five machines was offline).
Now we should have a better/happier Update Management Overview:
Here’s the title from OMS (All Solutions) view:
So how exactly did this all happen?
How the Update Management Solution Work?
The short answer is, “I don’t know.” 🙂
I say this because the solution clearly adds two Runbooks to the solution, and both of these Runbooks are not accessible and not even visible. If you dig a bit into the Job details, then we can see some information. But overall, the guts of this solution is pretty well hidden.
Go into your Azure portal (ARM — Azure Resource Manager) and find Automation Account you created for this solution to work. I called mine, “OMSUpdateMgmt“.
As you can see, there are 0 (Zero) Runbooks… and we now have 7 Hybrid Worker Groups.
If we click on the Jobs title, we can see 4 jobs completed (I had 5 schedules/deployments. I cancelled 1).
If we click on this title, we can get some more information:
Ah ha!! There are the Runbooks, “Patch-MicrosoftOMSComputer” and “Patch-MicrosoftOMSComputers“. If we select one of the jobs, we can get some more detail.
We can now see the Runbook executed against my SQL server.
If we click on Input, we can see the Runbook, “Patch-MicrosoftOMSComputer” has 6 Input parameters:
- WORKSPACEID
- DURATION
- SCHEDULENAME
- MACHINEID
- STARTTIMEUTC
- MASTERJOBID
If we go back to the OMSUpdateMgmt Automation Account overview, and select Hybrid Worker Groups, we can get some more insight. 😉
Nice, the Automation Account found all the machines in my workspace, and made them each a worker.
FINAL THOUGHTS
Pros:
- Very easy to create collections/groups (similar approach to SCCM/WSUS)
- Simple setup for multiple patch cycles
- Able to patch Nano machines as well
- Can leverage OMS Alerting for missed patches
- Complexity of the implementation could not be easier
- Works for both Windows Server and Client OS
Cons:
- Cannot approve/decline specific patches/fixes like in SCCM/WSUS
- Cannot use SCCM in parallel
- Computers must be Windows Server 2012 or higher
- No roll-back of patches
- No inventory of patches/hotfixes/drivers to be deployed
The Update Management solution for OMS is great! It makes the entire process a lot easier and cleaner (IMO), especially since I am not a SCCM expert. You can setup collections just like we could in WSUS and SCCM. However there are some negative takeaways (see above). Of course like most OMS solutions, updates are pushed out regularly, so I am sure the Update Management solution will get some tweaks here and there as time goes on.
For more information on the OMS Update Management Solution, please visit the following: https://docs.microsoft.com/en-us/azure/operations-management-suite/oms-solution-update-management
Great write-up, it’s amazing how the topic discussed lines up with the conversation I have will customers on a day to day basis. Love the fact you included a little how-to as well.
LikeLike
I tried the same way as you explained before, but my update schedule is completed, but updates were not installed. After checking the completed status it is showing me the pending. What would be the reason?
LikeLike
there could be many reasons but some of the first thoughts are… was there enough time given for the patches to be applied? how long was the window you created for the patch deployment?
LikeLike
Hi Ravi, Thanks for the reply, it was a configuration issue. I reconfigured it now, but the job shows it suspended. This time I gave 90min. Is this could be the reason for the job suspension,
LikeLike
It is very possible. Have you increase the job time? Perhaps there are a high number of patches to be deployed to the machine(s).
LikeLike
Yes, I increased the time to 4hours, but the job ran for 40min and not installed all the apps. So again I kept one more schedule, which installed the remaining updates. Did you face this issue anytime? Or do you foresee any bug/issue over the update management.
LikeLike
I did not face similar issues, however I was testing against new-builds, both 2012 and 2016 versions. Is there anything within the logs that helps? If you can send me a copy of the log(s) [ravi@scomandothergeekystuff.com] I can take a look. Of course, raising with Microsoft would help too.
LikeLike
Hi Ravi,
Thanks for the post.. I am looking for the CAU (Cluster Aware Updating) options in OMS like it is in SCCM. For eg: I have created a schedule and added the servers in group but I don’t want OMS to update all the servers in group at a same time, instead it should update one server reboot it and then it update next server reboot it and then so. So is this option available in OMS?
LikeLike
Hi Mohammed, That is one drawback from OMS patching solution, we do not have the opportunity to select and choose which patches will be applied. It has been quite some weeks since I tested with OMS update management last, but at the time, this feature was not included. When it comes to having the options to specify which patches to which machines, SCCM is still the better choice in that regards.
LikeLike
We struggle with Patch Saturation reporting… is there a way using the portal to run a query against an individual KB? I need to know whow many server need this KB, and how many successfully(or Unsuccessfully) patched. (I can figure out the success % if I know How many servers to start require said KB, and how many successfully loaded it… 100 servers need it, 97 successfully loaded it (I can do the math to determin failures 100-97 = 3) so 97 of 100 where successffuly for a patch saturation % of 97%. Can you help? Is it possible to query by KB this way?
LikeLike