Spaß mit der Konsolen-Session

Die Konsolen-Session hat eine besondere Bedeutung in Windows-Betriebssystemen. Eine besondere Konstellation bei einem Kunden erforderte, dass ich mich näher damit auseinandersetze.

Zunächst einmal ist die Konsolen-Session diejenige Benutzersitzung, die dem lokal angemeldeten Benutzer zur Verfügung steht. Davon kann es maximal eine geben, weil ja nur ein Anwender lokal arbeiten kann. Es kann aber auch keine solche Session geben, wenn niemand lokal angemeldet ist.

Zusätzlich kann die Konsolen-Session aber unterschiedliche Zustände abnehmen. Seit der Einführung der Terminaldienste steht diese Sitzung nämlich nicht mehr nur lokalen Benutzern zur Verfügung. Es ist tatsächlich auch möglich, diese “lokale” Sitzung “remote” zu nutzen. Das geschieht immer dann, wenn man sich an einen Server mit dem RDP-Client anmeldet und dabei den Schalter “/admin” nutzt. Ein Client-Windows hat nur diese eine Sitzung, also braucht man dort den Schalter “/admin” nicht, um sich auf die Konsolen-Sitzung zu verbinden.

Eine Spielart der Remote-Konsole kommt ins Spiel, wenn der Zielrechner eine virtuelle Maschine ist. Hier kann die Virtualisierungssoftware dafür sorgen, dass die Konsole auf einem anderen Rechner dargestellt wird, ohne dass das Betriebssystem in der VM davon weiß. In Hyper-V geschieht dies über das Programm “VMConnect.exe” (das ist das Programm, das u.a. der Hyper-V-Manager nutzt, um eine Konsolenverbindung herzustellen).

Besonders spannend wird es nun, wenn diese Konsolensitzung abwechselnd über mehrere Mechanismen genutzt wird, ohne sie zwischendurch zu schließen. Dabei ändert sich die Einordnung dieser Sitzung unter Umständen mehrfach. Um dies herauszufinden, habe ich mich auf einem Server lokal angemeldet (also die Konsolen-Sitzung gestartet) und dort folgendes Batch gestartet:

@echo off
:anfang
echo %time%>>%0\..\ergebnis.txt
query session>>%0\..\ergebnis.txt
echo. >>%0\..\ergebnis.txt
ping -n 5 localhost>nul
goto anfang

Dieses Batch schreibt alle laufenden Sessions in die Datei ergebnis.txt, und zwar alle fünf Sekunden. Dazu nutzt es den Befehl “query”, der in modernen Windows-Versionen enthalten ist. Die so entstandene Datei habe ich dann mit einem zweiten Kommando noch einmal ausgewertet:

find /I "admin-nils" ergebnis.txt>cons.txt && notepad cons.txt

Dies gibt mir alle Zeilen zurück, in denen mein Anmeldename auftaucht.

Danach habe ich die Sitzung aktiv belassen, aber mich auf unterschiedliche Arten damit verbunden. Das Resultat ist sehr aufschlussreich, denn es zeigt den mehrfachen Statuswechsel der Session (hier gekürzt):

>console         admin-nils             1  Aktiv                      
>console         admin-nils             1  Aktiv                      
>rdp-tcp#0       admin-nils             1  Aktiv   rdpwd              
>rdp-tcp#0       admin-nils             1  Aktiv   rdpwd              
>rdp-tcp#0       admin-nils             1  Aktiv   rdpwd              
>                admin-nils             1  Getr.                      
>                admin-nils             1  Getr.                      
>                admin-nils             1  Getr.                      
>console         admin-nils             1  Aktiv                      
>console         admin-nils             1  Aktiv                      

Die Konsolen-Sitzung habe ich über VMConnect.exe begonnen. In diesem Moment identifiziert Windows sie als “console”. Dann habe ich den RDP-Client gestartet und mich von dort auf die Konsole verbunden (mstsc.exe /v:server01 /admin). In diesem Moment wechselte die Identifikation der Sitzung auf “rdp-tcp#0”. Diese RDP-Sitzung habe ich dann nicht beendet, sondern nur das RDP-Clientfenster geschlossen. Was nun geschah, ist im Protokoll sehenswert: Die Konsolensitzung hat nun gar keine Identifikation mehr, sie wird am Ende der Zeile als “getrennt” markiert. Abschließend habe ich die VMConnect-Verbindung auf die bestehende Sitzung wiederhergestellt, worauf Windows die Sitzung wieder als “console” erkannte.