vcs-win_x64-CP9_VCSW_60
Obsolete
The latest patch(es) : vcs-win_x64-CP14_VCSW_60 

 Basic information
Release type: P-patch
Release date: 2013-09-26
OS update support: None
Technote: TECH191975 - Storage Foundation for Windows High Availability, Storage Foundation for Windows and Veritas Cluster Server 6.0 Cumulative Patches
Documentation: None
Popularity: 482 viewed    downloaded
Download size: 16.09 MB
Checksum: 1730144604

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

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

This patch is obsolete. It is superseded by: Release date
vcs-win_x64-CP11_VCSW_60 (obsolete) 2014-02-24
vcs-win_x64-CP10_VCSW_60 (obsolete) 2014-01-06

This patch supersedes the following patches: Release date
vcs-win_x64-CP8_VCSW_60 (obsolete) 2013-08-26
vcs-win_x64-CP7_VCSW_60 (obsolete) 2013-07-29
vcs-win_x64-CP6_VCSW_60B (obsolete) 2013-06-24
vcs-win_x64-CP5_VCSW_60 (obsolete) 2013-04-29
vcs-win_x64-CP4_VCSW_60 (obsolete) 2013-02-27
vcs-win_x64-CP3_VCSW_60 (obsolete) 2012-09-24
vcs-win_x64-CP2_VCSW_60 (obsolete) 2012-08-29

 Fixes the following incidents:
2649700, 2650336, 2695917, 2722108, 2786159, 2882535, 2898414, 3053280, 3062856, 3111155, 3300654, 3300658

 Patch ID:
None.

Readme file
This readme has the following sections:

=====================|
* Date
* OS/Version
* Packages
* Etrack Incidents
* Fixes Applied for Products
* What's new in this CP
* Install instructions
* - Before you begin
* - To install in the verbose mode
* - To install in the non-verbose (silent) mode
* Post-install steps
* Known issues
* Errors/Problems fixed
* Additional notes
* Disclaimer
=====================|

Date: 2013-09-30
OS: Windows
OS Version: 2008, 2008 R2
Packages:

================================================
Architecture/OS	  Windows Server 2008 / 2008 R2
================================================
x64 		      CP9_VCSW_60_W2k8_x64.exe
------------------------------------------------

Etrack Incidents: 
2650336, 2695917, 2722108, 2786159, 2882535, 2898414, 3053280, 3062856, 2649700, 3111155, 3300658, 3300654



Fixes Applied for Products
==========================|
Veritas Cluster Server (VCSW) 6.0 for Windows


What's new in this CP
=====================|

The following hotfixes have been added in this CP:
 - Hotfix_6_0_00024_3300658
 - Hotfix_6_0_00025_3300654
 - Hotfix_6_0_00019_3053280b

For more information about these hotfixes, see the "Errors/Problems fixed" section in this readme.


Install instructions
====================|
Download the appropriate cumulative public patch (CP) executable file to a temporary location on your system.
You can install the CP in a verbose mode or in a non-verbose mode. 
Instructions for both options are provided below.

Each cumulative public patch includes the individual hotfixes that contain enhancements and fixes related to reported issues.
See "Errors/Problems Fixed" 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] 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 and installed CP or Agent Pack 2Q2012 on your system. 

[5] Before installing CP on Windows Server Core systems, ensure that Visual Studio 2005 x86 redistributable is installed on the systems.

To install in the verbose mode
------------------------------:
In the verbose mode, the cumulative public patch (CP) installer prompts you for inputs and displays the installation progress status in the command window.

Perform the following steps:
[1] Double-click the CP executable 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>"

The installer also lists the hotfixes that require a reboot of the system after the installation. 
If system reboot is not an option at this time, you can choose not to install these hotfixes. 
In such a case, exit the installation and then launch the CP installer again from the command line using the /exclude option.
See "To install in a non-verbose (silent) mode" section for the syntax.

[2] When the installer prompts whether you want to continue with the installation; type Y to begin the hotfix installation.
The installer performs the following tasks:
	- Extracts all the individual hotfix executable files
	  On 64-bit systems 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 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 in the non-verbose (silent) mode
-------------------------------------------:
In the non-verbose (silent) mode, the cumulative public patch (CP) installer does not prompt you for inputs and directly proceeds with the installation tasks. 
The installer displays the installation progress status in the command window.

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> [/Exclude:<HF1.exe>,<HF2.exe>...] [/PreInstallScript:<PreInstallScript.pl>] [/silent [/forcerestart]]

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

	- HF1.exe, HF2.exe,... represent the executable file names of the hotfixes that you wish to exclude from the installation. Note that the file names are separated by commas, with no space after a comma. The CP installer skips the mentioned hotfixes during the installation.

	- 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>"

