We also recommend that you follow these best practices for your cluster network:

• Use meaningful names   Building a cluster gives you many opportunities to use meaningful names for cluster nodes, cluster network interfaces, the cluster name, and CMS names. For example, the network used to communicate with other Exchange servers and clients can be called Public. The network used to communicate between the cluster nodes can be called Private. Use names that can be related to each other without having to review a topology map. Another useful convention is to relate the nodes of a cluster to the name of the CMS. For example, use mbx01, mbx01-node1, and mbx01-node2 for the CMS and the two nodes, respectively.
  
• Use private IP addresses for the private network interfaces   For a list of IP address ranges and subnet masks that can be used for the private network interfaces on each node, see the following table.
  

  Address ranges and subnet masks for private network interfaces

  Network / node	IP address range	Subnet mask
  Private / NODE1	10.10.10.10-255	255.255.255.0
  Private / NODE2	10.10.10.11-255	255.255.255.0

Note the following:

• If your public network uses a 10.x.x.x network and 255.255.255.0 subnet mask, we recommend that you use alternate private network IP addresses and a subnet mask.
  
• We do not recommend the use of any type of fault-tolerant adapter or teaming for the private network. If you require redundancy for your private network, use multiple network adapters configured only for cluster use. It is important to verify that your firmware and driver are at the most current revision if you use this technology. For information about compatibility on a server cluster, contact your network adapter manufacturer. For more information about network adapter teaming in failover cluster deployments, see Microsoft Knowledge Base article 254101, Network adapter teaming and server clustering.
  

After you install the Cluster service on the first node, you will find that it takes less time to install it on the second node. This is because the Setup program uses the network configuration settings configured on the first node as a basis for configuring the network settings on subsequent nodes. Before you add and configure the second node, you should validate the cluster configuration. You can verify that the Cluster service is running and the cluster is operational by running Cluster.exe group from a command prompt. It should produce output similar to the following.

C:\>cluster group
Listing status for all available resource groups:
Group                   Node            Status
------------------ ---------------      ------
Cluster Group         <NODEName>        Online

We also recommend that you review the event logs for errors and warnings that might require attention before proceeding. For detailed steps about how to add the second node to the cluster, see How to Create a Windows Server 2008 Failover Cluster for Cluster Continuous Replication.

After cluster communications and network priority have been configured, we recommend that you configure specific tolerance settings for missed cluster heartbeats. Doing so configures the Cluster service monitoring of network connectivity between cluster nodes to be tolerant of minor interruptions. This prevents failovers in some cases where the network outage is brief. We recommend that you configure private and mixed cluster networks on all nodes to account for ten missed heartbeats. This setting level corresponds to approximately 12 seconds.

For detailed steps about how to configure the cluster networking components, see How to Configure Cluster Networks for a Failover Cluster.

There are two deployment scenarios in which exercising outage or recovery options will involve a change of the IP address assigned to the CMS:

• A CMS is deployed in a multiple subnet environment.
  
• A standby cluster is used to recover a failed cluster.
  

In both scenarios, the name of the CMS does not change, but the IP address assigned to the CMS changes. Clients and other servers that communicate with a CMS that has changed IP addresses will not be able to reestablish communications with the CMS until DNS has been updated with the new IP address, and any local DNS caches have been updated. To minimize the amount of time it takes to have the DNS changes known to clients and other servers, we recommend setting a DNS TTL value of five minutes for the CMS Network Name resource.

Note:
In most environments, we recommend setting the DNS TTL value only for the CMS Network Name resource. However, in environments with non-Exchange management tools that connect to the cluster by its name for management purposes, we recommend setting a TTL value of five minutes for the cluster's Network Name resource, as well.

By default, the Cluster service uses a setting of 20 minutes for the DNS TTL value of Network Name resources. Although the DNS management tools can be used to manually adjust the TTL value for the host name directly in the DNS database, the value in the DNS database will be overwritten and set to the Cluster service default of 20 minutes every time the network name registration in DNS is refreshed. A refresh of the network name registration in DNS will occur whenever the CMS is started, moved, or brought back online after a failure or failover.

