Intune enrollment status page: what it actually blocks, and why it hangs

The Intune enrollment status page is the screen a user watches while a new device provisions, and the first thing blamed when provisioning stalls. Most write-ups list the settings and stop there. The names do not tell you what is actually being tracked, which settings genuinely hold the desktop shut and which only display a message, or why a device sits on Identifying with nothing failing in the portal. This post covers all three. Verified against Microsoft Learn on 22 August 2026.

One piece of context decides whether any of it applies to you. The page belongs to classic Windows Autopilot. Autopilot device preparation, the newer provisioning flow, does not use it, and Microsoft states that plainly rather than leaving it to be inferred. The tracking itself is carried out by the Intune management extension, installed during the first phase under its internal name SideCar, which is why a device that never receives the extension never leaves that phase.

What the Intune enrollment status page actually tracks

There are three phases and they run in a fixed order: device preparation, device setup, account setup. Device preparation installs the management extension and tracks nothing of yours. Device setup covers work targeted at the device. Account setup repeats the same categories in the context of the first user to sign in, and is skipped entirely if device setup fails.

In the two phases that matter, Microsoft documents the tracked set as per machine line-of-business MSI apps, line-of-business store apps where the installation context is device, Win32 applications on currently supported versions of Windows, and WinGet applications. Wi-Fi profiles, SCEP certificate profiles and policies are tracked alongside them.

What is missing from that list is the important part. PowerShell scripts are not tracked. The troubleshooting reference is direct about it: the management extension tracks Win32 apps only during this phase, not PowerShell scripts. Security policies are not tracked either. A build that depends on a script running before first login therefore has no representation on the page at all, and the page will report success while that dependency is still outstanding.

One more constraint is worth knowing before you design around it. Reboots are supported during device setup and not during account setup. An app that demands a restart in the user phase is in the wrong phase.

The settings, and which of them actually block

There are eleven settings on an Intune enrollment status page profile, created under Devices, then Device onboarding, then Enrollment, the Windows tab, Windows Autopilot, Enrollment Status Page, then Create. Only three of them hold the desktop shut. The rest scope the page or decorate it.

The timeout deserves a second look because it is routinely misread. It shows an error message after the number of minutes you set. It does not cancel the installation, and Microsoft documents no maximum value. Raising it from 60 to 180 does not make anything install faster. It makes the failure take three hours to become visible.

Which profile wins when several are assigned

Profiles carry a priority number and the profile set to 1 is the highest. Resolution runs in a fixed order: the highest priority profile assigned to the device, then the highest priority profile assigned to the user if no device profile applies, then the default profile, which Intune applies to all users and all devices when nothing else is available to assign.

The trap is that default profile. It is always present, it covers everything, and it is the profile in force on any device your targeted assignment missed. If provisioning behaves differently on one device for no visible reason, check whether it is falling through to the default before looking anywhere else. The resolution logic has the same shape as an Intune policy conflict and it goes wrong for the same reason: the object that won is not the object you were looking at.

The failure modes

Mixed line-of-business and Win32 apps in the blocking list

This is the one that costs a day. Microsoft’s wording is unambiguous: do not mix LOB and Win32 apps, because both LOB MSI and Win32 installers use TrustedInstaller, which does not allow simultaneous installations. If the OMA DM agent starts an MSI installation while the management extension starts a Win32 installation using the same TrustedInstaller, the Win32 install fails and returns Another installation is in progress, please try again later. On the device that reads as a long stall on the app phase, followed by a timeout message and nothing obviously wrong in the portal. Pick one packaging format for everything in the blocking list and the symptom goes away.

Scripts that run in user context

Microsoft’s guidance is that scripts configured to run using the logged on credentials might not execute during the page, and the documented workaround is to run them in system context instead. Combine that with the fact that scripts are not tracked and the result is a silent gap: the script does not run, nothing reports a failure, and the device reaches the desktop missing whatever the script was supposed to do.

Stuck on Identifying with nothing failing

The device is waiting on tracking state that has not been written locally yet. That state lives in the registry, and reading it is faster than reading the portal.

1# Every phase the page is waiting on, with per item timestamps.
2reg query HKLMSOFTWAREMicrosoftWindowsAutopilotEnrollmentStatusTracking /s

Under that key, DeviceDevicePreparation holds the management extension installation state, DeviceSetup holds the tracking policy and the Win32 app status, and ESPTrackingInfo holds timestamps for every app and policy being watched. There is also a subkey per user SID. If the user SID subkey is absent, device setup failed and account setup was never attempted, which narrows the search considerably.

Collecting the logs

On Windows 10 version 1809 and later, the diagnostics tool gathers everything in one pass.

1# Autopilot area covers the provisioning path and the tracking registry dump.
2mdmdiagnosticstool.exe -area Autopilot -cab C:Tempautopilot.cab
3
4# Wider capture when the failure sits in the provisioning stack rather than the join.
5mdmdiagnosticstool.exe -area DeviceProvisioning -cab C:Tempprovisioning.cab

The file worth opening first inside the cab is MDMDiagReport_RegistryDump.Reg, which contains the same tracking keys in a form you can read on another machine.

Reaching for a sync

A device stuck on this page frequently gets a forced sync as the first response, on the reasonable theory that it is waiting for Intune. It is not. It is waiting on local installation state. Forcing an Intune sync is a useful reflex in other situations and does nothing here.

Device preparation does not use this page at all

Microsoft states in the same documentation that Windows Autopilot device preparation does not use the enrollment status page, so the blocking setting is not applicable to it, and that mixing LOB and Win32 apps is therefore supported there. The device preparation overview describes what replaces it: a simplified out-of-box experience showing a percentage progress indicator, with application and script status surfaced in Intune reporting rather than on the device itself.

I have not run either flow through a production rollout. My tenant is a lab with no enrolled devices, so everything above comes from Microsoft’s documentation and from the registry surface the tracking uses, not from a measured provisioning run. Where I would expect the documentation to understate the problem is the timeout. Sixty minutes is generous for four small apps and nowhere near enough for an estate that has quietly accumulated fifteen blocking apps over two years.

What I would do differently

Keep the blocking list short. The ceiling is 100 apps and that number is a limit, not a target. Everything on the list is a serial dependency standing between a new starter and a usable laptop. Three or four genuinely mandatory apps is a defensible list. Fifteen is a decision nobody made on purpose.

Turn on at least one escape hatch. A profile with blocking enabled and both the reset and the use-anyway options set to No produces, on failure, a device the user can neither use nor recover, and a support call that starts from a wiped machine.

Do not raise the timeout to fix a hang. The timeout controls when you find out, not whether it works.

And if the reason you are tuning these settings is that you need to mix packaging formats, or you need scripts to be tracked, the answer is not another option on this profile. It is device preparation. Where you land on that also shapes how a device is handled at the other end of its life, which is a separate decision covered in Intune wipe vs retire.

One thing the enrolment path also settles, quietly, is who ends up owning the device record afterwards. That is a small field with a long tail of consequences: what the primary user controls, and when to clear it.

nn

Last verified: 22 August 2026.