Configuration Manager 2007 中基于事务的复制概述

大家好，我是 Microsoft 的 Configuration Manager 支持团队成员 Umair Khan，想用几分钟的时间介绍一下 Configuration Manager 2007 中站点之间基于事务的复制。请注意，本文内容假定您已经了解站点间通信的基本流程，因此您可能需要回顾一下这些知识再进一步阅读：

https://blogs.msdn.com/b/steverac/archive/2010/07/16/understanding-site-to-site-communication-in-sms-sccm.aspx。

简介：

System Center Configuration Manager 2007 (ConfigMgr) 中的站点间通信共有两种复制类型。第一种是基于事务的复制，第二种是非基于事务的复制。此复制提供一种方法，使每个站点都有最新的数据，并且接收站点具有拒绝旧数据的能力。

1. 基于事务的复制

对于此类复制，复制管理器将在 replmgr\ready 中创建一个 .RPT 文件。

具有基于事务的复制的对象：

2. 非基于事务的复制。

对于此类复制，复制管理器将在 replmgr\ready 中创建一个 .RPL 文件。未在上面基于事务的表中列出的项目使用非基于事务的复制。

基于事务的复制的基本流程：

每个站点在注册表中的以下位置都有一个复制 ID：

HKLM\Software\Microsoft\SMS\Components\SMS_REPLICATION_MANAGER\Transaction ID

在创建复制作业时，发送站点将基于复制 ID 为该作业标记一个数字，并且复制 ID 按 1 递增。

在到达接收站点时，接收站点将执行验证检查，验证文件附带的数字是否与 replmgr\history 中本地存储在 sitecode .TRS 中的数字保持一致。如果数字小于 sitecode.TRS 文件中存储的相应对象的数字，则拒绝该文件。

接收站点上 replmgr.log 中的示例拒绝消息如下所示：

Replication file C:\Program Files\Microsoft Configuration Manager\inboxes\replmgr.box\incoming\1goq1xsi.RPT has an old transaction ID (Object Type = SITECTRLCT1SRCSITE, Object ID = CS1, Transaction ID = 1112), the current transaction ID is 1113, delete it. （复制文件 C:\Program Files\Microsoft Configuration Manager\inboxes\replmgr.box\incoming\1goq1xsi.RPT 有一个旧事务 ID (对象类型 = SITECTRLCT1SRCSITE，对象 ID = CS1、事务 ID = 1112)当前事务 ID 是 1113，请将其删除。）

这里，TRS 文件中的数据是 1113，它大于文件附带的数字（即 1112），因此将拒绝该文件。

示例：

下面将介绍一个层次结构示例（我的实验中也是该层次结构）：

假设此类层次结构的含义如下：

应用场景：

我要从中心站点控制台对子主站点 (PS1) 属性进行更改（例如添加一个注释）。

过程：

1.在 CS1 站点的 replmgr\ready 文件夹中创建一个 .RPT 文件，并附加一个在注册表的 HKLM\Software\Microsoft\SMS\Components\SMS_REPLICATION_MANAGER\Transaction ID 中提到的数字。

2.按照正常的站点到站点过程，despooler 将收到 .PCK（不要将其与包 PCK 混淆，因为每个文件信息文件都将在接收站点转换为一个 .PCK）和 .SNI 文件，并验证签名，然后作为一个 .RPT 文件将其移动到 replmgr\incoming。

3.PS1 站点的 replmgr 将文件附带的数字与位于 replmgr.box\history 文件夹中的 CS1.TRS 文件进行比较。由于这是一个站点控制文件复本，因此将在 CS1.TRS 文件中检查的节是 [SITECTRLCT1SRCSITE] ：

这是 PS1 站点中 CS1.TRS 文件的屏幕截图。因此，如果收到的文件附带的值小于 1112，将拒绝该文件。另请注意，此文件的滚动条将根据大小进行调整。

要验证 PS1 站点的 CS1.TRS 文件中是否有最新的更新数字，我们可以检查 CS1 站点中的“复制 ID 注册表”（在前面提到的路径中）。此注册表的屏幕截图如下所示：

我们看到，在 CS1 站点注册表中有数字 1113 （增量为 1）。这还意味着，下一个到任何其他站点的基于事务的复制都将包含数字 1113。

