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 2017 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 (Microsoft has granted 6-month extensions for versions 1511, 1607, 1703, & 1709). 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.
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 (prior 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 distinction anymore. This version is the final version and includes 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 have 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 publishes 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 February 2018 to reflect new terminology & EOL rules)
As you can see, unless you can deploy very fast and 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 end-of-life for 1703. However, based on our predicted timeline, the majority of your BBU Ring #2 will be upgraded AFTER 1703 has ended its 18-month support timeline (not taking into account the 6-month extension) and has become end-of-life (i.e,, no more service updates).
Potentially having thousands of users on an unsupported OS is 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, version 1709, wasn't released until mid-October. 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 have now seen Microsoft move end-of-life dates back for several versions now — 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 keeping 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 then 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 his or her 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.