vSphere Data Protection 5.8.4 Release Notes

vSphere Data Protection 5.8.4 Release Notes | 12 April, 2016

These release notes include the following topics:

Benefits and Features

Read about the benefits and features of this product at the following links:

Supported Environments

For information on supported environments, see VMware Interoperability Matrix.

Known Problems and Limitations

The following are the known problems and limitations in this release of vSphere Data Protection:

VMware Issues

  • Snapshot removal failed even though the "Create Snapshot" task returned a valid snapshot. (59450)

    Backups can sometimes fail with the "Snapshot Removal Failed" error. This is due to a VMware defect where the snapshot removal is denied by vCenter Server, even if the snapshot creation was successful.

    Workaround

    Manually remove the snapshot from the virtual machine by using the Snapshot Manager and then resubmit the backup job.

  • Image backup fails for powered-on virtual machine running on Virtual SAN datastore. (1281041)

    An image backup fails for powered-on virtual machines running on a Virtual SAN datastore, where both the vSphere Data Protection appliance and the virtual machine are running on the same Virtual SAN datastore, but are hosted and powered on by different vSphere hosts. The issue exists only when the virtual machine is in a Powered On state.

  • 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 by 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.

  • Users cannot run securely if running a non-default vCenter Server port. (1293852)

    This defect is a side effect of increased VDDK security to protect against OpenSSL man-in-the-middle attacks. If vCenter Server is not using the default web service port (443), and vSphere Data Protection is configured in such an environment, do not use the “Configuring Proxy Certificate Authentication” procedure in the vSphere Data Protection Administration Guide, as the result could be unfavorable.

    Workaround

    Use the default web service port (443) when configuring proxy authentication.

  • Running in secure mode results in users not able to clean up previous failed backups, in which artifacts are left behind. (1294581)

    Bugs 1293852 and 1294581 are related to enabling the secure mode. Currently in the vSphere Data Protection appliance UI, we recommend that if users want to secure their deployment, they should run with the SSL host verification enabled (which is disabled by default). Previously this option did not exist.

  • With 5.8, root login was disabled, as it is not a best practice. (1309755)

    An option is needed to enable ssh root login. Additionally, the shell is set to time out after 15 minutes, if no activity occurs in the shell. An option is needed to disable the shell timeout. These improvements will help with the customer support experience during troubleshooting and while using the shell.

    Workaround

    Log in by using the admin account. Then, use the sudo command to perform root functions.

    The bash shell (in the /etc/profile directory) is set for a 15-minute timeout if no activity occurs in the shell. You can add the console timeout value by using the hardening script. For example:

    TMOUT=900

    export TMOUT

  • The vApp > Import permission, which validates during vCenter Server registration, is missing from the vSphere Data Protection Administration Guide. (197864)

    The vApp > Import permission is not documented in the vSphere Data Protection Administration Guide. The vApp > Import permission is required during initial deployment, when vCenter Server is added or changed on the vSphere Data Protection Configure UI. Symptoms of the missing permission are as follows:

    • The appliance fails to add an external proxy and the following errors display: "Failed to find CIM service on VM image proxy" and "Failed to install a new VM image proxy."
    • No new proxy virtual machine is created in the vCenter Server inventory.
    • The appliance is unable to deploy an .ovf file from the VMware Web Client while logged in as a user that was used to register vCenter Server with the vSphere Data Protection appliance.

    Workaround

    Edit the role that has been customized to use with the vSphere Data Protection appliance and add the vApp > Import permission by using the information in the following VMware link:

    http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.hostclient.doc/GUID-6465FB18-7A57-40DB-B160-636DC2324A04.html

    When you edit a role, you can change the privileges selected for that role. When completed, these privileges are applied to any user or group assigned the edited role.

