故障現(xiàn)象

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

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

故障排查

經(jīng)過檢查，故障現(xiàn)象總結(jié)如下：

圖1 不能登錄Exchange

圖2 網(wǎng)絡(luò)拓撲圖

1.Exchange Server 2010對外收發(fā)郵件正常。

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

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

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

經(jīng)過進一步檢查，發(fā)現(xiàn)AD2（192.168.0.249）與Exchange（192.168.0.221）的 TCP的135端口不能登錄（測試方法telet 192.168.0.221 135時出錯）。但在Exchange上檢查，服務(wù)器的135端口已經(jīng)開放。

解決方法與思路

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

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

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

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

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

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

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

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

圖3 Exchange初始化失敗

1.使用“愛數(shù)”備份設(shè)備，備份Exchange的操作系統(tǒng)及數(shù)據(jù)庫。

2.使用一臺空閑的服務(wù)器搭建出虛擬化環(huán)境，新建AD1與MBX兩臺虛擬機，從愛數(shù)備份設(shè)備，將AD1與MBX備份恢復到虛擬機，故障再現(xiàn)。

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

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

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

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

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

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

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

經(jīng)過進一步對物理服務(wù)器中的操作系統(tǒng)進行檢查，發(fā)現(xiàn)telnet 127.0.0.1 135可用，但telnet 192.168.0.221 135不可用。我們分析認為Exchange各項服務(wù)、操作系統(tǒng)相關(guān)服務(wù)都正常，但是由于某項策略導致192.168.0.221的135不可用。

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

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

2.在“身份驗證方法”選項卡中，看到驗證方法包括了Kerberos。之后再telnet 192.168.0.221 135，發(fā)現(xiàn)已經(jīng)正常。

此時我們使用Outlook登錄Exchange，發(fā)現(xiàn)登錄正常，并收到了外網(wǎng)發(fā)來的郵件。

發(fā)現(xiàn)新問題并解決

在我們認為故障解決的時候，經(jīng)過測試發(fā)現(xiàn)，Exchange能收郵件、不能發(fā)郵件（無論是向外發(fā)郵件還是內(nèi)部發(fā)郵件，都不行），郵件都保存在“草稿箱”內(nèi)。

經(jīng)過分析，我們認為原因如下：

Exchange某項服務(wù)沒有啟動導致此事情發(fā)生。但經(jīng)過檢查，發(fā)現(xiàn)Exchange的所有服務(wù)都啟動正常。

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

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

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

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

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

繼續(xù)測試，Exchange的OWA、Outlook正常，收發(fā)正常，至此故障解決。

編寫腳本

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

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

"AutoAdminLogon"="1"

"DefaultUserName"="Ad ministrator"

"DefaultDomainName"="單位域名"

"DefaultPassword"="管理員密碼"

用“記事本”創(chuàng)建startexchange.cmd，內(nèi)容如下：

net stop MSExchangeFBA

net start MSExchangeFBA

net stop MSExchange MailSubmission

net start MSExchange MailSubmission

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

經(jīng)過這些配置，Exchange修復完成。