Windows Autopilot enrollment errors and profile drift remediation

Overview

Windows Autopilot problems fall into two different categories: enrollment-time failures that prevent a device from completing setup, and post-enrollment drift that leaves a previously provisioned device outside its intended configuration. The same symptom can also have more than one cause, so an error code should narrow the investigation rather than dictate a single fix.

This runbook starts with evidence collection, then covers common failure paths for Microsoft Entra join, error 0x80180014, device import, Enrollment Status Page stalls, and recurring profile drift.

Before changing device records

• Identify the failed phase. Record whether the failure occurred during device preparation, device setup, or account setup. Capture the displayed error, timestamp, deployment mode, profile assignment, device serial number, and correlation identifiers before resetting the device.
• Collect diagnostics. Use the Windows Autopilot diagnostics page when enabled, MDM diagnostic reports, and the relevant Windows event logs. For Enrollment Status Page failures, preserve the Intune Management Extension logs and EnrollmentStatusTracking state before retrying.
• Check service and assignment context. Confirm network access to required Microsoft endpoints, device time, licensing, enrollment restrictions, deployment-profile assignment, group membership, and whether the device already has records in Windows Autopilot, Intune, or Microsoft Entra ID.
• Choose the least destructive correction. Correct an assignment, restriction, app, or stale deployment state before deleting device objects. Deregistration and reimport can be appropriate when the evidence points to an inconsistent registration, but they should not be the automatic first response to every join error.

Error 0x801C03ED during Microsoft Entra join

When 0x801C03ED appears around the AADEnroll or Microsoft Entra join stage, treat the stage and error as diagnostic coordinates rather than proof of a bad password or a specific token defect.

• Inspect the Autopilot event trail. Review Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot and the related device-registration events. Correlate the failure with the stage reported on screen.
• Verify prerequisites first. Check device time, required network endpoints, deployment-profile assignment, enrollment eligibility, and the device records across Windows Autopilot, Intune, and Microsoft Entra ID.
• Recreate registration only when supported by evidence. If diagnostics show a missing, stale, or inconsistent device object, follow Microsoft's documented deregistration and registration sequence. Avoid presenting hardware-hash reimport as a universal fix because the same stage can fail for different reasons.

Error 0x80180014

Microsoft documents multiple conditions for 0x80180014. Start with the deployment history and tenant enrollment settings instead of assuming every occurrence has the same cause.

• Reused self-deploying or pre-provisioned device. A reset or redeployed device can be blocked from repeating the flow. In the Intune admin center, open Windows enrollment > Windows Autopilot devices, select the affected device, and use Unblock device when that action is available. Then redeploy the assigned profile.
• Windows MDM enrollment blocked. Review the tenant's device-platform enrollment restrictions and confirm Windows (MDM) is allowed for the affected user and device scenario.
• Ownership restriction conflict. If personally owned Windows enrollment is blocked, verify that the device is correctly registered as a corporate Windows Autopilot device. Do not weaken a recommended ownership restriction fleet-wide merely to bypass one inconsistent record.
• Delete only when necessary. If Unblock device is unavailable or the records remain inconsistent, follow the documented deregistration sequence and confirm which Windows Autopilot, Intune, and Microsoft Entra objects must be removed before registering the device again.

Hardware-hash and CSV import failures

Import failures are separate from a device that has already reached the enrollment flow. Keep the original CSV and import result so the registration problem can be reproduced.

• Recollect the hardware identity. If the import reports invalid device data, collect a new hardware hash from the device with a supported method and compare the required CSV headers and fields.
• Avoid spreadsheet rewriting. Microsoft warns that editing an Autopilot CSV in Excel or another editor can introduce characters that invalidate the file. Preserve the expected encoding and structure.
• Confirm registration before deployment. Verify that the import completed, the device appears in Windows Autopilot devices, and the intended deployment profile is assigned before returning the device to OOBE.

Enrollment Status Page stalls at Device setup

The Enrollment Status Page tracks apps, certificates, network profiles, and selected policy-related work during device setup. A stall can reflect a failed tracked item, an app-assignment problem, conflicting installer behavior, network delay, or a timeout that is too short for the required workload.

• Find the tracked item that failed. Inspect HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking and the Intune Management Extension logs. An app InstallationState value of 4 indicates an error that stops further ESP app installation.
• Review required assignments. Confirm that blocking apps are assigned as required in the correct device or user context and that their applicability rules match the enrollment phase.
• Avoid competing installers. Microsoft advises against mixing line-of-business MSI and Win32 applications during Windows Autopilot because both can contend for TrustedInstaller and cause ESP failure.
• Keep the blocking list intentional. Block only on applications genuinely required before first use. Test each blocking app independently and through the complete deployment sequence.
• Use timeouts diagnostically. A longer timeout can help a legitimately slow deployment, but it does not repair a failed application. Compare the configured limit with the number, size, dependencies, and restart behavior of required apps.

Profile drift after enrollment

A device that completed enrollment and later stopped matching its baseline is an ongoing-management problem, not an Autopilot enrollment failure. First distinguish stale reporting from a real difference between intended and effective configuration.

• Refresh the evidence. Trigger a device sync, record the last check-in and signal timestamps, and re-evaluate the affected control. A successful sync confirms communication; it does not by itself prove that every setting converged.
• Compare assignments and effective state. Review every profile, filter, group, security baseline, script, and application that can manage the setting. Conflicting owners can repeatedly alternate the effective value.
• Separate user, policy, and software changes. Use local event data and management history to determine whether a user changed the setting, another profile overwrote it, or an operating-system or application update reset it.
• Verify remediation. After correcting scope or configuration, recheck the actual device state. Retain the previous value, desired value, source policy, action, timestamp, and verification result.
• Escalate recurring patterns. Repeated drift across the same device group, application version, or profile combination usually calls for a baseline or assignment correction rather than repeated one-device fixes.

A practical decision path

• Setup never completed. Troubleshoot the exact Autopilot or ESP phase, preserve diagnostics, and correct registration, eligibility, assignment, network, or application failures before retrying.
• Setup completed but the device is now noncompliant. Treat the case as drift: refresh telemetry, compare desired and effective state, resolve conflicts, remediate, and verify.
• The same problem returns. Look for a fleet-level pattern and change the source baseline, deployment ring, application package, or profile ownership. Record the exception and owner if immediate convergence is unsafe.

Related resources

• Build the preventive control floor with the Windows Autopilot security baseline for mid-market teams.
• Examine recurring deviation and evidence in Configuration drift in endpoint management.
• Use the full lifecycle model in Zero-touch endpoint management for security teams.
• Explore Gideon Endpoint Management for provisioning, posture, and remediation evaluation paths.

Primary references

• Microsoft documents reuse, enrollment restrictions, and the Unblock device workflow in the Windows Autopilot troubleshooting FAQ.
• Microsoft maintains current deployment caveats in Windows Autopilot known issues.
• Microsoft describes blocking apps, time limits, and tracked phases in Set up the Enrollment Status Page.
• Microsoft documents the EnrollmentStatusTracking registry data and app failure states in Troubleshoot the Enrollment Status Page.

How to use this resource

Use this runbook during a pilot or support escalation. Capture evidence before reset, assign one owner for the next diagnostic action, and define success as a completed deployment or a verified return to the intended configuration—not merely the absence of the original error screen.