一、Alarm! Disaster is Fall……

    糟糕的事情總是在人們最不想它出現的時候出現。這天，那臺4400的服務器，就這樣忽然死亡了……

    據在現場的同事描述，服務器忽然變慢，停止了網絡服務，直到停止一切響應。

    為了恢復服務，他們只有重新啟動該服務器。強制重新啟動服務器后，出現藍屏，系統報告stop: 0x0000007b錯誤，inaccessable_boot_device。一開始我以為只是MBR壞了或者ntldr及NTdetect.com壞了，那樣的話我只需要在故障恢復臺里面使用fixmbr和fixboot來修復。由于服務器使用的是硬件RAID，只能在光盤啟動時使用F6加載RAID的啟動，然后進入故障恢復臺，看看是否能否訪問系統分區。進去后大驚，用diskpart可以看到系統分區，但是系統分區不再可讀了，dir命令無法枚舉任何文件和目錄。

    說到這里，要介紹一下該服務器的環境了。這臺Windows 2000 Advanced Server是這個域（下文使用domian.com命名）的第一臺Domain Controller，五個操作主機角色(FSMO)都在上面。限于條件，上面運行了Exchange Server 2000，也用作了File Server/Printer Server。另外還有DHCP/WINS/DNS。備份的磁帶，容量不足以完成完整備份……所以說，服務器的退出服務，對于我們是一場真正的災難。如果沒有其他的Domain Controller，可能我們要忙上好長時間了。就是因為還有其他Domain Controller，我們還有一線希望！

二、Mission Impossible? Impossible is Nothing!

0、使用其它服務器替代網絡服務

    客戶所受的影響必須降到最小。由于網絡中使用DHCP服務器為客戶機分配地址和提供網絡信息，我們必須先解決客戶機DHCP租約到期更新的問題。

    原先我們只有這一臺DHCP服務器，而現在它壞掉了。于是我們在另外的Server上安裝了DHCP，劃分的地址范圍是原先的20%。這樣做的理由是到期更新租約的客戶機畢竟不是很多，當然也可以根據租約時間長短和客戶機的數量自行調整，更新越快，劃分的地址越多。

同時，我們安裝了WINS和DNS，并且為DNS添加了原先手動設置的區域和記錄。

1、恢復域控制器

    Active Directory是基于Windows 2000網絡環境的基石。有太多的信息保存在這里，有了Active Directory，我們可以恢復相當多的服務器配置信息，比如DNS的配置之類。所以我們首先要考慮的，就是恢復主機角色。

    順便介紹一下主機角色。Active Directory 定義了五種操作主機角色（FSMO）：

 

    架構主機              schema master

    域命名主機            domain naming master

    相對標識號（RID）主機 RID master

    主域控制器模擬器        PDCE

    基礎結構主機           infrastructure master

 

    架構主機是可以更新目錄架構的唯一域控制器。架構更新會從架構主機復制到活動目錄森林中的所有其它域控制器。整個森林中只有唯一一臺架構主機。

    域命名主機是可以執行以下任務的唯一域控制器：在森林中添加或刪除域，添加或刪除描述外部目錄的交叉引用對象。

    相對標識號(RID)主機是負責向其它域控制器分配RID池的唯一一臺服務器。在創建安全主體（例如用戶、組或計算機，也可以理解成賬號）時，需要將RID與域內的標識符結合來創建唯一的安全標識符(SID)。每一個域控制器都會收到用于創建對象的RID池（默認為512）。RID主機通過分配不同的池來確保這些ID在每一個域控制器上都是唯一的。通過RID主機，還可以在同一森林中的不同域之間移動對象。

    域命名主機是基于森林的，整個森林中只有一個域命名主機。相對標識號（RID）主機是基于域的，森林中的每個域都有自己的相對標識號（RID）主機。

    主域控制器模擬器（PDCE）主要實現向后兼容低級客戶端和服務器，也就是允許在Windows 2000域中使用Windows NT備份域控制器（BDC）。本機模式Windows 2000環境里會將密碼更改轉發到PDCE。域控制器驗證密碼失敗后，會與PDCE聯系，以檢查該密碼是否可以通過驗證。因為也許密碼的更改還沒有被復制到當前驗證登錄的域控制器中。森林中各個域的PDCE都會與森林的根域中的PDCE進行同步。PDCE是基于域的，森林中的每個域都有自己的PDCE。

    基礎結構主機確保所有域間操作對象的一致性。當引用另一個域中的對象時，此引用包含該對象的全局唯一標識符（GUID）、安全標識符（SID）和可分辨的名稱（DN）。如果被引用的對象移動，則在域中擔當結構主機角色的域控制器會負責更新該域中跨域對象引用中的SID和DN。基礎結構主機是基于域的，目錄林中的每個域都有自己的基礎結構主機

    默認的，這五種FSMO存在于森林根域的第一臺域控制器（主域控制器）上，而子域中的相對標識號（RID）主機、PDCE 、基礎結構主機存在于子域中的第一臺域控制器。

