Windows 10 and the “disappearing” SAC-T
Published May 31 2018 01:30 PM 75.2K Views
Microsoft

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.

15 Comments

I'm not quite understanding?  You mean that in the future there won't be any ability to defer the semi-annual targeted ring?  

Deleted
Not applicable

The SAC and SAC-T naming was a very big mistake. They are far too similar for two different things and easily get confused.

 

Also, AFAIK, behaviors like, “We’re waiting for CBB release to begin testing,” and, for ISVs, “We’ll support it once CBB is released” is not because of misunderstanding the purpose of CB and CBB. It is because of the generally low quality of Windows 10. Your customers fear that Microsoft might provide no support in event of problems arising from the use of the CB branch releases on mission-critical machines.

Copper Contributor

Changing the naming makes a lot of sense.   If you take the time to explain to your customers how servicing works in Windows 10 it will just make sense.  :)

Copper Contributor

Sorry @John Wilcox but I now understand CB and CBB after Mike Niehaus LABORIOUSLY explained it many times. I sticking with that. Y'all maybe comfortably changing names at the drop of a hat but most of us DO not. This is no different then y'all trying to drop "RTM'. Believe me 'RTM' is alive and well in the lexicon of acronyms.

 

On top of that, CB & CBB is still all over the place, like in the Registry as well as other "soft" places.

 

All your customers really need know is:

  1. "The First ISO" release is RTM (Release to the Masses/OEM's).
  2. "The Second ISO" release 'Is a much more Stable Release than the first.

If one likes:

  1. CB or SAC-T or RTM or First YYMM.
  2. CBB or SAC or Stable RTM or Second YYMM(same as above).

If one hasn't taken control of there PC's in some way, they should/better because the option in Settings around this subject are notorious for FAILING which does boost the Install Numbers.

Whether one uses the ISO's or not their presents are Published and can me used as a guide for the wise, based on the testing, problems(or not) in the wild for those unsuspecting Beta testers as well as in ones own test lab.

I am an Insider, I believe everyone in IT/DevOPS with responsibility should be(IMHO). That is your first view of what is going to come at you. Just remember, the end of the WIP process Bits are different then the actual RTM bits. A bunch of stuff is added to the formal release (RTM) that sometimes sends the OS in to a tailspin. Unfortunately W 10.0 1803 was already going into a tailspin in March and April.

 

Just Sayn'.....

 

 

Best Regards,

 

Crysta

 

 

 

Copper Contributor

As this change is likely to affect most, if not all, IT pros out in the enterprise space, can these posts be linked up to the Windows 10 product page?

There are a myriad of blog posts, articles etc. that make things like this easy to miss - I for example found this out via  yammer post.

Thanks in advance,

Ian

Microsoft

In Order

 

Hi Susan

Yes,  we will continue to support deferrals. The work we are doing is to simply the configuration and management of the deferral and update process reflecting the one release.  I don't have details that are ready to share today, but if you would like early access when we are ready, participate in the Windows Insiders Preview program and give us your feedback.

 

Mr Master

Appreciate the feedback. I agree there was confusion with SAC an SAC-T, and happy to hear from Jim Kerr's feedback  this post help clarify and make sense of things.

 

 

Hi Ian

IT pros in the enterprise space mostly are self managing the updates, using tools like SCCM/Intune, and SAC-T/SAC has zero impact today and going forward. They make the call when to update devices, but they were the ones expressing confusion of there be separate releases. Unless you use WuFB/deferrals today, CB/CB , SAC-T/SAC has no impact on when your device was serviced. 
I will take your feedback to make sure this clarification gets broader publishing.

 

John

 

I am a participant in the insider program but often I miss changes because they aren't announced well, or I think it's just an issue with my computer (for example the hiding in the gui of the ability to choose semi-annual on a clean install 1803 - I thought that was a byproduct of my beta and didn't give feedback on that because I thought it was me - not that Microsoft had made a change).

 

Secondly there is an issue with making sure that Microsoft understands that there are others that feel similarly.   Is there a better way that many admins - many who participate on the patchmanagement.org listserve can be asked for feedback?  Currently if I try to "vote up" an issue, I get the feedback from others that I ask to vote for it that they are not a member of the insider edition - or they are back on a version that doesn't support the feedback app -- or any other myriad of things that block folks from voting up issues relating to patching in the 10 feedback app.  I put a link up - they don't have access to it.  Is there any better way that feedback on patching can be gathered?

Deleted
Not applicable

Well, thanks for being so nice, John. It is not every day that I see someone that responds "thanks" to "Windows 10 has low quality", even though what I said is not an expression of contempt. It was a technical fact. You see, I've been part of many Microsoft beta programs, and even remember the days of the ill-fated Microsoft Connect. I've been with Microsoft for far too long now, so much so that I have feelings for it. And I am saying this with all the feelings I can commend: Windows 10 could really some quality improvements.

 

But I am afraid I disagree with Mr. Kerr here. Explanations and justifications are very poor replacements for doing it right in the first place, not to mention that Microsoft has done this a lot before and I am not confident that customers would want to listen anymore. "When to install Windows 10" has become far too serious a conundrum.

 

What Microsoft should have done:

  1. Customers must have never been exposed to jargon such as "SAC", "SAC-T", "CB", "CBB"  or (most emphatically) "Windows Update for Business". Windows Settings app should have said "Install feature updates when:" (a) "After it reaches general availability" and (b) "After it reaches general availability and is tested for widespread use in organizations".
  2. There should have been am Upgrade Installer component in charge of getting feature updates that would let users schedule it to download during low-cost hours (e.g. 2 AM to 9 AM, depending on ISP), temporarily pause it, and see its progress. Trying to hide something so as a big full OS upgrade in the background was a supreme mistake on Microsoft's part. Just as no country takes kindly to 4 tonnes of unknown shipment crossing its borders, no user would take it kindly to 4 gigabytes of unannounced executable code entering its computer.

What Microsoft should do now:

Forget jargon and explaining them. Focus on bugs. If they are addressed swiftly, nobody cares what you refer to as SAC or SAC-T; for them, they are good enough anyway. If they are not addressed swiftly, no amount of explanation would improve customer satisfaction. All explanation does is to drain Microsoft resources on writing and explaining stuff.

Brass Contributor

I have Group Policies in production for configuring WUfB in which "Semi-Annual Channel (Targeted)" is selected as the Windows readiness level that I want specific machines to receive. Will that option be phased out in the future?

 

I currently have many machines configured to receive "Semi-Annual Channel" with the goal of them always waiting for 4 months after the release of a Feature Update. Will the upcoming changes result in those machines installing the latest Feature Update on day one?

 

How are we expected to transition to the new WAAS model with the same limited resources in our organization if the rules/terminology coming from Microsoft keep shifting?

Copper Contributor

WaaS is very difficult to manage.  The updates / feature upgrades and deferrals are all just wishful thinking.  When Upgrades are shoved down our throats they don't even obey the Active Hours schedule and restart a system during production hours without prompting.  It's amazing how your AI deems a new buggy release is stable for business within only 45 days of testing for an enterprise environment; but in the world of Green Screens, Blue Screens and just outright unusable, unstable Windows 10 systems, we all know that this is far from the truth.  Download and Pray.  Quality Control seems to really be an issue.  In regards to communication, there really needs to be better notification when a device is going to be auto downloading the latest feature release ultimately causing downtime.

Copper Contributor

As an ISV I'm confused.  Why does having Targeted versus not Targeted matter?  If we test the release and find a show stopper, the problem isn't going to be fixed until the next release.  We have to wait for a new release.

 

As much as we would like to say "supported on Windows 10" as a blanket statement, that won't work.  It might be a later build of 1709 or 1803 or some future release that has the show stopper fixed.  So the OS build is what matters.  https://support.microsoft.com/en-us/help/4099479

Microsoft

Hi David,

Thanks for reaching out.

 

Hopefully I can help clear up the confusion you described.  

 

Each release starts in the "Targeted" phase, where we offer the new update to specific, targeted devices, as we mange the roll out. With 1803, we adopted the use of AI, and saw both much faster velocity and better user experience as a result.  This is the basis of our servicing guidance that we provide to commercial customers as well. With a new release, provide it to a subset up users in an early servicing ring, and with good data and feedback met, add more users through additional targeting rings until you meet your deploy decision criteria, at which point you the update everyone else.  This mirrors what we just completed with the Windows Update managed devices. 

 

If an  issue is found during any point of a release lifecycle, preview, targeted or broad, with windows, we work to quickly understand the issue, generate a fix in Windows if the bug is ours, or work with the 3rd party if the issue is not ours.  For issues that are ours, we create and ship both quality fixes as well as security fixes each month, you don't have to wait for a new feature release ( 1809 ), just the next monthly patch Tuesday perhaps. It is the agile servicing that has enabled us to quickly address and unblock devices during a roll out, and why we have been able to achieve the velocity we just saw with 1803 with the highest quality and best user experience yet for Windows 10.

 

As an ISV,  your Windows Compatible apps will work from release to release, which is the experience 100,000Ks of apps and 100s Millions devices demonstrate and experience with each feature update. Yes, of course, we see issues as well. This is rare, but we actively monitor, investigate and work to correct when it happens, either with the fix ourselves, or working with the ISV/Driver owner.   

 

Thanks

John

 

 

 

 

 

 

 

 

 

 

Deleted
Not applicable

I feel like developers are naming this and not marketers. Start branding it as Windows as a Service, rather than Windows 10. SAC/SAC-T is way too complex to try to explain to users. This needs to be clear and concise, install features immediately, or install features after extended testing. Then there should be a "learn more" to explain what happens during the extended testing period, and why some features shouldn't be installed immediately for all users. This concept has to be user-facing, it is the key component to this "service."

Brass Contributor
I think many were treating waiting for CBB like waiting for the first SP. Unfortunately, this was a doomed strategy. 1511 had a bug that borked systems with Logitech wireless receivers connected during installation. This occurred on all our Logitech systems even though we had the install delayed 8 months from RTM. Then 1709 had a bug that killed Outlook search on any system it was installed on that already had the MSI version of Outlook installed.. That 8 month delay didn't save us their either. We thought the delay would give the team a chance to fix the problems exposed during early adoption. But, that's not what happened. The only thing the 8 month delay did was give us a wealth of historical google results to help us get out of the mess. I personally thought that the CB and CBB naming was very clear and that SAC and SAC-T was very confusing. But, I get what the goal was. You were trying to break that "wait for the first service pack mentality." I too agree that quality needs to be more important. You're proven right the naysayers in my office that wanted to stay on Windows 7. Every time our help desk is knee deep in Windows 10 feature upgrade problems, someone reminds me that the Windows 7 systems are fine.
Copper Contributor

I think you worked very hard to constructing the service structure. We beign as IT Pro also worked hard to understand the windows 10. At microsoft the knowledge and terminology evolved in time. However we had to adapt revolution when we faced with windows 10 we had to learn and test so much things. Morever in international thingking "business" can be percived differently from what you meant at first place. Now you changed the terminolgy again.  Being simple is the best instead of using fancy words. And the with the initials versions everything was so volatile and absurd. I saw even candy crush . Why a working person needs candy crush.  Microsoft Apps made the system so slow in shared pc in domain enviroment.  Thats why people tried to use LTSB. The purpose was the speeding up system and making the system very basic. There is hovever now get office app. Why it is in enterpise, education and pro versions. Usually people who uses these additions also uses office 365 or pro. As two  recommendations:

 1.) In enterprise additions microsoft apps like skype, get office, games, microsoft store(IT people choses software and apps), xbox,    should be removed or there should be option before installing.  They can be stay in Home and Pro versions.

  2. )Enterprise addtions should be more Active Directory friendly.

Version history
Last update:
‎May 31 2018 03:26 PM
Updated by: