What are OMA-URIs and CSPs in Intune?
Updated: Jan 5
Table of Contents
A Look Back at Group Policy
Before we dive into the new terminology, I want to summarize what Group Policy is and how it works. Please note that this is a very high-level summary:
Components of the Group Policy Framework
Component | Description |
|---|---|
Group Policy | an individual policy listed within an ADMX file |
Group Policy Objects | the finalized package of settings (group policies) that an administrator configures in the Group Policy Editor; GPOs are saved on Domain Controllers with the .pol file extension and are retrieved by clients |
Group Policy Management Console | the management user interface that allows administrators to manage the GPOs in their environment |
Group Policy Management Editor | the user interface that allows administrators to edit existing or new GPOs; the editor reads the ADMX files and creates a graphical hierarchy of settings available to the administrator to configure |
What is a "Group Policy?"
As mentioned above, a Group Policy is an individual policy listed within an ADMX file. Each policy references a setting or preference that can be configured on a device. Most all group policies are mapped to registry keys and values.
How Does the Group Policy Framework Work?
An admin can create a Group Policy Object using the Group Policy Editor UI which reads all the group policies listed in the device's ADMX files. When that Group Policy Object is saved, it is placed in the SYSVOL folder on the domain controllers for clients to read. On the client side, a CSE (client-side extension) is responsible for applying the group policy changes. Note that there are multiple CSEs (client-side extensions) and each one is a DLL. When you create a GPO, you specify which CSE to designate.
What are CSPs and OMA-URIs?
CSPs
Configuration Service Provider (CSP) is the "framework" on Windows devices that MDMs use to configure them. The CSPs intercept the configurations from the MDM and apply them to the client. CSPs can be viewed as the middleman between the MDM's configurations and the client's current settings. When an MDM sends a configuration profile to a client, the CSP intercepts it, compares it to the current configuration on the device, and applies it if needed.
CSPs expose device configuration settings in Windows client. The CSPs are used by mobile device management (MDM) service providers and are documented in the Configuration Service Provider reference. https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/how-it-pros-can-use-configuration-service-providers
OMA-URIs
OMA-URIs (Open Mobile Alliance URIs) are part of the OMA-DM (Open Mobile Alliance Device Management) standard; they are the OMA-DM standard's way of identifying which setting to configure on a device. OMA-URIs target settings by listing a CSP area and policy. Think of a CSP policy as an individual setting that can be configured on a device and the CSP area as a category of settings.
For example, the following OMA-URI targets the DesktopImageURL CSP policy under the Personalization area, allowing you to specify a URL to an image file to be used as the wallpaper.
./Vendor/MSFT/Personalization/DesktopImageUrlADMX to Policy CSP Conversion
Next, I'd like to review how MDM platforms, like Intune, use the same ADMX files that Group Policy did to configure settings on client devices. Is Intune just like the Group Policy framework? The answer is no, not really. Group Policy relied on ADMX files to know what settings an Administrator could configure. The same ADMX files also had to be on the Group Policy server as each client.
Intune does use ADMX files, but it converts them to the CSP framework. How? See below:
Converting Windows ADMX Files
Windows devices come pre-shipped with the standard Windows ADMX files. Windows automatically "converts" these group policies by mapping them to a Policy CSP area when the OS is built. This "mapping" is created when Windows stores the group policy's metadata file in the Policy CSP store to be referenced later. Now, your MDM of choice can target these “ADMX-backed” policies via an OMA-URI and the Policy CSP.
Windows maps the name and category path of a Group Policy to an MDM policy area and policy name by parsing the associated ADMX file, finding the specified Group Policy, and storing the definition (metadata) in the MDM Policy CSP client store. When the MDM policy contains a SyncML command and the Policy CSP URI, .\[device|user]\vendor\msft\policy\[config|result]\<area>\<policy>, this metadata is referenced and determines which registry keys are set or removed. For a list of ADMX policies supported by MDM, see Policy CSP - ADMX policies. https://learn.microsoft.com/en-us/windows/client-management/understanding-admx-backed-policies#background
What is the Policy CSP?
Remember that Configuration Service Providers (CSPs) are the middleman framework. allowing MDMs to configure devices. There are several different CSPs with one being the Policy CSP. You'll notice that the word "policy" appears in most OMA-URIs. This CSP is where ADMX files are "mapped to" or "ingested into." Remember that Intune does all of this for you. You'll only need to define an OMA-URI if you create a custom configuration profile.
To see all of the Windows "ADMX-backed" policies mapped to a Policy CSP area, click here.
Converting Third-Party ADMX Files
You can also upload third-party ADMX files to Intune, allowing you to create and deploy configuration profiles related to the third-party software. For example, you can ingest Google's or Mozilla's ADMX files into Intune to configure settings for their browsers.
Once you upload the third-party ADMX file to Intune, I believe Intune will do the same thing that Group Policy Editor did; Intune will read these ADMX files and display the configurable settings in its friendly web interface. Intune has to be able to target a Policy CSP in an OMA-URI, so I believe that Intune also "converts" or "maps" each individual group policy within the third-party ADMX file to a Policy CSP policy in the background similar to what will happen when a client ingests the third-party ADMX file.
How the Clients Receive and Convert the Third-Party ADMX files
Once you upload your ADMX file to Intune, Intune will ingest it into your devices using the Policy CSP; Intune will use the following OMA-URI to target the ADMXInstall policy to ingest the ADMX file:
./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstallOnce ingested, the ADMX group policies are "processed into new ADMX-backed policies or preferences." I believe this is the same process as for the preshipped Windows ADMX files; each group policy's metadata file is placed within the Policy CSP store creating a mapping between the third-party's ADMX group policy and the Policy CSP's policy.
By using ADMXInstall, you can add ADMX-backed policies for those Win32 or Desktop Bridge apps that have been added between OS releases. ADMX-backed policies are ingested to your device by using the Policy CSP URI: ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall. https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider#deviceconfigoperationsadmxinstall
How Does Intune Use OMA-URIs and CSPs?
Now that we've reviewed Group Policy, learned about CSPs and OMA-URIs, and discovered how Microsoft converts ADMX files to CSP policies, let's look at how all these things apply to Intune.
Intune provides a very friendly user interface for creating configuration profiles. This online platform provides many "built-in" templates and settings you can easily select and configure. Intune's platform, however, does not have every setting available for you to configure. This is where custom configuration profiles come in. Custom configuration profiles allow you to target the setting you want to configure using an OMA-URI. See the quote from Microsoft below, explaining how not all CSPs are available to configure within your MDM solution's friendly UI:
Most, if not all, CSPs are surfaced through your MDM service....When a CSP is available but isn't explicitly included in your MDM solution, you may be able to make use of the CSP by using OMA-URI settings. https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/how-it-pros-can-use-configuration-service-providers#csps-in-mdm
When you create a custom configuration profile, you tell Intune exactly which setting to configure by specifying an OMA-URI, the setting's value type, and the value itself (see screenshot below). Once ready, Intune will deploy this custom configuration profile to the assigned users/devices. The protocol used to transport this custom configuration profile is the OMA-DM protocol which uses SyncML files to deliver the configuration profile. Once a device receives the profile, the targeted CSP will implement/enforce it.
To summarize: The OMA-URI is the payload, the custom policy is the container, Intune is the delivery mechanism for that container, OMA-DM is the protocol that's used for delivery ["It is a pre-defined standard that uses XML-based SyncML to push the information to the client."], and the Windows CSP reads and applies the settings that are configured in the OMA-URI payload. https://learn.microsoft.com/en-us/troubleshoot/mem/intune/device-configuration/deploy-oma-uris-to-target-csp-via-intune#oma-uris
Example Custom Configuration Profile
For example, if we wanted to use a custom configuration profile to set the desktop image on our computers, we would use the following:
OMA-URI: ./Vendor/MSFT/Personalization/DesktopImageUrl
Data Type: String
Value: the file or HTTP/HTTPS path to an image file
To learn more about custom configuration profiles and how to create them, click the link below:
Cover picture provided by Freepik
