A Windows device shows your Intune configuration profile as Error, and the per-setting detail says 65000 or 0x87D1FDE8 (Remediation failed). Another device shows the same profile as Conflict. A third has been Pending since yesterday. The ticket says "Intune configuration profile error 65000," and someone is already suggesting you delete the profile and recreate it.
Don't rebuild anything yet. A configuration profile only "works" when the whole chain holds: the profile is assigned to the right kind of group → the device checks in and receives it → every setting is applicable to this Windows version and edition → no other policy (or GPO) sets the same setting to a different value → the device's MDM client accepts each CSP command → the value it reads back matches the value Intune sent. A generic code like 65000 is the console telling you one link failed. The device's own MDM event log usually tells you which one, by CSP URI.
If the device isn't checking in at all (old Last check-in, nothing updates), start with the Company Portal / device not syncing triage. If the failing profile is a Wi-Fi or SCEP certificate profile, those have their own chains: Wi-Fi profile not applying and SCEP certificate profile failed. This post covers Settings catalog, template, endpoint security, and custom OMA-URI profiles on Windows that report Error or Conflict.
TL;DR
- Read status per setting, not per profile. One bad setting turns the whole profile red. Per setting status and the device's Device configuration view show which setting failed.
-
0x87D1FDE8 = -2016281112 = "Remediation failed" in Microsoft's Intune status code list: the device was asked to set a value and didn't end up with it. 65000 is the low 16 bits of that same code (
0xFDE8). Microsoft's list doesn't show 65000 by itself, so treat it as the same generic "remediation failed" signal. - Conflict means two policies set the same setting to different values (or something on the device that Intune can't override). Intune doesn't pick a winner between configuration policies. You resolve it manually. Compliance policy settings always beat configuration profile settings.
- Not applicable usually means the setting isn't supported on that Windows version or edition (for example, an Enterprise-only setting on Pro).
-
The device log has the real error.
DeviceManagement-Enterprise-Diagnostics-Provider> Admin shows "Command failure status" events with the exact CSP URI and Result. - ADMX-backed settings fail when the ADMX definition isn't on the device yet. A Result like "The system cannot find the file specified" points there.
-
GPO and MDM on the same setting is a race unless the setting is in the Policy CSP and
MDMWinsOverGPis set.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Status read | You know which setting failed, on which device, and in which state | "The profile has errors" with no setting named |
| 2. Code | The error code is decoded to a category | 65000 / 0x87D1FDE8 read as "Intune is broken" |
| 3. Conflict | Only one policy sets this setting (or all of them set the same value) | Conflict state; error flips after another team ships a baseline |
| 4. Assignment scope | Included/excluded groups are a supported combination, and the setting scope (user/device) fits the target | Excluded devices still get the profile; user settings N/A on first check-in |
| 5. Applicability | Setting is supported on this Windows version and edition | Not applicable; 0x87D1FDE9 |
| 6. Device MDM log | The CSP command succeeds on the device | Admin log "Command failure status" with a CSP URI and Result |
| 7. Definition / ownership | ADMX definition is present; no GPO fights the same value; Get returns what Add/Replace set | "Cannot find the file specified"; value flips back after gpupdate; Error even though the value looks right |
Pick one device in Error and one device where the same profile is Succeeded and compare them at each step.
Step 1: Read status at the setting level
Profile-level status is a roll-up. Go one level deeper:
- By policy: Devices > Manage devices > Configuration > Policies > select the profile. Device and user check-in status shows the counts, Per setting status shows each setting with its Success/Conflict/Error counts, and View report lists devices with their last check-in.
- By device: Devices > All devices > select the device > Device configuration > select the profile. Every setting is listed with its own state. On a Conflict row, select it to see every policy and profile name that contains the conflicting setting.
- Tenant-wide: Devices > Monitor > Configuration policy assignment failures lists profiles with devices in Error or Conflict. Security baselines and endpoint security profiles are included too.
What each state means (Microsoft's definitions):
| State | Meaning | First move |
|---|---|---|
| Succeeded | Policy applied | Nothing, unless the user sees different behavior (Step 7) |
| Error | Policy failed to apply, usually with an error code | Step 2, then the device log (Step 6) |
| Conflict | Two settings applied to the same device and Intune can't sort it out, or an existing device setting Intune can't override | Step 3 |
| Pending | Device hasn't checked in to receive the policy, or received it but hasn't reported status yet | Check Last check-in and the timing table below |
| Not applicable | Device can't receive this policy or setting (platform, OS version, edition) | Step 5 |
Two report-timing notes from Microsoft that save a lot of false alarms: the Device assignment status report can take 24–48 hours to reflect recent assignment or group membership changes, and the counts in Device and user check-in status and Device assignment status are expected to differ.
Step 2: Decode the code
Microsoft's Error and status codes in Microsoft Intune list covers the configuration-profile family. Convert the decimal you see in the portal if you need to: -2016281112 is 0x87D1FDE8.
| Code | Decimal | Microsoft's message | What it usually points to |
|---|---|---|---|
0x87D1FDE8 |
-2016281112 | Remediation failed | Device couldn't set or keep the value. Read the device log (Step 6) |
65000 |
(low word 0xFDE8) |
Not listed on its own | Read as the same "remediation failed" signal (see note below) |
0x87D1FDE9 |
-2016281111 | Not applicable for this device | Version/edition/platform (Step 5) |
0x87D1FDEA |
-2016281110 | Invalid parameter to CIM setting | Value out of the allowed range or format |
0x87D1FDEB |
-2016281109 | Data type conversion failed | Custom OMA-URI data type doesn't match the CSP |
0x87D1FDEE |
-2016281106 | Not applicable because it lost in conflict resolution | Another policy owns the setting (Step 3) |
0x87D10190 |
— | SyncML(400): malformed syntax in the command | Malformed custom OMA-URI value / ADMX payload |
0x87D10194 |
— | SyncML(404): The requested target was not found | Wrong CSP path, or the node doesn't exist on this build |
0x87D10196 |
— | SyncML(406): optional feature in the request not supported | Feature not supported on this edition/build |
0x87D101F4 |
-2016345612 | SyncML(500): unexpected condition prevented fulfilling the request | Device-side failure. The MDM log Result is the next read |
About 65000: the 65000 = 0xFDE8 relationship is arithmetic, and it's how most admins read it, but Microsoft doesn't document 65000 as its own code. Don't stop at the number. Steps 3–7 find the cause.
One documented special case: Microsoft has a support article for -2016281112 on a password device restriction policy. On Windows desktop (and Android), password rules can't be enforced instantly. The error stays until the user changes their password (Ctrl+Alt+Del > Change a password on Windows). Microsoft recommends a compliance policy for the same password setting so the change is actually enforced.
Step 3: Find the competing policy
Microsoft's conflict rules, at the individual setting level:
| Policies that set the same setting | What applies |
|---|---|
| Compliance policy + configuration profile | Compliance wins. Compliance policy settings always take precedence over configuration profile settings |
| Compliance + compliance | The most restrictive compliance value applies |
| Configuration + configuration (different values) | Conflict shown in Intune. You resolve it manually |
| Custom Apple configuration profile vs other policies (iOS/macOS) | Intune doesn't evaluate the payload, and Apple randomly applies conflicting settings |
Configuration policies come from more places than the Configuration blade: Settings catalog, templates, Endpoint security, Security baselines, and policies you imported from Group Policy analytics. A baseline assigned to "All devices" is a classic source of a conflict on a single BitLocker or Defender setting. The device's Conflict row (Step 1) names every policy holding that setting, so start there.
To check the whole tenant before the next conflict ships, list where the same Settings catalog setting is defined more than once. This is read-only, and it uses the Graph beta configurationPolicies endpoint (where Settings catalog and many endpoint security / baseline policies live). Microsoft supports Intune beta APIs but says they change more often:
Connect-MgGraph -Scopes 'DeviceManagementConfiguration.Read.All'
function Get-GraphAll([string]$Uri) {
while ($Uri) {
$page = Invoke-MgGraphRequest -Method GET -Uri $Uri
$page.value
$Uri = $page.'@odata.nextLink'
}
}
$policies = Get-GraphAll 'https://graph.microsoft.com/beta/deviceManagement/configurationPolicies'
$rows = foreach ($p in ($policies | Where-Object { $_.isAssigned })) {
foreach ($s in (Get-GraphAll "https://graph.microsoft.com/beta/deviceManagement/configurationPolicies/$($p.id)/settings")) {
[pscustomobject]@{
Policy = $p.name
Family = $p.templateReference.templateFamily # e.g. none, endpointSecurity..., baseline
Setting = $s.settingInstance.settingDefinitionId
}
}
}
# Same top-level setting in more than one assigned policy = conflict candidate
$rows | Group-Object Setting | Where-Object Count -gt 1 | Sort-Object Count -Descending |
Select-Object Count, Name, @{n='Policies';e={ ($_.Group.Policy | Sort-Object -Unique) -join '; ' }}
How to read it:
| Result | Meaning |
|---|---|
| Setting in 2+ assigned policies | Candidate, not proof. A conflict needs different values and overlapping targets. Open both policies and compare value and assignment |
| Setting appears once | No Settings catalog overlap. Still check templates, custom OMA-URI profiles, and GPO (Step 7) |
| Your failing setting isn't in the list at all | It may be a template or custom profile (not in configurationPolicies). Use the device's Conflict row instead |
The script compares top-level setting instances only. Child settings (for example, the values under an enabled ADMX setting) aren't flattened, so treat it as a first pass.
Step 4: Read assignment scope (and the exclusions that don't work)
Microsoft's assignment guidance has two rules that explain a lot of "wrong devices got it" and "user settings show N/A" tickets.
Include/exclude combinations. From Microsoft's support matrix:
| Included | Excluded | Supported? |
|---|---|---|
| User group (static or dynamic) | Other user groups | Supported |
| Device group (static or dynamic) | Other device groups | Supported (dynamic device exclusions are only partially supported because of membership latency) |
| User group | Device group | Not supported |
| Device group | User group | Not supported. Intune doesn't evaluate user-to-device relationships, so devices of excluded users aren't excluded |
If you need to keep a user-targeted profile off certain devices, Microsoft recommends assignment filters instead of a device-group exclusion.
User scope vs device scope. Settings catalog settings tagged (User) write to HKCU and (Device) settings write to HKLM. A device-scope setting assigned to a user group applies to all users on that device once the user signs in and syncs. If a setting exists in both scopes and you assign both, user scope wins. Early in a device's life, before a user hive exists, some user-scope settings can show Not applicable. That usually clears after the user signs in and the device syncs again.
Dynamic device groups at enrollment. Membership takes processing time after the device enrolls. Policies assigned to that group aren't delivered until the device lands in it. For new devices, Microsoft suggests user groups, assignment filters, or enrollment time grouping instead.
Step 5: Read applicability (version and edition)
Microsoft: a setting shows Not Applicable on Windows when it isn't supported on the device's Windows version or edition. For example, it may exist only in newer builds, or only on Enterprise/Education.
- Look up the setting's CSP page in the Configuration service provider (CSP) reference. Each Policy CSP setting lists its Editions (Pro, Enterprise, Education, IoT Enterprise) and Applicable OS build.
- In the Settings catalog, Add settings > Add filter > OS edition shows only settings that apply to a given edition. Microsoft notes that Edge, Office, and OneDrive settings aren't filtered by edition.
- Applicability rules on a Windows profile can deliberately limit it to an OS version or edition. Read them on the profile's Properties before you assume Not applicable is a bug.
Community write-ups also report MDM log entries like "Policy is rejected by Licensing" (Result 0x82B00006) when an edition-limited setting reaches a Pro device. This isn't in Microsoft's Intune code list, so read it as "check the edition," not as a documented contract.
Step 6: Read the device's MDM event log
This is where 65000 turns into a specific answer. Microsoft documents the log at Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Read-only, on the affected device (elevated PowerShell):
$log = 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'
Get-WinEvent -FilterHashtable @{ LogName = $log; Level = 2; StartTime = (Get-Date).AddHours(-24) } -ErrorAction SilentlyContinue |
Where-Object Message -like '*CSP URI*' |
Select-Object TimeCreated, Id,
@{n='CspUri'; e={ if ($_.Message -match 'CSP URI: \((.+?)\)') { $Matches[1] } }},
@{n='Result'; e={ if ($_.Message -match 'Result: \((.+?)\)\.?\s*$') { $Matches[1] } }} |
Format-List
The failures you're looking for read like "MDM ConfigurationManager: Command failure status. … CSP URI: (./Device/Vendor/MSFT/Policy/Config/…), Result: (…)." Admins commonly see these as event ID 404. Microsoft's log article doesn't list event IDs, so filter on Level = Error and the message text rather than relying on one ID.
| What the event shows | Read it as |
|---|---|
CSP URI matches the failing setting, Result "The system cannot find the file specified." |
ADMX-backed setting with no definition on the device (Step 7) |
CSP URI starts with ./User/ but the profile only reached the device before sign-in |
User-scope timing (Step 4); recheck after the user signs in and syncs |
| Result says the setting/feature isn't supported, or a SyncML 404/406 | Wrong path for this build, or edition (Step 5) |
| No failure event for the setting, but the portal shows Error | Possibly a Get/readback mismatch or stale status. Compare the actual value (Step 7) and sync again |
Get the full picture in one file. Microsoft's MDM Diagnostic Information report is at Settings > Accounts > Access work or school > select the work account > Info > Create report > Export. It lands in C:\Users\Public\Documents\MDMDiagnostics. The same data from the command line:
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"
The zip contains MDMDiagHtmlReport.html (a snapshot of MDM configuration and policies), a registry dump of common MDM locations, and the devicemanagement-enterprise-diagnostics-provider-admin.evtx log. For corporate-owned Windows devices, you can also run Collect diagnostics from the device in the Intune admin center. It runs mdmdiagnosticstool.exe and pulls the Intune Management Extension logs, with no user interruption.
To see what the device currently holds for a Policy CSP area, many admins read HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\<Area>. Microsoft's diagnostics collection reads from this tree, but the layout isn't a documented contract, so use it to compare devices, not as proof:
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update' -ErrorAction SilentlyContinue
Step 7: Read definitions and ownership (ADMX, OMA-URI, GPO)
ADMX-backed settings. Many Settings catalog entries (Administrative Templates, Edge, Office, third-party apps) are ADMX-backed. Microsoft's ADMX docs describe two sources: inbox ADMX files that ship with Windows in %SystemRoot%\PolicyDefinitions, and ingested ADMX files sent through ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall. If the device doesn't have the definition (an older build missing a newer inbox ADMX, or an ingestion that hasn't arrived yet), the setting can't apply. That's the usual story behind "The system cannot find the file specified" in Step 6. Updating Windows, or letting the ingestion land and syncing again, is the fix. Rebuilding the profile isn't.
Two more ADMX rules from the same docs:
- Ingested (third-party/app) ADMX policies can't write to
System,Software\Microsoft, orSoftware\Policies\Microsoft, except for an allowlist (Office, Edge, OneDrive, Exchange, and a few others). A custom ADMX that targets a blocked key won't apply, however many times you push it. - Some OS components enforce their policy only on domain-joined devices, even when MDM sets it.
Custom OMA-URI. Microsoft: to work with Intune, a setting must support Add, Replace, and Get. If the value returned by Get doesn't match the value supplied by Add or Replace, Intune reports an error, even if the setting did apply. OMA-URIs are case sensitive, ./Device/ vs ./User/ has to match the CSP's scope, and the data type has to match the CSP format. For ADMX-backed policies, the value is the encoded <enabled/> / <data id=… value=…/> payload.
Group Policy on the same setting. From Microsoft's ControlPolicyConflict CSP:
| Situation | What happens |
|---|---|
Setting is in the Policy CSP with a GP equivalent, and MDMWinsOverGP = 1 |
MDM wins. GP is blocked from setting that policy |
MDMWinsOverGP not set (default 0) |
No MDM priority. GP and MDM both write |
| Setting is in another CSP (for example the Defender CSP) |
MDMWinsOverGP doesn't apply. Microsoft calls it a race condition with no guarantee which one wins |
Microsoft's recommendation is plain: don't configure the same setting in both GPO and MDM unless MDMWinsOverGP covers it. The MDM Diagnostic report lists GP settings that were blocked because an MDM equivalent is set. A value that flips back after gpupdate /force (read with gpresult /h report.html, which only reads) is the giveaway.
Timing: when "Pending" or a stale Error is just waiting
From Microsoft's policy refresh guidance:
| Event | Microsoft's timing |
|---|---|
| Profile assigned/updated/deleted, or group membership changes | Change-based notification: immediately up to a few hours (online devices) |
| Regular maintenance sync | About every 8 hours, and no more than one maintenance sync every 6.5 hours |
| Newly enrolled Windows device | Every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then about every 8 hours |
| Device assignment status report | Can take 24–48 hours to reflect recent assignment or group changes |
| User removed from a targeted user group | Removal of settings can take up to 7 hours or more |
| Last check-in older than 24 hours | Microsoft's troubleshooting guide flags this as a likely device issue (not a profile issue) |
To force a check-in on Windows: Settings > Accounts > Access work or school > the account > Info > Sync, or Sync from the device in the admin center.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Conflict between two configuration policies | Pick one owner for the setting and remove it from the other policy (or align the values) | Assigning a third policy to "override" |
| Baseline vs Settings catalog on one setting | Decide which one owns that area. Keep the setting in only one place | Excluding the device from the baseline entirely to clear one row |
| User-group include + device-group exclude | Use an assignment filter on the user-group assignment | Expecting the device exclusion to work |
| Not applicable on Pro for an Enterprise-only setting | Applicability rule or filter by edition, or move the setting to a supported path | Recording it as a delivery failure |
| ADMX "cannot find the file specified" | Update Windows / wait for the ingestion, then sync | Deleting and recreating the profile |
| Custom OMA-URI Error, value actually set | Check whether the CSP's Get returns the same value; prefer the Settings catalog entry if one exists | Endless re-pushes of the same OMA-URI |
| GPO and Intune both set it | Remove it from one side, or set MDMWinsOverGP deliberately where it applies (Policy CSP only) |
Leaving both and hoping MDM wins |
| Password policy -2016281112 | Have the user change their password; pair with a compliance policy | Retiring the device |
| Profile removed but setting still there | Expect CSP-dependent "tattooing": some CSPs keep the value after removal. Set the intended value explicitly | Assuming unassign = revert |
FAQ
What does Intune error 65000 mean on a configuration profile?
It's a generic failure. 65000 is the low 16 bits (0xFDE8) of 0x87D1FDE8, which Microsoft lists as "Remediation failed". The device was asked to set a value and didn't end up with it. Microsoft doesn't list 65000 by itself, so find the setting in Per setting status, then read the device's DeviceManagement-Enterprise-Diagnostics-Provider/Admin log for the CSP URI and Result.
How do I find which policy is causing an Intune configuration conflict?
Open Devices > All devices > the device > Device configuration > the profile, and select the Conflict row. Intune lists every policy and profile that contains the conflicting setting. Remember that endpoint security, security baselines, and Group Policy analytics imports are configuration policies too.
Which wins in Intune: a compliance policy or a configuration profile?
Compliance policy settings always take precedence over the same setting in a configuration profile. Two compliance policies resolve to the most restrictive value. Two configuration profiles with different values show Conflict, and you resolve that manually.
Why does my configuration profile show Not applicable?
On Windows, the setting usually isn't supported on that OS version or edition. Check the CSP reference page for the setting's editions and build, and read the profile's applicability rules. User-scope settings can also show Not applicable before a user signs in.
Does Intune override Group Policy?
Only for Policy CSP settings with a GP equivalent, and only when MDMWinsOverGP is set to 1. For settings in other CSPs, Microsoft says GPO and MDM race with no guaranteed winner. Don't configure the same setting in both.
Related posts
- Company Portal can't connect / device not syncing: a 10-minute triage order
- Intune Wi-Fi Profile Not Applying: A Read-First Assignment and EAP Triage
- Windows Hello for Business Provisioning Will Not Be Launched: A Read-First NGC and Intune Policy Triage
- Intune Remediation Script Not Running: A Read-First Exit Code, Context, and HealthScripts.log Triage (a different feature from the "Remediation failed" status in this post)
Free checklist
Configuration profiles are usually what makes a device compliant before you require a compliant device in Conditional Access. A baseline conflict that quietly breaks a BitLocker or Defender setting turns into a Monday lockout once that grant is enforced. The free Conditional Access pre-enforcement checklist keeps break-glass, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=intune-configuration-profile-error-65000-conflict
Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 only read (the Graph calls are GET-only; mdmdiagnosticstool and gpresult only collect) until you deliberately change a policy, assignment, filter, or GPO. Pilot conflict fixes and ownership changes on a small device group first, and check current Microsoft docs for CSP editions, conflict handling, and policy refresh timing.
Top comments (0)