In Windows Server 2008, a new private property has been added to Network Name resources in failover clusters. The new property is called HostRecordTTL, and you can configure it by using Cluster.exe.

Note:
The property is available only on Windows Server 2008 failover clusters. There is no such property in Windows Server 2003 failover clusters. For failover clusters running Windows Server 2003, the Cluster service default of 20 minutes will always apply.

For detailed steps about how to configure the DNS TTL values for the CMS Network Name resource for use in a multiple subnet CMS or standby cluster deployment, see How to Configure the DNS TTL Value for a Clustered Mailbox Server Network Name Resource.

In the release to manufacturing (RTM) version of Microsoft Exchange Server 2007, all log file copying and seeding occurs over the public network. In Exchange 2007 SP1, any cluster network configured as a mixed network can be enabled for continuous replication activity. This activity includes storage group seeding and reseeding, and log shipping.

In Exchange 2007 SP1, only cluster networks designated as mixed can be enabled for continuous replication. A mixed network is any cluster network that is configured for both cluster (inter-node communication) and client access traffic. Cluster networks configured for cluster access, but not for client access (sometimes referred to as private networks) cannot be enabled for continuous replication.

Support for log shipping over a mixed network is configured using a new cmdlet called Enable-ContinuousReplicationHostName. Similarly, turning off this feature is accomplished using the Disable-ContinuousReplicationHostName cmdlet. After a CMS exists in a CCR environment, an administrator can run Enable-ContinuousReplicationHostName on both nodes of the cluster and specify two IP addresses and host names. After doing this, the system randomly selects a mixed network for log copying after successful configuration and upon confirming that the mixed network is operational.

For detailed steps about how to enable cluster networks for continuous replication activity, see How to Enable Redundant Cluster Networks for Log Shipping and Seeding on Windows Server 2008.

Note:

In addition to the host name, IP address, and cluster group that is created on the failover cluster, each time you run the Enable-ContinuousReplicationHostName cmdlet, you are also creating a computer account in the Active Directory domain that contains the CMS. By default in Windows Server 2008, the maximum number of computer accounts that can be added by a user that has not been delegated domain administrator privileges and has not been granted the Create Computer Objects and Delete Computer Objects access control entries (ACEs) is 10. An Exchange administrator that frequently runs the Enable-ContinuousReplicationHostName and Disable-ContinuousReplicationHostName cmdlets and does not have domain administrator privileges or the aforementioned ACEs could reach the 10 account limit quickly. There are available workarounds for this issue, which are documented in Knowledge Base article 307532, How to troubleshoot the Cluster service account when it modifies computer objects. Additional information can be found in Knowledge Base article 251335, Domain Users Cannot Join Workstation or Server to a Domain.

Seeding and reseeding in a CCR environment is performed using the Update-StorageGroupCopy cmdlet. In Exchange 2007 SP1, this cmdlet has been extended to include a new parameter called DataHostNames. This parameter is used to specify which network should be used for seeding or reseeding. The value is a multiple valued list of two names: either a fully qualified domain name (FQDN) or a host name. One of these names must identify the passive node.

CCR includes attributes that let you control the failover behavior of a CMS. You can configure these attributes by using the Set-MailboxServer cmdlet. These attributes are provided so that you can control the following two decision algorithms:

• Algorithm 1   Algorithm 1 controls whether a database is mounted at failover time. At failover time, if the database is detected to have lost less than a configured amount of logs, it is automatically mounted. The acceptable number of lost logs can be configured using a value called AutoDatabaseMountDial. This parameter, which is represented in Active Directory by an Exchange Server attribute called msExchDataLossForAutoDatabaseMount, has three values: Lossless, Good Availability, and Best Availability. Lossless is zero logs lost; Good Availability is three logs lost; and Best Availability, which is the default, is six logs lost. For detailed steps about how to configure these values, see How to Tune Mount and Failover Settings for Cluster Continuous Replication.
  
