Intune OMA-URIs vs. On-Premise: Deep Dive & Deployment Strategies for CSP Targeting

Table of Contents

This article delves into the significance of Windows Configuration Service Providers (CSPs) and Open Mobile Alliance – Uniform Resources (OMA-URIs). It explains how these custom policies are delivered to Windows 10 and newer devices using Microsoft Intune. Understanding these concepts is crucial for effectively managing modern Windows endpoints.

Microsoft Intune offers a user-friendly interface for configuring a wide array of policies. However, not every possible setting configurable on a Windows device is available directly within the Microsoft Intune admin center interface. As the Windows platform evolves, there can sometimes be a delay before new settings are integrated into the Intune UI. In these specific situations, deploying a custom OMA-URI profile that leverages a Windows Configuration Service Provider (CSP) provides a powerful solution.

Understanding CSP Scope¶

CSPs function as interfaces utilized by mobile device management (MDM) providers to interact with device configuration settings. They enable MDM solutions like Intune to read, set, modify, or delete specific configuration values. This interaction often translates to changes within the Windows Registry, where policies are typically stored and applied. The applicability of a CSP policy is determined by its scope.

The scope dictates the level at which a particular policy can be configured on the device. This concept is similar to the policy scopes found within the Microsoft Intune admin center, where settings can apply differently. Some policies are designed to be configured only at the device level; these settings apply universally to the device, regardless of which user is currently logged on. Other policies are scoped specifically at the user level, meaning they only apply to the settings and environment for that individual user. The specific configuration level (user or device) is defined by the Windows platform itself and is not determined by the MDM provider being used. When implementing a custom policy, it is essential to consult the Windows CSP reference documentation to ascertain the correct scope for the CSP you intend to utilize.

The scope of the CSP is a critical factor because it directly influences the syntax of the OMA-URI string required for successful configuration. An incorrect scope in the OMA-URI path will result in the policy failing to apply to the target device or user. Carefully determining whether a policy applies at the device or user level is the first step in constructing the correct OMA-URI for your custom Intune profile.

User Scope¶

When a CSP policy is designed to apply specifically to the user profile and settings, it operates under the user scope. This means the configuration only takes effect when a particular user logs into the device. Policies like personal desktop backgrounds, specific application settings tied to a user profile, or user-specific network configurations often fall under this scope. The OMA-URI path for configuring a user-scoped policy always begins with ./User.

Here are examples illustrating the structure for user-scoped OMA-URIs:

• ./User/Vendor/MSFT/Policy/Config/AreaName/PolicyName: This syntax is used to configure or set the value of a specific policy within a designated CSP area for the current user.
• ./User/Vendor/MSFT/Policy/Result/AreaName/PolicyName: This path is used to query the configuration result or the currently applied value of a specific policy for the user.

Device Scope¶

Conversely, when a CSP policy is intended to apply to the entire device, affecting all users who log into it, it operates under the device scope. These policies often control fundamental device behavior, security settings enforced at the machine level, or hardware configurations. Examples include enforcing encryption, configuring Windows Update behavior, or setting system-wide proxy settings. The OMA-URI path for configuring a device-scoped policy consistently starts with ./Device.

Examples showcasing the structure for device-scoped OMA-URIs include:

• ./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName: This is the syntax used to configure or set the value of a specific policy within a designated CSP area for the entire device.
• ./Device/Vendor/MSFT/Policy/Result/AreaName/PolicyName: This path is utilized to query the configuration result or the currently applied value of a specific policy for the device.

Understanding and correctly specifying the scope in the OMA-URI path is paramount for the successful deployment of custom policies via Intune. Misconfiguring the scope is a common reason for policy deployment failures.

Exploring OMA-URIs¶

The OMA-URI itself is essentially a path, acting as a pointer to a specific configuration setting that is supported and exposed by a particular Configuration Service Provider on a Windows device. It is the fundamental building block for applying settings outside of Intune’s built-in templates. Think of it as the address for a specific setting node within the device’s configuration tree managed by the CSP.

