<img src="https://secure.leadforensics.com/51024.png" style="display:none;">

Now that most enterprises are in the process of migrating to Windows 10, IT project managers are starting to look beyond the initial rollout project and turn their attention on how to maintain the new OS. Since Windows 10 departed from Microsoft's tried and true 3-4 year release schedule in favor of a modern Windows-as-a-Service model, pushing two new versions a year, maintenance will be continuous and iterative. In other words, you had better get ready to manage a lot of change, all of the time!

As you might know, Microsoft has, after much confusion and frustration, recently clarified its version release timelines. Starting in September with the Fall Creators Update, Microsoft will align its Windows 10 versions with the Office 365 and SCCM support cycles and ship one major upgrade in March and in September. Furthermore, the announcement outlined the new support timelines: Each new OS version will be supported for 18 months. Since Microsoft will support multiple channels at once, you don’t need to move all devices to the same channel at the same time. But beware, this has major consequences for both your Windows 10 release adoption strategy, and your deployment strategy. 

While we previously talked at length about how to understand the Windows 10 Servicing timeline, we want to focus today on Windows 10 deployment rings.

The Impact Of Managing Branching Upgrades With Windows 10 Deployment Rings.png

Microsoft's Definition Of Deployment Rings

Microsoft defines deployment rings as follows:

Deployment rings in Windows 10 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 10, 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".

Essentially, they are simply a way to group devices into a deployment timeline based on your needs, capacity, or other deployment strategy considerations. Just like you probably did already for Patch Tuesday. 

Typical Deployment Ring Setup

Microsoft has a recommended theoretical Windows 10 deployment ring setup, which I have outlined below:

  • Windows Insider Preview (prio to the release of the new Semi-Annual Channel version): As soon as Microsoft releases a new version into the Windows Insider Preview, a few designated, tech-savvy Windows 10 migration project team resources will upgrade to the latest version to evaluate any new functionality.
  • IT Pilot Ring (Semi-Annual Channel release + 0 weeks): Twice a year, in March and September, Microsoft will release new versions into the Semi-Annual Channel. This version was initially known as the Current Branch, which was followed 4 months later by the enterprise-ready Current Branch for Business release. However, Microsoft does not make this distiction anymore. This version is the final version and include the new functionality of the previously released Windows Insider Preview. Most organizations will have a small group of IT pros test drive this version before rolling it out further.
  • Business User Pilot Ring (Semi-Annual Channel release + approx. 4 weeks): About four weeks after the new version release, Microsoft recommends that you onboard a small group of tech-savvy business users to broaden your testing into your business user base. This concludes your pilot rollout phase. 
  • Broader IT Ring (Semi-Annual Channel release + approx. 6 weeks): Now you are ready to roll out the latest Windows 10 version into your wider IT organization. While this means onboarding a larger number of users than you have so far, you can iron out any wrinkles in your migration process and ensure that your security and privacy is tight enough. Microsoft estimates two weeks for this rollout, but in my experience, four weeks is more realistic, especially given the size and risk of the update, and the number of applications that will need testing. 
  • Broader Business User Rings (Semi-Annual Channel release + approx. 16 weeks): This ring will kick off as soon as you completed your internal pilot phase and you are ready to roll it out to your entire business user base. If you have tens or even hundreds of thousands of users, you will want to sub-divide this into further rings. Again, Microsoft recommends 2 weeks per deployment ring, but realistically, you will at least need 2-3 months for this if you have a large estate!

So what does this mean for your deployment timeline? You will have to kick off major deployment efforts as soon as Microsoft published the new release for your IT Pilot and Business User Pilot and move into your broader business user rollout as fast as possible.

Following the logic for a typical 10,000 seat organization with deployment rings of 1,000 devices, this entire process could comfortably take you 7 months in total — so, by the time you finish the first round of upgrades, you will have already started your next round. That is unless you skip one upgrade cycle.

What Happens If You Skip A Version?

Many organizations opt for skipping one upgrade and focus on annual upgrades rather than running through the process twice a year. So, for example, if you are rolling out 1703, you would skip 1709, and target 1803 for your next rollout. 

If you follow the deployment ring setup as mapped out above, your project timeline would look as follows: You take 7 months in total to roll out 1703 across your entire organization and wait for the announcement of the Semi-Annual Channel (Targeted) release date for Version 1803. Assuming there are no delays on the Microsoft side, this process would look something like this:


(Image Credit: Juriba, Updated September 2017 to reflect new terminology & EOL rules)

As you can see, unless you can deploy very fast in volume, you could run into significant end of support problems for your 1803 upgrade (second upgrade cycle). Since you can only start your larger rollout to your business user rings after a successful pilot phase in the three previous rings (usually 3-4 months), you will only be able to upgrade all business users of the Broad Business User Ring #1 and some of the second ring before. However, based on our predicted timeline, the majority of your BBU Ring #2 will be upgraded AFTER 1703 has ended its grace period and has become end-of-life (i.e,, no more service updates).

A serious concern for organizations that bought into Windows 10 because of its increased security.

What Happens If Microsoft Runs Late?

Now, if this isn't scary enough, let me add another thought: What if Microsoft runs late? 

Since its initial release, Windows 10 versions have seen several delays — some over a month long. Even the Fall Creators Update (previously version 1709, now 1710) is over a month late. Now, if you shift this timeline one month back, you are really in hot water to migrate as fast as you can. In this scenario, BBU Ring #2 would not even have started yet - and this is the model scenario assuming everything on your end goes according to plan and runs smoothly.

Of course, we would hope in this situation that Microsoft repeats what it did with the initial 1507 release and moves the end of life date back - but moving targets are not something we should rely upon!


There are no two ways about it: Deployment rings are a big consideration in your Windows 10 Servicing Management strategy!

They are essential to keep everything running smoothly, but with lax management they can complicate the process significantly. You have to be extremely careful what criteria you use for your ring assignment and how you will handle the deployment of these rings. For example, as a user gets onboarded to their default ring, are all the required applications tested and certified on this new version? If not, you might stall your progress for weeks and no one gets migrated until this is remediated. 

Once you have your initial Windows 10 migration behind you, subsequent mini-upgrades to the next release must be efficient and swift. You need to prioritize based on the user's application requirements, their readiness status, their location, etc. Therefore, your tooling is just as important as defining the process itself. For example, you must be able to know exactly which user is assigned to which ring, and what their readiness status is — just to name a few. A command and control solution built to accelerate IT Transformation projects, like Juriba's Dashworks, will enable you to do that!

Last but not least, I cannot stress enough that the time to act is now! You need to be thinking about this NOW! The initial Windows 10 release (1507) is already out of support, and 1511 is nearing end of life in October 2017 — leaving you vulnerable. 

Click here to request a Juriba Dashworks demo

Barry Angell

Written by Barry Angell

Barry is a co-founder of Juriba, where he is focused on using his experience in IT migration to help drive product strategy, pre-sales and service delivery. He is an experienced End User Services executive that has helped manage thousands of users, computers, applications and mailboxes to their next IT platform. He has saved millions of dollars for internal departments and customers alike through product, project, process and service delivery efficiency.

Topics: Windows 10/Desktop Migration Evergreen IT