Terminal Server Clients

Wenn sie mit allen bisherigen Möglichkeiten ihre Anforderungen noch nicht erfüllen konnten, dann könnte der Terminal Service von Windows 2000 mit Citrix Metaframe eine Alternative darstellen. Technisch geht es damit, eine Windows NT-Sitzung mit allen bereitgestellten Anwendungen auf jedem beliebigen Desktop erreichbar zu machen. Sie können Sie damit Outlook als die optimale Anwendung für die Nutzung mit dem Exchange Server problemlos auf nahezu alle Plattformen bringen. Die Software zur Steuerung gibt es auch für Unix, Macintosh und als Java-Anwendung.

Die Funktion

Jede heutige Anwendung besteht aus drei wesentlichen Komponenten:

Store Datenspeicherung 
Ohne Speicherung von Daten macht die EDV kaum Sinn. Im Bezug auf Exchange und Outlook ist damit der Exchange Server gemeint, bzw. eine PST-Datei (Siehe auch Storageprovider).
Verarbeitung Verarbeitung
Hiermit ist die Verarbeitung der Daten gemeint. Das ist Outlook, welche die Tastatur und Mausbefehle in Aktionen umsetzt und an die Anzeige übergibt.
Anzeige
Diese Komponente ist die Schnittstelle zum Mensch und dient der Visualisierung von Daten und der Eingabe.

Zwischen den drei Komponenten gibt es einen regen Datenaustausch, der über die Transportwege abgewickelt wird. Und hier kann auch die Trennung zwischen den Systemen und den Betriebssystemen erfolgen.

Standard Clientfunktion

 Standard Client

Bei einem klassischen Einzelplatzsystem sind alle drei Funktionen auf einem System konzentriert. Die Ausgaben auf dem lokalen Bildschirm werden durch Outlook auf dem PC gesteuert und die Daten liegen in einer lokalen PST-Datei.
Client Server

Client Server

Der klassische vernetzte PC trennt hier schon die Datenspeicherung ab. Zwar gibt es auch lokal meist eine Festplatte, welche das Betriebssystem und die Anwendungen vorhält, aber die eigentliche Datenspeicherung erfolgt über das LAN auf einem Server, z.B. einem Dateiserver, einem Exchange Server oder auch einem SQL-Server. Vor Ort wird nur noch verarbeitet und angezeigt.
Terminal Clients Terminal Services

Beim Terminal Server wird die Anzeige von der Verarbeitung getrennt. Während auf den zentralen Anwendungsservern Outlook gestartet wird und auf den Exchange Server zugreift, werden alle Ausgaben und Eingaben über das Protokoll RDP oder ICA auf den Client übertragen.

Die Vorteile dieser gar nicht so neuen Technik (Textbasierte Terminals waren die ersten interaktiven Eingabegeräte nach dem Lochstreifenstapel, Terminal Dienste gab es schon für Windows NT 3.51 !) sind schnell zusammengefasst:

Ich möchte hier nicht den gesamten Marketingtext von Microsoft oder Citrix wiedergeben, aber es gibt wirklich einen Einsatzzweck für Terminal Server. Es ist sicher nicht die Universallösung für alle Probleme, wie dies gerne suggeriert wird, aber es wichtiges und nützliches Werkzeug bei der Bewältigung heutiger Aufgaben.

Diese Anbindung eignet sie z.B.: für kleine Außenstellen, bei denen ein Server vor Ort keinen Sinn macht oder einfach zu teuer in der Anschaffung und Betrieb ist. Vielleicht können Sie damit auch gleich die gesamte Officepalette zentral anbieten. Es ist mehr als nur eine Idee, es ist bei uns schon Realität. Auch über das Internet könnten Sie so ihr Outlook bedienen, da die Anzeigemodule auch als Java Applet, NetScape Plugin oder ActiveX-Komponente verfügbar ist.

Sie steuern dabei ein Outlook quasi fern. Durch den Einsatz von Metaframe ist der Start sogar in einem Browser oder als seamless Anwendung auf dem Client PC möglich. Der Anwender bemerkt damit gar nicht mehr, dass Outlook nicht auf seinem PC gestartet ist, sondern entfernt.

Die Arbeitsgeschwindigkeit ist dabei akzeptabel, da nur die Eingaben und Bildinhalte übertragen werden. Selbst lange Nachrichten oder HTML-Mails, in denen geblättert wird, sind damit zu lesen. Auf jeden Fall besser, als wenn die Information erst komplett auf den lokalen PC übertragen werden müsste.

