REDCENTRIC VSPHERE AGENT VERSION

REDCENTRIC VSPHERE AGENT VERSION 7.36.5686 RELEASE NOTES, MAY 17, 2016

vsphere Agent Version 7.36.5686 Release Notes, May 17, 2016 Contents 1 OVERVIEW 1.1 Release History 1.2 Supported Platforms/VMware Infrastructure 1.3 Supported File Systems for File and Folder Recovery 2 NEW FEATURES 2.1 New Feature in Version 7.34 2.2 New Features in Version 7.3 3 INSTALLATION NOTES 3.1 Installation Requirements 3.2 Conditional Requirements 3.3 Licensing Requirements 3.4 Install/Upgrade 4 FIXES and KNOWN ISSUES 4.1 Fixes 4.2 Known Issues 5 PRODUCT SUPPORT 5.1 Technical Support 5.2 Product Updates 5.3 Documentation 1 OVERVIEW This document contains release notes for vsphere Agent 7.36. The Agent provides recovery protection for VMware vsphere environments. A single vsphere Agent can back up VMs across all hosts managed by a vcenter Server. You can back up your VMs to a secure, remote vault, and restore VMs, VMDKs, or specific files and folders. The Agent is pre-installed in a VM and provided in OVA format. vsphere Agent 7.36 is for use in combination with: - Portal 7.50 or later - Web CentralControl version 7.50 or later - Windows CentralControl version 7.30 or later For VM and VMDK restores, you can use Director version 6.22 or later. To ensure successful backups and restores in N:1 replicated environments, the Director must be version 6.31 or later (or version 6.22 with a hotfix obtained from your service provider). For granular file and folder restores, Director 7.00 or later is required. Files and folders can be restored from safesets that were created using vsphere Agent version 6.90 or later and version 6.x vaults, but only after both the Agent and Director are upgraded to version 7.00 or later. 1.1 Release History

Version 7.36.5686, May 17, 2016 Version 7.35.5683, November 24, 2015 Version 7.34.5682, July 6, 2015 Version 7.33.5680, November 4, 2014 Version 7.32.5669, May 8, 2014 Version 7.31.5663, April 8, 2014 Version 7.30.5661, March 27, 2014 1.2 Supported Platforms/VMware Infrastructure vsphere ESXi Hosts: - ESXi 6.0 (Update 1b to Update 2) - ESXi 5.5 (up to Update 3b) - ESXi 5.1 (up to Update 3) vsphere vcenter Servers: - vcenter Server 6.0 (up to Update 2) - vcenter Server 6.0 Linux Appliance (up to Update 2) - vcenter Server 5.5 (up to Update 3d) - vcenter Server 5.5 Linux Appliance (up to Update 3d) - vcenter Server 5.1 (up to Update 3b) - vcenter Server 5.1 Linux Appliance (up to Update 3b) Raw Device Mappings: The vsphere Agent backs up both VMDKs and virtual disks which use "virtual" Raw Device Mapping (vrdm). Data backed up from a vrdm is restored as a VMDK. See VMware documentation for instructions on how to migrate a restored VMDK back to a vrdm. Note: The vsphere Agent skips any physical Raw Device Mapping (prdm) when backing up VMs, because VMware does not allow them to be included in the snapshots used for VM-level backups. To back up this data, you must install an Agent within the VM and use it to back up the data that resides on the prdm(s). 1.3 Supported File Systems for File and Folder Recovery For file and folder recovery, the vsphere Agent currently supports the following file systems. Windows: - NTFS - FAT - FAT32 - Dynamic disks (Limited support. For more information, see the vsphere Agent User Guide.) Note: GPT partitions are not supported for file and folder recovery. Linux: - ext3 - ext4 Note: For more information about disk types and file systems that are not supported for granular restores, see the vsphere Agent user guide.

