12
Terminalserver starten willkürlich neu
Hallo zusammen
ich hoffe, ihr könnt mir ein paar Denkanstösse geben, in welche Richtung ich ermitteln soll.
Umgebung: Citrix Xenapp 6.5 Farm mit 9 Terminalservern, alle Win 2k8R2, identischer Patchstand.
Problem: aus irgend einem Grund starten die Terminalserver (jeweils nur einer) willkürlich neu, die User welche
per Receiver darauf verbunden waren fliegen logischerweise raus.
Die Ereignisanzeige gibt m.E. nicht viel brauchbare her.
Die zwei letzten Fehler im Systemlog vor dem Neustart (Daten anonymisiert):
Und dann noch Schannel-Fehler, Ereignis-ID 36887
im Anwendungslog findet sich absolut gar nichts, was damit im Zusammenhang stehen könnte.
Habt ihr Ideeen, wie ich das Problem eingrenzen könnte?
Wir führen bereits Listen, welcher User auf welchem TS eingeloggt ist, um daraus evtl. Schlüsse zu ziehen.
Grüsse
Thomas
ich hoffe, ihr könnt mir ein paar Denkanstösse geben, in welche Richtung ich ermitteln soll.
Umgebung: Citrix Xenapp 6.5 Farm mit 9 Terminalservern, alle Win 2k8R2, identischer Patchstand.
Problem: aus irgend einem Grund starten die Terminalserver (jeweils nur einer) willkürlich neu, die User welche
per Receiver darauf verbunden waren fliegen logischerweise raus.
Die Ereignisanzeige gibt m.E. nicht viel brauchbare her.
Die zwei letzten Fehler im Systemlog vor dem Neustart (Daten anonymisiert):
Eine Kerberos-Fehlermeldung wurde auf
Anmeldesitzung empfangen:
Clientzeit:
Serverzeit: 9:36:3.0000 8/16/2017 Z
Fehlercode: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Erweiterter Fehler: 0xc0000035 KLIN(0)
Clientbereich:
Clientname:
Serverbereich: DOM.LOCAL
Servername: MSSQLSvc/server.dom.local:1433
Zielname: MSSQLSvc/server.dom.local:1433@DOM.LOCAL
Fehlertext:
Datei: 9
Zeile: f0a
Die Fehlerdaten stehen in den Berichtdaten.Es wurde eine schwerwiegende Warnung empfangen: 20.im Anwendungslog findet sich absolut gar nichts, was damit im Zusammenhang stehen könnte.
Habt ihr Ideeen, wie ich das Problem eingrenzen könnte?
Wir führen bereits Listen, welcher User auf welchem TS eingeloggt ist, um daraus evtl. Schlüsse zu ziehen.
Grüsse
Thomas
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 346448
Url: https://administrator.de/contentid/346448
Ausgedruckt am: 24.11.2024 um 13:11 Uhr
12 Kommentare
Neuester Kommentar
Dein Snippet lässt mich glauben, dass auf der Büchse ein SQLAgent läuft, der sich versucht mit seinem Server (Zeile 10) zu verbinden und dabei diese
Kerberosmeldung generiert.
Geh mal bitte mit erhöhten Rechten in die Kommandozeile des Servers und hack mal ein:
shutdown /?
Am unteren Ende werden etwaige Gründe für Shutdownevents von der Mühle aufgelistet.
Was steht da so alles?
Kerberosmeldung generiert.
Geh mal bitte mit erhöhten Rechten in die Kommandozeile des Servers und hack mal ein:
shutdown /?
Am unteren Ende werden etwaige Gründe für Shutdownevents von der Mühle aufgelistet.
Was steht da so alles?
Hi
ich glaube eher nicht, dass der Kerberos-Fehler für einen Neustart verantwortlich ist.
Habe ein bisschen zurückgeschaut im Log, den haben wir schon länger.
an SQL-Komponenten ist da nur der "Microsoft SQL Server 2012 Native Client" installiert.
shutdown /?
ich glaube eher nicht, dass der Kerberos-Fehler für einen Neustart verantwortlich ist.
Habe ein bisschen zurückgeschaut im Log, den haben wir schon länger.
an SQL-Komponenten ist da nur der "Microsoft SQL Server 2012 Native Client" installiert.
shutdown /?
Gründe auf diesem Computer:
(E = erwartet U = unerwartet P = geplant, C = benutzerdefiniert)
Typ Haupt Neben Titel
U 0 0 Anderer Grund (nicht geplant)
E 0 0 Anderer Grund (nicht geplant)
E P 0 0 Anderer Grund (geplant)
U 0 5 Anderer Fehler: System reagierte nicht mehr
E 1 1 Hardware: Wartung (nicht geplant)
E P 1 1 Hardware: Wartung (geplant)
E 1 2 Hardware: Installation (nicht geplant)
E P 1 2 Hardware: Installation (geplant)
E 2 2 Betriebssystem: Wiederherstellung (geplant)
E P 2 2 Betriebssystem: Wiederherstellung (geplant)
P 2 3 Betriebssystem: Aktualisierung (geplant)
E 2 4 Betriebssystem: Neukonfigurierung (nicht geplant)
E P 2 4 Betriebssystem: Neukonfigurierung (geplant)
P 2 16 Betriebssystem: Service Pack (geplant)
2 17 Betriebssystem: Hotfix (nicht geplant)
P 2 17 Betriebssystem: Hotfix (geplant)
2 18 Betriebssystem: Sicherheitspatch (nicht geplant)
P 2 18 Betriebssystem: Sicherheitspatch (geplant)
E 4 1 Anwendung: Wartung (nicht geplant)
E P 4 1 Anwendung: Wartung (geplant)
E P 4 2 Anwendung: Installiert (geplant)
E 4 5 Anwendung: Reagiert nicht
E 4 6 Anwendung: Instabil
U 5 15 Systemfehler: Abbruchfehler
U 5 19 Sicherheitsproblem
E 5 19 Sicherheitsproblem
E P 5 19 Sicherheitsproblem
E 5 20 Netzwerkkonnektivität getrennt (nicht geplant)
U 6 11 Stromversorgungsfehler: Kabel entfernt
U 6 12 Stromversorgungsfehler: Umgebung
P 7 0 Herunterfahren von Legacy-API
Zitat von @beidermachtvongreyscull:
Geh mal bitte mit erhöhten Rechten in die Kommandozeile des Servers und hack mal ein:
shutdown /?
Am unteren Ende werden etwaige Gründe für Shutdownevents von der Mühle aufgelistet.
Geh mal bitte mit erhöhten Rechten in die Kommandozeile des Servers und hack mal ein:
shutdown /?
Am unteren Ende werden etwaige Gründe für Shutdownevents von der Mühle aufgelistet.
Moin,
also ich kenn' diesen Befehl nur als "zeigt die Shutdown Hilfe" an.
Gruss
Bitte schau mal in die Windows Ereignisanzeige.
Log: SYSTEM
EVENTID: 1074
In der Annahme, dass die Mühlen nicht virtualisiert sind, schau auch bitte in die Logs der BoardmanagementController der Server.
Manchmal läuft ein Watchdog mit der, wenn er vom Betriebssystem keinen "Heartbeat" mehr empfängt, das Betriebssystem hart resettet und das Blech durchbootet.
Ergänzung:
Du kannst auch mittels Powershell die Events auslesen:
Get-EventLog System | Where-Object {$_.EventID -eq "1074" -or $_.EventID -eq "6008" -or $_.EventID -eq "1076"} | ft Machinename, TimeWritten, UserName, EventID, Message -AutoSize -Wrap
Mach das Fenster dann aber groß genug.
Log: SYSTEM
EVENTID: 1074
In der Annahme, dass die Mühlen nicht virtualisiert sind, schau auch bitte in die Logs der BoardmanagementController der Server.
Manchmal läuft ein Watchdog mit der, wenn er vom Betriebssystem keinen "Heartbeat" mehr empfängt, das Betriebssystem hart resettet und das Blech durchbootet.
Ergänzung:
Du kannst auch mittels Powershell die Events auslesen:
Get-EventLog System | Where-Object {$_.EventID -eq "1074" -or $_.EventID -eq "6008" -or $_.EventID -eq "1076"} | ft Machinename, TimeWritten, UserName, EventID, Message -AutoSize -Wrap
Mach das Fenster dann aber groß genug.
Danke,
Zur ID 1074 kommt da ganz viel, zur gleichen Zeit (01:30). Aber das ist soweit korrekt, da wir jeden Tag um 01:30 alle TS neu booten (Citrix-Richtlinie).
Die TS sind virtualisiert.
Event ID 6008 sagt auch nur "Das System wurde zuvor am 15.08.2017 um 11:39:49 unterwartet heruntergefahren".
Das weiss ich auch selber :p
Zur ID 1074 kommt da ganz viel, zur gleichen Zeit (01:30). Aber das ist soweit korrekt, da wir jeden Tag um 01:30 alle TS neu booten (Citrix-Richtlinie).
Die TS sind virtualisiert.
Event ID 6008 sagt auch nur "Das System wurde zuvor am 15.08.2017 um 11:39:49 unterwartet heruntergefahren".
Das weiss ich auch selber :p
Die 6008 deutet sehr auf Watchdog hin.
Virtualisiert Ihr auf VMware?
Noch was:
Habt Ihr nur einem VHost?
Liegt die neugestartete VM nachher auf einem anderen VHost?
Welche Version von VMWare habt Ihr?
Virtualisiert Ihr auf VMware?
Noch was:
Habt Ihr nur einem VHost?
Liegt die neugestartete VM nachher auf einem anderen VHost?
Welche Version von VMWare habt Ihr?
ja, wir virtualisieren auf ESX 6.5, 6 Hosts (DL380 Gen9).
Die neugestartete VM bleibt auf dem gleichen Host.
Die neugestartete VM bleibt auf dem gleichen Host.
Schau mal bitte die Vmware.Log der entsprechenden Maschine zum Zeitpunkt ihres Neustarts.
Ich nehme an, dass da ein Kernel Panic drinsteht.
Die 6.5 hat ne Macke mit Terminalservern.
Hier ein Workaround, falls Du mit Updates vorsichtig sein willst.
https://recommender.vmware.com/solution/SOL-12310
Ich hab das bei mir auch machen müssen.
VM runterfahren
Die vmx der entsprechenden TS runtergeladen,
die folgende Zeile eingetragen:
guest_rpc.rpci.usevsocket = "FALSE"
gespeichert, hochgeladen, VM gestartet und Ruhe seit dem.
Ich nehme an, dass da ein Kernel Panic drinsteht.
Die 6.5 hat ne Macke mit Terminalservern.
Hier ein Workaround, falls Du mit Updates vorsichtig sein willst.
https://recommender.vmware.com/solution/SOL-12310
Ich hab das bei mir auch machen müssen.
VM runterfahren
Die vmx der entsprechenden TS runtergeladen,
die folgende Zeile eingetragen:
guest_rpc.rpci.usevsocket = "FALSE"
gespeichert, hochgeladen, VM gestartet und Ruhe seit dem.
ookay, vielen Dank!
ich schau mir das an und melde mich!
ich schau mir das an und melde mich!
Hi
ich habe mir die Logs von den letzten zwei neugestarteten Maschinen geholt.
Wie in deinem Link beschrieben, sollte im Log das Wort "Panic" auftauchen - tut es aber nicht.
Gemäss Windows-Eventlog war der Neustart kurz vor 12 Uhr (Kernel-Power Eintrag um 11:59).
Zur gleichen Zeit wurde im vmware.log der entsprechenden Maschine das protokolliert:
Was denkst du, könnte das hier etwas sein? https://communities.vmware.com/thread/514949
Deutet aber eher auf die Netzwerkkarten hin (unsere sind E1000 Adapter im esx)
ich habe mir die Logs von den letzten zwei neugestarteten Maschinen geholt.
Wie in deinem Link beschrieben, sollte im Log das Wort "Panic" auftauchen - tut es aber nicht.
Gemäss Windows-Eventlog war der Neustart kurz vor 12 Uhr (Kernel-Power Eintrag um 11:59).
Zur gleichen Zeit wurde im vmware.log der entsprechenden Maschine das protokolliert:
2017-08-16T11:44:42.432Z| vcpu-0| I125: GuestRpc: Channel conflict: guest application toolbox-dnd tried to register, but it is still registered on channel 1
2017-08-16T11:52:08.699Z| vmx| I125: GuestRpc: Got error for channel 3 connection 115120: Remote disconnected
2017-08-16T11:57:17.371Z| vcpu-0| I125: GuestRpc: Channel conflict: guest application toolbox-dnd tried to register, but it is still registered on channel 1
2017-08-16T12:04:52.508Z| vmx| I125: Guest: toolbox-dnd: Version: build-4449150
2017-08-16T12:05:43.820Z| vcpu-0| I125: GuestMsg: Too many channels opened.
2017-08-16T12:05:43.820Z| vcpu-0| I125: GuestMsg: Too many channels opened.
2017-08-16T12:07:54.383Z| vmx| I125: Guest: toolbox-dnd: Version: build-4449150
2017-08-16T12:07:59.549Z| vmx| I125: Guest: toolbox-dnd: Version: build-4449150Was denkst du, könnte das hier etwas sein? https://communities.vmware.com/thread/514949
Deutet aber eher auf die Netzwerkkarten hin (unsere sind E1000 Adapter im esx)
Ich bin immer noch der Meinung, der Trigger kommt von außen...
Dein Fehlerbild ist aber ein anderes. Kein Panic...
Du kannst meinen oben beschriebenen Vorschlag aus meiner Sicht dennoch mal umsetzen, meine ich.
Nur weil das Bild anders ist, muss der Auslöser nicht unterschiedlich sein.
Alternativ schau mal hier: https://communities.vmware.com/thread/514949
Der Thread scheint zu Deinem Fehlerbild zu passen.
Dein Fehlerbild ist aber ein anderes. Kein Panic...
Du kannst meinen oben beschriebenen Vorschlag aus meiner Sicht dennoch mal umsetzen, meine ich.
Nur weil das Bild anders ist, muss der Auslöser nicht unterschiedlich sein.
Alternativ schau mal hier: https://communities.vmware.com/thread/514949
Der Thread scheint zu Deinem Fehlerbild zu passen.
