Kurioses RDP-Verhalten in Domäne

doskias
Goto Top
Hallo zusammen,

ich bin auf recht merkwürdiges (fast schon lustiges) verhalten in Windows 10 gestoßen. Ich kann das verhalten reproduzieren, aber nicht lösen. Vielleicht ist einem von euch das auch schon einmal aufgefallen. Ich kann das verhalten an etwa 3/4 der Rechner nachvollziehen, seitdem es vor ca. 3 Monaten zum ersten mal aufgefallen.

Vorweg: Ich installiere grade einige spezielle Rechner, für die es kein Image gibt. ich installiere diese nativ von einer Windows 10 CD (Updateversion 2004, 20H1). Genutzt wird ausschließlich Windows 10 Pro.

Schritt 1
Direkt nach der Installation bekommt der Rechner einen zuordbaren Namen, RDP wird aktiviert und er wird in der Domäne aufgenommen. Der Rechner wird neu gestartet und befindet sich zu diesem Zeitpunkt in der allgemeinen Computers-OU auf die keine GPO greift. RDP Zugriff ist möglich.

Schritt 2
Ich fahre den Rechner runter, schiebe ihn auf dem DC in die entsprechende OU und starte ihn. Hier werden jetzt GPOs angewandt, allerdings keine die RDP-Zugriff beeinflussen, dennoch kann ich nicht per RDP auf den Rechner zugreifen. Wenn ich jedoch lokal angemeldet bin, werde ich dort abgemeldet. meine RDP Verbindung am Client zeigt jedoch kein Bild, sondern bleibt schwarz. Nach ca. 90 Sekunden bekomme ich eine Fehlermeldung. Die Verbindung wird (laut Windows-Protokollen) hergestellt. Die Fehlermeldung besagt, dass der Administrator die RDP-Verbindung nicht erlaubt.

Schritt 3
Ich schiebe den Rechner wieder in die Computers-OU und starte ihn neu. Anschließend geht RDP wieder. Ergebnis von GPResult ist identisch mit dem aus Schritt 1.

Schritt 4
Ich schiebe den Rechner zurück in die OU aus Schritt 2. RDP geht nicht. Es folgt das gleiche Verhalten wie in Schritt 2.

Schritt 5
Ich führe ein gpupdate /force aus. Jetzt geht RDP, wobei GPResult für Schritt 2,3 und 5 identische Werte Ausgaben erzeugt.

Kurios ist jetzt:
1. Wenn ich den Rechner in die entsprechende OU verschoben habe, muss ich derzeit immer ein GPUPDATE ausführen, damit die RDP Verbindung funktioniert.
2. Wenn ich den Rechner in der OU lasse, dauert es teilweise bis zu 2 Tagen bis die RDP-Verbindung aufgebaut werden kann. Das Aktualisierungsintervall der GPO ist bei den üblichen 90 Minuten zzgl. Versatz. Eine automatische Aktualisierung der GPO löst dieses Verhalten also nicht auf
3. Wenn RDP einmal nach dem GPUPDATE funktioniert, kann ich den Rechner auch wieder in jede andere OU verschieben und dort belassen bzw. GPUPDATEs durchführen. DIE RDP Verbindung bleibt erhalten, auch beim zurück kopieren in die hier genutzte OU.

Die RDP Einstellungen, die in dieser OU greifen sehen wie folgt aus:
rdp

Keine dieser Einstellungen dürfte eine Auswirkung auf die Herstellung der Verbindung habe, und wie gesagt: Wenn es dann mal geht, dann geht es dauerhaft. Wenn eine dieser Einstellungen RDP verhindern würde, dann dürfte RDP auch auf den Rechnern nicht gehen, die seit Monaten in der OU sind. Es geht aber, lediglich am Anfang zickt er rum. Aufgetreten ist das Phänomen zuerst im Februar. Es spielt auch keine Rolle ob ich den Rechner im Installationsstand von 2004 lasse oder auf 21H1 komplett durchpatche. Das Verhalten bleibt identisch.

Ich hab zwar eine Lösung für das Problem, aber ich würde die Ursache dennoch gerne verstehen. Vielleicht hat ja jemand eine ähnliche Kuriosität beobachtet und/oder kann mir einen Tipp geben. Baugleiche Rechner die letztes Jahr installiert wurden und zur gleichen OU gehören, haben dieses Verhalten nicht gezeigt.

