How does a custom set of ADMX-based policies work with Intune

I often get the question “How to deploy a custom set of ADMX-based policies with Intune” In this blog post I will try to describe the workflow on ADMX based policies with Intune – it does not only applies to Intune but also 3 part. MDM solutions as a part of it is how it is working on Windows 10.
I will describe how to do it with a 3. part product that the company I work for has developed – then I’m sure that it is not a native build in to either Windows or Intune,

 

---

The product is called Acting Admin and we need to set policies to configure the application – like the same reason I set all other policies.

 

1. First we need to import the ADMX into a custom Intune profile
2. Create the policy settings in the profile (If we do this in the same profile instead of a different one – then we are sure that the ADMX is implemented on the device at the same time as

 

In the Microsoft 365 Device portal – Device Configuration – Profiles

Create a new profile

1. Name: Give it a name “ADMX – Acting Admin”
2. Platform : Select “Windows 10 and later”
3. Profile type: Select “Custom”
4. Click Settings
5. Click Add

Then you are ready to create the policy

1.  Name : “ADMX – Acting Admin”
2. OMA-URI : ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ActingAdmin/Policy/ActingAdmin
3. Data type: String
4. Value: Copy the content of the ADMX file

The OMA-URI string need to go into the policy CSP URI ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Applicationname/Policy/ADMXFileName

./Vendor/MSFT/Policy/Config/ remains the same for all machine polices that you a
The Applicationname and ADMXFileName are user defined, in this case the Applicationname is ActingAdmin and I use the same as ADMXFileName – just remember that the ADMXFilename need to be unique on a device.

Here is the content of the ADMX file in my case – this could also have been Google Chrome, Microsoft Office, Internet Explorer or others

Now you are ready to create a policy setting:

1. Name : isTimeExtendable (I always use the setting name here)
2. OMA-URI : ./Device/Vendor/MSFT/Policy/Config/ActingAdmin~Policy~ActingAdminCategory/IsTimeExtendable
3. Data type: String
4. Value : <enabled/>

Here you can see where I got the information for the last part of the of the OMA-URI IsTime Extendable and the enable value will set the value to 1 in the correct place in the registry.

<policy name=”IsTimeExtendable” class=”Machine” displayName=”$(string.IsTimeExtendable)” explainText=”$(string.IsTimeExtendable_help)” key=”Software\Policies\Atea Global Services\Acting Admin” valueName=”IsTimeExtendable“>
<parentCategory ref=”ActingAdminCategory” />
<supportedOn ref=”windows:SUPPORTED_Windows7″ />
<enabledValue>
<decimal value=”1″ />
</enabledValue>
<disabledValue>
<decimal value=”0″ />
</disabledValue>
</policy>

Now you can create all the setting you need and then assign the profile to the end users.

 

---

What is happening on the client site:

First of all you can see in the settings app that you have a new category in the policies area

Then if you take a closer look in the registry, the first place there are written is :

HKLM\SOFTWARE\MICROSOFT\PolicyManager\AdmxInstalled
The policy is always declared under a GUID and with the name you gave the policy in Intune when you created the policy.

That is when the policy template file is applied:

---

Then you will be able to see naming of the policy category that you are using when creating a policy setting in this case ActingAdmin~Policy~ActingAdminCategory

HKLM\Software\Microsoft\PolicyManager\AdmxDefault

 

 

---

If the policy is a device policy you will be able to see the direct result that are applying to the devices under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device

Again you have the category ActingAdmin~Policy~ActingAdminCategory and you can see what settings are being applied

---

At the end all a policy does on a Windows device is setting som registry keys – and it is the same with MDM policies. All the policy settings goes here:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\

In this case the naming of the policy is Atea Global Services and the sub category is Acting Admin, there is all the setting that I have pushed out from Intune.

This is not working for every ADMX based policy – I have not been able to figure out what is working and what is not.

---

Read more:

Understanding ADMX-backed policies

Win32 and Desktop Bridge app policy configuration