UPDATE: November 28, 2018 by Jon Rolls

Microsoft has continually updated its Windows 10 release terminology, and since this popular article was written we have been through more iterations and release cycles. Microsoft has now declined to officially declare a branch “ready for business” but they have still continued to do an “available for all devices” announcement (like this) which is very similar in nature.

For the Ivanti stance on Windows 10 releases and support in User Workspace Manager please check out this article, which is frequently updated as Microsoft tweaks the Windows 10 lifecycle!

___________________________________________________________

Editor’s Note: This post was originally posted on Dec. 21st 2016 on the AppSense blog. We’ve brought it back due to popularity and relevance of the continued migration to Windows 10 into 2017.

Windows 10’s evolutions don’t simply stop at the Start Menu.

With an eye on the likes of Apple and Google, both of whom have succeeded in bringing an aggressive fast-update cadence to their own flagship software platforms, Microsoft have performed a radical overhaul – or, to use their own terms, reimagining – of the method used to build, deploy and service the Windows client endpoint. These improvements have focused strongly on simplifying the process required, as well as maximizing user involvement in it, and minimizing the resource needed to perform updates of the Windows operating system to the latest features.

Traditional upgrade methods

Traditionally, a Windows operating system upgrade was a large project requiring a substantial amount of planning, resource and disruption. They came along every three to six years, and involved a big leap in terms of hardware, software and user familiarity. Because of changes in hardware specifications and also to the under-the-hood operation of day-to-day tasks, operating system upgrades were, for the most part, a case of wipe-and-reload. This approach necessitated additional overhead as migration processes and supporting scripts were created, tested and maintained to assist in the transition.

Brave new world?

With Windows 10, Microsoft have eschewed the “big bang” approach and adopted a rolling upgrade methodology that will be very familiar to users of applications such as Google Chrome and Mozilla Firefox. The emphasis is on escaping from the training burden by implementing feature changes that are incremental rather than radical, allowing rapid updating of security, deployment and management capabilities in response to new challenges or emerging technologies. They’ve also improved their testing process, moving away from the “technical preview” release close to RTM and instead releasing constant “flights” of previews to their Windows Insider community. This allows organizations to get a head start on testing and remediation instead of trying to cram it all into a limited TP window.

WEBINAR: Insights for Windows 10 in the Enterprise

What is worth drawing attention to is the fact that what Microsoft terms “feature updates” are actually self-contained operating system upgrades. No matter how much they market it as an “update”, it is still a full new version of the Windows OS. The control of the release of these upgrades is crucial to Windows 10 deployment, and to manage it, they have given us the concept of servicing.

Branching out

Microsoft’s idea is that their “servicing windows” will simply slot into enterprises and replace their current testing and release schedules with a global staging standard. Current Branch releases (CB) are intended to become the enterprise pilot cycle, receiving upgrades as soon as they are available. Current Branch for Business (CBB) is exactly the same as CB, just with a configuration change that defers the feature updates for one whole servicing window (approximately 3-4 months, although that may change or fluctuate upwards), meaning that enterprises can mix and match CB and CBB and also interchange seamlessly between the two.

CBB machines are intended to receive the update when the CB (pilot) machines have run it for the period of a single servicing window, and it is believed that by this point, the feature update will have had enough fixes and testing done to make it ready for general deployment. Microsoft are very keen to espouse the CB/CBB model as the ideal method of deployment for enterprise, and SCCM encourages this further by allowing you to configure two separate “rings” for deployment in the Windows 10 Servicing feature. The SCCM rings are tagged as “Release Ready” (which is CB) and “Business Ready” (which is CBB). This direct integration approach is Microsoft’s vision of how deployment schedules should run for all enterprises that adopt Windows 10.

Of course, there are always exceptions, and that’s why Enterprise edition customers get the option to use another servicing branch, Long Term Servicing Branch (LTSB). LTSB differs from CB/CBB in that it is actually a completely separate operating system, and has many Windows 10 features removed, such as the Universal Apps, Cortana and Windows Store. It also has a servicing window of up to ten years, with a new version of it released on what was originally intended to be an annual interval, but now, according to the latest Microsoft documentation, will be every two to three years.

