Azure Arc and Azure Update Manager: The WSUS Replacement for Hybrid Patch Management

Azure Arc is becoming the practical replacement many enterprises need after Microsoft signaled the deprecation of Windows Server Update Services (WSUS), and for organizations that want to centralize patching across on-premises servers and Azure VMs the recommended route is to Arc‑enable servers and leverage Azure Update Manager. (techcommunity.microsoft.com)

Background​

Microsoft announced in September 2024 that WSUS is deprecated, meaning Microsoft will no longer add new features to WSUS while preserving its current functionality and support for published updates. The guidance from Microsoft is explicit: plan to move server update management toward cloud options such as Azure Update Manager, Windows Autopatch, or Microsoft Intune for clients. This shift forces organizations to reassess long‑running WSUS-based processes and to consider hybrid tools that operate through a single control plane. (techcommunity.microsoft.com)
At the same time, Azure Arc — first released in late 2019 — has matured into a practical hybrid control plane. Azure Arc lets you register and manage on‑premises physical servers and VMs (and Kubernetes clusters) from the Azure portal and extend cloud services such as Azure Monitor, Azure Policy, and Azure Update Manager to those resources. The basic Arc control plane features (tagging, resource graph, RBAC, templates) are available at no charge; additional cloud services consumed through Arc will incur the normal Azure pricing for those services. (learn.microsoft.com)
This article synthesizes vendor guidance, hands‑on tutorial notes, and operational best practices to give Windows Server administrators a single, actionable feature article covering Azure Arc onboarding, Azure Update Manager patch workflows, cost considerations, networking and security constraints, and operational pitfalls to avoid — all built on official documentation plus the practical details included in the provided tutorial. (learn.microsoft.com)

---

Why Azure Arc + Azure Update Manager is the practical WSUS alternative​

Hybrid enterprises historically run dual patch systems: WSUS or SCCM/ConfigMgr in the data center, and cloud‑native tools for Azure workloads. That model increases operational friction, duplicates reporting, and complicates compliance proofs. Arc + Azure Update Manager addresses those pain points by offering:

• A single control plane for inventory, policy and update compliance across Azure and on‑premises resources.
• The ability to use the Azure Update Manager to schedule updates, run forced assessments, and orchestrate maintenance windows for Arc‑enabled machines.
• Unified RBAC and Azure Policy to enforce configuration and compliance settings across both environments.
• Integration points with Azure Monitor, Defender for Cloud, and Windows Admin Center for richer operational tooling.

Those advantages come with trade‑offs (network egress, service charges for certain features, and increased dependency on cloud identity), but for many organizations the reduced complexity and tighter integration win out. The Arc control plane itself is free; Azure Update Manager incurs charges for Arc‑enabled servers except in certain scenarios (detailed in the pricing section below). (learn.microsoft.com)

---

Overview: How Arc patching works (simple flow)​

• Arc‑enable a server by installing the Azure Connected Machine agent (aka the Connected Machine agent or CMA).
• The server registers as an Arc resource in your Azure subscription and appears in the Arc Machines inventory.
• From the Azure portal, use Azure Update Manager to discover missing updates, schedule maintenance windows, or push immediate patches.
• Monitor compliance and logs via the Update Manager dashboard, Azure Monitor, or third‑party tools that read Azure resource data.

The agent communicates outbound to Azure over HTTPS (TCP/443), and there is no requirement to create a site‑to‑site VPN as long as the machine has Internet access (or can reach the required Azure endpoints via proxy). That simplicity is one of the major operational attractions of Arc for on‑premises servers. (learn.microsoft.com)

---

Pricing and licensing — what to expect and how to plan​

Cost is often the chief concern when moving from a free on‑premises product (WSUS) to cloud services. Microsoft’s published pricing and FAQ documents make the billing model transparent but nuanced:

• Azure Arc control plane functionality (resource organization, resource graph, RBAC, basic templates) is offered at no extra cost. However, any Azure services used via Arc (Monitor, Defender, Update Manager, etc.) are billed as those services normally are. (learn.microsoft.com)
• Azure Update Manager (for Arc‑enabled servers) is charged $5 per Arc‑enabled server per month (prorated daily at approximately $0.16/day assuming 31 days) for non‑Azure VMs. Azure VMs are not charged for Update Manager. The $5/month rate is Microsoft’s published calculation. Check your Azure region and reservation/offer as prices shown in the portal can vary by currency and agreement. (learn.microsoft.com, azure.microsoft.com)
• Free scenarios for Azure Update Manager include:
• Arc‑enabled machines that are covered by Extended Security Updates (ESUs) enabled through Arc.
• Subscriptions with Microsoft Defender for Servers Plan 2 enabled (this may include Update Manager entitlements).
• Machines licensed using Windows Server with active Software Assurance or Windows Server pay‑as‑you‑go licensing (specific entitlements depend on your licensing terms). (learn.microsoft.com)

Important planning notes:

