· 算法2：算法2允许你确定旧数据的联机是否比脱机更重要。如果数据库在基于算法1挂载失败，你可以创建检查第二次的时间。可以通过ForcedDatabaseMountAfter属性来配置该等待时间。这个值是以小时为单位的，默认为无限制。

　　重要:

　　当ForcedDatabaseMountAfter设置的时间点到达时，不管是否存储器组是有1个日志滞后，10个日志滞后，或是1000个日志滞后，这些有可能导致大量数据丢失的情况，数据库都会被挂载。正是因为这样，如果服务等级协议(SLA)保证了导致丢失数据的最大值，就不应该使用这个参数。

　　调整传输Dumpster(Transport Dumpster)

　　传输Dumpster是使用本地连续复制(LCR)或CCR时，集线器传输服务器(Hub Transport server)角色必须配置的特性。该特性只能用于LCR和CCR环境。传输dumpster会在非常规故障发生后，提交最近发送的邮件。使用LCR或CCR时，应该总是打开传输dumpster。通过设置每个存储器组可用存储的大小和传输dumpster中保留邮件的时间，传输dumpster的设置在机构范围内生效。

　　集线器传输服务器保留最近发送到CMS的邮件队列。在无损故障转移事件中，CCR自动请求站点的每个集线器传输服务器重新提交传输dumpster中的邮件。在LCR环境中，重新提交请求是Restore-StorageGroupCopy任务的一部分。当重新提交发生时，信息存储自动删除副本，并重新发送丢失的邮件。你可以使用Set-TransportConfig的cmdlet来改变传输dumpster的默认配置信息，配置改变将在存储器组的层次生效。另外，在Exchange 2007 SP1中，你还可以使用Exchange管理控制台(Exchange Management Console)对传输dumpster的值进行设置。

　　我们建议你配置每个存储器组的最大空间(即MaxDumpsterSizePerStorageGroup参数)为能够发送的最大消息的1.5倍。例如，如果最大的消息为10MB，你应该设置MaxDumpsterSizePerStorageGroup参数的值为15MB。对于不存在最大消息空间的机构，我们建议将每个存储器组的最大空间值配置为机构中发送消息平均大小的1.5倍。

　　我们还建议将每个存储器组的最大保留时间(MaxDumpsterTime参数)设置为07.00:00:00，也就是7天。这个时间对于大范围故障发生时而不丢失邮件已经足够了。使用这个传输dumpster特性时，集线器传输服务器还需要额外的磁盘空间来存储传输dumpster队列。需要的磁盘空间大小大约等于MaxDumpsterSizePerStorageGroup乘以含有集线器传输服务器的活动目录站点中使用连续复制的所有邮箱服务器组上的存储器组的数量。

　　验证CCR解决方案

　　完成CCR解决方案的安装后，或是做了很大的配置改变后，我们建议你验证一下CMS的状态是否正常，两个节点的CMS支持配置是否正确。

　　验证CMS状态是否正常的推荐方法是在命令行中运行Test-ReplicationHealth，Get-StorageGroupCopyStatus和 Get-ClusteredMailboxServerStatus 这三个cmdlet命令。

　　· Test-ReplicationHealth的cmdlet是Exchange 2007 SP1中新出现的。这个cmdlet是为主动监测连续复制及其管道而设计的。Test-ReplicationHealth的cmdlet检查复制的各个方面，包括群集服务，存储器组复制及重现状态，为复制系统的提供全面的信息概览。关于Test-ReplicationHealth的这个cmdlet的详细信息，请查阅Test-ReplicationHealth命令。

　　· Get-StorageGroupCopyStatus的cmdlet为每一个存储器组提供当前的复制状态信息。

　　· Get-ClusteredMailboxServerStatus这个cmdlet为CMS提供基本的操作状态信息。

　　验证是否两个节点都能联机CMS的推荐方法是：使用Move-ClusteredMailboxServer的cmdlet命令，使CMS转移到每个节点。在Exchange 2007 SP1中，你还可以使用Exchange管理控制台中的管理群集邮箱服务器向导(Manage Clustered Mailbox Server wizard)在节点之间移动CMS，以验证是否两个节点都能联机CMS。