How does the update solution for OMS actually deploy patches?

For a little while now Microsoft has had an Update management solution which provides one stop visualization for Windows and Linux patch status. They recently added a very exciting feature of this solution which actually performs the patch management on your systems! For details on this solution including what it visualizes and how as well as how to use this to deploy patches see the article at: https://azure.microsoft.com/en-us/documentation/articles/oms-solution-update-management/

This blog post will deconstruct how OMS is actually performing the patch of these systems based upon information which is available in OMS and the attached Azure subscription.

At Ignite it was mentioned that you now must have an Azure subscription attached to your OMS workspace. That now makes a lot more sense as solutions such as the Update solution require an Azure subscription to function (this blog will explain why).

What does the update solution look like?

The top level view for the update management solution shows the high level status of patching for all Windows and Linux systems that OMS is getting data from.

Drilling in provides more details on the patch status:

The scheduling part of the Update solution is available on the right column:

How does the update solution deploy patches?

The update solution works exactly as it did prior to the addition of the ability to push patches – until you schedule the deployment of a patch in your environment. When you schedule a patch for deployment, the following steps occur (see the figure below):

The first step that occurs is to create an automation account in the subscription which is associated with the workspace.
In that workspace two runbooks are created:
1. Patch-MicrosoftOMSComputer
2. Patch-MicrosoftOMSComputers
Patch-MicrosoftOMSComputers configures EVERY computer in your OMS workspace as an Azure Hybrid Runbook Worker.
Patch-MicrosoftOMSComputer is run once for each computer that you target your Updates to.
When the patching is complete the systems report back their updated patch status after the Update solution re-gathers their update information.

Let’s dig into these in more detail:

Creates an automation account:

An automation account is created which will be used for patching from this point forward in this workspace.

Create the two runbooks:

Two runbooks are created which appear to configure the Azure Hybrid Runbook Worker and perform the patching. What is really interesting is that each of these are “hidden runbooks” so you cannot see their content or make any changes to them (@Microsoft – having this type of functionality would be extremely helpful for organizations who would like to write their own automations as a business).

You can’t even resume, stop, suspend or of course you cannot view the source.

Patch-MicrosoftOMSComputers:

The two runbooks run one after the other, starting with “Patch- MicrosoftOMSComputers”.

This runbook provides very little diagnostic information as shown below:

Based upon what I have seen in my environments it looks like this script is the one which configures all servers in OMS as Azure Hybrid Runbook Workers (@Microsoft – second hint, this either needs to be documented extremely well or should only target the systems which you are choosing to patch). You can determine which systems are Hybrid Worker Groups by opening the Automation Account and then opening the Hybrid Worker Groups.

Details on this show all of the systems which are now Hybrid Runbook Workers in this workspace.

Patch-MicrosoftOMSComputer:

The Patch-MicrosoftOMSComputer runbook runs next – once for each system which is scheduled to be patched. This runbook provides detailed logging showing its status while patching the system. A full set of the stream information from a single round of patching is shown below.

Runbook Jobs, Parameters and Modules:

The job information is available just like with any other jobs in in Azure Automation – so it’s easy to see what succeeds or fails.

Their status appears in real time on the jobs pane so you can tell when they are running or completed.

The input parameters are consistent between the two runbooks. The five parameters are:

WorkspaceID
Duration
ScheduleName
ComputerIDList
AdditionalOptions

Several Azure based modules are pre-loaded into the Azure Automation account as shown below.

Back to the Update solution:

After the patching is complete and the system has updated its patching the Update solution updates with the new patching information.

What do we see in OMS for logging?

The logging information for patching in OMS is very extensive. The example below shows how you can find updates based on their UpdateRunName, KBID, computer or title.

Additional details are available when you open up the table record as shown below.

What does the OS see?

From the Client/Server Operating System perspective patching occurs just like it does with any other tools (IE: items appear in the update history, the system reboots when required, etc).

Patch management status on the go!

Using OMS (even without patching via OMS) you can quickly see the state of your systems patching. The examples below show the patching status of systems from the Android version of the OMS mobile application.

Q&A:

Here’s a few items that I worked through while testing out this functionality:

Does the Update solution replace Configuration Manager? At this point in time the answer is no. Configuration Manager provides a much more robust method for deploying patches. It additionally contains functionality such as Operation System Deployment (OSD), hardware and software inventory and more. Each of these functions is not something which OMS performs.
Does this fit in with “Cattle vs. Pets”? If you are familiar with the Cattle vs. Pets analogy, the OMS patching appears to be focused on the large number of systems which do not require babysitting while patching (IE the Cattle).
Can I run the hidden runbook for patching? No
Can I run re-run previous runbook jobs? No
Can I add my own runbooks into this Automation Account? Yes
Can I use this Azure Automation account to run other automations? You can add and run your own runbooks in this Azure Automation account.