Windows Autopilot Errors: Fix Guide 2026

Why Autopilot Tickets Are the Worst Kind of Ticket

Autopilot tickets have a particular flavor. The user is sitting in front of a half-provisioned laptop, the Enrollment Status Page is at 47% and has been for an hour, and you've got basically no diagnostic surface to work with until you can either get them into Windows or pull the device back to your bench. Half the time the error message is just "Something went wrong. 0x80180005" with no further context. Helpful, right?

Honestly, this is the ticket type I dread most on a Monday morning — and I say that as someone who's run Autopilot rollouts for three different orgs.

So here's the structured triage path we actually use to close those tickets without sending devices back through the wipe-and-retry loop. It covers both classic Autopilot profiles and the 2026 Windows Autopilot device preparation model (sometimes called Autopilot v2), the Enrollment Status Page (ESP) failure modes you'll actually see in production, and the Hybrid Entra Join edge cases that just keep refusing to die — even though Microsoft would clearly like them to.

Know Which Autopilot You're Actually Troubleshooting

Before you do anything else, identify which deployment path the device is on. The diagnostic steps are different, and people regularly burn an afternoon checking classic Autopilot profile assignments on a device that's actually using device preparation policies. (Yes, I've done it. More than once.)

Classic Autopilot (user-driven, Entra-joined) — the original flow. Profiles assigned to device groups, hardware hash registered ahead of time, ESP shows the familiar three-phase progress.
Classic Autopilot Hybrid Entra Join — domain-joined OOBE via the Intune Connector for Active Directory. Microsoft's been pushing customers off this for two years now. It still works in 2026, but it's on its last legs.
Self-deploying mode — kiosks, shared devices, no user sign-in at OOBE. Requires TPM 2.0 attestation against Microsoft's attestation service.
Pre-provisioning (white glove) — IT runs phase one, ships the device, end user finishes phase two. Useful for any deployment where you want apps and policies baked in before the user touches the device.
Windows Autopilot device preparation (v2) — Entra-joined only, no hardware hash required, no device groups, profile-and-target assignment is replaced by a single user-targeted policy. This is the path Microsoft now recommends for all new Entra-joined deployments.

If you're not sure which path a device's on, run this on the device after you can sign in:

Get-AutopilotDiagnostics -Online

If Get-AutopilotDiagnostics isn't installed, grab it with Install-Script Get-AutopilotDiagnostics -Force. The output tells you the deployment profile name, ESP phase timings, every tracked policy and app, and the exit code of anything that failed. It's the single most useful Autopilot diagnostic tool out there — and weirdly, it's also one of the most underused.

Prerequisites: Verify Before You Touch the Device

Most Autopilot tickets resolve at the prerequisite stage. Walk this list before you start collecting logs.

Intune license assigned to the user — Microsoft 365 E3/E5, Business Premium, or EMS E3/E5. Self-deploying mode also requires a device-targeted Intune license, or you'll see 0x801c03ea.
MDM user scope includes the user — Entra admin center → Mobility (MDM and MAM) → Microsoft Intune. Set to All, or include the user's group.
Device platform restrictions allow Windows (MDM) personal/corporate — under Intune → Devices → Enrollment → Device platform restrictions.
Network endpoints reachable — the OOBE network has to reach *.manage.microsoft.com, *.dm.microsoft.com, login.microsoftonline.com, graph.microsoft.com, ztd.dds.microsoft.com, cs.dds.microsoft.com, and activation-v2.sls.microsoft.com. Captive-portal Wi-Fi will silently break Autopilot, so use a hardwired or open SSID for OOBE.
Time and date correct — TPM attestation and certificate validation both fail hard if the device clock's more than a few minutes off. New machines pulled from a warehouse after a year on the shelf are repeat offenders here.
TPM 2.0 enabled and ready — required for self-deploying mode and strongly recommended for everything else. Run Get-Tpm in WinPE or after sign-in to confirm.
Windows 11 24H2 or later — device preparation policies require 24H2. Devices imaged with older media will fall back to classic Autopilot, or fail outright.

