Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife

Windows[English]Ich ziehe es mal separat als Blog-Beitrag heraus. Administratoren von Windows Domain Controllern sollten mit der Installation der Sicherheitsupdates von Januar 2022 vorsichtig sein. Mir liegen inzwischen zahlreiche Berichte vor, dass die Windows Server, die als Domain Controller fungieren, anschließend nicht mehr booten. Lsass.exe (oder wininit.exe) löst einen Blue Screen mit dem Stopp-Fehler 0xc0000005 aus. Es kann nach meiner Einschätzung alle Windows Server-Versionen, die als Domain Controller fungieren treffen.


Anzeige

Januar 2022-Updates adressieren Active Directory-Bug

Ich habe es in den am Artikelende verlinkten Blog-Beiträgen zum Patchday aufgeführt. In allen Sicherheitsupdates für Windows Server (z.B. Update KB5009624 (Monthly Rollup for Windows 8.1 and Windows Server 2012 R2)) heißt es:

Addresses a Windows Server issue in which Active Directory attributes are not written correctly during a Lightweight Directory Access Protocol (LDAP) modify operation with multiple specific attribute changes.

Dabei scheint aber etwas schief gegangen zu sein, denn das Sicherheitsupdate kann eine Boot-Schleife auf Windows Servern auslösen, die als Domain Controller fungieren.

Boot-Loop bei Windows Server

Blog-Leser John L. hat mich bereits am 11. Januar 2022 per Mail kontaktiert und auf ein fettes Problem in Verbindung mit dem Update hingewiesen. Das Modul lsass.exe, Version: 6.3.9600.17415, löst über die Bibliothek msv1_0.DLL, Version: 6.3.9600.20239, einen Fehler 0xc0000005 (Zugriffsverletzung) aus, so dass der Server in eine Boot-Schleife gerät.

""Name der fehlerhaften Anwendung: lsass.exe, Version: 6.3.9600.17415, Zeitstempel: 0x545042fe
Name des fehlerhaften Moduls: msv1_0.DLL, Version: 6.3.9600.20239, Zeitstempel: 0x61c1a5c8
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000002663
ID des fehlerhaften Prozesses: 0x1f4
Startzeit der fehlerhaften Anwendung: 0x01d8072ac5b2c15a
Pfad der fehlerhaften Anwendung: C:\Windows\system32\lsass.exe
Pfad des fehlerhaften Moduls: C:\Windows\system32\msv1_0.DLL
Berichtskennung: afc36fda-7320-11ec-813a-00155d012601
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: ""

Ich hatte dies bereits im Blog-Beitrag Patchday: Windows 8.1/Server 2012 R2-Updates (11. Januar 2022), mögliche Boot-Probleme angesprochen. John hatte folgende Ratschläge:

Ich will davon abraten, Snapshots zurückzurollen, besonders bei DC's, um keine USN-Rollbacks zu provozieren.

Workaround: Einen der beiden DC's am Hochfahren hindern, dann erst auf dem einen und dann auf dem anderen DC die heutigen Hotfixes deinstallieren.

In den Kommentaren zum obigen Blog-Beitrag (und dem englischsprachigen Pendant) bestätigen weitere Blog-Leser dieses Problem. Blog-Leser MOM20xx hatte die Boot-Schleife auch nach Deinstallation des Updates und merkt an, dass auch das Security-only Update KB5009595 auf den Domain Controllern zu deinstallieren sei.

Betrifft vermutlich alle Windows Server DCs

Blog-Leser Simon schreibt in diesem Kommentar, dass es auch  Windows Server 2016/2019 Domain Controller betreffe. Er hat dann folgenden Dump-Auszug gepostet.

The process wininit.exe has initiated the restart of computer DC on behalf of user for the following reason: No title for this reason could be found
Reason Code: 0x50006
Shutdown Type: restart
Comment: The system process 'C:\Windows\system32\lsass.exe' terminated unexpectedly with status code -1073741819. The system will now shut down and restart.

Faulting application name: lsass.exe, version: 10.0.14393.4704, time stamp: 0x615be0cd
Faulting module name: lsadb.dll, version: 10.0.14393.4886, time stamp: 0x61d5242f
Exception code: 0xc0000005
Fault offset: 0x000000000001be5b
Faulting process id: 0x2a8
Faulting application start time: 0x01d8077b1080a9da
Faulting application path: C:\Windows\system32\lsass.exe
Faulting module path: C:\Windows\system32\lsadb.dll
Report Id: e14067b5-aac7-46a4-9e21-cc45371c522a
Faulting package full name:
Faulting package-relative application ID:

Dort löst also wininit.exe den Fehler 0xc0000005 am Domain-Controller aus. Ich habe auf Facebook auch noch eine Rückmeldung, dass Update KB5008873 bei Windows Server 2019 den Neustart der AD-Controller veranlasst (dort kommt folgende Benachrichtigung, scheint wohl kein Stopp-Fehler 0xc0000005 zu sein).

Boot-Loop bei Windows Server 2019
Boot-Loop bei Windows Server 2019


Anzeige

Falls wer noch einige Hinweise braucht, wie man das Update in einer Windows PE-Umgebung deinstalliert, verweise ich mal auf How to Remove Updates from Windows Recovery Environment (WinRE).

Anmerkung: Laut diesem Kommentar verursacht das Update KB5009543 Probleme mit L2TP-VPNs. Auf reddit.com gibt es diesen Thread dazu.

Zudem liegen mir Meldungen vor, dass VMs auf Server 2012 R2 Hypervisor nicht mehr starten. Als Fehlermeldung kommt das der Hypervisor nicht läuft: Hypervisor launch failed; The operating systems boot loader failed with error 0xC00000BB. Ist bei Server 2012 R2 wohl Update KB5009624 – nur als Hinweis, falls es unter Windows Server 2016 – 2019 auch Problemen geben sollte.