2 NEW FEATURES 2.1 New Feature in Version 7.34 - vsphere features that were supported on vsphere vcenter 5.5 are now supported on vsphere version 6.0. 2.2 New Features in Version 7.3 - vsphere features that were supported on vsphere vcenter 5.5 are now supported on vsphere version 5.5 Update 2b. - In a cluster where all hosts are running ESXi 5.5, the vsphere Agent can now back up and restore VMs with VMDKs that are as large as 2 TB. In a cluster where one or more hosts are running ESXi 5.1, the vsphere Agent backs up VMs with VMDKs that are as large as 2032 GB. - Backup jobs created using vsphere Agent 7.30 can only be encrypted using the strongest available encryption type (currently, AES 256). Jobs created using previous vsphere Agent versions continue to run with their existing encryption type. However, if you change the encryption type for an existing job, you can only select the strongest available encryption type. - When restoring a VM, the Agent can now reconnect a vnic to a distributed virtual port group (and vsphere distributed switch). The port group must have the same name as the port group where the vnic was connected at the time of backup. 3 INSTALLATION NOTES 3.1 Installation Requirements Hardware -------- See the VMware website for supported and recommended hardware platforms. Ensure that the vcenter has sufficient resources, including CPU and memory, for the vsphere Agent and all VMs in your vcenter. Ensure that the vcenter configuration follows VMware recommendations and best practices. When deploying the vsphere Agent with thin-provisioned disks, ensure that 10 GB of free space is available to allow sufficient space for logging and Agent files. Software -------- Using Microsoft SQL Server Express for the vcenter Server database or the internal database used by vcenter virtual appliance is not recommended. 3.2 Conditional Requirements A user ID with full Administrator rights is required for backups and restores.

VMware plug-in versions earlier than 6.90 cannot exist in the same environment as the vsphere Agent. For file and folder restores on Linux platforms, you must install the Samba client in order to mount shared virtual disks (VMDKs). Samba is an installable option with some Linux distributions. You can also visit www.samba.org to download the open-source software. 3.3 Licensing Requirements In Director versions 6.22 and later, the vsphere Agent claims at least three licenses from the Director. A Server Agent license and a VMware plugin license is required for each vsphere Agent. A VMware Cluster license (called ESXFarm ) is required for each hypervisor host in the environment. For example, in a vcenter with 15 VM hypervisors (ESX/ESXi hosts), the vsphere Agent claims 15 Cluster licenses, one ESX license and one Server Agent license. 3.4 Install/Upgrade 3.4.1 Install The vsphere Agent is pre-installed in a VM, and provided in Open Virtualization Appliance (OVA) format. You must deploy the OVA file in the vcenter where you want to back up VMs. The OVA file name is: vsphereagent-7-36-5686.ova To obtain the OVA file, contact your service provider. For deployment and configuration information, see the vsphere Agent User Guide. To restore files and folders from VMDKs that are Windows dynamic disks, you must install a separate Dynamic Disk Tool that is provided with the vsphere Agent. The Dynamic Disk Tool is the preferred way to access files and folders on shared VMDKs. For more information about the Dynamic Disk Tool, see the vsphere Agent User Guide and Dynamic Disk Tool release notes. 3.4.2 Upgrade With Internet access, you can upgrade a vsphere Agent by entering the "system upgrade" command in the Agent CLI. If direct Internet access is not available, you can download RPMs from your service provider, create a CIFS share, and upgrade the vsphere Agent locally using the "system upgrade manual" command. For more information, see the vsphere Agent User Guide. RPMs are available from your service provider in a.zip file named: vsphereagent-7-36-5686-rpms.zip When you upgrade a vsphere Agent, some or all of the RPMs are updated. Settings such as vcenter registration and Web CentralControl credentials are preserved. All vsphere Agents since version 7.01 include a fix for a problem backing up VMDKs that are larger than 1 TB minus 1 KB. To ensure that these large VMDKs are successfully backed up, run backup jobs using vsphere Agent version 7.01 or later. If you upgrade a vsphere Agent from version 7.00 or

