Deep dive ingesting third-party ADMX-files

A bit more than a week ago I got the suggestion to do a blog post about the ingestion of custom and/or third-party ADMX-files. Not without a reason. The suggestion was triggered by the latest Spectre and Meltdown vulnerabilities and the ability to manage site isolation via policies for Google Chrome. That was enough motivation for me to look into it. In this post I’ll provide an introduction to ingesting ADMX-files, followed by a step-by-step overview of how to ingest custom and/or third-party ADMX-files and how to configure the related settings. As a configuration example I’ll use the manage site isolation setting for Google Chrome. I’ll end this post with showing the configuration result.

Introduction

Starting with Windows 10, version 1703, it’s possible to ingest ADMX-files and to set those ADMX-backed policies for Win32 apps and Desktop Bridge apps, by using Windows 10 MDM. The ADMX-files that define policy information, can be ingested to the device by using OMA-URI. The ingested ADMX-files are then processed into MDM policies. When the ADMX policy settings are ingested, the registry keys, to which each policy is written, are checked so that known system registry keys, or registry keys that are used by existing inbox policies or system components, are not overwritten. This precaution helps to avoid security concerns over opening the entire registry. Currently, the ingested policies are not allowed to write to locations within the System, Software\Microsoft, and Software\Policies\Microsoft keys, except for the locations documented here.

Configuration

Now let’s have a look at the configuration. The configuration contains two important steps. The first step is to ingest the ADMX-file and the second step is to configure the required setting. I will configure both settings on the device level.

Step 1: Ingest the ADMX-file

The first step is to ingest the ADMX-file. As this post is using Google Chrome as an example, make sure to download the Chrome policies here. Before starting with ingesting this ADMX-file, it’s important to first construct the OMA-URI setting and value.

Setting

The OMA-URI should look like this ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid or AdmxFileName}. In this URI the following variables should be provided:

AppName: This should be the name of the app that will be configured, but can theoretically be anything. In this example I’ll use Chrome;
SettingType: This should always be policy with ingesting ADMX-files. So, in this example I’ll use Policy;
FileUid or AdmxFileName: This should be the name of the ADMX-file, but can theoretically be anything. In this example I’ll use ChromeADMX.

Value

The value is a lot easier. That’s simply the content of the downloaded chrome.admx, which is available in the folder policy_templates\windows\admx. So, to make this really simple, open chrome.admx in an editor and press Ctrl+A, followed by Ctrl+C.

Configuration

Now let’s put the OMA-URI setting and value together, in Microsoft Intune, in a Device configuration profile. To do this, simply follow the three steps below and keep in mind that the OMA-URI setting (step 3b) is nothing more than just putting together the variables as mentioned in the Setting section.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

MSI_DC_CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Windows 10 – Chrome configuration;
  • Description: (Optional);
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b;
3b

MSI_DC_AddRowOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Chrome ADMX Ingestion;
  • Description: (Optional);
  • OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx;
  • Data type: Select String;
  • Value: [Complete content of the chrome.admx];

Step 2: Configure the required setting

The second step is to configure the required setting. Finding the correct values for configuring the required setting, is similar to finding the correct values for any other ADMX-backed policy. So, make sure to be familiar with my post about Deep dive configuring Windows 10 ADMX-backed policies. Before starting with the configuration, it’s important to first construct the OMA-URI setting and value.

Setting

The OMA-URI should look like this ./Device/Vendor/MSFT/Policy/Config/{AppName}~{SettingType}~{CategoryPathFromADMX}/{SettingFromADMX}. Make sure to pay attention to the use of tildes in this URI. In this URI the following variables should be provided:

AppName: This should be the name of the app, as configured with the ingestion of the ADMX-file. In this example I used Chrome;
SettingType: This should be the same as configured with the ingestion of the ADMX-file. In this example I used Policy;
Chrome_CatCategoryPathFromADMX: This should be the complete category path, which actually starts with number 3 in the picture below. That shows googlechrome as the parent category. That category should be followed until the category definition of the ADMX-file, as shown with number 1 in the picture on the right. Number 2 in that same picture, shows that there is no additional parent category;
Chrome_SettingSettingFromADMX: This should be the name of the setting, which is shown with number 2 in the picture on the right. That shows SitePerProcess as the actual name of the setting. Number 2 in that same picture shows the actual registry that will be configured and which we can use to verify the result.

Value

The value is again a lot easier. In this example I simply want to enable the policy, which can be done by using <enabled/>. For more complicated settings, refer to my earlier mentioned post.

Configuration

Now let’s put the OMA-URI setting and value together, in Microsoft Intune, in the previously created Device configuration profile. To do this, simply follow the four steps below and assign the profile to an user group. Just like with ingesting the ADMX-file, keep in mind that the OMA-URI setting (step 4) is nothing more than just putting together the variables as mentioned in the Setting section.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;;
2 On the Devices configuration – Profiles blade, select the earlier created Windows 10 – Chrome configuration profile to open the Windows 10 – Chrome configuration blade;
3 On the Windows 10 – Chrome configuration blade, select Properties > Settings to open the Custom OMA-URI Settings blade;
4

MSI_DC_AddRow1On the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK on the Custom OMA-URI blade and Save on the Windows 10 – Chrome configuration blade);

  • Name: Chrome – ADMX – SitePerProcess;
  • Description: (Optional);
  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/SitePerProcess;
  • Data type: Select String;
  • Value: <enabled/>;

Result

