vcs-win_x64-CP6_VCSW_61

 Basic information
Release type: Patch
Release date: 2017-02-28
OS update support: None
Technote: None
Documentation: None
Popularity: 1047 viewed    downloaded
Download size: 28.46 MB
Checksum: 1525161528

 Applies to one or more of the following products:
Cluster Server 6.1 On Windows x64

 Obsolete patches, incompatibilities, superseded patches, or other requirements:
None.

 Fixes the following incidents:
3483164, 3590862, 3659693, 3684343, 3773252, 3773919, 3782628, 3820750, 3820751, 3862936, 3874745, 3889526, 3905599, 3910006

 Patch ID:
None.

Readme file
                          * * * READ ME * * *
                * * * Symantec Cluster Server 6.1 * * *
                      * * * Patch 6.1.0.600 * * *
                         Patch Date: 2017-02-28


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


PATCH NAME
----------
Symantec Cluster Server 6.1 Patch 6.1.0.600


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



BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Symantec Cluster Server 6.1


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: VCSW CP6
* 3910006 (3910307) Issue 1: The status of a Symantec Cluster Server (VCS) cluster is displayed incorrectly on the Veritas Operations Manager interface.
Issue 2: High Availability (HA) commands take long time to execute in a secure cluster.
Issue 3: CP4 and CP5 post-install tasks take a long time to complete or fail.
* 3905599 (3905019) WAC resource stops sending IAmAlive messages after a certain duration of time and reports the TCP/IP connection as unresponsive.
* 3483164 (3483164) In a cluster configured to use single sign-on authentication (secure cluster), the application service group configuration wizards fail with a 
"CmdServer service not running on system:nodename" error.
* 3590862 (3572840) The VxExplorer and the hagetcf utility fails to collect the GAB/LLT logs.
* 3659693 (3659697) Some of the cluster nodes may crash (BSOD) when all the network links are unconfigured from all the cluster nodes.
* 3684343 (3684342) A system crash occurred when VxExplorer gathered the GAB/LLT logs.
* 3773919 (3773915) Lanman resource fails to come online.
* 3773252 (3521503) The Lanman resources fault when checking whether the virtual server name is alive.
* 3820750 (3820747) A VMwareDisks resource takes a long time to come online or to go offline.
* 3820751 (3820747) A NativeDisks resource takes a long time to come online or to go offline.
* 3782628 (3615728) VMwareDisks agent supports only 'persistent' virtual disk mode.
* 3862936 (3862932) Rapid memory consumption occurs when Fire Drill is configured.
* 3874745 (3867326) VMDg resource fails to get online with error "OnlineDg failed. Error: 1".
* 3889526 (3880490) Issue 1: Users cannot increase the value of the LLT tunable parameter 'peerinact' beyond 3200 on Windows.
Issue 2: Heartbeat issues affecting virtual and physical servers.


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

Patch ID: VCSW CP6

* 3910006 (Tracking ID: 3910307)

SYMPTOM:
Issue 1: Even though a cluster is online and active, its information is displayed incorrectly on the Veritas Operations Manager interface.
Issue 2: High Availability (HA) commands take long time to execute in a secure cluster.
Issue 3: After any one of the following patches is installed, the VCS engine fails to start on a local node:
- Hotfix_6_1_00018_3856596
- CP4  
- CP5

DESCRIPTION:
Issue 1: Veritas Operations Manager runs the HA commands to discover a cluster and its details. The HA commands from Veritas Operations Manager  work with the default %VCS_HOME% path, so they fail if VCS is installed at a custom location. Thus, when VCS is installed at a custom location, Veritas Operations Manager is unable identify its correct status.
Issue 2: Executing HA commands may take approx 5 to 7 seconds in case when PDC is located in different geographical location. This happens because DC related APIs take long time to get completed, when they are invoked from AT for creating AT credentials.
Issue 3: An error message in the engine_A.log file indicates that the local node has left the cluster due to a difference in the VCS engine version. This issue occurs due to a version mismatch between the VCS engine on the upgraded node and the non-upgraded nodes. The engine version on the upgraded nodes is incorrectly set to 7.0.

RESOLUTION:
Issue 1: This patch addresses the issue by updating the HA executables to identify the home directory location from the appropriate registry key instead of the default %VCS_HOME% path.
Issue 2: This issue is fixed wherein time-consuming AT APIs are only invoked first time when they are executed. For subsequent execution of HA command, cached credentials are used.
Issue 3: This patch corrects the VCS engine version that was shipped in the hotfix 'Hotfix_6_1_00018_3856596' and the cumulative patches CP4 and CP5 from 7.0 to 6.1.

