Hotpatch and cluster-aware updating for Windows Server

Servers fall behind on patches for one main reason: restarting them costs something. A monthly reboot of a database, a file server or a line-of-business application needs a window, an owner and a rollback plan, and every month someone has a reason to skip it. The patching pillar sets targets for servers; this guide covers the two Windows Server features that make those targets realistic by reducing or hiding downtime: hotpatch and cluster-aware updating (CAU).

How hotpatch works

A hotpatch updates code in memory for running processes, and on disk for the next start, without a restart. Microsoft ships hotpatches on a quarterly cycle:

A hotpatched server is fully patched for security; it is not "partially" updated. The trade-off is that non-security fixes wait for the next baseline, and anything outside the OS cumulative update (drivers, firmware, .NET, third-party software) still follows its normal process and may restart the server.

Step 1: check eligibility

Hotpatch depends on edition, location and security features:

• Windows Server 2022 or 2025 Datacenter: Azure Edition on Azure VMs or Azure Local. Hotpatch is included and managed through Azure Update Manager.
• Windows Server 2025 Standard or Datacenter (build 26100.1742 or later, Desktop Experience or Server Core) on physical or virtual machines outside Azure, connected to Azure Arc, with Hotpatch enabled on the Arc resource. Since May 2026 this costs nothing extra; before that it was a paid per-core subscription.
• Virtualization-based security must be running, so the machine needs UEFI with Secure Boot (on Hyper-V, a Generation 2 VM). Hotpatch relies on VBS to protect the patching process, which also makes it a good companion to VBS and memory integrity.
• The server must be on the current baseline; a machine that misses a baseline can't take the following hotpatches and falls back to full cumulative updates until it catches up.

Windows 11 Enterprise 24H2 and later can also receive hotpatches through Windows Autopatch in Intune. That client program has its own licensing and device prerequisites, separate from the server model described here.

Check VBS on a candidate server:

Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning
# VirtualizationBasedSecurityStatus = 2 means VBS is running

If VBS is off, enable it through Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, test the workload (some older drivers and hypervisor-dependent tools object), then restart.

Step 2: enrol servers

Azure VMs with Azure Edition: choose a hotpatch-capable image and, in the VM's patch settings, use Azure-orchestrated patching with hotpatch enabled. Azure Update Manager then schedules baselines and hotpatches for you.

Arc-connected Windows Server 2025: onboard the machine to Azure Arc with the Connected Machine agent, then in the Azure portal go to Azure Arc > Machines, open the machine, select Hotpatch and then Confirm. The change applies in about 10 minutes (the portal checks that VBS is running and fails otherwise). The server then receives hotpatches from the next hotpatch month, provided it is on the current baseline. Use Azure Update Manager or your existing tool to schedule the baseline restarts.

Arc onboarding gives an Azure identity to an on-premises server. Treat the onboarding service principal and the Arc resource permissions as privileged: a role that can run commands or install extensions on Arc machines is effectively administrative on those servers. Scope Azure RBAC with the same care you apply to admin tiering, and never onboard domain controllers into a subscription managed by lower-tier admins.

Step 3: plan the patch calendar around baselines

With hotpatch, the monthly plan changes shape:

• Baseline months: the same process as today. Patch groups, maintenance windows, application owners on call. Schedule these windows a year ahead since the months are fixed.
• Hotpatch months: install within days of Patch Tuesday, across all eligible servers at once if your testing allows, since there is no restart to coordinate. Keep a small pilot group a day or two ahead.
• Unplanned baselines: keep a standing emergency window procedure so an out-of-cycle baseline doesn't wait for next quarter.

Separate hotpatch-enrolled servers from others in reporting. A server that silently fell off the hotpatch track and now needs a restart each month is easy to miss.

Step 4: cluster-aware updating for clustered roles

For failover clusters (Hyper-V hosts, file servers, SQL Server failover cluster instances), CAU automates the rolling pattern: drain one node, move its roles, install updates, restart, resume, move to the next node. It works with or without hotpatch and is part of the Failover Clustering feature (ClusterAwareUpdating module).

Check readiness first, then add the CAU clustered role in self-updating mode:

Test-CauSetup -ClusterName FS-CLU01

