Hi Neil, 1. You're probably right about the /CLUSTERNODE:YES with dsmcutil. I'll try that too, even though I believe that's not the problem.
2. I didn't mention the definition of a generic service cluster resource because that's the next step in the manual. We did that on the previous cluster we had set up and it working fine. We also did this definition on this cluster without testing the backup but the resource was failing, resulting in a loop of moving the group from node 1 to node 2 and vice versa. We managed to stop that from happening and then followed what the manual suggests, i.e. to test that the scheduler is ok by running a test backup step (on model db for example) just to test that it authenticates. And this is where we hit the authentication failure. 3. I'll try to use your third suggestion to change FROMSQLSERVER parameter in the tdpsql.cfg to FUNDTSQL. I believe that there's something wrong with the registry values. Can I safely delete these values using regedit or am I going to corrupt the registry ? Thanks Yiannakis -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Neil Schofield Sent: Wednesday, May 26, 2004 3:06 PM To: [EMAIL PROTECTED] Subject: Re: TSM TDP for MS SQL in a cluster Yiannakis I'm not sure exactly where the problem lies, but would make the following observations: - When using DSMCUTIL INSTALL, you should specify /CLUSTERNODE:YES /CLUSTERNAME:FUNDTCLR on both nodes in addition to specifying CLUSTERNODE YES in the DSM.OPT. - I'm assuming this is an Active/Passive SQL Cluster, ie the SQL Server instance FUNDTSQL is the only instance and can switch between nodes. In this case it's doubtful you want the TDP Scheduler service starting automatically on both nodes. It would be better to specify /AUTOSTART:NO and create a generic cluster service within MSCS Cluster Admin in the same group as the virtual SQL Server. This would then start the Scheduler accoring to which node the SQL Server was running on. - Running scheduler's concurrently on both nodes of the cluster with PASSWORDACCESS set to GENERATE means that upon password expirartion, one node will change the password and cause the service on the other node to fail. With a generic service cluster resource, you can configure the properties of the service to replicate the registry key Software\IBM\ADSM\CurrentVersion\BackupClient\Nodes\FUNDTSQL which is where the encrypted password is stored. - Unless your Virtual SQL Server resource is in the same group as your clustername, you probably want to change the FROMSQLSERVER parameter in the TDPSQL.CNF to FUNDTSQL. Regards Neil Schofield Yorkshire Water Services Ltd. Download walks around Yorkshire Water's reservoirs at http://www.yorkshirewater.com/yourenjoyment/main_walk.html The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682
