Configuration Profiles vs Settings Catalog vs Administrative Templates: The Decision Guide · CloudEngineerHub
Intune10 min read7 views
Configuration Profiles vs Settings Catalog vs Administrative Templates: The Decision Guide
When to use Templates, when the Settings Catalog, when ADMX-backed Administrative Templates are still the answer, and how OMA-URI fits — plus how Intune reports conflicts.
C
CloudEngineerHub Team
Published: September 5, 2026· Last Updated: September 24, 2026·10 min read
Configuration Profiles vs Settings Catalog vs Administrative Templates
Intune gives you three main vehicles to push Windows settings: classic configuration profile Templates, the Settings Catalog, and Administrative Templates (ADMX-backed). They overlap heavily — the same password length setting can be delivered by all three — which is exactly why teams end up with conflicting policies and mystery behavior. Here is the decision framework production admins actually use.
Visual Walkthrough
Three policy surfaces, one decision framework.
Side-by-SideConfiguration Profiles vs Settings Catalog vs Admin Templates6/6
Settings Catalog
modern CSP
Templates / ADMX
curated + legacy
Direct CSP exposure, granular
Templates bundle common intent
Per-setting conflict reporting
ADMX ingestion mirrors GPO settings
Fastest to add new Windows settings
Familiar to GPO administrators
Best for precision baselines
Some settings lack CSP coverage
Can feel overwhelming at first
Use when catalog lacks the key
Configuration Profiles vs Settings Catalog vs Admin Templates. Settings Catalog vs Templates / ADMX. Settings Catalog: Direct CSP exposure, granular · Templates / ADMX: Templates bundle common intent — Settings Catalog: Per-setting conflict reporting · Templates / ADMX: ADMX ingestion mirrors GPO settings — Settings Catalog: Fastest to add new Windows settings · Templates / ADMX: Familiar to GPO administrators — Settings Catalog: Best for precision baselines · Templates / ADMX: Some settings lack CSP coverage — Settings Catalog: Can feel overwhelming at first · Templates / ADMX: Use when catalog lacks the key
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Intune admin center access with a role that can create device configuration policies (Intune Administrator, or scoped Role Based Access).
Devices enrolled and checking in — policy delivery is meaningless without a healthy check-in cadence.
For Administrative Templates: Windows Pro/Enterprise (some settings apply only on editions with the underlying policy support).
For Custom OMA-URI profiles: the exact CSP documentation path for every URI you plan to use.
A written convention (even one page) for which vehicle your team uses and when — the conflicts below start as conventions that were never written down.
Know Your Vehicles
Start in intune.microsoft.com → Devices → Configuration → Create → New policy. Templates are the pre-built profiles: Restrictions, Wi-Fi, VPN, Custom (raw OMA-URI) and friends. Administrative Templates ingest classic Group Policy ADMX settings through the Policy CSP — Windows only, thousands of familiar GP settings, no Group Policy processing or loopback to worry about. Settings Catalog is the modern surface: cross-platform (Windows, macOS, iOS/iPadOS, Android), thousands of granular settings presented with their real value types, and — critically — new settings land here first. Microsoft direction is unambiguous: the Settings Catalog is the future, and Administrative Templates are maintained but no longer where new settings show up.
How Policy Delivery Works
Under the hood, every vehicle writes into the same destination: configuration service providers (CSPs) on the device. The MDM stack applies policy at enrollment and re-applies at each check-in; the device reports per-CSP status back, which Intune surfaces as per-setting device status. Because all three vehicles converge on the same CSP nodes, delivering one setting from two vehicles is not "redundant protection" — it is two writers to one value. Unlike Group Policy, Intune does not have tidy precedence for identical settings: two policies touching the same value produce a Conflict, and CSP-level behavior often ends up last-write-wins. That is the root cause of most "policy flapping" stories in real tenants.
The Decision Framework
For any new policy, ask three questions in order:
Is it in the Settings Catalog? Use the Settings Catalog. Better per-setting error reporting, cleaner scoping, and it is where Microsoft invests.
Is it a classic GP setting not yet in the catalog? Use Administrative Templates — but record why, because it is a migration debt.
Is it exposed only as a raw CSP node? Use a Custom (OMA-URI) profile as the last resort, with the CSP path written exactly (for example ./Device/Vendor/MSFT/Policy/Config/...).
Whatever you choose, deliver each setting from exactly one policy. Check health per setting under the profile's Device status and per-setting reports, not just the green overall compliance dot.
Step-by-Step: Shipping a New Setting Safely
Find the setting in the Settings Catalog by searching its GP name — new catalog entries frequently mirror ADMX naming.
Create a dedicated policy with a naming convention that says platform, purpose, and owner (e.g., WIN-Security-USB-Block-v1).
Assign to a pilot Entra group first — five to fifty devices spanning your main hardware models.
Read per-setting status, not the summary dot: one setting can error on one model while everything else succeeds.
Widen in waves, and resist the urge to redeploy the same setting from a second policy "temporarily" — temporary duplicates are exactly how permanent conflicts are born.
Configuration Deep Dive: Filters, Scope Tags, and Conflict Reporting
Two operational extras matter at scale. Assignment filters narrow a profile to specific devices (say, only a certain OS build or hardware model) without multiplying Entra groups, and scope tags keep large admin teams from editing each other's policies. When you do inherit a conflict, drill into the profile's per-setting device status: Intune labels each setting as Success, Error, Conflict, or Not applicable per device, which turns a mysterious fleet-wide behavior change into a two-device repro you can diff. The reporting is the safety net — but it only works if each setting has a single home to begin with.
Real-World Enterprise Scenario
A 4,500-device logistics firm chased a phantom for weeks: USB storage was blocked on most laptops but demonstrably writable on a few. Three vehicles were in play — a Settings Catalog policy blocking removable storage, an old Administrative Templates profile from the GPO migration that set the same ADMX policy to "not configured", and a Custom OMA-URI policy a leaver had built for a specific warehouse model. Per-setting status showed the Conflict state on exactly the affected devices. The fix was organizational as much as technical: one owner per setting, the OMA-URI duplicate deleted, the ADMX profile retired with its reason recorded, and a naming convention that made future duplicates visible at a glance in the policy list.
PowerShell: Auditing Your Policy Estate
As the estate grows, inventory it from Graph — the Settings Catalog and classic profiles live under different endpoints:
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
Connect-MgGraph -Scopes"DeviceManagementConfiguration.Read.All"# Settings Catalog policies
Get-MgDeviceManagementConfigurationPolicy -All |
Select-Object Name, Platforms, Technologies, CreationDateTime |
Sort-Object CreationDateTime -Descending# Expected: catalog policies newest first# Classic configuration profiles (Templates, Custom, Administrative Templates)
Get-MgDeviceManagementDeviceConfiguration -All |
Select-Object DisplayName, '@odata.type'# Expected: one line per classic profile with its concrete resource type
Sort by creation date and you will usually find the duplicate policy nobody remembers making — the root of most conflicts.
Troubleshooting Matrix
Symptom
Cause
Fix
Setting flagged Conflict on some devices
Two policies write the same CSP node
Keep one; delete or scope the other
Per-setting Error, profile shows success
A single setting failed on a model
Read per-setting status; fix value or exclude model
ADMX setting has no effect
Edition lacks the underlying policy, or CSP not supported
Verify edition support; use catalog equivalent
OMA-URI rejected
Malformed URI or wrong data type
Copy the exact CSP path and format from documentation
Policy applies then reverts
Another vehicle (legacy GPO or second profile) rewrites the value
Remove the competing writer
mac/iOS settings missing
Administrative Templates are Windows-only
Recreate in Settings Catalog for those platforms
Common Errors
Conflict status — two sources, one value. Intune reports it; it will not arbitrate it for you.
"Not applicable" where you expected enforcement — requirements, filters, or platform support excluded the device.
Silent OMA-URI failures — a typo'd URI may apply as "success" with no effect; validate on one device before waves.
Edition gaps — some Administrative Template settings simply do not exist on Pro/Home editions; check the CSP documentation, not the console.
Visual Walkthrough
Watch a policy travel from console to device and back as compliance telemetry.
Settings Catalog, template or ADMX ingestion — the console is the single source of intent.
targets
2
Assign with targeting
Device or user groups, filters include/exclude, optional scope tags for RBAC.
check-in
3
Device checks in
Push notification or the 8-hour scheduled cycle wakes the MDM channel.
4
CSP evaluation
Enterprise policy hits the Configuration Service Provider; unsupported settings are skipped, not fatal.
telemetry
5
State reports back
Per-setting success/error lands in Intune reports within minutes of check-in.
continuous
6
Drift re-mediated
Next cycle re-applies the intent — the loop keeps the fleet converged.
The Intune Policy Lifecycle — Console → Device → Telemetry. 1. Author the policy: Settings Catalog, template or ADMX ingestion — the console is the single source of intent. — 2. Assign with targeting: Device or user groups, filters include/exclude, optional scope tags for RBAC. — 3. Device checks in: Push notification or the 8-hour scheduled cycle wakes the MDM channel. — 4. CSP evaluation: Enterprise policy hits the Configuration Service Provider; unsupported settings are skipped, not fatal. — 5. State reports back: Per-setting success/error lands in Intune reports within minutes of check-in. — 6. Drift re-mediated: Next cycle re-applies the intent — the loop keeps the fleet converged.
Best Practices
Default to the Settings Catalog; use Administrative Templates only for classic GP settings the catalog lacks, and record each one as migration debt.
One setting, one policy — enforce it with a naming convention and a review step before any policy ships.
Pilot every policy on a real-device group and read per-setting status before widening.
Use filters to carve exceptions instead of cloning policies.
Inventory the estate quarterly with the Graph scripts above; duplicates age in quietly.
Security Considerations
Baseline hardening (BitLocker, Defender, USB restrictions) deserves the strictest single-owner discipline — a conflicted security control is an audit finding.
Custom OMA-URI profiles execute your exact CSP writes; review them like code, since a wrong value can weaken posture silently.
Scope tags double as blast-radius control: junior admins should not be able to edit the security baseline.
Watch settings that weaken platform defaults (e.g., disabling SmartScreen or Defender features) — catalog search makes accidental weakening easy.
FAQ
Which vehicle gets new Windows settings first?
The Settings Catalog. Administrative Templates are maintained but no longer receive new settings at the same pace.
Can I mix Administrative Templates and Settings Catalog in one tenant?
Yes, constantly — the rule is not mixing the same setting across vehicles.
Is OMA-URI deprecated?
No. It remains the escape hatch for CSP nodes without UI; the catalog simply removes most reasons to reach for it.
How do I find which policy set a value on a device?
Per-setting device status on each profile, plus the device's policy report — and the naming convention makes the suspect list short.
Do filters replace exclusion groups?
They reduce group sprawl for device attributes (OS build, model), but user-targeting still needs groups.
Conclusion
The three vehicles are one destination — CSPs on the device — which is why the decision framework matters more than the vehicle itself. Default to the Settings Catalog, treat Administrative Templates as recorded debt, keep OMA-URI as a reviewed last resort, and give every setting exactly one home. The conflicts you prevent are the midnight pages you never get.
Policy strategy is heavily tested in MD-102: prove yours with the mocks on /mock, debug policy conflicts with the free tools on /tools, and bundle your study plan from /store.
Comments
0No comments yet — be the first to share your thoughts.