diff --git a/windows/client-management/mdm/understanding-admx-backed-policies.md b/windows/client-management/mdm/understanding-admx-backed-policies.md index 33001ff094..1d99f002e1 100644 --- a/windows/client-management/mdm/understanding-admx-backed-policies.md +++ b/windows/client-management/mdm/understanding-admx-backed-policies.md @@ -28,7 +28,7 @@ Depending on the specific category of the settings that they control (OS or appl In a domain controller/Group Policy ecosystem, Group Policies are automatically added to the registry of the client computer or user profile by the Administrative Templates Client Side Extension (CSE) whenever the client computer processes a Group Policy. Conversely, in an MDM-managed client, ADMX files are leveraged to define policies independent of Group Policies. Therefore, in an MDM-managed client, a Group Policy infrastructure, including the Group Policy Service (gpsvc.exe), is not required. -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. +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]\\`, 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](https://docs.microsoft.com/windows/client-management/mdm/policy-configuration-service-provider#admx-backed-policies). @@ -37,22 +37,22 @@ Windows maps the name and category path of a Group Policy to a MDM policy area 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-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**. -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. +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-backed 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 ``. - - 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-backed 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-backed policy definition. The following diagram shows the main display for the Group Policy Editor. @@ -62,7 +62,7 @@ The following diagram shows the settings for the "Publishing Server 2 Settings" ![Group Policy publisher server 2 settings](images/group-policy-publisher-server-2-settings.png) -Note that most Group Policies are a simple Boolean type. For a Boolean Group Policy, if you select **Enabled**, the options panel contains no data input fields and the payload of the SyncML is simply ``. However, if there are data input fields in the options panel, the MDM server must supply this data. The following *Enabling a Group Policy* example illustrates this complexity. In this example, 10 name-value pairs are described by `` tags in the payload, which correspond to the 10 data input fields in the Group Policy Editor options panel for the "Publishing Server 2 Settings" Group Policy. The ADMX file, which defines the Group Policies, is consumed by the MDM server, similarly to how the Group Policy Editor consumes it. The Group Policy Editor displays a UI to receive the complete Group Policy instance data, which the MDM server’s IT administrator console must also do. For every `` element and id attribute in the ADMX policy definition, there must be a corresponding `` element and id attribute in the payload. The ADMX file drives the policy definition and is required by the MDM server via the SyncML protocol. +Note that most Group Policies are a simple Boolean type. For a Boolean Group Policy, if you select **Enabled**, the options panel contains no data input fields and the payload of the SyncML is simply ``. However, if there are data input fields in the options panel, the MDM server must supply this data. The following *Enabling a Group Policy* example illustrates this complexity. In this example, 10 name-value pairs are described by `` tags in the payload, which correspond to the 10 data input fields in the Group Policy Editor options panel for the "Publishing Server 2 Settings" Group Policy. The ADMX file, which defines the Group Policies, is consumed by the MDM server, similarly to how the Group Policy Editor consumes it. The Group Policy Editor displays a UI to receive the complete Group Policy instance data, which the MDM server's IT administrator console must also do. For every `` element and id attribute in the ADMX policy definition, there must be a corresponding `` element and id attribute in the payload. The ADMX file drives the policy definition and is required by the MDM server via the SyncML protocol. > [!IMPORTANT] > Any data entry field that is displayed in the Group Policy page of the Group Policy Editor must be supplied in the encoded XML of the SyncML payload. The SyncML data payload is equivalent to the user-supplied Group Policy data through GPEdit.msc. @@ -145,7 +145,7 @@ The following SyncML examples describe how to set a MDM policy that is defined b 1 2 Replace - 200 + ``` @@ -171,7 +171,7 @@ The following SyncML examples describe how to set a MDM policy that is defined b ./Device/Vendor/MSFT/Policy/Config/AppVirtualization/PublishingAllowServer2 - + ]]> @@ -186,7 +186,7 @@ The following SyncML examples describe how to set a MDM policy that is defined b 1 2 Replace - 200 + ``` @@ -223,7 +223,7 @@ The following SyncML examples describe how to set a MDM policy that is defined b 1 1 Delete - 200 + ``` @@ -249,10 +249,10 @@ Note that the data payload of the SyncML needs to be encoded so that it does not . . . - - - - + + + + . . . @@ -275,7 +275,7 @@ The `text` element simply corresponds to a string and correspondingly to an edit - + ``` @@ -310,14 +310,14 @@ The `multiText` element simply corresponds to a REG_MULTISZ registry string and ```XML - - - - - + explainText="$(string.Virtualization_JITVAllowList_Help)" presentation="$(presentation.Virtualization_JITVAllowList)" + key="SOFTWARE\Policies\Microsoft\AppV\Client\Virtualization" + valueName="ProcessesUsingVirtualComponents"> + + + + + ``` @@ -337,7 +337,7 @@ The `multiText` element simply corresponds to a REG_MULTISZ registry string and ./Device/Vendor/MSFT/Policy/Config/AppVirtualization/VirtualComponentsAllowList - + ]]> @@ -361,7 +361,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar - + ``` @@ -381,7 +381,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar ./User/Vendor/MSFT/Policy/Config/InternetExplorer/DisableSecondaryHomePageChange - + ]]> @@ -413,7 +413,7 @@ Variations of the `list` element are dictated by attributes. These attributes ar ./Device/Vendor/MSFT/Policy/Config/InternetExplorer/DisableUpdateCheck - + ]]> @@ -425,32 +425,32 @@ Variations of the `list` element are dictated by attributes. These attributes ar ```XML - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + ``` @@ -467,8 +467,8 @@ Variations of the `list` element are dictated by attributes. These attributes ar ./Device/Vendor/MSFT/Policy/Config/BitLocker/EncryptionMethodByDriveType - - + + ]]> @@ -482,13 +482,13 @@ Variations of the `list` element are dictated by attributes. These attributes ar ```XML - - - - - + + + + + ``` @@ -504,8 +504,8 @@ Variations of the `list` element are dictated by attributes. These attributes ar ./Device/Vendor/MSFT/Policy/Config/AppVirtualization/StreamingAllowReestablishmentInterval - - + + ]]> @@ -518,25 +518,25 @@ Variations of the `list` element are dictated by attributes. These attributes ar ```XML - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + ``` @@ -557,8 +557,8 @@ Variations of the `list` element are dictated by attributes. These attributes ar ./Device/Vendor/MSFT/Policy/Config/DeviceInstallation/PreventInstallationOfMatchingDeviceSetupClasses - - + + ]]>