[English]Das Update KB5063878 vom 12. August 2025 für Windows 11 24H2 macht Probleme bei der Installation über WSUS. Es kommt zu einem Abbruch mit dem Fehlercode 0x80240069. Nun hat Microsoft dieses Problem zum 14. August 2025 in einem Supportbeitrag bestätigt und bietet ein KIR-Lösung als Fix an. Hier einige Informationen dazu.
Anzeige
Update KB5063878 und der Error 0x80240069
Das kumulative Update KB5063878 vom 12. August 2025 für Windows 11 24H2 beinhaltet Qualitätsverbesserungen sowie Sicherheitspatches, macht aber Probleme bei der Installation über WSUS. Mit liegen zahlreiche Berichte vor, dass die Installation mit dem Fehlercode 0x80240069 abbricht.
Ich hatte das Problem zeitnah im Blog-Beitrag Windows 11 24H2: Update KB5063878 wirft Installationsfehler 0x80240069 aufgegriffen. Dort werden auch mehrere Workarounds, vom Registry-Eintrag über Import des Updates im WSUS, vorgestellt (siehe auch den ergänzenden Kommentar hier). Wegen des erforderlichen Aufwands und der benötigten Reboots warten einige Administratoren ab.
Microsoft bestätigt das Problem
Nun hat Microsoft dieses Problem zum 14. August 2025 in einem Supportbeitrag bestätigt und bietet ein KIR-Lösung als Fix an (danke an die Leser für die Hinweise). Microsoft hat zum 13. August 2025 (US-Zeit) den Support-Beitrag August 2025 security update might fail to install via WSUS with Error 0x80240069 im Windows 11 24H2 Release Health-Dashboard eingestellt. Dort heißt es, dass das Windows-Sicherheitsupdate (KB5063878) vom 12. August 2025 für Windows 11 24H2 bei der Installation über Windows Server Update Services (WSUS) möglicherweise mit dem Fehlercode 0x80240069 fehlschlagen kann.
WSUS ermöglicht es Servern mit der WSUS-Rolle, Updates für bestimmte Geräte oder Gruppen innerhalb einer Organisation zu verschieben, selektiv zu genehmigen und zu planen.
Wichtig ist, dass nur die Verteilung per WSUS, und nicht der direkte Download per Windows Update von den Microsoft Update-Servern betroffen ist. Home-Anwender sollten nicht betroffen sein.
Anzeige
Microsoft schreibt, dass nur Windows 11 24H2 von diesem Problem betroffen sei. Mir liegt aber dieser Kommentar hier im Blog vor, der das Problem auch für Windows Server 2025 bestätigt.
Workaround durch Known Issue Rollback (KIR)
Microsoft schreibt, dass als Workaround ein Known Issue Rollback (KIR) für verwaltete Systeme bereitstellt, der die problematische Komponente zurück rollt. IT-Administratoren in Unternehmen können dieses Problem durch Download und Installation sowie anwenden der nachfolgenden Gruppenrichtlinie beheben:
- Download for Windows 11, version 24H2 Windows 11 24H2 and Windows Server 2025 KB5063878 250814_00551 Known Issue Rollback
Die Gruppenrichtlinie im KIR-Paket soll laut obiger Beschreibung auch für Windows Server 2025 (KB5063878) greifen.
In diesem Kommentar kritisiert ein Leser, dass muss nach dem "Aktivieren des KIR-Eintrags und der Verteilung der Client PC erst noch rebootet werden müsse". Das sei somit keine gute Lösung, denn die Client würden ja normalerweise nur rebooten, wenn ein Neustart durch ein Patch ansteht.
Tommy merkt in diesem Kommentar an, dass der manuelle Import des Updates im WSUS und das Ablehnen des automatischen Synchronisieren ja fehlerfrei funktioniert. Er würde diesen Ansatz daher weiter präferieren.
Ähnliche Artikel:
Microsoft Security Update Summary (12. August 2025)
Patchday: Windows 10/11 Updates (12. August 2025)
Patchday: Windows Server-Updates (12. August 2025)
Patchday: Microsoft Office Updates (12. August 2025)
Windows 11 24H2: Update KB5063878 wirft Installationsfehler 0x80240069
Anzeige
Nutz wirklich niemand den Connected Cache Service von MS?
https://learn.microsoft.com/de-de/windows/deployment/do/mcc-ent-edu-overview
Ich bin gerade im Urlaub und kann nicht prüfen ob es dort auch Probleme gibt.
In den letzten Monaten war das deutlich stabiler wie der WSUS.
Mir ist immer noch am liebsten die Methode mit dem Import der Update Catalog Datei auf den WSUS. Sehr unkompliziert und funktioniert ohne die Systeme irgendwie verbiegen zu müssen.
Dito.
War in 5min gemacht und funktioniert bei uns bisher einwandfrei.
Ich hoffe nur dass dieser Weg später nicht irgendwelche andere Probleme erzeugt…
Hi,
eine Verteilung der Windows Updates über den Connected Cache sollte keine Probleme (nicht von mir getestet) bereiten, da hier das reguläre Updatepaket, welches auch über Windows Update verteilt, verwendet wird.
Wir haben einzelne Bereiche z. B. Produktion, wo der Internetzugriff gesperrt ist. Dort können die Windows Rechner nur per WSUS gepatcht werden, da für Connected Cache zwingend eine Internetverbindung der Clients benötigt wird.
Dein Cache Server ist ne Linux VM wo Container von Microsoft deployed sind. Da braucht nur der Cache Server Verbindung ins Internet. Die Clients können sich auch ohne Internet Verbindung dann die Updates holen. Soll ja Bandbreite sparen.
Gpo sagen wo der Cache Server erreichbar ist für die Clients, mehr muss da nicht definiert werden.
der Cache reduziert ja nur den Load, verwaltet aber keine Updates
selten dämlicher installer mal wieder.
statt dass man einfach die admx zum download anbietet
Ihr findet sie dann unter dem Namen KB5063878_250814_0055_1_KnownIssueRollback
im Ordner C:\Windows\PolicyDefinitions
sowie das Sprachfile im C:\Windows\PolicyDefinitions\en-US
Einfach mit einem Zip Tool enpacken
Ich habe heute Morgen mal auf dem WSUS das Paket abgelehnt, den wsus bereinigt und das Paket neu genehmigt. Nach dem Download habe ich eine meiner TestVM darauf angesetzt. Das Paket wurde geladen und installiert. Allerdings war die VM auf dem Patchstand März diesen Jahres. Kann jetzt Zufall sein.
Auf jeden Fall vergeht doch fast kein Patchday mehr seit gefühlt einigen Jahren ohne das es irgendwo Arbeit für die Admins gibt.
Ätzend für uns, gut für Günter und seinen Blog.
Mir ist auch schon aufgefallen das ältere 24H2 Patchlevel das Patch fressen, wenn 24H2 aber auf Stand vom letzten Monat ist, nicht
Heute Nacht ist ein neues 24H2 August Patch auf dem WSUS angekommen.
Das Alte wurde zurückgezogen. Das Update muss also neu genehmigt werden, da nicht nur eine neue Revision ist.
Korrekt – 7:18 unserer Zeit wurde das auch im Supportbeitrag hinterlegt. Allerdings ist im Update Catalog nach wie vor das "alte gefixte" Update hinterlegt… Seeehr dubios in meinen Augen was MS da veranstaltet. Mich würde ja langsam doch mal deren ganze interne Struktur und Workflow interessieren.
Update Catalog: Update ID 92061378-be93-4659-a72a-037225e6bb0f
WSUS Sync: Update ID 7e6cc676-cc0c-4373-b32c-cec2f5b1f285
"Korrekt – 7:18 unserer Zeit wurde das auch im Supportbeitrag hinterlegt."
Link? Find ich nicht, nur die KIR info
WSUS Sync Update-ID:
vorher 8018eab0-7242-4932-adf2-afda36f6b3f6
aktuell 7e6cc676-cc0c-4373-b32c-cec2f5b1f285
—
Hat sich die Checksumme verändert?
(sha1 vorher: c2d51482402fd8fc112d2c022210dd7c3266896d)
Ist das Patchlevel nach der Installation größer als (Build 26100).4946?
Unsere WSUS haben heute früh neuere Versionen des Updates synchronisiert. Offenbar hat MS nachgebessert.