[English]Ich stelle mal die Beobachtung eines Blog-Lesers hier im Blog ein, die sich auf Remote Desktop Protokoll-Sitzungen (RDP-Sessions) unter Windows 11 24H2 bezieht. In der Umgebung des Lesers gibt es dort massive Probleme, dass diese RDP-Sitzungen bei den Nutzern in bestimmten Szenarien hängen. Es scheint aber kein Einzelfall zu sein, wie ich gesehen habe.
Anzeige
Nutzer meldet Windows 11 24H2 RDP-Problem
Ein Blog-Leser hat mich gerade kontaktiert, nachdem er in seiner betrieblichen Umgebung auf ein RDP-Problem gestoßen ist. Eingesetzt wird Windows 11 24H2 in einer Firmenumgebung. Dabei kommen auch Sitzung über das Remote Desktop Protokoll (RDP) zum Einsatz.
Nun stellt der Blog-Leser fest, dass seit dem Umstieg auf Windows 11 24H2 der RDP-Logon Prozess in dieser Arbeitsumgebung Probleme bereitet. Laut Leser hängt die RDP-Anmeldung, wenn der betreffende Benutzer bereits eine aktive, aber getrennte Verbindung auf einem Client hat.
Beim Versuch sich einzuloggen, bleibt dieser einfach Vorgang bei dem in obigem Bild gezeigten Zustand hängen (der Kreisel dreht sich auch nicht weiter). Die einzige bisher bekannte Lösung besteht derzeit darin, den Client beispielsweise per PowerShell-Remote neu zu starten.
Anzeige
Problembeschreibung auf reddit.com
Der Blog-Leser hat dann recherchiert und ist auf reddit.com auf den Thread Windows 11 24H2 – RDP session hangs on logon von Oktober 2024 gestoßen. Dort fragt der Thread-Ersteller, ob andere Nutzer auch Probleme mit RDP-Sitzungen unter Windows 11 24H2 haben. Beim ihm bleibt der Prozess bei der RDP-Anmeldung hängen – genau wie oben beschrieben.
Dieser Benutzer gibt an, dass RDP-Verbindungen zu Windows 10 oder Windows 11 23H2 gut funktionieren. Sobald aber versucht wird, eine RDP-Verbindung zu einer Maschine mit Windows 24H2-Version herzustellen, bleibt der Vorgang bei einfach hängen und der Prozess friert ein.
Die einzige Lösung, die der Nutzer gefunden hat, sei ein Neustart des Rechners, schreibt er. Danach kann der Benutzer wieder für einige Zeit eine normale RDP-Verbindung herstellen. In diesem Szenario laufen alle Maschinen auf einem Hypervisor.
Im Thread bestätigen weitere Nutzer dieses Problem, wobei diese Hänger sowohl bei virtuellen Maschinen als auch bei physischen Rechnern beobachtet werden. Dort hat ein Nutzer angemerkt, dass auch Windows Server 2025 betroffen sei. Ein Ticket bei Microsoft sei seit längerer Zeit offen, ohne dass ein Fix avisiert ist.
Komischerweise scheinen RDP-Verbindungen zu Windows 11 24H2-Maschinen die Probleme nicht aufzuweisen. Nur eine RDP-Verbindung von einer Windows 11 24H2-Maschine zu einem anderen Rechner zeigt diese Problematik. Ein Betroffener schrieb, dass er das Problem mittels sfc /scannow beheben konnte – dort waren wohl beschädigte Systemdateien die Ursache. Scheint aber keine generelle Lösung zu sein.
Weitere Treffer im Web
Bei einer Suche bin ich auf den Microsoft Answers-Forenthread RDP sessions on mostly windows 11 computers stop responding vom 14. November 2024 gestoßen, wo das gleiche Problem der hängenden RDP-Sitzungen angesprochen wird. Eine Lösung gibt es dort nicht.
Interessanter erscheint mit im Microsoft Answers-Forum der Thread Issue where remote desktop connection to Windows 11 Pro (24H2) cannot be established vom 7. November 2024. Dort wird das gleiche Problem der hängenden RDP-Sitzungen angesprochen, wobei der Thread bereits drei Seiten umfasst. Dort berichtet ein Benutzer, dass in seiner Umgebung ein Workaround per Gruppenrichtlinie Besserung bringe. Er hat im Gruppenrichtlinien-Editor unter:
Local Computer Policy> Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment
Die Richtlinie Enforce Removal of Remote Desktop Wallpaper auf Enabled gesetzt.
Kennt jemand eine Lösung?
Dabei merkt der Leser an, dass die monatlichen Microsoft Updates (also auch das Januar 2025-Sicherheitsupdate) dieses Problem nicht zu adressieren scheinen. Das spiegelt sich auch im reddit.com-Thread Windows 11 24H2 – RDP session hangs on logon wieder. Dort gibt der Thread-Ersteller in mehreren Nachträgen an, dass er auf dem Patch-Level .2894 sei und sich immer noch nicht per RDP an existierenden Sitzungen anmelden könne. Der Patch-Level .2894 entspricht dem im Beitrag Patchday: Windows 10/11 Updates (14. Januar 2025) beschriebenen Stand von Windows 11 24H2.
Der Blog-Leser bat mich zu fragen, ob jemand aus der Leserschaft das Problem ebenfalls beobachtet und gegebenenfalls eine Lösung hat. Wirkt ggf. die im vorhergehenden Abschnitt angesprochene Lösung per Gruppenrichtlinie?
Ähnliche Artikel:
Microsoft Security Update Summary (14. Januar 2025)
Patchday: Windows 10/11 Updates (14. Januar 2025)
Patchday: Windows Server-Updates (14. Januar 2025)
Patchday: Microsoft Office Updates (14. Januar 2025)
Nachlese: Windows Patchday-Probleme Januar 2025
Windows 10/Server 2022: Dienst SgrmBroker startet nach Jan. 2025-Update (KB5049981) nicht mehr
Achtung: Probleme mit Windows Januar 2025-Updates und Citrix Umgebungen (Session Recordings)
Anzeige
Kann ich nicht bestätigen, haben 24H2 zu 24H2 und Server 2019 täglich im Einsatz.
Ausprobieren / Testen ob RDP nur mit TCP Verbindung das Problem löst. (Würde ich sowie so grundsätzlich empfehlen diese Einstellung / GPO zu nutzen)
Auch nein uns mit 24h2 zu x-beliebigen Systemen keine Probleme inkl. Home Office zum Unternehmen.
Ich hatte nach der Installation von 24H2 auch ähnliche Probleme … die Verbindung von einem W10 zu dem W11 hing sofort beim Aufbau oder klappte erst mal und hing dann nach einiger Zeit
Nach dem Rückgang auf 23H2 lief alles wieder wie zuvor
Kann ich nicht bestätigen, habe mehrere Systeme mit 24H2 und verbinde täglich zu dutzenden Server2019, keine Probleme.
Seit Dezember kann ich auch Probleme mit RDP Sitzungen feststellen aber hier ist es kei Win11 spezifisches Problem. Die Verbindung wird nur per TCP zu einem Server2019 Cluster hergestellt. Die Clienten sind Windows 10 und Windows 11 gemischt.
Als Ursache konnte ich bislang den Lokal angeschlossenen Reiner SCT Chipkartenleser ausmachen. Bei Clienten mit Problemen war das alte 7.x Treiberpaket installiert. Wenn man mal auf den RDP Server kam wurde die Karte nicht sauber durchgereicht (Datev).
Ein Wechsel auf das neue Treiberpaket mit der Version 1.5 hat hier geholfen. Die Verbindung klappt wieder Problemlos ohne Unterbrechungen und die Karte funktioniert auch wieder.
Wenn man bei der Hängenden Anmeldung 'Glück' hat findet man ggf ein Fenster dahinter mit einer Fehlermeldung. Leider habe ich die nicht gespeichert. Das man manchmal das Problem mit sfc /scannow beheben kann hatte ich auch schon. Irgendetwas klemmt da an der Benutzer Authentifizierung aber vermutlich nur deswegen weil viel tiefer irgendwas in der IP Kommunikation nicht funktioniert. Die Meldungen sind dann wohl nur Auswirkungen die in die Irre führen.
Technische Rückfrage: Wie kann ein Chipkartenleser Treiber Auswirkungen auf eine RDP Sitzung haben und diese quasi anhalten?
Und Nachfrage: Ist sowas nicht quasi ein DOS (Denial of Service) Hebelpunkt?
Der Smartcardleser (egal welcher Hersteller) kann in den Einstellungen des RDP Clienten zum Server durchgereicht werden. Das ist für verschiedene Szenarien nötig. Es gibt Serveranmeldungen auf Smartcard Basis und Anwendungen wie Datev, Signatur oder Ausweis Online auf Terminalserver. Am Server ist in diesem Fall kein physischer Smartcard Leser angeschlossen. Das wird dann alles vom lokalen Leser über die RDP Sitzung zum Server geleitet. Inwiefern der Treiber da irgendwo in die Kommunikation eingreift kann ich nicht sagen. Ich bin kein Coder. Ich kann das Problem aber in diesem Fall jederzeit nachstellen. Das muss mit irgendeinem Update von MS im November oder Dezember zu tun haben. Leider haben sich die betroffenen Kunden erst sehr spät gemeldet und das Problem verschleppt, so dass ich es nicht genau festmachen kann, welches Update nun das das Problem ausgelöst hat. Ich sehe derzeit nur, das es mit dem neuen Reiner Treibermodell in der Version 1.5 derzeit problemlos läuft.
Nachtrag: mit den Treibern für Datev Kartenleser (miDentity) gibt es keine Probleme. Computer mit diesen Lesern (Stick oder Karte) haben keine Störungen.
Vielen Dank für die weiterführenden Infos.
Halte es trotzdem für sehr bedenklich, dass so eine Funktion die grundlegende RDP Verbindung lahmlegen kann.
das können auch z.B. drucker treiber
Bei mir tritt es nur beim Zugriff von W10 zu W11 auf.
W11 zu W11 ist soweit kein Problem.
https://www.borncity.com/blog/2024/10/28/windows-server-2022-update-kb5044281-zerschiesst-remotedesktop-dienste/#comment-200070
"Komischerweise scheinen RDP-Verbindungen zu Windows 11 24H2-Maschinen die Probleme nicht aufzuweisen. "
Das kann ich so nicht bestätigen, das Problem tritt bei mir beim Verbinden von W10 zu W11 24H2 auf.
Habe das Problem neu beim Zugriff auf W10 22H2, wobei Neustart es (vorerst) löste
Ich konnte mich nach dem Update nur noch mit MicrosoftAccount\mail@example.com einloggen und habe auch das Gefühl, dass die Verbindung, weil vermutlich über MS Server geroutet und nicht mehr rein im lokalen Netz dadurch merklich an Latenz gewonnen hat.
Ps. Wenn man Kommentare editiert, wird der Backslash entfernt. Zwischen MicrosoftAccount und mail gehört der.
Der Hinweis mit dem Microsoft-Account hat geholfen, danke.
Ich kann das Problem nur teilweise bestätigen. Ich arbeite selbst sehr viel mit RDP und auch bei Kunden sind viele Terminalserver im Einsatz.
Bisher hatte ich nur bei einem Kunden und dort nur bei einem Mitarbeiter das Problem, dass dieser sich nach kurzer Zeit nicht mehr an einem TS2025 anmelden konnte. Oben beschriebe Problematik war eingetreten. Hat man die Sitzung per Admin abgemeldet war die Verbindung wieder möglich.
Das Problem hat sich nach einigen Tagen, während wir noch nach der Ursache gesucht hatten, von selbst gelöst und ist seit dem nicht wieder aufgetreten.
Ich habe ein ähnliches Problem seit des Updates bemerkt: Wenn man bei laufender RDP-Session das Fenster minimiert, bleibt der Bildschirm manchmal schwarz wenn man es wieder in den Vordergrund holt. Abhilfe schafft dann nur Trennen und neu verbinden. Habe noch keine Regelmäßigkeit gefunden, nach der das Problem auftritt.
Wir hatten das Problem auch, hauptsächlich bei Verbindungen zu Clients mit 24H2. Seit dem Setzen der GPO für die Entfernung des Wallpapers ist das Problem weg.
Umgebungen mit schwachen/legacy Kerberos Einstellungen scheinen von dem Problem nicht betroffen zu sein.
Ich hatte das Problem auch, nach einer Minute Verbindung ist der RD eingefroren. Habe dann von UDP auf TCP umgestellt und seitdem läuft es wieder.
Können wir bestätigen für alle Verbindungen von Win10 zu Win11 24H2. Wir bitten nun die User statt mstsc die Remote App zu verwenden. mit der geht es stabil. Aber nicht alle Feature sind in der Remote App verfügbar.
Dieses Problem legt unseren Betrieb fast lahm und ich weiß nicht was ich tun kann. "Enforce Removal of Remote Desktop Wallpaper" hilft leider nicht.
Das einzige was wir im Moment machen können ist so oft neu RDP-Verbinden versuchen, bis es funktioniert. (Oft geht es nach dem 3ten Mal)
Bei mir scheint es geholfen zu haben diese GPO zu setzen, seit seit letzter Woche kam es nicht mehr vor.
Das ist meine Einstellung:
https://i.imgur.com/U9Kfi1m.png
Evtl. einmal mit rsop.msc prüfen ob die GPO wohl auch aktiv ist.
Hallo, habe hier in der Firma auch das Problem. Die Clients 24H2 laufen in der VM Hyper-V und nach dem 1-4 Versuchen funktioniert es. Der Zugriff erfolgt von W10 22H2 und W11 24H2. Ich habe nichts umgestellt , sehe aber die RDP Verbindung wurde mit TCP aufgebaut. Werde mich jetzt mal mit der GPO auseinander setzen. Im privaten Umfeld ohne Hyper-V Clients konnte ich es noch nicht feststellen. Gruß Horst
Hallo!
Hier bei mir besteht ebenfalls so ein Problem bei Nutzung div. Betriebssystemstände (Windows 10 und Windows 11) auf Client-Seite für Verbindungen auf Server 2019. Einige RDP-Verbindungen frieren in kurzen Abständen ein, und müssen dann getrennt und neu verbunden werden.
Das Symptom ist hier aber geringfügig anders als der Artikel beschreibt, wo erst gar keine Verbindungen aufgebaut werden können. Ich bin deshalb nicht sicher, ob es hierher gehört und dieselbe Ursache betrifft. Aber ich sehe fehlende Angaben zur Art der Herstellung der RDP-Verbindungen.
Bislang helfen bei mir für Zeitbereiche von wenigen Minuten Trennung/Wiederaufbau der Verbindung, für Zeitbereiche von wenigen Stunden die Neustarts der Remotedesktopdienste auf dem Server, bis zu wenige Tage Besserung schafft ein vollständiger Neustart des betreffenden Servers und bisher ohne Zeitbeschränkung die Deaktivierung von UDP für Remotedesktop auf den Clients.
Ich könnte mir vorstellen, dass auch im vorliegenden Fall die Verwendung des Protokolls einen Unterschied machen könnte, habe davon allenfalls am Rande gelesen.
Für die Deaktivierung des UDP-Protokolls für RDP Verbindungen muss in der Registry des Clients im Verzeichnis
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client
Der Eintrag
fClientDisableUDP als DWORD auf 1 gesetzt (ggfs. erstellt) werden.
Weiß hier zufällig jemand, ob die TCP-Verbindung wirklich Nachteile mit sich bringt? Lt. Microsoft ist schließlich die UDP-Verbindung besser. Darum habe ich ich mich bisher nur auf betroffene Geräte/Nutzer beschränkt und diese auf TCP umgestellt. Das Problem scheint sich aber eher auszuweiten (oder bei toleranteren Nutzern ist es bisher nicht aufgefallen, weil nach dem Neustart der Server das Problem sowieso erstmal behoben war).
Fraglich scheint mir, wie sinnvoll es ist, pauschal domänenweit die UDP-Verbindung für RDP zu deaktivieren.
Viele Grüße!
Auch ich habe Probleme. Habe einen W11 Rechner auf dem ich ein paar HyperV Maschinen habe.
Egal wie ich mich verbinde, bleibt immer der Loginbildschirm da.
Das tritt erst auf, seit ich im Januar ich glaube auf 24H2 aktualisiert habe.
Früher hatte ich nie Probelem mich zu verbinden. Ipad, Mac, verschiedene W10 und W11 Rechner haben immer ohne Probleme eine Verbindung aufgebaut.
Habe jetzt mal auf dem W11 Host die Gruppenrichtline eingerichtet. Mal sehen ob es was bringt.
Die folgende Einstellung hat das Problem bei mir gelöst:
Lokale Gruppenrichtlinien, dort "Computer Konfiguration > Administrative Vorgaben > Windows Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Netzwerkerkennung auf dem Server auswählen" Einschalten
Yep, das hilft bei mir. Tausend dank!
Die Anpassung von Marschall Daniel hat bei uns ebenfalls geholfen, auch wenn der Pfad minimal anders ist. Waren etwa 20 betroffene Clients.
"Computer Konfiguration > Administrative Vorgaben > Windows Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Verbindungen > Netzwerkerkennung auf dem Server auswählen"
bei uns konnte ich einen Kollegen mit dem Problem durch das Einschalten der "Netzwerkerkennung auf dem Server auswählen" auch helfen.
Vielleicht sollte man noch erwaehnen, dass das auf dem fernzusteuernden Rechner eingestellt werden muss.
Als Workaround vorher hat er eine Session mit einem anderen Admin User hergestellt und dann per Taskmanager seine eigentliche Usersession uebernommen…
Danke!
Uwe
Der Workaround scheint auch in meinem Fall funktioniert zu haben.
Das war schon verdammt ärgerlich, wenn der Remoteserver erst beim 4ten oder 5ten Mal dann doch endlich reagiert hat.
Ich verstehe nicht, weshalb gut funktionierende Dinge immer so verschlimmbessert werden.
Es geht um Sicherheit?? -> irgendwann ist alles so sicher, dass allenfalls noch professionelle Hacker an die Systeme heran kommen.
JMTC
Die GPO hat auch bei uns geholfen, herzlichen Dank für die Info.
Das Problem passiert bei uns auch nicht bei RDP auf Microsoft Server Es passiert nur bei RDP auf einen Win 11 24H2 Rechner immer dann, wenn man die Session nicht beendet und somit einen Reconnect startet. Dann kommt entweder nur ein blauer Bildschirm ohne Inhalt oder ein blauer Bildschirm mit "Other User" und hängt oder aber es funktioniert und der schon angemeldete User ist wieder verbunden. Dazu kommt in den Fällen, wo die RDP Session hängt, sieht man auch nur einen "Verbindungsbalken" oben in der RDP Leiste. Die Verbindungsqualität wird als schlecht bezeichnet. Diese Probleme treten auch bei Verwendung der Microsoft Remote App auf. Der einzige funktionierende Workaround ist bei uns: RDP starten –
Anmeldung durchführen – blauer Screen hängt. RDP so stehen lassen. RDP ein zweites mal starten und wieder anmelden. Der zweite Versuch nimmt dem ersten Versuch die Session weg, schafft es aber auf diese Weise die Windows Anmeldung sauber zu beenden und zeigt den Windows Desktop an. Leider keine wirklich gute Lösung. Ein Kollege hat heute berichtet, dass er nach Deinstallation von KB5051987 (11.2.2025) bei seinen Win 11 Maschinen den Fehler nicht mehr hatte (15 mal einen RDP Session Reconnect ohne Probleme). Ein anderer Kollege, der dann ebenfalls das KB5051987 deinstalliert hat, bekommt weiterhin den hängenden Startbildschirm……. Ich bin hier echt gespannt was die Lösung für dieses Problem ist…
Tatsächlich tritt bei mir das Problem von einem Win 10 22H2 zu einem Win 11 Pro 24H2 aber auch von einem Mac zu einem Win 11 Pro 24H2
Dabei kommt man irgendwann durch, wenn man die Verbindung immer wieder versucht herzustellen. Heute vom Mac aus ca. 20 mal. Dann ging es
Hier das gleiche Problem bei verschiedenen Win11 24H2 virtuellen Maschinen auf einem VM Ware ESXI.
Ich habe bereits 2 Maschinen komplett neu installiert, auch hier das gleiche Problem.
Bisher hilft nur, die Maschinen über VSphere neu zu starten.
Den Vorschlag für eine GPO um den Desktophintergrund zu entfernen werde ich testen.
Vielen, vielen Dank für den Blogpost.
Ich betreibe ein paar Windows-VMs auf einem Proxmox-Cluster, und verwende bisher eigentlich relativ erfolgreich das Verbinden über Freerdp.
Seitdem die Windows11 VMs auf 24H2 sind, funktioniert immer nur der erste Login. Alle weiteren werden in der Ereignisanzeige der "RemoteDesktopServices-SessionServices" mit "Fehler beim Ändern des Sitzungsmonitorlayouts durch das RDP-Anzeigesteuerungsmodul. Fehlercode: 0xFFFFFFFF." kommentiert. Ein verbinden "auf die VM" über SPICE tut dann ohne Probleme, aber eben nicht mehr per RDP – das hängt exakt an dem Punkt "Kreisel dreht sich nicht weiter".
Leider hilft das "Enforce Removal of Remote Desktop Wallpaper" nicht – aber immerhin gibt es hier weitere betroffene. Vielleicht gibt es ja bald(ig) einen Workaround.
nutze rdp von unterwegs von den unterschiedlichsten pcs (win10, win11, home, pro, in domäne usw.) zum zugriff über dyndns auf meinen rechner.
bei mir seit update auf 24H2 muß ich mich immer 2x über rdp anmelden, beim ersten mal wird zwar die anmeldung akzeptiert, danach hängt das fenster mit dem kreisel.
direkt danach das 2. mal angemeldet > butterweich.
Nach dem Update des RDP-Client für Mac und IOS ist auch bei uns bei einer erneuten
RDP Verbindung unter dem gleichen User der Startbildschirm eingefroren.
Der Vorschlag von Marschall Daniel vom 10. Februar 2025 hat auch bei uns das Problem gelöst:
Lokale Gruppenrichtlinien, dort "Computer Konfiguration > Administrative Vorgaben > Windows Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Netzwerkerkennung auf dem Server auswählen" Einschalten.
Bei uns war der Pfad allerdings etwas anders und identisch zu dem Pfad von Oliver T.
"Computer Konfiguration > Administrative Vorgaben > Windows Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Verbindungen > Netzwerkerkennung auf dem Server auswählen"
Dickes Danke an Marschal Daniel und Oliver T.
Und an Born!!
Moin ich habe das Problem auch, wenn ich mich von einem aktuellen W11 24h2 auf einen aktuellen Windows Server 2025 per RDP Verbinde.
3 Auffälligkeiten
– 1. die maximal Verfügbare Übertragungsgeschwindigkeit ist mit 10 MBit/s
Meine Lösung ist bisher Benutzer Abmelden Neu anmelde und es kann sich normal verbunden werden.
3. Das ganze Betrifft nur Physische Server. meine Virtuellen Maschinen sind nicht betroffen!
Sorry das ich es ist Spät an einem Samstag, ich ich hab das nur so hingeklatscht und fahr jetzt in mein Verdientes Wochenende. aber wenn jemand eine Lösung hat. ich wäre Dankbar:)
VG
Wir haben das selbe Problem, allerdings nicht auf jedem Gerät. Auf allen unseren Geräten mit W11 Pro tritt das Problem auf, auf den Geräten mit W11 Pro for WS nicht! Auffällig ist auch, dass sich das Design des Balkens oben am Bildschirm der beiden Versionen deutlich unterscheidet. Einmal ist es ein grauer, einmal ein blauer Balken.
Hallo zusammen,
bei uns tritt das Problem auch auf. Immer wenn eine Verbindung zu einem Win11 24H2 RDP-Host aufgebaut wird. Der Client scheint dabei egal. Ich habe mich von der Wallpaper-Einstellung ein wenig inspirieren lassen und in meiner RDP-Datei unter "Leistung" einfach auf "LAN" umgestellt. Voila, klappt wieder alles. Sofort beim 1. Anmeldeversuch. Inkl. Wallpaper. Mehrfach getestet und Einstellung wieder zurückgesetzt auf Auto. Auto hängt. Mehrfache Anmeldeversuche erforderlich. Mit "LAN" ist die Verbindung sofort wieder da. Die anderen (WAN usw.) habe ich nicht getestet.
Grüße aus dem Bergischen Land ;)
Bei mir das gleiche Problem: Auch Win11 24H2. Und hier hängt sich auch beim Versuch, über RemoteDesktop von anderen Win10-Clients im lokalen Netz auf den Win11-Client zuzugreifen, der Zugriff immer mit dem Logout-Hintergrundbildschirm auf – es werden 1-2 Punkte des Windows-Kreisels angezeigt, dann steht der Kreisel und nichts geht mehr.
Wenn ich das Remotefenster schließe und direkt danach einen zweiten Versuch starte, klappt es immer.
Ich habe es jetzt mal mit der o.g. Änderung in den lokalen Gruppenrichtlinien versucht – und bis jetzt funktionert es gleich beim ersten Versuch – aber wer kommt denn auf so was!?
Bei mir heißt es übrigens abweichend von der ersten Beschreibung und der darauffolgenden Pfadkorrektur nicht 'Administrative Vorgaben', sondern 'Administrative Vorlagen'… ;-)
André
Gleiches Problem mit Win11 Pro 24H2 -> Win11 Pro 24H2
Nach anpassen der Gruppenrichtline für Verbindungserkennung hat es sofort geklappt.
Hier gefunden:
https://www.hardwareluxx.de/community/threads/windows-11-24h2-rdp-schwarzer-bildschirm.1364426/
Hatte auch das Problem von W10 zu W11 24H2.
Bei mir hat es geholfen, im RemoteDesktop-Tool bei den Verbindungseinstellungen im letzten Reiter auf WLAN umzustellen und dort die Übertragung des Hintergrundbildes zu deaktivieren.