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
本来并不抱希望的重建，虽然没有报错，在显示那个熟悉到不能在熟悉的登陆框面前，我们激动了。试试登陆，也没有问题。立刻修改了地址跳转和登陆方式。终于可以松一口气了。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
