6.3 Azure Update Manager: Assessment, Maintenance Configurations & Dynamic Scoping

Azure Update Manager: Assessment, Maintenance Configurations & Dynamic Scoping

Maintaining operating system patch compliance and automating routine operational tasks across distributed hybrid environments are fundamental responsibilities of enterprise Windows Server administrators. Historically, managing updates for multi-cloud and on-premises servers required complex on-premises System Center infrastructure, standalone Windows Server Update Services (WSUS) servers, or legacy Azure Automation Update Management linked to Log Analytics workspaces.

Azure Update Manager (AUM) modernizes this operational paradigm by delivering a cloud-native, software-as-a-service (SaaS) update management solution built directly into the Azure Resource Manager control plane. This section covers AUM itself — its architecture, assessment and patch deployment mechanics, maintenance configuration parameters and reboot policies, and dynamic scoping. Azure Automation, runbook authoring, and Hybrid Runbook Workers (HRW) are covered in section 6.4.

---

1. Azure Update Manager (AUM) Architecture

Azure Update Manager provides a single pane of glass for assessing, scheduling, and deploying operating system updates across Windows Server and Linux machines running in Azure, on-premises datacenters, and other cloud platforms.

+-----------------------------------------------------------------------------------------+
|                         AZURE UPDATE MANAGER ARCHITECTURE                               |
|                                                                                         |
|   [AZURE RESOURCE MANAGER CONTROL PLANE]                                                |
|   +---------------------------------------------------------------------------------+   |
|   | Azure Update Manager (AUM SaaS Engine)                                          |   |
|   | - Periodic Assessment (24-Hour Automated Scans)                                 |   |
|   | - Scheduled Maintenance Configurations (Patch Tuesday / Recurrence Schedules)   |   |
|   | - Dynamic Scoping (Azure Resource Graph Queries & Tag Selectors)                |   |
|   +---------------------------------------------------------------------------------+   |
|               |                                                       |                 |
|               | (Native Fabric APIs)                                  | (Arc Agent 443) |
|               v                                                       v                 |
|   [AZURE IAAS VIRTUAL MACHINES]                         [AZURE ARC-ENABLED SERVERS]     |
|   +---------------------------+                         +---------------------------+   |
|   | Zero Additional Agents    |                         | Connected Machine Agent   |   |
|   | Native VM API Integration |                         | - Communicates with WUA   |   |
|   | - Calls Windows Update    |                         | - Reports to AUM via ARM  |   |
|   |   Agent (WUA) / WSUS      |                         | - ZERO Log Analytics/MMA  |   |
|   +---------------------------+                         +---------------------------+   |
+-----------------------------------------------------------------------------------------+

Modern AUM vs Legacy Automation Update Management

Understanding the architectural evolution is critical for enterprise deployment planning and the AZ-800 exam:

---

2. Assessment & Patch Deployment Mechanics

Azure Update Manager separates update management into distinct assessment and deployment workflows:

+-----------------------------------------------------------------------------------------+
|                         AUM WORKFLOW & PATCHING LIFECYCLE                               |
|                                                                                         |
|   [1. PERIODIC ASSESSMENT]                                                              |
|   - Background scan runs every 24 hours via Windows Update Agent (WUA)                  |
|   - Queries local WSUS server or Windows Update catalog                                 |
|   - Uploads pending patch compliance status to Azure (Installs ZERO updates)            |
|                                 |                                                       |
|                                 v                                                       |
|   [2. DEPLOYMENT TRIGGER MODES]                                                         |
|   +------------------------------------+--------------------------------------------+   |
|   | Mode A: One-Time Updates (Ad-Hoc)  | Mode B: Scheduled Maintenance Configuration|   |
|   | - Immediate patch installation     | - Automated recurring patch windows        |   |
|   | - Interactive troubleshooting      | - Patch Tuesday offsets & dynamic tags     |   |
|   +------------------------------------+--------------------------------------------+   |
|                                 |                                                       |
|                                 v                                                       |
|   [3. MAINTENANCE WINDOW EXECUTION]                                                     |
|   - Evaluates Classification filters (Critical, Security, Rollups)                      |
|   - Evaluates KB Inclusions and Exclusions                                              |
|   - Applies per-item minimums; window is not a kill switch                              |
|   - Applies Reboot Policy (RebootIfRequired, NeverReboot, AlwaysReboot)                 |
+-----------------------------------------------------------------------------------------+

Core Capabilities:

1. Periodic Assessment: An automated background scan running every 24 hours. The local Windows Update Agent (WUA) assesses available patches against the server's configured update source (internal WSUS or public Microsoft Update) and posts the summary to Azure. It does not download or install updates.
2. Check for Updates (On-Demand): An interactive scan initiated via the Azure Portal, CLI, or REST API to retrieve real-time patch status immediately.
3. One-Time Updates: Immediate, ad-hoc installation of selected updates or classifications with custom reboot parameters, ideal for zero-day vulnerability remediation.
4. Scheduled Maintenance Configurations: Centralized, declarative schedules that execute unattended patching runs during defined maintenance windows.

---

3. Maintenance Configuration Parameters & Reboot Policies

When authoring a Maintenance Configuration in Azure Update Manager, administrators define the boundaries and rules of the patching window.

+-----------------------------------------------------------------------------------------+
|                    MAINTENANCE CONFIGURATION PARAMETER TAXONOMY                         |
|                                                                                         |
|   PARAMETER              SUPPORTED OPTIONS & EXAM CONSTRAINTS                           |
|   --------------------+-----------------------------------------------------------------|
|   Recurrence Schedule | - Daily, Weekly, or Monthly                                     |
|                       | - Relative Monthly: e.g., 'Second Tuesday of Month' + X days    |
|   Maintenance Window  | - Duration: 1 hour 30 min to 3 hours 55 min (portal maximum)    |
|                       | - Updates already in progress are NOT terminated at the limit   |
|   Reboot Settings     | - RebootIfRequired (Reboots ONLY if patch flags pending reboot) |
|                       | - NeverReboot (Suppresses all reboots; leaves pending state)    |
|                       | - AlwaysReboot (Forces server restart at end of window)         |
|   Classifications     | - Critical Updates, Security Updates, Update Rollups,           |
|   (Windows Server)    |   Feature Packs, Service Packs, Definition Updates, Updates     |
|   Explicit KB Filter  | - Include specific KB IDs (e.g., KB5034441)                     |
|                       | - Exclude problematic KB IDs (e.g., KB5034123)                  |
|   Pre/Post Events     | - Azure Event Grid integration (Trigger Functions/Webhooks)     |
+-----------------------------------------------------------------------------------------+

The Maintenance Window Timeline (Windows)

The maintenance window is a starting boundary, not a kill switch, and Microsoft's documented behaviour is the opposite of what most administrators assume:

• Azure Update Manager does not stop starting new updates merely because the window is nearly over, and it does not terminate an in-progress update when the window is exceeded. Only updates it has not yet begun are abandoned.
• Instead, each update type has a minimum remaining time requirement, evaluated before that item starts. For a window running 15:00–18:00:

• After issuing a reboot, Update Manager waits up to 15 minutes for an Azure VM and 25 minutes for an Arc-enabled server before marking the reboot failed.
• On Linux, a reboot requires 15 minutes remaining, and that rule applies to Azure VMs only — not to Arc-enabled servers.

[!WARNING] A window that is regularly exceeded is almost always a service pack that installs slowly. The remedy is a longer window or a split schedule, not a shorter update list — and machines in the same availability set are patched within update domain boundaries, so overlapping schedules across one availability set can leave machines unpatched.

Configuring Reboot Policies

Selecting the correct reboot policy prevents unintended service interruptions:

• RebootIfRequired (Default): The maintenance engine queries the Windows reboot pending flag (e.g., HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending). If any installed update demands a restart, the server is rebooted before the maintenance window closes. If no updates require a reboot, the server remains online.
• NeverReboot: The maintenance engine completely suppresses the reboot command. Installed updates requiring a reboot remain in a pending state until an administrator manually restarts the host during a separate outage window.
• AlwaysReboot: Forces an operating system reboot at the conclusion of the maintenance window regardless of whether the installed patches required one, ensuring a clean memory state.

---

4. Dynamic Scoping with Azure Resource Graph & Tags

In large enterprises, statically assigning individual servers to maintenance configurations creates severe administrative overhead and risk of unpatched machines. Azure Update Manager resolves this through Dynamic Scoping.

+-----------------------------------------------------------------------------------------+
|                    DYNAMIC SCOPING ARCHITECTURE IN UPDATE MANAGER                       |
|                                                                                         |
|   [MAINTENANCE CONFIGURATION: 'Prod-Wave-1-PatchTuesday']                               |
|   - Recurrence: 2nd Tuesday of Month + 2 Days, 02:00 UTC                                |
|   - Duration: 2 Hours | Reboot: RebootIfRequired                                        |
|   - Dynamic Scope Filter:                                                               |
|     * Subscriptions: 'sub-enterprise-prod'                                              |
|     * Resource Types: 'Microsoft.HybridCompute/machines'                                |
|     * Tag Query: 'Environment == Production' AND 'PatchGroup == Wave1'                  |
|                                 |                                                       |
|                                 v (Azure Resource Graph Evaluation)                     |
|   +---------------------------------------------------------------------------------+   |
|   | MATCHED TARGET MACHINES:                                                        |   |
|   | - Arc-Server-01 (Tags: Environment=Production, PatchGroup=Wave1)  --> ENROLLED  |   |
|   | - Arc-Server-02 (Tags: Environment=Production, PatchGroup=Wave1)  --> ENROLLED  |   |
|   |                                                                                 |   |
|   | UNMATCHED MACHINES:                                                             |   |
|   | - Arc-Server-03 (Tags: Environment=Production, PatchGroup=Wave2)  --> IGNORED   |   |
|   | - Arc-Server-04 (Tags: Environment=Dev,        PatchGroup=Wave1)  --> IGNORED   |   |
|   +---------------------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------------------+

How Dynamic Scoping Operates:

• When authoring a dynamic scope, administrators construct criteria based on Subscriptions, Resource Groups, Locations, Resource Types (Microsoft.HybridCompute/machines or Microsoft.Compute/virtualMachines), and Resource Tags.
• During every scheduled execution run, Azure Update Manager queries Azure Resource Graph in real time to resolve the current list of matching machines.
• Zero-Touch Onboarding: When a new on-premises Windows Server is onboarded via Azure Arc and tagged with PatchGroup = Wave1, it is automatically targeted during the next maintenance run without modifying the Maintenance Configuration.