When a profile reports Conflict, Intune is telling you that two policies want different values for the same setting and that it won't pick a winner. In this post I'll show how to find every policy involved, confirm what actually reached the device with the MDM diagnostic report and event log, rule out Group Policy, and clean up so the conflict stays gone.
Symptoms#
- A profile's Device and user check-in status shows devices in Conflict, and Per setting status flags one or more settings.
- In Devices › All devices, the device's Device configuration list shows a profile in Conflict.
- A setting doesn't take effect, or behaves differently on devices that should be identical.
Why it happens#
A conflict means policies assigned to the same device or user set one setting to different values. Between two configuration policies, Intune reports the conflict and leaves the decision to you; depending on timing, the device may keep its previous value or receive neither. Compliance policies behave differently: their settings take precedence over configuration settings, and between compliance policies the most restrictive value applies.
Conflicts are easy to create because the same setting can live in several places:
| Area | Where it's often configured twice |
|---|---|
| BitLocker | Endpoint security disk encryption, the Endpoint protection template, security baselines, settings catalog |
| Microsoft Defender Antivirus | Endpoint security antivirus, security baselines, the Device restrictions template, settings catalog |
| Windows Update | Update rings and Windows Update settings in the settings catalog |
| Anything with a GPO equivalent | An Intune policy plus a Group Policy Object on hybrid joined devices |
Group Policy adds another twist: Intune also reports Conflict when an existing value on the device can't be overridden, and some GPO overlaps never show up in Intune at all.
How to fix it#
1. Find every policy that sets the value#
Open the profile and select Per setting status to see which setting is in conflict. Then open the device, select Device configuration, pick the profile in Conflict and select the setting; when both policies come from Intune, the details show which profiles configure it. Check endpoint security policies, security baselines and custom OMA-URI profiles too, since they're easy to forget.
2. See what the device actually received#
On the device, go to Settings › Accounts › Access work or school, select the work account, then Info. At the bottom, under the advanced diagnostic report, select Create report and then Export. The report lands in C:\Users\Public\Documents\MDMDiagnostics. To collect it from the command line or a script, run this from an elevated prompt:
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"The zip contains MDMDiagHtmlReport.html (a summary of MDM configuration and policies), MDMDiagReport.xml (more detail), a dump of MDM registry keys and the relevant event logs. In the HTML report, find the policy area and compare the current value with the one you intended. The report also shows the device's configuration sources and, if you use MDMWinsOverGP, the Group Policy settings that were blocked because an MDM equivalent exists. For a quick look without the report, the effective MDM values are under HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\<Area>.
3. Read the MDM Admin event log#
Errors applying a policy appear in Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin, and they include the CSP path of the failing setting. This pulls the recent errors and warnings for one area:
$area = 'BitLocker'
Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 300 |
Where-Object { $_.Level -in 1, 2, 3 -and $_.Message -like "*$area*" } |
Format-List TimeCreated, Id, MessageFor more detail, enable Show Analytic and Debug Logs in Event Viewer's View menu and turn on the Debug channel next to Admin.
4. Rule out Group Policy#
On hybrid joined devices, run gpresult /h gpresult.html and search for the same setting. You can make MDM win by setting ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP to 1, but know its limits:
- It only covers Policy CSP settings that have a Group Policy equivalent. Settings in other CSPs, such as the Defender CSP, aren't covered.
- Microsoft's Intune guidance notes it doesn't apply to the Update policy CSP used for Windows updates.
- Outside its scope, setting the same value through GPO and MDM is a race with no guaranteed winner.
The cleanest fix is removing the setting from the GPO, or filtering that GPO away from Intune-managed devices.
5. Give each setting one owner#
- Decide which policy owns the setting. A practical rule: endpoint security profiles own their workloads, a baseline covers the broad defaults, and the settings catalog fills gaps.
- In every other policy, set it to Not configured or remove it from the settings catalog profile. If two groups genuinely need different values, separate them with exclusions or assignment filters.
- Remember tattooing: removing a setting doesn't always revert the device, because some CSPs keep the last value. If the old value sticks, deploy the value you want explicitly.
Watch out: Don't resolve a conflict by deleting the stricter policy just to make the status green. Check which value your security standard requires first.
Verify the fix#
- Sync the device from Access work or school › Info › Sync or with the Sync device action.
- Per setting status shows Succeeded for the setting, and the device lists the profile as Succeeded.
- A fresh MDM diagnostic report shows the intended value, and the Admin log has no new errors for that area.
- Be patient with the Device assignment status report, which can take 24 to 48 hours to reflect assignment changes in large tenants.
Prevent it next time#
- Keep a short ownership list: which policy type manages BitLocker, Defender, firewall, updates and so on.
- Before creating a policy, search the settings catalog and existing endpoint security profiles and baselines for the same settings.
- When moving from GPOs to Intune, use Group Policy analytics and remove each setting from the GPO once Intune owns it.
- Pilot new policies on a small group and check Per setting status before assigning broadly.