公用文件夹复制的故障排除 – 第 3 部分：有关副本删除的故障排除和常见问题

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

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

这是有关解决公用文件夹复制问题的第三篇博客文章。在第一篇文章（该链接可能指向英文页面）中，我们介绍了有关新更改复制的故障排除。第二篇博客文章（该链接可能指向英文页面）介绍了有关现有数据复制的故障排除。这一系列中的本篇文章将介绍有关副本删除的故障排除和常见问题。若要进行全面了解，请阅读提到的所有材料！

有关副本删除的故障排除

您从所有文件夹的副本列表中删除了一个旧服务器。但当您转到 ESM 中旧存储的公用文件夹实例时，仍会在该处看到一些文件夹。这是因为副本删除过程出现问题。在 ESM 的 Exchange 2003 Sp2 版本中，如果尝试在这种情况下删除公用存储，则 ESM 将显示一个包含以下内容的对话框：

“无法删除此公用文件夹存储，因为它包含文件夹副本。若要避免数据丢失，请右键单击此公用文件夹存储，然后使用“移动副本”将副本移至其他服务器。可能需要几个小时才能将内容复制到新服务器和删除本地副本。”

当您从文件夹的副本列表中删除某个存储时，该存储不会立即删除数据。相反，它会向所有其他副本发送一个特殊的 0x20 状态请求。该状态请求称为“副本删除挂起状态请求 (RDPSR)”，我们无法区分该请求与应用程序日志中的正常状态请求。RDPSR 包含一个指示副本处于删除挂起状态的标志。当其他存储收到此 0x20 请求时，会以一个称为“副本删除挂起确认 (RDPA)”的特殊 0x10 作为响应。RDPA 指示可以删除该数据 – 但其他存储仅在其已具有删除挂起的副本具有的所有 CN 时才发送此 0x10。仅当该存储收到指示其他某个存储也具有该数据的 0x10 后才会删除副本。

这意味着，如果在公用文件夹实例为空前删除存储，则可能会丢失数据。只有 2003 Sp2 ESM 会阻止您这样做 – 在早期的版本中，您必须手动检查公用文件夹实例以了解是否可以删除存储。在删除公用存储之前，您应总是检查公用文件夹实例，当 2003 Sp2 ESM 向您发出此警告时，您不应尝试忽略或绕过它 – 而应对副本删除过程进行故障排除。

请注意，在 Exchange 2003 Sp2 之前，从副本列表中删除的服务器仅会发送一次 RDPSR。如果没有任何响应，您将看到，文件夹将无限期地停留在公用文件夹实例中，除非您将存储添加回副本列表，然后再次删除它，从而导致发送新的 RDPSR。2003 Sp2 更改了此行为，使存储每小时重试一次，直到它从其他存储获得 RDPA。

故障排除

这几乎与对回填过程进行故障排除一样。

1. 删除挂起的副本是否发送了 0x20？

除非您在删除副本时已打开日志记录，否则您不会知道是否已发送。幸运的是，您只用添加回副本，然后再次删除它即可。随后，您可以查看应用程序日志中是否有 0x20。

2. 0x20 是否到达其他副本？

现在，您应知道操作方法了。检查其他副本上的应用程序日志以了解它们是否收到了 0x20。

3. 是否有任何副本以 0x10 作为响应？

这是您最后可能需要关注的部分。如果某副本收到来自删除挂起的副本的 0x20，但并未以 0x10 作为响应，则意味着该删除挂起的副本具有其他副本没有的数据。由于您知道前者收到来自后者的 0x20，那么也就知道前者已知道所丢失的数据。因此，您将期望每 24-48 小时看到一个针对该文件夹的回填请求。请查看应用程序日志，并完全按照前面所述的对正常回填过程采用的方式来进行故障排除。

4. 删除挂起的副本是否收到 0x10？

只要其他任何副本具有所有数据，该副本都应以 0x10 作为响应。当挂起的删除副本收到 0x10 时，最终将会同意删除相关数据。但这并不意味着删除会立即发生。如果有客户端正在使用该副本，则直到以后联机维护时才会进行删除。如果需要，您可以加快此过程，方法为卸除并装载存储来断开与客户端的连接。

常见问题

您可能发现，一台服务器会向另一台服务器发送某种类型的复制消息，但接收服务器不会将这些传入消息记录在应用程序日志中。但是，消息跟踪显示已将该消息本地传递到接收服务器上的存储中。此行为通常表示 复制 状态 表存在问题，或 SMTP 虚拟服务器上存在权限问题。

让我们先从简单的问题入手。导致接收服务器忽略传入复制消息的问题之一是 复制 状态（或称为 ReplState）表存在问题。请注意，ReplState 表存在问题可能还会导致服务器无法发送针对某些文件夹的回填请求 (0x8)，因此此信息也适用于该情况。每个公用存储使用其 ReplState 表跟踪所有已复制文件夹的复制状态。在该表中，每个文件夹有多个行，每个副本对应一行。ReplState 表中的行可能会中断与副本列表的同步，这样，该表就会包含多余的行或丢失行。有时候您可以再次进行同步，只需进行一个更改（如从副本列表中删除一台服务器），应用此更改，然后立即将它添加回副本列表即可，但这并不是每次都有用。幸运的是，ReplState 测试已添加到 isinteg。有关 Exchange 2003，请参阅 KB889331；有关 Exchange 2000，请参阅 KB892485。只要您具有已更新的 isinteg.exe 和 store.exe，就可使用 isinteg 纠正 ReplState 表的问题。如果只运行 ReplState 测试，一般而言速度会很快 - 即使在大型公用存储上也只要不到一分钟的时间。运行 isinteg 后，您可能仍需返回并对文件夹进行更改才能使 ReplState 表与副本列表同步。当它们同步后，服务器应该能处理传入复制消息，或者应该开始正常发出回填请求。

另一个导致忽略传入复制消息的问题是特定于 Exchange 2003 的问题。Exchange 2003 服务器要求发送服务器对接收 SMTP 虚拟服务器具有“代理发送”权限。也就是说，如果 ServerA 是 Exchange 2003，ServerB 要向 ServerA 发送一条 PF 复制消息，则 ServerB 对 ServerA 的 SMTP 虚拟服务器必须具有“代理发送”权限。否则，ServerA 不会处理该传入复制消息。此权限一般是通过 Exchange 域服务器组授予的。如果问题正出现在“代理发送”权限上，则来自特定服务器的所有传入复制消息将失败。我发现，当复制消息从一台服务器传输到另一台服务器时，使用网络跟踪是识别此问题最简单的方法。对话应如下所示：

ServerA: 220 ServerA.microsoft.com Microsoft ESMTP MAIL Service...

ServerB: EHLO ServerB.microsoft.com

ServerA: 250-ServerA.microsoft.com Hello

         250-TURN

         250-SIZE

         250-ETRN

         250-PIPELINE

         250-DSN

         250-ENHANCEDSTATUSCODES

         250-8bitmime

         250-BINARYMIME

         250-CHUNKING

         250-VRFY

         250-X-EXPS GSSAPI NTLM LOGIN

         250-X-EXPS=LOGIN

         250-AUTH GSSAPI NTLM LOGIN

         250-AUTH=LOGIN

         250-X-LINK2STATE

         250-X-EXCH50

         250 OK

此处的重要部分是 ServerA 必须播发 GSSAPI NTLM LOGIN 选项。如果您在 ServerA 对 EHLO 的响应中未看到这些选项，通常是因为尚未在 SMTP 虚拟服务器上选中“集成 Windows 身份验证”。这在 KB843106 的第 1 步和 KB842273的第 3 步中提到过。只要这些身份验证谓词出现，您应该就会看到 ServerB 尝试使用它们：

ServerB: X-EXPS GSSAPI

ServerA: 支持 334 GSSAPI

ServerB: <一组 base64 编码数据>

ServerA: 334 <更多 base64 编码数据>

ServerB: CRLF

ServerA: 235 2.7.0 身份验证成功。

如果身份验证未成功，则可能是 Kerberos 存在问题或 ServerB 的计算机帐户存在问题。接下来，服务器将传输链接状态信息。此后，服务器最终会绕过该问题，开始进行传送电子邮件的工作：

ServerB: MAIL FROM:<ServerB-IS@microsoft.com>

ServerA: 250 2.1.0 ServerB-IS@microsoft.com....Sender OK

ServerB: RCPT TO:<ServerA-IS@microsoft.com> NOTIFY=NEVER

ServerA: 250 2.1.5 ServerA-IS@microsoft.com

ServerB: XEXCH50 2404 2

ServerA: 354 Send binary data

这是对 XEXCH50 谓词的最后一次响应，它非常重要。如果响应为“354 发送二进制数据”，则表示一切都正常，至少就与 SMTP 虚拟服务器有关的权限而言是正常的。如果未播发 GSSAPI NTLM 登录选项，或身份验证尝试失败，则期望 ServerA 将改用“504 需要进行身份验证”响应。如果这些步骤成功，但 ServerA 仍响应“504 需要进行身份验证”而不是“354 发送二进制数据”，则表示 ServerB 对 ServerA 的 SMTP 虚拟服务器没有“代理发送”权限。此问题可能在以下几种情况下发生。第一种，当使用 ESM 委派“Exchange 完全权限管理员”等权限时，则该用户或组将继承对“代理发送”权限的拒绝。因此，使用 ESM 向计算机帐户、Exchange 域服务器组或包含 Exchange 服务器的其他某个组委派管理权限将中断公用文件夹复制。另一种可能的情况是，计算机帐户不在 Exchange 域服务器组中，而这通常是它获得“代理发送”权限的方式。您将需要评估对 SMTP 虚拟服务器的权限并确定发送服务器的计算机帐户没有适当权限的原因。有关“504 需要进行身份验证”问题的更多详细信息，请参阅 KB843106 和 KB842273。

结束语

当您仔细阅读本文档后，您可能已发现 Exchange 2003 Sp2 包含了若干重大改进，用于防止出现复制问题和帮助解决这些问题。当处于具有多个公用存储的环境中时，您才能真正看到 Sp2 带来的巨大好处，尤其是涉及在服务器之间移动副本以及添加和删除公用存储的情况。

但愿本文对您有所帮助。衷心感谢 Dave Whitney 对本文进行了审核！

- Bill Long

这是一篇本地化的博客文章。请访问 Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems 以查看原文