Microsoft Windows Server 2003 Terminaldienste - Begleitinformationen und Korrekturen

[Installationswerkzeuge] [Ressourcenverwaltung] [Desktops] [Citrix] [VBScript] [ACT 3.0] [LPC] [Konsole]

Kurzbeschreibung

Die Windows Server Terminaldienste ermöglichen die interaktive Nutzung eines Anwendungsservers durch mehrere gleichzeitig angemeldete Benutzer innerhalb eines Netzwerks. Hierbei werden sämtliche Anwendungsoperationen zentral auf dem Windows Server 2003 ausgeführt. Die grafische bzw. multimediale Interaktion der Benutzer mit den Anwendungen erfolgt über Clients, die als Mindestanforderung Tastatur, Maus und Bildschirm bereit stellen. Die Clients können dabei Terminals, Webbrowser oder jede andere Plattform sein, die über eine spezielle Software zur Anbindung an die Terminaldienste verfügt. Der Fokus liegt hierbei in der Regel auf einer vereinfachten zentralen Administration von Anwendungen und der Reduktion von Betriebskosten. Die erfolgreiche Einrichtung einer Produktivumgebung auf Basis der Terminaldienste erfordert ein umfangreiches technisches Verständnis für die zugehörigen Konzepte. Das vorliegende Buch beschreibt daher Planung, Installation, Konfiguration und Verwaltung der Windows Server 2003 Terminaldienste in Netzwerkumgebungen. Verschiedene Referenzszenarien zeigen konkrete Anpassungsoptionen und Einsatzgebiete. Ergänzend wird die Erweiterung der Terminaldienste durch die Produkte der Firma Citrix ausführlich besprochen. Auch die Integration in das Konzept von Anwendungsportalen basierend auf der Microsoft .NET-Umgebung und Citrix Secure Access Manager wird im Detail präsentiert.

Neue Informationen zu den Installationswerkzeugen von Drittherstellern

April 2004

Der Markt der Installationswerkzeuge entwickelt sich recht dynamisch. Aus diesem Grund ändern sich einige der zugehörigen Beschreibungen aus Kapitel 5.

Wise Solution und Altiris

Das Unternehmen Wise Solutions bietet wieder mehrere Produkte für die Erstellung und Verwaltung von Installationen an. Der Wise for Windows Installer erlaubt die Erstellung von MSI-Paketen, das Wise Installation System nutzt dagegen eine eigene Installations-technologie. Beide Produkte bauen auf eine spezifische Skriptsprache. Diese erlaubt die Festlegung einer weitgehend frei definierbaren Installationslogik. Des Weiteren wird die Erstellung von Dialogfenstern zur Benutzerführung und die Validierung der Ergebnisse mit einem Debugger unterstützt.

Nähere Informationen zu den Produkten von Wise Solutions erhalten Sie unter http://www.wise.com.

Wise Solutions wurde am 3. Dezember 2003 von Altiris übernommen, einem der größten Anbieter für Softwareprodukte im Bereich Systemverteilung und -konfiguration. Das interessanteste Produkt für Terminalserver ist hierbei die Altiris Server Management Suite. Die Produkte von Wise Solutions eignen sich im Zusammenhang mit der Altiris Server Management Suite insbesondere für die Erstellung von Softwarepaketen. Weitere Informationen zu Altiris finden sich unter http://www.altiris.com.

ON Technology und Symantec

Am 13. Februar 2004 wurde das Unternehmen ON Corporation und seine ON Command-Produktlinie von Symantec übernommen. Das Produkt ON Command CCM erlaubt hierbei die unbeaufsichtigte Installation von Betriebssystemen und Anwendungen auf Windows-Plattformen. Daher ist es auch für die Installation und Verwaltung von Terminalservern geeignet. Nähere Informationen hierzu finden sich unter http://www.on.com.

Ressourcenverwaltung

April 2004

Kapitel 11 meines Buchs "Microsoft Windows Server 2003 Terminaldienste" behandelt unter anderem die Verwaltung von Ressourcen. Auf Seite 403 sind hierbei einige Ergänzungen nötig: 

