Double-Take Release Notes

Double-Take Availability and Double-Take Move version 6.0.0, June 20, 2012

© 1996-2012 Vision Solutions, Inc. All rights reserved.

This readme file contains last minute release notes about Double-Take Availability and Double-Take Move that are not included in the user documentation. The user documentation is available on the product CD and in the installation directory after you have installed the software.

Be sure to check the readme file posted on the Vision Solutions support web site for the latest release notes. The readme file contained in the self-extracting zip file or on the CD may not contain all of the most recent information.

Contents

Overview

  1. This release is an updated release that includes, but may not be limited to, the modifications listed in this section. Items marked with an asterisk (*) indicate the latest updates.
  2. Since this release is an updated release, it supersedes all previous releases but may not include all product changes provided as updates for specific issues. Updates are only distributed by technical support to address specific customer issues. The versions listed below have been incorporated into this release. If you are not using a version listed below, contact technical support. If you have one of the versions listed below, you can safely upgrade to this release.
  3. The version 6.0 release requires activation of each Double-Take license. If you do not activate each license within the required time frame, your Double-Take jobs will fail.

    For complete details on license activation, see the User's Guide or online help.

  4. With this release, you must upgrade any existing Double-Take activation codes using the following process.
    1. Log in to the support site at https://support.doubletake.com.
    2. Select Agreements.
    3. Select Request Activation Codes (6.0).
    4. Select the licenses you would like to upgrade and use for this release and click Submit.
    5. You will receive an email from CSRGroup@visionsolutions.com with the subject Upgraded Double-Take Activation Codes. This email includes your upgraded codes in an XML file along with instructions for how to import the codes. For complete details on importing a license file, see the User's Guide or online help.

Known issues

The following known issues apply to both Double-Take Availability and Double-Take Move, however the Double-Take Availability terminology is used. For example, protecting will also mean migrating for migration jobs and failover will also mean cutover for migration jobs.

Installation and licensing

  1. The version 5.2.1 and later Double-Take Management service utilizes the Web Services function over port 6325. In the 5.2.0 release, it was using port 80. However, there were port sharing conflicts with port 80 and other applications, therefore the port was changed for version 5.2.1. If you upgraded from version 5.2.0, then port 80 has been upgraded to port 6325. However, if you modified version 5.2.0 from port 80 to another port number, the port number you changed to will be retained.
  2. You can upgrade HP Storage Mirroring Recover version 5.2.2 to Double-Take Availability version 6.0. However, the installation directory will continue to be your Storage Mirroring Recover installation directory, which is \Program Files\HP\Storage Mirroring by default.
  3. If you are performing a push installation from the Double-Take Console, and the servers you are pushing to do not have a C drive, make sure you update the installation folder fields on the Install page. The Double-Take Console will not validate that the fields are set to a volume that does not exist, and the installation will not start. This issue may be resolved in a future release.
  4. If you are upgrading an existing job from version 5.3, you should configure manual intervention for failover before you upgrade. Any jobs that are set to automatic failover will have an Engine Connection Error after the upgrade. If you did not configure manual intervention and have the engine error, you will have to start a mirror (Other Job Actions, Mirror, Start) or stop and restart the job.
  5. If you are using Windows 2008, 32-bit, localized in Japanese, you must install Microsoft .NET Framework 3.5.1 manually on your target before installing Double-Take Move on the target.
  6. If you will be protecting a Linux source with a full server to ESX appliance job and you previously had Double-Take for Linux version 4.7, use the following steps to update the Double-Take driver on the Linux source to the new driver included in this release.
    1. Shut down all of your protected applications on your Linux source.
    2. Save your DTFS configuration by moving /etc/DT/dtfs_mounts to another location, outside of /etc/DT.
    3. If you were using full server protection with version 4.7, you will need to remove it using DTSetup (Setup tasks, Configure File System or Block Device Replication, Full Server Replication Configuration, Remove Full Server Protection).
    4. Stop the Double-Take service and driver using DTSetup (Start/Stop Double-Take daemon, Stop the running service and teardown driver config).
    5. If you were using full server protection with version 4.7, reboot the Linux source server to unload the old driver.
    6. Upgrade Double-Take on your Linux source using the installation instructions in the User's Guide.
    7. Restart Double-Take on your Linux source.

back to the top

Common issues

