HP XP P9000 Command View Advanced Edition Software - Manual (Page 411)

• You cannot simultaneously create the replica of the active and passive mailbox database copies.
Wait until execution of the replica creation is finished for the first mailbox database copy before
you begin create the replica of the other mailbox database copies.
• When you restore a replica, the target mailbox database copy must be an active mailbox database
copy.
• A replica can be restored only to the Exchange Server 2010/2013 server where the replica was
created. Replicas acquired from another Exchange Server 2010/2013 server cannot be restored.
• After the restore completes, you must execute the seed function to change the status of the Exchange
Server 2010/2013 replication function to normal.
• If you perform a restore without using the seed function, the Exchange Server 2010/2013 replic-
ation function to be restored will be stopped, but the seeding will not be performed. After the restore
completes, you must perform seed processing and restart the Exchange Server 2010/2013 rep-
lication manually.
• If you create a replica of either the active mailbox database copy or a passive mailbox database
copy using the option for deleting transaction logs, you cannot perform a roll-forward restore using
the replica that was made before the transaction logs are deleted, regardless of the active mailbox
database copy or the passive mailbox database copy. Therefore, HP recommends that you use
the option to delete transaction logs for only one mailbox database copy (either the active or
passive).
• When performing a restore, Microsoft Exchange Replication Service must be running on the Ex-
change Server 2010/2013 server that is assigned the role of the Primary Active Manager.
• Even if performing the seed after point time restore, the length of copy queue might not be 0. If
you switch over the mailbox database copy in this status, use the Exchange Management Shell.
The following is an example using the
Move-ActiveMailboxDatabase cmdlet:
Move-ActiveMailboxDatabase databasename -ActivateOnServer destination-servername
-SkipLagChecks:$True MountDialOverride:Besteffort
Related topics
• Restoring the latest application replica (simple restore) , page 406
About Database Availability Groups (DAGs)
Database Availability Groups are a high-availability feature implemented in Exchange 2010/2013.
DAGs provide automatic database-level recovery from a database, server, or network failure. DAGs
use continuous replication and a subset of Windows failover clustering technologies to provide
continuous mailbox availability. Mailbox servers in a DAG monitor each other for failures. When a
Mailbox server is added to a DAG, it works with the other servers in the group to provide automatic,
database-level recovery from database failures.
NOTE:
There is a limit of 16 mailbox servers per DAG.
When a DAG is created, it is initially empty and a directory object is created in Active Directory that
represents the DAG. The directory object is used to store relevant DAG information, such as server
membership. When the first server is added to a DAG, a failover cluster is automatically created for
the group and the infrastructure that monitors the servers for network or server failures is initiated. The
failover cluster heartbeat mechanism and cluster database are then used to track and manage
information about the DAG, such as database mount status, replication status, and last mounted
location.
User Guide 411