FSLogixを検証してみた

はじめに
学校のパソコン教室や公共施設のPCで、ログオンするまでに長い時間待たされた経験はありませんか?
学校などで多数のPCを共用利用する環境向けに、当社ではPC管理運用システム「V-Boot ⧉」や環境復元システム「V-Recover ⧉」を開発・提供しています。 これらの製品は、PCへのイメージ配信やクローニングによって端末環境を統一する機能や、利用者が設定を変更しても再起動によって元の状態へ戻せる環境復元機能を提供し、共有端末における運用負担を低減することができます。
このような環境復元型の運用において課題となるのが、「利用者ごとの設定やデータをどこに保存するか」という設計です。 Windows環境では、この課題に対して移動ユーザープロファイルやフォルダーリダイレクトといったWindows標準機能を利用し、ユーザーデータの一部または全部をファイルサーバーへ保存する方法が採られてきました。 また、ローカルユーザープロファイルを毎回初期化する運用を前提とし、利用者が必要に応じてUSBメモリーやファイルサーバーへデータを保存する方法もあります。
しかし、これらの方式にはそれぞれメリット・デメリットがあり、特にログオン時間に与える影響が課題となるケースがあります。実際に、V-Bootをご利用いただいているお客様から最も多く寄せられる要望の一つが「ログオン時間を短縮したい」というものです。 さらに、移動ユーザープロファイルはMicrosoft 365をはじめとする近年のクラウドサービスとの相性が必ずしも良いとは言えません。
こうした課題に対し、マイクロソフトは同様の課題がある非永続型VDI環境のAzure Virtual Desktop(AVD)向けにプロファイル管理技術として「FSLogix」を提供しています。 FSLogixはVDI環境だけでなく、通常のWindows PC環境でも利用できるため、V-Bootと組み合わせて利用した場合の有効性を確認することを目的として、検証環境を構築して評価を実施しました。
この記事は全2回の構成とし、以下の内容を紹介します。
- 第1回(この記事)
- 主なWindowsユーザープロファイル管理方法
- 検証環境の構成
- 検証環境の構築手順
- 第2回(次回予定)
- 検証内容および検証結果
また近年では、Microsoft 365の普及に伴い、OneDriveの既知フォルダーの移動(Known Folder Move: KFM)を利用してDesktopやDocumentsなどのユーザーデータをクラウド上で管理する構成も利用されています。この記事では主にオンプレミス環境を前提としたプロファイル管理方式を中心に紹介しますが、現在のユーザーデータ管理手法としてOneDrive KFMも選択肢の一つといえます。なお、今回はV-Bootとの組み合わせにおけるFSLogixの有効性評価を主目的としているため、OneDrive KFMについては検証対象外としています。
主なWindowsユーザープロファイル管理方法
1. ローカルユーザープロファイル
最もシンプルな方式であり、Windowsの標準的なユーザープロファイル管理方法です。 ユーザー情報は各PCのローカルディスクに保存されます。 そのため、通常のWindows PCでは再起動後も設定やデータが保持されます。
ローカル
C:\Users\user1
一方、V-BootおよびV-Recoverなどの環境復元システムと組み合わせた場合、ユーザープロファイルは復元対象領域に保存されるため、再起動時に初期状態に戻ります。その結果、利用者は毎回プロファイルの再作成やアプリケーションの初期設定処理が実行されるため、ログオン時間が長くなる場合があります。 また、プロファイル内に保存したデータも再起動によって失われるため、必要なデータはUSBメモリーやファイルサーバーなどへ明示的に保存する運用が必要です。
メリット:
- 構成がシンプル
- サーバーの追加が不要
- ネットワーク障害の影響を受けない
デメリット:
- 複数のPC間で設定を共有できない
- 環境復元システムとの組み合わせでは毎回初期状態に戻る
- ユーザーデータの保存場所を別途用意する必要がある
2. 移動ユーザープロファイル(Roaming Profile)
利用者が複数のPCを使用する場合でも、同じデスクトップ環境や設定を利用できるようにするために提供された仕組みが「移動ユーザープロファイル」です。 ユーザープロファイルはファイルサーバー上に保存され、利用者はどのPCにログオンしても同じ環境を利用できます。
サーバー
\\FileServer\Profiles\user1動作の流れは以下のとおりです。
- ログオン時にファイルサーバーからプロファイルをPCへコピー
- 利用者がPCを使用
- ログオフ時に変更されたプロファイルをファイルサーバーへ保存
この方式によって、壁紙・アプリケーション設定・各種ユーザー設定を複数のPC間で共有できます。

