Windows Server, AD, Exchange und mehr…..

Wenn die Anzahl der Terminalserverbenutzer in einem Netzwerk eine bestimmte Größe erreicht, macht es Sinn, über eine Terminalserverfarm nachzudenken. Dadurch kann man die Remote Desktop Session Hosts zum Einen hochverfügbar gestalten und zum Anderen auch eine Lastverteilung erreichen. Allerdings steht man dann sofort vor neuen Herausforderungen. Wenn die Terminalserversitzung eines Benutzers z.B. durch den Verlust der Internetverbindung getrennt wird, dann soll der Benutzer bei einem erneuten Verbindungsversuch mit seiner alten Sitzung verbunden werden.

Durch die Farm könnte es aber theoretisch passieren, dass ein Benutzer nicht mit dem Terminalserver verbunden wird, mit dem er ursprünglich verbunden war. Um das zu vermeiden, muss man einen Remote Desktop Session Broker einsetzen. Der Session Broker verfügt über eine Datenbank (tsesdir.edb), in der alle Benutzersitzungen innerhalb der Farm registriert sind. Wenn ein Benutzer eine Verbindung mit der Farm herzustellen versucht, dann fragt der Terminalserver, mit dem die initiale Verbindung hergestellt wird, den Session Broker ab. Der Session Broker gleicht anhand des Benutzernamens ab, ob der Benutzer auf einem Terminalserver der Farm bereits eine bestehende Sitzung hat. Wenn das der Fall ist, dann wird die Verbindungsanforderung des Benutzers an den entsprechenden Terminalserver in der Farm umgeleitet.  Wenn der Session Broker ausfällt, dann funktioniert dieser Mechanismus nicht mehr und es könnte vorkommen, dass Benutzer, die sich zu ihrer getrennten Sitzung wieder verbinden wollen, einfach eine neue Sitzung auf einem völlig anderen Terminalserver innerhalb der Farm bekommen. Deshalb könnte man das Clustern des Session Broker Dienstes in Betracht ziehen. Das Clustern dieses Dienstes war bis Windows Server 2008 nicht möglich bzw. wurde durch Microsoft nicht supported. Ab Windows Server 2008 R2 kann man diesen Dienst innerhalb eines Windows Failoverclusters als Anwendung ausführen, der die notwendige Redundanz für diesen wichtigen Dienst zur Verfügung stellen kann.

Um das Clustern des Remote Desktop Session Brokers zu demonstrieren, habe ich eine kleine Testumgebung aufgebaut. Diese besteht aus den folgenden Rechnern:

1. Ein Domänencontroller DC1 (Windows Server 2008 R2 Enterprise)
2. Zwei Clusterknoten (CLU1 und CLU2) (Windows Server 2008 R2 Enterprise)
3. Zwei Terminalservern (TSNLB1 und TSNLB2) (Windows Server 2008 R2 Enterprise)

Aufbau der Testumgebung

Der Failovercluster verfügt über keine gesharten Datenträger. Diese sind für das Clustern des Remote Desktop Session Brokers auch nicht notwendig. Jeder der beiden Clusterknoten verfügt über seine eigene “tsesdir.edb”. Als Quorummodell habe ich in diesem Fall “Node and File Share Majority” ausgewählt. Nach dem der Cluster konfiguriert ist, kann man sich an die Installation des Remote Desktop Session Brokers auf den beiden Clusterknoten durchführen.

Nach der erfolgreichen Installation des Session Brokers, kann man diesen als Anwendung über die Failover Clusterverwaltung installieren.

Nachdem die Installation durchgeführt wurde, müssen beide Terminalserver in die lokale Benutzergruppe “Sitzungsbrokercomputer” auf BEIDEN Clusterknoten hinzugefügt werden.

Jetzt geht es an die Konfiguration der beiden Terminalserver. Der Lastenausgleich für die beiden Terminalserver wird über DNS Round Robin realisiert. Für die Terminalserverfarm gibt es einen A-Eintrag “tsfarm.spielwiese.intern”, der auf die IP Adressen 192.168.2.30 und 192.168.2.31 zeigt. Der FQDN “tsfarm.spielwiese.intern” wird von den Clients genutzt, um sich mit der Terminalserverfarm zu verbinden.

