Kurioses RDP-Verhalten in Domäne

Schnellstart ist per GPO deaktiviert auf den Clients, sofern sie in einer OU sind, die nicht der Computers-OU entspricht. Bedeutet: Bei aktivirtem Schnellstart geht es, bei deaktiviertem dann nicht

Ja auch schon versucht. Spielt keine Rolle ob ich Neustart durchführe oder aus und wieder einschalte. Aus- und wieder einschalten habe ich nur explizit getestet, da der Computer dann definitiv aus ist, wenn ich die OU Wechsel um gezielter die GPO-Übernahme bei Systemstart prüfen zu können.

Ich hab es mal auf Updateversion 2004 / 20H1 geändert. Denke/Hoffe so ist es klarer. Das kann ja aber künftig nicht mehr vorkommen, da MS jetzt die Updatebezeichnung geändert hat. Doch nicht alles schlecht was die Redmonter ändern

So... nach gefühlt 4 Tagen Analyse bin ich jetzt schlauer. Hier mal die Fakten

• qwinsta Zeigt mir an, dass kein RDP-Listener vorhanden ist.
• der Dienst UmRdpService nicht läuft. Beim Starten wird der Dienst sofort wieder beendet. Es wird nichts protokolliert, weder in den Windows-Protokollen, noch in den Anwendungs- und Dienstprotokollen.
• Dism hat keinen Fehler zum beheben gefunden
• Die Datei %windir%\system32\umrdp.dll ist vorhanden und hat den gleiche Hashwert wie auf den Rechnern wo es funktioniert
• Es ist der einzige von 70 Rechnern in der GPO der dieses Problem hat
• Der Registry-Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp eines Funktionierenden Rechners ist identisch mit dem Problem-PC
• Das RDP-Zertifikat des Computerkontos wird nach dem Löschen automatisch erstellt und sollte damit korrekt sein
• Es liegt nicht an der Firewall, die spielt keine Rolle. Egal ob aus oder an, die Situation ändert sich nicht
• Es gibt keinen weiteren Dienst der auf dem gleichen Port lauscht. Das ändern des RDP-Portes führt ebenfalls nicht zu einer Änderung der Situation

Oder um es anders zu sagen: Alle was Microsoft vorschlägt habe ich geprüft. Mir ist durchaus bewusst, dass das Problem der nicht laufende Dienst ist, der dazu führt, dass kein Listener vorhanden ist. Das Fehlverhalten im RDP lässt sich gut reproduzieren indem ich den Dienst auf einem funktionierenden Client stoppe. Allerdings kommt bei den anderen Clients der Dienst nach einem Neustart wieder. Das ist hier nicht der Fall.

Eine Neuinstallation des Arbeitsplatzes möchte ich gerne vermeiden, da hier mehrere Dongle dran hängen, von denen zwei durch Post-Ident-Verfahren des Finanzamtes nach einer Neuinstallation neu mit der Software verbunden werden müssen. RDP an sich hat (laut den Protokollen an meinem PC) zu diesem Rechner schon einmal funktioniert. Wiederherstellung des Clients aus dem Backup auf ein Gerät baugleicher Hardware hat gezeigt, dass der Dienst selbst im ältesten Backup nicht gestartet wird. Die Option fällt also auch weg.

Was uns zu folgender Frage führt: Wer hat noch eine Idee wie ich diesen Dienst zum Laufen kriege bzw. wo ich noch nachschauen kann warum der Dienst nicht startet. Irgendwas muss ja zu der Deaktivierung des Dienstes geführt haben, was folglich auch Rückgängig zu machen ist.

Meine erste Analyse, dass es an der entsprechenden OU-Zugehörigkeit liegt musste ich derweil verwerfen. Ein Verschieben in die OU aus dem Eröffnungspost aus Schritt 1 und Schritt 3 hat in diesem Fall die Funktion des RDP nicht wieder hergestellt.

Bin für jeden, noch so abwegigen Vorschlag, dankbar. Vielleicht bringt mich der ja auf den richtigen Weg oder auf die Richtige Idee.

Danke an alle, die sich die Zeit nehmen meine Romane zu lesen, aber ich versuche möglichst detailgenau keine Informationen wegzulassen

Gruß
Doskias

Moin
Das sehe ich (noch) nicht so. Zum einen existiert das kuriose Verhalten weiterhin. Es ist weiterhin so, dass bei den anderen, vor allem neu aufgesetzten, Rechner RDP erst nach dem hin und her funktioniert. Ich sehe hier ein klaren Zusammenhang und der Titel stimmt weiterhin. Nur weil sich während des Problems neue Erkenntnisse bilden, muss man nicht ein neues Thema aufmachen. Und wenn es keinen Zusammenhang zwischen dem ersten Post und dem gestrigen besteht, dann bleibt das Ursprungsproblem immer noch ungelöst.

