The following terms apply:

Address Book service

A service on the Client Access server that provides a directory access endpoint for Microsoft Outlook clients.

Continuous replication - block mode

A new form of continuous replication in SP1 whereby as each update is written to the active database copy's active log buffer, it's also shipped to a log buffer on each of the passive mailbox copies. When the log buffer is full, each database copy builds, inspects and creates the next log file in the generation sequence.

Continuous replication - file mode

The name for the original form of continuous replication in the release to manufacturing (RTM) version of Exchange 2010, whereby closed transaction log files are pushed from the active database copy to one or more passive database copies.

Database availability group (DAG)

A group of up to 16 Exchange 2010 Mailbox servers that hosts a set of replicated databases.

Database mobility

The ability of a single Exchange 2010 mailbox database to be replicated to and mounted on other Exchange 2010 Mailbox servers.

Datacenter

An Active Directory site.

Disaster recovery

Any process used to manually recover from a failure. This can be a failure that affects a single item, or it can be a failure that affects an entire physical location.

Exchange third-party replication API

An Exchange-provided API that enables use of third-party synchronous replication for a database availability group instead of continuous replication.

High availability

A solution that provides service availability, data availability, and automatic recovery from failures that affect the service or data (such as a network, storage, or server failure).

Incremental deployment

The ability to deploy high availability and site resilience after Exchange 2010 is installed.

Lagged mailbox database copy

A passive mailbox database copy that has a log replay lag time greater than zero.

Mailbox database copy

A mailbox database (.edb file and logs), which is either active or passive.

Mailbox resiliency

The name of a unified high availability and site resilience solution in Exchange 2010.

RPC Client Access service

A service on the Client Access server that provides a MAPI endpoint for Microsoft Outlook clients.

Site resilience

A manual disaster recovery process used to activate an alternate or standby datacenter when the primary datacenter is no longer able to provide a sufficient level of service to meet the needs of the organization. Also includes the process of re-activating a primary datacenter that has been recovered, restored or recreated. You can configure your messaging solution for high availability and enable site resilience using the built-in features and functionality in Exchange 2010.

Shadow redundancy

A transport server feature that provides redundancy for messages for the entire time they are in transit.

*over (pronounced "star over")

Short for switchovers and failovers. A switchover is a manual activation of one or more database copies. A failover is an automatic activation of one or more database copies after a failure.

Return to top

In Exchange 2010, Exchange is no longer a clustered application, and the cluster resource model is no longer used for Exchange high availability. Exres.dll and all Exchange cluster resources it provided also no longer exist, including clustered mailbox servers. Instead, Exchange 2010 uses its own internal high availability model. Some components of Windows failover clustering are still used, but they are now integrated into other functionality by Exchange 2010.

In Exchange 2010, a database is associated with a single, dedicated log stream, represented by a series of sequentially-named, 1-megabyte (MB) log files. The concept of storage groups has also been removed from Exchange 2010. As a result of these changes, Exchange databases have a dedicated log stream, and no longer share log streams with other databases.

Unlike in previous versions of Exchange, databases are no longer closely tied to a specific Mailbox server. In addition, databases are no longer identified by the Mailbox servers on which they reside, and server names are no longer part of database identities. As a result of these changes, databases are now global objects in Active Directory and in each Exchange organization. When using the Exchange Management Console, databases are now managed from the Mailbox node under the Organization Configuration node.

Each Mailbox server can host a maximum of 100 databases (total combined number of active and passive databases). The total number of databases equals the combined number of active and passive databases on a server. The recovery database doesn't count against the 100 database limit.

The continuous replication technology introduced in Exchange 2007 is also available in Exchange 2010. However, the feature has evolved considerably to support new high availability features and greater scalability. Some of these architectural changes include:

• Because storage groups are removed in Exchange 2010, continuous replication now operates at the database level. Exchange 2010 still uses an Extensible Storage Engine (ESE) database that produces transaction logs replicated to one or more other locations and replayed into one or more mailbox database copies. Each mailbox database can have as many as 16 copies.
  
  
• Log shipping no longer uses Server Message Block (SMB) and Windows file system notifications. Log shipping no longer uses a pull model, where the passive copy pulls a closed log file from the active copy. Instead, the passive copy uses TCP-based notifications to notify the active copy about which log files are required by the passive copy. The active copy then pushes the log files to each configured passive copy through the TCP socket.
  
  
• Exchange 2010 continuous replication uses one administrator-defined TCP port for data transfer. In addition, Exchange 2010 includes built-in options for network encryption and compression for the data stream.
  
  
• Seeding is no longer restricted to using only the active copy of the database. Passive copies of mailbox databases can now be specified as sources for database copy seeding and reseeding.
  
  
• Database copies are for mailbox databases only. For redundancy and high availability of public folder databases, we recommend that you use public folder replication. Unlike CCR, where multiple copies of a public folder database couldn't exist in the same cluster, you can use public folder replication to replicate public folder databases between servers in a DAG.
  
  
• In Exchange 2007, the Microsoft Exchange Replication service was responsible for replaying logs into passive database copies. When the passive copy was activated, the database cache that had been built by the Microsoft Exchange Replication service as a result of replay activity would be lost when the Microsoft Exchange Information Store service would mount the database. This put the database cache in a state known as a cold state. The database cache, which is used to cache read/write operations, is small in size (cold) during this period. Therefore, it has a significantly diminished ability to reduce read I/O operations. In Exchange 2010, the passive copy replay functionality previously performed by the Microsoft Exchange Replication service has been moved into the Microsoft Exchange Information Store service. As a result, a warm database cache is present and immediately available for use after a failover or switchover occurs.
  
  

Several concepts used in Exchange 2007 continuous replication also remain in Exchange 2010. These include the concepts of failover management, divergence, the use of the automatic database mount dial, and the use of replication and client access (MAPI) networks.

In the RTM version of Exchange 2010 and in all versions of Exchange Server 2007, continuous replication operates by shipping copies of the log files generated by the active database copy to the passive database copies. Beginning with Exchange 2010 SP1, this form of continuous replication is known as continuous replication - file mode. SP1 also introduces a new form of continuous replication known as continuous replication - block mode. In block mode, as each update is written to the active database copy's active log buffer, it's also shipped to a log buffer on each of the passive mailbox copies. When the log buffer is full, each database copy builds, inspects and creates the next log file in the generation sequence. In the event of a failure affecting the active copy, the passive copies will have been updated with most or all of the latest updates. The active copy doesn't wait for replication to complete in order to preclude replication issues from affecting the client experience.

Block mode dramatically reduces the latency between the time a change is made on the active copy and when the change is replicated to passive copies. In addition to replicating individual log file writes, block mode also changes the activation process for a passive copy. If a copy is in block mode when a failure occurs, the system uses whatever partial log content is available during the activation process. This eliminates the current log file on the active copy from being a single point of failure.

The initial mode of operation is always file mode. Block mode is only active when continuous replication is up-to-date in file mode. The transition into and out of block mode is performed automatically by the log copier. When the passive copy requests the current log file, it indicates that continuous replication is up-to-date (the copy queue length is 0), and the system should automatically switch from file mode to block mode.

You can determine if a passive database copy is in block mode by monitoring the Continuous replication – block mode Active performance counter under the MSExchange Replication performance object. Each database copy has its own instance of this counter. The value of the counter is set to 1 when the passive copy is in block mode and 0 when the passive copy is in file mode. You can also determine the value of this counter by using the Get-Counter or Get-WMIObject cmdlets, as shown in these examples:

	Copy Code
Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active" Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

The Exchange 2010 Hub Transport server role includes a feature called the transport dumpster, which was first introduced in Exchange 2007. The transport dumpster is designed to help protect against data loss by maintaining a queue of all recent e-mail messages sent to users whose mailboxes were protected by CCR or LCR. When a lossy failure occurred in either of these environments, the bulk of the data that would have ordinarily been lost as a result of the failure is automatically recovered by the transport dumpster.

The transport dumpster is used for replicated mailbox databases only. It doesn't protect messages sent to public folders, nor does it protect messages sent to recipients on mailbox databases that aren't replicated. The transport dumpster queue for a specific mailbox database is located on all Hub Transport servers in the Active Directory sites containing the DAG.

In Exchange 2007, messages were retained in the transport dumpster until the administrator-defined time limit or size limit is reached. In Exchange 2010, the transport dumpster now receives feedback from the replication pipeline to determine which messages have been delivered and replicated. As a message goes through Hub Transport servers on its way to a replicated mailbox database in a DAG, a copy is kept in the transport queue (mail.que) until the transaction logs representing the message have been successfully replicated to and inspected by all copies of the mailbox database. After the logs have been replicated to and inspected by all database copies, the messages in those logs are truncated from the transport dumpster. This keeps the transport dumpster queue smaller by maintaining only copies of messages whose transactions logs haven't yet been replicated.

Each DAG's Active Manager tracks the value for the last log inspected time on each passive database copy. The Active Manager client running on the Hub Transport server obtains this information from the DAG's Standby Active Manager (SAM) and converts that information into a time-based watermark. The Hub Transport server then compares the delivery time of messages in the transport dumpster with the watermark. If the delivery time of a message is older than the watermark, then the message is truncated from the transport dumpster.

The transport dumpster has also been enhanced to account for the changes to the Mailbox server role that enable a single mailbox database to move between Active Directory sites. DAGs can be extended to multiple Active Directory sites, and as a result, a single mailbox database in one Active Directory site can fail over to another Active Directory site. When this occurs, any transport dumpster redelivery requests will be sent to both Active Directory sites: the original site and the new site.

When the Hub Transport server is co-located with a Mailbox server that's a member of a DAG, there are changes in routing behavior to ensure that the resiliency features in both server roles will provide the necessary protection for messages sent to and received by users on that server. The Hub Transport server role was modified so that it now attempts to reroute a message for a local Mailbox server to another Hub Transport server in the same site if the Hub Transport server is also a DAG member and it has a copy of the mailbox database mounted locally. This extra hop was added to put the message in the transport dumpster on a different Hub Transport server.

For example, EX1 hosts the Hub Transport server role and Mailbox server role and is a member of a DAG. When a message arrives in transport for EX1 destined for a recipient whose mailbox is also on EX1, transport will reroute the message to another Hub Transport server in the site (for example, EX2), and that server will deliver the message to the mailbox on EX1.

There's a second, similar behavior change related to the Microsoft Exchange Mail Submission service. This service was modified so that it would not submit messages to a local Hub Transport server role when the Mailbox server or Hub Transport server is a member of a DAG. In this scenario, the behavior of transport is to load balance submission requests across other Hub Transport servers in the same Active Directory site, and fall back to a local Hub Transport server if there are no other available Hub Transport servers in the same site.

Return to top

In addition to the transport dumpster and routing behavior enhancements described previously, a new Hub Transport server feature named shadow redundancy has been added. Shadow redundancy provides redundancy for messages for the entire time they are in transit. The solution involves a technique similar to the transport dumpster. With shadow redundancy, the deletion of a message from the transport database is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting successful delivery, the message is resubmitted for delivery to that next hop. For more information about shadow redundancy, see Understanding Shadow Redundancy.

Exchange 2010 includes a new feature that enables you to move mailboxes asynchronously. In Exchange 2007, when you used the Move-Mailbox cmdlet to move a mailbox, the cmdlet logged on to both the source database and the target database and moved the content from one mailbox to the other mailbox. There were several disadvantages to having the cmdlets perform the move operation:

• Mailbox moves typically took hours to complete, and during the move, users weren't able to access their mailbox.
  
  
• If the Command Prompt window used to run the Move-Mailbox cmdlet was closed, the move was terminated and had to be restarted.
  
  
• The computer used to perform the move participated in the data transfer. If an administrator ran the cmdlets from his or her workstation, the mailbox data would flow from the source server to the administrator's workstation and then to the target server.
  
  

The New-MoveRequest cmdlet in Exchange 2010 can be used to perform asynchronous moves. Unlike in Exchange 2007, the cmdlets don't perform the actual move. The move is performed by the Microsoft Exchange Mailbox Replication service, a new service that runs on a Client Access server. The New-MoveRequest cmdlet sends requests to the Microsoft Exchange Mailbox Replication service. For more information about online mailbox moves, see Understanding Move Requests.

There are several changes to the core architecture of Exchange 2010 that have a direct effect on how you will protect your mailbox databases and the mailboxes they contain.

One significant change is the removal of storage groups. In Exchange 2010, each database is associated with a single log stream, represented by a series of 1 megabyte (MB) log files. Each server can host a maximum of 100 databases.

Another significant change for Exchange 2010 is that databases are no longer closely tied to a specific Mailbox server. Database mobility expands the system's use of continuous replication by replicating a database to multiple, different servers. This provides better protection of the database and increased availability. In the case of failures, the other servers that have copies of the database can mount the database.

The ability to have multiple copies of a database hosted on multiple servers means that if you have a sufficient number of database copies, you can use these copies as your backups. For more information about this strategy, see Understanding Backup, Restore and Disaster Recovery.

Exchange 2007 introduced the concepts of lost log resilience and incremental reseed. Lost log resilience is an internal component of ESE that enables you to recover Exchange mailbox databases even if one or more of the most recently generated transaction log files have been lost or damaged. Lost log resilience enables a mailbox database to mount even when recently generated log files are unavailable. Lost log resilience works by delaying writes to the database until the specified number of log generations have been created. Lost log resilience delays recent updates to the database file for a short time. The length of time that writes are delayed depends on how quickly logs are being generated.

Exchange 2007 also introduced the concept of incremental reseed, which provided the ability to correct divergences in the transaction log stream between a source and target storage group, by relying on the delayed replay capabilities of lost log resilience. Incremental reseed didn't provide a means to correct divergences in the passive copy of a database, after divergent logs had been replayed, which forced the need for a complete reseed. Unlike Exchange 2007, there is no amount of log loss that requires a full reseed in Exchange 2010.

In Exchange 2010, incremental resync is the new name for the feature that automatically corrects divergences in database copies under the following conditions:

• After an automatic failover for all of the configured copies of a database
  
  
• When a new copy is enabled and some database and log files already exist at the copy location
  
  
• When replication is resumed following a suspension or restarting of the Microsoft Exchange Replication service
  
  

As a result of these changes, lost log resilience is now hard-coded to one log file for all Exchange 2010 mailbox databases.

When divergence between an active database and a copy of that database is detected, incremental resync performs the following tasks:

• Searches historically in the log file stream to locate the point of divergence.
  
  
• Locates the changed database pages on the diverged copy.
  
  
• Reads the changed pages from the active copy, and then copies the necessary log files from the active copy.
  
  
• Applies the database page changes to the diverged copy.
  
  
• Runs recovery on the diverged copy and replays the necessary log files into the database copy.
  
  

Exchange 2010 also includes a new third-party replication API that enables organizations to use third-party synchronous replication solutions instead of the built-in continuous replication feature. Microsoft supports third-party solutions that use this API, provided that the solution provides the necessary functionality to replace all native continuous replication functionality that is disabled as a result of using the API. Solutions are supported only when the API is used within a DAG to manage and activate mailbox database copies. Use of the API outside of these boundaries is not supported. In addition, the solution must meet the applicable Windows hardware support requirements (test validation is not required for support).

When deploying a solution that uses the built in third-party replication API, be aware that the solution vendor is responsible for primary support of the solution. Microsoft supports Exchange data for both replicated and non-replicated solutions. Solutions that use data replication must adhere to Microsoft's support policy for data replication, as described in Microsoft Knowledge Base article 895847, Multi-site data replication support for Exchange Server. In addition, solutions that utilize the Windows Failover Cluster resource model must meet Windows cluster supportability requirements as described in Microsoft Knowledge Base article 943984, The Microsoft Support Policy for Windows Server 2008 Failover Clusters.

Microsoft's backup and restore support policy for deployments that use third-party replication API-based solutions is the same as for native continuous replication deployments.

If you are a partner seeking information about the third-party API, contact your Microsoft representative. For information about partner products for Exchange 2010, see Microsoft Exchange Partners.

Return to top