earlier, and then perform a backup, the Agent detects VMs with VMDKs larger than 1 TB minus 1 KB, and backs them up correctly. Note: After an upgrade from vsphere Agent version 7.31 or earlier, when vsphere Agent 7.35 first runs an existing job, the Agent rereads all data for the job. For more information, see Section 4.1.2 of these release notes. 3.4.3 Upgrade or install in a vsphere 6.0 environment Do not upgrade a vsphere Agent to version 7.36 or install vsphere Agent 7.36 in a vsphere 6.x environment until all ESXi 6.0 hosts are upgraded to version 6.0 Update 1b or Update 2. In earlier ESXi 6.0 versions, a VMware issue with CBT could result in inconsistent VM backups. To avoid this issue, vsphere Agent 7.35 blocked CBT when backing up VMs in vcenter Server 6.0.x. vsphere Agent 7.34 did not block CBT in vcenter Server 6.0.x, so inconsistent VM backups could occur. To ensure that your VMs are protected, do one of the following before upgrading the Agent to version 7.36: - Run all backup jobs using vsphere Agent 7.35. This will cause the Agent to re-read all data and ensure that it is backed up. You cannot upgrade the Agent to version 7.35 using the "system upgrade" command. If the Agent was not previously upgraded to version 7.35, download the vsphereagent-7-35-5683-rpms.zip file from your service provider. Save the files on a local Windows Share with read/write access, and upgrade the Agent by running the following command: system upgrade manual //path/sharedfolder Domain\User [password] - Reset CBT on vsphere virtual machines as described in VMware's knowledge base article 2139574. 4 FIXES and KNOWN ISSUES 4.1 Fixes 4.1.1 Fix in 7.36 release vsphere Agent 7.36 uses CBT when backing up VMs in vcenter Server 6.0.x. vsphere Agent 7.35 blocked the use of CBT in vcenter Server 6.0.x to avoid a VMware issue that could result in inconsistent backups. This issue was fixed in ESXi 6.0 Update 1b. Do not use vsphere Agent 7.36 in a vcenter where one or more ESXi 6.0 host versions are earlier than 6.0 Update 1b. If you upgrade the vsphere Agent to version 7.36 in an upgraded vsphere 6.0 environment, and then add an ESXi 6.0 host with a version earlier than 6.0 Update 1b, inconsistent backups could occur again and VMware workarounds must be applied. See VMware's knowledge base article 2136854. To ensure that your VMs are backed up before upgrading the vsphere Agent to version 7.36, see Section 3.4.3. (31187) 4.1.2 Fixes in 7.35 release VMware has reported an issue in ESXi 6.0.x where inconsistent VM backups can occur when CBT is used. To prevent this problem from occurring, vsphere

Agent 7.35 blocks the use of CBT when backing up VMs in vcenter Server 6.0.x. CBT is not blocked when backing up VMs in vcenter Server 5.5.x or 5.1.x. For alternative workarounds for this issue, see VMware's knowledge base article 2136854. (31187) When you install vsphere Agent 7.35, the glibc version installed is not vulnerable to GHOST Remote Code Execution. You do not need to upgrade the glibc files. (29176) 4.1.3 Fix in 7.34 release When you upgrade a vsphere Agent to version 7.34, the glibc version installed is not vulnerable to GHOST Remote Code Execution. Note: If you install a new vsphere Agent 7.34, you must run a system upgrade command to install glibc files that are not vulnerable to GHOST Remote Code Execution. For more information, contact Support. (29176) 4.1.4 Fixes in 7.33 release The Bash shell version provided with vsphere Agent 7.33 is not vulnerable to critical security issues known as "Shellshock". This new Bash shell version is installed when you install or upgrade to vsphere Agent 7.33. (28628) Some compatibility issues have been resolved between the vsphere Agent and Portal or Web CentralControl when recent Windows security updates are installed on the Portal server. (28059) 4.1.5 Fix in 7.32 release As described in Section 4.1.5, vsphere Agent 7.30 would sometimes skip files which should have been backed up (when the flag to enable QFS was present), and vsphere Agent 7.31 included a fix that prevented files from being skipped. However, assistance from Support and manual workarounds were required after upgrading to version 7.31 to ensure that jobs which had erroneously skipped files (in vsphere Agent 7.30) would capture the data which had been missed. vsphere Agent 7.32 now automatically detects and fixes any problems in existing backup jobs. When vsphere Agent 7.32 first runs an existing backup job, the Agent rereads all data for the job to ensure that the entire contents of the VMs are protected. This occurs on the first backup after any previous vsphere Agent version is upgraded to version 7.32, or after vsphere Agent 7.32 is reregistered to a vault with backups from any previous Agent version. (27619) 4.1.6 Fix in 7.31 release Note: vsphere Agent 7.31 is no longer available and is superseded by vsphere Agent 7.32. QFS (Quick File Scanning) is not applicable to vsphere Agent backups. Instead, the Agent uses CBT (Changed Block Tracking) to identify disk sectors that have changed. In some cases, backup configurations can include a flag to enable QFS. This can occur if vsphere Agent 7.30 was managed using Portal prior to April 5, or if a backup schedule was edited manually. Previous vsphere Agent versions ignored the flag to enable QFS. vsphere Agent 7.30 did not ignore this flag. If QFS was enabled for a backup, vsphere Agent 7.30 could skip files which should have been backed up.

