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.

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

  1. Hi Peter,

    Did you ever get a reply from Yining as to the value of the setting? I am also getting the critical failure issue for any list type value for chrome.

    Example:
    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallBlacklist

    Value:

    Thanks

  2. Now I’m seeing a -2016281112 (Remediation Failed) error when trying to ingest the chrome.admx file by following Google’s official instructions under Step 1 at https://support.google.com/chrome/a/answer/9102677

    The actual policy settings show up under chrome://policy for specific policies I’ve applied, but they’re not being enforced, maybe because the ADMX isn’t properly ingested.

    Here’s an example anyway in case it’s helpful:

    Name:
    Chrome – ADMX – ExtensionInstallForcelist

    Description:
    Extension Forcelist

    OMA-URI:
    ./User/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallForcelist

    Type:
    String

    Value:

  3. Has anyone tried to set the Homepagelocation policy to see if it works with Intune on a non AD domain join pc? Even though Google now has instructions on how to install the ADMX, some of their policies you still cannot be set because of this “This policy is not available on Windows instances that are not joined to a Microsoft® Active Directory® domain.”

    @peter, have you been able to test this or have a work around for setting homepage?

  4. Hi Daniel,

    No, I haven’t tested that specific setting yet. If it really requires a domain, it makes sense that it’s not possible. Another method you could try would be PowerShell (when you know the registry key).

    Regards, Peter

  5. Hello
    Anyone got any ideas on how to get the wildcard (*) to work with the ExtensionInstallBlacklist setting? I can get all other settings I want working after following the excellent Chrome writeup https://support.google.com/chrome/a/answer/9102677 , just not this one. We use it to stop students installing extensions (they quickly worked out that a VPN extension gets around some web filtering!). I have tried an asterisk by itself as the value, inside single quotes, double quotes, square brackets and round brackets but it always fails. And naturally it isn’t one of the examples….

  6. Hello Peter

    I had a couple of beers to lubricate the brain and realised that the ExtensionInstallBlacklist (and other extension settings) nest under the Extension branch – added that to the OMA-URI and it worked. Now looks like this:
    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallBlacklist

  7. Thanks for posting this how-to.

    Question: has anyone gotten the ‘URLs to open on startup’ setting working? If so, can you please post up your settings? 🙂

  8. I can confirm the 4 OMA-URI’s referenced in the above Spiceworks post do work, successfully set a Chrome homepage yesterday

  9. Hi Peter, thank you for this incredible resource! I’m new to Intune, but thanks to your posts, things are mostly going well. The only thing I’m stuck on is the ExtensionInstallForcelist. It looks perfect to me so I’m not sure why it isn’t working, but it’s throwing errors in Event Viewer and isn’t applying. All other policies are working great however!

    P.S. I substituted “[” for “<" so the post wouldn't be rejected by the site here.

    Here's what I have (I've tried both Device and User):

    OMA-URI:
    ./User/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallForcelist

    Data type:
    String

    Value:
    [enabled/]

    [data id=''ExtensionInstallForcelistDesc'' value=''1pallmgdilapjoclholbgammidhdjlmhe;https://clients2.google.com/service/update2/crx2ioalpmibngobedobkmbhgmadaphocjdn;https://clients2.google.com/service/update2/crx''/]

    Here is what's showing in Event Viewer:

    MDM ConfigurationManager: Command failure status. Configuration Source ID: (CD1E156D-68E2-4790-900A-EC7243071B57), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (Policy), Command Type: (Add: from Replace or Add), CSP URI: (./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallForcelist), Result: (Unspecified error).

    MDM PolicyManager: Set policy string, Policy: (ExtensionInstallForcelist), Area: (Chrome~Policy~googlechrome~Extensions), EnrollmentID requesting set: (CD1E156D-68E2-4790-900A-EC7243071B57), Current User: (Device), String: ([enabled/][data id=''ExtensionInstallForcelistDesc'' value=''1pallmgdilapjoclholbgammidhdjlmhe;https://clients2.google.com/service/update2/crx2ioalpmibngobedobkmbhgmadaphocjdn;https://clients2.google.com/service/update2/crx''/]), Enrollment Type: (0x6), Scope: (0x0), Result:(0x80004005) Unspecified error.

  10. Hello Peter,

    I believe Aaron might be following this/or similar post (https://www.imab.dk/install-google-chrome-extensions-using-microsoft-intune/?unapproved=10456&moderation-hash=35e896758af85cd892d07735962abd2c#comment-10456). Values are needed for multiple extension installation in one go.

    Same policy worked fine for me, till I wanted to check how you can then remove them. After I ran script via Intune to delete values for HKLM reg key – ExtensionInstallForcelist, I am now not able to reprovision same extension with same profile on the same devices. Anyone got idea why? OMA URI needs to be updated maybe?

  11. Hi Janis,
    I though the value in Aaron his post had a separate line. Regarding your question. The MDM settings currently doesn’t reapply after a “manual” change. An update to should trigger it again.
    Regards, Peter

  12. I have a follow-up question to Aaron Overington’s comment from Jan. 19th, as nothing I’ve tried has worked and I haven’t found the right information elsewhere. This is the comment I’m referring to:

    I had a couple of beers to lubricate the brain and realised that the ExtensionInstallBlacklist (and other extension settings) nest under the Extension branch – added that to the OMA-URI and it worked. Now looks like this:
    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallBlacklist

    I have the exact same OMI URI path entered into my custom profile, but the policy still yields a “Remediation failed” error for that setting (the events sent to the Admin log in Event Viewer reveal the same but only give an “unspecified error” as the result).

    All the other Chrome settings that are part of my custom OMA-URI profile are successful except that one. Can anyone here take a look at the String value (pasted below) I’ve used for that setting and let me know if there’s anything I’m missing? I copied the value from the same Google answer Aaron referenced and also tried changing the data id to ExtensionInstallBlacklistDesc (to match what was listed in the Chrome ADMX file), but neither has worked:

    Thank you,
    Brandon Cruz

  13. I also could not get anything related to the extension policies to work (others work fine). I went through the comments which suggested that the correct OMA-URI is something like this:

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

    For the string value: (substituted < with [)

    [enabled/]
    [data id="ExtensionInstallBlacklist" value="1&#F000;*"/]

    The example above uses the exact values shown in Google's official documentation here:
    https://support.google.com/chrome/a/answer/9102677?hl=en

    Except that Google did not include the ~Extensions part, which I assumed was an error after reading the comments here. Unfortunately, even with the ~Extensions bit added, the policy still does not work for me. Intune's error message is:

    -2016281112 (Remediation failed)

    WIndows Event Log shows:Result:

    (Unspecified error).

  14. Hopefully this post will help other admins who spent hours trying to debug why their Extensions related Chrome admx policies are not working.

    Simply put, the “ExtensionInstallBlacklist” example in Google’s “Manage Chrome Browser with Microsoft Intune” documentation screwed us big time because it contained not one, but THREE errors!

    1. The OMA-URI needs to be
    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallBlacklist
    Google’s example missed the ~Extensions part, thanks to Aaron for pointing this out in the earlier comment section.

    2. The data ID needs to be ExtensionInstallBlacklistDesc, not ExtensionInstallBlacklist as written in Google’s example

    3. The data value in Google’s example had a typo: it misses a “x” in the separator &#xF000, so for that blacklist example, it should to be 1* not 1&#F000;*

    Follow the same format for the other extension related policies such as ExtensionInstallWhitelist and ExtensionInstallForcelist. Note that for the blacklist and whitelist, only the extension IDs are needed in the value. For the forcelist, you need to specify the update URL as well, in the format of 1yourextensionid;https://clients2.google.com/service/update2/crx

    Like me, you probably copied and pasted Google’s example right into your Intune policy and then wondered why it doesn’t work. Then your Googling led you to this blog and some of the earlier comments and you were like “Oh this must be why…” —only to find it still does not work, because you fixed one part but not the others. How could we have thought that Google gave us THREE, not just one error, in a single example! That typo in the separator string is the final piece that took me 2 hours to notice.

    Regards,
    Mike Qu

  15. I apologize–I must have forgotten to paste the line. Here’s the string value:

    Thank you!

  16. Disgregard, I figured it out. It’s working now.

    This string value, which Google posted in their answer page on the subject (https://support.google.com/chrome/a/answer/9102677) is wrong:

    Here’s the correct value:

    I’d previously tried swapping the “ExtensionInstallBlacklist” with “ExtensionInstallBlacklistDesc”, but I also forgot to add the ‘x’ (in front of the first array value) that was missing from Google’s documentation. Now that I’ve made that change and resynced the client with InTune, the client’s registry was updated accordingly, and users are blocked from installing extensions.

    In the same Example from that answer page, Google also listed the wrong OMA_URI path, as Aaron Overington pointed out in his earlier comment. I just submitted a comment to that answer page, so hopefully, someone at Google fixes it.

    Thanks, Peter, for following up!

  17. Thank you, Mike! Your comment wasn’t showing up the page by the time I made my last post, so I only read it this morning. Also, for some odd reason, the string I copied from InTune and pasted didn’t show up either (that, or I just forgot again :-P).

  18. Hi Peter,

    I’m trying to mimic this same behavior with Firefox using their admx templates. Do you have any experience doing this? Any possible tips would help me out. I’m driving myself crazy trying to get this to work. Firefox admx templates are here https://github.com/mozilla/policy-templates/releases

    Below are the settings I am using
    ADMX ingest OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/MozillaFirefox/Policy/FirefoxADMX

    policy OMA-URI: ./Device/Vendor/MSFT/Policy/Config/MozillaFirefox~Policy~firefox~Homepage/HomepageURL
    value:

  19. Hi Andy,
    I haven’t been able to look into the ADMX files yet. Can you provide any more details about the settings that you’re using and what behavior you’re seeing?
    Regards, Peter

  20. Hey Peter, Thanks for the reply.

    I’ve ingested the admx using the following information:
    OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/MozillaFirefox/Policy/FirefoxADMX
    Data type: string
    Value: [found here: https://github.com/mozilla/policy-templates/releases%5D

    I’ve tried a couple different policy settings, including HomepageURL, HomepageStartPage, and DontCheckDefaultBrowser. Both HomepageStartPage and DontCheckDefaultBrowser I’ve seen the registry key carry down to my test machine and work as intended. But I cannot seem to figure out the correct OMA-URI for the HomepageURL. As the key is never created for it. Below is the information I am using. I’ve tried a couple different combinations of “Homepage” and “HomepageURL” in the OMA-URI.

    Not Working:
    Name: HomepageURL
    OMA-URI: ./Device/Vendor/MSFT/Policy/Config/MozillaFirefox~Policy~firefox~Homepage/URL
    Data type: string
    Value:

    Working:
    Name: DontCheckDefaultBrowser
    OMA-URI: ./Device/Vendor/MSFT/Policy/Config/MozillaFirefox~Policy~firefox/DontCheckDefaultBrowser
    Data type: string
    Value:

  21. Seems Google changed the ADMX structure, ever since I’ve been unable to set the “HomepageLocation” and “RestoreOnStartupURLs” via Intune. Other policies work as expected.

  22. John, just use powershell to change these settings. I never got ADMX to work in our environment

  23. Peter, Sorry to bother you as I know you are busy. Something seems to have changed. I tried to ingest the new chrome admx template Chrome v. 77.0.3865.90. I followed your instructions to the letter (Step 1 substeps 1 thru 3b). I have tried 3 times to just ingest the admx template (not even forcing any oma-uri settings) Every time i get this failure in Azure Intune.
    ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx
    -2016281112 (Remediation failed) 0x87d1fde8 Remediation failed

    Any suggestions you have would be appreciated.
    Thanks Lee

  24. For those trying to set the Homepage with these instructions, the path in the admx file has changed. You have to use the following OMA-URI’s to set the Homepage in the Intune profile after Ingesting the latest admx from Google.
    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/HomepageLocation
    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/HomepageIsNewTabPage
    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/RestoreOnStartup
    ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/RestoreOnStartupURLs

  25. Hi Peter,

    Can you maybe help with the following?
    I want to use ADMX Ingestion for FSLogix. I ingested the FSLogix ADMX, and can find it back in the registry of the clients, so far so good.
    After that I’m trying to set the policies, like this one:

    This policy has a lot of “parent objects” so I include them all:

    OMA-URI: ./Device/Vendor/MSFT/Policy/Config/FsLogix~Policy~2594ab6a0d5b818dbbc9ccba35b26929~d7b8a9babaaedbc7b58034d8ef9da5da/3e8dbd1d3a320d148f1e7566638fb96c

    Data type: String
    Value:

    Also I tried:
    Data type: Boolean
    Value: True

    The logs still show a “Command failure status” and in Intune a Remediation failed.

Leave a Comment

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