Bei einem Kunden wurde die Firmware eines Igel Thin Clients vom Modell IZ2-RFX (D220) auf die aktuelle Version 10.05.500 aktualisiert. Leider funktionierte danach die Netzwerkverbindung nicht mehr.

Eine Fernverwaltung geschweige denn eine Anmeldung vom Thin Client am Terminalserver war nicht mehr möglich. Direkt an der Konsole des Geräts meldete das Netzwerk “no carrier”. Auf der Rückseite waren die LEDs der Netzwerkschnittstelle dunkel bzw. aus.

Bei diesem Kunden sind die Thin Clients am Switch-Port von snom 320-VoIP-Telefonen angeschlossen. Entfernte man das Telefon aus der Netzwerkverbindung, so klappte die Verbindung wieder. Offenbar vertragen sich die genannte Igel Firmware mit dem snom-Switch nicht.

Als Workaround wurde ein Downgrade der Firmware auf Version 10.03.570 durchgeführt. Damit lief zwar die Netzwerkverbindung wieder, dafür erschien nun in der RDP-Sitzung ein Laufwerk “A” das vom Thin Client umgeleitet wurde. Gewollt und konfiguriert ist das nicht. Abhilfe hierzu schaffte das globale Deaktivieren des Laufwerks-Mappings. Das geht bzw. hilft natürlich nur, wenn dieses Feature nicht genutzt wird.

Via Suchmaschine konnte ich spontan zu diesen Schwierigkeiten nichts finden. Der Support ist informiert, mal sehen was da noch kommt.

Update 30.01.2019

Vom Support kam zum Laufwerk A folgendes:

“Wenn man im Setup unter Geräte – Speichergeräte – Hotplugspeichergeräte aktiviert und die Zahl der Laufwerke auf 1 oder höher setzt, wird standardmäßig ein Laufwerk A in der Sitzung angezeigt auss man ändert den Startbuchstaben ab (darunter).

Diese Konfiguration wird dazu verwendet Massenspeicher wie USB Sticks in die Sitzung zu nehmen.”

Ich hatte zwar testweise mal einen USB-Stick angesteckt, als mir dieses Laufwerk aufgefallen ist, durchgereicht wurde dieser allerdings nicht.

Zur Firmware kam dann noch dieses:

“der Client ist leider seit dem 31.12.2017 end-of-life und end-of-maintenance. Die letzte für diesen Client freigegebene Firmware ist die 10.03.100.”

Update 04.02.2019

Das Downgrade auf die letzte supportede Firmware führte zu neuen Problemen: Grundsätzlich scheiterte der erste RDP-Verbindungsaufbau, es kam nur zu einem Black Screen. Viel schwerwiegender war aber dann eine Folge dieses Fehlschlags, den der Terminalserver lies sich nicht mehr so ohne weiteres neu starten, er blieb immer bei “Wird neu gestartet” hängen. Soweit man es im Moment beurteilen kann, hilft das Downgrade auf die Firmware 10.02.210.

Nebenbei noch eine Info vom Support zum Laufwerk A:

“Wenn man im Setup unter Geräte – Speichergeräte – Hotplugspeichergeräte aktiviert und die Zahl der Laufwerke auf 1 oder höher setzt, wird standardmäßig ein Laufwerk A in der Sitzung angezeigt auss man ändert den Startbuchstaben ab (darunter). Diese Konfiguration wird dazu verwendet Massenspeicher wie USB Sticks in die Sitzung zu nehmen.”

Update 06.02.2019 – 08:32 Uhr

Leider hat der workaround mit dem Downgrade auf 10.02.210 nur einen Tag gehalten, heute gab es wieder Probleme, auch mehrfaches neu verbinden bzw. neu starten des Igels half nicht. Wir werden mal weiter Downgraden und testen “dürfen”.

Update 06.02.2019 – 17:35

Ich habe das Ganze jetzt nochmal und nochmal und nochmal getestet. Die Verbindungsprobleme tretten nicht immer auf. Im Schnitt bei jedem fünften Versuch, mal früher, mal später, mal nur einmal, mal mehrmals hintereinander. (Gefühlt) Häufiger ist es zu beobachten, wenn man Benutzer wechselt, d.h. von einem RDP-/WTS-Benutzer zu einem Anderem, z.B. auch wenn die Sitzung getrennt wird.

Downgrade auf 10.02.120 und 10.01.120 hat nichts gebracht.

Das der oder die Thin Client/s nicht immer wollen ist ja eine Sache, das der Terminalserver sich dann nicht mehr einfach neu starten lässt ist allerdings übel.

Update 07.02.2019

Nachdem ich mir die halbe Nacht um die Ohren geschlagen habe hier noch weitere erfolglose Versuche, das Problem zu lösen:

  • Unterstützte RDP-Protokolle von TCP und UDP auf nur TCP geändert.
  • RemoteFX de-/aktiviert und mit verschiedenen Einstellungen getestet.

So langsam Glaube ich, es liegt am Terminalserver und das Update der Igel-Firmware war, abgesehen vom ursprünglichen “Keine-Netzwerkverbindung”-Problem dann eher ein Zufallstreffer. Von zwei Windows-PC aus kam es ebenfalls zu Black Screens, unklar ist, ob sich dann ebenfalls der Terminalserver nicht mehr normal starten lässt.

Bei bzw. nach fehlgeschlagenen Verbindungen sieht man mit

query session

in der Eingabeaufforderung mehrere Verbindungen mit dem Status “ConnQ”, da geht also irgendwas beim Verbindungsaufbau oder der Aushandlung schief, der Beobachtung nach verschwinden diese dann auch nicht (was sie normalerweise tun sollten).

Update 19.02.2019

Weitere Tage bzw. Nächte später besteht der Ärger immer noch. Es liegt scheinbar wirklich am WTS (oder einer Software darauf), denn die Sache mit den fehlgeschlagenen RDP-Verbindungen konnte ich auch von Windows aus beobachten. Von daher, so scheint es, hat Igel damit nichts zu tun und es ist nur ein Zufallstreffer, das es in verbindungen mit diesen ThinClients aufgefallen ist. Vom zeitlichen Verlauf her könnte es an den Januar 2019-Patches von Microsoft liegen, gesichert ist das allerdings nicht.

Jedenfalls fanden sich endlich im EventLog ein paar Treffer. Das Thema wird ab jetzt in einem eigenen Beitrag weiter behandelt:

Windows-Terminalserver: Fehler beim Senden der disconnect (7)-Nachricht an das Windows-Videosubsystem. Der relevante Statuscode lautete 0x80070102