[English]Mitte Mai 2024 hat Microsoft das Out-of-Band-Update KB5039705 für Windows Server 2019 veröffentlicht, welches auf Systemen mit nicht englischem Sprachpaket den Installationsfehler 0x800f0982 des Sicherheitsupdates KB5037765 vom Mai 2024 korrigieren soll. Allerdings laufen Administratoren in einer Citrix-Umgebung in das Problem, dass Update KB5039705 mit dem Installationsfehler 0x8007371b scheitert. Es gibt aber einen Lösungsansatz, mit dem man versuchen kann, das Problem zu beheben.
Out-of-Band-Update KB5039705
Beim am 14. Mai 2024 veröffentlichte kumulative Update KB5037765 löste die Installation auf nicht englischsprachigen Windows Server 2019-Instanzen den Installationsfehler 0x800f0982 aus. Hintergrund war, dass dort das Sprachpaket en-us fehlte, welches zur Installation benötigt wurde. Systeme, die das Sprachpaket enthielten, ermöglichten i.d.R. dann die Installation des Update KB5037765. Microsoft hatte das Sicherheitsupdate vom 14. Mai 2024 dann zurückgezogen.
Microsoft hat dann zum 23. Mai 2024 das Out-of-Band-Update KB5039705 veröffentlicht, um das obige Installationsproblem mit dem Update KB5037765 auf Windows Server 2019 zu beheben. Dieses Update sorgte aber bei manchen Systemen für weitere Probleme, und ich habe im Beitrag Windows Server 2019: Installationsfehler bei Out-of-Band-Update KB5039705 vom 23. Mai 2024 einen Abriss der Fehler zusammen getragen, die mir untergekommen sind.
Citrix: Update KB5039705 scheitert mit 0x8007371B
Bereits zum 24. Mai 2024 hat sich Blog-Leser Horst in diesem Kommentar gemeldet und berichtet, dass das Out-of-Band-Update KB5039705 bei der Installation in einer Windows Server 2019 RDS-Umgebung mit Citrix VDA 1912 scheitert und den Installationsfehler 0x8007371B meldet. Weitere Leser bestätigen dieses Problem in der Citrix-Umgebung.
Im englischsprachigen Blog gibt es diesen Kommentar eines Nutzers, der den Installationsfehler 0x8007371b in Verbindung mit der RDS-Umgebung hat. Er konnte herausfinden, dass es von der installierten RDS-Rolle abhängt. Deinstalliert er die RDS-Rolle, kann er das Update installieren, bekommt um Anschluss aber die RDS-Rolle nicht mehr installiert, auch dort wird der Installationsfehler 0x8007371B gemeldet.
Auf reddit.com gibt es diesen Thread mit entsprechenden Bestätigungen des Fehlers. Eine weitere Fundstelle ist dieser Post bei Microsoft Q&A.
Ein Workaround für den Fehler
Blog-Leser MOM20xx hat sich dann in diesem Kommentar gemeldet (danke dafür) und nach Auswertung der cbs.log-Datei den Hinweis auf die Ursache des Installationsfehlers gefunden. Dort wird der Fehler STATUS_SXS_TRANSACTION_CLOSURE_INCOMPLETE gemeldet und auf eine Datei edgehtmlpolicy.bin verwiesen, deren Komponente amd64_microsoft-Windows-w..formplugins* wohl im Ordner C:\Windows\WinSxS fehlt.
Die Lösung besteht darin, den Ordner dieser Komponente mit Version .1 von einem anderen Windows Server 2019, der funktioniert, auf in den Ordner C:\Windows\WinSxS des streikenden Systems kopieren. Danach die Berechtigungen dementsprechend setzen. In einem weiteren Schritt ist per Registrierungseditor (erfordert administrative Berechtigungen) zum Schlüssel:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\amd64_microsoft-Windows-w..formplugins*
zu navigieren. Dort ist der Default Wert auf die .1 Version setzen und alle anderen Keys mit höheren Versionen sind zu löschen. Nun sollte die Installation beim nächsten Installationsversuch durchlaufen. Die Quelle für diesen Workaround findet sich im Artikel Windows: Windows Update error STATUS_SXS_TRANSACTION_CLOSURE_INCOMPLETE von Michls Tech Blog, wobei der Beitrag aus dem Jahr 2019 stammt.
Die genauen Paketnamen, die zu kopieren und per Registrierungseintrag zuzulassen sind, können dabei variieren (wird wohl durch den * in obiger Angabe ausgedrückt). Jiri Bergman hat in diesem Kommentar ein Paket mit vollständigem Namen benannt. Blog-Leser MOM20xx schrieb, dass er nach der Installation und einem Reboot noch eine Reparatur des Systems für Windows Server 2019 mittels folgender Anweisungen durchlaufen ließ.
DISM /cleanup-image /online /scanhealth DISM /cleanup-image /online /checkhealth DISM /cleanup-image /online /analyzecomponentstore und DISM /cleanup-image /online/startcomponentcleanup /resetbase gemacht
Inzwischen gibt es aber mehrere Bestätigungen, dass der Reparaturansatz wohl funktioniert hat. Vielleicht hilft es weiter.
Ähnliche Artikel:
Microsoft Security Update Summary (14. Mai 2024)
Patchday: Windows 10/Server-Updates (14. Mai 2024)
Patchday: Windows 11/Server 2022-Updates (14. Mai 2024)
Windows Server 2012 / R2 und Windows 7 (14. Mai 2024)
Windows Server 2019: Update KB5037765 scheitert mit Error 0x800f0982
Windows Server 2019: Revidiertes Update KB5037765 mit WSUS-Detection-Bug?
Windows Server 2019: Update KB5037765 zurückgezogen
Windows Server 2019: Out-of-Band-Update KB5039705 veröffentlicht (23. Mai 2024)
Windows Server 2019: Installationsfehler bei Out-of-Band-Update KB5039705 vom 23. Mai 2024
Also in meinem Fall existiert weder ein Ordner *amd64_microsoft-Windows-w..formplugins* noch ein entsprechender Regkey unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\
die cbs.log spuckt für mich (bisher) nichts aus, welcher Ordner genau fehlt
Eine Meldung STATUS_SXS_TRANSACTION_CLOSURE_INCOMPLETE trat aber in jedem Fall auf. Leider wurde die cbs.log so schnell erneut zugemüllt, bevor ich sie untersuchen konnte. Muss erneut probieren
Den CBS.log öffnen und nach: , error durchsuchen.
Sollte sich in dem Log der Fehler nicht finden lassen, den nächsten Archivierten CBS Log ansehen.
dann nimm *amd64_microsoft-windows-w..form-pluginpolicies*
***** Sterne fuer die Programmier-Daus bei MS. Wenn sie nicht mal mehr Citrix bei der Installation eines Updates beachten sollten sie lieber am Strand im Sand buddeln oder mit dem Smartphone von links nach rechts streichen.
Es könnte auch an Citrix selbst liegen. Ich hab in den letzten Jahren auch schon sehr oft erlebt, dass Citrix Receiver oder Workspace installationen diverse Windows 8.1 oder Windows 10 Installationen gekillt haben. Seitdem meide ich Citrix so gut es geht.
Bei dem File, das hier im übrigen bemangelt wird, geht es um wohl um ein verschlüsseltes File, dass für das damalige Flash Plugin in Edge diverse Domains automatisch für Flash freigeschalten hat. Also im Jahr 2024 vollkommen belanglos.
Es liegt ja nicht an Citrix sondern an der RDP Rolle. Bei unseren ca. 1000 Clients wurde in den letzten 15 Jahren noch nie ein OS durch Receiver/Workspace App Installation zerschossen.
Jain.
Die Systeme sind mittlerweile viel zu komplex, um alles mögliche zu testen und zu beachten. Zusatzsoftware und Änderungen per GPO/Regedit machen die Lage nicht einfacher.
Im Prinzip kann man sagen: je näher am Standard, desto eher läuft es einigermaßen rund, je weiter weg vom Standard, desto größer das Risiko bei Updates in Probleme zu laufen, weil Microsoft wohl hauptsächlich mit dem Standardsystem testet.
Ausnahmen bestätigen die Regel.
Und Citrix ist evtl. auch nicht ganz unschuldig.
Ändern des Reg Schlüssels auf die erste Version hat hier geholfen und Installation läuft durch, weitere Tests stehen noch aus.
Was das nun wieder für Auswirkungen haben wird bei einem der nächsten Updates. Was ein gefrickel, manoman und dafür soviel Geld bezahlen
Update: Mit den neuen Juni Updates läuft es vom Stand April ohne manuellen Eingriff nun durch. Fehler wurde durch MS behoben
Ich bekomme den Fehler obwohl ich kein Citrix sondern nur RDP nutze.
Citrix hat auch schon einmal das Spiel „Anno 1800“ lahmgelegt.
Citrix kann offenbar so einiges unvorhersehbar blocken.
Ich glaube auch ob VDA Agent oder nicht ist egal, die RDS Rolle ist das Problem.
bei reinen RDS Servern ohne VDA Komponenten hatten wir das Problem nicht. Das Problem wird erst erzeugt, wenn der neue Servicing Stack von MS installiert wurde. Selbst mit Backups aus Februar war es nicht möglich die Patches zu installieren. Sowie der aktuelle Servicing Stack installiert war, krachte es.
Dieser reg Schnipsel hat hier geholfen:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\amd64_microsoft-windows-w..form-pluginpolicies_31bf3856ad364e35_none_c84b413f649738e3]
@=“10.0″
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\amd64_microsoft-windows-w..form-pluginpolicies_31bf3856ad364e35_none_c84b413f649738e3\10.0]
„10.0.17763.1“=hex:01
@=“10.0.17763.1″
„10.0.17763.437“=-
Vielen Dank an Alle hier für die Hilfe.
Bei uns tritt das Problem auch auf, wenn der VDA in Version 2203 installiert ist (CU4 Update 1). Workaround habe ich noch nicht getestet.
Bei uns VDA 1912 CU8 und keine Probleme bei der Update Installation
Habe heute den Workaround von wz19 getestet. Die Installation des Updates hat danach einwandfrei funktioniert.
Komisch ist, dass das Problem nicht auf allen Citrix-Servern auftritt, obwohl diese über ein identisches Setup installiert wurden und auch alle den gleichen Patchlevel hatten (Windows und Citrix).
Sagt mal, kann irgendwer mit der letzten Variante vom CU auch Probleme mit Windows-Firewall und / oder GPOs bestätigen?
Ich habe gerade bei einem Kunden, mit den betroffenen Systemen jetzt den Spaß, dass z.B. das Monitoring seine Agents nicht mehr erreicht.
Auch bei mir hat es nach den beiden Regkeys funktioniert auf den Citrix Servern.
Vielen Dank!
VDA 2402
PVS mit Golden Image auf Basis Server 2019
Problem behoben mit Regkey Version anpassen und anderen löschen wie hier beschrieben und in diesem Post:
https://www.borncity.com/blog/2024/05/24/windows-server-2019-out-of-band-update-kb5039705-verffentlicht-23-mai-2024/#comment-182765
sfc uns dism habe ich nicht laufen lassen. Bisher keine Probleme.
Hole ich in der nächsten Version vom Master evtl. noch nach.
Danke an MOM20xx und alle anderen!
Und natürlich auch an Günter ;)
Bei mir war es nicht ganz derselbe Key.
Es war [amd64_microsoft-windows-w..form-pluginpolicies_31bf3856ad364e35_none_c84b413f649738e3]
Dieser lag bei mir in den Versionen .1 und .437 vor.
Ein Löschen war bei mir nicht notwendig, das Umstellen des Default Wertes in der
Registry hat gereicht.
Im übrigen sind beide Ordner vorhanden gewesen.
Im Anschluss hatte ich nur noch
> DISM /cleanup-image /online /scanhealth
ausgeführt, was problemlos durchlief.
Grüße