Zusätzlich müssen auf BEIDEN Terminalservern noch die Einstellungen für die Farm bzw. für den Session Broker konfiguriert werden. Wenn es sich um mehr als zwei Terminalserver handelt, dann könnte man diese Einstellungen auch über eine Gruppenrichtlinie konfigurieren.

• Farmname: tsfarm
• Remotedesktop-Verbindungsbroker: rdcp.spielwiese.intern
• Priorität: 100 (dadurch werden die Clients auf beide Remote Desktop Session Hosts verteilt)

Wenn diese Einstellungen vorgenommen wurden, werden die Clientsitzungen ab sofort auf die beiden Terminalserver gleichmäßig verteilt. Wenn ein Benutzer seine Sitzung trennt und sich anschließend wieder verbindet, dann wird der Benutzer wieder automatisch mit seiner getrennten Sitzung verbunden.

Was passiert nun, wenn der Cluster einen Failover durchführt und dadurch der Remote Desktop Session Broker auf dem anderen Knoten ausgeführt wird? Wenn das geschieht, dann verfügt der Clusterknoten, der die Rolle des Remote Desktop Session Brokers jetzt ausführt, über keine Informationen zu den einzelnen Sitzungen auf Remote Desktop Session Hosts. Der aktuelle Remote Desktop Session Broker kontaktiert die einzelnen Server in der Farm und liest deren Sitzungsliste ein. Dadurch verfügt er über eine aktuelle Liste der Sitzungen und kann seine Arbeit aufnehmen. Dieser Vorgang dauert zwei bis drei Minuten. Während dieser Zeit kann es passieren, das getrennte Sitzungen nicht mehr korrekt verbunden werden und Benutzer, die sich wieder verbinden wollen, einfach eine neue Sitzung innerhalb der Farm bekommen. Den Ablauf der Kommunikation zwischen dem Remote Desktop Session Broker und dem Remote Desktop Session Host kann man in diesem Netzwerktrace schön sehen:

Failover des Clusters

Der Server “tsnlb1.spielwiese.intern (192.168.2.30)” versucht den Remote Desktop Connection Broker “rdcb.spielwiese.intern (192.168.2.40) zu erreichen und stellt fest, dass die TCP Sitzung nicht mehr existiert. Er versucht jetzt mehrmals einen TCP-Retransmit.

Da diese Versuche erfolglos sind, schickt der Server “tsnlb1.spielwiese.intern (192.168.2.30)” einen TCP Reset (Frame 75) und versucht dann einen erneuten TCP Threeway Handshake der von dem Server “rdcp.spielwiese.intern (192.168.2.40)” auch beantwortet wird (Frame 76 – 78).

Nachdem die TCP Sitzung eingerichtet wurde, beginnt die eigentlich RPC Kommunikation zwischen dem Remote Deskop Session Host und dem Connection Broker (Frame 79 – 111) . Ab dem Frame 115 werden zwischen den beiden Peers nur noch TCP KeepAlive Pakete ausgetauscht. Das lässt darauf schließen, dass die Kommunikation beendet ist und alle Daten zwischen den beiden Servern ausgetauscht wurden.

Wenn man sich den Netzwerktrace etwas genauer ansieht, dann stellt man fest, dass es in meiner Testumgebung etwa zwei Minuten gedauert hat, bis nach dem eingeleiteten Failover die Sitzungsdatenbank des Remote Desktop Connection Brokers aktualisiert war. Dieser Umstand ist eigentlich nicht weiter dramatisch, da bestehende Remote Desktop Sitzungen natürlich weiter bestehen bleiben. Wenn natürlich in diesem Zeitraum ein Benutzer sich mit seiner bestehenden Remote Desktop Sitzung innerhalb der Farm verbinden möchte, dann schlägt das fehl und er bekommt eine neue Sitzung auf einem beliebigen Terminalserver eingerichtet. Nach den zwei Minuten sollte alles wieder wie gewohnt ablaufen.

