8
Verzögerung bei Anmeldung an Remote-Desktop Diensten
Hallo Zusammen,
unzwar haben wir das Problem, dass Morgens wenn sich fast alle Anmelden sich die Anmeldemaske verzögert. Also, man klickt auf die MSTSC.exe und dann wartet man 1-5 Minuten bis dann das Anmeldefenster auftaucht.
Unser System für die Arbeit am Terminalserver ist aufgebaut wie folgt: 1x Connection Broker Server, 2x Sitzungshost Server. Jeder Benutzer bekommt über eine GPO diese .exe als Verknüpfung am Desktop angelegt. Angegeben als Servername ist der DNS-Name für die Terminalserver.
Die CPU Auslastung der Server wurde auch überwacht, der Connection Broker erreicht maximal 60% Auslastung, während die Sitzungshosts maximal 75% erreichen zu dieser Zeit. Der Domain Controller spiked maximal auf 60% und läuft daraufhin normale weiter unter 40%.
Die DNS-Auflösung wurde am Domain Controller auch schon mehrfach getestet über dcdiag und die DNS-Einträge überprüft um auszuschließen, dass die DNS Auflösung nicht optimal läuft.
In der Ereignisanzeige konnte ich vorerst auch noch kein Problem auslesen, jedoch habe ich nur RemoteConnectionManager überprüft.
Woran könnte dies liegen? Kann es sein, dass ein Dienst sich aufhängt? Habe ich vielleicht was bei der DNS-Überprüfung nicht gesehen bzw. ausgelassen?
Vielen Dank im voraus.
unzwar haben wir das Problem, dass Morgens wenn sich fast alle Anmelden sich die Anmeldemaske verzögert. Also, man klickt auf die MSTSC.exe und dann wartet man 1-5 Minuten bis dann das Anmeldefenster auftaucht.
Unser System für die Arbeit am Terminalserver ist aufgebaut wie folgt: 1x Connection Broker Server, 2x Sitzungshost Server. Jeder Benutzer bekommt über eine GPO diese .exe als Verknüpfung am Desktop angelegt. Angegeben als Servername ist der DNS-Name für die Terminalserver.
Die CPU Auslastung der Server wurde auch überwacht, der Connection Broker erreicht maximal 60% Auslastung, während die Sitzungshosts maximal 75% erreichen zu dieser Zeit. Der Domain Controller spiked maximal auf 60% und läuft daraufhin normale weiter unter 40%.
Die DNS-Auflösung wurde am Domain Controller auch schon mehrfach getestet über dcdiag und die DNS-Einträge überprüft um auszuschließen, dass die DNS Auflösung nicht optimal läuft.
In der Ereignisanzeige konnte ich vorerst auch noch kein Problem auslesen, jedoch habe ich nur RemoteConnectionManager überprüft.
Woran könnte dies liegen? Kann es sein, dass ein Dienst sich aufhängt? Habe ich vielleicht was bei der DNS-Überprüfung nicht gesehen bzw. ausgelassen?
Vielen Dank im voraus.
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: 2944059084
Url: https://administrator.de/forum/verzoegerung-bei-anmeldung-an-remote-desktop-diensten-2944059084.html
Ausgedruckt am: 22.04.2025 um 15:04 Uhr
8 Kommentare
Neuester Kommentar
Moin,
vielleicht hilft dies:
https://community.spiceworks.com/topic/467039-remote-desktop-connection- ...
Oder dies:
https://blog.wapnet.nl/2021/11/slow-initial-rdp-connection/
Oder dies, Du schreibst leider nicht, ob Du während des Wartens auf das Anmeldefenster irgendetwas siehst oder ob es einfach nur dauert:
https://docs.microsoft.com/en-US/troubleshoot/windows-server/remote/rdc- ...
Viel Glück!
Gruß
vielleicht hilft dies:
https://community.spiceworks.com/topic/467039-remote-desktop-connection- ...
Oder dies:
https://blog.wapnet.nl/2021/11/slow-initial-rdp-connection/
Oder dies, Du schreibst leider nicht, ob Du während des Wartens auf das Anmeldefenster irgendetwas siehst oder ob es einfach nur dauert:
https://docs.microsoft.com/en-US/troubleshoot/windows-server/remote/rdc- ...
Viel Glück!
Gruß
Ob du was bei der DNS Überprüfung was ausgelassen hast, kann dir niemand beantworten, weil niemand weiss, was du geprüft hast.
Zu prüfen wäre:
Nslookup und Ping auf die Domäne.
Nslookup und Ping auf "alle" Domänencontroller, ob einer nicht antwortet.
Nslookup und Ping auf den Connection Broker.
Nslookup und Ping auf alle Session Hosts, ob einer nicht antwortet.
Und das Ganze vom Client aus, von den Session Hosts aus und vom Connection Broker aus.
TCPDUMP oder Wireshark ins Netzwerk, ob ein Broadcaststurm evtl alles verzögert.
Das wären so meine ersten Ideen...
Zu prüfen wäre:
Nslookup und Ping auf die Domäne.
Nslookup und Ping auf "alle" Domänencontroller, ob einer nicht antwortet.
Nslookup und Ping auf den Connection Broker.
Nslookup und Ping auf alle Session Hosts, ob einer nicht antwortet.
Und das Ganze vom Client aus, von den Session Hosts aus und vom Connection Broker aus.
TCPDUMP oder Wireshark ins Netzwerk, ob ein Broadcaststurm evtl alles verzögert.
Das wären so meine ersten Ideen...
Wir haben das Phänomen vor ein paar Monaten das erste mal beobachtet, damals hat sich die Maske zur Eingabe der Anmeldeinformation teilweise über Minuten einfach nicht geöffnet. Der Eintrag vom Fenster war in der Taskleiste zu sehen aber die Maske ging nicht auf. Das war aber ganz klar ein clientseitiges Problem, betroffen waren eigentlich nur Geräte in einem Subnetz (Besprechungsräume) die durch eine Firewall auf den RD-SH verbinden. Aber daran hat sich im Vergleich zu vorher auch nichts geändert, das Problem tritt seit irgendwelchen Windows 10 Updates auf. Wir haben damals sogar einen Client neu aufgesetzt und es ist immer wieder mal aufgetreten.
Mittlerweile ist das immer noch ein paar Sekunden verzögert, ich würde jetzt mal schätzen ca. 10 Sekunden. Die konkrete Ursache kenne ich nicht, Windows 10 wie wir es lieben.
Mittlerweile ist das immer noch ein paar Sekunden verzögert, ich würde jetzt mal schätzen ca. 10 Sekunden. Die konkrete Ursache kenne ich nicht, Windows 10 wie wir es lieben.
Moin,
trifft eine oder mehrere Rahmenbedingungen auf euch zu:
Gruß,
Dani
trifft eine oder mehrere Rahmenbedingungen auf euch zu:
- Nutzt ihr Pi-Hole/Adguard mit bestimmten Listen als AD Blocker/Malware-Filter?
- Kommen die Server der Remote DEsktop Services Plattform ins Internet oder ist dieser Zugriff geblockt (Outbound Firewalling)?
- Welche Betriebssystem kommt auf den verschiedenen Rollen des RDS zum Einsatz?
Gruß,
Dani
Die Clients brauchen übrigens auch Internetzugriff sonst können vermutlich Zertifikate (auch selbst ausgestellte) nicht mehr geprüft werden. Das hat bei uns allerdings zu Anmeldefehlern geführt, nicht zu Verzögerungen.
@ukulele-7
Gruß,
Dani
Die Clients brauchen übrigens auch Internetzugriff sonst können vermutlich Zertifikate (auch selbst ausgestellte) nicht mehr geprüft werden.
Solange Zertifikate aus einer internen PKI stammen, deren Sperrlisten (CRL und/oder OCSP) auch erreichbar sind, ist der Internetzugriff nicht erforderlich. Haben wir mehrfach so im Einsatz ohne Probleme. Anders sieht es bei gekauften oder Let's Encrypt Zertifikaten aus.Gruß,
Dani
Zitat von @Dani:
@ukulele-7
Ich habe mich um die Zertifikate beim Terminalserver nie geschert, ich glaube die wurden bei Installation der Terminal Dienste vom Setup erzeugt, danach einfach per Haken am Client akzeptiert. Der Client prüft das im Hintergrund alle ~3 Monaten und hat er kein Internet wird der Verbindungsaufbau echt langsam auch wenn die Verbindung zustande kommt.@ukulele-7
Die Clients brauchen übrigens auch Internetzugriff sonst können vermutlich Zertifikate (auch selbst ausgestellte) nicht mehr geprüft werden.
Solange Zertifikate aus einer internen PKI stammen, deren Sperrlisten (CRL und/oder OCSP) auch erreichbar sind, ist der Internetzugriff nicht erforderlich. Haben wir mehrfach so im Einsatz ohne Probleme. Anders sieht es bei gekauften oder Let's Encrypt Zertifikaten aus.Wie habt ihr die PKI umgesetzt? Ich will mir das eigentlich gar nicht antun.
Moin,
Gruß,
Dani
Wie habt ihr die PKI umgesetzt?
Klassisch, modern zwei-stufige PKI mit allem drum und dran. Wird für alleServices im Netzwerk und Internet genutzt.Gruß,
Dani
