Ninja cat knows OMA-URI

Understanding OMA-URI and ADMX Ingestion for MEM Intune

Intune is great for a lot of things, but is lacking some of the basic configuration options that Group Policies bring to the table.

UPDATE: Administrative Templates in Intune now make most Group Policy Templates available with a few clicks. Read more here:

But for some time now it has been possible to take almost any ADMX file, and ingest it into the Intune management engine.

This is however not for the faint of heart!

So it’s up to the community to share as many useful ADMX Ingestion / OMA-URI “conversions” as possible.

Being heavily inspired by Oliver Kieselbachs work in this area, I decided to embark on my own greenfield ADMX Ingestion, aiming at Outlook 2016/2019/365 silent configuration (first run only).

One might say that, this is is easily done via PowerShell – creating a property in HKey_Current_User: Software \Policies \Microsoft \Office \16.0 \Outlook \AutoDiscover
called ZeroConfigExchangeOnce and setting its value to 1.

But that leaves a lot to be wanted traceability wise in the devicemanagement portal.

So I started off by reading the official documentation on the subject, which btw is excellent!

I decided that I could do this (and so can you!) – So I headed on over to the download center, and got my self a fresh copy of the Office ADMX files, which you should also do now, if you want to be a fricking ADMX ingesting ninja!

If you want to stay here (please do), I have the Outlook ADMX (Outlk16.admx) file as a GIST in my Github repo.

Ok, so now let’s do this!

Creating an ADMX backed policy in Intune

With your confusing XML based ADMX file in hand, head on over to the device management portal, and create a shiny new device configuration policy.

Intune Device Configuration Profile

Steps: Click “Device configuration”. Click “Profiles”. Click “Create profile”.


In the appearing “Device configuration profile” Blade, fill out the fields in sequence like so:

Intune Profile Properties
Outlook Silent Config

Configures Outlook based on UPN or Mail attribute from AD

Windows 10 and later

Profile type:

Steps: Fill out with info from above. Click on “Settings” to begin the dirty work…

First part is easy, ingest the ADMX, by adding a custom OMA-URI.

Intune Custom OMA-URI Settings

Steps: Click “Add”.


Ingesting the ADMX file

In the appearing “Edit Row” blade, fill out the fields in sequence like so:

Intune Editing Row for OMA-URI
ADMX Ingestion - Outlk16.admx

Loads the Outlk16 ADMX template


Data type:


Steps: Fill out with info from above. Click the blue “Ok” button at the bottom of the blade.

Now let’s take a short knowledge break!

(or skip to the next heading if you just want the juice!)

A few things to note about the OMA-URI…

Up until the ADMXInstall/ part, it’s just how it HAS to be. After that we have the Outlk16/ part, this is a custom app name, which could just as well be called myApp, but it’s important later on, so I choose to set it as the admx name for convenience (it shows up in the logs and other places).

The Policy/ part, defines the setting type, and since this is a Policy (as stated in the ADMX file), we leave it at that.

The last part Outlk16Admx, is the filename including it’s extension – this could be a fileUid also, and I can’t really tell if it plays a huge importance, as changing it makes no difference.

So /Outlk16/Policy/ is really the important bits to remember here, as they play an important role in using the settings in the ADMX file we are ingesting/installing.

Ok, lets continue…

Using the ingested ADMX

Now, lets add another OMA-URI by clicking the blue “Add” button at the top of the active blade.

Intune Custom OMA-URI

Steps: Click “Add”.


Now we are ready to tell Intune how to use the settings in the ADMX file we just ingested.

In the appearing “Edit Row” blade, fill out the fields in sequence like so:

Intune OMA-URI Settings Edit Row
ADMX Setting - ZeroConfigExchangeOnce

Configures Outlook to do a silent config only once


Data type: 


Steps: Fill out with info from above. Click the blue “Ok” button at the bottom of the current AND next blade. Click on the blue “Save” disk icon.

THAT’S IT! – Don’t forget to assign the policy to some users/devices!

But Wait! How the hell did you come up with that whole fudged-up OMA-URI?“, you ask…

Time for more knowledge sharing (hell yeah!)

Well that was also my question when I was reading other blogs and documentation.

Turns out, it’s not really that hard to gather what to write there in order to hit a specific setting within the Group Policy…

The first part is easy ./User/, this indicates that this is a user policy, which you can tell within the ADMX XML, if you search for the setting you want to hit (typically a registry key of some sort).

