rsop日志模式是排查组策略是否真正落地的核心工具，需用gpresult /h或rsop.msc启用日志模式，重点核查安全筛选、wmi筛选、继承阻断三类失效原因，并验证策略刷新与落地。
rsop 不是“查设置有没有配”，而是查“策略到底有没有真正落地”。它反映的是系统实际执行后的净效果，不是你在 gpmc 里看到的配置状态。
必须用日志模式，别被建模模式误导
建模模式（Planning Mode）只是模拟，比如“如果把这台电脑挪到另一个 OU，会应用哪些策略”——它不反映真实环境。排查故障时，只认日志模式（Logging Mode），因为它是从 WMI 中读取组策略引擎真实写入的数据。
两种可靠启用方式：
- 命令行：以管理员身份运行 gpresult /h rsop.html（默认即日志模式），加 /scope computer 或 /scope user 可分别聚焦
- MCC（rsop.msc）：右键“组策略结果集”→“生成 RSOP 数据”→在向导中明确选择「日志记录模式」
重点看“没生效”的原因，不是“设了没设”
RSoP 报告里出现灰色项、带 × 的条目或标注 “Applied: No”，不代表你配错了，而是策略在途中被拦截。盯住三类提示：
- Security filtering prevented application：该 GPO 的安全筛选列表里没有当前用户/计算机，或账户虽在但缺少“读取”和“应用组策略”权限
-
WMI filter evaluated to False：WMI 筛选器在目标机上执行返回 False，例如筛选语句要求
SELECT * FROM Win32_OperatingSystem WHERE Caption LIKE "%Server%"，但机器是 Windows 10，就过滤掉了 - Inheritance blocked by parent 或 Enforced by higher-level GPO：上级 OU 启用了“阻止继承”，或更高层 GPO 设置了“强制”，导致本 GPO 被跳过
权限类策略要翻文本报告才看得清冲突
用户权限分配（如 SeBackupPrivilege、SeDenyInteractiveLogonRight）在 rsop.msc 图形界面里常被折叠，且不显示“拒绝覆盖”细节。真正判断谁赢谁输，得靠：
- 运行 gpresult /v > rsop_verbose.txt
- 在文本中搜索 User Rights Assignment 或具体权限名（如 SeRemoteInteractiveLogonRight）
- 逐条查看每项后的状态：Applied: Yes（生效）、Applied: Denied（被拒绝权限覆盖）、Applied: Filtered（筛选未通过）
确保数据是刚刷出来的，不是缓存旧快照
默认 RSoP 可能读的是上次刷新的缓存。要验证最新策略是否已生效，必须：
- 先执行 gpupdate /force，确认输出含“成功处理”字样（不只是“完成”）
- 立即运行 gpresult /h rsop.html，避免间隔太久
- 必要时检查事件查看器 → Windows 日志 → 系统，筛选 ID 1129（GPO 处理失败）、5312（安全策略应用）、4016（注册表策略写入）等关键事件
