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 :

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.

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