Das Windows Recovery Environment ist für die erste Notfallbehandlung oder auch für das Ausführen einer Wiederherstellung eine feine Sache. Noch schöner ist es, dass man WinRE auch über einen WDS Server starten kann. Dadurch entfällt das lästige Suchen nach eine DVD, die man im Notfall meistens sowieso nicht zur Hand hat.
In einem Kurs, den ich vor den Feiertagen gehalten habe, kam die Frage auf, ob es möglich wäre, WinRE beizubringen, mit einer statischen IP-Adresse zu arbeiten. Der Teilnehmer hat in seinem Netzwerk mehrere Netze, die jeweils durch Firewalls getrennt sind. Das produktive Netz ist dort von dem Datensicherungsnetz durch einen Firewall getrennt. In der Firewall gibt es eine Regel, die nur bestimmten IP-Adressen den Zugriff aus dem produktiven Netz in das Datensicherungsnetz erlaubt.

Als Erstes muss man sich entweder ein WIM File mit dem Windows Recover Environment erstellen oder man “klaut” sich das WIM File von einer bestehenden Installation. Wer den langen Weg gehen möchte, der kann sich nach dieser Anleitung ein WIM File erstellen:

Dieses WIM File kopiert man an einen temporären Speicherort. In meiner Testumgebung wurde ein Ordner “WinRE” direkt auf dem Laufwerk “C:\” erstellt. In diesem Ordner wird die Datei abgelegt.

Nachdem die Datei kopiert wurde, kann man sie mit “imagex” mounten. Damit das Tool imagex verfügbar ist, muss man das WAIK installieren. Das Setup findet man hier:

Windows® Automated Installation Kit (AIK) für Windows® 7

Zusätzlich zu dem Ordner “WinRE” benötigt man noch einen leeren Ordner, in dem das WIM File gemounted wird. Dafür wurde in der Testumgebung ein Ordner “WinREMount” erstellt. Mit folgendem Kommando wird das WIM-File in diesen Ordner gemounted:

imagex /mountrw C:\WinRE\WinRE.wim 1 C:\WinREMount

Nachdem das Image erfolgreich gemounted wurde, kann man über den Windows Explorer bequem die Ordnerstruktur von WinRE durchsuchen. In diesem speziellen Fall ist das Anpassen der Datei “winpeshl.ini” im Verzeichnis “C:WinREMount\Windows\System32″ notwendig. Im Orginal hat diese Datei folgenden Inhalt:

