はじめに
現在は、Azure Virtual Desktop (AVD) で、ホストプールと仮想マシンを作成する際に、どれだけシンプルな画面からデプロイさせられるか？ を研究しています。
その際には、いくつかのハードルがあったのですが、そこで得られたノウハウを記事にしていこうと思っています。
AVDに関する記事は、以下のリンク先で シリーズ化 していますので併せて参照ください。
今回のテーマは、ゴールデンイメージを作らずに、MarketPlaceのイメージからデプロイした AVD の VM に対して、初めから FSLogix を機能させようという内容になっています。
FSLogix とは
ユーザーが Windows のクライアントPC にログオンして利用した際のユーザープロファイルの情報を 外部ストレージに保存しておき、次回 他の PC にログオンした際にも、同一の利用環境を提供する仕組みです。
AVD では、多数のホストプールという VM の集まりを稼働させておき、空いている VM に ユーザーをサインインさせる動作となりますが、ユーザープロファイルが VM の Cドライブに保存されていると 利用環境を引き継げなくなります。
FSLogix を導入すると、どの VM にサインインした場合でも、プロファイルコンテナーと呼ばれる VM 外の保存場所から ユーザープロファイルが提供されるため、VM に依存しない形で、ユーザーエクスペリエンスを提供することが可能になります。
従来から、類似の機能として 移動ユーザープロファイルという仕組みがありましたが、機能的には それと同じような目的を果たすものですが、移動ユーザープロファイルは サインインの最中に ファイルサーバーからネットワーク経由でコピーが行われるため、動作が遅くなる欠点がありました。
FSLogix は、ユーザープロファイルが vhdxファイル（仮想ディスク）に保存されており、仮想基盤側で その vhdxファイルを OS にマウントさせるという仕組みになっており、サインイン中の待機時間の短縮に貢献しています。
この仕組みは、AVD とは親和性が高く、組み合わせて利用されることが多いソリューションです。
ユーザープロファイルに保存される情報としては、以下が挙げられます。
- ユーザーごとの PC の設定やアプリケーションの設定
→ NTUSER.DAT、AppData などの隠しファイル属性の フォルダ／ファイル - ユーザーごとに 保存されたファイル
→ お気に入り、ダウンロード、デスクトップ、ドキュメント などのフォルダ
ユーザープロファイルとは、下図の通り、エクスプローラーに %USERFROFILE% というパスを入力した際に表示されるファイル群のことです。
FSLogix を動作させるために必要なもの
FSLogix を動作させるためには、以下の環境が必要です。
- クライアントへ FSLogix アプリケーション の導入
- FSLogix コンテナー を配置するための ファイル共有
- サインイン時に FSLogix を動作させるための GPO設定
- ライセンス
上記、それぞれの構成について、このあとの章で解説していきます。
クライアントへ FSLogix アプリケーション の導入
検証する前の段階では、本記事のテーマ（MarketPlace のイメージを直接展開）を実現するにあたって、FSLogix アプリケーション と呼ばれるエージェントの導入がハードルになると思っていたのですが、結論としては、対処が不要でした。
過去に書かれている AVD + FSLogix 関連のブログ記事などをみると、エージェントの導入が必要なように見えるのですが、いざ イメージの中を確認した結果、MarketPlace で提供されている AVD 用マルチセッションのイメージには FSLogicx アプリケーション が導入されているようでした。
いくつかのバージョンのイメージを展開して中身を確認してみましたが、この認識で問題無さそうです。
これは、大きな発見でした。
以下の公開情報にも、「Windows 10/11 Azure Marketplace画像の一部としてプレインストールした」であれば エージェントの追加インストールは不要というニュアンスで書かれていて、これが私の判断に合致していそうです。
結果的に、「エージェントを導入しなくても使えましたよ！」というのが 本記事で紹介したかったノウハウです。
FSLogix コンテナー を配置するための ファイル共有
FSLogix コンテナー について
FSLogix コンテナーには、２種類のコンテナーが含まれます。
この記事を書く際に掘り下げていて "ODFCコンテナー" の存在を知ったのですが、結論としては ODFCコンテンツ は プロファイルコンテナー に含まれて利用することが推奨されていて、 ODFCコンテナー を使う場合は、他社製のプロファイル管理ソリューションを利用する際に ODFCコンテンツ を分離させたいときに使うもののようです。
この FAQ と、この公開情報の注意書きの欄 を読んでもらうと判ると思います。
今回の検証では、プロファイルコンテナー のみを扱う事にします。
ファイル共有について
コンテナーを配置するための ファイル共有 は ドメインに参加されていて NTFSと共有の権限管理を行えることが要件になっていて、以下の４つの仕組みから選択することが一般的と思います（おそらくSMB＋Kerberos認証に対応しているストレージであれば良いのでしょう）
- Windows Server のファイルサーバー の機能 で提供される ファイル共有
- Azure ストレージアカウントの Azure Files で提供される ファイル共有
- Azure NetApp Files で提供される ファイル共有
- Windows Server と Azure Stack HCI で構成した 記憶域スペースダイレクト で提供された ファイル共有
今回の検証では、AVD の一般的な構成であり、コストも安価となる Azure ストレージアカウントのファイル共有を選択することにしました。
Windows ファイルサーバーを使う場合、ADサーバー と同居させて構築すればコスト安ではありますが、ファイルサーバーを独立させたり、冗長化したりを考えると Azure Files の方が安価になると思います。
そのため、検証用途なら Windowsファイル共有もあると思いますが、本番運用で採用されるのかは疑問であり、あえて記事化する意味も無くなってしまうと思い、採用しませんでした。とにかくFSLogix の機能を動かしてみたいという人は、Windowsファイルサーバーでやってみるのも手かと思います。
プロファイルコンテナー ＋ Azure Files の構築手順
次の２STEPで、手順を紹介します。
- Azure Files を構成し、ドメインに参加する
- 作成したファイル共有を FSLogix 向けに権限設定する
Azure Files を構成し、ドメインに参加する
この ファイル共有 の準備は、当初 それほど難しく考えていなかったのですが、これが 思っていたよりも大変でした。
この記事と一緒に掲載できないほどのボリュームとなったため、以下の記事で説明しています。
この記事で Azure Files の構成とドメイン参加 までを実施してください。
作成したファイル共有を FSLogix向けに権限設定する
この章では、上記の記事をもとに準備した ファイル共有に対して、FSLogix向けの追加設定を説明します。
- ドメイン参加済みのマシン（ADサーバー等）でエクスプローラーを開き、前章で構築済みの ファイル共有 へアクセスします。
- そこへ、fsl-profiles というフォルダを作成し、「プロパティ」－「セキュリティ」タブの順に開き、「詳細設定」を押します。
- 以下の「アクセス許可」画面が表示されますが、「継承の無効化」を押します。
既定の権限設定のままだと、管理者ではなく一般ユーザーが fsl-profiles フォルダや その配下のファイルを閲覧したり削除できたりしてしまうため、「継承の無効化」は必須です。
４. 以下の画面が表示されるため「このオブジェクトから継承されたアクセス許可を全て削除します。」を選択します。
５. 必要な権限を付与するため、「追加」ボタンを押します。
６. 以下の順にアクションします。
① 「プリンシパルの選択」を押す
② [CREATOR OWNER] と手入力する
③ 「名前の確認」を押す
④ CREATOR OWNER に下線が引かれた状態になったことを確認する
⑤ 「OK」を押す
７. 以下の下線の通り、プリンシパルに CREATOR OWNER が選択された状態になります。
[適用先] は、「サブフォルダーとファイルのみ」を選択し、
[基本のアクセス許可] は、「変更」にチェックを入れ、変更～書き込み の５つにチェックが入る事を確認します。
最後に、「OK」を押します。
８. 以下の画面に遷移するため、赤下線部と同一の設定になっていることを確認します。
続いて、「追加」を押します。
９. 項番６と同じ画面になるため、同様に 推奨される ACL に記載された設定になるように プリンシパルを追加していきます。
| プリンシパル | アクセス | 継承元 | 適用先 |
|---|---|---|---|
| CREATOR OWNER | 変更 | なし | サブフォルダーとファイルのみ |
| ドメイン名￥Domain Admins | フル コントロール | なし | このフォルダー、サブフォルダー、およびファイル |
| ドメイン名￥Domain Users | 変更 | なし | このフォルダーのみ |
１０. 最終的に 以下の設定値になったことを確認して、「OK」を押します。
設定ミスがあると、意図しなかった権限のユーザーにファイルを見られてしまったり、削除されてしまったり、FSLogix が機能しないなどの問題に関わるため、厳重にチェックしてください。
サインイン時に FSLogix を動作させるための GPO 設定
FSLogix は、クライアント上でユーザーがサインインする際に 動作する必要があります。
そのためには、ドメインコントローラーのグループポリシーで FSLogixのためのポリシー設定を行っておき、クライアントへ配布されたポリシー設定を使って、FSLogixのエージェントとOSが ユーザープロファイルの制御を行う・・・という感じで動作します。
今回の検証では、VMイメージ をデプロイしたあとに そのまま FSLogix を自動的に機能させたいため、ドメインコントローラーの グループポリシー を利用します。
そのための手順として、以下の２STEP を行います。
- ポリシーテンプレートのダウンロードと保存
- FSLogix のポリシー設定
ポリシーテンプレートのダウンロードと保存
-
以下の URL から、FSLogix アプリケーションをダウンロードして解凍します。
（アプリをインストールはしないので、注意してください）
https://aka.ms/fslogix_download -
ダウンロードして解凍すると、fslogix.adml と fslogix.admx というファイルがあるため、この２つだけ使用します。
-
この２つのファイルを、ドメインコントローラー の以下のフォルダへコピーします。
※フォルダが無い場合は 手動で作ってください（この場合、後述する セントラルストア の説明も参照ください）
| ファイルの種類 | ドメインコントローラーのファイルの場所 |
|---|---|
| fslogix.admx | %systemroot%\sysvol\domain\policies\PolicyDefinitions |
| fslogix.adml | %systemroot%\sysvol\domain\policies\PolicyDefinitions\ja-jp |
下図のように、admlファイル は、 ja-JPフォルダ の配下にコピー
admxファイル は、他の admxファイル と同じ場所にコピー
（参考：ドメイン ファイルの場所）
https://learn.microsoft.com/ja-jp/fslogix/how-to-use-group-policy-templates#domain-file-locations
（参考：セントラルストアについて）
ドメインコントローラーが ポリシーテンプレートを管理する方法として、ローカルストア と セントラルストア という仕組みがあります。
以下のサイトで解説されているのですが、内容が難しいと感じる人は 何も考えずに Sysvolフォルダ配下に PolicyDefinitions というフォルダを作ってください。
https://learn.microsoft.com/ja-jp/troubleshoot/windows-client/group-policy/create-and-manage-central-store#the-central-store
FSLogix のポリシー設定
FSLogix用の admx と adml ファイルが配置できたら、グループポリシーエディタを使って、FSLogix の設定ができるようになります。
- ドメインコントローラーで、「グループポリシーの管理」を開きます。
- AVD の VM が配置されている OU を右クリックし、「このドメインに GPO を作成し、このコンテナーにリンクする」を選択します。
- GPO の名称として、FSLogix などの判りやすい名称をつけて、「OK」を押します。
- 作成された GPO を右クリックして、「編集」を選択します。
- 赤枠の v を開いていきます。
緑下線のとおりに「FSLogix」が表示されない場合は、前章の admx と adml のコピーが適切に行われていません。見直してください。
- 上図で、赤下線で示した３項目のポリシー設定を行います。
| 項目名 | 値 | 詳細項目 |
|---|---|---|
| Enabled | 有効 | |
| Delete Local Profile When VHD Should Apply | 有効 | |
| VHD Locations | 有効 | \\carol0226storage.file.core.windows.net\share\fsl-profiles |
（VHD Locations の設定例）
７. 設定が全て完了したら、グループポリシー管理エディターを閉じます。
８. AVD の VM で、Gpupdate /force のコマンドを叩くか、再起動することで、このポリシーが適用され FSLogix が動作するようになります。
（参考：グループ ポリシー管理エディター）
https://learn.microsoft.com/ja-jp/fslogix/how-to-use-group-policy-templates#group-policy-management-editor
動作確認
サインイン画面での確認
うまく VM にポリシーが適用されると、以下の通り サインイン時に「FSLogix Apps Services の処理が完了するのをお待ちください」と表示されます。
この表示がされない場合は、ポリシーが VM に適用されていないことが疑われます。
ユーザープロファイルが VM を跨いで引き継がれていることの確認
AVD にサインインが成功したら、デスクトップ上にファイルを保存したり、壁紙を変更したりしてみてください。コマンドで ホスト名を確認して、そのあと、サインアウトします。
ホストプールに複数台の VM があれば、先ほどの VM を停止します。
再度 AVD にサインインした際に 先ほどの設定変更が 引き継がれていることが確認できます。コマンドで ホスト名を確認して、先ほどの VM名 とは違うことを確認します。
ストレージブラウザーに作成されたプロファイルの確認
ストレージブラウザーで確認すると、fsl-profiles の配下に フォルダが増えています。
さらに、そのフォルダを開くと、vhdファイル ファイルが存在する事が判ります。
管理者であれば、この vhdファイルを ストレージブラウザー から削除することも可能です。
その場合は、次回 ユーザーがサインインした場合に「初回ログオン」の扱いとなり 新たに プロファイル（vhdファイル）が作成されます。
VM にマウントされている プロファイルコンテナー の確認
ユーザーが、VM のローカル管理者権限を持っていれば「ディスクの管理」で ディスクの状態を見る事ができます。FSLogix の VHDファイルは、「ディスク2」としてマウントされていることが判ります。
下図では、testnogu と testnogu4 という２つのユーザーで 同じ VM に同時にサインインした場合です。このようにマルチセッションでサインインした場合は、複数のプロファイルが同時にマウントされていることが判ります。
他人のプロファイルを参照したり、削除したりできない事の確認
サインインしたユーザーが、プロファイルフォルダーへアクセスします。
２ユーザー分の プロファイルフォルダーが表示されますが、自分のフォルダにしかアクセスできないことを確認しましょう。
以下の通り、自分のフォルダ (testnogu) は、参照できます。
以下は、testnogu というユーザーが、testnogu4 というユーザーのプロファイルフォルダーを開こうとした場合です。開くこともできませんし、削除しようとしても消せない事が判ります。
これで、FSLogix をうまく機能させることができました。
おつかれさまです。
参考
いつも参考にさせていただいています。
くらう道：FSLogix Profile Container と Office Container を設定してみる！