Forum Discussion
Solved
HowTo OMA-URI - something not working
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 GoogleUp...
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-configuration2. 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/ChromeAdmxIt'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)
sbuccimsft 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)
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-configuration
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)
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/ChromeUpdateAdmxThe 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.
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/ChromeUpdateAdmxthen you are right, this should work also:
./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ChromeUpdate/Policy/GoogleUpdateAdmx
Value:
your-google-chrome-update-admxOMA-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}3.) So i'm "allowed" to use this with or without "./Device" Prefix, if its a device wide config? => YES
best,
Oliver
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.
