WSUS Replacement with Azure Update Manager for Servers
IT Partner replaces your Windows Server Update Services (WSUS) infrastructure with Azure Update Manager for Windows and Linux servers — on-premises and other-cloud machines through Azure Arc, Azure VMs natively — in a two-week engagement built around one production-safe order: inventory what WSUS actually does today, design patch rings as dynamic scopes and maintenance configurations, onboard the servers that are not yet in Arc, pilot, roll out ring by ring, and decommission WSUS only after the first production cycle succeeds. It covers pre and post maintenance events for the scripts WSUS never had, compliance reporting and alerts from Azure Resource Graph, Extended Security Update delivery for enrolled Windows Server 2012 R2 and 2016 machines, and a written coexistence decision wherever Configuration Manager is present. Microsoft deprecated WSUS on 20 September 2024 and points server patching at Azure Update Manager; this is that migration, sized for estates of roughly 25 to 1,000-plus servers. Pricing is an estimate at $15 per server plus a $1,950 base fee, confirmed in writing once the inventory is agreed; estates above 500 servers are quoted per estate. Microsoft's own meters — Update Manager's per-server charge for Arc-enabled servers, and ESU — are billed by Microsoft to your Azure subscription and are not part of this fee. Workstation patching and ongoing patch operations after handover are separate, named services, linked below.
What this engagement is
Microsoft deprecated Windows Server Update Services on 20 September 2024. Deprecated, not removed: WSUS still ships in Windows Server 2025 and keeps receiving security fixes, but it gets no new development, and Microsoft's stated direction is Azure Update Manager for servers — through Azure Arc for anything that is not already an Azure VM — and Intune and Windows Autopatch for client devices. Two other things have shifted underneath a typical WSUS estate. Azure Automation Update Management, the previous cloud answer, was retired on 31 August 2024 together with the Log Analytics agent it depended on. And Microsoft's September 2025 hardening of WSUS on Windows Server 2025 removed the legacy self-update binaries WSUS used to serve Extended Security Updates to Windows Server 2012 and 2012 R2 clients, so the newest WSUS is the one least able to feed the oldest servers. If your patching still rests on a WSUS server, a set of approval rules and a Group Policy object from 2014, the platform beneath it is being wound down on three fronts at once. Azure Update Manager is a different model rather than a cloud-hosted WSUS, and the design has to respect that. There is no update repository to feed: each server keeps fetching updates from Microsoft Update, from a WSUS server you choose to keep as a download source for a while, or from its Linux distribution's repositories — Microsoft's own wording is that Update Manager honors the update source configured on the machine and does not publish updates itself. What moves to Azure is everything around the download: assessment, scheduling, installation, reboots and reporting. Azure VMs need only the platform's guest agent; on-premises and other-cloud servers come in through the Azure Connected Machine agent, which connects outbound only. WSUS computer groups become dynamic scopes — membership defined by subscription, resource group, location, OS type and tags, so a server tagged for ring 2 joins ring 2 the moment the tag lands, on Windows and Linux alike. Approval deadlines become maintenance configurations: recurring schedules with a window, update classifications, KB or package inclusions and exclusions, and an explicit reboot policy. The pre- and post-scripts WSUS never had become pre and post maintenance events on Azure Event Grid, wired to a webhook, an Azure Automation runbook or an Azure Function — stop a service, drain a cluster node, take a snapshot, notify an application owner, start a VM that is normally off. Periodic assessment checks each machine every 24 hours, and every result lands in Azure Resource Graph, which is where the compliance reports, workbooks and alert rules read from. This engagement is the transition, done in the order that keeps production safe. We inventory what WSUS is actually doing today — every computer group, approval rule, downstream server, and the Group Policy objects and registry settings that point servers at it — and design the replacement: rings, scopes, tag schema, maintenance windows, reboot rules, update source per site, and a written decision for every Configuration Manager and ESU interaction we find. We onboard the in-scope servers that are not yet in Azure Arc, or build on the Arc estate you already have, switch on periodic assessment through Azure Policy, and capture a compliance baseline before anything changes. A pilot ring patches first, on Update Manager, while WSUS is still standing. Production rings follow, servers are released from the WSUS policy in the order the design sets, and only after the first production cycle succeeds do we retire WSUS itself — approvals frozen, downstream servers handled, policies removed, service stopped with a rollback window, then removed. You leave with a runbook your team can operate and a closeout report that names every server that could not make the move, and why. Two things this page is careful about. Microsoft's meters are yours: per Microsoft's pricing page, Update Manager carries no separate charge for Azure VMs, while for Arc-enabled servers Microsoft bills a per-server monthly charge to your subscription — waived under Microsoft's terms for servers enabled for Extended Security Updates through Arc, for subscriptions running Microsoft Defender for Servers Plan 2, and for Azure Local — and Extended Security Updates themselves are metered per core. We model every one of those figures in the design against Microsoft's current price list rather than printing numbers here that Microsoft revises, and nothing metered is switched on before you have seen its monthly figure. And this is a server engagement for estates of roughly 25 to 1,000-plus machines: workstations belong on Intune and Windows Autopatch, and ongoing patch operations after handover are a separate, named service — both linked below rather than quietly bundled.
Success criteria
What you receive
How the work unfolds
We inventory the WSUS estate as it really is — groups, approvals, downstream servers, targeting policies — and the population behind it: operating systems against Microsoft's support matrix, Azure VMs versus servers that need Arc, ESU machines, Configuration Manager clients, and the maintenance constraints of each application owner. The design document follows: rings, tags, scopes, windows, reboot rules, update source per site, coexistence decisions, and the Microsoft cost model. You approve the design and the cost model before anything is deployed.
Servers not yet in Azure Arc are onboarded at scale, or the existing Arc estate is verified; Azure VMs get their native settings. Tags are applied per the schema, periodic assessment is switched on through Azure Policy, and we capture the compliance baseline — the honest picture of what WSUS has and has not been installing.
A pilot ring spanning your real diversity — Windows and Linux, an Azure VM, an Arc server, an ESU machine if you have one, the fussiest application — gets its maintenance configuration and dynamic scope, its pre and post events, and runs a full cycle on Update Manager while WSUS is still standing. Reporting is validated against what actually installed, and the design is corrected from evidence.
Production maintenance configurations and scopes are built ring by ring; servers are released from the WSUS policy in the designed order; Configuration Manager coexistence settings are applied where present; the workbook and alert rules go live; and the first production cycle runs inside the agreed windows. Where the calendar allows, the engagement is scheduled so this cycle falls on a real Patch Tuesday.
Once the first production cycle has succeeded on Update Manager, the decommission runbook runs: approvals frozen, downstream servers handled, targeting policies retired, WSUS stopped with a rollback window, then removed. The handover session, operations runbook and closeout report close the engagement. If Patch Tuesday falls outside the two weeks, the decommission step is scheduled for the first business days after that cycle, inside the same fixed price.
Prerequisites
Who does what
IT Partner
- Inventory the WSUS estate and design the Update Manager replacement: rings, tags, scopes, maintenance configurations, update sources, pre and post events, coexistence decisions, and the Microsoft cost model.
- Onboard in-scope servers to Azure Arc or verify the existing estate, enable Azure VMs natively, switch on periodic assessment through Azure Policy, and capture the compliance baseline.
- Build and run the pilot ring, then the production rings, and release servers from WSUS in the designed order with a rollback path.
- Implement the pre and post maintenance events, the compliance workbook and the alert rules, and verify ESU delivery on enrolled servers.
- Execute the WSUS decommission runbook after the first successful production cycle, and deliver the operations runbook, handover session and closeout report.
- Say plainly which servers cannot move — unsupported operating systems, no outbound path, machines that should be upgraded or retired instead — and route them to the right service rather than patching around them.
Your team
- Provide the inventory, administrative credentials, the agent deployment mechanism, and outbound connectivity or proxy details per the design.
- Sign off the ring model, maintenance windows, reboot policy, update source decisions, and the Configuration Manager coexistence decision where relevant.
- Provide change-window approvals for the pilot and production cycles, and make application owners available for the pre and post event requirements.
- Own Microsoft charges for Update Manager, ESU and any Azure services the events use, billed to your subscription.
- Confirm the go-ahead for WSUS decommission after the first production cycle, and retain or retire WSUS hardware and licensing afterwards.
- Operate the rings after handover using the runbook, or engage ongoing patch operations separately.
What's not included
Limitations & technical notes
Frequently asked questions
Is WSUS actually going away, or just deprecated?
Deprecated, on 20 September 2024, and Microsoft has been clear about what that means: no new features or investment, but WSUS still ships in Windows Server 2025 and keeps receiving security fixes for that product's lifecycle. Deprecation is not a shutdown date. What it is, is a signal that the tooling around WSUS will keep eroding — Azure Automation Update Management was retired on 31 August 2024, and the 2025 hardening of WSUS on Windows Server 2025 already broke ESU delivery to the oldest servers. Microsoft's stated direction is Azure Update Manager for servers and Intune with Windows Autopatch for clients, and moving on your own schedule beats moving when something breaks.
What does Azure Update Manager cost to run?
Per Microsoft's pricing page, nothing extra for Azure VMs. For Arc-enabled servers Microsoft bills a per-server monthly charge to your Azure subscription, prorated daily for the days the server is connected and managed — and waives it for servers enabled for Extended Security Updates through Arc, for subscriptions with Microsoft Defender for Servers Plan 2 enabled, and for Azure Local. Azure Arc's core control plane itself carries no charge. We deliberately do not print Microsoft's rate here because Microsoft revises it; the design phase models your exact mix against the current price list, and nothing metered is switched on before you have seen its monthly figure.
Do we need Azure Arc on every server?
Only on the ones that are not Azure VMs. Azure VMs are managed natively through the platform's guest agent. On-premises servers, servers in VMware or Hyper-V, and servers in other clouds need the Azure Connected Machine agent, which registers the machine in Azure as an Arc resource and connects outbound over HTTPS only — no inbound rules, no data plane moving anywhere. If your estate is already Arc-enabled from our Azure Arc Hybrid Server Management implementation, we build on it; if not, onboarding the in-scope servers is part of this engagement.
Can we keep WSUS as the download source for a while?
Yes, and for bandwidth-constrained or egress-restricted sites it is often the right first step. Update Manager honors whatever update source the machine is configured for — Microsoft Update or a WSUS server — and takes over assessment, scheduling, installation and reporting either way. The catch is that WSUS then remains a dependency you have to keep patched and synchronized, with approval rules that can still block an update Update Manager expects to install. The design names the source per site and, where WSUS stays as a source, the date and conditions for retiring it.
How do patch rings work compared with WSUS computer groups?
In WSUS, a computer group is a static list you maintain and approvals target it. In Update Manager, a ring is a dynamic scope — a query over subscription, resource group, location, OS type and tags — attached to a maintenance configuration that defines when and how updates install. Tag a new server with the ring tag and it is in the ring; move the tag and it moves. We typically design a pilot ring, one or two production rings, and a ring for ESU machines or servers with special reboot rules, each with its own window, classifications, exclusions and reboot policy, and we enforce the assignment through Azure Policy so a server nobody remembered still gets a schedule.
What happens to the pre and post scripts we had in Automation Update Management?
They come across as pre and post maintenance events. Update Manager publishes a pre-maintenance and a post-maintenance event on Azure Event Grid for each scheduled run, and you subscribe a handler — a webhook to an Azure Automation runbook, an Azure Function, or your own endpoint. Two engineering realities we design for: Event Grid delivers at least once, so handlers must be idempotent, and a pre-event that needs to cancel the run must call the cancellation API at least ten minutes before the window starts. The typical set we implement is service stop and start, an application health check, and notification to the owner; anything more elaborate is scoped as its own pattern.
We run Configuration Manager. Can both manage updates?
Not on the same servers. Microsoft's guidance is explicit: Update Manager and Configuration Manager must not manage software updates for the same set of machines at the same time, and once Update Manager is enabled Configuration Manager should be used only for its other capabilities. In practice that means scoping the software update point away from the servers moving to Update Manager, adjusting client settings, and setting the Windows Update client so it is not auto-updating on its own. Configuration Manager keeps application deployment, inventory and everything else it does well. One gap we name in the design: Update Manager has no equivalent of orchestration groups for sequencing maintenance across a cluster, so sequencing is reproduced with rings and pre and post events.
Does this deliver Extended Security Updates for Windows Server 2012 R2 and 2016?
It delivers them; it does not enroll you. Servers enabled for ESU through Azure Arc receive their Critical and Important security updates through the normal Windows Update channel, and Update Manager schedules and reports the installations — Microsoft also waives the Update Manager charge for those servers. Enrollment, licensing and the ESU meter are the Windows Server ESU Enrollment through Azure Arc service. Two dates frame the decision, per Microsoft's product lifecycle: Windows Server 2012 and 2012 R2 ESU ends on 13 October 2026, and Windows Server 2016 leaves extended support on 12 January 2027, with ESU through Arc configurable since 3 August 2026 and billed from 13 January 2027.
What about Linux servers?
Same tooling, same rings. Update Manager assesses and patches Linux through the distribution's package manager against the repositories the machine is configured for — Red Hat, SUSE, Ubuntu, Debian, Oracle, Rocky, Alma and Amazon Linux are on Microsoft's support matrix, with version ranges we confirm during assessment. Linux servers go into dynamic scopes and maintenance configurations exactly like Windows ones, with their own reboot handling, which is usually the first time a WSUS-only shop has had Linux patching in the same compliance view.
What does compliance reporting look like afterwards?
Every assessment and installation result lands in Azure Resource Graph, and Update Manager's own portal views show compliance, pending updates, history and schedule outcomes across Azure VMs and Arc servers together. We hand over saved Resource Graph queries for the questions your auditors actually ask — what is missing, where, since when, what failed and why — an Azure Monitor workbook for the estate, and alert rules for failed installations, missing Critical or Security updates beyond your threshold, and machines that have stopped reporting. No Log Analytics workspace is required for the core data, though one can be added for long-term retention.
How long can a maintenance window be?
Up to 3 hours 55 minutes for a single scheduled run, with Microsoft reserving the last minutes of the window so in-flight installs and reboots complete inside it. That surprises teams used to leaving WSUS deadlines open all night. The design answer is several rings with their own windows across the maintenance period rather than one long window, which also limits how much can go wrong at once. Schedules run daily, weekly or monthly — including patterns like the second Tuesday plus an offset — and hourly cadences are available through the API.
How are reboots handled?
Explicitly, per ring: reboot if required, never reboot, or always reboot. Never-reboot rings are honest about the consequence — an update that needs a restart stays pending, and the compliance view shows it. Where you want fewer reboots rather than deferred ones, Windows Server 2025 machines connected through Arc can use hotpatch, which installs most monthly security updates without restarting and, as of May 2026, carries no additional Microsoft charge; it needs virtualization-based security on and is an optional deliverable in this engagement.
How risky is the cutover?
Lower than a WSUS server upgrade, because nothing is cut over all at once. WSUS stays running while the pilot ring patches on Update Manager, servers are released from the WSUS policy ring by ring with a documented way back, and WSUS is shut down only after the first production cycle succeeds — and even then with a rollback window before removal. Installing the Arc agent does not reboot a server or touch workloads. The only activities with real change impact are the scheduled patch cycles themselves, inside windows you approve.
Can Update Manager patch our workstations too?
No — Microsoft's documentation is direct that Update Manager does not manage client devices, and Microsoft's direction for Windows 10 and 11 is Intune and Windows Autopatch. Organizations replacing one WSUS for everything usually end up with two engagements: this one for servers and the Windows Autopatch Implementation for the fleet, with the Managed Microsoft Intune Service running the client side afterwards. We are happy to scope both, but we will not pretend one tool covers both.
Who runs patching after the two weeks?
Your team, equipped for it — the runbook and handover cover adding a server to a ring, changing a window, excluding a KB, reading compliance and acting on an alert, and Azure Policy keeps new servers from slipping through unscheduled. If you would rather have it operated, the Managed ESU and Legacy Server Lifecycle service takes the legacy estate and Azure Resource Monitoring and Maintenance takes the Azure side, each as an explicit separate engagement. We do not bundle a retainer into an implementation.