Direkt zum Inhalt

Wie behebe ich ein Problem mit einem Windows WorkSpace, der sich im Status „Fehlerhaft“ befindet?

Lesedauer: 7 Minute
0

Der Status meines Amazon WorkSpaces Windows WorkSpace ist „Fehlerhaft“.

Kurzbeschreibung

WorkSpaces sendet regelmäßig eine Anfrage zum Zustandsstatus an jeden WorkSpace, um den Zustand des WorkSpace zu überprüfen. Wenn WorkSpaces keine Antwort vom WorkSpace erhält, ändert sich der WorkSpace-Status in Fehlerhaft.

Die folgenden Probleme können dazu führen, dass der Status in Fehlerhaft geändert wird:

  • Der WorkSpace hat eine konstant hohe CPU-Auslastung.
  • Der Agent oder Service, der auf WorkSpaces reagiert, läuft nicht oder die Verwaltungsschnittstelle (ETH0) ist ausgeschaltet.
  • Ein Amazon DCV- oder PCoIP-Service läuft nicht.
  • Antivirensoftware blockiert WorkSpaces-Komponenten.
  • Eine Anwendung oder Gruppenrichtlinie auf dem WorkSpace blockiert die Netzwerkverbindung zwischen WorkSpaces und WorkSpace auf der Verwaltungsschnittstelle.
  • Metadaten-Routen fehlen.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

CloudWatch-Metriken verwenden, um die WorkSpaces zu überprüfen

Um die Ursache zu ermitteln, überprüfe die Metriken CPUUsage, MemoryUsage und Fehlerhaft WorkSpaces in Amazon CloudWatch.

WorkSpace neu starten

Starte den WorkSpace neu. Wenn ein Neustart das Problem nicht behebt, verwende Remote Desktop Protocol (RDP), um eine Verbindung zum WorkSpace herzustellen.

Wenn du RDP nicht verwenden kannst, um eine Verbindung zum WorkSpace herzustellen, findest du weitere Informationen unter Wie behebe ich RDP-Verbindungsprobleme mit meiner Amazon Elastic Compute Cloud (Amazon EC2)-Windows-Instance? Wenn du mit RDP immer noch keine Verbindung zum WorkSpace herstellen kannst, liest du den Abschnitt WorkSpace wiederherstellen oder neu erstellen.

Du kannst auch den AWS-CLI-Befehl reboot-workspaces ausführen.

Auf hohe CPU-Auslastung prüfen

Überprüfe die Amazon EC2-Instance auf eine hohe CPU-Auslastung.

Prüfen, ob die Management- und Kundenschnittstellen funktionieren

Führe den folgenden Befehl aus, um die Verwaltungs- und Kundenschnittstellen-IP-Adressen zu identifizieren:

ipconfig /all

Führe den folgenden Befehl aus, um den Status der Management- und Kundenschnittstellen anzuzeigen:

netsh interface show interface

Wenn sich eine Schnittstelle nicht im Status Verbunden befindet, führe den folgenden Befehl aus, um die Schnittstelle zu aktivieren:

netsh interface set interface "interface-name" enable

Hinweis: Ersetze den interface-name durch den Schnittstellennamen.

Bestätigen, dass die WorkSpaces-Services ausgeführt werden und reagieren

 Gehe wie folgt vor, um den Status des Services zu überprüfen:

  1. Verwende RDP, um eine Verbindung zum WorkSpace herzustellen.
  2. Wähle das MenüStart und gib dann Service ein.
  3. Wähle die Registerkarte Services.
  4. Überprüfe den Status jedes Service für deinen WorkSpace:
    PCoIP-WorkSpaces:
    Skylight Workspaces ConfigService
    PCoIP Standard Agent für Windows
    DCV-WorkSpaces:
    Skylight Workspaces ConfigService
    WSP-Adapter für Gleichstrom
    DCV-Server
  5. Wenn sich ein Service nicht im Status Wird ausgeführt befindet, öffne das Kontextmenü und wähle den Service aus. 
    Hinweis: Stelle sicher, dass der Start-Typ für den Service auf Automatisch gesetzt ist.
  6. Wähle Start.

WorkSpaces-Konfiguration überprüfen

Stelle sicher, dass Endpunktschutzsoftware, wie z. B. Antiviren- oder Anti-Malware-Software, die WorkSpaces-Servicekomponenten zulässt. Wenn du WorkSpaces Web Access für PCoIP WorkSpaces aktiviert hast, stelle sicher, dass der STXHD Hosted Application Service ausgeführt wird und der Start-Typ Automatisch ist.

Hinweis: Wenn du WorkSpaces Web Access nicht verwendest, schalte den STXHD-Agent aus.

Stelle außerdem sicher, dass eine Anwendung oder ein VPN den Management-Adapter nicht blockiert. Überprüfe dann die WorkSpace-Konnektivität.

Um zu überprüfen, ob sich das Skylight-Zertifikat in dem Zertifikatsspeicher befindet, öffne certmgr.msc auf dem lokalen Computer. Das Zertifikat befindet sich im Skylight-Ordner.

