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

所要時間3分

Amazon WorkSpaces Windows WorkSpace のステータスが Unhealthy になっています。

簡単な説明

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

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

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

解決策

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

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

WorkSpace を再起動する

WorkSpace を再起動します。再起動しても問題が解決しない場合は、Remote Desktop Protocol (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 に接続します。次に、次の手順を実行してサービスのステータスを確認します。

[スタート] メニューを選択し、Services (サービス) と入力します。
[サービス] タブを選択します。
WorkSpace の各サービスのステータスを確認します。
PCoIP WorkSpace:
SkylightWorkSpacesConfigService
PCoIP Standard Agent for Windows
DCV WorkSpace:
SkylightWorkSpacesConfigService
WSP Adapter for DC
DCV Server
Running ではないサービスがある場合は、そのサービスのコンテキストメニュー (右クリック) を開きます。次に、[開始] を選択します。
注: サービスの [開始タイプ] が [自動] に設定されていることを確認します。

WorkSpaces の設定を確認する

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

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

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

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

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

RDP を使用して WorkSpace に接続します。
コマンドプロンプトを起動し、次のコマンドを実行して policy.html ファイルを作成します。このファイルは、任意のブラウザで開くことができます。
```
gpresult /h policy.html
```
policy.html ドキュメントを開き、ネットワークインターフェイスまたは WorkSpaces サービスへの通信をブロックしているポリシーを検索します。
ブロックポリシーを特定した場合は、WorkSpace コンピュータオブジェクトを Microsoft Active Directory 内の別の組織単位 (OU) に移動します。オブジェクトの [ブロック継承] 設定を使用します。ブロック継承の使用方法の詳細については、Microsoft のウェブサイトで「グループポリシーの上書きとブロック」を参照してください。
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 のコンピューター名が変更されていないことを確認する

次の手順を実行します。

Workspace コンソールを開きます。
正常ではないWorkSpaceを展開して詳細を表示します。
[コンピュータ名] の値を書き留めておきます。
RDP を使用して WorkSpace に接続します。
現在のコンピュータ名を確認するには、コマンドプロンプトを開いて、hostname と入力します。
出力の名前が [コンピューター名] の値と一致しない場合は、名前を元の名前に戻す必要があります。
[スタート] メニューを選択し、sysdm.cpl と入力します。
[変更] を選択し、[コンピューター名] に値を入力します。
[OK] をクリックします。
求められた場合は、WorkSpace をドメインに参加させるために使用するサービス AWS アカウントの認証情報を入力します。
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 アクセス許可」セクションを参照してください。

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

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

AWS コマンドラインインターフェイス (AWS CLI) を使用して WorkSpace を再起動、復元、再構築することもできます。

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

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