Custom OMA-URI vs Settings Catalog in Intune: when should IT use each?

In Microsoft Intune, there are two main ways to configure Windows settings that are not exposed as a simple toggle: the Settings Catalog and a custom OMA-URI profile. Both ultimately configure the same underlying Windows Configuration Service Providers (CSPs), the interfaces that Windows exposes for management, but they do so in very different ways. The guidance on which to use is now settled, and it has been settling for a while: Microsoft began restricting overlapping custom OMA-URI settings in 2024, and this guide is a two-years-on look at where that leaves the choice.

This guide explains what OMA-URI and the Settings Catalog are, how they relate to Windows CSPs, the state of Microsoft’s block on overlapping OMA-URI settings, a worked example, how to check whether a setting is already in the catalog, and a straightforward rule for when to use each. It is written for Intune administrators managing Windows devices who want to make the right call rather than default to habit.

The short version, for readers who want the answer first: check the Settings Catalog first and use it whenever the setting is there, and reserve custom OMA-URI for the settings the catalog does not yet cover. Microsoft has enforced that preference since 2024. The rest of this guide shows how to apply it in practice.

The foundation: what a CSP is

Both approaches sit on the same foundation, so it is worth one paragraph on it. A Configuration Service Provider (CSP) is the interface Windows exposes to let a management service to read and change a setting. When Intune configures a passcode rule, a firewall setting, or a browser policy on a Windows device, it is writing to a CSP. The Settings Catalog and custom OMA-URI are two different front ends for reaching those same CSPs. Understanding that they target the same layer is the key to understanding why one can increasingly replace the other.

What the Settings Catalog is

The Settings Catalog is Intune’s modern, searchable list of configurable settings. An administrator creates a Settings Catalog profile, searches for the setting by name, adds it, and sets its value through the Intune interface, without needing to know or enter the underlying CSP path. Microsoft describes it as the unified settings platform it is standardizing Windows configuration on, and it continually adds more settings to it (Microsoft Learn, custom settings for Windows in Intune)

The practical advantages are significant for a fleet. Settings are discoverable via search, values are presented with their valid options rather than as raw data types, reporting is clearer, and there is far less room for transcription errors that arise from typing long paths and values by hand. For most Windows configuration work today, the Settings Catalog is the intended and easier path.

What a custom OMA-URI profile is

A custom OMA-URI profile is the manual, low-level way to configure a CSP. OMA-URI (Open Mobile Alliance Uniform Resource Identifier) is the path syntax used to address a specific CSP setting directly. In a custom profile, the administrator enters the full OMA-URI path, selects the data type (integer, string, boolean, etc.), and enters the value, configuring the CSP manually. It can reach any CSP, but it is unforgiving: a mistyped path or the wrong data type simply fails to apply, often without an obvious error.

A worked example

A concrete example makes the mechanics clear, and this one is genuinely useful: the Windows account lockout policy is not currently in the Settings Catalog, so it is a legitimate use of a custom OMA-URI rather than a blocked one. In an Intune custom profile, you would add one OMA-URI setting with three fields:

OMA-URI:  ./Device/Vendor/MSFT/Policy/Config/DeviceLock/AccountLockoutPolicy

Data type: String

Value:  AccountLockoutThreshold:10;AccountLockoutDuration:15;ResetAccountLockoutCounterAfter:15

That single setting locks an account for fifteen minutes after ten failed attempts, then resets the counter. The path addresses the DeviceLock CSP directly, and the data type must be String; entering it as an Integer would result in a silent failure. This is the shape of every custom OMA-URI setting: a path, a data type that must match the CSP exactly, and a value (Microsoft Q&A, account lockout via custom OMA-URI)

Two years into the block: where custom OMA-URI stands

The single most important thing to understand about the choice today is Microsoft’s block on overlapping settings. In message center post MC822716, Microsoft announced that starting 15 August 2024, it would block the creation of new custom OMA-URI settings for any setting that already exists in the Settings Catalog, beginning with the least-used settings and expanding from there. That block has been in force and growing ever since (ourcloudnetwork, Microsoft to block custom OMA-URI settings)

Two years on, the practical picture is clear. Existing deployed OMA-URI policies continue to work, but you can no longer create a new custom OMA-URI entry for a setting the catalog already covers, and the set of blocked settings keeps growing as Microsoft moves more into the catalog. If creating a custom OMA-URI setting fails, that failure is itself the signal: the setting is now in the catalog and should be configured there instead.

This sits inside a larger migration. Microsoft has been moving Windows device-configuration templates onto the unified settings platform, deprecating some legacy template types entirely (such as the Administrative Templates and Network Boundary templates) and consolidating their settings into the Settings Catalog. Custom OMA-URI survives, but its role is now explicitly narrowed: it is for settings that do not exist in the Settings Catalog, not a parallel way to configure ones that do.

Microsoft will soon start blocking the use of custom OMA-URI settings in Microsoft Intune for settings that exist in the settings catalogue. My general advice is to use the settings catalog where possible, minimise the use of custom OMA-URI settings and migrate to the settings catalog as soon as you can.

Daniel Bradley, Microsoft MVP

How to check whether a setting is already in the catalog

