方案一：
文件複製服務檢測到副本集 "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 正處於 JRNL_WRAP_ERROR。
事件類型: 錯誤
事件來源: NtFrs
事件種類: 無
事件 ID: 13568
日期: 2006-11-1
事件: 11:34:09
用戶: N/A
計算機: SERVER
描述:
文件複製服務檢測到副本集 "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 正處於 JRNL_WRAP_ERROR。
副本集名稱是 : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
副本根路徑是 : "c:\windows\sysvol\domain"
副本根卷是 : "\\.\C:"
當嘗試從 NTFS USN 日誌讀取的記錄沒有找到時 副本集達到 JRNL_WRAP_ERROR。下列原因之一 可能導致這一問題。
[1] 卷 "\\.\C:" 已經格式化。
[2] 卷 "\\.\C:" 上 NTFS USN 日誌已經刪除。
[3] 卷 "\\.\C:" 上 NTFS USN 日誌已經截斷。如果 Chkdsk 在日誌結尾發現損壞的項目，可能會截斷日誌。
[4] 文件複製服務已經長時間沒有在此計算機上運行。
[5] 文件複製服務無法與 "\\.\C:" 上磁盤 IO 活動保持相同速率。
設置 "Enable Journal Wrap Automatic Restore" 註冊表參數爲 1 將 導致下面的恢復步驟將被執行以自動從此錯誤狀態中 恢復。
[1] 第一次輪詢將在 5 分鐘內執行，此計算機將 從副本集中刪除。如果您不想等待 5 分鐘，那麼 運行 "net stop ntfrs" 然後運行 "net start ntfrs" 以重新啓動文件複製服務。
[2] 在刪除後的輪詢中，此計算機會被重新添加到複製集中。 此重新添加將會爲此複製集觸發一個樹的完全同步。
注意: 在恢復過程中副本樹中的數據可能不可用。 如果此錯誤情況再次發生，您應當重置上述註冊表 參數爲 0 以阻止自動恢復導致數據意外的 不可用。
要更改此註冊表參數，運行 regedit。
單擊「開始」，運行並鍵入 regedit。
展開 HKEY_LOCAL_MACHINE。
單擊鍵路徑:
"System\CurrentControlSet\Services\NtFrs\Parameters"
雙擊此值名稱
"Enable Journal Wrap Automatic Restore"
並更新值。
如果此值名稱不存在，您可以使用編輯菜單項下的 “新建->DWORD 值”功能添加它。鍵入與上面的值完全一樣的值。
有關更多信息，請參閱在 http://go.microsoft.com/fwlink/events.asp 的幫助和支持。
解決方法：
建議不要按照日誌的提示進行操作，正確的操作應該是
出現這個問題的原因，是由於在硬件的損壞，導致服務器未正確處理NTFS USN 日誌。它記錄了NTFS捲上的更改的內容，而FRS依賴於USN 日誌來確定需要被複制到FRS的副本集的內容。這個錯誤，可以通重新初始化USN 日誌，使得FRS副本集的日誌一致，請確認其它的服務器是否有包含13568事件，如果至少有一臺是好的（第一種情況），則可以通過非權威還原來重新初始化。請根據以下步驟操作：
1. 切換到CMD模式，運行net stop ntfrs命令停止FRS。
2. 運行Regedit 啓動註冊表編輯器。
3. 定位到以下位置：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
4. 雙擊BurFlags，修改值爲D2。
5. 在CMD模式，輸入 net start ntfrs 命令啓動FRS。
When the FRS service restarts, the following actions occur:
? The value for BurFlags registry key returns to 0.
? Files in the reinitialized FRS folders are moved to a Pre-existing folder.
? The FRS database is rebuilt.
? The member performs an initial join of the replica set from an upstream partner or from the computer that is specified in the Replica Set Parent registry key if a parent has been specified for SYSVOL replica sets.
? The reinitialized computer performs a full replication of the affected replica sets when the relevant replication schedule begins.
如果所有的服務器都記錄了13568事件（第二種情況），則需執行授權還原，請根據以下步驟操作：
1. 把所有的服務器的FRS都停止。
2. 把其中一臺服務器的BurFlags設置爲D4，其它的步驟和執行非授權還原的操作一樣，在完成授權還原後，檢查FRS日誌，看是否還有問題。
3. 在確定沒有問題後，對其它的服務器執行非授權還原。
正常來說，這個操作不會導致DC崩潰，但爲了確保安全，建議對DC和重要數據進行備份，以免出錯。
如果是單域單DC狀態的話（第三種情況）
執行授權還原，請根據以下步驟操作：
1. 切換到CMD模式，運行net stop ntfrs命令停止FRS。
2. 運行Regedit 啓動註冊表編輯器。
3. 定位到以下位置：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
4. 雙擊BurFlags，修改值爲D4。
5. 在CMD模式，輸入 net start ntfrs 命令啓動FRS。
此文章轉載自：http://hi.baidu.com/kong10111/blog/item/298f9f5c0d3a8a46fbf2c0c9.html
我的情況如下：兩臺域控制器，主域控制器上沒有此錯誤，13568只出現在輔域控制器上，所以適用第一種情況，採用上文中所寫的解決方法完全解決，域控制器之間文件複製正常。第二、三種情況暫時未驗證。
方案二：
2012年7月9日，一個適合睡覺的陰雨天氣。早晨剛睜開眼就接到領導的電話，客戶兩臺Windows Server 2008 R2域控器出現故障，情況比較緊急，必須立即出發。剛出門，客戶電話打進來，要求30分鐘到現場。我的親哥哥呀，這不要人命嘛!這裏可是北京，陰雨天+周 一+早高峯。30分鐘我肯定飛不過去呀。考慮到事件的嚴重性，客戶只能是先開一個微軟原廠的A級Case，先電話處理着。
到現場後，先 瞭解當前的情況：一個父域是abc.local;兩個子域分別是it.abc.local和hr.abc.local。每個域中有二臺DC。此次出現問題 的是it.abc.local域，此域中的兩個DC名分別是dc01.it.abc.local和dc02.it.abc.local。另有兩臺成員服務 器server1.it.abc.local和server2.it.abc.local安裝有故障轉移羣集，上面配置有客戶應用。
症狀是：1個小時前，羣集應用出現故障，無法切換，處於失敗狀態。管理員登錄到DC上進行排查，發現DC01輸入正確的用戶名密碼無法登錄，懷疑是AD數據庫出現故障。
也就是說這裏看到的是兩個故障：羣集上的應用故障和域的用戶登錄故障。經過分析，判斷羣集上的應用故障應該是由於域故障而起的，所以還是決定先解決域的用戶登錄故障。
DC01你怎麼了?
關於DC02上域管理員賬戶無法登錄的問題，開始懷疑是DC01這臺機器上的數據庫有問題，解決就是想重新啓動驗證一下，如果不行就進行AD的恢復還原，實在不行，還有DC02在，可以將DC01降級再升爲DC，但這是下下策。
確認思路之後，開始按Power，強制關機。重新啓動後，管理員竟然成功登錄進去了，太詭異了。但隨後打開DC02上的AD用戶和計算機時發現如下圖所示的故障：
在DC01上也無法打開AD用戶和計算機管理界面，此時判斷應該是DNS的問題，兩臺DC重新啓動DNS服務後，故障依舊。 此時採用下面的方法解決：
1.將兩臺機器上的c:\windows\system32\config文件夾中的netlogon.dnb和netlogon.dns分別改名，如下圖所示：
在此，我們將二個文件加上bak後綴，然後重新啓動DNS服務。如下圖所示：
重新啓動後，會再次生成新的netlogon.dnb以及netlogon.dns文件，如下圖所示：
此時，再打開兩臺DC的AD用戶和計算機就可以很順利的查看相關對象了。兩臺DC也可以正常的複製數據。羣集上的應用也恢復正常了，似乎一切都平靜了。但故事還沒有結束。
DC02難道不是DC?
按理說兩臺DC都可以正常複製了，羣集上的應用也恢復正常了，應該就沒有問題了。但事實不 是!我們準備進行一下故障演練，當壞掉一臺DC，應用是否還能正常。於是，果斷的拔掉DC01的網線。但問題來了，羣集應用立即轉入失敗。也就是說 DC02沒有支撐起羣集應用。我的天呀，這是怎麼回事?難道是羣集節點服務器沒有找到DC，在兩個節點上解析DC也一切正常。此時使用命令nltest /dsgetdc:it.abc.local /force。查詢當前所識別出來的域控制器和其相應的 IP 地址等信息，顯示結果如下：
這就奇怪了，明明DC02是在線的，怎麼會獲取DC名稱失敗呢?而且域名解析是正常的，如下圖所示：
此時，我們又使用了nltest /dclist獲取it.abc.local域中的所有DC信息，如下圖所示：
前面的DC間複製，發現DC02似乎沒有問題呀，這裏怎麼會找不取DC02呢，也就是說系統發現DC02壓根就不是一臺DC。這是怎麼回事，爲了不影響應用，重新插上DC01的網線。
分析過程如下：
在DC02上運行dcdiag /v命令，來進行AD服務器的診斷並保存到dcdiag.txt文件中，如下圖所示：
此命令將對當前DC進行多項內容檢查，包括avertising、DFSR、Sysvol、KCC、MachineAccount等。通過分析此文件， 發現dc02無法通過檢查。於是確定抓包分析。在DC02上安裝抓包工具，在節點服務器上運行nltest /dsgetdc:it.abc.local /force命令，我們來分析DNS的解析過程是否有問題，結果如下圖所示：
在進行此步調試的時候，仍然需要將DC01處於脫機狀態，客戶端的DNS指向DC02並且清除DNS緩存。但我們從抓包所看DNS解析是沒有問題。客戶 端請求解析_ldap.tcp.default-first-site-name._sites.dc._msdcs.it.abc.local所對應的 SRV記錄，DC02也爲此返回了正確的地址。
接下來檢查DC02上KDC和Netlogon的運行狀態，使用的命令如下：sc query 服務，如下圖所示：
這兩個服務也算正常，但是當我們使用net share查看共享的時候，卻看不到netlogon和sysol這兩個共享文件夾，顯示如下圖所示：
圓滿解決
下面的操作就有點複雜了，我們要想辦法實現netlogon和sysvol的自動共享，其中sysvol 文件夾是安裝AD時創建的，它用來存放組策略和腳本相關信息，用戶登錄或計算機啓動時，會首先在SYSVOL文件查找組策略和啓動腳本。而且此文件夾中的 信息，會自動複製到域中所有DC上。那現在DC02上沒有出現，我們就需要想辦法從DC01複製過來，同理，當sysvol文件夾複製成功 後，Netlogon文件夾也會一起出現。方法如下：
步驟1：net stop ntfrs 首先停止文件複製服務
步驟2：刪除或者是改名 c:\windows\ntfrs\jet\netfrs.jdb;c:\windows\ntfrs\jet\sys\edb.chk; c:\windows\ntfrs\jet\log\edb.log、es00001.jrs、edbres00002.jrs三個文件。可以刪除也可以 改名。
步驟3：修改註冊表：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\NtFrs\Parameters\Backup/Restore\Process at Startup在右邊找到BurFlags由0改爲D2。如下圖所示：
最常見的值 BurFlags 註冊表項是：D2稱爲非授權模式還原;D4稱爲的授權模式還原。
步驟3：net start ntfrs 再啓動文件複製服務。
步驟4：稍等五分鐘左右，檢查應用程序和服務日誌下的文件複製服務日誌：
看到此圖中存在13554的日誌，入站源和出站目標是dco1，一般就說明已經從DC01上開始進行文件複製了。此時，最好在dc01上也重新啓動 Ntfrs服務。此時就可以使用net share查看sysvol文件夾是否出現。如果還未出現，可以使用命令： repadmin /showrepl 查看複製AD複製狀態。
很顯示，複製沒有成功。看來革命尚未成功，同志仍需努力。接下來我們需要利用repdump.exe工具進行檢查：
Rpcdump的作用是：查詢遠程過程調用 (RPC) 終結點的狀態及有關 RPC 的其他信息。
然後分析生成的rpcdump.txt文件，下面我們摘抄一部分分析：
其中Protseq:ncacn_ip_tcp： 也有可能是ncacn_http協議等， 爲RPC over HTTP 選擇指定的協議序列。Endpoint:49662：定RPC 服務器進程爲遠程過程調用偵聽的TCP/IP 端口。
Annotation：ntfrs API：相應的服務。Stringbinding: ncacn_ip_tcp:dc01.it.abc.local[49662]：連接字符串，協議名：對方主機名：端口。
在此次故障中，是因爲手動指定了文件複製服務所使用的端口，而此端口可能與其他服務存在衝突，所以需要將文件複製服務所使用的端口改爲動態分配，方法是需要修改註冊表，如下圖所示：
需要將HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Ntfrs \Paramenters中的Rpc Tcp/ip Port Assigment刪除。如果你打開某臺DC，沒有這一項則說明文件複製服務使用的端口是動態分配。如果是手動的，則需要考慮是否與其他端口衝突。查看某 端口是否衝突也很簡單，使用下面的命令：
Netstat –abon >c:\netstat.txt 此命令執行結束後，從此文本命令中查找該端口(如49153)所對應的PID。
如下圖所示：
可以看到49153被eventlog程序所用，PID是824。然後使用下面的命令tasklist/svc，可以進一步824所對應的具體程序或服務：
通過以上兩個命令就可以找出服務所使用的端口信息，以及文件複製服務所用的端口是否存在衝突。另外，如果需要檢測135端口，也可以使用Netstat –abon >c:\netstat.txt分析，在另一臺DC上使用telnet遠程測試一下： telnet dc02.it.abc.local 135，在此不再論述。
經過以上步驟的分析和操作，故障基本上就可以解決了，在節點server1上執行nltest /dclist:it.abc.local命令返回DC信息，如下圖所示：
好了，我們此次故障算是圓滿解決了。也希望大家能從此篇文章中有所收穫，如果你在工作中遇到了此問題，也希望與你交流。本文來自：http://server.it168.com/a2012/0712/1371/000001371360_2.shtml