3
Fragen zur Funktionsweise der Windows Server 2012 R2 Remote Desktop Services
Ich habe eine neue Windows 2012 R2 RDS Umgebung eingerichtet und teste sie grade. Hierbei ergeben sich für mich ein paar Fragen die mich sehr verwirren:
1) Ich ging ursprünglich davon aus das sich die Clients per RDP am Connection Broker anmelden und dieser die Sitzung an einen Session Host seiner Wahl weiter reicht, was mir auch logisch erschien. Jetzt lese ich, das in einer Round-Robin DNS Konfiguration alle DNS Einträge auf den ersten Session-Host verweisen sollen ( http://www.windowspro.de/wolfgang-sommergut/load-balancing-fuer-termina ... ).
a) Ist das nicht unsinnig, wenn der erste Session Host ausfällt? Sebst ein redundanter Connection Broker (auf den ich verzichtet habe) wäre doch dann zwecklos.
b) Wenn ich alle Clients auf den ersten Session Host schicke und die Verbindung dennoch umgeleitet wird, wiso kann ich dann nicht gleich jeden Client auf einen beliebigen Session Host connecten lassen?
2) Wenn mein Connection Broker mich einem anderen Session Host zuweist als dem, zu dem ich ursprünglich meine Vervindung aufgebaut habe, muss ich mich zwei mal mit Benutzername / Passwort anmelden. Sehr, sehr nervig, warum ist das so?
3) Ich habe zwei identisch eingerichtete Session Hosts. Ich habe außerdem Benutzerprofil-Datenträger (User Profile Disks) eingerichtet. Wenn mein User sich an Host 1 anmeldet, eine Datei auf dem Desktop erzeugt und sich abmeldet, kann ich nachvollziehen, das diese Datei in seine UPD gespeichert wird. Meldet sich der User jetzt auf dem anderen RD Session Host an bekommt er nur ein temporäres Profil. Was läuft hier quer?
Ich bin dankbar für Antworten, so ganz durchschaue ich das noch nicht.
1) Ich ging ursprünglich davon aus das sich die Clients per RDP am Connection Broker anmelden und dieser die Sitzung an einen Session Host seiner Wahl weiter reicht, was mir auch logisch erschien. Jetzt lese ich, das in einer Round-Robin DNS Konfiguration alle DNS Einträge auf den ersten Session-Host verweisen sollen ( http://www.windowspro.de/wolfgang-sommergut/load-balancing-fuer-termina ... ).
a) Ist das nicht unsinnig, wenn der erste Session Host ausfällt? Sebst ein redundanter Connection Broker (auf den ich verzichtet habe) wäre doch dann zwecklos.
b) Wenn ich alle Clients auf den ersten Session Host schicke und die Verbindung dennoch umgeleitet wird, wiso kann ich dann nicht gleich jeden Client auf einen beliebigen Session Host connecten lassen?
2) Wenn mein Connection Broker mich einem anderen Session Host zuweist als dem, zu dem ich ursprünglich meine Vervindung aufgebaut habe, muss ich mich zwei mal mit Benutzername / Passwort anmelden. Sehr, sehr nervig, warum ist das so?
3) Ich habe zwei identisch eingerichtete Session Hosts. Ich habe außerdem Benutzerprofil-Datenträger (User Profile Disks) eingerichtet. Wenn mein User sich an Host 1 anmeldet, eine Datei auf dem Desktop erzeugt und sich abmeldet, kann ich nachvollziehen, das diese Datei in seine UPD gespeichert wird. Meldet sich der User jetzt auf dem anderen RD Session Host an bekommt er nur ein temporäres Profil. Was läuft hier quer?
Ich bin dankbar für Antworten, so ganz durchschaue ich das noch nicht.
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: 263221
Url: https://administrator.de/contentid/263221
Ausgedruckt am: 22.11.2024 um 22:11 Uhr
3 Kommentare
Neuester Kommentar
Okay bei Frage 1 habe ich was missverstanden. Im Fall von Round Robin DNS verweist ein DNS Name auf mehrere Session Hosts, nicht umgekehrt. Dieser Artikel erklärt sehr gut dem Ablauf: http://www.virtualizationadmin.com/articles-tutorials/vdi-articles/gene ...
Dennoch bleibt Frage 2). Meine RDS Farm reicht mich an einen anderen Host als an den, zu dem ich mich verbunden habe. Ich muss mich zwei mal authentifizieren.
2a) Kann ich das umgehen? Kann mein Session Host mich nicht auf eine "authentifizierte Weise" redirecten?
2b) Wenn nein, kann ich zumindest dem Load Balancing mitteilen das bis zu einer gewissen Zahl an Connections ich auf dem initialen Session Host verweilen darf? (Bisher werde ich schon mitunter redirected wenn beide Server 0 Sessions haben.)
...und meine Frage 3) wie Eingangs gestellt.
Dennoch bleibt Frage 2). Meine RDS Farm reicht mich an einen anderen Host als an den, zu dem ich mich verbunden habe. Ich muss mich zwei mal authentifizieren.
2a) Kann ich das umgehen? Kann mein Session Host mich nicht auf eine "authentifizierte Weise" redirecten?
2b) Wenn nein, kann ich zumindest dem Load Balancing mitteilen das bis zu einer gewissen Zahl an Connections ich auf dem initialen Session Host verweilen darf? (Bisher werde ich schon mitunter redirected wenn beide Server 0 Sessions haben.)
...und meine Frage 3) wie Eingangs gestellt.
Habe kürzlich selber derartige Probleme gehabt...
Ich habe letztlich folgende Konfiguration genommen: 1 Server ist nur RD-WA, RD-CB, RD-LIC und 2 Server sind nur RD-SHs. Verbinden tut sich der Client nur auf den ConnectionBroker, von dort erfolgt eine Umleitung zu einem der beiden Sessionhosts. Auf welchen hab ich keinen Einfluss, dazu müsste man die Wertigkeiten bei der Lastverteilung verändern, aber wozu.
Habe mich auch durch diverse Internetanleitungen und Video-Workshops gequält, die Geschichte mit dem Round Robin ist glaube ich von vielen einfach von 2008R2 1:1 auf 2012/R2 übernommen worden, ohne es überhaupt einmal zu testen. MIT RoundRobin hatte ich jedenfalls Zertifikatsprobleme ohne Ende.
Zertifikate sind überhaupt das A und O einer 2012er Umgebung! Mit dem Zertifikat werden u.a. die RDP-Dateien signiert, bei falscher Konfiguration hagelt es bei jeder Verbindung Fehlermeldungen. Falls Du Remote-Apps benutzen willst muss die Zertifikatsgeschichte rundum sauber laufen, da gibt es die Möglichkeit zum "Ignorieren" schlicht nicht. Wenn Du Zugriff von domainfremden Clients benötigst kommst Du um ein "echtes" nicht herum, dann wird auch die Einrichtung der Farm nochmal etwas komplexer. Falls hier Bedarf besteht bitte nochmal melden.
Doch nun zu den Fragen:
1) Was ich zuerst auch falsch verstanden hab ist der Weg, wie MS den Benutzer zu so einer Farm verbunden haben möchte. Und zwar NICHT über den RDP-Client selbst gestartet, sondern erst via RDWeb auf der Farm eingeloggt und dann von dort die dort liegende RDP-Datei gestartet.
Dort wird automatisch eine RDP-Datei generiert, sobald Du eine Sammlung erstellt hast. In dieser RDP-Datei sind u.a. Einstellungen gespeichert, damit die RD-SHs keine Zertifikats-Fehlermeldungen mehr ausposaunen, wenn man umgeleitet wird. Wenn Du manuell vom Win7-RDP Client o.ä. auf den Namen oder die IP startest wird es immer eine Fehlermeldung geben, nur mit o.g. RDP-Datei nicht.
Wichtig zu o.g. Datei: sobald Du RD-Apps veröffentlichst verschwindet diese Datei, also vorher wegsichern! Dazu wenn eine Sammlung existiert zu dieser mit RD-Apps in der Systemsteuerung eines Clients verbinden. ( https://fqdndesrd-cb/RDWeb/Feed ) Ist man angemeldet kann man sich aus dem Clientverzeichnis "C:\Users\<username>\AppData\Roaming\Microsoft\Workspaces\<workspace-id>\Resource" die genannte "Fullsession-RDP" wegsichern, sobald man auch nur eine einzige Anwendung als Remote-App freigegeben hat ist der Link weg!
Wie gesagt, mit Fehlermeldungen kannst Du auch immer direkt über IP/FQDN an einen der RD-SHs rangehen, der fragt bei Verbindung dann seinen konfigurierten RD-CB, wohin er verbunden werden soll und leitet dann ggf. auf RD-SH2 um. Hat aber den Haken, wenn RD-SH1 zufällig mal offline sein sollte wegen Updates o.ä. Daher empfehle ich den "Microsoft-Way" über den RD-CB mit Hilfe der automatisch erstellten RDP-Datei. Auf den RD-CB darfst Du dich allerdings nicht einfach via IP oder FQDN verbinden, denn der sagt dann selbstverständlich, dass Benutzer XY keine Anmelderechte auf dem RD-CB hat. Das bezieht sich dann auf die lokalen RDP-Anmelderechte des CB!
2) Single-Sign On:
GPO "C_SSO_für_Terminalserver_aktivieren”, aktiviert an der Stammdomäne (Muss zumindest den ConnectionBrokernamen, der veröffentlicht wurde enthalten. Die Session-Hosts habe ich sicherheitshalber auch noch hinzugefügt.
Computerkonfiguration/Richtlinien/Administrative Vorlagen/System/Delegierung von Anmeldeinformationen
"Delegierung von Standardanmeldeinformationen zulassen" - Aktiviert
"Server zur Liste hinzufügen:" "TERMSRV/FQDN-RD-CB, TERMSRV/FQDN-RD-SH1, TERMSRV/FQDN-RD-SH2, ..."
"Betriebssystemstandards mit vorheriger Eingabe verknüpfen" - Aktiviert
3) Tipp meinerseits: deaktivier die UPD!
Ich hab mich damit anfangs ewig rumgeärgert, spätestens die Unmöglichkeit, den Administrator vor der UPD-Nutzung auszuklammern hat mich letztlich dazu bewogen gänzlich darauf zu verzichten. Außerdem gab es in meiner Farm Probleme mit temporären Dateien von RD-Apps.
Ich hab deshalb Roaming Profiles eingerichtet.
GPO "C_Terminalserver_RoamingProfiles”, aktiviert an der OU der RD-Sessionhosts
Computerkonfiguration/Richtlinien/Administrative Vorlagen/System/Benutzerprofile
"Sicherheitsgruppe "Administratoren" zu servergespeicherten Profilen hinzufügen" - Aktiviert
Computerkonfiguration/Richtlinien/Administrative Vorlagen/Windows-Komponenten/Remotedesktopdienste/Remotedesktopsitzungs-Host/Profile
"Pfad für servergespeichertes Remotedesktopdienste-Benutzerprofil festlegen" - Aktiviert
"Profilpfad" - "\\Fileserver\RDS-Profiles"
Ich habe letztlich folgende Konfiguration genommen: 1 Server ist nur RD-WA, RD-CB, RD-LIC und 2 Server sind nur RD-SHs. Verbinden tut sich der Client nur auf den ConnectionBroker, von dort erfolgt eine Umleitung zu einem der beiden Sessionhosts. Auf welchen hab ich keinen Einfluss, dazu müsste man die Wertigkeiten bei der Lastverteilung verändern, aber wozu.
Habe mich auch durch diverse Internetanleitungen und Video-Workshops gequält, die Geschichte mit dem Round Robin ist glaube ich von vielen einfach von 2008R2 1:1 auf 2012/R2 übernommen worden, ohne es überhaupt einmal zu testen. MIT RoundRobin hatte ich jedenfalls Zertifikatsprobleme ohne Ende.
Zertifikate sind überhaupt das A und O einer 2012er Umgebung! Mit dem Zertifikat werden u.a. die RDP-Dateien signiert, bei falscher Konfiguration hagelt es bei jeder Verbindung Fehlermeldungen. Falls Du Remote-Apps benutzen willst muss die Zertifikatsgeschichte rundum sauber laufen, da gibt es die Möglichkeit zum "Ignorieren" schlicht nicht. Wenn Du Zugriff von domainfremden Clients benötigst kommst Du um ein "echtes" nicht herum, dann wird auch die Einrichtung der Farm nochmal etwas komplexer. Falls hier Bedarf besteht bitte nochmal melden.
Doch nun zu den Fragen:
1) Was ich zuerst auch falsch verstanden hab ist der Weg, wie MS den Benutzer zu so einer Farm verbunden haben möchte. Und zwar NICHT über den RDP-Client selbst gestartet, sondern erst via RDWeb auf der Farm eingeloggt und dann von dort die dort liegende RDP-Datei gestartet.
Dort wird automatisch eine RDP-Datei generiert, sobald Du eine Sammlung erstellt hast. In dieser RDP-Datei sind u.a. Einstellungen gespeichert, damit die RD-SHs keine Zertifikats-Fehlermeldungen mehr ausposaunen, wenn man umgeleitet wird. Wenn Du manuell vom Win7-RDP Client o.ä. auf den Namen oder die IP startest wird es immer eine Fehlermeldung geben, nur mit o.g. RDP-Datei nicht.
Wichtig zu o.g. Datei: sobald Du RD-Apps veröffentlichst verschwindet diese Datei, also vorher wegsichern! Dazu wenn eine Sammlung existiert zu dieser mit RD-Apps in der Systemsteuerung eines Clients verbinden. ( https://fqdndesrd-cb/RDWeb/Feed ) Ist man angemeldet kann man sich aus dem Clientverzeichnis "C:\Users\<username>\AppData\Roaming\Microsoft\Workspaces\<workspace-id>\Resource" die genannte "Fullsession-RDP" wegsichern, sobald man auch nur eine einzige Anwendung als Remote-App freigegeben hat ist der Link weg!
Wie gesagt, mit Fehlermeldungen kannst Du auch immer direkt über IP/FQDN an einen der RD-SHs rangehen, der fragt bei Verbindung dann seinen konfigurierten RD-CB, wohin er verbunden werden soll und leitet dann ggf. auf RD-SH2 um. Hat aber den Haken, wenn RD-SH1 zufällig mal offline sein sollte wegen Updates o.ä. Daher empfehle ich den "Microsoft-Way" über den RD-CB mit Hilfe der automatisch erstellten RDP-Datei. Auf den RD-CB darfst Du dich allerdings nicht einfach via IP oder FQDN verbinden, denn der sagt dann selbstverständlich, dass Benutzer XY keine Anmelderechte auf dem RD-CB hat. Das bezieht sich dann auf die lokalen RDP-Anmelderechte des CB!
2) Single-Sign On:
GPO "C_SSO_für_Terminalserver_aktivieren”, aktiviert an der Stammdomäne (Muss zumindest den ConnectionBrokernamen, der veröffentlicht wurde enthalten. Die Session-Hosts habe ich sicherheitshalber auch noch hinzugefügt.
Computerkonfiguration/Richtlinien/Administrative Vorlagen/System/Delegierung von Anmeldeinformationen
"Delegierung von Standardanmeldeinformationen zulassen" - Aktiviert
"Server zur Liste hinzufügen:" "TERMSRV/FQDN-RD-CB, TERMSRV/FQDN-RD-SH1, TERMSRV/FQDN-RD-SH2, ..."
"Betriebssystemstandards mit vorheriger Eingabe verknüpfen" - Aktiviert
3) Tipp meinerseits: deaktivier die UPD!
Ich hab mich damit anfangs ewig rumgeärgert, spätestens die Unmöglichkeit, den Administrator vor der UPD-Nutzung auszuklammern hat mich letztlich dazu bewogen gänzlich darauf zu verzichten. Außerdem gab es in meiner Farm Probleme mit temporären Dateien von RD-Apps.
Ich hab deshalb Roaming Profiles eingerichtet.
GPO "C_Terminalserver_RoamingProfiles”, aktiviert an der OU der RD-Sessionhosts
Computerkonfiguration/Richtlinien/Administrative Vorlagen/System/Benutzerprofile
"Sicherheitsgruppe "Administratoren" zu servergespeicherten Profilen hinzufügen" - Aktiviert
Computerkonfiguration/Richtlinien/Administrative Vorlagen/Windows-Komponenten/Remotedesktopdienste/Remotedesktopsitzungs-Host/Profile
"Pfad für servergespeichertes Remotedesktopdienste-Benutzerprofil festlegen" - Aktiviert
"Profilpfad" - "\\Fileserver\RDS-Profiles"
Hi und erstmal vielen Dank für die umfangreiche Antwort.
Ich bin mitlerweile auch weiter in meinem Projekt und hier mal meine Erfahrung:
RDWeb habe ich mir schon angeschaut und die RD Config Datei verschwindet tatsächlich mit der Bereitstellung einer Remote App, sie kommt aber auch wieder wenn man die Bereitstellung aufhebt. Ich habe mir die Datei angeschaut und sie versucht sich auf den RD-CB zu verbinden, was mit gültigen DNS jetzt auch klappt. Wenn mich nicht alles täuscht ist das der funktionierende Failover den ich gesucht habe und ich kann diese Datei auch anderweitig zur Verbindung bereit stellen.
Verbinde ich mich über eine "gewöhnliche" RDP Config auf den RD-CB versucht er mich tatsächlich lokal anzumelden, das scheint mir auch sinnvoll. Verbinde ich mich auf einen RD-SH, egal welchen, werde ich auf einen Server nach Wahl des RD-CB verbunden, das läuft gut. Das Problem der doppelten Anmeldung tritt nach einer erneuten Bereitstellung nicht mehr auf, mein Punkt 2 hat sich erledigt und ich kann nicht sagen woran das im ersten Anlauf gescheitert ist. Das ist natürlich nur in einem Punkt wirklich hinderlich, nämlich wenn der RD-SH, den ich nutze um den ersten Kontakt aufzubauen, offline ist. Ich hätte in diesem Fall also Load-Balancing aber kein Failover der RD-SHs.
Eigentlich setze ich auch RDWeb und Zertifikate nicht ein, ich arbeite noch mit klassischem VPN zur Absicherung. Auch stelle ich keine einzelnen Apps bereit sondern immer einen kompletten Desktop. Die Zertifikate habe ich selbst erstellt und auf meinen RD-CB ausgestellt, wie auf diversen Seiten empfohlen. Wie mit beiden oben beschriebenen Methoden kann ich mich problemlos aus meiner aktiven Domäne in meine neue Domäne verbinden. Hier mal die (wie ich vermute) nötige GPO dafür:
Windows-Komponenten/Remotedesktopdienste/Remotedesktopsitzungs-Host/Sicherheit
Richtlinie Einstellung Ausschlaggebendes Gruppenrichtlinienobjekt
Benutzerauthentifizierung mit Authentifizierung auf Netzwerkebene ist für Remoteverbindungen erforderlich Deaktiviert
Die UPDs habe ich mitlerweile ebenfalls mit roaming Profiles in Kombination mit redirected Folders ersetzt. Hier habe ich auch die Empfehlung gegen UPD bekommen. Ich muss aber festhalten: Mit beiden Konfigurationen hatte ich Anfangs Ärger und nach einer Weile liefen sowohl UPDs als auch roaming Profiles unter Testbedingungen einwandfrei, hier sollte man eventuell nicht zu schnell zu verschiedenen Servern connecten.
Ich bin mitlerweile auch weiter in meinem Projekt und hier mal meine Erfahrung:
RDWeb habe ich mir schon angeschaut und die RD Config Datei verschwindet tatsächlich mit der Bereitstellung einer Remote App, sie kommt aber auch wieder wenn man die Bereitstellung aufhebt. Ich habe mir die Datei angeschaut und sie versucht sich auf den RD-CB zu verbinden, was mit gültigen DNS jetzt auch klappt. Wenn mich nicht alles täuscht ist das der funktionierende Failover den ich gesucht habe und ich kann diese Datei auch anderweitig zur Verbindung bereit stellen.
Verbinde ich mich über eine "gewöhnliche" RDP Config auf den RD-CB versucht er mich tatsächlich lokal anzumelden, das scheint mir auch sinnvoll. Verbinde ich mich auf einen RD-SH, egal welchen, werde ich auf einen Server nach Wahl des RD-CB verbunden, das läuft gut. Das Problem der doppelten Anmeldung tritt nach einer erneuten Bereitstellung nicht mehr auf, mein Punkt 2 hat sich erledigt und ich kann nicht sagen woran das im ersten Anlauf gescheitert ist. Das ist natürlich nur in einem Punkt wirklich hinderlich, nämlich wenn der RD-SH, den ich nutze um den ersten Kontakt aufzubauen, offline ist. Ich hätte in diesem Fall also Load-Balancing aber kein Failover der RD-SHs.
Eigentlich setze ich auch RDWeb und Zertifikate nicht ein, ich arbeite noch mit klassischem VPN zur Absicherung. Auch stelle ich keine einzelnen Apps bereit sondern immer einen kompletten Desktop. Die Zertifikate habe ich selbst erstellt und auf meinen RD-CB ausgestellt, wie auf diversen Seiten empfohlen. Wie mit beiden oben beschriebenen Methoden kann ich mich problemlos aus meiner aktiven Domäne in meine neue Domäne verbinden. Hier mal die (wie ich vermute) nötige GPO dafür:
Windows-Komponenten/Remotedesktopdienste/Remotedesktopsitzungs-Host/Sicherheit
Richtlinie Einstellung Ausschlaggebendes Gruppenrichtlinienobjekt
Benutzerauthentifizierung mit Authentifizierung auf Netzwerkebene ist für Remoteverbindungen erforderlich Deaktiviert
Die UPDs habe ich mitlerweile ebenfalls mit roaming Profiles in Kombination mit redirected Folders ersetzt. Hier habe ich auch die Empfehlung gegen UPD bekommen. Ich muss aber festhalten: Mit beiden Konfigurationen hatte ich Anfangs Ärger und nach einer Weile liefen sowohl UPDs als auch roaming Profiles unter Testbedingungen einwandfrei, hier sollte man eventuell nicht zu schnell zu verschiedenen Servern connecten.
