Double-Take Availability User's Guide Printable Version

This document is a single HTML page that contains all of the separate HTML pages in the Double-Take Availability User's Guide. This single HTML document is designed to make printing the entire User's Guide easier. You can also print sections of the User's Guide by using your browser's print preview feature and printing only the desired pages. Keep in mind that the page numbers as seen in the Table of Contents may not match the page numbers when you print the document because of differences in printer configurations.

This printable document is not a standalone document. It requires the style definition files and graphic files used in the separate-page User’s Guide. Therefore, if you try to view or print this document on its own (for example, by copying or downloading the single file to a different location), the output will not have any formatting or graphics included.

Table of Contents

Welcome to the Double-Take Availability User's Guide

This online documentation is designed to help you find detailed information about Double-Take Availability. Use the Table of Contents pane on the left to explore the different sections or use Search or Index to find specific topics. Below are some of the most useful and most accessed topics in the online documentation.

Getting started

• Double-Take Availability overview explains the basic functionality of Double-Take Availability.
• Double-Take Availability requirements lists the minimum requirements for each Double-Take Availability server as well as the specific requirements for specific Double-Take Availability features .
• Installation includes complete installation instructions.
• Evaluations is a step-by-step process to help you assess the key Double-Take Availability features. This is a good process for users who want to see, first-hand, the benefits that Double-Take Availability has to offer. 
• Double-Take Availability Scripting Guide contains detailed information on the DTCL internal scripting language.

Frequently used pages

• Workload protection includes detailed instructions for protecting your data, full-server, application, virtual, or cluster workloads.
• Workload monitoring details how to monitor your workload protections.
• Failover includes instructions for failing over to keep your data highly available.

Printable version

A printable version, which is a single HTML page containing all of the separate HTML pages in the Double-Take Availability User’s Guide, is available. This single HTML document is designed to make printing the entire User’s Guide easier.

Resources

• Product Updates—Check your service agreement to determine which updates and new releases you may be eligible for. Product updates can be obtained from the Double-Take Software support web site.
• Sales—If you need maintenance renewal, an upgrade activation code, or other sales assistance, contact your reseller/distributor or a Double-Take Software sales representative. Contact information is available on the Double-Take Software web site contact information page.
• Technical Support—If you need technical assistance, you can contact technical support. All basic configurations outlined in the online documentation will be supported through technical support. Your technical support center is dependent on the reseller or distributor you purchased your product from and is identified on your service agreement. If you do not have access to this agreement, contact Double-Take Software Technical Support and they will direct you to the correct service provider. To contact Double-Take Software Technical Support, you will need your serial number and activation code. Contact information is available on the Double-Take Software web site support information page.
• Professional Services—Assistance and support for advanced configurations may be referred to a Pre-Sales Systems Engineer or to Professional Services. For more information, see the Double-Take Software Professional Services information page.
• Training—Classroom and computer-based training are available. For more information, see the Double-Take Training information page.
• Documentation—Please forward any comments or suggestions about this online documentation to documentation@doubletake.com.

Legal 

Double-Take, Balance, Double-Take Availability, Double-Take Backup, Double-Take Cargo, Double-Take Flex, Double-Take for Hyper-V, Double-Take for Linux, Double-Take Move, Double-Take ShadowCaster, Double-Take for Virtual Systems, GeoCluster, Livewire, netBoot/i, NSI, sanFly, TimeData, TimeSpring, winBoot/i and associated logos are registered trademarks or trademarks of Double-Take Software, Inc. and/or its affiliates and subsidiaries in the United States and/or other countries. Microsoft, Hyper-V, Windows, and the Windows logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are the property of their respective companies.

© 1996-2010 Double-Take Software, Inc. All rights reserved.

Double-Take Availability overview

Double-Take Availability ensures the availability of critical workloads. Using real-time replication and failover, you can protect data, individual applications, entire servers, or virtual machines.

Identify your critical workload on your production server, known as the source, and replicate the workload to a backup server, known as the target. The target server, on a local network or at a remote site, stores the copy of the workload from the source. Double-Take Availability monitors any changes to the source workload and sends the changes to the copy stored on the target server. By replicating only the file changes rather than copying an entire file, Double-Take Availability allows you to more efficiently use resources.

Core operations

Double-Take Availability performs four basic types of operations.

• Mirroring—The initial copy or subsequent resynchronization of selected data
• Replication—The on-going capture of byte-level file changes
• Failure monitoring and failover—The ability to monitor and stand-in for a server, in the event of a failure
• Restoration—A mirror of selected data from the target back to the source

Double-Take Availability workloads

Building on Double-Take Availability core operations, you can protect specific workloads to meet your protection goals.

• Full-server workloads—You can protect an entire server, including the data and system state, which is the server's configured operating system and applications. In the event of a failure, the target becomes the source.
• Application workloads—You can protect applications running on your source including Exchange, SQL, SharePoint, BlackBerry, or a Windows file server.
• Virtual workloads—You can protect virtual servers in the following configurations.
• You can protect an entire physical or virtual server to an automatically provisioned (created) virtual server on a Hyper-V or ESX server. If you are protecting a virtual server, you are protecting the data within the guest operating system.
• You can protect a Hyper-V virtual server to a Hyper-V virtual server. In this case, you are protecting the host-level files (.vhd files), making them highly available on another Hyper-V server.
• You can protect an ESX virtual server to an ESX virtual server. In this case, you are protecting the host-level files (.vmdk files), making them highly available on another ESX server.
• Cluster workloads—You can protect two types of clusters.
• You can protect a standard cluster where a single copy of data resides on a SCSI disk shared between cluster nodes.
• You can protect a GeoCluster that eliminates the single point of failure of a shared disk by replicating data between volumes.

Full-server workloads

Full-server workload protection provides high availability for an entire server, including the system state, which is the server's configured operating system and applications. You identify your source, which is the server you want to protect, and your target, which is the server that will stand-in for the source in the event the source fails. Once the two servers are selected and their configurations validated, Double-Take Availability monitors the source for a failure. When it fails, Double-Take Availability allows the target to stand-in for the source by rebooting and applying the source, including its system state, on the target. After the reboot, the target becomes the source, and the target no longer exists.

Application workloads

Application workload protection provides high availability for Exchange, SQL, SharePoint, BlackBerry, and a Windows file server. You identify your source, which is the server running the application, and your target, which is the server that will stand-in for the source in the event the source fails. Double-Take Availability will gather information from your environment (Active Directory, DNS, and so on) about the application being protected and automatically protect the application. Double-Take Availability monitors the source server or the application services for a failure. When it fails, Double-Take Availability allows the target to stand-in for the source. Your end-users can continue to access the application running on the target, which is standing in for the source.

Virtual workloads

Virtual workload protection provides high availability to Hyper-V or ESX virtual servers. You identify your source, which is the server you want to protect. Your source can be a physical server, a virtual machine where you want to protect the data within the guest operating system, or a virtual machine where you want to protect the host-level virtual disk files (.vhd or .vmdk files). Your target is a Hyper-V or ESX server that will host a virtual machine that is a replica of the source. Double-Take Availability monitors the source for a failure. In the event of a source failure, the replica virtual machine on the target can stand-in allowing end-users to continue accessing data and/or applications.

Cluster workloads

In a standard cluster configuration, a single copy of data resides on a SCSI disk that is shared between cluster nodes. Data is available without users knowing which node owns a cluster resource. MSCS handles failover between nodes of the cluster. By adding Double-Take Availability to this cluster environment, you can further protect your data by replicating the cluster data to a target. In the event the cluster fails, your cluster data will be available on the target.

In a GeoCluster configuration, data is stored on volumes local to each node and replicated to each node in the cluster using Double-Take Availability. Resources and groups are handled in the same manner as a standard cluster. Instead of assigning one group by SCSI drive, you assign one group per logical volume. If a server, disk, group, or network interface should fail, MSCS relocates the failed group to another node, which contains the replicated copy of the data, thus maintaining availability.

Supported configurations

Double-Take Availability is an exceptionally flexible product that can be used in a wide variety of network configurations. To implement Double-Take Availability effectively, it is important to understand the possible configuration options and their relative benefits. Double-Take Availability configuration options can be used independently or in varying combinations.

Double-Take Availability requirements

Each Double-Take Availability server must meet minimum requirements. If you are protecting certain workloads, your servers may need to meet additional requirements. Verify that each server meets the general requirements and any additional requirements for your workload type. Additionally, the machine where you will be running the console must also meet several requirements.

• General source and target server requirements
• Full-server workload requirements
• Application workload requirements
• Virtual workload requirements
• Cluster workload requirements
• Double-Take Console requirements

General source and target server requirements

• Operating system—There are different licenses depending on the operating system you are using. Be sure you have the correct license for your operating system. Each of the Windows 2003 operating systems listed in the chart require Service Pack 1 or later.

License	Windows 2003 and 2003 R2 Operating Systems	Windows 2008 and 2008 R2 Operating Systems Note: If you are using Hyper-V R2 with Cluster Shared Volumes (CSV), you will be unable to protect the virtual machines at the host level using Double-Take Availability. However, you can use Double-Take Availability within the guest to protect your workloads.	Virtual Servers
			Guest-Level Protection Note: Double-Take Availability runs inside the virtual server to provide workload protection for data and/or applications running on the guest operating system. These licenses can be spread across multiple hosts.	Host-Level Protection Note: Double-Take Availability runs outside the virtual server to protect the hard disk (.vmdk or .vhd) and its associated files stored on the host operating system. These licenses are per host.
Foundation Edition Note: You can install the Foundation Edition on a server running other server Windows operating systems, so you do not have to pay extra for an upgraded Double-Take Availability license. When the Foundation Edition is installed on a server running these other server Windows operating systems, the following limitations will apply. 1) The server will function in a target role only. 2) The target-only server can only protect a source that is running the Double-Take Availability Foundation Edition and one of the operating system editions listed for the Foundation Edition. 3) Full-server failover is the only supported method of failover.	Storage Server Edition Small Business Server	Storage Server Edition i386 and x64 Small Business Server Standard and Premium x64 Foundation Server with SAK Essential Business Server x64	N/A	N/A
Standard Edition	Storage Server Edition Small Business Server Web Edition i386 and x64 Standard Edition i386 or x64	Storage Server Edition i386 and x64 Small Business Server Standard and Premium x64 Foundation Server Essential Business Server x64 Web Server i386 and x64 Standard Edition i386 and x64	1	N/A
Advanced Edition	Storage Server Edition Small Business Server Web Edition i386 and x64 Standard Edition i386 and x64 Enterprise Edition i386 and x64	Storage Server Edition i386 and x64 Small Business Server Standard and Premium x64 Foundation Server Essential Business Server x64 Web Server i386 and x64 Standard Edition i386 and x64 Enterprise Edition i386 and x64	1	N/A
Premium Edition	Storage Server Edition Small Business Server Web Edition i386 and x64 Standard Edition i386 and x64 Enterprise Edition i386 and x64 Enterprise Itanium IA64 Datacenter i386, x64, and IA64	Storage Server Edition i386 and x64 Small Business Server Standard and Premium x64 Foundation Server Essential Business Server x64 Web Server i386 and x64 Standard Edition i386 and x64 Enterprise Edition i386 and x64 Itanium Edition Datacenter Edition i386 and x64	Unlimited	N/A
Virtual Guest 5-Pack	Any valid Foundation, Standard, Advanced, or Premium Edition operating system		5	N/A
Virtual Host Standard Edition	N/A	Standard	N/A	ESX hosts-5 Hyper-V hosts-Unlimited
Virtual Host Advanced Edition	N/A	Standard Enterprise	N/A	ESX hosts-10 Hyper-V hosts-Unlimited
Virtual Host Premium Edition	N/A	Standard Enterprise Datacenter	N/A	ESX hosts-Unlimited Hyper-V hosts-Unlimited

Note:

Microsoft Server Core is supported for data workloads. See the specific requirements for the workload type you are protecting for additional Server Core requirements.

• File system—Double-Take Availability supports the same file system format that Microsoft supports: FAT, FAT32, and NTFS.
• System Memory—There are different memory requirements depending on the operating system you are using. Be sure you have at least the minimum amount of memory for your environment. You may want to consider having at least the recommended amount of system memory.

Operating System	Minimum System Memory	Recommended System Memory
Any Windows i386 operating system	128 MB	At least 512 MB
Any Windows x64 operating system	512 MB	At least 1024 MB

• Disk Usage—The amount of disk space required for the Double-Take Availability program files is approximately 70 MB. You will need to verify that you have additional disk space for Double-Take Availability queuing, logging, and so on. Additionally, on a target server, you need sufficient disk space to store the replicated data from all connected sources, allowing additional space for growth.

Note:

The program files can be installed to any volume while the Microsoft Windows Installer files are automatically installed to the operating system boot volume.

• Server Name—Double-Take Availability includes Unicode file system support, but your server name must still be in ASCII format. If you have the need to use a server's fully-qualified domain name, your server cannot start with a numeric character because that will be interpreted as an IP address.
• Microsoft .NET—Double-Take Availability requires the Microsoft .NET Framework version 3.5 Service Pack 1. You can install this version from the Double-Take Availability CD, via a web connection during the Double-Take Availability installation, or from a copy you have obtained manually from the Microsoft web site.
• Protocols and Networking—Your servers must meet the following protocol and networking requirements.
• Your servers must have TCP/IP with static IP addressing.
• By default, Double-Take Availability is configured for IPv6 and IPv4 environments, but the Double-Take service will automatically check the server at service startup and modify the appropriate setting if the server is only configured for IPv4.
• IPv6 is only supported for Windows 2008 servers.
• If you are using IPv6 on your servers, your clients must be run from an IPv6 capable machine.
• In order to properly resolve IPv6 addresses to a hostname, a reverse lookup entry should be made in DNS.
• Windows Management Instrumentation (WMI)—Double-Take Availability is dependent on the WMI service. If you do not use this service in your environment, contact technical support.
• Windows Firewall—The installation program will automatically attempt to configure ports 6320, 6325, 6330, and 6332 for Double-Take Availability. If you cancel this step, you will have to configure the ports manually.

• Snapshots—Double-Take Availability uses the Microsoft Volume Shadow Copy service for snapshot capabilities. To use this functionality, your servers must meet the following requirements.
• Snapshot operating system—Your servers must be running, at a minimum, Windows 2003 Service Pack 1. You should upgrade to Service Pack 2 or later so that several Microsoft patches that address memory leaks in the Volume Shadow Copy service are applied. If you do not have Service Pack 2 installed, you will need to review the patches available on the Microsoft web site and install those that correct the Volume Shadow Copy service memory leaks.
• Snapshot file system—Your servers must be using the NTFS file system. If you are using a FAT file system, the FAT volumes will not be included in the snapshot set, and when the snapshots are reverted, the FAT volume will not be time-consistent with the NTFS volumes.
• Snapshot configuration—If you have related data on different drives on your source (for example, an Exchange database on one drive and related log files on another), snapshots of each drive must be taken simultaneously so that the snapshots for each drive represent the same point in time. However, based on snapshot technology, different snapshots cannot be taken at the same time. To work around this limitation and guarantee data integrity on the target, you need to create a mount point, thus ensuring that one point-in-time consistent snapshot will be taken of both volumes at once. To create a mount point, create an empty folder on one of the drives. Using the Disk Management tool in the Windows Computer Management applet, remove the drive letter from the other drive. Then create a mount point by selecting Mount in the following empty NTFS folder and specifying the folder you just created. If you have multiple drives, create an empty folder on the drive for each of the other drives and create mount points to each of the folders. When the snapshot is taken of the drive, each mount point will be included in the snapshot. You will need to modify your applications to specify the new location for the files that are now on the mount point. For additional details on creating and using mount points, see your Windows reference manual. For details on modifying your applications, see your application reference manual.

Full-server workload requirements

If you will be protecting an entire server, the general source and target server requirements apply. However, keep in mind that a target server may meet these requirements but may not be suitable to stand-in for a source in the event of a source failure. See Finding a compatible target for additional information regarding an appropriate target server for your particular source.

There is one limitation for full-server protection of a cluster. Microsoft clusters identify disks by their disk signature, which is stored on the physical disk in the master boot record. When Double-Take Availabilityis used to failover a cluster node, the disk signature of the target will be different than the source and the cluster will fail to start. Therefore, Double-Take Availability does not natively support the full-server protection of Microsoft cluster nodes. However, you can alter the disk signature on the target manually. See the Microsoft Knowledge Base article 280425 for details on how to change the disk signature.

Application workload requirements

If you will be protecting an application, the general source and target server requirements apply. In addition, you must meet the application requirements below.

• Server and network configuration—Application protection requires the following server and network requirements.
• The application program files must be installed in the same location on the source and target.
• The drive letter(s) where the applications 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 Double-Take Availability 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.
• Microsoft Server Core is only supported for file server protection.
• Verification—If you want to use the Target Data Verification feature to confirm the integrity of your Exchange or SQL data on the target, you will need to install the Volume Shadow Copy Service SDK in the \windows\system32 directory on the target. You can download the SDK from the Microsoft website. Additionally, your Exchange version must be Exchange 2003 with service pack 1 or later.
• Application Manager Console—The following requirements and limitations apply to the Application Manager Console.
• Ideally, you should run the console from a client machine or from the target.
• Do not run the Application Manager Console from a domain controller.
• If you are using a cluster configuration and run the Application Manager Console from a workstation operating system, you must have the Windows Administration Pack installed in order to have the cluster components installed on the workstation operating system.
• Applications—In addition to these general application requirements, you must also meet the requirements for the application you are protecting. See Exchange, SQL, SharePoint, BlackBerry, or File Server for those 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 or Exchange 2007, with the following requirements and limitations.
• The version of Exchange on the source and target must be identical.
• 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, 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.
• 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 source and target clusters must have the same Exchange resource group name.
• 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.

Note:

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.
• The machine running the console must have access to the domain in which the Exchange servers are located.

SQL protection requirements

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

• SQL versions—Double-Take Availability can protect Microsoft SQL Server or Express 2000 with Service Pack 4 or later, Server or Express 2005, or Server or Express 2008, with the following requirements and limitations.
• If you are using Windows 2008, you can protect SQL Server or Express 2005 or 2008. SQL Server or Express 2000 is not supported on Windows 2008.
• You should use the same version, service pack, and architecture (32-bit or 64-bit) of SQL Server on both the source and target servers. The only exceptions is in database only protection mode you. In this case, you can use a newer version of SQL Server on the target server, or you may have a 32-bit source and a 64-bit target. For example, you may want migrate from SQL Server 2000 on the source to SQL Server 2005 on the target, or migrate data from a 32-bit source to a 64-bit target. However, you cannot failback using different versions of SQL Server on the source and target.
• If you are using SQL Express 2000 or Express 2005, named pipes and TCP/IP need to be added to the enabled protocols to accept remote connections. By default, these are disabled.
• For Express 2000, you must run svrnetcn.exe, which is located in the C:\Program Files\Microsoft SQL Server\80\Tools\Binn directory.
• For Express 2005, you must launch the SQL Server Configuration Manager. Expand SQL Server 2005 Network Configuration, and under Protocols for MSSQLSERVER enable Named Pipes and TCP/IP.
• Server and network configuration—The following requirements and limitations apply to your SQL server and network configuration.
• You can use a one-to-one configuration for SQL protection. You can also use a many-to-one configuration, however protection will be database mode only. You cannot use a one-to-many or chained configuration.
• The source and target servers should be in the same domain. If they are not, the SQL Server service on both the source and target servers must be configured to start with the same domain user account.
• If your source and target are in a workgroup, make sure the source server's NIC does not register the IP addresses with DNS.
• In order to protect SQL named instances, both the source and target servers must have named instances with the same name installed prior to configuring protection.
• If you are using SQL 2005 and are using a domain service account that is not in the domain or local Admins security group, the replicated databases will not mount on the target because of security restrictions at the file system level. You need to place the SQL 2005 service account in the local Admins group on the target.
• If you are using SQL 2008, local group permissions are not copied to the target during failover. You will need to use a domain Admin account as the SQL service account or manually copy the group permissions to the target.
• Double-Take Availability does not support a SQL default instance that is using non-default ports.
• Cluster to cluster and cluster to standalone configurations are supported for SQL Server 2005 and 2008 only.
• If you are protecting a cluster configuration, ideally you should have only one instance of SQL Server per owning node on your source and target cluster. This decreases the risk of problems when attempting to re-enable protection after failover and failback. The following problems may occur if multiple instances reside on the same owning node.
• After failover and failback, you will be able to re-enable protection on the first instance, but when you try to protect subsequent instances, after selecting the source instance, Application Manager will erroneously show that the instance is already protected. Contact technical support to obtain instructions for fixing this issue.
• If one instance is failed over, replication will stop on the other protected instances. On the other instances that are not failed over, you will need to perform a difference mirror in order to resume protection.
• Application Manager Console—The following limitations apply to the Application Manager Console when protecting SQL.
• If you are using a cluster configuration, you should run the console from a target node.
• If you want to run the console from a Vista client to protect a cluster, you will need to install the Microsoft Remote Server Administration Tools (RSAT). Installing this package will allow you to install the Failover Cluster Manager component on a Vista client so it can communicate with and administer Windows 2008 clustered environments.

SharePoint protection requirements

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

• SharePoint versions—Double-Take Availability can protect Windows SharePoint Services (WSS) version 3 or Microsoft Office SharePoint Server (MOSS) 2007. If you are using Windows 2008, you must have Service Pack 1 for each of these SharePoint versions.
• Application support for SharePoint is for SQL instance mode protection. Database-only protection mode is not available.
• Only target web servers running a version of SharePoint that is identical to what is installed on the source web front-end can be extended into the source SharePoint configuration.
• The SharePoint Admin account used to install SharePoint on the source web front-end is required to extend a target web server into the SharePoint configuration.
• Server and network configuration—The following requirements and limitations apply to your SharePoint server and network configuration.
• You can use a one-to-one configuration for SharePoint protection. You cannot use a one-to-many, many-to-one, or chained configuration.
• Each source and target must have SQL Server 2000, 2005 or 2008 installed.
• You will need to open port 6350 on each source and target for SharePoint communication
• SharePoint protection is currently only supported in a flat domain structure.

BlackBerry protection requirements

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

• BlackBerry versions—Double-Take Availability can protect BlackBerry Enterprise Server 4.1.4 through 4.1.6 for Microsoft Exchange.
• Server and network configuration—The following requirements and limitations apply to your BlackBerry server and network configuration.
• Only the Windows 2003 operating systems listed in the general source and target server requirements can be used to protect BlackBerry.
• Each source and target must have Microsoft Exchange 2003 or 2007.
• The version of Exchange on the source and target must be identical.
• Each source and target must have SQL Server 2000 with Service Pack 4, 2005, or 2008 installed.
• Double-Take Availability does not support database only mode. Only the instance of SQL where BlackBerry is installed will be protected.
• You should use the same version, service pack, and architecture (32-bit or 64-bit) of SQL Server on both the source and target servers. The only exceptions is in database only protection mode you. In this case, you can use a newer version of SQL Server on the target server, or you may have a 32-bit source and a 64-bit target. For example, you may want migrate from SQL Server 2000 on the source to SQL Server 2005 on the target, or migrate data from a 32-bit source to a 64-bit target. However, you cannot failback using different versions of SQL Server on the source and target.

File Server protection requirements

In addition to the general application requirements, you must also meet the following requirements to protect a file server.

• You can use a one-to-one configuration for file server protection. You cannot use a one-to-many, many-to-one, or chained configuration.
• The target must be a dedicated, stand-by server which does not host any critical applications.
• During failback, the Server service is restarted, which may also restart any dependent services.
• File server protection is currently only supported in a flat domain structure.
• Microsoft Server Core is supported for file server protection.

Virtual workload requirements

When you are protecting virtual server workloads, the general source and target server requirements still apply, however, the requirements and limitations are more strict depending on your virtual configuration. Select a link from the table below to see the requirements that correspond with your virtual configuration.

Physical or virtual to Hyper-V requirements

Use these requirements if your source is a physical or virtual server, you want to protect the volumes from the physical server or volumes from within the virtual guest operating system, and your target is an automatically provisioned virtual server on a Hyper-V server. This means Double-Take Availability will automatically create the virtual server on the Hyper-V target if failover is triggered.

• Source server—The source server can be any physical or virtual server running any of the operating systems listed in the General source and target server requirements. However, if you are using a Windows 2003 operating system, you must have Service Pack 2 which is required for Hyper-V Integration Services.
• Target server—The target server can be any Windows 2008 or 2008 R2 operating system from the supported server operating systems that has the Hyper-V role enabled. In addition, you can use Hyper-V Server 2008 R2 or Server Core 2008 R2 with the Hyper-V role enabled. (Hyper-V Server 2008 and Server Core 2008 are not supported.)

Physical or virtual to ESX requirements

Use these requirements if your source is a physical or virtual server, you want to protect the volumes from the physical server or volumes from within the virtual guest operating system, and your target is an automatically provisioned virtual server on an ESX server. This means Double-Take Availability will automatically create the virtual server on the ESX target if failover is triggered.

• Source server—The source server can be any physical or virtual server running any of the operating systems listed in the General source and target server requirements.
• ESX server—The ESX server that will host your target can be any of the following operating systems. Note that ESX is commonly referred to as the Classic edition and ESXi as the Embedded and Installable edition.
• ESX 3.5.x or ESXi 3.5.x Standard, Advanced, or Enterprise
• ESX 4.0 or ESXi 4.0 Standard, Advanced, Enterprise, or Enterprise Plus

Note:

If you are using the Standard edition of ESX 4.0 or ESXi 4.0, you must have update 1 or later. If your source is a Windows 2008 R2 server, your ESX server must have version 3.5 update 5 or later or ESX 4.0 update 1 or later.

• VirtualCenter—If you are using ESXi, VirtualCenter 2.5 or later is required. Although VirtualCenter is not required for the ESX versions, if you are using it, then you must use version 2.5 or later.

Note:

VMotion is only supported if you are using VirtualCenter.

• Target server or virtual recovery appliance—The target server must be an existing virtual machine, known as a virtual recovery appliance, running on the ESX server that meets the following requirements.
• The virtual recovery appliance can be any of the operating systems listed in the General source and target server requirements.
• The virtual recovery appliance must have the same or newer operating system than the source (not including service pack level).
• The virtual recovery appliance must have Double-Take Availability installed and licensed on it.
• When you establish protection, the virtual recovery appliance will create a new virtual server, mount disks, format disks, and so on. If failover occurs, the new virtual machine is detached from the virtual recovery appliance and powered on. Once the new virtual machine is online, it will have the identity, data, and system state of the source. Since the virtual recovery appliance maintains its own identity, it can be reused for additional failovers.
• Server and network configuration—The source and target cannot both be domain controllers. Only one or the other can be a domain controller.
• Ideally, the target should not be a domain controller or host any functionality (file server, application server, and so on) because the functionality will be removed when failover occurs.
• If your source is a domain controller, it will start in a non-authoritative restore mode after failover. This means that if the source was communicating with other domain controllers before failover, it will require one of those domain controllers to be reachable after failover so it can request updates. If this communication is not available, the domain controller will not function after failover. If the source is the only domain controller, this is not an issue.

Hyper-V to Hyper-V requirements

Use these requirements if your source is a virtual server on a Hyper-V server, you want to protect the host-level virtual disk files, and your target is a virtual server on a Hyper-V server.

• Source and target operating system—Your source and target servers can be any Windows 2008 or 2008 R2 operating system from the supported server operating systems that has the Hyper-V role enabled. In addition, you can use Hyper-V Server 2008 R2 or Server Core 2008 R2 with the Hyper-V role enabled. (Hyper-V Server 2008 and Server Core 2008 are not supported.)
• Source and target configurations—You can use one-to-one, many-to-one, or one-to-many configurations, however, you cannot use a chained configuration in a Hyper-V to Hyper-V to Hyper-V scenario.
• Hyper-V configuration—The following limitations apply to the virtual machines on the source and target Hyper-V servers.
• The virtual machines must be in their own home folder that is not shared by any other virtual machines.
• The virtual machines cannot be created in or replicated to the Hyper-V system default folder.
• The virtual machines' snapshot folder must be unique to each virtual machine, they cannot be in the Hyper-V system default folder, and they cannot be changed once protection has been established.
• The virtual machines cannot use raw, pass-through, or differencing disks.
• Clusters-Clustered Hyper-V hosts are not supported.
• Ports—In addition to the standard Double-Take Availability ports that must be opened, you must also open port 135 for communication between the client and the servers.

ESX to ESX requirements

Use these requirements if your source is a virtual server on an ESX server, you want to protect the host-level virtual disk files, and your target is a virtual server on an ESX server.

• ESX servers—The ESX servers that will host your source and target can be any of the following operating systems. Note that ESX versions listed are commonly referred to as the Classic edition.
• ESX 3.5.x Standard, Advanced, or Enterprise
• ESX 4.0.x Standard, Advanced, Enterprise, or Enterprise Plus

Note:

If your source and target are running on different versions of ESX, ideally, the target should be a newer version of ESX. If your source must be a newer version of ESX than the target, you must take into consideration ESX features that are supported on the newer version on the source (like VmxNet enhanced or additional virtual NICs available) that will not be supported on the earlier target version of ESX.

• VirtualCenter—Although VirtualCenter is not required, it is recommended. If you are using it, then you must use version 2.5 or later.

Note:

VMotion is only supported if you are using VirtualCenter. Do not use MSDE for the VirtualCenter database.

• Double-Take Availability for VMware Infrastructure service and console—The service and console can be run from a physical or virtual machine running Windows 7, Windows Vista, or Windows XP, or any of the supported server operating systems.
• Ports—In addition to the standard Double-Take Availability ports that must be opened, you must also open ports 22, 443, and 6331 on the source and target servers.
• E-mail notification—In order to use automatic e-mail notification, you must add VI_Service.exe to the exception list of most anti-virus and spam filters. In addition, you may need to open port 25 in your anti-trust software to allow SMTP e-mail.

Cluster workload requirements

• Standard cluster—If you will be protecting a standard cluster configuration, with a shared SCSI disk, there are two additional requirements.
• Network—The cluster's private network should be a unique subnet so that Double-Take Availability will not attempt to use an unreachable private network.
• Volumes—The source and target should have identical drive mappings.
• GeoCluster—If you will be protecting a GeoCluster configuration, where data is stored on volumes local to each node, there are several additional requirements.
• Operating system—The operating systems are limited to the Windows Enterprise, Itanium, and Datacenter editions listed in the source and target server requirements.
• Volumes—The source and target should have identical drive mappings.
• Hardware—Intel-based hardware is required. Microsoft support for MSCS and MSCS-based Microsoft applications requires that the cluster configuration appear on the Microsoft Hardware Compatibility List under category Cluster.
• Cluster Network Name—Double-Take Availability does not handle dynamic changes to the cluster network names, the names assigned to the routes for network traffic. If a network name is changed for a network that is used by a GeoCluster Replicated Disk resource, the resource must be taken offline, the resource's network property must be changed, and then the resource must be brought back online.
• Protocols and Networking—All of the networking requirements below must be met.
• TCP/IP connection between nodes on the same logical IP subnet
• Your network can contain direct LAN connections or VLAN technology.
• The maximum round trip latency between nodes should be no more than ½ second.
• Multiple networks are recommended to isolate public and private traffic.

Double-Take Console requirements

There are various Double-Take Availability consoles, many of which are being phased out over time. To help consolidate the consoles and help you locate the necessary workflows to complete your work, use the console called Double-Take Console. You must meet the following requirements for the Double-Take Console.

• Operating system—The Double-Take Console can be run from a source or target. It can also be run from a 32-bit or 64-bit physical or virtual machine running Windows 7, Windows Vista, or Windows XP Service Pack 2 or later.

• Microsoft .NET—The Microsoft .NET Framework version 3.5 Service Pack 1 is required to run the console.
• Screen resolution—For best results, use a 1024x768 or higher screen resolution.

Installation

Before beginning the installation, review the Double-Take Availability requirements and Installation and upgrade notes. Use the installation instructions appropriate for the type of workload you are protecting

• Data, full-server, and application workloads—If you are protecting a data workload, full-server workload, or an application workload, you can install using the standard installation program or the command-line automatic installation process.
• Virtual workloads—You can also use the standard installation program or the command-line automatic installation process if you are protecting a virtual workload, however, if your source and target are both virtual machines on an ESX server and you want to protect the host-level virtual disk files, you need to install Double-Take Availability for VMware Infrastructure.
• Clusters—If you are protecting a cluster, the installation will depend on the type of cluster configuration you are using. For standard clusters with a shared SCSI disk, use the standard installation program or use the command-line automatic installation process. For a GeoCluster configuration, where data is stored on volumes local to each node and replicated to each node in the cluster, you will need to configure your cluster appropriately and install Double-Take Availability.

Installation and upgrade notes

Review the following installation and upgrade notes before beginning your installation or upgrade.

• Since Double-Take Availability installs device drivers, it is recommended that you update your Windows Recovery Disk, before installing or making changes to your servers. For detailed instructions on creating a recovery disk, see your Windows reference manuals. Make sure that you select the option to backup the registry when building the repair disks.
• Because Double-Take Availability has operating system dependent files, if you are upgrading your operating system (to a new major version, not a service pack) and have Double-Take Availability installed, you must remove Double-Take Availability prior to the operating system upgrade. Uninstall Double-Take Availability, perform the operating system upgrade, and then reinstall Double-Take Availability.
• If you are installing to a drive other than the drive which contains your system TEMP directory, the Microsoft Windows Installer will still load approximately 100 MB of data to the TEMP directory during the installation. If you do not have enough disk space on the drive that contains the TEMP directory, you may need to change where it is located.
• During installation, a file called dtinfo.exe is installed to the Double-Take Availability installation directory. This program can be run to collect configuration data for use when reporting problems to technical support. It gathers Double-Take Availability log files; Double-Take Availabilityand system registry settings; network configuration information such as IP, WINS, and DNS addresses; and other data which may be necessary for customer support to troubleshoot issues. After running the executable, a zip file is automatically created with the information gathered.
• Double-Take Availability 5.2 is interoperable back to version 5.0 but is restricted to the following limitations. The Double-Take Availability clients can only control the same or earlier releases. To accommodate rolling upgrades, older sources can connect to newer targets, but newer sources cannot connect to older targets. Configurations not listed in the following chart are not supported.

Client	Source	Target	Supported
5.0	5.1 or 5.2	5.1 or 5.2	No
5.1	5.2	5.2	No
5.2	5.0	5.0, 5.1, or 5.2	Yes
5.2	5.1	5.0	No
5.2	5.1	5.1 or 5.2	Yes
5.2	5.2	5.0 or 5.1	No
5.2	5.2	5.2	Yes

• When performing a rolling upgrade, update the target servers first. After the upgrade is complete, the sources will automatically reconnect to the targets. Upgrade the sources when convenient. 
• If you are using a chained configuration, update the last target first, then update the middle server acting as both a source and target, and update the production source last.
• If you are using a configuration where the source is an older version than the target, you will not be able to restore from the newer version target back to the older version source. You must upgrade the source to the same version as the target before restoring.
• Use the following procedure to upgrade Double-Take Availability on a cluster. If both your source and target are clusters, use the following procedure on the target cluster first, then on the source.

1. Move all cluster resources to one node.
2. Upgrade to the new version of Double-Take Availability on all of the other nodes.
3. Move the cluster resources to one of the upgraded nodes.
4. Upgrade to the new version of Double-Take Availability on the last node.
5. If needed, move the cluster resources to the desired nodes.

• If you have protected clusters with an earlier version of the Application Manager, you should disable protection before upgrading to this version of Double-Take Availability.

Installing or upgrading Double-Take Availability

Use these instructions to install Double-Take Availability or upgrade an existing Double-Take Availability installation.

