deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-19 20:33:42 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge branch 'master' into Ashok-Lobo-5388078

Browse Source
This commit is contained in:
Ashok Lobo
2021-09-17 16:02:00 +05:30
committed by GitHub
parent d9c2598618 e1cb6d2954
commit eb39497539
9 changed files with 82 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
windows/client-management/mdm/enable-admx-backed-policies-in-mdm.md
View File

@ -1,6 +1,6 @@
---
title: Enable ADMX-backed policies in MDM
description: Use this step-by-step guide to configure a selected set of Group Policy administrative templates (ADMX-backed policies) in Mobile Device Management (MDM).
title: Enable ADMX policies in MDM
description: Use this step-by-step guide to configure a selected set of Group Policy administrative templates (ADMX policies) in Mobile Device Management (MDM).
ms.author: dansimp
ms.topic: article
ms.prod: w10
@ -12,30 +12,30 @@ ms.reviewer:
manager: dansimp
---
# Enable ADMX-backed policies in MDM
# Enable ADMX policies in MDM
This is a step-by-step guide to configuring ADMX-backed policies in MDM.
Here's how to configure Group Policy administrative templates (ADMX policies) in Mobile Device Management (MDM).
Starting in Windows 10 version 1703, Mobile Device Management (MDM) policy configuration support was expanded to allow access of [selected set of Group Policy administrative templates (ADMX-backed policies)](./policies-in-policy-csp-admx-backed.md) for Windows PCs via the [Policy configuration service provider (CSP)](policy-configuration-service-provider.md). Configuring ADMX-backed policies in Policy CSP is different from the typical way you configure a traditional MDM policy.
Starting in Windows 10 version 1703, Mobile Device Management (MDM) policy configuration support was expanded to allow access of [selected set of Group Policy administrative templates (ADMX policies)](./policies-in-policy-csp-admx-backed.md) for Windows PCs via the [Policy configuration service provider (CSP)](policy-configuration-service-provider.md). Configuring ADMX policies in Policy CSP is different from the typical way you configure a traditional MDM policy.
Summary of steps to enable a policy:
- Find the policy from the list ADMX-backed policies.
- Find the policy from the list ADMX policies.
- Find the Group Policy related information from the MDM policy description.
- Use the Group Policy Editor to determine whether there are parameters necessary to enable the policy.
- Create the data payload for the SyncML.
See [Support Tip: Ingesting Office ADMX-backed policies using Microsoft Intune](https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Support-Tip-Ingesting-Office-ADMX-Backed-policies-using/ba-p/354824) and [Deploying ADMX-Backed policies using Microsoft Intune](/archive/blogs/senthilkumar/intune-deploying-admx-backed-policies-using-microsoft-intune) for a walk-through using Intune.
See [Support Tip: Ingesting Office ADMX policies using Microsoft Intune](https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Support-Tip-Ingesting-Office-ADMX-Backed-policies-using/ba-p/354824) and [Deploying ADMX policies using Microsoft Intune](/archive/blogs/senthilkumar/intune-deploying-admx-backed-policies-using-microsoft-intune) for a walk-through using Intune.
>[!TIP]
>Intune has added a number of ADMX-backed administrative templates in public preview. Check if the policy settings you need are available in a template before using the SyncML method described below. [Learn more about Intune's administrative templates.](/intune/administrative-templates-windows)
<!-- >[!TIP] -->
<!-- >Intune has added a number of ADMX administrative templates in public preview. Check if the policy settings you need are available in a template before using the SyncML method described below. [Learn more about Intune's administrative templates.](/intune/administrative-templates-windows) -->
## Enable a policy
> [!NOTE]
> See [Understanding ADMX-backed policies in Policy CSP](./understanding-admx-backed-policies.md).
> See [Understanding ADMX policies in Policy CSP](./understanding-admx-backed-policies.md).
1. Find the policy from the list [ADMX-backed policies](./policies-in-policy-csp-admx-backed.md). You need the following information listed in the policy description.
1. Find the policy from the list [ADMX policies](./policies-in-policy-csp-admx-backed.md). You need the following information listed in the policy description.
- GP English name
- GP name
- GP ADMX file name
@ -63,7 +63,7 @@ See [Support Tip: Ingesting Office ADMX-backed policies using Microsoft Intune](
3. Create the SyncML to enable the policy that does not require any parameter.
In this example you configure **Enable App-V Client** to **Enabled**.
In this example, you configure **Enable App-V Client** to **Enabled**.
> [!NOTE]
> The \<Data> payload must be XML encoded. To avoid encoding, you can use CData if your MDM supports it. For more information, see [CDATA Sections](http://www.w3.org/TR/REC-xml/#sec-cdata-sect). If you are using Intune, select String as the data type.
@ -109,12 +109,12 @@ See [Support Tip: Ingesting Office ADMX-backed policies using Microsoft Intune](
![Publishing server 2 policy description.](images/admx-appv-policy-description.png)
3. Navigate to **C:\Windows\PolicyDefinitions** (default location of the admx files) and open appv.admx.
3. Navigate to **C:\Windows\PolicyDefinitions** (default location of the ADMX files) and open appv.admx.
4. Search for GP name **Publishing_Server2_policy**.
5. Under **policy name="Publishing_Server2_Policy"** you can see the \<elements> listed. The text id and enum id represents the data id you need to include in the SyncML data payload. They correspond to the fields you see in GP Editor.
5. Under **policy name="Publishing_Server2_Policy"** you can see the \<elements> listed. The *text id* and *enum id* represents the *data id* you need to include in the SyncML data payload. They correspond to the fields you see in the Group Policy Editor.
Here is the snippet from appv.admx:
@ -206,9 +206,9 @@ See [Support Tip: Ingesting Office ADMX-backed policies using Microsoft Intune](
</policy>
```
6. From the \<elements> tag, copy all the text id and enum id and create an XML with data id and value fields. The value field contains the configuration settings you would enter in the GP Editor.
6. From the **\<elements>** tag, copy all of the *text id* and *enum id* and create an XML with *data id* and *value* fields. The *value* field contains the configuration settings that you would enter in the Group Policy Editor.
Here is the example XML for Publishing_Server2_Policy :
Here is the example XML for Publishing_Server2_Policy:
```xml
<data id="Publishing_Server2_Name_Prompt" value="Name"/>
@ -308,4 +308,4 @@ The \<Data> payload is empty. Here an example to set AppVirtualization/Publishin
<Final/>
</SyncBody>
</SyncML>
```
```

6
windows/client-management/mdm/toc.yml
View File

@ -23,9 +23,9 @@ items:
href: certificate-authentication-device-enrollment.md
- name: On-premises authentication device enrollment
href: on-premise-authentication-device-enrollment.md
- name: Understanding ADMX-backed policies
- name: Understanding ADMX policies
href: understanding-admx-backed-policies.md
- name: Enable ADMX-backed policies in MDM
- name: Enable ADMX policies in MDM
href: enable-admx-backed-policies-in-mdm.md
- name: Win32 and Desktop Bridge app policy configuration
href: win32-and-centennial-app-policy-configuration.md
@ -381,7 +381,7 @@ items:
href: policy-ddf-file.md
- name: Policies in Policy CSP supported by Group Policy
href: policies-in-policy-csp-supported-by-group-policy.md
- name: ADMX-backed policies in Policy CSP
- name: ADMX policies in Policy CSP
href: policies-in-policy-csp-admx-backed.md
- name: Policies in Policy CSP supported by HoloLens 2
href: policies-in-policy-csp-supported-by-hololens2.md

30
windows/client-management/mdm/understanding-admx-backed-policies.md
View File

@ -1,6 +1,6 @@
---
title: Understanding ADMX-backed policies
description: Starting in Windows 10, version 1703, you can use ADMX-backed policies for Windows 10 mobile device management (MDM) across Windows 10 devices.
title: Understanding ADMX policies
description: In Windows 10, you can use ADMX policies for Windows 10 mobile device management (MDM) across Windows 10 devices.
ms.author: dansimp
ms.topic: article
ms.prod: w10
@ -11,15 +11,15 @@ ms.reviewer:
manager: dansimp
---
# Understanding ADMX-backed policies
# Understanding ADMX policies
Due to increased simplicity and the ease with which devices can be targeted, enterprise businesses are finding it increasingly advantageous to move their PC management to a cloud-based device management solution. Unfortunately, current Windows PC device-management solutions lack the critical policy and app settings configuration capabilities that are supported in a traditional PC management solution.
Due to increased simplicity and the ease with which devices can be targeted, enterprise businesses are finding it increasingly advantageous to move their PC management to a cloud-based device management solution. Unfortunately, the modern Windows PC device-management solutions lack the critical policy and app settings configuration capabilities that are supported in a traditional PC management solution.
Starting in Windows 10 version 1703, Mobile Device Management (MDM) policy configuration support will be expanded to allow access of select Group Policy administrative templates (ADMX-backed policies) for Windows PCs via the Policy configuration service provider (CSP). This expanded access ensures that enterprises do not need to compromise security of their devices in the cloud.
Starting in Windows 10 version 1703, Mobile Device Management (MDM) policy configuration support expanded to allow access of selected set of Group Policy administrative templates (ADMX policies) for Windows PCs via the Policy configuration service provider (CSP). This expanded access ensures that enterprises can keep their devices compliant and prevent the risk on compromising security of their devices managed through the cloud.
## <a href="" id="background"></a>Background
In addition to standard policies, the Policy CSP can now also handle ADMX-backed policies. In an ADMX-backed policy, an administrative template contains the metadata of a Window Group Policy and can be edited in the Local Group Policy Editor on a PC. Each administrative template specifies the registry keys (and their values) that are associated with a Group Policy and defines the policy settings that can be managed. Administrative templates organize Group Policies in a hierarchy in which each segment in the hierarchical path is defined as a category. Each setting in a Group Policy administrative template corresponds to a specific registry value. These Group Policy settings are defined in a standards-based, XML file format known as an ADMX file. For more information, see [Group Policy ADMX Syntax Reference Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753471(v=ws.10)).
In addition to standard MDM policies, the Policy CSP can also handle selected set of ADMX policies. In an ADMX policy, an administrative template contains the metadata of a Window Group Policy and can be edited in the Local Group Policy Editor on a PC. Each administrative template specifies the registry keys (and their values) that are associated with a Group Policy and defines the policy settings that can be managed. Administrative templates organize Group Policies in a hierarchy in which each segment in the hierarchical path is defined as a category. Each setting in a Group Policy administrative template corresponds to a specific registry value. These Group Policy settings are defined in a standards-based, XML file format known as an ADMX file. For more information, see [Group Policy ADMX Syntax Reference Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753471(v=ws.10)).
ADMX files can either describe operating system (OS) Group Policies that are shipped with Windows or they can describe settings of applications, which are separate from the OS and can usually be downloaded and installed on a PC.
Depending on the specific category of the settings that they control (OS or application), the administrative template settings are found in the following two locations in the Local Group Policy Editor:
@ -30,29 +30,29 @@ In a domain controller/Group Policy ecosystem, Group Policies are automatically
An ADMX file can either be shipped with Windows (located at `%SystemRoot%\policydefinitions`) or it can be ingested to a device through the Policy CSP URI (`./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall`). Inbox ADMX files are processed into MDM policies at OS-build time. ADMX files that are ingested are processed into MDM policies post-OS shipment through the Policy CSP. Because the Policy CSP does not rely upon any aspect of the Group Policy client stack, including the PC's Group Policy Service (GPSvc), the policy handlers that are ingested to the device are able to react to policies that are set by the MDM.
Windows maps the name and category path of a Group Policy to a MDM policy area and policy name by parsing the associated ADMX file, finding the specified Group Policy, and storing the definition (metadata) in the MDM Policy CSP client store. When the MDM policy is referenced by a SyncML command and the Policy CSP URI, `.\[device|user]\vendor\msft\policy\[config|result]\<area>\<policy>`, this metadata is referenced and determines which registry keys are set or removed. For a list of ADMX-backed policies supported by MDM, see [Policy CSP - ADMX-backed policies](./policy-configuration-service-provider.md).
Windows maps the name and category path of a Group Policy to a MDM policy area and policy name by parsing the associated ADMX file, finding the specified Group Policy, and storing the definition (metadata) in the MDM Policy CSP client store. When the MDM policy is referenced by a SyncML command and the Policy CSP URI, `.\[device|user]\vendor\msft\policy\[config|result]\<area>\<policy>`, this metadata is referenced and determines which registry keys are set or removed. For a list of ADMX policies supported by MDM, see [Policy CSP - ADMX policies](./policy-configuration-service-provider.md).
>[!TIP]
>Intune has added a number of ADMX-backed administrative templates in public preview. Check if the policy settings you need are available in a template before using the SyncML method described below. [Learn more about Intune's administrative templates.](/intune/administrative-templates-windows)
<!-- [!TIP] -->
<!-- Intune has added a number of ADMX administrative templates in public preview. Check if the policy settings you need are available in a template before using the SyncML method described below. [Learn more about Intune's administrative templates.](/intune/administrative-templates-windows) -->
## <a href="" id="admx-files-and-the-group-policy-editor"></a>ADMX files and the Group Policy Editor
To capture the end-to-end MDM handling of ADMX Group Policies, an IT administrator must use a UI, such as the Group Policy Editor (gpedit.msc), to gather the necessary data. The MDM ISV console UI determines how to gather the needed Group Policy data from the IT administrator. ADMX-backed Group Policies are organized in a hierarchy and can have a scope of machine, user, or both. The Group Policy example in the next section uses a machine-wide Group Policy named "Publishing Server 2 Settings." When this Group Policy is selected, its available states are **Not Configured**, **Enabled**, and **Disabled**.
To capture the end-to-end MDM handling of ADMX Group Policies, an IT administrator must use a UI, such as the Group Policy Editor (gpedit.msc), to gather the necessary data. The MDM ISV console UI determines how to gather the needed Group Policy data from the IT administrator. ADMX Group Policies are organized in a hierarchy and can have a scope of machine, user, or both. The Group Policy example in the next section uses a machine-wide Group Policy named "Publishing Server 2 Settings." When this Group Policy is selected, its available states are **Not Configured**, **Enabled**, and **Disabled**.
The ADMX file that the MDM ISV uses to determine what UI to display to the IT administrator is the same ADMX file that the client uses for the policy definition. The ADMX file is processed either by the OS at build time or set by the client at OS runtime. In either case, the client and the MDM ISV must be synchronized with the ADMX policy definitions. Each ADMX file corresponds to a Group Policy category and typically contains several policy definitions, each of which represents a single Group Policy. For example, the policy definition for the "Publishing Server 2 Settings" is contained in the appv.admx file, which holds the policy definitions for the Microsoft Application Virtualization (App-V) Group Policy category.
Group Policy option button setting:
- If **Enabled** is selected, the necessary data entry controls are displayed for the user in the UI. When IT administrator enters the data and clicks **Apply**, the following events occur:
- The MDM ISV server sets up a Replace SyncML command with a payload that contains the user-entered data.
- The MDM client stack receives this data, which causes the Policy CSP to update the device's registry per the ADMX-backed policy definition.
- The MDM client stack receives this data, which causes the Policy CSP to update the device's registry per the ADMX policy definition.
- If **Disabled** is selected and you click **Apply**, the following events occur:
- The MDM ISV server sets up a Replace SyncML command with a payload set to `<disabled\>`.
- The MDM client stack receives this command, which causes the Policy CSP to either delete the device's registry settings, set the registry keys, or both, per the state change directed by the ADMX-backed policy definition.
- The MDM client stack receives this command, which causes the Policy CSP to either delete the device's registry settings, set the registry keys, or both, per the state change directed by the ADMX policy definition.
- If **Not Configured** is selected and you click **Apply**, the following events occur:
- MDM ISV server sets up a Delete SyncML command.
- The MDM client stack receives this command, which causes the Policy CSP to delete the device's registry settings per the ADMX-backed policy definition.
- The MDM client stack receives this command, which causes the Policy CSP to delete the device's registry settings per the ADMX policy definition.
The following diagram shows the main display for the Group Policy Editor.
@ -83,9 +83,9 @@ Appv.admx file:
```
## <a href="" id="admx-backed-policy-examples"></a>ADMX-backed policy examples
## <a href="" id="admx-backed-policy-examples"></a>ADMX policy examples
The following SyncML examples describe how to set a MDM policy that is defined by an ADMX template, specifically the Publishing_Server2_Policy Group Policy description in the application virtualization ADMX file, appv.admx. Note that the functionality that this Group Policy manages is not important; it is used to illustrate only how an MDM ISV can set an ADMX-backed policy. These SyncML examples illustrate common options and the corresponding SyncML code that can be used for testing your policies. Note that the payload of the SyncML must be XML-encoded; for this XML encoding, you can use favorite online tool. To avoid encoding the payload, you can use CData if your MDM supports it. For more information, see [CDATA Sections](http://www.w3.org/TR/REC-xml/#sec-cdata-sect).
The following SyncML examples describe how to set a MDM policy that is defined by an ADMX template, specifically the Publishing_Server2_Policy Group Policy description in the application virtualization ADMX file, appv.admx. Note that the functionality that this Group Policy manages is not important; it is used to illustrate only how an MDM ISV can set an ADMX policy. These SyncML examples illustrate common options and the corresponding SyncML code that can be used for testing your policies. Note that the payload of the SyncML must be XML-encoded; for this XML encoding, you can use favorite online tool. To avoid encoding the payload, you can use CData if your MDM supports it. For more information, see [CDATA Sections](http://www.w3.org/TR/REC-xml/#sec-cdata-sect).
### <a href="" id="enabling-a-policy"></a>Enabling a policy

14
windows/client-management/mdm/win32-and-centennial-app-policy-configuration.md
View File

@ -1,6 +1,6 @@
---
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.
title: Win32 and Desktop Bridge app ADMX policy Ingestion
description: Starting in Windows 10, version 1703, you can ingest ADMX files and set those ADMX policies for Win32 and Desktop Bridge apps.
ms.author: dansimp
ms.topic: article
ms.prod: w10
@ -11,21 +11,21 @@ ms.reviewer:
manager: dansimp
---
# Win32 and Desktop Bridge app policy configuration
# Win32 and Desktop Bridge app ADMX policy Ingestion
## 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)
- [ADMX 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)
## <a href="" id="overview"></a>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.
Starting in Windows 10, version 1703, you can ingest ADMX files (ADMX ingestion) and set those ADMX 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
@ -33,7 +33,7 @@ NOTE: Starting from the following Windows 10 version Replace command is supporte
- 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:
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, 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\
@ -58,7 +58,7 @@ When the ADMX policies are imported, the registry keys to which each policy is w
- 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.
> 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).