NOTE: You do not need to restart the system after installing this patch.

NOTE: This hotfix supersedes Hotfix_6_1_00018_3856596, which was released earlier.

FILE / VERSION:
haagent.exe/6.1.28.315
haalert.exe/6.1.28.315
haattr.exe/6.1.28.315
hacf.exe/6.1.28.315
hacli.exe/6.1.28.315
haclus.exe/6.1.28.315
haconf.exe/6.1.28.315
had.exe/6.1.28.315
hadebug.exe/6.1.28.315
hagrp.exe/6.1.28.315
hadiscover.exe/6.1.28.315
hahb/6.1.28.315
halog/6.1.28.315
hamsg/6.1.28.315
hareg/6.1.28.315
hares/6.1.28.315
hashadow/6.1.28.315
hasite/6.1.28.315
hastart/6.1.28.315
hastatus/6.1.28.315
hastop/6.1.28.315
hasys/6.1.28.315
hatype/6.1.28.315
hauser/6.1.28.315
hanotify/6.1.28.315

* 3905599 (Tracking ID: 3905019)

SYMPTOM:
WAC resource stops sending IAmAlive messages after a certain duration of time and reports the TCP/IP connection as hung.

DESCRIPTION:
VCS incorrectly calculates the current time for a WAC resource due to the limitation of a Microsoft API (GetTickCount()). This current time is further used to control the sending of IAmAlive messages betweeen the WAC resources. Therefore, after a certain duration of time, the WAC resource stops sending IAmAlive messages to its peer and causes the connection to become unresponsive.

RESOLUTION:
This hotfix addresses the issue by correctly calculating the current time for a WAC resource using of a different API (GetTickCount64()).

FILE / VERSION:
wac.exe / 6.1.27.315

* 3483164 (Tracking ID: 3483164)

SYMPTOM:
In a cluster configured to use single sign-on authentication (secure cluster), the application service group configuration wizards fail with a 
"CmdServer service not running on system:nodename" error.

DESCRIPTION:
If a cluster is configured to use single sign-on authentication (secure cluster), then the application service group configuration wizards fail to connect to the remote cluster nodes with the following error:
"CmdServer service not running on system:nodename"
This error is displayed even though the VCS Command Server service is running on all the nodes. 
The wizard displays the error on the System Selection panel.
The issue occurs because the remote node IP address used for its authentication is not reachable.

RESOLUTION:
This hotfix enhances the wizard behaviour.
If the IP address of the remote cluster node is not reachable, then the wizard uses the hostname to connect to the nodes.

To resolve the issue, 
1) Exit the service group configuration wizard
2) Install the hotfix
3) Run the service group configuration wizard again

FILE / VERSION:
WizCmdClient.dll / 6.1.1.283

* 3590862 (Tracking ID: 3572840)

SYMPTOM:
The VxExplorer and the hagetcf utility fails to collect the GAB/LLT logs in the following two scenarios:
- The product is installed at a location other than the C: drive 
- The product is installed at a location on C: but the Windows option to generate the file names in 8dot3 format is disabled

DESCRIPTION:
During the product installation, by default, the installer installs the product package at the following location:
C:\program files\Veritas
Instead of this default location if you choose to install the package at a custom location (other than the c: drive) or if you disable (on the C: drive) the Windows option to generate 8dot3 format file names,
then the VxExplorer and the hagetcf utility fails to collect the GAB/LLT logs.
This issue occurs because the VxExplorer and the hagetcf utility uses the 8dot3 format files names (instead of the actual installation path) to collect the logs.
When the product is installed at a location on C: drive, the VxExplorer or the hagetcf utility can access the files using the 8dot3 format file names. 
However, if the product is installed at a location other than the C: drive or if the Windows option to generate the file names in 8dot3 format is disabled on C: drive,  then the VxExplorer and the hagetcf utility fails to access the files and to collect the logs.

RESOLUTION:
The behavior of VxExplorer and the hagetcf utility is modified through this hotfix.  The VxExplorer or the hagetcf utility now uses the complete installation path to collect the logs.
NOTE: The hotfix installer replaces the getcomms.pl file at the following location:
"%vcs_home%\bin\"
You must copy this file and replace its instance in the VxExplorer folder.  

