郵件服務器問題之郵件積壓、傳遞延遲解決

2009-09-02 17:36:12

郵件服務器出現了郵件積壓、傳遞延遲問題的時候會非常令人頭疼，這個時候我們可以用如下的解決方法來處理。

癥狀描述：
郵件服務器A和郵件服務器B，作前后端設置，前端接收郵件后，投遞給后端服務器內的郵箱，當前前端接收外部郵件后，無法投遞給后端郵箱，導致郵件積壓在前端服務器，內部郵件傳遞需要延遲25分鐘左右到達。

通過察看前后端服務器的各類服務，發現所有服務均正常，由于無法投遞給后端服務器，所以首先判斷可能是后端服務器出現了問題，決定重啟動。

重啟動耗時4分鐘，這時候察看前端隊列，發現已經正常投遞給后端服務器，認為問題解決，可能是意外原因導致后端服務器服務不正常。

但是經過5分鐘的觀察，發現，問題仍然存在，外部投遞郵件仍然積壓在前端服務器上，于是又深層次查找問題，發現如下癥狀
在Message Submitted to Advanced Queuing 和 Started Message Submission to Advanced Queue兩步用時超過10分鐘，在Message Submitted to Categorizer 和Message Categorized and Queued for Routing 之間歷時接近10分鐘，根據這個線索，查找資料，得到如下類似癥狀

http://www.microsoft.com/technet/prodtechnol/exchange/ZH-CN/Guides/E2k3TransnRouting/18682a71-ba92-42ec-9a54-8514d607c522.mspx?mfr=true

由于全局編錄服務器問題而導致郵件傳遞出現延遲
全局編錄問題可能導致郵件傳遞出現延遲。在這種情況下，會生成 NDR 以通知發件人這一延遲。可以使用郵件跟蹤中心來診斷這些問題。下面的示例顯示了從郵件跟蹤中心所收集到的數據：
6/22/2001 3:54 PM Tracked message history on server CONTOSO-MSG-01
6/22/2001 3:54 PM SMTP Store Driver: Message Submitted from Store
6/22/2001 3:54 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 3:54 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 3:54 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP
6/22/2001 4:24 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 4:24 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 4:24 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP
6/22/2001 4:24 PM SMTP Store Driver: Message Delivered Locally to Store
在上面的示例中，應注意到郵件在郵件分類程序中延遲了 30 分鐘，之后才開始進行出站傳輸，并且最終被送達。在這些情況下，應通過運行 Nltest 工具來確定 Exchange 使用哪一臺全局編錄服務器。具體步驟在本主題前面的“通過使用移動郵箱工具將收件人移到 Active Directory”中已說明。然后，調查所涉及到的全局編錄服務器。下面是全局編錄服務器的常見問題：
• 全局編錄服務器超載或工作過度。
• 全局編錄服務器出現性能問題。
• 內存不足。
• 硬盤空間不足。
• Exchange 2000 與全局編錄服務器之間出現暫時性的網絡問題。
• 使用同一個全局編錄服務器的 Exchange 服務器過多（推薦的 Exchange 處理器與全局編錄服務器處理器的比率是四比一）。

要點：
郵件跟蹤日志可能會起到一種誤導作用。例如，如果全局編錄服務器正常工作，并且郵件分類程序也正常工作，但是遠程 SMTP 服務器不可用達三十分鐘，則郵件跟蹤日志可能與上面顯示的示例日志類似。此外，如果郵件必須在本地傳遞，并且 Exchange 存儲執行速度很慢，則郵件跟蹤日志將顯示出“郵件已提交到郵件分類程序”與“郵件已傳遞到本地存儲”之間存在很大的時間差異。
重現問題時，應從全局編錄服務器中使用系統監視器日志。這有助于您診斷這些問題。再次使用全局編錄服務器可以解決這些問題。要解決這些問題，可以為每一臺 Exchange 服務器指定一臺全局編錄服務器。
注意：
建議只有在要排除故障時才手動配置全局編錄服務器。手動配置了全局編錄服務器后，如果某個服務器不可用，Exchange 將無法檢測到。
有關詳細信息，請參閱如何指定全局編錄服務器。
有關 DSAccess 的其他信息，請參閱 Microsoft 知識庫中編號為 250570 的文章：“XCON: Directory Service Server Detection and DSAccess Usage”。
ExchOwningPFTreeBL: CN=Public Information Store (PFREP55),CN=First Storage Group,CN=InformationStore,CN=PFREP55,CN=Servers,CN=FourthCoffee,CN=Administrative Groups,CN=Lake District,CN=Microsoft Exchange,CN=Services,CN=Configuration, DC= cumbria,DC=extest,DC=microsoft, DC=com;
CN=Public Folder Store (PFREP57),CN=First Storage Group,CN=InformationStore, CN=PFREP57,CN=Servers,CN=Coniston,CN=Administrative Groups,CN=Lake District,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;
CN=Public Information Store (PFREP56),CN=First Storage Group,CN=InformationStore,CN=PFREP56,CN=Servers,CN=Coniston,CN=Administrative Groups,CN=Lake District,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;

