Windows 10 Update Channels: You’re getting SAAAAAAAC’d

I’m going to shake it up here and do something totally crazy. I’m going to talk about operating systems for a moment. OSD is absolutely something in my wheel-house and I certainly have my own ways of doing things. However, I don’t really talk that much about it because there’s just so many freaking people blogging about OSD. I even like all most of them. Beyond that, I tend to keep things as simple as possible where-ever I can. I just want Task Sequences to work dangit!

However, last week Microsoft has done yet another shake-up in how we service Windows 10. As usual, there seems to be a fair amount of consternation. Personally, I think it’s a bit of a nothing-burger and while change is hard this is the final nail in the coffin to get Windows as a Service’s (WaaS) cadence to where it should have always been. To really make sense of why they would make this change you need to understand the whole journey.

What Series of Choices Have Led to This Moment?

When the first versions of Windows 10 were released we were given 3 branches: Current Branch (CB), Current Branch for Business (CBB), and the Long Term Servicing Branch (LTSB). The idea was that Microsoft would release CB/CBB 3 or more times a year and you would have 14 months of support from the moment it was released to Current Branch. LTSB would follow the old pattern of 5-year release cycles and 10-years of support.

The reaction of most admins was swift and predictable: Long Term Serving Branch. In reply Microsoft started threatening to sneak into your house and beat you to death with your own shoes. It was a risk most were willing to take. Ok, fine, we’re taking Office 365 and going home. Crap … looked like we were just going to have to buck up and deal with it.

The messaging surrounding the branches from Microsoft was widely interpreted to mean that CB was for consumers and CBB was for … well … businesses. It’s right there in the name. The belief being that the ‘for Business’ designation was some kind of metric-driven decision made by Microsoft. In reality it meant nothing of the sort. I’m not sure I’d call the CBB release completely arbitrary but it didn’t really confer anything special from Microsoft apart from the fact that the CB release had been out for a few months and didn’t destroy everything in it’s path. It most certainly didn’t mean that all your LOB apps were safe.

The problem with waiting for the CBB designation was that the support clock started ticking the moment CB was released. If it took 4 months for Microsoft to apply that rubber stamp then you just lost 4 out of the 14 months that the release was supported. If you waited for CBB to even start working on it then that was a hard hit to take. The end result was that every single day for the rest of your career you were going to be actively engaged in deploying the latest version of Window 10. So while Windows 10 might truly be the last version of Windows you ever deploy you will never … ever … stop deploying it. This was your life now.

The Peasants Revolt

This might be surprising to some people but apparently there’s a few administrators out there who didn’t get into IT to spend every waking hour rolling out operating systems. “Don’t worry” they said. “It’ll be easy” they said. “Servicing is the coolest” they said. “Set it and forget it” said the TV salesman. If we can’t trust TV advertisements then what can we trust in this world!? If any of the above were true then things might have ended there. Set up a servicing plan or WUfB and push out Feature Updates like they were any other update and move on with your life.

Sigh. If only that had actually worked. I don’t want to turn this into a Festivus airing of grievances but there were several show stoppers. The end result was that most organizations had to turn to Task Sequences to get things to actually work in the real world.

It was about this time that administrators realized that a 14 month support just was not going to work. You’re losing roughly 4 months waiting for CB to be christened CBB. Then you have to get a TS working and find out all the new things it’s going to break in your org. If a release proved to be a real turd-bucket then you were in deep doo-doo. The version you’ve barely finished deploying to the last of your systems is about to go out of support and the new release is broken. It wasn’t a fun place to find yourself.

My TAM at the time was unwilling to confirm in writing but he made it abundantly clear that he was getting reamed out by every single customer he had. The guy was quite literally walking funny from all the negative feedback. No one actually responsible for trying to pull this stuff of believed it could work as designed.

Hamstrung By their Own Product

Eventually the Windows product team finally started groking the above reality. Well that and they had a new idea: Microsoft 365. In April 2017 they announced that Win 10 and Office 365 would join each other in a very specific cadence: two releases a year (March and September) supported for 18 months. In July 2017 they similarly announced that Branches were dead and long-live Channels. Crucially, in that article Mr. Niehaus himself laid out the following: “The Semi-Annual Channel replaces the Current Branch [CB] and Current Branch for Business [CBB] concepts” [emphasis mine]. So branches are now channels, we’re down to just two (Semi-Annual Channel and Long Term We Kill You Branch), and SAC gets 18 months of support thus essentially erasing the 4 months lost waiting for the previous CBB designation that was kind of meaningless.

