Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Topic Last Modified: 2011-01-24

Microsoft Exchange Server 2010 introduces the concept of database mobility, which is Exchange-managed database-level failovers. An enhanced version of the continuous replication feature first introduced in Exchange Server 2007 is used in Exchange 2010 to create and maintain database copies.

Database mobility disconnects databases from servers, adds support for up to 16 copies of a single database, and provides a native experience for adding database copies to a database. In Exchange 2007, a feature called database portability also enabled you to move a mailbox database between servers. A significant distinction between database portability and database mobility, however, is that with database mobility, all copies of a database have the same GUID.

Because clustered mailbox servers and storage groups have been removed from Exchange 2010, continuous replication now operates at the database level. In Exchange 2010, transaction logs are replicated to one or more Mailbox servers and replayed into a copy of a mailbox database that's stored on those servers. A failover or switchover can occur at either the database level or at the server level.

Key Characteristics

The key characteristics of mailbox database copies are:

  • Database copies are for mailbox databases only. For redundancy and high availability for public folder databases, we recommend that you use public folder replication.

  • Up to 16 copies of an Exchange 2010 mailbox database can be created on multiple Mailbox servers, provided the servers are grouped into a database availability group (DAG), which is a boundary for continuous replication. Exchange 2010 mailbox databases can be replicated only to other Exchange 2010 Mailbox servers within a DAG. You can't replicate a database outside of a DAG, nor can you replicate an Exchange 2010 mailbox database to a server running Exchange 2007. For detailed information about DAGs, see Understanding Database Availability Groups.

  • All Mailbox servers in a DAG must be in the same Active Directory domain.

  • Like standby continuous replication (SCR), all mailbox database copies support the concepts of replay lag time and truncation lag time. Note however, careful planning must be performed before enabling these features.

  • All database copies can be backed up using an Exchange-aware, Volume Shadow Copy Service (VSS)-based backup application. However, the built-in support for Windows Server Backup is for active copies only. You can't use Windows Server Backup to back up passive copies.

  • Database copies can be created only on Mailbox servers that don't host the active (mounted and in-use) copy of a database. You can't create two copies of the same database on the same server.

  • All copies of a database use the same path on each server containing a copy. The database and log file paths for a database copy on each Mailbox server must not conflict with any other database paths.

  • Database copies can be created in the same or different Active Directory sites, and on the same or different network subnets.

  • Database copies aren't supported between Mailbox servers with round trip network latency greater than 500 milliseconds (ms).

Mailbox Database Copies

You can create a mailbox database copy at any time. Mailbox database copies can be distributed across Mailbox servers in a flexible and granular way. You can replicate one, some, or all mailbox databases on a server in a variety of ways.

You can create a mailbox database copy using the Add Mailbox Database Copy wizard in the Exchange Management Console or by using the Add-MailboxDatabaseCopy cmdlet in the Exchange Management Shell.

When creating a mailbox database copy, specify the following parameters:

  • Identity   This parameter specifies the name of the database being copied. Database names must be unique within the Exchange organization.

  • MaliboxServer   This parameter specifies the name of the Mailbox server that will host the database copy. This server must be a member of the same DAG and must not already host a copy of the database.

Optionally, you can also specify:

  • ActivationPreference    This parameter specifies the activation preference number, which is used as part of Active Manager's best copy selection process. It's also used to redistribute active mailbox databases throughout the DAG when using the RedistributeActiveDatabases.ps1 script. The value for the activation preference is a number equal to or greater than one, where one is at the top of the preference order. The position number cannot be larger than the number of mailbox database copies.

  • ReplayLagTime   This parameter specifies the amount of time that the Microsoft Exchange Replication service should wait before replaying log files that are copied to the database copy. The format for this parameter is (Days.Hours:Minutes:Seconds). The default setting for this value is 0 seconds. The maximum allowable setting for this value is 14 days. The minimum allowable setting is 0 seconds. Setting the value for replay lag time to 0 turns off log replay delay.

  • TruncationLagTime   This parameter specifies the amount of time that the Microsoft Exchange Replication service should wait before truncating log files that have replayed into a copy of the database. The time period begins after the log has been successfully replayed into the copy of the database. The format for this parameter is (Days.Hours:Minutes:Seconds). The default setting for this value is 0 seconds. The maximum allowable setting for this value is 14 days. The minimum allowable setting is 0 seconds. Setting the value for truncation lag time to 0 turns off log truncation delay.

  • SeedingPostponed    This parameter specifies that the task shouldn't automatically seed the database copy on the specified Mailbox server. This option is typically used when you intend to seed a new mailbox database copy by using an existing passive copy of the database (for example, adding a second copy of a specific database to a remote location). When you use this parameter, you must manually seed the database copy using the Update-MailboxDatabaseCopy cmdlet.

For more information about creating, using, and managing mailbox database copies, see Managing Mailbox Database Copies.