Autopilot Pre-Provisioning: The Complete Troubleshooting Guide

1. What is pre-provisioning?

Pre-provisioning (formerly known as white glove) allows IT teams or hardware vendors to fully configure a Windows device before the end user ever touches it. The device goes through Autopilot enrollment, installs all required apps, applies all policies and reaches a ready-to-use state — all without any user interaction.

The benefit is obvious: the user opens the laptop lid, signs in, and everything is already there. No waiting for apps to install. No “please wait while we set up your device” spinning for 45 minutes. The challenge? When pre-provisioning fails, it can be incredibly frustrating to diagnose because the error messages are often vague and the logs are buried deep.

2. How the process works under the hood

Understanding the flow is essential for troubleshooting. Pre-provisioning runs through these phases in order:

3. Prerequisites checklist

Before you even start troubleshooting a failure, verify that these are all in place. Missing one of these is the root cause in the majority of cases I see:

4. Common failures and how to fix them

Here is a quick-reference table of the failures I encounter most often. Detailed walkthroughs for the trickiest ones follow in dedicated sections below.

5. Collecting and reading diagnostic logs

When pre-provisioning fails and you are staring at a red screen, your first move should be collecting logs. Press Shift + F10 during the ESP to open a command prompt, then run:

# Collect Autopilot diagnostics (Windows 11)
mdmdiagnosticstool -area Autopilot -cab C:\temp\autopilot-diag.cab

# Alternative: collect full MDM diagnostics
mdmdiagnosticstool -out C:\temp\mdm-diag

# Export event logs for Autopilot and enrollment
wevtutil epl Microsoft-Windows-Provisioning-Diagnostics-Provider/AutoPilot C:\temp\autopilot-events.evtx
wevtutil epl Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin C:\temp\mdm-events.evtx

The key log files to look at inside the diagnostic cab:

• TpmHliInfo_Output.txt — TPM health and attestation status. Check for readiness and endorsement key issues
• DiagnosticLogCSP_Collector_Autopilot_* — the ETL traces that contain the actual enrollment flow and where it broke
• MdmDiagReport_RegistryDump.reg — contains the ESP tracking state, enrolled policies, and applied configurations
• IntuneManagementExtension.log — located in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Essential for tracking Win32 app installations

6. ESP timeout deep dive

The Enrollment Status Page is where most pre-provisioning failures surface. The ESP tracks three categories during the device phase: security policies, certificate profiles, and apps. If any tracked item fails to install within the timeout window, the whole process fails.

Strategies to reduce ESP timeouts:

• Minimize tracked apps — only mark apps as required if they truly need to be installed before first login. Move non-critical apps to the user ESP or assign them as available.
• Use app dependencies wisely — chain apps in the correct dependency order. Circular dependencies will cause deadlocks.
• Pre-cache content — for large apps (like Microsoft 365 Apps), consider using Delivery Optimization or a connected cache server to avoid slow downloads.
• Increase the timeout — the default ESP timeout is 60 minutes. For environments with many required apps, bumping this to 90 or 120 minutes can help — but it is a band-aid, not a solution.

To check which specific app or policy is blocking the ESP, run this from the command prompt during the stuck screen:

# Check ESP tracking state in the registry
reg query "HKLM\SOFTWARE\Microsoft\Enrollments" /s | findstr "EnrollmentState"

# Check which policies/apps are still being tracked
reg query "HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking" /s

7. TPM attestation failures

TPM attestation happens right at the start of pre-provisioning. If it fails, you never even get to the ESP. The device shows a red error screen almost immediately after pressing the Windows key five times to enter pre-provisioning mode.

Common causes and fixes:

• TPM firmware outdated — some manufacturers ship with old TPM firmware that does not support attestation. Update via BIOS/UEFI or the manufacturer’s firmware update tool. This is especially common on Lenovo and HP devices.
• TPM not cleared — if the device was previously enrolled or used, the TPM may hold old keys. Clear the TPM in BIOS or via tpm.msc and re-run provisioning.
• Hardware hash mismatch — if you replaced a motherboard or TPM module, the hardware hash has changed. Delete the old Autopilot device record and re-import the new hash.
• Network blocking attestation — the device needs to reach ztd.dds.microsoft.com and several other endpoints. Firewalls or proxies often block these. See the network section.

Quick TPM health check from a command prompt:

# Check TPM status
Get-Tpm | Format-List

# Verify TPM is ready for attestation
Confirm-SecureBootUEFI
Get-TpmEndorsementKeyInfo -Hash SHA256

8. Hybrid Azure AD join issues

Hybrid join adds a whole extra layer of complexity. The device needs to join both on-premises Active Directory and Entra ID. This requires the Intune Connector for Active Directory to be installed on a server that can reach a domain controller.

The most frequent hybrid join problems:

• Intune Connector service not running — check services.msc on the connector server for the “Intune Connector” service. Restart it and check the event log under Application and Services > Microsoft > Intune > ODJConnectorSvc.
• OU permissions — the connector service account needs permission to create computer objects in the target OU. This is the single most common hybrid join failure. Verify with dsacls or the AD delegation wizard.
• Entra Connect sync delay — after the connector creates the AD computer object, Entra Connect needs to sync it to Entra ID. If your sync cycle is 30 minutes, the device sits waiting. Consider triggering a delta sync manually or reducing the sync interval.
• Domain profile not found — the Autopilot profile must specify the correct domain and OU. Double-check the domain join configuration in your deployment profile.

9. Network and proxy pitfalls

Network issues are the silent killer of Autopilot deployments. The device needs access to a long list of Microsoft endpoints during provisioning. Corporate networks with aggressive firewalls or proxy servers frequently break one or more of these connections.

Critical endpoints that must be reachable:

Quick connectivity test from the OOBE command prompt:

# Test critical endpoints
Test-NetConnection ztd.dds.microsoft.com -Port 443
Test-NetConnection login.microsoftonline.com -Port 443
Test-NetConnection enrollment.manage.microsoft.com -Port 443

# Check if a proxy is configured
netsh winhttp show proxy

10. Get-AutopilotDiagnosticsCommunity

If you have ever tried to make sense of raw Autopilot logs and registry dumps, you know it is not a fun experience. That is exactly why the Get-AutopilotDiagnosticsCommunity script exists — a community-maintained PowerShell script published on the PowerShell Gallery.

The script is a successor to Michael Niehaus’s original Get-AutopilotDiagnostics and has been expanded with additional checks, better output formatting and support for the latest Autopilot and ESP changes. It is the single most useful tool in my troubleshooting toolkit and the first thing I run when a pre-provisioning attempt fails.

Installation

# Install from the PowerShell Gallery
Install-Script -Name Get-AutopilotDiagnosticsCommunity -Force

# Run the script
Get-AutopilotDiagnosticsCommunity

# Run with -Online to resolve app names, policy names, etc. from Graph API
# Without this flag you only see GUIDs — with it you get human-readable names
Get-AutopilotDiagnosticsCommunity -Online

# Combine with -Verbose for maximum detail
Get-AutopilotDiagnosticsCommunity -Online -Verbose

What it does

Instead of manually digging through registry keys, event logs and MDM diagnostic files, this script does the heavy lifting for you. Here is what it covers:

• Autopilot profile details — shows the assigned profile, deployment mode, join type and whether pre-provisioning is enabled.
• ESP status breakdown — lists every tracked policy, app and certificate with its current installation state. Instantly tells you what is blocking the ESP.
• App installation status — for each tracked Win32 and LOB app, it shows whether it downloaded, installed and passed detection — including error codes if it failed.
• Policy processing — shows configuration profiles, compliance policies and their delivery status.
• Timeline of events — a chronological overview of the enrollment flow, making it easy to spot where things went wrong and how long each step took.

11. Final pre-flight checklist

Before kicking off pre-provisioning, run through this list. It takes two minutes and saves hours of troubleshooting: