Autopilot ESP stuck? An assignment-first triage checklist
You've seen it: Autopilot starts, the user gets past Wi-Fi and sign-in, then the Enrollment Status Page (ESP) sits on "Setting up your device for work…" until someone pages you.
The rebuild reflex is strong. Sometimes a reset is correct. Often it isn't — and wiping first just burns another hour on the same assignment mistake.
Here's a value-first triage order before Autopilot reset: confirm registration and assignment, simplify ESP, check network and apps, then look for Conditional Access loops. No Microsoft affiliation. No fake scarcity. Just the checks that usually matter.
What "stuck on ESP" usually means
ESP waits for device and (often) user setup tasks: policies, apps marked as blocking, baselines, sometimes scripts. If a blocking item never succeeds — or never targets the device — ESP waits until timeout or failure.
| Pattern | What it looks like | Root cause family |
|---|---|---|
| Never got a profile | Generic OOBE, wrong join type, Autopilot never engages | Hash / group / deployment profile |
| Profile OK, ESP hangs | Progress, then forever on one app or "policies" | Blocking app, timeout, content delivery |
| Near-finish then loop | Almost done, then errors / re-auth | Network, TLS inspection, or CA gating enrollment |
Triage checklist (do these in order)
1. Is this device actually in Autopilot?
- [ ] Autopilot devices list: serial / hash present for this chassis
- [ ] Profile status shows an assigned deployment profile (not blank after sync)
- [ ] Hybrid Autopilot: domain-join prerequisites healthy before you blame ESP
If it isn't registered: register the hash, wait for sync, retry. Rebuilding an unregistered device won't invent a profile.
2. Assignment: device group vs user group
This is the silent killer.
- [ ] Deployment profile assigned to a device group that includes this Autopilot device
- [ ] Membership actually matches (dynamic query or static list)
- [ ] You're not relying on a user group alone while the device never lands in the Autopilot device set
- [ ] ESP (device + user setup) assignments also reach this device / user
Common failure: profile on a user security group; device never in the ZTD / device targeting set you designed in the lab — so it never gets the profile.
Name groups like tickets: AP-Devices-Pilot-Wave0, AP-Profile-UserDriven-Entra.
3. ESP: keep the blocker list honest
- [ ] Which apps are blocking device setup? User setup?
- [ ] Timeouts realistic for real hardware on real Wi-Fi?
- [ ] For a stuck pilot: cut blockers to the minimum that must exist before desktop
- [ ] Brand-new Win32 marked ESP-blocking on day one? Pull it until it installs reliably outside ESP
Rule of thumb: pilot Win32 as required/available without ESP blocking. Promote to ESP-blocking only when installs are boring.
4. Network and content delivery
- [ ] Captive / guest Wi-Fi that dropped after first auth
- [ ] Firewall / proxy allowlists for enrollment and Win32 content (current Microsoft guidance for your cloud)
- [ ] TLS / SSL inspection breaking delivery — exclude per your security process
- [ ] Clock skew; self-deploying: TPM + network requirements met
If sister devices fail the same installs after enrollment, fix delivery before rewriting detection rules again.
5. The failing app itself
When ESP names an app: install status, detection vs what the installer leaves, OS/arch requirements, dependencies, exit codes. Fix the package; don't just raise ESP timeouts until folklore sets in.
6. Conditional Access loops
A device must enroll before it can be compliant. Broad "require compliant device" CA that also hits enrollment-related apps can stall ESP in a loop that looks like haunted Autopilot.
- [ ] Prefer report-only while Autopilot is still flaky
- [ ] Follow current guidance on excluding enrollment apps from policies that demand compliance before enrollment can finish
- [ ] Validate with What If / sign-in logs — not vibes
Keep CA expansion one step behind Autopilot success rates.
7. Only then: reset / Autopilot retry
When assignment, ESP, network, apps, and CA checks are clean and the device is mid-corrupt: document the failure, reset per your org policy, confirm hash + profile still correct before the next OOBE. Wipe is last on a written checklist — not first.
Quick symptom → first check
| Symptom | Likely cause | First check |
|---|---|---|
| Never looks like Autopilot | Missing hash / wrong device | Autopilot devices list |
| Wrong join / unexpected OOBE | Profile not on this device | Device group + profile assignment |
| ESP hangs on one app | Bad Win32 / detection / delivery | App status; remove from ESP blockers |
| ESP hangs on "policies" | Assignment gap or CA | Profile/ESP targets; CA report-only |
| Ethernet OK, Wi-Fi fails | Captive portal / proxy / TLS inspect | Path to enrollment + content |
| Self-deploying never starts | TPM / mode / network | Profile mode vs hardware |
Optional read-only local snapshot
# Read-only: join + MDM URL — changes nothing
$dsreg = dsregcmd /status
$joined = [bool]($dsreg | Select-String 'AzureAdJoined\s*:\s*YES')
$mdm = ($dsreg | Select-String 'MDMUrl\s*:\s*(.+)').Matches.Groups[1].Value.Trim()
[pscustomobject]@{
Computer = $env:COMPUTERNAME
EntraJoined = $joined
MdmUrl = $mdm
CollectedAt = (Get-Date).ToString('s')
}
Empty MDMUrl when you expected enrollment → license, MDM user scope, and work/school account health before rewriting Autopilot profiles.
Want the full runbooks?
This post is the free triage spine. The Intune & M365 Admin Starter Pack is $19 during launch week (normally $29): five markdown playbooks (enrollment & device hygiene, baseline compliance with report-only CA phasing, PowerShell inventory snapshots, M365 admin hygiene, and a break/fix runbook with Autopilot/ESP cards). Three read-only PowerShell scripts included. Scripts do not wipe, retire, or change policy.
👉 https://cashflow4375.gumroad.com/l/joonf
Once Autopilot and compliance are boring, the companion Entra ID Conditional Access Starter Pack ($29) covers report-only → pilot → enforce, break-glass, and CA troubleshooting: https://cashflow4375.gumroad.com/l/nhuyrc
If you only use the checklist above, that's still a win. Questions welcome in the comments.
— Admin Pack Studio
Not affiliated with or endorsed by Microsoft. Operational guidance for admins authorized to manage their tenant. Test in a pilot first; AS-IS, no warranty.
Top comments (0)