Before we can select the best deployment method, we need to select a suitable branch, as one branch implies some timing restrictions due to shorter support timelines, which will be explained now.

Beginning with Windows 10 and its new Windows as a service concept, you can choose between two main flavors. All Windows 10 Home, S, Professional, Pro for Workstation, Enterprise, and Education SKUs support the Current Branch (CB) model. This branch was renamed with Windows 10 1709 to Semi-Annual Channel (Targeted). When Microsoft officially releases a new feature update for Windows 10, that update is marked as CB / Semi-Annual Channel (Targeted).

In this CB model, the system will be updated up to three times a year (don't worry, the Windows 10 product group stated that they normally plan only one to two releases per year). As soon as this CB is available, it will be rolled out to all Windows 10 installations, which will be getting their updates directly from Windows Update (WU) online. The roll out will be done in stacked waves.

If you want to postpone such a roll out, you need to defer feature updates, which is an option only available in Pro, Pro for Workstation, Enterprise, and Education. You can defer updates per GPO when using WU for 1-8 months, or directly inside your Windows Server Update Service (WSUS), System Center Configuration Manager (SCCM), or third-party deployment solution for a even longer time frame.

To distinguish between the different branches, a lot of people use the build numbers. But it is cumbersome to memorize all these builds: 10240, 10586, 14393, and so on. You should use this naming only when speaking of Windows Insider builds.

Also, the code names are not that clear and do not describe at what time a version was released (for example, Threshold 1/2, Redstone 1/2/3, and so on). With the Windows 10 release in 2016, they also introduced public code names such as Anniversary Update or Creators Update. But this is more or less only a way for marketing to describe a future version without already stating the exact release date, which is possibly not fixed at the time of announcing the new version.

When speaking of the defer option, a lot of sources mix it up with the Current Branch for Business (CBB). But this is only partially correct. When a new Windows 10 version is released, it is automatically CB. After around 4 months, when several cumulative updates have ironed out all remaining hiccups or when a newer version is released, the ISOs will be updated and the CB will be declared as CBB. So CBB is not different in its bits and bytes; it's just updated media and a different name.

This branch was renamed with Windows 10 1709 to Semi-Annual Channel.

Organizations can selectively delay CB and CBB updates into as many phases as they wish (also called a ring model) using one of the servicing tools mentioned in the CB section. Deferring a version long enough will result in it being on an older branch than the current CBB. If you now name it just CBB, it could be misleading.

We should instead always speak of a CB or CBB with its version (for example, CBB 1703) or as CBB and CBB+1, where CBB+1 is the older version. I prefer the year year month month (YYMM) versioning. Also naming convention of CBB/CBB+1 will be completely replaced with 1709 by Semi-Annual Channel (Targeted) and Semi-Annual Channel (without any extension). So beginning with Windows 10 1709 we should speak about Semi-Annual Channel 1709.

So, when you are able to defer feature updates as long as you want, how long is such a CBB / Semi-Annual Channel version supported and getting security updates?

Before the release of Windows 10 1709 it was rather complicated, the answer is a minimum of 12 months support, according to Michael Niehaus, Director of Product Marketing for Windows at Microsoft:

Most people were only reading 12 months and getting scared. But in fact, the support time frame can be much longer:

The minimum 12 months' time frame starts at the time when a release gets declared as CBB. So you always get a minimum 4 months of CB (blue bar) + 12 months of CBB (orange bar) + 60 days grace period (grey bar) after a release goes out of support. So each feature update release will be supported and updated for a total time frame of at least 18 months.

Depending on how many releases are done per year, this time frame could be even longer, because a release will be supported as long as there are no more than two CBB versions at the same time. For example, 1511 released in November 2015 got support until 1703 was declared CBB in August 2017, and with an additional grace period of 60 days, it was supported and updated for 24 months in all. (Version 1511 was declared CBB in March 2016, release 1607 was declared CBB in November 2016. When release 1703 was declared CBB, there would have been three CBB versions in the field and so support for the 1511 CBB was dropped and the grace period started.)

In the unlikely event of three releases a year, the other rule of a minimum 12 months' CBB support will jump in, so in all circumstances, you will always get a minimum of 18 months of total support and update time beginning with GA.

All these CBB, CBB+1 and Grace Period phase was more confusing than helping. With the release of Windows 10 1709 a lot of things were made easier. CBB is now named Semi-Annual Channel. And there is no more Grace period, no more calculating, no more dependence on any version release. You will get a fix full support time frame of 18 months.

Windows 10 will be released 2 times a year with a target frame of March and September each. After release each Windows 10 Version will be supported 18 months fix and end of support date will be available on release date or short after.

A lot of enterprise customers requested already longer support time-lines. At the time of writing this book the time was still 18 months. Look out for announcements regarding a longer opt-in time frame after release of 1709.

The Long-Term Servicing Branch (LTSB) has a ten year support time frame, like with former Windows releases. The ten year time frame is also split into five years main support and five years extended support. During this ten year time frame, the LTSB will only get security and quality updates but no feature updates. Stability and not breaking anything are the most critical points.

LTSB versions are only available as Windows 10 Enterprise LTSBs. So if you do not have Windows 10 Enterprise, you won't qualify for LTSB. The version always contains a year in its name. So the first LTSB version created is now referenced as Windows 10 Enterprise LTSB 2015. In 2016, Windows 10 Enterprise LTSB 2016 was released, but don't expect this to be a standard occurrence. Releasing the 2016 version was an exception, and the next LTSB version is not planned for release before 2019. New LTSB releases are planned typically every two or three years. To get new features, you will need to install a newer LTSB version.

IT pros getting nervous when reading about two updates per year at the CB/CBB branch may be tempted to select the LTSB as it seems at first like all the previous Windows versions' support strategies. But there are several risks and limitations when choosing the LTSB.

The LTSB was designed for specialized systems such as controlling medical equipment, point-of-sale systems, and ATMs. These devices typically perform a single important task and don't need feature updates as frequently as other devices.

Maximum compatibility, reliability, and stability are the key focuses of the LTSB, which makes changes to the kernel and system less possible. Using MS Office and other products on your system that would need changes to the system would block a patch. Therefore, you could end up in a situation where the only workaround would be waiting for the next (fixed) LTSB or changing to CB/CBB meanwhile.

At the time of the LTSB 2016 release, the latest processor families were Intel's Kaby Lake and AMD's Kaveri platforms. Newly released processors such as AMD Zen or Intel Cannonlake will most likely not be supported on LTSB 2016 as they will need modifications to the kernel and the system, and this is in conflict with the maximum reliability and compatibility goals.

The LTSB has some more limitations, which the following table summarizes:

Even so, since 1607/LTSB 2016, support has been introduced to perform an in-place upgrade from LTSB to CB/CBB; there is no support yet to perform an in-place upgrade from a down-level OS to LTSB or from CB/CBB to LTSB.

So you could end up in a situation where Kaby Lake and Kaveri are no longer available, but neither is the LTSB version, so you will have an image but no suitable hardware.

With all the limitations and caveats of LTSB, it is best to stay with CB and CBB for most of your PCs. Use LTSB only in situations where long-term maintenance is essential, such as in production lines, point-of-sale systems, and medical control systems. Most enterprise customers decide to roll out CB and CBB on their main general purpose systems and so should you.