You dont have javascript enabled! Please enable it!

Azure Update Manager 2023 – Comprehensive Guide

24 Min. Read

Updated – 28/11/2023 – Azure Update Manager now supports specialized images including VMs created by Azure Migrate, Azure Backup, and Azure Site Recovery. This means that you can enable periodic assessments to fetch the latest updates, and schedule updates on these VMs.

Updated – 21/11/2023 – The “Updates” blade is active in Azure Update Manager. This new blade provides a view from the pending updates instead of the machine’s lens.

Updated – 20/11/2023 – Update management for Azure Stack HCI clusters is integrated with Azure Update Manager, providing a unified tool for all your machines across the cloud and the edge. Only systems that have the Azure Stack HCI, version 23H2 OS can be managed using Azure Update Manager.

Updated – 06/11/2023 – Azure Update Manager staged patching with Azure Automation.

Updated – 17/10/2023 – Azure Update Manager will have Prescript and Postscript using Azure Automation runbook available by the end of 2023.

Updated – 12/10/2023 – Azure Update Manager now supports scheduled patching and periodic assessment for specialized VMs, including those created by Azure Migrate, Azure Backup, and Azure Site Recovery, in preview.

Updated – 09/10/2023 – Azure Update Manager is currently in preview for SQL Server running on Azure VMs.

Updated – 30/09/2023 – Microsoft announced that Azure Update Manager now offers support for generalized Azure Compute Gallery (SIG) custom images.

Updated – 21/09/2023 – Microsoft announced that Azure Update Manager, previously known as Update Management Center, is now generally available (GA).

Updated – 12/09/2023 – Azure Update Management Center v2 (preview) was renamed to Azure Update Manager (preview) before it reached general availability (GA).

Virtual machines (VMs) whether they are deployed in the cloud, on-premises, or physical are compute instances that can run on demand. You can use them just like servers, deploying operating systems and applications, or containerized workloads. Operating system updates for machines are one of the core elements of a zero-day vulnerability and the overall security strategy.

In this article, we will guide you step-by-step through the process of using the new Azure Update Manager solution to centrally manage and patch your virtual machines in and out of Azure.

Introduction

As you probably know, when we start provisioning resources in any public cloud provider or on-premises, we need to always think about the types of resources we have and the shared responsibility model.

For infrastructure as service (IaaS) virtual machines, we are responsible for things like the OS, their runtime, the middleware, application, and data. When we think about the OS, this includes securing and hardening the OS, but also obviously patching it. And that’s kind of a huge part of it.

You probably already have a patching solution on-premises like System Center Configuration Manager (SCCM), you could bring that to the cloud if that’s working for you today, you could just use your existing investments if you want. You could also use the cloud-native technology in Azure called “Update Management” to patch Azure and non-Azure VMs. You can read more about this solution here.

In the existing Azure Automation Update Management solution, onboarding was a multistep procedure, access control with multiple actors was not possible and limitations on scale existed.

Microsoft took the update management for servers and virtual machines to a whole new level by announcing a new patch management solution called (Azure Update Manager) and that’s what we want to focus on in this article.

The Azure Update Manager known as the v2 version of automation Update management and the future of Update management in Azure, has been completely redesigned and doesn’t depend anymore on Azure Automation and Log Analytics Workspace, as required by the Azure Automation Update Management feature.

Azure Update Manager | Getting started
Azure Update Manager | Getting started

Azure Update Manager Overview

You can use Azure Update Manager, previously known as Update Management Center to centrally manage operating system updates, update configuration settings, and manage the process of installing required updates for your Windows and Linux virtual machines (VMs) in Azure, physical or VMs in on-premises environments, and in other cloud environments as well.

You can quickly assess the status of available updates and manage the process of installing required updates for your machines by reporting to the update management center.

Azure Update Manager offers the same functionality as the original version available with Azure Automation today without the dependency on Azure Automation and Azure Monitor Logs, but it is designed to:

  • Take advantage of newer technology in Azure.
  • Deliver a native update capability.
  • No onboarding steps are required.
  • Granular role-based access control.

The following diagram illustrates how the new Azure Update Manager assesses and applies updates to all Azure machines and non-Azure machines (Arc-enabled servers) for both Windows and Linux operating systems.

Azure Update Manager architecture
Azure Update Manager architecture

Prerequisites

To follow this article, you need to have the following:

1) Azure subscription – If you don’t have an Azure subscription, you can create a free one here.

2) Your account must be a member of the Azure Owner or Contributor role in the subscription.

3) One or more Azure virtual machines, physical or virtual machines managed by Arc-enabled servers. Please check the following table lists for the supported operating systems for update assessments and patching. Microsoft is working to support all Azure-endorsed Linux distros and OSes including custom images (Shared Image Gallery images). Stay Tuned!

4) Azure Windows/Linux VM agent – The update management center supports Azure VMs created using Azure Marketplace images, where the virtual machine agent is already included in the Azure Marketplace image. If you have created Azure VMs using custom VM images and not an image from the Azure Marketplace, then you need to manually install and enable the Azure virtual machine agent as described here: Azure Windows VM agent and Linux VM agent.

5) Since Azure Update Manager was in (preview), you can enable the periodic assessment feature and scheduled patching (orchestration) for your subscription using the Azure portal, PowerShell, CLI, or the REST API as described by Microsoft. This step is NOT required anymore.

  • Sign in to the Azure portal, search for Preview features, and select it from the available options.
  • Choose your desired Azure subscription where you want to register the Update Management Center.
  • In the Preview features page, search for InGuestAutoAssessmentVMPreview.
  • Select Virtual Machine Guest Automatic Patch Assessment Preview from the list.
  • In the Virtual Machine Guest Automatic Patch Assessment Preview pane, select Register to register the Compute provider with your subscription.
Register Virtual Machine Guest Automatic Patch Assessment
Register Virtual Machine Guest Automatic Patch Assessment

6) Azure Update Manager is available in all Azure public regions where virtual machines are available. However, for Azure Arc-enabled servers, the following regions are only supported. See the current list of all the supported regions for Azure Arc-enabled servers (more regions will be added soon).

  • Australia East
  • Central US
  • East US
  • East US 2
  • North Central US
  • South Central US
  • West Central US
  • West US
  • West US 2
  • West US 3
  • North Europe
  • West Europe
  • France Central
  • East Asia
  • South East Asia
  • South Africa North
  • UK South
  • Switzerland North
  • Japan East
  • Korea Central
  • UK South
  • UK West

