VPN 上找不到组策略？先查作用域再看隧道

某个在办公室网络上一直生效的设置，在用户开始通过 VPN 工作的那一周失效了，而隧道往往在任何报告被打开之前就先背了锅。组策略决定哪些设置落到 Windows 用户和计算机上，从域中获取材料并执行客户端处理，而这三步会以三种不同的方式失败。隧道只改变客户端拥有哪条路径。按顺序走完检查，就不会把文件权限问题当成路由问题去追。

从设置入手，而不是从隧道入手

写下一个预期的 GPO 以及其中的一个具体设置，然后判断该设置属于用户配置还是计算机配置。这里的前提是 已获授权、已加入域的 Windows 客户端运行在获批的 VPN 上，而不是把未托管或纯云设备变成域成员。作用域的答案决定谁能读取结果、是否需要提权，所以在运行任何命令之前先把它定下来。

询问域管理员：应该有哪些链接、对象位置、安全筛选器和 WMI 筛选器生效。为了让测试通过而改动这些控制项，属于另一个负责人主导的另一个项目。

用拥有该设置的账户读取报告

在受影响用户自己的会话中运行 whoami /user，然后再运行 gpresult /scope user /r。通过 VPN 认证的账户并不自动等于你正在读取策略的那个 Windows 账户；从管理员账户做的检查回答的是另一个问题。把基线保存为新的文件名，例如 %TEMP%\vpn-policy-user-before.html。gpresult 参考文档 说明了作用域和输出开关，值得知道的是生成报告并不会刷新任何东西。

计算机策略有自己的作用域和权限上下文，所以要用所需的提权单独查看。把两个作用域混在一份报告里，正是一个用户设置明明从未属于该作用域、却被判定为缺失的原因。

发现不等于访问：先查 SRV 记录，再查 SMB

在获批 VPN 已连接的情况下，确认客户端通过预期的 DNS 路径解析域控制器；一个能打开的公共网站并不能说明控制器发现是否正常。对于示例域 corp.example，nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example 回答的才是你真正面临的问题。返回的服务记录只是发现证据，因为所选控制器的地址仍必须在所需认证和允许的目录服务下可访问。策略材料随后来自 SYSVOL，那是对该特定控制器的 SMB 读取，而不是 ICMP 测试。

较弱的证据很容易被当成证据。控制器返回的 ICMP 回应，配上一次被拒绝的策略模板读取，会生成一份看起来空白的报告，而原因还没人把它联系起来。

让部署中的 AD 服务权限、回程路径和时间同步保持一致，而不是用一刀切的防火墙放行或公共 DNS 服务器取而代之。控制器之间的策略数据不一致，属于目录所有者的复制问题。

一次刷新、两份报告、一次比较

路径被证明之后，用 gpupdate /target:user 请求相应的刷新，并读取结果而不是假设它。默认刷新会应用已更改的策略，而 /force 请求重新应用；两者都不修复 DNS、文件权限或筛选。有些扩展只在之后重新登录或另一个前台事件时才完成，所以一次运行并不算结论。把注销或重启开关当作常规诊断加到远程用户的会话上，会丢掉他正打开的东西。

换一个文件名生成第二份报告，比较处理时间、预期 GPO、它的应用或被拒绝状态以及设置本身。早前成功会话的报告并不能证明这次刷新的任何事。被筛掉的策略指向的是适用性而不是传输，这会改变下一步归谁负责。

把失败绑定到单一活动上

在事件查看器中，先从系统日志里的组策略警告或错误入手，再转到应用程序和服务日志下的 GroupPolicy 操作日志。按你刚才那次刷新的活动标识符筛选该操作日志，因为新的刷新会得到新的标识符，把它和昨天的事件混在一起就会得出自信却错误的结论。记录时间、用户或计算机上下文、选中的控制器、GPO、错误代码以及失败的依赖项。

那份记录才是网络或目录所有者能够据以行动的东西。连上了 VPN 并运行了几次 gpupdate 不是证据，两者都经不起交接。

把 HTML 报告当作私密材料，因为它们会暴露内部名称、组成员身份和安全配置。设置确认之后，请移除你添加的临时权限，而不是把它们留在原处。