Consolidate overlapping Intune policies, eliminate GPO conflicts, standardize naming conventions, and build a documented configuration baseline your team can actually maintain.
It starts with one extra profile. Then a quick fix. Then a migration. Before you know it, nobody can tell what's actually enforced.
Configuration profiles created by different admins over time with no naming convention, no descriptions, and no record of why they exist.
Hybrid-joined devices receiving conflicting instructions from Group Policy and Intune. Settings that revert on every sync cycle because both sides claim ownership.
OMA-URI custom policies that appear to deploy successfully but have no effect because they conflict with a Settings Catalog profile targeting the same CSP node.
Microsoft security baselines deployed initially but now overridden by newer custom policies. Your compliance report says "compliant" while devices run settings from 2022.
Policies named "DO NOT DELETE" or "backup" that nobody understands but everyone is afraid to remove because it might break something.
Every new policy you deploy introduces unexpected side effects because there are hidden conflicts with existing policies you did not know about.
Last updated:
We export every configuration profile, compliance policy, and security baseline via Graph API. Each setting is mapped to its CSP node, revealing hidden overlaps that the Intune portal does not show you.
We identify every conflict: same-setting conflicts across profiles, GPO-vs-Intune contradictions, OMA-URI collisions with Settings Catalog, and assignment group overlaps that cause inconsistent device behavior.
We design the consolidated policy set: fewer profiles, clear naming conventions, Settings Catalog where supported, proper group assignments, and alignment with your chosen security baseline (Microsoft, CIS, or custom).
New policies are deployed to pilot groups first. We validate effective settings on test devices before expanding. Old policies are retired only after confirming the replacement is working. No big-bang cutover.
Every policy gets a standardized name, a description with business justification, and a documented change process. Your team inherits a system they can extend without reintroducing sprawl.
We configure Intune policy change notifications, establish a lightweight review process for new policies, and optionally set up automated drift detection using Proactive Remediations.
A detailed map of every conflict in your current environment, including the specific CSP nodes affected, which policies win, and what the actual effective configuration is on devices today.
The new, clean set of Intune configuration profiles deployed and validated in your tenant. Typically reduces policy count by 50-70% while maintaining or improving security posture.
A documented standard for policy naming, descriptions, group assignments, and change management. Includes templates for creating new policies that follow the convention.
For hybrid environments: a complete mapping of which GPO settings were migrated to Intune, which were replicated via OMA-URI, which are handled by Proactive Remediations, and which were intentionally retired.
Side-by-side comparison of effective device configuration before and after rationalization. Proves that the consolidation did not change device behavior while eliminating conflicts.
Policy conflicts happen when multiple configuration profiles target the same setting on the same device through different assignment groups. This is common during SCCM-to-Intune migrations where GPO settings are partially replicated, when multiple admins create policies independently, or when security baselines overlap with custom configuration profiles. Intune's conflict resolution is "last write wins" for some settings and "most restrictive" for others, making the outcome unpredictable without careful analysis.
We follow a phased approach: first, we document every active policy and its effective settings using Graph API exports. Then we design the target-state policy set using Settings Catalog where possible. We deploy new policies to a pilot group alongside existing ones, validate that the effective configuration matches, then gradually reassign devices from old policies to new ones. At no point do we remove a policy before confirming its replacement is working.
Settings Catalog is the future of Intune policy management and our recommended approach for new deployments. It provides granular per-setting control, better conflict visibility, and is where Microsoft invests new functionality. Templates still work but create monolithic profiles that are harder to troubleshoot. We migrate clients to Settings Catalog as part of rationalization, keeping templates only where Settings Catalog doesn't yet support the setting.
We use a structured naming convention: [Platform]-[Category]-[Scope]-[Description]. For example: "WIN-Security-AllDevices-BitLockerEncryption" or "iOS-Compliance-BYOD-MinimumOS". Every policy includes a description field with the business justification, the owner, and a link to the change ticket.
Some GPO settings have no direct Intune equivalent. For these, we evaluate three options: 1) OMA-URI custom policies using the ADMX ingestion feature, 2) PowerShell remediation scripts via Intune Proactive Remediations, or 3) accepting the gap if the setting is no longer relevant in a cloud-managed environment. We document every decision so your team understands what was migrated, replaced, or intentionally dropped.
Free 30-minute consultation to understand your current policy landscape and scope the cleanup engagement.