Ähnliche Artikel:
Microsoft Office Updates (4. Januar 2022)
Microsoft Security Update Summary (11. Januar 2022)
Patchday: Windows 8.1/Server 2012 R2-Updates (11. Januar 2022), mögliche Boot-Probleme
Patchday: Windows 10-Updates (11. Januar 2022)
Patchday: Windows 11-Updates (11.Januar 2022)
Patchday: Updates für Windows 7/Server 2008 R2 (11. Januar 2022)

Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife
Windows VPN-Verbindungen (L2TP over IPSEC) nach Januar 2022-Update kaputt
Windows Server 2012/R2: Januar 2022 Update KB5009586 brickt Hyper-V Host
Microsoft Patchday-Probleme Jan. 2022: Bugs bestätigt, Updates zurückgezogen?


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

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

148 Antworten zu Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife

  1. Simon sagt:

    Hallo Günter,

    zur Klarstellung (zumindest bei uns) kommt es nicht zu BSODs bzw. Boot-Problemen bei 2016/2019er DCs, die Neustarts werden alle 15 Minuten durch die abstürzende LSASS vom WININIT Prozess ausgelöst und dabei die von mir beschriebenen Events geloggt.

  2. Johnny sagt:

    Da der KB5009624 den Namen "…Server 2012 R2" trägt, gehe ich davon aus, dass dieser News-Artikel / die Boot Probleme auch nur Server 2012 R2 betreffen?

  3. Bernhard sagt:

    Unser 2012 Hyper-V Server will nach dem Update von KB5009586 ebenfalls nicht mehr!
    "Fehler beim Versuch, die ausgewählten virtuellen Computer zu starten"
    "Der virtuelle Computer XXXXX konnte nicht gestartet werden, da der Hypervisor nicht ausgeführt wird."
    Nach der Deinstallation von KB5009586 läuft es wieder, aber leider hat es die virtuellen Linuxmaschinen zerschossen, sodass mittels Restore diese wiederhergestellt werden mussten.
    Mit lieben Grüßen
    Bernhard

  4. 1ST1 sagt:

    DANKE für diese Zusammenfassung! Bei uns haben wir auch schon diverse Effekte gesehen und sind momentan am Reversen, KB5009557, KB5009546, KB5009624 bzw. KB5009595 haben wir auf dem WSUS erstmal deaktiviert.

    Das ist wirklich ein Armutszeugnis für Redmond.

  5. Tom sagt:

    Hat jemand eine Idee wie man den Neustart aufhalten kann, damit man den KB zuverlässig entfernen kann?

    Die meisten DCs starten innerhalb weniger Minuten neu.

    Das stoppen der Domänendienste hilft nicht.
    Welcher Dienst könnte den Fehler auslösen?

    • Rafael sagt:

      das ist vermutlich eine GPO ich nehme an ihr habt "Neustart immer automatisch zur geplanten Zeit durchführen" aktiviert, hier kann man Minuten angeben…

    • Helmut sagt:

      Hallo Tom,

      deaktivieren des Netzwerkadapters in VMware hat bei mir geholfen. Zumindest läuft die Maschine und man kann alles machen solange man das Netzwerk nicht einschaltet. Dann dauert es wenige Minuten und er fährt einfach runter (Server2019 als DC)

    • 4Dre sagt:

      Bei uns hat das Deaktivieren der Netzwerkverbindung geholfen. Danach war das Zeitfenster deutlich größer.

    • Maik sagt:

      im Abgesicherten Modus starten (F8) dann deinstallieren.

      Interessant ist auch das nur die Desktopversionen betroffen sind. Die Core -Server starten nach der Deinstallation auf dem Desktop-Server nicht mehr neu.

      Habe die Updates trotzdem deinstalliert.

    • Richard sagt:

      Bei unseren 2012R2 DCs gelang die Deinstallation vom KB5009624 gerade problemlos und ohne Unterbrechungen im abgesicherten Modus.
      Dazu nach dem BIOS POST, jedoch vor dem Windows Bootlogo, die Taste F8 gedrückt halten und im Bootmenü in den Abgesicherten Modus starten.

      Interessanter Weise hörte der SDC mit den Reboots auf nachdem das fehlerhafte KB5009624 auf dem PDC deinstalliert war und der PDC neu gestartet war.
      Habe das KB auf dem SDC dennoch deinstalliert.

    • Markus sagt:

      VM hart abschalten, danach hatte ich beim Hochfahren genug Zeit für die Deinstallation. Obwohl die Tipps meiner Vorredner weniger invasiv sind :)

    • Andi sagt:

      Im abgesicherten Modus deinstallieren hat bei mir funktioniert

  6. Werner sagt:

    Ach jammert mal nicht so rum! Es sind doch NUR Domänen Controller betroffen.
    Dafür habt ihr mit den letzten Updates unter Windows 11 doch auch neue Emojis bekommen. 💖🧡💛💚💙💜🤎🖤💗

  7. Tom sagt:

    Wir konnten den Restart von einem Nachbarserver mit Powershell verhindern und den Deinstallationbefehl senden. Ob es 100% klappt können wir noch nicht bestätigen.

    enter-pssession SERVERNAME
    cd C:
    net stop ntds /Y
    net stop netlogon /Y
    net stop dhcp /Y
    wusa /uninstall /kb:5009557

    • MOM20xx sagt:

      sollte durch gehen. ich habs per gui im normal modus deinstalliert und musste 2 patches wegmachen. das ding hat da halt mehrfach unmotiviert rebootet. schlussendlich war es dann aber weg.

    • Tom sagt:

      Die Bootschleife lässt sich damit durchbrechen. Das Update lässt sich so aber nicht entfernen.

      Startet man nach einer Weile Netlogon wieder, kann man sich am Server anmelden und den KB5009557 manuell deinstallieren.

  8. Andreas sagt:

    Konnte den, in meinem Fall minütlichen, Neustart eines auf Hyper-V laufenden 2012 R2 DC´s verhindern indem ich die die virtuelle Netzwerkkarte im Hyper-V auf den virtuellen Switch "Nicht verbunden" gesetzt habe.

    Anschließend hatte ich genug Zeit das fehlerhafte Update auch ohne WinRE etc. zu deinstallieren.

  9. Seb Bo sagt:

    Bei Windows Server 2016 war KB5009546 zu deinstallieren, damit die Neustarts aufhören.

  10. Kingcopy sagt:

    Bei uns geht es los alles geht down…2016 er Masterdomäne und reserve um 12 Uhr herum

  11. jup sagt:

    Frage: in der Zeit bis zur obigen Boot-Loop _ kann man da jetzt drucken ?

  12. Jackie sagt:

    Davon abgesehen dass das was Microsoft hier liefert wieder völlig inakzeptabel ist wundert mich das so viele die Updates schon auf den DCs oder gar einem Hyper-V installieren. Klar für IT gibts oft kein Geld also hat man keine Testumgebung. Aber Updates aufm DC installiere ich nur wenn ich weiß das sie save sind.

    Bewährt hat sich bei mir folgende Reihenfolge:

    – Irgendwelche Appserver
    – SQL-Server
    – DCs
    – Hyper-V Cluster zu letzt da dieser extrem auf die AD angewiesen ist

    • 1ST1 sagt:

      Der Idealfall wäre, wenn Micrsoft Updates herausgeben würde, die safe sind. Das sollte man eigentlich erwarten können, oder? Wenn man morgens ins Büro kommt, und als erstes gleich ließt, dass die neuesten Patchdayupdates schon wieder ein Griff ins Klo sind, dann ist das nicht was ich von einem der führenden Softwareunternehmen dieses Planeten erwarte.

      • Jackie sagt:

        Ja das wäre natürlich der Idealfall :) Ich hatte vor Jahren einen 2008 R2 Server Foundation bei einem Freund im Unternehmen der hat seine Updates am Wochenende sogar automatisch installiert! War auch nur ein Fileserver und DNS aber kein AD Controller. Das war mehrere Jahre überhaupt kein Problem, so nach vier bis fünf Jahren wurde es dann doch unlustig und wir haben das dann mal geändert. Heute lasse ich nich mal mehr meinen privaten Windows 10 Client Updates automatisch installieren. Ich habe die Einstellung aus der Registry eines Windows Servers kopiert, das läuft ziemlich gut. Automatisch gibt es nur noch Defender Updates, was wie wir wissen aber auch nicht ganz ungefährlich ist ;)

    • MOWCJ sagt:

      Ja geil, nur das Problem taucht eben nur auf DCs auf
      Ohne Test mit 1:1 Struktur , für die keiner mehr Zeit / Geld hat ist das wohl nix mit x….

  13. Michael sagt:

    Hallo,

    Updates heute morgen auf einem DC mit Win Server 2012 R2 und Win Server 2019 installiert. Neustart dauerte ewig, aber Boot-Schleifen gab es hier keine. Wir sind aber vergleichsweise klein mit nur einer Domäne.

    Michael Buchner

  14. wz19 sagt:

    Problem tritt auch auf bei Server 2022 mit KB5009555
    also Vorsicht!
    Viele Grüße

    • M sagt:

      Aber nicht bedingungslos.

      Ich habe eine Versuchsumgebung mit 2022/2019 (beides DC's) und Funktionslevel 2016 (aktuelles Maximum) – beide laufen jetzt gut zwei Stunden ohne Probleme.

      Dem ganzen muss eine Bedingng zu grunde liegen – nur welche…

      • Anonymous sagt:

        tritt scheinbar nur auf denn der DC ein Hyper-V Gast ist.

      • Jelko sagt:

        Hallo,

        habe bei uns die Erfahrung gemacht, dass der DC immer in die Knie ging, wenn sich auf einem anderen Server ein User versuchte bei der Domain einzuloggen. Das würde auch erklären, warum ein Deaktivieren der Netzwerkkarte dafür sorgt, dass das Problem nicht mehr (so oft) auftritt…

        Ist übrigens ein Windows Server 2019 auf einem ESXi Host.

        Viele Grüße

        • JohnRipper sagt:

          Interessant aber wieviele DC doch auf virtuellen Umgebungen betreiben. Empfiehlt MS nicht stark physisches Blech? oO

          • GPBurth sagt:

            ich konnte auf die Schnelle nichts finden und seit Server 2012 oder so wurde ja inzwischen sogar der Restore aus Backups vereinfacht/zugelassen.

            Es sollten pro Standort ohnehin mehrere DCs vorhanden sein, die im Regelbetrieb nicht auf demselben Virtualisierungsserver laufen, damit nicht alle gleichzeitig ausfallen. Eventuell kam das früher daher – wenn einer physisch ist sind sie logischerweise nie auf demselben Blech. Können aber natürlich an derselben Stromversorgung oder Switch hängen…

          • Stefan A. sagt:

            Ich habe beides :) Blech und virtuell. Die Diskussion hatte ich schon öfters. Aber ich bin ein Verfechter von mindestens 1x Blech DC :)

          • Ben sagt:

            Wäre mir nichts bekannt, dass MS das empfiehlt… hast Du da ne Quelle für?

            Was dagegen empfohlen ist (hab auf die Schnelle auch keine Quelle… allerdings ist es ja auch irgendwo logisch): mindestens EINEN physikalischen DC. Um sicher zu gehen, dass man sich nicht selbst den Ast absägt, falls es mal ein Problem mit der Virtualisierungsumgebung kommen sollte.

  15. Tom R. sagt:

    Wenn man den Patch reguär deinstalliert, bleibt der Windows 2019er DC ca. 20min. nach dem Neustart bei 100% stehen. Einfach ausharren, das wird schon :-)

  16. Stefan sagt:

    Haben gestern 2016 DC, SQL und MX auf VM aktualisiert.
    Update lief sehr lange durch, jedoch bis dato ohne Probleme.
    Eine Sache viel auf: Auf DC und SQL startete nach Update automatisch unsere Windows Server Sicherung … spooki

  17. Andi sagt:

    Ich habe diese Probleme glücklicherweise nicht.

    Ich habe bisher 3 DCs mit 2012R2 aktualisiert und alle kamen problemlos wieder hoch.
    Auch nach 4-5 Stunden laufen die DCs noch ohne Probleme.
    Ich hoffe nur, dass das auch so bleibt.

  18. Andreas sagt:

    abgesichert booten über cmd -> msconfig, dann konnte ich die Updates deinstallieren (w2k12r2) – ich glaube, MS will die Kunden in die Cloud zwingen. So viele Fehler in letzter Zeit.

  19. Dominik sagt:

    Hier wurden gestern Abend an einem unserer Standorte auf dem Windows Server 2019 Domain Controller folgende Updates installiert:
    KB5009557
    KB5009718

    Bisher absolut keine Probleme.

    Auf den beiden Windows Server 2012 R2 Hosts des HyperV-Failoverclusters landeten folgende Updates auf der Platte:
    KB5009624
    KB5009721
    KB890830
    KB5009595
    KB5009713

    Auch hier waren bisher keinerlei Probleme feststellbar.

    Einfach nur Glück gehabt oder kommt das böse Erwachen erst noch?

  20. Gero sagt:

    Zwei physische 2019er DCs aktualisiert ohne Probleme.
    Mit den virtuellen warte ich dann erstmal noch ab….

  21. Andreas F. sagt:

    Hallo,

    Ich habe auch 2 Win 2012 R2 DCs und die Updates wurden heute morgen um 3 Uhr automatisch installiert.
    Die Kisten laufen direkt auf Blech.

    Bei mir tritt das Problem nicht auf. Und in den Logs ist nichts ersichtlich. Heute morgen gegen 3.30 automatisch neu gestartet und seid dem Laufen die beiden durch. Es scheit wohl eine Kompetente mit reinzuspielen die das Problem verursacht.

    Vg
    Andreas

  22. Johann Tissen sagt:

    Was gestern abend bei Windows Server 2012r2 auch geklappt hat (Hyper-V VM), Netzwerk wegnehmen. Der Server startet dann nicht automatisch nach einer Minute wieder neu und das Patch kann auch in Ruhe deinstalliert werden.

  23. Robert sagt:

    Hat MS sich inzwischen zu den Fehlern (DCs rebooten, VPN-Probs., ReFS und Hyper-V) in irgendeiner Form irgendwo geäußert, bzw. hat jemand mitbekommen, dass diese Fehler irgendwo bei MS überhaupt gemeldet worden sind?

    • Robert sagt:

      Hat sich anscheinend inzwischen erledigt :)
      …habe gerade mal auf meiner Test-AD Umgebung versucht, einen 2019er DC und einen 2012R2 DC zu updaten, um zu sehen, was passiert – und siehe da: auf dem 2019er und 2012R2 sind nur die .NET Framework Updates noch da. Anscheinend hat MS die kumulativen Januar Updates für die Server zurückgezogen – WOW!

  24. Martin Sitte sagt:

    Habe die Updates auf 3 DC (Server 2016, einer virtuell auf ESXi, 2 phys.) installiert, keine Probleme, die laufen seit Stunden. Da hatte ich offensichtlich Glück.

  25. Rick sagt:

    Richtig blöd ist es, wenn die Domaincontroller als Hyper-V Guest laufen und man sich auf den Hyper-V Manager nicht einloggen kann, weil kein Domainencontroller verfügbar ist.

    • Blubmann sagt:

      Hatte das am Anfang auch mal, war dann ein Lehrgeld und ich tu Hyper-V-Hosts nur noch aus der Domäne ziehen und eine lokale Anmeldung einrichten.

  26. Stefan A. sagt:

    @Robert
    Suchst du online nach Updates oder über WSUS?
    Wäre mal interessant, ob die Updates auch über den WSUS zurückgezogen wurden.

    Muss ich morgen gleich prüfen bzw. synchronisiert unser WSUS eh in 5 Stunden wieder.

    Ich durchforste schon den ganzen Tag das Internet.

    Die Neustarts habe ich bisher immer nur gelesen bei DCs und nicht bei anderen Servern wie Exchange oder andere „normale" Member Server….

    Hat da von euch nochmal einer was in die Richtung gelesen?

  27. Stefan A. sagt:

    WSUS hat frisch synchronisiert.
    Updates werden trotzdem weiterhin angeboten.

    Müssten diese nicht z.B. als abgelaufen markiert werden, wenn MS diese auch am WSUS zurückziehen würde?

    • Robert sagt:

      Gerade noch einmal (10:20 Uhr) nach gestern (23:30 Uhr) auf unserem 2012R2 mit Windows Update nach Updates gesucht. Das kumulative Januar 2022 Update fehlt weiterhin (zurückgezogen).

  28. Jakob sagt:

    Hallo,
    ich wollte den Link zu diesem Blogartikel von meiner privaten Email an meine Arbeitsemail (Office 365) schicken.
    Microsoft hat die Mail mit "Phishing"-Verdacht unter Quarantäne gestellt :-)
    Ein Schelm, wer Böses dabei denkt.

    • tineidae sagt:

      Ich habe gestern im "Microsoft Security" You Tube Kanal von Microsoft ein Kommentar bezüglich der Problematik in dem Video zum aktuellen Patchday abgegeben (freundlich), wurde direkt gelöscht ;)

  29. Taffie sagt:

    Hallo ihr Lieben,

    Gestern wurde auf einem unserer Kunden-Hyper-V Guests (Windows Server 2012R2 – DC) das Update deinstalliert, woraufhin das Problem gelöst war. Heute morgen tritt das selbe Problem auf einmal wieder auf, in den installierten Updates sind die fehlerhaften Updates jedoch nicht mehr auffindbar.

    Kennt dieses Problem noch jemand und hat vielleicht sogar schon eine Lösung parat?

  30. Blubmann sagt:

    Noch ein Phänomen bei DC 2012 R2. Nach Installation von KB5009624. Server startet und man kann das Passwort am Anmeldebildschirm eintippen. Beim drücken der Enter-Taste oder des Anmeldebuttons passiert dann aber nix mehr.

  31. Andi sagt:

    Diese Probleme scheinen durch irgendetwas getriggert zu werden, dass ich nicht einsetze.
    Ich habe gestern noch weitere DCs (2012R2) aktualisiert, zudem noch 30 Maschinen von 2012R2 – 2022. Auf keiner konnte ich Probleme feststellen.
    Auf WSUS werden die Updates auch nach wie vor angeboten.
    Dementsprechend werde ich die nächsten Tage auch die restlichen Server mit den Januar Updates betanken.

    Ich setze allerdings auch KEIN Hyper-V ein. Microsoft arbeitet ja schon länger daran Hyper-V kaputt zu machen, um den Kunden die "fantastische" Cloud schmackhaft zu machen.
    Mich wundert gar nichts mehr.

    • Günter Born sagt:

      Hatte auch mal kurz Hyper-V im Verdacht. Aber es gibt Kommentare, wo der DC auf Bar Metal läuft. Und es gibt einen Kommentar, wo eine Testinstallation virtualisiert läuft, der Fehler aber nicht auftritt. Wenn ich irgend etwas bzgl. der Ursache herausfinde, trage ich es nach.

      • Robert sagt:

        Nur mal so eine Vermutung 'ins Blaue' hinein ;-) …
        Bei den Systemen, wo diese Boot-Loops bzw. Restarts nach x Minuten auf den DCs auftreten, ist da die AD FS Komponente installiert?

        • M sagt:

          Du meinst explizit die Federation Services?

          Ich hab eine Umgebung mit 2016/2019 auf Hyper-V und AzureAD Connect (auf dem 2016, nicht im Federation Mode): der 2019 hat das Update bekommen und läuft ohne Probleme.

          Das 15min-Intervall klingt für mich stark nach dem default Replikationsintervall zwischen DCs, was ja auch damit passt, dass es ohne Netzwerk keine Abstürze/ Reboots gibt.

      • Zahni sagt:

        Ohne etwas getestet zu haben. mal ein paar Vermutungen.

        – Es tritt nur auf wenn der Function Level 2012 R2 ist. Hier könnte ich mir eine Anhängigkeit zum "gefixten" LDAP-Problem vorstellen.
        – es ist ein NLS-Problem, falls die Domäne ursprünglich mal in Deutsch installiert wurde, Stichwort "Domänen-Admins", auch noch mit Umlauten. Man findet zu dem Problem kaum amerikanische Quellen.

        • M sagt:

          ich habe eher den Funktionslevel in Verdacht.
          Das Problem tauchte im Kontext von 2012R2 auf, sprich Umgebungen die schon länge im Einsatz sind und ggf. so gar noch prä-2012R2 Funktionslevel haben und der eigehende Replikationen am AD dort auf ihnen unverständliche Daten stoßen.

          Das Neustarten rührt daher, dass die Fehlerbehandlung für den Anmeldedienst (lsass.exe) ein Neustart vorgibt – was nicht änderbar ist.

          • Robert sagt:

            Wäre ja nicht so toll, da selbst Funktionslevel 2008R2 noch unterstützt werden muss, da es ja noch Firmen mit bezahltem ESU gibt, die u.U. noch 2008R2 Server im Einsatz haben.

          • Florian Stichlberger sagt:

            Hab hier eine betroffene Umgebung, die wurde initial auf 2008R2 in Englisch in Betrieb genommen, die Server sind inzwischen auf 2019 aktualisiert worden, nur der Funktionslevel ist noch immer auf 2008R2.
            Ich kann heut abends mal den Funktionslevel raufstufen und das Update neu ausrollen – dann sehen wir ob es was ändert.

        • Anonymous sagt:

          tritt auch mit level 2016 auf

        • Dirk sagt:

          Tritt definitiv auf bei 2016er-Level auf.

      • Paul sagt:

        Vielleicht dadurch?

        "Support has responded. Apparently this is now a known issue that will be addressed in a future patch. For now, they've advised: Until a fix exists, temporarily avoid setting PacRequestorEnforcement = 2 (set as 1). Enforcing PAC hardening will cause the password change scenario. Setting PacRequestorEnforcement to '1' is about as secure as '2' if all DCs in an environment have been patched for more than 7 days. The main difference between '1' and '2' is that for '1' all security checks are done if the new Pac buffers are available, whereas '2' requires the buffers to be available."

        Source:

        • PeDe sagt:

          Der Eintrag aus dem Discord kam von einem User auf meine Anfrage, wir haben dazu ein Ticket bei MS auf . Nach dem Setzen von 2 kam es zu EventID 1207 Fehlern bezgl Failoverclustern.

          Zudem sind wir wieder auf 1 und konnten in der Testumgebung den Fehler nachstellen.

          • Robert sagt:

            Beudeutet dies, dass wenn PacRequestorEnforcement wieder zurück auf '1' gesetzt wird, dass dann die Updates keine Fehler mehr verursachen?
            Hatte auch erst sehr spät (ca. 6 Wochen nach den Nov. Patches) die DCs auf '2' umgestellt, weil mir in diversen Foren dazu geraten wurde ('1' sei kein Schutz und würde nur im EventLog protokollieren, wenn jemand 'angreift').
            Und nach den Patches dann wieder auf '2' stellen? Habt ihr das ausprobiert?
            auch an alle anderen hier: habt ihr das auf '2' stehen gehabt, als ihr die Boot-Loops bekommen habt?

          • PeDe sagt:

            @Robert konnte nicht auf deinen Kommentar Antworten:
            Im November auf "2" zu setzen war gar nicht gut da hatte es direkt geknallt bei diversen Produkten, gab es einige Artikel zu. Hier hatten wir es innerhalb weniger Stunden zurückgesetzt auf "1"

            Wir hatten es im Dezember dann erneut gesetzt bekamen die Fehler nicht mehr, das wurde ja auch Ende Nov in out-of-band patches gefixed.
            Stattdessen bekamen wir EventID 1207 und hierzu gibt es von MS die Info dass es inzwischen ein Bekanntes Problem ist das in "Zukunft" gefixed wird. Daher sind wir auf 1 Zurückgewechselt und 1 ist auch sicher ab 7 Tage nach CU2021-12 Installation. So zumindest die Kommunikation.

            Für Januar waren wir auf Stand "1" bei den DCs. 2012R2 mit FFL/DFL 2012R2 auf Physik.

          • Robert sagt:

            @PeDe
            wir hatten auch erst 6 Wochen (also im Dez) auf 2 gestellt, haben aber erst gar nicht versucht die Updates einzuspielen (rechtzeitig hier alles gelesen) :) !
            Wollte nur wissen, ob jemand das auf 1 gesetzt versucht hat und ob da auch die Boot-Loops kamen (sodass man 2 nicht benutzen darf), oder ob es bei '1' das Problem ist, oder generell (egal ob 1 oder 2)..?

          • Patrick sagt:

            @Robert:
            also im Januar hatten wir 1 und auf 2 zu gehen birgt das EventID 1207 Problem da würde man sich dann nur ein anderes Problem einhandeln.
            Daher hatten wir das nicht gemacht.

          • Robert sagt:

            @Patrick: also hattet ihr '1' gesetzt. Liefen Eure Server nach den Updates, oder hattet ihr das Boot-Loop Problem?
            Gut, wir haben ja nichts mit Cluster, ganz normale einfache AD Domain (auch nix mit ADFS). Möchte nur rausfinden, ob wir das mit '1' oder '2' versuchen sollen, um so ein Boot-Loop Problem zu vermeiden (wir haben noch keine Updates eingespielt) und als wir in unserer Test-AD Umgebung dies ausprobieren wollten, hatte MS gerade die Updates für Windows Update zurückgezogen. Klar, wir könnten jetzt mit denen aus dem Catalog testen, wollen aber erst einmal abwarten, was da jetzt von seiten MS kommt ;-)

          • PeDe sagt:

            @Robert:
            lieber abwarten…
            Da kommt noch eine Info, Frage ist nur wann…
            Ja in der Testumgebung trat der Boot-Loop bei "1" gesetzt auf.
            Im WSUS waren die Updates noch drin.

  32. MSwie? sagt:

    Ein Kommentator auf Bleepingcomputer hat dieses hier beobachtet:

    „Michiel1981
    Hey man,

    The issue of reboots only happens if 2 or more DC's have the update installed. Just turn off 1 dc or boot it into safemode without networking and the other DC stops rebooting. Then you have atleast 1 DC up for people to continue work and you have time to uninstall the patches.
    I had the same thing happen on 2012R2 and when i was in safe mode with 1 dc trying to uninstall the patch the other DC stopped rebooting. When i fired up the rolled back DC the other DC with the update kept running fine. Offcourse i did uninstall the update anyway on it."

    Könnte was dran sein…

  33. seteq sagt:

    Habe ebenfalls Bootloops bei virtualisierten 2019er DCs mit Certificate Services und Print Services (ja ich weiß eh, das tut man nicht) gehabt.
    Als Ursache kann ich das KB5009557 bestätigen, seit dem Entfernen alles wieder gut.

    Andere DCs ohne diese Rollen hatten das Problem bisher nicht.

    • Florian Stichlberger sagt:

      Hab nochmal die Monitoring-Daten durchgeschaut und muss korrigieren: Auch Domain-Controller ohne zusätzliche andere Services hatten das Problem.

  34. Anonymous sagt:

    Nein, das kann nicht stimmen (zumindest nicht generell). In einer Test-Umgebung mit nur 1 DC ist das Problem bei uns auch aufgetreten.

  35. MOM20xx sagt:

    Probleme sind bei uns erst gekommen, als der 2. DC das update auch hatte. Wir sind virutalisiert damit auf ESXi 6.5 Platform. Zudem vm paravirtual scsi und vmxnet3 adapter. letztmögliche hardware version für den esxi. vmware tools aktuell

    DC Windows Server 2012 R2 dazu noch Symantec Endpoint Protection 14.3 RU3 installiert.

  36. JohnRipper sagt:

    Puh da hatte ich ja nochmal glück, dass ich Zeit hatte die Bereitstellung zu verhindern.

    Wieso MS die Updates aber noch nicht zurückgezogen hat, ist mir ein Rätsel.

    • Robert sagt:

      Haben diese zurückgezogen (denke so gegen 23:00 Uhr gestern nacht), aber nur unter Windows Update, nicht aus dem Catalog.

      • Fritz sagt:

        Zumindest hatte wohl noch keiner Zeit, die KB zu aktualisieren. Neben einem STATUS_BAD_IMPERSONATION_LEVEL beim Cluster-Rename sind weder in der deutschen noch in der englischen KB bekannte Probleme aufgelistet.

        Wenn ich MS übrigens richtig verstanden habe sitzt auf der Telemetrie eine KI, die so etwas entscheiden kann wie "Upps, 50% der upgedateten DCs rebooten – dann stoppen wir mal den Rollout". Vermutlich hat sich bei MS noch kein Mensch (ja, so was aus Fleisch und Blut – falls es das dort noch gibt) die Geschichte angeschaut.

  37. dr-tiger sagt:

    Folgendes konnten wir beobachten:
    2 DCs 2012R2 (Gesamtstruktur 2012R2 mit KB5009624) rebooten sofort, sobald ein Mount-Befehl von Linux aus auf ein Synology-NAS (AD connected) abgesetzt wird.
    Dies ist auch der Fall, wenn ein neues Synology NAS ohne Anbindung an die AD im Netzwerk auftaucht (Inbetriebnahme).

    • MOM20xx sagt:

      das würd mich jetzt nicht grossartig wundern. womöglich haben all jene, die keine probleme haben mit den patches, ntlm komplett im netz deaktiviert.

      weil speziell C:\Windows\system32\msv1_0.DLL ist für ntlm zuständig. und soweit ich gesehen habe haben durch die patches die dateien keine andere version gehabt als wie nach dem rollback. sprich andere komponenten dürften wohl was aufrufen lassen, dass dann unschön ist.

  38. Manuel K. sagt:

    Das Fatale ist auch das mit Veröffentlichung der Sicherheitsupdates sicher auch eine weltweite Coding-Challenge für den ersten passenden Wurm gestartet sein dürfte.
    Und die ja nicht ganz unwichtigen Domänencontroller lassen ja nun nicht absichern.
    Der Kollateralschaden vom Kollateralschaden sozusagen

    • 1ST1 sagt:

      Ja, und am Ende reicht eine Email-Bombe mit einem präparierten Office-Dokument, was dann von einem ahnungslosen Benutzer geöffnet wird, um den HTTP-Wurm loszutreten, oder auf dem anderen Weg an Domainadmin-Rechte zu gelangen.

      • Robert sagt:

        Leute, bleibt mal locker.
        Der 'Wurm' bezieht sich nur auf die HTTP Geschichte und betrifft nur 2022er Server und nur 2019 Server, wenn Letztere (2019) das Feature nutzen, ist nicht per default auf dem 2019er an. Könnt ihr sehen, ob ihr den Registry-Key auf dem 2019er habt – DWORD registry value "EnableTrailerSupport" if present under: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters, wenn da nix ist, seid ihr mit dem 2019er auch SAFE. :)
        Und die meisten werden wohl noch keinen 2022er produktiv haben (kann mich auch irren).
        Aber ihr habt recht, das mit dem Veröffentlichen regt mich auch jedesmal furchtbar auf :(
        Vielleicht kann ja auch Hr. Born noch was dazu sagen, bzw. ob ich dies richtig sehe.

  39. MOWCJ sagt:

    DANKE lieber Günter, ich hatte noch manuell updates umgestellt nach dem Lesen im Forum (Pflichtlektüre nach Update Day), blöderweise war eine GPO gesetzt die das bei W2012R2 gesetzte overruled…
    *BAM* am nächsten Morgen.
    Besagter Fall tritt ein mit den Reboots. Konnte mich mit den pstools aus dem Schneider bringen und das Update per cmd line deinstallieren mit nachfolgendem ewigen Reboot.

    Puh, schnell noch den Kopf aus der Schlinge gezogen!
    Wieder einmal aus die Maus mit Automatic Updates!

    LG

  40. 1ST1 sagt:

    Meine Buschtrommeln hin zu alten Kollegen (großer Dienstleister und MS-Partner) hat jetzt ergeben, dass Micrsoft scheinbar sich morgen (oder heute Nacht unserer Zeit) zu dem Problem äußern wird. Die ex-Kollegen waren gestern und heute auch nur am Rotieren, weil die Hütte an allen Ecken und Enden brannte. Eine Umgebung, in der ich auch mal administriert habe, ist quasi komplett abgefackelt, weil dort der umsichtige Update-Admin des Kunden ohne Prüfung und ohne mal im Internet nach Erfahrungsberichten wie hier kurz hintereinander alle DCs aktualisiert hat. So einen ähnlichen Brüller hat der sich schonmal geleistet, als ich da noch selbst war.

    • Günter Born sagt:

      Gibt hier ja einen Kommentar, der den Technical Account Manager (TAM) referenziert:

      Root cause is with code incorrectly referencing the file type for the hvloader Win2k12 R2 servers running on UEFI platform will see this regression while BIOS machines will not see this regression.

      Bei hvloader dürfte es die hvloader.efi betreffen, eine Komponente von Windows. We will wait and see – ich schaue voraussichtlich nochmals die Nacht, ob es Milch gegeben hat.

  41. Markus Eb sagt:

    Es wirkt so, als hätte Microsoft die Updates zurückgezogen.

    Wir haben einige Server 2016 und 2019 im Einsatz, auf einigen Hosts und VMs steht das Kumulative 2022-01 Update in Windows Update direkt (ohne WSUS) plötzlich nicht mehr zur Installation bereit.

    Allerdings nicht auf allen. Ich hab dann 2 Server testweise neugestartet. Der Neustart hat auf einem System dazu geführt, dass das Update nicht mehr sichtbar war, am anderen jedoch schon noch..

    Hat jemand ähnliche Erfahrungen oder gibt es Infos von Microsoft dazu?

  42. 1ST1 sagt:

    Und die nächste brennende Hütte, für alle, welche Defender als AV einsetzen. Jeder Benutzer kann aus der Registy die Werte für Scan-Ausnahmen auslesen:

    https://www.bleepingcomputer.com/news/security/microsoft-defender-weakness-lets-hackers-bypass-malware-detection/

    Hier im Selbstversuch auf dem Privat-Notebook:

    C:\Windows\System32>reg query "HKLM\Software\Microsoft\Windows Defender\Exclusions" /s

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Defender\Exclusions\Extensions
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Defender\Exclusions\IpAddresses
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Defender\Exclusions\Paths
    C:\Program Files\NirSoft REG_DWORD 0x0
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Defender\Exclusions\Processes
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Defender\Exclusions\TemporaryPaths

    Ob man NirSoft vertrauen kann, will ich hier garnicht diskutieren.

  43. Holger sagt:

    Hallo zusammen,

    wo findet man denn weitere Informationen wie es nun weitergehen soll?

    Im MSRC findet man z.B. zu Windows 2012 R2 und dieser Problematik keine weiteren Informationen oder bekannte Probleme:
    https://support.microsoft.com/de-de/topic/11-januar-2022-kb5009624-monatliches-rollup-23f4910b-6bdd-475c-bb4d-c0e961aff0bc

    Hier kann ich das Update auch noch runterladen, also kann es ja "noch nicht ganz" zurückgezogen worden sein.

    Wir haben die Updates nun nur für Clients und ein paar Testserver ausgerollt.

    Wie handhabt ihr die aktuelle Situation?

    • MSwie? sagt:

      Ja, da hat man echt Skrupel, die Rechner mit unausgegorenen Patches zu ruinieren!
      Ich würde erstmal nur die Win10 Clients mit Updates versorgen, falls man kein L2TP VPN bei denen einsetzt. In einem ersten Testlauf bei uns, verhalten sich die Clients nicht abnormal.
      Bei den Servern würde ich noch das WE abwarten und schauen, was Microsoft nun macht.

      • Holger sagt:

        genauso haben wir es auch gemacht.

        – Erst Testgruppe ca. 20 Rechner, alles scheint ok.
        hier sind auch unkritische Member Server enthalten und derzeit ok
        – nun Rollout auf alle Clients.

        Die anderen Server lassen wir dann erstmal "mit ungutem Gefühl" ohne Updates stehen.

        patchen = wahrscheinlich kaputt, nicht patchen = unsicher

        Wasch mich aber mach mich nicht nass :-(

        Sehr unschön

    • Fritz sagt:

      Immerhin gestehen sie dort das Hyper-V-Problem ein: "After installing this update on a device by using Unified Extensible Firmware Interface (UEFI), virtual machines (VMs) in Hyper-V might not start."

      Man "untersucht". 😣

      Bei uns sind die Clientupdates nur in der Testgruppe freigegeben, die für die Server stehen explizit auf "entfernen" – wobei sie außer auf zwei Testmaschinen noch nicht ausgerollt sind.

  44. Masine sagt:

    Servus,

    meine Beobachtung aktuell:
    ungeimpft = ohne updates ,geimpft = Stand 12/21, geboostert Stand 01/22

    Testumgebung: Hyper-V 2016 core (ungeimpft)
    2x 2012 DC (geboostert)
    3x 2012 Member SQL, Daten etc… (geimpft)
    1x 2012 Exchange 2013 (geimpft)

    DC + Member laufen stabil ohne Probleme

    Problem: sobald der Exchange hinzugeschaltet wird, fliegen die DC´s zwischen 8 und 10 Minuten ab und das ganze in Endlosschleife.

    wird Exchange angehalten dann laufen wieder alles Server normal.

    Frage: könnte es sein da bei einigen die Updates problemlos laufen diese keinen Exchange betreiben?

    und bei denen wo die DC´s bootschleifen machen….. Exchange mal anhalten?…dann hätte man auch Zeit um die Updates zu deinstallieren!?

    MFG

  45. OlliBo sagt:

    Dank des Berichtes überprüfe ich gerade unsere Kunden AD-Server. Auffällig dabe ist, dass bei Win Server 2019 KB5009557 verantwortlich ist und bei Win Server 2012R2 ist es KB5009624. Bei der Deinstallation von KB5009624 ist zuwenig Zeit, daher klappt das bei uns nur über den abgesicherten Modus (F8). Bei der Deinstallation von KB5009557 war bisher in der Desktopumgebung genug Zeit gewesen. Zum Glück wurden die Updates von einigen Servern noch nicht durchgeführt, sodass ich diese Updates rechtzeitig ausblenden konnte. Hoffentlich kommen von MS nicht noch weitere Überraschungen ;-)

  46. notimportant sagt:

    In meiner Testumgebung booten die DCs seltsamerweise alle nur eimalig ca. um 23:40 Uhr seit den Updates mit dem lsass-Stoppfehler 0xc0000005 durch. VMs (auf vollgepatchtem 6.7 ESXi) als auch Bare-Metal. Dann laufen sie allerdings 24 Stunden weiter ohne Probleme. Die sind quasi unverändert out-of-the-box Version 2022, mit allen monatlichen Updates. Nur die Out-of-the-Bands hatte ich nicht eingespielt…

  47. RevolutionX sagt:

    Hallo Zusammen, hatte die Win Server 2019 KB5009557 auf 4 DC´s (2 Standorte) wieder deinstalliert nach Bootloop (inkl. ausblenden und Updates pausieren). Jetzt grade 4 Tage später haben alle 4 DC´s GLEICHZEITI! mit dem lsass.exe 0xc0000005 Fehler einmal neu gestartet.

    Hab jetzt sicherheitshalber auch alle anderen Updates von 12.1 deinstalliert. Hat einer von euch etwas ähnliches beobachtet bzw. eine Erklärung dafür?

  48. Roland sagt:

    Hallo zusammen
    Ich war letzte Woche auch konfrontiert mit diesem Problem bei einem Kunden (2012 R2 in VMWare). Der Kunde hat 4 virtuelle Server in der VM. Somit bin ich auf einen anderen Server gegangen, habe dort mit der Diensteverwaltung Kontakt zum DC aufgenommen, geduldig gewartet bis der DC gerade ansprechbar war, und dann den Anmeldedienst auf dem DC deaktiviert. Nach dem nächsten Neustart des DC konnte ich dann in aller Ruhe das Update deinstallieren, den DC neu starten und den Anmeldedienst wieder aktivieren.
    Falls es jemandem hilft…

  49. Phil sagt:

    ADFS-Problem
    Hallo zusammen.
    Ich habe nach installation von KB5009557 auf einem ADFS-Farm-Server folgendes Problem.
    Der ADFS-Farmserver konnte keine LDAP Abfragen zu einem DC in einem anderen Forst (one-way trust) mehr machen.
    EventID 325
    Microsoft.IdentityServer.Service.IssuancePipeline.CallerAuthorizationException: MSIS5007: The caller authorization failed for caller identity Domain\User for relying party trust example.com. —> Microsoft.IdentityServer.ClaimsPolicy.Language.PolicyEvaluationException: POLICY0018: Query 'SAMAccountName={0};Attribute_X' to attribute store 'examle.local' failed: 'The supplied credential is invalid.

    Nachdem ist den Patch deinstalliert hatte, funktionierte es wieder.

    Der Patch wurde auf keinem DC installiert, nur auf einem ADFS-Farmserver.

  50. Anonymous sagt:

    Die Netzwerkkarte im Hyper-V trennen hilft, Server hochfahren, Update deinstallieren. Traurig sowas.

  51. Christoph sagt:

    Ist das Thema eigentlich gelöst ?
    Frage mich, ob man denn nun die Februar Updates installieren kann …

Schreibe einen Kommentar zu MOM20xx Antworten abbrechen

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.