An update ring in Intune reports Succeeded across the fleet. A device in that ring restarts at the wrong time, takes an update it should have deferred, or ignores a deadline.
So you remote onto it, open the registry key where Windows Update policy has lived since Windows 2000, and find almost nothing. Most people conclude the policy never arrived and head back to the portal to re-target or recreate the profile.
Both moves are premature. The policy did arrive — just not where you looked, and the portal never claimed what you think it did.
A ring reported as Succeeded means the CSP commands were delivered and accepted — a statement about the management channel, not the resulting effective configuration. MDM-delivered Windows Update settings land under HKLM\SOFTWARE\Microsoft\PolicyManager, not the classic HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate hive every older runbook names. On the device I used here the classic key held two values while PolicyManager held 25 live ring settings, and the classic Delivery Optimization key did not exist at all despite thirteen DO policies being in force. PolicyManager records who won each setting in a _WinningProvider value, and Windows keeps a blocking record under HKLM\SOFTWARE\Microsoft\MDMWins for every Group Policy value MDM displaced, complete with the OMA-URI that claimed it — the most reliable setting-name map on the box. Read those three places before you touch the portal.
The problem: the portal says Succeeded and the old registry key says nothing
The ring is assigned, the blade is green, and a device in scope behaves as though no ring exists. The instinct is to check the registry.
Real output from a Windows 11 25H2 device, build 26200.9168, in a ring the portal calls healthy. Two values. An AU subkey that exists but holds nothing. The Delivery Optimization key absent outright.
Read that as proof nothing applied and you are wrong three ways: thirteen DO policies were in force, twenty-five Update policies were in force, and the two values you can see did not come from Intune at all.
The other half of the problem is what the portal reports. Intune reports per-setting status against the management channel, which is why Microsoft's own guidance for troubleshooting policies sends you to the device and the MDM diagnostic report.
"Succeeded" means the command was delivered, accepted and acknowledged. It does not mean the setting won, that no second source overrides it, or that every command in the profile succeeded.
Three questions need answers first, and all three are answerable read-only.
- Where did the ring land, and what is the effective value right now?
- Which source set it — this Intune enrollment, another enrollment, or Group Policy?
- Did any command fail on the client after the channel reported success?
Why it happens: PolicyManager is the store, the Policies hive is a GP mirror
The root cause is a documentation artefact, not a bug. Every setting on the Update Policy CSP page carries a Group policy mapping block with a field called Registry Key Name.
For Update/DeferQualityUpdatesPeriodInDays it reads Software\Policies\Microsoft\Windows\WindowsUpdate. For every Delivery Optimization policy it reads SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization.
People read that as "where the setting lives". It is not: it is where the Group Policy twin writes, published so you can match a CSP name to an ADMX element. MDM writes into PolicyManager instead.
gpedit and reason about conflicts. Treating it as the MDM storage location is the most common wrong turn in Intune policy troubleshooting. Delivery Optimization makes it obvious: thirteen DO settings were live on my test device and the key that page names had never been created.PolicyManager is a two-tier store, and the two tiers are the whole skill.
Microsoft documents this shape in one place, for one area. The Intune client-side BitLocker article names both HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker and ...\PolicyManager\Providers\<GUID>\default\Device\BitLocker, and notes the GUID differs per tenant. The layout generalises to every area; the docs do not.
Here is the resolved tier on my device — the ring the portal called Succeeded, invisible from the classic hive.
The suffixed values are the attribution layer, and why this key beats every other read.
| Value | Meaning | What to look for |
|---|---|---|
<Setting> | The resolved effective value after all sources reconcile. Name matches the Policy CSP Update area. | Compare against the portal. A mismatch here is real — unlike one in the classic hive, which proves nothing. |
<Setting>_ProviderSet | Present and 1 while a provider asserts this setting. | Absent is the signal. No source claims it, whatever sits in the classic hive. |
<Setting>_WinningProvider | The enrollment ID owning the resolved value. | Resolve against HKLM\SOFTWARE\Microsoft\Enrollments. Not your Intune enrollment? The portal is not your problem. |
<Setting>_LastWrite | Present once the setting has been written at least once. | Present with _ProviderSet absent and an empty value = set previously, then deleted. A ghost. |
QualityUpdateEnrolled, FeatureUpdateEnrolled, DriverUpdateEnrolled | Update-management enrollment flags, owned on my device by a different provider GUID from the ring settings. | Two winning providers in one area — the classic cause of "the ring is right but the behaviour is wrong". |
The suffix convention is what Microsoft does not publish. I could not find _ProviderSet, _WinningProvider or _LastWrite documented for any area, so treat their semantics as observed, not documented — fine for triage, not for a compliance gate. The setting names are documented; cite those.
A third location matters and almost nobody knows it. When MDM takes ownership of a setting with a Group Policy twin, Windows saves the displaced GP value and writes a blocking record under HKLM\SOFTWARE\Microsoft\MDMWins. My device had 242, thirteen in the Update area, each naming the OMA-URI that claimed it.
Two binaries are worth naming. mdmdiagnosticstool.exe in C:\Windows\System32 is the supported collector — on my device FileVersion 10.0.26100.8115, FileDescription MdmDiagnosticsTool: a 26100 binary on a 26200 build, the same independent-versioning pattern the servicing stack follows. The OMA-DM client and PolicyManager both log to C:\Windows\System32\winevt\Logs\Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider%4Admin.evtx. Neither touches wuaueng.dll, the WU agent service DLL, which only reads the result.
How to verify: seven reads that attribute every setting
Work these in order. Each narrows the answer; none writes to the device.
Step 1. Identify your enrollment ID first. Every attribution downstream depends on knowing which GUID is Intune, and two independent reads agree on it.
Two sources, one answer — hold yourself to that standard. The GUID differs per tenant, so never hard-code it.
Step 2. Read the resolved tier and compare every value against the ring as configured. Use the Intune ring settings reference to translate portal labels into CSP names — the mapping is published, and not always intuitive.
| Value | Meaning | What to look for |
|---|---|---|
DeferQualityUpdatesPeriodInDays | Portal: Quality update deferral period (days). Range 0–30. | Mine read 7. Portal says 7 and this says 0? A second source cleared it. |
AllowAutoUpdate | Portal: Automatic update behavior. | Mine read 6. The Policy CSP page enumerates 0–5 only, so do not assert a meaning for 6. |
ConfigureDeadlineForQualityUpdates | Portal: Deadline for quality updates. Portal range 2–30. | Mine read 30, top of range — which alone explains most "the deadline is not enforcing" tickets. |
ConfigureDeadlineGracePeriod | Portal: Grace period. Range 0–7. | Mine read 7. Deadline plus grace is the real number. |
ConfigureDeadlineNoAutoReboot | Portal: Auto reboot before deadline. | Mine read 1: reboots wait for deadline and grace to expire — the documented cause of restarts landing inside active hours. |
UpdateNotificationLevel | Portal: Change notification Update level. | Mine read 2. Suppressed notifications look identical to "updates are not being offered" from a user's desk. |
SetDisablePauseUXAccess | Portal: Option to pause Windows updates. | Mine read 1, so the pause control is hidden. Check before asking a user to unpause. |
ExcludeWUDriversInQualityUpdate | Portal: Windows drivers. | Mine read 1 — drivers excluded, which reads as "drivers are not patching" in most compliance reports. |
Step 3. Split the claim from the resolution. Enumerate every provider subtree. Two providers claiming one area is your conflict, found without the portal.
MDM_Policy_Result01_Update02 returned one instance holding every documented default — AllowAutoUpdate=2, DeferQualityUpdatesPeriodInDays=0, ConfigureDeadlineForQualityUpdates=7, ConfigureDeadlineGracePeriod=2, BranchReadinessLevel=16 — while the registry held 6, 7, 30 and 7. It did not error. It answered plausibly and wrongly. That silent fallback is observed, not documented; the fix is documented: run as SYSTEM, or read the registry.Step 4. Read the blocking records. This turns guesswork into attribution, and it is the best setting-name map on the device.
Each record carries Uri1 plus StorageType, Scope and UriCounter. The AUOptions line is the most useful fact here: the CSP name and the GP value name for one policy are different words. An audit keyed on CSP names misses GPO-set values; one keyed on GP names misses MDM-set values.
Step 5. Read the event log for commands that failed after the channel said success. This is where portal and device part company.
| Event ID | Message | What it tells you |
|---|---|---|
| 404 | "MDM ConfigurationManager: Command failure status. Configuration Source ID: (...), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (Policy), Command Type: (Add: from Replace or Add), CSP URI: (...), Result: (...)" | A CSP command failed on the client. Level Error. I counted 180 on a device the portal reported healthy. Start here. |
| 454 | "...Command Type: (Clear: first phase of Delete), CSP URI: (./Vendor/MSFT/Policy/Config/Update/RollbackFeatureUpdates), Result: (Unknown Win32 Error code: 0x86000002)" | An Update-area command that failed. Windows calls the code unknown — record it, correlate by timestamp, invent nothing. |
| 813 / 814 | "MDM PolicyManager: Set policy int" / "Set policy string, Policy: (...), Area: (Update), EnrollmentID requesting merge: (...), Enrollment Type: (0x6), Scope: (0x0)" | The authoritative record of a value applying, with area, requesting enrollment and the value. 813 for integers, 814 for strings. |
| 819 | "MDM PolicyManager: Delete policy, Policy: (...), Area: (Update), EnrollmentID requesting merge: (...)" | A setting was removed. Pair a 819 with an empty value in current\device and you have explained a ghost. |
| 881 | "MDM Wins Over GP: MDMWinsOverGP policy enabled and GP setting is blocked, Value: (...), Namespace: (...), Operation: (Set)" | Conflict resolution happening live. 353 occurrences on my device — proof MDMWinsOverGP is not theoretical. |
| 2211 / 2213 | "Created a blocking record. Record: (Software\Microsoft\MDMWins\device\...)" / "Attempted to save existing GP Value... Failures are expected if this location isn't set." | The two halves of MDM taking ownership: record the claim, then stash whatever GP had there. |
| 2210 / 2216 | "Attempted to restore GP Value. GP Location: (...), GP ValueName: (...), Result: (...)" / "All GP locations that were to be unblocked have been unblocked successfully." | The reverse path when MDM releases a setting. A "cannot find the file specified" result is benign — no GPO value was ever displaced. |
Step 6. Check the conflict switch itself. On my device ControlPolicyConflict\MDMWinsOverGP was 1 with a _WinningProvider pointing at Intune. Microsoft's guidance is unusually blunt: MDMWinsOverGP applies only to policies in Policy CSP, not all Group Policies are available via MDM or CSP, and for anything outside its control "there will be a race condition and no guarantee which one wins".
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "c:\users\public\documents\MDMDiagReport.zip". The archive holds MDMDiagHtmlReport.html (a snapshot of MDM configuration and policies), MDMDiagReport.xml, MdmDiagLogMetadata.json and — the one that matters here — MdmDiagReport_RegistryDump.reg, documented as containing "dumps from common MDM registry locations". The GUI route is Settings > Accounts > Access work or school > your account > Create report, landing in C:\Users\Public\Documents\MDMDiagnostics. The MDMWinsOverGP docs note this report also lists the GP settings blocked because an MDM equivalent is configured. Collect it first.Step 7. Now compare the two hives deliberately. Any value in Policies\Microsoft\Windows\WindowsUpdate with no matching MDMWins blocking record was not put there by MDM — and is not protected by MDMWinsOverGP either. That is a live, unmanaged value, invisible from the Intune portal.
The fix: attribute the setting, then change the right thing
There is no cache to clear and nothing to reset here, which is exactly why the reflex fixes do so much damage in this failure mode. The fix is correct attribution plus one targeted change. Four outcomes cover almost every case.
Case A — MDM owns it, value matches. _ProviderSet present, _WinningProvider is your Intune enrollment, resolved value equals the portal. The portal was right and you are chasing a misunderstanding of the setting. My device is textbook: a quality deadline of 30 with a grace period of 7 and no-auto-reboot enabled looks exactly like "deadlines are not enforcing" to a service desk, and every value arrived as configured.
Case B — MDM owns it, value does not match. A second provider is winning and _WinningProvider names it. On my device the ring settings belonged to Intune while QualityUpdateEnrolled, FeatureUpdateEnrolled and DriverUpdateEnrolled belonged to a different enrollment entirely. Fix it in the service that owns that enrollment — editing the Intune ring will not move a value it does not own.
Case C — nobody owns it, but the classic hive has a value. This is the interesting one, and what was actually happening on my device. Walk the evidence.
The classic hive held TargetReleaseVersion=1 and TargetReleaseVersionInfo=24H2. In PolicyManager, current\device\Update\TargetReleaseVersion was empty, _LastWrite present, _ProviderSet absent. And a search of all 242 blocking records found none for TargetReleaseVersion or TargetReleaseVersionInfo.
Those three facts say something precise. No MDM provider claims the release pin, and no blocking record shields it. So the 24H2 pin is a live, effective, non-Intune value — and it will never appear in the Intune ring blade, because Intune did not put it there.
Read only PolicyManager and you report "no release pin configured". Read only the classic hive and you report "Intune pinned this to 24H2". Both wrong. Only the three-way read reaches "something outside Intune pinned this, and nobody owns it".
The consequence is checkable, which is how you know the reading is right. That device ran 25H2, build 26200.9168 — later than the version it is pinned to. A pin does not roll a device back; Intune's documentation states plainly that "Feature update policies don't downgrade devices." The pin is stale rather than harmful, until somebody expects it to hold.
Case D — the command failed. Event 404 or 454 for the URI in question: profile-level success on the channel, individual command failure on the client. Take the CSP URI from the event, check that setting's applicability against the device's build and edition on the Policy CSP page, and fix the targeting rather than the value.
One caution before reaching for MDMWinsOverGP. The documented default is 0; setting it to 1 blocks the GP MMC from setting the equivalent policy, and setting it back to 0 or deleting it removes those blocks and restores the saved GP values — the MDMWins hive doing its job, visible in Events 2210 and 2216. It has side effects across every Policy CSP area on the device, so do not flip it to resolve one Windows Update setting.
Proof it worked: closing the loop on a live policy
Registry archaeology only convinces if something outside the registry agrees. Delivery Optimization gives you that, and it is the cleanest case because the classic key does not exist at all.
That is the loop closed. The classic key has never existed on this device. PolicyManager holds DODownloadMode=1, attributed to Intune. And Delivery Optimization's own runtime status reports DownloadMode : Lan on two completed multi-hundred-megabyte downloads with a Connected Cache host in play. The download URLs this cmdlet returns carry query-string authentication tokens, so redact those as well as the cache hosts before pasting into a ticket.
An admin who had grepped only the classic hive would have filed "no Delivery Optimization policy applied" while the device was actively peering on the LAN under a policy Intune delivered successfully.
The second proof is a full lifecycle, reconstructed read-only, validating the ghost-value signature from the reference table.
A quality-update pause was set to 2026-08-18 on the nineteenth, deleted on the twentieth. The blocking record was created, then removed. The GP restore reported "cannot find the file specified" because no Group Policy value had been displaced — benign, and exactly what Event 2213 means when it says failures are expected if the location is not set.
That leaves the signature from the reference table: empty value, _LastWrite present, _ProviderSet absent. Set once, then removed. So the identical signature on TargetReleaseVersion is not speculation — it is the same pattern with a verified timeline behind it.
Two closing habits. Capture mdmdiagnosticstool.exe output before you touch anything. And cite the CSP setting name and its OMA-URI in the ticket rather than a registry path — those names are documented and stable, the PolicyManager suffix convention is neither.
References
- Update Policy CSP — setting names, OMA-URIs, allowed values, and the Group Policy mapping block with the
Registry Key Namefield that causes the confusion. Source for AllowAutoUpdate being documented 0–5. - DeliveryOptimization Policy CSP —
DODownloadModevalue 1 as "HTTP blended with peering behind the same NAT", plus the GP registry key name for every DO policy. - ControlPolicyConflict Policy CSP —
MDMWinsOverGP, default 0, GP-block and restore behaviour, Policy-CSP-only scope, race-condition warning. - Collect MDM logs — the
mdmdiagnosticstool.execommand line, zip contents includingMdmDiagReport_RegistryDump.reg, and the Admin/Debug channels. - WMI Bridge Provider with PowerShell — device-scope bridge queries must run as local system.
- Troubleshooting BitLocker policies client-side — the only Microsoft page I found documenting the PolicyManager layout, naming both tiers and noting the GUID differs per tenant.
- Update rings policy settings — portal-label to CSP-name mapping and portal ranges.
- Troubleshoot policies and configuration profiles in Intune — the supported path from portal status to on-device diagnostics.
All output here was captured read-only from one Intune-enrolled Windows 11 Enterprise device, 25H2, build 26200.9168. Enrollment GUIDs differ per tenant, so treat every GUID as an example. Cache hosts are redacted. The value suffixes _ProviderSet, _WinningProvider and _LastWrite, the MDMWins blocking-record schema, and the WMI Bridge returning defaults instead of erroring outside SYSTEM context are all observed on-device behaviour I could not find documented on learn.microsoft.com — useful for triage, not for a compliance gate.