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.

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

    Reply
  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?

    Reply
  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!

    Reply
    • 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

      Reply
  4. 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

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

    Reply
    • 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

      Reply
  6. 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?

    Reply
    • 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

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

    Reply
  8. 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

    Reply
  9. 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.

    Reply
  10. 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.

    Reply
  11. 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

    Reply
  12. @ 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:

    Reply
  13. @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” /]

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

    Reply
  15. 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

    Reply
  16. Hi Peter,

    Arjan was able to direct me to the correct string. However, I get the following error when I deploy the policy.

    -2016281112 Remediation failed

    I notice that Intune has the option to import the ADMX files using the String (XML file) but neither could I get it to import or if this is the new/correct way to add ADMX files.

    Thoughts?

    Reply
  17. Hi Peter,

    Thanks so much for putting this together – it’s been incredibly helpful in figuring out how to use Intune to enforce Chrome policies for my company.

    Unfortunately, like Nathan and Owen above, I need to be able to push Chrome extensions via the ExtensionInstallForcelist policy, but Intune gives unhelpful failure errors whenever I try, because I can’t find any documentation on how to assign the value in the required “list of strings” format.

    The Chromium documentation on “Complex policies on Windows” is the most useful thing I’ve found, showing how you can pass JSON values as strings for the required “list of strings” format: https://www.chromium.org/administrators/complex-policies-on-windows

    Reply
  18. Sorry for the late reply. The setting is not working. I have tried all builds from 1703 an up. Same results.

    Reply
  19. Hi Peter,

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

    With String value

    But It will not deploy as other settings will, can you tell what the string vaule must be for setting a homepage?

    Reply
  20. @Greg Turnbull, It really is disappointing that PS scripts only work on user based and not devices, I hope next updated on Intune allows to use this. Do you happen to have a copy of your PS script on how to install Chrome and copy master preferences files? We currently have it where we install a customize version of Chrome with the homepage built into the MSI for Kiosk mode but we cannot get it to run in full screen mode. Maybe your solution might help instead. Thanks

    Reply
  21. @Nathan, @Owen
    Were you able to define ExtensionInstallForceList policy? I tried to write such OMA-URI string, but it is not recognized by Intune with error -2016281112 (Remediation failed)

    OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallForcelist
    type:String
    Value:

    Reply
  22. Peter,
    I found policy defined in , e.g or are both not working
    e.g
    OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/IncognitoModeAvailability
    data type: string
    Value:
    Intune reports error -2016281112 (Remediation failed)

    no IncognitoModeAvailability policy is written to registry.
    Do you know what’s wrong?
    I followed your colleague arjan’s blog at https://vroege.biz/?p=3939#comment-17841, the example L_UpdateBranch in his blog is not working either.
    thanks

    Reply
  23. 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

    Reply
  24. 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:

    Reply
  25. 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?

    Reply
    • 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

      Reply
  26. 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….

    Reply
  27. 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? 🙂

    Reply
  28. 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.

    Reply
  29. 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?

    Reply
    • 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

      Reply
  30. 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

    Reply
  31. 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).

    Reply
  32. 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

    Reply
  33. 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!

    Reply
  34. 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).

    Reply
  35. 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:

    Reply
    • 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

      Reply
      • 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:

        Reply
  36. 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.

    Reply
  37. 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

    Reply
  38. 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

    Reply
  39. 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.

    Reply
  40. Daniel
    I think you are mixing up a few of the parents, their ADMX isnt exactly user friendly with long strings of numbers for the policy names!

    to set the LogFileKeepingPeriod for example, I think the OMA-URI should be

    ./Device/Vendor/MSFT/Policy/Config/FsLogix~Policy~2594ab6a0d5b818dbbc9ccba35b26929~97b6e6718ceee98f6407c49e21804ebe/LogFileKeepingPeriod

    Data Type String
    Value 180

    Peter – link to the ADMX here if you want to have a look and advise – https://oneschool-my.sharepoint.com/:u:/g/personal/aaron_overington_westmount_school_nz/EdP7sTKDmStDvZ4O7J4SRewBb2RXxEI9EleAXX9M5sgKDA?e=UqbAy7

    Reply

Leave a Comment

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