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.
- First we need to import the ADMX into a custom Intune profile
- 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
- Name: Give it a name “ADMX – Acting Admin”
- Platform : Select “Windows 10 and later”
- Profile type: Select “Custom”
- Click Settings
- Click Add
Then you are ready to create the policy
- Name : “ADMX – Acting Admin”
- OMA-URI : ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ActingAdmin/Policy/ActingAdmin
- Data type: String
- 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:
- Name : isTimeExtendable (I always use the setting name here)
- OMA-URI : ./Device/Vendor/MSFT/Policy/Config/ActingAdmin~Policy~ActingAdminCategory/IsTimeExtendable
- Data type: String
- 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″ />
<decimal value=”1″ />
<decimal value=”0″ />
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 :
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
If the policy is a device policy you will be able to see the direct result that are applying to the devices under:
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:
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.