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

older windows version cleanup

Browse Source
This commit is contained in:
Vinay Pamnani
2023-04-11 11:36:23 -04:00
parent 92ff1941e9
commit 00af39a152
23 changed files with 285 additions and 776 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -7,7 +7,7 @@ ms.prod: windows-client
ms.technology: itpro-manage
author: vinaypamnani-msft
ms.date: 03/23/2020
ms.reviewer:
ms.reviewer:
manager: aaroncz
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
@ -18,9 +18,9 @@ appliesto:
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 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.
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
## Background
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 Windows 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)).
@ -39,7 +39,7 @@ Windows maps the name and category path of a Group Policy to an MDM policy area
<!-- [!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
## 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 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**.
@ -48,16 +48,16 @@ The ADMX file that the MDM ISV uses to determine what UI to display to the IT ad
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 policy definition.
- 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 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 policy definition.
- 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 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 policy definition.
- 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 policy definition.
The following diagram shows the main display for the Group Policy Editor.
@ -77,23 +77,26 @@ For more information about the Group Policy description format, see [Administrat
For example, if you search for the string, "Publishing_Server2_Name_Prompt" in both the *Enabling a policy* example and its corresponding ADMX policy definition in the appv.admx file, you'll find the following occurrences:
Enabling a policy example:
```XML
`<data id="Publishing_Server2_Name_Prompt" value="name"/>`
```
Appv.admx file:
```XML
<elements>
<text id="Publishing_Server2_Name_Prompt" valueName="Name" required="true"/>
```
## <a href="" id="admx-backed-policy-examples"></a>ADMX policy examples
## ADMX policy examples
The following SyncML examples describe how to set an 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. The functionality that this Group Policy manages isn't important; it's 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. 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
### Enabling a policy
**Payload**:
**Payload**
```XML
<enabled/>
<data id="Publishing_Server2_Name_Prompt" value="Name"/>
@ -107,7 +110,9 @@ The following SyncML examples describe how to set an MDM policy that is defined
<data id="User_Refresh_Interval_Prompt" value="15"/>
<data id="User_Refresh_Unit_Options" value="1"/>
```
**Request SyncML**
**Request SyncML**:
```XML
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
@ -141,7 +146,8 @@ The following SyncML examples describe how to set an MDM policy that is defined
</SyncML>
```
**Response SyncML**
**Response SyncML**:
```XML
<Status>
<CmdID>2</CmdID>
@ -152,14 +158,16 @@ The following SyncML examples describe how to set an MDM policy that is defined
</Status>
```
### <a href="" id="disabling-a-policy"></a>Disabling a policy
### Disabling a policy
**Payload**:
**Payload**
```XML
<disabled/>
```
**Request SyncML**
**Request SyncML**:
```XML
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
@ -180,9 +188,10 @@ The following SyncML examples describe how to set an MDM policy that is defined
<Final/>
</SyncBody>
</SyncML>
''''
```
**Response SyncML**:
**Response SyncML**
```XML
<Status>
<CmdID>2</CmdID>
@ -193,13 +202,13 @@ The following SyncML examples describe how to set an MDM policy that is defined
</Status>
```
### <a href="" id="setting-a-policy-to-not-configured"></a>Setting a policy to not configured
### Setting a policy to not configured
**Payload**
**Payload**:
(None)
**Request SyncML**
**Request SyncML**:
```XML
<?xml version="1.0" encoding="utf-8"?>
@ -218,7 +227,7 @@ The following SyncML examples describe how to set an MDM policy that is defined
</SyncML>
```
**Response SyncML**
**Response SyncML**:
```XML
<Status>
@ -230,11 +239,11 @@ The following SyncML examples describe how to set an MDM policy that is defined
</Status>
```
## <a href="" id="sample-syncml-for-various-admx-elements"></a>Sample SyncML for various ADMX elements
## Sample SyncML for various ADMX elements
This section describes sample SyncML for the various ADMX elements like Text, Multi-Text, Decimal, Boolean, and List.
### <a href="" id="how-a-group-policy-policy-category-path-and-name-are-mapped-to-a-mdm-area-and-policy-name"></a>How a Group Policy policy category path and name are mapped to an MDM area and policy name
### How a Group Policy policy category path and name are mapped to an MDM area and policy name
Below is the internal OS mapping of a Group Policy to an MDM area and name. This mapping is part of a set of Windows manifest that when compiled parses out the associated ADMX file, finds the specified Group Policy policy and stores that definition (metadata) in the MDM Policy CSP client store. ADMX backed policies are organized hierarchically. Their scope can be **machine**, **user**, or have a scope of **both**. When the MDM policy is referred to through a SyncML command and the Policy CSP URI, as shown below, this metadata is referenced and determines what registry keys are set or removed. Machine-scope policies are referenced via .\Device and the user scope policies via .\User.
@ -242,23 +251,19 @@ Below is the internal OS mapping of a Group Policy to an MDM area and name. This
The data payload of the SyncML needs to be encoded so that it doesn't conflict with the boilerplate SyncML XML tags. Use this online tool for encoding and decoding the policy data [Coder's Toolbox](https://coderstoolbox.net/string/#!encoding=xml&action=encode&charset=us_ascii).
**Snippet of manifest for AppVirtualization area:**
**Snippet of manifest for AppVirtualization area**:
```XML
<identity xmlns="urn:Microsoft.CompPlat/ManifestSchema.v1.00" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" owner="Microsoft" namespace="Windows-DeviceManagement-PolicyDefinition" name="AppVirtualization">
<policyDefinitions>
<area name="AppVirtualization">
<policies>
.
.
.
...
<stringPolicy name="PublishingAllowServer2" notSupportedOnPlatform="phone" admxbacked="appv.admx" scope="machine">
<ADMXPolicy area="appv~AT~System~CAT_AppV~CAT_Publishing" name="Publishing_Server2_Policy" scope="machine" />
<registryKeyRedirect path="SOFTWARE\Policies\Microsoft\AppV\Client\Publishing\Servers\2" />
</stringPolicy >
.
.
.
...
```
The **LocURI** for the above GP policy is:
@ -267,11 +272,11 @@ The **LocURI** for the above GP policy is:
To construct SyncML for your area/policy using the samples below, you need to update the **data id** and the **value** in the `<Data>` section of the SyncML. The items prefixed with an '&' character are the escape characters needed and can be retained as shown.
### <a href="" id="text-element"></a>Text Element
### Text Element
The `text` element simply corresponds to a string and correspondingly to an edit box in a policy panel display by gpedit.msc. The string is stored in the registry of type REG_SZ.
**ADMX file: inetres.admx**
**ADMX file: inetres.admx**:
```XML
<policy name="RestrictHomePage" class="User" displayName="$(string.RestrictHomePage)" explainText="$(string.IE_ExplainRestrictHomePage)" presentation="$(presentation.RestrictHomePage)" key="Software\Policies\Microsoft\Internet Explorer\Control Panel" valueName="HomePage">
@ -283,7 +288,7 @@ The `text` element simply corresponds to a string and correspondingly to an edit
</policy>
```
#### Corresponding SyncML:
**Corresponding SyncML**:
```XML
<?xml version="1.0" encoding="utf-8"?>
@ -307,7 +312,7 @@ The `text` element simply corresponds to a string and correspondingly to an edit
</SyncML>
```
### <a href="" id="multitext-element"></a>MultiText Element
### MultiText Element
The `multiText` element simply corresponds to a REG_MULTISZ registry string and correspondingly to a grid to enter multiple strings in a policy panel display by gpedit.msc. It's expected that each string in the SyncML is to be separated by the Unicode character 0xF000 (encoded version: `&#xF000;`)
@ -324,7 +329,7 @@ The `multiText` element simply corresponds to a REG_MULTISZ registry string and
</policy>
```
#### Corresponding SyncML:
**Corresponding SyncML**:
```XML
<?xml version="1.0" encoding="utf-8"?>
@ -348,7 +353,7 @@ The `multiText` element simply corresponds to a REG_MULTISZ registry string and
</SyncML>
```
### <a href="" id="list-element"></a>List Element (and its variations)
### List Element (and its variations)
The `list` element simply corresponds to a hive of REG_SZ registry strings and correspondingly to a grid to enter multiple strings in a policy panel display by gpedit.msc. How this element is represented in SyncML is as a string containing pairs of strings. Each pair is a REG_SZ name/value key. It's best to apply the policy through gpedit.msc (run as Administrator) and go to the registry hive location and see how the list values are stored. This location will give you an idea of the way the name/value pairs are stored to express it through SyncML.
@ -357,7 +362,7 @@ The `list` element simply corresponds to a hive of REG_SZ registry strings and c
Variations of the `list` element are dictated by attributes. These attributes are ignored by the Policy Manager runtime. It's expected that the MDM server manages the name/value pairs. See below for a simple write-up of Group Policy List.
**ADMX file: inetres.admx**
**ADMX file: inetres.admx**:
```XML
<policy name="SecondaryHomePages" class="Both" displayName="$(string.SecondaryHomePages)" explainText="$(string.IE_ExplainSecondaryHomePages)" presentation="$(presentation.SecondaryHomePages)" key="Software\Policies\Microsoft\Internet Explorer\Main\SecondaryStartPages">
@ -369,7 +374,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar
</policy>
```
#### Corresponding SyncML:
**Corresponding SyncML**:
```XML
<SyncML xmlns="SYNCML:SYNCML1.2">
@ -392,7 +397,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar
</SyncML>
```
### <a href="" id="no-elements"></a>No Elements
### No Elements
```XML
<policy name="NoUpdateCheck" class="Machine" displayName="$(string.NoUpdateCheck)" explainText="$(string.IE_ExplainNoUpdateCheck)" key="Software\Policies\Microsoft\Internet Explorer\Infodelivery\Restrictions" valueName="NoUpdateCheck">
@ -401,7 +406,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar
</policy>
```
#### Corresponding SyncML:
**Corresponding SyncML**:
```XML
<SyncML xmlns="SYNCML:SYNCML1.2">
@ -424,7 +429,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar
</SyncML>
```
### <a href="" id="enum"></a>Enum
### Enum
```XML
<policy name="EncryptionMethodWithXts_Name" class="Machine" displayName="$(string.EncryptionMethodWithXts_Name)" explainText="$(string.EncryptionMethodWithXts_Help)" presentation="$(presentation.EncryptionMethodWithXts_Name)" key="SOFTWARE\Policies\Microsoft\FVE">
@ -458,7 +463,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar
</policy>
```
#### Corresponding SyncML:
**Corresponding SyncML**:
```XML
<SyncML xmlns="SYNCML:SYNCML1.2">
@ -480,7 +485,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar
</SyncML>
```
### <a href="" id="decimal-element"></a>Decimal Element
### Decimal Element
```XML
<policy name="Streaming_Reestablishment_Interval" class="Machine" displayName="$(string.Streaming_Reestablishment_Interval)"
@ -495,7 +500,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar
</policy>
```
#### Corresponding SyncML:
**Corresponding SyncML**:
```XML
<SyncML xmlns="SYNCML:SYNCML1.2">
@ -517,7 +522,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar
</SyncML>
```
### <a href="" id="boolean-element"></a>Boolean Element
### Boolean Element
```XML
<policy name="DeviceInstall_Classes_Deny" class="Machine" displayName="$(string.DeviceInstall_Classes_Deny)" explainText="$(string.DeviceInstall_Classes_Deny_Help)" presentation="$(presentation.DeviceInstall_Classes_Deny)" key="Software\Policies\Microsoft\Windows\DeviceInstall\Restrictions" valueName="DenyDeviceClasses">
@ -543,7 +548,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar
</policy>
```
#### Corresponding SyncML:
**Corresponding SyncML**:
```XML
<?xml version="1.0" encoding="utf-8"?>