13
Planung RDS Farm mit Windows 2012 R2
Hi,
ich bin dabei eine neue RDS Farm mit Windows Server 2012 R2 zu planen.
Aktuell sind 2 alte Terminal Server 2008 R2 mit ca. 25 von 200 Usern gleichzeitig aktiv.
Es werden fast ausschließlich Office-Anwendungen genutzt, die Last ist also überschaubar.
Ich gehe davon aus, dass die Zahl der aktiven User im Laufe des kommenden Jahres auf ca. 50 steigt.
Ich habe nun diverse Guides gelesen und mit diesen eine kleine virtuelle Testumgebung aufgebaut.
Aktuell sieht meine Planung so aus:
Mir ist bewusst, dass das nicht dem Microsoft Best-Practice entspricht, welches eigentlich für jede Rolle einen eigenen Server empfiehlt. Ich denke jedoch, dass dies bei der Anzahl der Anwender ok sein sollte.
Wegen der doch recht hohen Komplexität mit dem SQL Server würde ich den Connection Broker auch nicht clustern.
Zu dem Konstrukt hätte ich nun folgende Fragen, welche in den Guides leider nicht so recht beantwortet werden:
Danke.
Grüße,
Daniel
ich bin dabei eine neue RDS Farm mit Windows Server 2012 R2 zu planen.
Aktuell sind 2 alte Terminal Server 2008 R2 mit ca. 25 von 200 Usern gleichzeitig aktiv.
Es werden fast ausschließlich Office-Anwendungen genutzt, die Last ist also überschaubar.
Ich gehe davon aus, dass die Zahl der aktiven User im Laufe des kommenden Jahres auf ca. 50 steigt.
Ich habe nun diverse Guides gelesen und mit diesen eine kleine virtuelle Testumgebung aufgebaut.
Aktuell sieht meine Planung so aus:
- RD Connection Broker, RD Web Access
- rds01.example.intern (Alias rds.example.intern)
- RD Gateway, RD Licensing
- rds02.example.intern / access.example.extern
- RD Session Hosts
- rds03.example.intern
- rds04.example.intern
- rds05.example.intern
Mir ist bewusst, dass das nicht dem Microsoft Best-Practice entspricht, welches eigentlich für jede Rolle einen eigenen Server empfiehlt. Ich denke jedoch, dass dies bei der Anzahl der Anwender ok sein sollte.
Wegen der doch recht hohen Komplexität mit dem SQL Server würde ich den Connection Broker auch nicht clustern.
Zu dem Konstrukt hätte ich nun folgende Fragen, welche in den Guides leider nicht so recht beantwortet werden:
- Mir sind die Zugriffswege noch unklar, besonders was den RD Gateway betrifft. Ich habe Anwender, welche von extern zugreifen. Wenn es irgendwie geht, soll hier sämtlicher Traffic ausschließlich über https/443 laufen. Da dies schlecht für die Performance ist, sollten interne Anwender dagegen einen normalen Zugriff haben, welcher nicht alle Pakete in HTTPS kapselt.
- Interne User greifen dazu vermutlich über den RDP Client auf rds.example.intern oder über den Browser auf https://rds.example.intern/rdweb zu, oder?
- Für externe User wurde zwar unter https://access.example.com mit der RD Gateway Rolle ein IIS installiert, dieser hat jedoch keine Unterseite /rdweb? Wie sieht der Zugriff für Externe denn dann aus?
- Angenommen der rds01 fällt aus. Hat das eine Auswirkung auf bestehende Sessions?
- Angenommen der rds02 fällt aus. Hat das eine Auswirkung auf Sessions von Usern aus dem internen Netz?
- Diverse Guides legen einen DNS Round-Robin für die Session Hosts an. Wozu?
- Aktuell liegen die User-Profile auf den Terminal-Servern. Bei dieser Farm denke ist wäre es besser, diese auf ein Netzlaufwerk zu legen. Ich bin mir da jedoch unsicher was die Performance angeht, da einige User ein Outlook Profil von 5-10 GB haben (Wir verwenden Kerio Connect). Meinungen dazu?
Danke.
Grüße,
Daniel
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 325132
Url: https://administrator.de/contentid/325132
Printed on: April 24, 2024 at 16:04 o'clock
13 Comments
Latest comment
Moin Dani,
Gruß,
Dani
Mir sind die Zugriffswege noch unklar, besonders was den RD Gateway betrifft. Ich habe Anwender, welche von extern zugreifen. Wenn es irgendwie geht, soll hier sämtlicher Traffic ausschließlich über https/443 laufen. Da dies schlecht für die Performance ist, sollten interne Anwender dagegen einen normalen Zugriff haben, welcher nicht alle Pakete in HTTPS kapselt.
Wo hast du das gelesen? Ich kann dir sagen, dass ist so nicht richtig. Das GW hat den Vorteil, dass du evtl. in zentrale Firewalls keine riesen Löcher bohren musst. Es ist völlig rausreichend, wenn das Gateway via HTTP(S), ICMP erreichbar ist.Mir ist bewusst, dass das nicht dem Microsoft Best-Practice entspricht, welches eigentlich für jede Rolle einen eigenen Server empfiehlt. Ich denke jedoch, dass dies bei der Anzahl der Anwender ok sein sollte.
Ich wüde RDGW und RDWEB auf einem gemeinsamen Server installieren. Den RDCB und RDLIC auf der anderen VM.Angenommen der rds01 fällt aus. Hat das eine Auswirkung auf bestehende Sessions?
Ja. Die Verbindung wird unterbrochen.Angenommen der rds02 fällt aus. Hat das eine Auswirkung auf Sessions von Usern aus dem internen Netz?
Nein.Diverse Guides legen einen DNS Round-Robin für die Session Hosts an. Wozu?
Macht für mich nur Sinn, wenn du kein RDCB bzw. RDGW hast und beide Sessionhosts identisch eingerichtet sind.Gruß,
Dani
Hi,
Für mich ist das mehr oder weniger klar, dass gekapselter Traffic schlecht für die Performance ist.
Wenn ich dich richtig verstehe, würdest du alle User direkt auf access.example.extern zugreifen lassen, egal ob interne oder externe User?
Zitat von @Dani:
Wo hast du das gelesen? Ich kann dir sagen, dass ist so nicht richtig. Das GW hat den Vorteil, dass du evtl. in zentrale Firewalls keine riesen Löcher bohren musst. Es ist völlig rausreichend, wenn das Gateway via HTTP(S), ICMP erreichbar ist.
Also so direkt gelesen habe ich das nirgends, auch wenn es ein paar "Mein RD Gateway ist langsam" Themen bei Microsoft gibt.Wo hast du das gelesen? Ich kann dir sagen, dass ist so nicht richtig. Das GW hat den Vorteil, dass du evtl. in zentrale Firewalls keine riesen Löcher bohren musst. Es ist völlig rausreichend, wenn das Gateway via HTTP(S), ICMP erreichbar ist.
Für mich ist das mehr oder weniger klar, dass gekapselter Traffic schlecht für die Performance ist.
Wenn ich dich richtig verstehe, würdest du alle User direkt auf access.example.extern zugreifen lassen, egal ob interne oder externe User?
Ich wüde RDGW und RDWEB auf einem gemeinsamen Server installieren. Den RDCB und RDLIC auf der anderen VM.
Darüber habe ich auch schon nachgedacht, allerdings bekommt man dann eine Warnung, dass man jetzt nur noch ein gemeinsames Zertifikat für RD Gateway und RD Web Access verwenden soll. Ich dachte bisher, ich brauche 2, siehe oben.
Moin,
Gruß,
Dani
Wenn ich dich richtig verstehe, würdest du alle User direkt auf access.example.extern zugreifen lassen, egal ob interne oder externe User?
Ja. Ich sehe da in der Größe keine Hürden.Darüber habe ich auch schon nachgedacht, allerdings bekommt man dann eine Warnung, dass man jetzt nur noch ein gemeinsames Zertifikat für RD Gateway und RD Web Access verwenden soll.
Worin siehst du in der Warnung ein Problem? Es ist aus meiner Sicht völlig logisch, dass damit nur noch ein Zertifikat benötigt wird. Was indirekt den Geldbeutel schont. Gruß,
Dani
Hi,
Ich hatte das falsch verstanden. Bei meiner ersten Test-Installation hat der RD Gateway nicht sauber installiert und kein Web-Interface bereitgestellt.
Zusammen mit der Warnung hatte ich dann einen Denkfehler ;)
Eine Frage hätte ich noch:
Ich habe nun die ganze Testumgebung neu aufgesetzt und testweise alle 4 Rollen auf rds01 installiert. rds02 ist aus und rds03 und rds04 sind die Session Hosts. Das funktioniert bisher ganz gut.
Weiterhin habe ich auf einem Test-Client das Zertifikat aus vertrauenswürdig hinzugefügt.
Ein Login sieht jedoch für den User wie folgt aus:
Kann man Punkt 5 und 6 unterdrücken?
Eigentlich würde ich erwarten, dass das Webinterface die Login-Credentials weiterleitet und eine Single Sign On ermöglicht, wie bei Citrix halt auch?
Zitat von @Dani:
Worin siehst du in der Warnung ein Problem? Es ist aus meiner Sicht völlig logisch, dass damit nur noch ein Zertifikat benötigt wird. Was indirekt den Geldbeutel schont.
Worin siehst du in der Warnung ein Problem? Es ist aus meiner Sicht völlig logisch, dass damit nur noch ein Zertifikat benötigt wird. Was indirekt den Geldbeutel schont.
Ich hatte das falsch verstanden. Bei meiner ersten Test-Installation hat der RD Gateway nicht sauber installiert und kein Web-Interface bereitgestellt.
Zusammen mit der Warnung hatte ich dann einen Denkfehler ;)
Eine Frage hätte ich noch:
Ich habe nun die ganze Testumgebung neu aufgesetzt und testweise alle 4 Rollen auf rds01 installiert. rds02 ist aus und rds03 und rds04 sind die Session Hosts. Das funktioniert bisher ganz gut.
Weiterhin habe ich auf einem Test-Client das Zertifikat aus vertrauenswürdig hinzugefügt.
Ein Login sieht jedoch für den User wie folgt aus:
- User ruft https://access.example.extern/rdweb auf (Zertifikat ist clean)
- User meldet sich mit mit dem AD Account an
- User klickt auf eine App, wodurch der Download einer .rdp Datei startet
- User wählt im Brower "öffnen" aus
- User bekommt eine Meldung, dass er dem Remote-Computer rds01 vertrauen soll (in blau, kein gelbes Ausrufezeichen, Zertifikat ist clean)
- User muss nochmal sein Passwort eingeben
Kann man Punkt 5 und 6 unterdrücken?
Eigentlich würde ich erwarten, dass das Webinterface die Login-Credentials weiterleitet und eine Single Sign On ermöglicht, wie bei Citrix halt auch?
Moin,
Gruß,
Dani
Kann man Punkt 5 und 6 unterdrücken?
wenn ich dich richtig verstanden habe, Ja. Nennt sich Single Sign On...Gruß,
Dani
Hi,
Ja, schon klar.
Aber sollte das Out-of-the-Box funktionieren oder ist dafür weitere Konfiguration erforderlich?
Laut einem Guide sollte es Out-of-the-Box funktionieren:
Das passt jedoch nicht zu meinen Tests, wo es eben nicht funktioniert.
Zitat von @Dani:
Kann man Punkt 5 und 6 unterdrücken?
wenn ich dich richtig verstanden habe, Ja. Nennt sich Single Sign On...Ja, schon klar.
Aber sollte das Out-of-the-Box funktionieren oder ist dafür weitere Konfiguration erforderlich?
Laut einem Guide sollte es Out-of-the-Box funktionieren:
Vorkonfiguriertes SSO in RD Web Access
Am einfachsten erlangt man unter Windows Server 2012 ein Single-Sign-on mittels RD Web Access, weil es keine separate Konfiguration erfordert. Zwar muss man sich auch dort eigens über das HTML-Formular anmelden, weil ja auch der Zugang von beliebigen Clients außerhalb der Domäne möglich ist. Danach lassen sich aber alle Desktops und RemoteApp über die Web-Seite ohne weitere Eingabe von Kennwörtern starten.
Quelle: https://www.windowspro.de/wolfgang-sommergut/single-sign-sso-fuer-termin ...Am einfachsten erlangt man unter Windows Server 2012 ein Single-Sign-on mittels RD Web Access, weil es keine separate Konfiguration erfordert. Zwar muss man sich auch dort eigens über das HTML-Formular anmelden, weil ja auch der Zugang von beliebigen Clients außerhalb der Domäne möglich ist. Danach lassen sich aber alle Desktops und RemoteApp über die Web-Seite ohne weitere Eingabe von Kennwörtern starten.
Das passt jedoch nicht zu meinen Tests, wo es eben nicht funktioniert.
Das hier durchlesen und nachmachen danach läuft SSO wie Schmidts Katze:
Windows 2012 R2 – How to Create a (Mostly) Seamless Logon Experience For Your Remote Desktop Services Environment
Gruß mik
Windows 2012 R2 – How to Create a (Mostly) Seamless Logon Experience For Your Remote Desktop Services Environment
Gruß mik
Hat sich erledigt, die Anleitung die ich hatte ist einfach falsch. Ich habe das noch in ein paar anderen Guides gefunden, offenbar kopiert da einer vom anderen.
Man braucht eine GPO, wie hier beschrieben: http://woshub.com/sso-single-sign-on-authentication-on-rds/
Die meisten GPO-Pfade in der Anleitung sind zwar falsch und man darf Punkt 2 (IIS) nicht umsetzen, aber damit läuft das Ganze jetzt.
Man braucht eine GPO, wie hier beschrieben: http://woshub.com/sso-single-sign-on-authentication-on-rds/
Die meisten GPO-Pfade in der Anleitung sind zwar falsch und man darf Punkt 2 (IIS) nicht umsetzen, aber damit läuft das Ganze jetzt.
Hi,
eine Frage ist jetzt doch noch aufgetaucht:
Wenn ein User sich über das RD Web Access einloggt, funktioniert alles einwandfrei.
Versucht ein User jedoch, sich per RDP zu rds.example.com (CNAME auf den Connection Broker rds01.example.com) zu verbinden, dann wird er von dort nicht auf einen Session Host umgeleitet. Statt dessen findet der Login direkt am rds01 statt, wo sich ein normaler User mangels Admin-Rechten nicht einloggen kann.
Ein direkter RDP Login direkt auf einen der Session Hosts funktioniert jedoch.
eine Frage ist jetzt doch noch aufgetaucht:
Zitat von @Dani:
Diverse Guides legen einen DNS Round-Robin für die Session Hosts an. Wozu?
Macht für mich nur Sinn, wenn du kein RDCB bzw. RDGW hast und beide Sessionhosts identisch eingerichtet sind.Wenn ein User sich über das RD Web Access einloggt, funktioniert alles einwandfrei.
Versucht ein User jedoch, sich per RDP zu rds.example.com (CNAME auf den Connection Broker rds01.example.com) zu verbinden, dann wird er von dort nicht auf einen Session Host umgeleitet. Statt dessen findet der Login direkt am rds01 statt, wo sich ein normaler User mangels Admin-Rechten nicht einloggen kann.
Ein direkter RDP Login direkt auf einen der Session Hosts funktioniert jedoch.
Les das mal, dann weißt du wieso das so ist:
http://microsoftplatform.blogspot.de/2012/04/rd-connection-broker-ha-an ...
http://microsoftplatform.blogspot.de/2012/04/rd-connection-broker-ha-an ...
Hi,
für mich macht das alles irgendwie keinen Sinn.
rds.example.com ist der Name, welchen ich im DNS angelegt habe:
rds.example.com -> CNAME auf rds01.example.com
Weiterhin habe ich rds.example.com als FQDN für den RD Gateway eingetragen.
Für mich ist rds.example.com also der Name der ganzen Farm. In der Produktivumgebung würde ich nun auch ein SSL Zertifikat für rds.example.com kaufen.
Irgendwas passt da jedoch noch nicht:
Wenn man sich über Web Access verbindet (funktioniert) steht in der Titel-Leiste der RDP Verbindung "rds01.example.com". WTF.
Hier ein RDP File vom Web Access:
Die Werte für gatewayhostname und für loadbalanceinfo sehen für mich richtg aus, so habe ich das in den Assistenten eingegeben.
Die Werte für full address, workspace id und alternate full address sind für mich falsch. Hier wurde offenbar der Hostname des Connection Brokers übernommen.
Ich habe das Gefühl, dass man an irgend einer Stelle noch den zentralen Namen der Farm umstellen muss.
Leider kann ich kein Guide finden, das näher auf den "Farm Name" eingeht.
Zitat von @131381:
Les das mal, dann weißt du wieso das so ist:
http://microsoftplatform.blogspot.de/2012/04/rd-connection-broker-ha-an ...
Les das mal, dann weißt du wieso das so ist:
http://microsoftplatform.blogspot.de/2012/04/rd-connection-broker-ha-an ...
für mich macht das alles irgendwie keinen Sinn.
rds.example.com ist der Name, welchen ich im DNS angelegt habe:
rds.example.com -> CNAME auf rds01.example.com
Weiterhin habe ich rds.example.com als FQDN für den RD Gateway eingetragen.
Für mich ist rds.example.com also der Name der ganzen Farm. In der Produktivumgebung würde ich nun auch ein SSL Zertifikat für rds.example.com kaufen.
Irgendwas passt da jedoch noch nicht:
Wenn man sich über Web Access verbindet (funktioniert) steht in der Titel-Leiste der RDP Verbindung "rds01.example.com". WTF.
Hier ein RDP File vom Web Access:
redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:0
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
prompt for credentials on client:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
videoplaybackmode:i:1
audiocapturemode:i:1
gatewayusagemethod:i:2
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:RDS01.EXAMPLE.COM
gatewayhostname:s:rds.example.com
workspace id:s:rds01.example.com
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.Example
use multimon:i:1
alternate full address:s:RDS01.EXAMPLE.COM
signscope:s:Full Address,Alternate Full Address,Use Redirection Server Name,Server Port,GatewayHostname,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,PromptCredentialOnce,RedirectDrives,RedirectPrinters,RedirectCOMPorts,RedirectSmartCards,RedirectClipboard,DevicesToRedirect,DrivesToRedirect,LoadBalanceInfo
signature:s:[...]Die Werte für full address, workspace id und alternate full address sind für mich falsch. Hier wurde offenbar der Hostname des Connection Brokers übernommen.
Ich habe das Gefühl, dass man an irgend einer Stelle noch den zentralen Namen der Farm umstellen muss.
Leider kann ich kein Guide finden, das näher auf den "Farm Name" eingeht.
Hi,
Ich habe gerade das hier gefunden und getestet:
https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
Damit kann man full address und alternate full address ändern, aber die workspace id steht immer noch auf dem falschen Wert.
Mit einem angepasstem RDP File - wie in dem Link erklärt - funktioniert die Verbindung, was für den User natürlich total intransparent ist.
Nur einmal will ich erleben, dass was von Microsoft "out-of-the-box" funktioniert
Zitat von @quin83:
Ich habe das Gefühl, dass man an irgend einer Stelle noch den zentralen Namen der Farm umstellen muss.
Leider kann ich kein Guide finden, das näher auf den "Farm Name" eingeht.
Ich habe das Gefühl, dass man an irgend einer Stelle noch den zentralen Namen der Farm umstellen muss.
Leider kann ich kein Guide finden, das näher auf den "Farm Name" eingeht.
Ich habe gerade das hier gefunden und getestet:
https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
Damit kann man full address und alternate full address ändern, aber die workspace id steht immer noch auf dem falschen Wert.
Mit einem angepasstem RDP File - wie in dem Link erklärt - funktioniert die Verbindung, was für den User natürlich total intransparent ist.
Nur einmal will ich erleben, dass was von Microsoft "out-of-the-box" funktioniert
Is aber so, mstsc hat keine GUI Optionen um die Collection anzugeben zu die der User verbunden werden soll, also ist anpassen und signieren der RDP Files angesagt. Gerade deswegen macht man das ganze ja per SSO das der User sich damit überhaupt nicht auseinandersetzen muss, sondern einfach auf sein Icon klickt und verbunden ist und alles ist gut!
Der Farmname sollte also auch auf den Connectionbroker zeigen. Du wirst bei der Einrichtung einfach noch einen Fehler zu haben.
Wenn alles von selbst ginge wären wir als Admins ja arbeitslos
Der Farmname sollte also auch auf den Connectionbroker zeigen. Du wirst bei der Einrichtung einfach noch einen Fehler zu haben.
Wenn alles von selbst ginge wären wir als Admins ja arbeitslos
