Configuration Profile Failures — Day 4 of the Microsoft Intune Real-Time Troubleshooting Series

Day 4 of the Microsoft Intune Real-Time Troubleshooting Series

Welcome to Day 4 of the Microsoft Intune Real-Time Troubleshooting Series — 15 days, 15 real-world scenarios, 15 practical solutions.

Day 1 was a device that would not enroll; Day 2, a user locked out of the Company Portal; Day 3, a device judged noncompliant. Today the device is enrolled, signed in, and compliant — and still the settings Intune is supposed to push are not landing. The profile says Error. Or Conflict. Or it has said Pending since yesterday. Nobody changed the device. Somebody changed a policy.

A configuration profile is a promise: Intune sends a setting, the device applies it, the device reports back. When that chain breaks, the admin center shows a status, not a reason. This episode reads past the status to the one setting that failed, and the one cause behind it.

1. Real-World Scenario

It is Monday morning, and the security team has shipped a new baseline. One Settings Catalog profile, WIN-Baseline-2026-11, assigned to every Windows device in the company: minimum password length 12 characters, removable USB storage blocked, Windows Hello for Business required, and a new ADMX-backed setting that turns off the Microsoft Store on shared machines.

By 9 a.m. the admin center tells a confusing story: roughly 300 devices show Error (0x87D1FDE8), about 40 show Conflict, a handful show Not applicable, and a long tail has shown Pending since Friday.

The tickets disagree: some users can still use USB drives, others cannot sign in with Windows Hello, and a few report nothing at all.

Nobody can say yet whether the baseline is broken, the assignment is wrong, or the devices are at fault.

2. Root Cause Analysis

A profile failure has a short list of causes, and they fail in a predictable order of likelihood. Work through them in this sequence before touching the device.

1. One bad setting poisons the whole profile. The most common cause, and the one admins miss most often. Intune reports status per profile, but a profile fails per setting: one setting the device cannot apply turns the whole profile red. Here, the ADMX-backed Store setting is the poison: it fails everywhere.

2. Two profiles set the same setting to different values. The old template profile WIN-Legacy-Restrictions is still assigned, and it sets minimum password length to 8. The new baseline sets it to 12. Intune picks no winner: the device reports Conflict, and neither value is applied. The 40 Conflict devices are the ones that received both profiles. Resolve it manually — remove the setting from one profile, or change the assignments so the two never meet on the same device.

3. Group Policy is fighting Intune over the same setting. On hybrid-joined devices, the same password-length setting also exists in a Group Policy Object. Unless the Policy CSP setting MDMWinsOverGP is configured, MDM and Group Policy race over the setting, and the losing side reports 0x87D1FDEE (-2016281106) — “Not applicable because it lost in conflict resolution.”

4. The profile is assigned to the wrong audience. The baseline is assigned to a user group, but its settings are device settings. Shared and kiosk devices, where no targeted user is signed in, never receive user-targeted settings at all. And an assignment filter written for the pilot fleet may never have been widened. When the profile never arrives, the device shows Pending forever — not because it is broken, but because it was never in the audience.

5. The setting does not apply to this device. Not applicable means the device cannot receive the setting: a setting that needs Windows 11 24H2 on a device still running 23H2, or an Enterprise-only setting on a Windows 11 Pro machine. Here, the handful of Not applicable devices are the older laptops the Store setting was never written for. That status is information, not a failure.

6. An ADMX-backed setting fails because the definition is not on the device. Settings Catalog settings backed by ADMX need the ADMX definition present on the device. When it is not, the setting fails with a result like “The system cannot find the file specified” — the device was asked to set a value it has no definition for. Ingest the ADMX, or use the Settings Catalog equivalent.

7. A custom OMA-URI has a typo. Custom profiles address settings by their OMA-URI path, and a wrong path fails with a SyncML status code: 404 means the CSP node was not found, 405 means the node is read-only, 418 means the node already exists. Intune surfaces these as 0x87D10000 plus the SyncML code — so a 404 arrives as 0x87D10194 (-2016345708).

8. The device has not checked in. Devices check in with Intune roughly every 8 hours. A device that is off, offline, or has a stale last check-in simply has not received the profile yet, and Pending is the honest status for that. Check the last check-in time first.

9. A prerequisite the profile assumes is not there. A Wi-Fi profile fails with 0x87D1FDE8 on a device with no Wi-Fi card. And some errors are false alarms: the local-admin password node (./Device/Vendor/MSFT/Accounts/Users/LAPSAdmin/Password) reports 0x87D1FDE8 even when the password was actually set — check whether the setting took effect before treating the code as a failure.

3. Step-by-Step Troubleshooting

Work in this order: read the status at the right level of detail, find the one failing setting, then fix that cause — not the whole profile.

1. Read the exact status and error code in the admin center. Open the profile (Devices > Manage devices > Configuration), select it, and look at Device and user check-in status. Note the status — Succeeded, Error, Conflict, Pending, Not applicable — and the error code on the Error devices. 0x87D1FDE8 (-2016281112, “Remediation failed”) is a generic code: it says the device was asked to set a value and did not end up with it. The code 65000 sometimes seen in the portal is the same signal — the low 16 bits of 0xFDE8.

