Azure Update Manager patch wave planning template

Good For

• Monthly patch cycle planning for Azure VMs and Arc-enabled servers
• CAB or change-ticket preparation
• Patch wave sequencing across application tiers
• Documenting exclusions, reboot limits, and validation ownership
• Creating CSV-backed wave plans for reporting or import into tracking sheets

How to Use It

1. Define the patch month, platform owner, application owner, and environment scope before assigning maintenance waves.
2. Map systems into pilot, lower-risk, business-hours-sensitive, and production waves according to uptime and reboot tolerance.
3. Record maintenance configuration, reboot policy, expected validation owner, and concurrency guardrails for each wave.
4. Document stop/go criteria and exception handling so one bad wave does not silently roll into the next one.
5. Use the finished plan as the source for maintenance schedule configuration, CAB evidence, and post-wave validation notes.

Execution Modes

• local

Inputs and Outputs

Inputs

• Change metadata - fields: Change ID, Patch cycle/month, Planned start date, Change manager, Primary operator
• Environment scope - fields: Subscription(s), Resource group(s), Region(s), Azure VM and/or Arc-enabled server scope, Environment tag values (Prod/Test/Dev)
• Wave plan CSV columns - fields: Wave, Hostname, ResourceId, SubscriptionId, ResourceGroup, Platform, OS, Environment, Service/Application, BusinessCriticality, PatchGroupTag, MaintenanceConfig, WindowStart, TimeZone, MaxDurationMinutes, RebootPolicy, ConcurrencyLimit, DependencyNotes, ValidationOwner, AppOwner, SoakHours, StopGoCriteria, ExclusionReason, ApprovalStatus, OperatorNotes
• Decision records - fields: Exclusions and approvals, Manual reboot exceptions, Service blackout periods, Escalation contacts, Rollback or containment notes

Outputs

• verbose-console
• operator-notes

Command Starter

Safe to run: read-only

az account show --output table
az resource list --tag PatchGroup --query "[].{name:name,resourceGroup:resourceGroup,type:type,location:location,tags:tags}" --output table
az connectedmachine list --query "[].{name:name,resourceGroup:resourceGroup,status:status,location:location,tags:tags}" --output table
az vm list --show-details --query "[].{name:name,resourceGroup:resourceGroup,powerState:powerState,location:location,tags:tags}" --output table
az maintenance configuration list --query "[].{name:name,resourceGroup:resourceGroup,location:location,maintenanceScope:maintenanceScope}" --output table
az graph query -q "Resources | where type =~ 'microsoft.compute/virtualmachines' or type =~ 'microsoft.hybridcompute/machines' | project name, type, resourceGroup, subscriptionId, location, tags" --output csv

Validation

• Every in-scope server is mapped to exactly one wave or documented as excluded with approver and reason.
• Each wave has a maintenance window, time zone, reboot policy, and named technical/app owner.
• Dependencies and sequencing for clustered or multi-tier applications are recorded and reviewed by service owners.
• Stop-go criteria, soak period, and escalation path are explicit enough to decide whether the next wave proceeds.

Reporting

• Per-wave server counts by environment, service, and reboot policy.
• Excluded server list with reason, approver, and planned review date.
• Wave progression summary showing pilot completion, soak expiry, and go/no-go decision.
• Post-change evidence index: compliance export, failed machine list, application validation notes, and incident references.

Safety Notes

• This template is a planning aid; validate actual Azure Update Manager schedules and maintenance configurations before execution.
• Do not mix tightly coupled application tiers into the same wave unless dependency and rollback handling are explicitly documented.
• Use local business time and UTC in notes where teams span regions to avoid maintenance window ambiguity.
• Treat exclusions as temporary decisions; capture expiry or next review date so systems do not silently drift from patch coverage.