ADMX Ingestion
Hey! Welcome to Part 1 of a multipart series on Intune device management, specifically: Third-Party ADMX & OMA-URI.
In part 1, we will look at "ingesting", or deploying, a third party ADMX.
There are a lot of posts on the internet that discuss Intune policy, the required OMA-URI format, and Value strings. For common settings, it’s good enough to just copy and paste the settings offered by the posts. However, what if you wanted to work with settings that you couldn’t easily find online? In this multipart series, we will take a deep-dive into working with third-party ADMX files, and constructing the OMA-URI settings from scratch for deployment through Intune.
In this blog example we work primarily with Google Chrome ADMX because Chrome is a commonly used application that administrators wish to manage. If you wish to follow along, you can download the latest Google Chrome Enterprise package, which will include the ADMX templates we will be referring to.
Background Information
Before we get started, some background information will help your overall understanding of this whole process.
What is OMA-URI?
OMA-URI stands for Open Mobile Alliance Uniform Resource Identifier. Open Mobile Alliance attempts to provide an open standard for mobile device management. Information is processed through a language called SyncML which provides the formatting we will need to know in order to process the OMA-URI settings that Intune MDM relies on.
With that out of the way, let’s work on setting our first policy.
Ingest the ADMX
Before you can set any policies on the target machine, you will need to deploy the ADMX templates. In traditional on-premise environments, this was as easy as uploading the ADMX file into the Central Policy Store and accessing the new settings via Administrative Templates.
For Intune, this process is called “ingestion”. The ADMX template will be sent via SyncML through the Policy Configuration Service Provider (CSP) URI. This URI comes in a standard format based on the OMA standard.
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
./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName
Using the documentation provided by Microsoft on CSP, we can see that to install an ADMX we will want to build the URI like this:
./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/Policy/{UniqueID}If we refer back to the Microsoft CSP documentation, we will see the UniqueID element specifies the unique ID of the app ADMX file that contains the policy to import. This is usually the name of the ADMX file. So, putting this all together, to ingest our Chrome ADMX, our OMA-URI will look like this
./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmxFor the Value field, we simply paste in the entire content of the ADMX file as the documentation indicates. Open the ADMX file in Notepad and copy/paste the whole thing into the Value field.
Push this policy down to your test machines by deploying this Intune custom policy to make sure this step successfully completes.
While you can move directly to Part 2 before applying the test policy, doing this first will be helpful as you build the OMA-URI. Trust us.
In Part 2 we will go over how to construct OMA-URI paths from scratch. Be sure to follow us on LinkedIn to make sure you don't miss Part 2 of this multipart series when it releases! If you've enjoyed this post, please Like or Share so others can also benefit.
If you're looking for some additional support with managing your corporate devices to support working from home, contact-us, or book a consult today!
The content on this web site is provided for general information purposes only and does not constitute professional advice. Users of this web site are advised to seek specific technical advice by contacting SiFr or their own IT resource regarding any specific technical issues. SiFr does not warrant or guarantee the quality, accuracy or completeness of any information on this web site. The articles published on this web site are current as of their original date of publication, but should not be relied upon as accurate, timely or fit for any particular purpose.
This web site may contain links to third party web sites. Links are provided for convenience only and SiFr does not endorse the information contained in linked web sites nor guarantee its accuracy, timeliness or fitness for a particular purpose.
SiFr is a Microsoft Partner. However, we do not have an affiliate relationship with Microsoft and we do not receive any monetary benefit in commissions or otherwise for clients choosing Microsoft services. We aim to offer unbiased advice based on our own experience with the services.