Your Patch Tuesday email lands, it says "confirm the build number matches," and that instruction is where most validation actually falls apart. Checking winver on the one laptop next to you tells you nothing about the other few hundred devices in your fleet - and even on a device that is on the right build, some of this month's new features might just not be there yet. Both of those are expected, not bugs, and this post explains why - plus a script to check the real answer instead of eyeballing it.
The problem: "confirm the build number" isn't a fleet-scale instruction
Two updates shipped this month:
| Branch | KB | Build |
|---|---|---|
| Windows 11, version 25H2 | KB5121003 | 26200.9168 |
| Windows 11, version 24H2 | KB5121003 | 26100.9168 |
| Windows 11, version 23H2 | KB5120240 | 22631.7517 |
"Confirm the build number matches" is correct advice - but doing it by hand, one device at a time, doesn't scale, and it doesn't tell you the whole story anyway. A device can genuinely be on build 26200.9168 and still not show the new File Explorer or Windows Search behaviour described below. That's not a failed install. It's a second, separate mechanism working exactly as designed - and if you don't know about it, you'll spend time chasing a "missing feature" that was never going to be there yet regardless of the build number.
Why it happens: two different things determine what a device shows you
The build number only updates after the cumulative update package has fully applied and the device has rebooted. Windows Update can report a device as "up to date" the moment the download and initial install steps finish - the actual build number in the registry (CurrentBuildNumber + UBR) doesn't increment until the pending servicing operation completes on next restart. A device sitting at "restart required" for two days is not lying about being patched, but it also isn't at the new build yet.
The features are a separate mechanism entirely. Most of the File Explorer, Search, Widgets, and Touchpad changes in KB5121003 aren't gated by the update package at all - the code ships inside the KB for every device, then Microsoft turns each feature on remotely, in stages, over the following weeks, using what's usually called Controlled Feature Rollout. Two devices on the identical build can show completely different feature sets because one has been flighted on and the other hasn't, yet - Microsoft's own release notes say as much: several changes "roll out gradually" and won't appear on every device immediately. There's no local registry flag you can query to check where a given device sits in that rollout; the only way to know is to look at the device itself.
How to verify: read the real build number, not the Windows Update status page
The registry values Windows Update itself is ultimately reporting from are CurrentBuild and UBR under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion, alongside DisplayVersion for the branch (23H2/24H2/25H2). Reading these directly is faster and more reliable than parsing Settings › Windows Update, especially at fleet scale via Intune or a login script.
That real result is genuinely useful here: this device's branch is 25H2, so the expected build is 26200.9168 - and at 26200.8875, it hasn't landed yet. That's a normal, honest "not yet," not a broken update - the point of checking the real number is exactly to catch this distinction before assuming the fleet is done.
Don't rely on Get-HotFix to confirm the KB installed - cumulative updates for 24H2/25H2 frequently don't enumerate through that legacy API even on a fully compliant device. The build number comparison above is the authoritative check; treat Get-HotFix as a nice-to-have, not the source of truth.
Registry keys behind build state and update policy
The build/branch values shown earlier come straight from the registry - and so does the answer to "is a reboot actually pending?" Two different Windows components each keep their own independent flag for this, plus a third, more general mechanism that gets confused with them, and a fourth key showing where a deferral policy actually lands on disk. Here is each one on its own, in plain English, with its complete path:
CBS is the Windows component that physically replaces system files during a patch. Some files are locked while Windows is running, so CBS stages the replacement and creates this key as a flag: "I have a pending file swap that needs a restart to finish."
Healthy: key does not exist. If wrong: key exists = a CBS servicing operation is waiting on a reboot.
This is a second, independent reboot flag - not from CBS, but from the Windows Update client component itself. When Windows Update finishes installing a patch and decides a restart is needed, it creates this key. CBS and Windows Update each track "reboot owed" separately, which is exactly why you check both rather than assuming one implies the other.
Healthy: key does not exist. If wrong: key exists = Windows Update is waiting on a reboot.
This is a generic "rename this file the next time Windows boots" queue that any program can use when a file is locked and can't be replaced live - not just Windows Update. See the real test-device gotcha below: this key can be non-empty for reasons that have nothing to do with a patch.
Healthy: absent or empty (REG_MULTI_SZ value type). If wrong: a value is present - but don't assume that alone means a Windows Update reboot is pending.
When you set "wait N days before installing quality updates" in an Intune Update ring, this is the value that policy actually resolves to on the device. It's the on-disk proof the policy genuinely reached this machine, rather than just showing as assigned in the Intune portal.
PolicyManager\default\Update key is not where the live value lives - on a real managed device it typically holds nothing but internal wnfStateName entries. The resolved, currently-effective value for a device-wide MDM policy is under PolicyManager\current\device\<Area>\<Setting> - check there, not default\.Healthy: matches your intended deferral value. If wrong: value absent = no deferral policy has landed here yet; the device will install as soon as an update is offered.
Real finding from this series' test device: both Windows Update-specific reboot flags read False, but PendingFileRenameOperations still has an entry - a queued rename from an unrelated IME/language-pack cache operation. This is the actual gotcha in relying on that key alone: a non-empty PendingFileRenameOperations does not by itself mean a Windows Update reboot is outstanding. Check all three together, and treat CBS/WU flags as the authoritative pair for patch-specific reboots.
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate - while an MDM/Intune-delivered policy resolves through PolicyManager\default\ (device-wide) and PolicyManager\current\{AreaGUID} (the merged, currently-effective value). If GPO and Intune both target the same setting, check PolicyManager\current\ to see which one actually won.Event ID catalog: install, download and servicing state
Two log channels between them cover the update lifecycle end to end - detection/download/install activity, and the lower-level servicing operations that sometimes need their own reboot:
| Log & Event ID | Level | Meaning |
|---|---|---|
| 19 - WindowsUpdateClient/Operational | Information | Installation successful - Windows Update Agent installed the update |
| 20 - WindowsUpdateClient/Operational | Error | Installation failure - Windows failed to install the update, with an error code in the event body |
| 31 - WindowsUpdateClient/Operational | Warning/Error | Scan failure - the device could not complete a detection pass against Windows Update |
| 4383 - Servicing | Information | Component-Based Servicing (CBS) completed changing an update's package state successfully |
| 4386 - Servicing | Warning | CBS requires a reboot to finish changing an update's package state - the low-level reason behind a "restart required" prompt |
The fix: a build-compliance check plus a repeatable smoke test
Context: "the fix" here isn't a setting to change - it's two things: a way to confirm compliance at scale instead of by eye, and a validation checklist that separates a genuine regression from an expected gradual-rollout gap.
Controlling when updates like this reach your fleet is a real, configurable policy, and it exists in both Intune and Group Policy:
- Intune (Settings Catalog / Update rings for Windows 10 and later) - the
Update/DeferQualityUpdatesPeriodInDaysandUpdate/DeferFeatureUpdatesPeriodInDaysCSP nodes, exposed as "Deferral period" fields in an Update ring profile, control how many days a device waits after Microsoft's release before installing. - Group Policy - Computer Configuration › Administrative Templates › Windows Components › Windows Update › Manage updates offered from Windows Update › Select when Quality Updates are received (and the equivalent Feature Updates policy) sets the same deferral, GPO-side.
To configure a deferral ring via Intune:
- Sign in to intune.microsoft.com.
- Go to Devices › Windows › Update rings for Windows 10 and later › Create.
- Under Update ring settings, set Quality update deferral period (days) to your pilot/broad-ring value (for example, 0 for a pilot ring, 7-14 for broad).
- Assign the ring to the target device group and select Create.
The QA testing matrix: four phases, not one flat checklist
A single flat checklist mixes together things that genuinely need deep testing every month with things that only need a glance. Split it into four phases instead, matched to how much attention each one actually deserves:
| Phase | What it covers | Depth needed |
|---|---|---|
| 1. Standard smoke test | Boot/restart/shutdown, sign-in (password/PIN/Hello), network, BitLocker, core apps, Search sanity check, reboot orchestration and Active Hours | Full - every device, every month, don't skip this one |
| 2. New-feature spot-checks | This month's gradual-rollout items (File Explorer units, Search typo tolerance, Hello ESS peripheral readers, Widgets accent colour, Touchpad gestures) | Light - eyeball only, and only if the feature has actually appeared |
| 3. Carry-forward regression | Whatever security hardening or behaviour changes shipped in previous months - confirm they still hold, don't just assume last month's fix stayed fixed | Targeted - re-test the specific prior changes, not a full re-run |
| 4. Legacy-branch light pass | Any branch nearing end of servicing (23H2 here) where the device count is shrinking and the risk profile is lower | Minimal - basic smoke test only, confirm the build landed, move on |
Phase 1 - Standard smoke test (the one that matters most, every month):
- Boot, restart, and shutdown all complete cleanly
- Sign-in works via password, PIN, and Windows Hello
- Network connectivity - Wi-Fi, VPN, and any proxy your organisation uses - is intact
- BitLocker shows a healthy status and its recovery key is still escrowed (AD or Entra ID / Intune, depending on join type)
- Core line-of-business apps (Office apps, your browser, your VPN/EDR client) open and behave normally
- The Search sanity check: click Start, type
Notepad- Notepad should be the top result, not a different app - The reboot completes through your update-management tooling (Intune, Configuration Manager, or whatever orchestrates it) without hanging or looping, and respects Active Hours - no reboot forced mid-workday
Phase 2 - New-feature spot-checks (eyeball only, skip anything not yet present):
- File Explorer: switch to Details view and confirm file sizes now show as KB/MB/GB rather than everything in KB; try middle-clicking a folder in the address bar to confirm it opens in a new tab.
- Windows Search: deliberately mistype an app name (e.g. "notpad") and confirm it still surfaces Notepad.
- Windows Hello Enhanced Sign-in Security (ESS): if you have a plug-in USB fingerprint reader, this is the one worth a proper test this month - ESS now supports external readers, not just built-in ones. Enroll it under Settings › Accounts › Sign-in options and confirm sign-in succeeds.
- Widgets: taskbar notification badges should now use your accent colour instead of red.
- Touchpad: check the new scroll/zoom speed and accelerated-scrolling options under Settings › Bluetooth & devices › Touchpad.
Phase 3 - Carry-forward regression (confirm last month's changes are still holding, don't assume):
- Re-test whatever security hardening change landed in the previous month's update specifically - not the whole feature area, just the exact behaviour that changed. If last month tightened a network/TLS/authentication policy, confirm your VPN client and EDR agent still connect cleanly today.
- Remote access: open a Remote Desktop or RemoteApp session, including any saved connection files, and confirm it connects without a certificate warning.
- Lock screen: password, PIN, and Windows Hello credential UI still all present and correct.
- VDI/Cloud PC: RemoteApp sessions reconnect cleanly if that's part of your fleet.
Phase 4 - Legacy-branch light pass (for a branch you're actively shrinking, like 23H2 here):
- Basic smoke test only: boot, sign-in, network, core apps
- General "does it still work" comparison against last month - not a full new-feature review
- Confirm the build number matches the branch's expected value (
22631.7517for 23H2 this month)
What's actually new, and does it matter for your organisation?
Not every item in a Patch Tuesday changelog deserves the same attention. Here's each change from this release scored against a simple question: does this need a decision from you, or can it just roll out?
| Change | Relevant if... | Action needed |
|---|---|---|
| File Explorer units, middle-click tabs | Always - every device eventually gets it | None. Expect a small bump in "why did my file sizes change" help-desk tickets - worth a one-line heads-up in your rollout communication. |
| Windows Search typo tolerance | Always | None - pure improvement, no configuration surface. |
| Windows Hello ESS - external fingerprint readers | You have desktops, kiosks, or shared devices with plug-in USB fingerprint readers | Worth piloting deliberately. This extends hardware-isolated Enhanced Sign-in Security to hardware that previously couldn't use it - a genuine capability upgrade if your fleet includes desktops without built-in biometrics. |
| Widgets accent-colour badges | Only if Widgets is enabled in your environment | None. If Widgets is disabled by policy, this change is moot for you - don't spend spot-check time on it. |
| Touchpad gesture controls | Laptop fleet | None - opt-in user preference, not a managed setting. |
| Secure Boot certificate rollout (background) | All devices with Secure Boot enabled - effectively everyone | No configuration action. Microsoft controls the phased rollout; your only job is confirming devices still boot normally after patching, which Phase 1 of the smoke test already covers. |
What a QA tester, an IT manager, and a change approver each need from this release
The same Patch Tuesday email means something different depending on which job you're doing with it. Here's what each role is actually looking for:
- A device matrix, not one laptop: at least one representative device per branch (23H2/24H2/25H2) and join type (Entra joined, hybrid, Autopilot-provisioned) before calling the pilot ring clean.
- Exact repro steps per test case, not "test Search" - e.g. "type notpad in Start, expected result: Notepad is the top hit."
- A pass/fail column plus an evidence column: screenshot, exact build number, and timestamp for anything that fails - "it didn't work" isn't actionable without the build it failed on.
- Run Phase 1 (standard smoke test) to completion before touching Phase 2 (feature spot-checks) - a Phase 1 failure invalidates the value of testing Phase 2 on that device.
- A defect template that captures: device model, branch/build, which phase failed, exact error text or Event ID, and whether it reproduces on a second device before escalating.
- "Microsoft reports no known issues" is a lower-risk signal, not a zero-risk one - it means no widely reported issue, not no issue on your specific hardware/software combination. Pilot-ring results are what actually de-risks the broad rollout.
- The compliance deadline your own Update ring policy already enforces matters here: on a device with a 30-day compliance deadline and a 7-day grace period (the real values captured earlier in this post), pilot devices that haven't installed voluntarily will be forced to update regardless once that window closes - plan communication and pilot sign-off around that date, not an arbitrary one.
- A rollback path decided before deployment, not during an incident: pause the ring in Intune, or uninstall the specific KB via
wusa /uninstall /kb:5121003(or 5120240) on an affected device while you investigate. - A communication plan for end users covering expected restart timing and Active Hours - most "why did my PC reboot" complaints are a communication gap, not a technical one.
- A simple metric to report upward: percentage of the fleet on the expected build by day 7, day 14, and day 30 - exactly what the compliance script in this post is built to produce at scale.
- What's changing: name both KBs and target builds explicitly (KB5121003 to 26200.9168/26100.9168, KB5120240 to 22631.7517) - a change board should never have to guess which update is being discussed.
- Why: routine monthly security cumulative update. Cite the MSRC Security Update Guide entry for the actual CVE severity being addressed, not just "it's this month's patch."
- Risk rating: justified by pilot-ring results, not assumed - attach the Phase 1/2/3 pass rate from the QA matrix above as evidence, not a summary sentence.
- Rollback procedure: the same one the IT Manager already defined - pause the ring, or per-device KB uninstall - stated explicitly in the change record, not implied.
- Scope: device count and which rings/groups are in this deployment wave, distinct from the fleet still pending in later waves.
- Deployment window: aligned to Active Hours and any existing maintenance window policy - a change that reboots devices mid-workday will get rejected by most boards on that basis alone, independent of the patch's technical merit.
- Post-implementation review date: when compliance percentage and helpdesk ticket volume will actually be checked against the plan - a change without a review date tends not to get reviewed.
Proof it worked: a real compliance check, not an eyeballed build number
Here is a real run of Get-PatchTuesdayBuildCompliance.ps1 from this series, against the same device shown earlier - correctly flagging it as not yet compliant:
And a real run of the paired report-only remediation script, which never forces an update - it just logs the finding for your existing patch-management tooling to act on, the same way this series' other Proactive Remediation pairs stay report-only when there's no safe automatic fix:
Deploy this as an Intune Proactive Remediation
- Sign in to the Intune admin center.
- Go to Devices › Scripts and remediations › Proactive remediations.
- Select Create and name it "Patch Tuesday Build Compliance - August 2026".
- On the Settings page, paste
Get-PatchTuesdayBuildCompliance.ps1into Detection script file. - Paste
Remediate-PatchTuesdayBuildComplianceReport.ps1into Remediation script file. - Set Run this script using the logged-on credentials to No - both scripts only read machine-level registry and event log data.
- Assign to your pilot or broad ring, set a daily schedule, and select Create.
References
- Microsoft Support - KB5121003 (Windows 11 24H2/25H2, August 11 2026)
- Microsoft Support - KB5120240 (Windows 11 23H2, August 11 2026)
- Microsoft Learn - Windows 11 release information
- Microsoft Learn - Windows 11 Home and Pro servicing lifecycle
Scripts for this post are in Windows-Patching-Scripts.