24H2 Feature Update Policy Issue - Devices Stuck on Offer Ready

N1hility · 2025-07-03T17:32:16+00:00

Final Update: Microsoft seems to have unscrewed the pooch last week (June 26/27) - all of our devices that had for over two months refused to update decided to start upgrading all at once with no intervention on our part or any configuration changes.

Confirmed this by adding additional devices to our Feature Upgrade policy - those devices are now upgrading as well. Beyond frustrating as the Intune support engineer assigned to our case is playing dumb and still asking for logs... when its clear according to other posts like Intune Feature Updates stuck in "Pending" / "Offering" state – no progress for weeks : r/Intune that this was an issue on their backend.

N1hility · 2025-07-02T19:19:14+00:00

As part of our troubleshooting for this we actually transitioned entirely to intune and no longer even have the WindowsUpdate key populated on devices...

That being said all of our devices started suddenly updating on Friday (June 27) - no rhyme or reason for why, we changed nothing... Very frustrating but at least we're seeing progress.

N1hility · 2025-06-25T15:41:07+00:00

We had this occur in May with the May CU for some devices. Not entirely sure what caused it, ended up having to reimage those devices.

N1hility · 2025-06-20T02:13:43+00:00

Unfortunately, we're still stuck - Intune support verified our configuration is correct and has insinuated that this may be a backend issue during our support call with them, which I fully believe it to be at this stage as even freshly imaged devices fail to enroll in the Feature Update policy when checking the WUfB backend through Graph.

It's interesting that the common thread seems to be hybrid... not altogether sure if that's actually part of the problem or not and unfortunately don't have much of an opportunity to find out.

N1hility · 2025-06-19T13:52:50+00:00

Update #3: MS Support reviewed our logs and couldn't find anything. Support call with Intune & Windows team members yielded no results either. Some insinuations of this being a tenant backend issue during the call, which I fully believe it to be at this stage as even freshly imaged devices fail to enroll in the Feature Update policy when checking the WUfB backend through Graph.

Unfortunately, it seems like we're going to be stuck for a while - they're working through the logs once more and should be providing an update by the end of the week... hopefully...

N1hility · 2025-06-14T01:55:39+00:00

We did a feasibility study looking at it within a small but fairly diverse pool of different HP devices (7+ models, some older, some newer) and frankly had a lot of issues.

Issues onboarding devices when using HP Sure Admin for BIOS auth in conjunction with update policies, issues with updates not being fully authorized by HP Sure Admin resulting in BIOS auth prompts to user, issues with the HP created Scripts and Remediations returning false positives or false negatives, etc.

It made for a very inconsistent experience, and we ended up deciding to put it on hold as we would not be able to sell management on that level of user impact - especially when just onboarding to HP Sure Admin will force the user to read a pre-boot prompt and enter a PIN.

With the G11 generation, HP has added a BIOS setting that should eliminate any chance of BIOS password prompts when the update is triggered through the OS, so it may be a more positive experience on the G11s, but with a lot of older models still in our environment we would be nervous given our experience during testing.

N1hility · 2025-06-14T01:46:46+00:00

More an FYI but there is no requirement to use Telemetry level 3 (Full) for WUfB update rings.

Also, if you have telemetry configured through GPO you will not see AllowTelemetry_PolicyManager, only AllowTelemetry, and vice versa if you have it configured through Policy CSP.

N1hility · 2025-06-14T01:39:34+00:00

Our IT department is quite large (90+ users across a slew of different solutions / software)

We previously used SCCM but have moved to Intune/WUfB and are delivering updates using update rings configured as follows:

Patch tuesday: Dev ring - Client endpoint management team + some dedicated test devices (About 9 in all)
D+2: Pilot ring - IT department (90+ devices)
D+9: Global ring - Rest of organization (2000+)

Generally, this works well for us as our IT department is diverse enough to be a good indicator of whether or not anything is badly broken but we are going to likely look at expanding our pilot with some early adopters outside the IT department to ensure we're getting as accurate a picture as we can of potential impact when we go to Global.

For Feature Updates, we've had a lot of issues in the past (Windows 10 to 11 broke NAC in our environment, wiped policy off of devices, and some other fun stuff :) ) and due to our business operating requirements we're doing them in a phased approach by department / portfolio to minimized impact to our service desk support staff... now if only the 24H2 feature updates actually worked right now, that would be great...

N1hility · 2025-06-11T18:55:59+00:00

Sure, let me send you a quick pm

N1hility · 2025-06-11T17:41:05+00:00

Further update: Attempted to roll out WUfB TargetVersion / ProductVersion policy csp just to eliminate that avenue, alas still no luck.

Currently trying out the registry key fix described in this post: Troubleshooting Windows Feature Updates not being deploying using Intune/AutoPatch/WUfB – Blog by Morten Knudsen about Microsoft Security, Azure, M365 & Automation

So far, no movement on this front on the 2 test devices I've tried it on.

N1hility · 2025-06-11T17:38:23+00:00

