在我的公司，我们有一台 Windows Server 2003 R2 服务器，它是我们的主要 AD 服务器，几乎所有基于 Windows 的东西都在其上运行（AD、文件共享、打印共享等）。域功能级别是 Windows Server 2003，但林功能级别是 Windows 2000（该域以前主要托管在 Windows 2000 Server 计算机上）。
几周前，我和一位同事从域中删除了 Windows 2000 Server，将所有 FSMO 角色移至 Windows Server 2003 计算机，使其成为主要且唯一的域控制器。不幸的是，我们忘记移动一些东西，例如 GPO 和登录脚本。大多数登录脚本和 GPO 都已重新创建，但我们仍有几个小问题。其中之一就是我们大约每 5 分钟收到一次的小错误：
Windows 无法访问 GPO CN={6AC1786C-016F-11D2-945F-00C04fB984F9}、CN=Policies、CN=System、DC=OURDOMAIN、DC=com 的文件 gpt.ini。该文件必须位于 <\OURDOMAIN.com\sysvol\OURDOMAIN.com\Policies{6AC1786C-016F-11D2-945F-00C04fB984F9}\gpt.ini> 位置。（系统找不到指定的路径。）。组策略处理已中止。
收到此错误后不久，我们收到以下错误：
Windows 无法查询组策略对象列表。检查事件日志中是否有策略引擎先前记录的可能消息，这些消息描述了此问题的原因。
现在，我重新创建的东西（例如文件夹重定向）目前运行良好，因此据我所知，客户端工作站正在找到现有的 GPO，并正在应用这些 GPO，因此我们在这方面做得很好。但是，我希望这些错误消失，因为它相当烦人。（我每天早上都会在收件箱中收到所有错误的副本）。
我尝试运行 dcgpofix，但这只会给我以下错误消息：
Microsoft Windows [版本 5.2.3790] (C) 版权所有 1985-2003 Microsoft Corp.
U:>dcgpofix
Microsoft(R) Windows(R) 操作系统默认组策略恢复实用程序 v5.1
版权所有 (C) Microsoft Corporation。1981-2003
描述：为域重新创建默认组策略对象 (GPO)
语法：DcGPOFix [/ignoreschema] [/目标：域 | DC | BOTH]
此实用程序可以将默认域策略或默认域控制器策略恢复到全新安装后的状态。您必须是域管理员才能执行此操作。
警告：您将丢失对这些 GPO 所做的任何更改。此实用程序仅适用于灾难恢复目的。
此域的 Active Directory 架构版本与此工具支持的版本不匹配。可以使用 /ignoreschema 命令行参数恢复 GPO。但是，建议您尝试获取此工具的更新版本，该版本可能具有更新版本的 Active Directory 架构。恢复具有不正确架构的 GPO 可能会导致不可预测的行为。恢复失败。有关更多详细信息，请参阅以前的消息
与往常一样，如果我遗漏了一些重要信息并需要告诉您以帮助解决此问题，请发表评论，我会将其包括在内。
由于评论限制为 600 个字符，因此需要更多信息：
我完全可以从客户端和服务器浏览到 \ourdomain\sysvol 和 \ourdomain.com\sysvol。我们遇到的真正问题是，在主 AD 服务器上的 C:\WINDOWS\SYSVOL\sysvol\ourdomain.com\Policies 目录中，没有 {6AC17...} 目录。就是这样。它根本没有复制。老实说，我认为没有复制任何东西，因为我们必须手动完全重建登录脚本和 GPO。
我不是淘汰旧 Win2k 服务器的人，但从观察来看，淘汰旧服务器的人遇到了问题，实际上不得不在新系统上夺取 FSMO 角色。如果我没记错的话，Sysvol 必须手动重建，并且 NETLOGON 的设置并不完全正确，尽管它确实可以工作，我们当前的 GPO 也是如此，除了这个似乎在某处被引用但不存在的 GPO。
以下是我为尝试解决此问题所采取的步骤列表：
- 在 C:\WINDOWS\SYSVOL\sosvol\ourdomain.com\Policies 目录中搜索文件，但不存在
- 在 \ourdomain.com\sysvol 和 \ourdomain\sysvol 中搜索文件，同样，不存在。这两个文件告诉我，GPO 在我们的系统中根本不存在。
- 我搜索了服务器的整个文件系统以查找匹配的内容6AC1786C除了 6 年前 Windows 2000 Server 的旧备份外，什么也没找到。
- 我尝试运行 dcgpofix，但却失败了，因为域的架构类型与工具的架构类型不匹配。
- 我已经运行了 dfsutil /PurgeMupCache，但实际上没有任何反应。
答案1
当您谈到“移动”登录脚本和 GPO 时，这让我认为您没有让 SYSVOL 正确复制。组策略的基于文件的部分会自动复制到新服务器计算机的 SYSVOL 中。您可能把事情搞得一团糟，具体取决于复制了什么或没有复制什么以及您采取了哪些步骤。
话虽如此，如果您的所有客户端计算机上都没有出现错误，我非常怀疑“默认域策略”是否“损坏”或丢失。（客户端上出现错误的频率远低于每 5 分钟一次。它们应该是每 90 分钟一次。）
在我看来，服务器计算机本身存在名称解析、DFS 或文件和打印共享协议问题。
一些问题：
- 服务器计算机上的 DCDIAG 输出是什么样的？
- 该服务器是否使用其自身（且仅使用其自身）作为其 DNS 服务器？
- 您能否从服务器计算机上的 Windows 资源管理器浏览到 GPO 的路径（在错误消息中）？
答案2
我遇到过类似的问题，我搜索了我的笔记，使用“dfsutil /PurgeMupCache”修复了这个问题。我认为 dfsutil 来自 2k3 安装 CD 上的支持工具。这肯定来自知识库文章，但我的笔记没有说明是哪篇文章。不过值得一试。
JR
答案3
显然，我的同事通过重建 GPO 并删除旧 GPO 的痕迹解决了这个问题。我不知道他具体是怎么做到的，但如果我能找到更多信息，我会用我找到的信息更新这篇文章。