I've spent nearly a year troubleshooting a Windows Update problem affecting many Intune-managed devices across multiple customers, tenants, and manufacturers. The devices are Entra joined, enrolled in Autopilot, and regularly check in with Intune. Some were enrolled in place, while others were reset and provisioned through Autopilot. Intune diagnostics show that the update ring and feature update policies are applying successfully, but many devices remain on older Windows 11 builds and do not install updates automatically.
The update ring allows Microsoft product updates, blocks driver updates, uses the General Availability channel, has no quality or feature deferral, and is configured for automatic installation and restart. Quality updates have a seven-day deadline, feature updates have a 30-day deadline, and grace periods are enabled.
Troubleshooting included cloning policies for a test device, changing deadlines and grace periods, checking compliance policies, removing possible policy conflicts, blocking driver updates, rebooting, deploying a feature update policy, reviewing MDM and ODC logs, checking Group Policy results, and enabling automatic update settings in Group Policy. A compliance policy initially required a newer OS build than the test device, but correcting that only changed the device to compliant; it did not make Windows update.
Support also found a NoAutoUpdate registry value, although changing it to 0 or deleting it caused it to return with a value of 0 and did not resolve the problem. Similar behavior occurs across several tenants, including environments that were not previously managed by us.
Separately, an in-place repair installation failed with "We couldn't update the system reserved partition." Attempts to free space using Microsoft's partition-resizing guidance did not work. I'm mainly trying to determine what common configuration or Windows Update issue could be preventing updates across these otherwise unrelated environments.
3 Answers
The system-reserved-partition error is probably separate from the update-ring problem. It commonly occurs when the reserved partition is too small or full, especially on older OEM layouts, and it can prevent an in-place upgrade without explaining why normal quality updates are not installing. Treat that as a separate repair or reimaging issue rather than making it the main lead for the Intune investigation.
The NoAutoUpdate setting is still the first thing I’d investigate. Even if it currently shows 0, something may be recreating or enforcing the Windows Update policy. Check HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdate and the AU subkey for WSUS values such as WUServer, UpdateServiceUrl, WIStatusServer, and UseWUServer. Old Group Policy, an RMM tool, a security baseline, a provisioning image, or another Intune profile can create a Windows Update for Business versus WSUS conflict.
I changed NoAutoUpdate to 0 and also deleted it, then restarted the test device. It came back as 0, but Windows Update still did not install anything. I’ll recheck the WSUS-related values and look for whatever policy source might be restoring them.
Compare a working device with an affected one instead of relying only on the Intune policy status. Export the Windows Update and Automatic Updates registry branches, review the Windows Update client logs, and identify the policy source for every differing value. If WSUS settings or NoAutoUpdate keep returning after a sync, the source is likely a shared image, baseline, script, RMM agent, or configuration profile. The fact that the issue spans tenants and manufacturers suggests a common deployment process or management tool rather than a Windows problem unique to each device.
That makes sense. I tried the recommended partition-resizing procedure, but it didn’t resolve the error. I’d prefer to avoid resizing partitions across a large number of devices and keep that issue separate from the broader Windows Update investigation.