8
Windows Remoteunterstützung läuft nur noch im eigenen Netz
Hallo!
Wir nutzen seit etwa zwei Jahren sehr ausgiebig die Windows Remoteunterstützung. Hierzu starten wir aus der IT den msra.exe-Client und schicken dem Benutzer eine Aufforderung, die Unterstützung zu aktzeptieren. Das hat seit Einführung auch gut funktioniert, wir bedienten damit drei verschiedene Netze. Unser eigenes, sowie zwei geroutete Standorte.
Die beiden gerouteten Standorte lassen sich nun nicht mehr mit der Remoteunterstützung bedienen. Interessanterweise startet im Moment der Aufforderung aber auf dem entfernten Client der zugehörige Dienst. Aber die Bildschirmmeldung "... möchten Sie XYZ die Ansicht... erlauben" kommt nicht. Stoppt man die Anforderung auf dem Quell-PC, stoppt der Dienst sogleich wieder. Macht man nichts und wartet ab, läuft er nach etwa einer Minute in einen Timeout. Dies wird dann auf beiden PCs mit "Benutzer reagiert nicht" oder "... es gab Probleme beim Verbindungsaufbau" quittiert.
An der bestehenden Netzwerkkonfiguration wurde nichts verändert. Der Klassiker eben. Ich habe hier den DNS-Server im Verdacht, allerdings ohne wirklich zu wissen, wo das Problem liegt. Die Rechner sind untereinander per DNS auffindbar (in beide Richtungen). Der Support von VNC klappt ebenfalls (in beide Richtungen). Es spielt auch keine Rolle, ob ich die IP-Adresse oder den Rechnernamen zur Verbindungsherstellung eingebe.
Ausführende Systeme sind Windows 7 und Windows 10 im Mischbetrieb. Windows Firewall testweise auf beiden Systemen deaktiviert.
Jemand eine Idee, oder das Problem vielleicht schon einmal gehabt?
Wir nutzen seit etwa zwei Jahren sehr ausgiebig die Windows Remoteunterstützung. Hierzu starten wir aus der IT den msra.exe-Client und schicken dem Benutzer eine Aufforderung, die Unterstützung zu aktzeptieren. Das hat seit Einführung auch gut funktioniert, wir bedienten damit drei verschiedene Netze. Unser eigenes, sowie zwei geroutete Standorte.
Die beiden gerouteten Standorte lassen sich nun nicht mehr mit der Remoteunterstützung bedienen. Interessanterweise startet im Moment der Aufforderung aber auf dem entfernten Client der zugehörige Dienst. Aber die Bildschirmmeldung "... möchten Sie XYZ die Ansicht... erlauben" kommt nicht. Stoppt man die Anforderung auf dem Quell-PC, stoppt der Dienst sogleich wieder. Macht man nichts und wartet ab, läuft er nach etwa einer Minute in einen Timeout. Dies wird dann auf beiden PCs mit "Benutzer reagiert nicht" oder "... es gab Probleme beim Verbindungsaufbau" quittiert.
An der bestehenden Netzwerkkonfiguration wurde nichts verändert. Der Klassiker eben. Ich habe hier den DNS-Server im Verdacht, allerdings ohne wirklich zu wissen, wo das Problem liegt. Die Rechner sind untereinander per DNS auffindbar (in beide Richtungen). Der Support von VNC klappt ebenfalls (in beide Richtungen). Es spielt auch keine Rolle, ob ich die IP-Adresse oder den Rechnernamen zur Verbindungsherstellung eingebe.
Ausführende Systeme sind Windows 7 und Windows 10 im Mischbetrieb. Windows Firewall testweise auf beiden Systemen deaktiviert.
Jemand eine Idee, oder das Problem vielleicht schon einmal gehabt?
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: 438427
Url: https://administrator.de/forum/windows-remoteunterstuetzung-laeuft-nur-noch-im-eigenen-netz-438427.html
Ausgedruckt am: 23.12.2024 um 15:12 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
geht RDP direkt?
Geht es aus dem jeweils lokalen Netzwerk?
Habt ihr sonstige Remotetools (Teamviewer) auf den Geräten installiert?
Was sagt ein gpresult an den betroffenen Systemen?
Eventlogs geben auch nichts her?
Wie ist die Domäne aufgebaut?
geht RDP direkt?
Geht es aus dem jeweils lokalen Netzwerk?
Habt ihr sonstige Remotetools (Teamviewer) auf den Geräten installiert?
Was sagt ein gpresult an den betroffenen Systemen?
Eventlogs geben auch nichts her?
Wie ist die Domäne aufgebaut?
Nein, die Eventlogs geben nichts her. RDP Sessions laufen problemlos, das Problem betrifft nur die Remoteunterstützung.
Außer VNC gibt es keine weiteren Remotetools.
gpresult ist meines Erachtens fehlerfrei, es gibt eine Hauptdomäne mit drei Standorten.
Es gibt auch keine Unterscheidung dieser Standorte. Keine Regeln die nur für Standort A, aber nicht für B greifen, welche somit irgendwelche Einseitigen Fehler verursachen könnten. Gleiches gilt für Netzwerkfreigaben, Firewall, etc.
Seltsam ist ja, dass auf dem Zielclient der Dienst auch prompt startet - er aber keine Meldung ausgibt. Dabei spielt es auch keine Rolle, ob ich dem User eine Aufforderung sende, oder er mir selbst eine Einladung per Mail schickt. Geht beides nicht.
Außer VNC gibt es keine weiteren Remotetools.
gpresult ist meines Erachtens fehlerfrei, es gibt eine Hauptdomäne mit drei Standorten.
Es gibt auch keine Unterscheidung dieser Standorte. Keine Regeln die nur für Standort A, aber nicht für B greifen, welche somit irgendwelche Einseitigen Fehler verursachen könnten. Gleiches gilt für Netzwerkfreigaben, Firewall, etc.
Seltsam ist ja, dass auf dem Zielclient der Dienst auch prompt startet - er aber keine Meldung ausgibt. Dabei spielt es auch keine Rolle, ob ich dem User eine Aufforderung sende, oder er mir selbst eine Einladung per Mail schickt. Geht beides nicht.
1
Moin,
wir haben genau das gleiche Problem. Im lokalem Netzwerk ist alles OK und die Remotestandorte machen Probleme. Auch ich sehe das der ferngesteuerte Client die msra.exe startet, aber die Abfrage öffnet sich nicht. Beende ich meinen Sitzungsversuch noch vor dem Timeout und versuche es gleich erneut, öffnet sich beim Remoteclient das Zustimmungsfenster, aber dafür sagt mir mein Client es besteht schon eine Sitzung.
Seltsam - eine Kommunikation läuft also.
Auch ich habe schon die Windows und die Netzwerk Firewall ausgeschlossen, die GPO ist seit Jahren unverändert. Vielleicht sind MS-Sicherheitsupdates verantwortlich.
wir haben genau das gleiche Problem. Im lokalem Netzwerk ist alles OK und die Remotestandorte machen Probleme. Auch ich sehe das der ferngesteuerte Client die msra.exe startet, aber die Abfrage öffnet sich nicht. Beende ich meinen Sitzungsversuch noch vor dem Timeout und versuche es gleich erneut, öffnet sich beim Remoteclient das Zustimmungsfenster, aber dafür sagt mir mein Client es besteht schon eine Sitzung.
Seltsam - eine Kommunikation läuft also.
Auch ich habe schon die Windows und die Netzwerk Firewall ausgeschlossen, die GPO ist seit Jahren unverändert. Vielleicht sind MS-Sicherheitsupdates verantwortlich.
Genau. Selbes Problem. Der Hinweis mit dem erneuten Starten ist mir glatt entfallen, ist aber bei uns genau so.
Hi, wie habt ihr eure Standorte verbunden? Wir nutzen die Sophos UTM mit RED-Devices.
Über eine MPLS-Verbindung des Providers.
Wir haben das Problem gefunden und gelöst.
Die Sophos UTM hat durch neue Pattern bestimmte Pakete in der Intrusion Prevention geblockt.
Meldung: OS-Windows Microsoft Windows Terminal server RDP over non-standard port attempt - https://www.snort.org/search?query=49040
Ich hoffe damit geholfen zu haben.
Die Sophos UTM hat durch neue Pattern bestimmte Pakete in der Intrusion Prevention geblockt.
Meldung: OS-Windows Microsoft Windows Terminal server RDP over non-standard port attempt - https://www.snort.org/search?query=49040
Ich hoffe damit geholfen zu haben.
Super Tipp, vielen Dank! Ein ausschalten der IPS hat auch gleich geholfen. Lief dann wieder.
Wie habt Ihr das Problem denn umgangen? Eine Ausnahme erstellt? Für was genau? Wenn ich die verwendeten Ports als Ausnahme hinterlege, bringt das leider keinen Effekt.
Beste Grüße
Wie habt Ihr das Problem denn umgangen? Eine Ausnahme erstellt? Für was genau? Wenn ich die verwendeten Ports als Ausnahme hinterlege, bringt das leider keinen Effekt.
Beste Grüße
