What Current Branch and Current Branch for Business are not.
A lot has been written and spoken by Microsoft and in the community of Windows 10 as a service and it’s multiple servicing models, commonly called Windows 10 Servicing. This of course includes Current Branch (CB), Current Branch for Business (CBB), and Long Term Servicing Branch (LTSB). LTSB is special servicing branch of Windows 10 but this post is completely non-applicable to it because, well, eww yuck, it’s best to avoid LTSB altogether.
There are a lot of incorrect and misleading statements floating around about CB and CBB in both official Microsoft documentation, unofficial documentation, and community blog posts to name a few sources. Here’s a summary of these statements which are more or less all related and stem from a faulty understanding of what the service model really is or rather what a customer should use it for. Additionally, these statements seem OK on the surface and in some scenarios may actually appear to be true. But, once you peel back the layers, it’s easy to see that they are not and can be bad for your environment if you treat them as true.
CB and CBB are a “state” of a Windows 10 system that can be determined by the value in the registry. NOT
This specifically refers to the Defer Updates and Upgrades setting (which has now become Pause Feature Updates setting in Windows 10 1703). This is completely incorrect and even dangerous, see Why WSUS and SCCM managed clients are reaching out to Microsoft Online for a lot more details on this. To summarize briefly, this setting (and resulting registry value) are meant to control when feature updates are applied from Windows Update for Business (WUfB) only. Even if you are using WUfB, don’t equate setting this value to somehow magically changing what is installed on a system. This setting defines the intent of an administrator for when it will get a feature update in the future. The exact state of the system right now is completely separate from what the value of this setting is.
If you are using System Center Configuration Manager (ConfigMgr) for updates, you should not be setting this value at all (and if you’re not using ConfigMgr, you’re doing it wrong to begin with). Setting this value, as detailed in the post above, enables dual-scan for Windows Update which in turn has multiple nasty side effects. Don’t do it and delete it ASAP if you have.
CB and CBB are different versions of Windows 10. NOT
CB and CBB are in fact, the exact same version of Windows 10. Many folks like to point out that Microsoft releases new media when a version of Windows 10 is declared CBB and so that means it’s a new version. This is [of course] false. The new media is simply a convenience for those building images and/or deploying new systems. The version does not change and a CB system can easily be updated to the latest build by applying the latest cumulative update.
It’s important to note here that version here refers to 1507, 1511, 1607, and now 1703 because these version numbers refer to a locked in feature set.
CB and CBB have different end of life dates. NOT
Because CB and CBB are really the same version of Windows 10, they go end of life at exactly the same time (which is still variable and based upon the initial CB release of the second version after the version in question).
I need to set the Defer Upgrades setting for Windows 10 Servicing to work in ConfigMgr. NOT
Per the theme of this post, this is also false. ConfigMgr doesn’t care about or rely on this setting in any way. The deployment ring criteria page when creating a servicing plan is for update selection and not targeting. Servicing plans are simply Automatic Deployment Rules (ADR) with a few additional settings and like ADRs, the result of evaluating a servicing plan is an Update group, an update deployment on that update group, and the download of the updates (feature updates in this case) to an update package (known as deployment packages if the console even though they have nothing to do with deployments).
So what are CB and CBB really?
CB are the builds of a Windows 10 version at the time that version is initially released up until the time that version is declared ready for business use. Similarly, CBB are the builds of a Windows 10 version from time that version is declared ready for business until the time that version is retired. That’s it, a simple set of builds.
Notice a key word in both statements above: declared. It’s very important to take note of this word because this is truly the difference between CB and CBB. At some point, Microsoft simply says, it’s ready to be used for our business customers. Nothing has truly changed about the version except a bunch of fixes wrapped up in the latest cumulative update. It’s still the same version though.
If you have a system on a CB build, as noted above, to bring it up to CBB (assuming the version has been declared ready for business) all you need to do is apply the latest cumulative update.
Put simply (and stolen from Mr. Niehaus) CBB = CB + latest CU.
So, how do you determine if a system is on a CB or CBB build? By looking at the actual build numbers. This page has those build numbers although it hasn’t been updated for 1703 yet: Windows 10 release information.
And how should you determine if you want to update your systems to CB or wait for CBB? Well that’s up to you. If you need a tracking mechanism and you are using ConfigMgr, you should do what you’ve always done: build and populate collections. What you put in those collections and how you get them there is completely up to you — just don’t use the Defer Updates and Upgrade setting for this.
Intent vs. Actual
One of the sources of the issue here is defining the intent of what build you want your systems on and the actual build those systems are on. Most documentation intermingles these two concepts without distinguishing between the two. If you have a set of systems that you always want on the latest (non-insider) build, i.e., your intent for these systems, you may call or classify those systems as your CB systems. But at some point, those systems will actually be on a CBB build because the next version hasn’t been released yet and the old/current version is already at CBB. So if you continue to call those systems your CB systems, folks might (rightly) assume that you haven’t updated them to the latest cumulative update and are out of support and/or a security risk.
My recommendation: stop using CB and CBB to define intent and only use these terms to define the actual, current build. Use other terms to define your intent.
Note that the ConfigMgr product team foresaw this confusion when creating the user interface for servicing plans and used the terms “release ready” and “business ready”. Unfortunately, this was and is not enough to prevent the confusion.
To be clear here, we are working with the content owners at Microsoft to get the documentation corrected (Niall Brady has been fighting the good fight on this for months and months). But it’s more than just a documentation issue at this point as there are a few lingering technical and strategy based issues as well. Windows 10 is moving so fast (as is ConfigMgr) that sometimes things just don’t happy as quickly as we want then to. That’s not an excuse, it’s just a statement of fact.
The ConfigMgr Servicing Dashboard
As confirmed in the comments below by Mr. Niehaus, the Windows 10 Servicing dashboard in ConfigMgr relies on the Defer Upgrade GPO setting (or really the registry value behind this setting) to show CB and CBB systems. These values are collected and accessible in ConfigMgr using the OSBranch attribute of the System Resource class. What this means is that this dashboard and those values, assuming you have the GPO set for your systems, define intent and not the actual, current build of a Windows 10 system. There’s not a lot of value in that IMO particularly if setting this policy breaks software updates on those client systems. If you want to view, audit, or control your intent, then as noted above, use collections just like you always have in ConfigMgr.