Achso, bevor die Frage aufkommt:
ich habe schon einmal testweise eine GPO erstellt, die RDP-Verbindung auf dem Rechner zulässt, indem ich den Wert Remoteverbindung für Benutzer mithilfe der Remotedesktopdienste zulassen aktiviert habe. Das Verhalten war identisch mit dem hier beschriebenen.

Gruß
Doskias

Content-Key: 667288

Url: https://administrator.de/contentid/667288

Ausgedruckt am: 16.08.2022 um 14:08 Uhr

Mitglied: dertowa
dertowa 03.06.2021 um 15:29:36 Uhr
Goto Top
Hey, mal ganz frei raus ohne das Verhalten jemals erlebt zu haben.
Schnellstart von Windows mal deaktiviert, oder aber statt des Herunterfahren mal mit einem Neustart gearbeitet?
Mitglied: Doskias
Doskias 03.06.2021 um 15:48:43 Uhr
Goto Top
Schnellstart von Windows mal deaktiviert,
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

oder aber statt des Herunterfahren mal mit einem Neustart gearbeitet?
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.
Mitglied: Visucius
Visucius 03.06.2021 aktualisiert um 16:29:43 Uhr
Goto Top
Ernsthaft? Win10Pro von ner DVD aus 2004?!

Wer soll sowas denn "nachvollziehen" können?! Normale Menschen machen sowas über nen aktuellen USB-Stick - alleine schon wegen der sonst anstehenden Update-Orgie? Wer installiert denn freiwillig ein 6 Jahre altes Windows und wundert sich dann über Inkompatibilitäten?!

https://www.microsoft.com/en-in/software-download/windows10ISO

Viele Grüße
Mitglied: erikro
erikro 03.06.2021 um 16:39:11 Uhr
Goto Top
Moin,

Zitat von @Visucius:

Ernsthaft? Win10Pro von ner DVD aus 2004?!

Nanana, Windows 10 aus 2004 geht nur im Kino (Zurück in die Zukunft). face-wink Stand 2004 stammt aus dem Mai 2020 und war bis vor Kurzem die aktuelle Version. face-wink

Liebe Grüße

Erik
Mitglied: Visucius
Visucius 03.06.2021 aktualisiert um 16:59:37 Uhr
Goto Top
Zitat von @erikro:

Nanana, Windows 10 aus 2004 geht nur im Kino (Zurück in die Zukunft). face-wink Stand 2004 stammt aus dem Mai 2020 und war bis vor Kurzem die aktuelle Version. face-wink


Oh mein Gott. Asche auf mein - ach was, ich spring gleich rein face-wink

PS: und dann noch "6 Jahre alt" ... hüstl, hüstl wer lesen und rechnen kann ist klar im Vorteil face-wink
Mitglied: Doskias
Doskias 03.06.2021 um 16:54:25 Uhr
Goto Top
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 face-big-smile
Mitglied: Visucius
Visucius 03.06.2021 um 16:59:58 Uhr
Goto Top
... keine Sorge, mich gibts hier nur einmal face-wink
Mitglied: Doskias
Doskias 07.06.2021 um 16:52:22 Uhr
Goto Top
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 face-wink

Gruß
Doskias
Mitglied: dertowa
dertowa 08.06.2021 um 09:41:55 Uhr
Goto Top
Zitat von @Doskias:
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.

Dann solltest du das Ding hier schließen und einen passenden Thread dazu eröffnen.

Aber nur mal so, Inplaceupgrade schon mal probiert?
Mitglied: Doskias
Doskias 08.06.2021 um 11:01:23 Uhr
Goto Top
Moin
Zitat von @dertowa:
Zitat von @Doskias:
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.
Dann solltest du das Ding hier schließen und einen passenden Thread dazu eröffnen.
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:
Aber nur mal so, Inplaceupgrade schon mal probiert?
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
Mitglied: dertowa
dertowa 14.06.2021 um 15:51:25 Uhr
Goto Top
Zitat von @Doskias:
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.

