方案一：

文件复制服务检测到副本集 "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用户和计算机时发现如下图所示的故障：

Windows Server 2008 R2域故障解决实例

　　在DC01上也无法打开AD用户和计算机管理界面，此时判断应该是DNS的问题，两台DC重新启动DNS服务后，故障依旧。 此时采用下面的方法解决：

　　1.将两台机器上的c:\windows\system32\config文件夹中的netlogon.dnb和netlogon.dns分别改名，如下图所示：

Windows Server 2008 R2域故障解决实例

　　在此，我们将二个文件加上bak后缀，然后重新启动DNS服务。如下图所示：

Windows Server 2008 R2域故障解决实例

　　重新启动后，会再次生成新的netlogon.dnb以及netlogon.dns文件，如下图所示：

Windows Server 2008 R2域故障解决实例

　　此时，再打开两台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