Intune Error 0x87D1FDE8 | Fix App Deployments That Fail

A single hex code in the Intune admin center can feel like a dead end. It isn’t. The code is a signpost, not a diagnosis. Your job is to figure out which workload raised it: a configuration profile, a remediation, or a Win32 app install that never met its detection rule.

This guide gives you a repeatable path: confirm the workload, pull the right logs, spot the failing line, then make one targeted change. You’ll also learn when you can safely ignore the code, because Microsoft documents one scenario where the console can show the error even when the device is fine.

What Intune Error 0x87D1FDE8 Usually Means

Intune uses shared error reporting across different workloads. That’s why the same code can show up for a policy, a remediation, or an app. The number alone doesn’t tell you which part broke. The good news is that Intune leaves breadcrumbs in two places: the device-side logs and the per-device “installation details” or “profile assignment” pages.

Treat the code as “enforcement didn’t complete as expected.” In plain terms, the device didn’t get from “assigned” to “applied” for at least one setting or action. Sometimes that’s a true failure. Sometimes it’s a timing glitch where the device reports back on the next check-in and the status clears.

Fast Triage In The Admin Center

• Confirm the workload — Open the device record and see whether the error is tied to a configuration profile, a remediation script, or an app install.
• Check the timestamp — Compare the last check-in time with the error time to spot stale reporting.
• Open the detail pane — On app installs, review the last processing state and any sub-error shown.
• Collect diagnostics — Use the remote action so you can read logs without asking the user to zip files.

Intune Error 0x87D1FDE8 In Win32 App Deployments

Win32 app installs are where this code tends to burn the most time, because a “failed” status can mean three different things: the installer returned a bad exit code, the install succeeded but detection didn’t match, or the Intune Management Extension never ran the job.

On Windows 10/11, Win32 apps run through the Intune Management Extension (IME). IME decides when to download content, which account context to use, how to run the install command, and how to evaluate detection. When the console shows a failure, the IME logs usually tell you which step failed and what IME expected to see after.

Quick Checks That Catch Most Win32 Failures

• Confirm install context — If the app needs admin rights, “User” context often fails even when the command works in an admin prompt.
• Test the install command — Run the exact command line from an admin prompt on a similar device and confirm the exit code.
• Validate detection logic — If detection checks the wrong path, registry view, or version string, Intune can mark a good install as failed.
• Retry after a cycle — A fresh IME cycle after a reboot can flip status once the device reports again.

Where To Pull The Clues Without Touching The Device

When you can’t remote in, Intune still gives you two strong options: device diagnostics and the per-device app troubleshooting view. Microsoft’s Win32 troubleshooting flow is built around collecting diagnostic files from the device and reviewing them alongside the install timeline.

Device diagnostics is also useful when the same error hits many devices, because you can compare the same log sections across machines and spot the one variable that differs: OS build, disk space, proxy rules, or a missing prerequisite.

Use Intune’s Built-In Diagnostics Collection

• Open the device record — In the Intune admin center, go to the Windows device that shows the failure.
• Run Collect diagnostics — Trigger the remote action and wait for the notification that diagnostics are ready.
• Download the package — Extract it into a folder named with the device and date.
• Search inside logs — Look for the app name, the content ID, and the last error line around the failure time.

Know The IME Log Path For On-Box Checks

If you do have access to the machine, the IME logs are typically under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. A good first stop is IntuneManagementExtension.log, which records app processing and status reporting.

Logs That Tell You Exactly What Broke

Logs are the shortest route to a fix. Your goal is to capture the line that says what IME tried to do, what it expected to see after, and what it got instead. Once you have that line, the fix stops being guesswork.

To line up events, note the device time zone and the timestamp format in each file. IME logs can be UTC on some builds and local time on others. When you’re unsure, search for the policy download line, then read forward until the first failure and capture the minute it flips.

Windows Logs That Pair Well With IME

