はじめに
IaC技術推進部の相澤です。WVD（Windows Virtual Desktop）ARMを構築してみたので、構築手順について2回に分けてご紹介します。
WVDとは、2019年9月にGAされたMicrosoft純正のDaaSです。
現在GAされているWVD（以下、Non-ARM）の構築はPowerShellを使用していますが、2020年5月のSpringUpdateで、
ARM（Azure Resouse Manager）デプロイモデルがパブリックプレビューされたことでAzure Portalから構築・管理することが可能となりました。
本記事は後半として、WVD ARMの構築～接続までを記述します。
前半はこちら→WVDを構築してみた_Part1（認証基盤編）
WVDの特徴
- Windows10マルチセッション
Windows10を同時に複数ユーザーが利用できる唯一のサービス - O365の最適化
高速バックボーンを利用してOffice365に接続 - セキュリティ更新プログラムの無償適用
Windows7のサポート延長
WVDの管理プレーンはMicrosoftが管理しており、システム設計の負担軽減や、導入・運用におけるコスト削減、VDI環境における最適なパフォーマンスが期待できます。
さらにSpringUpdateでAzureの他ソリューションとの連携も容易になり、デプロイや管理がよりシンプルで分かりやすくなりました。
構築環境
今回は下図のような環境を構築しました。
Azure内で完結する構成とし、認証基盤はAzure AD ＋ Azure AD DS 、ユーザープロファイルの保存先はファイルサーバとしました。
ファイルサーバは仮想マシンにデータディスクを追加したものを用意しました。
オンプレとAzureを連携させたハイブリット環境の場合、認証基盤はAD + Azure AD Connect + Azure ADとなります。
※Azure AD Connectのインストールにはエンタープライズ管理者権限（EA契約）が必要。
また、ユーザープロファイルの保存先はAzure Storage（Blobまたはファイル共有）やAzure NetApp Filesを利用することも可能です。
構築準備
WVDを構築するために準備するものです。上2つ以外は前半と同じです。
Azure ADと同期しているADは前半で構築した認証基盤を利用します。
- ライセンス
WVDを利用するために必要なライセンスを購入する必要があります。
試用版でも可能です。 - Azure ADと同期しているAD
今回構築した環境のようにAzure AD DS、もしくはAD＋Azure AD ConnectをAzure ADと同期させます。 - Azureサブスクリプション
無償サブスクリプションでも可能です。 - Azure AD
サブスクリプションを作成した際に自動的にディレクトリが作成されます。
カスタムドメインを使用する場合は、カスタムドメイン名を追加し、プライマリドメインとして設定しておきます。 - リソースへのアクセス権限
作業するアカウントには、リソースへのアクセス権限が必要です。
構築全体の流れ
WVD構築
2．WVD環境構築
1．マスターイメージの作成
セッションホストを展開するにあたり、コピー元となるマスターイメージを作成します。 今回は、OSにマルチセッション対応のWindows10を使用し、マスターイメージを作成していきます。
まずはマスターイメージにするVMを作成します。
VMのイメージは、「Windows 10 multi-session」 と記載のあるイメージを選択します。
Officeがインストール済みのイメージを選択することも可能です。
デプロイが成功したらVMにログインして、日本語化※やWindowsUpdateを行います。
※Azureが提供しているイメージは英語環境のため
Officeのインストールがまだの場合、展開ツールを使用してOfficeをインストールします。
こちらからOffice展開ツールをダウンロードすることができます。
FSLogixのインストールと設定
ユーザープロファイルを管理するFSLogixもマスターイメージとなるVMにインストールします。
こちらからFSLogixのダウンロードをし、
解凍したファイル配下のFSLogixAppsSetup.exeを実行して、インストールします。
FSLogixは、 GPOで制御 するか レジストリを直接編集 することで設定が可能です。
今回はGPOで設定します。
マスタイメージ用VMの解凍したファイル直下にあるfslogix.admlとfslogix.admxの両ファイルを、管理ツールをインストールしたVM（以下、管理用VM）に配置します。
| ファイル名 | 配置先ディレクトリ |
|---|---|
| fslogix.adml | C:\Windows\PolicyDefinitions\ja-JP |
| fslogix.admx | C:\Windows\PolicyDefinitions |
言語に依存するfslogix.admlファイルは、VMの日本語化していない場合、
ja-JPをen-USに読み替えてください。
.admlファイルと.admxファイルを管理用VMに配置することで、Azure AD DSの組み込みGPOにFSLogixのGPO管理用テンプレートが作成されます。
GPOで設定するため、ここからは管理用VM上の操作となります。
サーバーマネージャーから[グループポリシーの管理]を選択し、グループポリシー管理コンソールからグループポリシー管理エディターを開きます。
[フォレスト]>[ドメイン]>[設定したドメイン名]>[AADDC Computers]>[AADDC Computers GPO]を右クリック[編集]
グループポリシー管理エディターで、FSLogixの管理用テンプレートを開きます。
[コンピューターの構成]>[ポリシー]>[管理テンプレート]>[FSLogix]
ユーザープロファイルコンテナの設定をしていきます。
[Profile Containers]を開き、以下の設定項目を有効化します。
| 設定 | 説明 | 状態 |
|---|---|---|
| Enabled | ProfileContainterを有効にします | 有効 |
| Delete local profile when FSLogix Profile should apply | VHDから読み込まれるプロファイルと一致するローカルプロファイルが存在する場合は削除する | 有効 |
| VHD Location | VHD(X)ファイルを検索するためのファイルシステムの場所のリスト | VHDの保存先を指定 |
今回は、ユーザープロファイルの保存先にはファイルサーバーの共有フォルダ※のネットワークパスを指定します。
※予め、ドメインユーザーに共有フォルダのアクセス権を割り当てておいてください。
プロファイルコンテナ―で保存先を指定する際の入力形式は\\Location\folderです。
複数の保存先を指定する場合は、\\Location1\folder1;\\Location2\folder2;と入力します。
複数指定した場合はActive/Passive構成となり、先に指定したファイルサーバ(folder1)がActive、次に指定したファイルサーバ(folder2)がPassiveとなります。
これでFSlogixの設定ができました。
イメージ化する前に、再度マスターイメージ用のVMにログインし、一般化します。
管理者権限でコマンドプロンプトを開き、以下のコマンドを実行してsysprepとOSシャットダウンします。
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown
※sysprepで失敗する場合は、C:\Windows\System32\Sysprep\Panther配下のsetupact.logまたはsetuperr.logを確認します。
今回は、setuperr.logを確認すると、以下のようなエラーが表示されていました。
## setuperr.log
SYSPRP Package <アプリのパッケージ名> was installed for a user,
but not provisioned for all users.
This package will not function properly in the sysprep image.
そこで、管理者としてPowerShellを開き、該当パッケージをアンインストールしたらうまくいきました。
## 該当パッケージの削除
Get-AppxPackage -AllUsers Microsoft.LanguageExperiencePackja-JP* | Remove-AppxPackage
オンラインだと自動的にインストールされるパッケージがあるようです。
Azure Portalでマスターイメージ用VMの状態が 停止済み になっていることを確認したら、VMの概要ページから[キャプチャ]をクリックしてイメージを作成します。
イメージの基となったVMは起動できなくなるため、キャプチャの際に削除します。
これでマスターイメージが完成しました。
2．ホストプールの展開
ホストプールを作成する前に、WVD ARMのリソース関係を紹介します。
WVDの構造についての公式ドキュメントとtechcommunityを参考にすると、WVD ARMのリソース関係は下図のようになります。
ホストプールの作成では、ホストプールに紐づけるWorkspaceやSeesionHost、Application Groupも併せて作成・指定することができます。
では、先ほど作成したマスターイメージを使用して展開していきます。
ポータルの検索バーにWindows Virtual Desktopと入力して、[Windows Virtual Desktop] - [Create a Host pool]を選択します。
Project details
[Subscription] ホストプールを作成するサブスクリプション
[Resource group] ホストプールが属するリソースグループ
公式で推奨されているわけではないが、ホストプール毎にリソースグループを分けるのがオススメ。
[Hostpool name] ホストプール名
[Location] MetaデータをデプロイするAzureのリージョンを選択 ※現在はアメリカのみ
Host Pool type
[Host Pool type] PersonalかPooledを選択
接続するセッションホストがpersonalは固定、Pooledはランダム。
今回はPooledを選択
[Max session limit] 1つのホストに負荷分散する最大ユーザー数
[Load Balancing algorithm] 負荷分散方法（Breadth-firstかDepth-first）を選択
personalを選択した場合
[Assignment type] 割り当て方法（AutomaticかDirect）を選択
ホストプールに割り当てるセッションホストをマスターイメージを使用して作成します。
Virtual Machine
[Add virtual machine] Yes
[Resource group] セッションホストの属するリソースグループ
ホストプールで選択したリソースグループと別のリソースグループでも可能。
[Virtual Machine location] セッションホストのリージョン
[Virtual Machine size] セッションホストのサイズ
[Number of VMs] ホストプール用に作成するセッションホスト数
後から追加することも可能。
[Name prefix] 名前のプレフィックス
作成したセッションホスト名は[Name prefix]-0,[Name prefix-1]....となる。
[Image type] Gallaryを選択
[Image] [すべてのイメージとディスクを参照する] - [My Items]から作成したマスターイメージを選択
[OS disk type] OSディスクタイプ
Network and security
[Virtual network] セッションホストの仮想ネットワーク
[subnet] セッションホストのサブネット
ドメイン参加のため、Azure AD DSが配置してある仮想ネットワークと繋がっている必要がある。
[public IP] No
セキュリティを考慮してパブリップIPを使用しないことを推奨。
[Network seculity group] セッションホストのセキュリティグループ
[Specify domain or unit] YesかNoを選択
Administrator account
[AD domain join UPN] ADドメイン管理者のユーザー名
[Password] パスワード
[Confirm password] パスワードの再入力
Workspace
[Register desktop app group] YesかNoを選択
WVDを使用するためにホストプールとワークスペースの紐づけが必須。後から作成することも可能。
Yesを選択した場合
[To this workspace] 新規作成か既存のワークスペースを選択
[preview + create]をクリックして、ホストプールをデプロイします。
3．WVD接続
WVD接続の流れは以下のようになります。
※WVD管理プレーンは自動的に近いリージョンが選択されます。
- ユーザーが クライアントデバイスからエンドポイント（RD GatewayとRD WebAccess）に接続する。
- RD Gateway と RD WebAccess が Azure AD に対して認証を行う。
- 認証が成功すると Azure AD が クライアントデバイスに対してトークンを返す。
- RD クライアントデバイスはトークンを RD WebAccess に渡す。
- RD Connection Broker が SQL にクエリして、ユーザーに許可されたリソース（ホストプール）を判断し、RD WebAccess がクライアントデバイスに許可されたリソース（デスクトップ / Remote App）を表示する。
- ユーザーがリソース（デスクトップ / Remote App）を選択する。
- RD Connection Broker は最適なセッションホストをアサインする。
- RD Connection Broker はメタデータとともに US に存在するため、日本リージョンに存在する RD Gateway を経由してセッションホストに到達する。
- セッションホストはAzure AD DSに対して認証を行う。
- 認証が成功すると、ユーザーはリソース（デスクトップ/RemoteApp）を利用可能となる。
1．接続グループの割り当て
接続するセッションホストにアクセス権を割り当てるAzure ADグループを作成しておきます。
Azure Portalで[Windows Virtual Desktop] - [Application Group]を開き、ADグループを割り当てたいDesktop Application Group(DAG)またはRemoteApp Application Groupを選択します。
ホストプールをデプロイした際にDAGは自動的に作成されます。
[Assignments] - [Add]を選択し、作成したADグループを追加します。ユーザーを割り当てることも可能です。
Azure ADグループを割り当てておくと、新規ユーザーはグループに追加するだけでWVDのリソースにアクセスできるようになります。
2．デスクトップ接続
接続はクライアントアプリもしくはブラウザ経由で行います。
ブラウザから接続する場合は、以下のURLにアクセスします。これはWVD ARMのURLで、Non-ARMとは異なりますので、注意してください。
https://rdweb.wvd.microsoft.com/arm/webclient
まずはAzure ADの資格情報を入力します。
サインインすると、そのユーザーに許可されたデスクトップやアプリが表示されるので、接続先を選択します。
ユーザーのドメイン資格情報を入力して接続します。
ログインできました。
ここで、プロファイルの保存先に指定したファイルサーバを見ると、接続したユーザーのVHDファイルが作成されてることが確認できます。
CloudCacheで保存したときの画像だったので修正しました。(2020/7/21更新)
最後に
検証開始当初はNon-ARMで構築を進める準備をしていたんですが、COVID-19の影響1で構築開始まで時間がかかってしまい、
その間にSpringUpdateがあったため、ARMで構築をしました。
WVD自体の構築（ホストプールの展開）は設定値の入力からデプロイまで1時間もかからず、とても簡単です。（セッションホスト1台だったからかも、ですが。）
※既にGAされているWVD Non-ARMと今回構築したパブリックプレビューのWVD ARMの管理は統合されていません。Non-ARMで作成したリソースをARMで使用したい場合には移行する必要がありますのでご注意ください。執筆時点では移行ツールは開発中です。
個人的な感想としては、そもそもADやGPOがよく分からなくて、FSlogixの設定にかなり苦労しました。
admxファイルとはなんぞや、というレベルで...。
公式ドキュメントにもレジストリを直接編集する方法しか記載されていなかったのですが、実際の運用を考えるとGPOで設定できた方が良いだろうなと思い、GPOで設定する方法を選択しました。
ただ、管理用テンプレートが出来たあともAADDCComputersとAADDCUsersのどちらから設定するのか迷ったり、sysprepがうまくいかなかったりと全体を振り返るとマスターイメージの作成が山だった気がします。
それに比べるとWVD ARMのホストプールの作成から接続までは、少ない工数で短時間で構築ができました。まさにDaaSならではといったところでしょうか。近いうちにWVD ARMもGAされると思いますので楽しみです。
弊社ではWVDの導入支援もやっておりますので、ご興味のある方はこちらもご覧ください。
www.ap-com.co.jp
-
WVDを構築してみた_Part1（認証基盤編）の新規無償サブスクリプションでリソース制限されていた話をご覧ください。↩