Before creating a custom OMA-URI setting, the practical question is whether the catalog already has it; if it does, creation is blocked, and the catalog is the answer. There is no published list mapping OMA-URI paths to catalog settings, but you can check this programmatically. The diagram below shows both the anatomy of a path and where the check fits.

The key is the offsetUri: the trailing part of the OMA-URI path after the CSP base. Microsoft Graph PowerShell can filter the Settings Catalog using that offsetUri to determine whether a matching setting exists in the catalog. A result means the setting is in the catalog (use the catalog, and a new OMA-URI for it will be blocked); no result means a custom OMA-URI is still a valid path for that setting.

# Requires the Intune Administrator role and Microsoft.Graph.Beta.DeviceManagement

Get-MgBetaDeviceManagementConfigurationSetting `

  -Filter “offsetUri eq ‘/DeviceLock/AccountLockoutPolicy'” `

  | Select-Object DisplayName

# No result: the setting is not in the catalog, custom OMA-URI is valid.

# A result: use the Settings Catalog; a new custom OMA-URI is blocked.

Tip: run this against the offsetUri of each of your deployed custom OMA-URI settings to build a migration list; the ones that now return a catalog match are the ones to move to the catalog first.

When to use each: the decision rule

The choice reduces to a simple, ordered rule that matches what Microsoft now enforces.

1. Check the Settings Catalog first. Create a Settings Catalog profile and search for the setting by name (or check the offsetUri with the Graph query above). If it is there, use it. This is the default for almost all Windows configurations, and for overlapping settings, Microsoft requires it by blocking the OMA-URI alternative.

2. Use custom OMA-URI only when the setting is not in the catalog. If the setting genuinely does not appear in the Settings Catalog (like the account-lockout example above), fall back to a custom OMA-URI profile, using the Windows CSP policy reference to find the exact path and data type.

3. Keep custom OMA-URI for genuinely advanced cases. A few scenarios still call for it beyond simple missing settings: ingesting custom ADMX-backed policies, delivering AppLocker or other payload-style configurations, and reaching brand-new or niche CSP settings not yet surfaced in the catalog. These are the durable reasons OMA-URI remains in the product.

The rule in one sentence: Settings Catalog by default, custom OMA-URI by exception, and the set of exceptions keeps shrinking as Microsoft expands the catalog.

Reference: Windows Policy CSP reference (Microsoft Learn)

Settings Catalog vs custom OMA-URI at a glance

Behavior reflects Microsoft’s unified-settings-platform migration and MC822716 (blocked live since 15 August 2024): Microsoft Tech Community support tip.

Auditing your existing custom OMA-URI policies

Because existing OMA-URI policies continue to work but cannot be recreated once a setting moves into the catalog, the practical task for most teams is an audit rather than an urgent rebuild.

Inventory what you have. List the custom OMA-URI profiles currently deployed, with their paths and values. Undocumented OMA-URI policies are a common source of configuration mystery, so this is worth doing regardless.

Check each offsetUri against the catalog. Run the Graph query above against the offsetUri of each deployed setting. Where a catalog match already exists, plan to move that setting to a Settings Catalog profile so that new deployments and edits use the supported path.

Migrate on your schedule, not in a panic. Existing OMA-URI policies are not being switched off, so this is a managed cleanup. Move settings to the catalog as you touch the relevant profiles, prioritizing the ones you edit most, and retire the OMA-URI versions once the catalog equivalents are confirmed working.

How this maps to a cross-platform MDM

The Settings Catalog and custom OMA-URI are Intune’s two front ends onto Windows CSPs, and the OMA-URI-versus-catalog question, and Microsoft’s block, applies specifically to Intune. It is worth being precise about what that means for a cross-platform MDM, because the honest answer is not “other tools don’t do this.”

Windows CSPs are the operating system’s management interface, not an Intune feature, so any Windows MDM configures devices by writing to those same CSPs over the OMA-DM protocol. What differs between platforms is the front end each provides. Bento MDM manages Windows through that CSP model: it exposes common Windows settings as configurable policies in its console (the equivalent of catalog-style, guided configuration) and supports custom CSP configuration for settings not surfaced directly (the role custom OMA-URI plays in Intune). The concepts in this guide, CSPs as the target, guided settings as the default, and a manual custom path for the long tail, therefore carry across; the Settings Catalog and the MC822716 block are Intune’s particular implementation of that pattern.

The reason this matters for a mixed fleet is consistency. An organization running Windows alongside Android, iOS, and macOS wants one place to configure all of them, applying each platform’s native model: on Apple, that increasingly means declarative device management, and on Windows, it means the CSP-based model that both the Settings Catalog and OMA-URI target. A cross-platform MDM like Bento MDM manages those platforms from a single console, so Windows CSP configuration sits next to the rest of the fleet rather than in a separate tool.

The move to the Settings Catalog is the right direction for Windows management, and most of what we hear from admins is practical: which of their existing custom settings they will still be able to recreate, and where the manual path still earns its place. We built Bento’s Windows configuration around both, guided settings for the common cases and a custom CSP path for the long tail Microsoft has not surfaced yet, so teams are not left stranded when a setting is not in the catalog.

Ionut Soare, Senior Product Manager, Bento MDM

Frequently asked questions