• Algorithm 2   Algorithm 2 lets you determine if it is more important to be online with old data than to be offline. If the database fails to mount based on algorithm 1, you can establish the time to do a second check. The time to wait is configured by the ForcedDatabaseMountAfter attribute. The value is in units of hours with a default of unlimited.
  

  Important:
  When the value for ForcedDatabaseMountAfter is reached, the database will be mounted regardless of whether the storage group copy is 1 log behind, 10 logs behind, or 1,000 logs behind, which could result in significant data loss. For this reason, this parameter should not be used if service level agreements (SLAs) guarantee a maximum on the amount of data loss that can be incurred.

The transport dumpster is a feature of the Hub Transport server role that must be configured when using local continuous replication (LCR) or CCR, and this feature is used only by LCR and CCR environments. The transport dumpster submits recently delivered mail after an unscheduled outage. The transport dumpster should always be turned on when using LCR or CCR. The transport dumpster is enabled organization wide by setting the amount of storage available per storage group and setting the time to retain mail in the transport dumpster.

The Hub Transport server maintains a queue of mail that was recently delivered to a CMS. In the event of a failover that is not Lossless, CCR automatically requests every Hub Transport server in the site to resubmit mail from the transport dumpster queue. In LCR environments, the request for resubmission is performed as part of the Restore-StorageGroupCopy task. When resubmission occurs, the information store automatically deletes the duplicates and redelivers mail that was lost. You can use the Set-TransportConfig cmdlet to change the default configuration settings for the transport dumpster, which are applied at the storage group level. Alternatively, in Exchange 2007 SP1, you can also use the Exchange Management Console to configure the transport dumpster values.

We recommend that you configure the maximum size per storage group (the MaxDumpsterSizePerStorageGroup parameter) to a size that is 1.5 times the size of the maximum message that can be sent. For example, if the maximum size for messages is 10 megabytes (MB), you should configure the MaxDumpsterSizePerStorageGroup parameter with a value of 15 MB. For organizations without maximum message sizes, we recommend that you configure the maximum size per storage group with a value of 1.5 times the size of the average message size sent in the organization.

We also recommend configuring the maximum retention time per storage group (the MaxDumpsterTime parameter) to a value of 07.00:00:00, which is 7 days. This amount of time is sufficient to allow for an extended outage to occur without loss of e-mail. When using the transport dumpster feature, additional disk space is needed on the Hub Transport server to host the transport dumpster queues. The amount of storage space required is approximately equal to the value of MaxDumpsterSizePerStorageGroup multiplied by the number of storage groups on all Mailbox servers using continuous replication in the Active Directory site containing the Hub Transport server.

For detailed steps about how to enable and configure the transport dumpster, see How to Configure the Transport Dumpster.

After you complete the installation of a CCR solution, or after you make significant configuration changes, we recommend that you verify the health and status of the CMS, and that both nodes are correctly configured to support the CMS.

The recommended way to verify the health and status of the CMS is to run the Test-ReplicationHealth, Get-StorageGroupCopyStatus, and Get-ClusteredMailboxServerStatus cmdlets:

• The Test-ReplicationHealth cmdlet is new in Exchange 2007 SP1. This cmdlet is designed for proactive monitoring of continuous replication and the continuous replication pipeline. The Test-ReplicationHealth cmdlet checks all aspects of replication, cluster services, and storage group replication and replay status to provide a complete overview of the replication system. For more information about the Test-ReplicationHealth cmdlet, see Test-ReplicationHealth.
  
• The Get-StorageGroupCopyStatus cmdlet provides current replication status information for each storage group. For detailed steps about how to view the status of storage groups in a CCR environment, see How to View the Status of a Storage Group in a CCR Environment.
  
• The Get-ClusteredMailboxServerStatus cmdlet provides basic operational status for the CMS. For detailed steps about how to obtain basic operational status for a CMS, see How to View the Status of a Clustered Mailbox Server.
  

The recommended way to verify that both nodes are able to bring the CMS online is to use the Move-ClusteredMailboxServer cmdlet to move the CMS to each node. In Exchange 2007 SP1, you can also use the Manage Clustered Mailbox Server wizard in the Exchange Management Console to move a CMS between nodes to verify that both nodes can bring the CMS online.