1. Close any open applications.
2. Start the installation program using the appropriate instructions, depending on your media source.
• CD—Load the Double-Take Availability CD into the local CD-ROM drive. If auto-run is enabled, the installation program will start automatically. To manually start the program, select Start, Run and specify <cd_drive>:\autorun.exe.
• Web download—Launch the .exe file that you downloaded from the web.
3. When the installation program begins, the Double-Take Software Setup Launcher appears allowing you to install software and view documentation for various applications from Double-Take Software. The listed applications will depend on which products are included on the CD or in the web download. To install Double-Take Availability, select Double-Take Availability from the list of products. Under Product Installs, select Double-Take Availability.
4. Depending on your version of Windows and the components you have installed, you may see an initial screen indicating that you should install or enable Microsoft .NET Framework. If you do not see this screen, your server already has the appropriate version of Microsoft .NET. You should install or enable Microsoft .NET before installing Double-Take Availability. Click Yes to install Microsoft .NET. Click No to continue without installing .NET.
5. When the Double-Take Availability installation begins, you will be given the opportunity to check for a more recent version of the software.
• If you do not want to check for a later version, select No and click Next.
• If you want to check for a later version, select Yes and click Next. The installation program will establish an Internet connection from your server to the Double-Take Software web site.
• If later versions are found, they will be listed. Highlight the version you want and either download that version and install it automatically or download that version and exit the installation. (If you exit the installation, you can run the updated installation later directly from the location where you saved it.)
• If no later versions are found, continue with the current installation.
• If an Internet connection cannot be established, continue with the current installation or install a previously downloaded version.
6. Review and accept the Double-Take Software license agreement to continue with the installation program. Click Next to continue.
7. Select the type of installation you would like to perform on this machine.
• Client and Server Components—This option installs both the client and server components. The server components are required for systems that will function as a source or target. The server requires an activation code for the service to run. The client does not require an activation code, but it is required to administer this and other servers throughout the organization.
• Client Components Only—This option installs only the client components. The client components do not require an activation code, but are required to administer servers throughout the organization.
• Server Components Only—This option installs only the server components. The server components are required for systems that will function as a source or target. The server requires an activation code for the service to run.
8. If desired, specify where the Double-Take Availability files will be installed.
9. Click Next to continue.
10. You will be prompted to enter your activation code information. Your Activation Code is a 24-character, alpha-numeric activation code which applies the appropriate license to your installation. You must have a valid activation code to use Double-Take Availability. Enter your code and click Add.
11. Click Next to continue.
12. The next screen will depend on the activation code you entered.
• If you have entered a valid activation code, you will be prompted to confirm the code. Click Next to continue the installation.
• If you have entered an invalid activation code, you will be prompted that the code is incorrect and that the source and target modules will not load. Click Back and reenter your activation code.
• If you have entered an evaluation activation code, the expiration date will be displayed and you will be prompted that the source and target modules will not load after that date. Click Next to continue the installation. You must update the activation code to a valid one before the expiration date, otherwise, on the expiration date, Double-Take Availability functionality will be disabled.

13. Double-Take Availability uses system memory to store data in queues. Specify the maximum amount of system memory to be used for the Double-Take Availability queues and click Next to continue.

    If you set the system memory queue lower, Double-Take Availability will use less system memory, but you will queue to disk sooner which may impact system performance. If you set it higher, Double-Take Availability will maximize system performance by not queuing to disk as soon, but the system may have to swap the memory to disk if the system memory is not available. In general, the amount of memory Double-Take Availability and other applications on the server are configured to use should be less than the amount of physical memory on the system to prevent low memory conditions.

14. When the Double-Take Availability system memory queue is exhausted, Double-Take Availability will queue to disk. Specify the size and location of the disk queue. (See Queuing data for guidelines on selecting an appropriate location.) By default, the disk space is set to Unlimited which will allow the queue usage to automatically expand whenever the available disk space expands. Click Next to continue.
15. The Double-Take Availability security information screen appears next. Review this information and click Next to continue with the installation.
16. If you are satisfied with the selections you have made and are ready to begin copying the Double-Take Availability files, click Install.
17. During the installation, you may be prompted to add an exception to the Windows Firewall for Double-Take Availability. Click OK to add the port exception. If you Cancel the port modification, you will have to manually modify your firewall settings for Double-Take Availability processing.
18. After the files have completed copying, click Finish to exit the installation program.

Installing or upgrading Double-Take for VMware Infrastructure

In a typical Double-Take Availability installation, you install the server components on each source and target server. However, when you are protecting the host-level virtual disk files (the .vmdk files) from an ESX source to an ESX target, you need to install the server components on another machine. The Double-Take Availability for VMware Infrastructure service will run from this machine and will communicate with both the source and target servers to handle replication. You may want to consider protecting this machine with Double-Take Availability to keep the machine available because if it becomes unavailable, Double-Take Availability for VMware Infrastructure will be unable to replicate data between the source and target.

In addition to the Double-Take Availability for VMware Infrastructure service, you will need to install the Double-Take Availability for VMware Infrastructure console. The console can be installed on the same machine as the service or it can be installed on a different machine.

Use these instructions to install or upgrade an existing Double-Take Availability for VMware Infrastructure installation.

1. Close any open applications.
2. Start the installation program using the appropriate instructions, depending on your media source.
• CD—Load the Double-Take Availability CD into the local CD-ROM drive. If auto-run is enabled, the installation program will start automatically. To manually start the program, select Start, Run and specify <cd_drive>:\autorun.exe.
• Web download—Launch the .exe file that you downloaded from the web.
3. When the installation program begins, the Double-Take Software Setup Launcher appears allowing you to install software and view documentation for various applications from Double-Take Software. The listed applications will depend on which products are included on the CD or in the web download. To install Double-Take Availability for VMware Infrastructure, select Double-Take Availability from the list of products. Under Product Installs, select Double-Take Availability for VMware Infrastructure.
4. Depending on your version of Windows and the components you have installed, you may see an initial screen indicating that you should install or enable Microsoft .NET Framework. If you do not see this screen, your server already has the appropriate version of Microsoft .NET. You should install or enable Microsoft .NET before installing Double-Take Availability for VMware Infrastructure. Click Yes to install Microsoft .NET. Click No to continue without installing .NET.
5. When the Double-Take Availability for VMware Infrastructure installation begins, click Next.
6. You will be given the opportunity to check for a more recent version of the software.
• If you do not want to check for a later version, select No and click Next.
• If you want to check for a later version, select Yes and click Next. The installation program will establish an Internet connection from your server to the Double-Take Software web site.
• If later versions are found, they will be listed. Highlight the version you want and either download that version and install it automatically or download that version and exit the installation. (If you exit the installation, you can run the updated installation later directly from the location where you saved it.)
• If no later versions are found, continue with the current installation.
• If an Internet connection cannot be established, continue with the current installation or install a previously downloaded version.
7. Review and accept the Double-Take Software license agreement to continue with the installation program. Click Next to continue.
8. Specify where the Double-Take Availability for VMware Infrastructure files will be installed. Click Next to continue.
9. Select the type of installation you would like to perform on this machine.
• Client and Server—This option installs both the Double-Take Availability for VMware Infrastructure service and console components. The service components are required to control replication between a source and target. The service requires an activation code. The console does not require an activation code, but it is required to administer the Double-Take Availability for VMware Infrastructure service.
• Client—This option installs only the Double-Take Availability for VMware Infrastructure console components. The console does not require an activation code, but it is required to administer the Double-Take Availability for VMware Infrastructure service.
10. Click Next to continue.
11. You will be prompted to enter your user name, company name, and activation code information. Your Activation Code is a 24-character, alpha-numeric activation code which applies the appropriate license to your installation.
12. Click Next to continue.
13. If you are satisfied with the selections you have made and are ready to begin copying the Double-Take Availability for VMware Infrastructure files, click Install.
14. After the files have completed copying, click Finish to exit the installation program.

Installing Double-Take Availability automatically

The Double-Take Availability installation program can accept command-line parameters which allow you to automate the installation or upgrade process by running an unattended, or silent, installation. The automatic process allows you to pass parameters through to the installation program instead of entering information manually during the installation or upgrade.

Since the automated process does not prompt for settings, the settings are manually defined in a configuration file called DTSetup.ini. By default, DTSetup.ini contains two sections. The second section can be duplicated as many times as necessary. The first section, [Config], applies to any server not defined in the second (or duplicate of second) sections. The second (or duplicate of second) section, [MachineName], allows you to specify unique settings for individual servers. You have to modify the heading name (case-sensitive) to identify the server.

Review the following table to understand the different parameters available in DTSetup.ini.

Configuring your cluster for GeoCluster installation

If you want to use a GeoCluster configuration, where data is stored on volumes local to each node and replicated to each node in the cluster, complete the cluster configuration appropriate for the operating system you are using.

Double-Take Console

The Double-Take Console is used to protect and monitor your servers and connections. Each time you open the Double-Take Console, you start at the Home page. This page provides a high-level overview of the status of your connections.

The appearance of the Home page is the same for all users. However, other console pages may have variances in the appearance or you may not see some pages at all. The pages and views depend on the Double-Take Software products that you have installed.

• Starting the console
• Getting started
• Managing servers
• Console options
• Other consoles

Starting the console

After you have installed the console, you can launch it by selecting Start, Programs, Double-Take, Double-Take Console.

Getting started

The first time you start the console, it is empty. In order to protect and monitor your servers, you must insert your servers in the console. You can insert servers manually, through Active Directory discovery, or from a console server configuration file.

Inserting servers manually

1. Select Get Started from the toolbar.
2. Select Add servers and click Next.
3. On the Manual Entry tab, specify the server information.
• Server—This is the name of the server to be added to the console.
• User name—Specify a user that is a member of the Double-Take Admin or Double-Take Monitors security group on the server.
• Password—Specify the password associated with the User name you entered.
4. If necessary, specify the domain or protocol under More Options.
• Domain—If you are working in a domain environment, specify the Domain.
• Protocol—Specify the protocol type that the console will use to communicate with the server.
• Automatically detect protocol—Double-Take Availability will check the server to determine the protocol type to use.
• XML web services protocol—Select this option to use XML web services as your protocol. Select this option if your server is running Double-Take Availability version 5.2 or later.
• Legacy protocol—Select this option to use the legacy proprietary Double-Take protocol. Select this option if your server is running Double-Take version 5.1 or earlier.
5. After you have specified the server information, click Add.
6. Repeat steps 3 through 5 for any other servers you want to add.
7. If you need to remove servers from the list of Servers to be added, highlight a server and click Remove. You can also remove all of them with the Remove All button.
8. When your list of Servers to be added is complete, click OK.

You will automatically be taken to the Manage Servers page.

Inserting servers through Active Directory discovery

1. Select Get Started from the toolbar.
2. Select Add servers and click Next.
3. Select the Automatic Discovery tab.
4. Click Discover to search Active Directory for servers running Double-Take Availability.
5. If you need to remove servers from the list of Servers to be added, highlight a server and click Remove. You can also remove all of them with the Remove All button.
6. When your list of Servers to be added is complete, click OK.

You will automatically be taken to the Manage Servers page.

Inserting servers from a server configuration file

You can share the console server configuration between machines that have the Double-Take Console installed. The console server configuration includes the server name, server communications ports, user name, encrypted password, and other internal processing information.

1. To export a server configuration file, select File, Export.
2. Specify a file name and click Save.

After the configuration file is exported, you can import it to another console.

When you are importing a console server configuration file from another console, you will not lose or overwrite any servers that already exist in the console. For example, if you have server alpha in your console and you insert a server configuration file that contains servers alpha and beta, only the server beta will be inserted.

1. To import a server configuration file, select File, Import.
2. Locate the console configuration file saved from the other machine and Open.

After the configuration file is imported, you will automatically be taken to the Manage Servers page.

Managing servers

To manage the servers in your console, select Manage Servers from the toolbar. The Manage Servers page allows you to view, add, edit, or remove servers from your console.

Toolbar Item	Description
	Add a new server. This button leaves the Manage Servers page and opens the Add Servers page
	View detailed information about a server. This button leaves the Manage Servers page and opens the View Server Details page
	Remove the server from the console
	Change the login credentials for a server
	View event messages for a server. This button leaves the Manage Servers page and opens the View Server Events page.

Viewing server details

To view details about a specific server, select View Server Details from the toolbar on the Manage Servers page. The View Server Details page allows you to view details about a particular server.

Viewing server events

To view events associated with a specific server, select View Server Events from the toolbar on the Manage Servers page.The View Server Events page displays the same messages that are logged to the Windows Event Viewer. The list of events are displayed in the top pane of the page, although the Description is limited. When you highlight an event, the event details, including the full Description, are displayed in the bottom pane of the page.

• Severity—An icon or text that classifies the event, such as Error, Warning, Information, Success Audit, or Failure Audit
• Time—The date and time the event occurred
• ID—An identification number to help identify and track event messages.
• Source—The component that logged the event
• Description—The event details

You can filter the events displayed by using the Filter drop-down list or the View warning events and View error events toolbar buttons. To clear a filter, select All events in the Filter drop-down list. See Event messages for a complete list of the service and driver event messages.

Providing server credentials

To update the security credentials used for a specific server, select Provide Credentials from the toolbar on the Manage Servers page. When prompted, specify the User name, Password, and Domain of the account you want to use for this server. Click OK to save the changes.

Managing VirtualCenter servers

To manage your VirtualCenter servers, select Go, Manage VirtualCenter Servers. The Manage VirtualCenter Server page allows you to view, add, remove, or edit credentials for your VirtualCenter servers available in the console.

Toolbar Item	Description
	Add a new VirtualCenter server. When prompted, specify the VirtualCenter server and a user account.
	Remove the VirtualCenter server from the console.
	Edit credentials for the selected VirtualCenter server. When prompted, specify a user account to access the VirtualCenter server.

Console options

There are several options that you can set that are specific to the Double-Take Console. To access these console options, select Options from the toolbar.

• Setting the frequency of console refreshes
• Setting the console communications port
• Updating the console software automatically

Setting the frequency of console refreshes

To access the console refresh rate, select Options from the toolbar. On the Options page, Monitoring interval specifies how often, in seconds, the console refreshes the monitoring data. The servers will be polled at the specified interval for information to refresh the console.

Setting the console communications port

To access the console communications port, select Options from the toolbar. On the Options page, Default port specifies the port that the console will use when sending and receiving data to Double-Take servers. By default, the port is 6325. Changes to the console port will not take effect until the console is restarted.

Updating the console software

By default, each time the console is started, it will automatically check the Double-Take Software web site to see if there is updated console software available. If there is updated console software available, an Automatic Updates section will appear on the Home page. Click Get the latest update to download and install the updated console software.

If you want to disable the automatic check for updates, click Change automatic updates or select Options from the toolbar. On the Options page, deselect Automatically check for updates to disable the automatic check.

You can also manually check for updates by selecting Help, Check for Updates.

• Update available—If there is an update available, click Get Update. The dialog box will close and your web browser will open to the Double-Take Software web site where you can download and install the update.
• No update available—If you are using the most recent console software, that will be indicated. Click Close.
• No connection available—If the console cannot contact the update server of if there is an error, the console will report that information. The console log contains a more detailed explanation of the error. Click Check using Browser if you want to open your browser to check for console software updates. You will need to use your browser if your Internet access is through a proxy server.

Other consoles

There are various Double-Take Availability consoles, many of which are being phased out over time. To help consolidate the consoles and help you locate the necessary workflows to complete your work, use the console called Double-Take Console.

To access this console, select Start, Programs, Double-Take, Double-Take Console. Select Get Started from the toolbar and then select the type of workload protection you want to establish. The appropriate workflow or console will then open.

Use the following links to find more information on the other consoles available.

• Replication Console
• Failover Control Center
• Full-Server Failover Manager
• Application Manager
• Double-Take Availability for VMware Infrastructure console

Replication Console

To open the Replication Console, select Start, Programs, Double-Take, Double-Take Replication Console.

From the Replication Console, you can manage, monitor, and control your data workload connections. The Replication Console is a two pane view. The views in the panes change depending on what is highlighted. For example, when the root of the tree in the left pane is selected, all of the machines in your environment running Double-Take Availability are displayed in the right pane. If you expand the tree in the left pane and select a server, any connections for that server are displayed in the right pane.

• Logging on and off
• Managing the Replication Console tree
• Sharing group and server configuration
• Workspaces
• Clearing maintained security credentials

Logging on and off

To ensure protection of your data, Double-Take Availability offer multi-level security using native operating system security features. Privileges are granted through membership in user groups defined on each machine running Double-Take Availability. To gain access to a particular Double-Take Availability source or target, the user must provide a valid operating system user name and password and the specified user name must be a member of one of the Double-Take Availability security groups. Once a valid user name and password has been provided and the Double-Take Availability source or target has verified membership in one of the Double-Take Availability security groups, the user is granted appropriate access to the source or target and the corresponding features are enabled in the client. Access to Double-Take Availability is granted on one of the following three levels.

• Administrator Access—All Double-Take Availability features are available for that machine. For example, this access level includes creating replication sets and establishing Double-Take Availability connections.
• Monitor Access—Statistics can be viewed on that machine, but Double-Take Availability features are not available. For example, this access level does not allow the user to create or modify replication sets or create or modify Double-Take Availability connections, but does allow you to view the connection statistics for any established Double-Take Availability connections on that machine.
• No Access—The machine appears in the Double-Take Availability Replication Console and can be pinged using a scripting command, but no other access is available.

1. Highlight a machine on the left pane of the Replication Console. By double-clicking the machine name, Double-Take Availability automatically attempts to log you on to the selected machine using the ID that you are currently logged on with. Verify your access by the resulting icon.
2. If you have no access, the Logon dialog box will automatically appear. If you have monitor access or want to log on with a different username, right-click the machine name and select Logon.

3. Specify your Username, Password, Domain, and whether you want your password saved.
4. Click OK and verify your access by the resulting icon and log on again if necessary.

Note:

When logging in, the user name, password, and domain are limited to 100 characters. If your activation code is missing or invalid, you will be prompted to open the Server Properties General tab to add or correct the code. Select Yes to open the Server Properties dialog box or select No to continue without adding an activation code. If the login does not complete within 30 seconds, it is automatically canceled. If this timeout is not long enough for your environment, you can increase it by adjusting the Communication Timeout on the Configuration tab of the Replication Console properties. Select File, Options, from the Replication Console to access this screen. Double-Take Availability uses ICMP pings to verify server availability during the login process. If your Double-Take Availability server is across a router or firewall that has ICMP pings disabled, you will need to disable the Double-Take Availability ICMP ping verification. To do this, select File, Options, from the Replication Console and disable Use ICMP to verify server availability. Double-Take Availability uses the current user's login credentials to attempt to log in to servers. This is called a unified login. If you want to disable unified logins, select File, Options, from the Replication Console and enable Use Named Pipes for Login.

Icon	Description	Access Granted
	This icon is a computer with a gear and it indicates the Double-Take Availability security is set to administrator access.	Administrator rights
	This icon is a computer with a magnifying glass and it indicates the Double-Take Availability security is set to monitor only access.	Monitor rights
	This icon is a lock and it indicates the Double-Take Availability security is set to no access.	No rights

5. To log off of a Double-Take Availability machine, right-click the machine name on the left pane of the Replication Console and select Logout.

Managing the Replication Console tree

To better manage the servers that appear in the Replication Console, you can customize the server display to fit your needs. You can create groups and move servers to those groups to help you organize your environment. Within the groups, you can insert, remove, hide or unhide servers. Each of these functions is detailed in the following sections.

Groups

The left pane of the Replication Console is a tree view of the Double-Take Availability servers. By default, the first group in the tree is the Discovered Servers group. All Double-Take Availability servers that are automatically discovered will be added to this group. Use server groups in a hierarchical structure to help you organize your environment.

Servers

Within your server groups, you have the ability to further manage the servers that are displayed by using the following functions.

Sharing group and server configuration

All of the group and server information is stored on the local machine for each user. When you close the Replication Console, the group information is saved and will be persisted the next time you open the Replication Console on this machine. If you want to share the group configuration with another user or machine, you can export the group configuration information (File, Export server group configuration) to an .xml file. That file can then be copied and imported (File, Import server group configuration) by another user on this machine or to another machine.

Workspaces

The Replication Console workspace contains the display of the panes of the Replication Console and any servers that may have been inserted. Multiple workspaces can be used to help organize your environment or to view settings from another machine.

Clearing maintained security credentials

To remove cached credentials, select File, Options and select the Security tab. To remove the security credentials, enable Clear Cached Security Credentials and then click OK.

Failover Control Center

To open the Failover Control Center, select Start, Programs, Double-Take, Availability, Double-Take Availability Failover Control Center.

The Failover Control Center should be run from your target server or a client machine. Do not run the Failover Control Center from your source server.

From the Failover Control Center, you can manage, monitor, and control failover for your Double-Take Availability servers. The Failover Control Center displays a main window for monitoring failover activity. Control buttons to the right allow you to configure and manage your servers.

• Configuring communication ports
• Configuring the console refresh rate
• Clearing maintained security credentials

Configuring communication ports

The Failover Control Center uses port 6320, by default for Double-Take Availability communications. To view or modify the port settings in the Failover Control Center, select Settings, Communications.

Configuring the console refresh rate

The failover client periodically requests information from the source and target. Depending on the type of information, the request may be a machine-specific request, like obtaining the Time to Fail status from a target, or may be a general request, like determining which machines are running Double-Take Availability.

The rate at which these requests are made can be modified through the Failover Control Center refresh rate dialog box. Select Settings, Refresh Rate. The default update interval is one second. A lower refresh rate value updates the information in the Failover Control Center window's Monitored Machines tree more often, but also generates more network traffic and higher utilization on the client and target machines. A higher refresh rate value updates the information less frequently, but minimizes the network traffic.

Clearing maintained security credentials

To remove cached credentials, access the credentials security option, by selecting Settings, Security. To remove the security credentials, enable Clear Cached Security Credentials and then click OK.

Full-Server Failover Manager

To open the Full-Server Failover Manager, select Start, Programs, Double-Take, Availability, Double-Take Availability Full-Server Failover Manager.

The Full-Server Failover Manager allows you to create your source and target connection, monitor your full-server workload protection, manage your full-server snapshots, and initiate full-server failover.

The client is a simple interface with four numbered steps. Steps 1 and 2 for the source and target have to be completed before the other steps are available or the Protection Status is displayed.

• Configuring the console refresh rate
• Configuring the level of detail to log
• Clearing maintained security credentials
• Configuring the monitoring method for server availability
• Saving and reusing configuration options

Configuring the console refresh rate

Select File, Options. By default, the main window of Full-Server Failover Manager will automatically update every five (5) seconds. If desired, you can modify the Refresh Interval. You can also refresh the main window manually by selecting File, Refresh.

Configuring the level of detail to log

Select File, Options. By default, Full-Server Failover Manager creates a log that maintains all processing information. If desired, you can disable the option Enable Verbose Logging so that only basic processing information is logged.

Clearing maintained security credentials

Select File, Options. By default, Full-Server Failover Manager will save the user credentials supplied for each servers. If desired, you can enable Clear cached credentials on exit so they are not saved. You can also clear the user credentials manually by selecting File, Clear Cached Credentials.

Configuring the monitoring method for server availability

Select File, Options. By default, Full-Server Failover Manager will use ICMP pings to check for server availability. If you do not want to use ICMP pings, select Do not use ICMP Ping. When this option is selected, the Full-Server Manager will use the Double-Take service to check for server availability.

Saving and reusing configuration options

After you have created a protection pair and configured any of the optional settings you can save those settings so that you can reuse them for future pairs of servers. Once you have the settings the way you want them, save them by selecting File, Defaults, Save Current Settings as Defaults. This creates a file called FFMDefaults.xml, which will automatically be the default settings the next time you use the Full-Server Failover Manager. If desired, you can rename the FFMDefaults.xml file and then save a new set of defaults to FFMDefaults.xml to be used by the Full-Server Failover Manager. This would allow you to have multiple failover configurations, which can be more easily interchanged. You can also use these different files to initiate failovers without using the Full-Server Failover Manager GUI.

If you want to reset the configuration settings back to the default settings, select File, Defaults, Reset Defaults.

Application Manager

To open the Application Manager, select Start, Programs, Double-Take, Availability, Double-Take Availability Application Manager.

The Application Manager allows you to establish application protection, monitor that protection, and initiate application failover and failback.

When you select an application to protect in the Tasks list on the left pane, the Setup tab on the right pane is a simple interface with four numbered steps. Steps 1 and 2 are for the domain and servers. Step 3 is optional configuration and step 4 validates the servers.

After protection has been established, use the Monitor tab to check on the status of your protection.

• Adding or managing servers
• Changing Application Manager preferences

Adding or managing servers

Step 2 of the application protection workflow is to select your source and target servers. If no servers are populated in the lists (perhaps the server you need is in a child domain), click Advanced Find to add servers to the lists. Advanced Find is not available for all application protections.

1. Click Search to locate all the application servers that Application Manager can discover in the domain. If you have a large number of servers in Active Directory, this search may take awhile.
2. Highlight servers in the Discovered Servers list and move them to the Current Servers list to add them to the Application Manager console.
3. To add a non-discovered server, type the server name below the Current Servers list and click Add.
4. To remove any servers from the Application Manager console, highlight the server name in the Current Servers list and click Remove.
5. For some applications, you can click the Test SQL button to have Application Manager check to see if the application is installed and accessible on the selected server.
6. When you have finished managing your servers, click OK.

Changing Application Manager options

To modify Application Manager options, select Tools, Options and modify any of the following options.

• Service Listen Port—This is the port used for Double-Take Availability communications. This port must be the same on the client machine and the source and target servers.
• Enable automatic adjust of refresh interval—When this option is enabled, the Application Manager will automatically adjust the rate at which protection status is refreshed.
• Refresh Interval—If you want to specify an exact interval for refreshing the Application Manager protection status, disable the automatic adjustment option and specify a length of time, in seconds, for to refresh the status.
• Maximum log file size—Specify the maximum size of the dtam.verbose.log file. When the maximum size is reached, the log file will be renamed to dtam.verbose.prev.log and a new log file will be used.
• Enable verbose logging—When enabled, this options logs all user interactions in the Application Manager to the dtam.verbose.log file.
• Always show protection details—When enabled, the Protection Details area on the Monitor tab will be expanded by default. When disabled, the area will be collapsed by default.
• Display statistics values in bytes—When enabled, values displayed in the Protection Details area on the Monitor tab will shown in bytes. When disabled, the values will be shown in MB, GB, or TB.
• Load last selected server upon startup—This option automatically reconnects to the last protected source and target pair each time the Application Manager is started.
• Enable Alternative DNS—This option opens the Application Manager in \altdns mode on subsequent restarts so that Application Manager will not check for Microsoft DNS. See Non-Microsoft DNS for more information.
• Display advanced options—This option opens the Application Manager in \advanced mode on subsequent restarts.
• Use Primary Dns Zone—When enabled, the next time you start Application Manager, the server's primary DNS suffix will be used for the fully-qualified domain name if the server is listed in more than one DNS zone.
• Clear Cached Credentials—Click this button to clear all server credentials stored in Application Manager.

Double-Take Availability for VMware Infrastructure console

To open the Double-Take Availability for VMware Infrastructure console, select Start, Programs, Double-Take, Availability, Double-Take Availability for VMware Infrastructure.

The first time you use the console or if you have not saved your login information, you will be prompted to provide login information. Specify the Server, which is the machine running the Double-Take Availability for VMware Infrastructure service, and a User name and Password. If you do not want to provide login information each time you open the console, enable Save DTAVI connection information.

The Double-Take Availability for VMware Infrastructure console allows you to establish protection of host-level virtual disk files (the .vmdk files) from an ESX source to an ESX target. You can also initiate failover and failback.

The left pane is a tasks-style pane. When an item in the left pane is selected, the right pane of the console display updates to the corresponding workflow or page.

• Managing activation codes
• Managing VirtualCenter servers
• Managing ESX servers
• Setting up an e-mail server

Managing activation codes

You can manage your Double-Take Availability for VMware Infrastructure activation codes by selecting Go, Manage activation codes.

Enter a new activation code and click Add. To remove a code, highlight in the list and click Remove.

Each activation code corresponds to a number of slots, where each slot represents the capacity to protect a single virtual machine in your environment. Each time protection is established, Double-Take Availability for VMware Infrastructure will update the available number of slots for subsequent protections.

Managing VirtualCenter servers

To manage your VirtualCenter servers, select Manage VirtualCenter servers from the left pane of the console.

• Adding a VirtualCenter server—Click Add VirtualCenter server on the toolbar. On the Add VirtualCenter server page, specify the IP address or DNS Name of the VirtualCenter server and supply a User name and Password. Click Save to insert the VirtualCenter server.
• Configuring credentials for a VirtualCenter server—Highlight a VirtualCenter server in the list and click Configure VirtualCenter server on the toolbar. On the Set VirtualCenter server credentials page, specify the updated User name and Password and click Save.
• Removing a VirtualCenter server—Highlight a VirtualCenter server in the list and click Remove VirtualCenter server on the toolbar.

Managing ESX servers

To manage your ESX servers, select Manage ESX servers from the left pane of the console. Double-Take Availability for VMware Infrastructure scans to find ESX servers that are VMotion destination candidates, based upon SAN connectivity. The Credentials Cached column in the table identifies servers that need to have credentials added. To add the credentials, highlight a server in the list and click Configure ESX server on the toolbar. On the Configure ESX server page, add, edit, or remove a user. If prompted, specify the password associated with the user. Click Done to save the modficiations.

If you need to add an ESX server, click Add ESX server on the toolbar. On the Add ESX server page, specify the VirtualCenter server, the IP address or DNS name of the ESX server, a User name. and Password. Click Save to insert the ESX server.

If you need to remove an ESX server, highlight an ESX server in the list and click Remove ESX server.

Setting up an e-mail server

To set up an e-mail server, select Set up e-mail server from the left pane of the console. E-mail configuration applies to all protection jobs. Specify the e-mail server configuration.

• From address—Specify the e-mail address that you wan to appear in the From field of each message.
• SMTP server—Specify the SMTP server using the full Active Directory DNS name, the IP address, or the NetBIOS short name.
• User name—Specify a user account with privileges to send e-mail messages from your SMTP server.
• Password—Specify the password associated with the User name you entered.

Click Save to save your settings.

Workload protection

Double-Take Availability flexible configurations allow you to protect different workloads depending on the needs of your organization.

• Specific data—You can protect specific data (volumes, directories, files, and/or wildcards). In the event of a failure, the data you protected is available on the target.
• Entire server—You can protect an entire server, including the data and system state, which is the server's configured operating system and applications. In the event of failure, the target becomes the source.
• Applications—You can protect applications, including Exchange, SQL, SharePoint, BlackBerry, or a Windows file server. In the event of a failure, the data you protected is available on the target.
• Virtual servers—You can protect physical or virtual machine to a virtual machine on the VMware ESX or the Microsoft Hyper-V platform.
• Clusters—You can protect your cluster configuration, either a standard cluster or a GeoCluster.

Data protection

Protecting specific data consists of two main tasks - creating a replication set (to identify the data to protect) and connecting that replication set to a target.

You have the following data protection options.

• Automated process—If you would like to use an automated process that walks you through both the replication and connection tasks, you only need to complete the steps Establishing a connection using the automated Connection Wizard.
• Manual process—If you want to go through the tasks manually, begin by Creating a replication set and then continue with Establishing a connection manually using the Connection Manager.
• NAT or firewall—If your environment has a NAT or firewall configuration, you will need to begin with Creating a replication set and then follow the instructions for Establishing a connection across a NAT or firewall.
• Simulating a connection—If you want to simulate a connection for planning purposes, begin by Creating a replication set and then continue with Simulating a connection.

Once your connection is established, move on with Data workload failover to ensure high availability.

Establishing a connection using the automated Connection Wizard

The Connection Wizard guides you through the process of protecting your data. It helps you select a source, identify the data from your source that will be included in the replication set, and select a target.

1. From the Replication Console, start the Connection Wizard to establish your connection. If you have just opened the Replication Console, you can click Make a connection from the right pane of the Replication Console. If the quick launch screen is no longer visible, select Tools, Connection Wizard.

Note:

If the Servers root is highlighted in the left pane of the Replication Console, the Connection Wizard menu option will not be available. To access the menu, expand the server tree in the left pane, and highlight a server in the tree.

2. The Connection Wizard opens to the Welcome screen. Review this screen and click Next to continue.

Note:

At any time while using the Connection Wizard, click Back to return to previous screens and review your selections.

3. If you highlighted a source in the Replication Console, the source will already be selected. If it is not, select the Double-Take Availability source. This is the server where the files reside that you want to protect.

Note:

Double-Take Availability will automatically attempt to log on to the selected source using the identification of the user logged on to the local machine. If the logon is not successful, the Logon dialog box will appear prompting for your security identification. When logging in, the user name, password, and domain are limited to 100 characters.

4. Click Next to continue.
5. If you highlighted a target in the Replication Console, the target will already be selected. If it is not, select the Double-Take Availability target. This is your backup server that will protect the source.

Note:

Double-Take Availability will automatically attempt to log on to the selected target using the identification of the user logged on to the local machine. If the logon is not successful, the Logon dialog box will appear prompting for your security identification. When logging in, the user name, password, and domain are limited to 100 characters.

6. Click Next to continue.
7. Choose to create a new replication set or use a replication set that already exists.

• Create a new replication set with this name—If you choose to create a new replication, specify a replication set name.
• Use this replication set—If you choose to use an existing replication set, specify the name of that replication set by selecting it from the pull-down menu.

8. Click Next to continue.
9. If you are creating a new replication set, a tree display appears identifying the volumes and directories available on your selected source server. Mark the check box of the volumes and/or directories you want to protect and click Next to continue.
10. Select the location on the target where the data will be stored.

• Send all data to a single path on the target—This option sends all selected volumes and directories to the same location on the target. The default location is \source_name\replication_set_name\volume_letter.
• Send all data to the same path on the target—This option sends all selected volumes and directories to the same directories on the target. For example, c:\data and d:\files on the source will go to c:\data and d:\files on the target.
• Custom—To select a custom path, click once in the Target Path field and modify the drive and directory to the desired location.

11. Click Next to continue.
12. Review your selections on the summary screen. If your Connection Wizard settings are correct, establish your connection by completing one of the two options below:

• If you do not want to set advanced options, click Finish. The Connection Wizard will close, the connection will be established, and mirroring and replication will begin.
• If you want to set advanced options, click Advanced Options. The Connection Wizard will close and the Double-Take Availability Connection Manager will open. The Servers tab will be completed.

Creating a replication set

Before you can establish a connection, you must create a replication set.

1. From the Replication Console, highlight a source in the left pane of the Replication Console and select Insert, Replication Set from the menu bar. You can also right-click on the source name and select New, Replication Set.
2. A replication set icon appears in the left pane under the source. By default, it is named New Replication Set. Rename the newly inserted replication set with a unique name by typing over the default name and pressing Enter. This process is similar to naming a new folder in Windows Explorer.
3. Expand the tree under the replication set name to view the volume and directory tree for the source.

Note:

The default number of files that are listed in the right pane of the Replication Console is 2500, but this is user configurable. A larger number of file listings allows you to see more files in the Replication Console, but results in a slower display rate. A smaller number of file listings displays faster, but may not show all files contained in the directory. To change the number of files displayed, select File, Options and adjust the File Listings slider bar to the desired number. To hide offline files, such as those generated by snapshot applications, select File, Options and disable Display Offline Files. Offline files and folders are denoted by the arrow over the lower left corner of the folder or file icon.

4. Identify the data on the source that you want to protect by selecting volumes, drives, directories, and/or specific files.

5. After selecting the data for this replication set, right-click the new replication set icon and select Save. A saved replication set icon will change from red to black.

Establishing a connection manually using the Connection Manager

After you have created a replication set, you can establish a connection through the Connection Manager by connecting the replication set to a target.

1. From the Replication Console, open the Connection Manager to establish the connection.

• Highlight the replication set and select Tools, Connection Manager.
• Right-click on the replication set and select Connection Manager.
• Drag and drop the replication set onto a target. The target icon could be in the left or right pane of the Replication Console.

2. The Connection Manager opens to the Servers tab. Depending on how you opened the Connection Manager, some entries on the Servers tab will be completed already. For example, if you accessed the Connection Manager by right-clicking on a replication set, the name of the replication set will be displayed in the Connection Manager. Verify or complete the fields on the Servers tab.

• Source Server—Specify the source server that contains the replication set that is going to be transmitted to the Double-Take Availability target.
• Replication Set—At least one replication set must exist on the source before establishing a connection. Specify the replication set that will be connected to the target.
• Target Server—Specify which Double-Take Availability target will maintain the copy of the source’s replication set data. You can specify a machine name, IP address, or virtual IP address.
• Route—This is an optional setting allowing you to specify the IP address and port on the target that the data will be transmitted through. This allows you to select a different route for Double-Take Availability traffic. For example, you can separate regular network traffic and Double-Take Availability traffic on a machine with multiple IP addresses.
• Mappings—You must specify the location on the target where the source’s replication set data will reside. Double-Take Availability offers two predefined locations as well as a custom option that allows you to create your own path.
• All To One—This option replicates data from the source to a single volume on the target. The pre-defined path is \source_name\replication_set_name\volume_name. If you are replicating from multiple volumes on the source, each volume would be replicated to the same volume on the target. For example, c:\data and d:\files for the source Alpha and replication set DataFiles would be replicated to c:\alpha\DataFiles\c and c:\alpha\DataFiles\d, respectively.
• One To One—This option replicates data from the source to the same directory structure on the target. For example, c:\data and d:\files on the source will be replicated to c:\data and d:\files, respectively, on the target.
• Custom Location—If the predefined options do not store the data in a location that is appropriate for your network operations, you can specify your own custom location where the replicated files will be sent. Click the Target Path and edit it, selecting the appropriate location.

Note:

If you are mirroring and replicating dynamic volumes or mount points, your location on the target must be able to accommodate the amount of data that you are replicating. If you are mirroring and replicating sparse files and your location on the target is a non-NTFS 5 volume, the amount of disk space available must be equal to or greater than the entire size of the sparse file. If you are mirroring and replicating to an NTFS 5 volume, the amount of disk space available must be equal to or greater than the on-disc size of the sparse file. If you are mirroring and replicating multiple mount points, your directory mapping must not create a cycle or loop. For example, if you have the c: volume mounted at d:\c and the d: volume mounted at c:\d, this is a circular configuration. If you create and connect a replication set for either c:\d or d:\c, there will be a circular configuration and mirroring will never complete.

• Start Mirror on Connection—Mirroring can be initiated immediately when the connection is established. If mirroring is not configured to start automatically, you must start it manually after the connection is established.

Warning:

Data integrity cannot be guaranteed without a mirror being performed. This option is recommended for the initial connection.

• Start Replication on Connection—Replication can be initiated immediately when the connection is established. If replication is not configured to start automatically, you must start it manually after the connection is established. If you disable this option, you will need to perform a mirror prior to beginning replication to guarantee integrity.
• Block Target Path(s) on Connection—You can block writing to the data located in the target paths. This keeps the data from being changed outside of Double-Take Availability processing. If you are going to use failover, any target paths that are blocked will automatically be unblocked during the failover process so that users can modify data on the target after failover. During a restoration, the paths are automatically blocked again. If you failover and failback without performing a restoration, the target paths will remain unblocked. You can manually block or unblock the target paths by right-clicking on a connection.

3. If desired, you can configure mirror settings before establishing your connection. Select the Mirroring tab on the Connection Manager.

• Full Mirror—All files in the replication set will be sent from the source to the target.
• File Differences—Only those files that are different based on date, time, and/or size will be sent from the source to the target.
• Send data only if Source is newer than Target—Only those files that are newer on the source are sent to the target.

Note:

If you are using a database application, do not use the newer option unless you know for certain you need it. With database applications, it is critical that all files, not just some of them that might be newer, get mirrored.

• Use block checksum—For those files flagged as different, the mirror performs a checksum comparison and only sends those blocks that are different.

Note:

Stopping, starting, pausing, or resuming mirroring contains a comparison of how the file difference mirror settings work together, as well as how they work with the global checksum setting on the Source tab of the Server Properties.

• Remirror on Auto-Reconnect—In certain circumstances, for example if the disk-based queues on the source are exhausted, Double-Take Availability will automatically disconnect connections (called auto-disconnect) and then automatically reconnect them (called auto-reconnect). In order to ensure data integrity on the target, Double-Take Availability will perform an automatic mirror (called an auto-remirror) after an auto-reconnect. If you enable this option, specify the type of auto-remirror that will be performed.
• File Differences with Checksum—Any file that is different on the source and target based on date, time, and/or size is flagged as different. The mirror then performs a checksum comparison on the flagged files and only sends those blocks that are different.
• File Differences with no Checksum—Any file that is different on the source and target based on date, time, and/or size is sent to the target.
• Send data only if Source is newer than Target—Only those files that are newer on the source are sent to the target.

Note:

Stopping, starting, pausing, or resuming mirroring contains a comparison of how the file difference mirror settings work together, as well as how they work with the global checksum setting on the Source tab of the Server Properties.

• Full—All files are sent to the target.

Note:

Database applications may update files without changing the date, time, or file size. Therefore, if you are using database applications, you should use the File Differences with checksum or Full option.

• Calculate Replication Set size on connection—Determines the size of the replication set prior to starting the mirror. The mirroring status will update the percentage complete if the replication set size is calculated.

4. Click Connect to establish the connection.

Note:

The settings on the other tabs of the Connection Manager are advanced settings. You can modify any of them before or after establishing your connection. If you decide to enable orphan file processing while you are establishing your connection, orphan files will not be immediately processed when you create the connection. This setting is for processes that are run after a connection is already established (remirror, auto-remirror, verification, and so on).

Establishing a connection across a NAT or firewall

If your source and target are on opposite sides of a NAT or firewall, you will need special configurations to accommodate the complex network environment. Additionally, you must have the hardware already in place and know how to configure the hardware ports. If you do not, see the reference manual for your hardware.

In this environment, you must have static mapping where a single, internal IP address is always mapped in a one-to-one correlation to a single, external IP address. Double-Take Availability cannot handle dynamic mappings where a single, internal IP address can be mapped to any one of a group of external IP addresses managed by the router.

1. Double-Take Availability uses specific ports for communication between the Double-Take Availability servers and Double-Take Availability clients. In order to use Double-Take Availability through a NAT or firewall, you must first verify the current Double-Take Availability port settings so that you can open the correct ports on your hardware to allow Double-Take Availability machines to communicate with each other. By default, Double-Take Availability uses port 6320 for all communications. If you have changed your Double-Take Availability port, you will need to identify what port number is being used. The port setting can be found in the following locations.

• Replication Console—From the Replication Console, select File, Options, and the Configuration tab.
• Failover Control Center—From the Failover Control Center, select Settings, Communications.
• Double-Take Availability server—From the Replication Console, right-click on a server in the tree in the left pane of the Replication Console, select Properties, and the Network tab.

Note:

If you change any of the port settings, you must stop and restart the Double-Take service for the new port setting to take effect.

2. You need to configure your hardware so that Double-Take Availability traffic is permitted access through the router and directed appropriately. Configure your router identifying each Double-Take Availability server, its IP address, and the Double-Take Availability and router ports. Also, note the following caveats.

• Since Double-Take Availability communication occurs bidirectionally, make sure you configure your router for both incoming and outgoing traffic for all of your Double-Take Availability servers and Double-Take Availability clients.
• Double-Take Availability failover can use ICMP pings to determine if the source server is online. If you are going to use ICMP pings and a router between the source and target is blocking ICMP traffic, failover monitors cannot be created or used. In this situation, you must configure your router to allow ICMP pings between the source and target.

Since there are many types of hardware on the market, each can be configured differently. See your hardware reference manual for instructions on setting up your particular router.

3. Manually insert the servers, by selecting Insert, Server. Type the IP address of the router the server is connected to and the port number the server is using for heartbeats.
4. Once your server is inserted in the Replication Console, use the Connection Manager to establish your connection. When specifying the Route on the Connection Manager Servers tab, you can manually enter the external IP address so traffic is routed appropriately.

Simulating a connection

Double-Take Availability offers a simple way for you to simulate a connection in order to generate statistics that can be used to approximate the time and amount of bandwidth that the connection will use when actively established. This connection uses the TDU (Throughput Diagnostics Utility), which is a built-in null (non-existent) target to simulate a real connection. No data is actually transmitted across the network. Since there is no true connection, this connection type helps you plan for a disaster recovery solution.

Before and after simulating your connection, you should gather network and system information specific to Double-Take Availability operations. Use the DTInfo utility to automatically collect this data. It gathers Double-Take Availability log files; Double-Take Availability and system settings; network configuration information such as IP, WINS and DNS addresses; and other data which may be necessary in evaluating Double-Take Availability performance. The DTInfo utility can be found on the product CD, in the Double-Take Availability installation directory, or on the Double-Take Software support web site.

1. From the source where you will be running the TDU, run DTInfo.exe. It may take several minutes for DTInfo to finish processing. After DTInfo processing is complete, a \support subdirectory will automatically be created in the Double-Take Availability installation directory. A .zip file will contain the information gathered. The file name is based on the machine name. To distinguish this file from the next time you run DTInfo, append a unique identifier, perhaps the date and time, to the end of the file name.
2. Make sure you have created a replication set that contains the data you want to protect.
3. From the Replication Console, open the Connection Manager to establish the connection.

• Highlight the replication set and select Tools, Connection Manager.
• Right-click on the replication set and select Connection Manager.

4. The Connection Manager opens to the Servers tab. Depending on how you opened the Connection Manager, some entries on the Servers tab will be completed already. For example, if you accessed the Connection Manager by right-clicking on a replication set, the name of the replication set will be displayed in the Connection Manager. Verify or complete the fields on the Servers tab.

• Source Server—Specify the source server that contains the replication set that is going to be simulated to the TDU.
• Replication Set—At least one replication set must exist on the source before establishing a connection. Specify the replication set that will be connected to the TDU.
• Target Server—Select the Diagnostics target.
• Route—After selecting the Diagnostics target, the Route will automatically be populated with Throughput Diagnostics Utility (TDU).
• Mappings—Mappings are not required when simulating a connection because no data is actually transmitted to the target.
• Start Mirror on Connection—Make sure this option is selected so that your simulation will be realistic.
• Start Replication on Connection—Make sure this option is selected so that your simulation will be realistic.
• Block Target Path(s) on Connection—This option is not needed when simulating a connection because no data is actually transmitted to the target.

5. Click Connect to establish the connection. The simulation data will be logged to the Double-Take Availability statistics file.
6. Repeat step 1 to run the diagnostics utility after the simulation is complete.

Data workload failover

When you established your data workload protection, you only protected the data. You still need to establish failover monitoring, so that the target can stand in for the source in the event of a source failure, and your end users can access the data from the target.

• Configuring failover monitoring
• Updating shares on the target
• Editing failover monitoring configuration
• Removing failover monitoring configuration

Configuring failover monitoring

1. Open the Failover Control Center from your target server or a client machine. Do not run the Failover Control Center from your source server.
2. Select a failover target from the Target Machine list box.

Note:

If the target you need is not listed, click Add Target and manually enter a name or IP address (with or without a port number). You can also select the Browse button to search for a target machine name. Click OK to select the target machine and return to the Failover Control Center main window.

3. Click Login to login to the selected target.
4. Select a source machine to monitor by clicking Add Monitor. The Insert Source Machine dialog box appears in front of the Monitor Settings dialog box.
5. On the Insert Source Machine dialog, specify your source machine by any of the following methods.

• Type the name of the machine that you want to monitor in Machine Name(s) and click OK.
• Click Browse to search for a machine. Select a domain from the list box at the top of the Select Machine dialog box to list the available machines for that domain. Highlight a source to be monitored and click OK.
• Click Custom. Enter the name of the server and click Add. Specify the IP address and subnet mask of the specified server and click OK. Click OK again.

The Insert Source Machine dialog closes and the Monitor Settings dialog remains open with your source listed in the Names to Monitor tree.

6. In the Names to Monitor tree, locate and select the IP addresses on the source that you want to monitor.
7. Highlight an IP address that you have selected for monitoring and select a Target Adapter that will assume that IP address during failover. Repeat this process for each IP address that is being monitored. Current IP Addresses displays the IP address(es) currently assigned to the selected target adapter.
8. Highlight an IP address that you have selected for monitoring and select a Method to Monitor for Failover.

• Network Service—Source availability will be tested for by a Double-Take Availability network response
• Replication Service—Source availability will be tested for by a Double-Take service response.
• Network and Replication—Source availability will be tested for by both a Double-Take Availability network response and a Double-Take service response.
• No Monitoring—Double-Take Availability does not actively monitor the source. You will be responsible for identifying when a failure has occurred and initiating failover manually.

9. Repeat step 8 for each IP address that is being monitored.
10. Highlight an IP address that you have selected for monitoring and select a Monitor Interval. This setting identifies the number of seconds between the monitor requests sent from the target to the source to determine if the source is online. This option is not configurable if your Method to Monitor for Failover is set to No Monitoring. Repeat this step for each IP address that is being monitored.
11. Highlight an IP address that you have selected for monitoring and select the Missed Packets. This setting is the number of monitor replies sent from the source to the target that can be missed before assuming the source machine has failed. This option is not configurable if your Method to Monitor for Failover is set to No Monitoring. Repeat this step for each IP address that is being monitored.

Note:

To achieve shorter delays before failover, use lower Monitor Interval and Missed Packets values. This may be necessary for IP addresses on machines, such as a web server or order processing database, which must remain available and responsive at all times. Lower values should be used where redundant interfaces and high-speed, reliable network links are available to prevent the false detection of failure. If the hardware does not support reliable communications, lower values can lead to premature failover. To achieve longer delays before failover, choose higher values. This may be necessary for IP addresses on slower networks or on a server that is not transaction critical. For example, failover would not be necessary in the case of a server restart.

12. If you are monitoring multiple IP addresses, highlight the source name and specify the Failover Trigger.

• All Monitored IP Addresses Fail—Failover begins when all monitored IP addresses fail. If there are multiple, redundant paths to a server, losing one probably means an isolated network problem and you should wait for all IP addresses to fail.
• One Monitored IP Address Fails—Failover begins when any one of the monitored IP addresses fails. If each IP address is on a different subnet, you may want to trigger failover after one fails.

13. If Manual Intervention is enabled, Target Data State at Failover will be disabled because the same options will be presented to you at failover time. If Manual Intervention is disabled, the options will be enabled so that an option can be selected to occur automatically when failover occurs. Highlight the source name and specify the Target Data State at Failover by specifying what data you want to use on the target when failover occurs.

• Apply Data in Target Queues Then Failover—All of the data in the target queue will be applied before failover begins. Depending on the amount of data in queue, the amount of time to apply all of the data could be lengthy.
• Discard Data in Target Queues and Failover Immediately—All of the data in the target queue will be discarded and failover will begin immediately. Any data in the target queue will be lost.
• Revert to Last Good Snapshot if Target Data is Bad—If the target data is in a bad Double-Take Availability state, Double-Take Availability will automatically revert to the last good Double-Take Availability snapshot before failover begins. You will lose any data between the last good snapshot and the failure. If the target data is in a good state, Double-Take Availability will not revert the target data. Instead, Double-Take Availability will apply the data in the target queue and then failover. Depending on the amount of data in queue, the amount of time to apply all of the data could be lengthy.

14. Highlight the source name and specify the Items to Failover, which identifies which source components you want to failover to the target.

• IP Addresses—If you want to failover the IP addresses on the source, enable this option and then specify the addresses that you want to failover.
• Monitored—Only the IP address(es) that are selected for monitoring will be failed over.
• All—All of the IP address(es) will be failed over.

Note:

If you are monitoring multiple IP addresses, IP address conflicts may occur during failover when the number of IP addresses that trigger failover is less than the number of IP addresses that are assumed by the target during failover. For example, if a source has four IP addresses (three public and one private), and two of the three public addresses are monitored, but all three public addresses are configured to failover, a conflict could occur. If the source fails, there is no conflict because all of the IP addresses have failed and no longer exist. But if the failure only occurs on one of the monitored addresses, the other two IP addresses are still affected. If all of the addresses are failed over, these addresses then exist on both the source and the target. Therefore, when a source machine has fewer IP addresses that trigger failover than IP addresses that will be failed over, there is a risk of an IP address conflict. If your network environment is a WAN configuration, do not failover your IP addresses unless you have a VPN infrastructure so that the source and target can be on the same subnet, in which case IP address failover will work the same as a LAN configuration. If you do not have a VPN, you can automatically reconfigure the routers via a failover script (by moving the source's subnet from the source's physical network to the target's physical network). There are a number of issues to consider when designing a solution that requires router configuration to achieve IP address failover. Since the route to the source's subnet will be changed at failover, the source server must be the only system on that subnet, which in turn requires all server communications to pass through a router. Additionally, it may take several minutes or even hours for routing tables on other routers throughout the network to converge.

• Server Name—Failover is performed on the server name. If you specify the server name to be failed over, first Double-Take Availability checks the hosts file and uses the first name there. If there is no hosts file, Double-Take Availability uses the first name in DNS. (Although, the first name in DNS may not always be the same each time the DNS server is rebooted.) Lastly, if there is no DNS server, Double-Take Availability uses the Failover Control Center monitor name.
• Shares—Failover is performed on shares.

Note:

Automatic share failover only occurs for standard Windows file system shares. Other shares must be configured for failover through the failover scripts or created manually on the target. See Macintosh shares or NFS Shares for more information. If you are failing over Windows shares but your source and target do not have the same drive letters, you must use the All to One selection when establishing your Double-Take Availability connection. Otherwise, the shares will not be created on the target during failover. If a Windows share is created on Windows 2003 with the default full access permissions (without an ACL) and then failed over, the permissions given to the target will be read-only permissions. Windows share information is automatically updated on the target once an hour. If you need to manually update the share information, click Update Shares on the main Failover Control Center window after the monitor has been established.

15. By default, Manual Intervention is enabled, allowing you to control when failover occurs. When a failure occurs, a prompt appears in the Failover Control Center and waits for you to manually initiate the failover process. Disable this option only if you want failover to occur immediately when a failure occurs. This option is not configurable if the Method to Monitor for Failover is set to No Monitoring.
16. If the Shares selection under Items to Failover is selected, verify that the Use .SHR Share Mapping File check box is selected if you would like to use the Double-Take Availability share mapping file to create shares on the target during failover. If this option is not selected, shares will be created using the information gathered when the machine was selected as a source to be monitored.

Note:

If the Shares selection under Items to Failover is not selected, shares will not be failed over to the target regardless of the Use .SHR Share Mapping File selection.

17. By default, Failover Hostname is disabled. This option automatically removes the host SPN (Service Principle Name) from Active Directory on the source and adds it to Active Directory on the target. If you are using Active Directory, enable this option or you may experience problems with failover.
18. Failback Hostname returns the host SPN on the source and target back to their original settings on failback. If you are using Active Directory, enable this option or you may experience problems with failback.
19. If you are failing over or failing back hostnames, you need to specify an Active Directory user that has update privileges within Active Directory. Click Credentials and identify a user and the associated password that has privileges to create and delete SPNs. The username must be in the format fully_qualified_domain\user. Click OK to return to the Monitor Settings dialog box.

Note:

The Active Directory account password cannot be blank.

20. If you are using any failover or failback scripts, click Scripts and enter the path and filename for each script type. Scripts may contain any valid Windows command, executable, or batch file. Examples of functions specified in scripts include stopping services on the target before failover because they may not be necessary while the target is standing in for the source, stopping services on the target that need to be restarted with the source’s machine name and IP address, starting services or loading applications that are in an idle, standby mode waiting for failover to occur, notifying the administrator before and after failover or failback occurs, stopping services on the target after failback because they are no longer needed, stopping services on the target that need to be restarted with the target machine’s original name and IP address, and so on. Specify each script that you want to run and the following options, if necessary.

• If you want to pass any arguments to your script, specify the arguments.
• If you want to delay the failover or failback processes until the associated script has completed, mark the appropriate check box.
• If you want the same scripts to be used as the default for future monitor sessions, mark the appropriate check box.
• If you want to specify a user account to run the scripts, specify the credentials for the source and target. If no account is specified, the scripts will be processed using the same account that is configured to run the Double-Take service.

21. Click OK to return to the Monitor Settings dialog box.

Note:

Failover scripts will run but will not be displayed on the screen if the Double-Take service is not set to interact with the desktop. Enable this option through the Services applet. With these flexible scripting features, application failover using Double-Take Availability can be seamless to the end user. Double-Take Software tests many of the popular applications on the market today. The results of these testing procedures are written up into formal Application Notes that describe how Double-Take Availability should be configured to work correctly with certain applications, including scripting examples. For a complete list of Double-Take Availability Application Notes, visit the Double-Take Software support web site.

22. Click OK on the Monitor Settings dialog box to save your monitor settings and begin monitoring for a failure.

Updating shares on the target

Share information on the target can be manually updated from the Failover Control Center window. To manually update the share information, highlight a source machine in the Monitored Machines tree and click the Update Shares button.

Editing failover monitoring configuration

If you want to edit the monitor settings for a source that is currently being monitored, highlight that source on the Monitored Machines tree on the main Failover Control Center screen and click Edit. The Monitor Settings dialog box will open. Follow the Configuring failover monitoring instructions.

Removing failover monitoring configuration

If you want to discontinue monitoring a source, highlight that machine on the Monitored Machines tree on the main Failover Control Center screen and click Remove Monitor. No additional dialog boxes will open.

Server settings

Most of the Double-Take Availability server settings are located in the Replication Console Server Properties dialog box. To access this dialog box, right-click a server in the left pane of the Management Console and select Properties. The Server Properties dialog box contains multiple tabs with the Double-Take Availability server settings. For information on the server settings not available through the Replication Console, see the Scripting Guide.

This section contains the following topics, each corresponding to a tab in the Server Properties dialog box.

• Identifying a server
• Licensing a server
• Configuring server startup options
• Configuring network communication properties for a server
• Queuing data
• Configuring source data processing options
• Configuring target data processing options
• Specifying the Double-Take Availability database storage files
• Specifying file names for logging and statistics
• Supplying credentials for script processing
• E-mailing event messages

Identifying a server

From the Replication Console, you can see server identity information, including a server's Double-Take Availability activation code.

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties
3. Select the General tab.

4. Specify the server identity information. Some of the fields are informational only.

• Nickname—A nickname is saved in the Replication Console workspace, therefore, it only appears in the Replication Console on this server. It is not communicated across the network. If you export a workspace and use it on another Double-Take Availability server, the server nickname will appear there also.
• Machine—This is the actual server name. This field is not modifiable.
• Parent Group—This is the group in the Replication Console server
• Addresses—The IP address(es) for this server are listed in this field. This information is not modifiable and is displayed for your information. The machine’s primary address is listed first.
• Client Transmit Port—This field displays the port that the Replication Console uses to send commands to a server. This port cannot be modified.
• Discovery Method—This field indicates the method in which the Replication Console identifies the Double-Take Availability server. Manual indicates a server was manually inserted into the Replication Console server tree. Active Directory indicates a server is registered with Windows Active Directory.
• Operating System—The server’s operating system version is displayed.
• Product Information—The Double-Take service name and the build number are displayed.

5. Click OK to save the settings.

Licensing a server

From the Replication Console, you can manage your server activation codes. The activation code is the Double-Take Availability license which is required on every Double-Take Availability server. The activation code is a 24 character, alpha-numeric code. You can change your activation code without reinstalling, if your license changes. There are different licenses available.

• Evaluation—An evaluation license has an expiration date built into the activation code. When the license expires, the software will no longer function. The same evaluation licenses can be used on multiple machines on a network.
• Single—A single license is available on a per-machine basis. Each server is required to have a unique license whether it is functioning as a source, target, or both. A single license can only be used on one server on a network.
• Site—A site license is available to register every machine with the same license. This license is designed to be used on multiple servers on a network.
• Node-Locking—To prevent Double-Take Availability from being used illegally on multiple servers, you may have received a node-locked activation code, which is a temporary license. The temporary license is not activated until you login to the server. Once the temporary license is activated, you have 14 days to update it to a permanent, node-locked license. The permanent node-locked license will be created by supplying unique server information to Double-Take Software. Since the permanent node-locked license contains unique server information, specific to the hardware where Double-Take Availability is installed, the node-locked license cannot be used on any other server, thus prohibiting illegal applications.

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties.
3. Select the Licensing tab. The fields displayed on this tab will vary depending on your activation code(s).

4. Enter an activation code and click Add. Repeat for each activation code.
5. Highlight an activation code in the list to display any status messages for that code below the list display.
6. If you need to remove a code from the server, highlight it in the list and click Remove.
7. To update a temporary node-locked license to a permanent license, you need to provide server information which will be used to generate a permanent node-locked license.

1. Highlight your activation code in the list to display the Node-Locking section at the bottom of the Licensing tab.
2. Click the hyperlink in the Node-Locking section. If you do not have an Internet connection, copy the Server Information text from the Node-Locking section into the form at https://activate.doubletake.com from another machine.
3. After you submit the form, you will receive an email with a node-locked license key. Enter that key on the Licensing tab and click Add. The permanent activation code is specific to this server. It cannot be used on any other server. If the activation code and server do not match, Double-Take Availability will not run.

8. Click OK to save the settings.

Configuring server startup options

From the Replication Console, you can configure server startup options for each Double-Take Availability server.

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties
3. Select the Setup tab.

4. Specify the server setup and source startup options.

• Log Statistics Automatically—If enabled, Double-Take Availability statistics logging will start automatically when Double-Take Availability is started.
• Enable Task Command Processing—Task command processing is a Double-Take Availability feature that allows you to insert and run tasks at various points during the replication of data. Because the tasks are user-defined, you can achieve a wide variety of goals with this feature. For example, you might insert a task to create a snapshot or run a backup on the target after a certain segment of data from the source has been applied on the target. This allows you to coordinate a point-in-time backup with real-time replication.

Task command processing can be enabled from the Replication Console, but it can only be initiated through the scripting language. See the Scripting Guide for more information.

If you disable this option on a source server, you can still submit tasks to be processed on a target, although task command processing must be enabled on the target.

• Advertise service with Active Directory—If enabled, the Double-Take service registers with Windows Active Directory when the service is started.
• Automatically Reconnect During Source Initialization—If enabled, Double-Take Availability will automatically reconnect any connections that it automatically disconnected.
• Mirror only Changed Files on Source Reboot—If enabled, Double-Take Availability will use the Windows NTFS change journal to track file changes. If the source is rebooted, only the files identified in the change journal will be remirrored to the target. This setting helps improve mirror times.
• Perform Remirror After Auto-reconnect—If enabled, Double-Take Availability will automatically perform a remirror after an auto-reconnect has occurred. You will also need to specify the type of mirror that you wish to perform after an auto-reconnect.
• File Differences with Checksum—Any file that is different on the source and target based on date, time, and/or size is flagged as different. The mirror then performs a checksum comparison on the flagged files and only sends those blocks that are different.
• File Differences with no Checksum—Any file that is different on the source and target based on date, time, and/or size is sent to the target.
• Send data only if Source is newer than Target—Only those files that are newer on the source are sent to the target.
• Full—All files are sent to the target. 

Note:

Database applications may update files without changing the date, time, or file size. Therefore, if you are using database applications, you should use the File Differences with checksum or Full option.

• Server Shutdown Timeout—This setting indicates the amount of time, in seconds, for the service to wait prior to completing a shutdown so that Double-Take Availability can persist data on the target in an attempt to avoid a remirror when the target comes back online. A timeout of zero (0) indicates waiting indefinitely and any other number indicates the number of seconds. The timeout setting only controls the service shutdown from the Double-Take Availability clients. It does not control the service shutdown through a reboot or from the Service Control Manager.

5. Click OK to save the settings.

Configuring network communication properties for a server

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties
3. Select the Network tab.

4. Specify the network communication properties.

• Default Address—On a machine with multiple NICs, you can specify which address Double-Take Availability traffic will use. It can also be used on machines with multiple IP addresses on a single NIC.
• Communications port—Double-Take Availability servers use this port to send and receive commands and operations between two Double-Take Availability servers.

5. Click OK to save the settings.

Queuing data

You should configure queuing on both the source and target.

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties.
3. Select the Queue tab.

4. Specify the queue settings for the server.

   

• Folder—This is the location where the disk queue will be stored. Double-Take Availability displays the amount of free space on the volume selected. Any changes made to the queue location will not take effect until the Double-Take service has been restarted on the server.

  When selecting the queue location, keep in mind the following caveats.

  • Select a location on a non-clustered volume that will have minimal impact on the operating system and applications being protected.
  • Select a location that is on a different volume as the location of the Windows pagefile.
  • Select a dedicated, non-boot volume.
  • Do not select the root of a volume.
  • Do not select the same physical or logical volume as the data being replicated.

  Although the read/write ratio on queue files will be 1:1, optimizing the disk for write activity will benefit performance because the writes will typically be occurring when the server is under a high load, and more reads will be occurring after the load is reduced. Accordingly, use a standalone disk, mirrored (RAID 1) or non-parity striped (RAID 0) RAID set, and allocate more I/O adapter cache memory to writes for best performance. A RAID 5 array will not perform as well as a mirrored or non-parity striped set because writing to a RAID 5 array incurs the overhead of generating and writing parity data. RAID 5 write performance can be up to 50% less than the write performance of a single disk, depending on the adapter and disk.

  Another option is to use a solid state disk, which are hard drives that use RAM instead of disk platters. These devices are typically quite costly, but they will provide superior performance as a queuing device when the best performance is required.

Note:

Scanning the Double-Take Availability queue files for viruses can cause unexpected results. If anti-virus software detects a virus in a queue file and deletes or moves it, data integrity on the target cannot be guaranteed. As long as you have your anti-virus software configured to protect the actual production data, the anti-virus software can clean, delete, or move an infected file and the clean, delete, or move will be replicated to the target. This will keep the target from becoming infected and will not impact the Double-Take Availability queues.

• Maximum system memory for queue—This is the amount of Windows system memory, in MB, that will be used to store data in queues. When exceeded, queuing to disk will be triggered. This value is dependent on the amount of physical memory available but has a minimum of 32 MB. By default, 128 MB or 512 MB of memory is used, depending on your operating system. If you set it lower, Double-Take Availability will use less system memory, but you will queue to disk sooner which may impact system performance. If you set it higher, Double-Take Availability will maximize system performance by not queuing to disk as soon, but the system may have to swap the memory to disk if the system memory is not available.

  Since the source is typically running a production application, it is important that the amount of memory Double-Take Availability and the other applications use does not exceed the amount of RAM in the system. If the applications are configured to use more memory than there is RAM, the system will begin to swap pages of memory to disk and the system performance will degrade. For example, by default an application may be configured to use all of the available system memory when needed, and this may happen during high-load operations. These high-load operations cause Double-Take Availability to need memory to queue the data being changed by the application. In this case, you would need to configure the applications so that they collectively do not exceed the amount of RAM on the server. Perhaps on a server with 1 GB of RAM running the application and Double-Take Availability, you might configure the application to use 512 MB and Double-Take Availability to use 256 MB, leaving 256 MB for the operating system and other applications on the system. Many server applications default to using all available system memory, so it is important to check and configure applications appropriately, particularly on high-capacity servers.

  Any changes to the memory usage will not take effect until the Double-Take service has been restarted on the server.

• Maximum disk space for queue—This is the maximum amount of disk space, in MB, in the specified Folder that can be used for Double-Take Availability disk queuing, or you can select Unlimited which will allow the queue usage to automatically expand whenever the available disk space expands. When the disk space limit is reached, Double-Take Availability will automatically begin the auto-disconnect process. By default, Double-Take Availability will use an unlimited amount of disk space. Setting this value to zero (0) disables disk queuing.
• Minimum Free Space—This is the minimum amount of disk space in the specified Folder that must be available at all times. By default, 50 MB of disk space will always remain free. The Minimum Free Space should be less than the amount of physical disk space minus Maximum disk space for queue.

Note:

The Maximum disk space for queue and Minimum Free Space settings work in conjunction with each other. For example, assume your queues are stored on a 10 GB disk with the Maximum disk space for queue set to 10 GB and the Minimum Free Space set to 500 MB. If another program uses 5 GB, Double-Take Availability will only be able to use 4.5 GB so that 500 MB remains free.

• Alert at following queue usage percentage—This is the percentage of the disk queue that must be in use to trigger an alert message in the Linux system log. By default, the alert will be generated when the queue reaches 50%.
5. Click OK to save the settings.

Configuring source data processing options

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties
3. Select the Source tab.

4. Specify how the source will process data.

• Replication Packets to 1 Mirror Packet—You can specify the ratio of replication packets to mirror packets that are placed in the source queue. Specify a larger number if you have a busy network that has heavy replication. Also, if you anticipate increased network activity during a mirror, increase this number so that the replication queue does not get too large.
• Replicate NT Security by Name—Double-Take Availability allows you to replicate Windows permission attributes by local name as well as security ID (SID). By replicating Windows security by name, you can transmit the owner name with the file. If that user exists on the target, then the SID associated with the user will be applied to the target file ownership. If that user does not exist on the target, then the ownership will be unknown. By default, this option is disabled.
• Domain security model—If you are using a Windows domain security model by assigning users at the domain level, each user is assigned a security ID (SID) at the domain level. When Double-Take Availability replicates a file to the target, the SID is also replicated. Since a user will have the same SID on the source and target, the user will be able to access the file from the target. Therefore, this option is not necessary.
• Local security model—If you are using a Windows local security model by assigning users at the local level (users that appear on multiple machine will each have different SIDs), you will need to enable this feature so that users can access the data on the target. If you do not enable this feature with a local security model, after a Double-Take Availability file and SID is replicated, a local user will not be able to access the file because the user’s SID on the target machine is different from the SID that was replicated from the source machine.

If you enable this option, make sure that the same groups and users exist on the target as they do on the source. Additionally, you must enable this option on your target server before starting a restoration, because the target is acting like a source during a restoration.

Enabling this option may have an impact on the rate at which Double-Take Availability can commit data on the target. File security attributes are sent to the target during mirroring and replication. The target must obtain the security ID (SID) for the users and groups that are assigned permissions, which takes some time. If the users and groups are not on the target server, the delay can be substantial. The performance impact enabling this option will have will vary depending on the type of file activity and other variables. For instance, it will not affect the overall performance of large database files much (since there is a lot of data, but only a few file permissions), but may affect the performance of user files significantly (since there are often thousands of files, each with permissions). In general, the performance impact will only be noticed during mirrors since that is when the target workload is greatest.

Regardless of the security model you are using, if you create new user accounts on the source, you should start a remirror so the new user account information associated with any files in your replication set can be transmitted to the target.

• Maximum Pending Mirror Operations—This option is the maximum number of mirror operations that are queued on the source. The default setting is 1000. If, during mirroring, the mirror queued statistic regularly shows low numbers, for example, less than 50, this value can be increased to allow Double-Take Availability to queue more data for transfer.
• Size of Mirror Packets—This option determines the size of the mirror packets that Double-Take Availability transmits. The default setting is 65536 bytes. You may want to consider increasing this value in a high latency environment (greater than 100 ms response times).
• Block Checksum All Files on a Difference Mirror—This option allows a file difference mirror to check each block of data, regardless of the file attributes. If this option is not marked, Double-Take Availability will assume files are synchronized if their attributes match.

Note:

Database applications may update files without changing the date, time, or file size. Therefore, if you are using database applications, you should use the Block Checksum All Files on a Difference Mirror option to ensure proper file comparisons. If you are not using database applications, disabling this option will shorten mirror times.

5. Click OK to save the settings.

Configuring target data processing options

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties
3. Select the Target tab.

4. Specify how the target will process data.

• Target Mirror Capacity High Percentage—You can specify the maximum percentage of Windows system memory that can contain mirror data before the target signals the source to pause the sending of mirror operations. The default setting is 20.
• Target Mirror Capacity Low Percentage—You can specify the minimum percentage of Windows system memory that can contain mirror data before the target signals the source to resume the sending of mirror operations. The default setting is 15.
• Retry Delay for Incomplete Operations (seconds)—This option specifies the amount of time, in seconds, before retrying a failed operation on the target. The default setting is 3.
• Block Target Path(s) on Connection—You can block writing to the data located in the target paths. This keeps the data from being changed outside of Double-Take Availability processing.

Note:

If you are going to use failover, any target paths that are blocked will automatically be unblocked during the failover process so that users can modify data on the target after failover. During a restoration, the paths are automatically blocked again. If you failover and failback without performing a restoration, the target paths will remain unblocked. You can manually block or unblock the target paths by right-clicking on a connection. Do not block your target paths if you are protecting a full-server workload because system state data will not be able to be written to the target.

• Move deleted files to the following location—This option allows you to save files that have been deleted, by moving them to a different location on the target. When a file deletion is replicated to the target, instead of the file being deleted from the target, the file is moved to the specified location. This allows for easy recovery of those files, if needed. If you enable this option, specify where you want to store the deleted files.
• Remove after the following number of days—If you are moving deleted files, you can specify a length of time, in days, to maintain the moved files. A moved file that is older than the specified number of days will be deleted. Double-Take Availability checks for moved files that should be deleted once daily at 8 PM. Only the date, not the time, of the file is considered when moved files are deleted. For example, if you specify to delete moved files after 30 days, any file that is 31 days old will be deleted. Because the criteria is based on days and not time, a file that will be deleted could have been moved anytime between 12:01 AM and 11:59 PM 31 days ago.

Note:

If deleted files are moved for long enough, the potential exists for the target to run out of space. In that case, you can manually delete files from the target move location to free space. If you have Ignore Delete Operations enabled on the source, the Move deleted files setting will never be invoked because there will be no delete operations performed on the target. Do not include the Recycler directory in your replication set if you are moving deleted files. If the Recycler directory is included, Double-Take Availability will see an incoming file deletion as a move operation to the Recycle Bin and the file will not be moved as indicated in the Move deleted files setting. Alternate data streams that are deleted on the source will not be moved on the target. Encrypted files that are deleted on the source will only be moved on the target if the move location is on the same volume as the replication set target path. Compressed and sparse files that are deleted on the source will be moved on the target, although the compression and sparse flags will only be retained on the target if the move location is on the same volume as the replication set target path.

5. Click OK to save the settings.

Specifying the Double-Take Availability database storage files

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties
3. Select the Database tab.

4. Specify the database files that store the Double-Take Availability replication set, connection, and scheduling information.

• Folder—Specify the directory where each of the database files on this tab are stored. The default location is the directory where the Double-Take Availability program files are installed.
• Replication Set—This database file maintains which replication sets have been created on the server along with their names, rules, and so on. The default file name is DblTake.db.
• Connection—This database file maintains the active source/target connection information. The default file name is connect.sts.
• Schedule—This database file maintains any scheduling and transmission limiting options. The default file name is schedule.sts.

5. Click OK to save the settings.

Specifying file names for logging and statistics

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties
3. Select the Logging tab.

4. Specify the location and file names for the log and statistics files.

• Folder—Specify the directory where each of the log files on this tab are stored. The default location is the directory where the Double-Take Availability program files are installed.
• Messages & Alerts
• Maximum Length—Specify the maximum length of the client and service log files. The default size is 1048576 bytes and is limited by the available hard drive space.
• Maximum Files—Specify the maximum number of Double-Take Availability alert log files that are maintained. The default is 5, and the maximum is 999.
• Verification
• Filename—The verification log is created during the verification process and details which files were verified as well as the files that are synchronized. This field contains the base log file name for the verification process. The replication set name will be prefixed to the base log file name. For example, since the default is DTVerify.log, the verification log for the replication set called UserData would be UserData DTVerify.log.
• Maximum Length—Specify the maximum length of the verification log file. The default maximum length is 1048576 bytes (1 MB).
• Append—Mark the Append check box if you want to append each verification process to the same log file. If this check box is not marked, each verification process that is logged will overwrite the previous log file. By default, this check box is selected.
• Language—At this time, English is the only language available.
• Statistics
• Filename—The statistics log maintains connection statistics such as mirror bytes in queue or replication bytes sent. The default file name is statistic.sts. This file is a binary file that is read by the DTStat utility.
• Maximum Length—Specify the maximum length of the statistics log file. The default maximum length is 10485760 bytes (10 MB). Once this maximum has been reached, Double-Take Availability begins overwriting the oldest data in the file.
• Write Interval—Specify how often Double-Take Availability writes to the statistics log file. The default is every 5 minutes.
• Archive Preview
• Filename—If you are using Double-Take Backup product, the archive preview identifies what files would be archived based on the specified criteria. The default file name is ArchivePreview.txt. The replication set name is appended to this filename when the report is generated.
• Maximum Length—Specify the maximum length of the archive preview report. The default maximum length is 10485760 bytes (10 MB). Once this maximum has been reached, Double-Take Availability begins overwriting the oldest data in the file.

5. Click OK to save the settings.

Supplying credentials for script processing

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties
3. Select the Script Credentials tab.

4. If you will be using any customized scripts (mirroring, failover, task command processing, and so on) specify a Username, Password, and Domain to use when running the scripts. If you do not specify any security credentials, the account running the Double-Take service will be used.
5. Click OK to save the settings.

E-mailing event messages

You can e-mail Double-Take Availability event messages to specific addresses. The subject of the e-mail will contain an optional prefix, the server name where the message was logged, the message ID, and the severity level (information, warning, or error). The text of the message will be displayed in the body of the e-mail message.

1. Open the Replication Console and right-click the server on the left pane of the Replication Console.
2. Select Properties.
3. Select the E-mail Notification tab.

4. Select Enable notification.

Note:

Any specified notification settings are retained when Enable notification is disabled.

5. Specify your e-mail settings.

• Mail Server (SMTP)—Specify the name of your SMTP mail server.
• Log on to SMTP Server—If your SMTP server requires authentication, enable Log on to SMTP Server and specify the Username and Password to be used for authentication. Your SMTP server must support the LOGIN authentication method to use this feature. If your server supports a different authentication method or does not support authentication, you may need to add the Double-Take Availability server as an authorized host for relaying e-mail messages. This option is not necessary if you are sending exclusively to e-mail addresses that the SMTP server is responsible for.
• From Address—Specify the e-mail address that you want to appear in the From field of each Double-Take Availability e-mail message. The address is limited to 256 characters.
• Send To—Specify the e-mail address that each Double-Take Availability e-mail message should be sent to and click Add. The e-mail address will be inserted into the list of addresses. Each address is limited to 256 characters. You can add up to 256 e-mail addresses. If you want to remove an address from the list, highlight the address and click Remove. You can also select multiple addresses to remove by Ctrl-clicking.
• Subject Prefix and Add event description to subject—The subject of each e-mail notification will be in the format Subject Prefix : Server Name : Message Severity : Message ID : Message Description. The first and last components (Subject Prefix and Message Description) are optional. The subject line is limited to 150 characters.

If desired, enter unique text for the Subject Prefix which will be inserted at the front of the subject line for each Double-Take Availability e-mail message. This will help distinguish Double-Take Availability messages from other messages. This field is optional.

If desired, enable Add event description to subject to have the description of the message appended to the end of the subject line. This field is optional.

• Filter Contents—Specify which messages that you want to be sent via e-mail. Specify Information, Warning, and/or Error. You can also specify which messages to exclude based on the message ID. Enter the message IDs as a comma or semicolon separated list. You can indicate ranges within the list.

Note:

You can test e-mail notification by specifying the options on the E-mail Notification tab and clicking Test. (By default, the test will be run from the machine where the Replication Console is running.) If desired, you can send the test message to a different e-mail address by selecting Send To and entering a comma or semicolon separated list of addresses. Modify the message text up to 1024 characters, if necessary. Click Send to test the e-mail notification. The results will be displayed in a message box. Click OK to close the message and click Close to return to the E-mail Notification tab. E-mail notification will not function properly if the Event logs are full. If an error occurs while sending an e-mail, a message will be generated. This message will not trigger an e-mail. Subsequent e-mail errors will not generate additional messages. When an e-mail is sent successfully, a message will then be generated. If another e-mail fails, one message will again be generated. This is a cyclical process where one message will be generated for each group of failed e-mail messages, one for each group of successful e-mail messages, one for the next group of failed messages, and so on. If you start and then immediately stop the Double-Take service, you may not get e-mail notifications for the log entries that occur during startup. By default, most virus scan software blocks unknown processes from sending traffic on port 25. You need to modify the blocking rule so that Double-Take Availability e-mail messages are not blocked.

6. Click OK to save the settings.

Full-server protection

Before you can protect your entire source, you need to select a target that is suitable to become the source, in the event of a source failure. Double-Take Availability will validate the target you select and identify any incompatibilities. Errors will disqualify the target as a suitable server. First you will need to find a compatible target, then you can establish full-server protection.

Finding a compatible target

Review the table below to determine if your server is a compatible target.

Establishing full-server protection

Use the following instructions to establish protection for your entire source.

1. Login as a user that is a member of both the Double-Take Admin and local Administrators security groups.
2. Open the Full-Server Failover Manager.
3. Enter your source and target servers. You can click Browse when selecting either server to locate it by drilling down through your network. After you have specified a server name, enter login credentials when prompted. Once the server is selected and logged in, the Properties tab at the bottom of the Full-Server Failover Manager updates to display the server’s properties.

4. Optional protection settings are available but not required. If desired, configure the optional protection settings by clicking Configure protection.
5. You must validate that your target is compatible with your source and can stand-in if the source fails. Click Validate configuration. The Validation tab at the bottom of the Full-Server Failover Manager updates to display the validation check. Errors are designated by a white X inside a red circle. Warnings are designated by a black exclamation point (!) inside a yellow triangle. A successful validation is designated by a white checkmark inside a green circle.

6. Double-click on any of the validation items to see details. You must correct any errors before you can enable protection. Depending on the error, you may be able to click Fix or Fix All and let Double-Take Availability correct the problem for you. For those errors that Double-Take Availability cannot correct automatically, you will need to modify the target to correct the error, or you can select a different target. You must revalidate the selected servers until the validation check passes without errors.
7. Once the validation check passes without errors, click Enable Protection to begin monitoring.

Optional full-server protection settings

Optional protection settings are available when configuring a full-server protection connection, but they are not required. If you want to configure the optional settings, make sure you have a valid source and target specified, then click Configure protection from the main Full-Server Failover Manager page.

You have the following optional configuration settings available.

• Including and excluding data to be protected
• Stopping services on the target when protection is enabled
• Taking snapshots of the target
• Configuring failover monitoring and processing
• Mapping network configuration on the target for post-failover
• Routing data transmissions
• Mirroring data
• Compressing data

Including and excluding data to be protected

1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Protection tab.
2. Specify that data you want to include and/or exclude.

• Volumes to include—Select the volumes that you want to protect. You must have the same volumes on the source and target. You cannot deselect the boot volume. If you deselect other volumes, you will not be protecting the entire source server.
• Directories to exclude—Select the directories that you want to exclude. If you exclude any directories, you will not be protecting the entire source server.
• Add—Click Add to specify a directory to exclude. Enter the name of the directory or click Browse to search for the directory path. Specify Recursive if sub-directories of the listed directory should be excluded also. Specify Non-recursive if sub-directories of the listed directory should be included. Click OK to add the directory to the list of Directories to exclude. Repeat this process to add multiple directories.
• Edit—Highlight a directory in the list and click Edit to modify the directory definition. After modifying the directory, click OK to save the changes.
• Remove—Highlight a directory in the list and click Remove to delete the directory definition. The directory will no longer be excluded.

3. Click OK to save the settings.

Stopping services on the target when protection is enabled

1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Protection tab.
2. Double-Take Availability determines what services are currently running on the target. You can specify which services you want to keep running and those services you want to stop when you enable your protection. Move the services between the Services to stop and Services to leave running lists by using the double arrows. Select Show critical services to see the list of critical services that will remain running on the target. The critical services are displayed in a lighter colored, italics font. The critical services cannot be moved from the running list.
3. Click OK to save the settings.

Taking snapshots of the target

1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Protection tab.
2. A snapshot is an image of data taken at a single point in time. Snapshots allow you to view files and folders as they existed at points of time in the past, so you can, for example, recover from cases where corrupted source data was replicated to the target. By default, Double-Take Availability takes periodic snapshots of the data on the target. When failover is triggered, you can use the live target data at the time of failover or you can failover to a snapshot of the target data. Specify how you want to handle snapshots.

• Enable periodic snapshots—Enable snapshots if you want to be able to use them at failover time. If snapshots are disabled, the live data on the target at failover time will be used.
• Snapshot Interval—By default, snapshots of the target data are taken every 60 minutes. If desired, increase or decrease the interval between snapshots.
• Start now—If you want to start taking snapshots immediately after the full-server connection is established, select Start now.
• Start at—If you want to start taking snapshots at a specific data and time, select Start at and specify the date and time parameters.

3. Click OK to save the settings.

Configuring failover monitoring and processing

1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Failover tab.
2. Specify how you want to handle failover monitoring and processing.

• Manual intervention required—By default, you will be notified when a failover is necessary, but the failover process will not start until you manually initiate it. If you disable intervention, failover will automatically start when a failure is detected.
• Monitor Interval—By default, the target checks to see if the source is online every five (5) seconds. The source responds back to the target when it receives one of these checks. If desired, increase or decrease the interval between checks.
• Missed intervals—By default, the target can miss five (5) responses from the source before assuming the source has failed. If desired, increase or decrease the number of responses that can be missed before the source is identified as failed.

Note:

Together, the Monitor interval and Missed intervals settings determine the total time before failover would be triggered. For example, five missed checks every five seconds would be 25 seconds to trigger failover. To achieve shorter delays before failover, use lower values. To achieve longer delays before failover, choose higher values.

• Monitor type—Double-Take Availability monitors the source by testing for a Double-Take Availability network response via ICMP pings or a Double-Take service response. Select the type of monitoring you want to perform.
• Pre-Failover Script and Post-Failover Script—If you want to execute a script on the target before failover (pre-failover) begins or after failover has occurred (post-failover), specify the path to the script on the target. You can also search for the script by clicking Browse. The script will be processed using the same user account that is configured to run the Double-Take service. Scripts may contain any valid Windows command, executable, batch, or script file. The Pre-Failover Script will be executed as soon as the failover process is initiated. The Post-Failover Script will be executed after the failover process ends and the target has been rebooted.

3. Click OK to save the settings.

Mapping network configuration on the target for post-failover 

1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Failover tab.
2. Specify how you want to handle network configurations on the target after failover.

• Apply source network configuration to the target—If you select this option, the source IP addresses will be failed over to the target. The IP addresses associated with each NIC on the source will be mapped to the NIC you specify on the target. If the source has more NICs than the target, some of the source NICs will not be mapped to the target, or the target NICs may need to be used for more than one source NIC. If there are more NICs on the target than the source, the additional NICs will still be available after failover. If you are using a LAN environment, you should select this option.
• Retain target network configuration—If you select this option, the source IP addresses will not be failed over to the target. The target will retain all of its original IP addresses. If your target is on a different subnet (typical of a WAN environment), you should select this option. The following options are available if you want to update DNS.
• DNS Server—The source’s primary DNS server is selected by default. If desired, you can select a different DNS server.
• Source Server IP—Select the IP address from the source that you want to remap to an IP address on the target.
• Target Server IP—Select an IP address on the target that will be replace the source IP address in DNS.
• Username—Specify a user that has privileges to access and modify DNS records. The account must be a DNS Admin for the domain in which the DNS server resides. You can enter a user name for a different domain by entering a fully qualified user name. The fully qualified user name must be in the format domain\username or username@domain. If you enter a non-qualified name, the DNS domain will be used by default. The domain name is obtained from the DNS server name, provided that reverse lookup in DNS is enabled.
• Password—Enter the password that is associated with the specified user name.

3. After you have entered the DNS information, click Test to validate that DNS is configured correctly and that the specified credentials are sufficient to update DNS. When the DNS configuration is complete, click OK to save your entries and return to the Configure Protection window.

4. Click OK to save the settings.

Routing data transmissions

1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Advanced tab.
2. By default, Double-Take Availability will select the default route for transmissions. If desired, select a different IP address on the target that will be used for full-server connection transmissions.
3. Click OK to save the settings.

Mirroring data

1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Advanced tab.
2. Specify how you want to mirror data.

• Mirroring—Select the type of Double-Take Availability mirroring process you want to perform. A Full mirror will transmit all files from the source to the target. A Checksum mirror will transmit only the blocks of data that are different between the source and target.
• Estimate Replication Set size based on volume—The size of the replication set is used to determine mirroring remaining calculations. If this option is enabled, the replication set size is based on the volume size, which is a faster calculation. If disabled, the replication set size is based on the selected data, which can be a slower calculation. The mirror will remain in an initializing state until the calculation is complete.

3. Click OK to save the settings.

Compressing data

1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Advanced tab.
2. Compression allows you to reduce the amount of bandwidth needed to transmit data from the source to the target. The data is compressed before being transmitted and then is uncompressed before it is written on the target. Typically, compression is used in WAN environments, but not in LAN environments. If desired, enable compression and select the level of compression that you want to use. All connections to the same target will have the same compression settings.
3. Click OK to save the settings.

Using NAT or firewalls with full-server workloads

If your source and target are on opposite sides of a NAT or firewall, you will need to configure your hardware to accommodate full-server workload communications. You must have the hardware already in place and know how to configure the hardware ports. If you do not, see the reference manual for your hardware.

Full-server ports

By default, Double-Take Availability uses port 6320 for all communications. To verify or modify the ports, you must use the Replication Console.

1. Open the Replication Console.
2. Locate your servers in the server tree in the left pane of the Replication Console.
3. Right-click the server in the left pane of the Replication Console and select Properties.
4. On the Network tab, verify or modify the Communications Port as needed. All servers and clients in your full-server workload protection must be using the same port.

Double-Take Availability uses ICMP pings to monitor the source for failover. A failover monitor will not be created if ICMP is blocked (although the data and system state will still be protected). You should configure your hardware to allow ICMP pings between the source and target. If you cannot, you will have to monitor for a failure using the Double-Take Availability replication service. Use the Monitor Type option on the configuration Failover tab to set your failover monitoring method.

Microsoft Windows ports

Full-server workload protection uses WMI (Windows Management Instrumentation) which uses RPC (Remote Procedure Call). By default, RPC will use ports at random above 1024, and these ports must be open on your firewall. RPC ports can be configured to a specific range by specific registry changes and a reboot. See the Microsoft Knowledge Base article 154596 for instructions.

Full-server workload protections also rely on other Microsoft Windows ports.

• Microsoft File Share uses ports 135 through 139 for TCP and UDP communications.
• Microsoft Directory uses port 445 for TCP and UDP communications.

These ports must be open on your firewall. Check your Microsoft documentation if you need to modify these ports.

Hardware ports

You need to configure your hardware so that the full-server ports and Microsoft Windows ports are open. Since communication occurs bidirectionally, make sure you configure both incoming and outgoing traffic.

There are many types of hardware on the market, and each can be configured differently. See your hardware reference manual for instructions on setting up your particular router.

Application protection

Protecting an application consists of three main tasks - configuring the protection, validating the protection, and enabling the protection. The processes are similar for the different application types, however, there are some variances. Optional protection settings are available when configuring application protection, but they are not required.

Protecting an application

1. Open the Application Manager.
2. Verify the Setup tab is selected and then from the Tasks list on the left pane, select the type of application you want to protect.

Note:

The fields in the Application Manager console will vary depending on the type of application you are protecting.

3. Application Manager will automatically identify the root domain where the Application Manager is running and populate the Domain Name field. If necessary, change the domain name to a trusted root domain that the Application Manager console can connect to. If prompted, enter security credentials with administrator privileges for the domain.

   

Note:

Domain names must include a suffix, such as .com, .corp, .net, and so on. If you are protecting Exchange, the domain must be the root of the forest domain because that is where all Exchange server objects reside, even if the Exchange server is a member of a child domain.

4. Application Manager will automatically attempt to populate the Source Server and Target Server lists with any servers in the specified domain that are running the application you are protecting. Select your source and target servers.

   

Note:

If you have previously used this source and target pair, you will be prompted to reuse the previous configuration. If you select Yes, your previous configuration settings will be used. If you do not want to use the previous configuration settings (perhaps the source or target configuration has changed since you configured the connection), select No to use the default configuration settings. If you select a source that is currently unavailable, you will be prompted to select the target first. When you select the target then the source, you may get a failover prompt or the same source is unavailable prompt. This will depend on if a failover condition has been met according to the original failover configuration. You cannot protect a server if it is already functioning as a target. If you are using a cluster environment, select your virtual server as you would a physical server. If you are protecting Exchange, the target you select must be in the same Exchange administrative group as the source. If you are protecting Exchange in a like-named cluster scenario, select the same server for the source and target. The target server name will automatically be appended with the suffix like-named. Enter the requested information in the Like-named Cluster Setup dialog box. Target Cluster—Enter the name of one of the target nodes, then click Connect. Network—Select the target NIC that can accommodate a new IP address. IP Address—Enter a new IP address for the target to use when it stands in for the source. Subnet Mask—Enter the subnet mask to use for the new IP address. Storage Resources—The Application Manager will automatically select the required storage resources on the target, provided that they exist. Verify that the drive letters where Exchange data is located are selected. You cannot deselect a storage resource that exists on both the source and target. If the drive letters on the source and target do not match, then not all required data will be selected automatically. You will need to select it manually. The selected storage resources must be in the same group. If you have protecting 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. In this case, select the target Exchange virtual server. If you are protecting Exchange 2003 and it is running in mixed mode, the first installed Exchange virtual server contains the MTA (Message Transfer Agent) resource that is needed to communicate with versions prior to Exchange 2003. If you do not failover all Exchange virtual servers, then any user who is in a different mail store than the first one may not be able to route mail. If you are protecting SharePoint, enter the SharePoint Front-End Web Server and click Get Config to populate the Source Server list. If no servers are populated in the lists (perhaps the server you need is in a child domain), click Advanced Find to add servers to the lists. Advanced Find is not available for all application protections. See Managing servers for more details on Advanced Find. Server names must be 15 characters or less. You will be unable to configure protection when your environment between the Application Manager and the source or target contains a NAT or certain VPN configurations. This is due to WMI limitations. Contact technical support for instructions to configure protection manually.

5. If prompted when selecting a server, provide login credentials.
• You can enter a user for a different domain by entering a fully qualified name in the format domain\username or username@domain. If you enter a non-qualified name, the DNS domain from the DNS server will be used.
• The login account must be a member of the local administrators security group.
• The login account must be a member of the Double-Take Admin security group.
• If you will be configuring DNS failover, the login account must be a member of the domain DnsAdmins security group.
• If you are protecting Exchange, the following requirements apply to the login credentials.
• The login account must be an Exchange Full Administrator at the organizational level, as delegated via the Exchange System Manager at the user level or have delegated rights via the Application Manager Delegate Rights feature (select Tools, Delegate Rights). Rights must be delegated to a specific user and not the group the user belongs to in order for the Application Manager to recognize them.
• The login account must have rights to manage Exchange in order to query and modify the Exchange Active Directory objects.
• If Exchange is on a cluster, the login account must be a member of the Cluster Administrators security group on each node. Additionally, the same cluster service account should be used for both the source and target.
• If you are protecting SQL, the login account must be assigned the System Administrator role on the SQL server in order to query and administer SQL.
• If you are protecting SharePoint, the following requirements apply to the login credentials.
• The login account must be assigned the System Administrator role on the SQL server in order to query and administer SQL.
• The login account must be the same farm administrator account used when installing and configuring SharePoint.
• The login account must have local administrator rights on the source and target front-end web servers and the source and target back-end SQL servers.
• If you are protecting BlackBerry and the login account is the BesAdmin account, you will need to add that account to the Double-Take Admin group on the source and target servers.
6. Optional protection settings are available but not required. If desired, configure the optional protection settings by clicking Configure.
7. Once you have finalized your protection settings, you need to validate your configuration by clicking Validate. Monitor the status of the validation process in the status bar at bottom of the Application Manager.
8. When the validation is complete, the status progress indicator is removed. Errors are designated by a white X inside a red circle. Warnings are designated by a black exclamation point (!) inside a yellow triangle. A successful validation is designated by a white checkmark inside a green circle. Unknown items are a white question mark inside a blue circle. Double-click on any of the validation items to see details. Application Manager can automatically fix errors and warnings marked with a yellow gear. Highlight a single item and click Fix to have Application Manager fix that one issue. Click Fix All to have Application Manager correct all of the issues. You must correct any errors, and ideally any warnings, before you can enable protection.

Note:

If you are using DNS failover and did not enter DNS credentials under the optional protection settings, you will be prompted for credentials that can access and modify DNS records. If you validate a source and target pair that is already in a Protected state and the validation detects issues with the target, Fix and Fix All will be disabled. You must disable the protection, fix the issue, then re-enable protection. If you are protecting SQL, are using Database Only mode, and the database is online on the target, the database cannot be taken offline on the target by using Fix if it has a SQL Server replication publication. The publication will have to be deleted using the SQL Server management tools before the database can be taken offline. For SQL 2000 servers, Application Manager may hang when rerunning validation after disabling protection in the same session. To work around this issue, disable the protection, stop and restart the Application Manager, then validate or enable protection.

9. If you are protecting BlackBerry, a Complete BlackBerry Protection dialog will appear after the validation is complete. Select the name of the Exchange server under step 2 of the dialog box and you will be able to complete the application protection process again in order to protect your Exchange server.
10. Once the validation passes without errors, click Enable Protection. View the status of the protection on the Monitor tab.

Note:

If you are protecting Exchange keep in the mind the following caveats. If you need to protect data that is stored on a non-mailbox server role, for example SMTP queue data, you will need to configure protection for that data separately. In addition, you may need to manually update the DNS setting for the client access server to point to the target site. If your source has a public store that has a non-MAPI Owning Tree, the folders within this tree may not be updated with current information and therefore unavailable to the users. If you are protecting Exchange 2007 and your environment has more than one domain controller and the domain controller that Exchange is using will change during the failover process, stores may not mount during failover. To work around this issue, either modify the failover script to use the domain controller that Exchange uses when the Information Store service is started or mount the stores manually and run the Replace replicas PowerShell call from the failover script to update the PF replicas (if applicable). If you are protecting Exchange in a like-named cluster scenario, Application Manager will create four resources on the target cluster: two generic script resources, an IP address resource, and a temporary name resource. The temporary name resource will be the Exchange virtual server with the suffix _LN. Application Manager uses the temporary name resource for the connection between the source and target clusters. If you are protecting Exchange or SQL on a cluster, if the target cluster has more than one IP address resource for the virtual Exchange or SQL Server you may experience the following issue. If the one of the IP addresses is not routable from the source server and that IP address was created before any of the routable IP address resources, the Application Manager will fail to enable protection. To enable protection, you will need to delete the non-routable IP address resource(s), re-create them, and then re-add them as dependencies on the network name resource for the virtual server. If you modify your source server configuration on the source server, for example, adding a new storage group or database, you must disable protection, run validation and fix any issues, then re-enable protection to apply the changes. If your application protection is in a cluster environment, you should not move any resources from one cluster group to another once protection is established. If you close Application Manager prior to enabling protection, your configuration changes will not be saved. You must enable protection in order to save your configuration settings. After you have enabled protection, do not use the Failover Control Center client to edit your failover configuration. Doing so will force a failover. If this occurs, cancel the failover prompt and then disable and re-enable monitoring using Application Manager.

Optional application protection settings

Optional protection settings are available when configuring application protection, but they are not required. If you want to configure the optional settings, make sure you have a valid domain and servers specified, then click Configure from the main Application Manager page.

You have the following optional configuration settings available.

• Configuring failover processing
• Configuring DNS failover
• Configuring identity failover
• Configuring failover monitoring
• Taking snapshots of the target
• Application connection settings
• Routing data transmissions
• Protection configuration
• Configuring Exchange storage group protection
• Configuring SQL database protection
• Configuring file share protection
• Configuring BlackBerry database protection
• Configuring SharePoint database protection
• Mirroring data
• Application advanced settings
• Configuring the replication set
• Configuring scripts
• Configuring Active Directory
• Configuring items to failover
• Configuring default connection parameters

Configuring failover processing

1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Failover tab.

Note:

The fields on the Failover tab will vary depending on the type of application you are protecting.

2. Specify the Failover Type which is the name resolution method that will be used to redirect users to the target in the event the source fails. Ideally, you should use DNS failover to reduce downtime and avoid server name or IP address conflicts. However, you may want to select identity failover if access to the domain controller or DNS server is not available, the time required to propogate DNS updates is unacceptable, or your end-users are configured to connect to an IP address and not a server name. For cluster environments, DNS failover is the only option available.

• DNS Failover—With DNS failover, DNS records associated with the source will be updated to point to the target's IP address. This includes A, MX, and PTR-type DNS records. Clients will resolve the source server name to the target server's name and IP address at failover. Click Configure to specify the DNS failover settings.
• Identity Failover—With identity failover, the target will assume the source server's name and IP address. This option can potentially cause name and/or IP address conflicts if the source is brought back online while the target is standing in. Click Configure to specify the identity failover settings.

3. Application Manager automatically determines the appropriate application services or resources to start and stop based on the application you are protecting, your operating system, and your application configuration. If necessary, modify the list of services or resources.

1. Click Add to insert a service or resource into the list. Specify the service or resource name and make sure that Service must be stopped on target is enabled so that replication can update files on the target.
2. Click Remove to remove a service or resource from the list. The services you can remove depend on the application you are protecting. For example, if you are protecting Exchange, you can only remove services or resources that you have manually added.
3. If you are configuring your services, highlight a service and click the up or down arrow to reorder the list. The services will be stopped and started in the order displayed.
4. If you are using a cluster source and standalone target configuration, you can toggle between the services and resource configuration by clicking the Services button.
5. If you are protecting SharePoint, you can add or remove the SharePoint services to the list of SQL services by using the appropriate Add SharePoint Services and Remove SharePoint Services buttons.

4. Click OK to save the settings.

Configuring DNS failover

Application Manager will automatically determine default DNS failover settings. Use the following instructions to modify the DNS failover settings.

1. The DNS Server list contains all DNS IP addresses for the source and target servers. The label after the IP address indicates if the DNS IP address belongs to the source, target, or both. To additional DNS servers to the list, enter an IP address into the DNS Server field and click Add. To remove an IP address from the list, highlight the address and click Delete.

Note:

If you want to set the primary DNS server that Double-Take Availability will use during failover, you can specify Client DNS Server. This option is only available if you have launch the Application Manager using the command line advanced option.

2. Under Source IP addresses to update, map a source IP address to a target IP address for DNS updates.

Note:

If you are protecting Exchange and one or more IP addresses are configured for the SMTP virtual server on the target, the first IP address will be the default target IP address for all source IP addresses.

3. You can specify the length of time, in seconds, that the source's DNS A records are cached in the Time to Live. Enable Update TTL and specify a number of seconds. Ideally, you should specify 300 seconds (5 minutes) or less.

Note:

In order to update the Time to Live, the machine where the Application Manager is running must be able to connect to the DNS server through WMI. If it cannot, the Time to Live record will not be updated and the Application Manager will return an error that the RPC server is unavailable.

4. Specify DNS Credentials and specify a user that has privileges to access and modify DNS records. The user must be a member of the DNSAdmins gruop for the domain where the DNS server resides. You can enter a user for a different domain by entering a fully qualified name in the format domain\username or username@domain. If you enter a non-qualified name, the DNS domain from the DNS server will be used.
5. Once your DNS failover settings are configured, click Test to validate your configuration. If you have any issues with your configuration, review the following DNS information.

• The DNS zone Dynamic updates should be set to Secure only. Otherwise, you must disable dynamic registration on the source server in order to prevent the source from reclaiming its DNS record.
• DNS reverse lookup should be enabled For more information on enabling reverse lookup, see your Microsoft documentation.
• If you are running Windows Server 2000 on the primary DNS server and are hosting zones or domains that contain source and/or target records, you must have the DNS WMI Provider installed on that DNS server.
• If a hosts file entry for the source server exists on end-user machines, errors may occur during a failover and failback.
• If you have a NIC designated only for Double-Take Availability traffic, DNS registration for that NIC should be disabled.
• If you are protecting Exchange and your server is using a public IP address to receive e-mail, you will have to change the public advertised DNS MX record to reflect the target IP address. Consult your service provider for instructions.
• If you are protecting Exchange and you want to allow external e-mail to be delivered to the target server when the source is unavailable, you should create an additional external MX record for the target server. The target MX record should have a lower priority than the source. Refer to your router or firewall documentation for more information.
• In a cluster environment with more than one NIC on a server/node, if the heartbeat network IP address is at the top of the binding order, a socket error will occur when you attempt to select or configure the server. To avoid this issue, change the binding order on all source and target servers/nodes so the domain IP address is at the top of the order. Each server must be rebooted for the change to take effect.

6. Click OK to save your settings.

Configuring identity failover

Application Manager will automatically determine default identity failover settings. Use the following instructions to modify the identity failover settings.

1. Under Source IP address to failover, map a Source IP address to a Target NIC. The target NIC will assume the source IP address during failover. The Target IP addresses list displays the IP address(es) of the selected Target NIC.

2. The default selected items under Items to Failover will depend on the application you are protecting. Enable or disable if you want to failover the source's IP addresses, server name, file shares, and/or Active Directory host name.

Note:

If your source and target are on different subnets, you should not failover the IP address. If you are protecting Exchange, do not failover the Active Directory host name. If you are protecting SQL, do not failover the server name. You cannot failover file shares from a parent to child domain.

3. Click OK to save your settings.

Configuring failover monitoring

1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Monitoring tab.
2. To enable the target to monitor the source for a failure, enable Active Monitoring Enabled. If this option is disabled, you will need to manually monitor the source and initiate failover if the source fails.
3. To help you better control when failover occurs, enable Manual Intervention Required. If this option is disabled, failover will occur immediately when a failover condition is met.
4. Specify the following Monitor Settings.

• Method to Monitor for Failover—You have three choices for having the target monitor the source for a failure.
• Network Access—ICMP pings are used to determine if the source is online. Network devices, such as firewalls or routers, must have ICMP pings unblocked in order to use this option.
• Replication Service—The Double-Take service on the target sends a UDP request to the source, which replies immediately to confirm it is online. Use this method if ICMP pings are blocked.
• Application Monitoring—In non-cluster environments, you can monitor an application via a monitoring script. The script can be WMI, PowerShell, Visual Basic, or JScript.
• Monitor Interval—This setting identifies the number of seconds between the monitor requests sent from the target to the source to determine if the source is online. The default setting depends on the Method to Monitor for Failover.
• Failure Count—This setting is the number of monitor replies sent from the source to the target that can be missed before assuming the source machine has failed. The default setting depends on the Method to Monitor for Failover.

Note:

To achieve shorter delays before failover, use lower Monitor Interval and Failure Count values. This may be necessary for IP addresses on servers that must remain available and responsive at all times. Lower values should be used where redundant interfaces and high-speed, reliable network links are available to prevent the false detection of failure. If the hardware does not support reliable communications, lower values can lead to premature failover. To achieve longer delays before failover, choose higher values. This may be necessary for IP addresses on slower networks or on a server that is not transaction critical. For example, failover would not be necessary in the case of a server restart. Additionally, in a cluster environment, you must take into account the time it will take for a virtual server to failover between nodes.

• Monitored IPs—Mark the IP addresses on the source that you want the target to monitor.
• Failover Trigger—Specify if you want failover to be triggered when all monitored IP addresses fail or if only one of the monitored IP addresses fail.
• Application Monitoring Settings—If you selected Application Monitoring as your Method to Monitor for Failover, you need to configure the script that will monitor your application.
• Monitoring Option—You have a choice of two monitoring methods.
• Built-In Monitoring—Double-Take Availability will monitor the application using WMI. Specify if you want Double-Take Availability to Attempt to restart services if the application services are not responding.
• Customer Monitoring Script—Click Browse to locate your own custom script that will monitor the application. The custom script can be PowerShell, Visual Basic, or JScript. Once your script is identified, you can click Edit to open a text editor to view or modify the script.

Note:

A sample Visual Basic script for application monitoring is available in the \Application Manager\Samples subdirectory where Double-Take Availability is installed. If you are using a PowerShell script, PowerShell must be installed on the target.

• Credentials—Specify a user with access to run the application monitoring script on the target. The user name must be a fully qualified name in the format domain\username or username@domain. If you are using the Built-In Monitoring script, the user must have full WMI access to the CIMV2 namespace. By default, the administrative group on Windows 2008 has full WMI access. If you are using Windows 2008, the user must be allowed through DCOM and User Access Control.

5. Click OK to save the settings.

Taking snapshots of the target

1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Snapshot tab.

Note:

Snapshots are not available in cluster environments.

2. A snapshot is an image of data taken at a single point in time. Snapshots allow you to view files and folders as they existed at points of time in the past, so you can, for example, recover from cases where corrupted source data was replicated to the target. By default, Double-Take Availability takes periodic snapshots of the data on the target. When failover is triggered, you can use the live target data at the time of failover or you can failover to a snapshot of the target data. Specify how you want to handle snapshots.

• Enable periodic snapshots—Enable snapshots if you want to be able to use them at failover time. If snapshots are disabled, the live data on the target at failover time will be used.
• Snapshot Interval—By default, snapshots of the target data are taken every 60 minutes. If desired, increase or decrease the interval between snapshots.
• Start now—If you want to start taking snapshots immediately after the application connection is established, select Start now.
• Start at—If you want to start taking snapshots at a specific data and time, select Start at and specify the date and time parameters.

3. Click OK to save the settings.

Application connection settings

You can configure routing and mirroring settings for your application connection. In addition, there are application specific settings that you can configure. The fields on the Connection tab will vary depending on the type of application you are protecting.

• Routing data transmissions
• Protection configuration
• Configuring Exchange storage group protection
• Configuring SQL database protection
• Configuring file share protection
• Configuring BlackBerry database protection
• Configuring SharePoint database protection
• Mirroring data