Autopilot ESP Timeout: Setup Could Not Be Completed Fix

The device sits in the Device setup phase of the Enrollment Status Page (ESP), the app counter stops moving, and after an hour the screen says:

Setup could not be completed. Please try again or contact your support person for help.

That’s the default ESP error text when you haven’t set a custom message (Microsoft Learn, ESP setup). On its own it tells you nothing about which app or setting stalled. This article covers how to find that out, and what to change so the next device gets through.

Quick Fix checklist

1. If the ESP profile has Turn on log collection and diagnostics page for end users set to Yes, select Collect logs on the error screen and save the logs to a USB drive. Otherwise press Shift+F10 and run mdmdiagnosticstool.exe -area Autopilot -cab <pathToOutputCabFile>.
2. Open HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device\Setup\Apps\Tracking\Sidecar and look for any Win32App_{AppID} with InstallationState = 4 (Error) or stuck at 2 (InProgress).
3. If an app is in Error, fix that app first. Raising the timeout won’t help.
4. If nothing failed and apps were still installing, count the blocking apps against the time limit and raise Show an error when installation takes longer than specified number of minutes.
5. Check the blocking app list for a mix of LOB (MSI) and Win32 apps, and for apps that reboot from inside their own installer.

What the error means

The ESP profile setting Show an error when installation takes longer than specified number of minutes controls when the error appears. Microsoft says “The default time-out is 60 minutes. Enter a higher value if you think more time is needed to install apps on your devices.” (ESP setup). The same screen and message also appear when an install error occurs, so you can’t tell timeout from failure by looking at the screen.

Microsoft’s troubleshooting article states the cause plainly: “ESP time-out during app deployment usually occurs because the time-out value that’s set in the ESP profile isn’t enough to deploy all required apps.” Its example is a five-minute limit with more than 15 required apps. It also lists app failures from “incorrect app configuration, network connectivity issues or device-specific issues” as a cause (Troubleshoot the ESP).

Why the obvious fix can be wrong

Doubling the timeout feels like the fix, and sometimes it is. But Microsoft documents that “If the value of InstallationState for any app is 4, ESP stops installing applications” (Troubleshoot the ESP). If one app is in Error, a longer limit just means the user waits longer for the same failure. Read the registry before you touch the profile.

Two documented configuration problems also look like a slow ESP:

• LOB and Win32 apps mixed in the blocking list. Both installers use TrustedInstaller, which doesn’t allow two installs at once. Microsoft says the Win32 install then fails with “Another installation is in progress, please try again later” and “In this situation, ESP fails. Therefore, don’t mix LOB and Win32 apps when using Windows Autopilot.” (ESP setup)
• Reboots inside the app package. From the ESP known issues: “any reboots that are packaged within the app might cause ESP to hang and fail the deployment.” Microsoft recommends setting reboot behavior in Intune, not in the package.

On hybrid Microsoft Entra joined Autopilot, Microsoft also notes that ESP takes 40 minutes longer than the profile value, so a 30-minute setting can run for 70 minutes. Keep that in mind before calling a hybrid device stuck.

Evidence to inspect

Collect logs before anyone resets the device. A reset throws away the registry state you need.

From OOBE, press Shift+F10 and run the command for your deployment mode (Troubleshoot the ESP):

mdmdiagnosticstool.exe -area Autopilot -cab <pathToOutputCabFile>

For self-deploying and pre-provisioning on physical devices:

mdmdiagnosticstool.exe -area Autopilot;TPM -cab <pathToOutputCabFile>

In the cab, MDMDiagReport_RegistryDump.Reg holds the ESP keys. The ones that matter here:

Key	What it tells you
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}\FirstSync	ESP settings the device received
...\EnrollmentStatusTracking\Device\DevicePreparation	Intune Management Extension (SideCar) install state: 1 NotInstalled, 2 NotRequired, 3 Completed, 4 Error
...\EnrollmentStatusTracking\Device\Setup\Apps\Tracking\Sidecar\Win32App_{AppID}	InstallationState per device-context Win32 app: 1 NotInstalled, 2 InProgress, 3 Completed, 4 Error
...\EnrollmentStatusTracking\ESPTrackingInfo\Diagnostics	Timestamped status for LOB (MSI) apps, Wi-Fi profiles, SCEP certificates and Store apps

