Exchange 2007 灾难恢复手记

出处：blog.chinaunix.net/ 作者：张伟时间：2010-7-28 10:58:48

经历了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

本来并不抱希望的重建，虽然没有报错，在显示那个熟悉到不能在熟悉的登陆框面前，我们激动了。试试登陆，也没有问题。立刻修改了地址跳转和登陆方式。终于可以松一口气了。

分享到：

邮件服务器

Exchange 2007 灾难恢复手记