OMA-URI Path
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.
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:
./{Scope}/Vendor/MSFT/Policy/Config/{AreaName}/{PolicyName}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
AppName~SettingType~CategoryPathfromAdmx 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:
SafeBrowsing > googlechrome. So our CategoryPathfromAdmx is googlechrome~SafeBrowsing
Finally, the last element is PolicyName. We can refer to the ADMX in the <policy class> node to find the PolicyName. To make sure we didn’t miss a level, confirm the parentCategory ends at the last step of our CategoryPathfromAdmx attribute. In this case it should say “SafeBrowsing”, which it does.
Putting this all together:
./{Scope}/Vendor/MSFT/Policy/Config/{AreaName}/{PolicyName}We have:
./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~SafeBrowsing/ SafeBrowsingProtectionLevelAgain, it is much easier to copy/paste this path from the registry as it would be properly formatted hierarchically from the ingestion.
TIP: Use a blank notepad file as you work your way through the paths. It's difficult to keep all the path element straight in your head.
NOTE: the OMA-URI field is case sensitive!
In Part 3, we will go over how to construct OMA-URI Value field from scratch. Be sure to follow us on LinkedIn to make sure you don't miss Part 3 of this multipart series when it releases! If you've enjoyed this post, please Like or Share so others can also benefit.
If you're looking for some additional support with managing your corporate devices to support working from home, contact-us, or book a consult today!
The content on this web site is provided for general information purposes only and does not constitute professional advice. Users of this web site are advised to seek specific technical advice by contacting SiFr or their own IT resource regarding any specific technical issues. SiFr does not warrant or guarantee the quality, accuracy or completeness of any information on this web site. The articles published on this web site are current as of their original date of publication, but should not be relied upon as accurate, timely or fit for any particular purpose.
This web site may contain links to third party web sites. Links are provided for convenience only and SiFr does not endorse the information contained in linked web sites nor guarantee its accuracy, timeliness or fitness for a particular purpose.
SiFr is a Microsoft Partner. However, we do not have an affiliate relationship with Microsoft and we do not receive any monetary benefit in commissions or otherwise for clients choosing Microsoft services. We aim to offer unbiased advice based on our own experience with the services.