Fehlerbehebung für RDP

In einigen Situationen können Sie möglicherweise keine Verbindung mit Ihrer Windows-VM-Instanz von Compute Engine mit RDP herstellen. Dies kann an Konfigurationsfehlern, Netzwerkfehlern oder daran liegen, dass der Bootvorgang nicht abgeschlossen wurde.

In diesem Dokument werden einige Tipps und Ansätze zur Fehlerbehebung und Behebung häufiger RDP-Probleme beschrieben.

Feststellen, ob die VM online und bereit ist

Nachdem der Startvorgang der VM abgeschlossen ist, was einige Minuten dauern kann, können Sie den Status mit einer der folgenden Methoden prüfen:

Serieller Port 1

Der serielle Port 1 wird zum Protokollieren von System- und Anwendungsaktivitäten verwendet. Sehen Sie sich die Ausgabe an, um festzustellen, ob die VM gestartet wurde und ob Dienste ordnungsgemäß gestartet wurden.

  1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf:

    Zur Seite „VM-Instanzen“

  2. Klicken Sie auf den Namen der VM, für die Sie Logs aufrufen möchten. Die Seite VM-Instanzdetails wird geöffnet.

  3. Wählen Sie unter Logs die Option Serieller Port 1 aus.

  4. Prüfen Sie die Ausgabe des seriellen Ports 1 und achten Sie auf Ausgabe in etwa so aussehend:

    BdsDxe: loading Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
    BdsDxe: starting Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
    
    UEFI: Attempting to start image.
    Description: Windows Boot Manager
    FilePath: HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
    OptionNumber: 3.
    
    2021/04/13 10:50:22 GCEGuestAgent: GCE Agent Started (version 20210128.00)
    2021-04-13T10:50:23.4621Z OSConfigAgent Info: OSConfig Agent (version 20210217.00.0+win@1) started.
    2021/04/13 10:50:42 GCEMetadataScripts: Starting startup scripts (version 20200129.00).
    2021/04/13 10:50:42 GCEMetadataScripts: No startup scripts to run.
    

Die Ausgabe mit GCEGuestAgent oder GCEMetadataScripts bestätigt, dass Windows erfolgreich gestartet wurde. Versuchen Sie, mithilfe von RDP eine neue Verbindung zur VM herzustellen.

Serieller Port 2

Der serielle Port 2 bietet eine interaktive Verbindung zur VM und zeigt auch die Ausgabe der Special Administration Console (SAC) an. Mit der seriellen Konsole 2 können Sie feststellen, ob Systemdienste erfolgreich gestartet wurden.

  1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf:

    Zur Seite „VM-Instanzen“

  2. Klicken Sie auf den Namen der VM, für die Sie Logs aufrufen möchten. Die Seite VM-Instanzdetails wird geöffnet.

  3. Maximieren Sie unter Logs die Option Mehr und klicken Sie dann auf Serieller Port 2 (Konsole).

  4. Prüfen Sie die Ausgabe des seriellen Ports 2 und schauen Sie nach Ausgabe ähnlich der folgenden:

    BdsDxe: loading Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
    BdsDxe: starting Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
    
    UEFI: Attempting to start image.
    Description: Windows Boot Manager
    FilePath: HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
    OptionNumber: 3.
    
    <machine-info>
    <name>WINDOWS</name>
    <guid>b7ab5000-4000-e000-e000-bc5a738da000</guid>
    <processor-architecture>AMD64</processor-architecture>
    <os-version>10.0</os-version>
    <os-build-number>17763</os-build-number>
    <os-product>Windows Server 2019 Datacenter</os-product>
    <os-service-pack>None</os-service-pack>
    </machine-info>
    Computer is booting, SAC started and initialized.
    Use the "ch -?" command for information about using channels.
    EVENT: The CMD command is now available.
    SAC>
    

Die Ausgabe mit SAC started and initialized oder CMD command is now available bestätigt, dass Windows erfolgreich gestartet wurde. Versuchen Sie, mithilfe von RDP eine neue Verbindung zur VM herzustellen.

VM-Screenshot

