--- title: Win32 and Desktop Bridge app policy configuration description: Starting in Windows 10, version 1703, you can import ADMX files and set those ADMX-backed policies for Win32 and Desktop Bridge apps. ms.author: dansimp ms.topic: article ms.prod: w10 ms.technology: windows author: manikadhiman ms.date: 03/23/2020 ms.reviewer: manager: dansimp --- # Win32 and Desktop Bridge app policy configuration ## In this section - [Overview](#overview) - [Ingesting an app ADMX file](#ingesting-an-app-admx-file) - [URI format for configuring an app policy](#uri-format-for-configuring-an-app-policy) - [ADMX-backed app policy examples](#admx-backed-app-policy-examples) - [Enabling an app policy](#enabling-an-app-policy) - [Disabling an app policy](#disabling-an-app-policy) - [Setting an app policy to not configured](#setting-an-app-policy-to-not-configured) ## Overview Starting in Windows 10, version 1703, you can import ADMX files (also called ADMX ingestion) and set those ADMX-backed policies for Win32 and Desktop Bridge apps by using Windows 10 Mobile Device Management (MDM) on desktop SKUs. The ADMX files that define policy information can be ingested to your device by using the Policy CSP URI, `./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall`. The ingested ADMX file is then processed into MDM policies. NOTE: Starting from the following Windows 10 version Replace command is supported - Windows 10, version 1903 with KB4512941 and KB4517211 installed - Windows 10, version 1809 with KB4512534 and KB installed - Windows 10, version 1803 with KB4512509 and KB installed - Windows 10, version 1709 with KB4516071 and KB installed When the ADMX policies are imported, the registry keys to which each policy is written are checked so that known system registry keys, or registry keys that are used by existing inbox policies or system components, are not overwritten. This precaution helps to avoid security concerns over opening the entire registry. 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\Policies\Microsoft\Office\ - Software\Microsoft\Office\ - Software\Microsoft\Windows\CurrentVersion\Explorer\ - Software\Microsoft\Internet Explorer\ - software\policies\microsoft\shared tools\proofing tools\ - software\policies\microsoft\imejp\ - software\policies\microsoft\ime\shared\ - software\policies\microsoft\shared tools\graphics filters\ - software\policies\microsoft\windows\currentversion\explorer\ - software\policies\microsoft\softwareprotectionplatform\ - software\policies\microsoft\officesoftwareprotectionplatform\ - software\policies\microsoft\windows\windows search\preferences\ - software\policies\microsoft\exchange\ - software\microsoft\shared tools\proofing tools\ - software\microsoft\shared tools\graphics filters\ - software\microsoft\windows\windows search\preferences\ - software\microsoft\exchange\ - software\policies\microsoft\vba\security\ - software\microsoft\onedrive - software\Microsoft\Edge - Software\Microsoft\EdgeUpdate\ > [!Warning] > Some operating system components have built in functionality to check devices for domain membership. MDM enforces the configured policy values only if the devices are domain joined, otherwise it does not. However, you can still import ADMX files and set ADMX-backed policies regardless of whether the device is domain joined or non-domain joined. > [!NOTE] > Settings that cannot be configured using custom policy ingestion have to be set by pushing the appropriate registry keys directly (for example, by using PowerShell script). ## Ingesting an app ADMX file The following ADMX file example shows how to ingest a Win32 or Desktop Bridge app ADMX file and set policies from the file. The ADMX file defines eight policies. **Payload** ```XML ``` **Request Syncml** The ADMX file is escaped and sent in SyncML format through the Policy CSP URI, `./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid or AdmxFileName}`. When the ADMX file is imported, the policy states for each new policy are the same as those in a regular MDM policy: Enabled, Disabled, or Not Configured. The following example shows an ADMX file in SyncML format: ```XML 102 chr text/plain ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ContosoCompanyApp/Policy/AppAdmxFile01 ]]> ``` **Response Syncml** ```XML 21102Add200 ``` ### URI format for configuring an app policy The following example shows how to derive a Win32 or Desktop Bridge app policy name and policy area name: ```XML ``` As documented in [Policy CSP](policy-configuration-service-provider.md), the URI format to configure a policy via Policy CSP is: './{user or device}/Vendor/MSFT/Policy/Config/{AreaName}/{PolicyName}'. **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` ## ADMX-backed app policy examples The following examples describe how to set an ADMX-ingested app policy. ### Enabling an app policy **Payload** ```XML ``` **Request Syncml** ```XML 103 chr text/plain ./Device/Vendor/MSFT/Policy/Config/ContosoCompanyApp~ Policy~ParentCategoryArea~Category1/L_PolicyConfigurationMode ]]> ``` **Response SyncML** ```XML 21103Replace200 ``` ### Disabling an app policy **Payload** ```XML ``` **Request SyncML** ```XML 104 chr text/plain ./Device/Vendor/MSFT/Policy/Config/ContosoCompanyApp~ Policy~ParentCategoryArea~Category1/L_PolicyConfigurationMode ]]> ``` **Response SyncML** ```XML 21104Replace200 ``` ### Setting an app policy to not configured **Payload** (None) **Request SyncML** ```XML 105 ./Device/Vendor/MSFT/Policy/Config/ContosoCompanyApp~ Policy~ParentCategoryArea~Category1/L_PolicyConfigurationMode ``` **Response SyncML** ```XML 21105Delete200 ```