症狀描述：
郵件服務器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 處理器與全局編錄服務器處理器的比率是四比一）。
要點：
郵件跟蹤日志可能會起到一種誤導作用。例如，如果全局編錄服務器正常工作，並且郵件分類程序也正常工作，但是遠程 SMTP 服務器不可用達三十分鐘，則郵件跟蹤日志可能與上面顯示的示例日志類似。此外，如果郵件必須在本地傳遞，並且 Exchange 存儲執行速度很慢，則郵件跟蹤日志將顯示出“郵件已提交到郵件分類程序”與“郵件已傳遞到本地存儲”之間存在很大的時間差異。
重現問題時，應從全局編錄服務器中使用系統監視器日志。這有助於您診斷這些問題。再次使用全局編錄服務器可以解決這些問題。要解決這些問題，可以對每一台 Exchange 服務器指定一台全局編錄服務器。
注意：
建議只有在要排除故障時才手動配置全局編錄服務器。手動配置了全局編錄服務器後，如果某個服務器不可用，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”（英文）。
