[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:
Anzeige
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
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?
Anzeige
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.
Habe akut das gleiche Problem…
Hatte das gleiche Problem, konnte den Fehler beheben, indem ich im abgesicherten Modus die Sicherheitsupdates deinstalliert abe
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?
nein. auch server 2019 oder server 2012 oder server 2019 als Domain Controller sind davon betroffen. Da heisst es dann andere KBs wieder zu deinstallieren
Es stand doch im Text, dass auch Server 2016/2019 betroffen sein kann – habe jetzt noch eine Zwischenüberschrift eingefügt, dass es klarer wird.
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
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.
Warum WSUS, sind bei dir auch nicht DCs betroffen?
Er hat die KBs auf dem WSUS-Server zur Verteilung an andere Server deaktiviert. Der WSUS-Server an sich wird keine Probleme haben.
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?
das ist vermutlich eine GPO ich nehme an ihr habt "Neustart immer automatisch zur geplanten Zeit durchführen" aktiviert, hier kann man Minuten angeben…
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)
Bei uns hat das Deaktivieren der Netzwerkverbindung geholfen. Danach war das Zeitfenster deutlich größer.
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.
Wir haben zwei DCs mit 2012 R2. Einer mit Desktop, einer mit Core Installation. Beide DCs sind gleichermaßen betroffen.
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.
VM hart abschalten, danach hatte ich beim Hochfahren genug Zeit für die Deinstallation. Obwohl die Tipps meiner Vorredner weniger invasiv sind :)
Im abgesicherten Modus deinstallieren hat bei mir funktioniert
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. 💖🧡💛💚💙💜🤎🖤💗
Weltklasse! :o) *lach
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
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.
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.
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.
Bei Windows Server 2016 war KB5009546 zu deinstallieren, damit die Neustarts aufhören.
Bei uns geht es los alles geht down…2016 er Masterdomäne und reserve um 12 Uhr herum
Frage: in der Zeit bis zur obigen Boot-Loop _ kann man da jetzt drucken ?
;-)
YMMD
Böse Frage, nächste Frage! :-)
Ich sage mal so: "Ja, aber nur, wenn Freitag der 13. auf einen Samstag fällt". Zum Drucken schreibe ich ggf. noch was.
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
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.
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 ;)
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….
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
Problem tritt auch auf bei Server 2022 mit KB5009555
also Vorsicht!
Viele Grüße
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…
tritt scheinbar nur auf denn der DC ein Hyper-V Gast ist.
nein, meine Testumgebung ist virtualisiert.
Auch eine zweite Umgebung, 2016/2019, Funktionslevel 2016, Virtualisiert hat zumindestens was den 2019ziger angeht keine Probleme.
Hyper-V oder was anderes ?
Tritt auch bei physikalischen DCs unter 2012R2 auf.
@Work: 5 DCs (davon einer physikalisch, der Rest ESXi). Alle Server 2016er. Keiner hat das Problem
@Home: 4 DCs, alle Server 2019. Einer virtualisiert mit VMWare Workstation, drei virtualisiert auf Hyper-V. Keiner hat das Problem.
Der Hyper-V Host (Server 2022): kein Problem beim Starten von VMs
Scheint also nur unter recht speziellen Bedingungen Probleme zu verursachen. Spannend wäre natürlich: welche ;)
tritt auch bei einer 2022er VM im proxmox auf
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
Interessant aber wieviele DC doch auf virtuellen Umgebungen betreiben. Empfiehlt MS nicht stark physisches Blech? oO
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…
Ich habe beides :) Blech und virtuell. Die Diskussion hatte ich schon öfters. Aber ich bin ein Verfechter von mindestens 1x Blech DC :)
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.
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 :-)
ja ist mir auch aufgefallen, hab mir schon gedacht wird das noch was :)
Hatte ich auch ca 30min
Habe ich jetzt schon gute 45min. :\
Ungefähr 30 Sekunden nach absenden des Posts war dann der Server auch oben, dennoch ziemlich genau 45 Minuten, bei der die Deinstallation auf 100% stand und einen Core vollständig ausgelastet hat.
Danke für den Hinweis, man ist ja eh schon nervös und ungeduldig und denkt sich daß der Uninstall nicht klappt, und wer dann reset macht… game over!
Be patient! Auch bei W2012R2 braucht es etwas Zeit.
Etwas ist gut. Meiner war auch ca. 30 Minuten in dem Modus. Anmelden per RDP ging aber witzigerweise schon etwas früher…
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
Das habe ich aber auf 2019er Servern ohne AD die nur Fileserver sind auch schon ein paar Mal gesehen!
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.
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.
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?
Zwei physische 2019er DCs aktualisiert ohne Probleme.
Mit den virtuellen warte ich dann erstmal noch ab….
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
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.
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?
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!
Wie sieht es mit 2016er Server aus?
Hast du da auch einen?
Wird da das Update noch angeboten?
Gruß Stefan
Ja, habe ich auch :)
…dort ist auch nur noch das .NET Framework Update und das Software Removal Tool unter Windows Updates, wenn man jetzt sucht. Das kumulative Januar Update für 2016 ist auch weg.
Komisch. Via WSUS werden die Updates (z.B. KB5009546) weiterhin angeboten.
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.
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.
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.
@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?
Bei unserem WSUS hat sich nichts verändert. Ich sehe z.B. KB5009546 immer noch. Das Update wird auch weiterhin via Microsoft Update Catalog angeboten (https://www.catalog.update.microsoft.com/Search.aspx?q=KB5009546).
KB5009557 ist auf unserem WSUS/SCCM noch aktiv (Revision 200).
Allerdings habe ich jetzt die Bereistellung für diesen Monat für die DCs gelöscht.
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?
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).
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.
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 ;)
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?
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.
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.
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.
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?
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.
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.
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.
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.
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.
tritt auch mit level 2016 auf
Tritt definitiv auf bei 2016er-Level auf.
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:
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.
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?
@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.
@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)..?
@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.
@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 ;-)
@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.
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…
Genau dieses Verhalten habe ich hier gestern auch beobachten können:
https://www.borncity.com/blog/2022/01/12/windows-server-januar-2022-sicherheitsupdates-verursachen-boot-schleife/#comment-120137
2012R2 PDC heruntergefahren, SDC hat sofort mit den Reboots aufgehört.
Eine Vermutung zu dem warum habe ich indes noch nicht.
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.
Hab nochmal die Monitoring-Daten durchgeschaut und muss korrigieren: Auch Domain-Controller ohne zusätzliche andere Services hatten das Problem.
Nein, das kann nicht stimmen (zumindest nicht generell). In einer Test-Umgebung mit nur 1 DC ist das Problem bei uns auch aufgetreten.
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.
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.
Haben diese zurückgezogen (denke so gegen 23:00 Uhr gestern nacht), aber nur unter Windows Update, nicht aus dem Catalog.
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.
Das mit der KI kann natürlich nur funktionieren, wenn die rebellischen Benutzer nicht frecherweise die böseböse Telemetrie abwürgen…
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).
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.
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
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.
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.
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
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.
Gibt hier ja einen Kommentar, der den Technical Account Manager (TAM) referenziert:
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.
Nein, irgendwie denke ich das nicht.
Meine W2012R2 sind BIOS und keine UEFI.
Mal abwarten.
Der hvloader ist doch Teil des Hyper-V, wenn ich mich nicht irre…
Würde das Hyper-V Problem erklären, aber nicht, warum die DCs in eine Boot-Orgie verfallen.
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?
Steht doch oben, ab einer Uhrzeit wurden diese zurückgezogen. Deshalb habe ich auch manche Server die diese nicht gezogen hatten.
Vorhin noch nicht, jedenfalls auf unserem WSUS waren sie vorhin noch da, nur eben Freigabe von uns zurückgezogen. Aber gut, man lässt ja einen WSUS auch nicht alle paar Minuten neu syncen…
Sie haben es getan!!!
https://www.bleepingcomputer.com/news/microsoft/microsoft-pulls-new-windows-server-updates-due-to-critical-bugs/
Alle Server-Updates vom Janaur 2022 zurück gezogen!
Krass.
Ich hoffe, da bekommt der eine oder andere Verantwortliche im Qualitätsmanagement in Redmond einen Tritt in den Allerwertesten. Falls es solche Leute da überhaupt gibt, ich hab da momentan so meine Zweifel.
Und die Entwickler müssen jetzt Tag und Nacht durcharbeiten, bis ein fehlerfreies* Update vorliegt.
*als ob es das jemals gäbe…
"Tritt in den Allerwertesten" ?
Lieber lebenslanges Computer-Verbot…
Das ist richtig irre.
Ich verstehe auch nicht wieso die Updates noch im Katalog resp. Im WSUS/SCCM
KB5009586 für Windows Server 2012 (ohne R2) haben Sie wohl vergessen. Das wird noch fleißig angeboten.
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.
Nächster Grund für süße Träume:
https://www.bleepingcomputer.com/news/security/magniber-ransomware-using-signed-appx-files-to-infect-systems/
Was ist diese Tage bloß los?
Danke, hatte es bereits gesehen – mal schauen, wann ich Zeit finde …
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?
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.
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
Treffend auf den Punkt gebracht, Holger
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.
Beachte Microsoft Patchday-Probleme Jan. 2022: Bugs bestätigt, Updates zurückgezogen? – mittlerweile am Artikelende verlinkt.
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
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 ;-)
Trenne die Netzwerkverbindung – dann sollte laut Rückmeldung von Lesern mehr Zeit zur Deinstallation vorhanden sein.
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…
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?
Schau dir mal den Kommentar hier im englischen IT-Blog an. Der musste die Driver Signature Enforcement Feature deaktivieren, um einen BSOD zu verhindern. Bin aber nicht sicher, ob es auch bei dir zutrifft.
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…
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.
habe noch das dazu gefunden: https://www.blackvoid.club/windows-january-update-problems-kb5009557-kb5009546-kb5009555/
Die Netzwerkkarte im Hyper-V trennen hilft, Server hochfahren, Update deinstallieren. Traurig sowas.
Ist das Thema eigentlich gelöst ?
Frage mich, ob man denn nun die Februar Updates installieren kann …
Es gibt diesen Kommentar, dass es weiter Probleme geben kann.