RDS 2012 Schwarzer Bildschirm bei Anmeldung

[H@nnib@l 11]

Folgende TS-Umgebung:

 

10 VMs (ESXi 5.1.0):

1 x Windows 2012: Connection Broker, License Server

8 x Windows 2012:  RDS-Hosts in Sammlung "terminal" welche Sessions bereitstellen

1 x Windows 2012: RDS-Host in Sammlung "RemoteApp" welcher Applikationen bereitstellen soll

 

 

DNS-RR Eintrag "terminal" welcher auf die 8 RDS-Hosts zeigt

 

Jetzt haben wir das Problem, dass nach unbestimmter Zeit nach einem unbekannten Ereignis die Anmeldungen nicht mehr funktionieren.

Das äußert sich so, dass die User (HP ThinClients, Win7-Notebooks, Windows 2008 R2, Windows 2003) sich via RDP an "terminal" anmelden, einen schwarzen Bildschirm präsentiert bekommen und nach etwa 15-20 Sekunden der Verbindungsversuch abbricht.

 

Auf dem Terminalserver, auf welchem der Verbindungsversuch stattfindet sieht man im Eventlog lediglich, Ereignis ID 4005 Winlogon.

Eine Google-Recherche bringt nicht wirklich weiter...

 

 

Nach einem reboot funktionieren die Server wieder mind einen kompletten Tag.

Die Kollegen hatten eine tägliche Veeam-Sicherung der TS eingerichtet welche nun aber auch entfernt wurde um eine weitere Mögliche Fehlerquelle auszuschließen.

 

Das "komische" an der Sache ist, dass die Umgebung etwa 2-3 Wochen ohne Probleme lief und nun sukzessive die Fehler auftreten.

 

Die weitere Vorgehensweise wird nun sein auf vier der acht TS die Hotfixes [1] zu installieren und die Server nachts neu zu starten.

 

Die folgenden Hinweise/Artikel haben wir bereits ohne Erfolg durchgearbeitet:

http://social.technet.microsoft.com/Forums/windowsserver/en-US/e940f890-768d-489f-b6af-c7db0c1b6c02/remote-desktop-connects-to-a-black-screen

http://seanmcrawford.com/windows-82012-remote-desktop-black-screen/

 

 

Es ist sehr verwirrend da wir keinen Ansatz haben den Fehler zu reproduzieren bzw. dass er sowohl an ThinClient als auch an Fat-Clients mit unterschiedlichsten RDP-Versionen auftritt.

Der Sessionbroker erkennt dann auch nicht, dass der entspr. TS einen Fehler mit der Anmeldung hat sondern lotst weiterhin alle Clients auf den Server mit den wenigsten Verbindungen und so kommt es, dass die User in diesen black screen laufen.

 

Vielleicht hat von euch jemand weitere Ansätze?

 

[1] http://support.microsoft.com/?id=2821526

bearbeitet 23. August 2013 von H@nnib@l

[testperson 1.538]

Hi,

 

ich kenne den schwarzen Bildschirm bei der Anmeldung nur von ausgelasteten RDS Hosts. Die 10 VMs liegen die alle auf dem einen ESXi?

Sind alle Dienste gestartet auf einem Betroffen RDS Host?

Reicht es wenn man den Remotedesktop Dienst neu startet oder muss der gesamte RDS neu gestartet werden?

 

Gruß

Jan

[H@nnib@l 11]

Hi,

 

die ESXi Umgebung besteht aus 4 Hosts und die VMs sind wie folgt darauf verteilt:

- Host1: 3 VMs

- Host2: 3 VMs

- Host3: 2 VM

- Host4: 2 VM

 

Die Hosts sind alles HP DL380 G7 mit jeweils 196 GB RAM.

vmware seitig ist laut Performance-Graphs alles soweit in Ordnung (sowohl auf VM als auch auf Host-Ebene), sprich die ESX-Server langweilen sich...

 

Alle relevanten Dienste sind gestartet auf den Systemen.

 

Auf die Idee zu checken ob ein neustart des RDP-Dienstes genügt bin ich noch nicht gekommen, werde ich aber beim nächsten mal testen.

 

Danke erstmal für die weiteren Ideen/Anregungen...

[NeMiX 76]

Was für ein Storage liegt dadrunter und wie ist das Netzwerk designed? Ist zwar nach Nadel im Heuhaufen suchen, aber evtl. hilfts.

 

Hast du schon mal Wireshark geschaut was Netzwerkseitig passiert?

[testperson 1.538]

Hi,

 

wie sieht die Verteilung der vCPUs aus? Interessant wäre die CPU Ready Time..

 

