6
Win 10, 1903, 1909, RDP Sitzung bleibt schwarz und bricht ab - aus Domäne nehmen hilft, löst aber nicht das Problem
Hallo zusammen,
wir kämpfen bei uns mit ca 1000 Clients seit Win 10 1809 noch immer damit, dass mstsc-Sessions nur einen schwarzen Bildschirm zeigen und die Sitzung dann abbricht.
Versuche über GPO die WDDM Treiber zu erzwingen haben keinen Erfolg gebracht. 1903 und das Upgrade von 1903 auf 1909 helfen auch nicht weiter.
Ich habe dann einen PC aus der Domäne genommen und die GroupPolicy/Machine/registry.pol gelöscht. Nach dem Neustart klappte RDP von einem Domänen-PC auf diesen einwandfrei. oO
Nachdem ich ihn wieder in die Domäne aufgenommen und neu gestart habe, ist das Ergebnis wieder wie gewohnt, dass die Verbindung zwar hergestellt wird, der Bildschirm aber schwarz bleibt und die Session nach ca 30 Sekunden abgebrochen wird.
Ich weiß mir keinein Rat mehr dazu, aber vielleicht gibt es ja hier jemanden, der das Phänomen kennt?
wir kämpfen bei uns mit ca 1000 Clients seit Win 10 1809 noch immer damit, dass mstsc-Sessions nur einen schwarzen Bildschirm zeigen und die Sitzung dann abbricht.
Versuche über GPO die WDDM Treiber zu erzwingen haben keinen Erfolg gebracht. 1903 und das Upgrade von 1903 auf 1909 helfen auch nicht weiter.
Ich habe dann einen PC aus der Domäne genommen und die GroupPolicy/Machine/registry.pol gelöscht. Nach dem Neustart klappte RDP von einem Domänen-PC auf diesen einwandfrei. oO
Nachdem ich ihn wieder in die Domäne aufgenommen und neu gestart habe, ist das Ergebnis wieder wie gewohnt, dass die Verbindung zwar hergestellt wird, der Bildschirm aber schwarz bleibt und die Session nach ca 30 Sekunden abgebrochen wird.
Ich weiß mir keinein Rat mehr dazu, aber vielleicht gibt es ja hier jemanden, der das Phänomen kennt?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 518930
Url: https://administrator.de/contentid/518930
Ausgedruckt am: 19.11.2024 um 17:11 Uhr
6 Kommentare
Neuester Kommentar
Moin.
Wenn Du das Problem nach Domänenjoin bekommst, dann nimm doch bitte ein Testsystem und pack dies in eine Test-OU, auf der Du Vererbung von GPOs deaktivierst. Somit bekommt es keine GPOs - läuft es? Dann liegt es evtl. wirklich an den GPOs. Nun nimm die Hälfte der GPOs und verlinke sie auf diese Test-OU, mach ein gpupdate auf einem elevated command prompt und starte dann neu - Ist der Fehler noch immer nicht zu sehen, nimm die Hälfte der restlichen GPOs hinzu und so weiter, bis Du den Fehler siehst. Dann nimm von den zuletzt hinzugenommenen GPOs Stück für Stück welche weg, bist Du sagen kannst, welche GPO es ist.
Danach wird weiter geschaut, welche Einstellung innerhalb der GPO es ist - das Vorgehen kann ich dann erklären, wenn Du soweit bist.
Wenn Du das Problem nach Domänenjoin bekommst, dann nimm doch bitte ein Testsystem und pack dies in eine Test-OU, auf der Du Vererbung von GPOs deaktivierst. Somit bekommt es keine GPOs - läuft es? Dann liegt es evtl. wirklich an den GPOs. Nun nimm die Hälfte der GPOs und verlinke sie auf diese Test-OU, mach ein gpupdate auf einem elevated command prompt und starte dann neu - Ist der Fehler noch immer nicht zu sehen, nimm die Hälfte der restlichen GPOs hinzu und so weiter, bis Du den Fehler siehst. Dann nimm von den zuletzt hinzugenommenen GPOs Stück für Stück welche weg, bist Du sagen kannst, welche GPO es ist.
Danach wird weiter geschaut, welche Einstellung innerhalb der GPO es ist - das Vorgehen kann ich dann erklären, wenn Du soweit bist.
Moin. 
Stimmt, das mit der Test OU ist eine gute Idee, Danke für diesen Schubs in die Richtige Richtung!
Manchmal ist es wie an der Tafel zu stehen ...
Stimmt, das mit der Test OU ist eine gute Idee, Danke für diesen Schubs in die Richtige Richtung!
Manchmal ist es wie an der Tafel zu stehen ...
Schalte UDP auf den Clients ab, dann sollte der spuk vorbei sein.
Leider nein.
Habe sowohl auf dem Client als auch meinem Rechner den RegKey HKLM/Software/Policies/Microsoft/Windows NT/Terminal Services/Cleint/fClientDisableUDP erzeugt und auf 1 gesetzt, aber ohne Erfolg.
Die Verbidung benötigt weiterhin nach der Authentifizierung lange für den Aufbau, anschließend sehe ich nur schwarz und die Verbindung bricht nach einigen Sekunden wieder ab.
Mein Problem ist gerade: wie verhindere ich die Übernahme der ca. 30 GPOs, die auf die Domäne direkt wirken ohne jede ber Ausnahmegruppe anfassen zu müssen. Global dürfte da aber wohl nichts gehen ...
Habe sowohl auf dem Client als auch meinem Rechner den RegKey HKLM/Software/Policies/Microsoft/Windows NT/Terminal Services/Cleint/fClientDisableUDP erzeugt und auf 1 gesetzt, aber ohne Erfolg.
Die Verbidung benötigt weiterhin nach der Authentifizierung lange für den Aufbau, anschließend sehe ich nur schwarz und die Verbindung bricht nach einigen Sekunden wieder ab.
Mein Problem ist gerade: wie verhindere ich die Übernahme der ca. 30 GPOs, die auf die Domäne direkt wirken ohne jede ber Ausnahmegruppe anfassen zu müssen. Global dürfte da aber wohl nichts gehen ...
Nochmal zurück zu
Versuche über GPO die WDDM Treiber zu erzwingen haben keinen Erfolg gebracht
Hast Du zugesehen, dass die GPO nicht nur übernommen wurde, sondern auch der Ziel-PC danach neu gestartet wurde? Ist nötig.
Na klar habe ich das.
Sorry für die späte Antwort, bin lange krank gewesen und dann die Feiertage, daher keine Reaktion.
Was am Ende bei allen beteiligten PCs geholfen hat ist die lokale Registry.pol unter system32/GroupPolicy/Machine zu löschen und das System neu in die Domäne aufzunehmen.
Danke für Deine Unterstützung in jedem Fall.
Sorry für die späte Antwort, bin lange krank gewesen und dann die Feiertage, daher keine Reaktion.
Was am Ende bei allen beteiligten PCs geholfen hat ist die lokale Registry.pol unter system32/GroupPolicy/Machine zu löschen und das System neu in die Domäne aufzunehmen.
Danke für Deine Unterstützung in jedem Fall.
