So back in 2019, when I first go back into blogging, I wrote a piece on how we at my former employer adopted a modern approach to digital workplace, transitioning into a more Windows as a service concept internally. If you have missed this post, please pause here and head over the post here and read it.
Staying current in the new world – olastrom.com
I wrote that post more than 5 years ago, in a world where Configuration Manager was still king and we were running Windows 10 in a large enterprise (over 35 000 managed Windows devices globally). We never ran the feature upgrades as projects, and neither should you!
This post discussed they way Windows updates work for Windows 10, that we will see continuous innovation with several updates per year. Back then, Microsoft was still doing a spring and a fall release. This was a challenge to keep up with, and many reverted to “let’s at try to do one update per year” which for many was still a challenge. If you had this strategy, you usually went with the fall release since that was supported for longer than the spring release.
Since 2021, Microsoft only does one update per year, which so far has always been a fall update. Each release is supported for 36 months, given that you run Windows Enterprise.
But let’s talk about strategy to handle the Windows update cadence.
Find your tools
Since I’m a big cloud advocate, I will of course recommend to use Windows Update for Business to manage your Windows updates. This is also the recommended way by Microsoft, regardless if you are using Microsoft Intune or Configuration Manager to manage your devices. There is no reason to micro-manage the updates for the vast majority of your devices (there are of course exceptions), and since Windows 10 you cant really say no to update since they are all cumulative. If you skip the October patch, you will get them and bunch of more updates in November.
So making use of the cloud and the smart logics actually built into these tools are great.
If you really want to automate things, you can even move to Windows Autopatch which is almost like doing a set and forget setup. Microsoft will manage your whole setup and make sure your devices are kept up to date, and not updated all at once by using automated rings.
But I really hope that you all have your monthly patching in order. Otherwise we have a different level of problem. So lets pivot and talk about the feature updates which is released once per year, what is often referred to as the 23h2 or 24h2 update by the IT community.
What is a good practice?
So if we look back at my old post, I actually talked about using deployment rings which is still a thing (if you look at how Autopatch configures it self, it will use rings).
Whats important here is to devide this into several deployments, so we dont update everyone at the same time. A good practive could be:
Ring 0: First evaluation group
Ring 1: Second evaluation group/application testers
Ring 2: Pilot group
Ring 3: Broad deployment
Ring 4: Devices which needs extra attention
I think that in my original post I had 5 groups, but you can adopt this based on the size of your organization. The purpose of the first 3 groups in this scenario is validate and make sure we catch any compability issues. Any device you find that is cumbersome, or application which need additional testing or validation, you put in the last group to “buy time”. I By doing this, you don’t postpone the update for devices where this will work without any issues.
But what if there are known issues with a certian device model? Well then Microsoft has implememnted something called safeguard hold which will pause the update for the affected devices, so we don’t brake devices and cause issues for the end user. If you want to read more about this, this is a great article covering this.
Safeguard holds for Windows | Microsoft Learn
By utilizing safeguard holds, we can increase the trust in that updates will work since the Windows Update service will block any devices with known issues from recieveing updates. This is also a strong argument to move towards Windows Update instead of using e.g. Windows Server Update Services (WSUS) to handle your updates since it will prevent those supprises. There are also a bunch of reports you can utilize to keep track of any safeguard holds you might be affected by.
Setting up Windows Update for Business
Windows Update for Business can be configured in a few different places. The best way, even if you are using Configuration Manager, is to utilize Microsoft Intune for this. If you are in a hybrid state, move the toggle in Configuration Manager to move the co-managed workload to for Windows Updates to Microsoft Intune. In Microsoft Intune, you then configure your different rings (the number depends on your needs, but at least three). There are many good guides around how to build this, even pre-made ones you can import from e.g. Open Intune Baseline.
You can also enable Windows Autopatch which will create all the rings for you and populate all the groups.
The important part is to create the rings and divide your devices amongst those rings, putting the correct devices in the correct rings. What is correct is based on your needs and your environment, there is no right or wrong here. In these rings you also define the amount of deferal days you want.
Deferal days are the amount of days you want to postpone the update from the release date. There are a lot of different opinions on the cadence here, but it could be a good idea to aim to have ring 0 running the new update within the first two weeks to start evaluating. Then aim to have moved through the rings to your broad deployment within 3-4 months. There is usually no need to rush things, since we need to combine this with end-user communications to communicate any changes in the operating system. If you want to have broad deployments around 5-6 months later, that is perfectly fine to. This comes down to how fast you as an organization can move. But keep in mind that your “upgrade later” group, my ring 4, needs to be even further away. However, the ambition is that this ring should always be empty so as problems gets resolved you move those devices back to the earlier rings.
What is important to keep in mind, is that you need to be able to repet this process every year on a 12 month cycle. So don’t build it to complex!
What is the point behind this post?
My idea behind revisiting this topic is that I still see a lot of companies struggle with this concept. Feature updates are handled as projects and treated as something that is scary.
We have had great tools to manage this for several years now, and Microsoft has done a great job improving on these tools over the years, giving us more options and better reporting.
It’s about time that we stop micro-manage our Windows updates and put out trust into the tools, so we can spend our time doing something more productive than running project to catch up with the feature updates. If we fall one or two versions behind, we all of a sudden need to catch up and then it becomes a project.
I also want to highlight that I’m not just pushing the Microsoft message here. I have worked with several large customers who runs this smoothly as part of their daily operations. Once a Feature update is released, the process kicks in and ring 0 gets the update within a few days to validate that nothing breaks, and then it starts moving between the rings. Not everyone fully automates their rings, but the concept is still there and no internal projects to upgrade Windows is initiated. It’s all business as usual.
So creating a great strategy to handle Windows updates going forward is key, envisioning that “Windows as a Service” which we talked about a few years back, where Windows just keeps evolving and we don’t have to spend that much time thinking about updates.
