Author name: Lance Yoon

It will be very challenging to run TSM operation when TSM client options are all physically stored on TSM client end such as /opt/tivoli/tsm/client/ba/bin/dsm.sys for Unix/Linux or C:\Program Files\Tivoli\TSM\baclient\dsm.opt for Windows especially when there are hundreds of TSM client machines. Unfortunately, this is very normal configuration because many of TSM environment treat this as a default behavior. For example, you want to have certain folders or files to exclude a backup on Windows machine from tonight and this must be all across the board, Now you have to manually RDP login to every single Windows machines to update. What if there are several hundreds of Windows servers, Or you may use script from SCCM to push the configuration but it’s a bit risky that you might run into unexpected situation and very hard to roll back. It is very hard to control and visualize when TSM client options are all dispersed on TSM clients. Below is how to centrally manage TSM client options on TSM server.

At first, it requires to build the same name of TSM instance before you starting to recover TSM database. For rebuilding TSM instance on the server, refer to How to create TSM server instance (IBM Spectrum Protect Version 8). Now assuming that you have completed building TSM instance as the same name that you’re recovering, here’re the steps how to recover TSM server database. The procedure may apply to multiple versions of IBM Spectrum Protect from 6 to latest.

Here is the procedure of how to create IBM TSM server instance. The procedure was written based on the version 8 of IBM Spectrum Protect Version. But the procedure can apply to version 7 as well as the later version. Usually, you can use the procedure after TSM server newly installed and more often, use this procedure when running TSM server disaster recovery. Before executing TSM server database recovery process (dsmserv restore db), the same name of TSM instance should be ready as an empty vessel.

Here’re very simple steps of configurating TSM node replication between source/target TSM server. There are many options and considerations that you need to dive in to fully understand and implement the solution suited to your needs but this page focused on introducing just quick steps of TSM node replication. You can note the below configuration variables that are being used/described for the details procedures below.

ANR8583E An SSL socket-initialization error occurred on session 12. The GSKit return code is 414 GSK_ERROR_BAD_CERT.
ANR8599W The connection with srctsm01.mydomain.com:45274 failed due to an untrusted server certificate. An attempt to reconnect and establish certificate trust might follow.

This is new requirement from TSM server version 8 which implements SSL certificates on both ends. This not only strengthen a security posture for TSM server and client communication but also TSM server to server communication. If you had been running node replication successfully before version 8, However, after version upgrade, now you might notice the entire node replication failure due to SSL certificate error. No worries! Here’re the steps to exchange and properly install TSM server certificates on both source and target TSM servers.

gsk8capicmd_64 -cert -add -label 192.168.0.12 -db cert.kdb -stashed -file /tmp/cert256.arm