What's New with Azure Update Management
As with all things Azure, change is constant. Even how we update our workloads. Yes, it’s true, Azure Update Management has a new feature which allows you to target a dynamic group of VMs for updates very similar to what you could do with Windows Server Update Services (WSUS) on premises. In this article, we’ll take a peek at how this is done, but first, we’ll get up to speed on Azure Update Management.
What is it?
Unless you’ve been living on an island and running Windows 95 for the past 20 years, you are all too familiar with Windows Update. Love it or hate it, it’s what we know and how we keep our systems “functioning” and secure. This hasn’t changed for our cloud folks either. Our virtual machines (VM) in the cloud need the same maintenance. They aren’t just magically updated by the cloud fairy. Yes, updates can and will break things, which is why, the onus is on us as the custodians of our VMs to keep them up to date, as our requirements allow. This is where Azure Update Management comes in. Think of it as your own Windows Server Update Service in the cloud.
What about my Linux workloads? Azure has you covered. Azure Update Management can provide updates for your Linux workloads as well. Most Azure supported Linux distributions are supported. Just think of it, a large percentage of the workloads in Azure are running a Linux distribution. Not a bad idea to include them in the Update family. Unfortunately, Update management does not support Windows desktop clients (Windows 7,10). I would suspect they may add this down the line.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
But wait, there’s more! You can use Update Management for your non-Azure systems as well. The service is “free” while only paying for the log data stored in Azure Log Analytics. You can find more information about pricing here.
Getting Started with Azure Update Management
There are a few things that need to take place before you can get started with Azure Update Management. Both tasks can be done from a VM properties page. We need to have an automation account and a Log Analytics workspace. The Log Analytics workspace will log data from your VMs, we need an automation account to enable the Log Analytics capabilities. We start this by selecting Update management from the VM properties blade. You will have the option to enable Update Management for your VM or for your entire subscription.
Once that is complete, you can return to the Update management page and select Manage Multiple Machines. At this point, we can add our Azure VMs or our non-Azure Machines (see below)
Recall, we had the ability to enable Update management for the entire subscription or just that VM. I selected a single VM, giving me the opportunity to select a second VM (see below). You may choose to enable for your entire subscription, providing an auto-enroll for all VMs to register with Update management. Be patient, the VMs which are enrolled do not display immediately. As with most things in Azure, it will take some time for it to install the necessary Microsoft Monitoring Agent and report.
Dynamic Group Targeting
Now that we have our VMs reporting to Update management, we can now dynamically target groups for our updates. This is the new feature added to Azure Update Management. This feature gives us the ability to create a query to populate the dynamic group. The attributes we can query against include:
- Resource Groups
What I’ve done is created my filter based on my Subscription (required) and my Resource Group. We can click Preview (see below) to see the results of our query returns. Queries will with more than 500 machines is not supported resulting in a failed update deployment.
If we are good with the query results, we can add it to our group selection and create our new update deployment. We simply need to schedule the date and time (required) which includes a run once or recurring option. Optionally, we can select the types of updates we want (security, critical, etc), how long we wish to have the updates complete (maintenance window) as well as reboot options.
The ability to target specific workloads with updates is a great feature. I see this being extremely impactful if we need to deploy security updates and having the ability to target not only by Resource Groups but also Locations. Enterprise environments with workloads in different geo-locations will have different maintenance windows due to various time zones and having the ability to dynamically account for those different locations with a few simple steps can solve a lot of scheduling problems in the event of a critical security update. WSUS had some of these capabilities but did not account for our cloud friends. Updates are a critcal part of maintaining a “stable” and secure environment and providing more control over updates in Azure is always a good thing!