Please note that enabling periodic assessments for Arc-enabled machines that Defender for Servers Plan 2 is not enabled on their related Subscription or Connector, is subject to Azure Update Manager pricing (check this section for more details). Arc-enabled machines that Defender for Servers Plan 2 is enabled on their related Subscription or Connector, or any Azure VM, are eligible for periodic assessments with no additional cost.

Once you verified that you have all the prerequisites in place, take the following steps.

Enable Azure Update Manager

Once you deploy your Azure VMs or Non-Azure VMs using Azure Arc, you can find the Update Management solution either in the “Updates” option of your VM blade as shown in the following figure. You can switch to the new Azure Update Manager experience previously known as Update Management Center.

Update Management Center | VM Blade
Update Management Center | VM Blade

Or you can manage VM updates at scale with the new Update management center experience by using the search bar in the Azure portal as shown in the figure below.

Azure Update Manager dashboard
Azure Update Manager dashboard

The Overview page for Azure Update Manager enables you to view the patching compliance and status for all your Azure and Non-Azure machines as shown in the figure below.

Update Management Center | Overview
Update Management Center | Overview

You can use the filters on top to drill down to a specific set of machines, view a breakdown of machines and their status based on multiple categories, and identify the non-compliant machines to quickly take corrective action. The “No updates data” status in yellow tells you the count of machines that have not been assessed in the past 7 days or do not have the periodic assessment setup yet.

How to enable periodic assessment in Azure Update Manager?

Enable Periodic Assessment

You can enable periodic assessment using Azure Policy at scale or you could use the Update settings to add selected machines to regularly check for updates as shown in the figure below.

Enable periodic assessment
Enable periodic assessment

Configure periodic checking for missing system updates

If you opt for the Azure policy option which gets integrated with Microsoft Defender for Cloud, then you can select one of the built-in policy definitions below:

  • Configure periodic checking for missing system updates on Azure virtual machines.
  • Schedule recurring updates using Azure Update Manager.
  • Machines should be configured to periodically check for missing system updates.
  • Configure periodic checking for missing system updates on Azure Arc-enabled servers.
Update Management Center | Built-in Policies
Update Management Center | Built-in Policies

For assigning the policy to all Azure machines, select Configure periodic checking for missing system updates on Azure virtual machines and click on the Policy.

For Arc-enabled servers, select Configure periodic checking for missing system updates on Azure Arc-enabled servers.

Based on your deployment of Azure and non-Azure machines, you need to assign the policy on the desired scope (Management group, Subscription, or optionally Resource Group).

Configure periodic checking for missing system updates
Configure periodic checking for missing system updates

Next, on the Parameters tab, uncheck Only Show parameters that need input or review so that you can see the values of parameters as shown in the figure below. In Assessment mode, select AutomaticByPlatform, select Operating system type, and click on Next.

Note: You need to assign a separate policy for both Windows and Linux OS types.

Configure Assessment mode and OS Type
Configure Assessment mode and OS Type

On the Remediation tab, check “Create a remediation task”, so that periodic assessment is enabled on your machines, and click on Next. Please note that by default, this assignment will only take effect on newly created virtual machines. Existing VMs can be updated via a remediation task after the policy is assigned.

Periodic Assessment | Create a remediation task
Periodic Assessment | Create a remediation task

On the Non-compliance message tab, provide the message that you would like to see in case of non-compliance. For example: “Your machine doesn’t have periodic assessment enabled.” Click on Review+Create.

On the Review+Create tab, click on Create. This will trigger Assignment and Remediation Task creation which can take a minute or so.

You can monitor the compliance of resources under Compliance and remediation status under Remediation from the Policy home page.

Microsoft Defender for Cloud will also show the recommendation: System updates should be installed on your machines (powered by Azure Update Manager) under Apply system updates security control.

System updates should be installed on your machines (powered by Azure Update Manager)
System updates should be installed on your machines (powered by Azure Update Manager)

Update Settings

If you opt for the Update settings option to add selected machines, then you need to select the update settings that you want to change for your machine and select Next.

Periodic assessment – enable periodic assessments to run every 24 hours. As noted in the prerequisites section, you must register for the periodic assessment in your Azure subscription to enable this feature.

Hot patching – for Azure VMs, you can enable hot patching on supported Windows Server Azure Edition Virtual Machines (VMs) that don’t require a reboot after installation.

Patch orchestration – provides the following options: Customer Managed Schedules, Azure Managed – Safe Deployment, Windows automatic updates, Manual updates, or Image Default (Only supported for Linux Virtual Machines). Patch orchestration of Azure virtual machines should be set to “Customer Managed Schedules” which enables schedule patching on your existing VMs. This step is very important! The new patch orchestration option enables the two VM properties: Patch mode = Azure-orchestrated and BypassPlatformSafetyChecksOnUserSchedule = TRUE on your behalf after providing your consent.

Please note that if the Patch orchestration is set to Azure Managed – Safe Deployment, then BypassPlatformSafetyChecksOnUserSchedule is set to FALSE, and there’s NO schedule associated, the VMs will be auto-patched.

Related: Automatic guest VM patching (autopatch) for Azure VMs.

There are cases where removing a schedule from a virtual machine (VM) can result in the VM being automatically patched and rebooted. To address this issue, Microsoft has implemented a new prerequisite called ByPassPlatformSafetyChecksOnUserSchedule. This prerequisite can be set to True to allow for patching based on schedule so that VMs with this property set to True will NOT be auto-patched when there is no maintenance configuration associated with them.

Currently, the patch orchestration setting is not applicable for Arc-enabled servers, but this does not block Arc-enabled servers from using scheduled patching capability (See schedule recurring updates). Unlike Azure machines, for Arc-enabled servers, patch mode set to “Customer Managed Schedules” is NOT a prerequisite for scheduled patching.

Change update settings
Change update settings

Please note that if you set the patch orchestration mode to Azure orchestrated, but don’t attach a maintenance configuration to an Azure machine, it is treated as an Automatic Guest patching enabled machine and the Azure platform will automatically install updates as per its schedule.

In the Machines tab, add and select the checkbox for your machine(s) and select Next to continue. Note that you can add up to 20 machines at once.

