Windows Server 2025 Hotpatching Troubleshooting (2026): Azure Arc, Baseline Updates & Reboot-less Patch Failures
Fix Windows Server 2025 hotpatch failures the way I do in production: Azure Arc enrollment checks, baseline drift diagnostics, WSUS/WUfB conflicts, and clean rollback steps with PowerShell and CBS.log queries.
Windows Server 2025 hotpatching applies most monthly security updates to a running kernel without a reboot, but it only works when the server is Azure Arc-connected (or Azure IaaS), subscribed to the hotpatch channel, and running a baseline that is still inside its 60-day support window. If any of those three preconditions drift, the March/June/September/December "baseline" months quietly turn back into full cumulative updates, hotpatches roll over as "Not applicable", and users start losing the reboot-less experience they were promised. Honestly, I hit this exact drift shipping a small on-prem fleet last quarter, so this guide is the runbook I keep coming back to when a Server 2025 fleet stops hotpatching cleanly.
Hotpatch on Windows Server 2025 (Standard, Datacenter, Datacenter: Azure Edition) is GA as a paid subscription outside Azure (about $1.50 per core per month, billed via Azure Arc).
Enrollment fails silently when AzureConnectedMachineAgent is missing, the machine has no outbound HTTPS to *.his.arc.azure.com, or the Hotpatch resource provider is not registered on the subscription.
The yearly cadence is 8 hotpatch months + 4 baseline (reboot) months (Jan, Apr, Jul, Oct). Miss a baseline by more than 60 days and the device drops back to standard LCUs.
The authoritative log for hotpatch install state is %windir%\Logs\CBS\CBS.log plus WU client events in Microsoft-Windows-WindowsUpdateClient/Operational; use Get-HotFix plus Get-WindowsPackage to confirm the KB is truly staged.
Common blockers are Windows Update for Business (WUfB) policy conflicts, mismatched update rings between WSUS/Intune and Azure Update Manager, and Hyper-V / Credential Guard combinations that force a full servicing stack refresh.
You can roll back a hotpatch with wusa /uninstall /kb:<id>, but the server drops out of the hotpatch train until the next baseline; plan the rollback window accordingly.
How Windows Server 2025 hotpatching actually works
Hotpatch isn't a new patch delivery pipeline; it's a new payload format. The Windows Update Agent still downloads the KB, and CBS (Component-Based Servicing) still stages it. The difference is that a hotpatch package contains a set of function-level binaries the running kernel can splice in via the hot-patching runtime, so the servicing stack does not need to swap the on-disk file, reload drivers, or rewrite MpsSvc memory. That is why the machine keeps its uptime.
The catch is that this only works for a subset of the security surface, so Microsoft still ships one full cumulative update (a "baseline") every three months. Between baselines, the hotpatch packages carry every fix the baseline would have carried, minus the ones that need a boot to land. First a baseline, then two hotpatch months, then a baseline, and so on. When the year ends you should have four reboots and eight quiet months, assuming nothing else forces a restart.
Under the hood, three things must be true for a device to be on the hotpatch train:
The OS is Windows Server 2025 (Standard, Datacenter, or Datacenter: Azure Edition) with the Desktop Experience or Server Core install. Nano and 20H2-style installs are out of scope.
The device is enrolled in the Hotpatch policy in Azure Update Manager, either directly for Azure VMs or through the Azure Connected Machine Agent for on-prem/other-cloud servers.
Windows Update for Business is not overriding the update source with a conflicting WSUS or "Pause updates" GPO. This quietly demotes the device to standard LCUs.
If any of those slip, you will see hotpatches marked as NotApplicable in the WU history even though the KB looks correct. The good news? All three are diagnosable from the machine itself with a bit of PowerShell.
Hotpatch vs cumulative update: what changes each month
Before we start troubleshooting, it helps to know exactly which knobs move each month. The table below is the mental model I keep taped to the ticket queue.
Attribute
Hotpatch month
Baseline (LCU) month
Cadence
8 per year
Jan, Apr, Jul, Oct (4 per year)
Reboot required
No
Yes
KB naming
KB50xxxxx, labelled "Hotpatch"
Standard LCU + Servicing Stack Update
Payload
Function-level binary diff
Full component payload
Backing store growth
Minimal (< 200 MB)
500 MB – 1.5 GB (WinSxS)
Uninstall path
wusa /uninstall before next boot
DISM package removal
Missed window impact
Rolls into next baseline
Blocks hotpatch train until installed
Cost outside Azure
~$1.50 / core / month
Included in Software Assurance
The two behaviours that trip helpdesk teams most: (1) a "hotpatch" KB may still trigger a reboot if a co-required servicing stack update is bundled. Microsoft flags this in the KB release notes as a "hotpatch reboot exception". (2) On Datacenter: Azure Edition VMs, hotpatch is included in the SKU; on Standard/Datacenter you must have an active hotpatch subscription in your Azure billing account or the client returns error 0x800705B4 ("time out") during evaluation. If you are migrating from Windows Server 2022 Azure Edition, review the Windows Autopatch troubleshooting guide for the client-side hotpatch flow (the concepts are similar, but the enrollment surface is different).
Azure Arc prerequisites and enrollment failures
For any Server 2025 host that is not an Azure VM, hotpatch lives behind Azure Arc. That means the Azure Connected Machine Agent (azcmagent) must be installed, running as himds, and heartbeating to your Arc resource in Azure. Onboarding is usually a one-liner, but it can drop you into three failure modes that all look the same in the portal (agent shows Connected, hotpatch stays off).
1. Missing outbound endpoints
The agent needs HTTPS 443 to a specific set of Microsoft endpoints. In restricted networks I always run the reachability check first:
If *.his.arc.azure.com, *.guestconfiguration.azure.com, or login.microsoftonline.com come back as unreachable, hotpatch will never enable, because the enrollment call is proxied through the Hybrid Instance Metadata Service (HIMDS). Add these to the proxy allowlist or the firewall rule set. Microsoft publishes the full list in the Azure Arc network requirements documentation.
2. Resource provider not registered
The subscription that owns the Arc machine must have Microsoft.Compute, Microsoft.HybridCompute, and Microsoft.Maintenance registered. If you are the tenant owner, this takes 30 seconds:
az provider register --namespace Microsoft.Compute
az provider register --namespace Microsoft.HybridCompute
az provider register --namespace Microsoft.Maintenance
az provider show -n Microsoft.Maintenance --query registrationState
If registrationState comes back as Registering, wait 5 minutes and re-check. If it stays there beyond 15 minutes, your tenant likely has a policy blocking the provider. That's an Azure RBAC ticket, not a Windows one.
3. Hotpatch license assignment missing
Even after Arc is happy, hotpatch itself is a separate SKU for Standard/Datacenter. In the Azure portal, open the Arc machine, go to Licenses, and assign an active Windows Server Management licence with the Hotpatch add-on. If the licence is missing, Get-WindowsUpdate shows the hotpatch KB as available but installation returns 0x8007000E.
Why is my Windows Server 2025 hotpatch not applying?
This is the ticket I see most often. The KB is published, the server is Arc-connected, but the WU history says NotApplicable or Failed with 0x800f0922. The diagnostic sequence I run, in order:
Confirm SKU and build. Hotpatch requires build 26100.x or later:
Confirm hotpatch enrollment. This should return Enrolled:
Get-WindowsUpdateSetting | Select-Object HotpatchEnrollmentStatus
# or, if that cmdlet is unavailable on your build:
reg query "HKLM\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" /v HotpatchEnrolled
Event ID 20 with error 0x8024402C means WU cannot reach the update source; combined with an "Enrolled" status this almost always points at a WSUS override. See the WSUS section below.
Check for a pending reboot from a prior baseline. Hotpatches will not stage on top of an un-committed cumulative:
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"
If either returns True, reboot into the pending baseline first. This is the single most common cause of hotpatches sitting in NotApplicable forever.
Inspect CBS.log. Look for the last PSF (patch storage file) entry:
Errors that mention CBS_E_HOTPATCH_BASELINE_MISMATCH mean your machine has drifted off the current baseline; jump to the next section.
Baseline months, the 60-day window, and re-syncing
Every device on the hotpatch train has a "current baseline" tag stored in the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Servicing\Hotpatch\Baseline. Microsoft supports hotpatches against the current baseline plus one prior (roughly a 60-day grace window). Beyond that, the machine is considered "out of train" and only cumulative updates apply.
The two things that push a machine out of the window:
Missed baseline install. The device rebooted after the baseline was released but was not connected to WU at the time (e.g., it was in maintenance mode). The next hotpatch scan sees "expected baseline vNext, found vN-1" and returns NotApplicable.
Baseline install failed and rolled back. A pending .NET or servicing stack update blocked commit; the LCU rolled back on reboot; the hotpatch runtime now refuses to splice on top of a non-committed base.
The fix in both cases is to install the latest baseline manually and reboot. You can pull it directly from the Microsoft Update Catalog. Search for the current Server 2025 cumulative and grab the .msu:
After the reboot, run a fresh scan. Within an hour the device should re-enrol against the new baseline and the next hotpatch will apply cleanly. If you manage a large fleet, I generally schedule baseline months as a real maintenance window rather than trying to be clever with staged rings. The 4 reboots a year are the point of the deal.
WSUS, WUfB and Azure Update Manager conflicts
If your Server 2025 hosts also happen to be dual-scanned by WSUS or Configuration Manager (SCCM) alongside Azure Update Manager, hotpatch will fight the local WU policy and lose. The precedence rules are subtle: Group Policy WUfB settings win over MDM, but Azure Update Manager writes its own MDM policy through Arc, which can silently be reverted by the domain GPO next refresh.
Two GPO settings I always check first:
Computer Configuration → Administrative Templates → Windows Components → Windows Update → Specify intranet Microsoft update service location. If this points at WSUS, hotpatches will not be offered. WSUS does not sync hotpatch KBs on the standard classification list. Either add the "Windows Server 2025 Hotpatch" classification (available in WSUS 6.4+ on Server 2025) or exempt hotpatch-enrolled OUs from this GPO.
Do not connect to any Windows Update Internet locations. If this is Enabled, WU will refuse to reach Microsoft Update even when directed to by Azure Update Manager. Disable it on any OU containing Arc-managed servers.
For Intune-managed servers (yes, this exists in 2026 via the "Windows Server management for Intune" preview), the equivalent CSP path is ./Device/Vendor/MSFT/Policy/Config/Update/. Make sure DoNotConnectToWindowsUpdateInternetLocations is not set to 1. My rule of thumb: pick one update authority per server and stick with it. Mixed scanning is a swamp.
Force a re-scan after policy changes
# Refresh policy then force a full WU scan and evaluate
gpupdate /force
Stop-Service wuauserv
Remove-Item -Path C:\Windows\SoftwareDistribution\* -Recurse -Force -ErrorAction SilentlyContinue
Start-Service wuauserv
UsoClient StartInteractiveScan
UsoClient RefreshSettings
Wait ~10 minutes for the scan to finish, then check WU history. If the hotpatch still says NotApplicable, the CBS.log will now contain a fresh evaluation trace. Grep it for Update.*Applicability.
How do I roll back a Windows Server 2025 hotpatch?
Rollback is a real thing, and the workflow depends on whether the machine has rebooted since the hotpatch installed. Before the next reboot, the hotpatch lives in memory only. After it, CBS has committed the payload to disk.
The uninstall runs immediately and reverts the in-memory splice; no reboot required. This is the fastest rollback path if a hotpatch is causing a specific bug (I have used it for a nasty MpsSvc regression in early 2026).
After a reboot (committed to disk)
Now you need DISM to remove the package cleanly:
# List installed packages, filter for the hotpatch
DISM /Online /Get-Packages /Format:Table | findstr /I "Hotpatch"
# Remove the specific package
DISM /Online /Remove-Package /PackageName:Package_for_Hotpatch~31bf3856ad364e35~amd64~~10.0.26100.xxxx /NoRestart
# Reboot to fully unwind
shutdown /r /t 300 /c "Hotpatch rollback"
Logs, event IDs and PowerShell for verification
Hotpatch state is scattered across CBS, WU client, and the Azure Connected Machine Agent. Here are the exact paths and queries I keep in my runbook, sorted by "where the failure usually shows up first".
44/45: Update downloaded / started installing. Missing 45 after 44 usually means CBS blocked the install because of a baseline mismatch.
Azure Connected Machine Agent state
azcmagent show
# Look for: Agent Status: Connected
# Machine Name matches Azure resource
# Assigned identity is set
If Agent Status is Disconnected or Expired, hotpatch enrollment will not renew. Re-authenticate the agent with azcmagent connect before doing anything else. The rest of your troubleshooting is moot if Arc can't talk to Azure.
Does Windows Server 2025 hotpatch require Azure Arc?
Yes for any server that is not an Azure VM. Arc is the enrollment surface and the licensing gate. The Connected Machine Agent must be installed, connected, and assigned a Windows Server Management licence with the Hotpatch add-on. Azure IaaS VMs are exempt because they already have the equivalent metadata channel.
How much does Windows Server 2025 hotpatching cost outside Azure?
Roughly $1.50 per physical core per month, billed through Azure Arc. There is no minimum core count, but the licence attaches to the server, not the fleet, so multi-socket hosts add up quickly. Datacenter: Azure Edition VMs include hotpatch at no extra charge.
Do hotpatches ever require a reboot?
Almost never within a hotpatch month, but two exceptions exist. First, servicing stack updates that ship alongside a hotpatch package will force a reboot. Second, if the machine has drifted more than 60 days off its current baseline, the next hotpatch is downgraded to a full LCU which does require a restart.
Why does my hotpatch show "NotApplicable" in Windows Update history?
The three usual culprits: a pending reboot from a previous baseline that has not been committed, a WSUS/GPO override pointing WU at an update source that does not carry hotpatch KBs, or an out-of-window baseline that pushes the device off the hotpatch train. The CBS.log lines starting with CBS_E_HOTPATCH tell you which one you are hitting.
Can I use WSUS to distribute hotpatches?
Yes, but only on WSUS 6.4 or later on Windows Server 2025 with the "Hotpatch" classification enabled during sync. Older WSUS versions will silently drop hotpatch KBs from the metadata sync. If your WSUS server is on Server 2019 or 2022, plan a migration to Server 2025 or route hotpatch-enrolled servers through Azure Update Manager instead.
Troubleshoot Intune Remote Help licensing, RBAC scopes, EPM elevation, and session errors. Real KQL, PowerShell, and network fixes from a helpdesk lead.
Close AVD tickets faster in 2026 with PowerShell, KQL, and portal steps for session host registration, RDP Shortpath, Entra ID join, FSLogix, App Attach, and autoscale plans.
The four buckets that cover 90% of Teams Rooms tickets in 2026: resource-account sign-in, console pairing, PMP signal alerts, and auto-update ring stalls. A helpdesk manager's runbook with copy-paste PowerShell.
