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
