Fix Intune Remediation Failed 0x87D1FDE8 for Configuration Profiles

Intune error 0x87D1FDE8 usually appears as Remediation failed on a configuration profile, Settings Catalog setting, custom OMA-URI policy, or app configuration policy. The frustrating part is that the same code can show up for several different causes. One device may be using the wrong CSP scope. Another may be on an unsupported Windows build. A third may have a real policy conflict, while a fourth may only need another check-in.

Treat 0x87D1FDE8 as a policy application failure, not as a single fixed root cause. The repair path is to identify the exact setting, confirm whether Windows supports that CSP on the affected device, then prove what the MDM client returned in local logs.

This runbook is for Desktop Engineers and Intune admins who see 0x87D1FDE8, -2016281112, or Remediation failed in Intune device configuration status.

Quick fix checklist

Use this order before deleting profiles or rebuilding devices:

Open the failed policy in the Intune admin center and identify the exact setting that reports 0x87D1FDE8.
Confirm whether the profile is a Settings Catalog policy, endpoint security profile, app configuration policy, or custom OMA-URI.
Check the Microsoft CSP documentation for that setting. Verify scope, edition, and applicable OS build.
Confirm the assignment type matches the CSP scope. A user-scope CSP belongs in a user-targeted policy. A device-scope CSP belongs in a device-targeted policy.
Check the affected device in Intune under Devices > All devices > select device > Device configuration and compare the failed profile against other profiles.
Look for Conflict, Not applicable, Pending, and Error states on nearby settings. These statuses change the next action.
On the Windows client, force a sync from Settings > Accounts > Access work or school > Info > Sync.
Review Event Viewer under Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider.
If the setting is custom OMA-URI, verify the path, data type, value format, and whether the target is ./Device or ./User.
Change one variable at a time, then retest with a small pilot group before updating a production assignment.

Do not start by wiping the device. 0x87D1FDE8 is often a bad policy value, wrong scope, duplicate setting, unsupported build, or delayed check-in.

What 0x87D1FDE8 means in Intune

The Intune admin center often renders the decimal form -2016281112 as 0x87D1FDE8. In practical terms, the MDM client received a policy and could not apply or report it as successfully remediated.

Microsoft’s Intune troubleshooting guidance recommends checking the built-in Troubleshooting + support pane first. It also defines the common policy states you need to separate during triage:

Not Applicable: the policy is not supported on that platform or device context.
Conflict: another policy or existing setting prevents Intune from applying the requested value.
Pending: the device has not checked in or has not reported the final status yet.
Errors: the device attempted the setting and reported a failure.

Those states matter more than the error code by itself. A failed BitLocker setting, Copilot setting, password setting, browser allowlist, and local user CSP can all surface as 0x87D1FDE8, but the fix is different for each one.

Microsoft also documents a known case where a Managed Browser policy can show 0x87D1FDE8 and then clear after the device checks in again. In that specific article, Microsoft says the error does not affect Managed Browser behavior and can be safely ignored. Do not apply that conclusion to every 0x87D1FDE8 case. Use it as proof that the code is a reporting symptom, not a root cause.

Common root causes

Start with these patterns. They cover most enterprise cases.

Wrong CSP scope

Many Windows CSPs are either device scope or user scope. If the documentation shows only a User path, a device-targeted custom profile with a ./Device/... path will fail. If the documentation shows only Device, a user-targeted policy may never apply correctly.

A current example is the Windows AI policy TurnOffWindowsCopilot. Microsoft documents the path as:

./User/Vendor/MSFT/Policy/Config/WindowsAI/TurnOffWindowsCopilot

That setting is user scope. If an admin builds a custom OMA-URI with ./Device/Vendor/MSFT/Policy/Config/WindowsAI/TurnOffWindowsCopilot, the policy is not matching the supported CSP path.

Unsupported Windows edition or build

CSP pages include edition and applicable OS tables. These details are not optional. Some settings support Pro, Enterprise, and Education. Some support only Enterprise and Education. Some are available only on specific Windows 11 cumulative update levels or Windows Insider builds.

If Intune says a setting remediated on one pilot ring and failed on another, compare the exact OS build first. Do not assume every Windows 11 23H2 or 24H2 device supports the same Windows AI, DeviceLock, BitLocker, or Defender setting.

Duplicate policy ownership

A Conflict state means Intune cannot override an existing value or two deployed policies are setting the same thing differently. This commonly happens when a tenant has:

An old custom OMA-URI profile and a newer Settings Catalog policy for the same setting.
A security baseline plus a separate endpoint security profile.
GPO still writing a registry-backed policy while Intune tries to own the same control.
Multiple pilot policies that were never removed after testing.

Search for the setting name, CSP path, registry value, and policy area across all configuration profiles. Retire the duplicate or move the setting to one source of truth.

Wrong data type or value format

Custom OMA-URI policies fail when the path is right but the value is not. Check whether the CSP expects integer, string, boolean, XML, or ADMX-backed SyncML content. Some ADMX-backed policies need encoded XML payloads and specific format handling. A plain true or 1 is not always enough.

Settings Catalog is safer when the setting exists there because Intune handles much of the formatting. Use custom OMA-URI only when you need a setting that is not available in the catalog.

Delayed check-in or stale reporting

A device can show Pending or a stale Error when it has not reported a fresh status. Microsoft explicitly calls out Pending as a state where the device has not checked in or has not reported the status yet.

