15
2 Terminalserver (Windows Server 2019) über EINEN FQDN erreichen - geht nicht
Hallo zusammen.
Ziel ist es 2 Terminalserver für alle User über einen einzigen FQDN erreichbar zu machen.
Wichtig: kein Loadbalancer - jeder User wird per Sicherheitsgruppe einem bestimmten Terminalserver zugeordnet.
Wie würdet ihr das realisieren?
Aktuelle Konfiguration (funktioniert nicht, wie gewünscht):
Server Broker: hier wurden 2 Sammlungen angelegt
- Sammlung 1 beinhaltet Terminalserver 1 + Berechtigung der Sicherheitsgruppe 1 diesen Server zu nutzen
- Sammlung 2 beinhaltet Terminalserver 2 + Berechtigung der Sicherheitsgruppe 2 diesen Server zu nutzen
Ein HOST-A Eintrag für den Broker wurde am DNS-Server gesetzt. Ziel sollte es sein, dass die User diesen FQDN für ihre Remotedesktop-Session nutzen und der Broker leitet dann entsprechend des Users in der Sammlung an den entsprechenden Terminalserver weiter. Und das funktioniert nicht. Das Ereignislog zeigt unter Ereignis-ID 1306 Fehler an (siehe Screenshot), dass der Benutzer nicht umgeleitet werden konnte.
Wir sind für jeden Tipp dankbar.
Ziel ist es 2 Terminalserver für alle User über einen einzigen FQDN erreichbar zu machen.
Wichtig: kein Loadbalancer - jeder User wird per Sicherheitsgruppe einem bestimmten Terminalserver zugeordnet.
Wie würdet ihr das realisieren?
Aktuelle Konfiguration (funktioniert nicht, wie gewünscht):
Server Broker: hier wurden 2 Sammlungen angelegt
- Sammlung 1 beinhaltet Terminalserver 1 + Berechtigung der Sicherheitsgruppe 1 diesen Server zu nutzen
- Sammlung 2 beinhaltet Terminalserver 2 + Berechtigung der Sicherheitsgruppe 2 diesen Server zu nutzen
Ein HOST-A Eintrag für den Broker wurde am DNS-Server gesetzt. Ziel sollte es sein, dass die User diesen FQDN für ihre Remotedesktop-Session nutzen und der Broker leitet dann entsprechend des Users in der Sammlung an den entsprechenden Terminalserver weiter. Und das funktioniert nicht. Das Ereignislog zeigt unter Ereignis-ID 1306 Fehler an (siehe Screenshot), dass der Benutzer nicht umgeleitet werden konnte.
Wir sind für jeden Tipp dankbar.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670871
Url: https://administrator.de/forum/2-terminalserver-windows-server-2019-ueber-einen-fqdn-erreichen-geht-nicht-670871.html
Ausgedruckt am: 03.03.2025 um 22:03 Uhr
15 Kommentare
Neuester Kommentar
Moin,
Ganz pragmatisch zwei Namen verwenden und die auf die IP jeweiligen Hosts auflösen.
Ist nicht das was Du hören willst, geht aber am einfachsten und schnellsten.
lks
1
Erst einmal Danke für deine Antwort.
Ne, aktuell haben wir das ja so, wie du gerade beschrieben hast, am Laufen.
Wir benötigen aber das Szenario mit nur einem FQDN für beide TS, damit die User auch beim Wechsel der Arbeitsstation, auf die für sie gewohnte Verknüpfung klicken können und trotzdem auf dem richtigen Terminalserver landen. Die Verknüpfung soll immer gleich heißen und je nach User eben auf dem richtigen TS zeigen. Wichtig zu erwähnen: die User-Authentifizierung erfolgt erst beim Aufbau der RDP-Session.
Ne, aktuell haben wir das ja so, wie du gerade beschrieben hast, am Laufen.
Wir benötigen aber das Szenario mit nur einem FQDN für beide TS, damit die User auch beim Wechsel der Arbeitsstation, auf die für sie gewohnte Verknüpfung klicken können und trotzdem auf dem richtigen Terminalserver landen. Die Verknüpfung soll immer gleich heißen und je nach User eben auf dem richtigen TS zeigen. Wichtig zu erwähnen: die User-Authentifizierung erfolgt erst beim Aufbau der RDP-Session.
Ähm, Netzwerknamen und Netzwerkadressen müssen doch immer eindeutig sein.
Ich würde das über den Connection Broker und Collections mit Berechtigungsgruppen lösen.
So wird das bei unserer Terminalserverfarm gemacht.
In unserer Terminalserverfarm mit über 250 Hosts, sind verschiedene Collections und Berechtigungsgruppen eingerichtet. Damit wird der Zugriff auf die Terminalserver oder Remote Apps gesteuert.
Gruss Penny.
Ich würde das über den Connection Broker und Collections mit Berechtigungsgruppen lösen.
So wird das bei unserer Terminalserverfarm gemacht.
In unserer Terminalserverfarm mit über 250 Hosts, sind verschiedene Collections und Berechtigungsgruppen eingerichtet. Damit wird der Zugriff auf die Terminalserver oder Remote Apps gesteuert.
Gruss Penny.
1
Moin
Dann leitest Du den Desktop der Benutzer um (was ja ohnehin wg. Backup vorteilhaft ist) und schon haben die User auf allen Rechnern ihre persnliche Verknüpfung.
So wie Du dir das vorstellst, wird es m.E. nicht funktioniern können.
Gruß
Dann leitest Du den Desktop der Benutzer um (was ja ohnehin wg. Backup vorteilhaft ist) und schon haben die User auf allen Rechnern ihre persnliche Verknüpfung.
So wie Du dir das vorstellst, wird es m.E. nicht funktioniern können.
Gruß
1
Moin,
Hört sich danach an, als wären die Rechner bereits mit einem allgemeine Account angemeldet !?
Wenn dem so ist, kann ich mir nicht vorstellen, wie das technisch unter diesem Umständen funktionieren kann.
Sollten es nur die beiden Gruppen sein, könnte man die zwei Symbole für die RDP-Verknüpfungen grafisch besser darstellen...
Gruß und viel Erfolg
Wir benötigen aber das Szenario mit nur einem FQDN für beide TS, damit die User auch beim Wechsel der Arbeitsstation, auf die für sie gewohnte Verknüpfung klicken können und trotzdem auf dem richtigen Terminalserver landen. Die Verknüpfung soll immer gleich heißen und je nach User eben auf dem richtigen TS zeigen. Wichtig zu erwähnen: die User-Authentifizierung erfolgt erst beim Aufbau der RDP-Session.
Hört sich danach an, als wären die Rechner bereits mit einem allgemeine Account angemeldet !?
Wenn dem so ist, kann ich mir nicht vorstellen, wie das technisch unter diesem Umständen funktionieren kann.
Sollten es nur die beiden Gruppen sein, könnte man die zwei Symbole für die RDP-Verknüpfungen grafisch besser darstellen...
Gruß und viel Erfolg
Zitat von @Penny.Cilin:
Ähm, Netzwerknamen und Netzwerkadressen müssen doch immer eindeutig sein.
Ich würde das über den Connection Broker und Collections mit Berechtigungsgruppen lösen.
So wird das bei unserer Terminalserverfarm gemacht.
In unserer Terminalserverfarm mit über 250 Hosts, sind verschiedene Collections und Berechtigungsgruppen eingerichtet. Damit wird der Zugriff auf die Terminalserver oder Remote Apps gesteuert.
Gruss Penny.
Ähm, Netzwerknamen und Netzwerkadressen müssen doch immer eindeutig sein.
Ich würde das über den Connection Broker und Collections mit Berechtigungsgruppen lösen.
So wird das bei unserer Terminalserverfarm gemacht.
In unserer Terminalserverfarm mit über 250 Hosts, sind verschiedene Collections und Berechtigungsgruppen eingerichtet. Damit wird der Zugriff auf die Terminalserver oder Remote Apps gesteuert.
Gruss Penny.
Netzwerknamen und Adressen sind doch eindeutig. Der FQDN für die RDP-Sessions zeigt auf den Connection Broker. Sammlungen und Berechtigungsgruppen sind nach Vorgabe verteilt. Die Frage ist: was muss noch konfiguriert werden und wo muss der FQDN hinzeigen?
Zitat von @Hubert.N:
Moin
Dann leitest Du den Desktop der Benutzer um (was ja ohnehin wg. Backup vorteilhaft ist) und schon haben die User auf allen Rechnern ihre persnliche Verknüpfung.
So wie Du dir das vorstellst, wird es m.E. nicht funktioniern können.
Gruß
Moin
Dann leitest Du den Desktop der Benutzer um (was ja ohnehin wg. Backup vorteilhaft ist) und schon haben die User auf allen Rechnern ihre persnliche Verknüpfung.
So wie Du dir das vorstellst, wird es m.E. nicht funktioniern können.
Gruß
Hier geht es eher um ein lizenztechnisches Problem einer Software, die eben nur auf einem von den beiden Terminalservern zur Verfügung steht. Deswegen ist vorbestimmt welcher User auf welchem Server arbeiten soll.
Zitat von @ElmerAcmeee:
Moin,
Hört sich danach an, als wären die Rechner bereits mit einem allgemeine Account angemeldet !?
Wenn dem so ist, kann ich mir nicht vorstellen, wie das technisch unter diesem Umständen funktionieren kann.
Sollten es nur die beiden Gruppen sein, könnte man die zwei Symbole für die RDP-Verknüpfungen grafisch besser darstellen...
Gruß und viel Erfolg
Moin,
Wir benötigen aber das Szenario mit nur einem FQDN für beide TS, damit die User auch beim Wechsel der Arbeitsstation, auf die für sie gewohnte Verknüpfung klicken können und trotzdem auf dem richtigen Terminalserver landen. Die Verknüpfung soll immer gleich heißen und je nach User eben auf dem richtigen TS zeigen. Wichtig zu erwähnen: die User-Authentifizierung erfolgt erst beim Aufbau der RDP-Session.
Hört sich danach an, als wären die Rechner bereits mit einem allgemeine Account angemeldet !?
Wenn dem so ist, kann ich mir nicht vorstellen, wie das technisch unter diesem Umständen funktionieren kann.
Sollten es nur die beiden Gruppen sein, könnte man die zwei Symbole für die RDP-Verknüpfungen grafisch besser darstellen...
Gruß und viel Erfolg
Ja genau, ein allgemeiner Account auf dem Client ist angemeldet. Die Benutzerauthentifizierung an der Domäne passiert dann erst beim Anmelden der RDP-Session.
Noch bin ich der Hoffnung, dass es dafür eine Lösung gibt.
Im Prinzip müsstest du dich gegen einen Connection Broker authentifizieren, der dann die RDP Ressource startet, die für diesen User zur Verfügung steht...
Und zwei vollkommen unterschiedlich aussehende Verknüpfungen gehen wirklich nicht?
Und zwei vollkommen unterschiedlich aussehende Verknüpfungen gehen wirklich nicht?
Ja, im RDP Broker kann man Gruppen anlegen wer wohin umgeleitet wird.
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-s ...
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-s ...
Der simple Klassiker: Einfach deinem DNS Server zwei IPs zum gleichen Namen definieren, dann macht der doch automatisch ein Round Robin Load Sharing.
https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_07.htm
https://de.wikipedia.org/wiki/Lastverteilung_per_DNS
https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_07.htm
https://de.wikipedia.org/wiki/Lastverteilung_per_DNS
Zitat von @NordicMike:
Ja, im RDP Broker kann man Gruppen anlegen wer wohin umgeleitet wird.
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-s ...
??? - dass würde mich jetzt selber mal interessieren... Nur finde ich dazu unter dem von Dir verlinkten Artikel keine Infos dazu.Ja, im RDP Broker kann man Gruppen anlegen wer wohin umgeleitet wird.
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-s ...
Zitat von @ElmerAcmeee:
Im Prinzip müsstest du dich gegen einen Connection Broker authentifizieren, der dann die RDP Ressource startet, die für diesen User zur Verfügung steht...
Und zwei vollkommen unterschiedlich aussehende Verknüpfungen gehen wirklich nicht?
Im Prinzip müsstest du dich gegen einen Connection Broker authentifizieren, der dann die RDP Ressource startet, die für diesen User zur Verfügung steht...
Und zwei vollkommen unterschiedlich aussehende Verknüpfungen gehen wirklich nicht?
Genau das ist der Plan. Die 2 optisch verschiedenen Verknüpfungen wären die absolute Notlösung.
Zitat von @NordicMike:
Ja, im RDP Broker kann man Gruppen anlegen wer wohin umgeleitet wird.
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-s ...
Ja, im RDP Broker kann man Gruppen anlegen wer wohin umgeleitet wird.
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-s ...
Genau da wollen wir ja hin. Aber irgendwas läuft eben noch nicht. Danke für den Link ich werde mich daran mal abarbeiten, obwohl wir eigentlich alles schon so umgesetzt haben. Bis auf die Zertifikate aber da kam bisher auch keine Warnung zu.
Zitat von @aqui:
Der simple Klassiker: Einfach deinem DNS Server zwei IPs zum gleichen Namen definieren, dann macht der doch automatisch ein Round Robin Load Sharing.
https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_07.htm
https://de.wikipedia.org/wiki/Lastverteilung_per_DNS
Der simple Klassiker: Einfach deinem DNS Server zwei IPs zum gleichen Namen definieren, dann macht der doch automatisch ein Round Robin Load Sharing.
https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_07.htm
https://de.wikipedia.org/wiki/Lastverteilung_per_DNS
Lastverteilung geht eben nicht. Da hatte ich weiter oben schon was zu geschrieben. Es ist genau vordefiniert welcher User auf welchem TS arbeitetet.
Zitat von @Hubert.N:
Zitat von @NordicMike:
Ja, im RDP Broker kann man Gruppen anlegen wer wohin umgeleitet wird.
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-s ...
??? - dass würde mich jetzt selber mal interessieren... Nur finde ich dazu unter dem von Dir verlinkten Artikel keine Infos dazu.Ja, im RDP Broker kann man Gruppen anlegen wer wohin umgeleitet wird.
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-s ...
^^
Wissen die User das auch?
Also hier wäre meine pragmatische Lösung zwei Links auf den Desktop zu klatschen und den Usern zu sagen. welcher User welchen Link klicken soll.
lks
1
Hier geht es eher um ein lizenztechnisches Problem einer Software, die eben nur auf einem von den beiden Terminalservern zur Verfügung steht. Deswegen ist vorbestimmt welcher User auf welchem Server arbeiten soll.
Mal andersrum gedacht, ist das wirklich nötig? Besser wäre es doch, die Software wäre auf beiden RD-SH vorhanden, so das ein echter Lastenausgleich statt finden kann und bei Problemen die Benutzer grundsätzlich ausweichen können. Das würde ebenfalls alle deine Probleme lösen.
Ich weiß, das im allgemeinen eine Software auf einem RD-SH "für alle Benutzer mit Zugriff" zu lizensieren ist. Ich habe mir in der Vergangenheit so beholfen, das ich die NTFS-Rechte der Software einschränke, so das nur eine bestimmte Gruppe die Software ausführen kann. Zugegeben, ich hatte noch nie ein Lizenzaudit für so eine Konstellation. Mein Standpunkt wäre allerdings der, das ein solcher Benutzer die Software nicht verwenden kann, egal ob er auf dem Host oder auf einem anderen Host in der selben RD-Umgebung arbeitet - darauf könnte man es ankommen lassen.
Moin,
Gruß,
Dani
Besser wäre es doch, die Software wäre auf beiden RD-SH vorhanden, so das ein echter Lastenausgleich statt finden kann und bei Problemen die Benutzer grundsätzlich ausweichen können. Das würde ebenfalls alle deine Probleme lösen
das ist meistens mit Mehrkosten verbunden. Und da geht es selten um ein paar Hundert Euro. Ich habe mir in der Vergangenheit so beholfen, das ich die NTFS-Rechte der Software einschränke, so das nur eine bestimmte Gruppe die Software ausführen kann.
Das ist genau einer der Gründe warum in den letzten Jahren immer mehr Fachsoftware wieder via Dongle gesichert werden. Denn damit wird zu oft die Lizenz Bestimmungen gedehnt. Das merken auch die Hersteller und reagieren entsprechend.Gruß,
Dani
Ich sage nur, das es sich lohnen kann, nochmal auf das Lizenzthema zu schauen, um den anderen Problemen aus dem Weg zu gehen. Je nachdem, von welcher Software wir reden, kann das auch mit dem Hersteller geklärt werden, ob z.B. eine Einschränkung auf NTFS-Ebene reicht, um den Lizenzbestimmungen gerecht zu werden (ohne Mehrkosten).
Ich habe auch in einem Fall die spezielle Software auf einen weiteren RD-SH ausgelagert. Die Benutzer arbeiten alle auf der selben Farm und der kleine Kreis an Benutzern, die diese eine Software nutzen (und nutzen dürfen), starten aus der Remote Session eine Remote App. Die VMs sind über Datecenter lizensiert, die RDS CALs sind named user. Leider ist hier die Integration seitens Microsoft schlecht, gewisse Features wie Dateitypen-Zuordnung für Remote Apps gehen nicht in einer Remote Session, das findet MS unnötig...
Ich habe auch in einem Fall die spezielle Software auf einen weiteren RD-SH ausgelagert. Die Benutzer arbeiten alle auf der selben Farm und der kleine Kreis an Benutzern, die diese eine Software nutzen (und nutzen dürfen), starten aus der Remote Session eine Remote App. Die VMs sind über Datecenter lizensiert, die RDS CALs sind named user. Leider ist hier die Integration seitens Microsoft schlecht, gewisse Features wie Dateitypen-Zuordnung für Remote Apps gehen nicht in einer Remote Session, das findet MS unnötig...