Add-CauClusterRole -ClusterName FS-CLU01 `
  -DaysOfWeek Tuesday -WeeksOfMonth 3 `
  -MaxFailedNodes 0 -MaxRetriesPerNode 2 -RequireAllNodesOnline `
  -EnableFirewallRules -Force

Key parameters:

• -RequireAllNodesOnline refuses to start if a node is already down, so an update run never reduces a degraded cluster further.
• -MaxFailedNodes 0 stops the run at the first failed node instead of carrying on.
• -PreUpdateScript and -PostUpdateScript run your own checks, for example confirming a SQL availability group is healthy before the next node goes.
• The default plug-in, Microsoft.WindowsUpdatePlugin, uses the Windows Update Agent and whatever source the nodes are configured for (Windows Update, WSUS). Microsoft.HotfixPlugin installs packages from a file share you control.

To run once on demand, from a management machine rather than a cluster node:

Invoke-CauScan -ClusterName FS-CLU01 -CauPluginName Microsoft.WindowsUpdatePlugin
Invoke-CauRun  -ClusterName FS-CLU01 -CauPluginName Microsoft.WindowsUpdatePlugin `
  -MaxFailedNodes 0 -RequireAllNodesOnline -Force

The CAU computer object and the account running remote updating mode have administrative access to every node. Place the cluster and its management machine in the right tier, and keep CAU's firewall rules scoped to the management network (see firewall hardening).

Azure Local clusters use their own lifecycle manager for OS, driver and firmware updates; follow that process there rather than configuring CAU directly.

Step 5: keep the rest of the server current

Hotpatch and CAU handle the OS cumulative update. The other layers still need their own process:

• Firmware and drivers: vendor tools (for example the server vendor's update suite) on the baseline-month schedule, so their restarts coincide with the one you already have. BitLocker-protected servers may need protection suspended for one restart.
• .NET and other Microsoft products: allow Microsoft Update in your update source; .NET updates usually need a restart of the applications that use them, sometimes of the server.
• Server roles and applications: SQL Server cumulative updates, Exchange, IIS modules and third-party agents follow vendor schedules. Align them with baseline months where you can.
• Hyper-V hosts: guests benefit from hotpatch only if the guest OS is eligible; the host restart still moves or pauses VMs, which is where CAU helps.

The goal is one planned restart per quarter that absorbs everything, rather than several unplanned ones.

Verify it

On a server, check the build revision and the update history:

$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
'{0}.{1}' -f $cv.CurrentBuild, $cv.UBR
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, Description, InstalledOn
(Get-CimInstance Win32_OperatingSystem).LastBootUpTime

A hotpatched server shows a new build revision while LastBootUpTime stays at the last baseline. Compare the revision with the one listed in Microsoft's release notes for the month's hotpatch. Install results are in the System log from Microsoft-Windows-WindowsUpdateClient (event 19 success, 20 failure). In Azure Update Manager, the machine's update history shows hotpatch and baseline installs separately.

For CAU, review the last run and the event logs:

Get-CauReport -ClusterName FS-CLU01 -Last -Detailed
Get-WinEvent -LogName 'Microsoft-Windows-ClusterAwareUpdating/Admin' -MaxEvents 20

What breaks

• VBS disabled by a driver or a BIOS change. The server quietly stops being hotpatch-eligible. Monitor VirtualizationBasedSecurityStatus.
• Missed baseline. A server that skips the quarterly restart drops back to full cumulative updates. Treat baseline windows as mandatory.
• Manual cumulative update installs. Installing a standalone package out of sequence can take a machine off the hotpatch track; let the orchestration tool install updates.
• CAU runs that stall on a node that won't drain, often because of a role with preferred owners or a VM that can't live-migrate. Fix the cluster health issue; don't raise MaxFailedNodes.
• Clusters patched both by CAU and by another tool. Two orchestrators restart nodes independently and can take down quorum. Exclude clustered nodes from client-style ring policies such as Windows Update policies.

Checklist

• Server estate classified: Azure Edition, Arc-connected 2025, not eligible
• VBS running and monitored on hotpatch candidates
• Arc onboarding identity and RBAC scoped as privileged access
• Baseline windows scheduled for January, April, July and October
• Hotpatch months installed within days, pilot group first
• Clusters updated by CAU with RequireAllNodesOnline and MaxFailedNodes 0
• Pre- and post-update health scripts for critical clustered roles
• Reporting separates hotpatched, baseline-only and non-compliant servers

Hotpatch and CAU remove the restart objection for most servers. The rest of the process, from rings to third-party software, is in the patching and updates area.