Every estate I walk into has a patching story, and almost none of them has a patching owner. The updates arrive, the servers reboot at some hour nobody chose recently, and the arrangement holds because it has always held. Azure Update Manager is the tool Microsoft wants you to move that arrangement into, and it is best understood as a redistribution of authority rather than as a replacement console. Patching is made of two separate powers that WSUS kept in one building, and Update Manager takes exactly one of them.
The two powers
Patching a Windows estate involves deciding two things that have nothing to do with each other. The first is which updates a machine is even offered, which is a question about where it gets its content. The second is when the machine installs them and whether it restarts afterwards, which is a question about your change process. A WSUS deployment answered both in the same room. Someone approved updates in a console, and a Group Policy told the machines where to look and roughly how to behave, and because one team held the console and wrote the policy, nobody had to notice that these were two powers rather than one.
Update Manager separates them, and it is emphatic about which half it will not touch. Microsoft’s own words are that Update Manager honors the update source settings on the machine and fetches updates accordingly, and that Update Manager does not publish or provide updates. It is not an update source. It never becomes one. Point a server at your existing WSUS box and Update Manager will happily assess and patch that server against whatever WSUS has approved, because the content decision was never its to make.
Update Manager took over the change window, and left the content question exactly where it was.
That single design fact is the reason this series runs as long as it does rather than being one article. If the product replaced WSUS outright, the work would be a migration and migrations are boring. Because it replaces only half, you end up running two systems on purpose for a while, and every interesting decision in this whole subject lives in that overlap.
What Update Manager actually is now
If you last looked at Azure patching in the Automation Update Management era, put that mental model down. The old one hung off a Log Analytics workspace and an Automation account, and that dependency is gone. Microsoft states it flatly in the product’s own benefits list, no dependency on Log Analytics and Azure Automation, and answers the direct question in the FAQ with a single sentence: it is a native capability on a virtual machine. There is no workspace to size, no automation account to keep alive, and nothing to migrate between them when one of them rots.
What actually runs on the machine is an extension, pushed automatically the first time you trigger any Update Manager operation, and it drives the Windows Update client that was already there. An Azure virtual machine gets one extension, Microsoft.CPlat.Core.WindowsPatchExtension. An Arc-connected Windows machine gets two, that one for periodic assessment plus Microsoft.SoftwareUpdateManagement.WindowsOsUpdateExtension for on-demand operations and scheduled patching. You do not install them and you do not manage their lifecycle. This matters less as an implementation detail than as a mental correction: Update Manager orchestrates, and the local Windows Update agent executes. Almost every confusing failure in this product reduces to that sentence, and we will keep returning to it.
The results land in Azure Resource Graph rather than a log workspace, and the retention is short enough to plan around: pending updates for seven days in patchassessmentresources, installation results for thirty in patchinstallationresources. If your auditor wants patch evidence going back a year, that is an export pipeline you have to build, and knowing it now is cheaper than discovering it during an audit.
The estate this series is written against
Abstractions about hybrid estates are useless, so this series runs on a specific one. Cat Snack Jack is a company with real workload in an office and real workload in Azure, ten servers between them, currently patched through a WSUS box that has been there longer than anyone who now maintains it. It is deliberately unglamorous, because the estates that make this subject interesting are unglamorous.
On premises there are two domain controllers on Windows Server 2016, a file server pair on 2022, a SQL server on 2019, a legacy application server on 2016 that reboots reluctantly and is patched last by long tradition, a new application server on 2025 running on Gen 2 Hyper-V, and the WSUS server itself, which is also 2016. In Azure there are two more: one Windows Server 2025 machine built from the Datacenter: Azure Edition image and never joined to the domain, and one 2022 machine that is domain-joined across the site-to-site link.
Three things about that list do all the work in this series. The first is that four of those machines run Windows Server 2016, whose support ends on 12 January 2027, and one of the four is the WSUS server, so the box being retired has its own deadline written on it. The second is that the two application servers running Windows Server 2025 sit on opposite sides of a genuine asymmetry in how Microsoft delivers reboot-free patching, and walking both sides is the only honest way to explain it. The third is the quiet one, and it is the reason this series opens where it does.
The Azure machine that was never domain-joined never received the Group Policy that pins everything else to WSUS. It has been patching itself directly from Microsoft since the day it was built. Cat Snack Jack does not have one patching architecture with an exception. It has two, it has had two for years, and nobody chose the second one. That is not a story about a badly run company. It is what happens by default the moment a server exists outside the domain, and it is why the question of coexisting with WSUS is the next article rather than a late one.
Who owns the reboot
Here is the authority shift, stated as plainly as I can. In the WSUS world, the change window was an artifact of Group Policy. It lived in a GPO, it was edited by whoever edited GPOs, and its blast radius was whatever the policy was linked to. In the Update Manager world, the change window is a maintenance configuration, which is an Azure resource. It has a resource ID, it lives in a resource group, it is subject to role-based access control, and it can be created, edited or deleted by anyone holding the right role at the right scope. The window did not just change format. It changed jurisdiction, from the directory to the subscription.
Microsoft has given that authority a name, which is more than most platform capabilities get. The built-in role is Scheduled Patching Contributor, and its description is exactly what you would want it to be: access to manage maintenance configurations with maintenance scope InGuestPatch and the corresponding configuration assignments. What makes it worth noticing is what it does not carry. Read the role definition and it holds nothing but Microsoft.Maintenance actions. No virtual machine permissions. No Arc machine permissions. It cannot start, stop, resize, or log into anything. It can only decide when the machines it is pointed at take their updates and whether they restart.
That is a genuinely useful separation and I would encourage you to use it deliberately, because the alternative is what most estates land in by accident. If nobody assigns that role, the people who end up owning your change window are whoever holds Contributor or Owner on the subscription, which in a small estate is usually everybody who has ever needed to do anything. Handing the reboot schedule for your domain controllers to the same principal that builds test virtual machines is a decision, whether or not anyone made it.
If you have not named who holds the maintenance configuration, you have named everyone with Contributor.
There is a second-order version of this that catches people later, and it is worth planting now. Membership of a patch ring is not a property of the schedule; it is a query the schedule runs, and in practice the query is over tags. Whoever can write a machine’s tags can move it between rings, and the set of people who can write tags on a resource is almost always far larger than the set who should be able to change when a production database restarts. Moving a server from the cautious ring to the first one is a patching change made without touching anything that looks like a patching setting. The article on rings takes that apart properly.
One asymmetry to carry with you
Update Manager does not behave identically on the two kinds of machine it manages, and the difference is not cosmetic. On an Azure virtual machine configured for Azure-orchestrated patching, Update Manager writes to the registry, setting the automatic-update behavior and tracking reboot state. On an Arc-connected machine it writes nothing. Microsoft’s own comparison is blunt about it: Arc machines are OS orchestrated only, Update Manager does not modify the registry, and Group Policy fully controls update behavior.
Read that last clause slowly, because it undoes an assumption almost everyone brings to this product. Connecting your on-premises servers to Arc and scheduling them in Update Manager does not take them out from under Group Policy. Their update behavior is still governed by the GPOs you have, and the maintenance configuration sits on top as an orchestrator. For most of this estate that is fine and even desirable. It becomes the whole story later, when the time comes to change where those machines get their content, because that change is Group Policy work from beginning to end and Update Manager only watches it happen.
The fences, stated before you hit them
Products are usually sold by what they do. It saves more time to know what they refuse to do, and Update Manager refuses five things clearly enough that Microsoft documents each of them in a sentence. I would rather you meet them here than in a planning meeting.
It does not do client devices. Windows client operating systems are listed as an unsupported workload, and the FAQ answers the Windows 10 and Windows 11 question by pointing at Intune. If your WSUS box serves workstations as well as servers, and most do, then retiring it is two projects and only one of them is this one. The other belongs to the endpoint side of the house, which is covered in [5.5] and its build companion.
It does not patch third-party software on Windows. Microsoft’s position is that if you want third-party applications patched, you import and publish them to WSUS and Update Manager installs what WSUS offers. Which means the tool positioned as the successor to WSUS depends on WSUS for a category of work many estates rely on it for. That is not a gap I can talk you out of, and it is the single most common reason a WSUS server outlives its own funeral.
It shows you driver updates and will not install them. They appear in assessment, which is useful, and then stop there. It cannot pre-download anything, so every machine pulls its cumulative update inside the maintenance window rather than staging it beforehand. And it cannot change where a machine gets updates, which Microsoft states as an instruction rather than a limitation: to change the patch source, use Windows settings or Group Policy, and do not use Update Manager for this.
None of those five is a defect. Together they describe a product with a narrower and more honest job than its name suggests, and every one of them shapes a decision later in this series.
What this series assumes
Two assumptions, both stated so you can check them before investing an afternoon.
The first is Arc. Any machine that is not an Azure virtual machine has to be Arc-connected for Update Manager to manage it at all, and Microsoft is unambiguous that this is a prerequisite rather than a recommendation. This series does not re-teach that. The Arc series on this site covers what Arc is and what connecting an agent commits you to in [ARC 1], and the onboarding decision itself in [ARC 2]. If your servers are not connected yet, start there and come back.
The second is that this is a servers-only story, and I mean that as a scope boundary rather than an aside. Everything here is about machines running a server operating system. Your laptops leave WSUS through a different door, on a different timetable, owned by a different team in most organisations. Trying to make one project of both is the most common way this work stalls.
Where this goes
The series runs in the order I would actually do the work, which is not the order the product documentation implies.
It starts with the WSUS question, immediately, because every other decision depends on the answer and because the honest answer is not the one the word deprecated implies. Then the rings: maintenance configurations, dynamic scoping, and the tag governance that has to sit underneath them if ring membership is going to mean anything. Then hotpatch, which is where the reboot conversation gets genuinely better and where the two Windows Server 2025 machines earn their place in the estate.
The middle of the series is the cutover, and it is the part I would read first if I only read one: moving the content source off WSUS ring by ring, which is Group Policy work with a specific trap on this estate’s exact mix of operating systems, followed by the decommissioning of the WSUS server itself. Microsoft publishes no guidance for that last part, which is worth knowing before you plan around finding some.
Then the money, which is where the surprises live, because assessment alone is a billable event on an unwaivered machine and several licensing positions waive the charge entirely. Then operations, meaning the reporting and alerting scaffolding that everyone ends up building because the product’s own retention is measured in weeks. And the series closes on the estate afterwards, including the January 2027 deadline sitting on four of these ten servers. Extended Security Updates for Windows Server 2016 became configurable in the Azure portal in early August 2026, so for estates whose licensing qualifies that is a live option rather than a promised one, though what it costs is still published nowhere. Whether yours qualifies is a real question with a real answer and it is not the same answer for everybody, which is why the licensing article takes it and the closing article weighs it against the two exits.
Next: the WSUS question, argued both ways and then decided, because a deprecated product supported into the 2030s is not a burning platform and pretending otherwise makes for bad architecture.
Azure Update Manager
Next: [AUM 2] The WSUS Question: Coexist, Cut, or Keep ›
