在我的公司，我們有一台 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 sc hema 的更新版本。使用不正確的架構恢復 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 的痕跡解決了這個問題。我不知道他到底是怎麼做到的，但如果我能找到更多相關信息，我會用我發現的內容更新這篇文章。