• The $5/month figure is Microsoft’s published guidance and is the most load-bearing pricing statement for planning. Validate costs in Azure Pricing Calculator and confirm entitlements with your Microsoft account team. Prices, promotions, and partner offers can change; treat the $5/month as the baseline planning figure and build a verification step into procurement. (learn.microsoft.com, azure.microsoft.com)

---

Step‑by‑step: Onboard a single on‑premises server via the Azure portal​

The portal onboarding flow is friendly for smaller fleets or for pilots. Summary of the typical steps:

• Sign in to the Azure portal and open Azure Arc > Add resources > Machines.
• Choose Add a machine and then Add a single server with installer (the portal also offers bulk onboarding options).
• Download the Windows or Linux installer that the portal prepares. Copy the installer to the target server (or run the command the portal generates on the machine).
• Run the installer on the target server; the installer will authenticate you with Azure (or you can supply a service principal) and will register the machine as an Arc resource.
• Once completed the server appears under Arc > Machines and can be managed with Azure Update Manager, Azure Policy, and other Arc extensions.

Operational tips from practice:

• The portal installer provides a gated interactive flow; for unattended or large fleets, use PowerShell or the CLI (see next section).
• After onboarding, the server will report its connectivity and status to the portal. Expect a short delay for the portal to surface inventory and update data — the tutorial test found the Update Manager dashboard could take around 30 minutes to reflect a fresh update cycle. Account for this window in automation and troubleshooting workflows to avoid unnecessary interventions.

---

Scripted onboarding: PowerShell commands and automation​

For scale and repeatability, PowerShell is the preferred path for many organizations:

• Install the required PowerShell module:
• Install-Module -Name Az.ConnectedMachine
• Sign in to Azure:
• Connect-AzAccount
• Install the Connected Machine agent and create the Arc resource:
• Connect-AzConnectedMachine -ResourceGroupName <myResourceGroup> -Name <myMachineName> -Location <region>

The Connect-AzConnectedMachine command downloads and installs the agent on the machine, creates the Arc resource in the specified resource group, and associates the agent with Azure. You can add the -Proxy parameter if onboarding must use an HTTP proxy. Expect the onboarding process to take a few minutes to complete. (learn.microsoft.com)
Automation best practices:

• Use Managed Identities or a service principal for unattended runs and avoid interactive credentials in scripts.
• Create per‑region resource groups and standard tags (environment, owner, app) so you can control costs and apply policies consistently.
• Log the full installer output to a central place; the agent logs are written to %ProgramData%\AzureConnectedMachineAgent\Log on Windows and /var/opt/azcmagent/log/ on Linux for troubleshooting. (learn.microsoft.com)

---

Networking and firewall checklist​

Azure Arc’s design intentionally minimizes inbound firewall dependencies: the Connected Machine agent makes outbound connections over HTTPS (TCP/443) to Azure endpoints. That means no inbound ports need to be opened for normal Arc management.
Key network considerations:

• Allow outbound HTTPS (443) to Azure service endpoints and the service tags Azure publishes (e.g., AzureArcInfrastructure, AzureResourceManager, AzureActiveDirectory). For strict firewall environments, allowlisting service tags is recommended rather than static IPs because Azure IP ranges change. (learn.microsoft.com)
• If using a proxy, configure the agent during onboarding (the agent supports proxies); the Microsoft docs provide explicit guidance for the -Proxy parameter in the PowerShell onboarding command. (learn.microsoft.com)
• For private‑link or highly restricted deployments, Azure Arc offers Private Link Scopes and gateway patterns that reduce public egress surface, but note that some endpoints still require public Internet access; consult the Azure Arc network requirements for a definitive endpoint list. (learn.microsoft.com)

Security note: outbound HTTPS means all traffic is encrypted, but you still must treat egress as sensitive traffic. Use TLS 1.2+ as a baseline, maintain endpoint allowlists under change control, and monitor egress traffic for anomalous patterns.

---

Managing patch lifecycle in Azure Update Manager​

Once a server is Arc‑enabled it will show up in Azure Update Manager’s Machines view. Typical patch lifecycle actions:

• Run an assessment (Check for updates) to report missing patches and compliance state.
• Enable automatic updates on a per‑machine basis or create a scheduled deployment.
• Schedule maintenance windows (maintenance window start/end, reboot behavior).
• Use deployment rings and phased rollouts (pilot -> broader) to limit blast radius.

Practical operational notes:

• The portal indicates when a machine lacks update data and offers an Enable Now action or immediate assessment; use the enable flow as part of baseline onboarding to ensure machines participate in future scans.
• Expect dashboard synchronization to lag: the tutorial observed roughly a 30‑minute delay from the update job start until the Update Manager dashboard refreshed the VM’s status. Build that delay into monitoring processes and compliance verification to prevent false positives or redundant runs.

---

Security, identity and access controls​

Arc depends on Azure identity and Azure RBAC. Enforce these operational controls:

