Intune profile error 65000 and 0x87D1FDE8 (Remediation failed): causes and fixes

Error 65000 and Remediation failed are among the least helpful results in Intune: they tell you a Windows device received a setting and didn't apply it, but not why. In this post I'll decode the related codes, show how to find the failing setting and CSP node on the device, and fix the usual causes: edition, build, licensing, custom OMA-URI data and competing configuration.

Symptoms#

• A configuration profile shows Error for some devices, and Per setting status lists one or more settings with error 65000.
• The device's Device configuration list shows the profile with 0x87D1FDE8 or -2016281112, sometimes displayed without the minus sign.
• Custom OMA-URI profiles report other codes from the same family, or SyncML errors.
• On the device, the MDM Admin event log records event ID 404.

65000
0x87D1FDE8 Remediation failed
-2016281112 (Remediation failed)
0x87D1FDE9 Not applicable for this device
0x87D1FDEB Data type conversion failed
0x87D10196 Syncml (406): The requested command failed because an optional feature in the request was not supported.
0x87D101F4 Syncml (500): The recipient encountered an unexpected condition which prevented it from fulfilling the request
Event ID 404: MDM ConfigurationManager: Command failure status.

Why it happens#

How the numbers relate#

0x87D1FDE8 is -2016281112 written as a signed decimal, and its last four hex digits, FDE8, are 65000 in decimal. That's why admins read a per-setting 65000 as Remediation failed (Microsoft's code list doesn't show 65000 itself): the device was asked to set a value and reported that it couldn't. Microsoft's Intune status code list gives the neighbouring codes:

Common causes#

• Edition: the setting needs Enterprise or Education and the device runs Pro.
• Licensing: the device should have stepped up to Enterprise through subscription activation but is still Pro.
• Build: the setting was added in a later Windows release.
• Device state: the setting depends on something the device lacks, such as BitLocker prerequisites, or Defender Antivirus being the active antivirus.
• Custom OMA-URI mistakes: wrong path or scope, wrong data type, wrong value format, or an ADMX that was never ingested.
• Competing configuration: another policy or a GPO sets the same value.

How to fix it#

1. Find the exact setting#

Open the profile and select Per setting status, or go to Devices › All devices, open the device, select Device configuration, then the profile and the failing setting. Note the setting name and test with one affected device.

2. Read event 404 on the device#

Failures are logged under Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin. Event 404 includes the CSP URI of the node that failed and a Result such as (The system cannot find the file specified.):

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'
    Id      = 404
} -MaxEvents 30 -ErrorAction SilentlyContinue |
    Format-List TimeCreated, Message

Match the CSP URI to your setting. Admins commonly report that a 404 for a path ending in FakePolicy/Version is harmless noise. For the full picture, create an MDM diagnostic report from Settings › Accounts › Access work or school: select the account, then Info › Create report › Export; it's saved to C:\Users\Public\Documents\MDMDiagnostics.

3. Check edition and build#

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
    Select-Object EditionID, DisplayVersion, CurrentBuild, UBR

Each setting's CSP page on Microsoft Learn lists its scope, supported editions and minimum OS version; in the settings catalog, the setting's Learn more link takes you there. If the device should be Enterprise, fix the licence or activation. Otherwise, use an assignment filter on OS edition or version, or split the profile by edition.

4. Correct custom OMA-URI settings#

• Copy the path from the CSP documentation; use ./Device/ for device scope and ./User/ only where the CSP supports user scope.
• Match the data type (Integer, String, Boolean and so on) to the CSP's format. A mismatch can surface as 0x87D1FDEB or as a SyncML error.
• ADMX-backed policies take the String data type with a value in this shape:

<enabled/>
<data id="ExampleElementId" value="ExampleValue"/>

Third-party ADMX settings only work after the ADMX file is ingested; see importing custom ADMX templates. Where a settings catalog equivalent exists, use it instead of OMA-URI.

5. Deal with state-dependent settings#

• Passwords: admins report that a password setting can keep showing an error until the user's password meets the new rules. Have the user change it (on Windows, press Ctrl+Alt+Del and choose Change a password), then sync.
• BitLocker: see BitLocker silent encryption not starting.
• Defender Antivirus: see Defender Antivirus settings not applying.

6. Remove competing owners#

If another Intune policy or a GPO sets the same value, give the setting one owner. The policy conflicts guide covers this, including MDMWinsOverGP.

Verify the fix#

• Sync from Access work or school › Info › Sync or with the Sync device action.
• No new event 404 entries appear for that CSP URI, and the effective value shows under HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\<Area> or in a fresh MDM diagnostic report.
• Per setting status shows Succeeded. Reporting can lag behind the device, so trust the device-side checks first.

Prevent it next time#

• Check a setting's supported editions and minimum OS before adding it, especially Enterprise-only settings on mixed Pro and Enterprise fleets.
• Prefer the settings catalog over custom OMA-URI; see choosing the right Intune policy type.
• Pilot new profiles on a small ring and review Per setting status before broad assignment.
• VPN profiles have their own Remediation failed case: see third-party VPN profiles in Intune. More codes: profile and compliance error codes quick reference.

References#

• Error and status codes in Microsoft Intune (Microsoft Learn)
• Collect MDM logs (Microsoft Learn)