Exchange 2007 灾难恢复手记

经历了 2天彻夜的奋战，终于将 Exchange 2007 从灾难中恢复过来。也算是体验了一把技术支持的辛苦，如今把恢复过程分享给你们，本身也作个备忘录。

  

事件的原由：

   

根据公司今年的规划，要将同城内A站点的Exchange 2007服务器迁移至同城内B站点中，因此负责Exchange的同事就首先在B站点中先扩展了域架构，而后部署了一台安装有相同角色（Hub transport、Client Access、Mailbox、Umified Messaging）的Exchange服务器，而后安装了最新的rollup 9补丁集。

  

注意：此时部署好B站点内的服务器后，并无进行AD站点同步 。

 

 

爆发的故障：

   

次日当咱们依旧使用Exchange OWA来访问邮箱时，竟然发现页面显示【440 Login Timeout】错误。按照以往的经验，咱们觉得是IIS中的OWA目录损坏了，致使了验证失败。因此咱们按照微软关于此错误的经典KB941201（ http://support.microsoft.com/kb/941201/zh-cn ）将CAS角色的IIS虚拟目录进行重建。重建完成后，竟然发现仍然提示【440 Login Timeout】。

 

注意：此时，HUB、MB和UM角色功能正常，且使用Outlook收发邮件也正常。

  

这时咱们为了尽快恢复OWA功能，决定重建CAS角色。因为考虑到迁移以后，B站点内暂时不须要UM角色，因此咱们先使用PowerShell正常卸载了UM和CAS角色。而后重启了服务器。

  

事态严重：

   

重启服务器以后， 在安装CAS角色时，提示【须要 DSProxy.dll，但没法加载】。同时发现A站点内Exchange的服务管理器中，【 Exchange System Attendant 和Information Store 】服务都处于中止状态，尝试手工启动，提示报错，没法启动。

  

注意：虽然Exchange System Attendant服务中止不会致使Information Store也没法启动，但咱们遇到的状况是这样。

  

这一事态给咱们吓出一身冷汗，此时邮件服务已彻底没法使用。马上向Google大神请教问题，通过搜索找到微软知识库文章 （ http://technet.microsoft.com/zh-cn/library/bb218464(EXCHG.80).aspx ）

  

火速修改了注册表DSProxy文件的路径，再次启动【 Exchange System Attendant 和Information Store 】服务，状态正常。Outlook此刻已恢复正常使用，但CAS角色仍然没法经过图形或PowerShell方式进行安装。

  

经过Google和百度的双重搜索，咱们在钉子的博客中找到这样一篇文章：大体的意思是：

  

Exchange Server 2007 是经过注册表中的Watermark的键值来定位安装失败的。首先，安装程序会在C:\ExchangeSetupLogs下写入相似     <Install_Type>-<ServerRole_Or_Component>-Date-TimeStamp.ps1     这样的文件。当咱们要进行安装排错时，能够打开这个文件，你将会发现有不少相似# [ID = fdfe6b1a, Wt = 1, isFatal = False]这样的内容，你能够找到对应于Watermark的ID，也就是说在这个ID的任务没有正常完成。安装停止了

因而咱们在文章中提到的注册表位置找到了Watermark和Action键值，在对应的角色文件夹中删除这两个键值。再次启动Exchange安装程序，CAS角色能够正常部署了。

 

 

回到原点：

   

通过一番折腾，咱们又回到了原点：OWA没法访问，报440 LOGIN TIME OUT。此时时间已经指向了下午5点。

 

 

一番风雨：

   

通过N屡次的搜索，网络上关于此问题的解决方法千篇一概，但无论咱们如何进行目录重建，IUSER和IWAN帐户密码与元数据库的同步，OWA展示给咱们的依然是那白底黑字桀骜不驯的【440 LOGIN TIME OUT】。

  

夜晚悄悄降临，在服务器一次又一次的重启中咱们思考着。偶然一次的重启，Information Store服务没有启动，但OWA返回的提示依然是【440 LOGIN TIME OUT】。咱们灵光一闪，思考是否是Exchange服务器与域的验证出了问题，翻看事件记录，果真发现一些蛛丝马迹。在Exchange服务器系统日志中，发现Event ID为5719和Event ID为7的两个事件

 其中在 Exchange指定域控制器中，还有 Event ID为 5723的错误事件

 

这几个事件的连续发生，让咱们联想到果真是Exchange服务器与域之间的验证出了问题。因而在咨询了退域没有太大风险以后，果断的进行了从新加入域的操做，同时在退域和加域的时候都手工进行了站点间域控制器同步。

 

不过结果依然不理想，但至少AD和Exchange中都不存在帐户验证的错误了。

 

 

小插曲：IIS中OWA相关程序池会自动禁用，这时只要让计算机自动更新，就能够查找到新的.net程序补丁，安装便可排除问题。

 

 

峰回路转：

 

又是无数次的Google和百度，依然没有好的方案。翻了无数的文章，都是要重建IIS虚拟目录或者重建CAS，鉴于前次的CAS重建受挫，虽然对此颇有顾忌，但没有其余办法的话，也只能死马当活马医一下了。

 

关于CAS重建，找到微软KB320202（ http://support.microsoft.com/kb/320202/en-us ）和顾武雄的讲义PPT

 

http://download.microsoft.com/download/9/b/2/9b24903a-a633-4901-97fa-f87abb618027/1032353254/0117_Exchange2007_Reconstruct.ppt

 

原本并不抱但愿的重建，虽然没有报错，在显示那个熟悉到不能在熟悉的登录框面前，咱们激动了。试试登录，也没有问题。马上修改了地址跳转和登录方式。终于能够松一口气了。