Blog
Why Windows 11 upgrades fail in co-managed estates
Windows 10 support ended last month, and plenty of co-managed estates are discovering that the Windows 11 rollout they scheduled has quietly stalled on thousands of devices. Usually nothing is broken. Two management authorities are simply disagreeing about who owns updates.
Split authority is the default state
Co-management, Configuration Manager and Intune managing the same device, was designed as a transition, not a destination. The workload sliders decide which authority a device listens to for each area, and the one that matters here is Windows Update policies. The trap is that moving the slider changes who issues policy from now on; it does not undo what the previous authority already delivered. Deferral values, WSUS server assignments and approval decisions all survive the handover unless someone deliberately removes them. Most estates never do, because on the day the slider moved, everything still appeared to work.
Rings against ADRs
The classic conflict is an Intune update ring and a feature update policy offering Windows 11, while WSUS and its automatic deployment rules are still running for the same devices. If the device is still scanning WSUS, and WSUS has never approved a Windows 11 feature update, the device waits politely forever. Nothing errors. Compliance dashboards on both sides look plausible, because each authority is reporting faithfully on the half of the picture it can see. Since Microsoft introduced the scan source policy, you can and should state explicitly which service each update class comes from; leave it ambiguous and the device decides for you, based on whatever policy residue it holds.
The GPO you forgot
Group Policy remnants are the most common residue we find. A WUServer value and UseWUServer flag pointing at a WSUS server that may not even exist any more. A “do not connect to any Windows Update internet locations” setting from a 2016 hardening exercise. Deferral or TargetReleaseVersion values pinning devices to a Windows 10 release nobody remembers choosing. MDM policy does not automatically win these arguments, and a single legacy value under the WindowsUpdate policy key can hold feature updates to a dead source while every modern console insists the device is targeted correctly.
Each authority reports faithfully on the half of the picture it can see. The device obeys the half you forgot.
Stale collections, silent failures
Then there is targeting itself. Pilot workload moves are scoped to Configuration Manager collections, and collections rot: membership rules referencing OUs that were restructured, queries against attributes no longer populated, machines rebuilt under new names. Devices you believe moved to Intune months ago never did, and devices you believe are excluded are happily taking pilot policy. Because a device that receives no upgrade instruction does nothing at all, the failure mode is silence, discovered only when someone counts the estate honestly.
Finding out who actually owns updates
On any single device, four questions settle the argument. First, is co-management genuinely active and which workloads apply: the ConfigMgr client records its workload state, and CoManagementHandler.log shows what the device believes, which regularly differs from what the console believes. Second, what has Group Policy delivered: values under the WindowsUpdate policy registry key, particularly WUServer and UseWUServer, mean legacy authority is still in play. Third, what has MDM delivered: the PolicyManager registry values and an MDM diagnostics report show the Intune side. Fourth, where does the device actually scan: the scan source settings, per update class, are the final word on which service can ever offer Windows 11. Do this on 5 to 10 devices per business unit and the pattern is usually obvious within a day. At estate scale, our discovery tooling captures the same device-side evidence for every machine, because the console view is precisely what cannot be trusted here.
The sequencing that fixes it
The fix is boring and ordered, which is why it works. Decide the single target authority for updates, which today should be Intune and Windows Update for Business, with WSUS now formally deprecated. Clean before you move: unlink or scope out the update GPOs, retire the ADRs, and set scan source explicitly for every update class. Only then move the Windows Update workload, to a pilot collection that is actively maintained, and verify on the devices rather than in the console. Configure rings and the Windows 11 feature update policy, checking for inherited deferrals and release pins. Broaden in waves, gated on hardware eligibility and safeguard holds, not on the calendar. Declare success only when device-side evidence agrees with both consoles. Estates that run this sequence stop chasing ghost failures within a fortnight; estates that skip the cleaning step relive this article every month.
Is your estate arguing with itself about updates?
We untangle co-managed update authority with device-side evidence, then sequence the Windows 11 rollout so it actually lands.