The following issues may be common to multiple job types within Double-Take Availability and/or Double-Take Move.

  1. If you have specified an IP address as the source server name, but that IP address is not the server's primary IP address, you will have issues with snapshot functionality. If you need to use snapshots, use the source's primary IP address or its name.
  2. Only one primary IPv6 address can be monitored for failover when using the replication service monitoring method. Therefore, if you have multiple IPv6 addresses per subnet, failover monitoring may not work properly with the replication service monitoring method. To ensure proper failover monitoring, use IPv4 addresses or use only a single IPv6 address per subnet with the replication service monitoring method. You can also use the network service monitoring method with any IPv4 or IPv6 configuration.
  3. If you are using Windows 2008 R2, virtual hard disks can be mounted and dismounted reusing the same drive letter. However, once you have established a job, you cannot mount a different virtual hard disk to the same drive letter used in your job. This could cause errors, orphan files, or possibly data corruption. If you must change drive letters associated with a virtual hard disk, delete the job, change the mounting, and then re-create the job. This issue may be resolved in a future release.
  4. If you are using SQL to create snapshots of your SQL database, the Double-Take Availability verification report will report the file size of the snapshot files on the source and target as different. This is a reporting issue only. The snapshot file is mirrored and replicated completely to the target. This issue may be resolved in a later release.
  5. If you are using HP StorageWorks File Migration Agent, migrated files will incorrectly report modified time stamp differences in the verification report. This is a reporting issue only. This issue may be resolved in a future release.
  6. During the job creation process, the Double-Take Console may select the wrong route to the target on the Set Options page. Make sure that you confirm the route selected is reachable from your source. This issue may be resolved in a future release.
  7. If you are performing DNS failover but your source and target are in a workgroup, the DNS suffix must be specified for the source NICs and that suffix must correspond to the zone name on the DNS server. This issue may be resolved in a future release.
  8. In a cluster configuration, if you add a possible owning node to the protected network name after a job has started, you must stop and restart the job. If you do not, the records for the new node will not be locked. This could cause problems with DNS records if the source cluster nodes are rebooted or the resources are otherwise cycled on the new owning node. This issue may be resolved in a future release.
  9. When you first open the Double-Take Console, the Home page may not show any jobs in an error state. If you go to any other page in the console and then return to the Home page, any jobs with errors will be displayed. This issue may be resolved in a future release.
  10. If you are using Trend Micro Firewall, shares may not be accessible after failover. You can work around this issue by resetting the NIC's IP address with the netsh ip reset command. For more details on using this command, see your Windows reference.
  11. If you are protecting a Hyper-V source and you select an existing Hyper-V server to use as the target, the Hyper-V Integration Services on the target must be version 2008 SP2 or greater. Without this version, the target may not start after failover. This limitation may be addressed in a future release.
  12. Because Windows 64-bit has a strict driver signing policy, if you get a stop code 0x7b after failover, you may have drivers failing to load because the driver signatures are failing the policy. In this case, reboot the server and press F8. Choose the option to not enforce the driver signing policy. If this allows the system to boot, then the problem is being caused by the cat file signature mismatch. This issue may be resolved in a future release. If your system still fails to boot, contact technical support.
  13. If you receive a path transformation error during job validation indicating a volume does not exist on the target server, even though there is no corresponding data being protected on the source, you will need to manually modify your replication rules. Go back to the Choose Data page and under the Replication Rules, locate the volume from the error message. Remove any rules associated with that volume. Complete the rest of the workflow and the validation should pass. This issue may be resolved in a future release.
  14. If you are using Windows 2008 and the Microsoft Windows Update feature, do not failover if the target is in the middle of an update that is waiting on a reboot. Otherwise, the failover reboot could repeat indefinitely. If you do get into this situation, you will need to access a command prompt through the Windows Recovery Environment and delete the file \Windows\winsxs\pending.xml file. This issue may be corrected in a future release.
  15. If you have specified replication rules that exclude a volume at the root, that volume will be incorrectly added as an inclusion if you edit the job after it has been established. If you need to edit your job, modify the replication rules to make sure they include the proper inclusion and exclusion rules that you want. This issue may be resolved in a future release.
  16. If you are using Double-Take over a WAN and do not have DNS name resolution, you will need to add the host names to the local host file on each server running Double-Take. See your Windows documentation for instructions on adding entries to host files.

back to the top