Let’s end this post with the result of the device configuration. The easiest location to look for a success would be Google Chrome itself, but instead I would like to show that the configuration actually arrived on the device. Below on the left is a screenshot of the Settings panel (Accounts > Access work or school > {tenant} > Info). That screenshot clearly shows the custom policy of Chrome~Policy~googlechrome. The applied custom policy doesn’t get any clearer than that. Below on the right is a screenshot of the Registry Editor. That screenshot clearly show the applied configuration, which can be matched with the registry setting in the ADMX-file (see number 2 in the picture with SettingFromADMX).

Chrome_Settings Chrome_Registry

More information

For more information about ingesting ADMX-files, refer to this article Win32 and Desktop Bridge app policy configuration.

132 thoughts on “Deep dive ingesting third-party ADMX-files”

  1. Hi Guy’s! Configuring the RestoreOnStartup and RestoreOnStartupURLs doesn’t seem to work for me. I Always get a -2016281112 (Remediation failed) for these 2 values. It looks like they are still correct..

    Any idea? Does the order of the oma-uri’s matter?

    Thank you,
    John

    Reply
  2. Hello,
    I try to apply:
    ./Device/Vendor/MSFT/Policy/Config/GoogleChrome~Policy~googlechrome~ContentSettings/LegacySameSiteCookieBehaviorEnabled
    ./Device/Vendor/MSFT/Policy/Config/GoogleChrome~Policy~googlechrome~ContentSettings/LegacySameSiteCookieBehaviorEnabledForDomainList
    But values should be Integer, any advice how to set this up?

    Reply
      • Hello Peter,

        Thanks, there was some trick, but I manage to deploy it:

        1. First, in the registry created as Integer, but should be set in policy as a string
        2. Second, created as a string in registry and also created as a string in policy

        Name: LegacySameSiteCookieBehaviorEnabled

        OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~ContentSettings

        STRING: /LegacySameSiteCookieBehaviorEnabled

        NAME: LegacySameSiteCookieBehaviorEnabledForDomainList

        OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~ContentSettings/LegacySameSiteCookieBehaviorEnabledForDomainList

        STRING:

        Reply
  3. Hello Peter,

    I am trying to get the Google Chrome Same Site Policy working, but it always end up with the remediation error:

    Name: LegacySameSiteCookieBehaviorEnabledForDomainList

    OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~ContentSettings/LegacySameSiteCookieBehaviorEnabledForDomainList

    Data type: String

    Value:

    I also tried (without the backslashs \):

    I already tried different solutions without success. Do you ever get this working?

    Thank you!

    Note: admx file is imported successfully. We are already deploying settings successfully.

    Reply
  4. Hi,
    how can configure OMA-URI to set a proxy server on Chrome?

    OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Proxy
    type: string

    Value= ???

    thanks
    Francesco

    Reply
  5. Hi,

    Can someone help me? I have a problem with this setting:
    Pol_TargetVersionPrefixGears

    OMA_URI: ./Device/Vendor/MSFT/Policy/Config/GoogleUpdate~Policy~Cat_GoogleUpdate~Cat_Applications~Cat_GoogleChrome

    Data type: String

    Value:
    ./Device/Vendor/MSFT/Policy/Config/GoogleUpdate~Policy~Cat_GoogleUpdate~Cat_Applications~Cat_GoogleChrome

    …and it’s not working. It should be this setting:
    https://getadmx.com/?Category=GoogleUpdate&Policy=Google.Policies.Update::Pol_TargetVersionPrefixGoogleChrome

    Other settings for Google updates are working, so admx was ingestion successful, I think

    Reply
  6. Hi

    If there is no standard ADMX file and I create a custom one. Should I be able to deploy this in the same manner? I have created a custom ADMX file (very simple). This allowed me to deploy my setting. I’ve also deployed the ADMX file but when I try to configure I keep getting an Event ID 404

    MDM ConfigurationManager: Command failure status. Configuration Source ID: (E04564B5-4F5E-4685-95AA-4E2D847DC851), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (Policy), Command Type: (Add: from Replace or Add), CSP URI: (./User/Vendor/MSFT/Policy/Config/My_Outook~Policy~OutlookRenderforMonitorDPI/RenderForMonitorDpi), Result: (The system cannot find the file specified.).

    I’m guessing its my references to what is in the ADMX file but not sure where I am going wrong. This is the custom ADMX file

    Reply
      • Hi Peter
        Thanks for your reply. When you say deploy the ADMX file. Do I need to deliver the actual ADMX file to the client, if so which path? I did the ingest element and and that seems to have worked. I can see this in the registry. I wondered if I had to send the file to the device or if I had my ‘names’ incorrect in referencing the elements of the ADMX file.
        Its a great article, I think I’m just making hard work of it ?

        Thanks

        Jacqui

        Reply
        • Hi Jacqui,
          I was referring to what I explained as step 1 that you need to ingest the ADMX-file. That will make sure that the content of the ADMX-file will become available on the device. When you’ve not done that, you will receive an error message that the file cannot be found.
          Regards, Peter

          Reply
  7. Hi

    I started again from scratch and its still not working.

    As far as I am aware I have ingested the ADMX file. If I check the registry I have I have
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxDefault\E04564B5-4F5E-4685-95AA-4E2D847DC851\TestADMX~Policy~OutlookRenderforMonitorDPI . Under here there is subkey RenderForMonitorDpi and within this the settings for the registry key I want to amend. I’m assuming these are correct.

    I also have

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled\E04564B5-4F5E-4685-95AA-4E2D847DC851\TestADMX

    and under this

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled\E04564B5-4F5E-4685-95AA-4E2D847DC851\TestADMX\Policy\TestAdmx

    I still get the error file not found.

    This is the ADMX file I created

    I’m wondering if I’m getting my OMA-URI elements mixed up. This is the part I am questioning myself about….

    Any help appreciated ?

    Thanks

    Reply

Leave a Reply to Peter van der Woude Cancel reply

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