Trouble with unattended installation of W11 24H2 [Solved?]

That's not adding to much.

5058411.csv:
CBS\WindowsInternal.ComposableShell.Experiences.SuggestionUIUndocked\app.appx 572,342
Microsoft.BingSearch_8wekyb3d8bbwe.msixbundle 1,234,527
Microsoft.StartExperiencesApp_8wekyb3d8bbwe.msixbundle 2,653,487
Microsoft.WidgetsPlatformRuntime_8wekyb3d8bbwe.msixbundle 2,347,406
 
KB5043080 is the current 24H2 Checkpoint. It's not clear how often Checkpoints will be released.

In case anyone is wondering: Unlike a service pack, KB5043080 never registers as installed with any unambiguous artifacts anywhere.

Even if building with the newer NTLite that avoids this problem, it doesn't seem that KB5043080 ever shows as installed (get-hotfix ; systeminfo.exe)

However, the Registry is littered with references in various entries within tree [ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\ ]

I suppose all that implicit evidence is sufficient: If you're able to install CUs post-December 2024, Checkpoint CU KB6043080 was previously installed properly and the system is healthy.

1747435588893.png

~Brian
 

Attachments

  • 1747435606119.png
    1747435606119.png
    100.2 KB
Last edited:
As I'm beginning to understand, KB5043080 is not a normal SSU/CU. It is a "checkpoint", so therefore it is like a prerequisite checkpoint to be able to install all/any SSU/CUs beyond [ September 10, 2024 ] . Prior to [ v2024.10.10089 ] , it would silently fail to integrate, or integrate, but fail to register as having been installed.

If you integrated KB5043080 into W11 24H2 with NTLite versions prior to [ v2024.10.10089 ], the resulting target system would fail to apply/integrate SSU/CUs beyond [ KB5043080 / September 10, 2024 ] until KB5043080 is force-reinstalled manually with DISM (the .msu cannot be installed with Windows Update). The following work-around can help you with maintaining those images/installed systems; but one should rebuild your image with the latest NTLite versions v2025+

Bash:
B:\> more KB5043080.bat
@echo on
REM $Id$
dism /online /Add-Package /PackagePath:%~dp0\windows11.0-kb5043080-x64_953449672073f8fb99b.msu
pause

View attachment 14337
Additional notes on this:

I assumed that if a Win11 ISO was built with a CU/SSU after [ 2024-September] kb5043080, but with NTLite prior to [ v2024.10.10089 ] , it would be permanently broken.

As testing revealed, manually installing with NTLite prior to [ v2024.10.10089 ]would fail, but then so would installing any CU beyond [ 2024-September ].

Resulting in a Win11 system where there does not appear to be a way to patch-update a CU; thus resulting in a need for reinstallation.

However, it seems that this is not true: There is a procedure to rescue Win11 images built with NTLite prior to [ v2024.10.10089 ]:

1) Make a directory that contains both KB5043080 [ windows11.0-kb5043080-x64_953449672073f8fb99b.msu ]
2) Place the latest Win11/24H2 CU [ windows11.0-kb5074105-x64_74e1f93136eef7114e2bed8ff032b049ec62992a.msu for example, 2026-Jan ] in that same directory (*)
3) Run [ dism /online /Add-Package /PackagePath:%~dp0\windows11.0-kb5074105-x64_74e1f93136eef7114e2bed8ff032b049ec62992a.msu ]
4) After that, the Win11 host is now able to be normallly updated through standard update procedures to the latest CU by :
4.1) simply running the .msu via GUI
4.2) WMI PS-Remote calling ( wusa.exe "path\to\.msu" ) or DISM again

(*) Yes, indeed, that is the key. When DISM.EXE is reading [ windows11.0-kb5074105-x64_74e1f93136eef7114e2bed8ff032b049ec62992a.msu ] (or any patch newer), it will also look to open/search-for [ windows11.0-kb5043080-x64_953449672073f8fb99b.msu ] in that exact same directory.
 
Last edited:
The problem isn't NTLite, but was acknowledged to be Servicing issues with Oct/Nov 2024:

Issues might occur with media which installs the October or November update
StatusOriginating updateHistory
Resolved OS Build 26100.2033
KB5044284
2024-10-08
Resolved: 2025-02-06, 17:47 PT
Opened: 2024-12-24, 11:20

When using media to install Windows 11, version 24H2, the device might remain in a state where it cannot accept further Windows security updates. This occurs only when the media is created to include the October 2024, or November 2024, security updates as part of the installation (these updates were released between October 8, 2024 and November 12, 2024).

Please note, this only occurs when utilizing media - such as CD and USB flash drives - to install Windows 11, version 24H2. This issue does not occur for devices where the October 2024 security update or the November 2024 security updates are installed via Windows Update or the Microsoft Update Catalog website.

Resolution: To prevent this issue, do not install Windows 11, version 24H2 using media that installs the October 2024 or November 2024 security updates. If a device becomes unable to receive further updates as a result of this issue, it can be remediated by re-installing Windows 11, versions 24H2, using media which instead includes the December 2024 monthly security update (released December 10, 2024), or later.

Affected platforms:

Client: Windows 11, version 24H2
Server: None
 
My interest is never to assign blame (*), just solve the technical problem....my apologies if I trigger you >:}
~Brian

(*) Unless it something to do with the daily challenges of life in France, in which the French People and French Government are always to blame. >:}
 
I thought everyone solved this problem back in Jan/Feb 2025. :cool:
 
Back
Top