前多少天有一個客戶的公司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以及advancedexchangerecover。郵件營銷郵件營銷成功率高達99%以上,直達客戶收件箱。y等工具，然而有一個最主要的用戶的ost文。郵件歸檔備份輕松，壓縮存儲,萬家合作伙伴,25年經驗,高性價比!件一到70%就報錯，并且有局部用戶本機并不ost文件，所以這個方式只是解決了部門用戶的問題。
這樣我們將重點轉移到了恢復exchange脫機備份的文件上，客戶的數據庫在20g左右，我將mdbdata下的文件copy到我的exchange測試環境中對數據庫的狀況進行數據恢復測試，這里有兩個kb給了我很大輔助，
經由數據收拾，數據庫的狀況變為clear shutdown
而后我將db mount到我的存儲中，無奈加載，日志中記載了1088的過錯
事件 id：1088
源：msexchangeis
類型：毛病
種別 general
闡明：
the information store could not be loaded because the distinguished name 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文件。