By the end of this you have periodic assessment turned on by policy, a maintenance configuration that schedules patching against a tag rather than a list, the one patch-mode difference between Azure virtual machines and Arc servers understood so you do not chase a setting that does not apply, hotpatching enrolled where the operating system supports it, the content source made authoritative, and the meter confirmed, including the easy-to-miss fact that assessment itself now counts against it. The portal walk comes first, then the same thing as a script. This assumes the doctrine article’s decisions are made, in particular who owns the maintenance configuration, because that owner now owns your reboot windows.
Before Step 1: Arc-connected machines (Azure Update Manager works natively through the Connected Machine agent, with no Log Analytics workspace and no legacy Monitoring Agent), rights to assign Azure Policy and to create maintenance configurations, and a patch-ring tag scheme you will scope schedules against.
Step 1: Turn on periodic assessment, by policy
Before you schedule anything, get visibility. In Azure Policy, assign the built-in definition “Configure periodic checking for missing system updates on Azure Arc-enabled servers” at a subscription or management-group scope. It sets each machine’s assessment mode to AutomaticByPlatform, and every in-scope machine then reports its pending updates every twenty-four hours. Do it by policy rather than machine by machine so a newly onboarded server inherits it automatically. Assessment installs nothing; it builds the posture you schedule against.
| Setting | Value | Why |
|---|---|---|
| Policy | Configure periodic checking for missing system updates on Azure Arc-enabled servers | Sets assessment mode to AutomaticByPlatform on every in-scope machine |
| Scope | Subscription or management group | New machines inherit it; you govern a scope, not a list |
| Effect on the machine | Assessment only, every 24 hours | Read-only posture, no reboot risk at this stage |
The same as a script, assigning that built-in policy at the subscription:
az policy assignment create \
--name "AUM-PeriodicAssessment" \
--policy "<periodic-assessment-definition-id>" \
--scope "/subscriptions/<sub-id>"One point to state plainly, because it is easy to assume otherwise: assessment is not free. Any managed operation, including periodic and on-demand assessment, makes the machine managed for that day and counts toward the meter in Step 6. Turn assessment on deliberately across the fleet you intend to patch, not reflexively across everything.
Step 2: Build a maintenance configuration with dynamic scope
A maintenance configuration is where the schedule, the window, the classifications, and the reboot behavior live. In Azure Update Manager, create one with its Maintenance scope set to Guest, which is the scope that patches inside Windows and Linux rather than the Azure platform underneath. Set the recurrence and the window, select the classifications on the Updates tab, and choose the reboot setting on purpose. Then add a dynamic scope that filters by your patch-ring tag, so membership is a query and a newly onboarded server tagged for that ring joins it without anyone editing a list.
| Setting | Value | Why |
|---|---|---|
| Maintenance scope | Guest (Azure VM, Arc-enabled VMs and servers) | Patches inside the guest; the API value is InGuestPatch |
| Schedule and window | A recurring window, maximum three hours fifty-five minutes | The window is the change window; owning this object is owning the reboot |
| Classifications | Security and Critical first, broaden per ring | Stage risk the way you always staged rings, expressed as scope |
| Reboot setting | Chosen explicitly (reboot if required, never, or always) | The difference between a patched server and a patched-and-restarted one is a decision, not an accident |
| Dynamic scope | Filter by a patch-ring tag | Membership follows the tag; onboarding a tagged server enrolls it automatically |
The same as a script. This creates the configuration itself; the classifications, reboot setting, and dynamic scope are properties you set on it in the portal or through an ARM or Bicep template:
az maintenance configuration create \
--resource-group "rg-arc-mgmt" \
--resource-name "mc-patch-ring1" \
--maintenance-scope InGuestPatch \
--location "eastus" \
--recur-every "1Week Saturday" \
--duration "03:00" \
--start-date-time "2026-08-01 02:00" \
--time-zone "UTC" \
--reboot-setting "IfRequired"Failure mode: leaving the reboot setting at its default turns a routine patch job into an unplanned restart of production, which is the one outcome the maintenance configuration exists to make deliberate.
Step 3: Know the one Arc patch-mode difference
This is the step that trips people who came from Azure virtual machines. On an Azure VM you must first switch patch orchestration to Customer Managed Schedules, or scheduled patching silently does nothing. On an Arc-enabled server that switch is not a prerequisite: associating the machine, or its dynamic scope, with the maintenance configuration is sufficient. So do not go hunting for a patch-orchestration mode to flip on your Arc servers, because the requirement that exists on Azure VMs does not apply to them, and looking for it wastes time and invites you to change a setting that was never the problem.
Step 4: Enroll hotpatching where it applies
On Windows Server 2025, enroll eligible machines in hotpatching so most months install without a reboot. As of May 19, 2026 this is free on Arc-connected 2025 machines, with no per-core meter and no separate hotpatch line item, which reverses the paid subscription Microsoft had earlier planned for non-Azure hosts. Confirm the prerequisites first, because a machine that fails one silently falls back to the reboot cadence rather than raising an error.
| Prerequisite | Requirement |
|---|---|
| Operating system | Windows Server 2025, Standard or Datacenter |
| Security | Virtualization-based security enabled |
| Management | Arc-connected and managed through Azure Update Manager, enrolled via a scheduled (Customer Managed) path |
| Cost | No additional charge as of May 19, 2026; the hotpatch meter was removed |
Step 5: Decide the content source
Azure Update Manager honors the machine’s configured update source and cannot override WSUS approvals. If you are keeping WSUS as the approved-content source during the transition, point the Windows Update client at it through Group Policy and approve the updates in WSUS, then let Update Manager drive the timing against what WSUS approves. An update that WSUS has not approved is not installed, and the way that shows up depends on its state. An update left Not Approved can still be assessed as applicable yet fail at deployment time, which is why Microsoft advises approving the updates you intend to deploy to prevent Update Manager deployment failures. A Declined update is not offered to the machine at all and simply never appears as applicable. That distinction is the difference between a noisy failure you will investigate and a silent absence you will not, so validate expected KBs against both the Update Manager assessment and the configured update source rather than trusting either alone. If you are going direct to Microsoft Update instead, confirm the endpoints are reachable through the connectivity model you chose at onboarding. Either source is valid; what matters is knowing which one is authoritative for approvals.
Step 6: Confirm the meter and its waivers
Update Manager bills about five dollars per server per month, charged at roughly sixteen cents per server per day, on any day the machine is both Connected and managed. Managed means patched, assessed, or associated with a schedule, and that now explicitly includes assessment, which older guidance treated as free. Check your machines against the waivers before you widen, because the difference between a free and a billed fleet is entirely a licensing-posture question.
| Situation | Update Manager charge |
|---|---|
| Plain Arc machine, no qualifying licensing | About sixteen cents per server per day on any managed day, roughly five dollars per month |
| Windows Server with Software Assurance or subscription licenses, attested | Waived under Windows Server Management enabled by Azure Arc |
| Defender for Servers Plan 2 on the subscription | Included at no additional cost |
| Machine enrolled in Extended Security Updates through Arc | Included for the enrolled machine |
A worked example
Take a sixty-server fleet you have tagged PatchRing=Ring1 and PatchRing=Ring2. You assign periodic assessment by policy at the subscription, then create a maintenance configuration named mc-patch-ring1 with Guest scope, a Saturday window opening at 02:00 for three hours, Security and Critical classifications, reboot if required, and a dynamic scope that filters on PatchRing=Ring1. A week later Ring2 gets its own configuration on a different night. A dozen of these servers are Windows Server 2025 with virtualization-based security enabled, so you hotpatch-enroll them and their monthly quality updates stop forcing restarts. The whole estate is attested under Windows Server Management enabled by Azure Arc, so the meter reads zero. When a new server is onboarded and tagged PatchRing=Ring1, it joins that schedule at the next window with no list to edit, which is the entire point of scoping by query.
Naming convention
Name maintenance configurations for the ring they serve, for example mc-patch-ring1 and mc-patch-ring2, so a glance at the configuration list reads as a patch calendar. Drive membership entirely through a single PatchRing tag rather than per-machine associations, so onboarding and ring promotion are tag changes, not schedule edits. Keeping the tag and the configuration names aligned is what lets the fleet’s patch posture be read from the tags alone.
The end-to-end test
Prove the loop on one server before you trust the schedule. Run an on-demand assessment on a test machine and confirm it reports pending updates, then let a scheduled maintenance run install them in its window, or trigger a one-time update, and confirm the machine reports compliant afterward. If a machine assesses, patches on its schedule, and reports clean without anyone touching it directly, the patching plane is working as designed.
Rolling it back
Patching is the plane people are most nervous about piloting, so know the exit before you take the entrance. Unwind it from the machine outward, and note that nothing here uninstalls a patch: rolling back the schedule stops future deployments, it does not reverse an update that already installed.
- Take the machine out of the schedule first. If it arrived through the dynamic scope, remove the
PatchRingtag, which is the cleanest possible undo because the query stops matching it and nothing else changes. If it was directly assigned, delete its maintenance configuration assignment, either from the configuration’s Machines pane in the portal or by deleting theMicrosoft.Maintenance/configurationAssignmentsobject on the machine resource. - Confirm the machine’s next scheduled run is gone before you go further, because a configuration you delete while an assignment still points at it is the one scenario that leaves confusing state behind.
- Disable periodic assessment. If you enabled it by policy, remove or set the policy assignment to disabled rather than editing machines one at a time, and remember that leaving the policy in place will simply re-enable it on the next evaluation.
- Delete the maintenance configuration itself once no assignments remain:
az maintenance configuration delete --resource-group "rg-arc-servers" --resource-name "mc-patch-ring1". Deleting the configuration removes maintenance control from any resources still associated with it, so do step 1 first rather than relying on this to tidy up. - If you enrolled machines in hotpatching, unenroll them and expect the next cumulative update to require a restart again. Set patch expectations with whoever owns the maintenance window before that first reboot surprises them.
- Check the meter after the rollback, not before. Assessment is a billable managed operation, so a fleet you thought you had disengaged but which is still assessing daily is still charging daily.
Before you widen the scope
- Periodic assessment enabled by policy so new machines inherit it, with the understanding that assessment is a billable managed operation.
- Maintenance configuration created with Guest scope, and the window, classifications, and reboot setting all chosen deliberately.
- Dynamic scope filtering by a patch-ring tag, so onboarding a tagged server enrolls it automatically.
- The Arc patch-mode difference understood: no Customer Managed Schedules prerequisite on Arc, association is enough.
- Hotpatching enrolled on eligible Windows Server 2025 machines, prerequisites confirmed, at no charge.
- Content source known and authoritative, whether WSUS or Microsoft Update, with its endpoints reachable, and the updates you intend to deploy actually approved in WSUS. Expected KBs validated against both the assessment and the update source, because Not Approved and Declined fail differently.
- Meter and waivers checked against the real machines, and the maintenance configuration owned by the intended team.
- End-to-end test passed: a test machine assessed, patched on schedule, and reported compliant on its own.
Settings and patching cover the two things the domain did most visibly for a server. The next article widens the lens to the rest of the operations surface: the extensions that add capability, the monitoring that tells you what is happening, and the remote access that lets you reach a server without a jump box.
Azure Arc
‹ Previous: [ARC 4] Update Manager: Patching After WSUS
Next: [ARC 5] The Operations Surface: Extensions, Monitoring, and Remote Access ›