Gruß

Jan

[H@nnib@l 11]

Vielen Dank für eure Ideen/Hinweise...

 

@NeMiX

 

Die RDS-VMs liegen auf einer IBM DS3524 (FC) mit einem Diskpool (3,5 TB) bestehend aus 12 x 500 GB 7,2k SAS HDDs.

In diesem Diskpool gibt es 6 LUNs mit jeweils 500GB im Raid 6 Verbund.

Auf LUN 1-5 liegen jeweils zwei der RDS-VMs.

 

Der Performance-Graph von vmware sowie des IBM Storage Managers zeigen keinen ungewöhnlich hohen IO.

Den Storage würde ich erstmal außen vor lassen...

 

Netzwerkseitig ist der betreffende vSwitch über eine Intel 82571EB Gigabit QuadPort Karte mit seinen vier Beinchen, welche alle aktiv sind, an einen Cisco GBit Switch angebunden.

Die VMs sind alle mit einer VMXNET3 NIC in das entspr. Server-VLAN verbunden.

Die Netzwerkseite habe ich noch nicht beleuchtet außer beim betrachten der Performance-Graphen auf den ESX-hosts und dort gibt es keine Anomalien.

 

 

@testperson

 

Die VMs haben jeweils 4 vCPUs aufgeteilt in 2 Sockets mit 2 Kernen.

Anbei die Charts für CPU-Ready-Time:

 

 

bearbeitet 26. August 2013 von H@nnib@l

[testperson 1.538]

Hi,

 

die CPU Ready Time der VMs wäre interessanter als die der Hosts ;)

Wieviele pCPUs haben die Hosts?

 

Generell würde ich immer sehen, dass ich VMs mit so wenig wie möglich vCPUs austatte. Bei uns gibt es eigentlich nur VMs mit 1-2 vCPUs.

 

Gruß

Jan

[H@nnib@l 11]

Natürlich die VMs  :D

 

 

 

 

 

Naja diese zwei Sockel mit jeweils einem Kern sind denke ich mal nicht wirklich oversized bzw. Performanceseitig relevant in diesem Fall...

 

Die Hosts haben jeweils 2 pCPUs (Xeon x5660) mit 6 Kernen pro CPU und aktiviertem HT (=24 logische Prozessoren)

Klar laufen auch noch div. andere VMs auf den ESX-Hosts aber die langweilen sich dennoch :)

[H@nnib@l 11]

Hi Zusammen,

 

es gibt Neuigkeiten in diesem Zusammenhang.

 

Wir können den "Absturz" der Terminalserver nun reproduzieren.

 

Und zwar stürzen die Server in Zusammenhang mit USB-Speichermedien ab welche am ThinClient (HP t510 mit aktuellstem ThinPro4 OS) angeschlossen sind.

 

Wenn beispielsweise ein USB-Medium an den ThinClient angeschlossen wird tauchen im Explorer teilweise "Systemordner" mit der Bezeichnung des USB-Speichermediums auf und nach etwa 20-30 Sekunden die entspr. Wechseldatenträger (Laufwerk H: bis L: z.B.).

 

Wird die Session nun getrennt, sei es durch "Start -> Trennen" oder durch einen Netzwerkfehler, wird es spannend.

Nach Wiederaufnahme der Session konnten wir beobachten, dass teilweise die doppelte bis dreifache Anzahl an "Systemordnern" im Explorer angezeigt werden.

Der Explorer sucht dann anschließend wieder nach den Wechseldatenträgern und findet bzw. mappt diese nicht sauber und dann ist schicht im Schacht.

Im Eventlog taucht folgender Eintrag auf:

 

Ergebnis ist, dass die Remotedesktopdienste "hinüber" sind, sprich ein Anmelden via RDP ist nicht mehr Möglich.

Ein Anmelden an der Console (via vi-client) ist auch bei einem kaputten Server Möglich, dh er reißt nicht den kompletten Server herunter sondern lediglich die Remotedesktopdienste.

Der Dienst lässt sich auch nicht einfach beenden und neustarten (weder GUI, noch net stop, noch sc, noch PoSh) sondern es ist ein Neustart Vonnöten.

 

Eingangs erwähnte ich ja, dass die Umgebung 2-3 Wochen ohne Probleme funktionierte, in diesen 3 Wochen war ein User im Urlaub welcher exzessiv einen USB-Cardreader verwendet.

 

 

Summa Summarum haben wir jetzt endlich einen Ansatz und können uns auf die strukturierte Fehleranalyse stürzen...

 

Danke nochmal an alle Helfer :)