Microsoft is very zealous in its insistence that LTSB should only be used for machines that are “not general purpose”. According to them, a machine that has Microsoft Office on it counts as “general purpose” (an interesting way of classification!), and should therefore always be allocated to the CBB branch. Examples of LTSB use cases only cover critical endpoints such as air-traffic control systems and life-support machines. So to make the choice between CB/CBB or LTSB, what you really need to know is exactly how long you have before the next upgrade must be applied.

The big question

Unfortunately, as with Microsoft licensing, it’s very difficult to infer from Microsoft’s documentation precisely when a machine on CB/CBB must be upgraded to the next feature update. With two servicing windows (which will be somewhere in the region of 6-12 months, but could extend), plus a 60-day grace period, and potentially an additional month if you configure the “pause updates” GPO – we can see straight away that upgrade timing isn’t an absolute value that we are dealing with. In the light of this, I’ve personally settled on a period of two servicing windows plus the grace period (I don’t trust Microsoft not to tinker with the GPO settings) – so 8-14 months is the timeframe I’ll usually stipulate when determining feature update timing.

Some aspects of upgrade timing, though, remain very murky, and I can see a lot of potential for CB and CBB clients to get “out of step” with each other in particular configurations. The whole “greyness” of the concept when dealing with CB/CBB is something I have heard used as a driver for the adoption of LTSB instead, so I think it would benefit Microsoft to do a detailed Q&A session around the whole servicing branches model. I’d be quite happy to participate in this, if they were so inclined!

So if we consider 8-14 months as the servicing window for a CBB machine, and err on the side of caution down to 8 months, then in that eight month period you must:-

  • Test all applications
  • Identify any application issues
  • Work with vendors to resolve application issues and verify success
  • Assess the user interface for any potential changes that require training or communications
  • Identify any features which have been removed that users may rely on
  • Verify that all previously-applied policies and configurations still work as intended

And that’s probably not an exhaustive list…I’m sure every enterprise out there has some specific testing that needs doing in addition to this list. The presence of the Windows Insider branch means that some of these actions can be done prior to the actual CB release, but still, it’s a lot of work.

So really, when you are deciding on CB/CBB or LTSB, the main question is – do you think you can fit all of the required testing and remediation into the maintenance window? If the answer is yes, use CB/CBB. If not, then go with LTSB.

CBB versus LTSB

So, what’s in the names? How do CBB and LTSB differ from each other in the flesh?

Microsoft maintains that the most important difference between the two major servicing branches relates purely to the management of feature update releases. The below diagram shows how the two branches differ in their approach towards updates – Servicing Branch #1 is CB/CBB, Servicing Branch #2 is LTSB

But in reality, there are many other factors to consider, which are summed up nicely in the following table:

windows 10 servicing options screenshot

A poll we conducted amongst enterprise EUC admins revealed the following split between preferred servicing branches:
With these statistics in mind, what are the real areas to focus on between CBB and LTSB? And what is the choice that real-world IT staff are going for?

cbb or itsb pie chart

Interestingly, nearly 1 in 4 respondents reported plans to adopt LTSB, compared to 54% for CB/CBB. The remainder were opting for a mixed environment encompassing both major branches.

The lion’s share of respondents appear committed to embracing the CB/CBB model, but it is also clear that many more people than Microsoft expected are looking at adopting LTSB – either wholly, or in part. But what are the major drawbacks of putting machines onto LTSB? What features are lost when deploying this to client endpoints?

In my experience, the main feature that is lost when adopting LTSB is Microsoft Edge. It’s about the only application or feature that businesses seem to be concerned about losing access to. The Windows Store, Cortana, and all the other Universal Apps don’t seem yet to have enough uptake or interest to justify any meaningful interest in adopting CBB on a feature basis alone.

However, because there isn’t a real killer app available on the UWP platform yet…doesn’t mean there won’t be one. Microsoft – and other vendors too – are slowly porting applications to the new platform, and every iterative update of Windows 10 brings more. The Desktop Bridge offers a way for vendors to convert applications directly from legacy desktop formats without a huge development effort, and this may drive future movement towards the UWP model.

