You are here: Application protection > Application requirements > Exchange protection requirements

Exchange protection requirements

In addition to the general application requirements, you must also meet the following requirements to protect Exchange.

Exchange versions—Double-Take Availability can protect Microsoft Exchange 2003, Exchange 2007 or Exchange 2010, with the following requirements and limitations.

The version of Exchange on the source and target must be identical.
Exchange 2010 must have Service Pack 1.
Exchange 2010 must be running a 64-bit server running Windows 2008 SP2 or later or Windows 2008 R2.
Double-Take Availability 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.
For Exchange 2007, 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 Availability 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.

Multi-site DAGs (DAG to DAG configurations) are not supported.
All mailbox stores must be replicated to all other members of the DAG.
Exchange Management Tools and Failover Cluster Tools must be installed on the client machine where the Application Manager is being run. If these snap-ins are not installed, Exchange 2010 server will be filtered from the Application Manager display.
During failover, Double-Take Availability 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.

All Microsoft best practices should be used for all versions of Exchange.

Server and network configuration—The following requirements and limitations apply to your Exchange server and network configuration.

You can use a one-to-one configuration for Exchange protection. You cannot use a one-to-many, many-to-one, or chained configuration.
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.
Exchange 2003 on a domain controller is not a recommended configuration. However, if you must run Exchange 2003 on a domain controller, review Microsoft Knowledge Base articles 822179, 332097, 305065, 304403, and 875427.
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 using like-named clusters, this requirement does not apply.
Public folder replication issues may occur in environments where public folder replicas are shared between the source, target, and other Exchange server(s). In these environments, event IDs 3085 and 3092 are logged to the Application event log after failback. If you are using Exchange 2003, no additional steps are required. If you are using Exchange 2007, you must run the Application Manager Console on a machine, preferable the target server, that has PowerShell and the Exchange Management snap-in installed in order to address the issue.
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.

Cluster protection—Cluster to cluster and cluster to standalone configurations are supported. A standalone to cluster configuration is not supported. In addition, the following limitations 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.
If you are using a Windows Server 2008 cluster, the Application Manager must be running a machine with the Windows 2008 failover cluster management tools.

Like-named cluster protection—If you are using Exchange 2003, you can protect a cluster with a like-named cluster, also known as a standby cluster. Double-Take Availability will move the Exchange virtual server from the source cluster to the target cluster. The process of moving users and public folders from one server to another is not needed because users will continue to use the same mail store on the target as they were on the source. The like-named cluster environment must meet the following requirements.

All nodes on the source and target clusters must have the same Exchange version and service pack.
The target resource group only needs to contain physical disk resources, however they must use the same drive letters that are used by the physical disk resources on the source.
Application Manager will create temporary name and IP address resources on the target cluster for Double-Take Availability mirroring and replication. A DNS entry is created based on the target's owning node DNS server. If the source and target owning nodes are configured to use different DNS servers, this can cause issues when enabling protection. If you have issues enabling protection in this configuration, verify that the source's owning node DNS server is correctly set up to receive DNS zone updates from the target's owning node DNS server, or reload the forward and reverse zones using the dnsmgmt utility.
The user configuring the like-named cluster protection in the Application Manager must be a member of the local administrator and Double-Take Admin groups on all cluster nodes. Additionally, the user must be delegated Full Exchange Administrator access through Exchange System Manager. Optionally, the user must be a member of the DnsAdmins group if you want to be able to update the Time to Live DNS attribute.
If you have multiple Exchange virtual servers, you can configure multiple like-named cluster protection connections, or you can failover multiple Exchange virtual servers to pre-existing Exchange virtual servers on the target.

Security—By default, the Double-Take service is configured to use the local system account. If you are protecting Exchange, you cannot change this configuration.

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.
Application Manager Console—The following limitations apply to the Application Manager Console when protecting Exchange.

If you are using Exchange 2007, the console may be run on a workstation provided that the Exchange 2007 Management Tools are installed prior to installing Double-Take Availability.
If you are using Exchange 2010 with DAG, the console may be run on a workstation provided that the Exchange 2010 Management Tools and Failover Cluster Tools are installed prior to installing Double-Take Availability.
The machine running the console must have access to the domain in which the Exchange servers are located.