Password expiration setting on the server is DEFAULT setting only and takes
place when no other setting is defined. For administrators and nodes there
is a setting for password expiration and it takes precedence over the
default server setting. For example on our server password expiration is 90
days (as from installation defaults) but my user is having password
expiration of 0. Same can be set for nodes. And each particular node or
administrator can have its own password expiration period.
For clusters I would recommend you to have three nodes registered - for
node A, for node B and for cluster's virtual node (and I did not invented
this wheel). You can set PASSWORDDir option to point to cluster shared
directory and password problem is solved. But later you will fall in deep
mess for backup of files which are different (and registry also can be
counted there). And you would be able to restore only two nodes A or two
nodes B (or maybe even some very strange combination of both) and change IP
addresses, system files by yourself after restore.

Zlatko Krastev
IT Consultant





Michael Bartl <michael.bartl AT CW DOT COM> on 02.11.2001 10:40:24
Please respond to michael.bartl AT de.cw DOT com
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: Password Expiration

There's no connection between NT passwords and TSM passwords.

For NT: Password expiration is set in NTs userdatabase (on local machine
or domain contr.). When you don't use the system account to run the TSM
scheduler as a service, be sure to set "password does not expire" in the
account settings on NT.

For TSM: Password expiration is set on the TSM server as a global
setting. 0 (zero) means the passwords will not expire, any other number
indicates the number of days until newly set password will expire.
When you use "passwordaccess generate", this only means that the client
maintains its own password: After you type in the initial password, it
gets saved encrypted into a file (unix) or the registry (win32). With
access generate the password may expire without any problems. The client
generates a new password, does the change, saves the password, everythin
is fine.
Problems can come up when you use the same nodename (and password) for
two instances (e.g. two servers in a cluster). With unix you can guide
both of them to the same passwordfile. I don't know how to guide two NTs
to the same registry, so with NT clusters you probably will need to set
expiration to zero or do a trick within tsm like regularly run a script
that updates the password of the node in question before it expires.

Best wishes,
Michael

>       Does anyone have an idea why it keeps expiring on the clients?
>
>       we do have passwordaccess generate within the dsm.opt file too
>
>       any ideas?
>
--
Michael Bartl                               mailto:michael.bartl AT cw DOT com
Michael Bartl                               mailto:michael.bartl AT cw DOT com
Office of Technology, IT Germany/Austria    Tel: +49-89-92699-806
Cable & Wireless Deutschland GmbH.          Fax: +49-89-92699-302
Landsberger Str. 155, D-80687 Muenchen      http://www.cw.com/de