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!
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/forum/dc-rebooten-nach-januar-updates-1713495108.html
Ausgedruckt am: 25.12.2024 um 20:12 Uhr
90 Kommentare
Neuester Kommentar
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
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
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
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
Moin,
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.
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 ...
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.
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ß
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ß
Zitat von @Looser27:
war das jemals anders?
Also wieder mal wieder wir Admins mit mehrfachem Patchaufwand.
war das jemals anders?
Schon, aber nicht bei MS.
lks
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.
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.
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:
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.
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?
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.
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.
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.
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.
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.
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,
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:
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
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 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.
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.
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.
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.
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 @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.
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
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.
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.
@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
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.).
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:
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:
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.
@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......
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......
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!
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.
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.
Grüße
lcer
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:
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 .....P.S.: Erinnert mich sehr stark an den Ex-User Certified......
Wooot? Certified ist nich mehr?
Grüße
lcer
@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]
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.
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.
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.
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 ...
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 ...
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.
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
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
Hallo,
@Frank wo bleibt die Ignorierfunktion?
Grüße
lcer
Zitat von @Coreknabe:
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.
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.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.
@Frank wo bleibt die Ignorierfunktion?
Grüße
lcer
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.
@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.
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 @Coreknabe:
Wenn ich wüsste, wie man Dich beleidigen kann, würde ich es tun, ist ja scheinbar nicht so einfach bei Dir
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.
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......
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......
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.
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?
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 ...
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.
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
Viele Grüße
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
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,
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?
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 @Coreknabe:
Jupp, bekanntes Problem. Einfach laufen lassen.
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?
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.
Nach 4 Stunden immer noch?
Kunde wird langsam ungedulgig, obwohl ich ihm das gleiche geraten habe.
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?
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?
Weder noch, aber wenn Du wissen willst, was die Kiste macht, dann probiere folgendes:
Hüpf mit
psexec64.exe \\Computername cmd
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
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?
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)
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)
(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.
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.