Documentation Issues

  • The following are late-breaking updates to the vSphere Data Protection Administration Guide 5.8. Please note the following corrections to the text: (198175)

    • The following limitation is documented on page 20 of the vSphere Data Protection Administration Guide:

      Backing up more than 2 TB VMs on Windows operating systems is not supported. This limitation does not exist on Linux operating systems.

      This limitation no longer exists.

    • The following versions of Avamar were added to Table 15.4 Replication Source Matrix on page 130 of the vSphere Data Protection Administration Guide:

      Backups created with this product... Can be replicated to these targets...
      Avamar SP2 (6.1.2.47) Avamar 7.0.0.427 Avamar SP1 7.0.1.56
      vSphere Data Protection 5.1.x N N N
      vSphere Data Protection 5.5.1.x Y Y Y
      vSphere Data Protection 5.5.5.x Y Y (Not Recommended) Y
      vSphere Data Protection Advanced 5.5.5.x Y Y (Not Recommended) Y
      vSphere Data Protection Advanced 5.5.5.x + DD Y Y (Not Recommended) Y (Not Recommended)
      vSphere Data Protection 5.5.6.x Y Y (Not Recommended) Y
      vSphere Data Protection Advanced 5.5.6.x Y Y (Not Recommended) Y (Not Recommended)
      vSphere Data Protection Advanced 5.5.6.x + DD Y (Not Recommended) Y (Not Recommended) Y (Not Recommended)
      vSphere Data Protection 5.8.x Y Y Y
      vSphere Data Protection Advanced 5.8.x Y Y Y
      vSphere Data Protection Advanced 5.8.x + DD Y (Not Recommended) Y (Not Recommended) Y
      RTI 5.8.x Y Y Y
      RTI 5.8.x + DD Y (Not Recommended) Y (Not Recommended) Y (Not Recommended)

  • VMware Proxy appliance are vulnerable to a man-in-the-middle-attack. (222547)

  • By default, proxies do not validate SSL certificates when connecting to vCenter Server. This can leave vCenter Server vulnerable to a man-in-the-middle exploitation, which might result in unauthorized access to vCenter Server. Configure each proxy to use an SSL certificate authentication when connecting to vCenter Server to correct this vulnerability.

    Because of bug 222547, the (Optional) Configuring Proxy Certificate Authentication topic on pages 69–70 in the vSphere Data Protection 5.8 Administration Guide requires an update. The following list summarizes the updates:

    • An additional step after step 3 on page 69 to run the following command: openssl x509 -in vcenter-1.crt -fingerprint | grep Finger.
    • A change to step 5 to add the following command: --ssl_server_cert_thumbprint="thumbprint"
    • The replacement of vcenter-1.crt with rui-ca-cert.pem in steps 5 and 9.
    • The addition of steps 11, 12, and 13 to edit /etc/vmware/config.

    The following procedure includes all required changes. Use this procedure instead of the one on pages 69-70:

    1. Open a command shell and log in to the proxy as root.
       
    2. Copy the vCenter Server certificate to /usr/local/avamarclient/bin on the proxy:
       
      • For a Linux vCenter Server:

        scp file /etc/vmware-vpx/ssl/rui.crt and /etc/vmware-vpx/ssl/rui-ca-cert.pem from vCenter Server into /usr/local/avamarclient/bin on the proxy
         
      • For a Windows vCenter Server:

        scp c:\ProgramData\VMware\VMware VirtualCenter\SSL\rui.crt and c:\ProgramData\VMware\VMware VirtualCenter\SSL\cacert.pem into /usr/local/avamarclient/bin on the proxy.  
      • NOTE: If a chained SSL certificate is used for vCenter Server, copy the chain.pem file, which contains all certificates in the chain, to /usr/local/avamarclient/bin on the proxy.

    3. Set the proper operating system permissions on the certificate by typing:

      chmod 600 /usr/local/avamarclient/bin/rui.crt

      where rui.crt is the actual certificate name.

    4. Run the following command against the rui.crt to capture the SSL cert thumbprint:

      openssl x509 -in rui.crt -fingerprint | grep Finger

      The output should look similar to the following:

      SHA1 Fingerprint=C7:35:19:95:9C:3F:56:1D:73:35:52:41:F3:02:46:A3:B9:46:4F:D9

    5. Open /usr/local/avamarclient/var/avvcbimageAll.cmd in a UNIX text editor.
       
    6. Append the following entries to the end of the file:

      --ssl_server_cert_thumbprint="thumbprint of rui.crt"
      --ssl_server_authentication_file=/usr/local/avamarclient/bin/rui-ca-cert.pem

      where rui.crt is the actual certificate name and thumbprint is the actual thumbprint for vCenter Server. The output should look similar to the following:

      --ssl_server_cert_thumbprint=”C7:35:19:95:9C:3F:56:1D:73:35:52:41:F3:02:46:A3:B9:46:4F:D9”

      NOTE: Use chain.pem for the chained vCenter Server SSL certificates.

    7. Save your changes and close avvcbimageAll.cmd.
       
    8. Open /usr/local/avamarclient/var/avvmwfileAll.cmd in a UNIX text editor.
       
    9. Append the following entry to the end of the file:

      --ssl_server_authentication_file=/usr/local/avamarclient/bin/rui-ca-cert.pem

      where rui-ca-cert.pem is the actual certificate name.

      NOTE: Use chain.pem for the chained vCenter Server SSL certificates.

    10. Save your changes and close avvmwfileAll.cmd.
       
    11. Open /etc/vmware/config in a UNIX text editor.
       
    12. Append the following lines to the end of the file:

      vix.enableSslCertificateCheck = "true"

      vix.sslCertificateFile = "/usr/local/avamarclient/bin/rui-ca-cert.pem"

    13. Save your changes and close /etc/vmware/config.
       
    14. Open /usr/local/avamarclient/var/vddkconfig.ini in a UNIX text editor.
       
    15. Find the vixDiskLib.linuxSSL.verifyCertificates=0 entry.
       
    16. Change the vixDiskLib.linuxSSL.verifyCertificates=0 entry to 1:

      vixDiskLib.linuxSSL.verifyCertificates=1
       
    17. Save your changes and close vddkconfig.ini.
       
    18. Ensure that no backup or restore jobs are running on this proxy.
       
    19. Restart the avagent and vmwareflr services by typing the following commands:

      service avagent-vmware restart
      service vmwareflr restart
       
  • Installing SSL Certificates from vCenter Server Appliance. (225859)

    To install the default SSL certificate, which is used on vCenter Server Appliance to the vSphere Data Protection appliance, use the following procedure.

    The first requirement is to create a single PEM file which contains the vCenter Server Appliance cert and the vCenter Server Appliance CA cert.

    1. Use SSH or Putty to log in to the vCenter Server Appliance as the root user:

      ssh root@vcsa

    2. Navigate to the /etc/vmware-vpx/ssl directory:

      cd /etc/vmware-vpx/ssl

    3. Concatenate the default vCenter Server Appliance cert (rui.crt) and the vCenter Server Appliance CA cert (rui-ca-cert.pem) into a single file named chain.pem:

      cat rui.crt rui-ca-cert.pem > /tmp/chain.pem

    4. Copy the chain.pem file to the vSphere Data Protection appliance and place it in the /usr/local/avamarclient/bin directory:

      scp /tmp/chain.pem root@:/usr/local/avamarclient/bin

    5. For the next steps, you will need to SSH or Putty in to the vSphere Data Protection appliance and switch to the root user:

      ssh admin@VDP
      su - root

      Provide proper credentials for both accounts.

    6. Set the proper operating system permissions on the certificate by typing:

      chmod 600 /usr/local/avamarclient/bin/chain.pem

    7. Navigate to the /usr/local/avamarclient/var directory:

      cd /usr/local/avamarclient/var

    8. Before modifying the next file, determine the thumbprint of the SSL certificate:

      openssl x509 -in /usr/local/avamarclient/bin/chain.pem -fingerprint –noout

      The output should look similar to:

      SHA1Fingerprint=76:D9:44:E0:5C:6B:32:A1:B3:B8:81:15:93:37:07:5A:8D:A4:AD:EE

    9. Open avvcbimageAll.cmd in a UNIX text editor:

      vi avvcbimageAll.cmd

    10. Append the following entry to the end of the file:

      --ssl_server_authentication_file=/usr/local/avamarclient/bin/chain.pem

    11. To append the SSL thumbprint in the file, append the following entry to the end of the file:

      --ssl_server_cert_thumbprint="thumbprint"

      where thumbprint is the SHA1 Fingerprint value from step 8.

      The entry will look similar to:

      ssl_server_cert_thumbprint="76:D9:44:E0:5C:6B:32:A1:B3:B8:81:15:93:37:07:5A:8D:A4:AD:EE"

    12. Close /usr/local/avamarclient/var/avvcbimageAll.cmd and save your changes.
       
    13. Open /usr/local/avamarclient/var/avvmwfileAll.cmd in a UNIX text editor:

      vi avvmwfileAll.cmd

    14. Append the following entry to the end of the file:

      --ssl_server_authentication_file=/usr/local/avamarclient/bin/chain.pem

    15. Close /usr/local/avamarclient/var/avvmwfileAll.cmd and save your change.
       
    16. Open /etc/vmware/config in a UNIX text editor:

      vi /etc/vmware/config

    17. Append the following lines to the end of the file:

      vix.enableSslCertificateCheck = "true"
      vix.sslCertificateFile = "/usr/local/avamarclient/bin/chain.pem"

    18. Close /etc/vmware/config and save your changes.
       
    19. Open /usr/local/avamarclient/var/vddkconfig.ini in a UNIX text editor:

      vi vddkconfig.ini

    20. Locate the vixDiskLib.linuxSSL.verifyCertificates=0 entry.
       
    21. Modify the vixDiskLib.linuxSSL.verifyCertificates=0 entry to 1.

      The modified value should look like: vixDiskLib.linuxSSL.verifyCertificates=1

    22. Close /usr/local/avamarclient/var/vddkconfig.ini and save your changes.
       
    23. Ensure that no backup or restore jobs are running on the system:

      mccli activity show --active

    24. If there are no jobs running, restart the avagent and vmwareflr services by typing the following commands:

      service avagent-vmware restart
      service vmwareflr restart

