0x87D101F8 is the code that sends admins hunting through installer logs for a bug that is not there. It is an OMA-DM SyncML status, a gateway timeout in the management channel between the device and Intune. It is reported against a Win32 app, but it describes a sync that did not complete, not an install that failed. Repackaging the app will not clear it. What a native MSI does change is how much noise surrounds it, so you can tell a transport problem from a payload problem in minutes instead of hours.
Fast Verdict Matrix
| Behavior | Legacy EXE Behavior | MSI Behavior |
|---|---|---|
| Root cause of 0x87D101F8 | Sync or gateway timeout between device and Intune. Independent of the package. | Same. Package format does not cause or cure a transport timeout. |
| Ability to rule out the installer | Hard. A wrapper script, bootstrapper and vendor setup all sit between you and a clean exit code, so every failure looks suspect. | Easy. If msiexec never logged, the install never started. |
| Behavior on retry after a timeout | A half-run installer may be re-launched over leftover state, producing a second, different error. | Windows Installer is transactional; a retry starts clean or repairs cleanly. |
| Detection after a late sync | Custom detection scripts can misread a partial install. | MSI product code detection is binary: installed or not. |
The Rule of Thumb
- No install log means no install bug. If
IntuneManagementExtension.lognever shows the install command starting, stop editing the package and look at connectivity, proxy and sync. - Fix the channel, then simplify the payload. Clear the network path first. Then remove the wrapper layers that make the next transient failure hard to classify.
The Fix: A Package You Can Rule Out Quickly
The network side is yours to fix: proxy rules, TLS inspection, and reachability of the Intune endpoints. The packaging side is where tooling helps. A PowerShell wrapper such as PSAppDeployToolkit adds a script, logging and its own failure modes, and when a deployment goes red, each layer is a suspect.
InstallMage converts the source EXE into a native MSI, so the install is one Windows Installer transaction with a standard exit code and a product code for detection. When 0x87D101F8 appears, you can confirm in one log search that the installer never ran, and send the ticket to the network team instead of rewriting a wrapper. See how this compares in the PSAppDeployToolkit vs InstallMage guide.
Deep Dive
What the Code Actually Means
SyncML is the protocol Windows MDM uses to exchange commands with Intune. Status 504 is defined as a gateway timeout: the recipient, acting as a gateway or proxy, did not get a timely response from an upstream server. 0x87D101F8 is that status surfaced in the Intune console. The key point is when it occurs: the management session timed out, so the Win32 app work was never dispatched or never acknowledged. The status codes are broken down alongside the others in the status code reference.
Proving the Installer Never Ran
On the device, open C:\ProgramData\Microsoft\IntuneManagementExtension\Logs and search IntuneManagementExtension.log for the app ID. Then check whether an install attempt was logged at all. For an MSI, also look for a Windows Installer entry:
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
ProviderName = 'MsiInstaller'
StartTime = (Get-Date).AddHours(-2)
} | Select-Object TimeCreated, Id, MessageNo MsiInstaller events in the window, and no command start in the IME log, confirms the timeout happened before execution. Wrapped EXEs make this harder, because activity from a bootstrapper or script can be mistaken for an attempt. If the log instead shows the command starting and a real exit code, you are looking at a different problem, such as the one in the 1603 guide.
Checking the Sync Path
Force a sync from Settings, Accounts, Access work or school, Info, Sync, or restart the Intune Management Extension service, then watch the log for the retry. If the timeout repeats, test the path: confirm the device can reach the Intune service endpoints, that a proxy or SSL inspection device is not stalling the TLS session, and that the same failure appears on more than one device or network. A failure on one device only points at that device; a failure across a site points at the network. Once it clears, the app should install on the next check-in with no change to the package.
Frequently Asked Questions
What does Intune error 0x87D101F8 mean?
It is a SyncML 504 gateway timeout. The management session between the device and Intune did not complete in time, so the app deployment was not dispatched or acknowledged. It is a sync-layer error, not a Windows Installer exit code.
Is 0x87D101F8 caused by my installer or package?
Almost never. It fires before the install command runs, so the package format is irrelevant to the cause. Check the IME log for the command start; if it is absent, investigate connectivity, proxy and TLS inspection rather than the installer.
How do I make this error easier to diagnose without PowerShell wrappers?
Deploy a single native MSI instead of a wrapped EXE. With InstallMage the install is one msiexec transaction with a standard exit code and MSI product code detection, so you can rule the installer in or out with one log search and send the issue to the right team.
0x87D101F8 is a message about the management channel. Confirm the installer never started, fix the path to Intune, and keep the package simple enough that the next transient failure takes minutes to classify.