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.

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.