10
Anmeldung über Remote Connection Broker auf Terminalservern sehr langsam
Hallo zusammen,
ich benötige einmal euer Schwarmwissen und bin über jede qualifizierte Antwort dankbar
.
Folgendes Problem:
Die Anmeldung der User eines Kunden auf den Terminalservern (Remote App, kein vollwertiger Remote Desktop) über den Connection Broker dauert teilweise bis zu einer Minute und wirft entsprechend Fehler, außerdem kommt es zu Printfehlern aus der Anwendung (MS Navision) die über die Terminalserver wandern.
Konfig der Server:
Der Broker ist so eingerichtet, dass er die Anmeldung der rund 200 User nach dem Prinzip des Lastenausgleichs verteilt.
Die Hostsysteme haben jeweils 4 Nics die im Nic-Teaming zusammengeschlossen sind auf zwei Switche verteilt wurden.
Die virtuellen Switche von Hyper-V haben jeweils das Nic-Team als Netzwerkverbindung, es gibt je Host einen virtuellen Switch.
Die TS haben jeweils zwei virtuelle Nics die in einem Nic-Team zusammengeschlossen sind.
Dienste mit Fehlern:
So, das sollte alles so weit zusammen gefasst haben.
Ich hoffe Ihr könnt mir weiter helfen und danke im Voraus!
Beste Grüße
JGA
*Edit:
Eventuell noch wichtig zu wissen wäre die eingesetzte Virenschutzsoftware, bei den Systemen kommt die Bitdefender Gravityzone Advanced Business zum Einsatz.
ich benötige einmal euer Schwarmwissen und bin über jede qualifizierte Antwort dankbar
.Folgendes Problem:
Die Anmeldung der User eines Kunden auf den Terminalservern (Remote App, kein vollwertiger Remote Desktop) über den Connection Broker dauert teilweise bis zu einer Minute und wirft entsprechend Fehler, außerdem kommt es zu Printfehlern aus der Anwendung (MS Navision) die über die Terminalserver wandern.
Konfig der Server:
- Hostsystem 1 mit Server 2012r2 Standard und Hyper-V hostet den DC01 welcher ebenfalls Connection Broker ist und auf Server 2012r2 Standard basiert
- Hostsystem 2 mit Server 2012r2 Standard und Hyper-V hostet den TS01 mit Server 2012r2 Standard
- Hostsystem 3 mit Server 2016 Datacenter und Hyper-V hostet den TS02 mit Server 2012r2 Standard
- Hostsystem 4 mit Server 2016 Datacenter und Hyper-V hostet den TS03 mit Server 2012r2 Standard
Der Broker ist so eingerichtet, dass er die Anmeldung der rund 200 User nach dem Prinzip des Lastenausgleichs verteilt.
Die Hostsysteme haben jeweils 4 Nics die im Nic-Teaming zusammengeschlossen sind auf zwei Switche verteilt wurden.
Die virtuellen Switche von Hyper-V haben jeweils das Nic-Team als Netzwerkverbindung, es gibt je Host einen virtuellen Switch.
Die TS haben jeweils zwei virtuelle Nics die in einem Nic-Team zusammengeschlossen sind.
Dienste mit Fehlern:
- UmRdpService - Wirft Fehler, wenn es auf dem Terminalserver zum o.g. Printproblem kommt. Der Spooler lässt sich in dem Fall nicht neustarten und es ist ein manuelles Abmelden der User und anschließender Neustart des Terminalservers notwendig.
So, das sollte alles so weit zusammen gefasst haben.
Ich hoffe Ihr könnt mir weiter helfen und danke im Voraus
!Beste Grüße
JGA
*Edit:
Eventuell noch wichtig zu wissen wäre die eingesetzte Virenschutzsoftware, bei den Systemen kommt die Bitdefender Gravityzone Advanced Business zum Einsatz.
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: 468847
Url: https://administrator.de/contentid/468847
Printed on: April 28, 2024 at 15:04 o'clock
10 Comments
Latest comment
Moin,
Ein Domain Controller ist ein Domain Controller ist ein Domain Controller. Nimm den Connection Broker da raus und installiere ihn auf einer eigenen virtuellen Maschine.
hth
Erik
Zitat von @JGA-Attus-IT:
- Hostsystem 1 mit Server 2012r2 Standard und Hyper-V hostet den DC01 welcher ebenfalls Connection Broker ist und auf Server 2012r2 Standard basiert
Ein Domain Controller ist ein Domain Controller ist ein Domain Controller. Nimm den Connection Broker da raus und installiere ihn auf einer eigenen virtuellen Maschine.
hth
Erik
Moin,
danke für deine Antwort.
Was mich dabei wundert, es lief jahrelang problemlos.
BG
JGA
danke für deine Antwort.
Was mich dabei wundert, es lief jahrelang problemlos.
BG
JGA
Moin,
noch mal ne kleine Zwischenfrage die eventuell die Fehleranalyse vereinfachen könnte:
Kennt eventuell jemand ein Tool welches es ermöglicht den Gesamten Ablauf von der Eingabe der Credentials bis hin zum Starten der Anwendung zu protokollieren und somit zu sehen welcher Dienst da eventuell zicken macht?
BG
JGA
noch mal ne kleine Zwischenfrage die eventuell die Fehleranalyse vereinfachen könnte:
Kennt eventuell jemand ein Tool welches es ermöglicht den Gesamten Ablauf von der Eingabe der Credentials bis hin zum Starten der Anwendung zu protokollieren und somit zu sehen welcher Dienst da eventuell zicken macht?
BG
JGA
Servus,
Eventlog oder auf deutsch die Ereignisanzeige.
Gruß
Maxblank
Eventlog oder auf deutsch die Ereignisanzeige.
Gruß
Maxblank
Ereignislog gibt da leider zu wenig Info
BG
JGA
Wenn du die Logs von allen beteiligten Servern und Clients zu dem Vorgang im entsprechenden Zeitraum im Zusammenhang sichtest, wirst du schon genügend Anhaltspunkte finden.
Welche Info fehlt deiner Meinung nach im Eventlog?
Welche Info fehlt deiner Meinung nach im Eventlog?
Zitat von @maxblank:
Wenn du die Logs von allen beteiligten Servern und Clients zu dem Vorgang im entsprechenden Zeitraum im Zusammenhang sichtest, wirst du schon genügend Anhaltspunkte finden.
Welche Info fehlt deiner Meinung nach im Eventlog?
Wenn du die Logs von allen beteiligten Servern und Clients zu dem Vorgang im entsprechenden Zeitraum im Zusammenhang sichtest, wirst du schon genügend Anhaltspunkte finden.
Welche Info fehlt deiner Meinung nach im Eventlog?
Wie gesagt hätte ich gerne eine detaillierte Auswertung beim Login eines Testaccounts welcher Diensta auf welchem Server zu welchem Zeitpunkt der Anmeldung wie lange gebraucht hat (also von Start bis endgültiger Ausführung).
In den Eventlogs sehe ich lediglich wie lange der User für die Anmeldung braucht, nicht aber wie lange er an welchem Server auf die Anmeldung/DienstXYZ warten musste.
BG
JGA
Auch nicht, wenn du es chronologisch betrachtest?
Leider nein, ich habe aber gerade das Problem "gelöst" bzw. ein workarount geschaffen indem ich die VM auf einen anderen Host gemoved habe.
Die Anmeldezeiten liegen nun bei 1-2 Sekunden mit den Testusern.
Ich werde mal schauen, wie sich das morgen im Realbetrieb auswirkt.
Bleibt nur das Printproblem, da steh ich auch noch wie Ochs vorm Berg :/.
BG
JGA
Die Lösung war tatsächlich eine Neuinstallation des Hosts, auf dem der DC lag.
Dieser ist nun auch ein Server 2016 und seitdem gibt es keinerlei Probleme mehr!
Dieser ist nun auch ein Server 2016 und seitdem gibt es keinerlei Probleme mehr!
