Keeping on top of updates is critical to the security of an environment. Microsoft’s Azure Update Management Center has been in preview for a little while now. It provides a powerful way to centrally manage Azure virtual machine updates at scale. However, some of the options may require a little explanation to get the most out of it.
Firstly, some caveats. Update Management Center (I’ll refer to it as UMC from here for convenience) is in public preview, so does not benefit from the full levels of Microsoft support. However, as with other public previews, it is pretty robust and a failure to apply updates is not going to cause an immediate service impact.
Next, check the supported OS list to ensure that your workloads can be patched by UMC. This includes marketplace OS images, and generalized customized images. Specialized VMs and VMs created by Azure Migrate, Backup, or Site Recovery, can use one-time updates and check for updates only, or continue to use Automation update management till support is available in UMC. Note the ability to apply patches includes support for on-premises servers managed by Azure Arc, which is great news.
Finally, and this might be obvious, but you can only patch machines that are powered on. If you routinely power off machines to save some compute costs then you will need to ensure that these are powered up again during patching operations.
The simplest way to apply patches is to manually trigger evaluation and then application of updates. Until an initial evaluation is completed all machines will show as having “no update data”.
Clicking the “Check for updates” button at the top of the Overview page will allow you to select machines and submit the job., After a few minutes the numbers in the table should change. You can review the machine status under the Machines option in the Manage section on the left.
Pending updates can be applied using the “One Time Update” button at the top of the Overview page, and the same button appears on other pages such as Machines. Update application is very flexible and can be applied to individual machines or in batches. All outstanding updates for these machines can be applied in one go, or you can select specific updates, or select updates by classification. You also have the option to control how reboots are handled after patches are installed, either force a reboot, never reboot, or reboot if required.
Update progress can be viewed in the History section. One-time updates will be recorded as “manual udpate”.
Manually installing updates is great, but depending on the situation you might want update evaluations to occur regularly, and even apply updates to machines on a schedule. The settings for these are less obvious, so let’s run through them.
Firstly let’s review the update settings for our VMs. Just as with the other settings we’ve discussed, update settings can be controlled per machine or in batches. Once the targets have been selected you are able to control several options here.
Periodic assessment is really useful. As the tooltip states, this evaluates the machine every 24 hours for outstanding updates. There is an associated (also in preview) Azure Policy which will enable this for VMs in scope of the policy automatically.
Hotpatching applies security patches to supported VMs without requiring a reboot. Sounds great? There’s a catch (or course). It is only supported on very limited images. Specifically
- Windows Server 2022 Datacenter: Azure Edition Core
- Windows Server 2022 Datacenter: Azure Edition with Desktop Experience
So if you can use it, great. For many it’s not going to be an option, although I expect support will grow over time.
You may have noticed a yellow warning message in some of the screenshots here related to changes to “patch orchestration”. Well this is where you find it. The implications of each option presented aren’t immediately clear. Azure modifies two parameters depending on the setting chosen. The first, “Patch Mode” defines whether the guest OS or Azure is responsible for managing update schedules, and can be “AutomaticByPlatform” (i.e. Azure-orchestrated), “AutomaticByOS” (Windows only), “Manual” (Windows only), or “ImageDefault” (Linux only). The second, “BypassPlatformSafetyChecksOnUserSchedule” determines whether user-scheduled patching or “AutoPatch” applies, and can be either “True” or “False”. Finally the behaviour varies depending on whether a schedule, or Maintenance Configuration, is applied. The interactions between these three settings are laid out in the Microsoft documentation Configure schedule patching on Azure VMs to ensure business continuity in update management center (preview). | Microsoft Learn
Customer Managed Schedules (Preview)
What does it do? Another setting that’s in Preview! The documentation states that it sets “Patch Mode” to “AutomaticByPlatform”, and “BypassPlatformSafetyChecksOnUserSchedule” to “True”. Which isn’t really very helpful out of context.
What it actually does is allows you to set a user-managed update schedule and override any other automated checks. In short, if you assign a Maintenance Configuration to the device(s) updates will happen based on that configuration, otherwise no patching will occur.
When do I use this? When you have a specific patching or maintenance window where you want to ensure that patches are applied only during this time.
Azure Managed – Safe Deployment
What does it do? “Orchestrates patches across availability sets” says the description. You may have come across this mode previously, as it can be referred to as “AutoPatch”. Patch mode here is “AutomaticByPlatform” and “BypassPlatformSafetyChecksOnUserSchedule” is set to “False”. A Maintenance Configuration should not be applied.
When do I use this? When you want updates to apply to machines as they become available without having to specify a maintenance schedule. Note that if you do assign a schedule patching will fail.
Windows Automatic Updates
What does it do? Patch mode here is “AutomaticByOS” (i.e. not Azure-orchestrated) and “BypassPlatformSafetyChecksOnUserSchedule” is not applicable. A Maintenance Configuration should not be applied.
When do I use this? “Best for scenarios where interrupting workloads isn’t an issue” – i.e. the same behaviour as any Windows OS with fully automatic updates controlled by the OS. Updates apply as they become available and reboots happen as required.
What does it do? “Turns of Windows automatic updates”. Neither Azure nor the Windows OS will apply updates.
When do I use this? When you want full manual control of Windows updates
What does it do? “Use the default patching configuration in the image used to create the VM”. Applicable only to Linux machines, this turns off Azure orchestrated updates but does not attempt to configure Windows OS-driven updates. Basically it’s allowing the Linux OS to manage itself.
When do I use this? When you want to let the Linux OS manage it’s own patches rather than Azure.
Putting it all together
So, assuming you would like automatic evaluation and deployment of patching to keep your environment up-to-date, here’s a list of actions. Obviously if you just want evaluation and want to perform manual updates or use another management platform to manage updates then you will need to vary this process appropriately.
- Enable Perodic Assessment by deploying the Azure Policy to a scope containing the VMs you wish to keep up-to-date.
- Run a one-time assessment by clicking “Check for Updates” and select the VMs in-scope.
- Configure Update Settings for the VMs and set them to “Customer Managed Schedules” which will set the patch mode and allow us to specify a patching schedule.
- Create a Maintenance Configuration by clicking Schedule Updates, and set the patching schedule and patch classifications. Scope the configuration either manually or using a dynamic scope which is evaluated at runtime. Note that if you use a dynamic scope the VMs must all be configured for Customer Managed Schedules or updates will fail.
- Sit back and watch!