• Use Azure RBAC to limit who can onboard machines, create update deployments, or define policies. The Arc control plane is integrated with RBAC and supports scoped roles.
• Prefer least privilege service principals for automation and use conditional access policies to protect high‑risk operations.
• Pair Arc with Azure Policy and Change Tracking to detect drift and unauthorized configuration changes.
• Consider Defender for Cloud (formerly Microsoft Defender for Servers) for enhanced threat detection on Arc‑enabled hosts — note Defender licensing can influence Update Manager billing entitlements. (learn.microsoft.com)

---

Governance, compliance, and reporting​

Azure Update Manager and Arc feed into Azure’s resource graph and monitoring tools. Recommended governance checklist:

• Standardize and enforce tags and resource groups on onboarding to make cost and compliance reporting useful.
• Use Azure Policy initiatives as guardrails (security baselines, allowed extensions, required diagnostics settings).
• Regularly export Update Manager compliance data into a SIEM or centralized database for long‑term reporting and audit trails.
• Keep a documented rollback and recovery playbook for each patch ring; test recovery procedures in a dev/lab environment before production rollout.

---

Operational pitfalls and troubleshooting​

• Delayed status updates: the Update Manager dashboard can lag — the tutorial observed roughly 30 minutes of delay between the patch action and the portal reflecting the final status. Build slack into automation and incident response processes.
• Proxy and firewall misconfigurations: missing allowlist entries or blocked Azure service tags will prevent agent onboarding or periodic assessments; use Microsoft’s published endpoint and service tag lists and prefer service tags in firewall rules. (learn.microsoft.com)
• Misunderstood billing: if you assume Arc control plane is free and forget Update Manager charges for Arc servers, your bill can surprise you. Use tagging to track Update Manager consumption and tie Arc resources to a billing resource group or cost center. (learn.microsoft.com)
• Mixed tooling drift: if you continue running WSUS alongside Update Manager without a clear migration and cutover plan, patch approval state and compliance reporting will diverge. Define a cutover strategy: pilot -> housecleaning -> phased migration -> decommission WSUS roles when safe. (techcommunity.microsoft.com)

---

Migration playbook: recommended step sequence​

• Inventory: map current WSUS/SCCM scope, approval rules, maintenance windows, and reporting needs.
• Pilot: choose a non‑critical ring (e.g., dev/test) and Arc‑enable a small number of servers; evaluate Update Manager workflows and portal delays.
• Policy: implement Azure Policy and RBAC for Arc onboarding and update deployments.
• Phased rollout: move mission‑critical systems to a staged model with clear rollback points.
• Decommission: when stable, migrate approval processes and data retention from WSUS to Azure Update Manager and retire WSUS servers in a controlled fashion.
• Audit: run a compliance audit and produce a report showing parity between old WSUS reports and new Update Manager reports.

---

When Arc may not be the right answer​

• Air‑gapped or strictly isolated systems that cannot connect to Azure endpoints without lengthy architecture changes.
• Organizations with contractual restrictions on cloud management for certain regulated workloads (though Azure Private Link and hybrid architectures can sometimes mitigate this).
• Very small shops that prefer a zero‑ongoing‑cost model and are comfortable with WSUS for the long term (WSUS remains supported for in‑market OS versions but receives no new features). (techcommunity.microsoft.com)

---

Final best practices (quick checklist)​

• Test first: pilot Arc and Update Manager on non‑critical servers to confirm networking, identity and update behavior.
• Tag early: attach cost and compliance tags at onboarding to track Update Manager usage.
• Document windows: include Update Manager dashboard lag (~30 min observed) in runbooks.
• Harden connectivity: allow outbound 443 to AzureArcInfrastructure, AzureResourceManager and related service tags; use Private Link Scopes for higher security where feasible. (learn.microsoft.com)
• Validate licensing: verify if Defender for Servers Plan 2 or existing Windows Server licensing entitles you to Update Manager inclusion to offset per‑server charges. (learn.microsoft.com)

---

Conclusion​

The deprecation of WSUS changes the calculus for server patch management and pushes organizations to cloud‑centric and hybrid solutions. Azure Arc plus Azure Update Manager offers a realistic path to unify on‑premises and cloud patching under one control plane, with strong operational integration and clear tooling paths for automation. There are real costs, networking demands, and governance changes to manage — but for enterprises with hybrid footprints the operational benefits (single inventory, Azure RBAC, integrated reporting) make Arc a strategic and practical replacement for WSUS‑centric workflows. Administrators should pilot, plan for the modest Update Manager charges for Arc servers, and build the network and identity checks into onboarding scripts. The tutorial steps — portal onboarding, PowerShell automation, and the hands‑on notes about dashboard lag — provide an approachable blueprint to begin the migration and reduce the friction of moving from WSUS to a modern, hybrid update model. (techcommunity.microsoft.com, learn.microsoft.com)
Cautionary note: pricing, entitlements, and endpoint behavior can change. Always verify your current agreement in the Azure portal and consult Microsoft documentation for the latest guidance before wide deployment. (azure.microsoft.com, learn.microsoft.com)

---

Source: TechTarget Azure Arc setup tips for on-premises server management | TechTarget