Intune Baseline Conflict Fixes

Intune conflicts usually start with good intentions. One team deploys a baseline, another adds a settings catalog profile for a gap, then someone drops in an endpoint security policy because it looks cleaner in the portal. A few weeks later the device is arguing with itself.

That is why "policy sprawl" matters more than people expect. The admin center can make the tenant look busy and well protected, while the real device is stuck in conflict, error, or partial state.

These fixes are rarely about adding another profile. They are usually about choosing one policy home for each control area, then retiring the duplicates with a bit of discipline.

Where conflicts usually come from

The same setting can show up in several places:

Control area	Common places it appears
BitLocker	Disk encryption policy, settings catalog, security baseline
Defender Antivirus	Endpoint security, security baseline, local Defender tooling
Firewall	Endpoint security, settings catalog, old GPO carry-over
Local admin membership	Account protection, settings catalog, scripts, legacy build steps
ASR rules	Endpoint security, baseline, custom OMA-URI or older templates
Windows hardening	Settings catalog, baseline, template profiles

The trouble is not that Intune gives you options. The trouble is that tenants often use all of them at once.

What a sane ownership model looks like

You want one main owner per control family:

Control family	Best default home	Why
Defender AV, firewall, disk encryption	Endpoint security	Security teams can review and report in one place
Local users, local groups, Windows LAPS direction	Account protection	It is built for identity and local group control
Broad Windows configuration	Settings catalog	Best coverage and per-setting reporting
Compliance decisions	Compliance policies	Keep access decisions separate from hardening
Update rings and feature rollout	Windows update policies	Easier servicing logic and reporting

That does not mean "never break the rule". It means break it deliberately, document it, and know why.

A better cleanup order

1. Export current Intune policies.
2. Group settings by control family, not by team name.
3. Flag duplicate settings and any place where values disagree.
4. Decide the long-term owner for each family.
5. Pilot the new layout with a small device group.
6. Use per-setting status and device reports to confirm the result.
7. Remove the old assignment only when the replacement is stable.
8. Record the rule in plain English so the next admin does not recreate the mess.

Baselines help, but they are not the operating model

Microsoft's security baselines are useful for getting to a recommended posture faster. They are not a substitute for clear ownership. Once the baseline is in place, you still need to decide what stays in the baseline and what moves into a more explicit endpoint security or settings catalog design.

This matters even more in older tenants. Many of the ugliest conflicts come from "temporary" profiles that stayed around for a year.

What to check before you blame Intune

Before you call it a platform problem, check four things:

1. Is the same setting configured in more than one place?
2. Is the policy assigned to both users and devices in an awkward mix?
3. Is there old group policy still landing on the machine?
4. Does the conflict show up in per-setting reporting, not just the top-level status tile?

That last one matters. Device-level evidence is where the story becomes honest.

The practical standard

A tidy Intune tenant is not one with the most profiles. It is one where a reviewer can point at a control, explain where it lives, explain why it lives there, and prove the device received it.

That is boring. It is also what keeps policy failure from eating a whole afternoon.

References

• Manage device security with endpoint security policies in Microsoft Intune
• Create a policy using settings catalog in Microsoft Intune
• Questions with policies and profiles in Microsoft Intune