一方で、環境復元システムと組み合わせた場合は課題があります。ログオン時に取得したプロファイルデータは再起動時に削除されるため、毎回ログオンのたびにファイルサーバーからプロファイル全体を取得する必要があります。 その結果、授業開始前など多数の利用者が同時にログオンする環境では、ネットワークやファイルサーバーへ大きな負荷が発生し、ログオン時間の増加やログオン失敗の原因となることがあります。 また、プロファイルサイズが大きくなるほどログオン時のダウンロード、およびログオフ時のアップロードに時間がかかるため、運用を続ける中で性能問題が発生しやすいという特徴があります。
メリット:
- 複数のPCで同じユーザー環境を利用できる
- ユーザーデータをサーバー上で管理できる
- PC交換時の移行が比較的容易
デメリット:
- プロファイルサイズが肥大化するとログオン・ログオフ時間が長くなる
- 一斉ログオン時にネットワーク負荷が集中する
- Microsoft 365などの最新アプリケーション環境では運用上の課題が発生することがある
3. フォルダーリダイレクト
フォルダーリダイレクトは、ユーザープロファイル内の特定フォルダー(Desktop・Documents・Picturesなど)の保存先を、ファイルサーバー上の共有フォルダーへ変更する機能です。 例えば「Documents」フォルダーをフォルダーリダイレクトした場合、利用者は通常のドキュメントフォルダーとして利用しているつもりでも、実際の保存先はファイルサーバー上になります。
サーバー
\\FileServer\Home\user1\(Desktop・Documentsなど)ローカル
C:\Users\user1\(上記以外)フォルダーリダイレクトでは、利用時に直接ファイルサーバー上のフォルダーへアクセスします。そのため、移動ユーザープロファイルのようにログオン時にデータをダウンロードし、ログオフ時にアップロードするといった同期処理は発生しません。 そのため、移動ユーザープロファイルで課題となる大容量データの同期負荷や、ログオン・ログオフ時間の増加を抑えることができます。

また、フォルダーリダイレクトはローカルユーザープロファイル・移動ユーザープロファイルのいずれとも組み合わせて利用できます。 特にローカルユーザープロファイルと組み合わせた場合、環境復元システムによってローカルユーザープロファイルが再起動時に初期化される環境でも、DesktopやDocumentsなどに保存されたユーザーデータを保持することができます。 一方で、フォルダーリダイレクトの対象となるのは指定したフォルダーのみです。そのため、アプリケーション設定やユーザープロファイル全体を保持することはできず、利用するアプリケーションによっては期待どおりに動作しない場合があります。
メリット:
- ユーザーデータをサーバー上で保管できる
- ログオン・ログオフ時の同期負荷を低減できる
- 環境復元型の環境でもユーザーデータを保持できる
デメリット:
- アプリケーション設定は保存できない
- ネットワーク障害の影響を受ける(リダイレクト先となるDesktop・Documentsへのアクセスができなくなる)
4. FSLogix
FSLogixは、ファイルサーバー上に保存されたVHD/VHDXファイルをユーザープロファイルとして利用する仕組みです。 ユーザーごとに割り当てられたVHD/VHDXファイルをログオン時にマウントし、Windowsからは通常のローカルユーザープロファイルとして認識されます。
サーバー
\\FileServer\FSLogix\user1\Profile_user1.vhdx
移動ユーザープロファイルでは、ログオン時にプロファイルをPCへダウンロードし、ログオフ時に変更内容をサーバーへアップロードする必要があります。一方、FSLogixではプロファイル全体のコピーは行わず、VHD/VHDXファイルのマウントおよびアンマウントによって利用します。 そのため、移動ユーザープロファイルで課題となるログオン時・ログオフ時の大量データ転送が発生せず、一斉ログオン時におけるネットワークやファイルサーバーへの負荷を大幅に低減できます。 また、環境復元システムと組み合わせた場合でも、ユーザープロファイルの実体はファイルサーバー上のVHD/VHDXファイルに保存されるため、再起動のたびにローカルユーザープロファイルを再作成する必要がありません。 そのため、環境復元型の環境においては、ローカルユーザープロファイル方式や移動ユーザープロファイル方式と比較してログオン時間の短縮が期待できます。
メリット:
- ユーザープロファイル全体を保持できる
- 大容量プロファイルに強い
- Microsoft 365やOutlookとの親和性が高い
デメリット:
- VHD/VHDXファイルの管理が必要
- ネットワーク障害時に影響を受ける(アプリケーションの設定なども含めユーザープロファイル部分全体がアクセスできなくなる)
検証環境の構成
今回の検証では、Hyper-V上に仮想環境を構築し、同一環境内で複数のプロファイル管理方式を比較します。 なお、クライアントについては実機で同機種の端末を使用します。

