Autopilot ESP and Intune Win32 app dependency sequencing during enrollment

Integration boundary: Autopilot Enrollment Status Page ↔ Intune Win32 app deployment

The Enrollment Status Page (ESP) in Windows 11 Autopilot is designed to block user access until all required apps and policies report a successful state. However, Win32 applications packaged as .intunewin files are processed by the Intune Management Extension in parallel by default, regardless of dependency metadata declared in the Intune portal. This creates a race condition when one Win32 app (for example, a Visual C++ runtime) must be fully installed and registered before a dependent application installer runs.

Documentation confirms that app dependencies can be defined in Intune, yet the ESP does not enforce a topological sort; it tracks each app independently and may report overall success before prerequisite components finish. The behavior has been observed in Windows 11 22H2 and 23H2 (build 22631) with Intune service version 2406, and no official sequencing guarantee has been announced. Workarounds such as chaining apps via PowerShell or bundling multiple install steps into a single .intunewin package increase packaging complexity and obscure per-application reporting in the Intune portal.

Given that parallel installation can succeed on fast hardware but fail under load, making reproduction non-deterministic, the core uncertainty is whether the platform intends to support declarative dependency ordering for Win32 apps during ESP or expects administrators to manage sequencing externally.

• Does the current ESP implementation in Windows 11 23H2 provide any mechanism to enforce install-order guarantees for Win32 apps with declared dependencies?
• If not, is there a supported pattern—short of custom scripting or monolithic packages—that ensures prerequisite Win32 apps complete before dependents start during Autopilot enrollment?