vsphere Agent 7.31 now ignores the flag to enable QFS. If you ran backups using vsphere Agent 7.30, contact Support to determine whether any backups were affected and to ensure that data is backed up correctly. (27619) 4.1.7 Fixes in 7.30 release For a vcenter environment with a large number of datastores, the restore wizard no longer times out when preparing the list of destination datastores. (25467) Under rare conditions, the Agent became unresponsive during a backup. This problem no longer occurs. (26374) The presence of a VM that contains a large number of snapshots (e.g., more than 250) no longer causes backups to fail for any other VMs in the vcenter. (24703) 4.2 Known Issues 4.2.1 Backup Issues In vcenter Server 6.0 and vcenter Server 6.0 Update b, the vcenter vpxd service could fail in rare cases under extremely heavy load. VMware included a fix for this issue in vcenter Server 6.0 Update 1. WORKAROUND: Upgrade the vcenter Server to version 6.0 Update 1. (29828) Backups of large VMs whose file systems are highly fragmented can sometimes fail with no errors or warnings (segmentation fault). WORKAROUND: Defrag the volumes within the VM. (22816) When a job is configured to use CBT, the Agent may fail to enable CBT for a VM with the message "Failed to enable Changed Block Tracking on VM <VM name>". In some cases, this occurs because the VM is suspended and VMware does not allow CBT to be enabled for a suspended VM. WORKAROUND: Power the VM on or off before the next backup so that CBT can be enabled. Once CBT has been enabled, backups will be able to use CBT even while the VM is suspended. (21846) When a job is configured to use CBT, the Agent may fail to enable CBT for a VM with the message "Failed to enable Changed Block Tracking on VM <VM name>". In some cases, this occurs because VMware does not allow CBT to be enabled for a VM which already has one or more snapshots. WORKAROUND: Remove the snapshot(s) so that CBT can be enabled. (21739) The log for a backup which recreates the metadata needed for incrementals (e.g., after changing the encryption password) will contain an informational message which mentions that "quick file scanning will be turned off". This message can be ignored; QFS is not applicable to VMware backups (because CBT provides equivalent functionality). (22989) vsphere Agents are not prevented or protected from performing concurrent backups of the same VM from the same vsphere Agent or another vsphere Agent. Avoid running concurrent backups of the same VM or job from the same vsphere Agent or another vsphere Agent. This can cause unfavorable CBT results and put delta backups out of sync. (21659) 4.2.2 Snapshot Issues (27108, 22557)

