rsop报告用于确认策略实际生效情况而非仅查看配置，必须使用日志模式（logging mode）而非建模模式，重点关注灰色项、红色×或“applied: no”等失败标记，结合安全筛选、wmi筛选、继承阻断分析原因，并通过gpresult /v、事件查看器及注册表等手段验证落地效果。
生成组策略结果集（rsop）报告不是为了看“有哪些策略”，而是为了确认“哪些真正生效了、哪些被拦下了、为什么没起作用”。关键在于用对模式、读准线索、结合验证动作——否则容易把“没应用”当成“配置错”，把“被拒绝”当成“没链接”。
必须用日志模式，别选建模模式
建模模式（Planning Mode）是预演，比如“如果把张三加进IT组，他会受哪些策略影响”，它不读真实环境数据。排查问题必须用日志模式（Logging Mode），它采集的是目标机实际执行组策略时写入WMI的原始记录。
- 图形界面操作：打开MMC → 添加“组策略结果集”管理单元 → 运行向导时，明确勾选「收集日志模式数据」
- 命令行等效：以管理员身份运行 gpresult /h rsop.html /scope computer（查计算机策略）或 gpresult /h rsop.html /scope user（查用户策略）
- 避免误用 gpresult /z：它不区分“已应用”和“被筛选”，容易把“安全筛选未通过”误判为“策略无效”
盯紧三类失败标记，定位拦截点
RSoP报告里出现灰色项、红色×或“Applied: No”，说明策略中途被拦，不是设置本身有问题。重点查以下三处：
- 安全筛选器不匹配：提示“Security filtering prevented application”，说明该GPO的安全筛选列表里没有当前用户/计算机，或虽有但缺少“读取”和“应用组策略”权限
- WMI筛选器返回False：提示“WMI filter evaluated to False”，需在目标机上手动验证，例如运行 wmic os get caption 看是否匹配筛选语句中的操作系统名
- 继承被阻断：报告顶部“GPO应用顺序”区域会标注“Inheritance blocked by parent”或“Enforced by higher-level GPO”，说明上级OU启用了“阻止继承”，或更高优先级GPO设置了“强制”
权限类设置要翻文本报告细查
用户权限分配（如SeBackupPrivilege、SeDenyInteractiveLogonRight）极易因叠加或拒绝冲突，而rsop.msc图形界面默认折叠这些项，且不显示冲突细节。
- 用 gpresult /v > rsop_verbose.txt 输出详细文本报告
- 搜索关键词如 User Rights Assignment 或具体权限名（如SeRemoteInteractiveLogonRight）
- 找到条目后，向下查看每条“GPO Name”后的状态：Applied: Yes 表示生效，Applied: Denied 表示被拒绝权限覆盖，Applied: Filtered 表示安全或WMI筛选未通过
- 特别注意带 Deny 前缀的权限（如SeDenyLogonAsServiceRight），它会直接覆盖同名允许权限
验证策略是否真正落地，不止看RSoP
RSoP显示“已应用”，不代表配置已写入系统。还需进一步验证：
- 先执行 gpupdate /force，观察是否返回“成功处理”（不是仅“完成”）
- 打开事件查看器 → Windows日志 → 系统，筛选事件ID：1129（GPO处理失败）、5312（安全策略应用）、4016（注册表策略写入）
- 对注册表类策略，直接打开regedit，检查对应路径（如HKEY_LOCAL_MACHINE\SOFTWARE\Policies\）下键值是否存在且正确
- 对脚本类策略，检查%SystemRoot%\System32\GroupPolicy\Machine\Scripts\Startup等目录下脚本是否被复制，以及gpresult /v中是否列出执行状态
