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.
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.
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.
| -| Broad | Either **80%** or **90%** | The Broad ring is the last group of users to receive software update deployments. Since it contains most of the devices registered with Windows Autopatch, it favors stability over speed in a software update deployment.| -| Last | **zero** | The Last ring is intended to be used for either specialized devices or devices that belong to VIP/executives in an organization. Windows Autopatch doesn't automatically add devices to this deployment ring. | +| 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: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.
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.
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.
| +| 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.| +| N/A | Last | **zero** | The Last ring is intended to be used for either specialized devices or devices that belong to VIP/executives in an organization. Windows Autopatch doesn't automatically add devices to this deployment ring. | ## Software update-based to service-based deployment ring mapping diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md index 9831d4850d..c059889d51 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md @@ -1,7 +1,7 @@ --- title: Manage Windows Autopatch groups description: This article explains how to manage Autopatch groups -ms.date: 05/11/2023 +ms.date: 06/05/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: how-to @@ -99,6 +99,10 @@ 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.**" +> 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. @@ -111,6 +115,18 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr > [!IMPORTANT] > Windows Autopatch creates the device-based Azure AD assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience. +## 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:** + +1. Select the **horizontal ellipses (…)** > **Rename** for the Custom Autopatch group you want to rename. The **Rename Autopatch group** fly-in opens. +1. In the **New Autopatch group name**, enter the new Autopatch group name of your choice, then click **Rename group**. + +> [!IMPORTANT] +> Autopatch supports up to 64 characters for the custom Autopatch group name. Additionally, when you rename a custom Autopatch group all [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) associated with the custom Autopatch group are renamed to include the new Autopatch group name you define in its name string. Also, when renaming a custom Autopatch group all Azure AD groups representing the custom Autopatch group's deployment rings are renamed to include the new Autopatch group name you define in its name string. + ## Delete a Custom Autopatch group You **can’t** delete the Default Autopatch group. However, you can delete a Custom Autopatch group. @@ -125,10 +141,6 @@ You **can’t** delete the Default Autopatch group. However, you can delete a Cu ## Manage device conflict scenarios when using Autopatch groups -> [!IMPORTANT] -> The Windows Autopatch groups functionaliy is in **public preview**. This feature is being actively developed and not all device conflict detection and resolution scenarios are working as expected. -> For more information on what to expect for this scenario during public preview, see [Known issues](#known-issues). - Overlap in device membership is a common scenario when working with device-based Azure AD groups since sometimes dynamic queries can be large in scope or the same assigned device membership can be used across different Azure AD groups. Since Autopatch groups allow you to use your existing Azure AD groups to create your own deployment ring composition, the service takes on the responsibility of monitoring and automatically solving some of the device conflict scenarios that may occur. @@ -180,22 +192,6 @@ Autopatch groups will keep monitoring for all device conflict scenarios listed i This section lists known issues with Autopatch groups during its public preview. -### Device conflict scenarios when using Autopatch groups - -- **Status: Active** - -The Windows Autopatch team is aware that all device conflict scenarios listed below are currently being evaluated during the device registration process to make sure devices are properly registered with the service, and not evaluated post-device registration. The Windows Autopatch team is currently developing detection and resolution for the followin device conflict scenarios, and plan to make them available during public preview. - -- Default to Custom Autopatch device conflict detection and resolution. -- Device conflict detection and resolution within an Autopatch group. -- Custom to Custom Autopatch group device conflict detection. - -> [!TIP] -> Use the following two best practices to help minimize device conflict scenarios when using Autopatch groups during the public preview: -> -> - Review your software update deployment requirements thoroughly. If your deployment requirements allow, try using the Default Autopatch group as much as possible, instead of start creating Custom Autopatch groups. You can customize the Default Autopatch to have up to 15 deployment rings, and you can use your existing device-based Azure AD groups with custom update deployment cadences. -> - If creating Custom Autopatch groups, try to avoid using device-based Azure AD groups that have device membership overlaps with the devices that are already registered with Windows Autopatch, and already belong to the Default Autopatch group. - ### Autopatch group Azure AD group remediator - **Status: Active** @@ -219,12 +215,3 @@ The Windows Autopatch team is currently developing the Autopatch group Azure AD > - Modern Workplace Devices-Windows Autopatch-Broad > > Use the [Policy health feature](../operate/windows-autopatch-policy-health-and-remediation.md) to restore these groups, if needed. For more information, see [restore deployment groups](../operate/windows-autopatch-policy-health-and-remediation.md#restore-deployment-groups). - -### Rename an Autopatch group - -- **Status: Active** - -You can't rename an Autopatch group yet. The Autopatch group name is appended to all deployment ring names in the Autopatch group. Windows Autopatch is currently developing the rename feature. - -> [!IMPORTANT] -> During the public preview, if you try to rename either the [Update rings](/mem/intune/protect/windows-10-update-rings) or [feature updates](/mem/intune/protect/windows-10-feature-updates) for Windows 10 and later policies directly in the Microsoft Intune end-user experience, the policy names are reverted back to the name defined by the Autopatch group end-user experience interface. diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-manage-windows-feature-update-release.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-manage-windows-feature-update-release.md index fab7bbabbc..8323fdbc22 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-manage-windows-feature-update-release.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-manage-windows-feature-update-release.md @@ -91,6 +91,7 @@ The release statuses are described in the following table: | Active | All phases in the release are active. This means all phases have reached their first deployment date, which created the Windows feature update policies. |A global Windows feature update policy is automatically assigned behind the scenes to the newly added deployment rings or when you assigned Azure AD groups to the deployment ring (Last) in the Default Autopatch group.
| | Scenario #2 | You create new [Custom Autopatch groups](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group).The global Windows feature policy is automatically assigned behind the scenes to all deployment rings as part of the Custom Autopatch groups you create.
| +> [!NOTE] +> Global releases don't show up in the Windows feature updates release management blade. + #### Policy configuration values See the following table on how Windows Autopatch configures the values for its global Windows feature update policy. If your tenant is enrolled with Windows Autopatch, you can see the following default policies created by the service in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431):