HowTo OMA-URI - something not working

[PatrickF11]

Hi folks,

i'm trying to experiment with OMA-URI within custom profiles.

In this Use-case we're trying to achive, that we can manage Google Chrome Updates.

Therefore i've downloaded the GoogleUpdate.admx and ingested it into the Intune custom profile.

This is working, i'm able to see the admx at the clients registry under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled" as well as the corresponding, possible values under ..\PolicyManager\AdmxDefault.

Well, this looks good.

Now i want to add the first setting to the custom profile.

I had a look in ..\PolicyManager\AdmxDefault and found the value "ChromeUpdate~Policy~Cat_GoogleUpdate~Cat_Preferences\Pol_AutoUpdateCheckPeriod".

Afterwards i've build the oma-uri path like this:

./Device/Vendor/MSFT/Policy/Config/ChromeUpdate~Policy~Cat_GoogleUpdate~Cat_Preferences/Pol_AutoUpdateCheckPeriod

What i really don't get:

How to find out what value type (and what spelling) is required?

In this case i think it should be Integer and e.g. 60 (for 60 minutes).

Unfortunatelly this setting is marked as "remediation failed".

[#2]

@PatrickF11 right, now the only supported ADMX backed policies are listed here https://docs.microsoft.com/en-us/windows/client-management/mdm/policies-admx-backed 

[#3]

@Steve Bucci Oh okay, that wonders me.

Currently we're using another ADMX template for configuring Google Chrome itself successfully.
In the past we used another one for configuring OneDrive.

[#4]

@PatrickF11 there are often times where unsupported scenarios work, until they don't.  That is basically what supported/unsupported comes down to: supported=designed to work consistently and unsupported=no design to work consistently.

From the Intune UserVoice there is an article on the mapping for Policy CSP being complete, but not the translation.  This item is on the mapping, with a link to the translation item if you want to upvote. https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/31741903-provide-a-mapping-bet...

[#5]

@PatrickF11 

I assume you have seen this post: https://support.google.com/chrome/a/answer/9102677?hl=en

Unfortunately, there is nothing much else we can do. I would suggest to double check the spelling, if that's all okay, I assume this to be a bug within Google Chrome

[#6]

Hey @PatrickF11,

first of all we need to differentiate a bit the technology used here. There is a ADMX ingestion and a ADMX backed policy which is fairly similar but not identical.

Microsoft uses a technique called ADMX-backed policies. This is a clever move to make important policies shipped with Windows 10 accessible by compiling them into MDM policies during OS-build time.

In addition to that, it is even allowed to ingest new third party ADMX policies and compile them to new MDM policies (e.g. Google Chrome ADMX policies). This allows us and Microsoft to easily make new policies available for MDM configuration.

To dive into that topic I really recommend to carefully read the article here Understanding ADMX-backed policies, which provides great details on the whole process. For custom ADMX ingestion read carefully this article Win32 and Desktop Bridge app policy configuration. 

Regarding your problem we talk about a ADMX ingested policy (Google Chrome) where we are ingesting the ADMX definition and then configure them. This is supported for third party admx files.

Your config will work if you use the following settings:

OMA-URI:
./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/GoogleUpdateAdmx
Value:
your-google-chrome-update-admx

OMA-URI:
./Vendor/MSFT/Policy/Config/Chrome~Policy~Cat_GoogleUpdate~Cat_Preferences/Pol_AutoUpdateCheckPeriod
Value:
<enabled/>
<data id="Part_AutoUpdateCheckPeriod" value="60"/>

Your policy for configuration was slightly wrong it is Chrome~ and not ChromeUpdate~.

👍

best,

Oliver

[#7]

@Steve Bucci Thank you (and the others) for your reply.

So just to be clear: Many custom ADMX Ingestions and configurations should work, but they're not especcially marked as "supported" until they appear in the list of supported ones, right?

@Thijs Lecomte I've read this one. We're already using some of them to configure the chrome browser itself. Now the second step should be the management of updates of the chrome browser. That's why i tried to experiment with the custom admx file and ingested it into intune.

@Oliver Kieselbach Thank you for the provided links, i'm excited to read them.

Please correct me if theres a misunderstanding at my point of view:

1. Ingesting custom ADMX Files and use them to configure some settings is supported and should work. (as in my case: the chrome update for example.)

2. Naming:

Ingesting of an ADMX File:

- How could i have known that i need to name this "chrome" instead of "ChromeUpdate"?

(If i would have known that, i would have used this of course in the setting OMA-URI itself, too)

- You've left away "./Device" in your suggestion. Isn't it neccesary for me?

3. The Ingesting of the ADMX with the choosen name "ChromeUpdate" instead of "Chrome" worked. At least i can see this in the registry. (.\PolicyManager\AdmxInstalled\ChromeUpdates)

Why is this wrong anyway? (I thought that this could be a freely choosen name which should be equal to the name i use in the setting.)

4. How could i found out the proper data type and the value, e.g. when it is a string and not a simple number (integer). In some cases i need something like "</enable>" followed by completely various strings.

Thank you very much for answering my questions and pushing me in the right directions.

Hopefully my questions are not that dumb. 😄 (I'm really interested in understanding this topic, not just making it work through copy&paste)

[#8 · Accepted solution]

@PatrickF11 

1. Ingesting custom ADMX Files and use them to configure some settings is supported and should work. (as in my case: the chrome update for example.)

=> Starting in Windows 10, version 1703, you can import ADMX files (also called ADMX ingestion) and set those ADMX-backed policies for Win32 and Desktop Bridge apps by using Windows 10 Mobile Device Management (MDM) on desktop SKUs. The ADMX files that define policy information can be ingested to your device by using the Policy CSP URI, ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall. The ingested ADMX file is then processed into MDM policies.
https://docs.microsoft.com/en-us/windows/client-management/mdm/win32-and-centennial-app-policy-confi...

2. Naming:

Ingesting of an ADMX File:

- How could i have known that i need to name this "chrome" instead of "ChromeUpdate"?

(If i would have known that, i would have used this of course in the setting OMA-URI itself, too)

- You've left away "./Device" in your suggestion. Isn't it neccesary for me?

=> simply look at the ingested ADMX file and you will see the complete structure and here we have the Chrome~

Sorry slightly different screenshot (chrome policy not googleupdate) but was the one I had currently, same applies to googleupdate of course...

regarding ./Device:

Device scope:

• ./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy.
• ./Device/Vendor/MSFT/Policy/Result/AreaName/PolicyName to get the result.

For device wide configuration the Device/ portion may be omitted from the path, deeming the following paths respectively equivalent:

• ./Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy.
• ./Vendor/MSFT/Policy/Result/AreaName/PolicyName to get the result.

https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider

3. The Ingesting of the ADMX with the choosen name "ChromeUpdate" instead of "Chrome" worked. At least i can see this in the registry. (.\PolicyManager\AdmxInstalled\ChromeUpdates)

Why is this wrong anyway? (I thought that this could be a freely choosen name which should be equal to the name i use in the setting.)

=> Only during the ingestion the name at the end is free to choose, it must not be equal, you could also name it ChromeV2Admx for example. Here I've chosen ChromeAdmx
./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx

It's an ingestion name and does not correlate to the category path from above.

Sorry slightly different screenshot (chrome policy not googleupdate) but was the one I had currently, same applies to googleupdate of course...

4. How could i found out the proper data type and the value, e.g. when it is a string and not a simple number (integer). In some cases i need something like "</enable>" followed by completely various strings.

=> looking at this article: 

Understanding ADMX-backed policies

https://docs.microsoft.com/en-us/windows/client-management/mdm/understanding-admx-backed-policies

there are examples of Decimal Element, Boolean Element, List Elements, Enum, No Element, MultiText Element, Text Element

Thank you very much for answering my questions and pushing me in the right directions.

Hopefully my questions are not that dumb. 😄 (I'm really interested in understanding this topic, not just making it work through copy&paste)

[#9]

@Oliver Kieselbach 

Thank you very much!

1. Okay.

2. At first i've ingested the ChromeUpdate ADMX with this OMA-URI:

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ChromeUpdate/Policy/ChromeUpdateAdmx

The string "ADMXInstall/ChromeUpdate" was choosen by myself, because "Chrome" already exists and i wanted to keep that nice and clean.

After this step (and assigning this policy) i've noticed the ADMX in the registry:

Isn't this correct? (Of course i could have build the OMA-URI as "ADMXInstall/Chrome/Policy/ChromeUpdateAdmx" but i thought, my idea was right.

After i've noticed the registry i've found under "AdmxDefault all of the possible configurations:

That's why i thought, everything is working fine.

For testing purposes i rebuild the OMA-URI to "Google" instead "GoogleUpdate".

Now this appears here: (appears twice, because of earlier assignment)

Why should this be correct and the "ChromeUpdate\Policy\ChromeUpdateAdmx" not?

3. So i'm "allowed" to use this with or without "./Device" Prefix, if its a device wide config?

4. Thank you for this article, as said before, i'm going to read through this.

[#10]

@PatrickF11 

Oh, I see you used initially ChromeUpdate (my fault I thought somehow you used Chrome as Appname, maybe I read to fast, sorry):

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ChromeUpdate/Policy/ChromeUpdateAdmx

then you are right, this should work also:

./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ChromeUpdate/Policy/GoogleUpdateAdmx
Value:
your-google-chrome-update-admx

OMA-URI:
./Vendor/MSFT/Policy/Config/ChromeUpdate~Policy~Cat_GoogleUpdate~Cat_Preferences/Pol_AutoUpdateCheckPeriod
Value:
<enabled/>
<data id="Part_AutoUpdateCheckPeriod" value="60"/>

it is defined by:

./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid or AdmxFileName}

https://docs.microsoft.com/en-us/windows/client-management/mdm/win32-and-centennial-app-policy-confi...

3.) So i'm "allowed" to use this with or without "./Device" Prefix, if its a device wide config? => YES

best,

Oliver

[#11]

@Oliver Kieselbach 

Okay, thanks for the confusion. 😄

So nearly everything i thought of first, was right, except the data type and the value.

The current problem is:

When trying to choose data type "string" and the value 

<enabled/>
<data id="Part_AutoUpdateCheckPeriod" value="60"/>

i get an error when saving this configuration:

Unable to save due to invalid data. Update your data then try again: The property 'isReadOnly' does not exist on type 'microsoft.management.services.api.omaSettingString'. Make sure to only use property names that are defined by the type.

Is "id="part_...."" really the correct syntax? Shouldn't it be "id="pol_....""?

As before i'm able to save integer / 60, but as you said this should be the wrong data type & value.

[#12]

Hey @PatrickF11,

I've seen this error just once. I couldn't fix it at that point in time. I've recreated the policy and the error went away. I don't know what caused this and I've never seen the error again. Please try to recreate the complete policy.

best,

Oliver

[#13]

@Oliver Kieselbach 

it has already been sufficient to remove this OMA-URI Setting out of the profile and to re-add it.

Could you please answer my last question belonging the data id?

Thank you very much! You really teached me many things about the OMA-URI Settings. 🙂

[#14]

@PatrickF11 

Sure here we go 🙂

Part_ is correct as we reference the policy decimal element id with that:

    <policy name="Pol_AutoUpdateCheckPeriod" class="Machine"
        displayName="$(string.Pol_AutoUpdateCheckPeriod)"
        explainText="$(string.Explain_AutoUpdateCheckPeriod)"
        presentation="$(presentation.Pol_AutoUpdateCheckPeriod)"
        key="Software\Policies\Google\Update">
      <parentCategory ref="Cat_Preferences" />
      <supportedOn ref="Sup_GoogleUpdate1_2_145_5" />
      <elements>
        <decimal id="Part_AutoUpdateCheckPeriod"
            key="Software\Policies\Google\Update"
            valueName="AutoUpdateCheckPeriodMinutes"
            required="true" minValue="0" maxValue="43200" />
      </elements>
    </policy>

with this value and notation we are referencing the value directly not the policy element

<enabled/>
<data id="Part_AutoUpdateCheckPeriod" value="60"/>

This way the MDM client exactly knows which element in the ADMX file it has to use. Tt can also be the case that an policy definition has more than one element for configuration. That's why we exactly reference the value which configures the setting in the end.

[#15]

@Oliver Kieselbach 

Ladys and Gentlemen: THIS is good support! 🙂

Again: Thank you for all the help.

I really don't know which of your answers i should mark as "best response" 😄

And thanks to all the others. 🙂 I really appreciated it.

[#16]

Hey @Oliver Kieselbach 

there's one last question left open, after i've read through the links recommended by you:

When ingesting an admx, first i have to build the OMA-URI Path.

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/NAME111/Policy/NAME222

In one of your earlier replies you've written, that only "NAME222" is a free to choose name.

After i've read though the articles i think that "NAME111" is also free to choose, when ingesting the admx file.

What i know: When configuring an element i need to use "NAME111" of course like in the following example:

./Device/Vendor/MSFT/Policy/Config/NAME111~Policy~RestOfConfigPath/ConfigItem

And of course: i need to look into the registry (PolicyManager\AdmxDefault\...) to find the correct name for the config. ("RestOfConfigPath")

So referrencing to the Subject "Chrome Update":

I could have build the OMA-URI String for ingesting like i mentioned above, with the freely choosen name (NAME111).

Afterwards i could add configurations like that:

./Device/Vendor/MSFT/Policy/Config/NAME111~Policy~RestOfConfigPathFromRegedit/ConfigItem

Did I summarize that correctly?

So the name "NAME111" doesn't matter at all, it just have to be the same in the "ingesting part" and in the "configuration part" of my custom intune profile, right?

[#17]

@PatrickF11 

that's correct, 

NAME222

is absolutely free and has no consequence other than representation in registry. Often it is wise to use something like your own prefix or a version MyFile or Filev1

NAME111

has to be used in both OMA-URIs that's why it miss understandingly referred to not free to choose. in fact it is free to choose but must be used in both OMA URIs

your summary is correct! 👍 

[#18]

@Oliver Kieselbach 

Great, thank you (again).

[#19]

Hi @PatrickF11 With the help of Oliver you have probably already deployed the policy, otherwise have a look at my article about managing Chrome with intune https://www.inthecloud247.com/manage-google-chrome-settings-with-microsoft-intune/ Maybe it is of any help.

[#20]

@Peter Klapwijk 

Probably your article would have helped, too.

Just a short addition to your article:

You're building the string together while looking inside of the admx file.

Of course, this is working. But it's much easier, after ingesting the admx file, to have a look at the clients registry. (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxDefault\)

At this location, every policy ingested by an admx is listed.