Aber zurück zum Problem:
Nein habe ich noch nicht, da ich mir noch nicht 100% sicher bin, dass die Dongle hinterher noch funktionieren. Ich weiß, dass es daran nichts ändern sollte, aber auf ein sollte kann ich mich in diesem Fall nicht verlassen. Die Option habe ich schon im Hinterkopf, allerdings löst das ja nicht de Ursache. Wenn ich die Ursache nicht kenne und das Problem bei anderen Rechnern auftritt ist ein Inplace-Upgrade auf Dauer keine Lösung.

Als nächstes werde ich mir die Einstellungen von gpedit.msc mal ganz genau ansehen. Dazu muss ich allerdings warten bis der Kollege den Rechner nicht braucht und ich da bin. Vermutlich also diese Woche nicht mehr.

Gruß
Doskias

Ich tendiere grade dazu die Lösung eher umzudrehen und erstmal ein Restore auf einem baugleichen gerät (oder VM) durchzuführen um zu prüfen ob die RDP-Dienste dann immer noch nicht gehen. Da gehe ich eigentlich von aus und dann werde ich auf dem Restore das Inplace-Upgrade machen um erstmal zu testen ob das den Fehler auch behebt.

So, was lange wärt, wärt endlich gut. Aber das hier dauert ja noch nicht so lange und ist daher auch nicht gut:

Ich muss an der Stelle mein verwerfen widerrufen. Bei besagtem Rechner, der aus dem Muster fiel lag/liegt das Problem an einer anderen Stelle begründet.

Ich hab derweil gezielt mehrere Rechner neu Installiert um diese Kuriosität zu analysieren (und ich werde da absolut nicht schlau draus). Bei allen Rechner, die ich neu in die Domäne genommen habe war das im Eröffnungspost beschriebene Verfahren notwendig um RDP nutzen zu können. Ich habe daher gezielt am vergangenen Freitag einige Rechner neu installiert und eine entsprechende Teststellung am Wochenende laufen lassen.

Teststellung 1: Rechner wie oben beschrieben als Kontroll-PC installiert. Verhalten am Freitag noch wie hier geschrieben mit entsprechenden Schritten für RDP-Verbindung

Teststellung 2: Rechner installiert und in die OU verschoben. RDP war nicht möglich. Von Freitag bis heute stündlich den Rechner neu gestartet und per Skript versucht eine RDP-Verbindung aufzubauen. Bis heute morgen 07:00 Uhr nicht möglich. Anschließend die Schritte wie oben beschrieben durchgeführt, dann RDP-Verbindung möglich.

Teststellung 3: Rechner installiert und übers WE aktuelle Updates von MS (nicht unserem WSUS) installieren lassen. Heute morgen dann getestet. Schritte 1 bis 5 waren weiterhin notwendig.

Teststellung 4: Rechner installiert. In Ursprungs OU angemeldet, im laufenden Betrieb in die OU verschoben, neugestartet, Keine RDP möglich.

Teststellung 5: Rechner installiert. In Ursprungs OU angemeldet, im laufenden Betrieb in die OU verschoben, gpupdate /force durchgeführt. RDP sofort möglich.

Fazit: Obwohl laut GPO-Result die Gruppenrichtlinien bei der Anmeldung und beim Start des Gerätes korrekt von allen DCs (Synchronisation geprüft) stattfindet, funktioniert die RDP-Verbidnung nur dann, wenn ich den Rechner während des Betriebes in die entsprechende OU verschiebe und händisch ein GPUpdate durchführe.
Ich hab es auch nochmal erneut geprüft. Die einzigen Einstellungen die sich auf die GPO auswirken, sind die sieben aus dem Eröffnungsposting. An denen kann es aber meiner Einschätzung nach auch gar nicht liegen, denn wenn es dann einmal geht, dann geht es auch dauerhaft.
Die Probleme treten sdowohl in 20H1, 20H2 und 21H1 auf.

Zu dem einen Rechner bei dem es auch nach diesen Schritten nicht funktioniert noch einmal ausführlicher: Der eine Rechner hat das Problem, dass der Listener-Dienst nicht läuft und dadurch kein Port geöffnet wird, wie qwinsta deutlich zeigt. Auf den anderen Rechner, auch die aus dem Test, zeigt qwinsta eine laufenden Listener an. Es kann dann auch stets eine Verbindung aufgebaut werden, allerdings bleibt das Bild schwarz. Daher kann man den Rechner nicht zu dieser Problematik dazu zählen.

So viel erstmal dazu. Über Tipps bin ich weiterhin dankbar.

Gruß
Doskias

Ich weiß nicht, wer hier überhaupt noch mitliest, aber es gibt Neuigkeiten bzgl. des kuriosem Verhalten.

