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