Update to the Windows as a Service Model

Hi together,

as you have probably read in the news we have slightly modified the Servicing Model.
This is the continuance of my previous article "Demystifying Windows as a Service - wake up! please."

TL;DR;

The Windows as a Service model has been simplified. Every OS Version is 18 months supported and the releases will be published twice a year in March and September. The naming convention will be changed into "channels" - so we will release in a semi-annual channel. The LTSB will be renamed into Long-Term-Servicing-Channel (LTSC). CB will be simply renamed to the OS release and CBB will be published as ready for broad deployment between 3 to 5 months after the official OS release and it does not have any impact on the supportability times - they will always stay at 18 months for each OS version.

Let´s take a closer look how this will look like:

As you can see the + marks the release of the OS version. Before that you can take a look at the Insider Preview and the blue part is the "ready for broad deployment" area. With the defined supportability time frame of 18 months you can now plan in an organized manner and set up recurring processes which can then be automated.

You should also recognize that skipping one OS-Version seems to be theoretically possible, but keep in mind that you will have nearly no time buffer if you take a look at a dedicated machine and want to deploy it at the same timespot as before:

In this example you see a dedicated computer (or collection) which is upgraded slightly after the "ready for broad deployment" statement. Let´s say this is 10 days after the ready for broad deployment statement for the current available feature update - for each feature update - because you still need the same time to develop your client, create the GPOs and so on. So you will probably target the same timeframe for the overnext release as you see in the picture with "Upgrade Machine" and the two darkblue arrows.

The dotted line just shows the problem - you don´t have the time to actually do this. Even worse - even if you try pushing out the overnext version to an earlier timepoint this won´t help, because the time buffer is still too small and potentially risky. This brings us to the next picture targetting every Windows version and trying to automate things:

Here you see an example for a dedicated computer (or collection) which receives its feature update the same time after an event, which is here the "ready for broad deployment" statement starting in blue. The recurring process publishes the upgrade always 10 days after this event for this specific collection and there should be no manual workload to achieve this. I will dive into the automation part in the upcoming blog articles and I hope that I clarified till here the changes made.

Summary:

Despite the naming convention it is just a slightly and simplifying change.

Stay tuned,

David das Neves

Premier Field Engineer, EMEA, Germany
Windows Client, PowerShell, Security