この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。
前回の記事で作成した環境を削除し（従量課金のコストを減らすため）、再度、hosts pool を作成しました。 作成自体は成功したのですが、リモートデスクトップクライアントで接続しても作成したリソース(workspace)が表示されません。 トラブルシューティングの内容を共有します。
目次
1. 問題の状況
1.1. クライアントからの見え方
リモートデスクトップクライアントで接続すると今回追加したリソースが表示されません。
古い情報が残っているのか、手動での更新が必要なのか切り分けます。
具体的には以下のように登録を解除し、
”申し込む”から再度Azure AD のアカウントでサインインします。
結果の画面は省略しますが変わりなしです。
1.2. 展開のタスクの状況
実は展開テスクが完了していない可能性を確認します。
hosts pool の作成の中で行われる5つのリソース作成はすべて問題ありません。
1.3. hosts pool の状況
“Session hosts” は1台で正常に認識されています。
“Applications” でも1つ登録されています（デスクトップのみですが）。
“Activity log” を見ても展開タスクのログだけで参考になる情報はありません。
”Session hosts” を確認します。 仮想マシンのStatus はavailable です。 仮想マシンに問題は特に無いようです。
Azure Portal から見る限りhosts pool に特に問題は見当たりません。
1.4. Application groups
Overview の情報を確認します。 こちらは構成情報のため特にトラブルシューティングにつながる情報はありません。
Assignments を確認します。 原因がわかりました。 Application groups に接続するユーザないしグループがアサインされていません。
結論として単純な手順の実施漏れでした。
2. 問題の解決
Assignments から”Add”よりユーザ・グループを追加します。
Azure AD 上のユーザまたはグループを指定します。
リモートデスクトップクライアントから”最新の情報に更新”を事項します。 または再度申し込みでも問題ありません。
Spring 2020 のリソースが表示されるようになりました。
3. まとめ
今回のトラブルは単純な手順の実施漏れでした。 とはいえトラブルシューティングのノウハウはこのような単純なケースから積み重ねておくことで本当の有事の際の対応力が培われるとも考えています。
今回のトラブルシューティングの流れをおさらいします。 以下の4ステップで確認を進め、結果、④で原因が判明しました。
- （問題発生）リモートデスクトップクライアントからの接続失敗
- リソースデプロイの結果の確認
- hosts pool の確認
- Application group の確認
今回の経験をノウハウとして整理します。 新しいトラブルシューティングの流れは以下になります。
① （問題発生）リモートデスクトップクライアントからの接続失敗
接続失敗の状況としてリソースが表示されるかどうか確認する。表示されない場合は②へ
② Application group でAssignments を確認する。
サインインしたAzure AD アカウントが利用したいApplication group のAssignments に登録されていることを確認する。
Fall 2019 ではhosts pool の展開時にサインインユーザの指定が必須だったためこのような手順漏れが発生しにくかったことも補足しておきます。
以上