In most cases, vsphere Agent deletes the snapshot used for a backup after the backup completes. The delay until the snapshot has been deleted can be substantial (e.g., several hours if the vcenter is busy). In some cases where backups fail (e.g. because vsphere Agent cannot connect to vcenter), the snapshot for a VM could be left behind. In most cases, the leftover snapshot will be cleaned up before the next attempt to back up the same VM. Do not reboot the Agent in this situation, as doing so might interfere with the Agent's mechanism for cleaning up old snapshots. In rare cases, the Agent might not clean up a snapshot left behind by a previous terminated or failed backup, and the next attempt to back up the same VM fails. If this occurs, remove the leftover snapshot using the vcenter UI. It might also be necessary to run the "Consolidate Snapshots" command in the vcenter UI. For assistance or more information, contact Support. 4.2.3 Restore Issues Do not attempt to restore a VM with a VMDK larger than 2032 GB to an ESXi version 5.1 host. vsphere Agent 7.31 can back up these VMs on an ESXi 5.5 or 6.0 host. However, if they are restored to an ESXi 5.1 host, the Agent will not be able to resume backups of the restored VM. WORKAROUND: Restore a VM with a VMDK larger than 2032 GB to an ESXi 5.5 or 6.0 host. (27562) If there is insufficient space for restoring a VM or VMDK on the original or alternate datastore, the restore appears to continue but the data is not restored. WORKAROUND: Restore VMs and VMDKs to datastores with sufficient space. (23379) In a restore, each VM and VMDK is restored to a separate folder on a datastore: one for each VMX file, and one for each VMDK file. The first folder created has the specified name. "_X" is appended to the name for each subsequent folder, where X is a sequential number starting at 1. (23561/21952) 4.2.4 File and Folder Restore Issues To prevent problems with granular restores, the minimum bandwidth usage value for the Agent is now 1500 kilobits per second. If bandwidth throttling is set for the Agent, the total bandwidth available is divided by the number of granular restores you are running. Reduced bandwidth can cause delays in opening the Dynamic Disk Tool and mounting VMDKs, and could cause the Dynamic Disk Tool to become unresponsive. (23057) If you terminate a granular restore and then try to perform another granular restore, the second attempt may hang before the data is made available. When this occurs, the vsphere Agent will not respond to any attempts to cancel the restore. WORKAROUND: Force the vsphere Agent to restart before performing another granular restore. (23053) For Linux VMs, granular restores are supported on LVM2 volumes that do not span multiple virtual disks. Granular restores do not work with LVM2 volumes that span multiple virtual disks. (23196) Email notifications are not provided for granular restores. (22842)

4.2.5 Communication Issues If replication between vaults is configured using host names instead of IP addresses, and the vsphere Agent cannot resolve host names, the Agent cannot register or back up to a Base or Passive vault. The log does not indicate that the problem is related to host name resolution. WORKAROUND: Configure replication using vault IP addresses instead of host names, or ensure that the vsphere Agent can resolve host names using DNS or static entries. If you replace a vsphere Agent's virtual network card or assign a different MAC address, the Agent does not recognize the virtual network card after a reboot. WORKAROUND: In the Agent Setup interface, select Network Reset. The Agent then recognizes the new virtual network card and assigns an IP Address or can be configured to use static IP. (24053) Windows CentralControl may be unable to connect to the vsphere Agent when Windows proxy settings prevent it from obtaining the SSL certificate from the Agent. WORKAROUND: On the computer where Windows CentralControl is running, disable proxy settings in Internet Explorer. (23231) When performing a reregistration to the vault, vcenter credentials are removed from the Agent configuration, and backups, restores and synch operations fail until you provide correct vcenter credentials. WORKAROUND: Provide vcenter credentials so that Synchronize can recover the delta information. (22028) 4.2.6 Naming Issues In some circumstances, vcenter allows multiple VMs to have identical display names. All of these VMs are shown in the list displayed in the UIs when configuring a job for the vsphere Agent, and they can be selected for inclusion in the job. However, when the job runs, these VMs will not be backed up. WORKAROUND: Rename VMs so that each has a unique name. (21900) When the vsphere Agent host name is longer than 20 characters, backups fail with "Validation failed: failed to validate computer". The vsphere Agent host name must be restricted to a maximum 20 characters. (22388) VM names with special characters may display differently in the backup structure versus the restore structure. Upon restore, the log might indicate that the VM has been renamed, and also that the created datastore folder name is incorrect. However, in VMware, the name of the restored VM appears correctly. (22281) In vcenter 5, the following characters cannot be used and are not supported for VM names: # & @ { } (21974/21415) When you try to change the vsphere Agent host name, the following warning sometimes appears: "This node is a group master. Changing the hostname may break the group communication." You can ignore this warning and continue to change the Agent host name. Changing the Agent host name does not result in any problems. (23289)

When you create a support bundle, the destination directory cannot include spaces. (24105) 5 PRODUCT SUPPORT 5.1 Technical Support Contact information for your provider is available through the Help menu. 5.2 Product Updates Product updates are available from your provider. 5.3 Documentation The following documentation is available for the vsphere Agent: vsphere Agent User Guide vsphere Agent Quick Start Guide vsphere Agent release notes (this document) DynamicDiskTool release notes All documentation is available from your provider.