Amazon WorkSpaces(以下、WorkSpaces)と Azure Virtual Desktop(以下、AVD)シリーズの5本目です。
1本目は記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Amazon WorkSpaces事前準備編~
2本目は記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Amazon WorkSpaces構築編~
3本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Amazon WorkSpaces MFA実装編~
4本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Azure Virtual Desktop事前準備編~
夜中1時ですが、本記事はいよいよAVDの構築を行います。
自分でも頭が回っていないのがわかるので、ところどころ日本語がおかしいと思いますが、後程修正しますのでご勘弁ください。
AVDとは?
WorkSpacesとの最大の違いは、Windows 10 OSで、マルチセッションが使えるという事です。
サーバであればマルチセッションは理解できると思いますが、Windows 10では唯一Azure上でのみ利用可能です。
アプリケーション配信もWorkSpacesと同じくできますが、今回はWorkSpaces側もデスクトップ環境を作成したので、構築環境を合わせるためにAVDもデスクトップ環境を作成します。
またWorkSpacesには無かった(のか私が見逃してるだけなのか、わかっていないだけなのか不明ですが)ホストプールという概念があり、同一イメージから画一化された複数台のVMをデプロイすることができ、これをまずは作成しないとVDI環境として利用できません。
利点としては、例えば製造業のユーザを想定した場合、経理部、営業部、製造部でそれぞれ業務で必要なマシンスペックに違いがあると思います。
経理部ではOfficeアプリケーション中心、営業部はTeamsやZoomなどのコミュニケーションツール中心、製造部ではCADが利用できないと業務にならない、という具合です。
そこで経理部用のホストプール、営業部用のホストプール、製造部用のホストプール、とそれぞれ部に紐づいたホストプールを作成し、それぞれの利用部署にそれぞれのホストプールのみにアクセスさせる、という展開方法です。
AVDの構成図
はい。
今回も構成図書いてみました。
このシリーズの前提条件では、オンプレミスのActive Directoryと連携する必要があるので、ここで初めてVPNが登場します。
WorkSpaces比べて随分シンプルですね。
ホストプールが分かれてもサブネットは1つでOKですが、分けることも可能です。
今回は検証なので1つのサブネットで1種類のホストプールで構築します。
WorkSpacesの時と同じく、VPN接続は別の記事に譲るので割愛します。
AVDの構築
前回の記事、Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Azure Virtual Desktop事前準備編~の構築が終わっているので、既にAzure ADとオンプレミスのADは連携済みです。
仮想ネットワークの事前準備
事前準備に書いておこうか迷ったんですが、ここで書きます。
VPNは構築済みの前提なのですが、Azure上のVMにDNSサーバをDHCPで配布するパラメーターは仮想ネットワークで行います。
AVDを構築するサブネットを含む仮想ネットワークのDHCPのDNSオプションでオンプレミスActive DirectoryのDNSサーバを指定しましょう。
Azure Portalから[仮想ネットワーク]を検索し、今回オンプレミスとVPNを張っている、AVD構築対象の仮想ネットワークを選択します。
仮想ネットワークを選択したら、[DNSサーバ]をクリックします。
[カスタム]を選択し、IPアドレスを入力するテキストボックスが有効化されたらActive DirectoryのDNSサーバ、ドメインコントローラーとDNSサーバが同居している場合はドメインコントローラーのIPアドレスを入力して、最後に[保存]をクリックしましょう。
事前準備は以上です。
AVDの構築
ではいよいよAVDを構築しましょう。
Azure Portal上で[すべてのサービス]をクリックし、検索ボックスに[Azure Virtual Desktop]と入力し、最上位の候補をクリックします。
ホストプールの作成
[ホストプールの作成]をクリックしましょう。
AVDの各種パラメータを入力していきます。
[サブスクリプション]にはAVDを構築するサブスクリプションを指定します。
[リソースグループ]ですが、これは既に仮想ネットワークの存在するリソースグループがあるかと思いますが、ホストプール単位で作成した方が後々管理しやすいので新規作成しましょう。
[場所]はこのホストプールのメタデータを格納する[リージョン]です。
ホストプールが展開されるリージョンではないのでお間違いなきよう指定してください。
[検証環境]は[はい]を選ぶとデプロイ前に検証が可能になりますが、今回はもういきなり[いいえ]=つまり本番環境としてデプロイします。
[優先するアプリ グループの種類]は[デスクトップ]と[リモートアプリ]の2種類があります。
前述のアプリのみ配信する機能が[リモートアプリ]に相当しますが、今回はWorkSpacesに合わせて[デスクトップ]を選択します。
[ホストプールの種類]は[個人]と[プール]がありますが、これは前述のWorkSpacesとAVDの最大の違いであるWindows 10のマルチセッションを使うか、1台のOSに1ユーザという「個人用OSの展開」かを選択する部分です。
せっかくなので[プール]を選択します。
[負荷分散アルゴリズム]は前項目を[プール]にした場合に出てくる選択肢で、帯域幅優先にするとセッションを分散させて接続させるか、深さ(1台のOS何セッション入っているかを判定し、最大セッションに達したら次のVMに接続を行う)優先で接続を選択するかの設定値です。
今回は[幅優先]で設定します。
ユーザに対して最も公平に同じ負荷のかかっているVMが割り当てられる想定だからです。
[セッション数の上限]は1台のVMに最大何セッション張ることを許容するか、このセッション上限を超えたら自動的にもう1台デプロイするのか、を設定する値です。
入力が終わったら[仮想マシン]をクリックします。
仮想マシンの指定
ちょっと1つの画面で設定値が多いので2つに分けます。
[仮想マシンの追加]は[はい]を選択します。するとこれより下にある項目が出てきます。
[リソースグループ]は[規定でホストプールと同じにする]で良いでしょう。部署単位で展開するホストプールなので、部署が無くなったり、部署単位で必要なイメージが変わった場合にホストプールのリソースグループごと削除することができるからです。
[名前のプレフィックス]ですが、これはVMのホスト名のプレフィックスです。
ここで名付けたプレフィックスのが[avdsh]だとしたが、実際のホスト名は[avdsh-0]から末尾の数字がカウントアップしていきます。
[仮想マシンの場所]は実際に仮想マシンがデプロイされるリージョン、かつVPNで接続されていて本記事の事前準備でDNSサーバの値をカスタムした仮想ネットワークと同一リージョンでないといけません。
[可用性オプション]は可用性ゾーンを利用するかどうかのオプションです。可用性グループが利用できるかどうかはリージョン単位で異なるので、利用可否と共に事前に調査してリージョンを選択しましょう。
[セキュリティの種類]はTPM(Trusted Platform Module)のついているCPUで起動するVMか、更にセキュアなVMかを選択します。
今回は[Standard]を選択します。
[イメージ]は展開されるVMのOSです。今回はせっかくなので[Windows 10 Multi-session]を選択してみます。
[サイズの変更]はVMのSKUです。
[VM数]は初期値で展開されるVMの台数です。
[ブート診断]はOS起動時にOSがどのような状況か、例えばAzure Portal上ではVMは起動済みになっているのにRDPにつながらない場合などに[ブート診断]画面をみてみると、VMの起動状況を3分おきにGUIで確認できま宇s。
VMのWindows Updateが当たっている最中だと、[電源を切らないでください。〇〇%]というおなじみの画面が見れます。推奨の方法にしておいた方が良いでしょう。
[仮想ネットワーク]は本記事の事前準備でDNSをカスタムした仮想ネットワークを選択します。
[サブネット]はAVDのVMを展開するサブネットを選択します。
[ネットワークセキュリティグループ]は事前に定義したものをサブネットに割り当てているので、ここでは[なし]です。
[参加するディレクトリを選択する]はAzure ADかActive Directoryか選択できますが、今回は[Active Directory]を選択します。
この選択肢はWorkSpacesには存在しません。WorkSpacesはActive Directory択一だからです。
[ADドメイン参加UPN]はAVDのVMを参加させるドメインのドメイン管理者権限を持つユーザのUPNです。
[パスワード]は前項目の[ADドメイン参加UPN]で指定したユーザのパスワードです。
[参加するドメイン]はドメイン名を入力します。
[組織単位のパス]はAVDのVMがActive Directory内でどのOUに所属させるか、という設定です。分かりにくいので記載例を記載しておきましたので参考にしてください。
この設定値はオプションなので、未設定だと[Computers]OUにAVDのVMは参加させられます。
WorkSpacesにもこのオプションはあるらしいのですが、私には見つけられませんでした・・・
[ユーザ名]は展開されるAVDのVMのローカル管理者権限アカウントです。
[パスワード]はローカル管理者権限のアカウントのパスワードです。
省略していますが[カスタム構成]のURL入力はこれらの設定値をARM(Azure Resource Manager)のテンプレートに従って記載したファイルを格納しているURLを指定するととでこれらの処理を自動化できるものです。
所謂IaCですね。
最後に[次へ:ワークスペース]をクリックします。
ワークスペースの作成
はい。
夜も深まりすぎて自分でも何言ってるかわからなくなってきました。
この[宛先のワークスペース]は、ユーザがAVD環境にWebブラウザかデスクトップアプリケーション経由でアクセスした際に表示されるワークスペース名です。
部署名やAVDのVMの役割の分かりやすい名前にすると良いと思います。
後の項目は[詳細]と[タグ]ですが、[詳細]では診断設定の有無と設定するのであればどこにどのようなデータを格納するかの指定です。
[タグ]は利用される方は指定してください。
これらは必須オプションではないので、今回はスキップして[確認と作成]をクリックします。
最後に確認画面があるので確認し、最後に[作成]をクリックします。
事前に作成しておいた[avdclient]というOUには、当たり前ですがまだ何のオブジェクトも存在しません。
デプロイ画面ではまだVMデプロイ中っぽいんですが、
VM配下のように作成済みで実行中になっていますが、まだActive Directory上には変化がありません。
これはVMは作成済みなのですが、ローカル管理者権限の作成やAD参加などの処理も行っているので通常よりもデプロイに時間がかかっている、ということです。
まだデプロイは終わっていませんが、
コンピューターオブジェクトができてる!
素晴らしい!
ここまできたら、もうデプロイ完了したも同然です!
AVDのデスクトップ環境にログインできるユーザを割り当てる
デプロイが終わったので[リソースに移動]をクリックします。
以下の画面に飛ばされるので、[アプリケーショングループ]をクリックします。
[hostpool01-DAG]をクリックします。
[DAG]は恐らくDesktop Application Groupの頭文字でしょう。
[割り当て]をクリックします。
[追加]をクリックします。
AVDにアクセスさせたいユーザ名を入力し、選択します。
最後に[選択]をクリックします。
トーストが出てきてくれます。
割り当てられましたね。
クライアントからのアクセス
それではクライアントアプリケーションをインストールして接続してみましょう。
公式サイトからインストーラーをダウンロードしてインストールしてください。
https://learn.microsoft.com/ja-jp/azure/virtual-desktop/users/connect-windows?tabs=subscribe
クライアントアプリケーションを起動すると、
こんな画面が上がってきますので、[登録]ボタンをクリックしましょう。
そしてまたしても上がってきました、Azure ADのログイン画面
[AVDのデスクトップ環境にログインできるユーザを割り当てる]の項目で割り当てたユーザ[domain.user01]を入力します。
Active Directoryのパスワードを入力して、[サインイン]をクリックします。
Azure ADログイン時にログインしたユーザに、ログイン権限が付与されているAVDを自動で検索してくれます。
Azure ADにログインするだけで良いって、めっちゃ便利やん!
Azure、始まってますね!
はい。
以下のように[ワークスペースの作成]の項目で入力したワークスペース名がここで出てきます。
AVD利用ユーザの目に触れるところなので、所属組織名やその略称などわかりやすい命名が良いと思います。
で、この[Sesstion Desktop]っていうアイコンをダブルクリックすると
なんとリモートデスクトップクライアントの接続待ちみたいな画面が出てきて
Active Directoryへのログイン聞いてきた!
なのでActive Directoryのパスワードを入力して[OK]をクリックすると
遂に来ました!
やった!
やりましたね!
ここまで記事を書きながらの構築で2時間半ほどです。
早いっすね。
いや、疲れましたが無事AVDが構築できてよかったです。
何気にAzure AD クラウド同期でのAVD構築は今回が初めてでしたしね。
次回はAVD利用時にMFA使えるようにします。
もうこれはぶっちぎりでAzureの方が簡単です。
今回はここまで。