未傳遞報告的常見案例

上次修改主題的時間： 2005-05-24

本主題涵蓋下列產生 NDR 的常見案例：

• Active Directory 問題。
• 因通用類別目錄伺服器問題而延遲郵件傳遞。
• 將郵件傳送給個人通訊錄或連絡人清單中的收件者。
• 將郵件傳送至公用資料夾。

Active Directory 問題

Active Directory 問題可能會產生未傳遞報告。下列類別的 NDR 與 Active Directory 問題有關：

• 使用 Active Directory 連接器 (ADC)，將收件者移動至 Active Directory。
• 使用移動信箱工具，將收件者移動至 Active Directory。
• 屬性遺失。

使用 Active Directory 連接器，將收件者移動至 Active Directory

如果您的部份使用者發生 NDR，且您已使用 Active Directory 連接器移動收件者，請判斷下列項目：

• 產生 NDR 的收件者類型 (例如，信箱、通訊群組或連絡人)。
• 將收件者移動至 Active Directory 的方式。如果已使用 ADC 將收件者複寫至 Active Directory，則請使用 ADCDump 工具取得 ADC 傾印檔案，然後針對發生問題的收件者，比較這兩個目錄中的屬性。ADC 傾印檔案會顯示 Exchange 2003 物件與 Exchange Server 5.5 物件間的遺失屬性。若要取得 ADCDump 工具，請連絡 Microsoft 產品支援服務。

如果是使用 ADC 移動使用者，則這些使用者必須存在於 Active Directory 中，並且至少需為停用的使用者。若將使用者當成連絡人 (自訂收件者) 從 Exchange 5.5 目錄複寫至 Active Director，也會導致 NDR。如果將 Exchange 5.5 及 Microsoft Windows NT® Server 4.0 版收件者當成連絡人複寫至 Active Directory，Exchange 2003 就不會再將電子郵件傳送給 Active Directory 中表示為連絡人的 Windows NT Server 4.0 收件者。在此案例中，會傳回下列 NDR：

A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator. <servername.contoso.com #5.4.6>

如需其他資訊，請參閱 Microsoft 知識庫文件 - 272593＜XCON: Message Generates NDR When Sent to a Windows NT Server 4.0 Recipient Represented as Contact in Active Directory＞(英文)。雖然此文件是針對 Exchange 2000 撰寫的，但相同原則也可套用至 Exchange 2003。

在 Exchange 2003 中所建立的連絡人不會發生此狀況；只有透過 ADC 並作為連絡人複寫至 Active Directory 的 Windows NT Server 4.0 使用者，才會發生這種狀況。但是郵件仍可傳送至原始的 Exchange 2003 連絡人，而不會發生任何問題。

附註：
如果 Active Directory 中未顯示停用的使用者，並且您收到 8277 MSADC 錯誤訊息，請將連線協定的複寫伺服器變更為想要複寫之目標 Exchange 2003 站台或網域中的 Bridgehead 伺服器。此外，若要取得 Exchange 2003 伺服器與 Exchange 5.5 電腦間的完整交互操作性，請確定 ADC 複寫是設定為雙向。

使用移動信箱工具，將收件者移動至 Active Directory

如果收件者、通訊群組或使用者是原始 Exchange 2003 物件，或是使用移動信箱工具從 Exchange 5.5 中移動的，請確定所有擁有郵件功能的屬性都存在。下列步驟將可協助您確認：

• 判斷寄件者實際所在的 Exchange 伺服器。如果收件者是通訊群組，請尋找通訊群組擴充伺服器。
• 判斷寄件者的 Exchange 伺服器或通訊群組擴充伺服器會進行連絡，以供名稱解析的通用類別目錄伺服器使用。(如需詳細步驟，請參閱本節稍後的程序。)
• 執行 Nltest 工具 (可在 Windows 2000 及 Windows Server 2003 上取得)，判斷寄件者之伺服器或通訊群組擴充伺服器正在連絡的通用類別目錄伺服器。確定是從寄件者的 Exchange 伺服器中或通訊群組擴充伺服器中執行 Nltest。如果通訊群組擴充伺服器是設定為組織中的任何伺服器，則請從傳送伺服器中執行 Nltest。

