SCR is a new feature introduced in Exchange 2007 SP1. SCR extends the existing continuous replication features in Exchange 2007 RTM and enables new data availability scenarios for Exchange 2007 Mailbox servers. SCR uses the same log shipping and replay technology used by local continuous replication (LCR) and CCR to provide added deployment options and configurations. SCR is similar to LCR and CCR, but it has unique characteristics of its own:

• SCR supports multiple targets per storage group. LCR and CCR support only one replication target per storage group (the passive copy).
  
• SCR enables an administrator to specify a lag time for replication. This is useful in a variety of scenarios. For example, in the event of a lossy failover from NodeA to NodeB, if the lost log files have been replayed on remote NodeM, NodeM would need to be reseeded. However if the logs were copied but not replayed, they may be deleted, and new log files can then be copied and later replayed. In this event, no reseed of the copy on NodeM would be needed.
  
• Unlike CCR and LCR, you cannot back up an SCR copy. When using SCR, the database headers for SCR copies are updated, and the log files are truncated when backups are taken against the source storage group.
  

SCR enables you to use continuous replication to replicate Mailbox server data from a stand-alone Mailbox server, or from a clustered mailbox server in an SCC or CCR environment.

The process for activating copies of Mailbox server data that are created and maintained by SCR is manual and is designed to be used when a significant failure occurs (and not for simple server outages that are recoverable by a restart or some other quick means). You can activate an SCR target using database portability, the server recovery option (Setup /m:RecoverServer), or if the Mailbox server is clustered, the clustered mailbox server recovery option (Setup /RecoverCMS). The option you choose will be based on your configuration and the type of failure that occurs.

For more information about SCR, see Standby Continuous Replication.

Windows Server 2008 includes new high availability features that are supported by Exchange 2007 SP1. In Windows Server 2008, the improvements to failover clusters (known as server clusters in Windows Server 2003 and earlier versions) are aimed at simplifying clusters, helping to make them more secure, and enhancing cluster stability. In addition, cluster setup and management has been made easier, and the underlying cluster security, networking, and storage components have been improved. For a complete list of the improvements in failover clusters, see Failover Clustering with Windows Server 2008.

In addition to supporting Windows Server 2008 as an operating system platform, Exchange 2007 SP1 also introduces support for the following Windows Server 2008 failover cluster features. Support for these features has also been integrated into Exchange 2007 Setup for both the command-line version (Setup.com) and the graphical user interface (GUI) version (Setup.exe, also known as the Exchange Server 2007 Setup wizard).

 Support for Multiple Subnet Failover Clusters

Windows Server 2008 failover clustering introduces new networking capabilities that are a major shift away from the way things have been done in legacy clusters. For example, Windows Server 2008 failover clusters introduce support for multiple subnets. When running in a Windows Server 2008 failover cluster, Exchange 2007 SP1 includes support for geographically dispersed clusters for failover across two subnets. This support includes both SCCs, as well as Mailbox servers in a CCR environment.

Beginning with Windows Server 2008 failover clustering, individual cluster nodes can now be located on separate, routed networks. This requires that resources that depend on IP Address resources (for example, Network Name resources), implement an OR logic because it is unlikely that every cluster node will have a direct local connection to every network that the cluster knows about. This facilitates IP Address and Network Name resources coming online when services or applications fail over to remote nodes.

Important:
All nodes in an SCC or CCR environment must be in the same Active Directory site. Although Windows Server 2008 failover clusters introduce support for cluster nodes to be members of different Active Directory sites, this configuration is not supported by Exchange 2007.

When using multiple subnet failover clusters, IP addresses associated with a Network Name resource will be dynamically registered in the Domain Name System (DNS) (if configured for dynamic updates) when they are brought online. Therefore, only those IP Address resources that are online are returned to clients. Because cluster nodes can be placed on different, routed networks, and the communication mechanisms have been changed to use reliable session protocols implemented over User Datagram Protocol (UDP) (unicast), the networking requirements for Windows Server 2003 geographically dispersed clusters are no longer applicable in Windows Server 2008. As a result, organizations can deploy an SCC or CCR environment across two physical datacenters without having to use virtual LAN (VLAN) technology to span the subnets.

