Bents Blog

Eine alltägliche Situation: Ein Kunde ruft an und hat ein zunächst einfach erscheinendes Problem. Da man selbst zumeist hinter einem anderen Problem steckt und um eine schnelle Lösung bemüht ist, liegt nichts näher, als sich einfach auf die Sitzung des Benutzers zu schalten und selber nach dem Rechten zu sehen.

Dank VPN-Standortverbindung zum Kundensystem und Terminalserverumgebungen vor Ort alles kein Problem, denkt man. Nach der Initiierung der Remoteüberwachung über die Terminaldiensteverwaltung gab es aber gelegentlich unangenehme Überraschungen.

Genauer gesagt, sind in letzter Zeit sind zwei verschienene Problemsituationen aufgetreten:

Problem 1

Unabhängig davon die eigene Sitzung bleibt solange hängen, bis letztendlich der Timeout für die Rückfrage angehaufen ist und ein heißt lapidar „Zugriff wurde verweigert“. Nun will man ja seinen Kunden nichts schlechtes nachsagen, aber nicht für jeden die IT den Stellenwert wie für uns. Folglich kann schonmal ein Fenster irgendwo untergehen oder zu schnell weggeklickt werden. In diesem Fall war dem aber nicht so, sondern es handelte sich tatsächlich um ein sehr einfaches Rechteproblem:

Dazu muss man folgendes kontrollieren:

In den Servereinstellungen unter der Teminaldienstekonfiguraton auf dem Terminalserver kann über den Reiter „Remoteüberwachung“ global definiert werden, ob die Option aktiviert werden soll oder nach den Einstellungen auf Nutzerebene verfahren werden soll (der Standardeinstellung). Da bei den Benutzern die Remoteüberwachung standardmäßig deaktiviert ist (zu finden unter einem eigenen Reiter der Benutzereigenschaften in der AD-Konsole, siehe Bild) empfiehlt sich die zentrale Konfiguration.

Eine Anforderung beim Benutzer sollte aufgrund der rechtlichen Situation in jedem Fall erfolgen. Auch bei korrekter Konfiguration ist jetzt aber folgendes passiert:

Problem 2

Nach Bestätigung der Remoteüberwachung, wird die Sitzung mit folgender Meldung getrennt:

Auf Serverseite sieht man für den Bruchteil einer Sekunden den Aufbau des Überwachungsfensters, welches aber sofort wieder beendet wird. Eine unangenehme Situation, zumal die Meldung dem gestressten Administrator doch tatsächlich Absicht unterstellt…

Nach eingem Testen ist mir jedoch folgendes aufgefallen:

In der betreffenden Kundenumgebung wird Small Business Server 2008 eingesetzt, welcher auch der zentrale Einstiegspuntk für jegliche Systemkonfigurationen. Auf dem Terminalserver (bzw. „Remotedienste-Sitzungshost“) kommt jedoch Windows Server 2008 R2 zum Einsatz.

Es lag also nahe, es direkt von einer Konsolen-Sitzung des Terminalsservers auszuprobieren und siehe da: Es funktioniert wie erwartet. Sollte es also tatsächlich ein Netzwerkproblem geben ?

Mitnichten, denn mir fiel sofort auf, dass die Option „Remoteüberwachung“ in „Remotesteuerung“ umbenannt wurde (was ich sehr begrüße) und offensichtlich haben unter der Haube noch weitere Veränderungen stattgefunden, sodass die Verwaltungskonsole von Windows Server 2008 Betriebssystemen nicht in jedem Fall kompatibel zu neueren Betriebssystemen sind. Eine offizielle Bestätigung, außer der Aussage „Die Remoteüberwachung ist nur mit ähnlichen Clientprotokollen möglich.“ in einem älteren Supportartikel bei Microsoft zu Windows Server 2000, habe ich dazu nicht gefunden.

Bei der Hyper-V Verwaltung sieht es ähnlich aus: Hier besitzt die Verwaltungsoberfläche unter einem Windows Server 2008 Betriebssystem besitzt nich alle Optionen bei der Verwaltung eines Hyper-V Servers unter Windows Server 2008 R2 und die entsprechenden Verwaltungstools sind nur für Windows 7 verfügbar.

Aus diesem Grund gehe ich davon aus, dass auch in diesem Fall die Verwaltungstools nicht 100%tig kompatibel sind.

Nachtrag (14.03.2010)

Heute morgen wies mich ein Kollege darauf hin, dass er das von mir beschriebene Verhalten ebenfalls beobachtet hat, aber mit meinen Hinweisen nicht lösen konnte.

Tatsächtlich konnte ich das Verhalten (Problem 2) in der betroffenen Umgebung nachvollziehen, allerdings kam hier auf den Terminalservern Windows Server 2008 zum Einsatz. Selbst der Versuch, direkt von Terminalserver aus eine darauf befindliche Benutzersitzung zu übernehmen, scheiterte dies.

Ich vermutete, dass der verwendete RDP-Client ebenfalls eine Rolle spielen könnte (viele Clients verwenden Windows XP mit nachinstalliertem RDP-Client 7.0 oder direkt Windows 7) und nach bisherigem Kenntnisstand scheint das tatsächlich der Fall zu sein: Wenn ich in der selben Umgebung die Verwaltungtools eines Systems mit Windows Server 2008 R2 verwende, kann ich die Sitzungen problemlos übernehmen. Sobald ich jedoch in meiner Verbindungskette auch nur ein einziger RDP-Client 7.0 befindet (was auch die Verbindung von meiner Arbeitsstation zum Server sein kann, von der aus ich dann wiederum eine Verbindung mit einem älteren Client verwende), scheitert der Versuch der Remotesteuerung mit einem Abbruch der Benutzersitzung.

Im Endeffekt empfiehlt sich also die Verwendung einer Windows 7 basierten Arbeitsstation mit installierten Remoteserver-Verwaltungstools, sofern in der betreffenden Umgebung das RDP-Protokoll in der Version 7 zum Einsatz kommt.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.