Auf einem Rechner, der seit mehreren Monaten problemlos läuft, soll sich jetzt ein User remote Anmelden. Kein schweres Ding, also den User in den RDP-Berechtigten Usern eingetragen, Rechner neu gestartet (eigentlich nicht erforderlich) und versucht. Folgende Auffälligkeit:

1. Anmeldung am Rechener (OU: PC-Gruppe) via Administrator ging
2. Anmeldung am Rechner via normaler User führt dazu, dass der Admin seine Verbindung verliert (soweit ok), anschließend jedoch nur schwarzes Bild, gefolgt von einem (offensichtlichen Timeout.
3 Anmeldung als Administrator erfolgt ohne Probleme.

Meine Vermutung: Müsste dann ja am User liegen. Überprüfung:

1. Rechner aus PC-Gruppe in Standard-Computer Gruppe verschoben und PC neu gestartet
2. Admin Anmeldung OK
3. User Anmeldung nicht OK
4. GPUPDATE durchgeführt
5. User Anmeldung auf Einmal ok

Fazit: In der Berechtigungsgruppe ohne jegliche GPOs funktioniert alles nachdem ich händisch ein GPUpdate durchgeführt habe.
Also weiter getestet und PC wieder in die PC OU geschubst

1. Rechner neu gestartet
2. Admin Anmeldung OK
3. User Anmeldung nicht ok

Fazit: Muss ja wohl doch eine Computereinstellung sein, die per GPO geregelt wird. Also nochmal experimentiert:

1. Rechner aus PC-Gruppe in Standard-Computer Gruppe verschoben und PC neu gestartet
2. Admin Anmeldung OK
3. User Anmeldung nicht OK
4. GPUPDATE durchgeführt
5. User Anmeldung ok
6. PC in PC-OU
7. GPupdate durchgeführt
8. Rechner neu gestartet
9 User Anmeldung OK

Sprich:
Wenn ich den Rechner in die OU schiebe in der er sein sollte, während ich per RDP mit dem User dort angemeldet bin und dann ein gpupdate durchführe, dann funktioniert die RDP-Verbindung. Ich habe es auch per VNC-Verbindung ohne RDP versucht, da hat die RDP-Verbindung nicht funktioniert.

Wenn ich den Rechner verschiebe während der Administrator angemeldet ist dann funktioniert die RDP Verbindung nur für den Administrator, nicht für den User.
Wenn ich den Rechner verschiebe während er aus ist, funktioniert RDP weiterhin nur für den Administrator.

Das ganze verhalten ergibt für mich keinen Sinn, konnte ich jetzt aber mehrfach gezielt konstruieren (bis auf die Tatsache, dass ich nicht weiß warum es nicht funktioniert. Das hin und her verschieben des PC in den beiden OUs mit einem händischen GPupdate funktioniert.
Meiner Einschätzung nach:
- kann es nicht an Benutzerrechten liegen, denn ich habe nur den Rechner in den OUs bewegt. Den Benutzer habe ich nicht angefasst. Es gibt kein Loopbackverarbeitung. Computer- und Benutzer-Rechte sind in den GPOs strickt getrennt und den Benutzern und Computer OUs zugeordnet.
- kann es nicht an den Gruppenrichtlinien des PCs liegen, denn das GPResult vor und nach dem händischen GPUpdate sind identisch. Auch die GPResult vom händischen und dem beim hochfahren abgerufenen Gruppenrichtlinien sind identisch.
- kann es ebenfalls nicht an den GPOs liegen, denn wenn es einmal funktioniert, dann funktioniert dauerhaft. Selbst nach fünf Tagen, dutzenden Neustarts und zahlreichen händischen gpupdates funktioniert die RDP auch beim User weiterhin.
- kann es kein Verbindungsproblem oder ähnliches sein, denn der Administrator kann darauf zugriefen, der normale User aber nicht. Die Funktion an sich ist ja offenbar gegeben und funktioniert. Es muss demnach irgendwie am User liegen.

In meinen Augen macht das ganze keinen Sinn und dennoch ist es nach mehrmaliger Prüfung so, wie ich es hier beschrieben habe. Wenn es als Administrator geht, als User aber nicht, dann muss es ein Fehler bei der Userberechtigung sein. Wenn es aber ein Fehler in der User-Berechtigung ist, dann dürfte es sich durch ein verschieben des Computer in den OUs (Alle Computer-GPOs werden für authentifizierte Benutzer ausgeführt) keine Änderung erwirken. Wenn Änderung der OU des Computers eine Änderung bewirkt, so muss das Problem an den Computereinstellungen liegen und kann nicht User-bezogen sein. Wenn das Problem aber an den Computereinstellungen liegt, dann sollte es sowohl für den User/Admin zeitgleich funktionieren oder fehlschlagen. Das ist aber nicht der Fall, da es nur bei einem User nicht funktioniert. Also muss es ein Fehler in den user-Berechtigungen sein, womit sich der Teufelskreis schließt.

Sorry für die Wall-of-Text aber ich denke das war auch das letzte mal. Vielleicht hat noch jemand eine Idee. Ich bin an der Stelle mittlerweile völlig ratlos, was die Ursache betrifft. Ich weiß wie ich das Problem lösen kann. Ich weiß nicht in welchen Protokollen oder Einstellungen ich noch suchen kann um eine fehlerhafte Einstellung zu finden. Das erste mal ist das Problem an meinem Test-Rechner vor 5 Monaten aufgetreten und nachdem ich es auf hier beschrieben Weise gelöst habe, funktioniert es seitdem.

Danke das ihr euch die Zeit genommen habt, meine Walls zu lesen. Sollte ich noch eine Lösung/Ursache finden, werde ich sie hier bekannt geben.

Gruß
Doskias

Bin ich völlig bei dir. Das habe ich ja auch nie wirklich abstreiten wollen (und glaube es auch nicht getan zu haben). So wie ich es sehe muss es ja auch an einer GPO liegen, die in der OU liegt, allerdings finde ich bei Betrachtung der GPO nichts was irgendeinen Einfluss auf die RDP-Verbindung hat (außer die oben gezeigte Druckerumleitung). Merkwürdig bleibt dennoch: Wenn es geht, dann geht es dauerhaft. Was eigentlich ja eher zeigt, dass es keine GPO ist die ein Verhalten des RDP steuert, sondern viel mehr muss irgendwas bei OU Wechsel eine Einstellung verändern, die nicht automatisch korrigiert werden kann. Ich hätte nur gerne eine neue Log-Option kennen gelernt um das gezielt zu prüfen . Wird mir wohl nur weiterhin Try-and-Error bleiben.

Siehste, manchmal kommt man auch gar nicht auf die einfachsten Ideen. Auf die Idee es einfach mal mit einer anderen, neu angelegten leeren GPO zu probieren und dann nach und nach die vorhandenen GPOs dort zu verknüpfen bin ich bislang nicht gekommen. Probiere ich dann nach meinem Urlaub mal aus und teile das Ergebnis mit.

Das ist klar und habe ich nach deinem Posting direkt noch einmal geprüft. Das Computerkonto kann auf alle Benutzer-GPOs zugreifen.

Gruß
Doskias

Nach laaaaaaaaaaaaaaaanger Zeit mal wieder ein Statusupgrade zu diesem Problem. Ich stell schonmal den Sekt kalt, geöffnet wird der erst später, vermutlich am Freitag, wenn ich wieder zum Test komme.

Es liegt tatsächlich an einer GPO, allerdings an einer, die ich bei weitem nicht dafür verantwortlich gemacht habe, da es eine GPO ist, die nichts mit den RDP-Einstellungen zu tun hat.

Heute habe ich (das erste mal sichtbar), ein kleines Popup bekommen mit dem Inhalt, dass eine Richtlinie die Treiberinstallation verhindert hat.

Wir haben nämlich bei uns folgende GPO aktiv:
Computer -> adm. Vorlagen -> System -> Geräteinstallation -> Einschränkungen:

Deaktiviere ich die GPO für den Zielrechner, also auf den ich mich verbinden möchte, funktioniert es. Aktiviere ich sie, funktioniert es anschließend auch noch. Das ganze Verhalten ist dadurch erklärbar. Als Admin greift die GPO nicht, denn:
Daher klappt die Anmeldung als Administrator. Schieb ich den PC aus der GPO heraus, dann greift die Richtlinie nicht. Die Verbindung funktioniert, die Treiber werden installiert. Schieb ich den User in die GPO zurück, dann funktioniert es, weil die Treiber ja schon da sind.

Ich muss jetzt nur noch rausfinden welches Gerät an der Stelle das Verhalten auslöst, die Gerätesetupklasse oder Gerät-ID ermitteln, diese für die Installation freigeben und dann wird der Sekt geöffnet Leider halten sich die Protokolle da sehr bedeckt was die Installation angeht. Weder die "normalen" Windows-Protokolle noch die Dienst- und Anwendungsprotokolle haben bislang rausgerückt welches Gerät die Meldung verursacht hat. Lediglich die Mitteilung, dass die Installation eines Gerätes verhindert wurde, wird dort angezeigt.

Gruß
Doskias

So. Nach langen langem Test müsste der Fehler an der GUID {4d36e968-e325-11ce-bfc1-08002be10318} liegen. Das ist der Treiber für Microsoft remote Display Adapter. Der erste Test war erfolgreich. Nächste Woche wird ein Blank installierter Rechner getestet um auf Nummer sicher zu gehen.