GPOのループバック処理が効かないときは、まず「故障」よりも適用対象の考え方が通常のユーザーGPOと違うことを疑うのが近道です。特に多いのは、対象PCがいるOUではなくユーザーOUにGPOをリンクしている、MergeとReplaceの期待がズレている、Security Filteringでコンピューターの読み取り権限まで外している、の3つです。ループバック処理は、ユーザー設定を「ユーザーの所属場所」ではなく「サインイン先コンピューターの所属場所」基準で適用する仕組みなので、確認ポイントも少し変わります。 (Microsoft Learn)
この記事では、GPOのループバック処理が効かないときに起きやすい原因、短時間で切り分ける確認手順、再発しにくい構成まで、実務でそのまま使える形で整理します。読み終わるころには、「どこを見ればよいか」「何を直せばよいか」「次にどのコマンドを打つべきか」が分かる状態を目指します。 (Microsoft Learn)
ループバック処理の前提を先に整理する
ループバック処理は、コンピューター側のポリシー設定です。設定場所は Computer Configuration\Policies\Administrative Templates\System\Group Policy の Configure user Group Policy loopback processing mode で、ここで Merge または Replace を選びます。通常はユーザー設定はユーザーのOUを基準に処理されますが、ループバックを有効にすると、サインイン先コンピューターのOUにリンクされたGPOのユーザー設定を使えるようになります。 (Microsoft Learn)
動きの違いはシンプルです。Merge は「通常のユーザーGPOに、コンピューター側で集めたユーザーGPOを後から足す」方式で、競合した場合はコンピューター側のGPOが優先されます。Replace は「通常のユーザーGPOを集めず、コンピューター側で集めたユーザーGPOだけを使う」方式です。ここを勘違いすると、「ループバックが効かない」のではなく「Mergeにしたので元のユーザーGPOも残って見えている」だけ、ということがよくあります。 (Microsoft Learn)
なお、ループバック処理はActive Directory環境が前提で、Microsoft Learnでもユーザーアカウントとコンピューターアカウントの両方がActive Directory内にあることが前提とされています。ローカルユーザーや、想定外の場所にあるコンピューターで同じ挙動を期待すると切り分けがぶれます。 (Microsoft Learn)
GPOのループバック処理が効かない主な原因
GPOのリンク先が違う
GPOはサイト、ドメイン、OUにリンクして適用します。ユーザーオブジェクトやコンピューターオブジェクトそのものに直接リンクすることはできません。 そのため、ループバックを効かせたいなら、少なくともループバックを有効にしたGPOは対象コンピューターが存在するOUにリンクされている必要があります。ユーザーOUにだけリンクしていても、ループバック処理の条件にはなりません。 (Microsoft Learn)
ここでありがちなのが、「ユーザー用設定だからユーザーOUにリンクした」という設計です。ループバックでは逆で、そのユーザー設定を適用したいコンピューターのOU側を中心に見ます。対象PCが思っていたOUではなく別OUや既定のコンテナーに残っていると、それだけで対象外になります。まずはAD上で対象コンピューターの実際の格納先を確認してください。 (Microsoft Learn)
Merge と Replace の期待値が合っていない
「共有端末では普段のユーザーGPOを消したい」のに Merge を選ぶと、ユーザーOU側の設定が残るため、効いていないように見えます。逆に、「普段のユーザー設定は残しつつ、その端末だけ追加設定を重ねたい」のに Replace を選ぶと、必要なユーザーGPOまで消えてしまいます。元のユーザーGPOを残したいなら Merge、持ち込ませたくないなら Replace と覚えると判断しやすいです。 (Microsoft Learn)
特に受付端末、教室PC、キオスク、厳密に固定したい共有サーバー系では Replace のほうが挙動を読みやすいケースがあります。一方で、RDSや共有PCで「普段の設定に、その環境専用の制御だけ足したい」なら Merge が向いています。 (Microsoft Learn)
GPO自体が無効、または優先順位で負けている
GPOがリンクされていても、リンクが無効だったり、GPO Status が User configuration settings disabled になっていたりすると、ユーザー設定は適用されません。同じOUに複数のGPOがある場合はリンク順も重要で、GPMCでは数字が小さいリンク順ほど優先順位が高い扱いです。 (Microsoft Learn)
さらに、上位OUやドメイン側のGPOが Enforced になっていると、下位OU側で上書きできないことがあります。逆に、Block Inheritance が入っていると通常の継承GPOは止まりますが、Enforced のGPOは止まりません。 「見えているのに勝てない」「親OUの設定が残る」というときは、リンク順だけでなく Enforced と Block Inheritance も一緒に見てください。 (Microsoft Learn)
Security Filtering と WMIフィルターで落ちている
GPOは、対象ユーザーまたは対象コンピューターに Read と Apply Group Policy の権限があって初めて適用候補になります。さらにWMIフィルターを付けている場合は、対象コンピューター上でWMIクエリが True にならないとGPOは落ちます。 ループバックの問題を切り分けるときは、まずWMIフィルターを一時的に外して動作確認するほうが早いです。 (Microsoft Learn)
実務で特に多いのは、Authenticated Users（認証されたユーザー） を Security Filtering から外した結果、コンピューターアカウントの Read 権限まで消してしまうパターンです。Microsoft Learnでも、Authenticated Users を外した場合は、ユーザーGPOを正しく機能させるためにコンピューターオブジェクトへ Read 権限を戻す必要があると案内されています。Apply を対象グループに絞るのはよくても、Read まで消すとハマりやすい、というのが実務上の重要ポイントです。 (Microsoft Learn)
また、ループバックを有効にしたGPOそのものも、対象コンピューターが読めて適用できる必要があります。MicrosoftのRDS向けガイダンスでも、ループバック用GPOのセキュリティに対象コンピューターアカウントを追加し、Read と Apply Group Policy を許可する手順が示されています。 (Microsoft Learn)
なお、Security Filtering はGPO単位でしか効きません。同じGPOの中で「この設定だけ別グループに」という細かい分け方はできないので、適用条件が違う設定はGPOを分割したほうが切り分けやすくなります。 (Microsoft Learn)
更新タイミングの問題で、まだ反映されていない
グループポリシーは、基本的にコンピューター起動時とユーザーログオン時に前景処理され、その後は定期的にバックグラウンド更新されます。ただし、すべての拡張がバックグラウンド更新で完全に処理されるわけではありません。たとえば、フォルダーリダイレクトはユーザーログオン時、ソフトウェアインストールは起動時やログオン時に処理されるため、gpupdate /force だけでは見た目が変わらないことがあります。 (Microsoft Learn)
さらに、GPOの変更はADとSYSVOLで別々に複製されるため、複数DC環境では反映までタイムラグが出ます。「設定は正しいのに効かない」ときは、複製待ち・サインアウト/サインイン・再起動を挟んでから再判定したほうが正確です。 (Microsoft Learn)
5分でできる確認手順
まずGPMCで「対象コンピューターのOU」を確認する
最初にやるべきなのは、ユーザーではなくコンピューターを起点に見ることです。対象PCがどのOUにあり、そのOUにどのGPOが直接リンクされ、どのGPOが継承で入ってくるのかを確認します。PowerShellなら Get-GPInheritance で、直リンクのGPO、実際に継承されるGPO、継承ブロックの有無をまとめて確認できます。 (Microsoft Learn)
Get-GPInheritance -Target "OU=SharedPC,DC=contoso,DC=com"この段階で見るポイントは、ループバック有効化GPOのリンク有無、リンク有効状態、GPO Status、WMIフィルター、Security Filtering、そしてリンク順です。ここがズレていると、クライアント側でいくら gpupdate しても結果は変わりません。 (Microsoft Learn)
次に対象PCで gpupdate と gpresult を取る
影響を受けるユーザーで対象PCにサインインした状態で、まずは更新と結果確認を行います。gpresult はそのユーザーとそのコンピューターに実際に適用されたRSoPを確認する基本コマンドです。HTMLで保存しておくと、あとから比較しやすくなります。 (Microsoft Learn)
gpupdate /force
gpresult /scope user /r
gpresult /h C:\Temp\gpresult.html /fgpupdate には、ユーザーだけ・コンピューターだけを更新する /target、ログオフが必要な拡張向けの /logoff、再起動が必要な拡張向けの /boot があります。ログオン時や起動時にしか効かない設定を試しているなら、次のコマンドまで使うと確認が速くなります。 (Microsoft Learn)
gpupdate /target:user /force /logoff
gpupdate /target:computer /force /bootそれでも分からなければ、Results とイベントログを見る
GPMCの Group Policy Results は、対象コンピューターから実際のRSoPを取得して表示します。Group Policy Modeling はシミュレーションで、Group Policy Results は実測です。まずは Results を見て、「想定GPOが実際に入っているか」を確認するほうが、遠回りしません。 (Microsoft Learn)
イベントログを見るなら、Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational が基本です。Microsoft Learnのトラブルシューティングでも、まずSystemログ側の警告・エラーから ActivityID を確認し、そのIDで Operational ログを絞り込む流れが案内されています。RDSや共有サーバーのように複数の処理が同時に動きやすい環境では、この見方が特に有効です。 (Microsoft Learn)
復旧しやすい構成に直すなら、この形が安全
Microsoft LearnのOU設計、リンク、権限、ループバックの説明を踏まえると、実務ではGPOを役割ごとに分ける構成が復旧しやすく、あとから見ても迷いにくいです。特に共有端末やRDSでは、対象コンピューターだけを入れた専用OUを作り、そのOUを中心に設計すると事故が減ります。 (Microsoft Learn)
- GPO-A：Loopback-Enable
ループバック設定だけを入れるGPOです。対象コンピューターOUにリンクし、対象コンピューターが Read と Apply Group Policy を持つ状態にします。 (Microsoft Learn) - GPO-B：UserSettings-For-SharedPC
その環境で強制したいユーザー設定だけを入れるGPOです。対象コンピューターOUにリンクし、User Configuration が無効化されていないことを確認します。Apply は絞っても構いませんが、Read 権限の扱いは慎重に見ます。 (Microsoft Learn) - 切り分け中はWMIフィルターを極力外す
まずスコープと権限が正しいかを確認し、その後でWMIフィルターを戻すほうが原因が見えやすくなります。 (Microsoft Learn) - 用途で Merge / Replace を決める
通常のユーザーGPOを残したいなら Merge、共有端末で通常のユーザーGPOを持ち込ませたくないなら Replace が分かりやすい選択です。 (Microsoft Learn)
設計に迷ったら、「この端末では普段のユーザー設定を残すのか、消すのか」 を先に決めると、Merge と Replace の選択を間違えにくくなります。ここが曖昧なまま作ると、後から「効かない」のか「効いているが見え方が違うだけ」なのか判別しづらくなります。 (Microsoft Learn)
まとめ
GPOのループバック処理が効かないときは、順番に見れば大半は切り分けできます。最優先は、対象コンピューターが正しいOUにいるか、ループバックGPOがそのOUにリンクされているか、Merge/Replaceの選択が目的と一致しているか、Security FilteringでコンピューターのRead権限を消していないか の確認です。そこを通過したら、gpresult と Group Policy Results、最後に GroupPolicy Operational ログで詰めれば、原因はかなり絞れます。 (Microsoft Learn)
次にやることはシンプルです。対象PCのOUを確認し、GPMCでリンク・権限・GPO Status を見直し、gpresult /h を取り、必要ならサインアウト/サインインまたは再起動で再検証してください。これで改善しない場合も、少なくとも「スコープの問題なのか、権限の問題なのか、更新タイミングの問題なのか」は切り分けやすくなります。 (Microsoft Learn)
コメント