Windows Autopatch Troubleshooting (2026): Fix Device Readiness, Hotpatch Errors & WSUS Migration

Updated: June 28, 2026

Windows Autopatch troubleshooting in 2026 almost always begins with one of three root causes: a legacy WSUS or Group Policy registry key that blocks the cloud scan source, a device that fails the post-registration readiness check, or the new hotpatch default rejecting devices that aren't on Windows 11 24H2 with Virtualization-Based Security enabled. Honestly, after running Autopatch across mixed Intune and co-managed fleets for the better part of two years, I'd say fixing those three categories resolves roughly 90% of "Not ready" alerts before you ever open a support case with Microsoft.

• Microsoft deprecated WSUS in September 2024 and now steers customers to Intune, Windows Autopatch, and Azure Update Manager. WSUS still receives security fixes but no new features.
• Hotpatch updates became the default in Windows Autopatch starting with the May 2026 security cycle; eligible devices require Windows 11 24H2 build 26100.2033+, an x64 CPU, and VBS enabled.
• The most common "Not ready" cause is a leftover HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate key blocking the cloud scan source (often planted by retired RMM or MDM agents).
• Use the Autopatch Client Broker, the Update Readiness report, and the new Update Lifecycle report to pinpoint stalls between Offered, Installing, and Reported states.
• If feature or quality updates are still routed to WSUS via Group Policy, Autopatch loses inventory events and ring assignments silently break. Always set scan source to Windows Update.

Why is my device not ready for Windows Autopatch?

A device shows the "Not ready" status in the Autopatch Groups Membership report when one or more prerequisite or post-registration checks fail. The single most common offender I see in the field is the registry value HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate set to 1, usually a leftover from a Configuration Manager client, a retired Group Policy Object, or a third-party RMM tool that's been removed without cleaning up its policy footprint. Clicking the "Not ready" cell in Intune surfaces the specific failed check, and that's where you start your remediation.

The readiness engine evaluates more than 30 distinct signals. Beyond NoAutoUpdate, you'll typically see flags for UseWUServer pointing at a WSUS endpoint, DoNotConnectToWindowsUpdateInternetLocations blocking the Microsoft Update CDN, DisableDualScan being overridden, or a stale TargetGroup value pinning the device to a defunct WSUS classification. Each of these blocks Autopatch from inventorying the device cleanly, which in turn breaks ring assignment.

Deploy a detection-and-remediation pair via Intune to fix the most common offenders at scale. The detection script below returns exit code 1 when problem keys exist, which triggers the remediation:

# Autopatch readiness: detect legacy WindowsUpdate policy keys
$path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$problemValues = @("DoNotConnectToWindowsUpdateInternetLocations",
                   "DisableWindowsUpdateAccess",
                   "WUServer", "WUStatusServer")
$problemAuValues = @("NoAutoUpdate", "UseWUServer", "TargetGroup")

$found = $false
if (Test-Path $path) {
    $key = Get-ItemProperty -Path $path -ErrorAction SilentlyContinue
    foreach ($v in $problemValues) { if ($key.PSObject.Properties.Name -contains $v) { $found = $true } }
}
$auPath = Join-Path $path "AU"
if (Test-Path $auPath) {
    $auKey = Get-ItemProperty -Path $auPath -ErrorAction SilentlyContinue
    foreach ($v in $problemAuValues) { if ($auKey.PSObject.Properties.Name -contains $v) { $found = $true } }
}

if ($found) { Write-Output "Legacy WU policy detected"; exit 1 } else { exit 0 }

The matching remediation removes the values and restarts the Windows Update service so the next sync uses the cloud endpoint:

# Autopatch readiness: remove legacy WindowsUpdate policy values
$path   = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$auPath = "$path\AU"

"DoNotConnectToWindowsUpdateInternetLocations","DisableWindowsUpdateAccess",
"WUServer","WUStatusServer" | ForEach-Object {
    Remove-ItemProperty -Path $path -Name $_ -ErrorAction SilentlyContinue
}
"NoAutoUpdate","UseWUServer","TargetGroup" | ForEach-Object {
    Remove-ItemProperty -Path $auPath -Name $_ -ErrorAction SilentlyContinue
}