Update Management Center | Add machine
Update Management Center | Add machine

Once you enable periodic assessment, the automatic assessment will run every 24 hours and provide the latest OS update status for your machine(s).

The Machines page shows the list of all VMs under a given subscription. You can access the features of the Update management center from the menu on the top as shown in the figure below.

Update Management Center | Machines
Update Management Center | Machines

The, “Check for updates” allows you to assess updates on-demand while “One-time update” allows you to install patches on-demand. The “Scheduled updates” and “Updates Settings” options allow you to enable customized patching schedules. The “Browse maintenance configurations” lets you manage platform updates that don’t require a reboot using maintenance control. Maintenance control lets you decide when to apply updates to your machine(s).

The History page allows you to see the update process and the last run update (time frame: Last 24 hours up to 30 days).

The Azure Update Manager offers an easy-to-use single pane for all operating systems and application patching scenarios for a single VM or VMs at scale.

How to schedule recurring updates in Azure Update Manager?

Schedule Recurring Updates

Azure Update Manager allows you to establish recurring deployment schedules. You can choose to schedule updates on a daily, weekly, or hourly basis and select the specific machines that require updating, as well as the updates to be installed. This automated schedule ensures that updates are installed as per the predetermined schedule for individual virtual machines and at scale.

To schedule recurring updates at scale, follow these steps:

1) In Azure Update Manager, Overview, select your Subscription(s) and select Schedule updates.

2) In the Create new maintenance configuration page, you can create a schedule for multiple machines. Currently, VMs and maintenance configurations in the same subscription are supported.

3) In the Basics page, select Subscription, Resource Group, and enter all options under the Instance details.

  • Configuration name
  • Region
  • Maintenance scope
  • Reboot setting
Create a maintenance configuration
Create a maintenance configuration

4) Next, select Add a schedule, and in Add/Modify schedule, specify the schedule details such as:

  • Start on
  • Maintenance window (in hours). The upper maintenance window is 3 hours 55 minutes.
  • Repeats (hourly, daily, weekly, or monthly)
  • Add end date
  • Schedule Summary

For the Repeats-monthly, there are two options:

  • Repeat on a calendar date (optionally run on the last date of the month).
  • Repeat on the nth (first, second, etc.) x day (for example, Monday, Tuesday) of the month. You can also specify an offset from the day set. It could be +6/-6. For example, if you want to patch on the first Saturday after a patch on Tuesday, you would set the recurrence as the second Tuesday of the month with a +4 day offset. Optionally, you can also specify an end date when you want the schedule to expire.

Click Save and then click Next: Dynamic Scopes >

Add/Modify the schedule
Add/Modify the schedule

5) In the Dynamic Scopes tab, you can assign a dynamic scope to this maintenance configuration now or assign it after the maintenance configuration deploys. If you want to add a dynamic scope now, click “+ Add a dynamic scope“, then select the desired subscription(s) which is mandatory. Next to Filter by, choose Select, and in the Select filter by blade, specify the Resource groups, Resource types, Locations, OS types, and Tags, and then select OK. Please note that these filters are optional fields.

Azure Update Manager | Add a Dynamic scope
Azure Update Manager | Add a Dynamic scope

In the Preview of machines based on the above scope, you can view the list of machines for the selected criteria and then select Save.

In the Configure Azure VMs for schedule updates page, you need to select any one of the following two options to provide your consent:

  • Change the required options to ensure schedule supportability – This option confirms that you want to update the patch orchestration from the existing option (E.g. Automatic by OS) to Customer Managed Schedules: This updates the following two properties on your behalf:
    * Patch mode = AutomaticByPlatform
    * Set the BypassPlatformSafetyChecksOnUserSchedule = True
  • Continue with supported machines only – This option confirms that you want to proceed with only the machines that already have patch orchestration set to Customer Managed Schedules.
Configure Azure VMs for schedule updates
Configure Azure VMs for schedule updates

Select Save to go back to the Dynamic Scopes tab. In this tab, you can view, edit, and remove the Dynamic scope that you have created.

In this example, we won’t assign a dynamic scope to this maintenance configuration, we will use Azure Policy to schedule recurring updates at scale by using maintenance configuration ARM ID (more details in the next section). Click Next: Machines >

6) In the Resources page, add your resources (machines). In this example, we won’t assign resources to this maintenance configuration now, you can assign them after the maintenance configuration deploys. Please note that you’re limited to adding five resource assignments on the Resources page, but you can add as many as you like after deployment. Click Next: Updates >

7) In the Updates page, select the appropriate updates to include in the deployment such as update classification(s) or KB ID/ packages that must be installed when you trigger your schedule.

Add update classification(s) or KB ID/ packages
Add update classification(s) or KB ID/ packages

Similar to Windows Server Update Services (WSUS), you can specify or remove update classifications (or categories) based on your update deployment for Windows/Linux OS. If your deployment is meant to apply only to a select set of updates, it’s necessary to clear all the preselected update classifications when you configure the Inclusion/Exclusion updates as shown in the figure below. This action ensures only the updates you’ve specified to include in this deployment are installed on the target machine. Note: Azure Update Manager does NOT support driver updates.

Include/Exclude update classification in Azure Update Manager
Include/Exclude update classification in Azure Update Manager

8) Click Next: Tags >. In the Tags page, assign tags to maintenance configurations.

9) Last, in the Review + Create page, verify your update deployment options and select Create.

Once the maintenance configuration is created, you can browse and manage all your maintenance configurations from a single place. In the Azure portal, search for Maintenance configurations. It shows a list of all maintenance configurations along with the maintenance scope, resource group, location, and the subscription to which it belongs.

You can filter maintenance configurations using filters at the top. Maintenance configurations related to Guest OS updates are the ones that have Maintenance scope as Guest (Azure VM, Arc-enabled VMs/servers) as shown in the figure below.

Azure Update Manager | Maintenance Configurations
Azure Update Manager | Maintenance Configurations

You can create a new Guest OS update maintenance configuration or modify an existing configuration.

Onboarding to Schedule using Azure Policy

With Azure Update Manager, you can easily deploy updates to a specific group of Azure or non-Azure virtual machines using Azure Policy. By using policy-based grouping, you can avoid the need to manually adjust your deployment to update machines. You have the flexibility to define the scope of your deployment using management groups, subscriptions, resource groups, tags, or regions, and customize the built-in policies to meet your specific needs.