But wait … there was a problem. The policies that make up Windows Update for Business (WUfB) and are used by ConfigMgr’s (Win 10) Servicing Plans have CBB hardcoded into them as well as the OS itself. While they didn’t really formerly announce it (I could find no article introducing SAC-T), Microsoft was forced to put out a Semi-Annual Channel (Targeted) (SAC-T) in order for those two products, and those two products alone, to function as intended. This is laid out in a delightful post by John Wilcox (Microsoft WaaS Evangelist) that I appreciate for this little bit of honesty. Of their original plans laid in 2015 he writes: “It was also a complete failure.” The key take away from this last article is that right from the start they planned for SAC-T to go away. It was always a temporary stop-gap until they could update their tools.

We Want More!

This is a bit of a tangent but the problem with customers is that they’re kinda needy. For large enterprises, even 18 months just wasn’t enough. In my own organization at the time we were looking down the barrel of 1703’s eminent EOL without having a solid In Place Upgrade strategy in place. Plus, we weren’t even half way through our Windows 10 rollout in the first place. If it takes you 3 years to get to Win 10 it’s beyond optimistic to think you can do IPUs every single year. At least out of the gate. Put out a few rock solid no-nonsense releases and maybe we can talk. So in September 2018 Microsoft announced yet another change: The Fall (September) release would be supported for 30 months for those using the Enterprise and Education SKUs. Pro users just got the sad trumpet and those of us with deeper pockets rejoiced.

A Moment of Silence for SAC-T

Everything above leads to the recent announcement that SAC-T is officially dead and that the 1903 release of Windows 10 will not have that channel. Since this is change of any sort to a process that has changed so very much in so very little time (see above) there is the usual amount of confusion and consternation.

What’s an Administrator to Do?

What does the retirement of SAC-T actually mean and what do you, dear administrator, need to do? As the highest paid consultants will tell you: it depends. In this case it entirely depends on how you roll out your In-Place Upgrades:

ConfigMgr Task Sequences	Nothing
ConfigMgr Software Updates	Nothing
Windows Server Update Services (WSUS)	Nothing
ConfigMgr Servicing Plans	Reconfigure
Windows Update for Business (WUfB)	Reconfigure

I can’t give you actual numbers, you’d have to pester the product group for that, but the overwhelming majority of the ConfigMgr admins that I know are using Task Sequences for their In-Place Upgrades. Those that want to get away from TS’s are testing the waters by manually releasing the Feature Updates as software updates. The retirement of SAC-T means literally nothing to those groups. If I just wasted 30 minutes of your time … I’m sorry … but you can go back to your regularly scheduled programming of Reddit, Twitter, and Slack.

What if I Love my WUfB and Servicing Plans?

If you are one of the few and proud that are using WUfB or Servicing Plans then you do have to consider these changes and probably rework your configuration. However, it’s ridiculously easy to handle since you now only have a single channel to worry. Bump back any existing SAC release rings you have and replace your SAC-T with a SAC ring with a very minimal, if any, delay. Keep in mind that for 1903 and only 1903 they are adding a built-in 60 day additional delay for those configured for SAC. That’s really it. It should take all of 5 minutes of actual real work and 10 hours of change management documentation and review.

The only thing you could truly complain about with this change is that you are losing the increased delay inherent in waiting for CBB/SAC to be released. If you are using ConfigMgr Servicing Plans that’s actually a big deal. With Servicing Plans you can only delay the releases by 120 days so losing 60 days or more is troublesome. For you weirdos here’s a User Voice Item I just cooked up: Bring Servicing Plans into Parity with WUfB/Intune or Kill Them.

If you’re using WUfB then you can delay Feature Updates for 365 days making it less of a problem. If you can’t get a release out in a year then quite frankly you’re not ready for the kind of ‘modern’ environment that WUfB/Servicing Plans are made for. You need to move to Task Sequences or just manually deploying them via Software Updates.

The Moral: We’re Finally There!

The reason I wanted to write this all out in long-form is because it tells a story. A slightly hopeful story even. When Microsoft first announced their WaaS concept in 2015 pretty much every administrator I talked to said it was doomed to fail. You have to crawl before you can walk and Microsoft was expecting a bunch of desk jockeys to compete in a 100 yard dash where losing was a career limiting move.

In 2015 we were given three branches (CB, CBB, LTSB) released whenever Microsoft got around to it and supported for 14 months with roughly 4 of those eaten up waiting for the almost meaningless CBB stamp.

Fast forward to 2019. We now have two channels (SAC and LTSC) that are released on a specified schedule and are supported for up to 30 months. This is exactly what we asked for from the start: fewer releases supported for longer with a schedule we could plan around. This is simple and straightforward. Everyone should be able to understand and plan around this cadence. Instead of wailing and gnashing your teeth because change is happening be glad that we are getting what we wanted in the first place.

Now the task is to start stringing together high quality, trouble-free releases so that we are all comfortable putting the Task Sequences down and start using WUfB/Servicing. When 1809 was released I don’t think I was alone in going to my whiteboard and writing: