Chapter 11.

Managing Client Nodes

This chapter contains information about managing client nodes that have been installed and configured. For information about installing and configuring client nodes, see Chapter 10, Adding Client Nodes. Note: The Tivoli Storage Manager server views its registered clients, application clients, and source servers as nodes. In a general sense, the server considers all of these entities as a client. The term nodes in this chapter refers to the following type of clients and servers as client nodes: Tivoli Data Protection application clients Tivoli Storage Manager backup-archive client Tivoli Storage Manager source server registered as a node on a target server Network-attached storage (NAS) file server using Tivoli Data Protection for NDMP support

Administrators can manage client nodes and control their access to the server. See the following sections for more information:
Tasks: "Managing Nodes" "Managing Client Access Authority Levels" "Managing File Spaces" "Modifying Client Option Files" "Managing Tivoli Storage Manager Sessions" "Managing Tivoli Storage Manager Security" Concepts: "Overview of Client Nodes and File Spaces"

In this chapter, most examples illustrate how to perform tasks by using a Tivoli Storage Manager command-line interface. For information about the commands, see Administrator's Reference, or issue the HELP command from the command line of a Tivoli Storage Manager administrative client. Tivoli Storage Manager tasks can also be performed from the administrative Web interface. For more information about using the administrative interface, see Quick Start.

Managing Client Node Registration Techniques

By default, Tivoli Storage Manager provides closed registration as the technique for registering client nodes. Administrators can modify the default with the SET REGISTRATION command. For more information about open and closed registration, see Accepting Default Closed Registration or Enabling Open Registration.

Managing Nodes
From the perspective of the server, each client and application client is a node requiring Tivoli Storage Manager services. For information, see Overview of Client Nodes and File Spaces. Client nodes can be local or remote to the server. For information, see Comparing Network-Attached Nodes to Local Nodes. Administrators can perform the following activities when managing client nodes.
Task Updating, renaming, locking, or unlocking any client nodes Updating, renaming, locking, or unlocking client nodes assigned to specific policy domains Displaying information about client nodes or file spaces Deleting any client nodes Removing client nodes assigned to specific policy domains Managing client access authority levels Required Privilege Class System or unrestricted policy System, unrestricted policy, or restricted policy for those domains Any administrator System or unrestricted policy System, unrestricted policy, or restricted policy for those domains System

Updating Client Node Information

You can use the UPDATE NODE command to update information such as the client's assigned policy domain, the user's password or contact information, and the client option set used by the node. For example, update client node TOMC to prevent him from deleting archived files from storage pools by entering: update node tomc archdelete=no

Renaming Client Nodes

You can rename a client node with the RENAME NODE command. You may need to rename a client node if the workstation network name or host name changes. For example, with UNIX clients, users define their node name based on the value returned by the HOSTNAME command. When users access the server, their Tivoli Storage Manager user IDs match the host name of their workstations. If the host name changes, you can update a client node user ID to match the new host name. For example, to rename CAROLH to ENGNODE, enter: rename node carolh engnode ENGNODE retains the contact information and access to backup and archive data that belonged to CAROLH. All files backed up or archived by CAROLH now belong to ENGNODE.

Locking and Unlocking Client Nodes

You can prevent client nodes from accessing the server with the LOCK NODE command. This will prevent client nodes from performing functions such as either backup and restore or archive and retrieve. You can restore a locked node's access to the server with the UNLOCK NODE command.

For example, to prevent client node MAB from accessing the server, enter: lock node mab To let client node MAB access the server again, enter: unlock node mab

Deleting Client Nodes

You can delete a client node from the server with the REMOVE NODE command. All file spaces that belong to the client node must first be deleted from server storage. After all of the client node's file spaces have been deleted (see Deleting File Spaces and Client Nodes), you can delete the node. For example, to remove client node DEBBYG, enter: 1. 2. 3. 4. Note: Delete the DEBBYG file space by entering: delete filespace debbyg * type=any Delete the DEBBYG node by entering: remove node debbyg Before you can delete a NAS node, you must first delete any file spaces, then delete any defined paths for the data mover with the DELETE PATH command. Delete the corresponding data mover with the DELETE DATAMOVER command. Then you can issue the REMOVE NODE command to delete the NAS node.

Displaying Information about Client Nodes

You can display information about client nodes. For example, as a policy administrator, you might query the server about all client nodes assigned to the policy domains for which you have authority. Or you might query the server for detailed information about one client node.

Displaying Information about Client Nodes Assigned to Specific Policy Domains

You can display information about client nodes assigned to specific policy domains. For example, to view information about client nodes that are assigned to STANDARD and ENGPOLDOM policy domains, enter: query node * domain=standard,engpoldom The output from that command may display similar to the following:

+-------------------------------------------------------------------------------+ |Node Name Platform Policy Domain Days Since Days Since Locked? | | Name Last Password | | Access Set |

|------------------------------ ------------------------| |DEBBYG DOS STANDARD 2 12 No | |ENGNODE AIX ENGPOLDOM <1 1 No | |HTANG OS/2 STANDARD 4 11 No | |MAB AIX ENGPOLDOM <1 1 No | |PEASE AIX STANDARD 3 12 No | |SSTEINER (?) ENGPOLDOM <1 1 No | | | +-------------------------------------------------------------------------------+

Displaying Information about a Specific Client Node

You can view information about specific client nodes. For example, to review the registration parameters defined for client node JOE, enter: query node joe format=detailed The resulting report may appear similar to the following:

+-------------------------------------------------------------------------------+ | | | Node Name: JOE | | Platform: WinNT | | Client OS Level: 4.00 | | Client Version: Version 3, Release 1, Level 3.0 | | Policy Domain Name: STANDARD | | Last Access Date/Time: 05/19/1999 18:55:46 | | Days Since Last Access: 6 | | Password Set Date/Time: 05/19/1999 18:26:43 | | Days Since Password Set: 6 | | Invalid Sign-on Count: 0 |

| Locked?: No | | Contact: | | Compression: Client's Choice | | Archive Delete Allowed?: Yes | | Backup Delete Allowed?: No | | Registration Date/Time: 05/19/1999 18:26:43 | | Registering Administrator: SERVER_CONSOLE | |Last Communication Method Used: Tcp/Ip | | Bytes Received Last Session: 108,731 | | Bytes Sent Last Session: 698 | |Duration of Last Session (sec): 0.00 | | Pct. Idle Wait Last Session: 0.00 | | Pct. Comm. Wait Last Session: 0.00 | | Pct. Media Wait Last Session: 0.00 | | Optionset: | | URL:http://joe.host.name:1581 | | Node Type: Client | | Password Expiration Period: 60 | | Keep Mount Point?: No | | Maximum Mount Points Allowed: 1 | | Auto Filespace Rename: No | | Validate Protocol: No | | | +-------------------------------------------------------------------------------+

Overview of Remote Access to Web Backup-Archive Clients

With the introduction of the Web backup-archive client, when a client node is registered with a Tivoli Storage Manager 3.7.0 server or above, an identical administrative user ID is created at the same time. This user ID has client owner authority over the node by default.

Enterprise logon enables a user with the proper administrative user ID and password to access a Web backup-archive client from a Web browser. The Web backup-archive client can be used by the client node or a user ID with the proper authority to perform backup, archive, restore, and retrieve operations on any machine that is running the Web backup-archive client. You can establish access to a Web backup-archive client for help desk personnel that do not have system or policy privileges by granting those users client access authority to the nodes they need to manage. Help desk personnel can then perform activities on behalf of the client node such as backup and restore operations. A native backup-archive client can log on to Tivoli Storage Manager using their node name and password, or administrative user ID and password. The administrative user ID password is managed independently from the password that is generated with the passwordaccess generate client option. The client must have the option passwordaccess generate specified in their client option file to enable use of the Web backup-archive client. To use the Web backup-archive client from your web browser, you specify the URL and port number of the Tivoli Storage Manager backup-archive client machine running the Web client. The browser you use (R) to connect to a Web backup-archive client must be Microsoft Internet Explorer 5.0 or Netscape 4.7 or later. The browser must have the Java Runtime Environment (JRE) 1.3.1, which includes the Java Plug-in software. The JRE is available at the following URL, http://java.sun.com/getjava. During node registration, you have the option of granting client owner or client access authority to an existing administrative user ID. You can also prevent the server from creating an administrative user ID at registration. If an administrative user ID already exists with the same name as the node being registered, the server registers the node but does not automatically create an administrative user ID. This process also applies if your site uses open registration. For more information about installing and configuring the Web backup-archive client, refer to BackupArchive Installation and User's Guide.

Description of Node Privilege Class with Client Access Authorities

Access to a Web backup-archive client requires either client owner authority or client access authority. Administrators with system or policy privileges over the client node's domain, have client owner authority by default. The administrative user ID created automatically at registration has client owner authority by default. This administrative user ID is displayed when an administrator issues a QUERY ADMIN command. The following describes the difference between client owner and client access authority when defined for a user that has the node privilege class: Client owner You can access the client through the Web backup-archive client or native backup-archive client. You own the data and have a right to physically gain access to the data remotely. You can backup and restore files on the same or different machine, you can delete file spaces or archive data. The user ID with client owner authority can also access the data from another machine using the -NODENAME parameter. The administrator can change the client node's password for which they have authority.

This is the default authority level for the client at registration. An administrator with system or policy privileges to a client's domain has client owner authority by default. Client access You can only access the client through the Web backup-archive client. You can restore data only to the original client. A user ID with client access authority cannot access the client from another machine using the NODENAME parameter. This privilege class authority is useful for help desk personnel so they can assist users in backing up or restoring data without having system or policy privileges. The client data can only be restored to none other than the original client. A user ID with client access privilege cannot directly access client's data from a native backup-archive client.

Managing Client Access Authority Levels

By default, an administrator with system or policy privilege over a client's domain can remotely access clients and perform backup and restore operations. You can grant client access or client owner authority to other administrators by specifying CLASS=NODE and AUTHORITY=ACCESS or AUTHORITY=OWNER parameters on the GRANT AUTHORITY command. You must have one of the following privileges to grant or revoke client access or client owner authority: System privilege Policy privilege in the client's domain Client owner privilege over the node Client access privilege over the node

You can grant an administrator client access authority to individual clients or to all clients in a specified policy domain. For example, you may want to grant client access privileges to users that staff help desk environments. See Example: Setting up Help Desk Access to Client Machines in a Specific Policy Domain for more information.

Granting Client Authority

To grant client access authority to administrator FRED for the LABCLIENT node, issue: grant authority fred class=node node=labclient The administrator FRED can now access the LABCLIENT client, and perform backup and restore. The administrator can only restore data to the LABCLIENT node. To grant client owner authority to ADMIN1 for the STUDENT1 node, issue: grant authority admin1 class=node authority=owner node=student1 The user ID ADMIN1 can now perform backup and restore operations for the STUDENT1 client node. The user ID ADMIN1 can also restore files from the STUDENT1 client node to a different client node.

Automatically Creating an Administrative User ID with Client Owner Authority

When you use the REGISTER NODE command, by default, the server creates an administrative user ID in addition to the client node. The administrative user ID has client owner authority to the node when the node is defined to the server. For example, you want to register client node DESK2, issue: register node desk2 pass2dsk The following shows the output from this command.

+-------------------------------------------------------------------------------+ |ANR2060I Node DESK2 registered in policy domain STANDARD. | |ANR2099I Administrative userid DESK2 defined for OWNER access to node DESK2. | | | +-------------------------------------------------------------------------------+ The DESK2 client node is registered, in addition to an administrative user ID with the same ID. The administrative user ID DESK2 has a password of pass2dsk with client owner authority to the DESK2 node. When the PASSWORDACCESS=GENERATE option is used by the client to change the password, the administrative DESK2 ID can still access the client from a remote location.

Preventing Automatic Creation of an Administrative User ID with Client Owner Authority

You can prevent automatic creation of an administrative user ID with client owner authority by specifying USERID=NONE on the REGISTER NODE command. For example, you want to register DESK2 without creating an administrative user ID with client owner authority by default. Issue the following: register node desk2 pass2dsk userid=none

Registering a Node and Granting an Existing Administrative ID Client Owner Authority

You can grant client owner authority to an existing administrative user ID. For example, to give client owner authority to the HELPADMIN user ID when registering the NEWCLIENT node, enter: register node newclient pass2new userid=helpadmin This command results in the NEWCLIENT node being registered with a password of pass2new, and also grants HELPADMIN client owner authority. This command would not create an administrator ID. The HELPADMIN client user ID is now able to access the NEWCLIENT node from a remote location.

Example: Setting up Help Desk Access to Client Machines in a Specific Policy Domain
You want to set up help desk access for user HELP1 to the client nodes in the FINANCE domain. You want to grant HELP1 client access authority to the FINANCE domain without having to grant system or policy privileges.

The client nodes have been previously set up as follows: Installed and configured. The URL and port numbers were specified during the REGISTER NODE process. Assigned to the FINANCE policy domain. Started the TSM Client Acceptor service. Specified passwordaccess generate option in their client option files.

The help desk person, using HELP1 user ID, has a Web browser with Java Runtime Environment (JRE) 1.3.1. 1. Register an administrative user ID of HELP1. 2. register admin help1 05x23 contact="M. Smith, Help Desk x0001" 3. Grant the HELP1 administrative user ID client access authority to all clients in the FINANCE domain. With client access authority, HELP1 can perform backup and restore operations for clients in the FINANCE domain. Client nodes in the FINANCE domain are Dave, Sara, and Joe. 4. grant authority help1 class=node authority=access domains=finance The following is output generated by this command:

+-------------------------------------------------------------------------------+ |ANR2126I GRANT AUTHORITY: Administrator HELP1 was granted ACCESS authority for c| | DAVE. | |ANR2126I GRANT AUTHORITY: Administrator HELP1 was granted ACCESS authority for c| | JOE. | |ANR2126I GRANT AUTHORITY: Administrator HELP1 was granted ACCESS authority for c| | SARA. | | | +-------------------------------------------------------------------------------+ 5. The help desk person, HELP1, opens the Web browser and specifies the URL and port number for client machine Sara: 6. http://sara.machine.name:1581 A Java applet is started, and the client hub window is displayed in the main window of the Web browser. When HELP1 accesses the backup function from the client hub, the Tivoli Storage Manager login screen is displayed in a separate Java applet window. HELP1 authenticates with the administrative user ID and password. HELP1 can perform a backup for Sara. For information about what functions are not supported on the Web backup-archive client, refer to Backup-Archive Installation and User's Guide.

Managing File Spaces

A file space name identifies a group of files that are stored as a logical unit in server storage. Administrators manage file spaces in which Tivoli Storage Manager stores each client node's data. See Overview of Client Nodes and File Spaces for more information. Administrators can perform the following activities when managing file spaces:
Task Required Privilege Class

Determine when existing file spaces are renamed to allow for the System, unrestricted policy privilege, or restricted policy privilege creation of new Unicode-enabled file spaces for the policy domain to which the client node is assigned. Displaying information about file spaces Move selected file spaces for a single node, as well as move a node's data located in a sequential access storage pool Any administrator System, unrestricted storage, or restricted storage privilege for the source storage pool. If your authorization is restricted storage privilege and you intend to move data to another storage pool, you must also have the appropriate authority for the destination storage pool. System or unrestricted policy System, unrestricted policy, or restricted policy for those domains

Deleting file spaces Deleting file spaces assigned to specific policy domains

Overview of Client Nodes and File Spaces

Each client is given a node name when it is registered with the server. The server views its registered nodes as clients that require services and resources from the server. Typically, a node is equivalent to a machine as in the case of a backup-archive client installed on a user's computer for file system backups. However, multiple nodes can exist on a single machine as in the case of a SQL server machine containing both an application client for SQL database and transaction log backups, and a backup-archive client for file system backups. Typically, each client file system is represented on the server as a unique file space that belongs to each client node. Therefore, the number of file spaces a node has depends on the number of file systems on the client machine. For example, a Windows desktop system may have multiple drives (file systems), such as C: and D:. In this case, the client's node has two file spaces on the server; one for the C: drive and a second for the D: drive. The file spaces can grow as a client stores more data on the server. The file spaces decrease as backup and archive file versions expire and the server reclaims the space. Tivoli Storage Manager does not allow an administrator to delete a node unless the node's file spaces have been deleted.

