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.

Achtung: Security Update

Um diese Meldung zu lösen, müssen Sie ein Security Update installieren
https://blogs.technet.microsoft.com/mckittrick/unable-to-rdp-to-virtual-machine-credssp-encryption-oracle-remediation/
https://support.microsoft.com/en-us/help/4295591/credssp-encryption-oracle-remediation-error-when-to-rdp-to-azure-vm
Ursache ist meist, dass der Client das Update schon h at aber der Server noch nicht.

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:

  • Zentrale Haltung der Daten und Anwendungen. Damit zentrales Backup und Updates
  • Effektivere Nutzung der Rechenleistung (schon mal gesehen, wie viel CPU-Leistung ihr PC im "Leerlaufprozess" verbringt ?
  • Die Anzeigeeinheit kann "einfach" sein. Angefangen von einem Windows PC, über Unix-Clients oder wirklich einfache "thin" Terminals ohne Festplatte, Lüfter etc.
  • Die geringe Bandbreite erlaubt auch den Zugriff über langsamer Leitungen oder von unterwegs.
  • Auch ein Verbindungsabbruch oder ein Absturz des Arbeitsplatzsystems verliert seinen Schrecken, da die Verbindung wieder aufgebaut werden kann.
  • Verbesserter Support, da Sie sich auch die Sitzung heranholen und den Benutzer bei dem Problem unterstützen können (vergleichbar zu einer Fernsteuerung).
  • Und vieles mehr

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 Plug-in 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

  • Mehrfache Kopien einer OST
    Viele Firmen nutzen mehrere TerminalServer und "Farmen". Da ein Anwender auch jedem der Server landen kann, würden nach einiger Zeit auf allen Servern eine Kopie meiner OST-Datei im Profil liegen. Das wäre ein sehr hohes mehrfaches Replikationsaufkommen. Auch die Anfangsreplikation hindert hier, wenn z.B. ein neuer Server in die Farm aufgenommen wird und ich das erste Mal dort lande. Das passiert auch, wenn die Profile nach der Abmeldung gelöscht werden
  • Mehrere OSTs pro Server
    Zudem arbeiten auf einem Terminal Server ja mehrere User parallel bzw. nacheinander. Dies würde dann dazu führen, dass auf einem Terminal Server von jedem User eine OST-Datei angelegt werden würde

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 können 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.

Aber für Administrative Zugänge ist natürlich auch die Sicherheit höher anzusetzen. Ein einfaches "Username/Kennwort"-Schema ist nicht ausreichend. Ein vom Admin erratenes Kennwort öffnet die Tür für Angreifer und ein offener Server ist natürlich auch eine Teststelle um Anmeldeinformationen per Brute Force Attacke auszuprobieren.

Leider habe ich noch keinen Weg gefunden, wie man z.B. das RDP-Gateway per Client-Zertifikate absichern kann. Man könnte es zumindest hinter einer IPSec-Absicherung auf Netzwerkebene schützen.

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:

  • MaxCmds (DWORD: Default=50 Max=65535)
    Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
    Anzahl der maximal ausstehenden Anforderungen auf dem Client (Hier der Terminal Server)
  • MaxMpxCt (DWORD: Default=50 Max=65535)  Windows 2000 Maximum = 125
    Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanServer\parameters
    Achtung: >125 blockiert Windows 95/98 (siehe KB 232890). Wert wird an den Client beim SMB Connect mitgegeben. Einstellung ist daher NUR auf dem remote Server (Nicht auf dem TS) sinnvoll
    "The MaxMpxCt parameter allows a server to provide a suggested maximum number of simultaneous outstanding client requests to a particular server"
  • MaxWorkItems (DWORD: Default = (4*(MB*SMBServerPerfSetting)*OSVersion/1)*(#Processors) (Siehe KB232476)
    Registr<y: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanServer\parameters
    Empfehlung 4x MaxMpxCt.

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

Automatische Anmeldung

Es ist auch mit RDP möglich, dass ein Anwender automatisch angemeldet wird. Allerdings muss dazu per Gruppenrichtlinie quasi eine "Allowlist" der Server gepflegt werden, für welche diese Vorgabe zutrifft.

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.

  • 951608 Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3

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

  • CRL
    RDP7 prüft CRL
  • 951608 Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3
  • 953760 When you enable SSO für a terminal server from a Windows XP SP3-based client computer, you are still prompted für User credentials when you log on to the terminal server
  • 951616 Description of the Remote Desktop Connection 6.1 client Update für Terminal Services
  • 969084 Description of the Remote Desktop Connection 7.0 client Update für Remote Desktop Services (RDS) für Windows XP SP3, Windows Vista SP1, and Windows Vista SP2

Weitere Links