Azure Virtual Desktop（AVD）の FSLogix プロファイルが肥大化してきて、「ドキュメント」だけはコンテナーに入れたくない、という要件はかなりよくあります。本記事では、Entra ID 参加の AVD 環境を前提に、redirections.xml を使って「ドキュメント」フォルダーだけをプロファイル コンテナーから除外する具体的な手順と設計ポイントを、実運用寄りに整理します。
Azure Virtual Desktop と FSLogix プロファイルの前提整理
まずは前提から軽く整理します。
- FSLogix プロファイル コンテナーは、ユーザーの Windows プロファイル（
C:\Users\<ユーザー名>）全体を VHD/VHDX にリダイレクトする仕組みです。典型的には SMB 共有上にコンテナーが置かれます。 - ODFC コンテナー（Office データ専用）は、プロファイル コンテナーを使っている場合は基本的に不要です。
- redirections.xml は、「プロファイル コンテナーの中から一部フォルダーだけ除外したい」ときに使う XML で、プロファイル コンテナー内の
%USERPROFILE%\AppData\Local\FSLogix\redirections.xmlに配置されます。 - redirections.xml 自体は、セッションホストが参照する ソース パス（共有フォルダー）からコピーされます。このソース パスをレジストリ値
RedirXMLSourceFolderで指定します。 - redirections.xml は「プロファイル コンテナー」に対してのみ有効で、ODFC コンテナー単体では効きません。
なお、最近の既知の問題として「Entra ID のみ参加」のデバイスでは FSLogix のアプリケーション ルール関連でイベント ID 26 が多く出ることがありますが、FSLogix チームは現在のところ無視してよい情報メッセージと位置づけています（ルールセットを使っていない環境でも出る）。
ドキュメントだけを除外する redirections.xml の最小構成
ドキュメントを除外する最小サンプル
「ユーザーの ドキュメント フォルダーだけを FSLogix プロファイル コンテナーから除外したい」だけであれば、次のような最小構成の redirections.xml で十分です。
<?xml version="1.0" encoding="UTF-8"?>
<FrxProfileFolderRedirection ExcludeCommonFolders="4">
<Excludes>
</Excludes>
<Includes>
</Includes>
</FrxProfileFolderRedirection>
ExcludeCommonFolders は「既知フォルダー（Known Folders）」を一括で除外するためのビットマスクです。Microsoft のドキュメント上、値 4 が「Documents（ドキュメント）」に割り当てられています。
ファイル名は必ず redirections.xml にし、文字コードは UTF-8（BOM 付き／なしどちらでも可）で保存するのが無難です。
ExcludeCommonFolders ビットマスク一覧
複数フォルダーをまとめて除外したいときは、下の表で値を足し合わせていきます。
| 値 | 対象フォルダー（英語名） | 対象フォルダー（日本語 UI の例） | 主な用途 |
|---|---|---|---|
| 1 | Contacts | 連絡先 | あまり使われないことが多い |
| 2 | Desktop | デスクトップ | デスクトップをコンテナーから除外 |
| 4 | Documents | ドキュメント | 本記事の主役 |
| 8 | Downloads | ダウンロード | 一時ファイルが多く肥大化しがち |
| 16 | Links | リンク | クイックリンクなどのショートカット |
| 32 | Music | ミュージック | 業務環境ではあまり使わないことが多い |
| 64 | Pictures / Videos | ピクチャ / ビデオ | 画像・動画データをコンテナーから外したいとき |
| 128 | Low Integrity （AppData\LocalLow 等） | 低整合性フォルダー | ブラウザー等の一部キャッシュ |
たとえば「ドキュメント（4）とダウンロード（8）を除外」したい場合は、4 + 8 = 12 と計算し、ExcludeCommonFolders="12" と指定します。
redirections.xml の配置と RedirXMLSourceFolder の設定
ファイル共有の用意
redirections.xml は、セッションホストから参照できて、ユーザーが読み取り可能な共有フォルダーに置きます。
- 例：
\\fs01\FslogixConfig - ユーザーには読み取り権限のみを付与（変更・削除は不可）
- FSLogix コンテナー用の共有（
\\fs01\FslogixProfilesなど）とは分けておくと運用しやすい
この共有に redirections.xml をコピーします。
RedirXMLSourceFolder レジストリの設定
次に、FSLogix が redirections.xml を探しに行くフォルダーパスをレジストリで指定します。Microsoft の公式リファレンスでは、以下のように定義されています。
- レジストリ ハイブ:
HKEY_LOCAL_MACHINE - キー:
SOFTWARE\FSLogix\Profiles - 値名:
RedirXMLSourceFolder - 値の種類:
REG_SZ - 値: フォルダー パスのみ（例：
\\fs01\FslogixConfig）
ここで重要なのは、ファイル名 redirections.xml まで書かないことです。指定するのはあくまでフォルダー パスだけ、という点を公式ドキュメントも明示しています。
PowerShell で一括設定する例は次の通りです。
New-Item -Path "HKLM:\SOFTWARE\FSLogix\Profiles" -Force | Out-Null
New-ItemProperty `
-Path "HKLM:\SOFTWARE\FSLogix\Profiles" `
-Name "RedirXMLSourceFolder" `
-PropertyType String `
-Value "\\fs01\FslogixConfig" `
-Force | Out-Null
既に FSLogix プロファイル コンテナーを構成済みであれば、その他の FSLogix 設定（VHDLocations や Enabled など）はそのままで問題ありません。
設定が反映されるタイミング
redirections.xml は「ユーザーのサインイン時」に読み込まれ、必要に応じてプロファイル コンテナーへコピーされたあと適用されます。
- XML を更新したらユーザーのサインアウト → 再サインインが必須
- サインイン中に XML を書き換えても、そのセッション中には反映されない
適用確認：FSLogix ログと frx ツールでの検証
FSLogix Profile ログの確認
設定が正しく読み込まれているかを確認するために、FSLogix のログをチェックします。公式チュートリアルも同様の手順を案内しています。
- 対象ユーザーで AVD セッションにサインイン
- セッションホスト上で
C:\ProgramData\FSLogix\Logs\Profileを開く Profile-YYYYMMDD-HHmmss.logのような最新ログをメモ帳で開く[INFO] ===== Begin Session: StartShell付近を検索し、次のような記録があるか確認
[23:36:31.364][INFO] Configuration Read (REG_SZ): SOFTWARE\FSLogix\Profiles\RedirXMLSourceFolder. Data: \\fs01\FslogixConfig
[23:36:31.364][INFO] Attempting to copy: "\\fs01\FslogixConfig\Redirections.xml" to: "C:\Users\<ユーザー名>\AppData\Local\FSLogix\Redirections.xml"
[23:36:31.396][INFO] Redirections.xml copy success
上記のような「copy success」の行が出ていれば、redirections.xml のコピーと読み込みは成功しています。
frx list-redirects で実際のリダイレクトを確認
FSLogix には frx というコマンドライン ユーティリティが付属しており、現在有効なリダイレクト一覧を確認できます。
cd "C:\Program Files\FSLogix\Apps"
frx list-redirects
出力の中に、ユーザー プロファイルから local_<ユーザー名> 側へのリダイレクトが並んでいれば、redirections.xml の内容が実際のファイルシステム レベルで効いていることが確認できます。
除外された「ドキュメント」フォルダーの動作を理解する
local_%username% へのリダイレクトと削除タイミング
redirections.xml でフォルダーを除外すると、そのフォルダーの実体はセッションホスト上の C:\Users\local_<ユーザー名> 配下にリダイレクトされます。
- ユーザーから見るとパスは変わらず
C:\Users\<ユーザー名>\Documents - 実体の I/O は
C:\Users\local_<ユーザー名>\Documents側で発生 Copy="0"（後述の既定動作）の場合、サインアウト時にlocal_側のフォルダーは削除される
redirections.xml の仕様上、「Exclude / Copy=0」で除外したフォルダーは、サインイン時に空のフォルダーが local_%username% 配下に作られ、サインアウトで削除される、という動作が明示されています。
ExcludeCommonFolders も同じエンジンを使っているため、基本的な挙動は同じと考えてよいです。
つまり、「ドキュメント」を ExcludeCommonFolders=4 で除外すると、ユーザーが保存したファイルはそのセッション限りのローカル データとなります。
Copy 属性の違い（応用編）
redirections.xml の <Exclude> 要素に対しては、Copy 属性でコピー動作を制御できます。
| Copy 値 | 動作 | プロファイル コンテナーへの影響 | 典型的な用途 |
|---|---|---|---|
| 0（既定） | コンテナー側は触らず、 local_%username% に空フォルダーを作る | 既存データは残るが、以降の書き込みはローカルのみ。 サインアウト時にローカル側は削除。 | キャッシュや一時ファイルの「ローカル退避」 |
| 1 | コンテナー → local_%username% へコピー | コンテナー上の既存データを毎回ローカルへコピーして使用。 サインアウト時にローカルは削除。 | 読み取り中心で、毎回初期状態をコピーしたいケース |
| 2 | local_%username% → コンテナーへコピー | セッション中にローカルへ書き込み、サインアウト時にコンテナーへ反映。 | 特殊な要件向け（Microsoft サポートの指示がない限り推奨されない） |
| 3 | 1 + 2 の組み合わせ | サインイン時にコンテナーからローカルへコピーし、 サインアウト時にローカルからコンテナーへ戻す。 | 非常に限定的な用途のみ。テスト必須。 |
今回の「ドキュメント除外」は ExcludeCommonFolders のみで済むので、<Exclude> 要素を追加する必要はありませんが、他のフォルダーを細かく制御したい場合には Copy 値も理解しておくと設計の幅が広がります。
既存 VHD(X) 内のドキュメント データは自動では消えない
ここが実運用で非常にハマりやすいポイントです。
- redirections.xml に除外設定を追加しても、すでに VHD(X) 内に存在するドキュメントのデータは自動では削除されません。
- そのため、「除外したのに VHDX のサイズが全然減らない」という状態が普通に起こります。
- サイズ削減をしたい場合は、以下いずれかの対応が必要になります。
| 対応パターン | 概要 | メリット | デメリット / 注意点 |
|---|---|---|---|
| 不要データを手動削除 | メンテナンス時間に VHD(X) をマウントし、 ユーザーの Documents 内の不要ファイルを削除 | 細かくコントロールできる | 作業ミスによるデータ損失リスク。ユーザーとの調整が必要。 |
| プロファイル コンテナーを作り直す | 対象ユーザーの VHD(X) をバックアップのうえ削除し、 次回サインイン時に新規プロファイルを生成 | 最も確実にスリム化できる | アプリの個別設定やキャッシュがすべてリセットされる |
| スクリプトで自動削除 | サインイン後にコンテナー内の特定パスを 削除するスクリプトを実行 | 運用として回しやすい | スクリプトのバグによる影響が大きい。十分なテストとバックアップが必須。 |
FSLogix 自体には「コンテナーからデータだけきれいに削除する」ツールは用意されていないため、削除と VHD コンパクトの組み合わせでサイズを減らす、というスタイルになります。
ドキュメントを永続保管したい場合の設計パターン
「FSLogix のコンテナーからは除外したいが、ドキュメントのファイル自体は永続的に残したい」という場合は、別の仕組みでドキュメントの保管先を定義する必要があります。代表的なのは次の 2 パターンです。
パターン1：OneDrive Known Folder Move（KFM）と組み合わせる
OneDrive の Known Folder Move（KFM）機能を使うと、ユーザーの「デスクトップ」「ドキュメント」「ピクチャ」フォルダーを OneDrive にリダイレクトして保護・同期できます。
| 項目 | 内容 |
|---|---|
| 想定環境 | Microsoft 365 / OneDrive が利用可能な AVD ユーザー |
| 構成イメージ | FSLogix redirections.xml で ドキュメント（=4）を除外 Intune または GPO で OneDrive KFM を有効化 ユーザーのドキュメントは OneDrive <tenant> の Documents に保存 |
| メリット | AVD 外の PC / ブラウザーからも同じドキュメントにアクセスでき、バックアップや共有も OneDrive の仕組みで完結。 |
| 注意点 | 既に Windows フォルダー リダイレクト GPO でドキュメントを別場所へリダイレクトしている場合、そのままでは KFM ポリシーが動作しません。 フォルダー リダイレクトから KFM へ移行するときは、公式ドキュメントの手順（共有上のデータを事前に OneDrive へ移行 → GPO 無効化 → KFM 有効化）に従う必要があります。 |
パターン2：Windows フォルダー リダイレクト（GPO / Intune）と組み合わせる
従来型の Windows フォルダー リダイレクトを使うと、「ドキュメント」をオンプレミスのファイルサーバーなどにリダイレクトできます。
ただし、フォルダー リダイレクト GPO は「ドメイン参加クライアント」が前提です。AVD セッションホストが Entra ID のみ参加の場合は、そのままでは GPO を使えないため、Intune の設定カタログやスクリプトによる代替が必要になります。
| 項目 | 内容 |
|---|---|
| 想定環境 | オンプレ AD + ファイルサーバーを持っており、既にフォルダー リダイレクトを運用している / したい場合 |
| 構成イメージ | FSLogix redirections.xml でドキュメント（=4）を除外 ドキュメントをファイルサーバー（例：\\fs01\Home\%username%\Documents）へリダイレクト ローミングはフォルダー リダイレクト側で担保 |
| メリット | 既存のファイルサーバー ベースの運用をそのまま活かせる。バックアップやアクセス制御も従来通り。 |
| 注意点 | OneDrive KFM と同じフォルダーを二重にリダイレクトしないこと（公式にも非推奨）。 |
Entra ID 参加 AVD 環境ならではのチェックポイント
Entra ID 参加の AVD セッションホストで FSLogix + redirections.xml を使う際に意識したいポイントをまとめます。
- ファイル共有の認証方式
Azure Files や Azure NetApp Files を使う場合、「Entra ID 認証」「AD DS 認証」どちらを採用しているかで付与すべき権限が変わります。FSLogix コンテナー用共有と redirections.xml 用共有の両方で、ユーザーに適切な読み取り（と必要なら書き込み）権限があるかを確認します。 - イベント ログのノイズに惑わされない
前述の通り、Entra のみ参加デバイスでは FSLogix のアプリ ルール周りでイベント ID 26 が大量に出る既知の問題があり、現状は無視して良いとされています。これは redirections.xml の設定ミスとは無関係です。 - プロファイルのクリーンアップ ポリシー
FSLogix 導入前から存在するローカル プロファイルが残っていると、トラブルシューティングが複雑になります。「FSLogix コンテナーが適用されるタイミングでローカル プロファイルを削除する」設定（DeleteLocalProfileWhenVHDShouldApply）の有効化も検討してください。
実践チェックリスト（ドキュメント除外版）
ここまでを踏まえ、実際に構成するときのチェックリストをまとめます。
- □ redirections.xml を作成
ExcludeCommonFolders="4"を指定してドキュメントのみを除外- ファイル名は
redirections.xml、UTF-8 で保存
- □ 共有フォルダーを準備
- 例：
\\fs01\FslogixConfig - ユーザーには読み取り権限のみ付与（変更不可）
- 例：
- □ RedirXMLSourceFolder を設定
HKLM\SOFTWARE\FSLogix\Profiles\RedirXMLSourceFolder（REG_SZ）に\\fs01\FslogixConfigを設定- ファイル名は指定せず、「フォルダー パスのみ」であることを再確認
- □ FSLogix ログでコピー成功を確認
C:\ProgramData\FSLogix\Logs\ProfileのログでRedirections.xml copy successを確認- エラーや警告が出ていないかも合わせてチェック
- □ frx list-redirects で実際のリダイレクトを確認
frx list-redirectsの出力にlocal_%username%へのリダイレクトが含まれているか確認
- □ ドキュメントの永続化方針を決定
- OneDrive KFM で OneDrive に集約するのか
- 従来型のフォルダー リダイレクトでファイルサーバーに保存するのか
- ローカル退避（セッションごとの一時ストレージ）で割り切るのか
- □ 既存コンテナーのサイズ削減方針を決める
- マニュアル削除 / スクリプト削除 / コンテナー再作成 のどれで行くか
- 削除後は VHD コンパクト（FSLogix の自動コンパクト機能を含む）が効くことを確認
トラブルシューティングのコツ
最後に、実際によくあるハマりポイントと、その確認方法を一覧にしておきます。
| 症状 | よくある原因 | 確認・対処方法 |
|---|---|---|
ログに Redirections.xml copy success が出ない | 共有パスが間違っている / ユーザーに読み取り権限がない | ログの Configuration Read (REG_SZ): ... RedirXMLSourceFolder の行で、参照されているパスを確認。共有に実際にアクセスできるかテスト。 |
| ドキュメントがコンテナーに残り続ける | 既存データは redirections.xml では自動削除されない仕様 | メンテナンス手順（不要データ削除＋VHD コンパクト、またはコンテナー再作成）を計画する。 |
| ドキュメントがセッション間で残らない | Copy=0 と同じ挙動（ローカル退避）になっている | それが意図通りなら問題なし。永続化したい場合は OneDrive KFM やフォルダー リダイレクトで別途ローミングを設計する。 |
| Entra ID 参加環境で FSLogix のイベント ID 26 が多発 | 既知の挙動（アプリケーション ルールセットが DC に問い合わせられないため） | Known Issues ドキュメントで「無視してよい」と明示されていることを確認し、redirections.xml とは切り離して考える。 |
| サインインが極端に遅い / 失敗する | コンテナーがサイズ上限に達している、またはストレージが逼迫 | コンテナーの使用量と SizeInMBs の値、SMB 共有の空き容量を確認し、必要に応じてサイズ拡張や不要データの削除＋コンパクトを実施。 |
以上のポイントを押さえておけば、「ドキュメント」だけを FSLogix プロファイル コンテナーから外しつつ、必要に応じて OneDrive やフォルダー リダイレクトで永続化する、といったハイブリッド構成も安全に設計できます。まずは検証用の AVD ホストプールで redirections.xml の動作を試し、ログと frx ツールで挙動を一通り確認してから本番へ展開するのがおすすめです。
コメント