Windows Virtual Desktop GUI管理コンソール解禁！！

この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

WVD GUI解禁！

追記6/13:
・Automation Account Job実行時のエラー回避について記載しました。
・指定するResource Groupは空でなくてよい点修正しました。
・複数ユーザーがGUI管理コンソールへアクセスするための手順を記載しました。

Public Previewとして公開されているWindows Virtual Desktop(以下、WVD）に、待望のGUI管理コンソールが登場しました！！
WVD GUI画面

はじめに

従来はWVDのコンポーネントを操作するにはPowerShellを利用しなければならず、敷居の高いものでした。
解禁された管理UIでは、各種コンポーネントの表示、設定変更、追加、削除の操作を管理することができます。

ただし、このUI表示に至るまでハマるポイントが少なからず存在します。
今回は、この管理UIを表示させる手順をお伝えいたします。
（注意：AzureサービスのApp Serviceを利用してWVDのWeb UIを表示します。
利用状況に応じて課金が発生しますので、以下の手順を実施する際には自己責任でお願いします。）

手順

手順は大きく3つにわかれます。1つずつ見ていきましょう。

・アカウントの用意

・カスタムテンプレートからのデプロイ

・管理ポータルへのサインイン

アカウントの準備

以下の権限を持つAzure ADユーザーをご用意ください。

・Subscription：所有者又は共同作成者

・WVD Tenant：読み取り権限

カスタムテンプレートからのデプロイ

次のページにアクセスし、「Deploy to Azure」アイコンを右クリック「リンクのアドレスをコピー(E)」をクリックします。
GitHub Azure RDS-Templates page.
次にコピーしたアドレスをメモ帳などに貼り付けて、以下のように編集します。
https://portal.azure.com/@<Tenant Domain Name>#create …
テナントドメイン名は Portal > Azure AD > 概要から確認することができます。
編集したURLにアクセスし、【アカウントの準備】で用意したAzure AD アカウントでAzure へサインインします。
カスタムテンプレートのデプロイ画面に移りますので、パラメータを入力し、「上記の使用条件に同意する」にチェックを入れ、「購入」をクリックします。
サブスクリプション：リソースを展開するサブスクリプションを指定します。
リソースグループ：空のリソースグループを指定します。
場所：必要に応じて変更します。
Azure AD User Pricipan Name：【アカウントの準備】で用意したAzure AD アカウントのUPNを指定します。
Azure Login Password：上記アカウントのパスワードを指定します。
Application Name：各種AppServiceリソースの接頭辞になります。
問題なければ無事にリソースが作成されます。
作成されたApp Serviceの概要ページに記載のURLへアクセスします。
【アカウントの準備】で用意したAzure ADアカウントを利用して、GUIポータルへサインインします。
「組織の代理として同意する」にチェックを入れることで、他のAzure ADユーザーもGUIポータルへサインインすることができます。
（なおWVDコンポーネントを表示させるためには、RDS Reader権限がユーザーに割り当たっている必要があります。WVDロールの割当は引き続きPowreShellでの操作になりますので、ご注意ください。）
初回サインイン時には、なかなかサインインページに遷移しないかと思いますが、気長に待ちましょう。
資格情報を入力した後でアクセス許可を求めるページへ移るので、「承諾」をクリックします。
テナントグループの指定を求められるので、プルダウンから「Default Tenant Group」を選択し「Save」をクリックします。カスタマイズされている場合は、ご自身の環境のテナントグループを選択しましょう。
以上でWVDのGUI管理ポータルへサインインすることができます！
（初回は各種情報を取得するため、コンポーネントが表示されるまでしばらく時間がかかると思います。）

つまずきポイント

・アカウントの権限

カスタムテンプレートで指定することのできるAzure ADアカウントは1つしかありません。
このアカウントはWVD Tenantに対してRDS Reader Roleが割り当たっている必要があり、Subscriptionに対してもリソースを作成する役割が割り当たっている必要がありました。
理由は後述しますが、適切なアカウントを持っていない場合にはデプロイ時またはその後でエラーが発生します。
複数アカウントを指定できれば回避できますが、そういうわけにもいかず。細やかにアカウント管理をされいる企業様には、気を付けて欲しいポイントになります。

・Automation Account Job実行時に発生するエラー

デプロイ時に発生するエラーを一つご紹介します。

種類:Microsoft.Automation/automationAccounts/jobs
{ "status": "Failed", "error": { "code": "ResourceDeploymentFailure", "message": "リソース操作が完了し、ターミナルプロビジョニング状態は 'Failed' です。" } }

このエラーの原因は「Azure AD User Principal Name」フォームに指定したアカウントがAutomation Account のRunbookを実行する権限がないことに起因します。
恐らく「サインインアカウント」にご自身のアカウント(Subscriptionに対してリソース作成の権限を持っている）を利用して、カスタムテンプレートの「Azure AD User Principal Name」にWVDのTenant Creatorロールを割り当てたアカウントを指定しているのではないでしょうか？
混乱するポイントではございますが、WVDコンポーネント周りの権限は既存のRBACとは全く独立したものとなります。(あくまでPublic Preview時点での話であり、GAされた後はRBACに統合される可能性があります）

具体的な解決策として以下の2つの方法が挙げられます。
1. Runbookを実行できるアカウントにて、デプロイされたRunbookを実行する。（所有者、共同作成者の権限を持つアカウントで十分です）
2. 指定したAzure ADユーザーに対してRunbookを実行できる権限(所有者、共同作成者等）を割り当てて、当該ユーザーにてデプロイされたRunbookを実行する。

一点注意事項を申し上げますと、当該Automation Accountの変数にカスタムテンプレートで指定した値がセットされているのですが、なんと恐ろしいことにString型であり、パスワードやSubscriptionIDが丸見えです。
先ほども申し上げました通り、Runbookを実行した後に当該リソースは全て削除されます。しかし少しの時間とはいえ、パスワードが丸見えになってしまうため最新の注意が必要となります。
また、デプロイに失敗したけれどもAutomation Accountが作成されている場合には、上述の方法で対応するか、手動でリソースを削除することを必ず実施いただきたいと思います。

どういう仕組みなの？

以下はあくまで弊社独自の見解になります。

PowerShell及びRest APIを使用したWVDの拡張

先日のde:code 2019のセッション内で話題にあがりました、WVDの拡張の一例だと思われます。
PowerShellにて取得した情報をDBへ保存し、わかりやすく表示するという至ってシンプルなWebアプリケーション。
このアプリケーションを作成するためにAzure リソースの作成、WVDコンポーネントの読み取り権限が必要となっていると思われます。
ユーザー環境に応じてWebアプリケーションを構築するためか、Automation Accountも途中で使用されています。
そのため、各種リソースは作成されたけどジョブ実行時にエラーが発生した場合などは、適切な権限を持つアカウントでRunbookを実行すれば、当該エラーを解消することができます。

今回はこれで以上になります。
弊社では、Windows Virtual Desktopの支援を行っていますので、お気軽にご相談ください。

当サイトはパーソルクロステクノロジー㈱より提供しています