Patching Without Fear: Rings, Risk and a Way Back

The first version of this post was a tidy list of ten update types, each with a recommended action and a "problem occurrence" percentage. Feature updates, 10 to 20 percent. Drivers, 15 to 25. It looked very official.

I don't trust those numbers anymore, and you shouldn't either. They were gut feel dressed up as data. The real failure rate for any update depends almost entirely on your hardware, your apps and how weird your environment is. What holds up better is a way of thinking about risk that works no matter what the numbers turn out to be.

Sort by blast radius, not by label

Microsoft's categories matter less than they used to. Since Windows 10, security and quality fixes ship together in one monthly cumulative update, so "critical vs. security vs. quality" mostly collapsed into a single decision each Patch Tuesday. Service packs are history. What's worth sorting on is how much can break, and how hard it is to undo.

• Defender definitions are small, frequent and low risk. Let them flow automatically. The rare bad one gets pulled by Microsoft faster than you could have tested it.
• The monthly cumulative update is the big one. It touches everything, which is why it deserves rings.
• Optional preview updates (the non-security release late in the month) are next month's fixes, early. They're great in a test ring and a gamble anywhere else.
• Feature updates come once a year and change the most. Treat each one like a small OS migration, because that's basically what it is.
• Drivers and firmware are where the scary stories come from. A bad display driver is an annoyance. A bad BIOS update can turn a laptop into a paperweight, and there's often no rolling it back.

Rings, and who belongs in them

A ring is just a group of machines that gets an update before the next group does. Three or four is plenty:

Ring	Who's in it	When
1. Pilot	IT's own machines and a couple of test boxes.	Day zero or one.
2. Early adopters	Roughly a tenth of the fleet.	A few days later.
3. Broad	Everyone else.	About a week in.
4. Sensitive	The servers and the systems that can't have a bad day.	Last. Last, not never.

Heads up

The mistake I see most is building the pilot out of whoever complains least. You want the opposite: every hardware model you own, every line-of-business app that matters, a VPN user, someone with three monitors and a docking station from 2019. A pilot that looks like the fleet catches problems. A pilot of identical desktops just tells you identical desktops are fine.

Intune update rings and Windows Update for Business deployment rings handle this with deferral days. In ConfigMgr, it's automatic deployment rules with staggered deadlines, or phased deployments if you want it to wait for success before moving on.

Decide what "bad" means before you start

"Nobody's complained yet" isn't a success criterion. Before a ring goes, know what you're watching:

• install failure rate,
• machines stuck in a reboot loop,
• help desk tickets that mention the update,
• a smoke test of the three apps that would really ruin your week.

And decide the pause threshold ahead of time. Deciding it mid-incident, while people are yelling, never goes well.

Know your way back

Rollback is the part people plan last, and it's the part that saves you. A few facts worth having in your pocket:

• Cumulative updates now ship combined with the servicing stack update, so wusa /uninstall often won't remove them. You need DISM with the package name from DISM /Online /Get-Packages.
• Known Issue Rollback lets Microsoft switch off a broken non-security change without anyone uninstalling anything. On managed devices, you apply it by deploying the Group Policy that Microsoft publishes for that issue.
• Feature updates can be rolled back for 10 days by default. DISM /Online /Set-OSUninstallWindow can stretch that to 60, which is worth doing for your early rings.
• Pausing in Windows Update for Business buys you up to 35 days. Know where that button is before the day you need it.
• Firmware mostly doesn't go back. That's exactly why it gets the smallest pilot and the slowest rollout.

Tip

For servers, a snapshot or backup taken right before patching is still the most reliable undo button there is.

When to throw the plan out

When something is being actively exploited, the math flips. Waiting a week for the broad ring is a risk too, and sometimes it's the bigger one. Squeeze the rings into hours, accept that you'll probably find a problem or two in production, and patch anyway. The whole point of a calm, boring process for normal months is having the room to move fast in the abnormal ones.

That's really the goal. Patching should be dull. If every Patch Tuesday feels like an event, the process is what needs fixing, not the updates.