[1] 清除原有Domain Controller的信息

    因為這臺服務器已經不再可用，我們必須重新安裝，所以需要將原來的服務器的數據從ACTIVE DIRECTORY中刪除。

    完成這個目標，需要使用ntdsutil這個工具。（為便于閱讀，這些命令已折行，粗斜體為輸入內容）

    出現對話框，詢問你是否確定刪除該DC。按“確定”刪除DC1主控服務器。

    從Active Directory users and computers中刪除Domain controllers中DC1服務器對象，可以使用ADSI EDIT工具。ADSI EDIT是Windows 2000 support tools中的工具，你需要安裝Windows 2000 support tool，安裝程序在windows 2000光盤中的supporttools目錄下。在DC2上打開ADSI EDIT工具，展開Domain NC[DC2.domain.com]，展開OU=Domain controllers，右擊CN=DC1，然后選擇Delete，把DC1服務器對象刪除。

    在Active Directory Sites and Service中刪除DC1服務器對象，可以打開Administrative tools中的Active Directory Sites and Service，展開Sites，展開Default-First-Site-Name，展開Servers，右擊DC1，選擇Delete，單擊“確認”按鈕確認。

[2] 在額外域控制器上通過ntdsutil.exe工具奪取五種ＦＭＳＯ

    （為便于閱讀，這些命令已折行，粗斜體為輸入內容）

    出現對話框，按“確定”

    出現對話框，按“確定”

    出現對話框，按“確定”

    出現對話框，按“確定”

    出現對話框，按“確定”

    （注：Seize用于原FSMO不在線時操作，如果原FSMO在線，則需要使用Transfer操作）

#p#副標題#e#

[3] 設置額外控制（DC2.domain.com&, , amp;, , lt;, , /SPAN>）為GC（全局編錄）

 

    打開Administrative Tools中的Active Directory Sites and Services，展開Sites，展開Default-First-Site-Name，展開Servers，展開DC2.domain.com（額外控制器），右擊NTDS Settings選擇Properties，然后在“Global Catalog”前面打勾，單擊“確定”按鈕，然后重新啟動服務器。

[4] 重新安裝并恢復損壞的主域控制器

    修復DC1.domain.com之后，在DC1.domain.com服務器上重新安裝Windows 2000 Server。基本上按照原來的服務器配置安裝組件，但是先不要安裝“證書服務”（安裝“證書服務”后，無法進行有關改名和域的操作）。安裝好Windows 2000 Server之后，再運行dcpromo升級為額外的域控制器；如果需要DC1.domain.com擔任五種FMSO角色，通過ntdsutil工具進行角色轉換，使用Transfer操作（注意：這時DC2在線，不能用Seize，只能Transfer）。完成后再安裝“證書服務”。

    通過Active Directory Sites and Services設置DC1.domain.com為GC，而取消DC2.domain.com的GC。至此，修復Active Directory部分。

    （注：建議domain naming master同時必須作為GC，而不和RID master使用同一臺Domain Controller）

2、恢復郵件服務器

    由于Exchange Server會擴展Active Directory的Schema，將配置信息保存在Active Directory中，所以我們不能簡單地重新安裝了事。那樣會覆蓋掉以前的所有配置信息，包括地址簿結構、郵件存儲還有其他的非郵件存儲數據。讓我們一步一步地來嘗試修復。

