mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 02:43:43 +00:00
Autopatch NFA release
This commit is contained in:
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Device registration overview
|
||||
title: Autopatch group registration overview
|
||||
description: This article provides an overview on how to register devices in Autopatch.
|
||||
ms.date: 10/30/2024
|
||||
ms.date: 03/31/2025
|
||||
ms.service: windows-client
|
||||
ms.subservice: autopatch
|
||||
ms.topic: concept-article
|
||||
@ -15,11 +15,9 @@ ms.collection:
|
||||
- tier1
|
||||
---
|
||||
|
||||
# Device registration overview
|
||||
# Autopatch group registration overview
|
||||
|
||||
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
|
||||
|
||||
Windows Autopatch must [register your existing devices](../deploy/windows-autopatch-register-devices.md) into its service to manage update deployments on your behalf.
|
||||
When you assign a Microsoft Entra Group to an Autopatch policy or [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group), the device is registered with the Autopatch Service.
|
||||
|
||||
## Prerequisites for device registration
|
||||
|
||||
@ -31,88 +29,17 @@ A role defines the set of permissions granted to users assigned to that role. Yo
|
||||
|
||||
To be eligible for Windows Autopatch management, devices must meet a minimum set of required software-based prerequisites. For more information, see [Windows Autopatch prerequisites](../prepare/windows-autopatch-prerequisites.md).
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Windows Autopatch supports registering [Windows 10 and Windows 11 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/overview) devices that are being currently serviced by the [Windows 10 LTSC](/windows/release-health/release-information) or [Windows 11 LTSC](/windows/release-health/windows11-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](/windows/deployment/deploy-windows-cm/upgrade-to-windows-10-with-configuration-manager) for Windows devices that are part of the LTSC.
|
||||
|
||||
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 as follows:
|
||||
The overall Autopatch group 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 prerequisites](#prerequisites-for-device-registration) before registering devices with Windows Autopatch.
|
||||
2. IT admin identifies and adds devices, or nests other Microsoft Entra device groups when you [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group), [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group), or import Windows Update for Business (WUfB) policies.
|
||||
3. Windows Autopatch then:
|
||||
1. IT admin identifies and adds devices, or nests other Microsoft Entra device groups 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).
|
||||
2. Windows Autopatch then:
|
||||
1. Performs device readiness prior registration (prerequisite checks).
|
||||
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 Microsoft Entra 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](../deploy/windows-autopatch-register-devices.md#detailed-device-registration-workflow-diagram) section for more technical details behind the Windows Autopatch device registration process.
|
||||
|
||||
## Windows Autopatch deployment rings
|
||||
|
||||
> [!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.<p>Additionally, it's not supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.</p>
|
||||
|
||||
When you [start using Autopatch](../prepare/windows-autopatch-feature-activation.md), Windows Autopatch creates the following deployment ring set to organize devices.
|
||||
|
||||
| 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 |
|
||||
|
||||
> [!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 [Move devices in between deployment rings](../deploy/windows-autopatch-register-devices.md#move-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 your Autopatch groups. 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 deployment ring 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.
|
||||
|
||||
### Device record and deployment ring assignment
|
||||
|
||||
When you register your devices, Windows Autopatch:
|
||||
|
||||
1. Makes a record of devices in the service.
|
||||
2. Assign devices to the [deployment ring set](#default-deployment-ring-calculation-logic) and other groups required for software update management.
|
||||
|
||||
### Default deployment ring calculation logic
|
||||
|
||||
The Windows Autopatch deployment ring calculation occurs during the device registration process:
|
||||
|
||||
- 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 is First **(1%)**, Fast **(9%)**, remaining devices go to the Broad ring **(90%)**.
|
||||
|
||||
> [!NOTE]
|
||||
> You can customize the deployment ring calculation logic by [editing an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-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 before 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.|
|
||||
| N/A | **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. |
|
||||
|
||||
## 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>
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Windows Autopatch groups overview
|
||||
description: This article explains what Autopatch groups are
|
||||
ms.date: 09/16/2024
|
||||
ms.date: 03/31/2025
|
||||
ms.service: windows-client
|
||||
ms.subservice: autopatch
|
||||
ms.topic: concept-article
|
||||
@ -17,13 +17,11 @@ ms.collection:
|
||||
|
||||
# Windows Autopatch groups
|
||||
|
||||
[!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?
|
||||
|
||||
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).
|
||||
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), [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates), [driver update policies](../manage/windows-autopatch-manage-driver-and-firmware-updates.md), [Microsoft 365 App update policies](../manage/windows-autopatch-microsoft-365-policies.md), and [Microsoft Edge update policies](../manage/windows-autopatch-edge.md).
|
||||
|
||||
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.
|
||||
|
||||
@ -49,10 +47,7 @@ Before you start managing Autopatch groups, ensure you meet the following prereq
|
||||
| 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: |<ul><li>Read device attributes to successfully register devices.</li><li>Manage all configurations related to the operation of the service.</li></ul> |
|
||||
| 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:<ul><li>Avoid having device membership overlaps in between device-based Microsoft Entra groups that are going to be used with Autopatch groups.</li><li>Prevent device conflicts within an Autopatch group or across several Autopatch groups. **Autopatch groups doesn't support user-based Microsoft Entra groups**.</li></ul> |
|
||||
| Ensure devices used with your existing Microsoft Entra groups meet [device registration prerequisite checks](../deploy/windows-autopatch-device-registration-overview.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-missing-windows-update-policies).
|
||||
| Ensure devices used with your existing Microsoft Entra groups meet [device registration prerequisite checks](../deploy/windows-autopatch-device-registration-overview.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 [Autopatch groups membership report](../deploy/windows-autopatch-register-devices.md#autopatch-groups-membership-report). |
|
||||
|
||||
## Register devices into Autopatch groups
|
||||
|
||||
@ -67,9 +62,9 @@ An Autopatch group is a function app that is part of the device registration mic
|
||||
| Step | Description |
|
||||
| ----- | ----- |
|
||||
| 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:<ul><li>Microsoft Entra groups</li><li>Software update policy assignments with other Microsoft services, such as Microsoft Entra ID, Intune, and Windows Update for Business (WUfB) based on IT admin choices when you [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).</li></ul> |
|
||||
| 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:<ul><li>Microsoft Entra groups</li><li>Software update policy assignments with other Microsoft services, such as Microsoft Entra ID, and Intune, and or Windows Update for Business (WUfB) based on IT admin choices when you [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).</li></ul> |
|
||||
| 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:<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> |
|
||||
| Step 4: Windows Autopatch responsibilities | Windows Autopatch service is responsible for:<ul><li>Delivering those update policies</li><li>Retrieving update deployment statuses back from devices</li></ul> |
|
||||
|
||||
## Autopatch group deployment rings
|
||||
|
||||
@ -108,7 +103,7 @@ The following are three common uses for using Autopatch groups.
|
||||
:::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.
|
||||
> Once Autopatch groups are set up, the releases of either Windows quality or feature updates are deployed sequentially through its deployment rings.
|
||||
|
||||
### Use case #2
|
||||
|
||||
@ -119,7 +114,7 @@ The following are three common uses for using Autopatch groups.
|
||||
:::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.
|
||||
> Once Autopatch groups are set up, the releases of either Windows quality or feature updates are deployed sequentially through its deployment rings.
|
||||
|
||||
## Supported configurations
|
||||
|
||||
@ -137,9 +132,9 @@ Autopatch groups work with the following software update workloads:
|
||||
|
||||
### Maximum number of Autopatch groups
|
||||
|
||||
Windows Autopatch supports up to 50 Autopatch groups in your tenant. Each Autopatch group supports up to 15 deployment rings.
|
||||
Windows Autopatch supports up to 300 Autopatch groups in your tenant. Each Autopatch group supports up to 15 deployment rings.
|
||||
|
||||
> [!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.
|
||||
> 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 is greyed out.
|
||||
|
||||
To manage your Autopatch groups, see [Manage Windows Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.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: 09/16/2024
|
||||
ms.date: 03/31/2025
|
||||
ms.service: windows-client
|
||||
ms.subservice: autopatch
|
||||
ms.topic: concept-article
|
||||
@ -17,8 +17,6 @@ ms.collection:
|
||||
|
||||
# Post-device registration readiness checks
|
||||
|
||||
[!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 ongoing change management processes is important; it helps mitigate high Helpdesk ticket volumes, reduces cost, and improves overall update management results.
|
||||
@ -51,7 +49,7 @@ 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 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.
|
||||
Windows Autopatch has devices readiness states within its [**Autopatch group membership report**](../deploy/windows-autopatch-register-devices.md#autopatch-group-membership-report). Each state provides IT admins monitoring information on which devices might have potential device health issues.
|
||||
|
||||
| Tab | Description |
|
||||
| ----- | ----- |
|
||||
@ -68,6 +66,16 @@ A healthy or active device in Windows Autopatch is:
|
||||
|
||||
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** and **Windows Autopatch Client Broker** 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** and **Windows Autopatch Client Broker** are subcomponents of the overall Windows Autopatch service.
|
||||
|
||||
### Install the Windows Autopatch Client Broker
|
||||
|
||||
You can install the Windows Autopatch Client Broker on-demand at the tenant level to determine device update readiness and collect logs for issue triaging.
|
||||
|
||||
**To install the Windows Autopatch Client Broker**:
|
||||
|
||||
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
|
||||
1. Navigate to the **Tenant administration** menu.
|
||||
1. In the **Windows Autopatch** section, select **Tenant Management**. Then, select **Manage client broker**.
|
||||
|
||||
The following list of post-device registration readiness checks is performed in Windows Autopatch:
|
||||
|
||||
| Check | Description |
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Register your devices
|
||||
title: Register devices with Autopatch groups
|
||||
description: This article details how to register devices in Autopatch.
|
||||
ms.date: 09/26/2024
|
||||
ms.date: 03/31/2025
|
||||
ms.service: windows-client
|
||||
ms.subservice: autopatch
|
||||
ms.topic: how-to
|
||||
@ -15,11 +15,11 @@ ms.collection:
|
||||
- tier1
|
||||
---
|
||||
|
||||
# Register your devices
|
||||
# Register devices with 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).
|
||||
|
||||
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).
|
||||
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), the device-based Microsoft Entra groups you use are scanned on an ongoing basis to see if new devices need to be added to the Autopatch group.
|
||||
|
||||
## Detailed device registration workflow diagram
|
||||
|
||||
@ -29,91 +29,45 @@ 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 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.<ol><li>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:</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 before 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>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Microsoft Entra 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 Microsoft Entra device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>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.</li><li>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).</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 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 the device's Autopatch readiness status appears as **Not registered** in the **Devices report**.</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 is **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 two deployment ring sets, the first one being the service-based deployment ring set represented by the following Microsoft Entra 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 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.</li></ol><li>**Modern Workplace Devices-Windows Autopatch-Fast**</li><li>**Modern Workplace Devices-Windows Autopatch-Broad**</li> |
|
||||
| **Step 7: Assign devices to a Microsoft Entra group** | Windows Autopatch also assigns devices to the following Microsoft Entra 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 **Ready**. The device's Autopatch readiness status appears as **Registered** in the **Devices report**.</li><li>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.</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's Autopatch readiness status. Devices are either **Registered** or **Not registered** in the **Devices report**.<ol><li>If the device was **successfully registered**, the device's Autopatch readiness status appears as **Registered** in the **Devices report**.</li><li>If **not**, the device's Autopatch readiness status appears as **Not registered** in the **Devices report**.</li></ol> |
|
||||
| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
|
||||
| **Step 1: Assign Entra Groups** | IT admin identifies the Microsoft Entra group they want to assign when they [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). |
|
||||
| **Step 2: 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 #1**. 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.<ol><li>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:</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 before registration.</li></ol> |
|
||||
| **Step 3: 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>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Microsoft Entra 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 Microsoft Entra device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>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 [**Autopatch groups membership report**](#autopatch-groups-membership-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.</li><li>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).</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 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 the device's Autopatch readiness status appears as **Not registered** in the **Autopatch groups membership report**.</li></ol></ol></ol>|
|
||||
| **Step 4: Calculate dynamic distribution and assign devices** | Microsoft Entra Groups, which are directly assigned to a deployment ring, adds those devices to the Microsoft Entra Group that Autopatch creates for that deployment ring.<p>If you choose to use dynamic distribution, the Autopatch service distributes the devices you selected. The service takes a percentage of the devices in the dynamic pool and adds them to the relevant Microsoft Entra groups. Devices that are members of Microsoft Entra groups that are directly assigned aren't included in the dynamic pool.</p><p>If you have fewer than 100 devices in an Autopatch group, the distribution might not match your selection.</p>|
|
||||
| **Step 5: Post-device registration** | If you deployed the [**Windows Autopatch Client Broker**](../deploy/windows-autopatch-post-reg-readiness-checks.md#install-the-windows-autopatch-client-broker), post-device registration actions occur. For more information, see [Post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md#post-device-registration-readiness-checks-workflow). |
|
||||
| **Step 6: Review device registration status** | IT admins review the device's Autopatch readiness status. Devices are either **Registered** or **Not registered** in the **[**Autopatch groups membership report**](#autopatch-groups-membership-report)**.<ol><li>If the device was **successfully registered**, the device's Autopatch readiness status appears as **Registered** in the **Autopatch groups membership report**.</li><li>If **not**, the device's Autopatch readiness status appears as **Not registered** in the **Autopatch groups membership report**.</li></ol> |
|
||||
| **Step 7: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
|
||||
|
||||
## Detailed prerequisite check workflow diagram
|
||||
|
||||
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.
|
||||
As described in **step #3** 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="Diagram of the prerequisite check workflow." lightbox="../media/windows-autopatch-prerequisite-check-workflow-diagram.png":::
|
||||
|
||||
## Devices report
|
||||
## Autopatch groups membership report
|
||||
|
||||
Windows Autopatch has a device report that allows you to see:
|
||||
Windows Autopatch has an Autopatch groups membership report that allows you to see:
|
||||
|
||||
- Each registered devices readiness for the service
|
||||
- Autopatch group membership (only if the device is added to an Autopatch group)
|
||||
- Update status
|
||||
- Policies that target each device
|
||||
|
||||
### View the device report
|
||||
### View the Autopatch groups membership report
|
||||
|
||||
**To view the device report:**
|
||||
**To view the Autopatch groups membership 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. 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.
|
||||
Once a device is added to an Autopatch group, 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 | Substatus description |
|
||||
| Autopatch readiness status in the Autopatch groups membership report | Substatus description |
|
||||
| --- | --- |
|
||||
| Registered |<ul><li>**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.</li><li>**Not ready**: These devices were successfully registered with Windows Autopatch. However, these devices:</li><ul><li>Failed to pass one or more [post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).</li><li>Aren't ready to have one or more software update workloads managed by the service.</li><li>The device didn't communicate with Microsoft Intune in the last 28 days</li><li>The device has a conflict with policies or with Autopatch group membership</li></ul></ul> |
|
||||
| Not registered |<ul><li>**Autopatch group conflict**: The device has a conflict with Autopatch group membership</li><li>**Prerequisites failed**: The device failed to pass one or more [post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).</li><li>**Excluded**: Devices with this status are removed from the Windows Autopatch service only. Microsoft assumes you manage these devices yourself in some capacity.</li></ul> |
|
||||
|
||||
### 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.
|
||||
|
||||
> [!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. Navigate to **Windows updates** > **Monitor** > **Autopatch devices**.
|
||||
1. Select one or more devices you want to assign and select **Assign ring**.
|
||||
1. Use the dropdown menu to select the deployment ring to move devices to, and then select **Save**. All selected devices are assigned to the deployment ring you specify. The "1 devices scheduled for assignment" notification appears.
|
||||
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. The **Ring assigned by** column is only visible in the fly-in menu.
|
||||
|
||||
> [!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 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:
|
||||
@ -136,7 +90,7 @@ 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 [activate Windows Autopatch features](../prepare/windows-autopatch-feature-activation.md) to continue.
|
||||
1. Under the **Microsoft managed services** section, ensure **Windows Autopatch** is selected.
|
||||
1. Assign your policy accordingly and select **Next**.
|
||||
1. Select **Create**. Now your newly provisioned Windows 365 Enterprise Cloud PCs are automatically enrolled and managed by Windows Autopatch.
|
||||
|
||||
@ -146,7 +100,7 @@ For more information, see [Create a Windows 365 Provisioning Policy](/windows-36
|
||||
|
||||
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](../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.
|
||||
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-autopatch-group-registration-related-incidents), unless otherwise specified.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
@ -183,27 +137,23 @@ In the dual state, you end up having two Microsoft Entra device records with dif
|
||||
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.
|
||||
> 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)** prerequisite check in the **Not ready** tab because it expects 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)]
|
||||
### Contact support for Autopatch group registration-related incidents
|
||||
|
||||
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](../manage/windows-autopatch-support-request.md).
|
||||
|
||||
---
|
||||
- For Windows Autopatch support, see [Submit a support request](../manage/windows-autopatch-support-request.md). You can only submit a support request if you have E3+ or F3 licenses. For more information, see [Features and capabilities](../overview/windows-autopatch-overview.md).
|
||||
|
||||
## Device management lifecycle scenarios
|
||||
|
||||
There's a few more device management lifecycle scenarios to consider when planning to register devices in Windows Autopatch.
|
||||
There's a few more device management lifecycle scenarios to consider when planning to register devices in an Autopatch group.
|
||||
|
||||
### Device refresh
|
||||
|
||||
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.
|
||||
If a device was previously registered into an Autopatch group, 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 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.
|
||||
|
||||
|
Reference in New Issue
Block a user