OMA-URI Value
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 looked at constructing the OMA-URI path from scratch so that we can begin to pull any setting we want out of the ADMX.
In this part, we will look at the one last critical piece for applying an ADMX backed policy in Intune: constructing the OMA-URI Value. Let's begin!
Data Type
For the Data Type field, you have to chose via a drop down. This isn’t exactly documented well everywhere but I’ve found through experience the Data type for most third party ADMX is almost always “String”.
Simple OMA-URI Value
Now that you have two parts of the three-part puzzle, you just need the last part to get your policy working.
Once again, we should refer to the ADMX file to construct the OMA-URI Value field.
If you look at our sample Google Chrome ADMX again, the SafeBrowsing option used to just be
<enabledValue><decimal value="1"/></enabledValue>
<disabledValue><decimal value="0"/></disabledValue>Which means the policy is either enabled, or disabled. There are no extra options. Refer to the ADMX Backed Policies document, which reads:
"For a Boolean Group Policy, if you select Enabled, the options panel contains no data input fields and the payload of the SyncML is simply <enabled/>"
Meaning if the policy only takes binary options, we can simply enter <enabled/> or <disabled/> in our Value field. For example, the policy to disable Chrome Password Manager policy would look like this:
Advanced OMA-URI Value
What if the policy option wasn't binary? Refer again to the ADMX backed policies documentation which states:
"if there are data input fields in the options panel [in the GPMC], the MDM server must supply this data… For every <text> element and id attribute in the ADMX policy definition, there must be a corresponding <data /> element and id attribute in the payload. The ADMX file drives the policy definition and is required by the MDM server via the SyncML protocol."
This means that for any policy that takes a value that’s more than enabled or disabled, you will need to again look at GPMC or the ADMX file to figure out the value it will accept.
Recall from Part 1, in the new Chrome.admx, SafeBrowsingProtectionLevel setting has expanded from the previous enabled/disabled choices to No Protection (0), Standard Protection (1), and EnhancedProtection (2)
Because this field now accepts nonbinary values, we need to specify the value it will take by specifying the <data/> element.
The data id is the same name as the enum id for the elements. In this case:
<enum id="SafeBrowsingProtectionLevel"...The resulting OMA-URI Settings looks like this:
Complex OMA-URI Value
Now that you're nearly experts, let's look at an even more complex OMA-URI Value field. In this example, we will use SafeBrowsingAllowListDomains.
Refer to the Chrome ADMX:
In this case, we can see that the policy is expecting a “list” element, with the “id” “SafeBrowsingAllowlistDomainsDesc”. Refer to the ADMX Backed Policies document once again (yes you should bookmark this page if you haven't already), this time specifically for the "list" element.
"Each pair is a REG_SZ name/value key. It is best to apply the policy through gpedit.msc (run as Administrator) and go to the registry hive location and see how the list values are stored. This will give you an idea of the way the name/value pairs are stored to express it through SyncML."
This is very good advice, particularly if you're unfamiliar with registry hives. When we apply the setting "SafeBrowsingAllowlistDomainsDesc" via regular Group Policy we can see the name/value pairs that are stored in the registry.
So this is the format you’re working towards. We will use these pairs of domains for testing.
1 – sifr.ca
2 – sifrconsulting.com
3 – microsoft.com In NotePad, simply type these out in a single line, with spaces in between like this:
As per the documentation, we will separate the SyncML format by the Unicode character 0xF000 (encoded version ) <- pay special attention to the semi colon ";" at the end.
So, go ahead and replace very single space with the encoded Unicode character above. When you're done, your list should look like this:
Putting it all together, your Value string for the OMA-URI should look like this:
<enabled/><data id="SafeBrowsingAllowlistDomainsDesc" value="1sifr.ca2sifrconsulting.com3microsoft.com"/>
When the policy is applied via Intune, you’ll see it populate the registry as you would expect.
User or Device?
An interesting note if you haven’t noticed: in our GPO test, the registry hive that's populated is HKCU, whereas the final Intune policy populated the HKLM. If you’ve managed Group Policies before, you should be very familiar with the User and the Computer scope of the policies.
In Intune, this is actually defined by the scope tag that appears at the beginning of the URI.
./Device/
./User/So how do we know which scope tag to use? We can again refer to the ADMX by looking at the ADMX file. In this case, SafeBrowsingAllowlistDomains is indicated as "Both", which means it can be either a user or a computer policy.
So if we modify our Intune settings to ./User/ and apply the policy, we can see this properly populates the HKCU node.
For the skeptics out there, here's a screenshot from Intune that shows both Device and User settings can be successfully applied for this policy.
If the ADMX says class="User" as per the example below, the scope tag will be "user".
If the ADXM (unhelpfully) says class="Machine", as in the example below, the scope tag will be "device". Yes, I realize that there are three separate ways of referring to a computer - Machine, Device, or Computer. While I want to blame Microsoft on their terminology, I suspect the "device" scope tag was because SyncML was an MDM standard, as in Mobile Device Management.
You can refer to the ADMX backed policies document, for additional data types and how to format them for SyncML to construct the Value field.
One last point of note is that Intune policies are a bit different than Group Policy in the way the scopes are applicable. If you're familiar with Group Policy, you'll remember that applying a User policy setting to a Device OU wa pointless. Similarly, applying a Computer policy to an User OU was also pointless (unless you have a loopback).
Intune doesn't work like that. You absolutely can assign a user policy to All Devices. If you do, it will apply the policy to the device and doesn't follow the user. Similarly, you can apply computer policies to users. If you do, the settings will apply to all computers the assigned user logs on to. So, it really depends on what your end goal is. For more details on policy assignment, refer to the Microsoft article here.
Next time, we will go over how to troubleshoot Intune configuration policies. Be sure to follow us on LinkedIn to make sure you don't miss it 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.