公用文件夹复制的故障排除 – 第 1 部分：有关新更改复制的故障排除

原文发布于 2011 年 11 月 28 日（星期一）

原文在美国博客上的发布日期：2006 年 1 月 17 日

注意：本博客文章是“公用文件夹的故障排除”系列的第 1 部分。另请确保查看本系列的第 2 部分（该链接可能指向英文页面）、第 3 部分（该链接可能指向英文页面）和第 4 部分（该链接可能指向英文页面）。

简介

本系列的博客文章旨在充当解决公用文件夹复制问题的指南。它不会告诉您修复所有可能的复制问题的确切方法。但是，它将为您演示如何隔离每个可能的复制问题，以便您可以将故障排除的重点放在故障点上。也就是说，本文旨在将您的问题描述的范围从诸如“我的旧服务器上的内容无法复制到我的新服务器”缩小为诸如“我的旧服务器无法响应来自我的新服务器的状态请求，因此新服务器不知道其缺少数据，从而不会尝试回填。这意味着这实际上是旧服务器的问题”。本文还介绍了如何识别一些最常见的复制问题。在开始详细说明故障排除之前，我会先概述我解决这些问题所使用的常规方法。

公用文件夹复制的最佳故障排除工具是应用程序日志。为了隔离复制问题，您必须能够根据日志中的复制事件来判断进程中断的确切位置。通常，在开始进行故障排除时要做的第一件事就是，应将针对复制传入和复制传出的诊断日志记录调到最大值。每当存储发送或接收复制消息时，它都会记录一个相关事件（假定已打开日志记录）。不同类型的复制消息可根据事件描述中显示的“类型”进行区分。我更喜欢关注类型而不是事件 ID，原因如下：

- 事件 ID 随 Exchange 版本不同而变化。例如，在 Exchange 5.5 中，某个出站回填请求为 3014，而在 Exchange 2000 和 2003 中，该请求为 3016。

- 每种类型的传入和传出事件 ID 均不同。某个传出层次结构消息为 3018，而相应的传入层次结构消息为 3028。

- 状态请求和状态消息使用同一事件 ID，即使它们属于两种不同的消息类型也是如此。因此，您无法仅通过事件 ID 区分它们。

关注类型会稍微简单一点。您可以通过检查应用程序日志轻松地将类型与事件 ID 进行关联。类型只有 7 种，因此您可以通过查看事件类别来确定消息是传出还是传入的。如果您关注的是类型而不是事件 ID，则只需记住以下内容：

层次结构 - 0x2

内容 - 0x4

回填请求 - 0x8

回填响应 - 0x80000002（针对层次结构）或 0x80000004（针对内容）

状态 - 0x10

状态请求 - 0x20

另请注意，复制错误日志记录没有多大帮助。即使复制在正常工作时，大部分服务器也会生成大量复制错误事件（如事件 ID 3093，它指示读取属性时出错）。多数情况下，属性对复制没有影响，因此可忽略这些错误。我建议将复制错误日志记录保持为“无”，除非您要查找某些特定内容，如本博客文章的上一篇文章（该链接可能指向英文页面）中所述的问题。

有关新更改复制的故障排除

若要对公用文件夹复制进行故障排除，您必须先熟悉在进行复制时预期的正常消息流。基于这些知识，您就可以在出现问题时识别故障点。在讨论如何对新更改的复制进行故障排除之前，让我们先讨论预期的行为。

层次结构复制

在创建或删除文件夹或者对公用文件夹的属性（如副本列表、客户端权限、描述、管理说明或存储限制）进行更改时，都会复制新的层次结构更改。请注意，这不包括启用了邮件的文件夹上的电子邮件地址。这些电子邮件地址存储在 Active Directory 中的目录对象上，因��，更改它们不会导致层次结构复制。仅当更改存储在公用存储本身中的属性时才会导致层次结构复制。

每隔 15 分钟（默认），存储就会在一条或多条层次结构复制消息中广播一次对文件夹的属性进行的所有更改。通过将复制传出的日志记录调到最大值，您将会在已修改层次结构的服务器上看到类似于下面的事件：

事件类型: 信息

事件源:      MSExchangeIS Public Store

事件类别:    复制传出邮件

事件 ID:    3018

描述:

已发出了传出复制邮件。

类型: 0x2

消息 ID: <91ACCD0758385549A56A10971798985572D5@bilongexch1.bilong.test>

数据库“第一个存储组\公用文件夹存储(BILONGEXCH1)”

CN 最小值: 1-72CF，CN 最大值: 1-72D3

RFI: 1

1) FID: 1-6994，PFID: 1-1，偏移: 28

      IPM_SUBTREE\NewFolder

请注意此描述开头的“类型: 0x2”，应将它视为一条层次结构复制消息。

层次结构复制消息是从发起服务器直接发送到所有其他公用存储的。新更改的复制没有拓扑的概念。所有层次结构更改将直接从进行这些更改的服务器发送到具有与同一层次结构关联的公用存储的所有其他服务器。当所有其他服务器成功处理传入复制消息时，它们应记录一个显示了类型 0x2 的传入事件。

内容复制

每当创建或删除消息或更改消息属性时都会进行内容复制。存储广播文件夹内容更改的时间可通过更改文件夹的复制计划来进行修改，但默认情况下每 15 分钟广播一次更改，这与层次结构一样。在事件描述中，内容复制消息由类型 0x4 进行标识。同样，新更改的广播也没有拓扑的概念。当某个文件夹的内容在任何给定副本上发生修改时，该副本将直接向该文件夹的所有其他副本发送 0x4 消息。同样，当所有接收服务器成功处理传入消息时，它们也应记录一个传入 0x4 事件。

故障排除步骤

上面是复制的两种最基本的方案。当新层次结构更改或新内容更改没有从一台服务器传递到另一台服务器时，故障排除就会非常简单。

1. 服务器是否生成了出站复制消息？

您更改了文件夹或向特定服务器上的文件夹添加了内容，且这些内容没有传递到其他一些服务器。第一个要回答的问题是目标服务器是否会广播这些更改？在进行故障排除时，跟踪您进行更改时所在的服务器非常重要。有几种方法可实现这一目的。在 ESM 中，您可以右键单击公用文件夹节点并选择“连接到”以指向特定存储。大多数情况下，ESM 将在指定存储上进行所有更改，但请注意一个例外 - 客户端权限。在 Exchange 2003 Sp2 以前的版本中，当您通过 ESM 更改客户端权限时，ESM 将尝试在保存文件夹副本的存储上进行更改，即使没有必要这样做（因为此权限在层次结构中作为文件夹属性进行存储）也是如此。在 ESM 的 2003 Sp2 版中，这一点已经更改，现在确实可以在您指向的层次结构上进行更改。当您通过借助 ESM 进行更改来测试层次结构复制时，应避免使用测试权限，因为很难预测在哪个存储上进行更改，除非您运行的是 ESM 的 2003 Sp2 版。如果您使用的是 Outlook 且希望验证您点击的是文件夹的哪个副本，则可以使用 MFCMAPI 或类似的工具来查看文件夹的 PR_REPLICA_SERVER 属性。这会向您显示 Outlook 用于访问该文件夹的内容的服务器名称。

如果相关文件夹的复制计划为“始终”（对于层次结构始终适用），且您在 15 分钟之内未看到出站 0x2 或 0x4，那么您就可以断定发起服务器出现了问题。如果服务器未生成任何出站层次结构或内容广播，则复制代理的启动可能已失败。KB272999 中描述了常见的情形之一。此处要注意的重点是 3079 事件：

事件 ID: 3079

源: MSExchangeIS Public

类型: 错误

类别: 复制错误

描述:

意外的复制线程错误 0x3f0。

EcGetReplMsg

EcReplStartup

FReplAgent

上述事件将会被记录，即使您在装载公用存储时没有打开任何其他日志记录也是如此。如果 3079 包含“EcReplStartup”函数，那么这意味着复制代理启动已失败，因此不会广播任何新更改，直到纠正问题并再次装载存储。

当组织中存在 Exchange 5.5 公用存储时，层次结构复制也容易出现某些权限问题。当 Exchange 2000 或 2003 服务器向 Exchange 5.5 服务器发送层次结构复制消息时，它必须通过 ptagNTSD 属性（基于 SID 的 2000 样式的权限）生成 ptagACLData 属性（基于 legacyExchangeDN 的 5.5 样式的权限）。这意味着每个 SID 必须转换为 legacyExchangeDN。此 SID 到 legacyExchangeDN 的转换可能由于某些原因而失败。例如，如果 SID 解析到多个用户，就会生成类似下面的事件：

事件 ID: 9528

类别: 常规

源: MSExchangeIS

类型: 错误

描述:

在 DS 中找到 2 个用户拥有 SID S-1-5-21-408248388-469072634-37170099-1391，因此存储无法将此 SID 映射到唯一用户。

这些用户包括:

/DC=com/DC=company/CN=Users/CN=User1

/DC=com/DC=company/CN=Users/CN=User2

因为 SID 无法转换为 legacyExchangeDN，所以存储将无法生成出站层次结构广播消息。

2. 消息是否被发送到未接收更改的服务器？

如果发起服务器生成了出站消息，则下一步是确定它是否被发送到不接收数据的服务器。验证这一点的最简单方法是跟踪该消息。在消息跟踪中，您可以仅跟踪出站复制事件中报告的消息 ID。在消息历史记录窗口中，“收件人”行将是可见的。如果此处没有列出未接收更改的存储，则应再次重点调查发起服务器。是否在组织中看到该服务器？该服务器是否有其公用存储对象的电子邮件地址？发起服务器是否在相关文件夹中的副本列表中看到该存储？

3. 消息是否传递到目标服务器？

确认消息已被发送到目标服务器后，下一个要回答的问题是 - 此消息是否已传递到那里？您可以通过消息跟踪进行确定。如果消息跟踪显示消息已传递到存储，但是您没看到确认此消息的传入复制事件，请参阅本系列的最后一篇文章（该链接可能指向英文页面）的“常见问题”一节。

下一篇博客文章：有关现有数据复制的故障排除（该链接可能指向英文页面）。

- Bill Long

这是一篇本地化的博客文章。请访问 Public Folder Replication Troubleshooting – Part 1: Troubleshooting the Replication of New Changes 以查看原文