[English]Ich greife erneut das Thema RDP-Probleme unter Windows 11 (24H2) hier im Blog auf. Nachdem es im Januar 2025 bereits entsprechende Meldungen gab, tauchen weitere Nutzerkommentare auf, die auch im Umfeld der Februar 2025 Sicherheitsupdates von Probleme mit Remote Desktop Protocol (RDP) Verbindungen berichten. Hier eine kurze Zusammenfassung.
Anzeige
Erste Meldungen im Januar 2025 mit Ursachen
Mitte Januar 2025 hatte ich im Blog-Beitrag Windows 11 24H2: Hängende RDP-Session als Problem die Beobachtung eines Blog-Lesers aufgegriffen, der sich über hängende RDP-Sessions bei Windows 11 24H2 beklagte. Es scheint aber diverse Ursachen zu geben.
Reiner SCT Chipkartenleser als Ursache
Ein Blog-Leser meldete sich in diesem Kommentar und gab den lokal angeschlossenen Reiner SCT-Chipkartenleser als Ursache an. Eine Aktualisierung des Treibers für den Leser behob dieses Problem.
Wallpaper als Problem
Interessant ist dieser Kommentar eines Blog-Lesers, der das Wallpaper (für das Hintergrund des Desktop) wohl als Problem identifiziert hat. Seit dem Setzen der GPO für die Entfernung des Wallpapers sei das Problem weg, schrieb er.
Sollte in gpedit.msc im Zweig Lokale Computerrichtlinie, Computerkonfiguration, Administrative Vorlagen, Windows-Komponenten, Remotedesktopdienste, Remotedesktopsitzungshost, Remotesitzungsumgebung einstellbar sein. Dort gibt es die Gruppenrichtlinie "Erzwingen des Entfernens von Remotedesktop-Hintergrundbildern".
Anzeige
Bolko hat in diesem Kommentar ebenfalls diese Details zusammen getragen und gibt an, dass die folgenden .reg-Anweisungen die gleiche Wirkung erzielen.
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services] "fNoRemoteDesktopWallpaper"=dword:00000001
Allerdings gibt es auch Nutzer, die schreiben, dass das Entfernen des Wallpaper bei den RDP-Problemen nicht gewirkt habe. Das wird beispielsweise hier und hier berichtet.
Netzwerkerkennung auf dem Server
Ein weiterer Blog-Leser schreibt in diesem Kommentar, dass die Netzwerkerkennung auf dem Server einen Einfluss habe. Er hat im Gruppenrichtlinien-Editor den folgenden Zweig aufgerufen:
Computer Konfiguration > Administrative Vorgaben > Windows Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Verbindungen
Dort ist die Gruppenrichtlinie "Netzwerkerkennung auf dem Server auswählen" zu aktivieren. Es gibt Bestätigungen von Lesern, dass dies in ihrem Fall geholfen und die RDP-Probleme beseitigt habe.
Meldungen im Februar 2025
Zum Februar-Patchday (12.2.2025) haben sich einige Nutzer zum Blog-Beitrag Patchday: Windows Server-Updates (11. Februar 2025) mit Kommentaren gemeldet, die RDP-Probleme ansprechen.
Windows Server 2025: RDP-Anmeldung hängt
Blog-Leser Brima berichtet hier, dass das Sicherheitsupdate KB5051987 für Windows Server 2025 etwas bei Remote Desktop Verbindungen kaputt mache. Baut ein Nutzer eine RDP Session auf und trennt diese dann, wird diese auch als getrennt angezeigt. Bei einer späteren Anmeldung an der getrennten Verbindung wird diese erneut als aktiv angezeigt. Die Anmeldung bleibt aber auf dem Login Screen hängen, und ein Arbeiten ist unmöglich. Man muss die Verbindung im Task-Manager beenden, um sich erneut anmelden zu können.
Auch hier hilft es, die Netzwerkerkennung in den Gruppenrichtlinien (gpedit.msc) über folgenden Zweig:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections
mittels der GPO "Select network detection on the Server" auf enabled zu setzen.
Das bringt mich zur Frage: Gibt es bei euch RDP-Probleme und habt ihr eine Lösung gefunden?
Anzeige
Ich habe das Problem seit heute auch. Der Client PC ist schon länger auf 24H2 und bisher keine Probleme. Gestern nun den Host auch auf 24H2 gebracht und seitdem eingefrorener Bildschirm nach Eingabe des Passwortes.
Die GP "Select network detection on the Server" auf enabled gesetzt und es geht wieder.
Wir hatten bei mehreren Personen die selben Probleme.
Das einzige was hier geholfen hatte war die GPO-Einstellung für die Netzwerkerkennung auf dem Server, seit dieser Änderung gab es keine Beschwerden mehr.
Wir haben seit einigen Tagen bei manchen Usern das Problem dass die RDP-Verbindung auf unsere Terminalserver einfach abbricht. Man kann sich erneut anmelden und nach 2 Minuten bricht sie einfach wieder ab.
Habe ich hier auch, mit den Win11 24H2 Clients. Ist bei Dir nach dem Wiederherstellen der RDP-Verbindung dann auch die Authentifizierung der Verbindung von Kerberos auf Zertifikat gewechselt?
Habe ich auch. Gibt es dazu schon eine Lösung? 2-3 Minuten und die Verbindung von 24H2 zu TS 2016 bricht zusammen.
Hier auch seit einigen Tagen das Problem. 24H2 alleridngs schon vor 2 Wochen installiert.
Verbindung wird hergestellt und bricht nach ca. 1 Minute ab, Reconnectversuch funktioniert sofort, usw.
bei der GP "Netzwerkerkennung auf dem Server auswählen" (Select network detection on the Server) gibt es aber vier Auswahlmöglichkeiten. Welche haben den die Schnellklicker ausgewählt
Hallo. bei mir hat es mit der Auswahl "Netzwerkerkennung und fortlaufende Verbindungszeiterkennung deaktivieren" geklappt. (Hatte massive Probleme mit Win10 zu Win11 24H2 und von Ubuntu 24.04.2 LTS zu dem Win11 24H2.)
Hab hier auch massive Probleme seit gestern. Die RDP Verbindungen zu allen 2012 Server brechen nach ca. 70 sek. ab und reconnecten. Nicht katastrophal aber nervig.
GP für Netzwerkerkennung und Verbindungszeiterkennung aktiviert und abgeschaltet und RDP Transportprotokolle auf TCP und RDP zu setzen bringt auch nix. Aber was hilft ist HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client
New DWORD value: fClientDisableUDP SET TO 1
Danach läuft die RDP Session zwar stabil ab es gibt Probleme bei der Anmeldung.
Funktioniert soweit!
Ich hatte das Problem auch. Die Konfiguration von TCP anstelle von UDP für RDP hat geholfen.
Dieser Tipp hat mir geholfen. Ich habe erst alle anderen Hinweise (vorherige) dazu probiert, allerdings ohne Erfolg. Nungeht alles wieder, Dankeschön.
Das hat bei mir auch geholfen!
Danke
Ich hatte ein Hintergrundbild. Nach Entfernung habe ich keine Probleme mehr. Aber irgendwie ist der ganze Vorgang anders als vor 24H2 Ob MS da ein Caching oder Appstreaming oder ähnl. vorgeschaltet hat?
Danke für die Hinweise
Habe ebenfalls eine Kombination Client 24H2 und Host 24H2. Sporadisch bleibt bei der RDP Anmeldung der Bildschirm schwarz und wird nach ca. 10 sec mit einer Fehlermeldung (passt nicht zum Problem) abgebrochen. Die Verbindung klappt ein paar mal, wenn der Host neu gestartet wurde und nicht angemeldet ist. Vermehrt passiert das über SSL VPN, aber auch im LAN. Geholfen hat hier der Tipp mit der Hintergrundbild GPO und die Aktivierung der Netzwerkerkennung. Konnte nun zuverlässig die RDP Verbindung aufbauen. Danke für die Tipps.
Gruß blablax
Bitmap Zwischenspeicherung abschalten oder Auflösungstiefe niedriger stellen oder Vollbild abschalten. Dann funktioniert es bei mir.
BSOD mit Power Driver State Failure nur bei RDP Verbindung mit Freezing and Bluescreen seit Monaten: BIOS Updates, Windows Updates, Intel Updates und Dell Updates haben nicht hat geholfen!
Beim ersten Client mit 24H2 nun auch der Fall. Anmeldebildschirm reagiert nicht. Vor 2 Wochen noch einwandfrei funktioniert. Kann ich diese Richtlinie auch auf dem DC in der gruppenrichtlinienverwaltung für alle Clients setzen?
Hat sich teilweise erledigt. Nur kann man ohne auf den Client zu kommen und ohne Neustart die Richtlinie aktivieren? Auf dem Client direkt geht es ja per Befehl. Aber gerade schwierig physisch auf den PC zu kommen.
Ich hatte das Problem auch. Die Konfiguration von TCP anstelle von UDP für RDP hat geholfen.
Wenn wir den Microsoft RDP Client aus dem AppStore nutzen statt des windowseigenen RDP Clients, dann sind alle Probleme behoben.
Hi,
bei mir ähnlich, ich habe nur das Problem, dass der Microsoft RDP Client aus dem AppStore mir nicht alle Monitor mit in die RDP-Session nimmt. Weiß einer wie man das einstellt?
Ich kann das Problem auch bestätigen und zwar beim Verbindungsaufbau zu mittlerweile mind. 4 RDP "Servern". Ich finde es gut, dass Microsoft sehr bemüht ist immer neue Bugs in Windows zu implementieren.
Ich hab mir einen neuen Heim-Boliden mit 24H2 aufgesetzt und hatte auch mit RDP zu kämpfen. Der Alte war nicht mehr wirklich Win 11 tauglich, hatte es zwar geschafft, auf 23h2 zu gehen, aber 24h2 geht jetzt nicht mehr, da lässt sich das mit TPM 2.0 jetzt nicht mehr umgehen, die Kiste bootete dann nach Update nicht mehr. Schade um den alten Rechner, 8/16 Kern Xeon, 64GB RAM, dass man sowas in Rente schicken muss… naja, vielleicht bekommt er mit Ubuntu oder so noch ein zweites Leben… Das war dann jetzt die Gelegenheit, eine seit Windows 7 existierende, immer wieder upgedatete Installation mal von Grund auf auf einer neuen Hardware mit neuer SSD neu zu machen. Jedenfalls hab ich jetzt geschlagene 1,5 Stunden damit verbracht, RDP auf der neuen Kiste zu konfigurieren, bin eigentlich gewohnt, dass das out-of-the Box funzt. Klassifizierung des Netzes als Privat gecheckt, war Ok, Firewallregeln gecheckt, war auch Ok, User als Remotedesktop-Benutzer war eingetragen (ist ja sowieso Admin, aber doppelt gemoppelt hält besser), Remotedesktopdienst automatisch starten war Ok, tnc ip-adresse -p 3389 war auch Ok, obige Gruppenrichtliniensettings hab ich gemacht, hat aber nichts geändert. Ich musste dem PC im Netz eine feste IP geben und kann ihn per RDP auch nur über die IP ansprechen, da der Heim-Router keinen internen DNS macht (komischerweise setzt der Speedport-Router eine getätigte IP-Reservierung anhand der Mac-Adresse nicht um, aber das ist eine andere Baustelle), mit dem alten PC klappte das trotzdem, keine Ahnung warum. Im Explorer per \\rechnernamen anzusprechen klappt aber, den Unterschied kennen wohl wiedermal nur die Götter… Dann wies der neue PC den Login als fehlerhaft ab, war im Eventviewer zu sehen, obwohl User und Passwort richtig waren, erst als ich in der Eingabeaufforderung "runas /user:username(at)outlook.com cmd.exe" gestartet habe, wurde auch der Remotezugriff aktzeptiert, tsss…. Und zuletzt war meine AMD-Grafikkarte (für Fotobearbeitung) auf 10 Bit Farbtiefe eingestellt, was zu Fehlfarben in der RDP-Verbindunbg führte, seltsam, das eine sollte nichts mit dem anderen zu tun haben. Immerhin positiv, mit dem Patchmypc Homeupdater konnte ich in einem Rutsch rund 40 Tools, die ich mindestens gelegentlich nutze, in einem Rutsch installieren, das hat bestimmt einen ganzen Tag eingespart, den Kram einzeln runter zu laden und zu installieren und umging auch die nervigen Hinweise vom Egde wenn man einen anderen Browser runterladen will.
Das mit dem runas ist ja kurios! Auf die schräge Idee muss man erstmal kommen!
Würde mich interessieren, warum das so ist! Wie es aussieht, bist du ja mit MS-Account unterwegs?! Da muss man ja heutzutage bei Erstanmeldung an einem PC nicht mal mehr das Passwort eingeben, sondern die Authentikator-App auf dem Handy meldet sich nach Accounteinnahme und man muss dort bestätigen. Vielleicht liegt deswegen auf dem Zielsystem (für RDP) noch kein Passworthash vor, der erst beim Runas Anmelden erzeugt wird? Irgend sowas schräge muss das sein!
Meine bisherigen Posts haben nur temporär geholfen. Jetzt habe ich in den Verbindungsoptionen von automatischer Verbindungsgüte auf 10Mbit umgestellt. Jetzt kann ich sonst alles aktiviert lassen und die Verbindung kommt immer zu Stande.
Dann hast du ein Problem wahrscheinlich außerhalb des PCs, Qualität/Länge des Netzwerkkabels, Kompatiblität zwischen Netzwerkkarte des PCs und Switches, oder sowas.
Klingt nach defektem Netzwerk-Kabel oder -Stecker/Buchse.
Bei uns hatte es anscheinend am veralteten Grafiktreiber der Intel Grafikeinheit gelegen. Einfach die neuste Version von 2024 (vorher war noch irgendein Windows 10-Treiber aus 2021 installiert (irgendwann mal inplace-upgrade gemacht)) installiert, neu gestartet, et voila, RDP auf die Jump-Hosts läuft wieder fluffig und flutschig, wie vor dem Februar Patchday. Aber seltsam, dass es erst diese Symptome zeigte, als Microsoft versucht hatte, die Probleme zu beheben, die wir vor dem Februar-Patchday nicht hatten.
Die Spielereien in den GPO bez. Wallpaper und oder TCP/UDP brachten leider keine Besserung.
Konnte das Problem eingrenzen auf: per Android App zum Client (nur Windows 11 24H2 funktioniert nicht) verbinden. Gehe ich per Remotedesktopverbindung oder Remotedesktop App von einem Windows PC auf den Client funktioniert die Verbindung.
Alle Probleme und Lösungen deuten auf eine murks Implementierung von RDP over UDP hin. Mit RDP over TCP gibt's keine Probleme außer theoretisch etwas mehr overhead beim Traffic.
Ich habe das Problem bei einer RDP-Verbindung von Windows 11 24H2 zu Windows 11 24H2. Nach Eingabe von Benutzername+Kennwort bleibt der Bildschirm einfach schwarz. Bei 10 Verbindungsversuchen klappt es mit Glück 1x, aber in 9 Fällen muss ich eine oder beide Maschinen rebooten.
Die ganzen Spielerein mit Registry und GPOs helfen nicht. Es ist zum veruweifeln.
Hast du die App ausprobiert? Bei mir hat ebenfalls kein anderer Lösungsvorschlag funktioniert. Mit der Windows-App funktioniert es jetzt wieder.
Ergänzend zu meinen bisherigen RDP Verbindungs-Problemen von W10 zu W11 Clients
https://www.borncity.com/blog/2025/01/18/windows-11-24h2-haengende-rdp-session-als-problem/#comment-205862
scheint es jetzt seit den Updates letzter Woche auch bei W11 23H2 zu W11 24H2 aufzutreten.
Die GPO "Erzwingen des Entfernens von Remotedesktop-Hintergrundbildern" hat aber jedes Mal Abhilfe geschaffen.
Fehler seit 13.02. (Patchday Februar 2025) – Win 11 24H2 Rechner haben RDP Verbndungsprobleme zu einem x-beliebigen Server (Bei mir ist es ein Win-Server 2012 (TS))
RDP-Verbindung Win 11 24H2 => Win Server 2012 (TS) => 1-2 Minuten geht es dann für 2-10sec Verbindungsunterbrechnung
GPO:
[1] Computer Konfiguration > Administrative Vorgaben > Windows Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Verbindungen
=> Welche Option ist hier zu setzen? Aktuell habe ich "Verbindungszeiterkennung und fortlaufende Netzwerkerkennung deaktivieren"
[2] RDP-Transportprotokoll => aktiviert mit der Option "UDP und TCP verwenden"
Hintergrundbild deaktiveren muss ich noch testen
RDP-App aus dem Windows Store installiert und siehe da, keine Verbindungsabbrüche. Das ganze rumgebastle spare ich mir bis das behoben wurde :-P
In zeitlicher Korrelation hatten wir just heute noch das gleiche Problem allerdings mit der anzupassenden MTU behebbar, bei bestimmten ISP, in diesem Fall o2 über das Vodafone-Kabelfernsehnetz. Die MTU des VPN-Tunnel-Interface musste auf 1300 resp. 1272 herabgesetzt werden und schon schwupperte das Ganze wieder wie gewohnt. Vorher hatte der Kollege einen o2-Mobilfunkhotspot, darüber hatte er keinerlei solcher Probleme.
Wir haben nur RDP Probleme wenn der Host Windows 11 24H2 ist. Diese Hosts sind bei uns Teils über eine Raritan KVM Box angebunden. Wurde nun über KVM eingeloggt auf die Konsole des Windows 11 24H2 hosts und RDP soll diese Sitzung übernehmen, bleibt der Versuch einfach hängen und man sieht teile des Sperrbildschirms. RDP Client schliessen und erneut einloggen funktioniert dann aber. Ebenso funktioniert RDP einwandfrei wenn eine RDP Session übernommen werden soll. Probleme gibt es also nur, wenn eine Konsole Session besteht und übernommen werden soll.
Seit ich den Windows 11 Client auf 24H2 aktualisiert habe, friert auch bei mir die RDP Session auf einen Windows 2019 Server ständig ein. Saunervig und unfassbar, dass Microsoft das Problem scheinbar komplett ignoriert. Das Schrauben an den Registry Einstellungen und der GPO hat nichts gebracht. Ich habe den Client auf Ubuntu 24 LTS umgestellt, jetzt läuft es wieder super stabil mit xfreerdp3. Smartcards, Audio, Micro wird durchgeschleift, Kamera leider nicht.
Der Zugriff auf meinen Home PC mit 24H2 ist von Windows 10 aus mit RDP unmöglich. Die Nutzung der Remotedesktop App aus dem Store ändert daran nichts.
Einmal gibt es nur einen schwarzen Bildschirm, einml den Sperrbildschirm ohne Reaktion, manchmal schafft man es bis zur "Willkommen" Meldung. Danach passiert aber nichts.
Ich finde es unverschämt von MS, daß Fehler bei einer so wichtigen Funktion für zahlende Kunden nicht behoben werden.
Zum Glück gibt es Chrome-RDP und diverse andere Apps die man solange nutzen kann.
Nachstehend das funktionierende workaround über gpedit.msc :
https://winaero.com/windows-11-24h2-has-issues-with-rdp-after-recent-udpates/
Es hat auf jeden Fall mit dem zugrunde liegenden Netzwerk zu tun. O2 Internet und FortiClient IPSec VPN: keine Verbindung per RDP möglich.
Geht man über mobile hotspot (Telekom) rein können wir mit der gleichen VPN Verbindung ohne Probleme connecten.
Ich werde die MTU Einstellung versuchen anzupassen. Die verschiedenen Einstellungen die hier im Thread vorgeschlagen wurden, haben bei uns nichts gebracht.
in Windows adm.CMD:
netsh interface ipv4 show subinterfaces
i.d.R. reicht es, wenn der VPN-Adapter bspw. "Ethernet 2" heißt, die MTU auf 1228 (um ganz auf Nummer sicher zu gehen!) zu drücken:
netsh interface ipv4 set subinterface "Ethernet 2" mtu=1228 store=persistent
dann sollte der Ziel-RDP-Host entsprechend ohne zusätzliche Fragmentierung erreichbar sein:
ping -f -l 1200 IP-oder-Name-des-RDP-Ziel-Host
Das hat bisher immer geholfen, auch bei so Krachern wie 1&1 über einen untergemieteten Telekom-Zugang, die machen nämlich auch so Schweinereien.
Nein einen Wechsel der Authentifizierung kann ich nicht feststellen. Ich habe noch einmal die Zeit gestoppt. Es sind exakt 60 Sekunden. selbst wenn ich von dem Client einen dauerping auf den Server , oder in der laufenden Sitzung einen dauerping vom Server auf einen anderen absetze, wird die Verbindung getrennt.
Keep-Alive Einträge sind gesetzt. Im Ereignisprotokoll ist nichts besonderes festzustellen. Habe alternativ einen alten RDP-Manager laufen. Dort bleibt die Verbindung aufrecht. Wird also am MSTSC liegen.
Eine weitere spannende Erkenntnis:
Eine Anmeldung mit
[DOMAINNAME]\[Username]
schlug mit einem weißen Screen fehl, eine Anmeldung mit
[Username]@[FQDN]
funktionierte dann sofort.
Vielleicht war es auch nur Zufall, ein weiteres Mal klappte es dann nach einem Verbindungsabbruch doch nicht mehr.
Interessanterweise kann ich mich gerade von einem W10 PC aus auf den W11 Client verbinden, von einem anderen W11 24H2 Client aber nicht.
GPO für den Hintergrund ist beim Client gesetzt.
Hier wäre es interessant zu wissen, welcher RDP-Client installiert ist, der mit schwarz/weißen Leiste, oder der mit der blauen?
Denn irrwitzigerweise ist beim alten Client (blaue Leiste) keine MTU-Anpassung erforderlich und es fluppt sofort. Insofern schon einmal danke für den Hinweis!
Hallo in die Runde,
auch hier die gleiche Problematik.
Folgende Beobachtungen:
– Surface Win11 24H2 (UpToDate) -> L2TP VPN -> mstsc -> TinyPC Win11 24H2 (UpToDate) – Keine Verbindung – Schwarzes Bild – 10 bis 15 Sekunden – Fehler
– Laptop Win10 22H2 (UpToDate) -> L2TP VPN -> mstsc -> TinyPC Win11 24H2 (UpToDate) – Verbindung ohne Probleme möglich
– Surface Win11 24H2 (UpToDate) -> L2TP VPN -> mstsc -> VM Win10 22H2 (UpToDate) – Verbindung ohne Probleme möglich
Auffällig, dass das Problem aktuell scheinbar nur mit Win11 24H2 in Zusammenhang steht. Alle hier vorher genannten Lösungsansätze haben leider nicht geholfen das Problem zu lösen.
Vielen Dank für das Posten aller Ideen.