[English]Microsoft hat zum 23. Mai 2024 (also in Europa am gestrigen späten Abend) das Out-of-Band-Update KB5039705 für Windows Server 2019 veröffentlicht. Dieses Sonderupdate wurde erforderlich, weil das am 14. Mai 2024 veröffentlichte kumulative Update KB5037765 zurückgezogen werden musste. Das Update löste bei der Installation auf nicht englischsprachigen Windows Server 2019-Instanzen den Installationsfehler 0x800f0982 aus. Hier einige Informationen zu diesem Problem und dem Sonderupdate KB5039705.
Anzeige
Out-of-Band-Update KB5039705
Die Information über das Out-of-Band-Update KB5039705 erreichte mich über die zahlreichen Leserkommentare im Beitrag Windows Server 2019: Update KB5037765 zurückgezogen (danke dafür). Das kumulative Update KB5039705 wurde am 23. Mai 2024 für Windows Server 2019 (sowie Windows 10 2019 Enterprise LTSC und IoT Enterprise LTSC ) bereitgestellt und hebt die Build auf 17763.5830. Als Korrektur wird nur angemerkt:
Dieses Update behebt ein bekanntes Problem im Zusammenhang mit dem Sprachpaket Englisch (USA). Wenn sie auf Ihrem Gerät nicht vorhanden ist, schlägt die Installation von KB5037765 möglicherweise fehl. Der Fehlercode ist 0x800f0982.
Dieses Problem kann sich jedoch auf Geräte auswirken, die über dieses Sprachpaket verfügen. In diesem Fall wird der Fehlercode 0x80004005 [ausgegeben].
Microsoft erwähnt auch, dass das SSU KB5037017 (Servicing Stack Updates) auf die Build 17763.5695 aktualisiert wurde. Dort werden qualitative Verbesserungen angegeben. Aktuell sind Microsoft keine Probleme mit dem Update bekannt.
Das Problem mit Update KB5037765
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.
Rückmeldungen zum Update KB5039705
Zum Blog-Beitrag Windows Server 2019: Update KB5037765 zurückgezogen haben sich bereits zahlreiche Leser mit Hinweisen auf das Sonderupdate gemeldet. Robert Glöckler hat sich bereits sehr früh in diesem Kommentar gemeldet und berichtet, dass das 2024-05 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5039705) veröffentlicht worden sei.
Robert merkt an, dass das Update "leider es auch für die Systeme erforderlich ist, die er über Umwege schon mit dem ersten CU gepatcht hatte". Das ist meiner Interpretation nach dem Umstand geschuldet, dass das Sicherheitsupdate vom 14. Mai 2024 den Fehlercode 0x80004005 auslösen kann, wenn das Sprachpaket en-us auf dem System vorhanden ist.
Das Update KB5039705 sollte auf dem WSUS beim Synchronisieren angezeigt werden (siehe Screenshot) und kann dann auf nicht englischsprachigen Systemen installiert werden. Das fehlerhafte Update KB5037765 vom 14. Mai 2024 sollte auf dem WSUS als "superseded" (abgelöst) angezeigt werden.
In diesem Kommentar gibt es eine erste Bestätigung, dass das Update ohne Fehlermeldung installiert werden konnte. Ein weiterer Nutzer merkt hier an, dass die Installation (im Gegensatz zum fehlerhaften Update vom 14. Mai) erstaunlich schnell von statten gehe. Einen Neustart des Windows Server 2019 hat dieser Nutzer bisher noch nicht ausgeführt.
Anzeige
Allerdings hat sich Fritz hier gemeldet und berichtet, dass zwei Server wieder mit dem Fehler 0x800f0985 ausgestiegen seien. In den nachfolgenden Kommentaren finden sich Meldungen, dass Server, auf denen das fehlerhafte Update KB5037765 vom 14. Mai 2024 installiert werden konnte, mit den Fehlermeldungen 0x800f0985 und 0x800f0986 scheitern können. Der letztgenannte Fehler deutet auf beschädigte Dateien hin. Es ist verhext, Microsoft hat es versaut.
Ergänzung: Ich habe im Beitrag Windows Server 2019: Installationsfehler bei Out-of-Band-Update KB5039705 vom 23. Mai 2024 einen Abriss der Probleme zusammen getragen, die mir untergekommen sind.
Ergänzung 2: Zudem gibt es in Citrix-Umgebungen den Installationsfehler 0x8007371B, den ich im Beitrag Windows Server 2019 OOB-Update KB5039705: Citrix-Fehler 0x8007371B aufgegriffen habe.
Update auch für Windows 10 2019 Enterprise
Bei meinem Windows 10 2019 IOT Enterprise LTSC wird das erwähnte Update KB5039705 übrigens auch angeboten, obwohl die Installation des Update KB5037765 durchgelaufen ist. Hier scheint Microsoft proaktiv das Update auszurollen, um den potentiellen Installationsfehler 0x80004005, verursacht durch das Altupdate KB5037765, auszumerzen. Ich habe die Installation aktuell aber noch nicht ausführen lassen – mache das gleich und werde nachtragen, ob es Probleme gab.
Ä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: Installationsfehler bei Out-of-Band-Update KB5039705 vom 23. Mai 2024
Windows Server 2019 OOB-Update KB5039705: Citrix-Fehler 0x8007371B
2015
Seit ich das KB5039705 am Server 2019 welcher den WSUS Server betreibt installiert habe, liefern die Windows Clients den Fehler 0x8024401c bei der Suche nach Updates.
Zufall, oder macht das KB5039705 den WSUS Server kaputt?
Hat jemand dasselbe Problem?
Ich habe das gerade getestet und nein, dieses Verhalten kann ich nicht nachvollziehen.
Danke für die Info, bei mir läuft der WSUS inzwischen auch wieder, es lag nicht am Update.
Der WSUS braucht nun seitdem ich vor einigen Wochen auch die Treiber mit in den Klassifizierungen ausgewählt habe etwa 1,75 Std. bis er nach dem Reboot bereit ist um auf Anfragen von Clients zu antworten. Die WSUS Console hatte in dieser Zeit aber schon normal reagiert.
Hierbei läuft bei mir der w3wp.exe Prozess nach dem Reboot auf voller CPU Auslastung und der Arbeitsspeicher des Prozesses steigt langsam bis auf 12 GB. Erst danach ist der WSUS Server für die Clients erreichbar.
WSUS mit Treibern braucht anscheinend irre viel Ressourcen.
Hatte das auch mal versucht, aber bald wieder sein gelassen. Zweiter Grund war, dass für etliche sehr alte Grafikkarten gar nicht der neueste Treiber darüber zur Verfügung gestellt wurde, das erhoffte 'ich muss nicht mehr nach Treibern schauen' also nicht erreicht wurde.
Ja, ich musste deswegen den RAM vom IIS mehrmals hochdrehen, da der sich immer aufgehängt hatte bevor er alles verbeiten konnte.
Am SQL Server benötigt er auch noch etwa 50 GB an SSD Speicher.
Jetzt klappt es im Prinizp damit, auch wenn alles etwas träge ist, aber wie kann man sonst Treiber Updates (gibt ja auch sicherheitsrelevante) auf viele Clients am besten verteilen?
Auch bei uns ist aufgrund schlechter Erfahrungen die Kategorie Treiber im WSUS deaktiviert.
Wir nutzen daher für die Aktualisierung der Treiber die Tools der Hersteller.
Die Installation erfolgt über unsere Softwareverteilung bzw. UEM-Lösung.
Bei DELL ist dieses aktuell Dell Command | Update und bei Lenovo der Thin Installer im Zusammenspiel mit dem Update Retriever.
Bist Du sicher, dass auf dem System alle Updates korrekt installiert worden sind?
Wir hatten hier letztens ein ähnliches Phänomen auf einem virtualisierten Server 2019 Core mit Exchange. Da kam es nach Update-Installation (Windows + Exchange) beim Neustart zu einem Fehler, welcher einen weiteren Neustart nötig gemacht hat. Wahrscheinlich war das der Grund, warum die Updates nicht korrekt zu Ende eingespielt wurden — was aber zunächst nicht auffiel.
Allerdings fiel zwei Tage später auf, dass der Exchange, der auf den ersten Blick normal lief, doch etwas träger wurde. Bei der Kontrolle hab ich dann bemerkt, dass eine der vielen w3wp.exe mittlerweile bei uns ungewöhnliche 12GB an RAM belegt hat, kontinuierlich im kByte Bereich weiter steigend. Es war absehbar, dass das irgendwann womöglich zum Crash führen könnte.
Ich hab das health-Checker-Script des Exchange einmal laufen lassen und dann gesehen, dass dieses unter anderem 'pending updates' und 'system needs reboot' geliefert hat.
Ein weiteres Mal den Server neu gestartet und danach war das w3wp-RAM-Problem behoben.
Vielleicht liegt ein ähnliches Problem beim IIS des WSUS vor?
Sieht bei mir ähnlich aus, nur dass bei mir die Ressourcenauslastung nicht ganz so krass ist.
Es gab keine Änderung in der Konfiguration, Treiber werden aber vom WSUS mit ausgeliefert. Aber seit ca 1-2 Wochen braucht WSUS ungefähr eine Stunde nach dem Reboot, bis Anfragen angenommen werden. Danach geht auch alles wieder ganz ok.
grandios was die kapazunder in redmond wieder leisten. wir haben nur englisch sprachige systeme. haben am patchday das update installiert, welches dann zurückgezogen wurde. und nun ist auf allen englischsprachigen servern plötzlich der out-of-band patch nötig.
sorry für den unfug fehlt mir langsam aber sicher das verständnis. sind da in redmond nur hirntote unterwegs?
"sind da in redmond nur hirntote unterwegs?" – Ja sicher. Lies die Beschreibung des OOBs durch: "This update addresses a known issue that is related to the English (United States) language pack. If your device does not have it, installing KB5037765 might fail. The error code is 0x800f0982. But this issue might affect devices that do have that language pack. In that case, the error code is 0x80004005."
Also: wenn du das Languagepack (Oder dieses OOB Update?) nicht hast, hast Du ein Problem mit KB5037765 und zwar Code x und wenn du es aber NICHT hast, dann Code Y. Alles klar?
Hallo
Meine Frage in die Runde (bei MS versuche ich es nicht):
Wenn ich letzte woche LanguagePacks nachinstalliert habe, und das Update danach "erfolgreich" installiert habe, sollte ich das Out-off-Band Update jetzt trotzdem installieren, Gab es noch mehr Probleme, ggf funktioneller Art?
Ich installiere gerade KB5039705 über ein System mit KB5037765 drüber, es dauert wieder so lange und erfordert einen Reboot. "Ist es das wert?"
Sorry das schlimmste an Microsoft ist generell die Intransparenz und damit verbreitete Unsicherheit.
Gruß Reiner
Ja das musst du. Über Windows Update wird es auch angeboten, trotz Installation des englischen Pakets mit Sprachpaket. Hatte ich so bei mir letzte Woche durchgeführt. Installation muss also nochmal erfolgen.
WorkAround hätte man sich sparen können :(
Ich habe da inzwischen eine Zeile zu geschrieben (wegen Beitrag in Progress hast Du das noch nicht gelesen): Nach meiner Lesart ist das Update KB5039705 auf den Server 2019-Systemen erforderlich, auch wenn das Update KB5037765 mit dem von mir genannten Workaround installiert werden konnte. Der Hintergrund: Microsoft schreibt ja, dass das Update KB5037765 bei der Installation einen Fehler 0x80004005 auslösen kann. Da ist also im Code noch ein Bug gefunden worden, der mit dem Sonderupdate wohl (so mein Verständnis) ausgemerzt wird. Zudem kommt ja noch ein SSU mit.
Die Version des SSU wurde schon mit dem April Update ausgeliefert.
ich denke, wenn man das KB5037765, wie auch immer, auf das System installiert bekommen hat, sind die CVE gepatcht und das KB5039705 bringt keinen Mehrwert. Eine neue Revision des alten Paketes wäre zu einfach gewesen.
es dauert ja nicht mehr lange bis das nächste kumulative Update kommt und dann taktet sich alles wieder ein.
Wenn ich die hier berichteten Installationsfehler sehe, gebe ich dir Recht. Hoffen wir, dass da nicht noch mehr schlummert, dann wird es im Juni ekelig.
Server 2019 deutsch, KB5037765 nicht installiert, auch keine weiteren Sprachpakete.
WSUS hat mir heute morgen KB5039705 angeboten, habe es auf einem Testsystem installiert. Ging rasch und ohne Auffälligkeiten. Der WSUS Server hat das Update noch nicht erhalten.
Ja, hier gerade auch mal auf einem Server installiert. Lief unauffällig durch.
Ja, hier bei 4 Servern unauffällig durchgelaufen.
Der WSUS kommt jetzt dran…
Auch WSUS hat funktioniert – zwei Clients sind auch durch.
Wurde hier im Blog zwar auch schon thematisiert und nochmal als Erkenntnis, aber selbst US_EN Windows Server 2019 machten ab 16. Mai, als KB5037765 in der neueren Revision 201 released wurde, "Probleme". Da kam wohl wirklich ein Detection Bug mit, denn das revidierte Update konnte sowohl direkt mit WSUS, als auch zusätzlich mit MECM nicht mehr angewendet/installiert werden (Windows Server 2019 wurden als "up-to-date" ausgewiesen, obwohl dies nicht der Fall war. Zumindest bei uns). Am 15. Mai ging es mit der Erst-Revision 200 noch ohne Probleme.
Weiß jemand, ob man nach der Installation von KB5039705 das englische Sprachpaket wieder deinstallieren kann?
Das Ganze ist reichlich seltsam. KB5039705 enthält gegenüber KB5037765 keinerlei zusätzlichen Fehlerbehebungen außer dass sich das alte Update nicht auf 2019er ohne englische Langpacks installieren ließ. Unsere bisher schon erfolgreich mit KB5037765 gepatchten Server melden bisher auch keine Notwendigkeit, auch KB5039705 zu installieren. Aber wenn man das 684 MB große MSU manuell aus dem Update Catalog runterlädt und auf so einem Server manuell installiert, installiert er es.
Ich fände es jetzt übrigens nicht in Ordnung, wenn jetzt die schon mit KB5037765 gepatchten Server nochmal mit KB5039705 aktualisiert werden müssten, obwohl es keine zusätzlichen Fehlerbehebungen mitbringt. Das ist unnötige Arbeit.
tja nachdem sie in der beim alten KB eine neue REV für WSUS rausbrachten, die das Ding dann nicht mal mehr als installed erkannte oder so bei englischsprachigen Servern und die neue Version die alte ersetzt gemäß WSUS, heisst es patchen. Bei uns haben alle Englischsprachigen Server das Update benötigt. Installationszeit ca. 10 Minuten. Bin grad am Verteilen.
Du kannst das KB5039705 in deinem Fall wie ein Vorschau-Update bei den Clients behandeln. Wenn du die auch nicht verteilst, lass es bleiben. Mit erfolgreich installiertem KB5037765 sind die Server sicherheitstechnisch auf dem aktuellen Stand.
Funktioniert und lässt sich auf allen 2019 Servern problemlos relativ schnell installieren.
Wir hatten aber auch nicht am System rumgefummelt sondern, haben auf dieses OOB gewartet.
Auch hier keine Probleme mit der Installation über WSUS (Windows Server 2019 und Windows 1809 LTSC) auf 2 Testsystemen.
OS Build Number nach dem Update: 17763.5830
keine Probleme bei der Installation
Vorsicht bei Systemen, die bereits KB5037765 installiert haben. Auf diesen bekomme ich den Fehler 0x800F0986.
Auf Systemen, welche das KB5037765 noch nicht hatten, läuft es durch.
dann hat das System einen Schuss. Neben dem Löschen des Softwaredistribution-Ordners kann auch eine Reparatur nötig sein
"Der Windows-Update-Fehler 0x800F0986 kann auftreten, wenn wichtige Dateien des Windows Betriebssystems beschädigt sind. In diesem Zusammenhang kann die Durchführung von SFC- und DISM-Scans die Beschädigung der Windows Systemdateien beheben und somit das Problem lösen."
Evtl auch mal im Ereignisprotokoll nachsehen ob Storage-Probleme dabei sind. Nicht, dass die Systeme irgendwann mitten im Betrieb aussteigen oder andere Daten kaputtschreiben.
Sind glücklicherweise virtuelle unkritische Systeme und ich habe einen Snapshot :).
Aber da es gleich drei Maschinen sind (und alle mit erfolgreichem KB5037765), die es betrifft werde ich erstmal vorsichtig sein…
Dieser Monat ist verhext ;)
Der französische Kommentar von aa besagt, dass sfc und dism bei ihm nicht geholfen haben. Hier bleibt nur eine CBS.log-Analyse, in der Hoffnung, was zu finden.
Das Löschen des Softwaredistribution-Ordners schlägt fehl,
wenn nicht zuvor die entsprechenden Dienste gestoppt werden, die auf diesen Ordner zugreifen.
Was ggf. helfen kann ist ein Zurücksetzen des lokalen Windows Update Dienst.
Hierzu gibt es zahlreiche Anleitungen im Netz, z. B. (ohne Gewähr):
https://github.com/wureset-tools/reset-wsus-client-id/blob/master/resetSUSClientID.bat
Echt Klasse:
Installation Failure: Windows failed to install the following update with error 0x800F0986: 2024-05 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5039705).
Hyper-V 2019 (die kostenlose Core Version)
Freigabe über WSUS
KB5037765 nicht installiert
Bei uns kein Problem, egal ob das alte schon installiert war oder nicht.
Hatte ich (wie oben zusammengefaßt 😅) bei zwei von 10 Systemen auch. Hier hat es geholfen, KB5037765 zu deinstallieren. Es waren die ersten Systeme aus der Testumgebung, auf denen ich zuerst KB5037765 und erst dann nach den bekannten Problemen das Languagepack en-US installiert hatte.
Bei allen später installierten Testsystemen war die Reihenfolge umgekehrt und die lassen sich sauber und schnell patchen – wie auch Systeme ganz ohne zweite Sprache.
Die beiden genannten laufen nach Deinstallation von KB5037765 auch. SFC und DISM fanden übrigens in diesem Zwischenzustand keine Fehler.
Das ist ja der Wahnsinn, wir haben weil es wirklich recht lange dauerte bis MS reagierte. Am letzten Wochenende alle System erfolgreich und stressfrei mit dem Sprachpaket-Workaround updates können. Dabei hatten wir aber schon die Revision 201 welche am 16.05.2024 veröffentlicht wurde verwendet.
Soweit wir es nach einer Woche Betrieb ( Betrifft insgesamt 17 Server, davon 4 DC ) beurteilen können läuft alles soweit normal.
Mir ist jetzt auch leider nicht ganz klar warum ich das jetzt alles nochmal machen muss. Sicherheitsrelevant ist ja offenbar nicht. Denn wischen dem vom 16.05 und dem OOB von Gestern gibt da ja keinen Unterschied.
Was spricht also Dagegen einfach auf den nächsten Patchday zu warten und dann wieder "Normal" weiter zu machen?
Und wenn schon drüber installiert werden muss? Das ist mit dem Sprachpaket. Drauf lassen. Deinstallieren? In welcher Reihefolge?
jaa einfach drüber installieren, du kannst das zusätzliche Sprachpaket auch lassen. Hat bei mir funktioniert :)
Vorgang war
letzte Woche:
Sprachpaket installiert, englisches CU, alles okay
heute "richtiges /deutsches CU" drüber :) – funktioniert alles!
schönes Wochenende
Die Frage war glaube ich:
Muss das jetzt? Oder reicht es das nächste Update am Patchday 06 2024 zu installieren?
(wenn man den Workaround schon hat)
Windows Server 2019 RDS mit Citrix VDA 1912 schlägt KB5039705 mit 0x8007371b fehl, sowohl aus dem Updatekatalog als auch über Windows Update. Installation ca. 20 Minuten, Rollback ca. 10 Minuten.
Hallo Horst,
ich kann das Verhalten bei mir mit Citrix VDA 2203 CU4 bei meinem Masterimage (PVS) bestätigen.
Sowohl über Updatekatalog manuell heruntergeladen, als auch über WSUS, bekomme ich die gleiche Fehlermeldung 0x8007371b.
Ein Versuch über:
DISM /ONLINE /CLEANUP-IMAGE /….
….
Sfc /Scannow
hat nichts geholfen und es bleibt bei dieser Fehlermeldung.
Ein manuell installierter Citrix Worker lässt sich updaten. Es könnte also an den Treibern / Technik von PVS liegen.
Die restlichen 38 Windows 2019 Server liefen ebenfalls mit dem WSUS ohne Probleme durch.
Ich fürchte wir (Citrix Admins) dürften alle das gleiche Problem haben. :-(
Tja das Problem hatten wir auch nun ist klar warum. auf beiden Servern waren Komponenten der Firma Citrix drauf.
https://michlstechblog.info/blog/windows-windows-update-error/ schafft abhilfe. Im CBS.Log wird der Fehler STATUS_SXS_TRANSACTION_CLOSURE_INCOMPLETE aufscheinen bei einem File edgehtmlpolicy.bin file es geht um die komponente amd64_microsoft-Windows-w..formplugins*
Im Ordner C:\Windows\WinSxS fehlt dazu ein Ordner dieser Komponente mit Version .1 diesen von einem Anderen Server reinkopieren und die Berechtigungen dementsprechend wieder setzen.
danach in der registry unter
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\amd64_microsoft-Windows-w..formplugins*
den default auf die .1 Version setzen und alle anderen Keys mit höheren Versionen löschen. Danach sollte das Update beim 2. Versuch sich installieren lassen. So haben wir das bei uns gelöst bekommen.
Wir haben nach der Installation und einem Reboot noch
DISM /cleanup-image /online /scanhealth
DISM /cleanup-image /online /checkhealth
DISM /cleanup-image /online /analyzecomponentstore und
DISM /cleanup-image /online/startcomponentcleanup /resetbase gemacht
in my case on WS2019 it was
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\amd64_microsoft-windows-w..form-pluginpolicies_31bf3856ad364e35_none_c84b413f649738e3\10.0
default value to 10.0.17763.1 and delete 10.0.17763.437 value
Thank, and many many thanks Jiri,
it works for me.
thank u
thanks, it works for registery.
many thanks to Jiri.
it worked,
but after restart en CMD sfc /scannow it shows in cbs.log that is missing file amd64_microsoft-Windows-w..formplugins*.
think needs to be as describe as MOM20xx said.
how do you copy and past with needs security privelege in winSXS?
Vielen lieben Dank!
Die Lösung funktioniert auch bei uns.
Bei uns hat sogar der registry part gereicht.
Beste Grüße
Works on our Citrix VDAs!
Thx for these hints
Danke – hab die Info mal in einem separaten Blog-Beitrag herausgezogen – siehe meine Ergänzung oben im Text mit dem betreffenden Link. Hilft ggf. auch, falls jemand an der RDS-Rolle scheitert.
in my case, there is no Reg Key matching that. and in CBS-log it is not "formplugins" but "form-pluginpolicies"
so I guess there are many different possibilities…
yes use "form-pluginpolicies" also for registry.
for me using LTSC 2019, it is "form-pluginpolicies"
Stand 24.5.2024 18:00 bei mir
– aktuelles Update wurde auf allen Servern angezeigt und lief ohne Fehlermeldung durch. Neustart und Betrieb danach ohne Probleme.
Im Vorfeld bei mir:
– alle bis auf einen Server: Workaround mit Installation Sprachpaket funktioniert.
– ein Server: Sprachpaket ließ sich nicht installieren. fehlermeldung. Folglich ließ sich auch das Update nicht installieren.
Heute abends:
– auf allen Servern – auch jenen mit Workaround – wurde Update angezeigt und ließ sich installieren
– auf den Servern auf denen der Workaround mit dem Sprachpaket ausgeführt wurde lief die Installation schneller durch. Ich würde schätzen etwa doppelt so schnell wie sonst.
– auf dem einen Server, wo der Workaround und das Update nicht installiert waren, dauerte die Installation des Updates so lange wie sonst auch immer.
Vielleicht war es bei mir "Zufall" (oder irgend eine andere Gegebenheit) – aber da wo der Workaround durchgeführt wurde, lief es schneller.
Vorsicht bei HyperV-VMs
KB5039705 hat mir eben eine VM zum Stillstand gebracht.
Die Installation (vom WSUS geholt) lief so weit durch, dann Restart …
Warten …
Warten …
Warten …
Die VM war auch nach ner halben Stunde nicht pingbar oder vom Host aus verbindbar, einfach nur "schwarz".
Konfiguration:
– Host: Win2019 noch ohne KB5039705,
– VM: Win2019 beim Versuch von KB5039705,
– Beide Maschinen bislang durchgepatcht bis/mit KB5036896 2024-04 CU for WinServer 2019
Nachdem der Guest also tot war, Versuche am Host, den Guest von außen Herunterzufahren: Kein Erfolg, dafür 0x800705B4, offenbar eine Timeout-Meldung
Dann also: Hart Ausschalten. Guest kam wieder hoch, verarbeitete sein Update und läuft nun wieder (ob er alles macht wie vorher, ist noch in Prüfung).
In die Produktion kann ich KB5039705 so nicht geben.
Saftladen.
Bonjour,
J'avais installé le 15/05/24 la KB5037765 sur 4 serveurs Windows 2019 French
j'avais l'erreur 0x800f0982, j'avais installé le language pack en puis relancé la KB5037765, celle ci était passée.
Aujourd'hui est sortie la KB5039705 , elle est passée sur 3 de mes serveurs par contre sur le dernier 0x800f0986
j'ai tenté :
sfc /scannow OK
cmd en mode admin
Dism /Online /cleanup-Image /CheckHealth OK
Dism /Online /cleanup-Image /ScanHealth OK
Dism /Online /cleanup-Image /RestoreHealth
cette dernire commande renvoie erreur: 0x800f0954
chkdsk C: /F /R: OK
Reboot relance windows update meme erreur 0x800f0986
une suggestion ?
Hallo tuxbox64,
Ich antworte mal in deutsch.
Ich hatte Probleme mit einem Server 2022, Fehlermeldung bei RestoreHealth weiß ich nicht mehr genau. Da half es als /Source einen anderen Server anzugeben:
Dism /online /Cleanup-Image /RestoreHealth /Source:\\goodserver.domain\C$\Windows
Damit konnte er das System reparieren.
Guten Morgen,
ich stelle den Kommentar erneut ein, der mithilfe eines Übersetzers ins Deutsche übersetzt wurde …
Ich hatte am 15.05.24 KB5037765 auf 4 Windows 2019 French Servern installiert.
Ich hatte den Fehler 0x800f0982, ich hatte das Sprachpaket installiert und dann die KB5037765 neu gestartet, diese war durchgelaufen.
Heute wurde KB5039705 veröffentlicht, das auf drei meiner Server funktioniert, auf dem letzten jedoch 0x800f0986.
Ich habe es versucht:
sfc /scannow OK
cmd im Admin-Modus
Dism /Online /cleanup-Image /CheckHealth OK.
Dism /Online /cleanup-Image /ScanHealth OK
Dism /Online /cleanup-Image /RestoreHealth
Dieser letzte Befehl gibt einen Fehler zurück: 0x800f0954.
chkdsk C: /F /R: OK
Reboot startet Windows Update neu, gleiche Fehlermeldung 0x800f0986
ein Vorschlag?
Übersetzt mit DeepL.com (kostenlose Version)
Deinstalliere das das Update KB5037765 vom 14. Mai 2024 und versuche die Installation von Update KB5039705 erneut – Blog-Leser berichten, dass dieser Ansatz erfolgreich war. Es sieht so aus, als ob KB5037765 etwas kaputt macht, was Nachfolge-Updates dann in den Fehler 0x800f0986 laufen lässt. Aufschluss könnte möglicherweise die Analyse der cbs.log liefern.
———-
Uninstall the KB5037765 update from May 14, 2024 and try installing update KB5039705 again – blog readers report that this approach was successful. It looks like KB5037765 is breaking something, which then causes subsequent updates to run into error 0x800f0986. The analysis of the cbs.log could possibly provide information.
————————–
Désinstaller la mise à jour KB5037765 du 14 mai 2024 et réessayer d'installer la mise à jour KB5039705 – des lecteurs du blog rapportent que cette approche a été couronnée de succès. Il semble que KB5037765 casse quelque chose, ce qui fait que les mises à jour suivantes se terminent par l'erreur 0x800f0986. L'analyse du fichier cbs.log pourrait éventuellement fournir des informations.
Der Fehler lautet 0x800f0985 bei einem Server. Eine Deinstallation (Reboot, "wartete" dann 5 Minuten bei 100%) und die Installation des Updates KB50339705 hat geholfen.
Ich hab den gesamten Master weggeworfen und mit einer sauberen Version mit Patchstand 04/2024 gestartet, ohne jemals einen Versuch des zurückgezogenen Updates. Genauso kaputt wenn ein Citrix VDA drauf ist.
Danke an Microsoft für einen kompletten Releasezyklus, den ich neu machen darf…
Jepp!
Schließe mich an. Den ganzen (sonnigen) Samstag damit verballert und Ergebnis gleich null, außer verlorener Lebenszeit. :-(
Allerdings bei mir ist der VDA Agent auf einem Standalone Worker 2203 LTSR CU 4 durchgelaufen. Nur nicht die PVS Kisten (11 Stück)
Schönes Restwochenende!
Ginko
J'ai désinstallé la KB5037765, rebooté, relancé le Windows update demande alors la KB50339705 mais refuse de l'installer,
2024-05 Mise à jour cumulative pour Windows Server 2029 pour les systèmes x64 (KB5039705)
erreur 0x800f0986
par contre une autre KB qui n'etait pas demandée elle est bien passée: KB5012170
Je pense que je vais attendre la prochaine KB du mois de juin
je pense que la KB50339705 n'est pas encore au point , Merci Microsoft !
J'ai fait une restauration de mon serveur (machine virtuelle) à avant la mise à jour KB5037765, lancement ensuite Windows update , la KB5039705 c'est alors bien installée.
Dorénavant je patienterais avant d'installer les nouvelles maj, avec la fiabilité des updates Microsoft, je préfère dorénavant patienter
Wie kopiere ich den Ordner von einem anderen System nach WinSxS? Ich kann in den Ordner nichts schreiben. Auch nicht im Safe Mode
Du musst zuvor als Admin den Besitz von WinSxS übernehmen und danach noch zusätzlich die Schreibrechte für den Admin hinzufügen. Dann klappt es!
Danke an alle Beteiligten hier – auch bei uns hat es nun mit der Kopie von amd64_microsoft-windows-w..form-pluginpolicies_31bf3856ad364e35_10.0.17763.1_none_fe2052c317c5f161 nach WinSxS und der Änderung in der Registry geklappt!
[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.437"=hex:01
@="10.0.17763.1"
In der letzten Zeile (Default) stand zuerst @="10.0.17763.437" – was ja auch zum vorhandenen Verzeichnis gepasst hätte, aber das Update läuft eben nur durch, wenn hier @="10.0.17763.1" steht und das Verzeichnis auch wirklich da ist.
Nach dieser Änderung hat es bei uns auf 5 Citrix Masterimages sofort, ohne weitere Änderung wieder funktioniert!