6
Windows Server 2008 r2 Terminalserver auf ESXI stürzt ab
Hallo zusammen,
ich habe seit längerer Zeit folgendes Problem. Unser Terminalserver (ca. 10 User) stürzt nach längerem Betrieb (ca. 2-3 Monate) ab. Es handelt sich um einen Server 2008r2 mit Office 2007 und weiterer Software wie Beispielsweise Branchensoftware, welcher auf einem ESXI 5.5.0 läuft. Diese VM ist zurzeit die einzige aktive VM auf dem Host. Leider ist in den Log Files weder auf dem Terminalserver selbst noch im ESXI etwas verdächtiges zu finden. Was allerdings im ESXI zusehen war ist, dass bei einem Absturz die CPU Auslastung der VM in der Anzeige vom ESXI Server auf 100% steht. Aus diesem Grund gehen ich fast schon davon aus, dass der Fehler vom Terminalserver selbst kommt.
Zur Hardware:
ThinkServer RD330
1 x E5-2407 (4 Kerne)
49 GB RAM
VM(Terminalserver):
vCPU (4 Kerne)
20GB Ram
Netzwerk: VMXNET 3
Schon mal vielen Dank vorab
ich habe seit längerer Zeit folgendes Problem. Unser Terminalserver (ca. 10 User) stürzt nach längerem Betrieb (ca. 2-3 Monate) ab. Es handelt sich um einen Server 2008r2 mit Office 2007 und weiterer Software wie Beispielsweise Branchensoftware, welcher auf einem ESXI 5.5.0 läuft. Diese VM ist zurzeit die einzige aktive VM auf dem Host. Leider ist in den Log Files weder auf dem Terminalserver selbst noch im ESXI etwas verdächtiges zu finden. Was allerdings im ESXI zusehen war ist, dass bei einem Absturz die CPU Auslastung der VM in der Anzeige vom ESXI Server auf 100% steht. Aus diesem Grund gehen ich fast schon davon aus, dass der Fehler vom Terminalserver selbst kommt.
Zur Hardware:
ThinkServer RD330
1 x E5-2407 (4 Kerne)
49 GB RAM
VM(Terminalserver):
vCPU (4 Kerne)
20GB Ram
Netzwerk: VMXNET 3
Schon mal vielen Dank vorab
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 298742
Url: https://administrator.de/forum/windows-server-2008-r2-terminalserver-auf-esxi-stuerzt-ab-298742.html
Ausgedruckt am: 12.04.2025 um 19:04 Uhr
6 Kommentare
Neuester Kommentar
Hmmm, war da nicht mal was, daß ein Terminalserver jeden Tag bzw. jede Nacht einen Neustart kriegen sollte? Bin mir ziemlich sicher, daß das zumindest noch bis vor ein paar Jahren so empfohlen wurde.
Außerdem:
Wie überstehst Du bei 2-3 Monaten permanenter Laufzeit den mtl. Patchday bzw. den damit zumeist notwendigen Reboot?
Abhilfe:
cmd-Skript schreiben: shutdown.exe /r
im Aufgabenplaner jede Nacht laufen lassen (natürlich zu einer Uhrzeit, wo weder Betrieb noch Backup, falls vorhanden, gestört werden).
Viele Grüße
von
departure69
Erst einmal vielen Dank für die Antwort. Um ehrlich zu sein wäre das, nachdem ich heute noch einmal über die Aussage des Kunden nachgedacht habe auch mein Vorschlag gewesen (es handelt sich um den Terminalserver eines Kunden). Das einzige was mich etwas stutzig gemacht hat ist, dass der Server zum Zeitpunkt des Absturzes eine CPU Auslastung von 100% hat und überhaupt nicht mehr reagiert. Das seltsame ist, dass der Server ansonsten auch nach längerer Betriebszeit Problemlos läuft.
Verstehe.
Ich vermute aber stark, daß dies genau die Effekte sind, die nach längerer Laufzeit eines Terminalservers auftreten (z. B. dauerhafte 100 % CPU-Auslastung ohne erkennbaren Grund).
Wenn man bedenkt, daß ein TS eigentlich in seiner Funktion gar kein Server ist, sondern eher ein riesiger Client, auf dem viele Nutzer gleichzeitig arbeiten, wundert es nicht, daß hier ein Reboot öfter als nur alle paar Monate mal nicht nur gut tut, sondern schlichtweg einfach häufiger notwendig ist.
Bei meinem ehem. AG waren ca. 15 TS im Einsatz, pro Server ca. 20-25 User, und die wurden wirklich jede Nacht neu gestartet. Selbst dann, wenn nur wöchentlich neu gestartet wurde, ergaben sich unter der Woche merkwürdige Fehler, für die nie eine Erklärung gefunden werden konnte. Somit also Reboot jede Nacht.
Bei Deinem Kunden sind's jetzt nur 10 User, vielleicht hält der Server nur deshalb überhaupt solange durch, aber ich würde hier 2 Fliegen mit einer Klappe schlagen und zumindest einmal im Monat, am besten nach dem Patchday jeden zweiten Dienstag, einen per Taskplaner geplanten Reboot einlegen, dann sollte Ruhe sein.
Viele Grüße
von
departure69
Ich vermute aber stark, daß dies genau die Effekte sind, die nach längerer Laufzeit eines Terminalservers auftreten (z. B. dauerhafte 100 % CPU-Auslastung ohne erkennbaren Grund).
Wenn man bedenkt, daß ein TS eigentlich in seiner Funktion gar kein Server ist, sondern eher ein riesiger Client, auf dem viele Nutzer gleichzeitig arbeiten, wundert es nicht, daß hier ein Reboot öfter als nur alle paar Monate mal nicht nur gut tut, sondern schlichtweg einfach häufiger notwendig ist.
Bei meinem ehem. AG waren ca. 15 TS im Einsatz, pro Server ca. 20-25 User, und die wurden wirklich jede Nacht neu gestartet. Selbst dann, wenn nur wöchentlich neu gestartet wurde, ergaben sich unter der Woche merkwürdige Fehler, für die nie eine Erklärung gefunden werden konnte. Somit also Reboot jede Nacht.
Bei Deinem Kunden sind's jetzt nur 10 User, vielleicht hält der Server nur deshalb überhaupt solange durch, aber ich würde hier 2 Fliegen mit einer Klappe schlagen und zumindest einmal im Monat, am besten nach dem Patchday jeden zweiten Dienstag, einen per Taskplaner geplanten Reboot einlegen, dann sollte Ruhe sein.
Viele Grüße
von
departure69
Alles klar dann werde ich das die Tage mal einrichten und den TS dann noch mal über einen etwas längeren Zeitraum testen.
Viele Grüße
alex456
Viele Grüße
alex456
Hallo alex456
ich kenne (seit 1993 mit Citrix) WTS als einen sehr stabilen und zuverlässigen Serverdienst. Ich habe WTS (2008R2 und 2012R2) mit bis paralellel 300 Usern (Spitzenlast) bis runter zu kleinen 5 Mann WTS Servern in unregelmäßigen Abständen zur Wartung (Admin on Demand). Wir haben eigentlich keinerlei AutoRestart im Einsatz, ABER icinga welches uns Statistiken über CPU/RAM Verbrauch überwacht. Ebenso ist Autologoff erst nach 30h aktiv, sprich da sammelt sich schon viel Müll (Zombies) an. Es ist nicht ungewöhnlich das eine App sich aufhängt, klassisch Word, IE, Flash oder was auch immer und dann auf 100% SingleThread Last gehen. Bei 48 Kernen ist das für den User nicht wirklich sichtbar, teils wird dann einfach Appx beendet und neu gestartet, wodurch das Problem schon schnell bei dir erklärbar ist. Der w2k8R2 Kernel ist nicht schlecht, aber ohne Trapinfo/kerneldump schwer im Detail nachvollziehbar.
Was ICH machen würde:
-AutoReboot (bei Trap) deaktivieren (sofern du schnell genug dran sein kannst) oder Memdump aktivieren und dann im Falle auswerten.
-Regelmäßig Updates fahren und damit regelmäßige Wartungsfenster nutzen.
-RAM/CPU Überwachung über eine kleine Zusatz VM (nagios oder icinga) damit er dir hängende Tasks mitteilt
bis auf ein wenig CPU/Netzlast kommt da nichts auf dich zu und du kriegst Probleme recht früh mit um sie dann automatisch (icinga=>pskill)
oder manuell zu killen.
-Den vmxnet3 hast du wegen dicker Netzwerkanbindung (>1GBit) im Einsatz? Ansonsten gehe ich immer den Weg der E1000 oder gleich E1000E. Die Treiber werden direkt von M$ zertifiziert
-Evtl. die Berechtigung der User überdenken
Über eine simple forkbomb (da reicht die cmd.exe schon voll aus) kriegst du auch Treiber irgendwann dazu einen NMI auszulösen
Gruß
Sam
ich kenne (seit 1993 mit Citrix) WTS als einen sehr stabilen und zuverlässigen Serverdienst. Ich habe WTS (2008R2 und 2012R2) mit bis paralellel 300 Usern (Spitzenlast) bis runter zu kleinen 5 Mann WTS Servern in unregelmäßigen Abständen zur Wartung (Admin on Demand). Wir haben eigentlich keinerlei AutoRestart im Einsatz, ABER icinga welches uns Statistiken über CPU/RAM Verbrauch überwacht. Ebenso ist Autologoff erst nach 30h aktiv, sprich da sammelt sich schon viel Müll (Zombies) an. Es ist nicht ungewöhnlich das eine App sich aufhängt, klassisch Word, IE, Flash oder was auch immer und dann auf 100% SingleThread Last gehen. Bei 48 Kernen ist das für den User nicht wirklich sichtbar, teils wird dann einfach Appx beendet und neu gestartet, wodurch das Problem schon schnell bei dir erklärbar ist. Der w2k8R2 Kernel ist nicht schlecht, aber ohne Trapinfo/kerneldump schwer im Detail nachvollziehbar.
Was ICH machen würde:
-AutoReboot (bei Trap) deaktivieren (sofern du schnell genug dran sein kannst) oder Memdump aktivieren und dann im Falle auswerten.
-Regelmäßig Updates fahren und damit regelmäßige Wartungsfenster nutzen.
-RAM/CPU Überwachung über eine kleine Zusatz VM (nagios oder icinga) damit er dir hängende Tasks mitteilt
bis auf ein wenig CPU/Netzlast kommt da nichts auf dich zu und du kriegst Probleme recht früh mit um sie dann automatisch (icinga=>pskill)
oder manuell zu killen.
-Den vmxnet3 hast du wegen dicker Netzwerkanbindung (>1GBit) im Einsatz? Ansonsten gehe ich immer den Weg der E1000 oder gleich E1000E. Die Treiber werden direkt von M$ zertifiziert
-Evtl. die Berechtigung der User überdenken
Über eine simple forkbomb (da reicht die cmd.exe schon voll aus) kriegst du auch Treiber irgendwann dazu einen NMI auszulösen
Gruß
Sam
war das ein Bluescreen im Gast oder ein Absturz im ESXi?
Ich hab nur einmal ein esx Absturz gesehen und das war GPU Passthrogh mit einer Grafikkarte die offiziell nicht supported war.
Kann im Übrigen auch ein Problem mit der Kühlung der CPU sein, ist mir auch schon mal vorgekommen
Ich hab nur einmal ein esx Absturz gesehen und das war GPU Passthrogh mit einer Grafikkarte die offiziell nicht supported war.
Kann im Übrigen auch ein Problem mit der Kühlung der CPU sein, ist mir auch schon mal vorgekommen
