3
Server 2012R2 Verbindungsbroker ohne HA umziehen
Folgende Situation:
Wir betreiben eine kleine Remotedesktop - Serverfarm unter Server 2012R2 mit einem DC, der die Rolle RD-Lizenzierung hält, sowie 2 RD - Sitzungshosts, von denen bedauerlicherweise der erste den Verbindungsbroker installiert hat.
Da die Farm erweitert werden soll und Sitzungen nur dann vernünftig zugewiesen werden können, wenn der Broker läuft, ist klar, dass der Broker sinnigerweise auf den DC umgezogen werden sollte - nur wie kann ich dies ohne HA/Cluster bewerkstelligen?
Müssen alle RD-Rollen von allen beteiligten Servern komplett entfernt und wieder neu installiert werden oder gilt dies nur für einzelne Rollen? In welcher Reihenfolge müsste ich vorgehen bzw. was gilt es zu beachten?
Wir betreiben eine kleine Remotedesktop - Serverfarm unter Server 2012R2 mit einem DC, der die Rolle RD-Lizenzierung hält, sowie 2 RD - Sitzungshosts, von denen bedauerlicherweise der erste den Verbindungsbroker installiert hat.
Da die Farm erweitert werden soll und Sitzungen nur dann vernünftig zugewiesen werden können, wenn der Broker läuft, ist klar, dass der Broker sinnigerweise auf den DC umgezogen werden sollte - nur wie kann ich dies ohne HA/Cluster bewerkstelligen?
Müssen alle RD-Rollen von allen beteiligten Servern komplett entfernt und wieder neu installiert werden oder gilt dies nur für einzelne Rollen? In welcher Reihenfolge müsste ich vorgehen bzw. was gilt es zu beachten?
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: 366445
Url: https://administrator.de/forum/server-2012r2-verbindungsbroker-ohne-ha-umziehen-366445.html
Ausgedruckt am: 23.12.2024 um 04:12 Uhr
3 Kommentare
Neuester Kommentar
Hallo (so viel Zeit muss sein),
Wie kommt man auf die Idee, eine solche Rolle mit Benutzerinteraktion, auf einen Domain Controller zu packen? Sucht man die besondere Herausforderungen oder ist das ein Hype? Solche Rollen gehören auf separate Maschinen, bevorzugt als VM.
Gruß,
Dani
Da die Farm erweitert werden soll und Sitzungen nur dann vernünftig zugewiesen werden können
das musst du mir einmal klären. Warum hat das bisher nicht vernünftig funktioniert?ist klar, dass der Broker sinnigerweise auf den DC umgezogen werden sollte
Bei solchen Gedanken/Ideen sollte der Admin jedes Mal einen Stromschlag bekommen. Beim 3. Mal wird eine Nachschulung fällig!Wie kommt man auf die Idee, eine solche Rolle mit Benutzerinteraktion, auf einen Domain Controller zu packen? Sucht man die besondere Herausforderungen oder ist das ein Hype? Solche Rollen gehören auf separate Maschinen, bevorzugt als VM.
nur wie kann ich dies ohne HA/Cluster bewerkstelligen?
Nutzt ihr die klassische RDP Verbindung oder habt ihr RemoteApps über RDWeb im Einsatz? Du müsstest über den Server Manager -> Remote Desktopdienste die jeweilige RDS-Rolle vom Server entfernen können.Gruß,
Dani
Ok, ich hätte etwas weiter ausholen sollen..
Alle Server werden auf einem Hyper-V 2012 R2 betrieben.
Wenn bei Wartungsarbeiten der Broker (Downtime 1.RDS-Host) nicht erreichbar ist, können sich Benutzer nicht mehr am 2.RDS-Host über den Farmnamen anmelden, daher auch für mich die logische Konsequenz den Broker umzuziehen.
Dass der auf einem DC nichts zu suchen hat, ist mir auch klar, hierfür werden wir mittelfristig eine weitere VM bereitstellen und lizenzieren müssen.
Die künftige Aufgabe wird sein, die ersten beiden RDS-Hosts (wie bisher) für die klassische Remote-Verbindung zu verwenden und mit dem 3. neuen RDS-Host RemoteApps bereitzustellen.
Alle Server werden auf einem Hyper-V 2012 R2 betrieben.
Wenn bei Wartungsarbeiten der Broker (Downtime 1.RDS-Host) nicht erreichbar ist, können sich Benutzer nicht mehr am 2.RDS-Host über den Farmnamen anmelden, daher auch für mich die logische Konsequenz den Broker umzuziehen.
Dass der auf einem DC nichts zu suchen hat, ist mir auch klar, hierfür werden wir mittelfristig eine weitere VM bereitstellen und lizenzieren müssen.
Die künftige Aufgabe wird sein, die ersten beiden RDS-Hosts (wie bisher) für die klassische Remote-Verbindung zu verwenden und mit dem 3. neuen RDS-Host RemoteApps bereitzustellen.
Moin,
Gruß,
Dani
Wenn bei Wartungsarbeiten der Broker (Downtime 1.RDS-Host) nicht erreichbar ist, können sich Benutzer nicht mehr am 2.RDS-Host über den Farmnamen anmelden, daher auch für mich die logische Konsequenz den Broker umzuziehen.
frei nach dem Motto: Ist der Domain Conroller tot, wen interessiert dann noch den RDP Zugriff. Dass der auf einem DC nichts zu suchen hat, ist mir auch klar, hierfür werden wir mittelfristig eine weitere VM bereitstellen und lizenzieren müssen.
Plan es anständig und vernünftig. Spar dir lieber den Umzug auf den Domain Controller und nutze die Zeit die Umsetzung.Die künftige Aufgabe wird sein, die ersten beiden RDS-Hosts (wie bisher) für die klassische Remote-Verbindung zu verwenden und mit dem 3. neuen RDS-Host RemoteApps bereitzustellen.
Ich an deiner Stelle würde auch die vollen Desktops über RDWeb veröffentlichen. Ja, das ist durch einen kl. Trick problemlos möglich. Mit einem neutralen FQDN (z.B. rds.domain.de) kannst du später die Rolle problemlos auf neue Windows Sever Versionen umziehen, ohne etwas an den Clients ändern zu müssen. Auf den Clients rollst du die Verbindung in den Benutzerkonten mit Hilfe eines Powershellskripts aus, welches du beim Anmelden der Benutzer ausführen lässt. Ich meine Kollege @DerWoWusste hat dazu hier etwas veröffentlicht. Ich finde den Beitrag/Kommentar gerade nicht.Gruß,
Dani
