【IT168 技术】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信息，如下图所示：

　　好了，我们此次故障算是圆满解决了。也希望大家能从此篇文章中有所收获，如果你在工作中遇到了此问题，也希望与你交流。