Patching every device on the same day is why patching keeps failing

Every IT team I’ve worked with already knows devices need patching. The gap is rarely awareness. It’s logistics: devices that go home overnight and are never on the network long enough to update, staff who click “remind me tomorrow” on the restart prompt for a fortnight straight, and no spare lab to test a patch in before it goes to everyone at once.

Why the instinct under pressure makes it worse

Patch operating systems is one of the eight ASD mitigation strategies. At maturity level one, ACSC’s requirement is patches, updates or mitigations applied within one month of release for workstations, servers and network devices, or within two weeks, 48 hours if there’s a known exploit, for anything internet-facing. That’s a demanding clock against a fleet of laptops that go home, lab machines only switched on during class, and a restart prompt most people dismiss on reflex.

The instinct under that pressure is a big-bang rollout: push everything to everyone and hope. That’s the approach most likely to break something for the whole school on a Monday, and it also removes any early warning if a patch itself turns out to be broken. Even Microsoft’s own delivery infrastructure isn’t immune to that risk: as of mid-2026, Microsoft confirmed a Windows Server Update Services synchronisation fault that had been silently stopping some WSUS servers pulling update metadata since around 13 July 2026, worst immediately before that month’s Patch Tuesday release. A fix shipped for new or rebuilt WSUS servers on 18 July, but existing affected servers needed manual remediation, detailed in Microsoft’s KB5121986. Any school running WSUS is worth checking that its server has actually been syncing since, not assuming it has, since this kind of silent failure is precisely what a staged rollout is designed to catch before it becomes a fleet-wide problem.

The free fix: rings, not a big bang, and the fork is your management model

The fix for the rollout problem isn’t a new tool, it’s a free feature most schools already have and aren’t using: deployment rings, sometimes called servicing rings. Instead of one policy for the whole fleet, devices split into groups and the rollout staggers, so a small low-risk group gets patches first, and the rest follow once nothing’s caught fire.

Which free path applies depends on how the fleet is managed, and this is the fork worth stating plainly rather than assuming one path fits every school. Schools still on-premises with WSUS already have computer groups and client-side targeting built in, at no extra cost: create groups such as Pilot, Broad and Critical, and use Group Policy so devices join the right group automatically by organisational unit rather than being sorted by hand. Schools that are cloud-managed, or moving that way, get the same ring concept through Windows Update for Business, configurable via Group Policy without needing Intune, or through Intune update rings if that licence is already in place. Quality updates can be deferred up to 30 days, feature updates up to 365, so a short or zero deferral suits the pilot ring and a longer one suits anything the school genuinely can’t afford to have misbehave.

The deferral period doubles as a test lab. A dedicated testing environment isn’t necessary if the pilot ring runs a patch for a week or two before anyone else does; if a patch is going to break something, the wider Windows admin community usually finds out before the broad rollout ring does.

Fixing the restart problem, and the population question this control doesn’t carry

Both WSUS-driven and Windows Update for Business environments support deadline and grace period policies: once a patch has been available for a set number of days, the device restarts automatically during active hours, whether the user dismissed the prompt or not. That takes the restart decision out of the user’s hands after a reasonable grace window, rather than leaving it to goodwill and memory.

This control doesn’t carry the student-versus-staff population fork that runs through other editions in this series, patching applies device by device rather than by who’s logged in. What it does require is thinking about device categories: exam computers, reception machines, and anything where an unplanned mid-use reboot would be a real problem belong in a slower, later ring regardless of whether staff or students use them.

Where this leaves you

The test worth putting to your IT team: can they show, today, which ring every device sits in, and how long each ring takes to reach full deployment? If that answer doesn’t exist yet, the patching conversation has been about intent, not process, and process is what actually closes the gap.

Best Practice - This is the way