Before changing the policy, force a sync, confirm the device is online, and check the last check-in timestamp. If a setting succeeds after sync, your fix is monitoring and timing, not policy redesign.

Step-by-step remediation workflow

1. Pin the failure to one setting

In Intune, open the affected profile and drill into the device status. Record:

Profile name.
Setting name.
Error code and decimal code.
Device name and primary user.
Last check-in time.
OS edition and build.
Assignment group.

If a profile has 30 settings and only one failed, do not replace the whole profile. Export or screenshot the failed setting and work from there.

2. Validate assignment and enrollment state

Use Troubleshooting + support > Troubleshoot to select the user. Confirm the user has an Intune license and that the device shows as managed by MDM or EAS/MDM. Microsoft notes that a device must show MDM or EAS/MDM to receive compliance or configuration policies.

If the policy is not listed under Device Compliance or Device Configuration, the profile is probably not targeted correctly. Fix the assignment before changing the CSP.

3. Compare against CSP documentation

Open the Microsoft documentation for the failed setting. Check four things:

Supported scope: Device, User, or both.
Supported editions: Pro, Enterprise, Education, IoT Enterprise, or other listed editions.
Supported OS version and minimum build.
Expected data type and allowed values.

For Windows AI settings, do not assume all Copilot and Recall controls work the same way. The same CSP area can include settings for user scope, device scope, Insider builds, deprecated policies, and features that changed after app-based Copilot experiences shipped.

4. Read the device-side MDM logs

On the Windows client, open Event Viewer:

Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin

Filter around the time of the most recent sync. Look for the CSP path, policy area, SyncML response, and status code. The Intune admin center tells you that remediation failed. The device log usually tells you what the MDM client rejected.

For deeper cases, collect an MDM diagnostic report:

Settings > Accounts > Access work or school > Export your management log files

The exported CAB can help when you need to send evidence to Microsoft Support or compare a successful pilot device with a failed device.

5. Test with a clean pilot policy

Create a narrow test policy for one setting and assign it to a small device or user group. Do not reuse a broad production policy for root cause analysis.

If the pilot succeeds, compare the production policy for conflicts, filters, group targeting, and old settings. If the pilot fails, the issue is likely CSP support, syntax, OS build, or local device state.

6. Remove conflicts carefully

When you find duplicate ownership, do not delete every profile that mentions the setting. Pick the target management plane and document it. For example:

Security baseline owns browser security defaults.
Settings Catalog owns Windows AI user experience controls.
Endpoint security policy owns BitLocker.
Custom OMA-URI is retired after all devices report success.

Then remove or unassign only the duplicate setting. Give devices time to check in before judging the result.

Example: Copilot policy fails with 0x87D1FDE8

A common modern case is an admin trying to disable Copilot through a custom OMA-URI. The policy reports 0x87D1FDE8 on Windows 11 devices.

Triage it this way:

Confirm the exact path in the profile.
Compare it with Microsoft’s WindowsAI CSP page.
Notice that TurnOffWindowsCopilot is documented under ./User/..., not ./Device/....
Confirm the target OS meets the documented Windows build requirements.
Recreate the setting through Settings Catalog if available, or use the correct user-scope OMA-URI.
Assign it to a user pilot group and sync one test device.
Confirm the setting state in Intune and the local MDM event log.

Also check Microsoft’s note that TurnOffWindowsCopilot is deprecated and is not for the newer Copilot experience in some builds. If your business goal is to control the current Microsoft 365 Copilot app or web experience, a legacy Windows Copilot CSP may not be the right control.

Limitations and caveats

0x87D1FDE8 is not enough evidence to approve a fix. Always tie the code to a profile, setting, CSP path, and device log entry.

Be careful with tenant-wide changes. A setting that fails on 5 percent of devices may be correct for the other 95 percent. The failed devices may be older builds, wrong editions, stale enrollments, or devices with GPO residue.

Do not rely only on the Intune portal’s first status after assignment. Sync timing, reboot requirements, user sign-in, and reporting delay can produce noisy early results. Use a second check-in before declaring failure unless the client log shows a hard rejection.

Finally, do not copy an OMA-URI from a forum without checking the current CSP page. Microsoft updates CSP docs as Windows changes. Copilot, Recall, DeviceLock, and other Windows policy areas have changed quickly, and older examples may be wrong for current builds.

Prevention checklist

Add these checks to your Intune change process:

Prefer Settings Catalog over custom OMA-URI when the setting exists there.
Record the Microsoft CSP URL in the change ticket for every custom OMA-URI.
Include supported scope, edition, and OS build in the policy notes.
Use one owner per setting area to avoid baseline and Settings Catalog conflicts.
Pilot by OS ring, not only by department.
Validate one successful and one failed device with MDM client logs before broad rollout.
Keep a retired-policy list so old custom profiles do not stay assigned after migration.

Conclusion

0x87D1FDE8 is a signal that Intune could not finish remediation for a setting. The fastest fix is not to reset the device. The fastest fix is to isolate the failed setting, verify CSP support, check assignment scope, look for conflicts, and read the local MDM logs.

Once you know whether the failure is scope, build support, syntax, conflict, or stale reporting, the repair is usually small. Change the path, move the assignment, remove the duplicate policy, correct the value, or let the device check in again. That approach keeps production profiles stable while you fix the real cause.