Let’s break down the key components involved in this process:

• The OMA-URI: This is a string representing a custom configuration setting intended for a Windows 10 or newer device. Its precise syntax is determined by the specific CSPs present and active on the client device. Detailed information about the syntax, supported values, and behavior of each CSP can be found in the comprehensive Windows CSP reference documentation provided by Microsoft. Consulting this documentation is mandatory when constructing custom OMA-URIs.
• A Custom Policy: In the context of Microsoft Intune, a custom policy profile is the container used to bundle one or more OMA-URIs that you wish to deploy. You configure this profile within the Intune portal, specifying the OMA-URI string, the data type of the value (e.g., integer, string, boolean), and the actual value you want to set.
• Intune: Once a custom policy containing OMA-URIs is created and assigned to targeted client devices or users, Intune takes on the role of the delivery mechanism. It is responsible for transmitting the configured OMA-URIs from the Intune service to the designated Windows clients. Intune orchestrates this communication process efficiently.
• OMA-DM Protocol: Intune leverages the Open Mobile Alliance Device Management (OMA-DM) protocol to facilitate the communication and policy transfer to the client devices. OMA-DM is a pre-defined industry standard protocol. It uses an XML-based language called SyncML to package and push configuration information, including the OMA-URIs, securely to the client devices.
• CSPs: Upon receiving the SyncML message containing the OMA-URIs from Intune via the OMA-DM protocol, the CSP on the client device becomes active. The relevant CSP reads the received OMA-URI path and the associated value. It then interacts with the Windows platform to apply the configured setting accordingly. This action typically involves operations like adding new registry keys, reading existing values, or modifying current registry entries to enforce the policy.

To encapsulate this workflow: the OMA-URI serves as the specific configuration instruction (the payload). The custom policy profile in Intune acts as the package holding these instructions (the container). Intune is the system responsible for sending this package. The OMA-DM protocol is the method used for transmission, employing SyncML. Finally, the appropriate Windows CSP on the client device interprets the instructions and implements the settings by interacting with the underlying Windows configuration, often through the registry.

This entire process is fundamentally the same mechanism that Intune employs internally to deliver its standard device configuration policies, the ones conveniently available through the graphical user interface. When standard Intune policies are configured, the underlying OMA-URIs and CSP interactions are abstracted away. They are hidden behind user-friendly toggles, text boxes, and dropdown menus within the Intune admin center, making configuration more intuitive for administrators. It is always recommended to utilize the built-in policy settings in Intune whenever they meet your requirements, reserving custom OMA-URI policies for those specific settings that are not otherwise exposed or available through the standard UI templates. Using built-in policies simplifies management and troubleshooting.

To illustrate the concept, consider setting the lock screen image on a device. You can achieve this using Intune’s built-in Device Restrictions policy. Alternatively, you can achieve the identical outcome by deploying a custom OMA-URI policy that directly targets the relevant CSP responsible for lock screen settings. Both methods, though different in configuration approach within Intune, result in the same change being applied on the client device via the underlying CSP mechanism.

OMA-URIs from the Microsoft Intune Admin Center¶

Intune’s built-in policies abstract the complexity of OMA-URIs. For instance, configuring the device lock screen image is done through a simple UI element. You upload an image file, and Intune handles the conversion and delivery via the appropriate CSP path. You don’t need to know the specific OMA-URI or data type; the Intune interface manages it for you. This is the preferred method when a setting is available through the standard templates, simplifying configuration and reducing the chance of syntax errors.

Use a Custom Policy¶

When a setting is not available in the standard Intune templates, you must create a custom policy profile. This requires you to manually specify the OMA-URI path, data type, and value. For example, to set the lock screen image using a custom OMA-URI (this specific setting might be available in the UI, but it serves as a clear example of how a custom policy works), you would find the relevant CSP documentation. The documentation for the Policy CSP - DeviceLock would show the specific OMA-URI path for enforcing a lock screen and logon image.

