Microsoft Intune Device Enrollment & Policy Errors, Complete Fix Guide

The Enrollment Status Page is where a lot of Windows device enrollment errors surface visibly. If the device gets stuck at ESP during Autopilot or fresh enrollment, spinning indefinitely or throwing a generic failure, here's how to get actionable data out of it.

First, collect the ESP diagnostic log. When a device is stuck on the ESP screen, press Ctrl + Shift + J. This opens the MDM Enrollment Diagnostics report in a browser-style pane on the right side of the screen. Scroll through and look for any policy or app installation failures. Note exact error codes, they'll look like 0x80070005, 0x800705b4, or 0x8024200d. These map to specific failure types.

Next, review what's blocking ESP completion. In the Intune admin center, go to Devices → Windows → Windows enrollment → Enrollment Status Page. Open your ESP profile and check the list of apps and certificates configured to block the device use phase. If a single app in that list fails to install, ESP halts the entire process. Remove any non-critical apps from the required list temporarily to isolate whether the ESP blocker is app-related or policy-related.

For apps deployed via Configuration Manager that appear in Company Portal, this is a known active issue right now. Apps delivered through ConfigMgr can take minutes to appear on the Windows apps page in Company Portal. If your ESP timeout is set below five minutes, it may fail before the ConfigMgr-sourced apps even appear. Extend the ESP timeout under the profile settings to at least 60 minutes for co-managed scenarios.

# Pull ESP-related event logs for offline analysis
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" |
  Where-Object { $_.Message -like "*EnrollmentStatusPage*" } |
  Select-Object TimeCreated, Id, Message |
  Format-List

If this returns events with ID 75 or 76, ESP hit a timeout or application failure respectively. The message body will name the specific policy or app that caused the halt, target that for remediation.

Once you've identified the blocker, either fix the app deployment or temporarily exclude the device from the restrictive ESP profile, re-enroll, then add it back. You should see the ESP progress cleanly through all phases and the device land in a Ready state.

Android Enterprise enrollment errors are some of the most confusing in the Intune ecosystem because there are actually three distinct corporate enrollment modes, dedicated, fully managed, and corporate-owned work profile, and they fail in different ways. The Intune admin center often groups them, which makes pinpointing the problem harder.

If you're seeing Android devices fail to enroll or lose access to Intune-managed resources, start here. Navigate to Devices → Android → Android enrollment in the Intune admin center and confirm the enrollment profile assigned to the device actually matches the intended management mode. A mismatch here silently breaks enrollment in ways that look like authentication failures.

For OPPO, OnePlus, and Realme devices specifically, there was a resolved issue where upgrading from Android 11 to Android 12 would cause these devices to lose access to Intune-managed resources entirely due to OEM-specific MDM header handling. If you're still seeing enrollment failures on these brands post-upgrade, install the latest OTA update from the OEM first. Microsoft confirmed the fix is rolled out on their side, but the device needs to be on a recent enough OEM build to pair with it correctly.

For Android 12 and later devices in general, be aware of a current active issue: Android 12 introduced a clipboard access toast notification that fires whenever any application touches the clipboard. Users running Company Portal version 5.0.5450.0 or later will see notifications like "Outlook pasted from your clipboard" appear during normal app use. This is an Android OS behavior, not a policy misconfiguration. The clipboard data is not stored locally or sent to Microsoft, it's purely a visual notification. Communicate this to users proactively so they don't flag it as a data breach.

For Android Enterprise personally-owned work profile enrollment failures, check that the user's Intune license is correctly assigned in Microsoft Entra ID (Azure AD) → Users → Licenses. Missing or incorrectly scoped licenses are a very common cause of enrollment failing silently at the token exchange step. The error shown in Company Portal will look like a generic network error, which is misleading.

# Verify Intune license assignment via Microsoft Graph (PowerShell)
Connect-MgGraph -Scopes "User.Read.All", "Directory.Read.All"
Get-MgUserLicenseDetail -UserId "user@yourdomain.com" |
  Select-Object SkuPartNumber

Look for INTUNE_A, EMS, or M365_F1 in the output. If none of those appear, the user can't enroll devices regardless of any other configuration.

Windows device enrollment errors are the most diagnosable category in Intune because Windows writes detailed MDM enrollment events to dedicated event logs that most people don't know exist. Once you find these logs, the root cause usually becomes obvious within a minute.

Open Event Viewer on the affected Windows device. Navigate to Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin. This is your primary diagnostic source. Sort by date descending and look for Error-level events. The most common enrollment-blocking events you'll find here:

• Event ID 32, MDM enrollment failed; usually a certificate issue or connectivity problem to the enrollment endpoint
• Event ID 64, Certificate installation failure during enrollment; the MDM agent couldn't install the required client certificate
• Event ID 76, Policy application failure; a specific configuration policy failed to apply after enrollment completed

For Event ID 64 specifically, certificate installation failures, this directly maps to a known issue where the MDM agent mishandles failed MDM certificate installations. On macOS the result is automatic unenrollment (discussed later), but on Windows you'll see enrollment appear to succeed and then silently degrade. The fix is to clear the existing enrollment state and re-enroll cleanly:

# Remove stale MDM enrollment state (run as Administrator)
# First, identify the enrollment ID
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Enrollments" |
  Select-Object -ExpandProperty PSChildName