検証用アカウント
| ユーザーID | プロファイル管理方式 | プロファイルパス | GPO |
|---|---|---|---|
| user1 | ローカルユーザープロファイル+ フォルダーリダイレクト | 未設定 | 未設定 |
| user2 | 移動ユーザープロファイル | \\FileServer\Profiles\%username% | 未設定 |
| user3 | FSLogix | 未設定 | VHDLocations |
検証環境の構築手順
フォルダーリダイレクト環境の構築手順
-
1.プロファイルデータ保存場所の作成
-
ファイルサーバー上のリダイレクトデータ保存用ドライブの配下で共有フォルダーを作成
D:\Home -
共有アクセス許可を設定
- フォルダーのプロパティ > [共有]タブ → 詳細な共有 → アクセス許可
- Everyone(またはAuthenticated Users)を追加しフルコントロールに設定

-
NTFS権限を設定
- フォルダーのプロパティ > [セキュリティ]タブ > 詳細設定
- 以下の権限を設定
SYSTEMフルコントロールAdministratorsフルコントロールDomain AdminsフルコントロールDomain Usersこのフォルダーのみフォルダー作成データ追加Creator Ownerサブフォルダーとファイルのみフルコントロール
-
-
2.ユーザーの作成
- ADサーバー上でユーザー作成
- 「Active Directory ユーザーとコンピューター」を起動
- 必要なOU配下で「新規作成」 > 「ユーザー」から検証用アカウントのユーザー user1 を作成
- ADサーバー上でユーザー作成
-
3.GPOの作成/対象アカウントの制御
-
OUの作成
- ADサーバー上で「Active Directory ユーザーとコンピューター」を起動
- 任意のOU配下で「新規作成」 > 「組織単位(OU)」 > FolderRedirectTest など任意の名前を付ける
- ローカルユーザープロファイル+フォルダーリダイレクトとして使用する検証端末(ここではPC-A)を作成したOU配下に移動
-
GPOの作成
- ADサーバー上で「グループポリシーの管理」を起動
- 「グループ ポリシー オブジェクト」を右クリックし「新規」 > フォルダーリダイレクト用ポリシーなど任意の名前を付ける
- 作成したグループポリシーを右クリックし「編集」
- ユーザーの構成 > ポリシー > Windowsの設定 > フォルダーリダイレクト > デスクトップ を右クリックし「プロパティ」
・設定 :基本 - 全員のフォルダーを同じ場所にリダイレクトする・対象フォルダーの場所 :ルートパスの下に各ユーザーのフォルダーを作成する・ルートパス :\\FileServer\Home- ユーザーの構成 > ポリシー > Windowsの設定 > フォルダーリダイレクト > ドキュメント を右クリックし「プロパティ」から同様の設定をする
-
GPOのリンク
- ADサーバー上で「グループポリシーの管理」を起動
- 作成したOUを右クリックし「既存のGPOのリンク」 > 作成したGPOを選択し「OK」
-
-
4.動作確認
- クライアント端末を起動後、user1でログオン
- ファイルサーバー上のフォルダーリダイレクト保存用フォルダー配下にプロファイルおよびリダイレクトしたファイルが生成されることを確認
D:\Home\user1\├─ Desktop└─ Documents - クライアントのデスクトップに適当なファイルを作成し、再起動・再ログオン後に維持されることを確認(フォルダーリダイレクト環境ではない場合、V-Bootの環境復元機能により消える)
- クライアント端末を起動後、user1でログオン
移動ユーザープロファイル環境の構築手順
-
1.プロファイルデータ保存場所の作成
-
ファイルサーバー上の移動ユーザープロファイルデータ保存用ドライブの配下で共有フォルダーを作成
D:\Share -
共有アクセス許可を設定(フォルダーリダイレクト環境構築時と同様の手順)
-
NTFS権限を設定(フォルダーリダイレクト環境構築時と同様の手順)
-
-
2.ユーザーの作成
- ADサーバー上でユーザー作成
- 「Active Directory ユーザーとコンピューター」を起動
- 必要なOU配下で「新規作成」 > 「ユーザー」から検証用アカウントのユーザー user2 を作成
- 作成したユーザーを右クリックし「プロパティ」 > 「プロファイル」 > 「プロファイル パス」を設定
\\FileServer\Share\%username%
- ADサーバー上でユーザー作成
-
3.動作確認
- クライアント端末を起動後、user2でログオン
- ファイルサーバー上の移動ユーザープロファイル保存用フォルダー配下にプロファイルが生成されることを確認
Windows 10/11 では、一般的に末尾に「.V6」が付与されます。D:\Share\user2.V6 - クライアントのデスクトップに適当なファイルを作成し、再起動・再ログオン後に維持されることを確認(移動ユーザープロファイル環境ではない場合、V-Bootの環境復元機能により消える)
- クライアント端末を起動後、user2でログオン
FSLogix環境の構築手順
-
1.プロファイルデータ保存場所の作成
-
ファイルサーバー上のプロファイルデータ保存用ドライブの配下で共有フォルダーを作成
D:\FSLogix -
共有アクセス許可を設定(フォルダーリダイレクト環境構築時と同様の手順)
-
NTFS権限を設定(フォルダーリダイレクト環境構築時と同様の手順)
-
-
2.ユーザーの作成
- ADサーバー上でユーザー作成
- 「Active Directory ユーザーとコンピューター」を起動
- 必要なOU配下で「新規作成」 > 「ユーザー」から検証用アカウントのユーザー user3 を作成
- ADサーバー上でユーザー作成
-
3.GPO環境の用意、GPOテンプレートの登録
- GPO環境の用意(ドメイン名をcontoso.localとする)
- ADサーバー上にポリシーファイルがあるか確認する
\\localhost\SYSVOL\contoso.local\Policies\PolicyDefinitions- 中央ストアが存在しない場合のみ実施
コピー元C:\Windows\PolicyDefinitionsコピー先\\localhost\SYSVOL\contoso.local\Policies\PolicyDefinitions - FSLogix用のポリシーテンプレートの登録
- FSLogixをダウンロードしZIPファイル内のfslogix.admxおよびfslogix.admlを取得
- fslogix.admxとfslogix.admlを以下のような構成で配置
\\localhost\SYSVOL\contoso.local\Policies\PolicyDefinitions│├─ fslogix.admx│├─ en-US│ └─ fslogix.adml│└─ ja-JP└─ fslogix.adml
- GPO環境の用意(ドメイン名をcontoso.localとする)
-
4.GPOの作成/対象アカウントの制御
-
OUの作成
- ADサーバー上で「Active Directory ユーザーとコンピューター」を起動
- 任意のOU配下で「新規作成」 > 「組織単位(OU)」 > FSLogixTest など任意の名前を付ける
- FSLogixとして使用する検証端末(ここではPC-C)を作成したOU配下に移動
-
GPOの作成
- ADサーバー上で「グループポリシーの管理」を起動
- 「グループ ポリシー オブジェクト」を右クリックし「新規」 > FSLogix用ポリシーなど任意の名前を付ける
- 作成したグループポリシーを右クリックし「編集」
- コンピューターの構成 > ポリシー > 管理用テンプレート > FSLogix > Profile Containers > Enabled を「有効」かつ「Enabled」に設定
- コンピューターの構成 > ポリシー > 管理用テンプレート > FSLogix > Profile Containers > VHD Locations を「有効」かつプロファイルパスを設定(
\\FileServer\FSLogix)など
なお、FSLogixはユーザーの構成配下にはポリシーが作成されません。したがって、コンピューター単位で設計・設定する必要があります。
-
GPOのリンク
- ADサーバー上で「グループポリシーの管理」を起動
- 作成したOUを右クリックし「既存のGPOのリンク」 > 作成したGPOを選択し「OK」
-
-
5.クライアントにFSLogixインストール
- FSLogixをダウンロードしインストール(要再起動)
- FSLogixサービスが稼働しているか確認
Terminal window > sc query frxsvc以下の結果になることを確認する。
Terminal window STATE : RUNNINGTerminal window > reg query HKLM\SOFTWARE\FSLogix\Profiles以下の結果になることを確認する。
Enabled REG_DWORD 0x1VHDLocations REG_MULTI_SZ (FSLogix用の共有フォルダーのパス) -
6.動作確認
- クライアント端末を起動後、user3でログオン
- ファイルサーバー上のFSLogix保存用フォルダー配下にプロファイルおよびVHD/VHDX形式のファイルが生成されることを確認
D:\FSLogix\(SID文字列)_(ユーザーID)\Profile_user3.vhdx - クライアントのデスクトップに適当なファイルを作成し、再起動・再ログオン後に維持されることを確認(FSLogix環境ではない場合、V-Bootの環境復元機能により消える)
- クライアント端末を起動後、user3でログオン
-
(正常動作しない場合)
- FSLogixのイベントログを確認
イベント ビューアー└─ アプリケーションとサービス ログ└─ Microsoft└─ FSLogix└─ Apps└─ Operational- FSLogixの動作ログを確認
C:\ProgramData\FSLogix\Logs\Profile-YYYYMMDD.log
その他(所感)
この検証環境でログオン時間を測定したところ、それぞれの参考値は以下のとおりでした。
| プロファイル管理方式 | ログオン時間 |
|---|---|
| ローカルユーザープロファイル+フォルダーリダイレクト(初回ログオン時) | 49秒 |
| 移動ユーザープロファイル(プロファイル作成済み) | 46秒 |
| FSLogix(VHDX作成済み) | 34秒 |
ただし、プロファイルの中身についてはほぼ未カスタマイズの状態のため、ここからプロファイルデータを溜めていった場合に挙動も変わってくるのではないかと考えています。プロファイルデータの条件や検証環境のスペック、データ値などについては次回掲載予定ですので、楽しみにしていただけると幸いです。
なお、FSLogixではネットワーク接続が切れた場合にPCが一時的にフリーズ状態になったため、ネットワークが常時接続されている環境が望ましいといえます。
おわりに
今回は、ユーザープロファイル管理方式の紹介およびV-Boot環境におけるFSLogixとの相性を確認するための構成・環境構築手順について紹介しました。 プロファイルデータの管理方法は時代とともに変化しており、ユーザーにとって必要となるデータをどのように管理していくかは、本当に奥が深いものです。
次回は、この記事で紹介した検証環境を使用した検証内容およびその検証結果について掲載する予定です。ご興味のある方は、ぜひご覧ください。
記事の執筆にあたっては情報の正確性に努めておりますが、掲載されている文章やソースコード、設定ファイル等の内容について、完全な正確性や安全性を保証するものではありません。活用される際は、必ず公式ドキュメント等をご自身で確認のうえご判断ください。

