What Is OMA-URI? How It Works, Examples, and When to Use It

Every MDM platform has an edge, a point where the built-in policy templates run out and a Windows setting you need to enforce simply doesn't appear in any catalog or template. That gap is exactly where OMA-URI comes in. OMA-URI is the mechanism that lets an MDM platform reach any Windows configuration setting, covered by a user-friendly interface or not.

OMA-URI is a string-based address that points to a specific node in Windows' device management tree. When your MDM platform sends that path alongside a value, Windows reads it through a Configuration Service Provider (CSP) and applies the setting. No Group Policy, no registry editor, no on-premises infrastructure required.

It's not your first tool, though. Microsoft's Settings Catalog covers many common configurations through a UI. OMA-URI is the escape hatch for settings the Catalog hasn't surfaced yet, and in 2026, that's still a meaningful number of CSP nodes for anyone managing Windows fleets at scale.

This article covers how the OMA-URI delivery stack works, how to read and build a path, a reference table of real-world examples, when to use OMA-URI versus the Settings Catalog or Group Policy, how to troubleshoot the most common failure modes, and how Trio MDM fits into this picture for organizations managing Windows devices.

TL;DR

What OMA-URI Actually Is (and the Stack It Sits In)

If you've already built and deployed a custom OMA-URI policy, skip ahead to the examples table in the next section. This section is for practitioners who want a clear mental model before they start writing paths.

OMA-URI, short for Open Mobile Alliance Uniform Resource Identifier, is a string-based path that points to a specific node in Windows' device management tree. The formal name tells you the standard's origin: the Open Mobile Alliance, which defined the protocol originally for mobile devices. What is OMA-URI in practical terms? It's an address. You give your MDM platform the address, a data type, and a value, and Windows applies the setting at that address.

Every OMA-URI path follows the same anatomy:

./[Scope]/Vendor/MSFT/[CSP Name]/[Setting Name]

• ./Device/ or ./User/, the scope. Device scope applies to the machine regardless of who's logged in. User scope applies to the signed-in user's session.
• Vendor/MSFT/, Microsoft's namespace within the OMA standard.
• [CSP Name], the specific Configuration Service Provider branch (e.g., Policy, BitLocker, Defender).
• [Setting Name], the exact setting node within that CSP.

A concrete example: ./Device/Vendor/MSFT/Policy/Config/Defender/EnableNetworkProtection

The CSP (Configuration Service Provider) is the Windows API sitting between your MDM platform's OMA-URI command and the actual OS setting. Think of the OMA-URI as the address and the CSP as what opens the door. Each CSP handles a specific category, Defender, BitLocker, Policy, AccountManagement, and translates the MDM instruction into an OS action.

The transport layer is OMA-DM: an HTTPS-based protocol that carries OMA-URI payloads from the MDM server to the device using SyncML-formatted messages. It operates on a Get → Set → Get confirmation model. The OMA DM 1.2 standard dates to 2007, and Microsoft's MS-MDM protocol received its latest revision in April 2024, this is an active, maintained standard, not a legacy relic.

The full OMA-DM protocol delivery stack runs in this order:

1. OMA-URI (the payload, the address and value)
2. Custom policy profile (the container that holds one or more OMA-URI settings)
3. MDM platform (the delivery mechanism that packages and sends the profile)
4. OMA-DM protocol (the transport layer over HTTPS)
5. CSP (the receiver on the Windows device that applies the setting)

Before writing any path, check the CSP documentation's "minimum supported version" column. Building a path for a CSP node that doesn't exist on your target Windows build will give you a silent "Not Applicable" result, making this check a habit saves a lot of investigation later.

Custom OMA-URI Settings: A Working Reference Table and Real Examples

Finding the right path is the hardest part of working with OMA-URI. Microsoft's CSP reference documentation is the authoritative source, and the most effective search strategy is "[setting you want] CSP" in Microsoft Docs. When working with any MDM platform, including Trio MDM, which is building Windows CSP support based on Microsoft's list, the five required fields for a custom OMA-URI policy are always the same: name, description, OMA-URI path, data type, and value. The policy management container that holds these settings is how your MDM platform packages and deploys them. The table below covers OMA URI examples for the most common use cases practitioners reach for OMA-URI to handle.

Data Types You'll Encounter

Using the wrong data type for a path, entering a String where Integer is required, for example, causes a silent failure or 0x87d1fde8 error. The CSP won't process it, and the MDM console may still show a success. Match the type to what the CSP documentation's "Format" column specifies.

• Integer, numeric values; used for enable/disable flags (0 = disabled, 1 = enabled, 2 = audit mode in Defender)
• String, text-based values; used for path lists, URL allowlists, custom text
• Boolean, true/false; less common than Integer for Windows MDM
• Base64, encoded binary; used for certificate payloads
• XML, structured data; used for AppLocker policy and ADMX ingestion for third-party apps

One practical note on copy-pasting: paths copied from documentation often carry invisible characters that cause errors. Retype paths manually or strip formatting in a plain-text editor before using them.

