如何对状态为“不正常”的 Windows WorkSpace 进行故障排除?
我的 Amazon WorkSpaces Windows WorkSpace 的状态为“不正常”。
简短描述
WorkSpaces 定期向每个 WorkSpace 发送运行状态请求,以检查 WorkSpace 的运行状况。如果 WorkSpaces 未收到 WorkSpace 的响应,则该 WorkSpace 的状态将更改为 Unhealthy(不正常)。
以下问题可能导致状态更改为 Unhealthy(不正常):
- WorkSpace 的 CPU 使用率始终较高。
- 用于响应 WorkSpaces 的代理或服务当前未运行,或者管理接口 (ETH0) 已关闭。
- Amazon DCV 或 PCoIP 服务当前未运行。
- 防病毒软件正在阻止 WorkSpaces 组件。
- WorkSpace 上的应用程序或组策略在管理接口阻止 WorkSpaces 与 WorkSpace 之间的网络连接。
- 缺少元数据路由。
- WorkSpace 计算机名称已更改。
解决方法
使用 CloudWatch 指标查看您的 WorkSpaces
为了帮助您确定原因,请查看 Amazon CloudWatch 中的 CPUUsage、MemoryUsage 和 Unhealthy WorkSpaces 指标。
重启 WorkSpace
重启 WorkSpace。如果重启无法解决问题,请使用远程桌面协议 (RDP) 连接到 WorkSpace。
如果无法使用 RDP 连接到 WorkSpace,请参阅如何对 Amazon Elastic Cloud Compute (Amazon EC2) Windows 实例的 RDP 连接问题进行故障排除?如果仍然无法使用 RDP 连接到 WorkSpace,请参阅“恢复或重建 WorkSpace”部分。
检查 CPU 利用率是否较高
检查 Amazon EC2 实例的 CPU 利用率是否较高。或者,使用 Windows 任务管理器识别导致 CPU 利用率较高的进程。
检查管理接口和客户接口是否正在运行
要识别管理接口和客户接口 IP 地址,请运行以下命令:
ipconfig /all
要显示管理接口和客户接口的状态,请运行以下命令:
netsh interface show interface
如果接口未处于 Connected(已连接)状态,请运行以下命令来激活该接口:
netsh interface set interface "interface-name" enable
**注意:**将 interface-name 替换为您的接口名称。
确认 WorkSpaces 服务正在运行且能够响应
使用 RDP 连接到 WorkSpace。然后,完成以下步骤以检查服务状态:
- 选择 Start(开始)菜单,然后输入 Services(服务)。
- 选择 Services(服务)选项卡。
- 检查 WorkSpace 每项服务的状态。
PCoIP WorkSpace:
SkylightWorkSpacesConfigService
适用于 Windows 的 PCoIP Standard Agent
DCV WorkSpace:
SkylightWorkSpacesConfigService
适用于 DC 的 WSP Adapter
DCV 服务器 - 如果服务未处于 Running(正在运行)状态,请打开该服务的上下文菜单(右键单击)。然后,选择 Start(启动)。
**注意:**确保将该服务的 Start type(启动类型)设置为 Automatic(自动)。
验证您的 WorkSpaces 配置
确认端点保护软件(例如防病毒软件或反恶意软件)允许 WorkSpaces 服务组件。如果为 PCoIP WorkSpaces 启用了 WorkSpaces Web Access(WorkSpaces Web 访问权限),请验证 STXHD Hosted Application Service(STXHD 托管应用程序服务)的状态是否为 Running(正在运行),以及 Start type(启动类型)是否为 Automatic(自动)。
注意: 如果您没有使用 WorkSpaces Web 访问权限,请关闭 STXHD 代理。
此外,确认应用程序或 VPN 不会阻止您的管理适配器。然后,检查您的 WorkSpace 连接。
要检查 Skylight 证书是否在您的证书存储库中,请在本地计算机上打开 certmgr.msc。该证书位于 Skylight 文件夹中。
要验证组策略是否正在阻止管理接口或所需的 WorkSpaces 服务上的通信,请完成以下步骤:
-
启动命令提示符,然后运行以下命令以创建可以在任何浏览器中打开的 policy.html 文件:
gpresult /h policy.html
-
打开 policy.html 文档,然后搜索是否存在阻止与网络接口或 WorkSpaces 服务通信的策略。
-
如果识别到阻止策略,请将 WorkSpace 计算机对象移至 Microsoft Active Directory 中的单独组织单位 (OU)。对对象使用块继承设置。有关如何使用块继承的详细信息,请参阅 Microsoft 网站上的覆盖和阻止组策略。
验证防火墙规则
防火墙必须允许管理网络接口上列出的流量。此外,验证操作系统 (OS) 防火墙或第三方防火墙是否具有允许所需端口的规则。
检查元数据路径是否丢失
要检查所需的全部元数据路由是否都位于您的 WorkSpace 中,请运行以下 Windows PowerShell 命令:
Get-NetRoute
如果缺少元数据路由,则运行以下脚本将其添加到您的 WorkSpace:
$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 }
添加缺失的元数据路由后,重启 WorkSpace。
确认 WorkSpace 的计算机名称未更改
完成下面的步骤:
- 打开 WorkSpaces 控制台。
- 展开不正常的 WorkSpace 以显示详细信息。
- 记下 Computer name(计算机名称)的值。
- 使用 RDP 连接到 WorkSpace。
- 要查看当前计算机名称,请打开命令提示符,然后输入主机名。
- 如果输出中的名称与 Computer name(计算机名称)的值不匹配,则必须将该名称改回原来的名称。
- 选择 Start(开始)菜单,然后键入 sysdm.cpl。
- 选择 Change(更改),然后输入 Computer name(计算机名称)的值。
- 选择 OK(确定)。
- 如果出现提示,请输入您用于将 WorkSpace 加入域的 AWS 服务账户的凭证。
- 重启 WorkSpace。
恢复或重建 WorkSpace
如果您无法使用 RDP 连接到 WorkSpace,请恢复 WorkSpace 以回滚到最新快照。如果 WorkSpace 仍然不正常,请重建 WorkSpace。
要恢复或重建 WorkSpace,最佳做法是使用 AWS 系统管理器 AWSSupport-RecoverWorkSpace 运行手册。
**重要事项:**恢复或重建 WorkSpace 时,数据可能会丢失。WorkSpace 将从最长 12 小时之前的最后一个可用快照中进行恢复。Rebuild 将使用最新的快照重新创建用户卷,并通过您从中创建 WorkSpace 的捆绑包的映像重新创建 WorkSpace。创建 WorkSpace 后安装的应用程序或更改的系统设置将丢失。
在运行自动化之前,请确保您的 AWS Identity and Access Management (IAM) 用户或角色具有所需的权限。有关详细信息,请参阅 AWSSupport-RecoverWorkSpace 的“所需的 IAM 权限”部分。
要运行运行手册,请完成以下步骤:
- 打开 AWSSupport-RecoverWorkSpace 运行手册。
- 选择 Execute automation(执行自动化)。
- 对于输入参数,输入以下值:
(可选)对于 AutomationAssumeRole,输入允许自动化代您执行操作的 IAM 角色的 ARN。如果您未指定角色,则自动化将使用启动运行手册的用户的权限。
在 Acknowledge(确认)中,输入 Yes(是)以确认“恢复和重建”操作可以从最新的快照中恢复 WorkSpace。
对于 Reboot(重启)、Rebuild(重建)或 Restore(恢复),选择 Yes(是)作为首选选项。
在 WorkspaceId 中,输入要恢复的 WorkSpace 的 ID。 - 选择 Execute(执行)。
有关运行手册所执行步骤的列表,请参阅 AWSSupport-RecoverWorkSpace 的“文档步骤”部分。 - 在运行手册的“输出”部分中检查 Workspace 的状态。
您还可以使用 AWS 命令行界面 (AWS CLI) 来重启、恢复以及重建 WorkSpace。
**注意:**如果在运行 AWS CLI 命令时收到错误,请参阅 AWS CLI 错误故障排除。此外,请确保您使用的是最新版本的 AWS CLI。
如果上述故障排除步骤均无法解决您的问题,请收集客户端日志并提交 AWS Support 案例。
相关信息
WorkSpaces Personal 的 IP 地址和端口要求

相关内容
- AWS 官方已更新 5 个月前
- AWS 官方已更新 4 个月前
- AWS 官方已更新 4 个月前
- AWS 官方已更新 3 年前