はじめに

第1回の記事では、主なWindowsユーザープロファイル管理方法・検証環境の構築手順について紹介しました。 今回は、前回の記事の内容を踏まえて構築した環境を用いて、実際に検証し、その結果を紹介します。また、当社で開発、提供しているV-Boot ⧉との相性についても確認します。

検証の目的について改めて2点記載します。

• AVD（Azure Virtual Desktop）向けのプロファイル管理技術である「FSLogix」をV-Boot環境で利用した場合の有効性を確認する

• 第1回で紹介した各ユーザープロファイル管理方式の性能（主にログオン時間）を実際に比較し、相性を確認する

この記事は全2回の構成とし、以下の内容を紹介します。

• 第1回（前回掲載）
  • 主なWindowsユーザープロファイル管理方法
  • 検証環境の構成
  • 検証環境の構築手順
  • その他（所感）
• 第2回（この記事）
  • 検証観点
  • 検証パターン
  • 検証環境
  • 計測方法・算出方法
  • 計測結果
  • 考察

＜注意事項＞
本検証では動作の傾向をつかむため、検証パターンに極端な条件を設定しています。そのため、実際の導入先の環境でも今回の検証結果と同様のログオン・ログオフ時間になるとは限りません。
また、運用する際はユーザープロファイルデータの削減やファイルサーバーのストレージ設定の見直しなど、時間短縮の対策をしております。

検証観点

各ユーザープロファイル管理方式の性能をログオン時間で評価する場合、計測値はユーザープロファイルの内容や構成によって変わるため、それらの要素を含めて検証する必要があります。 ユーザープロファイルデータの構成要素として以下を検証観点に加えます。

また、ユーザープロファイル管理方式によってはログオフ時間も長くなるケースがあります。利用終了後となるため優先度は比較的低いですが、ログオン時間とセットで計測可能なため併せて計測します。

検証パターン

1. ユーザープロファイルサイズ

前述の観点を加味し、計測結果を上記の観点から考察できるよう、ユーザープロファイルの構成を以下のパターンで用意します。

• 「中」のパターンを平均的なモデルとし合計データサイズが異なる「小」「大」のパターンを用意
• 最小構成として「初期」のパターンを用意
• データ内訳の比較用に「比較用」のパターンを用意

また、ユーザープロファイルのデータを用意するにあたり、以下の形としました。

• ユーザープロファイル管理方式にかかわらずユーザーデータの条件を統一するため、ユーザープロファイルデータはDefaultプロファイルにためた状態で検証する

• ユーザープロファイルデータはアプリケーションによって傾向に差が出る可能性があるため、アプリケーションのインストール・利用によってユーザープロファイルデータをためるのではなく、ランダムなダミーデータを用意する

• ユーザープロファイルデータの配置先（Desktop・Documents・AppDataなど）によって影響の度合いに差が出る可能性があるため、一律に以下のパスに必要なサイズ・ファイル数のデータを配置する

  C:\users\Default\Desktop

2. ユーザープロファイルの生成状態

ファイルサーバー上にユーザープロファイルが生成される前の状態（初回ログオン）と、生成された後の状態（2回目以降のログオン）でパターンを分けます。

3. ユーザープロファイル管理方式

前回の記事ではユーザープロファイル管理方式を紹介しました。 「ローカルユーザープロファイル＋フォルダーリダイレクト」については、ローカルに保持するデータとファイルサーバー上にリダイレクトするデータがある構成のため、計測結果（ログオン時間）の評価が設定次第で変わる懸念があります。

前項でデスクトップにユーザープロファイルデータを配置していますが、検証として明確な差分を確認するため、比較で使用するユーザープロファイルの管理方式は、ローカルユーザープロファイルで検証します。 なお、ローカルユーザープロファイルはユーザープロファイルデータをサーバー上に保存する形式ではありません。 したがって、V-Bootのような環境復元システムの環境下では、再起動するとローカルユーザープロファイルのデータは削除されます。

なお、ローカルユーザープロファイルはユーザープロファイルデータをサーバー上に保存する形式ではないため、V-Bootのような環境復元システムの環境下においては再起動にてデータは消えます。