2. Open the per-setting status report. From the same profile view, select Per setting status: it shows each setting in the profile and how many devices report Success, Error, or Conflict on that setting. Here, three settings are green everywhere and the Store setting is red everywhere.

3. Check the device’s own view. Compare one failing device with one succeeding device. Go to Devices > All devices, open the device, and select Device configuration: every profile on the device is listed with its status, and a device in Conflict shows you the other policies that contain the conflicting setting.

4. Use the built-in Troubleshoot pane. In Troubleshooting + support > Troubleshoot, select the user and the device, with assignments set to Configuration profiles. It shows whether the user is in the assigned groups, whether the profile reached the device, and when the device last checked in. If the profile never arrived, you learn it here.

5. Read the device’s MDM log. On the device, open Event Viewer and go to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Filter for “Command failure status” events: they name the exact CSP URI that failed and the result that came back. A 404 result points at a wrong OMA-URI (cause 7); “The system cannot find the file specified” points at a missing ADMX definition (cause 6).

6. Check what actually landed in the registry. The applied policy values live under HKLM\SOFTWARE\Microsoft\PolicyManager\current\device, one area per setting family. If the password length reads 8, the legacy profile won; if the Store setting is absent, the ADMX-backed setting never applied. The registry is the ground truth.

7. Hunt the conflicting profile. On a Conflict device, the device configuration view lists every policy containing the conflicting setting. Open the legacy profile, confirm the 8, and decide: retire it, or remove that one setting. Do not edit the baseline to match the legacy value.

8. Check for the Group Policy overlap. On a hybrid-joined device showing 0x87D1FDEE, run gpresult /r and look for a GPO setting the same value. If one exists, remove the setting from the GPO, or set MDMWinsOverGP so Intune wins the race deliberately.

9. Verify assignment and filters. Confirm the target groups contain the failing devices — and check the assignment filters. A filter that excludes by OS version or device model will silently hold the profile back from exactly the machines in the tickets. User-targeted settings need a signed-in targeted user; device-targeted settings apply to the device itself.

10. Force a sync and watch the status change. On the device, go to Settings > Accounts > Access work or school > Info and select Sync, then watch the profile status in the admin center. A flip to Succeeded means it was just between check-ins.

11. Collect the MDM diagnostic bundle if the cause is still unclear. From an elevated prompt, run mdmdiagnosticstool.exe, or use Settings > Accounts > Access work or school > Info > Create report. The bundle’s MDMDiagHtmlReport.html is a readable snapshot of the management URLs, certificates, and policies on the device.

4. PowerShell Commands

Each of these is a real command an admin runs on the device or against the tenant. Run the device-side ones in an elevated prompt where noted.

# Find profile failures in the MDM event log (look for "Command failure status" events)
Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 100 |
    Where-Object { $_.Message -like '*Command failure*' } |
    Select-Object TimeCreated, Id, Message

# Confirm the device is enrolled and holds a valid MDM configuration
dsregcmd /status

# Collect a full MDM diagnostic bundle
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Temp\MDMDiag.zip"

# List the policy areas that actually landed on the device
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device' | Select-Object Name

# Check whether the MDM sync scheduled task exists and last ran
Get-ScheduledTask -TaskPath '\Microsoft\Windows\EnterpriseMgmt\' | Select-Object TaskName, State, LastRunTime, LastTaskResult

# Check for a Group Policy setting the same value (run on a hybrid-joined device showing 0x87D1FDEE)
gpresult /r /scope computer

# From the admin side: find the baseline profile and confirm its version
Connect-MgGraph -Scopes 'DeviceManagementConfiguration.Read.All'
Get-MgDeviceManagementDeviceConfiguration -All |
    Where-Object { $_.DisplayName -like '*Baseline*' } |
    Select-Object DisplayName, Version, LastModifiedDateTime

# From the admin side: list the devices reporting Error on that profile
$profileId = '<profile-id-from-the-previous-command>'
Invoke-MgGraphRequest -Method GET -Uri "deviceManagement/deviceConfigurations/$profileId/deviceStatuses" |
    Select-Object -ExpandProperty value |
    Where-Object { $_.status -eq 'error' } |
    Select-Object deviceDisplayName, userPrincipalName, status, errorCode

# From the admin side: force a sync on one device, then check its last check-in time
$deviceId = '<managed-device-id>'
Invoke-MgGraphRequest -Method POST -Uri "deviceManagement/managedDevices/$deviceId/sync"
Get-MgDeviceManagementManagedDevice -ManagedDeviceId $deviceId |
    Select-Object DeviceName, LastSyncDateTime, ComplianceState

5. Important Log Locations