Interoperability Issues

  • In a Virtual SAN environment, the image-level restore to original location operation is allowed, but the disk-level restore to original location operation is grayed out, after migrating the entire virtual machine to another datastore. (58839)

    Workaround

    Either restore the entire VM with an image-level backup or restore the disk level backup as a new disk on the original VM.
     

  • Failed to import vSphere Data Protection disks stored in the Virtual SAN datastore. (60306)

    In a Virtual SAN environment, VMware creates two folders in the vsanDatastore for each VM. One is named after the virtual machine's name and the other is named after the virtual machine's UUID. All the VM files are saved in the UUID folder. In the VM name folder, symbolic links point to the files in the UUID folder. A failure occurs when you try to import vSphere Data Protection disks from an old appliance by using the symbolic links in the VM name folder.

    Workaround

    Storage vMotion the disks out of the Virtual SAN datastore to a regular datastore.

Installation Issues

  • During vSphere Data Protection installation, if you click Previous on the vCenter Server registration page but do not enter any values, the system fails to register with vCenter Server and the installation fails. (52385)

    Workaround

    Re-install vSphere Data Protection by using the instructions in the "VDP Installation and Configuration" chapter of the vSphere Data Protection Administration Guide.

Upgrade Issues

  • Upgrading the vSphere Data Protection appliance from either 5.5.10 or 5.8.2 to 5.8.3 fails. (244133)

    Upgrading the vSphere Data Protection appliance from either 5.5.10 or 5.8.2 to 5.8.3 fails because vSphere Data Protection proxy RPM installation has failed because of timeout.

    Workaround

    Before you upgrade the vSphere Data Protection appliance, upgrade the vSphere Data Protection appliance kernel.

    Perform the following steps to upgrade the vSphere Data Protection appliance kernel:

    1. From the vSphere Data Protection 5.8.3 installation package on the vSphere Data Protection appliance that you want to upgrade, copy the VDP_KernelUpgrade.tar.gz file to any directory, for example, /root on the same vSphere Data Protection appliance.
    2. Extract the VDP_KernelUpgrade.tar.gz file by running the following command:

      tar -zxvf VDP_KernelUpgrade.tar.gz

    3. Add the execute permissions to the VDPHotfix_KernelUpgrade.sh file by running the following command:

      chmod a+x VDPHotfix_KernelUpgrade.sh

    4. Run the VDPHotfix_KernelUpgrade.sh file:

      ./VDPHotfix_KernelUpgrade.sh

      The vSphere Data Protection appliance restarts.

      The kernel is upgraded to 2.6.32.59-0.19.1.8590.0.PTF-default #1 SMP 2015-05-28 13:06:16 +0200 x86_64 x86_64 x86_64.

    5. Upgrade the vSphere Data Protection appliance by using the vSphere Data Protection 5.8.3.13 ISO image.

