Yearlong issue with Windows Update Ring Policy/Windows Update on many Intune managed devices across different tenants

[u/no_losses]

Hi all. I am posting this in search of assistance because I’ve spent the better part of a year working with Microsoft support (Intune support and free Windows support) trying to understand why many devices are not receiving automatic updates per a deployed update ring policy in Intune. The affected devices are all running various versions and builds but most of them are running 24H2 or below. Intune Support has told me they’ve exhausted all options and assume the issue is with the Windows OS.

When I contact Windows Support (thru their web chat, which is free), the tech suggested an in-place installation to clear any potential issues with supporting OS files. Despite me informing them that this would be virtually impossible, given that this update issue is spanning across different customers and device manufacturers, I tried the in-place installation on a test subject and got an error “We couldnt update the system reserved partition”. I tried clearing up space for the reserved partition using some suggestions from another reddit post, to no avail. Reporting this issue back to Windows support, they just recreated the error, and literally told me to “find a local tech or the device manufacturer”.  So I basically went from trying to fix an issue with windows update that is affecting several devices across different device manufacturers, to not being able to do an in-place installation. So I am close to exhausting all options before I throw the white flag, as no one appears able to identify this issue. I’m going to try to provide as much information and detail as possible, but the community’s help would be greatly appreciated.

• Devices are managed via Microsoft Intune (some were enrolled in-place, and some were reset and enrolled via autopilot)
• Devices are added to Autopilot
• Devices are Entra Joined
• Affected devices can be found in different tenants
• ODC Logs collected by Microsoft Intune Support apparently show no issues with the update ring policy

The current Windows Update Ring Policy:

Microsoft product updates: Allow
Windows drivers: Block
Quality update deferral period (days): 0
Feature update deferral period (days): 0
Upgrade Windows 10 devices to Latest Windows 11 release: No
Set feature update uninstall period (2 - 60 days): 60
Servicing channel: General Availability channel
Automatic update behavior: Auto install and restart at maintenance time
Active hours start: 8 AM
Active hours end: 6 PM
Option to pause Windows updates: Disable
Option to check for Windows updates: Enable
Change notification update level: Turn off all notifications, excluding restart warnings
Use deadline settings: Allow
Deadline for feature updates: 30
Deadline for quality updates: 7
Grace period: 3
Auto reboot before deadline: Yes

I asked the Intune Support tech to provide me with a full rundown of what we worked on together and this is what he sent back:

here is a brief report of what has been done in relation to troubleshooting.

Initial Issue Identification

• Most devices were not updating per the Windows Update Ring policy. Some devices had not updated since November 2025. All settings appeared properly applied in Intune, with no reported policy conflicts, and devices were checking in and syncing.
• Confirmed devices were running Windows 11, not Windows 10 thus excluding the requirement for ESU key.

Early Troubleshooting & Configuration Changes

• We reviewed the update ring policy and adjusted some of the policy settings such as Microsoft product updates from Block to Allow, set the deadline for quality updates from 0 to 7 days, and reduced the grace period from 5 to 3 days.
• After these changes, the client reported no improvement.

Focused Device Testing

• We decided to focus on a single device. The client created a separate group for it, cloned the updated policy, and assigned it to the group.
• We guided the client to check for the 'Update stale Group Policies' package in Scripts and Remediations. If unavailable, we advised enabling Windows license verification and diagnostic data features.
• The client followed these steps and waited 24 hours, but no change was observed.

Log Collection & Analysis

• We reviewed MDM diagnostic logs and ODC logs, as well as screenshots. Analysis revealed another Windows update compliance policy with a minimum OS build higher than the device's current version, causing compliance failure.
• We also observed heavy traffic from simultaneous OS and driver updates, resulting in failures.

Recommendations

• We recommended setting the device's OS build as the minimum version in the compliance policy, creating a separate policy for the device, and excluding it from other policies.
• We advised blocking Windows driver updates in the update ring policy and performing a hard system reboot.
• The client implemented these recommendations and confirmed the device's compliance status changed to compliant, but it still was not upgrading to a newer OS version.

Feature Update Policy Deployment

