menne
Goto Top

Remoteunterstützung - Fenster zur Zugriffsbestätigung kommt nicht auf Client

Client kann Remoteunterstützungsangebot nicht annehmen und den Zugriff somit nicht erlauben, da kein Abfragefenster kommt. Der Client kann aber selbst Remoteunterstützung anbieten. Ereignisprotokolleintrag: Fehler TermDD ID:50; "Die RDP-Protokollkomponente X.224 hat einen Fehler im Protokollablauf festgestellt und die Clientverbindung getrennt."

Hallo liebe Mitglieder,

bin bis jetzt immer in Foren fündig geworden, aber diesmal steh ich wirklich vor einem Rätsel:

Windows Server 2003 R2 SP1 wird als DC mit Gruppenrichtlinien für die Domänenbenutzer konfiguriert, um automatisch die Remotedesktopunterstützung auf den Clients zur Verfügung zu stellen. Konfiguration ist entsprechend http://www.gruppenrichtlinien.de/index.html?/HowTo/Remoteunterstuetzung ... vorgenommen und die Ports 3389/135 via telnet vom Server (der Testweise als Adminrechner dient) zum Client auch erreichbar. Wenn ich vom Server nun entweder unaufgefordert Remotenunterstützung anbieten will oder auch vom Client eine Einladung öffne, geht auf dem Server das Fenster auf mit Status: "Auf Antwort wird gewartet" - auf dem Client tut sich aber nichts. Das Fenster zur Bestätigung der Verbindung kommt nicht. Statt dessen Anwendungsfehleinträge, Fehler: Quelle - TermDD, ID:50

"Ereignistyp: Fehler
Ereignisquelle: TermDD
Ereigniskategorie: Keine
Ereigniskennung: 50
Datum: 03.11.2006
Zeit: 14:29:17
Benutzer: Nicht zutreffend
Computer: TEMP
Beschreibung:
Die RDP-Protokollkomponente X.224 hat einen Fehler im Protokollablauf festgestellt und die Clientverbindung getrennt."

Andersrum funktioniert es wunderbar, ich kann also vom XP Pro SP2 Client-PC dem Server Remoteunterstüzung anbieten, dort annehmen und bin drauf...
Dabei ist egal ob ich auf dem Client als lokaler Admin, Domänen-Admin oder Domänenbenutzer angemeldet bin.

Ich hoffe jemand hat einen guten Hinweis, ich muss nämlich nächste Woche das Netzwerk ausrollen und voher vom template-Client per HDD-Spiegelung noch Klone ziehen.
Bonusfrage: Was muss ich da bezüglich der SID's in den Computer-OUs noch machen, damit die Rechner auch als unterschiedliche erkannt werden?

Vielen Dank!

Menne

Content-ID: 43654

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

Ausgedruckt am: 26.11.2024 um 13:11 Uhr

Dani
Dani 03.11.2006 um 17:25:13 Uhr
Goto Top
Hi,
schau mal hier, ob da was passendes dabei ist;
http://eventid.net/display.asp?eventid=50&eventno=606&source=Te ...


Gruß
Dani
Menne
Menne 06.11.2006 um 14:23:25 Uhr
Goto Top
Hallo Dani und alle anderen,

die Informationen zum Fehlerereignis habe ich soweit schon alle nachverfolgt; zur Event-ID 50, Quelle TermDD finde ich nur einen Hinweis auf fehlerhafte Zertifikate; habe den Schlüssel in der Registry auch gelöscht und er wurde von System neu erstellt, allerdings alles ohne den gewünschten Erfolg.

Ereignisprotokoll - System - Fehler - TermDD - ID:50 kommt nach wie vor, außerdem finde ich im Ereignisprotokoll des Clients folgenden Eintrag:

Systemfehleintrag

Ereignistyp: Warnung
Ereignisquelle: RemoteAccess
Ereigniskategorie: Keine
Ereigniskennung: 20169
Datum: 06.11.2006
Zeit: 09:33:26
Benutzer: Nicht zutreffend
Computer: TEMP
Beschreibung:
Es konnte keine Verbindung zum DHCP-Server hergestellt werden. Die private IP-Adresse 169.254.238.205 wird Einwählclients automatisch zugewiesen. Clients können eventuell nicht auf Netzwerkressourcen zugreifen.

--> was mir grundlegend komisch vorkommt, da weder der Server als DHCP fungiert und der Client statische Adressierung verwendet; nach Einrichtung der DHCP-Funktionalität am Server kommt die Warnung nicht mehr


Zuvor hatte ich auf andere Fehlermeldungen wie:

Ereignistyp: Fehler
Ereignisquelle: NETLOGON
Ereigniskategorie: Keine
Ereigniskennung: 5719
Beschreibung:
Es steht kein Domänencontroller für die Domäne ... aus folgendem Grund zur Verfügung:
Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. .