[1] 安裝Exchange Server

    為了適應災難恢復環境下的安裝，Exchange Server以及后面的Exchange Server Service Pack的安裝文件都提供了 /disasterrecovery 參數來實現災難恢復環境下的系統修復。

    我們需要將系統恢復到崩潰前的狀態，如果安裝了SP和Patch，新的系統也要安裝相同的SP和Patch。

    安裝組件的選擇也很重要，必須與崩潰時的系統所安裝的組件一致。所以，日常維護中記錄軟件的安裝配置也是一項很重要的工作。

    在這個例子中，安裝好郵件服務器后，依次安裝SP3還有Rollout，恢復到崩潰之前的軟件安裝。

[2] 修復郵件存儲

    Exchange Server 2000 發生損壞時，信息存儲是最容易受到影響的組件之一。實際上Windows家族的很多設計為永遠在線工作的數據庫，都使用了Exchange數據庫引擎。信息存儲由下列四個數據庫文件組成：

    Priv1.edb

    Priv1.stm

    Pub1.edb

    Pub1.stm

 

    Priv1.edb 數據庫文件包含簡單郵件傳輸協議 (SMTP) 郵件，其中包括正在傳送的郵件和存儲在服務器上的郵件。Priv1.stm 數據庫文件包含正在傳送的郵件和存儲的非 SMTP郵件。Pub1.edb 數據庫文件包含用于SMTP 格式信息的公用文件夾存儲。Pub1.stm包含用于非SMTP格式數據的共用文件夾存儲。

    我們的郵件服務器是stand alone的，沒有使用站點連接器，也沒有安裝密鑰管理。所以，我們選擇了KB313184的恢復流程。

    由于我們的數據庫是異常退出，所以需要確認數據庫的一致性。如果數據庫是一致的，則所有日志文件都已提交給信息存儲。如果數據庫不一致，則數據庫可能未損壞。相反，日志文件可能丟失、被損壞或尚未提交到數據庫。

    我們運行下面的eseutil命令以檢查公用和專用數據庫的一致性（為便于閱讀，這些命令已折行，粗斜體為輸入內容）。

    注意：這里假設正在從C盤上的Program FilesExchSrvrBin文件夾中運行程序，并且.edb文件位于Program FilesExchSrvrMdbdata文件夾中，如果執行了升級，這些數據庫文件可能位于C:ExchsrvrMdbdata文件夾中。如果優化了數據庫，則這些文件可能位于另一驅動器上，可根據實際情況自行替換。

    要驗證.edb文件是否一致，請檢查標有“State”的輸出行。為了方便觀察可以在前面的命令行后面分別加上“> mypriv.txt”和“> mypub.txt”，生成兩個文本文件。或者使用“| more”參數來逐屏輸出。

    在我們的例子里，服務器上的數據庫state是“Dirty Shutdown”，所以需要對數據庫進行軟故障恢復，以檢查 Mdbdata 文件夾中是否存儲了日志文件的副本。

注意：以下步驟并不是按操作順序排列的，也不是每一步都必須執行的，修復郵件存儲，需要根據實際情況選擇一步或者幾部執行！

(a) 保存有日志文件的存儲恢復

    執行軟故障恢復時，所有未提交的日志文件都將被提交給信息存儲數據庫。打開數據庫和日志文件所駐留的文件夾，然后在命令提示符處鍵入下面的內容（為便于閱讀，這些命令已折行，粗斜體為輸入內容）：

    單擊“是”運行修復。實用工具將顯示下面的消息：

    完成軟故障恢復之后，程序將顯示下面的消息：

    可再次運行 eseutil /mh 命令。如果公用信息存儲和專用信息存儲的狀態都更改為“一致”，表明數據庫已經修復。

(b) 無日志文件或者日志文件損壞的存儲恢復

    如果eseutil /r 命令未恢復數據庫到一致狀態，請使用硬故障恢復（強制狀態恢復）命令。（注意：該命令可能會丟失某些 Exchange 2000 數據，其中包括尚未提交給信息存儲數據庫的日志文件中所包含的消息。Microsoft 建議，只有在執行軟故障恢復后公用信息存儲或專用信息存儲仍沒有恢復到一致的狀態時，才使用此命令。）

    在命令提示符處，鍵入下列命令（為便于閱讀，這些命令已折行，粗斜體為輸入內容）：

    將 Priv1.edb 文件恢復到一致狀態：

    將 Pub1.edb 文件恢復到一致狀態：

    單擊“是”運行修復。實用工具將顯示下面的消息：

    修復過程中將自動包括.stm 文件。在完成此過程之后，程序將顯示下面的消息：

