The install succeeded on the endpoint. Intune still shows red. But the code sitting in the portal is not 1603 or any other Windows Installer exit code — it is something like 0x87D300C9, 0x87D101F8, or 0x80070005. These come from a different layer entirely: the Intune Management Extension (IME) and the MDM sync channel, not the installer process itself. Troubleshooting them the way you troubleshoot 1603 wastes time, because the fix lives somewhere else.
This article breaks down what each of these three codes actually means, why they show up more often on wrapped EXE installers than on native MSI, and the specific place to look before you touch the install command.
Fast Verdict Matrix
| Failure Surface | Legacy EXE Behavior | Native MSI Behavior |
|---|---|---|
Process monitoring0x87D300C9 | Self-extracting bootstrappers often spawn a detached child process and exit. IME loses the PID it was watching and reports the process as unmonitored, even when the install finishes cleanly. | IME launches msiexec.exe directly. The Windows Installer service reports state back to that same process, so IME never loses the thread. |
Sync / gateway timeout0x87D101F8 | No difference. This is a transport-layer MDM sync error, not an install error — it fires before either package type begins executing. | Same as EXE. Package format is irrelevant here; the failure is between the device and the Intune service. |
Access denied0x80070005 | Custom install paths, hand-rolled registry writes, and non-standard ACLs widen the surface area for SYSTEM-context permission failures. | The Windows Installer service already has well-understood, consistent ACL handling for HKLM and Program Files, which eliminates most of the common causes. |
The Rule of Thumb
- Read the prefix before you read the code.
0x87D3xxxxis the app install engine (IME) — look at process monitoring and how the installer is launched.0x87D1xxxxis the MDM sync channel — check network and proxy conditions on the device before you touch the package. 0x80070005is never a silent-switch problem. It is an ACL failure. Reproduce it underNT AUTHORITY\SYSTEMwith PsExec before changing a single argument in the install command.
The Fix: Eliminate the Surface Area That Causes These
Notice the pattern in the matrix above: two of the three codes are more likely on wrapped EXE installers because the bootstrapper, the custom paths, and the hand-rolled registry writes are all surface area that a native MSI simply does not have. The usual workaround is a PowerShell wrapper — PSAppDeployToolkit or a homegrown script — that tries to launch the real child process directly, set explicit permissions, and paper over the bootstrapper's quirks. That works, but it means writing and maintaining a script per app, and it does nothing about the underlying architecture that caused the problem.
InstallMage removes the surface area instead of scripting around it. It converts the source EXE into a native MSI, so IME launches msiexec.exe the same way for every app in your catalog — no detached child processes, no bootstrapper stub, no custom install path to get an ACL wrong on. The silent switches are detected automatically during conversion, so there is no PSADT wrapper to write, version, and debug for each new package. You get one predictable execution path instead of one script per vendor installer.
Deep Dive
0x87D300C9 — The Unmonitored Process Is In Progress
This code means IME lost track of the process it launched while the install was still running, or shortly after. It is not necessarily a failure — the install may complete successfully on the endpoint while Intune reports this status because IME can no longer confirm what happened.
The most common causes, in order of likelihood:
- A detached child process. The install command points at a stub or bootstrapper EXE that extracts a payload and launches the real installer as a separate, detached process before exiting itself. IME was watching the stub's PID, and that PID is gone.
- Missing or wrong silent switches. Without the correct silent flag, the installer can hang waiting for input it will never receive in a SYSTEM session, which eventually presents as an unmonitored, stuck process.
- Corrupted or incomplete package content. If the
.intunewincontent extracted incorrectly, the installer may launch into an inconsistent state.
To triage it, install PsExec and run psexec -i -d -s cmd.exe to open a shell running as NT AUTHORITY\SYSTEM, confirm the context with whoami, then run the exact install command configured in Intune. If the installer hangs or spawns a visible window in that session, you have found the problem — either the silent switch is wrong, or the install command needs to target the real installer directly instead of a bootstrapper that detaches. For framework-specific silent flags, see the silent install switches guide.
0x87D101F8 — SyncML(504) Gateway Timeout
This one is easy to misdiagnose because it looks like an installer error but is not one. 0x87D101F8 is an OMA-DM SyncML status code: the recipient, acting as a gateway or proxy, did not get a timely response from an upstream recipient it needed to reach to complete the request. In plain terms — the device's management session with Intune timed out somewhere in the sync path, before the Win32 app install was ever dispatched.
Check these in order, and do not touch the package at all:
- Corporate proxy or firewall rules. Confirm the device can reach the required Intune and Microsoft Entra endpoints without interception or inspection breaking the TLS session.
- Device check-in health. In the Intune admin center, check the device's last successful check-in time. A device with a stale or intermittent check-in history will surface sync errors like this one repeatedly.
- Transient service-side issues. If the error clears on its own after the device's next scheduled sync (IME checks roughly hourly, or on a manual sync from the Company Portal), it was a one-off network blip rather than a configuration problem.
Because this code fires upstream of the install step, it will show up identically whether the target package is an EXE, MSI, or .intunewin. Package format is not the variable here — device connectivity is.
0x80070005 — ERROR_ACCESS_DENIED
This is a raw Win32 HRESULT, not an Intune-specific code, and it means exactly what it says: the process did not have permission to do what it just tried to do. In a Win32 app deployment, that permission failure usually happens in one of three places:
- Registry writes under the wrong hive or view. A 32-bit installer writing to
HKLM\SOFTWAREon a 64-bit endpoint gets silently redirected toHKLM\SOFTWARE\WOW6432Nodeby the OS. If the installer also tries an explicit write to the 64-bit view without the right registry reflection flags, that write can be denied. This is a different failure mode from a detection-rule mismatch againstWOW6432Node— here, the installer itself is being blocked mid-write, not just misread afterward. - Install context mismatch. An installer that assumes it is running interactively as the logged-in user, deployed instead in SYSTEM context, will hit access-denied errors the moment it tries to write to a per-user path like
%APPDATA%that does not resolve the way it expects underNT AUTHORITY\SYSTEM. - Endpoint security software. AV or EDR agents that block unrecognized processes from writing to protected folders will produce the exact same code. Check the security agent's block log for the timestamp of the failed install before assuming the packaging is at fault.
Reproduce the failure under SYSTEM with PsExec first, the same as with 0x87D300C9 above. If the write succeeds manually but fails through Intune, compare the exact user context Intune assigned in the Win32 app properties against what the installer expects — see the per-machine vs per-user context guide for how that setting changes which paths and hives are writable.
Frequently Asked Questions
What does Intune error 0x87D300C9 mean?
It means the Intune Management Extension lost track of the process it launched for the Win32 app install — usually because the installer is a bootstrapper that spawns a detached child process and exits. The install may have actually succeeded; IME just could not confirm it. Test the install command under NT AUTHORITY\SYSTEM with PsExec to see whether it hangs or launches a UI it should not.
What does Intune error 0x87D101F8 mean?
It is a SyncML(504) gateway timeout — an MDM sync-channel error, not an installer error. The device did not get a timely response somewhere in its management session with Intune, so the app request never reached the install step. Check network and proxy connectivity to Intune endpoints and the device's recent check-in history before looking at the package at all.
How do I fix Intune error 0x80070005 (Access Denied)?
Reproduce the install manually under NT AUTHORITY\SYSTEM using PsExec to confirm it is a permissions issue and not a silent-switch issue. From there, check for a 32-bit/64-bit registry redirection conflict, a per-machine vs per-user context mismatch in the Win32 app properties, or an AV/EDR agent blocking the write. It is almost never fixed by changing the install command's arguments.
All three of these codes point away from the installer's exit code and toward a different layer — process monitoring, MDM sync, or permissions. Diagnosing them starts with reading the prefix, not the installer's own documentation. And for two of the three, the fastest long-term fix is removing the bootstrapper and custom install paths that create the surface area in the first place — which is exactly what converting the EXE to a native MSI does. For the standard Windows Installer exit codes like 1603 and 3010, see the Intune Win32 app exit codes guide.