Azure Update Manager replacing Azure automation account for update management.
Introduction:
In this post we take a look at how to manage OS updates for your servers with Azure Update Manager. We will talk about its strengths, costs, weaknesses and limitations, but also some thoughts about how to manage patching in general.
Strengths:
So lets start off by looking at the positive things with Azure update manager and its actually in my opinion most things about it :).
Dashboard
Opening up the "Azure Update Manager" in the Azure portal, we are meet with a clean and easy to understand dashboard! It has clickable statuses so we can quickly filter on machines with different patch status. We can use filtering as normal if we want to filter on specific subscription/resource groups and so on, clean and simple.
The overview dashboard showing us 1 machine in pending reboot status.
Clicking the pending reboots will show us what machines currently falls under this category.
Clicking on update status will take us even further and show all updates not installed for a specific machine.
If we select the "Machines" view in the left pane we get a overview of all our virtual machines, update status, OS, Patch config, assessment, Patch schedule (maintenance configuration) and VM status. Easy overview for what VMs are onboarded and what schedule they are using.
All machines status.
As mention before normal Azure filters are available on all these view, as can be seen in the pictures. We can use filtering as tags, location, os, status and more to manage the list as we like.
Management and Configuration
When it comes to management there is a limitation that depending on your environment, is very annoying or does not affect you at all, i will talk about this in the weakness and limitation section.
For now lets just look at the general management and configurations.
To manage machines with Azure Update Manager two settings needs to be set on the machines, "periodic assessment" and "Patch orchestration". These settings decide how the machines patching is handled and that it regular checks for new updates (this is done via Microsoft updates). These settings can be configured automatically with policy or scripting.
There are a few built-in policy for managing the configuration of Azure Update Manager, including configure a schedule automatically.
Policies for Azure Update Manager, you can also use your custom built.
To configure a schedule for your patches (usually you have more than one) we create something called a "Maintenance Configuration". The schedule itself is pretty straight forward, you select a date and time when you would like the maintenance window to start. You have the option to make it recurring (as you should) and select specific days, offset days and Maintenance length to make it fit your organization. For example we can configure it to happen every 1:st Wednesday after every 2:nd Tuesday, so we align with Microsoft release windows.
To assign machines to a specific maintenance configuration we can use different methods. We can assign with policy, PowerShell, add the resources manually or the use of dynamic scopes. Dynamic scopes is in my opinion the best option and ill show you why in the "Configure Updates" section.
Dynamic scopes add some useful customization, such as adding machines based on subscription, tags, region and resource group.
Dynamic scope with filter on Tag "Patch" with value "True"
On-premise, AWS, GC
A quick mention, if you have servers in other cloud solutions or on-premise, Azure Update Manager can handle them with the help of Azure-Arc. We will not look at Azure-Arc specifically in this post since its a tool to extend several Azure capabilities to other cloud provides and on-premise. Just know that they will be handled the same way when it comes to Azure Update Manager.
Weakness and limitations
Lets start by talking about that annoying limitation if you are using enterprise scale (or group with subscriptions generally). While Dynamic scopes are great they have a limitation in that they will not automatically onboard new subscriptions, meaning if you have 3-5 update schedules (maintenance configurations) you need to create a new dynamic scope for these for every new subscription that should be using it. If your using the enterprise scale and have a large environment this can result in some annoying administration. This is however not an issue at all if your environment only contains 2-5 static subscriptions that you have all your resources in.
Another limitation is that you can not customize what product you would like to update or not, you can only select updates based on category in the form of, security updates, critical updates, feature packs and so on. If you do want to exclude something you can do so but only specific KB/patches, as shown below.
Cost
The Azure Update Manager is free for Azure VM:s, but if you want to manage servers outside of Azure it can cost you a lot depending on the amount of severs.
Currently the cost for Azure Update Manager is 5$ a month per server outside of Azure, which is a strange price model since its scale terrible. Have an environment with 5-10 servers no problem 25-50 dollars for a patch solution is very cheep. Have a environment with 1000 servers, well paying 5000$ a month for patching is very expensive.
On the plus side if you are using Microsoft Defender for Cloud with service plan 2 the Azure Update Manager is included free of charge.
My advice
Now we are going over in how i personally think you should manage your updates and configuration in Azure Update Manager (should you chose to use this solution).
Lets start to talk about the limitation when it comes to selecting patches, the question here is, should you really exclude any security updates for Microsoft products? In my opinion, no you should not so i personally don't se this as a problem. If you currently are excluding patches, it might be a good thing to look at why and a way to change this inside the organization.
The administrative hassle of several subscription pretty much is what it is and i hope they add a feature for dynamically add new subscriptions in the scope.
Lets talk about Dynamic scopes first since its already on our minds, this is a great tool in combination with Azure policies to ensure you have configured patches for all your system and can force each VM deployment to be added to a schedule. In the Configuration Updates section below, i will give you an example how i would configure Azure Update Manager with Dynamic scopes to ensure our servers are enrolled to a "maintenance configuration".
Configure Updates
Configure the built-in policy to set up assessment automatically for your VM:s, then set up a policy that forces new VM:s to have the tag named "Patch" (can be anything) with a preselected value for each of your dynamic scope as selectable (named after patch window). With this you can ensure that each VM is deployed with a selected patch window, since you are forcing the value to be selected on deploy. On the dynamic scope the filter is set to correspond with the values in the policy. This helps you ensure that your VM:s are enrolled in updates.
Example of tag
Scheduling
So how should I plan my scheduling? Well here is a list of some things to consider
Apply patches to test system first (verify these)
Apply security patches as soon as possible
Ensure to split system in different windows when it come to failover/redundant system (to avoid downtime), includes Domain controllers.
Ensure you follow up on each patch window.
So how soon is as soon as possible? If you ask me all systems should be patched the same week as patches have been released, starting with "test systems" and/or "less critical" on Wednesday, follow up with "non-critical" systems on the day after and the rest after that. There is a lot of opinions on this and several organizations wait a long time with patching their critical system in case the patches cause any issues. While i definitely will acknowledge that point of view i would like to ask you two question (in case you have this scenario).
If this system is that critical why would you allow it to be filled with security vulnerabilities half of its life time?
If the system is so critical why does it not have a staging environment with the exact same configuration as the prod that is the first out to get patches and verification?
Ultimately its for you to decide how to manage your updates of course, but i hope i at least gave you something to think about ;)
Summary
Overall Azure Update Manager is a good product with potential to be even better if they sort out some administrative "annoyances" and maybe add a different pricing plan for larger organizations that still have a lot of servers.