We just discovered  a bug in dsmcutil which causes the registry password of a
cluster node
 to be encrypted  incorrectly.

The backup clients (scheduler, command line, GUI, etc.) expect cluster node
passwords to
be encrypted with a different seed key than non-cluster node passwords, and I
overlooked
changing dsmcutil to reflect this so any password generated for a cluster node
by dsmcutil
will be invalid.

When the client password access mode is set to generate (which it always is for
the scheduler service)
and the generated password isn't valid (authentication with the ADSM server
fails) the password file
(registry entry in the case of NT) is always deleted.

Interactive clients such as dsmc will then prompt the user to enter a valid
password and then
regenerate the encrypted password file/registry entry.

This explains why issuing an interactive command (i.e. dsmc q sess) causes the
problem to go away.

Obviously the scheduler service can't prompt for a new password  (it is
non-interactive), so it will write a message
to the eventlog indicating that the password validation failed and will try to
restart the scheduler
several time at 20 minute intervals.

So until a fix is available the workaround is to use an interactive client to
generate the clusternode password as
described above.


Pete Tanenhaus
ADSM NT Client Development
email: tanenhau AT us.ibm DOT com



---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 06/11/99
02:53 PM ---------------------------
02:53 PM ---------------------------


Gerard Luechinger <gluech AT osys DOT ch> on 06/11/99 12:22:35 PM

Please respond to gluech AT osys DOT ch

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Pete Tanenhaus/San Jose/IBM)
Subject:  Re: Error installing 2nd scheduler service