Set up for Tivoli Storage Manager (TSM) on a Microsoft Cluster. There are two choices:
1. The backups should always point to an option file with the ClientNode and Password in the option file. When you failover a node of the cluster, the option file should change so it is pointing at the correct physical named server.
-OR-
2. Install the TSM client on the virtual node, make sure all of its files go to each of the nodes and the client node name will never change because it is set up as the virtual node name.
When installing to the virtual node, the same exact dsm.opt file must exist on each cluster node. Then each cluster node will try to use the same TSM client node name. This is dependant on the client node name is in the dsm.opt file. TSM does not like the node name to be the same as the physical machine name if passwordaccess generate is set. So the node name depends on if the passwordaccess generate set and clusternode set to yes (both of those are in the dsm.opt file).TSM likes the client node name on a cluster to be the cluster network name (in cluster administrator, right click on the cluster name resource, properties, and then the parameters tab)
TSM supports a "PASSWORDACCESS generate" mode. After PASSWORDACCESS generate is added to the Tivoli dsm.opt options file then the very next connection cannot pass in the client node name, but must pass in the password. That password is then tied to the client node name that is either specified in the dsm.opt file on the NODENAME line, or determined by TSM for that client computer. The password is encrypted and stored in the registry for that client node name.
Thereafter, when connecting to TSM via the TSM Client api, the node name still must not be passed in but the password is then optional. If the password is not passed in then it is used from the registry.
However, the SLS Enterprise Console supports passing in either BOTH the client node name and password, OR neither the client node name and password, but does NOT currently support passing in only the password. Work arounds are as follows:
If "CLUSTERNODE YES" is specified in the dsm.opt file, then the easiest current work around is to connect that first time using TSM's BA client which will be on any machine on which the TSM Client is already installed. BA Client will take the password you provide, encrypt it and store it in the registry, and then EC and SQLLiteSpeed can connect without providing any password.
HOWEVER, if CLUSTERNODE YES is not specified in the dsm.opt file, then TSM ties the password in the registry to not just the client node but also to the calling application’s name. So one cannot then use BA Client to authenticate on behalf of SQLLiteSpeed since they are different applications. SQLiteSpeed must then be given the password that first time it connects.
In this case, with “CLUSTERNODE YES” not specified in the dsm.opt file, the next most straight forward work around is then to
A. temporarily remove the “PASSWORDACCESS generate” line in the dsm.opt file.
B. You should now be able to proceed to do a backup in EC without checking the “PASSWORDACCESS generate” check box on the destination dialog. You may notice on the “Select TSM Object” dialog that the upper half of the window is for reference only. It is primarily used for restore, not backup. Continue with the backup, and then on the final window “View the script” and copy and paste the script in to Query Analyzer or any comparable interface for running SQL Server Queries. Then remove the @tsmclientnode parameter. Do not run yet and you can cancel the EC backup.
C. Then replace the “PASSWORDACCESS generate” in the dsm.opt file and then run the copied script from QA or tsql. TSM will now tie that password with SQLLiteSpeed.exe.
D. You can now check the “PASSWORDACCESS generate” check box in EC wizard and it will be able to connect with no password.