VM-Screenshots bieten eine visuelle Darstellung des Status einer VM, ähnlich wie bei einem Computermonitor.

  1. Bevor Sie einen Screenshot Ihrer VM erstellen können, müssen Sie die virtuelle Anzeige der VM aktivieren. Wenn Sie die virtuelle Anzeige noch nicht aktiviert haben, siehe Virtuelle Anzeigen aktivieren.

  2. Machen Sie einen Screenshot. Weitere Informationen finden Sie unter Screenshot einer VM erstellen.

  3. Sehen Sie im Screenshot nach, ob die Instanz bereit ist.

Vergleichen Sie Ihren Screenshot mit dem folgenden Beispiel, um den aktuellen Status zu ermitteln:

  • Ein Windows-Anmeldebildschirm bestätigt, dass das Betriebssystem erfolgreich gestartet wurde. Sie können jetzt versuchen, eine Verbindung über RDP herzustellen.
  • Der Fortschrittsbildschirm für Windows Update zeigt an, dass die VM noch nicht bereit ist. Warten Sie, bis die Updates abgeschlossen sind.
  • Ein Ladebildschirm für Dienste zeigt an, dass die VM noch nicht bereit ist. Geben Sie der VM mehr Zeit, um die erforderlichen Dienste zu starten.
  • Ein UEFI-Ladebildschirm kann auf eine fehlende Bootdatei oder einen fehlenden Bootdatensatz oder einen beschädigten Bootsektor/Bootmanager hinweisen.
  • Ein Windows-Bluescreen-Fehler kann vorübergehend sein oder eine weitere Fehlerbehebung erfordern.

Wenn Windows nach einigen Minuten nicht erfolgreich gestartet wurde, lesen Sie den Leitfaden Fehlerbehebung bei Windows.

Konnektivität zwischen Workstation und VM-Instanz prüfen

Wenn beim Verbinden Ihrer Windows-VM Probleme auftreten, ist es sinnvoll, festzustellen, ob das Problem auf die Workstation zurückzuführen ist, die Sie für die Verbindung verwenden, oder auf die VM, zu der Sie eine Verbindung herstellen wollen. Prüfen Sie die Verbindung zwischen Ihrer Workstation und der VM. Führen Sie dazu folgenden Befehl auf Ihrer Linux-, macOS- oder Windows-Workstation aus:

curl -v telnet://DESTINATION_IP_ADDRESS:PORT

Ersetzen Sie Folgendes:

  • DESTINATION_IP_ADDRESS: Die IP-Adresse Ihrer Windows-VM
  • PORT: Der für die Verbindung über RDP auf Ihrer Windows-VM konfigurierte Port

Sie können auch Konnektivitätstests verwenden, um die Konnektivität zwischen der VM-Instanz und anderen Produkten und Diensten von Google Cloud weiter zu prüfen. Darüber hinaus kann es auch sinnvoll sein, einen Bastion Host im selben Subnetzwerk einzurichten, um RDP-Verbindungsprobleme auf der VM-Instanz zu isolieren.

Verbindung zum Metadatenserver prüfen

Die Verbindung zum Metadatenserver (169.254.169.254 oder fd20:ce::254) ist für eine fehlerfreie Windows-Instanz unerlässlich. Wenn die Instanz den Zugriff auf den Metadatenserver verliert, können Anwendungen möglicherweise keine Anmeldedaten abrufen und Sie können möglicherweise keine Verbindung zur Instanz über RDP herstellen.

Meldungen in den Konsolenlogs des seriellen Ports 1 können Hinweise auf Netzwerk- oder Dienstfehler während des Bootvorgangs geben. Suchen Sie beispielsweise nach Fehlern, die darauf hinweisen, dass die Instanz keine Verbindung zum Metadatenserver (169.254.169.254 oder fd20:ce::254) herstellen kann.

Wenn die Instanzprüfungen erfolgreich sind, Sie den Metadatenserver aber immer noch nicht erreichen können, folgen Sie der Anleitung unter Fehlerbehebung bei Zugriffsproblemen mit Metadatenserver, um die Verbindung zu testen und das Problem zu beheben.

RDP-Script zur Fehlerbehebung verwenden