The policy also ensures that the patch orchestration property for Azure machines is set to Customer Managed Schedules as it is a prerequisite for scheduled patching.

Before we assign the policy to schedule recurring updates at scale, you need first to get the maintenance configuration ARM ID from the maintenance configurations page. Select the desired maintenance configuration schedule, then select Properties under Settings, and then copy the ARM ID as shown in the figure below.

Azure Update Manager | Maintenance Configuration ARM ID
Azure Update Manager | Maintenance Configuration ARM ID

1) Sign in to the Azure portal and select Policy. In Assignments, select the desired Scope and then click Assign policy.

2) Under Basics, on the Assign policy page:

  • In Scope, you can choose your desired Management Group, Subscription, or Resource group. Assignment on the Management Group level is fully supported, this is important for large environments with many subscriptions.
Assign Schedule recurring updates Policy on the Management Group scope
Assign Schedule recurring updates Policy on the Management Group scope
  • Next, select Policy Definition to view a list of policies.
  • In Available Definitions, select Built-in for Type and in search, enter – Schedule recurring updates using Azure Update Manager and click Add.
Schedule recurring updates using Azure Update Manager
Schedule recurring updates using Azure Update Manager

3) Next, ensure that Policy enforcement is set to Enabled and click Next twice.

4) In the Parameters tab, by default, only the Maintenance Configuration ARM ID is visible, it’s a mandatory parameter to be provided. Paste the ARM ID that you copied from the previous step.

Maintenance Configuration ARM ID
Maintenance Configuration ARM ID

Please note that if you do not specify any other parameters, all virtual machines in the management group, subscription, and resource group that you selected in Basics will be covered under the scope. However, if you want to scope further based on Resource groups, Machines location, OS, Tags, and Effect, deselect Only show parameters that need input or review to view all parameters. Once you are done with the parameters, click Next.

Optional parameters input
Optional parameters input

5) In the Remediation tab, under Managed Identity, select System assigned managed identity and then select a paired Azure region for the System assigned identity location. The Permissions is already set as ‘Contributor‘ according to the policy definition. It is advised that managed identity is to be created in a region that is different than your source region because in scenarios where a disaster strikes, your source region (E.g. Switzerland North), and even more Identity will go down. So, we would pick (Switzerland West) which is our pair target region for the managed identity location.

Create a Managed Identity
Create a Managed Identity

If you select Remediation (Create a Managed Identity), the policy would be effective on all the existing virtual machines in the scope, else it is assigned to any new machine that is added to the scope later on.

6) Last, in Review + Create, verify your selections, and select Create to identify the non-compliant resources to understand the compliance state of your environment.

IMPORTANT: As part of the remediation process, Azure Policy needs permissions on management groups, subscriptions, or resource group levels to be able to patch existing and new virtual machines for the schedule that you set in the maintenance configuration. The managed identity needs to be assigned the minimum role-based access control (RBAC) role(s) required to remediate resources.

In the case of Azure Update Manager to schedule recurring updates, we need the minimum Contributor RBAC role assigned. For this to work, you must ensure that the Managed Identity (Principal ID) that gets created as part of the assigned policy above, needs to be assigned the Contributor role on the desired scope (management groups, subscriptions, or resource groups).

Managed Identity | Contributor role Schedule recurring updates using Azure Update Manager
Managed Identity | Contributor role Schedule recurring updates using Azure Update Manager

If you don’t set the required RBAC role, the remediation task will fail with the following message:

Reason: Evaluation of the “DeployIfNotExists” policy was unsuccessful. The policy assignment resource identity does not have the necessary permissions to create the deployment.

Schedule recurring updates using Azure Update Manager Succeeded
Schedule recurring updates using Azure Update Manager Succeeded

There you have it. Happy Patching with Azure Update Manager!

Azure Update Manager Monitoring

By default, Azure Update Manager sends the results of all its operations into Azure Resource Graph as logs and stores them in the following 3 tables which are available for 30 days:

  • Patchassessmentresources: This table includes information related to machine patch assessment.
  • Patchinstallationresources: This table includes information related to installed updates.
  • Maintenanceresources: This table includes information related to maintenance configuration.
Azure Update Manager logs
Azure Update Manager logs

What you could do, is you can run the following KQL query in Azure Resource Graph Explorer to get the latest installed successful patches on your virtual machines filtered by Date, VM Name, Update Classification, Patch Name, and the Microsoft Knowledge Base number (KBID).

// Azure Update Manager Get Patch Installation Resources
patchinstallationresources
| extend Date = tostring(properties.lastModifiedDateTime)
| extend Status = tostring(properties.installationState)
| extend PatchName = tostring(properties.patchName)
| extend KBID = tostring(properties.kbId)
| extend ID = split(id,"/")
| extend VMName = ID[8]
| mv-expand Classification = properties.classifications
| where Status == "Installed"
| project Date, VMName, Classification, PatchName, KBID
Azure Update Manager Get Patch Installation Resources
Azure Update Manager Get Patch Installation Resources

Furthermore, Azure Update Manager includes a built-in report that you can access under the Monitoring blade as shown in the figure below. You can also create your custom report if you want.

Azure Update Manager workbook
Azure Update Manager workbook

The built-in Workbook for Azure Update Manager gives you insights about your overall machine status and configurations, status updates of machines, schedules and maintenance configurations, and patch run history across your subscriptions.

Azure Update Manager | Update reports
Azure Update Manager | Update reports

Staged Patching with Azure Update Manager

With a staged patching solution, you can test first the update on the Dev and Test environments, because configuring Maintenance Configurations for each update cycle could lead to untested patches being deployed in production environments, and untested patches could lead to production breaks.

At the time of this writing, Azure Update Manager does not include a built-in feature for staged patching, it is very difficult to control which specific patch versions are applied between environments.

The good news is, that we could leverage Azure Automation using a PowerShell script and Azure Resource Graph to perform a staged patching solution that involves deploying OS updates in a test environment first, then in pre-production and production environments. This ensures that only the specific updates initially deployed in the test environment are received by the pre-production and production environments. By adopting this approach, the risk of having an OS update break a production system is significantly reduced.

