rsop.msc（結果セット・オブ・ポリシー）で「赤い×（Red X）」が出ているのに、実際の設定は期待どおりに適用されている――しかもドメインコントローラー（DC）だけ表示が変。こうした“表示と実体のズレ”に遭遇したとき、何を正として確認し、どこを整理すれば再発を防げるのかを、現場で使える手順に落とし込んで解説します。
現象の整理：何が「おかしい」のか
ご相談の状況を、トラブルシュートしやすい形に分解すると次のとおりです。
| 観点 | 状況 | ポイント |
|---|---|---|
| GPO構成 | ドメイン直下にGPO1 / GPO2をリンク（優先順位はGPO2が上） | 同一設定を複数GPOが持つ「重複設定」状態 |
| 設定内容 | セキュリティ オプション配下の「abc」が両GPOに存在 | セキュリティ設定（Security Settings）は“適用方式”が特殊 |
| 値の差 | GPO1: Test / GPO2: test（大小文字のみ） | 大小文字差は「実体側で正規化される」ことがある |
| 表示の違い | DCだけrsop.mscで赤い×、値はGPO2相当だがソースGPOがGPO1表示 | 「勝っている値」と「表示されるソース」が食い違う |
| 他サーバー | メンバーサーバーでは赤い×なし、ソースもGPO2で整合 | DC固有の条件（OU、セキュリティ設定の扱い、RSOPデータ）を疑う |
まず結論：実効設定が正しければ、赤い×だけで「障害」とは断定しない
結論から言うと、最終的な適用結果（実効設定）が期待どおりで、かつグループポリシー適用のエラーが出ていないなら、重大な影響が出る可能性は高くありません。rsop.mscは便利ですが、特定の条件下で“表示の不整合”が起きることがあります。
ただし、DCは影響範囲が大きい役割のため、次の2点だけは必ず押さえておくのが安全です。
- 「どのGPOが勝ったか」ではなく「実際にOSの実効値がどうなっているか」を確認する
- 同じ設定を複数GPOに重複させない（または完全に同一の値に統一する）運用に寄せる
RSOP.mscの赤い×は何を意味しがちか
rsop.mscは「Resultant Set of Policy（RSoP）」を見やすく表示するためのスナップインです。基本的には“その時点の結果”を見られますが、次のようなケースで赤い×やソース表示のズレが起きやすくなります。
- 同一設定が複数GPOで定義されている（勝ち負けが発生）
- 値が表記ゆれ（大小文字、空白、末尾スペース、ローカライズ表記など）している
- セキュリティ設定（Security Settings）系で、実体がローカルセキュリティDBやレジストリに“正規化”される
- RSoPデータ（WMI）側が古い/壊れ気味で、表示が最新状態と合わない
つまり、赤い×＝即座に「適用されていない」「壊れている」とは限りません。特に今回のように“値が期待どおりで、違いが大小文字だけ”という状況は、表示系がハマりやすい典型です。
GPOの優先順位：本当に「GPO2が勝つ」状態かを言語化する
「優先順位はGPO2が上」という前提は正しいことが多い一方、DCだけ挙動が違う場合は、優先順位の“全体像”がメンバーサーバーと異なっている可能性があります。ここは、よくある見落としを潰すと判断が早くなります。
| 優先順位が変わる要因 | DCで起きやすい理由 | 確認ポイント |
|---|---|---|
| 所属OUが違う | DCは通常「Domain Controllers OU」に所属 | DCがどのOUにいるか、OUリンクGPOが追加されていないか |
| Default Domain Controllers Policy等の存在 | DCにはDC向けGPOがリンクされがち | 同じ設定がDC向けGPOにも存在しないか |
| リンク順（Link Order） | OU側のリンク順が影響 | 「どの階層で」「どの順番で」リンクされているか |
| Enforced（強制）/ Block Inheritance（継承のブロック） | セキュリティ要件でDC OUに設定されがち | 該当OU/ドメインの設定状態 |
| セキュリティフィルタ/WMIフィルタ | DCだけ対象グループが違うことがある | GPOの適用対象（Authenticated Users等）とWMI条件 |
ポイントは、「ドメイン直下にリンクしている2つのGPO」だけを見て安心しないことです。DCは“所属OUが違う”だけで、追加のGPOが混ざりやすく、結果として「見えている優先順位」と「実際の優先順位」がズレます。
大小文字だけ違う重複設定が“表示ズレ”を誘発しやすい理由
今回の肝はここです。Windowsのセキュリティ設定には、内部的に次のような動きが入ることがあります。
- 格納時に表記が正規化される（例：内部処理で小文字に寄せる、余計な空白を詰める、既定表記に合わせる）
- 比較は大小文字を区別しない（またはする）など、コンポーネントごとに扱いが違う
- GPO側の“定義値”と、OSが保持している“実効値”の見え方が一致しない
この状態で、rsop.mscが「どのGPO由来か」を表現するために内部比較を行うと、大小文字差のような“軽微な差”でも「競合」とみなして赤い×表示になったり、ソースGPOの紐付けが直感とズレることがあります。
とくに、セキュリティ設定（ローカルポリシー/セキュリティオプション）は、一般的なレジストリベースのポリシーと違い、ローカルセキュリティDBやセキュリティ設定の適用エンジンを介して反映されます。この“別経路”が、表示ツール側の比較ロジックと噛み合わず、不整合に見えることがあります。
DCだけRSOP表示が崩れやすい実務的な理由
「メンバーサーバーは正常、DCだけ変」という時点で、DC固有の条件に絞って見られます。現場で多いのは次の3系統です。
DCは“適用対象の前提”が違う
DCはDomain Controllers OUにいることがほとんどで、OUリンクGPOが加わります。結果として、同じ設定が別のGPOでも定義されていたり、リンク順やEnforcedの影響で、思った優先順位になっていないことがあります。まずは「DCの適用GPO一覧」を確定させるのが最短です。
セキュリティ設定は“適用後の保持形式”が違う
セキュリティオプションの一部は、適用後にOS側の保持形式が変わったり、表示が正規化されます。大小文字や表記ゆれがあると、表示ツール側が「別物」と判断しやすく、赤い×やソースずれに繋がります。
RSoP（WMI）データの状態差
rsop.mscは、内部的にRSoPデータ（WMI）を参照して表示します。DCは役割上、管理ツールや監査、バックアップ製品などと相性が出ることもあり、RSoPデータの更新が遅れたり、表示が追随しないケースがあります。gpresultや実効値で整合しているなら、表示だけの問題であることも珍しくありません。
最優先の確認：gpresult /h で“勝者”とエラーを確定する
rsop.mscの見え方が怪しいときに、最初にやるべきことは「正しい事実を固める」ことです。実務では、gpresult /h（HTMLレポート）が扱いやすく、証跡としても残せます。
DCでの実行例
管理者権限のコマンドプロンプト、またはPowerShellで実行します。
mkdir C:\Temp 2>nul
gpresult /h C:\Temp\gpresult_dc.html /f出力したHTMLを開き、次を確認します。
- Computer Details / Applied Group Policy Objects：実際に適用されたGPO一覧
- Denied GPOs：適用されなかったGPOと理由（フィルタ、権限など）
- Group Policy was applied from：参照しているドメインコントローラー等
- エラー/警告の有無：ポリシー拡張（CSE）で失敗がないか
メンバーサーバーでも同様に採取して比較
mkdir C:\Temp 2>nul
gpresult /h C:\Temp\gpresult_member.html /f比較の観点は「abc設定そのもの」だけでなく、適用GPO一覧と順序がDCと同じかです。DCだけ追加のGPOが混ざっていれば、rsop.mscの見え方が違うのも自然です。
| 比較項目 | DC | メンバーサーバー | 解釈 |
|---|---|---|---|
| 適用GPO一覧 | 例：ドメインGPO + DC OU GPO | 例：ドメインGPO + サーバーOU GPO | 追加GPOがあると“勝ち負け”の前提が変わる |
| Denied GPOs | 理由が出る場合あり | 出ない場合あり | フィルタや権限で適用対象が変わっている可能性 |
| エラーの有無 | 有/無 | 有/無 | エラーがある場合は表示問題ではなく適用問題の線が濃い |
次にやる確認：OS側の“実効セキュリティポリシー”を見る
gpresultで「GPO2が勝っている」ように見えても、最終的に大事なのはOSが保持している実効値です。セキュリティオプションは、最終的にローカルセキュリティDBやレジストリに落ちます。ここが期待どおりなら、rsop.mscの赤い×は“表示上の違和感”で終わる可能性が高いです。
seceditでセキュリティポリシーをエクスポートして確認
secedit /export /cfg C:\Temp\secpol_dc.cfg出力ファイル（secpol_dc.cfg）を開き、該当するキーや文字列（abcに紐づく項目）を探して、最終値が期待どおりか確認します。
ここで重要なのは、「GPO上の表記（Test/test）」と、エクスポートで見える表記が一致しないことがある点です。OS側が正規化して小文字になっているなら、どちらが“勝った”としても、結果は同じに見えることがあります。
レジストリでの最終値確認（説明タブを活用）
セキュリティオプションの多くはレジストリに反映されます。GPOエディターの各設定には、説明（Explain）に「どのレジストリキーに書き込むか」が記載されていることが多いので、そこを手がかりにします。
例（パスは設定によって異なります）。
reg query "HKLM\...\(該当パス)" /v (値名)この“最終値の直視”ができると、rsop.mscの見え方に引っ張られずに判断できます。
実際の対処：重複設定を解消するのが最も確実で早い
今回のように「同じ設定が複数GPOにある」状態は、適用結果が正しくても、将来のトラブルシュートコストを確実に上げます。しかも、大小文字などの表記ゆれが混ざると、ツールの表示までブレて、判断が難しくなります。
運用の現実解としては、次のいずれか（できれば両方）を実施するのが最も効果的です。
不要な側の設定を削除して一本化する
- GPO2が常に勝たせたい“正”なら、GPO1側の「abc」を削除して重複をなくす
- 逆にGPO1が基盤なら、GPO2側を削除して基盤に寄せる
どうしても重複が必要なら、値を完全一致させる
- 大小文字、前後スペース、記号、改行を含めて完全に同じ値に統一する
- GPOのコメント欄に「なぜ重複しているのか」「どちらを正とするのか」を残す
| 方針 | メリット | デメリット | おすすめ度 |
|---|---|---|---|
| 重複をなくす（一本化） | 表示・調査が最短になる。将来の事故が減る | 権限分掌やチーム分けの都合で調整が必要な場合がある | 高 |
| 重複のまま値を完全一致 | 組織事情を維持しつつ表示ズレを減らせる | 将来どちらかが変更されて再発しやすい | 中 |
| 重複のまま放置 | 今は手がかからない | 障害時に原因究明が長引く。監査・引き継ぎが難しくなる | 低 |
表示問題か適用問題か：現場で迷わない切り分けチェックリスト
「RSOPが赤い×」という情報だけでは判断がブレます。次の表の順で潰すと、最短で結論に辿り着けます。
| 観測 | 確認方法 | 結論 | 次アクション |
|---|---|---|---|
| gpresultで、abcの期待値になっている | gpresult /h（DC/メンバーで比較） | ポリシー処理としては概ねOK | secedit/exportやレジストリで実効値を確認し、重複設定を整理 |
| gpresultにエラーが出る | HTML内のエラー、イベントログ（GroupPolicy/Operational） | 適用に失敗している可能性 | エラー内容に沿って修復（SYSVOL、権限、CSE、ネットワーク等） |
| gpresultでGPO順序が想定と違う | Applied GPO一覧、GPOリンク状況 | 前提（優先順位）が違う | OUリンクやEnforced/Block Inheritanceを見直し、狙いどおりの順に整備 |
| 実効値（secedit/レジストリ）が期待と違う | secedit /export、reg query | 表示ではなく実害がある | GPOの競合解消、CSEの適用状況、再適用（gpupdate）を実施 |
RSOP表示を再評価するための“安全側”の再実行手順
「表示だけの問題か」を切る目的で、過剰に危険な作業は避けつつ、次の順で再評価すると整理できます。
ポリシーの再取得・再評価
gpupdate /forceその後、rsop.mscを開き直して表示が変わるか確認します。これは“表示側の更新遅れ”の切り分けに有効です。
イベントログで「適用が成功しているか」を見る
DCの場合、トラブルがあるならイベントログに痕跡が残りやすいです。最低限、次を確認します。
- グループポリシーの適用が成功しているか
- セキュリティ設定の拡張（Security Settings）で失敗していないか
- SYSVOL/ポリシーファイル取得に失敗していないか
エラーが出ていないなら、rsop.mscの赤い×は“表示の癖”として扱いやすくなります。
よくある質問
DCだけ赤い×なら、DCにだけ実害が出ていると考えるべき？
実害の有無は「赤い×」ではなく、実効値とイベントログで判断します。gpresultとsecedit/レジストリで期待どおり、かつエラーがないなら、実害が出ている可能性は低いです。
「ソースGPOがGPO1」と表示されるのは、GPO1が勝っているという意味？
必ずしもそうとは限りません。今回のように大小文字のみの差だと、OS側の正規化で“結果の見え方”が揃ってしまい、表示ツールの紐付けが直感と合わなくなることがあります。まずはgpresultの適用GPO一覧と、実効値の一致を正として確認するのが確実です。
重複設定を消すと、どんなメリットがある？
最大のメリットは、障害時の調査が圧倒的に速くなることです。GPOが増えるほど「どこが勝っているか」「なぜ勝ったのか」の説明が複雑になります。重複を排除しておくと、表示のブレやツールの癖に振り回されにくくなり、監査・引き継ぎにも強くなります。
まとめ：見るべきはRSOPのアイコンではなく「gpresultと実効値」
rsop.mscの赤い×がDCだけに出ると不安になりますが、今回の条件（同一設定が複数GPOに存在し、差が大小文字だけ）は、表示が不整合になりやすい要素が揃っています。運用上は次の方針が堅実です。
- gpresult /hで、適用GPO一覧・順序・エラーの有無を確定する
- secedit/レジストリで、OSの実効値が期待どおりかを見る
- 重複設定を解消し、同じ設定は1か所で管理する（どうしても重複なら完全一致）
この3点を押さえると、「RSOPの表示に振り回される」状態から抜けられ、DC環境でも自信を持って判断できるようになります。
コメント