Azure, Custom CSP, Uncategorized

ADMX Backed Policies – Quick(ish) Reference Guide

I check the TechNet Intune forum on a regular basis.  It’s a great way to hear about new topics to explore, raise questions and help others

Recently I saw a post there that described problems when trying to configure Device Setup Class restrictions for Windows 10 via the Configuration Service Provider (CSP). It was clear from the post (and my own struggles with this policy) that some basic ideas around how to best approach ADMX backed policies may help others.

The aim here is to avoid too much technical detail – the excellent  Understanding ADMX Backed Policies will provide a wealth of technical depth if required.  My aim is try to condense that information down into a quick reference guide.

Example Policy Used

For my example I will refer to the settings contained in the following policy:

Computer Configuration\Administrative Templates\System\Device installation\Device Installation Restrictions\Prevent installation of devices using drivers that match these device setup classes

Discovery Phase 1 –  Gpedit and the Registry

First I recommend using Gpedit.msc and then a registry check to gain an insight into the setting you are working with.  The following steps should help you on your way.

  1. Use https://gpsearch.azurewebsites.net to search for your policy, corresponding registry locations and the name of the ADMX file (in my example ‘DeviceInstallation.admx’):

2.  Make the changes in gpedit.msc and observe the new entries created in the registry.  Pay special attention to any entries that you were perhaps not expecting, In the example an entry called ‘DenyDeviceClassesRetroactive’ is created even if we do not check the box to enable this setting:

3. Our example policy also creates a subkey and string values to reflect our device classes:

Discovery Phase 2 – The Policy CSP Reference

We should have enough information now to check the Policy CSP Reference document.

  1.  Visit the Policy CSP Reference URL
  2.  Search the CSP reference for your policy.  In the example case I searched for the keyword “Device” and then found the relevant entry:

3.  Copy the three areas I have highlighted below into Notepad, you will need the information later on:

Discovery Phase 3 – The ADMX file

1.  Open the ADMX file using your favourite xml editor, the file can be found here:

“C:\Windows\PolicyDefinitions\DeviceInstallation.admx”

2.  Search the ADMX file for the ‘GP Name value’ copied from the policy CSP reference – in the example the search phrase is “DeviceInstall_Classes_Deny”

3.  The most important information is contained within the <elements></elements> section – this essentially tells us how to configure the policy for deployment via Intune. Make a note of the XML tags you see here (eg ‘<boolean id=’) and you can then refer to the table below to get an idea of how to create the correct XML in Intune.

4. I wanted to try to summarise all of the possible element types and give examples of each  one – there will be variants on the examples I have used especially with List elements so remember to use gpedit and the registry to help figure out the correct way to express the values in SyncML (best viewed on PC):

Discovery Phase 4 – The OMA-URI

  1. We now need to create the correct OMA-URI entry before we move all of the discovered configuration into Intune.  The key things to find out:
  • Is your policy only applicable to Users?
  • Only applicable to the Computer?
  • Applicable to both Users and Computers?  If so which entity do you want to set this for?

When you copied information from the Policy CSP Reference you will have also noticed it mentions the scope the policy will apply to – the choice you have to make should be obvious:

/User/Vendor/MSFT/Policy/Config/AreaName/PolicyName

or

./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName

2. Copy the first part of the highlighted text in Discovery Phase 2 – The Policy CSP Reference (point 3) – in my case the text to copy is: “DeviceInstallation/PreventInstallationOfMatchingDeviceSetupClasses”

3. Replace the italicised text in the OMA-URI example above to create the required value e.g:

./Device/Vendor/MSFT/Policy/Config/DeviceInstallation/PreventInstallationOfMatchingDeviceSetupClasses

Note: Remember the AreaName and PolicyName values are case sensitive.

Implementing Phase

  1.  Open up the Intune console in Azure and create a new custom Windows 10 Custom Configuration Profile.
  2. Create a new row and give the row a meaningful name and description before pasting in the OMA-URI and XML into the Value box as a String:

3.  Save the policy and assign it to a user/computer or group

4.  Sync the device from settings>Accounts>Info and check the DeviceManagement-Enterprise-Diagnostic-Provider admin log followed by the relevant registry location to ensure the correct settings have been applied.

As a bonus bit of information you can see above that I have had to include a Boolean value as well as the List element.  As I mentioned earlier always check the registry when working with List elements – in this case the tick box shown all the way back in Discovery phase 1 (point 2) must be expressed even if you do not set it but do enable the policy to deny certain device setup classes.  Confusingly if you set the policy as disabled the tick box is expressed for you automatically… took me a while to work this out 😉

That should hopefully help anyone new to ADMX backed policies – good luck.

Finally I wanted to thank MS for creating the Understanding ADMX Backed Polices guide and also Sandy’s Blog which really helped me to understand the use of &#xF000;

Thanks for reading and I hope this has been helpful.

Some sites for further reading/reference:

Understanding ADMC backed Policies

Policy CSP Reference

Use Intune Policy CSP manage Windows 10 settings – Internet Explorer Site to Zone Assignment List

Intune: Deploying ADMX-Backed policies using Microsoft Intune

5 thoughts on “ADMX Backed Policies – Quick(ish) Reference Guide

  1. Hi Carl,

    For someone new to Intune and trying to get to grips with managing a new raft of Win 10 PCs without any training, this was a very succint and useful article (especially after reading the in depth Understanding ADMX article above)

  2. Hi Carl,

    Thanks for your blog labour, it’s really useful. I was wondering if you could comment on:

    1) Adding additional OMA-URI settings to a Device Configuration Profile that has already been assigned and deployed to the client
    2) Modifying values of already deployed DCPs

    I have been testing with the Office suite of ADMX ingested settings – settings are applied successfully when the system is fresh but any subsequent attempts to add or changes values has no effect on the target systems. I don’t feel like ADMX backed policies are a tenable solution if this is the current functionality (please tell me I am doing something wrong? 🙂 )

    Note: I have tested a monolithic style with ADMX ingestion and settings in same DCP and also a split method with ADMX ingestion in it’s own DCP and settings in another – both have the same issue.

    Many thanks,

    Daniel

    1. Hi Dan, as discussed offline with you, the office16.admx file appears to be so large that it causes problems with the CSP on the client, I was able to re-create the same scenario. You solved this by creating a custom office16.admx with just the settings you need – thanks for your comment 😉

Leave a Reply to Carl Barrett Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.