* * * READ ME * * *
                  * * * Veritas Risk Advisor 7.0 * * *
                          * * * Patch 1 * * *
                         Patch Date: 2015-08-07


This document provides the following information:

   * PATCH NAME
   * OPERATING SYSTEMS SUPPORTED BY THE PATCH
   * PACKAGES AFFECTED BY THE PATCH
   * BASE PRODUCT VERSIONS FOR THE PATCH
   * SUMMARY OF INCIDENTS FIXED BY THE PATCH
   * DETAILS OF INCIDENTS FIXED BY THE PATCH
   * INSTALLATION PRE-REQUISITES
   * INSTALLING THE PATCH
   * REMOVING THE PATCH
   * KNOWN ISSUES


PATCH NAME
----------
Veritas Risk Advisor 7.0 Patch 1


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
Windows Server 2012 R2 X64 and IA64
Windows Server 2008 R2 X64 and IA64



BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Veritas Risk Advisor 7.0


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: 7.0.0_HF1
* 3835359 (3835356) * Temp files are accumulated and not deleted when agent is used for data collection
* Gap ID 1600 may fail when ZVM is installed on a standalone ESXi host
* Gap ID 380 may fail to run successfully
* VMware SRM scan may fail
* Incorrect scan status when performing test connectivity through an Agent
* Generation of several reports fails
* WebLogic configuration collection fails due to invalid XML 
* WebLogic deployment checksum collection issue
* Scan troubleshooting page presents outdated information
* Partial HBA masking information collected for EMC DMX
* XIV cluster mappings collection issue
* Filesystem collection issue on Solaris servers with non-English Locale
* vxdmp.sh script fails on hosts with large number of storage devices
* Error reported when scanning an AIX WebLogic server
* Zerto scan may fail when a null group exists
* XIV devices are not discovered on HP-UX hosts
* HDS and EMC Symmetrix device access by ESXi clusters is partially collected
* Partial vCenter configuration collection due data parsing issue
Changes and Enhancements
-------------------------
* Ability to disable the SLA tab and enrichment added
* Ability to tune level of data collection from VMware vCenter


DETAILS OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
This patch fixes the following Symantec incidents:

Patch ID: 7.0.0_HF1

* 3835359 (Tracking ID: 3835356)

SYMPTOM:
* Temp files are accumulated and not deleted when agent is used for data collection
* Gap ID 1600 may fail when ZVM is installed on a standalone ESXi host
* Gap ID 380 may fail to run successfully
* VMware SRM scan may fail
* Incorrect scan status when performing test connectivity through an Agent
* Generation of several reports fails
* WebLogic configuration collection fails due to invalid XML 
* WebLogic deployment checksum collection issue
* Scan troubleshooting page presents outdated information
* Partial HBA masking information collected for EMC DMX
* XIV cluster mappings collection issue
* Filesystem collection issue on Solaris servers with non-English Locale
* vxdmp.sh script fails on hosts with large number of storage devices
* Error reported when scanning an AIX WebLogic server
* Zerto scan may fail when a null group exists
* XIV devices are not discovered on HP-UX hosts
* HDS and EMC Symmetrix device access by ESXi clusters is partially collected
* Partial vCenter configuration collection due data parsing issue
Changes and Enhancements
-------------------------
* Ability to disable the SLA tab and enrichment added
* Ability to tune level of data collection from VMware vCenter

DESCRIPTION:
* When agent is used for data collection and encryption is enabled, temporary
files are accumulated on the master server and never deleted, which may
eventually lead to free disk space problems. 
* Gap 01600ZVMInstalledOnVMWithoutHA fails to open a ticket when the Zerto
Virtual Manager (ZVM) VM is installed on a host that does not belong to an ESXi
cluster.
* Gap 00380HBAFamily may fail to open a ticket and report an exception in the
log file. 
* In rare cases VMware SRM scan may fail due to data parsing issue.
* When an agent is used for data collection and the user performs the Test
Connectivity operation, the user interface incorrectly reports Connection
Error although the connection was successful. 
* Generation of the following reports fails: Database Replica Synchronization,
Database Storage Utilization, Host HBA Comparison, Host to Storage SAN
Connectivity, Hosts with a Single SAN I/O Path, MS SQL Server Backup Summary,
NetApp Filer Replication Summary, Old Replicas, Replicated Temporary Databases,
Standby Pairs, Storage Allocation Optimization, Un-replicated Data on Replicated
Hosts, Un-synchronized Remote Replication, VMware Summary, What-if Impact Analysis.
* In certain cases, WebLogic configuration collection may fail due to an invalid
XML file structure. 
* In certain cases, the checksum of WebLogic deployments fails to be collected. 
* When opening the Scan Troubleshooting page, the data presented is not up-to-date. 
* In certain cases partial HBA masking information is collected from the output
of the symmaskdb list command. 
* When an XIV cluster name includes multiple words separated by white space, its
mappings (masking) are not collected. 
* When scanning a Solaris server configured with Locale other than English,
additional inexistent filesystems are occasionally wrongly identified.
* The vxdmp.sh data collection script fails on hosts with large number of
storage devices. 
* When scanning an AIX host installed with WebLogic, log file may report an error. 
* When ZVM is scanned and a protection group with no machines is configured, the
scan will fail. 
* Scan of HP-UX hosts does not discover IBM XIV storage volumes. 
* In environments where ESXi clusters are accessing HDS or EMC Symmetrix storage
volumes, only one of the cluster hosts is correctly identified with storage access. 
* The system may not collect all the VM information when one or more of the VM
names include a special char. 
Changes and Enhancements
-------------------------
* It is now possible to disable the SLA tab functionality system-wide. Once
disabled and following a tomcat restart, the SLA tab will not be presented.
Furthermore, risk analysis will not perform tasks related to the SLA tab. 
	To disable the SLA tab:
	#	Backup the current VRA Configuration.xml file, located under
