|vSphere Data Protection 6.1.4 Release Notes | 16 March, 2017
These release notes include the following topics:
The following link provides information about the vSphere Data Protection features
in this release: Introduction to Data Protection.
The following section describes the vSphere Data Protection change in
Enabled Transport Layer Security (TLS) 1.2 on vSphere Data Protection appliance
For a vSphere Data Protection appliance that has TLS 1.2
enabled to support a vCenter Server 6.0 U3 that has TLS 1.2 enabled, perform the following steps:
- From VMware website, download the Hotfix275948-7.2.80-124.avp package to the /data01/avamar/repo/packages directory on the vSphere Data Protection appliance.
- Open the vSphere Data Protection avinstaller GUI by using the following URL:
- Log in to the vSphere Data Protection appliance, to which you downloaded the Hotfix275948-7.2.80-124.avp package, by using the root credentials.
- Go to the available package list.
The Hotfix275948-7.2.80-124.avp package is in the Ready to install state.
- Install the package.
For information on supported environments, see the
VMware Interoperability Matrix.
Best Practices to Deploy vSphere Data Protection
The following are the best practices to deploy vSphere Data Protection:
- For a better performance of vSphere Data Protection in a high-scaled environment, where Data Domain is the destination or the target, use the following reference to deploy the number of virtual machines according to the capacity of vSphere Data Protection appliance:
|vSphere Data Protection Appliance Capacity
||Number of Virtual Machines to Deploy
- For effective load balancing, deploy a maximum of 10 vSphere Data Protection appliances with 100 virtual machines per vSphere Data Protection appliance, in a single vCenter Server domain.
- In a large environment, deploy a maximum of 8 proxies per vSphere Data Protection appliance regardless the size of the vSphere Data Protection appliances.
- For better performance of backups and restores, limit the size of each virtual machine to a maximum of 2 TB.
Known Problems and Limitations
The following are the known problems and limitations in this release
of vSphere Data Protection.
- Support for routed / NAT / Firewall / IDS / TSNR between the vSphere Data Protection appliance and vCenter Server. (1292848)
When configuring the network for the vSphere Data Protection appliance and vCenter Server, modifying network address information using NAT or other configuration methods (for example: firewall, IDS, or TSNR) is not supported.
When those tools are deployed as part of the virtual network, some vSphere Data Protection functionality may not work as designed.
- Powering On a virtual machine fails when the backed up virtual machine was connected to DVS and restored to other ESXi. (222475)
When powering on a virtual machine after you restore it, vCenter Server returns a PowerOnFailure error similar to the following:
DRS cannot find a host to power on or migrate the virtual machine. Network interface 'Network adapter 1' uses network '77 d3 02 50 5f 76 ca d7-db f9 42 6c 0f 6f 87 1f', which is not accessible
This error message occurs when the environment where you restore the virtual machine does not have the network connection that was present when you backed up the virtual machine.
For instance, a user backs up a virtual machine that is connected to a distributed vSwitch. Then the user restores the virtual machine to an ESXi host that is part of a Distributed Resource Scheduler (DRS)
cluster. The vSwitch does not exist in the DRS cluster. Powering on the virtual machine, therefore, fails.
Edit the virtual machine settings, set the network connection to the network adaptor, and then power on the virtual machine.
- The VM MAC conflict alarm appears after you restore a virtual machine to an alternate location. (1588177)
After you successfully restore a virtual machine that either vCenter Server 6.0 P2 or vCenter Server 6.0 U2 manages, to an alternate location, the VM MAC conflict
alarm appears on vCenter Server though the MAC address has changed during the restore.
Acknowledge the alarm and clear it.
- If the name of the data store that you have selected to restore contains either non-ASCII characters or high-ASCII characters, the restore operation fails. (1755102)
Ensure that the name of the data store does not contain either non-ASCII characters or high-ASCII characters.
- If the vCenter Server password contains either non-ASCII characters or high-ASCII characters, you cannot create a storage. (1755156)
Ensure that the vCenter Server password does not contain either non-ASCII characters or high-ASCII characters.
- ISO detection fails during upgrade from vSphere Data Protection 6.1 to 6.1.1. (244505)
Before you upgrade the vSphere Data Protection appliance, perform the following steps:
- From the vSphere Data Protection 6.1.1 installation package on the vSphere Data Protection appliance that you want to upgrade, copy the VDP61_Iso_Hotfix.tar.gz file to any directory, for example, /root on the same
vSphere Data Protection appliance.
- Extract the VDP61_Iso_Hotfix.tar.gz file by running the following command:
tar -zxvf VDP61_Iso_Hotfix.tar.gz
- Go to the VDP61_Iso_Hotfix directory.
- Add the execute permissions to the VDP61_Iso_Hotfix.sh file by running the following command:
chmod a+x VDP61_Iso_Hotfix.sh
- Run the VDP61_Iso_Hotfix.sh file:
The hotfix checks whether it is running on vSphere Data Protection 6.1. If the hotfix cannot detect vSphere Data Protection 6.1, it exits without applying any changes.
The hotfix backs up the vdr-configure.war file of vSphere Data Protection 6.1 to the /VDP_Files directory. You require the vdr-configure.war file if you want to revert vSphere Data Protection to the state, in which it was before running the hotfix.
- After you upgrade vSphere Data Protection, the Storage tab in the GUI does not display the Data Domain information. (269636)
Start the vSphere Data Protection console, and perform the following steps:
vSphere Data Protection upgrade from 6.1 fails at 60% progress. (270037)
- Run the following command:
admin@vdpmachine:~/>: ssh sysadmin@dd_ip
- SSH to the Data Domain system.
- Leave the passphrase prompt blank.
- In the password prompt, type the password of the Data Domain system user.
- Proceed with other prompts as required.
The Data Domain system information appears.
- To exit the Data Domain system, run the following command:
- Upgrade vSphere Data Protection from 6.1 to 6.1.2.
- Upgrade vSphere Data Protection from 6.1.2 to 6.1.3.
- Upgrade vSphere Data Protection from 6.1.3 to 6.1.4.
vSphere Data Protection Issues
- Incorrect behavior of the vSphere Data Protection appliance when more disks are added to the same SCSI slots. (59774)
The vSphere Data Protection appliance initiates a restore operation with the same SCSI IDs on the same existing virtual machine assigned to two different restore points.
In addition, the Summary page incorrectly indicates that two new virtual disks will be added.
The Restore operation completes successfully without informing the user that only the first single disk was added, and the second disk simply replaced the first disk.
- A password change on a configured vCenter Server instance is not allowed on the vSphere Data Protection appliance, even after the vCenter Server password has expired. (59497)
The vSphere Data Protection-Configure application does not allow a password change for the configured vCenter Server instance if backups are in a Running state on the server.
If the user password on the configured vCenter Server instance has already expired, no tasks are posted on the task console, and, consequently, the tasks cannot be canceled.
Perform the following steps:
- Wait until all the backups and tasks finish in the vSphere
appliance and then change the password.
- Restart the vSphere Data Protection appliance in the maintenance window, and then log into the
vSphere Data Protection-Configure user interface and change the
vCenter Server password from the vSphere Data Protection-Configure user interface.
- The Performance Assessment Test (PAT) result changes to Never Run when the datastore name is changed. (59784)
In this scenario, the user opens the vSphere Data Protection-Configure user interface, clicks the Storage tab, selects a datastore, and clicks the Run performance analysis on storage configuration checkbox.
The performance analysis test completes successfully and the results of the performance analysis are displayed correctly.
If the user changes the name of the datastore, however, the performance analysis results erroneously indicate the status as Never Run.
- The vSphere Data Protection GUI displays an error message in the Firefox browser when you edit a Data Domain device. (231126)
If you edit a Data Domain device by using the vSphere Data Protection GUI or the vSphere Data Protection configuration utility in the Firefox browser, an error message, which states that editing the Data Domain device has failed, appears even though the configuration is correct.
Use either the Chrome browser or the Internet Explorer browser.
- The Configuration tab page displays the services are not running messages after either restarting vSphere Data Protection or initial configuration. (235086)
After either restarting vSphere Data Protection or initial configuration, the Configuration tab page of the
vSphere Data Protection configuration utility displays the following messages, and the proxies’ status in red.
Backup and recovery services are not running.
File Level Restore service is not running.
The messages disappear after 20 minutes.
To make the messages immediately disappear, click the refresh button beside Proxies.
- The status of the Data Domain devices on the Storage tab page appears wrong after either changing the vSphere Data Protection password or restarting the management service. (237934)
After either changing the vSphere Data Protection password or restarting the management service, the following message appears on the Storage tab page for the Data Domain devices:
Data Domain storage status not available. Unable to retrieve ssh key file pair.
However, after approximately 20 minutes, the Data Domain devices appear online.
- The vCenter Server certificate does not appear in the vCenter Registration window though the certificate is uploaded during the initial configuration of vCenter Server. (238242)
Though the vCenter Server certificate is uploaded during the initial configuration of
vCenter Server, the certificate does not appear in the vCenter Registration window of the
vSphere Data Protection configuration utility. Also, the user selection does not persist.
You must upload the vCenter Server certificate whenever you register
- If a vCenter Server instance has vSphere Data Protection appliances of multiple versions, the UI of any vSphere Data Protection version displays the features of the latest version. (235357)
- The vSphere Data Protection-Configure user interface either is not accessible or hangs on the initialization progress bar window. (267125)
Refresh the vSphere Data Protection-Configure user interface page to access the required page.
- If you install vSphere Data Protection 6.1.2.x and any later version on the same vCenter Server, sometimes you notice unexpected behavior of the vSphere Data Protection plug-in (GUI). (267573)
After the initial configuration of the latest vSphere Data Protection completes:
- Log out from the vSphere web client.
- Clear the browser cache.
- Log in to the vSphere web client.
- When you reconfigure vSphere Data Protection, sometimes the backup scheduler service does not automatically start. (268661)
Wait for 10 minutes, and then manually start the backup scheduler service by using the vSphere Data Protection configuration utility.
- While configuring vSphere Data Protection, specifying the load balancer IP address in the vCenter Registration window displays an error message. (268915)
vSphere Data Protection does not support the load balancer certificate. So, configure vSphere Data Protection without specifying the load balancer IP address.
- In case of vCenter Server 6.5, vSphere Data Protection does not support backups and restores of encrypted virtual machines. (270169)
- vSphere Data Protection fails to deploy an external proxy in a VxRail environment. (270040)
vSphere Data Protection fails to deploy an external proxy in a VxRail environment because VxRail contains only distributed vSwitch and ESXi cluster configuration.
Before you deploy an external proxy in a VxRail environment:
- Create a standard switch on the ESXi, on which you want to deploy the external proxy.
The standard switch enables you to deploy the external proxy on any switch (standard or
- [Optional] Perform the configuration steps that the following KB article describes, as required:
- Loading clients takes a significant amount of time when editing or cloning a backup job. (50334)
The edit or clone action of a backup job for a SharePoint Server (upgraded plug-in) takes 5 to 10 minutes to load clients.
In addition, some delay occurs when loading clients for Microsoft Exchange and SQL servers that were created before an upgrade.
This is a known issue that will be fixed in a future release.
- Progress of a large size backup stalls at 92%. (270172)
In case of a backup of size more than 50 GB, the progress bar first proceeds to 92% regardless the actual progress of the backup, and then stalls till the backup completes.
This behavior is regardless the version of vCenter Server. The Avamar logs provide the actual progress of the backup.
- If the connection between vSphere Data Protection and vCenter Server is lost, you cannot start a vSphere Data Protection backup job. (272187)
Restart vSphere Data Protection.
- A backup verification job does not migrate the verification script parameters. (238608)
After migrating a backup verification job that contains the verification script parameters to an Avamar server, clicking More Options… on the Avamar Administrator > Policy Management > Edit virtual machine Backup Validation Group > Overview page does not display the verification script parameters of the migrated job.
- After migrating to vSphere Data Protection 6.1, you cannot restore the application data to the original location by clicking Reset. (240401)
- The backup jobs that do not have active clients do not migrate to vSphere Data Protection 6.1.1. (244970)
Migrating a backup job that has all MC_Retired clients (virtual machines) from vSphere Data Protection 6.1 or earlier to 6.1.1 fails because the clients are not active, that is, they are retired (deleted).
- If a virtual machine is deleted during a vSphere Data Protection restore operation, the virtual machine is not properly removed from the vSphere Data Protection inventory.
This causes an error when editing the backup jobs that included the deleted virtual machine as source.
Additionally, if a virtual machine is created with the same name, attempts to add the virtual machine to a backup job will fail. (35110)
As a best practice, avoid deleting virtual machines during restore operations. If this error does occur, create the virtual machine with a new name and add it to a new backup job.
- File Level Restore (FLR): "Error 10007: Miscellaneous error" is displayed for most of the FLR failures. (45699)
The "Error 10007: Miscellaneous error" message is displayed for most of the FLR failures.
In addition, FLR does not display any error message in cases where there is a restore failure due to the disk being full or a long file path.
Therefore, it is impossible to determine the root cause of the FLR failure.
- Deleted disks are skipped when restoring to original location. (53004)
If the target virtual machine no longer has the same disk footprint as the original virtual machine that was backed up (if the disks have been removed or deleted from the virtual machine), performing a "Restore to original location" operation, after selecting a restore point timestamp in the Restore pane, will silently fail to restore the missing disk of
the virtual machine.
Restore the disk to its original location after manually adding the missing disk to the virtual machine. Ensure the disk is the same size as it was when the virtual machine was backed up.
If this workaround fails, restore the disk to a new location to create a new virtual machine.
When the restore task completes, detach the restored disks from the new virtual machine and attach them to the required virtual machine using the information in "Detaching and Reattaching Storage" of the vSphere Data Protection Administration Guide.
- Canceling a restore operation does not delete the restored data on a virtual machine. (237125)
While performing a restore to a different virtual machine that is not the source virtual machine, if you cancel the operation, the
cancellation succeeds, but the already restored data that is part of the canceled restore is not deleted from the virtual machine.
- Restoring to the same source location on a virtual machine by selecting the Restore along with configuration option fails. (237015)
If the source virtual disks are removed on a virtual machine, and you restore the same virtual disks to the same source location on the virtual machine by selecting the Restore along with configuration option, the operation fails.
Perform the restore to an alternate location.
- You cannot restore an image backup to a new virtual machine if you have included physical Raw Device Mapping (RDM) disks in the backup. (267439)
If you back up a virtual machine that has both virtual disks and physical RDM disks, the backup successfully processes the virtual disks only.
You can restore the backed up data to only either the source virtual machine or redirect it to another (already existing) virtual machine.
Because the backup does not process the physical RDM disks, you cannot restore the data that is present on the physical RDM disks. So, you cannot restore an image backup to a new virtual machine.
- Replication of replicated clients under a particular tenant on the target server fails. (194669)
The replication of replicated clients from a source to a target server under a particular tenant account fails with the following error message:
Specified account ( ) does not fall within the current authorization domain.
In addition, the failure occurs with the following source/target combinations:
- Source server: vSphere Data Protection Advanced and Target Server:
vSphere Data Protection Advanced/Replication Target Identity (RTI)
- Source server: RTI and Target Server: RTI/vSphere Data
- Replication logs are filling up the root partition, and this creates a need to create a symlink to another partition. (195196)
The replication logs are currently going to the
/space partition and not to the
Manage the replication logs in the
/usr/local/Avamar/var/client directory (the space partition).
Operating System Issues
Microsoft Application Issues
- On Microsoft Exchange clients, there are many warning messages in the avagent log that print frequently and fill up the logs. (56723)
The Microsoft Exchange client is left registered with two vSphere Data Protection Advanced appliances on vCenter Server, which is causing this issue.
- You cannot back up the SharePoint Server databases if the database names contain unicode characters. (192449)
- You cannot perform GLR on an Exchange client if you install the GLR plug-in by using the repair option of the Exchange client installer. (238439)
You cannot perform GLR on an Exchange client if the GLR plug-in is not installed.
Even if you install the GLR plug-in by using the repair option of the Exchange client installer, you cannot perform GLR.
- Uninstall the Exchange client.
- Run the Exchange client installer.
- On the Feature selection page, select the GLR feature.
- Complete the installation.
- SharePoint virtual directories are not restored. (248324)
Performing a full backup of a web application does not back up the SharePoint virtual directories. So, if you delete the source web application and the SharePoint virtual directories, and restore the
backed up web application, the SharePoint virtual directories are not restored. You cannot open the sites that are under the web application.
- Back up the full image of virtual machine.
- To restore the required virtual directories, perform a File Level Restore of the backed up virtual machine image.
- On a Client Access Server (CAS) host that does not have a Mailbox (MBX) server role, EMC Avamar Exchange Backup User Configuration tool crashes while starting the VMwareVDPBackupuser services for an existing account. (249184)
Manually start the services.
- GLR to Exchange Server 2013 that has only the MBX role sometimes fails. (249522)
Before you perform GLR, ensure that you meet the following prerequisites:
- You have started the Backup Agent service by using the domain\VMwareVDPBackupUser account.
- You have removed the LAN setting proxy.
- You have restarted the mailbox servers, for which the restart is
- You have not mounted any RDB in the environment, and deleted the stale entries of RDBs.
- You have successfully created the MFCMAPI (32-bit) profile.
Despite meeting these prerequisites, sometimes GLR fails and displays the following similar error message:
2016-01-14 17:24:01 avmapi Error <0000>: Error 0x80040111 opening message store
2016-01-14 17:24:01 avmapi Error <13547>: Error MAPI_E_LOGON_FAILED. (code: 0X80040111), avmapi_misc::open_mapi_session avmapi_misc.cpp:1363
2016-01-14 17:24:01 avmapi Info <0000>: Logon failed for CAS: E13MBX3.MsApp-ExchBlrQa.com.
In this case, perform the following workaround:
- Install the latest MAPI CDO kit from Microsoft website.
- Enable the VMwareVDPBackupUser account.
To ensure that the account is enabled, log in to the VMwareVDPBackupUser account's mailbox and send a few emails.
- If the VMwareVDPBackupUser account is not enabled, run the following command:
Get-ExchangeServer | Add-ADPermission -User VMwareVDPBackupUser@domain.com -ExtendedRights Receive-As,Send-As
- If the Exchange Server uses the SSL certificate authentication, create the avmapi.cmd file in the ..\avp\var directory on the Exchange Server.
- Set the following flags in the avmapi.cmd file:
Despite performing this workaround, if GLR fails, perform GLR on the Exchange Server that has both the CAS role and the MBX role.
Automatic Backup Verification (ABV) Issues
- ABV: Verification job fails after renaming the datastore. (55790)
This error can occur if you rename or move the destination datastore outside of vSphere Data Protection.
Edit the verification job and select the renamed or moved destination datastore as the new destination. For instructions, refer to "Editing a Backup Verification Job" in the vSphere Data Protection Administration Guide.
- Improper error messages are reported if the Verification job failed because of connection issues due to Data Domain. (56619)
The backup cannot be restored and the Verification job fails because the
vSphere Data Protection
appliance cannot talk to the Data Domain.
It is expected for the Verification job to fail; however, the proper error message does not display and the user does not know the root of the failure.
- ABV does not start if the last backup is completed with an exception. (206091)
- If the vSphere Data Protection IPv6 address contains zero-valued octets, you can use only an internal proxy. To use an external proxy, the IPv6 address must contain non-zero-valued octets. (276747)
The following table lists the problems that have been fixed in this release of
vSphere Data Protection:
||When you perform an FLR, and you browse for a virtual machine, the vSphere Data Protection GUI displays a misleading error.
||A replication recovery job that runs on a target vSphere Data Protection appliance publishes the task by specifying the source server as unknown.
||Tivoli Java Collections Library is vulnerable that enables exploitation of port 7778 by running a command on a remote client.
|Fix common vulnerabilities and exposures (CVEs) that are found in third-party libraries by updating vSphere Data Protection appliance with Avamar OS rollup version Q4 2016.
|On vSphere Data Protection appliance, update the Java runtime binaries version to 8u121.
|Provide support for vCenter Server 6.0 U3.
|On vSphere Data Protection appliance, enable TLS 1.2.
|Fix the error, System accounting is not in use: System accounting not found in /etc/cron.d/sysstat.