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

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 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.

9 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

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s