Deep dive ADMX ingestion to configure SilentAccountConfig with OneDrive

Since Windows 10 1703 you can use a feature called ADMX ingestion to extend policy settings in Intune. What it basically does is to parse an ADMX file and build a MDM policy of it. In the end you can configure the ADMX settings via OMA-URIs in Intune.

More details about ADMX ingestion can be read here Win32 and Desktop Bridge app policy configuration.

During the last time I’m working a lot in the field of Modern IT and Modern Workplace. In the Modern Workplace scenario I like to have Windows 10 clients joined to Azure Active Directory and auto enrolled into Intune (preferred as an AutoPilot enrollment). The nice thing here is, the device gets configured right after the Azure Active Directory join. In this scenario we typically configure necessary system settings. In addition to that I want to drive the user experience and I want to present the files in OneDrive without further sign-in by the user. Normally the user needs to sign-in with his email address to accomplish this.


To solve this we need to configure OneDrive to silently setup the user account information from the Windows signed-in user. According the article Use Group Policy to control OneDrive sync client settings we can use the following two registry keys for that:

HKCU\SOFTWARE\Microsoft\OneDrive\EnableADAL=1 (dword)
HKLM\SOFTWARE\Policies\Microsoft\OneDrive\SilentAccountConfig=1 (dword)

As we do not have a native Configuration service provider for OneDrive right now we need to configure these settings via ADMX ingestion policy. We can get the OneDrive ADMX from here:


We need the original OnDrive.admx file as a template and we copy the complete policyDefinitions node to a new file. Then we remove every policy node except the policy node with SilentAccountConfig. As we have no node for EnableADAL in the ADMX file we duplicate policy node SilentAccountConfig as additional node under the policies node. In this new node we rename the attribute values “name” and “valueName” to EnableADAL. As last step we replace SOFTWARE\Policies\Microsoft\OneDrive with SOFTWARE\Microsoft\OneDrive.

The result is the following xml file:

<policyDefinitions xmlns:xsd="" xmlns:xsi="" revision="1.0" schemaVersion="1.0" xmlns="">
 <target prefix="OneDriveNGSC" namespace="Microsoft.Policies.OneDriveNGSC" />
 <using prefix="windows" namespace="Microsoft.Policies.Windows" />
 <resources minRequiredRevision="1.0" />
 <category name="OneDriveNGSC" displayName="$(string.OneDriveNGSCSettingCategory)">
 <parentCategory ref="windows:Software" />
 <policy name="EnableADAL" class="User" displayName="$(string.EnableADAL)" explainText="$(string.EnableADAL_Help)" key="SOFTWARE\Microsoft\OneDrive" valueName="EnableADAL">
 <parentCategory ref="OneDriveNGSC" />
 <supportedOn ref="windows:SUPPORTED_Windows7" />
 <decimal value="1" />
 <decimal value="0" />
 <policy name="SilentAccountConfig" class="Machine" displayName="$(string.SilentAccountConfig)" explainText="$(string.SilentAccountConfig_help)" key="SOFTWARE\Microsoft\OneDrive" valueName="SilentAccountConfig">
 <parentCategory ref="OneDriveNGSC" />
 <supportedOn ref="windows:SUPPORTED_Windows7" />
 <decimal value="1" />
 <decimal value="0" />

Why the replacement of \Policies\ in the registry path?

Excerpt from Win32 and Desktop Bridge app policy configuration (17th of November 2017)

Currently, the ingested policies are not allowed to write to locations within the System, Software\Microsoft, and Software\Policies\Microsoft keys, except for the following locations:

  • software\microsoft\onedrive

Because of this exception we can use SOFTWARE\Microsoft\OneDrive to configure the both keys. EnableADAL is listed under the registry key without \Policies\ but SilentAccountConfig is listed under \Policies\ path. The exceptions are subject to change and Microsoft is constantly adding new paths to it. The following is based on the exceptions available at the time of writing Nov ’17. Before building something by your own go and verify which exceptions are currently available and adapt your strategy accordingly.

The path \Policies\ is based on the group policy technique where the sub key is used to overlap the default settings of an application. For example: SOFTWARE\Policies\Microsoft\OneDrive\SilentAccountConfig will overlap an application setting SOFTWARE\Microsoft\OneDrive\SilentAccountConfig. With the xml file above we target the application setting of OneDrive and not the policy setting of OneDrive (keep in mind the default value of OneDrive is overwritten then).

Why not using the whole OneDrive.admx file without \Policies? I’m not sure which of the settings all work without \Policies\ in the path. It depends on the targeted application. With further testing you may find settings working successfully like SilentAccountConfig with OneDrive. For me it was enough for now to have the EnableADAL and SilentAccountConfig settings configured.