The installer also lists the hotfixes that require a reboot of the system after the installation.
If system reboot is not an option at this time, you can choose not to install these hotfixes. 
In such a case, launch the CP installer from the command line using the /exclude option.

[2] When the installer prompts whether you want to continue with the installation; type N to exit the installer.

[3] In the same command window, run the following command to begin the CP installation in the non-verbose mode:
vxhfbatchinstaller.exe /CP:<CPName> /silent

For example, to install a VCSW 6.0 x64 CP for Windows Server 2008, the command is:
vxhfbatchinstaller.exe /CP:CP9_VCSW_60 /silent

The installer performs the following tasks:
	- Extracts all the individual hotfix executable files
	  On 64-bit systems 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.

[4] 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 3 earlier.


VxHFBatchInstaller usage examples:
----------------------------------
[+] Install CP in silent mode, exclude hotfix Hotfix_6_0_00003_2650336_w2k8_x64.exe:

vxhfbatchinstaller.exe /CP:CP9_VCSW_60 /Exclude:Hotfix_6_0_00003_2650336_w2k8_x64.exe /silent

[+] Install CP in silent mode, restart automatically:
vxhfbatchinstaller.exe /CP:CP9_VCSW_60 /silent /forcerestart


Post-install steps
==================|
The following section describes the steps that must be performed after installing the hotfixes included in this CP.
Note that these steps are applicable only to the hotfixes listed in this section.

[1] HotFix_6_0_00007_2722108 
Perform the following steps only if you have installed HotFix_6_0_00007_2722108 as part of the CP installation.

Setting the DisableServerNameScoping and DisableStrictVirtualNameCheck registry keys 
Perform the following steps to create and set the DisableServerNameScoping and DisableStrictVirtualNameCheck registry keys that are used by the FileShare agent to support non-scoped file shares and disable virtual name availability as a requirement for file shares to be available on the network.

Caution: Incorrectly editing the registry may severely damage your system. Make a backup copy before making changes to the registry.

To configure DisableServerNameScoping and DisableStrictVirtualNameCheck registry parameters:
1. To open the Registry Editor, click Start > Run, type regedit, and then click OK.
2. In the registry tree (on the left), navigate to
HKLM\SOFTWARE\VERITAS\VCS\BundledAgents.
3. Click Edit > New > Key and create a key by the name Lanman, if it does not
exist already.
4. Select Lanman and then click Edit > New > Key and create a key by the name
__GLOBAL__. (underscore-underscore-GLOBAL-underscore-underscore)
5. Select __GLOBAL__ and add a DWORD type and specify Value name as
DisableServerNameScoping and Value data as 1.
The value 1 indicates that the FileShare agent supports non-scoped file shares
on Windows Server 2008 and 2008 R2 systems.
6. Select __GLOBAL__ and add a DWORD type and specify Value name as
DisableStrictVirtualNameCheck and Value data as 1.
Setting this registry value to 1 allows the FileShare agent to make the file
shares available even if the virtual name is not available on the network.
You must create the DisableStrictVirtualNameCheck key parallel to the file share
scoping key DisableServerNameScoping.
7. Save and exit the Registry Editor.

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

[2] Hotfix_6_0_00003_2650336 and Hotfix_6_0_00013_2882535 

If the cluster is not configured before installing this hotfix, the post-install task of modifying the type will fail. In that case, manually run the batch files for the hotfixes after cluster is configured to update the type. You can find the batch file name from the location where the hotfix is extracted.

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


Known issues
============|
The following section describes the issues related to the individual hotfixes that are included in this CP:

[1] The post-installation task of starting the Plugin-Host service fails on Windows Server Core system.

The Plugin-Host service requires that the .NET Framework is present on the system where the service is to be started. As the .NET Framework is not supported on the Windows Server Core systems, the service cannot be started on these systems. Hence for the hotfixes that have the post-installation task of starting the Plugin-Host service, the task fails. This is expected behavior and can be safely ignored.

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


Errors/Problems fixed
=====================|
The fixes and enhancements that are included in this cumulative public patch (CP) are as follows:

[1] Hotfix name: Hotfix_6_0_00003_2650336

Symptom:
This hotfix addresses an issue related to the VCS PrintSpool agent where information about printers that were newly added in the virtual server context is lost in case of a system crash or unexpected failures that require a reboot.

