A device shows "Succeeded" against every policy in the Intune admin center. The user still isn't getting the behaviour the policy is supposed to enforce. Before you touch the assignment, the conflict-resolution engine, or open a support ticket, there's a question worth answering first: has that policy actually landed on this device, in this registry, right now? The admin center reports deployment status from the last check-in. It does not show you the live, local, currently-in-effect value sitting on the machine in front of the user.
That gap is where a lot of wasted troubleshooting time goes. This post covers where MDM policy actually lives on a Windows device, why "Succeeded" in the portal and "in effect" on the device aren't the same claim, and a script that reads all six real local sources in one pass so you don't have to open Registry Editor six times.
The problem — six different places, one incomplete picture from any single one
When Intune deploys a policy to a device, the actual mechanism is the Windows Policy CSP. Microsoft's own troubleshooting documentation states this plainly for Update rings, and the same mechanism applies to every other MDM policy category:
Writes the appropriate values to the registry — not to a cache, not to a config file the portal can query remotely on demand. The registry is the actual, physical destination. Everything the Intune console shows you about "applied" status is a report generated from telemetry the device sent back on its last check-in cycle. It's accurate as of that check-in. It is not a live read of the device's current state.
The same Learn article is explicit that this local verification step is a distinct, necessary stage of troubleshooting, separate from the admin center:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update."Generalise that one policy area to the whole device and you get the six sources that actually matter when you need ground truth:
PolicyManager\current\device— every MDM device-scope policy currently in effectPolicyManager\current\user— every MDM user-scope policy currently in effect for the signed-in userPolicyManager\providers— which MDM authority (Intune) owns the enrollment, and its provider metadataSOFTWARE\Microsoft\Enrollments— the enrollment record itself: IDs, provider references, enrollment typeSOFTWARE\Policies\Microsoft— the parallel hive used by both Group Policy and some MDM-delivered ADMX-backed policies; this is where a lot of GPO-vs-MDM conflicts are actually visible side by sidedsregcmd /status— join state, tenant ID, device ID, Primary Refresh Token status; not registry, but the other half of "is this device even correctly identified to the tenant that's supposed to be managing it"
No single one of those six tells the whole story. A policy can be present and correct in PolicyManager\current\device while the device is actually failing to apply it because dsregcmd shows a broken PRT. A GPO sitting in SOFTWARE\Policies\Microsoft can be silently overriding what MDM just wrote to the CSP-backed key next to it. You only see the real picture by reading all six together.
Why it happens — the portal reports check-in telemetry, not live device state
This isn't a bug in Intune — it's an inherent property of how any cloud-managed fleet has to work. The admin center can't hold an open connection to every enrolled device and query its registry on demand; it relies on the device phoning home on its regular check-in cycle and reporting what it applied. Between check-ins, or if the device has any delivery, connectivity, or conflict issue that a person hasn't yet investigated, the portal's "Succeeded" reflects the last known-good report, not necessarily the device's current reality.
gpresult and the registry directly rather than trusting the console status alone.The PolicyManager\providers and SOFTWARE\Microsoft\Enrollments hives matter for a related but different reason: they're where you confirm the device is actually enrolled the way you think it is, with the provider you expect, rather than assuming enrollment health from the fact that policies are merely present. Microsoft's guidance on diagnosing enrollment failures notes that enrollment information is written into the registry and can occasionally persist even after unenrollment — another reason a registry read beats an assumption based on portal status alone.
How to verify — read the real sources before you file a ticket or start reassigning
You can check every one of these manually. It's slow, but knowing where to look by hand is what makes the automated version trustworthy rather than a black box.
Each subkey under current\device is a policy area; each value inside it is a policy name and its currently-applied value. Repeat the same read against current\user for user-scope policies, and against SOFTWARE\Policies\Microsoft to see anything landing via the classic Policies hive instead — including some ADMX-backed CSP policies and any surviving Group Policy values.
- Run
dsregcmd /statusand confirm AzureAdJoined/DomainJoined and AzureAdPrt are the values you expect for this device's enrollment type - Open
PolicyManager\providersand confirm the provider entry matches your actual MDM authority — a stale or duplicate provider entry is a real, if uncommon, cause of policies silently not applying - Check
SOFTWARE\Microsoft\Enrollmentsfor a stale enrollment ID left behind from a previous unenrollment, per Microsoft's own enrollment-diagnostics guidance - Only after those three come back clean, compare individual policy values in
current\device/current\useragainst what the admin center says was assigned
The fix — pull all six sources in one pass instead of six manual trips
- Run the companion script below directly on the affected device. It needs no admin rights beyond standard read access to
HKEY_LOCAL_MACHINE, no internet connection, and no Graph or Intune console access at all. - It produces one self-contained HTML report with all six sources laid out side by side, plus a plain-text summary and a timestamped log — genuinely useful evidence to attach to a support ticket or hand to a colleague, rather than six separate screenshots.
- Cross-reference the report's Applied Policies section (the
SOFTWARE\Policies\Microsofthive) against the MDM Device/User Policies sections. If the same setting appears in both with different values, or appears only in the Policies hive when you expected it to be MDM-delivered, that's a real conflict worth investigating withgpresultnext — exactly the escalation path Microsoft's own troubleshooting guide recommends. - Check the Device Join State section before assuming a policy delivery problem — if
dsregcmdshows a broken PRT or unexpected join state, no policy will reliably deliver regardless of what's configured in Intune.
Proof it worked — Export-LocalIntunePolicies.ps1
This script reads all six local sources described above and builds a single self-contained HTML report — dark header, sticky section nav, per-source badge counts — plus a plain-text summary and a timestamped log file. It performs registry reads and one call to dsregcmd.exe /status only. It makes no changes of any kind.
Export-LocalIntunePolicies.ps1 is free and open source. It's a genuinely read-only local check — no registry writes, no network calls, no tenant connection of any kind.
Every value shown above is exactly what's in the report's MDM Device Policies section — the same 1,372-row table the script pulled straight from PolicyManager\current\device on a real device, with the section's nav link, badge count, and area/name/value columns all generated automatically by the script's own HTML builder.
References
- Troubleshoot Update ring policies for Windows devices — Microsoft Learn
- Policy CSP — Microsoft Learn
- Diagnose MDM enrollment failures — Microsoft Learn
- Collect MDM logs — Microsoft Learn
- Troubleshoot devices by using the dsregcmd command — Microsoft Learn
- Intune Enrollment Status Page (ESP) Configuration & Troubleshooting — EndpointWeekly
- LAPS Rotation Compliance Audit — EndpointWeekly