File Spaces for Clients

For client nodes running on Windows, file spaces map to logical partitions and shares. Each file space is named with the UNC name of the respective client partition or share. For client nodes running on NetWare, file spaces map to NetWare volumes. Each file space is named with the corresponding NetWare volume name.

For clients running on Macintosh, file spaces map to Macintosh volumes. Each file space is named with the corresponding Macintosh volume name. For clients running on UNIX, a file space name maps to a file space in storage that has the same name as the file system or virtual mount point from which the files originated. The VIRTUALMOINTPOINT option allows users to define a virtual mount point for a file system to back up or archive files beginning with a specific directory or subdirectory. For information on the VIRTUALMOUNTPOINT option, refer to the appropriate Backup-Archive Installation and User's Guide.

Supporting Unicode-Enabled Clients

Unicode is a universal character encoding standard that supports the interchange, processing, and display of text that is written in any of the languages of the modern world. For Windows NT, Windows 2000, Windows 2002, Windows .NET, and Windows XP systems with the Unicode-enabled client, the server supports storing file spaces with Unicode file space names, directory names, and file names in server storage. The file spaces in server storage that have Unicode names are called Unicode-enabled file spaces. Support for Unicode names enables a client to successfully process a Tivoli Storage Manager operation even when the file spaces contain directory names or files in multiple languages, or when the client uses a different code page than the server. New clients storing data on the server for the first time require no special set-up. If the client has the latest Tivoli Storage Manager client software installed, the server automatically stores Unicode-enabled file spaces for that client. However, if you have clients that already have data stored on the server and the clients install the Unicode-enabled Tivoli Storage Manager client software, you need to plan for the migration to Unicodeenabled file spaces. To allow clients with existing data to begin to store data in Unicode-enabled file spaces, Tivoli Storage Manager provides a function for automatic renaming of existing file spaces. The file data itself is not affected; only the file space name is changed. Once the existing file space is renamed, the operation creates a new file space that is Unicode enabled. The creation of the new Unicode-enabled file space for clients can greatly increase the amount of space required for storage pools and the amount of space required for the server database. It can also increase the amount of time required for a client to run a full incremental backup, because the first incremental backup after the creation of the Unicode-enabled file space is a full backup. When clients with existing file spaces migrate to Unicode-enabled file spaces, you need to ensure that sufficient storage space for the server database and storage pools is available. You also need to allow for potentially longer backup windows for the complete backups. Note: Once the server is at the latest level of software that includes support for Unicode-enabled file spaces, you can only go back to a previous level of the server by restoring an earlier version of Tivoli Storage Manager and the database. A Unicode-enabled Tivoli Storage Manager client is currently available only on Windows NT, Windows 2000, Windows 2002, Windows .NET, and Windows XP. Data in a Unicode code page from any other source, including down-level clients and API clients, will not be identified or treated as Unicode enabled. Note: The remainder of this section will refer to these clients as Unicode-enabled clients, users of Windows NT-based operating systems, or clients.

It is strongly recommended that users of Windows NT-based operating systems migrate their nonUnicode file spaces to Unicode enabled file spaces. For more information see Backup-Archive Installation and User's Guide. See the following sections: Reasons for Migrating Clients to Unicode-Enabled File Spaces Migrating Clients to Unicode-Enabled File Spaces Querying Unicode-enabled File Spaces Unicode-enabled Clients and Existing Backup Sets

Reasons for Migrating Clients to Unicode-Enabled File Spaces

Without Tivoli Storage Manager support for storing Unicode-enabled file spaces, some clients have experienced backup failures when file spaces contain names of directories or files in multiple languages, or have names that cannot be converted to the server's code page. When Tivoli Storage Manager cannot convert the code page, the client may receive one or all of the following messages if they were using the command line: ANS1228E, ANS4042E, and ANS1803E. Clients that are using the GUI may see a "Path not found" message. If you have clients that are experiencing such backup failures, then you need to migrate the file spaces for these clients to ensure that these systems are completely protected with backups. If you have a large number of clients, set the priority for migrating the clients based on how critical each client's data is to your business. See Migrating Clients to Unicode-Enabled File Spaces. Any new file spaces that are backed up from client systems with the Unicode-enabled Tivoli Storage Manager client are automatically stored as Unicode-enabled file spaces in server storage. Objects backed up or archived with a Unicode-enabled Tivoli Storage Manager client in any supported language environment can be restored or retrieved with a Unicode-enabled client in the same or any other supported language environment. This means, for example, that files backed up by a Japanese Unicode-enabled client can be restored by a German Unicode-enabled client. Note: Objects backed up or archived by a Unicode-enabled Tivoli Storage Manager client, cannot be restored or retrieved by a client that is not Unicode enabled.

Migrating Clients to Unicode-Enabled File Spaces

To allow clients with existing data to migrate to Unicode-enabled file spaces, Tivoli Storage Manager provides an automatic rename function for file spaces. When enabled, Tivoli Storage Manager uses the rename function when it recognizes that a file space that is not Unicode enabled in server storage matches the name of a file space on a client. The existing file space in server storage is renamed, so that the file space in the current operation is then treated as a new, Unicode-enabled file space. For example, if the operation is an incremental backup at the file space level, the entire file space is then backed up to the server as a Unicode-enabled file space. The following example shows how this process works when automatic renaming is enabled from the server, for an existing client node that has file spaces in server storage.

1. The administrator updates a client node definition by issuing an UPDATE NODE command with the parameter, AUTOFSRENAME YES. 2. The client processes an incremental back up. 3. Tivoli Storage Manager processes the back up as follows: a. Renames the existing file space (_OLD) b. Creates a new Unicode-enabled file space c. Processes the back up in the current operation to the new Unicode-enabled file space Attention: If you force the file space renaming for all clients at the same time, backups can contend for network and storage resources, and storage pools can run out of storage space. Before you allow automatic renaming of file spaces for Unicode-enabled Tivoli Storage Manager clients, read the following sections. The Rules for Automatically Renaming File Spaces Options for Automatically Renaming File Spaces Planning for Unicode Versions of Existing Client File Spaces How Clients are Affected by the Migration to Unicode Example of a Migration Process

Options for Automatically Renaming File Spaces

As an administrator, you can control whether the file spaces of any existing clients are renamed to force the creation of new Unicode-enabled file spaces. By default, no automatic renaming occurs. To control the automatic renaming, use the parameter AUTOFSRENAME when you register or update a node. You can also allow clients to make the choice. Clients can use the client option AUTOFSRENAME. Note: The setting for AUTOFSRENAME affects only clients that are Unicode enabled. You have these options: Do not allow existing file spaces to be renamed, so that Unicode-enabled file spaces are not created (AUTOFSRENAME=NO, the default). Tivoli Storage Manager does not automatically rename client file spaces when the client system upgrades to the Unicode-enabled Tivoli Storage Manager client. This setting can help an administrator control how many clients' file spaces can be renamed at one time. The administrator can determine how many Unicode-enabled clients exist by using the QUERY NODE FORMAT=DETAILED command. The output displays the client level. A Unicode-enabled client is on a Windows NT, Windows 2000, Windows 2002, Windows .NET, and Windows XP system at Tivoli Storage Manager Version 4.2.0 or higher. Automatically rename existing file spaces, forcing the creation of Unicode-enabled file spaces in place of the renamed file spaces (AUTOFSRENAME=YES). Tivoli Storage Manager automatically renames client file spaces in server storage when the client upgrades to the Unicode-enabled client and runs one of the following operations: archive,

selective backup, full incremental backup, or partial incremental backup. Tivoli Storage Manager automatically renames the file spaces that are specified in the current operation and creates new, Unicode-enabled file spaces where files and directories are stored to complete the operation. Other file spaces that are not specified in the current operation are not affected by the rename. This means a client can have mixed file spaces. See The Rules for Automatically Renaming File Spaces for how the new name is constructed. Attention: If you force the file space renaming for all clients at the same time, client operations can contend for network and storage resources, and storage pools can run out of storage space. Allow clients to choose whether to rename files spaces, in effect choosing whether new Unicodeenabled file spaces are created (AUTOFSRENAME=CLIENT). If you use this value for a client node, the client can set its AUTOFSRENAME option in its options file. The client option determines whether file spaces are renamed (YES or NO), or whether the user is prompted for renaming at the time of a Tivoli Storage Manager operation (PROMPT). The default value for the client option is PROMPT. When the option is set for prompting, the client is presented with a choice about renaming file spaces. When a client that has existing file spaces on server storage upgrades to the Unicode-enabled client, and the client runs a Tivoli Storage Manager operation with the server, the user is asked to choose whether to rename the file spaces that are involved in the current operation. The client is prompted only once about renaming a particular file space. If the client does not choose to rename the file space, the administrator can later rename the file space so that a new Unicode-enabled file space is created the next time the client processes an archive, selective backup, full incremental backup, or partial incremental backup. Attention: There is no prompt for operations that run with the client scheduler. If the client is running the scheduler and the client AUTOFSRENAME option is set to PROMPT, there is no prompt and the file space is not renamed. This allows a client session to run unattended. The prompt appears during the next interactive session on the client. The following table summarizes what occurs with different parameter and option settings. Table 21. Effects of AUTOFSRENAME Settings Parameter on the Option on the client Result for file spaces server (for each client) Yes No Client Yes, No, Prompt Yes, No, Prompt Yes No Prompt Renamed Not renamed Renamed Not renamed Command-line or GUI: The user receives a one-time only prompt about renaming Is the file space renamed? Yes No Yes Yes Depends on the response from the user (yes or no)

Client Scheduler: Not renamed (prompt No

appears during the next command-line or GUI session)

The Rules for Automatically Renaming File Spaces

With its automatic renaming function, Tivoli Storage Manager renames a file space by adding the suffix _OLD. For example: Original file space Renamed file space \\maria\c$ \\maria\c$_OLD

If the new name would conflict with the name of another file space, a number is added to the suffix. For example: Original file space \\maria\c$ Other existing file spaces: \\maria\c$_OLD \\maria\c$_OLD1

Renamed file space

\\maria\c$_OLD2

If the new name for the file space exceeds the limit of 64 characters, the file space name is truncated on the right before the suffix _OLD is added.

Planning for Unicode Versions of Existing Client File Spaces

You need to consider the following factors in your planning: After clients with existing file spaces start to create Unicode-enabled file spaces, they will still need to have access to the renamed file spaces that are not Unicode-enabled for some period of time. Your storage pool and database space requirements can double if you allow all clients to create Unicode-enabled file spaces in addition to their existing file spaces that are not Unicode-enabled. Because the initial backups after migration are complete backups, it can also greatly increase the time required to finish backup operations.

To minimize problems, you need to plan the storage of Unicode-enabled file spaces for clients that already have existing file spaces in server storage. 1. Determine which clients need to migrate. Clients that have had problems with backing up files because their file spaces contain names of directories or files that cannot be converted to the server's code page should have the highest priority. Balance that with clients that are most critical to your operations. If you have a large number of clients that need to become Unicode enabled, you can control the migration of the clients. Change the rename option for a few clients at a time to keep control of storage space usage and processing time. Also consider staging migration for clients that have a large amount of data backed up.

2. Allow for increased backup time and network resource usage when the Unicode-enabled file spaces are first created in server storage. Based on the number of clients and the amount of data those clients have, consider whether you need to stage the migration. Staging the migration means setting the AUTOFSRENAME parameter to YES or CLIENT for only a small number of clients every day. Note: If you set the AUTOFSRENAME parameter to CLIENT, be sure to have the clients (that run the client scheduler) set their option to AUTOFSRENAME YES. This ensures the file spaces are renamed. 3. Check the current storage usage for the clients that need to become Unicode enabled. You can use the QUERY OCCUPANCY command to display information on how much space each client is currently using. Initially, clients will need only the amount of space used by active files. Therefore, you need to estimate how much of the current space is used by copies (different versions of the same file). Migration will result in a complete backup at the next incremental backup, so clients will need space for that backup, plus for any other extra versions that they will keep. Therefore, the amount of storage required also depends on policy (see the next step). Your Tivoli Storage Manager policy specifies how files are backed up, archived, migrated from client node storage, and managed in server storage. 4. Understand how your Tivoli Storage Manager policies affect the storage that will be needed. If your policies expire files based only on the number of versions (Versions Data Exists), storage space required for each client will eventually double, until you delete the old file spaces. If your policies expire files based only on age (Retain Extra Versions), storage space required for each client will increase initially, but will not double. If your policies use both the number of versions and their age, each client will need less than double their current usage. 5. Estimate the effect on the database size. The database size depends on the number of files in server storage, as well as the number of versions of those files. As Unicode-enabled file spaces are backed up, the original file spaces that were renamed remain. Therefore, the server requires additional space in the database to store information about the increased number of file spaces and files. See Estimating and Monitoring Database and Recovery Log Space Requirements. 6. Arrange for the additional storage pool space, including space in copy storage pools, based on your estimate from step 3 and 4. 7. Check the server database space that is available and compare with your estimate from step 5. 8. Ensure that you have a full database backup before you proceed with migration of Unicodeenabled file spaces. See Backing Up the Database. 9. Consider how you will manage the renamed file spaces as they age. The administrator can delete them, or the clients can be allowed to delete their own file spaces.

How Clients are Affected by the Migration to Unicode

The server manages a Unicode-enabled client and its file spaces as follows: When a client upgrades to a Unicode-enabled client and logs in to the server, the server identifies the client as Unicode-enabled. Note: That same client (same node name) cannot log in to the server with a previous version of Tivoli Storage Manager or a client that is not Unicode-enabled. The original file space that was renamed (_OLD) remains with both its active and inactive file versions that the client can restore if needed. The original file space will no longer be updated. The server will not mark existing active files inactive when the same files are backed up in the corresponding Unicode-enabled file space. Note: Before the Unicode-enabled client is installed, the client can back up files in a code page other than the current locale, but cannot restore those files. After the Unicode-enabled client is installed, if the same client continues to use file spaces that are not Unicode-enabled, the client skips files that are not in the same code page as the current locale during a backup. Because the files are skipped, they appear to have been deleted from the client. Active versions of the files in server storage are made inactive on the server. When a client in this situation is updated to a Unicode-enabled client, you should migrate the file spaces for that client to Unicode-enabled file spaces. The server does not allow a Unicode-enabled file space to be sent to a client that is not Unicode enabled during a restore or retrieve process. Clients should be aware that they will not see all their data on the Unicode-enabled file space until a full incremental backup has been processed. When a client performs a selective backup of a file or directory and the original file space is renamed, the new Unicode-enabled file space will contain only the file or directory specified for that backup operation. All other directories and files are backed up on the next full incremental backup. If a client needs to restore a file before the next full incremental backup, the client can perform a restore from the renamed file space instead of the new Unicode-enabled file space. For example: 1. Sue had been backing up her file space, \\sue-node\d$. 2. Sue upgrades the Tivoli Storage Manager client on her system to the Unicode-enabled Tivoli Storage Manager client. 3. Sue performs a selective backup of the file HILITE.TXT. 4. The automatic file space renaming function is in effect and Tivoli Storage Manager renames\\sue-node\d$ to \\sue-node\d$_OLD. Tivoli Storage Manager then creates a new Unicode-enabled file space on the server with the name \\sue-node\d$. This new Unicode-enabled file space contains only the HILITE.TXT file. 5. All other directories and files in Sue's file system will be backed up on the next full incremental backup. If Sue needs to restore a file before the next full incremental backup, she can restore the file from the \\sue-node\d$_OLD file space.

Refer to the Using the Backup-Archive Client publication for more information.

Example of a Migration Process

This section gives one possible sequence for migrating clients. Assumptions for this scenario are: The Tivoli Storage Manager server database has been backed up. The latest server software has been installed. This installation has also performed an upgrade to the server database. Clients have installed the latest software. A few clients are file servers. Most clients are workstations used by individuals. Clients generally run scheduled incremental backups every night.

The following is a possible migration process: 1. Have all clients install the Unicode-enabled Tivoli Storage Manager client software. 2. Migrate the file servers first. For clients that are file servers, update the AUTOFSRENAME parameter to enable automatic renaming for the file spaces. For example, if the client node names for all file servers begin with FILE, enter the following command: 3. update node file* autofsrename=yes This forces the file spaces to be renamed at the time of the next backup or archive operation on the file servers. If the file servers are large, consider changing the renaming parameter for one file server each day. 4. Allow backup and archive schedules to run as usual. Monitor the results. a. Check for the renamed file spaces for the file server clients. Renamed file spaces have the suffix _OLD or _OLDn, where n is a number. (See The Rules for Automatically Renaming File Spaces.) b. Check the capacity of the storage pools. Add tape or disk volumes to storage pools as needed. c. Check database usage statistics to ensure you have enough space. 5. Migrate the workstation clients. For example, migrate all clients with names that start with the letter a. 6. update node a* autofsrename=yes 7. Allow backup and archive schedules to run as usual that night. Monitor the results. 8. After sufficient time passes, consider deleting the old, renamed file spaces. See Managing the Renamed File Spaces.

Managing the Renamed File Spaces

The file spaces that were automatically renamed (_OLD) to allow the creation of Unicode-enabled file spaces continue to exist on the server. Users can still access the file versions in these file spaces. Because a renamed file space is not backed up again with its new name, the files that are active (the most recent backup version) in the renamed file space remain active and never expire. The inactive files in the file space expire according to the policy settings for how long versions are retained. To determine how long the files are retained, check the values for the parameters, Retain Extra Versions and Retain Only Versions, in the backup copy group of the management class to which the files are bound. When users no longer have a need for their old, renamed file spaces, you can delete them. If possible, wait for the longest retention time for the only version (Retain Only Version) that any management class allows. If your system has storage constraints, you may need to delete these file spaces before that.

Querying Unicode-enabled File Spaces

You can determine which file spaces are Unicode-enabled by querying all of the file spaces: query filespace +-------------------------------------------------------------------------------+ |Node Name Filespace FSID Platform Filespace Is Capacity Pct | | Name Type Filespace (MB) Util | | Unicode? | |---------- ----------- ---- ------- --------- --------- -------- ----| |SUE \\sue\c$ 1 WinNT NTFS Yes 2,502.3 75.2 | |SUE \\sue\d$ 2 WinNT NTFS Yes 6,173.4 59.6 | |JOE \\joe\c$ 1 WinNT NTFS No 12,299.7 31.7 | | | +-------------------------------------------------------------------------------+ To query a specific Unicode-enabled file space, it may be more convenient to use the file space identifier (FSID) than the file space name. File space names for Unicode-enabled file spaces may not be readable when displayed in the server's code page. Attempting to enter the name of a Unicode-enabled file space may not work because it depends on the server's code page and conversion routines that attempt to convert from the server's code page to Unicode. See Displaying Information about File Spaces for details.

Unicode-enabled Clients and Existing Backup Sets

A client can have a backup set that contains both file spaces that are Unicode-enabled and file spaces that are not Unicode-enabled. The client must have the same level of Tivoli Storage Manager or higher to restore the data in the backup set. For example, a Version 4.1.0 client backs up file spaces, and then upgrades to Version 4.2.0 with support for Unicode-enabled file spaces. That same client can still restore the non-Unicode file spaces from the backup set. Unicode-enabled file spaces in a backup set can only be accessed by a Unicode-enabled client, and not by an earlier version of the client. The server allows only Unicode-enabled clients to restore data from Unicode-enabled file spaces. For information about restoring backup sets, see Restoring Backup Sets from a Backup-Archive Client.

Displaying Information about File Spaces

You can display file space information to: Identify file spaces defined to each client node, so that you can delete each file space from the server before removing the client node from the server Identify file spaces that are Unicode enabled and identify their file space ID (FSID) Monitor the space used on workstation's disks

Monitor whether backups are completing successfully for the file space Determine the date and time of the last backup

You display file space information by identifying the client node name and file space name. Note: File space names are case-sensitive and must be entered exactly as known to the server. For example, to view information about file spaces defined for client node JOE, enter: query filespace joe * The following figure shows the output from this command.

+-------------------------------------------------------------------------------+ |Node Name Filespace FSID Platform Filespace Is Capacity Pct | | Name Type Filespace (MB) Util | | Unicode? | |---------- ----------- ---- ------- --------- --------- -------- ----| |JOE \\joe\c$ 1 WinNT NTFS Yes 2,502.3 75.2 | |JOE \\joe\d$ 2 WinNT NTFS Yes 6,173.4 59.6 | | | +-------------------------------------------------------------------------------+ When you display file space information in detailed format, the Filespace Name field may display file space names as "...". This indicates to the administrator that a file space does exist but could not be converted to the server's code page. Conversion can fail if the string includes characters that are not available in the server code page, or if the server has a problem accessing system conversion routines. File space names and file names that can be in a different code page or locale than the server do not display correctly on the administrator's Web interface or the administrative command-line interface. The data itself is backed up and can be restored properly, but the file space name or file name may display with a combination of invalid characters or blank spaces. Refer to Administrator's Reference for details.

Moving Data by Node

You can move a node's data in a sequential-access storage pool or move selected file spaces for a single node. For more information see, Moving Data by Node.

Deleting File Spaces and Client Nodes

You can delete a client node from a server, but first you must delete all of that client's data from server storage by deleting any file spaces that belong to the node.

Deleting a File Space

Administrators may want to delete a file space when: Users are not authorized to delete backed up or archived files in storage pools. The authority to delete backed up or archived files from server storage is set when a client node is registered. See Accepting Default Closed Registration or Enabling Open Registration for information on allowing users to delete files in storage pools. For example, client node PEASE no longer needs archived files in file space /home/pease/dir2. However, he does not have the authority to delete those files. You can delete them by entering: delete filespace pease /home/pease/dir2 type=archive You want to remove a client node from the server You must delete a user's files from storage pools before you can remove a client node. For example, to delete all file spaces belonging to client node ID DEBBYG, enter: delete filespace debbyg * type=any You want to delete a specific user's files For client nodes that support multiple users, such as UNIX, a file owner name is associated with each file on the server. The owner name is the user ID of the operating system, such as the UNIX user ID. When you delete a file space belonging to a specific owner, only files that have the specified owner name in the file space are deleted. When a node has more than one file space and you issue a DELETE FILESPACE command for only one file space, a QUERY FILESPACE command for the node during the delete process shows no file spaces. When the delete process ends, you can view the remaining file spaces with the QUERY FILESPACE command. Note: After you delete all of a client node's file spaces, you can delete the node with the REMOVE NODE command. See Deleting Client Nodes for more details.

Modifying Client Option Files

Client nodes connect with the server through a client options file (dsm.opt). This file, located in the client directory, contains client options that control processing and connections with the server. The most important option is the network address of the server, but you can add many other client options at any time. See more information about client option files, see Connecting Nodes with the Server.

Administrators can also create client option sets to be used in conjunction with client option files. See Creating Client Option Sets from the Server for more details.

All Nodes
All client options files (dsm.opt) can be edited with a text editor. Anyone can edit the client options file if they have access to the directory where the node software is installed. Editing individual options files is the most direct method, but may not be suitable for sites with many client nodes. Note: If any changes are made to the dsm.opt file, the client must be restarted for changes in the options file to have any affect.

Creating Client Option Sets from the Server

An administrator can create a set of client options to be used by a client node at Tivoli Storage Manager Version 3 or later. The client options specified in the set are used in conjunction with the client options file described in Connecting Nodes with the Server. Client option sets allow the administrator to specify additional options that may not be included in the client's option file (dsm.opt). You can specify which clients use the option set with the REGISTER NODE or UPDATE NODE commands. The client can use these defined options during a backup, archive, restore, or retrieve process. See Backup-Archive Installation and User's Guide for detailed information about individual client options. To create a client option set and have the clients use the option set, do the following: 1. Create the client option set with the DEFINE CLOPTSET command. 2. Add client options to the option set with the DEFINE CLIENTOPT command. 3. Specify which clients should use the option set with the REGISTER NODE or UPDATE NODE command.

Creating a Client Option Set

When you create a client option set, you define a name for the option set, and can optionally provide a description of the option set. For example: define cloptset engbackup description='Backup options for eng. dept.' Note: The option set is empty when it is first defined.

