The ESP device phase and user phase are two different machines: policy targeted at the wrong one never lands

The Enrollment Status Page is usually described as one screen with a progress bar. It is not. It is a sequence of phases, and the phases do not all run as the same identity. The early phases run before any human has signed in. The last phase runs as the person who just signed in. That single fact decides whether the policy you assigned lands before the desktop appears, or forty minutes after the user has already started working.

The problem: the device reaches the desktop unconfigured

The report always sounds the same. A new laptop finishes the Enrollment Status Page, or ESP, in a reasonable time. The user gets to the desktop. Then the help desk hears that the corporate wireless profile is missing, the certificate has not arrived, and the line-of-business application is nowhere to be found. Nothing failed. Nothing errored. The ESP said everything was fine.

Check the Intune assignments and they look correct. The Wi-Fi profile is assigned. The certificate profile is assigned. The application is assigned as required. Every one of them is assigned to a single group that contains all the staff who get new laptops. That group is a user group.

That is the whole bug. It is not a timing problem, a network problem, or an Intune Management Extension problem. It is a targeting problem. The reason it produces silence rather than an error is that the ESP phase which could have enforced those assignments either never ran, or ran after the point you were watching.

Habit makes this worse. Most Intune tenants started life with user-group assignments, because that is how software distribution worked for twenty years. Autopilot inverted the assumption. During the phases that matter most, there is no user yet.

Why it happens: two phases, two contexts, two rulebooks

Microsoft documents the ESP as tracking three phases. The names matter, because the names map to security contexts.

Read the third column twice. Device setup tracks SCEP profiles targeted at devices. Account setup tracks SCEP profiles assigned to users. These are two separate tracking lists, built from two separate assignment scopes. The ESP does not merge them.

There is even an asymmetry inside that table. Device setup tracks VPN and Wi-Fi profiles. Account setup tracks Wi-Fi profiles only. A user-assigned VPN profile has no documented tracking slot in either phase.

The CSP proves the boundary is structural

The clearest evidence is not in the Intune documentation. It is in the EnrollmentStatusTracking configuration service provider, or CSP. That CSP publishes two separate trees, and they are not the same shape.

Microsoft describes the Setup node in one sentence that settles the argument. It provides the settings that the ESP reads during the account setup phase in the user context, and during the device setup phase in the device context. Same node name, two instantiations, two different phases. The device tree additionally carries DevicePreparation, which Microsoft marks as supported only in device context.

So the boundary is not a convention. It is the shape of the CSP. A user-context provider has no way to register a device preparation block, because the node it would register under does not exist in the user tree.

Which ESP profile the device gets is decided device-first

Assignment targeting also decides which ESP profile applies. Microsoft documents a three-step selection order, and the order is not alphabetical or arbitrary.

1. Intune applies the highest-priority profile assigned to the device.
2. If no profiles are targeted at the device, Intune applies the highest-priority profile assigned to the user. Microsoft adds that this only works where there is a user, and that in pre-provisioning and self-deploying scenarios only device-targeted profiles are applied.
3. If nothing is assigned to either, Intune applies the Default ESP profile.

The consequence is easy to miss. A single device-targeted ESP profile anywhere in scope wins outright, and your carefully prioritised user-targeted profile is never consulted. A tenant can hold up to 51 ESP profiles, the Default plus 50, so there is plenty of room for one forgotten device-targeted profile to shadow everything else.

One ESP setting makes the asymmetry explicit. Microsoft states that the Install Windows quality updates setting does not support user-targeted ESP profiles at all. The device uses the highest-priority device-targeted profile instead, which is typically the Default profile.

The skip switches for both phases are device-scoped

Here is the detail that surprises even experienced engineers. The two nodes that decide whether each phase is displayed both live in the device half of the DMClient CSP.

SkipUserStatusPage controls the user phase, but it is a device-only node. So a device-scoped setting can delete the only phase capable of enforcing user-targeted assignments, and nothing in the user's own configuration can restore it. Microsoft documents the CSP default for both skip nodes as true, which is why an enrollment that never received an explicit ESP policy shows no ESP at all.

Three more documented consequences of the boundary

Once you see the boundary, several long-standing Autopilot oddities stop being mysterious.

• Scripts. Microsoft lists as a known issue that scripts configured to run using the logged-on credentials might not execute during ESP. The documented workaround is to run them in System context instead. A user-context script has no context to run in during the device phases.
• Reboots. Reboots are supported during the device setup phase and are not supported during account setup. A reboot during device setup also forces the user to re-enter credentials before account setup can begin, because those credentials are not preserved.
• Hybrid join. When using Microsoft Entra hybrid join, Win32 and UWP apps assigned to the device with a user installation context are not tracked during provisioning at all. That is a device assignment with a user-context payload, which belongs cleanly to neither side.

How to verify: read which phase this device actually recorded

You do not have to guess which side of the boundary did what. Microsoft documents the registry surface, and the top-level subkey list is the answer on its own.

