The ESP does not have to wait for everything: 'only fail selected blocking apps'

Most Autopilot admins either make the Enrollment Status Page track every required app (slow, fragile builds) or none (users land on an unprotected desktop). There is a middle path — choose exactly which apps block, and since 2024, let everything else install best-effort during pre-provisioning.

The problem

You run Windows Autopilot with an Enrollment Status Page (ESP), and one of two failure patterns is eating your deployments:

• Track everything: the ESP waits for every required app assigned to the device. A build that needs five minutes of genuinely critical software sits at "Apps (7 of 23)" for an hour because Microsoft 365 Apps, Teams and a 2 GB CAD suite are in the tracked set. One flaky installer and the whole enrolment fails with 0x800705b4 (timeout) or an app-install error, and the user is looking at a red screen instead of a desktop.
• Track nothing: you disable app blocking to make builds quick, and users reach the desktop before the VPN client, the EDR agent or the SSO broker has installed. The device works — unprotected, and unable to reach anything behind conditional access — and the first-day support ticket arrives on schedule.

Both camps are missing the same pair of settings: the ESP can block on a selected list of apps rather than all of them, and — since early 2024 — the technician (pre-provisioning) phase can be told that only those selected apps are allowed to fail the build, while everything else installs best-effort.

Why it happens

The ESP settings are nested, and the useful ones only appear once their parents are enabled, so most admins never see them. The chain in the ESP profile (Intune: Devices > Enrollment > Enrollment Status Page) is:

1. Show app and profile configuration progress = Yes
2. Block device use until all apps and profiles are installed = Yes
3. Block device use until these required apps are installed if they are assigned to the user/device = All or Selected. Choosing Selected opens a picker for the specific apps that must succeed before the user gets the desktop.
4. Only fail selected blocking apps in technician phase — this toggle only appears once you have chosen Selected, which is why so few people know it exists. It was added in the Intune 2402 service release (February 2024).

Setting 4 fixes a long-standing pre-provisioning trap. Historically, the technician phase of Autopilot pre-provisioning attempted every required Win32 app targeted at the device, and any one of them failing failed the whole technician run — even if the app was not in your blocking list. The toggle replaces that behaviour with a choice. Set to No, the Intune Management Extension (IME) attempts only the apps you selected as blocking during the technician phase; non-blocking apps are not attempted at all and are deferred until after the user signs in. Set to Yes, the IME attempts all required apps, but only the ones you flagged as blocking can fail the phase — for everything else it makes a best-effort attempt and reports the app as complete to the ESP even if the install failed, with failed apps retried later through the normal IME cycle after sign-in. (Under the hood, as the call4cloud analysis documents, the IME decides which phase it is in by inspecting the FirstSync registry key's LogonID — empty during pre-provisioning, populated during user-driven enrolment.)

The timeout interplay compounds the pain of the track-everything approach. The ESP's Show error when installation takes longer than specified number of minutes defaults to 60. Microsoft's own guidance is that if the ESP tracks Microsoft 365 Apps, other large apps, or simply many apps, you may need to raise that timeout. But a raised timeout cuts both ways: every genuine failure now takes that much longer to surface as a red screen. Blocking on Office does not just slow the happy path — it slows every diagnosis too.

The fix

You can restructure this today in one edit to your ESP profile:

1. In your ESP profile, change Block device use until these required apps are installed from All to Selected, and pick only the apps that genuinely must be present before a user touches the device.
2. Set Only fail selected blocking apps in technician phase to Yes, so pre-provisioning runs are judged on the same short list rather than on every required app assigned to the device.
3. Apply a decision rule for what goes on the blocking list. The test is: would a user reaching the desktop without this app be a security or access incident?

4. Revisit the timeout. With Office and other large apps off the blocking list, the 60-minute default is usually generous rather than tight. If a large app truly must block, raise the timeout per Microsoft's guidance — and accept that failures will take longer to show.
5. Remember what best-effort means for verification: non-blocking apps that fail during the ESP are reported as complete so the build can proceed, then retried after sign-in. A green ESP no longer proves every app landed. Spot-check the IME logs (%ProgramData%\Microsoft\IntuneManagementExtension\Logs) on a sample device after changing the policy.
6. Validate with one pre-provisioning run and one user-driven run before rolling out — the two phases track different app sets (device-targeted vs user-targeted), and your blocking list needs to make sense in both.

The result is the split you actually wanted: the ESP holds the device only until it is safe and able to authenticate, and the long tail of productivity software installs while the user is already working.

How Decolla handles it

Decolla builds Windows devices over your own Intune and Autopilot tenant, and this blocking-versus-trailing split is exactly the kind of decision its written plan is designed to surface. When you assemble a build from the catalogue (260+ items), the plan you approve before anything runs itemises every component with its delivery method — so the question "which of these must the ESP actually wait for, and which can arrive after first sign-in?" is answered explicitly, per customer, in a document you can read, rather than left to whatever the ESP profile defaulted to. Security- and access-critical items block; productivity items trail.

To be clear about what that does and does not mean: Decolla does not make individual app installs or Intune sync any faster — the ESP still waits as long as the blocking installs take. What it changes is that the blocking list is a deliberate, reviewed decision, so devices reach the desktop as soon as the critical set is in place without shipping unprotected. Every change Decolla makes is classified for reversibility in the same plan (automatic, reversible, or flagged irreversible), and Decolla can roll back its own changes per item. Decolla is pre-launch; if this is the kind of provisioning discipline you want without hand-building it, the waitlist is open at decolla.app.

Sources

• call4cloud — Autopilot ESP: only fail selected blocking apps (technician-phase mechanics, IME best-effort behaviour)
• Peter van der Woude — Block access to a device until specific apps are installed (selected blocking apps, timeout guidance for Office/large apps)
• Microsoft Learn — Set up the Enrollment Status Page