ADMX-Backed Policies: Managing Third-Party Apps via Custom OMA URI

Chrome, Firefox, and other third-party applications can be managed via custom OMA URI by first ingesting the application's ADMX file into your MDM platform. The platform then maps each ADMX setting to a Policy CSP path. This is a genuine capability, your MDM platform can manage virtually any third-party app that ships an ADMX file.

The prerequisite to flag explicitly: if you deploy an OMA-URI for Firefox without ingesting the Firefox ADMX file first, you will get a 0x87d1fde8 error every time. This is the most common stumbling block for browser management via OMA-URI. Troubleshooting pair: if Firefox OMA-URI policies return 0x87d1fde8, check whether the Firefox ADMX file has been ingested into your MDM platform before investigating anything else.

The real-world bottleneck here is often not the technical configuration, it's getting the right ADMX file approved and uploaded by someone with MDM platform admin access.

User Scope vs. Device Scope

The ./Device/ and ./User/ prefixes are not interchangeable. Some CSP nodes are device-scoped only. Some are user-scoped only. A policy deployed with the wrong scope produces a silent failure, no error, the policy simply doesn't apply. The CSP reference documentation lists the applicable scope for every node: check it before writing the path.

The table below lists 8 real-world custom OMA URI settings with their full paths, data types, and values.

OMA-URI vs. Settings Catalog vs. Group Policy: Which One Do You Need?

The decision between OMA-URI, the Settings Catalog, and Group Policy comes down to where your devices live and what tool can actually reach them. For anyone managing a mobile device management policy for a hybrid fleet, this framing matters: Group Policy's wide setting coverage applies only to domain-joined, on-premises devices. The moment a device is cloud-managed or remote, GPO either can't reach it or requires a VPN or SCCM dependency. For cloud-managed fleets, the setting count comparison between GPO and MDM is beside the point.

Use this decision tree to pick the right tool:

For hybrid environments where both GPO and MDM are active, the ControlPolicyConflict/MDMWinsOverGP OMA-URI (value 1) forces MDM to win any conflicts with Group Policy. This setting has been available since Windows 10 version 1803.

One second-order consequence worth naming before you enable it: any GPO that previously managed a conflicting setting will silently stop applying. Audit your existing GPO inventory before enabling MDMWinsOverGP in production, you may have settings enforced by Group Policy that you've forgotten about.

OMA-URI is genuinely more manual and error-prone than Group Policy for the same setting. The trade-off is that it works on devices Group Policy can't reach, which is the whole reason you're here.

A well-designed MDM platform reduces the manual burden significantly by surfacing common CSP paths in a validated UI, leaving raw OMA-URI for the edge cases.

How to Create a Custom OMA-URI Policy in Any MDM Platform

Knowing how to create OMA-URI policies starts with one reliable fact: the five required fields are the same across every MDM platform that supports windows device management. Whether you're using Trio MDM or any other MDM platform that supports Windows device management, you'll fill in the same information. The OMA URI path syntax and data model are defined by the OMA standard, not by the platform vendor.

Here are the five fields, in the order you'll encounter them:

1. Name, A label for the policy in your MDM console. Make it descriptive (e.g., "Defender Network Protection - Enable") so you can audit it later without opening the policy to read the path.
2. Description, Optional but worth using. Document what the setting does and why it's configured this way. Policies without context become a problem when someone else inherits the environment.
3. OMA-URI path, The full path string, case-sensitive, no trailing spaces. Example: ./Device/Vendor/MSFT/Policy/Config/Defender/EnableNetworkProtection
4. Data type, Must match what the CSP expects (Integer, String, Boolean, Base64, XML). Check the CSP documentation's "Format" column before entering anything here.
5. Value, The setting value (e.g., 1 to enable, 0 to disable). Must match the data type exactly.

To find the correct path for a setting, search Microsoft's CSP reference documentation for the setting name followed by "CSP." The documentation lists the path, data type, and allowed values for every node.

After deployment, check device status in the MDM console. "Succeeded" means the CSP received and applied the setting. If you see an error code, move to the troubleshooting section below.

Troubleshooting pair: if the OMA URI path doesn't apply after deployment, check whether you copied the path from a formatted source. Invisible characters introduced by copy-paste are the most common cause of 0x87d1fde8 on otherwise-valid policies, retype the path manually if you're not sure.

Always test on a single device or a test group before deploying broadly. If your change management process requires a documented rollback plan, OMA-URI policies can be reversed by redeploying the same path with the previous value, document the before-state before you deploy.

Troubleshooting OMA-URI Policies: Error Codes, Silent Failures, and What to Check First

The Three Failure States (and What They Mean)

Remediation Failed / 0x87d1fde8 / -2016281112: The CSP tried to apply the setting and couldn't. The most common causes:

