Quest® vRanger® 7.8.1
These release notes provide information about the Quest® vRanger® release.
vRanger Backup & Replication is the market-leading backup, recovery, and backup-management solution for VMware® and Hyper-V® virtual environments. vRanger automatically discovers new virtual machines (VMs), reduces backup windows, provides smarter backup options, and offers more scalability through its agent-less architecture and features while using fewer resources.
vRanger 7.8.1 is a maintenance release with minor enhancements and defect resolutions. See and for more detailed information.
Table 1. General enhancements
Table 2. Resolved issues
Table 3. Installation known issues
If the Quest vRanger Service is installed with a user other than the currently logged in user, use mixed-mode authentication for SQL Server® and authenticate with the system administrator (sa) user.
Alternatively, Windows®-only authentication can be used if the following workaround is implemented.
3 Replace VRANGER\vRangerServiceUser with the name of the vRanger service user in the following command:
2 When the Charms bar appears, select the Start icon.
3 Right-click in an empty space on the Start screen, and select All Apps.
4 Using the scroll bar at the bottom, scroll right to the Quest section.
5 Look for the Uninstall tile above the vRanger Backup & Replication tile.
6 Right-click the Uninstall tile, and select Run as Administrator.
When a proxy server is configured on the vRanger machine, vRanger may not be able to connect to VMware® vCenter™ Servers or NetVault SmartDisk repositories.
2 Open Internet Explorer® (IE) while logged-in with the account.
3 Go to Internet Options > Connections > LAN settings; this location varies depending on the version of IE installed on the machine.
4 Make sure that no proxy information is defined, and no proxy server is being used.
5 Clear the automatically detect settings check box, in case your particular environment has an automatic proxy script set up.
If vRanger is installed using a local admin account, and that account is changed after vRanger is uninstalled, you must use SQL Server authentication for the database installer for both vRanger and Cataloging when you reinstall vRanger.
Table 4. General known issues
• VM backups encounter 2129 Can’t Write errors to CIFS repositories with any transport type.
• Physical machine backups encounter 2129 Can’t Write errors to CIFS repositories.
• Virtual appliance (VA) backups fail with 2129 Can’t Write errors to CIFS repositories.
• Physical machine shows as Disconnected in Inventory.
• Domain membership: The machine may be part of the domain, as seen when you bring up the computer properties, but the membership may not be active, and may have to be reset. To check the status of the systems domain membership from the machine itself, use the command: netdom verify %computername% /verbose
By default, this directory is C:\Program Files\Quest\vRanger.
2 Open the Vizioncore.vRanger.Service.exe.config file in Notepad.
3 Search the file for CommitTimeout, and change the timeout value to 450.
5 Restart the Quest vRanger Service to implement the changes.
To use NTLMv2, you must edit the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel to set the LmCompatibilityLevel to 5.
Table 5. Backup known issues
When performing SAN backups of VMs created in VMware® vCloud Director® from a template, the backup may fail with the “Error: 2760 - <VIXcannotOpenDetails> VIX can’t open…” error.
The VMware SAN mode transport searches for VMs by BIOS UUID. By default, all instances and VMs that are deployed from a given catalog vApps/template in vCloud Director are assigned the same BIOS UUID. For more information, see .
When performing a quiesced backup of a Windows Server 2012 VM without using vzShadow.exe, event log errors are generated for System Reserved volumes during snapshot creation.
The VMware QueryChangedDiskAreas API returns incorrect sectors after extending the VM VMDK file with CBT enabled. This issue causes the CBT filter to become invalid, possibly corrupting vRanger backups. For more information, see .
Ensure that the patches described in are applied, and follow other workaround recommendations documented in the KB as appropriate for your environment.
When using the vzShadow.exe executable to perform application-consistent backups, lettered drives are required. The use of vzShadow.exe to quiesce mount points with databases is not supported.
When backing up Windows Server 2008 R2 VMs with multiple disks, and the Enable Guest Quiescing option is selected, some backup tasks may fail with the “API Call failed with message: A general system error occurred: Protocol error from VMX” error.
Backup of Hyper-V VHD Sets is not supported by vRanger. While adding the Hyper-V host or Hyper-V Cluster in the vRanger inventory that contains a VM with VHD Sets disk, the Hyper-V host or Hyper-V Cluster gets added but remains in disconnected status.
• Change the VM settings to set the StartConnected value of the CD-ROM-image device to True.
• Ensure that the restore job option Force Power On is enabled.
When a standalone ESXi host is added to the vRanger inventory, and that Host is associated with a vSphere® vCenter that is not in the vRanger inventory, restore operations to that host fail with the error:
“<host> is being managed by a Virtual Center. Please disassociate the host from the Virtual Center before continuing a Restore operation or register the Virtual Center in vRanger.”
Association is relationship in vSphere, whereby some host resources are managed only by an associated vCenter, and not the host itself. The Host, therefore, does not have permission to perform the operations required to restore a VM. If the vCenter is not in the vRanger inventory, vRanger cannot obtain the required permissions.
When performing a Linux® FLR operation that recovers files and folders with the following characters in the name, the files and folders are displayed with what look to be randomly generated names, and are restored successfully with same random names. Characters that cause this behavior are:
Physical backup of Windows Server 2012 and 2012 R2 machines may fail with the “Failed to create VSS snapshot (P_VSSUTIL_WRITER_ERR)” message. This issue is often due to a VSS timeout caused by resource contention on the source server.
When deploying the vRanger physical client to a physical server, the account used to install and run the client must have administrative Log on as a service rights. If this computer is a node in a cluster, check that this user right is assigned to the Cluster service account on all nodes in the cluster.
If you have already assigned this user right to the service account, and the user right appears to be removed, a Group Policy object associated with this node might be removing the right. Check with your domain administrator to find out if this issue is happening.
The use of dynamic disks are not supported for physical backup. If a physical backup task is performed on a source server containing dynamic disks, the task fails with the “Value cannot be null” message.
When restoring to a physical server, vRanger does not lock the source or savepoint. This behavior potentially allows the un-supported practice of creating two simultaneous restore tasks to the same server.
When performing physical backups, if the credentials used for authenticating to the source server are changed without updating vRanger, subsequent backup tasks fail with the “Failed to acquire shared resources (Unable to connect to the backup destination.) Failed to connect to the backup destination” error. When this issue occurs, update the credentials in vRanger.
Table 8. Replication known issues
The vRanger replication wizard will allow you to create a job replicating from a higher hardware version to a lower hardware version. When executed, the job will fail with error "Error: API Call failed with message: The virtual machine version is not compatible with the version of the host."
VMware ESXi 6.7u2 introduces hardware version 15. This hardware version is incompatible with ESXi versions 6.7u1 or lower. When configuring a replication job from a 6.7u2 host to a host running 6.7u1 or earlier, the VM hardware versions will be incompatible.
When a standalone ESXi host is added to the vRanger inventory, and that Host is associated with a vSphere vCenter not in the vRanger inventory, replication operations to that host fail with the error:
“<host> is being managed by a Virtual Center. Please disassociate the host from the Virtual Center before continuing a replication operation or register the Virtual Center in vRanger.”
Association is a relationship introduced in vSphere 5, whereby some host resources are managed only by an associated vCenter, and not the host itself. The Host, therefore, does not have permission to perform the operations required to replicate a VM. If the vCenter is not in the vRanger inventory, vRanger cannot obtain the required permissions.
A failover operation performs two key tasks that need to be performed manually if the operation fails: powering on the destination VM, and reversing the direction of replication to ensure that changes to the destination VM are captured when operation reverts to the production site. To replicate a failover task manually, perform the following steps:
When performing replications, in some cases the scratch disk reconfiguration process may result in the replication job failing with error “The virtual appliance 'VA-Name' has not been configured with a required data disk.”. This is the result of a stale disk on the virtual appliance.
When editing a replication job, disk selection for newly added disks is disabled. This is observed only when the disks initially added in the replication job are of a different controller type than the newly added disk.
Table 9. Virtual appliance (VA) known issues
4 Run the command: dmesg | grep "rename.*eth"
6 Run the command: cd /etc/sysconfig
7 Run the following command to create and edit the configuration file for the new NIC where <IFname> is the new name for the new NIC card:
9 Restart networking by running the command: /etc/init.d/network restart
Table 10. Third-party known issues