修復企業AD與Exchange故障

故障現象

某企業使用Exchange Server 2010作為郵件系統，根據集團下發文件，在服務器上安裝了某廠商的“防勒索病毒補丁”后，導致Exchange出現問題，所有用戶不能登錄郵箱。后來卸載了補丁，將Exchange退出域、又重新加入到域，Exchange恢復正常。

一 周 后，大多數員工的Outlook不能登錄Exchange，但 OWA（在瀏覽器中通過Web頁面登錄Exchange）與手機客戶端正常，只有極少數員工的Outlook能登錄Exchange。對于不能登錄Exchange的無論是重新安裝操作系統還是重新配置Outlook，都會出現圖1錯誤。

故障排查

經過檢查，故障現象總結如下：

圖1 不能登錄Exchange

圖2 網絡拓撲圖

1.Exchange Server 2010對外收發郵件正常。

2.員工使用手機客戶端、使用OWA（Web頁面）登錄Exchange郵件系統正常。

3.只有Outlook登錄Exchange時出錯，錯誤如圖1所示。如果修改Outlook使用 POP3、SMTP方式，也可以登錄Exchange。

該單位有1臺Exchange Server 2010，2 臺 Active Directory的服務器。其中 AD1、AD2、Exchange Server都 是Windows Server 2008 R2操作系統。網絡拓撲如圖2所示。

經過進一步檢查，發現AD2（192.168.0.249）與Exchange（192.168.0.221）的 TCP的135端口不能登錄（測試方法telet 192.168.0.221 135時出錯）。但在Exchange上檢查，服務器的135端口已經開放。

解決方法與思路

因 為 AD1（192.168.0.249）的 AD 與 Exchange（192.168.0.221）都出現TCP 135不能登錄的故障，并且故障原因也是在“勒索病毒”打補丁之后出現（192.168.0.223沒有安裝補丁，故一切正常）。所以解決故障的方法也就在修復TCP的135端口上。

在正式修復之前，我們做了如下的準備與測試工作：

1.將 DC（192.168.0.223）的設置為主域，轉移角色到223。此時249將成為額外域控制器。

2.因為192.168.0.249上有證書服務器，所以備份該服務器的根證書私鑰及數據庫。

3.通過升級安裝的方式（登錄進入Windows，使用同操作系統、同版本的安裝鏡像，執行Setup，執行升級安裝），升級 192.168.0.249。

4.升級安裝192.168.0.249，升級之后，TCP的135端口能用。

因為通過升級192.168.0.249之 后，TCP的 135端口能用，故準備通過升級Exchange修復135端口。

為驗證方法是否正確，我們進行了如下的前期測試：

圖3 Exchange初始化失敗

1.使用“愛數”備份設備，備份Exchange的操作系統及數據庫。

2.使用一臺空閑的服務器搭建出虛擬化環境，新建AD1與MBX兩臺虛擬機，從愛數備份設備，將AD1與MBX備份恢復到虛擬機，故障再現。

3.在MBX的虛擬機中升級 Exchange，郵 箱、Outlook正常，但Exchange控制臺不能打開，錯誤提示為“嘗試連接到指定的Exchange服務器***時出現以下錯誤：嘗試使用"Kerberos"身份驗證連接到 http://***/PowerShell失?。哼B接到遠程服務器失敗，錯誤消息如下：WinRM 無法處理該請求。使用 Kerberos 身份驗證時發生以下錯誤：找不到網絡路徑?！保ㄈ鐖D 3）。

4.經過分析，打開服務器管理器，添加“WINRAM IIS擴展”組件，安裝該組件后正常。之后可以打開Exchange管理控制臺。

在實驗成功之后，我們準備修復生產環境中的Exchange，并提前在集團OA發布了此項維護通知。

本著數據第一、安全第一的原則，在修復前使用對Exchange進行備份，備份完成后再對系統進行修復，這樣一旦出現問題，可以通過備份恢復。因為數據量較大，整個備份大約花了28個小時。

升級修復不成功但找到故障原因

在周六正式對Exchange進行升級安裝，升級花費了大約2個小時，但升級之后，故障依舊。

因為當前操作系統是Windows Server 2008 R2，而做實驗的虛擬環境的操作系統是Windows Server 2008 R2 SP1的版本，我們將當前的操作系統升級到Windows Server 2008 R2 SP1，打補丁之后，故障依舊。

經過進一步對物理服務器中的操作系統進行檢查，發現telnet 127.0.0.1 135可用，但telnet 192.168.0.221 135不可用。我們分析認為Exchange各項服務、操作系統相關服務都正常，但是由于某項策略導致192.168.0.221的135不可用。

在檢查到“本地安全策略”時，在“IP安全策略，在本地計算機”中有一個“Block”的策略。

1.查看該策略，在“篩選器操作→編輯”中，打開屬性，查看“安全方法”為“阻止”。

2.在“身份驗證方法”選項卡中，看到驗證方法包括了Kerberos。之后再telnet 192.168.0.221 135，發現已經正常。

此時我們使用Outlook登錄Exchange，發現登錄正常，并收到了外網發來的郵件。

發現新問題并解決

在我們認為故障解決的時候，經過測試發現，Exchange能收郵件、不能發郵件（無論是向外發郵件還是內部發郵件，都不行），郵件都保存在“草稿箱”內。

經過分析，我們認為原因如下：

Exchange某項服務沒有啟動導致此事情發生。但經過檢查，發現Exchange的所有服務都啟動正常。

繼續分析認為可能是安裝了Windows Server 2008 R2 SP1引發的，之后卸載Windows Server 2008 R2 SP1補丁。在卸載補丁后，故障依舊。

之后繼續卸載“WinRM IIS擴展”，卸載之后，系統并未提示需要重新啟動。為了可靠，我們重新啟動Exchange。在Exchange重新啟動的過程中，停留在“發件箱”中的郵件發送成功。但再次進入系統后，故障依舊。

此時我們再次逐一檢查Exchange相關服務，雖然檢查到每項服務的狀態為“己啟動”，但在重新啟動“Microsoft Exchange郵 件提交”服務之后，Exchange發信恢復正常。

此時已經是下午16：50多。在經過多次測試之后，確認Exchange恢復正常。

之后安裝了“WinRM IIS擴展”，Exchange管理正常。

繼續測試，Exchange的OWA、Outlook正常，收發正常，至此故障解決。

編寫腳本

為了防止以后Exchange登錄后，不能發送郵件，我們配置Exchange，讓Exchange在重新啟動后自動以Administrator賬戶登錄進入系統，并且執行腳本重新啟 動“Microsoft Exchange郵件提交”服務。

運 行regedit， 打 開“HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon”鍵值，新建“字符串值”，前面為鍵值，后面為內容。具體項如下。

"AutoAdminLogon"="1"

"DefaultUserName"="Ad ministrator"

"DefaultDomainName"="單位域名"

"DefaultPassword"="管理員密碼"

用“記事本”創建startexchange.cmd，內容如下：

net stop MSExchangeFBA

net start MSExchangeFBA

net stop MSExchange MailSubmission

net start MSExchange MailSubmission

將其添加到“啟動”菜單，或者編輯計劃內容，選擇“登錄后只執行一次”。

經過這些配置，Exchange修復完成。