Remotesteuerung bricht ab

Hallo in die Runde,

habe hier ein kurioses Problem, was die Remotesteuerung betrifft, vorab die dafür vorhandene Umgebung:

-Terminalserver unter Windows Server 2008 und WS2k8 R2
-Client-PC für die Administration unter Win 7 Prof.

Wenn ich nun über den Client-PC eine RDP-Session zu einem Terminal aufbaue, baut sich ganz normal der Desktop auf und es lässt sich auch normal arbeiten. Nun aktiviere ich den Task-Manager und gehe bei Benutzer auf den User, der Hilfe anfordert und wähle REMOTESTEUERUNG aus.

Erst passiert nichts, dann wird der Bildschirm kurz schwarz und danach ist meine Sitzung wieder da, die Benutzer-Sitzung habe ich aber nicht gesehen.

Nun habe ich gelesen, das es an rdesktop liegen könnte, setze aber selbst ja WIN7 ein und demzufolge das dort installierte RDP der aktuellen Fassung. Auch auf den Servern liegt das MS-eigene RDP vor.

Früher unter Windows Server 2003 und Windows XP konnten wir problemlos damit den Usern helfen und support leisten, aber seit wir die WS2008er einsetzen, hakt es da immer.

Kennt einer das Problem und evtl. auch die Lösung?

Grüße
Oliver

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 191491

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

Ausgedruckt am: 26.11.2024 um 06:11 Uhr

8 Kommentare

Neuester Kommentar

Moin.

seit wir die WS2008er einsetzen, hakt es da immer

IMMER? Ging noch nie, oder ging schon mal?

Wenn die UAC an ist, muss man seit win2008 zunächst den Taskmanager elevaten, also beispielsweise auf "Prozesse aller Nutzer anzeigen" klicken, das ruft elevation (die UAC-Abfrage+anschließende Hochstufung) hervor. Dann erst kann man andere steuern.

Was sonderbar ist: es müsste nicht wie bei der Bildschirm kurz schwar werden, sondern "Zugriff verweigert" gemeldet werden. Oder ist Eure UAC aus?

Zitat von @DerWoWusste:

Moin.

> seit wir die WS2008er einsetzen, hakt es da immer
IMMER? Ging noch nie, oder ging schon mal?

seit WS2008er-Zeiten, immer. Anfänglich gab es mal noch Fehlermeldungen die auf ein Protokollfehler verwiesen, seit zwei Monaten kommt aber auch diese Meldung nicht mehr, seit ein Update drüber ist, um evtl. Remotesteuerungsprobleme zu beheben.

Wenn die UAC an ist, muss man seit win2008 zunächst den Taskmanager elevaten, also beispielsweise auf "Prozesse aller
Nutzer anzeigen" klicken, das ruft elevation (die UAC-Abfrage+anschließende Hochstufung) hervor. Dann erst kann man
andere steuern.

Was sonderbar ist: es müsste nicht wie bei der Bildschirm kurz schwar werden, sondern "Zugriff verweigert" gemeldet
werden. Oder ist Eure UAC aus?

Wir gehen ja eigentlich über den Taskmanager und als Administrator ist da auch immer der Haken für alle Prozesse aktiv, als Admin erhalte ich aber keinen Hinweis auf UAC, diese haben wir aber aktiv auf den Servern.

So, hab es mal eben nochmal nachgestellt, mit folgender Umgebung:

- Anmeldung als Admin auf einem Terminal
- Anmeldung als User auf dem gleichen Terminal

Admin - startet TASK, haken für alle Prozesse ist schon vorhanden, gehe auf Register Benutzer, wähle User aus und klicke Remotesteuerung an.

User - erhält Hinweis DOMAIN\Admin fordert die Remoteüberwachung der Sitzung an, Nehmen Sie die Anforderung an? (Bildschirm Admin solange schwarz)
klicke auf JA

es passiert:
User - Remotedesktopsitzung wurde beendet
Admin - fällt in seine Sitzung zurück, Task Manager zeigt USER als getrennt an.

So, nun habe ich mir mal das Eventlog angesehen, unter Anwendung ist nichts aufgeführt, im Bereich System gibt es jedoch den Hinweis auf Fehler TERMDD - 50 - Die RDP-Protokollkomponente "DATA ENCRYPTION" hat einen Fehler im Protokollablauf festgellt und die Clientverbindung getrennt. Bei zwei Versuchen, kommt der Hinweis aber nur 1x vor.

An diesem Beispiel Terminal ist aber die UAC sogar deaktiviert, war eine Empfehlung in Bezug auf einige Anwendungen die interaktive Meldungen versenden, u. a. Druckermonitore.

als Administrator ist da auch immer der Haken für alle Prozesse aktiv

Nein. Nur beim eingebauten Konto "Administrator" ist das so. Wenn die UAC an ist und wie empfohlen auf voll (und nicht wie bei Win7/2008R2 per default nur auf zweithöchster Stufe), dann ist der Haken bei normalen (Domänen-)admins nicht gesetzt und der Taskmanager ist nicht elevated.

Aber egal, wenn der Haken bei Dir gesetzt ist, läuft er elevated und das Problem kann auf dieser Schiene nicht angegangen werden.

seit ein Update drüber ist, um evtl. Remotesteuerungsprobleme zu beheben

Welches Update? Nennen, deinstallieren, Fehler reproduzieren, Meldung nennen.

Wenn ich das Update noch wüßte,... aber ohne kommt halt nur beim Admin sofort ein Fehlerhinweis und der User erhält erst gar nicht die Anforderung, von daher würde ich es nicht unbedingt entfernen wollen.

Meine Suche über Fehler der TERMDD-Quelle mit ID 50 verweist meistens auf XP-Rechner, habe aber hier einen WIN7 Rechner, sprich die Kommunikation und Sicherheitsaushandlung sollte ohne Probleme durchlaufen. Ein Hinweis für Server unter Win2000 verweist auf ein Zertifikatsproblem, tja, aber gilt das dann auch für einen 2008?

Hätte da jetzt noch eine Idee,.. der Server hat aktuell die RDC Version 6.0.6002, er selbst sagt das er nur bis 6.1 unterstützen kann.

Der Client liegt dagegen bei 6.1.7601 und unterstützt 7.1

Kann es sein das sich das kappelt? Das der Server einfach nicht versteht was für eine Version der Client führt, zwar soweit alles zulässt, aber bei der Remotesteuerung durcheinander kommt und abbricht?

Das C in RDC steht für Client. Die Clientkomponente hat nichts mit seinen Eigenschaften als Server zu tun, aber auf den letzten RD-Client kannst Du den Server jedenfalls schmerzfrei und ohne Neustart upgraden, wenn Du es mit absoluter Sicherheit wissen willst.
Auch kannst Du es clientseitig (von xp oder Vista aus) ja mal mit 6.0 versuchen.

Ich würde das Update entfernen und mit der Meldung auf die Suche gehen. Kannst das Update ja sofort wieder einspielen.

Danke für die bisherigen Antworten, werde wohl oder übel mir am Wochenende die Updateverlaufliste ansehen und prüfen.
Mit XP oder Vista kann ich es leider nicht testen, da wir das überhaupt nicht mehr einsetzen.