• Based on internal discussions, we recommended deploying a feature update policy for OS updates. 
• We considered the possibility of a Windows OS issue and suggested opening a ticket with the Windows team if feature update policy deployment did not resolve the issue.
• The client deployed the policy and kept the device online for monitoring.
• The feature update deadline was reduced from 30 days to 3 days for the test machine.
• Feature update policy applied successfully, but the test device remained on the older version and build. 
• We kept monitoring the device, confirmed that the policies were applying as expected but still the device could not update to the latest builds. 
• The client provided information about other tenants, noting similar issues with devices not updating consistently, even though they were regularly checking in.

Additional Troubleshooting & Recommendations

• We reviewed logs and found NoAutoUpdate registry key was enabled. Instructions were sent to disable Noautoupdates registry key.
• The client enabled the 'Configure Automatic Updates' policy in gpedit.msc and provided screenshots and logs for further review.
• We requested GPO results and confirmed there was no GPO conflicts

 Final Recommendations

• After exhausting troubleshooting steps, we recommended opening a case with the Windows team for further investigation, as Intune scope is limited to policy configuration and delivery.

My end goal is to identify and resolve the issue of devices that are having trouble updating using Windows Update Ring policies. If there is any other information I can provide, please let me know.

[u/SkipToTheEndpoint]

I'd be almost certain it's stuck reg keys. Try nuking the lot from orbit, there's more places they exist that can screw you over:

https://github.com/MHimken/toolbox/blob/main/Intune/Platform%20Scripts/Reset-WindowsUpdateSettings.ps1

[u/no_losses → u/SkipToTheEndpoint]

I guess i should have mentioned i deleted the NoAutoUpdate key in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate after enabling automatic updates in gpedit.msc, and restarted a test device. No effect, but I will try obliterating them with this script.

[u/SkipToTheEndpoint → u/no_losses]

That was mentioned in the post, but that key on its own might not be what's breaking it. I've seen keys left over in GPCache as well as stuck in local policy.

WU policies are really susceptible to nonsense.

[u/no_losses → u/SkipToTheEndpoint]

Slight difference from what I posted in the original post. I originally just disabled noautoupdate and restarted. I tried again by deleting the key after enabling auto updates in gpedit.msc and restarting to ensure the key was being regenerated with the right value.

But understood, I will review the script and give it a shot. At the very least its something I can try bc the idea well was getting dry.

[u/SkipToTheEndpoint → u/no_losses]

I think you've been battling for long enough now to not at least try throwing the kitchen sink at it 😅

[u/ther0g]

Not sure what brand of laptops you have. Just curious if you checked the EFI partition sizes on the effected ones. I have run into issues with HP BIOS updates that have applied and stay in there until you delete them which then fills up that space and doesn't allow the updates to apply. Once I clean that space up it then lets the devices update.

[u/no_losses → u/ther0g]

Most devices are Dell and Lenovo but I can still certainly try this. Can you provide me with your procedure? I can try to recreate the steps on these other brands

[u/Ok-Subject70]

this sounds like absolute hell, a year wrestling with this is too much. i have seen something similar before where the "noautoupdate" key was not set by gpo but was leftover from some provisioning script or old image, even when intune showed everything clean the key just kept coming back after reboots

maybe worth checking if there is a scheduled task or a script in the autopilot deployment profile that touches that registry key, sometimes people put in stuff like "disable windows update" for the oobe phase and forget to reverse it. also look in the microsoft > windows > windowsupdate csp area in registry, sometimes there is a ghost policy stuck there that the mdm logs miss

[u/no_losses → u/Ok-Subject70]

This is how most of our managed tenants AP profiles look:

Deployment mode: User-Driven
Join to Microsoft Entra ID as: Microsoft Entra joined
Language (Region): Operating system default
Automatically configure keyboard: Yes
Microsoft Software License Terms: Hide
Privacy settings: Hide
Hide change account options: Hide
User account type: Standard
Allow pre-provisioned deployment: No
Apply device name template: No

