Azure Managed Service Column ＜Azure運用コラム＞Azure Virtual Desktop (AVD) を構築してみる

はじめに

テレワークの普及により、VDI (仮想デスクトップ) の需要が高まってきています。VDI を導入すると、以下のようなメリットがあります。

• 場所に捉われない働き方を実現できる
• 各種データをクライアント端末に保存しないため、端末紛失による情報漏洩リスクを軽減できる
• 各仮想デスクトップの OS やアプリケーションのバージョンを管理者側で一元的管理できる

たくさんある VDI のなかでもオススメなのが、Microsoft が提供する Azure Virtual Desktop (旧:Windows Virtual Desktop) (以下、AVD) です。本コラムでは、実際に AVD を構築することで、どのようなサービスなのかを紹介します。

AVD のメリット

他の VDI 製品と比べたときの AVD のメリットとしては、以下が挙げられます。

• 複数ユーザでの共有が可能な Windows10 マルチセッションの利用ができ、少ない台数の仮想マシンを効率よく利用できる
• ネイティブな Windows10 を利用することができるため、クライアントアプリが期待通りに動作する
• オンプレミス Active Directory や Microsoft 365 と同一のユーザ情報で認証ができ、ユーザの一元管理が可能になる
• 条件付きアクセスによるきめ細やかなアクセス制御ができる

やはり Microsoft が提供するだけあって、ネイティブな Windows10 をマルチセッションで使えたり、Active Directory や Microsoft365 など他の Microsoft サービスとの連携ができたりすることが大きな強みとなっています。

3番目と4番目のメリットはそれぞれ別コラム “Hybrid ID 環境 + Azure Virtual Desktop (旧:Windows Virtual Desktop) を構築してみる” “条件付きアクセスでゼロトラストセキュリティを実現する” を用意しておりますので、本コラムのあとに御覧ください。

システム構成

以下が AVD のシステム構成です。

以下のコンポーネントから成り立っています。

• コントロールプレーン : Web アクセス、ゲートウェイ、ブローカー、診断からなる AVD の管理システムで、Microsoft が管理しています。ユーザが AVD を利用する際には、必ず、このコントロールプレーンを経由してから、”ユーザ個別の AVD 環境” にアクセスすることになります。コントロールプレーンをユーザが構築する必要はありません。
• ホストプール : “ユーザ個別の AVD 環境” のことで、セッションホストと呼ばれる VM の集合体です。
• セッションホスト : ホストプールを構成する VM たちです。個々の VM は通常の Azure VM であり、”Virtual Machines” サービスの画面から参照することも出来ます。ただし、セッションホストとなる VM たちは、必ず AD DS ドメインに参加している必要があります。
• Azure AD : ユーザがコントロールプレーンにアクセスすると、Azure AD による認証が行われます。この認証をパスすると、今度はホストプールにアクセスすることになります。
• AD DS : オンプレ AD DS、もしくは、Azure AD DS のことです(次の章で詳しく説明します)。コントロールプレーンでの Azure AD 認証をパスしたユーザはホストプールに到達し、今度はセッションホストにログインするために AD DS 認証が行われます。同じユーザ情報でログインすることができるよう、AD DS と Azure AD とは同期されていなければなりません。

構築のポイント (前提条件)

システム構成にて説明したとおり、AVD を構築するには AD DS を用意する必要があります。以下の2つの選択肢があります。

• オンプレ環境の Active Directory Domain Service を利用する。 (オンプレ AD DS)
• Azure サービスの Azure Active Directory Domain Service を利用する。 (Azure AD DS)

社内環境にオンプレ AD DS をお持ちの方は、それを使いましょう。ユーザ情報を同期をさせて、同じ ID とパスワードで AVD を使えるという、大きなメリットを得ることができます。ただ、オンプレ AD DS をお持ちでない方でも、Azure AD DS を使うことで簡単に AVD を利用することができますので、ご安心ください。

そして、用意した Active Directory は Azure AD と同期する必要があります。どちらを使うかによって、同期の仕組みが異なります。

• オンプレ AD DS : Azure AD Connect という同期ツールが必要です。同期の方向は オンプレ AD DS → Azure AD となります。
• Azure AD DS : デフォルトで Azure AD と同期されています。同期の方向は Azure AD DS → Azure AD となります。

本コラムでは、Azure AD DS を使うことにします。別コラムにて、オンプレ AD DS のパターンも紹介します。

AVD を構築する

それでは、AVD を作っていきましょう。

1. VNET を作成する