In Intune we configure a Device Configuration Profile for Windows 10 as a Custom policy. We need to construct the OMA-URI for ADMX ingestion as described here: Win32 and Desktop Bridge app policy configuration

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

Device Configuration Profile: ADMX Ingestion – CustomOneDrive.admx

Name: CustomOneDrive.admx
Data type: string
Value: <xml content from above>

The next step is to configure the ADMX ingested settings:

Again we follow the article Win32 and Desktop Bridge app policy configuration. Excerpt how to configure user or device policy:

In the policy class, the attribute is defined as “User” and the URI is prefixed with ./user. If the attribute value is “Machine”, the URI is prefixed with ./device. If the attribute value is “Both”, the policy can be configured either as a user or a device policy. 

The policy {AreaName} format is {AppName}~{SettingType}~{CategoryPathFromAdmx}. {AppName} and {SettingType} are derived from the URI that is used to import the ADMX file. In this example, the URI is: ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ContosoCompanyApp/Policy/AppAdmxFile01.

{CategoryPathFromAdmx} is derived by traversing the parentCategory parameter. In this example, {CategoryPathFromAdmx} is ParentCategoryArea~Category2~Category3. Therefore, {AreaName} is ContosoCompanyApp~ Policy~ ParentCategoryArea~Category2~Category3. 

Therefore, from the example: 

  • Class: User
  • Policy name: L_PolicyPreventRun_1
  • Policy area name: ContosoCompanyApp~Policy~ParentCategoryArea~Category2~Category3
  • URI: ./user/Vendor/MSFT/Policy/Config/ContosoCompanyApp~Policy~ParentCategoryArea~Category2~Category3/L_PolicyPreventRun_1

In Intune we configure a Device Configuration Profile for Windows 10 as a Custom policy with two custom settings. Important we need to specify EnableADAL as ./User to map it to HKCU and SilentAccountConfig as ./Device to map it to HKLM.

Device Configuration Profile: ADMX Config – CustomOneDrive.admx


OMA URI Settings:

Name: EnableADAL
OMA-URI: ./User/Vendor/MSFT/Policy/Config/OneDriveNGSC~Policy~OneDriveNGSC/EnableADAL
Data type: string
Value: <enabled/>
Name: SilentAccountConfig
Data type: string
Value: <enabled/>

In the end we assign the device configuration profile to a user group and if applied successfully we will see OneDrive singed-in shortly after the Desktop appears:


If you look into Start > Settings > Accounts > Access work or school > your Tenant > Info your should see Policy listed as: OneDriveNGSC~Policy~OneDriveNGSC as defined above.


Special thanks to Mark for inspiring me to write about that topic my very first blogpost here.

Peter van der Woude has a good article about ADMX ingestion to configure Google Chrome site isolation.

UPDATE May 25th: Senthil’s Blog has a great article about it, I can truly recommend to read: Intune: Deploying ADMX-Backed policies using Microsoft Intune.

UPDATE October 17th: I recommend to use the Administrative Templates in Intune now to configure OneDrive Settings as they will be available soon in every tenant. A very good post by my fellow Maurice Daly can be found here:

Configure ADMX settings with Microsoft Intune Administrative Templates

UPDATE December 10th: I highly recommend to use a custom name during ingestion, instead of the admx policy name like this:


During my initial writing of this blog post this was not a problem but it may lead now to conflicts with other features, therefore use a custom prefix like Custom, e.g.:


The custom name will prevent that the upcoming “Administrative Templates” feature like explained in Maurice Blog post will generate a conflict as this feature will also ingest admx files in the background and if it will find an already ingested policy with the same name it generates a conflict.