(c) 進行郵件存儲的脫機碎片整理

    建議對修復的數據庫文件執行碎片整理。特別是磁盤空間不足的時候。可以在另外的機器上執行這種脫機碎片整理工作。如果對 Pub1.edb 文件和 Priv1.edb 文件都運行了軟故障恢復過程，請分別對這兩個文件運行下面的碎片整理命令（為便于閱讀，這些命令已折行，粗斜體為輸入內容）。

    對 Priv1.edb 進行碎片整理：

    對 Pub1.edb 進行碎片整理：

    注意：如果存儲數據庫很大，整理需要一段時間。如果提示磁盤空間不足，請將 Program FileExchSrvrBin 文件夾復制到更大的磁盤，然后嘗試從該位置運行此命令。

 

    刪除 Mdbdata 文件夾中的所有.log 文件、.chk 文件，然后刪除 Temp.edb 文件（如果存在）。 關閉所有收發信的服務，以避免用戶在修復過程中訪問郵件存儲。將數據庫裝入一次，然后立即將其卸載（Dismount）。

    建議對修復的數據庫文件執行碎片整理。特別是磁盤空間不足的時候。可以在另外的機器上執行這種脫機碎片整理工作。如果對 Pub1.edb 文件和 Priv1.edb 文件都運行了軟故障恢復過程，請分別對這兩個文件運行下面的碎片整理命令（為便于閱讀，這些命令已折行，粗斜體為輸入內容）。

    對 Priv1.edb 進行碎片整理：

    對 Pub1.edb 進行碎片整理：

    注意：如果存儲數據庫很大，整理需要一段時間。如果提示磁盤空間不足，請將 Program FileExchSrvrBin 文件夾復制到更大的磁盤，然后嘗試從該位置運行此命令。

#p#副標題#e#

使用<, SPAN lang=EN-US> Isinteg.exe實用工具可對Pub1.edb 數據庫和 Priv1.edb 數據庫的所有區域運行測試，并報告測試結果，而且還會嘗試修復遇到的任何問題。（為便于閱讀，這些命令已折行，粗斜體為輸入內容）：

 

    系統會提示您選擇要檢查的數據庫。

    注意：Exchange 2000 不再結合使用 -patch 選項來實現 Isinteg 實用工具。修補操作將在信息存儲啟動時由 Store.exe 自動執行。

    只能檢查標記為“Offline”（脫機）的數據庫。在選擇一個數據庫后，將出現下面的消息，提示確認我們的選擇：

    重復修復的過程，直到不報告警告、錯誤或修復信息，報告內容類似于以下顯示：

    如果連續三次出現同樣的警告、錯誤或修復信息，可以忽略。這些錯誤可能是由于損壞的電子郵件附件，或者不會阻止啟動信息存儲的類似情況造成的。