Vorher ein Image ziehen, testen und im Zweifel das Image wieder einspielen, so lang sich an der Hardware nichts ändert darf da nichts passieren.
Mitglied: Doskias
Doskias 14.06.2021 um 15:58:17 Uhr
Goto Top
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.
Mitglied: Doskias
Doskias 05.07.2021 um 09:10:00 Uhr
Goto Top
So, was lange wärt, wärt endlich gut. Aber das hier dauert ja noch nicht so lange und ist daher auch nicht gut:
Zitat von @Doskias:
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.

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
Mitglied: Doskias
Doskias 20.07.2021 um 13:56:08 Uhr
Goto Top
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
Mitglied: dertowa
Lösung dertowa 21.07.2021 um 18:28:09 Uhr
Goto Top
Sorry, aber dieses ganze Hin und Hergeschubse vom PC deutet doch nach wie vor auf GPOs die greifen/nicht greifen und ein Verhalten verursachen.
Dafür müsste man jetzt mal die Domain und ihre GPOs zerlegen oder aber einfach mal neue OUs anlegen und mit einem frischen PC dort testen.

Noch was, sollte aber klar sein:
Das Computerkonto muss auf allen Benutzer-GPOs ebenso Lesezugriffe haben, ansonsten bekommst du da auch ein Problem.
Mitglied: Doskias
Doskias 22.07.2021 um 08:19:08 Uhr
Goto Top
Zitat von @dertowa:
Sorry, aber dieses ganze Hin und Hergeschubse vom PC deutet doch nach wie vor auf GPOs die greifen/nicht greifen und ein Verhalten verursachen.
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 face-smile. Wird mir wohl nur weiterhin Try-and-Error bleiben.

Dafür müsste man jetzt mal die Domain und ihre GPOs zerlegen oder aber einfach mal neue OUs anlegen und mit einem frischen PC dort testen.
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.

Noch was, sollte aber klar sein:
Das Computerkonto muss auf allen Benutzer-GPOs ebenso Lesezugriffe haben, ansonsten bekommst du da auch ein Problem.
Das ist klar und habe ich nach deinem Posting direkt noch einmal geprüft. Das Computerkonto kann auf alle Benutzer-GPOs zugreifen.

Gruß
Doskias
Mitglied: dertowa
dertowa 22.07.2021 um 10:53:06 Uhr
Goto Top
Zitat von @Doskias:

Siehste, manchmal kommt man auch gar nicht auf die einfachsten Ideen.

Das ist so ein Wald und Bäume Ding, zumindest so lang da noch kein Borkenkäfer aktiv ist. ;)
Mitglied: Doskias
Lösung Doskias 08.09.2021 um 16:40:47 Uhr
Goto Top
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:
Installation von Geräten verhindern, die nicht in anderen Richtlinien beschrieben sind Aktiviert
Installation von Geräten mit Treibern zulassen, die diesen Gerätesetupklassen entsprechen (es folgen einige GUIDs)

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:
Administratoren das Außerkraftsetzen der Richtlinien unter "Einschränkungen bei der Geräteinstallation" erlauben Aktiviert
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 face-wink 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
Mitglied: dertowa
dertowa 08.09.2021 um 21:06:05 Uhr
Goto Top
Salut,
na das klingt doch nach einer Zielgeraden.
All zu viel gibt es da ja nicht was "installiert" wird, kommt aber auch wieder darauf an welche Einstellungen in der RDP-Verbindung gemacht wurden.
Ich würde erstmal unter Lokale Geräte und Ressourcen alles unnötige deaktivieren, Drucker und Zwischenablage ebenso.
Mitglied: Doskias
Doskias 10.09.2021 um 12:00:32 Uhr
Goto Top
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.
Mitglied: Doskias
Lösung Doskias 21.09.2021 um 15:33:28 Uhr
Goto Top
Letzter Eintrag von mir mit einem Dank für die Geduld. Das Problem ist jetzt endgültig gelöst und die Ursache analysiert. Es lag/liegt tatsächlich, wie ich im vorherigen Posting vermutet habe, an der GUID {4d36e968-e325-11ce-bfc1-08002be10318}. Nachdem die Installation dieser GUID zugelassen wurde, funktioniert es wieder fehlerfrei.