公用文件夹复制的故障排除 – 第 2 部分：有关现有数据复制的故障排除
原文发布于 2011 年 11 月 28 日（星期一）
原文在美国博客上的发布日期：2006 年 1 月 20 日
这是有关解决公用文件夹复制问题的第二篇博客文章。在第一篇文章（该链接可能指向英文页面）中，我们介绍了有关新更改复制的故障排除。本篇博客文章将介绍有关现有数据复制的故障排除，而本系列的最后一篇文章（该链接可能指向英文页面）将介绍有关副本删除的故障排除和常见问题。若要进行全面了解，请阅读提到的所有材料！
有关现有数据复制的故障排除
当复制了新更改，但未复制旧的未更改的数据时，您会遇到回填问题。层次结构回填通常发生在创建新的公用存储时。内容回填通常发生在公用存储已添加到文件夹的副本列表时。
当您遇到类似的回填问题时，您可能已想到有一个简单的解决方法，即更改所有项目。通过这样做，您可以避开中断的回填进程，并将所有内容作为新更改进行复制。尽管我将通常用于解决此问题的两个工具（PFDAVAdmin 和 ModifyItems）都写了出来，但通常最好是对回填过程进行故障排除并消除根本原因。如果您只是针对复制做必要的更改，则在将来副本失去同步时还是会遇到相同的回填问题。说了这么多，让我们继续讨论回填。若要了解回填过程，首先必须了解如何跟踪更改。
存储中的所有文件夹和消息在创建时和每次修改时都分配有一个更改编号 (CN)。当复制发生时，每个对象上的 CN 将用于确定该对象是否需要复制。一组 CN 称为 CNSet。特定服务器上特定文件夹的 CNSet 称为状态信息。每条复制消息都包含此状态信息。每个消息类型 0x2 都包含发送服务器的层次结构状态。与此类似，每个消息类型 0x4 都包含发送服务器的特定文件夹的状态信息。所有其他复制消息类型都包含其各自的文件夹的状态信息。
当首次装载新的公用存储时，它会向所有现有公用存储发送一条对层次结构的状态请求（类型 0x20）。与此类似，当新存储添加到文件夹的副本列表时，该存储将向该文件夹的所有其他副本发送 0x20。与所有复制消息一样，状态请求包含一个 CNSet，该 CNSet 包含发起存储具有的相关文件夹（或层次结构）的所有 CN。状态请求会要求具有发送方没有的 CN 的其他存储做出响应。请注意，在 Exchange 2003 Sp2 之前，并不要求每个副本响应状态请求，因此，某些存储将忽略该状态请求，即使它们有发起存储没有的更改时也是如此。2003 SP2 服务器将要求所有副本进行响应，而且只要它有发起服务器没有的更改，则即使发起服务器并未明确要求响应，它也会进行响应。这可以显著改进回填过程中所做的决定。状态请求的独特之处在于，它不包含任何要复制的数据，而只包含一个更改编号列表。其他存储会用状态消息 (0x10) 做出响应，该消息将列出这些存储自己的针对该同一相关文件夹（或层次结构）的 CNSet。当发起服务器收到 0x10 消息时，它会将该消息中包含的 CNSet 与自己的 CNSet 进行比较。如果 0x10 包含该存储尚未拥有的更改，则回填过程会开始。
回填过程的第一步是将条目添加到相关文件夹的回填数组。这些条目具有说明丢失的更改的 CNSet 和说明存储将在何时请求丢失数据的超时值。回填超时值将因情况而异。对于要联机的新公用存储或要添加的文件夹的新副本，初始超时值为 15 分钟。
回填条目也可以在正常操作过程中添加到回填数组。请考虑一种情况，即特定公用存储已在两条单独的 0x2 消息中广播了两个更改。假设管理员从队列中删除了第一条 0x2 消息，但让第二条消息通过。当其他服务器收到此 0x2 时，将会发现状态信息中的 CNSet 包含它们从未获取的 CN。因此，其他服务器将为该数据创建回填条目。对于在复制的正常过程中发现的丢失数据的回填条目，如果该数据可用于相同的路由组 (RG)，则这些条目将在超时 6 小时后启动；如果该数据仅可用于另一个 RG，则这些条目将在超时 12 小时后启动。每次发出回填请求后，对 RG 内请求的下一次超时将先后为 12 小时和 24 小时，或对 RG 间请求的下一次超时将先后为 24 小时和 48 小时。
每隔五分钟，存储将检查是否有任何回填条目已达到其超时值。如果有，则发出针对丢失的 CN 的回填请求（类型 0x8），并将超时设置为下一间隔。回填请求不是广播；它面向单台服务器 - 服务器之一，先前指示它具有发送给请求服务器的状态信息中的丢失 CN。当该服务器收到传入的 0x8 时，它将立即处理该请求，并以一个或多个回填响应（针对层次结构的 0x80000002 或针对内容的 0x80000004）做出响应，其中包含请求的更改编号的实际数据。与回填请求一样，回填响应也不是广播 - 它们仅发送给请求服务器。
如果请求服务器成功处理传入回填响应，则其包含的 CN 将从存储的回填数组中清除。实际上，任何包含回填数组中的未完成 CN 的传入消息都将导致这些 CN 从数组中清除。
故障排除
显而易见，对回填过程进行故障排除有许多要回答的问题。
1. 存储是否知道它丢失了数据？
首先，您应确定服务器是否哪怕意识到其他存储具有它需要请求的更改。很遗憾，没有支持的工具或实用程序能让您直接查看回填数组中是否有任何数据。但是，还是有其他比较间接的方法可以解决这个问题。
一种方法是等待。如果服务器知道其丢失了数据，它将至少每 24 小时或 48 小时请求一次丢失的数据。这意味着您只要打开日志记录并等待查看否有 0x8 消息传出即可。如果您没看到相关文件夹的 0x8 消息，但看到其他文件夹的 0x8 消息，则表示您可能已达到未完成回填的限制数，对此我们将在稍后讨论。
另一个方法是确保服务器收到最新的状态信息。请记住，服务器仅在您添加新副本后发送一次状态请求。此后，它接收的唯一状态信息将贯穿整个正常的复制过程。因此，如果服务器获取状态的初次尝试因为作为响应的 0x20 或 0x10 丢失或删除而丢失，则它会无限期地停滞在此，甚至不会意识到它丢失了数据。有几种方式可确保服务器已收到文件夹的状态信息。
- 转到一台包含所有数据的服务器并通过添加、删除或修改消息对文件夹进行更改。对于层次结构，则是创建、删除或更改文件夹的属性。生成的 0x4 或 0x2 将分别包含该文件夹或层次结构的状态信息。当该丢失数据的服务器成功处理传入复制消息时，您就知道它已将相应条目添加到回填数组。
- 在 Exchange 2003 ESM 中使用“同步内容”选项。这是一项隐蔽性很高但又十分有用的选项。若要找到它，请转到“公用文件夹”树下，再转到相关文件夹。在左侧窗格中突出显示该文件夹。在右侧窗格中单击“状态”选项卡。右键单击包含所有数据的服务器并选择“同步内容”。这可能导致两个结果 - 导致服务器发出该文件夹的状态请求 0x20，并导致服务器立即让任何回填条目超时。请注意，我之前说过您应从已具有该数据的服务器同步内容。您可能想知道为何要这样做，以及其他具有回填条目的服务器需要在何时超时。请记住，此时我们只是尝试确保丢失数据的服务器知道它有要回填的数据。为此，我们可以使用“同步内容”从具有该数据的服务器向不具有该数据的服务器发送 0x20。在这种情况下，我们并不是真的要查看响应 0x20 的状态 0x10。我们只是希望丢失内容的存储从具有该内容的存储接收文件夹的复制消息，以便它可以将相应条目添加到回填数组。来自服务器的包含该数据的 0x20 正是用于这一目的。请注意，在 Exchange 2003 Sp2 中，现在可以通过右键单击“公用文件夹”节点本身让“同步内容”用于层次结构。
- 使用“复制标记”注册表值 (KB813629)。如果您应用了此值和来自 KB321082 的“启动时，启用复制邮件”值，则会导致存储在启动时为每个文件夹发送状态请求 0x20。您将又需要在具有该内容的服务器上使用此方法 - 此步骤的要点是使具有内容的服务器向丢失内容的服务器发送其状态信息。
- 使用 2003 ESM 发送回填响应。在 2003 Sp1 中，您可以使用“发送层次结构”选项来发送层次结构回填响应，还可以使用“发送内容”选项来发送文件夹内容回填响应。在 2003 Sp2 中，这两个选项都变为“重新发送更改”。这会针对您指定的数据范围发送回填响应，但您可能不应指定整个数据范围，因为这可能满足会所有未完成的回填条目，并最终解决原始问题。相反，您应仅指定一天或两天的范围。这会导致 0x80000002 或 0x80000004 传递到目标服务器，从而再次用于向该服务器提供具有该数据的存储的状态信息。
当您使用这些选项之一来强制发送状态信息，并已通过查看应用程序日志来确认丢失数据的存储收到传入消息后，您就知道了该存储知道它丢失了数据。
2. 存储是否请求了丢失的数据？
在您确认存储知道它需要回填某些数据后，它是否发出过回填请求？在其尝试回填数据两次后，请撤回该请求。您可能必须等待 24 小时或 48 小时才能发出下一个回填请求，因为这将是网站内和网站间回填各自的最长超时间隔。有一种方法可加快此操作的速度，那就是再次使用“同步内容”，但是这次是从丢失数据的服务器上使用“同步内容”。这会立即使该文件夹的回填条目超时。但是，您可能仍然发现该存储没有发出针对您关注的文件夹的回填请求。如果出现这种情况，请查看接下来的 24 到 48 小时的应用程序日志。如果存储正在发送针对其他文件夹的回填请求，而没有发送针对您关注的文件夹的回填请求，则表示它可能已达到未完成回填的限制数。
如果您已向新存储添加许多文件夹的副本，并且复制一开始看来运行状况良好但在接下来的一天或两天出现逐渐停止的情况，则表示您可能已达到未完成回填的限制数。未完成回填限制数是一个用于限制复制的机制。默认情况下，存储一次仅允许 50 个未完成回填请求。一旦存储有 50 个未完成回填请求，它就会重复发送这 50 个请求，直到这些请求被满足。当任一未完成条目被满足后，OBL 中就会出现一个空缺，这样便能请求一组新的数据。这意味着，如果 50 个请求出于任何原因而无法满足，复制将无法进行。
如果您看到了此行为，则应查看应用程序日志来了解存储请求的内容。您将看到当前 50 个未完成回填请求的定期发送 0x8 消息，然后您将发现未收到任何回填响应，这就是它们仍未完成的原因。此时，您应将工作重点改为对存储当前正在尝试回填的文件夹之一进行故障排除，因为解决该问题后就能继续处理其他文件夹。
还有另一个方法，那就是增大未完成回填限制数 (OBL)。您可以通过在注册表项下为存储创建一个名为“复制未完成回填限制数”的注册表值来做到这一点。最大值为 5000（十进制）。但是，一旦您这样做，则会进行大量的复制，从而很难确定是哪 50 个文件夹导致它堵塞。您将需要推迟故障排除，直到系统再次稳定。通常而言，我建议将限制数保持在 50 然后再解决问题，而不是通过增大限制数来解决问题。
如果 OBL 似乎没有问题，而您仍然看不到相关文件夹的传出 0x8 消息，请参阅本系列的上一篇文章（该链接可能指向英文页面）中的“常见问题”。
3. 其他存储是否响应了请求？
当您有要关注的回填请求时，就需要确定回填目标是否收到过该请求。请查看该服务器的应用程序日志中的传入 0x8。您还可以在应用程序日志中搜索来自发送端的传出事件中提到的消息 ID。如果您无法在应用程序日志中找到相应线索，请使用消息跟踪来查看该消息传递到的位置。如果应用程序日志收到 0x8，它几乎应立即以一个或多个 0x80000002 或 0x80000004 消息进行响应（您将经常看到多个回填响应一个回填请求，因为更改不是全部在单条消息中发送的）。当然，生成回填响应消息所需的时间将因文件夹中的数据和复制消息的大小限制而异。例如，如果您将复制消息的最大大小设置为 1 GB，则响应服务器可以尝试将整个层次结构打包到单个回填响应中 - 仅打包就可能需要一个小时或更长时间！
4. 请求服务器是否获得响应？
现在该检查请求服务器上的应用程序日志是否收到回填响应了。如果未收到，请跟踪消息并观察它传递到的位置。如果收到回填响应并将其记录在应用程序日志中，则表示回填请求应该已满足，因此应该可以继续操作。
如前所述，如果您发现消息跟踪显示这些消息中有一个消息已传递给存储，但应用程序日志未显示传入复制消息，请参阅本系列的最后一篇文章（该链接可能指向英文页面）中的“常见问题”。
下一篇博客文章：有关副本删除的故障排除和常见问题（该链接可能指向英文页面）。
这是一篇本地化的博客文章。请访问 Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data 以查看原文