Die Lastenverteilung sorgt für eine möglichst gleichmäßige Verteilung der Benutzersitzungen über die verfügbaren Terminalserver einer Farm. Hierbei mögen zwar Analysen der momentanen Ressourcenauslastung jedes Servers für eine entsprechende Anpassung des Verteilungsalgorithmus' sorgen. Jedoch kann dies fast immer nur abhängig von einer Momentaufnahme der Systemauslastung sein, die zum Zeitpunkt der Verbindungsanforderung eines neuen Benutzers besteht. Wie kann die Skalierbarkeit einer Terminalserverumgebung jedoch noch weiter erhöht werden? Wie kann man verhindern, dass das Verhalten eines Benutzers die Ressourcenanforderungen an den Terminalserver so erhöhen, dass andere Benutzer davon massiv beeinträchtigt sind?

Die technische Beantwortung dieser Fragen basiert zumeist auf dem Einsatz von Erweiterungswerkzeugen. In den folgenden Abschnitten dieses Buchs werden entsprechende Produkte von Microsoft, AppSense und Citrix vorgestellt. Diese sind jedoch nur als eine Auswahl der verfügbaren Optionen zu sehen. Auch die Produkte ARMTech von Aurema (http://www.aurema.com), TScale von RTO Software (http://www.rtosoft.com), Expedian von Wyse (http://www.wyse.com) und Revelos von WM Software (http://www.wmsoftware.com) sind es definitv Wert im Hinblick auf die Ressourcenverwaltung von Terminalserver beachtet zu werden. 

Einen besonders interessanten und zukunftsträchtigen Ansatz verfolgt in diesem Zusammenhang auch das Unternehmen Softricity mit seinem Produkt SoftGrid (http://www.softricity.com). Hierbei können auf Terminalservern Anwendungen ausgeführt werden, die nicht physikalisch auf dem Server installiert sind. Die Anwendungen liegen vielmehr in einem speziellen Paketformat auf einem zentralen Server. Nur die Anwendungssymbole sind in den Benutzersitzung der Terminalserver zu sehen. Sobald ein Benutzer eine Anwendung startet, wird sie vom zentralen Server auf den betreffenden Terminalserver übertragen und dort in einer eigenen virtuellen Umgebung ausgeführt. Diese Umgebung beinhaltet auch eine virtuelle Registrierungsdatenbank und virtuelle DLLs. Zugriffe auf die reale Registrierungsdatenbank des Terminalservers finden somit nicht statt. Da sich jede über SoftGrid gestartete Anwendung in einer solchen virtuellen Umgebung befindet, ist der Einfluss auf das Betriebssystem und andere Anwendungen minimal. Wird eine solche Anwendung wieder beendet, verschwindet sie rückstandslos vom Terminalserver. Bevor sich Anwendungen jedoch so verhalten, müssen sie mithilfe von speziellen SoftGrid-Werkzeugen auf einer Referenzplattform installiert und vorbereitet werden. Neben reinen Terminalservern unterstützt Softricity SoftGrid auch Citrix MetaFrame XP Presentation Server.

Absicherung des Desktops - zusätzliche Produkte

März 2004

Auf Seite 296 (Kapitel 8) in meinem Buch "Microsoft Windows Server 2003 Terminaldienste" beschreibe ich zusätzliche Werkzeuge zur Absicherung des Desktops. Hierzu sollen an dieser Stelle einige Ergänzungen aufgeführt werden:

HINWEIS: Auf dem kommerziellen Markt adressieren spezielle Produkte in verschiedener Weise dieses Problem. Beispiele für gängige Lösungen bieten Simplify Lockdown von triCerat (http://www.tricerat.com), SoftGrid for Terminal Servers von Softricity (http://www.softricity.com), PowerFuse von Real Enterprise Solutions (http://www.respowerfuse.com), SecureEXE von SecureWave (http://www.securewave.com), Total Control von OneApp (http://www.oneapp.co.uk) oder EOL Desktop Manager von Emergent Online (http://www.go-eol.com).

Anmerkungen zu Citrix MetaFrame XP Presentation Server

Januar 2004

Während der Übersetzung des deutschen Buchs nach Englisch durchlief es eine zusätzliche Korrekturphase in der Firmenzentrale von Citrix in Ft. Lauderdale. Hierbei waren insbesondere Bob Kruger (CTO), Jennifer Lang, Russ Naples und Rizwan Pirani sehr hilfreich. Sie korrigierten noch eine Reihe kleinerer Fehler bei der Beschreibung von Citrix MetaFrame XP Presentation Server. Diese Korrekturen sollen natürlich auch für die deutschen Leser verfügbar gemacht werden.

Auf Seite 329 und auch in späteren Abschnitten wird die Empfehlung ausgesprochen, dass nicht mehr als 100 Server pro Farm konfiguriert sein sollten. Citrix hat viele Verbesserungen an seinem System vorgenommen, um dieses Limit weiter nach oben zu verschieben. Daher sind auch größere Serverzahlen inzwischen durchaus möglich. Dies zeigt sich auch darin, dass Citrix das vorkonfigurierte Limit der Serverzahl von 256 auf 512 erhöht hat. Diese Zahl 256 für die vorgegebene Grenze von Servern pro Zone ist daher auch auch auf der Seite 385 auf 512 zu verändern.

Auf Seite 330 werden die unterschiedlichen Datenbankplattformen aufgezählt, unter anderem auch Microsoft SQL Server 7 SP2 und spätere. Dies beinhaltet natürlich auch den Microsoft SQL Server 2000, obwohl dieser nicht explizit aufgeführt wird.

Auf Seite 331 steht im zweiten Absatz folgender Satz: "Nach diesem initialen Kontakt überprüft der MetaFrame-Server alle 10 Minuten bei der IMA-Datenbank, ob sich die Konfiguration geändert hat." Das Intervall hat sich jedoch bei MetaFrame XP Feature Release 3 (= MetaFrame XP Presentation Server für Windows Server 2003) im Vergleich zu den Vorgängerversionen auf 30 Minuten erhöht.

Im Nächsten Abschnitt wird folgende Aussage gemacht: "Weiterhin sorgt der LHC (Local Host Cache) auch dann noch für die korrekte Funktion des MetaFrame-Servers, wenn die Verbindung zur IMA-Datenbank unterbrochen ist. Dies gilt natürlich nur so lange, wie der MetaFrame-Server nicht neu gestartet wird oder bis 96 Stunden vergangen sind." Tatsächlich ist es so, dass sich auch bei einer verlorenen Datenbankverbindung und nach dem Neustart des MetaFrame-Server ein Benutzer anmelden kann, solange die 96 Stunden noch nicht vergangen sind. Die benötigten Informationen werden dabei vom LHC bezogen. Daher muss der zweite Satz von oben heißen: "Dies gilt natürlich nur so lange, bis 96 Stunden vergangen sind." Entsprechend muss auch der letzte Satz im WICHTIG-Vermerk auf Seite 369 angepasst werden. Der korrekte Text ist somit:

WICHTIG: Verliert ein MetaFrame-Server der Farm die Verbindung zur IMA-Datenbank, können sich noch für maximal 96 Stunden Benutzer bei ihm anmelden. Nach dieser Zeitspanne ohne Verbindung zur IMA-Datenbank ist dies nicht mehr möglich.

In Tabelle 9.2 auf Seite 331 wird aufgeführt, dass der IMA Port 2513 über das Kommando Imaport veränderbar ist. Dies gilt in gleichem Maße auch für das zweite IMA-Port 2512.

Die Beschreibung zweier Spiegelstriche auf Seite 364 ist missverständlich. Daher folgen hier verbesserte Erklärungen:

• ICA-Keep-Alive: Möglichkeit zur Einstellung eines Herzschlagintervalls, das vom Server zum Client geschickt wird, um zu erkennen, dass die Verbindung noch geöffnet ist.
• MetaFrame XP-Einstellungen: Antwort auf ICA-Rundrufe (Broadcasts), Clientzeitzonen, DNS-Adressauflösung für den XML-Dienst, Inhaltsumleitung aktivieren und Remoteverbindung zur Windows Server 2003 Konsolesitzung erlauben.

Auch bei der zweiten Liste mit Spiegelstrichen auf Seite 265 haben sich einige unklare Formulierungen eingeschlichen:

• Druckerbandbreite: Verfügbare Clientdrucker-Bandbreite und Einstellungen eines oberen Limits für die genutzte Bandbreite jedes Client-Druckauftrags.
• ICA-Keep-Alive: Auswahl der Option eine farmweite Konfiguration des ICA-Keep-Alive oder eine entsprechende individuelle Einstellung zu wählen.

Auch hat Citrix eine neue Formel für die ungefähre Datenmenge in KB, die ein MetaFrame-Server während seiner Startphase von der IMA-Datenbank erhält:

Alte Formel (auf Seite 387):

IMA-Daten = 330 + 10*Server + 2,8*Anwendungen + 3*Druckertreiber

Server: Anzahl der MetaFrame-Server in der Farm
Anwendungen: Anzahl der veröffentlichten Anwendungen 
Druckertreiber: Anzahl der installierten Druckertreiber

Neue Formel:

IMA-Daten = 402 + 6.82*(Server-1)

VBScript zur Anpassung der Terminalserver-Einstellungen

Dezember 2003

Das englische Buch "Microsoft Windows Server 2003 Terminal Services" enthält in Kapitel 7 ein Skript-Beispiel in VBScript. Es zeigt, wie man aus dem Windows Script Host die Terminalserver-Einstellungen verändert. Natürlich sollen auch die deutschen Leser Zugriff auf dieses Skript bekommen:

' Creation of required objects
Set WshNetwork = CreateObject("Wscript.Network")
Set UserObj = GetObject("WinNT://" & WshNetwork.UserDomain & "/" & WshNetwork.UserName)

' Changing terminal server settings
UserObj.TerminalServicesInitialProgram = "C:\Program Files\Internet Explorer\iexplore.exe" 
UserObj.TerminalServicesWorkDirectory = "C:\windows" 
' UserObj.ConnectClientDrivesAtLogon = 1 
' UserObj.ConnectClientPrintersAtLogon = 1 
' UserObj.DefaultToMainPrinter = 1 
' UserObj.TerminalServicesProfilePath = "\\FILESRV1\profiles\" & WshNetwork.UserName 
' UserObj.TerminalServicesHomeDirectory = "\\FILESRV2\home\" & WshNetwork.UserName 
' UserObj.TerminalServicesHomeDrive = "U:" 
' UserObj.AllowLogon = 1 
' UserObj.MaxDisconnectionTime = 30 
' UserObj.MaxConnectionTime = 0 
' UserObj.MaxIdleTime = 120 
' UserObj.BrokenConnectionAction = 0 
' UserObj.ReconnectionAction = 0 
' UserObj.EnableRemoteControl = 1 
UserObj.SetInfo

Microsoft Application Compatibility Toolkit 3.0

November 2003

In meinem Buch "Microsoft Windows Server 2003 Terminaldienste" beschreibe ich in Kapitel 5 auf Seite 208 das Application Compatibility Toolkit 3.0 (ACT). ACT 3.0 befindet sich nicht auf der Begleit-CD. Hier ist der Pfad zum Herunterladen von ACT über die Microsoft Web-Site.

Local Procedure Call Facility (LPC)

November 2003

In meinem Buch "Microsoft Windows Server 2003 Terminaldienste" beschreibe ich in Kapitel 1 auf Seite 15 die Local Procedure Call Facility (LPC). Die Beschreibung beinhaltet jedoch einen Fehler, auf den mich Mark Russinovich von Sysinternals.com hingewiesen hat (wozu englische Übersetzungen doch gut sind...). LPC ist nicht eine Variante der Remote Procedure Calls (RPC). Lokale RPCs basieren vielmehr auf LPCs. Die zugehörigen Prozesse können dabei auf den Adressraum eines anderen Prozesses zugreifen, solange die Sicherheitseinstellungen des Zielprozesses dies erlauben. Alle Prozesse im Kontext des selben Benutzerkontos können jeweils auf den Speicher der anderen Prozesse zugreifen. Viele Anwendungen basieren auf dem gemeinsamen Speicherzugriff für die Interprozesskommunikation.

Konsolesitzung

November 2003

In meinem Buch "Microsoft Windows Server 2003 Terminaldienste" mache ich in Kapitel 1 auf Seite 14 die Aussage, dass die Konsolesitzung immer die Sitzungs-ID 0 hat. Dies ist jedoch nicht immer der Fall. Entsprechend der Platform SDK Dokumentation von April 2003 ist es auch möglich, dass die Sitzung 0 nicht mit der physikalischen Konsole verbunden ist. Dies liegt daran, dass die Sitzung 0 auch mit einer entfernten Sitzung verbunden sein kann, da der erste Benutzer, der sich anmeldet, die Sitzungs-ID 0 zugeteilt bekommt.