2
RDP-Verbindung via mRemoteNG kommt nicht zustande (TimeOut)
Guten Abend zusammen,
da fast Freitag ist - mal eine Frage nach dem "Schubs" in die richtige Richtung....
Ich sortier's mal unter Windows Server ein, scheint mir das Naheliegendste? Wenn ich mich mal wieder irre - bitte gerne verschieben!
In meinem HomeLab habe ich einige Windows-Server am Laufen, ganz easy (fast) direkt an der Fritzbox 7590 - darauf greife ich der Einfachheit halber mittels mRemoteNG zu. Das relativ sporadisch, die Rechner laufen aber 24/7, sprich: MS-Updates auf "Automatik" (Nicht gut, ich weiss, WSUS ist im Aufbau/in Planung)
Seit kurzer Zeit (5-6 Wochen) bekomme ich beim Zugriff mittels mRemoteNG auf einen bestimmten Server Probleme, weil ich ewig auf das Herstellen der Verbindung warte - und NG irgendwann alle Versuche aufgibt und in eine TimeOut läuft.
Einstellungen habe ich alle auf den vorgegebenen Standards belassen, Leerlauf steht bei 240 Sekunden.
Meldung des Servers lautet immer "Warten auf Benutzerprofildienst" - Zugriff trotz Domäne als lokaler Server-Admin (ja, übertrieben, zu Hause eine Domäne hochzuziehen für 2 Leute, ist aber auch nur Bastelbude und soll demnächst mal auf Linux und UCS umgemodelt werden - und wenn's dann mal läuft...).
Hat jemand Erfahrung oder einen Tipp, wo das Problem liegen könnte? Etwaige fehlende Infos liefere ich gerne nach, ist auch nicht lebensnotwendig, das zeitnah zu beheben (ist ja nur Lab) - ich würd's nur gern verstehen - und (jetzt kommt der Freitag): "bis vor ein paar Tagen/Wochen lief's völlig problemlos"...
Das "ich hab nix gemacht" spar ich mir an dieser Stelle
NW-Konstrukt:
alles hängt an einer FB 7590, daran ein Netgear JGS524Ev2 – 24-Port Gigabit Ethernet Smart Managed Plus Switch, von da geht's mit Cat7 weiter zu den "Servern" (div. ausgediente Laptops - für's Lab reicht's aber). RDP über Port 3389
Alle Server 2016er, auch auf dem aktuellen Stand, DC inkl. DNS flott erreichbar, SQL flott erreichbar, SharePoint flott erreichbar, nur der Applikations-Server zickt rum.
[Flott heißt hier: sofortiger Verbindungsaufbau mittels NG via RDP ohne imense Wartezeiten direkt beim ersten Mal]
Ich will gar keine fertige Lösung, aber ein Schubs in die Richtung wäre toll! Steh' gerade wie der Ochs' vor'm Berg... Im Anhang mal die NG-Einstellungen, falls es hilft.
Besten Dank vorab den verehrten Profis!
HoyerAC
KORREKTUR: "Bite warten Sie auf Lokaler Sitzungsmanager" ist das Problem (Sch... Copy and Paste..., war in einem Teams-Chat mit den Kollegen noch drin für ein anderes Problem)
da fast Freitag ist - mal eine Frage nach dem "Schubs" in die richtige Richtung....
Ich sortier's mal unter Windows Server ein, scheint mir das Naheliegendste? Wenn ich mich mal wieder irre - bitte gerne verschieben!
In meinem HomeLab habe ich einige Windows-Server am Laufen, ganz easy (fast) direkt an der Fritzbox 7590 - darauf greife ich der Einfachheit halber mittels mRemoteNG zu. Das relativ sporadisch, die Rechner laufen aber 24/7, sprich: MS-Updates auf "Automatik" (Nicht gut, ich weiss, WSUS ist im Aufbau/in Planung)
Seit kurzer Zeit (5-6 Wochen) bekomme ich beim Zugriff mittels mRemoteNG auf einen bestimmten Server Probleme, weil ich ewig auf das Herstellen der Verbindung warte - und NG irgendwann alle Versuche aufgibt und in eine TimeOut läuft.
Einstellungen habe ich alle auf den vorgegebenen Standards belassen, Leerlauf steht bei 240 Sekunden.
Meldung des Servers lautet immer "Warten auf Benutzerprofildienst" - Zugriff trotz Domäne als lokaler Server-Admin (ja, übertrieben, zu Hause eine Domäne hochzuziehen für 2 Leute, ist aber auch nur Bastelbude und soll demnächst mal auf Linux und UCS umgemodelt werden - und wenn's dann mal läuft...).
Hat jemand Erfahrung oder einen Tipp, wo das Problem liegen könnte? Etwaige fehlende Infos liefere ich gerne nach, ist auch nicht lebensnotwendig, das zeitnah zu beheben (ist ja nur Lab) - ich würd's nur gern verstehen - und (jetzt kommt der Freitag): "bis vor ein paar Tagen/Wochen lief's völlig problemlos"...
Das "ich hab nix gemacht" spar ich mir an dieser Stelle
NW-Konstrukt:
alles hängt an einer FB 7590, daran ein Netgear JGS524Ev2 – 24-Port Gigabit Ethernet Smart Managed Plus Switch, von da geht's mit Cat7 weiter zu den "Servern" (div. ausgediente Laptops - für's Lab reicht's aber). RDP über Port 3389
Alle Server 2016er, auch auf dem aktuellen Stand, DC inkl. DNS flott erreichbar, SQL flott erreichbar, SharePoint flott erreichbar, nur der Applikations-Server zickt rum.
[Flott heißt hier: sofortiger Verbindungsaufbau mittels NG via RDP ohne imense Wartezeiten direkt beim ersten Mal]
Ich will gar keine fertige Lösung, aber ein Schubs in die Richtung wäre toll! Steh' gerade wie der Ochs' vor'm Berg... Im Anhang mal die NG-Einstellungen, falls es hilft.
Besten Dank vorab den verehrten Profis!
HoyerAC
KORREKTUR: "Bite warten Sie auf Lokaler Sitzungsmanager" ist das Problem (Sch... Copy and Paste..., war in einem Teams-Chat mit den Kollegen noch drin für ein anderes Problem)
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: 1328905569
Url: https://administrator.de/forum/rdp-verbindung-via-mremoteng-kommt-nicht-zustande-timeout-1328905569.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
2 Kommentare
Neuester Kommentar
bitte gerne verschieben!
DU selber bist der TO (Thread Owner) folglich kannst also aus gutem Grund NUR DU SELBER den Thread verschieben ("Bearbeiten" Knopf) ! Ein etwas sinnfreier Appell also. darauf greife ich der Einfachheit halber mittels mRemoteNG zu
Über das FB eigene VPN oder mit gefährlichem Port Forwarding und einem Loch in der FB Firewall ??Das wäre nich wichtig zu wissen. Meistens sind solche Fehler DNS Fehler.
Schalt mal das CredSSP aus, die CredSSP Negotiation wird nur verwendet bei Rechnern, die die Terminalserver Rolle haben, reine Remotedesktops nicht.
Was auch manchmal vorkommt, aber nur für eine Gatewayanmeldung (Webinterface mit oder ohne Lastenausgleich) zutrifft manchmal schlägt die Anmeldung fehl wenn per GPO per NTLMv2 gesperrt ist - dann verwendet der IIS Radius, und Radius überträgt die AD Gruppenmitgliedschaften unkomprimiert.
Wenn der betreffende Benutzer mehr als 2048 Zeichen an AD Gruppenmitgliedschaften mitbringt dann schlägt die Anmeldung fehl trotz korrekten Credentials. Sollte man aber grundsätzlich in den EReignisprotokollen des Servers wiederfinden, der die Anmeldung verarbeitet.
Was auch manchmal vorkommt, aber nur für eine Gatewayanmeldung (Webinterface mit oder ohne Lastenausgleich) zutrifft manchmal schlägt die Anmeldung fehl wenn per GPO per NTLMv2 gesperrt ist - dann verwendet der IIS Radius, und Radius überträgt die AD Gruppenmitgliedschaften unkomprimiert.
Wenn der betreffende Benutzer mehr als 2048 Zeichen an AD Gruppenmitgliedschaften mitbringt dann schlägt die Anmeldung fehl trotz korrekten Credentials. Sollte man aber grundsätzlich in den EReignisprotokollen des Servers wiederfinden, der die Anmeldung verarbeitet.
