deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 21:37:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge branch 'main' of https://github.com/MicrosoftDocs/windows-docs-pr into uc-wkbk

Browse Source
This commit is contained in:
Meghan Stewart 2022-08-08 08:58:19 -07:00
commit ae8fd15bda
5 changed files with 88 additions and 61 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,7 +1,7 @@
---
title: Register your devices
description: This article details how to register devices in Autopatch
ms.date: 08/04/2022
ms.date: 08/08/2022
ms.prod: w11
ms.technology: windows
ms.topic: how-to
@ -18,7 +18,7 @@ Before Microsoft can manage your devices in Windows Autopatch, you must have dev
## Before you begin
Windows Autopatch can take over software update management of supported devices as soon as an IT admin decides to have their tenant managed by the service. The Windows Autopatch software update management scope includes:
Windows Autopatch can take over software update management control of devices that meet software-based prerequisites as soon as an IT admin decides to have their tenant managed by the service. The Windows Autopatch software update management scope includes the following software update workloads:
- [Windows quality updates](../operate/windows-autopatch-wqu-overview.md)
- [Windows feature updates](../operate/windows-autopatch-fu-overview.md)
@ -31,7 +31,7 @@ Windows Autopatch can take over software update management of supported devices
You must choose what devices to manage with Windows Autopatch by either adding them through direct membership or by nesting other Azure AD dynamic/assigned groups into the **Windows Autopatch Device Registration** Azure AD assigned group. Windows Autopatch automatically runs its discover devices function every hour to discover new devices added to this group. Once new devices are discovered, Windows Autopatch attempts to register these devices.
> [!NOTE]
> Devices that are intended to be managed by the Windows Autopatch service **must** be added into the **Windows Autopatch Device Registration** Azure AD assigned group. Devices can only be added to this group if they have an Azure AD device ID. Windows Autopatch scans the Azure AD group hourly to discover newly added devices to be registered. You can also use the **Discover devices** button in either the Ready or Not ready tab to register devices on demand.
> Devices that are intended to be managed by the Windows Autopatch service **must** be added into the **Windows Autopatch Device Registration** Azure AD assigned group. Devices can only be added to this group if they have an Azure AD device ID. Windows Autopatch scans the Azure AD group hourly to discover newly added devices to be registered. You can also use the **Discover devices** button in either the **Ready** or **Not ready** tab to register devices on demand.
#### Supported scenarios when nesting other Azure AD groups
@ -48,9 +48,6 @@ Azure AD groups synced up from:
> [!IMPORTANT]
> The **Windows Autopatch Device Registration** Azure AD group only supports one level of Azure AD nested groups.
> [!TIP]
> You can also use the **Discover Devices** button in either the Ready or Not ready tab to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand.
### Clean up dual state of Hybrid Azure AD joined and Azure registered devices in your Azure AD tenant
An [Azure AD dual state](/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state) occurs when a device is initially connected to Azure AD as an [Azure AD Registered](/azure/active-directory/devices/concept-azure-ad-register) device. However, when you enable Hybrid Azure AD join, the same device is connected twice to Azure AD but as a [Hybrid Azure AD device](/azure/active-directory/devices/concept-azure-ad-join-hybrid).
@ -66,7 +63,7 @@ It's recommended to detect and clean up stale devices in Azure AD before registe
To be eligible for Windows Autopatch management, devices must meet a minimum set of required software-based prerequisites:
- Windows 10 (1809+)/11 Enterprise and Professional edition versions (only x64 architecture).
- Windows 10 (1809+)/11 Enterprise or Professional editions (only x64 architecture).
- Either [Hybrid Azure AD-Joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or [Azure AD-joined only](/azure/active-directory/devices/concept-azure-ad-join-hybrid) (personal devices aren't supported).
- Managed by Microsoft Endpoint Manager.
- [Microsoft Intune](https://www.microsoft.com/cloud-platform/microsoft-intune) and/or [Configuration Manager Co-management](/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites#configuration-manager-co-management-requirements).
@ -105,33 +102,39 @@ For more information, see [Azure AD built-in roles](/azure/active-directory/role
## Details about the device registration process
Registering your devices in Windows Autopatch does the following:
Registering your devices with Windows Autopatch does the following:
1. Makes a record of devices in the service.
2. Assign devices into the deployment ring groups and other groups required for software updates management.
2. Assign devices to the [deployment rings](../operate/windows-autopatch-update-management.md) and other groups required for software update management.
For more information, see [Device registration overview](../deploy/windows-autopatch-device-registration-overview.md).
## Steps to register devices
Any device (either physical or virtual) that contains an Azure AD device ID can be added into the **Windows Autopatch Device Registration** Azure AD group to be registered with Windows Autopatch.
Any device (either physical or virtual) that contains an Azure AD device ID, can be added into the **Windows Autopatch Device Registration** Azure AD group through either direct membership or by being part of another Azure AD group (either dynamic or assigned) that's nested to this group, so it can be registered with Windows Autopatch. The only exception is new Windows 365 Cloud PCs, as these virtual devices must be registered with Windows Autopatch from the Windows 365 provisioning policy. For more information, see [Windows Autopatch on Windows 365 Enterprise Workloads](#windows-autopatch-on-windows-365-enterprise-workloads).
Since existing Windows 365 Cloud PCs already have an existing Azure AD device ID, these devices can be added into the **Windows Autopatch Device Registration** Azure group through either direct membership or by being part of another Azure AD group (either dynamic or assigned) that's nested to this group.
**To register physical devices into Windows Autopatch:**
**To register devices with Windows Autopatch:**
1. Go to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/).
2. Select **Windows Autopatch** from the left navigation menu.
3. Select **Devices**.
4. Select the **Ready** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
5. Add either devices through direct membership, or other Azure Active Directory dynamic or assigned groups as nested groups in the **Windows Autopatch Device Registration** group.
4. Select either the **Ready** or the **Not ready** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
5. Add either devices through direct membership, or other Azure AD dynamic or assigned groups as nested groups in the **Windows Autopatch Device Registration** group.
> [!NOTE]
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Ready tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both Ready and Not ready tabs.
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Ready tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both **Ready** and **Not ready** tabs.
Once devices or Azure AD groups containing devices are added to the **Windows Autopatch Device Registration** group, Windows Autopatch discovers these devices, and runs software-based prerequisite checks to try to register them with its service.
Once devices or other Azure AD groups (either dynamic or assigned) containing devices are added to the **Windows Autopatch Device Registration** group, Windows Autopatch's device discovery hourly function discovers these devices, and runs software-based prerequisite checks to try to register them with its service.
> [!TIP]
> You can also use the **Discover Devices** button in either the **Ready** or **Not ready** tab to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand.
### Windows Autopatch on Windows 365 Enterprise Workloads
With Windows 365 Enterprise, IT admins are given the option to register devices with the Windows Autopatch service as part of the Windows 365 provisioning policy creation. This option provides a seamless experience for admins and users to ensure your Cloud PCs are always up to date. When IT admins decide to manage their Windows 365 Cloud PCs with Windows Autopatch, the Windows 365 provisioning policy creation process calls Windows Autopatch device registration APIs to register devices on behalf of the IT admin.
Windows 365 Enterprise gives IT admins the option to register devices with the Windows Autopatch service as part of the Windows 365 provisioning policy creation. This option provides a seamless experience for admins and users to ensure your Cloud PCs are always up to date. When IT admins decide to manage their Windows 365 Cloud PCs with Windows Autopatch, the Windows 365 provisioning policy creation process calls Windows Autopatch device registration APIs to register devices on behalf of the IT admin.
**To deploy Windows Autopatch on a Windows 365 Provisioning Policy:**
**To register new Windows 365 Cloud PC devices with Windows Autopatch from the Windows 365 Provisioning Policy:**
1. Go to the [Microsoft Endpoint Manager](https://endpoint.microsoft.com/) admin center.
1. In the left pane, select **Devices**.
@ -144,12 +147,7 @@ With Windows 365 Enterprise, IT admins are given the option to register devices
1. Assign your policy accordingly and select **Next**.
1. Select **Create**. Now your newly provisioned Windows 365 Enterprise Cloud PCs will automatically be enrolled and managed by Windows Autopatch.
For general guidance, see [Create a Windows 365 Provisioning Policy](/windows-365/enterprise/create-provisioning-policy).
#### Deploy Autopatch on Windows 365 for existing Cloud PC
All your existing Windows 365 Enterprise workloads can be registered into Windows Autopatch by leveraging the same method for any other physical or virtual device. See [steps to register devices](#steps-to-register-devices) for more details.
For more information, see [Create a Windows 365 Provisioning Policy](/windows-365/enterprise/create-provisioning-policy).
### Contact support for device registration-related incidents
Support is available either through Windows 365, or the Windows Autopatch Service Engineering team for device registration-related incidents.

4
windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft 365 Apps for enterprise
description: This article explains how Microsoft 365 Apps for enterprise updates are managed in Windows Autopatch
ms.date: 05/30/2022
ms.date: 08/08/2022
ms.prod: w11
ms.technology: windows
ms.topic: conceptual
@ -88,7 +88,7 @@ Since quality updates are bundled together into a single release in the [Monthly
A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other management tools, such as Microsoft Endpoint Manager or the Office Deployment Tool. This means that the servicing profile will affect all devices that meet the [device eligibility requirements](#device-eligibility) regardless of existing management tools in your environment. So, if you're targeting a managed device with a servicing profile it will be ineligible for Microsoft 365 App update management.
However, the device may still be eligible for other managed updates. For more information about a device's eligibility for a given [update type](windows-autopatch-update-management.md#update-types), see the Device eligibility section of each respective update type.
However, the device may still be eligible for other managed updates. For more information about a device's eligibility for a given [software update workload](windows-autopatch-update-management.md#software-update-workloads), see the Device eligibility section of each respective software update workload.
## Incidents and outages

89
windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md
View File

@ -1,7 +1,7 @@
---
title: Update management
title: Software update management
description: This article provides an overview of how updates are handled in Autopatch
ms.date: 05/30/2022
ms.date: 08/08/2022
ms.prod: w11
ms.technology: windows
ms.topic: overview
@ -9,16 +9,16 @@ ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: dougeby
msreviewer: hathind
msreviewer: andredm7
---
# Update management
# Software update management
Keeping your devices up to date is a balance of speed and stability. Windows Autopatch connects all devices to a modern cloud-based infrastructure to manage updates.
Keeping your devices up to date is a balance of speed and stability. Windows Autopatch connects all devices to a modern cloud-based infrastructure to manage updates on your behalf.
## Update types
## Software update workloads
| Update type | Description |
| Software update workload | Description |
| ----- | ----- |
| Windows quality update | Windows Autopatch uses four update rings to manage Windows quality updates. For more detailed information, see [Windows quality updates](../operate/windows-autopatch-wqu-overview.md). |
| Windows feature update | Windows Autopatch uses four update rings to manage Windows feature updates. For more detailed information, see [Windows feature updates](windows-autopatch-fu-overview.md).
@ -27,44 +27,73 @@ Keeping your devices up to date is a balance of speed and stability. Windows Aut
| Microsoft Edge | For more information, see [Microsoft Edge](../operate/windows-autopatch-edge.md). |
| Microsoft Teams | For more information, see [Microsoft Teams](../operate/windows-autopatch-teams.md). |
## Update rings
## Windows Autopatch deployment rings
During the [tenant enrollment process](../prepare/windows-autopatch-enroll-tenant.md), Windows Autopatch creates four Azure AD assigned groups that are used to segment devices into its deployment rings:
| Ring | Description |
| ----- | ----- |
| **Modern Workplace Devices-Windows Autopatch-Test** | Deployment ring for testing update 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. |
Each deployment ring has a different set of update deployment policies to control the updates rollout.
> [!IMPORTANT]
> Windows Autopatch device registration doesn't assign devices to its test deployment ring (**Modern Workplace Devices-Windows Autopatch-Test**). 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.
Also, during the [device registration process](../deploy/windows-autopatch-device-registration-overview.md), Windows Autopatch assigns each device being registered to one of its deployment rings so that the service has the proper representation of the device diversity across the organization in each deployment ring. The deployment ring distribution is designed to release software update deployments to as few devices as possible to get the signals needed to make a quality evaluation of a given update deployment.
> [!NOTE]
> Update rings only apply to Windows quality updates.
> Windows Autopatch deployment rings only apply to Windows quality updates. Additionally, you can't create additional deployment rings or use your own for devices managed by the Windows Autopatch service.
During enrollment, Windows Autopatch creates four Azure Active Directory groups that are used to segment devices into update rings:
### Deployment ring calculation logic
1. Modern Workplace Devices - Test
2. Modern Workplace Devices - First
3. Modern Workplace Devices - Fast
4. Modern Workplace Devices - Broad
The Windows Autopatch deployment ring calculation happens during the [device registration process](../deploy/windows-autopatch-device-registration-overview.md) and it works as follows:
Each of the update rings has a different purpose and assigned a set of policies to control the rollout of updates in each management area.
- 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%)**.
When a device is enrolled into the Windows Autopatch service, the device is assigned to an update ring so that we have the right distributions across your estate. The distribution of each ring is designed to release to as few devices as possible to get the signals needed to make a quality evaluation of a given release.
> [!NOTE]
> You can't create additional rings for managed devices and must use the four rings provided by Windows Autopatch.
| Ring | Default device count | Description
| Deployment ring | Default device balancing percentage | Description |
| ----- | ----- | ----- |
| Test | zero | Windows Autopatch doesn't automatically add devices to this ring. You must manually add devices to the Test ring. 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: min 50 devices</li></ul>Devices in this group are intended for your IT Administrators and testers since changes are released here first. This release schedule provides your organization the opportunity to validate updates prior to reaching production users. |
| First | 1% | The First ring is the first group of production users to receive a change.<p><p>This group is the first set of devices to send data to Windows Autopatch and are used to generate a health signal across all customers. For example, we can generate a statistically significant signal saying that critical errors are trending up in a specific release for all customers but can't be confident that it's doing so in your environment.<p><p>Since Windows Autopatch doesn't yet have sufficient data to inform a release decision, devices in this ring might experience outages if there are scenarios that weren't covered during 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 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 | 90% | The Broad ring is the last group of users to receive changes. Since it contains most of the devices enrolled in Windows Autopatch, it favors stability over speed in deployment.|
| Test | **zero** | Windows Autopatch doesn't automatically add devices to this deployment ring. You must manually add devices to the Test ring. The recommended number of devices in this ring, based upon your environment size, is as follows:<br><ul><li>**0–500** devices: minimum **one** device.</li><li>**500–5000** devices: minimum **five** devices.</li><li>**5000+** devices: minimum **50** devices.</li></ul>Devices in this group are intended for your IT Administrators and testers since changes are released here first. This release schedule provides your organization the opportunity to validate updates prior to reaching production users. |
| First | **1%** | The First ring is the first group of production users to receive a change.<p><p>This group is the first set of devices to send data to Windows Autopatch and are used to generate a health signal across all end-users. For example, Windows Autopatch can generate a statistically significant signal saying that critical errors are trending up in a specific release for all end-users, but can't be confident that it's doing so in your organization.<p><p>Since Windows Autopatch doesn't yet have sufficient data to inform a release decision, devices in this deployment ring might experience outages if there are scenarios that weren't covered during early testing in the Test ring.|
| Fast | **9%** | The Fast ring is the second group of production users to receive changes. The signals from the First ring are considered as a part of the release process to the Broad ring.<p><p>The goal with this deployment ring is to cross the **500**-device threshold needed to generate statistically significant analysis at the tenant level. These extra devices allow Windows Autopatch to consider the effect of a release on the rest of your devices and evaluate if a targeted action for your tenant is needed.</p> |
| Broad | Either **80%** or **90%** | The Broad ring is the last group of users to receive software update deployments. Since it contains most of the devices registered with Windows Autopatch, it favors stability over speed in an software update deployment.|
## Moving devices between rings
## Moving devices in between deployment rings
If you want to move separate devices to different rings, repeat the following steps for each device:
If you want to move separate devices to different deployment rings, after Windows Autopatch's deployment ring assignment, you can repeat the following steps for one or more devices from the **Ready** tab.
**To move devices in between deployment rings:**
1. In Microsoft Endpoint Manager, select **Devices** in the left pane.
2. In the **Windows Autopatch** section, select **Devices**.
3. Select the devices you want to assign. All selected devices will be assigned to the ring you specify.
3. In the **Ready** tab, select one or more devices you want to assign. All selected devices will be assigned to the deployment ring you specify.
4. Select **Device actions** from the menu.
5. Select **Assign device to ring**. A fly-in opens.
6. Use the dropdown menu to select the ring to move devices to, and then select **Save**. The **Ring assigned by** column will change to **Pending**.
6. Use the dropdown menu to select the deployment ring to move devices to, and then select **Save**. The **Ring assigned by** column will change to **Pending**.
When the assignment is complete, the **Ring assigned by** column will change to Admin (indicates that you made the change) and the **Ring** column will show the new ring assignment.
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.
> [!NOTE]
> You can't move devices to other rings if they're in the "error" or "pending" registration state.<p>If a device hasn't been properly removed, it could show a status of "ready." If you move such a device, it's possible that the move won't be complete. If you don't see the **Ring assigned by column** change to **Pending** in Step 5, check that the device is available by searching for it in Intune. For more information, see [Device details in Intune](/mem/intune/remote-actions/device-inventory).
> You can only move devices to other deployment rings when they're in an active state in the **Ready** tab.<p>If you don't see the **Ring assigned by column** change to **Pending** in Step 5, check to see whether the device exists in Microsoft Endpoint Manager-Intune or not by searching for it in its device blade. For more information, see [Device details in Intune](/mem/intune/remote-actions/device-inventory).
## Automated deployment ring remediation functions
Windows Autopatch monitors device membership in its deployment rings, except for the **Modern Workplace Devices-Windows Autopatch-Test** ring, 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 rings assigned during the [device registration process](../deploy/windows-autopatch-device-registration-overview.md).
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, for some reason, 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** ring). |
| **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** ring). If, for some reason, a device is part of multiple deployment rings, Windows Autopatch randomly removes device of one or more deployment rings until the device is only part of one deployment ring.|
> [!IMPORTANT]
> Windows Autopatch automated deployment ring functions doesn't assign or remove devices to or from the **Modern Workplace Devices-Windows Autopatch-Test** ring.

6
windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md
View File

@ -1,7 +1,7 @@
---
title: Windows quality updates
description: This article explains how Windows quality updates are managed in Autopatch
ms.date: 05/30/2022
ms.date: 08/08/2022
ms.prod: w11
ms.technology: windows
ms.topic: conceptual
@ -37,7 +37,7 @@ For a device to be eligible for Windows quality updates as a part of Windows Aut
Windows Autopatch deploys the [B release of Windows quality updates](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/windows-quality-updates-primer/ba-p/2569385) that are released on the second Tuesday of each month.
To release updates to devices in a gradual manner, Windows Autopatch deploys a set of mobile device management (MDM) policies to each update ring to control the rollout. There are three primary policies that are used to control Windows quality updates:
To release updates to devices in a gradual manner, Windows Autopatch deploys a set of mobile device management (MDM) policies to each update deployment ring to control the rollout. There are three primary policies that are used to control Windows quality updates:
| Policy | Description |
| ----- | ----- |
@ -48,7 +48,7 @@ To release updates to devices in a gradual manner, Windows Autopatch deploys a s
> [!IMPORTANT]
> Deploying deferral, deadline, or grace period policies which conflict with Autopatch's policies will cause a device to be considered ineligible for management, it will still receive policies from Windows Autopatch that are not in conflict, but may not function as designed. These devices will be marked as ineligible in our device reporting and will not count towards our [service level objective](#service-level-objective).
Windows Autopatch configures these policies differently across update rings to gradually release the update to devices in your estate. Devices in the Test ring receive changes first and devices in the Broad ring receive changes last. For more information, see [Update rings](../operate/windows-autopatch-update-management.md#update-rings).
Windows Autopatch configures these policies differently across update rings to gradually release the update to devices in your estate. Devices in the Test ring receive changes first and devices in the Broad ring receive changes last. For more information, see [Windows Autopatch deployment rings](../operate/windows-autopatch-update-management.md#windows-autopatch-deployment-rings).
:::image type="content" source="../media/release-process-timeline.png" alt-text="Release process timeline":::

6
windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
View File

@ -4,7 +4,7 @@ metadata:
description: Answers to frequently asked questions about Windows Autopatch.
ms.prod: w11
ms.topic: faq
ms.date: 07/06/2022
ms.date: 08/08/2022
audience: itpro
ms.localizationpriority: medium
manager: dougeby
@ -96,9 +96,9 @@ sections:
- question: Can you customize the scheduling of an update rollout to only install on certain days and times?
answer: |
No, you can't customize update scheduling. However, you can specify [active hours](../operate/windows-autopatch-wqu-end-user-exp.md#servicing-window) to prevent users from updating during business hours.
- question: Does Autopatch support include and exclude groups, or dynamic groups to define ring membership?
- question: Does Autopatch support include and exclude groups, or dynamic groups to define deployment ring membership?
answer: |
Windows autopatch doesn't support managing update ring membership using your Azure AD groups. For more information, see [Move devices between rings](../operate/windows-autopatch-update-management.md#moving-devices-between-rings).
Windows autopatch doesn't support managing update deployment ring membership using your Azure AD groups. For more information, see [Moving devices in between deployment rings](../operate/windows-autopatch-update-management.md#moving-devices-in-between-deployment-rings).
- question: Does Autopatch have two release cadences per update or are there two release cadences per-ring?
answer: |
The release cadences are defined based on the update type. For example, a [regular cadence](../operate/windows-autopatch-wqu-overview.md#windows-quality-update-releases) (for a Windows quality update would be a gradual rollout from the Test ring to the Broad ring over 14 days whereas an [expedited release](../operate/windows-autopatch-wqu-overview.md#expedited-releases) would roll out more rapidly.