Freigeben über

Update to the Windows as a Service Model

  • Artikel

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

Comments

  • Anonymous
    August 28, 2017
    If you have windows update for business, you have delay set for 180 days and during that time 2 feature updates come out, will you receive the latest feature update or the older one?
    • Anonymous
      September 01, 2017
      Good question - needs to be tested, but this needs to be much more than 180 days to happen. SACT = 4 months, every new release 6 months in between - so this will very rarely happen. 6+6 (for having two releases to possibly skip one) +4 (SACT) = 16 Months.
  • Anonymous
    February 04, 2018
    The comment has been removed
    • Anonymous
      February 06, 2018
      Hi Georges,Thank you for your feedback.1) Sorry for that - working on that ;)2) It is completely transparent what data is being sent to Microsoft. You can actually take a dedicated look at it with the Diagnostic Data Viewer. I get your point, but there is nothing to gain with this model in comparison to the old model. Either you go for E3 or E5 - that´s it. WaaS is more the preparation for all features into the Modern IT field, especially targeting also the newer ones. So, if you stick to your E3 model, the effective costs keep the same. The supporting time frame is more an agile approach to deliver always a current version and to avoid the errors from the past, where every customer could stick on an OS almost forever and decide for each security update, which to integrate or not. This is from a developer and also supporter point of view just hilarious. Just curious - we are the very last ones to move on that type of model. The complete IT is sitting on these approaches - Linux, Apple OSs and also other ones are pushing its servicing time frames: Citrix, Java [...]What makes Microsoft different here? Because we did it 20 years the old way, IT people are just afraid of changes and try to eagerly stick to their old behaviors. Its time for Digital Transformation - take the chance with WaaS, clean the old mess up and place in good new processes with a focus to Digital Transformation; otherwise you will still stick to your old approaches for 5 years and wonder, why you are not able to adopt Modern IT or you are having dramatic problems with security. All the best,David