Microsoft has declared WSUS deprecated, and Azure Update Manager is the answer it wants server teams to reach for. This is not a like-for-like port. Update Manager keeps the parts of patching that were always sound and rebuilds the parts that were always painful, but in doing so it moves where approval authority lives and it puts a meter on a capability that used to be free with the operating system. Treat it as the successor it is, understand what it changed on purpose, and it becomes the patching plane for servers that no longer answer to a domain.
What Update Manager actually is now
The most important thing to know about Update Manager is what it no longer requires. The earlier generation of Azure patching leaned on a Log Analytics workspace and an Automation account, and that dependency is gone. Update Manager assesses and patches a machine directly through the Arc agent, with no workspace and no automation account underneath it, which removes an entire layer of plumbing that used to break. On top of that it gives you periodic assessment on a regular cycle, on-demand and one-time patching when you need it, and scheduled patching driven by maintenance configurations that you scope dynamically by subscription, resource group, tag, or location. You describe the population and the window, and machines that match are patched on that schedule whether they existed when you wrote the rule or were onboarded afterward. That dynamic scoping is the feature that makes it scale, because you are governing a query rather than a static list.
Where WSUS fits, and who owns approvals now
Update Manager does not force you to abandon WSUS on day one, and this is where teams get the transition wrong. You can point the Windows Update client at an existing WSUS server and let Update Manager drive assessment and scheduling against whatever WSUS approves. What Update Manager replaces is the console and the scheduling, not necessarily the content source. But be honest about what that does to your operating model, because it is the real change. In the WSUS world, approval authority lived with whoever administered WSUS, and the update ring was a function of computer groups in a console. In the Update Manager world, the schedule and its scope live in Azure, and the person who owns the maintenance configuration owns when your servers reboot. The authority for patching moved from a Windows admin console into Azure role-based access control, and if you do not decide deliberately who holds that role, you have handed the change window for your entire server estate to whoever happened to get subscription rights.
WSUS decided which updates were allowed. Update Manager decides when your servers reboot. Those are not the same authority, and it moved.
Hotpatch, and a rare reversal worth noting
For Windows Server 2025, Update Manager is also the path to hotpatching, which installs most monthly security updates without the reboot, dropping the restart cadence from every month to a handful of baseline months across the year. Hotpatching is worth a paragraph on its own because its commercial story reversed in a way that rarely happens. It launched as a paid subscription, billed per core per month, and then Microsoft removed the charge entirely: hotpatching for Windows Server 2025 is now available at no additional cost to any Arc-enabled 2025 server, with the billing that had started already stopped. It is not unconditional, it wants virtualization-based security enabled and the machine Arc-connected, but the cost objection that made people hesitate is gone. If you are running 2025, this is now simply part of what Arc gives you, and it changes the reboot conversation materially.
The meter, and how the fleet gets it for free
Update Manager bills per server per month, and like the rest of the Arc management stack, that charge disappears for machines whose licensing already entitles them to it. A machine enrolled in Extended Security Updates through Arc carries no separate Update Manager charge. A subscription with Defender for Servers Plan 2 enabled includes it. And Windows Server with active Software Assurance or subscription licenses, once attested, waives it along with the rest of the management benefits. The practical result is that for a properly licensed Windows estate, modern patching costs nothing beyond what you were already paying Microsoft, and the meter mostly bites the machines that were not licensed the way you assumed. As with everything on this platform, the bill is a function of your licensing posture, so check the posture before you budget the patching.
Where this stops, and where clients go
Keep the scope honest. This is the server patching story, and it deliberately does not reach your workstations. Client devices belong to a different plane entirely, Windows Autopatch and the Intune update rings covered in the endpoint guide, and trying to bend Update Manager into a client-patching tool fights the design. The clean division is that Intune owns the clients and Update Manager owns the servers, and the WSUS deprecation that pushed you here applies to both, which is why the migration is happening across the estate at once even though the tools on each side are different.
To the build
That is the shape of patching after WSUS: a workspace-free assessment engine, dynamic maintenance schedules, a real coexistence path with the content source you already run, an authority that quietly moved into Azure, and a hotpatch story that just got cheaper. The companion build sheet stands it up, from periodic assessment through a scoped maintenance configuration to the hotpatch enrollment and its prerequisites, and confirms the meter and its waivers against your actual machines. After patching, the series turns to the wider operations surface, the extensions, monitoring, and remote access that make an Arc server something you can actually run day to day.
Azure Arc
‹ Previous: [ARC 3.1] Build Sheet: A Machine Configuration Baseline
Next: [ARC 4.1] Build Sheet: Update Manager End to End ›
