mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 02:43:43 +00:00
Updating Technet/MSDN links and getting rid of gremlins
This commit is contained in:
Frank Rojas
@ -19,7 +19,7 @@ ms.collection:
|
||||
|
||||
Windows Autopatch must [register your existing devices](windows-autopatch-register-devices.md) into its service to manage update deployments on your behalf.
|
||||
|
||||
The Windows Autopatch device registration process is transparent for end-users because it doesn’t require devices to be reset.
|
||||
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:
|
||||
|
||||
@ -48,11 +48,11 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto
|
||||
| **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 Microsoft Entra ID assigned or dynamic groups into the **Windows Autopatch Device Registration** Microsoft Entra ID assigned group when using adding existing device-based Microsoft Entra 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** Microsoft Entra ID assigned group or 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 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 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, 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 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 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 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>Then the second deployment ring set, the software updates-based deployment ring set represented by the following Microsoft Entra 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 Microsoft Entra 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 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 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, 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 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 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 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>Then the second deployment ring set, the software updates-based deployment ring set represented by the following Microsoft Entra 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 Microsoft Entra 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 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 **Active** in the **Registered** tab.</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 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 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 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. |
|
||||
|
||||
@ -86,7 +86,7 @@ The five Microsoft Entra ID assigned groups that are used to organize devices fo
|
||||
| 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. |
|
||||
| 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.
|
||||
|
||||
@ -94,7 +94,7 @@ In the software-based deployment ring set, each deployment ring has a different
|
||||
> 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.
|
||||
> 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#service-based-versus-software-update-based-deployment-rings) so that the service has the proper representation of device diversity across your organization.
|
||||
|
||||
@ -107,15 +107,15 @@ The deployment ring distribution is designed to release software update deployme
|
||||
|
||||
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#service-based-versus-software-update-based-deployment-rings):
|
||||
|
||||
- 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%)**.
|
||||
- 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.
|
||||
|
||||
| Service-based deployment ring | Default Autopatch group deployment ring | Default device balancing percentage | Description |
|
||||
| ----- | ----- | ----- | ----- |
|
||||
| Test | 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. |
|
||||
| Test | 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 | Ring 1 | **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 | Ring 2 | **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 | Ring 3 | 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.|
|
||||
@ -123,17 +123,17 @@ The Windows Autopatch deployment ring calculation occurs during the device reg
|
||||
|
||||
## 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.
|
||||
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 |
|
||||
| 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**.
|
||||
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
|
||||
|
||||
@ -162,7 +162,7 @@ If you don't see the Ring assigned by column change to **Pending** in St
|
||||
|
||||
## 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:
|
||||
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.
|
||||
@ -171,8 +171,8 @@ 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. |
|
||||
| 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>
|
||||
> 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>
|
||||
|
||||
@ -23,7 +23,7 @@ Autopatch groups is a logical container or unit that groups several [Microsoft E
|
||||
|
||||
## Autopatch groups prerequisites
|
||||
|
||||
Before you start managing Autopatch groups, ensure you’ve met the following 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-autopatch-groups) within your organization.
|
||||
- Ensure the following [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) are created in your tenant:
|
||||
@ -32,23 +32,23 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr
|
||||
- Modern Workplace Update Policy [Fast]-[Windows Autopatch]
|
||||
- Modern Workplace Update Policy [Broad]-[Windows Autopatch]
|
||||
- Ensure the following [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) are created in your tenant:
|
||||
- Windows Autopatch – DSS Policy [Test]
|
||||
- Windows Autopatch – DSS Policy [First]
|
||||
- Windows Autopatch – DSS Policy [Fast]
|
||||
- Windows Autopatch – DSS Policy [Broad]
|
||||
- Ensure the following Microsoft Entra ID assigned groups are in your tenant before using Autopatch groups. **Don’t** modify the Microsoft Entra group membership types (Assigned or Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups and causes the Autopatch groups feature and other service-related operations to not work properly.
|
||||
- Windows Autopatch - DSS Policy [Test]
|
||||
- Windows Autopatch - DSS Policy [First]
|
||||
- Windows Autopatch - DSS Policy [Fast]
|
||||
- Windows Autopatch - DSS Policy [Broad]
|
||||
- Ensure the following Microsoft Entra ID assigned groups are in your tenant before using Autopatch groups. **Don't** modify the Microsoft Entra group membership types (Assigned or Dynamic). Otherwise, the Windows Autopatch service won't be able to read the device group membership from these groups and causes the Autopatch groups feature and other service-related operations to not work properly.
|
||||
- Modern Workplace Devices-Windows Autopatch-Test
|
||||
- Modern Workplace Devices-Windows Autopatch-First
|
||||
- Modern Workplace Devices-Windows Autopatch-Fast
|
||||
- Modern Workplace Devices-Windows Autopatch-Broad
|
||||
- Windows Autopatch – Test
|
||||
- Windows Autopatch – Ring1
|
||||
- Windows Autopatch – Ring2
|
||||
- Windows Autopatch – Ring3
|
||||
- Windows Autopatch – Last
|
||||
- Windows Autopatch - Test
|
||||
- Windows Autopatch - Ring1
|
||||
- Windows Autopatch - Ring2
|
||||
- Windows Autopatch - Ring3
|
||||
- Windows Autopatch - Last
|
||||
- Additionally, **don't** modify the Microsoft Entra group ownership of any of the groups above otherwise, Autopatch groups device registration process won't be able to add devices into these groups. If the ownership is modified, you must add the **Modern Workplace Management** enterprise application as the owner of these groups.
|
||||
- For more information, see [assign an owner or member of a group in Microsoft Entra ID](/azure/active-directory/privileged-identity-management/groups-assign-member-owner#assign-an-owner-or-member-of-a-group) for steps on how to add owners to Azure Microsoft Entra groups.
|
||||
- Make sure you have [app-only auth turned on in your Windows Autopatch tenant](../operate/windows-autopatch-maintain-environment.md#windows-autopatch-tenant-actions). Otherwise, the Autopatch groups functionality won’t work properly. Autopatch uses app-only auth to:
|
||||
- Make sure you have [app-only auth turned on in your Windows Autopatch tenant](../operate/windows-autopatch-maintain-environment.md#windows-autopatch-tenant-actions). Otherwise, the Autopatch groups functionality won't work properly. Autopatch uses app-only auth to:
|
||||
- Read device attributes to successfully register devices.
|
||||
- Manage all configurations related to the operation of the service.
|
||||
- Make sure that all device-based Microsoft Entra groups you intend to use with Autopatch groups are created prior to using the feature.
|
||||
@ -86,7 +86,7 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr
|
||||
1. Once the review is done, select **Create** to save your custom Autopatch group.
|
||||
|
||||
> [!CAUTION]
|
||||
> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that’s been already used, you'll receive an error that prevents you from finish creating or editing the Autopatch group (Default or Custom).
|
||||
> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from finish creating or editing the Autopatch group (Default or Custom).
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience.
|
||||
@ -94,13 +94,13 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr
|
||||
## Edit the Default or a Custom Autopatch group
|
||||
|
||||
> [!TIP]
|
||||
> You can't edit an Autopatch group when there's one or more Windows feature update releases targeted to it. If you try to edit an Autopatch group with one or more ongoing Windows feature update releases targeted to it, you get the following informational banner message: "**Some settings are not allowed to be modified as there’s one or more on-going Windows feature update release targeted to this Autopatch group.**"
|
||||
> You can't edit an Autopatch group when there's one or more Windows feature update releases targeted to it. If you try to edit an Autopatch group with one or more ongoing Windows feature update releases targeted to it, you get the following informational banner message: "**Some settings are not allowed to be modified as there's one or more on-going Windows feature update release targeted to this Autopatch group.**"
|
||||
> See [Manage Windows feature update releases](../operate/windows-autopatch-groups-manage-windows-feature-update-release.md) for more information on release and phase statuses.
|
||||
|
||||
**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. 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.
|
||||
@ -111,7 +111,7 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr
|
||||
|
||||
## Rename a Custom Autopatch group
|
||||
|
||||
You **can’t** rename the Default Autopatch group. However, you can rename a Custom Autopatch group.
|
||||
You **can't** rename the Default Autopatch group. However, you can rename a Custom Autopatch group.
|
||||
|
||||
**To rename a Custom Autopatch group:**
|
||||
|
||||
@ -123,7 +123,7 @@ You **can’t** rename the Default Autopatch group. However, you can rename a Cu
|
||||
|
||||
## Delete a Custom Autopatch group
|
||||
|
||||
You **can’t** delete the Default Autopatch group. However, you can 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:**
|
||||
|
||||
@ -131,7 +131,7 @@ You **can’t** delete the Default Autopatch group. However, you can delete a Cu
|
||||
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.
|
||||
> 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 using Autopatch groups
|
||||
|
||||
@ -140,7 +140,7 @@ Overlap in device membership is a common scenario when working with device-based
|
||||
Since Autopatch groups allow you to use your existing Microsoft Entra groups to create your own deployment ring composition, the service takes on the responsibility of monitoring and automatically solving some of the device conflict scenarios that may occur.
|
||||
|
||||
> [!CAUTION]
|
||||
> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that’s been already used, you'll receive an error that prevents you from creating or editing the Autopatch group (Default or Custom).
|
||||
> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from creating or editing the Autopatch group (Default or Custom).
|
||||
|
||||
### Device conflict in deployment rings within an Autopatch group
|
||||
|
||||
@ -162,21 +162,21 @@ Device conflict across different deployment rings in different Autopatch groups
|
||||
|
||||
| Conflict scenario | Conflict resolution |
|
||||
| ----- | ----- |
|
||||
| You, the IT admin at Contoso Ltd., starts using only the Default Autopatch group, but later decides to create an Autopatch group called “Marketing”.<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> |
|
||||
| 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> |
|
||||
| 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 to device registration
|
||||
|
||||
When you create or edit the Custom or Default Autopatch group, Windows Autopatch checks if the devices that are part of the Microsoft Entra groups, used in Autopatch groups’ deployment rings, are registered with the service.
|
||||
When you create or edit the Custom or Default Autopatch group, Windows Autopatch checks if the devices that are part of the Microsoft Entra groups, used in Autopatch groups' deployment rings, are registered with the service.
|
||||
|
||||
| Conflict scenario | Conflict resolution |
|
||||
| ----- | ----- |
|
||||
| Devices are in the Custom-to-Custom Autopatch group device conflict scenario | You must resolve this conflict.<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 Microsoft Entra groups that are used with the Custom Autopatch groups don’t have device membership overlaps.</p> |
|
||||
| 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 Microsoft Entra groups that are used with the Custom Autopatch groups don't have device membership overlaps.</p> |
|
||||
|
||||
#### Device conflict post device registration
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ ms.collection:
|
||||
|
||||
# Windows Autopatch groups overview
|
||||
|
||||
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.
|
||||
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?
|
||||
|
||||
@ -56,7 +56,7 @@ There are a few key concepts to be familiar with before using Autopatch groups.
|
||||
> [!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:
|
||||
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).
|
||||
@ -64,21 +64,21 @@ The Default Autopatch group uses Windows Autopatch’s default update management
|
||||
The Default Autopatch group is intended to serve organizations that are looking to:
|
||||
|
||||
- Enroll into the service
|
||||
- Align to Windows Autopatch’s default update management process without requiring more customizations.
|
||||
- Align to Windows Autopatch's default update management process without requiring more customizations.
|
||||
|
||||
The Default Autopatch group **can’t** be deleted or renamed. However, you can customize its deployment ring composition to add and/or remove deployment rings, and you can also customize the update deployment cadences for each deployment ring within it.
|
||||
The Default Autopatch group **can't** be deleted or renamed. However, you can customize its deployment ring composition to add and/or remove deployment rings, and you can also customize the update deployment cadences for each deployment ring within it.
|
||||
|
||||
#### Default deployment ring composition
|
||||
|
||||
By default, the following [software update-based deployment rings](#software-based-deployment-rings), represented by Microsoft Entra ID assigned groups, are used:
|
||||
|
||||
- Windows Autopatch – Test
|
||||
- Windows Autopatch – Ring1
|
||||
- Windows Autopatch – Ring2
|
||||
- Windows Autopatch – Ring3
|
||||
- Windows Autopatch – Last
|
||||
- Windows Autopatch - Test
|
||||
- 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.
|
||||
**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.
|
||||
@ -86,7 +86,7 @@ By default, the following [software update-based deployment rings](#software-bas
|
||||
> [!CAUTION]
|
||||
> These and other Microsoft Entra ID assigned groups created by Autopatch groups **can't** be missing in your tenant, otherwise, Autopatch groups might not function properly.
|
||||
|
||||
The **Last** deployment ring, the fifth deployment ring in the Default Autopatch group, is intended to provide coverage for scenarios where a group of specialized devices and/or VIP/Executive users. They must receive software update deployments after the organization’s general population to mitigate disruptions to your organization’s critical businesses.
|
||||
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
|
||||
|
||||
@ -144,7 +144,7 @@ Both the **Test** and **Last** deployment rings are default deployment rings tha
|
||||
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.
|
||||
> 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 Microsoft Entra group assignment at a time. If you need to assign more than one Microsoft Entra group, you can nest the other Microsoft Entra groups under the ones you plan to use with the **Test** and **Last** deployment rings. Only one level of Microsoft Entra group nesting is supported.
|
||||
@ -168,7 +168,7 @@ The following are the Microsoft Entra ID assigned groups that represent the serv
|
||||
- Modern Workplace Devices-Windows Autopatch-Broad
|
||||
|
||||
> [!CAUTION]
|
||||
> **Don’t** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly. <p>Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.</p>
|
||||
> **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>
|
||||
|
||||
##### Software-based deployment rings
|
||||
|
||||
@ -177,16 +177,16 @@ The software-based deployment ring set is exclusively used with software update
|
||||
The following are the Microsoft Entra ID assigned groups that represent the software updates-based deployment rings. These groups can't be deleted or renamed:
|
||||
|
||||
- Windows Autopatch - Test
|
||||
- Windows Autopatch – Ring1
|
||||
- Windows Autopatch – Ring2
|
||||
- Windows Autopatch – Ring3
|
||||
- Windows Autopatch – Last
|
||||
- Windows Autopatch - Ring1
|
||||
- Windows Autopatch - Ring2
|
||||
- Windows Autopatch - Ring3
|
||||
- Windows Autopatch - Last
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Additional Microsoft Entra ID assigned groups are created and added to list when you add more deployment rings to the Default Autopatch group.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Don’t** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly. <p>Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.</p>
|
||||
> **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>
|
||||
|
||||
### About device registration
|
||||
|
||||
@ -203,7 +203,7 @@ The following are three common uses for using Autopatch groups.
|
||||
|
||||
| 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 precommunicated 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 preconfigured 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 preconfigured and fully managed by the Windows Autopatch service.</p> |
|
||||
| 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 precommunicated 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 preconfigured 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 preconfigured 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":::
|
||||
|
||||
@ -211,7 +211,7 @@ The following are three common uses for using Autopatch groups.
|
||||
|
||||
| Scenario | Solution |
|
||||
| ----- | ----- |
|
||||
| You’re working as the IT admin at Contoso Ltd. Your organization needs to plan a gradual rollout of software updates within specific critical business units or departments to help mitigate the risk of end-user disruption. | You can create a Custom Autopatch group for each of your business units. For example, you can create a Custom Autopatch group for the finance department and breakdown the deployment ring composition per the different user personas or based on how critical certain user groups can be for the department and then for the business.<p>The following is a visual representation of a gradual rollout for Contoso’s Finance department.</p> |
|
||||
| You're working as the IT admin at Contoso Ltd. Your organization needs to plan a gradual rollout of software updates within specific critical business units or departments to help mitigate the risk of end-user disruption. | You can create a Custom Autopatch group for each of your business units. For example, you can create a Custom Autopatch group for the finance department and breakdown the deployment ring composition per the different user personas or based on how critical certain user groups can be for the department and then for the business.<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":::
|
||||
|
||||
@ -222,7 +222,7 @@ The following are three common uses for using Autopatch groups.
|
||||
|
||||
| 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> |
|
||||
| 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":::
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ ms.collection:
|
||||
# Post-device registration readiness checks (public preview)
|
||||
|
||||
> [!IMPORTANT]
|
||||
> This feature is in "public preview". It is being actively developed, and may not be complete. They're made available on a “Preview” basis. You can test and use these features in production environments and scenarios, and provide feedback.
|
||||
> This feature is in "public preview". It is being actively developed, and may not be complete. They're made available on a "Preview" basis. You can test and use these features in production environments and scenarios, and provide feedback.
|
||||
|
||||
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.
|
||||
|
||||
@ -41,7 +41,7 @@ Device readiness in Windows Autopatch is divided into two different scenarios:
|
||||
| ----- | ----- |
|
||||
| <ul><li>Windows OS (build, architecture and edition)</li></li><li>Managed by either Intune or ConfigMgr co-management</li><li>ConfigMgr co-management workloads</li><li>Last communication with Intune</li><li>Personal or non-Windows devices</li></ul> | <ul><li>Windows OS (build, architecture and edition)</li><li>Windows updates & Office Group Policy Object (GPO) versus Intune mobile device management (MDM) policy conflict</li><li>Bind network endpoints (Microsoft Defender, Microsoft Teams, Microsoft Edge, Microsoft Office)</li><li>Internet connectivity</li></ul> |
|
||||
|
||||
The status of each post-device registration readiness check is shown in the Windows Autopatch’s Devices blade under the **Not ready** tab. You can take appropriate action(s) on devices that aren't ready to be fully managed by the Windows Autopatch service.
|
||||
The status of each post-device registration readiness check is shown in the Windows Autopatch's Devices blade under the **Not ready** tab. You can take appropriate action(s) on devices that aren't ready to be fully managed by the Windows Autopatch service.
|
||||
|
||||
## About the three tabs in the Devices blade
|
||||
|
||||
@ -57,8 +57,8 @@ Windows Autopatch has three tabs within its Devices blade. Each tab is designed
|
||||
| Tab | Description |
|
||||
| ----- | ----- |
|
||||
| Ready | This tab only lists devices with the **Active** status. Devices with the **Active** status successfully:<ul><li>Passed the prerequisite checks.</li><li>Registered with Windows Autopatch.</li></ul>This tab also lists devices that have passed all postdevice registration readiness checks. |
|
||||
| Not ready | This tab only lists devices with the **Readiness failed** and **Inactive** status.<ul><li>**Readiness failed status**: Devices that didn’t pass one or more post-device registration readiness checks.</li><li>**Inactive**: Devices that haven't communicated with the Microsoft Intune service in the last 28 days.</li></ul> |
|
||||
| Not registered | Only lists devices with the **Prerequisite failed** status in it. Devices with the **Prerequisite failed** status didn’t pass one or more prerequisite checks during the device registration process. |
|
||||
| Not ready | This tab only lists devices with the **Readiness failed** and **Inactive** status.<ul><li>**Readiness failed status**: Devices that didn't pass one or more post-device registration readiness checks.</li><li>**Inactive**: Devices that haven't communicated with the Microsoft Intune service in the last 28 days.</li></ul> |
|
||||
| Not registered | Only lists devices with the **Prerequisite failed** status in it. Devices with the **Prerequisite failed** status didn't pass one or more prerequisite checks during the device registration process. |
|
||||
|
||||
## Details about the post-device registration readiness checks
|
||||
|
||||
@ -76,12 +76,12 @@ The following list of post-device registration readiness checks is performed in
|
||||
| ----- | ----- |
|
||||
| **Windows OS build, architecture, and edition** | Checks to see if devices support Windows 1809+ build (10.0.17763), 64-bit architecture and either Pro or Enterprise SKUs. |
|
||||
| **Windows update policies managed via Microsoft Intune** | Checks to see if devices have Windows Updates policies managed via Microsoft Intune (MDM). |
|
||||
| **Windows update policies managed via Group Policy Object (GPO)** | Checks to see if devices have Windows update policies managed via GPO. Windows Autopatch doesn’t support Windows update policies managed via GPOs. Windows update must be managed via Microsoft Intune. |
|
||||
| **Microsoft Office update policy managed via Group Policy Object (GPO)** | Checks to see if devices have Microsoft Office updates policies managed via GPO. Windows Autopatch doesn’t support Microsoft Office update policies managed via GPOs. Office updates must be managed via Microsoft Intune or another Microsoft Office policy management method where Office update bits are downloaded directly from the Office Content Delivery Network (CDN). |
|
||||
| **Windows update policies managed via Group Policy Object (GPO)** | Checks to see if devices have Windows update policies managed via GPO. Windows Autopatch doesn't support Windows update policies managed via GPOs. Windows update must be managed via Microsoft Intune. |
|
||||
| **Microsoft Office update policy managed via Group Policy Object (GPO)** | Checks to see if devices have Microsoft Office updates policies managed via GPO. Windows Autopatch doesn't support Microsoft Office update policies managed via GPOs. Office updates must be managed via Microsoft Intune or another Microsoft Office policy management method where Office update bits are downloaded directly from the Office Content Delivery Network (CDN). |
|
||||
| **Windows Autopatch network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that Windows Autopatch services must be able to reach for the various aspects of the Windows Autopatch service. |
|
||||
| **Microsoft Teams network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that devices with Microsoft Teams must be able to reach for software updates management. |
|
||||
| **Microsoft Edge network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that devices with Microsoft Edge must be able to reach for software updates management. |
|
||||
| **Internet connectivity** | Checks to see if a device has internet connectivity to communicate with Microsoft cloud services. Windows Autopatch uses the PingReply class. Windows Autopatch tries to ping at least three different Microsoft’s public URLs two times each, to confirm that ping results aren't coming from the device’s cache. |
|
||||
| **Internet connectivity** | Checks to see if a device has internet connectivity to communicate with Microsoft cloud services. Windows Autopatch uses the PingReply class. Windows Autopatch tries to ping at least three different Microsoft's public URLs two times each, to confirm that ping results aren't coming from the device's cache. |
|
||||
|
||||
## Post-device registration readiness checks workflow
|
||||
|
||||
@ -93,8 +93,8 @@ See the following diagram for the post-device registration readiness checks work
|
||||
| ----- | ----- |
|
||||
| **Steps 1-7** | For more information, see the [Device registration overview diagram](windows-autopatch-device-registration-overview.md).|
|
||||
| **Step 8: Perform readiness checks** |<ol><li>Once devices are successfully registered with Windows Autopatch, the devices are added to the **Ready** tab.</li><li>The Microsoft Cloud Managed Desktop Extension agent performs readiness checks against devices in the **Ready** tab every 24 hours.</li></ol> |
|
||||
| **Step 9: Check readiness status** |<ol><li>The Microsoft Cloud Managed Desktop Extension service evaluates the readiness results gathered by its agent.</li><li>The readiness results are sent from the Microsoft Cloud Managed Desktop Extension service component to the Device Readiness component within the Windows Autopatch’s service.</li></ol>|
|
||||
| **Step 10: Add devices to the Not ready** | When devices don’t pass one or more readiness checks, even if they’re registered with Windows Autopatch, they’re added to the **Not ready** tab so IT admins can remediate devices based on Windows Autopatch recommendations. |
|
||||
| **Step 9: Check readiness status** |<ol><li>The Microsoft Cloud Managed Desktop Extension service evaluates the readiness results gathered by its agent.</li><li>The readiness results are sent from the Microsoft Cloud Managed Desktop Extension service component to the Device Readiness component within the Windows Autopatch's service.</li></ol>|
|
||||
| **Step 10: Add devices to the Not ready** | When devices don't pass one or more readiness checks, even if they're registered with Windows Autopatch, they're added to the **Not ready** tab so IT admins can remediate devices based on Windows Autopatch recommendations. |
|
||||
| **Step 11: IT admin understands what the issue is and remediates** | The IT admin checks and remediates issues in the Devices blade (**Not ready** tab). It can take up to 24 hours for devices to show back up into the **Ready** tab. |
|
||||
|
||||
## FAQ
|
||||
@ -102,7 +102,7 @@ See the following diagram for the post-device registration readiness checks work
|
||||
| Question | Answer |
|
||||
| ----- | ----- |
|
||||
| **How frequent are the post-device registration readiness checks performed?** |<ul><li>The **Microsoft Cloud Managed Desktop Extension** agent collects device readiness statuses when it runs (once a day).</li><li>Once the agent collects results for the post-device registration readiness checks, it generates readiness results in the device in the `%programdata%\Microsoft\CMDExtension\Plugins\DeviceReadinessPlugin\Logs\DRCResults.json.log`.</li><li>The readiness results are sent over to the **Microsoft Cloud Managed Desktop Extension service**.</li><li>The **Microsoft Cloud Managed Desktop Extension** service component sends the readiness results to the Device Readiness component. The results appear in the Windows Autopatch Devices blade (**Not ready** tab).</li></ul>|
|
||||
| **What to expect when one or more checks fail?** | Devices are automatically sent to the **Ready** tab once they're successfully registered with Windows Autopatch. When devices don’t meet one or more post-device registration readiness checks, the devices are moved to the **Not ready** tab. IT admins can learn about these devices and take appropriate actions to remediate them. Windows Autopatch will provide information about the failure and how to potentially remediate devices.<p>Once devices are remediated, it can take up to **24 hours** to show up in the **Ready** tab.</p>|
|
||||
| **What to expect when one or more checks fail?** | Devices are automatically sent to the **Ready** tab once they're successfully registered with Windows Autopatch. When devices don't meet one or more post-device registration readiness checks, the devices are moved to the **Not ready** tab. IT admins can learn about these devices and take appropriate actions to remediate them. Windows Autopatch will provide information about the failure and how to potentially remediate devices.<p>Once devices are remediated, it can take up to **24 hours** to show up in the **Ready** tab.</p>|
|
||||
|
||||
## Additional resources
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ Windows Autopatch can take over software update management control of devices th
|
||||
|
||||
When you either create/edit a [Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups) or edit the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) to add or remove deployment rings, the device-based Microsoft Entra groups you use when setting up your deployment rings are scanned to see if devices need to be registered with the Windows Autopatch service.
|
||||
|
||||
If devices aren’t registered, Autopatch groups starts the device registration process by using your existing device-based Microsoft Entra groups instead of the Windows Autopatch Device Registration group.
|
||||
If devices aren't registered, Autopatch groups starts the device registration process by using your existing device-based Microsoft Entra groups instead of the Windows Autopatch Device Registration group.
|
||||
|
||||
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.
|
||||
|
||||
@ -178,7 +178,7 @@ The service supports:
|
||||
|
||||
- Personal persistent virtual machines
|
||||
|
||||
The following Azure Virtual Desktop features aren’t supported:
|
||||
The following Azure Virtual Desktop features aren't supported:
|
||||
|
||||
- Multi-session hosts
|
||||
- Pooled non persistent virtual machines
|
||||
|
||||
Reference in New Issue
Block a user