The ESP Hit Its Time Limit, The User Clicked Continue Anyway, And The Device Went Live Without Its Baseline

A laptop turns up in your fleet report looking almost normal. It is Microsoft Entra joined, it is enrolled in Microsoft Intune, and the user has been working on it for three weeks. What it does not have is the security baseline, the certificate profile, or two of the four required applications. Nobody raised a ticket, because from the user's point of view nothing went wrong. They sat through the Enrollment Status Page (ESP), watched it stall, saw an error message, and clicked the button that said they could keep going. Windows let them, because that is exactly what you told it to do.

The problem: the device reached the desktop, the baseline did not

Most administrators configure the Enrollment Status Page once. They set Show app and profile configuration progress to Yes and pick a time limit that feels generous. Then they tick the boxes that sound helpful and move on. The time limit then gets treated as a patience setting. It is not. It is the trigger for an entire failure path with its own user interface, its own choices, and its own consequences.

Here is what actually happens at the end of the timer. The setting is documented as Show an error when installation takes longer than specified number of minutes. Microsoft describes the behaviour plainly: "A time-out error message is shown after your desired time." The device does not roll back. It does not reset itself. It shows an error message, and then it shows the user whichever remediation buttons you allowed.

Three of those buttons are documented in the DMClient configuration service provider (CSP). They are Reset PC, Try Again and Continue Anyway. The last one is the one that puts half-provisioned hardware into production.

Now think about what "continue" actually means. ESP tracks a specific, documented list of items during the device setup and account setup phases. That list includes Win32 applications, SCEP certificate profiles, VPN and Wi-Fi profiles, and a small set of app-related policies. Microsoft is explicit that ESP does not track security policies such as device restrictions, although those policies do still install in the background.

There is a second, quieter consequence. Compliance policy and Conditional Access evaluate later, on their own schedule. A device that skipped a certificate profile can look fine for hours before anything notices. That is a real exposure window. It exists because a person in an office clicked a green button they were told they were allowed to click.

Why it happens: one timer, three buttons, one bitmask

The Enrollment Status Page is a user interface sitting on top of two configuration service providers. Understanding which one owns what makes the failure path obvious.

The DMClient CSP owns the ESP settings and the final verdict, under its FirstSyncStatus node. The EnrollmentStatusTracking CSP, added in Windows 10 version 1903, owns the per-item progress that fills the page. When people say the ESP "timed out", the timer they are describing lives in DMClient.

The timer, with real numbers

The DMClient node behind the time limit is TimeOutUntilSyncFailure. Its documented characteristics are worth committing to memory, because they are the only published numbers in this whole area.

• Unit of measurement: minutes.
• Documented default value: 60.
• Documented allowed range: 1 to 1440, which is one day.
• Documented purpose: "how long we will poll until we surface an error message to the user".

Read that purpose again. The timer surfaces a message. It is not documented as a cancellation, and installations already in flight are not documented as being aborted by the timer itself. What is documented is different and more brutal. If the InstallationState value for any tracked app reaches 4 (Error), ESP stops installing applications.

There is also a second, separate timer that almost nobody configures. The EnrollmentStatusTracking CSP gives each device preparation policy provider its own Timeout node, in minutes. Microsoft documents that "if no timeout value is specified, ESP selects the default timeout value of 15 minutes". That timer governs the device preparation phase, before device setup even starts.

The bitmask that draws the buttons

This is the part that explains everything else. The remediation buttons are not three independent switches inside Windows. They are three bits in one integer node called BlockInStatusPage, documented with a default value of 0.

Because these are bit flags they combine. A device carrying BlockInStatusPage of 7 is blocking and offers all three buttons. A device carrying 1 is blocking and offers only a reset. A device carrying 0 is not blocking at all, which is a different risk with the same outcome.

How to verify: read the settings and the outcome the device recorded

Everything above is theory until you read a real device. Microsoft states that all ESP settings and tracking information are logged in the device registry. That means a device can tell you which failure path it was offered, and how the attempt ended.

Step 1: read the ESP settings the device actually received

The settings live under one parent key, keyed by the enrollment identifier. The enrollment GUID differs per device, so enumerate rather than hardcode it.

Step 2: read the per-phase tracking state

The second key tells you what failed, rather than only that something failed. It is created by the EnrollmentStatusTracking CSP.

Three subkeys matter for the failure path. Device holds device preparation and device setup state. ESPTrackingInfo holds timestamped diagnostics for tracked apps and profiles. A subkey named after the signed-in user's security identifier (SID) holds the account setup state.

That third one is diagnostic gold, precisely because of what Microsoft says about it. The SID subkey "is created in the account setup phase" and "won't be created if the device setup phase fails". So on a device where the user status page was not deliberately skipped, a missing SID subkey is evidence that device setup never completed.

Inside those subkeys, InstallationState carries the documented values 1 (NotInstalled), 2 (InProgress), 3 (Completed) and 4 (Error). For device preparation providers the values are 1 (NotInstalled), 2 (NotRequired), 3 (Completed) and 4 (Error). Those providers also carry a LastError value, which ESP only reads when the state is 4.