VMDK Issues

  • Incorrect behavior of the vSphere Data Protection Advanced appliance when more disks are added to the same SCSI slots. (59774)

    The vSphere Data Protection Advanced appliance initiates a restore operation with the same SCSI IDs on the same existing VM 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 you that only the first single disk was added, and the second disk simply replaced the first disk.
     

  • Restoring individual VMDKs to multiple virtual machines results in VMDK restore for only one of the virtual machines. (194209)

    When restoring individual VMDKs to multiple VMs, the restore only completes for one VM. Restores for the other VMs do not get initiated. This issue does not occur when restoring the VMDK to its original location.

    Workaround

    Do not restore individual VMDKs to multiple virtual machines. Submit another restore job of VMDKs for a single virtual machine at a time.

vSphere Data Protection Issues

  • If a thin provisioned vSphere Data Protection reaches datastore capacity, then even after freeing up the datastore and creating more space, integrity check errors occur on vSphere Data Protection. (41005)
     
  • The vSphere Data Protection appliance disconnects and, in many cases, unexpected errors occur. (49566)

    Users may occasionally receive the following error message: "An unexpected connection error occurred and the cause could not be determined. Please check your VDP Configuration screen to troubleshoot, or contact an administrator." This is a generic error message and may display for any unexpected error.

    NOTE: The message more frequently appears in case of vCenter Server 5.5.x (including version 5.5u1b).

    Workaround

    Cancel the error message and perform the task. If the failure persists, contact Technical Support.
     

  • vCenter Server events do not generate during initial configuration if you modify the vSphere Data Protection hostname or IP address. (52677)

    Workaround

    Monitor the reconfiguration events on the vSphere Data Protection appliance console.
     

  • Unable to log in to the vSphere Data Protection configuration utility after the first reboot. (56351)

    There are intermittent instances where you cannot log in to the vSphere Data Protection configuration utility after the deploy-reboot cycle. No error is shown in the vdr-configure log. Clearing the browser cache and trying to log in with different browsers does not fix the problem.

    Workaround

    By using a console connection, log into the vSphere Data Protection virtual appliance and use the following commands to manually start and stop the vSphere Data Protection configuration utility services:

    emwebapp.sh --restart
     

  • The vSphere Data Protection appliance crashes and powers off when a thin-provisioned virtual machine is restored on a datastore with insufficient space. (56386)

    The appliance crashes because the disk that has been hot-added to the appliance has insufficient space, so placing the appliance on a different datastore would not fix the problem.

    As a best practice, before performing an ABV or restore task, check the free space availability on the datastore to ensure there is sufficient space.
     

  • Import Disk: The Initial Configuration wizard always allocates the default of 4 vCPUs and 4 GB RAM. (56534)

    Irrespective of imported capacity, which for vSphere Data Protection Advanced can be 2 TB, 4 TB, 6 TB, or 8 TB, by default, the wizard always allocates only 4 vCPU and 4 GB RAM. The import operation completes successfully, the vSphere Data Protection Advanced appliance is up and running, which could cause issues later in terms of being under-provisioned for memory. The expected behavior is the Initial Configuration wizard should set the default to the minimum Memory based on the capacity being imported, as it does when performing a fresh installation of vSphere Data Protection Advanced.

    Adjust the amount of allocated memory based on the information below. The minimum amount of memory per VM depends on the capacity.

    • 2 TB capacity--6 GB memory
    • 4 TB capacity--8 GB memory
    • 6 TB capacity--10 GB memory
    • 8 TB capacity--12 GB memory
       
  • Backups, restores to original location, and restores to new location operations work as expected on datastores with Chinese names. However, if a target virtual machine is on that datastore as a new disk, the restore to new location operation fails on datastores with Chinese names. (56877)

    This is a known image proxy issue, which will be fixed in a future release.
     

  • 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 configuration utility 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.

    Workaround

    Perform the following steps:

    1. Wait till all the backups and tasks on the vSphere Data Protection appliance complete and then change the password.
       
    2. Restart the vSphere Data Protection appliance in the maintenance window, and then log into the vSphere Data Protection configuration utility and change the vCenter Server password.
       

  • The Performance Assessment Test (PAT) result changes to Never Run when the datastore name is changed. (59784)

    In this scenario, you open the vSphere Data Protection configuration utility, click the Storage tab, select a datastore, and select Run performance analysis on storage configuration. The performance analysis test completes successfully and the results of the performance analysis are displayed correctly. If you change the name of the datastore, the performance analysis results erroneously indicate the status as Never Run.
     

  • The vSphere Data Protection appliance disconnects automatically while selecting any option in the vSphere Web Client. (61093)

    If you select the  Event or Task options on the vSphere Web Client, and attempt to return to the vSphere Data Protection UI, the connection is lost. You must manually connect to the vSphere Data Protection appliance.
     

  • Reports: Refresh does not clear the filter options. (186142)

    You can click the Refresh button at any time to update the data. Clicking the Refresh button updates the table with new rows but does not clear the filter options.

    This defect occurs on the Reports tab only.

    Workaround (p>Manually clear the filter options.
     

  • Timed-out tasks for the vSphere Data Protection Advanced appliance should be reported in the Recent Tasks pane or Error Logs. (194115)

    This is a generic bug to cover all the time out scenarios for various types of tasks, including replication, backup, verification, restore, and replication recovery, that the vSphere Data Protection Advanced appliance performs. The timed-out tasks could be due to no proxy or agent available to perform the given tasks. It is expected that the various timed-out tasks, failure logs, or the reason for the failure should be reported in the Recent Tasks pane or the Events log, but they are not.

    These are known issues that will be fixed in a future release.
     

  • Reports: Rerun failed job runs all the clients in the backup job. (195252)

    If there is only one client failure in the backup job, when Rerun is triggered from the Reports > Actions-Rerun action, the system runs the backup of all the clients in the backup job. The system should rerun the backup only for failed clients.

    Workaround

    To re-run only failed clients, select Backup only out of date source under Backup Now to run all failed clients from the Backup tab.
     

  • Delay in the availability of the vSphere Data Protection appliance in the Web Client following an upgrade from 2013 R2 U1. (196727)

    There is more than a one-hour delay in the availability of the vSphere Data Protection appliance on the vCenter Server Web Client home page (in the plug-in drop-down menu). (The appliance deploys to vCenter Server in seconds; however, it does not display in the Web Client at the same time).

    This is an issue with the VMware vSphere plug-in update, and not with the vSphere Data Protection appliance upgrade.

Backup Issues

  • If a large backup job is created (~100 VMs), the backup job can take up to ten minutes to create. (39456)

  •  

  • No proper error handling when running scheduled disk backup job of a VMDK which was migrated to another datastore. (53880)

    A scheduled backup job of a VMDK completes without any errors but when the datastore location is changed to another datastore, the error occurs.
     

  • Loading clients takes a significant amount of time when editing or cloning a backup job. (60249)

    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.
     

  • VM backup failed with miscellaneous error 10007: Failed to download VM metadata. (197100)

    To determine the cause of the miscellaneous error:

    1. Navigate to the Reports tab of the vSphere Data Protection appliance.
    2. Click the View Log link to view details for the failed backup job.

    NOTE: To verify virtual machine errors or errors with the virtual machine's metadata, you can browse the VM datastore. The backup job might have failed because the appliance is looking for a .vmx file inside an incorrect VM folder.

    Workaround

    1. Consolidate the VM files into a single VM folder

    2.   or
    3. Keep the VM files in a different VM folder in separate datastores, and then migrate them to different datastores (if the virtual machines are in the same datastore).
    4. Rerun the backup job.

  • The vSphere Data Protection backup fails and displays the error code 31037 in the GUI. The error code indicates that the selected disks for the backup are invalid. (Escalation 24278)

    Workaround

    1. Deploy the VM from template and rename it according to the convention of your site.
    2. By using the migration wizard, migrate the deployed VM to another datastore. The VM name and the VMDK name synchronize.
    3. Either configure or reconfigure the backup for the migrated VM with the changed name.

Restore Issues

  • 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)

    Workaround

    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.
     

  • Clean up is required for canceled restore operations. (46162)

    When you start a restore operation on a virtual machine and then cancel the restore operation before it completes, the new virtual machine, which is created on vCenter Server, is not cleaned up. The current implementation removes the snapshot of the virtual machine but does not remove the newly-created or newly-registered virtual machine.

    This is by design.
     

  • Deleted disks are skipped when restoring to original location. (53004)

    If the target VM no longer has the same disk footprint as the original VM that was backed up (if the disks have been removed or deleted from the VM), 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 VM.

    Workaround

    Restore the disk to its original location after manually adding the missing disk to the VM. Ensure the disk is the same size as it was when the VM was backed up. If this workaround fails, restore the disk to a new location to create a new VM. When the restore task completes, detach the restored disks from the new VM and attach them to the required VM by using the information in "Detaching and Reattaching Storage" of the vSphere Data Protection Administration Guide.
     

  • Restore fails when attempted to restore as new VM by using previous name of the renamed VM. (53712)

    When you create a backup job for a VM, select the restore point, and type the old name of the renamed VM in the Restore to New Location field, the restore fails with the following message: Unable to restore VM for restore point. The datastore path already exists
     

  • File Level Restore (FLR): Need proper error message for failure to load EXT4 partition tree with internal proxy. (191574)

    FLR browsing of an EXT4 partition with an internal proxy is not supported. If you perform this task, no proper error is prompted.
     

  • Restore fails or is aborted when the availability group database name contains a Unicode character. (193319)

    The availability group's database name cannot contain Unicode characters (for example, an apostrophe). The database is unable to join to the specified availability group and the Restore operation fails or aborts with an incorrect syntax error.

    Workarounds

    1. Preventive workaround: Do not include Unicode characters when you name your SQL database.
       
    2. If the error does occur, remove the database from the availability group and perform a full backup. Make sure all the data is backed up, and then perform a redirected restore from the availability group client to the SQL client.
       

  • Restore backup of secondary replica failed or aborted with log gap error. (197652)

    When restoring an incremental backup of a secondary replica, the restore returned a failed / aborted status and the log indicates the log gap error, though the database has no log gap. Note that this issue has not been observed in restoring a backup of a primary replica.

    The issue is AlwaysOn nodes synchronization-related and occurs during the creation of SQL metadata file in the backup workflow, in cases where the backup is taken on a secondary AlwaysOn replica.

    This issue results in backups with a corrupted metadata file, so users could not perform a Log tail recovery or some additional differential / incremental backup could not be linked to this backup chain.

    There is no data loss.

    Workaround

    Perform a full backup. Ensure the "Force incremental backup after full backup" backup option is unchecked.
     

  • File Level Restore (FLR): Error observed as 'Failed to get disks: Unable to browse as proxies are unavailable'. (197462)

    When performing an FLR operation, if the following error message is shown while browsing the file system:

    Failed to get disks: Unable to browse as proxies are unavailable

    Please logout, log back in, and try again.

    If the failure persists, contact Technical Support.

