Fix Autopilot Device ESP When User-Targeted Blocking Apps Are Ignored

If Windows Autopilot reaches device ESP and the apps you expected to block setup never appear in the blocking list, do not start by rebuilding the Win32 package. Microsoft documents a specific known issue for this exact branch: blocking apps specified in a user-targeted Enrollment Status Profile are ignored during device ESP.

That distinction matters because the failure looks like an app-delivery problem, but the root cause is earlier and simpler. During device ESP, the service that decides which apps should block setup does not know the user identity yet. If your blocking-app logic depends on a user-targeted ESP profile, device setup can move forward without honoring the blocking app list the way your bench team expects.

This is one of those issues that creates bad troubleshooting habits fast. Admins see a device hit the desktop too early, assume Intune skipped required apps, then start changing detection rules, reinstall commands, or supersedence chains. Microsoft’s known-issue wording points somewhere else: ESP profile targeting and phase alignment.

Quick fix checklist

Use this order before you repackage anything:

1. Confirm the symptom happens during device ESP, not during the user ESP phase.
2. Check whether the affected Enrollment Status Page profile is targeted to a user group.
3. Review the ESP setting Block device use until all apps and profiles are installed.
4. If you use the blocking-app list, confirm whether the apps are expected to block device setup or user setup.
5. Move the ESP profile to a device group or use the default ESP profile that targets all users and devices.
6. Verify the apps that must block early setup are assigned as required to a group that contains the device.
7. Confirm those apps install in device context and do not depend on user-context applicability rules.
8. Export an MDM diagnostics CAB before rerunning Autopilot.
9. Re-test one pilot device from OOBE after the ESP targeting change.

If changing the ESP profile to a device group fixes the issue on a pilot device, stop touching the app package. You found the control-plane problem.

What Microsoft is actually saying

Microsoft’s current Windows Autopilot known issues page describes the issue this way:

Blocking apps specified in a user-targeted Enrollment Status Profile are ignored during device ESP

The services responsible for determining the list of apps that should be blocking during device ESP aren't able to determine the correct ESP profile containing the list of apps because they don't know the user identity. As a workaround, enable the default ESP profile (which targets all users and devices) and place the blocking app list there. To avoid this issue, target the ESP profile to device groups.

That wording gives you the whole root cause in one paragraph:

• the problem is specifically about device ESP
• the service cannot determine the correct profile because user identity is not available yet
• Microsoft’s workaround is to use the default ESP profile
• Microsoft’s prevention guidance is to target the ESP profile to device groups

This is why the issue deserves its own exact-symptom article. If the environment is healthy enough for profile download, tenant enrollment, and app assignment, the visible miss can still come from the ESP not being able to map a user-targeted profile at the device phase.

Why the blocking logic breaks

Microsoft’s ESP documentation and troubleshooting guidance help explain the mechanics.

The Intune ESP setup page says you can configure Block device use until all apps and profiles are installed and optionally define a blocking apps list. That makes many admins assume the same blocking list will always apply as long as the app is required somewhere.

But Microsoft’s ESP troubleshooting article draws a sharper line:

• device-targeted apps are tracked during the device setup phase
• user-targeted apps are tracked during the user setup phase

That is the key model to keep in your head.

If you are in device ESP, anything that relies on user identity is fragile by design. Microsoft explicitly says the service cannot determine the correct blocking-app list from a user-targeted ESP profile because the user is not known yet. So the device is not ignoring your app because Intune delivery is broken. It is missing the blocking instruction because the profile logic does not line up with the phase that is currently running.

This is the known issue when

You are likely in this exact branch when the pattern looks like this:

• the device is in Windows Autopilot OOBE
• the problem happens during device setup, before the full user phase is established
• the blocking apps are configured in an ESP profile targeted to users
• the apps do not appear in the blocking list during device ESP
• the device reaches the desktop or advances farther than expected
• the same apps can still install later, or behave normally in a different ESP phase

This is especially common when the service desk says something like:

• “The app is required, but ESP never waited for it.”
• “The profile looks correct, but OOBE did not block.”
• “Only some devices skip the blocking list, especially at the bench.”

In those cases, check who or what the ESP profile targets before checking the app command line.

This is probably not only this issue when

Do not over-apply the known issue.

You likely have a different or additional problem when:

• the apps fail even after the user reaches the desktop
• the apps are device-targeted and still never install
• the app depends on user-context requirements or user context install behavior
• the device has broader MDM enrollment problems
• ESP times out with unrelated failures in logs
• TPM attestation, profile assignment, or Conditional Access is failing earlier in OOBE

The ESP targeting issue explains why blocking apps are ignored during device ESP. It does not explain every failed app install in Autopilot.

Logs and where to check

1. Confirm whether you are in device ESP or user ESP

This is the first branch that matters. Microsoft’s ESP troubleshooting doc says:

• device-targeted apps are tracked during the device setup phase
• user-targeted apps are tracked during the user setup phase

If your engineers are reading screenshots or videos from the bench, verify which phase is on screen before you conclude the wrong app was skipped.

2. Review the ESP profile assignment model

In the Intune admin center, open the relevant Enrollment Status Page profile and verify:

