1
Remote Desktop Connection Broker redirect an Drained Session Host
Hallo zusammen,
folgende Farm auf Server 2019 - alle Updates installliert
Connection Broker (nicht HA)
3 Sammlungen mit jeweils 2 Hosts
Alle RDP Sessions Files sind mit den korrekten Load Balancing Infos(TSV String) augestattet und connecten sich alle immer gegen den Broker
Intern funktioniert alles wunderbar.
Broker verteilt Connection sauber über die Hosts
Schaltet man einen der beiden Hosts in den Drain Mode (neue Verbindungen nicht erlaubt, bestehende verbinden) funktioniert das sauber.
In den Logfiles kann man sehen:
Server A ist in Drain Mode
Neue Session für einen User ist redirected zu einem anderen Host.
Von extern arbeiten wir mit einem SSLVPN und Browserbasiertem Bookmark. (Sonicwall SMA)
Dieses ruft dann lokal mstsc.exe auf und tunnelt das alles durch das SSLVPN.
Das Bookmark reicht auch die LoadBalancing Info durch (TSV String)
Solange kein Host im Drain Mode ist, funktioniert auch alles wie oben beschrieben.
Broker verteilt Connection sauber über die Hosts.
Schalten wir nun einen Host einer Collection in den DrainMode, dann wird ein User mit neuer Session trotzdem an den Host im DrainMode redirected.
Im Logfile kann man folgendes erkennen:
Server (nennen wir ihn ServerB) ist im DrainMode
User connect zum Broker mit richtiger LoadBalancingInfo (TSV)
Broker prüft ob vorhandene Session existiert: existiert nicht (User ist sauber abgemeldet worden)
Broker redirected zum HostB im DrainMode- Session kommt natürlich nicht zustande
Scheinbar will der Broker hier immer da hin verbinden, wo der User zuletzt angemeldet war (ServerB)
Irgendwo in diesem Redirect Prozess muss ja überprüft werden, ob der Host im DrainMode ist.
Darüber gibt es aber keine Infos und Logs
Hat da jemand eine Erklärung ?
Wie kann man hier tieferes TroubleShooting betreiben ?
Logfiles geben nicht mehr her, da sieht ja alles richtig aus.
M.E. ist das ber ein Pronlem des Brokers, da er beim redirect den DrainMode nicht berücksichtigt.(Das aber nur im RemoteZugang nicht)
(Wireshark nutzt nichts, da ja alles verschlüsselt ist.)
Danke und Grüße
Michael
folgende Farm auf Server 2019 - alle Updates installliert
Connection Broker (nicht HA)
3 Sammlungen mit jeweils 2 Hosts
Alle RDP Sessions Files sind mit den korrekten Load Balancing Infos(TSV String) augestattet und connecten sich alle immer gegen den Broker
Intern funktioniert alles wunderbar.
Broker verteilt Connection sauber über die Hosts
Schaltet man einen der beiden Hosts in den Drain Mode (neue Verbindungen nicht erlaubt, bestehende verbinden) funktioniert das sauber.
In den Logfiles kann man sehen:
Server A ist in Drain Mode
Neue Session für einen User ist redirected zu einem anderen Host.
Von extern arbeiten wir mit einem SSLVPN und Browserbasiertem Bookmark. (Sonicwall SMA)
Dieses ruft dann lokal mstsc.exe auf und tunnelt das alles durch das SSLVPN.
Das Bookmark reicht auch die LoadBalancing Info durch (TSV String)
Solange kein Host im Drain Mode ist, funktioniert auch alles wie oben beschrieben.
Broker verteilt Connection sauber über die Hosts.
Schalten wir nun einen Host einer Collection in den DrainMode, dann wird ein User mit neuer Session trotzdem an den Host im DrainMode redirected.
Im Logfile kann man folgendes erkennen:
Server (nennen wir ihn ServerB) ist im DrainMode
User connect zum Broker mit richtiger LoadBalancingInfo (TSV)
Broker prüft ob vorhandene Session existiert: existiert nicht (User ist sauber abgemeldet worden)
Broker redirected zum HostB im DrainMode- Session kommt natürlich nicht zustande
Scheinbar will der Broker hier immer da hin verbinden, wo der User zuletzt angemeldet war (ServerB)
Irgendwo in diesem Redirect Prozess muss ja überprüft werden, ob der Host im DrainMode ist.
Darüber gibt es aber keine Infos und Logs
Hat da jemand eine Erklärung ?
Wie kann man hier tieferes TroubleShooting betreiben ?
Logfiles geben nicht mehr her, da sieht ja alles richtig aus.
M.E. ist das ber ein Pronlem des Brokers, da er beim redirect den DrainMode nicht berücksichtigt.(Das aber nur im RemoteZugang nicht)
(Wireshark nutzt nichts, da ja alles verschlüsselt ist.)
Danke und Grüße
Michael
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: 608378
Url: https://administrator.de/contentid/608378
Printed on: April 24, 2024 at 12:04 o'clock
1 Comment
Moin,
Gruß,
Dani
M.E. ist das ber ein Pronlem des Brokers, da er beim redirect den DrainMode nicht berücksichtigt.(Das aber nur im RemoteZugang nicht)
wenn im LAN alles funktioniert, liegt doch der Verdacht nahe, dass es am VPN Tunnel liegt. Zumal du gegen Sonicwall damit auch Druck aufbauen kannst. Ein Microsoft Support Case hilft meiner Ansicht erst einmal nicht weiter, da du keine funktionale Referenzkonfiguation hast. (Wireshark nutzt nichts, da ja alles verschlüsselt ist.)
Ist möglich - How to Decrypt SSL with Wireshark – HTTPS Decryption GuideGruß,
Dani
