Anzeige der RDP-Session friert nach Anmeldung ein
Moin!
Ich habe da ein Phänomen, das bereits seit Jahren von vielen beschrieben wird, viele fragen danach, aber so eine echte Lösung habe ich bisher nicht gefunden.
Ich verbinde mich auf einen Terminalserver 2008 R2, Patch-Stand Dezember 2015.
Verbinde ich mich mit meinem Firmennotebook mit Windows 7, ist alles tutti.
Verbinde ich mich mit meinem Privatnotebook mit Windows 7, 8.1 oder 10, ist alles tutti. Egal, ob per WLAN im Büro oder von zu Hause über VPN.
Verbinden sich meine rund 50 Kollegen mit was auch immer, einschließlich Linux und Mac als Client, ist alles tutti.
Nur seit ich mein Firmennotebook (das erste oben in der Liste, i5, 12GB RAM, keine Leistungsbremsen, das Ding kann was) von Windows 7 auf 10 aktualisiert habe, gibt es folgendes Bild:
Ich melde mich am Terminalserver an, der Desktop erscheint und das Bild bleibt stehen. Es friert nicht die Session ein, ich kann sie nur nicht mehr bewusst bedienen. Wenn ich mit Maus oder Tastatur irgendwelche Aktionen ausführe, klicke, Shortcuts abfeuern o.ä. funktioniert das, ich sehe es nur nicht.
Jetzt trenne ich die RDP-Verbindung, was übrigens sehr, sehr lange dauert, manchmal gerne auch eine Minute (über das X im blauen Balken) und auch Minimieren braucht so eine gefühlte halbe Minute und anschließend schalte ich mich neu auf. Jetzt habe ich ein neues Bild. Z.B. ist der IE auf (liegt bei uns im Autostart, brauchen wir für unser Intranet), Outlook ist vielleicht geöffnet, weil ich den Button blind getroffen habe, irgendsowas passiert also. Nun klicke ich z.B. auf den Posteingang im Outlook. Ich sehe keine Reaktion. Ich trenne die Session erneut (manchmal auch gerne per Taskmanager, weil mir das sonst zu lange dauert) und verbinde mich wieder. Jetzt sehe ich also meinen Posteingang.
So geht das eine ganze Weile, gerne auch mal ein, zwei Stunden. Irgendwann dann läuft es. Wie gesagt: nach Stunden! Irgendwann kann ich das Ding ganz normal bedienen. Wenn ich mich dann abmelde und wieder anmelde, ist das kein Problem. Vielleicht geht es auch morgen ohne Probleme. Und übermorgen ist es dann wieder so wie beschrieben.
Ich habe zwei Terminalserver zur Auswahl, es gibt kein Gateway dazwischen. Ich habe mich selbst und einen Domänen-Admin und zum Test auch mal einen anderen User ausprobiert: es ist immer dasselbe, also kein Profilproblem oder so.
Ich vermute nun irgendeine DLL oder den RDP-Cleint auf meinem Firmennotebook, obwohl mein Privatnotebook zumindest mal den gleichen Patchstand (aktuell) hat.
Vielleicht sollte ich noch hinzufügen, dass die Terminalserver auf VMware laufen, wobei ich damit vom Client aus nicht in Kontakt komme. Die VM-Treiber sind aktuell.
Hat da jemand mal von einer Lösung dafür gehört?
Gespannte Grüße
Y.
Ich habe da ein Phänomen, das bereits seit Jahren von vielen beschrieben wird, viele fragen danach, aber so eine echte Lösung habe ich bisher nicht gefunden.
Ich verbinde mich auf einen Terminalserver 2008 R2, Patch-Stand Dezember 2015.
Verbinde ich mich mit meinem Firmennotebook mit Windows 7, ist alles tutti.
Verbinde ich mich mit meinem Privatnotebook mit Windows 7, 8.1 oder 10, ist alles tutti. Egal, ob per WLAN im Büro oder von zu Hause über VPN.
Verbinden sich meine rund 50 Kollegen mit was auch immer, einschließlich Linux und Mac als Client, ist alles tutti.
Nur seit ich mein Firmennotebook (das erste oben in der Liste, i5, 12GB RAM, keine Leistungsbremsen, das Ding kann was) von Windows 7 auf 10 aktualisiert habe, gibt es folgendes Bild:
Ich melde mich am Terminalserver an, der Desktop erscheint und das Bild bleibt stehen. Es friert nicht die Session ein, ich kann sie nur nicht mehr bewusst bedienen. Wenn ich mit Maus oder Tastatur irgendwelche Aktionen ausführe, klicke, Shortcuts abfeuern o.ä. funktioniert das, ich sehe es nur nicht.
Jetzt trenne ich die RDP-Verbindung, was übrigens sehr, sehr lange dauert, manchmal gerne auch eine Minute (über das X im blauen Balken) und auch Minimieren braucht so eine gefühlte halbe Minute und anschließend schalte ich mich neu auf. Jetzt habe ich ein neues Bild. Z.B. ist der IE auf (liegt bei uns im Autostart, brauchen wir für unser Intranet), Outlook ist vielleicht geöffnet, weil ich den Button blind getroffen habe, irgendsowas passiert also. Nun klicke ich z.B. auf den Posteingang im Outlook. Ich sehe keine Reaktion. Ich trenne die Session erneut (manchmal auch gerne per Taskmanager, weil mir das sonst zu lange dauert) und verbinde mich wieder. Jetzt sehe ich also meinen Posteingang.
So geht das eine ganze Weile, gerne auch mal ein, zwei Stunden. Irgendwann dann läuft es. Wie gesagt: nach Stunden! Irgendwann kann ich das Ding ganz normal bedienen. Wenn ich mich dann abmelde und wieder anmelde, ist das kein Problem. Vielleicht geht es auch morgen ohne Probleme. Und übermorgen ist es dann wieder so wie beschrieben.
Ich habe zwei Terminalserver zur Auswahl, es gibt kein Gateway dazwischen. Ich habe mich selbst und einen Domänen-Admin und zum Test auch mal einen anderen User ausprobiert: es ist immer dasselbe, also kein Profilproblem oder so.
Ich vermute nun irgendeine DLL oder den RDP-Cleint auf meinem Firmennotebook, obwohl mein Privatnotebook zumindest mal den gleichen Patchstand (aktuell) hat.
Vielleicht sollte ich noch hinzufügen, dass die Terminalserver auf VMware laufen, wobei ich damit vom Client aus nicht in Kontakt komme. Die VM-Treiber sind aktuell.
Hat da jemand mal von einer Lösung dafür gehört?
Gespannte Grüße
Y.
Kommentieren
Teilen
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: 301150
Url: https://administrator.de/forum/anzeige-der-rdp-session-friert-nach-anmeldung-ein-301150.html
Ausgedruckt am: 26.04.2025 um 02:04 Uhr
4 Kommentare
Neuester Kommentar
Nachtrag: auf den Windows 10 Rechnern ist jeweils auch der gleiche RDP-Client Version 10.0.10586 installiert.
Mit dem Programm "RdClient" z.B. funktioniert alles, nur leider unterstützt das Programm nur einen Monitor, ich brauche zwei. Mir würde als schnelle Abhilfe ein RDP-Client für Windows 10 genügen, der zwei Monitore unterstützt und eben NICHT auf den systemeigenen Client zurückgreift, wie ich es bei einigen getesteten Clients bisher gefunden habe.
Y.
Mit dem Programm "RdClient" z.B. funktioniert alles, nur leider unterstützt das Programm nur einen Monitor, ich brauche zwei. Mir würde als schnelle Abhilfe ein RDP-Client für Windows 10 genügen, der zwei Monitore unterstützt und eben NICHT auf den systemeigenen Client zurückgreift, wie ich es bei einigen getesteten Clients bisher gefunden habe.
Y.
Noch ein Nachtrag:
Mir ist durch einen Test mit nur einem Monitor jetzt aufgefallen, dass das Bild in der Session etwa alle fünf bis zehn Minuten aktualisiert wird (hab nicht so auf die Uhr geschaut, habe ich zufällig gesehen).
Y.
Mir ist durch einen Test mit nur einem Monitor jetzt aufgefallen, dass das Bild in der Session etwa alle fünf bis zehn Minuten aktualisiert wird (hab nicht so auf die Uhr geschaut, habe ich zufällig gesehen).
Y.
Das Problem ist nicht gelöst, ich habe nur die Frage geschlossen, weil so gar keine Rückmeldung kommt.
Nachtrag: Ursache gefunden!
Dass es zwischendurch mal funktioniert hat, lag weniger an den Windows-Updates, als vielmehr daran, dass ich ungefähr zeitgleich den Haken in der RDP-Verbindung herausgenommen habe, dass SmartCards übergeben werden sollen. Ich habe eine SmartCard, brauche die aber nur gelegentlich mal für die Anmeldung auf einer bestimmten Webseite. Inzwischen ist für den Reader ein neuer Treiber herausgekommen und siehe da: das war's. Läuft jetzt seit drei, vier Wochen ohne Probleme.
Dass es zwischendurch mal funktioniert hat, lag weniger an den Windows-Updates, als vielmehr daran, dass ich ungefähr zeitgleich den Haken in der RDP-Verbindung herausgenommen habe, dass SmartCards übergeben werden sollen. Ich habe eine SmartCard, brauche die aber nur gelegentlich mal für die Anmeldung auf einer bestimmten Webseite. Inzwischen ist für den Reader ein neuer Treiber herausgekommen und siehe da: das war's. Läuft jetzt seit drei, vier Wochen ohne Probleme.