Description:
The PrintSpool agent stores printer information to the configuration during its offline function. 
Therefore if printers are added in the virtual server context but the printspool resource or the printshare service group is not gracefully taken offline or failed over, the new printers information does not get stored to the disk.
In such a case, if the node where the service group is online hangs, shuts down due to unexpected failures, or reboots abruptly, all the new printer information is lost.
The printshare service group may also fail to come online again on the node.

Resolution:
This issue has been fixed in the PrintSpool agent.
A configurable parameter now enables the agent to save the printer information periodically.

A new attribute, 'SaveFrequency', is added to the PrintSpool agent.
SaveFrequency specifies the number of monitor cycles after which the PrintSpool agent explicitly saves the newly added printer information to the cluster configuration.
The value 0 indicates that the agent does not explicitly save the information to disk. 
It will continue to save the printer information during its offline function.
The default value is 5.

Binary / Version:
PrintSpool.dll / 6.0.3.416
PrintSpool.xml / NA

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

[2] Hotfix name: HotFix_6_0_00006_2695917

Symptom:
This hotfix addresses an issue where the VCS engine log is flooded with information messages in case of a network congestion.

Description:
MOMUtil.exe is a VCSAPI client. It uses VCS APIs to get information from VCS and present that to SCOM Server. 
MOMUtil.exe is invoked after every 5 minutes as part of VCS monitoring. 
This connects to the VCS Cluster running on the system and tries to fetch the information to display the current status of service groups. 
In case of a network congestion, the engine is unable to send the data to the client immediately. 

In this scenario, the following information message is logged after every 5 minutes:
Could not send data to peer MOMUtil.exe at this point; received error 10035 (Unknown error), will resend again

The engine successfully sends data to the client (MOMUtil.exe) after some time. 
By this time, the engine log is flooded with the information messages.

Resolution:
The engine has been modified to print the information messages as debug messages. 
So the messages will appear in the engine log only if DBG_IPM debug level is set.

If you need to log the information messages in the engine log, run the following command to set the debug level DBG_IPM:
halog -addtags DBG_IPM

Binary / Version:
had.exe / 6.0.6.425
hacf.exe / 6.0.6.425 

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

[3] Hotfix name: HotFix_6_0_00007_2722108

Symptom:
This hotfix addresses an issue related to the VCS FileShare agent wherein non-scoped file shares are not accessible using virtual server name or IP address if NetBIOS and WINS are disabled.

Description:
VCS FileShare and Lanman agents can support non-scoped file shares on Windows Server 2008 and 2008 R2 systems if the DisableServerNameScoping registry is created and set to 1.
The VCS FileShare agent depends on NetBIOS and DNS to resolve the virtual name.
If NetBIOS and WINS are disabled and the DNS is not updated, the agent is unable to resolve the virtual name. 
This may typically occur when the file share service groups are configured to use localized IP addresses. 
When the service group is switched or failed over, the virtual name to IP address mapping changes. 
In such a case if WINS database and the DNS are not updated, the agent is unable to resolve the virtual name. 
As a result the FileShare resources fault and the shares become inaccessible.

The following message is seen in the agent log:
VCS INFO V-16-10051-10530 FileShare:<servicegroupname>:online:Failed to access the network path (\\virtualname)

RESOLUTION: 
The FileShare agent is enhanced to address this issue. 
The FileShare agent behavior can be controlled using the following registry keys:
- HKLM\SOFTWARE\VERITAS\VCS\BundledAgents\Lanman\__Global__\DisableServerNameScoping
Set the DisableServerNameScoping key to enable non-scoped file share support.

- HKLM\SOFTWARE\VERITAS\VCS\BundledAgents\Lanman\__Global__\DisableStrictVirtualNameCheck
Set the DisableStrictVirtualNameCheck key to have the FileShare agent make the file shares accessible irrespective of whether or not the virtual name is resolvable.
You must manually create these registry keys after installing this hotfix.
See the topic "Setting the DisableServerNameScoping and DisableStrictVirtualNameCheck registry keys" in this readme for more details.

