Mixing Win32 and MSI LOB apps during ESP: the invisible msiexec collision

Your Autopilot build sits at "Apps (0 of 5 installed)" and eventually times out — but only on some devices, some of the time. If your required apps mix Win32 and MSI line-of-business formats, two delivery stacks are fighting over msiexec in a session nobody can see.

The problem

An Autopilot deployment stalls during the Device setup phase of the Enrollment Status Page (ESP), typically frozen at an app count such as Apps (0 of 5 installed), before failing with the timeout error 0x800705b4. The maddening part is the inconsistency: the same profile, the same apps, and one device sails through while the next hangs. Re-provision it and it might work.

You hit this when your ESP-blocking (required) apps include both MSI line-of-business apps (an .msi uploaded directly to Intune) and Win32 apps (.intunewin packages). Nothing in the Intune portal warns you about the combination, and no error surfaces on the device — because, as Andrew Taylor puts it, the failure dialog appears in the SYSTEM context AND during ESP so no-one sees it at all.

Because it is a timing race, it is worst on estates with several sizeable MSI LOB apps: the longer an MSI install runs, the wider the window for a Win32 install to crash into it.

Why it happens

Intune delivers the two app types through two separate stacks that do not coordinate with each other:

• MSI LOB apps are delivered by the MDM enrolment stack, which hands the .msi straight to msiexec. Intune staggers these installs, but maintains no live queue of them.
• Win32 apps are delivered by the Intune Management Extension (IME), which queues its own installs sequentially — but has no visibility of what the MDM stack is doing.

Windows Installer only permits one execute-phase installation at a time (guarded by the global _MSIExecute mutex). So when the IME starts a Win32 app whose installer invokes msiexec while an MSI LOB install is still running, Windows Installer refuses with exit code 1618 — ERROR_INSTALL_ALREADY_RUNNING.

"If you are lucky, the apps will have completed installing before the first Win32 hits, but if not, your Win32 app will start the installer, trigger msiexec which will get extremely unhappy because it's already in-use."
— Andrew Taylor, Why not to mix Win32 and MSI LOB applications in Intune

Interactively, you would see the familiar "there is already an installation in progress" dialog and click through it. During ESP there is no interactive session: the dialog is raised in SYSTEM context (session 0), nobody can dismiss it, the install neither completes nor cleanly fails, and ESP waits until its timeout expires. That is why the failure looks random — it is a race condition, not a broken package.

The fix

1. Standardise on Win32 — wrap your MSIs

The durable fix is to stop mixing formats. Andrew Taylor's advice: always wrap as a Win32, it's extremely easy. For each MSI LOB app:

1. Package the .msi into an .intunewin with Microsoft's Win32 Content Prep Tool.
2. Install command: msiexec /i "yourapp.msi" /qn /norestart (Intune pre-fills this when it detects an MSI inside the package).
3. Detection rule: use the MSI product code (also auto-populated).
4. Assign the Win32 version, confirm detection on a test device, then retire the LOB assignment.

Once everything is Win32, the IME's sequential queue is the only thing driving msiexec during ESP, so the collision cannot occur. You also gain supersedence, dependencies, requirement rules, delivery optimisation and custom detection — none of which LOB apps support.

2. Until you've migrated, keep the two types apart in ESP

If some LOB apps must remain temporarily, remove one type from the ESP blocking-app list so they don't install concurrently during Device setup. Apps installing after ESP can still hit 1618, but the IME's retry cycle will generally converge — and the build no longer stalls in front of the user.

3. Diagnose a device that's stuck right now

• Check C:\ProgramData\Microsoft\IntuneManagementExtension\Logs (IntuneManagementExtension.log / AppWorkload.log) for exit code 1618 or "another installation is in progress".
• Inspect HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking — your blocker is the app that never reaches InstallationState = 3 (Completed): a mutex-stalled install sits indefinitely at 1 (NotInstalled) or 2 (InProgress). A value of 4 means the app failed outright (Error) — that stops ESP too, but it is a different failure from the silent stall described here.
• Run the community Get-AutopilotDiagnostics script against the device or its diagnostics ZIP to see per-app timings and which install sat on the mutex.

4. Longer term, consider Autopilot device preparation

The restriction does not apply to Autopilot device preparation (the newer "APv2" flow) — a point Microsoft's Michael Niehaus raised in the comments on Taylor's post, and which Taylor acknowledged. That alone is rarely a reason to switch — weigh its other trade-offs against classic Autopilot for your estate — but if you are already evaluating it, this niggle disappears there.

How Decolla handles it

Decolla provisions Windows devices over your own Intune and Autopilot tenant, and every deployment starts from a written, itemised plan that you approve before anything runs. Each item in that plan states its delivery method explicitly — so a Win32/LOB mix can never slip into a build unseen.

More fundamentally, everything in Decolla's curated catalogue and Library is packaged to a single, consistent format, so a Decolla build plan never queues MDM-stack MSI installs against IME installs in the first place. The race described above is designed out of the plan rather than debugged afterwards.

To be clear about the boundary: Decolla standardises what it deploys. It does not repackage or rewrite LOB apps you have assigned in your tenant outside a Decolla plan — for those, the migration steps above are the fix. Decolla is currently pre-launch; if this is the class of problem you spend your provisioning days on, you can join the waitlist at decolla.app.

Sources

• Andrew Taylor — Why not to mix Win32 and MSI LOB applications in Intune
• Microsoft Q&A — Windows Autopilot deployment gets stuck on Device setup (0x800705b4)