Restart-Service -Name wuauserv -Force
Start-Process -FilePath "$env:SystemRoot\System32\UsoClient.exe" -ArgumentList "StartScan"

How do I migrate from WSUS to Windows Autopatch?

The migration path Microsoft recommends in 2026 is to leave WSUS running for legacy on-premises servers while moving every Intune-managed client device to Autopatch quality and feature update policies. WSUS was officially deprecated in September 2024. It still receives security updates and continues to function for the foreseeable future, but no new features will ship. For client patching strategy this means a staged cutover, not a flag-day migration. Read the official Windows Autopatch FAQ for the supported coexistence matrix before you plan dates.

I run migrations in four phases. First, audit existing Group Policy and Configuration Manager update settings and document every device's current classification, deferral, and ring. Second, build Autopatch deployment groups in Intune that mirror your existing test/pilot/broad waves, but keep them empty. Third, deploy the detection-and-remediation scripts above to a 10% canary so devices start cleaning their own WSUS policy footprint. Finally, move device collections into the new Autopatch groups in batches of 500 to 2,000, watching the Update Readiness report between waves.

The migration step that catches teams off-guard is the scan source switch. If you've ever set the Group Policy "Specify intranet Microsoft update service location," the device keeps scanning WSUS for feature and quality updates even after you assign it to an Autopatch group. The Autopatch service then sees the device as registered but never gets inventory events, so it's silently excluded from rings without raising an alert. The scan source policy is the cure, covered in detail below.

For environments still running co-management, follow the same approach we documented in the Intune device enrollment troubleshooting guide: confirm the device is Hybrid Entra joined or Entra joined, then transition the Windows Update workload to Intune before assigning Autopatch policies. Skipping that step is the most common cause of "Device is enrolled but never gets updates" tickets.

Fixing Windows Autopatch hotpatch errors in 2026

Hotpatch updates install monthly security fixes without a reboot, and Microsoft flipped them to the default for all eligible devices starting with the May 2026 security cycle. See the hotpatch updates documentation for the full eligibility matrix. Tenant-level controls to block or allow hotpatch became available on April 1, 2026. The catch is that ineligible devices silently fall back to the standard Latest Cumulative Update (LCU), so a fleet can suddenly diverge into hotpatched and non-hotpatched populations without anyone realising.

The four eligibility prerequisites are non-negotiable: Windows 11 version 24H2 build 26100.2033 or later, current baseline installed, an x64 (AMD/Intel) CPU, and Virtualization-Based Security enabled. Arm64 devices are not eligible. If you see the alert "Hotpatch, VBS not running" in the Autopatch console, VBS is the gating factor. You can confirm with msinfo32 or this PowerShell check:

# Verify hotpatch prerequisites on a target device
$os = Get-CimInstance Win32_OperatingSystem
$build = [int]($os.BuildNumber + "." + ($os.Version.Split(".")[3]))
$vbs = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
                       -ClassName Win32_DeviceGuard
$cpu = Get-CimInstance Win32_Processor | Select-Object -First 1

[PSCustomObject]@{
    Build         = $os.Version
    BuildEligible = $os.BuildNumber -ge 26100 -and ([int]$os.Version.Split(".")[3]) -ge 2033
    Architecture  = $cpu.Architecture     # 9 = x64, 12 = Arm64
    ArchEligible  = $cpu.Architecture -eq 9
    VbsStatus     = $vbs.VirtualizationBasedSecurityStatus  # 2 = running
    VbsEligible   = $vbs.VirtualizationBasedSecurityStatus -eq 2
}

So, what if a device meets every prerequisite but still receives LCUs instead of hotpatches? The next thing to check is the baseline month. Hotpatch operates in quarterly cycles: months 1 and 4 deliver a baseline LCU with a reboot, and months 2, 3, 5, 6 deliver hotpatches with no reboot. A device that missed a baseline month is temporarily ineligible until the next baseline applies. The Update Lifecycle report surfaces this; look for the "Eligibility lost: baseline missing" sub-state.

Scan source policy: redirecting devices away from WSUS