When a move or a failover occurs for a clustered mailbox server deployed in a geographically dispersed, multiple subnet failover cluster, the name of the clustered mailbox server is maintained, but the IP address assigned to that name is not maintained. The availability of this server to clients and other servers will depend on propagation of the new IP address throughout DNS. It may take some time for DNS propagation to occur. For this reason, we recommend configuring a Time to Live (TTL) value for the clustered mailbox server DNS host record to 10 minutes.

Although internal Microsoft Outlook clients do not need new or reconfigured profiles to connect using the new IP address, they will need to wait for their local DNS cache to be cleared so that name resolution of the clustered mailbox server's name will move from its old IP address to its new IP address. After the IP address has been propagated to the appropriate DNS servers, the DNS cache on the Outlook clients can be cleared by using the following command at the command line on the client.

ipconfig /flushdns

 Support for DHCP-IPv4

In Windows Server 2008 failover clustering, the capability exists where cluster IP Address resources can obtain their addressing from DHCP servers, as well as via static entries. If the cluster nodes themselves are configured to obtain their IP addresses from a DHCP server, the default behavior will be to obtain an IP address automatically for all cluster IP Address resources. If the cluster node has statically assigned IP addresses, the cluster IP Address resources will have to be configured with static IP addresses as well. Thus, cluster IP Address resource IP assignment follows the configuration of the physical node and each specific interface on the node.

 Support for IPv6

Windows Server 2008 and the Cluster service support IPv6. This includes being able to support IPv6 IP Address resources and IPv4 IP Address resources either alone or in combination in a cluster. In addition, failover clusters also support Intra-site Automatic Tunneling Addressing Protocol (ISATAP), and they support only IPv6 addresses that allow for dynamic registration in DNS (AAAA host records and the IP6.ARPA reverse look-up zone). Currently, there are three types of IPv6 address types: global, site local, and link local. Dynamic DNS registrations will not occur for link local addresses and therefore link local addresses cannot be used in a cluster.

Note:

Using Internet Protocol Version 6 (IPv6) addresses and IP address ranges is supported only when Exchange 2007 SP1 is deployed on a computer that is running Windows Server 2008, both IPv6 and Internet Protocol Version 4 (IPv4) are enabled on that computer, and the network supports both IP address versions. If Exchange 2007 SP1 is deployed in this configuration, all server roles can send data to and receive data from devices, servers, and clients that use IPv6 addresses. A default installation of Windows Server 2008 enables support for IPv4 and IPv6. If Exchange 2007 SP1 is installed on Windows Server 2003, IPv6 addresses are not supported. For more information about Exchange 2007 SP1 support for IPv6 addresses, see IPv6 Support in Exchange 2007 SP1 and SP2.

 Exchange and Failover Cluster Network Configuration

When configuring an SCC or CCR for Exchange 2007 SP1, be aware of the following requirements:

• IPv6 and DHCP IPv4 are supported only on Windows Server 2008. Neither can be used when Exchange 2007 is running on Windows Server 2003.
  
• DHCP IPv6 is not supported by Windows Server 2008 or the Cluster service. As a result, it is also not supported by Exchange 2007. Only system-assigned dynamic IPv6 addresses are supported.
  
• Static IPv6 addresses are supported by Windows Server 2008 and the Cluster service. However, using static IPv6 addresses is contrary to best practices. As a result, Exchange 2007 does not support configuring static IPv6 addresses during setup.
  
• IPv6 tunneling over IPv4 is supported by Windows Server 2008 clustering, but Exchange setup does not enable creating this type of IP Address resource.
  

