了解公用文件夹复制
**适用于：**Exchange Server 2010
**上一次修改主题：**2009-12-07
**“公用文件夹复制”是在多个服务器之间复制公用文件夹的内容和层次结构所执行的过程，可以提高效率和容错能力。如果分别位于各个独立服务器上的多个公用文件夹数据库都支持一个单一公用文件夹树，则 Microsoft Exchange 将使用公用文件夹复制保持数据库同步。公用文件夹内容只存在于配置为包含特定文件夹副本的 Exchange 存储中。内容和层次结构信息是分别复制的。每个公用文件夹数据库都保留层次结构的一个副本，其中包含保留了每个文件夹的内容副本的其他公用文件夹数据库的列表。内容副本只存在于指定的公用文件夹数据库中。有关如何配置公用文件夹复制的详细信息，请参阅配置公用文件夹复制。
备注
与 Exchange Server 2007 中不同的是，不能在 Exchange Server 2010 中使用连续复制来复制公用文件夹。在 Exchange 2010 中，连续复制仅适用于邮箱数据库。公用文件夹数据库可以托管在数据可用性组 (DAG) 中的邮箱服务器上，但必须针对数据冗余使用多个公用文件夹数据库和公用文件夹复制。
公用文件夹数据库复制以下两种类型的公用文件夹信息：
层次结构 当修改了文件夹属性和与文件夹有关的组织信息时，就会进行层次结构复制。所有公用文件夹数据库都有层次结构信息的副本。修改以下公用文件夹信息将导致层次结构复制：
文件夹名
副本列表
文件夹在公用文件夹树（包括所有父文件夹和子文件夹）中的位置。
权限
备注
更改启用邮件的公用文件夹的电子邮件地址时，不会进行层次结构复制。该电子邮件地址存储在 Active Directory 中的目录对象上。只有更改公用存储数据库内部的属性才会进行层次结构复制。
内容 当邮件发送到公用文件夹或添加了数据时，就会进行内容复制。例如，向启用邮件的公用文件夹发送电子邮件或向公用文件夹添加组织表单都会导致发生内容复制。要复制内容，必须配置一个文件夹，以将其内容复制到特定公用文件夹数据库或数据库列表。只有指定的数据库才拥有内容的副本。包含内容的文件夹的副本称为内容副本。
目录
公用文件夹复制的工作方式
复制邮件
回填请求与回填邮件
复制周期示例
实现复制的最佳做法
若要了解与公用文件夹相关的管理任务，请参阅管理公用文件夹。
公用文件夹复制的工作方式
当修改公用文件夹或其内容时，包含已更改的该公用文件夹副本的公用文件夹数据库，会向驻留该公用文件夹副本的其他公用文件夹数据库发送一封描述性电子邮件。为减少网络上的通信，Exchange 将在一封电子邮件中包含多个更改的信息。这些邮件中所含的信息量取决于为复制邮件设定的大小限制。如果有邮件超出了指定的大小限制，则会将此邮件作为一封单独的复制邮件发送。Exchange 路由这些复制邮件的方式与其路由他电子邮件的方式相同。
如果更改公用文件夹层次结构影响到多个文件夹，则复制过程可能需要相当大的网络带宽。例如，要在服务器之间移动公用文件夹，则必须在公用文件夹要移至的目标服务器上创建副本，然后等待将层次结构更改复制到原始服务器，再等待将内容复制到新副本。同步各副本后，必须将这些副本从旧服务器上删除。因为删除副本必须作为层次结构更改进行复制，所以即使从旧服务器删除副本也会产生网络通信。有关对公用文件夹层次结构所做的这些更改如何影响系统的详细信息，请参阅本主题稍后部分介绍的“状态请求与状态邮件”部分。
层次结构复制和内容复制基本过程
下图以及随附的说明性文字描述了复制公用文件夹层次结构和公用文件夹内容的基本过程。
基本复制过程
.gif "基本过程公用文件夹复制")
该过程的详细情况如下：
- 用户修改公用文件夹。
- 本地公用文件夹数据库记录此更改。
- 在制定的下一个复制周期（由您为公用文件夹数据库设置的复制间隔确定）内，公用文件夹数据库将检查文件夹属性，以确定哪些服务器包含此公用文件夹的副本。如果存在其他副本，该数据库将确定必须向这些服务器复制哪些信息。此信息将成为副本的更新。
公用文件夹复制是基于对象的。如果修改了对象的某个属性，则必须复制整个对象。因为复制此更改的数据库不能认定收到的所有副本都是最新的，所以它必须复制整个对象。不同复制类型的含义如下：- 层次结构复制 当创建或删除公用文件夹时，或更改公用文件夹属性（例如，更改副本列表、客户端权限、描述、管理注释或存储限制）时，就会复制新层次结构更改。
- 内容复制 如果投递了一封新邮件或修改了现有邮件，则更新将包含整个邮件及其属性。
- 公用文件夹数据库为更新分配更改编号。
当文件夹将某个更新复制到其他服务器时，此更新将随附更改编号。随后，接收服务器使用此更改编号确定该更新是否代表新的更改，以及服务器是否缺少数据。 - 公用文件夹数据库将更新打包到复制邮件中。此邮件中所有更新的更改编号称为更改编号集 (CNSet*)*。
公用文件夹数据库将复制状态表中的文件夹项信息（包括以前应用于副本的 CNSet）随更新一起打包。有关复制状态表的详细信息，请参阅本主题稍后部分介绍的“复制状态表”部分。 - 为减少邮件通信，公用文件夹数据库将多个层次结构更新打包到一封复制邮件中。同样，该数据库还会将同一文件夹的多个内容更新打包到一封复制邮件中。但是，该数据库不能将层次结构更新与内容更新打包到同一封复制邮件中，并且每封内容复制邮件都只能包含一个文件夹的更新。
- 公用文件夹数据库将复制邮件发往包含更新文件夹副本的其他公用文件夹数据库。该数据库将此邮件连同自上一个复制周期起打包的所有其他邮件一起发送。
公用文件夹数据库依靠 Exchange 中的内部路由组件传递复制邮件。该数据库不会试图拆分基于拓扑详细信息的复制邮件。如果修改了文件夹的内容并且该文件夹有五个其他副本，则数据库将生成一封复制邮件，然后将其发往包含这些副本的所有五个数据库。路由组件确定如何路由和传递邮件。 - 公用文件夹数据库接收复制邮件。
- 接收公用文件夹数据库将来自复制邮件的更新信息和状态信息解包。
- 该数据库将新更新的更改编号与其已包含的更改编号列表进行比较，并随后找出以前没有收到过的更新。
- 该数据库将新更新应用到对应的文件夹副本。
- 对于每个已更新的副本，该数据库使用当前更新的更改编号和来自复制邮件的文件夹状态信息更新复制状态表。
如果复制状态表中的信息表明除此数据库中的副本以外，已对该文件夹的其他副本应用了其他 CNSet，则此数据库将在称为**“回填数组”的位置记录缺少的 CNSet，然后准备发送回填请求。有关回填请求的详细信息，请参阅本主题稍后部分介绍的“回填请求与回填邮件”部分。
返回顶部
复制邮件
复制过程使用公用文件夹数据库的 Active Directory 属性，而不是各个公用文件夹的 Active Directory 属性。各个公用文件夹的 Active Directory 属性仅用于在各文件夹间发送和接收常规电子邮件。公用文件夹数据库对象是自动配置和维护的，驻留在 Active Directory 的“配置”容器中。
复制邮件与其他电子邮件的不同之处在于，Exchange 将复制邮件视为系统邮件。这意味着复制邮件不受对用户电子邮件施加的限制（如大小和传递限制）束缚。
下表列出了 Exchange 所用的各种复制邮件类型。
备注
下表中圆括号内列出的值代表用十六进制表示法表示的邮件类型。这些表示法用于事件和日志中。您可以使用此十六进制值解决复制问题。
公用文件夹复制邮件类型及使用场合
| 邮件类型* | 使用场合 |
|---|---|
层次结构 (0x2) |
将层次结构更改从本地公用文件夹数据库复制到支持相同层次结构的所有其他公用文件夹数据库时使用此类型。尽管 Exchange 会分别处理层次结构更改和内容副本更改，但它将层次结构视为另一个文件夹。在一些事件消息和其他操作中，Exchange 将层次结构视为文件夹 1-1。 |
内容 (0x4) |
将内容更改从一个副本复制到该文件夹的所有其他内容副本时使用此类型。内容邮件仅包含应用于单个文件夹的信息。 |
回填请求 (0x8) |
从另一数据库请求 CNSet 中缺少的数据时使用此类型。这包括层次结构和内容更改编号。 |
回填反应（0x80000002 或 0x80000004） |
将 CNSet 中缺少的数据发送到请求缺少的更新的数据库。 |
状态 (0x10) |
将某个文件夹的当前 CNSet 发送到该文件夹的一个或多个副本时使用此类型。这包括层次结构和内容更改编号。 |
状态请求 (0x20) |
请求复制 CNSet 或返回状态邮件时使用此类型。这包括层次结构和内容更改编号。 |
复制状态表
每个公用文件夹数据库都维护一个复制状态表，用以跟踪数据库中每个副本的状态。复制状态表存储以下信息：
- 构建针对每个副本的更新所需的基本信息。
- 来自本地数据库的关于每个副本的上次更新的信息，包括更新的更改编号。
- 已应用到文件夹的所有其他已知副本的更新组。更改编号标识每个组中的更新。组中所有更新的更改编号集称为 CNSet。在复制过程中，更新信息从一个数据库传递到另一个数据库。
以下各表提供了说明复制状态表如何工作的示例。在此示例中，服务器 A 和服务器 B 上的公用文件夹数据库都具有名为 Projects 的文件夹的副本。在每个服务器上，复制状态表不仅跟踪该服务器上副本的状态，还跟踪其他服务器上副本的状态。使用此信息，服务器 A 可以确定其 Projects 文件夹的副本是否已与服务器 B 上 Projects 文件夹的副本同步。服务器 B 同样能够跟踪其相对于服务器 A 的状态。
来自服务器 A 的复制状态表的示例数据
| 副本 | 数据 |
|---|---|
服务器 A 上的 Projects 文件夹 （本地副本） |
上一次更新发送时间：A-100 |
服务器 B 上的 Projects 文件夹 |
已接收 A-100 已接收 B-50 |
来自服务器 B 复制状态表的示例数据
| 副本 | 数据 |
|---|---|
服务器 A 上的 Projects 文件夹 |
已接收 A-100 已接收 B-50 |
服务器 B 上的 Projects 文件夹 （本地副本） |
上一次更新发送时间：B-50 |
通过将包含内容副本的公用文件夹数据库列表与复制状态表中的信息相结合，每个公用文件夹数据库都能够确定自己有多新（与支持公用文件夹树的其他公用文件夹数据库相比而言）。
返回顶部
回填请求与回填邮件
当公用文件夹数据库确定自己尚未收到复制文件夹（或层次结构）的所有更新，因而必须从另一公用文件夹数据库检索缺少的更新时，将进行**“回填”。
为减化回填过程，Exchange 将缺少的更新的相关信息存储在回填数组中。
下列事件可能表示公用文件夹数据库存在需要回填的缺少的更新：
- 传入复制邮件中的状态信息指示发送此邮件的公用文件夹数据库上的副本具有接收数据库上缺少的更新。接收数据库识别缺少的更改编号并将其存储在自己的回填数组中。
- 公用文件夹数据库首次启动。新数据库发送状态请求，请求获得层次结构中其他数据库的相关信息。收到相应的状态邮件后，该数据库填充其复制状态表，如有必要，还会填充回填数组。回填数组可能同时包含该数据库必须承载的层次结构和所有内容副本的条目。
- 传入层次结构邮件指示新内容副本将置于公用文件夹数据库中。新数据库发送状态请求，请求获得可能适用于层次结构中其他数据库中此副本的内容的相关信息。收到相应的状态邮件后，该数据库会填充复制状态表，如有必要，还会填充回填数组。
回填数组存储此信息并将存储的信息保留到指定的时间长度（称为回填超时）。如果在这期间，缺少的更新在后续复制邮件中到达，则会从回填数组中删除这些更新。下表列出了默认的回填超时值，该值取决于缺少的更新所处的位置及以前是否请求过这些更新。
用于回填请求的默认超时
| 请求类型 | 位于本地 Active Directory 站点中的数据库中的内容 | 位于远程 Active Directoty 站点中的数据库中的内容 |
|---|---|---|
初始回填 |
6 小时 |
12 小时 |
首次回填重试 |
12 小时 |
24 小时 |
后续回填重试 |
24 小时 |
48 小时 |
如果回填超时过期，但仍然缺少更新，Exchange 会创建一个或多个回填请求，并确定将哪个服务器作为回填源。
为选择用作回填源的服务器，Exchange 首先创建具有该文件夹的副本的所有服务器列表，然后根据以下条件序列对列表排序：
- 根据服务器状态排序。出现故障的或不可用的服务器将排在列表的底部。
- 根据首选回填服务器（如果存在）排序。Exchange 将检查 Active Directory 中的公用文件夹数据库对象以寻找首选回填服务器。此设置很少使用。大多数情况下，如果 Exchange 自动选择回填服务器，回填过程运行的效率会很高。Exchange 的大多数部署都无需首选回填服务器。如果部署需要回填服务器，Microsoft 客户服务和支持部门可以提供一个用于设置首选回填服务器的脚本。
- 根据传输成本排序（从最低到最高）。同一路由组中的服务器优先级高于远程 Active Directory 站点中的服务器。
- 根据 Exchange 版本排序（从最新到最旧）。
- 根据服务器上提供的必要更改的数目排序（从最大到最小）。没有缺少的更改的服务器排在列表的底部。
如果某个服务器没有任何必要更改，Exchange 将选择存储列表中的下一个服务器，并向该服务器发送回填请求。重复执行此过程，直到请求了所有更改。
如果所选服务器未响应回填请求，数据库会将此服务器标记为不可用，然后重复该选择过程。标记为不可用的服务器将移至列表的底部。
状态请求与状态邮件
除每封复制邮件中的状态信息外，Exchange 还使用状态请求和状态邮件来确定公用文件夹是否必须发出回填请求。
在下列情况下，公用文件夹数据库发送状态请求：
- 数据库被告知包含文件夹副本的数据库列表有改动。例如，如果您向该列表中添加了一个数据库或从该列表中删除了一个数据库，则 Exchange 将使用层次结构更新邮件复制此更改。在这种情况下，该数据库将发送状态请求，要求包含该文件夹副本的每一个数据库都做出响应。
- 新数据库首次启动。在这种情况下，该数据库将请求公用文件夹层次结构的状态。该数据库将发送状态请求，要求支持该公用文件夹树的每一个数据库都做出响应。
- 还原完成之后，使用 Windows Server 备份工具还原的数据库将首次启动。在这种情况下，此数据库请求公用文件夹层次结构的状态，以及此数据库中包含其内容副本的所有文件夹的状态。此状态请求列出了两个或三个数据库作为必要响应方。必要响应方是支持此层次结构的数据库，根据内部选择过程，这些数据库还是文件夹内容的可靠来源。
为指示发送数据库上特定文件夹的当前状态，在下列环境下，公用文件夹数据库会向其他数据库发送一封状态邮件：
- 响应另一个数据库发送的状态请求。状态邮件只发送给请求数据库，而且仅在满足下列条件时才发送：
- 接到状态请求的数据库在必要响应方请求列表中。
- 复制状态表指示，接收状态请求的数据库具有发送请求的数据库缺失的更新。
- 自文件夹最近一次收到更新的时间算起，24 小时内没有后续更新。数据库每次收到针对特定文件夹的更新时，计时器都重设为 24 小时。此状态邮件将被发送到包含更新文件夹副本的其他公用文件夹数据库。
如果公用文件夹数据库收到一封状态邮件，该邮件指示发送数据库具有关于该文件夹的更新的信息，则接收数据库将创建一个回填请求。如果显示的更改编号相同（或接收服务器上的更改编号更新），则不执行任何操作。例如，当新公用文件夹数据库首次运行时，会将状态请求邮件发送到支持该公用文件夹层次结构的每个数据库。每个数据库都会做出响应，提供关于该层次结构的状态（该数据库所跟踪的）的信息。新数据库使用此信息确认自身应具有哪些副本（如果存在）。然后，新数据库会根据需要发送回填请求以填充副本内容。
返回顶部
复制周期示例
下图说明了一个简化的两服务器方案，此方案显示在将内容副本添加到公用文件夹数据库时所发生的事件的序列。此操作向文件夹的副本列表添加公用文件夹数据库。请注意，步骤序列取决于复制间隔的时间选择和路由拓扑等因素。
向公用文件夹数据库添加副本时的事件序列
.gif "将公用文件夹副本添加到层次结构")
该过程的详细情况如下：
- 处理 ExServ01 时，管理员将 ExServ01 添加到文件夹的副本列表。
- ExServ01 发送层次结构邮件。
- ExServ02 将 ExServ01 添加到文件夹的副本列表的本地副本。
- ExServ01 向 ExServ02 发送状态请求。
- ExServ02 将状态邮件发送到包含该文件夹的完整 CNSet 的 ExServ01。
- ExServ01 确定缺少该文件夹的所有内容并在回填数组中记录相应条目。
- 如果回填超时已过，但仍然缺少内容，ExServ01 会创建回填请求并将其发送到 ExServ02。
- ExServ02 编译内容邮件并将其发送到 ExServ01。
- ExServ01 使用传入内容邮件更新文件夹内容和相关的跟踪信息。
- 如果仍会显示缺少更改编号，ExServ01 会等待 24 小时，然后发送更新的回填请求。如果除 ExServ02 外还有可用的服务器，ExServ01 可能会将请求发送到该服务器。
下图说明了一个简化的双服务器方案，此方案显示从公用文件夹数据库删除副本时所发生的事件的序列。（此操作将从文件夹的副本列表删除公用文件夹数据库。）请注意，步骤序列取决于拓扑中服务器的数量等因素。
从公用文件夹数据库删除副本时的事件序列
.gif "从公用文件夹数据库中删除副本")
该过程的详细情况如下：
- 处理 ExServ01 时，管理员将 ExServ01 从文件夹的副本列表中删除。
- ExServ01 将它的副本（ExServ01 上的文件夹副本）标记为“延迟删除”。
客户端不再能使用此数据库访问该文件夹。 - ExServ01 发送层次结构邮件。
- ExServ02 更新其该文件夹的副本列表的副本，以显示该文件夹在 ExServ01 上处于延迟删除状态。
ExServ02 不再向 ExServ01 提交正在查找此文件夹的客户端。 - ExServ01 向 ExServ02 发送状态请求。
- ExServ02 向 ExServ01 发送状态邮件。如果 ExServ02 上的副本不是最新的，则 ExServ02 会将相应条目添加到回填数组中。ExServ02 在 5 分钟内向 ExServ01 发送相应的回填请求。
- ExServ01 检查 ExServ02 上的文件夹副本是否包含延迟删除副本包含的所有信息。如果未包含，ExServ01 将发送相应的内容更新并返回到步骤 5。否则，ExServ01 继续执行步骤 8。
此过程确保了只要其他副本存在，删除一个副本就不会导致内容丢失。 - ExServ01 将其副本标记为“立即删除”****。下一维护周期中将从 ExServ01 中删除此副本。
- ExServ01 发送层次结构邮件。
- ExServ02 从其文件夹副本列表的副本中删除 ExServ01。
返回顶部
实现复制的最佳做法
Exchange 中的公用文件夹复制可能是一项非常耗费资源的操作。复制操作需要用到网络、CPU 和磁盘资源。实施启用高效公用文件夹复制的解决方案，可能会显著增加 Exchange 组织中网络、CPU 和磁盘的负载，在公用文件夹使用率很高的组织中尤其如此。
通常，最佳做法是将整个组织中的复制降到最少。通过将复制降到最少，可以将通过网络传输的数据量降到最低。此外，将复制降到最少还有助于减少多个用户从多个副本上访问到不同版本的数据的情况。但请注意，将复制降到最少会降低公用文件夹数据的可用性，这是因为公用文件夹数据库失败时，可供客户端使用的文件夹副本少了。如果特定公用文件夹中的数据要求具有大范围的可用性，就需要进行更多的复制。
返回顶部