Replication Issues

  • Failed Replication task with expired or changed destination credentials should display an appropriate error. (60924)

    For a replication job failure with expired or changed user login credentials and / or password, the vSphere Data Protection Advanced appliance does not display a correct error related to user login credentials. Rather, the appliance reports the error as follows:

    The following jobs could not be initiated: <Replication Job Name>. Please check the vCenter events screen for more details.

    Destination "<target server IP/ Hostname>" of Replication Job "<Replication Job Name>" is not available. The replication destination is not accessible, you have insufficient privileges to login, a user account does not exist for the specified user, or the user name and/or password were mistyped.

    This is a known issue that will be fixed in a future release.
     

  • Replicated workorder on the source vSphere Data Protection Advanced appliance gets queued up intermittently. (187198)

    On a vSphere Data Protection Advanced appliance with imported disks, the first time an ad-hoc replication job is triggered, the replication client is placed in a disabled state. This causes the replication to become queued. The job waits until the replication client is re-enabled or the job times out.

    Workaround

    Disable the replication client and then re-enable it. If the replication client is already disabled, simply re-enable the client.

    As an Admin user, use the following commands to disable and re-enable the replication client:

    To locate the replication client, use the following command:

    mccli client show --recursive=true --domain=/MC_SYSTEM

    To disable and re-enable the replication client, replace with the client name retrieved in the previous command:

    mccli client edit --name=/MC_SYSTEM/ --enabled=false

    mccli client edit --name=/MC_SYSTEM/ --enabled=true

    NOTE: If the client is already disabled, only the second command is necessary to re-enable the client.
     

  • Replication Recovery: Recovery logs should be identified separately from ad-hoc replication logs. (190490

    Recovery logs and ad-hoc replication log items are distinguished by workorder IDs (WIDs), which are unique identifiers for virtual machines or clients that have been recovered or replicated. When you perform replication and recovery on the same vSphere Data Protection Advanced server, the logs-bundler collects logs for both actions under the /REPLICATE/Server_logs directory. The appliance cannot segregate recovery logs from ad-hoc replication logs and this creates a burden to you when attempting to identify and debug logs.
     

  • Multi-Tenancy: Replication source server information should be provided on the Recover wizard. (191699)

    When either the same virtual machine or a virtual machine with the same name is replicated from two different source servers under the same tenant node by using the same user account, the Clients and Backups page on the Recover wizard displays the virtual machine from the source server, as shown in the following multi-tenancy hierarchy:

    /VDP Advanced-Target
    /Replicate
     -Tenant
      -VDP Advanced-Source 1
        -VCSA
         -VM
           -Client 1
      -VDP Advanced-Source 2
       -VCSA
        -VM
         -Client 1

    During the recovery action, the Clients and Backups page displays Client 1 from Source 1 and Source 2 with the respective backups. However, other than the date and time stamp, you cannot distinguish between the two clients with the same name and suffix.
     

  • Replication job erroneously displays a status of 'failed' rather than 'cancelled'. (192936)

    On a vSphere Data Protection Advanced appliance, even when the replication job is cancelled, the job continues to run for some time and eventually the job fails instead of cancels.

    The cancellation request does not reach the source, so the replication tasks keep running on both the replication source (the parent) and the replication target (the child), even when the job is cancelled.

    This is a known issue that will be fixed in a future release.
     

  • 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 Protection Advanced
       

  • Replication Recovery: Replication logs are filling up the root partition - need to create a symlink to another partition. (195196)

    The replication logs are currently going to the /space partition and not to the root partition.

    Workaround

    Manage the replication logs in the /usr/local/Avamar/var/client directory (the space partition).
     

  • Replication recovery: The Recover wizard's authentication mechanism does not terminate the authentication process properly. (195235)

    While in the Recover wizard, when the user navigates to the Restore tab and clicks Recover replicated backups, the Destination dialog box displays. If you modify the port number by changing the value in the Port field, and then click Verify Authentication, an info message appears and you must click Cancel to manually terminate the authentication process.

    This is a known issue that will be fixed in a future release.
     

  • Replication recovery: Action logs are not collected under the log bundler of the source vSphere Data Protection appliance. (195548)

    Recovery logs that are created under a local host source server are not collected by the log collector.

    This is a known issue that will be fixed in a future release.
     

  • Replication succeeds when there are no restore points. (196573)

    Replication jobs run and complete successfully, even after the restore points have been deleted. The replication job, however, does not replicate the backups. The expected behavior is the job should fail as there are no restore points to replicate.

    This is a known issue that will be fixed in a future release.
     

  • After a checkpoint recovery from a Data Domain system, the vSphere Data Protection appliance cannot run a replication operation. (197306)

    Workaround

    To manually run the replication operation, perform the following steps from the command line on the vSphere Data Protection Advanced 5.8 appliance:

    1. Enter the following commands:

      service avagent-replicate stop

      service avagent-replicate unregister 127.0.0.1 /MC_SYSTEM

      root@lava92239:/usr/local/avamar/var/client/#: ls -ltr
      total 192
      lrwxrwxrwx 1 root root    29 Jul 30 10:03 avamar.cmd -> /data01/avamar/var/avamar.cmd
      -rw------- 1 root root    74 Aug 1 14:24 cid.bin
       

    2. Compare the CID MCGUI to MCDB.
       

    3. Enter the following command:

      rm -rf cid.bin
       

    4. On the MCGUI, navigate to Clients > MC_system > edit. Uncheck the Activated checkbox.
       

    5. Enter the following commands:

      service avagent-replicate register 127.0.0.1 /MC_SYSTEM

      service avagent-replicate restart - should have the checkbox activated now.
       

    6. Observe the time and CID for the avagent replicate on the MCGUI.
       

    7. Now, the replication operation should work for both vSphere Data Protection and Data Domain system backups.

Operating System Issues

  • Granular Level Restore (GLR) of any Microsoft application fails on Windows Server 2008 R2 (243196)

    Workaround

    Install the Windows update 3033929 from the following location:

    https://technet.microsoft.com/en-us/library/security/3033929

    https://support.microsoft.com/en-us/kb/3033929 provides information about the Windows update 3033929.

    Note: GLR can fail on Windows Server 2008 because of the ELDOS driver update issue. In this case, contact EMC technical support professional for a private binary that is packaged with the latest ELDOS driver.

Microsoft Application (MS App) Issues

  • When you restore a full backup of a web application, SharePoint virtual directories are not restored. (248324)
  • Microsoft SharePoint redirected restore job fails for the database if the IP address is used as an alias instead of the server name. (56344)

    Backing up to the original location with the overwrite option works correctly. The backup fails only when running a redirected restore when the IP address is used instead of the server name.

    Workaround

    Use the server name when creating an alias.
     

  • A Microsoft SharePoint redirected restore job displays as successful, even when some databases fail to restore. (56382)

    When restoring many databases or an entire SharePoint farm, some problematic databases may fail. Even though some of the databases fail, the restore job reports that the job is successful. This could result in lost data. The database backup fails only when running a redirected restore when the IP address is used instead of the server name when creating an SQL alias.

    Workaround

    Use the server name when creating an alias.
     

  • Out-of-date sources for a failed or cancelled Application database backup displays incorrect count. (56503)

    The difference between the sources count and the out-of-date sources count is common for Microsoft SQL and Exchange application database backups.
     

  • 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.
     

  • Upgrade 2014: The Backup Agent user is reset to Local System after upgrading the Microsoft Exchange client plug-in. (191795)

    When upgrading the Microsoft Exchange client plug-in from the previous version of the vSphere Data Protection Advanced appliance to the current vSphere Data Protection Advanced appliance, the backup agent service logon user is reset to Local System, rather than Backup User.

    From vSphere Data Protection 5.5.6 to 5.8, the system resets the credentials to local system credentials without asking for permission, causing the backup job to fail

    Workaround

    To edit the Microsoft Exchange backup job or to create a new Microsoft Exchange backup job, you must manually configure the backup agent service. To do this, you must enter the username and password by using the Backup User Configuration Utility.
     

  • On Microsoft Exchange clients, the system times out and the browse capability fails. (193074)

    The Microsoft Exchange client cannot browse the databases in the backup job wizard and you are prompted for credentials, even though the services are already running under a valid user account. This is an MSFT timeout issue.

    Workaround

    Wait several minutes and refresh the system, or restart the vSphere Data Protection services on the client.
     

  • Lower-version SQL client configurations are not supported in higher-level vSphere versions. (195342)

    When a lower version of an SQL client is installed on a higher version of a vSphere Data Protection Advanced appliance, you cannot see or browse the client in the vSphere Web Client. Lower version clients are not supported in the vSphere Data Protection Advanced appliance.

    This is a known issue. Because the lower-level SQL clients are not intended to be supported, the issue will be documented in the Troubleshooting section of the vSphere Data Protection Administration Guide.

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.

    Workaround

    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.
     

  • ABV: Verification job fails to initiate when destination path for host is changed. (55795)

    Workaround

    Edit the verification job and select the appropriate destination path when you perform the verification job.
     

  • ABV: An on-demand verification job is not initiated if the last backup was not successful. (55807)

    The following error is observed on an ABV job if the last backup was not successful:

    Error: "Unexpected error with NO error code, refer to logs."

    You are not made aware of the problem and the logs do not contain useful information.
     

  • 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 you do not know the root of the failure.

Granular Level Recovery (GLR) Issues

  • When you perform a GLR on a Microsoft Exchange Server, the destination mailbox field should be optional. (56439)

    When you perform restore to a single mailbox, the default value is to restore to the original location. The user interface does not allow an empty value for this field. If you select Restore to alternate location, every mailbox from that backup is restored to a single mailbox.

    Restoring a mailbox to its original location and restoring the original path to a different client is supported and working as designed. The inability to restore multiple mailboxes to their original locations is a known issue.

  • A GLR on the Microsoft Exchange Server 2013 fails and displays the "The callee (server [not server application]) is not available and disappeared; all connections are invalid." error. (248221)

Data Domain Issues

  • Error message needs correcting when adding a Data Domain system to the vSphere Data Protection appliance when the time is not in synch. (192821)

    The following error message displays when the Data Domain system time and the vSphere Data Protection appliance time are not synchronized:

    Unable to add trap host to Data Domain system

Proxy Issues

  • You must be prompted not to deploy an external proxy during a backup job. (193143)

    You are not warned against deploying an external proxy while a backup is in progress. If an external proxy is deployed during a backup, the deployment continues but the process automatically disables the internal proxy. This could cause currently-running backups to fail or the backup session could end unexpectedly.

    NOTE: If you try to deploy an internal proxy, the currently-running backup job is canceled.
     

  • During a vSphere Data Protection or external proxy configuration, the vSphere Data Protection appliance fails to resolve by using the secondary Domain Name System (DNS) service. (195132)

    Typically, when you have configured the primary and secondary DNS services, all the entries are duplicated on both the primary and secondary side, and when the primary DNS fails to respond, the lookup commands return the proper information from the secondary DNS.

    When you install the product and try to configure the product by using the vSphere Data Protection configuration utility by providing the primary and secondary details, since the primary DNS is not reachable, the lookup fails. The expected behavior is the appliance resolves the configuration by using the secondary DNS but this is not happening.

    Workaround

    Provide secondary DNS information when prompted for the primary DNS information.
     

  • External proxy: The internal proxy is enabled after rolling back to a previous checkpoint. (196272)

    The configuration can consist of external or internal proxies; a combination is not allowed.

    If a vSphere Data Protection Advanced appliance is rolled back to a previous checkpoint, internal proxies are enabled and external proxies are still enabled, but in a degraded state.

Fixed Problems

The following table lists the problems that have been fixed in this release of vSphere Data Protection:

Defect Number Description
246842 Create vSphere Data Protection 6.1.2 version (OS Rollup – Openssh and Openssl)
246849 The vSphere Data Protection email report shows wrong status about the DDVE Boost license
233385 An ABV job details report never appear under the completion column in the vSphere Data Protection plug-in though the ABV job succeeded
247377 Disk expansion fails if number of VMDKs does not match mapping
248596 vSphere Data Protection server is making many unnecessary DNS Lookups to Data Domain system
237352 The size of a user mailbox does not appear during GLR restore
247481 Minimum disk space requirement for upgrades must be corrected
252554 The vSphere Data Protection link on the web client does not list the vSphere Data Protection appliances that are deployed on a particular vCenter Server
252275 vSphere Data Protection exposed to CVE-2015-7547 vulnerability