Ehe sie nun aber in freudiger Erwartung in den nächsten Softwareladen laufen, um einmal Terminal Server zu kaufen, möchte ich ihnen nicht verschweigen, dass die Installation und der Betrieb eines Terminal Servers nicht mit einer Windows 2000 Workstation oder Servers zu vergleichen ist. Natürlich sieht die Oberfläche aus wie immer, aber es kommen zusätzliche Anforderungen hinzu. Stellen Sie sich vor, es gibt ein System, da ist Windows NT Server installiert ist, aber es gebärdet sich wie 20 wild gewordene Windows 2000 Workstations mit 20 Benutzern, die alle an "ihrem PC" herumschrauben. Während Sie einen Arbeitsplatzrechner problemlos mal wieder neu installieren können, bedeutet eine Störung auf dem Terminal Server eine viel größere Auswirkung. Dreh und Angelpunkt sind die Anwender, die zwar auf dem System arbeiten, aber nicht verstellen dürfen. Je nach Anwendung ist daher genau zu prüfen, wie die Anwendung und das Gesamtsystem gegen absichtliche oder unabsichtliche Einflüsse der Benutzer gesichert werden kann. Eine strenge Vergabe von NTFS-Rechte und ausgefeilte Anmeldeskripte mit "Selbstheilungsfunktionen" sind hier ebenso gefragt wir eine effektive Überwachung der Systemleistung. Aber lassen Sie sich dadurch nicht entmutigen.

Ein Wort noch zur Lizenzierung

Die Lizenzierung des Terminal Server ist ein wenig zu kompliziert, um sie hier in aller Breite zu erklären. Zumal Sie in ihrem Umfeld entscheiden müssen, ob ein einfacher Windows 2000 Terminal Server genügt, oder ob die Zusatzfunktionen von Metaframe in ihrem Umfeld notwendig oder nützlich sind. Hier dazu die Übersicht, für welchem Client welche Lizenz notwendig ist.

Einen Windows 2000 Server brauchen Sie als Lizenz sowieso. Hinzukommen dann je nach Client eine Windows 2000 CAL (W2K CAL), eine Terminal Server CAL (TS CAL), und eine Metaframe CAL. Wenn Sie Metaframe einsetzen, brauchen Sie auch eine Serverlizenz für Metaframe pro Server.

Client Protokoll W2K Cal TS Cal MetaFrame CAL
DOS ICA notwendig notwendig notwendig
WIN 3.11 ICA notwendig notwendig notwendig
WIN 3.11 RDP notwendig notwendig  
WIN 9X ICA notwendig notwendig notwendig
WIN 9X RDP notwendig notwendig  
Windows NT ICA notwendig notwendig notwendig
Windows NT RDP notwendig notwendig  
Windows 2000 Pro ICA notwendig enthalten notwendig
Windows 2000 Pro RDP notwendig enthalten  

Die Liste der optionalen Zutaten von Citrix ist hiermit noch lange nicht vorbei. So gibt es Komponenten für Lastverteilung, Softwareverteilung, Überwachung, Verschlüsselung etc.

Detaillierte Antworten zur Lizenzierung finden sich direkt bei Microsoft unter: http://www.Microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/win2kts/deploy/tslicen.asp

Outook 2003 Cached Mode und Terminal Server

Der Outlook 2003/2007 Cached Mode und Terminal Dienste sind nicht miteinander kombinierbar. Outlook "erkennt" dass es auf dem WTS läuft und verhindert die Konfiguration des Cached mode. Mir ist kein Hack bekannt, um Outlook hier zu überlisten. Es gibt nur eine Einstellung, mit der ich den Cached Mode auf anderen Systeme auch verhindern kann

Die Aktivierung des Cached Mode auf Terminal Servern macht aber konzeptionell keinen Sinn. Der Cached Mode hat die primäre Funktion, dass Outlook Anwender zügig arbeiten können, auch wenn Sie verbindungstechnisch schlechter (Bandbreite und Laufzeit) angebunden sind. Aus dem gleichen Grund stellt man auch Terminalserver mit den Anwendungen nahe an die Server und überträgt per RDP nur die Bildschirme. Aber gegen Cached Mode auf Terminal Servern sprechen noch andere Gründe

Im ungünstigsten Fall würden auf allen Terminal Server-Festplatten quasi je eine Kopie der Postfächer aller User liegen. Die WTS-Server müssten also alle so viel Platz haben, wie die Summe der Exchange Server Postfächer.

Die Lösung ist daher so zu gestalten, dass Outlook ohne Cached Mode "nahe" am Exchange Server positioniert wird. Damit ist die Latenzzeit im LAN zwischen Outlook und Exchange gering. Leider entfällt die Entlastung von Exchange durch den Cached Mode. Die WAN-Strecke besteht dann zwischen dem Client und dem Terminal Server in Form einer RDP-Verbindung

Mit ist klar, dass eine Firma mit genau einem Terminal Server das Problem in der Größe nicht hat. Der CachedMode ist von großem Vorteil, wenn zwischen Arbeitsplatz und Exchange Server eine WAN-Leitung ist und das ist zwischen Terminal Server und Exchange besser nicht der Fall.

Terminal Services für Administratoren

Man muss nicht immer gleich einen Terminal Server für Benutzer installieren. Windows 2000 und höher kennen auch noch Terminal Dienste im "Adminmodus", so dass man als Administrator bis zu zwei RDP-Verbindungen zum Server ohne gesonderte Lizenzen aufbauen kann. Ab Windows 2003 kann man neben den zwei RDP-Verbindungen sogar direkt die Konsole bedienen. Und Windows 2008 bringt sogar noch die TS-Gateway-Funktion mit, so dass Sie per HTTP aus dem Internet ihre Server per RDP fernsteuern können.