Here you would find the value class=“user” in the <policy …> tag area. Had it said machine instead, you would have to put in ./Device/ instead of ./User/.

Next up we have /Vendor/MSFT/Policy/Config/ which is always what you put in, according to my experience, and the documentation I have read, so let’s keep it that way (a part of the OMA-URI standard I guess).

Then comes the part where one might get lost/confused/blind/what?…


Looks nasty… But there is a very logical structure to this, and the map is in the OMA-URI that we used to ingest the ADMX with, and the original XML of the ADMX file.

Remember the OMA-URI for the AMDX ingestion?

I told you that a few parts of it was important, right?

Well imagine replacing “~” with a “/” in the above OMA-URI – it would look something like this:


Notice, the first part is ripped straight out of the OMA-URI, used to ingest the ADMX! Easy to understand… Maybe.

The next part is like a tree structure, that you “traverse in reverse” (hmm.. that has a nice ring to it.), starting with the actual name of the policy we want to configure, then adding a /, and seperating the policy category names with ~.

So let’s imagine that we want to enable a certain setting from our ADMX – looking at the XML code in notepad (or an actual XML viewer), we do a search for the setting / registry key.

We get a hit on this line:

<policy name=”L_AutomaticallyConfigureProfileBasedOnActiveOnce” class=“User” displayName=“$(string.L_AutomaticallyConfigureProfileBasedOnActiveOnce)” explainText=“$(string.L_AutomaticallyConfigureProfileBasedOnActiveOnceExplain)” key=“software\policies\microsoft\office\16.0\outlook\autodiscover” valueName=”zeroconfigexchangeonce“>

The value of “name” in the policy tag, is the last part of our OMA-URI.

To get the value of the path that precedes it, we need to look at the next line for the parent category, which we will note and follow all the way to the main category.

<parentCategory ref=”L_Exchangesettings” />

Go back a few lines and look at the OMA-URI and see where L_Exchangesettings fit’s in – begining to make sense now?

To get the next category name to put in, let’s scroll all the way up to the top of our XML code, and find the <categories> tag.

Here we will look for L_Exchangesettings category, and find that it also has a parent category, called L_ToolsAccounts, which also needs to be in the OMA-URI string (again, go up a few lines to the OMA-URI, and see where L_ToolsAccounts fit’s in).

And yet again we look a bit further to find that L_ToolsAccounts, ALSO has a parent category named L_MicrosoftOfficeOutlook! (When will it end!?)..

Again, we put L_MicrosoftOfficeOutlook into the OMA-URI and go search for it further up the category ladder…

FINALLY we discover that L_MicrosoftOfficeOutlook is the main category (since it’s category tag is closed with a “/”).

So now we have the complete OMA-URI:


Ready for use in our custom policy!

Thanks for reading!

I really hope this helps you get a better grasp, on ingesting ADMX templates and using them in a policy.

Please feel free to reach out on Twitter (@michael_mardahl) – Questions/feedback/likes/follows are very much appreciated!

Michael Mardahl

Michael Mardahl is a seasoned IT pro with over 25 years of experience under his belt. He's a Microsoft Certified Cloud Architect at APENTO in Denmark, where he helps customers move from traditional infrastructure to the cloud while keeping security top of mind. When he's not working, Michael's either spending time with his family and friends or passionately blogging about Microsoft cloud technology. His expertise in this area has even earned him the prestigious title of Microsoft Most Valuable Professional (MVP) in both the Enterprise Mobility and Security categories. In short, Michael is the IT equivalent of a rockstar, but don't expect him to act like one - he's way too down-to-earth for that.


  • Hi Michael.
    I learned a lot from your advice.
    I’m having a tough time trying to achieve 1 things.

    Automatically changing the Cached Exchange Sync Settings to 1 months.
    The ADMX ingestion seems to work (but with “Remediation” errors), but the policy changes don’t.
    Any guidance would be GREATLY appreciated.

    1.I share the configurations for the ingested ADMX file as below.

    Copy and paste the content from outlk16.admx.

    2. Cached Exchange Sync Settings


    Best regards

    • Hi Yuichi,

      Sorry for the late reply, and I see your comment is missing the important part “the value”.
      Also I suggest getting the latest ADMX version if you have not done so. as the one I have supplied is a few years old and these things change.


Categories use cookies to ensure that we give you the best experience on our website.