The device in front of me is a managed Windows 11 Enterprise laptop on a corporate fleet. Its Windows Update policy is clean, entirely WUfB-shaped, and says exactly what the update-ring owner intended it to say: stay on 24H2.
It is running 25H2.
Not "nearly 25H2", and not "25H2 staged and waiting". DisplayVersion reads 25H2. CurrentBuild reads 26200. The August 2026 cumulative is on top of it at UBR 9168. And the policy value under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate still reads 24H2.
Nothing on the device is broken. There is no error code to look up, no failed install to retry, no reboot pending. That is exactly what makes this state dangerous: a feature-update pin that has been overtaken fails silently, and while it is failing it is also actively preventing the device from taking any feature update at all.
TargetReleaseVersion is a ceiling on what Windows Update will offer, evaluated at scan time. It is not a rollback mechanism and it cannot pull a device down to an earlier release. Microsoft is explicit that "Feature update policies don't downgrade devices" and that if you target a version older than the installed one, "the device won't receive any feature updates until the policy is updated". So a 24H2 pin on a 25H2 device is not a harmless leftover: it is a device that has left your intended baseline and been quietly removed from feature-update servicing. Because both halves of the truth live in the registry, you detect it by comparing TargetReleaseVersionInfo against the real installed DisplayVersion / CurrentBuild - never by reading the policy alone, and never by trusting ProductName, which still says "Windows 10 Enterprise" on this Windows 11 machine.
The problem: the pin says 24H2, the device says 25H2
This did not start as an investigation. It started as a baseline capture on a healthy device - the sort of read you do so that you know what "normal" looks like before a real incident lands. The policy hive came back exactly as a WUfB-managed device should. Then the version block came back, and the two did not agree.
Captured read-only from a live Windows 11 Enterprise device during this session. Nothing was written, no service was restarted, no policy was changed.
Read that output slowly, because there are four separate disagreements in it and only one of them is the headline.
The headline is the pin. Policy asks for 24H2; the installed release is 25H2. Per Microsoft's Windows 11 release information, 24H2 is OS build 26100 and 25H2 is OS build 26200. CurrentBuild is 26200, so the device is one full annual release ahead of where policy wants it.
The second is ProductName, claiming "Windows 10 Enterprise" on a machine that Win32_OperatingSystem.Caption correctly identifies as Windows 11 Enterprise. That is not corruption - it is a deliberate compatibility decision, true of every Windows 11 build since 21H2. The third is ReleaseId, frozen at 2009, the Windows 10 20H2 value, superseded years ago by DisplayVersion.
The fourth is the interesting one for later: BuildLabEx still reads 26100.1...ge_release.240331-1435. A 24H2 build lab string on a 26200 build is a fingerprint, and it tells you how the device got here.
TargetReleaseVersion plus TargetReleaseVersionInfo is the registry backing for the Group Policy setting Select the target Feature Update version, and for the Update/TargetReleaseVersion node in the Policy CSP. Microsoft describes it as letting administrators "specify which version they would like their device(s) to move to and/or stay on until they reach end of service or reconfigure the policy". Note the verbs: move to and stay on. There is no third verb for come back down to.Now consider what your tooling would have said about this device. The policy-compliance dashboard shows a correctly-applied version pin. The patch-level dashboard shows a fully-patched device on the current August cumulative. Both are true, neither is the finding, and the finding only exists in the gap between two data sources that most fleet reports keep in separate tables: intent and reality.
Why it happens: a pin caps offers, it never pulls a device back
Before the causes, the mechanism - because the mechanism is what makes every one of the causes possible.
A version pin is not a state the device is held in. It is a filter applied to an answer. When the Update Session Orchestrator triggers a scan and the Windows Update Agent evaluates applicability, the pin narrows the set of feature updates the service is allowed to offer. If the pinned release is the current one, nothing newer gets offered and the device sits still. That looks like enforcement, and for a device that has not yet moved, it is.
But the filter runs on the offer. It has no hand on the installed release. Microsoft's Intune documentation states the consequence in one sentence: "Feature update policies don't downgrade devices. If a device is already running a newer Windows version than the one targeted, the policy doesn't apply and the device continues running its current version."
So there are exactly two ways to end up with a pin below the installed release: the device moved forward while the pin was not looking, or somebody moved the pin backwards. Both happen, and in a large fleet both happen routinely.
Route one: the pin arrived after the upgrade had already shipped. A feature update is offered, downloaded and installed over a period of days. If the pin is authored, assigned or re-scoped during that window, the device can complete an upgrade that the pin - had it existed a week earlier - would have blocked. The policy then lands on a device that is already past it.
Route two: a documented processing race. This one is not folklore; Microsoft calls it out twice. On the co-management path: moving the Windows Update policies workload to Intune "can initially result in devices updating to a later feature update version than is configured in the policy". And on the deferral-to-pin migration path: "If a device scans for updates after a deferral is removed but before Windows Update finishes processing the feature update policy, the device might be offered a feature update you didn't intend to deploy." Both produce precisely the state on this device.
Route three: an enablement package flip. This is the one that catches people out on the 24H2-to-25H2 transition specifically, and it is almost certainly what happened here. Microsoft ships 24H2 and 25H2 from a shared servicing branch: the two releases "share a common core operating system with an identical set of system files", and the 25H2 features already sit inside 24H2's monthly cumulative in a dormant state. KB5054156 is the enablement package - a small "master switch" that activates them with a single restart.
Which brings us back to BuildLabEx. Here is the evidence chain on the lab device.
Read as a sequence: installed as 24H2 in the 26100 lab, took cumulative updates through 2025 and into 2026, and on 4 February 2026 took KB5054156 - after which the same file set started reporting itself as build 26200, release 25H2. The pin was never satisfied by that transition; it was simply left behind by it.
Route four: someone edited the pin down. A ring gets re-cut, a template gets copied from an older environment, a value gets typed as the release the author is standing on rather than the release the fleet is on. This is the most avoidable route and the most common one in my experience, because a pin value looks like documentation and nobody re-reads documentation.
24h2, 2024H2 and 24H2 with a trailing space are all invalid values with the same effect.There is one more clause in that guidance worth putting a date on, because it converts a quiet misconfiguration into a scheduled surprise: "If you don't update this before the device reaches end of service, the device will automatically be updated once it's 60 days past end of service for its edition."
Per the release information page, Windows 11 24H2 stops receiving updates on 2026-10-13 for Home, Pro, Pro Education and Pro for Workstations, and on 2027-10-12 for Enterprise, Education, IoT Enterprise and Enterprise multi-session. 25H2 runs to 2027-10-12 and 2028-10-10 respectively.
How to verify: six reads, in order, before you change anything
The instinct at this point is to fix the policy. Do not, yet. The pin value is a symptom of a decision made somewhere upstream, and if you correct it on the device you destroy the only local evidence of what that decision was. Work through the reads first.
Everything below is read-only. None of it restarts a service, clears a cache or touches SoftwareDistribution.
Step 1 - read the pin, both values. TargetReleaseVersion is the enable switch and TargetReleaseVersionInfo is the target. A 1 with an empty or missing TargetReleaseVersionInfo is a different failure from a 1 with a stale value, and the two need different fixes.
| Value | Meaning | What to look for |
|---|---|---|
TargetReleaseVersion (REG_DWORD) | Enables the version pin. 1 = a target release is being enforced. | 1 here with no usable TargetReleaseVersionInfo means the pin is on and pointing nowhere. Absent or 0 means no pin - deferrals govern instead. |
TargetReleaseVersionInfo (REG_SZ) | The release the device is allowed to move to and stay on, as a release string such as 24H2. | Compare it against DisplayVersion. Lower than installed, or malformed, means no feature updates at all. Equal means the pin is doing its job. |
ProductVersion (REG_SZ) | Optional companion that names the product family for the target release - documented values include Windows 11, 11 and Windows 10. | Present but naming the wrong family is a classic cross-major-version pin bug. Absent is normal on a single-family fleet. |
DeferFeatureUpdatesPeriodInDays (REG_DWORD) | Feature-update deferral in days, 0-365. | Microsoft states that when a target version is specified, "feature update deferrals won't be in effect". A non-zero value alongside a pin is dead configuration that will confuse the next engineer. |
Step 2 - read the installed release, and read it from the right values. This is where most detection scripts quietly break, and the lab device demonstrates why.
| Value | Meaning | What to look for |
|---|---|---|
DisplayVersion (REG_SZ) | The marketing release string of the installed OS - 24H2, 25H2. | Use this. It is directly comparable to TargetReleaseVersionInfo with no translation. On the lab device: 25H2. |
CurrentBuild (REG_SZ) | The OS build number: 26100 for 24H2, 26200 for 25H2, 22631 for 23H2. | Use this too, as the arithmetic sanity check. Anything at or above 22000 is Windows 11. On the lab device: 26200. |
UBR (REG_DWORD) | Update Build Revision - the fourth part of the version, incremented by each cumulative update. | Combine as CurrentBuild.UBR to get the number in the release-information tables. Lab device: 26200.9168, which is the 2026-08 B release, KB5121003. |
ProductName (REG_SZ) | Legacy product string, retained for application compatibility. | Do not key on this. On this Windows 11 Enterprise device it reads Windows 10 Enterprise. Any script that matches ProductName -like '*Windows 11*' classifies this machine as Windows 10 and silently excludes it from your Windows 11 reporting. |
ReleaseId (REG_SZ) | Superseded release identifier. | Do not key on this either. Frozen at 2009 - the Windows 10 20H2 value - on a 25H2 device. |
BuildLabEx (REG_SZ) | Build lab string from the originally-installed image. | Diagnostic gold, not a version source. 26100.1...ge_release.240331-1435 on a 26200 build tells you the device was installed as 24H2 and was moved to 25H2 later. |
Microsoft's own Win32 documentation explains why ProductName and the major-version numbers are useless here: the operating system version table lists both Windows 11 and Windows 10 as version 10.0. Consistent with that, CurrentMajorVersionNumber on this device is 10. The build number is the only numeric that moved between the two products, which is why 22000 is the threshold everyone ends up using.
wuauserv, rename SoftwareDistribution and force a rescan. On this failure that is worse than useless. The pin is a policy read, not a cached-state problem, so the rescan changes nothing - but clearing the datastore does discard the local scan and offer history that would have shown you when the device last saw a feature update at all. Read DisplayVersion against TargetReleaseVersionInfo first. It is two registry reads and it either explains everything or rules the pin out completely.Step 3 - decide whether the pin is above, level with, or below the installed release. This is the whole diagnosis, and it has three outcomes. Pin above installed: the pin is working and the device has an upgrade in its future. Pin level with installed: the pin is working and holding. Pin below installed: the pin has been overtaken, and the device is receiving no feature updates.
Step 4 - date the transition. When the device moved tells you whether this is a policy-authoring problem or a race. Get-HotFix gives you the enablement package's install date on a 24H2-to-25H2 flip; for a full feature update, C:\Windows\Panther\setupact.log carries the timestamps. Compare that against when the pin was authored on the management side - the Intune profile's modified date, or the GPO's version history.
Step 5 - read the update client's event log, and know what it cannot tell you. This step exists mainly so you do not waste an hour on it. The event log will confirm scan activity; it will not confirm the pin is stale.
| Event ID | Message | What it tells you |
|---|---|---|
| 26 (WindowsUpdateClient) | "Windows Update successfully found 0 updates." | The scan completed and the service answered. This is not diagnostic. A fully-patched device and a device excluded from feature updates by a stale pin produce the identical line. On the lab device this event appears 210 times in the retained log. |
| 41 (WindowsUpdateClient) | "An update was downloaded." | Content actually arrived. Useful for proving the device still talks to the service, and for bounding when it last received anything. |
| 2 (Setup) | "Package KB<nnnnnnn> was successfully changed to the Staged state." | CBS accepted a package. On an enablement-package flip this is the record of the switch being staged - if the log has not rolled over since. |
| 4 (Setup) | "A reboot is necessary before package KB<nnnnnnn> can be changed to the Installed state." | The package needs the restart to complete. An enablement package is designed to need exactly one. |
Step 6 - identify which component made the decision, so you know where to look next time. The pin is not enforced by a service you can restart into compliance; it is read during applicability evaluation inside the update agent itself.
| Binary | Role | Location |
|---|---|---|
wuaueng.dll | File description "Windows Update Agent". The agent engine - it performs the scan and evaluates which updates are applicable and offerable under policy. | C:\Windows\System32\wuaueng.dll (version 1509.2607.1012.0 on the lab device) |
wuapi.dll | File description "Windows Update Client API". The COM surface (IUpdateSession, IUpdateSearcher) that scripts and tools call to drive a scan. | C:\Windows\System32\wuapi.dll (version 1509.2607.1012.0) |
usosvc.dll | File description "Update Session Orchestrator Service". Hosts UsoSvc, which schedules and sequences scan, download and install sessions. | C:\Windows\System32\usosvc.dll (version 10.0.26100.8737) |
UsoClient.exe | Command-line front end for triggering orchestrator actions such as a scan. | C:\Windows\System32\UsoClient.exe (version 10.0.26100.8328) |
Two of those version strings say 26100 on a device whose build is 26200. That is not a servicing failure - it is the shared servicing branch doing exactly what Microsoft documents, with 24H2 and 25H2 running an identical set of system files. It is also another reason not to build version detection on binary versions.
Detecting it across the fleet
Locally this is two registry reads. Fleet-wide it is the same two reads plus an ordering, because "later than" is not something you can express by string comparison on release labels.
Four outcomes, four different conversations. OK-NOPIN means deferrals govern this device, which may be intentional. BAD-PIN-EMPTY means the switch is on with no target - a broken policy delivery. REVIEW-UNKNOWN-LABEL catches the typo class and any release your map has not learned yet. OVERTAKEN-PIN is the finding in this post.
Deploy it as an Intune remediation detection script or a Configuration Manager configuration item; exit code 1 flags the device without changing anything. Then cross-check the management side against the Intune Windows feature updates (Organizational) report - a device enrolled and protected by a feature update policy reaches a state of OfferReady, and devices that never reach it are not being governed by the policy you think is governing them.
The fix: reconcile the pin with reality, in the right order
The device does not need repairing. The policy needs a decision. Those are different jobs, and confusing them is how this gets made worse.
Do not start by editing the registry on the device. The value came from Group Policy or the Policy CSP, and the source of truth will reassert it - or, worse, the local edit will survive just long enough to make the fleet report look clean while the real policy stays wrong.
Step 1: decide the intended baseline, out loud. 25H2 is already on the device - is it acceptable? For most fleets in mid-2026 the answer is yes: 25H2 shares its system files with 24H2, so the compatibility exposure between them is far smaller than a normal annual jump, and 25H2 buys a year of servicing runway that 24H2 does not have.
Step 2a: if 25H2 is acceptable, raise the pin to match. Set TargetReleaseVersionInfo to 25H2 at the source - the Intune feature update profile, or the Select the target Feature Update version GPO under Computer Configuration > Administrative Templates > Windows Components > Windows Update. The moment that lands, the device stops being excluded from feature-update servicing and starts being genuinely pinned again.
Step 2b: if you truly need 24H2, understand that policy cannot get you there. Lowering the pin does not move the device back; it only guarantees the device receives nothing. Going back to 24H2 is a deployment task - in-place installation from 24H2 media, or a rebuild - and it is a decision to take on a release whose Pro-edition support ends in October 2026. Choose it deliberately or not at all.
Step 2c: for a mixed fleet, pin per ring, not per fleet. If some devices are on 24H2 and some are on 25H2, a single pin value is wrong for one of the two groups by definition. Split on the detection output above and pin each group to what it is actually running or higher.
Step 3: clean up the configuration that is now dead. If a feature-update deferral is still configured alongside the pin, remove it. Microsoft is direct on this point: when a target version is specified, feature update deferrals are not in effect, and the Intune guidance recommends stopping the use of feature update deferrals entirely once feature update policies are in play because "combining feature update deferrals with feature update policies adds unnecessary complexity and can delay or block feature updates".
Step 4: sequence the change so you do not create a second race. Microsoft's documented order is to assign the feature update policy first, wait for Windows Update to process it, confirm the devices report OfferReady, and only then set the update-ring feature update deferral to 0. Doing it in the other order reopens the exact window that produced the problem.
OK today returns OVERTAKEN-PIN the moment anything moves it forward, and that is exactly the moment you want to hear about it - not eleven months later when a release goes end-of-service.Proof it worked: the two reads that must agree
The verification is the diagnosis run again, and the only acceptable result is agreement between intent and reality.
Three things to check off, in this order.
First, the policy value on the device matches what you set at the source. If it does not, the change has not arrived and everything downstream of it is meaningless - wait for the next policy refresh rather than editing locally.
Second, TargetReleaseVersionInfo is greater than or equal to DisplayVersion. Equal is a holding pin. Greater is a pin with an upgrade still to come. Less is the failure you started with.
Third - the check people skip - the device appears in the management-side feature update report at OfferReady or beyond. Registry agreement proves the value arrived; only the service-side state proves the device is enrolled for feature updates again.
What you should not expect is any change in the device's health signals, because none of them were ever unhealthy. Services running, component store serviceable, no reboot pending, every scan successful. That was the trap the whole way through.
The broader lesson is worth stating plainly. A version pin is the only Windows Update setting whose correctness cannot be established by reading the setting. DeferQualityUpdatesPeriodInDays=7 means seven days whatever else is true of the device. TargetReleaseVersionInfo=24H2 means "hold at 24H2" on a 24H2 device, "upgrade to 24H2" on a 23H2 device, and "receive nothing, forever" on a 25H2 device. Same value, three behaviours, and only one of them is what the author had in mind.
So report it as a pair, always. Intent next to reality, in the same row, on the same dashboard. That single column comparison is the entire difference between a fleet you have pinned and a fleet you merely believe you have pinned.
References
- Configure Windows Update client policies via Group Policy - the Select the target feature update version setting, the "older than your current version" behaviour, the "feature update deferrals won't be in effect" clause, and the automatic update 60 days past end of service.
- Policy CSP - Update -
Update/TargetReleaseVersionandUpdate/ProductVersiondefinitions, formats and supported values. - Configure Windows feature update policies (Microsoft Intune) - "Feature update policies don't downgrade devices", the co-management processing delay, the deferral-to-policy race, and the OfferReady state.
- Configure Windows Update client policies - the full policy-to-registry mapping under
HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate, including the deferral and pause values. - Windows 11 release information - build numbers per release (24H2 = 26100, 25H2 = 26200), end-of-servicing dates by edition, and the 26H1 in-place-update note.
- Operating System Version (Win32) - both Windows 11 and Windows 10 report version
10.0, which is why build number is the only usable numeric discriminator. - KB5054156: Feature update to Windows 11, version 25H2 by using an enablement package - the shared servicing branch, the dormant feature set, and the single-restart switch.
All device output in this post was captured read-only from one live Windows 11 Enterprise device (build 26200.9168, DisplayVersion 25H2) on 2026-08-23. Console blocks are reproductions of that captured output, reformatted for width.