Away from the UWP side, there is the rolling nature of the Windows 10 CB/CBB branch, and it does make LTSB look dated very quickly. Comparing the RTM LTSB version of Windows 10 with the 1607 Anniversary CBB update reveals two operating systems that look and operate very differently, both in terms of the visible user interface and the underlying features. This, I think, is where enterprise staff are worried – they fear falling behind and potentially ending up with a mismatched estate of Windows 10 LTSB devices in various different stages of support. Whilst CB/CBB brings rapid change, it also does so on a regular, predictable basis.

CB/CBB is also much more hands-off – upgrades to LTSB, whilst they still can be done in-place if necessary, must be triggered and managed directly by an administrator using automated tools. Of course, if you’re using WSUS and/or SCCM you have the option to manage updates in this granular fashion, but it’s clear that Microsoft intends for Windows 10 deployments to have much fewer resource requirements than earlier versions, so the hands-off nature of CB/CBB has to be seen as a boon – providing it is reliable.

And reliability really is the key consideration. In terms of adopting new features and embracing new industry standards, CB/CBB has to be the way forward. It allows enterprises to be agile in their Windows client deployments, rather than having to invoke huge costs for every upgrade project. But adopting this model relies on Microsoft to avoid major problems with core applications and cause a minimum of user disruption. It will only take one widespread issue with a feature update for trust in the new model to dissipate entirely, and for seasoned Windows admins to revert straight back to type and jump onto LTSB as the safety net.

Mitigation

However – while we’re in this transitional period, as Microsoft builds trust in their new servicing model (or not!), you may need to adopt some supplementary technologies to help you adjust to the servicing paradigm. And it’s not just strictly for CB/CBB either – if you’re on LTSB but want to adopt the latest features, you may have to consider performing OS upgrades every year or two as well.

Maintaining the “user experience” breaks down into three key areas:

  • Applications
  • Data
  • Profile/personality

Users need to have access to their applications, the data those applications use, and all of the config settings and supplementary files that sit along with them (shortcuts, FTAs, views, etc.). Together, these areas combine to produce the user experience, and maintaining a consistent user experience is a key factor in enabling user productivity. If there’s any sort of failure in the update process, having the relevant pieces of the “user experience” available to slot back in to a newly-imaged endpoint makes user disruption much less of a possibility.

Microsoft has App-V built in to the operating system as of the 1607 Anniversary Update, so delivering applications is no longer such a specific challenge. There are many other technologies that also help with this – Unidesk, Cloudhouse, Turbo, Cloudpaging, FlexApp, etc. All of these solutions abstract the applications away so that they are easily deployed to the client endpoint.

With regards to data and profile/personality, these can easily be captured and maintained by Ivanti’s ‘powered by AppSense’ tools, not just between Windows 10 versions (let’s not forget that Windows 10 1511 and 1607 profiles are completely incompatible with each other) but across older Windows client and server types as well. We have had great success, particularly in the data area, by leveraging our DataNow product to get around the limitations of every admin’s usual response to data roaming – Folder Redirection. Additionally, Ivanti’s DesktopNow provides an unprecedented level of control over the user profile and personality aspects, enabling smooth roaming even between CB/CBB and LTSB Windows 10 instances – so if you’ve had to mix and match your endpoint types, as many do, then it’s no longer a problem for the users.

Pick your poison

So – in a nutshell, what’s it to be? CB/CBB, or LTSB?

There is, sadly, no definitive answer. But there are definitive questions. And the answers to those will probably be driven by your applications, your application vendors, and the resources you can dedicate to testing and remediation. In my experience so far, most enterprises have adopted CBB with a smattering of LTSB. The few I have seen adopting LTSB exclusively have done so for reasons of resource, which is probably completely at odds with Microsoft’s vision.

But if you choose your supporting toolset wisely, the delineations between CBB and LTSB become less clearly defined. The main reason for adopting LTSB is due to remediation worries that an aggressive operating system upgrade model will cause issues that regularly disrupt users. If you abstract away the applications, data and profile from the operating system, then an aggressive update cadence has less potential for impact. Make the right decisions about your tooling now, and you could find that the CBB model might actually become less of a millstone, and more of a benefit.