Quest® vRanger® 7.8.1

Quest® vRanger® 7.8.1

March 2020

These release notes provide information about the Quest® vRanger® release.

About this 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 capabilities:

•	Performs incremental, differential, or full image backups of virtual and physical machines.

•	Restores the entire machine or specific files.

•	Manages disaster recovery strategies and protects critical data in virtual environments.

•	Replicates VMs to more than one destination, which lets you accomplish multiple high-availability and disaster recovery objectives based on your specific needs.

vRanger 7.8.1 is a maintenance release with minor enhancements and defect resolutions. See Enhancements and Resolved issues for more detailed information.

Enhancements

Enhancements

The following is a list of enhancements implemented in vRanger 7.8.1.

Table 1. General enhancements

Enhancement

Enhanced support for encrypted VMware VMs

Support for VDDK 6.7u3

Resolved issues

Resolved issues

The table below lists the defects resolved in this release of vRanger:

 

Table 2. Resolved issues

Issue description	Issue ID
FLR service fails to start when vRanger is installed on Windows Server 2012.	VR-1106
Unable to upgrade encrypted VA with scratch disk.	VR-1154

Known issues

Known issues

The following is a list of issues, including those issues attributed to third-party products, known to exist at the time of release.

 

Table 3. Installation known issues

Known issue	Issue ID
The vRanger Service does not start after installing vRanger on Windows Server 2008 R2 SP1.   Workaround: When installing vRanger on Windows Server 2008 R2 SP1, the Windows Management Framework 3.0 must also be installed in order for the vRanger Service to run. Options for installing WMF 3.0 are: Before installing vRanger: 1 First, manually install the Microsoft .Net Framework 4.5. 2 Install the Windows Management Framework 3.0 using the installer available in Microsoft KB article KB2506143. 3 Install vRanger. After installing vRanger: 1 Install vRanger as documented in the vRanger Installation/Upgrade Guide. If the .Net Framework 4.5 is not already installed on the server, it will be installed automatically during the vRanger installation process. 2 Install the Windows Management Framework 3.0 using the installer available in Microsoft KB article KB2506143. 3 Confirm the vRanger Service is started. 4 Start vRanger.	VR-177
When installing or upgrading vRanger on a Micrsoft Windows 2012 R2 Server, the vRanger GUI may fail to launch with following error: “FileNotFoundException. Could not load file or assembly 'Vizioncore.vRanger.FLR.dll' or one of its dependencies. The specified module could not be found.”   Workaround: This issue is caused by a corrupted Visual C++ 14.0 installation on the installation server. To resolve this issue 1 Uninstall the current Visual C++ 14.0 instance. 2 Install the updates from the following Microsoft Knowledge Base articles: ▪ KB2939087 ▪ KB2975061 ▪ KB2919355 ▪ KB2999226 3 Reinstall VC++14.0 4 Perform fresh install /upgrade for vRanger.
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. Workaround: 1 Log in to Windows as the install user. 2 Run a command prompt, and type: sqlcmd -S .\vRangerPro use vRangerPro go 3 Replace VRANGER\vRangerServiceUser with the name of the vRanger service user in the following command: EXEC sys.sp_addsrvrolemember @loginame=N'VRANGER\vRangerServiceUser', @rolename=N'sysadmin' go quit exit 4 Stop and start the Quest vRanger Service. vRanger is able to connect to the service.	17210
When vRanger is installed on Windows 8.1 or Windows Server 2012, using the Uninstall icon to remove the application fails unless the uninstall is performed using the Administrator role. Workaround 1: 1 Move the cursor to the upper-right or lower-right corner of the screen. 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. The uninstall starts as it normally does. Workaround 2: You may also uninstall vRanger using the Programs and Features application in the Control Panel.	15470
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. Workaround: 1 Log in to the vRanger machine using the account used to run the three vRanger services. If you are unsure what the account is, use Microsoft Management Console (MMC) to check the services.msc file. 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. If the second local admin account does not have access to the database, grant that account administrator access to the SQL Server instance before installation.	16034

 

Table 4. General known issues

