---
title: Win32 and Desktop Bridge app ADMX policy Ingestion
description: Ingest ADMX files and set ADMX policies for Win32 and Desktop Bridge apps.
ms.topic: conceptual
ms.date: 07/08/2024
---
# Win32 and Desktop Bridge app ADMX policy Ingestion
## Overview
You can ingest ADMX files (ADMX ingestion) and set those ADMX policies for Win32 and Desktop Bridge apps by using Windows 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.
Starting from the following Windows versions `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 ingested, 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, aren't overwritten. This precaution helps to avoid security concerns over opening the entire registry. Currently, the ingested policies aren't 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 ingest ADMX files and set ADMX 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 the ones 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](mdm/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
```