Gehe wie folgt vor, um zu überprüfen, ob eine Gruppenrichtlinie die Kommunikation auf der Verwaltungsschnittstelle oder einem erforderlichen WorkSpaces-Service blockiert:

  1. Verwende RDP, um eine Verbindung zum WorkSpace herzustellen.

  2. Starte die Eingabeaufforderung und führe dann den folgenden Befehl aus, um eine Datei policy.html zu erstellen:

    gpresult /h policy.html
  3. Öffne das Dokument policy.html und suche dann nach Richtlinien, die die Kommunikation mit Netzwerkschnittstellen oder WorkSpaces-Services blockieren.

  4. Wenn du eine Blockierungsrichtlinie identifizierst, verschiebe das Workspace-Computerobjekt in eine separate Organisationseinheit (OU) in Microsoft Active Directory. Verwende die Einstellung Vererbung blockieren für das Objekt. Weitere Informationen zur Verwendung der Vererbung blockieren findest du auf der Microsoft-Website unter Überschreiben und Blockieren von Gruppenrichtlinien.

  5. Starte den WorkSpace neu.

Firewallregeln verifizieren

Die Firewall muss den aufgelisteten Datenverkehr auf der Verwaltungsnetzwerkschnittstelle zulassen. Stelle außerdem sicher, dass die Betriebssystem-Firewall (OS) oder die Firewall eines Drittanbieters über Regeln verfügt, die die erforderlichen Ports zulassen.

Prüfen, ob die Metadaten-Routen fehlen

Führe den folgenden Windows PowerShell-Befehl aus, um zu überprüfen, ob sich alle erforderlichen Metadatenrouten im WorkSpace befinden:

Get-NetRoute

Wenn eine Metadaten-Route fehlt, führe das folgende Skript aus, um sie zum WorkSpace hinzuzufügen:

$mgmtIp = (Get-ItemProperty "hklm:\software\Amazon\SkyLight\ConfigurationData").ManagementIp
$mgmtGW = (Get-WmiObject win32_networkAdapterConfiguration | where IPAddress -eq $mgmtIp |select DefaultIPGateway).DefaultIPGateway

if($mgmtGW){

route delete 169.254.169.123
route delete 169.254.169.249
route delete 169.254.169.250
route delete 169.254.169.251
route delete 169.254.169.252
route delete 169.254.169.253
route delete 169.254.169.254

route -P add 169.254.169.249 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.250 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.251 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.252 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.253 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.254 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.123 MASK 255.255.255.255 $mgmtGW METRIC 1000

}

Nachdem du die fehlende Metadatenroute hinzugefügt haben, starte den WorkSpace neu.

Den WorkSpace wiederherstellen oder neu erstellen

Wenn du RDP nicht verwenden kannst, um eine Verbindung zum WorkSpace herzustellen, stelle den WorkSpace wieder her, um auf den neuesten Snapshot zurückzusetzen. Wenn der WorkSpace immer noch fehlerhaft ist, erstelle den WorkSpace neu.

Um den WorkSpace wiederherzustellen oder neu aufzubauen, empfiehlt es sich, das AWS Systems Manager AWSSupport-RecoverWorkspace-Runbook zu verwenden.

Wichtig: Wenn du einen WorkSpace wiederherstellst oder neu erstellst, kann es zu Datenverlust kommen. Bei der Wiederherstellung wird der WorkSpace aus dem letzten verfügbaren Snapshot wiederhergestellt, der bis zu 12 Stunden alt ist. Bei der Neuerstellung wird das Benutzer-Volume aus dem neuesten Snapshot und der WorkSpace aus dem Image des Pakets, aus dem du den WorkSpace erstellt hast, neu erstellt. Du verlierst Anwendungen, die du installiert hast, oder Systemeinstellungen, die du nach der Erstellung des WorkSpace geändert hast.

Bevor du die Automatisierung ausführst, stelle sicher, dass dein AWS Identity and Access Management (IAM)-Benutzer oder deine -Rolle über die erforderlichen Berechtigungen verfügt. Weitere Informationen findest du im Abschnitt Erforderliche IAM-Berechtigungen von AWSSupport-RecoverWorkSpace.

Gehe wie folgt vor, um das Runbook auszuführen:

  1. Öffne das AWSSupport-RecoverWorkspace-Runbook.
  2. Wähle Automatisierung ausführen aus.
  3. Geben Sie für die Eingabeparameter die folgenden Werte ein:
    (Optional) Gib für AutomationAssumeRole den Amazon-Ressourcennamen (ARN) der IAM-Rolle ein, die es der Automation ermöglicht, Aktionen auszuführen. Wenn du keine IAM-Rolle angibst, verwendet die Automatisierung die Berechtigungen des Benutzers, die das Runbook startet.
    Gib für Bestätigen Ja ein, um zu bestätigen, dass mit den Aktionen „Wiederherstellen“und „Neu erstellen“ der WorkSpace aus dem letzten Snapshot wiederhergestellt wird.
    Wähle für Neustart, Wiederherstellen oder Neu erstellen die Option Ja als die bevorzugte Option.
    Gib für WorkspaceID die ID des Workspace ein, den du wiederherstellst.
  4. Wähle Ausführen.
  5. Überprüfe den Status deines Workspace im Abschnitt Ausgabe des Runbooks.

Du kannst auch die AWS-CLI-Befehle restore-workspace oder ](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/workspaces/rebuild-workspaces.html)rebuild-workspaces[ ausführen.

Wenn keiner der vorherigen Schritte zur Fehlerbehebung das Problem löst, erfasse die clientseitigen Protokolle und öffne einen AWS Support-Fall.

Ähnliche Informationen

Anforderungen an IP-Adresse und Port für WorkSpaces Personal

Aktiviere die Verwaltungsfunktionen für Self-Service-WorkSpaces für den Benutzer in WorkSpaces Personal

Wie behebe ich Fehler in einem Linux WorkSpace, der sich im Status „Fehlerhaft“ befindet?

AWS OFFICIALAktualisiert vor 8 Monaten