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

Windows Autopatch groups

Browse Source
This commit is contained in:
tiaraquan
2023-04-27 11:34:06 -07:00
parent 147c633db4
commit 3bda17d4e8
31 changed files with 2284 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files

147
windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md
View File

@ -1,7 +1,7 @@
---
title: Device registration overview
description: This article provides an overview on how to register devices in Autopatch
ms.date: 10/5/2022
ms.date: 05/01/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: conceptual
@ -18,19 +18,21 @@ Windows Autopatch must [register your existing devices](windows-autopatch-regist
The Windows Autopatch device registration process is transparent for end-users because it doesn’t require devices to be reset.
The overall device registration process is:
The overall device registration process is as follows:
:::image type="content" source="../media/windows-autopatch-device-registration-overview.png" alt-text="Overview of the device registration process" lightbox="../media/windows-autopatch-device-registration-overview.png":::
1. IT admin reviews [Windows Autopatch device registration pre-requisites](windows-autopatch-register-devices.md#prerequisites-for-device-registration) prior to register devices with Windows Autopatch.
2. IT admin identifies devices to be managed by Windows Autopatch and adds them into the **Windows Autopatch Device Registration** Azure Active Directory (AD) group.
1. Windows Autopatch then:
1. IT admin reviews [Windows Autopatch device registration prerequisites](windows-autopatch-register-devices.md#prerequisites-for-device-registration) prior to register devices with Windows Autopatch.
2. IT admin identifies devices to be managed by Windows Autopatch through either adding:
1. The devices into the Windows Autopatch Device Registration (classic) Azure Active Directory (AD) group.
2. Device-based Azure AD groups as part of the [Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md) or the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md).
3. Windows Autopatch then:
1. Performs device readiness prior registration (prerequisite checks).
1. Calculates the deployment ring distribution.
1. Assigns devices to one of the deployment rings based on the previous calculation.
1. Assigns devices to other Azure AD groups required for management.
1. Marks devices as active for management so it can apply its update deployment policies.
1. IT admin then monitors the device registration trends and the update deployment reports.
2. Calculates the deployment ring distribution.
3. Assigns devices to one of the deployment rings based on the previous calculation.
4. Assigns devices to other Azure AD groups required for management.
5. Marks devices as active for management so it can apply its update deployment policies.
4. IT admin then monitors the device registration trends and the update deployment reports.
For more information about the device registration workflow, see the [Detailed device registration workflow diagram](#detailed-device-registration-workflow-diagram) section for more technical details behind the Windows Autopatch device registration process.
@ -43,14 +45,14 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto
| Step | Description |
| ----- | ----- |
| **Step 1: Identify devices** | IT admin identifies devices to be managed by the Windows Autopatch service. |
| **Step 2: Add devices** | IT admin adds devices through direct membership or nests other Azure AD assigned or dynamic groups into the **Windows Autopatch Device Registration** Azure AD assigned group. |
| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function hourly discovers devices previously added by the IT admin into the **Windows Autopatch Device Registration** Azure AD assigned group in **step #2**. The Azure AD device ID is used by Windows Autopatch to query device attributes in both Microsoft Intune and Azure AD when registering devices into its service.<ol><li>Once devices are discovered from the Azure AD 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 Azure AD in this step:</li><ol><li>**AzureADDeviceID**</li><li>**OperatingSystem**</li><li>**DisplayName (Device name)**</li><li>**AccountEnabled**</li><li>**RegistrationDateTime**</li><li>**ApproximateLastSignInDateTime**</li></ol><li>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 prior to registration.</li></ol> |
| **Step 2: Add devices** | IT admin adds devices through Direct membership or nests other Azure AD assigned or dynamic groups into the **Windows Autopatch Device Registration** Azure AD assigned group when using the:<ul><li> [Classic device registration method](../deploy/windows-autopatch-register-devices.md#classic-device-registration-method), or </li><li>Adding existing device-based Azure AD groups while [creating](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group)/[editing](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) Custom Autopatch groups, or [editing](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) the Default Autopatch group</li></ul> |
| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function discovers devices (hourly) that were previously added by the IT admin into the **Windows Autopatch Device Registration** Azure AD assigned group or from Azure AD groups used with Autopatch groups in **step #2**. The Azure AD device ID is used by Windows Autopatch to query device attributes in both Microsoft Intune and Azure AD when registering devices into its service.<ol><li>Once devices are discovered from the Azure AD 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 Azure AD in this step:</li><ol><li>**AzureADDeviceID**</li><li>**OperatingSystem**</li><li>**DisplayName (Device name)**</li><li>**AccountEnabled**</li><li>**RegistrationDateTime**</li><li>**ApproximateLastSignInDateTime**</li></ol><li>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 prior to registration.</li></ol> |
| **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:<ol><li>**Serial number, model, and manufacturer.**</li><ol><li>Checks if the serial number already exists in the Windows Autopatch’s managed device database.</li></ol><li>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.</li><ol><li>If **yes**, it means this device is enrolled into Intune.</li><li>If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol><li>**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 Azure AD device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not registered** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.</li><li>A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD 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).</li></ol><li>**If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.</li></ol><li>**If the device is a Windows device or not.**</li><ol><li>Windows Autopatch looks to see if the device is a Windows and corporate-owned device.</li><ol><li>**If yes**, it means this device can be registered with the service because it's a Windows corporate-owned device.</li><li>**If not**, it means the device is a non-Windows device, or it's a Windows device but it's a personal device.</li></ol></ol><li>**Windows Autopatch checks the Windows SKU family**. The SKU must be either:</li><ol><li>**Enterprise**</li><li>**Pro**</li><li>**Pro Workstation**</li></ol><li>**If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:</li><ol><li>**Only managed by Intune.**</li><ol><li>If the device is only managed by Intune, the device is marked as Passed all prerequisites.</li></ol><li>**Co-managed by both Configuration Manager and Intune.**</li><ol><li>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:</li><ol><li>**Windows Updates Policies**</li><li>**Device Configuration**</li><li>**Office Click to Run**</li></ol><li>If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not registered** tab.</li></ol></ol></ol>|
| **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:<ol><li>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%)**.</li><li>If the Windows Autopatch tenant’s existing managed device size is **>200**, the deployment ring assignment will be **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.</li></ol> |
| **Step 6: Assign devices to a deployment ring group** | Once the deployment ring calculation is done, Windows Autopatch assigns devices to one of the following deployment ring groups:<ol><li>**Modern Workplace Devices-Windows Autopatch-First**</li><ol><li>The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD 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.</li></ol><li>**Modern Workplace Devices-Windows Autopatch-Fast**</li><li>**Modern Workplace Devices-Windows Autopatch-Broad**</li></ol> |
| **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 Azure AD groups:<ol><li>**Modern Workplace Devices-Windows Autopatch-First**</li><ol><li>The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD 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.</li></ol><li>**Modern Workplace Devices-Windows Autopatch-Fast**</li><li>**Modern Workplace Devices-Windows Autopatch-Broad**</li>Then the second deployment ring set, the software updates-based deployment ring set represented by the following Azure AD groups:<ul><li>**Windows Autopatch - Ring1**<ul><li>The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD groups (**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.</li></ul><li>**Windows Autopatch - Ring2**</li>**Windows Autopatch - Ring3**</li></li></ol> |
| **Step 7: Assign devices to an Azure AD group** | Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply:<ol><li>**Modern Workplace Devices - All**</li><ol><li>This group has all devices managed by Windows Autopatch.</li></ol><li>**Modern Workplace Devices - Virtual Machine**</li><ol><li>This group has all **virtual devices** managed by Windows Autopatch.</li></ol> |
| **Step 8: Post-device registration** | In post-device registration, three actions occur:<ol><li>Windows Autopatch adds devices to its managed database.</li><li>Flags devices as **Active** in the **Ready** tab.</li><li>The Azure AD 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.</li><ol><li>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.</li></ol> |
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Ready** and **Not registered** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Ready** tab.</li><li>If **not**, the device shows up in the **Not registered** tab.</li></ol> |
| **Step 8: Post-device registration** | In post-device registration, three actions occur:<ol><li>Windows Autopatch adds devices to its managed database.</li><li>Flags devices as **Active** in the **Registered** tab.</li><li>The Azure AD 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.</li><ol><li>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.</li></ol> |
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Registered** and **Not registered** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Registered** tab.</li><li>If **not**, the device shows up in the **Not registered** tab.</li></ol> |
| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
## Detailed prerequisite check workflow diagram
@ -58,3 +60,118 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto
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":::
## Windows Autopatch deployment rings
During the tenant enrollment process, Windows Autopatch creates two different deployment ring sets:
- [Service-based deployment ring set](../deploy/windows-autopatch-groups-overview.md#service-based-deployment-rings)
- [Software update-based deployment ring set](../deploy/windows-autopatch-groups-overview.md#software-based-deployment-rings)
The following four Azure AD assigned groups are used to organize devices for the service-based deployment ring set:
| Service-based deployment ring | Description |
| ----- | ----- |
| Modern Workplace Devices-Windows Autopatch-Test | Deployment ring for testing service-based configuration, app deployments prior production rollout |
| Modern Workplace Devices-Windows Autopatch-First | First production deployment ring for early adopters. |
| Modern Workplace Devices-Windows Autopatch-Fast | Fast deployment ring for quick rollout and adoption |
| Modern Workplace Devices-Windows Autopatch-Broad | Final deployment ring for broad rollout into the organization |
The five Azure AD assigned groups that are used to organize devices for the software update-based deployment ring set within the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#default-deployment-ring-composition):
> [!IMPORTANT]
> Windows Autopatch groups is in **public preview**. This feature is being actively developed and might not be complete. You can test and use these features in production environments and provide feedback.<p>The Windows Autopatch group experience only applies if you’ve opted-in to use Windows Autopatch groups.</p><br>**To opt-in to use Windows Autopatch groups:**<ol><li>Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and select **Devices** from the left navigation menu.</li><li>Under **Windows Autopatch**, select **Release Management**, then select **Autopatch groups (preview)**.</li><li>Review the **[Microsoft Privacy Statement](../overview/windows-autopatch-privacy.md)** and the **[Autopatch groups Public Preview Addendum](../references/windows-autopatch-groups-public-preview-addendum.md)**. If you agree, select the **I have reviewed and agree to the Autopatch groups Public Preview Addendum** checkbox. Then, select **Use preview** to test out Windows Autopatch groups and its bundled feature set. If the **Use preview** option is greyed out, ensure you meet all the [Autopatch group prerequisites](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#autopatch-groups-prerequisites).</li></ol>
| Software updates-based deployment ring | Description |
| ----- | ----- |
| Windows Autopatch - Test | Deployment ring for testing software updates-based deployments prior production rollout. |
| Windows Autopatch - Ring1 | First production deployment ring for early adopters. |
| Windows Autopatch - Ring2 | Fast deployment ring for quick rollout and adoption. |
| Windows Autopatch - Ring3 | Final deployment ring for broad rollout into the organization. |
| Windows Autopatch - Last | Optional deployment ring for specialized devices or VIP/executives that must receive software update deployments after it’s well tested with early and general populations in an organization. |
In the software-based deployment ring set, each deployment ring has a different set of update deployment policies to control the updates rollout.
> [!CAUTION]
> Adding or importing devices directly into any of these groups isn't supported. Doing so might affect the Windows Autopatch service. To move devices between these groups, see [Moving devices in between deployment rings](#moving-devices-in-between-deployment-rings).
> [!IMPORTANT]
> Windows Autopatch device registration doesn't assign devices to the Test deployment rings of either the service-based (**Modern Workplace Devices-Windows Autopatch-Test**), or software updates-based (**Windows Autopatch – Test and Windows Autopatch – Last**) in the Default Autopatch group. This is intended to prevent devices that are essential to a business from being affected or devices that are used by executives from receiving early software update deployments.
During the device registration process, Windows Autopatch assigns each device to a [service-based and software-update based deployment ring](../deploy/windows-autopatch-groups-overview.md#sevice-based-versus-software-update-based-deployment-ring-sets) so that the service has the proper representation of device diversity across your organization.
The deployment ring distribution is designed to release software update deployments to as few devices as possible to get the signals needed to make a quality evaluation of a given update deployment.
> [!NOTE]
> You can't create additional deployment rings or use your own rings for devices managed by the Windows Autopatch service.
## Default deployment ring calculation logic
The Windows Autopatch deployment ring calculation occurs during the device registration process and it applies to both the [service-based and the software update-based deployment ring sets](../deploy/windows-autopatch-groups-overview.md#sevice-based-versus-software-update-based-deployment-ring-sets):
- 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%)**.
- If the Windows Autopatch tenant’s existing managed device size is **>200**, the deployment ring assignment will be First **(1%)**, Fast **(9%)**, remaining devices go to the Broad ring **(90%)**.
> [!NOTE]
> You can customize the deployment ring calculation logic by editing the Default Autopatch group.
| Deployment ring | Default device balancing percentage | Description |
| ----- | ----- | ----- |
| Test | **zero** | Windows Autopatch doesn't automatically add devices to this deployment ring. You must manually add devices to the Test ring following the required procedure. For more information on these procedures, see [Moving devices in between deployment rings](/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management#moving-devices-in-between-deployment-rings). The recommended number of devices in this ring, based upon your environment size, is as follows:<br><ul><li>**0–500** devices: minimum **one** device.</li><li>**500–5000** devices: minimum **five** devices.</li><li>**5000+** devices: minimum **50** devices.</li></ul>Devices in this group are intended for your IT Administrators and testers since changes are released here first. This release schedule provides your organization the opportunity to validate updates prior to reaching production users. |
| First | **1%** | The First ring is the first group of production users to receive a change.<p><p>This group is the first set of devices to send data to Windows Autopatch and are used to generate a health signal across all end-users. For example, Windows Autopatch can generate a statistically significant signal saying that critical errors are trending up in a specific release for all end-users, but can't be confident that it's doing so in your organization.<p><p>Since Windows Autopatch doesn't yet have sufficient data to inform a release decision, devices in this deployment ring might experience outages if there are scenarios that weren't covered during early testing in the Test ring.|
| Fast | **9%** | The Fast ring is the second group of production users to receive changes. The signals from the First ring are considered as a part of the release process to the Broad ring.<p><p>The goal with this deployment ring is to cross the **500**-device threshold needed to generate statistically significant analysis at the tenant level. These extra devices allow Windows Autopatch to consider the effect of a release on the rest of your devices and evaluate if a targeted action for your tenant is needed.</p> |
| Broad | Either **80%** or **90%** | The Broad ring is the last group of users to receive software update deployments. Since it contains most of the devices registered with Windows Autopatch, it favors stability over speed in a software update deployment.|
| Last | **zero** | The Last ring is intended to be used for either specialized devices or devices that belong to VIP/executives in an organization. Windows Autopatch doesn't automatically add devices to this deployment ring. |
## Software update-based to service-based deployment ring mapping
There’s a one-to-one mapping in between the service-based and software updates-based deployment rings introduced with Autopatch groups. This mapping is intended to help move devices in between deployment rings for other software update workloads that don’t yet support Autopatch groups such as Microsoft 365 Apps and Microsoft Edge.
| If moving a device to | The device also moves to |
| ----- | ----- |
| Windows Autopatch – Test | Modern Workplace Devices-Windows Autopatch-Test |
| Windows Autopatch – Ring1 | Modern Workplace Devices-Windows Autopatch-First |
| Windows Autopatch – Ring2 | Modern Workplace Devices-Windows Autopatch-Fast |
| Windows Autopatch – Ring3 | Modern Workplace Devices-Windows Autopatch-Broad |
| Windows Autopatch – Last | Modern Workplace Devices-Windows Autopatch-Broad |
If your Autopatch groups have more than five deployment rings, and you must move devices to deployment rings after Ring3. For example, `<Autopatch group name – Ring4, Ring5, Ring6, etc.>`. The devices will be moved to **Modern Workplace Devices-Windows Autopatch-Broad**.
## Moving devices in between deployment rings
If you want to move devices to different deployment rings (either service or software update-based), after Windows Autopatch's deployment ring assignment, you can repeat the following steps for one or more devices from the **Registered** tab.
**To move devices in between deployment rings:**
> [!NOTE]
> You can only move devices to other deployment rings when they're in an active state in the **Registered** tab.
1. In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices** in the left pane.
1. In the **Windows Autopatch** section, select **Devices**.
1. In the **Registered** tab, select one or more devices you want to assign. All selected devices will be assigned to the deployment ring you specify.
1. Select **Device actions** from the menu.
1. Select **Assign device group**. 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 will change 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.
If you don't see the Ring assigned by column change to **Pending** in Step 5, check to see whether the device exists in Microsoft Intune or not by searching for it in its device blade. For more information, see [Device details in Intune](/mem/intune/remote-actions/device-inventory).
> [!WARNING]
> Moving devices between deployment rings through directly changing Azure AD group membership isn't supported and may 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.
## Automated deployment ring remediation functions
Windows Autopatch monitors device membership in its deployment rings, except for the **Modern Workplace Devices-Windows Autopatch-Test**, **Windows Autopatch – Test** and **Windows Autopatch – Last** rings, to provide automated deployment ring remediation functions to mitigate the risk of not having its managed devices being part of one of its deployment rings. These automated functions help mitigate risk of potentially having devices in a vulnerable state, and exposed to security threats in case they're not receiving update deployments due to either:
- Changes performed by the IT admin on objects created by the Windows Autopatch tenant enrollment process, or
- An issue occurred which prevented devices from getting a deployment ring assigned during the device registration process.
There are two automated deployment ring remediation functions:
| Function | Description |
| ----- | ----- |
| Check device deployment ring membership | Every hour, Windows Autopatch checks to see if any of its managed devices aren't part of one of the deployment rings. If a device isn't part of a deployment ring, Windows Autopatch randomly assigns the device to one of its deployment rings (except for the **Modern Workplace Devices-Windows Autopatch-Test**, **Windows Autopatch – Test and Windows Autopatch – Last** rings). |
| Multi-deployment ring device remediator | Every hour, Windows Autopatch checks to see if any of its managed devices are part of multiple deployment rings (except for the **Modern Workplace Devices-Windows Autopatch-Test**, **Windows Autopatch – Test** and **Windows Autopatch – Last** rings). If a device is part of multiple deployment rings, Windows Autopatch randomly removes the device until the device is only part of one deployment ring. |
> [!IMPORTANT]
> Windows Autopatch automated deployment ring functions don’t assign or remove devices to or from the following deployment rings:<li>**Modern Workplace Devices-Windows Autopatch-Test**</li><li>**Windows Autopatch – Test**</li><li>**Windows Autopatch – Last**</li></ul>

155
windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md Normal file
View File

@ -0,0 +1,155 @@
---
title: Manage Windows Autopatch groups
description: This article explains what Autopatch groups are
ms.date: 05/01/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: how-to
ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: dougeby
ms.reviewer: andredm7
---
# Manage Windows Autopatch groups (public preview)
> [!IMPORTANT]
> Windows Autopatch groups is in **public preview**. This feature is being actively developed and might not be complete. You can test and use these features in production environments and provide feedback.<p>The Windows Autopatch group experience only applies if you’ve opted-in to use Windows Autopatch groups.</p><br>**To opt-in to use Windows Autopatch groups:**<ol><li>Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and select **Devices** from the left navigation menu.</li><li>Under **Windows Autopatch**, select **Release Management**, then select **Autopatch groups (preview)**.</li><li>Review the **[Microsoft Privacy Statement](../overview/windows-autopatch-privacy.md)** and the **[Autopatch groups Public Preview Addendum](../references/windows-autopatch-groups-public-preview-addendum.md)**. If you agree, select the **I have reviewed and agree to the Autopatch groups Public Preview Addendum** checkbox. Then, select **Use preview** to test out Windows Autopatch groups and its bundled feature set. If the **Use preview** option is greyed out, ensure you meet all the [Autopatch group prerequisites](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#autopatch-groups-prerequisites).</li></ol>
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 [Azure AD 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](https://learn.microsoft.com/mem/intune/protect/windows-10-feature-updates).
## Autopatch groups prerequisites
Before you start managing Autopatch groups, ensure you’ve met the following prerequisites:
- 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-windows-autopatch-groups) within your organization.
- Ensure the following Azure AD assigned groups are in your tenant before using Autopatch groups. **Don’t** modify the Azure AD 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
- Make sure you have [app-only auth turned on in your Windows Autopatch tenant](../operate/windows-autopatch-maintain-environment#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 Azure AD groups you intend to use with Autopatch groups are created prior to using the feature.
- Review your existing Azure AD group dynamic queries and direct device memberships to avoid having device membership overlaps in between device-based Azure AD 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 Azure AD groups**.
- Ensure devices used with your existing Azure AD 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.
## 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:**
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 (preview)**.
1. Only during the public preview:
1. Review the [Microsoft Privacy Statement](../overview/windows-autopatch-privacy.md) and the [Autopatch groups Public Preview Addendum](../references/windows-autopatch-groups-public-preview-addendum.md).
1. Select the **I have reviewed and agree to the Autopatch groups Public Preview Addendum** checkbox. Then, select **Use preview** to test out Autopatch groups. If the **Use preview** option is greyed out, ensure you meet all the [Autopatch group prerequisites](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#autopatch-groups-prerequisites).
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. Each new deployment ring added must have either an Azure AD device group assigned to it, or an Azure AD 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 Azure AD groups to be used for Dynamic group distribution.
1. In the **Dynamic group distribution** column, select the desired deployment ring checkbox. Then, either:
1. Enter the percentage of devices that should be added from the Azure AD groups selected in step 9. The percentage calculation for devices must equal to 100%, or
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 Azure AD 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 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.
> [!CAUTION]
> A device-based Azure AD 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 Azure AD 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).
> [!IMPORTANT]
> Windows Autopatch creates the device-based Azure AD 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.
## Edit the Default or a Custom Autopatch group
**To edit either the Default or a Custom 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. 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.
1. Once the review is done, select **Save** to finish editing the Autopatch group.
> [!IMPORTANT]
> Windows Autopatch creates the device-based Azure AD 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.
## Delete a Custom Autopatch group
You **can’t** delete the Default Autopatch group. However, you can delete a Custom 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.
> [!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.
## Manage device conflict scenarios when Autopatch groups
Overlap in device membership is a common scenario when working with device-based Azure AD groups since sometimes dynamic queries can be large in scope or the same assigned device membership can be used across different Azure AD groups.
Since Autopatch groups allow you to use your existing Azure AD 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.
> [!CAUTION]
> A device-based Azure AD 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 Azure AD group that’s been already used, you'll receive an error that prevents you from creating or editing the Autopatch group (Default or Custom).
### 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:
| 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 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]
> When a device belongs to a deployment ring that has combined distribution types (**Assigned** and **Dynamic**), and a deployment ring that has only the **Dynamic** distribution type, the deployment ring with the combined distribution types takes precedence over the one with only the **Dynamic** distribution. If a device belongs to two deployment rings that have combined distribution types (**Assigned** and **Dynamic**), the deployment ring that comes later takes precedence over the deployment ring that comes earlier in the deployment ring order.
### 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:
#### Default to Custom Autopatch group device conflict
| 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”.<p>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.</p> | Autopatch groups automatically resolve this conflict on your behalf.<p>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.</p> |
#### Custom to Custom Autopatch group device conflict
| 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.<p>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.</p> |
#### Device conflict prior device registration
When you create or edit the Custom or Default Autopatch group, Windows Autopatch checks if the devices that are part of the Azure AD 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.<p>Devices will fail to register with the service and will be sent to the **Not registered** tab. You’re required to make sure the Azure AD groups that are used with the Custom Autopatch groups don’t have device membership overlaps.</p> |
#### 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-device-conflict-scenarios-when-autopatch-groups) section even after devices were successfully registered with the service.

250
windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md Normal file
View File

@ -0,0 +1,250 @@
---
title: Windows Autopatch groups overview
description: This article explains what Autopatch groups are
ms.date: 05/01/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: conceptual
ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: dougeby
ms.reviewer: andredm7
---
# Windows Autopatch groups overview (public preview)
> [!IMPORTANT]
> Windows Autopatch groups is in **public preview**. This feature is being actively developed and might not be complete. You can test and use these features in production environments and provide feedback.<p>The Windows Autopatch group experience only applies if you’ve opted-in to use Windows Autopatch groups.</p><br>**To opt-in to use Windows Autopatch groups:**<ol><li>Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and select **Devices** from the left navigation menu.</li><li>Under **Windows Autopatch**, select **Release Management**, then select **Autopatch groups (preview)**.</li><li>Review the **[Microsoft Privacy Statement](../overview/windows-autopatch-privacy.md)** and the **[Autopatch groups Public Preview Addendum](../references/windows-autopatch-groups-public-preview-addendum.md)**. If you agree, select the **I have reviewed and agree to the Autopatch groups Public Preview Addendum** checkbox. Then, select **Use preview** to test out Windows Autopatch groups and its bundled feature set. If the **Use preview** option is greyed out, ensure you meet all the [Autopatch group prerequisites](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#autopatch-groups-prerequisites).</li></ol>
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 helps 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 [Azure AD 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).
## Key benefits
Autopatch groups help Microsoft Cloud-Managed services meet organizations where they are in their update management journey. Key benefits include:
| Benefit | Description |
| ----- | ----- |
| Replicating your organizational structure | You can set up Autopatch groups to replicate your organizational structures represented by your existing device-based Azure AD 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 Azure AD 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. |
| Choosing the deployment cadence | You choose the right software update deployment cadence for your business. |
## 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:
| Step | Description |
| ----- | ----- |
| Step 1: Create an Autopatch group | Create an Autopatch group. |
| Step 2: Windows Autopatch uses Microsoft Graph to create Azure AD and policy assignments | Windows Autopatch service uses Microsoft Graph to coordinate the creation of:<ul><li>Azure AD groups</li><li>Software update policy assignments with other Microsoft services, such as Azure AD, Intune, and Windows Update for Business (WUfB) based on IT admin choices when you create or edit an Autopatch group.</li></ul> |
| Step 3: Intune assigns software update policies | Once Azure AD groups are created in the Azure AD 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:<ul><li>Delivering those update policies</li><li>Retrieving update deployment statuses back from devices</li><li>Sending back the status information to Microsoft Intune, and then to the Windows Autopatch service</li></ul> |
## 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 additional 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 Azure AD 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 Azure AD 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 | Azure AD 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 | Azure AD 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 20H2 | Make update available as soon as possible | N/A | N/A | N/A | May 8, 2023; 7:00PM |
| Windows Autopatch - DSS Policy [Ring1] | Windows Autopatch - Ring1 | Windows 10 20H2 | Make update available as soon as possible | N/A | N/A | N/A | May 8, 2023; 7:00PM |
| Windows Autopatch - DSS Policy [Ring2] | Windows Autopatch - Ring2 | Windows 10 20H2 | Make update available as soon as possible | December 14, 2022 | December 21, 2022 | 1 | May 8, 2023; 7:00PM |
| Windows Autopatch - DSS Policy [Ring3] | Windows Autopatch - Ring3 | Windows 10 20H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | May 8, 2023; 7:00PM |
| Windows Autopatch - DSS Policy [Last] | Windows Autopatch - Last | Windows 10 20H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | May 8, 2023; 7:00PM |
### 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
Deployment rings make it possible for an Autopatch group to have software update deployments sequentially delivered in a gradual rollout within the Autopatch group.
Windows Autopatch aligns with Azure AD and Intune terminology for device group management. There are two types of deployment ring group distribution in Autopatch groups:
| Deployment ring distribution | Description |
| ----- | ----- |
| Dynamic | You can use one or more device-based Azure AD groups, either dynamic query-based or assigned to use in your deployment ring composition.<p>Azure AD groups that are used with the Dynamic distribution type can be used to distribute devices across several deployment rings based on percentage values that can be customized.</p> |
| Assigned | You can use one single device-based Azure AD 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.<p>The combination of Dynamic and Assigned device distribution is **not** supported for the Test and Last deployment ring in Autopatch groups.</p> |
#### About the 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.
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.
> [!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.
> [!TIP]
> Both the **Test** and **Last** deployment rings only support one single Azure AD group assignment at a time. If you need to assign more than one Azure AD group, you can nest the other Azure AD groups under the ones you plan to use with the **Test** and **Last** deployment rings. Only one level of Azure AD 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 Azure AD assigned groups that represent the service-based deployment rings. These groups cannot 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 Azure AD 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. <p>Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Azure AD group created by Autopatch groups.</p>
##### 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 Azure AD assigned groups that represent the software updates-based deployment rings. These groups cannot be deleted or renamed:
- Windows Autopatch - Test
- Windows Autopatch – Ring1
- Windows Autopatch – Ring2
- Windows Autopatch – Ring3
- Windows Autopatch – Last
> [!IMPORTANT]
> Additional Azure AD assigned groups are created and added to list when you add more deployment rings to the Default Autopatch group.
> [!CAUTION]
> **Don’t** modify the Azure AD 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. <p>Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Azure AD group created by Autopatch groups.</p>
### About device registration
Autopatch groups register devices with the Windows Autopatch service when you either [create](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group) or [edit a Custom Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group), and/or when you [edit the Default Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) to use your existing Azure AD 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.<p>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 pre-communicated to your end-users.</p> | 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.<p>The Default Autopatch group is pre-configured and doesn’t require extra configurations when registering devices with the Windows Autopatch service.</p><p>The following is a visual representation of a gradual rollout for the Default Autopatch group pre-configured and fully managed by the Windows Autopatch service.</p> |
:::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, 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 subsequently for the business.<p>The following is a visual representation of a gradual rollout for Contoso’s Finance department.</p> |
:::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
| 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.<p>The following is a visual representation of a gradual rollout for the Contoso Chicago branch location.</p> |
:::image type="content" source="../media/autopatch-groups-contoso-chicago-example.png" alt-text="Contoso Chicago example" lightbox="../media/autopatch-groups-contoso-chicago-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.
## Supported configurations
The following configurations are supported when using Autopatch groups.
### Software update workloads
Autopatch groups works 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)
> [!IMPORTANT]
> [Microsoft Edge](../operate/windows-autopatch-edge.md) and [Microsoft 365 Apps for enterprise](../operate/windows-autopatch-microsoft-365-apps-enterprise.md) are supported through the (classic) service-based deployment rings. Other software update workloads aren’t currently supported.
### Maximum number of Autopatch groups
Windows Autopatch will support 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.
To manage your Autopatch groups, see [Manage Windows Autopatch groups](../deploy/windows-autopatch-groups-manage-autopatch-groups.md).

100
windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md
View File

@ -1,7 +1,7 @@
---
title: Register your devices
description: This article details how to register devices in Autopatch
ms.date: 04/24/2023
ms.date: 05/01/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: how-to
@ -20,14 +20,25 @@ Before Microsoft can manage your devices in Windows Autopatch, you must have dev
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:
- [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md)
- [Windows feature updates](../operate/windows-autopatch-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)
- Windows quality updates
- [Autopatch groups experience](../operate/windows-autopatch-groups-windows-quality-update-overview.md)
- [Classic experience](../operate/windows-autopatch-windows-quality-update-overview.md)
- Windows feature updates
- [Autopatch groups experience](../operate/windows-autopatch-groups-windows-feature-update-overview.md)
- [Classic experience](../operate/windows-autopatch-windows-feature-update-overview.md)
- The following software update workloads use the Classic experience:
- [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)
### About the use of an Azure AD group to register devices
Windows Autopatch provides two methods of registering devices with its service, the [Classic](#classic-device-registration-method) and the Autopatch groups device registration method.
#### Classic device registration method
This method is intended to help organizations that don’t require the use of [Custom Autopatch groups](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups) or additional customizations to the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) to register devices.
You must choose what devices to manage with Windows Autopatch by adding them to the **Windows Autopatch Device Registration** Azure AD assigned group. Devices can be added using the following methods:
- Direct membership
@ -36,17 +47,31 @@ You must choose what devices to manage with Windows Autopatch by adding them to
Windows Autopatch automatically runs its discover devices function every hour to discover new devices added to this group. Once new devices are discovered, Windows Autopatch attempts to register these devices.
> [!NOTE]
> Devices that are intended to be managed by the Windows Autopatch service **must** be added into the **Windows Autopatch Device Registration** Azure AD assigned group. Devices can only be added to this group if they have an Azure AD device ID. Windows Autopatch scans the Azure AD group hourly to discover newly added devices to be registered. You can also use the **Discover devices** button in either the **Ready** or **Not ready** tab to register devices on demand.
You can also use the **Discover devices** button in either the Registered or Not ready tab to register devices on demand. The **Discover devices** button scans for devices to be registered in the **Windows Autopatch Device Registration** or any other Azure AD group used with either the Default or Custom Autopatch groups.
#### Supported scenarios when nesting other Azure AD groups
#### Windows Autopatch groups device registration method
> [!IMPORTANT]
> Windows Autopatch groups is in **public preview**. This feature is being actively developed and might not be complete. You can test and use these features in production environments and provide feedback.<p>The Windows Autopatch group experience only applies if you’ve opted-in to use Windows Autopatch groups.</p><br>**To opt-in to use Windows Autopatch groups:**<ol><li>Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and select **Devices** from the left navigation menu.</li><li>Under **Windows Autopatch**, select **Release Management**, then select **Autopatch groups (preview)**.</li><li>Review the **[Microsoft Privacy Statement](../overview/windows-autopatch-privacy.md)** and the **[Autopatch groups Public Preview Addendum](../references/windows-autopatch-groups-public-preview-addendum.md)**. If you agree, select the **I have reviewed and agree to the Autopatch groups Public Preview Addendum** checkbox. Then, select **Use preview** to test out Windows Autopatch groups and its bundled feature set. If the **Use preview** option is greyed out, ensure you meet all the [Autopatch group prerequisites](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#autopatch-groups-prerequisites).</li></ol>
This method is intended to help organizations that require the use of [Custom Autopatch groups](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups) or additional customizations to the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group).
When you either create/edit a Custom Autopatch group or edit the Default Autopatch group to add or remove deployment rings, the device-based Azure AD 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 starts the device registration process by using your existing device-based Azure AD groups instead of the Windows Autopatch Device Registration group.
For more information, see [create Custom Autopatch groups](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group) and [edit Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) to register devices using the Autopatch groups device registration method.
##### Supported scenarios when nesting other Azure AD groups
Windows Autopatch also supports the following Azure AD nested group scenarios:
Azure AD 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).
- On-premises Active Directory groups (Windows Server AD)
- [Configuration Manager collections](/mem/configmgr/core/clients/manage/collections/create-collections#bkmk_aadcollsync)
The Azure AD groups apply to both the [Classic](#classic-device-registration-method) and the [Autopatch group device registration](#windows-autopatch-groups-device-registration-method) methods.
> [!WARNING]
> It isn't recommended to sync Configuration Manager collections straight to the **Windows Autopatch Device Registration** Azure AD group. Use a different Azure AD group when syncing Configuration Manager collections to Azure AD groups then you can nest this or these groups into the **Windows Autopatch Device Registration** Azure AD group.
@ -63,10 +88,13 @@ In the dual state, you end up having two Azure AD device records with different
It's recommended to detect and clean up stale devices in Azure AD before registering devices with Windows Autopatch, see [How To: Manage state devices in Azure AD](/azure/active-directory/devices/manage-stale-devices).
> [!WARNING]
> If you don't clean up stale devices in Azure AD 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 Azure AD devices are not enrolled into the Intune service anymore.
> If you don't clean up stale devices in Azure AD 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 Azure AD devices aren't enrolled into the Intune service anymore.
## Prerequisites for device registration
> [!IMPORTANT]
> The following prerequisites apply to both the [Classic](#classic-device-registration-method) and the [Autopatch groups device registration](#windows-autopatch-groups-device-registration-method) methods.
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).
@ -88,26 +116,29 @@ To be eligible for Windows Autopatch management, devices must meet a minimum set
For more information, see [Windows Autopatch Prerequisites](../prepare/windows-autopatch-prerequisites.md).
## About the Ready, Not ready and Not registered tabs
## About the Registered, Not ready and Not registered tabs
Windows Autopatch has three tabs within its device blade. Each tab is designed to provide a different set of device readiness statuses so IT admin knows where to go to monitor, and fix potential device health issues.
> [!IMPORTANT]
> Devices registered through either the [Classic](#classic-device-registration-method) or the [Autopatch groups device registration method](#windows-autopatch-groups-device-registration-method) 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 |
| ----- | ----- | ----- |
| Ready | The purpose of this tab is to show devices that were successfully registered with the Windows Autopatch service. | Active |
| 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. | Pre-requisites failed |
| 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
See all possible device readiness statuses in Windows Autopatch:
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. | Ready |
| 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 |
| Pre-requisites failed | Devices with this status haven't passed one or more pre-requisite checks and haven't successfully registered with Windows Autopatch | Not registered |
| 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
@ -120,7 +151,7 @@ For more information, see [Azure AD built-in roles](/azure/active-directory/role
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 Azure AD groups created during the [tenant enrollment](../prepare/windows-autopatch-enroll-tenant.md) process:
| Role | Discover devices | Modify columns | Refresh device list | Export to .CSV | Device actions |
| Azure AD 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 |
@ -133,30 +164,36 @@ If you want to assign less-privileged user accounts to perform specific tasks in
Registering your devices with Windows Autopatch does the following:
1. Makes a record of devices in the service.
2. Assign devices to the [deployment rings](../operate/windows-autopatch-update-management.md) and other groups required for software update management.
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).
## Steps to register devices
## Steps to register devices using the classic method
> [!IMPORTANT]
> For more information, see [Create Custom Autopatch groups](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group) and [Edit Autopatch groups](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) on how to register devices using the Autopatch groups device registration method.
Any device (either physical or virtual) that contains an Azure AD device ID, can be added into the **Windows Autopatch Device Registration** Azure AD group through either direct membership or by being part of another Azure AD group (either dynamic or assigned) that's nested to this group, so it can be registered with Windows Autopatch. The only exception is new Windows 365 Cloud PCs, as these virtual devices should be registered with Windows Autopatch from the Windows 365 provisioning policy.
For more information, see [Windows Autopatch on Windows 365 Enterprise Workloads](#windows-autopatch-on-windows-365-enterprise-workloads).
Any device (either physical or virtual) that contains an Azure AD device ID, can be added into the **Windows Autopatch Device Registration** Azure AD group through either direct membership or by being part of another Azure AD group (either dynamic or assigned) that's nested to this group, so it can be registered with Windows Autopatch. The only exception is new Windows 365 Cloud PCs, as these virtual devices should be registered with Windows Autopatch from the Windows 365 provisioning policy. For more information, see [Windows Autopatch on Windows 365 Enterprise Workloads](#windows-autopatch-on-windows-365-enterprise-workloads).
Since existing Windows 365 Cloud PCs already have an existing Azure AD device ID, these devices can be added into the **Windows Autopatch Device Registration** Azure group through either direct membership or by being part of another Azure AD group (either dynamic or assigned) that's nested to this group.
**To register devices with Windows Autopatch:**
**To register devices with Windows Autopatch using the classic method:**
1. Go to the [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 **Devices**.
4. Select either the **Ready** or the **Not registered** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
4. Select either the **Registered** or the **Not registered** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
5. Add either devices through direct membership, or other Azure AD dynamic or assigned groups as nested groups in the **Windows Autopatch Device Registration** group.
> [!NOTE]
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Ready tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both **Ready** and **Not registered** tabs.
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Registered tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both **Registered** and **Not registered** tabs.
Once devices or other Azure AD groups (either dynamic or assigned) containing devices are added to the **Windows Autopatch Device Registration** group, Windows Autopatch's device discovery hourly function discovers these devices, and runs software-based prerequisite checks to try to register them with its service.
> [!TIP]
> You can also use the **Discover Devices** button in either one of the **Ready**, **Not ready**, or **Not registered** device blade tabs to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand. On demand means you don't have to wait for Windows Autopatch to discover devices from the Azure AD group on your behalf.
> You can also use the **Discover Devices** button in either one of the **Registered**, **Not ready**, or **Not registered** device blade tabs to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand. On demand means you don't have to wait for Windows Autopatch to discover devices from the Azure AD group on your behalf.
### Windows Autopatch on Windows 365 Enterprise Workloads
@ -177,11 +214,14 @@ Windows 365 Enterprise gives IT admins the option to register devices with the W
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-ring-sets).
### 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](#steps-to-register-devices).
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](#steps-to-register-devices). 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](#steps-to-register-devices-using-the-classic-method). However, Windows Autopatch defers any Azure Virtual Desktop specific support to [Azure support](#contact-support-for-device-registration-related-incidents), unless otherwise specified.
#### Prerequisites
@ -199,7 +239,7 @@ The following Azure Virtual Desktop features aren’t supported:
#### 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](#steps-to-register-devices). For more information, see [Register your devices](#steps-to-register-devices).
Azure Virtual Desktop workloads can be registered into Windows Autopatch by using the same method as your [physical devices](#steps-to-register-devices-using-the-classic-method).
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: