Every business is now very much aware of the very real threats of attacks that are lurking out there. And for any that aren’t aware, then those threats are even greater. Time and again, we hear of businesses under cyber attacks and critical data compromised. With this in mind, we all need to be looking at ways to enhance our data security.
Otherwise, your business could soon fall victim to hackers. Given the multitude of threats that businesses are constantly dealing with, Microsoft has introduced Windows Autopatch to help improve security. This solution intends to streamline the update process, thus enabling businesses to operate better. In this business solutions article, we will be exploring Windows Autopatch groups and how they function.
Windows Autopatch Recap
For the benefit of those who may not yet be familiar with the service, I’m going to start by going over what Windows Autopatch is. IT admins can attest to the challenges that they sometimes face when it comes to keeping the devices in their environments up to date. Although service providers may offer updates regularly, the process of implementing these updates can sometimes present plenty of challenges to IT staff.
With that in mind, what you get with Windows Autopatch is a cloud-based service that seeks to automate the updates for Windows, Microsoft 365 Apps for Enterprise, Microsoft Teams, and Microsoft Edge.
Due to the automation of these updates, your business can expect to improve security and productivity across the organization. Over the years, we have grown accustomed to getting regular updates. Despite that, the process of implementing them is not always a seamless one. And that’s in addition to the plethora of other tasks that IT admins are responsible for managing. The Windows Autopatch solution gives you a more reliable update method that improves efficiency.
Windows Autopatch Groups
Additionally, Windows Autopatch uses groups to better manage updates in a way that minimizes issues and improves the experience for your business. Autopatch groups, by definition, are logical containers or units that bring together several Azure AD groups and software update policies. These include:
- Update rings policy for Windows 10 and later,
- Feature updates for Windows 10 and other later policies.
BENEFITS OF AUTOPATCH GROUPS
Windows Autopatch aims to adapt to the needs of businesses that are using Microsoft Cloud-Managed services. It is going to meet you wherever you may be in your update management journey. The first benefit that you’ll be able to get from Autopatch groups is that they can replicate your organizational structure.
What this means is that you can set up Autopatch groups to replicate your organizational structures represented by your existing device-based Azure AD group targeting logic. Furthermore, the use of Autopatch groups allows you to choose which software update deployment cadence is most ideal for your business.
Another benefit is a flexible number of deployments. As a result of this flexibility, you get to have the ideal number of deployment rings that will work perfectly for your business. Depending on your needs, you can have as many as 15 deployment rings per Autopatch group.
The next benefit you’ll get is being able to decide which device or devices will belong to deployment rings. In addition to your existing device-based Azure AD groups, as well as choosing the number of deployment rings, your business also has the option to select which devices belong to deployment rings during the device registration process when setting up Autopatch groups.
AUTOPATCH GROUPS WORKFLOW
There are a few steps in this high-level workflow, including these below:
- The first step requires the creation of an Autopatch group.
- Next, the Windows Autopatch service is going to leverage Microsoft Graph to facilitate the creation of:
- Azure AD groups.
- Software update policy assignments with other Microsoft services, such as Azure AD, Intune, and Windows Update for Business (WUfB,) based on IT admin choices when you create or edit an Autopatch group.
- Intune assigns software update policies. You’re going to find that Intune assigns the software update policies to these groups as soon as the Azure AD groups become available in the Azure AD service. In addition, Intune will also provide the number of devices that need the software update policies to the Windows Update for Business (WUfB) service.
- Lastly, we’ll go over the Windows Update for Business responsibilities and these include:
- Delivering update policies.
- Retrieving update deployment statuses back from devices.
- Sending back the status information to Microsoft Intune and then to the Windows Autopatch service
Things to know
Before you can proceed to use Windows Autopatch groups, there are a few key concepts that you’ll need to familiarize yourself with.
DEFAULT AUTOPATCH GROUP
If your organization can meet its business needs using the pre-configured five-deployment ring composition, then you are the ideal candidate for the Default Autopatch group. The group has the intention of serving businesses that want to enroll in the service as well as those that want to align to Autopatch’s default update management process without the need for additional customizations. Furthermore, this group uses Windows Autopatch’s default update management process recommendation and contains:
- A set of 5 deployment rings.
- A default update deployment cadence for both Windows feature and quality updates.
You should also note that you cannot delete or rename the Autopatch group. But you do still get the option to customize its deployment ring composition to add and/or remove deployment rings. Additionally, you can customize the update deployment cadences for each deployment within it.
Default deployment ring composition
The software update-based deployment rings that will be used are determined by default. These deployment rings, represented by Azure AD assigned groups, are as follows:
| Deployment ring | Use |
| Windows Autopatch – Test | Can only be used as Assigned device distributions. |
| Windows Autopatch – Ring1 | Can be used with either Assigned or Dynamic device distributions or have a combination of both device distribution types. |
| Windows Autopatch – Ring2 | Can be used with either Assigned or Dynamic device distributions or have a combination of both device distribution types. |
| Windows Autopatch – Ring3 | Can be used with either Assigned or Dynamic device distributions or have a combination of both device distribution types. |
| Windows Autopatch – Last | Can only be used as Assigned device distributions. |
An additional thing to note for instances where a group of specialized devices and/or VIP/Executive users coverage is provided by the Last deployment ring, the fifth deployment ring in the Default Autopatch group. Furthermore, to minimize any potential disruptions that your business may encounter, software updates for the aforementioned should be received after the organization’s general population.
Default update deployment cadences
Default update deployment cadences are going to be provided by the Default Autopatch group for deployment rings, with the exception of the Last (fifth) deployment ring.
Update rings policy for Windows 10 and later
Each of the default rings in the Default Autopatch group is going to get Update rings policy for Windows 10 and later set up by Windows Autopatch groups. Below is some data concerning the default policy values:
| Policy name | Azure AD group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline |
| Windows Autopatch Update Policy – default – Test | Windows Autopatch – Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes |
| Windows Autopatch Update Policy – default – Ring1 | Windows Autopatch – Ring1 | 1 | 0 | 30 | 2 | 5 | 2 | Yes |
| Windows Autopatch Update Policy – default – Ring2 | Windows Autopatch – Ring2 | 6 | 0 | 30 | 2 | 5 | 2 | Yes |
| Windows Autopatch Update Policy – default – Ring3 | Windows Autopatch – Ring3 | 9 | 0 | 30 | 5 | 5 | 2 | Yes |
| Windows Autopatch Update Policy – default – Last | Windows Autopatch – Last | 11 | 0 | 30 | 3 | 5 | 2 | Yes |
Feature update policy for Windows 10 and later
Each of the default rings in the Default Autopatch group is going to get feature updates for Windows 10 and later set up by Windows Autopatch groups. Below is some data concerning the default policy values:
| Policy name | Azure AD group assignment | Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date |
| Windows Autopatch – DSS Policy [Test] | Windows Autopatch – Test | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024; 1:00AM |
| Windows Autopatch – DSS Policy [Ring1] | Windows Autopatch – Ring1 | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024; 1:00AM |
| Windows Autopatch – DSS Policy [Ring2] | Windows Autopatch – Ring2 | Windows 10 21H2 | Make update available as soon as possible | December 14, 2022 | December 21, 2022 | 1 | June 11, 2024; 1:00AM |
| Windows Autopatch – DSS Policy [Ring3] | Windows Autopatch – Ring3 | Windows 10 21H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | June 11, 2024; 1:00AM |
| Windows Autopatch – DSS Policy [Last] | Windows Autopatch – Last | Windows 10 21H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | June 11, 2024; 1:00AM |
CUSTOM AUTOPATCH GROUPS
If your business needs a more precise representation of its structures as well as its own update cadence in the service, then the Custom Autopatch groups are ideal for you. You’ll also find that the Test and Last deployment rings are automatically present by default.
TEST AND LAST DEPLOYMENT RINGS
Both of these are default deployment rings, and they will be automatically present in both the Default Autopatch group and Custom Autopatch groups. These deployment rings are an essential component because they allow the recommended minimum number of deployment rings needed by each Autopatch group to be provided. In a couple of instances, you’ll find that the Test deployment ring can serve as the pilot deployment ring, with the Last serving as the production deployment ring. This can happen:
- If only the Test and Last deployment rings are within your Default Autopatch group.
- If at the time you are creating a Custom Autopatch group, you don’t add more deployment rings.
Something else that you need to know is that you cannot remove or even rename the Test and Last deployment rings from the Default or Custom Autopatch groups. Because these Autopatch groups require a minimum of 2 deployment rings for their gradual rollout, they won’t support using a single deployment ring as part of its deployment ring composition.
So, you will need to consider managing devices outside Windows Autopatch whenever you have a specific scenario that you want to implement using a single deployment ring and where the gradual rollout is not necessary.
Deployment rings
Autopatch groups intend to have software update deployments delivered sequentially in a gradual rollout within the. Autopatch group. Deployment rings are the tools that make this possible. Windows Autopatch can align with Azure AD and Intune terminology for device group management. As far as deployment ring group distribution in Autopatch groups is concerned, there are two types that you need to know about:
| Deployment ring distribution | Description |
| Dynamic | For this situation, one or more device-based Azure AD groups can be used. And these can be either dynamic query-based or assigned to use in your deployment ring composition. Moreover, you can use the Azure AD groups that are available with the Dynamic distribution type for the distribution of devices across several deployment rings according to the percentage values that can be customized. |
| Assigned | For this type of deployment ring distribution, a single device-based Azure AD group is best. And this can be either dynamic query-based or assigned to use in your deployment ring composition. |
| Combination of Dynamic and Assigned | In some cases, you’ll find yourself needing a greater level of flexibility when working on deployment ring compositions. And this option will prove to be the most ideal. It allows you to combine both device distribution types in Autopatch groups. You will, however, need to note that this particular combination of device distribution will not be supported for the Test and Last deployment ring in Autopatch groups. |
Service-based versus software update-based deployment rings
Another thing you will discover is that Autopatch groups create 2 different layers. And each of those layers will have its own deployment ring set. By default, both of the deployment ring sets that we are looking at will assign to devices that have completed successful registration with Windows Autopatch.
SERVICE-BASED DEPLOYMENT RINGS
This deployment ring set is only going to be for keeping Windows Autopatch updated. It does so with service and device-level configuration policies, apps, and the APIs required for the core functions of the service. Below is the list of Azure AD-assigned groups representing the service-based deployment rings.
- Modern Workplace Devices-Windows Autopatch-Test
- Modern Workplace Devices-Windows Autopatch-First
- Modern Workplace Devices-Windows Autopatch-Fast
- Modern Workplace Devices-Windows Autopatch-Broad
Please note that you should absolutely avoid making any modifications to the Azure AD group membership types (Assigned and Dynamic). If you make those changes, Windows Autopatch won’t be able to read the device group membership from these groups.
As a result, the Autopatch groups feature, along with other service-related operations, will not function correctly. Not only that, but you should also know that having Configuration Manager collections directly synced to any Azure AD group and created by Autopatch groups is an unsupported option.
SOFTWARE-BASED DEPLOYMENT RINGS
The second type of deployment ring set is only going to be compatible with software update management policies, such as the Windows update ring and feature update policies, in the Default Windows Autopatch group. Below is the list of Azure AD-assigned groups representing the software updates-based deployment rings.
- Windows Autopatch – Test
- Windows Autopatch – Ring1
- Windows Autopatch – Ring2
- Windows Autopatch – Ring3
- Windows Autopatch – Last
IT admins should note that any additional Azure AD assigned groups will be created and added to the list at the same time you’ll be adding more deployment rings to the Default Autopatch group. Moreover, similar to the previous type of deployment ring set, you can’t make any modifications to the Azure AD group membership types (Assigned and Dynamic). If you make those changes, Windows Autopatch won’t be able to read the device group membership from these groups.
As a result, the Autopatch groups feature, along with other service-related operations, will not function correctly. Not only that, but you should also know that having Configuration Manager collections directly synced to any Azure AD group and created by Autopatch groups is an unsupported option.
How to use Autopatch groups
There are a few examples that we can look at that describe certain scenarios and how we use Autopatch groups for those cases.
EXAMPLE NUMBER 1
Imagine a scenario where you are an IT admin who is responsible for several Microsoft and non-Microsoft cloud services. In this example, you don’t have the time necessary to set up and manage multiple Autopatch groups. At present, your company relies on using five deployment rings to operate it’s update management. However, you do have the option for flexible deployment cadences if you were to communicate to your end-users.
The solution, in this case, will involve using the Default Autopatch group if you currently don’t have thousands of devices under your management. The Default Autopatch group is editable to include additional deployment rings and/or slightly modify some of its default deployment cadences.
Additionally, because this Default Autopatch group comes preconfigured and doesn’t require extra configurations when registering devices with the Windows Autopatch service, it will offer greater convenience to IT admins.
EXAMPLE NUMBER 2
For the second example, you’re going to be an IT admin for a business that is looking to implement a gradual rollout of software updates within certain critical business units or departments to help mitigate the risk of end-user disruption.
What you can do in this case is to create a Custom Autopatch group for all your business units. This means that you can create a Custom Autopatch group for each department. And then, you can proceed to break down the deployment ring composition according to the various user personas. You could also perform the breakdown by categorizing how essential certain users may be for not only a particular department but for the business as a whole.
EXAMPLE NUMBER 3
In the final example, imagine being an IT admin working in the New York branch of a particular company. And in this scenario, you’re looking to implement a gradual rollout of software updates within certain departments in a way that does not disrupt operations in that New York branch.
Similar to the second example, you’re going to create a Custom Autopatch group. But this time, it will be for the New York branch. Then, you will proceed to break down the deployment ring composition according to the various departments within that branch location.
Wrap up
With the threat of cyber-attacks seemingly increasing each and every year, businesses need to be highly proactive about their security. They need to put in place measures that help to improve security and minimize vulnerabilities. Microsoft is looking to help businesses do that with the Windows Autopatch service. It is a highly efficient tool that streamlines the management of software updates and patches.
Autopatch leverages groups to enable businesses to get the maximum benefits from the service. This is also while taking into account the unique needs of the business. Therefore, what you ultimately get is a solution that can cut the security gap. And one that optimizes your IT resources in a way that improves productivity.