The Enrollment Status Page Is Your Diagnostic Surface

The ESP runs in three phases: Device preparation, Device setup, and Account setup. Every Autopilot failure that survives prerequisites manifests at one of these phases — and knowing which one narrows the problem down dramatically.

Phase 1: Device preparation

This phase covers "Identifying your device" and "Preparing your device for mobile management". If you're stuck here, the device hasn't successfully MDM-enrolled yet. Likely causes:

Network can't reach the discovery endpoints (most common — usually a Conditional Access policy blocking the OOBE sign-in, or a proxy intercepting TLS).
The hardware hash isn't registered (classic Autopilot only — device preparation doesn't need this).
The user's MDM scope doesn't include them, or no Intune license is assigned.
For Hybrid Join: the Intune Connector for AD is offline, the connector account password expired, or domain controller connectivity from the OOBE network is broken.

Phase 2: Device setup

This is where required apps, scripts, and policies install before the user signs in. Most "ESP stuck at 23%" tickets are stuck right here, and the root cause is almost always a single failing required app.

Win32 apps with bad detection rules will retry indefinitely until ESP times out.
PowerShell scripts that prompt for input or hang on a network call will block the phase.
A required certificate profile that depends on an unreachable internal CA will hang.
If you set Block device use until required apps are installed, every required app must complete or ESP fails at the timeout.

The fix is almost always to identify the failing component, fix it in Intune, and let ESP retry — not to wipe and start over. Pull the IME logs (see below), and you'll usually spot the offender within thirty seconds of opening them.

Phase 3: Account setup

User-targeted apps and policies install after the user signs in. Failures here are less catastrophic — the user can normally sign in and use the device while the helpdesk fixes whatever's broken — but they still generate tickets.

Decoding the Autopilot Error Codes You'll Actually See

0x80180005 — DM_E_GENERIC

The most generic error in Autopilot's catalog and, consequently, the most reported. It almost always means the MDM enrollment request was rejected by Intune. Real causes:

The device was previously enrolled and Intune still has a stale device record. Resolution: find the device in Intune by serial number, delete it, then retry.
The user has hit the device cap (default 15). Increase the cap in Entra under Devices → Device settings, or remove old devices from the user.
Conditional Access is blocking the enrollment sign-in. Exclude the Microsoft Intune Enrollment and Microsoft Intune service principals from policies that require compliant device or hybrid join — those checks can't pass during enrollment because the device isn't enrolled yet. (Chicken, meet egg.)

0x801c03ed — STATUS_NOT_SUPPORTED (this device must be reset)

Famous for being the most demoralizing error message in Autopilot. It usually means the device is already joined to Entra ID under a different identity, or it was hybrid-joined to a domain it can no longer reach. Resolution path:

dsregcmd /leave
dsregcmd /status
# Confirm AzureAdJoined: NO and DomainJoined: NO
# Then retry Autopilot

If dsregcmd /leave doesn't actually take the device out of Entra (it sometimes silently fails on devices with broken PRTs), boot to recovery and reset. The "this device must be reset" message is honest in that case.

0x801c03ea — TPM attestation failure

Self-deploying mode only. Either the device's TPM endorsement key isn't recognized by Microsoft's attestation service (older or off-brand TPMs), or TPM is just disabled in firmware. Run Get-Tpm in WinPE; if TpmReady is False, fix it in firmware before retrying. If the TPM is fine but attestation still fails, the device manufacturer needs to upload the EK certificates to Microsoft — which sounds exotic, but it's a real situation that occurs with some white-label OEMs.

0x800705b4 — Timeout

ESP ran past its configured timeout (default 60 minutes). Don't reflexively raise the timeout to 240 minutes — find the failing component first. Almost always a Win32 app with bad detection.