This staged patching approach can be implemented with the help of the (Create-StagedMaintenanceConfiguration.ps1 PowerShell script) published by Microsoft (more details below), which runs after Stage 0 (Phase 0) and automates Stages 1 and Stages 2. This script can be, for example, deployed as an Azure Automation Runbook scheduled to run after the Dev/Test recurrent update cycle as shown in the diagram below. It works for both Windows and Linux scenarios for Azure VMs and Azure Arc-enabled servers.

Staged Patching with Azure Update Manager
Staged Patching with Azure Update Manager

Staged Patching Prerequisites

To deploy a staged patching solution with Azure Update Manager, you should have the following:

1) The machines in the scope of the staged solution must be supported by Azure Update Manager prerequisites.

2) The machines in the scope of the staged solution must have the Customer Managed Schedules patch orchestration mode which is a prerequisite for scheduled patching.

3) You need to have at least one recurrent scheduled patching Maintenance Configuration created to cover the Dev/Test machines in scope. This maintenance configuration will serve as the reference for the following patching stages, it should be assigned to Non-Production machines and, ideally, recur every few weeks.

4) You need to have an Azure Automation Account (you can reuse one or create a new one) with an associated Managed Identity (this can be a system or user-assigned identity). You should also have the following modules installed and imported: “Az.Accounts“, “Az.Resources“, and “Az.ResourceGraph” as shown in the figure below. This staged patching solution is based on an Automation Account, but you can use other approaches, such as Azure Functions or Logic Apps.

Staged Patching with Azure Automation
Staged Patching with Azure Automation

5) The Automation Account Managed Identity must have the following minimum permissions (as a custom role) on the subscription or on the management group level where the reference (initial) maintenance configuration was created:

  • */read
  • Microsoft.Maintenance/maintenanceConfigurations/write
  • Microsoft.Maintenance/configurationAssignments/write
  • Microsoft.Resources/deployments/*

You could use the following PowerShell command to create a custom role with the above minimum required permissions. Please make sure to replace the {groupID1} variable below with the appropriate value of your Management Group ID:

$role = Get-AzRoleDefinition -Name "Automation Runbook Operator"

$role.Id = $null
$role.Name = "Staged Patching Automation Custom Role"
$role.Description = "Staged Patching for Azure Update Manager with Azure Automation."
$role.IsCustom = $True
$role.Actions.RemoveRange(0,$role.Actions.Count)
$role.Actions.Add("*/read")
$role.Actions.Add("Microsoft.Maintenance/maintenanceConfigurations/write")
$role.Actions.Add("Microsoft.Maintenance/configurationAssignments/write")
$role.Actions.Add("Microsoft.Resources/deployments/*")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/providers/Microsoft.Management/managementGroups/{groupID1}")

New-AzRoleDefinition -Role $role
Assign Custom Role for Azure Automation Account Managed Identity
Assign Custom Role for Azure Automation Account Managed Identity

6) You need to tag your Azure VMs and Azure Arc-enabled servers according to the staged patching strategy you need to define (example below). By tagging your servers according to their OS version and patching stage, it will be easier to dynamically define the scope of a specific patching stage. Use tags to group your servers according to their patching phase and OS version, your servers can be tagged as follows:

  • A “aum-stage” tag for each of the patching stages (e.g., aum-stage=dev, aum-stage=preprod, aum-stage=prod, aum-stage=prod-ha-instance1, aum-stage=prod-ha-instance2, etc.).
  • An “os-name” tag for each of the OS versions of your environment (e.g., os-name=windows2016, os-name=windows2019, os-name=ubuntu20, os-name=ubuntu22, etc.)

Deploy Staged Patching Solution

Once you have all the prerequisites in place, take the following steps to deploy the Staged Patching solution using Azure Update Manager:

First, you need to download the Create-StagedMaintenanceConfiguration.ps1 to your local machine and then import the Runbook into the Automation Account. The Runbook must be configured as PowerShell 5.1 and NOT PowerShell 7.2 (preview). Then make sure to Publish the runbook because draft runbooks cannot be scheduled.

Import Create-StagedMaintenanceConfiguration.ps1 Runbook
Import Create-StagedMaintenanceConfiguration.ps1 Runbook

Next, you need to create an Azure Automation schedule for each of the Phase 0 (Stage 0) Maintenance Configurations (one schedule per OS version). The schedule must have the same frequency as the Maintenance Configuration it refers to, with at least an +8-hour offset. For example, if the Dev/Test Maintenance Configuration is scheduled on Fridays, every 2 weeks at 8:00 p.m., then the respective Azure Automation schedule should be scheduled on Saturdays, every 2 weeks at least at 4:00 a.m.

Create Maintenance Configuration Schedule by OS Type
Create Maintenance Configuration Schedule by OS Type

Last, you need to link the Create-StagedMaintenanceConfiguration Runbook to each of the schedules you created in the previous step, and specify the two parameters (MaintenanceConfigurationId, NextStagePropertiesJson) according to the instructions below.

Link Maintenance Configuration Runbook Schedule
Link Maintenance Configuration Runbook Schedule

MaintenanceConfigurationId: The Azure Resource Manager ID of the Maintenance Configuration is to be used as a reference to create maintenance configurations for further stages. To obtain the Maintenance Configuration ID, go the the “Properties” blade of the Dev/Test Maintenance Configuration and copy it.

Staged Maintenance Configuration Parameters
Staged Maintenance Configuration Parameters

NextStagePropertiesJson: Is a JSON-formatted parameter that will define the scope of the next maintenance configurations for pre-production and production environments.

The example below implements a scenario in which the Pre-Production and Production stages are deployed respectively 7 days and 14 days after the reference maintenance configuration (Dev/Test) runs. The maintenance scope is targeted at three subscriptions (00000000-0000-0000-0000-000000000001, 00000000-0000-0000-0000-000000000002, and 00000000-0000-0000-0000-000000000003), for both Windows Azure VMs and Azure Arc-enabled servers “resourceTypes” and tagged with “aum-stage=preprod“, “aum-stage=prod“, and “os-name=windows2022“. The “filter” property follows the format defined for Maintenance Configuration Assignments ARM template (see the reference documentation).