• is the profile targeted to users or devices?
• is the blocking app list defined there?
• is Block device use until all apps and profiles are installed turned on?
• are the apps in Block device use until these required apps are installed if you use selective blocking?

Microsoft’s own workaround is clear: if the issue is happening during device ESP, move the blocking logic to an ESP profile that can be resolved without user identity. That usually means the default ESP profile or a profile targeted to the device group.

3. Check the app targeting itself

Microsoft’s ESP troubleshooting guidance says required apps are tracked correctly when these conditions are true:

• the apps are assigned as required
• the target group contains the device for device-phase tracking or the user for user-phase tracking
• the apps install in device context
• the apps do not have user-context applicability rules

That means your remediation cannot stop at “move the ESP profile to a device group.” Also verify that the apps you expect to block device ESP are actually compatible with device-phase behavior.

4. Export MDM diagnostics

Use the built-in diagnostics tool before repeated OOBE retries:

mdmdiagnosticstool.exe -area DeviceProvisioning -cab C:\Temp\esp-device-phase.cab

Microsoft’s ESP troubleshooting article says the resulting CAB includes MDMDiagReport_RegistryDump.Reg, which contains MDM enrollment keys, Windows Autopilot profile settings, policies, and application state.

For ESP troubleshooting, Microsoft points you to this registry path inside that dump:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}\FirstSync

That is a useful evidence point when you need to prove whether device or user phase behavior was skipped, applied, or misaligned.

Practical remediation workflow

Step 1: Prove the ESP phase mismatch

Take one failing device and answer these questions before making changes:

1. Did the miss happen during device setup?
2. Is the ESP profile with the blocking apps targeted to a user group?
3. Are the apps expected to block before the user identity is established?

If all three are true, you already have enough evidence to test the Microsoft workaround.

Step 2: Move the ESP profile to device targeting

Microsoft’s known-issue guidance gives you two safe paths:

• enable the default ESP profile, which targets all users and devices, and place the blocking app list there
• or target the ESP profile to device groups

For most enterprise teams, the cleaner long-term fix is a device-group-targeted ESP profile because it makes the phase logic explicit and avoids hiding tenant intent in user-only assignments.

Also remember that Microsoft’s Autopilot profile guidance says deployment profiles are applied after the device group is created. Keep the same discipline for ESP where possible. If the setup phase is device-driven, target the control to the device.

Step 3: Align blocking apps to the device phase

After fixing the ESP profile target, check the app design:

• assign the must-have apps as required to the device group
• confirm they install in system/device context
• remove user-context assumptions from apps that must block device ESP
• keep user-context apps for user ESP or post-enrollment delivery

This is where many teams cleanly separate “bench critical” apps from “user session” apps. VPN clients, security agents, remote support tools, and tenant bootstrap utilities are good candidates for device-phase blocking. User-personalized apps often are not.

Step 4: Re-test from clean OOBE

After the targeting change:

1. sync the policy changes in Intune
2. reset or reprovision one pilot device
3. watch whether the app now appears in the blocking path during device ESP
4. capture the exact timing and screenshots
5. verify whether the device now waits correctly before proceeding

Do not roll the change tenant-wide until one pilot device behaves the way Microsoft says it should.

What not to do first

When this known issue is in play, these are the usual time-wasters:

• repackaging the Win32 app before checking ESP targeting
• rewriting detection rules because the blocking list did not appear
• assuming every required app should block every phase of ESP
• leaving the ESP profile user-targeted while expecting device-phase behavior
• treating early desktop access as proof that app assignment is broken

Those actions create noise. The known issue is about phase identity and ESP targeting, not about generic app failure.

Caveats

A few limits matter here.

First, Microsoft’s guidance is specifically about device ESP. User-targeted logic can still make sense during user ESP, where the service actually knows who signed in.

Second, moving the ESP profile to a device group does not magically fix bad app packaging. If the app is misconfigured, it can still fail after the targeting issue is corrected.

Third, not every required app should be a blocking app. If you mark too many apps as blocking, you can create long or fragile provisioning paths that fail for reasons unrelated to this known issue.

Prevention

To avoid seeing this again in the next device wave:

• target device-phase ESP controls to device groups
• keep device ESP and user ESP app expectations separate in your runbook
• use the default ESP profile only when that fits your tenant design and you need Microsoft’s documented workaround quickly
• make a short list of true blocking apps for device setup
• document which apps are expected during device setup versus user setup
• export one MDM diagnostics CAB from a passing pilot device so the team has a known-good baseline

Bottom line

If blocking apps specified in a user-targeted Enrollment Status Profile are ignored during device ESP, the fastest useful fix is usually not in the app package. It is in the ESP profile target.

Microsoft already states the cause: during device ESP, the service cannot determine the right user-targeted blocking-app profile because it does not know the user identity yet. Move the ESP profile to device groups or use the default ESP profile workaround, align the required apps to device-phase tracking, and retest from OOBE before you touch the Win32 package again.

Sources

• Windows Autopilot known issues
• Set up the Enrollment Status Page in the admin center
• Troubleshoot the Enrollment Status Page (ESP)
• Configure Windows Autopilot profiles