5
Windows Server 2016 RD Verbinungsbroker hochverfügbar
Hallo,
ich muß bei einem Kunden die Windows Server 2016 RDS-Farm mit einem zweiten RD-Verbindungsbroker ausstatten. Hierzu möchte ich die RD-Verbindungsbroker für hohe Verfügbarkeit konfigurieren.
Ich habe mich dazu exakt an die verschiedensten Konfigurationsbeispiele gehalten, die im Prinzip alle die gleiche Vorgehensweise beschreiben. Hier ein Link zu einer möglichen Vorgehensweise:
https://www.terminalworks.com/blog/post/2015/08/14/implementing-rd-conne ...
Zwar sind die meisten K-Beispiele für Windows Server 2012, aber sollten ebenso für 2016 gelten, zu mindestens habe ich dies mehrfach so gelesen. Konfigurationsbeispiele für Windows Server 2016 RDVB sind nur vereinzelt verfügbar, beschreiben aber die gleiche Vorgehensweise.
Geprüft habe ich, dass auf dem MS SQL Server 2016 die gleiche Version des SQL Server Native Client 11.0 und ODBC Driver 17 for SQL Server installiert ist, wie auf dem Verbindungsbroker.
Hier die Screenshots zur Einrichtung, die am Ende mir einem Fehler abbricht:
Die hier angegebene Fehlermeldung habe ich geprüft und sollten Funktionieren:
1. Der Broker sollte auf den SQL-Server zugriff haben, da das Computerkonto des Brokers Mitglied der Sicherheitsgruppe ist mit folgenden Rechten:
2. Der angegeben Pfad ist der Standardpfad auf diesem SQL-Server für die Datenbankablage und ist auch verfügbar.
3. Im Ereignisprotokoll stehen weder auf dem Broker noch auf dem SQL-Server brauchbare Fehlerhinweise.
Die Windows Firewall habe ich testweise auf allen betroffenen Servern deaktivier. Die Sicherheitsgruppe, in der das Computerkonto des Verbindungsbrokers integriert ist, habe ich ebenfalls erstellt und unter Sicherheit, Anmeldung im SQL-Server mit den entsprechenden Rechten angelegt. Testweise habe ich eine komplett neue VM mit Windows Server 2016 und MS SQL 2016 aufgesetzt. Leider hat dies ebenfalls nicht funktioniert. DNS-Round-Robbin habe ich ebenfalls eingerichtet und ist auch im DNS aktiviert.
Leider weiß ich jetzt nicht mehr, was ich noch prüfen kann und mir ist nicht klar, wo hier das Problem liegt. Ich wäre sehr dankbar für jede Hilfestellung
Danke
Arnold
ich muß bei einem Kunden die Windows Server 2016 RDS-Farm mit einem zweiten RD-Verbindungsbroker ausstatten. Hierzu möchte ich die RD-Verbindungsbroker für hohe Verfügbarkeit konfigurieren.
Ich habe mich dazu exakt an die verschiedensten Konfigurationsbeispiele gehalten, die im Prinzip alle die gleiche Vorgehensweise beschreiben. Hier ein Link zu einer möglichen Vorgehensweise:
https://www.terminalworks.com/blog/post/2015/08/14/implementing-rd-conne ...
Zwar sind die meisten K-Beispiele für Windows Server 2012, aber sollten ebenso für 2016 gelten, zu mindestens habe ich dies mehrfach so gelesen. Konfigurationsbeispiele für Windows Server 2016 RDVB sind nur vereinzelt verfügbar, beschreiben aber die gleiche Vorgehensweise.
Geprüft habe ich, dass auf dem MS SQL Server 2016 die gleiche Version des SQL Server Native Client 11.0 und ODBC Driver 17 for SQL Server installiert ist, wie auf dem Verbindungsbroker.
Hier die Screenshots zur Einrichtung, die am Ende mir einem Fehler abbricht:
Die hier angegebene Fehlermeldung habe ich geprüft und sollten Funktionieren:
1. Der Broker sollte auf den SQL-Server zugriff haben, da das Computerkonto des Brokers Mitglied der Sicherheitsgruppe ist mit folgenden Rechten:
3. Im Ereignisprotokoll stehen weder auf dem Broker noch auf dem SQL-Server brauchbare Fehlerhinweise.
Die Windows Firewall habe ich testweise auf allen betroffenen Servern deaktivier. Die Sicherheitsgruppe, in der das Computerkonto des Verbindungsbrokers integriert ist, habe ich ebenfalls erstellt und unter Sicherheit, Anmeldung im SQL-Server mit den entsprechenden Rechten angelegt. Testweise habe ich eine komplett neue VM mit Windows Server 2016 und MS SQL 2016 aufgesetzt. Leider hat dies ebenfalls nicht funktioniert. DNS-Round-Robbin habe ich ebenfalls eingerichtet und ist auch im DNS aktiviert.
Leider weiß ich jetzt nicht mehr, was ich noch prüfen kann und mir ist nicht klar, wo hier das Problem liegt. Ich wäre sehr dankbar für jede Hilfestellung
Danke
Arnold
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: 643476
Url: https://administrator.de/contentid/643476
Printed on: April 26, 2024 at 19:04 o'clock
5 Comments
Latest comment
Hi,
hast du Mal per Powershell ein Test-netconnection -Computername SQL SERVER-NAME -Port 1433 gemacht?
Kommt hier bei TCP ein True zurück?
Falls nein im SQL Server Konfigurationsmanager unter TCP schauen dass auch der Zugriff von anderen Systemen geöffnet ist.
Gruß
hast du Mal per Powershell ein Test-netconnection -Computername SQL SERVER-NAME -Port 1433 gemacht?
Kommt hier bei TCP ein True zurück?
Falls nein im SQL Server Konfigurationsmanager unter TCP schauen dass auch der Zugriff von anderen Systemen geöffnet ist.
Gruß
Hallo,
ja, es kommt ein True zurück:
LG
ja, es kommt ein True zurück:
LG
Hi,
die Broker haben auch Vollzugriff Rechte auf den Database Pfad? Prüfen mittels Explorer...
Und der nativ Client ist auch installiert?
Grüße
die Broker haben auch Vollzugriff Rechte auf den Database Pfad? Prüfen mittels Explorer...
Und der nativ Client ist auch installiert?
Grüße
Moin,
vergleiche deine Konfiguration nochmals mit diesem Beitrag. Damit habe ich bei uns damals den Cluster erfolgreich hochgezogen.
Gruß,
Dani
vergleiche deine Konfiguration nochmals mit diesem Beitrag. Damit habe ich bei uns damals den Cluster erfolgreich hochgezogen.
Gruß,
Dani
Hallo Dani und Fabezz,
vielen Dank für Eure Unterstützung. Zwischenzeitlich habe ich das Problem lösen können. In diesem Fall hatte ich die kompletten MS SQL Komponenten, die unter Programme auf dem Broker installiert waren, deinstalliert, rebootet und nur die SQL Server Native Clint 11.0 als separates Download neu installiert und siehe da, es funktioniert. Ich hatte zur Erstkonfiguration über das MS SQL Server 2016 Setup die Verwaltungstools installiert und in diesem Zusammenhang hat das Setup div. zusätzliche Software mit installiert, die scheinbar irgendwelche Unstimmigkeiten verursachten.
Das hinzufügen eines zweiten Brokers funktioniert dann im zweiten Schritt völlig problemlos.
Danke für Eure Unterstützung.
Arnold
vielen Dank für Eure Unterstützung. Zwischenzeitlich habe ich das Problem lösen können. In diesem Fall hatte ich die kompletten MS SQL Komponenten, die unter Programme auf dem Broker installiert waren, deinstalliert, rebootet und nur die SQL Server Native Clint 11.0 als separates Download neu installiert und siehe da, es funktioniert. Ich hatte zur Erstkonfiguration über das MS SQL Server 2016 Setup die Verwaltungstools installiert und in diesem Zusammenhang hat das Setup div. zusätzliche Software mit installiert, die scheinbar irgendwelche Unstimmigkeiten verursachten.
Das hinzufügen eines zweiten Brokers funktioniert dann im zweiten Schritt völlig problemlos.
Danke für Eure Unterstützung.
Arnold