From 94f22f88be0fcbe8a20e8ab972e3a815719aaa8f Mon Sep 17 00:00:00 2001 From: Meghan Stewart <33289333+mestew@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:44:28 -0700 Subject: [PATCH 01/78] legacy-drmsrv-dep-9183757 --- windows/whats-new/deprecated-features.md | 1 + 1 file changed, 1 insertion(+) diff --git a/windows/whats-new/deprecated-features.md b/windows/whats-new/deprecated-features.md index 4c4a6712c3..5c7db25ea6 100644 --- a/windows/whats-new/deprecated-features.md +++ b/windows/whats-new/deprecated-features.md @@ -47,6 +47,7 @@ The features in this article are no longer being actively developed, and might b | Feature | Details and mitigation | Deprecation announced | |---|---|---| +| Legacy DRM services | Legacy DRM services, typically used by either Windows Media Player, Windows 7, or Windows 8 clients are deprecated. The following functionality will no longer work when these services are fully retired:
diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md index b7800e6cab..429942a06d 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md @@ -1,7 +1,7 @@ --- title: Windows Autopatch groups overview description: This article explains what Autopatch groups are -ms.date: 07/08/2024 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: concept-article @@ -15,13 +15,19 @@ ms.collection: - tier1 --- -# Windows Autopatch groups overview +# Windows Autopatch groups -As organizations move to a managed-service model where Microsoft manages update processes on their behalf, they're challenged with having the right representation of their organizational structures followed by their own deployment cadence. Windows Autopatch groups help organizations manage updates in a way that makes sense for their businesses with no extra cost or unplanned disruptions. +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + +As organizations move to a managed-service model where Microsoft manages update processes on their behalf, they’re challenged with having the right representation of their organizational structures followed by their own deployment cadence. Windows Autopatch groups help organizations manage updates in a way that makes sense for their businesses with no extra cost or unplanned disruptions. ## What are Windows Autopatch groups? -Autopatch groups is a logical container or unit that groups several [Microsoft Entra groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates). +An Autopatch group is a logical container or unit that groups several [Microsoft Entra groups](/entra/fundamentals/groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates). + +Autopatch groups are intended to help organizations that require a more precise representation of their organization's structures along with their own update deployment cadence in the service. + +By default, an Autopatch group has the Test and Last deployment rings automatically present. For more information, see [Test and Last deployment rings](#test-and-last-deployment-rings). ## Key benefits @@ -31,101 +37,41 @@ Autopatch groups help Microsoft Cloud-Managed services meet organizations where | ----- | ----- | | Replicating your organizational structure | You can set up Autopatch groups to replicate your organizational structures represented by your existing device-based Microsoft Entra group targeting logic. | | Having a flexible number of deployments | Autopatch groups give you the flexibility of having the right number of deployment rings that work within your organization. You can set up to 15 deployment rings per Autopatch group. | -| Deciding which device(s) belong to deployment rings | Along with using your existing device-based Microsoft Entra groups and choosing the number of deployment rings, you can also decide which devices belong to deployment rings during the device registration process when setting up Autopatch groups. | +| Deciding which devices belong to deployment rings | Along with using your existing device-based Microsoft Entra groups and choosing the number of deployment rings, you can also decide which devices belong to deployment rings during the device distribution process when setting up Autopatch groups. | | Choosing the deployment cadence | You choose the right software update deployment cadence for your business. | +## Prerequisites + +Before you start managing Autopatch groups, ensure you meet the following prerequisites: + +| Prerequisite | Details | +| --- | --- | +| Review [Windows Autopatch groups overview documentation](../deploy/windows-autopatch-groups-overview.md) | Understand [key benefits](../deploy/windows-autopatch-groups-overview.md#key-benefits) and [common ways to use Autopatch groups](../deploy/windows-autopatch-groups-overview.md#common-ways-to-use-autopatch-groups) within your organization. | +| Make sure you have [app-only auth turned on in your Windows Autopatch tenant](../monitor/windows-autopatch-maintain-environment.md#windows-autopatch-tenant-actions). Otherwise, the Autopatch groups functionality doesn't work properly. Autopatch uses app-only auth to: | | +| Make sure that all device-based Microsoft Entra groups you intend to use with Autopatch groups are created before using the feature. | Review your existing Microsoft Entra group dynamic queries and direct device memberships to: | +| Ensure devices used with your existing Microsoft Entra groups meet [device registration prerequisite checks](../deploy/windows-autopatch-register-devices.md#prerequisites-for-device-registration) when being registered with the service | Autopatch groups register devices on your behalf, and device readiness states are determined based on the registration state and if any applicable alerts are targeting the device. For more information, see the [Devices report](../deploy/windows-autopatch-register-devices.md#devices-report). | + +> [!TIP] +> [Update rings](/mem/intune/protect/windows-10-update-rings) and [feature updates](/mem/intune/protect/windows-10-feature-updates) for Windows 10 and later policies that are created and managed by Windows Autopatch can be restored using the [Policy health](../monitor/windows-autopatch-policy-health-and-remediation.md) feature. For more information on remediation actions, see [restore Windows update policies](../monitor/windows-autopatch-policy-health-and-remediation.md#restore-windows-update-policies). + +## Register devices into Autopatch groups + +Autopatch groups register devices with the Windows Autopatch service when you either [create](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group). For more information, see [Register devices into Autopatch groups](../deploy/windows-autopatch-register-devices.md#register-devices-into-autopatch-groups). + ## High-level architecture diagram overview :::image type="content" source="../media/windows-autopatch-groups-high-level-architecture-diagram.png" alt-text="Overview of the device registration process" lightbox="../media/windows-autopatch-groups-high-level-architecture-diagram.png"::: -Autopatch groups is a function app that is part of the device registration micro service within the Windows Autopatch service. The following table explains the high-level workflow: +An Autopatch group is a function app that is part of the device registration micro service within the Windows Autopatch service. The following table explains the high-level workflow: | Step | Description | | ----- | ----- | -| Step 1: Create an Autopatch group | Create an Autopatch group. | -| Step 2: Windows Autopatch uses Microsoft Graph to create Microsoft Entra ID and policy assignments | Windows Autopatch service uses Microsoft Graph to coordinate the creation of: | +| Step 1: Create an Autopatch group | Create an Autopatch group. Autopatch groups register devices with the Windows Autopatch service when you either [create](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group). | +| Step 2: Windows Autopatch uses Microsoft Graph to create Microsoft Entra ID and policy assignments | Windows Autopatch service uses Microsoft Graph to coordinate the creation of: | | Step 3: Intune assigns software update policies | Once Microsoft Entra groups are created in the Microsoft Entra service, Intune is used to assign the software update policies to these groups and provide the number of devices that need the software update policies to the Windows Update for Business (WUfB) service. | | Step 4: Windows Update for Business responsibilities | Windows Update for Business (WUfB) is the service responsible for: | -## Key concepts - -There are a few key concepts to be familiar with before using Autopatch groups. - -### About the Default Autopatch group - -> [!NOTE] -> The Default Autopatch group is recommended for organizations that can meet their business needs using the pre-configured five deployment ring composition. - -The Default Autopatch group uses Windows Autopatch's default update management process recommendation. The Default Autopatch group contains: - -- A set of **[five deployment rings](#default-deployment-ring-composition)** -- A default update deployment cadence for both [Windows quality](../operate/windows-autopatch-groups-windows-quality-update-overview.md) and [feature updates](../operate/windows-autopatch-groups-windows-feature-update-overview.md). - -The Default Autopatch group is intended to serve organizations that are looking to: - -- Enroll into the service -- Align to Windows Autopatch's default update management process without requiring more customizations. - -The Default Autopatch group **can't** be deleted or renamed. However, you can customize its deployment ring composition to add and/or remove deployment rings, and you can also customize the update deployment cadences for each deployment ring within it. - -#### Default deployment ring composition - -By default, the following [software update-based deployment rings](#software-based-deployment-rings), represented by Microsoft Entra ID assigned groups, are used: - -- Windows Autopatch - Test -- Windows Autopatch - Ring1 -- Windows Autopatch - Ring2 -- Windows Autopatch - Ring3 -- Windows Autopatch - Last - -**Windows Autopatch - Test** and **Last** can be only used as **Assigned** device distributions. **Windows Autopatch - Ring1**, **Ring2** and **Ring3** can be used with either **Assigned** or **Dynamic** device distributions, or have a combination of both device distribution types. - -> [!TIP] -> For more information about the differences between **Assigned** and **Dynamic** deployment ring distribution types, see [about deployment rings](#about-deployment-rings). Only deployment rings that are placed in between the **Test** and the **Last** deployment rings can be used with the **Dynamic** deployment ring distributions. - -> [!CAUTION] -> These and other Microsoft Entra ID assigned groups created by Autopatch groups **can't** be missing in your tenant, otherwise, Autopatch groups might not function properly. - -The **Last** deployment ring, the fifth deployment ring in the Default Autopatch group, is intended to provide coverage for scenarios where a group of specialized devices and/or VIP/Executive users. They must receive software update deployments after the organization's general population to mitigate disruptions to your organization's critical businesses. - -#### Default update deployment cadences - -The Default Autopatch group provides a default update deployment cadence for its deployment rings except for the **Last** (fifth) deployment ring. - -##### Update rings policy for Windows 10 and later - -Autopatch groups set up the [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) for each of its deployment rings in the Default Autopatch group. See the following default policy values: - -| Policy name | Microsoft Entra group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline | -| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | -| Windows Autopatch Update Policy - default - Test | Windows Autopatch - Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes | -| Windows Autopatch Update Policy - default - Ring1 | Windows Autopatch - Ring1 | 1 | 0 | 30 | 2 | 5 |2 | Yes | -| Windows Autopatch Update Policy - default - Ring2 | Windows Autopatch - Ring2 | 6 | 0 | 30 | 2 | 5 | 2 | Yes | -| Windows Autopatch Update Policy - default - Ring3 | Windows Autopatch - Ring3 | 9 | 0 | 30 | 5 | 5 | 2 | Yes | -| Windows Autopatch Update Policy - default - Last | Windows Autopatch - Last | 11 | 0 | 30 | 3 | 5 | 2 | Yes | - -##### Feature update policy for Windows 10 and later - -Autopatch groups set up the [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates) for each of its deployment rings in the Default Autopatch group, see the following default policy values: - -| Policy name | Microsoft Entra group assignment |Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date | -| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | -| Windows Autopatch - DSS Policy [Test] | Windows Autopatch - Test | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024; 1:00AM | -| Windows Autopatch - DSS Policy [Ring1] | Windows Autopatch - Ring1 | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024; 1:00AM | -| Windows Autopatch - DSS Policy [Ring2] | Windows Autopatch - Ring2 | Windows 10 21H2 | Make update available as soon as possible | December 14, 2022 | December 21, 2022 | 1 | June 11, 2024; 1:00AM | -| Windows Autopatch - DSS Policy [Ring3] | Windows Autopatch - Ring3 | Windows 10 21H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | June 11, 2024; 1:00AM | -| Windows Autopatch - DSS Policy [Last] | Windows Autopatch - Last | Windows 10 21H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | June 11, 2024; 1:00AM | - -### About Custom Autopatch groups - -> [!NOTE] -> The [Default Autopatch group](#about-the-default-autopatch-group) is recommended for organizations that can meet their business needs using the pre-configured five deployment ring composition. - -Custom Autopatch groups are intended to help organizations that require a more precise representation of their organization's structures along with their own update deployment cadence in the service. - -By default, a Custom Autopatch group has the Test and Last deployment rings automatically present. For more information, see [Test and Last deployment rings](#about-the-test-and-last-deployment-rings). - -### About deployment rings +## Autopatch group deployment rings Deployment rings make it possible for an Autopatch group to have software update deployments sequentially delivered in a gradual rollout within the Autopatch group. @@ -137,92 +83,38 @@ Windows Autopatch aligns with Microsoft Entra ID and Intune terminology for devi | Assigned | You can use one single device-based Microsoft Entra group, either dynamic query-based, or assigned to use in your deployment ring composition. | | Combination of Dynamic and Assigned | To provide a greater level of flexibility when working on deployment ring compositions, you can combine both device distribution types in Autopatch groups.

The combination of Dynamic and Assigned device distribution is **not** supported for the Test and Last deployment ring in Autopatch groups.

| -#### About the Test and Last deployment rings +### Test and Last deployment rings -Both the **Test** and **Last** deployment rings are default deployment rings that are automatically present in the Default Autopatch group and Custom Autopatch groups. These default deployment rings provide the recommended minimum number of deployment rings that an Autopatch group should have. +Both the **Test** and **Last** deployment rings are default deployment rings that are automatically present in an Autopatch group. These default deployment rings provide the recommended minimum number of deployment rings that an Autopatch group should have. -If you only keep Test and Last deployment rings in your Default Autopatch group, or you don't add more deployment rings when creating a Custom Autopatch group, the Test deployment ring can be used as the pilot deployment ring and Last can be used as the production deployment ring. +If you don't add more deployment rings when creating an Autopatch group, the Test deployment ring can be used as the pilot deployment ring and Last can be used as the production deployment ring. > [!IMPORTANT] -> Both the **Test** and **Last** deployment rings **can't** be removed or renamed from the Default or Custom Autopatch groups. Autopatch groups don't support the use of one single deployment ring as part of its deployment ring composition because you need at least two deployment rings for their gradual rollout. If you must implement a specific scenario with a single deployment ring, and gradual rollout isn't required, consider managing these devices outside Windows Autopatch. +> Both the **Test** and **Last** deployment rings **can't** be removed or renamed from Autopatch groups. Autopatch groups don't support the use of one single deployment ring as part of its deployment ring composition because you need **at least two deployment rings** for their gradual rollout. If you must implement a specific scenario with a single deployment ring, and gradual rollout isn't required, consider managing these devices outside Autopatch groups. > [!TIP] > Both the **Test** and **Last** deployment rings only support one single Microsoft Entra group assignment at a time. If you need to assign more than one Microsoft Entra group, you can nest the other Microsoft Entra groups under the ones you plan to use with the **Test** and **Last** deployment rings. Only one level of Microsoft Entra group nesting is supported. -#### Service-based versus software update-based deployment rings - -Autopatch groups creates two different layers. Each layer contains its own deployment ring set. - -> [!IMPORTANT] -> Both service-based and software update-based deployment ring sets are, by default, assigned to devices that successfully register with Windows Autopatch. - -##### Service-based deployment rings - -The service-based deployment ring set is exclusively used to keep Windows Autopatch updated with both service and device-level configuration policies, apps and APIs needed for core functions of the service. - -The following are the Microsoft Entra ID assigned groups that represent the service-based deployment rings. These groups can't be deleted or renamed: - -- Modern Workplace Devices-Windows Autopatch-Test -- Modern Workplace Devices-Windows Autopatch-First -- Modern Workplace Devices-Windows Autopatch-Fast -- Modern Workplace Devices-Windows Autopatch-Broad - -> [!CAUTION] -> **Don't** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won't be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly.

Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.

- -##### Software-based deployment rings - -The software-based deployment ring set is exclusively used with software update management policies, such as the Windows update ring and feature update policies, in the Default Windows Autopatch group. - -The following are the Microsoft Entra ID assigned groups that represent the software updates-based deployment rings. These groups can't be deleted or renamed: - -- Windows Autopatch - Test -- Windows Autopatch - Ring1 -- Windows Autopatch - Ring2 -- Windows Autopatch - Ring3 -- Windows Autopatch - Last - -> [!IMPORTANT] -> Additional Microsoft Entra ID assigned groups are created and added to list when you add more deployment rings to the Default Autopatch group. - -> [!CAUTION] -> **Don't** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won't be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly.

Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.

- -### About device registration - -Autopatch groups register devices with the Windows Autopatch service when you either [create](../manage/windows-autopatch-manage-autopatch-groups.md#create-a-custom-autopatch-group) or [edit a Custom Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group), and/or when you [edit the Default Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) to use your existing Microsoft Entra groups instead of the Windows Autopatch Device Registration group provided by the service. - ## Common ways to use Autopatch groups The following are three common uses for using Autopatch groups. ### Use case #1 -> [!NOTE] -> The [Default Autopatch group](#about-the-default-autopatch-group) is recommended for organizations that can meet their business needs using the pre-configured five deployment ring composition. - | Scenario | Solution | | ----- | ----- | -| You're working as the IT admin at Contoso Ltd. And manage several Microsoft and non-Microsoft cloud services. You don't have extra time to spend setting up and managing several Autopatch groups.

Your organization currently operates its update management by using five deployment rings, but there's an opportunity to have flexible deployment cadences if it's precommunicated to your end-users.

| If you don't have thousands of devices to manage, use the Default Autopatch group for your organization. You can edit the Default Autopatch group to include additional deployment rings and/or slightly modify some of its default deployment cadences.

The Default Autopatch group is preconfigured and doesn't require extra configurations when registering devices with the Windows Autopatch service.

The following is a visual representation of a gradual rollout for the Default Autopatch group preconfigured and fully managed by the Windows Autopatch service.

| - -:::image type="content" source="../media/autopatch-groups-default-autopatch-group.png" alt-text="Default Autopatch group" lightbox="../media/autopatch-groups-default-autopatch-group.png"::: - -### Use case #2 - -| Scenario | Solution | -| ----- | ----- | -| You're working as the IT admin at Contoso Ltd. Your organization needs to plan a gradual rollout of software updates within specific critical business units or departments to help mitigate the risk of end-user disruption. | You can create a Custom Autopatch group for each of your business units. For example, you can create a Custom Autopatch group for the finance department and breakdown the deployment ring composition per the different user personas or based on how critical certain user groups can be for the department and then for the business.

The following is a visual representation of a gradual rollout for Contoso's Finance department.

| +| You're working as the IT admin at Contoso Ltd. Your organization needs to plan a gradual rollout of software updates within specific critical business units or departments to help mitigate the risk of end-user disruption. | You can create an Autopatch group for each of your business units. For example, you can create an Autopatch group for the finance department and breakdown the deployment ring composition per the different user personas or based on how critical certain user groups can be for the department and then for the business.

The following is a visual representation of a gradual rollout for Contoso’s Finance department.

| :::image type="content" source="../media/autopatch-groups-finance-department-example.png" alt-text="Finance department example" lightbox="../media/autopatch-groups-finance-department-example.png"::: > [!IMPORTANT] > Once Autopatch groups are setup, the release of either Windows quality or feature updates will be deployed sequentially through its deployment rings. -### Use case #3 +### Use case #2 | Scenario | Solution | | ----- | ----- | -| You're working as the IT admin at Contoso Ltd. Your branch location in Chicago needs to plan a gradual rollout of software updates within specific departments to make sure the Chicago office doesn't experience disruptions in its operations. | You can create a Custom Autopatch group for the branch location in Chicago and breakdown the deployment ring composition per the departments within the branch location.

The following is a visual representation of a gradual rollout for the Contoso Chicago branch location.

| +| You're working as the IT admin at Contoso Ltd. Your branch location in Chicago needs to plan a gradual rollout of software updates within specific departments to make sure the Chicago office doesn’t experience disruptions in its operations. | You can create an Autopatch group for the branch location in Chicago and breakdown the deployment ring composition per the departments within the branch location.

The following is a visual representation of a gradual rollout for the Contoso Chicago branch location.

| :::image type="content" source="../media/autopatch-groups-contoso-chicago-example.png" alt-text="Contoso Chicago example" lightbox="../media/autopatch-groups-contoso-chicago-example.png"::: @@ -235,16 +127,19 @@ The following configurations are supported when using Autopatch groups. ### Software update workloads -Autopatch groups works with the following software update workloads: +Autopatch groups work with the following software update workloads: -- [Windows quality updates](../operate/windows-autopatch-groups-windows-quality-update-overview.md) -- [Windows feature updates](../operate/windows-autopatch-groups-windows-feature-update-overview.md) +- [Windows feature updates](../manage/windows-autopatch-windows-feature-update-overview.md) +- [Windows quality updates](../manage/windows-autopatch-windows-quality-update-overview.md) +- [Driver and firmware updates](../manage/windows-autopatch-manage-driver-and-firmware-updates.md) +- [Microsoft 365 Apps for enterprise](../manage/windows-autopatch-microsoft-365-apps-enterprise.md) +- [Microsoft Edge](../manage/windows-autopatch-edge.md) ### Maximum number of Autopatch groups -Windows Autopatch supports up to 50 Autopatch groups in your tenant. You can create up to 49 [Custom Autopatch groups](#about-custom-autopatch-groups) in addition to the [Default Autopatch group](#about-the-default-autopatch-group). Each Autopatch group supports up to 15 deployment rings. +Windows Autopatch supports up to 50 Autopatch groups in your tenant. Each Autopatch group supports up to 15 deployment rings. -> [!TIP] -> If you reach the maximum number of Autopatch groups supported (50), and try to create more Custom Autopatch groups, the "**Create**" option in the Autopatch groups blade will be greyed out. +> [!NOTE] +> If you reach the maximum number of Autopatch groups supported (50), and try to create more Autopatch groups, the "Create" option in the Autopatch groups blade will be greyed out. -To manage your Autopatch groups, see [Manage Windows Autopatch groups](../deploy/windows-autopatch-groups-manage-autopatch-groups.md). +To manage your Autopatch groups, see [Manage Windows Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md). diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md index a8ddab157a..c5f450553f 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md @@ -1,7 +1,7 @@ --- title: Post-device registration readiness checks description: This article details how post-device registration readiness checks are performed in Windows Autopatch -ms.date: 07/08/2024 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: concept-article @@ -15,14 +15,13 @@ ms.collection: - tier1 --- -# Post-device registration readiness checks (public preview) +# Post-device registration readiness checks -> [!IMPORTANT] -> This feature is in "public preview". It is being actively developed, and may not be complete. They're made available on a "Preview" basis. You can test and use these features in production environments and scenarios, and provide feedback. +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] One of the most expensive aspects of the software update management process is to make sure devices are always healthy to receive and report software updates for each software update release cycle. -Having a way of measuring, quickly detecting and remediating when something goes wrong with on-going change management processes is important; it helps mitigate high Helpdesk ticket volumes, reduces cost, and improves overall update management results. +Having a way of measuring, quickly detecting and remediating when something goes wrong with ongoing change management processes is important; it helps mitigate high Helpdesk ticket volumes, reduces cost, and improves overall update management results. Windows Autopatch provides proactive device readiness information about devices that are and aren't ready to be fully managed by the service. IT admins can easily detect and fix device-related issues that are preventing them from achieving their update management compliance report goals. @@ -37,13 +36,13 @@ Device readiness in Windows Autopatch is divided into two different scenarios: ### Device readiness checks available for each scenario -| Required device readiness (prerequisite checks) prior to device registration (powered by Intune Graph API) | Required post-device registration readiness checks (powered by Microsoft Cloud Managed Desktop Extension) | +| Required device readiness (prerequisite checks) before device registration (powered by Intune Graph API) | Required post-device registration readiness checks (powered by Microsoft Cloud Managed Desktop Extension) | | ----- | ----- | -| | | +| | | -The status of each post-device registration readiness check is shown in the Windows Autopatch's Devices blade under the **Not ready** tab. You can take appropriate action(s) on devices that aren't ready to be fully managed by the Windows Autopatch service. +The status of each post-device registration readiness check is shown in the Windows Autopatch's Devices blade under the **Not registered** tab. You can take appropriate actions on devices that aren't ready to be fully managed by the Windows Autopatch service. -## About the three tabs in the Devices blade +## Devices blade: Registered and Not registered tabs You deploy software updates to secure your environment, but these deployments only reach healthy and active devices. Unhealthy or not ready devices affect the overall software update compliance. @@ -52,13 +51,12 @@ Figuring out device health can be challenging and disruptive to the end user whe - Obtain proactive data sent by the device to the service, or - Proactively detect and remediate issues -Windows Autopatch has three tabs within its Devices blade. Each tab is designed to provide a different set of device readiness statuses so IT admins know where to go to monitor, and remediate potential device health issues: +Windows Autopatch has devices readiness states within its [**Devices report**](../deploy/windows-autopatch-register-devices.md#devices-report). Each state provides IT admins monitoring information on which devices might have potential device health issues. | Tab | Description | | ----- | ----- | -| Ready | This tab only lists devices with the **Active** status. Devices with the **Active** status successfully:This tab also lists devices that have passed all postdevice registration readiness checks. | -| Not ready | This tab only lists devices with the **Readiness failed** and **Inactive** status. | -| Not registered | Only lists devices with the **Prerequisite failed** status in it. Devices with the **Prerequisite failed** status didn't pass one or more prerequisite checks during the device registration process. | +| Registered | | +| Not registered || ## Details about the post-device registration readiness checks @@ -68,7 +66,7 @@ A healthy or active device in Windows Autopatch is: - Actively sending data - Passes all post-device registration readiness checks -The post-device registration readiness checks are powered by the **Microsoft Cloud Managed Desktop Extension**. It's installed right after devices are successfully registered with Windows Autopatch. The **Microsoft Cloud Managed Desktop Extension** has the Device Readiness Check Plugin. The Device Readiness Check Plugin is responsible for performing the readiness checks and reporting the results back to the service. The **Microsoft Cloud Managed Desktop Extension** is a sub-component of the overall Windows Autopatch service. +The post-device registration readiness checks are powered by the **Microsoft Cloud Managed Desktop Extension**. It's installed right after devices are successfully registered with Windows Autopatch. The **Microsoft Cloud Managed Desktop Extension** has the Device Readiness Check Plugin. The Device Readiness Check Plugin is responsible for performing the readiness checks and reporting the results back to the service. The **Microsoft Cloud Managed Desktop Extension** is a subcomponent of the overall Windows Autopatch service. The following list of post-device registration readiness checks is performed in Windows Autopatch: @@ -95,16 +93,16 @@ See the following diagram for the post-device registration readiness checks work | **Step 8: Perform readiness checks** |
  1. Once devices are successfully registered with Windows Autopatch, the devices are added to the **Ready** tab.
  2. The Microsoft Cloud Managed Desktop Extension agent performs readiness checks against devices in the **Ready** tab every 24 hours.
