Windows 11 24H2 Update: What Changed and What to Check Before You Deploy It
Three office machines out of twelve came back from the 24H2 feature update with something broken. That is roughly the failure rate I plan for now, and it shapes how I roll these things out. Not a disaster, not smooth either. If you are the person who gets the call when a user’s VPN stops connecting or a shared printer disappears, this is the update you want to stage rather than push.
Here is what actually changes under the hood, what tends to break, and the checks I run before letting 24H2 loose on a floor of non-technical staff.
What 24H2 actually changes
It is a full feature update, not a monthly patch, so treat it like a version upgrade. The headline items are mostly cosmetic or convenience: more controls in the taskbar and system tray, tighter integration of Copilot into the shell, and a handful of new privacy and energy settings. Microsoft has also tightened the hardware floor. Machines without the required security chip simply will not be offered the update through Windows Update, which is Microsoft’s way of quietly retiring older hardware from the upgrade path.
The behavioural changes matter more than the marketing ones. Several legacy components get less tolerant of old configurations. Networking stacks, certificate handling, and the way the OS talks to certain VPN clients have all seen adjustments in this release cycle. That is where the support tickets come from.
The failures I keep seeing
VPN breakage tops the list. Microsoft has a documented pattern of security updates in this release train interfering with Always On VPN connections, and that class of problem is exactly what bites remote workers. If your staff tunnel into the office through a third-party client rather than the built-in one, check the vendor’s compatibility notes for 24H2 before you touch anything. A VPN client that worked on 23H2 is not guaranteed to connect after the upgrade, and the user will not know why.
Printers are the second recurring headache. Driver packages that shipped with older hardware sometimes fail to re-register after a feature update, and the printer simply vanishes from the list. The fix is usually a fresh driver from the manufacturer, but you want to know which machines are affected before the user does, not after.
Third on my list is anything that hooks deeply into the shell: old backup agents, legacy antivirus, custom login scripts. Feature updates rewrite portions of the system that these tools rely on. If a piece of software has not been updated in two years, assume it will misbehave and test it in a virtual machine first.
Run these checks before you deploy
The order matters. Do the cheap checks first, because they catch most of the problems before you spend a weekend imaging machines.
- Confirm the hardware qualifies. Open Settings, then System, then About, and check the processor and installed RAM against Microsoft’s stated requirements. Then check for the security chip requirement. If the machine does not meet it, Windows Update will not offer 24H2 anyway, and you should plan a hardware refresh rather than fight it.
- Inventory your VPN clients. Note the exact version on every machine that connects remotely. Cross-reference against the vendor’s 24H2 support page. Any client without a stated compatible version gets held back.
- List your printers and their drivers. For each shared printer, find the current driver from the manufacturer and have it downloaded and ready. Do not rely on Windows to fetch it after the fact, because it often will not.
- Check free disk space. A feature update needs working room. Microsoft’s own guidance points to Storage Sense and Disk Cleanup for reclaiming space. Run Storage Sense from Settings, then System, then Storage, and clear temporary files. A machine limping along with a nearly full drive is the one most likely to fail mid-upgrade and leave you reinstalling.
- Run a malware scan. It sounds like boilerplate, but an infected machine that upgrades cleanly can still behave strangely afterward, and you will waste hours blaming the update. A quick scan through Windows Security takes minutes.
- Remove software nobody uses. Settings, then Apps, then Installed apps. Every old program you uninstall is one less compatibility variable. I have watched a forgotten screen-recording tool block an upgrade because its driver refused to load.
Settings worth reviewing first
While you are in Settings, take five minutes on the privacy side. The optional diagnostic data, the inking and typing improvements, and the personalised search results are all things you can turn off without breaking anything. Go to Privacy and security, then Diagnostic and feedback, and switch off the optional collection. If your organisation has a policy about data leaving the building, this is the moment to align the machines with it, because the update sometimes resets preferences to defaults.
Do this before the upgrade, not after. Once the user is staring at a fresh install, they will not want you poking around in privacy menus.
How I roll it out
I pick one machine per department, ideally the user who is most patient and least likely to email me in a panic. That machine gets the update first, and I check three things the next morning: does it boot normally, does the VPN connect, and does the shared printer print. Those three cover the overwhelming majority of real-world failures.
If that machine survives a full working day, I expand to the rest in small batches of three or four, spaced a day apart. This is not caution for its own sake. It is about keeping the failure blast radius small and keeping my own workload sane. When something breaks, you want to know exactly which batch caused it.
For the machines that fail the compatibility check, do not force the upgrade. A machine that Microsoft will not offer 24H2 to is a machine that will likely run it badly. Plan the replacement, or keep it on the previous branch until it retires.
What to have ready on the day
Before you start, confirm that you can restore a machine quickly. Know where your restore media is and that it works. Know the local admin password. Know which user data lives only on the local drive and needs backing up first, because a failed feature update can leave the system unbootable and the recovery partition is not always enough.
The 24H2 update is not hostile, but it is a version jump, and version jumps break things that monthly patches do not. Run the checks, stage the rollout, and keep one machine back as your canary. That habit has saved me more than any single piece of software.