16 thoughts on “Deep dive ADMX ingestion to configure SilentAccountConfig with OneDrive”

  1. Very nice and detailed write-up, one of the best out on the web.
    Some questions i have i hope you will answer.

    In the first oma-uri for ingesting the admx for {AppName} you have OneDriveNGSC , is this a name you choose yourself or has it to be a parameter fron the admx and if yes which parameter should this be?
    Also in this oma-uri for {SettingType} you have Policy , again is this always Policy when ingesting an oma-uri ?

    In the enableADAL oma-uri the OneDriveNGSC for {appname} and {settingtype }is derived from the import
    The {CategoryPathFromAdmx} value which value/parameter in the admx is this?

    1. Thanks RKast!

      Yes {AppName} is free for your choice, I chose to align it with the policy of the app and this one is called in the namespace OneDriveNGSC in the admx file
      For {SettingType} you have to use Policy

      The referenced article from MS is great for explaining how to build the URI, have a look at section: URI format for configuring an app policy

      the important sentence here is:
      {CategoryPathFromAdmx} is derived by traversing the parentCategory parameter.

      In this example, {CategoryPathFromAdmx} is ParentCategoryArea~Category2~Category3.
      Therefore, {AreaName} is ContosoCompanyApp~ Policy~ ParentCategoryArea~Category2~Category3.
      you can find the referenced xml example on the target link above.

      in the Onedrive ADMX xml we have just one parentCategory so we do not need to traverse backwards:
      parentCategory ref=”OneDriveNGSC”

      The AppName is: OneDriveNGSC

      and the SiltentAccountConfig is derived from:
      policy name=”SilentAccountConfig”

      so we will use =>

      the confusing part here is that the AppName is OneDriveNGSC and the ParentCategory also OneDriveNGSC
      imagine we chose AppName OneDriveClient then the URI would be:


      1. Oliver,
        I get your point and lost a lot of braincells with it ๐Ÿ™‚
        You search for the policy to set, in the link above you sent the policy “L_PolicyPreventRun_1″
        Then make not of the ‘parentCategory ref’ of the policy, in this case Category3
        Then search for a [category name=”Category3”] in the ADMX file and make note if there is a ‘parentCategory ref’ in this case yes it’s “ParentCategoryArea”
        Then search for a [category name=”ParentCategoryArea”] in the ADMX file and make note if there is a ‘parentCategory ref’ for this category, in this case the parentCategory for “ParentCategoryArea” is “ParentCategoryArea” ๐Ÿ™‚ so no more parentCategory

        This is the correct oma-uri for dummies method ๐Ÿ™‚ ?

      2. Yes traverse through all categories to find {CategoryPathFromAdmx}:
        category name=”Category3″ -> parentCategory ref=”Category2″
        category name=”Category2″ -> parentCategory ref=”ParentCategoryArea”
        category name=”ParentCategoryArea”

        follow the chain backwards ๐Ÿ™‚ and then build the URI


        -> URI: ./user/Vendor/MSFT/Policy/Config/ContosoCompanyApp~Policy~ParentCategoryArea~Category2~Category3/L_PolicyPreventRun_1

  2. Hi Oliver,
    I was testing this with an example policy in the TerminalServer.admx file.
    I want to set the policy “Specify SHA1 thumbprints of certificates representing trusted .rdp publishers”

    Can you please check if both OMA-URI are correct ? (fyi i changed brackets to [ ] )



    [data id=”TRUSTED_CERTIFICATE_THUMBPRINTS” value=”00 11 22 33 44 55 66 77″/]

    PS. i know ingesting policies are not allowed to write to locations software\policies\windows nt where the above policy writes but i want to know how derive such policy

  3. Oliver, I saw you posted a question about two weeks ago about Enum values in a ADMX file. Did you ever get an answer on that or figure out the solution? What do you do when the ADMX file doesn’t contain an and tag and just an Enum list?

    1. Hi David,
      Iโ€˜m enjoying vacation at the moment and did not further research there. As soon as Iโ€˜m back and I find something out Iโ€˜ll update my blog and post. Itโ€˜s definitely on my agenda to find out after vacation.

      1. I’ll keep posted on and your blog as well then. For now I will probably just work around it with Powershell scripts until ADMX settings are built into the Intune GUI.

  4. I’m trying to implement the AutoMountTeamSites part of the onedrive.admx but I can’t find the good configuration on the data id part. I use OMA-URI : ./Device/Vendor/MSFT/Policy/Config/OneDriveNGSC~Policy~OneDriveNGSC/AutoMountTeamSites after type of data String and put:
    Is there something wrong on my input ? I can’t find explanation for List Box type input on the web…

    1. Hi Ludo,

      yes that’s quite a challenge all the time to figure out how the correct syntax is. In your case you have to look here: it describes the list entries. Be careful with the separator and I had to use the value as a tuple when I configured single values. For example if you only specify an URL I needed to specify URLURL. If you have key values to specify it is obvious to have KEYVALUE. In the case for OneDrive AutoMount I think you need URLURL.

      Let me know if you have further trouble, then I will test it out for you in my lab in a few days.


      1. Thanks a lot, I have try with KEYVALUE like it’s wrote on the microsoft website but it fails and then the insertion returns me: -2016281112 (Remediation failed) . Then I follow the debug process but didn’t find where the matter is. If you wan’t to make a test I can send you a csv extract of my onedriveadmx policy. It’s the same of yours but with AutomountTeamSites value added and the twice value (SilentAccountConfig and EnableOneDriveFileOnDemand) that we can found now on administrative template has been removed for used with the last modification of microsoft.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s