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.

33 thoughts on “Deep dive ingesting third-party ADMX-files

  1. Hi Peter, very good post. Can you confirm Google Chrome respects the settings ? I have tested this before and also saw the registry keys in place, but Google Chrome did not pickup the settings.

  2. Hi Peter,
    I have read your and Oliver blog about ingest ADMX extensively but i try to understand how to get the {CategoryPathFromADMX}

    In the ADMX file you search the policy you want to set, in your case search for ‘SitePerProcess’ in the ADMX file.
    Look for valuename=”SitePerProcess” and make not of the ‘parentCategory ref’ , in this case it is ‘googlechrome’
    Then go to the top of the ADMX file to the ‘category displayname’ sections.
    Search between the ‘category displayname’ entries for a entry with the name=”googlechrome”

    Q1) Is this the correct oma-uri for dummies method 🙂 ?

    Q2) You mention “Number 2 in that same picture, shows that there is no additional parent category;”. How do you determine there is no additional parent category? In the screenshot i see

    [category displayName=”$(string.googlechrome)” name=”googlechrome”][parentCategory ref=”Google:Cat_Google”/]

    To me it looks like there is a parent Category “Google:Cat_Google” or am i incorrect?

  3. Thank you for this. My question is related to the Chrome.ADMX- can a policy have more than one category? For example, the actual policy I’m attempting to set is

    According to this, the parent category is “Homepage”. But at the top of the .admx, it reads:

    To me that indicates the parent category of the “Homepage” category is “googlechrome”.

    So would I construct my policy like

    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/Homepage/HomepageLocation

    or

    ./Device/Vendor/MSFT/Policy/Config/CHrome~Policy~Homepage/HomepageLocation

    Thank you!

  4. Hi Steve,
    Yes, a policy can have a chain of categories. In that case you should construct it like this: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Homepage/HomepageLocation
    Regards, Peter

  5. Hi Peter,
    I’m trying to set the set of pages that open when Chrome is started using OMA-URI
    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~RestoreOnStartupGroup/RestoreOnStartup
    with the string value

    but it seems that whenever I try to use a subcategory like this, the setting doesn’t show in the registry whereas the policies without a subcategory are visible there.
    Do you know if I’m doing anything wrong?

    Thanks!

    Regards,
    Roland

  6. Oops the brackets don’t work here, the string value I used is:
    [enabled/][data id=”RestoreOnStartup” value=”4″/]

  7. Hi Roland,
    I’ve just successfully tested that specific setting. I initially got an error on that setting, but that was related to the quotes in the value. Not sure if that’s what you pasted, or what my blog made of it. Anyway, I’ve successfully tested that specific setting on Windows 10, version 1709.
    Regards, Peter

  8. Hello,

    I am currently encountering the exact same problem with setting a list of startup URLs:

    My ADMX install OMA-URI
    ./Device/Vender/MSFT/ConfigOperations/ADMXInstall/GoogleChrome/Policy/chromeADMX1

    The ADMX seems to be getting pushed correctly.

    My OMA-URI:
    ./Device/Vendor/MSFT/Policy/Config/GoogleChrome~Policy~googlechrome~RestoreOnStartupGroup/RestoreOnStartup

    My String value (really String, not String (XML-File), as it wont accept that, saying its malformed):
    [enabled/][data id=”RestoreOnStartup” value=”4″/]

    Windows Eventlog tells me an unspecified for the CSP URI.

    Any pointers?

  9. I managed to get the RestoreOnStartup setting pushed down.

    Now running into a “Catastrophic failure” when actually setting the URL list.

    OMA-URI:
    ./Device/Vendor/MSFT/Policy/Config/GoogleChrome~Policy~googlechrome~RestoreOnStartupGroup/RestoreOnStartupURLs

    Value:
    [enabled/][data id=”RestoreOnStartupURLsDesc” value=”http://a.com;https://c.com“/]

    Any thoughts would be much appreciated.

  10. Did anyone get the chrome home page to work.
    The setting applied in the registry however chrome doesn’t seem to respect it.
    I tried setting it both as device and as user setting.
    Thanks

  11. Hi Dennis,
    The configuration looks fine. I only noticed with copying your lines that the quotes (“) were not correct. I used exactly the same and the configuration reflected in the registry.
    Regards, Peter

  12. Peter, you’re awesome. Thanks for this.

    We use password injection for many apps via Azure AD single sign-on. This has assisted me to disable Password Manager which has been remembering injected passwords.

  13. Has anyone had any luck setting a Homepage URL?

    It is applying in registry, but I suspect this is the cause:

    This policy is not available on Windows instances that are not joined to a Microsoft® Active Directory® domain.

  14. Hi Nathan.
    I’m having the same problem with the home page. The setting applies in the registry, however Google chrome does not recognise it. I have a suspicion it might be because the workstation is not joined to a on-premise domain. My other thought was whether it has to be a combination of settings for the home page to work. As the moment (until I can get back to it) I am using a PowerShell script to install chrome and at the same time copying the master preferences file (to set home page and other settings) using an azure blob. That seems to work except you can only target intune psscripts it to users (not devices) from what I can see and what I have read in the forums. If you need more info let me know.
    Greg

  15. @ Greg – cheers for that, I’ve also parked that one for now.

    @ Peter – would you be able to provide some guidance on force installing chrome extensions?

    I’m using:

    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallForcelist

    with value:

  16. Hi Nathan,
    I haven’t tested that specific setting yet. I might look into it, but I can’t make any promises (busy times). Are you running into specific issues?
    Regards, Peter

  17. @Nathan Morris

    Did you get the ExtensionInstallForcelist working, I have been trying to get this work and have got catastrophic errors

    have tried the following:

    OMA-URI: ./User/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallForcelist
    Type: STRING
    Value:
    [Enabled/][Data id=”ExtensionInstallForcelistDesc” value=”ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx” /]

  18. Hello Nathan, Owen
    Did you get that going? I have similar issues trying to get ExtensionInstallBlacklist to work….

  19. Hi Peter,

    Thank you so much for this post. It helped me understand how to ingest the ADMX files. However, I would like some direction on the following OMA-URI to disable Outlook 2016 signatures. I believe I configured the settings per your documents correctly but I still receive failures.

    OMA-URI:
    ./Device/Vendor/MSFT/Policy/Config/Outlook2016~Policy~L_MailFormat/disablesignatures

    Data Type: String

    Value:

    Thank you in advance

  20. Hi Peter,

    Here is the original ADMX for Office 2016. For Outlook 2016 there are options to disable signatures and I was not sure if I was pulling the correct information based on your example in this article.

    https://www.microsoft.com/en-us/download/details.aspx?id=49030

    Intune reports that the Per-setting status has succeeded for the outlk12.admx, but failed for disabling the signature.

Leave a Comment