Job issues

  1. The following issues are for files and folders jobs.
    1. In some cases, when you failback before restoring your data from the target, your job may end up in a stopped state, not allowing you to continue with the next step of restoring. Click Start from the toolbar to restart the job, and then you can continue with the restoration process. This issue may be resolved in a future release.
    2. If you have two files and folders jobs created from the same source to the same target, only one failover monitor will be created. Therefore, if you delete one of the jobs, that shared failover monitor will be deleted. To re-create the failover monitor, you can stop and start the job (which will require a remirror) or you can restart the Double-Take Management Service (which will not require a remirror). This issue may be resolved in a future release.
  2. The following issues are for full server jobs and/or full server migration jobs.
    1. You will be unable to failover to a snapshot if your full server job is stopped. If you need to revert to a snapshot, contact technical support for a manual process. This issue may be addressed in a future release.
    2. Right before failover occurs, Double-Take will stop all services that are not critical to Windows. If the stop command fails (perhaps because it is a blocking driver that cannot be shutdown, as is the case with some anti-virus software) or a third-party tool restarts any of these services, Double-Take may not be able to successfully failover files locked by the services. In this case, you may have to make manual modifications to your server after failover.
    3. After a failover is complete and your target server is online as your source, when you login, you may have to specify a Windows reboot reason. You can specify any reason and continue. Additionally, you may see a prompt indicating a reboot is required because of a device change. You can disregard this error and select to reboot later.
    4. If the login credentials for your source and target are different, you will be unable to restart your job after a reverse. In this case, you will need to update the credentials for the target server and then stop and restart the Double-Take Management Service on the target server.
    5. Before you reverse a full server job, make sure the production NIC on your original source is online. If the NIC is disabled or unplugged, you will experience problems with the reverse. This issue may be resolved in a future release.
    6. The full server reverse process will not update DNS. You will have to manually configure DNS updates after a reverse. This issue may be resolved in a future release.
    7. The backup job, when a full server protection job is configured for reverse, may become orphaned after the initial backup job has been completed, manually updated, and then the target server is restarted. In this specific case, you will need to contact technical support for a workaround to use the backup job during a reverse. This issue may be resolved in a future release.
  3. The following issues are specific to Exchange and SQL jobs.
    1. You may receive an error when trying to failback to the source cluster if the application’s virtual IP address is offline. Verify the source cluster’s virtual name and IP address resources are online, as well as the application’s virtual IP address resource, and retry failback.
    2. The test failover process may display an error -2402 when trying to revert a snapshot. Clicking Undo Failover will resolve the snapshot revert issue and allow you to continue the test failover. You can repeat the same process next time you revert to a snapshot during a test failover, or you can contact technical support for assistance in resolving the underlying issue.
    3. The following issues are specific to Microsoft Exchange protection.
      1. The CatalogData directory will not be mirrored to the target, but will be regenerated automatically on the target after failover. Searching through messages after failover may be slower until the catalog data is rebuilt.
      2. If you are protecting Exchange 2007 and will only be protecting a subset of the storage groups, the storage groups you are protecting cannot have a space followed by a hyphen in the storage group name. You will either need to change the name of the storage group to remove the space followed by the hyphen, or select all of your storage groups for protection.
      3. If you are protecting Exchange 2007 or Exchange 2010 and need to use the Exchange Management Console while the Double-Take Availability test failover process is running, you will need to start the IIS service. Stop the IIS service after the test failover is complete.
      4. If you are protecting Exchange 2010, arbitration mailboxes will not be failed over. These mailboxes can be rehomed manually using the Set-Mailbox -database PowerShell command.
      5. If you are protecting Exchange 2010 and you have a consolidated target server, you must have a send connector configured specifically with the target server before failover. Otherwise, you will be unable to send email to the Internet after failover. This issue may be resolved in a future release.
      6. If you are protecting Exchange 2010, the Fix All option may report validation errors if a public folder store already existed on the target before a clone but there is no corresponding public folder store on the source. You can disregard the errors. Subsequent fixes and validations will be successful.
      7. If you are protecting Exchange 2010 DAG or are in a non-DAG cluster environment, failback may be unsuccessful if you experienced a hard failover. If possible, move the source DAG or cluster to the original owning node when failover occurred and retry failback.
      8. If you are protecting Exchange 2010 in a DAG environment and a mailbox store fails to come online after failback, you will need to manually mount the store. If that does not work, contact technical support for assistance.
  4. The following issues are specific to virtual job types, including full server to Hyper-V, V to Hyper-V, full server to ESX, full server to ESX appliance, V to ESX, full server to ESX migration, and full server to Hyper-V migration.
    1. If you are protecting your source to a Hyper-V target and the source is running on Windows Server 2008 and the target replica has one or more SCSI drives, then after failover the CD/DVD ROM will not be allocated. If the CD/DVD ROM is required, you will need to edit the virtual machine settings to add a CD/DVD ROM after failover. By not allocating a CD/DVD ROM under these specific conditions, drive letter consistency will be guaranteed.
    2. If you are protecting a Windows 2008 source to ESX or Hyper-V and the source SAN policy is not set to Online, then the non-boot volumes will be offline after recovery.  You will have to manually bring them online.
    3. Do not protect a Windows 2003 32-bit source to a Windows 2003 32-bit virtual recovery appliance using a bus logic controller. The replica virtual machine will blue screen. This issue may be resolved in a future release.
    4. If you are using Windows 2008 R2 Service Pack 1 in a cluster environment, SCVMM may incorrectly report your virtual machine as missing after the Double-Take Availability reverse process. To workaround this issue, remove the virtual machine from SCVMM and it will automatically be added back in the proper state. This issue may be resolved in a future release.
    5. After failover of a full server to Hyper-V job, other full server to Hyper-V jobs may experience slower job processing. This issue may be resolved in a future release.
    6. The full server to ESX appliance job is included with this release, but it is not completely release ready. This job type is production ready (in an FCS state), but you may encounter unknown issues. Report any issues you experience to technical support.
  5. If you are using GeoCluster and the Windows Firewall, you need to open port 1105 for TCP and UDP communication. This limitation may be removed in a future release.

back to the top

Contact information

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 Vision Solutions, 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-2012 Vision Solutions, Inc. All rights reserved.