Step 3: check the event channel and the collected diagnostics

Windows Autopilot logs to its own channel. Open Event Viewer and navigate to Applications and Services Logs, then Microsoft, then Windows, then ModernDeployment-Diagnostics-Provider, then Autopilot.

These are the documented identifiers on that channel. Pay attention to what is not in the list.

For the full picture, collect diagnostics. In OOBE on a non-S mode device, press Shift+F10 and run the documented command for your scenario.

You also get server-side evidence for free, unless you have turned it off. Microsoft documents that Autopilot diagnostics are automatically captured when devices experience a failure. Each device can capture one set of logs per day. Collections are stored for 28 days, and each device can hold up to 10 collections at a time. That is a genuine audit trail of failed provisioning attempts.

The fix: configure the failure path on purpose

Start by finding the profile the device actually got, not the one you remember editing.

1. Sign in to the Microsoft Intune admin center.
2. Select Devices, expand Device onboarding, then select Enrollment.
3. On the Windows tab, under Windows Autopilot, select Enrollment Status Page.
4. Note every profile in the list and its priority order. Priority 1 wins.
5. Open the profile that targets your build group, then select Properties.
6. Next to Settings, select Edit.
7. Confirm Show app and profile configuration progress is set to Yes.
8. Set Show an error when installation takes longer than specified number of minutes to a realistic value. Count your blocking apps and be honest about how long they take.
9. Set Block device use until all apps and profiles are installed to Yes. Without this, the failure path settings below never appear.
10. Set Allow users to use device if installation error occurs to No for any build where the security baseline is not optional.
11. Set Allow users to reset device if installation error occurs to Yes if your users can tolerate a rebuild, or No if you would rather they call the service desk.
12. Set Turn on log collection and diagnostics page for end users to Yes. Microsoft explicitly recommends this, and it costs you nothing.
13. Set Show custom message when time limit or error occur to Yes, then write a message that names your service desk. A user who knows who to call does not go hunting for a bypass.
14. Select Review + save, then Save.
15. Repeat for every profile that could match your devices, including the default profile.

Now pick a posture per scenario, rather than one setting for the whole fleet.

Finally, accept the architectural point. ESP was never a security control, and treating it as one is the root cause of this entire problem. It is a provisioning progress gate. The control that decides whether an incompletely provisioned device reaches your data is compliance policy plus Conditional Access. Configure the ESP failure path so devices rarely slip through, and configure compliance so it matters less when they do.

Proof it worked: a device-level outcome report

The companion script reads only documented state. It enumerates the enrollments and finds the FirstSync key. It decodes BlockInStatusPage into named buttons and reads the EnrollmentStatusTracking phases. Then it prints a single verdict of CLEAN, REVIEW, FAILED or UNKNOWN. It writes nothing to the registry and it calls no cloud service.

Its most important behaviour is the one it refuses to perform. If it cannot read the enrollment root, it aborts with exit code 1 rather than reporting a clean device. A false clean on a compliance check is worse than no check at all.

Run it as a Win32 app detection script, as a Remediations detection script, or as a one-off sweep across a build batch. Add -JsonPath to emit structured findings for an inventory pipeline, and -SkipEventLog when the session is not elevated.

Then close the loop in the console. A device that hit the failure path should have a diagnostics collection sitting against it.

A good outcome looks boring. WasDeviceSuccessfullyProvisioned reads 1 and BlockInStatusPage has no 0x4 bit set. No tracked item sits at InstallationState 4. The per-user SID subkey exists, and Device diagnostics is empty for that device. When that is true across a whole build batch, the ESP time limit has stopped being a decision you quietly delegated to your users.

References

• Set up the Enrollment Status Page — Microsoft Intune. The full documented settings list, the 60 minute default time limit, the profile priority model, ESP tracking scope and known issues.
• DMClient CSP — Microsoft Learn. The FirstSyncStatus nodes, including the BlockInStatusPage bit flags, TimeOutUntilSyncFailure and WasDeviceSuccessfullyProvisioned.
• EnrollmentStatusTracking CSP — Microsoft Learn. DevicePreparation, Setup, the InstallationState values and the 15 minute provider default.
• Troubleshoot the Enrollment Status Page — Microsoft Intune. The registry surface, the log collection commands and the user SID subkey behaviour.
• Windows Autopilot troubleshooting FAQ — Microsoft Learn. The Autopilot event channel, the documented event ID table and the Windows Autopilot diagnostics page.
• Device action: Collect diagnostics — Microsoft Intune. Automatic capture on Autopilot failure, 28 day retention and the 10 collection per device limit.
• windows10EnrollmentCompletionPageConfiguration — Microsoft Graph. The ESP profile properties, including installProgressTimeoutInMinutes, allowDeviceUseOnInstallFailure and blockDeviceSetupRetryByUser.
• Windows Autopilot Enrollment Status Page — Microsoft Learn. Overview of what the ESP tracks and what an ESP profile can configure.

Microsoft MVP community deep-dives