Notes:
- The registry key DisableVirtualNameCheck will take effect only if DisableServerNameScoping key value is set to 1. 
- This FileShare agent behavior is applicable only for non-scoped file shares.
- In the earlier procedure you created these registry keys at the global level.
If there are multiple file share service groups that are to be used in the non-scoped mode, you may have to create these registry keys manually for each virtual server and then set the values.
You must create these keys at the following location:
HKLM\SOFTWARE\VERITAS\VCS\BundledAgents\Lanman\<VirtualName>\.
Here <VirtualName> should be the virtual computer name assigned to the file share server. 
This is the VirtualName attribute of the lanman resource in the file share service group.
- In case these registry parameters are configured at a global level and also configured for individual file share virtual servers, the registry settings for individual virtual servers takes precedence.
- You must create this key only for lanman resources that are part of VCS file share service groups. Configuring this key for lanman resources that are part of other VCS service groups may result in an unexpected behavior.

Binary / Version:
Fileshare.dll / 6.0.7.433

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

[4] Hotfix name: HotFix_6_0_00011_2786159

Symptom:
Issue 1:
This hotfix addresses an issue related to the VCS Cluster Manager (Java Console) where the only the first user in the Cluster Administrator's group is treated as the cluster administrator. All other users in the group do not get cluster administrator privileges and are treated as Guest users.

Issue 2:
This hotfix addresses an issue related to the VCS Cluster Manager (Java Console) where a service group switch or failover operation to the secondary site fails due to a user privilege error. 

Fix for issue #1 was earlier released as Hotfix_6_0_00002_2649700. It is now included in this hotfix.

Description:
Issue 1:
If you add multiple users as Cluster Administrators, the VCS Java Console only treats the first user in the list as an administrator. All the other users are treated as Guest users even though the users are listed as Cluster Administrators in the cluster configuration file.

Issue 2:
This issue occurs in secure clusters set up in a disaster recovery (DR) environment. When you switch or failover a global service group to the remote site, the operation fails with the following error:
Error when trying to failover GCO Service Group. V-16-1-50824 At least Group Operator privilege required on remote cluster.

This error occurs even if the user logged on to the Java Console is a local administrator, which by default has the Cluster Administrator privilege in the local cluster.

This issue occurs because the local administrator is not explicitly added to the cluster admin group at the remote site. During a switch or a failover, the Java Console is unable to determine whether the logged-on user at the local cluster has any privileges on the remote cluster and hence fails the operation.

If you use the Java Console to grant the local administrator with operator or administrator privileges to the remote cluster, the Java Console only assigns guest privileges to that user.

Resolution:
Issue 1:
This issue has been fixed in the Java Console.

Issue 2:
This issue is fixed in the Java Console. The Java Console now allows you to assign the local administrator at the local cluster with cluster admin or cluster operator privileges in the remote cluster.
This change is applicable only on Windows.

Binary Name / Version
VCSGui.jar / NA

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

[5] Hotfix name: Hotfix_6_0_00013_2882535

Symptom:
This hotfix includes the VCS FileShare agent that is enhanced to ensure that the file shares configured with VCS are accessible even if the LanmanResName attribute is not specified.

Description:
File shares configured with VCS come online if the LanmanResName attribute of the Fileshare resource is specified. In case this attribute is not specified, the Fileshare resource would go into an unknown state and would not come online. The Fileshare resource should have the ability to share the folder under physical server context even if LanmanResName attribute is not specified.

Resolution: 
The FileShare agent is enhanced to address this issue. 

Binary / Version: 
FileShare.dll / 6.0.00013.509

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

[6] Hotfix name: HotFix_6_0_00016_2898414

Symptom:
This hotfix addresses an issue where the MSMQ resource failed to bind to the correct port.

Description:
When the MSMQ agent was brought online, the Event Viewer reported an error stating that Message Queuing failed to bind to port 1801. This error could occur due to various reasons. Even though the binding failed, the agent reported the MSMQ resource as Online.

Resolution:
The MSMQ agent has been enhanced to verify that the clustered MSMQ service is bound to the correct virtual IP and port. By default, the agent performs this check only once during the Online operation. If the clustered MSMQ service is not bound to the correct virtual IP and port, the agent stops the service and the resource faults. You can configure the number of times that this check is performed. To do so, create the DWORD tunable parameter 'VirtualIPPortCheckRetryCount' under the registry key 'HKLM\SOFTWARE\VERITAS\VCS\BundledAgents\MSMQ'. If this parameter is set to a value greater than 1, the agent starts the clustered MSMQ service again and verifies its virtual IP and port binding as many times. It waits 2 seconds between each verification attempt. If the clustered MSMQ service is bound to the correct virtual IP and port, the agent reports Online.

Binary / Version:
MSMQ.dll / 6.0.00016.534

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

[7] Hotfix name: Hotfix_6_0_00017_2898414

