公用資料夾複寫疑難排解 - 第 4 部分：Exchange Server 2007/2010 秘訣
英文原文已於 2011 年 11 月 28 日星期一發佈
英文原文張貼於美國部落格：2008 年 1 月 11 日
我兩年前發表過分成三部分的一系列文章，討論公用資料夾複寫的疑難排解。第 1 部分 (可能為英文網頁)討論新資料的複寫，第 2 部分 (可能為英文網頁)討論現有資料的複寫，而第 3 部分 (可能為英文網頁)討論複本刪除程序以及一些我們看到的 Exchange 2003 常見問題。在本文中，我想要針對 Exchange 2007 更新該系列。
在 Exchange 2007 中，公用資料夾複寫的運作方式基本上和以往一樣。本系列前三部分中的疑難排解步驟仍然適用。但系統管理工具有所變更，而我們看到的 Exchange 2007 常見問題則稍有不同，所以我要在這裡加以說明。
系統管理工具的變更
事件日誌仍是將複寫問題縮小至特定失敗點的最佳工具。在第 1 部分 (可能為英文網頁)中，我建議將 [複寫內送] 和 [複寫外寄] 上的記錄功能調至 [最大]。這仍然適用，只是使用 Exchange 2007 時，您要使用 Set-EventLogLevel Cmdlet 將 "MSExchangeIS\9001 Public\Replication Incoming Messages" 和 "MSExchangeIS\9001 Public\Replication Outgoing Messages" 設為 [專家] 層級。
在第 2 部分 (可能為英文網頁)中，我說明了如何使用 ESM 中的 [同步處理階層] 和 [同步處理內容] 選項，強制送出狀態郵件，並讓所有未解決的回填項目逾時。在 Exchange 2007 中，仍可透過 Update-PublicFolderHierarchy 和 Update-PublicFolder Cmdlet 執行此作業。SP1 的公用資料夾管理工具中也有這些功能，選取公用資料夾根目錄時，會顯示為 [更新階層]，選取特定公用資料夾時，會顯示為 [更新內容]。因為您可以從命令列使用這些功能，所以會比 Exchange 2003 選項更有彈性。例如，現在在 Exchange 2007 伺服器上，只要簡單的 "Get-PublicFolderStatistics | Update-PublicFolder" 命令，就可以針對具有複本的每個資料夾，讓回填項目逾時。以前在 Exchange 2003 中，要按很多次滑鼠才有可能辦到。
在第 3 部分 (可能為英文網頁)中，我說明了如何使用公用資料夾執行個體檢視，來查看是否已完成複本的刪除。在 Exchange 2007 中，您可以使用 Get-PublicFolderStatistics 命令來查看相同的資訊。
Exchange 2007 中的常見問題
目前我看到最常見的徵兆，就是儲存區驅動程式失敗。例如，回填回應會傳送到 Exchange 2007 伺服器，但是如果您在 2007 那端查看應用程式記錄檔，則從未看到內送複寫事件。郵件追蹤會顯示複寫郵件已傳送到集線傳輸伺服器，然後在儲存區驅動程式中失敗。
發生這種情形的原因有好幾個，幸好它通常不會很難進行疑難排解。在此情況下，您最佳的疑難排解方法，就是使用集線傳輸伺服器上提供的「管線追蹤」和「內容轉換追蹤」。如果您執行 "Get-TransportServer | fl"，就會看到與此相關的幾項設定：
PipelineTracingEnabled : False
ContentConversionTracingEnabled : False
PipelineTracingPath : C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing
PipelineTracingSenderAddress : SERVER01-IS@contoso.com
若要找出回填回應在儲存區驅動程式中失敗的原因，請將 PipelineTracingSenderAddress 設為符合傳送回填回應之公用資料夾儲存區的 SMTP 位址。然後將 ContentConversionTracingEnabled 設為 $true 而且將 PipelineTracingEnabled 設為 $true，並重新產生問題。這麼做之後，查看 PipelineTracingPath 所指定的資料夾。您應該會在裡面發現一個名為 ContentConversionTracing 的子資料夾，以及 InboundFailures 資料夾。在 InboundFailures 資料夾中，會有一個包含複寫郵件本身的 EML 檔，以及一個包含失敗相關資訊的 TXT 檔。TXT 檔頂端通常會提供您失敗原因的有用線索。
例如，我們在一些情況的 TXT 檔中看過下列輸出：
Microsoft.Exchange.Data.Storage.PropertyValidationException: 內容驗證失敗。內容 = [{00020329-0000-0000-c000-000000000046}:'Keywords'] 類別
錯誤 = 多重值內容中的元素 0 無效。
此情況是在指出 [類別] 內容有誤。如果有問題的公用資料夾包含之項目的 [類別] 內容設為空白 (例如單一空格)，而不是真正的清空，就會發生這種狀況。您可以在 Outlook 中選擇依 [類別] 檢視項目，就會看到此情形。您應該會發現有兩組不同的項目顯示 [無]。若要更正此問題，只要使用 Outlook，清除所有 [無] 項目上的 [類別] 即可。您必須將其設為其他類別，再設回 [無]。一旦 [類別] 內容真正清空，就只會有一組項目顯示 [無]，項目就會複寫成功。
另一個範例：
Microsoft.Exchange.Data.Storage.PropertyValidationException: 內容驗證失敗。內容 = [{00062004-0000-0000-c000-000000000046}:0x8092] Email2AddrType
錯誤 = Email2AddrType 太長：長度上限為 9，實際長度為 35。
此案例中將 Email2AddrType 內容標示為有問題。我們發現某些連絡人上似乎已填入完整的電子郵件地址，而不只是包含正常該有的位址類型，例如 'SMTP' 或 'EX'。修正該內容可讓項目進行複寫。
有時候儲存區驅動程式失敗的方式會讓它無法識別特定問題內容，例如下列輸出：
Microsoft.Exchange.Data.Storage.ConversionFailedException: 郵件內容已損毀。 ---> Microsoft.Exchange.Data.Storage.ConversionFailedException: 因為 TNEF 損毀，所以內容轉換失敗 (違規狀態: 0x00000800)
這是在您發生 KB 936000 中所描述的問題時，失敗狀況看起來的樣子。將修正程式套用至產生複寫郵件的 Exchange 2003 伺服器可更正該問題。
我們從這裡可以發現一件很重要的事，那就是 Exchange 2007 會做許多內容驗證來避免不良資料進入儲存區。雖然這是好事，但它會無法從 Exchange 2003 伺服器複寫公用資料夾資料，直到 2003 伺服器上的內容問題更正為止。ContentConversionTracing 可協助您找出這些問題，而且通常可為您指出造成問題的確切內容。
還有一個您可以用 ContentConversionTracing 找出的常見問題，但它不是由任何有關內容的實際問題所造成。InboundFailures 資料夾中的 TXT 檔看起來像下面這樣：
Microsoft.Exchange.Data.Storage.ConversionFailedException: 已超過內容轉換限制。
at Microsoft.Exchange.Data.Storage.InboundMimeConverter.ConvertToItem(MimePromotionFlags promotionFlags)
at Microsoft.Exchange.Data.Storage.ItemConversion.InternalConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options, MimePromotionFlags promotionFlags, Boolean isStreamToStream)
at Microsoft.Exchange.Data.Storage.ItemConversion.ConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options)
InboundConversionOptions:
- preferredCharset: iso-8859-1
- trustAsciiCharsets: True
- isSenderTrusted: False
- imceaResolveableDomain: contoso.com
- preserveReportBody: False
- clearCategories: True
- userADSession:
- recipientCache: Microsoft.Exchange.Data.Directory.Recipient.ADRecipientCache
- clientSubmittedSecurely: False
- serverSubmittedSecurely: False
ConversionLimits:
- maxMimeTextHeaderLength: 2000
- maxMimeSubjectLength: 255
- maxSize: 2147483647
- maxMimeRecipients: 12288
- maxRecipientPropertyLength: 1000
- maxBodyPartsTotal: 250
- maxEmbeddedMessageDepth: 30
- exemptPFReplicationMessages: True
首先，請注意第一行寫著：「已超過內容轉換限制。」通常公用資料夾複寫郵件可不受大小之類的限制，所以為什麼此郵件會以這種方式失敗呢？請注意 "isSenderTrusted" 為 False。這表示郵件是透過未經驗證的 SMTP 連線傳送過來。傳送伺服器可能驗證失敗，或甚至從未嘗試驗證。這和我在第 3 部分 (可能為英文網頁)的＜常見問題＞一節中描述的非常類似，其中驗證失敗會導致 XEXCH50 動詞在 Exchange 2003 中失敗。因為傳送伺服器沒有經過驗證，所以 Exchange 2007 伺服器會對郵件套用一般大小限制。如果這是含有超過 250 個附件的內容複寫郵件 (就內容回填回應而言並非不常見)，就會失敗，因為它超出限制。因為系統管理員建立了不允許驗證的第二個接收連接器，但又將它設定為接聽內部 IP 而非外部 IP，所以會經常發生這種情況。如果不是這個原因，您可能需要使用 Netmon 擷取來找出問題，如我在第 3 部分中所述。
結論
這應該涵蓋了在 Exchange 2007 環境中縮小公用資料夾複寫問題範圍時，需要知道的所有內容。所有舊的疑難排解步驟仍然適用；我們只是有不同的系統管理工具和不同的問題組合。希望有所幫助！
這是翻譯後的部落格文章。英文原文請參閱 Public Folder Replication Troubleshooting - Part 4: Exchange Server 2007/2010 tips