• Sijia

Intune: Third-Party ADMX & OMA-URI - Step-by-Step (Part 2)


Welcome back folks! We will continue our deep dive of Intune ADMX backed policies by creating a custom OMA-URI setting from scratch. In Part 1 of this multipart series, we looked at what is OMA-URI, What is SyncML, and how to "ingest" a third party ADMX. If you haven't read it, I would suggest you begin there.

In Part 2, we will look at constructing the OMA-URI path from scratch. Let's begin!


Understandably, you’ll want to apply some settings after the ADMX ingestion. To do this, we will need to construct OMA-URI and Value strings for the OMA-URI setting.

While some vendors and internet searches can provide you with some common strings for this purpose, it is very helpful to know how to construct these fields yourself so that you can apply any settings from the ADMX to suit your specific environment purpose.

We will again be using Google Chrome and Chrome.admx for this example. If you haven't followed along from Part 1, you should download Chrome Enterprise now.

For this example, we want to apply Safe Browsing protection to our corporate browsers. When we reference the Google Chrome Common Settings spreadsheet, we note the setting “SafeBrowsingEnabled” has been deprecated. In fact the spreadsheet hasn’t been updated since 2018 which, in IT years, is basically eons. If we attempt to copy and paste the information from the spreadsheet, we will end up with a failure status in Intune.

When we look at the new Chrome ADMX file, this setting is in fact now called “SafeBrowsingProtectionLevel”. With it, we also have several possible values for this setting.

Chrome ADMX - SafeBrowsingProtectionLevel

To help you construct the OMA-URI, make sure the ADMX has been successfully ingested by your test machine. If it hasn’t, you may want to do so before proceeding further.

As we learned in Part 1, the OMA-URI always follows a common format:


An easy way to figure out the AreaName/PolicyName is to simply look at the path the ADMX file creates in the registry. When an ADMX is ingested, it always appears in the PolicyManager\AdmxDefault node with a unique GUID. (Thinformatics has a very cool article you can read if you’re curious if this works even for a custom ADMX.)

If you had ingested the ADMX from Part 1, you can simply copy/paste the portion after the GUID for the full AreaName/PolicyName (note the slash difference).

However, if you're the adventurous sort, you can construct this path entirely by referring to the ADMX file.

Based on the documentation, the format for AreaName is


In our case, by referencing the ADMX file:

AppName – Chrome

This should be the same name as the AppName portion of your Ingestion OMA-URI from Part 1

SettingType – Policy

This is always either policy or preference, similar to Group Policy Objects.

The {CategoryPathFromAdmx} is derived by traversing the parentCategory parameter separated by the tilde "~" character. If you’re working off of the ADMX file alone, the easiest way is to find the key you’re looking for, then refer to its parentCategory setting and work backwards.

In this case, working backwards we have: