DevOps · K8s · Volleyball · Travel  •  DevOps · K8s · Volleyball · Travel  •  DevOps · K8s · Volleyball · Travel
Explore NY Stream

Tivoli Storage Manager Client Install on Windows

— ny_wk

Tivoli Storage Manager Client Install on Windows

Installing the IBM Tivoli Storage Manager (TSM) Backup-Archive Client on Windows means running the installer, generating a working dsm.opt options file that points at your backup server, registering the scheduler as a Windows service, and enabling Open File Support so in-use files back up cleanly. This guide walks the full process end to end, fixes the common mistakes from older install notes, and verifies the result.

One important note before you start: Tivoli Storage Manager has been renamed. IBM rebranded TSM to IBM Spectrum Protect in 2015, and again to IBM Storage Protect in 2022. The product, the client architecture, and the dsm.opt options file described here are essentially the same across all three names, so this procedure applies whether your environment still says "Tivoli" on the splash screen or shows the newer branding. Where the modern client behaves differently, it is called out below.

Before you install the TSM Backup-Archive Client

The TSM Backup-Archive Client is the agent that runs on each protected machine. It talks to a central TSM/Storage Protect server over TCP/IP, sends backup data to the server's storage pools, and restores it on demand. Get these prerequisites lined up first so the installation does not stall halfway through:

  • Match the architecture to your OS, not the server. Install the 64-bit client on 64-bit Windows and the 32-bit client on 32-bit Windows. Older notes told you to match the server's bit-width — that is wrong. The client architecture must match the local operating system.
  • Server hostname or IP and port. You need the address of the TSM server and its client communication port. The default port is 1500, not 1581 — confirm the real value with your backup administrator.
  • A registered node name and password. Every client is a node on the server. Either the admin pre-registers the node, or the server allows open registration so the client registers itself on first contact. Note the exact node name and password.
  • Local administrator rights on the Windows machine, since the install creates services and writes to Program Files.
  • A maintenance window if Open File Support or journaling is involved, because a reboot is required at the end.

Step 1: Run the installer and select components

Modern clients ship as a single self-extracting package; legacy media used an autorun menu. Either way the flow is the same.

  1. Launch the installer. If installing from a disc that does not autostart, browse the media and run setup.exe (or the extracted install.bat on newer builds) as administrator.
  2. Choose your language at the prompt and click OK.
  3. On the installer welcome screen, choose Install Products (legacy launcher) or simply click Next on the InstallShield wizard.
  4. Select TSM Backup-Archive Client for your platform. On the feature tree, expand it and confirm the core Backup-Archive Client GUI and Command Line feature is set to install.
  5. If you intend to use journaling or Open File Support, also tick the Journal Engine and the Open File Support / Logical Volume Snapshot Agent features now. They can be added later, but selecting them up front saves a second pass.
  6. Click Next, then Install, and let it finish.
  7. Do not reboot yet if prompted — you still need to build the options file and register services. Reboot once at the very end.

Step 2: Build the dsm.opt options file with the configuration wizard

The heart of any TSM Backup-Archive Client install is the dsm.opt options file. It tells the client which server to contact, on which port, and as which node. Launch the GUI from Start > All Programs > Tivoli Storage Manager (or IBM Storage Protect) > Backup Archive GUI. On first run the client detects no configuration and opens the Client Configuration Wizard.

  1. When the wizard lists components, accept the default selection and click Next.
  2. Choose Create a new options file and click Next.
  3. For the node name, the machine's hostname is a sensible default. Confirm it matches the node registered on the server, then click Next.
  4. Select TCP/IP as the communication method and click Next.
  5. Enter the server address (hostname or IP, for example 172.17.76.61) and the server port. Use the real port your admin gave you — the documented default is 1500. Click Next.
  6. Review the summary and click Finish to write the file.

The wizard saves dsm.opt to the client's baclient folder, typically C:\Program Files\Tivoli\TSM\baclient\dsm.opt (or ...\IBM\SpectrumProtect\baclient\ on newer installs). A minimal working file looks like this:

  1. NODENAME WIN-SERVER01
  2. COMMMETHOD TCPip
  3. TCPSERVERADDRESS 172.17.76.61
  4. TCPPORT 1500
  5. PASSWORDACCESS generate

Set a node password, not a reused secret. Older guides told you to make the password identical to the node/host name. Do not do that — it is a predictable, insecure choice. Use a strong, unique password. With PASSWORDACCESS generate in the options file, the client stores the encrypted password locally after the first successful login, so the scheduler can run unattended without prompting.

Step 3: Run the first manual backup to register and verify

Before automating anything, prove the client can reach the server. From the GUI click Backup, expand the tree, tick a small folder, and click Backup. On first contact the client prompts for the node password; if the server uses open registration, this is also where the node is created. A successful run that ends with "Backup completed" confirms three things at once: networking is correct, the credentials are valid, and the node is active on the server.

To do the same thing from the command line, which is the fastest way to test, run:

  1. cd "C:\Program Files\Tivoli\TSM\baclient"
  2. dsmc query session (confirms it can talk to the server)
  3. dsmc incremental C:\temp (runs a real incremental backup of a test folder)

Step 4: Install the Web Client (optional)

The Web Client lets an administrator launch an ad-hoc backup or restore against this node from a browser without sitting at the console. It is genuinely handy for help-desk-driven restores, but it is optional — skip it if you do not need remote control.

  1. In the configuration wizard, choose to install the Web Client agent (the Client Acceptor, or CAD).
  2. Accept the default web port unless it conflicts with another service.
  3. Set the agent to start automatically when Windows boots so it is always reachable.
  4. Provide the node password when asked and click Next, then Finish.

A note on security: the legacy Web Client serves over HTTP and is unauthenticated by modern standards. On the current IBM Storage Protect client this component is deprecated in favor of the Operations Center and the command line. If you are on a recent release, prefer those tools and leave the Web Client off.

Step 5: Register the TSM Scheduler as a Windows service

For backups to run on a schedule defined by the server, the client needs the scheduler running as a Windows service. This is the single most important automation step — without it, nothing runs unattended.

  1. In the wizard, choose Install a new scheduler.
  2. Name the service clearly, for example TSM Scheduler (or TSM Client Scheduler). A descriptive name makes it easy to find later in services.msc.
  3. Accept the default location of the options file (the dsm.opt you just built).
  4. Enter the node password so the service can authenticate.
  5. Set Automatically when Windows boots so the scheduler survives reboots.
  6. Decide on event logging. The old advice to uncheck event logging is fine for quiet servers, but on production systems it is usually better to enable logging to a file so you can troubleshoot failed backups. At minimum keep the scheduler's own log, dsmsched.log.
  7. Click Next and Finish.

You can create the same service from the command line, which is repeatable across many machines:

  1. dsmcutil install /name:"TSM Scheduler" /node:WIN-SERVER01 /password:YourStrongPassword /autostart:yes

Step 6: Install the Journal Engine (optional, for performance)

The Journal Engine monitors the filesystem and records which files change, so an incremental backup only has to inspect the journal instead of scanning every directory. On volumes with millions of files this dramatically shortens backup windows.

  1. In the wizard, choose to install the Journal Engine service and click Next.
  2. Select the drives or partitions to journal. Journaling is most useful on local data volumes with large or volatile file counts; there is little benefit to journaling tiny or rarely changing volumes.
  3. Accept the default location for journal files unless that drive is short on space. Journals can grow, so place them on a volume with headroom.
  4. Accept the default include/exclude filters unless you have a specific need to change them.
  5. Set a size limit per journaled partition. By default a journal can grow to roughly 1 GB per partition if left uncapped. Pick a cap that fits the free space on the chosen location.
  6. Confirm the service is set to start automatically, click Next, and Finish.

Step 7: Enable Open File Support to back up in-use files

Windows locks files that applications hold open, and a normal backup either skips them or copies an inconsistent version. Open File Support (OFS) solves this by taking a point-in-time snapshot of the volume — using the Logical Volume Snapshot Agent (LVSA) or, on modern clients, the built-in Volume Shadow Copy Service (VSS) — and backing up the frozen snapshot instead of the live files.

  1. In the wizard, install the Logical Volume Snapshot Agent / Open File Support component and finish the prompts. One snapshot agent supports open-file backups; the related image agent supports full-volume image backups.
  2. Reboot the workstation or server now. The snapshot driver loads at boot, so OFS is not active until you restart.

After the reboot, finish the configuration by editing dsm.opt. Add an INCLUDE.FS statement for each volume that should use snapshot-based backups, and point each one's snapshot cache at a different drive so the cache never lives on the volume it is protecting:

  1. INCLUDE.FS C: fileleveltype=snapshot snapshotcachelocation=F:\tsmlvsa
  2. INCLUDE.FS F: fileleveltype=snapshot snapshotcachelocation=C:\tsmlvsa

TSM needs the cache location to hold the original blocks of any file that changes mid-backup, which is how it presents a consistent point-in-time copy. The rules are simple:

  • Use one INCLUDE.FS line per volume, with the correct drive letters for your machine.
  • Never put a volume's snapshot cache on itself. Point C: at a cache on another drive and vice versa.
  • For three or more volumes, copy a line for each drive letter and give each a cache on a different drive.
  • Remove any leading comment markers (the old notes left stray asterisks on these lines), save the file, and restart the TSM Scheduler service so the new options take effect.

    • Restart the scheduler from an elevated prompt:

    1. net stop "TSM Scheduler"
    2. net start "TSM Scheduler"

    Common pitfalls when installing the TSM client

    Most failed installs trace back to a handful of repeat offenders. Watch for these:

    SymptomLikely cause and fix
    Client cannot connect to the serverWrong TCPPORT or address in dsm.opt. Confirm the real port (default 1500) and that a firewall allows it.
    Scheduler service starts then stopsWrong node password or missing PASSWORDACCESS generate. Re-run dsmcutil update with the correct password.
    Open files are skippedOFS not active — you skipped the post-install reboot, or the INCLUDE.FS lines are still commented out.
    Snapshot fails with cache errorsSnapshot cache pointed at the same volume being backed up, or the cache drive is out of space. Move the cache to another drive.
    Wrong-architecture client32-bit client on 64-bit Windows (or vice versa). Reinstall the build that matches the local OS.
    Node already registered elsewhereTwo machines share a node name. Each protected machine needs its own unique node.

    Verify the installation works end to end

    An install is not finished until you have proven that scheduled, snapshot-aware backups actually run. Verify in this order:

    1. Services are running. Open services.msc and confirm TSM Scheduler (and the Journal Engine / Client Acceptor if installed) show Running and Automatic.
    2. The client reaches the server. Run dsmc query session from the baclient folder; it should return server name, policy domain, and a clean session.
    3. A schedule is bound. Run dsmc query schedule to confirm the node has an associated backup schedule from the server.
    4. Open File Support is active. Run a backup and check dsmsched.log for snapshot messages; confirm in-use files are backed up rather than skipped.
    5. A restore actually works. The only real proof of a backup is a restore. Restore a test file from the server with dsmc restore C:\temp\testfile.txt C:\temp\restored\ and compare it to the original.

    When all five pass, the client is correctly installed, automated, and protecting open files — and you have confirmed the data is genuinely recoverable.

    Key Takeaways

    • Match the client architecture to the local Windows OS (32- or 64-bit), not to the server.
    • The dsm.opt options file drives everything — node name, server address, and the correct port (default 1500); use a strong, unique node password, never the hostname.
    • Register the TSM Scheduler as a Windows service set to start automatically, or no backup ever runs unattended.
    • Open File Support requires a post-install reboot plus INCLUDE.FS lines whose snapshot cache lives on a different drive than the volume being backed up.
    • TSM is now IBM Storage Protect (formerly Spectrum Protect); the procedure is the same, but prefer VSS and the Operations Center over the deprecated legacy Web Client.

    Frequently Asked Questions

    What is the difference between Tivoli Storage Manager, Spectrum Protect, and Storage Protect?

    They are the same product under three names. IBM sold it as Tivoli Storage Manager (TSM), renamed it IBM Spectrum Protect in 2015, and renamed it again to IBM Storage Protect in 2022. The Backup-Archive Client, the dsm.opt options file, and the dsmc command line carry forward across all three.

    Which TCP port does the TSM Backup-Archive Client use?

    The client connects to the server's communication port, which defaults to 1500. Some environments use a custom port, so always confirm the value with your backup administrator and set TCPPORT in dsm.opt to match.

    Why are my open or in-use files being skipped during backup?

    By default Windows backups cannot copy locked files. You must enable Open File Support, reboot so the snapshot driver loads, and add an INCLUDE.FS line with a snapshotcachelocation on a different drive for each affected volume. After editing dsm.opt, restart the TSM Scheduler service.

    How do I confirm the TSM client is actually backing up?

    Run dsmc query session to confirm connectivity, dsmc query schedule to confirm a schedule is bound, and check dsmsched.log for completed runs. The definitive test is a real restore with dsmc restore — if you can recover a file, the backup is valid.

    For more Windows server and system-administration walkthroughs, subscribe to our YouTube channel @explorenystream.