0x80070774 — Could not be resolved

DNS broke during enrollment. Captive portal, split-tunnel VPN, or a proxy that doesn't allow OOBE traffic. Test by retrying on a known-clean network.

0x80180014 — MDM_E_NOT_SUPPORTED_DEVICE_OS_VERSION

The device platform restrictions in Intune are blocking this Windows version. This one's common after a fresh tenant, where someone tightened the platform restrictions and forgot Windows 11 Home (which can't be MDM-enrolled at all) or set a minimum OS version above 24H2.

0x80180023 — MDM_E_NOT_FOUND

No Autopilot profile assigned to the device, or assigned but not yet synced. For classic Autopilot, confirm the device is in the assigned group and the profile shows Assigned status. For device preparation, confirm the user is in the targeted group of the Device Preparation policy. Profile assignment can take 15 minutes to propagate after group membership changes — be patient before you escalate.

Pulling the Logs That Actually Tell You Something

The Autopilot diagnostic surface in 2026 is significantly better than it was three years ago. Use these in order:

1. `Get-AutopilotDiagnostics`

Run from an elevated PowerShell on the device after sign-in:

Install-Script Get-AutopilotDiagnostics -Force
Get-AutopilotDiagnostics -Online
Get-AutopilotDiagnostics -ShowPolicies | Out-File C:\Temp\autopilot.txt

-Online resolves policy and app GUIDs to friendly names by querying Graph. -ShowPolicies dumps every CSP policy attempted with its result code. This is the fastest way to find a failing policy you didn't even know was assigned.

2. `MdmDiagnosticsTool.exe`

Built right into Windows. From OOBE, press Shift+F10 to open a command prompt, then:

MdmDiagnosticsTool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning;TPM -zip C:\Temp\mdmlogs.zip

This is the bundle Microsoft Support will ask you for if you open a case. It's also what you should pull before wiping the device, because most of the diagnostic state lives in the user profile that gets destroyed by reset.

3. The IME log directly

The Intune Management Extension log lives at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. Open it with CMTrace and search for "app result", "policy result", or "FailureReason". For Win32 apps that fail in ESP, this is where the actual MSI exit code and PowerShell stderr show up.

4. Event Viewer

Two channels matter: Applications and Services Logs → Microsoft → Windows → ModernDeployment-Diagnostics-Provider → Autopilot and ...DeviceManagement-Enterprise-Diagnostics-Provider → Admin. The Autopilot channel logs profile retrieval and OOBE phase transitions; DeviceManagement-Enterprise logs every CSP policy result with its exact error code.

The Device Preparation Migration Trap

If your tenant created its first Device Preparation policy in 2025 or later, you've probably hit one of these. Device preparation looks similar to classic Autopilot, but the assumptions underneath are different.

No hardware hash needed — but a device that's already registered with a hash will still try to use the classic profile. So if a device was hash-registered for testing and you've since moved to device preparation, deregister the hash from Intune → Devices → Enrollment → Devices, or the device will keep getting the classic profile.
Targeted at users, not devices — assignment is to a user group only. There's no device group on a device preparation policy. Helpdesk teams used to classic Autopilot reflexively look for a device group assignment that just doesn't exist.
One policy per user — if a user is in two device preparation groups, the policy that wins is essentially undefined. Audit overlap with the Conflict tab in the policy view.
Co-managed devices not supported — device preparation doesn't work for devices that are co-managed with Configuration Manager. Use classic Autopilot for those.

Hybrid Entra Join Autopilot: Specific Gotchas

Hybrid Join Autopilot still works in 2026, but it's living on borrowed time. Microsoft's official guidance is to migrate to cloud-native Entra Join, and most of the recent product investment has gone into device preparation. If you have to support hybrid for now:

Intune Connector for Active Directory must be on a 2025+ build — old connectors are deprecated, and tickets where "hybrid join started failing last week" are usually a connector that auto-updated and lost its service account permissions.
The OOBE network must reach a domain controller — directly, or via a VPN that connects pre-logon (Always On VPN with device tunnel, or a built-in VPN client triggered by the OOBE script).
The OU for new computer objects must allow the connector account to create accounts — and the OU has to be configured in the connector itself, not just in Intune. Two places to check, both of which I've forgotten exactly once.
Watch for SCP misconfiguration — the AD service connection point overrides Entra discovery. Run dsregcmd /status after the Hybrid Join attempt; if AzureAdPrt: NO persists after a reboot and a sign-in, the SCP is pointing somewhere wrong.

The Five-Minute Triage Script

For helpdesk staff who need to triage an Autopilot device before escalating, this is the quick first pass:

# Run from elevated PowerShell on the device after sign-in
dsregcmd /status | Select-String "AzureAdJoined|DomainJoined|TenantId|Mdm|AzureAdPrt"
Get-AutopilotDiagnostics -Online | Select-String "Failed|Error|Timeout"
Get-WinEvent -LogName "Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot" -MaxEvents 50 |
  Where-Object { $_.LevelDisplayName -in 'Error','Warning' } |
  Format-Table TimeCreated, Id, Message -AutoSize -Wrap

Three commands. If those don't surface the cause within five minutes, the device needs a deeper look — usually with MdmDiagnosticsTool.exe output and an IME log review.

When to Reset, and When Not To

The instinct on a stuck Autopilot device is to reset and retry. Sometimes that's right. More often, though, it's how a one-hour ticket becomes a four-hour ticket — because the underlying issue is in the tenant, not on the device.

Reset when: the device shows 0x801c03ed after a previous abandoned enrollment, or the OS image itself is suspect (consumer build, OEM customization that breaks Autopilot, leftover bloatware that fails ESP).

Don't reset when: ESP is timing out on a required app (the same app will fail again), Conditional Access is blocking enrollment (same), the user has hit the device cap (same), the device platform restriction is wrong (same), or the assigned profile is wrong (same).

The pattern's pretty straightforward, really: if the failure is in something stored on the device, reset can fix it. If the failure is in something stored in the tenant, reset just makes you do the OOBE typing twice.

Frequently Asked Questions

How do I find a stuck Autopilot device's serial number from OOBE?

From any OOBE screen, press Shift+F10, then run wmic bios get serialnumber (or Get-CimInstance Win32_BIOS | Select SerialNumber in PowerShell). Use that serial to look up the device in Intune. If you need the hardware hash, Get-WindowsAutopilotInfo -Online will collect and upload it directly.

Can I skip the Enrollment Status Page if it's stuck?

Only if your ESP profile has Allow users to skip after error enabled and the timeout has been reached. Otherwise no — and honestly, you shouldn't, because skipping leaves the device half-provisioned and you'll be back tomorrow with the same ticket plus a non-compliant device. Fix the failing component instead.

Why does Windows Autopilot device preparation say my device isn't supported?

Three common reasons: the device is running Windows 11 23H2 or earlier (24H2 is the minimum), the device is already enrolled in another tenant or is in a co-management scenario, or the user just isn't in the targeted group of any device preparation policy. The error message itself doesn't distinguish between them — check all three.

How long should an Autopilot deployment take in 2026?

For a typical user-driven Entra Join with a small ESP profile (a few required apps, a handful of policies), 15 to 30 minutes is normal on a modern laptop with gigabit internet. Anything past 45 minutes is a sign that something is retrying, not that the deployment is "almost done." Pull the logs.

Do I still need to upload hardware hashes for new devices?

For classic Autopilot profiles, yes. For Windows Autopilot device preparation, no — the user-targeted policy assigns the deployment to whichever device the user signs in to, with no pre-registration. This is the single biggest operational reason to migrate to device preparation, and it's why Microsoft is pushing it so hard.