Known issue	Issue ID
Domain controller and domain authentication issues can cause errors such as: • 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. Workaround: The following lists some common situations that can cause these issues: • System Time synchronization: If any of the systems — AD server, the DNS server, and so on — is not within the allowed time drift, authentication can fail. • 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	15187
When a Backup Group contains two Windows 8.1 or Windows Server 2012 VMs that are clones of each other, and that group is backed up using HotAdd, only one of the cloned machines restores properly.	15112
During periods of heavy activity on the vRanger machine, HotAdd backup tasks may fail over to LAN backups with the following message. Sometimes, the LAN backups fail with the same error. Backup task using VDDK Hot-add failed: RETRY operation timed out [at xtimedwait:416] These errors can be caused by excessive resource contention, which causes vRanger message queues to become out of synch. Workaround 1: To avoid task timeout errors, schedule jobs to avoid excessive resource contention on the vRanger machine. Workaround 2: If rescheduling jobs is not an option, you may increase the timeout value to allow the vRanger message queues to recover from issues caused by resource contention. To change the timeout value: 1 Browse to the vRanger installation directory. 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. 4 Save the file. 5 Restart the Quest vRanger Service to implement the changes.
When the vCenter User credentials are changed, the change does not take full effect until the Quest vRanger Service is restarted.	17038
In some circumstances, Changed Block Tracking (CBT) does not show as enabled for some VMs in the vRanger inventory. This issue is due to an error described in VMware KB article 2075984. Workaround: To resolve this issue, perform the workaround documented in VMware KB article 2075984.	17528
When creating Hyper-V virtual machines, avoid using special characters. The [ ] (square brackets) and ‘ (backtick) specifically should not be used.
When adding a CIFS repository, the Security Protocol setting applies only to Virtual Appliance based operations. For machine-based operations, the security protocol used is determined by the Windows configuration on the vRanger machine. By default, this is NTLM. Workaround: To use NTLMv2, you must edit the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel to set the LmCompatibilityLevel to 5.	VR-1236

 

Table 5. Backup known issues

Known issue	Issue ID
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 VMware KB article 1002403. Workaround: To resolve this issue, perform the workaround documented in VMware KB article 2002506.	17591
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.	14130
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 VMware KB article 2090639. Workaround: Ensure that the patches described in VMware KB article 2090639 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. Workaround: For options to resolve this issue, see VMware KB article 1037071.
When using a Microsoft Storage Spaces Direct (S2D) cluster as a repository, VA-based HotAdd will fail with error “Error 2258: FATAL cifs_cant_mkdir”.   Workaround: Add the VA into the same domain as the S2D cluster.	VR-1158
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.   Workaround: Remove the VM with the VHDS file from the Hyper-V cluster or host and then try to add the Hyper-V cluster or host to the vRanger inventory.	VR-1365
The use of SAN transport mode is not supported when working with encrypted VMs. This is due to a VMware VDDK limitation documented here.

 

 

Table 6. Restore and file-level restore (FLR) known issues

Known issue	Issue ID
When vRanger is installed on Windows Server 2019, attempting to perform a FLR on an ReFS volume causes the vRanger machine to crash.   Workaround: ReFS is not supported as removable media on Windows Server 2019. FLR for ReFS volumes when vRanger is installed on Windows Server 2019 is not supported.	VR-990
When restoring a VM that had an ISO connected when the VM was backed up, the restored VM does not have the ISO connected. Workaround: To ensure that ISO images are attached to a VM when restored: • 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. • Ensure that the path to the ISO image is available to both the backup source VM and the restore target VM.	8366
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. Workaround: Either disassociate — disconnecting is insufficient — the host from the vCenter, or register the vCenter in vRanger.
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: \ : * " ? < > |
The vRanger cataloging feature does not support operation against dynamic disks.	13755

 

Table 7. Physical backup and restore known issues

