Forum Discussion
HowTo OMA-URI - something not working
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)
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
