單位採用帶有域的局域網，域內有一臺名爲paqserver2的主域控制器，該服務器也是域內唯一一臺DC。該服務器同時運行了與AD集成的DNS。
前幾天由於打印室的服務器出現了打印機的共享問題，於是我查看了DC的日誌，發現一切正常，唯有DNS日誌中有如下的警告信息：
事件ID：7062
描述：DNS服務器遇到一個發給自己的數據包 – IP地址10.37.40.100
DNS服務器不應該發給自己數據包。這種情況通常說明有一個配置問題。
……
有可能委任操作正確，但子區域的主要 DNS 有指回該服務器的不正確的 NS 記錄。
如果在該服務器緩存這個不正確的 NS 記錄，則會導致自送。
如果被發現，子區域 DNS 服務器管理應該刪除不正確的 NS 記錄。
根據日誌提示檢查了一下DNS，發現的確有一些NS記錄有問題，比如其中顯示網內有另外幾臺 域控制器STJJ-DC、ZFLW、Proxy1…等等，因爲這幾臺機器事實上根本不存在了，於是刪掉，（其實這些記錄一直存在，只是因爲服務正常所以沒去管它，正好借這次機會刪掉）結果問題沒有解決，又在“文件複製服務”日誌中出現了文件複製服務的錯誤提示：
事件ID：13568
描述：文件複製服務檢測到副本集 "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 正處於JRNL_WRAP_ERROR。
副本集名稱是 : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
副本根路徑是 : "c:\windows\sysvol\domain"
……
設置 "Enable Journal Wrap Automatic Restore" 註冊表參數爲1將導致下面的恢復步驟將被執行以自動從此錯誤狀態中恢復。
[1] 第一次輪詢將在 5 分鐘內執行，此計算機將 從副本集中刪除。如果您不想等待 5 分鐘，那麼 運行 "net stop ntfrs" 然後運行 "net start ntfrs" 以重新啓動文件複製服務。
[2] 在刪除後的輪詢中，此計算機會被重新添加到複製集中。此重新添加將會爲此複製集觸發一個樹的完全同步。
注意: 在恢復過程中副本樹中的數據可能不可用。如果此錯誤情況再次發生，您應當重置上述註冊表參數爲0以阻止自動恢復導致數據意外的不可用。
要更改此註冊表參數，運行 regedit。
展開 HKEY_LOCAL_MACHINE。
單擊鍵路徑: "System\CurrentControlSet\Services\NtFrs\Parameters"
雙擊此值名稱"Enable Journal Wrap Automatic Restore" 並更新值。
如果此值名稱不存在，您可以使用編輯菜單項下的 “新建->DWORD值”功能添加它。
既然刪了就刪乾淨一些。(正常域控刪除應該通過命令dcromo實現，這些記錄顯然是之前沒有正確進行AD降級造成的殘留記錄，只好直接刪除)
此時打開“Active Directory用戶和計算機”控制檯，在Domain Controller 裏面可以看到若干臺主機記錄（其中只有paqserver2本身是正確的），錯誤記錄無法刪除，提示“不能刪除DSA對象”，但是可以“所有任務-移動” 到普通的Computers組裏面。
打開“AD站點和服務”控制檯，在“Sites/Default-first-site /Servers”裏面同樣可以看到這些錯誤的服務器，但是隻有paqserver2和stjj-dc兩臺機器存在NTDS Settings，在此處其他無效服務器記錄可以刪除，但stjj-dc依然無法刪除，最後用ntdsutil工具（在系統安裝盤 support/tools下）刪掉了（按網上資料進行的，具體步驟記不清了，同上面的錯誤同時出現的還有一個與stjj-dc有關的文件複製錯誤，用 ntdsutil刪除後提示消失，但問題仍未解決）。
然後又按照上述日誌提示增加了註冊表鍵值Enable Journal Wrap Automatic Restore，並重啓了FRS服務，結果問題似乎變得更加嚴重：“文件複製服務”在FRS服務啓動信息出現後，又出現瞭如下警告提示：
事件ID：13566
描述：File Replication Service正在掃描系統捲上的數據。在此進程完成之前，計算機SV-01不能成爲域控制器。系統卷將被共享爲SYSVOL。
要檢查 SYSVOL 共享，在命令提示下，輸入：net share
File Replication Service 完成掃描進程後，SYSVOL 共享會出現。
初始化系統卷要花時間。所花時間基於系統捲上的數據。
而該操作始終無法完成，SYSVOL共享也沒有出現，嘗試手動共享該目錄無效，在Directory Service 日誌裏面出現如下錯誤提示：
事件ID：1126
描述：無法與全局編錄建立連接
此時發現的問題是客戶機無法再加入域，而已加入的機器退出以後也無法再加入，在XP上的提示爲“指定的域不存在或者無法聯繫”，查看詳細則顯示可能是DNS解析錯誤。
用nslookup 進行DNS測試，反向解析出錯，正向解析沒有問題。（因爲該DNS是安裝AD時系統自動創建的，默認並不需要配置反向搜索區域，所以解析是正常的。事實上 後來手工配置了反向搜索區域後，雙向解析都沒有問題，而且最初的“發給自己數據包”的警告也消失了，變成了“DNS服務器寫入區域DominName的版本12697到文件DominName.dns”的正常信息提示。）
在任何客戶機使用 nslookup –type=ns DominName 命令都可以解析出正確的IP，在另外一臺服務器上配置了輔助DNS服務器，並配置爲“標準輔助區域”亦可以正常與該DNS進行記錄的傳遞，證明DNS服務其實是正常的。
現在回想整個操作過程，在檢查並清理NS記錄的時候，只有那臺名爲STJJ-DC的服務器比 較特殊，因爲其他幾臺機器只是作爲A記錄出現的，只有這一臺曾作爲DC和GC出現，而這臺機器並非一臺真正的機器，有可能是域控paqserver2本身 曾經使用過的一個機器名（印象中是這樣，否則沒有理由解釋這臺機器的存在，具體事實記不清了），於是機器名修改造成了一臺物理上的服務器邏輯上被識別成兩臺服務器，並互相進行文件複製服務，而這條NS記錄的刪除則導致了文件複製服務執行失敗，從而導致全局編錄的建立失敗。
按照這個思路，又在DC上執行了dcdiag，輸出結果沒有記錄下來，但跟該鏈接提供的情況大致相同，且都顯示瞭如下錯誤信息：
http://www.mstc.com.cn/archiver/?tid-8878.html
Starting test: FsmoCheck
Warning: DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1355
A Global Catalog Server could not be located - All GC's are down.
Warning: DcGetDcName(TIME_SERVER) call failed, error 1355
A Time Server could not be located.
The server holding the PDC role is down.
Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 1355
A Good Time Server could not be located.
Warning: DcGetDcName(KDC_REQUIRED) call failed, error 1355
A KDC could not be located - All the KDCs are down.
......................... DESIGN.ARK failed test FsmoCheck
在微軟知識庫中搜索其中反覆出現的error 1355，找到下面的文章：
http://support.microsoft.com/kb/316790/zh-cn —— Sysvol和Netlogon共享已從備份還原域控制器後丟失。其中提到：
症狀
從備份, 還原域控制器後 Sysvol 和 Netlogon 共享可能已丟失。並且Dcdiag.exe 沒有通過 FsmoCheck 測試並生成以下錯誤信息：
警告: DcGetDcName(GC_SERVER_REQUIRED) 調用失敗, 1355 錯誤
問題通常發生只如果域控制器， 還原是域, 中只域控制器或如果已還（例如,） 來複制實驗室中生產環境還原所有域中域控制器。
原因
因爲文件複製服務 (FRS) 無法找到有效的複製夥伴來同步 Sysvol 副本集發生此行爲。
與預料的情況相同，於是按其提供的解決方案執行了如下操作：
解決方案
您必須將一個域控制器爲正在對 Sysvol 副本集授權。 如果所有域中域控制器已經還原, 選擇在主域控制器仿真器靈活單主機操作 (FSMO) 角色承擔:
1. 停止文件複製服務在域控制器上。
2. 啓動註冊表編輯器 (Regedt 32 .exe)。
3. 找到並單擊註冊表中以下項下 BurFlags 值：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/ Restore\Process
4. 單擊DWORD在 "編輯" 菜單, 單擊Hex，鍵入D4 ,然後單擊 確定 。
5. 退出註冊表編輯器。
6. 移動 PreExisting 夾出的數據。
7. 重新啓動文件複製服務。
注意 此註冊表值標記作爲對整個副本集授權 FRS 副本。 設置此值僅一個副本, 上和僅要解決此特定問題。 如果配置多個副本作爲權威, 衝突和衝突可能出現在副本集中。
所有其他域控制器上, 一個域控制器上設置 D4 註冊表設置時， 必須設置 D2 註冊表設置。 有關其他信息, 請單擊下列文章編號以查看 Microsoft 知識庫中相應：
操作完成後重啓FRS服務，FRS順利執行完成，並在文件複製服務日誌中記錄瞭如下信息：
文件複製服務不再阻止計算機 PAQSERVER2 成爲 域控制器。系統卷已成功 初始化 ,而且 Netlogon 服務已經收到信息表明系統卷已經準備好共享爲 SYSVOL。
Directory Services日誌裏面顯示如下信息：
AD找到了以下全局目錄
AD服務終於恢復正常，亦可以成功將客戶機加入域，本以爲結束了，但是查看應用程序日誌裏面卻出現瞭如下兩條錯誤信息：
事件 ID: 1000
描述:Windows不能爲GPO訪問文件gpt.ini。此文件必須位於 < >。()。組策略處理被放棄。
事件 ID: 1000
描述:Windows 無法查詢組策略對象列表。描述發生這個故障原因的消息是由這個策略引擎記錄的。
關於這個問題在微軟知識庫中查找了以下兩篇文章：
http://support.microsoft.com/kb/290647/zh-cn —— 應用程序事件日誌中每 5 分鐘記錄一次 Event ID 1000、1001
http://support.microsoft.com/kb/887303/zh-cn —— 應用組策略導致運行 Windows Server 2003、Windows XP 或 Windows 2000 的計算機上發生 Userenv 錯誤和事件
原因：如果您將不適當的權限分配給 %SystemRoot%\Winnt\Sysvol 文件夾或將不適當的組分配給 Bypass Traverse Checking User Rights Assignment（跳過遍歷檢查用戶權利指派），可能會發生此問題。另外，如果 sysvol 共享權限限制過多，也可能會發生此問題。
想到之前的sysvol文件夾是手動共享的，並且6. 移動 PreExisting 夾出的數據。（系統中並沒有該文件夾，但是存在名爲NtFrw_PreExisting__See_Eventlog的文件夾，於是把它修改了）於是按文 章提供的解決方法進行了如下操作：
1.設置文件夾安全權限。請按照下列步驟操作：
a. 在Windows資源管理器中，右鍵單擊 %SystemRoot%\Winnt\Sysvol 文件夾，然後單擊屬性。
b. 在安全性選項卡上，清除“允許從父系來的繼承權限傳播到這個對象”複選框，然後確保安全設置與下列設置匹配：
管理員：完全控制
經身份驗證的用戶：讀取、讀取和執行、列出文件夾內容
創建者所有者：沒有選中項
服務器操作員：讀取、讀取和執行、列出文件夾內容
系統：完全控制
c. 單擊確定。
d. 右鍵單擊 %SystemRoot%\Winnt\Sysvol\Sysvol 文件夾，然後單擊屬性。
e. 在安全性選項卡上，選中“允許從父系來的繼承權限傳播到這個對象”複選框，然後單擊確定。
f. 右鍵單擊 %SystemRoot%\Winnt\Sysvol\Sysvol\domain:文件夾，然後單擊屬性。
g. 在安全性選項卡上，選中“允許從父系來的繼承權限傳播到這個對象”複選框，然後單擊確定。
h. 右鍵單擊 %SystemRoot%\Winnt\Sysvol\Sysvol\domain\Policies 文件夾，然後單擊屬性。
i. 在安全性選項卡上，清除“允許從父系來的繼承權限傳播到這個對象”複選框，然後確保安全設置與下列設置匹配：
管理員：完全控制
經身份驗證的用戶：讀取、讀取和執行、列出文件夾內容
創建者所有者：沒有選中項
組策略創建者所有者：讀取、讀取和執行、列出文件夾內容、修改、寫入
服務器操作員：讀取、讀取和執行、列出文件夾內容
系統：完全控制
j. 單擊確定。
k. 對於位於 %SystemRoot%\Winnt\Sysvol\Sysvol\domain\Policies 文件夾中的文件或文件夾，分別右鍵單擊這些文件或文件夾，然後單擊屬性。在安全性選項卡上，選中“允許從父系來的繼承權限傳播到這個對象”複選框，然後單 擊確定。
2. 打開“Active Directory 用戶和計算機”：單擊開始，單擊程序，然後單擊管理工具。
3. 展開“Active Directory 用戶和計算機”，然後展開域名。
4. 右鍵單擊域控制器，然後單擊屬性。
5. 在組策略選項卡上，單擊“默認域控制器策略”，然後單擊編輯。
運行到第五步時，點擊編輯後出現“無法打開組策略，可能是沒有權限”的對話框，回頭重新檢查 權限設置沒有問題，於是將NtFrw_PreExisting__See_Eventlog文件夾下的文件恢復回去，繼而檢查了DFS服務、運行net time \\(domain controller name) /set /y使時鐘時間與域控同步、文件和打印共享，均沒有問題，但錯誤依然出現，最後重新檢查日誌，注意到此文件必須位於< >。()。的奇怪提示，於是跟知識庫文章中對照發現這裏的路徑應該是%SystemRoot%\Winnt\Sysvol\Sysvol \domain\Policies，而這臺機器domain文件夾下面並沒policies文件夾，只有一個名爲NtFrw_PreExisting__See_Eventlog的文件夾，而該文件夾下面則有一個名爲Policies的文件夾。於是把這個Policies手動複製到了domain文件夾下，錯誤居然停止了，並出現如下信息提示：
ID：1704
描述：組策略對象中的安全策略被成功應用
組策略亦可以正常編輯，於是繼續完成配置如下：
6. 展開下面的文件夾：
計算機配置 - Windows 設置 - 安全設置 - 本地策略
7. 單擊用戶權限分配，然後雙擊“跳過遍歷檢查”。應該出現下列默認設置：
經身份驗證的用戶
所有人
管理員
如果沒有出現，而您又需要添加這些組，請單擊添加，然後單擊瀏覽。
8. 在命令提示符下，鍵入：
secedit /refreshpolicy machine_policy /enforce （因爲顯示正常，這一步跳過）
9. 請驗證 sysvol 共享權限設置是否正確，如下所示：
管理員 = 完全控制
經身份驗證的用戶 = 完全控制
所有人 = 讀取
至此，所有錯誤均已消失，服務恢復正常，故障修復完畢。
後記：因爲之前並未深入學習過Windows的活動目錄，所以在排查簡單錯誤的時候導致了更嚴重的錯誤發生，並且在後繼的錯誤修復過程中亦有嘗試或者冒險的成分在裏面，最後雖然成功修復，但過程很不專業。
這一過程的收穫是修正了本單位原來域中元素混亂的局面，清除了許多之前殘留的錯誤記錄，並對活動目錄有了一次較深入的接觸。對應用於活動目錄的一些術語和工具的使用也有了初步的瞭解。
最後的感覺是，Microsoft的東西 很多很複雜，壞了通常都能夠解決，但是不知道的話找到這個機關則很不容易。希望有機會能系統的學習一下，畢竟在一般層次的服務應用中，Windows還是佔很重要的位置的