So, operation with on-premises Windows Servers is really not the world I prefer. Although most of us will still run such local workloads. Keeping them up to date can be challenging and involves manual effort. Luckily there is an Azure service to handle and automate this workflow.


Azure Update Management is a low-cost automation instance to schedule update deployments from the cloud only requiring an agent on-prem (one per Windows or Linux OS) and an Azure subscription. (This service is also natively integrated to Azure VMs, but will not be part of this documentation)

Concept & architecture



Based from the official documentation.

To begin the deployment, you need to create an Azure subscription. Then create a new Automation Account, which will also need a Resource group.


As soon as your resources are ready, you can navigate to Update management, that requests to enable Update Management and needs a Log Analytics Workspace. The data stored in those will also be the only costs you pay. Learn more about Log Analytics


After this step was successful, the page should be looking like this:


If you want to integrate future or current Azure VMs automatically, you can do this under Manage machines at the top right.


Monitoring Agent

Next we are going to include an on-premises resource/server and install the Microsoft Monitoring Agent. It is basically just a next, next, finish installation, the only thing to pay attention to, is where you enter a Workspace ID and Key, to choose a corresponding Log Analytics Workspace endpoint.



This entries and the Agent download can be found at Agents Management in your Log Analytics Workspace:



So, you may ask yourself, how you would automate an installation and integration to update deployment cycles. Thats an easy thing:

  • The installation can be done through a silent Powershell script, carrying the Workspace ID and Primary key. I can recommend the script of John Savill.

Computer groups

Servers can be included into update deployments via. on-premises Active Directory Groups - those are fetched from the Monitoring Agent and can be found in the Log Analytics Workspace under Computer Groups. To set it up, follow those instructions (based on the official documentation):

  1. Enable the checkbox at LAW under Computer groups at Active Directory

  2. Go to the log queries in LAW, and save a query as a function that returns your computers, based on the AD group

| where Group == "YOUR_ON-PREM_AD_GROUP"
| distinct Computer



  1. This saved function should now be visible in the saved Computer Groups tab


  1. Now as you want to add selected groups to update deployments (view the steps below) - here is the function we saved before (make sure to take a look at the preview to ensure the correct computers are added) and of course add your Server to the on-premises AD group


Update deployment

You can create multiple Update deployments, at the top under Schedule update deployment. There are a lot of configurations, enabling granular control of server-patching processes. I would recommend a tier hierarchy, to differentiate from internal/dev - non-business relevant up to business critical and production workloads.


These are the options available:


  • Groups to update are Active Directory/WSUS/SCCM groups, where the servers are member of (alternative: Azure VMs of specific subscriptions/resource groups and so on)
  • Machines to update is the option to include particular servers manually
  • Update classification
  • Include/exclude groups allows to do exclusion of special workloads
  • Schedule settings
  • Pre-scripts + Post-scripts does remediation tasks, with custom scripts
You’ve successfully subscribed to Oceanleaf
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Your link has expired
Success! Check your email for magic link to sign-in.