Die von Google bereitgestellten Windows-VM-Instanzen enthalten ein Diagnoseskript, das viele der in diesem Dokument beschriebenen Prüfungen automatisiert.

  1. Verbindung zur SAC einer Windows-VM herstellen
  2. Öffnen Sie PowerShell; dazu geben Sie powershell ein.
  3. Führen Sie den folgenden Befehl aus, um die Diagnose zu starten:

    powershell -file "C:\Program Files\Google\Compute Engine\diagnostics\rdp_status.ps1" | more
    
  4. Prüfen Sie die Ausgabe auf „FEHLGESCHLAGEN“-Ergebnisse und wenden Sie die vorgeschlagenen Lösungen an.

Windows-Instanzkennwort überprüfen

Für jede Windows-Instanz von Compute Engine muss ein lokales Kennwort festgelegt werden, wenn es sich nicht bereits in einer Domain oder einem benutzerdefinierten Image befindet. Überprüfen Sie, ob Sie über das Google Cloud CLI-Befehlszeilentool oder die Google Cloud Console das richtige Passwort festgelegt haben, indem Sie eine Verbindung zur VM herstellen. Weitere Informationen finden Sie unter Verbindung zur SAC einer Windows-VM herstellen.

Wenn beim Herstellen der Verbindung Probleme auftreten, versuchen Sie, das Passwort zu erstellen oder zurückzusetzen. Weitere Informationen finden Sie unter Konten und Anmeldedaten auf Windows-VMs verwalten.

Prüfen, ob Sie Windows Server Core verwenden

Wenn Sie beim Herstellen einer Verbindung über RDP ein Eingabeaufforderungsfenster auf einem leeren Hintergrund erhalten, verwenden Sie wahrscheinlich Windows Server Core. Führen Sie den folgenden Befehl aus, um dies zu bestätigen:

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v InstallationType

Server Core in Ihrer Ausgabe bestätigt, dass Sie Windows Core Version verwenden.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    InstallationType    REG_SZ    Server Core

Wenn Sie eine grafische Benutzeroberfläche für Ihre Arbeitslast benötigen, finden Sie unter Windows Server-Instanz erstellen Informationen dazu, wie Sie eine Instanz mit Desktopdarstellung anstelle einer Windows Server Core-Instanz erstellen. Alternativ können Sie die Microsoft-Dokumentation zum Verwalten von Windows Core-Servern lesen.

VPC-Firewall-Regeln prüfen

Compute Engine stattet neue Projekte automatisch mit einer Firewallregel aus, die RDP-Datenverkehr zulässt. Wenn Sie ein vorhandenes Projekt haben oder die Konfigurationen geändert haben, ist die Standard-Firewallregel, die RDP zulässt, möglicherweise nicht vorhanden. Bestätigen Sie, dass eine Regel dem RDP-Traffic die Verbindung mit dem Netzwerk ermöglicht, in dem sich die betroffene Instanz befindet.

Wenn Sie überprüfen möchten, ob die Firewallregel default-allow-rdp in Ihrem Projekt vorhanden ist, öffnen Sie die Seite "Firewallregeln" oder führen Sie den folgenden gcloud CLI-Befehl aus:

gcloud compute firewall-rules list

Wenn es keine Regel gibt, können Sie mit dem folgenden Befehl eine neue erstellen:

gcloud compute firewall-rules create allow-rdp --allow tcp:3389

Externe IP-Adresse prüfen

Überprüfen Sie, ob Sie sich mit der richtigen externen IP-Adresse für die Instanz verbunden haben. Sehen Sie sich die IP für die Instanz auf der Seite VM-Instanzen an oder verwenden Sie den folgenden gcloud CLI-Befehl:

gcloud compute instances list

Fehlerbehebung bei RDP auf VMs ohne direkten Internetzugriff

Wenn Sie eine Verbindung zu einer Windows-VM herstellen, die keine externe IP-Adresse hat, reagiert die RDP-Verbindung möglicherweise nicht mehr, wenn die Aufforderung Remoteverbindung sichern oder Remotesitzung konfigurieren angezeigt wird, und es kommt zu einer Zeitüberschreitung. Dieses Problem tritt häufig auf, wenn Sie über einen TCP-Weiterleitungstunnel für Identity-Aware Proxy (IAP) eine Verbindung zu einer VM herstellen, die keinen direkten ausgehenden Internetzugriff hat.