• Read IntuneManagementExtension.log — Find the policy update, download step, install command line, and detection evaluation.
• Check AgentExecutor.log — If a script-based detection rule runs, this log can show script output and exit code.
• Review AppWorkload.log — Newer IME builds add workload-oriented logs that can make timelines easier to follow.
• Inspect Event Viewer — MSI installs often log extra detail under Application, System, or MsiInstaller.
• Capture installer logs — Many installers can write a log file; store it under ProgramData so diagnostics can collect it.

What To Search For Inside The Log

• Find the command line — Confirm the exact install command IME ran, including quoting and working directory.
• Look for the exit code — A non-zero code often points to missing prerequisites, access denied, or a reboot requirement.
• Locate detection results — You want the line that evaluates the rule and states whether it matched.
• Spot timing issues — Download timeouts or stalled “preparing” steps can point to network or content delivery trouble.

Common Causes And The Fix That Matches Each One

This section keeps you out of random tweaks. Once you know whether the failure is install, detection, or reporting, the fixes get pretty mechanical. Use the table to map what you see to the next check.

Fix Detection Rule Mismatches

Detection is the top reason a clean install still shows as failed. It often happens after a vendor changes an EXE name, writes the version to a different registry value, or installs per-user when you expected per-machine.

• Match what the installer does — Install the app once, then confirm the real file path, product code, or registry value that proves it’s present.
• Check 32-bit vs 64-bit views — A 32-bit app can write to WOW6432Node; your detection must query the same view.
• Pick stable markers — Use a file version or MSI product code that won’t change every minor update.
• Keep scripts deterministic — Return clear exit codes and avoid user profile paths that differ by device.

Fix Install Command Issues

If the log shows the command line ran and returned a failure code, put your attention on what the installer expected that IME didn’t provide. Silent switches, working directory, and quoting errors are common culprits.

• Run the same command locally — Use an admin prompt and confirm it installs without prompts or dialogs.
• Log the installer output — Add a logging switch and store the log under ProgramData.
• Handle reboots cleanly — If the app needs a reboot, return the right code and let Intune retry.
• Validate content paths — If your command references a file, confirm it exists in the extracted content folder.

Fix IME And Check-In Problems

When the app never appears in IME logs, the device may not be running the agent, or it may not be receiving the assignment. This can show up after enrollment trouble, service crashes, or network filtering.

• Confirm the IME service — Check Services for Microsoft Intune Management Extension and restart it to trigger a new cycle.
• Force a device sync — Trigger a sync from Company Portal or the device’s Access work or school page, then watch for new log entries.
• Check proxy rules — If your network blocks downloads, you’ll see repeated retry lines around content retrieval.
• Reinstall the agent if needed — Re-assign a Win32 app or script so Intune deploys the extension again.

When The Code Can Be Ignored And How To Reduce Repeat Hits

Microsoft documents a known issue where deploying a Managed Browser policy can show 0x87D1FDE8 in the console. In that case, the error can disappear after the device checks in again, and it doesn’t change the app’s behavior. If your case matches that exact policy scenario, you can stop chasing the code and verify the policy result on the device.

For everything else, fewer repeat failures come from predictable deployments: stable detection, clean packaging, and a small pilot ring before broad assignment.

Packaging Habits That Reduce Failures

• Keep installers quiet — Use vendor-documented silent switches and test them on a clean VM.
• Pin dependencies — Deploy runtimes as separate required apps, then set dependencies so installs run in order.
• Use supersedence carefully — Replace older versions with clear uninstall behavior, and update detection to match.
• Stage a pilot ring — Assign to a small group first, then expand once logs look clean.

A Repeatable Checklist For The Next Time

• Confirm what failed — App, profile, or remediation.
• Collect diagnostics — Download the logs and sort by time.
• Find the failing line — Command, exit code, or detection mismatch.
• Apply one change — Fix the root cause, not three settings at once.
• Recheck after a cycle — Force a sync and confirm status after IME runs again.

If you’re still stuck, search the logs for a second code or message next to the hex value. That extra text is usually the real clue. When you pair it with the failing step, the fix becomes straightforward.

You may also see the string intune error 0x87d1fde8 in log lines and status payloads. Keep a short note of what the logs showed and which change cleared it, and you’ll fix the next hit faster.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback