Setup guide · from scratch
Monitor for and resolve Intune policy conflicts
When two profiles set the same setting differently, Intune applies NEITHER and it silently reverts to default. Find clashes in the assignment-failure report and remove the overlap, exclude a group, or use an assignment filter.
≈ 20 min
Across every platform · step 1 of 2 · ≈ 20 minNext ›
Do these first — this guide assumes you already have:
The Decolla way — skip the clicks.
Every step below can be done by hand. Or connect your Microsoft tenant to Decolla once, and Decolla performs this for you over Microsoft Graph in your own tenant — then hands back a verified result you can see and roll back per item. It also puts the fundamentals this step depends on in place — the target group, the licence allocation — so a build is never blocked half-way by a missing dependency.
⏱ By hand: about 20 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Before you start
- An Intune role that can edit policies (Intune Administrator or Policy and Profile Manager), not a read-only viewer account.
- A decision, per contested setting, on which policy is the authoritative owner — so you know which one to change.
- The names of the device groups your policies target, plus any assignment filter you plan to use to separate them.
- At least one affected device you can force a sync on, to verify the fix quickly.
The steps
- Sign in to https://intune.microsoft.com as the Example Company Intune admin.
- Click Devices > Monitor.
- Open the 'Configuration policy assignment failure' report; the Conflict column…
- Click a policy row with a non-zero conflict, then a device, to see the exact…
- Fix in Devices > Configuration: open ONE policy and either remove the overlapping…
- Check ALL blades (Configuration, Endpoint security, Security baselines, Group…
- After the next device check-in (up to ~8h, or force a sync) confirm the conflict…
0 of 7 done
Step 1. Sign in to https://intune.microsoft.com as the Example Company Intune admin.
Screenshot: Intune signed in (captured during a live customer build — coming to this page)
Why: The Monitor reports are read-only, but the fix in step 5 edits a live policy — sign in with a role that can write, not a viewer-only account.
Step 2. Click Devices > Monitor.
Screenshot: Devices > Monitor menu (captured during a live customer build — coming to this page)
Watch for: Conflicts surface under Devices > Monitor, NOT the top-level Reports blade in the left-hand nav — a common wrong turn.
Step 3. Open the 'Configuration policy assignment failure' report; the Conflict column counts clashing devices per policy.
Screenshot: Assignment-failure report with the Conflict column (captured during a live customer build — coming to this page)
Why: This report is the one place that aggregates conflicts across every device, so you can spot a clashing policy at a glance rather than device by device.
Watch for: Read the Conflict column, not Error — a conflict means two policies are fighting over one setting, a different problem from a policy that simply failed to deliver.
Step 4. Click a policy row with a non-zero conflict, then a device, to see the exact conflicting setting and the other policy that set it.
Screenshot: Per-device drill-down naming the setting + both policies (captured during a live customer build — coming to this page)
Why: The per-device drill-down names both the setting and the second policy — you cannot resolve a conflict without knowing which two policies are clashing.
Watch for: One setting can clash with more than one other policy; note every partner named, not just the first.
Step 5. Fix in Devices > Configuration: open ONE policy and either remove the overlapping setting, add the other group to Excluded groups, or replace the include with a broad group + assignment filter; Save.
Screenshot: Policy Assignments tab after adding an Excluded group / filter (captured during a live customer build — coming to this page)
Why: The aim is to leave exactly one policy setting that value on any given device; while two do, Intune applies neither and it reverts to default.
Watch for: Excluding a group only separates the policies if the device is genuinely in that group — where both target overlapping dynamic groups or All Devices, exclusion won't help and you need the filter or to consolidate the setting.
Don’t: Do NOT delete the whole policy to clear one clash — remove or reassign just the overlapping setting; the rest of that profile may still be doing useful work.
If this step errors: Intune policies taking 8 hours? Check WNS first
If this step errors: OEMConfig shows success in Intune but setting not applied
Step 6. Check ALL blades (Configuration, Endpoint security, Security baselines, Group Policy analytics), not just Configuration.
Screenshot: The multiple policy blades being checked (captured during a live customer build — coming to this page)
Why: The same setting can be defined in more than one product area, so a Configuration profile can clash with a Security baseline or Endpoint security policy — the conflict often spans blades.
Watch for: Security baselines are the usual hidden culprit: they set dozens of values you didn't hand-pick, so one can clash with a profile you assumed was standalone.
Don’t: Don't stop once Configuration reads 0 — the clashing partner may live in Endpoint security, a baseline, or Group Policy analytics.
Step 7. After the next device check-in (up to ~8h, or force a sync) confirm the conflict count is now 0.
Screenshot: Report showing 0 conflicts (captured during a live customer build — coming to this page)
Why: The report reflects each device's last check-in, not the moment you saved, so the count won't move until devices actually re-evaluate.
Watch for: The '~8h' figure is the outer bound, not a fixed timer — a manual sync is far quicker for verification.
Don’t: Don't conclude the fix failed if the count is still non-zero a few minutes after saving; force a sync on one device and re-check first.
If it goes wrong
The failures people actually hit on this process, each with the diagnosis and fix:
- Intune policies taking 8 hours? Check WNS first — Intune delivers policy changes in minutes via WNS; the 8-hour sync is only a safety net. If WNS is blocked at the firewall, here's how to fix it.
- OEMConfig shows success in Intune but setting not applied — Intune reports a Knox Service Plugin OEMConfig profile as succeeded, yet the device ignores it. Why "applied" only means delivered, and how to verify.
- Intune registry detection rule not working: 32/64-bit fix — Intune marks a Win32 app failed though it installed fine? Two silent detection-rule killers — WOW6432Node redirection and HKCU:\ syntax — and the fix.
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access