經歷了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】。
![p_w_picpath]( "p_w_picpath")
![p_w_picpath]( "p_w_picpath")
![p_w_picpath]( "p_w_picpath")
夜晚悄悄降臨，在服務器一次又一次的重啓中我們思考着。偶然一次的重啓，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
本來並不抱希望的重建，雖然沒有報錯，在顯示那個熟悉到不能在熟悉的登陸框面前，我們激動了。試試登陸，也沒有問題。立刻修改了地址跳轉和登陸方式。終於可以鬆一口氣了。