TL;DR

If you roll out an Application Control for Business policy with a Managed Installer to a device that is  going through Windows Autopilot, and your Device ESP doesn’t contain at least one Win32 app, and your User ESP has at least one Win32 App, you can end up with a User ESP failure. The Managed Installer policy is delivered through an Intune Remediation. The client doesn’t execute a newly assigned remediation the instant it’s received — Intune’s internal job scheduler (SerialJobScheduler) queues it and runs it on its own interval, separate from the Win32 app agent’s install timeline — so the policy can land after User ESP has already started tracking your Win32 apps. Those apps then sit in InProgressPendingManagedInstaller, waiting for a policy that hasn’t arrived yet, and by the time it does, ESP has already moved on without them.

The fix is simple once you know the mechanism: make sure Device ESP has at least one Win32 app. That forces Application Control for Business to wait for the Managed Installer policy during Device ESP, before Autopilot ever hands control to User ESP.

This post walks through the mechanism and backs every step with lines pulled from an actual MdmDiagReport collected on the affected device – though annonymised.

The environment

• Device ESP apps:
  • Microsoft 365 Apps (installed as Microsoft 365 Apps, not a Win32 app — it’s a Click-to-Run app type) (yes, i know, per Microsoft docs. you should not enable this, but some clients still want to do that).
  • Company Portal (a UWP/Store app, also not Win32)
• User ESP apps:
  • 3 Win32 apps
• An Application Control for Business policy with Managed Installer enabled.
• A Managed Installer configuration created from the builtin policy from Intune.

The Managed Installer policy is pushed via a Proactive Remediation, which — unlike a normal device configuration profile — isn’t applied to the client the instant it’s assigned. The client only picks it up on its own policy check-in cycle, independent of the Win32 app agent’s install timeline.

Because neither app in Device ESP is a Win32 app, nothing in Device ESP ever needs the Managed Installer AppLocker rule. Device ESP can complete perfectly fine while the Managed Installer policy is still nowhere near being applied, resulting in the User ESP failing on Application install.

What the logs actually show

1. Device ESP registers a single, non-Win32-blocking app

Logfile: Appworkload.log

[Win32App][ESPAppLockInProcessor] 1 app(s) have been registered for ESP tracking
for device. 0 app(s) were skipped.

At this point the device is still in Device ESP. Only one app is registered for tracking here (Company Portal); Microsoft 365 Apps doesn’t go through the Win32 app agent at all, so there’s no Win32 app whose enforcement is gated by AppLocker/Managed Installer during this phase.

2. Device ESP finishes, User ESP starts tracking the 3 Win32 apps

Logfile: Appworkload.log

[Win32App][ESPAppLockInProcessor] 3 app(s) have been registered for ESP tracking
for user <GUID>. 0 app(s) were skipped.
0 app(s) were tracked in previous phase.

This is the moment Autopilot moves from Device ESP into User ESP (Account Setup), and the three Win32 apps assigned to the user start being processed.

3. The Managed Installer policy isn’t there yet

[ManagedInstallerSync] Did not find managed installer policy

This log entry lands 2 seconds after User ESP started tracking the Win32 apps. The client is now trying to enforce the Managed Installer requirement for Win32 app installs, but the AppLocker “ManagedInstaller” rule collection hasn’t been delivered by the remediation script yet.

4. Every Win32 app targeted at the user is put on hold

The Win32 app agent logs show, for each of the Win32 apps, the same pattern within the EspPhase: AccountSetup window, in this sample, i have 3 apps:

Logfile: AppWorkload.log

[Win32App] Managed installer opt-in is enabled, but the policy has not been set
on this client, app will not be downloaded until the policy is processed.
PolicyId: <Application_GUID>

[Win32App][ReportingManager] Download state for app with id:
<Application_GUID> has been updated.
Report delta: {"EnforcementState":{"OldValue":"InProgress",
"NewValue":"InProgressPendingManagedInstaller"}}

[Win32App][DownloadActionHandler] Pending Managed Installer enforcement.
App will be processed again after managed installer is enabled.

The same three-line pattern repeats for all three Win32, and the apps are parked in InProgressPendingManagedInstaller almost simultaneously, right at the start of User ESP.

A note which also appears in the logfile is that: the download requests for these apps went out with "EspPhase":"AccountSetup" in the JSON payload (visible in the same log lines) — confirming this is happening inside User ESP, not Device ESP.

5. The Managed Installer policy only lands minutes later

VerifyCompliance Effective AppLocker Policy is: ... RuleCollection Type="ManagedInstaller" ...
[...]
detect.ps1 Intune management extension is set as the managed installer.

6. Meanwhile, ESP has already moved on

The Managed Installer policy briefly took effect once, but the app’s enforcement state flipped from InProgressPendingManagedInstaller to InProgress and back to InProgressPendingManagedInstaller within one second. By the time the app finally reached EnforcementState: Success, the same status report shows “EspPhase”:0 instead of “EspPhase”:3 — meaning ESP was no longer tracking it at all. In other words: the app did eventually install correctly once the Managed Installer policy was fully in place, but only after User ESP had already exited, so from ESP’s perspective the installation counts as failed.

Why Device ESP would have prevented this

If Device ESP had contained at least one Win32 app, that app would have hit the exact same Managed installer opt-in is enabled, but the policy has not been set on this client check — but during Device ESP. Device ESP’s tracking window is evaluated before Autopilot is allowed to proceed to User ESP at all, so Autopilot would simply wait (within its own timeout) at the device phase until the Managed Installer policy landed — which is also when Application Control for Business’s AppLocker policy is normally in place early, since it’s rolled out early in the flow.

In other words: forcing at least one Win32 app into Device ESP turns the Managed Installer dependency into a device-phase blocker instead of a user-phase blocker — and the device phase is exactly where you have the runway to let a Remediation-delivered policy actually land before the client needs it.

The fix

Ensure Device ESP always contains at least one Win32 app in autopilot that uses:

• Application Control for Business with Managed Installer enabled, and
• A Managed Installer policy delivered via Intune’s builtin managed installer, which uses a “Proactive Remediation script).

This is a small, low-risk addition to your Device ESP app list, but it closes a real timing race that otherwise makes Autopilot ESP intermittently — and confusingly — unstable, since the failure is entirely dependent on how fast the remediation happens to run on a given device.