11.01.2022

9667

DC rebooten nach Januar Updates

Moin,

und scheinbar wieder mal ein verfrühtes Osterei von Microsoft...

Habe auf unseren Servern gerade die Januar 2022-Updates installiert und dann zunächst merkwürdige Phänomene festgestellt (Netzlaufwerke ließen sich auf einigen Rechnern nicht mehr verbinden, Anmeldung an alle Server mit AD-Authentifizierung funktionieren gar nicht oder Anmeldung dauert sehr lange). Nach kurzer Suche dann bemerkt, dass alle unsere DCs immer wieder plötzlich unerwartet herunterfahren (Event ID 6008) und neu starten, dies im Minutentakt.

Unsere DCs:
2x Server 2012R2 (HyperV-VMs)
1x Server 2019 (Blech)

Mache mich dann wohl mal an die Deinstallation der Patches... Noch jemand mit diesem Problem?

Grüße!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1713495108

Url: https://administrator.de/contentid/1713495108

Ausgedruckt am: 22.11.2024 um 21:11 Uhr

90 Kommentare

Neuester Kommentar

Guten Abend,
bislang noch nicht installiert, die Sekundärsysteme bekommen die Patches morgen.
Auf den Primärsystemen lass ich mir seit jeher etwas mehr Zeit.

Gib mal kurze Rückmeldung ob die Phänomene nach Deinstallation stoppen.

Grüße

Moin,

scheint nach Deinstallation aller Januar-Updates wieder zu laufen. Ich teste das morgen (oh, ich kann das ja schon nachher machen

) noch einmal an einem DC und installiere alles wieder. Danach taste ich mich per Ausschlussverfahren an das Update heran. Vielleicht ist das schuldige Update bis dahin ja aber auch schon bekannt.

Danke an MS für dieses traumhafte Date, ich habe es sehr genossen und lege mich jetzt erst einmal ins Bett. Vielleicht läuft morgen früh ja immer noch alles

Gute Nacht!

Hallo

Habe auf beiden Windows Server 2019 Standard DCs keinerlei Probleme. Sind nur DC sonst nichts.

So long

Yumper

Hier das Gleiche,
DCs mit BSOD, nach Deinstallation wieder ok.

Zudem: Failovercluster HyperV: Livemigration hinüber.. nach Deinstallation auch wieder ok.

Dafür läuft der Exchange noch mit dem Januar-Update, immerhin.

Good N8

Moin,

Kollege Born hat auch schon eine Meldung verfasst, offenbar sind nur 2012 R2 Systeme betroffen:
https://www.borncity.com/blog/2022/01/12/patchday-windows-8-1-server-201 ...

Gruß

cykes

Zitat von @cykes:

Kollege Born hat auch schon eine Meldung verfasst, offenbar sind nur 2012 R2 Systeme betroffen:
https://www.borncity.com/blog/2022/01/12/patchday-windows-8-1-server-201 ...

Kann ich nicht bestätigen, unser 2019-DC drehte auch fröhlich seine Runden, wenn auch nicht so oft wie die 2012R2.
Vielleicht macht es aber auch die Kombi mit 2012R2.

Grüße!

Ich habe eben angefangen das Update auszurollen....allerdings erstmal nur auf den 2016er WSUS.
Gibt es schon jemanden, der die Updates auf nem 2016er DC installiert hat?

Auf 2012R2 DC installiert, bisher kein Reboot (seit 30 Minuten)

Hallo,

4 DCs 2019 - keine Reboot-Schleifen. Dafür schlägt die Storm-Control vom Switch seit gestern ständig und unerwartet zu. Außerdem ist ein Server (2019 Druckerserver, wichtiges Ding aber eigentlich nichts besonderes) nach einem Neustart über Stunden im "Windows wird vorbereitet" hängengeblieben. Kann aber Zufall sein ...

Grüße

lcer

Das Update hat auf dem 2016er WSUS auch gut 40min gebraucht....zzgl. Reboot.

Moin,

Zitat von @lcer00:
Außerdem ist ein Server (2019 Druckerserver, wichtiges Ding aber eigentlich nichts besonderes) nach einem Neustart über Stunden im "Windows wird vorbereitet" hängengeblieben. Kann aber Zufall sein ...

Das hatte ich in den letzten zwei oder drei Jahren zwei oder dreimal auch schon bei nem harmlosen 2016er Server. Hab dann die VM stumpf "zurückgesetzt". Danach startete der Server, hat die (vermutlich) noch offenen Update-Arbeiten abgeschlossen und rennt seitdem ohne murren...
Ich denke da auch eher an einen Zufall.

Zwei 2016er DCs, einmal physisch, einmal virtuell - keine Probleme.

Weitere "normale" W2K12- bzw. W2K12R2-Server (keine DCs) - ebenfalls keine Probleme.

Ui.
Dann warte ich mal ab.

Toll, einerseits soll/muss ich abwarten, ob bzw. bis wann MS hierfür den Patch zum Patch liefert?!

Und dazu passt dann diese Heise-Warnung super https://www.heise.de/news/Patchday-Trojaner-koennte-sich-ueber-kritische ...

Also wieder mal wieder wir Admins mit mehrfachem Patchaufwand.

Gruß

Also wieder mal wieder wir Admins mit mehrfachem Patchaufwand.

war das jemals anders?

Zitat von @Looser27:

Also wieder mal wieder wir Admins mit mehrfachem Patchaufwand.

war das jemals anders?

Schon, aber nicht bei MS.

lks

Interessant in diesem Zusammenhang auch dies:

https://www.reddit.com/r/sysadmin/comments/s1nybs/fsmo_domain_controller ...

Da unser 2019er-DC auch loopte, aber nicht so oft, hatte ich auch eine Ahnung, dass da irgendwas triggern könnte.

Grüße!

Danke für die Warnungen. Habe Updates nur auf Testsystem installiert, 2012R2, hochgestuft zum DC, Updates installiert, Bootschleife.

Uff... zum Glück habe ich bei Heise in die Kommentare geschaut und gleich alle Vorkehrungen getroffen. Das wird noch lustig die Woche.

Was mich nur wundert, dass dazu nichts offizielles kommt. Nichts von Microsoft, nichts von den Medien... da muss es doch jetzt zigfach krachen? Das hat mich auch schon bei meiner Sonntagsschicht beim Exchange 2022 Bug gewundert.

Mal eine Frage in den Raum geschmissen:

So wie ich das verstehe, ist es seit Server 2012 OK, wenn ich mit HyperV VM-Snapshots anlege und diese KURZE Zeit später anwende? Das wäre also in diesem Falle eine Option gewesen?

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/introduct ...

https://www.altaro.com/hyper-v/virtualized-domain-controllers-4-myths-12 ...
(Punkt 4)

Ich sehe den Punkt, dass das nicht Best Practice ist und nicht in 100% der Fälle funktionieren muss, aber notfalls habe ich Backups. Was meint Ihr?

Grüße!

Windows Server 2016 mit Exchange 2016

Keine Probleme.

Da scheinen ja wieder ein paar Kobolde am Werk zu sein.
Gerade läuft die Installation am sekundären Domaincontroller (2019) mal sehen was der mir dann so mitteilt.

Ganz lustig fand ich die Bemerkung eines Kollegen heute:

Mein PC hat mir heute Morgen angezeigt, dass Updates installiert wurden und fertiggestellt werden müssten. Das habe ich dann ausnahmsweise mal gemacht, mach ich ja sonst immer beim Herunterfahren.
Hat mich heute dann 20 min gekostet wo ich nix machen konnte, dauert das immer so lang?

Edit:
Läuft nun seit 1 Stunde ohne Neustart, also alles gut.
Der DC macht auch nur AD und DNS... Scheint also nicht generell ein Problem zu sein.

Ich habe alle 2016er Server bis auf die DCs mittlerweile gepatched. Diese laufen ohne Probleme (inkl. SQL).
Den DCs habe ich die Genehmigung für das Update erstmal weg genommen.....

So kurzes Statusupdate, da der 2019er DC ohne Probleme rannte, habe ich mich heute an die restlichen Systeme gewagt.
Wie bereits an vielen Ecken zu lesen, solang kein Domaincontroller scheint die Sache unproblematisch zu sein.
Da ich aber neben den zwei 2019er DCs auch noch zwei 2012 R2 habe, war auch hier erstmal das sekundäre System dran.
Tatsächlich sah es danach gut aus. 30 min Laufzeit und kein Reboot.
Habe dann mit dem primären DC angefangen und gerade als ich dort den Neustart eingeleitet hatte bootet auch der sekundäre DC neu.

Ende vom Lied, der sekundäre DC hat eine Laufzeit von ca. 35 min bekommen bis er sich neustartet, die Deinstallation des Updates war dort also problemlos wieder machbar.
Beim primären DC sah es anders aus, nach dem Hochfahren ist direkt Ende und er startet direkt wieder neu.
Daher dann vom Installationsmedium gestartet und über die Konsole deinstalliert...

Unterschied zwischen meinen 2019ern und den 2012R2, letztere sind Altlasten, da läuft für eine alte Umgebung noch DHCP, Fileservices, etc. etc.

Was mich ein wenig verwundert, offenbar genügt es ja das monatliche Rollup KB5009624auszulassen, aber warum dann nicht auch das KB5009595, denn das hat doch identische Änderungen nur dass es auf den Patches von 12/2021 aufbaut?
Microsoft gibt die Hinweise in beiden KB Infos an...

Bleibt wohl erstmal beobachten und im Zweifel auch das andere Update noch rauswerfen.

Eben mal ein cluster aware update auf Windows 2016 Datacenter gefahren.

4 Hyper-Vs und nur einer hat die Updates installiert. Die anderen haben sie ausgekotzt.

Soviel dazu Kollegen. Microsoft hat es in meinen Augen einfach nicht mehr drauf, sichere Updates zu bauen oder das ist deren Methode, alle in die Cloud zu bewegen: Updates für on premises Server werden stiefmüttlerlich gepflegt und der Cloud läuft alles schick, rund und sicher.

Zitat von @dertowa:
Was mich ein wenig verwundert, offenbar genügt es ja das monatliche Rollup KB5009624auszulassen, aber warum dann nicht auch das KB5009595, denn das hat doch identische Änderungen nur dass es auf den Patches von 12/2021 aufbaut?
Microsoft gibt die Hinweise in beiden KB Infos an...

Bleibt wohl erstmal beobachten und im Zweifel auch das andere Update noch rauswerfen.

So die Zweifel sind bestätigt.
Die Deinstallation von KB5009624 brachte zwar erstmal Erfolg, heute Nacht haben die beiden Systeme allerdings auch wieder neugestartet.
Faktisch fliegt nun auch KB5009595 raus.

Die Deinstallation des Updates ist doch die letzte Maßnahme, welche man durchführen kann.
Bekanntlich gibt es mehrere Gründe, weshalb die Aktualisierung nicht erfolgreich verläuft

Host OK; Update NOK
Host NOK; Update OK
Host NOK; Update NOK

Hast du einmal geprüft, ob der Host eventuell NOK ist?
Was sagt den das Log? Warum will er einen Reboot? Woran stört er sich?
Davon sehe ich hier leider nix.

Hallo,

Zitat von @148656:

Die Deinstallation des Updates ist doch die letzte Maßnahme, welche man durchführen kann.
Bekanntlich gibt es mehrere Gründe, weshalb die Aktualisierung nicht erfolgreich verläuft

Host OK; Update NOK
Host NOK; Update OK
Host NOK; Update NOK

Hast du einmal geprüft, ob der Host eventuell NOK ist?
Was sagt den das Log? Warum will er einen Reboot? Woran stört er sich?
Davon sehe ich hier leider nix.

Da hast Du vollkommen recht. Allerdings ...

Die große Unbekannte ist trotzdem das Update. Solange ich nicht im Detail weiß, was genau geändert wurde (und das steht nicht im KB-Artikel!!!), kann man bezüglich des Problems leider nur raten und experimentieren. Strukturiertes Vorgehen ist hier kaum möglich. Zumindest nicht im Produktionsbetrieb. Und Testsysteme können die Wirklichkeit meist nur begrenzt simulieren. Also bleibt hier:

durch Deinstallation der Updates kann erst einmal die Betriebsbereitschaft wiederhergestellt werden.
An einer (isolierten) Sicherungskopie des System kann man danach gerne rumspielen. Wenn man Zeit hat.
oder man wartet erst mal ab, bis seitens MS oder durch andere Nutzerberichte das Problem eingegrenzt werden kann.

Im übrigen erwecken alle die sich bezüglich der Updates hier im Forum geäußert haben (bis auf einen Userbeitrag) den Anschein, dass sie ihre System aktuell halten und durchaus gelegentlich die Logs lesen.

Juristisch gesehen wäre es zwar Aufgabe des geschädigten, den Updatefehler nachzuweisen. Wissenschaftlich gesehen, genügt aber die statistische Häufung der Fehlerberichte nach dem Januarupdate, um den Verdacht eines fehlerhaften Updates aufkommen zu lassen. Die Berichte über Fehler nach dem Update waren halt häufiger als üblicherweise erwartet (Wobei sich diese Erwartung gerade ändert

).

Grüße

lcer

Eine große Unbekannte, ist auch der Server.
Wissen wir gerade, was alles auf dem Server läuft? Wie "Es" konfiguriert ist? Ist der DC, wirklich nur ein DC mit ein bisschen hiervon, ein wenig davon?

Wir wissen jedoch, dass der Fehler nicht auf jedem DC auftritt.
Wir wissen, dass es Zyklisch ist. Alle 35 min. Also irgendein Prozess.
Wir wissen, dass Microsoft derzeit nur ein Problem bezüglich des VPNs einräumt.
Also besteht eine Wahrscheinlichkeit, dass das Update "OK" ist.

Er hat ja genügend Zeit, um sich über die "Qualitätsprüfer" zu äußern.
Genauso schnell, sind die paar Befehle zur Hostprüfung eingegeben.
Auch die Maßnahmen, zum Reparieren könnte man durchführen.
Nimmt nicht viel Zeit in Anspruch und hilft dabei, den Fehler einzugrenzen oder eine These auszuschließen.

Zitat von @148656:
Wir wissen, dass Microsoft derzeit nur ein Problem bezüglich des VPNs einräumt.
Also besteht eine Wahrscheinlichkeit, dass das Update "OK" ist.

Ach wirklich?
Microsoft aus den zwei genannten KBs:

Nach der Installation dieses Updates auf DCs (DCs) können betroffene Versionen von Windows Server unerwartet neu gestartet werden.

Hinweis: Bei Windows Server 2016 und höher ist die Wahrscheinlichkeit höher, dass Sie betroffen sind, wenn DCs Schattenprinzipale in der erweiterten Sicherheitsadministratorumgebung (Enhanced Security Admin Environment, ESAE) oder Umgebungen verwenden, die Privileged Identity Management (PIM) verwenden.

Wir suchen zurzeit nach einer Aktualisierung und werden in einer kommenden Version ein Update bereitstellen.

In meinem Fall, beide 2012 R2 (Altserver) werden für alles Mögliche missbraucht, sind also keine reinen DCs.
Die 2019er allerdings schon.
Mein privater 2019 Essentials macht allerdings (abgesehen von DHCP) auch alles und den habe ich am Wochenende ebenfalls aktualisiert - kein Problem aufgetreten.

Daher auf den Systemen Updates deinstallieren und abwarten bis Microsoft das aus den ganzen Diagnosedaten ausgewertet hat.

Zitat von @dertowa:

Zitat von @148656:
Wir wissen, dass Microsoft derzeit nur ein Problem bezüglich des VPNs einräumt.
Also besteht eine Wahrscheinlichkeit, dass das Update "OK" ist.

Ach wirklich?
Microsoft aus den zwei genannten KBs:

Daher auf den Systemen Updates deinstallieren und abwarten bis Microsoft das aus den ganzen Diagnosedaten ausgewertet hat.

Danke für die Klarstellung. Dieses ganze Bullshitgelaber von "Wir müssen das ordentlich analysieren" bringt überhaupt nix. Auch komplett sinnfrei: Die Erwartung, dass Microsoft Schadenersatz an irgendwen zahlt, wenn ihnen nur die Schuld nachzuweisen ist. Konkret: Die werden nichts zahlen, an niemanden, egal, wer was nachweist.
Aber wer genügend Zeit und Wissen hat, das alles im Detail zu analysieren und zu testen, um dann den Schluss zu ziehen, dass Microsoft nachbessern muss. Dann mal los.

Zitat von @Coreknabe:

Aber wer genügend Zeit und Wissen hat, das alles im Detail zu analysieren und zu testen, um dann den Schluss zu ziehen, dass Microsoft nachbessern muss. Dann mal los.

Wer Zeit und Wissen hat, vergeudet das nicht damit, sondern benutzt Alternativen.

lks

Zitat von @Lochkartenstanzer:

Zitat von @Coreknabe:

Aber wer genügend Zeit und Wissen hat, das alles im Detail zu analysieren und zu testen, um dann den Schluss zu ziehen, dass Microsoft nachbessern muss. Dann mal los.

Wer Zeit und Wissen hat, vergeudet das nicht damit, sondern benutzt Alternativen.

lks

Du alter Linux-Fetischist

Zitat von @Coreknabe:

Du alter Linux-Fetischist

Aus BSD und Solaris haben schöne Töchter.

lks

Ich hatte zu Beginn eines neuen Jobs noch eine SCO-Schulung. Und ein großer Burgerdealer war seinerzeit der größte SCO-Kunde, die hatten das auf ihren Kassen. Irgendwie ... undenkbar

Ansonsten HP-UX, Sinix, nix mit Windows. Ja, damals und so

Muss aber gestehen, dass mir das Rumklicken leichter fällt, auch wenn ich einige Linux-Systeme bei uns betreue.

Aber wir schweifen ab, zurück an die Ursachenforschung

Da kannst du auch noch so oft, Zeter und Mord rufen. Eine Aufgabe des Administrators ist, unter anderem, die Analyse von Störungen. 3mal zu klicken, "Geht nicht" rufen und dann die Hände in den Schoss zu legen, ist nicht die korrekte Vorgehensweise. Ich habe hier genügend Hinweise gegeben, dass man noch viel mehr machen kann, als deine "Arbeitsweise" hergibt.
Und eins ist klar, deine Art eine Frage zu stellen, entspricht nicht einmal den hiesigen Anforderungen. Da ist es auch nicht verwunderlich, dass du von einem nachgelagerten Support nie eine zielführende Antwort erhalten hast oder wirst.
Diese Punkte gehören auch in ein Ticket/Call/Case, welches man beim Hersteller eröffnet.

Die versuchten Lösungsstrategien, die nicht zu einem Erfolg geführt haben.
Evtl Fehlermeldungen der Software oder/und in Protokolldateien, gerne auch als Screenshots.

Aha.

@148656
Demnach muss ich, als Fahrzeugbesitzer demnächst eigene Analysen betreiben, um dann dem Hersteller meines Fahrzeuges mitzuteilen, dass das Klappern hinten rechts der ausgeschlagene Stoßdämpfer ist, nachdem ich selbst schon versucht habe, das Problem durch Tausch der Bremsen und der Radlager sowie festschrauben der Bremsleitungshalterungen einzugrenzen?
Gut, als Admin (=Nutzer des Systems) stünde mir per se ein Diagnosegerät (=Logfiles) zur Verfügung. Aber nur, weil ich es habe, muss ich ja nicht das ganze Auto von Kopf bis Fuß analysieren oder?
Und als Admin bin ich nicht die Fach-/ Vertragswerkstatt, denn letztere ist ein Partner des Herstellers und arbeitet im Auftrag dessen. Ich, als Admin, arbeite jedoch nicht im Auftrag von Microsoft (oder Apple, oder oder oder...)

Für gewöhnlich fahre ich als Fahrzeugbesitzer in die Werkstatt und teile mit: "Da hinten klappert es. Aber auch nur, wenn ich über Bodenwellen/ Schlaglöcher fahre." Ich teile also dem Hersteller das Symptom mit. Hier dann aber - da bin ich mit dir d'accord - so genau wie möglich. Ein "Mein Auto klappert" ist dann natürlich recht unpräzise.

Und wenn sich von 500 Fahrzeugen (Modell Golf 3.18 CLA) des Herstellers "Wolfsburger Motorenwerke" mit Sitz in Stuttgart 250 melden, dass ein Klappern hinten rechts zu verzeichnen ist, müssen sich also alle 250 Besitzer selbst um die Analyse kümmern, wenngleich WMV das einmal selbst tun kann (unter Erhalt aller identifizierten Symptome) und anschließend die Kunden informiert und einen Rückruf ausspricht...

So, genug Analogien zum Fahrzeug. Mag hier und da ein kleinwenig hinken, aber im groben und ganzen passt es, denke ich.

MS hat offensichtlich ein Problem mit den Updates, dessen Ursache man (Stand heute) noch nicht eindeutig identifiziert bzw. publiziert hat. Hilfreich wäre es natürlich, wenn man irgendwie einen gemeinsamen Nenner finden könnte. Aber auch das ist schwierig, da es - zumindest beim DC reboot - sowohl physische als auch virtuelle Server betrifft, in den Versionen Server 2012R2 bis Server 2019 (wenn ich das recht im Kopf habe). Somit ist es auch nicht an einer Hardware (Treiber) auszumachen. Auch betrifft es Standalone DCs sowie Systeme, die mehrere Dienste bereitstellen (m. W. n.).
Vielleicht haben alle Systeme gemein, dass sie an Vollmond installiert wurden!?
Keine Ahnung. MS muss Infos von Betroffenen und Nicht-Betroffenen erhalten, diese auswerten, und die Gemeinsamkeiten finden. Da man aber Telemetrie (aufgrund des Datenschutzes) deaktiviert hat, wird es etwas schwieriger für MS.

Und ich gehe davon aus, dass du, @148656, bereits deine Umgebung umfangreich an MS gemeldet hast, damit die auch diese Konstellationen auswerten können

So genug davon. Amen

Edit: Typo

Zitat von @em-pie:
MS hat offensichtlich ein Problem mit den Updates, dessen Ursache man (Stand heute) noch nicht eindeutig identifiziert bzw. publiziert hat. Hilfreich wäre es natürlich, wenn man irgendwie einen gemeinsamen Nenner finden könnte. Aber auch das ist schwierig, da es - zumindest beim DC reboot - sowohl physische als auch virtuelle Server betrifft, in den Versionen Server 2012R2 bis Server 2019 (wenn ich das recht im Kopf habe). somit ist es auch nicht an einer Hardware (Treiber) auszumachen. Auch betrifft es Standalone DCs sowie Systeme, die mehrere Dienste bereitstellen (m. W. n.).

Richtig, meine Wenigkeit hat als Endkunde 2 DCs zur Verfügung, glücklicherweise oder eher unglücklicherweise aktuell noch 4 St. (bedingt durch die Altumgebung mit 2012R2). Dazu kommt ein Essentials bei mir privat.
Alles in allem ist das aber keine ausschlaggebende Referenzumgebung.
Da wird es Systemhäuser (Partner von Microsoft) geben, welche umfangreiche Kundeninstallationen betreuen und Microsoft entsprechende Gemeinsamkeiten, Diagnosen etc. zur Verfügung stellen können.

Aber ich kann hier gern mal was vom "Extremfall" (System startet und wird direkt neugestartet) reinhauen.

ID 1000:

Name der fehlerhaften Anwendung: lsass.exe, Version: 6.3.9600.17415, Zeitstempel: 0x545042fe
Name des fehlerhaften Moduls: lsadb.dll, Version: 6.3.9600.20244, Zeitstempel: 0x61cfe060
Ausnahmecode: 0xc0000005
Fehleroffset: 0x000000000002a00d
ID des fehlerhaften Prozesses: 0x23c
Startzeit der fehlerhaften Anwendung: 0x01d80a48272e731a
Pfad der fehlerhaften Anwendung: C:\Windows\system32\lsass.exe
Pfad des fehlerhaften Moduls: C:\Windows\system32\lsadb.dll
Berichtskennung: 820355bf-763b-11ec-811d-00155d0afb04
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

ID 1001:

Fehlerbucket , Typ 0
Ereignisname: APPCRASH
Antwort: Nicht verfügbar
CAB-Datei-ID: 0

Problemsignatur:
P1: lsass.exe
P2: 6.3.9600.17415
P3: 545042fe
P4: lsadb.dll
P5: 6.3.9600.20244
P6: 61cfe060
P7: c0000005
P8: 000000000002a00d
P9:
P10:

Angefügte Dateien:

Diese Dateien befinden sich möglicherweise hier:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_lsass.exe_42cb4e8946be1ca1afadf141391c9cfbac62623_0c1f8dbe_0f18c9d7

Analysesymbol:
Es wird erneut nach einer Lösung gesucht: 0
Berichts-ID: 820355bf-763b-11ec-811d-00155d0afb04
Berichtstatus: 4100
Bucket mit Hash:

gefolgt von ID 1015:

Ein kritischer Systemprozess C:\Windows\system32\lsass.exe ist fehlgeschlagen mit den Statuscode 255. Der Computer muss neu gestartet werden.

wieder ID 1001 s.o., dann ID 16385

Fehler beim Planen des Softwareschutzdiensts für den erneuten Start bei 2121-12-22T19:44:40Z. Fehlercode: 0x800706BA.

Danach geht das Spiel von vorn los.

Das ist und bleibt Bullshit.

Zusammenfassung für mich:
- Ich sehe das Problem und "behebe" es durch Deinstallation der Updates.
- Hände in den Schoß legen. Klar, die durchgeschwitzte Nachtschicht habe ich echt genossen, gern mehr davon.
- Ich habe bei MS überhaupt keinen Ansprechpartner, dem ich Probleme dieser Art melden kann. Klar kann ich den offiziellen Weg nehmen und habe zusätzlich einige Stunden investiert.
- Es haben genügend andere dieselben Probleme wie ich. MS hat es mittlerweile auch gemerkt. Wenn ich der einzige mit diesem Problem wäre, müsste ich mehr investieren, klar.

Zusammenfassung für Dich:
- Du glänzt hier laufend mit Beiträgen, in denen Du anderen bestätigst, wie dumm sie doch sind. Ansonsten redest Du viel, sagst aber nichts.
- Du könntest ratzfatz die Ursache jeglichen Problems in Erfahrung bringen. Dummerweise hast Du keine Probleme.
- Du hast unendlich viel Zeit für Problemanalyse und sinnfreie Kommentare.
- Es heißt "Zeter und Mordio", nicht "Zeter und Mord". Allerdings kann ich bei mir beides nicht anwenden.

Zusammenfassung für alle:
- MS hat das Problem im Blick und wird Abhilfe schaffen. Hoffe ich mal.

Schönen Tach!

@Coreknabe
Genau so verstehe ich den Job von Admins. Nicht stundenlang suchen....handeln! Hängt schließlich normalerweise min. 1 Firma dran.

Wenn etwas nach dem Update nicht mehr läuft, was vor dem Update noch lief.....was ist dann wohl die Ursache? Richtig....das Update!
Aber es wird immer Leute geben, die einem den eigenen Job erklären wollen; und das, obwohl sie die Umgebung nicht mal kennen.

Just my 2 Cents.

P.S.: Erinnert mich sehr stark an den Ex-User Certified......

P.S.: Erinnert mich sehr stark an den Ex-User Certified......

Wooot? Certified ist nich mehr?

Zitat von @Looser27:

Genau so verstehe ich den Job von Admins. Nicht stundenlang suchen....handeln! Hängt schließlich normalerweise min. 1 Firma dran.

Wenn etwas nach dem Update nicht mehr läuft, was vor dem Update noch lief.....was ist dann wohl die Ursache? Richtig....das Update!

Da bin ich voll bei dir.

Aber C.Caveman kann ja nun mal alles raushauen, dafür hab ich ja mal die Logeinträge des Servers gepostet, schauen wir doch mal wie der Profi nun an die Ursachenforschung geht.
Ich bin gern bereit was dazu zu lernen und stehe gern Rede und Antwort sollten da Rückfragen sein.

Ja, in einem Auto stecken heutzutage mehr Computer wie in der Apollo 11.
Aber ein Fahrzeugführer ist kein Kraftfahrzeugmechatroniker.
Ein Administrator sollte nicht mit einem Fahrzeugführer gleichgesetzt werden.

Da es zu den Aufgaben des Administrators gehört, sich mit der Technik auseinander zu setzten.

Die junge von Microsoft kennen einen Teil unserer Umgebungen. Es gibt immer Probleme, die man nicht allein lösen kann. Aber, man kann schon viel Vorarbeit leisten. Es nennt sich nicht umsonst nachgelagerter Support und nicht First-Level für DAUs.

Hallo,

noch etwas ...

Wer basteln will, nutzt eine freie und Supportfreie Linux Distribution, und löst seine Probleme selbst, ggf. unter Zuhilfenahme der Community in den entsprechenden Foren bzw. auf Github. Wer nicht basteln will, kauft ein Betriebssystem und bezahlt Lizenzen. OK, da ist im Standard auch nur wenig Support enthalten. Aber man zahlt letztlich ja auch Geld dafür, dass man weniger Support benötig (genau deshalb hat Windows ja ein GUI). Er wenn man sich das Leben noch leichter machen will, zahlt man auch für Supportverträge mir definierten Reaktionszeiten. Das ist aber bei (Enterprice)Linux und (Enterprice)Windows ähnlich.

Nimm ein freies Linux, dann musst Du eh alles selber machen??? Nein. Wir kaufen ein aktuell unterstütztes Produkt und erwarten bestimmte Maßnahmen des Herstellers zur Qualitätssicherung.

Ansonsten könnte man die Argumentationslinie auch weiterspinnen: Oszilloskop auspacken und die Schaltkreise auf der Hauptplatine prüfen! - vielleicht liegts ja da dran.

Zitat von @Coreknabe:

P.S.: Erinnert mich sehr stark an den Ex-User Certified......

Wooot? Certified ist nich mehr?

hier zumindest nicht. Ihm hatte der automatische Melde-Reaktionsmechanismus ("Beitrage melden"-Button) den Garaus gemacht. Ist so etwas wie fail2ban für Forumuser .....

Grüße

lcer

Wooot? Certified ist nich mehr?

hier zumindest nicht. Ihm hatte der automatische Melde-Reaktionsmechanismus ("Beitrage melden"-Button) den Garaus gemacht. Ist so etwas wie fail2ban für Forumuser .....

Grüße

lcer

Vielleicht lebt der jetzt in einer Höhle. SCNR

@dertowa
Und was hast du versucht um den Fehler zu beheben?
3mal geklickt, fragendes Gesicht gemacht und dann deinstalliert?
Wie bereits geschrieben. Microsoft stellt reichlich Informationen und Lösungsansätze bereit. Schau mal in die Dokumentation und suche nach Troubleshooting.
Die sollte man im Vorfeld prüfen und die Ergebnisse sauber zusammentragen. Das hilft dem nachgelagerten Support.
Ich bin Privat hier und gebe gern Tipps. Ich bin nicht hier, um deinen Job zu machen.

[OT]
Ich fühle mich schon geschmeichelt, wenn man mich mit Herrn Enderle vergleicht.
Aber mit einer kollegialen Koloskopie kommt man bei mir nicht weiter. Da muss derjenige schon die Schuhe ausziehen und ganz reinkriechen.
[/OT]

Zitat von @148656:

Und was hast du versucht um den Fehler zu beheben?
3mal geklickt, fragendes Gesicht gemacht und dann deinstalliert?
Wie bereits geschrieben. Microsoft stellt reichlich Informationen und Lösungsansätze bereit. Schau mal in die Dokumentation und suche nach Troubleshooting.

versucht?
Sagen wir mal so: Ich bin nicht unvorbereitet an die Updates gegangen, da mir die Probleme durchaus bekannt sind.
Daher habe ich mich auch vorab mit dem "was tue ich wenn" befasst.
In produktiver Industrieumgebung ist die Prio aber ganz klar:

Muss laufen.

Da ich sowas aus freien Stücken auf ein Wochenende lege und dort meine Zeit mit arbeiten verbringe, um unnötigen Stress zu vermeiden beschränkte sich die Fehleranalyse aber auf die Fehlerbehebung.

Letztere ist/war ganz leicht, ging vor dem Update, geht nachher nicht mehr, also rückgängig...
Die Systeme "betreue" ich seit einiger ganzen Weile, habe diese aber wie sie sind übernommen. Ich weiß aus dem Systemzustand nur, dass der 2012 R2 mal irgendwann ein SBS war, der ehem. Dienstleister hat sich aber auch bei der Übergabe mit jeglichen Informationen mehr als nur bedeckt gehalten.

Da die 2012 R2 wie bereits geschrieben bei mir unter "ferner liefen" agieren und durch recht junge 2019er abgelöst werden, stecke ich dort auch nicht mehr Herzblut als nötig rein.

Die Lösungsansätze von Microsoft welche du ansprichst kann ich allerdings nicht ganz nachvollziehen, denn nachdem klar war womit ich es zu tun habe ist der Knowledgebase Artikel zu den Updates meine Anlaufstelle und da steht absolut nix, außer "under investigation":
DC rebooten nach Januar Updates
Entsprechend teile ich auch gern meine Lösung für das Dilemma:
DC rebooten nach Januar Updates

Ich bin Privat hier und gebe gern Tipps. Ich bin nicht hier, um deinen Job zu machen.

Ich werde hier auch nicht für meine Aktivität bezahlt, versuche allerdings stehts zu geben und zu nehmen.

Wenn ich dann solche Beiträge lese: DC rebooten nach Januar Updates dann gebe ich gern die Chance zu beweisen, dass da mehr dahinter steckt.

Also solltest du tiefere Einblicke in die Updates haben und eine Idee haben wie ich diese installiert bekomme, ohne dass mir die Systeme um die Ohren fliegen bitte gern.
Ob ich dem Rat dann folge beurteile ich allerdings erst danach, denn für mich steht die Aussage von Microsoft:
Wir suchen zurzeit nach einer Aktualisierung und werden in einer kommenden Version ein Update bereitstellen.

Die wertvollen Hinweise eines Administrator.de-Users haben Microsoft bei der Fehlerbehebung geholfen!

https://www.heise.de/news/Microsoft-patcht-wieder-ausser-der-Reihe-63303 ...

Hierbei der Hinweis, dass das Update nicht über den WSUS bereitgestellt wird, außer, man importiert eben jenes.

https://support.microsoft.com/de-de/topic/17-januar-2022-kb5010790-betri ...

Zitat von @Coreknabe:

Die wertvollen Hinweise eines Administrator.de-Users haben Microsoft bei der Fehlerbehebung geholfen!

https://www.heise.de/news/Microsoft-patcht-wieder-ausser-der-Reihe-63303 ...

Super, wer traut sich?

Für die Installation sind übrigens die Patches aus Dezember wichtig, die müssen installiert sein - zumindest beim 2012 R2.

Vielleicht kann unser Oberanalysator das überprüfen und dann für alle freigeben

Ich lasse die Finger von dem Mist.

Microsoft Updates haben bei einen ähnlichen Stellenwert bei mir wie Computerviren.

Ja, was will man hier Analysieren?
Schon die Bestandsaufnahme ist peinlich.
Administratoren die keinen Wert auf strukturiertes, lösungsorientiertes sowie selbstständiges Arbeiten legen. Die nur aus dem Stehgreif agieren und alles gemacht haben. Nur leider können Sie nicht mehr sagen, was es war. Somit wartet man natürlich bis eine helfende Elfe aus der Community eine Anleitung postet, die ihnen nochmal vor Augen hält, was sie gemacht haben könnten.
Ne Handvoll "Fachkräfte" die keine Updates einspielen werden. Never touch… Jaja, ob die "Jungs" noch Stützräder am Fahrrad haben?

Joar… unterm Strich, ein super Beitrag unter einer großen Überschrift, der wieder einmal keinem Administrator weiterhelfen wird. Da es nur um Microsoft-Bashing und Flaming geht.

Case Closed

Wow....soviel Arroganz in einem Beitrag. Respekt......

Zitat von @Looser27:

Wow....soviel Arroganz in einem Beitrag. Respekt......

Leistungsbefreites Selbstbewusstsein, sagt man das so? Es sei gern noch einmal auf seine sonstigen Beiträge verwiesen, sagt genug aus. Und "Case Closed" halte ich für ein Gerücht, so einer hört nicht auf.

Hallo,

Zitat von @Coreknabe:

Zitat von @Looser27:

Wow....soviel Arroganz in einem Beitrag. Respekt......

Na hoffen wir mal, dass sein Arbeitgeber ihn behält und er sich nicht umorientieren muss… Man soll immer zufrieden sein mit dem was man hat, da man nicht weiß, was man bekommt.

@Frank wo bleibt die Ignorierfunktion?

Grüße

lcer

Zitat von @Looser27:

Wow....soviel Arroganz in einem Beitrag. Respekt......

ich hab den Fokus verloren und weiß nicht so genau auf wen er sich jetzt so bezieht.
Daher weiß ich nicht ob ich nun beleidigt sein muss.

Moin,

Ein Kindergarten ist nichts dagegen. Einfach mal bei einem Single-Malt oder einem Bier ein wenig entspannen und das Ganz nicht so verbissen sehen.

Prost

lks

Prost!

Ich hätt hier einen schönen Highland Park …

Grüße

lcer

Mein Glühwein war leider leer.....

Zitat von @Lochkartenstanzer:

Moin,

Ein Kindergarten ist nichts dagegen. Einfach mal bei einem Single-Malt oder einem Bier ein wenig entspannen und das Ganz nicht so verbissen sehen.

Prost

lks

Wie in 99,567% der Fälle hast Du absolut Recht

. Eine Ignore-Funktion wäre trotzdem hilfreich, hier muss man, wohlwollend betrachtet, einen Troll annehmen.

@Coreknabe:
Du weißt aber schon, dass du dieses Thema eröffnet hast, also müsstest du mal die überarbeiteten Patches testen, damit der Thread auf gelöst gesetzt werden kann?

Ich habe für die 2012 R2 den Patch im WSUS importiert, ggf. ergibt sich heute Abend die Gelegenheit zum Einspielen.

Zitat von @dertowa:

@Coreknabe:
Du weißt aber schon, dass du dieses Thema eröffnet hast, also müsstest du mal die überarbeiteten Patches testen, damit der Thread auf gelöst gesetzt werden kann?

Ich habe für die 2012 R2 den Patch im WSUS importiert, ggf. ergibt sich heute Abend die Gelegenheit zum Einspielen.

Hallo?

Wenn ich wüsste, wie man Dich beleidigen kann, würde ich es tun, ist ja scheinbar nicht so einfach bei Dir

Ich warte noch einmal ab und werde mich wahrscheinlich morgen an einen Test machen. Bin noch etwas unsicher, ob die Reboot-Orgie nicht ein paar Stunden später doch noch zuschlägt und das Update ein weiteres Update braucht...
Ich werde aber den auch von mir befeuerten Flamewar noch erfolgreichem Test ordnungsgemäß als gelöst abschließen

Zitat von @Coreknabe:
Wenn ich wüsste, wie man Dich beleidigen kann, würde ich es tun, ist ja scheinbar nicht so einfach bei Dir

Ach es gibt so viele Formen von Beleidigung und man muss immer schauen von wem diese kommt, ggf. würde mich deine aber härter treffen, wir werden es hoffentlich nie erfahren.

Aber vielleicht war ich gestern auch so deprimiert, dass ich den Rest des Abends offline verbracht habe, sonst hätte ich ja bereits meinen Fokus auf die Windowsupdates legen können, um den Thread hier hinsichtlich der Lösung zu unterstützen.

Traurig bei der Sache empfinde ich mal wieder, dass man das Patch zum Geraderücken wieder manuell in den WSUS importieren muss. Schließlich kam das defekte Patch ja auch automatisch in den WSUS......

Zitat von @Looser27:

Traurig bei der Sache empfinde ich mal wieder, dass man das Patch zum Geraderücken wieder manuell in den WSUS importieren muss. Schließlich kam das defekte Patch ja auch automatisch in den WSUS......

Das stimmt mich umso misstrauischer und zieht diverse Fragen nach sich. Behebt das Ding die Fehler des Ursprungsupdates und das ursprüngliche Müll-Update muss trotzdem installiert sein? Nicht wirklich, oder? Ist mein System mit dem nachgeschobenen Update genauso sicher, wie es mit dem Müll-Update geplant war?

Ich mutmaße ja mögliche Nebenwirkungen. Dann erscheint es mir sinnig, wenn MS solche Patches, die im Eiltempo zusammengekloppt wurden tatsächlich (vorerst) nicht über generelle Wege ausrollt.

Scheinbar werden da immer noch neue Updates von MS nachgeschoben, ganz sicher ist man sich offensichtlich nicht:
https://www.heise.de/news/Microsoft-patcht-wieder-ausser-der-Reihe-63303 ...

Zitat von @Coreknabe:
Das stimmt mich umso misstrauischer und zieht diverse Fragen nach sich. Behebt das Ding die Fehler des Ursprungsupdates und das ursprüngliche Müll-Update muss trotzdem installiert sein? Nicht wirklich, oder? Ist mein System mit dem nachgeschobenen Update genauso sicher, wie es mit dem Müll-Update geplant war?

Ganz ehrlich?
Das ist doch nicht dein Problem.
Im Falle der 2016 und höher ist es das voll kumulative Paket, da muss nix vorher installiert sein.
Beim 2012 R2 ist es, wie ich schon geschrieben hatte, nur das Sicherheitsupdate (~81 MB), da braucht es also die Patches aus 12/2021 zur Installation.

Da es auch nur gewisse Systeme betrifft sieht Microsoft wohl eher davon ab das Update per WSUS zu verteilen.
Ich werde mich da entsprechend zurückhalten und auf den 2019ern wo der bisherige Patch problemlos läuft den neuen Patch gar nicht erst reinhauen.

Entsprechend kann ich das schon nachvollziehen, für die Server, die Probleme machen gibt es manuell eine Bereinigung, Microsoft gewinnt dadurch noch etwas Zeit und Daten um bis zum nächsten Patchday ggf. weitere Korrekturen vorzunehmen.

Also einspielen da wo es klemmt, sonst nirgends.
Hinsichtlich der Sicherheit ist man damit dann ja schon mal deutlich weiter als ohne das Update, denn es gab ja auch andere Korrekturen, welche nicht mit dem Problem zu tun hatten. ;)

Zitat von @Coreknabe:

Scheinbar werden da immer noch neue Updates von MS nachgeschoben, ganz sicher ist man sich offensichtlich nicht:
https://www.heise.de/news/Microsoft-patcht-wieder-ausser-der-Reihe-63303 ...

Ist doch nur ein Nachtrag, also die Anpassung für Windows 10 und Windows Server 1809 sowie Windows Server 2019 in KB5010791, das braucht eben ein anderes Paket als die bislang veröffentlichten.
In diesem Fall also vollkommen normal.

So, gestern Abend am sekundären 2012 R2 - DC mal den neuen Patch eingespielt.
...das war der, der erst nach >3h einen Neustart machte.

Läuft nun seit gut 8 Stunden am Stück, damit werde ich mich morgen wohl an den primären DC trauen.

Ich hab mich auch getraut und eben dem sekundären DC (2016er) das Update installiert.
Den lasse ich dann kommende Nacht mal neu starten und dann sehen wir, ob es klappt.....

Danke für die Zwischenstände, ich schaue mal, ob ich das heute noch mit dem Test schaffe. Morgen ist Freitag, da wäre es vielleicht ein wenig riskant...
Gebe in jedem Fall auch noch eine Rückmeldung!

Ich hab' gestern und vorgestern die jüngst nachgeschobenen Updates für alle Server 2012 -> 2016 eingespielt, ebenso diejenigen für W10 und W11, und keinerlei Probleme bemerkt. Hatte allerdings auch vorher, mit den regulären Patchday-Updates aus der Vorwoche, keine Probleme, auch nicht an den DCs

.

Viele Grüße

Zitat von @departure69:

Ich hab' gestern und vorgestern die jüngst nachgeschobenen Updates für alle Server 2012 -> 2016 eingespielt, ebenso diejenigen für W10 und W11, und keinerlei Probleme bemerkt. Hatte allerdings auch vorher, mit den regulären Patchday-Updates aus der Vorwoche, keine Probleme, auch nicht an den DCs

.

Viele Grüße

Da wäre es mal interessant, zu erfahren, ob es Sinn macht die neuen Updates einzuspielen, auch wenn die alten keine Probleme gemacht haben... Du hast die quasi drüberinstalliert?

Du hast die quasi drüberinstalliert?

Jup.

Angesichts dessen, daß bspw. das nachgeschobene Update für den W2K16 genauso wie zum Patchday ein Downloadgewicht von wieder mal mehr als 1 GB hatte, dachte ich mir, daß darin auch noch weiteres Neues stecken könnte, und nicht bloß die Fehlerbehebung vom Patchday. Davon abgesehen bin ich immer bestrebt, schlichtweg den neuesten verfügbaren Softwarestand auf die Server zu bringen. Deshalb führe ich solche Fehlerkorrekturupdates auch durch, wenn ich von dem Fehler gar nicht betroffen war. Denn diese jüngsten Sonderpatche waren ja keine, die man gesondert anfordern oder von Hand aus dem Katalog ziehen mußte, sondern die kamen ja per auch per regulärem WU (und schlugen deshalb auch an unserem WSUS auf, bloß eines mußte ich manuell importieren, ich glaube, das für W2K12R2).

Viele Grüße

Denn diese jüngsten Sonderpatche waren ja keine, die man gesondert anfordern oder von Hand aus dem Katalog ziehen mußte, sondern die kamen ja per auch per regulärem WU (und schlugen deshalb auch an unserem WSUS auf, bloß eines mußte ich manuell importieren, ich glaube, das für W2K12R2).

OK... Habe jetzt einmal KB5010791 für Server 2019 auf dem DC installiert und beobachte jetzt mal. Der war nicht im WSUS.

Zitat von @departure69:

Du hast die quasi drüberinstalliert?

Angesichts dessen, daß bspw. das nachgeschobene Update für den W2K16 genauso wie zum Patchday ein Downloadgewicht von wieder mal mehr als 1 GB hatte, dachte ich mir, daß darin auch noch weiteres Neues stecken könnte, und nicht bloß die Fehlerbehebung vom Patchday.

Da ist nicht mehr und nicht weniger drin als zum regulären Patchday, die 1 GB kommen zustande, da es für die Systeme nur die vollständigen kumulativen Updates gibt.
DC rebooten nach Januar Updates

Beim 2012 R2 ist eben nur Stand zwischen 12/2021 und 01/2022 enthalten, daher sind es da nur 81 MB und die waren es zum regulären Patchday auch.

Mich wundert allerdings deine Aussage, dass die Patches im WSUS verfügbar waren/sind, denn das passt nicht.
Bei mir taucht nichts von den nachgeschobenen Patches auf, egal ob Windows 10, Server 2012 R2, oder 2019.
...was auch richtig so ist, denn in den KB-Artikeln von Microsoft steht überall:

Windows Update or Microsoft Update --> Yes
Windows Update for Business --> No
Microsoft Update Catalog --> Yes
Windows Server Update Services (WSUS) --> No

P.S.: Ich würde diese Out-of-band Updates auch nicht einspielen, klar schaden wird es eher nicht, einen Vorteil sehe ich aber auch nicht, sofern man von den VPN-Problemen bei Windows oder dem DC Problem bei Server nicht betroffen war.

Moin!

Jetzt auch von mir eine Rückmeldung, gestern Morgen auf einem 2019 das Update KB5010791. Bisher keine Probleme. Gestern Abend noch für den ultimativen Nervenkitzel einen 2012R2 mit KB5010794 ausgestattet. Auch hier bisher keine Probleme, keine merkwürdigen Vorkommnisse oder Einträge in den Eventlogs.
Wenn alles so bleibt, installiere ich heute Nachmittag noch das Update auf unserem zweiten 2012R2.

@dertowa
Eine Beleidigung für Dich ist mir immer noch nicht eingefallen, aber wenn am Montag alles noch wie erwartet hinhaut, gehe ich davon aus, dass das Problem gelöst ist und ich eine entsprechende Markierung setzen werde

Vielen Dank für all die konstruktiven Beiträge hier, bei all dem ganzen Ärger hat es trotzdem irgendwie Spaß gemacht

So. Der eine DC mit dem Update läuft noch immer.....hab mal in einem Anflug von Freitag den 2. DC eben mit dem Update versorgt. Scheint alles wie gewohnt zu laufen.

Moin,

Gerade hat es einen Kunden mit Server 2019 und KB5009557 getroffen, der sich das Zeug heute reingezogen hat. Lauf Updateverlauf ist die Installation in den vergangenen Tagen die letzten drei Male schiefgegangen. Anscheinend hat er die Warnungen nicht mitbekommen.

Bin gerade am deinstallieren und schauen, ob es hilft.

lks

Edit:

Die Kiste hängt nach dem Deinstallations.Reboot seit ca 30 Minuten immer noch im

"Updates werden Verarbeitet
100% abgeschlossen
Schalten Sie den Computer nicht aus"-Modus.

Kann einer besteätigen oder dementieren, ob das bei Euch beim deinstallieren von KB5009557 auch so lange gedauert hat?

Zitat von @Lochkartenstanzer:

Moin,

Gerade hat es einen Kunden mit Server 2019 und KB5009557 getroffen, der sich das Zeug heute reingezogen hat. Lauf Updateverlauf ist die Installation in den vergangenen Tagen die letzten drei Male schiefgegangen. Anscheinend hat er die Warnungen nicht mitbekommen.

Bin gerade am deinstallieren und schauen, ob es hilft.

lks

Edit:

Die Kiste hängt nach dem Deinstallations.Reboot seit ca 30 Minuten immer noch im

"Updates werden Verarbeitet
100% abgeschlossen
Schalten Sie den Computer nicht aus"-Modus.

Kann einer besteätigen oder dementieren, ob das bei Euch beim deinstallieren von KB5009557 auch so lange gedauert hat?

Jupp, bekanntes Problem. Einfach laufen lassen.

Zitat von @Coreknabe:

Jupp, bekanntes Problem. Einfach laufen lassen.

Nach 4 Stunden immer noch?

Kunde wird langsam ungedulgig, obwohl ich ihm das gleiche geraten habe.

Also bei mir hats auch gedauert, aber "nur" etwa 10 Minuten. Wir haben allerdings auch recht aktuelle Hardware, ist der Server bei Dir älter? Für 2019 zertifiziert?

Ohne Gewähr und ungetestet, evtl. hilft es, die Netzwerkverbindung zu trennen. Könnte sein, dass da im Netzwerk eine Endlosschleife läuft.

Im Prinzip riskierst Du nen Totalschaden, wenn Du das abbrichst. Irgendwann ist es aber auch einfach sinniger, ein Backup wieder einzuspielen.

Bekannt ist das an sich aber schon:
https://www.borncity.com/blog/2022/01/12/windows-server-januar-2022-sich ...
(s. Kommentar Tom R. und folgende)

https://www.bleepingcomputer.com/news/microsoft/new-windows-server-updat ...
(s. Kommentar unclebloodyfester)

Weder noch, aber wenn Du wissen willst, was die Kiste macht, dann probiere folgendes:

Hüpf mit

psexec64.exe \\Computername cmd

auf den Rechner, der hängen geblieben ist.

Dienstabfrage mit

sc queryex trustedinstaller

Steht der Dienst im State STOP_PENDING, kannst Du ihn aus meiner Sicht so abschießen:

taskkill /PID xxxx /F

Die PID bekommst Du durch den vorangegangenen Befehl.

So mache ich das bei meinen Kisten, wenn es zu lange dauert. Bisher keinerlei Probleme.

Gruß
bdmvg

Zitat von @Lochkartenstanzer:
Nach 4 Stunden immer noch?

Salut,
wie hast du denn deinstalliert?
Ich hatte beim 2012 R2 über die Reparaturkonsole auch einiges an Wartezeit bei 100% in der Konsole zu verzeichnen.
Die Konfiguration beim Reboot ging dann aber zügig.

Da hängt also vermutlich einer.

Zitat von @Coreknabe:

Also bei mir hats auch gedauert, aber "nur" etwa 10 Minuten. Wir haben allerdings auch recht aktuelle Hardware, ist der Server bei Dir älter? Für 2019 zertifiziert?

Hardware von 2019, für Hyper-V, ordentlich ausgestattet und natürlich auch mit 2019-er Support. der fehlerhafte Server ist zum Glück nur eine VM, daß ich alles In Ruhe von zusahause aus reparieren kann.

Ohne Gewähr und ungetestet, evtl. hilft es, die Netzwerkverbindung zu trennen. Könnte sein, dass da im Netzwerk eine Endlosschleife läuft.

Zu spät, ich habe vor ca 2 h auf Kundenwunsch entschieden, einen Restore zu machen, der gerade fertig wurde. Habe nur das System "neu" gemacht, Die Datenbank und sonstige Daten auf der zweiten virtuellen Platte mal auf heitigem Stand gelassen. Kunde prüft jetzt sein Anwendungen.

Im Prinzip riskierst Du nen Totalschaden, wenn Du das abbrichst. Irgendwann ist es aber auch einfach sinniger, ein Backup wieder einzuspielen.

Das war mit schon bewußt, Aber dem Kunden kostest das auch Geld, wenn er einen ganzen Tag da drauf nicht zugreifen kann und 4 Studne warem ihm dann doch zuviel. Da hat er lieber in Kauf genommen, die Stunde Arbeit, die seine Mitarbeiter am dem System "gearbeitet" haben, nochmal machen zu lassen.

Bekannt ist das an sich aber schon:
https://www.borncity.com/blog/2022/01/12/windows-server-januar-2022-sich ...
(s. Kommentar Tom R. und folgende)

ich habe den Thread zwar überflogen, aber nicht alles gelesen.

https://www.bleepingcomputer.com/news/microsoft/new-windows-server-updat ...
(s. Kommentar unclebloodyfester)

Da war ich ich nicht. Mal nacher in ruhe die Sachen durchlesen.

Ich dachte, ich wäre auf der sicheren Seite, wenn ich den Kunden empfehle, mit den Updates zu warten, bis die Sache sich gelichtet hat. Üblicherweise warten die meisten ja, bis ich ihnen ein "go" gebe (Nichtsdestotrotz sind die alle selbst für Ihre Systeme verantwortlich, auch wenn ich sie "coache").

lks

Zitat von @dertowa:
Läuft nun seit gut 8 Stunden am Stück, damit werde ich mich morgen wohl an den primären DC trauen.

So, für den primären DC auf 2012 R2 Basis habe ich mir dann doch noch mal etwas Zeit gegönnt und ihn erst gerade mit dem neuen Patch aktualisiert.
Sieht erstmal gut aus, kein direkter Reboot und keine Fehlereinträge im Log.

Moin,

auch nach Tagen auf unseren 2012R2- / 2019-DCs keine Probleme. Installation der nachgeschobenen Updates also erfolgreich.

Ich mach hier jetzt zu

gelöst Frage Microsoft Windows Server

Mehr von Coreknabe

Zyxel Firewalls verbreiten RansomwareCoreknabe - 5 Kommentare

Exchange 2019 - Automatisches Leeren der PapierkörbeCoreknabe - 6 Kommentare

Patchday November 2024Coreknabe - 11 Kommentare

NetApp-SchulungCoreknabe - 8 Kommentare

Heiß diskutiert