Während des TLS-Handshakes für die Authentifizierung auf Netzwerkebene validiert die Windows Cryptographic API (CAPI) das X.509-Zertifikat, das der RDP-Listener verwendet. Zur Validierung dieses Zertifikats sendet CAPI ausgehende HTTP-Anfragen an Endpunkte für Zertifikatssperrlisten (Certificate Revocation List, CRL), Online Certificate Status Protocol oder Windows Update. Da der TermService-Dienst und die Zertifikatsvalidierung im Systemkontext ausgeführt werden, werden systemweite WinHTTP-Proxy-Einstellungen anstelle von Proxy-Einstellungen auf Nutzerebene verwendet. Wenn die VM keine direkte ausgehende Internetroute oder WinHTTP-Proxy-Konfiguration hat, kommt es nach 15 bis 30 Sekunden zu einem Zeitüberschreitungsfehler bei diesen HTTP-Anfragen und die RDP-Verbindung schlägt fehl.

Um dieses Problem zu beheben, stellen Sie eine Verbindung zur SAC der Windows-VM her und verwenden Sie eine der folgenden Methoden, je nach Ihren Netzwerk- und Sicherheitsanforderungen:

Systemweiten HTTP-Proxy mit WinHTTP konfigurieren

Wenn Ihr Netzwerk ausgehenden Internettraffic über einen HTTP-Proxy weiterleitet, konfigurieren Sie den Proxy auf WinHTTP-Ebene, damit Anfragen zur Zertifikatsvalidierung auf Systemebene den Proxy verwenden:

  • Führen Sie den folgenden Befehl über eine Eingabeaufforderung mit erhöhten Rechten aus, um einen WinHTTP-Proxyserver direkt anzugeben:

    netsh winhttp set proxy PROXY_SERVER:PORT
    

    Ersetzen Sie Folgendes:

    • PROXY_SERVER: die IP-Adresse oder der Hostname Ihres HTTP-Proxyservers
    • PORT: die Portnummer für den HTTP-Proxyserver.
  • Wenn in Windows bereits ein Proxy auf Nutzerebene konfiguriert ist, können Sie die Einstellungen auf Nutzerebene auch in WinHTTP importieren. Führen Sie dazu den folgenden Befehl aus:

    netsh winhttp import proxy source=ie
    

Automatische Updates von Root-Zertifikaten deaktivieren

Wenn Ihre VM in einer isolierten Umgebung ohne ausgehenden Internet- oder HTTP-Proxy-Zugriff ausgeführt wird, deaktivieren Sie die automatischen Updates von Root-Zertifikaten, damit Windows Zertifikate nur mit lokal installierten Root-Zertifikaten validiert:

Registry

Führen Sie den folgenden Befehl über eine Eingabeaufforderung mit erhöhten Rechten oder eine SAC-PowerShell-Sitzung aus:

reg add "HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot" /v DisableRootAutoUpdate /t REG_DWORD /d 1 /f

Gruppenrichtlinien

Wenn Sie die VM mithilfe von Gruppenrichtlinien verwalten, führen Sie die folgenden Schritte aus:

  1. Öffnen Sie den Editor für lokale Gruppenrichtlinien, indem Sie den Befehl gpedit.msc ausführen.
  2. Gehen Sie zu Computerkonfiguration > Administrative Vorlagen > System > Internetkommunikationsverwaltung > Internetkommunikationseinstellungen.
  3. Setzen Sie Automatische Aktualisierung von Root-Zertifikaten deaktivieren auf Aktiviert.
  4. Optional: Wenn die Verbindungsverzögerungen weiterhin bestehen, weil ein benutzerdefiniertes Zertifikat CRL- oder Authority Information Access-Endpunkte enthält, reduzieren Sie das Zeitlimit für den CAPI-Netzwerkabruf:
    1. Gehen Sie im Editor für lokale Gruppenrichtlinien zu Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Richtlinien für öffentliche Schlüssel.
    2. Öffnen Sie die Validierungseinstellungen für den Zertifikatspfad und wählen Sie den Tab Netzwerkabruf aus.
    3. Wählen Sie Diese Richtlinieneinstellungen definieren aus und legen Sie für beide Zeitüberschreitungswerte für den Abruf 1 Sekunde fest.
  5. Führen Sie den Befehl gpupdate /force über eine Eingabeaufforderung mit erhöhten Rechten aus, um die Änderungen zu übernehmen.

