ESP hangs at Account Setup when the IME and ESP fall out of sync

Your Autopilot device has been parked on "Account setup" for an hour — and even after enrolment finishes, the Intune Management Extension can go on believing the device is still mid-ESP, silently blocking app uninstalls. Here is what the ESP is actually waiting for, where that state lives in the registry, and how to find and clear it.

The problem

The Enrollment Status Page (ESP) runs three sequential phases — device preparation, device setup and account setup — and it is the third one that most often refuses to finish. Typical symptoms:

• A user-driven Autopilot deployment sits indefinitely at Account setup, usually on "Identifying" or "Apps (x of y installed)", then eventually times out with 0x800705b4.
• Hybrid-joined devices are disproportionately affected: they clear device setup fine, then never progress past account setup.
• The delayed version of the same fault: weeks after a device enrolled successfully, Win32 apps assigned as required uninstall never come off it. The Intune Management Extension (IME) log shows the agent still treating the device as being inside the ESP, so it defers the uninstall forever.

You will hit this if you run user-driven Autopilot (particularly hybrid Microsoft Entra join), if you track user-targeted apps in your ESP profile, or if you use the setting that shows the ESP to every first-time user on a device. The root of all three symptoms is the same: the IME keeps its own record of ESP progress, and that record can disagree with what actually happened.

Why it happens

Two separate state stores have to agree for the ESP to complete, and for the IME to behave normally afterwards.

1. The EnrollmentStatusTracking CSP (Windows 10 1903+)

ESP tracking data is written to the registry under:

HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking

It holds a Device subkey (device preparation and device setup), an ESPTrackingInfo subkey (timestamped diagnostics per app, Wi-Fi profile and SCEP profile), and a {User_SID} subkey that is only created when the account setup phase begins. The IME registers here as the Sidecar policy provider, and each tracked Win32 app gets an InstallationState value under Setup\Apps\Tracking\Sidecar\Win32App_{AppID}: 1 = NotInstalled, 2 = InProgress, 3 = Completed, 4 = Error. A single value of 4 halts all further app installation in the ESP.

2. The IME's own view of provisioning

Independently, the IME decides whether the device is "in ESP" by checking enrolment provisioning state under HKLM\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}\FirstSync — values such as IsSyncDone and HasProvisioningCompleted, with a per-user subkey keyed on the signed-in user's SID for the account setup phase. Patch My PC's deep-dive into the IME internals documents a real case where the user-SID FirstSync key was never written and a stale Sidecar tracking entry persisted, so the IME kept returning an "in ESP" status after enrolment had visibly completed — which is exactly why apps later refused to uninstall.

What actually blocks Account Setup

• User-context apps that cannot complete in that phase. Only apps that install in device context with no user-context applicability rules are reliably trackable; user-targeted required apps are tracked during account setup, where far more can go wrong.
• Hybrid join prerequisites. The user's first sign-on on a hybrid-joined device needs line of sight to a domain controller. No DC connectivity (classic case: VPN not up before sign-in) means account setup cannot finish.
• Conditional Access interrupting the token flow that the IME and enrolment components rely on during first sign-in.
• Reboots during account setup. Microsoft's ESP documentation is explicit that reboots are supported during device setup but not during account setup — an installer that forces a restart there breaks the tracking chain.
• LOB (MSI) and Win32 apps mixed in the ESP. Both serialise behind the Windows Installer service and can deadlock each other ("another installation is in progress").

The fix

Diagnose it live

1. At the stuck ESP (or at timeout, via the Collect logs button if you enabled it in the ESP profile), press Shift+F10 for a command prompt and run:
   mdmdiagnosticstool.exe -area Autopilot -cab C:\temp\autopilot.cab
   (add ;TPM to the area for self-deploying scenarios).
2. On another machine, install and run Michael Niehaus's community script against the cab:
   Install-Script -Name Get-AutopilotDiagnostics -Force
Get-AutopilotDiagnostics -CABFile C:\temp\autopilot.cab
   It names exactly which apps and policies each ESP phase is still waiting on — this alone usually identifies the guilty item.

Read the state directly

1. Open HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking. If the {User_SID} subkey is missing, device setup never handed over cleanly. Under Setup\Apps\Tracking\Sidecar\, any Win32App_{AppID} with InstallationState = 4 is your blocker — cross-reference the AppID in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log.
2. Check HKLM\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}\FirstSync (and its user-SID subkey) for IsSyncDone / HasProvisioningCompleted.
3. On hybrid join, run dsregcmd /status and confirm the device can reach a domain controller at sign-in time; review Conditional Access sign-in logs for blocked token requests during enrolment.

Unstick a device post-enrolment

If enrolment is long finished but the IME still refuses to uninstall apps because it believes the ESP is running: export the keys above first, then remove the stale Sidecar tracking entries under EnrollmentStatusTracking that reference the completed enrolment, and restart the Microsoft Intune Management Extension service (or reboot). In the documented Patch My PC case, deleting the lingering tracking entry and rebooting was what returned the IME to a NotInEsp state and let deferred uninstalls proceed. This clears agent bookkeeping only — it does not touch installed apps or policy.

Prevent the next one

• Block only on the apps genuinely needed at first sign-in, using Block device use until these required apps are installed rather than "all apps".
• Keep every ESP-tracked app device-context, silent, with no user-context applicability rules and with reboot behaviour handled through Intune return codes.
• Do not mix LOB (MSI) and Win32 apps in the blocking set.
• Set the ESP timeout to something honest for your app payload — five minutes and fifteen apps is a timeout you configured, not a bug.

How Decolla handles it

Honestly: nothing can reach into a device that is already wedged mid-ESP — the steps above are the way out, and Decolla does not claim otherwise.

What Decolla does is remove the conditions that produce the stall in the first place. Decolla provisions Windows devices zero-touch over your own Intune and Autopilot tenant, and every deployment starts from a written, itemised plan: each item you pick from the catalogue (260+ items) is listed with its delivery method and reversibility class, and you approve that plan before anything runs. That means an ESP stall is never an anonymous "Apps (3 of 7)" — it is traceable to a named step you signed off.

The Library items themselves — pre-built, industry-tested policies, scripts and fixes — are packaged the way this article recommends: device-context, silent, reboot behaviour declared, so the ESP is only asked to wait on installs proven to complete in the device setup phase rather than gambling on user-context apps in Account Setup. And because Decolla tracks what it changed, its per-item rollback can cleanly remove any of its own changes later — the scenario where the IME refuses an uninstall because of stale ESP state is exactly the kind of ambiguity the plan-first model is designed out of. Decolla is pre-launch; you can join the waitlist at decolla.app.

Sources

• Microsoft Learn — Troubleshoot the Enrollment Status Page (ESP)
• Patch My PC — How the Intune Management Extension tracks ESP phases
• Microsoft Q&A — Windows Autopilot deployment gets stuck on device setup (ESP timeout)