Administrative Konsolen

Wer mehr als ein paar Server gleichzeitig zu verwalten hat, wird sich irgendwann eine Konsole wünschen, um alle Server in einem Fenster zu steuern, schnell umzuschalten, sich einfach anzumelden und die Konfiguration zu speichern. Die eigentliche RDP-Console ist als Objekt sehr einfach anzusprechend, so dass es nur eine Frage der Zeit war, biss findige Entwickler ihre eigene Konsole gebaut haben, um mehrere Server zu verwalten. Schauen Sie sich einfach mal die ein oder andere Konsole an und entscheiden Sie selbst, welche sie nutzen möchten.

Ich habe längere Zeit mit Vision vRD gearbeitet, aber mittlerweile tendiere ich eher zu mRemote hin. mRemote unterstützt auch andere Protokolle (Telnet, VNC etc.), erlaubt mehrere Verbindungen zum gleichen Server mit unterschiedlichen Namen und die Entwickler scheinen aktiv daran weiter zu entwickeln.

Diese Programme benötigen allerdings ein Update 925876 Terminaldiensteclient 6.0 (http://support.microsoft.com/kb/925876)

Terminal Server und MaxMpxCt und MaxCmds

Meist fällt es nicht auf, wenn ein paar Benutzer sich am Terminal Server anmelden, aber wenn sich viele Personen nahezu gleichzeitig anmelden, dann kann es zu merklichen Verzögerungen führen, bei denen aber keine hohe CPU-Last, Festplatten-IO oder Netzwerklast zu erkennen ist. Das kann an einem Limit liegen, welches Windows Server bei Zugriffen per SMB per Default anwenden:

Ein Windows Server erlaubt per Default nur 50 ausstehende SMB-Befehle pro Client

Nun ist ein Terminal Server aus Sicht des Server auch nur ein "Client" und zwar genau "1" Client, auch wenn darauf 10, 20 oder 100 Benutzer z.B. Outlook verwenden. Und wenn sich morgens viele Benutzer nahezu gleichzeitig anmelden, dann muss der Anmeldeprozess viele Anmeldeskripte und Gruppenrichtlinien "nachladen". Da können 50 "offene Befehle" pro Server eng werden. Die Anmeldung dauert dann quälend lange. Die entsprechenden Parameter können aber angepasst werden:

Achtung MaxWorkItems=16000 belegt ca. 320MB of non-paged pool memory !!

Hier noch ein paar KB Artikel, die das Thema weiter beleuchten:

Sicher gibt es verschiedene Empfehlungen der "richtigen" Werte. Die Anzahl der ausstehenden Anfragen auf dem Terminal Server können sich sicher einfacher hoch setzen, da dies eine Funktion des LanManClients ist. Die Einstellung auf dem Server ist allerdings auch "global", so dass bei höheren Werten auch das Risiko ansteigt, dass auch andere Client mehr Befehle zur gleichen Zeit nutzen (und missbrauchen) können. Sinnvoll ist hier der Einsatz von PERFMON, um die aktuelle Ausnutzung der Ressourcen auf dem Server, Domain Controller und Terminal Server zu beobachten und dann die Werte mit Gefühl anzuheben.

Allerdings gibt es auch seitens Microsoft entsprechende Empfehlungen, die ich ohne weitere Prüfung hier als REG-Datei zum Download bereit stelle, so dass diese quasi mit einem Doppelklick übernommen werden können.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanserver\Parameters]
"MaxWorkItems"=dword:2000
"MaxMpxCt"=dword:800
"MaxRawWorkItems"=dword:200
"MaxFreeConnections"=dword:64
"MinFreeConnections"=dword:20

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters]
"MaxCmds"=dword:800

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Configuration Manager]
"RegistryLazyFlushInterval"=dword:3C

tssetting.reg

RDP und "Netzwerkpolicies"

Vielleicht haben Sie das auch schon erlebt. Sie starten wie gewohnt ihren RDP-Client auf Windows XP, aber können nicht auf ihren neuen Windows 2008 Server nicht zugreifen. Das hat den Grund, da neuere Versionen von Windows NLA anfordern und damit eine "Vorprüfung" der Clients mit weniger Ressourcen durchführen, ehe Sie dem Anwender den Anmeldeschirm anzeigen. Das soll die Angriffsfläche reduzieren.

RDP 6.1 und höher unterstützen auch NLA aber leider ist diese Funktion in Windows XP SP3 noch nicht per Default aktiviert. Die erforderlichen Ergänzungen sind über die Registrierung zu addieren.

Da diese Änderungen bestehende Werte "erweitert", kann ich leider kein REG-File dafür anbieten.

Weitere Links

Keywords:Terminalserver Metaframe Citrix MSTSC RDP