Intune policy conflicts, and how to find which policy won

Administrators arriving from Group Policy bring an assumption with them: that when two policies disagree, one of them wins according to a precedence rule. Group Policy has such a rule, as described in Group Policy processing order.

Intune does not. When two policies assigned to the same device configure the same setting to different values, Intune does not attempt to resolve it. The setting reports a conflict and neither value is applied. There is no most-restrictive-wins, no last-writer-wins, and no link order.

This single fact explains most of what confuses people about Intune configuration.

The symptom

• A setting is not applying, and the profile shows as succeeded overall.
• A device reports “Conflict” in the profile status, with no obvious indication of which profile is responsible.
• A setting applies to some devices and not others, where the difference is group membership.
• A newly created profile appears to have broken a setting that was working.

That last one is the classic. Someone creates a new profile for a new requirement, includes a setting that an existing profile already configures with a different value, and the setting that was working stops working for everyone in both assignments.

The architecture: where a setting can come from

Before diagnosing, know the sources. A Windows device can receive the same setting from:

• An Intune configuration profile, from the settings catalog or a template.
• A security baseline, which is a large collection of settings and a frequent source of unexpected conflicts.
• Endpoint security policies — antivirus, firewall, attack surface reduction.
• Group Policy, if the device is also domain-joined.
• Configuration Manager, if the device is co-managed and the workload has not moved.
• A local setting or a previously applied policy that Intune cannot override.

The last three are the sources people forget, and they produce the most puzzling results — particularly a co-managed device where Intune has a policy but Configuration Manager is still the authority for that workload, as covered in co-management workloads.

Note also that “Conflict” has a second meaning: an existing setting on the device that Intune cannot override. That is not two Intune policies disagreeing; it is Intune being unable to take control of a setting. The remedy is different, so establish which one you have.

Diagnosis

1. Get the per-setting status, not the profile status

The profile-level status tells you almost nothing, because a profile can report success while individual settings conflict. Go to the device or the profile and read the per-setting status. That is where the conflict is named.

In the Intune admin centre, the report under Devices, then Monitor, for configuration policy assignment failures, lists conflicts with the profiles involved. This is the fastest route to “which two policies are fighting”, and it is the report most people do not know exists.

2. Establish what is actually assigned to the device

List every profile, baseline and endpoint security policy assigned to the device and to its user. Include assignments inherited through group membership, and check both include and exclude assignments — an exclusion that was supposed to prevent overlap is frequently mis-scoped.

This step is tedious and it is where the answer usually is.

3. Collect diagnostics from the device itself

For a Windows device, the built-in diagnostic collection gathers the MDM state, the policies received and the enrolment detail into a single archive:

# Run elevated on the affected device.
MdmDiagnosticsTool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" `
    -cab C:\Temp\mdm-diagnostics.cab

Intune can also collect diagnostics remotely from a managed device, which is usually easier than asking a user to run a command.

The device’s own view of what it received is the authoritative answer to “what did this device actually get”, and it settles arguments that the console cannot.

4. Read the MDM event log

Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' `
    -MaxEvents 60 |
    Where-Object { $_.LevelDisplayName -in 'Error', 'Warning' } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

This shows the policy application attempts and their results, including failures that the console summarises less helpfully.

Interpretation

Two Intune policies, same setting, different values. The common case. Neither applies. Decide which value is correct and remove the setting from the other policy — do not create a third policy to override, because there is nothing to override with.

A security baseline conflicting with a configuration profile. Very common, because baselines configure hundreds of settings and nobody reads all of them. If you deploy a baseline, treat it as owning its settings and avoid configuring the same ones elsewhere.

A setting Intune cannot override. The device has the setting configured by something outside Intune’s control — Group Policy on a hybrid-joined device, or a legacy local policy. For hybrid devices, the MDM-wins-over-Group-Policy behaviour is configurable, and where it is not enabled, Group Policy continues to take precedence for conflicting settings.

The device is co-managed and the workload is still with Configuration Manager. Intune’s policy is assigned, Configuration Manager is the authority, and Intune’s setting does not apply. This is working as designed and looks exactly like a fault.

The user-versus-device distinction. Some settings are per-user and some per-device. Assigning a device-scoped setting to a user group, or the reverse, produces a policy that never applies to anything and reports little about why.

Resolution: the structural fix

Fixing an individual conflict is straightforward: remove the setting from one of the two policies. Preventing the next one is a design question, and it is worth doing properly because this problem compounds.

One setting, one policy. Adopt it as a rule. Every setting should be configured in exactly one place across your whole Intune configuration. This is the entire prevention.

Organise profiles by function, not by audience. A profile per functional area — browser settings, BitLocker, Windows Update — assigned to different groups, rather than a profile per department containing overlapping settings. Department profiles guarantee overlap.

Use exclusions deliberately where two audiences genuinely need different values, so no device is in scope for both.

Keep a register of which policy owns which setting. For an estate of any size this is the document that prevents the problem. A spreadsheet is sufficient; the discipline is what matters.

Do not create a policy to fix a conflict. It does not work and it adds a third participant to the argument.

Validation

• Re-check the per-setting status on an affected device after the change. The conflict should clear and the setting should report success with the intended value.
• Confirm the value on the device itself — the registry, or the feature’s own interface — rather than trusting the console alone.
• Check a device from each assignment group, not just the one you were debugging.
• Force a sync from the device and wait for a full cycle rather than concluding from an immediate check.

Operations

Review before assigning. When creating a profile, check whether its settings are already configured elsewhere. The settings catalog makes it easy to add a setting and hard to notice that another profile already has it.

Watch the conflict report rather than waiting for a user to notice. Conflicts are visible in the console before anyone raises a ticket.

Be cautious with baselines. They are valuable and they are large. Deploy one, understand what it configures, and then build around it rather than alongside it.

Verification and limits

That Intune does not arbitrate policy conflicts and applies neither value, the two meanings of the conflict state, the assignment failure reporting location, MdmDiagnosticsTool.exe usage and the MDM diagnostics event log were checked against current Microsoft documentation on 20 September 2026. The structural recommendations are my own practice.

No tenant or device was configured for this article. The diagnostic commands are read-only. Removing a setting from a policy changes configuration on every device in its assignment — confirm the assignment scope before editing, and change one policy at a time so the effect is attributable. Reporting surfaces in the Intune admin centre move; confirm the current location of the per-setting status view.

References

• Troubleshoot policies and profiles in Microsoft Intune
• Common questions with policies and profiles in Microsoft Intune
• Avoid policy conflicts
• Collect diagnostics from a Windows device