0x87D1FDE8 Remediation Failed: Fix This Intune Error

When the Microsoft Intune admin centre reports 0x87D1FDE8 beside a Remediation failed status, it is telling you the device did not reach the state the policy demanded — and almost nothing else.

Status: Error
Error code: 0x87D1FDE8
Remediation failed

This code is generic. It appears against configuration profiles, remediation scripts, and Win32 app deployments alike, and Microsoft does not publish a single canonical cause for it. Anyone who tells you it means one specific thing is guessing. The productive approach is to stop treating it as a diagnosis and use it as a pointer to where the real detail lives.

Why This Happens

Intune reports policy outcomes centrally while the work happens on the device. When the device cannot confirm the required end state, the service records a remediation failure and surfaces this shared code. The underlying cause is nearly always one of:

• A conflicting policy — two profiles setting the same setting to different values, so neither can be satisfied.
• An unsupported setting for that Windows edition, hardware, or platform.
• Assignment targeting that reaches devices the policy was never designed for.
• A script that fails or reports failure through its exit code.
• A detection rule that does not match what the installer actually produced.
• A device that has not checked in since the policy changed.

Note also that a remediation failure does not always mean the setting is absent. It is a well-documented source of false alarms: a setting can be correctly applied on the device while Intune still reports failure, typically when a GPO or a local configuration owns the same setting and Intune cannot confirm ownership. Verify the real device state before rewriting a working policy.

Step 1: Identify the Workload

This is the step that saves the most time, and it is the one most often skipped. In the Microsoft Intune admin centre, open the affected device and determine which workload raised the error:

• Devices → select the device → Device configuration — a configuration profile.
• Devices → Remediations — a remediation script package.
• Apps → select the app → Device install status — a Win32 app.

Then open the per-setting status for that item. Unlike the top-level code, it names the individual setting or step that failed, and frequently flags a conflict outright.

Step 2: Read the Right Client Log

Intune Management Extension logs live on the device at:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Microsoft recommends CMTrace for reading them. Pick the file that matches the workload:

For MDM policy processing rather than IME workloads, use Event Viewer: Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin.

Step 3: Fix by Cause

Conflicting policies (admin-side)

Two profiles setting the same setting differently is the most common cause. The per-setting status flags the conflict; consolidate the setting into a single profile rather than adjusting both.

Unsupported settings or platform (admin-side)

Confirm the setting is supported on the target Windows edition and hardware. BitLocker settings on devices without a TPM, and Enterprise-only settings assigned to Pro devices, both produce failures that no retry will clear. Note too that the Intune Management Extension does not support Windows in S mode, so anything depending on it will never succeed there.

Script problems (admin-side)

Intune judges a script by its exit code — 0 for success, non-zero for failure. A script that does its job but never sets an exit code can still be reported as failed. Confirm the required context as well: a script that needs administrative rights but runs in user context will fail on every device, consistently.

Detection rules (admin-side)

For Win32 apps, a detection rule that checks a file version, registry key, or MSI product code that the installer did not actually produce reports failure even when the install succeeded. Verify the detection target on a device where the app is genuinely installed.

Device has not synced (user-side)

If the policy or fix is recent, the device may simply not have picked it up. The Intune Management Extension checks in every 8 hours, independently of the MDM check-in.

To force it, open Company Portal → Settings → Sync, which triggers both an MDM check-in and an IME check-in. A Sync from the Windows Settings app or from the admin centre triggers only the MDM check-in and will not force an IME check-in — a distinction that causes a lot of wasted waiting. Restarting the IntuneManagementExtension service from Task Manager also forces a check-in.

Verify the Fix

Confirm on the device rather than trusting the console, then confirm in the console:

Get-Service IntuneManagementExtension
Get-Content "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log" -Tail 100

Then force a sync from Company Portal and re-check the per-setting status in the admin centre. Allow a full check-in cycle before concluding the fix did not work — reporting lags the device.

Prevent It From Recurring

• Pilot every policy against a small group first, and only broaden the assignment once the per-setting status is clean.
• Keep one owner per setting. Overlapping profiles, and Intune competing with legacy GPOs, are the leading source of conflicts.
• Filter assignments by platform and edition so unsupported settings never reach devices that cannot honour them.
• Set explicit exit codes in every script and test in the same context Intune will use, not just interactively as an administrator.
• Validate detection rules on a known-good device before releasing a Win32 app.
• Check the device state, not only the report, before rewriting a policy — the false-alarm case is real and common.

For the surrounding configuration, see our guides on compliance policies and deploying applications.