Exchange 2010 DAG Protection using Double-Take Availability 6.0

Exchange 2010 DAG Protection using Double-Take Availability 6.0

The following video demonstrates how to protect an Exchange 2010 DAG (Database Availability Group) that is running on a Windows Server 2008 R2 platform, to a standalone installation of Exchange 2010 using Double-Take Availability 6.0.

The demonstration specifically details:
  1. View the Exchange DAG
  2. Configure Double-Take Availability job to protect the Exchange DAG
  3. Mirror (DAG to standalone)
  4. Fail (shutdown) the DAG
  5. Failover to the target Exchange server
  6. Show mounted Exchange on the failed over server
  7. Bring up DAG and restore to it
  8. Failback to the DAG
  9. Check DAG is working and restart Double-Take protection job


YouTube Video :
Exchange 2010 DAG Protection using Double-Take Availability 6.0

Exchange 2010 DAG
Figure 1:
Exchange Protection with Double-Take

Exchange Protection Requirements

In addition to the Core Double-Take requirements (see Double-Take Availability User Guide), you must also meet the following requirements to protect Exchange.
  • Exchange versions—Double-Take can protect Microsoft Exchange 2007 or Exchange 2010. Exchange 2010 must have Service Pack 1 or later.
  • Exchange and network configuration—The following requirements and limitations apply to your Exchange server and network configuration.
  • All Microsoft best practices should be used for all versions of Exchange.
  • The version of Exchange on the source and target must be identical.
  • Exchange 2010 must be running on a 64-bit server running Windows 2008 SP2 or later or Windows 2008 R2.
  • Double-Take does not check the edition of Exchange 2007 (Enterprise or Standard). However, it is able to differentiate between service pack levels. If you have Exchange 2007 Enterprise on the source and Exchange 2007 Standard on the target, you will be limited to only failing over the number of databases or storage groups supported by Exchange 2007 Standard. See the "Exchange Server 2007 Editions and Client Access Licenses" information on the Microsoft website.
  • In a consolidated role environment only the mailbox role is protected. The Hub Transport and Client Access roles are not protected or failed over because they are already installed on the target.
  • For Exchange 2007 and 2010, replication and failover between a distributed role source configuration to a consolidated role target configuration is permitted as long as the source Mailbox Server role is installed on a standalone server or cluster with the other roles residing on different servers, and the target configuration is a standalone server with the Mailbox, Hub Transport, and Client Access roles installed. In these configurations, Double-Take will not replicate any data associated with the Hub Transport/Client Access data, however, the target Hub Transport/Client Access roles function properly when failing over the source Mailbox role, allowing necessary operations to resume. For Exchange 2010 with DAG (Database Availability Group), replication and failover from a distributed role source configuration must be to a non-DAG distributed role target configuration.
  • For Exchange 2010 with DAG, the following requirements and limitations also apply.
    • A DAG to standalone configuration is the only supported configuration. Multi-site DAGs (DAG to DAG configurations) are not supported.
    • All mailbox stores must be replicated to all other members of the DAG.
    • During failover, Double-Take will update SPNs, move user mailboxes, and perform Active Directory updates. DNS updates are not made during failover, but can be scripted manually if needed.
  • The Exchange program files must be installed in the same location on the source and target.
  • The drive letter(s) where Exchange stores its data on the source must be the same on the target.
  • Single-label DNS domain names (those without a suffix such as .com, .corp, .net) are not supported.
  • In environments where the FIPS security policy is enabled, you must use impersonation, which requires the following.
    • The user running the Double-Take Console must have all appropriate rights to update the domain (that is, only impersonation is supported).
    • You must manually verify DNS rights by running the DFO utility with the /test parameter.
  • If you are protecting Exchange 2007 and will only be protecting a subset of the storage groups, the storage groups you are protecting cannot have a hyphen followed by a space in the storage group name. You will either need to change the name of the storage group to remove the hyphen followed by the space, or select all of your storage groups for protection.
  • Microsoft Server Core is not supported.
  • The source and target servers must be in the same root forest domain.
  • In a parent/child domain, at least one domain controller in the child domain must be designated as a global catalog server.
  • The target server cannot be a domain controller.
  • Exchange and a domain controller cannot be on the same node of a cluster.
  • The source and target servers must be part of the same Exchange Administrative Group.
  • The Exchange configurations on the source and target servers must be identical for the following components: storage groups, location of storage groups (log and data files), log file prefixes, database locations (log and data files), Message Transfter Agent (MTA) location, and queue paths.
  • If you are protecting Exchange in a 2008 R2 domain where the domain functional level is set to R2, you must grant two levels of access to the local system account on the target. First, grant the Administer information store control to the target in the Configuration Naming Context in order to move users during failover. Second, grant Full control to the target in the Domain Naming Context in order to move Service Principal Names, which will allow users to access their e-mail after a failover.
  • Before you attempt to protect your Exchange application, you may want to complete the following tasks to verify that the environment is properly set up.
    • With both Exchange servers online, use Active Directory Users and Computers to move an existing user from the source to the target and then back to the original source.
    • Verify that you can create a new user on the target.
    • To verify connectivity, create an Outlook profile for the new user on a client machine and connect to the target.
    • If /domainprep has not been run in an Exchange 2007 environment, users will not be failed over and SPNs will not be updated during failover due to access denied errors. To fix this issue, run setup with the /domainprep parameter in the environment.
  • Supported configurations—The following table identifies the supported configurations for an Exchange job
Configuration Supported Not Supported
One-to-one, active/standby X
One-to-one, active/active X
Source to target configuration Many-to-one X
One-to-many X
Chained X
Single server X
Standalone-to-standalone X
Standalone-to-cluster X
Server configuration1 Cluster-to-standalone X
Cluster-to-cluster X
Cluster Shared Volumes (CSV) guest level X
Cluster Shared Volumes (CSV) host level X

1.When using a supported cluster configuration, the following limitations also apply.
  • If you are using Exchange 2007, only the mailbox role is protected.
  • Exchange and the domain controller cannot be on the same node in the cluster.
  • Exchange must be installed in a unique group, not in the cluster group.

Article ID: SLN310473

Last Date Modified: 08/14/2018 03:54 AM

Rate this article

Easy to understand
Was this article helpful?
Yes No
Send us feedback
Comments cannot contain these special characters: <>()\
Sorry, our feedback system is currently down. Please try again later.

Thank you for your feedback.