如需詳細指示，請參閱＜如何判定通訊群組的擴充伺服器＞。

當您知道正在使用的通用類別目錄後，請取得收件者使用者通訊群組的傾印檔案。如需如何取得傾印檔案的其他資訊，請參閱下列 Microsoft 知識庫文件：

• 255253,"XADM: How to Perform a Dump of a Container or Object in Exchange 2000" (英文)
• 271201,"XADM: Alternative Methods to Obtain a Dump of an Object" (英文)

您也可使用 LDP 工具，取得收件者物件的 LDP 傾印檔案。使用 LDP 工具時，請確定連線至通用類別目錄伺服器時所使用的連接埠為 3268。郵件分類程式會使用此連接埠來查詢通用類別目錄伺服器，以進行名稱解析。

附註：
如果 LDP 工具會截斷結果，則您可從 NDR 中取得物件的基本辨別名稱 (需要有此名稱才可使用知識庫文件 271201 中所討論的程序)。每個 NDR 都含有無法傳遞之物件的基本辨別名稱資訊。如果無法確定 NDR 的格式或收件者物件的基本辨別名稱資訊，您可以傳送索取送達回條的新測試郵件。請從可順利傳送給發生問題之收件者的使用者處，將此測試郵件傳送給該收件者。

屬性遺失

遺失物件屬性的原因有很多，其範圍可從手動刪除屬性到通用類別目錄同步處理問題。然而，如果遺失任何屬性，則最常見的原因是收件者更新服務未正確寫入這些屬性，或發生 ADC 複寫問題。

如需詳細資訊，請參閱＜如何更正遺失的屬性問題＞。

因通用類別目錄伺服器問題而延遲郵件傳遞

通用類別目錄問題可能會造成郵件傳遞的延遲。在此情況下，會產生 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 伺服器有 30 分鐘的時間是無法使用的，則郵件追蹤記錄檔看起來就會與上例所示的範例類似。此外，如果必須在本機上傳遞郵件，且 Exchange 儲存區的執行速度很慢，則郵件追蹤記錄檔會在「已提交給郵件分類程式的郵件」與「將郵件本機傳遞到儲存區」之間顯示一大段的時間空檔。

重現問題時，請使用通用類別目錄伺服器的系統監視器記錄檔。它可協助您診斷這些問題。而回收通用類別目錄伺服器可能可解決這些問題。若要疑難排解這些問題，您可為每部 Exchange 伺服器都指定一部通用類別目錄伺服器。

附註：
手動設定通用類別目錄伺服器是唯一建議的疑難排解方法。手動設定通用類別目錄伺服器時，Exchange 無法偵測伺服器是否變成無法使用。

如需詳細資訊，請參閱＜如何指定通用類別目錄伺服器＞。

如需 DSAccess 的相關資訊，請參閱 Microsoft 知識庫文件 - 250570＜XCON: Directory Service Server Detection and DSAccess Usage＞(英文)。

傳送至個人通訊錄及連絡人清單時發生未傳遞報告

如果使用 Exchange 2003 移動信箱工具從 Exchange Server 5.5 電腦中移動使用者，且所移動的信箱具有 Exchange 5.5 信箱中的個人通訊錄或連絡人清單，則在 Exchange 2003 信箱上，此個人通訊錄及連絡人清單會變成無效。任何針對個人通訊錄或連絡人清單解析的地址都會產生與下列類似的 NDR：

Your message did not reach some or all of the intended recipients.

Subject: Test

Sent: 8/3/2000 5:24 PM

The following recipient(s) could not be reached:

CN=\ Network,OU=United States,OU=Distribution Lists,DC=Contoso,DC=com on 8/3/2000 5:24 PM

The e-mail address could not be found. Perhaps the recipient moved to a different e-mail organization, or there was a mistake in the address. Check the address and try again.

<CONTOSO-MSG-01.Contoso.com #5.1.0>

