The node passwords are encrypted into subkey
HKLM\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\<nodename>\<servername>

where <nodename> is the name of the node, and <servername> is the TSM
server name (as shown by the admin QUERY STATUS command). The

I would try the following:

1) Make sure you're logged in as a local administrator.

2) Clean out the <nodename> subkey in the registry.

3) Set PASSWORDACCESS PROMPT in the options file.

4) Start the client. When prompted for the password, make sure you can
connect, then quit.

5) Change PASSWORDACCESS back to GENERATE.

6) Start the client. Enter the password when prompted, then quit.

Does it work?

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 11/16/2004
11:49:44:

> We have a Windows NT client running 5.1.7.0 client code that cannot
> perform scheduled backups. As far as I can tell, the underlying problem
> is that all attempts to write the encrypted password to the registry
have
> failed. Attempts to create or update the scheduler service generate
> messages about errors storing the password. When the service is started
> it stops almost immediately, reporting error 1067. A manually triggered
> backup prompts for a password and writes the following to the client
error
> log:
>
> WritePswdToRegistry(): RegCreatePathEx(): Win32 RC=2
>
> along with a number of similar messages about problems reading the
password.
> The system administrator for the client has tried all of the following:
>
> Removing and reinstalling the service
> Verifying permissions on files and registry keys
> Using different administrator IDs
> Using different TSM passwords
> Removing the client software, removing all registry keys that appeared
to
>  be related to TSM, and reinstalling the software
>
> None of these have resolved the problem. Does anyone know of a fix for
this
> problem? Failing that, does anyone know what registry key the password
is
> stored in? Knowing that would enable us to undertake a more focused
search
> for problems with registry permissions.