Azure AD DS と AVD のホストプールは、VNET 上に作成されます。そして、ホストプール内のセッションホストは Azure AD DS ドメインに参加する必要がありますので、2つは同一 VNET 上に作成しましょう。今回はあらかじめ、”WVD-VNET” として “/16″ の VNET を作成し、”AVD 用” と “Azure AD DS 用” のサブネットをそれぞれ “/24” で作成しておきました。

なお、大規模なシステムになる場合は、ハブ・アンド・スポーク構成というものが推奨されています。これは、”ハブ” と呼ばれる VNET 上に共通利用するサービスを置き、”スポーク” と呼ばれる VNET 上に実際の処理を行う個別サービスを複数、ピアリングでくっつけていく、というやり方です。AVD であれば、ハブ VNET 上に Azure AD DS を置き、スポーク VNET 上に AVD を置く構成にすると拡張性の高いシステムとなります。

2. Azure AD DS を作成する

Azure AD DS を作っていきます。オンプレ AD DS をマネージド化したサービスなので、指定することも殆ど同じです。Azure AD DS サービスの画面を開きます。

DNS ドメイン名を決めます。デフォルトでは、Azure AD テナントのドメイン名が入力されています。任意のドメイン名を入力することができますが、オンプレ AD DS と同様、実際に名前解決できるものが推奨されています。.local などは非推奨です。今回は、テスト用に取得したドメイン名を指定しました。

次に、VNET を指定します。ユーザが見ることはできませんが、バッググラウンドでドメインコントローラが2台、作成されます。

以降のステップは全てデフォルトで構いません。[確認と作成] をクリックしましょう。デプロイ完了までかなり時間がかかりますが、ドメインが作成されました。作成直後は、ネットワーク構成に関するエラーが表示されています。

クリックすると、VNET 上で DNS 設定を修正するように言われます。DNS に指定しなさいと言われている2つのプライベートアドレスは、ドメインコントローラのインターフェイスです。要は、VNET 内ではドメインコントローラを DNS サーバとしなさい、と言われています。オンプレ AD DS と同じですね。[修正] ボタンをクリックしましょう。

VNET 側の DNS 設定をみると、以下のように修正されています。VNET 内に作成される VM は、こちらの DNS 設定が反映されるようになります。このように、Azure では、OS 側ではなく、ポータル上で DNS を指定しましょう。なお、この設定を飛ばしてしまうと、セッションホストを Azure AD DS に参加させられなくなるので、気をつけてください。

3. Azure AD DS 管理者ユーザを作成する

後ほど、セッションホストを Azure AD DS に参加させるために必要となる管理者ユーザを作成しておきます。ユーザは Azure AD DS ではなく、Azure AD の画面で作成します。しばらくすると、Azure AD DS に同期されるので安心してください。

作成したユーザを “AAD DC Administrator” グループに参加させます。このグループは、オンプレ AD DS での Administrators グループに相当します。

このままだと初回ログイン時にパスワード変更を求められてしまい、ホストプール作成時にエラーとなってしまうため、一度 Azure ポータルにログイン確認をしてパスワード変更しておきましょう。

4. ホストプールを作成する

準備が整ったので、いよいよ AVD のホストプールを作っていきます。

基本設定です。ホストプールの名前を決めます。[場所] はメタデータが格納されるリージョンとなります。2021/03 時点では日本を選ぶことはできません。[ホストプールの種類] にて、個人型 (VM を専有) かプール型 (VM を共有) かを選択します。プール型の場合は、セッション数の上限と負荷分散の方法を指定することができます。通常の用途では、プール型のほうが VM を効率よく利用できるので、オススメです。

次に、[仮想マシン] の設定です。ここでは、セッションホストとなる VM の設定をしていきます。[仮想マシンの場所] は VM が作成される場所です。[イメージ] では VM の作成に使うイメージを指定します。素の Windows10 マルチセッション、あるいは、Microsoft365 がインストールされた Windows10 マルチセッションなどを選択できます。さらに、ユーザ自身がカスタマイズしたイメージを選択することもできます。その他の設定は通常の VM を作成するときと同じく、スペックの指定です。

まだ [仮想マシン] の設定をしていきます。[仮想ネットワーク] は VM が作成されるネットワークです。当然、[仮想マシンの場所] で指定したリージョン内のネットワークである必要があります。また、Azure AD DS と通信できる VNET でなければなりません。Azure AD DS のところで作成した “WVD-VNET” を指定し、サブネットは AVD 用に作った “sessionhost-sunnet” を指定しましょう。

