Windows WorkSpace が Unhealthy 状態になっている場合のトラブルシューティング方法を教えてください。

簡単な説明

WorkSpaces は定期的に各 WorkSpace にヘルスステータスリクエストを送信して WorkSpace の状態を確認します。WorkSpaces が WorkSpace から応答を受け取らなかった場合、WorkSpace のステータスは Unhealthy に変わります。

次の問題が原因で、ステータスが Unhealthy に変わる場合があります。

• WorkSpace の CPU 使用率が常時高くなっている。
• WorkSpaces に応答するエージェントまたはサービスが実行されていないか、管理インターフェイス (ETH0) が無効になっている。
• Amazon DCV または PCoIP サービスが実行されていない。
• ウイルス対策ソフトウェアが WorkSpaces コンポーネントをブロックしている。
• WorkSpace 上のアプリケーションまたはグループポリシーが、管理インターフェイス上の WorkSpace と WorkSpace 間のネットワーク接続をブロックしている。
• メタデータのルートが欠けている。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

CloudWatch メトリクスを使用して WorkSpaces を確認する

Amazon CloudWatch の WorkSpaces メトリクス CPUUsage、MemoryUsage、Unhealthy を確認すると、原因の判断に役立ちます。

WorkSpace を再起動する

WorkSpace を再起動します。再起動しても問題が解決しない場合は、Remote Desktop Protocol (RDP) を使用して WorkSpace に接続します。

RDP を使用して WorkSpace に接続できない場合は、「Amazon Elastic Compute Cloud (Amazon EC2) Windows インスタンスの RDP 接続に関する問題をトラブルシューティングする方法を教えてください」を参照してください。 それでも RDP で WorkSpace に接続できない場合は、「WorkSpace を復元または再構築する」セクションを参照してください。

または、AWS CLI コマンド reboot-workspaces を実行してもかまいません。

CPU 使用率が高くなっているかどうか確認する

Amazon EC2 インスタンスの CPU 使用率が高くなっているかどうかを確認します。

管理インターフェイスと顧客インターフェイスが実行中であることを確認する

管理インターフェイスと顧客インターフェイスの IP アドレスを特定するには、次のコマンドを実行します。

ipconfig /all

管理インターフェイスと顧客インターフェイスの状態を確認するには、次のコマンドを実行します。

netsh interface show interface

インターフェイスが Connected 状態でない場合は、次のコマンドを実行してインターフェイスをアクティブにします。

netsh interface set interface "interface-name" enable

注: interface-name は、お使いのインターフェイス名に置き換えます。

WorkSpaces サービスが実行中であり、応答していることを確認する

サービスのステータスを確認するには、次の手順を実行します。

1. RDP を使用して WorkSpace に接続します。
2. [スタート] メニューを選択し、Services (サービス) と入力します。
3. [サービス] タブを選択します。
4. WorkSpace の各サービスのステータスを確認します。
   PCoIP WorkSpace:
   SkylightWorkSpacesConfigService
   PCoIP Standard Agent for Windows
   DCV WorkSpace:
   SkylightWorkSpacesConfigService
   WSP Adapter for DC
   DCV Server
5. サービスが Running 状態ではない場合は、コンテキストメニューを開き、そのサービスを選択します。
   注: サービスの [開始タイプ] が [自動] に設定されていることを確認します。
6. [開始] を選択します。

WorkSpaces の設定を確認する

ウイルス対策ソフトウェアやマルウェア対策ソフトウェアなどのエンドポイント保護ソフトウェアが、WorkSpaces サービスコンポーネントを許可していることを確認します。PCoIP WorkSpaces で WorkSpaces Web Access が有効になっている場合は、STXHD Hosted Application Service が実行中であり、**[開始タイプ]**が [自動] であることを確認します。

注: WorkSpaces Web Access を使用していない場合は、STXHD エージェントを無効にします。

さらに、アプリケーションまたは VPN が管理アダプターをブロックしていないことを確認します。次に、WorkSpace の接続を確認します。

Skylight 証明書が証明書ストアにあるかどうかを確認するには、ローカルコンピュータで certmgr.msc を開きます。証明書は Skylight フォルダにあります。

グループポリシーが管理インターフェイスまたは必要な WorkSpaces サービス上の通信をブロックしているかどうかを確認するには、次の手順を実行します。

1. RDP を使用して WorkSpace に接続します。

2. コマンドプロンプトを起動し、次のコマンドを実行して policy.html ファイルを作成します。

   gpresult /h policy.html

3. policy.html ドキュメントを開き、ネットワークインターフェイスまたは WorkSpaces サービスへの通信をブロックしているポリシーを検索します。

4. ブロックポリシーを特定した場合は、WorkSpace コンピュータオブジェクトを Microsoft Active Directory 内の別の組織単位 (OU) に移動します。オブジェクトの [ブロック継承] 設定を使用します。ブロック継承の使用方法の詳細については、Microsoft のウェブサイトで「グループ ポリシーの上書きとブロック」を参照してください。

5. WorkSpace を再起動します。

ファイアウォールのルールを確認する

ファイアウォールは、管理ネットワークインターフェイスに対し、リストされているトラフィックを許可する必要があります。さらに、オペレーティングシステム (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 を復元または再構築する

RDP を使用して WorkSpace に接続できない場合は、WorkSpace を復元して最新のスナップショットにロールバックします。それでも WorkSpace が正常でない場合は、WorkSpace を再構築してください。

WorkSpace を復元または再構築するには、AWS Systems Manager の AWSSupport-RecoverWorkSpace ランブックを使用するのがベストプラクティスです。

重要: WorkSpace を復元または再構築すると、データが失われる可能性があります。復元を行うと、WorkSpace は 過去 12 時間以内の、使用可能な最新のスナップショットから復元されます。再構築では、最新のスナップショットからユーザーボリュームを再作成し、WorkSpace を作成したバンドルのイメージから WorkSpace を再作成します。WorkSpace の作成後にインストールしたアプリケーションや、変更したシステム設定は失われます。

オートメーションを実行する前に、AWS Identity and Access Management (IAM) ユーザーまたはロールに必要なアクセス許可があることを確認してください。詳細については、AWSSupport-RecoverWorkSpace の「必要な IAM アクセス許可」セクションを参照してください。

ランブックを実行するには、次の手順を実行します。

1. AWSSupport-RecoverWorkSpace ランブックを開きます。
2. [オートメーションの実行] を選択します。
3. 入力パラメータには、次の値を入力します。
   (オプション) AutomationAssumeRole に、オートメーションによるアクションの実行を許可する IAM ロールの Amazon リソースネーム (ARN) を入力します。ロールを指定しない場合、オートメーションはランブックを起動したユーザーのアクセス許可を使用します。
   [確認] に Yes と入力し、復元アクションと再構築アクションによって WorkSpace が最新のスナップショットから復元されることを受諾します。
   [再起動]、[再構築]、[復元] のいずれかで、希望するオプションで [Yes] を選択します。
   WorkspaceId に復元する WorkSpace の ID を入力します。
4. [実行] を選択します。
5. ランブックの [出力] セクションで WorkSpace のステータスを確認します。

AWS CLI コマンド restore-workspace または rebuild-workspaces を実行することもできます。

上記のトラブルシューティング手順で問題が解決しない場合は、クライアント側のログを収集して AWS サポートケースを開始してください。

関連情報

WorkSpaces Personal での IP アドレスとポートの要件

WorkSpaces Personal のユーザーに対し、セルフサービスの WorkSpaces 管理機能を有効にする

Linux WorkSpace が Unhealthy 状態になっている場合のトラブルシューティング方法を教えてください