[
    {
        "stageName": "windows2022-preprod-mc",
        "offsetDays": 7,
        "scope": [
            "/subscriptions/00000000-0000-0000-0000-000000000001",
            "/subscriptions/00000000-0000-0000-0000-000000000002",
            "/subscriptions/00000000-0000-0000-0000-000000000003"
        ],
        "filter": {
            "resourceTypes": [
                "microsoft.compute/virtualmachines",
                "microsoft.hybridcompute/machines"
            ],
            "resourceGroups": [
            ],
            "tagSettings": {
                "tags": {
                    "aum-stage": [
                        "preprod"
                    ],
                    "os-name": [
                        "windows2022"
                    ]
                },
                "filterOperator": "All"
            },
            "locations": [],
            "osTypes": [
                "Windows"
            ]
        }
    },
    {
        "stageName": "windows2022-prod-mc",
        "offsetDays": 14,
        "scope": [
            "/subscriptions/00000000-0000-0000-0000-000000000001",
            "/subscriptions/00000000-0000-0000-0000-000000000002",
            "/subscriptions/00000000-0000-0000-0000-000000000003"
        ],
        "filter": {
            "resourceTypes": [
                "microsoft.compute/virtualmachines",
                "microsoft.hybridcompute/machines"
            ],
            "resourceGroups": [
            ],
            "tagSettings": {
                "tags": {
                    "aum-stage": [
                        "prod"
                    ],
                    "os-name": [
                        "windows2022"
                    ]
                },
                "filterOperator": "All"
            },
            "locations": [],
            "osTypes": [
                "Windows"
            ]
        }
    }
]

Note: The Staged Patching solution with Azure Automation is credited to Microsoft Team contributors (Hélder Pinto, and Wiszanyel Cruz).

Azure Update Manager | Updates

The new blade in Azure Update Manager provides a view to customers to see pending updates instead of machine updates. For instance, using this view, you can see total pending updates and see which updates are applicable on which (Windows/Linux) machines and take action accordingly as shown in the figure below.

Azure Update Manager | Updates Blade
Azure Update Manager | Updates Blade

Using this blade solves a classic use case for IT admins: They want to apply a critical update “XYZ” on all machines to remediate a particular vulnerability. The new “Updates” blade enables customers to:

  • View which all machines have “XYZ” update pending.
  • Allow IT admin to apply “XYZ” update to all affected machines either on demand or scheduled for a later date.

Microsoft announced that Azure Update Manager (AUM) now supports specialized images including VMs created by Azure Migrate, Azure Backup, and Azure Site Recovery. This means that customers can enable periodic assessments to fetch the latest updates, and schedule updates on these VMs.

This release addresses one of the top customer requests – expanding AUM support to include VMs created by Azure Migrate, Backup, ASR, etc. With this release, the support base of Azure Update Manager has been expanded by an additional 12% of Azure VMs.

Check how to manage updates for customized images and operating systems support in AUM.

Azure Update Manager Benefits

The new update management center solution offers many new features and provides enhanced functionality over the original Azure Automation Update Management version and some of those benefits are listed below:

Central visibility for updates —

  • Oversee update compliance for the entire fleet of Windows and Linux machines including Azure machines and Azure Arc-enabled servers on a single dashboard.
  • You can view the compliance status for each machine, easily deploy updates and track results.

Native experience with zero onboarding —

  • Built as native functionality on Azure Compute and Azure Arc for Servers platform for ease of use.
  • No dependency on Log Analytics and Azure Automation.
  • Azure policy support.
  • Scale to the limits of ARM and resource RP.
  • Global availability in all Azure Compute and Azure Arc regions.

Works with Azure roles and identity —

  • Granular access control at per resource level instead of access control at Automation account and Log Analytics workspace level.
  • Update management center now as Azure Resource Manager-based operations. It allows RBAC and roles based on ARM in Azure.

Enhanced flexibility —

  • You can install updates right away or schedule them for a later date.
  • Check updates automatically or on demand.
  • Secure machines with new ways of patching such as Automatic VM guest patching in Azure, Hotpatch, or custom maintenance schedules.
  • Use periodic assessment and scheduled patching at scale with Azure Policy.
  • Sync patch cycles about Patch Tuesday—the unofficial term for Microsoft’s scheduled security fix release every second Tuesday of the month.

Azure Update Manager Pricing

As mentioned earlier, Azure Update Manager is the successor to Azure Automation (AA) Update Management solution. While the Azure Automation-based model works great, it’s time to get serious about the Microsoft Monitoring Agent (MMA) to Azure Monitor Agent (AMA) migration path and that includes moving from AA-based update management to the new Azure Update Manager.

The reason is that the AA-based update model requires the MMA, while the new Azure Update Manager solution does not require either the MMA or the AMA. But there is also a financial impact on customers.

Microsoft has published an extensive and good FAQ from the Azure Update Manager team which you can find at this URL (Azure Update Manager frequently asked questions).

Among the answers is this: “Azure Update Manager is free for machines hosted on Azure and Azure Stack HCI. For Arc-enabled servers (not the HCI scenario), it’s chargeable up to $5/server/month“. Since the old Azure Automation Update Management was free to all servers, including Azure Arc, this represents a significant cost increase for customers with large server populations outside of Azure.

There are a couple of important things that you should know about this cost increase for Arc-enabled servers:

1) If you have been using Automation Update Management for free on Arc machines, you can use Azure Update Manager for free for one year (ending on September 18, 2024) on all subscriptions that were using Automation Update Management on Arc-enabled machines for free. After this period, Arc machines will be charged.

2) If you have purchased Microsoft Defender for Servers Plan 2, then you won’t have to pay to remediate the recommendations (Periodic assessment should be enabled on your machines, and System updates should be installed on your machines using Azure Update Manager).

3) If the machine is enabled for delivery of Extended Security Updates (ESUs) enabled by Azure Arc, then the Arc-enabled Server isn’t charged for Azure Update Manager.

4) Azure Arc pricing depends on the usage. If your machines are connected to Arc and being assessed by Azure Update Manager for updates every day because periodic assessment is turned on, then a full $5 would be charged per month. But let’s say you keep the machines turned on (connected with Arc) for 15 days out of 30 days, then you would be paying for 15 days because Azure Update Manager service will be called for only those 15 days. This converts to $2.5.

