One of the changes precipitated by the latest Windows 10 version, the Creators’ Update, is that this version (1703) will be the last version that fits into what we knew as the Current Branch/Current Branch for Business model.
The first thing that’s going to change is that the “branches” nomenclature is going to change. We now won’t be talking about servicing branches, but instead they will now be referred to as servicing channels.
What we previously referred to as feature upgrades have now become feature updates. This is despite the fact that feature updates are whole new copies of the operating system and essentially are upgrades – the terminology now rather cynically classes them as updates when in fact they are complete operating system upgrades. To be fair, this change came in before the Creators’ Update, but it is worth bringing it to your attention as part of the wider changes happening.
Windows Update has now become Windows Update with Unified Update Platform (UUP). The changes in UUP are intended to make downloads smaller and less time-consuming, introducing the concept of “canonical” (full) and “differential” builds. This is now extending onto other devices such as Windows mobile, Xbox and HoloLens as well.
The Current Branch (CB) and Current Branch for Business (CBB) channels will change – making 1703 the last version of Windows 10 that is delivered through the servicing “branches”. When the next version is released, we will see a change in the nomenclature that will now refer to CB (or Release Ready) as Semi-Annual Channel (Pilot), and CBB (or Business Ready) as Semi-Annual Channel (Broad). I don’t know whether it’s the official usage, but I’ve already started referring to these two easy-reading roll-off-the-tongue acronyms as SACP and SACB.
Interesting that Microsoft have now admitted that the CB users (of which many are home, consumer users) are now actually really a “pilot” group whose purpose is to identify issues that can be fed into the release channel. How consumer users react to being classified as glorified beta testers is unclear, but it is certainly refreshing that Microsoft have admitted that the purpose of the former CB channel is as a pilot test group.
The use of the term Semi-Annual was a little confusing at first, as my perceived interpretation of the word “semi” had always, in my head at least, meant “partly”. However, it was pointed out to me on Twitter (thanks Rob!) that the actual official meaning of “semi” actually translates to “twice”, although that’s very much a literal interpretation that in my opinion has changed somewhat over time. If Microsoft meant it to be “twice-annually”, then I don’t see why “bi-annual” couldn’t have been used instead – but after thinking about it, “bi-annual” would have nailed them down to a twice-yearly release, whereas “semi-annual” remains wooly enough to allow them to possibly alter this schedule as they see fit. Maybe I’m being a little cynical (hide your surprise!), but time will tell.
Now, assuming Microsoft are going to adopt the twice-yearly release schedule, and stick to it, the servicing window (starting from the 1709 release) should look something like this, as Microsoft are now telling us there will be a specific 18-month support lifecycle.
As noted in the image above (which was lifted straight from one of my presentations), the grace period of 60 days at the end of a support window for a release has now been removed, fixing the servicing window at 18 months from release. The GPO which allowed you to delay feature updates by a further 35 days may still work, but I’m willing to bet it will be deprecated pretty shortly, so you have exactly 18 months to fit in all of the required testing, remediation, vendor engagement and implementation that goes along with moving to a new feature update.
Concurrency-wise, this means that if Microsoft stick to the six-month release schedule, we should at any given point have no more than three Windows 10 versions in support, as shown in the diagram below.
It also means that if you choose to upgrade, for instance, from 1709 to 1809, the 1809 release will have passed through SACP before 1709 goes out of support, ensuring that you can move in jumps of two releases at a time, which will be good news for enterprises that are struggling for resources within operations and testing teams.
Finally, Long-Term Servicing Branch (LTSB) still sits outside of this and as of now (June 2017) is still referred to as such. Whilst some are predicting an LTSB release in September of this year to coincide with some updates to Server 2016, the official word of Microsoft (again, as of this moment in time) is that the next LTSB release is not due until 2019.
Summary
Microsoft’s changes to the terminology used within the servicing model are somewhat unwelcome, given that it took a very long time to both divine and understand the nature of the previous terminologies they introduced us to.
However, the move towards a fixed 18-month supported servicing window – if it is stuck to – is very welcome. Prior to this, there was a lot of confusion and misunderstanding as to precisely how long a servicing window would be. Whilst still a little aggressive for my liking, the 18-month window at least ensures that we know where we stand and how we need to approach the management of our Windows 10 platform.
I will stand by my assertion that virtualizing applications and user settings is key to being able to maintain an agile Windows 10 environment. Coupling virtualization with the requisite mindset changes and additional monitoring required will allow you to keep on top of it, even if you choose to go the SACB route.
Share