All of these come from Microsoft’s ESP troubleshooting article. The ... prefix is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Autopilot.

How I read the result:

• One app at 4. That app is the cause. Take its {AppID} to the Intune Management Extension logs in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs (Win32 app troubleshooting); AppWorkload.log covers installs and detection.
• Apps at 3, last one at 2, no 4. Apps were still installing when the clock ran out. That points at the time limit, a slow network, or a large app.
• DevicePreparation SideCar at 4. The Intune Management Extension itself didn’t install, so no Win32 app could start.

The fix

If an app failed (InstallationState 4): fix the app, not the ESP. Reproduce the install, correct the command line or detection rule, and set reboot behavior in Intune rather than inside the package. If the app doesn’t need to be on the device before the user signs in, remove it from Block device use until these required apps are installed if they are assigned to the user/device and let it install after ESP.

If the blocking list mixes LOB and Win32: repackage the MSI as a Win32 app, or move one side out of the blocking list. Microsoft’s alternative when you must mix them is Windows Autopilot device preparation, which doesn’t use ESP (ESP setup).

If apps were still installing: trim the blocking list to what the user needs at first sign-in, then raise the time limit. Microsoft gives no per-app timing formula, so measure a test device on your own network and set the limit with room to spare. My preference is a short blocking list over a long timeout, because every extra blocking app is one more thing that can stop the whole ESP.

Turn on log collection in the ESP profile while you’re there. Microsoft recommends it, and it gives the person at the device a Collect logs button the next time this happens.

Verify the fix

Run a fresh deployment on a test device in the same groups. During Device setup, watch InstallationState values move to 3 under Device\Setup\Apps\Tracking\Sidecar. Success means the device gets to account setup or the desktop without the error, inside the limit you set.

What not to waste time on

• Resetting the device before you collect logs.
• Raising the timeout when the registry already shows an app at 4.
• Disabling the ESP profile as a quick bypass. Microsoft’s known issues say disabling it “doesn’t remove ESP policy from devices.”

Test the free beta scripts

While you wait for the Autopilot + Device Prep Deployment Doctor (Kit 1), the free, read-only Kit 1 beta scripts are on GitHub: Get the Kit 1 beta scripts. Per its README, Invoke-DeviceDiagnostic.ps1 reads the ESP tracking keys above on the device, and Invoke-TenantPreCheck.ps1 flags ESP profiles whose blocking apps mix LOB MSI and Win32 apps. I haven’t run them against a real failed device for this article; the repo says they’re covered by unit tests with mocked data, so try them on a non-production device first and check each file against the published checksums.

Related: Autopilot error 815 when no profile is assigned and why device ESP ignores user-targeted blocking apps.

FAQ

What is the default ESP timeout?

60 minutes. You change it with Show an error when installation takes longer than specified number of minutes in the ESP profile.

Does a longer timeout fix an app that failed?

No. Microsoft says ESP stops installing apps once any app has InstallationState 4, so fix that app first.

Why does my hybrid joined device take longer than the timeout?

Microsoft documents that on hybrid Microsoft Entra joined Autopilot, ESP takes 40 minutes longer than the profile value to give the on-premises AD connector time to create the device record.

Does Windows Autopilot device preparation hit the same ESP timeout?

No. Device preparation doesn’t use ESP, per Microsoft’s ESP documentation. It has its own failure modes, covered in Autopilot device preparation failures in Intune.

Sources

• Set up the Enrollment Status Page, Microsoft Learn (retrieved 2026-10-20): default 60-minute timeout, default error message, log collection setting, LOB/Win32 mix, packaged reboots, disabled profile, hybrid +40 minutes, device preparation doesn’t use ESP.
• Troubleshoot the Enrollment Status Page, Microsoft Learn (retrieved 2026-10-20): timeout cause, Collect logs, mdmdiagnosticstool commands, FirstSync and EnrollmentStatusTracking keys and values.
• Troubleshoot Win32 app issues, Microsoft Learn (retrieved 2026-10-20): IME log location and AppWorkload.log.