一家公司Exchange Server出現硬件問題，管理員在危機關頭非常幸運的Copy出了Exchangeinstall目錄中的所有文件。非常糟糕的是這家公司的DC和Exchange在同一臺Server上，并且沒有其他的DC。

    由于客戶對郵件的應用比較敏感，管理員在第一時間重新安裝了DC，并且又安裝了Exchange在上面，我了解他的想法，先可以收發郵件以后再說...

    管理員曾經嘗試幾次恢復AD并且恢復Exchange未能成功，后來找到了我們... ...

    通過我們對客戶狀況的調研，核心信息如下

    1、客戶單臺使用Exchange 2003作為郵件服務器，上一次通過NTbackup備份的郵箱存儲已經間隔達三個月之久，基本無利用價值。

    2、客戶已經搭建了一個新的Exchange環境，已經使用了一周，但是舊的數據一直沒有導過來。

    3、用戶都是使用MAPI的方式收發郵件，用戶郵件都是存放在服務器上，本機使用MAPI的緩沖模式，本機的OST文件，有一部分人已經Copy到PST保存，但仍有用戶OST目前無法打開。

    經過以上信息匯整得出，用戶最為迫切的需求是恢復舊的郵件，并且重新架構目前的Exchange環境，并做好備份體系避免類似故障的發生。

    重新架構Exchange和建立備份體系的問題，可以另外開文章去寫，我這里想記錄的是Exchange恢復的過程。那么恢復郵件客戶有兩個可以利用的資源一個是本地的OST文件，另外是Exchange 2003的離線備份文件。

    客戶規模比較小，想盡量降低恢復數據的成本。我首先建議他們利用OST2PST這樣的工具把用戶的郵件導出到PST中，但是非常遺憾的是，我們使用了OST2PST以及AdvancedExchangeRecovery等工具，但是有一個最重要的用戶的OST文件一到70%就報錯，并且有部分用戶本機并沒有OST文件，所以這個方法只是解決了部分用戶的問題。

這樣我們將重點轉移到了恢復Exchange脫機備份的文件上，客戶的數據庫在20G左右，我將MDBData下的文件Copy到我的Exchange測試環境中對數據庫的狀態進行數據恢復測試，經過數據整理，數據庫的狀態變為Clear Shutdown，然后我將DB Mount到我的存儲中，無法加載，日志中記錄了1088的錯誤

事件 ID：1088
源：MSExchangeIS
類型：錯誤
類別 General
說明：
The information store could not be loaded because the distinguished name (DN) of the message database
/O=OldOrg /OU=OldSite /CN=RECIPIENTS /CN=
does not match the DN of the directory
/O=OldOrg /OU=OldSite /CN=RECIPIENTS /CN=

The database may have been restored to a computer that is an organization or site different than the original database.

組織名稱和管理組不一致的問題，因為我這個是測試環境，所以我就用Legacydn.exe 的forcewrite的模式將我的Exchange環境DN修改成為這個DB當時的組織名稱，如何下載Legacydn.exe可以訪問。如果你不確定舊組織的名稱，也可以通過這個方式查看，雖然KB是寫給Exchange 5.5的，經過我測試在03下一樣適用，修改完成之后，唱出一口氣，DB Mount成功。

 下面就是在我的環境中重建DB中的賬號，如果賬號少你當然可以新建然后關聯賬號，但是如果賬號很多的話，你可以通過這個Mbconn.exe 這個工具重建DB中的AD賬號，然后將賬號重新管理之后，使用Exmerge這個工具將郵箱導出到PST文件。