这回连系统都进不了了，看来也没什么戏好唱了，只能把一些应用修改全部删除，这就是用虚拟机的好处，哈!!!!!，而且我在前面配置好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可不是闹着玩的，工作量大得很，这也许就是虚拟机的好处吧
.分页: [1] [2]
TAG: Exchange 域控制器