Wie richte ich eine RDS-Farm und USer Profile Disk unter Windows Server 2016 ein?
Hallo Leute,
ich habe hier ein kleines Problem welches mich schon ein paar Tage verfolgt.
Ich habe ein ESXi-Server auf welchem ich 3 Windows Server 2016 VM eingerichtet habe.
Diese sollen zu einer RDS-Farm (nennt man ja so wenn es nicht 'Standalone' sein soll und die Rollen etwas verteilt werden, richtig?).
Ich möchte einen Server als ConnectionBroker und Lizenzierungsserver (WebAccess weiß ich gar nicht ob ich das benötige?) betreiben. Einen weiteren als Fileserver für das User Profile Disk und (momentan) einen als SessionHost, also den eigentlichen 'Terminalserver'.
Ich nenne den ersten (also Connectionbroker UND Lizenzierungsserver) 'srv-rds'.
Den 'User Profile Disk' Fileserver, welcher die Freigabe 'rdprofiles$' hat, nenne ich 'srv-profiles' und den SessionHost 'srv-rdsh01'.
Nebenbei zur Info habe ich die Ressourcen so verteilt:
- srv-rds hat 4 x vCores, 4 GB RAM und eine 80 GB HDD
- srv-profiles hat 4 x vCores, 4GB RAM und 650 GB HDD
- srv-rdsh01 hat 16 x vCores, 50 GB RAM und 50 GB HDD (Profiles werden ja auf User Disk Profile gespeichert und alles andere auf dem Firmen-Fileserver)
All das läuft auf vSphere 6.7.0 unter folgender Hardware:
- 2x Intel Xeon X5690 6 Kerne mit HT 3,47 GHz (insgesamt 12 Kerne und mit HT = 24 vCores)
- 64 GB RAM
- 1,2 TB SAS 15K HDD RAID 5
So, meine Frage ist nun: wie richte ich das alles ein das es auch funktioniert?
Ich habe bereits auf den srv-rds die Rollen 'ConnectionBroker', 'Lizenzierungsserver' und sogar 'RD WebAccess' installiert, auf dem srv-profiles den Fileserver mit der Freigabe 'rdprofiles$' und auf dem srv-rdsh01 die Rolle 'SessionHost'. Ausser den Fileserver habe ich alles von einem ServerManager verteilt indem ich dies auf srv-rds gemacht habe und srv-rdsh01 hinzugefüpgt und dort die Rolle verteilt habe während des Installationsprozesses (gibt ja einige Anleitungen im Web dazu).
Ich habe anschliessend auch eine Sammlung erstellt (ebenfalls nach Anleitung) und die User Profile Disk angelegt. Hat sogar die Profil-Vorlagendatei (vdhx oder so) angelegt.
Auch habe ich erst mit der AD-Gruppe 'Domänenbenutzer' (also alle Domänenmitglieder), und dann einmal mit einer bestimmten Gruppe das eingerichtet. Sprich diese Gruppe dem srv-rdsh01-Server zugeweisen bzw. der Sammlung zugewiesen und diese dem srv-rdsh01 (SessionHost).
Beides mal hat es nicht geklappt!
Es war so das sich irgendein Nicht-Administrator erst gar nicht anmelden konnte weil er nicht in der AD-Gruppe war die Remodesktopanmeldungen ermöglicht.
Administratoren (bzw. User die Mitglieder der Domänen-Administratoren sind) bekommen lediglich ein loakles Profil angelegt und zwar auf dem angemeldeten Server selber (ConnectionBroker bzw. srv-rds).
Zu erwarten war ja daß man auf den srv-rdsh01 geleitet wird und dort sich anmeldet + das auf dem srv-profiles (der User Profile Disk) das Profil des Users angelegt wird.
Somit war das ein Fehlschlag.
So, meine Frage an die Profis ist jetzt folgendes:
1. Welche Verbindungs-Adresse muss ich eigentlich in der Remotedesktopverbindung angeben? (ich bin vom ConnectionBroker ausgegangen)
Nebenbei noch weitere Fagen:
2. Ist meine Aufteilung der Ressourcen so sinnvoll? Die Musik spielt ja auf dem SessionHost und der braucht RAM und CPU, richtig? ConnectionBroker und Lizenzierungsserver brauchen ja nicht viel, oder?
3. Was macht der RD Web Access eigentlich? Wenn ich den im Browser angebe bekomme ich die IIS-Startseite mit den 'Willkommen' auf mehreren Sprachen und das war es.
Ich danke euch schon einmal im Voraus für eure Hilfe oder zumindest für das Lesen bis hierher!
ich habe hier ein kleines Problem welches mich schon ein paar Tage verfolgt.
Ich habe ein ESXi-Server auf welchem ich 3 Windows Server 2016 VM eingerichtet habe.
Diese sollen zu einer RDS-Farm (nennt man ja so wenn es nicht 'Standalone' sein soll und die Rollen etwas verteilt werden, richtig?).
Ich möchte einen Server als ConnectionBroker und Lizenzierungsserver (WebAccess weiß ich gar nicht ob ich das benötige?) betreiben. Einen weiteren als Fileserver für das User Profile Disk und (momentan) einen als SessionHost, also den eigentlichen 'Terminalserver'.
Ich nenne den ersten (also Connectionbroker UND Lizenzierungsserver) 'srv-rds'.
Den 'User Profile Disk' Fileserver, welcher die Freigabe 'rdprofiles$' hat, nenne ich 'srv-profiles' und den SessionHost 'srv-rdsh01'.
Nebenbei zur Info habe ich die Ressourcen so verteilt:
- srv-rds hat 4 x vCores, 4 GB RAM und eine 80 GB HDD
- srv-profiles hat 4 x vCores, 4GB RAM und 650 GB HDD
- srv-rdsh01 hat 16 x vCores, 50 GB RAM und 50 GB HDD (Profiles werden ja auf User Disk Profile gespeichert und alles andere auf dem Firmen-Fileserver)
All das läuft auf vSphere 6.7.0 unter folgender Hardware:
- 2x Intel Xeon X5690 6 Kerne mit HT 3,47 GHz (insgesamt 12 Kerne und mit HT = 24 vCores)
- 64 GB RAM
- 1,2 TB SAS 15K HDD RAID 5
So, meine Frage ist nun: wie richte ich das alles ein das es auch funktioniert?
Ich habe bereits auf den srv-rds die Rollen 'ConnectionBroker', 'Lizenzierungsserver' und sogar 'RD WebAccess' installiert, auf dem srv-profiles den Fileserver mit der Freigabe 'rdprofiles$' und auf dem srv-rdsh01 die Rolle 'SessionHost'. Ausser den Fileserver habe ich alles von einem ServerManager verteilt indem ich dies auf srv-rds gemacht habe und srv-rdsh01 hinzugefüpgt und dort die Rolle verteilt habe während des Installationsprozesses (gibt ja einige Anleitungen im Web dazu).
Ich habe anschliessend auch eine Sammlung erstellt (ebenfalls nach Anleitung) und die User Profile Disk angelegt. Hat sogar die Profil-Vorlagendatei (vdhx oder so) angelegt.
Auch habe ich erst mit der AD-Gruppe 'Domänenbenutzer' (also alle Domänenmitglieder), und dann einmal mit einer bestimmten Gruppe das eingerichtet. Sprich diese Gruppe dem srv-rdsh01-Server zugeweisen bzw. der Sammlung zugewiesen und diese dem srv-rdsh01 (SessionHost).
Beides mal hat es nicht geklappt!
Es war so das sich irgendein Nicht-Administrator erst gar nicht anmelden konnte weil er nicht in der AD-Gruppe war die Remodesktopanmeldungen ermöglicht.
Administratoren (bzw. User die Mitglieder der Domänen-Administratoren sind) bekommen lediglich ein loakles Profil angelegt und zwar auf dem angemeldeten Server selber (ConnectionBroker bzw. srv-rds).
Zu erwarten war ja daß man auf den srv-rdsh01 geleitet wird und dort sich anmeldet + das auf dem srv-profiles (der User Profile Disk) das Profil des Users angelegt wird.
Somit war das ein Fehlschlag.
So, meine Frage an die Profis ist jetzt folgendes:
1. Welche Verbindungs-Adresse muss ich eigentlich in der Remotedesktopverbindung angeben? (ich bin vom ConnectionBroker ausgegangen)
Nebenbei noch weitere Fagen:
2. Ist meine Aufteilung der Ressourcen so sinnvoll? Die Musik spielt ja auf dem SessionHost und der braucht RAM und CPU, richtig? ConnectionBroker und Lizenzierungsserver brauchen ja nicht viel, oder?
3. Was macht der RD Web Access eigentlich? Wenn ich den im Browser angebe bekomme ich die IIS-Startseite mit den 'Willkommen' auf mehreren Sprachen und das war es.
Ich danke euch schon einmal im Voraus für eure Hilfe oder zumindest für das Lesen bis hierher!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 555492
Url: https://administrator.de/forum/wie-richte-ich-eine-rds-farm-und-user-profile-disk-unter-windows-server-2016-ein-555492.html
Ausgedruckt am: 06.04.2025 um 05:04 Uhr
31 Kommentare
Neuester Kommentar
Hi,
ich habe selbst nie den Broker ausprobiert, jedoch kann ich ein paar Teilantworten geben:
Für Serverprofile musst Du noch eine GPO verteilen, sonst bleiben die Profile auch beim Remote Desktop lokal.
Starte mal https://servername/RDweb
ich habe selbst nie den Broker ausprobiert, jedoch kann ich ein paar Teilantworten geben:
Für Serverprofile musst Du noch eine GPO verteilen, sonst bleiben die Profile auch beim Remote Desktop lokal.
Starte mal https://servername/RDweb
Die User müssen noch (manuell oder per GPO) in die Gruppe Renotedesktopbenutzer der jeweiligen Server hinzugefügt werden.
Die Benutze können auch über „mstsc“ direkt zur Adresse des Sitzungshosts, wie früher auch.
Der Vorteil des rdweb ist, dass Du Apps veröffentlichen kannst, die auf mehreren Servern liegen, z.B. Zur Lastverteilung oder einer wird gerade gewartet. Diese Apps brauchen auch keinen ganzen Desktop, sondern öffnet sich als Fenster, als werden sie auf dem lokalen Desktop laufen. So kannst Du mehrere Apps von verschiedenen Servern auf Deinem lokalen Desktop sehen, sogar von Linux aus. Quasi Outlook auf dem Linux Client :c)
Die Benutze können auch über „mstsc“ direkt zur Adresse des Sitzungshosts, wie früher auch.
Der Vorteil des rdweb ist, dass Du Apps veröffentlichen kannst, die auf mehreren Servern liegen, z.B. Zur Lastverteilung oder einer wird gerade gewartet. Diese Apps brauchen auch keinen ganzen Desktop, sondern öffnet sich als Fenster, als werden sie auf dem lokalen Desktop laufen. So kannst Du mehrere Apps von verschiedenen Servern auf Deinem lokalen Desktop sehen, sogar von Linux aus. Quasi Outlook auf dem Linux Client :c)
Moin,
Gruß,
Dani
2. Welchen Mehrwert bringt mir ein RD Gateway sofern ich den einrichten würde?
Mehr Sicherheit. Die Kommunikation läuft über Port 443/tcp. Standardmäßig wird Port 3389/tcp-udp für RDP genutzt. Spielt primär eine Rolle beim Zugriff über das Internet oder bei Datacenter Firewalls.Ich würde gerne den Benutzern ermöglichen ohne dieses "RD WebAccess" sich direkt zu verbinden. Kann man das auch mit der Remotedesktopverbindung bewerkstelligen?
Du kannst bei Verwendung von Collections diese automatisch beim Benutzer einbinden (RD Webfeed), so dass diese im Startmenü erscheinen. RemoteApp von Windows Server 2012 (R2) auf Windows 7/8.x verteilenGruß,
Dani
Wie gesagt, das mit dem Broker habe ich noch nie ausprobiert. Wir greifen, wie früher, auf den Sessionhost direkt zu und haben die User auch auf dem Sessionhost hnzugefügt.
Nicht wirklich die User, sondern nur eine selbst angelegte Sicherheitsgruppe im AD: RDS-User-irgendwas
Beim Anlegen der Benutzer im Active Directory weise ich ihm nur noch diese Sicherheitsgruppe zu und schon darf er auf den Seasionhost.
Da wir mehrere Sessionhosts fahren, habe ich sie alle in einer OU. Sobald ich einen neuen Sessionhost in diese OU schiebe, greift eine GPO, das diese eine Sicherheitsgruppe automatisch zu den lokalen Remotedesktopbenutzern des Sessionhosts hinzufügt. Somit ist gar keine manuelle Konfiguration mehr nötig.
Der Broker und der RDweb existiert zwar auch, aber wir ignorieren es einfach. Wir brauchen die Vorteile nicht
Nicht wirklich die User, sondern nur eine selbst angelegte Sicherheitsgruppe im AD: RDS-User-irgendwas
Beim Anlegen der Benutzer im Active Directory weise ich ihm nur noch diese Sicherheitsgruppe zu und schon darf er auf den Seasionhost.
Da wir mehrere Sessionhosts fahren, habe ich sie alle in einer OU. Sobald ich einen neuen Sessionhost in diese OU schiebe, greift eine GPO, das diese eine Sicherheitsgruppe automatisch zu den lokalen Remotedesktopbenutzern des Sessionhosts hinzufügt. Somit ist gar keine manuelle Konfiguration mehr nötig.
Der Broker und der RDweb existiert zwar auch, aber wir ignorieren es einfach. Wir brauchen die Vorteile nicht
Zitat von @NordicMike:
Wie gesagt, das mit dem Broker habe ich noch nie ausprobiert. Wir greifen, wie früher, auf den Sessionhost direkt zu und haben die User auch auf dem Sessionhost hnzugefügt.
Nicht wirklich die User, sondern nur eine selbst angelegte Sicherheitsgruppe im AD: RDS-User-irgendwas
Beim Anlegen der Benutzer im Active Directory weise ich ihm nur noch diese Sicherheitsgruppe zu und schon darf er auf den Seasionhost.
Da wir mehrere Sessionhosts fahren, habe ich sie alle in einer OU. Sobald ich einen neuen Sessionhost in diese OU schiebe, greift eine GPO, das diese eine Sicherheitsgruppe automatisch zu den lokalen Remotedesktopbenutzern des Sessionhosts hinzufügt. Somit ist gar keine manuelle Konfiguration mehr nötig.
Der Broker und der RDweb existiert zwar auch, aber wir ignorieren es einfach. Wir brauchen die Vorteile nicht
Wie gesagt, das mit dem Broker habe ich noch nie ausprobiert. Wir greifen, wie früher, auf den Sessionhost direkt zu und haben die User auch auf dem Sessionhost hnzugefügt.
Nicht wirklich die User, sondern nur eine selbst angelegte Sicherheitsgruppe im AD: RDS-User-irgendwas
Beim Anlegen der Benutzer im Active Directory weise ich ihm nur noch diese Sicherheitsgruppe zu und schon darf er auf den Seasionhost.
Da wir mehrere Sessionhosts fahren, habe ich sie alle in einer OU. Sobald ich einen neuen Sessionhost in diese OU schiebe, greift eine GPO, das diese eine Sicherheitsgruppe automatisch zu den lokalen Remotedesktopbenutzern des Sessionhosts hinzufügt. Somit ist gar keine manuelle Konfiguration mehr nötig.
Der Broker und der RDweb existiert zwar auch, aber wir ignorieren es einfach. Wir brauchen die Vorteile nicht
Und wie verteilst du die Leute dann auf die SessionHost ? Zb wenn ein Host ausfällt? Etwas mit DNS round Robin? Das was man schon lange nicht mehr machen soll?
Korrekt wäre sich auf den Broker zu Connection und der verteilt die User an die Hosts. Dafür ist entweder ein DNS Eintrag notwendig der auf die ip vom Broker zeigt + ein reg Eintrag (TSVUrl) direkt auf dem Broker , oder eine RDP Datei in der eine bestimmte Zeile (TSVUrl)drin steht.
Da ich hier über 200 Igel Thin Clients habe nutze ich es wie folgt.
- DNS Eintrag RDS-2k19.domain.hilfe zeigt auf Broker IP
- Registry Eintrag setzen (Auszug von einer anderen Seite)
HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\ClusterSettings
DefaultTsvUrl tsv://VMResource.1.RDS-2k19
Die Sammlung muss natürlich auch so heißen.
Falls man später direkt auf den Broker sich connecten will für Wartungen oder Ähnliches, muss man mstsc im Administratormodus öffnen -> mstsc /admin
Ps.: die default vhdx fasse ich nie an, da ich alle Settings über gpo für die User festlege
Und wie verteilst du die Leute dann auf die SessionHost?
Guter Einwand, gar nicht :c)Die paar Session Hosts sind nicht redundant ausgelegt. Ich habe für diverse Abteilungen oder Softwareanforderungen diverse Aliase für die Session Hosts. Somit werden sie bestimmten Session Hosts zugewiesen und bleiben auch dort. Wenn einer ausfällt, schiebe ich die VMs auf einen anderen Hyper-V Host.
Ich arbeite mit Unbekannten selbst gestrickten RDP Clients, die von Linux Thin Clients aus zugreifen. Ich habe nicht ermittelt wie sich die Clients verhalten würden, wenn diese auf den Broker zugreifen würden, statt auf einen direkten Session Host, sie befinden sich auch nicht in der Windows Domäne. Mein Chef wollte den Broker auch gar nicht, da die Abteilungen auf den anderen Session Hosts ihre speziellen Programme nicht finden würden.
In dem Broker Thema habe ich ebenfalls Wissensdefizite, wie der Fragesteller auch, aber ich vermute stark, dass der Broker nicht mit jedem Linux RDP Client arbeitet.
Wieso die Frage? Was hat der RAID-Level mit der Performance direkt zu tun? Klar kann man auf noch mehr verteilte Platten ein paar Prozentpunkte mehr 'herauskitzeln', aber im großen und ganzen verstehe ich die Frage jetzt nicht wirklich? Habei ch was übersehen?
Naja die Frage ist wo die VHDX liegne und wie viel Leute schreiben etc Dafür ist wiederum die Lesegeschwindigkeit gut
HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\ClusterSettings\DefaultTsvUrl
tsv://MS Terminal Services Plugin.1.Firma_Alle
Nur der letzte Abschnitt nach dem letzten Punkt ist indivudell.
genautsv://MS Terminal Services Plugin.1.Firma_Alle
Nur der letzte Abschnitt nach dem letzten Punkt ist indivudell.
"Firma Alle" (ohne Anführunszeichen) ist der Name des Sammlung / Collection.
Moin,
Gruß,
Dani
Ok, also mit diesen 'Workressources' über WebFeed würde es gehen. Aber einfach wie bisher den Remodesktop zu starten und dann die Adresse des Zielservers eingeben und sich dann Anmelden geht so nicht mehr?
ist dann aber auch nicht mehr notwendig. Denn der Anwender sieht die Anwendungen im Startmenü bzw. auf dem Desktop und kann sofort diese starten. Bei richtiger Konfiguration von SingleSignOn (SSO) sind nicht mal eine Anmeldedaten für die RDP Sitzung notwendig.Gruß,
Dani
Zitat von @kaineanung:
Keiner eine Ahnung was ich auf dem ConnectionBroker ändern müsste damit es wieder funktioniert das eine direkte RDP-Verbindung zum CB auf den hinterlegten SessionHost umgeleitet wird?
Keiner eine Ahnung was ich auf dem ConnectionBroker ändern müsste damit es wieder funktioniert das eine direkte RDP-Verbindung zum CB auf den hinterlegten SessionHost umgeleitet wird?
Naja...was erscheint denn jetzt für eine Fehlermeldung? Denn Grundsätzlich funktionert das...wird zu tausendfach so gehandhabt
Das ist aber nebensächlich geworden. Was mich zu dem ganzen Thema noch viel mehr interessiert ist:
ich habe bemerkt das einige RDS-Lizenzen nicht 'gezogen' wurden von neu angemeldeten Benutzern (RD Lizenzierungsserver zeigt ja die Zuteilungen an wann wem für wie lange eine RDS-User-Lizenz zugewiesen wurde).
Kann es eventuell sein das sich User von zu Hause auf den Server anmelden und der Lizenzserver vergisst eine Lizenz auszustellen? Wieso konnte der User sich aber (nachweislich) anmelden?
wie weißt du das nach? Worüber hat er sich angemeldet? direkt am Host ?ich habe bemerkt das einige RDS-Lizenzen nicht 'gezogen' wurden von neu angemeldeten Benutzern (RD Lizenzierungsserver zeigt ja die Zuteilungen an wann wem für wie lange eine RDS-User-Lizenz zugewiesen wurde).
Kann es eventuell sein das sich User von zu Hause auf den Server anmelden und der Lizenzserver vergisst eine Lizenz auszustellen? Wieso konnte der User sich aber (nachweislich) anmelden?