Intune error 0x87d1fde8 does not mean a setting failed to apply. It means Intune asked the device for the value back and did not get the answer it expected. Those are different problems with different fixes, and most of the advice ranking for this code treats them as one, which is why the usual sequence of re-sync, reassign and re-enrol rarely moves it. Below is what the code actually reports, the causes sorted by whether the setting really landed, and where the device keeps the evidence. It sits inside the wider Intune troubleshooting order, which is worth following first if more than one profile is misbehaving.
What intune error 0x87d1fde8 actually reports
The same error appears in two forms. The admin centre often shows the decimal value -2016281112, and the device side shows the hex 0x87D1FDE8. They are one number: -2016281112 is how a signed 32-bit integer displays 0x87D1FDE8. Microsoft’s own troubleshooting articles title it “Remediation Failed”.
The useful definition is not in an error table at all. It is in the custom settings documentation, which describes how Intune decides that a setting has applied:
To work with Intune, the setting must support the Add, Replace, and Get operations. If the value returned by the Get operation doesn’t match the value supplied by the Add or Replace operations, then Intune reports a compliance error.
That sentence explains almost every version of this error. Intune writes a value, reads it back, and compares the two. Anything that breaks the comparison produces the error, including cases where the write succeeded perfectly and only the read-back disagrees.
Microsoft says as much in the one place it addresses the error directly. For custom VPN profiles delivered as XML, the troubleshooting article states:
If the XML differs between the policy and the client response, Intune interprets the mismatch as a remediation failure.
And then: “You can safely ignore this error because the connection works as expected.” A second article does the same for a Managed Browser policy, calling it “a known issue in Microsoft Intune.” So on at least two documented paths, intune error 0x87d1fde8 is a reporting artefact, not a failure.
One more detail worth knowing before you go looking for an official definition. The old Intune page of common error codes, the table that used to map 0x87D1FDE8 to Remediation failed alongside its neighbouring codes, now redirects from TechNet to a Learn address that returns a 404. If you have it bookmarked, the bookmark is dead. The definition that survives is the read-back rule quoted above.
Sort the causes by whether the setting landed
This is the triage that saves the afternoon. Before changing anything in Intune, check the device itself: the registry key, the policy result, or simply whether the behaviour the setting controls has changed. Then work the list for whichever side you are on.
The setting applied, and the report is wrong
If the device is behaving as configured, you are looking at a read-back mismatch rather than a failure. The documented examples are the custom VPN XML and the Managed Browser policy above. The pattern extends further in practice: nodes that are written in one form and returned in another, and nodes whose Get response does not echo the value you sent. The custom settings page warns that the requirement is support for Add, Replace and Get, and not every node in the CSP reference behaves well on all three.
The honest response here is to record the exception and stop. Re-pushing a setting that has already applied changes nothing, because the comparison will fail the same way next time.
The setting is not supported where you sent it
The custom settings page is blunt about scope: “Intune doesn’t support all the settings listed in CSP reference.” It also says “Not all settings are compatible with all Windows client versions. The CSP reference lists the supported versions for each CSP.” Each Policy CSP page carries an applicability table listing editions and the minimum Windows build. A setting sent to a Pro device that the table lists only for Enterprise and Education, or to a build older than the minimum, is one of the causes that comes up most often in the Microsoft Q&A threads on this error.
Check the applicability table for the exact node before anything else. It is the cheapest test there is.
A dependency was never set
Some settings only take effect when another setting holds a particular value, and the CSP documentation says so on the node. The clearest example is in DeviceLock:
The DevicePasswordEnabled setting must be set to 0 (device password is enabled) for the following policy settings to take effect
Send MaxInactivityTimeDeviceLock on its own and the device has no reason to honour it. Read the node’s page for a dependency line before assuming the value is wrong.
The payload is malformed, or the ADMX is not there yet
ADMX-backed policies have a payload format of their own, and it is strict. From Microsoft’s ADMX documentation, a Boolean policy that is enabled sends a payload that “is simply <enabled/>“, and for policies with inputs:
For every <text> element and ID attribute in the ADMX policy definition, there must be a corresponding <data /> element and ID attribute in the payload.
A missing <data /> element, a mistyped ID, or smart quotes pasted in from a document will all fail. For third-party ADMX, such as browser or OEM templates, there is an ordering problem as well. The template is ingested through ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall, and a setting that arrives before its template has been ingested has nothing to apply to. In a Microsoft Q&A thread about an OEM template, the accepted answer was exactly that: the ADMX ingest had not completed before the setting was applied. I have not found Microsoft documentation that ties the ordering problem to this error code, so treat it as field experience rather than documented behaviour.
The OMA-URI or the data type is wrong
Microsoft notes that the OMA-URI field is case sensitive. A path copied with the wrong case, a ./User path for a device-scoped setting, or a node renamed in a later Windows release will all produce failures. Data type is the other half. The custom settings page lists the types Intune accepts, including String, Integer, Boolean and Base64. Sending an Integer node as a String is a mistake I would expect to surface as a read-back mismatch, but no Microsoft page I found states that explicitly, so I am flagging it as my expectation rather than a documented cause.
It is a conflict, not this error
If the status says Conflict rather than Remediation failed, you are in a different problem. Microsoft defines Conflict as “There’s an existing setting on the device that Intune can’t override.” That usually means two Intune profiles, or a Group Policy object, setting the same thing. The Intune policy conflict diagnosis is a separate path and does not need anything on this page.
Where the device keeps the real error
The admin centre shows you that the comparison failed. The device shows you why. Two sources matter.
The first is the MDM event channel. Microsoft documents it as the microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx log, “main one that contains MDM events”, under Applications and Services Logs, Microsoft, Windows, DeviceManagement-Enterprise-Diagnostics-Provider, Admin. Filter it to the time of the last sync and look for the failing node by name. In the threads where admins posted the event, it named the failing node and a result far more specific than Remediation failed, such as the system not being able to find the file specified.
The second is the MDM diagnostic report. Microsoft gives this command to collect it:
# Collect the MDM diagnostic bundle, including the HTML summary report
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "c:\users\public\documents\MDMDiagReport.zip"
Inside the zip, MDMDiagHtmlReport.html lists every policy the device believes it has, with its current value. Compare that value with what you configured. If they match, you are in the first category above and the report is the problem. If they do not, the event log tells you which of the others it is. When the device will not hand the bundle over remotely, the Intune diagnostic logs collection has its own failure modes worth knowing.
Custom OMA-URI or settings catalog
Many of the threads on this error involve custom OMA-URI profiles built before the settings catalog carried the same setting. Microsoft describes catalog settings as generated directly from the Windows CSPs, so the path, the data type and the payload shape are generated rather than typed. That removes three of the causes above at a stroke.
I would not migrate a working custom profile just to tidy up. I would migrate any custom profile that is producing intune error 0x87d1fde8 and whose setting now exists in the catalog, because that is the cheapest fix available and it removes a hand-typed path from the estate. The trade-offs between catalog and template profiles are covered in settings catalog vs administrative templates.
What I would do differently
I would stop treating Remediation failed as a single status. It is two statuses that share a code: the setting did not apply, and the setting applied but read back differently. The second one is common, it is sometimes documented as safe to ignore, and it eats far more time than the first because nothing you change in Intune fixes it.
So the first move is always on the device, not in the console. Confirm the behaviour, open the diagnostic report, and only then decide whether you have a configuration problem or a reporting one. If it is reporting, write it down with the node name and move on. If it is configuration, the applicability table and the dependency line on the CSP page answer most cases before you need the event log at all.
Primary sources, verified on the date below: Use custom settings for Windows client devices in Intune, 2016281112 (Remediation Failed) error in a custom VPN profile, and Understanding ADMX policies.
Last verified: 9 October 2026. I have not run this in production; my tenant is a lab with no enrolled devices, so everything above is what the documentation states, what practitioners report, and where I would expect it to bite.