| | **Step 9: Check readiness status** |
  1. The Microsoft Cloud Managed Desktop Extension service evaluates the readiness results gathered by its agent.
  2. The readiness results are sent from the Microsoft Cloud Managed Desktop Extension service component to the Device Readiness component within the Windows Autopatch's service.
| | **Step 10: Add devices to the Not ready** | When devices don't pass one or more readiness checks, even if they're registered with Windows Autopatch, they're added to the **Not ready** tab so IT admins can remediate devices based on Windows Autopatch recommendations. | -| **Step 11: IT admin understands what the issue is and remediates** | The IT admin checks and remediates issues in the Devices blade (**Not ready** tab). It can take up to 24 hours for devices to show back up into the **Ready** tab. | +| **Step 11: IT admin understands what the issue is and remediates** | The IT admin checks and remediates issues in the Devices blade (**Not ready** tab). It can take up to 24 hours for devices to show in the **Ready** tab. | ## FAQ | Question | Answer | | ----- | ----- | | **How frequent are the post-device registration readiness checks performed?** || -| **What to expect when one or more checks fail?** | Devices are automatically sent to the **Ready** tab once they're successfully registered with Windows Autopatch. When devices don't meet one or more post-device registration readiness checks, the devices are moved to the **Not ready** tab. IT admins can learn about these devices and take appropriate actions to remediate them. Windows Autopatch will provide information about the failure and how to potentially remediate devices.

Once devices are remediated, it can take up to **24 hours** to show up in the **Ready** tab.

| +| **What to expect when one or more checks fail?** | Devices are automatically sent to the **Ready** tab once they're successfully registered with Windows Autopatch. When devices don't meet one or more post-device registration readiness checks, the devices are moved to the **Not ready** tab. IT admins can learn about these devices and take appropriate actions to remediate them. Windows Autopatch provides information about the failure and how to potentially remediate devices.

Once devices are remediated, it can take up to **24 hours** to appear in the **Ready** tab.

| ## Additional resources -- [Device registration overview](windows-autopatch-device-registration-overview.md) -- [Register your devices](windows-autopatch-register-devices.md) +- [Device registration overview](../deploy/windows-autopatch-device-registration-overview.md) +- [Register your devices](../deploy/windows-autopatch-register-devices.md) diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md index 5f9eee104c..7dc6bc9a67 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md @@ -1,7 +1,7 @@ --- title: Register your devices description: This article details how to register devices in Autopatch. -ms.date: 07/10/2024 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -17,29 +17,106 @@ ms.collection: # Register your devices -Before Microsoft can manage your devices in Windows Autopatch, you must have devices registered with the service. +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] -## Before you begin +Before Microsoft can manage your devices in Windows Autopatch, you must register devices with the service. Make sure your devices meet the [device registration prerequisites](../deploy/windows-autopatch-device-registration-overview.md#prerequisites-for-device-registration). -Windows Autopatch can take over software update management control of devices that meet software-based prerequisites as soon as an IT admin decides to have their tenant managed by the service. The Windows Autopatch software update management scope includes the following software update workloads: +## Detailed device registration workflow diagram -- [Windows quality updates](../operate/windows-autopatch-groups-windows-quality-update-overview.md) -- [Windows feature updates](../operate/windows-autopatch-groups-windows-feature-update-overview.md) -- [Microsoft 365 Apps for enterprise updates](../operate/windows-autopatch-microsoft-365-apps-enterprise.md) -- [Microsoft Edge updates](../operate/windows-autopatch-edge.md) -- [Microsoft Teams updates](../operate/windows-autopatch-teams.md) +See the following detailed workflow diagram. The diagram covers the Windows Autopatch device registration process: -### Windows Autopatch groups device registration +:::image type="content" source="../media/windows-autopatch-device-registration-workflow-diagram.png" alt-text="Detailed device registration workflow diagram" lightbox="../media/windows-autopatch-device-registration-workflow-diagram.png"::: -When you either create/edit a [Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups) or edit the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) to add or remove deployment rings, the device-based Microsoft Entra groups you use when setting up your deployment rings are scanned to see if devices need to be registered with the Windows Autopatch service. +| Step | Description | +| ----- | ----- | +| **Step 1: Identify devices** | IT admin identifies devices to be managed by the Windows Autopatch service. | +| **Step 2: Add devices** | IT admin identifies and adds devices, or nests other Microsoft Entra device groups into any Microsoft Entra group when you [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group) or imported (WUfB) policies. | +| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function discovers devices (hourly) that were previously added by the IT admin from Microsoft Entra groups used with Autopatch groups in **step #2**. The Microsoft Entra device ID is used by Windows Autopatch to query device attributes in both Microsoft Intune and Microsoft Entra ID when registering devices into its service.
  1. Once devices are discovered from the Microsoft Entra group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Microsoft Entra ID in this step:
    1. **AzureADDeviceID**
    2. **OperatingSystem**
    3. **DisplayName (Device name)**
    4. **AccountEnabled**
    5. **RegistrationDateTime**
    6. **ApproximateLastSignInDateTime**
  2. In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements before registration.
| +| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:
  1. **If the device is Intune-managed or not.**
    1. Windows Autopatch looks to see **if the Microsoft Entra device ID has an Intune device ID associated with it**.
      1. If **yes**, it means this device is enrolled into Intune.
      2. If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.
    2. **If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name, and other attributes. When this happens, the Windows Autopatch service uses the Microsoft Entra device attributes gathered and saved to its memory in **step 3a**.
      1. Once it has the device attributes gathered from Microsoft Entra ID in **step 3a**, the device is flagged with the **Prerequisite failed** status, and the device's Autopatch readiness status appears as **Not registered** in the [**Devices report**](#devices-report). The IT admin can review the reasons the device wasn't registered into Windows Autopatch. The IT admin remediates these devices. In this case, the IT admin should check why the device wasn't enrolled into Intune.
      2. A common reason is when the Microsoft Entra device ID is stale, it doesn't have an Intune device ID associated with it anymore. To remediate, [clean up any stale Microsoft Entra device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).
    3. **If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device checked into Intune in the last 28 days.
  2. **If the device is a Windows device or not.**
    1. Windows Autopatch looks to see if the device is a Windows and corporate-owned device.
      1. **If yes**, it means this device can be registered with the service because it's a Windows corporate-owned device.
      2. **If not**, it means the device is a non-Windows device, or it's a Windows device but it's a personal device.
  3. **Windows Autopatch checks the Windows SKU family**. The SKU must be either:
    1. **Enterprise**
    2. **Pro**
    3. **Pro Workstation**
  4. **If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:
    1. **Only managed by Intune.**
      1. If the device is only managed by Intune, the device is marked as Passed all prerequisites.
    2. **Co-managed by both Configuration Manager and Intune.**
      1. If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:
        1. **Windows Updates Policies**
        2. **Device Configuration**
        3. **Office Click to Run**
      2. If Windows Autopatch determines that one of these workloads isn't enabled on the device, the service marks the device as **Prerequisite failed** and the device's Autopatch readiness status appears as **Not registered** in the **Devices report**.
| +| **Step 5: Calculate deployment ring assignment** | Once the device passes all prerequisites described in **step #4**, Windows Autopatch starts its deployment ring assignment calculation. The following logic is used to calculate the Windows Autopatch deployment ring assignment:
  1. If the Windows Autopatch tenant's existing managed device size is **≤ 200**, the deployment ring assignment is **First (5%)**, **Fast (15%)**, remaining devices go to the **Broad ring (80%)**.
  2. If the Windows Autopatch tenant's existing managed device size is **>200**, the deployment ring assignment is **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.
