Modern Management

Troubleshooting ADMX Ingestion

Having read the excellent posts from both Oliver Kieselbach  and Peter van der Woude  regarding the ingestion of third party ADMX templates, I decided to implement their suggestions in my test environment.  This emerging area of configuration is where I believe we truly start to add value to devices and users that are modern managed. 

What follows in my very first blog post is my experience with the configuration they both designed…some troubleshooting methods (which should give you a clue on how well this went for me) and finally the steps I took to successfully deploy the OneDrive and Chrome configuration


Part 1 – Chrome ‘SitePerProcess’ Settings

After following Peter’s post I had successfully created the necessary configuration profiles to deliver the ADMX payload and the Chrome settings but as you can see no custom Chrome settings appear in the policy summary screen:

So how do we start to troubleshoot this issue?  Well Microsoft provide some initial pointers to help us via the Troubleshoot CSP custom settings page. For my purposes the most helpful section describes where we can find events of interest in the DeviceManagement-Enterprise-Diagnostic-Provider Event Log (found in Applications and Services Logs > Microsoft > Windows).

On the view tab ensure you have Enabled “Show Analytic and Debug Logs:

Next navigate to the DeviceManagement-Enterprise-Diagnostic-Provider Event Log and open the Admin log:

I filtered the Admin log to show only errors to help me to reduce noise.  After reviewing all of the errors on my device one in particular seemed to be more interesting than the others:

“Cannot find the file specified”  So the ADMX has  not been ingested?….how do we confirm this? Lets try to determine if the payload is reaching my machine and go from there.

By using traditional analysis tools we can begin to uncover what is happening behind the scenes.  Process Explorer can show us that a particular process is triggered each time I press the sync button – the executable being called is “omadmclient.exe”

Lets use Process Monitor to try to find out more about this exe by analysing what happens when I press “sync” and then search the filtered output for “Chrome”.  We can see that the ADMX file has indeed been ingested…so that error earlier that stated that the system “cannot find the file specified” is a lie!?  So what is going wrong?

Lets look more closely at the ingested ADMX via the registry because ProcMon can show us some of the ADMX information but not all of it.

We can easily jump to the specific registry location using ProcMon which should allow us a closer look at the entire ingested ADMX file.  ProcMon told us that the ExpectedValue string found in this key ‘HKLM\Software\Microsoft\Provisioning\NodeCache\CSP\Device\MS DM Server\Nodes\87’ is where the complete ADMX information should be available for us to view.

However…I guess there is a limitation with Regedit in that it cannot show me anything at all for this Value data:

Lets see if PowerShell can grab the compete Ingested ADMX file information from the registry location .  So using a simple one liner we can output the value we have in the registry to a text file and then compare it with the Chrome.admx file from Google:

Get-ItemProperty -Path Registry::”HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\NodeCache\CSP\Device\MS DM Server\Nodes\87″ | Select-Object “ExpectedValue” | Format-List * | Out-File c:\IngestedChromeADMX.txt

Here I used Visual Studio Code to compare the files…and it’s not good  The highlighted lines show the differences and as you can see, there are many:

My error was to use a copy of Chrome.admx that came from the Central Store in my work environment.  It must be out of date and maybe it doesnt contain the SitePerProcess information neccessary to make this configuration valid on the target device..

A search of the ingested ADMX in notepad for “SitePerProcess” confirms this:

Copying the latest Chrome.admx information back into the Custom Windows 10 policy in Intune yields better results:

And finally the registry has the intended value:

So, encouraged by that eventual success, I moved on to configure my device with the OneDrive settings Oliver highlights in his great blog post.


Part 2 – OneDrive Configuration

In this example Oliver has us create our own ADMX file by copying the key parts out of the OneDrive ADMX file.

This time around I got instant success after importing the ADMX, configuring the custom policy and assigning it to my test account:

However Intune reported a problem when I checked the deployment status:

With the OneDrive settings we are importing there are two settings (granted more than two items are listed in the pic).  Intune is telling me that one of them is OK but one of them is not…we have nothing much more at this point to help.

So we return to reviewing DeviceManagement-Enterprise-Diagnostic events again and we see this glaring error:

This tells me I did something wrong when I made my custom ADMX file – and its obvious when we look at the scope I specified in my ADMX when we compare it to configuration in the Windows Custom Profile:

Changing the class for “EnableADAL” to “User” resolved this second problem for me and we can see the value updated in the registry:


Part 3 – Summary

To summarise:

  • Always check the ADMX file you are delivering to the endpoint for ingestion, ensure it actually contains the values you are trying to set!
  • Explore the ‘DeviceManagement-Enterprise-Diagnostic’ event log when you hit problems as it does usually contain some helpful information
  • Double check the scope you have configured in the ADMX 🙂
  • Dont be afraid to fail and most important…dont give up if you do

I hope I have highlighted some ways to help others explore where their issues could lie.

Until next time…

Leave a Reply

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