Setup has been modified in Exchange 2007 SP1 to support the changes described earlier. When you use the Exchange Server 2007 Setup wizard, notice that additional pages and fields are available for configuring cluster IP Address and Network Name resources. In addition, the /NewCMS and /RecoverCMS options for Setup.com have been updated to support several new optional parameters, which are documented in the following table.

Optional parameters for /NewCMS and /RecoverCMS added in Exchange 2007 SP1

Parameter	Description
CMSIPV4Addresses	A comma separated list used to specify one or two static IPv4 addresses for the clustered mailbox server. If two static addresses are specified, they must be on different subnets.
CMSIPV4Networks	A comma separated list used to specify one or two IPv4 cluster network names. These names will be used in the creation of DHCP-IPv4 resources.
CMSIPV6Networks	A comma separated list used to specify one or two IPv6 cluster network names. These names will be used in the creation of IPv6 resources. This parameter can be used with the CMSIPV4Addresses or the CMSIPV4Networks parameters.

Note:
The CMSIPV4Addresses and CMSIPV4Networks parameters are exclusive of each other.

The CMSIPAddress parameter, which was a required parameter for /NewCMS and /RecoverCMS in the release to manufacturing (RTM) version of Microsoft Exchange Server 2007, is still used to specify a single static IPv4 address for the clustered mailbox server. However, in Exchange 2007 SP1, the CMSIPAddress parameter is now optional because specifying any of the four available parameters is sufficient for Setup.

The parameters in the preceding table can be used only on Windows Server 2008.

 New Quorum Models in Windows Server 2008

When network problems occur, they can interfere with communication between cluster nodes. A small set of nodes might be able to communicate together across a functioning part of a network, but they may not be able to communicate with a different set of nodes in another part of the network. This situation can cause serious problems. In this split brain situation, at least one of the sets of nodes must stop running as a cluster, even though the sets of nodes will not have definite information about the states of other nodes.

To prevent problems caused by a split in the cluster, the cluster software requires that any set of nodes running as a cluster must use a voting algorithm to determine whether, at a specific time, that set has quorum. Because a specific cluster has a specific set of nodes and a specific quorum configuration, the cluster will know how many votes constitutes a majority (a quorum). If the number drops below the majority, the cluster stops running. Nodes will still listen for the presence of other nodes, in case another node appears again on the network, but the nodes will not begin to function as a cluster until the quorum once again exists.

The quorum configuration in a failover cluster determines the point at which too many failures will stop the cluster from running. The failures relevant in this context are failures of nodes or, in some cases, a witness disk or witness file share (which contains a copy of the cluster configuration). Windows Server 2008 enables you to choose from among four possible quorum configurations:

• Node Majority   This model is recommended for clusters with an odd number of nodes. It can sustain failures of half the nodes minus 1. For example, a 7-node cluster can sustain 3 node failures.
  
• Node and Disk Majority   This model is recommended for clusters with an even number of nodes. It can sustain failures of half the nodes if the witness disk remains online. For example, a 6-node cluster with a witness disk could sustain 3 node failures. It can also sustain failures of half the nodes minus 1 if the witness disk goes offline or fails. For example, a 6-node cluster in which the witness disk failed could sustain 2 node failures (3-1 = 2).
  
• Node and File Share Majority   This model is designed for clusters with special configurations, and we recommend it for clustered mailbox servers in a CCR environment. This model works in the same way as the Node and Disk Majority model, but instead of a witness disk, it uses a witness file share.
  
• No Majority: Disk Only   This model, although supported, is not recommended. It can sustain failures of all nodes except 1. However, this configuration is not recommended because the disk is a single point of failure.
  

In Exchange 2007 RTM, all transaction log file copying and seeding in a CCR environment occurs over the public network. This configuration has the following limits:

• When the passive node is unavailable for several hours, a significant number of logs can build up that need to be transferred. The movement of those logs should be as rapid as possible when the passive node is available. By copying the logs over the public network, the movement of the logs contends with client traffic. This affects client traffic and slows the resynchronization.
  
• When the public network fails, the failover is lossy, even though the log data is available.
  
• Using an isolated network for log communication allows you to provide security for messaging data without using encryption and experiencing its associated performance penalty.
  
• Log storms may occur under some circumstances. When they occur, the system experiences an unusually high replication burden. This situation could cause client starvation if the log data must be communicated over the same network used to communicate with clients.
  

Not all of these issues will occur with the same frequency. However, the first issue is effectively guaranteed to happen every few months because passive nodes are taken offline for regular maintenance activity.

Exchange 2007 SP1 minimizes the effects of the preceding problems by allowing the administrator to create one or more mixed networks in the cluster (for example, a cluster network that supports both internal cluster heartbeat traffic and client traffic) for log shipping. Exchange 2007 SP1 also enables an administrator to specify a specific network to be used for seeding.

Note:

Cluster networks used for log shipping or seeding must be configured as mixed networks. A mixed network is any cluster network that is configured for both cluster (heartbeat) and client access traffic. In addition, on the network adapter being configured with a continuous replication host name, the administrator must check the Register this connection’s addresses in DNS check box on the Advanced TCP/IP properties dialog. The DNS server used by the network adapter can be located on the public or private network; however, regardless of its location, it must be accessible by both nodes so that host name resolution can occur.

Support for log file copying over a mixed network is configured by using a new Exchange Management Shell cmdlet called Enable-ContinuousReplicationHostName. Similarly, turning off this feature is accomplished using the Disable-ContinuousReplicationHostName cmdlet. After a clustered mailbox server exists in a CCR environment, an administrator can run Enable-ContinuousReplicationHostName on both nodes of the cluster and specify additional IP addresses and host names, which will then be created in dedicated cluster groups that are associated with each node. After this task has been performed, the Microsoft Exchange Replication service will begin using the newly created network for log copying shortly after successful configuration and upon confirming that the new network is operational. If multiple new networks are created, the Microsoft Exchange Replication service will randomly select one of them. If the specified network becomes unavailable, the Microsoft Exchange Replication service will automatically begin using other replication networks, or if none are available, it will begin using the public network for log shipping within 5 minutes. (Microsoft Exchange Replication service network discovery occurs every 5 minutes.) When the preferred replication network is again available, the Microsoft Exchange Replication service will automatically revert back to using it for log shipping. For more information about these cmdlets, see Enable-ContinuousReplicationHostName and Disable-ContinuousReplicationHostName.

Support for seeding over a redundant cluster network is configured using the Update-StorageGroupCopy cmdlet, which has been updated in Exchange 2007 SP1 to include a new parameter called DataHostNames. This parameter is used to specify which cluster network should be used for seeding. For more information about the changes to the Update-StorageGroupCopy cmdlet in Exchange 2007 SP1, see Update-StorageGroupCopy.

After a cluster network has been created for continuous replication, you can use the Get-ClusteredMailboxServerStatus cmdlet to view updated information about cluster networks that have been enabled for continuous replication activity. The new output details include:

• OperationalReplicationHostNames:{Host1,Host2,Host3}
  
• FailedReplicationHostNames:{Host4}
  
• InUseReplicationHostNames:{Host1,Host2}
  

For more information about the changes to the Get-ClusteredMailboxServerStatus cmdlet in Exchange 2007 SP1, see Get-ClusteredMailboxServerStatus.

For more information about enabling cluster networks for continuous replication on Windows Server 2003, see How to Enable Redundant Cluster Networks for Log Shipping and Seeding on Windows Server 2003.

For more information about enabling cluster networks for continuous replication on Windows Server 2008, see How to Enable Redundant Cluster Networks for Log Shipping and Seeding on Windows Server 2008.

For more information about disabling cluster networks for continuous replication, see How to Disable Continuous Replication for a Cluster Network.

Exchange 2007 SP1 also introduces several changes that enhance the manageability of Exchange 2007. These changes improve upon the cluster reporting features in Exchange 2007 RTM and include additional functionality designed for proactive monitoring of continuous replication environments. Specifically, the changes and enhancements correct known deficiencies with the Get-StorageGroupCopyStatus cmdlet, introduce a new cmdlet called Test-ReplicationHealth, and provide greater visibility into the loss window covered by the transport dumpster. For more information about these reporting and monitoring improvements, see Monitoring Continuous Replication.

Performance improvements have been made in Exchange 2007 SP1 that benefit high availability deployments. These improvements include:

• I/O reductions on the disks containing passive copies of storage groups in continuous replication environments   In Exchange 2007 SP1, the design of the continuous replication architecture has been modified so that the database cache is now persisted on the passive node in between batches of log replay activity. The persistence of the database cache between batches of log replay activity enables the Microsoft Exchange Replication service to leverage the database caching features of the Extensible Storage Engine (ESE), which in turn, reduces the amount of disk input/output (I/O) that occurs on the passive copy's logical unit numbers (LUNs). By contrast, in Exchange 2007 RTM, a new database cache was created for each batch of log replay activity, which in some cases made the disk I/O activity on the passive node as much as two or three times the disk I/O on the active node.
  Faster moving of clustered mailbox servers between nodes in a CCR environment   These improvements enable clustered mailbox servers to move between nodes in two minutes or less. This includes moves performed by an administrator (using the Move-ClusteredMailboxServer cmdlet), and failovers that are managed by the Cluster service. To accomplish fast moves in a CCR environment, the databases are taken offline without flushing the database cache. In an SCC, moving the clustered mailbox server takes approximately five minutes. Flushing of the database cache still occurs before the clustered mailbox server is moved. This is an opportunistic flush that allows clients to remain connected to the database. This behavior reduces the amount of downtime that occurs when the clustered mailbox server is moved to another node.
  During the failover process, event ID 9868 is logged two times to indicate the status of the flush operation, and event ID 113 is logged to indicate replication status. These events resemble the following:
  

  Event ID: 9868 Source: MSExchangeIS Category: General Type: Information Description: Attempt to flush cache for server '<MailboxServerName>' completed with 0 storage group(s) failing to reach desired checkpoint depth.

  
  

  Event ID: 9868 Source: MSExchangeIS Category: General Type: Information Description: Attempt to flush cache for server '<MailboxServerName>' completed with 2 storage group(s) failing to reach desired checkpoint depth.

  
  

  Event ID: 113 Source: MSExchangeRepl Category: Move Type: Information Description: Information Store cache flush before moving clustered mailbox server '<MailboxServerName>' did not complete. Data: Storage group '<MailboxServerName>\<StorageGroupName>': checkpoint depth start was 19 and end was 17. Storage group '<MailboxServerName>\<SecondStorageGroupName>': checkpoint depth start was 19 and end was 13.

  
  

The transport dumpster is a feature of the Hub Transport server role. The transport dumpster maintains a queue of messages that were recently delivered to recipients whose mailbox is on a clustered mailbox server in a CCR environment. This queue is bound by the amount of time that mail is kept and the total space used. When a failover is experienced that is not lossless, the clustered mailbox server automatically requests every Hub Transport server in the Active Directory site to resubmit mail from the transport dumpster queue.

In Exchange 2007 SP1, the transport dumpster feature has been improved in the following ways:

• Support for LCR   The transport dumpster now includes support for LCR deployments. Unlike CCR, in which the request for transport dumpster redelivery is an automatic part of the recovery process, the process is manual in an LCR environment. The Restore-StorageGroupCopy cmdlet has been updated in Exchange 2007 SP1 to include the transport dumpster resubmission request. Thus, when an administrator activates a passive copy of a storage group in an LCR environment using the Restore-StorageGroupCopy cmdlet, the transport dumpster submission request occurs as part of the activation process.
  
• Transport dumpster statistics   To better inform an administrator prior to recovering a server that is missing log files, the transport dumpster has been enhanced to include statistical information that provides the current state of all Hub Transport servers that contain messages for an affected storage group. These statistics include the number of messages, as well as the age of the oldest message, available on each Hub Transport server in the Active Directory site. These statistics are viewable when using a new parameter for the Get-StorageGroupCopyStatus cmdlet called DumpsterStatistics. When using this new value, the output for Get-StorageGroupCopyStatus will include transport dumpster statistics from all accessible Hub Transport servers, and a list of Hub Transport servers that are not accessible. Accessible servers will be listed in a multivalued structure called DumpsterStatistics, and inaccessible servers will be listed as a multivalued string called DumpsterStatisticsNotAvailable, as illustrated by the following:
  DumpsterStatistics: {HUB1 (oldest time stamp; number of items in the dumpster; size of dumpster), HUB2 (oldest time stamp; number of items in the dumpster; size of dumpster), HUB3 (oldest time stamp; number of items in the dumpster; size of dumpster)}
  DumpsterStatisticsNotAvailable: {HUB4,HUB5}
  In the preceding example, the oldest time stamp is the time at which the message is received by the Hub Transport server, and not the time at which the message was originally delivered to the Mailbox server.
  The Get-StorageGroupCopyStatus cmdlet also includes a new multivalued structure called OutstandingDumpsterRequests, which includes Hub Transport servers with outstanding requests and the time range (low–high) for outstanding requests, as illustrated by the following:
  OutstandingDumpsterRequests: {HUB1 (time-low;time_high), HUB5 (time_low;time_high)}
  

Exchange 2007 SP1 includes new GUI elements in the Exchange Management Console that are designed to improve the management and configuration experience for clustered mailbox servers. These improvements include:

• Manage Clustered Mailbox Server wizard   This wizard is used to move, stop, or start a clustered mailbox server in both a CCR environment, and in an SCC. The move and stop functionality also includes the optional administrator comment fields, enabling an administrator to input the reason why the clustered mailbox server is being moved or stopped. This wizard is the equivalent of using the following Exchange Management Shell cmdlets:
  
  • Move-ClusteredMailboxServer
    
  • Stop-ClusteredMailboxServer
    
  • Start-ClusteredMailboxServer
    
• Manage continuous replication   Additional user interface controls have been added to the Exchange Management Console that enable an administrator to suspend, resume, update, and restore continuous replication. These controls are the equivalent of using the following Exchange Management Shell cmdlets:
  
  • Suspend-StorageGroupCopy
    
  • Resume-StorageGroupCopy
    
  • Update-StorageGroupCopy
    
  • Restore-StoreGroupCopy
    
  You can use these cmdlets and the corresponding Exchange Management Console tasks to manage continuous replication in both an LCR environment and in a CCR environment.
  

  Note:
  In a CCR environment, the Update Storage Group Copy wizard is available only from the passive node, and the Restore Storage Group Copy wizard is available only from the active node.

• Clustered Mailbox Server tab   A new tab has been added to the Server Properties dialog box for Mailbox servers that exist in a cluster. This information is available for both CCR environments and for SCCs. The new tab provides detailed information about the clustered mailbox server and enables an administrator to configure the value for the AutoDatabaseMountDial property for clustered mailbox servers in a CCR environment. Much of the information displayed on the new tab is also available using the Get-ClusteredMailboxServerStatus cmdlet. For more information about the Clustered Mailbox Server tab, see Server Properties > Clustered Mailbox Server Tab.
  
• Cluster Continuous Replication page   A new page has been added to the Storage Group Properties dialog box for Mailbox servers that are deployed in a CCR environment. The new property page provides detailed information about the status of continuous replication in the cluster. For more information about the Cluster Continuous Replication page, see Storage Group Properties > Cluster Continuous Replication Page.
  

Windows Server 2008 includes several features that have been enhanced or renamed. For information about the feature changes between Windows Server 2003 and Windows Server 2008, see Terminology Changes.