Windows Server 2019: Update KB5037765 scheitert mit Error 0x800f0982

Windows[English]Bei den zum 14. Mai 2024 (zweiter Dienstag im Monat, Patchday bei Microsoft) verteilten kumulativen Updates hat Microsoft wohl einen kolossalen Bug geschossen. Das für Windows Server 2019 vorgesehene Update KB5037765 scheitert mit dem Installationsfehler 0x800f0982. Es haben sich bereits mehr als ein halbes Dutzend Leser mit dem Problem gemeldet – es betrifft wohl nicht englische Installationen. Ergänzung: Ein weiterer Leser hat sich gemeldet, er kommt mit RDP nicht mehr auf seine Server 2019 – ist aber wohl ein "Zeitproblem". Ergänzung 2: Für den Installationsfehler 0x800f0982 gibt es einen Workaround.


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.

Windows Server 2019: Update-Fehler 0x800f0982

Bereits kurz nach Freigabe dieses Sicherheitsupdates hat sich Blog-Leser Nils S. sich per E-Mail gemeldet und schrieb, dass bei den Windows Updates für Windows Server 2019 und Windows Server 2016 schon die ersten Fehler auftreten. Das kumulative Update KB5037765 für Windows Server 2019 (1809) scheitert mit dem Installationsfehler 0x800f0982. Im Event-Log findet sich der Eintrag:

Der Status des Pakets KB5037765 konnte nicht in "Installiert" geändert werden. Status: 0x800f0982.

Die Erkennung und Reparatur von Systemspeicherfehlern wird initiiert. Nur Erkennung: 0, automatisch ausgelöst: 1.

Update KB5036896 scheitert mit Error 0x800f0982

Das ist kein Einzelfehler, auch Blog-Leser Dieter K. schrieb, dass er bei Update KB5037765 den Installationsfehler 0x800f0982 gemeldet bekomme (er hat das Ganze in obigem Screenshot dokumentiert, danke dafür). Er konnte diesen Installationsfehler bei sieben Windows Server 2019-Systemen, die bei sieben verschiedenen Kunden stehen, beobachten. Hier der Fehler im Ablauf:

  • Update KB5038283 bleibt bei 0% hängen
  • dann warten und Reboot nach 1,5 Stunden
  • Server bleibt bei "Windows wird vorbereitet …." stehen
  • ausschaltet; danach fährt der Server wieder hoch

Eine Reihe weiterer Blog-Leser hat sich mit der gleichen Beobachtung in Kommentaren – leider unter einem anderen Artikel – gemeldet.

Dominik schrieb in einem Kommentar, den ich mal hierhin herausziehe:

Auf Windows Server 2019 scheitert die Installation der Updates mit Fehlercode: 0x800f0982

Auf 2x VM's und einem Hyper V.

Völlig unabhängig voneinander… super Microsoft!!!

Robert bestätigt diesen Fehler für zwei Windows Server 2019, die als Domain Controller (DCs) betrieben werden und als VMs laufen. Manuel schreibt in einem weiteren Kommentar:

Bei uns auf 5 unterschiedlichen Systemen ebenso (W2019 / Deutsch, KB5037765 -> 0x800f0982), egal ob Member oder DC. Scheint wieder ein Lokalisierungsproblem bzw. fehlerhaftes Update zu sein. Das heißt wohl wieder warten auf einen Fix…

Fritz hat dann in einem Kommentartext folgende Frage gepostet, die ich ebenfalls hier in den Artikel ziehe, da ich die artikelfremden Kommentare im Nachgang lösche.

Ein bis dato fehlerfrei funktionierender WSUS (2019) hing vorhin beim Synchronisieren dauerhaft bei 0%, im SoftwareDistribution-Logfile des WSUS war von DOT-NET-Fehlermeldungen des ReportingWebService im IIS die Rede.

Ich habe dann einfach einen Snapshot von gestern wiederhergestellt – damit gelang die Synchronisation. Einzig bewusst gemachte Änderung seit gestern war nach dem Artikel "WSUS: MSSQL-Treiberupdates jetzt verfügbar" die Aufnahme eben jener Kategorien und des seit kurzem verfügbaren "Windows Server OS 2024" in die Synchronisationsliste.

Hat jemand ähnliche Erfahrungen gemacht?

Die Fehlerbeschreibung gleicht der obigen Beschreibung von Dieter K. Inzwischen kristallisiert sich heraus (Manuel hat in einem Kommentar auf den Sachverhalt hingewiesen, danke dafür), dass der Installationsfehler 0x800f0982 wohl nur bei nicht englischen Windows Server 2019-Installationen auftritt. Unter dem Strich bleibt Administratoren nur, das Update auszublenden und dann auf einen Fix durch Microsoft zu warten. Auf reddit.com gibt es ebenfalls eine Diskussion.


Anzeige

Fehlendes Sprachpaket Englisch?

Ergänzung: Inzwischen könnte es mit einem Leserkommentar gefangen worden sein: Ist auf Windows Server 2019 ein englisches Sprachpaket installiert, läuft es. Ist nur ein deutsches Sprachpaket vorhanden, bringt die Update-Installation den Installationsfehler 0x800f0982. Kann das jemand bestätigen?

Ergänzung 2: Inzwischen wurde der Workaround durch mehrere Leser bestätigt. Oliver schrieb mir dazu noch, dass man die Sprache "English (Unites States)" mit Status "Sprachpaket installiert" zusätzlich zum deutschen Sprachpaket installiert haben muss  Das Sprachpaket muss nicht aktiv sein, aber er hatte den Fall, dass bei einem seiner Windows Server 2019 "Sprachpaket verfügbar" stand. Das reicht nicht, um das Update fehlerfrei installieren zu lassen (was auch irgendwie klar ist, denn dann ist das Language Pack nicht installiert). Die Links zum betreffenden Sprachpakete finden sich weiter unten in diesem Kommentar.

