Azure コラム 第7回 「Azure Virtual Desktop システム構成 Vol.3」
第7回 上級編 「Azure Virtual Desktop システム構成 Vol.3」 です。
今回はマスタ管理についての話題をお届けしたいと思います。
マスタ管理とは
DaaS(Desktop as a Service)におけるマスタ管理とは、それはライフサイクル管理と言い換えても良いかもしれません。
ライフサイクルと言えば真っ先に思いつくであろうHWライフサイクル(いわゆるHW保守期限切れ)はクラウドの場合基本的に考えなくて良いですし、代わりにサービスライフサイクル(サービス提供終了)の観点はありますがAVDが当面なくなるってこともないでしょう。
そのため本コラムでは製品ライフサイクル観点にフォーカスして書き進めたいと思います。
では製品ライフサイクルとは、そこには軸が2つありますので表にしてみます。
軸は赤枠で囲っているところで、どの製品をどのタイミングで公開するかと言う観点ですね。
上記の表の場合は、2023年2月22日にWindows 10 Ent 22H2 / 2022年2月23日にMicrosoft 365 Apps 2108 が公開され、その後ちょっと間をおいて現行バージョンは停止される形になっています。
そしてこの製品ライフサイクルに合わせてマスタ更新を行うことがマスタ管理だという事が出来るでしょう。
[Windows 10 Enterprise and Education]
https://docs.microsoft.com/ja-jp/lifecycle/products/windows-10-enterprise-and-education
[Microsoft 365 Apps の更新履歴]
https://docs.microsoft.com/ja-jp/officeupdates/update-history-microsoft365-apps-by-date
Windows 10 Ent 22H2の次はもうWindows 11ですね、Windows 10も10年頑張ったと見れば立派に役目は果たしたと言えますでしょうか(そもそも最後のバージョンのWindowsだったはずですが、まあ詮無き事ですか)。
マスタのライフサイクル
マスタにも 公開 →(更新)→ 停止 と言うサイクルがありますのでこれをマスタのライフサイクルとネーミングします。
例えばこんな感じでしょう。
- 1. 作成:マスタ作成
- 2. 公開:マスタ公開
- ~~~~~ ループ ~~~~~
- 3. 更新1:品質更新プログラム(QU)に合わせての月次マスタ更新
- 4. 更新2:機能更新プログラム(FU)に合わせての年次マスタ更新
➢ Windows 10 Ent の 9月更新(H2)が最長のサポート期間30か月ですので、そちらでは隔年更新が可能です
➢ とは言えもう1つの大玉であるMicrosoft 365 Appsのサポート期間が14か月ですので、何らか年次での大型更新は見込む必要がありますね - ~~~~~~~~~~~~~
- 5. 停止:マスタ利用停止、次期マスタ公開
以降の章にてこのライフサイクルのステージごとに技術的な話題を展開していきます。
前提条件
この後VMにリモートデスクトップ接続しての作業が発生します。その為、ExpressRoute or VPNによるダイレクト接続かBastionが必要となりますので前提条件としてご準備ください。くれぐれもRDPをPublic IPでさらして直接接続などされぬよう。
あとマスタVMに関しては言語パックや更新プログラムのダウンロードのためインターネットへの送信接続を全開放しておくことをお奨めします。
マスタ作成
これがなくては始まらないマスタ作成のステージです。
マスタ作成に関しては先達から多くの情報が公開されていますので詳細はそちらに譲り、ここでは各ステップの中でトピックスをお伝えしたいと思います。
- 1. マスタVMの作成
イメージを選択(既定ではmulti-sessionは選択されていませんのでご留意を)して普通にVMを作成してください。
Microsoft 365 Appsインストール済みイメージもありますが、おそらくカスタマイズが発生であろう事を考慮すると後続ステップにて別途インストールする事をお奨めします。
※ プレビューですがWindows 11が公開されていましたので画面キャプチャ貼ってみました。
- 2. 日本語化
何はともあれ真っ先に日本語化します。 - 3. FSLogixのインストールと設定
FSLogix(Profile Container)のインストールと設定を行います。
インストールはインストーラー起動してポチポチで完了です。設定はGPOもしくはレジストリにて行う形となりますが、これくらいならレジストリ直接設定で良いかなと思います。
[チュートリアル: ユーザー プロファイルをリダイレクトするプロファイル コンテナーを構成する]
https://docs.microsoft.com/ja-jp/fslogix/configure-profile-container-tutorial
- 4. アプリケーション/ランタイムのインストール
Microsoft 365 Appsなどのアプリケーションおよび.NET Frameworkなどのランタイムの追加を行います。
ここがマスタ作成ステージにおける最大の肝になります。ポイントは第5回にて触れていますのでそちらをご覧ください。サマリとしては インストール物件を増やす=メンテナンスコストが悪化する と言う関係性にどう折り合いをつけるかですね。
- 5. 更新プログラム適用
OS/アプリケーション/ランタイムが取り揃ったところで一度更新プログラムの適用を行います。 - 6. チューニング
さあここまで来たら一気にイメージ化と行きたいところですがDaaSにおいてチューニングは必須です。
本コラム向けの環境は開発環境ですのでディープなチューニングは行っていませんが、オンプレミスの事例ベースでは特にメモリ最適化観点でのチューニング項目が結構ありますね。
そんな中でもVirtual-Desktop-Optimization-Toolは使ってみて価値ありだと思いましたので紹介しておきます。中身がブラックボックスですのでいずれ解析をしてみようかと。
[Virtual-Desktop-Optimization-Tool]
GitHub - The-Virtual-Desktop-Team/Virtual-Desktop-Optimization-Tool: The script and configuration files in this repository provide an easy method to customize and apply performance related settings to virtual desktop environments.
- 7. スナップショットの取得
ここでディスクのスナップショットを取得します。
後続のSysprepは再実行の際にエラーが発生することがありますので、実行履歴のないクリーンな状態をベースイメージとして保持してください。
- 8. Sysprep(一般化)
Sysprepの実行です。必要に応じて端末固有設定の初期化(Microsoft Defender for Endpointのオフボーディング など)もこのタイミングで行います。
- 9. VMのキャプチャ(イメージ化)
マスタ作成の最終ステップとしてVMのキャプチャを行います。キャプチャ先は共有イメージギャラリーがお奨めです。
[ポータルで VM のイメージを作成する]
https://docs.microsoft.com/ja-jp/azure/virtual-machines/capture-image-portal
とここまでのステップで一旦イメージは出来上がりますが、
- 10. テスト
イメージからセッションホストを展開して各種テストを行います。
このテスト環境はインターネット接続制御など本番環境と同様の設定を施してください。接続もAVD経由で行います。
がその後に控えており、実際は6~10を何度も行ったり来たりした後にマスタは完成となります。 感覚的には…どうですかね、1マスタあたり2~3か月くらいはかかるのではないでしょうか。
マスタ公開
ここは簡単ですね、ホストプールからセッションホストの追加を行うだけです。一度使用可能になってもエージェントのバージョンアップ等で何度か使用不可との行き来が発生しますので気長にお待ちください。
あとポータルからですと入力パラメータがそこそこありますので、テンプレート化なりスクリプト化しておいた方がサクサク感出せると思います(特にテスト中)。
マスタ更新
- ●マスタ更新方式
まず方式に大きく2通りがありますのでそれぞれの方式について記載します。2はマスタには手が入りませんが便宜上マスタ更新として取り扱います。
- 1. マスタを更新してセッションホストを再展開する方式
- ・マスタVMをベースイメージのスナップショットから作成して、あとはマスタ作成ステージの4~10を実施
- ・セッションホストのシステム領域への変更はクリアされます
➢ 変更差分をマスタに反映と言うのも考え得ますがかなりの難易度なので現実的な感じではありません - ・ユーザー領域についてはFSLogixで保持されます
- ・展開は楽ですねマスタ更新後スクリプト一発で完了です
- ・展開後のトレースにも力をかけなくて大丈夫だと思います
- 2. セッションホストを更新する方式
- ・WSUS/端末管理製品等を駆使してセッションホストを直接更新する形、まあ旧来のやり方と言えばその通り
- ・テストVMを常時維持しつつ、そこを使って展開→テストの繰り返しと言うステップになります
- ・セッションホストを上書き更新しますのでシステム領域への変更も保持されます
- ・ユーザー領域ももちろんFSLogixで保持されます
- ・ポツポツと展開エラーが発生し得ますので個別のリカバリ作業発生が懸念されます
- ・展開期間が月単位に渡る可能性がありますのでしっかりとしたトレース計画が必要となります
方式的にも作業負荷的にも1がお奨めですが、すべては システム領域への変更はクリアされます が許容できるか次第ですね。このあたりの結論は第5回に記載の通りです。
-
オンプレミスでは負荷分散の観点から展開をコントロールする必要がありましたが、AVDにおいても
- ・Azure Resource Manager (ARM) サブスクリプション API の調整制限により、Azure portal を使用した 1 時間あたり 600 回を超える Azure VM の再起動は許可されません。 オペレーティング システムを使用して、すべてのマシンを一度に再起動できます。この方法であれば、Azure Resource Manager サブスクリプション API 呼び出しは使用されません。 Azure サブスクリプションに基づく調整制限のカウントとトラブルシューティングの詳細については、「API の調整エラーのトラブルシューティング」を参照してください。
- ・現時点では、Azure Virtual Desktop の ARM テンプレートのデプロイあたり 399 の VM を可用性セットなしでデプロイするか、可用性セットごとに 200 の VM をデプロイすることができます。 デプロイあたりの VM 数は、ARM テンプレートか Azure portal のホスト プール登録で可用性セットをオフにすることにより増やすことができます。
と言った制限事項を意識して展開を行う必要があります。夜仕掛けて朝終わってないみたいなことも起こり得ますのでご留意を。
[エンタープライズ向け Azure Virtual Desktop - Azure の制限事項]
https://docs.microsoft.com/ja-jp/azure/architecture/example-scenario/wvd/windows-virtual-desktop#azure-limitations
- 1. マスタを更新してセッションホストを再展開する方式
- ●マスタ更新スケジュール
-
- ・更新1:品質更新プログラム(QU)に合わせての月次マスタ更新
更新1については2週間程度が目安で、例えばWindows の更新プログラムの場合は第2水曜日リリース2週間後の第4水曜日に公開と言う形になります。
この2週間には作業期間以外にもう1つ、Bリリースに不具合があった場合にその後のCリリースやOOBリリースの様子を見ると言う観点があります。リリース種別については下記ご参照ください。
[毎月の品質更新プログラム]
https://docs.microsoft.com/en-us/windows/deployment/update/quality-updates
- ・更新2:機能更新プログラム(FU)に合わせての年次マスタ更新
更新2については機能更新プログラム(FU)がターゲットなりますので大体3~4か月くらいでしょうか。こちらは業務アプリ提供元などとの連携が必要ですし2か月は見ておいた方が良いかと思います。
と言ったところで、
実はこれが破綻しちゃってるんですよね。Microsoft 365 Apps 2108 はリリースから公開まで1か月ちょっとしかありません (かつ2008のサポート期限がすぐなのでこれ以上後ろにずらすことも出来ない)。ただMicrosoft 365 Apps にはプレビュー版のリリースがありますのでこのシチュエーションにおいてはリスク軽減策が取り得ます。
- ・更新1:品質更新プログラム(QU)に合わせての月次マスタ更新
-
OSとMicrosoft 365 Appsだけでもこんな感じですがインストール物件が増えればライフサイクルも入り組むのでもう大変です。逆に月次でアップデートかかるものはそちらに統一した方が楽な気もしてきますね(推奨)。
マスタ停止
そしてライフサイクルの終着駅マスタ停止です。
Windows 10 では Azure VM 上のインプレースアップグレードがサポートされるようになりましたので、Windows 11へ乗り換えまでマスタ停止と言うイベントはないかもしれません。
[サポートされているWindows10 AzureVMのインプレースシステムアップグレードの手順]
https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/in-place-system-upgrade
Know-How
最後にマスタ管理関連のノウハウをいくつか記載しておこうかと思います。
- ●リモートデスクトップでキーボードがUS配列になる問題
ストアアプリ版のリモートデスクトップアプリでほぼ確実に起こる問題で、下記のレジストリ設定で対応することが出来ます。
[回避策2]
https://docs.microsoft.com/ja-jp/archive/blogs/askcorejp/rs4-rdp-keyboardlayout#%E5%9B%9E%E9%81%BF%E7%AD%96-2
- ●Microsoft Defender for Endpointのオンボーディング/オフボーディング
- ・オンボーディング
下記の記事に詳しい記載がありますのでご参照ください。当コラムでは検証当時AADDS使ったグループポリシー管理に不慣れだったため シナリオ 1: ローカル グループ ポリシーの使用 を採用しています。
[Azure Windows 10デスクトップでのマルチセッション デバイスのオンボード]
https://docs.microsoft.com/ja-jp/microsoft-365/security/defender-endpoint/onboard-windows-10-multi-session-device?view=o365-worldwide - ・オフボーディング
上記のシナリオではマスタVM起動時にオンボーディングしてしまいますので、イメージ化の前にオフボーディングを行う必要あります。
[ローカル スクリプトを使用してデバイスをオフボードする]
https://docs.microsoft.com/ja-jp/microsoft-365/security/defender-endpoint/configure-endpoints-script?view=o365-worldwide#offboard-devices-using-a-local-script
このスクリプトには有効期限がありますのでご留意ください(有効期限切れだとスクリプトがエラーになります)。
スクリプトの実行だけではマスタ展開後のオンボーディングでエラーが発生しますので、合わせて下記の記事に記載のレジストリ削除対応が必要となります。
[非永続的仮想デスクトップ インフラストラクチャ (VDI) イメージの更新]
https://docs.microsoft.com/ja-jp/microsoft-365/security/defender-endpoint/configure-endpoints-vdi?view=o365-worldwide#updating-non-persistent-virtual-desktop-infrastructure-vdi-images
- ・オンボーディング
- ●MSIXパッケージ
本コラム執筆時点ではMSIXパッケージまだ Microsoft 365 Apps に対応してないと思います。将来的にどうでしょうこの手のテクノロジーってレガシーアプリの延命用ってイメージではありますが。
マスタとアプリを分離して柔軟に組み合わせることが出来るのは理想的なのですが、如何せんパッケージ作成の手順が面倒でかつ結構なノウハウが必要になると思います(App-Vをちょっとやっていた頃の印象)。
という事でここはもう少し様子見かなと。
おわりに
Azureコラム第7回いかがでしたでしょうか。
マスタ管理も事例を踏んで大分こなれてきてかなと思います。それよりも脆弱性対応とか更新プログラム自体の不具合とかによる緊急リリースもフローも広義のマスタ管理なのでそっちの方が大変です。
あと Windows 10 Ent 9月更新が30か月サポートになったのとAzure VM 上のインプレースアップグレードがサポートされたのはMicrosoftの英断ですね。
さて次回のコラムですが、
は一旦筆をおいて別のテーマを考えています。
でもPower Apps で AVD のセルフポータル作成って情報を見かけたので、次々回はそれも良いかなと思ってみたり。
いずれにしても近々公開いたしますのでお楽しみに!
- 文章中の商品名、会社名、団体名は、各社の商標または登録商標です。