在我的公司，我们有一台 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，并且正在应用，所以我们很好部分。但是，我想让这些错误消失，因为这很烦人。（我每天早上都会在收件箱中收到所有错误的副本）。
我试图运行 dcgpofix，但这只会给我以下错误消息：
Microsoft Windows [版本 5.2.3790] (C) 版权所有 1985-2003 Microsoft Corp.
U:>dcgpofix
Microsoft(R) Windows(R) 操作系统默认组策略还原实用程序 v5 .1
版权所有 (C) 微软公司。1981-2003
描述：为域重新创建默认组策略对象 (GPO)
语法：DcGPOFix [/ignoreschema] [/目标：域 | 直流| 两个都]
此实用程序可以将默认域策略或默认域控制器策略中的一个或两个恢复到全新安装后立即存在的状态。您必须是域管理员才能执行此操作。
警告：您将丢失对这些 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 ，它实际上什么也没做。
当您谈论“移动”登录脚本和 GPO 时，我认为您没有让 SYSVOL 正确复制。组策略中基于文件的部分会自动复制到新服务器计算机的 SYSVOL 中。你可能把事情弄得一团糟，具体取决于复制或不复制的内容以及你采取的步骤。
话虽如此，如果您在所有客户端计算机上都没有收到错误，我高度怀疑“默认域策略”是否“损坏”或丢失。（客户端上的错误比每 5 分钟发生一次的频率要低得多。它们每 90 分钟发生一次。）
在我看来，您的服务器计算机本身存在名称解析、DFS 或文件和打印共享协议问题。
一些问题：
我有一个类似的问题，并搜索我的笔记我使用“dfsutil /PurgeMupCache”修复它。我认为 dfsutil 来自 2k3 安装 CD 上的支持工具。这一定来自知识库文章，但我的笔记没有说明是哪一篇。值得谷歌虽然。
JR
显然，我的同事通过重建 GPO 并删除旧 GPO 的痕迹解决了这个问题。我不知道他到底是怎么做到的，但如果我能找到更多关于它的信息，我会用我发现的内容更新这篇文章。