Managing client nodes includes:
Task | Required Privilege Class |
---|---|
Register client nodes to specific policy domains and assign the nodes to a specified client option set | System, unrestricted policy, or restricted policy for those domains |
Update, rename, lock, or unlock any client nodes | System, unrestricted policy |
Update, rename, lock, or unlock client nodes assigned to specific policy domains | System, unrestricted policy, or restricted policy for those domains |
Define client options from the server | System or unrestricted policy |
Request information about client nodes or file spaces | Any administrator |
Delete any file space from storage pools | System or unrestricted policy |
Delete file spaces defined for client nodes assigned to specific policy domains | System, unrestricted policy, or restricted policy for those domains |
Remove any client nodes | System or unrestricted policy |
Remove client nodes assigned to specific policy domains | System, unrestricted policy, or restricted policy for those domains |
Central client configuration allows an administrator to define a set of client options to be used by a client node at TSM Version 3. The client options specified in the set are used in conjunction with the client options file. This allows an administrator to specify additional options that may not be included in the client's option file. Specify 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.
To define a client option set and have the clients use the option set, do the following:
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. |
You can set client options in a defined client option set.
The following example shows how to set 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 include d:\admin define clientopt engbackup 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 include d:\admin sequence=2 define clientopt engbackup include d:\payroll sequence=1
The FORCE parameter allows an administrator to specify whether a client node can override an option value. The default value is NO. If FORCE=YES, the client cannot override the value.
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.
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
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
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
To display information about the contents of a client option set, issue the following command:
query cloptset financeschd
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'
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
You can control client node access to the server by updating or renaming client nodes or by locking and unlocking client nodes from the server.
You can update the following client node information:
Note: | An administrator with restricted policy privilege must be authorized to the current policy domain and to the new policy domain. |
For example, you can update client node TOMC to prevent him from deleting archived files from storage pools by entering:
update node tomc archdelete=no
You can rename a client node if the workstation network name or host name changes.
For example, with UNIX systems, users define their node name based on the value returned by the HOSTNAME command. When users access the server, their TSM 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.
You can prevent a client node from accessing the server and performing functions such as back up and restore or archive and retrieve. You can later let the client node reaccess the server. 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
The following can use enterprise logon:
Enterprise logon enables a user with the proper administrative user ID and password to access a TSM client for help desk activities, such as performing a client restore operation. This also allows for a native backup-archive client to log on to TSM using their node name and password, or administrative user ID and password if they are configured to access a 3.7.0 server or above. A user can temporarily access their node's data from another machine by using the VIRTUALNODENAME option. Refer to Using the Backup-Archive Client guide for your particular platform for details.
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=CLIENT and AUTH=ACCESS or AUTH=OWNER parameters on the GRANT AUTHORITY command. The administrator must have one of the following privileges to grant or revoke client access or client owner authority:
You can grant an administrator client access authority to individual clients or you can grant an administrator client access to all clients in a specified policy domain. For example, you may want to grant client access privileges to all nodes for individuals that staff help desk environments.
The following describes the difference between client owner and client access privileges:
The administrator can change the client node's password for which they have authority.
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. An administrative user ID with client access privilege cannot directly access client's data from a native backup-archive client. A system or policy administrator has client access privileges by default.
To grant client access authority to administrator FRED for the LABCLIENT node, issue:
grant authority fred class=client auth=access domain=primary 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=owner auth=owner domain=primary node=student1
The administrator ADMIN1 can now perform backup and restore operations for the STUDENT1 client node. The administrator can also restore files from the STUDENT1 client node to a different client node.
An administrator can use the REGISTER NODE command to automatically create an administrative user ID with client owner authority to a node when the node is defined to the server. By default, the server creates an administrative user ID in addition to the client node entry. For example, you want to register client node DESK2, issue:
register node desk2 pass2dsk
The DESK2 client node is registered, in addition to an administrator user ID with the same DESK2 ID. The administrator DESK2 has a password of pass2dsk. The DESK2 administrator now has client owner authority to the DESK2 node. If the PASSWORDACCESS=GENERATE option is used by the client to change the password, the administrative DESK2 ID can access the client from a remote location.
An administrator can prevent automatic creation of an administrative user ID with client owner authority by specifying ACCESSUSERID=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
You can grant client owner authority to an existing administrative user ID. This is useful if you want to set up enterprise logon for a remote help desk. For example, to give client access 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.
You can request 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.
You can display information about client nodes assigned to specific policy domains. For example, to view information about client nodes assigned to STANDARD and ENGPOLDOM policy domains, enter:
query node * domain=standard,engpoldom
The output from that command might look like this:
+--------------------------------------------------------------------------------+ |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 | | | +--------------------------------------------------------------------------------+
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 would look like this:
+--------------------------------------------------------------------------------+ | | | 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:2121 | | Node Type: Client | | Password Expiration Period: 60 | | Keep Mount Point?: No | +--------------------------------------------------------------------------------+
A file space name identifies a group of files that are stored as a logical unit in server storage. On registered client nodes, users can define file spaces for their workstation.
On client nodes such as OS/2 or DOS, a file space name identifies a logical partition, such as the volume label of a disk drive. For example, a volume with the label XYZ is a different file space from a volume with the label ABC.
On client nodes such as AIX or SunOS, a file space name identifies a file system or file space defined by a user with the VIRTUALMOUNTPOINT option. With this option, users can 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 Using the Backup-Archive Client.
You can display file space information in order to:
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 PEASE, enter:
query filespace pease *
The following figure shows the output from this command. The report shows that client node ID PEASE:
+--------------------------------------------------------------------------------+ |Node Name Filespace Platform Filespace Capacity %Util | | Name Type (MB) | |------------------------------ ----------- -------- --------- -------- ----- | |PEASE /home/peas- AIX JFS 196.0 91.7 | | e/dir | |PEASE /home/peas- AIX JFS 328.0 81.0 | | e/dir1 | |PEASE /home/peas- AIX JFS 46.9 96.0 | | e/dir2 | | | +--------------------------------------------------------------------------------+
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 belonging to the node.
You may want to delete a file space when:
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 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
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.
After all file spaces belonging to a client node have been deleted (see Deleting a File Space), you can delete the client node.
For example, to remove client node DEBBYG, enter:
remove node debbyg