(d) 使用ExMerge移動郵件到新的郵件存儲

    如果多次運行 Isinteg.exe 后仍報告同樣的錯誤和警告，但是存儲服務可以正常啟動。我們可以將所有用戶郵箱導出為.pst文件。然后再將這些.pst文件合并為新的Priv1.edb文件。如果使用電子郵件的脫機存儲（.ost文件），必須先將.ost文件移至.pst文件中。

    限制：必須要運行存儲服務。ExMerge只能移動用戶郵箱，不能移動特定的Exchange 2000配置屬性，如連接器設置、Outlook設置或客戶端規則。也不能移動通訊組列表、通訊組列表中的成員或公用文件夾。可以將公用文件夾內容移動到用戶的個人文件夾中，以便在合并的.pst文件中包括公用文件夾信息。如果您嘗試此過程，則必須手動重新創建或重新配置通訊組列表。

    確保當前沒有用戶正在訪問服務器郵箱，運行ExMerge。

    使用兩步合并中的第一步，然后輸入所有用戶。當ExMerge過程完成之后，停止Exchange 2000信息存儲服務，找到并打開 ExchSrvrMdbdata 文件夾，然后重命名Pub1.edb和Priv1.edb文件。刪除此文件夾中的所有其他文件。在確信合并成功完成之前，請務必不要刪除重命名的 Pub1.edb和Priv1.edb文件，以留作備份。重新啟動 Exchange 2000 信息存儲服務。在客戶機上啟動 Outlook，然后向 Exchange 2000 全球通訊簿中的所有用戶發送一封電子郵件。（注意：如果未完成此步驟，ExMerge 兩步合并中的第二步將不顯示任何可供還原的郵箱。）

    使用兩步合并中的第二步運行 ExMerge，然后輸入所有用戶。完成此過程后，以前存儲在.pst文件中的電子郵件將被移至Exchange 2000郵箱，我們將得到一個包含所有電子郵件副本的新 Priv1.edb 文件。（注意：如果用戶登錄到空郵箱，則帳戶可能未連接到新創建的郵箱。）

    要恢復公用文件夾存儲，需要在客戶端（如Outlook）將公用文件夾復制到該客戶端上用戶的個人文件夾。停止信息存儲服務，然后重命名現有的 Pub1.edb 和 Pub1.stm 文件。要創建新的 Pub1.edb，請裝入公用文件夾數據庫。單擊“確定”創建新的 Pub1.edb。將文件夾從客戶端移回服務器上的新公用文件夾結構。

    接下來重新啟動信息存儲。

    （注意：必須恢復公用存儲上的所有權限。在能夠訪問電子郵件和公用文件夾后，應盡快執行備份并驗證備份是否成功。此過程還將刪除到此時間點為止收到的郵件的單一實例存儲。結果，Exchange 2000 數據庫可能會增長，并需要更多的磁盤空間。）

 

 

[3] 使用一致性調整程序

    Exchange 2000 中，Mbconn.exe 實用工具提供了相同的功能。有關更多信息，請參閱“Mailbox Reconnect Help”（郵箱重新連接幫助）文件 (Mbconn.chm)，該文件位于<CD 驅動器>ExchSrvrServerSupportUtilsi386 文件夾中。您可以與 /G 開關一起使用 Eseutil 來驗證信息存儲的完整性。

[4] 使用Exchange 2000目錄服務完整性檢查程序(E2kdsinteg)

    E2kdsinteg 實用工具最初包括在Exchange 2000 SP2中。在安裝并運行 Exchange 2000或Exchange 2000 Active Directory連接器(ADC)后，此實用工具將報告Active Directory的運行狀態。E2kdsinteg實用工具以文本文件的格式生成簡單的報告，該報告記錄異常或可疑的對象。E2kdsinteg不會更改Active Directory 中的任何對象。根據Active Directory中支持郵件的對象和配置對象的數量，處理支持郵件的對象可能需要相當長的時間。

    我們的例子中，由于Active Directory中的Exchange Server信息沒有損壞，所以略過這一步。

3、修復IIS和OWA

[1] 修復DCOM錯誤

    用戶的要求總是千奇百怪的。幸運的是Exchange Server給我們提供了多種多樣的郵件訪問方式。

    我們可以使用Exchange客戶端，也可以使用Office里面的Outlook通過RPC連接來收發郵件；可以使用諸如Outlook Express之類的郵件客戶端通過POP3/SMTP/IMAP協議收發郵件；還可以干脆就使用任何支持SSL的Web客戶端比如Internet Explorer通過OWA來收發郵件。

    在這個例子里，我們應用了OWA來為不能使用Outlook客戶端或者POP3/SMTP客戶端的客戶服務。我們重新安裝了OWA，但是它不能正常工作：根本就不能打開任何非靜態的頁面。經查，每次我們要求訪問需要執行腳本的目錄，就會在系統日志中留下如下日志：

 

 

 

    這可能有兩種原因：

(a) 組件服務

    COM+賬號信息存儲在IIS metabase中，由Active Directory來同步，但是COM+不會自動更新。Windows 2000組件服務和Internet Information Services (IIS) 進程不同步的話，IWAM_<machine>賬號和IIS metabase就不同步而出現上述日志。

    IIS提供synciwam.vbs腳本來同步IWAM_<machine> 賬號和IIS metabase。該腳本位于InetpubAdminScripts下面。可以使用Cscript或Wscript來運行該腳本。

    使用Cscript運行Synciwam.vbs:

    可以看到該腳本成功執行。

    使用Wscript運行Synciwam.vbs:

    可以看到圖形的界面下該腳本成功執行。