| +| **Step 6: Assign devices to a deployment ring group** | Once the deployment ring calculation is done, Windows Autopatch assigns devices to two deployment ring sets, the first one being the service-based deployment ring set represented by the following Microsoft Entra groups:
  1. **Modern Workplace Devices-Windows Autopatch-First**
    1. The Windows Autopatch device registration process doesn't automatically assign devices to the Test ring represented by the Microsoft Entra group (**Modern Workplace Devices-Windows Autopatch-Test**). It's important that you assign devices to the Test ring to validate the update deployments before the updates are deployed to a broader population of devices.
  2. **Modern Workplace Devices-Windows Autopatch-Fast**
  3. **Modern Workplace Devices-Windows Autopatch-Broad**
    4. | +| **Step 7: Assign devices to a Microsoft Entra group** | Windows Autopatch also assigns devices to the following Microsoft Entra groups when certain conditions apply:
    1. **Modern Workplace Devices - All**
      1. This group has all devices managed by Windows Autopatch.
    2. **Modern Workplace Devices - Virtual Machine**
      1. This group has all **virtual devices** managed by Windows Autopatch.
      | +| **Step 8: Post-device registration** | In post-device registration, three actions occur:
      1. Windows Autopatch adds devices to its managed database.
      2. Flags devices as **Ready**. The device's Autopatch readiness status appears as **Registered** in the **Devices report**.
      3. The Microsoft Entra device ID of the device successfully registered is added into the Microsoft Cloud Managed Desktop Extension's allowlist. Windows Autopatch installs the Microsoft Cloud Managed Desktop Extension agent once devices are registered, so the agent can communicate back to the Microsoft Cloud Managed Desktop Extension service.
        1. The agent is the **Modern Workplace - Autopatch Client setup** PowerShell script that was created during the Windows Autopatch tenant enrollment process. The script is executed once devices are successfully registered into the Windows Autopatch service.
        | +| **Step 9: Review device registration status** | IT admins review the device's Autopatch readiness status. Devices are either **Registered** or **Not registered** in the **Devices report**.
        1. If the device was **successfully registered**, the device's Autopatch readiness status appears as **Registered** in the **Devices report**.
        2. If **not**, the device's Autopatch readiness status appears as **Not registered** in the **Devices report**.
        | +| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. | -If devices aren't registered, Autopatch groups starts the device registration process by using your existing device-based Microsoft Entra groups instead of the Windows Autopatch Device Registration group. +## Detailed prerequisite check workflow diagram -For more information, see [create Custom Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md#create-a-custom-autopatch-group) and [edit Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) to register devices using the Autopatch groups device registration method. +As described in **step #4** in the previous [Detailed device registration workflow diagram](#detailed-device-registration-workflow-diagram), the following diagram is a visual representation of the prerequisite construct for the Windows Autopatch device registration process. The prerequisite checks are sequentially performed. - +:::image type="content" source="../media/windows-autopatch-prerequisite-check-workflow-diagram.png" alt-text="Detailed prerequisite check workflow diagram" lightbox="../media/windows-autopatch-prerequisite-check-workflow-diagram.png"::: -#### Supported scenarios when nesting other Microsoft Entra groups +## Devices report + +Windows Autopatch has a device report that allows you to see: + +- Each registered devices readiness for the service +- Update status +- Policies that target each device + +### View the device report + +**To view the device report:** + +1. In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices** in the left pane. +1. Under Manage updates, select **Windows updates**. +1. Select the **Monitor** tab, and then select **Autopatch devices**. + +Once a device is registered to the service, a readiness status is displayed. Each readiness status helps you to determine if there are any actions to take or if the device is ready for the service. + +#### Readiness statuses + +| Autopatch readiness status in the Devices report | Sub-status description | +| --- | --- | +| Registered |
        • **Ready**: Devices successfully passed all prerequisite checks and successfully registered with Windows Autopatch. Additionally, Ready devices successfully passed all [post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md) and don't have any active alerts targeting them.
        • **Not ready**: These devices were successfully registered with Windows Autopatch. However, these devices:
          • Failed to pass one or more [post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).
          • Aren't ready to have one or more software update workloads managed by the service.
          • The device didn't communicate with Microsoft Intune in the last 28 days
          • The device has a conflict with policies or with Autopatch group membership
        | +| Not registered |
        • **Autopatch group conflict**: The device has a conflict with Autopatch group membership
        • **Prerequisites failed**: The device failed to pass one or more [post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).
        • **Excluded**: Devices with this status are removed from the Windows Autopatch service only. Microsoft assumes you manage these devices yourself in some capacity.
        | + +### View only excluded devices + +You can view the excluded devices in the Not registered tab to make it easier for you to bulk restore devices that were previously excluded from the Windows Autopatch service. + +**To view only excluded devices:** + +1. In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), navigate to **Windows Autopatch** > **Devices**. +2. In the **Not registered** tab, select **Excluded** from the filter list. Leave all other filter options unselected. + +## Move devices in between deployment rings + +If you want to move devices to different deployment rings after Windows Autopatch's deployment ring assignment, you can repeat the following steps for one or more devices from the **Devices report**. + +> [!IMPORTANT] +> **You can only move devices in between deployment rings within the same Autopatch group**. You can't move devices in between deployment rings across different Autopatch groups. If you try to select a device that belongs to one Autopatch group, and another device that belongs to a different Autopatch group, you'll receive the following error message on the top right corner of the Microsoft Intune portal: **An error occurred. Please select devices within the same Autopatch group**. + +**To move devices in between deployment rings:** + +> [!NOTE] +> You can only move devices to other deployment rings when the device's Autopatch readiness status appears as **Registered** and the Update status is **Active**. + +1. In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices** in the left pane. +1. Under **Manage updates** section, select **Windows updates**. +1. In the **Devices report**, select one or more devices you want to assign. All selected devices are assigned to the deployment ring you specify. +1. Select **Device actions** from the menu. +1. Select **Assign ring**. A fly-in opens. +1. Use the dropdown menu to select the deployment ring to move devices to, and then select **Save**. The Ring assigned by column changes to **Pending**. +1. When the assignment is complete, the **Ring assigned by** column changes to Admin (which indicates that you made the change) and the **Ring** column shows the new deployment ring assignment. + +> [!WARNING] +> Moving devices between deployment rings through directly changing Microsoft Entra group membership isn't supported and might cause unintended configuration conflicts within the Windows Autopatch service. To avoid service interruption to devices, use the **Assign device to ring** action described previously to move devices between deployment rings. + +## Register devices into Autopatch groups + +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + +An Autopatch group is a logical container or unit that groups several [Microsoft Entra groups](/entra/fundamentals/groups-view-azure-portal), and software update policies. For more information, see [Windows Autopatch groups](../deploy/windows-autopatch-groups-overview.md). + +When you [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group) to add or remove deployment rings, the device-based Microsoft Entra groups you use when setting up your deployment rings, are scanned to see if devices need to be registered with the Windows Autopatch service. + +If devices aren't registered, Autopatch groups start the device registration process by using your existing device-based Microsoft Entra groups. + +- For more information, see [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group) to register devices into Autopatch groups. +- For more information about moving devices between deployment rings, see [Move devices in between deployment rings](#move-devices-in-between-deployment-rings). + +### Supported scenarios when nesting other Microsoft Entra groups Windows Autopatch also supports the following Microsoft Entra nested group scenarios: @@ -48,94 +125,7 @@ Microsoft Entra groups synced up from: - On-premises Active Directory groups (Windows Server AD) - [Configuration Manager collections](/mem/configmgr/core/clients/manage/collections/create-collections#bkmk_aadcollsync) -> [!WARNING] -> It isn't recommended to sync Configuration Manager collections straight to the **Windows Autopatch Device Registration** Microsoft Entra group. Use a different Microsoft Entra group when syncing Configuration Manager collections to Microsoft Entra groups then you can nest this or these groups into the **Windows Autopatch Device Registration** Microsoft Entra group. - -> [!IMPORTANT] -> The **Windows Autopatch Device Registration** Microsoft Entra group only supports **one level** of Microsoft Entra nested groups. - - - -### Clean up dual state of Microsoft Entra hybrid joined and Azure registered devices in your Microsoft Entra tenant - -An [Microsoft Entra dual state](/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state) occurs when a device is initially connected to Microsoft Entra ID as an [Microsoft Entra registered](/azure/active-directory/devices/concept-azure-ad-register) device. However, when you enable Microsoft Entra hybrid join, the same device is connected twice to Microsoft Entra ID but as a [Hybrid Microsoft Entra device](/azure/active-directory/devices/concept-azure-ad-join-hybrid). - -In the dual state, you end up having two Microsoft Entra device records with different join types for the same device. In this case, the Hybrid Microsoft Entra device record takes precedence over the Microsoft Entra registered device record for any type of authentication in Microsoft Entra ID, which makes the Microsoft Entra registered device record stale. - -It's recommended to detect and clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, see [How To: Manage stale devices in Microsoft Entra ID](/azure/active-directory/devices/manage-stale-devices). - -> [!WARNING] -> If you don't clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, you might end up seeing devices failing to meet the **Intune or Cloud-Attached (Device must be either Intune-managed or Co-managed)** pre-requisite check in the **Not ready** tab because it's expected that these stale Microsoft Entra devices aren't enrolled into the Intune service anymore. - -## Prerequisites for device registration - -To be eligible for Windows Autopatch management, devices must meet a minimum set of required software-based prerequisites: - -- Windows 10 (1809+)/11 Enterprise or Professional editions (only x64 architecture). -- Either [Microsoft Entra hybrid joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or [Microsoft Entra joined only](/azure/active-directory/devices/concept-azure-ad-join-hybrid) (personal devices aren't supported). -- Managed by Microsoft Intune. - - [Already enrolled into Microsoft Intune](/mem/intune/user-help/enroll-windows-10-device) and/or [Configuration Manager co-management](/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites#configuration-manager-co-management-requirements). - - Must switch the following Microsoft Configuration Manager [co-management workloads](/mem/configmgr/comanage/how-to-switch-workloads) to Microsoft Intune (either set to Pilot Intune or Intune): - - Windows updates policies - - Device configuration - - Office Click-to-run -- Last Intune device check in completed within the last 28 days. - -> [!IMPORTANT] -> Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Windows Update for Business service and Windows Autopatch don't offer Windows feature updates for devices that are part of the LTSC. You must either use [LTSC media](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise) or the [Configuration Manager operating system deployment capabilities to perform an in-place upgrade](/mem/configmgr/osd/deploy-use/upgrade-windows-to-the-latest-version) for Windows devices that are part of the LTSC. - -For more information, see [Windows Autopatch Prerequisites](../prepare/windows-autopatch-prerequisites.md). - -## About the Registered, Not ready and Not registered tabs - -> [!IMPORTANT] -> Registered devices can appear in the Registered, Not ready, or Not registered tabs. When devices successfully register with the service, the devices are listed in the Registered tab. However, even if the device(s)is successfully registered, they can be part of Not ready tab. If devices fail to register, the devices are listed in the Not registered tab. - -Windows Autopatch has three tabs within its device blade. Each tab is designed to provide a different set of device readiness statuses so the IT admin knows where to go to monitor, and fix potential device health issues. - -| Device blade tab | Purpose | Expected device readiness status | -| ----- | ----- | ----- | -| Registered | The purpose of this tab is to show devices that were successfully registered with the Windows Autopatch service. | Active | -| Not ready | The purpose of this tab is to help you identify and remediate devices that failed to pass one or more post-device registration readiness checks. Devices showing up in this tab were successfully registered with Windows Autopatch. However, these devices aren't ready to have one or more software update workloads managed by the service. | Readiness failed and/or Inactive | -| Not registered | The purpose of this tab is to help you identify and remediate devices that don't meet one or more prerequisite checks to successfully register with the Windows Autopatch service. | Prerequisites failed | - -## Device readiness statuses - -The following are the possible device readiness statuses in Windows Autopatch: - -| Readiness status | Description | Device blade tab | -| ----- | ----- | ----- | -| Active | Devices with this status successfully passed all prerequisite checks and then successfully registered with Windows Autopatch. Additionally, devices with this status successfully passed all post-device registration readiness checks. | Registered | -| Readiness failed | Devices with this status haven't passed one or more post-device registration readiness checks. These devices aren't ready to have one or more software update workloads managed by Windows Autopatch. | Not ready | -| Inactive | Devices with this status haven't communicated with Microsoft Intune in the last 28 days. | Not ready | -| Prerequisites failed | Devices with this status haven't passed one or more prerequisite checks and haven't successfully registered with Windows Autopatch | Not registered | - -## Built-in roles required for device registration - -A role defines the set of permissions granted to users assigned to that role. You can use the **Intune Service Administrator** role to register devices. - -For more information, see [Microsoft Entra built-in roles](/azure/active-directory/roles/permissions-reference) and [Role-based access control (RBAC) with Microsoft Intune](/mem/intune/fundamentals/role-based-access-control). - -If you want to assign less-privileged user accounts to perform specific tasks in the Windows Autopatch portal, such as register devices with the service, you can add these user accounts into one of the two Microsoft Entra groups created during the [tenant enrollment](../prepare/windows-autopatch-enroll-tenant.md) process: - -| Microsoft Entra group name | Discover devices | Modify columns | Refresh device list | Export to .CSV | Device actions | -| ----- | ----- | ----- | ----- | ----- | ----- | -| Modern Workplace Roles - Service Administrator | Yes | Yes | Yes | Yes | Yes | -| Modern Workplace Roles - Service Reader | No | Yes | Yes | Yes | No | - -> [!TIP] -> If you're adding less-privileged user accounts into the **Modern Workplace Roles - Service Administrator** Microsoft Entra group, it's recommended to add the same users as owners of the **Windows Autopatch Device Registration** Microsoft Entra group. Owners of the **Windows Autopatch Device Registration** Microsoft Entra group can add new devices as members of the group for registration purposes.

        For more information, see [assign an owner of member of a group in Microsoft Entra ID](/azure/active-directory/privileged-identity-management/groups-assign-member-owner#assign-an-owner-or-member-of-a-group).

        - -## Details about the device registration process - -Registering your devices with Windows Autopatch does the following: - -1. Makes a record of devices in the service. -2. Assign devices to the [two deployment ring sets](../deploy/windows-autopatch-groups-overview.md#about-deployment-rings) and other groups required for software update management. - -For more information, see [Device registration overview](../deploy/windows-autopatch-device-registration-overview.md). - -### Windows Autopatch on Windows 365 Enterprise Workloads +## Windows Autopatch on Windows 365 Enterprise Workloads Windows 365 Enterprise gives IT admins the option to register devices with the Windows Autopatch service as part of the Windows 365 provisioning policy creation. This option provides a seamless experience for admins and users to ensure your Cloud PCs are always up to date. When IT admins decide to manage their Windows 365 Cloud PCs with Windows Autopatch, the Windows 365 provisioning policy creation process calls Windows Autopatch device registration APIs to register devices on behalf of the IT admin. @@ -148,22 +138,19 @@ Windows 365 Enterprise gives IT admins the option to register devices with the W 1. Provide a policy name and select **Join Type**. For more information, see [Device join types](/windows-365/enterprise/identity-authentication#device-join-types). 1. Select **Next**. 1. Choose the desired image and select **Next**. -1. Under the **Microsoft managed services** section, select **Windows Autopatch**. Then, select **Next**. If the *Windows Autopatch (preview) can't manage your Cloud PCs until a Global Admin has finished setting it up.* message appears, you must [enroll your tenant](../prepare/windows-autopatch-enroll-tenant.md) to continue. +1. Under the **Microsoft managed services** section, select **Windows Autopatch**. Then, select **Next**. If the *Windows Autopatch (preview) can't manage your Cloud PCs until a Global Admin has finished setting it up.* message appears, you must [activate Windows Autopatch features](../prepare/windows-autopatch-feature-activation.md) to continue. 1. Assign your policy accordingly and select **Next**. -1. Select **Create**. Now your newly provisioned Windows 365 Enterprise Cloud PCs will automatically be enrolled and managed by Windows Autopatch. +1. Select **Create**. Now your newly provisioned Windows 365 Enterprise Cloud PCs are automatically enrolled and managed by Windows Autopatch. For more information, see [Create a Windows 365 Provisioning Policy](/windows-365/enterprise/create-provisioning-policy). -> [!IMPORTANT] -> Starting in May 2023, Windows 365 Cloud PC devices are assigned to two deployment ring sets, the service-based and the software-based deployment rings. Additionally, once registered with Windows Autopatch, Windows 365 Cloud PC devices are automatically added to the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group). For more information, see [service-based versus software update-based deployment ring sets](../deploy/windows-autopatch-groups-overview.md#service-based-versus-software-update-based-deployment-rings). - -### Windows Autopatch on Azure Virtual Desktop workloads +## Windows Autopatch on Azure Virtual Desktop workloads Windows Autopatch is available for your Azure Virtual Desktop workloads. Enterprise admins can provision their Azure Virtual Desktop workloads to be managed by Windows Autopatch using the existing device registration process. -Windows Autopatch provides the same scope of service with virtual machines as it does with [physical devices](#windows-autopatch-groups-device-registration). However, Windows Autopatch defers any Azure Virtual Desktop specific support to [Azure support](#contact-support-for-device-registration-related-incidents), unless otherwise specified. +Windows Autopatch provides the same scope of service with virtual machines as it does with [physical devices](../deploy/windows-autopatch-device-registration-overview.md). However, Windows Autopatch defers any Azure Virtual Desktop specific support to [Azure support](#contact-support-for-device-registration-related-incidents), unless otherwise specified. -#### Prerequisites +### Prerequisites Windows Autopatch for Azure Virtual Desktop follows the same [prerequisites](../prepare/windows-autopatch-prerequisites.md) as Windows Autopatch, and the [Azure Virtual Desktop prerequisites](/azure/virtual-desktop/prerequisites). @@ -177,9 +164,9 @@ The following Azure Virtual Desktop features aren't supported: - Pooled non persistent virtual machines - Remote app streaming -#### Deploy Autopatch on Azure Virtual Desktop +### Deploy Autopatch on Azure Virtual Desktop -Azure Virtual Desktop workloads can be registered into Windows Autopatch by using the same method as your [physical devices](#windows-autopatch-groups-device-registration). +Azure Virtual Desktop workloads can be registered into Windows Autopatch by using the same method as your physical devices. For ease of deployment, we recommend nesting a dynamic device group in your Autopatch device registration group. The dynamic device group would target the **Name** prefix defined in your session host, but **exclude** any Multi-Session Session Hosts. For example: @@ -187,13 +174,30 @@ For ease of deployment, we recommend nesting a dynamic device group in your Auto | ----- | ----- | | Windows Autopatch - Host Pool Session Hosts |
        • `(device.displayName -contains "AP")`
        • `(device.deviceOSType -ne "Windows 10 Enterprise for Virtual Desktops")`
        | + + +### Clean up dual state of Microsoft Entra hybrid joined and Azure registered devices in your Microsoft Entra tenant + +An [Microsoft Entra dual state](/entra/identity/devices/hybrid-join-plan#handling-devices-with-azure-ad-registered-state) occurs when a device is initially connected to Microsoft Entra ID as an [Microsoft Entra registered](/entra/identity/devices/concept-device-registration) device. However, when you enable Microsoft Entra hybrid join, the same device is connected twice to Microsoft Entra ID but as a [Hybrid Microsoft Entra device](/entra/identity/devices/concept-hybrid-join). + +In the dual state, you end up having two Microsoft Entra device records with different join types for the same device. In this case, the Hybrid Microsoft Entra device record takes precedence over the Microsoft Entra registered device record for any type of authentication in Microsoft Entra ID, which makes the Microsoft Entra registered device record stale. + +It's recommended to detect and clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, see [How To: Manage stale devices in Microsoft Entra ID](/entra/identity/devices/manage-stale-devices). + +> [!WARNING] +> If you don't clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, you might end up seeing devices failing to meet the **Intune or Cloud-Attached (Device must be either Intune-managed or Co-managed)** pre-requisite check in the **Not ready** tab because it's expected that these stale Microsoft Entra devices aren't enrolled into the Intune service anymore. + ### Contact support for device registration-related incidents +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + Support is available either through Windows 365, or the Windows Autopatch Service Engineering team for device registration-related incidents. - For Windows 365 support, see [Get support](/mem/get-support). - For Azure Virtual Desktop support, see [Get support](https://azure.microsoft.com/support/create-ticket/). -- For Windows Autopatch support, see [Submit a support request](/windows/deployment/windows-autopatch/operate/windows-autopatch-support-request). +- For Windows Autopatch support, see [Submit a support request](../manage/windows-autopatch-support-request.md). + +--- ## Device management lifecycle scenarios @@ -203,17 +207,17 @@ There's a few more device management lifecycle scenarios to consider when planni If a device was previously registered into the Windows Autopatch service, but it needs to be reimaged, you must run one of the device provisioning processes available in Microsoft Intune to reimage the device. -The device will be rejoined to Microsoft Entra ID (either Hybrid or Microsoft Entra-only). Then, re-enrolled into Intune as well. No further action is required from you or the Windows Autopatch service, because the Microsoft Entra device ID record of that device remains the same. +The device is rejoined to Microsoft Entra ID (either Hybrid or Microsoft Entra-only). Then, re-enrolled into Intune as well. No further action is required from you or the Windows Autopatch service, because the Microsoft Entra device ID record of that device remains the same. ### Device repair and hardware replacement -If you need to repair a device that was previously registered into the Windows Autopatch service, by replacing the motherboard, non-removable network interface cards (NIC) or hard drive, you must re-register the device into the Windows Autopatch service, because a new hardware ID is generated when there are major hardware changes, such as: +If you need to repair a device that was previously registered into the Windows Autopatch service, by replacing the motherboard, nonremovable network interface cards (NIC) or hard drive, you must re-register the device into the Windows Autopatch service, because a new hardware ID is generated when there are major hardware changes, such as: - SMBIOS UUID (motherboard) -- MAC address (non-removable NICs) +- MAC address (nonremovable NICs) - OS hard drive's serial, model, manufacturer information When one of these hardware changes occurs, Microsoft Entra ID creates a new device ID record for that device, even if it's technically the same device. > [!IMPORTANT] -> If a new Microsoft Entra device ID is generated for a device that was previously registered into the Windows Autopatch service, even if it's technically same device, the new Microsoft Entra device ID must be added either through device direct membership or through nested Microsoft Entra dynamic/assigned group into the **Windows Autopatch Device Registration** Microsoft Entra group. This process guarantees that the newly generated Microsoft Entra device ID is registered with Windows Autopatch and that the device continues to have its software updates managed by the service. +> If a new Microsoft Entra device ID is generated for a device that was previously registered into the Windows Autopatch service, even if it's technically same device, the new Microsoft Entra device ID must be added either through device direct membership or through nested Microsoft Entra dynamic/assigned group in the Windows Autopatch group experience. This process guarantees that the newly generated Microsoft Entra device ID is registered with Windows Autopatch and that the device continues to have its software updates managed by the service. diff --git a/windows/deployment/windows-autopatch/includes/windows-autopatch-applies-to-all-licenses.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-applies-to-all-licenses.md new file mode 100644 index 0000000000..28cef2dd9a --- /dev/null +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-applies-to-all-licenses.md @@ -0,0 +1,14 @@ +--- +author: tiaraquan +ms.author: tiaraquan +manager: aaroncz +ms.service: windows-client +ms.subservice: autopatch +ms.topic: include +ms.date: 09/16/2024 +ms.localizationpriority: medium +--- + + +> [!IMPORTANT] +> The information in section applies to Business premium, A3+, E3+ and F3 licenses. For more information, see [Features and capabilities](../overview/windows-autopatch-overview.md#features-and-capabilities) and [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements). diff --git a/windows/deployment/update/includes/wufb-deployment-audience-graph-explorer.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-audience-graph-explorer.md similarity index 96% rename from windows/deployment/update/includes/wufb-deployment-audience-graph-explorer.md rename to windows/deployment/windows-autopatch/includes/windows-autopatch-audience-graph-explorer.md index 572d549362..1b467a2ff9 100644 --- a/windows/deployment/update/includes/wufb-deployment-audience-graph-explorer.md +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-audience-graph-explorer.md @@ -1,11 +1,11 @@ --- -author: mestew -ms.author: mstewart +author: tiaraquan +ms.author: tiaraquan manager: aaroncz -ms.subservice: itpro-updates ms.service: windows-client +ms.subservice: autopatch ms.topic: include -ms.date: 02/14/2023 +ms.date: 09/16/2024 ms.localizationpriority: medium --- diff --git a/windows/deployment/windows-autopatch/includes/windows-autopatch-business-premium-a3-licenses.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-business-premium-a3-licenses.md new file mode 100644 index 0000000000..30ab466ec3 --- /dev/null +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-business-premium-a3-licenses.md @@ -0,0 +1,14 @@ +--- +author: tiaraquan +ms.author: tiaraquan +manager: aaroncz +ms.service: windows-client +ms.subservice: autopatch +ms.topic: include +ms.date: 09/16/2024 +ms.localizationpriority: medium +--- + + +> [!IMPORTANT] +> To [activate all Windows Autopatch features](../overview/windows-autopatch-overview.md#windows-enterprise-e3-and-f3-licenses), you must have Windows 10/11 Enterprise E3+ or F3 (included in Microsoft 365 F3, E3, or E5) licenses. [Feature activation](../prepare/windows-autopatch-feature-activation.md) is optional and at no additional cost to you when you have Windows 10/11 Enterprise E3+ or F3 licenses. For more information, see [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements). diff --git a/windows/deployment/update/includes/wufb-deployment-driver-policy-considerations.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-driver-policy-considerations.md similarity index 60% rename from windows/deployment/update/includes/wufb-deployment-driver-policy-considerations.md rename to windows/deployment/windows-autopatch/includes/windows-autopatch-driver-policy-considerations.md index c386f7fd42..080b40a056 100644 --- a/windows/deployment/update/includes/wufb-deployment-driver-policy-considerations.md +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-driver-policy-considerations.md @@ -1,16 +1,16 @@ --- -author: mestew -ms.author: mstewart +author: tiaraquan +ms.author: tiaraquan manager: aaroncz -ms.subservice: itpro-updates ms.service: windows-client +ms.subservice: autopatch ms.topic: include -ms.date: 02/14/2023 +ms.date: 09/16/2024 ms.localizationpriority: medium --- - + -It's possible for the service to receive content approval but the content doesn't get installed on the device because of a Group Policy, CSP, or registry setting on the device. In some cases, organizations specifically configure these policies to fit their current or future needs. For instance, organizations may want to review applicable driver content through the deployment service, but not allow installation. Configuring this sort of behavior can be useful, especially when transitioning management of driver updates due to changing organizational needs. The following list describes driver related update policies that can affect deployments through the deployment service: +It's possible for the service to receive content approval but the content doesn't get installed on the device because of a Group Policy, CSP, or registry setting on the device. In some cases, organizations specifically configure these policies to fit their current or future needs. For instance, organizations may want to review applicable driver content, but not allow installation. Configuring this sort of behavior can be useful, especially when transitioning management of driver updates due to changing organizational needs. The following list describes driver related update policies that can affect deployments: ### Policies that exclude drivers from Windows Update for a device @@ -22,10 +22,10 @@ The following policies exclude drivers from Windows Update for a device: - **Registry**: `HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\ExcludeWUDriversFromQualityUpdates` set to `1` - **Intune**: [**Windows Drivers** update setting](/mem/intune/protect/windows-update-settings#update-settings) for the update ring set to `Block` -**Behavior with the deployment service**: Devices with driver exclusion polices that are enrolled for **drivers** and added to an audience though the deployment service: - - Will display the applicable driver content in the deployment service - - Won't install drivers that are approved from the deployment service - - If drivers are deployed to a device that's blocking them, the deployment service displays the driver is being offered and reporting displays the install is pending. +**Behavior**: Devices with driver exclusion polices that are enrolled for **drivers** and added to an audience: + - Will display the applicable driver content + - Won't install drivers that are approved + - If drivers are deployed to a device that's blocking them, Windows Autopatch displays the driver is being offered and reporting displays the install is pending. ### Policies that define the source for driver updates @@ -37,9 +37,9 @@ The following policies define the source for driver updates as either Windows Up - **Registry**: `HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\SetPolicyDrivenUpdateSourceForDriverUpdates` set to `0`. Under `\AU`, `UseUpdateClassPolicySource` also needs to be set to `1` - **Intune**: Not applicable. Intune deploys updates using Windows Update for Business. [Co-managed clients from Configuration Manager](/mem/configmgr/comanage/overview?toc=/mem/configmgr/cloud-attach/toc.json&bc=/mem/configmgr/cloud-attach/breadcrumb/toc.json) with the workload for Windows Update policies set to Intune will also use Windows Update for Business. -**Behavior with the deployment service**: Devices with these update source policies that are enrolled for **drivers** and added to an audience though the deployment service: - - Will display the applicable driver content in the deployment service - - Will install drivers that are approved from the deployment service +**Behavior**: Devices with these update source policies that are enrolled for **drivers** and added to an audience: + - Will display the applicable driver content + - Will install drivers that are approved -> [!NOTE] -> When the scan source for drivers is set to WSUS, the deployment service doesn't get inventory events from devices. This means that the deployment service won't be able to report the applicability of a driver for the device. +> [!NOTE] +> When the scan source for drivers is set to WSUS, Windows Autopatch doesn't get inventory events from devices. This means that Windows Autopatch won't be able to report the applicability of a driver for the device. diff --git a/windows/deployment/update/includes/wufb-deployment-enroll-device-graph-explorer.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-enroll-device-graph-explorer.md similarity index 96% rename from windows/deployment/update/includes/wufb-deployment-enroll-device-graph-explorer.md rename to windows/deployment/windows-autopatch/includes/windows-autopatch-enroll-device-graph-explorer.md index f84dd43e0a..4c86165a65 100644 --- a/windows/deployment/update/includes/wufb-deployment-enroll-device-graph-explorer.md +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-enroll-device-graph-explorer.md @@ -1,11 +1,11 @@ --- -author: mestew -ms.author: mstewart +author: tiaraquan +ms.author: tiaraquan manager: aaroncz -ms.subservice: itpro-updates ms.service: windows-client +ms.subservice: autopatch ms.topic: include -ms.date: 02/14/2023 +ms.date: 09/16/2024 ms.localizationpriority: medium --- diff --git a/windows/deployment/windows-autopatch/includes/windows-autopatch-enterprise-e3-f3-licenses.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-enterprise-e3-f3-licenses.md new file mode 100644 index 0000000000..37b872ad2a --- /dev/null +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-enterprise-e3-f3-licenses.md @@ -0,0 +1,14 @@ +--- +author: tiaraquan +ms.author: tiaraquan +manager: aaroncz +ms.service: windows-client +ms.subservice: autopatch +ms.topic: include +ms.date: 09/16/2024 +ms.localizationpriority: medium +--- + + +> [!IMPORTANT] +> **The information in this article or section only applies if you have Windows Enterprise E3+ or F3 licenses (included in Microsoft 365 F3, E3, or E5) licenses and have [activated Windows Autopatch features](../overview/windows-autopatch-overview.md#windows-enterprise-e3-and-f3-licenses).**

        [Feature activation](../prepare/windows-autopatch-feature-activation.md) is optional and at no additional cost to you if you have Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) licenses.

        For more information, see [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements). If you choose not to go through feature activation, you can still use the Windows Autopatch service for the features included in [Business premium and A3+ licenses](../overview/windows-autopatch-overview.md#business-premium-and-a3-licenses).

        diff --git a/windows/deployment/update/includes/wufb-deployment-find-device-name-graph-explorer.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-find-device-name-graph-explorer.md similarity index 91% rename from windows/deployment/update/includes/wufb-deployment-find-device-name-graph-explorer.md rename to windows/deployment/windows-autopatch/includes/windows-autopatch-find-device-name-graph-explorer.md index 9cfcff85ad..00dc5b6ebd 100644 --- a/windows/deployment/update/includes/wufb-deployment-find-device-name-graph-explorer.md +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-find-device-name-graph-explorer.md @@ -1,16 +1,16 @@ --- -author: mestew -ms.author: mstewart +author: tiaraquan +ms.author: tiaraquan manager: aaroncz -ms.subservice: itpro-updates ms.service: windows-client +ms.subservice: autopatch ms.topic: include -ms.date: 02/14/2023 +ms.date: 09/16/2024 ms.localizationpriority: medium --- -Use the [device](/graph/api/resources/device) resource type to find clients to enroll into the deployment service. Change the query parameters to fit your specific needs. For more information, see [Use query parameters](/graph/query-parameters). +Use the [device](/graph/api/resources/device) resource type to find clients to enroll into Windows Autopatch. Change the query parameters to fit your specific needs. For more information, see [Use query parameters](/graph/query-parameters). - Displays the **AzureAD Device ID** and **Name** of all devices: diff --git a/windows/deployment/update/includes/wufb-deployment-graph-explorer-permissions.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-graph-explorer-permissions.md similarity index 56% rename from windows/deployment/update/includes/wufb-deployment-graph-explorer-permissions.md rename to windows/deployment/windows-autopatch/includes/windows-autopatch-graph-explorer-permissions.md index 40f67810ab..439c49b803 100644 --- a/windows/deployment/update/includes/wufb-deployment-graph-explorer-permissions.md +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-graph-explorer-permissions.md @@ -1,18 +1,18 @@ --- -author: mestew -ms.author: mstewart +author: tiaraquan +ms.author: tiaraquan manager: aaroncz -ms.subservice: itpro-updates ms.service: windows-client +ms.subservice: autopatch ms.topic: include -ms.date: 02/14/2023 +ms.date: 09/16/2024 ms.localizationpriority: medium --- - + The following permissions are needed for the queries listed in this article: -- [WindowsUpdates.ReadWrite.All](/graph/permissions-reference#windows-updates-permissions) for [Windows Update for Business deployment service](/graph/api/resources/adminwindowsupdates) operations. +- [WindowsUpdates.ReadWrite.All](/graph/permissions-reference#windows-updates-permissions) for [Windows Autopatch](/graph/api/resources/adminwindowsupdates) operations. - At least [Device.Read.All](/graph/permissions-reference#device-permissions) permission to display [device](/graph/api/resources/device) information. Some roles, such as the [Windows Update deployment administrator](/azure/active-directory/roles/permissions-reference#windows-update-deployment-administrator), already have these permissions. diff --git a/windows/deployment/update/includes/wufb-deployment-graph-explorer.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-graph-explorer.md similarity index 80% rename from windows/deployment/update/includes/wufb-deployment-graph-explorer.md rename to windows/deployment/windows-autopatch/includes/windows-autopatch-graph-explorer.md index 8250bc9e1d..336c4c82fe 100644 --- a/windows/deployment/update/includes/wufb-deployment-graph-explorer.md +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-graph-explorer.md @@ -1,14 +1,14 @@ --- -author: mestew -ms.author: mstewart +author: tiaraquan +ms.author: tiaraquan manager: aaroncz -ms.subservice: itpro-updates ms.service: windows-client +ms.subservice: autopatch ms.topic: include -ms.date: 02/14/2023 +ms.date: 09/16/2024 ms.localizationpriority: medium --- - + For this article, you'll use Graph Explorer to make requests to the [Microsoft Graph APIs](/graph/api/resources/adminwindowsupdates) to retrieve, add, delete, and update data. Graph Explorer is a developer tool that lets you learn about Microsoft Graph APIs. For more information about using Graph Explorer, see [Get started with Graph Explorer](/graph/graph-explorer/graph-explorer-overview). @@ -21,8 +21,7 @@ For this article, you'll use Graph Explorer to make requests to the [Microsoft G 1. You may need to enable the [`WindowsUpdates.ReadWrite.All` permission](/graph/permissions-reference#windows-updates-permissions) to use the queries in this article. To enable the permission: 1. Select the **Modify permissions** tab in Graph Explorer. 1. In the permissions dialog box, select the **WindowsUpdates.ReadWrite.All** permission then select **Consent**. You may need to sign in again to grant consent. - - :::image type="content" source="../media/7512398-wufbds-graph-modify-permission.png" alt-text="Screenshot of the modify permissions tab in Graph Explorer" lightbox="../media/7512398-wufbds-graph-modify-permission.png" ::: + :::image type="content" source="../media/7512398-graph-modify-permission.png" alt-text="Screenshot of the modify permissions tab in Graph Explorer" lightbox="../media/7512398-wufbds-modify-permission.png" ::: 1. To make requests: 1. Select either GET, POST, PUT, PATCH, or DELETE from the drop-down list for the HTTP method. diff --git a/windows/deployment/update/includes/wufb-deployment-graph-unenroll.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-graph-unenroll.md similarity index 58% rename from windows/deployment/update/includes/wufb-deployment-graph-unenroll.md rename to windows/deployment/windows-autopatch/includes/windows-autopatch-graph-unenroll.md index d4681b40c2..f91004dfa0 100644 --- a/windows/deployment/update/includes/wufb-deployment-graph-unenroll.md +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-graph-unenroll.md @@ -1,19 +1,19 @@ --- -author: mestew -ms.author: mstewart +author: tiaraquan +ms.author: tiaraquan manager: aaroncz -ms.subservice: itpro-updates ms.service: windows-client +ms.subservice: autopatch ms.topic: include -ms.date: 02/14/2023 +ms.date: 09/16/2024 ms.localizationpriority: medium --- - + -When a device no longer requires management, unenroll it from the deployment service. Just like [enrolling a device](#enroll-devices), specify either `driver` or `feature` as the value for the `updateCategory`. The device will no longer receive updates from the deployment service for the specified update category. Depending on the device's configuration, it may start to receive updates from Windows Update. For instance, if a device is still enrolled for feature updates, but it's unenrolled from drivers: +When a device no longer requires management, unenroll it from Windows Autopatch. Just like [enrolling a device](#enroll-devices), specify either `driver` or `feature` as the value for the `updateCategory`. The device will no longer receive updates from Windows Autopatch for the specified update category. Depending on the device's configuration, it may start to receive updates from Windows Update. For instance, if a device is still enrolled for feature updates, but it's unenrolled from drivers: - Existing driver deployments from the service won't be offered to the device -- The device continues to receive feature updates from the deployment service +- The device continues to receive feature updates from Windows Autopatch - Drivers may start being installed from Windows Update depending on the device's configuration To unenroll a device, POST to [updatableAssets](/graph/api/resources/windowsupdates-updatableasset) using [unenrollAssets](/graph/api/windowsupdates-updatableasset-unenrollassets). In the request body, specify: diff --git a/windows/deployment/windows-autopatch/includes/windows-autopatch-limitations.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-limitations.md new file mode 100644 index 0000000000..dc0fd1a739 --- /dev/null +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-limitations.md @@ -0,0 +1,15 @@ +--- +author: tiaraquan +ms.author: tiaraquan +manager: aaroncz +ms.service: windows-client +ms.subservice: autopatch +ms.topic: include +ms.date: 09/16/2024 +ms.localizationpriority: medium +--- + + +Windows Autopatch is a Windows service hosted in Azure Commercial that uses Windows diagnostic data. While customers with GCC tenants may choose to use it, Windows Autopatch is outside the [US Government community compliance (GCC)](/office365/servicedescriptions/office-365-platform-service-description/office-365-us-government/gcc#us-government-community-compliance) boundary. For a list of GCC offerings for Microsoft products and services, see the [Microsoft Trust Center](/compliance/regulatory/offering-home). + +Windows Autopatch isn't available in Azure Government for [Office 365 GCC High and DoD](/office365/servicedescriptions/office-365-platform-service-description/office-365-us-government/gcc-high-and-dod) tenants. diff --git a/windows/deployment/update/includes/wufb-deployment-update-health-tools-logs.md b/windows/deployment/windows-autopatch/includes/windows-autopatch-update-health-tools-logs.md similarity index 71% rename from windows/deployment/update/includes/wufb-deployment-update-health-tools-logs.md rename to windows/deployment/windows-autopatch/includes/windows-autopatch-update-health-tools-logs.md index cd39b4dd7e..adc812a9a0 100644 --- a/windows/deployment/update/includes/wufb-deployment-update-health-tools-logs.md +++ b/windows/deployment/windows-autopatch/includes/windows-autopatch-update-health-tools-logs.md @@ -1,14 +1,14 @@ --- -author: mestew -ms.author: mstewart +author: tiaraquan +ms.author: tiaraquan manager: aaroncz -ms.subservice: itpro-updates ms.service: windows-client +ms.subservice: autopatch ms.topic: include -ms.date: 02/14/2023 +ms.date: 09/16/2024 ms.localizationpriority: medium --- - + ## Log location for the Update Health Tools The Update Health Tools are used when you deploy expedited updates. In some cases, you may wish to review the logs for the Update Health Tools. diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-customize-windows-update-settings.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-customize-windows-update-settings.md index bfd579ee3b..7b85eceadd 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-customize-windows-update-settings.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-customize-windows-update-settings.md @@ -1,7 +1,7 @@ --- title: Customize Windows Update settings Autopatch groups experience description: How to customize Windows Updates with Autopatch groups -ms.date: 07/08/2024 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -17,9 +17,11 @@ ms.collection: # Customize Windows Update settings -You can customize the Windows Update deployment schedule for each deployment ring in Windows Autopatch groups per your business and organizational needs. This capability is allowed for both [Default](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) and [Custom Autopatch groups](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups). However, we recommend that you remain within service defined boundaries to maintain compliance. +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] -When the deployment cadence is customized, Windows Autopatch will override our service defaults with your preferred deployment cadence. Depending on the selected options, devices with [customized schedules](#scheduled-install) may not count towards the Windows Autopatch [Windows quality update service level objective](../operate/windows-autopatch-groups-windows-quality-update-overview.md#service-level-objective). +You can customize the Windows Update deployment schedule for each deployment ring in Windows Autopatch groups per your business and organizational needs. However, we recommend that you remain within service defined boundaries to maintain compliance. + +When the deployment cadence is customized, Windows Autopatch overrides our service defaults with your preferred deployment cadence. Depending on the selected options, devices with [customized schedules](#scheduled-install) might not count towards the Windows Autopatch [Windows quality update service level objective](../manage/windows-autopatch-windows-quality-update-overview.md#service-level-objective). ## Deployment cadence @@ -37,35 +39,30 @@ For each tenant, at the deployment ring level, there are two cadence types to co With the deadline-drive cadence type, you can control and customize the deferral, deadline, and grace period to meet your specific business needs and organizational requirements. -There are certain limits that Windows Autopatch defines and you'll only be able to make changes with those boundaries. The following boundaries are implemented so that Windows Autopatch can maintain update compliance. - -| Boundary | Description | -| ----- | ----- | -| Deferrals and deadlines | Windows Autopatch will enforce that deadline plus deferral days for a deployment ring to be less than or equal to 14 days. | -| Grace period | The permitted customization range is zero to seven days. | - > [!NOTE] > The configured grace period will apply to both Windows quality updates and Windows feature updates. -Each deployment ring can be scheduled independent of the others, and there are no dependencies that the previous deployment ring must be scheduled before the next ring. Further, if the cadence type is set as **Deadline-driven**, the automatic update behavior setting, **Reset to default** in the Windows Update for Business policy, will be applied. +Each deployment ring can be scheduled independent of the others, and there are no dependencies that the previous deployment ring must be scheduled before the next ring. Further, if the cadence type is set as **Deadline-driven**, the automatic update behavior setting, **Reset to default** in the Windows Update for Business policy, are applied. -It's possible for you to change the cadence from the Windows Autopatch Release management blade while update deployments are in progress. Windows Autopatch will abide by the principle to always respect your preferences over service-defined values. +It's possible for you to change the cadence from the Windows Autopatch Release management blade while update deployments are in progress. Windows Autopatch abides by the principle to always respect your preferences over service-defined values. -However, if an update has already started for a particular deployment ring, Windows Autopatch won't be able to change the cadence for that ring during that ongoing update cycle. The changes will only be effective in the next update cycle. +However, if an update already started for a particular deployment ring, Windows Autopatch isn't able to change the cadence for that ring during that ongoing update cycle. The changes will only be effective in the next update cycle. #### Scheduled install > [!NOTE] ->If you select the Schedule install cadence type, the devices in that ring won't be counted towards the [Windows quality update service level objective](../operate/windows-autopatch-groups-windows-quality-update-overview.md#service-level-objective). +>If you select the Schedule install cadence type, the devices in that ring won't be counted towards the [Windows quality update service level objective](../manage/windows-autopatch-windows-quality-update-overview.md#service-level-objective). -While the Windows Autopatch default options will meet the majority of the needs for regular users with corporate devices, we understand there are devices that run critical activities and can only receive Windows Updates at specific times. The **Scheduled install** cadence type will minimize disruptions by preventing forced restarts and interruptions to critical business activities for end users. Upon selecting the **Scheduled install** cadence type, any previously set deadlines and grace periods will be removed. Devices will only update and restart according to the time specified. +While the Windows Autopatch default options meet most the needs for regular users with corporate devices, we understand there are devices that run critical activities and can only receive Windows Updates at specific times. -If other applications force a device to restart outside of the specified time and a Windows Update is pending a restart, the Windows Update will complete its installation at this time. For this reason, ensure that you consider your update and restart scenarios for devices running business critical activities, or restart sensitive workloads before using the Scheduled Install option. +The **Scheduled install** cadence type minimizes disruptions by preventing forced restarts and interruptions to critical business activities for end users. When you select the **Scheduled install** cadence type, any previously set deadlines and grace periods are removed. Devices will only update and restart according to the time specified. + +If other applications force a device to restart outside of the specified time and a Windows Update is pending a restart, the Windows Update completes its installation at this time. For this reason, ensure that you consider your update and restart scenarios for devices running business critical activities, or restart sensitive workloads before using the Scheduled Install option. > [!NOTE] > The compliance deadline and grace period for Windows quality updates won't be configured for the Scheduled Install cadence type. -Devices **must** be active and available at the time when the device is scheduled for installation to ensure the optimal experience. If the device is consistently unavailable during the scheduled install time, the device can remain unprotected and unsecured, or the device may have the Windows Update scan and install during active hours. +Devices **must** be active and available at the time when the device is scheduled for installation to ensure the optimal experience. If the device is consistently unavailable during the scheduled install time, the device can remain unprotected and unsecured, or the device might have the Windows Update scan and install during active hours. ##### Scheduled install types @@ -76,7 +73,7 @@ The Scheduled install cadence has two options: | Option | Description | | ----- | ----- | -| Active hours | The period (daily) that the user normally does their work, or the device is busy performing business critical actions.

        The time outside of active hours is when the device is available for Windows to perform an update and restart the device (daily). The max range for Active hours is 18 hours. The six-hour period outside of the active hours is the deployment period, when Windows Update for Business will scan, install and restart the device.

        +| Active hours | The period (daily) that the user normally does their work, or the device is busy performing business critical actions.

        The time outside of active hours is when the device is available for Windows to perform an update and restart the device (daily). The max range for Active hours is 18 hours. The six-hour period outside of the active hours is the deployment period, when Windows Update for Business scans, install and restart the device.

        | Schedule install and restart | Use this option to prevent the service from installing Windows Updates except during the specified start time. You can specify the following occurrence options:
        • Weekly
        • Bi-weekly
        • Monthly

        Select a time when the device has low activity for the updates to complete. Ensure that the Windows Update has three to four hours to complete the installation and restart the device.

        | > [!NOTE] @@ -84,7 +81,7 @@ The Scheduled install cadence has two options: ### User notifications -In addition to the cadence type, you can also manage the end user notification settings. End users will receive all update notifications by default. For critical devices or devices where notifications need to be hidden, use the **Manage notifications** option to configure notifications. For each tenant, at the deployment ring level, there are four options for you to configure end user update notification settings: +In addition to the cadence type, you can also manage the end user notification settings. End users receive all update notifications by default. For critical devices or devices where notifications need to be hidden, use the **Manage notifications** option to configure notifications. For each tenant, at the deployment ring level, there are four options for you to configure end user update notification settings: - Not configured - Use the default Windows Update notifications @@ -106,7 +103,7 @@ For more information, see [Windows Update settings you can manage with Intune up 4. Select **Next** to navigate to the Windows update settings page. The page lists the existing settings for each of the deployment rings in the Autopatch group. 5. Select [**Manage deployment cadence**](#cadence-types) to customize Windows Update settings. 1. Select one of the cadence types for the ring: - 1. Select **Deadline-driven** to configure the deferral, deadline, and grace periods. This option will enforce forced restarts based on the selected deadline and grace period. In the event you want to switch back to the service recommended defaults, for each of the settings, select the option tagged as "default". + 1. Select **Deadline-driven** to configure the deferral, deadline, and grace periods. This option enforces forced restarts based on the selected deadline and grace period. In the event you want to switch back to the service recommended defaults, for each of the settings, select the option tagged as "default". 1. Select **Scheduled install** to opt-out of deadline-based forced restart. 1. Select either **Active hours** or **Schedule install and restart time**. 2. Select **Save**. @@ -118,5 +115,5 @@ For more information, see [Windows Update settings you can manage with Intune up 1. Turn off all notifications included restart warnings 1. Select **Save** once you select the preferred setting. 7. Repeat the same process to customize each of the rings. Once done, select **Next**. -8. In **Review + apply**, you'll be able to review the selected settings for each of the rings. -9. Select **Apply** to apply the changes to the ring policy. Once the settings are applied, the saved changes can be verified in the **Release schedule** tab. The Windows quality update schedule on the **Release schedule** tab will be updated as per the customized settings. +8. In **Review + apply**, you're able to review the selected settings for each of the rings. +9. Select **Apply** to apply the changes to the ring policy. Once the settings are applied, the saved changes can be verified in the **Release schedule** tab. The Windows quality update schedule on the **Release schedule** tab is updated as per the customized settings. diff --git a/windows/deployment/update/deployment-service-drivers.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-driver-and-firmware-update-programmatic-controls.md similarity index 85% rename from windows/deployment/update/deployment-service-drivers.md rename to windows/deployment/windows-autopatch/manage/windows-autopatch-driver-and-firmware-update-programmatic-controls.md index ca104fce34..9557d457c6 100644 --- a/windows/deployment/update/deployment-service-drivers.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-driver-and-firmware-update-programmatic-controls.md @@ -1,12 +1,12 @@ --- -title: Deploy drivers and firmware updates -titleSuffix: Windows Update for Business deployment service -description: Use Windows Update for Business deployment service to deploy driver and firmware updates to devices. +title: Programmatic controls for drivers and firmware +titleSuffix: Windows Autopatch +description: Use programmatic controls to deploy driver and firmware updates to devices. ms.service: windows-client -ms.subservice: itpro-updates -ms.topic: conceptual -author: mestew -ms.author: mstewart +ms.subservice: autopatch +ms.topic: how-to +author: tiaraquan +ms.author: tiaraquan manager: aaroncz ms.collection: - tier1 @@ -14,13 +14,13 @@ ms.localizationpriority: medium appliesto: - ✅ Windows 11 - ✅ Windows 10 -ms.date: 06/22/2023 +ms.date: 09/16/2024 --- -# Deploy drivers and firmware updates with Windows Update for Business deployment service +# Programmatic controls for drivers and firmware updates -The Windows Update for Business deployment service is used to approve and schedule software updates. The deployment service exposes its capabilities through the [Microsoft Graph API](/graph/use-the-api). You can call the API directly, through a [Graph SDK](/graph/sdks/sdks-overview), or integrate them with a management tool such as [Microsoft Intune](/mem/intune). +Windows Autopatch programmatic controls are used to approve and schedule software updates through the [Microsoft Graph API](/graph/use-the-api). You can call the API directly, through a [Graph SDK](/graph/sdks/sdks-overview), or integrate them with a management tool such as [Microsoft Intune](/mem/intune). This article uses [Graph Explorer](/graph/graph-explorer/graph-explorer-overview) to walk through the entire process of deploying a driver update to clients. In this article, you will: > [!div class="checklist"] @@ -37,36 +37,36 @@ This article uses [Graph Explorer](/graph/graph-explorer/graph-explorer-overview ## Prerequisites -All of the [prerequisites for the Windows Update for Business deployment service](deployment-service-prerequisites.md) must be met. +All of the [Windows Autopatch prerequisites](../prepare/windows-autopatch-fix-issues.md) must be met. ### Permissions -[!INCLUDE [Windows Update for Business deployment service permissions using Graph Explorer](./includes/wufb-deployment-graph-explorer-permissions.md)] +[!INCLUDE [Windows Autopath permissions using Graph Explorer](../includes/windows-autopatch-graph-explorer-permissions.md)] ## Open Graph Explorer -[!INCLUDE [Graph Explorer sign in](./includes/wufb-deployment-graph-explorer.md)] +[!INCLUDE [Graph Explorer sign in](../includes/windows-autopatch-graph-explorer.md)] ## Run queries to identify devices -[!INCLUDE [Graph Explorer device queries](./includes/wufb-deployment-find-device-name-graph-explorer.md)] +[!INCLUDE [Graph Explorer device queries](../includes/windows-autopatch-find-device-name-graph-explorer.md)] ## Enroll devices -When you enroll devices into driver management, the deployment service becomes the authority for driver updates coming from Windows Update. Devices don't receive drivers or firmware from Windows Update until a deployment is manually created or they're added to a driver update policy with approvals. +When you enroll devices into driver management, Windows Autopatch becomes the authority for driver updates coming from Windows Update. Devices don't receive drivers or firmware from Windows Update until a deployment is manually created or they're added to a driver update policy with approvals. -[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-enroll-device-graph-explorer.md)] +[!INCLUDE [Graph Explorer enroll devices](../includes/windows-autopatch-enroll-device-graph-explorer.md)] ## Create a deployment audience and add audience members -[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-audience-graph-explorer.md)] +[!INCLUDE [Graph Explorer enroll devices](../includes/windows-autopatch-audience-graph-explorer.md)] -Once a device has been enrolled and added to a deployment audience, the Windows Update for Business deployment service will start collecting scan results from Windows Update to build a catalog of applicable drivers to be browsed, approved, and scheduled for deployment. +Once a device has been enrolled and added to a deployment audience, Windows Autopatch will start collecting scan results from Windows Update to build a catalog of applicable drivers to be browsed, approved, and scheduled for deployment. ## Create an update policy @@ -75,7 +75,6 @@ Update policies define how content is deployed to a deployment audience. An [upd > [!IMPORTANT] > Any [deployment settings](/graph/api/resources/windowsupdates-deploymentsettings) configured for a [content approval](#approve-driver-content-for-deployment) will be combined with the existing update policy's deployment settings. If the content approval and update policy specify the same deployment setting, the setting from the content approval is used. - ### Create a policy and define the settings later To create a policy without any deployment settings, in the request body specify the **Audience ID** as `id`. In the following example, the **Audience ID** is `d39ad1ce-0123-4567-89ab-cdef01234567`, and the `id` given in the response is the **Policy ID**: @@ -115,6 +114,7 @@ content-type: application/json ### Specify settings during policy creation To create a policy with additional settings, in the request body: + - Specify the **Audience ID** as `id` - Define any [deployment settings](/graph/api/resources/windowsupdates-deploymentsettings). - Add the `content-length` header to the request if a status code of 411 occurs. The value should be the length of the request body in bytes. For information on error codes, see [Microsoft Graph error responses and resource types](/graph/errors). @@ -147,7 +147,6 @@ To create a policy with additional settings, in the request body: } ``` - ### Review and edit update policy settings To review the policy settings, run the following query using the **Policy ID**, for example `9011c330-1234-5678-9abc-def012345678`: @@ -181,10 +180,9 @@ content-type: application/json } ``` - ## Review applicable driver content -Once Windows Update for Business deployment service has scan results from devices, the applicability for driver and firmware updates can be displayed for a deployment audience. Each applicable update returns the following information: +Once Windows Autopatch has scan results from devices, the applicability for driver and firmware updates can be displayed for a deployment audience. Each applicable update returns the following information: - An `id` for its [catalog entry](/graph/api/resources/windowsupdates-catalogentry) - The **Microsoft Entra ID** of the devices it's applicable to @@ -197,6 +195,7 @@ GET https://graph.microsoft.com/beta/admin/windows/updates/deploymentAudiences/d ``` The following truncated response displays: + - An **Microsoft Entra ID** of `01234567-89ab-cdef-0123-456789abcdef` - The **Catalog ID** of `5d6dede684ba5c4a731d62d9c9c2a99db12c5e6015e9f8ad00f3e9387c7f399c` @@ -332,9 +331,9 @@ GET https://graph.microsoft.com/beta/admin/windows/updates/deployments?orderby=c ## Unenroll devices -[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-graph-unenroll.md)] +[!INCLUDE [Graph Explorer unenroll devices](../includes/windows-autopatch-graph-unenroll.md)] ## Policy considerations for drivers -[!INCLUDE [Windows Update for Business deployment service driver policy considerations](./includes/wufb-deployment-driver-policy-considerations.md)] +[!INCLUDE [Windows Autopatch driver policy considerations](../includes/windows-autopatch-driver-policy-considerations.md)] diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-edge.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-edge.md index a8274a7d80..b42a76a736 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-edge.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-edge.md @@ -1,7 +1,7 @@ --- title: Microsoft Edge description: This article explains how Microsoft Edge updates are managed in Windows Autopatch -ms.date: 09/15/2023 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -17,8 +17,13 @@ ms.collection: # Microsoft Edge +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + Windows Autopatch uses the [Stable Channel](/deployedge/microsoft-edge-channels#stable-channel) of Microsoft Edge. +> [!IMPORTANT] +> To update Microsoft 365 Apps for enterprise, you must [create at least one Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) first and **Microsoft Edge update setting** must be set to [**Allow**](#allow-or-block-edge-updates). For more information on workloads supported by Windows Autopatch groups, see [Software update workloads](../deploy/windows-autopatch-groups-overview.md#software-update-workloads). + ## Device eligibility For a device to be eligible for Microsoft Edge updates as a part of Windows Autopatch, they must meet the following criteria: @@ -28,15 +33,54 @@ For a device to be eligible for Microsoft Edge updates as a part of Windows Auto - The device must be able to access the required network endpoints to reach the Microsoft Edge update service. - If Microsoft Edge is open, it must restart for the update process to complete. +## Allow or block Microsoft Edge updates + +> [!IMPORTANT] +> You must be an Intune Administrator to make changes to the setting. + +For organizations seeking greater control, you can allow or block Microsoft Edge updates for Windows Autopatch-enrolled devices. + +| Microsoft Edge setting | Description | +| ----- | ----- | +| **Allow** | When set to **Allow**, Windows Autopatch assigns devices to Microsoft Edge's [Stable Channel](/deployedge/microsoft-edge-channels#stable-channel). To manage updates manually, set the Microsoft Edge setting to **Block**. | +| **Block** | When set to **Block**, Windows Autopatch doesn't assign devices to Microsoft Edge's [Stable Channel](/deployedge/microsoft-edge-channels#stable-channel) updates on your behalf, and your organizations have full control over these updates. You can continue to receive updates from [channels](/deployoffice/overview-update-channels) other than the default [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview). | + +**To allow or block Edge updates:** + +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +1. Navigate to **Tenant administration** > **Windows Autopatch** > **Autopatch groups** > **Update settings**. +1. Go to the **Edge updates** section. By default, the Allow/Block toggle is set to **Block**. +1. Turn off the **Allow** toggle (set to Block) to opt out of Microsoft Edge update policies. You see the notification: *Update in process. This setting will be unavailable until the update is complete.* +1. Once the update is complete, you receive the notification: *This setting is updated*. + +> [!NOTE] +> If the notification: *This setting couldn't be updated. Please try again or submit a support request.* appears, use the following steps:
        1. Refresh your page.
        2. Please repeat the same steps in To allow or block Edge updates.
        3. If the issue persists, [submit a support request](../manage/windows-autopatch-support-request.md).
          4. + +**To verify if the Edge update setting is set to Allow:** + +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +2. Navigate to **Devices** > **Configuration profiles** > **Profiles**. +3. The following profiles should be discoverable from the list of profiles: + 1. Windows Autopatch - Microsoft Edge Update Channel Stable + 2. Windows Autopatch - Microsoft Edge Update Channel Beta + +**To verify if the Edge update setting is set to Block:** + +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +2. Navigate to **Devices** > **Configuration profiles** > **Profiles**. +3. The following **five** profiles should be removed from your list of profiles and no longer visible/active. Use the Search with the keywords "Microsoft Edge Configuration". The result should return *0 profiles filtered*. + 1. Windows Autopatch - Microsoft Edge Update Channel Stable + 2. Windows Autopatch - Microsoft Edge Update Channel Beta + ## Update release schedule -Microsoft Edge checks for updates every 10 hours. Quality updates occur weekly by default. Feature updates occur automatically every four weeks and are rolled out [progressively](/deployedge/microsoft-edge-update-progressive-rollout) by the Microsoft Edge product group to ensure the best experience for customers. The update is available within a few days of the initial release. +Microsoft Edge checks for updates every 10 hours. Quality updates occur weekly by default. The Microsoft Edge product group [progressively](/deployedge/microsoft-edge-update-progressive-rollout) rolls out feature updates automatically every four weeks to ensure the best experience for customers. The update is available within a few days of the initial release. Browser updates with critical security fixes have a faster rollout cadence than updates that don't have critical security fixes to ensure fast protection from vulnerabilities. Devices in the Test device group receive feature updates from the [Beta Channel](/deployedge/microsoft-edge-channels#beta-channel). This channel is fully supported and automatically updated with new features approximately every four weeks. -## Pausing and resuming updates +## Pause and resume updates Currently, Windows Autopatch can't pause or resume Microsoft Edge updates. diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-exclude-device.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-exclude-device.md index ce0f4a6c0b..1c024c812e 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-exclude-device.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-exclude-device.md @@ -1,7 +1,7 @@ --- title: Exclude a device description: This article explains how to exclude a device from the Windows Autopatch service -ms.date: 07/08/2024 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -16,9 +16,11 @@ ms.collection: # Exclude a device -To avoid end-user disruption, excluding a device in Windows Autopatch only deletes the Windows Autopatch device record itself. Excluding a device can't delete the Microsoft Intune and/or the Microsoft Entra device records. Microsoft assumes you'll keep managing those devices yourself in some capacity. +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] -When you exclude a device from the Windows Autopatch service, the device is flagged as **excluded** so Windows Autopatch doesn't try to restore the device into the service again, since the exclusion command doesn't trigger device membership removal from the **Windows Autopatch Device Registration** group, or any other Microsoft Entra group, used with Autopatch groups. +To avoid end-user disruption, excluding a device in Windows Autopatch only deletes the Windows Autopatch device record itself. Excluding a device can't delete the Microsoft Intune and/or the Microsoft Entra device records. Microsoft assumes you manage those devices yourself in some capacity. + +When you exclude a device from the Windows Autopatch service, the device is flagged as **Excluded** so Windows Autopatch doesn't try to restore the device into the service again. The exclusion command doesn't trigger device membership removal from any other Microsoft Entra group, used with Autopatch groups. > [!IMPORTANT] > The Microsoft Entra team doesn't recommend appending query statements to remove specific device from a dynamic query due to dynamic query performance issues. @@ -28,7 +30,7 @@ When you exclude a device from the Windows Autopatch service, the device is flag 1. Sign into the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Select **Windows Autopatch** in the left navigation menu. 1. Select **Devices**. -1. In either the **Ready** or **Not ready** tab, select the device(s) you want to exclude. +1. Select the devices you want to exclude. 1. Once a device or multiple devices are selected, select **Device actions**. Then, select **Exclude device**. > [!WARNING] @@ -36,14 +38,14 @@ When you exclude a device from the Windows Autopatch service, the device is flag ## Only view excluded devices -You can view the excluded devices in the **Not registered** tab to make it easier for you to bulk restore devices that were previously excluded from the Windows Autopatch service. +You can view the excluded devices in the [**Devices report**](../deploy/windows-autopatch-register-devices.md#devices-report) to make it easier for you to bulk restore devices that were previously excluded from the Windows Autopatch service. **To view only excluded devices:** 1. Sign into the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Select **Windows Autopatch** in the left navigation menu. 1. Select **Devices**. -1. In the **Not registered** tab, select **Excluded** from the filter list. Leave all other filter options unselected. +1. Select **Excluded** from the filter list. Leave all other filter options unselected. ## Restore a device or multiple devices previously excluded @@ -52,5 +54,5 @@ You can view the excluded devices in the **Not registered** tab to make it easie 1. Sign into the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Select **Windows Autopatch** in the left navigation menu. 1. Select **Devices**. -1. In the **Not registered** tab, select the device(s) you want to restore. +1. Select the devices you want to restore. 1. Once a device or multiple devices are selected, select **Device actions**. Then, select **Restore excluded device**. diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-feature-deactivation.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-feature-deactivation.md index 2101b7f827..2fae25dbc4 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-feature-deactivation.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-feature-deactivation.md @@ -1,7 +1,7 @@ --- -title: Unenroll your tenant -description: This article explains what unenrollment means for your organization and what actions you must take. -ms.date: 07/08/2024 +title: Deactivate Windows Autopatch +description: This article explains what deactivation means for your organization and what actions you must take. +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -15,45 +15,48 @@ ms.collection: - tier1 --- -# Unenroll your tenant +# Deactivate Windows Autopatch -If you're looking to unenroll your tenant from Windows Autopatch, this article details what unenrollment means for your organization and what actions you must take. +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + +If you're looking to deactivate Windows Autopatch features, this article details what deactivation means for your organization and what actions you must take. > [!IMPORTANT] -> You must be a Global Administrator to unenroll your tenant. +> You must be a Global Administrator to deactivate Windows Autopatch features. -Unenrolling from Windows Autopatch requires manual actions from both you and from the Windows Autopatch Service Engineering Team. The Windows Autopatch Service Engineering Team will: +Deactivating from Windows Autopatch requires manual actions from both you and from the Windows Autopatch Service Engineering Team. The Windows Autopatch Service Engineering Team: -- Remove Windows Autopatch access to your tenant. -- Exclude your devices from the Windows Autopatch service. Excluding your devices from Windows Autopatch won't remove your devices from Intune, Microsoft Entra ID or Configuration Manager. The Windows Autopatch Service Engineering Team follows the same process and principles as laid out in [Exclude a device](../operate/windows-autopatch-exclude-device.md). -- Delete all data that we've stored in the Windows Autopatch data storage. +- Removes Windows Autopatch access to your tenant. + - We remove the [Modern Workplace Management application](../references/windows-autopatch-changes-made-at-feature-activation.md#windows-autopatch-enterprise-applications) from your tenant that is used to run the Windows Autopatch service on your tenant +- Excludes your devices from the Windows Autopatch service. Excluding your devices from Windows Autopatch doesn't remove your devices from Intune, Microsoft Entra ID or Configuration Manager. The Windows Autopatch Service Engineering Team follows the same process and principles as laid out in [Exclude a device](../manage/windows-autopatch-exclude-device.md). +- Deletes all data that we stored in the Windows Autopatch data storage. > [!NOTE] > We will **not** delete any of your customer or Intune data. -## Microsoft's responsibilities during unenrollment +## Microsoft's responsibilities during deactivation | Responsibility | Description | | ----- | ----- | -| Windows Autopatch data | Windows Autopatch will delete user data that is within the Windows Autopatch service. We won't make changes to any other data. For more information about how data is used in Windows Autopatch, see [Privacy](../overview/windows-autopatch-privacy.md). | -| Excluding devices | Windows Autopatch will exclude all devices previously registered with the service. Only the Windows Autopatch device record is deleted. We won't delete Microsoft Intune and/or Microsoft Entra device records. For more information, see [Exclude a device](../operate/windows-autopatch-exclude-device.md). | +| Windows Autopatch data | Windows Autopatch deletes user data that is within the Windows Autopatch service. We don't make changes to any other data. For more information about how data is used in Windows Autopatch, see [Privacy](../overview/windows-autopatch-privacy.md). | +| Excluding devices | Windows Autopatch excludes all devices previously registered with the service. Only the Windows Autopatch device record is deleted. We don't delete Microsoft Intune and/or Microsoft Entra device records. For more information, see [Exclude a device](../manage/windows-autopatch-exclude-device.md). | -## Your responsibilities after unenrolling your tenant +## Your responsibilities after deactivating Windows Autopatch features | Responsibility | Description | | ----- | ----- | -| Updates | After the Windows Autopatch service is unenrolled, we'll no longer provide updates to your devices. You must ensure that your devices continue to receive updates through your own policies to ensure they're secure and up to date. | -| Optional Windows Autopatch configuration | Windows Autopatch won't remove the configuration policies or groups used to enable updates on your devices. You're responsible for these policies following tenant unenrollment. If you don't wish to use these policies for your devices after unenrollment, you may safely delete them. For more information, see [Changes made at tenant enrollment](../references/windows-autopatch-changes-to-tenant.md). | -| Microsoft Intune roles | After unenrollment, you may safely remove the Modern Workplace Intune Admin role. | +| Updates | After the Windows Autopatch service is deactivated, we'll no longer provide updates to your devices. You must ensure that your devices continue to receive updates through your own policies to ensure they're secure and up to date. | +| Optional Windows Autopatch configuration | Windows Autopatch doesn't remove the configuration policies or groups used to enable updates on your devices. You're responsible for these policies following tenant deactivation. If you don't wish to use these policies for your devices after deactivation, you can safely delete them. For more information, see [Changes made at feature activation](../references/windows-autopatch-changes-made-at-feature-activation.md). | +| Microsoft Intune roles | After deactivation, you can safely remove the Modern Workplace Intune Admin role. | -## Unenroll from Windows Autopatch +## To Deactivate Windows Autopatch features -**To unenroll from Windows Autopatch:** +**To deactivate Windows Autopatch features:** -1. [Submit a support request](../operate/windows-autopatch-support-request.md) and request to unenroll from the Windows Autopatch service. -1. The Windows Autopatch Service Engineering Team communicates with your IT Administrator to confirm your intent to unenroll from the service. +1. [Submit a support request](../manage/windows-autopatch-support-request.md) and request to deactivate Windows Autopatch features. +1. The Windows Autopatch Service Engineering Team communicates with your IT Administrator to confirm your intent to deactivate Windows Autopatch features. 1. You have 14 days to review and confirm the communication sent by the Windows Autopatch Service Engineering Team. 2. The Windows Autopatch Service Engineering Team can proceed sooner than 14 days if your confirmation arrives sooner. -1. The Windows Autopatch Service Engineering Team proceeds with the removal of all items listed under [Microsoft's responsibilities during unenrollment](#microsofts-responsibilities-during-unenrollment). -1. The Windows Autopatch Service Engineering Team informs you when unenrollment is complete. -1. You're responsible for the items listed under [Your responsibilities after unenrolling your tenant](#your-responsibilities-after-unenrolling-your-tenant). +1. The Windows Autopatch Service Engineering Team proceeds with the removal of all items listed under [Microsoft's responsibilities during deactivation](#microsofts-responsibilities-during-deactivation). +1. The Windows Autopatch Service Engineering Team informs you when deactivation is complete. +1. You're responsible for the items listed under [Your responsibilities after deactivating Windows Autopatch features](#your-responsibilities-after-deactivating-windows-autopatch-features). diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-groups-policies.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-groups-policies.md new file mode 100644 index 0000000000..e69de29bb2 diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-autopatch-groups.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-autopatch-groups.md index f160717b52..17c2113bc1 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-autopatch-groups.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-autopatch-groups.md @@ -1,7 +1,7 @@ --- title: Manage Windows Autopatch groups description: This article explains how to manage Autopatch groups -ms.date: 07/08/2024 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -17,62 +17,32 @@ ms.collection: # Manage Windows Autopatch groups +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + Autopatch groups help Microsoft Cloud-Managed services meet organizations where they are in their update management journey. -Autopatch groups is a logical container or unit that groups several [Microsoft Entra groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates policy for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates). +An Autopatch group is a logical container or unit that groups several [Microsoft Entra groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates policy for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates). -## Autopatch groups prerequisites +Before you start managing Autopatch groups, ensure you meet the [Windows Autopatch groups prerequisites](../deploy/windows-autopatch-groups-overview.md#prerequisites). -Before you start managing Autopatch groups, ensure you've met the following prerequisites: +## Create an Autopatch group -- Review [Windows Autopatch groups overview documentation](../deploy/windows-autopatch-groups-overview.md) to understand [key benefits](../deploy/windows-autopatch-groups-overview.md#key-benefits), [concepts](../deploy/windows-autopatch-groups-overview.md#key-concepts) and [common ways to use Autopatch groups](../deploy/windows-autopatch-groups-overview.md#common-ways-to-use-autopatch-groups) within your organization. -- Ensure the following [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) are created in your tenant: - - Modern Workplace Update Policy [Test]-[Windows Autopatch] - - Modern Workplace Update Policy [First]-[Windows Autopatch] - - Modern Workplace Update Policy [Fast]-[Windows Autopatch] - - Modern Workplace Update Policy [Broad]-[Windows Autopatch] -- Ensure the following [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) are created in your tenant: - - Windows Autopatch - DSS Policy [Test] - - Windows Autopatch - DSS Policy [First] - - Windows Autopatch - DSS Policy [Fast] - - Windows Autopatch - DSS Policy [Broad] -- Ensure the following Microsoft Entra ID assigned groups are in your tenant before using Autopatch groups. **Don't** modify the Microsoft Entra group membership types (Assigned or Dynamic). Otherwise, the Windows Autopatch service won't be able to read the device group membership from these groups and causes the Autopatch groups feature and other service-related operations to not work properly. - - Modern Workplace Devices-Windows Autopatch-Test - - Modern Workplace Devices-Windows Autopatch-First - - Modern Workplace Devices-Windows Autopatch-Fast - - Modern Workplace Devices-Windows Autopatch-Broad - - Windows Autopatch - Test - - Windows Autopatch - Ring1 - - Windows Autopatch - Ring2 - - Windows Autopatch - Ring3 - - Windows Autopatch - Last -- Additionally, **don't** modify the Microsoft Entra group ownership of any of the groups above otherwise, Autopatch groups device registration process won't be able to add devices into these groups. If the ownership is modified, you must add the **Modern Workplace Management** enterprise application as the owner of these groups. - - For more information, see [assign an owner or member of a group in Microsoft Entra ID](/azure/active-directory/privileged-identity-management/groups-assign-member-owner#assign-an-owner-or-member-of-a-group) for steps on how to add owners to Azure Microsoft Entra groups. -- Make sure you have [app-only auth turned on in your Windows Autopatch tenant](../operate/windows-autopatch-maintain-environment.md#windows-autopatch-tenant-actions). Otherwise, the Autopatch groups functionality won't work properly. Autopatch uses app-only auth to: - - Read device attributes to successfully register devices. - - Manage all configurations related to the operation of the service. -- Make sure that all device-based Microsoft Entra groups you intend to use with Autopatch groups are created prior to using the feature. - - Review your existing Microsoft Entra group dynamic queries and direct device memberships to avoid having device membership overlaps in between device-based Microsoft Entra groups that are going to be used with Autopatch groups. This can help prevent device conflicts within an Autopatch group or across several Autopatch groups. **Autopatch groups doesn't support user-based Microsoft Entra groups**. -- Ensure devices used with your existing Microsoft Entra groups meet [device registration prerequisite checks](../deploy/windows-autopatch-register-devices.md#prerequisites-for-device-registration) when being registered with the service. Autopatch groups register devices on your behalf, and devices can be moved to **Registered** or **Not registered** tabs in the Devices blade accordingly. +> [!IMPORTANT] +> Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience. > [!TIP] -> [Update rings](/mem/intune/protect/windows-10-update-rings) and [feature updates](/mem/intune/protect/windows-10-feature-updates) for Windows 10 and later policies that are created and managed by Windows Autopatch can be restored using the [Policy health](../operate/windows-autopatch-policy-health-and-remediation.md) feature. For more information on remediation actions, see [restore Windows update policies](../operate/windows-autopatch-policy-health-and-remediation.md#restore-windows-update-policies). +> For more information on workloads supported by Windows Autopatch groups, see [Supported software workloads](../deploy/windows-autopatch-groups-overview.md#software-update-workloads).
          • To manage Microsoft 365 Apps for enterprise, you must create an Autopatch group first and [set the Microsoft 365 app update setting to Allow](../manage/windows-autopatch-microsoft-365-apps-enterprise.md#allow-or-blow-microsoft-365-app-updates).
          • To manage Microsoft Edge updates, you must create an Autopatch group first and [set the Edge update setting to Allow](../manage/windows-autopatch-edge.md#allow-or-block-edge-updates).
          -## Create a Custom Autopatch group - -> [!NOTE] -> The Default Autopatch group is recommended for organizations that can meet their business needs using the pre-configured five deployment ring composition. - -**To create a Custom Autopatch group:** +**To create an Autopatch group:** 1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Select **Devices** from the left navigation menu. 1. Under the **Windows Autopatch** section, select **Release management**. 1. In the **Release management** blade, select **Autopatch groups**. 1. In the **Autopatch groups** blade, select **Create**. -1. In **Basics** page, enter a **name** and a **description** then select **Next: Deployment rings**. - 1. Enter up to 64 characters for the Autopatch group name and 150 characters maximum for the description. The Autopatch group name is appended to both the update rings and the DSS policy names that get created once the Custom Autopatch group is created. -1. In **Deployment rings** page, select **Add deployment ring** to add the number of deployment rings to the Custom Autopatch group. +1. In the **Basics** page, enter a **name** and a **description** then select **Next: Deployment rings**. + 1. Enter up to 64 characters for the Autopatch group name and 150 characters maximum for the description. The Autopatch group name is appended to both the update rings and the DSS policy names that get created once the Autopatch group is created. +1. In the **Deployment rings** page, select **Add deployment ring** to add the number of deployment rings to the Autopatch group. 1. Each new deployment ring added must have either a Microsoft Entra device group assigned to it, or a Microsoft Entra group that is dynamically distributed across your deployments rings using defined percentages. 1. In the **Dynamic groups** area, select **Add groups** to select one or more existing device-based Microsoft Entra groups to be used for Dynamic group distribution. 1. In the **Dynamic group distribution** column, select the desired deployment ring checkbox. Then, either: @@ -80,27 +50,27 @@ Before you start managing Autopatch groups, ensure you've met the following prer 1. Select **Apply default dynamic group distribution** to use the default values. 1. In the **Assigned group** column, select **Add group to ring** to add an existing Microsoft Entra group to any of the defined deployment rings. The **Test** and **Last** deployment rings only support Assigned group distribution. These deployment rings don't support Dynamic distribution. 1. Select **Next: Windows Update settings**. -1. Select the **horizontal ellipses (…)** > **Manage deployment cadence** to [customize your gradual rollout of Windows quality and feature updates](../operate/windows-autopatch-windows-update.md). Select **Save**. +1. Select the **horizontal ellipses (…)** > **Manage deployment cadence** to [customize your gradual rollout of Windows quality and feature updates](../manage/windows-autopatch-customize-windows-update-settings.md). Select **Save**. 1. Select the **horizontal ellipses (…)** > **Manage notifications** to customize the end-user experience when receiving Windows updates. Select **Save**. 1. Select **Review + create** to review all changes made. -1. Once the review is done, select **Create** to save your custom Autopatch group. +1. Once the review is done, select **Create** to save your Autopatch group. > [!CAUTION] -> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from finish creating or editing the Autopatch group (Default or Custom). +> **Don't** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won't be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly.

          Additionally, it's not supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.

          -> [!IMPORTANT] -> Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience. +> [!CAUTION] +> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from creating or editing the Autopatch group. -## Edit the Default or a Custom Autopatch group +## Edit an Autopatch group > [!TIP] > You can't edit an Autopatch group when there's one or more Windows feature update releases targeted to it. If you try to edit an Autopatch group with one or more ongoing Windows feature update releases targeted to it, you get the following informational banner message: "**Some settings are not allowed to be modified as there's one or more on-going Windows feature update release targeted to this Autopatch group.**" -> See [Manage Windows feature update releases](../operate/windows-autopatch-groups-manage-windows-feature-update-release.md) for more information on release and phase statuses. +> For more information on release and phase statuses, see [Windows feature update](../manage/windows-autopatch-windows-feature-update-overview.md). -**To edit either the Default or a Custom Autopatch group:** +**To edit an Autopatch group:** 1. Select the **horizontal ellipses (…)** > **Edit** for the Autopatch group you want to edit. -1. You can only modify the **description** of the Default or a Custom Autopatch group. You **can't** modify the name. Once the description is modified, select **Next: Deployment rings**. +1. You can only modify the **description** of an Autopatch group. You **can't** modify the name. Once the description is modified, select **Next: Deployment rings**. To rename an Autopatch group, see [Rename an Autopatch group](#rename-an-autopatch-group). 1. Make the necessary changes in the **Deployment rings** page, then select **Next: Windows Update settings**. 1. Make the necessary changes in the **Windows Update settings** page, then select **Next: Review + save**. 1. Select **Review + create** to review all changes made. @@ -109,46 +79,42 @@ Before you start managing Autopatch groups, ensure you've met the following prer > [!IMPORTANT] > Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience. -## Rename a Custom Autopatch group +## Rename an Autopatch group -You **can't** rename the Default Autopatch group. However, you can rename a Custom Autopatch group. +**To rename an Autopatch group:** -**To rename a Custom Autopatch group:** - -1. Select the **horizontal ellipses (…)** > **Rename** for the Custom Autopatch group you want to rename. The **Rename Autopatch group** fly-in opens. -1. In the **New Autopatch group name**, enter the new Autopatch group name of your choice, then click **Rename group**. +1. Select the **horizontal ellipses (…)** > **Rename** for the Autopatch group you want to rename. The **Rename Autopatch group** fly-in opens. +1. In the **New Autopatch group name**, enter the new Autopatch group name of your choice, then select **Rename group**. > [!IMPORTANT] -> Autopatch supports up to 64 characters for the custom Autopatch group name. Additionally, when you rename a custom Autopatch group all [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) associated with the custom Autopatch group are renamed to include the new Autopatch group name you define in its name string. Also, when renaming a custom Autopatch group all Microsoft Entra groups representing the custom Autopatch group's deployment rings are renamed to include the new Autopatch group name you define in its name string. +> Autopatch supports up to 64 characters for the Autopatch group name. Additionally, when you rename a Autopatch group all [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) associated with the Autopatch group are renamed to include the new Autopatch group name you define in its name string. Also, when renaming an Autopatch group all Microsoft Entra groups representing the Autopatch group's deployment rings are renamed to include the new Autopatch group name you define in its name string. -## Delete a Custom Autopatch group +## Delete an Autopatch group -You **can't** delete the Default Autopatch group. However, you can delete a Custom Autopatch group. +**To delete an Autopatch group:** -**To delete a Custom Autopatch group:** - -1. Select the **horizontal ellipses (…)** > **Delete** for the Custom Autopatch group you want to delete. -1. Select **Yes** to confirm you want to delete the Custom Autopatch group. +1. Select the **horizontal ellipses (…)** > **Delete** for the Autopatch group you want to delete. +1. Select **Yes** to confirm you want to delete the Autopatch group. > [!CAUTION] -> You can't delete a Custom Autopatch group when it's being used as part of one or more active or paused feature update releases. However, you can delete a Custom Autopatch group when the release for either Windows quality or feature updates have either the **Scheduled** or **Paused** statuses. +> You can't delete an Autopatch group when it's being used as part of one or more active or paused feature update releases. However, you can delete an Autopatch group when the release for either Windows quality or feature updates have either the **Scheduled** or **Paused** statuses. ## Manage device conflict scenarios when using Autopatch groups -Overlap in device membership is a common scenario when working with device-based Microsoft Entra groups since sometimes dynamic queries can be large in scope or the same assigned device membership can be used across different Microsoft Entra groups. +Overlap in device membership is a common scenario when working with device-based Microsoft Entra groups. Sometimes dynamic queries can be large in scope or the same assigned device membership can be used across different Microsoft Entra groups. -Since Autopatch groups allow you to use your existing Microsoft Entra groups to create your own deployment ring composition, the service takes on the responsibility of monitoring and automatically solving some of the device conflict scenarios that may occur. +Since Autopatch groups allow you to use your existing Microsoft Entra groups to create your own deployment ring composition, the service takes on the responsibility of monitoring and automatically solving some of the device conflict scenarios that might occur. > [!CAUTION] -> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from creating or editing the Autopatch group (Default or Custom). +> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from creating or editing the Autopatch group. ### Device conflict in deployment rings within an Autopatch group -Autopatch groups uses the following logic to solve device conflicts on your behalf within an Autopatch group: +Autopatch groups use the following logic to solve device conflicts on your behalf within an Autopatch group: | Step | Description | | ----- | ----- | -| Step 1: Checks for the deployment ring distribution type (**Assigned** or **Dynamic**) that the device belongs to. | For example, if a device is part of one deployment ring with **Dynamic** distribution (Ring3), and one deployment ring with **Assigned** distribution (Test,) within the same Autopatch group, the deployment ring with **Assigned** distribution (Test) takes precedence over the one with the **Dynamic** distribution type (Ring3). | +| Step 1: Checks for the deployment ring distribution type (**Assigned** or **Dynamic**) that the device belongs to. | For example, if a device is part of one deployment ring with **Dynamic** distribution (Ring3), and one deployment ring with **Assigned** distribution (Test) within the same Autopatch group, the deployment ring with **Assigned** distribution (Test) takes precedence over the one with the **Dynamic** distribution type (Ring3). | | Step 2: Checks for deployment ring ordering when device belongs to one or more deployment ring with the same distribution type (**Assigned** or **Dynamic**) | For example, if a device is part of one deployment ring with **Assigned** distribution (Test), and in another deployment ring with **Assigned** distribution (Ring3) within the **same** Autopatch group, the deployment ring that comes later (Ring3) takes precedence over the deployment ring that comes earlier (Test) in the deployment ring order. | > [!IMPORTANT] @@ -156,28 +122,18 @@ Autopatch groups uses the following logic to solve device conflicts on your beha ### Device conflict across different Autopatch groups -Device conflict across different deployment rings in different Autopatch groups may occur, review the following examples about how the Windows Autopatch services handles the following scenarios: +Device conflict across different deployment rings in different Autopatch groups might occur, review the following examples about how the Windows Autopatch services handles the following scenarios: -#### Default to Custom Autopatch group device conflict +#### Same device in different deployment rings across different Autopatch groups | Conflict scenario | Conflict resolution | | ----- | ----- | -| You, the IT admin at Contoso Ltd., starts using only the Default Autopatch group, but later decides to create an Autopatch group called "Marketing".

          However, you notice that the same devices that belong to the deployment rings in the Default Autopatch group are now also part of the new deployment rings in the Marketing Autopatch group.

          | Autopatch groups automatically resolve this conflict on your behalf.

          In this example, devices that belong to the deployment rings as part of the "Marketing" Autopatch group take precedence over devices that belong to the deployment ring in the Default Autopatch group, because you, the IT admin, demonstrated clear intent on managing deployment rings using a Custom Autopatch group outside the Default Autopatch group.

          | +| You, the IT admin at Contoso Ltd., are using several Autopatch groups. While navigating through devices in the Windows Autopatch Devices blade, you notice that the same device is part of different deployment rings across several different Autopatch groups. This device appears as **Not ready**. | You must resolve this conflict.

          Autopatch groups inform you about the device conflict in the [**Devices report**](../deploy/windows-autopatch-register-devices.md#devices-report). Select the **Not ready** status for the device you want to address. You're required to manually indicate which of the existing Autopatch groups the device should exclusively belong to.

          | -#### Custom to Custom Autopatch group device conflict +#### Device conflict before device registration + +When you create or edit an Autopatch group, Windows Autopatch checks if the devices that are part of the Microsoft Entra groups, used in Autopatch groups’ deployment rings, are registered with the service. | Conflict scenario | Conflict resolution | | ----- | ----- | -| You, the IT admin at Contoso Ltd., are using several Custom Autopatch groups. While navigating through devices in the Windows Autopatch Devices blade (**Not ready** tab), you notice that the same device is part of different deployment rings across several different Custom Autopatch groups. | You must resolve this conflict.

          Autopatch groups informs you about the device conflict in the **Devices** > **Not ready** tab. You're required to manually indicate which of the existing Custom Autopatch groups the device should exclusively belong to.

          | - -#### Device conflict prior to device registration - -When you create or edit the Custom or Default Autopatch group, Windows Autopatch checks if the devices that are part of the Microsoft Entra groups, used in Autopatch groups' deployment rings, are registered with the service. - -| Conflict scenario | Conflict resolution | -| ----- | ----- | -| Devices are in the Custom-to-Custom Autopatch group device conflict scenario | You must resolve this conflict.

          Devices will fail to register with the service and will be sent to the **Not registered** tab. You're required to make sure the Microsoft Entra groups that are used with the Custom Autopatch groups don't have device membership overlaps.

          | - -#### Device conflict post device registration - -Autopatch groups will keep monitoring for all device conflict scenarios listed in the [Manage device conflict scenarios when using Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md#manage-device-conflict-scenarios-when-using-autopatch-groups) section even after devices were successfully registered with the service. +| Device conflict before device registration due to device membership overlap | You must resolve this conflict.

          Devices fail to register with the service and are marked with a **Not registered** status. You’re required to make sure the Microsoft Entra groups that are used in an Autopatch group don’t have device membership overlaps.

          | diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-driver-and-firmware-updates.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-driver-and-firmware-updates.md index 50979877ff..db938a79bd 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-driver-and-firmware-updates.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-driver-and-firmware-updates.md @@ -1,7 +1,7 @@ --- title: Manage driver and firmware updates description: This article explains how you can manage driver and firmware updates with Windows Autopatch -ms.date: 07/08/2024 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -17,46 +17,105 @@ ms.collection: # Manage driver and firmware updates -You can manage and control your driver and firmware updates with Windows Autopatch. You can choose to receive driver and firmware updates automatically, or self-manage the deployment. +You can manage driver and firmware profiles for Windows 10 and later devices. By using targeted policies, you can expedite a specific driver and firmware update to release to your tenant. For more information about driver updates for Windows 10 and later, see [Windows driver update management in Intune](/mem/intune/protect/windows-driver-updates-overview). -> [!TIP] -> Windows Autopatch's driver and firmware update management is based on [Intune's driver and firmware update management](/mem/intune/protect/windows-driver-updates-overview). You can use **both** Intune and Windows Autopatch to manage your driver and firmware updates. +## Driver and firmware controls -## Automatic and Self-managed modes +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] -Switching the toggle between Automatic and Self-managed modes creates driver profiles on a per-ring basis within your tenant. +You can manage and control your driver and firmware updates by: + +- Controlling the flow of all drivers to an Autopatch group or rings within an Autopatch group +- Controlling the flow of a specific driver or firmware across your entire tenant via approvals +- Approving and deploying other drivers and firmware that previously couldn’t be centrally managed + +### Automatic and Manual modes + +The Autopatch service creates additional driver profiles on a per-deployment ring and per group basis within your tenant. + +> [!NOTE] +> For more information about policies created for Driver updates for Windows 10 and later, see [Changes made at feature activation](../references/windows-autopatch-changes-made-at-feature-activation.md#driver-updates-for-windows-10-and-later). + +Choosing between Automatic and Manual modes can be done per-deployment ring and/or per Autopatch group. For a single Autopatch group, a mix of both Automatic and Manual policies is allowed. If you were previously in Manual mode, we create Manual policies for all your group rings. If Automatic (the default) was previously used, we create Automatic policies instead. + +> [!IMPORTANT] +> If you switch between Automatic and Manual modes, new policies are generated to **replace old policies**. **You’ll lose any approvals previously made for those groups and/or deployment rings**. | Modes | Description | | ----- | -----| -| Automatic | We recommend using **Automatic** mode.

          Automatic mode (default) is recommended for organizations with standard Original Equipment Manufacturer (OEM) devices where no recent driver or hardware issues have occurred due to Windows Updates. Automatic mode ensures the most secure drivers are installed using Autopatch deployment ring rollout.

          | -| Self-managed | When you use **Self-managed** mode, no drivers are installed in your environment without your explicit approval. You can still use Intune to choose specific drivers and deploy them on a ring-by-ring basis.

          Self-managed mode turns off Windows Autopatch's automatic driver deployment. Instead, the Administrator controls the driver deployment.

          The Administrator selects the individual driver within an Intune driver update profile. Then, Autopatch creates an Intune driver update profile per deployment ring. Drivers can vary between deployment rings.

          The drivers listed for selection represent only the drivers needed for the targeted clients, which are the Autopatch rings. Therefore, the drivers offered may vary between rings depending on the variety of device hardware in an organization.

          | +| Automatic | We recommend using **Automatic** mode.

          Automatic mode (default) is recommended for organizations with standard Original Equipment Manufacturer (OEM) devices where no recent driver or hardware issues occurred due to Windows Updates.

          Automatic mode ensures the most secure drivers are installed using Autopatch deployment ring rollout. You can also choose to deploy additional drivers from the **Other** tab to your deployment rings or Autopatch groups that are set to **Automatic**.

          | +| Manual | When you use **Manual** mode, no drivers are installed in your environment without your explicit approval. You can also choose to deploy additional drivers from the Other tab to your deployment rings or Autopatch groups that are set to Manual.

          Manual mode turns off Windows Autopatch’s automatic driver deployment. Instead, the Administrator controls the driver deployment.

          The Administrator selects the individual drivers to be deployed to their tenant. Then, the Administrator can choose to approve those drivers for deployment. Drivers approved can vary between deployment rings.

          | -## Set driver and firmware updates to Automatic or Self-managed mode +> [!NOTE] +> In both Automatic and Manual modes, the drivers listed for selection represent only the drivers needed for the targeted clients, which are the Autopatch deployment rings. Therefore, the drivers offered may vary between rings depending on the variety of device hardware in an organization. -**To set driver and firmware updates to Automatic or Self-managed mode:** +#### Set driver and firmware updates to Automatic or Manual mode + +**To set driver and firmware updates to Automatic or Manual mode:** 1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Navigate to **Devices** > **Windows Autopatch** > **Release management** > **Release settings**. -1. In the **Windows Driver Updates** section, read and accept the agreement. -1. Select either **Automatic** or **Self-managed**. +1. Navigate to **Devices** > **Manage Updates** > **Windows Updates** > **Driver Updates** tab. +1. Select the groups you’d like to modify. Find the Driver update settings section, then select Edit. +1. Set the policy to be **Automatic** or **Manual** for each deployment ring within the previously selected group. + 1. If you select **Automatic**, you can choose a **Deferral period** in days from the dropdown menu. + 2. If you select **Manual**, the deferral day setting can’t be set and displays **Not applicable**. +1. Select **Review + Save** to review all changes made. +1. Once the review is done, select **Save** to commit your changes. -## View driver and firmware policies created by Windows Autopatch +##### Choose the deferral period for driver and firmware updates for Automatic deployment rings -**To view driver and firmware policies created by Windows Autopatch:** +For deployment rings set to **Automatic**, you can choose the deferral period for driver and firmware updates. The deferral period is the number of days that you must wait to deploy after a driver becomes available. By default, these deferral values match the values you set for your Windows quality updates. -1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Navigate to **Devices** > **Driver updates for Windows 10 and later**. -1. Windows Autopatch creates four policies. The policy names begin with **Windows Autopatch - Driver Update Policy** and end with the name of the deployment ring to which they're targeted in brackets. For example, **Windows Autopatch - Driver Update Policy [Test]**. +The deferral period allows you to delay the installation of driver and firmware updates on the devices in the specified deployment ring in case you want to test the update on a smaller group of devices first or avoid potential disruptions during a busy period. -The `CreateDriverUpdatePolicy` is created for the Test, First, Fast, and Broad deployment rings. The policy settings are defined in the following table: +The deferral period can be set from 0 to 14 days, and it can be different for each deployment ring. -| Policy name | DisplayName | Description | Approval Type | DeploymentDeferralInDays | -| ----- | ----- | ----- | ----- | ----- | -| `CreateDriverUpdatePolicy` | Windows Autopatch - Driver Update Policy [**Test**] | Driver Update Policy for device **Test** group | Automatic | `0` | -| `CreateDriverUpdatePolicy`| Windows Autopatch - Driver Update Policy [**First**] | Driver Update Policy for device **First** group | Automatic | `1` | -| `CreateDriverUpdatePolicy` |Windows Autopatch - Driver Update Policy [**Fast**] | Driver Update Policy for device **Fast** group | Automatic | `6` | -| `CreateDriverUpdatePolicy` | Windows Autopatch - Driver Update Policy [**Broad**] | Driver Update Policy for device **Broad** group | Automatic | `9` | +> [!NOTE] +> The deferral period only applies to Automatic driver and firmware updates. Updates to approved Manual policies, that are approved, are installed immediately. -## Feedback and support +### Recommended driver and firmware updates across managed devices -If you need support with this feature, and have enrolled your tenant into Windows Autopatch, [submit a support request](../operate/windows-autopatch-support-request.md). +#### Recommended drivers and firmware + +Recommended drivers are the best match for the 'required' driver updates that Windows Update can identify for a device. To be a recommended update, the OEM or driver publisher must mark the update as required and the update must be the most recent update version marked as required. These updates are the same ones available through Windows Update and are almost always the most current update version for a driver. + +When an OEM releases a newer update version that qualifies to be the new recommended driver, it replaces the previous update as the recommended driver update. If the older update version is still applicable to a device in the policy, it's moved to the **Other drivers** tab. If the older version was previously approved, it remains approved. + +##### Approve and deploy recommended drivers + +**To approve and deploy recommended drivers:** + +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), navigate to **Devices** > **Manage Updates** | **Windows Autopatch** > **Driver Updates** > **Recommended drivers** tab. This tab lists all drivers that are to be deployed to all Autopatch managed devices. +1. Select the driver or drivers you’d like to manage. +1. Select **Manage**. You can either: + 1. Approve the drivers for all or some deployment rings + 2. Decline the drivers for all or some deployment rings + 3. Manage the drivers for all or some deployment rings +1. In the **Approve for these rings** dropdown, select the applicable rings. Approved drivers are grayed out in the Decline for these rings dropdown. +1. In the **Decline for these rings** dropdown, select the applicable rings. Declined drivers are grayed out in the Approve for these rings dropdown. +1. Select **Save**. + +### Other drivers and firmware + +Other driver updates are updates available from the original equipment manufacturer (OEM) aside from the current recommended driver update. These updates remain in the policy if they're newer than the driver version that is currently installed on at least one device with the policy. + +These updates can include: + +- A previously recommended update is superseded by a newer update version +- Firmware updates +- Optional driver updates, or updates that the OEM doesn't intend to be installed on all devices by default + +#### Approve and deploy other drivers + +**To approve and deploy other drivers:** + +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), navigate to **Devices** > **Windows Autopatch** > **Release Management** > **Release schedule** > **Driver Updates** > **Other drivers** tab. This tab lists updates that are available from the original equipment manufacturer (OEM) aside from the current recommended driver update. The list of drivers in this tab can be long. +1. Select the driver or drivers you’d like to manage throughout the tenant. +1. Select **Manage**. You can either: + 1. Approve the drivers for all or some deployment rings + 2. Decline the drivers for all or some deployment rings + 3. Manage the drivers for all or some deployment rings +1. In the **Approve for these rings** dropdown, select the applicable rings. Approved drivers are grayed out in the Decline for these rings dropdown. +1. In the **Decline for these rings** dropdown, select the applicable rings. Declined drivers are grayed out in the Approve for these rings dropdown. +1. You must provide a justification for the change. If you need to submit a support request, you must copy and paste your justification in your support request. The Windows Autopatch Service Engineering Team doesn’t have access to your original justification. +1. Select **Save**. diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-windows-feature-update-releases.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-windows-feature-update-releases.md deleted file mode 100644 index dbdbcdcdc5..0000000000 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-manage-windows-feature-update-releases.md +++ /dev/null @@ -1,218 +0,0 @@ ---- -title: Manage Windows feature update releases -description: This article explains how you can manage Windows feature updates with Autopatch groups -ms.date: 07/08/2024 -ms.service: windows-client -ms.subservice: autopatch -ms.topic: how-to -ms.localizationpriority: medium -author: tiaraquan -ms.author: tiaraquan -manager: aaroncz -ms.reviewer: andredm7 -ms.collection: - - highpri - - tier1 ---- - -# Manage Windows feature update releases - -You can create custom releases for Windows feature update deployments in Windows Autopatch. - -## Before you begin - -Before you start managing custom Windows feature update releases, consider the following: - -- If you're planning on using either the [Default or Custom Autopatch groups](../deploy/windows-autopatch-groups-overview.md#key-concepts) ensure: - - The Default Autopatch group has all deployment rings and deployment cadences you need. - - You have created all your Custom Autopatch groups prior to creating custom releases. -- Review [Windows feature update prerequisites](/mem/intune/protect/windows-10-feature-updates#prerequisites). -- Review the [Windows feature updates policy limitations](/mem/intune/protect/windows-10-feature-updates#limitations-for-feature-updates-for-windows-10-and-later-policy). - -## About the auto-populate automation for release phases - -By default, the deployment rings of each Autopatch group will be sequentially assigned to a phase. For example, the first deployment ring of each Autopatch group is assigned to Phase 1, and the second deployment ring of each Autopatch group is assigned to Phase 2, etc. - -The following table explains the auto-populating assignment of your deployments rights if you have two Autopatch groups. One Autopatch group is named Finance and the other is named Marketing; each Autopatch group has four (Finance) and five (Marketing) deployment rings respectively. - -| Phases | Finance | Marketing -| ----- | ----- | ----- | -| Phase 1 | Test | Test | -| Phase 2 | Ring1 | Ring1 | -| Phase 3 | Ring2 | Ring2 | -| Phase 4 | Last | Ring3 | - -If the Autopatch groups are edited after a release is created (Active status), the changes to the Autopatch group won't be reflected unless you create a new custom release. - -If you wish to change the auto-populating assignment of your deployment rings to release phases, you can do so by adding, removing, or editing the auto-populated phases. - -### More information about the completion date of a phase - -The goal completion date of a phase is calculated using the following formula: - -` + ( - 1) * Days in between groups (7) + Deadline for feature updates (5 days) + Grace Period (2 days).` - -This formula is only applicable for **Deadline-driven** not for Scheduled-driven deployment cadences. For more information, see [Customize Windows Update settings](../operate/windows-autopatch-groups-windows-update.md). - -> [!IMPORTANT] -> By default, both the **Deadline for feature updates** and the **Grace period** values are set by Windows Autopatch in every [Update rings for Windows 10 and later policy](/mem/intune/protect/windows-10-update-rings) created by Autopatch groups. - -### How to use the Windows feature update blade - -Use the Windows feature update blade to check in the overall status of the [default release](../operate/windows-autopatch-groups-windows-feature-update-overview.md#default-release) and the custom ones you create. - -**To access the Windows feature update blade:** - -1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Select **Devices** from the left navigation menu. -1. Under the **Windows Autopatch** section, select **Release management**. -1. In the **Release management** blade, under the **Release schedule** tab, select **Windows feature updates**. -1. In the **Windows feature updates** blade, you can see all the information about the releases. The columns are described in the following table: - -| Status | Description | -| ----- | ----- | -| Release name | Name of the release | -| Version to deploy | Version to deploy for the applicable release or phase | -| Status | Status of the applicable release or phase:
          • Scheduled
          • Active
          • Inactive
          • Paused
          • Canceled
          | -| First deployment |
          • The date the deployment for the applicable release or phase will begin.
          • Feature update policy for Windows 10 and later is created 24 hours prior to the first deployment date. The service automation runs twice a day at 4:00AM and 4:00PM (UTC).
          • Not all devices within a phase will be offered the feature update on the same date when using gradual rollout.
          | -| Goal completion date | The date the devices within the release or phases are expected to finish updating. The completion date is calculated using the following formula:

          ` + ( - 1) * Days in between groups (7) + Deadline for feature updates (5) + Grace Period (2)`

          | - -#### About release and phase statuses - -##### Release statuses - -A release is made of one or more phases. The release status is based on the calculation and consolidation of each phase status. - -The release statuses are described in the following table: - -| Release status | Definition | Options | -| ----- | ----- | ----- | -| Scheduled | Release is scheduled and not all phases have yet created its Windows feature update policies |
          • Releases with the **Scheduled status** can't be canceled but can have its deployment cadence edited as not all phases have yet created its Windows feature update policies.
          • Autopatch groups and its deployment rings that belong to a **Scheduled** release can't be assigned to another release.
          | -| Active | All phases in the release are active. This means all phases have reached their first deployment date, which created the Windows feature update policies. |
          • Release can be paused but can't be edited or canceled since the Windows feature update policy was already created for its phases.
          • Autopatch groups and their deployment rings can be assigned to another release.
          | -| Inactive | All the Autopatch groups within the release have been assigned to a new release. As a result, the Windows feature update policies were unassigned from all phases from within the release. |
          • Release can be viewed as a historical record.
          • Releases can't be deleted, edited, or canceled.
          | -| Paused | All phases in the release are paused. The release will remain paused until you resume it. |
          • Releases with Paused status can't be edited or canceled since the Windows feature update policy was already created for its phases.
          • Release can be resumed.
          | -| Canceled | All phases in the release are canceled. |
          • Releases with Canceled status can't be edited or canceled since the Windows feature update policy wasn't created for its phases.
          • Canceled release can't be deleted.
          | - -##### Phase statuses - -A phase is made of one or more Autopatch group deployment rings. Each phase reports its status to its release. - -> [!IMPORTANT] -> The determining factor that makes a phase status transition from **Scheduled** to **Active** is when the service automatically creates the Windows feature update policy for each Autopatch group deployment ring. Additionally, the phase status transition from **Active** to **Inactive** occurs when Windows feature update policies are unassigned from the Autopatch groups that belong to a phase. This can happen when an Autopatch group and its deployment rings are re-used as part of a new release. - -| Phase status | Definition | -| ----- | ----- | -| Scheduled | The phase is scheduled but hasn't reached its first deployment date yet. The Windows feature update policy hasn't been created for the respective phase yet. | -| Active | The first deployment date has been reached. The Windows feature update policy has been created for the respective phase. | -| Inactive | All Autopatch groups within the phase were re-assigned to a new release. All Windows feature update policies were unassigned from the Autopatch groups. | -| Paused | Phase is paused. You must resume the phase. | -| Canceled | Phase is canceled. All Autopatch groups within the phase can be used with a new release. A phase that's canceled can't be deleted. | - -#### Details about Windows feature update policies - -Windows Autopatch creates one Windows feature update policy per phase using the following naming convention: - -`Windows Autopatch - DSS policy - - Phase ` - -These policies can be viewed in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). - -The following table is an example of the Windows feature update policies that were created for phases within a release: - -| Policy name | Feature update version | Rollout options | First deployment date| Final deployment date availability | Day between groups | Support end date | -| ----- | ----- | ----- | ----- | ----- | ----- | ----- | -| Windows Autopatch - DSS Policy - My feature update release - Phase 1 | Windows 10 21H2 | Make update available as soon as possible | April 24, 2023 | April 24, 2023 | N/A | June 11, 2024 | -| Windows Autopatch - DSS Policy - My feature update release - Phase 2 | Windows 10 21H2 | Make update available as soon as possible | June 26, 2023 | July 17, 2023 | 7 | June 11, 2024 | -| Windows Autopatch - DSS Policy - My feature update release - Phase 3 | Windows 10 21H2 | Make update available as soon as possible | July 24, 2023 | August 14, 2023 | 7 | June 11, 2024 | -| Windows Autopatch - DSS Policy - My feature update release - Phase 4 | Windows 10 21H2 | Make update available as soon as possible | August 28, 2023 | September 10, 2023 | 7 | June 11, 2024 | -| Windows Autopatch - DSS Policy - My feature update release - Phase 5 | Windows 10 21H2 | Make update available as soon as possible | September 25, 2023 | October 16, 2023 | 7 | June 11, 2024 | - -## Create a custom release - -**To create a custom release:** - -1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Select **Devices** from the left navigation menu. -1. Under the **Windows Autopatch** section, select **Release management**. -1. In the **Release management** blade, select **Release schedule**, then **Windows feature updates**. -1. In the **Windows feature updates** blade, select **New release**. -1. In the **Basics** page: - 1. Enter a **Name** for the custom release. - 2. Select the **Version** to deploy. - 3. Enter a **Description** for the custom release. - 4. Select **Next**. -1. In the **Autopatch groups** page, choose one or more existing Autopatch groups you want to include in the custom release, then select Next. -1. You can't choose Autopatch groups that are already part of an existing custom release. Select **Autopatch groups assigned to other releases** to review existing assignments. -1. In the Release phases page, review the number of auto-populated phases. You can Edit, Delete and Add phase based on your needs. Once you're ready, select **Next**. **Before you proceed to the next step**, all deployment rings must be assigned to a phase, and all phases must have deployment rings assigned. -1. In the **Release schedule** page, choose **First deployment date**, and the number of **Gradual rollout groups**, then select **Next**. **You can only select the next day**, not the current day, as the first deployment date. The service creates feature update policy for Windows 10 and later twice a day at 4:00AM and 4:00PM (UTC) and can't guarantee that the release will start at the current day given the UTC variance across the globe. - 1. The **Goal completion date** only applies to the [Deadline-driven deployment cadence type](../operate/windows-autopatch-groups-windows-update.md#deadline-driven). The Deadline-drive deployment cadence type can be specified when you configure the Windows Updates settings during the Autopatch group creation/editing flow. - 2. Additionally, the formula for the goal completion date is ` + ( - 1) * Days in between groups (7) + Deadline for feature updates (5 days) + Grace Period (2 days)`. -1. In the **Review + create** page, review all settings. Once you're ready, select **Create**. - -> [!NOTE] -> Custom releases can't be deleted from the Windows feature updates release management blade. The custom release record serves as a historical record for auditing purposes when needed. - -## Edit a release - -> [!NOTE] -> Only custom releases that have the **Scheduled** status can be edited. A release phase can only be edited prior to reaching its first deployment date. Additionally, you can only edit the deployment dates when editing a release. - -**To edit a custom release:** - -1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Select **Devices** from the left navigation menu. -1. Under the **Windows Autopatch** section, select **Release management**. -1. In the **Release schedule** tab, select **Windows feature updates**. -1. In the **Windows feature updates** blade, select the **horizontal ellipses (…)** > Edit to customize your gradual rollout of your feature updates release, then select **Save**. - 1. Only the release schedule can be customized when using the edit function. You can't add or remove Autopatch groups or modify the phase order when editing a release. -1. Select **Review + Create**. -1. Select **Apply** to save your changes. - -## Pause and resume a release - -> [!CAUTION] -> You should only pause and resume [Windows quality](../operate/windows-autopatch-groups-windows-quality-update-overview.md#pause-and-resume-a-release) and [Windows feature updates](../operate/windows-autopatch-groups-windows-feature-update-overview.md) on Windows Autopatch managed devices using the Windows Autopatch Release management blade. Do **not** use the Microsoft Intune end-user experience flows to pause or resume Windows Autopatch managed devices. - -> [!IMPORTANT] -> Pausing or resuming an update can take up to eight hours to be applied to devices. Windows Autopatch uses Microsoft Intune as its device management solution and that's the average frequency Windows devices take to communicate back to Microsoft Intune with new instructions to pause, resume or rollback updates. For more information, see [how long does it take for devices to get a policy, profile, or app after they are assigned from Microsoft Intune](/mem/intune/configuration/device-profile-troubleshoot#how-long-does-it-take-for-devices-to-get-a-policy-profile-or-app-after-they-are-assigned). - -**To pause or resume a release:** - -> [!NOTE] -> If you've paused an update, the specified release will have the **Paused** status. The Windows Autopatch service can't overwrite IT admin's pause. You must select **Resume** to resume the update. The **Paused by Service Pause** status **only** applies to Windows quality updates. Windows Autopatch doesn't pause Windows feature updates on your behalf. - -1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Select **Devices** from the left navigation menu. -1. Under the **Windows Autopatch** section, select **Release management**. -1. In the **Release schedule** tab, select **Windows feature updates**. -1. In the **Windows feature updates** blade, select the **horizontal ellipses (…)** > **Pause** or **Resume** to pause or resume your feature updates release. -1. Select a reason from the dropdown menu. -1. Optional. Enter details about why you're pausing or resuming the selected update. -1. If you're resuming an update, you can select one or more deployment rings. -1. Select **Pause deployment** or **Resume deployment** to save your changes. - -## Cancel a release - -> [!IMPORTANT] -> You can only cancel a release under the Scheduled status. You cannot cancel a release under the **Active**, **Inactive** or **Paused** statuses. - -**To cancel a release:** - -1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Select **Devices** from the left navigation menu. -1. Under the **Windows Autopatch** section, select **Release management**. -1. In the **Release schedule** tab, select **Windows feature updates**. -1. In the **Windows feature updates** blade, select the **horizontal ellipses (…)** > **Cancel** to cancel your feature updates release. -1. Select a reason for cancellation from the dropdown menu. -1. Optional. Enter details about why you're pausing or resuming the selected update. -1. Select **Cancel deployment** to save your changes. - -## Roll back a release - -> [!CAUTION] -> Do **not** use Microsoft Intune's end-user flows to rollback Windows feature update deployments for Windows Autopatch managed devices. If you need assistance with rolling back deployments, [submit a support request](../operate/windows-autopatch-support-request.md). - -Windows Autopatch **doesn't** support the rollback of Windows feature updates through its end-user experience flows. - -## Contact support - -If you're experiencing issues related to Windows feature update deployments, [submit a support request](../operate/windows-autopatch-support-request.md). diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-apps-enterprise.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-apps-enterprise.md index 7cfc8cb222..fec46b3cb0 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-apps-enterprise.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-apps-enterprise.md @@ -1,7 +1,7 @@ --- title: Microsoft 365 Apps for enterprise description: This article explains how Windows Autopatch manages Microsoft 365 Apps for enterprise updates -ms.date: 10/27/2023 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -17,8 +17,13 @@ ms.collection: # Microsoft 365 Apps for enterprise +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + ## Service level objective +> [!IMPORTANT] +> To update Microsoft 365 Apps for enterprise, you must [create at least one Autopatch group](../manage/windows-autopatch-groups-manage-autopatch-groups.md#create-an-autopatch-group) first and **Microsoft 365 app update setting** must be set to [**Allow**](#allow-or-block-microsoft-365-app-updates). For more information on workloads supported by Windows Autopatch groups, see [Software update workloads](../deploy/windows-autopatch-groups-overview.md#software-update-workloads). + Windows Autopatch aims to keep at least 90% of eligible devices on a [supported version](/deployoffice/overview-update-channels#support-duration-for-monthly-enterprise-channel) of the Monthly Enterprise Channel (MEC) for the: - [Enterprise Standard Suite](/deployoffice/about-microsoft-365-apps). The Enterprise Standard Suite includes Access, Excel, OneNote, Outlook, PowerPoint, and Word. @@ -27,7 +32,7 @@ Windows Autopatch aims to keep at least 90% of eligible devices on a [supported Microsoft 365 Apps deployed on the [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview) are supported for two months. > [!NOTE] -> [Microsoft Teams](../operate/windows-autopatch-teams.md) uses a different update channel from the rest of Microsoft 365 Apps. +> [Microsoft Teams](../manage/windows-autopatch-teams.md) uses a different update channel from the rest of Microsoft 365 Apps. ## Device eligibility @@ -36,14 +41,14 @@ For a device to be eligible for Microsoft 365 Apps for enterprise updates (both - The device must be turned on and have an internet connection. - The device must be able to access the [required network endpoints](../prepare/windows-autopatch-configure-network.md#required-microsoft-product-endpoints) to reach the Office Content Delivery Network (CDN). - There are no policy conflicts between Microsoft Autopatch policies and customer policies. -- The device must have checked into the Intune service in the last five days. +- The device must check into the Intune service in the last five days. - If Microsoft 365 Apps are running, the apps must close for the update process to complete. ## Update release schedule All devices registered for Windows Autopatch receive updates from the [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview). This practice provides your users with new features each month, and they receive just one update per month on a predictable release schedule. Updates are released on the second Tuesday of the month; these updates can include feature, security, and quality updates. These updates occur automatically and pulled directly from the Office Content Delivery Network (CDN). -Unlike Windows update, the Office CDN doesn't make the update available to all devices at once. Over the course of the release, the Office CDN gradually makes the update available to the whole population of devices. Windows Autopatch doesn't control the order in which updates are offered to devices across your estate. After the update downloads, there's a seven day [update deadline](../references/windows-autopatch-microsoft-365-policies.md) that specifies how long the user has until the user must apply the update. +Unlike Windows update, the Office CDN doesn't make the update available to all devices at once. Over the course of the release, the Office CDN gradually makes the update available to the whole population of devices. Windows Autopatch doesn't control the order in which updates are offered to devices across your estate. After the update downloads, there's a seven day [update deadline](../manage/windows-autopatch-microsoft-365-policies.md) that specifies how long the user has until the user must apply the update. ## Deployment rings @@ -63,7 +68,7 @@ Windows Autopatch configures the following end user experiences: Updates are only applied when Microsoft 365 Apps aren't running. Therefore, [end user notifications for Microsoft 365 Apps](/deployoffice/updates/end-user-update-notifications-microsoft-365-apps) usually appear when: -- The user is working in a Microsoft 365 App, such as Microsoft Outlook, and hasn't closed it in several days. +- The user is working in a Microsoft 365 App, such as Microsoft Outlook, and didn't closed it in several days. - The update [deadline arrives](/deployoffice/updates/end-user-update-notifications-microsoft-365-apps#notifications-your-users-see-when-you-set-an-update-deadline-for-microsoft-365-apps) and the updates still aren't applied. ### Office client app configuration @@ -74,7 +79,7 @@ To ensure that users are receiving automatic updates, Windows Autopatch prevents Windows Autopatch doesn't allow you to pause or roll back an update in the Microsoft Intune admin center. -[Submit a support request](../operate/windows-autopatch-support-request.md) to the Windows Autopatch Service Engineering Team to pause or roll back an update when needed. +[Submit a support request](../manage/windows-autopatch-support-request.md) to the Windows Autopatch Service Engineering Team to pause or roll back an update when needed. > [!NOTE] > Updates are bundled together into a single release in the [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview). Therefore, we can't roll back only a portion of the update for Microsoft 365 Apps for enterprise. @@ -94,19 +99,19 @@ For organizations seeking greater control, you can allow or block Microsoft 365 **To allow or block Microsoft 365 App updates:** 1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -2. Navigate to the **Devices** > **Release Management** > **Release settings**. -3. Go to the **Microsoft 365 apps updates** section. By default, the **Allow/Block** toggle is set to **Allow**. -4. Turn off the **Allow** toggle to opt out of Microsoft 365 App update policies. You'll see the notification: *Update in process. This setting will be unavailable until the update is complete.* -5. Once the update is complete, you'll receive the notification: *This setting is updated.* +2. Navigate to the **Tenant administration** > **Windows Autopatch** > **Autopatch groups** > **Update settings**. +3. Go to the **Microsoft 365 apps updates** section. By default, the **Allow/Block** toggle is set to **Block**. +4. Turn off the **Allow** toggle to opt out of Microsoft 365 App update policies. You see the notification: *Update in process. This setting will be unavailable until the update is complete.* +5. Once the update is complete, you receive the notification: *This setting is updated.* > [!NOTE] -> If the notification: *This setting couldn't be updated. Please try again or submit a support request.* appears, use the following steps:
          1. Refresh your page.
          2. Please repeat the same steps in To block Windows Autopatch Microsoft 365 apps updates.
          3. If the issue persists, [submit a support request](../operate/windows-autopatch-support-request.md).
            4. +> If the notification: *This setting couldn't be updated. Please try again or submit a support request.* appears, use the following steps:
            1. Refresh your page.
            2. Please repeat the same steps in To block Microsoft 365 apps updates.
            3. If the issue persists, [submit a support request](../manage/windows-autopatch-support-request.md).
              4. **To verify if the Microsoft 365 App update setting is set to Allow:** 1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 2. Navigate to **Devices** > **Configuration profiles** > **Profiles**. -3. The following **five** profiles should be discoverable from the list of profiles: +3. The following profiles should be discoverable from the list of profiles: 1. Windows Autopatch - Office Configuration 2. Windows Autopatch - Office Update Configuration [Test] 3. Windows Autopatch - Office Update Configuration [First] @@ -117,7 +122,7 @@ For organizations seeking greater control, you can allow or block Microsoft 365 1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 2. Navigate to **Devices** > **Configuration profiles** > **Profiles**. -3. The following **five** profiles should be removed from your list of profiles and no longer visible/active. Use the Search with the keywords "Office Configuration". The result should return *0 profiles filtered*. +3. The following profiles should be removed from your list of profiles and no longer visible/active. Use the Search with the keywords "Office Configuration". The result should return *0 profiles filtered*. 1. Windows Autopatch - Office Configuration 2. Windows Autopatch - Office Update Configuration [Test] 3. Windows Autopatch - Office Update Configuration [First] @@ -128,10 +133,8 @@ For organizations seeking greater control, you can allow or block Microsoft 365 [Servicing profiles](/deployoffice/admincenter/servicing-profile) is a feature in the [Microsoft 365 Apps admin center](https://config.office.com/) that provides controlled update management of monthly Office updates, including controls for user and device targeting, scheduling, rollback, and reporting. -A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other policies, such as a Microsoft Intune policy or the Office Deployment Tool. The servicing profile affects all devices that meet the [device eligibility requirements](#device-eligibility) regardless of existing management tools in your environment. So, if you're targeting a managed device with a servicing profile it's ineligible for Microsoft 365 App update management.However, the device may still be eligible for other managed updates. +A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other policies, such as a Microsoft Intune policy or the Office Deployment Tool. The servicing profile affects all devices that meet the [device eligibility requirements](#device-eligibility) regardless of existing management tools in your environment. So, if you're targeting a managed device with a servicing profile it's ineligible for Microsoft 365 App update management. However, the device might still be eligible for other managed updates. ## Incidents and outages -If devices in your tenant aren't meeting the [service level objective](#service-level-objective) for Microsoft 365 Apps for enterprise updates, an incident is raised. The Windows Autopatch Service Engineering Team will work to bring the devices back into compliance. - -If you're experiencing issues related to Microsoft 365 Apps for enterprise updates, [submit a support request](../operate/windows-autopatch-support-request.md). +If you're experiencing issues related to Microsoft 365 Apps for enterprise updates, [submit a support request](../manage/windows-autopatch-support-request.md). diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-policies.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-policies.md index 2311528bed..b82a92e490 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-policies.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-policies.md @@ -1,7 +1,7 @@ --- title: Microsoft 365 Apps for enterprise update policies description: This article explains the Microsoft 365 Apps for enterprise policies in Windows Autopatch -ms.date: 07/08/2024 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: concept-article @@ -16,6 +16,8 @@ ms.collection: # Microsoft 365 Apps for enterprise update policies +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + ## Conflicting and unsupported policies Deploying any of the following policies to a managed device makes that device ineligible for management since the device prevents us from delivering the service as designed. diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-release-schedule.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-release-schedule.md new file mode 100644 index 0000000000..40f899d0a2 --- /dev/null +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-release-schedule.md @@ -0,0 +1,35 @@ +--- +title: Manage the release schedule +description: How to manage the release schedule +ms.date: 09/16/2024 +ms.service: windows-client +ms.subservice: autopatch +ms.topic: how-to +ms.localizationpriority: medium +author: tiaraquan +ms.author: tiaraquan +manager: aaroncz +ms.reviewer: andredm7 +ms.collection: + - highpri + - tier1 +--- + +# Manage the Release schedule + +[!INCLUDE [windows-autopatch-applies-to-all-licenses](../includes/windows-autopatch-applies-to-all-licenses.md)] + +Windows Autopatch provides a unique update experience and a single view for all your current quality, feature, and driver and firmware releases. This view: + +- Consolidates all your applicable policies into a view consolidated by releases +- Provides an all-up summary of the current release applicable to your tenant + +When you select a release, Windows Autopatch provides a list view of associated policies and metrics including: + +- Start and end dates +- percentage complete + +These metrics are a summary of the individual workload views that should be used to manage your updates. + +> [!NOTE] +> **The device count metric is only available if you have Windows Enterprise E3+ or F3 licenses (included in Microsoft 365 F3, E3, or E5) licenses and have [activated Windows Autopatch features](../overview/windows-autopatch-overview.md#windows-enterprise-e3+-and-f3-licenses).**

              [Feature activation](../prepare/windows-autopatch-feature-activation.md) is optional and at no additional cost to you if you have Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) licenses.

              For more information, see [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements). If you choose not to go through feature activation, you can still use the Windows Autopatch service for the features included in [Business premium and A3+ licenses](../overview/windows-autopatch-overview.md#business-premium-and-a3+-licenses).

              diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-support-request.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-support-request.md index c6eb294c1a..6465a2a404 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-support-request.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-support-request.md @@ -1,7 +1,7 @@ --- title: Submit a support request description: Details how to contact the Windows Autopatch Service Engineering Team and submit support requests -ms.date: 09/06/2023 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -17,6 +17,8 @@ ms.collection: # Submit a support request +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + > [!IMPORTANT] > Make sure you've [added and verified your admin contacts](../deploy/windows-autopatch-admin-contacts.md). The Windows Autopatch Service Engineering Team will contact these individuals for assistance with remediating issues. @@ -29,7 +31,7 @@ Support requests are triaged and responded to as they're received. 1. Sign into the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and navigate to the **Tenant administration** menu. 1. In the **Windows Autopatch** section, select **Support requests**. 1. In the **Support requests** section, select **+ New support request**. -1. Enter your question(s) and/or a description of the problem. +1. Enter your questions and/or a description of the problem. 1. Review all the information you provided for accuracy. 1. When you're ready, select **Create**. @@ -44,12 +46,12 @@ Depending on your support contract, the following severity options are available | Support contract | Severity options | | ----- | ----- | -| Premier | Severity A, B or C | -| Unified | Critical or non-critical | +| Premier | Severity A, B, or C | +| Unified | Critical or noncritical | ## Manage an active support request -The primary contact for the support request will receive email notifications when a case is created, assigned to a service engineer to investigate, and mitigated. If, at any point, you have a question about the case, the best way to get in touch is to reply directly to one of those emails. If we have questions about your request or need more details, we'll email the primary contact listed on the support requests. +The primary contact for the support request receives email notifications when a case is created, assigned to a service engineer to investigate, and mitigated. If, at any point, you have a question about the case, the best way to get in touch is to reply directly to one of those emails. If we have questions about your request or need more details, we email the primary contact listed on the support requests. ## View all your active support requests @@ -75,7 +77,7 @@ You can edit support request details, for example, updating the primary case con 1. Update the editable information, add attachments to the case, or add a note for the Windows Autopatch Service Engineering Team. 1. Select **Save**. -Once a support request is mitigated, it can no longer be edited. If a request has been mitigated for less than 24 hours, you'll see the option to reactivate instead of edit. Once reactivated, you can again edit the request. +Once a support request is mitigated, it can no longer be edited. If a request was mitigated in less than 24 hours, you can reactivate instead of edit. Once reactivated, you can again edit the request. ## Microsoft FastTrack @@ -83,4 +85,4 @@ Once a support request is mitigated, it can no longer be edited. If a request ha Customers who need help with Microsoft 365 workloads can sign in to [Microsoft FastTrack](https://fasttrack.microsoft.com/) with a valid Azure ID and submit a Request for Assistance. - Contact your Microsoft account team if you need additional assistance. +Contact your Microsoft account team if you need additional assistance. diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-teams.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-teams.md index 37a7cc46c9..e6b32fd7ca 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-teams.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-teams.md @@ -1,7 +1,7 @@ --- title: Microsoft Teams description: This article explains how Microsoft Teams updates are managed in Windows Autopatch -ms.date: 09/15/2023 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: how-to @@ -17,6 +17,8 @@ ms.collection: # Microsoft Teams +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + Windows Autopatch uses the [standard automatic update channel](/microsoftteams/teams-client-update#can-admins-deploy-updates-instead-of-teams-auto-updating) for Microsoft Teams. ## Device eligibility @@ -30,13 +32,13 @@ For a device to be eligible for automated Teams updates as a part of Windows Aut ## Update release schedule -The Teams desktop client updates are released once a month for all users, and twice a month for members of the Technology Adoption Program (TAP). +The Teams desktop client updates are released once a month for all users, and twice a month for members of the [Technology Adoption Program (TAP)](https://developer.microsoft.com/microsoft-365/tap). -Updates undergo vigorous internal testing and are first released to members of TAP for validation. The update usually takes place on a Monday. If a critical update is needed, Teams will bypass this schedule and release the update as soon as it's available. +Updates undergo vigorous internal testing and are first released to members of [Technology Adoption Program (TAP)](https://developer.microsoft.com/microsoft-365/tap) for validation. The update usually takes place on a Monday. If a critical update is needed, Teams bypasses this schedule and releases the update as soon as it's available. ## End user experience -Teams will check for updates every few hours behind the scenes, download the updates, and then will wait for the computer to be idle for at least 40 minutes before automatically installing the update. +Teams checks for updates every few hours behind the scenes, download the updates, and then waits for the computer to be idle for at least 40 minutes before automatically installing the update. When an update is available, the following are required to be able to download the update: @@ -47,7 +49,7 @@ When an update is available, the following are required to be able to download t > [!NOTE] > If a user is on a version of Teams that is out of date, Teams will force the user to update prior to allowing them to use the application. -## Pausing and resuming updates +## Pause and resume updates Windows Autopatch can't pause or resume Teams updates. diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-troubleshoot-programmatic-controls.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-troubleshoot-programmatic-controls.md new file mode 100644 index 0000000000..62a8d7c8e5 --- /dev/null +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-troubleshoot-programmatic-controls.md @@ -0,0 +1,63 @@ +--- +title: Troubleshoot programmatic controls +titleSuffix: Windows Autopatch +description: Solutions to commonly encountered problems when using Windows Autopatch API. +ms.service: windows-client +ms.subservice: autopatch +ms.topic: troubleshooting +ms.author: tiaraquan +author: tiaraquan +manager: aaroncz +ms.collection: + - tier1 +ms.localizationpriority: medium +appliesto: +- ✅ Windows 11 +- ✅ Windows 10 +ms.date: 09/16/2024 +--- + +# Troubleshoot programmatic controls + +This troubleshooting guide addresses the most common issues that IT administrators face when using Windows Autopatch API. For a general troubleshooting guide for Windows Update, see [Windows Update troubleshooting](/troubleshoot/windows-client/deployment/windows-update-issues-troubleshooting?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json). + +## The device isn't receiving an update that I deployed + +- Check that the device doesn't have updates of the relevant category paused. See [Pause feature updates](/windows/deployment/update/waas-configure-wufb) and [Pause quality updates](/windows/deployment/update/waas-configure-wufb). +- **Feature updates only**: The device might have a safeguard hold applied for the given feature update version. For more about safeguard holds, see [Safeguard holds](/windows/deployment/update/safeguard-holds) and [Opt out of safeguard holds](/windows/deployment/update/safeguard-opt-out). +- Check that the deployment to which the device is assigned has the state *offering*. Deployments that have the states *paused* or *scheduled* doesn't deploy content to devices. +- Check that the device was scanned for updates and is scanning the Windows Update service. To learn more about scanning for updates, see [Scanning updates](/windows/deployment/update/how-windows-update-works#scanning-updates). +- **Feature updates only**: Check that the device is successfully enrolled in feature update management. A device that is successfully enrolled will be represented by a Microsoft Entra device resource with an update management enrollment for feature updates and have no Microsoft Entra device registration errors. +- **Expedited quality updates only**: Check that the device has the Update Health Tools installed (available for Windows 10 version 1809 or later in the update described in [KB 4023057 - Update for Windows 10 Update Service components](https://support.microsoft.com/topic/kb4023057-update-for-windows-10-update-service-components-fccad0ca-dc10-2e46-9ed1-7e392450fb3a), or a more recent quality update). The Update Health Tools are required for a device to receive an expedited quality update. On a device, the program can be located at **C:\\Program Files\\Microsoft Update Health Tools**. You can verify its presence by reviewing **Add or Remove Programs** or using the following PowerShell script: `Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -match "Microsoft Update Health Tools"}`. + +## The device is receiving an update that I didn't deploy + +- Check that the device is scanning the Windows Update service and not a different endpoint. If the device is scanning for updates from a WSUS endpoint, for example, it might receive different updates. To learn more about scanning for updates, see [Scanning updates](/windows/deployment/update/how-windows-update-works#scanning-updates). +- **Feature updates only**: Check that the device is successfully enrolled in feature update management. A device that isn't successfully enrolled might receive different updates according to its feature update deferral period, for example. A device that is successfully enrolled will be represented by a Microsoft Entra device resource with an update management enrollment for feature updates and have no Microsoft Entra device registration errors. + +### The device installed a newer update than the expedited update I deployed + +There are some scenarios when a deployment to expedite an update results in the installation of a more recent update than specified in policy. This result occurs when the newer update includes and surpasses the specified update, and that newer update is available before a device checks in to install the update that's specified in the expedited update policy. + +Installing the most recent quality update reduces disruptions to the device and user while applying the benefits of the intended update. This avoids having to install multiple updates, which each might require separate reboots. + +A more recent update is deployed when the following conditions are met: + +- The device isn't targeted with a deferral policy that blocks installation of a more recent update. In this case, the most recently available update that isn't deferred is the update that might install. + +- During the process to expedite an update, the device runs a new scan that detects the newer update. This can occur due to the timing of: + - When the device restarts to complete installation + - When the device runs its daily scan + - When a new update becomes available + + When a scan identifies a newer update, Windows Update attempts to stop installation of the original update, cancel the restart, and then starts the download and installation of the more recent update. + +While expedite update deployments override an update deferral for the update version that's specified, they don't override deferrals that are in place for any other update version. + + +[!INCLUDE [Windows Autopatch Update Health Tools](../includes/windows-autopatch-update-health-tools-logs.md)] + +## Policy considerations for drivers + + +[!INCLUDE [Windows Autopatch driver policy considerations](../includes/windows-autopatch-driver-policy-considerations.md)] diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-update-rings.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-update-rings.md new file mode 100644 index 0000000000..296bef04db --- /dev/null +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-update-rings.md @@ -0,0 +1,68 @@ +--- +title: Manage Update rings +description: How to manage update rings +ms.date: 09/16/2024 +ms.service: windows-client +ms.subservice: autopatch +ms.topic: how-to +ms.localizationpriority: medium +author: tiaraquan +ms.author: tiaraquan +manager: aaroncz +ms.reviewer: andredm7 +ms.collection: + - highpri + - tier1 +--- + +# Manage Update rings + +[!INCLUDE [windows-autopatch-applies-to-all-licenses](../includes/windows-autopatch-applies-to-all-licenses.md)] + +You can manage Update rings for Windows 10 and later devices with Windows Autopatch. Using Update rings, you can control when and how updates are installed on your devices. For more information, see [Configure Update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings). + +## Import Update rings for Windows 10 and later + +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + +You can import your organization’s existing Intune Update rings for Windows 10 and later into Windows Autopatch. Importing your organization’s Update rings provides the benefits of the Windows Autopatch's reporting and device readiness without the need to redeploy, or change your organization’s existing update rings. + +Imported rings automatically register all targeted devices into Windows Autopatch. For more information about device registration, see the [device registration workflow diagram](../deploy/windows-autopatch-device-registration-overview.md#detailed-device-registration-workflow-diagram). + +> [!NOTE] +> Devices which are registered as part of an imported ring, might take up to 72 hours after the devices have received the latest version of the policy, to be reflected in Windows Autopatch devices blade and reporting. For more information about reporting, see [Windows quality and feature update reports overview](../monitor/windows-autopatch-windows-quality-and-feature-update-reports-overview.md). + +> [!NOTE] +> Device registration failures don't affect your existing update schedule or targeting. However, devices that fail to register might affect Windows Autopatch's ability to provide reporting and insights. Any conflicts should be resolved as needed. For additional assistance, [submit a support request](../manage/windows-autopatch-support-request.md). + +### To import Update rings for Windows 10 and later + +**To import Update rings for Windows 10 and later:** + +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +2. Select **Devices** from the left navigation menu. +3. Under the **Windows Autopatch** section, select **Release management**. +4. In the **Release management** blade, go to the **Release schedule** tab and select **Windows quality updates**. +5. Select **Import Update rings for Windows 10 and later**. +6. Select the existing rings you would like to import. +7. Select **Import**. + +### Remove an imported Update ring for Windows 10 and later + +**To remove an Imported Update rings for Windows 10 and later:** + +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +2. Select **Devices** from the left navigation menu. +3. Under the **Windows Autopatch** section, select **Release management**. +4. In the **Release management** blade, go to the **Release schedule** tab and select **Windows quality updates**. +5. Select the Update rings for Windows 10 and later you would like to remove. +6. Select the **horizontal ellipses (...)** and select **Remove**. + +### Known limitations + +The following Windows Autopatch features aren't available with imported Intune Update rings: + +- [Autopatch groups](../deploy/windows-autopatch-groups-overview.md) and [features dependent on Autopatch groups](../deploy/windows-autopatch-groups-overview.md#supported-configurations) +- [Moving devices in between deployment rings in devices](../deploy/windows-autopatch-register-devices.md#move-devices-in-between-deployment-rings) +- [Automated deployment ring remediation functions](../deploy/windows-autopatch-device-registration-overview.md#automated-deployment-ring-remediation-functions) +- [Policy health and remediation](../monitor/windows-autopatch-policy-health-and-remediation.md) diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-overview.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-overview.md index 233baa86f8..0a28bce8df 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-overview.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-overview.md @@ -1,7 +1,7 @@ --- title: Windows feature updates overview -description: This article explains how Windows feature updates are managed with Autopatch groups -ms.date: 07/08/2024 +description: This article explains how Windows feature updates are managed +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: overview @@ -15,158 +15,129 @@ ms.collection: - tier1 --- -# Windows feature updates overview +# Windows feature update -Microsoft provides robust mobile device management (MDM) solutions such as Microsoft Intune, Windows Update for Business, Configuration Manager etc. However, the administration of these solutions to keep Windows devices up to date with the latest Windows feature releases rests on your organization's IT admins. The Windows feature update process is considered one of the most expensive and time consuming tasks for IT since it requires incremental rollout and validation. +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] -Windows feature updates consist of: +Windows Autopatch provides tools to assist with the controlled roll out of annual Windows feature updates. These policies provide tools to allow version targeting, phased releases, and even Windows 10 to Windows 11 update options. For more information about how to configure feature update profiles, see [Feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates). -- Keeping Windows devices protected against behavioral issues. -- Providing new features to boost end-user productivity. +## Multi-phase feature update -Windows Autopatch makes it easier and less expensive for you to keep your Windows devices up to date. You can focus on running your core businesses while Windows Autopatch runs update management on your behalf. +Multi-phase feature update allows you to create customizable feature update deployments using multiple phases for your [existing Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md). These phased releases can be tailored to meet your organizational unique needs. -## Service level objective +### Release statuses -Windows Autopatch's service level objective for Windows feature updates aims to keep **95%** of eligible devices on the targeted Windows OS version [currently serviced](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2) for its default and global releases maintained by the service, and custom releases created and managed by you. +A release is made of one or more phases. The release status is based on the calculation and consolidation of each phase status. -## Device eligibility criteria +The release statuses are described in the following table: -Windows Autopatch's device eligibility criteria for Windows feature updates aligns with [Windows Update for Business and Microsoft Intune's device eligibility criteria](/mem/intune/protect/windows-10-feature-updates#prerequisites). +| Release status | Definition | Options | +| ----- | ----- | ----- | +| Scheduled | Release is scheduled and not all phases created its Windows feature update policies |
              • Releases with the **Scheduled status** can't be canceled but can have its deployment cadence edited as not all phases created its Windows feature update policies.
              • Autopatch groups and its deployment rings that belong to a **Scheduled** release can't be assigned to another release.
              | +| Active | All phases in the release are active. All phases reached their first deployment date, which created the Windows feature update policies. |
              • Release can be paused but can't be edited or canceled since the Windows feature update policy was already created for its phases.
              • Autopatch groups and their deployment rings can be assigned to another release.
              | +| Inactive | All the Autopatch groups within the release are assigned to a new release. As a result, the Windows feature update policies were unassigned from all phases from within the release. |
              • Release can be viewed as a historical record.
              • Releases can't be deleted, edited, or canceled.
              | +| Paused | All phases in the release are paused. The release remains paused until you resume it. |
              • Releases with the Paused status can't be edited or canceled since the Windows feature update policy was already created for its phases.
              • Release can be resumed.
              | +| Canceled | All phases in the release are canceled. |
              • Releases with the Canceled status can't be edited or canceled since the Windows feature update policy wasn't created for its phases.
              • Canceled release can't be deleted.
              | + +#### Phase statuses + +A phase is made of one or more [Autopatch group deployment rings](../deploy/windows-autopatch-groups-overview.md#autopatch-group-deployment-rings). Each phase reports its status to its release. > [!IMPORTANT] -> Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Windows Update for Business service and Windows Autopatch don't offer Windows feature updates for devices that are part of the LTSC. You must either use [LTSC media](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise) or the [Configuration Manager operating system deployment capabilities to perform an in-place upgrade](/mem/configmgr/osd/deploy-use/upgrade-windows-to-the-latest-version) for Windows devices that are part of the LTSC. +> The determining factor that makes a phase status transition from **Scheduled** to **Active** is when the service automatically creates the Windows feature update policy for each Autopatch group deployment ring. Additionally, the phase status transition from **Active** to **Inactive** occurs when Windows feature update policies are unassigned from the Autopatch groups that belong to a phase. This can happen when an Autopatch group and its deployment rings are re-used as part of a new release. -## Key benefits - -- Windows Autopatch makes it easier and less expensive for you to keep your Windows devices up to date. You can focus on running your core businesses while Windows Autopatch runs update management on your behalf. -- You're in control of telling Windows Autopatch when your organization is ready to move to the next Windows OS version. - - Combined with custom releases, Autopatch Groups gives your organization great control and flexibility to help you plan your gradual rollout in a way that works for your organization. -- Simplified end-user experience with rich controls for gradual rollouts, deployment cadence and speed. -- No need to manually modify the default Windows feature update policies (default release) to be on the Windows OS version your organization is currently ready for. -- Allows for scenarios where you can deploy a single release across several Autopatch groups and its deployment rings. - -## Key concepts - -- A release is made of one or more deployment phases and contains the required OS version to be gradually rolled out throughout its deployment phases. -- A phase (deployment phase) is made of one or more Autopatch group deployment rings. A phase: - - Works as an additional layer of deployment cadence settings that can be defined by IT admins (only for Windows feature updates) on top of Autopatch group deployment rings (Windows update rings policies). - - Deploys Windows feature updates across one or more Autopatch groups. -- There are three types of releases: - - Default - - Global - - Custom - -### Default release - -Windows Autopatch's default Windows feature update release is a service-driven release that enforces the minimum Windows OS version currently serviced by the Windows servicing channels for the deployment rings in the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group). - -> [!TIP] -> Windows Autopatch allows you to [create custom Windows feature update releases](../operate/windows-autopatch-groups-manage-windows-feature-update-release.md#create-a-custom-release). - -When devices are registered by manually adding them to the Windows Autopatch Device Registration Microsoft Entra ID assigned group, devices are assigned to deployment rings as part of the default Autopatch group. Each deployment ring has its own Windows feature update policy assigned to them. This is intended to minimize unexpected Windows OS upgrades once new devices register with the service. - -The policies: - -- Contain the minimum Windows 10 version currently serviced by the [Windows servicing channels](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2). The current minimum Windows OS version is **Windows 10 21H2**. -- Set a bare minimum Windows OS version required by the service once devices are registered with the service. - -If the device is registered with Windows Autopatch, and the device is: - -- Below the service's currently targeted Windows feature update, that device will be automatically upgraded to the service's target version when the device meets the [device eligibility criteria](#device-eligibility-criteria). -- On, or above the currently targeted Windows feature update version, there won't be any Windows OS upgrades available to that device. - -#### Policy configuration for the default release - -If your tenant is enrolled with Windows Autopatch, you can see the following default policies created by the service in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431): - -| Policy name | Phase mapping | Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date | -| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | -| Windows Autopatch - DSS Policy [Test] | Phase 1 | Windows 10 21H2 | Make update available as soon as possible | May 9, 2023 | N/A | N/A | June 11, 2024 | -| Windows Autopatch - DSS Policy [First] | Phase 2 | Windows 10 21H2 | Make update available as soon as possible | May 16, 2023 | N/A | N/A | June 11, 2024 | -| Windows Autopatch - DSS Policy [Fast] | Phase 3 | Windows 10 21H2 | Make update available as soon as possible | May 23, 2023 | N/A | N/A | June 11, 2024 | -| Windows Autopatch - DSS Policy [Broad] | Phase 4 | Windows 10 21H2 | Make update available as soon as possible | May 30, 2023 | N/A | N/A | June 11, 2024 | - -> [!NOTE] -> Gradual rollout settings aren't configured in the default Windows Update feature policy. If the date of the final group availability is changed to a past date, all remaining devices are offered the update as soon as possible. For more information, see [rollout options for Windows Updates in Microsoft Intune](/mem/intune/protect/windows-update-rollout-options#make-updates-available-gradually). - -### Global release - -Windows Autopatch's global Windows feature update release is a service-driven release. Like the [default release](#default-release), the Global release enforces the [minimum Windows OS version currently serviced by the Windows servicing channels](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2). - -There are two scenarios that the Global release is used: - -| Scenario | Description | +| Phase status | Definition | | ----- | ----- | -| Scenario #1 | You assign Microsoft Entra groups to be used with the deployment ring (Last) or you add additional deployment rings when you customize the [Default Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group).

              A global Windows feature update policy is automatically assigned behind the scenes to the newly added deployment rings or when you assigned Microsoft Entra groups to the deployment ring (Last) in the Default Autopatch group.

              | -| Scenario #2 | You create new [Custom Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md#create-a-custom-autopatch-group).

              The global Windows feature policy is automatically assigned behind the scenes to all deployment rings as part of the Custom Autopatch groups you create.

              | +| Scheduled | The phase is scheduled but didn't reach its first deployment date yet. The Windows feature update policy wasn't created for the respective phase yet. | +| Active | The first deployment date reached. The Windows feature update policy was created for the respective phase. | +| Inactive | All Autopatch groups within the phase are reassigned to a new release. All Windows feature update policies were unassigned from the Autopatch groups. | +| Paused | Phase is paused. You must resume the phase. | +| Canceled | Phase is canceled. All Autopatch groups within the phase can be used with a new release. A phase that is canceled can't be deleted. | + +#### Phase policy configuration + +For more information about Windows feature update policies that are created for phases within a release, see [Windows feature update policies](../manage/windows-autopatch-windows-feature-update-policies.md). + +## Create a custom release + +**To create a custom release:** + +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +1. Select **Devices** from the left navigation menu. +1. Under the **Windows Autopatch** section, select **Release management**. +1. In the **Release management** blade, select **Release schedule**, then **Windows feature updates**. +1. In the **Windows feature updates** blade, select **New release**. +1. In the **Basics** page: + 1. Enter a **Name** for the custom release. + 2. Select the **Version** to deploy. + 3. Enter a **Description** for the custom release. + 4. Select **Next**. +1. In the **Autopatch groups** page, choose one or more existing Autopatch groups you want to include in the custom release, then select Next. +1. You can't choose Autopatch groups that are already part of an existing custom release. Select **Autopatch groups assigned to other releases** to review existing assignments. +1. In the Release phases page, review the number of autopopulated phases. You can Edit, Delete, and Add a phase based on your needs. Once you're ready, select **Next**. **Before you proceed to the next step**, all deployment rings must be assigned to a phase, and all phases must have deployment rings assigned. +1. In the **Release schedule** page, choose **First deployment date**, and the number of **Gradual rollout groups**, then select **Next**. **You can only select the next day**, not the current day, as the first deployment date. The service creates feature update policy for Windows 10 and later twice a day at 4:00AM and 4:00PM (UTC) and can't guarantee that the release starts on the current day given the UTC variance across the globe. + 1. The **Goal completion date** only applies to the [Deadline-driven deployment cadence type](../operate/windows-autopatch-groups-windows-update.md#deadline-driven). The Deadline-drive deployment cadence type can be specified when you configure the Windows Updates settings during the Autopatch group creation/editing flow. + 2. Additionally, the formula for the goal completion date is ` + ( - 1) * Days in between groups (7) + Deadline for feature updates (5 days) + Grace Period (2 days)`. +1. In the **Review + create** page, review all settings. Once you're ready, select **Create**. > [!NOTE] -> Global releases don't show up in the Windows feature updates release management blade. +> Custom releases can't be deleted from the Windows feature updates release management blade. The custom release record serves as a historical record for auditing purposes when needed. -#### Policy configuration values - -See the following table on how Windows Autopatch configures the values for its global Windows feature update policy. If your tenant is enrolled with Windows Autopatch, you can see the following default policies created by the service in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431): - -| Policy name | Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date | -| ----- | ----- | ----- | ----- | ----- | ----- | ----- | -| Windows Autopatch - Global DSS Policy [Test] | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024 | +## Edit a custom release > [!NOTE] -> Gradual rollout settings aren't configured in the default Windows Update feature policy. If the date of the final group availability is changed to be a past date, all remaining devices are offered the update as soon as possible. For more information, see [rollout options for Windows Updates in Microsoft Intune](/mem/intune/protect/windows-update-rollout-options#make-updates-available-gradually). +> Only custom releases that have the **Scheduled** status can be edited. A release phase can only be edited prior to reaching its first deployment date. Additionally, you can only edit the deployment dates when editing a release. -### Differences between the default and global Windows feature update policies +**To edit a custom release:** + +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +1. Select **Devices** from the left navigation menu. +1. Under the **Windows Autopatch** section, select **Release management**. +1. In the **Release schedule** tab, select **Windows feature updates**. +1. In the **Windows feature updates** blade, select the **horizontal ellipses (…)** > Edit to customize your gradual rollout of your feature updates release, then select **Save**. + 1. Only the release schedule can be customized when using the edit function. You can't add or remove Autopatch groups or modify the phase order when editing a release. +1. Select **Review + Create**. +1. Select **Apply** to save your changes. + +## Cancel a release > [!IMPORTANT] -> Once you create a custom Windows feature update release, both the global and the default Windows feature update policies are unassigned from Autopatch group's deployment rings behind the scenes. +> You can only cancel a release under the **Scheduled** status. You cannot cancel a release under the **Active**, **Inactive, or **Paused** statuses. -The differences in between the global and the default Windows feature update policy values are: +**To cancel a release:** -| Default Windows feature update policy | Global Windows feature update policy | -| ----- | ----- | -|
              • Set by default with the Default Autopatch group and assigned to Test, Ring1, Ring2, Ring3. The default policy isn't automatically assigned to the Last ring in the Default Autopatch group.
              • The Windows Autopatch service keeps its minimum Windows OS version updated following the recommendation of minimum Windows OS version [currently serviced by the Windows servicing channels](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2).
              |
              • Set by default and assigned to all new deployment rings added as part of the Default Autopatch group customization.
              • Set by default and assigned to all deployment rings created as part of Custom Autopatch groups.
              | +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +1. Select **Devices** from the left navigation menu. +1. Under the **Windows Autopatch** section, select **Release management**. +1. In the **Release schedule** tab, select **Windows feature updates**. +1. In the **Windows feature updates** blade, select the **horizontal ellipses (…)** > **Cancel** to cancel your feature updates release. +1. Select a reason for cancellation from the dropdown menu. +1. Optional. Enter details about why you're pausing or resuming the selected update. +1. Select **Cancel deployment** to save your changes. -### Custom release - -A custom release is the release that you create to tell Windows Autopatch how you want the service to manage Windows OS upgrades on your behalf. - -Custom releases gives you flexibility to do Windows OS upgrades on your pace, but still relying on Windows Autopatch to give you insights of how your OS upgrades are going and additional deployment controls through the Windows feature updates release management experience. - -When a custom release is created and assigned to Autopatch groups, either the default or global releases are unassigned to avoid feature update policy for Windows 10 and later conflicts. - -For more information on how to create a custom release, see [Manage Windows feature update release](../operate/windows-autopatch-groups-manage-windows-feature-update-release.md#create-a-custom-release). - -### About Windows Update rings policies - -Feature update policies work with Windows Update rings policies. Windows Update rings policies are created for each deployment ring for the [Default or a Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md#key-concepts) based on the deployment settings you define. The policy name convention is `Windows Autopatch Update Policy - - `. - -The following table details the default Windows Update rings policy values that affect either the default or custom Windows feature updates releases: - -| Policy name | Microsoft Entra group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline | -| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | -| Windows Autopatch Update Policy - default - Test | Windows Autopatch - Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes | -| Windows Autopatch Update Policy - default - Ring1 | Windows Autopatch - Ring1 | 1 | 0 | 30 | 2 | 5 |2 | Yes | -| Windows Autopatch Update Policy - default - Ring2 | Windows Autopatch - Ring2 | 6 | 0 | 30 | 2 | 5 | 2 | Yes | -| Windows Autopatch Update Policy - default - Ring3 | Windows Autopatch - Ring3 | 9 | 0 | 30 | 5 | 5 | 2 | Yes | -| Windows Autopatch Update Policy - default - Last | Windows Autopatch - Last | 11 | 0 | 30 | 3 | 5 | 2 | Yes | +## Pause and resume a release > [!IMPORTANT] -> When you create a custom Windows feature update release, new Windows feature update policies are:
              • Created corresponding to the settings you defined while creating the release.
              • Assigned to the Autopatch group's deployment rings you select to be included in the release.
              +> **Pausing or resuming an update can take up to eight hours to be applied to devices**. Windows Autopatch uses Microsoft Intune as its device management solution and that's the average frequency Windows devices take to communicate back to Microsoft Intune with new instructions to pause, resume or rollback updates. For more information, see [how long does it take for devices to get a policy, profile, or app after they are assigned from Microsoft Intune](/mem/intune/configuration/device-profile-troubleshoot#how-long-does-it-take-for-devices-to-get-a-policy-profile-or-app-after-they-are-assigned). -## Common ways to manage releases +**To pause and resume a release:** -### Use case #1 +> [!IMPORTANT] +> **You can only pause an Autopatch group if you have Windows Enterprise E3+ or F3 licenses (included in Microsoft 365 F3, E3, or E5) licenses and have [activated Windows Autopatch features](../overview/windows-autopatch-overview.md#windows-enterprise-e3-and-f3-licenses).**

              [Feature activation](../prepare/windows-autopatch-feature-activation.md) is optional and at no additional cost to you if you have Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) licenses.

              For more information, see [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements). If you choose not to go through feature activation, you can still use the Windows Autopatch service for the features included in [Business premium and A3+ licenses](../overview/windows-autopatch-overview.md#business-premium-and-a3-licenses).

              -| Scenario | Solution | -| ----- | ----- | -| You're working as the IT admin at Contoso Ltd., and you need to gradually rollout of Windows 11's latest version to several business units across your organization. | Custom Windows feature update releases deliver OS upgrades horizontally, through phases, to one or more Autopatch groups.
              Phases:
              • Set your organization's deployment cadence.
              • Work like deployment rings on top of Autopatch group's deployment rings. Phases group one or more deployment rings across one or more Autopatch groups.

              See the following visual for a representation of Phases with custom releases. | +> [!NOTE] +> If you pause an update, the specified release has the **Paused** status. The Windows Autopatch service can't overwrite IT admin's pause. You must select **Resume** to resume the update. [The **Paused by Service Pause** status **only** applies to Windows quality updates](../manage/windows-autopatch-windows-quality-update-overview.md#pause-and-resume-a-release). Windows Autopatch doesn't pause Windows feature updates on your behalf. -:::image type="content" source="../media/autopatch-groups-manage-feature-release-case-1.png" alt-text="Manage Windows feature update release use case one" lightbox="../media/autopatch-groups-manage-feature-release-case-1.png"::: +1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +1. Select **Devices** from the left navigation menu. +1. Under the **Windows Autopatch** section, select **Release management**. +1. In the **Release schedule** tab, select **Windows feature updates**. +1. In the **Windows feature updates** blade, select the **horizontal ellipses (…)** > **Pause** or **Resume** to pause or resume your feature updates release. +1. Select a reason from the dropdown menu. +1. Optional. Enter details about why you're pausing or resuming the selected update. +1. If you're resuming an update, you can select one or more deployment rings. +1. Select **Pause deployment** or **Resume deployment** to save your changes. -### Use case #2 +## Roll back a release -| Scenario | Solution | -| ----- | ----- | -| You're working as the IT admin at Contoso Ltd. and your organization isn't ready to upgrade its devices to either Windows 11 or the newest Windows 10 OS versions due to conflicting project priorities within your organization.

              However, you want to keep Windows Autopatch managed devices supported and receiving monthly updates that are critical to security and the health of the Windows ecosystem.

              | Default Windows feature update releases deliver the minimum Windows OS upgrade vertically to each Windows Autopatch group (either [Default](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) or [Custom](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups)). The Default Windows Autopatch group is pre-configured with the [default Windows feature update release](#default-release) and no additional configuration is required from IT admins as Autopatch manages the default release on your behalf.

              If you decide to edit the default Windows Autopatch group to add additional deployment rings, these rings receive a [global Windows feature update policy](#global-release) set to offer the minimum Windows OS version [currently serviced](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2) to devices. Every custom Autopatch group you create gets a [global Windows feature update policy](#global-release) that enforces the minimum Windows OS version [currently serviced](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2).

              See the following visual for a representation of default releases.

              | - -:::image type="content" source="../media/autopatch-groups-manage-feature-release-case-2.png" alt-text="Manage Windows feature update release use case two" lightbox="../media/autopatch-groups-manage-feature-release-case-2.png"::: +Windows Autopatch doesn't support the rollback of Windows feature updates through its end-user experience flows. diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-policies.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-policies.md new file mode 100644 index 0000000000..80f7b24b96 --- /dev/null +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-policies.md @@ -0,0 +1,111 @@ +--- +title: Windows feature updates policies +description: This article describes Windows feature update policies used in Windows Autopatch +ms.date: 09/16/2024 +ms.service: windows-client +ms.subservice: autopatch +ms.topic: overview +ms.localizationpriority: medium +author: tiaraquan +ms.author: tiaraquan +manager: aaroncz +ms.reviewer: andredm7 +ms.collection: + - highpri + - tier1 +--- + +# Windows feature update policies + +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + +## Windows feature updates for Windows 10 and later + +These policies control the minimum target version of Windows that a device is meant to accept. Throughout the rest of the article, these policies are referred to as DSS policies. There are four of these policies in your tenant with the following naming convention: + +**`Modern Workplace DSS Policy [ring name]`** + +### Windows feature update deployment settings + +| Setting name | Test | First | Fast | Broad | +| ----- | ----- | ----- | ----- | ----- | +| Name | Current targeted version of Windows | Current targeted version of Windows | Current targeted version of Windows | Current targeted version of Windows | +| Rollout options | Immediate start | Immediate start | Immediate start | Immediate start | + +### Windows feature update policy assignments + +| Setting name | Test | First | Fast | Broad | +| ----- | ----- | ----- | ----- | ----- | +| Included groups | Modern Workplace Devices-Windows Autopatch-Test | Modern Workplace Devices-Windows Autopatch-First | Modern Workplace Devices-Windows Autopatch-Fast | Modern Workplace Devices-Windows Autopatch-Broad | + +## Default release policy configuration + +You can see the following default policies created by the service in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431): + +| Policy name | Phase mapping | Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date | +| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | +| Windows Autopatch - DSS Policy [Test] | Phase 1 | Windows 10 21H2 | Make update available as soon as possible | May 9, 2023 | N/A | N/A | June 11, 2024 | +| Windows Autopatch - DSS Policy [First] | Phase 2 | Windows 10 21H2 | Make update available as soon as possible | May 16, 2023 | N/A | N/A | June 11, 2024 | +| Windows Autopatch - DSS Policy [Fast] | Phase 3 | Windows 10 21H2 | Make update available as soon as possible | May 23, 2023 | N/A | N/A | June 11, 2024 | +| Windows Autopatch - DSS Policy [Broad] | Phase 4 | Windows 10 21H2 | Make update available as soon as possible | May 30, 2023 | N/A | N/A | June 11, 2024 | + +> [!NOTE] +> Gradual rollout settings aren't configured in the default Windows Update feature policy. If the date of the final group availability is changed to a past date, all remaining devices are offered the update as soon as possible. For more information, see [rollout options for Windows Updates in Microsoft Intune](/mem/intune/protect/windows-update-rollout-options#make-updates-available-gradually). + +## Global release policy configuration + +Windows Autopatch configures the values for its global Windows feature update policy. See the following default policies created by the service in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431): + +| Policy name | Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date | +| ----- | ----- | ----- | ----- | ----- | ----- | ----- | +| Windows Autopatch - Global DSS Policy [Test] | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024 | + +> [!NOTE] +> Gradual rollout settings aren't configured in the default Windows Update feature policy. If the date of the final group availability is changed to be a past date, all remaining devices are offered the update as soon as possible. For more information, see [rollout options for Windows Updates in Microsoft Intune](/mem/intune/protect/windows-update-rollout-options#make-updates-available-gradually). + +### Difference between the default and global update policies + +> [!IMPORTANT] +> Once you create a custom Windows feature update release, both the global and the default Windows feature update policies are unassigned from Autopatch group's deployment rings behind the scenes. + +The differences in between the global and the default Windows feature update policy values are: + +| Default Windows feature update policy | Global Windows feature update policy | +| ----- | ----- | +|
              • Set by default with an Autopatch group and assigned to Test, Ring1, Ring2, Ring3. The default policy isn't automatically assigned to the Last ring in an Autopatch group.
              • The Windows Autopatch service keeps its minimum Windows OS version updated following the recommendation of minimum Windows OS version [currently serviced by the Windows servicing channels](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2).
              |
              • Set by default and assigned to all new deployment rings added as part of an Autopatch group customization
              • Set by default and assigned to all deployment rings created as part of Autopatch groups.
              | + +## Windows Update ring policies + +Feature update policies work with Windows Update rings policies. Windows Update rings policies are created for each deployment ring for the [Autopatch group](../deploy/windows-autopatch-groups-overview.md#key-concepts) based on the deployment settings you define. The policy name convention is **`Windows Autopatch Update Policy - - `**. + +The following table details the default Windows Update rings policy values that affect either the default or custom Windows feature updates releases: + +| Policy name | Microsoft Entra group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline | +| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | +| Windows Autopatch Update Policy - Default - Test | Windows Autopatch - Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes | +| Windows Autopatch Update Policy - Default - Ring1 | Windows Autopatch - Ring1 | 1 | 0 | 30 | 2 | 5 |2 | Yes | +| Windows Autopatch Update Policy - Default - Ring2 | Windows Autopatch - Ring2 | 6 | 0 | 30 | 2 | 5 | 2 | Yes | +| Windows Autopatch Update Policy - Default - Ring3 | Windows Autopatch - Ring3 | 9 | 0 | 30 | 5 | 5 | 2 | Yes | +| Windows Autopatch Update Policy - Default - Last | Windows Autopatch - Last | 11 | 0 | 30 | 3 | 5 | 2 | Yes | + +> [!IMPORTANT] +> When you create a custom Windows feature update release, new Windows feature update policies are:
              • Created corresponding to the settings you defined while creating the release.
              • Assigned to the Autopatch group's deployment rings you select to be included in the release.
              + +## Phase policy configuration + +Windows Autopatch creates one Windows feature update policy per phase using the following naming convention: + +**`Windows Autopatch - DSS policy - - Phase `** + +These policies can be viewed in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). + +The following table is an example of the Windows feature update policies that were created for phases within a release: + +| Policy name | Feature update version | Rollout options | First deployment date| Final deployment date availability | Day between groups | Support end date | +| ----- | ----- | ----- | ----- | ----- | ----- | ----- | +| Windows Autopatch - DSS Policy - My feature update release - Phase 1 | Windows 10 21H2 | Make update available as soon as possible | April 24, 2023 | April 24, 2023 | N/A | June 11, 2024 | +| Windows Autopatch - DSS Policy - My feature update release - Phase 2 | Windows 10 21H2 | Make update available as soon as possible | June 26, 2023 | July 17, 2023 | 7 | June 11, 2024 | +| Windows Autopatch - DSS Policy - My feature update release - Phase 3 | Windows 10 21H2 | Make update available as soon as possible | July 24, 2023 | August 14, 2023 | 7 | June 11, 2024 | +| Windows Autopatch - DSS Policy - My feature update release - Phase 4 | Windows 10 21H2 | Make update available as soon as possible | August 28, 2023 | September 10, 2023 | 7 | June 11, 2024 | +| Windows Autopatch - DSS Policy - My feature update release - Phase 5 | Windows 10 21H2 | Make update available as soon as possible | September 25, 2023 | October 16, 2023 | 7 | June 11, 2024 | + diff --git a/windows/deployment/update/deployment-service-feature-updates.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-programmatic-controls.md similarity index 79% rename from windows/deployment/update/deployment-service-feature-updates.md rename to windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-programmatic-controls.md index 99d6c26f7c..db264d3c4f 100644 --- a/windows/deployment/update/deployment-service-feature-updates.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-programmatic-controls.md @@ -1,12 +1,12 @@ --- -title: Deploy feature updates -titleSuffix: Windows Update for Business deployment service -description: Use Windows Update for Business deployment service to deploy feature updates to devices in your organization. +title: Programmatic controls for feature updates +titleSuffix: Windows Autopatch +description: Use programmatic controls to deploy feature updates to devices in your organization. ms.service: windows-client -ms.subservice: itpro-updates -ms.topic: conceptual -ms.author: mstewart -author: mestew +ms.subservice: autopatch +ms.topic: how-to +ms.author: tiaraquan +author: tiaraquan manager: aaroncz ms.collection: - tier1 @@ -14,17 +14,21 @@ ms.localizationpriority: medium appliesto: - ✅ Windows 11 - ✅ Windows 10 -ms.date: 08/29/2023 +ms.date: 09/16/2024 --- -# Deploy feature updates with Windows Update for Business deployment service +# Programmatic controls for Windows feature updates + +[!INCLUDE [windows-autopatch-applies-to-all-licenses](../includes/windows-autopatch-applies-to-all-licenses.md)] + -The Windows Update for Business deployment service is used to approve and schedule software updates. The deployment service exposes its capabilities through the [Microsoft Graph API](/graph/use-the-api). You can call the API directly, through a [Graph SDK](/graph/sdks/sdks-overview), or integrate them with a management tool such as [Microsoft Intune](/mem/intune). +Windows Autopatch programmatic controls are used to approve and schedule software updates through [Microsoft Graph API](/graph/use-the-api). You can call the API directly, through a [Graph SDK](/graph/sdks/sdks-overview), or integrate them with a management tool such as [Microsoft Intune](/mem/intune). This article uses [Graph Explorer](/graph/graph-explorer/graph-explorer-overview) to walk through the entire process of deploying a feature update to clients. In this article, you will: In this article, you will: > [!div class="checklist"] +> > * [Open Graph Explorer](#open-graph-explorer) > * [Run queries to identify devices](#run-queries-to-identify-devices) > * [Enroll devices](#enroll-devices) @@ -35,36 +39,35 @@ In this article, you will: > * [Delete a deployment](#delete-a-deployment) > * [Unenroll devices](#unenroll-devices) - ## Prerequisites -All of the [prerequisites for the Windows Update for Business deployment service](deployment-service-prerequisites.md) must be met. +All of the [Windows Autopatch prerequisites](../prepare/windows-autopatch-prerequisites.md) must be met. ### Permissions -[!INCLUDE [Windows Update for Business deployment service permissions using Graph Explorer](./includes/wufb-deployment-graph-explorer-permissions.md)] +[!INCLUDE [Windows Autopatch permissions using Graph Explorer](../includes/windows-autopatch-graph-explorer-permissions.md)] ## Open Graph Explorer -[!INCLUDE [Graph Explorer sign in](./includes/wufb-deployment-graph-explorer.md)] +[!INCLUDE [Graph Explorer sign in](../includes/windows-autopatch-graph-explorer.md)] ## Run queries to identify devices -[!INCLUDE [Graph Explorer device queries](./includes/wufb-deployment-find-device-name-graph-explorer.md)] +[!INCLUDE [Graph Explorer device queries](../includes/windows-autopatch-find-device-name-graph-explorer.md)] ## Enroll devices -When you enroll devices into feature update management, the deployment service becomes the authority for feature updates coming from Windows Update. -As long as a device remains enrolled in feature update management through the deployment service, the device doesn't receive any other feature updates from Windows Update unless explicitly deployed using the deployment service. A device is offered the specified feature update if it hasn't already received the update. For example, if you deploy Windows 11 feature update version 22H2 to a device that's enrolled into feature update management and is currently on an older version of Windows 11, the device updates to version 22H2. If the device is already running version 22H2 or a later version, it stays on its current version. +When you enroll devices into feature update management, Windows Autopatch becomes the authority for feature updates coming from Windows Update. +As long as a device remains enrolled in feature update management through Windows Autopatch, the device doesn't receive any other feature updates from Windows Update unless explicitly deployed using Windows Autopatch. A device is offered the specified feature update if it hasn't already received the update. For example, if you deploy Windows 11 feature update version 22H2 to a device that's enrolled into feature update management and is currently on an older version of Windows 11, the device updates to version 22H2. If the device is already running version 22H2 or a later version, it stays on its current version. > [!TIP] -> Windows Update for Business reports has a [workbook](wufb-reports-workbook.md#feature-updates-tab) that displays the current operating system version for devices. In the workbook, go to the **Feature updates** tab and in the **In Service feature update** tile, select the **View details** link to open the details flyout. The OS version and Microsoft Entra ID of devices can easily be exported into a .csv file or opened in [Azure Monitor Logs](/azure/azure-monitor/logs/log-query-overview) to help when creating a deployment audience. +> Windows Update for Business reports has a [workbook](/windows/deployment/update/wufb-reports-workbook#feature-updates-tab) that displays the current operating system version for devices. In the workbook, go to the **Feature updates** tab and in the **In Service feature update** tile, select the **View details** link to open the details flyout. The OS version and Microsoft Entra ID of devices can easily be exported into a .csv file or opened in [Azure Monitor Logs](/azure/azure-monitor/logs/log-query-overview) to help when creating a deployment audience. -[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-enroll-device-graph-explorer.md)] +[!INCLUDE [Graph Explorer enroll devices](../includes/windows-autopatch-enroll-device-graph-explorer.md)] ## List catalog entries for feature updates @@ -99,7 +102,7 @@ When creating a deployment for a feature update, there are multiple options avai - Deployment [start date](/graph/api/resources/windowsupdates-schedulesettings) of February 14, 2023 at 5 AM UTC - [Gradual rollout](/graph/api/resources/windowsupdates-gradualrolloutsettings) at a rate of 100 devices every three days -- [Monitoring rule](/graph/api/resources/windowsupdates-monitoringrule) that will pause the deployment if five devices rollback the feature update +- [Monitoring rule](/graph/api/resources/windowsupdates-monitoringrule) that pauses the deployment if five devices rollback the feature update - Default [safeguard hold](/graph/api/resources/windowsupdates-safeguardprofile) behavior of applying all applicable safeguards to devices in a deployment - When safeguard holds aren't explicitly defined, the default safeguard hold behavior is applied automatically @@ -138,7 +141,8 @@ content-type: application/json } ``` -The response body will contain: +The response body contains: + - The new **Deployment ID**, `de910e12-3456-7890-abcd-ef1234567890` in the example - The new **Audience ID**, `d39ad1ce-0123-4567-89ab-cdef01234567` in the example - Any settings defined in the deployment request body @@ -228,7 +232,7 @@ GET https://graph.microsoft.com/beta/admin/windows/updates/deployments/de910e12- ## Add members to the deployment audience -The **Audience ID**, `d39ad1ce-0123-4567-89ab-cdef01234567`, was created when the deployment was created. The **Audience ID** is used to add members to the deployment audience. After the deployment audience is updated, Windows Update starts offering the update to the devices according to the deployment settings. As long as the deployment exists and the device is in the audience, the update will be offered. +The **Audience ID**, `d39ad1ce-0123-4567-89ab-cdef01234567`, was created when the deployment was created. The **Audience ID** is used to add members to the deployment audience. After the deployment audience is updated, Windows Update starts offering the update to the devices according to the deployment settings. As long as the deployment exists and the device is in the audience, the update is offered. The following example adds three devices to the deployment audience using the **Microsoft Entra ID** for each device: @@ -282,7 +286,7 @@ content-type: application/json ## Delete a deployment -To remove the deployment completely, DELETE the deployment. Deleting the deployment will prevent the content from being offered to devices if they haven't already received it. To resume offering the content, a new approval will need to be created. +To remove the deployment completely, DELETE the deployment. Deleting the deployment prevents the content from being offered to devices if they haven't already received it. To resume offering the content, a new approval needs to be created. The following example deletes the deployment with a **Deployment ID** of `de910e12-3456-7890-abcd-ef1234567890`: @@ -294,4 +298,4 @@ DELETE https://graph.microsoft.com/beta/admin/windows/updates/deployments/de910e ## Unenroll devices -[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-graph-unenroll.md)] +[!INCLUDE [Graph Explorer unenroll devices](../includes/windows-autopatch-graph-unenroll.md)] diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-communications.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-communications.md index a606ae1c4c..02ddb0ce1e 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-communications.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-communications.md @@ -1,7 +1,7 @@ --- title: Windows quality update communications description: This article explains Windows quality update communications -ms.date: 07/08/2024 +ms.date: 09/16/2024 ms.service: windows-client ms.subservice: autopatch ms.topic: concept-article @@ -17,6 +17,8 @@ ms.collection: # Windows quality update communications +[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)] + There are three categories of communication that are sent out during a Windows quality and feature update: - [Standard communications](#standard-communications) @@ -35,7 +37,7 @@ Communications are posted to, as appropriate for the type of communication, to t | Communication | Location | Timing | Description | | ----- | ----- | ----- | ----- | -| Release schedule |