Amazon WorkSpaces(以下、WorkSpaces)と Azure Virtual Desktop(以下、AVD)シリーズの8本目の派生記事です。
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事前準備編~
5本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Azure Virtual Desktop構築編~
6本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Azure Virtual Desktop MFA実装編~
7本目の記事はこちら
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~まとめ編~
まとめ編の記載後にAVDの便利な機能に気付いたので番外編の位置づけです。
WorkSpacesのAutoStop機能について
2本目の記事、
Amazon WorkSpaces と Azure Virtual Desktop 比較 ~Amazon WorkSpaces構築編~でさらっと触れている、というか書いているだけのAutoStop機能ですが、なかなか便利で、どういう機能かというと、
WorkSpacesのEC2が停止している状態で、ユーザが任意のタイミングでログオンすると、自動的にログオン対象のEC2が起動する
という機能です。
メインの機能はEC2がアイドル(ユーザ未アクセス)状態になると、あらかじめ指定した時間が経過すると自動的にEC2をシャットダウンする、という機能です。
この自動シャットダウン機能と表裏一体で提供される自動起動なのですが、AzureのVMでも同じことができれば便利だなと常々思っていました。
まとめ記事を書いた後に調べたところ、AVDであればStart VM on Connectという機能を使えばこのVMが停止(割り当て解除済み)状態で、ユーザが任意のタイミングでアクセスしたらVMを起動させることができるとわかったので、本記事はこのStart VM on Connectについて記載していきます。
公式サイトはこちらです。
https://learn.microsoft.com/ja-jp/azure/virtual-desktop/start-virtual-machine-connect?tabs=azure-portal
前提条件
当然AVDは構築済みです。
Start VM on ConnectはWorkSpacesのAutoStopのように、構築時に自動的に反映される機能ではなく、後から追加する機能です。
見えない前提条件
普通に構築してるとユーザが意識しない部分になっているのですが、本機能を使うにあたって意識する必要があるので記載しておきます。
まずAzure内のリソースは、操作しようとしているリソースの存在するサブスクリプションや対象リソースに対してどのような権限を持っているか、によってできる操作が変わってきます。
VMの起動、停止も同じです。
通常、Azure Portal経由でVMの起動/停止を行う場合は以下の図のようになります。
はい。
よくある認証/認可で、操作できる範囲が決まっている、という図ですね。
今回のStart VM on Connectは、AVDのサービスがユーザのアクセスを検知したタイミングで、アクセスしたユーザ、及びそのユーザの権限でAVDのサービスが対象のVMを起動するのではなく、AVDのサービスがアクセスしてきたユーザを判定し、該当ユーザがアクセス許可権限を持つVMを起動するというサービスです。
アクセスしたユーザがユーザの権限をもってVMを起動しているのではありません。
Start on VM Connectは、AVDというサービスがVMを起動しています。
ここが大事です。
これを図にすると、
こんな感じですかね。
ですのでStart on VM Connectは、AVDというサービスにVMの起動権限を付与するところから作業開始になります。
Start VM on Connect追加設定
またしても前置きが長くなりましたが、Start VM on Connectの設定を行います。
AVDにVMを起動できる権限を付与する
Azure Portalに権限操作を行える権限をもつユーザでログインし、右ペインから[サブスクリプション]をクリックします。
右ペインにサブスクリプションがなければ[すべてのサービス]から検索してください。
Start VM on Connect設定対象のホストプールが存在する[サブスクリプション]をクリックします。
右ペインから[アクセス制御(IAM)]をクリックします。
[+追加]をクリックし、展開される[ロールの割り当ての追加]をクリックします。
ロール(役割)の検索ボックスが出てくるので、
[Desktop Virtualization Power On Contributor]と入力すると2つの権限が出てきますので、[Desktop Virtualization Power On Contributor]をクリックします。
(もう一つのDesktop Virtualization Power On Off Contributor権限はまた別記事で触れます。なんとこの権限を使うとAuto Scale機能が・・・)
[次へ]をクリックし
[アクセスの割り当て先]を[ユーザ、グループ、またはサービスプリンシパル]を選択し、[メンバー]を[メンバーを選択する]をクリックし、出てきた[選択]ページの検索ボックスに[Azure Virtual Desktop]もしくは[Windows Virtual Desktop]と入力し、
[Azure Virtual Desktop]をクリックし、
[選択]をクリックします。
[レビューと割り当て]をクリックします。
再度[レビューと割り当て]をクリックします。
これで作業の半分はおわりです。
対象のホストプールで、Start VM on Connect機能を有効にする
Azure Portalの右ペイン、若しくは[すべてのサービス]から[ホストプール]をクリックします。
対象のホストプールをクリックします。
[プロパティ]をクリックします。
[接続時にVMを起動する]の項目はデフォルトで[いいえ]なので、これを[はい]に変更し、[保存]をクリックします。
以上で作業は完了です。
動作確認
それでは動作確認です。
まずはホストプールに含まれるVMが停止していることを確認し、起動していたら停止しましょう。
AVDのクライアントアプリケーションを起動し、セッションホストをダブルクリックします。
リモート接続開始の画面が出てきますが、すぐにはアクセスできませんが、
[リモートPCを開始しています・・・]に変わり、
VMは比較的すぐに[実行中]に変わります。
VMの起動がこの記事を書くために私がイカサマしていないことを確認するために、対象VMのActivity Logを見てみましょう。
私が①時間前にDeallocate、[停止(割り当て解除済み)]にしたVMが、2分前に[Azure Virtual Desktop]が[起動]した、とログにあります。
間違いないですね。
セッションホストをダブルクリックしてから、私の環境(US West 2)では3分かかって起動してきました。
ちょっと遅いかな、って気はしますが、VMのスペックを上げれば起動速度は比例して高速化可能です。
目標通り自動起動できましたね。
結構丁寧に、ほぼワンクリック単位で説明しましたが、おわかりいただけましたでしょうか?
結構簡単です。
Microsoft、始まってますね!
今回はここまで。