Windows Autopilot enrolment failures: a diagnostic sequence

Autopilot failures are unusually visible. They occur during out-of-box experience, in front of a new starter, on their first morning. The pressure to do something immediately is real, and it leads people to reset the device repeatedly rather than diagnose it.

The useful thing to know is that the failures cluster into four categories, and the category is identifiable in a couple of minutes.

The four categories

1. The device is not recognised as an Autopilot device. It boots to a normal out-of-box experience with no company branding and no Autopilot behaviour. The device’s hardware hash is not registered, or it is registered to a different tenant.

2. The device is recognised but no profile applies. It is registered, but the deployment profile has not been assigned or has not yet been applied to it.

3. Entra ID join or MDM enrolment fails. Autopilot starts, then fails during sign-in or enrolment, typically with an error code.

4. The Enrollment Status Page fails or times out. Everything works until the provisioning phase, then a required application or policy does not arrive within the configured timeout.

Establishing which one you have is the whole diagnosis, and it is answered by watching where the process stops.

Diagnosis

Category 1: not recognised

The device boots as if it were a consumer machine.

Check the device’s registration in the Intune admin centre, under Windows enrolment and Windows Autopilot devices. Search for the serial number. Three outcomes:

• Not present. The hash was never uploaded, or the vendor did not register it. This is the most common single cause of Autopilot not happening at all.
• Present but assigned to no profile. Category 2.
• Present in a different tenant. The device was registered by a reseller or a previous owner and must be deregistered there before it can be registered by you. This one is slow to resolve because it needs the other party.

To collect the hash from a device you already have:

# Run elevated. Install the script from the PowerShell Gallery first.
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile C:\Temp\autopilot-hash.csv

For devices arriving in volume, having the vendor register them at the point of supply is the only approach that scales — collecting hashes by hand from a hundred new laptops is a poor use of a week.

Category 2: recognised, no profile

The device appears in the Autopilot devices list. Check:

• Profile assignment status. It should show a profile assigned. Assignment is not instantaneous after registration, and a device that boots too soon after being registered will not have one.
• Group membership. Autopilot profiles are assigned to groups, usually dynamic groups based on Autopilot device attributes. A dynamic group rule that does not match the device is a common cause, and dynamic group membership takes time to evaluate.
• The profile itself — deployment mode, join type, and whether it matches what the device can actually do.

The practical advice: after registering a device, confirm profile assignment status shows assigned before handing it to anyone.

Category 3: join or enrolment failure

This is where error codes appear. Work through these:

Is MDM automatic enrolment configured and in scope for this user? In Entra ID, MDM user scope must include the user. A user outside the scope authenticates successfully and then fails to enrol, which reads as an authentication problem and is not one.

Does the user have a licence? An Intune licence is required. An unlicensed user produces an enrolment failure at exactly this point.

Are there enrolment restrictions blocking the platform? Device type restrictions can block Windows enrolment, or block personally owned devices, and a corporate device not recognised as corporate will be treated as personal.

Has an enrolment device limit been reached? A user at their device limit cannot enrol another.

For hybrid join specifically — is the Intune Connector for Active Directory installed, healthy and able to create computer objects in the target organisational unit? Does the device have line of sight to a domain controller during provisioning? Hybrid Autopilot has substantially more moving parts than Entra join, and this is the usual reason to prefer Entra join for new deployments.

Is Conditional Access blocking the enrolment? A policy requiring a compliant device will block a device that is not yet enrolled and therefore cannot be compliant. This is a circular dependency and it is a genuinely common self-inflicted failure — check your policies for it specifically, as noted in Conditional Access baselines.

Category 4: Enrollment Status Page

The device joins and enrols, then sits on the provisioning screen and eventually fails or times out.

The Enrollment Status Page waits for the applications and policies you told it to wait for. It fails when one of them does not arrive in time, and the causes are usually:

• A blocking application that is large, slow or failing. Every application listed as required for the ESP must install successfully within the timeout.
• An application with a detection rule that never returns true, so the ESP waits forever for something that has actually installed. This is the single most common ESP failure and it is a detection rule problem, not an ESP problem — see Intune app deployment.
• A timeout that is too short for the real-world combination of network and application set.
• A dependency or supersedence chain that takes longer than anyone measured.

The setting controlling whether users can use the device when installation fails is worth considering deliberately. Allowing it turns a hard failure into a degraded start; blocking it guarantees the device is fully configured but strands the user when anything goes wrong.

Collecting evidence from the device

During out-of-box experience, Shift + F10 opens a command prompt, which is how you get diagnostics off a device that is failing in front of you:

MdmDiagnosticsTool.exe -area "Autopilot;DeviceEnrollment;DeviceProvisioning;TPM" `
    -cab C:\Temp\autopilot-diagnostics.cab

Collect this before resetting the device. A reset destroys the evidence and produces the same failure again, which is how a single diagnosable problem becomes an afternoon.

For an enrolled device, Intune can collect diagnostics remotely, and the Autopilot deployment reports in the admin centre show per-device deployment status and failures.

Resolution and validation

The fix follows the category, and each has a clear test.

Validate with a genuine end-to-end test rather than a console check:

• Reset a test device and run the full Autopilot experience, signing in as a test user from the target population.
• Time it. The duration is what determines whether the ESP timeout is adequate, and it should be measured on a realistic network, not on the corporate LAN next to the switch.
• Test from outside the corporate network, because that is where many devices will actually be provisioned.
• Confirm the device ends up compliant, with the intended policies and applications.
• Repeat after any change to the ESP application list, because every added blocking application extends the critical path.

Operations

Register devices at the point of purchase. Vendor registration removes category 1 entirely, which is the largest single category.

Keep the ESP blocking application list short. Every application on it is a way for provisioning to fail. Deliver the rest after the device is in use.

Test the whole flow after any change to profiles, ESP configuration, Conditional Access or enrolment restrictions. All four can break Autopilot without any of them looking like an Autopilot change.

Pre-provision where the logistics allow it. Doing the heavy work before the device reaches the user turns a first-morning failure into a warehouse problem, which is a much better place for it.

Verification and limits

Autopilot registration and profile assignment behaviour, MDM scope and licensing requirements, enrolment restrictions, the Intune Connector requirement for hybrid join, Enrollment Status Page behaviour, the Shift + F10 diagnostic route and MdmDiagnosticsTool.exe usage were checked against current Microsoft documentation on 20 September 2026. The four-category framing and the diagnostic ordering are my own practice.

Nothing here was executed against a device or tenant for this article. The diagnostic steps are read-only; resetting a device destroys evidence, so collect diagnostics first. Autopilot behaviour and deployment profile options change with Windows and Intune releases — confirm current behaviour for your build and deployment type.

References

• Windows Autopilot deployment overview
• Troubleshoot Windows Autopilot
• Enrollment Status Page
• Collect diagnostics from a Windows device