Intune Autopilot Troubleshooting: Fix Common Failures

The Error

You've shipped a laptop to a remote user. They power it on, connect to Wi-Fi, and the Windows Autopilot provisioning screen appears. Then one of these happens:

Something went wrong.
Your organization's MDM terms of use could not be retrieved.
Error code: 0x800705b4

— or —

Account setup couldn't be completed. Please contact your administrator.
Error code: 80180018

— or —

The provisioning package could not be applied.
Error: 0x800706BA

Alternatively, the device just sits on the Enrollment Status Page (ESP) indefinitely — "Setting up your device for work" with a spinner that never completes. After 40+ minutes, it either hard-fails or the user force-reboots and lands on the desktop with half-applied policies.

You'll see these scenarios across three main situations: net-new device deployments that were never properly hash-registered, re-used hardware that still has a stale Autopilot object, or environments where the Intune/Azure AD configuration drifted after initial setup. Each has a different root cause and a different fix.

Root Cause

Error 0x800705b4 — MDM Terms of Use Not Retrieved

This one is almost always a connectivity or MDM enrollment URL resolution failure. The device is trying to reach enrollment.manage.microsoft.com and enterpriseregistration.windows.net during the out-of-box experience. If the user's network is blocking these endpoints — corporate proxy without OOBE bypass, captive portal, or split-DNS misconfiguration — the MDM terms of use call fails silently and surfaces this error code.

The second cause: the device hash exists in Autopilot, but the assigned user's license doesn't include Intune. The enrollment token gets issued, MDM enrollment is attempted, and then the license check at devicemanagement.microsoft.com returns a 403. The error code is misleading — it looks like a network problem but it's actually an authorization failure.

Error 80180018 — Enrollment Blocked

This is a device enrollment restriction conflict. You have an Enrollment Restriction policy scoped to block personally-owned Windows devices, and the device being enrolled isn't marked as Corporate in Intune yet. Even with a valid Autopilot registration, if the corporate device marker hasn't propagated before the restriction check fires, enrollment is blocked.

The timing gap is the issue: Autopilot device import sets the ownership flag, but that flag sync from Autopilot service to Intune device records can lag 15-30 minutes after import. If someone tries to enroll immediately after uploading the hardware hash CSV, they'll hit this.

ESP Timeout — Stuck Provisioning

The Enrollment Status Page tracks three phases: Device setup, Account setup, and (for user-driven) the user ESP. Each phase has a configurable timeout. The default is 60 minutes per phase, but the actual failure point is usually one of these:

• A required app is blocked from installing — Win32 app dependencies not met, or the Intune Management Extension hasn't installed yet when the app install is attempted.
• Certificate deployment failure — SCEP or PKCS certificate profiles failing silently because NDES is unreachable or the connector is down.
• A required policy is marked as blocking in ESP config but never delivers — this happens when you've set "Block device use until all apps and profiles are installed" and one policy targets a group the device/user isn't actually a member of yet.

The ESP doesn't tell you which item is blocking. You have to dig into the IME logs to find it.

The Fix

Step 1: Verify the Device Hash Registration

Before anything else, confirm the device is actually in your Autopilot inventory and the profile is assigned. Run this against Graph:

# Requires Microsoft.Graph PowerShell module
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"

$serialNumber = "YOUR_SERIAL_HERE"
$device = Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -Filter "contains(serialNumber,'$serialNumber')"
$device | Select-Object SerialNumber, Model, GroupTag, DeploymentProfileAssignmentStatus, DeploymentProfileAssignedDateTime

You want to see DeploymentProfileAssignmentStatus as assigned — not notAssigned or pending. If it's pending, the device is in the right group but the profile hasn't synced yet. Force a sync from the Intune portal under Devices > Enrollment > Windows > Windows Autopilot Devices and wait 5 minutes.

Step 2: Fix License Assignment

If you're seeing 0x800705b4 and connectivity is confirmed fine, check the target user's license:

Connect-MgGraph -Scopes "User.Read.All"
$upn = "user@yourdomain.com"
$licenses = Get-MgUserLicenseDetail -UserId $upn
$licenses | Select-Object SkuPartNumber