The path might look something like this (example based on a common pattern, verify with documentation):

./Device/Vendor/MSFT/Policy/Config/DeviceLock/EnforceLockScreenAndLogonImage

After identifying the OMA-URI, you would create a new Custom policy in Intune. You would add a row, paste the OMA-URI path, select the appropriate data type (e.g., String for a path to an image file or a boolean Integer depending on the specific setting and CSP definition), and provide the corresponding value (e.g., the path to the image hosted online, or 1 to enable a setting). This manual process requires careful attention to detail regarding the URI path, data type, and value format as specified in the CSP documentation.

Regardless of whether you configure a setting via a user-friendly built-in policy or a manually constructed custom OMA-URI policy, the end result on the client device is typically identical. The setting is applied through the same underlying CSP mechanism. The choice depends solely on whether Intune’s UI provides a direct method for that specific configuration.

Consider another common configuration area: BitLocker drive encryption. Intune provides extensive built-in policies under Endpoint Security -> Disk encryption to configure BitLocker settings. This allows administrators to easily enforce encryption, configure protectors, manage recovery keys, and set various related parameters through a structured interface.

Use a Custom Policy from the Microsoft Intune Admin Center (BitLocker Example)¶

Using the standard BitLocker policy in Intune involves selecting options from dropdowns and checkboxes, and specifying desired enforcement levels or key storage settings. The Intune UI translates these selections into the necessary OMA-URIs and values behind the scenes, targeting the relevant BitLocker CSPs (like the Policy CSP - BitLocker). This method is highly recommended for BitLocker configuration due to the complexity and interdependencies of the settings involved.

Using a Custom Policy (BitLocker Example)¶

Alternatively, if a specific BitLocker setting existed that was not exposed in the standard BitLocker policy template in Intune, you would need to consult the BitLocker CSP documentation. You would find the specific OMA-URI for that setting, its required data type (e.g., integer, string, boolean), and the accepted values. Then, you would create a custom OMA-URI policy in Intune, manually adding a row with the correct OMA-URI path, data type, and the desired value. For instance, if there was a very granular BitLocker setting not in the UI, its OMA-URI might look something like ./Device/Vendor/MSFT/Policy/Config/BitLocker/SpecificSettingName. You would then provide the appropriate value based on the CSP documentation.

This demonstrates the principle: built-in policies simplify common tasks, while custom OMA-URIs provide the flexibility to configure any setting exposed by a CSP, provided you know the correct URI and parameters.

Relating Custom OMA-URIs to the On-Premises World¶

Organizations transitioning from a traditional on-premises management model primarily relying on Group Policy Objects (GPOs) to a modern cloud-based MDM approach using solutions like Microsoft Intune often need to replicate existing configurations. You can leverage your existing Group Policy settings as a valuable reference point when building your MDM policy configuration strategy. Analyzing your current Group Policy environment is highly recommended as a preparatory step for migrating devices to MDM management. This analysis helps identify which existing policies are necessary to maintain and how they map to MDM equivalents.

The MDM Migration Analysis Tool (MMAT) is a helpful utility designed for this purpose. It analyzes the Group Policies applied to a targeted user or computer. Subsequently, it generates a detailed report that assesses the level of support available for each identified policy setting within MDM equivalents, often pointing to the corresponding CSPs or Intune settings. Using MMAT helps streamline the transition by highlighting compatible settings and identifying those that may require alternative approaches or custom configurations via OMA-URIs.

Understanding the conceptual shift from Group Policy to MDM policies is crucial for a successful transition. While both aim to configure device settings, their architecture, delivery mechanisms, and processing on the client are fundamentally different.

Here’s a comparative look at key aspects of Group Policy in the on-premises world versus MDM policies in the cloud:

On-premises (Group Policy)	Cloud (MDM Policy - Intune)
Group Policy Objects (GPOs)	MDM Configuration Policies (including Custom OMA-URIs)
Domain Controllers host GPOs	MDM Service (Intune Service) hosts policies
Sysvol folder stores GPO files (.gpo)	Intune database/backend services store policy data
Client-Side Extensions (CSEs) process GPOs on the client	Configuration Service Providers (CSPs) process MDM policies on the client
Server Message Block (SMB) protocol often used for GPO file access	HTTPS protocol used for secure communication and policy delivery
.pol files and .ini files are typical inputs processed by CSEs	SyncML (XML-based) is the common input format processed by CSPs

This table highlights the core differences in how policies are stored, delivered, and processed. In the MDM world, the entire process relies on secure HTTPS communication between the Intune service and the client, with CSPs directly applying configurations, often driven by OMA-URI instructions delivered via SyncML messages. This modern approach offers advantages in managing devices outside the traditional corporate network boundary without requiring VPN connections for policy application.

Important Notes on Policy Behavior¶

When managing settings via MDM, especially using custom OMA-URIs, it is important to be aware that policy behavior upon removal can differ from the behavior typically observed with Group Policy. If a policy configuration is modified on the MDM server (Intune), the updated policy is pushed to the device during the next sync cycle. The corresponding setting on the device is then configured to the new value as intended. However, a crucial distinction is that removing the assignment of an MDM policy profile from a user or device security group, or even deleting the policy profile itself from Intune, does not universally revert the configured setting on the client device back to its default value or a neutral state.

The behavior upon policy removal is controlled by each individual CSP. Some CSPs are designed to revert settings when the MDM policy that configured them is removed; this is often the case for profiles like Wi-Fi configurations, VPN profiles, certificate deployments, and email account setups. When the profile is removed, the CSP cleans up the corresponding settings. However, many CSPs, particularly those related to operating system features and security settings, are designed to leave the last configured value in place even after the policy is removed. This is often referred to as a “tattooing” effect, similar to some Group Policy preferences. Because this behavior is CSP-specific, it is imperative to understand the expected behavior of the CSP you are using by consulting the Windows CSP reference documentation. Knowing how a CSP behaves upon policy removal is essential for correctly planning your configuration deployments and ensuring desired outcomes when policies are modified or retired.

Put It All Together¶

Deploying a custom OMA-URI to target and configure a specific CSP setting on a Windows device using Microsoft Intune follows a structured process. The core requirement is the creation of a custom configuration policy within the Intune admin center. This policy serves as the vehicle for delivering your specific, non-UI-exposed settings to the target endpoints.

Within the custom policy profile, you must define the specific OMA-URI path that points to the desired setting within the relevant CSP on the client device. You also need to specify the exact value you want to apply to that setting. This value could be used to enable a feature, disable a function, modify a configuration parameter, or potentially delete a previously configured value (though deletion behavior depends heavily on the CSP). The policy definition requires careful attention to the OMA-URI string, the data type of the value (e.g., integer, string, boolean, XML, etc.), and the format of the value itself, all of which are detailed in the Windows CSP documentation.

For example, adding a setting involves:
1. Clicking “Add” to create a new row in the custom policy.
2. Providing a descriptive name for the setting.
3. Pasting the exact OMA-URI path (e.g., ./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName).
4. Selecting the correct Data type as specified by the CSP (e.g., String, Integer, Boolean, XML, Date/time, Base64).
5. Entering the Value that corresponds to the Data type and the desired state for the setting (e.g., 1 for enabled, 0 for disabled, a specific string value, an XML payload).

After the custom policy profile is created and contains all the necessary OMA-URI settings, the final step is to assign it. You must assign the policy to one or more security groups containing the users or devices that you intend to target with these configurations. Once assigned, Intune will process the assignment and push the custom policy configuration down to the members of the targeted group during their next sync cycle. The client device will then use the OMA-DM protocol to receive the policy, and the relevant CSPs will process the OMA-URIs to apply the configured settings.

Troubleshoot¶