紫色字部分癥狀與我們的癥狀是一樣的，所以，根據此結果，我們查詢了兩臺郵件服務器獲取賬戶的GC，通過命令
NLTEST /DSGETDC:suzsoft.com /GC
得到如下信息：
NLTEST /DSGETDC:suzsoft.com /GC
           DC: \\w2kdc1.suzsoft.com
      Address: \\10.0.15.11
     Dom Guid: f4938c04-de3e-4db1-bbd6-b8a65eaeb77e
     Dom Name: suzsoft.com
Forest Name: suzsoft.com
Dc Site Name: Default
Our Site Name: Default
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN
DNS_FOREST CLOSE_SITE
The command completed successfully

NLTEST /DSGETDC:suzsoft.com /GC
           DC: \\w2kdc2.suzsoft.com
      Address: \\10.0.15.12
     Dom Guid: f4938c04-de3e-4db1-tt58-b8a666dwb07e
     Dom Name: suzsoft.com
Forest Name: suzsoft.com
Dc Site Name: Default
Our Site Name: Default
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN
DNS_FOREST CLOSE_SITE
The command completed successfully

可以看出，兩臺服務器引用的GC是不同的，由于以前沒有出現該問題，那么我們猜測，是否由于兩臺GC同步上出了問題，導致GC數據不同步，郵件服務器引用數據無法匹配，導致郵件無法傳遞，因此，我們做了如下操作：

修正郵件服務器的缺省引用GC，保證兩郵件服務器引用同一臺GC的數據，重啟動生效后，問題解決。

總結：

由于EXCHANGE 服務器與域結合非常緊密，所以，當郵件服務器出現問題后，有可能是域控制器的問題導致。

附一：如何指定全局編錄服務器

http://www.microsoft.com/technet/prodtechnol/exchange/ZH-CN/Guides/E2k3TransnRouting/411e8bfd-6291-4bd0-bfd5-dad94220062e.mspx?mfr=true

全局編錄問題可能導致郵件傳遞出現延遲。在這種情況下，會生成 NDR 以通知發件人這一延遲。可以使用郵件跟蹤中心來診斷這些問題。
下面是全局編錄服務器的常見問題：
• 全局編錄服務器超載或工作過度。
• 全局編錄服務器出現性能問題。
• 內存不足。
• 硬盤空間不足。
• Exchange 2000 Server 與全局編錄服務器之間出現暫時性的網絡問題。
• 使用同一個全局編錄服務器的 Exchange 服務器過多（推薦的 Exchange 處理器與全局編錄服務器處理器的比率是四比一）。

步驟
指定全局編錄服務器
1. 在 Exchange 系統管理器中，展開“服務器”，用鼠標右鍵單擊您的 Exchange 服務器，再單擊“屬性”。
2. 單擊“目錄訪問”選項卡。
3. 在“顯示”中，選擇“全局編錄服務器”。
4. 清除“自動探查服務器”復選框。
“目錄訪問”選項卡
5. 單擊“添加”，再選擇要排除其故障的全局編錄服務器。所選定的用作域的全局編錄服務器的服務器必須存在于 Active Directory 中、必須可以通過 LDAP 端口 3268 訪問到、必須實時地處理 Exchange 服務器的請求，并且必須具有收件人對象的全部已啟用郵件屬性。

下面的示例顯示了從郵件跟蹤中心所收集到的數據：
6/22/2001 3:54 PM Tracked message history on server CONTOSO-MSG-01
6/22/2001 3:54 PM SMTP Store Driver: Message Submitted from Store
6/22/2001 3:54 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 3:54 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 3:54 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP
6/22/2001 4:24 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 4:24 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 4:24 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP
6/22/2001 4:24 PM SMTP Store Driver: Message Delivered Locally to Store
在上面的示例中，應注意到郵件在郵件分類程序中延遲了 30 分鐘，之后才開始進行出站傳輸，并且最終被送達。在這些情況下，應通過運行 Nltest 工具來確定 Exchange 使用哪一臺全局編錄服務器。具體步驟在產生未送達報告的常見情形中的“通過使用移動郵箱工具將收件人移到 Active Directory”部分已說明。然后，調查所涉及到的全局編錄服務器。
有關 DSAccess 的其他信息，請參閱 Microsoft 知識庫中編號為 250570 的文章：“XCON: Directory Service Server Detection and DSAccess Usage”（英文）。

該文章轉載自宋氏電腦技術無憂：http://www.pc51.net/server/mail/2007-05-30/8186.html

責任編輯：桑丘來源： www.pc51.net

郵件服務器