Ausgehenden Internetzugriff mit Cloud NAT konfigurieren

Wenn Ihre Sicherheitsanforderungen ausgehenden Internettraffic von der VM zulassen, richten Sie ein Cloud NAT-Gateway mit einer Standard-Internetroute 0.0.0.0/0 ein, damit die VM externe Endpunkte für die Zertifikatsvalidierung direkt erreichen kann.

Windows Remote Desktop Services (RDS) verwenden

Wenn auf Ihrer Instanz Windows Remote Desktop Services (vormals "Terminal Services") installiert ist, werden die Bedingungen der Client Access Licenses (CALs) erzwungen. Mit diesen CALs schlagen RDP-Verbindungen unter den folgenden Bedingungen fehl:

  • Sie haben alle verfügbaren Lizenzen verwendet.
  • Ihre Lizenz ist installiert, aber nicht korrekt konfiguriert oder aktiviert.
  • Ihr RDS-Testzeitraum von 180 Tagen ist abgelaufen

Zu den Symptomen, wenn nicht genügend gültige Lizenzen vorhanden sind, gehören beispielsweise folgende Nachrichten:

  • Die Verbindung zu dieser Remote-Sitzung wurde getrennt, da keine Remote Desktop-Lizenzserver verfügbar sind, um eine Lizenz bereitzustellen.
  • Die Verbindung zur Remote-Sitzung wurde aufgrund eines Lizenzierungsfehlers im Terminalserver getrennt.
  • Die Verbindung zur Remote-Sitzung wurde getrennt, da für diesen Computer keine Remote Desktop-CALs verfügbar sind.

Wenn Ihre RDP-Verbindungen fehlschlagen, können Sie den Administrator-Switch verwenden, um eine Verbindung zur Instanz für Verwaltungszwecke herzustellen. Dies kann auf einem Windows-Computer über den integrierten RDC-Client (Remote Desktop Connection) erfolgen.

%SystemRoot%\System32\mstsc.exe /admin

Im On-Demand-Image für Windows Server und SQL Server sind zwei gleichzeitige Remote Desktop-Sitzungen für die Verwaltung enthalten.

Erwerben Sie neue RDS-Lizenzen für Ihre Instanz, um Probleme mit RDP-Verbindungen zu beheben. Weitere Informationen zu CALs finden Sie in der Microsoft-Dokumentation. Wenn RDS nicht erforderlich ist, können Sie den Dienst auch deinstallieren und die regulären RDP-Verbindungen verwenden.

Konfiguration und Ressourcen auf Betriebssystemebene validieren

Wenn die Gastumgebung und die Konfigurationen für die Instanz korrekt sind, ist das Betriebssystem auf der Instanz möglicherweise falsch konfiguriert. Darüber hinaus ist es ohne ausreichende Ressourcen möglich, dass eine RDP-Verbindung nicht hergestellt werden kann. Stellen Sie eine Verbindung zum Windows SAC her, um die Konfiguration auf Betriebssystemebene zu prüfen:

Sichern, dass die VM über ausreichende Ressourcen verfügt

Prüfen Sie, dass CPU, Arbeitsspeicher, Laufwerksnutzung und verfügbarer Speicherplatz nicht an ihre Grenzen kommen. Um diese Daten zu prüfen, rufen Sie die Beobachtbarkeitsmesswerte in der Google Cloud Console auf. Einige Messwerte sind nur für VMs verfügbar, auf denen der Ops-Agent installiert ist. Ist der Ops-Agent nicht installiert, verwenden Sie folgende Befehle, wenn Sie mit SAC verbunden sind:

CPU-Auslastung, Arbeitsspeichernutzung, Laufwerksnutzung und Laufwerkskapazität

  • CPU-Nutzung:
    typeperf "\Processor(_Total)\% Processor Time" -sc 5
  • Arbeitsspeichernutzung:
    typeperf "\Memory\% Committed Bytes In Use" -sc 5
  • Laufwerknutzung:
    typeperf "\LogicalDisk(*)\% Idle Time" -sc 5
  • Laufwerkskapazität:
    fsutil volume diskfree C:

Im Folgenden werden die empfohlenen Ressourcennutzungen für RDP-Verbindungen aufgeführt. Diese sind jedoch nur Schätzungen und können zwischen Instanzen variieren.

  • CPU: < 80 %
  • Arbeitsspeicher: < 80 %
  • Speicherplatz: >20 %
  • Laufwerk inaktiv: > 50 %

Wenn eine der vorgeschlagenen Schätzungen ihre Grenzen erreicht, können Sie diese Ressource für die VM-Instanz ändern. Informationen zum Bearbeiten von VM-Attributen finden Sie unter Maschinentyp einer VM-Instanz bearbeiten und Größe eines nichtflüchtigen Speichers erhöhen.

Betriebssystemkonfiguration überprüfen

Stellen Sie eine Verbindung zur SAC der VM her und führen Sie die folgenden Befehle aus, um sicherzustellen, dass die Instanz Verbindungen akzeptiert:

  1. Überprüfen Sie, ob der Ethernet-Adapter aktiviert ist:

    • Befehl:
      netsh interface show interface
    • Erfolgreich: Der Administratorstatus ist für den Schnittstellennamen mit der Bezeichnung Ethernet auf Aktiviert gesetzt
    • Fehlgeschlagen: Der Administratorstatus ist für den Schnittstellennamen mit der Bezeichnung Ethernet auf Deaktiviert gesetzt
    • Lösung: Aktivieren Sie den Ethernet-Adapter:
      netsh interface set interface Ethernet admin=enabled
  2. Prüfen Sie, ob die Instanz eine gültige IP-Konfiguration hat:

    • Befehl:
      ipconfig /all
    • Erfolgreich: Der Ethernet-Adapter Ethernet zeigt eine IPv4-Adresse des Subnetzes an, dem die Instanz zugewiesen ist.
    • Fehlgeschlagen: Keine IPv4-Adresse oder eine Adresse, die nicht dem entspricht, was in der Google Cloud Console angezeigt wird.
    • Lösung: Fahren Sie mit dem nächsten Schritt fort.
  3. Prüfen Sie, ob DHCP für die Instanz aktiviert ist:

    • Befehl:
      netsh interface ipv4 show addresses
    • Bestanden: Ausgabe unter Ethernet enthält DHCP aktiviert: Ja.
    • Fehlgeschlagen: Die Ausgabe unter Ethernet enthält DHCP aktiviert: Nein.
    • Lösung: Aktivieren Sie DHCP auf dem Ethernet-Adapter:
      netsh interface ipv4 set address Ethernet dhcp
  4. Prüfen Sie, ob der "Remote Desktop-Dienst" ausgeführt wird:

    • Befehl:
      net start | find "Remote Desktop Services"
    • Erfolgreich: Remote Desktop-Dienst
    • Fehlgeschlagen: (Der Remote Desktop-Dienst fehlt in der Ausgabe)
    • Lösung: Starten Sie die Remote Desktop-Dienste:
      net start "Remote Desktop Services"
  5. Überprüfen Sie, ob Remoteverbindungen zugelassen sind:

    • Befehl:
      reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
    • Erfolgreich: fDenyTSConnections REG_DWORD 0x0
    • Fehlgeschlagen: fDenyTSConnections REG_DWORD 0x1
    • Lösung: Aktivieren Sie Remote Desktop-Verbindungen in der Registry:
      reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /f /v fDenyTSConnections /t REG_DWORD /d 0
  6. Prüfen Sie, ob in der Windows-Firewall Remote Desktop-Verbindungen zugelassen sind:

    • Befehl:
      netsh advfirewall firewall show rule name="Remote Desktop - User Mode (TCP-In)"
    • Erfolgreich: Zugelassen: Ja, Richtung: In, Profile: Öffentlich, Gruppierung: Remote Desktop, LocalIP: Egal, RemoteIP: Egal, Protokoll: TCP, LokalerAnschluss: 3389, Remote: Egal, Edge-Traversal: Nein, Aktion: Erlauben

    • Fehler: (unerwartete Ergebnisse, z. B. zugelassen = Nein)

    • Lösung: Aktivieren Sie die Standard-Firewallregel "Remote Desktop" in der Windows-Firewall:

      netsh advfirewall firewall set rule group="remote desktop" new enable=Yes

  7. Prüfen Sie, welche Portnummer für RDP-Verbindungen auf der Remote-Instanz konfiguriert ist:

    • Befehl:
      reg query "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
    • Erfolgreich: PortNumber REG_DWORD [PORT NUMBER]
    • Fehlgeschlagen: (unerwartete Portnummer)
    • Lösung: Konfigurieren Sie die Portnummer in der für RDP erforderlichen Registry:

      reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /f /v PortNumber /t REG_DWORD /d [PORT NUMBER]

  8. Vergewissern Sie sich, dass eine andere Anwendung nicht versucht, denselben Port zu verwenden:

    • Befehl:
      netstat -ano | find "3389"
    • Bestanden: Suchen Sie nach einem Eintrag für den zugewiesenen RDP-Port mit dem Status Überwachung. Der übereinstimmende Dienst kann mithilfe der Prozess-ID (PID) mit dem folgenden Befehl ermittelt werden:
      tasklist /svc | find ""
      , wobei PID die ID aus dem vorherigen Befehl ist. In der Ausgabe sollte nur Termservice zurückgegeben werden.
    • Fehlgeschlagen: Alles außer Termservice verwendet den zugewiesenen Port.
    • Lösung: Konfigurieren Sie die Anwendung oder den Dienst für die Verwendung einer anderen Portnummer.
  9. Überprüfen Sie, ob Remoteverbindungen für das verbundene Nutzerkonto zugelassen sind:

    • Befehl:
      net localgroup "Remote Desktop Users"
    • Erfolgreich: (lokaler Ziel- oder Domainnutzername in der Ergebnisliste)
    • Fehlgeschlagen: (lokaler Ziel-/Domainnutzername fehlt)
    • Lösung: Fügen Sie einem Nutzer in der Domain die Regel "Remote Desktop-Nutzer" hinzu:

      net localgroup "Remote Desktop Users" /add [DOMAIN\USERNAME]

      Die Domain ist nur für Nutzerkonten auf einem System erforderlich, das mit einer anderen Domain verbunden ist. Geben Sie für lokale Konten nur den Nutzernamen an.

  10. Prüfen Sie, ob die Sicherheitsverhandlung von Clients und Servern auf den Standardwert festgelegt ist:

    • Befehl:
      reg query "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer
    • Erfolgreich: SecurityLayer REG_DWORD 0x1
    • Fehlgeschlagen: SecurityLayer REG_DWORD 0x0 (or 0x2)
    • Lösung: Legen Sie den Wert der Sicherheitsverhandlung in der Registry fest:
      reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 1 /f
  11. Wenn die Instanz mit einer Active Directory-Domain verbunden ist, die Verbindung jedoch nicht hergestellt werden konnte, wird beim Zugriff auf die Instanz möglicherweise folgender Fehler angezeigt:

    The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA.
    

    Prüfen Sie, ob die NLA (Network Level Authentication) auf den Standardwert eingestellt ist:

    • Befehl:
      reg query "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
    • Erfolgreich: UserAuthentication REG_DWORD 0x0
    • Fehlgeschlagen: UserAuthentication REG_DWORD 0x1
    • Lösung: Legen Sie den Wert für die Authentifizierung auf Netzwerkebene in der Registry fest:
      reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f
  12. Achten Sie darauf, dass Ihre MTU-Größe nicht größer als die MTU des Netzwerks ist:

    • Befehl:
      netsh interface ipv4 show subinterfaces
    • Erfolgreich: wenn die Zahl nach der MTU mit der MTU des VPC-Netzwerks übereinstimmt
    • Fehlgeschlagen: wenn die Zahl nach der MTU größer ist als die MTU des VPC-Netzwerks
    • Lösung: Legen Sie die MTU der Schnittstelle auf die MTU des VPC-Netzwerks fest:

      netsh interface ipv4 set subinterface Ethernet mtu=MTU_OF_VPC_NETWORK

      Weitere Informationen zu MTU-Größeninkompatibilitäten finden Sie in der Dokumentation zur Paketfragmentierung.

  13. Wenn Sie versuchen, über RDP eine Verbindung zur VM herzustellen und auf der VM der Bildschirm des Tastaturlayouts angezeigt wird, müssen Sie durch Herstellen einer Verbindung zum Windows SAC eine Sprache auswählen. Führen Sie die folgenden Schritte aus, um eine Sprache auszuwählen:

    1. Verbindung zur SAC herstellen.
    2. Öffnen Sie Powershell; dazu geben Sie powershell ein.
    3. Ermitteln Sie den richtigen Sprachstring.

      Get-WinUserLanguageList
    4. Legen Sie das Layout fest. Ersetzen Sie LANGUAGE_TAG durch das gewünschte Sprachlayout (z. B. en-US).

      Set-WinUserLanguageList -LanguageList LANGUAGE_TAG -force
    5. Starten Sie Ihre Instanz neu.

      shutdown -r -t 0
  14. Bei RDP-Fehlern auf dem Anmeldebildschirm, der you need the right to sign in through Remote Desktop Services oder you must be granted the Allow log on through Terminal Services right referiert, wurde die Gruppe "Remote Desktop-Nutzer oder Administratoren" aus der Einstellung "Lokale Computerrichtlinie" entfernt, die sich unter Anmeldung über Remote Desktop-Dienste zulassen oder SeRemoteInteractiveLogonRight findet.

  15. Prüfen Sie, ob die Authentifizierung von Zertifikaten durch fehlende Berechtigungen blockiert wird:

    • Befehl:
      icacls.exe "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys"
    • Erfolgreich: Die Ausgabe sieht etwa so aus: Everyone:(R,W) BUILTIN\Administrators:(F)
    • Fehlgeschlagen: Die Ausgabe sieht nicht wie Everyone:(R,W) BUILTIN\Administrators:(F) aus
  16. Prüfen Sie, ob Ihre Antiviren- oder Endpunktschutz-Clienteinstellungen die konfigurierte Portnummer und die konfigurierten Dienste zulassen.

  17. CredSSP-Verschlüsselungs-Oracle-Fehlerbehebung: Wenn Sie einen Fehler erhalten, der „CredSSP-Verschlüsselungs-Oracle-Fehlerbehebung“ erwähnt, prüfen Sie, ob auf Ihrer Workstation und der VM-Instanz die neuesten Windows-Updates installiert sind.

  18. Interner Fehlercode 0x4: Wenn die Verbindung mit dem Fehlercode 0x4 fehlschlägt, prüfen Sie, ob TLS 1.2 auf dem Server aktiviert ist. Sie können die Registry unter HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client prüfen.

  19. Fehlercode 0x108: Wenn Sie die Fehlermeldung „Fehlercode: 0x108 (Die beiden Computer konnten innerhalb der vorgegebenen Zeit keine Verbindung herstellen)“ erhalten, prüfen Sie die Beobachtbarkeitsmesswerte auf eine hohe CPU- oder Arbeitsspeicherauslastung. Wenn die Ressourcen erschöpft sind, sollten Sie den Maschinentyp ändern.

Zeitlimits von Sitzungen überprüfen

Wenn Sie eine RDP-Verbindung herstellen können, die Verbindung aber nach einiger Zeit mit der Meldung Timer abgelaufen getrennt wird, prüfen Sie, ob folgende Werte wie erwartet sind:

Registry-Pfad: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Registry-Schlüssel:

  • MaxDisconnectionTime
  • MaxIdleTime
  • MaxConnectionTime
  • MaxDisconnectionTime
  • RemoteAppLogoffTimeLimit

Diese Werte werden in Millisekunden festgelegt. Wenn diese Schlüssel in Ihrer Registry fehlen, gibt es keine Sitzungslimits für Ihre VM-Instanz. Wenn diese Schlüssel in Ihrer Registry vorhanden sind, ihre Werte aber auf 0 gesetzt sind, läuft Ihre Sitzung nie ab.

Fehlerbehebung beim Windows-Start

Wenn das Problem mit der RDP-Verbindung durch die vorherigen Schritte zur Fehlerbehebung nicht behoben wurde, wird Ihre Windows-Instanz möglicherweise nicht richtig gestartet oder ausgeführt. In diesem Fall finden Sie weitere Informationen in unserem Leitfaden zur Fehlerbehebung unter Windows.

Nächste Schritte