# Then remove the specific enrollment entry (replace {GUID} with actual ID)
Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Enrollments\{GUID}" -Recurse -Force

# Clear the enrollment task schedule entries
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" |
  Unregister-ScheduledTask -Confirm:$false

After running this, go to Settings → Accounts → Access work or school, disconnect the existing work account, restart the device, and re-enroll. This clears the corrupted enrollment state that causes persistent sync failures even when the device shows as enrolled in the admin center.

For hybrid Azure AD joined devices that can't sync with Intune, also check Applications and Services Logs → Microsoft → Windows → AAD → Operational for token acquisition failures alongside the MDM logs. Hybrid join problems almost always have a footprint in both log channels.

App Protection Policies (APP) in Microsoft Intune are the layer that controls data handling in managed apps, things like blocking copy-paste from managed to unmanaged apps, requiring PIN, or wiping corporate data on unenrolled devices. When APP isn't applying, users typically notice because managed app restrictions aren't working, or conditional access blocks them despite compliant devices. Here's how to work through it.

Start in the Intune admin center at Apps → Monitor → App protection status. Find the user and check their APP status. You're looking for "Checked in" status. If it shows "Not checked in" or the policy assignment is blank, the policy isn't reaching the app at all. This is almost always an assignment issue, the policy isn't targeted at the right user group.

Go to Apps → App protection policies → [Your policy] → Properties → Assignments. Verify the user's group is listed under Included groups. A common mistake is assigning APP to a device group instead of a user group, APP is always user-targeted, not device-targeted. If the assignment looks correct, check for an exclusion group that might be inadvertently capturing the user.

If assignment is correct but policy still isn't applying, the issue is often the parent setting problem. Microsoft identified a category of Office settings in the Settings Catalog that don't automatically enable required parent settings when a child setting is configured. These settings are now marked as (deprecated) in the Settings Catalog UI. If you see any deprecated markers on your APP-related settings, you need to manually enable the parent setting first, then re-configure the child setting. This is a known active issue with no automatic remediation, it requires manual policy reconstruction.

# Check APP status for a specific user via Graph API
GET https://graph.microsoft.com/v1.0/deviceAppManagement/managedAppStatuses('userstatus')

# Or use PowerShell with the Graph module
Get-MgDeviceAppManagementManagedAppStatus -ManagedAppStatusId "userstatus"

For Android APP issues post-Android 12 upgrade, the clipboard toast notifications (described in Step 2) sometimes cause users to believe their APP isn't working correctly, they see unexpected messages and assume something is broken. Verify with the user whether their concern is a behavior change or a complete policy failure before diving into technical remediation. Many APP "issues" reported after Android 12 upgrades are actually just this notification behavior.

Once you've corrected the assignment and parent settings, have the user sign out of the affected managed app completely, sign back in, and wait up to 8 hours for the policy to fully propagate. The Intune APP check-in cycle isn't instant.

Compliance policies are the backbone of Intune's conditional access story, get them wrong and either devices get incorrectly blocked or non-compliant devices slip through. There's a live bug affecting compliance messaging right now that's tripping up a lot of organisations, and it's worth understanding exactly what it does and doesn't affect.

Here's the situation: when you configure a compliance policy with the Valid operating system builds setting and specify multiple OS build ranges, devices that fall outside those ranges show a remediation message in Company Portal. That message is supposed to list all valid ranges the user could update to. Right now, it only shows the first range. The compliance policy itself is enforcing all ranges correctly, this is purely a display bug in Company Portal for Windows 10/11. Users aren't getting wrong guidance on whether they're compliant; they're just not seeing all their valid update targets.

The practical impact: users whose build falls within a second or third valid range may think they need to update even when they don't, and they'll contact your helpdesk. Your communication to users should be: "Check the OS build range in your compliance policy settings, not just the Company Portal message."

For the underlying compliance policy configuration, go to Devices → Compliance policies → [Policy] → Properties and review the Device Health and System Security sections carefully. The most common misconfiguration I find is BitLocker compliance set to Required on devices that have BitLocker pending a restart, the policy reports the device as non-compliant even though BitLocker is technically enabled. Have the user restart the device, then trigger a compliance re-evaluation:

# Force compliance evaluation on Windows device (run as Administrator)
Start-Process -FilePath "C:\Windows\System32\deviceenroller.exe" -ArgumentList "/c /AutoEnrollMDM"

# Or trigger sync via scheduled task
Start-ScheduledTask -TaskName "\Microsoft\Windows\EnterpriseMgmt\*\Schedule created by enrollment client"

After forcing the evaluation, check the Intune admin center under Devices → [Device] → Device compliance → Check compliance. The compliance state should update within a few minutes. If BitLocker was the blocker and the user restarted, it should flip to Compliant. If the device remains non-compliant after this, pull the compliance report from Reports → Device compliance → Reports → Noncompliant devices to see exactly which policy setting is failing.

For Azure enterprise applications not appearing in Company Portal for Windows, this is another current active known issue Microsoft is investigating. If users report missing apps in the Company Portal website or the Windows app, verify first whether the apps are Azure enterprise apps versus apps deployed directly through Intune. If they're Azure enterprise apps and they're assigned but not showing, this is the known issue. The workaround is to provide users direct links to the applications through MyApps (myapps.microsoft.com) while Microsoft resolves this on the backend.