Adding Client Options in an Option Set

You can add client options in a defined client option set. The following example shows how to add a client option in the ENGBACKUP option set. define clientopt engbackup schedlogretention 5 For a list of valid client options you can specify, refer to Administrator's Reference.

The server automatically assigns sequence numbers to the specified options, or you can choose to specify the sequence number for order of processing. This is helpful if you have defined more than one of the same option as in the following example. define clientopt engbackup inclexcl "include d:\admin" define clientopt engbackup inclexcl "include d:\payroll" A sequence number of 0 is assigned to the option include d:\admin. A sequence number of 1 is assigned to the option include d:\payroll. If you want to specifically process one option before another, include the sequence parameter as follows: define clientopt engbackup inclexcl "include d:\admin" seqnumber=2" define clientopt engbackup inclexcl "include d:\payroll" seqnumber=1" The options are processed starting with the highest sequence number. Any include-exclude statements in the server client option set have priority over the include-exclude statements in the local client options file. The server include-exclude statements are always enforced and placed at the bottom of the include-exclude list and evaluated before the client include-exclude statements. If the server option set has several include-exclude statements, the statements are processed starting with the highest sequence number. The client can use the QUERY INCLEXCL command to view the include-exclude statements in the order they are processed. QUERY INCLEXCL also displays the source of each include-exclude statement. For more information on the processing of the include-exclude statements see The Include-Exclude List and also the Backup-Archive Installation and User's Guide. The FORCE parameter allows an administrator to specify whether a client node can override an option value. This parameter has no effect on additive options such as INCLEXCL and DOMAIN. The default value is NO. If FORCE=YES, the client cannot override the value. The following example shows how you can prevent a client from using subfile backup: define clientopt engbackup subfilebackup no force=yes

Registering Client Nodes and Assigning Them to an Option Set

You can register or update a client node and specify an option set for the client to use as follows: register node mike pass2eng cloptset=engbackup The client node MIKE is registered with the password pass2eng. When the client node MIKE performs a scheduling operation, his schedule log entries are kept for 5 days.

Managing Client Options from the Server Using Client Option Sets
Administrators can perform the following activities when managing client option sets:
Task Required Privilege Class

Updating the sequence number for a client option System or unrestricted policy Deleting an option from a client option set System, unrestricted policy, or restricted policy

Copying a client option set Displaying client option set information Updating the client option set description Deleting a client option set

System, unrestricted policy, or restricted policy Any administrator System, unrestricted policy, or restricted policy System, unrestricted policy, or restricted policy

Updating the Sequence Number for a Client Option

You can update the sequence number for a client option to change its processing order. This is helpful if you have more than one of the same option, for example several INCLUDE options. The following example shows how to change the sequence number for the DATEFORMAT option from 0 to 9: update clientopt engbackup dateformat 0 9

Deleting an Option from a Client Option Set

You can remove an option that is defined in a client option set. The following example shows how to remove the SCHEDMODE polling option from the financeschd option set: delete clientopt financeschd schedmode

Copying a Client Option Set

You can copy an existing client option to another option set. The following example shows how to copy the engbackup option set to financeschd option set: copy cloptset engbackup financeschd

Requesting Information about a Client Option Set

To display information about the contents of a client option set, issue the following command: query cloptset financeschd

Updating the Description for a Client Option Set

You can update the description for a client option set. The following example shows how to update the description for the engbackup option set: update clopset engbackup description='Scheduling information'

Deleting a Client Option Set

When you delete a client option set, client node references to the option set are null. The clients continue to use their existing client options file. The following example shows how to delete the engbackup client option set: delete cloptset engbackup

Managing Tivoli Storage Manager Sessions

Each time an administrator or client node connects with the server, an administrative or client session is established. Tivoli Storage Manager tracks its sessions in the server database. Backup-archive clients are eligible for client restartable restore sessions, however, application clients are not. See Managing Client Restartable Restore Sessions for more information. Administrators can perform the following activities when managing Tivoli Storage Manager sessions:
Task Required Privilege Class

Displaying information about client sessions Any administrator Canceling a client session Disabling or enabling a client session Freeing links for client connections System or operator System or operator Administrator with root authority

Displaying Information about Tivoli Storage Manager Sessions

Each client session is assigned a unique session number. To display information about client sessions, enter: query session Figure 41 shows a sample client session report. Figure 41. Information about Client Sessions +-------------------------------------------------------------------------------+ | Sess Comm. Sess Wait Bytes Bytes Sess Platform Client Name | |Number Method State Time Sent Recvd Type | |------ ------ ------ ------ ------- ------- ----- -------- ----------| | 471 Tcp/Ip IdleW 36 S 592 186 Node WinNT JOEUSER | | 472 Tcp/Ip RecvW 0 S 730 838.2 K Node WinNT STATION1 | | 475 HTTP Run 0 S 0 0 Admin WebBrow- ADMIN | | ser | | | +-------------------------------------------------------------------------------+ You can determine the state of the server by examining the session state and wait time to determine how long (in seconds, minutes, or hours) the session has been in the current state.

Server Session States

The server session state can be one of the following: Start Connecting with a client session. Run Executing a client request. End Ending a client session. RecvW Waiting to receive an expected message from the client while a database transaction is in progress. A session in this state is subject to the COMMTIMEOUT limit. SendW Waiting for acknowledgment that the client has received a message sent by the server. MediaW Waiting for removable media to become available. Aggregation can cause multiple media waits within a transaction and is indicated by one client message. For more information, see Reclaiming Space in Sequential Access Storage Pools. Note: If QUERY SESSION FORMAT=DETAILED is specified, the Media Access Status field displays the type of media wait state. IdleW Waiting for communication from the client, and a database transaction is NOT in progress. A session in this state is subject to the IDLETIMEOUT limit as specified in the server options file. If a client does not initiate communication within the specified time limit set by the IDLETIMEOUT option in the server options file, then the server cancels the client session. For example, if the IDLETIMEOUT option is set to 30 minutes, and a user does not initiate any operations within those 30 minutes, then the server cancels the client session. The client session is automatically reconnected to the server when it starts to send data again.

Canceling a Tivoli Storage Manager Session

You can cancel a client session with the CANCEL SESSION command and the associated session number. Canceling sessions may be necessary when a user's machine is not responding or as a prerequisite to halting the server. Administrators can display a session number with the QUERY SESSION command as described in Displaying Information about Tivoli Storage Manager Sessions. Users and administrators whose sessions have been canceled must reissue their last command to access the server again. If an operation, such as a backup or an archive process, is interrupted when you cancel the session, the server rolls back the results of the current transaction. That is, any changes made by the operation that are not yet committed to the database are undone. If necessary, the cancellation process may be delayed.

If the session is in the Run state when it is canceled, the cancel process does not take place until the session enters the SendW, RecvW, or IdleW state. For details, see Server Session States. If the session you cancel is currently waiting for a media mount, the mount request is automatically canceled. If a volume associated with the client session is currently being mounted by an automated library, the cancel may not take effect until the mount is complete. For example, to cancel a session for client MARIE: 1. Query client sessions to determine the session number as shown Figure 41. The example report displays MARIE's session number 6. 2. Cancel node MARIE's session by entering: 3. cancel session 6 If you want to cancel all backup and archive sessions, enter: cancel session all

When a Client Session is Automatically Canceled

Client sessions can be automatically canceled based on the settings of the following server options: COMMTIMEOUT Specifies how many seconds the server waits for an expected client message during a transaction that causes a database update. If the length of time exceeds this time-out, the server rolls back the transaction that was in progress and ends the client session. The amount of time it takes for a client to respond depends on the speed and processor load for the client and the network load. IDLETIMEOUT Specifies how many minutes the server waits for a client to initiate communication. If the client does not initiate communication with the server within the time specified, the server ends the client session. For example, the server prompts the client for a scheduled backup operation but the client node is not started. Another example can be that the client program is idle while waiting for the user to choose an action to perform (for example, backup archive, restore, or retrieve files). If a user starts the client session and does not choose an action to perform, the session will time out. The client program automatically reconnects to the server when the user chooses an action that requires server processing. A large number of idle sessions can inadvertently prevent other users from connecting to the server. THROUGHPUTDATATHRESHOLD Specifies a throughput threshold, in kilobytes per second, a client session must achieve to prevent being cancelled after the time threshold is reached. Throughput is computed by adding send and receive byte counts and dividing by the length of the session. The length does not include time spent waiting for media mounts and starts at the time a client sends data to the server for storage. This option is used in conjunction with the THROUGHPUTTIMETHRESHOLD server option. THROUGHPUTTIMETHRESHOLD Specifies the time threshold, in minutes, for a session after which it may be canceled for low throughput. The server ends a client session when it has been active for more minutes than specified and the data transfer rate is less than the amount specified in the THROUGHPUTDATATHRESHOLD server option.

Refer to the Administrator's Reference for more information.

Disabling or Enabling Access to the Server

Task Required Privilege Class

Disabling and enabling client node access to the server System or operator Displaying server status Any administrator

You can prevent clients from establishing sessions with the server by using the DISABLE SESSIONS command. This command does not cancel sessions currently in progress or system processes such as migration and reclamation. For example, to disable client node access to the server, enter: disable sessions You continue to access the server and current client activities complete unless a user logs off or an administrator cancels a client session. After the client sessions have been disabled, you can enable client sessions and resume normal operations by entering: enable sessions

You can issue the QUERY STATUS command to determine if the server is enabled or disabled.

Managing Client Restartable Restore Sessions

Some large restore operations may invoke a special type of restore operation called client restartable restore sessions. These special sessions allow users to restart the restore session from where it left off if the session was interrupted. Tivoli Storage Manager identifies client restartable restore sessions by displaying message ANS1247I on the client machine when the sessions start. These restore sessions can be restarted as long as the restore interval has not expired. When a restartable restore session is saved in the server database the file space is locked in server storage. The following is in effect during the file space lock: Files residing on sequential volumes associated with the file space cannot be moved. Files associated with the restore cannot be backed up. However, files not associated with the restartable restore session that are in the same file space are eligible for backup. For example, if you are restoring all files in directory A, you can still backup files in directory B from the same file space.

The RESTOREINTERVAL server option allows administrators to specify how long client restartable restore sessions are saved in the server database. Consider scheduled backup operations when setting this option. For more information, refer to the RESTOREINTERVAL server option in Administrator's Reference.. Administrators can perform the following activities when managing client restartable restore sessions:
Task Required Privilege Class

Displaying information about client restartable restore sessions Any administrator Canceling client restartable restore sessions System or operator

Interrupting client restartable restore sessions

System or operator

Displaying Information about a Client Restartable Restore Session

You can display information about client restartable restore sessions with the QUERY RESTORE command. For example, to determine which client nodes have eligible restartable restore sessions, enter: query restore Restartable restore sessions have a negative session number.

Canceling a Client Restartable Restore Session

When a client restore session is in a restartable state, the file space is locked in server storage and no files can be moved from sequential volumes. This prevents the data from being migrated, moved, reclaimed, or backed up by another operation. These sessions will automatically expire when the specified restore interval has passed. An administrator can cancel a restartable restore session that is in an active or restartable state. If the restore session is active, any outstanding mount requests related to the active session are automatically canceled. When a restartable restore session is canceled with the CANCEL RESTORE command, it cannot be restarted from the point of interruption. A restartable restore session always has a negative session number. To cancel a restartable restore session, you must specify the session number. For example: cancel restore -1

Interrupting an Active Client Restartable Restore Session

An administrator can interrupt an active restartable restore session and have the option to later restart the session from its point of interruption by canceling the session. cancel session -2

Managing Tivoli Storage Manager Security

Administrators can perform the following activities when managing Tivoli Storage Manager security.
Task Managing administrators Managing levels of administrative authority Managing administrator access to the server and clients Managing passwords Managing the server console

Managing Tivoli Storage Manager Administrators

The administrator is responsible for registering other administrators, granting levels of authority, renaming or removing administrators, or for locking and unlocking administrators from the server.
Task Registering an administrator Granting administrative authority Updating information about other administrators Updating information about yourself Displaying information about administrators Renaming an administrator user ID Removing administrators Required Privilege Class System System System Any administrator Any administrator System System

Locking or unlocking administrators from the server System

About the Server Console

At installation, the server console is defined with a special user ID, which is named SERVER_CONSOLE. This name is reserved and cannot be used by another administrator. An administrator with system privilege can revoke or grant new privileges to the SERVER_CONSOLE user ID. However, an administrator cannot update, lock, rename, or remove the SERVER_CONSOLE user ID. The SERVER_CONSOLE user ID does not have a password. Therefore, you cannot use the user ID from an administrative client unless you set authentication off.

Registering Administrators
The administrator registers other administrators with the REGISTER ADMIN command. To register the administrator with a user ID of DAVEHIL and the password of birds, and a password expiration period of 120 days, enter the REGISTER ADMIN command: register admin davehil birds passexp=120 contact='backup team'

Granting an Administrator Privilege Class Authority

After administrators are registered, they can make queries and request command-line help. To perform other server functions, they must be granted authority by being assigned one or more administrative privilege classes. This section describes the privilege classes, which are illustrated in Figure 42. An administrator with system privilege can perform any server function. Administrators with policy, storage, operator, analyst, or node privileges can perform subsets of server functions. When an administrator accesses the administrative Web interface, only the tasks that correspond to the administrator's privilege class are displayed. Figure 42. Administrative Privilege Classes

Privilege classes, and examples of how to set privilege classes, can be summarized as follows:
Privilege Class System Responsibilities

grant authority rocko classes=system

Can perform any server administrative task. System-wide responsibilities Manage the enterprise Manage Tivoli Storage Manager security

Unrestricted Policy

grant authority smith classes=policy

Can manage the backup and archive services for nodes assigned to any policy domain. Manage nodes Manage policy Manage schedules

Restricted Policy

grant authority jones domains=engpoldom

Same responsibilities as unrestricted policy except authority is limited to specific policy domains.

Unrestricted Storage

Can manage server storage, but cannot define or grant authority coyote classes=storage delete storage pools. Manage the database and recovery log Manage Tivoli Storage Manager devices Manage Tivoli Storage Manager storage

Restricted Storage

Can manage server storage but is limited to specific storage

grant authority holland stgpools=tape* pools.

Operator

Manage Tivoli Storage Manager devices Manage Tivoli Storage Manager storage

grant authority bill classes=operator

Can control the immediate operation of the server and the availability of storage media. Manage the Tivoli Storage Manager server Manage client sessions Manage tape operations

Node

grant authority help1 classes=node node=labclient

Analyst

Can access a Web backup-archive client to perform backup and restore operations. Can reset the counters that track Tivoli Storage Manager server statistics.

grant authority marysmith classes=analyst

Updating Information about Other Administrators

An administrator can reset another administrator's password with the UPDATE ADMINISTRATOR command. For example, administrator DAVEHIL changes his password to ganymede, by issuing the following command: update admin davehil ganymede

Renaming an Administrator
You can rename an administrator ID when an employee wants to be identified by a new ID, or you want to assign an existing administrator ID to another person. You cannot rename an administrator ID to one that already exists on the system. For example, if administrator HOLLAND leaves your organization, you can assign administrative privilege classes to another user by completing the following steps: 1. Assign HOLLAND's user ID to WAYNESMITH by issuing the RENAME ADMIN command: 2. rename admin holland waynesmith

By renaming the administrator's ID, you remove HOLLAND as a registered administrator from the server. In addition, you register WAYNESMITH as an administrator with the password, contact information, and administrative privilege classes previously assigned to HOLLAND. 3. Change the password to prevent the previous administrator from accessing the server by entering: 4. update admin waynesmith new_password contact="development" Note: The administrator SERVER_CONSOLE cannot be renamed. See About the Server Console.

Removing Administrators
You can remove administrators from the server so that they no longer have access to administrator functions. For example, to remove registered administrator ID SMITH, enter: remove admin smith Notes: 1. You cannot remove the last system administrator from the system. 2. You cannot remove the administrator SERVER_CONSOLE. See About the Server Console for more information.

Displaying Information about Administrators

Any administrator can query the server to display administrator information. You can also query all administrators authorized with a specific privilege class. For example, to query the system for a detailed report on administrator ID DAVEHIL, issue the QUERY ADMIN command: query admin davehil format=detailed Figure 43 displays a detailed report. Figure 43. A Detailed Administrator Report +-------------------------------------------------------------------------------+ | | | Administrator Name: DAVEHIL | | Last Access Date/Time: 1998.06.04 17.10.52 | | Days Since Last Access: <1 | | Password Set Date/Time: 1998.06.04 17.10.52 | | Days Since Password Set: 26 | | Invalid Sign-on Count: 0 |

| Locked?: No | | Contact: | | System Privilege: Yes | | Policy Privilege: **Included with system privilege** | | Storage Privilege: **Included with system privilege** | | Analyst Privilege: **Included with system privilege** | | Operator Privilege: **Included with system privilege** | | Client Access Privilege: **Included with system privilege** | | Client Owner Privilege: **Included with system privilege** | | Registration Date/Time: 05/09/1998 23:54:20 | | Registering Administrator: SERVER_CONSOLE | | Managing profile: | |Password Expiration Period: 90 Day (s) | | | +-------------------------------------------------------------------------------+

Locking and Unlocking Administrators from the Server

Administrators can prevent other administrators from accessing the server by locking and unlocking their administrative privilege classes. For details, see Locking and Unlocking Administrators from the Server.

Managing Levels of Administrative Authority

A privilege class is a level of authority granted to an administrator. The privilege class determines which administrative tasks the administrator can perform. See Granting an Administrator Privilege Class Authority and Administrator's Reference about the activities that administrators can perform with each privilege class. You can perform the following activities when managing other administrators' levels of authority:
Task Modifying administrators level of authority Required Privilege Class System

Locking and unlocking administrators from the server System

Modifying Administrator Levels of Authority

You may need to modify other administrators levels of authority as more clients and administrators are added to the Tivoli Storage Manager environment. If a person already has some level of authority, granting additional authority adds to any existing privilege classes; it does not override those classes.

Extending Authority for Administrators

You can grant and extend authority with the GRANT AUTHORITY command. For example, JONES has restricted policy privilege for policy domain ENGPOLDOM. Enter the following command to extend JONES' authority to policy domain MKTPOLDOM and add operator privilege: grant authority jones domains=mktpoldom classes=operator As an additional example, assume that three tape storage pools exist: TAPEPOOL1, TAPEPOOL2, and TAPEPOOL3. To grant restricted storage privilege for these storage pools to administrator HOLLAND, you can enter the previous command: grant authority holland stgpools=tape* HOLLAND is restricted to managing storage pools beginning with TAPE that existed when the authority was granted. HOLLAND is not authorized to manage any storage pools that are defined after authority has been granted. To add a new storage pool, TAPEPOOL4, to HOLLAND's authority, enter: grant authority holland stgpools=tapepool4

Reducing Authority for Administrators

You can revoke part of an administrator's authority with the REVOKE AUTHORITY command and specifying the administrator's ID and one or more privilege classes. Assume that rather than revoking all of the privilege classes for administrator JONES you wished only to revoke his operator authority and his policy authorization to policy domain MKTPOLDOM. You would enter: revoke authority jones classes=operator domains=mktpoldom JONES still has policy privilege to the ENGPOLDOM policy domain.

Reducing Privilege Classes

You can reduce an administrator's authority simply by revoking one or more privilege classes and granting one or more other classes. For example, administrator HOGAN has system authority. To reduce HOGAN to the operator privilege class do the following: 1. Revoke the system privilege class by entering: 2. revoke authority hogan classes=system

3. Grant operator privilege class by entering: 4. grant authority hogan classes=operator

Revoking Authority for Administrators

You can revoke an administrator's authority with the REVOKE AUTHORITY command. To revoke all administrative privilege classes, do not specify any privilege classes, policy domains, or storage pools. For example, to revoke both the storage and operator privilege classes from administrator JONES enter: revoke authority jones

Locking and Unlocking Administrators from the Server

You can lock out other administrators to temporarily prevent them from accessing Tivoli Storage Manager with the LOCK ADMIN command. For example, administrator MARYSMITH takes a leave of absence from your business. You can lock her out by entering: lock admin marysmith When she returns, any system administrator can unlock her administrator ID by entering: unlock admin marysmith MARYSMITH can now access the server to complete administrative tasks. You cannot lock or unlock the SERVER_CONSOLE ID from the server. See About the Server Console for details.

Managing Access to the Server and Clients

An administrator can control access to the server by registering and granting authority to administrators, renaming or removing an administrator, or by locking and unlocking an administrator from the server. By default, a system or policy administrator over a specified client's domain can create a backup set from a client node's latest active files. For more information, see Chapter 15, Managing Schedules for Client Nodes.

Preventing Clients from Accessing the Server

You can prevent clients from establishing administrative sessions with the server. For details, see Locking and Unlocking Client Nodes.

Preventing Administrators from Accessing the Server

You can prevent other administrators from establishing administrative sessions with the server. For details, see Locking and Unlocking Administrators from the Server.

Disabling or Enabling Client Sessions

You can prevent clients from establishing sessions with the server. This effectively locks the nodes from the server. For details, see Disabling or Enabling Access to the Server.

Managing Passwords
By default, Tivoli Storage Manager requires authorized administrators and nodes to identify themselves to the server with a password. Administrators can perform the following activities when managing passwords
Task Modifying the default timeout period for the administrative Web interface Required Privilege Class System

Modifying the default password expiration period Setting the limit for invalid password attempts Setting the minimum limit for passwords Disabling the default password authentication

Modifying the Default Timeout Period for the Administrative Web Interface
At installation, the timeout default value for the administrative Web interface is 10 minutes. When the timeout period expires, the user of the Web interface is required to reauthenticate by logging on and specifying a password. The following example shows how to set the timeout value to 20 minutes: set webauthtimeout 20 You can specify a value from 0 to 9999 minutes. If the minimum value is 0, there is no timeout period for the administrative Web interface. To help ensure the security of an unattended browser, it is recommended that you set the timeout value higher than zero.

Modifying the Default Password Expiration Period

By default, the server sets a password expiration of 90 days. The expiration period begins when an administrator or client node is first registered to the server. If a user password is not changed within this period, the server prompts the user to change the password the next time the user tries to access the server. To set the password expiration period for selected administrators or client nodes, you must specify the administrator or node names with the ADMIN or NODE parameter with the SET PASSEXP command. If you set the expiration period only for selected users, you may set the expiration period from 0-9999 days. A value of 0 means that user's password never expires. For example, to set the expiration period of client node LARRY to 120 days, issue the following command: set passexp 120 node=larry Note:

Once you have explicitly set a password expiration for a node or administrator, it is not modified if you later set a password expiration for all users.

Setting a Limit for Invalid Password Attempts

By default, Tivoli Storage Manager does not check the number of times a user attempts to log in with an invalid password. You can set a limit on consecutive invalid password attempts for all client nodes. When the limit is exceeded, the server locks the node. The following example sets a system-wide limit of three consecutive invalid password attempts: set invalidpwlimit 3 The default value at installation is 0. A value of 0 means that invalid password attempts are not checked. You can set the value from 0 to 9999 attempts. If you initially set a limit of 4 and then change the limit to a lower number, some clients may fail verification during the next login attempt. After a client node has been locked, only a storage administrator with proper authority can unlock the node. For information about unlocking a client or administrator node, see Locking and Unlocking Client Nodes and Locking and Unlocking Administrators from the Server. An administrator can also force a client to change their password on the next login by specifying the FORCEPWRESET=YES parameter on the UPDATE NODE or UPDATE ADMIN command. For more information, refer to Administrator's Reference.

Setting a Minimum Length for a Password

By default, Tivoli Storage Manager does not check the minimum length of a password. The administrator can specify a minimum password length that is required for Tivoli Storage Manager passwords. The following example shows how to set the minimum password length to eight characters: set minpwlength 8 The default value at installation is 0. A value of 0 means that password length is not checked. You can set the length value from 0 to 64.

Disabling the Default Password Authentication

By default, the server automatically sets password authentication on. With password authentication set to on, all users must enter a password when accessing the server. To allow administrators and client nodes to access the server without entering a password, issue the following command: set authentication off Attention: Setting password authentication off reduces data security.