FILE / VERSION:
getcomms.pl

* 3659693 (Tracking ID: 3659697)

SYMPTOM:
Systems may crash (BSOD) when all the network links are unconfigured from all the cluster nodes.

DESCRIPTION:
This issue occurs if all the network links are unconfigured from all the cluster nodes.
The network links from the all the cluster nodes can be unconfigured in any of the following scenarios:
- User executes the following command:
  -lltconfig -u
- Network adapter is disabled from all the machines
- Hyper-V live migration occurs
Once all the links are unconfigured, LLT reports to GAB about the network links being unconfigured from local as well as the other nodes in the cluster.
This resets the value of GAB membership to "Empty", due to which some of the nodes may crash.

RESOLUTION:
This hotfix addresses the issue by updating LLT behaviour. 
LLT now does not report to GAB about the network links being disconnected from the local node.
This prevents to reset the GAB membership to "Empty" and the cluster nodes do not crash. 

FILE / VERSION:
llt.sys / 6.1.10.298

* 3684343 (Tracking ID: 3684342)

SYMPTOM:
When VxExplorer gathers the GAB/LLT logs, the program crashes or causes a system crash.

DESCRIPTION:
This issue occurs when the lltshow utility attempts to fetch information about the LLT nodes or links using the following options:
lltshow -n -1
lltshow -l -1
VxExplorer executes these commands when gathering the logs. Therefore, you might encounter the issue when you run VxExplorer with the GAB/LLT option.

RESOLUTION:
This hotfix addresses the issue by updating the lltshow utility to identify the correct sizes of the LLT nodes and links.

FILE / VERSION:
lltshow.exe / 6.1.11.301

* 3773919 (Tracking ID: 3773915)

SYMPTOM:
The Lanman resource fails to come online due to certain DNS settings.

DESCRIPTION:
This issue occurs if your setup uses CNAME records instead of  HOST (A) records for the virtual name. The Lanman agent faults when it performs a duplicate name check, because it incorrectly looks at non-HOST records.

RESOLUTION:
This hotfix addresses the issue by updating the Lanman agent to look at only the HOST records from a DNS query.

FILE / VERSION:
Lanman.dll / 6.1.12.308

* 3773252 (Tracking ID: 3521503)

SYMPTOM:
When bringing the Lanman resource online, the Lanman agent checks whether the virtual server name is alive. If the virtual server name is alive, the resource faults.

DESCRIPTION:
This issue occurs if your setup contains DNS entries that point to a virtual IP address that is online. The Lanman agent faults when it performs a duplicate name check.

RESOLUTION:
This hotfix addresses the issue by updating the Lanman agent to skip the duplicate name check.

ADDITIONAL TASKS: After you apply this hotfix, perform the following tasks on all the nodes in the cluster.
1. Open the registry editor.
2. Navigate to the registry key:
'HKLM\SOFTWARE\VERITAS\VCS\BundledAgents\Lanman\<Lanman_Resource_Name>'
or
'HKLM\SOFTWARE\VERITAS\VCS\BundledAgents\Lanman\__GLOBAL__' 
3. Create the DWORD key 'DisablePingCheckForDND' with the value '1'.
Note: If you create this tunable parameter under the '__GLOBAL__' key, it applies to all the Lanman resources configured in the cluster.

FILE / VERSION:
Lanman.dll / 6.1.12.308

* 3820750 (Tracking ID: 3820747)

SYMPTOM:
The VMwareDisks agent takes longer than expected to bring a VMwareDisks resource online or to take it offline.

DESCRIPTION:
In large ESX or vCenter configurations with lots of datastores, the VMwareDisks agent does not work efficiently.

RESOLUTION:
This hotfix addresses the issue by enhancing the VMwareDisks agent to work more efficiently in large ESX or vCenter configurations.

FILE / VERSION:
VMwareDisks.dll / 6.1.14.313
VMwarelib.dll / 6.1.14.313

NOTE: Symantec recommends that you set the NumThreads attribute of the VMwareDisks agent to 1; otherwise, the agent may fail intermittently.

* 3820751 (Tracking ID: 3820747)

SYMPTOM:
The NativeDisks agent takes longer than expected to bring a NativeDisks resource online or to take it offline.

DESCRIPTION:
In large configurations with systems that have many high-capacity disks attached, the NativeDisks agent does not work efficiently.

RESOLUTION:
This hotfix addresses the issue by enhancing the NativeDisks agent to work more efficiently in large configurations.

