Intune gives you at least six ways to push the same Windows setting: the settings catalog, templates, administrative templates, custom OMA-URI, security baselines and endpoint security policies, plus Group Policy analytics to translate what you already have. They all write to the same configuration service providers (CSPs), which is exactly why mixing them carelessly produces conflicts. In this post I'll explain what each one is for, how Intune resolves and reports conflicts, and the layering I'd start with in a new tenant.
How it works#
Every Windows policy type in Intune is a front end for CSP settings. A setting can arrive from several policies, and Intune treats all policy types as equal sources: there's no "baselines win" or "last one wins" rule. The differences are in grouping, ownership in the admin center, versioning and reporting:
| Policy type | What it is | Use it for |
|---|---|---|
| Settings catalog | Every available setting in one picker, generated from the CSPs (and from Apple payload keys and declarative management), including the built-in ADMX settings. Devices › Manage devices › Configuration › Create › New policy › Windows 10 and later › Settings catalog | The default for new Windows, macOS, iOS/iPadOS and Android Enterprise configuration |
| Templates | Curated groups of settings for one feature: Wi-Fi, VPN, certificates (SCEP, PKCS, trusted root), Domain join, kiosk, device restrictions, Delivery Optimization, custom. Some are deprecated as their settings move into the catalog (the macOS Endpoint protection and Extensions templates since release 2408) | Things the catalog can't express yet, mostly network and certificate profiles |
| Administrative templates (ADMX) | Group Policy-style settings. Built-in Windows, Edge, Office and OneDrive ADMX settings live in the catalog; third-party ADMX/ADML files are imported under Configuration › Import ADMX (public preview: up to 20 files of 1 MB each, one en-us ADML per ADMX, dependencies such as Windows.admx first) and used through the Imported Administrative templates template | Vendor apps that ship their own ADMX |
| Custom (OMA-URI) | A raw CSP path such as ./Device/Vendor/MSFT/Policy/Config/... with a typed value (String, String (XML), Integer, Boolean, Date and time, Floating point, Base64). Intune delivers the value without understanding it, so it can't detect conflicts; the setting must support Add, Replace and Get | Last resort for settings not exposed anywhere else |
| Security baselines | Microsoft's recommended security configuration as a versioned template under Endpoint security › Security baselines: Security Baseline for Windows 10 and later (25H2, 24H2, 23H2...), Microsoft Defender for Endpoint, Microsoft Edge, Microsoft 365 Apps for Enterprise, Windows 365, HoloLens 2. Since 2023 baseline settings use the CSP names directly | A hardened starting point you then trim |
| Endpoint security policies | Focused profiles under Endpoint security › Manage: Account protection (including Windows LAPS and local user group membership), Antivirus, App Control for Business, Attack surface reduction, Disk encryption (BitLocker, FileVault, Personal Data Encryption), Endpoint detection and response, Firewall. Same CSPs, plus reusable settings groups and Defender portal management for devices not enrolled in Intune | Everything security teams own |
| Group Policy analytics | Import a GPO exported as XML (under 4 MB) at Devices › Manage devices › Group Policy analytics; it shows the MDM support percentage per GPO and setting, flags deprecated settings and can migrate the supported ones into a settings catalog policy | Triaging an on-premises GPO estate before rebuilding it in the cloud |
How conflicts are resolved and reported#
The rules are short and the same regardless of blade:
- Two configuration-type policies (catalog, template, baseline, endpoint security) that set the same setting to different values produce a Conflict. Intune doesn't pick a winner; the setting may fail to apply and both policies report it. You resolve it by hand.
- A compliance policy that evaluates a setting takes precedence over the same setting in a configuration profile; if two compliance policies disagree, the most restrictive applies.
- Baselines default most settings to a restrictive value, while endpoint security and catalog policies default to Not configured. That's the most common conflict: a baseline sets a firewall or Defender value and a separate antivirus policy sets it differently.
- Custom OMA-URI payloads aren't inspected, so a conflicting custom value isn't flagged; the device just ends up with one of the two.
- Removing a setting from a policy (the minus sign in the catalog) stops managing it, but whether the device reverts depends on the CSP; some keep the last value ("tattooing").
Where to see it: open the policy and use Per setting status to find the conflicting setting and device count, and check Devices › Monitor › Assignment failures for policies that failed through errors or conflicts, drilling down to the setting and error code.
Watch out: One setting, one owner. Decide which policy type manages each area (for example, Defender Antivirus only through the endpoint security antivirus profile) and remove those settings from everywhere else, including the baseline. Two policies agreeing today will disagree after someone edits one of them.
A recommended approach for a new tenant#
- Start with one baseline per product: deploy the Security Baseline for Windows 10 and later and, if you use Defender for Endpoint, its baseline, each as one profile assigned to a pilot device group. Review every default and set the ones you can't live with yet to Not configured rather than fighting them from another policy. Older baseline versions become read-only when a new one ships; move a profile forward with the built-in version change rather than recreating it.
- Put security workloads in endpoint security policies: antivirus, BitLocker, firewall, ASR rules, EDR onboarding and LAPS each get their own profile, which your security team can review and RBAC can scope separately.
- Use the settings catalog for everything else: OneDrive Known Folder Move, Edge and Office settings, Windows experience and privacy. Build small, single-purpose policies and use Duplicate or Export JSON to copy them between tenants.
- Fall back to templates only for Wi-Fi, VPN, certificates, Domain join and kiosk where the catalog doesn't yet cover the scenario.
- Reserve custom OMA-URI for documented exceptions, with the CSP link in the description, and review them every few months to see whether the catalog has caught up.
- Run Group Policy analytics on the GPOs you're replacing, but migrate deliberately: the tool tells you what can move, not what should.
Naming and assignment hygiene#
Names are your only index in a flat list that will pass a hundred policies. A pattern that holds up:
<Platform>-<Type>-<Area>-<Purpose>-v<n>
WIN-SC-OneDrive-KnownFolderMove-v1 (settings catalog)
WIN-ES-AV-DefenderAntivirus-Std-v2 (endpoint security)
WIN-BL-SecurityBaseline-25H2-v1 (baseline)
WIN-TPL-WiFi-CorpWPA3-v1 (template)
WIN-OMA-Policy-SomeCspSetting-v1 (custom)Put the why in the description, and bump the version instead of silently editing a policy already in production. Assign device-scope settings to device groups and user-scope settings to user groups; a device-scope catalog setting assigned to a user group still applies to the whole device once that user signs in, which surprises people.
Assignment filters (Tenant administration › Assignment filters) refine an assignment without another group: a rule over device properties, evaluated at check-in, used in Include or Exclude mode. A tenant can have up to 200 filters of up to 3,072 characters each. For example, assign a Surface-specific policy to All devices with this filter in include mode:
(device.manufacturer -eq "Microsoft") and (device.model -startsWith "Surface")Filters beat dynamic groups for Intune-only targeting by OS version, model, manufacturer, ownership or enrolment profile because there's no membership-processing delay; keep dynamic groups for things that span workloads, such as Conditional Access, licensing and Autopilot profile assignment.
Examples#
| Need | Right tool | Why not the others |
|---|---|---|
| Turn on BitLocker with TPM and back up keys to Entra ID | Endpoint security › Disk encryption | The baseline also sets BitLocker values; keep one owner |
| Deploy a Wi-Fi profile with a SCEP certificate | Templates (Trusted certificate, SCEP, Wi-Fi) | Not in the catalog for Windows |
| Configure a third-party app that ships ADMX files | Import ADMX, then Imported Administrative templates | Custom OMA-URI would need ADMX ingestion by hand |
| Replace 40 legacy GPOs | Group Policy analytics for triage, then catalog and endpoint security policies for the build | Migrating a GPO wholesale copies decisions made for domain-joined desktops years ago |
| A new CSP setting with no UI yet | Custom OMA-URI, documented | Nothing else exposes it; revisit later |