Re: Error writing registry password

[Andrew Raibeck]

The node passwords are encrypted into subkey
HKLM\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\\

where  is the name of the node, and  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  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/[EMAIL PROTECTED]
Internet e-mail: [EMAIL PROTECTED]

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" <[EMAIL PROTECTED]> 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.

Re: Error writing registry password

[Bill Boyer]

HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes

then under that is the NODENAME. Under the nodename is the TSM server name.
That has the encrypted password in it.

Searching Microsoft, there is no hit for the RegCreatePathEx() API function.
and the Win32 return code 2 is "The system cannot find the file specified.
". Any errors in the event log for that server?

Searching IBM only gives APAR IC30896 that has to do with more that 50 TSM
services being installed using DSMCUTIL.

Bill Boyer
DSS, Inc.


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Thomas Denier
Sent: Tuesday, November 16, 2004 1:50 PM
To: [EMAIL PROTECTED]
Subject: Error writing registry password


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.