WindowsServer2008R2域迁移后存在的故障解决方法.doc

窗体顶端 窗体底端 Windows Server 2008 R2域故障解决实战 　　到现场后，先了解当前的情况：一个父域是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这两个共享文件夹，显示如下图所示： 窗体顶端 窗体底端 　　圆满解决 　　下面的