[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe

Mit der Hilfe dieser Datei kann man weitere Applikationen automatisch starten. Allerdings gibt es dort ein paar Stolperfallen zu beachten. Im gleichen Verzeichnis gibt es noch eine weitere Datei “startnet.cmd”, die für das Starten des Netzwerkes bzw. für die Hardwareerkennung von WinRE zuständig ist. Diese befindet sich ebenfalls im Ordner “System32″. Diese Datei kann man nutzen, um über “netsh” eine IP-Adresse für die erkannte Netzwerkkarte zu konfigurieren und das komplette Skript dann über einen Eintrag in der “winpeshl.ini” zu starten. Also wird als Erstes die Datei “startnet.cmd” angepasst:

wpeinit
netsh interface ipv4 set address “LAN-Verbindung” static 192.168.2.3 255.255.255.0 192.168.2.1

Wenn man jetzt dem Technet Artikel “Einschließen eines benutzerdefinierten Skripts in ein Windows PE-Abbild” folgt, dann könnte man z.B die Datei “winpeshl.ini” folgendermaßen ergänzen, um die Datei “startnet.cmd” während des Starts von WinRE mit auszuführen:

[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe
[LaunchApps]
X:\Windows\System32\startnet.cmd

Allerdings funktioniert das leider nicht. Scheinbar kann man innerhalb der Datei “winpeshl.ini” entweder die Sektion “[LaunchApp]” oder “[LaunchApps]” einsetzen. Wenn man das oben angeführte Beispiel einsetzt, dann wird die Sektion “[LaunchApps]” einfach ignoriert. Deshalb hier die korrigierte Version:

[LaunchApps]
X:\Windows\System32\startnet.cmd
X:\sources\recovery\recenv.exe

Danach speichert man die Datei “winpeshl.ini” einfach wieder ab (ACHTUNG: Diese Datei ist schreibgeschützt!). Danach schließt man alle Anwendungen, die auf das Verzeichnis “C:\WinRE” zugreifen (Notepad, Windows Explorer u.s.w.). Anschließend werden mit folgendem Kommando die Änderungen in das WIM-File übernommen:

imagex /unmount C:\WinREMount /commit

Jetzt muss das WIM-File als neues Startabbild in die Windows Bereitstellungsdienste integriert werden.

Wenn das WIM-File auf den Bereitstellungsdiensten erfolgreich integriert wurde, kann jetzt über die Windows Bereitstellungsdienste darüber gestartet werden.

Nach dem Start von WinRE über WDS wird dann sofort das Netzwerk konfiguriert und die statische IP-Adresse wird genutzt.

Outlook 2003 wird von Exchange 2010 offiziell unterstützt. Leider gibt es aber doch ein paar Probleme, die den Spaßfaktor beim Arbeiten vermissen lassen. Den größten Ärger gab es für den Dienstleister immer, wenn neue Mails nicht sofort von Outlook 2003 Posteingang erschienen aber auf dem Pocket PC, Iphone oder BlackBerry schon da waren. Dieses Problem ist der Tatsache geschuldet, dass Microsoft unter Exchange 2010 die UDP Notifications für Outlook 2003 entfernt hat. Linderung verspricht dieser KB Artikel.

Allerdings ist das nur Kosmetik und veranlasst jeden Outlook 2003 Client wesentlich öfter den Exchange 2010 zu kontaktieren. Dadurch wird das Serversystem natürlich wesentlich mehr belastet.

Scheinbar hat die hohe Anzahl von Supportfällen Microsoft dazu veranlasst, den UDP Notification Support wieder zu Exchange 2010 hinzuzufügen. Im März 2010 soll es endlich mit RU3 so weit sein.

Artikel MS-Exchange Team

Jeder Admin kennt das Problem. Da will man etwas für die Sicherheit seines Netzwerkes tun und legt fest, dass die Benutzerkennwörter nach xTagen ablaufen. Was erntet der arme Admin dafür………nur Ärger und Stress. Eine beliebte Ausrede für deaktivierte Konten ist dann meist, dass der User ja nicht ordentlich benachrichtigt wurde. Das kleine graue Fenster von Windows, was einen ja auf das Ablaufen des Kennwortes hinweist, wird eben zu gern ignoriert. Allerdings gibt es auch arme Benutzer, die es vielleicht wirklich nicht mitbekommen, dass ihr Kennwort bald ablaufen wird. Das sind zum Beispiel VPN Benutzer oder auch Benutzer die über POP3 oder auch IMAP auf ein Exchange Postfach zugreifen. Genau an dieser Stelle setzt das Tool PassAlert an. Dieses Tool scannt das Active Directory nach Benutzerkonten ab, deren Kennwörter recht bald ablaufen (der Zeitraum ist frei konfigurierbar). Diesen Nutzern stellt das Tool eine Mail zu, um sie darüber zu informieren. Der Inhalt der Mail kann vom Administrator frei erstellt werden. Somit kann kein Nutzer mehr sagen, er wäre nicht über den Ablauf seines Kennworts informiert worden.

Weitere Informationen findet Ihr unter der Webseite http://www.mcseboard.de/active-directory-forum-79/passalert-betaphase-145443.html

ACHTUNG:  Das gute Stück ist noch Beta. Ich habe es eigentlich lang genug getestet und es läuft stabil. Trotzdem kann ich natürlich für die korrekte Funktion des Tools nicht garantieren.

PassAlert kann man hier herunterladen. Passalert (470)

Über Feedback und Bugmeldungen würde ich mich natürlich sehr freuen.

Sehr oft kommt es in den Newsgroups vor, dass Teilnehmer nach Best Practise Lösungen fragen. Da kommt zum Beispiel die Frage wie in folgendem Forenbeitrag. Diese Fragen werden meist von mehreren Teilnehmern beantwortet und der Fragende hat dann mehrere Unterschiedliche Meinungen und ist genau so klug wie zuvor.

Microsoft hat jetzt gerade für Exchange 2010 ein paar geteste Szenarios veröffentlicht, die dem einen oder anderen Forenteilnehmer die Frage nach dem Exchange Sizing beantworten.

Link zu den Beiträgen

Viel Spaß beim Lesen wünscht,

Frank