4
Terminal Service Cluster, Redundante Windows Terminal Server
Hallo,
ich habe mich im Netz ein wenig nach Möglichkeiten umgesehen, mehrere Windows Terminal Server redundant laufen zu lassen. Alles was ich von MS gefunden habe ist die Funktion des Session Directorys, was ein Dienst ist der eine Art Datenbank hält in denen die Sessions der Terminal Server stehen. Die Info wer der Session Directory Server ist, kann man via Admintool oder Policy konfigurieren.
Um aber jetzt zu der Farm eine RDP Connection zu öffnen und meine passende Session wieder zubekommen brauche ich eine IP hinter der sich dann der WTS verbirgt der meine Session besitzt.
Ich bin nur bis zu Session Directory Konfiguration gekommen und an der Cluster Installation gescheitert.
Hat jemand Erfahrung damit oder eine Idee wie man das anders lösen kann?
Besten Dank
ich habe mich im Netz ein wenig nach Möglichkeiten umgesehen, mehrere Windows Terminal Server redundant laufen zu lassen. Alles was ich von MS gefunden habe ist die Funktion des Session Directorys, was ein Dienst ist der eine Art Datenbank hält in denen die Sessions der Terminal Server stehen. Die Info wer der Session Directory Server ist, kann man via Admintool oder Policy konfigurieren.
Um aber jetzt zu der Farm eine RDP Connection zu öffnen und meine passende Session wieder zubekommen brauche ich eine IP hinter der sich dann der WTS verbirgt der meine Session besitzt.
Ich bin nur bis zu Session Directory Konfiguration gekommen und an der Cluster Installation gescheitert.
Hat jemand Erfahrung damit oder eine Idee wie man das anders lösen kann?
Besten Dank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 78457
Url: https://administrator.de/contentid/78457
Ausgedruckt am: 22.11.2024 um 14:11 Uhr
4 Kommentare
Neuester Kommentar
Hi
Ja
kauf dir Citrix
Gruß
-jo-
Ja
kauf dir Citrix
Gruß
-jo-
Hallo Sielan,
ich hoffe, dass deine Frage noch aktuell ist ...
Was du brauchst sind einige Dinge, die Einrichtung ist aber eigentlich nicht schwer. Glücklicherweise ist alles mit Bordmitteln zu schaffen.
Im Gegensatz zu Citrix kannst du hier keine Published Apps fahren, aber das weisst du sicher. Außerdem ändert sich das mit Windows 2008 ja.
Also los geht's
a) x Anzahl Terminalserver
b) einen Server, der das Sessiondirectory hält (wird per GPO bestimmt)
a)
an den Terminalservern musst du in den Netzwerkeinstellungen Änderungen vornehmen.
Zunächst musst du Network Load Balancing ggf. nachinstallieren! Dem NLB gibst du im Anschluß über "Eigenschaften" eine eigene IP-Adresse. Diese IP ist nachher die "Sammel-IP" für dein TS-Cluster. Im FQDN trägst du dann auch den künftigen Namen deines Clusters ein (als FQDN!).
(Beide Einstellungen (Cluster-IP und Cluster-Name) sind bei allen Mitgliedern deines Clusters gleich.)
Weiter unten - "unicast" auswählen.
b)
du erstellst eine Gruppenrichtlinie, die nur auf der OU des künftigen TS-Cluster-Server liegt. In der OU (nennen wir sie mal TS-Cluster-members) liegen alle deine TS.
Die Gruppenrichtlinie =>
Computer Config - Administrative Templates - Windows Components - Terminal Services - Sessiondirectory - Join Session Directory => aktivieren
Computer Config - Administrative Templates - Windows Components - Terminal Services - Sessiondirectory - Session Directory Server => aktivieren, name des Clusters wie oben festgelegt eintragen
Computer Config - Administrative Templates - Windows Components - Terminal Services - Sessiondirectory - Session Directory Cluster Name => aktivieren, Name des Clusters von oben (NLB bei den TS) eintragen
Dann gehst du an deine TS, machst ein gpupdate (kein force!), dann einen Reboot.
Deine Clients müssen sich dann nicht mehr zu den jeweils einzelnen Terminalserver verbinden, sondern nur noch zu dem Clusternamen bzw. der IP des Clusters!
Vorteil liegt ja klar auf der Hand...
Sollte dir ein TS mal ausfallen, nimm den TS aus deiner TS-OU, gpupdate und boot, dann wird er im Cluster nicht mehr "erwartet".
Weitere Fundstellen:
Microsoft KB243523,
Viel Erfolg!
ich hoffe, dass deine Frage noch aktuell ist ...
Was du brauchst sind einige Dinge, die Einrichtung ist aber eigentlich nicht schwer. Glücklicherweise ist alles mit Bordmitteln zu schaffen.
Im Gegensatz zu Citrix kannst du hier keine Published Apps fahren, aber das weisst du sicher. Außerdem ändert sich das mit Windows 2008 ja.
Also los geht's
a) x Anzahl Terminalserver
b) einen Server, der das Sessiondirectory hält (wird per GPO bestimmt)
a)
an den Terminalservern musst du in den Netzwerkeinstellungen Änderungen vornehmen.
Zunächst musst du Network Load Balancing ggf. nachinstallieren! Dem NLB gibst du im Anschluß über "Eigenschaften" eine eigene IP-Adresse. Diese IP ist nachher die "Sammel-IP" für dein TS-Cluster. Im FQDN trägst du dann auch den künftigen Namen deines Clusters ein (als FQDN!).
(Beide Einstellungen (Cluster-IP und Cluster-Name) sind bei allen Mitgliedern deines Clusters gleich.)
Weiter unten - "unicast" auswählen.
b)
du erstellst eine Gruppenrichtlinie, die nur auf der OU des künftigen TS-Cluster-Server liegt. In der OU (nennen wir sie mal TS-Cluster-members) liegen alle deine TS.
Die Gruppenrichtlinie =>
Computer Config - Administrative Templates - Windows Components - Terminal Services - Sessiondirectory - Join Session Directory => aktivieren
Computer Config - Administrative Templates - Windows Components - Terminal Services - Sessiondirectory - Session Directory Server => aktivieren, name des Clusters wie oben festgelegt eintragen
Computer Config - Administrative Templates - Windows Components - Terminal Services - Sessiondirectory - Session Directory Cluster Name => aktivieren, Name des Clusters von oben (NLB bei den TS) eintragen
Dann gehst du an deine TS, machst ein gpupdate (kein force!), dann einen Reboot.
Deine Clients müssen sich dann nicht mehr zu den jeweils einzelnen Terminalserver verbinden, sondern nur noch zu dem Clusternamen bzw. der IP des Clusters!
Vorteil liegt ja klar auf der Hand...
Sollte dir ein TS mal ausfallen, nimm den TS aus deiner TS-OU, gpupdate und boot, dann wird er im Cluster nicht mehr "erwartet".
Weitere Fundstellen:
Microsoft KB243523,
Viel Erfolg!
1
Hallo Hussi,
vielen Dank für Deine Hilfe!
Ich habs jetzt folgendermaßen gemacht:
- 2 Server als SessionDirectory Cluster, d.h. mit cluadmin.msc den Session Directory Services geclustert (Quorum Disk nötig, aber unter VMWare kein Problem)
- 3 TS die in dem SessionDirectory Mitglieder sind (Config per Policy verteilt)
- als Loadbalacing Lösung nehme ich entweder DNS Round Robin (3 Host Records mit mit selben Namen und unterscheidl. TS IPs) oder über windowsintegrated NLB (nlbmgr.msc)
leider geht das NLB nicht mit VMware Maschinen (VMWare Server 1.0.4), zumindest bei mir und Kollegen. Kollege meint mit Hardware servern solls gehen.
BG SIELAN
vielen Dank für Deine Hilfe!
Ich habs jetzt folgendermaßen gemacht:
- 2 Server als SessionDirectory Cluster, d.h. mit cluadmin.msc den Session Directory Services geclustert (Quorum Disk nötig, aber unter VMWare kein Problem)
- 3 TS die in dem SessionDirectory Mitglieder sind (Config per Policy verteilt)
- als Loadbalacing Lösung nehme ich entweder DNS Round Robin (3 Host Records mit mit selben Namen und unterscheidl. TS IPs) oder über windowsintegrated NLB (nlbmgr.msc)
leider geht das NLB nicht mit VMware Maschinen (VMWare Server 1.0.4), zumindest bei mir und Kollegen. Kollege meint mit Hardware servern solls gehen.
BG SIELAN
Hallo Siegan,
schön dass es bei dir geklappt hat.
NLB unter VM habe ich noch nicht machen müssen, da wir reine Hardware fahren. Aber möglich ist es ja, dass es unter VM nicht geht - im Virtuellen finden sich ja immer wieder "Ausnahmen"
Aber unter "echten" Servern funktioniert es wunderbar.
Gibt es einen bestimmten Grund, dass du zwei Server für das Session Directory hältst? Sieht aufwändig aus (wg. dem Quorum und natürlich auch BS-Lizenzen). Ich habe es nur auf einer Maschine - und das auch nur "nebenbei" (auf Fileserver).
Wenn die Maschine versagen sollte, wird eben die GPO fix geändert und das war's dann schon (aber wenn der Fileserver versagt, habe ich eh ein gaaaaanz anderes Problem )
LG Hussi
schön dass es bei dir geklappt hat.
NLB unter VM habe ich noch nicht machen müssen, da wir reine Hardware fahren. Aber möglich ist es ja, dass es unter VM nicht geht - im Virtuellen finden sich ja immer wieder "Ausnahmen"
Aber unter "echten" Servern funktioniert es wunderbar.
Gibt es einen bestimmten Grund, dass du zwei Server für das Session Directory hältst? Sieht aufwändig aus (wg. dem Quorum und natürlich auch BS-Lizenzen). Ich habe es nur auf einer Maschine - und das auch nur "nebenbei" (auf Fileserver).
Wenn die Maschine versagen sollte, wird eben die GPO fix geändert und das war's dann schon (aber wenn der Fileserver versagt, habe ich eh ein gaaaaanz anderes Problem
)LG Hussi
