ADMX Ingestion with Intune

As Intune is still “developing” and more and more features are added almost on a monthly base (which by the way still amazes me every time), sometimes the customer demands customization which cannot be satisfied “out-of-the-box”

These can be settings which we easily handled via GPO in the “good old times”. Mostly using existing ADMX Templates or by setting the registry keys via GPO Preferences.

In Intune and modern management this is indeed different. So basically Intune and other MDM solutions rely on the Open Mobile Alliance Device Management (OMA-DM) protocol to exchange data using XML-based (SyncML) format. On the clients  Configuration Service Providers (CSPs)  process these information and apply restrictions/settings to the device accordingly.

What are CSPs ?

“CSPs are similar to Group Policy client-side extensions, in that they provide an interface to read, set, modify, or delete configuration settings for a given feature. Typically, these settings map to registry keys, files or permissions.”

https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/how-it-pros-can-use-configuration-service-providers

There are a lot of CSPs which are baked into Windows 10, depending on the windows 10 edition and version. Here a complete list of available CSPs and in which edition and build they are available. https://docs.microsoft.com/en-us/windows/client-management/mdm/configuration-service-provider-reference

Intune Device configuration profiles, for example, address these CSP directly via OMA-URI’s (Open Mobile Alliance – Uniform Resource Identifier). It is possible that not all CSP are configurable via Intune UI. So if you are missing settings in the UI it might is worth a look in the CSP reference to check if the provider can be addressed via custom policy. There you can address the CSP via OMA-URI and configure it.

But what do you do when you cannot address the CSP directly?

One solution might be ingesting ADMX files via the Policy CSP. This is supported since Windows 10 (1703) and allows importing of settings and processing them into new so called ADMX-backed policies. Policy CSP Documentation -> https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider

ADMX-backed policies rely on the metadata of (well-known) ADMX templates. This is, by the way, the mechanism which is used by Intune Device configuration policies administrative templates regarding Edge and Office settings (surprise).

The Documentation for ADMX backed policies is quite good https://docs.microsoft.com/en-us/windows/client-management/mdm/understanding-admx-backed-policies

So why should I care?

I stumbled upon a customers request for disabling a applications pop-up for users. This is a kind of no brainer, since it is just a registry key in the HKCU hive, back in the days by using GPO-preferences (if there aren’t ADMX templates available)  or even during application installation if you have a decent software deployment tool (e.g. ConfigMgr). For sure this can also be managed by Intune e.g. deploying customized Applications or running a script which sets the key.

But IMHO the modern approach would be using the Policy CSP for that task. And during testing we determined the CSP approach much more reliable than using scripts.

So, how do we do that?

Knowing the above we take advantage of the Policy CSP and ingest an ADMX template. If we are lucky then there is already an ADMX template we can ingest otherwise we have to create one ourselves.

Creating an ADMX file is more complicated that creating an ADM file and convert it, so the first step would be creating an ADM file with the necessary adjustments. Let’s keep it simple

This is a very simple construct defining a user policy.

After creating the ADM file we can verify it on a test machine by importing the template into the local group policy editor (gpedit.msc)

• 

• 

• 

You can see how the configuration resembles our basic ADM template. If we enable this policy we can see that the registry key is set accordingly

After that we use the ADMX editor to convert the file into a more or less decent ADMX. This is an ADMX we can ingest via the policy CSP. With a little help from Microsoft and the ADMX Migrator https://www.microsoft.com/en-us/download/details.aspx?id=15058 you can transform your ADM to and ADMX. Of course you can skip this if you want to write an ADMX yourself

According syntax reference can be found here http://download.microsoft.com/download/5/0/8/5081217f-4a2a-470e-a7fa-5976e40b0839/Group%20Policy%20ADMX%20Syntax%20Reference%20Guide.doc

After installing ADMX migrator start a CMD as administrator and change directory to the ADMX install directory. use the converter -> faAdmxconv.exe old.adm new.admx

During transformation there is one warning that the “supported on” attribute is not configure – IMHO we can ignore that. The resulting ADMX template is quite more complex than the ADM file.

you might want to replace the target prefix and namespace to something more recognizable. But keep in mind that the namespace must be unique.

Upload !

We can now upload this ADMX as a custom policy. According to the documentation the OMA-URI must be in the following format

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid or AdmxFileName}

The {AppName} should be something some you would recognize. In this example we choose “CUSTOM1”. The {Settingtype} is “Policy” since we are ingesting and ADMX template. The last portion {FileUid or AdmxFileName} is supposed to be something unique, we take “MYCustomPolicy”. In the End the OMA-URI looks like this

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/CUSTOM1/Policy/MYCustomPolicy

As value we copy the complete content of the ADMX template. After that we create the policy and assign it to a test group.

In the registry the changes are reflected under HKLM\Software\Microsoft\PolicyManager\ADMXInstalled you can see that the Policy was successfully ingested. Of course you can see that in Intune as well.

• 

• 

If we now want to configure the settings we have to address the corresponding OMA-URI for this setting and set its value. But how do we get the correct path? Since the ADMX is ingested successfully we can take the OMA-URI from the registry. If there is an error you have to check the eventlog for more details.

Under HKLM\Software\Microsoft\PolicyManager\ADMXDefault we will find our ingested ADMX.

We can extract the OMA-URI from the registry or we can sum it up from the information from the ADMX file. It is documented, that the OMA-URI has to be

  ‚./{user or device}/Vendor/MSFT/Policy/Config/{AreaName}/{PolicyName}

The policy {AreaName} format is {AppName}~{SettingType}~{CategoryPathFromAdmx} .So in our case it has to begin with ./User since we know already it’s adding a registry key in the HKCU hive of the registry (it is in the ADMX template as well).

Adding everything up we are ending with the following OMA-URI

./User/Vendor/MSFT/Policy/Config/CUSTOM1~Policy~Custom_Policy/DoSomething

We take the same policy an add another OMA-URI setting. The Data type is string and the value is <enabled/>. This way the key gets set

In Intune we will see if the settings apply successfully and we can double check on the client.

• 

• 

Keep in mind that settings will not get removed once the policy is not applied anymore and that ingesting ADMX files, especially from 3rd party vendors, is complicated, risky and needs good testing.