The windows client is using computername to encrypt passwords in registry.
When one changes computername, the stored passwords also become invalid. So
on Windows, you should do the same , i.e. delete (or rename, just in case)
the corresponding registry entries which are currently located under
Unfortunately, there is no TSM command or utility for doing that.
You are right, TSM should not be using wrong encryption key. As a matter of
fact, there is already an APAR - please see IC48782:
It was fixed on Mac in 5.3.4 and is planned to be fixed on unix, linux and
windows in 5.4.0.
TSM Client Development
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/31/2006
> thanks a lot for your detailled explanation ! It's clearer to me now
> ... just only two more questions ?
> What about the windows-Clients - do I then (when changing the
> windows system-name)
> also have to manually remove the equivalent 'TSM.PWD' entry
> in the registry or elsewhere ?
> if so: Is that something to be done with the windows registry-editor
> or is there a tsm-windows-client function that can do for me the
> renaming/refresh of the locally stored tsm-pwds on windows so I can
> the (same) encryption key passord once again ?
> About the 'using some garbage encryption key' : Isn't that something
> where the tsm-client really should say 'NO'
> stop backup and generate an error message ?
> ... preventing the user to have something unrecoverable
> - is there an existing apar ?
> Best regards
> Alexei Kojenov schrieb:
> > Rainer,
> > Your data is always encrypted with the key generated from the password
> > you enter, regardless of the hostname. The hostname is only used to
> > the password locally. For example,
> > 1) Let's say the hostname is 'mercury'
> > 2) You run your first backup and are prompted for encryption key
> > Let's say you enter 'secret'
> > 3) The string 'secret' is encrypted with 'mercury' and is stored in
> > 4) The data are encrypted with 'secret'.
> > 5) On the next backup, the stored password is retrieved from TSM.PWD
> > decrypted with 'mercury', and 'secret' is used for data backup.
> > 6) Let's say you change the hostname to 'venus' and delete/rename
> > TSM.PWD
> > 7) TSM prompts you for encryption key password and you enter 'secret'
> > again.
> > 8) 'secret' is encrypted with 'venus' and is stored in TSM.PWD (note,
> > TSM.PWD will binary differ from the one from step 3, because the key,
> > is dependent on hostname, is different)
> > 9) The data are encrypted with 'secret' (the same as in step 4,
> > of hostname).
> > 10) On the next backup, stored password is decrypted with 'venus', and
> > same password 'secret' is used for backup.
> > So you shouldn't worry about validity of your old backups as long as
> > use the same encryption password and you deleted/renamed TSM.PWD when
> > changing the hostname.
> > The problems come when someone changes the hostname bud does not delete
> > TSM.PWD. In the example above, a backup following the hostname change
> > try to decrypt stored password with 'venus' and will get an incorrect
> > result (because 'secret' was originally encrypted with 'mercury'!), so
> > new backups will be using some garbage encryption key, and it would be
> > really hard to restore the new data correctly if TSM.PWD is lost or if
> > restore happens on a different machine.
> > Alexei
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/27/2006
> > 06:31:17 AM:
> >>Hi Alexei,
> >>thanks for your hint - now i come with a new question concerning the
> >>'restore' :
> >>Because nothing changes other than the 'hostname' of that linux system
> > ...
> >>... what about the data that has been backed up prior to the time
> >>I rename the hostname and reenter the 'encryption key password' ?
> >>Because I stay with 'encryptkey save' what happens when (some time)
> >>I may do a full restore of the '/home/' -Filespace ?
> >>Because this Filespace '/home/' has data backed up that is encrypted
> >>with both encryption-key-usage of the old and the new 'hostname'
> >>( but always the same 'tsm-Nodename' )
> >>... will I am able to restore(and decrypt) all of it ?
> >>... i fear to go into problems - Or do I have to start backup again
> >>from 'zero' - for example :
> >>by renaming the filespace on the server
> >>at the time changing the hostname ?
> >>Thanks again for any hints !
> >>-- that is something really confusing to me :-|
> >>Alexei Kojenov schrieb:
> >>>You need to make TSM client prompt you for encryption key password on
> > the
> >>>next backup after you changed the hostname. The only way to do this is
> > to
> >>>rename/remove the existing TSM.PWD file (this is the file where TSM
> > client
> >>>stores its passwords). You should rename this file rather than delete
> > it,
> >>>in case you have problems and want to revert.
> >>>Dear TSmers,
> >>>we have tsmserver 188.8.131.52 /solaris and tsm-Client 184.108.40.206 /linux.
> >>>On the Client we use tsm-encryption :
> >>>The 'nodename' Option is set in the dsm.sys and also the
> >>>'encryptkey save' OPtion is set and 'encryptiontype AES128' is also
> > set.
> >>>The inclexc-File contains a line like 'include.encrypt *'
> >>>So far anything runs fine :-)
> >>>Problem: Next week we have to change the 'hostname' of that
> > linux-server.
> >>>The Question now is : - if any - what steps are to be done at the
> >>>tsm-Client ?
> >>>... and even at the tsm-server ?
> >>>The (tsm)nodename won't be changed.
> >>>Do I need the TSM-Client in a manual way give once again the
> >>>encryption-key password to let the encryption-key be generated ?
> >>>Or is there nothing to be done at the Client ?
> >>>I have looked throgh the lists and docs and havent't found any
> >>>'procedures' for that scenario - just pointers to dependancies on the
> >>>system's hostname.
> >>>Thanks in advance for any hints , recipe or links ... !