A maintenance configuration is a change window with a resource ID. That sounds like a change of format and it is not one. The moment the window becomes an Azure resource it acquires a region, a lifecycle, a role boundary and an owner, and the people who can create, edit and delete it are no longer the people who edit Group Policy. This article is about what that resource does, what it quietly refuses to do, and the two authority surfaces it creates: the one Microsoft named and the one almost nobody guards.
The window lives in somebody else’s service
Update Manager has no scheduler of its own. It borrows one. The object you create when you define a patch window is a maintenance configuration in the Microsoft.Maintenance provider, the same Maintenance Control surface Azure uses for platform maintenance on dedicated hosts and isolated virtual machines. One property decides which job the object is doing: the maintenance scope, whose value for guest operating system patching is InGuestPatch, appearing in the portal as the option labelled Guest and covering Azure virtual machines and Arc-enabled machines and servers. Pick a different scope and you have built a perfectly valid resource that will never install a single update.
Everything else follows from it being an ordinary Azure resource. It carries its own tags, which have nothing to do with the tags it filters on. It is subject to role assignments at every scope above it. And it can be written by a template, drifted by a template, and destroyed by deleting the resource group it was parked in, an accident a Group Policy object was structurally incapable of having.
The recurrence model is narrow: daily, weekly or monthly, where monthly means a calendar date or an ordinal weekday, with repeats at least six hours apart and anything hourly reachable only through the API. What catches people is how an ordinal weekday interacts with release day. Patch Tuesday floats between the eighth and the fourteenth, an ordinal weekday floats too, and the two do not float together, so rings defined as the second Thursday and the third Saturday land in the wrong order in some months and the cautious ring patches before the pilot ring did. Calendar dates have no such failure mode. Unglamorous, and it decides whether ring discipline survives contact with a calendar.
A ceiling, not a deadline
The window has a floor of one hour thirty and a ceiling of three hours fifty five, which is the product refusing to let you schedule an all night maintenance period. The bounds matter less than the semantics, and the semantics are not what the word window suggests. The window is permission to begin work, not a promise that the work will finish inside it.
Microsoft’s description of the overrun is precise. An installation already running is not forcibly stopped even if it exceeds the window, but Update Manager does not install the remaining updates once the window ends, and the run reports a maintenance window exceeded error. The window truncates the queue, not the operation. Underneath that the product does arithmetic before it starts anything. Windows reserves ten minutes of the window for a restart, a service pack needs twenty minutes remaining and other updates fifteen. Below twenty five minutes remaining the run does not scan, download or attempt an installation at all: it checks whether a reboot is needed, restarts if ten minutes remain, and otherwise skips that too.
Put that next to a fact from the fences: Update Manager cannot pre-download. Every byte of a cumulative update crosses the wire inside the window, and how long that takes is a property of your link rather than your schedule. A two hour window that has been fine for a year is one slow Saturday from being a window where nothing gets installed.
A window that is too short does not fail loudly. The run executes, the record is written, and the update you cared about was never attempted.
The reboot options are three. Reboot if required is the honest default. Always reboot is blunt and has legitimate uses on machines whose pending reboot state is chronically dirty. Never reboot is the one chosen for the wrong reason, and Microsoft documents the caveat itself: a reboot can occur even when you specify never reboot, because the registry keys governing automatic updates and restart behaviour can force one. A never reboot run against a machine with a restart already pending completes with warnings rather than succeeding, a status your reporting has to be taught to read. Never reboot is a preference expressed to an orchestrator, not a lock on the machine.
Membership is a query, not a list
A maintenance configuration can be pointed at machines two ways: attach them individually, producing a static list, or give the schedule a dynamic scope, which is a set of filters over subscription, resource group, location, resource type, operating system type and tags. The sentence that makes the filters interesting is Microsoft’s own. The criteria are evaluated at the scheduled run time to produce a final list of machines. The machines you previewed while authoring the scope are not the machines that will be patched. They are a sample of what the query returned at that instant.
That is the property that makes rings scale. In a static model, adding a server to the cautious ring is an edit to a shared object other machines depend on, performed by whoever holds rights on it. In a dynamic model the server declares its own membership and the schedule finds it, and Microsoft states the corollary flatly: removing the tag on the machine automatically drops the association. There is no orphaned entry to find in eighteen months.
Three constraints are worth carrying. A dynamic scope exists only inside a schedule, and it is anchored at either a subscription or a resource group when you create it, and that anchor cannot be changed afterwards. Each scope tops out at a thousand resource associations, fifty tag filters and fifty resource group filters. And static and dynamic assignment coexist by design, which sounds convenient and is a trap: a machine individually attached to one schedule and caught by another schedule’s query is associated with both, and both will run. Two windows, two installations, one server that needed neither of them twice.
A second concurrency question hides in the same place and has no documented answer. Microsoft guarantees exactly one thing about machines being updated at the same time: virtual machines in a common Azure availability set are not updated concurrently. There is no equivalent statement about machines sharing a maintenance configuration, and none at all about Arc-connected servers in your own building. So if two machines must never restart within minutes of each other, the ring boundary is the only separation you have. A pair of domain controllers belongs in two rings, not in one ring with a comment in a runbook.
The asymmetry, and what it leaves with Group Policy
Scheduled patching does not work the same way on the two kinds of machine, and the difference is a prerequisite on one side and an explicit absence of one on the other. For Azure virtual machines, patch orchestration has to be set to Customer Managed Schedules, which is a portal label for two properties: the patch mode becomes AutomaticByPlatform and the platform safety check bypass on user schedules becomes true. Miss it and the machines are broken in a way that reads as fine, and Microsoft’s warning is that the schedules will fail to patch the virtual machines. The note directly underneath is the one that matters for a hybrid estate: for Azure Arc-enabled machines, it is not a requirement. The Arc documentation agrees from the other direction. There are no prerequisites for patch orchestration, but you must associate a schedule with the machine.
Underneath the prerequisite sits a difference that is easy to miss and impossible to unsee. On an Azure virtual machine running Azure-orchestrated patching, Update Manager writes to the Windows Update registry keys: the automatic update option, the reboot required state, the service identifier. On an Arc-connected machine it writes nothing. The comparison Microsoft publishes is unambiguous on all three points. Arc machines are operating system orchestrated only, Update Manager does not modify the registry, and Group Policy fully controls update behaviour.
So on the machines in this estate that sit in an office, the maintenance configuration is an orchestrator issuing instructions to a Windows Update client whose settings are still owned entirely by the directory. Two authorities, in two planes, neither aware the other exists. That is not a defect. It is the reason the source cutover later in this series is Group Policy work from beginning to end, and the reason never reboot is weaker on Arc machines than anywhere else: the registry keys that can override it are yours, they arrive by GPO, and Update Manager will not touch them. The Arc series makes the general version of this argument in [ARC 3]. Patching is its sharpest instance.
The authority Microsoft named
Because the window is a resource, who may change it is a role assignment, and Microsoft has shipped a built-in role for exactly this: Scheduled Patching Contributor. Its description is scoped precisely to managing maintenance configurations with the InGuestPatch scope and their configuration assignments. What makes it worth deliberate use is what it omits. The definition carries nothing but Microsoft.Maintenance actions: no virtual machine permissions, no Arc machine permissions, no ability to start, stop, resize, connect to or read anything. It decides when a set of servers takes its updates and whether they restart, and nothing else at all.
The blanket alternatives are what most estates land on by omission: Virtual Machine Contributor or Owner for the Azure machines, Azure Connected Machine Resource Administrator for the Arc ones, each carrying the maintenance surface incidentally along with everything else. Make no assignment at all and the owners of your change window are whoever holds Contributor on the subscription, which in a ten server estate is usually everybody. That is a decision. It just is not a considered one.
The authority nobody guards
Here is the part I planted a paragraph of earlier in this series and owe you properly. If ring membership is a tag query, the tag is a control surface, and a control surface with no governance on it is not a control at all. There are two ways to acquire the ability to write one. The first is the dedicated route, the Tag Contributor built-in role, whose description advertises exactly what it is: it lets you manage tags on entities without providing access to the entities themselves. Through the portal that role can only tag subscriptions. Through PowerShell, the CLI and REST it performs every tag operation on every resource in scope, so anybody who concludes from a portal experiment that it is harmless has tested the wrong surface.
The second route is write access on the resource itself, which Contributor and Virtual Machine Contributor both include, and it undoes the separation from the previous section. You can hand your change window to a small group holding Scheduled Patching Contributor, and every engineer with Virtual Machine Contributor on the same subscription can still move a production database server out of the cautious ring and into the pilot ring by editing a key and a value on a properties page. Nothing that looks like a patching setting was touched. No maintenance configuration was modified. The change appears in no review of who edited the schedule, because nobody edited the schedule.
You can separate the right to schedule a reboot from the right to administer a server. You cannot separate it from the right to edit a tag, unless you go and do that on purpose.
Two mechanical details make the tag more load-bearing than people assume. Tag names are case insensitive, tag values are case sensitive, and dynamic scopes filter on values, so a machine tagged with a lower case ring name is not in the ring and nothing will tell you so. It is simply never patched, and its absence from a run record is indistinguishable from it having been quiet. And resources do not inherit the tags you apply to a resource group or a subscription, so the instinct to tag the container and let membership flow downhill produces a ring with nothing in it.
So the tag needs governance in two directions: presence, so a machine cannot exist without declaring a ring, and value, so the ring it declares is one you built. Azure Policy has a built-in that requires a tag to be present. It has nothing that constrains a tag to a list of permitted values, because the built-in that looks like it does takes one exact value per assignment. Constraining a ring tag to a defined set is custom definition work, and I would rather say that plainly than dress it up. The Azure Policy series on this site owns how a custom definition is authored and moved from audit to deny without breaking every pipeline in the tenant. This series names the requirement and assigns the result.
Policy as the governor, not as the scheduler
Update Manager ships five built-in policy definitions and they divide into three jobs. Two are modify policies that turn periodic assessment on, one for Azure virtual machines and one for Arc-enabled servers, each needing a separate assignment per operating system type. One is an audit policy asserting that machines should be configured to periodically check for missing system updates, which is the compliance statement rather than the mechanism. One is a deploy-if-not-exists that attaches machines to a named maintenance configuration, taking the configuration’s resource manager identifier as a mandatory parameter and optionally narrowing by resource group, operating system, location and tags. And one is a deploy-if-not-exists that only sets the Azure virtual machine prerequisite, whose description ends by telling you it does not apply to Arc-enabled servers.
Two mechanical facts decide how those definitions behave. A modify policy needs a managed identity, and an assignment on its own only catches resources as they are created or updated, so catching the existing fleet is a remediation task with its own scope and throttles. And the compliance picture lies in a documented way: specialized, migrated and restored virtual machines land non-compliant even when created after the assignment, and the fix is again a remediation task rather than the next evaluation cycle. Assign the policy and walk away and you have a dashboard that is green about the wrong population.
The interesting question is the one Microsoft does not answer. Both the deploy-if-not-exists policy and dynamic scoping will put a machine under a schedule, the documentation presents both without preference, and I have not found a page that ranks them. So this is my reading and you should weigh it as such. Use dynamic scope for ring membership, and use policy for the audit gate and for the Azure virtual machine prerequisite.
The reasoning is latency and what each mechanism is. A dynamic scope is a property of the schedule, resolved when the schedule runs, with no identity, no remediation machinery and no compliance record to reconcile, and it reacts to a tag change at the next run. That is the responsiveness you want from something whose only job is to answer which machines are in this ring tonight. The policy route writes a per machine configuration assignment through the governance plane, on the governance plane’s cadence, which is right for a statement about how the estate should be and wrong for membership of a group that changes when somebody promotes a server. Assessment and the orchestration prerequisite are statements about how the estate should be. Ring membership is not. And do not point both at the same population: a machine caught by an assignment and by a dynamic scope is associated twice and scheduled twice.
One thing to know before you assign the assessment policies rather than after. Periodic assessment runs every twenty four hours once enabled, only against machines that are running, and on an Arc-connected server an assessment is itself a metered event unless a waiver applies. Turning it on across a fleet by policy is a billing decision as well as a hygiene one, and the cheapest moment to establish which waivers you hold is before the remediation task rather than on the invoice. The article on what patching costs takes that apart properly.
Where this goes
Of the work that follows, the part I would not compromise on is the tag governance, because it is the only part that cannot be retrofitted quietly. Rings without governed tags are a naming convention with a schedule attached, and the first person to type a ring name in the wrong case finds that out in a month when nobody is looking.
The build sheet that follows stands all of it up across this estate, in the order that puts each verification in front of the step it protects, and finishes by running one full cycle for a real ring with WSUS still supplying every byte. That last part is the point of the exercise. If a schedule can complete a monthly cycle without anything changing about where the content came from, the two powers this series opened with really are separable, and the cutover later is a change to one of them rather than a leap involving both.
After that, hotpatch, where the reboot conversation stops being about scheduling restarts well and starts being about not having most of them, and where the two Windows Server 2025 machines in this estate arrive there by entirely different routes.
Azure Update Manager
‹ Previous: [AUM 2] The WSUS Question: Coexist, Cut, or Keep
Next: [AUM 3.1] Build Sheet: Standing Up Update Manager Across the Estate ›