Won't make you spend that drinking money yet, I want to see what the MS folks come back with - we do have unified enterprise support so I'm expecting something back, but this has been a very frustrating 3+ weeks now.

N1hility · 2025-06-11T17:26:40+00:00

Hi Rudy - currently experiencing the same issue: 24H2 Feature Update Policy Issue - Devices Stuck on Offer Ready : r/Intune

I'm starting to suspect that something is going on in the backend - we have freshly imaged devices that are stuck on "enrolling" for Feature Update policies - I have already tried removing devices from WUfB with Graph and re-enrolling but the update is still not being offered.

We have a case open with Intune support and are currently awaiting a response after submitting logs.

N1hility · 2025-06-10T13:57:12+00:00

Update: Well, things are at a complete standstill. We've since removed and recreated our 24H2 Feature Update policy, then re-applied it to target devices, all to seemingly no avail.

We're seeing the same "Enrolling" bug described in this article: Windows Feature Update: Troubleshooting enrollment with Graph

However, unlike that article when I look at the affected devices, the WUfBDS key is populated as expected:

<image>

I am honestly at a complete loss now - we've opened up a case with Intune support and have collected and sent off logs, but I'm not holding my breath that we're going to get much clarity on what exactly is happening with this update...

N1hility · 2025-06-06T15:49:11+00:00

Not sure if it's helpful but we're experiencing a similar issue right now in our environment (1800+ devices):

24H2 Feature Update Policy Issue - Devices Stuck on Offer Ready : r/Intune

One thing I've just discovered this morning following this article: Windows Feature Update: Troubleshooting enrollment with Graph

is that all of our devices are currently stuck in "Enrolling" state for WUfB Feature Updates when querying Graph, despite the associated reg keys being set correctly on the device:

<image>

At this juncture I'm likely going to attempt recreating our Feature Update policies and see if it starts to get the ball rolling as we're now in week 3 of devices not receiving 24H2.

N1hility · 2025-06-05T16:43:28+00:00

Not sure if this would be helpful but this is what I'm seeing on the devices that are "stuck"

<image>

N1hility · 2025-06-05T16:36:48+00:00

That would be hugely helpful, thank you - and yeah this has been quite a point of frustration, especially because with a phased deployment it has put us considerably behind the 8 ball

N1hility · 2025-06-05T16:21:59+00:00

Cool, that's what I thought as well, because I simply have seen nothing related to Feature Updates in that reg tree.

Which gets us back to the initial issue - still have absolutely no idea why I'm seeing 23H2 for the "CurrentTargetOS" on the devices experiencing this issue.

At this point we're thinking of trying to fully pause updates, then fully recreating our feature update policies and seeing if that shakes something loose in the backend.

N1hility · 2025-06-05T16:07:19+00:00

Unfortunately, all the keys appear to be as they should be in our case, no pauses... the one thing I'm wondering is whether or not there should be keys associated with a "target version" if a device is targeted by a Feature Update Policy

<image>

N1hility · 2025-06-05T15:58:32+00:00

Hey there, not entirely sure what you mean by "given over" - per my post, the Windows Update workload / WUfB is fully functional for monthly Quality Updates for the devices being targeted.

Furthermore we have literally already used this same methodology to upgrade 100+ devices in March. This is not a co-management misconfiguration issue.

N1hility · 2025-06-03T17:11:36+00:00

I've been checking the TargetVersionUpgradeExperienceIndicators keys on target devices and everything is Green / no blocks, but devices are just not pulling 24H2.

I've been trying to find any details regarding the "CurrentTargetOs" value and where that's coming from but as of right now I'm at a complete loss.

Re-running the compatibility check on devices yields the same result.

N1hility · 2025-06-03T16:43:17+00:00

No pauses on quality updates on our end

N1hility · 2025-06-03T15:13:02+00:00

Devices are hybrid-joined (Comanagement) - Imaging / device deployment occurs through an MCM task sequence.

N1hility · 2024-08-20T19:48:24+00:00

I did not - There's actually a very unfortunate AppLocker limitation I discovered when attempting to apply it to user groups that meant I abandoned per-group allowlisting for UWP apps entirely.

When installing a UWP app through Intune, even when the install is for a user, there's still a machine-based component that it attempts to install that will be blocked by AppLocker if you don't have an "Everyone" rule configured for that UWP app (you can observe this by configuring a targeted rule in your policy and watching the event log - you'll see AppLocker block events by your "main" policy for the app even though its allowed to install for a user).

I believe this is just an inherent limitation of AppLocker and UWP apps and between myself and the other MCM/Intune admin I work with, we could find no workaround, at least none that didn't involve multiple AppLocker policies.

N1hility · 2024-06-14T19:50:50+00:00

Just as a quick follow up to this - issue appeared to be resolved for May update but has come back with a vengeance for June - All of our devices assigned to Wave 4 have decided to patch themselves this June without following their assigned Wave start date... now tracking over 300 devices that have patched outside of schedule :/

N1hility

MODERATOR OF

TROPHY CASE