First let’s get things right: Windows as a Service (WaaS) is NOT a service or a tool; it is a process by which the repeated exercise of updating Windows 10 in small increments results in having less issues because the changes are small enough to get them deployed efficiently.
If you make a big change over a long period of time and there is a problem with that change, it will take a longer time to identify, resolve, test and re-deploy than it would take for a small change. This is one of the principles applied with CI / CD in DevOps (In their “State of DevOps Report,” Puppet details that high-performing DevOps organizations see 200 times more frequent deploys with 24 times faster recovery times).
Microsoft explains WaaS as such:
“This process repeats with each new feature update, twice per year. These are small deployment projects, compared to the big projects that were necessary with the old three-to-five-year Windows release cycles.”
Windows 10 new feature updates are made Generally Available (GA) twice a year: in March and in September (sometimes it may be delayed by a couple of weeks). For Enterprise Editions, the March update is supported for 18 months while the September update is supported for 30 months (source: https://support.microsoft.com/en-au/help/13853/windows-lifecycle-fact-sheet). One might ask why there are 2 updates and why aren’t they both 18 or 30 months? Why aren’t they exactly 2 years or 3 years instead of being shy of just 6 months each?
Depending on how you look at it, you might find a reason for this that does make sense. In terms of security especially, Microsoft does explain that before it releases an update, tests for the update are done on a fully patched OS. This is not the reality for many organizations out there that will apply the new update. Hence, each time you update your OS to the latest Feature update, or to the latest Quality update, your OS will be 100% updated and patched with the latest security patches (Feature and Quality updates will be discussed in detail in Part 2 of this series on WaaS).
Source: https://docs.microsoft.com/en-us/windows/deployment/update/waas-overview
Once you’ve applied a feature update, be it the March or the September release, you will still have to apply the Quality updates on a monthly basis over the course of the support lifecycle of that update or until the next feature update. For example, if you install Windows 10 1903, you’ll be applying Quality updates each month until September 2020.
Note: Since the 1903 was not available until May 2019, it is supported until December 2020.
If you have a small organization, this can be quite easy to handle. But what if you have a significant number of devices that encompass multiple hardware models, various chassis, in multiple network locations, etc. At this point you need to be aggressively more organized in your Windows 10 update deployments and you need as much automation as possible. You wouldn’t want to send 6 or 7 Gb to 500 or 700 devices across a WAN link. Neither would you want to have a single device on that distant network be used as a caching source (I’m referring to the Peer Cache Source feature): It would render that device simply unusable. And you wouldn’t want to hire technicians on a full-time basis just to continuously deploy the update; make it available for the user to update his/her own device at his/her own time provided with a deadline date is a more feasible and cost effective solution.
So how would you go about this? There is no definite answer because there are so many factors to take into consideration that the number of solutions can grow very quickly. You also don’t want to have 20 different methods of deploying your Windows 10 update but 2 or even 3 is in my opinion a manageable number of deployment scenarios when you are dealing with 20 000 to 50 000 devices or more.
If you think about it, in a 50 000 devices environment, you would have to deploy 75 devices per day on average continuously over the 30 month support period or, 126 devices per day on average continuously over the 18 month support period (depending on which feature update you choose to deploy).
Note: If you follow this cadence, your upgraded devices will be out of support in no time at the end of your deployment. So, you need to overlap your builds to have all your devices remain in support. This is discussed in Part 6 of this series.
Think of the effort that must be put it in terms of scheduling if you had to perform a “Lite Touch Deployment” (which means that a human action is required), especially if your organization has some business critical devices that require 24hrs usage or ones that can be accessed only outside business hours. You’d have to organize physical access (devices could be in a metal cabinet in a public space for instance), security access if the device is behind a bank teller for example, communication to the various stakeholders to let them know that an upgrade of their system is occurring on such and such date, holidays, etc.
In this blog series, I will attempt to provide an explanation of Windows as a Service and what are some of the different available tools that would facilitate a smooth deployment of Windows 10 feature updates.
