DEV Community

AdminPackStudio
AdminPackStudio

Posted on

Autopilot ESP stuck? An assignment-first triage checklist for Intune admins

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')
}
Enter fullscreen mode Exit fullscreen mode

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)