ドメイン環境でイベント ID 1202「Security policies were propagated with warning. 0x534」が大量発生する場合、多くは GPO のセキュリティ設定に“存在しない（SID に解決できない）アカウント／グループ参照”が残っているのが原因です。ログから問題名と元の GPO を突き止め、GPO を編集して削除・修正する具体手順をまとめます。
イベント ID 1202「Security policies were propagated with warning. 0x534」とは
イベント ID 1202 は、ドメイン参加端末がグループ ポリシー（GPO）のセキュリティ ポリシー（「ユーザー権利の割り当て」「制限されたグループ（Restricted Groups）」など）を適用する途中で、何らかの警告が発生したときに記録される代表的なイベントです。
メッセージに含まれる 0x534 は、Windows のエラーとしては「アカウント名を SID に変換できない（マッピングできない）」状態を指します。つまり、GPO が参照している“誰か（ユーザー／グループ）”が、端末側で SID 解決できず、適用処理が警告扱いになっています。
| 項目 | 内容 | 現場での読み替え |
|---|---|---|
| イベント ID | 1202 | セキュリティ系 GPO の適用で警告が出た |
| 代表メッセージ | Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done. | GPO に書かれたユーザー／グループ名が見つからない（SID 解決できない） |
| よく関係する設定 | ユーザー権利の割り当て、制限されたグループ | 削除済みグループや誤記が残りやすい場所 |
「大量に出る」理由
イベント ID 1202 は、端末がグループ ポリシーを適用・更新するタイミングで記録されやすく、端末台数が多い環境ほど「大量」に見えます。例えば次のような条件が重なると、ログが増えます。
- 起動時／ログオン時にポリシーを同期適用している
- バックグラウンドの定期更新（gpupdate 相当）が走る
- 同じ OU 配下の多数端末が同じ壊れた参照を踏む
- DC／DNS／ネットワークの揺れで、名前解決が不安定になっている（頻度は低めだが起こり得る）
ただし、最も多いのは「GPO に残った“存在しないアカウント名／グループ名”が、全端末で毎回失敗する」パターンです。
原因の定番パターン
0x534 が出る“壊れ方”は、現場ではだいたい次に集約されます。
| パターン | 何が起きているか | ありがちな背景 | 対処の方向性 |
|---|---|---|---|
| 削除済みグループ参照 | GPO が参照するグループが AD に存在しない | 統廃合、OU 移動、運用変更でグループ削除 | GPO から参照を削除／正しいグループに差し替え |
| 誤記・表記揺れ | 名前が合っておらず SID 解決できない | 手入力、テンプレ流用、英字大小や記号違い | 「参照の追加」は手入力せず参照ボタンで入れ直す |
| ローカル側に存在しないグループ | 端末上のローカルグループを想定したが、実際は存在しない | 途中から作成手段が変わった／端末種別で差がある | ローカルグループを作る仕組みを整えるか、参照を削除 |
| 過去のドメイン／信頼の名残 | 別ドメインや過去の信頼先のアカウントを参照している | ドメイン統合、信頼解除、移行プロジェクト後 | 参照を現行ドメインへ移し替え（不要なら削除） |
| 一時的な DC 到達問題 | 適用タイミングで SID 解決が間に合わない／失敗 | 起動直後のネットワーク未確立、DNS 不調 | まずは参照の健全性を直し、残るなら通信系を調査 |
最短ルート：解決できない名前を特定 → どの GPO か特定 → GPO を編集して消す
質問にある「最後の “GPO から問題アカウントを削除・修正する” 手順が分からない」は、原因の GPO と該当設定が特定できれば、やることはシンプルです。ただし、闇雲に Domain Admins などを消すと副作用が出るため、先に“解決できない名前”と“Source GPO”を確実に掴むのがコツです。
ログから「解決できない名前」を拾う
イベント 1202 本体だけでは、どの名前が解決できないのかが分かりにくいことがあります。そこで、端末側のログで“失敗した名前”を直接拾います。
winlogon.log を確認する
セキュリティ設定の適用に関連する詳細が winlogon.log に出ていることがあります。代表的には「Cannot find …」「No mapping …」「Error 0x534（1332）」などの行です。
| 確認対象 | 場所（代表例） | 探す文字列 | 得たい情報 |
|---|---|---|---|
| winlogon.log | %windir%\security\logs\winlogon.log | Cannot find / No mapping / 0x534 / 1332 | 解決できないアカウント名・グループ名 |
GUI で開いて検索してもよいですが、現場ではコマンドで絞ると早いです。
cd /d %windir%\security\logs
findstr /i /c:"Cannot find" /c:"No mapping" /c:"0x534" /c:"1332" winlogon.logこの出力の中に、例えば次のような“名前”が含まれていれば、それが当たりです。
- CONTOSO\Local admin
- Local admin（ドメイン名が付かない）
- 旧ドメイン\SomeGroup
- タイポしたグループ名
ここで拾えた “xxxx” が、質問にある「Cannot find xxxx」の xxxx に相当します。まずはこの文字列をメモしてください（後で GPO を横断検索する時にも使えます）。
補足：イベント ビューアの併用
端末の「イベント ビューア」でも、該当タイミングの周辺に GroupPolicy 系のエラーや警告が出ていないかを確認します。特に「ドメイン コントローラーに到達できない」「DNS が不安定」などが同時に出ている場合、0x534 が“副作用”として出ているケースもあります。
どの GPO のどの設定かを突き止める
“解決できない名前”が分かったら、次は「それがどの GPO の、どのセキュリティ設定に書かれているか」を特定します。ここが分かれば、最後の修正は迷いません。
rsop.msc で Source GPO を見る（手堅い）
rsop.msc（結果セット ポリシー）は、実際に端末へ適用されている設定と、その設定の元になった GPO（Source GPO）を表示できます。
- 問題が出ている端末で、管理者権限で「ファイル名を指定して実行」→ rsop.msc
- ツリーで次を確認
- コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカル ポリシー → ユーザー権利の割り当て
- コンピューターの構成 → Windows の設定 → セキュリティの設定 → 制限されたグループ（Restricted Groups）
- 赤い×や警告が付く項目、または怪しい設定をクリックし、右ペインで Source GPO（元の GPO）を確認
質問のケースのように「Restricted Groups に Domain Admins や Local admin が見える」なら、まず Restricted Groups を重点的に見ます。RSoP で Source GPO を特定できれば、最後はその GPO を編集するだけです。
gpresult /h でレポート化する（共有しやすい）
現場で“原因切り分けの証跡”として残すなら、gpresult の HTML レポートも便利です。
gpresult /h C:\Temp\gpresult.html /scope computerHTML を開き、「セキュリティ設定」や「制限されたグループ」周辺の“どの GPO が設定しているか”を確認します。端末を触れない場合でも、ファイルだけ回収して解析できます。
| 方法 | 強み | 弱み | おすすめ場面 |
|---|---|---|---|
| rsop.msc | Source GPO が直感的に見える | GUI 操作が必要 | 現地で素早く原因 GPO を当てたい |
| gpresult /h | レポートを共有できる（証跡になる） | 情報量が多く探すのに慣れが要る | 遠隔対応、チームで解析したい |
| GPMC の「Group Policy Results」 | 管理端末から解析できる | 権限や到達性が必要 | 管理側で集中解析したい |
最後の手順：特定した GPO を編集して “SID に解決できない参照” を削除・修正する
ここからが質問の核心です。やることは次のどちらか（または両方）です。
- 削除：存在しないアカウント／グループ参照を、GPO の該当設定から外す
- 修正：正しい AD オブジェクト名（存在するグループ）に差し替える
ポイントは「rsop.msc で見えた Source GPO を、GPMC で開いて編集する」です。
GPO を開く手順（GPMC）
- 管理端末（RSAT / GPMC が入っている端末）で gpmc.msc を起動
- ドメイン → グループ ポリシー オブジェクト → Source GPO（RSoP で特定したもの）を選択
- 右クリック → 編集
制限されたグループ（Restricted Groups）を直す
該当箇所は次のパスです。
Computer Configuration → Policies → Windows Settings → Security Settings → Restricted Groups
Restricted Groups は“強力”で、設定の意味を理解せずに触ると事故ります。まず、画面に出てくる 2 つの枠の意味を押さえてください。
| 欄 | 意味 | ここに「存在しない名前」があると… | よくある誤解 |
|---|---|---|---|
| Members of this group（このグループのメンバー） | 指定したメンバーだけに“固定”する（それ以外は削られる） | SID 解決失敗で警告（1202）／意図せずメンバーが消える危険 | 「追加」ではなく「置き換え」になる |
| This group is a member of（このグループが所属するグループ） | 対象グループを、別グループのメンバーにする | 追加先グループ名が壊れていると SID 解決失敗で警告 | ネスト設計を誤ると管理が破綻しやすい |
修正の具体手順は次の通りです。
- Restricted Groups に表示されている該当グループ（例：Local admin、Domain Admins）をダブルクリックして開く
- 両方の欄を確認し、winlogon.log で拾った「解決できない名前」が含まれていないか探す
- 存在しない／誤記のエントリを見つけたら、次のどちらかを実施
- 削除：そのエントリを削除して OK
- 修正：一度削除してから、「追加」→「参照」ボタンで AD から正しいグループを選び直す（手入力は避ける）
- GPO を保存し、影響範囲（リンク先 OU、セキュリティ フィルタリング、WMI フィルタ）を再確認
質問にある結論の通り、“SID に解決できない参照” を削除（または正しく修正）すると、イベント 1202 は止まります。今回のケースのように、最終的に「Local admin」や「Domain Admins」側の該当エントリを削除して解消することも現場では珍しくありません。
ユーザー権利の割り当て（User Rights Assignment）を直す
該当箇所は次のパスです。
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment
ここも同様に、削除済みグループが残りやすい場所です。例えば以下のような権利に、退役したグループ名が入っていると 0x534 が出ます。
- ローカル ログオンを許可（Allow log on locally）
- リモート デスクトップ サービスによるログオンを許可
- ネットワークからこのコンピューターへアクセス
- サービスとしてログオン
修正のコツは Restricted Groups と同じで、存在しない名前は削除し、必要なものは参照から入れ直すです。手入力やコピペで紛れ込んだ “表記だけの名前” が、後から壊れる温床になります。
「Domain Admins や Local admin が見える。削除すべきか？」の判断基準
Restricted Groups に Domain Admins や Local admin（カスタム） が表示されると、「これ全部消していいの？」となりがちです。結論は次の通りです。
- “消すべきかどうか”は、そのエントリが何を実現するために置かれたかで決まる
- ただし、SID 解決できない（存在しない／誤記の）参照が含まれているなら、その部分は消すか修正が必須
| 状況 | よくある原因 | 推奨アクション | 注意点 |
|---|---|---|---|
| Local admin が「カスタムグループ」だが AD に存在しない | 過去運用の名残、作成手段がなくなった | GPO から削除、または先にローカルグループを全端末に作る仕組みを用意 | Restricted Groups だけで“ローカルグループ作成”まで期待すると破綻しやすい |
| Domain Admins が Restricted Groups に登録されている | Domain Admins のメンバー固定、または別グループ所属固定を狙っている | 意図が不明ならいったん当該 GPO から外して挙動確認し、必要なら正しい形で再設計 | 誤ると管理者権限が消えるなど致命傷になり得る（検証 OU 推奨） |
| Domain Admins 自体は存在するのに 0x534 が出る | Domain Admins の欄に“別の壊れた参照”が混ざっている | Domain Admins の設定を開き、Members / Member Of の中身を精査 | “表示されているグループ名”が原因とは限らず、中のメンバーが原因のことが多い |
| 本来やりたいことが「ローカル Administrators にメンバーを追加」 | Restricted Groups を使うと“置き換え”になり事故りやすい | 環境次第ではGroup Policy Preferences（ローカル ユーザーとグループ）等に切り替えを検討 | ポリシーの方式が変わるので、移行手順と既存影響の洗い出しが必要 |
質問のケースのように、最終的に「Local admin」と「Domain Admins 側も含めて削除したら止まった」という結果は、Restricted Groups のどこかに“解決できない参照”が混ざっていたことを強く示唆します。特に Local admin のようなカスタム名が AD に存在しないなら、原因になりやすいです。
修正後の確認ポイント（止まったことを“証明”する）
GPO を直したら、端末側で確認して「再発していない」状態を作ります。単にイベントが出なくなっただけでなく、意図した権限・グループ構成になっているかも重要です。
ポリシー再適用とイベント確認
- 対象端末で管理者として次を実行
gpupdate /forceその後、イベント ビューアで以下を確認します。
- イベント ID 1202 が以後発生しない（または頻度が大きく下がる）
- 同時に出ていた関連エラー（GroupPolicy の失敗など）が落ち着く
- winlogon.log の “Cannot find xxxx” が新規に出ていない
ローカル Administrators などの実状態も確認する
Restricted Groups を触った場合は特に、メンバーが意図せず削られていないかを必ず見ます。
net localgroup administrators| 確認項目 | 確認方法 | OK の目安 |
|---|---|---|
| イベント 1202 の停止 | イベント ビューア / winlogon.log | gpupdate 後に同じ警告が繰り返し出ない |
| Restricted Groups の影響 | net localgroup / 実機 GUI | ローカル Administrators 等のメンバーが想定通り |
| ユーザー権利の割り当て | secpol.msc（端末ローカル）や RSoP | 必要なグループだけが割り当てられている |
大規模環境の時短：問題名で GPO を横断検索する
端末台数や GPO 数が多いと、「RSoP を端末ごとに見る」のが辛い場面もあります。winlogon.log で拾った“問題の名前”が分かっているなら、GPO を横断検索して一気に当てにいく方法もあります。
SYSVOL 上の GPO ファイルを検索する（文字列検索）
GPO のセキュリティ設定は SYSVOL 配下に保存されています。権限がある管理端末から、問題の名前（例：Local admin）を検索します。
REM 例：ドメインの SYSVOL を直接検索（環境に合わせてパスを調整）
findstr /s /i /n /c:"Local admin" \\yourdomain\SYSVOL\yourdomain\Policies\*.*ヒットした GUID（{xxxxxxxx-xxxx-…}）が、該当 GPO のフォルダです。GPMC でその GPO を開いて確認します。
PowerShell で “GPO レポート” から探す（管理しやすい）
PowerShell で全 GPO のレポート（XML/HTML）を出して検索すると、後から追跡しやすくなります。運用ルールに合わせて使い分けてください。
# 例：全 GPO のレポートを出力して文字列検索する（権限が必要）
# 出力先フォルダを用意
$Out = "C:\Temp\GPOReports"
New-Item -ItemType Directory -Path $Out -Force | Out-Null
# 全 GPO を HTML で出力
Get-GPO -All | ForEach-Object {
$path = Join-Path $Out ($_.DisplayName -replace '[\\/:*?"<>|]', '_' ) + ".html"
Get-GPOReport -Guid $_.Id -ReportType Html -Path $path
}
# “Local admin” を含むレポートだけ列挙
Select-String -Path "$Out\*.html" -Pattern "Local admin" | Select-Object Path, LineNumberこの方法は「どの GPO に文字列が含まれるか」を早く把握できますが、セキュリティ設定は SID 表記で入っている場合もあるため、文字列が必ず見つかるとは限りません。見つからない場合は RSoP での特定に戻すのが確実です。
再発防止：Restricted Groups を“安全に”運用するコツ
Restricted Groups は強力で便利ですが、運用のクセが強い機能です。イベント 1202 対応を機に、次の観点で整備すると再発率が下がります。
- 存在するグループだけを載せる（削除したら GPO からも外す、が鉄則）
- グループ指定は極力参照ボタンで選択し、手入力・コピペを避ける
- Restricted Groups は「追加」ではなく「置き換え」になりやすいので、ローカル Administrators へ“追加だけしたい”用途には別手段も検討する
- GPO の変更は、いきなり本番 OU ではなく検証 OUで適用し、影響（メンバーが消えていないか）を確認してから展開する
「ローカル Administrators に特定のドメイングループを入れたい」だけなら、環境によっては Group Policy Preferences（ローカル ユーザーとグループ）での管理の方が事故りにくいことがあります。Restricted Groups を使い続ける場合でも、設計意図（誰を、どの端末で、どのローカルグループに入れるのか）を文書化しておくと、将来の“削除済み参照”が残りにくくなります。
「このエラーがネットや Outlook を遅くする？」への考え方
イベント 1202 自体が直接「回線を遅くする」ことは通常ありません。一方で、次のような影響はあり得ます。
- ポリシー適用処理が警告でつまずき、ログオン時の処理が長引く
- バックグラウンド更新が繰り返し失敗し、一時的な CPU／I/O／認証トラフィックが増える
- 同時に DC 到達性や DNS に問題がある場合、GPO 適用全体が遅れ、結果として“体感が重い”
ただし、体感としての「インターネットが激遅」「Outlook が重い」は、プロキシ、回線品質、名前解決、証明書失効確認、M365 接続経路、AV/EDR の挙動など、別要因が主因のことも多いです。まずはイベント 1202 の“壊れた参照”を直してノイズを消し、まだ遅いならネットワーク／DNS／認証経路の調査へ進むのが効率的です。
まとめ：迷わないためのチェックリスト
| やること | 具体的な操作 | ゴール |
|---|---|---|
| 解決できない名前を特定 | winlogon.log を検索（Cannot find / 0x534） | 問題のアカウント／グループ名をメモできる |
| 原因の GPO を特定 | rsop.msc で Restricted Groups / User Rights Assignment を見て Source GPO を確認 | “どの GPO を直すか”が確定する |
| GPO を修正 | GPMC で Source GPO を編集し、存在しない参照を削除 or 正しいグループに差し替え | SID 解決できない参照が消える |
| 再適用と検証 | gpupdate /force、イベント 1202 の停止、ローカルグループの実状態確認 | 警告が止まり、権限構成も想定通り |
コメント