Troubleshooting custom OMA-URI policies can sometimes be challenging, but most issues tend to fall into one of two primary categories. Either the custom policy configuration, containing the OMA-URI, failed to successfully reach the client device from Intune, or the policy did reach the device, but the expected configuration behavior was not observed for some reason. Systematically investigating these two possibilities is key to resolving deployment problems.

If you encounter a custom policy that is not working as anticipated on a target device, the first crucial verification step is to confirm whether the policy configuration actually made its way to the client. There are a couple of primary locations on the Windows client device where you can check logs to verify the delivery and processing of MDM policies, including custom OMA-URI profiles. These logs provide insights into the communication between the device and the MDM service.

MDM Diagnostic Logs¶

One of the most valuable resources for troubleshooting MDM policy delivery is the MDM diagnostic report. This report can be generated on the client device and provides a snapshot of the MDM configuration, including applied policies and sync status. Generating this report is typically done via the Settings app (Accounts -> Access work or school -> Select the account -> Info -> Create report). Reviewing this report can confirm if the custom policy was received and processed by the MDM client component on the device. Look for mentions of the policy name or the specific OMA-URI paths.

The Windows Event Log¶

The Windows Event Log is another critical source of information. MDM activity, including policy reception and CSP processing, is logged here. Specifically, the Applications and Services Logs -> Microsoft -> Windows -> DeviceManagement-Enterprise-Diagnostic-Provider -> Admin log channel is where you will find detailed events related to MDM policy application, processing successes, and failures. You should filter or search this log for events around the time the policy should have been applied. Look for specific event IDs related to policy configuration or errors. Searching for the OMA-URI string or a portion of the policy name in the event details can help pinpoint relevant entries.

Both the MDM diagnostic report and the relevant Windows event log channel should contain references to your custom policy profile or the specific OMA-URI settings you are attempting to deploy if the policy was successfully delivered to the device. If you review these logs and do not see any mention or processing attempt related to your custom policy or the specific OMA-URI string, it strongly indicates that the policy configuration did not reach the client device. In this scenario, focus your troubleshooting on the Intune assignment and policy configuration itself. Verify that the custom policy is correctly configured (correct OMA-URI syntax, data type, value) and that it is assigned to the appropriate security group containing the target device or user. Ensure the device has successfully synced with Intune recently.

If the logs do show that the policy reached the device and was processed (e.g., CSP received the command), but the expected behavior or setting change is still not observed, the issue likely lies in how the CSP interpreted the OMA-URI or value, or there might be a conflict with another policy or local setting. In this case, double-check the exact OMA-URI syntax, data type, and value against the official Windows CSP documentation for that specific setting. Ensure there are no typos or incorrect parameters. Sometimes, the issue could be related to policy precedence (e.g., a conflicting setting applied via Group Policy or another MDM policy, though MDM policies generally take precedence over Group Policy for co-managed devices) or environmental factors on the device preventing the CSP from applying the setting.

• Conceptual Diagram of MDM Policy Flow:
  mermaid graph LR A[Intune Admin Center] --> B(Custom Policy Profile); B --> C{Policy Assignment to<br/>Security Group}; C --> D[Intune Service]; D --> E{OMA-DM Protocol<br/>SyncML}; E --> F[Windows Client Device]; F --> G{DeviceManagement-Enterprise-<br/>Diagnostic-Provider}; G --> H[Configuration Service Providers<br/>(CSPs)]; H --> I[Windows OS<br/>Registry/Settings]; F --> J[MDM Diagnostic Report]; F --> K[Windows Event Log]; subgraph Troubleshooting J K end
  This diagram illustrates the flow from creating the policy in Intune to its application on the client device via CSPs, highlighting the points relevant for troubleshooting (MDM logs and Event Log).

Please feel free to leave any comments or questions below regarding your experiences with Intune custom OMA-URI policies, CSPs, or the transition from Group Policy. Your insights and troubleshooting tips could be valuable to others navigating these configurations.