Dual Scan for Windows Update has been deprecated and replaced by the scan source policy. Autopatch supports the scan source policy provided feature updates and quality updates workloads point at Windows Update. If either workload is still configured for WSUS, Autopatch can't reliably build a ring view, release schedules drift, and devices that look healthy in Intune stop receiving updates from Autopatch.

Configure the scan source via the Intune Settings Catalog under Windows Update for Business → Manage updates offered from Windows Server Update Service, or via the CSP path SetPolicyDrivenUpdateSourceFor[Feature|Quality|Driver|OtherUpdates]. Set each to 0 (Windows Update) for any device under Autopatch management. The matching registry path is HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\SetPolicyDrivenUpdateSourceForDriverUpdates and its siblings.

Update workload	WSUS-only (legacy)	Windows Autopatch (recommended)
Quality updates	Sourced from WSUS, classified manually	Sourced from Windows Update via Autopatch policy
Feature updates	Approved per OU, slow rollout	Ring-based, automatic safeguard holds
Driver & firmware	Inventoried by WSUS, often outdated	Cloud-delivered via Autopatch driver service
Hotpatch	Not supported	Default from May 2026 if prerequisites met
Rollback	Manual via WSUS console or PSWindowsUpdate	Pause/resume/roll back via Intune
Reporting	WSUS Reports + custom queries	Update Lifecycle and Readiness reports in Intune
Future support	Deprecated September 2024, security fixes only	Active development, hotpatch and AI-assisted insights

One gotcha I hit on a 50,000-seat tenant: setting the scan source via CSP does not retroactively cancel an existing scan that's in flight. After deploying the policy, force a fresh sync with UsoClient.exe StartScan or wait for the next scheduled scan window. Until then, the device's last update scan timestamp will lag and the Update Readiness report may still show stale WSUS data for up to 24 hours.

Safeguard holds, deferrals, and update lifecycle stalls

For feature updates specifically, Microsoft applies safeguard holds when telemetry indicates a known compatibility issue between the target build and a driver, application, or hardware configuration on the device. A held device shows up as "Offered" in the Update Lifecycle report but never moves to "Installing." You can confirm the hold and the reason from %ProgramData%\USOPrivate\UpdateStore\ logs or via the Feedback Hub.

For helpdesk-tier troubleshooting, the practical question is: should you opt the device out of the hold? In most cases, no. The hold is protecting users from a real defect. The exception is when you've already validated the build on identical hardware and the hold is too broad. In that case, deploy the DisableWUfBSafeguards policy to the specific device only, never tenant-wide.

Quality update stalls have a different signature. The Update Lifecycle report's granular states replace the generic "In Progress" with transitions like Download pending, Download in progress, Install pending, Restart pending, and Reported. A device stuck at Restart pending for more than seven days is almost always a user actively dismissing the restart prompt. Combine an Intune notification policy with a scheduled forced restart during off-hours. Devices stuck at Install pending usually have low disk space (the threshold is roughly 8 GB free for a feature update).

The Windows Autopatch update readiness report is the tool I check first thing every Monday. It surfaces readiness risks before they cause real failures and maps directly back to the failed prerequisite check, so the remediation path is unambiguous.

Using the Autopatch Client Broker for log collection

The Autopatch Client Broker is the diagnostic agent Microsoft introduced to streamline support cases. Deploy it from Tenant Admin → Windows Autopatch → Management. Once installed it does three things: validates that the device is genuinely ready to be managed by Autopatch, proactively detects known issues like time-skew or expired certificates, and uploads diagnostic logs automatically when you open a support ticket. No more manually collecting CBS, WindowsUpdate, and SetupAct logs.

For everyday troubleshooting before you open a ticket, the logs that matter most are C:\Windows\Logs\WindowsUpdate\WindowsUpdate.etl (use Get-WindowsUpdateLog to convert to text), %ProgramData%\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log for remediation script outcomes, and the Event Viewer channels we cover in our Windows Event Viewer troubleshooting guide. Specifically, expand Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient → Operational and filter on event IDs 19 (installation success), 20 (installation failure), and 43 (download started).

A quick PowerShell one-liner I run on any device that's drifted out of compliance:

# Pull the last 50 Windows Update events into a sortable table
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName,
        @{n='Message';e={ ($_.Message -split "`n")[0] }} |
    Sort-Object TimeCreated -Descending |
    Format-Table -AutoSize -Wrap

Common Windows Autopatch error codes and fixes

Most Autopatch failures bubble up as a numeric Windows Update error code, which means the existing wuauclt knowledge base still applies. That said, a handful of codes are uniquely associated with Autopatch readiness and ring assignment. The table below collects the ones I see weekly. If you're chasing an Intune Autopilot code in the same family, our deep dive on Intune Autopilot error 0x80180014 covers the overlap.

0x8024500C: WU_E_REDIRECTOR_LOAD_FAILED

The Windows Update Agent can't load its redirector configuration. On Autopatch-managed devices this almost always means the device can't reach fe2cr.update.microsoft.com or has an expired or untrusted CA chain. Verify proxy and firewall rules allow the Autopatch network endpoints, then test with Test-NetConnection fe2cr.update.microsoft.com -Port 443.

0x80072EE2 / 0x80072EFD: Network timeouts

Classic connectivity issues to the Microsoft Update CDN. On devices behind a TLS-inspecting proxy, exclude the Autopatch and Windows Update endpoints from inspection. Microsoft publishes the canonical endpoint list in the Autopatch documentation; SSL bumping breaks pinned cert validation and produces this code.

0x80240438: WU_E_PT_NO_AUTH_PLUGINS_REGISTERED

Seen on hybrid-joined devices where Entra ID authentication for the WU service fails. Usually fixed by repairing the Entra registration with dsregcmd /leave followed by dsregcmd /join, but only after confirming the device's Entra device object isn't stale.

0x80070643: Generic install failure

Vague but extremely common. Pull the CBS log (C:\Windows\Logs\CBS\CBS.log) and search for [SR] entries; corruption in the component store is the usual culprit. Run DISM /Online /Cleanup-Image /RestoreHealth followed by sfc /scannow, then retry the update.

0x800f0922: Install fails late

The update started installing but couldn't commit a change. On hotpatch-eligible devices this often means VBS was disabled mid-flight by Intune policy conflict. Resolve the conflict, reboot to clear the half-applied state, then re-deploy.

Frequently Asked Questions

What is the difference between hotpatch and cumulative updates in Windows Autopatch?

Cumulative updates (LCUs) bundle every fix released since the last major Windows release and require a restart to apply. Hotpatches install the same security fixes without a reboot by patching code in memory, but they're delivered only in months 2, 3, 5, and 6 of each quarter; months 1 and 4 still deliver a baseline LCU with a reboot. Hotpatch requires Windows 11 24H2 (build 26100.2033+), an x64 CPU, and VBS enabled.

How do I opt out of hotpatch in Windows Autopatch?

Since April 1, 2026 you can set a tenant-level opt-out in Intune under Tenant Admin → Windows Autopatch → Hotpatch settings, or apply a hotpatch-disabled quality update policy to a specific device group. Per-device opt-out takes precedence over the tenant default. Opting out reverts those devices to standard LCU delivery on every Patch Tuesday.

Why is Windows Autopatch not installing updates on my device?

Most often the device is still scanning WSUS instead of Windows Update because of a legacy WUServer or UseWUServer registry value, or the scan source policy hasn't applied yet. Other common causes are insufficient disk space (under 8 GB free blocks feature updates), a safeguard hold for a known compatibility issue, or a VBS-related ineligibility for hotpatch with no fallback configured.

Does WSUS still work in 2026 after deprecation?

Yes. Deprecation announced in September 2024 means Microsoft will not add new features to WSUS, but the product continues to receive security updates and remains supported for the foreseeable future. Microsoft's published guidance is to plan migration to Intune, Windows Autopatch, or Azure Update Manager, with no hard end-of-support date announced yet.

How do I force a Windows Autopatch device to re-evaluate readiness?

Run UsoClient.exe StartScan to trigger a fresh update scan, then in the Intune admin centre open the device in the Autopatch Groups Membership report and choose Sync. The Update Readiness report refreshes on its own roughly every 24 hours, but a forced sync surfaces fixes within an hour. If the device still shows "Not ready," the Autopatch Client Broker can collect the failing check details directly.