[ドメイン管理者アカウント] が一番のキモです。Azure AD DS ドメインに参加するために使う資格情報を入力します。「2. Azure AD DS 管理者ユーザの作成」にて作成したユーザを指定しましょう。[仮想マシンの管理者アカウント] は VM のローカルユーザになります。

次の画面では、アプリケーショングループとワークスペースを作成します。詳細については後ほど説明します。

最終確認をして、作成します。

作成されたホストプールを見てみましょう。[セッションホスト] メニューを開くと、2つの VM が作成されています。それぞれの名前をクリックすると、”Virtual Machines” サービスの画面に飛ぶことがわかります。セッションホストと呼ばれていますが、実体は至って普通の VM です。

ホストプール作成のウィザードにて、アプリケーショングループとワークスペースを作成しました。アプリケーショングループというのは、ユーザに提供するアプリケーションを管理するためのグループです。“ホストプール” “提供したいアプリケーション” “ユーザ” の3つを紐付けます。これにより、同一のホストプールを利用する部署 A, B に対して、部署 A には全てのアプリケーション(リモートデスクトップ)を提供、部署 B には Web ブラウザと Excel だけを提供、といったことができます。

デフォルトでは、以下のように [アプリケーション] に “デスクトップ” が指定されています。後ほど、このデスクトップを提供したいユーザを、このアプリケーショングループに割り当てます。

ワークスペースは、アプリケーショングループを管理するためのグループです。ユーザ側で何か設定したりすることは基本的にありません。

5. アプリケーショングループにユーザを割り当てる

デフォルトのアプリケーショングループに、テスト用ユーザを割り当ててみましょう。Azure AD サービスの画面に移動し、”WVD-loginuser-groups” というグループを作成します。そして、このグループに “rworks01” というテストユーザを参加させます。

再び、AVD の画面に戻り、デフォルトのアプリケーショングループに、ユーザグループ “WVD-loginuser-groups” を割り当てます。これで、”rworks01″ ユーザは、このアプリケーショングループのアプリケーションにアクセスすることができるようになりました。

AVD にログインする

構築が完了したので、実際に使ってみましょう。AVD にアクセスする方法は幾つかありますが、まずは Web ブラウザからアクセスしてみます。以下の URL にアクセスしてみてください。
https://rdweb.wvd.microsoft.com/arm/webclient/index.html

Azure AD による認証画面が表示されます。Azure AD ユーザ “rworks01” の資格情報を入力します。

資格情報を入力すると、アクセス権限のあるワークスペースと、それに紐付いたアプリケーショングループ内のアプリケーションが表示されます。今回は、デフォルトのワークスペース内に “デスクトップ” アプリケーションだけが表示されています。クリックして “デスクトップ” アプリケーションを使ってみましょう。

今度は、デスクトップにログインするための認証画面が表示されます。これには、Active Directory ユーザの資格情報を入力しますが、Azure AD DS と Azure AD が同期されていますので、AVD にログインするときの Azure AD ユーザと同じ “rworks01” でログインできます。

Windows10 のデスクトップ画面が表示されました！

その他、Windows 用やスマホ用の専用クライアントアプリも存在します。

まとめ

AVD を構築し、デスクトップ画面にログインするところまでを行いました。AVD 自体の構築は簡単ですが、適切なネットワーク設計の VNET を用意したり、Azure AD DS を用意して VM を参加させたりと、意外とハマリポイントがありました。今回はここまでとしますが、実際に運用で利用する場合には、以下のことも考慮する必要があります。

• アプリケーションの配信(RemoteApp)
• VM イメージのカスタマイズ (独自アプリケーションのインストール、日本語化など)
• ユーザプロファイル設定

ユーザプロファイルというのは、ホームフォルダ、ドキュメントフォルダ、ダウンロードフォルダなどユーザ個別のデータのことです。プール型のホストプールでは、ログインするたびにログイン先の VM が変わってしまうので、ユーザ個別のデータは外部に保存する必要があるのです。別コラムにて、ユーザプロファイルをAzure Files に保存する方法を紹介したいと思います。

さらに、”条件付きアクセス” と組み合わせることで「特定アクセス元 IP からのアクセスのみを許可」「Microsoft が怪しいと判断したアクセスをブロック」「指定した OS デバイスからのアクセスのみを許可」といったアクセスコントロールが可能です。 興味のある方は 条件付きアクセスの設定方法を解説したコラム を御覧ください。

本コラムにて、AVD への理解が深まれば幸いです。

Tag： AVD Azure Virtual Desktop Windows Virtual Desktop WVD

• 

  Azure VPN Gatewayとは？VPN Gatewayの冗長化や料金なども解説

• 

  Hybrid ID 環境を構築してみる