[TOMCAT_HOME]\webapps\VRA\WEB-INF\classes\conf.	Do not skip this step.
	#	Edit the Configuration.xml file and add the following property under the SLA section:
		Property privacy="public" category="SLA" description="Activate SLA Module" valuetype="boolean" 
		name="activate.sla.module" defaultValue="true" info="Changing this property will take effect only after the
		next user login"/
	#	Take care not to modify any other elements within the Configuration xml file, and to keep the XML structure
		intact. In case the Configuration xml file is malformed, VRA will fail to start.
	#	Restart Tomcat.
	#	Login to VRA and navigate to the Configuration tab. Select System Properties on the left navigation tree and 			
		edit the “Activate SLA Module” under the SLA properties group. Set the property value to “No”.

* It is now possible to tune the level of data collection performed against VMware vCenter, and to enable a new processing 
algorithm designed for large vCenter outputs. These two options can be used to reduce the overall vCenter scan time. 
Some of the data returned by vCenter queries is not used to date and collected only for future potential use. 
The following procedure can be used to configure VRA to collect only the information currently required for risk detection 
and reports. Note that no functionality is harmed or reduced in any way by enabling this option.
	The procedure: 
	#	Backup the current VRA Configuration.xml file, located under [TOMCAT_HOME]\webapps\VRA\WEB-INF\classes\conf. 			
		Do not skip this step.
	#	Open the Configuration.xml file and search the following property:
		Property category="Collection - Admin" defaultValue="true" description="Whether to collect all vCenter data" 			
		name="mediator.vcenter.getall" privacy="protected" valuetype="boolean"/
	#	Replace the property with the following:
		Property brand="open" category="Collection - Admin" defaultValue="true" description="Whether to collect all 			
		vCenter data" excludedProducts="" group="General" info="" name="mediator.vcenter.getall" privacy="protected" 			
		value="false" valuetype="boolean"/
	#	Take care not to modify any other elements within the Configuration xml file, and to keep the XML structure 			
		intact. In case the Configuration xml file is malformed, VRA will fail to start.
	#	Restart Tomcat.

RESOLUTION:
Symantec has modified the code to resolve these issues.



INSTALLING THE PATCH
--------------------
1. Download the patch VRA_7.0.0_HF1.exe and copy it to the master VRA server.
2. On the master VRA server, stop the VRA web server using the following steps:
    a. Open a command line window running with administrator privileges
    b. Enter the following commands: 
        # net stop TomcatWatchDog
        # net stop tomcat8
3. Locate the VRA folder. By default, it is in the path: 
    C:\Program Files\Apache Software Foundation\Tomcat 8.0\webapps\ 
4. Make a copy of the VRA folder and store it in another location (do not store the copy under the tomcat tree). The patch updates files in this folder, so if you need to revert to the unpatched version of VRA, you will need the original folder.
5. Go to the folder where you downloaded the patch. Find VRA_7.0.0_HF1.exe and double-click it.
6. Follow the steps in the wizard to install the patch. 
7. On the master VRA server, start the VRA web server using the following steps:
    a. Open a command line window running with administrator privileges
    b. Enter the following commands: 
        # net start tomcat8
        # net start TomcatWatchDog
8. Login to VRA. 
9. Verify that the build number is correct. On the VRA main screen, click "About". The build number should be 38149.


REMOVING THE PATCH
------------------
Symantec strongly recommends that you install the patch. However, if after installing it you need to revert to the unpatched version of VRA 7.0, use the following procedure:

1. Make sure you still have the backed up copy of the pre-patched, version 7.0 VRA folder
2. On the master VRA server, stop the VRA web server using the following steps:
    a. Open a command line window running with administrator privileges
    b. Enter the following commands: 
        # net stop TomcatWatchDog
        # net stop tomcat8
3. Locate the VRA folder. By default, it is in the path:
    C:\Program Files\Apache Software Foundation\Tomcat 8.0\webapps\ 
4. Delete the "VRA folder"
5. Copy the backed up folder to its original location.  If you have changed the name of the copied folder, make sure to rename it to "VRA" (not including the quotes).
6. On the master VRA server, start the VRA web server using the following steps:
    a. Open a command line window running with administrator privileges
    b. Enter the following commands: 
        # net start tomcat8
        # net start TomcatWatchDog


KNOWN ISSUES
------------
* Tracking ID: 3835415

SYMPTOM: No Symptom Found

WORKAROUND: No WorkAround Found



SPECIAL INSTRUCTIONS
--------------------
NONE


OTHERS
------
NONE