Quick tip: Easy method for constructing settings of ingested ADMX-files

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.

  1. 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.
  1. 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.
  1. 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).
  1. 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.

6 thoughts on “Quick tip: Easy method for constructing settings of ingested ADMX-files”

  1. 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.

  2. 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.

  3. i wanted to control the auto update and entered the oma-uri for citrix workspace as

    with the value of

    it failed – below is a truncated list of the admx policy, what did i miss???












Leave a Comment

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