Ereignistyp: Fehler
Ereignisquelle: AutoEnrollment
Ereigniskategorie: Keine
Ereigniskennung: 15
Beschreibung:
Die automatische Zertifikatregistrierung für "lokaler Computer" konnte keine Verbindung zum Active Directory (0x8007054b) herstellen. Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. Die Registrierung wird nicht durchgeführt.

Ereignistyp: Fehler
Ereignisquelle: Userenv
Ereigniskategorie: Keine
Ereigniskennung: 1054
Beschreibung:
Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen.

--> Allerdings waren die für mich auch nicht ganz nachvollziehbar, da es keine Probleme bei der Anmeldung etc. gab, ebenso wurden Gruppenrichtlinien am Client verarbeitet...


AKTUELLER STAND
Wenn ich vom Win2003 R2 Server SP1 dem XP Pro SP2 Client Remoteunterstützung anbiete, erscheint auf dem Client nach wie vor kein Meldungsfenster zum Bestätigen der Remotesteuerung. Mittlerweile ist die Ereignisanzeige auf dem Client Fehler- und Warnungsfrei. Ebenso erscheint in den Anwendungseinträgen des Clients die Information "Ein Remoteunterstützungsticket mit Lebensdauer 0.08 Stunden wurde erstellt..."; Quelle: Remote Assistance, ID: 5270. Firewall ist offen, telnet funktioniert auf TCP 3389 und 135. Andersrum funktiert das Ganze, das Problem ist also auf dem Client zu lokalisieren.
Ich bin ratlos.

Bin für weitere Ideen und Anregungen dankbar!
Menne
Menne 06.11.2006 um 16:09:56 Uhr
Goto Top
Nachtrag:
Fehler von TermDD, ID:50 tritt nun wieder regelmäßig auf dem Client auf, genau zu der Zeit wo versucht wird eine Remoteverbindung aufzubauen. Das Problem scheint also doch damit in engem Zusammenhang zu stehen.

Ereignistyp: Fehler
Ereignisquelle: TermDD
Ereigniskategorie: Keine
Ereigniskennung: 50
Datum: 06.11.2006
Beschreibung:
Die RDP-Protokollkomponente X.224 hat einen Fehler im Protokollablauf festgestellt und die Clientverbindung getrennt.

Ein Anruf bei Microsoft ergab, dass mit ein Einzelfallsupport 299,- € netto kostet... brauch ich nichtmal ansatzweise drüber nachzudenken. Ein freundlicher Verweis noch auf TechNet, wo ich dann auch nochmals gestöbert habe. Habe nun zusätzlich noch via Gruppenrichtlinie die Terminaldienste konfiguriert (Remoteverbindung via Terminaldienste zulassen + Vollzugriff OHNE Erlaubnis des Benutzers); auch davon wird es nicht besser.
Das einzige was bleibt ist eine Remotedesktopverbindung zum Client, womit ich allerdings keine Benutzersitzungen übernehmen kann, damit das Benutzerpasswort bräuchte... nutzlos.

*Grrmpf* face-sad
Menne
Menne 07.11.2006 um 09:13:08 Uhr
Goto Top
Ich habe das Ganze jetzt mit einem weiteren XP Pro SP2 Client mit jungfräulicher Windows-Installation getestet - da funktioniert es wie erwartet. Das Problem liegt also definitiv lokal auf meinem Template-Client, was aber nun mal der fertig konfigurierte Template-Client ist, der als Image-Grundlage dient.
Konkret würden mir alle erforderlichen Registryeinträge weiterhelfen, die für die Remoteunterstützung und die Terminaldienste verantwortlich sind. Diese könnte ich dann vielleicht von dem funktionierenden System übernehmen...
Ich muss dringend mit dem Re-Imaging beginnen, Problem ist eilig.

Grüße in die Foren-Gemeinde,

Menne
Menne
Menne 07.11.2006 um 11:28:43 Uhr
Goto Top
Nach langem Haare raufen und endlosen Recherchen hat mich der Artikel KB306045 in der englischen Knowledge-Base (http://support.microsoft.com/kb/306045/en-us) auf die Lösung gebracht:

Wenn in der Registry die Einstellung "zuletzt angemeldeten Benutzer nicht anzeigen" gesetzt ist wird die Autologon-Funktion deaktiviert, was dazu führt, dass der Hilfsassistent die Remotesitzung nicht aufbauen kann. In der Folge bekommt der Client auch keinen Abfragebildschirm.

PROBLEM:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Value name: DontDisplayLastUserName
Data type: REG_SZ
Value Data: 1

LÖSUNG:
REG_SZ-Wert für diesen Schlüssel auf 0 setzen, bzw. den gesamten Schlüssel löschen.

Schade, dass sich die Einstellungen beißen. DontDisplayLastUserName war von mir nicht umsonst gesetzt! Aus Datenschutzsicht sehe ich es durchaus nicht als unerheblich, ob der zuletzt angemeldete Benutzer am Anmeldebildschirm preisgegeben wird oder nicht.

Vielleicht kann dieser Beitrag jemand anderen viel Arbeit und Ärger ersparen...

Gruß
Menne