The ticket reads like a contradiction. The device is compliant, the update ring shows success, Intune is plainly in charge, and yet Windows Update never offers the Windows 11 feature update. Weeks pass and the machine sits on an old build while its twins upgrade around it. Nine times out of ten the cause is not the ring you built. It is the WSUS past the device never let go of.
Why the device still believes in WSUS
WSUS was always driven by Group Policy, and Group Policy writes real registry values that outlive the GPO’s usefulness. A device migrated to Intune keeps scanning against whatever those values say until someone removes them, because Intune’s update policies land in a different part of the registry entirely and do not overwrite the old ones. The values that matter all live under one policy key.
| Value | Location under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate | What it does |
|---|---|---|
| WUServer / WUStatusServer | root | The WSUS server URL the device scans against. |
| UseWUServer = 1 | \AU | The switch that actually routes Automatic Updates to that server. |
| TargetReleaseVersion / ProductVersion | root | Pins the device to a named Windows release. |
| DoNotConnectToWindowsUpdateInternetLocations = 1 | root | Blocks the fallback connections to public Windows Update entirely. |
| SetPolicyDrivenUpdateSourceFor*Updates | root | The per-class scan source policy: feature, quality, driver, other. |
Windows 11 made the trap stricter
On Windows 10 there was an escape hatch called dual scan: configure deferral policies alongside a WSUS server and the device would flip its scans to Windows Update. Windows 11 removed it. On Windows 11, if a WSUS server is configured, every update class comes from WSUS unless the per-class scan source policy explicitly says otherwise, and deferral policies no longer change that. So a lingering WUServer value on a Windows 11 machine quietly pins feature updates to a server that may not have approved anything in years, and if DoNotConnectToWindowsUpdateInternetLocations is set as well, the device cannot even fall back to the cloud. It will wait politely forever.
The second blocker hides in plain sight: a stale TargetReleaseVersion. Pin a device to a release and it stays there, which is the point. But if the pinned version is older than what you now want, or simply invalid, the device receives no feature updates at all until the policy changes. Microsoft’s documented safety net is that a device stuck past its edition’s end of service gets force-updated 60 days later, which is not a safety net any operator wants to rely on. If you pin versions, pin them with Intune feature update policies, which are built for exactly this, and retire the registry-era pin.
Why MDMWinsOverGP will not save you
The reflex is to reach for the ControlPolicyConflict policy and declare that MDM wins over Group Policy. For update policy, it does not. Microsoft states it twice in its own troubleshooting guidance: the ControlPolicyConflict CSP does not apply to the Update Policy CSP, and using MDM-wins does not work with Windows update policies. The conflict has to be removed at the source, not arbitrated.
Finding it
The fastest confirmation is on the device: Windows Update’s advanced options include a view of configured update policies, and each entry names its source. Anything sourced from Group Policy on a machine that is supposed to be cloud-managed is your suspect list. The registry check is the same list as the table above, and on a hybrid-joined device, gpresult tells you which GPO is still writing the values, because deleting them locally is pointless if a linked GPO reapplies them at the next refresh. One unrelated cause worth ruling out while you are there: if the registry is clean and feature updates still never arrive, check that the Microsoft Account Sign-in Assistant service has not been disabled by an overzealous hardening baseline, because Intune’s feature update policies documented dependency on it is real.
Cleaning it up at scale
A remediation script pair handles the fleet. Detection flags any device still carrying the legacy values; remediation deletes the policy key tree, clears the cached Group Policy state that Windows keeps for update policy, and restarts the update service so the next scan starts clean.
# Detection
$wu = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'
$p = Get-ItemProperty $wu -ErrorAction SilentlyContinue
$au = Get-ItemProperty "$wu\AU" -ErrorAction SilentlyContinue
if ($p.WUServer -or $p.TargetReleaseVersion -or
$p.DoNotConnectToWindowsUpdateInternetLocations -eq 1 -or
$au.UseWUServer -eq 1) {
Write-Output 'Legacy WSUS policy present'; exit 1
}
Write-Output 'Clean'; exit 0# Remediation
Remove-Item 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item 'HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache' -Recurse -Force -ErrorAction SilentlyContinue
Restart-Service wuauserv -Force
Write-Output 'Legacy WSUS policy removed'Run it as SYSTEM in a 64-bit host, and pair it with the actual fix on the directory side: unlink or descope the GPO that wrote the values in the first place. On hybrid-joined devices the script buys you a clean scan, and the GPO change makes it stay clean.
The direction of travel
WSUS was deprecated in September 2024, and driver synchronization ended in April 2025. It still works, and Microsoft still publishes updates through it, but every part of this story is a one-way migration to cloud scan sources. If you are mid-transition and genuinely need some update classes on WSUS while feature updates come from the cloud, the per-class scan source policy is the documented way to say so, deliberately, rather than by registry accident. The update strategy itself, Autopatch first and rings as the fallback, is [5.5] Updates: Autopatch as Default, and the ring build is [5.5.1] Configuring Autopatch and Update Rings in Practice. This article is for the devices that read those policies and then went looking for a server that no longer answers.
