I still think TSM provides the necessary facilities to deal with the problem, WITHOUT having to know/compromise/reset/muck with the password.
When your client node was registered with TSM, YOU SHOULD HAVE HAD a TSM admin id created for it. Ask your TSM support group to give you the password for that admin id. Or ask them to create the admin id for you; it only has CLIENT OWNER privilege, so you can't do any harm to anyone else's stuff with it. Then you can go to your recovery machine, start dsm with -virtualnodename. When the prompt pops up for the password, OVERRIDE the node name with your admin id, and use your admin id password. YOU DON"T NEED the client password. And when the admin id password expires, you get prompted to change it, that one doesn't get generated automatically. It isn't involved in the use of the scheduler. If your TSM admin group doesn't want you to have the admin id with CLIENT OWNER privilege, well, that's a policy question, not a technical one.... -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Chris Rodgers Sent: Thursday, December 16, 2004 3:09 PM To: [EMAIL PROTECTED] Subject: Re: Passwordaccess Generate > Can't remember if you have to restart the scheduler, I don't think so. > (And yes, that's a hassle for you, too. You may want to stick with SET > ACCESS as a solution, if your admins require frequent changes.) OK, I'll try it like that. Do you think that perhaps future versions might see the password storing and password changing features split into two options? It's no problem not to be able to recover the password iff the system doesn't change it automatically i.e. only the storing option enabled. Similarly, at many sites, it's no problem to have no-one know the password and just reset it if it's ever needed so both options would be enabled. Finally, some people may feel their machine very insecure and not want to store the password at all, i.e. neither option enabled. This should satisfy both your security and my usability concerns. Chris.