Intune Policy Shows Succeeded, But the Windows Setting Isn’t Applied

Intune Policy Shows Succeeded in the Intune admin center means the service delivered the policy and the device acknowledged it. It says nothing about whether the setting is actually sitting at the expected value on that device right now. Three different things produce the same green checkmark: the policy reached the device and applied cleanly, the policy reached the device and the CSP rejected it, or the policy applied and something else — usually a leftover Group Policy — changed it afterward.

Recreating the profile from scratch is the wrong first move. It resets your own troubleshooting trail along with whatever was actually wrong, and if the real cause was a GPO fight, you’ll be back here in a week with a new profile and the same symptom.

Where do you actually start?

Confirm the device is enrolled and reachable before looking at the policy at all. In the Intune admin center, go to Troubleshooting + support > Troubleshoot, select the user and device, and check that Managed reads MDM or EAS/MDM — anything else means the device can’t receive configuration policy regardless of what the profile itself says. Check the assignment too: include and exclude groups, any assignment filter, and scope tags all narrow who actually gets the policy, independent of whether the profile shows Succeeded in aggregate.

Did the policy reach the device / Intune Policy Shows Succeeded?

If check-in looks stale, trigger one manually from the device: Settings > Accounts > Access work or school, select the connected account, Info, then Sync. That forces an MDM check-in rather than waiting for the next scheduled one.

To see what actually landed, collect an MDM diagnostic report from an elevated PowerShell session:

mdmdiagnosticstool.exe -area DeviceEnrollment;DeviceProvisioning;Autopilot -cab C:\Temp\mdm-diagnostics.cabCode language: CSS (css)

Extract the cab and look for MDMDiagReport_RegistryDump.reg along with the policy-specific entries — Microsoft’s own troubleshooting documentation points to C:\Users\Public\Documents\MDMDiagnostics as where these reports land by default. If your CSP path and value show up in the report, delivery worked; what happens next is a separate question.

Read the CSP result in Event Viewer

Open Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin and look for the Set operation against the CSP path in question, along with any error code attached to it. No matching event usually means the policy never reached the device or check-in itself is failing — go back to enrollment and assignment before anything else. An event with an error means the device received the policy and the CSP refused it; at that point check the data type, the exact CSP path, and whether the setting is supported on this Windows edition and build.

Profiles built on OMA-URI are the most common source of this specific failure. Compare the path character for character against the CSP documentation — a boolean sent as text, or one wrong character in the node name, produces exactly this symptom: Succeeded at the profile level, a rejected Set underneath it.

Check what’s actually on the device

A registry value being present only confirms the CSP wrote something — it doesn’t confirm the OS component is honoring it. Confirm the setting through the actual UI, the relevant app’s own policy page, or a component-specific command (Defender’s own status cmdlets, for instance) rather than stopping at the registry.

$paths = @(
    'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device',
    'HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts'
)
foreach ($path in $paths) {
    Get-ChildItem -Path $path -ErrorAction SilentlyContinue
}Code language: PHP (php)

These two paths are useful for tracing what MDM has touched, but they’re read-only diagnostic territory — editing them directly to force a setting is a different problem with a different set of risks, not a fix for this one.

Leftover Group Policy is the other half of this check, especially for Windows Update, Defender, and Firewall settings that both GPO and Intune can manage:

gpresult.exe /h C:\Temp\gpresult.html
Start-Process C:\Temp\gpresult.html

If a GPO owns the setting, changing the Intune profile again won’t do anything — remove the conflicting GPO scope on a pilot device first, confirm the Intune value takes over, then roll that out.

The sync interval isn’t what it used to be assumed to be

There’s a widely repeated shorthand that Windows devices only check in with Intune every eight hours. That number is real, but it’s the maintenance-cycle fallback, not the whole picture. A profile or setting change on the service side triggers a push notification that wakes the device and forces a check-in, typically within minutes rather than hours — Microsoft throttles this to roughly one push every 30 minutes per device, so rapid-fire edits to the same profile queue up rather than each firing immediately. Newly enrolled devices check in far more aggressively still: every 3 minutes for the first 15 minutes, then every 15 minutes for 2 hours, before settling into the longer cycle. The one hard limit that does apply regardless of any of this is that a device won’t run more than one maintenance sync within roughly 6.5 hours.

Practically: if you just changed a policy and the device isn’t reflecting it after a few minutes, that’s worth investigating, not waiting out. If a device has been offline or asleep, that’s a check-in problem, not a policy delay — the 8-hour number was never a promise that changes take that long to land. Dynamic group membership is the other timing trap here: if the device was just added to the group the policy targets, group evaluation has to complete before assignment even starts, on top of whatever check-in timing applies afterward.

Confirm the basics you’d otherwise skip

The device needs a supported Windows edition and build, an Intune license, and correct user or device scope before any of the above matters. If Managed isn’t MDM or EAS/MDM, the device doesn’t receive configuration or compliance policy at all, full stop.

Not applicable and Error are not the same failure. Not applicable means the platform, edition, or OS version condition wasn’t met — the policy was correctly withheld. Error means the policy reached the device and the CSP couldn’t process it. Treating the two the same wastes time chasing a CSP bug that doesn’t exist when the real issue is that the profile was never going to apply to that edition in the first place.

Comparing devices, and what to hand off if you can’t fix it

When only one device is affected, look at that device specifically: enrollment health, Windows build, local GPO remnants, and general device state. When many devices show the same result, the more likely culprits are assignment scope, filters, platform requirements, or a genuine CSP limitation — troubleshooting individual devices in that scenario mostly wastes time. Don’t compare two devices by name alone; pull managed device ID, Microsoft Entra device ID, last check-in, Windows build, and assignment timing for each, since two devices that look identical in the portal aren’t always on the same enrollment record.We learn why intune policy shows succeeded but no works prod.

Learn More: Best Export Group Memberships in Microsoft Entra ID with PowerShell

Frequently Asked Questions

References

Microsoft — Troubleshoot Policies and Profiles in Microsoft Intune https://learn.microsoft.com/en-us/troubleshoot/mem/intune/device-configuration/troubleshoot-policies-in-microsoft-intune

Microsoft — Diagnose MDM Failures in Windows https://learn.microsoft.com/en-us/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10

Microsoft — Policy CSP https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp

PatchMyPC — Intune Sync and Policy Delivery: Debunking the 8-Hour Myth https://patchmypc.com/blog/intune-policy-delivery-debugging-the-8-hour-sync-myth/