主域控降级后Exchange服务故障解决图解

一日闲来无事，正在天极东荡西逛的时候，QQ上出现了等米下锅这个家伙的信息，打开一看，是别人问他的一个关于Exchange的问题:主域控上安装了Exchange，由于主域控发生了一些问题，需要降级，成功降级后，虽然网络上存在着很多台额域，但Exchange服务却启动不了了，米锅问我有没有碰到过类似的情况?说实话，我的确是没有碰到过，不过我记得他以前和我讨论过这个问题，我当时是建议为其它的额域或成员服务器上再安装一个Exchange服务器，并做成群集，这样就算把主域控完全删除也不会有任何问题，但当时米锅却比较反对这样操作，他认为做成群集对以后的管理会造成很大的麻烦，而且提出这个问题的人似乎水平也不咋的，群集管理对他而言可能难度比较大。从米锅现在提出的这个问题来看，对方似乎已经把主域控降级了，看来现在说什么也于事无补了。米锅说他的机器配置不好，做不了实验，想让我帮忙做一个，我想反正没事，就满口答应下来。现在我把整个实验的过程、解决方案及实验中走过的一些弯路写下来，希望能和大家分享一下。

　　首先，来介绍一下实验环境:

　　域名:exc.com

　　主域控

　　机器名:TEST2003.exc.com

　　OS:Windows Server 2003

　　IP:192.168.2.1

　　子网掩码:255.255.2550

　　DNS服务器:192.168.2.1

　　并在上面安装Exchange 2003

　　额域控:

　　机器名:TEST20031.exc.com

　　OS:Windows Server 2003

　　IP:192.168.2.2

　　子网掩码:255.255.2550

　　DNS服务器:192.168.2.1

　　对于如何把成员服务器配置成主域控，如何配置成额域控，及如何配置DNS，安装Exchange 2003之类的操作我就不在此详细说明了，如果大家在配置、安装过程有什么问题的话，可以给我发E-Mail，我的E-Mail:hzswg@sohu.com，本次实验我总共做了两次，因为第一次失败了，好，现在先来说第一次实验:

　　当然，首先得把这个环境做出来，我在主域控上运行Dcpromo，把主域控降级成为成员服务器:

　　点“下一步”可能出现下图:

　　这是由于主域控是全局编录服务器，可以先点“确定”，降级完成后到其它域控上指定，也可以先到其它额域上指定，然后再降级。其它就没有什么好说的了，一路上点“下一步”就可以了。然后重新启动系统。

重启后，发现Exchang的服务果然无法启动，又去运行了一下Exchange的“系统管理器”，发生了如下错误:

　　于是再进入事件查看器，发现在系统里产生如下错误:

　　在应用程序日志里发现了以下几处错误日志:

从上面的日志可以看出，Exchang仍然把原来的TEST2003在做为域控制器，于是我在TEST2003上运行了一下dsa.msc，想看一下上面有关Exchang的一些用户的属性，但是我一运行，却发现如下错误提示:

　　我一看这个提示，第一感觉是降级时发生了问题，所以无法和现有的域控连接，所以我就把TEST2003退出域，然后重启，准备重新加入域看一下，但是遗憾的是虽然成功的退出了域，但在重启过程中到下图位置里再也无法通过:

　　在进入安全模式时也出现类似情况，区别只是在于正常模式下是停在“准备网络连接”，而安全模式下则停在“正在应用计算机设置”。

　　这回连系统都进不了了，看来也没什么戏好唱了，只能把一些应用修改全部删除，这就是用虚拟机的好处，哈!!!!!，而且我在前面配置好Exchang后保存了一次，现在想想实在是太英明了。

　　在第二次操作前，不妨先来分析一下问题，前面我已经提过了，从日志上看，Exchang还在把原来的TEST2003当成域控，但TEST2003我是运行Dcpromo进行降级的，那么TEST2003应该会变成成员服务器，就算TEST2003不是域控，但只要有权限，也可以运行dsa.msc进行域用户的管理的，现在运行这个都不行，这就说明不仅仅是Exchang的问题了，那么问题会不会在TEST20031的DNS服务器上呢?我进入TEST20031有DNS服务管理器上看了一下，发现果然在上面的记录里TEST2003还是被当做一台域控，如下图:

　　看来手动去删除这些记录太麻烦了，还不如重做一下DNS，所以我在第二次实验时，先把TEST2003降级，然后在TEST20031上重做DNS，重做后的DNS如下图所示:

　　是不是觉得少了很多东西，不要急，这些纪录过一会DNS会自动修复的。然后，再回到TEST2003上，把上面的DNS服务器改为TEST20031的IP，也就是:192.168.2.2，然后再运行Exchang的系统管理器，发现已经可以运行了。如图:

运行一下services.msc，发现有几个Exchang的关键服务被处于禁用状态，不过不要紧，只要手动改成自动，然后启动一下就可以了，再去查看一下日志查看器，发现系统日志中的错误已经全部解决了，但是应用程序日志8260和8026日志依然存在，由于我对Exchang不是十分熟悉，所以看到可以收发邮件，OWA运行也正常就没有理会，直接把这个结果给了米锅，过了几天米锅给了我一段英文:

　　exchange system manager

　　Check the status of the directory and verify that the DC name is correct in the Recipient Update Services.

　　Recipient Update Services在Exchang中文版里被翻译成:收件人更新服务，我找到这个位置，发现Recipient Update Services (Enterprise Configuration)和Recipient Update Services(EXC)仍然把TEST2003当成了域控制器，这就是8026和8260错误的根本所在。

　　解决的办法也很简单，只要把上面的域控制器改成TEST20031就可以了，再重启，发现8026和8260错误日志消失，至此，问题全部解决。

　　总结:其实本次问题的解决方法很简单，但由于事先没有认真思考，所以也走了不少的弯路，所以才花了这么长的时间去解决这个问题，另外提醒大家以后遇到问题多用虚拟机先做实验，等到实验成功后再到物理网络上去实施，因为一旦物理网络出现问题。在大型网络上重做域控和Exchange可不是闹着玩的，工作量大得很，这也许就是虚拟机的好处吧!对于以是文章如有什么不妥之处，欢迎大家给我来信!