重要说明： 就此层次结构示例而言，PS1 站点的 CS1.TRS 文件中任何存储对象的数字都不能大于数字 1113 （当然假定站点是工作站点）。 

.TRS 文件的格式

一个 .TRS 文件包含许多节。基本格式如下所示：

 这里，分配给每个对象的数字是上次复制对象时（对象中上次修改的更改）发送站点的复制 ID 注册表数字。

 下面是 PS1 站点的 CS1.TRS 文件的示例：

请考虑一个 [CIOBJHANDLER] 节的示例，我们可以看到上次将对象 BB727F46-94A3-4D23-9704-DDE66A3674BB 复制到 PS1 站点的时间就是 CS1 站点的复制 ID 为 163 时。

常见问题解答

注意：所有问题都假定您较好地理解了前面提到的层次结构。

1.接收站点是否必须具有 .TRS 文件？

是。在从发送方站点收到对象的序列号数据时，需要使用此文件存储这些数据。

2.如果从 PS1 站点中删除 CS1.TRS 会发生什么情况？CS1 到 PS1 的站点间复制是否会中断，是否会重新创建 CS1.TRS 文件？如果重新创建，那么创建的位置和方式是怎样的？

是的，将在 PS1 站点中创建一个新的 CS1.TRS 文件，但仅包含从现在开始复制的新数据。例如，PS1 站点上原来的 CS1.TRS 文件大约 4 MB，它包含有关所有包、CI 和公布的信息，而新创建的文件只有几个字节，包含关于 [SITECTRLCT1SRCSITE] 节的信息，该节是站点控制文件复本。

详细说明：

首先要注意的是，PS1 站点上的 CS1.TRS 文件大小随着时间的推移而逐渐增长。这是由于 CS1 站点中的更改所致，如创建包、公布、同步 CI 等。

每当从 CS1 复制任何对象时，都会在复制该对象时为其提供 CS1 站点的复制 ID，这意味着 CS1.TRS 文件中任何存储对象的序列号在任何时间点都将包含不同的序列号，具体取决于它们被同步的时间，但所有数字中的最大数字始终小于中心站点的复制 ID。

3.从 PS1 站点删除 CS1.TRS 文件会有什么后果？

在删除 PS1 站点服务器上的 CS1.TRS 文件之后，将处理从 CS1 站点服务器接收的第一个基于事务的复制作业，并将事务 ID 记录到 PS1 站点中新的 CS1.TRS 文件。这可能导致不按顺序处理复制作业，因为处理的复制作业不一定是删除该文件后发送到 PS1 站点服务器的第一个作业（我们没有与最新的 ID 比较的信息）。如果不按顺序处理复制作业，可能会丢弃有效的复制作业。

4.如果新 CS1.TRS 文件仅包含新信息，那么以前的信息呢？在复制时如何检查其他对象？

答案是我们已经丢失该数据。但这不会影响站点之间的通信流。如前一问题中所述，当 CS1.TRS 中不存在某个对象时，将使用其附带的最新复制 ID 插入该对象，且不进行任何验证检查，因为 CS1.TRS 文件中无任何数据。仅当再次复制同一对象之后（对象在 CS1 站点中更改），CS1.TRS 文件中才有数据，在这里将检查附带的数字是否大于 CS1.TRS 站点中的值，如果大于，将接受该文件，并使用最新值更新 CS1.TRS。这意味着，即使删除了文件，它也会随着对象的复制而增长。

5.我已经还原了我的 PS1 站点，现在我发现文件被 CS1 站点和 SS1 站点拒绝。如何使 PS1 站点恢复正常？

首先要注意的是，如果还原 PS1 站点，将不会拒绝到 PS1 站点的入站连接，这是因为 CS1.TRS 文件或 SS1.TRS 中对象的值仍早于 CS1 和 SS1 站点的当前复制 ID 注册表值。受到阻碍的通信是出站连接（即指向 CS1 和 SS1 站点的连接）。这是因为 CS1 站点和 SS1 站点的 PS1.TRS 文件中存储的对象的值大于 PS1 站点的当前复制 ID 注册表值（由于它已被还原）。因此，从 PS1 站点复制到 CS1 或 SS1 的任何文件都将被拒绝。

