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

 

原本並不抱但願的重建，雖然沒有報錯，在顯示那個熟悉到不能在熟悉的登錄框面前，咱們激動了。試試登錄，也沒有問題。馬上修改了地址跳轉和登錄方式。終於能夠鬆一口氣了。