The estate at the end of this work is one server smaller and one console quieter, and if that is the whole of what you booked then you undercharged. Retiring WSUS does not simplify a patching architecture by itself. It takes four powers that used to sit in one building and puts three of them somewhere new, under different roles, held by different people. The fourth one does not move anywhere. It stops existing, and almost nobody notices it going.
The approval gate did not move
WSUS had a human step in it. An update sat in a console and was not installable on a single machine until a named person approved it, and whatever you think of how rigorously that got done on a Wednesday afternoon, it was a gate. Update Manager has nothing shaped like that. Its selection controls are update classifications, inclusion and exclusion by KB number, and a maximum publish date, every one of them a filter the machine evaluates at run time against whatever Microsoft has already published. A filter narrows what arrives. It does not require anybody to have looked.
I have not found a way to express per-update sign-off in Update Manager and I do not believe one exists, which is my reading rather than a Microsoft statement, and an absence I report deserves less weight than a limitation the vendor documents. The consequence is not in doubt. An estate that cut its content source over to Microsoft did not relocate its approval step into Azure. It deleted it, in the same change that deleted the GPO, and the deletion produced no error, no prompt and no line in any report.
That is a thing to decide rather than discover, and there are two defensible answers. The first is that approval stops being editorial and becomes empirical: Ring0 is the gate now, and an update is approved by surviving a pilot machine for a week rather than by somebody reading a bulletin. In most estates that is the better gate, and it is worse in exactly one respect, which is that it leaves no artifact an auditor recognises. The second is to keep a WSUS instance as the content source under an Update Manager schedule and keep the sign-off, which the article on the WSUS question already ruled legitimate. What you cannot do is claim the first while your change policy still describes the second.
The change window has an owner, and the owner is written down
Before this work the change window was an artifact of Group Policy: registry values written by a GPO, changed by whoever had rights over that GPO, with a blast radius of whatever it was linked to. Reconstructing who moved a reboot schedule and when was possible only if somebody had turned the auditing on beforehand, which in the estates I walk into is roughly never.
Now the window is a maintenance configuration, an ordinary Azure resource with a resource ID, sitting in a resource group, created and edited and deleted through Resource Manager, so every one of those operations is a resource write with a principal attached to it. The jurisdiction moved from the directory to the subscription, and the evidence moved with it, from somewhere you had to prepare in advance to somewhere that was already recording.
The role boundary is the part I would make somebody sign off. Scheduled Patching Contributor, role ID cd08ab90-6b14-449c-ad9a-8f8e549482c6, carries nothing but Microsoft.Maintenance actions: it can create the window, assign machines to it and decide whether they restart, and it cannot start, stop, resize or connect to a single one of them. That separation had no usable equivalent in the WSUS world and is the one piece of this redistribution that is unambiguously an improvement. It only exists if you use it. If nobody holds the role, your change window belongs to everyone with Contributor or Owner on the subscription, which in an estate this size is everybody who has ever needed to build anything.
Ring membership is now a string in a field
The rings are the part of this design I am fondest of and the part with the softest edges. A dynamic scope resolves membership at the scheduled run time rather than at authoring time, which is what makes rings survive a real estate: machines built last Tuesday land in the right window without anybody remembering to add them. The mechanism underneath is a tag, and removing the tag drops the association automatically, so ring membership is as durable as a text value anyone with write access can overwrite.
Two things follow. The first is that the population able to move a production database server from the cautious ring into the pilot ring is far larger than anybody intends. Writing tags takes either write access on the resource, which every Contributor and Virtual Machine Contributor already has, or the Tag Contributor role, ID 4a9ae827-6dc8-4573-8ac7-8239d42aa03f, whose description says it lets you manage tags on entities without providing access to the entities themselves. So one person can be handed the power to change when a domain controller reboots while holding no authority over that machine at all, and everyone who can already administer it can do the same by editing a field that does not look like a patching setting.
Ring membership is a string in a field. The only thing defending it is a policy somebody had to sit down and write.
The second is that Azure will not defend the value set for you. Tag values are case-sensitive, dynamic scopes filter on them, and no built-in policy definition enforces an allowed list of values. Requiring that PatchRing is one of Ring0, Ring1, Ring2, RingSQL or RingAzure and nothing else is custom policy authoring, which the Azure Policy series on this site owns. Skip it and the estate sits one typo away from a machine in no ring at all, patching on no schedule, reporting as compliant because nothing ever asked it to install anything.
The source is Microsoft’s now, and so is the lever
Cutting the content source over is the change that removes a server from the estate, and the sale is honest as far as it goes. The Group Policy pin is gone, and so are the database, the Windows Internal Database underneath it that Microsoft says will be removed from Windows in a future release anyway, the IIS site, the content volume and the accumulated metadata that gave a whole class of estates a bad fortnight in July 2026. That there is no documented way to perform the removal, because Microsoft publishes no WSUS decommissioning guidance at all, tells you how much interest there is upstream in that retirement.
What went with it is a lever. When the content source was a box in the comms room, holding one update back across the whole estate was a single unapproval, central, immediate, reversible in the same click. Nothing here replaces that cleanly. The nearest equivalents are a KB exclusion and a maximum publish date, per-schedule filters somebody has to author correctly on every ring, and the ring structure itself, which contains a bad update rather than preventing it. If your reflex for a bad Tuesday was to unapprove and move on, replace that reflex before you need it.
Two smaller losses are worth naming so nobody rediscovers them under pressure. There is no local cache and no pre-download, so every machine pulls its own cumulative update inside its own window, and Delivery Optimization is not a mitigation on Windows Server 2016 because it is not supported there at all. On a ten server estate that is a non-problem most months. And the cost did not disappear, it changed shape and owner: an Arc machine that gets assessed is a metered machine unless a licensing position waives it, so the estate swapped a server bought once for a line item renewed monthly, and which waiver you qualify for matters for more than the invoice.
Where this whole approach is the wrong answer
I would rather lose a reader here than have one finish a migration their estate cannot support, so these are stated flatly.
Update Manager is the wrong tool for Windows clients. Client operating systems are an unsupported workload and Microsoft’s own answer to the Windows 10 and Windows 11 question is to point at Intune. If the WSUS box you are retiring also serves laptops, and most do, you have two projects on two timetables owned by two teams, and the endpoint one is covered in [5.5] rather than here.
It is the wrong tool for a third-party-heavy estate. It does not patch third-party software on Windows, and Microsoft’s own remedy is to publish those updates into WSUS and let Update Manager install what WSUS offers, which makes the successor product’s answer to the gap the product it succeeds. If publishing Chrome and Adobe and your line-of-business agent is load-bearing, cutting the source does not relocate that capability, it ends it. The working answers are a standalone WSUS kept alive as a publishing point and nothing else, a dedicated third-party patching product, or keeping Configuration Manager if you have it.
It is unavailable, not merely awkward, to an estate with no Azure footprint. Every machine that is not an Azure virtual machine has to be Arc-connected before Update Manager will manage it, which means a subscription, an agent on every server and an outbound trust relationship somebody has to own. There is no offline mode and no entry point that skips Arc. If the organisation has no Azure tenancy and is not acquiring one, stay on WSUS deliberately and put the diary date against the operating system underneath it rather than the role.
And it does not serve genuinely air-gapped machines. The architecture assumes a machine that can reach Azure for orchestration and Microsoft for content, and one that can do neither needs a local source, which in that environment is the entire mechanism rather than an optimisation. Those estates keep a content server permanently, and that is the design rather than debt.
The decision, condensed
All of that resolves into a handful of estate characteristics that decide the architecture for you, in the order I would ask about them.
| If this is true of your estate | The architecture | Why it decides |
|---|---|---|
| No Azure subscription, and none coming | Keep WSUS. Plan the host operating system’s lifecycle, not the role’s | Arc is a hard prerequisite for every non-Azure machine |
| Machines with no route to the internet at all | Keep a local content source permanently | Orchestration and content both need reachability, so a local source is the mechanism rather than a tuning choice |
| Third-party publishing into WSUS is load-bearing | Standalone WSUS as a publishing point, a dedicated third-party product, or keep Configuration Manager | Update Manager publishes nothing, so cutting the source ends the capability rather than moving it |
| Per-update human sign-off is a written, non-negotiable requirement | WSUS as content source, Update Manager as the schedule. Stop after phase one and record why | The product’s controls are filters, not gates. Approval has no successor |
| Windows client devices in scope | Intune and Autopatch, as a separate project with a separate owner | Client operating systems are an unsupported workload, which is a scope boundary rather than a limitation to route around |
| Windows Server estate, Arc-connected or Azure-hosted, approval by pilot ring acceptable | Update Manager, rings as maintenance configurations, source cut ring by ring, WSUS retired last | Schedule and source are independent levers, so this is two reversible phases rather than one migration |
| Windows Server 2016 present, Software Assurance in place | Extended Security Updates through Arc, over the connection the patching already uses | Configurable now, billing from 13 January 2027, and an enrolled machine stops metering Update Manager |
| Windows Server 2016 present, no Software Assurance | Upgrade or replatform those machines before 12 January 2027 | Software Assurance is required and SPLA excluded, so there is nothing to buy |
The four machines with a date on them
Four of Cat Snack Jack’s ten servers run Windows Server 2016, whose extended support ends on 12 January 2027. Two are the domain controllers, one is the legacy application server that gets patched last by tradition, and the fourth is WSUS01, which this work removes by design. The project retires a quarter of the problem as a side effect and hands the rest straight back.
Extended Security Updates for Windows Server 2016 through Arc are real and configurable now: announced in February 2026, configurable in the Azure portal since 3 August 2026, billing beginning 13 January 2027, the day after support ends. They ride the Arc connection the patching already uses, and an enrolled machine stops being charged for Update Manager. What nobody can tell you is the price, because it is published nowhere, and I will not infer it from a previous generation when Microsoft has spent 2026 removing exactly that continuity from its offerings.
The eligibility rule is where this stops being a planning exercise for a large part of the readership. Software Assurance is required and SPLA is excluded, and weighed against the two licensing positions the article on the meter set out, that is not symmetrical. The estate with Software Assurance on its server licences, already attesting for Windows Server Management and running Update Manager without a meter, can buy runway and choose when to spend it. The estate on the Microsoft 365 Business Premium footing, with no Software Assurance on its server licences, cannot buy ESUs at all. Not expensively. At all. Defender for Servers Plan 2 does not rescue it, because what Plan 2 waives is the Update Manager charge, not the licensing status that makes a machine eligible.
Without Software Assurance there is nothing to buy. For that estate January 2027 is not a decision. It is a date.
For that reader the only honest options are upgrading in place or replatforming the workload, and both belong in a plan now rather than a conversation next autumn, because two of the three surviving machines are domain controllers and domain controllers are not a weekend. The legacy application server is harder, because the reason it is still on 2016 is almost never the operating system. It is the application, the vendor, and a support statement written by somebody who has since left. Update Manager will keep it patched impeccably until the month there is nothing left to patch it with, and a green dashboard on an unsupported operating system is a worse artifact than a red one.
What the plane does once the machines are on it
Patching was the reason these servers got connected to Arc, and it is the smallest thing that connection now makes possible. Once a machine is projected into Resource Manager it has an identity, a policy surface, an extension surface and a remote access path, and Update Manager is one consumer among several. The Arc series is where that argument lives: [ARC 1] for what the management plane is and what connecting an agent commits you to, [ARC 5] for the operations surface, [ARC 6] for the licensing arithmetic that decides whether the plane pays for itself, and [ARC 6.1] for the ESU enrolment where the estate qualifies. If this series left you wondering whether an Arc-managed server should still be domain-joined, [ARC 8] takes that decision directly.
The other half of the story is identity, and it has the same shape. An estate that just removed one server for being a middle tier nobody develops any more still has two domain controllers on an operating system with a date on it, holding the last workload in the building that everything else assumes will always be there. Whether those machines get upgraded, replatformed or made unnecessary is the subject of the AD to Azure series here, and it is this same argument about authority arriving at a much older institution. Patching moved to the subscription first because it was the easiest thing to move. That does not make it the most important.
What you own now is smaller and sharper than what you owned before. A schedule that is a resource, with a role attached to it that you can name in a meeting. A ring structure that is only as good as the policy defending its tag values. A content source you no longer operate and can no longer overrule. And a January date that settles itself on paperwork signed years ago rather than on anything you can do in a console. Go and find out which of the first three you have actually assigned to somebody, because until somebody owns them they are only architecture. The fourth one does not need an owner. It arrives on its own.
Azure Update Manager
‹ Previous: [AUM 7.1] Build Sheet: The Operations Scaffolding
