mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-13 05:47:23 +00:00
Merge pull request #5660 from MicrosoftDocs/master
Publish 09/16/2021, 3:30 PM
This commit is contained in:
commit
a07048ceae
@ -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](
|
||||
|
||||

|
||||
|
||||
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,7 +206,7 @@ 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:
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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).
|
||||
|
@ -13,9 +13,14 @@ ms.topic: article
|
||||
|
||||
# Create a deployment plan
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
|
||||
A "service management" mindset means that the devices in your organization fall into a continuum, with the software update process being constantly planned, deployed, monitored, and optimized. And once you use this process for feature updates, quality updates become a lightweight procedure that is simple and fast to execute, ultimately increasing velocity.
|
||||
|
||||
When you move to a service management model, you need effective ways of rolling out updates to representative groups of devices. We’ve found that a ring-based deployment works well for us at Microsoft and many other organizations across the globe. Deployment rings in Windows 10 are similar to the deployment groups most organizations constructed for previous major revision upgrades. They are simply a method to separate devices into a deployment timeline.
|
||||
When you move to a service management model, you need effective ways of rolling out updates to representative groups of devices. We’ve found that a ring-based deployment works well for us at Microsoft and many other organizations across the globe. Deployment rings in Windows client are similar to the deployment groups most organizations constructed for previous major revision upgrades. They are simply a method to separate devices into a deployment timeline.
|
||||
|
||||
At the highest level, each “ring” comprises a group of users or devices that receive a particular update concurrently. For each ring, IT administrators set criteria to control deferral time or adoption (completion) that should be met before deployment to the next broader ring of devices or users can occur.
|
||||
|
||||
@ -99,8 +104,7 @@ Once the devices in the Limited ring have had a sufficient stabilization period,
|
||||
In most businesses, the Broad ring includes the rest of your organization. Because of the work in the previous ring to vet stability and minimize disruption (with diagnostic data to support your decision) broad deployment can occur relatively quickly.
|
||||
|
||||
> [!NOTE]
|
||||
> In some instances, you might hold back on mission critical devices (such as medical devices) until deployment in the Broad ring is complete. Get best practices and recommendations for deploying Windows 10 feature
|
||||
> updates to mission critical devices.
|
||||
> In some instances, you might hold back on mission-critical devices (such as medical devices) until deployment in the Broad ring is complete. Get best practices and recommendations for deploying Windows client feature updates to mission critical-devices.
|
||||
|
||||
During the broad deployment phase, you should focus on the following activities:
|
||||
|
||||
@ -116,7 +120,7 @@ Previously, we have provided methods for analyzing your deployments, but these h
|
||||
[Desktop Analytics](/mem/configmgr/desktop-analytics/overview) is a cloud-based service and a key tool in [Microsoft Endpoint Manager](/mem/configmgr/core/understand/microsoft-endpoint-manager-faq). Using artificial intelligence and machine learning, Desktop Analytics is a powerful tool to give you insights and intelligence to
|
||||
make informed decisions about the readiness of your Windows devices.
|
||||
|
||||
In Windows 10 deployments, we have seen compatibility issues on < 0.5% of apps when using Desktop Analytics. Using Desktop Analytics with Microsoft Endpoint Manager can help you assess app compatibility with the latest
|
||||
In Windows client deployments, we have seen compatibility issues on < 0.5% of apps when using Desktop Analytics. Using Desktop Analytics with Microsoft Endpoint Manager can help you assess app compatibility with the latest
|
||||
feature update and create groups that represent the broadest number of hardware and software configurations on the smallest set of devices across your organization. In addition, Desktop Analytics can provide you with a device and software inventory and identify issues, giving you data that equate to actionable decisions.
|
||||
|
||||
> [!IMPORTANT]
|
||||
|
@ -15,34 +15,39 @@ ms.collection: m365initiative-coredeploy
|
||||
|
||||
# Evaluate infrastructure and tools
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
|
||||
Before you deploy an update, it's best to assess your deployment infrastructure (that is, tools such as Configuration Manager, Microsoft Intune, or similar) and current configurations (such as security baselines, administrative templates, and policies that affect updates). Then, set some criteria to define your operational readiness.
|
||||
|
||||
## Infrastructure
|
||||
|
||||
Do your deployment tools need updates?
|
||||
|
||||
- If you use Configuration Manager, is it on the Current Branch with the latest release installed. Being on this branch ensures that it supports the next Windows 10 feature update. Configuration Manager releases are supported for 18 months.
|
||||
- If you use Configuration Manager, is it on the Current Branch with the latest release installed.? Being on this branch ensures that it supports the next Windows client feature update. Configuration Manager releases are supported for 18 months.
|
||||
- Using a cloud-based management tool like Microsoft Intune reduces support challenges, since no related products need to be updated.
|
||||
- If you use a non-Microsoft tool, check with its product support to make sure you're using the current version and that it supports the next Windows 10 feature update.
|
||||
- If you use a non-Microsoft tool, check with its product support to make sure you're using the current version and that it supports the next Windows client feature update.
|
||||
|
||||
Rely on your experiences and data from previous deployments to help you judge how long infrastructure changes take and identify any problems you've encountered while doing so.
|
||||
|
||||
## Device settings
|
||||
|
||||
Make sure your security baseline, administrative templates, and policies have the right settings to support your devices once the new Windows 10 update is installed.
|
||||
Make sure your security baseline, administrative templates, and policies have the right settings to support your devices once the new Windows client update is installed.
|
||||
|
||||
### Security baseline
|
||||
|
||||
Keep security baselines current to help ensure that your environment is secure and that new security feature in the coming Windows 10 update are set properly.
|
||||
Keep security baselines current to help ensure that your environment is secure and that new security feature in the coming Windows client update are set properly.
|
||||
|
||||
- **Microsoft security baselines**: You should implement security baselines from Microsoft. They are included in the [Security Compliance Toolkit](https://www.microsoft.com/download/details.aspx?id=55319), along with tools for managing them.
|
||||
- **Industry- or region-specific baselines**: Your specific industry or region might have particular baselines that you must follow per regulations. Ensure that any new baselines support the version of Windows 10 you are about to deploy.
|
||||
- **Industry- or region-specific baselines**: Your specific industry or region might have particular baselines that you must follow per regulations. Ensure that any new baselines support the version of Windows client you are about to deploy.
|
||||
|
||||
### Configuration updates
|
||||
|
||||
There are a number of Windows policies (set by Group Policy, Intune, or other methods) that affect when Windows updates are installed, deferral, end-user experience, and many other aspects. Check these policies to make sure they are set appropriately.
|
||||
|
||||
- **Windows 10 Administrative templates**: Each Windows 10 feature update has a supporting Administrative template (.admx) file. Group Policy tools use Administrative template files to populate policy settings in the user interface. The templates are available in the Download Center, for example, this one for [Windows 10, version 1909](https://www.microsoft.com/download/100591).
|
||||
- **Windows Administrative templates**: Each Windows client feature update has a supporting Administrative template (.admx) file. Group Policy tools use Administrative template files to populate policy settings in the user interface. The templates are available in the Download Center, for example, this one for [Windows 10, version 1909](https://www.microsoft.com/download/100591).
|
||||
- **Policies for update compliance and end-user experience**: A number of settings affect when a device installs updates, whether and for how long a user can defer an update, restart behavior after installation, and many other aspects of update behavior. It's especially important to look for existing policies that are out of date or could conflict with new ones.
|
||||
|
||||
|
||||
@ -50,9 +55,9 @@ There are a number of Windows policies (set by Group Policy, Intune, or other me
|
||||
|
||||
When you’ve deployed an update, you’ll need to make sure the update isn’t introducing new operational issues. And you’ll also ensure that if incidents arise, the needed documentation and processes are available. Work with your operations and support team to define acceptable trends and what documents or processes require updating:
|
||||
|
||||
- **Call trend**: Define what percentage increase in calls relating to Windows 10 feature updates are acceptable or can be supported.
|
||||
- **Incident trend**: Define what percentage of increase in calls asking for support relating to Windows 10 feature updates are acceptable or can be supported.
|
||||
- **Support documentation**: Review supporting documentation that requires an update to support new infrastructure tooling or configuration as part of the Windows 10 feature update.
|
||||
- **Call trend**: Define what percentage increase in calls relating to Windows client feature updates are acceptable or can be supported.
|
||||
- **Incident trend**: Define what percentage of increase in calls asking for support relating to Windows client feature updates are acceptable or can be supported.
|
||||
- **Support documentation**: Review supporting documentation that requires an update to support new infrastructure tooling or configuration as part of the Windows client feature update.
|
||||
- **Process changes:** Define and update any processes that will change as a result of the Windows 10 feature update.
|
||||
|
||||
Your operations and support staff can help you determine if the appropriate information is being tracked at the moment. If it isn't, work out how to get this information so you can gain the right insight.
|
||||
|
@ -15,6 +15,11 @@ ms.collection: m365initiative-coredeploy
|
||||
|
||||
# Define readiness criteria
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
|
||||
## Figure out roles and personnel
|
||||
|
||||
Planning and managing a deployment involves a variety of distinct activities and roles best suited to each. As you plan, it's worth figuring out which roles you'll need to carry out the deployment and who should fill them. Different roles are active at various phases of a deployment. Depending on the size and complexity of your organization, some of the roles could be filled by the same person. However, it's best to have an established *process manager*, who will oversee all of the tasks for the deployment.
|
||||
|
@ -16,7 +16,12 @@ author: jaimeo
|
||||
|
||||
# Determine application readiness
|
||||
|
||||
Before you deploy a Windows 10 update, you should know which apps will continue to work without problems, which need their own updates, and which just won't work and must be replaced. If you haven't already, it's worth [classifying your apps]<link to plan-define-readiness> with respect to their criticality in your organization.
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
|
||||
Before you deploy a Windows client update, you should know which apps will continue to work without problems, which need their own updates, and which just won't work and must be replaced. If you haven't already, it's worth [classifying your apps](plan-define-readiness.md) with respect to their criticality in your organization.
|
||||
|
||||
## Validation methods
|
||||
|
||||
|
@ -29,7 +29,7 @@ This library describes the Windows Security app, and provides information on con
|
||||
|
||||
In Windows 10, version 1709 and later, the app also shows information from third-party antivirus and firewall apps.
|
||||
|
||||
In Windows 10, version 1803, the app has two new areas, **Account protection** and **Device security**.
|
||||
In Windows 10, version 1803, the app has two new areas: **Account protection** and **Device security**.
|
||||
|
||||

|
||||
|
||||
@ -75,20 +75,20 @@ You can find more information about each section, including options for configur
|
||||
## How the Windows Security app works with Windows security features
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Microsoft Defender AV and the Windows Security app use similarly named services for specific purposes.
|
||||
> Microsoft Defender Antivirus and the Windows Security app use similarly named services for specific purposes.
|
||||
>
|
||||
> The Windows Security app uses the Windows Security Service (*SecurityHealthService* or *Windows Security Health Servce*), which in turn utilizes the Security Center service ([*wscsvc*](/previous-versions/windows/it-pro/windows-xp/bb457154(v=technet.10)#EDAA)) to ensure the app provides the most up-to-date information about the protection status on the endpoint, including protection offered by third-party antivirus products, Windows Defender Firewall, third-party firewalls, and other security protection.
|
||||
>
|
||||
>These services do not affect the state of Microsoft Defender AV. Disabling or modifying these services will not disable Microsoft Defender AV, and will lead to a lowered protection state on the endpoint, even if you are using a third-party antivirus product.
|
||||
>These services do not affect the state of Microsoft Defender Antivirus. Disabling or modifying these services will not disable Microsoft Defender Antivirus, and will lead to a lowered protection state on the endpoint, even if you are using a third-party antivirus product.
|
||||
>
|
||||
>Microsoft Defender AV will be [disabled automatically when a third-party antivirus product is installed and kept up to date]/microsoft-365/security/defender-endpoint/microsoft-defender-antivirus-compatibility).
|
||||
>Microsoft Defender Antivirus will be [disabled automatically when a third-party antivirus product is installed and kept up to date](/microsoft-365/security/defender-endpoint/microsoft-defender-antivirus-compatibility).
|
||||
>
|
||||
> Disabling the Windows Security Center service will not disable Microsoft Defender AV or [Windows Defender Firewall](/windows/access-protection/windows-firewall/windows-firewall-with-advanced-security).
|
||||
> Disabling the Windows Security Center service will not disable Microsoft Defender Antivirus or [Windows Defender Firewall](/windows/access-protection/windows-firewall/windows-firewall-with-advanced-security).
|
||||
|
||||
> [!WARNING]
|
||||
> If you disable the Security Center service, or configure its associated Group Policy settings to prevent it from starting or running, the Windows Security app may display stale or inaccurate information about any antivirus or firewall products you have installed on the device.
|
||||
>
|
||||
> It may also prevent Microsoft Defender AV from enabling itself if you have an old or outdated third-party antivirus, or if you uninstall any third-party antivirus products you may have previously installed.
|
||||
> It may also prevent Microsoft Defender Antivirus from enabling itself if you have an old or outdated third-party antivirus, or if you uninstall any third-party antivirus products you may have previously installed.
|
||||
>
|
||||
> This will significantly lower the protection of your device and could lead to malware infection.
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user