I've been troubleshooting for nearly a year with Microsoft support because many Windows 11 devices managed through Microsoft Intune are not installing updates according to their assigned Windows Update ring policies. The devices are Entra joined, enrolled in Autopilot, and spread across multiple customers and tenants. Some were enrolled in place, while others were reset and provisioned through Autopilot. They check in and sync normally, and Intune diagnostics show that the policies are being delivered without obvious conflicts.
The update ring allows Microsoft product updates, blocks driver updates, has no deferral period, and uses automatic installation and restart deadlines. Quality updates have a seven-day deadline, feature updates have a 30-day deadline, and the grace period is three days. Despite this, some devices have not updated since late 2025.
Support identified a separate compliance policy with a minimum OS build higher than the devices' current builds, as well as simultaneous OS and driver update activity. Adjusting those policies, creating a dedicated test group, blocking driver updates, rebooting, deploying a feature update policy, and reducing the test device's deadline did not resolve the issue. The policies apply successfully, but the device remains on the older build.
A NoAutoUpdate registry value was also found and disabled. Group Policy settings and results were reviewed, but no obvious conflict was found. Changing or deleting the value and rebooting caused it to return as 0, yet Windows Update still did not install updates.
An attempted in-place repair installation failed with "We couldn't update the system reserved partition." I'm mainly trying to determine what common cause could affect devices across several tenants and manufacturers, and how to get Windows Update working reliably without manually repairing every device.
3 Answers
The system-reserved-partition error is probably a separate issue from the update-ring problem. Older OEM images sometimes have a partition that is too small for servicing or recovery updates. Resizing that partition may fix the in-place upgrade failure, but it won’t explain why Windows Update is failing across multiple tenants. I’d keep that as a separate repair project and focus first on finding a shared policy, image, or agent that is controlling Windows Update.
The NoAutoUpdate value is still a major clue. If it was set to 1, Windows Update automatic installation would be disabled even though the Intune update ring was applied correctly. If it keeps coming back, look for a common source such as a provisioning image, configuration baseline, legacy GPO, RMM agent, or deployment script. Compare the Windows Update and Automatic Updates registry branches, relevant event logs, and Windows Update logs from one healthy device and one affected device. Since the issue spans tenants and manufacturers, a shared management artifact is more likely than a Windows hardware problem.
Check whether the devices have leftover WSUS configuration. Look under HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdate for UpdateServiceUrl, WUServer, or WIStatusServer. If they point to an old WSUS server, remove them, and verify that UseWUServer under the AU key is set to 0. Also check where the settings come from. If those values return after a sync, an old Group Policy, RMM tool, baseline, provisioning image, or settings profile is probably writing them back.
That’s worth checking again. My concern is how the same problem could appear across different tenants, especially where the devices were not previously managed. A shared image, script, or management tool could still explain it, so I’ll compare the policy sources and registry state on affected devices.
I changed the value from 1 to 0 and restarted, then also deleted it and allowed the policy to recreate it as 0. Neither test changed Windows Update behavior, but I agree that identifying what originally set it is still important.