Symptom:
This hotfix addresses an issue where an application resolved a virtual name incorrectly due to DNS lag.

Description:
This issue occurred due to a delay in resolving the DNS name. For example, MSMQ resolved a virtual name incorrectly. Therefore, when the MSMQ agent was brought online, the Event Viewer reported an error stating that Message Queuing failed to bind to the appropriate port.

Resolution:
The Lanman agent has been enhanced to verify the DNS lookup and flush the DNS resolver cache after bringing the Lanman resource online. You need to create the DWORD tunable parameter 'DNSLookupRetryCount' under the registry key 'HKLM\SOFTWARE\VERITAS\VCS\BundledAgents\Lanman'. If this parameter is set, the Lanman agent verifies the DNS lookup as per the parameter value. It waits 5 seconds between each verification attempt. You can also create the DWORD tunable parameter 'SkipDNSCheckFailure' under the Lanman registry key. The default value of 'SkipDNSCheckFailure' is 0 (zero), which indicates that the resources should fault if the DNS lookup fails. If this parameter value is set to 1, the resources should not fault even if the DNS lookup fails. 

Binary / Version:
Lanman.dll / 6.0.00017.534

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

[8] Hotfix name: HotFix_6_0_00019_3053280b

Symptom:
Windows Server Backup fails to perform a system state backup with the following error: 
Error in backup of C:\program files\veritas\\cluster server\ during enumerate: Error [0x8007007b] The filename, directory name, or volume label syntax is incorrect.

Description:
The backup operation fails because the VCS service image path contains an extra backslash (\) character, which Windows Server Backup is unable to process.

Resolution:
This issue has been fixed by removing the extra backslash character from the VCS service image path. 
This hotfix changes the following registry keys: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Had\ImagePath 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HADHelper\ImagePath 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Cmdserver\ImagePath 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VCSComm\ImagePath

Binary / Version:
NA / NA

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

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

[9] Hotfix name: Hotfix_6_0_00020_3062856 

Symptom:
If LLT is running alongside a utility like Network Monitor, a system crash (BSOD) occurs when shutting down Windows.

Description:
The system crashes due to a time out that occurs while waiting for LLT to unbind from the adapters during a shutdown operation. This issue occurs when LLT is configured over Ethernet.

Resolution:
The LLT driver has been updated to properly handle unbind calls so that Windows can shut down gracefully.

Binary / Version:
llt.sys / 6.0.00020.625

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

[10] Hotfix name: Hotfix_6_0_00022_ 3111155 

Symptom:
After every 49.7 days, VCS logs report that the Global Counter VCS attribute is not updated. This error is reported on all nodes in the cluster, except the node with the lowest node ID value. The 'GloablCounter not updated' error also appears in the Event Viewer.

Description:
The error indicates that there could be communication issue between the cluster nodes. However, this error is incorrectly reported, and no communication issue actually occurs.

Resolution:
This issue has been fixed and the error is no longer reported at that odd interval. 

Binary / Version:
had.exe / 6.0.22.628 
hacf.exe / 6.0.22.628

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

[11] Hotfix name: Hotfix_6_0_00024_3300658

Symptom:
When NetBios is disabled, a FileShare service group fails to come online.

Description:
This issue occurs if the value of the VirtualName attribute in the Lanman resource is specified in lower case characters, and NetBios is disabled. The Lanman resource faults and therefore the FileShare service group fails to come online.

Resolution:
The hotfix addresses this issue, and now, the FileShare service group comes online successfully.

Binary / Version:
FileShare.dll / 6.0.24.694

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

[12] Hotfix name: Hotfix_6_0_00025_3300654

Symptom:
If the cluster name string in the registry and the main.cf file is not an exact match, upgrading to SSO authentication or reconfiguring SSO fails. However, the operation is incorrectly reported to be successful.

Description:
The upgrade or reconfiguration fails because, even though the other configuration settings are updated correctly, the SecureClus cluster attribute is not set to 1 (true).

Resolution:
The hotfix addresses this issue, and now you can successfully upgrade to SSO authentication or reconfigure SSO even if there is a case mismatch in the cluster name string recorded in the registry and the main.cf file.

Binary / Version:
VCWDlgs.dll / 6.0.25.694

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


Additional notes
================|
[+] To confirm the list of 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 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.

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

[+] The hotfix installer (vxhf.exe) creates and stores logs at:
"%allusersprofile%\Application Data\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 steps mentioned in the following technote:
http://www.symantec.com/docs/TECH73443


Disclaimer
==========|
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.