To summarize, if you own an Azure Arc-enabled server and use Defender for Cloud workload protection, it is recommended that you also use Defender for Servers P2 (DfS). If you follow this best practice, migrating to the new model will not have any cost implications. However, if you are not a DfS customer and rely on the free Azure Automation-based update solution, you have one year to budget for additional expenses. You can either add Defender for Servers P2 protection or opt for another update management solution for your servers.

FAQs

Does Azure Update Manager support custom images?

Yes, Azure Update Manager offers support for generalized Azure Compute Gallery (SIG) custom images. Expanded support for specialized images including Azure Migrate, Azure Backup, and Azure Site Recovery (ASR) is in preview.

Does Azure Update Manager support updates on Azure Arc-enabled servers?

Yes, support for scheduled patching is available for Arc-enabled servers and Azure machines alike. The experience is the same. Please refer to the following section to learn how to configure scheduled patching for both Azure and Arc-enabled servers.

Currently, the Patch Orchestration setting is not applicable for Arc-enabled servers, but this does not block Arc-enabled servers from using scheduled patching capability. Unlike Azure machines, patch mode set to “Customer Managed Schedules” is not a prerequisite for scheduled patching for Arc-enabled servers.

Does Azure Update Manager support category updates?

Yes, like Windows Server Update Services (WSUS), with Azure Update Manager you can specify or remove update classifications (or categories) based on your update deployment for Windows/Linux OS.

Please be aware that the updates you have chosen will display a preview of the available OS updates that can be installed based on the most recent assessment information in Update Manager. However, if this information is outdated, the actual updates installed may differ. This is especially true if you have selected a particular update category, as the applicable OS updates may vary due to the availability of new packages or KB IDs in the category.

Note: Azure Update Manager does NOT support driver updates.

Does Azure Update Manager support policy assignments on the management group?

Yes, recurring updates can be scheduled,  missing updates can be checked, and configuring periodic checking for missing system updates can be enabled through Azure Policy as shown in the figure below.

Azure Update Manager Policies
Azure Update Manager Policies

Those policies can be assigned at the Management Group, Subscription, or Resource Group level. Management group assignments scope is useful in a large environment with many Azure subscriptions.

Can we schedule updates 7 days after an update is released?

The short answer is Yes and No depending on when the update is released. By default, the offset could be set between -1 to -6 days or between 0 to 6 days (Before, On, or After an update is released) because day 7 counts toward a new week.

For example, if you want to update your systems on the first Saturday after Patch Tuesday, you would set the recurrence schedule as the “Second Tuesday” of the Month with a +4 day Offset (4 days after an update is released), or -3 day Offset (3 days before the second Tuesday).

Now, if you want to schedule updates 7 days after an update is released, you can set the recurrence schedule (Repeat) on the “Third Tuesday” of the Month with a “0” day Offset. In this case, the initial update is released on the “Second Tuesday” and you patch on the “Third Tuesday”, 7 days after the update.

Summary

In this article, we showed you how to get started with Azure Update Manager (previously known as Update Management Center) to patch all your systems in Azure and non-Azure machines.

With Azure Update Manager, you can easily manage software updates for both Windows and Linux machines across Azure, on-premises, and multi-cloud environments. This SaaS solution is an evolution of the Azure Automation Update management solution, offering new features and functionality for assessing and deploying software updates on a single machine or multiple machines at scale.

The best part is that Azure Update Manager has been redesigned to offer new capabilities without relying on the Log Analytics agent or Azure Monitor agent. Instead, it uses the Microsoft Azure VM agent to manage update workflows on Azure VMs and the Azure Connected Machine agent to manage Arc-enabled servers. This makes it a more efficient and reliable solution for managing software updates.

This new service provides easy, out-of-the-box, and native Guest OS update control across your fleet of virtual machines (VMs) in Azure, physical machines or VMs in on-premises environments, and in other cloud environments for both: Windows and Linux operating systems. In addition to zero onboarding steps, and no dependency on Azure Automation and Log Analytics agents, you also get new capabilities such as flexible scheduling options and on-demand assessments that help you manage a patch workflow that is best suited for your needs.

> Learn more about the Azure Update Manager on the Microsoft official documentation.

__
Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect with 20+ years of IT experience. As a Swiss Certified ICT Security Expert, CCSP, CISM, MVP, and MCT, he excels in optimizing mission-critical enterprise systems. His extensive practical knowledge spans complex system design, network architecture, business continuity, and cloud security, establishing him as an authoritative and trustworthy expert in the field. Charbel frequently writes about Cloud, Cybersecurity, and IT Certifications.
Previous

Data Storage in Azure – The Ultimate Know it All Guide

What is a Disaster Recovery Plan? All You Require is This

Next

16 thoughts on “Azure Update Manager 2023 – Comprehensive Guide”

