Why TargetReleaseVersion Stops Honoring 23H2 After 24H2 Becomes GA

When you configure the TargetReleaseVersion policy in Windows 11 to lock devices to version 23H2, the setting may stop working after Microsoft releases version 24H2 to General Availability. Devices that were previously blocked from upgrading to 24H2 may suddenly begin receiving the update. This behavior is not a bug — it is caused by how Windows Update interprets the TargetReleaseVersion and TargetReleaseVersionInfo policies once a new version reaches GA status. This article explains the root cause of the policy change, provides steps to verify your current configuration, and offers a reliable alternative to keep devices on a specific Windows 11 version.

How Windows Update Interprets TargetReleaseVersion After a New GA Release

The TargetReleaseVersion policy is stored in the Windows registry under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. It contains two values: TargetReleaseVersion (a DWORD set to 1 to enable the policy) and TargetReleaseVersionInfo (a string containing the target version, such as “23H2”). When you set these values, Windows Update checks the target version against the list of available feature updates.

Before 24H2 reaches GA, Windows Update sees 23H2 as the latest eligible version and 24H2 as a preview or optional update. The policy blocks 24H2 because it is not the specified target. After 24H2 becomes GA, Windows Update changes its behavior. It now considers 24H2 the default recommended version. The TargetReleaseVersion policy, by design, only blocks upgrades to versions that are newer than the specified target and not yet the default GA version. Once 24H2 is GA, the policy treats it as the baseline. If the TargetReleaseVersionInfo value is not updated to explicitly exclude 24H2, Windows Update begins offering 24H2 to devices that previously respected the 23H2 lock.

The Role of TargetReleaseVersionInfo String

The string value TargetReleaseVersionInfo is critical. Setting it to “23H2” works only as long as 23H2 is the current GA release. When 24H2 becomes GA, Windows Update no longer interprets “23H2” as a valid target to block 24H2. Instead, it sees 23H2 as an older version that is no longer the default. The policy then allows 24H2 because the target version is older than the current GA version and the policy does not prevent downgrades or upgrades from an older target to a newer GA release. To maintain the block, you must set TargetReleaseVersionInfo to the exact build number of 23H2, such as “22631.2428”, and also configure the ProductVersion value to “Windows 11”.

Steps to Verify and Correct TargetReleaseVersion Configuration

1. Open Registry Editor
   Press Ctrl + R, type regedit, and press Enter. If prompted by User Account Control, click Yes.
2. Navigate to the WindowsUpdate key
   Go to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. If the key does not exist, the policy is not configured.
3. Check TargetReleaseVersion DWORD
   Look for a DWORD value named TargetReleaseVersion. Its data must be 1 for the policy to be active. If it is missing or set to 0, the policy is disabled.
4. Check TargetReleaseVersionInfo string
   Look for a string value named TargetReleaseVersionInfo. If the data is “23H2”, change it to the full build number of the latest 23H2 update, for example 22631.2428. You can find the current build number by running winver on a device that is still on 23H2.
5. Add ProductVersion string if missing
   Create a new string value named ProductVersion and set its data to Windows 11. This tells Windows Update which product line the target version belongs to.
6. Restart the Windows Update service
   Open Command Prompt as administrator and run net stop wuauserv && net start wuauserv. Then run wuauclt /resetauthorization /detectnow to force a detection cycle.
7. Verify the policy in Group Policy Editor
   If you manage devices via Group Policy, open gpedit.msc and go to Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Update. Open the setting “Select the target Feature Update version”. Set it to Enabled. In the options, enter “Windows 11” for the product version and the exact build number for the target version. Do not use the release name “23H2”.

Common Misconceptions and Configuration Mistakes

The TargetReleaseVersion Policy Works by Release Name

Many administrators assume that setting TargetReleaseVersionInfo to “23H2” permanently blocks upgrades to any version newer than 23H2. This is not true. The policy is designed to work with the current GA release. Once a newer version reaches GA, the policy loses its blocking effect unless you update the string to a specific build number. Microsoft’s documentation confirms that the string should contain a version number, not a marketing name, for long-term use.

TargetReleaseVersion Blocks All Newer Versions

Another common belief is that the policy blocks any version newer than the specified target. In practice, it only blocks versions that are in preview or optional status. When a newer version becomes GA, Windows Update treats it as the default and overrides the policy. This is by design to ensure devices receive security updates. To truly block a newer GA version, you must use the Windows Update for Business deferral policies or the Feature Update deferral period setting.

Using a Build Number Breaks Future Updates

Some administrators worry that specifying an exact build number will prevent devices from receiving cumulative updates for 23H2. This is incorrect. The TargetReleaseVersion policy only controls which feature update version the device is offered. Cumulative updates for the specified version continue to install normally. You must update the build number only when you want to move to a newer feature update, such as from 23H2 to 24H2.

TargetReleaseVersion vs Windows Update for Business Deferral Policies

Item	TargetReleaseVersion	Windows Update for Business Deferral
Scope	Locks device to a specific feature update version	Delays all feature updates by a set number of days
Granularity	Requires exact version or build number	Uses a deferral period in days
Behavior after new GA	Stops blocking unless build number is specified	Continues to defer until the period expires
Management	Registry or Group Policy	Group Policy or MDM
Best use case	Keeping devices on a known stable version	Staggering rollout across an organization

For most enterprise scenarios, combining TargetReleaseVersion with a deferral period provides the most control. Use TargetReleaseVersion with a specific build number to lock devices to 23H2, and set a feature update deferral period of 60 to 120 days to prevent premature upgrades even if the policy is misconfigured. This dual approach ensures that devices do not upgrade to 24H2 until you explicitly update the target version.

You can now configure the TargetReleaseVersion policy correctly to keep devices on Windows 11 version 23H2 even after 24H2 reaches GA. The key change is to use the exact build number in TargetReleaseVersionInfo instead of the release name. For additional control, enable the “Select the target Feature Update version” policy in Group Policy and set a deferral period for feature updates. An advanced tip: use PowerShell to audit all devices in your environment for the current TargetReleaseVersionInfo value by running Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' on each machine to confirm the correct build number is in place.