RDP-Zugriff auf Server 2019 kaputt

Ergänzung: Blog-Leser Reinhold S. hat sich bei mir per E-Mail gemeldet, weil er in massive Probleme gelaufen ist. Hier seine Erfahrung:

Hallo Herr Born,

ich habe heute unseren Server mit dem Patchday updates versehen. D.h 4 Hyper-V VMs und den Rootserver, alles Win 2019

Nun kann ich mich nicht mehr per RDP in den Root Server einloggen, per VPN (Sophos UTM).

Diesen Fehler, so schrieb Reinhold, hatte er noch nie in den letzten Jahrzehnten und meint "Vielleicht warnen Sie Ihre Leserschaft vor dem Kumulativen Mai-Update für Server 2019." Er muss jetzt zum Hoster (glücklicherweise vor Ort) fahren und schauen, wie er das behebt. Der meint, dass er Backups auf dem NAS habe (Macrium) – sogar jeweils Full Backups die er vor dem Patchday immer erstellen lässt.

Ergänzung 3: Der Leser hat sich in einer weiteren Mail gemeldet – der Installationsprozess scheint extrem lange zu laufen. Nach mehreren Stunden warten und einem Server-Reboot funktioniert auch RDP.

Ä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 Update endet mit Fehler 0x800f0982 / 0x8024200d


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Störung, Update, Windows Server abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

