When we first released Windows 10 in July 2015, we tried to explain the process by which servicing worked in what became known as the Current Branch/Current Branch for Business, or CB/CBB. As part of a cross-functional team of authors who dedicated many, many hours to the creation of the initial documentation, we were very pleased and proud with the finished product. It precisely explained, from a software engineering perspective, exactly how we were managing our branch structure to effectively enable and support the different Windows 10 SKUs and service cadence options. It was also a complete failure.
We learned a lot from our original approach and documentation, as feedback from customers pointed to some important considerations:
- We didn’t fully recognize that some of our customers were deploying Office 365 ProPlus in parallel with Windows 10.
- Routinely, our customers and the Windows ecosystem rightfully interpreted CBB as a unique “release” separate from CB, rather than our intent of a statement in time about the existing release. As a result, it understandably created behaviors like, “We’re waiting for CBB release to begin testing,” and, for ISVs, “We’ll support it once CBB is released.”
Since then, Office and Windows 10 have updated their release cadence, service terminology, and servicing guidance, incorporating feedback from customers and partners as well as key learnings from the last two years to address confusion over the CB/CBB nomenclature.
In July 2017, we announced a newly simplified and aligned servicing model for Windows 10 and Office that would begin with Windows 10, version 1709. As part of this announcement, we aligned Office and Windows with common terminology via the Semi-Annual Channel (SAC)—the replacement for CB and CBB—and the Long-Term Servicing Channel (LTSC), a servicing mode designed for special-purpose PCs, such as those used in point-of-sale systems or controlling factory or medical equipment. As John Cable pointed out in his Windows Experience blog post, we recommended that, just as targeted consumers would begin receiving Windows 10 updates right away, enterprises should also follow the same approach, starting with targeted deployments to validate apps, devices, and infrastructure used within the organization. The goal was for enterprises, once validation was complete, to begin broadly deploying.
Therein lies the challenge…
What does “targeted” mean?
In my March 2018 blog post on the organizational culture shift of moving Windows 10 deployments from project to process, I discussed the phases of the common servicing framework: plan & prepare, targeted validation, and broad deployment.
Targeted, therefore, refers to the initial phase of a release, the phase wherein your IT team (or the IT team here at Microsoft) makes the release available only to specific, “targeted” devices for the purpose of validating and generating data in order to get to a broad deployment decision.
This is precisely what is happening now with the Windows 10, version 1803. We are rolling out Windows 10, version 1803 to specific, targeted devices and, as we get positive telemetry and feedback from devices and users, we will gradually expand the offering until it becomes fully available to all devices. At that moment we will say what Windows 10, version 1803 is “broadly” available.
Our servicing framework guidance for commercial customers recommends this same approach. Start targeted deployments within your organization as soon as a release is available, deploying to an initial servicing ring, or rings, for validation. Target specific devices until you feel confident to make the decision to deploy broadly, at which time you will then update all of the devices in your organization.
Can you please explain the Windows 10 release information page?
Based on the information we’ve presented in this blog post thus far, you would rightfully expect to see just two entries each year on the Windows 10 release information page, right? Instead it still looks very much like the earlier CB/CBB days, with an entry for SAC and SAC-T (for Targeted). Why?
The explanation is Windows Update for Business. The origins of Windows Update for Business gave users the option to defer updates either from the CB or CBB declaration. If you, as an IT pro, have configured your devices to defer taking an update until CBB declaration, we needed to communicate the start date for the deferral, thus the two dates for each release. This model continues in Windows Update for Business today, so both SAC-T and SAC are present on the release information page.
If you are not using Windows Update for Business today, “targeted” has no impact on your devices other than to signify which phase the Windows 10 release deployment is in.
There is work underway to evolve the Windows Update for Business model, and have deferrals based on just one offset date. Once that happens, the SAC-T entry on the release information page will go away and you will just see two entries per year. This change will be communicated well in advance.
In my next blog, I’ll cover more specific uses of Windows Analytics and how it factors into your organization’s deployment rollout.
To learn more about Windows as a service, check out our Windows as a service page on the Windows IT Pro Center. You can also discover the benefits of Windows Analytics by signing up for this free service.
Continue the conversation. Find best practices. Bookmark the Windows 10 Tech Community.
Looking for support? Visit the Windows 10 IT pro forums.
