Every Windows feature release lands the same way in an office: someone in IT clicks “check for updates,” and by Friday half the building is running a different build than the other half. Windows 11 25H2 is rolling out now, and before you push it to a room full of workstations, there are a few things worth checking on a test box first. I’ve been burned by enough “minor” updates to stop trusting the label.
This isn’t a review of 25H2. It’s the checklist I actually run before rolling a Windows feature update across machines that people depend on to do their jobs. Driver state, installer paths, privacy defaults, startup load. All of it matters more on a fleet than it does on your personal laptop.
Confirm the driver baseline before you touch the build number
Feature updates have a nasty habit of refreshing device drivers. Sometimes that’s fine. Sometimes your print server driver, your USB dock firmware, or that one weird NIC in the conference room stops cooperating. The safe move is to snapshot your driver state before the update and compare after.
Open Device Manager and look for any yellow bangs. If you’ve been ignoring a problem device for six months, fix it now. An update on top of a broken driver stack is how you end up with machines that won’t wake from sleep.
- Export your current driver list using
pnputil /enum-driversfrom an admin prompt, or a tool like DriverView. Keep the output somewhere you can compare it to. - Check manufacturer pages for your specific model. Dell, Lenovo, and HP usually publish a “Windows 11 25H2 supported” note within weeks. Update regularly, per every reasonable guide on the topic.
- Do not use a driver updater on production machines right before a feature update. If a driver updater pushes something broken, you’ve now got two variables to debug at once.
I’ll say it plainly: the week of a feature update is the wrong week to “refresh all drivers.” Hold that maintenance window.
Audit what launches at startup, because 25H2 will re-enable some of it
Feature updates have a well-documented tendency to bring back things you deliberately disabled. Edge startup boost. OneDrive auto-launch. Teams (still). A feature update on a machine with a dozen startup entries turns a five-second login into forty seconds, and the user blames you, not Microsoft.
Before you push, walk each machine’s startup list in Task Manager (Ctrl+Shift+Esc, Startup tab) and note what’s enabled. After the update, walk it again. Then trim. Startup program management is the single highest-return cleanup you can do on a fleet, and it’s low-risk. Disabling a startup entry doesn’t uninstall anything. If something breaks, you re-enable it.
Pair that with Storage Sense on your image. It’s built into Windows 11 under Settings > System > Storage and clears temp files and Recycle Bin automatically. On a fleet, that alone keeps the C: drive from silently filling between updates.
Lock down diagnostics defaults before deployment, not after
Here’s the thing that actually annoys me about feature updates: privacy defaults sometimes reset to “send optional diagnostic data.” That’s the drop-down you turned off in Settings > Privacy & security > Diagnostic & feedback six months ago. Optional data includes app activity and can include browsing history. Microsoft’s minimum required data is not optional, but the extra stuff is.
On a single PC, you’d just open Settings and turn off the optional toggle plus “Improve inking and typing.” On a fleet, do it with Group Policy or a registry policy, so the update can’t quietly undo your work. If you’re not running domain policy, a tool like Windows Privacy Dashboard or O&O ShutUp10 still handles this in a couple of minutes on a per-machine basis, and each setting is described in plain language. I keep one around for one-off boxes.
Worth saying directly: turning these off won’t break functionality. That’s the source I trust most on this point. It’s just less data about your users leaving the building.
Sanity-check your installers and install paths
Before you upgrade fifty machines, run your full app install script on one test machine running 25H2. I’ve watched feature updates break silent installer flags, mangle paths under Program Files, and cause setup wizards to trip over a changed environment. None of that shows up in a “supports Windows 11” claim on a vendor’s site.
On my own test box I install the usual stack: 7-Zip for archive handling, the standard Visual C++ Redistributable bundle and DirectX runtime for the older games and CAD tools that still expect them, and whatever management agent the org uses. Runtime libraries are the classic silent failure. A machine that “runs fine” until someone opens a legacy app and gets a missing DLL is a machine that wasn’t tested properly.
Also verify your uninstall paths. Windows 11’s Settings > Apps has been the default uninstaller for a while, but feature updates sometimes orphan registry entries. Run an installer, confirm it launches, uninstall it cleanly. If the uninstaller leaves junk behind, fix your script now, before it’s on fifty machines.
What I’d actually do on rollout week
- Pick one sacrificial machine. A user who tolerates a reboot, ideally someone using the same apps and hardware model as your trouble cases.
- Update it, reboot twice, then log in and open every app that matters. Twice. The second reboot catches things the first one misses more often than you’d think.
- Compare Device Manager, startup list, and privacy toggles against your pre-update snapshot.
- Then stage the rollout in small batches. Ten machines, live with them a week, expand.
The Windows 11 25H2 push is not scary. It’s just a feature update, and feature updates are exactly where small configuration drift turns into a helpdesk ticket queue. Do the audit before the roll-out, not after, and the rollout is quiet. That’s the only outcome you want to hear about from the office.