So Config manager 2309 does’nt solve this?

I had this issue too. The 22h2 and 23h2 packages share the same core dll’s, and so they detect the same way. You just need the 23h2 enablement package to make it display “23h2” instead of “22h2”, but this is not available via WSUS/SCCM. I used the offline installer and deployed it as an application.

Deploy the standalone update as an application (you’ll have to manually specify the application information) I renamed the downloaded file to ‘KB5027397’ to make it easier (the default filename is several dozen characters).

The installation command I use is: wusa.exe kb5027397.msu /quiet /norestart (these switches make it install silently and allow the user to restart on their own timeframe…if you don’t specify ‘norestart’ it will immediately reboot after installing.

The detection method is a custom powershell script: get-hotfix | Where-Object {$_.HotFixID -match “KB5027397”}

I am experiencing the same problem – perhaps the latest Windows 11 22H2 is too similar to Windows 11 23H2 for ConfigMgr to tell the difference, or a detection method is wrong.

We followed this process and the systems in the collection are showing as “Compliant” so they never get the 23h2 update. Any ideas to get past this?