Previous blogs in this series:
The below process chart might look very familiar as it is used over and over in many Microsoft events but, given everything I’ve discussed in this blog series, I think it will make a lot more sense now.
Scheduling it juuuuust right!
Windows 10 feature updates are deployed semi-annually, and we’ve seen that the March update is supported for 18 months as opposed to the 30 months support for the September update (https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet and https://docs.microsoft.com/en-us/windows/release-information/). If your organization is small, say 300 systems, you might be able to update your entire fleet in about 2 months at a rate of about 7 upgrades per day. However, if you have 3 000 devices, you need to upgrade 70 per day for 2 months to complete the entire fleet. What if you had 30 000 systems and your organization’s policy is to be 90% updated within 2 months of a feature update release… That’s 700 devices a day!
If you are prepared, it can be done. For example, when Microsoft releases a feature update, 700 million devices worldwide receive it in less than a month (source: https://techcommunity.microsoft.com/t5/microsoft-ignite-the-tour-2019/streamline-and-stay-current-with-windows-10-and-office-365/m-p/907358). Additionally, the more you get used to this process and repeat it over and over (not just deployment rings but phased deployments as well), the more confident you will become, the easier it will get, and the number of issues will reduce over time. The question you need to ask yourself is: Do I want – and are you allowed – to deploy the new feature upgrade in a very short time leaving you with a gap of non-deployment time until the next feature update is released or, do you prefer to continuously update… forever!
Here’s what I mean:
Scenario 1: Deploy the September updates only and benefit from the 30 months support (on Enterprise and Education editions only)
If you opt to continuously deploy the September updates as they are released, it means that your build will be supported from September of any given year to March two and a half years later. For example, if you deploy Windows 10 1909 (released in 2019), it will be supported until March 2021. This means that you cannot wait for build 2109 because it will be September 2021 and you will be out of support by then. Therefore,
Yyou have to repeat the process for build 2009 so that, by the time you start deploying to your Broad ring (in January of 2021), your devices are still supported whether they have build 1909 or build 2009.
Your deployment rings will be somewhat like the below duration estimates (based on a 1909 build deployment):
As you might have guessed it, there will be an overlap between the 1909 and the 2009 because when you start your Broad deployment say in January 2020, you can focus on its success for about 3 months before you start the whole process again with the Insider Ring for build 2009.
It is therefore essential that your first 3 months of Broad deployment include systems that are also very much a representation of the following 6 months and that your desktop support department is on alert during this period.
Scenario 2: Deploy the March updates only and benefit from the 18 months support (All editions)
If you are deploying only the March updates and you are continuously deploying to your fleet, then the time you have between each process loop is even shorter than Scenario 1. March feature updates are supported until September of the next year; So, build 1903 was release on the 21st of May 2019 (yes it was almost 2 months late!) and is supported until the 8th of December 2020. In this case you don’t have a choice but to repeat the process on a yearly basis just like for Scenario 1. The only difference is that your Pilot and Broad deployment rings will be shorter in duration.
Scenario 3: Deploy as the feature updates are released
With this scenario, you will basically never go out of support if you have your Broad deployment groups properly configured. Think about it: You will end up having to organize your deployment groups in such a way that your entire fleet is updated before the next release. In other words, you are combining Scenarios 1 & 2.
To sum up, depending on the size of your organization and your business-critical applications, it seems that Windows as a Service is one big scheduling board doesn’t it? With various triggers, milestones, durations and targets that you must think about according to your organization’s compliance requirements on getting current and staying current.
At Cubesys, we are dedicated to helping you investigate the best approach to map your business requirements to the WaaS concept. We will help you design a process that will be in line with Windows servicing using the right combination of management services, tools, reports and automation so you can focus on the things that are important to your business.
Next week: Manage your upgrade readiness with Desktop Analytics.