(b) 賬號的密碼

    IWAM_<machine>是IIS用于執行腳本的賬號，雖然我們從來沒有為它設過密碼，但是它的確使用了密碼。雖然這個賬號是本地的，但是卻會保存在Active Directory中。如果存儲在Active Directory中的密碼與IIS metabase中的不一致，該賬號將無法啟動IIS的腳本進程。我們遇到的就是這種情況了。

    可以使用adsutil腳本來修復該問題。

    這里的name通常就是服務器的機器名。

    打開組件服務的MMC控制臺，展開“Component Services”文件夾，展開“My Computer”文件夾，找到“COM+ Applications”文件夾，右鍵單擊，選擇“IIS Out-of-Process Applications”，確認“Advanced”頁面里的“Disable changes”選擇框被清除，這可以確保IWAM_<Computer>賬號的改動會保存在Active Directory里。

    如果IIS運行于域控制器，打開“Active Directory用戶和計算機的MMC管理控制臺snap-in。如果IIS運行于成員服務器，則右鍵單擊“我的電腦”，選擇“管理”，展開“系統工具”，展開“本地用戶和組”，選擇“用戶”文件夾。

    在右邊找到我們剛才通過adsutil腳本查詢到的IWAM賬號名，更改該賬號的密碼。然后通過腳本來修改IIS metabase里的IWAM賬號密碼：

    可以看到提示修改成功，接著通過剛才的管理控制臺，找到“服務”，停止、然后啟動“IIS Admin”服務。也可以使用命令行：

[2] 證書服務

    使用OWA的更改密碼功能時，由于密碼使用明文傳送，非常危險。為了保證賬號的安全，我們必須為該功能啟用SSL（安全套接字層）加密。為了實現SSL，需要使用證書來驗證IIS服務。

    前面我們安裝了證書服務，為的就是給IIS和域內賬號提供證書。如果您有商業公司發布的證書（如VeriSign等），當然也可以直接使用他們的。為該IIS服務生成一張服務器證書，并導出。將其安裝至“受信任的企業根證書”，這樣該證書可以被與用戶信任。

    打開“Internet 信息服務”的管理控制臺Snap-in，右鍵單擊“默認Web站點”（這里我們假設IIS上面只有一個站點并且該站點準備用來使用OWA，如果情況不同，請自行修改），在“默認站點屬性”中選擇“目錄安全性”，在其下方的“安全通信”中單擊“服務器證書”，使用其向導安裝我們剛才導出的服務器證書。

    為了通過OWA可以修改用戶的密碼，需要在默認站點下，建立“IISADMPWD”的虛擬文件夾。該目錄只允許讀取。“應用程序設置”那里的“應用程序名”填入IISADMPWD，執行許可為純腳本。

    打開Internet Explorer，輸入“http://<ExchangeServerAddress>/exchange”，看看是否可以正常OWA。

 

4、修復網絡服務

    在前面我們已將在另外的服務器上安裝了WINS，現在可以在新安裝的服務器上安裝WINS來實現“推/拉”復制。也可以安裝DNS實現區域復制。而DHCP，我們可以將區域的地址范圍劃分為原有區域剩下的80%（吻合前面的20%，當然可以根據需要改變）。

    這樣，WINS/DNS/DHCP可以繼續提供服務了。

    接下來，按照原有的共享內容，提供打印機和文件共享的服務。不要忘記補丁和防病毒程序！剩下的該裝的軟件比如備份、UPS之類我就不再廢話了。

三、Mission, accomplished.

    總算完工了，向用戶們確認一下所有的服務是否都正常吧。在得到他們的感謝的同時，不要忘記做一次系統的完整備份！

    最后啰嗦一句，所有的知識和信息，都可以在KB中找到。如果可能的話，平時我們可以收集一些災難恢復的資料準備，在不影響業務的前提下，我們可以進行假想的演習。養兵終須千日，才能用在一時。