Known issue	Issue ID
The vRanger Restore CD is not compatible with UEFI. Physical target servers booting into UEFI will not boot the Restore CD. Workaround: To restore a backup to a physical server booting into UEFI, change the boot mode to BIOS. To do so, follow the steps below: 1 Change the boot mode to BIOS for the physical server. 2 Boot using restore CD. 3 Perform restore from vRanger. 4 After successful restore from vRanger, change the BIOS mode back to UEFI.	VR-422
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. Workaround: If possible, adjust the backup schedule so that the backup is performed during a period of lower resource consumption.	16589
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. For instructions, see the Microsoft TechNet article Add the Log on as a service right to an account.	15278
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.	14470
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. Workaround: Ensure that you only configure one restore task per server.	14507
When performing physical backups of an Exchange 2010 server, the task fails with the “Failed to create VSS snapshot on the target machine (P_VSSUTIL_WRITER_ERR)” error. Workaround: To protect Exchange 2010 with physical backups, install Exchange Server 2010 Service Pack 2 on the source server.	14426
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.	14712

 

Table 8. Replication known issues

Known issue	Issue ID
Successfully replicated encrypted VM with different types of controllers fails to reboot.	VR-1163
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.   Workaround: Ensure that replication jobs are configured between hosts running the same version of VMware ESXi.	VR-1104
Replication to a target containing vRDM disks is not supported.	16612
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. Workaround: Either disassociate — do not simply disconnect — the host from the vCenter, or register the vCenter in vRanger.
When performing a failover operation, without synchronizing changes, and the source host is unavailable, the failover task fails and you must manually perform the failover. Workaround: 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: 1 Disable the original replication job. 2 Power on the destination VM manually. 3 Operate as needed using the destination VM. 4 After the source host is up again, set up a new replication job using the pre-seed function, selecting the original source VM as the pre-seed target. 5 Run the pre-seed replication job. 6 After the job is successful, run a test failover to verify that the changes have been transferred. 7 Power off the destination — disaster recovery — VM, and power on the original source VM. 8 Enable the original job again. The next replication pass should be successful.
When replicating a VM with a name containing a space in front of a bracket, “ [,” the replication task hangs at 12%.	12163
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.   Workaround: On the vRanger VA, execute the commands #cd /root/vautil/ ./scratch_scsi.sh -c After executing the above commands, reboot the virtual appliance.	VR-1336
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.   Workaround: Create a new replication job with the new disk included.	VR-1376

 

Table 9. Virtual appliance (VA) known issues

Known issue	Issue ID
Deploying a VA to a standalone host fails if the host is managed by a vCenter.	16792
When deploying the vRanger VA using the Virtual Appliance Deployment Wizard, only one VA is allowed per host. If a second VA deployment is attempted, the VA Deployment Wizard does not let you deploy a VA to a host that has an existing VA.	13606
When creating a VA with the Install-VirtualAppliance vAPI cmdlet, enabling the VADeployStatus parameter may cause failures when used with multiple VAs. Workaround: When deploying more than three VAs with the vAPI cmdlets, use the Get-VirtualApplianceDeploymentStatus cmdlet to retrieve the status.	13834
In some environments, it may be necessary for a customer to add a second network interface card (NIC) to the vRanger VA. To add a second network card: 1 In the vSphere client, add the NIC to the VA. 2 Power on or reboot the VA. 3 Log in to the VA. 4 Run the command: dmesg | grep "rename.*eth" You see two messages indicating the renaming of the real NICs with new Udev NIC names. 5 Find the Udev NIC name for the new NIC, and note the name indicated for the renamed NIC. 6 Run the command: cd /etc/sysconfig This directory already contains one configuration file for the first NIC. 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: vi ifconfig.<IFname> 8 Add these lines: == For DHCP (SAMPLE NIC Interface Name): ONBOOT=yes SERVICE=dhcpcd IFACE=enps2 DHCP_STOP="-k" PRINTIP=yes PRINTALL=no   == For Static (SAMPLE NIC Interface Name & IP Addresses): ONBOOT=yes SERVICE=ipv4-static IFACE=enps2 IP=192.168.1.1 GATEWAY=192.168.1.254 PREFIX=24 9 Restart networking by running the command: /etc/init.d/network restart 10 Check the new NIC and IP configuration by running the command: ifconfig

 

Table 10. Third-party known issues

Known issue	Issue ID
When special characters are used in a file or folder name, you cannot see that file or folder when browsing the datastore in vCenter. This issue is documented in more detail in the VMware KB article 1015650.
When creating a Hyper-V backup job, mixing VMs with Cluster Shared Volumes (CSV) and non-CSV volumes is not supported. For more information, see Microsoft KB article 2771882.