4. 計測項目

主目的である「ログオン時間」を計測しますが、検証の都合上ログオフもセットで作業するため「ログオフ時間」も参考として計測します。

検証環境

1. 検証環境の構成

今回の検証では、Hyper-V上に仮想環境を構築し、同一環境内で複数のユーザープロファイル管理方式を使用します。 また、クライアントについては実機で同機種の端末を使用します。

なお、前述のとおりローカルユーザープロファイル＋フォルダーリダイレクト方式は検証のブレを減らすため、ローカルユーザープロファイルにて検証します。

2. 機器スペック

※他用途の検証としても使用しているため、各機器のスペック値については検証に必要なスペック以上で用意しています。

3. 検証環境の条件

ログオン・ログオフ時間計測のブレ抑制のため、他サービスによる処理の影響については可能な範囲で除外します。

• ファイルサーバー

  • ユーザープロファイルデータの入出力が多いため、Windows Server 2025に標準搭載のMicrosoft Defender Antivirusのリアルタイム保護機能は無効化する
  • SSDへのアクセスはM.2 NVMe相当とする

• V-Bootサーバー

  • AET※による起動時間の高速化が適用されている状態を前提とする
    ※Alpha Elasticboot Technology。特許取得済みの当社独⾃技術により起動時間を⾼速化し、イメージ更新の繰り返しによる劣化も防⽌する機能です。
  • クライアントのIPアドレス割り当て方法はV-BootのDHCPサーバーを利用する
  • 計測中のV-Bootイメージ配信機能は使用しないものとする
  • V-Bootのジョブやライセンス管理機能などは使用しないものとする

• V-Boot機種設定

  • COW領域のサイズは、V-Bootクライアントサイジングツールの推奨値である40GBとする
    ※COW（Copy On Write）とは、起動したV-Bootクライアントの作業内容が保存される領域です。

• クライアント端末（実機）

  • SSDへのアクセスはM.2 NVMe相当とする
  • 充電状態で実施する
  • 無線LANはOFFにし、有線LANケーブル（1Gbps、カテゴリー5e以上）のみを使用するものとする

• クライアント端末（V-Bootイメージ）

  • Windows Updateは検証時点の最新版を適用するが、自動更新・自動ダウンロードは無効化する
  • Windows 11標準搭載のMicrosoft Defender Antivirusについて、ログオン前の状態からの機能停止が難しいため、動作・設定状態は初期状態とする
  • 壁紙は「Windows スポットライト」（自動で取得）
  • Microsoft Edgeは最新バージョンとする
  • バックグラウンドでのアップデート確認などの処理を除外するため、OS標準のもの以外のアプリケーションはインストールしない

• その他

  • インターネット通信は可能な状態とする
  • ネットワーク内に他の機器はない、または他の機器があっても影響を無視できるレベルとする

4. 検証に必要な設定（FSLogixのGPO制御）

第1回の記事にて検証環境の構築手順を紹介しましたが、検証を実施するうえで推奨される設定が追加で見つかりましたので、追加で設定項目を掲載します。

FSLogixにおけるVHD／VHDX形式ファイルのサイズ上限はデフォルトで30GBです。今回の検証ではユーザープロファイルを約50GBまで使用するため、上限値をあらかじめ100GBまで引き上げておきます。

• GPOへの設定項目追加
  • コンピューターの構成 ＞ ポリシー ＞ 管理用テンプレート ＞ FSLogix ＞ Profile Containers ＞ Size in MBs を「有効」かつ「30000」から「100000」に変更

また、FSLogixではファイルサーバー上のVHDXをマウントして利用する形式のため、複数ユーザーによる同時アクセスは仕組み上できません。 そのため、GPOに以下の設定を追加することで後からのログオンを防ぐことができます。今回の検証では、複数端末から同時にログオンする使い方は想定していませんが、以下の制御を追加します。

• GPOへの設定項目追加

  • コンピューターの構成 ＞ ポリシー ＞ 管理用テンプレート ＞ FSLogix ＞ Profile Containers ＞ Prevent login with failure を「有効」かつ「Enabled」に設定

  • コンピューターの構成 ＞ ポリシー ＞ 管理用テンプレート ＞ FSLogix ＞ Profile Containers ＞ Prevent login with temporary profile を「有効」に設定

設定後の挙動の詳細についてはMicrosoft Learn ⧉を参照してください。 なお、この設定がない環境で同時にログオンした場合、後からログオンした端末ではローカルユーザープロファイルとしてログオンされました。そのため、V-Bootの環境復元機能によりPC内に作成、保存したデータは次回起動時には削除されてしまいます。

計測方法・算出方法

1. 計測方法

• クライアントは計測するごとに再起動した状態で計測する（一度ログオンした場合、ユーザープロファイル管理方式によってはローカルにユーザープロファイルが残り、その影響で2回目以降の計測値が変わるため）

• ログオン・ログオフ時間の計測方法

  • システムログやイベントログからの算出ではなくストップウォッチを用いて目視で計測する

  • 画面の状態・ボタン押下などのタイミングで目視で計測する

  • 計測開始・停止タイミング

    • 計測開始：処理が開始されるタイミング（ログオン時のID・パスワードの入力時間は含めない）
    • 計測停止：画面が切り替わり、ログオン時はデスクトップ画面、ログオフ時はログオン画面が表示されたタイミング（初回ログオンで初期設定画面が表示される場合は、該当画面が出たタイミング）

2. 算出方法

• 計測値は整数値とし、小数点以下を四捨五入する（例：42.6秒の場合43秒とする）

• 5回計測し、その平均値を結果とする（例：40、43、43、38、50の場合は42.8秒とする）

計測結果

計測した結果を記載します。単位はすべて[秒]で記載しています。

ログオン時間

1. ユーザープロファイルサイズの影響

• ユーザープロファイルサイズが小→中→大と増加するのに伴い、ログオン時間は増加傾向
• 大についてはユーザープロファイルサイズがV-BootのCOW領域のサイズ以上であるため、ローカルユーザープロファイル・移動ユーザープロファイルはログオンできない想定だったが、実際にログオンを完了できなかった
• ユーザープロファイル生成後のFSLogixによるログオンでは、ユーザープロファイルサイズの増加による影響はほぼなし

2. ファイル数の影響（「中」「比較用」で比較）

• ユーザープロファイル生成前のログオン時、ローカルユーザープロファイル・移動ユーザープロファイルはローカル上にユーザープロファイルデータを生成するが、同じユーザープロファイルサイズであってもファイル数の差に伴いログオン時間は約3倍となった
• FSLogixでは約1.6倍となっており、他の方式よりは影響が少ないが増加傾向

3. ファイルサイズの影響（「小」「比較用」で比較）

• ユーザープロファイル生成前のログオン時、ローカルユーザープロファイル・移動ユーザープロファイルはローカル上にユーザープロファイルデータを生成するが、同じファイル数（5,000）であってもユーザープロファイルサイズ（1GBと10GB）によりログオン時間が1.6倍程度となった
• FSLogixでは3.6倍程度となり、他の方式よりも影響が大きい傾向
• 今回の検証結果では、FSLogixはファイル数よりも合計データサイズのほうが影響が大きい

4. ユーザープロファイルの生成状態（初回ログオン／2回目以降）の違い

• ローカルユーザープロファイルについては、V-Bootの場合は再起動によりリセットされるため対象外とした
• FSLogixでは2回目以降のほうがログオン時間は短い傾向があった。初回ログオン時にファイルサーバー上へユーザープロファイルデータを生成する影響だと考えられる
• 移動ユーザープロファイルは、初回ログオン時よりも2回目以降のほうがログオン時間が長い傾向にあった。理由は、移動ユーザープロファイルの挙動を整理することでわかるため、後述する

5. ユーザープロファイル肥大化時の挙動

• 前述したとおり、ローカルユーザープロファイル・移動ユーザープロファイルについてはCOW領域を超えるためログオンが完了しない
• 一方でFSLogixについてはファイルサーバー上にユーザープロファイルデータを展開するため、COW領域への影響があまりなくログオンに成功（ただしユーザープロファイルサイズが50GBのときはログオンに約39分（2315秒）かかる）

ログオフ時間

1. ログオフの挙動

• ローカルユーザープロファイルについては、ユーザープロファイルのサイズなどの影響は受けない
• 移動ユーザープロファイルについて、初回ログオフ時にユーザープロファイルのサイズに比例して増加する傾向
• FSLogixについては、基本的にはユーザープロファイルのサイズなどの影響を受けないが、ファイル数の増加に伴いログオフ時間もやや増加する傾向

考察

ユーザープロファイル管理方式ごとの考察

ローカルユーザープロファイル

• ログオン時はローカル上にユーザープロファイルを生成するため、ファイル数とファイルサイズに比例してログオン時間が長くなっている
• ログオフ時はユーザープロファイルサイズによる傾向はつかめなかったが、特別な処理がないため4～7秒程度と全体的に短時間で完了しているように見える
• V-Boot環境では、再起動によりユーザープロファイルデータが消えるため、毎回初回ログオンとなる。そのため、ユーザープロファイルサイズが大きい環境には不向きであり、ユーザープロファイルサイズを小さくする必要があると考えられる

移動ユーザープロファイル

• プロファイルの挙動を整理
  • 初回ログオン：ローカルでプロファイルを生成するため、ローカルユーザープロファイルと同程度の時間がかかる
  • 初回ログオフ：ローカルで生成したプロファイルをファイルサーバー上にアップロードするため比較的長い時間を要する
  • 2回目以降のログオン：ファイルサーバーからダウンロードする時間だけかかる
  • 2回目以降のログオフ：プロファイルに差分がなければ数秒レベルでログオフされる（ただし差分がある場合はその分だけ時間を要すると考えられる）
• ユーザープロファイルデータの増加に比例してログオン時間も延びるため、V-Bootとの相性は中程度と考えられる

FSLogix

• 2回目以降はプロファイルが肥大化しない限りは比較的短時間でログオンできている
• ユーザープロファイルデータが50GBでもログオンできたため、ログオン処理でのCOWの消費量が少ないと言える
• ただし、初回ログオン時については、他のユーザープロファイル管理方式と同様にユーザープロファイルデータに比例して増加する傾向がある
• また、ユーザープロファイルデータ肥大化時の影響としては、ログオン時間よりもログオフ時間のほうが増加する傾向にある
• 他のユーザープロファイル管理方式と比較してもV-Boot環境下でのログオン時間は短いため、相性はよいと言える

V-Bootと各ユーザープロファイル管理方式の相性

おわりに

今回、ログオン時間が長い問題に対しての1つの解決案としてFSLogixを使ったログオン時間の検証を実施しました。

FSLogixは、非永続型VDI環境のAzure Virtual Desktop（AVD）向けのプロファイル管理技術とされていますが、V-Bootのような環境復元システムを使った環境でも利用できることがわかりました。 この検証を通して、V-Bootのような環境復元システムでもFSLogixが有効な選択肢となる可能性がわかりました。 特に「環境復元システム＋移動ユーザープロファイル」という構成で運用している環境の場合、改善する可能性があるのではないかと感じました。

ただし注意点や未検証の部分もあるため、導入可否については以下も考慮しておいたほうがよいと考えます。

• 初回ログオンについては、アカウント発行時にあらかじめ実施しておくほうがよい
• ファイルサーバー側に必要な容量は他の方式よりも増える可能性があるため、十分に確保しておいたほうがよい
• 複数ユーザーが同時ログオンする環境ではファイルサーバーのストレージ性能が影響してくる可能性がある

ここまで読んでいただきありがとうございます。 2回にわたってユーザープロファイル管理方式・V-Bootとの相性について紹介しましたが、いかがだったでしょうか。この記事が何かの参考になれば幸いです。

なお、この記事では対象外としましたが、OneDrive KFMを使った方式についても関心が高いためこちらも気になるところではあります。 また機会がありましたら、検証し、紹介できればと思います。