• Wrong OMA-URI path (typo, wrong case, trailing space)
• Incorrect data type
• ADMX file not ingested for a third-party app policy
• The CSP node doesn't exist on that Windows build
• Payload over 350K bytes, Microsoft blocked creation of OMA-URI policies with payloads exceeding this limit after finding they were not consistently applied to Windows 10 devices

Not Applicable: The policy was deployed but the CSP node is not supported on the target device. This is almost always a Windows version mismatch, the CSP node was introduced in a later build than what the device is running. Check the CSP documentation's "minimum supported version" column. The Windows 11 24H2 Copilot deprecation is a concrete example: the TurnOffWindowsCopilot path stopped working reliably from 23H2 onward and was formally dropped for 24H2, leaving admins who had deployed this policy to rebuild their approach using AppLocker. This is exactly why version checks before deployment matter.

Succeeded 0, Error 0, Conflict 0, Not Applicable 0 (the invisible failure): The policy registered with the MDM console but never reached the device. Common causes: co-management conflict (SCCM and MDM both active), assignment targeting issue (policy assigned to a group the device or user isn't actually in), or a scope mismatch (policy scoped to device but the setting requires user scope). This is the hardest failure mode to diagnose, the console gives you no signal.

How to Diagnose a Failed Policy

Step 1: Export the MDM diagnostics XML from the target device: Settings → Accounts → Work or School → Export MDM diagnostics. This file gives you the ground truth of what policies the device actually received, regardless of what the console reports.

Step 2: Check Event Viewer on the device for MDM-related entries. The event log references custom policies by name if they were received.

Step 3: For protocol-level inspection, use SyncMLViewer to monitor real-time OMA-DM session activity. This shows exactly what the MDM server sent and what the device acknowledged.

Troubleshooting pair: if the MDM console shows Succeeded but the setting isn't applying on the device, export the MDM diagnostics XML. If the policy doesn't appear in that file, the device never received it, regardless of what the console reports.

Where OMA-URI Fits in 2026: MMP-C and the Dual-Engine Reality

OMA-URI in 2026 sits in an interesting position. You may have seen forum discussions questioning whether it's about to be replaced, the short answer is no, and the context behind that answer matters for how you plan your management approach.

Microsoft introduced a new management architecture called MMP-C (Microsoft Management Platform – Cloud), which runs the Windows Declared Configuration (WinDC) protocol alongside the existing OMA-DM engine. Rather than replacing OMA-DM, Windows devices running MMP-C are dual-enrolled, both engines operate simultaneously.

OMA-URI policies continue to run on the legacy OMA-DM engine. Newer capabilities like Endpoint Privilege Management and Resource Access Policies use the WinDC engine. The two engines coexist without conflicting, each handles a different class of management scenarios.

For the settings OMA-URI can configure (anything in the CSP tree), nothing is going away. WinDC handles a different scope. OMA-URI remains the mechanism for configuration settings not yet surfaced in higher-level tools.

MMP-C is rolling out through 2025 and is primarily relevant for environments managed through Microsoft's own MDM platform. Organizations using other MDM platforms should evaluate how their platform's roadmap handles this evolution, check your MDM vendor's roadmap for how they're handling MMP-C, as this is an active area of development for Trio MDM.

One second-order consequence for co-managed environments: if your organization runs devices managed by both SCCM and MDM, MMP-C introduces a third policy layer. Audit which engine owns each policy category before deploying WinDC-based policies, unexpected conflicts between engines are harder to trace than standard OMA-DM failures.

The criticism that OMA-URI was never meant for desktop management isn't entirely wrong, it is manual, and it is error-prone. But it's also the only path available to configuration settings on cloud-managed devices that have no on-premises infrastructure behind them. That's not changing with MMP-C.

How Trio MDM Helps With Windows Configuration Policy

For IT admins working through the CSP-based layer that OMA-URI depends on, Trio MDM approaches Windows device management by building support across Microsoft's CSP list. Trio MDM is building Windows CSP support based on Microsoft's published CSP list, the same list that defines what OMA-URI can reach. The underlying infrastructure that OMA-URI targets, the CSP tree, is part of Trio MDM's active development roadmap.

One CSP-level capability already live in Trio MDM is BitLocker recovery key escrow. Trio MDM stores recovery keys securely on its backend, so admins can retrieve them without physically accessing devices, a practical example of the kind of Windows security configuration OMA-URI paths into the BitLocker CSP enable.

Trio MDM's architecture pairs MDM enrollment with an RMM agent on the same Windows device. MDM enrollment alone leaves gaps, real-time monitoring, remote configuration, and extended automation aren't fully covered by MDM protocols. The Trio MDM agent fills those gaps without requiring a separate platform. For large-scale deployments, enrollment can be automated via PowerShell script, which integrates with existing SCCM or Intune workflows.

If your organization manages Windows alongside macOS, iOS/iPadOS, Android, or Linux, Trio MDM handles all of them from one platform, no separate consoles for different operating systems.

If you want to see how Trio MDM's Windows CSP roadmap fits your environment, start your free trial or book a demo to walk through the specifics with the team.