新しいドメイン環境でフォルダー リダイレクト用の GPO を作成したのに、ADUC（Active Directory ユーザーとコンピューター）のユーザー「Member Of（所属）」から GPO 名が検索できず、「追加できない＝適用できない」と感じてしまうケースがあります。これは設定ミスというより、GPO の仕組みに対する“前提”の取り違えが原因です。この記事では、正しい適用方法と、フォルダー リダイレクトで詰まりやすい共有・権限・確認ポイントまでまとめて解説します。
結論：GPO は「所属（Member Of）」で追加するものではない
まず押さえるべきポイントは、GPO はセキュリティグループではないという点です。
ADUC のユーザー画面にある「Member Of（所属）」タブは、ユーザーがどの“グループ”のメンバーかを管理するための場所です。ここに追加できるのは、基本的に以下のような “グループ オブジェクト” です。
| ADUC の「Member Of」で扱う対象 | 例 | 用途 |
|---|---|---|
| セキュリティ グループ | Domain Users / FolderRedirectionUsers | アクセス制御、GPO の絞り込み（セキュリティ フィルタリング）など |
| 配布グループ | Sales-ML | メール配布など（アクセス制御には基本不向き） |
| GPO（グループ ポリシー オブジェクト） | HPRS Folder Redirection など | 対象外（グループではない） |
つまり、ADUC の「オブジェクト名を入力」欄に GPO 名を入れても見つからないのは自然な挙動です。GPO を “所属に追加” する概念はありません。
GPO を適用する正しい基本：OU にリンクして、そこにユーザーを置く
GPO はユーザーやコンピューターに直接「所属」させるのではなく、OU（組織単位）やドメイン、サイトにリンクして適用範囲を決めます。フォルダー リダイレクトは原則としてユーザーのポリシーなので、基本形は次の通りです。
- フォルダー リダイレクト用の GPO を作る
- その GPO を対象ユーザーが入っている OUにリンクする
- 必要に応じてセキュリティ フィルタリングで対象を絞る
- クライアントでログオンしてポリシー処理（必要に応じて
gpupdate）
質問の例で言うと、GPO を HPRS Groups OU にリンクしているのに、ユーザー mark が別の OU（または既定のコンテナー）にいる場合、GPO は期待通り当たりません。重要なのは「リンク先」と「ユーザーの所在」が一致していることです。
よくある見落とし：「Users」コンテナーは OU ではない
新規構築で特に多いのが、ユーザーを既定の Users コンテナーに置いたまま、別の OU に GPO をリンクしてしまうパターンです。
Usersは多くの環境で “既定の置き場” として存在しますが、OU とは違うオブジェクトです（そのため設計上の扱いも変わります）。- 実運用では、ユーザー用 OU（例：
HPRS Users）を作り、ユーザーを移動して、その OU に GPO をリンクするのが分かりやすいです。
「GPO をユーザー作成前に作った」ことは問題にならない
GPO を先に作ったか、ユーザーを先に作ったかは関係ありません。必要なのは次の 2 点だけです。
- GPO が正しい場所（OU/ドメイン/サイト）にリンクされている
- ユーザーがそのスコープに含まれている（＝同じ OU 配下、継承範囲内など）
作成順ではなく、最終的な配置とリンクで決まります。
GPO の適用範囲を決める仕組みを“短く”理解する
トラブルを早く切り分けるために、GPO が効く条件を整理します。
| 観点 | 何を見る？ | よくある「効かない」原因 |
|---|---|---|
| リンク | GPO がどこにリンクされているか | リンク先 OU が違う／リンクが無効／継承がブロック |
| 対象オブジェクト | ユーザーがどの OU にいるか | ユーザーが別 OU、既定コンテナーのまま |
| セキュリティ フィルタリング | Security Filtering / Delegation | Read はあるが Apply がない、逆に読み取り不可 |
| ポリシーの種類 | ユーザー構成か、コンピューター構成か | フォルダー リダイレクトはユーザー側。PC の OU にリンクしても期待通りにならない |
| 優先順位・競合 | リンク順、上位 OU の設定 | 別 GPO が上書き、ループバック処理で想定外 |
| クライアント処理 | ログオン、gpupdate、イベントログ | ログオンしていない／オフライン／共有権限エラー |
フォルダー リダイレクト GPO を正しく適用する手順
OU を決める（ユーザー用 OU を作るのが基本）
フォルダー リダイレクトはユーザー設定です。まず「対象ユーザーを置く OU」を決めます。例として以下のような構成が分かりやすいです。
HPRS.local
├─ HPRS Users（ユーザーを置く）
├─ HPRS Computers（PCを置く）
└─ HPRS Groups（グループを置く）ポイントは、グループ置き場の OU（例：HPRS Groups）にユーザー GPO をリンクしても、そこにユーザーがいなければ効かないということです。名前が似ている OU を作っていると混乱しやすいので、役割を明確にするのがおすすめです。
GPMC で GPO をリンクする
「グループ ポリシーの管理（GPMC）」で以下を確認します。
- 作成した GPO（例：
HPRS Folder Redirection）が存在する - 対象ユーザーが入っている OU（例：
HPRS Users）を右クリック →「既存の GPO をリンク」 - リンクした GPO が「リンク有効」になっている
この時点で「Authenticated Users」が残っていれば、その OU 配下の通常ユーザーには適用される状態になります（詳細な絞り込みをしない限り）。
ユーザーを OU に移動する
ADUC でユーザー（例：mark）を、GPO をリンクした OU に移動します。OU の移動は構造変更なので、管理チーム内でルールがある場合はそれに従ってください。
クライアントでログオンしてポリシー処理を発生させる
フォルダー リダイレクトは、対象ユーザーでクライアントにログオンしたタイミングで処理されます。反映確認の基本は以下です。
- ログオフ → ログオン（これが最優先）
- 必要に応じて管理者でコマンド実行：
gpupdate /force
ログオンの前に「設定したはずなのに動かない」と悩むことがあるので、まずはログオンで必ず処理が走る点を意識します。
特定ユーザーだけに当てたい場合：セキュリティ フィルタリングで絞る
「OU にリンク＝その OU のユーザー全員」が基本です。そこから、特定ユーザーや特定グループだけに適用したい場合は、セキュリティグループを作って絞るのが定石です。
おすすめの構成：対象者用セキュリティグループを作る
例：
- グループ名：
FolderRedirectionUsers - メンバー：フォルダー リダイレクト対象のユーザー（例：
mark）
そして GPO の「Scope（スコープ）」で Security Filtering を次のようにします。
| やりたいこと | Security Filtering の例 | 運用メモ |
|---|---|---|
| OU 配下の全員に適用 | Authenticated Users のまま | まずはこれで動作確認すると切り分けが早い |
| 特定ユーザーだけに適用 | FolderRedirectionUsers を追加し、Authenticated Users を削除（または Apply を外す） | Read と Apply group policy の両方が必要 |
| 段階導入（テスト→本番） | テスト用グループ→本番用グループへ段階的にメンバー追加 | 影響範囲をコントロールしやすい |
「Read はあるのに効かない」を防ぐ：Delegation で権限を確認
Security Filtering を触った後に増えるのが、GPO を読めるが適用されない／そもそも読めない系の事故です。GPMC の「Delegation（委任）」→「Advanced（詳細）」で、対象ユーザーまたはグループに以下が付いているか確認します。
- Read
- Apply group policy
特に、Authenticated Users を消した場合は「コンピューターアカウントが GPO を読めない」状態になることがあります。環境や設計により方針は異なりますが、迷ったら次の考え方が安全です。
Authenticated Users：Read のみ（Apply なし）- 対象グループ（例：
FolderRedirectionUsers）：Read + Apply
この形だと、GPO 自体は読めるが、適用は対象だけという状態にできます。
フォルダー リダイレクトは「共有パスと権限」が原因で失敗しやすい
GPO が“当たっている”のに、実際のリダイレクトが失敗しているケースも多いです。フォルダー リダイレクトは、最終的に「ファイルサーバー（共有）」へアクセスできないと成立しません。
ルートパスは UNC 共有を使う
一般的に、フォルダー リダイレクトのルートには UNC を使います。
- 例：
\\mail.hprs.local\Users - 例（隠し共有にする）：
\\mail.hprs.local\Users$
フォルダー リダイレクトの設定画面で「各ユーザーにフォルダーを作成する」系のオプションを選ぶと、ユーザーごとに自動でフォルダーが作られます。典型的なイメージは以下です。
\\mail.hprs.local\Users\
├─ mark\
│ ├─ Documents
│ ├─ Desktop
│ └─ ...
├─ userA\
└─ userB\権限設計の目安（共有権限と NTFS 権限）
権限は環境の方針（管理者が中身を見られるべきか、完全にユーザー専用にするか、バックアップ運用はどうするか）で正解が変わりますが、トラブルを減らす“目安”を示します。
共有権限（Share Permissions）はシンプルにし、実制御は NTFS で行うのが運用しやすいです。
| 権限の種類 | 推奨の考え方 | 例 |
|---|---|---|
| 共有権限 | 極力ゆるく（NTFS で締める） | Everyone または Authenticated Users：フルコントロール |
| NTFS 権限（ルート） | ユーザーは自分のフォルダーだけ作れて、他人のフォルダーは見えない | 下記の例参照 |
NTFS（ルートフォルダー）の一例（代表的なパターン）です。GUI での指定はやや複雑なので、意図が伝わる形でまとめます。
| 主体 | 権限 | 適用先の考え方 |
|---|---|---|
SYSTEM | フルコントロール | このフォルダー、サブフォルダー、ファイル |
Domain Admins（または管理者グループ） | フルコントロール | このフォルダー、サブフォルダー、ファイル |
CREATOR OWNER | フルコントロール | サブフォルダーとファイルのみ（＝作成者が自分の配下を完全制御） |
Authenticated Users | フォルダー作成／フォルダー一覧（必要最小限） | このフォルダーのみ（＝ルート直下に自分のフォルダーを作れる） |
この手の権限がズレていると、GPO は適用されたように見えても、実際のフォルダー作成・移動処理が失敗します。特に「ルートにフォルダーを作れない」「他人のフォルダーが見えてしまう」の 2 パターンは、後から直すほど面倒になるので、早い段階で設計を固めるのがおすすめです。
「ユーザーに排他的権限を付与」設定の注意点
フォルダー リダイレクトの設定項目には「ユーザーに排他的権限を付与する（Grant the user exclusive rights）」系のオプションがあります。これはセキュリティ的には強い一方で、次のような運用要件と衝突しがちです。
- 管理者がトラブル対応で中身を確認したい
- バックアップ運用で管理者権限の読み取りが必要
- 移行作業で管理者が一時的にアクセスする必要がある
「ユーザーのプライバシー優先」なのか「運用・復旧優先」なのかで選択が変わります。どちらにせよ、後から切り替えると権限の整合性が崩れやすいため、運用方針を先に決めておくと事故が減ります。
適用確認の実務：まず “当たっているか” を見える化する
「GPO が見つからない」「効かない」と感じるときほど、感覚ではなく証拠を取りに行くのが近道です。
gpresult で、ユーザーに適用された GPO を確認
対象ユーザーでクライアントにログオンし、コマンドプロンプトで以下を実行します。
gpresult /h C:\Temp\gpresult.html生成された HTML を開き、ユーザーの適用済み GPOに HPRS Folder Redirection が載っているかを確認します。載っていなければ、まず「OU」「リンク」「セキュリティ フィルタリング」の問題です。
RSOP で “最終的な設定値” を確認
GUI で確認したい場合は以下も有効です。
rsop.msc（結果セット）- GPMC の「Group Policy Results（グループ ポリシーの結果）」
フォルダー リダイレクトは、複数 GPO が競合していると意図せず上書きされます。「どの GPO が勝っているか」は RSOP が特に分かりやすいです。
イベントログで「共有に書けない」などのエラーを拾う
GPO 自体は当たっているのにフォルダーが移動しない場合、イベントログにヒントが出ます。クライアント側で次のログを確認します。
- Microsoft-Windows-GroupPolicy/Operational
- Microsoft-Windows-Folder Redirection/Operational（環境により名称や有効化が異なる場合があります）
ここで「パスにアクセスできない」「権限がない」「共有に接続できない」などが出ていれば、OU や GPO の話ではなく、共有・DNS・権限の話に切り替えます。
「GPO をリンクしたのに効かない」時のチェックリスト
最後に、現場で遭遇頻度が高い順にチェック観点をまとめます。上から順に潰すと、遠回りしにくいです。
| チェック項目 | 確認方法 | 対処の方向性 |
|---|---|---|
| ユーザーがリンク先 OU 配下にいるか | ADUC でユーザーの場所を確認 | ユーザーを OU に移動、または GPO のリンク先を変更 |
| GPO のリンクが有効か | GPMC で「リンク有効」 | リンク有効化、リンク先の見直し |
| セキュリティ フィルタリングで Apply が付いているか | GPMC の Scope / Delegation | 対象グループに Read + Apply を付与 |
| 上位 OU で継承がブロックされていないか | GPMC で Block Inheritance / Enforced を確認 | 継承設計を整理、必要なら Enforced の検討 |
| 別の GPO と競合していないか | gpresult / RSOP | リンク順を調整、設定の重複を解消 |
| ループバック処理で想定外になっていないか | コンピューター側 GPO を確認 | Loopback（Merge/Replace）を理解して整理 |
| 共有パスにアクセスできるか | エクスプローラーで UNC を開く、イベントログ | DNS、ファイルサーバー到達性、SMB、権限を確認 |
| ルートにユーザーフォルダーを作成できる権限があるか | 権限設定とイベントログ | 共有/NTFS の権限を是正 |
新しいドメインコントローラー構築中に特に注意したいこと
新規 DC 構築のタイミングだと、GPO の話と見せかけて、実は “基盤” が原因のこともあります。該当しそうなら、次も確認してください。
クライアントが正しい DC を見ているか（DNS が最重要）
クライアントの DNS が旧サーバーや外部 DNS を向いていると、ドメイン参加や GPO 取得が不安定になります。以下のような状況がある場合は要注意です。
- ドメイン参加はできるが GPO の反映が遅い／不安定
- 共有（
\\mail.hprs.local\Users）が名前解決できない - ログオンに時間がかかる
クライアント側で「どの DC を使っているか」を見たい場合、状況に応じて以下のようなコマンドが切り分けに役立ちます。
nltest /dsgetdc:hprs.local複数 DC がある場合はレプリケーションを疑う
複数 DC 環境では、GPO（特に SYSVOL 配下）の同期が遅れていると「作ったはずの GPO が別 DC からは見えない」ような状況が起きます。GPMC 上では見えても、クライアントが別 DC に当たっていれば取得できないことがあります。
この場合は AD のレプリケーションや SYSVOL の複製状態も視野に入れて確認します（運用手順がある場合は必ずそれに従ってください）。
まとめ：ADUC の「所属」で探すのではなく、OU とスコープで設計する
「ドメインユーザーを GPO の“メンバー”に追加できない」という現象は、GPO をグループのように扱おうとしてしまうことが出発点です。GPO はメンバーに追加するものではなく、OU にリンクして適用範囲を決めるものです。
フォルダー リダイレクトまで含めて安定させるには、次の順番で整理すると失敗しにくいです。
- ユーザーを置く OU を決め、そこに GPO をリンクする
- 必要ならセキュリティグループで対象を絞る（Read + Apply を確認）
- UNC 共有と権限（共有/NTFS）を最優先で固める
gpresultとイベントログで“当たっている/失敗している”を見える化する
この流れで見直すと、「検索できない」系の誤解も、「当たっているのに動かない」系の実障害も、どちらも短時間で切り分けられるようになります。
コメント