That bottom entry is the whole diagnostic. Microsoft documents the {User SID} subkey as being created during the account setup phase, and states that it will not be created if the device setup phase fails. Its presence proves a user phase ran. Its absence proves one did not.

Registry reference for the whole feature area

Every path below hangs off one parent key.

The ESP settings themselves live somewhere else entirely, under the enrollment record.

Microsoft documents that when either skip node is configured, the matching value under that key is set to 0xffffffff. That is the fastest way to confirm a phase was deliberately suppressed rather than silently broken.

What the event log can and cannot tell you

Autopilot writes to its own channel, which you can read in Event Viewer.

The channel path is worth writing down once.

The fix: target the phase you need, then prove the targeting

The fix is not a setting. It is a rule you apply to every assignment. Decide which phase must enforce it, then assign to the scope that phase can see.

Step 1: give the ESP profile a device-group assignment

Because selection is device-first, a device-targeted ESP profile is the only one you can rely on in every scenario, including pre-provisioning and self-deploying.

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. Select Create, name the profile in Basics, then select Next.
5. In Settings, set Show app and profile configuration progress to Yes.
6. Set Block device use until all apps and profiles are installed to Yes, so the phases actually gate rather than merely report.
7. Set Turn on log collection and diagnostics page for end users to Yes. That also enables the Windows 11 diagnostics page, reachable with CTRL + SHIFT + D.
8. Select Next, and in Assignments pick a group of devices, not users. Filters are supported, but restricted to rules on model, manufacturer, osVersion, operatingSystemSKU, deviceOwnership and enrollmentProfileName.
9. Select Next through Scope tags, then Review + create.
10. Back on the Enrollment Status Page list, drag your profile so its priority is 1. Priority 1 is the highest.

Step 2: move anything that must land before the desktop to a device group

1. Open the application, configuration profile or certificate profile in the admin center.
2. Edit its Assignments and add a group containing the devices, using a Required assignment. Microsoft is explicit that ESP tracking needs a required assignment to a group containing the device for device-targeted items, or the user for user-targeted items.
3. For applications, confirm the install context is device and that there are no user-context applicability rules. Microsoft lists both as conditions for ESP tracking.
4. Keep line-of-business MSI apps and Win32 apps out of the same ESP run. Both use TrustedInstaller, which does not permit simultaneous installations, and the documented failure is Another installation is in progress, please try again later.
5. If a payload genuinely must be per-user, accept that it belongs to the account setup phase, and keep the user status page enabled so that phase exists.

One caveat on the blocking-apps list. Microsoft explains it as a filter, not an instruction. If you list App 1, App 2 and App 3, but App 3 and App 4 are the apps actually targeted, the ESP tracks App 3 only. In user-driven and self-deploying modes, App 4 is not even installed until after the ESP completes when it is a Win32, Microsoft Store or Enterprise app catalog app.

Proof it worked: a real phase boundary report

The companion script reads only the documented registry state described above, and reports which phases this device recorded in which context. It is read-only, needs no PowerShell module, and aborts rather than printing a partial report if any read fails. Below is a genuine run, with the host name and enrollment identifier redacted.

That output is the whole article in one screen. The device phases ran and completed. The account setup phase does not exist on this machine, and FirstSync shows exactly why, because SkipUserStatusPage is set to 0xffffffff. Any application, certificate or Wi-Fi profile assigned to a user group on this device had no ESP phase in which to be enforced. It was never going to appear before the desktop, and no error was ever going to be raised.

Two details are worth calling out in that run. First, the provider is named ConfigMgr rather than Sidecar, because this device was enrolled through Configuration Manager co-management rather than user-driven Autopilot. Microsoft documents that the ESP lists installation status for all enrollment methods, co-management included. Second, BlockInStatusPage is 7, which under the documented flag values is 0x1 plus 0x2 plus 0x4, so the page blocks and offers Reset PC, Try Again and Continue Anyway on failure.

Run the script on a device that behaved as expected and on one that did not, then compare the two verdict blocks. If the working device has a {User SID} record and the broken one does not, you have found the boundary rather than guessed at it.

References

• Set up the Enrollment Status Page — Microsoft Intune — the three tracked phases, what each phase tracks, the three-step profile selection order, and the quality-update restriction on user-targeted profiles.
• EnrollmentStatusTracking CSP — the two documented trees, the device-only DevicePreparation node, and both InstallationState value sets.
• Troubleshoot the Enrollment Status Page (ESP) — the registry subkey layout, the {User SID} subkey behaviour, and the 0xffffffff skip values under FirstSync.
• DMClient CSP — the device and user scope of every FirstSyncStatus node, including both skip nodes and BlockInStatusPage.
• Windows Autopilot troubleshooting FAQ — the Autopilot event channel and the documented event ID catalog.
• Windows Autopilot Enrollment Status Page — the overview statement that ESP profiles are deployed to a licensed Intune user.

Community deep-dives that were fetched, checked and are genuinely on this topic: