ACHTUNG: Windows Update Januar 2022 legt Server lahm

[#1]

Hallo Community,

Heise und andere berichten, dass die jüngst veröffentlichten Microsoft-Updates massive Folgen haben können. Teils geraten Server in endlos Boot-Schleifen und Hyper-Vs lassen keine Anmeldung mehr zu.

https://www.facebook.com/groups/IDAeV/permalink/931586004148663/

Also sollte man erst man warten, bis neue Infos kommen.

[#2]

Genau diese ständigen wackligen Updates mit mehr oder weniger auffälligen Bugs sind die eigentliche Geißel bei der Systemwartung..... 

Wichtige Warnung (auch wenn hier wahrscheinlich ein diffuses Bild vorherrschen wird und nicht grundsätzlich alle DCs betroffen sein werden - denke doch, das eine Minimalprüfung bei MS stattfindet)!!!

Hier muss man - glaube ich - auch darauf hinweisen, dass solche Bugs nicht zwangsweise bei der Datev-Prüfung auffallen müssen (die Prüfen ja primär ihre eigenen Programme)...

Die Abwägung zwischen Sicherheitslücken und Systemfunktion ist immer spannend ....

Auch deshalb sind wir mittlerweile in die Cloud ...

Dennoch allen viel Erfolg beim Updaten

[#3]

Danke für den Hinweis.

Wie gut das so manch 2016er Server draussen eh keine Updates mehr zieht, weil er sowieso in einer Update-Fehlerschleife hängt. Printnightmare, ewige Exchange-Lücken, LOGj4 und UO Stammdaten geht auch nicht.. SmardCard rein/raus weil SiPa Rot und Browser Cache löschen. MediaMarkt / Saturn Probleme mit Lagerbeständen im Webshop und weiss der Geier was...

Was ist den los zur Zeit? AB einschalten und ab ins Bett.

[#4]

Lieber Herr @Michael-Renz, 

jetzt muss ich also selber den Artikel bei www.heise.de herausuchen, weil Sie einen Screenshot eingefügt haben und einen facebook-Link? 

Das können Sie besser 😉. 

Manuel 👨 hat für mich bei Google gesucht 😜: Sicherheitsupdates vom Januar 2022 mit massiven Kollateralschäden in Windows

[#5]

Und die Beschreibung unterstreicht meine pessimistische Vermutung, dass die SW-Buden heute ihre eigene Software kaum noch zu verstehen scheinen.... die Komplexität scheint eine natürliche Grenze zu erreichen, wenn man sich die Häufung dieser Fehler ansieht.

M.E. muss hier abgerüstet werden und nicht alles in allen Richtungen unterstützt werden.

[#6]

Hallo @metalposaunist,

Hier der heise-Link: https://www.heise.de/news/Sicherheitsupdates-vom-Januar-2022-mit-massiven-Kollateralschaeden-in-Windows-6325265.html?wt_mc=rss.red.ho.ho.atom.beitrag.beitrag

Jetzt, da ich „nachgeliefert“ habe, dürfen Sie sich auch revanchieren !

Ob‘s gut war, kann ich nicht beurteilen. Jedenfalls war’s nicht unbeabsichtigt. Die IDA-Facebook Gruppe gibt jeden Werktag morgens gute Tipps und Hinweise für DATEV-Anwender und freut sich auch über einen 👍 von Ihnen.

PS: habe einen virtualisierten 2016 Terminalserver upgedatet - es lief problemlos! Ist evtl. ein Zufallsergebnis, wollte das aber nicht vorenthalten!

[#7]

Ich hatte das Problem gestern auch schon bei einem DC gelöst. Ging an einem 2012R2 wie folgt.

Warten bis Server startet, dann anmelden.

Eingabeaufforderung oder Powershell öffnen.

Folgende Dienste stoppen:

net stop ntds /Y
net stop netlogon /Y
net stop dhcp /Y

Danach ca. 10-30 Sekunden warten und netlogon wieder starten.

net start netlogon

betroffenes kb deinstallieren mit:

wusa /uninstall kb:5009624

Neustart des Servers. 

Das dauert dann ca. 20 Minuten und es ist wieder alles ok.

[#8]

Danke für den Tip!

Also "Feuer frei" sobald Verträglichkeit gegeben?!

[#9]

Datev bestätigte die Verträglichkeit mit Datev-Programmen, gibt aber auch einen Hinweis auf das hier diskutierte Thema.

https://www.datev.de/web/de/service/antworten-finden/systemplattform/microsoft-updates/

Klare Ursachen wurden noch nicht beschrieben, kann also problemlos laufen oder halt auch nicht ...

Also bleibt es eine Gewissensfrage und dann ggf. Glücksspiel ob der DC endlos bootet nach einigen Minuten Laufzeit

oder nicht...

[#10]

Ich warte mal noch bis nach dem Wochenende - vielleicht konkretisiert sich das Problem etwas. Baustellen gibts auch so genug.

[#11]

Bei uns sind alle Server-Updates installiert (gestern) und bislang keine Problem (ausschließlich Server 2016 im Einsatz).

[#12]

Hallo zusammen,

wir haben Windows Server 2019 als Fileserver in einer Fileserver-Client-Umgebung, kein TS.

Ich habe letzten Freitag bevor ich die Datev-Jahreswechselversion installiert habe, das Update 5009557 installiert, welches zunächst keine der genannten Probleme gezeigt hat.

Allerdings ist mir gestern eher zufällig aufgefallen dass der Arbeitsspeicher (32 GB) zu etwa 90% ausgelastet ist. Ich habe da mal nachgeschaut, weil der Server lauter arbeitet als gewöhnlich. Echte Performanceprobleme sehe ich aber derzeit nicht.

Ich habe dann gestern abend das Sonderupdate 5010791 installiert, der die Probleme des Januar-Patchday beheben soll. Heute sehe ich wieder eine Auslastung von knapp 90%, welches sich über der Zeit aufgebaut haben muss.

Mir fällt im Task-Manager nichts auf dem ersten Blick auf was das verursachen könnte.

Hat jemand vielleicht das gleiche Problem?

[#13]

Auf dem Fileserver läuft dann ja der SQL-Dienst bzw. die Datenbank. SQL zieht sich meistens immer so viel Arbeitsspeicher wie zur Verfügung steht, sofern keine Begrenzung hinterlegt wurde.

Im Task-Manager wird der Arbeitsspeicher aber dem SQL-Dienst nicht zugewiesen. Habe ich schon öfters gesehen - eventuell ein Anzeige-Bug?

[#14]

---

@pascal_duennebacke schrieb:

Habe ich schon öfters gesehen - eventuell ein Anzeige-Bug?

---

Microsoft SQL Server (DATEV): Maximal nutzbaren Arbeitsspeicher einstellen Punkt 4

Und gerne abstimmen: direkte Verlinkung in einzelne Unterkapitel Das hätte es Dir @pascal_duennebacke einfacher gemacht und Du müsstest nicht scrollen 😉.

[#15]

Hallo,

ich denke nicht dass es der SQL-Server ist, und ich möchte daran auch nicht herumschrauben. Die RAM-Werte für den SQL-Server sind in meinen Augen auch völlig normal.

Ich habe gerade nochmal reingeguckt, weil der Server wieder laut geworden ist, die Festplatten waren stark am Arbeiten (weil er nun auslagern muss), der Arbeitsspeicher ist zu 95% voll.

Im Task-Manager steht, nach Verbrauch des Arbeitsspeichers sortiert, der Domänennamensserver ganz oben mit einem Verbrauch von 815 MB. Ich weiss allerdings nicht ob es vorher auch schon war. Aber der DNS-Server hat ja im Update eine grosse Rolle gespielt.

Was mir seitdem auch aufgefallen ist dass das Symbol des Lima-Servers im Laufe der Zeit verschwunden ist (das ist mir letzte Woche vor dem erwähnten Neustart auch aufgefallen) - was aber auf unser Arbeiten im Netz mit Datev keinerlei Auswirkungen hat.

[#16]

Hi,

---

@Gelöschter Nutzer schrieb: ich denke nicht dass es der SQL-Server ist, und ich möchte daran auch nicht herumschrauben. Die RAM-Werte für den SQL-Server sind in meinen Augen auch völlig normal.

---

Der Taskmanager schaut hier leider nur eine Sache des SQL an. Nämlich die RAM-Last für den Programmcode. Die RAM-Last für den SQL-Cache sieht der Taskmanager nicht. 

Was aber der Taskmanager sehr wohl sieht, ist dass der RAM zu >90% ausgelastet ist.

Das Verhalten des SQL ist aber gut und richtig. Wie hoch die RAM-Last durch SQL-Cache tatsächlich ist, können Sie über den SQL-Manager prüfen. Hier bitte das Dokument 1013653 nutzen, welches @metalposaunist schon verlinkt hat.

Evtl. würde der ProzessExplorer aus den Sysinternals mehr zeigen, das habe ich aber noch nicht getestet.

LiMa: Ja, das Systray-Symbol ist bei ein paar Anlagen auch schon weg gewesen. Der Dienst lief aber und Lizenzen wurden auch ausgeteilt. Ist also kein Grund zur Beunruhigung.

Beste Grüße
Christian Ockenfels

[#17]

Nachtrag:

---

@Gelöschter Nutzer schrieb: ich denke nicht dass es der SQL-Server ist, und ich möchte daran auch nicht herumschrauben. Die RAM-Werte für den SQL-Server sind in meinen Augen auch völlig normal.

---

Virtuelle Maschine mit zugewiesenen 32GB RAM. RAM-Last gesamt bei 96% belegt.

Taskmanager für SQL-Server:

Die dort ausgewiesenen 700 MB müssten bei Ihnen auch anliegen... 

Prozess-Explorer der Sysinternals:

Aha...  29GB für den SQL als "Private Bytes" und die gesehenen 700 MB im "Working Set".

DATEV-SQL-Manager:

Und hier die Bestätigung, dass die 29GB von dem SQL genutzt werden...

Beste Grüße
Christian Ockenfels

[#18]

Seit der Version 14 (so glaube ich) hatte unser früherer Fileserver (32 GB) auch alles an Speichercache genommen, was als freier Speicher so da war. Alle anderen Anwendungen wurden damit aus dem Cache verdrängt und fühlten sich sehr träge an. Wenngleich das mit der Einstellung "Seiten im Arbeitsspeicher sperren" ( DATEV Hilfe-Center, Dok.-Nr. 1005594) schon sei Version 13 bestand (und bei uns auch aktiv war), hat dies bei uns erst seit der 14 extreme Auswirkungen gehabt. Interessant, dass es hier mit der 15 losging....

Vielleicht ist die automatische Speicherverwaltung nicht mehr so zuverlässig?

PS: Auf unserem File-Server waren nur DC und DHCP-Server ohne weitere Datev-Programme (außer dem File-Server - Datev-Standardumfang).

[#19]

@Gelöschter Nutzer 

die interne Windowsdatenbank läuft auch über den SQL, sollte auf dem betroffenen Server der WSUS Dienst betrieben werden hat die Kiste eine lange Zeit mit hoher Auslastung durch die Updates zu kämpfen und zeigt die Last auch im Bereich SQL. Wenn die Updates "durch" sind ist nach einiger Zeit Ruhe. Hier 2019 und 2012R2 ohne die Reparaturpatches und zum Glück keine Probleme.

[#20]

Vielen Dank an alle! Sieht so aus als ob ich mir da keine Sorgen machen müsste.

@chrisocki ist sogar ein Tick weniger bei uns. Vielen Dank für die Darstellung.

@münster  kein WSUS installiert.

[#21]

Hi,

---

@münster schrieb: die interne Windowsdatenbank läuft auch über den SQL,

---

Korrekt, in diesen Fällen bin ich dazu übergegangen mit dem SQL-Managment dem SQL (WSUS) einen Max-RAM-Wert von 8GB zuzuweisen. 

Den SQL (DATEV) belasse ich in den Standard-Einstellungen. Der darf und soll sich nehmen, was er bekommen kann.

Auf den "alten" Small-Business-Servern" war das mit den Max-Werten elementar. Dort musste man auch den Exchange noch eingrenzen, damit die Kiste halbwegs vernünftig zu betreiben war. DATEV, WSUS, Exchange, SharePoint und das bei 32GB... furchtbar... 

Beste Grüße
Christian Ockenfels

[#22]

@chrisocki 

Wieviel RAM kann der SQL eigentlich verarbeiten?

Wir haben nur eine Instanz, also immer noch maximal 128gb (außer wir Lizensieren selbst)?

Hab dem SQL 82% max RAM gegeben.. 5% verbrauchen - normalerweise - die anderen Dienste. 13% Puffer... so sollte nie etwas am Anschlag laufen.

[#23]

@Gelöschter Nutzer 

Ja, der Standard kann bis 128GB.

Das sollte eigentlich auch ausreichend sein. In meiner vorherigen Wirkungsstätte (Kanzlei-Vollzeitadmin) haben wir tatsächlich einen zweiten Server hinzugenommen um den kompletten Workload zu verteilen. Nicht nur wegen RAM, sondern auch wegen der Dateitransaktion, CPU-Lasten, etc. 

Ob es was bringt, kann man nur schwierig messen. Das subjektive Gefühl der Anwender ist sowieso immer "zu langsam..."   😉

Windows bzw. der SQL kümmern sich erfahrungsgemäß schon ganz gut um die Max-Werte. Im Regelfall braucht es hier keine Eingriffe mehr. Das war halt unter SBS schon deutlich anders.

Wenn es die Umgebung dann noch hergibt, dass mal den DATEV-FS von anderen Diensten (AD, DNS, WSUS, o.ä.) isolieren kann, dann ist da alles in Butter.

Beste Grüße
Christian Ockenfels