Microsoft Autopilot is one of the best tools in the Intune ecosystem for zero-touch device provisioning. When it works, a new employee opens their laptop, signs in, and everything configures itself. But when Autopilot fails, the troubleshooting process can be time-consuming and opaque. Error messages are vague, logs are scattered across multiple locations, and the failure could stem from network issues, configuration problems, or backend service delays.
We have deployed and troubleshot Autopilot across hundreds of environments. These are the ten most common failures we encounter and the specific steps to resolve each one. Bookmark this page because you will need it the next time a deployment goes sideways.
1. ESP Stuck at "Identifying"
The Enrollment Status Page (ESP) shows "Identifying" as its first step, which is when the device contacts the Autopilot service to determine its deployment profile. When it gets stuck here, it means the device cannot reach Microsoft's backend or the service does not recognize the device.
What is happening: During the "Identifying" phase, the device sends its hardware hash to the Autopilot service at ztd.dds.microsoft.com. The service looks up the hash in your tenant's Autopilot device list, finds the assigned deployment profile, and sends it back. If any step in this chain fails, the ESP stalls.
Fix 1: Verify network connectivity. The device needs HTTPS access to several Microsoft endpoints during Autopilot. Press Shift+F10 during the ESP to open a command prompt and test connectivity. Run ping login.microsoftonline.com and nslookup ztd.dds.microsoft.com. If DNS resolution fails, the network configuration is the issue. Check DHCP, DNS server settings, and any network isolation for the provisioning VLAN.
Fix 2: Check for proxy interference. If your network uses a web proxy or SSL inspection, it may be blocking or intercepting the Autopilot traffic. Autopilot requires direct (non-proxied) HTTPS access to Microsoft endpoints during OOBE. Configure a proxy bypass for *.microsoft.com, *.microsoftonline.com, *.windows.net, and *.azure.net. For SSL inspection, exclude these domains from certificate interception.
Fix 3: Re-import the hardware hash. If the hardware hash was corrupted during export or import, the Autopilot service will not find the device. Delete the device from the Autopilot devices list in the Intune admin center, re-collect the hardware hash from the device using Get-WindowsAutopilotInfo, and reimport it. Wait 15 minutes for the import to propagate before retrying.
Fix 4: Wait for service propagation. If you just imported the hardware hash, it can take up to 15 minutes to fully propagate. If you also just assigned a deployment profile, give it an additional sync cycle (up to 30 minutes). Retrying too quickly is the most common cause of false failures at this stage.
2. Device Not Appearing in Intune After Autopilot
The Autopilot deployment appears to complete (or partially complete), but when you check the Intune admin center, the device is not listed under Devices. This means enrollment did not fully succeed even if the user reached the desktop.
What is happening: Autopilot orchestrates two processes: Entra ID join and Intune MDM enrollment. The device can join Entra ID but fail to enroll in Intune, leaving it visible in Entra ID but missing from Intune.
Fix 1: Check Entra ID device limit. Each user has a maximum number of devices they can register in Entra ID (default is 50, but some tenants have this set lower). If the user has hit their limit, the join succeeds but enrollment fails. Check the user's device registrations in Entra ID and remove stale entries.
Fix 2: Verify MDM enrollment scope. In the Entra admin center under Mobility (MDM and WIP), verify that Intune MDM enrollment is configured for the user. If MDM user scope is set to "None" or to a specific group that does not include the user, enrollment will be silently skipped. Set it to "All" or ensure the user is in the designated group.
Fix 3: Check for duplicate device objects. If the same device was previously enrolled and not properly cleaned up, duplicate objects in Entra ID or Intune can block re-enrollment. Search for the device by serial number in both Entra ID Devices and Intune Devices. Delete any stale entries, wait 15 minutes, and retry.
Fix 4: Review enrollment restrictions. Intune enrollment restrictions can block specific platforms, OS versions, or personal devices. If the device falls outside your allowed parameters, enrollment will fail. Check Devices > Enrollment restrictions in the Intune admin center and verify the device meets all criteria.
3. Autopilot Profile Not Assigned
The device appears in the Autopilot devices list, but the profile assignment status shows "Pending" or "Not assigned" instead of "Assigned." Without a profile, the device goes through standard OOBE instead of the Autopilot experience.
What is happening: Autopilot profiles are assigned to device groups. The device must be a member of a group that has an Autopilot deployment profile assigned to it. If group membership or profile assignment is misconfigured, the device will not receive a profile.
Fix 1: Verify group membership. Check which group the Autopilot profile targets. Then verify the device is a member of that group. If you are using dynamic device groups (recommended for Autopilot), check the dynamic membership rule. A common rule is (device.devicePhysicalIDs -any (_ -contains "[ZTDId]")) which captures all Autopilot-registered devices. If you use a more specific rule, verify it matches the device attributes.
Fix 2: Wait for dynamic group evaluation. Dynamic groups in Entra ID do not update instantly. After importing a hardware hash, the device object needs to be created and then evaluated against dynamic group rules. This can take up to 30 minutes. Check the dynamic group's membership processing status. If it shows "Evaluation in progress," wait for it to complete.
Fix 3: Assign directly if needed. For urgent deployments, you can assign a profile directly to the device in the Autopilot devices list. Select the device, click "Assign profile," and choose the deployment profile. This bypasses group-based assignment and takes effect within minutes.
Fix 4: Check for conflicting profiles. If the device is a member of multiple groups with different Autopilot profiles assigned, the assignment may conflict. Ensure each device group targets only one Autopilot deployment profile. Use the Autopilot devices list to verify which profile is assigned to the specific device.
4. TPM Attestation Failures
Self-deploying mode and pre-provisioning (white glove) require TPM 2.0 attestation. If the TPM cannot attest, these deployment modes fail immediately with error codes like 0x800705B4 or 0x80070490.
What is happening: TPM attestation is a cryptographic process where the device proves its identity to the Autopilot service using the TPM's Endorsement Key (EK). This requires a functional TPM 2.0 chip, correct firmware, and a valid system clock for certificate validation.
Fix 1: Update TPM firmware. Older devices may ship with TPM firmware that has known attestation bugs. Check the OEM manufacturer's support site for TPM firmware updates. Lenovo ThinkPad models from 2019-2021, certain HP EliteBook models, and some Dell Latitude series have documented TPM firmware issues that specifically affect Autopilot attestation. Apply the firmware update from the BIOS/UEFI before retrying.
Fix 2: Clear the TPM. A previous OS installation or enrollment attempt may have left the TPM in a state that prevents attestation. Enter the device BIOS/UEFI settings and clear the TPM (sometimes listed as "Security Chip" or "TPM Reset"). This erases all TPM keys and returns it to factory state. The device will reinitialize the TPM on next boot. Note: clearing the TPM will invalidate any existing BitLocker keys tied to that TPM, so ensure you have recovery keys for any encrypted volumes.
Fix 3: Fix the system clock. TPM attestation validates certificates that are time-bound. If the device BIOS clock is off by more than a few minutes, certificate validation fails and attestation is rejected. Enter BIOS and verify the date and time are correct. A dead CMOS battery is a common cause of clock drift on older hardware.
Fix 4: Fall back to user-driven mode. If TPM attestation continues to fail and you cannot resolve the firmware issue, switch the device to user-driven deployment mode, which does not require TPM attestation. This is a workaround, not a fix, but it unblocks the deployment while you address the TPM issue separately.
5. Network and Proxy Issues
Autopilot requires access to a specific set of Microsoft endpoints over HTTPS. Network restrictions, firewalls, proxies, and DNS filtering can all interfere with this communication, causing failures at various stages of deployment.
What is happening: During Autopilot deployment, the device communicates with Microsoft endpoints for device registration, Entra ID authentication, Intune policy delivery, app downloads, and Windows Update. Blocking any of these causes a failure that may not clearly indicate a network issue.
Fix 1: Whitelist required endpoints. At minimum, the following endpoints must be accessible over HTTPS (port 443): login.microsoftonline.com, aadcdn.msftauth.net, ztd.dds.microsoft.com, cs.dds.microsoft.com, login.live.com, enrollment.manage.microsoft.com, portal.manage.microsoft.com, and config.edge.skype.com. Additionally, Windows Update endpoints must be reachable for ESP-tracked updates. Microsoft publishes the complete list of required URLs in their documentation. Review your firewall and proxy rules against this list.
Fix 2: Disable SSL inspection for Microsoft endpoints. SSL inspection (TLS interception) replaces Microsoft's certificates with your proxy's certificates. This breaks certificate pinning and can cause authentication failures during Autopilot. Create an SSL inspection bypass rule for all *.microsoft.com, *.microsoftonline.com, *.windows.net, and *.azure.net domains.
Fix 3: Configure proxy settings via WPAD or DHCP. During OOBE, Windows does not have access to proxy configuration that would normally be delivered through Group Policy or Intune. If your network requires a proxy, configure it via WPAD (Web Proxy Auto-Discovery) on your DHCP server or via proxy auto-config (PAC) files. Alternatively, configure the proxy in the OOBE network settings screen.
Fix 4: Test with a direct connection. As a diagnostic step, connect the device to a mobile hotspot or a network segment with direct internet access (no proxy, no content filtering). If Autopilot works on the direct connection but not on your corporate network, you have confirmed the issue is network-related and can focus troubleshooting there.
6. Azure AD (Entra ID) Join Failures
The device attempts to join Entra ID during Autopilot and fails. This presents as an error during the "Joining your organization" phase of the ESP, often with error code 0x801c03f3 or similar.
What is happening: The Entra ID join process creates a device object in your directory and establishes the device's identity for subsequent Intune enrollment and policy application. Failures here block the entire Autopilot flow.
Fix 1: Check device registration settings. In the Entra admin center, go to Devices > Device settings. Verify that "Users may join devices to Entra ID" is set to "All" or includes the user attempting the join. If set to a specific group, confirm the user is a member.
Fix 2: Clean up stale device objects. If the device was previously joined to this or another Entra ID tenant, stale objects can conflict. Search Entra ID Devices for the device by name or serial number. Delete any stale entries. Also check Intune and the Autopilot devices list for orphaned objects. Wait 15 minutes after cleanup before retrying.
Fix 3: Check maximum device limit. Entra ID enforces a per-user device limit (configurable in Device settings). If the user has reached this limit, new joins will fail. Increase the limit or remove stale devices registered to that user.
Fix 4: Verify MFA and Conditional Access. If you have Conditional Access policies that require MFA for device registration, ensure the user can complete MFA during OOBE. Some MFA methods (like phone app push notifications) work during OOBE while others (like FIDO2 keys) may not work in the pre-desktop context. Test the MFA flow on a separate device to confirm it works for the target user.
7. App Installation Timeouts During ESP
The ESP stalls on "Installing apps" and eventually times out after 60 minutes (or whatever your configured timeout is). The deployment fails, and the user cannot proceed.
What is happening: Every application marked as "required" and tracked by the ESP must install successfully before the ESP completes. If any app takes too long to download, install, or report its status, the entire ESP blocks.
Fix 1: Reduce ESP-tracked apps. Only include essential apps in the ESP. Security agents (EDR, VPN), core LOB applications, and configuration tools should be in the ESP. Everything else can install after the user reaches the desktop. Navigate to Devices > Enrollment > Enrollment Status Page, edit your ESP profile, and reduce the selected apps under "Block device use until these required apps are installed."
Fix 2: Investigate the stalling app. Check the Intune Management Extension (IME) logs on the device at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. Search for the app name or the app ID. The log will show download progress, install commands executed, and detection results. Common issues include apps that display hidden dialog boxes during silent install, apps that require a reboot before completing, and apps with incorrect command-line switches for silent installation.
Fix 3: Increase the ESP timeout. If apps legitimately take a long time to install (large applications like AutoCAD or Visual Studio over slow networks), increase the ESP timeout from the default 60 minutes. Edit the ESP profile and set a longer timeout. However, this is a band-aid. The real fix is to optimize app delivery through pre-caching, MSIX packaging, or moving large apps out of the ESP.
Fix 4: Verify app packaging and detection rules. A Win32 app that installs successfully but has an incorrect detection rule will appear "stuck" to the ESP because Intune keeps checking for successful installation and never detects it. Verify your detection rules by manually installing the app and checking if the detection criteria exist (file path, registry key, MSI product code). Update the detection rule if it is not matching correctly.
8. Hybrid Entra ID Join Issues
For organizations using hybrid Entra ID join with Autopilot, the domain join step frequently fails, especially for remote devices. The ESP shows "Joining your organization's network" for an extended period before timing out.
What is happening: Hybrid join Autopilot creates a computer object in your on-premises Active Directory through the Intune Connector for Active Directory. This requires network connectivity to a domain controller from the connector server, correct OU permissions, and a healthy connector service.
Fix 1: Verify Intune Connector status. In the Intune admin center, navigate to Devices > Enrollment > Windows enrollment > Intune Connector for Active Directory. Check that the connector shows a status of "Active" and that the last contact time is recent. If the connector is offline, restart the Intune Connector Service on the server where it is installed. Check the event logs on that server under Applications and Services Logs > Microsoft > Intune for error details.
Fix 2: Verify OU permissions. The connector's service account must have permission to create computer objects in the target OU specified in your Autopilot profile. In Active Directory Users and Computers, right-click the OU, select "Delegate Control," and verify the service account has "Create Computer Objects" permission. A common mistake is changing the target OU without updating the connector permissions.
Fix 3: Configure VPN for remote devices. If the device is remote and not on the corporate network, it needs a VPN connection before the domain join can occur. Configure an Always On VPN device tunnel profile in Intune that connects during OOBE before user sign-in. This is the most complex part of hybrid Autopilot for remote users and often requires additional infrastructure (RRAS, NPS, certificates).
Fix 4: Consider moving to cloud-native join. If hybrid join is causing persistent issues, evaluate whether you still need it. Many organizations originally required hybrid join for Group Policy or on-premises resource access but have since migrated those workloads to Intune and Entra ID. Cloud-native Entra ID join is significantly more reliable for Autopilot and eliminates the domain controller dependency entirely.
9. White Glove / Pre-Provisioning Errors
Pre-provisioning (formerly White Glove) allows IT to complete the device-targeted phase of Autopilot before shipping the device to the user. When pre-provisioning fails, it shows a red screen with an error code and a "Reset" button.
What is happening: Pre-provisioning runs the device phase of Autopilot (policies, device-targeted apps, certificates) without user interaction. It requires TPM 2.0 attestation (self-deploying mode mechanics) and cannot process any policy or app that requires user context.
Fix 1: Ensure all policies are device-targeted. Review every policy and app that is assigned to the device group. Any policy that requires user context will fail during pre-provisioning because no user is signed in. User-targeted apps, user-context configurations, and user-certificate profiles must be moved to the user phase (they will apply when the end user signs in). Check the Intune admin center for each assignment to verify the target type.
Fix 2: Resolve TPM attestation first. Pre-provisioning requires the same TPM attestation as self-deploying mode. If the device fails TPM attestation, pre-provisioning will fail immediately. Apply the TPM fixes from Fix 4 above (update firmware, clear TPM, verify clock).
Fix 3: Check network bandwidth. Pre-provisioning downloads everything during a single session, often on the IT staging network. If you are pre-provisioning multiple devices simultaneously, network bandwidth may become a bottleneck. Stagger provisioning or ensure adequate bandwidth for concurrent downloads.
Fix 4: Collect diagnostic logs from the red screen. When the red screen appears, press the diagnostics button (or press Windows key five times) to collect logs. The diagnostics include the specific error that caused the failure, the phase that was in progress, and the relevant Autopilot and Intune logs. Review the generated ETL files with Windows Performance Analyzer or upload them to our LogLens tool for automated analysis.
10. Reset and Retry Strategies
When troubleshooting does not resolve the issue or when you need to start fresh, knowing the right reset approach saves time. Different failure scenarios call for different reset methods.
Autopilot Reset (from Intune). If the device is enrolled in Intune (even partially), you can trigger an Autopilot Reset remotely. In the Intune admin center, find the device, click "Autopilot Reset." This resets Windows to OOBE while preserving the wireless network connection and the Entra ID device join. It is the fastest retry method because it skips the initial network setup. Use this when the failure was in app installation or policy application, not in the join or enrollment phases.
Fresh Start. Also available from Intune for enrolled devices. Fresh Start removes all pre-installed OEM apps and reinstalls Windows from a clean image downloaded from Microsoft. Use this when you suspect the OEM image is causing issues (driver conflicts, pre-installed software interfering with Autopilot). Note that Fresh Start takes longer because it downloads a new Windows image.
Local OOBE reset. If the device is stuck at the ESP and you have not yet completed enrollment, press Shift+F10 to open a command prompt and run shutdown /r /o /t 0 to restart into recovery. From there, select "Reset this PC" and choose "Remove everything." This returns the device to a clean OOBE state for a fresh Autopilot attempt. Before doing this, collect diagnostic logs from the command prompt.
Full wipe and reimport. For persistent failures, especially after hardware repairs or motherboard replacements, the most reliable approach is to completely wipe the device, re-collect the hardware hash, delete and reimport the device in the Autopilot devices list, wait for profile assignment, and then start Autopilot fresh. This eliminates any stale state from previous attempts.
Backend cleanup between retries. Before any retry, clean up the device objects. Delete the device from Intune Devices, Entra ID Devices, and verify the Autopilot devices entry still has a profile assigned. Do not skip this step. Stale objects from failed attempts are the number one cause of repeated failures on retry.
Collecting Diagnostic Data for Escalation
If none of the fixes above resolve your issue, you may need to open a support case with Microsoft. Collecting comprehensive diagnostic data before opening the case will dramatically speed up resolution.
From the ESP screen: Press Shift+F10 to open a command prompt. Run mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning -cab C:\temp\autopilot-diag.cab. This collects Autopilot-specific logs, enrollment logs, and provisioning data in a single compressed file.
From a completed (or partially completed) deployment: Open Settings > Accounts > Access work or school > select your account > Info > Create report. This generates a management log bundle. Alternatively, run the diagnostic tool from an elevated command prompt.
From the Intune admin center: Navigate to the device in question, go to Monitor > Diagnostics, and check if any diagnostic data has been uploaded. If the device was at least partially enrolled, Intune may have collected telemetry that shows the failure point.
When filing the support case, include: the device serial number, the hardware hash (CSV), the Autopilot deployment profile name, the specific error code or symptom, the diagnostic CAB file, and a timeline of what you have already tried. This prevents multiple rounds of back-and-forth with support asking for basic information.
For faster resolution, consider using BluetechGreen's Intune Stabilization Sprint to get expert hands on your Autopilot environment and resolve persistent issues within days instead of weeks of support ticket ping-pong.