Freeze the case before remediation
Record the device identifier, Intune managed-device identifier, Entra device identifier, user, Windows edition and build, UTC time window, profile name, and setting name. Export evidence before deleting assignments, unenrolling, or forcing policy changes.
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"The generated report can include an HTML summary, detailed XML, registry export, event logs, and collection metadata. Treat it as potentially sensitive administrative evidence.
Know what each source can prove
| Source | Useful for | Cannot prove alone |
|---|---|---|
| Intune per-setting status | Service-side assignment and reported result | The exact local transaction or competing authority |
| DMEDP/Admin event log | MDM command, policy area, result and local processing time | The complete current tenant design |
| MDMDiag HTML/XML | Enrollment and policy snapshot | What changed after collection |
| Registry policy state | Current or recorded local values | Which source should win without additional context |
| Resultant user experience | Whether the intended control is observable | Whether reporting and enforcement came from the expected policy |
Build the correlation row
Create one row per failing setting. Include the profile and setting name, OMA-URI or Policy CSP path, expected data type and value, assignment scope, local event ID, HRESULT or status, and portal result. This prevents two similarly named settings from being treated as the same command.
- Confirm the canonical CSP path and its current applicability.
- Find the matching event in the Admin channel during the recorded time window.
- Convert decimal and hexadecimal results consistently.
- Compare the event’s policy scope and data format with the configured profile.
- Check for another MDM, Group Policy, security baseline, or local configuration controlling the same behavior.
- Verify the effective behavior after correcting only the identified mismatch.
Classify the failure before fixing it
- Applicability: unsupported edition, version, scope, or node.
- Contract: wrong OMA-URI, data type, value, or SyncML operation.
- Conflict: multiple policy authorities attempt to control the same setting.
- Dependency: certificate, identity, service, hardware, or restart prerequisite is missing.
- Reporting: local enforcement completed but service status is stale or associated with an earlier attempt.
“Remediation failed” is not specific enough. The classification determines whether to change the assignment, profile payload, device prerequisite, or reporting investigation.
Use debug logging deliberately
The Admin channel is enabled by default and is the correct first stop. Debug logging can add detail, but it also increases volume and should be enabled through an approved collection plan. Record when it was enabled and disabled, reproduce once, and preserve the exported EVTX with the diagnostic package.