FILE / VERSION:
NativeDisks.dll / 6.1.15.314

NOTE: Symantec recommends that you set the NumThreads attribute of the NativeDisks agent to 1; otherwise, the agent may fail intermittently.

* 3782628 (Tracking ID: 3615728)

SYMPTOM:
VMwareDisks agent supports only 'persistent' virtual disk mode.

DESCRIPTION:
The VMwareDisks agent currently supports only 'persistent' virtual disk mode.
If you have configured the disk in 'independent' mode, in the event of a failover, the VMwareDisks agent sets the mode to 'persistent'.

RESOLUTION:
The behaviour of VMwareDisks agent is modified through this hotfix. 
The VMwareDisks agent now supports 'independent' disk mode.
An attribute 'VirtualDiskMode' is now added to the VMwareDisks agent's attributes. 
You can set the value of this attribute to 'persistent', 'independent_persistent' or 'independent_nonpersistent'.
By default the value is set to 'persistent'. You must modify the value after you configure application monitoring.
Note: The VMwareDisks agent does not detect the mode in which the disk is configured. After a fail over the disk is attached in the mode as that defined 
in the attribute value. 
For more details about the disk modes, refer to VMware documentation.

To modify the value use the VCS Java Console or perform the following steps through command line:
1.	If you have configured the disk in 'persistent' mode, bring the service group offline.
hagrp -offline service_group -sys system_name
2.	Change the cluster configuration to read-write mode
haconf -makerw
3.	Modify the attribute value
hares -modify resource_name VirtualDiskMode independent_persistent
4.	Save the cluster configuration and change the mode to read-only.
haconf -dump -makero 

FILE / VERSION:
VMwareDisks.dll 6.1.13.311
VMwarelib.dll 6.1.13.311
VMwareDisks.xml

* 3862936 (Tracking ID: 3862932)

SYMPTOM:
Memory consumption increases rapidly in a FireDrill setup for IMF-enabled agents.

DESCRIPTION:
When a fire drill (FD) service group (SG) is brought online, the offline monitoring function of Intelligent Monitoring Framework (IMF) detects that the resources are up. IMF then notifies the corresponding application SG resources that the FD resources are online. Since the FireDrill attribute is set to True, this notification is ignored and the state of the resources remains unchanged in the application service group.
IMF once again registers for offline monitoring, and again notifies the application SG again that the FD resources are up. These continue in a loop.
The same behavior is observed if you configure an application for fire drill and then bring the application SG online.

RESOLUTION:
This hotfix addresses the issue by disabling offline IMF monitoring whenever the FireDrill attribute is set to true.
The function that initiates offline monitoring now skips the IMF registration if FireDrill is set to True. IMF now attempts to register for offline monitoring only a fixed number of times and the stops.

NOTE:
- If the Intelligent Monitoring Framework (IMF) Mode value is set to 3, IMF is applied to both offline and online monitoring. However, if the FireDrill attribute is set to True, offline 'intelligent' monitoring is disabled for as long as FireDrill is enabled.
- If the affected VCSAgDriver process continues to consume memory even after you have applied this hotfix, the process may not have been killed during the installation. If you encounter this situation, kill the process manually. Then, restart HAD by using the following commands:
1. hastop -local -force
2. hastart

FILE / VERSION:
vcsagfw.dll / 6.1.17.315
IAL.dll / 6.1.17.315

* 3874745 (Tracking ID: 3867326)

SYMPTOM:
VMDg resource fails to get online with error "OnlineDg failed. Error: 1".

DESCRIPTION:
If the VMDg is in the Disabled state, VCS cannot find the disk group and so it fails to bring the VMDg resource online. 
This situation may occur if the disk group gets disabled at the array level before VCS sends a 'disable' call to SFW. 
The updated state of the disk group is not available when VCS attempts to bring the VMDg resource online, so the import fails.

RESOLUTION:
This hotfix addresses the issue by updating the VMDg agent introduce a rescan operation. 
If VCS encounters the error code 1 (one) while importing a disk group, it performs a rescan, and waits for the operation to complete. 
When a rescan is successful and the state of the disks is updated to Enabled, VCS attempts to bring the disk group online. 
The rescanning of disk groups depends on a newly introduced registry setting. Perform the following steps to add the 'RescanEnabled' registry key.
ADDITIONAL TASKS: After you apply this hotfix, perform the following tasks on all the nodes in the cluster. 
1. Open the registry editor. 
2. Navigate to the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\VCS\BundledAgents\VMDg\ 
3. Create the DWORD key 'RescanEnabled' with the value '1'. 
NOTE: After installing this hotfix on a secure cluster, the Startup Type of the VCS Authentication Service may change to Manual from Automatic. 
If this happens, make sure to change the Startup Type back to Automatic. 

