Manage new ADMX Backed Windows 10 policies with Microsoft Intune

Administrative Templates

A lot of companies are moving, or planning to move, their Windows 10 management from on-premises Group Policy Management to MDM solutions like Microsoft Intune. But when moving existing environments to Intune a lot of companies face a (big) gap between the settings which are available in Intune and which are currently managed via GPOs. This prevents a lot of companies to shift their Windows management to Intune for various reasons.

It seems that this customer feedback is heard by Microsoft as they announced support for 647 new MDM policies across 56 ADMX files for the latest Windows 10 Insider Preview Build.

Starting with Windows 10 Insider Preview Build 20175, we have enabled 647 new MDM policies across 56 ADMX files to enable commercial customers to configure policies that are also supported through Group Policies. Contains ADMX based Policies such as App Compat, Event Forwarding, Servicing and Task Scheduler. These new policies can be configured using Intune custom profile. Intune UX is planned to be available later this year.

For now, as written in the Windows blog, we need to use an Intune custom profile to start testing these settings. Support for these new settings, starts with Windows 10 Insider Preview Build 20175.

With this post I hope to help you get started with testing these new enabled MDM policies.
I use two examples from two different ADMX files. One device and one user setting. I show where the required information is found, which we need to collect before we can create these Intune custom profiles. And I show how these custom profiles are created.
I assume that with this two examples and additional information you are able to configure all other new ADMX backed policies yourself.

Microsoft started creating documentation about the new ADMX Settings which can be found on Microsoft Docs.

Which policies are available

The new policies which are made available, are found in the ADMX files which are located on the Windows device in the folder C:\Windows\PolicyDefinitions.

But not all (Windows related) ADMX files found here are supported. To get an overview of the (current) supported settings you can refer to the Windows blog post or create an Advanced Diagnostics Report on a Windows Insider device. The new ADMX backed policies all start with ADMX_.
The last option is probably the most accurate as I assume the number of supported policies will be expanded in the near future in a future Windows release.

How to build up the OMA-URI

Like I showed in previous blogs about managing settings with custom Intune profiles, like the Google Chrome post, a custom profile consists of two required settings. The OMA-URI and the value.

In case of the ADMX backed policies the OMA-URI always starts with ./Device/Vendor/MSFT/Policy/Config or ./User/Vendor/MSFT/Policy/Config. Which depends if it`s a device or user policy.

This is followed by ADMX_admxfilename, for example ADMX_AppCompat. The OMA-URI ends with the Policy name which is found inside the ADMX files.

Let`s open the AppCompat.admx file. In this file, we find all the available settings related to Application Compatibility. As example AppCompatTurnOffUserActionRecord to Turn off Steps Recorder.
Here we also find the class, device in this case, so this is a machine policy.
In this example we also see an enable and disable value, which we need to use later in the value box of the custom policy.


Let`s also open a second file, the CtrlAltDel.admx file. Here we see for the policy DisableTaskMgr that this is a User policy. And there are no additional values that we need to add in the value box of the custom profile later.

With this information we can create the two example OMA-URI`s:

Create custom configuration profile

We have the two example OMA-URIs, time to open the Endpoint Manage admin center to create the custom profile.

  • Choose Windows 10 and later as Platform
  • Choose Custom as Profile
  • Click Create
  • Give the profile a Name
  • Enter a Description (Optional)
  • Click Next
  • Click Add on the Configuration settings tab
  • Give the Row a Name
  • Fill in the OMA-URI: ./Device/Vendor/MSFT/Policy/Config/ADMX_AppCompat/AppCompatTurnOffUserActionRecord
  • Data type: String
  • Value:
<enabled/> <data id="AppCompatTurnOffUserActionRecord" value="1"/>

As you can see the value starts with <enabled/> to enable the policy. As the policy contained two values (enable and disable) the value is expanded with a data ID which is equal to the policy name we found in the ADMX file. This is followed by a value. This is the value 0 or 1 which we also found in the ADMX file.
During my testing with this setting, it made no difference if I set the value to 0 or 1. There might be other policies where this value does make a difference as seen before with manage Google Chrome settings.

Move on to the second example, which is a user policy and didn`t contain additional values in the ADMX file.

  • Click Add
  • Give the Row a Name
  • Fill in the OMA-URI: ./User/Vendor/MSFT/Policy/Config/ADMX_CtrlAltDel/DisableTaskMgr
  • Data type: String
  • Value: <enabled/>
  • Click Add

As you can see we only use <enabled/> to enable the policy setting. No need to enter a data Id and value, as that value isn`t required and found in the ADMX file.
In these two example I enabled the setting, but you might have a policy which need to be set to disabled.
That is accomplished by adding <disabled/> to the value box.

Don`t forget to assign the policy to a security group as soon as all the required settings are added.

The end-result

Let`s have a look at what the end-result is.

Sign-in to a Windows 10 Insider device (Preview Build 20175 or later). The policy which was previously found under the Unmanaged policies in the Advanced Diagnostics Report is now found under Managed Policies.
The AppCompat setting AppCompatTurnOffUserActionRecord with the value we configured is shown.

And also the CtrlAltDel setting DisableTaskMgr is found in the list with the value we set.

Another place to have a look is the registry. The location where the setting is set in the registry, is found in the ADMX file.
In this case, Software\Policies\Microsoft\Windows\AppCompat under HKLM as it`s a device setting. The value to have a look at is DisableUAR.


And indeed, under that registry key we find the configured value DisableUAR.

And the value for the CtrlAltDel setting is found under HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System as it`s an user setting.

And if I press CTRL+ALT+DEL the option to start the TaskManager is removed.

Adding these MDM policies to Windows 10 is a good example that Microsoft takes the feedback of customers serious. Bur of course it`s also in their favor as they like to see companies move there management to the cloud 🙂
I assume the number of available MDM policy settings will be expanded in the near future, as this list of settings probably still doesn`t close the gap for a lot of companies between GPO and cloud Windows 10 management. So we keep an eye on future updates for Windows, but also for Intune as “Intune UX is planned to be available later this year”!

I hope you find this post informative. If something isn`t clear please let me know and I`m happy to help.

Happy testing!

Be the first to comment

Leave a Reply

Your email address will not be published.