Leave a comment...

  1. Nice article. Still have some problems with the Policy’s. Although you set the OS type on Windows, both Windows and Linux machine checked by the policy. Probably due to the ‘allowedValues’ in the definition:

    “osType”: {
    “type”: “String”,
    “metadata”: {
    “displayName”: “OS type”,
    “description”: “OS type for the machines.”
    },
    “allowedValues”: [
    “Windows”,
    “Linux”
    ],
    “defaultValue”: “Windows”
    },

    Also the Linux VMs that have periodic assessment disabled, are also marked as ‘Compliant’. I’ll set the settings using update settings for the moment, and will check back when it’s no longer in Preview.

  2. Hello Joran, thanks for the comment and feedback!
    Please note that Azure Update Manager is now in GA and the Azure Policies are no longer in preview.
    Are you still experiencing the same behavior you mentioned above?
    The Policy: “Machines should be configured to periodically check for missing system updates” will Audit only both OS (Windows and Linux).
    There is a second Policy to: “Configure periodic checking for missing system updates” which will Modify and enable periodic assessment for Azure virtual machines or Azure Arc-enabled servers for the Operating system that you specify, the default OS Type is set to Windows. You can change the OS Type to Linux when you assign the Policy under the “Parameters” tab.
    Hope it helps!

  3. I have the same issue as Joran, deployed “Configure periodic checking for missing system updates on azure virtual machines” and in the parameters section I selected “Windows”, yet it shows incorrect results.

    For example, I scoped this on my management group where I have three subscriptions.
    In total there are 52 VMs and 44 of these are Windows, 8 Linux.

    Checking the compliance policy it states 96% (50 out of 52).

    If I create the same policy and select “Linux” in the parameters, it still results in 96% (50 out of 52).

    So scoping the policy on OSType doesn’t seem to make any difference.

  4. Hello Ndr, thanks for the comment!

    Could you please confirm that you assigned the “Managed Identity” of this policy (Configure periodic checking for missing system updates on azure virtual machines) the “Contributor” role on your management group scope?
    This is a “Modify” policy which will set the Assessment Mode for Windows and Linux to “AutomaticByPlatform” instead of “ImageDefault”.

    I would recommend creating two separate assignments (duplicate assignments) of the same policy to target “Windows” and “Linux” individually. The built-in policy is targeting “Windows” OS by default.
    You can check the Compliance reason (details) of the 2 remaining machines on why they are not compliant.

    Last, if you are still facing this issue, then you can run the following Azure CLI commands to update the patch settings for (Windows and Linux) manually to “AutomaticByPlatform”:

    #Update Windows OS Patch Settings:
    az vm update --resource-group "rg-name" --name "vm-name" \
    --set osProfile.windowsConfiguration.enableAutomaticUpdates=true \
    osProfile.windowsConfiguration.patchSettings.patchMode=AutomaticByPlatform
    
    #Update Linux OS Patch Settings:
    az vm update --resource-group "rg-name" --name "vm-name" \
    --set osProfile.linuxConfiguration.patchSettings.patchMode=AutomaticByPlatform \
    osProfile.linuxConfiguration.patchSettings.assessmentMode=AutomaticByPlatform

    Hope it helps!

  5. Hi!!

    I would like to ask you something about Azure Update Manager.

    Is it possible to schedule updates 7 days after an update is released?

    Best regards,

  6. Hello Miguel, thanks for the comment and the great question!
    The short answer is Yes and No depending on when the update is released.
    The offset could be set between -1 to -6 days or between 0 to 6 days (Before, On, or After an update is released) because day 7 counts toward a new week.
    For example, if you want to update your systems on the first Sunday after Patch Tuesday, you would set the recurrence schedule as the “Second Tuesday” of the Month with a +5 day Offset (5 days after an update is released).
    Now, if you want to schedule updates 7 days after an update is released, you can set the recurrence schedule (Repeat) on the “Third Tuesday” of the Month with a “0” day Offset. In this case, the initial update is released on the “Second Tuesday” and you patch on the “Third Tuesday”, 7 days after the update.
    Hope it helps!

  7. Hi Charbel.

    Thank you for your response. I have a second question about this.

    Can updates be scheduled based on the release date of an update? That is, we want to update machines when a critical or security update has been published for more than 7 days to make sure it is stable. Could it be done?

    Thank you!!

  8. Thanks for the article. Do you know how to create a notification/email that tells you that patches have been installed successfully or have failed?

  9. Hello George, thanks for the comment and feedback!
    As of today, alerting is not ready yet.
    Microsoft is working on alerting where you can enable alerts to address events as captured in updates data, but I don’t have ETA on when it will be available.
    Update: By default, Azure Update Manager sends the results of all its operations into Azure Resource Graph as logs under the following 3 tables which are available for 30 days:
    *Patchassessmentresources: Includes information related to machine patch assessment.
    *Patchinstallationresources: Includes information related to installed updates.
    *Maintenanceresources: Includes information related to maintenance configuration.
    What you could do, is you can query the “Patchinstallationresources” table in Azure Resource Graph Explorer and check which patches have been installed successfully on your VMs.
    Hope it helps!

  10. Hi! Great article.

    For us who cant run the latest and the greatest. And would like to have the opportunity to choose exactly what patch is installed. Is that possible in Azure Update Manager Center. Today we use “WSUS” and there is it possible to choose patches to be released/installed to our different server groups.

    /Thanks

  11. Hello Mange, thanks for the comment and feedback!
    Yes, you can choose the exact patch (KB ID) and the update classification that you want to install in Azure Update Manager Center.
    You can control that when you create/update a “Maintenance Configuration” resource, under the “Updates” section, you can select to “+ Include specific KB ID / package” or “- Exclude specific KB ID / package”.
    You can also remove/add update classification(s) by selecting “+ Include update classification”.
    You can also use the “Dynamic scopes” capability in the “Maintenance Configuration” so you can filter and assign the update to a subset of servers based on OS Types, Locations, Tags, etc.
    By tagging your servers according to their OS version, it will be easier to dynamically define the scope so you can patch and install the updates into different server groups.
    Is this what you are looking for?
    Hope it helps!

  12. Hello Miguel, to address this scenario, you must first know when the update will be released in the first place.
    You need the date as input, so you can schedule the update 7 days after the initial release.
    As I mentioned previously, Microsoft releases Windows update every “Second Tuesday” of the month, so you can schedule 7 days after the release.
    You can also define in the maintenance configuration that you want only “Critical” and “Security” updates.
    What I also recommend is to perform staged patching, you patch first Dev/Test machines, next you validate if it’s stable, and then patch Prod machines.
    Hope it helps!

  13. Hi Charbel,

    Thank you for the detailed explanation of how Azure Update Manager works. It’s a very informative document. We are currently working on automating our patch management using Azure Update Manager via APIs. Could you please provide more information about the APIs for Azure Update Manager?

  14. Good morning Charbel,

    Do you know if its possible to list with KQL resources attached to maintenance configurations?

    Thank You!

  15. Hello Miguel, thanks for the comment!
    You could try the following KQL in Azure Resource Graph to get the list of VMs attached to maintenance configurations:

    // Azure Update Manager get attached maintenance configurations by resource
    maintenanceresources
    | extend MaintenanceScope = tostring(properties.maintenanceScope)
    | extend maintenanceConfigurationId = tostring(properties.maintenanceConfigurationId)
    | extend maintenanceConfigurationId = split(maintenanceConfigurationId,"/")
    | extend MaintenanceConfigurationName = maintenanceConfigurationId[8]
    | extend resourceId = tostring(properties.resourceId)
    | extend resourceId = split(resourceId,"/")
    | extend VMName = resourceId[8]
    | project VMName, MaintenanceConfigurationName, MaintenanceScope

    Hope it helps!

Let me know what you think, or ask a question...

error: Alert: The content of this website is copyrighted from being plagiarized! You can copy from the 'Code Blocks' in 'Black' by selecting the Code. Thank You!