FILE / VERSION:
VMDg.dll / 6.1.00019.315

* 3889526 (Tracking ID: 3880490)

SYMPTOM:
Issue 1: Intermittent network issues lead to a split-brain scenario in a VCS cluster.
Issue 2: LLT links are intermittently lost on VCS cluster nodes that are configured with LLT over ethernet.

DESCRIPTION:
Issue 1: Increasing the value of the LLT peerinact parameter on Windows to more than 3200 (32 seconds) does not take effect. 
For example, you may set the value as follows: 
-lltconfig -T peerinact:3400 
However, it still remains capped at 3200.
Issue 2: This issue occurs when LLT honors an operating system (OS) call to unbind the all the adapters (NICs) that are registered with NDIS. 
When the adapters are unbound, the corresponding LLT links are also closed.

RESOLUTION:
Issue 1: This hotfix provides an update that lets you set the peerinact value to a maximum of 214748300 (2147483 seconds). 
Issue 2: This hotfix resolves the issue by updating LLT so that after honoring a call from the OS to unbind an adapter, it binds that adapter back. 

FILE / VERSION: 
llt.sys / 6.1.23.315



INSTALLING THE PATCH
--------------------
What's new in this CP
=====================|

The following hotfixes have been added in this CP:
 - Hotfix_6_1_00027_3905599
 - Patch_6_1_00028_3910006
For more information about these hotfixes, see the "FIXED_INCIDENTS" section in this Readme.

Note: Create the cluster before you install this CP. If you have already installed the CP before the cluster was created, then create the cluster and execute the C:\Program Files (x86)\Common Files\Veritas Shared\WxRTPrivates\Hotfix_6_1_00014_3820750\InstallVMwareDisksType.bat batch file.

Install instructions
====================|

Download the appropriate cumulative public patch (CP) executable file to a temporary location on your system.

Each cumulative public patch includes the individual hotfixes that contain enhancements and fixes related to reported issues.
See the "FIXED_INCIDENTS" section for details.

Before you begin
----------------:
[1] Ensure that the logged-on user has privileges to install the CP on the systems.

[2] One or more hotfixes that are included with this CP may require a reboot.
Before proceeding with the installation ensure that the system can be rebooted.

[3] Symantec recommends that you close the Cluster Manager (Java Console) and the Veritas Enterprise Administrator (VEA) Console before installing this CP.

[4] Ensure that you close the Windows Event Viewer before proceeding with the installation.

[5] Before installing CP, ensure that the Startup type of the VCS Authentication Service is set to Automatic. This is applicable only if you have configured a secure cluster.

To install the CP in the silent mode
-----------------------------------:

Perform the following steps:

[1] Double-click the CP executable file to start the CP installation. 

The installer performs the following tasks:
    - Extracts all the individual hotfix executable files
      The files are extracted at %commonprogramfiles(x86)%\Veritas Shared\WxRTPrivates\<HotfixName>
    - Runs the pre-install tasks
    - Installs all the hotfixes sequentially
    - Runs the post-install tasks
The installation progress status is displayed in the command window.

[2] After all the hotfixes are installed, the installer prompts you to restart the system.
Type Y to restart the system immediately, or type N to restart the system later. 
You must restart the system for the changes to take effect.

Note that the installer prompts for a system restart only if hotfixes that require a reboot are included in the CP and are installed.

To install the CP using the command line
----------------------------------------:

Use the VxHFBatchInstaller.exe utility to install a CP from the command line.
The syntax options for this utility are as follows:

vxhfbatchinstaller.exe /CP:<CPName> [/PreInstallScript:<PreInstallScript.pl>] [/silent [/forcerestart]]

where,
    - CPName is the cumulative patch executable file name without the platform, architecture, and .exe extension.
For example, if CP executable name is CP6_VCSW_61_W2K12_x64.exe, specify it as CP6_VCSW_61.

    - PreInstallScript.pl is the Perl script that includes the pre-installation steps. These steps forcefully kill the required services and processes in case a graceful stop request does not succeed.
    Symantec recommends that you use this option and script only in case the CP installer fails repeatedly while performing the pre-installation tasks.

    - /silent indicates the installation is run in a non-verbose mode; the installer does not prompt for any inputs during the installation.

    - /forcerestart indicates that the system is automatically restarted, if required, after the installation is complete.