118 Antworten zu Windows Server 2019: Update KB5037765 scheitert mit Error 0x800f0982

  1. Anonymous sagt:

    Das Problem ist hier auch vorhanden, es wird allerdings gar nicht installiert. Deutsches Image.

    • Anonymous sagt:

      Kann ich so bestätigen. Mehrere 2019er Installation aus detschen Image.
      Update wird nicht installiert mit 0x800f0982…

    • SP sagt:

      Ich schließe mich diesen Aussagen an.
      Die Lösung für mich:
      Ich habe auf einem Domain Member Server 2019LTS das UpdatePaktet installiert bekommen
      nachdem das english US sprach Paket installiert war wurde das Update installiert.

      Ablauf:
      – Snapshot
      – Updates aussetzten

      – Sprachen hinzufügen –> englisch US (United States)
      anschließend das Paket anklicken und über Optionen sehen das er es auch downloadet und Installiert.
      Wichtig ist das es unter "Optionen" als "Installiert" angezeigt wir –> neu starten
      – Nach dem Neustart die Updates fortsetzen und installieren.

      – Neustarten fertig.
      Das Update war in annehmbarer Zeit installiert (10Min)

      Es hat hier funktioniert auch wenn ich es nicht bei allen Servern gemacht habe.
      Ich warte noch ein paar Tage auf einen FIX sonst versuche ich es auch bei den heiklen Maschinen auf diese weise.

      Viel Glück

  2. der bug ist das ziel sagt:

    win10 und server 2019 (bisher) sehr durchwachsen und wenn dann vollkatastrophe :(

    https://www.borncity.com/blog/2024/05/15/patchday-windows-10-server-updates-14-mai-2024/#comment-181437

    • Robert Glöckner sagt:

      mehrere Win10 22H2 und Win11 23H2 bisher keine Probleme. Server 2022 installiert gerade… und ist auch fehlerfrei durch
      das kumulative für den 2019er habe ich noch nirgends freigegeben – warten wir ab

  3. der bug ist das ziel sagt:

    komischerweise habe ich aber drei deutsche! windows server 2019 installationen einen physical und darinnen zwei virtualisierte (hyper-v) alles deutsch win 2019 x64. die keine probleme gemacht haben.

    weitere standalone physische server zicken jedoch rum :(

    wie kann das dann ein localisation problem sein? wenns doch? sporadisch? durchgeht? wzt?!

    • Fritz sagt:

      Ich habe noch kein klares Bild.
      Es scheint aber von der Vorgeschichte abhängig zu sein. Wenn der Server ursprünglich auf Englisch installiert war (will bei HPE das Intelligent Provisioning so) und dann das deutsche Languagepack (MUI) nachinstalliert wurde geht es, bei VM-Gästen, die direkt von einer deutschen ISO installiert wurden nicht.

      Microsofts Supportseite übrigens mal wieder typisch:
      KB5037765 Englisch: Microsoft is not currently aware of any issues with this update.
      KB5037765 Deutsch: Welches Update? Ich nix haben KB5037765! 😣

  4. Dirk sagt:

    Von 27 x Windows Server 2019 DE: 6 Mal problemlos installiert, Rest Installationsfehler. Auch das Herunterladen des Updates aus dem Microsoft Update Catalog und manuelle Installation schlägt fehl.

    Meldung beim Neustart einer fehlgeschlagen Installation: Der Dienst wird beendet: "Windows Modules Installer". Hard shutdown der VM und Neustart behebt das Problem.

    • MaGGs sagt:

      Nach dem "Hard Reset" / Kaltstart meldet sich der Windows Modules Installer nach dem Neustart als nicht gestartet. Manuell starten, Aktualisierung der Ansicht, Dienst ist wieder aus.
      Schaut man bei den Updates, stehen dort das "böse" CU Update 05-2024 als Fehler und das .NET Update als abgebrochen. Das System möchte einen Neustart… dann mal los – direkt über den vorgesehenen Button ^^
      Reboot läuft normal durch, kein ewiges "Updates werden installiert, schalten Sie den Computer nicht aus".
      [..]
      System ist wieder komplett UP. Und auch der Windows Modules Installer scheint sich gefangen zu haben.
      Also ich für meinen Teil werde hier nicht den Job von Microsofts Jüngern machen und mit dem De- und Re-Installieren von Sprachpaketen anfangen, um das Update auf die Büchsen zu klöppeln.
      Das sollte doch wohl nicht ewig dauern, bis es einen Patch für den Patch gibt ;0)

      Nachtrag: "Böse Updates" im WSUS ablehnen und auf den Clients (Server 2019) in der Kommandozeile "usoclient StartScan" ausführen. Siehe da, "Sie sind auf dem neuesten Stand" ^^

      Aber hinterher bloß nicht auf "Suchen Sie online nach Updates von Microsoft Updates" klicken!

  5. Paul Horn sagt:

    Hier das gleiche Problem bei einem physischen Server 2019 und zwei virtuellen Servern 2019. Der physische Server ließ keine RDP Verbindung mehr zu, d.h. nach der Anmeldung kam nach 1 sek. wieder die Anmeldemaske.
    Wir sitzen in Düsseldorf, die Server in Süd-Bayern.
    Von einem im gleichen Netzwerk befindlichen Server 2016 (noch keine Updates erhalten) den physischen Server 2019 per shutdown.exe /m \\10.xxx.xxx.xxx /f /r /t 5
    neu gestartet. Nach ca. 50 Min. (!sic) funktionierte dann auch wieder rdp.
    Microsoft ist mittlerweise ein Saftladen. Anders kann man es nicht bezeichnen.

  6. Darko sagt:

    Bei mir scheiterte die Installation auch. Seit einer halben Stunde dreht er nun die Uhr "Windows wird vorbereitet, schalten Sie den Comptuter nicht aus."
    Habe den Beitrag zum Glück vorher gelesen und das Update erstmal auf einer VM installiert. Komme jetzt nur noch über das Host Betriebssystem ran. RDP ist tot. Am besten überspringen. WinSrv2019.

  7. Tymoteusz Partyka sagt:

    Auch bei mir ist dieses Problem aufgetreten. Alle meine VMs (WS 2019) haben die Installation des Updates verweigert, nur der Hyper-V Host nicht – da klappte das. Auf der Lösungssuche bin ich auf diesen Artikel gestoßen:

    https://www.windows-faq.de/2020/01/23/fehlercode-0x800f0982-beim-windows-update/

    Der Fehlercode bezieht sich wohl auf ein Problem mit Sprachpaketen. Da auf meinem Hyper-V Server, neben dem deutschen Sprachpaket auch das englische Paket installiert war, habe ich das auf den VMs nachinstalliert. Wenn die Installation des Updates schon versucht wurde, kann ein Neustart notwendig sein, damit der Updatedienst wieder sauber läuft, ansonsten wird das Sprachpaket (oder weitere Updates) nicht installiert.

    Sobald das Sprachpaket für Englisch (Vereinigte Staaten) installiert wurde, konnte auch KB5037765 (ohne weiteren Neustart) problemlos installiert werden, sowohl über sconfig als auch über die normalen Windows-Einstellungen. Die Features "Spracherkennung" und "Handschrift" sind übrigens bei der Installation des Sprachpakets nicht notwendig, ebenso wie die Umstellung der Sprache von Deutsch auf Englisch.

    • MaGGs sagt:

      Aha, also macht man den gleichen Fehler (der Artikel ist aus Januar 2020) auch gern mehrfach? Ich kann das mit dem Saftladen aktuell ohne Probleme bestätigen. Also bei allen Kunden die aktuellen Updates (auch das für .NET, das läuft auch nicht sauber und hängt ewig bis zum Reboot bei 0%) im WSUS abgelehnt…

      btw. ein "alter" Exchange 2016 auf Server 2016 hat alles gemacht, wie's soll. ;)

  8. Stefan A. sagt:

    Ich wollte in paar Stunden auch loslegen.
    Danke für den Hinweis!

    Bezüglich Überschrift: Aber ist das Mai Update 2019 nicht KB5037765 und KB5036896 ist doch noch von April, oder?

  9. Roman sagt:

    Gestern bei einen virtuellen deutschen 2019er Server vor dem lesen hier das Update KB5037765 eingespielt. Lief aber problemlos durch.
    Beim Rest hab ich jetzt mal das Update ausgeblendet.

    Wird da gewürfelt welche Systeme betroffen sind?

    • Günter Born sagt:

      Inzwischen könnte es mit einem Leserkommentar gefangen worden sein: Ist auf Windows Server 2019 ein englisches Sprachpaket installiert, läuft es. Nur deutsches Sprachpaket bringt den Installationsfehler 0x800f0982.

      • Roman sagt:

        In dem Fall nur Deutsch (Deutschland). kein englisches oder überhaupt weiteres Sprachpaket installiert, und trotzdem ohne Probleme durchgelaufen.

  10. Anonymous sagt:

    bzgl WSUS Sync issue. Die MSSQL Treiber sind es nicht, die habe ich schon vor ein paar Wochen hinzugefügt.

  11. Beutel sagt:

    Auch hier ein Server 2019 (DE) als DC mit der Fehlermeldung: Letzter fehlerhafter Installationsversuch: ‎15.‎05.‎2024 – 0x80246007

    – Update angestoßen
    – wird heruntergeladen und installiert, bleibt jedoch bei 0%
    – Neustart des Servers während "Schalten Sie den Computer nicht aus"
    – Server fährt wieder hoch und macht seinen Job

    Für den Nervenkitzel werde ich langsam zu alt. Mal abwarten wann Microsoft nachbessert.

  12. Anonymous sagt:

    Hab ich schon in meiner Jugend (mit Server 2000) gelernt, nie ein nicht-englisches Server OS installieren!

  13. Anonym sagt:

    Dasselbe Problem bei uns. Bei virtualisierten Windows 2019-Servern (Deutsch) bricht die Installation ab, bei einem physikalischen System (auch Deutsch) komme ich per RDP nicht mehr dran. Ich lass das erstmal sein mit Patchday heute.

  14. Anonymous sagt:

    Das Update für Windows Server 2019 KB7037765 lässt sich auch nicht installieren mit Fehler "CbsPackageServicingFailure2". Server ist physikalisch, deutsches OS. Direkt zurückgezogen und nicht weiter ausprobiert. Sehr schön.

  15. Daniel.A sagt:

    Da hat sich MS ja mal wieder sehr mit Ruhm bekleckert. Und ich dachte, das März Update vom Exchange wäre schlecht gewesen, aber das geht ja sogar noch schlimmer. Hatten wir sowas nicht vor einiger Zeit schon mal, also Patche, die nur auf englischen Systemen installiert werden konnten? Irgendwie habe ich ein Deja-Vu.
    Da werde ich mit dem Patchen wohl noch etwas warten, in der Hoffnung, dass das zeitnah von MS gefixt wird.

  16. Reinhold sagt:

    Heute früh funktionierte der RDP Zugriff wieder.
    Die 4 VMs mit Windows 2019 laufen auch.

    d.h. der Bootprozess nach dem defektem Update dauert extrem lange.

    Updates werde ich nun nicht installieren sondern länger abwarten was MS dazu schreibt und macht. Der KB5037765 muss dringend überbeitet werden.

  17. Kingcopy sagt:

    Hallo, Bei mir auch:
    Der Status des Pakets KB5037765 konnte nicht in "Installiert" geändert werden. Status: 0x800f0982.
    Die 2019 er RDP haben ca. 2 Stunden nicht reagiert, nach einem Restart jedoch wieder.
    Der RDP Block ist doch nicht dauerhaft. Ich restarte nun Testweise einige weniger wichtige 2019 er Backup Systeme mehrfach durch…
    Bei den wichtigen habe ich die Updatepause aktivert.

  18. der bug ist das ziel sagt:

    es muss noch mehr malad sein im monat mai des jahres 2024 mit den windowsupdates denn das alles ist elendig lahmarschig und failed downloads auch bein client rechnern (win10) egal welcher sprachbasis und egal mit welchen sprachpaketen so habe ich festgestellt.

    auch dass dotnetframework oft garnicht gelistet wird und erst im dritten reboot dann auftaucht und installiert wird und das auch wieder elend langsam alles

    was hat da microsoft diesen monat an ihrem stack, an ihren update CDNs oder wo auch immer verhurt? ist doch unglaublich eigentlich

  19. Dominik sagt:

    Tritt das Problem mit dem RDP-Server auch auf einem 2016er auf oder "nur" einem 2019er? Weil dann lasse ich die Installation direkt bleiben….

  20. Gregor sagt:

    Dürfte sich dann bei Clients mit LTSC (W10 Enterprise) u. dt. Sprachpaket auch so verhalten oder? Hat jemand diesbzgl. schon Systeme mit KB5037765 aktualisiert bzw. dies versucht?

  21. Michael sagt:

    sehr wahrscheinlich wieder eine Abfrage die auf lokalisierten Systemen fehlschlägt,
    auf englischen aber valide funktioniert.
    So wie bei dem Exchange-Update vor Monaten.

  22. Anonym sagt:

    Hallo ihr Helden,

    schon mal auf die Idee gekommen einschlägige Logs zu konsultieren? Als Einstieg: learn.microsoft.com/en-us/windows/deployment/update/windows-update-logs

    Ich meine, ihr arbeitet für Unternehmen! Da sollte schon mehr Sachverstand sein, als Me Too und Hier auch.

    • Michael sagt:

      Sind Sie zum Provozieren hier ? Die Lösung muss von Microsoft kommen, nicht von Administratoren! Dafür wird man nicht bezahlt.

      Danke.

      • Anonym sagt:

        > Dafür wird man nicht bezahlt. <

        Das können Sie der Personalabteilung erzählen. Bei uns hätten Sie jetzt eine Abmahnung in der Akte. Merke: Genau dafür werden Sie bezahlt. Schönwetteradministration kann jeder.

        Unveränderter Stand auf (1): "Microsoft is not currently aware of any issues with this update.". Was zweierkei bedeutet: a) Es gibt keine in der Verantwortung von Microsoft liegenden Probleme; b) deutsche Adminstratoren waren entweder zu lahm die Probleme an massgeblicher Stelle zu melden ODER die gemeldeten Probleme wurden als hausgemacht identifiziert.

        Für letzteres spricht die Gemengelage in diesem Thread, insb. auch obiges "Gestern bei einen virtuellen deutschen 2019er Server vor dem lesen hier das Update KB5037765 eingespielt. Lief aber problemlos durch."

        Meine Prognose: Es wird keinen 'korrigierten' Patch geben, allenfalls einen der Kategorie 'Gnade vor Recht ergehen lassen', der auch auf 'zerwalteten' Systemen funktioniert.

        Wer nicht kontinuierlich Release Notes liest/beherzigt und seinen Servicing Stack aktuell hält, darf sich nicht wundern, wenn seine Systeme zunehmend der Unwartbarkeit anheimfallen.

        (1) support.microsoft.com/en-US/topic/may-14-2024-kb5037765-os-build-17763-5820-82d1aefb-093c-4e4a-a729-cd4a829750ad

    • Curtis Newton sagt:

      Bei so einem dummen Kommentar bleibt man wohl besser "Anonym".

      Kann ja wohl nicht sein, dass man als Admin jeden Monat die fehlende Qualitätssicherung bei Microsoft mit irgendwelchen Workarounds oder anderen Handgriffen ausbügelt!

      Auch hier alle Server DE 2019 mit oben genannter Fehlermeldung. Auch Installationsversuche aus dem Mikrosoftkatalog schlugen fehl.

      (Meine Versuche gestern Abend ca. 19:30-21:00Uhr)

      • Michael sagt:

        Danke Curtis Newton. 100% Zustimmung :)

      • Niko sagt:

        Danke auch von mir. Wenn ich mir meine Linuxsysteme anschaue, die laufen seit Jahren. Probleme mit Updates in der Form kommen sehr selten vor und wenn dann fixt mein Linuxadmin das schnell. Aber diese Angst alle 4 Wochen davor, dass ein System beim Neustart nicht mehr hochkommt, Updates zig mal nicht installalieren lassen oder insbesondere bei MS SQL Datenbankservern die Angst groß ist, dass Instanzen regelrecht beschädigt werden, all das hat nicht mehr viel mit Sachverstand und Administrationsverantwortung zu tun; hier wird man vom Hersteller verballh0rnt, weil man als Versuchskaninchen herhalten muss und das ist de facto eine Frechheit, weil niemand dafür zur Verfügung stehen muss!

  23. T Sommer sagt:

    Hab den Fehler hier gerade auch (VM).
    Beim suchen nach 0x800f0982 findet google folgenden Hinweis bei Günter:
    https://www.borncity.com/blog/2019/03/12/windows-update-endet-mit-fehler-0x800f0982-0x8024200d/
    Kann es sein das da mal wieder was fehlt MS?

    • Günter Born sagt:

      Meine Ergänzung zum englischen Sprachpaket hast Du berücksichtigt?

      • T Sommer sagt:

        Sorry noch nicht – musste dem Server erst noch den Hals rumdrehen, das er nicht aus den pötten kam und bereinigen.

        Dann habe ich gerade die WSUS Datei abgefangen und gesehen das die CAB defekt ist. Also im WSUS das update abgelehnt, bereinigt und neu genehmigt.
        Neue CAB im WSUS ist Ok, er installiert gerade.

  24. Joachim sagt:

    An sich ja. Aber bei Terminal Servern muss es eben oft Deutsch sein.

    Abgesehen davon muss MS das einfach in den Griff bekommen. Schuld ist hier klar nicht der Kunde.

  25. Ross sagt:

    Englisches Sprachpaket hilft!
    Deutsches Image, Deutsche Sprache = Fehlercode.
    Dann habe ich das Englische Sprachpaket installiert, und sofort lief das Update ohne Probleme durch.

  26. Reiner sagt:

    Hallo

    Ich wolte gerade EN-US auf einem Server nachinstallieren ->

    Download "startet" -> Wir haben Probleme bei der Installation dieser optionalen Funktion. Sie können es soäter nochmal versuchen. Fehlercode: 0x800f0954

    … und nun

  27. Hans Mustermann sagt:

    Was mich ja wundert ist, dass so viele Admins die Windows-Updates anscheinend sofort nach Erscheinen auf alle Maschinen ausrollen. Ich habe im WSUS eine Testgruppe mit einer VM für jedes OS und schaue mir erst einmal in Ruhe an, was da passiert. Auch verfolge ich wie zum Beispiel hier die Erfahrungsberichte anderer Admins. Der produktive Rollout erfolgt frühestens eine Woche nach Erscheinen. Bei mir gibt es auch keine automatischen Reboots bei Servern. Das ist mir zu heiß. Ich musste mit den Jahren auch so manche Schmerzen mit Microsoft erleiden. Da hab ich einfach keine Lust mehr drauf.

    • some guy infront of a monitor sagt:

      In den letzten Sicherheitsworkshops und -schulungen, in denen ich sass, kam man unisono und über die komplette Bandbreite seitens der Dozenten zu dem Schluss, dass man sich früher den Luxus mit Testumgebungen noch leisten konnte, aber heute eher Probleme im Nachgang bereinigen sollte, als das System noch tagelang anfällig zu lassen, weil man den Patch noch nicht fertig analysiert hat.
      Ich finde die Idee, erst alles in ein Testbett zu giessen, auch charmant, aber bei den eher hyperventilierenden Releasenotes zu den Mai-Patches, wäre ich aktuell lieber in der Lage, überhaupt zu installieren.

      • J. sagt:

        Erst gemeinte Frage: Hast du dazu eine schriftliche Quelle zur Hand? Ich halte ein Abwarten von zwei Wochen auch für fahrlässig. Aber da unser IT-Dienstleister sich da anders positioniert, brauche ich etwas Rückenwind für meine Position intern ;)

        • ARC4 sagt:

          was genau willst denn da reinschreiben. Es wird hier eh nicht DIE Lösung geben, sondern der Hauptverantwortliche muss schlussendlich die Abwägung treffen, wann denn nun Updates installiert werden können. Ich mache zB ein fixes Interval und je nach Lage muss ich halt auch Mal Updates zurückstellen, aber die Entscheidung wird dir niemand abnhemen können.

          Meiner Meinung nach ist das individuell je nach Unternehmen zu entscheiden.

        • Curtis Newton sagt:

          Kenne ich auch so.

          Quelle u.a. secIT Vortrag von Oneconsult. Ging da u.a. um Patchen von Exchangeserver. nennt sich "patching by default". Schon ein Tag ohne Patch kann bei "hoch" bis "kritisch" einer zu viel sein.

          Habe ich so aber auch schon von anderen Sicherheitsexperten gehört.

      • 1ST1 sagt:

        Wir haben da auch schon unsere Strategie geändert. Früher hatten wir tatsächlich Testgruppen, die 1 Woche (!) liefen, bis die Updates freigegeben wurden. Ganz früher, als es noch nicht besser ging, wurde das noch über kaskadierte WSUS-Server realisiert, "vorne" die Testgruppe, "hinten" 1 Woche später Freigabe an den Rest. Verdampt lang her. Das kann man sich heute nicht mehr leisten, da draußen herrscht Krieg und jeder wird angeschossen oder erschossen, der auch nur ein Türchen offen hat.

        Aus Erfahrung wissen wir aber inzwischen, dass über 95% der Updateprobleme schon am Mittwoch – auch dank dieses Bloggs und reddid/sysadmin (früher auch heise und golem) – schon bekannt werden. So gibts auch bei uns weiterhin eine Testgruppe mit Test- und Spielservern, die gleich Mittwoch nachts automatisch installieren, und der Rest folgt soweit es automatisch geht, gestaffelt Donnerstag, Freitag und Samstag. Die Staffelung ist so, dass gleichartige/redundate Server (Cluster, Sachen mit Loadbalancer davor, etc.) über diese 3 Tage verteilt werden. Der Rest wird manuell gepatcht, das kann dann je nach Projektlage bis zu 2 Wochen dauern, so dass wir im Idealfall spätestens zum Monatsende fertig sind.

        Stellt sich heraus, das Updates Schwierigkeiten machen, dann wird individuell reagiert. Heute: Sprachpakete nachinstallieren.

        • Tom sagt:

          Wie handhabt ihr das mit den Clients bezüglich "Patching by default"?

          Bei uns aktuell 2 Testphasen je 2 Arbeitstage, d. h. produktiver Rollout am Dienstag nach dem MS-Patchday.

    • Stephan sagt:

      Same hier: Auf der Clientseite (ca. 85x Windows 10) installieren wir in der Nacht von heute auf morgen Updates bei einer Testgruppe, bestehend aus zehn Clients. Nur falls das erfolgreich ist, dann in der darauffolgenden Nacht die restlichen.
      Auf der Serverseite installieren wir Updates jeweils an dem Samstag, der auf den Patchday folgt. Das ist unserer Erfahrung nach ein geeigneter Kompromiss zwischen Sicherheit und Verfügbarkeit. Vielen Dank für nichts an Microsoft, dass das überhaupt ein Spannungsfeld und eine Abwägung ist. :(

    • Valerius sagt:

      So handhabe ich das auch ;)

    • Urs sagt:

      Ähnliche Vorgehensweise, ich warte einfach generell 2 Wochen ab.

    • Curtis Netwon sagt:

      Macht man heute bei Servern die angreifbar sind nicht mehr.
      Nennt sich "Patching by default". Siehe u.a. Vorträge der Sicherheitsexperten von Oneconsult. Aber auch andere.

      Einen Server um zu testen ob das Update sich installieren läßt oder so ein Mist passiert wie jetzt O.K. Aber dann sehr zeitnah installieren.

      Die Ausnutzung von Schwachstellen passiert immer schneller. Thema Reverseengineering.

      Um so wichtiger ist Qualitätsmanagement beim patchanbieter. Bei Microsoft leider unter aller Sau.

  28. Kulm sagt:

    Ich bestätige: die Installation des Sprachpakets en-us hilft. Während der Installation hat man auch Zeit darüber zu sinnieren, warum man erst eine DVD mit 2,6 GB herunterladen muss, ob wohl man nur das eine Sprachpaket mit 40 MB Größe braucht und warum die Installation dieser 40 MB so lange dauert ;-)

  29. der bug ist das ziel sagt:

    sprachpaket ist hier in den kommentaren weiter oben/vorher, in dem reddit post (zitiert) und in der offiziellen ISO von microsoft. ist schon ein wahnsinn. hatten frueher sprachpakete nicht auch mal updates etc? wasfuer iso ist das so ganz genau wo ordnet es sich vom alter, release etc ein etc pp, habs noch nicht gegrabbed und angeschaut.

    cheers und viel erfolg beim frickeln mit microsoft. ihr seid alle unbezahlte angestellte der firma. ich auch ;D

  30. Fabian sagt:

    Update KB5037765 ist bei Server 2019 gescheitert – war ja zu erwarten. Hart neu gestartet und die Kisten (1xHardware 1xVM) starten wieder.

    Die Freude war bei uns nur kurz. Die VM ist der Monitoring Server, heißt jede menge ICMP – Ping aufgaben -> Pings scheitern in unregelmäßigen abständen.
    Wir haben uns mit einem Backup gerettet. Leider hat die Physikalische Maschine das selbe Problem, fällt nur mit einem dauer Ping auf – bisher.
    Kann das Problem jemand bestätigen? Bitte einmal einen Ping auf beliebige ziele setzten und warten. Alle anderen Server in unseren Netzwerk die das Update nicht erhalten haben, haben keine Probleme der Art.
    RDP etc. laufen weiterhin stabil.

    • kelma sagt:

      Verstehe ich das richtig, und es gibt nun die ICMP Probleme, obwohl das Update gar nicht korrekt installiert wurde?

      • Fabian sagt:

        Korrekt, wir hatten auf zwei Servern das gleiche Bild.
        Dabei ist es auch völlig egal, ob das angesprochene Ziel im gleichen oder im gerouteten Netz ist.
        Interessant ist noch, das nicht generell alle Pings abbrechen. Von 6 Gleichzeitigen Pings brechen 3 Ziele ab, 3 sind weiter erreichbar.
        Es ist wirklich gruselig.
        Es würde mich interessieren, ob jemand das Problem bestätigen kann.

  31. MANU sagt:

    Hallo, ja ich habe das selbe Probelm auf VM`s Hyper V.

    Zunächst hing es beim Netframe update. Durch beenden des Task den Windows Modules Installer – startete bei erneuen Öffnen des "Windows Update" , das Netframe Update und wurde erfolgreich installiert – aber das Microsoft update wurde zwar installiert und lief dann auf Fehler.
    Also am besten warten auf die Korreltur von MS ;)

  32. Daniel sagt:

    Kann den Workaround mit dem nachinstallieren des Sprackpakets Englisch (Vereinigte Staatem) bestätigen. Danach ging das Update ohne Probleme durch.

  33. der bug ist das ziel sagt:

    ich konnte auf einem deutschen winserver 2019 standard, x64, amd hardware, einfach dann in den spracheinstellungen da zusaetzlich sprachset "en-us" hinzufuegen, das dauerte zwar so 20mins, aber er hat sichs online geladen, paar megabit an traffic, und ohne spracherkennung ohne extrabullshit alles weggewaehlt. danach direkt ohne reboot war winupdate dann erfolgreich mit mai 2024 monatsupdate. nach dem reboot dann war der ganze scheiss server english, aber dann wieder auf deutsch zurueckgeswappt erstmal in der dropdown liste der installierten sprachen, danach konnte man dann auch das englische en-us wieder entfernen, erneut rebooten dann war der server (display sprache etc) wieder deutsch und gut ist monatsupdate so erstmal appliziert workaround wenn onlinefaehig. mfg

  34. Dominik sagt:

    Denke MS wird das Update nun zurückziehen oder wollen die wirklich, dass alle das englische Sprachpaket nach installieren ?!

    • T Sommer sagt:

      Selbst wenn die das "fixen" – wann kommt das nächste Update das nur geht wenn die englische Anzeige installiert ist?
      Mein Tipp- rein damit und fertig – for all Time (we hope)

  35. Werner sagt:

    Den von Roman beschriebenen Weg kann ich nachvollziehen und bestätigen.

    Habe es aber aktuell nur auf einem Testserver ohne AD Rolle probiert. Es funktionierte. Nach Reboot war mein Server immernoch auf deutsch, aber eben mit einem Zusätzlichen Sprachpaket.

    Ich warte aber erstmal noch was Microsoft da anbietet, ich kann mir nicht vorstellen das es richtig ist jetzt allen Admins dieses gefrickel zuzumuten. Kostet einfach einen haufen Zeit und zudem bleibt der beschgeschmack das dadurch eventuell wieder irgendwas anderen im Longterm nicht geht.

    Ich glaube das ist schon der dritte Patchday 2024 der nicht sauber durchläuft. Keine gute Quote bei 5 Monaten.

    Danke an alle.

  36. Tobias sagt:

    Gibt es denn schon eine offizielle Meldung von Microsoft ?

    • Sandra sagt:

      Ich habe nun eine Mail von Microsoft erhalten, wo das Problem bestätigt wird:

      Microsoft
      The May 2024 security update might fail to install

      Status

      Confirmed
      Affected platforms

      Server Versions
      Message ID
      Originating KB
      Resolved KB
      Windows Server 2019
      WI793371
      KB5037765

      Windows servers attempting to install the May 2024 security update (the Originating KBs listed above), released May 14, 2024, might face issues during the installation process. The installation might fail with an error code 0x800f0982. This issue is more likely to affect devices that do not have en_us language pack support.

      Next steps: We are working on a resolution and will provide an update when more information is available.

      To customize what's included in this email and who gets it, or to stop receiving these emails, set your Windows release health preferences. If you're receiving this email because your admin added you as a recipient and you want to stop receiving these notifications, please contact your admin.
      Privacy Statement
      Microsoft Corporation, One Microsoft Way, ​Redmond, WA 98052​

      Microsoft

  37. Danny sagt:

    Das Problem mit dem RDP rührt daher, dass das Update über Stunden im Zustand "Windows wird vorbereitet. Schalten sie den Computer nicht aus." hängt. RDP funktioniert, aber zum Zeitpunkt der Authentifizierung bricht die Session ab. Das konnte man auf der VMWare Console gut beobachten. Nach etwa 1 Std startet der Server 2019 neu, geht wieder in "Windows wird vorbereitet .." Nach erneutem automatischen Neustart starten alle Dienste und Windows Update meldet das fehlgeschlagene KB5037765– Fehler 0x800f0982

    • Stefano sagt:

      Kann ich bestätigen. Unsere ersten beiden Server die Updates bekommen haben gestern ca. 2 Std. für den Neustart gebraucht. Erst danach tauchte der Fehler zur KB im Ereignisprotokoll auf.

    • Jörg Steinlechner sagt:

      Update ist beim Server nun sauber durch und installiert, sfc /scannow findet nichts, RDP geht trotzdem nicht. auch nach Stunden nicht, auch nach mehrfachen Reboots nicht. über die lokale Konsole kommt man drauf. Hilft halt nix am Terminalserver.
      Logs sind nicht auffällig, außer dass es nach dem Logon Event unmittelbar ein Logoff gibt. Aber ohne Fehler….

  38. Martin Seidel sagt:

    Es ist schon irgendwie lustig dass der Workaround in dem Sinne nicht funktioniert, dass das Sprachpaket nicht heruntergeladen werden kann, es hängt bei: "Sprachpaket wird gesucht…" seit mehr als 12 Stunden

  39. Wollmaus sagt:

    Moin,
    hat das noch jemand, dass auf Server 2019 nach Installation des Language Packs EN/US nach Reboot im Ereignisprotokoll netlogon Fehler 5719 (secure channel) auftauchen?Update 05/24 ist noch nicht drauf.
    Ich habe erst 2 Test VMs mit dem Language Pack bestückt, beide haben dieses Problem.
    Test-ComputerSecureChannel -verbose meldet aber "true" und "guter Zustand"
    Test-ComputerSecureChannel -Server xxxx -Credential xxxx\yyyy meldet auch true
    Start & Anmelden etc. geht alles, sonst nichts auffälliges gefunden…

  40. Jörg Steinlechner sagt:

    Das Update ist nun drauf auf dem SRV19DC, allerdings RDP geht immer noch nicht.
    Das geht allerdings schon seit gestern nicht, wo der erste Versuch des Updates bereits scheiterte.
    Irgendwas ist da noch im Busch….

  41. xyz01 sagt:

    Ich möchte mal meine Version des Fehlers bekannt geben:

    PS C:\Windows\system32> DISM.exe /Online /Add-Package /PackagePath:D:\Downloads\Windows10.0-KB5037765-x64.cab

    Tool zur Imageverwaltung für die Bereitstellung
    Version: 10.0.17763.3406

    Abbildversion: 10.0.17763.5696

    1 von 1 werden verarbeitet – Paket "Package_for_RollupFix~31bf3856ad364e35~amd64~~17763.5820.1.11" wird hinzugefügt
    [==========================100.0%==========================]
    Fehler – Package_for_RollupFix: 0x8007371b

    Fehler: 14107

    Mindestens ein erforderliches Mitglied der Transaktion ist nicht vorhanden.

    Die DISM-Protokolldatei befindet sich unter "C:\Windows\Logs\DISM\dism.log".
    PS C:\Windows\system32>

    Ein Auszug von dism.log

    [cbs.log auf Pastebin unter https://pastebin.com/8E4Ki3E2 ausgelagert]

    Interessanter Weise wird hier an erster Stelle eine fehlende wcp.dll aus microsoft-windows-servicingstack bemängelnd die da nicht vorhanden ist. Nachfolgend kommen dann die anderen Fehler. Fragt sich nun, stehen die in den Zusammenhang mit der Aussage von PS? Wer hat da den Fehler verursacht? Alle vorherigen Updates liefen "naja" bislang problemlos. Auch eine schönen Gruß an Anonymos

    Hat da eine Idee oder vielleicht hilft das auch weiter wie man hinter den Fehler kommen könnte!?

    • admin sagt:

      Bei den meisten Servern 2019 konnte ich das Language Pack installieren.
      Jetzt sind noch 4 übrig, bei denen genau das passiert, was Du hier geschrieben hast Fehler 14107:

      Da ich bei allen die gleiche (nur 1 x heruntergeladene .CAB-Datei verwendet habe, liegt es wohl nicht an der CAB Datei.
      Aber woran dann?

  42. Mr. T sagt:

    Verlangt Microsoft eigentlich mittlerweile Ransom für funktionierende Updates?
    Ich weiß gerade nicht mehr, was mir mehr Angst machen soll: die Updates von Microsoft oder die Cyber-Schurken.

  43. Jörg Themlitz sagt:

    Wen es interessiert. Server Updates mache ich immer nach 2-3 Tagen. Darum bin ich erst heut mit dieser Fehlermeldung konfrontiert und hierher gelangt. Server 2019 essentials, hier in der CZ, alles in deutsch, nur als einfacher fileserver. Update nach 20 % mit obiger Fehlermeldung abgebrochen, Server neu gestartet Update nach 100 % Installation mit der Fehlermeldung abgebrochen. Ohne Update, jetzt 2 Stunden später erst einmal keine Auffälligkeiten. Mal sehen oder wie Werner sagt: "Ein Glück Morgen ist Berufsschule." (ich fahre nach DE) Bitte nicht kommentieren. Die obigen Hinweise (z. B. Sprache) probiere ich heut Abend. Etwas anderes ungewöhnliches, von 16 PC W10 22H2 (Hardware sehr ähnlich) ließen sich nach dem Update, 3 nicht herunterfahren. Blieb nur ausschalten. Laufen nach dem Anschalten normal.

  44. Matthias sagt:

    Da ich gelesen habe, dass manche sich bei Problemlösung schwer getan haben hier nochmal das Vorgehen, was bei uns auf ca. 35 Servern – 2019 Datacenter, nur deutsches Sprachpaket bisher – (TS, DC, SQL, FILE) erfolgreich war:
    1. ISO-file mit den Sprachpaketen herunterladen: https://software-download.microsoft.com/download/pr/17763.1.180914-1434.rs5_release_SERVERLANGPACKDVD_OEM_MULTI.iso
    2. Iso-file Mounten und unter 64/langpacks die en-us Sprachdatei auf den Desktop kopieren
    3. unter Windows "Start" "LPKsetup" eingeben.
    4. mit einem rechten Mausklick den Speicherort öffnen
    5. mit einem rechten Mausklick auf LPKsetup.exe "ausführen als Administrator" wählen
    6. via Durchsuchen => Desktop => Sprachpaket wählen und installieren (dauert meist 20-30 Minuten)
    7. Nach erfolgreicher Installation können (ohne Neustart) die Updates gesucht und installiert werden (ging während des laufenden Betriebes auf den Terminalservern)
    8. Anschließend müssen die Server neu gestartet werden
    Keiner der Server bootet aktuell mit aktivem englischen Sprachpaket, wie das von Anderen erwähnt wurde.
    Also lasse ich das Sprachpaket installiert.

  45. Jörg Steinlechner sagt:

    Kleinen Abschlusssenf zu meinem RDP Problem:

    ich konnte ja nur mehr via Console-Session auf den Server zugreifen.

    Als Workaround / Lösung hab ich nun den RDP Session Host von der Maschine deinstalliert und nach einem Reboot neu installiert, somit funktionieren auch wieder "normale" RDP Sessions auf den Server!

  46. admin sagt:

    Ich habe es gerade exakt nach dieser Anweisung ausgeführt.
    Die Installation startert und läuft ca. 25 min. Der Wartebalken geht bis ca. 90 % dann erscheint dort "Fehler" ohne irgend eine weitere Angabe.
    Das Sprachpaket lässt sich auf dieser VM nicht installieren.

  47. PVSJT sagt:

    Heute Scheint KB5037765 scheinbar aus dem Verkehr gezogen worden zu sein.
    Hab grade einige meiner 2019 Server nochmal neu gestartet um das ganze mit dem Workaround anzugehen und jetzt wird mir KB5037765 nicht mehr Angeboten.
    Kann das jemand bestätigen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.