フォルダーリダイレクトや移動ユーザープロファイルをユーザーごとに容量制限するなら、Windows ServerのFile Server Resource Manager（FSRM）で親フォルダーへ「自動適用クォータ」を設定します。親全体へ一つのクォータを置くのではなく、既存・新規の各サブフォルダーへテンプレート由来の個別クォータを生成する点が要点です。2026年時点の公式資料ではWindows Server 2016〜2025が対象で、FSRMはNTFSと組み合わせて使います。
いきなりハードクォータで書き込みを止めず、まずソフトクォータと通知で実利用を測り、例外業務と復旧方法を確認してから制限へ進みます。
クォータ設計の前に決めること
- 対象がリダイレクト先、移動プロファイル、FSLogixコンテナーのどれか
- 1人あたりの通常使用量、増加率、最大ファイル、ピーク時の一時ファイル
- ソフトクォータで監視する期間とハードクォータへ移行する条件
- 80%、90%、100%などのしきい値と、メール・イベントログ・レポートの通知先
- 管理者、役員、大容量業務、サービスアカウントなど例外の承認と有効期限
- 上限到達時に利用者が削除・退避できる手順とヘルプデスク窓口
移動プロファイルはサインイン・サインアウト時に同期が発生し、上限到達でプロファイルが保存されないと設定消失や一時プロファイルにつながります。フォルダーリダイレクトでは、アプリが一時ファイルを同じ場所へ作る場合があります。単純な平均容量ではなく、ピーク、業務締め、Windows更新、Officeキャッシュを含めて観測します。
バックアップと前提確認
FSRMの設定、クォータテンプレート、通知、対象パスをエクスポートし、対象ファイルサーバーのバックアップが復元可能か確認します。サーバー名、ボリューム、ファイルシステム、クラスタ・DFS構成、共有名、空き容量、VSS、ウイルス対策の除外を台帳化します。Microsoftのトラブルシューティング資料ではFSRMはReFSを管理できないため、対象がNTFSであることを必ず確認します。
テスト用ユーザーとサブフォルダーを用意し、実利用者のプロファイルを実験に使いません。通知メールを使うならSMTP経路と送信元を検証し、個人名やファイル名をメール本文へ過剰に出さない設計にします。イベントログの保存期間と監視連携も確認します。
自動適用クォータを作成する
- サーバーマネージャーでFSRMが導入済みか確認し、変更承認と保守時間を確保します。
- FSRMの「Quota Templates」でテスト用テンプレートを作ります。最初はソフトクォータにし、容量としきい値通知を設定します。
- 「Quotas」からCreate Quotaを開き、ユーザーフォルダーを格納する親パスを指定します。
- 「Auto apply template and create quotas on existing and new subfolders」を選び、作成したテンプレートを指定します。
- 作成後に一覧を更新し、既存の各サブフォルダーと新規テストフォルダーへ個別クォータが生成されたことを確認します。
公式資料では、自動適用クォータは親へテンプレートを割り当て、既存と将来の各サブフォルダーに個別のクォータを作ります。すでに個別クォータがあるフォルダー、除外したい管理フォルダー、深い階層へどう適用されるかを検証します。親フォルダーそのものへ一つの上限を設ける通常クォータとは目的が異なります。
通知とハードクォータへの移行
ソフトクォータ期間中に、実際の使用量分布、上限超過者、増加速度、誤通知を確認します。しきい値は利用者通知だけでなく、管理者の容量計画へ使います。利用者へは具体的な空き容量、整理方法、申請先を示し、システムパスや他ユーザー名を含めません。スクリプト通知を設定する場合は、署名済み・レビュー済みの処理だけにし、クォータ到達を理由にファイルを自動削除しません。
ハードクォータへ変更すると、上限を超える書き込みが失敗します。Officeの保存、プロファイル同期、アプリ終了、サインアウトをテストし、利用者へ事前周知します。テンプレート変更を派生クォータへ反映する方法は便利ですが、全員へ同時に影響します。パイロット用テンプレートと本番用を分け、変更件数を確認してから適用します。
動作確認のシナリオ
- 既存ユーザーの容量が正しく表示される
- 新規ユーザーフォルダー作成時に自動でクォータが生まれる
- しきい値到達でイベントと通知が一度だけ期待どおり届く
- 上限未満では保存・サインアウト・再サインインが正常
- 上限超過時のエラーが利用者に理解でき、既存ファイルが壊れない
- 例外フォルダーと管理用フォルダーが意図せず制限されない
- バックアップ、復元、ウイルススキャン、インデックス処理が継続する
失敗時の分岐
クォータが生成されない場合は、対象ファイルシステム、親パス、FSRMサービス、テンプレート名、既存クォータ、イベントログを確認します。新規だけ生成されないのか、既存だけ不足するのかを分けます。通知だけ届かない場合は、容量制御そのものとSMTP・イベント転送を別に検証します。アクセス拒否はNTFS権限とクォータを混同しないでください。
利用者が保存できなくなった場合、緊急で上限を無制限にする前に、対象フォルダーと現在量、書き込み中アプリ、空き容量を確認します。承認済みの一時的な上限引き上げまたはソフトクォータへの戻しで業務を復旧し、期限を設定します。データを勝手に削除せず、所有者が整理します。
ロールバックと運用
変更前のFSRM構成を保存し、パイロットグループを旧テンプレートへ戻せるようにします。派生クォータを削除してもデータは消えませんが、監視と制限が失われます。切り戻し後に書き込み、サインアウト、再サインイン、通知停止を確認します。毎月の容量レポートと四半期の上限見直しを行い、単に容量を増やすだけでなく不要データの保管ルールを整えます。
容量制限だけでは解決しない問題
クォータは総容量を抑えますが、ファイル数、巨大な単一ファイル、重複データ、同期競合、長いパス、禁止拡張子を直接解決しません。FSRMのレポートやファイル分類、バックアップ製品の統計を使い、何が増えているかを確認します。動画やPST、ISOなど業務上不要な種類が多い場合も、いきなりファイルスクリーンで止めず所有者と代替保存先を決めます。
OneDrive Known Folder Moveなどクラウド同期へ移行する場合、従来のFSRM上限とクラウド容量、オンデマンド、保持、DLPを重複して設計しないようにします。移動プロファイルと同期フォルダーを同じ階層に混在させると、ログオン時間と競合が増える可能性があります。Microsoftの各製品要件と現行構成を比較します。
例外ユーザーの扱い
大容量業務の例外は個人名ではなく役割グループで管理し、標準値との差、業務理由、承認者、期限を台帳へ残します。人事異動後も高い上限が残らないよう、グループ変更とクォータ確認を同じ手順へ組み込みます。手動で一人ずつ上限を変えるとテンプレート更新から外れるため、例外用テンプレートを別に用意します。
上限を引き上げる前に、削除可能データ、別保管すべき記録、法定保持、バックアップ重複を確認します。容量不足がサーバーボリューム全体の空き不足なら、一人のクォータ変更では解決しません。ストレージ増設、アーカイブ、データライフサイクルを別の変更として計画し、復元時間も見積もります。
コメント