Stuck on Windows 11 23H2? Here’s Why Your Fleet Isn’t Getting the 24H2 Update

If you manage a fleet of Windows 11 devices, you may have noticed a concerning trend: despite Windows 11 24H2 being fully available, a significant number of workstations are stubbornly refusing to update. They remain on version 23H2, and even clicking “Check for updates” returns a “You are up to date” message.

With Windows 11 23H2 reaching End of Support, getting these systems upgraded is critical. So, what is happening?

It is likely not a bug. It is a feature. Microsoft has introduced new, stricter requirements and “Safeguard Holds” that make 24H2 the most difficult upgrade to deploy automatically in years.

Here are the three reasons your systems are stuck, and a script to identify the culprit.

1. The “Hard” Block: The New POPCNT Requirement

This is the most significant change in the Windows kernel in over a decade.

Starting with version 24H2, the Windows kernel requires the CPU to support an instruction set called POPCNT (part of SSE4.2).

• The Issue: If a computer runs on a pre-2010 CPU (e.g., Intel Core 2 Duo), Windows 11 24H2 simply cannot boot.
• The Symptom: If you previously bypassed requirements to install Windows 11 on unsupported hardware, those tricks end here. The update will not appear, and forcing it will result in a boot failure.
• The Fix: There is none. These machines must be retired or switched to Linux/Windows 10 (until its EoL).

2. The “Soft” Block: Safeguard Holds

Microsoft uses telemetry to identify hardware or software that crashes on the new version. If a PC has a specific driver installed, Microsoft places a “Safeguard Hold” on it.

• Common Culprits: Intel Smart Sound Technology (audio drivers), certain fingerprint sensors, and outdated Ubisoft games/anti-cheat software.
• The Symptom: The update is hidden to prevent the user from experiencing a Blue Screen of Death (BSOD).
• The Fix: You must wait for a driver update, or uninstall the conflicting software. Do not force these updates via ISO, or you will likely break the machine.

3. The “Silent” Block: Forgotten GPOs

Many MSPs and IT admins set “Target Release Version” policies in Intune or RMM tools to keep fleets stable on version 23H2 last year.

• The Issue: If that policy was never cleared, the computer is strictly forbidden from seeing version 24H2.
• The Fix: Check your Registry or Group Policy Object (GPO) settings and clear the TargetReleaseVersion key.

The Solution: Audit Your Fleet with PowerShell

Stop guessing why a machine isn’t updating. We have developed a PowerShell script specifically for RMM deployment that checks for all three blockers instantly.

What this script does:

1. Verifies if the CPU supports the required POPCNT instruction.
2. Checks the Windows Registry for active Safeguard Holds (and gives you the ID).
3. Checks if a “Target Release Version” policy is pinning the OS to an old version.

The Script

Run this as Administrator or System context via your RMM.

PowerShell

<#
.SYNOPSIS
    Checks for Windows 11 24H2 Readiness: POPCNT, Safeguards, and Policy Blocks.
#>

$Results = [PSCustomObject]@{
    ComputerName    = $env:COMPUTERNAME
    Status          = "Ready"
    BlockerType     = "None"
    Detail          = ""
}

# 1. Check CPU POPCNT (SSE4.2) Support
$code = @"
using System;
using System.Runtime.InteropServices;
public class CpuCheck {
    [DllImport("kernel32.dll")]
    public static extern bool IsProcessorFeaturePresent(int ProcessorFeature);
}
"@
Add-Type -TypeDefinition $code
if (-not [CpuCheck]::IsProcessorFeaturePresent(38)) {
    $Results.Status = "Blocked"
    $Results.BlockerType = "HARDWARE_POPCNT"
    $Results.Detail = "CPU obsolete (No SSE4.2). Cannot run 24H2."
}

# 2. Check Safeguard Holds
$SafeguardPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\TargetVersionUpgradeExperienceIndicators\GE24H2"
if (Test-Path $SafeguardPath) {
    $Reason = Get-ItemProperty -Path $SafeguardPath -Name "RedReason" -ErrorAction SilentlyContinue
    if ($Reason.RedReason -ne "None" -and $Reason.RedReason -ne $null) {
        $Results.Status = "Blocked"
        $Results.BlockerType = "SAFEGUARD_HOLD"
        $Results.Detail = "Microsoft Driver Block Active. Reason: $($Reason.RedReason)"
    }
}

# 3. Check Policy Pins
$PolicyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$TargetVer = Get-ItemProperty -Path $PolicyPath -Name "TargetReleaseVersionInfo" -ErrorAction SilentlyContinue
if ($TargetVer.TargetReleaseVersionInfo -match "23H2|22H2") {
    $Results.Status = "Blocked"
    $Results.BlockerType = "POLICY_PINNED"
    $Results.Detail = "Registry pinning active: $($TargetVer.TargetReleaseVersionInfo)"
}

$Results | Format-List

Summary

If you are seeing widespread update failures, run the audit above.

• Hardware Block? Time to refresh the hardware.
• Safeguard Hold? Identify the driver and update it.
• Policy Block? Update your RMM policies.