How to Troubleshoot MEM Intune

Half the time when someone tells me "Intune isn't applying policies," the device isn't actually fully enrolled, it just looks like it is. Here's how to confirm.

In the Intune admin center (intune.microsoft.com), navigate to Devices → All devices and search for the device by name or serial number. Look at the Managed by column, it should say Intune. If it says Co-managed or ConfigMgr, your workloads may be split, meaning Intune only controls certain policy categories while SCCM controls others. That's intentional for co-management, but it's often the source of confusion.

On the device itself, open an elevated Command Prompt and run:

dsregcmd /status

Look for these three fields in the output:

AzureAdJoined     : YES
MDMUrl            : https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc
EnterpriseJoined  : NO

If MDMUrl is blank, the device has no MDM enrollment at all. If AzureAdJoined is NO, you have a hybrid join issue that needs to be resolved before Intune can function. You should also check the MDM enrollment URL matches your tenant, wrong URLs indicate the device enrolled into a different Intune tenant, which happens more often than you'd think in multi-tenant organizations.

If you see WPJ (Workplace Joined) instead of Azure AD Joined, the device is doing MAM-only enrollment. Policies that require full MDM enrollment won't apply. You'll need the user to unenroll and re-enroll properly through Settings → Accounts → Access work or school → Connect using their work credentials.

When this step is done correctly, dsregcmd /status should show AzureAdJoined : YES and a populated MDMUrl.

Microsoft built a diagnostic tool directly into Windows that generates a detailed report on MDM enrollment health, applied policies, and sync errors. This is the single most useful tool for MEM Intune troubleshooting, and most admins don't know it exists.

Open an elevated PowerShell window and run:

$path = "$env:TEMP\MDMDiagReport"
New-Item -ItemType Directory -Path $path -Force | Out-Null
MdmDiagnosticsTool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "$path\MDMDiag.zip"
Write-Host "Report saved to: $path\MDMDiag.zip"

Extract the zip and open MDMDiagReport.html in a browser. This file contains your complete enrollment state, every applied policy with its OMA-URI and current value, any provisioning errors with full error codes, and Autopilot profile status if applicable.

Look specifically at the Policies section. Each policy entry shows its Source (the policy CSP path), Value (what Intune sent), and Status (whether it applied or failed). An error status of 0x87D1FDE8 means a remediation failed, the policy reached the device but the system rejected it, usually due to a conflict with a local Group Policy. An error of 0x80070005 is an access denial, typically a permissions issue with the MDM client itself.

Also check the Enrollment section for your certificate details. Note the expiry dates on the MDM certificates, anything expiring within 30 days warrants a re-enrollment before it fails outright.

When you've run this successfully, you'll have a clear list of exactly which policies are failing and why, no more guessing.

Compliance policy issues are the most business-impacting MEM Intune problem because they trigger Conditional Access blocks. A device marked non-compliant can't access Exchange Online, SharePoint, or Teams, and users get blocked from their work with a message that says essentially nothing useful.

In the Intune admin center, go to Devices → [device name] → Device compliance. You'll see each compliance policy assigned to the device and its per-setting status. Look for any items showing Not compliant with a red indicator. Common offenders:

• BitLocker: reports not compliant when the encryption is still in progress or when the device hasn't uploaded its recovery key to Azure AD yet, even if BitLocker is actually enabled
• Windows Defender: reports non-compliant if the service is in a "Limited" state, which happens after a failed signature update
• OS version: Windows Update for Business rings and compliance minimum version requirements frequently drift out of sync after feature updates

For BitLocker specifically, run this on the device to check key escrow status:

manage-bde -status C:

If Key Protectors shows Numerical Password but the key hasn't uploaded to Azure AD, force the upload:

$BLV = Get-BitLockerVolume -MountPoint "C:"
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

After forcing the key upload, resync the device. Compliance status should update within 5–10 minutes. If Conditional Access is still blocking the user, check whether the CA policy has a grace period configured, if it does, the user can access resources during the grace period while compliance catches up.

App deployment failures are a special kind of frustrating because the admin center often just shows "Install failed" with no further detail. Here's how to get the actual error.

In the Intune admin center, navigate to Apps → All apps → [App name] → Device install status. Find the specific device and click it. The Status details column will show an error code. Write it down, the most common ones I see are:

• 0x87D13B68, Win32 app content download failed (network or CDN issue)
• 0x80070643, MSI installation failed (check the application's own installer log)
• 0x87D1041C, Device not checked in recently enough to receive the assignment
• 0x80004005, Unspecified failure in the Intune Management Extension (IME)

On the device, open Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin. Filter for Error-level events. You'll find IME (Intune Management Extension) failures logged here with much more detail than the portal shows.

For Win32 apps, the IME writes detailed logs to:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

Open this file (it's plain text) and search for your app's name or the error code. You'll see the full installation command, the return code from the installer, and whether the detection rule matched after installation. If the detection rule is wrong, for example, checking for a registry key that the installer writes to a different path on 64-bit systems, the app installs successfully but Intune thinks it failed and retries repeatedly.

Fix the detection rule in Apps → [App] → Properties → Detection rules, resave the app, and force a sync. The app should show as installed within one sync cycle.

Sometimes the cleanest path forward is a full re-enrollment. This sounds drastic, but for Windows 10/11 devices it's actually non-destructive, user data stays intact, and the process takes about 15 minutes.

Before re-enrolling, you need to cleanly remove the existing MDM enrollment. Do NOT just click "Disconnect" in Settings, as that sometimes leaves orphaned registry entries that cause the new enrollment to fail with error 0x80180014 (The device is already enrolled).

Instead, run this in an elevated PowerShell to fully clean the enrollment:

# Remove all MDM enrollment registrations
$enrollPath = "HKLM:\SOFTWARE\Microsoft\Enrollments"
$entries = Get-ChildItem $enrollPath
foreach ($entry in $entries) {
    $providerID = (Get-ItemProperty -Path $entry.PSPath -Name "ProviderID" -ErrorAction SilentlyContinue).ProviderID
    if ($providerID -eq "MS DM Server") {
        Write-Host "Removing enrollment: $($entry.Name)"
        Remove-Item -Path $entry.PSPath -Recurse -Force
    }
}

Then go to Settings → Accounts → Access work or school and verify the work account is gone. If you see the account still listed, click it and choose Disconnect to finish the cleanup.

Now re-enroll. Have the user navigate to Settings → Accounts → Access work or school → Connect and sign in with their work Azure AD account. If your organization has auto-enrollment configured via Group Policy or Azure AD join, the MDM enrollment will trigger automatically when they sign in. If not, they'll step through the manual enrollment wizard.

Watch the enrollment complete in real-time in the Intune admin center under Devices → Monitor → Enrollment failures. If a new failure appears, you'll see the error code immediately and can address it before the user walks away from their desk.

After successful enrollment, wait one full sync cycle (or manually force sync) and verify policies are applying in the MDM Diagnostic Report.