You need to see INTUNE_A, M365BP, SPE_E3, or similar SKU that includes Intune. If it's missing, assign the license and retry enrollment. Don't waste time looking at network traces until you've ruled this out.

Step 3: Fix the Enrollment Restriction Conflict (80180018)

Go to Intune > Devices > Enrollment > Enrollment Restrictions. Find your Windows restriction policy and check if "Personally owned" is set to Block. If it is, and your Autopilot device hash was imported recently, the device ownership might not have propagated.

Verify the device shows as Corporate-owned in Intune:

$autopilotDevice = Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -Filter "contains(serialNumber,'$serialNumber')"
$autopilotDevice.EnrollmentState
$autopilotDevice.ManagementCertificateExpirationDate

If the device isn't appearing as corporate, re-import the hash and wait a full 30 minutes before attempting enrollment. Alternatively, temporarily move the user to a group that has a less restrictive enrollment restriction scoped to it — useful in a pinch for remote deployments.

Step 4: Diagnose ESP Timeouts with IME Logs

When the ESP is hanging, get to a command prompt during OOBE (Shift+F10) and pull the IME logs:

type C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log | findstr /i "error\|fail\|timeout\|blocked"

Look for lines referencing specific app IDs or policy GUIDs that are repeatedly retrying. Also check:

type C:\Windows\Temp\MdmDiagnostics\MdmDiagReport_RegistrationInfo.xml

Cross-reference the failing GUID in the Intune portal by searching under Apps or Configuration Profiles. Nine times out of ten, you'll find a Win32 app with a bad detection rule or a SCEP profile pointing at a dead NDES URL.

Once you identify the blocking item, either fix the app/policy or — if you need to unblock the user now — temporarily remove that item from the ESP blocking list under Devices > Enrollment > Enrollment Status Page > [Your Profile] > Settings and set "Show error when installation takes longer than specified minutes" to a higher value, or uncheck the specific blocking requirement.

Step 5: Collect a Full Autopilot Diagnostic

Microsoft's built-in diagnostic tool captures everything needed for escalation or deeper analysis:

# Run during OOBE via Shift+F10, or after enrollment from an admin prompt
mdmdiagnosticstool.exe -area Autopilot -cab C:\Temp\AutopilotDiag.cab

Extract the cab and look at AutopilotDDSZTDFile.json for profile assignment details and tpm.txt if you're seeing TPM attestation failures on specific hardware models.

For a complete reference on diagnostic collection, see Microsoft's Autopilot OOBE troubleshooting guide and the Enrollment Status Page documentation.

Prevention

Pre-flight Checklist Before Every Deployment Wave

Autopilot failures are almost always detectable before the device is in the user's hands. Build this into your deployment runbook:

1. Validate hash import and profile assignment — Run the Graph query above for every serial in the batch. Don't ship until DeploymentProfileAssignmentStatus is assigned.
2. License check at scale — Export your pending Autopilot users and cross-reference against licensed users. A simple Graph query comparing Autopilot device assigned user UPNs against Intune-licensed accounts catches this before deployment.
3. ESP timeout hygiene — Audit your ESP-blocking apps quarterly. Every Win32 app marked as required and blocking in ESP should have a verified detection rule. Use the Win32 app troubleshooting documentation to validate detection logic before adding apps to blocking ESP policies.
4. Network endpoint testing — If deploying to remote or home users, document which Autopilot endpoints must be reachable and provide that list to the user or IT contact on-site. The critical ones: ztd.dds.microsoft.com, cs.dds.microsoft.com, login.microsoftonline.com, and enrollment.manage.microsoft.com.

Monitoring and Alerting

Set up an Intune Device Enrollment alert under Tenant Administration > Alerts for enrollment failures. Also build a Logic App or Power Automate flow that queries the Graph /deviceManagement/autopilotEvents endpoint daily and flags any devices with deploymentState of failure or unknown. Catching a failed Autopilot event the same day beats getting a ticket from a user who's been stuck for three days waiting for IT to respond.

Autopilot is reliable when the prerequisites are solid. Most failures in production trace back to a race condition on import timing, a missed license, or an ESP blocking policy referencing something that was never fully tested. Nail those three areas and you'll cut your Autopilot failure rate to near zero.