公用文件夹复制的故障排除 - 第 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: Property validation failed. Property = [{00020329-0000-0000-c000-000000000046}:'Keywords'] Categories 
Error = Element 0 in the multivalue property is invalid..

在此示例中，Categories 属性便是问题所在。如果相关公用文件夹包含 Categories 属性设置为空（如包含一个空格而不是真正为空）的项目，则会出现上述问题。您可通过进入 Outlook 并选择按类别查看项目来查看这些项目。您应该会发现有两组不同的“None”项目。若要纠正此问题，只需使用 Outlook 清除所有“None”项目上的类别即可。您可能必须将这些项目设置为其他某个类别，然后再将其设置回 None。一旦真正清除了 Categories 属性，则将只有一组显示“None”的项目，并且这些项目将复制成功。

另一个示例：

Microsoft.Exchange.Data.Storage.PropertyValidationException: Property validation failed. Property = [{00062004-0000-0000-c000-000000000046}:0x8092] Email2AddrType 
Error = Email2AddrType is too long: maximum length is 9, actual length is 35..

在此示例中，标记着 Email2AddrType 属性为问题所在。我们发现，已经以某种方式使用特定联系人的完整电子邮件地址填充了该属性，而不仅仅是包含正常情况下应包含的地址类型（如“SMTP”或“EX”）。修复该属性就能复制项目。

有时候，存储驱动程序将以未标识特定问题属性的方式失败，如下面的输出所示：

Microsoft.Exchange.Data.Storage.ConversionFailedException: Message content has become corrupted. ---> Microsoft.Exchange.Data.Storage.ConversionFailedException: Content conversion failed due to corrupt TNEF (violation status: 0x00000800)

这是当您遇到 KB 936000 中介绍的问题时的故障表现。对生成复制消息的 Exchange 2003 服务器应用此修复将可纠正该问题。

除此之外还要提到的一个重点是，Exchange 2007 会执行大量属性验证以阻止损坏的数据进入存储。尽管这个功能不错，但在 2003 服务器上纠正内容的问题之前，它也可能会阻止从 Exchange 2003 服务器复制公用文件夹数据。ContentConversionTracing 可帮助您识别这些问题，并且会经常向您指出导致问题的确切属性。

有一个您可以使用 ContentConversionTracing 发现的更常见的问题，但该问题不是由内容的任何实际问题导致的。InboundFailures 文件夹中的 TXT 文件将如下所示：

Microsoft.Exchange.Data.Storage.ConversionFailedException: The content conversion limit has been exceeded. 
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 的环境中的公用文件夹复制问题的范围所需了解的所有内容。原来的所有故障排除步骤仍然适用；我们只是使用了不同的管理工具并遇到了一组不同的问题。希望本文对您有所帮助！

- Bill Long

这是一篇本地化的博客文章。请访问 Public Folder Replication Troubleshooting - Part 4: Exchange Server 2007/2010 tips 以查看原文