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:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of 
Neil
Schofield
Sent: Wednesday, May 26, 2004 3:06 PM
To: ADSM-L AT VM.MARIST DOT EDU
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