Build deployment rings for Windows client updates
- Windows 10
- Windows 11
Looking for consumer information? See Windows Update: FAQ
We're in the process of updating this topic with more definitive guidance. In the meantime, see this post on the Windows 10 IT Pro blog for some great suggestions for a deployment ring structure.
For Windows as a service, maintenance is ongoing and iterative. Deploying previous versions of Windows required organizations to build sets of users to roll out the changes in phases. Typically, these users ranged (in order) from the most adaptable and least risky to the least adaptable or riskiest. With Windows 10, a similar methodology exists, but construction of the groups is a little different.
Deployment rings in Windows client are similar to the deployment groups most organizations constructed for previous major revision upgrades. They are simply a method by which to separate machines into a deployment timeline. With Windows client, you construct deployment rings a bit differently in each servicing tool, but the concepts remain the same. Each deployment ring should reduce the risk of issues derived from the deployment of the feature updates by gradually deploying the update to entire departments. As previously mentioned, consider including a portion of each department’s employees in several deployment rings.
Defining deployment rings is generally a one-time event (or at least infrequent), but IT should revisit these groups to ensure that the sequencing is still correct. Also, there are times in which client computers could move between different deployment rings when necessary.
Table 1 provides an example of the deployment rings you might use.
|Deployment ring||Servicing channel||Deferral for feature updates||Deferral for quality updates||Example|
|Preview||Windows Insider Program||None||None||A few machines to evaluate early builds prior to their arrival to the Semi-Annual channel|
|Broad||Semi-Annual channel||120 days||7-14 days||Broadly deployed to most of the organization and monitored for feedbackPause updates if there are critical issues|
|Critical||Semi-Annual channel||180 days||30 days||Devices that are critical and will only receive updates once they've been vetted for some time by most of the organization|
In this example, there are no rings made up of the long-term servicing channel (LTSC). The LTSC does not receive feature updates.
As Table 1 shows, each combination of servicing channel and deployment group is tied to a specific deployment ring. As you can see, the associated groups of devices are combined with a servicing channel to specify which deployment ring those devices and their users fall into. The naming convention used to identify the rings is customizable as long as the name clearly identifies the sequence. Deployment rings represent a sequential deployment timeline, regardless of the servicing channel they contain. Deployment rings will likely rarely change for an organization, but they should be periodically assessed to ensure that the deployment cadence still makes sense.