Perform the following steps:
[1] From the command prompt, navigate to the directory where the CP executable file is located and then run the file to extract the contents to a default location on the system. 
The installer displays a list of hotfixes that are included in the CP.
    - On 64-bit systems, the hotfixes executable files are extracted to:
      "%commonprogramfiles(x86)%\Veritas Shared\WxRTPrivates\<CPName>"
      
[2] In the same command window, run the following command to begin the CP installation in the silent mode:
vxhfbatchinstaller.exe /CP:<CPName> /silent

For example, to install a VCSW 6.1 CP for Windows Server 2012, the command is:
vxhfbatchinstaller.exe /CP:CP6_VCSW_61 /silent

The installer performs the following tasks:

    - Extracts all the individual hotfix executable files
      The files are extracted at %commonprogramfiles(x86)%\Veritas Shared\WxRTPrivates\<HotfixName>
    - Runs the pre-install tasks
    - Installs all the hotfixes sequentially
    - Runs the post-install tasks
The installation progress status is displayed in the command window.

[3] After all the hotfixes are installed, the installer displays a message for restarting the system.
You must restart the system for the changes to take effect.

Note that the installer prompts for a system restart only if hotfixes that require a reboot are included in the CP and are installed. The installer automatically restarts the system if you had specified the /forcerestart option in step 2 earlier.

VxHFBatchInstaller usage example
---------------------------------:

[+] Install CP in silent mode, restart automatically:

vxhfbatchinstaller.exe /CP:CP6_VCSW_61 /silent /forcerestart


Known issues
============|
There are no known issues identified in this CP.

-------------------------------------------------------+


REMOVING THE PATCH
------------------
NO


SPECIAL INSTRUCTIONS
--------------------
This fix is provided without warranty of any kind including the warranties of title or implied warranties of merchantability, 
fitness for a particular purpose and non-infringement. Symantec disclaims all liability relating to or arising out of this fix. 
It is recommended that the fix be evaluated in a test environment before implementing it in your production environment. 
When the fix is incorporated into a Storage Foundation for Windows maintenance release, the resulting Hotfix or Service Pack 
must be installed as soon as possible. Symantec Technical Services will notify you when the maintenance release (Hotfix or Service Pack) 
is available if you sign up for notifications from the Symantec support site http://www.symantec.com/business/support and/or 
from Symantec Operations Readiness Tools (SORT) http://sort.symantec.com.

Additional notes
================|

[+] To confirm the list of cumulative patches installed on a system, run the following command from the directory where the CP files are extracted:
vxhfbatchinstaller.exe /list

The output of this command displays a list of cumulative patches and the hotfixes that are installed as part of a CP. 
This command also displays the hotfixes that are included in a CP but are not installed on the system.

[+] To confirm the installation of the hotfixes, perform one of the following:
    - Run the following command:
      vxhf.exe /list
      The output of this command lists the hotfixes installed on the system.
    - In the Windows Add/Remove program, click "View installed updates" to view the list of the hotfixes installed on the system.

[+] To confirm the latest cumulative patch installed on a system, run the following command from the directory where the CP files are extracted:
vxhfbatchinstaller.exe /cplevel

The output of this command displays the latest CP that is installed, the CP status, and a list of all hotfixes that were a part of the CP but not installed on the system.

[+] The CP installer (vxhfbatchinstaller.exe) creates and stores logs at:
"%allusersprofile%\Veritas\VxHF\VxHFBatchInstaller.txt"

[+] The hotfix installer (vxhf.exe) creates and stores logs at:
"%allusersprofile%\Veritas\VxHF\VxHF.txt"

[+] For general information about the hotfix installer (vxhf.exe), please refer to the following technote:
http://www.symantec.com/docs/TECH73446

[+] To view a list of hotfixes already installed on a system, please refer to the steps mentioned in the following technote:
http://www.symantec.com/docs/TECH73438

[+] For information on uninstalling a hotfix, please refer to the following technotes:
http://www.symantec.com/docs/TECH225604
http://www.symantec.com/docs/TECH73443

[+] For general information about the CP, please refer to the following technote:
http://www.symantec.com/docs/Tech225573


OTHERS
------
NONE