服务器 频道

Windows Server 2008 R2域故障解决实战

        【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用户和计算机时发现如下图所示的故障:

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也可以正常的复制数据。群集上的应用也恢复正常了,似乎一切都平静了。但故事还没有结束。

${PageNumber}

  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这两个共享文件夹,显示如下图所示:

${PageNumber}

  圆满解决

  下面的操作就有点复杂了,我们要想办法实现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信息,如下图所示:

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

4
相关文章