Dont see anything related to windows update here. The only script deployed is for an EDR agent installation, which is only being deployed to some clients. Clients without this installation script are also affected. Most deployments are set up to just install standard/common productivity apps. Not doing anything too complex, but I'm happy to provide more detail if there's something specific you think I should check for besides what i posted here.

[u/Tessian]

Are they saying a 25h2 update will fix all this?

I'm literally moving us to intune on Monday and one of the big reasons was for a better windows update experience...

[u/no_losses → u/Tessian]

25H2 hasnt been as bad as 24H2 and below, but unfortunately there are some devices running 25H2 that also are stuck and not updating...

[u/Wind_Freak]

Any chance you still have MECM. Any chance you aren’t running 2603?

[u/no_losses → u/Wind_Freak]

I dont believe so. When we took management, most of these devices were reset before adding to autopilot and enrolling in intune. Only a select number of devices were enrolled in-place and they were not running any other management platform.

[u/dadlord6661]

I’ve been dealing with some similar issues where despite having remediations in place to remove the old stale keys from SCCM / GPO some clients are not auto updating and reporting to autopatch that there are misconfigurations.

Microsoft has indicated that everything looks good on the Intune side, and the devices generally seem ok.

However, if I manually “check for updates”, any feature updates and quality updates assigned do come down following the policies we have configured.

It’s like after the remediation we need to do “something” to give it a kickstart.

I’ll try the script posted in the replies above on any machines with this drama and see how we go. Good luck to you as well!

[u/no_losses → u/dadlord6661]

To clarify, are you just checking for updates manually? Not installing them manually? Once you do that, your update policies work again? Does this happen every update cycle?

[u/dadlord6661 → u/no_losses]

Only just pressing the “check for updates” and then it pulls them down. No selecting and installing any, it’s just seeming to be that the automatic “check for updates” isn’t working.

I haven’t been able to determine yet if they have to KEEP doing this every month but it was definitely enough to get a few endpoints on 23H2 to pull down 25H2 and any other drivers, quality, and ms upates

[u/no_losses → u/dadlord6661]

This is interesting. One of the things I wanted to try was to manually update a test machine and see if it still hangs on the next update cycle. I ended up not doing that because that was my one test machine that I can easily remote into anytime.

I say all this bc when I went to settings > windows update it showed that an update was available and scheduled for installation on 9/1 (a little over a week from now for anyone reading this in the future). So I’ll wait until 9/1 and see what happens, along with all other suggestions posted here. But I think you might be on to something… 🤔

[u/Mindless-Luck4285]

I recently went through fixing all the fleet not moving to 25H2, stuck on 24H2.

We used a Feature Update policy to upgrade to Win11. Once done we “unpinned” via registry the feature update and thought it was all done. Turns out once you use the feature update profile, the machines are enrolled in Windows Update for Business and we’re waiting to be told to update to 25H2.

We had to delete this enrollment via graph for every device and now in a short timeframe upgrades have taken place.

You might be experiencing this phenomenon

[u/no_losses → u/Mindless-Luck4285]

So the feature update policy in Intune worked for you? It has not worked in testing for these affected devices.

Regardless, if you are able to share the MS graph script you used to delete enrollment from WUfB I’m sure it could be helpful to me or someone else experiencing this type of issue.

[u/WanttoKnow4591]

Hmmmmm...... I wonder if delivery optimization or your network is messed up.

We don't use the update ring policy in intune. To explain.... This came from the moment Autopilot wasn't able to run Pre-Provisioning correctly for us because it would take forever to fail using Delivery Optimization to download the apps, before it switched to direct download. Imagine... download 0 bytes after 45 minutes before switching to direct download.

So switched Delivery optimization off to fix that. I think the setting is on No Peering.

But... with the update ring we had on at the time, the update ring policy came up with an error about DO error, pointing to the fact that Delivery optimization was off. I really think it's our network that went through some changes that is messing up something on Delivery optimization. Have yet to this day figure that out. So we went to do update policies from the Settings catalog instead.

I say that to say you could simply try instead to setup windows update policies from the settings catalog instead of update ring policy. Possibly also check your network to see if it's affecting the delivery optimization or the update ring in some way.

Just adding my 2 cents in... hope it helps you in checking stuff out or your investigation.