Remotedesktop schlägt ohne Fehlermeldung fehl

Nach dem Neustart meines Servers Windows 2008 R2 kann ich mich nicht mehr beim Remotedesktop anmelden. Wenn ich versuche, eine Verbindung herzustellen, zoomt der Remotedesktop durch verschiedene Statusmeldungen, von denen die letzte "Konfigurieren der Remotesitzung" ist, und kehrt dann zum ursprünglichen Dialogfeld "Verbindung" zurück, ohne dass eine Fehlermeldung angezeigt wird.

Der Server scheint in Betrieb zu sein, da er immer noch Webseiten liefert. Außerdem scheint es meine Anmeldeinformationen zu akzeptieren.

Gibt es eine Möglichkeit zu erkennen, warum die Verbindung fehlschlägt? Ich habe die geraden Protokolle meines Systems durchsucht, konnte jedoch nichts im Zusammenhang mit dem Remotedesktop finden. Vielleicht gibt es einen versteckten Fehlerbehebungsmodus?

Vielen Dank,

Adrian

Bearbeiten: In der Zwischenzeit ist der Server wieder online. Ich bin mir nicht sicher, ob dies alleine oder beim technischen Support der Fall war, da ich bisher noch nichts von ihnen gehört habe, aber das Problem ist im Moment gelöst. Es ist ein bisschen enttäuschend, die Ursache des Problems nicht zu kennen.

Stellen Sie sicher, dass es tatsächlich neu gestartet wurde. Wenn Sie eine "Nettonutzung" für den Remoteserver durchführen können, stellen Sie eine Verbindung zur Ereignisanzeige her, um festzustellen, ob der Neustart tatsächlich durchgeführt wurde. Ich habe viele Win2k3-Server gesehen, die beim Neustart von einer RDP-Sitzung nicht neu gestartet werden, sondern nicht mehr auf RDP reagieren. In diesem Fall können Sie den Server herunterfahren / i oder eine andere Out-of-Band-Methode verwenden, um den Neustart tatsächlich auszuführen.

Wenn dies der Fall ist, starten Sie in Zukunft nicht mehr von einer regulären RDP-Sitzung aus neu. Starten Sie nur über die Verbindung / console oder / admin neu oder verwenden Sie shutdown / i oder andere Remote-Methoden.

Ich hatte ein Problem mit der Verwendung des Remotedesktops auf einem Server 2003. Ich habe eine Verbindung hergestellt und nachdem einige Statusmeldungen angezeigt wurden, wurde die Verbindung getrennt, bevor der vollständige Desktop angezeigt wurde.

Das Problem war, dass der Server eine falsche Zeit hatte, weil die Synchronisation einige Monate lang fehlschlug (ich glaube, es gab einen Zeitunterschied von ungefähr 30 Minuten).

Nach weiteren Untersuchungen des Ereignisprotokolls habe ich das Problem gefunden. Es gab diesen Fehler fast genau nach dem Start des Neustarts:

Der Windows Modules Installer-Dienst wurde nach Erhalt eines Preshutdown-Steuerelements nicht ordnungsgemäß heruntergefahren.

Das Problem war also, dass einige der Dienste heruntergefahren wurden, während dieser bestimmte Dienst hing. Es scheint nach einem Timeout (eine Stunde) beendet worden zu sein, wonach Windows wie beabsichtigt neu gestartet wurde.

Jetzt bleibt nur noch die Frage, wie dies in Zukunft verhindert werden kann. Natürlich möchte ich, dass zukünftige Neustarts etwas schneller laufen ...

Ich bin über Google mit dem gleichen Problem mit meinem Windows Server 2012 (7 Jahre später) hierher gekommen, daher werde ich meine eigenen Erfahrungen mit dem Problem für zukünftige Suchende hinzufügen. Folgendes ist passiert:

1. Angesichts der jüngsten WannaCrypt-Angriffe habe ich alle ausstehenden Sicherheitsupdates von Microsoft installiert. Natürlich war ein Neustart erforderlich. Zum zweiten Mal. In weniger als 24 Stunden. Auf einem Server, der 350 Tage vor diesem ganzen Durcheinander lief. Ich hoffe, alle Hacker brennen und verrotten in der Hölle (ich bin übrigens ein Atheist, ich glaube nicht einmal an die Hölle).
2. Ich habe in Windows Update auf die Schaltfläche Neustart geklickt. Meine RD-Sitzung wurde sofort beendet und alle Versuche, die Verbindung wiederherzustellen, schlugen ohne Fehlermeldung fehl, aber der Server war weiterhin ohne Unterbrechung in Betrieb und lieferte Seiten. Ich weiß das, weil mein AppPool bei jedem Herunterfahren ein oder zwei Minuten braucht, um vollständig geladen zu werden. Ich vermute, dass Windows Update einige vorbereitende Schritte durchlaufen hat, bei denen keine anderen Dienste auf dem System heruntergefahren werden mussten.
3. Nach einigen weiteren (sehr langen und stressigen) Minuten würde der Server für alle Anforderungen HTTP 503 zurückgeben. Ich könnte trotzdem den Server anpingen. Vermutung: Server läuft noch, IIS wird heruntergefahren, ernsthaftere Aktualisierungsarbeiten werden durchgeführt.
4. Etwa eine Minute später verlor ich jeglichen Zugriff auf den Server. Kein Kernel, kein Windows, nichts, das darauf wartet, dass das System nach dem eigentlichen Neustart wieder online geht.
5. Nach einer weiteren Minute war der Ping wieder da und ich konnte mich rechtzeitig mit RD verbinden, um die letzten Schritte des angewendeten Updates zu sehen. Der Server läuft seitdem normal.

Wenn Sie also unmittelbar nach dem Neustart den Remotezugriff auf Ihren Server verlieren, geraten Sie nicht in Panik . Er führt wahrscheinlich Wartungsarbeiten durch und wird nach Abschluss des Vorgangs sofort wieder online geschaltet.

Remotedesktop kann sich auch merkwürdig verhalten, wenn Sie ältere Grafiktreiber haben. Auf einem Server würde ich nicht denken, dass dies ein Problem wäre, aber das Aktualisieren der Grafiktreiber ist etwas anderes, das Sie versuchen können. (Es hat ein ähnliches Problem auf einem XP SP3-Computer für mich behoben.)

es ist gut, wenn es gelöst ist, aber für die zukünftigen Referenzen, füge ich diese Zeilen hinzu;

1. Remotedesktop funktioniert, sobald der Server in Betrieb ist und der Anmeldebildschirm nach dem Neustart angezeigt wird. Normalerweise werden alle ICMP (Ping) und Dienste (Web / Domain usw.) verfügbar, aber Remotedesktop erforderte, dass der Server vollständig betriebsbereit ist.
2. Wenn der Server neu gestartet wird und Sie erwarten, dass möglicherweise bereits eine andere Person verbunden ist, können Sie mstsc / admin ausprobieren . Auf diese Weise können Sie sich anmelden / das Limit von zwei Anmeldungen auf dem Server umgehen.
3. Um noch eine Sache in dieser Antwort zu behandeln, die nicht dazu dient, sondern damit zusammenhängt, kann ein veralteter Eintrag im DNS-Cache ebenfalls eine Sache sein, die Sie berücksichtigen sollten, aber er informiert Sie deutlich über den Fehler.