13518219792
在工作中有时会出现Exchange服务器在意外重启后蓝屏并且无法直接恢复的情况，通过灾难恢复方式处理之后稳定运行一个月该服务器又出现脱域的现象。在此我总结处理问题的过程及思路，希望能对同行有所帮助。环境：
操作系统：Windows Server 2008 R2 sp1
Exchange版本：Exchange2010sp3 CU8
架构：3台CAS+4台MBX
现象：CAS服务器中的一台（用CAS2表示）系统在意外重启后无法进入系统。测试同样无法进入安全模式和最后一次正确配置。
解决过程：
根据微软官方文档
https://technet.microsoft.com/zh-cn/library/dd876880(v=exchg.141).aspx
提供的信息得知恢复操作需要满足先决条件：
执行恢复操作的服务器必须运行与丢失服务器相同的操作系统；
执行恢复操作的服务器必须与丢失服务器拥有相同的性能特征和硬件配置；
可在安装了客户端访问、集线器传输、邮箱或统一消息服务器角色的 Exchange 2010 服务器上运行。
客户处的Exchange2010环境中没有安装边缘服务器的角色，完全能满足上述条件。另外能确定的时原有Exchange服务器上安装程序的路径为默认值，使得恢复过程变得更加便利，不需要指定自定义的安装路径。
整个恢复过程还算顺利，等用户信息同步完成后测试新装CAS2的OWA和outlook功能都能正常使用。最后将新加服务器加入NLB群集即可。如果环境中使用的是硬件负载设备，只需启用对应IP策略即可。
本以为事情就这样结束了，事实观察使用两周的情况都还不错，没有出现批量用户报障。大约一个月后的周一，上班时大量用户反馈outlook弹窗需要输入密码，并且在输入密码后也不能使用。马上分别检查三台CAS的owa访问是否正常，恰好是CAS2无法正常使用：可以弹出登录界面，输入密码后无法进行进一步跳转。使用邮箱管理员账号亦无法登录至该服务器，本地管理员可登陆。登陆后立即做了基础诊断：
网络配置正常，与DC和其他Exchange服务器之间网络畅通；
系统资源正常：磁盘使用情况、CPU和内存在使用率都在正常范围内；
切换其他域管理员账号登录提示无法建立信任关系。
为了进一步确认是脱域，我使用nltest测试了域安全通道信任关系：
nltest /server:servername /sc_query:domainname
系统提示Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
为了尽快恢复业务，没有深究脱域的原因而是恢复信任关系。通常客户端脱域之后最简单的处理办法时退域之后重新加域即可，比较简单的判断是否正常的手段是检查网络适配器是否连接到了域网络，根据我的经验脱域的计算机多显示为公用网络。
邮箱服务器不便采用退域重新加域的方式处理，防止在退域的时候AD数据库会抹除部分Exchange服务器特有的信息，需要使用netdom工具来重建信任关系
在脱域的服务器上运行
netdom resetpwd /Server:dcname /ud:mailadminaccount /pd:password
有惊无险，重启后邮箱恢复正常，不过整个处理的过程倒是循序渐进。后续检查了系统日志试图确认服务器脱域的原因，未找到有相关信息。微软论坛求助等多方资源求助无果后便没再深究。
造成服务器脱域的因素时多方面的，诸如计算机重名、长时间关机未与域通信或者sid冲突等都有可能。
【总结】
两次故障都能恢复有一个很大的条件时，当前客户环境是3CAS提供服务，配置信息可以从正常服务器上同步过来。其中蓝屏和脱域的恢复都需要的一个动作是重置计算机账号，而不是直接删除。这是比较关键的点，既能保留原有信息又防止因为计算机名冲突SID不一致导致无法正常入域的现象。
再者，命令处理的方式对于问题的诊断和恢复都更有针对性，对定位问题提供了更明确的方向。
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