要解决此问题，您有两种选择：

选项 1：

从其连接的所有站点删除 PS1.TRS 文件。这里，连接的站点是 CS1 和 SS1。现在的问题是如何修复此问题。由于从 CS1 和 SS1 站点中都删除了 PS1.TRS 文件，这将导致在两个站点创建新的 PS1.TRS 文件。每当从 PS1 站点向 CS1、SS1 复制对象时，都会使用复制 ID 的当前条目创建一个条目，仅在同一对象的第二次复制之后才进行复制检查。

为什么这不是一个优秀的解决方案？

如问题 2 中所述，我们已经知道删除 .TRS 文件的后果。而且，如果 PS1 站点有许多辅助站点，那么到每个站点然后从 replmgr\history 文件夹中删除 PS1.TRS 文件会很麻烦。

选项 2：

将 PS1 站点中的复制 ID 注册表更改为大于连接到 PS1 站点的任何站点的 PS1.TRS 中任何对象的任何值。增大该值将导致新对象的值大于任何站点（CS1、SS1）的 PS1.TRS 文件中存储的值。

但这里出现一个巨大的问题：如何知道选择哪个数字会大于为 CS1 和 SS1 站点的 PS1.TRS 文件中的任何对象存储的任何值？而且，如果站点数量较多，这将变得不可操作。您不能打开每个 PS1.TRS 来查找最大数字。

那么在此情况下该怎么办呢？达到某个数字以便在注册表中更改此值的常见方法如下所示：

当恢复使用 SMS 备份或 ConfigMgr 备份还原的站点时，将站点停机的天数乘以 1,000，然后将其添加到事务 ID 的当前值。

当不使用 SMS 备份或 ConfigMgr 备份恢复站点时，如果层次结构中只有几个站点，则打开已恢复站点的父站点和所有子站点上的 \SMS\Inboxes\Replmgr.box\history\sitecode.trs 文件，并查找最大数字。在此数字上加 20。如果层次结构中有许多站点，则打开其他站点上 \SMS\Inboxes\Replmgr.box\history\ sitecode.trs 文件的 5-10% 随机样本，查找最大数字。使用父站点和子站点作为参考。确保您的示例站点已连接到与任何其他站点一样新的恢复站点；在这些计算机上的资源管理器中检查客户端代理时间，因为它们也是客户端。在 .TRS 文件中发现的最大数字应增加一倍或增加 100 万，以增幅较少的为准。

问题 3 和问题 5 的参考内容：

https://blogs.technet.com/b/configurationmgr/archive/2010/07/15/new-deep-dive-document-component-details-and-data-flow-for-site-to-site-replication-in-sms-2003-and-configuration-manager-2007.aspx

希望此内容能提供一些帮助！

Umair Khan | System Center Configuration Manager 支持工程师

在 Facebook 和 Twitter 上获取 System Center 的最新新闻：

App-V 团队博客：https://blogs.technet.com/appv/
ConfigMgr 支持团队博客：https://blogs.technet.com/configurationmgr/
DPM 团队博客：https://blogs.technet.com/dpm/
MED-V 团队博客：https://blogs.technet.com/medv/
Orchestrator 支持团队博客：https://blogs.technet.com/b/orchestrator/
Operations Manager 团队博客：https://blogs.technet.com/momteam/
SCVMM 团队博客：https://blogs.technet.com/scvmm
Server App-V 团队博客：https://blogs.technet.com/b/serverappv
Service Manager 团队博客：https://blogs.technet.com/b/servicemanager
System Center Essentials 团队博客：https://blogs.technet.com/b/systemcenteressentials
WSUS 支持团队博客：https://blogs.technet.com/sus/

Forefront Server Protection 博客：https://blogs.technet.com/b/fss/
Forefront Endpoint Security 博客：https://blogs.technet.com/b/clientsecurity/
Forefront Identity Manager 博客：https://blogs.msdn.com/b/ms-identity-support/
Forefront TMG 博客：https://blogs.technet.com/b/isablog/
Forefront UAG 博客：https://blogs.technet.com/b/edgeaccessblog/