Location	What it tells you
Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin	The profile log. “Command failure status” events name the exact CSP URI that failed and the result — a 404 means a wrong OMA-URI, “The system cannot find the file specified” means a missing ADMX definition. Enable the Debug channel when the Admin channel is not detailed enough.
C:\Users\Public\Documents\MDMDiagnostics	Output of mdmdiagnosticstool.exe and the Settings > Create report bundle, including MDMDiagHtmlReport.html — the readable snapshot of management URLs, certificates, and policies.
HKLM\SOFTWARE\Microsoft\PolicyManager\current\device	The applied policy values, one area per setting family. The ground truth about what the device believes — check here when the portal and the device disagree.
HKLM\SOFTWARE\Microsoft\PolicyManager\Providers	One subkey per MDM provider enrolled on the device. A stale provider here is the registry evidence behind a profile that applies to a management relationship that no longer exists.
%ProgramData%\Microsoft\IntuneManagementExtension\Logs	Intune Management Extension logs (IntuneManagementExtension.log). These cover Win32 apps and PowerShell scripts — not configuration profiles. If you are reading this log for a profile failure, you are in the wrong log.
Task Scheduler > Microsoft > Windows > EnterpriseMgmt	The MDM sync task. Its last run time tells you whether the device has checked in recently enough to have received the profile.

6. Practical Resolution

Back to the 300 Error devices, the 40 Conflict devices, and the Pending tail: three separate causes wearing one symptom.

Per-setting status shows the Store setting red on every Error device, and the device log shows “The system cannot find the file specified”: the ADMX definition was never ingested. The fix: replace that setting with the Settings Catalog equivalent, which needs no definition file, and keep ADMX-backed settings out of broad baselines until ingestion is verified on a pilot ring.

The 40 Conflict devices all still have the legacy template profile assigned, setting minimum password length to 8 against the baseline’s 12. The fix is to retire WIN-Legacy-Restrictions entirely — it was superseded by the baseline, and nothing else in it is still needed. Retiring it clears the Conflict on the next check-in, and the baseline’s 12 applies.

The Pending tail is simplest: those devices have not checked in since Friday. A manual sync from Settings > Access work or school > Info > Sync flips them to Succeeded within minutes.

The fix, in order:

1. Replace the ADMX-backed Store setting with the Settings Catalog equivalent, verified on a pilot group first.
2. Retire the legacy template profile and confirm the Conflict count drops to zero.
3. On the Pending devices, trigger a manual sync and confirm the profile flips to Succeeded.
4. Confirm the Not applicable devices are the older laptops the setting was never written for, and record that as expected.
5. Add a pre-flight step to the runbook: check per-setting status on the pilot ring before any baseline ships fleet-wide, and confirm no legacy profile or GPO sets the same setting. The baseline was fine. The rollout skipped the check that would have caught the one bad setting before it reached 300 machines.

7. Interview Questions

Q1: A configuration profile shows Error with code 0x87D1FDE8. What does that code mean, and where do you look next?

0x87D1FDE8 (-2016281112) means “Remediation failed” — the device was asked to set a value and did not end up with it. It is a generic code. Next, open the profile’s Per setting status report to find which setting failed, then read the device’s MDM log (DeviceManagement-Enterprise-Diagnostics-Provider > Admin) for the “Command failure status” event, which names the exact CSP URI and the result.

Q2: What is the difference between Error, Conflict, Pending, and Not applicable on a configuration profile?

Error means the profile failed to apply. Conflict means two settings are applied to the same device and Intune cannot sort it out — an administrator has to review and resolve it. Pending means the device has not checked in with Intune to receive the policy yet. Not applicable means the device cannot receive the policy — for example, a setting needing a newer Windows version or edition.

Q3: Two configuration profiles set the same setting to different values. What happens, and how do you fix it?

The device reports Conflict, and Intune applies neither value — it does not pick a winner between two configuration profiles. Fix it by removing the setting from one of the profiles, or by changing the assignments so the two profiles never meet on the same device. Exception: compliance policy settings always beat configuration profile settings.

Q4: Group Policy and Intune both set the same setting on a hybrid-joined device. Who wins?

By default, neither wins cleanly — they race, and the losing side reports 0x87D1FDEE, “Not applicable because it lost in conflict resolution.” The deliberate fix is the Policy CSP setting MDMWinsOverGP (./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP), which makes MDM win. The cleaner fix is usually to remove the setting from the GPO once Intune owns it.

Q5: A profile shows Error on 300 devices. How do you find which setting failed without opening 300 devices?

Open the profile in the admin center and select Per setting status. It shows every setting in the profile with the count of devices reporting Success, Error, or Conflict on that setting. One red setting among green ones is the diagnosis. Then confirm it on one failing device via its Device configuration view and the MDM event log.

Q6: A custom OMA-URI profile fails and the device log shows a SyncML 404. What does that mean?

The CSP node was not found — the OMA-URI path is wrong, usually a typo in the path or a node that does not exist on that Windows version. Intune surfaces SyncML codes as 0x87D10000 plus the code, so a 404 arrives as 0x87D10194. Fix the URI. A 405 means read-only; a 418 means it already exists.

---

Day 4 done. Tomorrow, Day 5: Win32 Application Installation Issues — when the app package reaches the device and the install itself refuses to run.

Follow the series here on ongoingideas.com — one scenario a day, for 15 days.

Missed the start of the series? Begin with Day 1: Windows Device Not Enrolling into Intune, then Day 2: Company Portal Login Failures, then Day 3: Device Compliance Issues.