This week a quick extra blog post, just before the start of my vacation, about an easy method for construction settings of ingested ADMX-files. A few years ago I did a post about a deep dive for ingesting third-party ADMX-files and until today I still receive questions on that post that are related to constructing settings of ingested ADMX-files. Even though the described method is still available, there is an easier method for constructing the settings of ingested ADMX-files. A method that is less sensitive to errors. The following four steps walk through that easy method by again using chrome.admx as an example.
- The first step is ingesting the ADMX-file. That can be achieved by following the same steps as provided in my earlier post. After creating the required configuration that contains the content of the ADMX-file, assign the profile to a group with a test device and let Microsoft Intune do its magic.
- While Microsoft Intune is performing its magic on the test device, it’s time to start with the second step. The second step is looking up the setting and the available values in the ADMX-file. Just like my earlier post – to keep it simple – I’m looking at the SitePerProcess setting (see Figure 1). Now instead of going through the ADMX-file to construct a difficult OMA-URI, it’s time to have a look at the test device once Microsoft Intune performed its magic.
Figure 1: Overview of the ADMX-file
- After Microsoft Intune performed its magic, it’s time to start with the third step. The third step is looking up the setting of the ingested ADMX-file in the registry of the test device. Simply navigate to HKLM\SOFTWARE\Microsoft\PolicyManager\ADMXDefault and locate the just ingested ADMX-file. To make life a little bit easier, knowing to parent category can help. Otherwise, just find and locate the SitePerProcess setting. Once the setting is located, the required part of the OMA-URI is available without doing any really difficult steps (see Figure 2).
Figure 2: Overview of the ingested ADMX-file
- The fourth and last step is putting the information together. The OMA-URI of a device-based ingested ADMX-file always starts with ./Device/Vendor/MSFT/Policy/Config. That combined with the information found in the registry of the test device makes ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/SitePerProcess.
I know I should have posted these steps earlier, but I still hope that it will still help administrators around the globe with constructing their OMA-URIs for settings of ingested ADMX-files. For as long as it’s still required.
Hi Peter… Chrome deprecated some policies so I attempted to ingest the latest admx file and found it fails.
It turns out you can’t update the existing policy using the same name (i.e. ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx <– had to use ChromeAdmx88)
This does work to overwrite the existing Chrome policies but it doesn't remove older policies that are no longer valid (i.e. Chrome~Policy~googlechrome~Extensions\ExtensionAllowWhitelist)
I'm concerned this might cause issues in the future which brings me to the question; Do you know how to remove ingested policy definitions? Have you come across this before? Obviously I could wipe it out with a script but curious how you have handled this.
Hi Mark,
Sadly I don’t have a pretty solution for that yet. At this moment third-party ADMX requires (a lot of) effort.
Regards, Peter
I wish they would figure out a way to make Group Policy work in Intune. Ultimately it’s just adding/removing/updating data in the registry. OMA-URI is a mess.
Hi Pete,
At this moment it is what it is. Who knows what the future brings.
Regards, Peter
i wanted to control the auto update and entered the oma-uri for citrix workspace as
./Device/Vendor/MSFT/Policy/Config/Citrix~Policy~ICAClient~AutoUpdate/Policy_EnableAutoUpdatePolicy
with the value of
it failed – below is a truncated list of the admx policy, what did i miss???
True
True
False
True
False
-1
0
1
2
30
The actual value is filtered from the message Nick.
Regards, Peter