[English]Der Installationsfehler 0x800f0982 bei der Installation des Mai 2024-Patchday Update KB5037765 unter nicht englischsprachigen Windows Server 2019-Instanzen hat ja einige Administratoren beschäftigt. Während ich die Lösung – englisches Sprachpaket installieren – hier im Blog frühzeitig kommuniziert habe, hat Microsoft nun ebenfalls reagiert. Es gibt einen Support-Beitrag, in dem der Fehler bestätigt wird. Ergänzung: Es gibt ein revidiertes Update-Paket, welches aber einen weiteren Bug hat.
Anzeige
Update KB5037765 für Windows Server 2019
Das kumulative Update KB5037765 steht für Windows Server 2019 (sowie Windows 10 2019 Enterprise LTSC und IoT Enterprise LTSC ) bereit. Mit dem Update will Microsoft eine Reihe an Fehlerkorrekturen vornehmen. So werden die unter Windows 10/11/Server: VPN-Verbindungen nach April 2024-Updates kaputt und Windows Server: April 2024-Updates stören NTLM-Authentifizierung beschriebenen Probleme behoben.
Allerdings waren viele Administratoren von deutschen, italienischen, französischen, spanischen und weiteren nicht englischsprachigen Installationen nicht in der Lage, das Update zu installieren. Das Windows Server 2019 Update KB5037765 scheitert mit dem Installationsfehler 0x800f0982. Ich hatte die im Blog-Beitrag Windows Server 2019: Update KB5037765 scheitert mit Error 0x800f0982 aufgegriffen und auch eine Workaround (englisches Sprachpaket installieren) gepostet.
Microsoft bestätigt Installationsproblem
Blog-Leser haben bereits in Kommentaren darauf hingewiesen, dass Microsoft nun den Installationsfehler bestätigt habe (danke). Im Supportbeitrag The May 2024 security update might fail to install des Windows Health Status-Bereichs Known Issues findet sich die betreffende Information. Dort heißt es, dass bei Windows Server 2019-Maschinen, die versuchen, das Sicherheitsupdate vom 14. Mai 2024 (KB5037765) zu installieren, während des Installationsvorgangs Probleme auftreten können. Die Installation kann mit einem Fehlercode 0x800f0982 fehlschlagen.
Von diesem Problem sind eher Geräte betroffen, die keine Unterstützung für das en_us-Sprachpaket haben. Die Microsoft-Entwickler arbeiten an einer Lösung und werden ein Update bereitstellen, sobald weitere Informationen verfügbar sind. Wie bereits oben erwähnt: Wer das Sicherheitsupdates sofort installieren muss (es werden ja einige Schwachstellen beseitigt), sollte den von mir geposteten Workaround (englisches Sprachpaket nachinstallieren) versuchen.
Anzeige
Revisions-Update mit weiterem Bug?
Ergänzung: Blog-Leser haben in Kommentaren darauf hingewiesen, dass Microsoft ein revidiertes Update-Paket im WSUS bereitgestellt habe. Das Paket hat aber vermutlich einen Detection Bug, siehe Windows Server 2019: Revidiertes Update KB5037765 mit WSUS-Detection-Bug?
Ähnliche Artikel:
Office Updates vom 7. Mai 2024
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)
Microsoft Office Updates (14. Mai 2024)
Windows Server 2019: Update KB5037765 scheitert mit Error 0x800f0982
Windows Server 2019: Revidiertes Update KB5037765 mit WSUS-Detection-Bug?
Anzeige
Sollte man das Unternehmen das denen die ISO9001 Zertifiziert hat mal auf die Füße treten und fragen was die denn am QS Prozesss auditiert und bestätigt haben? :D
Die QS ist schon sehr schlecht geworden, wobei das wohl beabsichtigt ist, damit alle nur noch deren Cloud-Produkte nutzen, alles andere ergibt keinen Sinn.
Wieso? ISO9001 zertifiziert, dass Managementprozesse installiert sind, um die Unternehmensziele zu erreichen…
Insofern passt das damit wohl schon und du hast ja bereits angedeutet was man daraus ableiten kann wie vermutlich die aktuellen Unternehmensziele aussehen.😉
Ein (immer noch) weit verbreitetes Missverständnis. Bei ISO 9001 geht es nicht (direkt) um Qualitätssicherung, sondern darum, (a) in bestimmten Bereichen Prozesse definiert zu haben, und (b) nachweisen zu können, dass auch nach diesen Prozessen gearbeitet wird.
Wenn also ein — natürlich fiktives — Unternehmen sagt, unser Ziel ist es, unseren Kunden jeden Monat wieder enormen Aufwand durch fehlerhafte Updates zu generieren, die Prozesse entsprechend beschreibt und den Nachweis erbringt, dass sie gelebt werden (was im Falle dieses fiktiven Unternehmens nicht schwierig sein dürfte), dann bekommt es den ISO-Stempel.
Unabhängig von diesem fiktiven Unternehmen, und ohne Ironie: Der Sinn von ISO 9001 ist es, dass man sich, wenn man einem Unternehmen einen Auftrag erteilen möchte, sich dessen ISO 9001-Dokumentation aushändigen lassen und anhand dieser Dokumentation überprüfen kann, ob das Unternehmen voraussichtlich die Qualität zu liefern imstande sein wird, die man benötigt und erwartet.
Papier ist geduldig. Die Realität schaut meist anders aus.
Klar. Und ich bin da auch kein grosser Fan von.
Aber ganz dumm ist es nicht. So fängst Du immerhin nicht bei Null an, sondern hast einen Einstiegspunkt, anhand dessen Du tiefergehen kannst und Dir alles Dir Wichtige detaillieren oder konkret zeigen lassen kannst, ehe Du entscheidest, ob die Bude wirklich in der Lage sein wird, Deinen 100-Millionen-Auftrag wie gewünscht abzuwickeln.
ja ich weis, "Beschreib deine Prozesse, egal wie schlecht diese sind und erhebe Kennzahlen zur Messung der Prozessqualität".
Betrifft ab jede Norm, die 50001, 14001 27001 – alles stille Papiertiger, außer der Aufwand der vor Audits aufkommt, sieht und hört man nahezu nichts davon.
Aber: man kann damit wunderbar anderen Kollegen "auf die E*er gehen" :), frei nach dem Motto "Danke für das Dokument, aber wo ist die Revisions-Nummer und die Dookumenten ID und außerdem fehlt hier noch die Vertraulichkeits-Klassifizierung, dass kann ich so auf keinen Fall bearbeiten" :-).
es ist schon interessant wie nicht-deterministisch software heutzutage scheinbar ist.
sollte versuchen….sprachpaket zu installieren…..
update kann fehlschlagen…..
was ich mich frage wie uneindeutig microsoft kommuniziert. es schaegt doch bei allen non-en_US fehl…..
und sprachpaket installieren (eigene erfahrung) bringt scheinbar bei sonst gleichartigen servern, server 2019, deu x64, jedoch bei einem den winupdate erfolg beim anderen server schlaegt das update immernoch fehl trotz sprachpakets auf gleiche art erfolgreich installiert.
nichtdeterministische muellsoftware QED =D
Man sollte den Cannabis-Konsum im US-Bundesstaat Washington schnellstens wieder verbieten.
https://de.wikipedia.org/wiki/Rechtliche_Stellung_des_Cannabisgebrauchs_in_den_USA
Guten Morgen,
Hier ein Skript, was die Installation des Sprachpakets und Updates weitestgehend automatisiert, falls man nicht auf einen Fix warten möchte (Es sind gravierende Sicherheitslücken dabei…):
https://github.com/t-klemenc/Install-KB5037765/tree/main
danke – versuche ich mal auf einem Test-Server
Microsoft bestätigt das so locker nach mehr als einem Tag. Und vermutlich basteln die noch paar Tage…
Aber gibt es da nich CVE-2024–30051 wegen der man schnell handeln sollte?
Bei MS hat doch Sicherheit – mal wieder – oberste Priorität. Dachte ich.
Quelle u.a. https://www.golem.de/news/malware-im-anmarsch-schwachstelle-in-windows-wird-aktiv-ausgenutzt-2405-185134.amp.html
Schon gesehen? https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30051
Attack Vector -> LOCAL
Solange da keine User auf Deinem Server (z.B. per RDP) sind, wieso der Stress?
Selbst wenn da lokale User drauf sind, solange die dort mit Programmen arbeiten und nicht Mails mit Outlook abholen und dann wild clicken, bzw. irgendwelche ominösen Websites ansurfen, wo siehst Du dann das Problem mit diesem CVE ?
> Selbst wenn da lokale User drauf sind, solange die dort mit Programmen arbeiten und nicht Mails mit Outlook abholen und dann wild clicken, bzw. irgendwelche ominösen Websites ansurfen, wo siehst Du dann das Problem mit diesem CVE ? <
Sie haben die Angriffspfade und Rechteausweitungsverläufe vergangener Ransomwareattacken nicht wirklich verstanden. Bitte jetzt kein 'Mach mich schlauer'; ich bin nicht die Cyber-Nanny. Nur EINE Anregung: Machen Sie sich einmal über Angreifer aus den eigenen Reihen Gedanken.
Hab das Problem auch, allerdings tatsächlich nur auf einem einzigen Server, der vor langer Zeit auf Deutsch installiert wurde.
hab nun mal manuell das Sprachpaket EN-US draufgepackt, hoffe das Update läuft nun durch, und meine User können auch wieder via RDP drauf.
Aus dem Grund installiere ich Server grundsätzlich nur mit der englischen Version.
Der Fehler betrifft auch Windows Server 2016 (2024-05 KB5037763) mit dem Fehler 0x800f0816
Bei uns sind Server2016 fehlerfrei installiert worden.
Der Status des Pakets KB5037763 wurde erfolgreich in "Installiert" geändert.
Absolut beruhigend, dass man es im Hause Microsoft immerhin noch schafft einen absolut vermeidbaren, bereits mehrfach verursachten Fehler innerhalb von 1,5 Tagen zu "bestätigen"
Woher die Häme? Grund der 'Verspätung' sind u. a. Administratoren wie aus dem hiesigen Forum. Den ganzen Tag rummaulen, aber keiner hat ein Ticket eröffnet! Und dann die Qualität der Fehler- und Symptombeschreibungen, unter aller S..! Windows Update Logs (1) anschalten, analysieren und Auszüge bereitstellen? Wir doch nicht, haben wir nicht nötig.
Ich will mir nicht vorstellen, wie sich der Microsoft Support den lieben langen Tag das Ohr abkauen lassen muss, von wirren Administratoren, die nicht stringent und vollständig vortragen können und ihre Systeme über die entlegensten Pfade in die Unwartbarkeit manövriert haben.
(1) learn.microsoft.com/en-us/windows/deployment/update/windows-update-logs
Also ich kann keine wirkliche Häme im Vorpost erkennen – der Mann hat doch Recht. Diese Bugs wiederholen sich immer wieder. Wenn wirklich mal ein Admin unter den Kommentatoren ist, der im Eifer des Gefechts das nicht sauber auf die Reihe bringt, so what?
Und mal kurz festgehalten: Ich erlebe immer wieder (z.B. in direkten Mails mit Problembeschreibungen aus der Leserschaft), dass im Admin-Bereich die Leute einen sehr guten Job machen und mit dem MS-Support versuchen, Bugs zu verfolgen.
Häufiger ist es so, dass die Fehlerbeschreibungen und Ursachenanalysen aus der Administratorschaft über meinen englischen Blog an die Microsoft-Entwickler herangetragen werden. Das größere Problem für mich ist oft, da irgend einen bei MS hinter dem Ofen hervor zu locken – die ziehen sich gerne mal auf "Formalien" und ihren Hub zurück. Das Problem sitzt meiner Beobachtung nach in den meisten Fällen eindeutig in Redmond.
Von daher "frisch von der Leber": In diesem Kontext wirken Deine Anwürfe in Bezug "wie sich der Microsoft Support den lieben langen Tag das Ohr abkauen lassen muss, von wirren Administratoren, die nicht stringent und vollständig vortragen können und ihre Systeme über die entlegensten Pfade in die Unwartbarkeit manövriert haben" für mein Gefühl irgendwie deplatziert.
+1
Was für ein UpdateFiasko, wieder einmal….
Wobei – schlimmer gehts immer, so gesehen, hat MS ja oft genug bewiesen – aber ich hab die Nerven schlicht nicht mehr, jedes Mal Bauchweh zu haben wenn Patchday angesagt ist.
Und wir in der IT sollen weniger Zeit investieren…
pfffffff….
Hat jemand Erfahrung mit Windows Server 2016 diesbezüglich und kann berichten?
Sowohl Server 2022 als auch 2016 sind von dem Fehler nicht betroffen.
Server 2016 sind bei uns ebenfalls betroffen.
Gerade den ersten (deutschen) 2019er gepatched, erfolgreich.
Erst das LP EN-US installieren und dann das Update, habe beides manuell installiert (lpksetup und dann Sprache gewechselt, dann KB5037034 installiert)
Und? RDP geht noch..?
Aber ja!
Ich musste die Sprache nicht wechseln. Das LP musste nur installiert sein, damit das Update klappt
jap, via normaler Auth und via SmartCard auch keine Probleme
Zur Info:
Ich habe heute festgestellt, dass die Installation des Language Pack
über DISM (Dauer ca. 5 Minuten) deutlich performanter ist als die Installation über lpksetup.exe.
Kurze Anleitung:
Die Datei Microsoft-Windows-Server-Language-Pack_x64_en-us.cab auf einem Netzlaufwerk (Share) kopieren.
Syntax (CMD) für die Installation auf dem Server:
dism.exe /online /add-package packagepath:"\\UNC_PFAD_Netzlaufwerk\Microsoft-Windows-Server-Language-Pack_x64_en-us.cab"
In der Befehlszeile fehlt ein "/" vor packagepath:
Richtig: dism.exe /online /add-package /packagepath:"\\UNC_PFAD_Netzlaufwerk\Microsoft-Windows-Server-Language-Pack_x64_en-us.cab"
Danke!
Der fehlende slash schwimmt gerade in meiner Kaffeetasse,
ist da wohl gestern versehentlich hineingefallen…
Auch zur Info:
Ich habe festgestellt, dass MS wahrscheinlich das englische Sprachpaket (en-us) jetzt proaktiv auf den betroffenen Maschinen installiert.
lpksetup meldete jedenfalls bisher auf vier von mir betreuten PCs, dass das Paket bereits installiert wäre – ohne, dass ich es installiert hätte.
Ich könnte mich natürlich irren, deshalb wären Erfahrungen anderer Admins wahrscheinlich hilfreich. :-)
Heute Nacht hat der WSUS eine neue Revision des Server 2019 Patches (KB5037765) bekommen.
Aus unserem WSUS wurde um 04.00 Uhr MEZ ein Updates gesynct: KB5037765, taucht in der Sync Tabelle als "überarbeitetes Update" auf. Ggf. hat MS nachgefasst. Kann jemand bestätigen?
Ja bei uns auch, dank deiner Info gerade mal einen Sync auf dem WSUS angestoßen und haben es auch erhalten als "Revised Update"…
Gleich mal austesten!
https://support.microsoft.com/de-de/topic/14-mai-2024-kb5037765-betriebssystembuild-17763-5820-82d1aefb-093c-4e4a-a729-cd4a829750ad –
hier steht:
Bekannte Probleme bei diesem Update
Microsoft sind zurzeit keine Probleme mit diesem Update bekannt.
Wir werdens auf jeden Fall noch nicht installieren … keine Lust auf script-gefrickel
Das Problem ist doch schon längst von MS erkannt worden:
https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-1809-and-windows-server-2019#3299msgdesc
ja habe wir auch bekommen aber ACHTUNG! dieses neue Patch scheint einen Detection Bug zu haben!
Diverse ungepatchte (also Stand April 2024) Server 2019 (nur englisch!) werden als "not needed" erkannt!
@Günter, könntest du ggf. drauf im Text hinweisen, bitte.
Hier auch… neue Version vom WSUS wird nicht mehr vom 2019 Server als erforderlich angezeigt und daher auch nicht zur Installation angeboten… "usoclient startscan" findet auch nichts neues
Ist am Artikelende nachgetragen – danke.
Bestätigt.
Wobei es wahrscheinlich kein Bug ist, sondern die schnellste Möglichkeit seitens Microsoft das Update in WSUS Umgebungen nicht weiter verteilen zu lassen.
in diesem Fall hätte MS das update aber eigentlich "declined"
Der Status bei MS ist immer noch "confirmed" und nicht "resolved".
Mehr kann ich da aber auch nicht zu sagen.
Wir hatten die "alte Version" auf einem deutschen Testserver (ohne jegliche, Rollen, Features oder Drittsoftware) installiert: kein Installationsproblem.
Mir ist jetzt aber auch nicht klar, ob ich dann die alte Version manuell deinstallieren müsste um dann die neue Version über WSUS wieder draufzuinstallieren. Lt. Windows Update gibt es auf dem Server nicht s zu tun, denn das Update mit der KB-Nummer 5037765 ist ja bereits genehmigt.
Wir werden wohl in Zukunft auch eher englische Serverversionen als Basis verwenden, häuft sich in letzter Zeit bei Microsoft, siehe den Exchange SecUpdate Bug aus dem letzten Jahr.
Gerdae den WSUS synchronisiert, das alte 2019er Update ist weg, kein neues da…
Ergänzung:
auf den 2019er VMs, wo nur das language pack installiert wurde, taucht das CU vom April wieder im WSUS als notwendig auf…
Ich bin ja ein geduldiger Mensch, aber so langsam nervt es…
Die Updates werden anscheinend von der M$ KI zusammengestrickt, wobei KI = künstliche Inkompetenz bedeutet
Kann es sein das MS das Update zurückgezogen hat?
Über Windows Update Online wird das Update nicht mehr angezeigt.
Siehe Ergänzungen am Artikelende.
Im MS Update Katalog hat sich auch das Datum von 14.05. auf den 16.05. geändert:
https://catalog.update.microsoft.com/Search.aspx?q=KB5037765
Masl sehen, ob jetzt alles funktioniert.
Auch mit dem neu vom Update Katalog heruntergeladenen KB5037765 bekomme ich den Fehler 0x800f0982. Was machen die da bei MS? Hat mal noch jemand probiert?
kann ich gerade bestätigen. Lustigerweise ging es auf einem Server, bei dem anderen wiederum nicht
Same here!
Soweit ich das erkennen kann, hat sich das Updatepaket nicht geändert, lediglich der Metadatensatz, aus dem sich z.B. die Anwendbarkeit ergibt.
Bei mir das Gleiche- funktioniert auch nicht.
Mit Certutil melden beide Dateien aus dem Katalog den gleichen Hash Wert. Wahrscheinlich also keine geänderte Datei.
bei meinen 2019er Servern (1809) wie auch bei zahlreichen Kundenservern (1809) wird das Update heute nicht mehr angezeigt – also wurde es mit hoher Wahrscheinlichkeit zurückgezogen