因為移動信箱工具不會移動個人通訊錄及連絡人清單，所以個人通訊錄及連絡人清單中的所有地址資訊都會變成無效。

若要解決這個問題，請確定在 Outlook 用戶端上，已將全域通訊清單選取為此通訊錄的來源。理想上，已從 Exchange 5.5 伺服器移動的使用者應該會刪除其個人通訊錄及連絡人清單，然後再重新建立它們。

將郵件傳送至公用資料夾

在 Exchange 中將電子郵件傳送至公用資料夾，會比將電子郵件傳送至信箱還複雜。一個信箱只可存在於一部伺服器上，因此也只會屬於特定信箱儲存區。而信箱的 Active Directory 屬性會指向特定伺服器。因此，在解析項目後，Exchange 可使用路由來判斷要傳遞郵件的目標郵件儲存區。

Active Directory 中的公用資料夾沒有主伺服器。如此公用資料夾便可存在於多部伺服器上，且在 Active Directory 中不會保留任何可指出保留此資料夾複本之伺服器的資訊。Exchange 儲存區會處理此資訊。

Exchange 將郵件傳遞給公用資料夾時，它所執行的第一個工作是將郵件傳遞至 Exchange 儲存區，而此儲存區是指向公用資料夾複本的位置。Exchange 儲存區會查閱 ptagReplicaList 項目 (這個項目可列出具有此資料夾複本的 Exchange 伺服器)，然後將重設地址的郵件重新提交給保留此資料夾複本的 Exchange 儲存區。

分類程式會負責正確地解析郵件的地址。而在公用資料夾的情況下，它也負責：

• 判斷該資料夾所屬的頂層階層。
• 正確地設定郵件的地址，以提交給該頂層階層中的儲存區。
• 在取得複本清單後，將郵件的地址重寫為保留該公用資料夾複本的儲存區。

將電子郵件傳送至公用資料夾時，分類程式會執行下列步驟以傳遞郵件：

1. 首次公用資料夾查閱
2. 頂層階層伺服器查閱

首次公用資料夾查閱

提交電子郵件時，Exchange 會將地址解析為 Active Directory 中的項目。如果該項目是公用資料夾，而非信箱，則分類程式會嘗試取得公用資料夾的 homeMDB 屬性：

homeMDB: CN=Public Folders,CN=Folder Hierarchies,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=MicrosoftExchange,CN=Services,CN=Configuration,DC=contoso-msg-01,DC=contoso,DC=com;

資料夾的 homeMDB 屬性會含有該資料夾所屬之頂層階層的辨別名稱。

頂層階層伺服器查閱

接下來，分類程式會查閱從資料夾之 homeMDB 屬性中所擷取的頂層階層，以取得該資料夾之頂層階層中的所有伺服器清單。雖然分類程式無法判斷複本的位置，但是它可將郵件提交至不含位置資訊的 Exchange 儲存區。而頂層階層辨別名稱會含有該頂層階層中所有伺服器的連結。

為了判斷分類程式要從頂層階層中挑選哪個公用資料夾儲存區或伺服器，Exchange 會使用下列準則：

• 其中一個公用資料夾儲存區存在於本機伺服器上嗎？如果是，則 Exchange 會使用該儲存區。
• 其中一個公用資料夾儲存區存在於本機路由群組的 Exchange 伺服器上嗎？如果是，則 Exchange 會使用該儲存區。
• 其中一個公用資料夾儲存區存在於任一 Exchange 伺服器上嗎？如果是，則 Exchange 會使用該儲存區。否則，Exchange 會使用清單中的第一個儲存區。

清單中的第一個伺服器是包含在 msExchOwningPFTreeBL 屬性中。此屬性位於資料夾階層下的公用資料夾樹狀目錄中。然後，分類程式會從 msExchOwningPFTreeBL 屬性中選擇它要傳送郵件的目標伺服器。

下列範例會顯示 msExchOwningPFTreeBL 屬性的內容 (與從 LDP 輸出中取得的一樣)：

msExchOwningPFTreeBL: 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;