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.
- 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.
- Visit the Policy CSP Reference URL
- 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:
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
- 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:
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:
Note: Remember the AreaName and PolicyName values are case sensitive.
- Open up the Intune console in Azure and create a new custom Windows 10 Custom Configuration Profile.
- 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.
Thanks for reading and I hope this has been helpful.
Some sites for further reading/reference: