planning, installation, and...
TRANSCRIPT
IBM Tivoli License Manager
Planning, Installation, and Configuration
Version 2.1
SC32-1431-01
���
IBM Tivoli License Manager
Planning, Installation, and Configuration
Version 2.1
SC32-1431-01
���
Second Edition, October 2004
This edition applies to version 2.1 of IBM Tivoli License Manager (program number 5724-D33) and to all subsequent
releases and modifications until otherwise indicated in new editions.
IBM welcomes your comments.
Address your comments to:
IBM License Management Information Development
Rome Tivoli Lab
IBM Italia S.p.A.
Via Sciangai, 53
00144 Rome
Italy
Fax Number: (+39) 06 5966 2077
Internet ID: [email protected]
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 2002, 2004. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Note
Before using this information and the product it supports, read the information under “Notices” on page 319.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Who should read this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
What this guide contains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Tivoli License Manager library . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Accessing publications online . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Ordering publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Tivoli technical training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Contacting software support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Determine the business impact of your problem . . . . . . . . . . . . . . . . . . . . . xviii
Describe your problem and gather background information . . . . . . . . . . . . . . . . . xviii
Submit your problem to IBM Software Support . . . . . . . . . . . . . . . . . . . . . . xix
Searching knowledge bases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Search the information center on your local system or network . . . . . . . . . . . . . . . . xix
Search the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Obtaining fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Updating support information . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Conventions used in this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Typeface conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Operating system-dependent notation . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Chapter 1. Plan to deploy IBM Tivoli License Manager . . . . . . . . . . . . . . . . 1
Tivoli License Manager infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
The main components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
The logical structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Implementation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Catalog management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Tivoli Data Warehouse enablement . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Determine the Tivoli License Manager topology . . . . . . . . . . . . . . . . . . . . . . . 9
Organizational topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Component topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Supported platforms for servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Supported platforms for databases . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Supported platforms for agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Supported platforms for the catalog manager . . . . . . . . . . . . . . . . . . . . . . . 15
Determine inter-component communications . . . . . . . . . . . . . . . . . . . . . . . . 15
SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Why use SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
The disadvantages of SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
How SSL works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
How SSL is implemented in Tivoli License Manager . . . . . . . . . . . . . . . . . . . . 17
How you get an SSL server certificate . . . . . . . . . . . . . . . . . . . . . . . . 18
How to configure for SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Inter-component passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Alternative runtime servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Planning to install and configure the components . . . . . . . . . . . . . . . . . . . . . . 22
The packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Plan how to install the server and database components . . . . . . . . . . . . . . . . . . . 23
© Copyright IBM Corp. 2002, 2004 iii
Choosing the install method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Prerequisites for administration and runtime servers . . . . . . . . . . . . . . . . . . . 25
Prerequisites for databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Obtaining and installing the prerequisite software . . . . . . . . . . . . . . . . . . . . 31
Auto-installation of prerequisite software . . . . . . . . . . . . . . . . . . . . . . . 32
Avoiding port conflicts with WebSphere Application Server . . . . . . . . . . . . . . . . . 35
Additional prerequisites for installing servers and databases using Tivoli Configuration Manager . . . . 36
Preparing the required installation information . . . . . . . . . . . . . . . . . . . . . 37
Plan how to configure your Tivoli License Manager environment . . . . . . . . . . . . . . . . 37
Plan how to operate Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . . . 41
Web user interface prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Plan how to deploy the agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Agent prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Agent deployment parameter preparation . . . . . . . . . . . . . . . . . . . . . . . 45
Using Web deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Using the installagent command . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Using Tivoli Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . 48
Using SSH or RSH for UNIX nodes . . . . . . . . . . . . . . . . . . . . . . . . . 49
Using Windows logon scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Deploying OS/400 agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Scheduling the agent deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Plan how to install the catalog manager . . . . . . . . . . . . . . . . . . . . . . . . . 55
Catalog manager prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Additional prerequisites for installing the catalog manager using Tivoli Configuration Manager . . . . . 57
Optionally plan how to deploy the Tivoli Data Warehouse enablement pack . . . . . . . . . . . . . 57
Data Warehouse prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Plan how to populate the databases . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Estimating the maximum time required to upload inventory scans . . . . . . . . . . . . . . . 59
Uninstalling, refreshing, repeat installations . . . . . . . . . . . . . . . . . . . . . . . . 59
Chapter 2. Install Tivoli License Manager main components . . . . . . . . . . . . . 61
Install scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Pre-install tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Installing the main components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Choosing the install method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Installing components on the same computer in more than one pass . . . . . . . . . . . . . . . 70
Using the install wizard in interactive mode . . . . . . . . . . . . . . . . . . . . . . . 70
Starting the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Typical installation of the runtime components . . . . . . . . . . . . . . . . . . . . . 82
Typical installation of the administration components . . . . . . . . . . . . . . . . . . . 83
Custom installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
All components installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Completing the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
What to do if the wizard fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Chapter 3. Configure Tivoli License Manager . . . . . . . . . . . . . . . . . . . 95
Configure the administration server . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Perform the organization-related initial tasks . . . . . . . . . . . . . . . . . . . . . . . . 96
Configure the runtime servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Configure SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Configuration procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Configuring SSL for communications from the administration server to the runtime server . . . . . . . 99
Configuring SSL for communications from the runtime server to the administration server . . . . . . 101
Configuring SSL for communications from Web browsers . . . . . . . . . . . . . . . . . 102
Configuring SSL for communications from the agent to the runtime server . . . . . . . . . . . . 104
Configuration activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Enabling SSL for the Web server . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Disabling encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Set SSL port aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
iv IBM Tivoli License Manager: Planning, Installation, and Configuration
Configure the runtime server to send secure communications . . . . . . . . . . . . . . . . 110
Change the SSL password . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Request a server certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Create a server certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Create a server certificate as a Certificate Authority . . . . . . . . . . . . . . . . . . . . 114
Add a certificate to the database . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Register the runtime server to be contacted using SSL communication . . . . . . . . . . . . . 114
Using the HTTPS protocol between browsers and servers . . . . . . . . . . . . . . . . . 115
Disabling secure communications . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Using the HTTP protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Deleting the virtual host definition . . . . . . . . . . . . . . . . . . . . . . . . . 116
Restoring default port aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configure the mail notification settings for a server . . . . . . . . . . . . . . . . . . . . . . 117
Customize the Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Define the authentication method . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
XML or Database Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
LDAP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Importing account data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Configuring proxy servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Automatic computer label assignment . . . . . . . . . . . . . . . . . . . . . . . . . . 132
The effect of automatic computer label assignment . . . . . . . . . . . . . . . . . . . . . 132
Implementing automatic computer label assignment . . . . . . . . . . . . . . . . . . . . 133
Import an up-to-date version of the IBM Catalog . . . . . . . . . . . . . . . . . . . . . . 134
Other configuration procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Optionally configure a server on UNIX to run under a non-root user. . . . . . . . . . . . . . . 134
Optionally configure Java 2 Security for a server . . . . . . . . . . . . . . . . . . . . . 135
Tuning your environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Tuning Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Tuning DB2 and WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . 136
Chapter 4. Deploy agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Deploying an agent over the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Deploying the agent manually (installagent command) . . . . . . . . . . . . . . . . . . . . 145
Parameters of the installagent command . . . . . . . . . . . . . . . . . . . . . . . . 147
Specifying installagent parameters in the command line . . . . . . . . . . . . . . . . . . . 149
Specifying installagent parameters in a file . . . . . . . . . . . . . . . . . . . . . . . 150
Examples of installagent command use . . . . . . . . . . . . . . . . . . . . . . . . . 151
Example of installagent command without proxy . . . . . . . . . . . . . . . . . . . . 151
Example of installagent command with proxy . . . . . . . . . . . . . . . . . . . . . 151
Example of installagent command on Linux390 with proxy . . . . . . . . . . . . . . . . . 152
Deploying agents using Tivoli Configuration Manager . . . . . . . . . . . . . . . . . . . . . 152
Deploying agents to UNIX nodes using SSH and RSH . . . . . . . . . . . . . . . . . . . . . 162
Deploy agents using Windows logon scripts . . . . . . . . . . . . . . . . . . . . . . . . 170
Install agents on OS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Install the OS/400 agent from a Windows node . . . . . . . . . . . . . . . . . . . . . . 175
Installing the agent interactively . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Installing the agent silently . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Install the OS/400 agent on an iSeries node . . . . . . . . . . . . . . . . . . . . . . . 182
Saving and Restoring the agent to a different iSeries node . . . . . . . . . . . . . . . . . . 183
Deploying the WebSphere Application Server agent . . . . . . . . . . . . . . . . . . . . . 185
Chapter 5. Install the catalog manager . . . . . . . . . . . . . . . . . . . . . 187
Pre-install tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Install procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Choosing the installation method . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Using the install wizard in interactive mode . . . . . . . . . . . . . . . . . . . . . . . 191
Problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Configuring the catalog manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Multi-catalog setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Selecting the correct catalog to manage . . . . . . . . . . . . . . . . . . . . . . . . 199
Contents v
Chapter 6. Migrate to version 2.1 . . . . . . . . . . . . . . . . . . . . . . . . 201
Chapter 7. Uninstall Tivoli License Manager . . . . . . . . . . . . . . . . . . . 203
Uninstalling the Tivoli License Manager server and database components . . . . . . . . . . . . . . 203
Planning whether to drop the databases . . . . . . . . . . . . . . . . . . . . . . . . 205
Using the uninstall wizard in interactive mode . . . . . . . . . . . . . . . . . . . . . . 206
What to do if the uninstallation fails . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Dropping the Tivoli License Manager databases manually . . . . . . . . . . . . . . . . . . 207
Dropping the Tivoli License Manager databases on Windows . . . . . . . . . . . . . . . . 207
Dropping the Tivoli License Manager databases on UNIX . . . . . . . . . . . . . . . . . 208
Uninstalling the agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Uninstall agents on Windows platforms . . . . . . . . . . . . . . . . . . . . . . . . 209
Uninstall agents on UNIX platforms . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Uninstall agents on OS/400 platforms . . . . . . . . . . . . . . . . . . . . . . . . . 209
Uninstall the OS/400 agent directly on an iSeries node . . . . . . . . . . . . . . . . . . 209
Uninstall the OS/400 agent interactively from a Windows node . . . . . . . . . . . . . . . 210
Uninstall the OS/400 agent using DLTLICPGM . . . . . . . . . . . . . . . . . . . . . 211
Uninstalling the catalog manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
What to do if the catalog manager uninstallation fails . . . . . . . . . . . . . . . . . . . . 213
Chapter 8. Upgrading from Tivoli License Manager for IBM software . . . . . . . . 215
Chapter 9. The agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Summary of agent functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Agent functionality on OS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Managing privacy policies for computers and users . . . . . . . . . . . . . . . . . . . . . 219
Files required by the installagent command . . . . . . . . . . . . . . . . . . . . . . . . 219
Agent files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
AIX agent files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
HP/UX agent files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Linux agent files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
OS/400 agent files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Sun agent files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Windows agent files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Agent commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
AIX – additional commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
HP/UX – additional commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Sun and Linux platforms – additional commands . . . . . . . . . . . . . . . . . . . . . 229
OS/400 platforms – additional commands . . . . . . . . . . . . . . . . . . . . . . . . 229
WebSphere Application Server agent commands . . . . . . . . . . . . . . . . . . . . . . 230
Reviewing and deleting agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Redeploying an agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Agent self-update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Appendix A. Configuration settings . . . . . . . . . . . . . . . . . . . . . . . 233
Tivoli License Manager configuration files . . . . . . . . . . . . . . . . . . . . . . . . . 233
Default values in configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Ranges in configuration file tables . . . . . . . . . . . . . . . . . . . . . . . . . . 234
The system.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Timing of events and services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Synchronizing the servers’ base times . . . . . . . . . . . . . . . . . . . . . . . . 236
Web Interface settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Administration server settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Runtime server settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Agent settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
E-mail configuration settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
The communication.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Backup and restore of configuration files . . . . . . . . . . . . . . . . . . . . . . . . . 246
The backup and restore commands . . . . . . . . . . . . . . . . . . . . . . . . . . 246
backupconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
vi IBM Tivoli License Manager: Planning, Installation, and Configuration
restoreconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Appendix B. Installation parameter list and checklists . . . . . . . . . . . . . . . 251
Install parameter list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Administration components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Runtime components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Bundled DB2 checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Bundled WebSphere Application Server checklist . . . . . . . . . . . . . . . . . . . . . . 262
Agent checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Catalog manager checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Appendix C. Response files and software package blocks for silent and remote
installations and uninstallations . . . . . . . . . . . . . . . . . . . . . . . . 267
Server and database silent installations . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Which installation parameters are required? . . . . . . . . . . . . . . . . . . . . . . . 268
Parameters used in all installations . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Parameters used in all custom installations . . . . . . . . . . . . . . . . . . . . . . . 273
Parameters used only if you are installing either server, or both, without any databases . . . . . . . . 273
Parameters used only if your installation includes a database . . . . . . . . . . . . . . . . . 274
Parameters used only if your installation includes a server . . . . . . . . . . . . . . . . . . 275
Parameters used in all custom installations of the administration server without its database . . . . . . . 275
Parameters used in all installations that include a runtime server . . . . . . . . . . . . . . . . 276
Additional parameters used in all custom installations that include a runtime server . . . . . . . . . 276
Additional parameters used in all custom installations that include a runtime server without the
administration server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Additional parameters used in all custom installations that include a runtime server without its database . . 277
Parameters used in an All components (Full) installation, on Linux for zSeries . . . . . . . . . . . 278
Parameters used to install the bundled DB2 prerequisite . . . . . . . . . . . . . . . . . . . 278
Parameters used to install the bundled WebSphere Application Server prerequisite . . . . . . . . . . 279
Software package block keys for server and database installations using Tivoli Configuration Manager . . . . 280
Server and database silent uninstallations . . . . . . . . . . . . . . . . . . . . . . . . . 285
Catalog manager silent installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Software package block for catalog manager installation using Tivoli Configuration Manager . . . . . . . 288
Silent installation of OS/400 agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Appendix D. Common tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Starting and stopping a Tivoli License Manager server . . . . . . . . . . . . . . . . . . . . 295
Initializing the DB2 command line . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Starting and stopping the IBM HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . 296
Starting the WebSphere Administrator’s Console . . . . . . . . . . . . . . . . . . . . . . 297
Changing passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Appendix E. Database table cleanup . . . . . . . . . . . . . . . . . . . . . . 301
Performance and sizing considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Setting parameters for cleanup processes . . . . . . . . . . . . . . . . . . . . . . . . . 301
Appendix F. UNIX agent deployment wizard import file formats . . . . . . . . . . . 303
Agents’ import format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Import format for agents on Linux s390 . . . . . . . . . . . . . . . . . . . . . . . . 306
Topology import format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Appendix G. Enabling graphics for an administration server on UNIX (X-display) . . . 311
Enabling X display locally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Enabling X display remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Appendix H. Running elements of the install or uninstall procedures manually . . . . 313
Creating and populating a database for Tivoli License Manager . . . . . . . . . . . . . . . . . 313
Connecting a Tivoli License Manager database to its server . . . . . . . . . . . . . . . . . . . 314
Disconnecting a Tivoli License Manager database from its server . . . . . . . . . . . . . . . . . 315
Contents vii
Appendix I. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Other prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
viii IBM Tivoli License Manager: Planning, Installation, and Configuration
Figures
1. Three-tiered topology of Tivoli License Manager components . . . . . . . . . . . . . . . . . 3
2. Tivoli License Manager structure with multiple runtime servers . . . . . . . . . . . . . . . . 4
3. Monitoring needs of a large company . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Tivoli License Manager structure at a large organization . . . . . . . . . . . . . . . . . . . 7
5. Starting the installation: panel flow . . . . . . . . . . . . . . . . . . . . . . . . . 71
6. Typical, Custom or All components installation: panel flow . . . . . . . . . . . . . . . . . 72
7. Completing the installation: panel flow . . . . . . . . . . . . . . . . . . . . . . . . 73
8. SSL channel configuration possibilities . . . . . . . . . . . . . . . . . . . . . . . . 99
9. Configuring SSL from administration server to runtime server . . . . . . . . . . . . . . . . 99
10. Configuring SSL from runtime server to administration server . . . . . . . . . . . . . . . . 101
11. Configuring SSL from Web browser to servers . . . . . . . . . . . . . . . . . . . . . 102
12. Configuring SSL between agents and runtime servers . . . . . . . . . . . . . . . . . . . 104
© Copyright IBM Corp. 2002, 2004 ix
x IBM Tivoli License Manager: Planning, Installation, and Configuration
Tables
1. Test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Supported server platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Supported agent platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. SSL implementation in Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . . 17
5. Additional patches, service packs, patches for the bundled DB2 . . . . . . . . . . . . . . . . 33
6. Additional patches, service packs, patches for the bundled WebSphere Application Server . . . . . . . 34
7. Supported browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8. Base configuration parameter panels . . . . . . . . . . . . . . . . . . . . . . . . . 85
9. Agent files on AIX platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
10. Agent files on HP/UX platforms . . . . . . . . . . . . . . . . . . . . . . . . . . 222
11. Agent files on Linux platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
12. Agent files on OS/400 platforms . . . . . . . . . . . . . . . . . . . . . . . . . . 224
13. Agent files on Sun platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
14. Agent files on Windows platforms . . . . . . . . . . . . . . . . . . . . . . . . . 226
15. Tlmagent command parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 227
16. Agent commands on AIX platforms . . . . . . . . . . . . . . . . . . . . . . . . . 228
17. Agent commands on UNIX platforms . . . . . . . . . . . . . . . . . . . . . . . . 229
18. Agent commands on Sun and Linux platforms . . . . . . . . . . . . . . . . . . . . . 229
19. Agent commands on OS/400 platforms . . . . . . . . . . . . . . . . . . . . . . . . 229
20. Agent commands on OS/400 platforms . . . . . . . . . . . . . . . . . . . . . . . . 230
21. Configuration files for Tivoli License Manager servers . . . . . . . . . . . . . . . . . . . 233
22. Web interface parameters in the system.properties file . . . . . . . . . . . . . . . . . . . 236
23. Administration server parameters in the system.properties file . . . . . . . . . . . . . . . . 237
24. Runtime server parameters in the system.properties file . . . . . . . . . . . . . . . . . . 239
25. Agent parameters in the system.properties file . . . . . . . . . . . . . . . . . . . . . 242
26. E-mail configuration parameters in the system.properties file . . . . . . . . . . . . . . . . 243
27. Parameters in the communications.properties file . . . . . . . . . . . . . . . . . . . . 244
28. Commands required to backup and restore the configuration files . . . . . . . . . . . . . . . 246
29. Parameter table for installation options . . . . . . . . . . . . . . . . . . . . . . . . 252
30. Administration components install parameter values . . . . . . . . . . . . . . . . . . . 254
31. Administration components configuration checklist . . . . . . . . . . . . . . . . . . . . 254
32. Runtime components install parameter values . . . . . . . . . . . . . . . . . . . . . 257
33. Runtime components configuration checklist . . . . . . . . . . . . . . . . . . . . . . 257
34. Bundled DB2 install parameter values . . . . . . . . . . . . . . . . . . . . . . . . 261
35. Bundled WebSphere Application Server install parameter values . . . . . . . . . . . . . . . 262
36. Runtime server-specific agent deployment parameter values . . . . . . . . . . . . . . . . . 263
37. Runtime server-specific agent deployment parameter values . . . . . . . . . . . . . . . . . 263
38. Catalog manager install parameter values . . . . . . . . . . . . . . . . . . . . . . . 265
39. Parameters required for silent installation options . . . . . . . . . . . . . . . . . . . . 269
40. Server and database silent install parameters: all installations . . . . . . . . . . . . . . . . 272
41. Server and database silent install parameters: all custom installations . . . . . . . . . . . . . . 273
42. Server and database silent install parameters: any server but no databases . . . . . . . . . . . . 274
43. Server and database silent install parameters . . . . . . . . . . . . . . . . . . . . . . 274
44. Server and database silent install parameters: any server . . . . . . . . . . . . . . . . . . 275
45. Server and database silent install parameters: administration server without database . . . . . . . . 275
46. Server and database silent install parameters: all runtime server installations . . . . . . . . . . . 276
47. Server and database silent install parameters: custom runtime server . . . . . . . . . . . . . . 276
48. Server and database silent install parameters: runtime server with no administration server . . . . . . 277
49. Server and database silent install parameters: runtime server with no runtime database . . . . . . . . 277
50. Server and database silent install parameters: all components on Linux for zSeries . . . . . . . . . 278
51. Server and database silent install parameters: bundled DB2 prerequisite . . . . . . . . . . . . . 278
52. Server and database silent install parameters: bundled WebSphere Application Server prerequisite . . . . 279
53. Software package block keys for server and database installations . . . . . . . . . . . . . . . 281
54. Server and database silent uninstall parameters . . . . . . . . . . . . . . . . . . . . . 286
55. Catalog manager silent install parameters . . . . . . . . . . . . . . . . . . . . . . . 287
© Copyright IBM Corp. 2002, 2004 xi
56. Software package block keys for catalog manager installation . . . . . . . . . . . . . . . . 289
57. OS/400 silent install parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 291
xii IBM Tivoli License Manager: Planning, Installation, and Configuration
About this guide
This guide contains information about planning, installing, and configuring IBM®
Tivoli® License Manager.
The product is available in two versions:
Tivoli License Manager
This version monitors products from multiple vendors.
Tivoli License Manager for IBM software
This version only monitors IBM products.
All that is written in this guide applies to both versions, unless specifically stated
otherwise.
Who should read this guide
This guide is for system administrators who are responsible for setting up the
license management environment.
What this guide contains
This guide contains the following sections:
v Chapter 1, “Plan to deploy IBM Tivoli License Manager”
Provides an overview of the monitoring infrastructure and a list of issues you
should take into account when planning to install Tivoli License Manager.
v Chapter 2, “Install Tivoli License Manager main components”
Provides instructions for installing the main server and database components of
the product.
v Chapter 3, “Configure Tivoli License Manager”
Provides instructions for configuring the main server and database components
of the product, after installation.
v Chapter 4, “Deploy agents”
Provides instructions for deploying agents on computers that you want to
monitor.
v Chapter 5, “Install the catalog manager”
Provides instructions for installing the catalog manager.
v Chapter 6, “Migrate to version 2.1”
Provides information about migrating the servers, databases and agents from a
prior version.
v Chapter 7, “Uninstall Tivoli License Manager”
Provides instructions for uninstalling all Tivoli License Manager components.
v Chapter 8, “Upgrading from Tivoli License Manager for IBM software”
Provides instructions for upgrading Tivoli License Manager for IBM software to
the full version.
v Chapter 9, “The agent”
Summarizes agent functionality and provides instructions for the use of the
agent command line. Also contains descriptions of the files used by the agent.
© Copyright IBM Corp. 2002, 2004 xiii
v Appendixes, including information about the following topics:
– Appendix A, “Configuration settings”
Provides full details of customizable configuration parameters for servers and
agents.
– Appendix B, “Installation parameter list and checklists”
Provides check lists of information required and configuration steps to be
performed for all components. Also provides a table of the install parameters
appropriate to each type of installation and combination of installed
components.
– Appendix C, “Response files and software package blocks for silent and
remote installations and uninstallations”
Provides full details of the parameters used by the silent install and uninstall
options that enable you to install or uninstall components without using a
graphical interface.
– Appendix D, “Common tasks”
Describes certain tasks that you might need to perform on the servers in a
variety of situations.
– Appendix E, “Database table cleanup”
Provides instructions for configuring the regular task to clear old entries from
certain database tables.
– Appendix F, “UNIX agent deployment wizard import file formats”
Provides information about the file formats used by the agent deployment
wizard to import your Tivoli License Manager topology or to import a list of
agents to be deployed.
– Appendix G, “Enabling graphics for an administration server on UNIX
(X-display)”
Describes how to connect to an X-display server on UNIX® platforms.
– Appendix H, “Running elements of the install or uninstall procedures
manually”
Describes how to run selected installation procedures manually. Used in the
case where the install wizard fails to complete one or more procedures, and
you choose to complete them manually, rather than to uninstall and reinstall
the components.
– Appendix I, “Prerequisites”
Prerequisite information for all of the components, wizards and options is
provided in the planning chapter. This appendix provides a series of links to
that prerequisite information, enabling you to easily locate all of the
prerequisite information.
Publications
This section lists publications in the Tivoli License Manager library and related
documents. It also describes how to access Tivoli publications online and how to
order Tivoli publications.
xiv IBM Tivoli License Manager: Planning, Installation, and Configuration
Tivoli License Manager library
The Tivoli License Manager library consists of the following books:
v IBM Tivoli License Manager: Administration, SC32-1430
Provides an overview of Tivoli License Manager and gives information about
how to use the product to set up a monitoring infrastructure, define licensing
conditions, and produce reports.
v IBM Tivoli License Manager: Planning, Installation, and Configuration, SC32-1431
Provides information about planning, installing, and configuring the Tivoli
License Manager product
v IBM Tivoli License Manager: Data Dictionary, SC32-1432
Provides descriptions of the database tables and indexes maintained in the Tivoli
License Manager administration server database.
v IBM Tivoli License Manager: Problem Determination, SC32-9102
Provides information about Tivoli License Manager diagnostic information,
including messages, traces, and event logs, and about tools and techniques for
diagnosing problems.
v IBM Tivoli License Manager: Catalog Management, SC32-1434
Describes how to use the software catalog management tool to maintain an
up-to-date master catalog of products and the modules that are used to detect
their presence and use on monitored computers.
v IBM Tivoli License Manager, Version 2.1: Warehouse Enablement Pack, Version 2.1.0
Implementation Guide for Tivoli Data Warehouse, Version 1.2, SC32-1433
Provides instructions and other information related to enabling the use of Tivoli
Data Warehouse with Tivoli License Manager.
v IBM Tivoli License Manager: Release Notes, SC32-1429
Provides a summary of changes made in the release, lists the supported
platforms for each component, documents known errors and workarounds, and
includes the latest information about the product that could not be included in
the main documentation. This document is not delivered on the publications CD,
but is available from the Tivoli Software Information Center. Updated versions
of the document may be placed on the Tivoli Software Information Center at any
time.
How to access the Tivoli Software Information Center is described in “Accessing
publications online” on page xvi.
Related publications
The following documents also provide useful information:
v IBM DB2 Universal Database™: Quick Beginnings for DB2® Servers, GC09-4836
v IBM DB2 Universal Database: Quick Beginnings for DB2 Clients, GC09-4832
These Quick Beginnings guides provide an introduction to installing and
configuring DB2 products.
v www.ibm.com/software/webservers/appserv/infocenter.html provides access to
WebSphere® Application Server product information.
v Redbook: DB2/UDB/WebSphere Performance Tuning Guide, SG246417
This redbook contains useful information about tuning DB2 and WebSphere
Application Server for performance. In particular, see Sections 2.7–2.10, Chapter
3, Sections 3.3-3.5; and Chapters 4 and, 5.
v Redbook: IBM WebSphere V5.0 Performance, Scalability, and High Availability:
WebSphere Handbook Series, SG246198
About this guide xv
This redbook contains useful information about tuning WebSphere Application
Server for performance. In particular, see chapter 18.
v IBM WebSphere Application Server, version 5.0.2: Monitoring and Tuning Performance,
This is the original tuning guide for WebSphere Application Server, version 5.
v DB2 UDB V8 and WebSphere V5: Performance Tuning and Operations Guide,
SG24-7068
This contains useful information for improving the performance of DB2, version
8, and WebSphere Application Server, version 5.
The Tivoli Software Glossary includes definitions for many of the technical terms
related to Tivoli software. The Tivoli Software Glossary is available, in English only,
at the following Web site:
www.ibm.com/software/tivoli/library/
Access the glossary by clicking the Glossary link on the left pane of the Tivoli
software library window.
Accessing publications online
The Tivoli License Manager documentation CD contains the publications that are
in the product library, other than the IBM Tivoli License Manager: Release Notes, in
all supported languages. The format of the publications is PDF, HTML, or both. To
access the publications using a Web browser, open the allpubs.htm file. The file is
in the root directory on the documentation CD. Select the language of your choice,
and an Information Center for the product in that language is displayed. Select the
publication and the format in which you want to view it.
Note: On Windows® platforms, an autorun opens the allpubs.htm file in your
default browser.
IBM posts publications for this and all other Tivoli products, as they become
available and whenever they are updated, to the Tivoli Software Information
Center Web site. Access the Tivoli Software Information Center by first going to the
Tivoli software library at the following Web address:
www.ibm.com/software/tivoli/library/
Scroll down and click the Product manuals link on the left pane of the Tivoli
software library window. In the Tivoli Technical Product Documents Alphabetical
Listing window, click the IBM Tivoli License Manager link to access the product
library at the Tivoli Information Center.
Note: If you print PDF documents on other than letter-sized paper, set the option
in the File → Print window that allows Adobe Reader to print letter-sized
pages on your local paper.
xvi IBM Tivoli License Manager: Planning, Installation, and Configuration
Ordering publications
You can order many Tivoli publications online at the following Web site:
www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi
You can also order by telephone by calling one of these numbers:
v In the United States: 800-879-2755
v In Canada: 800-426-4968
In other countries, see the following Web site for a list of telephone numbers:
www.ibm.com/software/tivoli/order-lit/
Accessibility
Accessibility features help users with a physical disability, such as restricted
mobility or limited vision, to use software products successfully. With this product,
you can use assistive technologies to hear and navigate the interface. You can also
use the keyboard instead of the mouse to operate all features of the graphical user
interface.
This product is operated using a Web browser, which has certain built-in
accessibility features, and has been provided with specific shortcut keys for
navigating the Web interface, starting tasks, and performing toolbar actions.
For additional information, see the Accessibility appendix in the IBM Tivoli License
Manager: Administration.
Tivoli technical training
For Tivoli technical training information, refer to the following IBM Tivoli
Education Web site:
www.ibm.com/software/tivoli/education/
Contacting software support
IBM Software Support provides assistance with product defects.
Before contacting IBM Software Support, your company must have an active IBM
software maintenance contract, and you must be authorized to submit problems to
IBM. The type of software maintenance contract that you need depends on the
type of product you have:
v For IBM distributed software products (including, but not limited to, Tivoli,
Lotus®, and Rational® products, as well as DB2 and WebSphere products that
run on Windows or UNIX operating systems), enroll in Passport Advantage® in
one of the following ways:
– Online: Go to the Passport Advantage Web page and click How to Enroll .
The Web address is the following:
www.lotus.com/services/passport.nsf/WebDocs/Passport_Advantage_Home
About this guide xvii
– By phone: For the phone number to call in your country, go to the IBM
Software Support Web site
(techsupport.services.ibm.com/guides/contacts.html) and click the name of
your geographic region.v For IBM eServer™ software products (including, but not limited to, DB2 and
WebSphere products that run in zSeries®, pSeries®, and iSeries™ environments),
you can purchase a software maintenance agreement by working directly with
an IBM sales representative or an IBM Business Partner. For more information
about support for eServer software products, go to the IBM Technical Support
Advantage Web page (www.ibm.com/servers/eserver/techsupport.html).
If you are not sure what type of software maintenance contract you need, call
1-800-IBMSERV (1-800-426-7378) in the United States or, from other countries, go to
the contacts page of the IBM Software Support Handbook on the Web
(techsupport.services.ibm.com/guides/contacts.html) and click the name of your
geographic region for phone numbers of people who provide support for your
location.
Follow the steps in this topic to contact IBM Software Support:
1. “Determine the business impact of your problem”
2. “Describe your problem and gather background information”
3. “Submit your problem to IBM Software Support” on page xix
Determine the business impact of your problem
When you report a problem to IBM, you are asked to supply a severity level.
Therefore, you need to understand and assess the business impact of the problem
you are reporting. Use the following criteria:
Severity 1 Critical business impact: You are unable to use the program,
resulting in a critical impact on operations. This condition
requires an immediate solution.
Severity 2 Significant business impact: The program is usable but is
severely limited.
Severity 3 Some business impact: The program is usable with less
significant features (not critical to operations) unavailable.
Severity 4 Minimal business impact: The problem causes little impact on
operations, or a reasonable circumvention to the problem has
been implemented.
Describe your problem and gather background information
When explaining a problem to IBM, be as specific as possible. Include all relevant
background information so that IBM Software Support specialists can help you
solve the problem efficiently. To save time, know the answers to these questions:
v What software versions were you running when the problem occurred?
v Do you have logs, traces, and messages that are related to the problem
symptoms? IBM Software Support is likely to ask for this information.
v Can the problem be recreated? If so, what steps led to the failure?
v Have any changes been made to the system? (For example, hardware, operating
system, networking software, and so on.)
v Are you currently using a workaround for this problem? If so, please be
prepared to explain it when you report the problem.
xviii IBM Tivoli License Manager: Planning, Installation, and Configuration
The problem determination toolkit includes commands for assembling problem
determination information for all product components. For more information see
IBM Tivoli License Manager: Problem Determination.
Submit your problem to IBM Software Support
You can submit your problem in one of two ways:
v Online: Go to the ″Submit and track problems″ page on the IBM Software
Support site (www.ibm.com/software/support/probsub.html). Enter your
information into the appropriate problem submission tool.
v By phone: For the phone number to call in your country, go to the contacts page
of the IBM Software Support Handbook on the Web
(techsupport.services.ibm.com/guides/contacts.html) and click the name of your
geographic region.
If the problem you submit is for a software defect or for missing or inaccurate
documentation, IBM Software Support creates an Authorized Program Analysis
Report (APAR). The APAR describes the problem in detail. Whenever possible,
IBM Software Support provides a workaround for you to implement until the
APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the
IBM product support Web pages daily, so that other users who experience the
same problem can benefit from the same resolutions.
For more information about problem resolution, see “Searching knowledge bases”
and “Obtaining fixes” on page xx.
Searching knowledge bases
If you have a problem with your IBM software, you want it resolved quickly. Begin
by searching the available knowledge bases to determine whether the resolution to
your problem is already documented.
Search the information center on your local system or network
IBM provides extensive documentation that can be installed on your local machine
or on an intranet server. You can use the search function of this information center
to query conceptual information, instructions for completing tasks, reference
information, and support documents.
Search the Internet
If you cannot find an answer to your question in the information center, search the
Internet for the latest, most complete information that might help you resolve your
problem. To search multiple Internet resources for your product, expand the
product folder in the navigation frame to the left and select Support on the Web.
From this topic, you can search a variety of resources including:
v IBM technotes
v IBM downloads
v IBM Redbooks™
v IBM DeveloperWorks
v Forums and newsgroups
v Google
About this guide xix
Obtaining fixes
A product fix might be available to resolve your problem. You can determine what
fixes are available for your IBM software product by checking the product support
Web site:
1. Go to the IBM Software Support Web site (www.ibm.com/software/support).
2. Under Products A - Z, select your product name. This opens a product-specific
support site.
3. Under Self help, follow the link to Search all Downloads, where you will find
a list of fixes, fix packs, and other service updates for your product. For tips on
refining your search, click Search tips.
4. Click the name of a fix to read the description and optionally download the fix.
To receive weekly e-mail notifications about fixes and other news about IBM
products, follow these steps:
1. From the support page for any IBM product, click My support in the
upper-right corner of the page.
2. If you have already registered, skip to the next step. If you have not registered,
click register in the upper-right corner of the support page to establish your
user ID and password.
3. Sign in to My support.
4. On the My support page, click Edit profiles in the left navigation pane, and
scroll to Select Mail Preferences. Select a product family and check the
appropriate boxes for the type of information you want.
5. Click Submit.
6. For e-mail notification for other products, repeat Steps 4 and 5.
For more information about types of fixes, see the Software Support Handbook
(techsupport.services.ibm.com/guides/handbook.html).
Updating support information
Information centers typically include one or more support information plug-ins.
These plug-ins add IBM technotes and other support documents to the information
center. The following steps describe how to update your support information
plug-ins:
1. Go to the IBM Software Support Web site (www.ibm.com/software/support).
2. Under Products A - Z, select your product name. This opens a product-specific
support site.
3. Under Search support for this product, type the keyword phrase:
com.ibm.support. Click the Download check box, and click Submit.
4. Check the search results for updates to support information plug-ins. All
support information plug-ins follow the naming convention,
″com.ibm.support.product.doc.″ If an update is available, select it from the list
and view the download instructions.
5. Save the attached zip file to a temporary location on your hard drive.
6. Unzip the downloaded file, making sure that you retain the subfolders.
7. From the location where you unzipped the file, copy the support information
plug-in folder to your Eclipse plug-ins folder. For example, if your IBM
software product is installed at c:\IBM\WebSphere\, copy the updated plug-in
folder (com.ibm.support.product.doc) to c:\IBM\WebSphere\eclipse\plugins.
xx IBM Tivoli License Manager: Planning, Installation, and Configuration
8. To see the updated support information, start the information center (or shut it
down and restart it), and expand the Support information node in the
navigation tree.
Conventions used in this book
This book uses several conventions for special terms and actions, and operating
system-dependent paths.
Typeface conventions
This book uses the following typeface conventions:
Bold
v Lowercase commands and mixed case commands that are
otherwise difficult to distinguish from surrounding text
v Interface controls (check boxes, push buttons, radio buttons, spin
buttons, fields, folders, icons, list boxes, items inside list boxes,
multicolumn lists, containers, menu choices, menu names, tabs,
property sheets), labels (such as Tip:, and Operating system
considerations:)
v Column headings in a table
v Keywords and parameters in text
Italic
v Citations (titles of books, diskettes, and CDs)
v Words defined in text
v Emphasis of words (words as words)
v New terms in text
v Variables and values you must provide
Monospace
v Examples and code examples
v File names, programming keywords, and other elements that are
difficult to distinguish from surrounding text
v Message text and prompts addressed to the user
v Text that the user must type
v Values for arguments or command options
<text> Indicates a variable in a path name. For example, in the path
<INSTALL_DIR>\admin\conf, INSTALL_DIR depends on the location
where you have installed a Tivoli License Manager component,
while \admin\conf is constant.
Operating system-dependent notation
This book uses the Windows convention for environment variables and directory
notation.
When using the UNIX, Linux™, and OS/400® command line you should do the
following:
Environment variables
First verify the correct value for the UNIX, Linux, or OS/400 variable
name, as many variables in different platforms that perform the same task
About this guide xxi
have different names (for example, %TEMP% in Windows is equivalent to
$tmp in UNIX and Linux). Then replace %Windows_variable% with
$UNIX_variable
File and directory paths
Replace each backslash ( \ ) with a forward slash ( / ).
Note: If you are using the bash shell on a Windows system, you can use the UNIX
conventions.
xxii IBM Tivoli License Manager: Planning, Installation, and Configuration
Chapter 1. Plan to deploy IBM Tivoli License Manager
IBM Tivoli License Manager is a Web-based solution that provides software usage
metering and license allocation services on Windows, Linux, and UNIX platforms.
It can be scaled to meet the needs of large and small organizations, and supports
the management of multiple organizations, for example by service providers. IBM
Tivoli License Manager relies on a flexible, three-tiered architecture.
v Small agents, deployed on the machines that are to be monitored
v One or more runtime servers for real time communication and agent monitoring
v One administration server for historical information storing and management
IBM Tivoli License Manager is available in two versions:
IBM Tivoli License Manager
This version monitors products from multiple vendors.
IBM Tivoli License Manager for IBM software
This version only monitors IBM products.
The information in this book is relevant to both IBM Tivoli License Manager and
IBM Tivoli License Manager for IBM software, unless stated otherwise.
This first chapter provides information that helps you to plan your implementation
of Tivoli License Manager. It includes the following sections:
v A short overview of the Tivoli License Manager structure. This aims to provide
you with information about the functions of the system components and how
they fit together to form a monitoring infrastructure. See “Tivoli License
Manager infrastructure” on page 2.
v A discussion of different implementation scenarios, which provides an example
of an implementation spread over multiple sites. See “Implementation scenario”
on page 5.
v Details of all the items to take into consideration when planning the topology of
your Tivoli License Manager environment. See “Determine the Tivoli License
Manager topology” on page 9.
v Details of the supported platforms. See “Supported platforms” on page 12.
v A discussion of the factors that influence the communications between the
components. See “Determine inter-component communications” on page 15.
v Full details of the factors to take into consideration when planning to install the
components, including all the prerequisites. See “Planning to install and
configure the components” on page 22.
v A brief note about refreshing the components of Tivoli License Manager. See
“Uninstalling, refreshing, repeat installations” on page 59.
For those who have already installed a prior version of IBM Tivoli License
Manager, details of how to migrate to version 2.1 are given in Chapter 6, “Migrate
to version 2.1,” on page 201.
© Copyright IBM Corp. 2002, 2004 1
Tivoli License Manager infrastructure
This section describes the infrastructure of the Tivoli License Manager product. It is
divided into the following subsections:
v “The main components” describes the physical infrastructure required to
perform the license management functions of Tivoli License Manager.
v “The logical structure” on page 4 describes the hierarchical structure of the
logical components of Tivoli License Manager.
v “Catalog management” on page 8 describes the facilities provided by Tivoli
License Manager to manage the product software catalog.
v “Tivoli Data Warehouse enablement” on page 8 briefly describes the facilities
provided for extracting data to be used by Tivoli Data Warehouse.
The main components
The basis of the license manager infrastructure are the three physical components
of Tivoli License Manager that can be installed:
Tivoli License Manager agent
A license management agent must be deployed on each organization node that
is to be monitored by Tivoli License Manager. Each agent performs the
following functions:
v Performs an inventory of the software installed on the node and forwards
this information to the runtime server
Note: This functionality is not available on OS/400 nodes.
v Identifies the starting or stopping of a monitored software product and
communicates this information to the runtime server so that a license can be
assigned or released
Tivoli License Manager runtime server
Each Tivoli License Manager installation must have at least one runtime server,
and can have several. Each runtime server provides the following facilities:
v A repository for information about the software installed on the agents that
the server manages
v The capability to assign and release the licenses that are assigned to the
server according to the rules defined for each license pool
v The capability to generate and send e-mails to provide notification about
events that have occurred on the server or its agents
v A Web interface that can be used to deploy the agents to nodes that are to
be monitored and to produce real-time reports of usage of software running
on the monitored agents
Tivoli License Manager administration server
Each Tivoli License Manager installation has a single administration server. It
provides the following facilities:
v A central repository of product, license agreement, license usage, inventory,
and organization information
v A Web interface that can be used to perform license management and
administration tasks and to produce historical reports of license usage and
inventory information over time
Tivoli License Manager provides a flexible structure that can be adapted for large
and small installations. Figure 1 on page 3 shows the three-tiered relationship
between the physical components, which is maintained in all possible
Infrastructure
2 IBM Tivoli License Manager: Planning, Installation, and Configuration
implementations, and the functions of each component. It also shows the primary
user interfaces.
Information is passed between the three components at intervals, the frequency of
which are defined in the Tivoli License Manager configuration files. See
Appendix A, “Configuration settings,” on page 233.
Information that passes between the administration server and the runtime server
can be encrypted in both directions. Information that passes from the agents to the
runtime server can also be encrypted.
It is at the runtime server level that an implementation can be expanded to meet
the needs of larger enterprises. You can install a runtime server component on each
of several computers and allocate monitored nodes to each server. Figure 2 on page
4 shows an expanded infrastructure with multiple runtime servers.
Runtimeserver
Administrationserver
Agents
DBMS
Catalog
Other
Catalogmanager
DBMS
Webinterface
Webinterface
Figure 1. Three-tiered topology of Tivoli License Manager components
Main components
Chapter 1. Plan to deploy IBM Tivoli License Manager 3
Figure 2 shows that each agent is assigned to a specific runtime server. Each
runtime server receives the license requests from the agents that are assigned to it,
and reports software usage from the agents that are assigned to it.
The logical structure
The Tivoli License Manager logical hierarchy divides your enterprise into one or
more organizations, each of which contains one or more divisions.
You can group your whole enterprise into one organization, or split it into several.
What determines your decision are the logical units for which you need to control
software licensing and measure software usage.
Each organization can have only one administration server where a centralized
database of licensing, product, and historical software usage and inventory
information is maintained. No data can be accumulated across organizations and
no licenses can be shared across organizations. Runtime servers and agents belong
to, manage the licenses for, and report the software use for, only one organization.
Thus, if your enterprise consists of a number of completely separate operations
(from a software licensing point-of-view) , you may choose to manage license
information and software usage separately for each of those operations by setting
up each as a separate organization. If organizations are small, they can share an
administration server. If they are large you would need to dedicate one
administration server per organization.
However, there is a disadvantage to dividing your enterprise into multiple
″organizations″. With this option, enterprise-wide reports relating to entitlement
overstate product use because the ″organizations″ are separate and distinct from
each other. Summing the usage peaks from each ″organization″ is likely to yield
higher figures than was actually true. This means that if your primary use of Tivoli
License Manager is to collect software usage data, you would be better to remain
with a single organization.
Divisions are administrative units that give you the ability to perform operations on
a group of agents. For example, inventory scans, which are performed by the
agents, are scheduled at division level; reports can be produced by division; and
license pools can be limited to selected divisions.
Divisions are the lowest structural unit into which an enterprise can be divided.
The grouping of agents into divisions should reflect the structure of the
organization. For example, there might be a division for each department of an
DBMS
Agents
Runtime servers
Administration server
Figure 2. Tivoli License Manager structure with multiple runtime servers
Main components
4 IBM Tivoli License Manager: Planning, Installation, and Configuration
enterprise. However, if the structure of your enterprise requires a deeper
granularity, you could adopt a hierarchical naming convention for divisions that
would allow you to group smaller divisions together to report information relevant
to a department, for example.
Decisions about how to distribute agents between runtime servers do not need to
reflect the organizational structure. The important factor for these decisions is
performance. Agents should be assigned to a runtime server that is local to them
and care should be taken to ensure that the server is not likely to become
overloaded because of too many agents attempting to contact it at the same time.
For this reason, you should split large divisions between more than one runtime
server to avoid overloading of the runtime server when an inventory scan of a
division is performed.
Each runtime server receives the license requests from the agents that are assigned
to it. However, if a runtime server cannot satisfy a license request from its license
pools, the agent can contact another runtime server. The range of runtime servers
that an agent can contact is configurable; see “Agent settings” on page 241.
Possible settings are:
v Allow the agent to contact all runtime servers that are registered for the
organization.
v Allow the agent to contact runtime servers that have agents in the same
division.
v Restrict the agent to its own runtime server.
The default is to allow the agent to contact all servers within the organization. This
structure provides the benefits of improved performance provided by multiple
runtime servers without sacrificing license usage efficiency.
Implementation scenario
To understand the different ways in which Tivoli License Manager can be
implemented to provide a solution to monitoring needs, this section looks at an
example of a large company, with several sites in different countries.
Figure 3 on page 6 shows the structure of an international company with sites in
the UK, Spain, and Italy. It illustrates the organization of the workstations that
need to be monitored.
Logical structure
Chapter 1. Plan to deploy IBM Tivoli License Manager 5
This illustration represents the structure of ACME International, an international
organization with more than 10 000 workstations. There are three sites. The U.K.
site has departments for Administration, Research, and Development, for a total of
8 000 workstations. The Austrian site has Manufacturing and Sales departments,
for a total of 2 500 workstations. This site also has small Administration and
Development departments. The Spanish site has a Help Desk, as well as a small
Administration department, for a total of 1 000 workstations.
Examining the licensing needs of this company, the following is discovered:
v The Administration division purchases its software centrally, and requires all
users to use the same software, regardless of their location.
v All other divisions purchase their software in the country in which they use it,
and have budgets for that purpose.
v The enterprise wants to be able to monitor this policy, so they want to be able to
collect information about software use and licenses at enterprise level.
The decision is made to set up one organization, so that information about
software use can be collected at enterprise level. The following divisions are to be
created:
v Administration
v Research – UK
v Development – UK
v Development – Austria
v Manufacturing – Austria
v Sales – Austria
ACME InternationalAn international organization with more than10000 desktops and servers
U.K. Site.Head office, Research, and Development
Administration 1000 workstationsResearch 2000 workstationsDevelopment 5000 workstations
––
–
Austrian Site.Manufacturing and Sales
Administration 250 workstationsManufacturing 1500 workstationsSales 500 workstationsDevelopment 250 workstations
––
––Spanish Site.
Help Desk
Administration 200 workstationsHelp Desk 800 workstations
––
Figure 3. Monitoring needs of a large company
Logical structure
6 IBM Tivoli License Manager: Planning, Installation, and Configuration
v Help Desk – Spain
With this structure information can be gathered for each division, for each country
and for each department.
Figure 4 shows an implementation of the Tivoli License Manager main components
designed to meet the needs of this company.
This illustration shows an implementation of the Tivoli License Manager servers
and databases that would satisfy the needs of ACME International.
As the largest site and as the site where the administration functions of the
organization are located, the U.K. site has the administration server and associated
DB2 database as well as two runtime servers between which the 8 000 workstations
are shared. The administration server database is installed on a separate computer,
which must have a high-speed connection to the administration server computer. A
single runtime server is installed at each of the smaller sites. Even though it would
be possible, in terms of capacity, for a single runtime server to cover both of the
small sites, each site has a local runtime server, because runtime servers should be
local to the agents they are dealing with to avoid excessive network traffic and to
optimize performance.
In this scenario, the three sites are being monitored as a single entity. License pools
that are applicable to all monitored workstations can be defined, and all software
usage and inventory information can be included in the same reports.
If the enterprise management decide that they would like to separate the license
administration and reporting of the sites, each site might be defined as a separate
organization. This implementation would look exactly the same as the large single
organization implementation shown in Figure 4. There is no need to use additional
resources by installing the administration server component on each site. The
RTAS1 RTES1
2500 workstations
RTUK2Administration
Server
8000 workstations
shared between 2
runtime servers
DB2
Database
Server
1000 workstations
Runtime server
and database
RTUK1
Spanish SiteAustrian Site
U.K. Site
Runtime server
and database
Runtime server
and database
Runtime server
and database
Figure 4. Tivoli License Manager structure at a large organization
Logical structure
Chapter 1. Plan to deploy IBM Tivoli License Manager 7
central administration server would remain on the US site. The difference between
the two implementations is in the accessibility of the data stored in the
administration server database. Each organization registered on the administration
server has its own data, including the components that form its monitoring
infrastructure, the software licenses that are defined, and the usage and inventory
information that is collected by agents. In the original example, there was one
organization structure covering the three sites. An administrator logged on to the
administration server Web interface might obtain reports that included data for all
three sites. In the second example, each site is an organization with its own data
and no single report can include data for more than one of the sites. However, as
discussed above, the reporting of software use by several smaller organizations
may overstate software use if peak uses do not occur at the same time.
Catalog management
Tivoli License Manager includes a catalog manager tool that enables you to
maintain the master catalog of products that you want to monitor.
The Tivoli License Manager for IBM software version does not include the catalog
manager.
The tool has a graphical interface that enables you to perform the following tasks:
v Upload updated catalog information from IBM (if you have the Tivoli License
Manager for IBM software version, this functionality is also provided by a
command run from the administration server command line)
v Set up software in hierarchical structures of products, versions and releases
v Associate executable files with releases
v Integrate unknown executable files found on monitored nodes with the catalog,
setting them up as products
v Add new products, change existing products, and disable products
The tool has no fixed place in the Tivoli License Manager infrastructure, as it can
be installed on the same computer as the administration server database or can be
installed elsewhere and connect to the database using a fast network connection.
The catalog manager can be used to manage the catalogs of any number of
administration server databases.
How the catalog manager tool is installed is described in “Planning to install and
configure the components” on page 22. Detailed instructions on how to use the
catalog manager are given in IBM Tivoli License Manager: Catalog Management.
Tivoli Data Warehouse enablement
Tivoli License Manager is supplied with an enablement pack that enables you to
extract data from the Tivoli License Manager administration server database and
use it in Tivoli Data Warehouse. The Tivoli Data Warehouse documentation gives
you general information about the use of that product, and the IBM Tivoli License
Manager, Version 2.1: Warehouse Enablement Pack, Version 2.1.0 Implementation Guide
for Tivoli Data Warehouse, Version 1.2 describes in full detail what data is extractable,
and what you need to do to extract it.
The packaging for Tivoli License Manager includes a CD containing Tivoli Data
Warehouse, version 1.2. As indicated in the IBM Tivoli License Manager, Version 2.1:
Warehouse Enablement Pack, Version 2.1.0 Implementation Guide for Tivoli Data
Warehouse, Version 1.2, Tivoli Data Warehouse requires the latest fix pack to be
Logical structure
8 IBM Tivoli License Manager: Planning, Installation, and Configuration
installed, which can be downloaded from the fix pack support site.
Determine the Tivoli License Manager topology
The first step is to determine the organizational topology (see “Organizational
topology”) and then the component topology (see “Component topology” on page
10) of your Tivoli License Manager environment.
Organizational topology
Consider the following points:
Computers to be monitored
Identify the workstations and other computers that are to be monitored by
Tivoli License Manager. IBM Tivoli License Manager: Administration describes
the functionality of the product and the information that it can provide.
This helps you decide what you want to monitor. If you have any doubts
about which computers are capable of being monitored, see the agent
prerequisites in Appendix I, “Prerequisites,” on page 317.
Note: You can monitor the computers where servers and databases are
installed. However, you must ensure that entitlement settings for
prerequisite software products, for example WebSphere Application
Server, do not prevent the product from starting when the server
cannot be contacted. For such products the entitlement settings must
always be defined to allow the product to run offline.
Organizations
Determine if these computers are to be monitored under one or under
more organizations. A key factor in this decision is that data cannot be
aggregated or compared across organizations within Tivoli License
Manager. However, using Tivoli Data Warehouse, you can merge the
information coming from more than one organization. But beware that if
your primary purpose for using Tivoli License Manager is the production
of software usage information, it would be better to configure your
enterprise within one organization, to ensure that the peak usages revealed
by the product’s reports relate to your entire enterprise.
Each organization can be served by only one administration server.
However, one administration server can serve more than one organization
Each organization has one or more runtime servers that are dedicated to
that one organization.
The agents that run on the monitored computers can belong to only one
organization at a time.
Divisions
Devise divisions within each organization that reflect a meaningful
breakdown of the organization into units that you want to monitor
separately. The divisions you set up in Tivoli License Manager normally
match the divisions into which your organization is divided
administratively, (for example, Sales, Marketing, Production,
Administration). If you do not wish to monitor at sub-organization level,
you need set up just one division for all computers to be monitored.
Note: Divisions should not be too large. For performance reasons, it is not
advisable to have a very large number of agents in the same
division, especially if they are assigned to a single runtime server.
Determine topology
Chapter 1. Plan to deploy IBM Tivoli License Manager 9
Component topology
You now need to define the components that you will require to support your
organizational topology. This section provides some specific advice about the
capability of the Tivoli License Manager components. Table 1 describes the testing
environment and assumptions used to determine this information.
Table 1. Test environment
Administration server v 4 processors
v 4 GB RAM
v SCSI discs
v Server and database on the same computer
Runtime server v 2 processors
v 2 GB RAM
v SCSI discs
v Server and database on the same computer
Software Standard prerequisites.
Agents Some using SSL to contact the runtime server, some not.
Tivoli License
Manager configuration
Default
Tivoli License
Manager topology
5 organizations, which involved 5 separate administrators using
the GUI (requesting reports, viewing information, distributing
licenses)
Usage workload 4 application uses per hour on each agent, 10-hour working day
Inventory workload 250 detected products per scan per computer (this is significantly
more than the average 60 Windows and less than 60 UNIX
products on a typical workstation)
Given this environment, consider the following points:
Administration server
Assign a computer for the administration server. The administration server
can serve more than one organization, provided that the total number of
runtime servers and agents that connect to it are not so high as to impede
efficiency.
The maximum number of agents that should be connected to one
administration server is 45000.
These agents can be connected through between three and 10 runtime
servers for maximum performance, but probably as many as 20 runtime
servers can be connected without having any significant affect on the
administration server’s performance.
The administration server should be on a dedicated computer. If the
computer is powerful enough, it is probably better to also install the
administration server database on it. However, if you have fast network
connections, there should be no disadvantage in installing it remotely.
Runtime servers
Decide how many runtime servers are required. You should determine the
maximum number of agents that can be assigned to a runtime server
without reducing performance to unacceptable levels.
You should not attach more than 15000 agents to any one runtime server.
Determine topology
10 IBM Tivoli License Manager: Planning, Installation, and Configuration
The runtime server should be on a dedicated computer. The runtime server
database is less heavily used than that of the administration server, and it
is probably better to also install it on the same computer. However, if you
have fast network connections, there should be no disadvantage in
installing it remotely.
As far as is possible you should ensure that each runtime server is in the
same geographical and network location as the agents assigned to it. This
is to keep response time when requesting licenses to a minimum. Further,
if you decide not to implement SSL communications between the runtime
server and the agents, the communications are unencrypted, so for security
reasons it is preferable to keep the runtime server and its agents behind
some sort of common security fence such as a firewall and a proxy server.
For this reason, if your Tivoli License Manager implementation covers
more than one location, it is advisable to have at least one runtime server
at each location.
Another factor to take into consideration is the licenses that are distributed
by means of your runtime servers. A license can be made available to the
agents at more than one runtime server, but you are not recommended to
split the license over more than two runtime servers. The reason for this is
that the administration server makes an arbitrary split of its available
license instances to each of the runtime servers involved in the license
distribution. The more runtime servers are involved, the more likely it is
that an agent is unable to get a license from its registered runtime server,
and has to look for one on the alternate runtime servers, with a consequent
impact on performance.
You should only install a runtime server and the administration server on
the same computer for demonstration or testing purposes. The only
exception to this is if you want to have a working environment with not
more than 250 agents in it, in which case it must be configured as follows:
v The computer must be powerful
v No other runtime servers should be attached to the administration
server
v Unless the computer is very powerful (for example, with 4 processors)
you should install the databases remotely, with fast network connections.
Database sizes
Estimate the database size as 300 MB plus a quota for each agent that is
deployed. For the administration server database, estimate the quota as
400–500 KB for each agent. For each runtime server database, estimate the
quota as 300–400 KB of disk space for each agent that reports to the
runtime server.
Using SSL
The use of SSL between the components is described more fully in “SSL”
on page 16. However, it can be said here that although using SSL can be
measured to have a significant impact on network traffic and CPU usage at
the servers, in practice, using SSL in a working environment does not
produce an unacceptable impact. However, if you want to minimize any
impact you should consider multiple processors and additional memory, to
enable the Web server to work at its encrypting and unencrypting activities
while leaving sufficient processing capacity for the server to perform its
activities without serious impact.
Determine topology
Chapter 1. Plan to deploy IBM Tivoli License Manager 11
Catalog manager
The catalog manager does not need to be installed where the
administration server or its database are installed. The catalog manager has
no specific requirement for a fast connection with the administration server
database, but your use of the tool will be more efficient if it has one.
Maintaining a stable environment
It is important that the Tivoli License Manager components run in a stable
environment. For this aspect, consider the following points:
v The time and time zone settings must be correct on all main
components. If the computers where the main components are installed
are not synchronized in Universal Time Coordinates (UTC), either
through incorrect settings at installation, or by a change of settings
during use, the product may fail or its results become unreliable. From
such a situation there is no recovery. You are also strongly recommended
to install a system that uses the Network Time Protocol to maintain the
correct time on the computers of your main components.
v During the installation you will need to identify the administration
server to its runtime servers. You can do this by host name or IP
address. Attention: Changing the host name or IP address of the administration
server after installing the runtime servers will require you to reconfigure
all runtime servers. It should be avoided.
v During the configuration of the administration server you will need to
identify each runtime server. You will also need to identify the runtime
server to its agents. You can do this by host name or IP address. Attention: Changing the host name or IP address of a runtime server
after the runtime server has been configured at the administration server
will require you to reconfigure the runtime server entries in the
administration server GUI. Changing the host name or IP address after
deploying the agents will require you to redeploy all the agents
registered with it. Changing the host name or IP address of the runtime
server should be avoided.
Supported platforms
This section details the supported platforms for the main components. This
information was correct when this manual was created. However, platform
information may change through the life of a product, as new platforms are
certified. For the most recent information about platforms, consult the supported
platforms matrix on the IBM software support Web site
http://www.ibm.com/support. When you reach the Web site, select a Tivoli
product’s support page. When the page displays, click on the Supported Platforms
link. Click the Tivoli Platform and Database Support Matrix link. You will be
asked for your IBM registration ID and password.
Determine topology
12 IBM Tivoli License Manager: Planning, Installation, and Configuration
Supported platforms for servers
Table 2. Supported server platforms
Platform
Operating
system
Version Level, service packs,
patches
Windows 2000 Server for Intel™ x86 (32-bit) Service Pack 3
2000 Advanced Server for Intel x86 (32-bit)
Server 2003 Standard or Enterprise Edition for Intel
x86 (32-bit)
IBM AIX 5.1 (32-bit)
5.1 (64-bit)
5.2 (32-bit)
5.2 (64-bit)
HP/UX 11i for PA-Risc (32-bit)
11i for PA-Risc (64-bit, in 32-bit compatibility mode)
Red Hat
Enterprise
Linux
ES/AS/WS 2.1 for Intel x86 (Standard or Premium
edition)
Update 2
ES/AS/WS 3.0 for Intel x86 (Standard or Premium
edition)
Update 1
AS, version 3.0 for IBM iSeries and pSeries (64-bit, in
32-bit compatibility mode: Standard or Premium
edition)
Update 2
AS, version 3.0 for IBM zSeries and IBM S/390®
(31-bit: Standard or Premium edition)
Update 1
SUSE
LINUX
Enterprise
Server
8 for x86 (Intel) Service Pack 3
8 for IBM iSeries/pSeries (64-bit, in 32-bit compatibility
mode)
Service Pack 3a for
iSeries
Service Pack 3 for
pSeries
8 for IBM Mainframes (zSeries 31-bit)
Sun Solaris 8 Operating System for SPARC platforms (32-bit)
8 Operating System for SPARC platforms (64-bit)
9 Operating System for SPARC platforms (32-bit)
9 Operating System for SPARC platforms (64-bit)
Note: Platforms that were also supported in version 1.1.1 are shown in italics.
Supported platforms for databases
Platform
Same as the administration and runtime servers: see “Prerequisites for administration and
runtime servers” on page 25.
Supported platforms: servers
Chapter 1. Plan to deploy IBM Tivoli License Manager 13
Supported platforms for agents
Table 3. Supported agent platforms
Platform
Operating
system Version
Levels, service packs,
patches
Windows 2000 Professional for Intel x86 (32-bit) Service Pack 3
2000 Server for Intel x86 (32-bit)
2000 Advanced Server for Intel x86 (32-bit)
Server 2003 Standard or Enterprise Editions for Intel
x86 (32-bit)
XP Professional for Intel x86 (32–bit)
IBM AIX 5.1 (32-bit) Fix
xlC.aix50.rte.6.0.0.0
Patch for APAR
IY52121
5.1 (64-bit)
5.2 (32-bit) Fix
xlC.aix50.rte.6.0.0.0 5.2 (64-bit)
OS/400 V5R2 Option 13 of 5722SS1
The following PTFs
for product 5722SS1:
SI10060, SI07110, and
SI10904
If the agent is
running WebSphere
Application Server,
product 5722AC3 and
PTFs SF99245,
SF99169
If you intend to
implement SSL
between the runtime
server and the agent,
PTFs MF31411,
SI10035, SI10759
V5R3
Note: The name of the OS/400 operating system is
changing with V5R3 to i5/OS™. However, in this
document, OS/400 V5R2 and i5/OS V5R3 are referred
to collectively as OS/400.
Option 13 of 5722SS1
PTF SI12116
HP/UX 11i on PA-Risc 32-bit Patches PHSS_26560,
PHSS_26946, and
PHSS_28880
11i on PA-Risc 64-bit (in 32-bit compatibility mode)
Supported platforms: agents
14 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 3. Supported agent platforms (continued)
Platform
Operating
system Version
Levels, service packs,
patches
Red Hat
Enterprise
Linux
ES/AS/WS, version 2.1 for Intel X86 (Standard or
Premium edition)
Update 2
ES/AS/WS, version 3.0 for Intel X86 (Standard or
Premium edition)
Update 1
AS, version 3.0 for PPC (iSeries and pSeries - 64-bit, in
32-bit compatibility mode)
Update 2
AS, version 3.0 for zSeries and S/390 (31-bit) Update 1
SUSE
LINUX
Enterprise
Server
8 for x86 Service Pack 3
8 for IBM iSeries/pSeries (64-bit, in 32-bit compatibility
mode)
Service Pack 3a for
iSeries
Service Pack 3 for
pSeries
8 for IBM Mainframes (zSeries 31-bit)
Sun Solaris 8 Operating System for SPARC platforms (32-bit) Patches 108434-14,
108528-29, 108991,
108993-31, 111023-03,
111317-05, 111327-05,
113648-03, 115827-01,
and 116602-01
8 Operating System for SPARC platforms (64-bit) Patch 111711–08
9 Operating System for SPARC platforms (32-bit) Patches 108435-14,
108528-29, 108991,
108993-31, 111023-03,
111317-05, 111327-05,
113648-03, 115827-01,
and 116602-01
9 Operating System for SPARC platforms (64-bit) Patch 111712–08
Note: Platforms that were also supported in version 1.1.1 are shown in italics.
Supported platforms for the catalog manager
Platform
The catalog manager can be installed and used on the same platform types where you can
install the server components (see “Prerequisites for administration and runtime servers”
on page 25).
Determine inter-component communications
Determine whether you are going to use “SSL” on page 16, what policy you are
going to adapt for the “Inter-component passwords” on page 21 and what agents
do when they need to contact “Alternative runtime servers” on page 22 because
their own runtime server is not contactable.
Supported platforms: agents
Chapter 1. Plan to deploy IBM Tivoli License Manager 15
SSL
The planning information about using SSL is divided into these sections:
v “Why use SSL”
v “How SSL works”
v “How SSL is implemented in Tivoli License Manager” on page 17
v “How you get an SSL server certificate” on page 18
v “How to configure for SSL” on page 19
Why use SSL
Secure Sockets Layer (SSL) is a message transportation protocol that provides the
following advantages:
Authenticated
The origin of all messages is assured. For example, no Tivoli License
Manager component belonging to any another Tivoli License Manager user
may contact your components.
Reliable
The message transport uses a message integrity check (using a MAC) that
ensures the quality of the data being transmitted.
Private
Messages between the components are encrypted, after a handshake to
define a secret key. This ensures that the contents of the messages cannot
be read by a third party. If all of your components are behind a firewall, or
some other means of protection, and do not require encryption, privacy
can be disabled without comprising the authentication and reliability
aspects of SSL.
The disadvantages of SSL
Implementing SSL for any communication has one disadvantage: it requires both
parties to the communication to do extra work in exchanging handshakes and
encrypting and decrypting the messages, making this form of communication
slower than communication without SSL.
Performance tests have revealed that using SSL between the agent and the runtime
server, for example, increases network traffic three-fold, and can reduce the speed
of response of the runtime server to agent requests by from two to ten times,
depending largely on the agent platform. This extra work at the runtime server is
actually done by the Web server, but its use of the computer’s resources can also
have an impact on other activities that the runtime server is performing.
You need to examine the type of data that you are communicating, look at what
other security measures you might have in place (proxy servers, enterprise
firewalls, for example), and evaluate whether you need this level of security.
How SSL works
There are many sources in the Internet and elsewhere that explain how SSL works
in detail, but the important elements from the planning perspective are these:
SSL client
The party that commences a communication using SSL is termed the SSL
client.
SSL
16 IBM Tivoli License Manager: Planning, Installation, and Configuration
SSL server
The party that receives the communication is termed the SSL server.
SSL server certificate
The SSL server offers the SSL client its server certificate.
Certificate key database
The SSL server keeps its server certificate in its key database (in the case of
the IBM HTTP server, in a file called key.kdb).
Key database password
To protect the server certificate in the key database, a password is set that
is used by applications that have been configured to use SSL.
Certificate validation
The SSL client validates that the server certificate is authentic. To do this it
must have either a copy of the server certificate or must have the root
certificate of the Certification Authority that issued the server certificate.
Certificate keystore
All certificates used to validate a server certificate are stored on the SSL
client. Where the SSL Client is a Java™ client, they are stored in a Java
keystore (a file called key.jks).
Java keystore password
For a Java program, the Key database password also gives access to the
Java keystore.
Encrypting the message
When the SSL client has validated the authenticity of the server certificate,
it can encrypt the message it wants to send, using the information in the
server certificate.
Decrypting the message
When the SSL server receives the message it is able to decrypt it because it
has been encrypted using its own server certificate.
How SSL is implemented in Tivoli License Manager
Table 4 shows how SSL can be implemented in Tivoli License Manager:
Table 4. SSL implementation in Tivoli License Manager
Communication type SSL client
(communication
originator)
SSL server
(communication
receiver)
Flexibility
Administration server wake
up call
Administration
server
Runtime servers You can configure the communication channel
with each runtime server to use or not use
SSL.
All runtime service requests
(for example, download
catalog, upload use
information)
Runtime server Administration
server
You can configure each runtime server to use
or not use SSL for its communications (the
administration server must be configured to
permit both).
Administration GUI Web browser Administration
server
At the start of each session of using the GUI
you can decide whether to use or not use SSL
(the server must be configured to permit
both). Note, however, that the administrator
can alternatively decide to force the use of
SSL just for logging on, and for creating or
changing passwords.
Runtime GUI Web browser Runtime server
SSL
Chapter 1. Plan to deploy IBM Tivoli License Manager 17
Table 4. SSL implementation in Tivoli License Manager (continued)
Communication type SSL client
(communication
originator)
SSL server
(communication
receiver)
Flexibility
Agent service requests (for
example, license issue and
release requests, upload use
information)
Agent Runtime servers SSL is enabled per organization or per
division. A configuration setting at the
administration server (requestScope)
determines whether, in the event of an agent’s
runtime server being unavailable, agents can
contact alternative runtime servers in the
organization or only in the agent’s division, or
not at all (see “Alternative runtime servers”
on page 22). SSL between agents and runtime
servers must be enabled to correspond to that
setting, so that the agent is always capable of
validating the server certificate at any runtime
server it is allowed to contact.
If SSL is not configured for this
communication type, no check is made on the
agent’s credentials by the runtime server, and
neither does the agent authenticate the
runtime server’s communications.
Your communications policy, the topology of your network, and the
communication type will help you determine which types of communications
between which components require to be in SSL.
How you get an SSL server certificate
The SSL process requires that the party that is performing the role of the SSL
server in a communication needs an SSL certificate.
This can be obtained in one of the following ways:
Obtain a server certificate from a well-known trusted Certificate Authority
You can ask a well-known trusted Certificate Authority, such as Verisign or
Thawte to issue the certificate. The Web sites of these authorities indicate
how much such certificates cost, and for how long they are valid. Such
certificates have the advantage that their root certificates are already
installed in the key databases of the prerequisite Web browsers, and similar
databases containing these root certificates are also installed by the Tivoli
License Manager installation process on servers and agents. Thus, once you
have obtained and installed the server certificate on your SSL servers,
authentication, reliability, and privacy can be achieved without having to
also install the certificate in the key database of the SSL clients. However,
this option has the disadvantage that if you want to have different server
certificates at each runtime server (the most secure method) you will have
to pay the certificate issue fee for each server certificate. This option is the
preferred solution from an ease-of-use point of view.
Issue a self-signed server certificate
Your enterprise might have decided to issue self-signed server certificates.
The advantage of these is that you do not have to pay each time you issue
a new certificate. The disadvantage is that you will need to install the same
server certificate in the key database of all SSL clients (other servers,
agents, and Web browsers). Another disadvantage is that, if the alternative
runtime server facility is enabled, you must use the same server certificate
at all runtime servers that an agent can contact, and implement its use in
SSL
18 IBM Tivoli License Manager: Planning, Installation, and Configuration
all agents at the same time. This option is not recommended, but
implementation instructions for it are included in this manual.
Issue a server certificate as a Certificate Authority
If your enterprise is already a private Certificate Authority, you can issue
server certificates with private keys for use at your SSL servers, and install
your own root certificate in the key database of all SSL clients (other
servers, agents, and Web browsers). This option is the most flexible with
regard to the alternative runtime server facility, as it allows you to generate
different server certificates for each runtime server, knowing that the
common root certificate at the agents will allow any of them to be
validated. This option is the preferred solution from a security point of
view.
Note: When Tivoli License Manager is installed, also installed with each
component are not only the key databases that contain the well-known
trusted Certificate Authority root certificates, but also a test certificate in the
keystore (and also in the agent section of the runtime server in a file called
cert.arm). This must be used only for test purposes. You do not have the
right to use it in an active environment, and in case it is insecure, as it is
distributed to all Tivoli License Manager customers. The configuration steps
explain how to replace this certificate.
Further, the same fixed, default SSL password (slmtest) is used for all
installed keystores and databases. This can be used for testing purposes, but
is not secure, as it is issued to all customers. The configuration steps explain
how to change this password.
How to configure for SSL
This section gives an overview of the steps required to configure your Tivoli
License Manager environment for SSL. There are steps required for the component
playing the role of the SSL server, and steps required for the component playing
the role of the SSL client. Both Tivoli License Manager servers can play both roles
and each can play the SSL server role in more than one of the communication
types listed in Table 4 on page 17. Thus, when you configure your network for one
communication type you may find that some aspects of the configuration for a
different communication type are already in place.
The configuration procedure overviews are as follows:
v “Configuring SSL at the SSL server”
v “Configuring SSL at the SSL client” on page 20
Configuring SSL at the SSL server:
The SSL server role in Tivoli License Manager can be performed by the
administration server or the runtime server, depending on the communication type
(see Table 4 on page 17). The steps are as follows:
1. Enable SSL on the Web server of the Tivoli License Manager server and allocate
the secure (SSL) port to be used. You can optionally disable encryption.
2. Ensure that WebSphere Application Server has secure-port aliases.
3. Change the default SSL password that allows you and the server’s Web server
to access its keystore. You can have different passwords for each server, but you
may find it more convenient to have the same password for all.
4. Obtain or create a server certificate with a private key.
SSL
Chapter 1. Plan to deploy IBM Tivoli License Manager 19
5. Install the server certificate in the keystore (key.kdb), replacing the test
certificate supplied with Tivoli License Manager. You should not use a server
certificate obtained for any other purpose or any other server.
If you have decided to use the same certificate for all runtime servers (and
have the same keystore password), you can install the certificate on one server
and copy the keystore and the stashed password file to all other runtime
servers.
These operations are performed after the installation, and are described in full in
“Configure SSL” on page 98.
Configuring SSL at the SSL client: The SSL server role in Tivoli License Manager
can be performed by the administration server, the runtime server, agents or Web
browsers, depending on the communication type (see Table 4 on page 17). The
steps are as follows, and differ in details depending on the type of SSL client:
1. Enable the component for SSL:
SSL client Action
Administration
server
Register each of the runtime servers using the administration server
GUI, enabling SSL and indicating for each the port you assigned for
SSL at the runtime server.
Runtime server Enable SSL when installing the runtime server, or edit the
communication.properties file to reconfigure the runtime server
after installation so that it is enabled for SSL and has details of the
administration server’s secure port.
Agent Enable SSL when you create the division that an agent will belong
to.
Web browser Enable SSL by communicating with the server using ″https″ instead
of ″http″ in the Web address.
2. If the SSL client is a Tivoli License Manager server or agent, change the SSL
password that allows you and the server’s Web server to access its key
database.
3. This step depends on the type of server certificate you have chosen for the SSL
server:
v Obtained a server certificate from a well-known trusted Certificate
Authority: take no action.
v Issued a self-signed server certificate: the action depends on the type of SSL
client:
SSL client Action
Tivoli License
Manager server
Install the server certificate in the SSL client’s Java keystore
(key.jks).
Agent Put a copy of the server certificate in the agent file structure
on the corresponding runtime servers (for agent deployment).
When performing agent deployment using the wizards, select
this certificate to be deployed on the agents.
Web browser Install the server certificate in the Web browser’s key
database.
v Issued a server certificate as a Certificate Authority: the action depends on
the type of SSL client:
SSL
20 IBM Tivoli License Manager: Planning, Installation, and Configuration
SSL client Action
Tivoli License
Manager server
Install your Certificate Authority’s root certificate in the SSL
client’s Java keystore (key.jks).
Agent Put a copy of your Certificate Authority’s root certificate in
the agent file structure on the corresponding runtime servers
(for agent deployment). When performing agent deployment
using the wizards, select this certificate to be deployed on the
agents.
Web browser Install your Certificate Authority’s root certificate in the Web
browser’s key database.
These operations are performed as part of or after the installation, and are
described in full in “Configure SSL” on page 98.
Inter-component passwords
Determine what values you propose to use for the various inter-component
passwords that the product requires.
tlmsrv password
On every computer where you install a database component, the install
process creates a user id called ″tlmsrv″. The user id is used for
communications between the server and database components. During the
install phase on each computer, you need to decide what password to give
to this user id.
On every computer where you install a server component, the install
process needs to record the password used for the ″tlmsrv″ user for its
corresponding database.
If a server and its database are installed on the same computer, this is done
in one action. If you install both components on the same computer but in
two separate moments, you are asked to confirm the original password
supplied. If you install the components on separate computers, you must
ensure to supply the same value for both.
To change the tlmsrv password after installation see “Changing
passwords” on page 297.
Runtime server communication password
This is used to authenticate communications between a runtime server and
its administration server. A password must be supplied whenever you are
installing a runtime server, but where you have more than one runtime
server, a different value can be supplied for each. After the runtime server
has been set up on the administration server GUI with the same password,
when the runtime server contact (plugs in to) the administration server it
uses its password to authenticate the communications. The password is not
used if the runtime to administration communication channel does not use
SSL.
To change the runtime server communication password after installation
see “Changing passwords” on page 297.
SSL password
Each server that is enabled to use SSL communications requires a
password to access its SSL key store. Whether or not you enable SSL, the
server will be installed with a key store, and the password used to access
that keystore will have the default value of ″slmtest″. Thus, this value
SSL
Chapter 1. Plan to deploy IBM Tivoli License Manager 21
applies, either if you enable SSL at installation, or if you enable it at some
point after installation. This password is common to all Tivoli License
Manager users, and thus should be changed after installation, for security
reasons.
To change the SSL password after installation see “Changing passwords”
on page 297. The password is only used by the server itself, so different
values can be selected for each server.
Alternative runtime servers
The agent needs to be able to contact its runtime server very regularly, both for
license-based operations and to report usage. In the event that the normal runtime
server is not available, you can set a parameter that determines whether agents can
contact just their registered runtime server, all runtime servers in their division, or
all runtime servers in the organization.
This setting must correspond with the SSL agent policy you have chosen, see
“SSL” on page 16. The configuration parameter is called requestScope and is
documented in “Agent settings” on page 241
Planning to install and configure the components
This section describes the main steps for deploying Tivoli License Manager in a
fresh environment.
Note: If you already have a version of Tivoli License Manager installed on the
computers where you plan to install this version, you need to upgrade your
Tivoli License Manager environment. Full details are given in Chapter 6,
“Migrate to version 2.1,” on page 201.
First in this section is a description of the CDs that are supplied to install the
product. See “The packaging.”
Following this are descriptions that help you to plan how to deploy and use the
components:
1. “Plan how to install the server and database components” on page 23.
2. “Plan how to configure your Tivoli License Manager environment” on page 37.
3. “Plan how to operate Tivoli License Manager” on page 41.
4. “Plan how to deploy the agents” on page 42.
5. “Plan how to install the catalog manager” on page 55.
6. “Optionally plan how to deploy the Tivoli Data Warehouse enablement pack”
on page 57.
7. “Plan how to populate the databases” on page 58.
The packaging
The following is a list of the CDs that are supplied with the product:
Server and agents CD
This contains the setup files that allow you to install the servers, databases
and agents. This also contains the files to install the Tivoli Data Warehouse
Enablement Pack.
Inter-component passwords
22 IBM Tivoli License Manager: Planning, Installation, and Configuration
Catalog manager CD
This contains the setup files that allow you to install the catalog manager.
It also includes the software package blocks (SPBs) that you can use with
Tivoli Configuration Manager to install the catalog manager remotely. The
CD is not made available with IBM Tivoli License Manager for IBM
software.
Software Package Block CD (Windows, AIX®, HP, and SUN)
This contains the software package blocks that you can use with Tivoli
Configuration Manager to install the server, databases and agents remotely.
The SPBs are large and so are divided across two CDs; this one is for
Windows AIX, HP and SUN.
Software Package Block CD (Linux, OS/400)
This contains the software package blocks that you can use with Tivoli
Configuration Manager to install the server, databases and agents remotely.
The SPBs are large and so are divided across two CDs; this one is for all of
the Linux platforms and OS/400.
Documentation CD
This will contain, as a minimum, the complete documentation set in
English, with the exception of the Release Notes. All books, including the
Release Notes, will also be available on the IBM and Tivoli documentation
Web sites indicated in “Accessing publications online” on page xvi.
In addition, and depending on their availability at the time when you
obtained the product, you can find those books that have been translated
into languages other than English.
To access any document, open the file allpubs.htm in the root of the CD
using a Web browser, select the language you prefer and select the pdf or
html version of the book you want to look at. If it has been translated, the
translated book will open. If the selected book has not been translated into
the language of your choice, the English version of the book will open.
DB2 CDs (bundled prerequisite)
A set of CDs containing the prerequisite version of DB2 that is provided
with Tivoli License Manager for manual or automatic installation.
WebSphere Application Server CDs (bundled prerequisite)
A set of CDs containing the prerequisite version of WebSphere Application
Server that is provided with Tivoli License Manager for manual or
automatic installation.
Plan how to install the server and database components
This section discusses what you need to take into consideration when planning the
installation of your main components. It contains the following topics:
v “Choosing the install method” on page 24
v “Prerequisites for administration and runtime servers” on page 25
v “Prerequisites for databases” on page 29
v “Obtaining and installing the prerequisite software” on page 31
v “Auto-installation of prerequisite software” on page 32
v “Additional prerequisites for installing servers and databases using Tivoli
Configuration Manager” on page 36
v “Preparing the required installation information” on page 37
Packaging
Chapter 1. Plan to deploy IBM Tivoli License Manager 23
Choosing the install method
This section explains the mechanisms used to deploy the server and database
components. There are the following possibilities:
Local interactive installation
The server and database components can be installed by running the Tivoli
License Manager install wizard interactively on the computer on which the
components are to be installed. The install wizard offers you three ways of
selecting product components:
Typical
In this installation, you can choose one of the following, for
installation on the same computer:
v The administration server and its database
v The runtime server and its database
v Both servers and their databases (this option is like an ″All
components″ installation without the agent – see below)
This type of installation uses default values for most install
parameters.
Custom
This installation enables you to select any combination of
components for installation on the same computer.
All components
In this installation, both servers and their databases are installed on
the same computer, and an agent is also deployed on that computer.
This type of installation uses default values for most install
parameters. It can be used for demo or training purposes, and in a
restricted business environment where the number of agents does not
exceed about 250.
Local silent installation
The install wizard can also be run as a silent installation, using a response
file. In this case, there are only two ways of selecting the product
components:
Custom
This is the same as the interactive ″Custom″ installation.
All components
This is the same as the interactive ″All components″ installation.
Note: Tivoli License Manager does not support the ″console″ install option
that was available with previous releases of the product.
Remote installation
If you are a user of the Software Distribution component of IBM Tivoli
Configuration Manager, you can install the Tivoli License Manager server
and database components, by leveraging Software Distribution’s ability to
distribute, install and run an item of software on multiple remote nodes.
Tivoli License Manager is supplied with one software package block for the
server and database components for each platform on which they can be
installed. You distribute the appropriate software package block to the target
computer, using Software Distribution’s facility that enables you to supply
the install parameters.
Plan to install main components
24 IBM Tivoli License Manager: Planning, Installation, and Configuration
The full instructions for installing the server and database components are given in
Chapter 2, “Install Tivoli License Manager main components,” on page 61.
Prerequisites for administration and runtime servers
For details of supported server platforms see “Supported platforms for servers” on
page 13.
The following lists the prerequisites for each server component:
Software
Database client
If the server component and its associated database component are to be
installed on the same computer, a database client is not required.
If the server component and its associated database are to be installed on
different computers, you require a DB2 client or server to access the database.
The version of the client or server required is as follows:
On all Windows and UNIX platforms and Linux platforms on Intel x86, one
of the following versions:
v DB2 Universal Database, Enterprise Extended Edition client or
server, version 7.2.0 with fix pack 10a installed
v DB2 UDB, Enterprise Server Edition client or server, version
8.1.0 or 8.1.4.
On Linux platforms for iSeries, pSeries and zSeries, the following version:
v DB2 UDB, Enterprise Server Edition client or server, version
8.1.0 or 8.1.4
On Red Hat Enterprise Linux, version 3.0 (all supported versions and
processors), the following version:
v DB2 UDB, Enterprise Server Edition client or server, version
8.1.4
If you do not have the database prerequisite, the install procedure can install
DB2 UDB, Enterprise Server Edition, version 8.1.4 runtime client for you. See
“Auto-installation of prerequisite software” on page 32 for more details.
Database driver
If you plan to use IBM DB2 Universal Database, Enterprise Extended Edition,
version 7.2.0 with fix pack 10a, you should also install JDBC, version 2.0.
Plan to install main components
Chapter 1. Plan to deploy IBM Tivoli License Manager 25
Software (continued)
Web application server
One of the following versions:
v IBM WebSphere Application Server version 5.0.2.x, where x > 0 (version
5.0.2 with the WebSphere Plug-in Cumulative Fix for 5.0.0, 5.0.1 and 5.0.2.x
applied).
Note: Versions 5.0.2.x or higher are not available for the following
operating systems:
– Red Hat Enterprise Linux AS, version 3.0 for PPC (iSeries and pSeries -
64-bit, in 32-bit compatibility mode)
– SUSE LINUX Enterprise Server 8 for IBM iSeries/pSeries, with Service
Pack 3 (64-bit, in 32-bit compatibility mode)
– SUSE LINUX Enterprise Server 8 for IBM Mainframes (zSeries 31-bit)
v IBM WebSphere Application Server version 5.1
Supported editions, modalities and options:
v Tivoli License Manager only supports the Base Edition of WebSphere
Application Server in standalone modality. Other editions, such as Express
and Network Deployer are not supported.
v Federated mode is not supported.
v WebSphere Application Server can be operated in a secure cell, but you
will be required to supply the secure cell’s user id and password whenever
you need to stop one of the Tivoli License Manager servers.
If you do not have either of the Web application server prerequisites, the
install procedure can install WebSphere Application Server version 5.1 for
you. See “Auto-installation of prerequisite software” on page 32 for more
details.
Web server
Any Web server supported by the prerequisite version of WebSphere
Application Server.
Note: Among these supported Web servers is IBM HTTP Server, version
1.3.28. In this manual you will find references to configuring only this version
of IBM HTTP Server. If you are using a different Web server you should
consult the documentation of your Web server to achieve the same result.
UNIX shell
To install the servers on UNIX platforms you must have the korn shell (ksh)
installed and activated.
Note: The shell must be present but the setup command to install the
product can be issued from any shell – not necessarily the korn shell.
The same shell is also required to run the command line interface on both
servers.
Java Runtime Environment
The servers require Java Runtime Environment, version 1.4. This is installed
by the install wizard, automatically, and should not be uninstalled. If Tivoli
License Manager is completely uninstalled from a computer, this version of
Java Runtime Environment is also uninstalled.
Plan to install main components
26 IBM Tivoli License Manager: Planning, Installation, and Configuration
CPU
Windows and Linux on
Intel x86
Intel Pentium® IV 1.5 GHz
AIX and Linux on pSeries RS/6000® - Model 7044/270, two processor IBM
RS/6000 375
Solaris Sunblade 2000 model, 2 Ultrasparc III processors
HP/UX rp2470, 2 PA Risc 650 MHz processors
Linux on zSeries 1 dedicated processor.
Other platforms No special requirements.
Memory
At least 1GB minimum of available memory.
On HP/UX, if you want to install both servers on the same computer you will need
at least 2GB
Plan to install main components
Chapter 1. Plan to deploy IBM Tivoli License Manager 27
Space
Component Resource type Space
required
Administration
server (without
the runtime
server)
Tivoli License Manager administration server; in the
product install directory
90 MB
An application server; in the WebSphere
Application Server install directory
30 MB
WebSphere Application Server temporary directory
(java.io.tmpdir).
40 MB
Logs and traces in the Tivoli Common Directory 21 MB
Log Viewer (Tivoli License Manager server install
directory)
3 MB
Runtime server
(without the
administration
server)
Tivoli License Manager runtime server, plus agent
code for all platforms, in the install directory
250 MB
An application server; in the WebSphere
Application Server install directory
210 MB
WebSphere Application Server temporary directory
(java.io.tmpdir).
240 MB
Logs and traces in the Tivoli Common Directory 21 MB
Log Viewer (Tivoli License Manager server install
directory)
3 MB
Both servers on
the same
computer
Tivoli License Manager administration and runtime
servers, plus agent code for all platforms, in the
install directory
300 MB
Both application servers; in the WebSphere
Application Server install directory
240 MB
WebSphere Application Server temporary directory
(java.io.tmpdir).
280 MB
Logs and traces in the Tivoli Common Directory 31 MB
Log Viewer (Tivoli License Manager server install
directory)
3 MB
In addition, on Windows platforms there must be a minimum of 100 MB of
available temporary space on the default drive, while on UNIX platforms there
must be at least 250 MB of free space in the /tmp directory.
See the appropriate documentation for DB2 and WebSphere Application Server for
details of the space they require.
Display
If you plan to install the administration server on a UNIX platform, the server
computer must have access to an X display server. See Appendix G, “Enabling
graphics for an administration server on UNIX (X-display),” on page 311 for
information about checking for the connection to the X display server and
instructions on making the connection if it does not exist.
Note: A Web browser is required to use the administration server or the runtime
server, not to install or run them. The browser can be used from the same
computer where the servers are installed, or any other supported computer.
For details of the browsers that can be used, see “Plan how to operate Tivoli
License Manager” on page 41.
Plan to install main components
28 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Prerequisites for databases
For supported platforms, see “Supported platforms for databases” on page 13.
The following contains the prerequisites for each database component.
Software
Database server
On all Windows and UNIX platforms and Linux platforms on Intel x86,
one of the following versions:
v DB2 Universal Database, Enterprise Extended Edition server,
version 7.2.0 with fix pack 10a installed
v DB2 UDB, Enterprise Server Edition server, version 8.1.0 or
8.1.4.
On Linux platforms for iSeries, pSeries and zSeries, the following version:
v DB2 UDB, Enterprise Server Edition server, version 8.1.0 or
8.1.4
On Red Hat Enterprise Linux, version 3.0 (all supported versions and
processors), the following version:
v DB2 UDB, Enterprise Server Edition server, version 8.1.4
If you do not have this prerequisite, the install procedure can install it for
you. See “Auto-installation of prerequisite software” on page 32 for more
details.
Database driver
If you plan to use IBM DB2 Universal Database, Enterprise Extended Edition,
version 7.2.0 with fix pack 10a, you should also install JDBC, version 2.0.
UNIX shell
To install the databases on UNIX platforms you must have the korn shell
(ksh) installed and activated.
Note: The shell must be present but the setup command to install the
product can be issued from any shell – not necessarily the korn shell.
CPU
See the DB2 documentation of the chosen database server for prerequisites.
Memory
See the DB2 documentation of the chosen database server for prerequisites.
Plan to install main components
Chapter 1. Plan to deploy IBM Tivoli License Manager 29
Space
Component Resource type Space
required
Administration
server database
(without the
runtime server
database)
Tivoli License Manager administration server
database; in the product install directory
6 MB
The DB2 database tables for the administration
server database, in the DB2 install directory
(Windows) or the home directory of the DB2
instance owner (UNIX)
200 MB
The DB2 database tables for each agent reported by
the administration server, in the DB2 install
directory (multiply this value by the number of
agents you expect to manage with the
administration server)
450 KB
If the database is installed without a server
component, install logs and traces in the Tivoli
Common Directory
10 MB
Runtime server
database
(without the
administration
server database)
Tivoli License Manager runtime server database, in
the product install directory
6 MB
The DB2 database tables for the runtime server
database, in the DB2 install directory
200 MB
The DB2 database tables for each agent registered
with a runtime server, in the DB2 install directory
(multiply this value by the number of agents you
expect to register with the server)
350 KB
If the database is installed without a server
component, install logs and traces in the Tivoli
Common Directory
10 MB
Both servers’
databases (on
the same
computer)
Tivoli License Manager administration and runtime
server database, in the product install directory
12 MB
The DB2 database tables for the administration and
runtime server database, in the DB2 install directory
400 MB
The DB2 database tables for each agent registered
with a runtime server, in the DB2 install directory
(multiply this value by the number of agents you
expect to register with the server)
800 KB
If the databases are installed without a server
component, install logs and traces in the Tivoli
Common Directory
10 MB
In addition, on Windows platforms there must be a minimum of 100 MB of
available temporary space on the default drive, while on UNIX platforms there
must be at least 250 MB of free space in the /tmp directory.
See the appropriate documentation for DB2 for details of the space it requires.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Plan to install main components
30 IBM Tivoli License Manager: Planning, Installation, and Configuration
Obtaining and installing the prerequisite software
If you do not have the prerequisite version of WebSphere Application Server or the
prerequisite DB2 server or client, this section provides information on how to
obtain and install them.
IBM DB2 UDB, Enterprise Server Edition
v DB2 is bundled with a variety of IBM products, but there are many
different versions and editions, so you must ensure that any existing
version is the one that you require.
v Tivoli License Manager bundles version 8.1.4, (supported on all
platforms) which you can install before commencing the installation of
Tivoli License Manager. Alternatively, you can let the Tivoli License
Manager install wizard install the prerequisite version for you (see
“Auto-installation of prerequisite software” on page 32).
v If you install the DB2 server on an UNIX platform and you are going to
install both the server and database on this computer, make sure that the
/home file system is at least 10 GB, as the DB2 databases are hosted in
this partition. You can extend the file system size using a UNIX
configuration tool.
IBM WebSphere Application Server
v WebSphere Application Server is bundled with a variety of IBM
products, so you may already have a prerequisite version.
v Tivoli License Manager bundles version 5.1 which you can install before
commencing the installation of Tivoli License Manager. Alternatively,
you can let the Tivoli License Manager install wizard install the
prerequisite version for you (see “Auto-installation of prerequisite
software” on page 32).
v If you already have version 5.0.2 of WebSphere Application Server, but
have not installed the prerequisite fix to bring it to 5.0.2.2, you can
obtain the WebSphere Plug-in Cumulative Fix for 5.0.0, 5.0.1 and 5.0.2.x
directly from this link, or by following these steps:
1. Go to the IBM Software Support Web site:
http://www.ibm.com/support
2. Click Software
3. Enter ″WebSphere Application Server″ in the search window, select
the Downloads check button and click Submit
4. Refine your search by typing ″plug-in 5.0.2″ in Additional search
terms. Click Submit
5. Click WebSphere Plug-in Cumulative Fix for 5.0.0, 5.0.1 and 5.0.2.x
The fix download page is displayed.
Web server
v WebSphere Application Server requires a Web server to be installed on
the same computer. WebSphere Application Server is delivered with the
IBM HTTP Server already bundled. If you have not yet installed
WebSphere Application Server, when you do so, ensure to select the
install options that include the installation of IBM HTTP Server. If you
let Tivoli License Manager install WebSphere Application Server for you,
it automatically installs the IBM HTTP Server.
v If you are planning to use secure sockets layer (SSL) protocol for
communications with the Tivoli License Manager server component on a
given computer, the IBM HTTP server must be installed on that
computer with the SSL option turned on.
Plan to install main components
Chapter 1. Plan to deploy IBM Tivoli License Manager 31
You are advised to maintain a separate DB2 / WebSphere Application Server
environment for Tivoli License Manager, using the bundled prerequisites. This is
because you have a license that allows you to use these prerequisites for Tivoli
License Manager, that is separate from any other licenses you may have for other
versions of DB2 or WebSphere Application Server. You should further note that if
you deploy an agent on the computers where these prerequisites are installed, their
use will be monitored, and included in use reports.
Attention: The installation and use of DB2 and WebSphere Application Server
may require a particular configuration of the computer on which they are to be
installed. For example, on HP/UX and Solaris platforms the kernel has to be
configured to work with DB2.
Auto-installation of prerequisite software
In order to facilitate the installation of Tivoli License Manager, the product
packaging includes all of the prerequisite software, and the install wizard installs
the prerequisite software, if you want it to. The bundled software comprises the
following items:
Database server or client
IBM DB2 UDB, Enterprise Server Edition, version 8.1.4
Web application server
IBM WebSphere Application Server version 5.1 (which also installs IBM
HTTP Server version 1.3.28 as its Web server)
The packaging contains a CD for each of the separate supported platforms for each
of these prerequisites.
Attention: These prerequisites are supplied with restricted-use licenses that allow
them to be used only in association with the use of Tivoli License Manager. The
licenses also give you the right to download, install and use any fixes issued on
these products. By accepting the Tivoli License Manager license agreement during
the install process, you also implicitly accept the license agreements for the
prerequisite software, and accept the restricted use. See the wording of the Tivoli
License Manager license agreement (displayed during the interactive installation)
for details.
The action of the install process differs, depending on the prerequisite:
IBM DB2 UDB, Enterprise Server Edition
If you do not have a version of DB2 UDB, Enterprise Server Edition which
is supported by Tivoli License Manager, the install wizard asks you if you
wish to install the bundled version.
If you have an unsupported version of DB2 on the computer, you should
not go ahead with the installation of DB2, as the wizard attempts to make
a fresh installation of it, which fails if a previous version is present.
Instead, you should exit from the wizard, uninstall your existing version of
DB2 or migrate it to a version supported by Tivoli License Manager, and
then retry the product installation.
If you answer yes, you are asked to insert the appropriate CD, supply the
install directory for DB2 and the user id and password for the DB2
administration user, and then DB2 is installed, using a silent installation.
DB2 is installed listening at a port number determined by you during the
installation.
Plan to install main components
32 IBM Tivoli License Manager: Planning, Installation, and Configuration
IBM WebSphere Application Server
If you do not have a version of WebSphere Application Server which is
supported by Tivoli License Manager, the install wizard asks you if you
wish to install the bundled version.
If you have an unsupported version of WebSphere Application Server on
the computer, you should not go ahead with the installation of WebSphere
Application Server, as the wizard attempts to make a fresh installation of
it, which may fail if a previous version is present. Instead, you should exit
from the wizard, and either uninstall your existing version of WebSphere
Application Server, or migrate it to a version supported by Tivoli License
Manager, or manually install a supported version of WebSphere
Application Server alongside the unsupported version. Then retry the
product installation.
If you answer yes, you are asked to insert the appropriate CD, supply the
product install directory, and then WebSphere Application Server is
installed, using a silent installation.
Note: On Windows platforms you are also asked to supply the
Administrator password, so that WebSphere Application Server and
the IBM HTTP Server can be installed as services.
The installation of WebSphere Application Server also installs the IBM
HTTP Server version 1.3.28. If you have any other Web server installed on
the computer, it must be stopped while Tivoli License Manager is being
installed.
Prerequisite service packs, fix packs and patches for bundled versions of DB2
and WebSphere Application Server: This section describes the prerequisites for
installing the bundled versions of DB2 and WebSphere Application Server.
Attention: The details supplied here apply only to the product versions installed
by the Tivoli License Manager installation. They do not necessarily apply to any
other supported versions. In case of doubt you should always check with the DB2
or WebSphere Application Server documentation, on or offline.
Bundled version of DB2
The following table shows only those prerequisites of IBM DB2 UDB,
Enterprise Server Edition, version 8.1.4 that are in addition to those
required by Tivoli License Manager:
Table 5. Additional patches, service packs, patches for the bundled DB2
Operating
system
Version Additional level, service packs, patches
IBM AIX 5.1 (32-bit) Maintenance level 2, or later, and APARs
IY31254, IY32217, IY32905, IY33023, and
IY29345
5.1 (64-bit) Maintenance level 2, or later, and APARs
IY31254, IY32217, IY32905, Y33023, and IY32466
HP/UX 11i for PA-Risc December 2001 GOLDBASE11i and December
2001 GOLDAPPS11i bundles, patch
PHSS_26560, patches for Java SDK 1.4
(QPK1100 Sept ’03, QPK1100 March ’03,
QPK1100 Sept ’02, QPK1100 March ’02,
QPK1100 Sept ’01 Base 11.00)
Plan to install main components
Chapter 1. Plan to deploy IBM Tivoli License Manager 33
Table 5. Additional patches, service packs, patches for the bundled
DB2 (continued)
Operating
system
Version Additional level, service packs, patches
Sun Solaris 8 (32-bit) Recommended & Security Patches plus patches
108921-12, 108940-24, 108434-03, and 108528-12
from: http://sunsolve.sun.com.
9 (64-bit) Recommended & Security Patches plus patches
108921-12, 108940-24, 108435-03, and 108528-12
from: http://sunsolve.sun.com.
Bundled version of WebSphere Application Server (5.1)
The following table shows only those prerequisites of IBM WebSphere
Application Server version 5.1 that are in addition to those required by
Tivoli License Manager:
Table 6. Additional patches, service packs, patches for the bundled WebSphere
Application Server
Operating
system
Version Additional level, service packs, patches
Windows 2000 Server or
Advanced
Server for Intel
x86 (32-bit)
Service Pack 3 or 4
IBM AIX 5.1 Recommended Maintenance package 5100-04
and AIX PTF U484272
5.2 Recommended Maintenance package 5100-04 +
APAR IY44183, and AIX PTF U484272
HP/UX 11i for PA-Risc Quality Pack of June 2003, Patches
PHSS_26560, PHCO_29109, and PHSS_26946.
Red Hat
Enterprise
Linux
ES/AS/WS,
version 3.0
Reference technote #1164634 before installation.
AS, version 3.0
Sun Solaris 8 and 9 Recommended Patch Cluster of July 2003
Prerequisite software installation passwords: The installation of the prerequisite
software requires the creation or use of user IDs for the computer on which they
are installed. The details are as follows:
DB2 administration password
If you are asking the wizard to install the bundled DB2 for you, the install
wizard must create a user id on the computer which is enabled for DB2
administration activities (see the DB2 documentation for details). This user
id must be supplied with a password that respects the password rules of
that computer. You need to supply this information during the installation.
To change the DB2 administration password after installation see
“Changing passwords” on page 297.
Administrator password (to set up WebSphere Application Server and the IBM
HTTP Server as services)
If you are asking the wizard to install the bundled WebSphere Application
Server for you on a Windows computer, the wizard needs to make these
programs available as Windows services. For this, the install wizard has to
Plan to install main components
34 IBM Tivoli License Manager: Planning, Installation, and Configuration
use the ″Administrator″ user ID of the computer, and thus requires the
password to the ″Administrator″ account. You need to supply this
password during the installation.
To change the Administrator password after installation see “Changing
passwords” on page 297.
Avoiding port conflicts with WebSphere Application Server
When installing the prerequisites you may possibly discover some port conflicts
between WebSphere Application Server and software already installed. WebSphere
Application Server Administrative Console is by default installed listening on port
9090, and IBM HTTP Server is installed listening on port 80 for insecure and 443
for secure communications. If you have other products listening on these ports you
will need to either change their ports or disable them during the installation of the
bundled products. To list the ports which are currently in use, type the following
commands:
Windows netstat –an
UNIX netstat –an | grep LISTEN
The most likely problems are with port 80 and 9090. The details are as follows:
Port 80
If you choose to install the WebSphere Application Server bundled
prerequisite, it will be installed with its HTTP server listening on port 80.
If you know that port 80 is in use, you will want to assign different ports.
This involves the following steps:
1. If you have a supported HTTP server already installed on the
computer, change the configuration to let it listen on the port you want
Tivoli License Manager to use.
2. If you have a supported version of WebSphere Application Server
already installed on the computer, add aliases for the port you want to
use.
3. During the installation of the Tivoli License Manager server, supply the
port number you want it to use.
4. If you let the installation install the bundled WebSphere Application
Server and the IBM HTTP Server, the Tivoli License Manager server
will not start successfully at the end of the installation. You should now
set up the aliases in WebSphere Application Server and configure the
IBM HTTP Server for the new port, and then restart the Tivoli License
Manager server.
Port 9090
There is a possible port conflict for AIX users: Port 9090, which is used by
the WebSphere Application Server Administrative Console, might already
be in use by the Web-based System Manager of AIX, version 5.1.
If you are not using the AIX Web-based System Manager, you can disable
it (see the section called ″Configuring Web-based System Manager in
Client-Server Mode″ in the AIX 5L Version 5.1: Web-based System Manager
Administration Guide).
If you are using the AIX Web-based System Manager, you can change it to
use a different port number (see the same documentation).
If you are using the AIX Web-based System Manager and you do not want
to change its port, use the following procedure:
Plan to install main components
Chapter 1. Plan to deploy IBM Tivoli License Manager 35
1. Temporarily disable the AIX Web-based System Manager, using the
same documentation indicated above.
2. Install Tivoli License Manager, including its bundled prerequisites
3. Stop theWebSphere Application Server default server ″server1″, which
is required for the Administrative Console
4. Using the WebSphere Application Server documentation, change the
WebSphere Application Server configuration to use a different port for
the Administrative Console (see IBM WebSphere Application Server V5.1:
System Management and Configuration WebSphere Handbook Series)
5. Restart the AIX Web-based System Manager
6. Restart ″server1″, if required.
Additional prerequisites for installing servers and databases
using Tivoli Configuration Manager
Tivoli Configuration Manager can be used for server and database deployment.
However, you should be aware that the implementation requires you to supply
certain passwords in the software package block parameters that guide the
installation. To preserve the security of this data, Tivoli Management Framework,
on which Tivoli Configuration Manager is built, can be configured to provide
56-bit DES encryption on gateway to endpoint unicast communication. Encryption
is not supported for multicast communication.
The following contains the additional prerequisites for using Tivoli Configuration
Manager for server and database deployment.
Server and database platforms
All the supported platforms for the server and databases.
Software
Product Platform Version
IBM Tivoli
Management
Framework
Supported iSeries and
pSeries platforms
4.1 with fixes 4.1-TMF-0015 for
Linux-PPC (server) and
4.1-INVGW-0005 for Linux-PPC
(gateway) installed
Other platforms 4.1
IBM Tivoli
Configuration
Manager
Supported iSeries and
pSeries platforms
4.2 with fixes 4.2-SWD-0014
(server) and 4.2-SWD-0015
(gateway) installed
Other platforms 4.2 with fix pack 4.2-TCM-FP02
installed
Space
160 MB for the software package block that is distributed.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Plan to install main components
36 IBM Tivoli License Manager: Planning, Installation, and Configuration
Preparing the required installation information
The installation of the server and database components requires you to provide
certain installation parameters. These parameters are described in detail in
“Installing the main components” on page 66. Each component also needs to be
configured, and the configuration steps are described in Chapter 3, “Configure
Tivoli License Manager,” on page 95.
To help you prepare the information you require to install and configure the
components, the following checklists are provided:
v A table of the installation parameters, showing which are required for each
combination of components in a Custom installation, and which are required for
the special installations (Typical Runtime, Typical Administration, or All
components). See “Install parameter list” on page 251.
v A check list of the installation parameters and configuration steps required for
the administration server and its database. See “Administration components” on
page 254.
v A check list of the installation parameters and configuration steps required for
the runtime server and its database. See “Runtime components” on page 257.
v A check list of the installation parameters required to install the bundled DB2
prerequisite. See “Bundled DB2 checklist” on page 261.
v A check list of the installation parameters required to install the bundled
WebSphere Application Server prerequisite. See “Bundled WebSphere
Application Server checklist” on page 262.
v A check list of the parameters required to deploy the agent. See “Agent
checklist” on page 263.
v A check list of the parameters required to install the catalog manager. See
“Catalog manager checklist” on page 265.
Plan how to configure your Tivoli License Manager
environment
In order for your Tivoli License Manager environment to function correctly, some
configuration activities need to be performed. This section describes the activities
and discusses the information you need to prepare. The activities are as follows:
Plan to configure the administration server
After installation, the administration server needs to be set up with basic
information. If you are planning to use more than the one organization
that was created during the installation, you creates the extra
organizations, and assign accounts to each. For this activity you need to
have determined the names of the organizations and the users that are the
administrator or system resources manager for each organization (see IBM
Tivoli License Manager: Administration for more information about users and
roles).
Full details of the configuration steps are given in “Configure the
administration server” on page 95.
Plan the organization-related initial tasks
For each organization you have created, you need to register the runtime
servers and set up the divisions.
Full details of the configuration steps are given in “Perform the
organization-related initial tasks” on page 96.
Plan to install main components
Chapter 1. Plan to deploy IBM Tivoli License Manager 37
Plan to configure the runtime servers
On each runtime server you need to create the user accounts. You need to
start the server, and check that it correctly plugs in to the administration
server.
Full details of the configuration steps are given in “Configure the runtime
servers” on page 97.
Plan to enable secure communications
If you decide to implement SSL in your Tivoli License Manager
environment, the options you select during the installation configure the
appropriate Tivoli License Manager components to use SSL. However, you
must also configure the corresponding Web servers to use SSL, and obtain
and install your own trusted certificate. Tivoli License Manager is
delivered with a certificate to use for testing purposes, but you should
supply your own certificate for regular use.
Full details of the configuration steps are given in “Configure SSL” on
page 98.
Plan to define the event notification settings
Tivoli License Manager can be configured to send event notifications by
e-mail to nominated recipients. You edit the configuration files at the
servers to define the SMTP server to use and the sender’s address. You use
the server GUIs to add e-mail addresses to the user details and to
determine which users are to receive which event notifications. This
information needs to be prepared.
Full details of the configuration steps are given in “Configure the mail
notification settings for a server” on page 117.
Plan to customize the Web server
There are going to be occasions when the administration or runtime
servers are not going to respond to a service request from the associated
Web server. In these circumstances the server responds with a standard
″Error 500″, meaning that the application server is unavailable. Tivoli
License Manager comes with a customized version of the standard HTML
file which is displayed when this error is encountered, in all languages
supported by the product. You can choose to customize the Web server at
each of your Tivoli License Manager servers to use the file supplied with
the product. You can also further customize each of these files adding any
local information that might be useful, like the contact details of the system
administrator. If yours is an international enterprise, you can also provide
different message contents with different contact points, for different
languages.
Full details of the configuration steps are given in “Customize the Web
server” on page 118.
Plan to define the authentication method
The default method used by Tivoli License Manager to authenticate each
user of the administration and runtime servers, is that you, as the super
user, create a series of accounts, each of which has a password associated
with it. This information is stored in the administration server database.
However, if you are already using the Lightweight Directory Access
Protocol (LDAP) to authenticate user access to other applications, you can
configure it also for Tivoli License Manager. To use LDAP authentication,
you need to set up your Tivoli License Manager users with the same user
names as their LDAP user names. You need also to configure Tivoli License
Plan to configure
38 IBM Tivoli License Manager: Planning, Installation, and Configuration
Manager and the WebSphere Application Server to use LDAP
authentication. This latter process requires you to have available the LDAP
server address and port, and the LDAP domain name prefix and suffix.
Note: An option is available that enables you to import the user details
after having exported them from any database of users. This saves
you having to re-enter information which is already accessible to
you in an electronic format.
A wide range of LDAP servers is supported, as follows:
v Lotus Domino® Directory
v Microsoft® Active Directory
v IBM SecureWay® Directory Server
v Sun One Directory
v Novell eDirectory
v z/OS® LDAP directory
Special consideration needs to be taken with respect to the super
administrator ID ″tlmroot″. If possible, you should set it up on your LDAP
server. Otherwise you are advised to use it as little as possible, as you need
to toggle between LDAP and one of the other authentication methods each
time you need to use the super administrator user.
Full details of the configuration steps are given in “Define the
authentication method” on page 121.
An alternative to these two approaches (database and LDAP) is to
configure the product to store this information in an XML file within the
product’s install directory structure, with the passwords encrypted.
Plan to configure proxy servers
If you have, or want to use, a proxy server between the administration
server and the runtime server, or between the runtime server and its
agents, you can configure the product to use the proxy server. In the
former case you need to edit a configuration file at each runtime server,
which means that you can enable, disable or change the proxy server
details quite easily.
To enable the use of a proxy server between the runtime server and its
agents, you need to supply the proxy server information at agent
deployment time, so enabling, disabling or changing the proxy server
details requires that the agents are redeployed.
Full details of the configuration steps are given in “Configuring proxy
servers” on page 131.
Plan to use automatic computer label assignment
When you deploy an agent you must give it a unique identifier. The
various agent deployment methods allow you to define, at the moment of
deployment, the use of certain system variables, such as the computer’s
serial number, or its operating system, to add useful and unique
information into the agent’s computer label (node tag).
In all cases except Web deployment, this use of system variables is
controlled by you, as you are ″pushing″ the deployment. For Web
deployment, the user is ″pulling″ the deployment. Automatic computer label
Plan to configure
Chapter 1. Plan to deploy IBM Tivoli License Manager 39
assignment is a way of setting parameters that determine which
concatenation of text and variables to use for each agent platform.
Full details of the configuration steps are given in “Automatic computer
label assignment” on page 132.
Plan to import an up-to-date version of the IBM Catalog
Tivoli License Manager includes a copy of the IBM Catalog, which the
installation loads into the administration server database. However, this
catalog may not be the latest version, depending on when you obtained
the product CDs, or when you downloaded the CD images. You should
take an early opportunity to download an up-to-date version of the catalog
from the IBM Catalog Web site
This activity is described in “Import an up-to-date version of the IBM
Catalog” on page 134.
Plan to enable Java 2 Security
If you want to use Java 2 Security in WebSphere Application Server, you
need to configure both WebSphere Application Server and Tivoli License
Manager. The procedure is described in “Optionally configure Java 2
Security for a server” on page 135, and is performed after Tivoli License
Manager has been installed.
If you have Java 2 Security already enabled in an existing version of
WebSphere Application Server, you will not be able to use Tivoli License
Manager after the installation until you have enabled Tivoli License
Manager for Java 2 Security. You have two options:
v Disable Java 2 Security in WebSphere Application Server before
performing the Tivoli License Manager installation, and follow the full
configuration procedure for both products after the installation has
completed. This allows you, for example, to test that the installation has
completed successfully, before performing enabling Java 2 Security.
v Install Tivoli License Manager with Java 2 Security still enabled, but then
immediately configure it only in Tivoli License Manager.
Plan for disaster recovery
Creating backups to protect your files from disaster is not just a question
of taking copies of the data. Your Tivoli License Manager environment is
spread over several computers, and relies on the synchronization of the
data in the various databases. Because it is not feasible to take snapshots of
all the databases at the exact same moment, the following procedure is
recommended for backup and recovery:
v Periodic backups should be made of the administration server database
and the administration and runtime servers’ configuration files only.
v In the event of any disaster you should:
1. Uninstall and reinstall any servers that have been damaged by the
disaster
2. If the administration server database has been damaged by the
disaster uninstall and reinstall it
3. Uninstall all runtime databases and reinstall them
4. Restore the most recently backed up version of the administration
server database
5. Restore the most recently backed up version of the administration
and runtime server configuration files
Plan to configure
40 IBM Tivoli License Manager: Planning, Installation, and Configuration
6. Restart the servers. The runtime servers will reconstruct their
databases from the information on the administration server
database.
Attention: You should not take backups of the runtime server databases
as they cannot be used – you must never try to restore a runtime server
database. If something is wrong with the database you should uninstall the
component, selecting the option to drop the database, and then reinstall it.
When its runtime server plugs in again to the administration server after
this activity, the runtime server will reconstruct its database from the
information on the administration server database.
For full details about the disaster recovery procedure see IBM Tivoli License
Manager: Problem Determination.
Plan how to operate Tivoli License Manager
Tivoli License Manager provides Web interfaces that enable you to access the
administration and runtime servers. You do not need to install client software on
the computers from which you want to access the Web interfaces. All you need is a
Web browser.
The main Web interface is the password-protected interface on the administration
server that administrators can use to define the monitoring infrastructure and
license conditions and to produce historical reports.
The runtime server has a much smaller password-protected interface, where
administrators can obtain real-time software usage information. The runtime server
also hosts a Web page from which end users can deploy the agent software on
their computers. This page is not password-protected.
Attention: Any software that restricts in any way the availability of pop-up
windows in your Web browser must be switched off or disabled. This is because,
when you log into either the administration or the runtime GUI, the browser
window from which you have accessed the GUI closes, and a pop-up is launched,
containing the GUI. The software that attempts to control pop-up windows
includes most personal firewalls, certain freeware toolbars and taskbars, and a
wide variety of freeware or shareware utilities that specifically restrict the display
of pop-up windows or advertisements. Where possible, these programs’ settings
should be reset to switch off the pop-up suppression, or if this is not possible they
should be disabled or uninstalled.
Web user interface prerequisites
The following contains the prerequisites for the browser from which you access the
administration and runtime servers’ Web GUIs. As they are Web GUIs, you do not
need to access them from the computer where the servers are installed; you just
need the ability to make an HTTP connection to those servers.
Table 7. Supported browsers
Internet browser
One of the following browsers:
Windows platforms
Microsoft Internet Explorer, version 5.5 or later
Other supported platforms
Mozilla, versions 1.4 or 1.5
Plan to configure
Chapter 1. Plan to deploy IBM Tivoli License Manager 41
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Plan how to deploy the agents
This section provides you with the information to decide how you want to deploy
a Tivoli License Manager agent. Full details about the agent, its functionality, its
files and its commands can be found in Chapter 9, “The agent,” on page 217.
The information in this section first gives general information about agent
deployment, regardless of the deployment method:
v “Agent prerequisites”
v “Agent deployment parameter preparation” on page 45
Then information is provided about the prerequisites for each of the deployment
methods:
v “Using Web deployment” on page 46
v “Using the installagent command” on page 47
v “Using Tivoli Configuration Manager” on page 48
v “Using SSH or RSH for UNIX nodes” on page 49
v “Using Windows logon scripts” on page 51
v “Deploying OS/400 agents” on page 52
Also included is advice about scheduling your agent deployment, in “Scheduling
the agent deployment” on page 54.
Agent prerequisites
This section contains the prerequisites for running the agent component.
Notes:
1. These prerequisites are not for the deployment or installation of the agent. They
tell you what you need to have for the agent to run.
2. You should adjust the date, time, and time zone settings on each computer
where you plan to install an agent. It is not advisable to change these settings
when Tivoli License Manager is in use. However, if you need to change the
date or time on a computer where an agent is installed, you must stop the
agent, change the date or time, and then restart the agent again. See “Agent
commands” on page 227 for details of the commands to stop and start the
agent.
Software
GSKit communications software
The agent requires GSKit to implement communications. The appropriate version is
supplied with the product. The following list gives the versions that are used on the
various agent platforms:
Operating
System
Version GSKit Version
OS/400 V5R2 4d
V5R3 6b
Windows 7.0.2.8
All other platforms 7.0.2.6
Plan to operate
42 IBM Tivoli License Manager: Planning, Installation, and Configuration
Software (continued)
Certified Linux Kernels
Tivoli License Manager is certified to work on the following Linux kernels:
Platform Operating System Version Supported kernels Libraries
Intel x86 Red Hat Enterprise
Linux
ES/AS/WS, version 2.1
Update 2 (Standard or
Premium edition)
2.4.9-e24
glibc 2.2.4-32.3
2.4.9-e24smp
2.4.9-e24summit
2.4.9-e24enterprise
ES/AS/WS, version 3.0
Update 1 (Standard or
Premium edition)
2.4.21-9EL
glibc 2.3.2-95.6 2.4.21-9ELsmp
2.4.21-9ELhugemem
SUSE LINUX
Enterprise Server
8 SP3 2.4.21-138-default
glibc 2.2.5-213
2.4.21-138-psmp
2.4.21-138-smp
2.4.21-138-smp4G
iSeries Red Hat Enterprise
Linux
AS, version 3.0 for PPC
Update 2
2.4.21-15.EL glibc 2.3.2-95.20
SUSE LINUX
Enterprise Server
8 for IBM iSeries/pSeries
(64-bit, in 32-bit
compatibility mode) SP3a
2.4.21-147-iseries64 glibc 2.2.5-143
pSeries Red Hat Enterprise
Linux
AS, version 3.0 for PPC
Update 2
2.4.21-15.EL glibc 2.3.2-95.20
SUSE LINUX
Enterprise Server
8 for IBM iSeries/pSeries
(64-bit, in 32-bit
compatibility mode) SP3a
2.4.21-111-pseries64 glibc 2.2.5-139
zSeries and
S/390
Red Hat Enterprise
Linux
AS, version 3.0 for zSeries
and S/390 Update 1 (31-bit)
2.4.21-9.EL glibc 2.3.2-95.6
SUSE LINUX
Enterprise Server
8 for IBM Mainframes
(zSeries 31-bit)
2.4.19-3suse-SMP glibc 2.2.5-87
Certification of other Linux kernels may be announced from time-to-time on the support Web site.
WebSphere Application Server (for WebSphere Application Server applications)
If WebSphere Application Server is installed on the node where the agent is installed, the agent deployment
installs an additional agent module called the WebSphere Application Server agent, to recognize and monitor
applications running on WebSphere Application Server.
The versions of WebSphere Application Server running at the agent that are supported by this module are
5.0.x and 5.1.x.
Plan agent deployment
Chapter 1. Plan to deploy IBM Tivoli License Manager 43
Space
For all agents
Platform Resource type Space
required
Windows For the agent code, in the directory $WINDIR 25 MB
Logs and traces in the Tivoli Common Directory
(for its location see the Appendix on the Tivoli
Common Directory in the IBM Tivoli License
Manager: Problem Determination)
30 MB
UNIX For the agent code, in the directory /var/itlm 20 MB
Logs and traces in the Tivoli Common Directory
(for its location see the Appendix on the Tivoli
Common Directory in the IBM Tivoli License
Manager: Problem Determination)
30 MB
In the directory /usr/sbin 2 MB
In the directory /lib 2 MB
In addition, if WebSphere Application Server agent required
If the WebSphere Application Server agent is also required (see under Software in
previous table), you should add the following:
Windows and Linux RISC 60 MB
UNIX RISC 120 MB
Installed languages on OS/400
For all agents
You must install one of the supported languages as your primary or secondary
language on the OS/400 node:
Language code Language
2924 English
2928 French
2929 German
2932 Italian
2962 Japanese
2986 Korean
2980 Portuguese (Brazil)
2989 Simplified Chinese
2931 Spanish
2987 Traditional Chinese
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Plan agent deployment
44 IBM Tivoli License Manager: Planning, Installation, and Configuration
Agent deployment parameter preparation
Agents can be deployed in any of these ways:
v Locally, by you
v By the owner of the computer following your instructions
v Remotely, on an individual basis, by you
v In bulk, using distribution methods that you control
The following provides details of the information that you must supply when
deploying an agent:
Topological information
v Organization name
v Division name
v Runtime server address
v Runtime server port
v Whether a proxy server protects the node, and if so what is its address
and port
v Startup mode (sometimes called Secure Level), which determines
whether or not you want to use SSL for the initial communication
between the agent and the runtime server (subsequent communications
are determined by the values that the agent downloads from the runtime
server).
Agent-specific information
v Node tag (sometimes called computer label). This uniquely identifies the
agent within Tivoli License Manager. It does not need to correspond to
any local computer name, or the name of the owner, or the host name in
the network. In most deployment methods you can choose to generate a
value from local system variables. In the case of Web deployment, there
is a configuration parameter that allows you to set a default value for
the computer label, based on these system variables.
v In some bulk distribution methods (Using Tivoli Configuration Manager
and Using RSH/SSH on UNIX, OS/400) you must specifically identify
the node by its network name
v In one bulk distribution method (Using RSH/SSH on UNIX) you must
supply the administrator password of the node.
Required infrastructure information
v Supply the name of the GSKit security software that the agent uses. This
information is node platform-dependent and is documented in
“Parameters of the installagent command” on page 147. Supply the
value indicated. If the security system at the runtime server ever
requires a fix, it may be necessary to use a new version of GSKit, which
would be supplied with the fix.
v Supply the name of the security certificate to be used. This information
is documented in “Parameters of the installagent command” on page
147. Supply the value indicated. The default certificate name is
″cert.arm″. If you need to replace the default certificate with a certificate
of your own, you are strongly recommended to name your certificate
″cert.arm″ rather than change this value.
v Supply the name of the scanner software to be used. This information is
node platform-dependent and is documented in “Parameters of the
installagent command” on page 147. Supply the value indicated. If the
Plan agent deployment
Chapter 1. Plan to deploy IBM Tivoli License Manager 45
scanner software ever requires a fix, it may be necessary to use a new
version of software, which would be supplied with the fix.
Additional information required for Linux390
v Processor type, which specifies if the Linux390 image is running on CP
or IFL processors
v System active processors, which specifies the total number of processors
(CP or IFL, as appropriate, not both) in the CEC.
v Shared pool capacity. If the Linux390 image is configured to share
processors, this specifies the total number of shared processors (CP or
IFL, as appropriate, not both) in the CEC. Enter zero if no shared
processors are used by the image.
Using Web deployment
The user of the node where the agent is to be installed connects to the appropriate
runtime server and registers the node. The agent software is downloaded and
installed automatically.
With this option you can contact one runtime server but register the node with
another (by supplying the name of the other runtime server instead of the one you
are connected to).
You should also supply the user of the node with the details of who to contact
should an error message be received during the deployment.
There are a number of ways of passing the required information to the user, for
example e-mail.
The full instructions for deploying the agent using the Web are given in
“Deploying an agent over the Web” on page 140.
Web deployment prerequisites:
Platform
All supported agent platforms except the following operating systems:
Operating System Version
OS/400 V5R2
V5R3
Red Hat Enterprise Linux AS, version 3.0 for zSeries and S/390 (31-bit)
AS, version 3.0 for PPC, running on pSeries
SUSE LINUX Enterprise
Server
8 for IBM Mainframes (zSeries 31-bit)
The following details the prerequisites for deploying the agent component using
the Web.
Plan agent deployment
46 IBM Tivoli License Manager: Planning, Installation, and Configuration
Software
Internet browser
Windows Microsoft Internet Explorer, version
6.x or later
Supported iSeries and pSeries
platforms
Mozilla, version 1.0
Other platforms Mozilla, versions 1.4 or 1.5
Note: These browsers are prerequisites only for registering the client with the
runtime server. They are not needed if you choose a different method of
deploying the agent “Plan how to deploy the agents” on page 42, or after the
agent has been registered.
Java Runtime Environment
Before starting the deployment you should have already installed Java Runtime
Environment (JRE), with the Java Plug-in, as follows:
Supported iSeries and pSeries
platforms:
Version 1.3.1 from Sun
Other platforms: Version 1.4
If JRE is not present, and you are using Internet Explorer as your browser on
a Windows platform and are connected to the Internet, the prerequisite
version of JRE is installed automatically. In other circumstances, the Web
deployment option directs you to the appropriate Web site, from where you
can download and install JRE manually. Alternatively, you should install the
required version of JRE before commencing the Web deployment.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Using the installagent command
A platform-specific folder is copied from the runtime server to the node where the
agent is to be installed. Somebody runs the installagent command from this folder.
You can set this process up so that you run the command remotely, or you can ask
the user of the node to run the command once you have downloaded the
appropriate files to the node. The command installs and runs the agent, which
then connects to the appropriate runtime server and registers the node.
If the command is to be run by the user of the node, you should also supply the
user of the node with the details of who to contact should an error message be
received during the running of the command.
There are a number of ways of passing the folder containing the installagent
command and the required information to the user. For example, you can e-mail
the user with the folder as an attachment, or you can e-mail the user and give him
an address from which to FTP the folder. Alternatively, you may be able to FTP the
folder to the node and run the command remotely, yourself, if you have the
appropriate software.
The full instructions for deploying the agent using the installagent command are
given in “Deploying the agent manually (installagent command)” on page 145.
Plan agent deployment
Chapter 1. Plan to deploy IBM Tivoli License Manager 47
Installagent prerequisites: The following details the prerequisites for running the
installagent command on a node that you want to register as an agent.
Platform
All the supported platforms for the agent, except the following operating systems:
v OS/400 V5R2
v OS/400 V5R3
Space
20 MB for the folder that you copy to the node.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Using Tivoli Configuration Manager
If you have or are about to implement an appropriate version of Tivoli
Configuration Manager (see “Prerequisites for agent deployment using Tivoli
Configuration Manager” for details), you can use the facilities of its Software
Distribution component to distribute a software package block to one or more
agents. It enables you to benefit from the functions provided by Software
Distribution, among which are the following:
v Installation and customization of the agent are performed in silent mode from a
Tivoli region server.
v If any problems occur, the distribution is retried automatically.
v The results are returned to the server and stored in the server database.
v The checkpoint/restart mechanism makes the installation feasible even on slow
networks.
Tivoli License Manager is supplied with a software package block for each
platform on which the agent can be installed. You need to create separate profile
managers for each unique combination of operating system platform, runtime
server and division, associating with it the appropriate software block and the
endpoints where you want to deploy the agent. When you distribute the profile
manager, Software Distribution sends the software package block to the endpoint,
where it installs the folder that contains the installagent command and the agent
files, and then runs the command (see “Using the installagent command” on page
47).
The full instructions for deploying the agent using Tivoli Configuration Manager
are given in “Deploying agents using Tivoli Configuration Manager” on page 152.
Prerequisites for agent deployment using Tivoli Configuration Manager: The
following details the prerequisites for using Tivoli Configuration Manager for
agent deployment.
Agent platform
All the supported platforms for the agent.
Plan agent deployment
48 IBM Tivoli License Manager: Planning, Installation, and Configuration
Software
Product Platform Version
IBM Tivoli Management
Framework
Supported iSeries and
pSeries platforms
4.1 with fixes
4.1-TMF-0015 for
Linux-PPC (server) and
4.1-INVGW-0005 for
Linux-PPC (gateway)
installed
Supported zSeries
platforms
4.1.1
Other platforms 4.1
IBM Tivoli Configuration
Manager
Supported iSeries and
pSeries platforms
4.2 with fixes
4.2-SWD-0014 (server) and
4.2-SWD-0015 (gateway)
installed
Supported zSeries
platforms
4.2.1
Other platforms 4.2 with fix pack
4.2-TCM-FP02 installed
Space
20 – 30 MB for the software package block that is distributed, depending on the
platform.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Using SSH or RSH for UNIX nodes
To deploy the agent on UNIX nodes, you can use the Tivoli License Manager agent
deployment tool, which leverages an existing remote shell (RSH) or secure shell
(SSH) network to deploy the agent to nodes on the network. The steps are as
follows:
1. Copy the setup and other wizard files to a hard disk.
2. Obtain the libraries that are needed to enable the computer to operate as an
SSH client.
3. Place the libraries in the directory where the setup file for the wizard has been
copied.
You are now ready to run the tool (described in “Deploying agents to UNIX nodes
using SSH and RSH” on page 162).
The tool runs on Windows platforms (see the prerequisites in “Prerequisites for
agent deployment on RSH and SSH UNIX networks” on page 50). It does not need
to be run on a computer with any other Tivoli License Manager components
installed on it.
The tool enables you to identify the nodes on which you want to deploy the agent
and supply the node-specific parameters required for the deployment.
The tool distributes the installagent command and the agent files to one or more
UNIX nodes, where it is installed and run (see “Using the installagent command”
on page 47). If it is run on an SSH network the files are distributed using SSL.
Plan agent deployment
Chapter 1. Plan to deploy IBM Tivoli License Manager 49
Attention: The distribution information for each node includes the node’s root
password. If you allow the agent deployment tool to use this method you run the
risk that the distribution information is intercepted, compromising the security of
the node.
The full instructions for deploying the agent using RSH or SSH on UNIX nodes are
given in “Deploying agents to UNIX nodes using SSH and RSH” on page 162.
Prerequisites for agent deployment on RSH and SSH UNIX networks: The
following tables detail the prerequisites for running the agent deployment tool.
Agent deployment tool platform
The tool runs on any of the following operating systems:
Operating system Platform Patches, service packs,
fixes
Windows 2000 Professional (32-bit) Service Pack 3
2000 Server (32-bit)
2000 Advanced Server (32-bit)
Server 2003 Standard or Enterprise
Editions (32-bit)
XP Professional
Agent platform
The tool can distribute the installagent command (to deploy the agent) on one of the
following operating systems:
Operating system Version Patches, service packs,
fixes
IBM AIX 5.1 32-bit
5.1 64-bit (in 32-bit compatibility
mode)
5.2 32-bit
5.2 64-bit (in 32-bit compatibility
mode)
HP/UX 11i on PA-Risc 32-bit
11i on PA-Risc 64-bit (in 32-bit
compatibility mode)
Red Hat Enterprise
Linux
ES/AS/WS, version 2.1 for Intel
x86 (Standard or Premium edition)
ES/AS/WS, version 3.0 for Intel
x86 (Standard or Premium edition)
AS, version 3.0 for PPC (iSeries
and pSeries - 64-bit, in 32-bit
compatibility mode)
SUSE LINUX
Enterprise Server
8 for x86 Service Pack 3
8 for IBM iSeries/pSeries (64-bit,
in 32-bit compatibility mode)
Service Pack 3
Plan agent deployment
50 IBM Tivoli License Manager: Planning, Installation, and Configuration
Agent platform
Sun Solaris 8 Operating System for SPARC
platforms (32-bit)
8 Operating System for SPARC
platforms (64-bit)
9 Operating System for SPARC
platforms (32-bit)
9 Operating System for SPARC
platforms (64-bit)
Software
RSH/SSH server
daemon
A RSH/SSH server daemon must be installed on all target
nodes.
Security software If you want a secure distribution of the agent deployment
data (which includes the root password of the node) you
need to distribute the files in an SSH network. To do this,
you need to obtain the libraries that will enable the
Windows node from which you run the wizard to become
an SSH client. The wizard installs these libraries. The wizard
has been tested with the J2SSH-Lite libraries obtained from
3SP.
Space
On the Windows computer where you run the tool you need 130 MB for the tool.
You also need the same space as detailed for the installagent command (see
“Installagent prerequisites” on page 48).
On the UNIX agent computers , you need the same space as detailed for the
installagent command (see “Installagent prerequisites” on page 48).
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Using Windows logon scripts
This option enables you to leverage the Windows operating system’s facility that,
when a user logs on to a Windows network, runs a script on the user’s computer.
To implement this you need to ensure that the Microsoft Windows Domain
Controller is set up to run logon scripts, and the main script file is customized to
your network environment. You also need to customize the default configuration
file, and optionally set up specific configuration files for specific nodes. The
configuration file contains the parameters to run the installagent command.
It is important to note that the installation of the agent requires Administrator
rights. If your user cannot log on to the network as a user with Administrator
rights, the script cannot install the agent.
The full instructions for deploying the agent using Windows logon scripts are
given in “Deploy agents using Windows logon scripts” on page 170.
Plan agent deployment
Chapter 1. Plan to deploy IBM Tivoli License Manager 51
Prerequisites for agent deployment using Windows logon scripts: The following
tables detail the prerequisites for deploying agents using Windows logon scripts.
Platforms
Script preparation platform
The Windows logon script can be prepared on any runtime server.
Agent platform
The logon scripts are run by a user logging on to the Windows network domain
server from a computer running one of the following operating systems:
Operating system Platform Patches, service
packs, fixes
Windows 2000 Professional (32-bit) Service Pack 3
2000 Server (32-bit)
2000 Advanced Server (32-bit)
Server 2003 Standard or
Enterprise Editions (32-bit)
XP Professional
The logon script requires that the user of the node where the agent is to be
deployed logs on with Administrator rights.
Space
On the computer where you prepare the script, and on the Windows network
domain server, you need 20 MB for the script and its agent files.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Deploying OS/400 agents
To deploy an agent on a node running OS/400, you are provided with the
following options:
v “Use the OS/400 agent install wizard on a Windows computer connected to an
OS/400 node”
v “Use the OS/400 agent install wizard in silent mode” on page 53
When an agent has been installed on a node running OS/400, you have two
further options that can be exercised within your OS/400 environment:
v “Use Save Licensed Program and Restore Licensed Program to transfer the agent
from one OS/400 node to another” on page 54
v “Use cloning to transfer the agent from one OS/400 node to another” on page 54
Use the OS/400 agent install wizard on a Windows computer connected to an
OS/400 node: Run the Windows OS/400 agent install wizard on a platform that is
connected to an OS/400 node. The wizard offers you the option of a Typical or a
Custom installation. In the typical installation you are only required to supply a
minimum of information, the wizard supplying default values for the rest. In a
custom installation you can set all of the install parameters. The OS/400 agent is
then installed on the connected node.
Plan agent deployment
52 IBM Tivoli License Manager: Planning, Installation, and Configuration
Prerequisites for deploying the OS/400 agent from a Windows node: The following
tables describe the prerequisites for running the agent deployment tool.
Platforms
Agent deployment tool platform
The Windows wizard for installing OS/400 agents runs on the following operating
systems:
Operating system Platform Patches, service
packs, fixes
Windows 2000 Professional (32-bit) Service Pack 3
2000 Server (32-bit)
2000 Advanced Server (32-bit)
Server 2003 Standard or
Enterprise Editions (32-bit)
XP Professional
Agent platform
This wizard installs the agent on all supported OS/400 platforms (see “Agent
prerequisites” on page 42 for details).
Software on the Windows node
v Java Runtime Environment, version 1.4.1 or later
Software on the OS/400 agent
v Java Developer Kit, version 1.4.1 or later (shipped as licensed program 5722JV1)
v Host Servers option installed and running (shipped as licensed program 5722SS1,
option 12)
v QShell Interpreter option installed and running (shipped as licensed program
5722SS1, option 30)
v TCP/IP option installed and running (shipped as licensed program 5722TC1)
Space
On the computer where you run the wizard 30 MB is required in the temp directory.
See “Agent prerequisites” on page 42 for space requirements of the agent on the
OS/400 node.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Use the OS/400 agent install wizard in silent mode: Copy the OS/400 wizard
and its response file to the OS/400 node. Customize the response file with the
parameters appropriate for the node and then run the wizard in silent mode on the
node to install the agent.
Plan agent deployment
Chapter 1. Plan to deploy IBM Tivoli License Manager 53
Prerequisites for deploying the OS/400 agent directly on the OS/400 node: The
following tables describe the prerequisites for running the agent deployment tool.
Platforms
Agent deployment tool platform
The wizard for installing OS/400 agents directly on the node runs on all platforms
supported by the OS/400 agent. The wizard requires a login with permission to
install.
Software
On OS/400 agent Java Developer Kit, version 1.4.1 or later (shipped
as licensed program 5722JV1)
v Host Servers option installed and running
(shipped as licensed program 5722SS1, option
12)
v QShell Interpreter option installed and running
(shipped as licensed program 5722SS1, option
30)
Space
30 MB for the installation. See “Agent prerequisites” on page 42 for space
requirements of the agent on the OS/400 node.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Use Save Licensed Program and Restore Licensed Program to transfer the agent
from one OS/400 node to another: Once the agent is installed you can use the
Save Licensed Program option to save a copy of the agent. You can transfer this to
another OS/400 node, run the Restore Licensed program option on the other node,
and then edit the agent configuration file to customize the parameters for the new
agent.
Use cloning to transfer the agent from one OS/400 node to another: Once the
agent is installed you can use the cloning technique to create a clone of the OS/400
agent, and install it on another node. See your OS/400 documentation for details.
Scheduling the agent deployment
When you have decided which methods of agent deployment are appropriate for
your environment, create an agent deployment schedule. For example, create a
deployment calendar in which each division has a deployment date, allowing time
for the agents of division A to be deployed on runtime server X, before deploying
the agents of division B.
When the runtime servers have been installed and the divisions have been created,
implement the deployment schedule.
Note: You can check the progress of the scheduled deployments using the Agents
option available from the Manage Components section of the administration
server Web interface.
Plan agent deployment
54 IBM Tivoli License Manager: Planning, Installation, and Configuration
Plan how to install the catalog manager
This section explains the mechanisms used to install the catalog manager. There are
the following possibilities:
Local interactive installation
The catalog manager can be installed by running the Tivoli License Manager
install wizard interactively on the computer on which the catalog manager is
to be installed.
Local silent installation
The install wizard can also be run as a silent installation, using a response
file.
Note: Tivoli License Manager does not support the ″console″ install option
that was available with previous releases of the product.
Remote installation
If you are a user of the Software Distribution component of IBM Tivoli
Configuration Manager, you can install the Tivoli License Manager catalog
manager, by leveraging Software Distribution’s ability to distribute, install
and run an item of software on multiple remote nodes.
Tivoli License Manager is supplied with one software package block for the
catalog manager for all platforms on which it can be installed. You distribute
the appropriate software package block to the target computer, using
Software Distribution’s facility that enables you to supply the install
parameters.
The prerequisites for this option are given in “Additional prerequisites for
installing the catalog manager using Tivoli Configuration Manager” on page
57
These procedures install the catalog manager and set up a link to the
administration server database. If you have more than one administration server
database, you can set up aliases in the DB2 server or client on the computer where
the catalog manager is installed, to enable you to access the other databases. When
you open the catalog manager you select the required database to manage.
Catalog manager prerequisites
For supported platforms see “Supported platforms for the catalog manager” on
page 15
The following tables show the software, hardware, and space requirements for the
installation of the catalog manager.
Plan to install catalog manager
Chapter 1. Plan to deploy IBM Tivoli License Manager 55
Software
Database server
If the catalog manager is installed on the same computer as the
administration server database, the database server required is the same as
that used by the database, see “Prerequisites for databases” on page 29.
Database client
If the catalog manager is installed on a different computer than the
administration server database, you need a DB2 client or server to access the
database. The version of the client or server required is as follows:
On all Windows and UNIX platforms and Linux platforms on Intel x86,
one of the following versions:
v DB2 Universal Database, Enterprise Extended Edition client or
server, version 7.2.0 with fix pack 10a installed
v DB2 UDB, Enterprise Server Edition client or server, version
8.1.0 or 8.1.4.
On Linux platforms for iSeries, pSeries and zSeries, the following version:
v DB2 UDB, Enterprise Server Edition client or server, version
8.1.0 or 8.1.4
On Red Hat Enterprise Linux, version 3.0 (all supported versions and
processors), the following version:
v DB2 UDB, Enterprise Server Edition client or server, version
8.1.4
If you do not have this prerequisite, the install procedure can install it for
you. See “Auto-installation of prerequisite software” on page 32 for more
details.
Database driver
If you plan to use IBM DB2 Universal Database, Enterprise Extended Edition,
version 7.2.0 with fix pack 10a, you should also install JDBC, version 2.0.
Java Runtime Environment
The catalog manager requires Java Runtime Environment, version 1.4. This is
installed by the install wizard, automatically, and should not be uninstalled.
If Tivoli License Manager is completely uninstalled from a computer, this
version of Java Runtime Environment is also uninstalled.
UNIX shell
To install the catalog manager on UNIX platforms you must have the korn
shell (ksh) installed and activated.
Note: The shell must be present but the setup command to install the
catalog manager can be issued from any shell – not necessarily the korn
shell.
CPU
One of the following processors:
Intel Pentium III 800 MHz or equivalent
IBM RS/6000 (7044 recommended)
Plan to install catalog manager
56 IBM Tivoli License Manager: Planning, Installation, and Configuration
Memory
512 MB
Space
55 MB
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Additional prerequisites for installing the catalog manager using
Tivoli Configuration Manager
The following tables describe the prerequisites for using Tivoli Configuration
Manager for catalog manager deployment.
Platform
All the supported platforms for the catalog manager.
Software
Product Platform Version
IBM Tivoli Management
Framework
Supported iSeries and
pSeries platforms
4.1 with fixes
4.1-TMF-0015 for
Linux-PPC (server) and
4.1-INVGW-0005 for
Linux-PPC (gateway)
installed
Other platforms 4.1
IBM Tivoli Configuration
Manager
Supported iSeries and
pSeries platforms
4.2 with fixes
4.2-SWD-0014 (server) and
4.2-SWD-0015 (gateway)
installed
Other platforms 4.2 with fix pack
4.2-TCM-FP02 installed
Space
50 MB for the software package block that is distributed.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Optionally plan how to deploy the Tivoli Data Warehouse
enablement pack
What you need to know to enable you to decide where and how to install the
Tivoli Data Warehouse enablement pack is described in IBM Tivoli License Manager,
Version 2.1: Warehouse Enablement Pack, Version 2.1.0 Implementation Guide for Tivoli
Data Warehouse, Version 1.2.
Plan to install catalog manager
Chapter 1. Plan to deploy IBM Tivoli License Manager 57
Data Warehouse prerequisites
The following tables describe the prerequisites for the Tivoli Data Warehouse
enablement pack.
Tivoli Data Warehouse
Version 1.2
Server platforms
Data can be retrieved from all server and database platforms supported by Tivoli
Data Warehouse, version 1.2, except zSeries.
Software and hardware prerequisites
See IBM Tivoli License Manager, Version 2.1: Warehouse Enablement Pack, Version 2.1.0
Implementation Guide for Tivoli Data Warehouse, Version 1.2.
Appendix I, “Prerequisites,” on page 317 contains links to the prerequisite tables
for all components and options.
Plan how to populate the databases
When your servers and databases have been installed and your agents deployed,
the next step is to populate the databases, so prepare a schedule for performing
inventory scans. Scans are performed by the agent and are scheduled by division,
so you must plan a date and time for each division.
Consider the following when you decide on your schedule:
v As far as possible, scans should be scheduled for times when other activity at
the agent’s computer is low.
v Before the information is available for reporting, it must be transferred to the
runtime server and then to the administration server. Allow for this time, which
depends mainly on the number of agents attached and the configuration of the
communications between the servers. The information in “Estimating the
maximum time required to upload inventory scans” on page 59 tells you how to
calculate this figure.
v When you know the maximum upload time for your organization you can set
the schedule accordingly. If you schedule inventory scans to occur more
frequently than this maximum upload time, one scan will not have finished
being uploaded before the next begins. Thus, allow a little extra on top of this
calculation, and set the schedule period accordingly.
Note: You create the schedules for inventory scanning on the administration server
Web interface. This means that some time elapses between the time when
you record a schedule and the time when the agents can use it. For this
reason it is advisable to define the schedule well before the time at which
you want it to start.
The timing of the transmissions of data between Tivoli License Manager
components are defined in the system.properties configuration file. See
Appendix A, “Configuration settings,” on page 233.
Plan to deploy Tivoli Data Warehouse enablement pack
58 IBM Tivoli License Manager: Planning, Installation, and Configuration
Estimating the maximum time required to upload inventory
scans
To determine the maximum time required for an inventory scan to be uploaded,
you need to take the following into consideration:
v Maximum inventory upload time is different on Windows and UNIX nodes
v Uèploading the inventory of nodes that have not been upgraded to version 2.1
takes longer than on upgraded nodes
Thus you need to count your Windows and UNIX nodes, according to which
product version they are at, and apply the following timings:
Operating System Tivoli License Manager
version
Maximum upload inventory
time (seconds)
Windows 1.x 120
2.1 8
UNIX 1.x 600
2.1 16
These are estimated timings. The actual upload times depend on node activity and
connection activity.
Uninstalling, refreshing, repeat installations
Uninstalling components:
Detailed instructions for uninstalling components are provided in
Chapter 7, “Uninstall Tivoli License Manager,” on page 203.
Refreshing component installations:
It is not possible to refresh the installation of a main Tivoli License
Manager component. Instead, you should uninstall the component and
reinstall it afterwards, as if it was a fresh install. In the cases of the
database components, if you uninstall them you will be asked if you want
to drop (delete) the databases:
v You can always drop the runtime server database, as it will be recreated
automatically from information on the administration server database.
v You should never drop the administration server database, unless you
want to start over the process of creating and configuring your Tivoli
License Manager environment.
If you have made any changes to the server configuration files, take a
backup of those files before uninstalling the component, and restore them
from the backup after the component has been installed again.
However, the agent can be refreshed, by redeploying it, using any method.
Installing components in more than one pass:
Detailed instructions for installing components in more than one pass are
provided in “Installing components on the same computer in more than
one pass” on page 70. There are no particular planning implications, other
than the practical ones of how the subsequent passes differ from the first.
Plan to populate databases
Chapter 1. Plan to deploy IBM Tivoli License Manager 59
Plan to populate databases
60 IBM Tivoli License Manager: Planning, Installation, and Configuration
Chapter 2. Install Tivoli License Manager main components
This chapter describes how to install and configure the main components of Tivoli
License Manager. It is divided into the following sections:
v “Install scenario”
v “Pre-install tasks” on page 63
v “Installing the main components” on page 66
Before proceeding with the installation you should ensure that you have read the
planning chapter (see Chapter 1, “Plan to deploy IBM Tivoli License Manager,” on
page 1) and in particular the section “Plan how to install the server and database
components” on page 23.
Install scenario
A scenario for installing the product is as follows. It assumes that you want to
install the administration server on a different computer than its database, but that
each runtime server is to be installed on the same computer as its database. In
each of the steps where you are installing a component, Tivoli License Manager
offers to install any missing prerequisites, for you.
This is just one scenario. It shows one way of deploying the product, but there are
other ways. The rest of this chapter describes all you need to know to adjust this
scenario to your environment.
1. Log on to the computer where you want to have the administration server
database as administrator/root, and install it using a ″custom″ installation. To
run the wizard, see “Using the install wizard in interactive mode” on page 70.
2. Log on to the computer where you want to have the administration server as
administrator/root, and install it using a ″custom″ installation, identifying the
administration server database that you installed in step 1. At the end of the
wizard, the administration server is started automatically and your default
Web browser opened for you to log on to Tivoli License Manager. To run the
wizard, see “Using the install wizard in interactive mode” on page 70.
3. Validate the installation of these two components. See the IBM Tivoli License
Manager: Problem Determination for a description of the steps to do this for
both types of server.
4. Within the product, perform the following operations:
a. Log on as the super administrator and set up the initial organization (you
must always have at least one organization, even if you do not want to
use a multi-organization environment).
b. In a multi-organization environment, set up any additional organizations.
c. Set up administration accounts.
d. Assign the administration accounts to organizations.
e. If you are going to use SSL for communication between the administration
and runtime servers, enable SSL on the administration server.
See “Configure the administration server” on page 95 for detailed instructions
of the steps to take for each administration server.
5. Within the product, log on to each organization as administrator and perform
the following operations:
© Copyright IBM Corp. 2002, 2004 61
a. Register the runtime servers. This activity can be performed even though
the runtime servers have not yet been installed.
b. Set up divisions.
See “Perform the organization-related initial tasks” on page 96 for detailed
instructions of the steps to take for each organization.
6. For each computer where you want to have a runtime server, perform the
following operations:
a. Log on to each computer as administrator/root and install the runtime
server and its database using a ″typical runtime components″ installation.
To run the wizard, see “Using the install wizard in interactive mode” on
page 70.
b. Validate the installation of the runtime server and database components.
See the IBM Tivoli License Manager: Problem Determination for a description
of the steps to do this for both types of server.
c. Configure the runtime server.
d. If you are going to use SSL for communication between the administration
and runtime servers, configure the runtime server as an SSL client.
Note: This step is optional. When you install a runtime server, you can
choose to use SSL for secure communication. If you choose not to,
you can omit this step.
e. Check that the runtime server has been able to connect to the
administration server.
f. Create administration accounts.
g. Schedule inventory scans with a suitable delay to enable you to complete
the remaining setup activities.
h. Set up license entitlements
See “Configure the runtime servers” on page 97 for detailed instructions of
the steps to take for each runtime server.
7. Set parameters for event notification in the system.properties file of each
Tivoli License Manager server. See “Configure the mail notification settings for
a server” on page 117 for detailed instructions.
8. Configure the HTTP servers associated with the administration server and all
of the runtime servers. See “Customize the Web server” on page 118 for
detailed instructions.
9. Deploy the agent component to the computers you want to monitor. See
Chapter 4, “Deploy agents,” on page 139 for more details about how to deploy
the agents.
10. Install the catalog manager to enable you to manage your software catalog.
See Chapter 5, “Install the catalog manager,” on page 187 for more details
about how to install the catalog manager.
When you have completed these activities, Tivoli License Manager is up and
running.
Install scenario
62 IBM Tivoli License Manager: Planning, Installation, and Configuration
Pre-install tasks
Before proceeding with the installation you should ensure that you have read the
planning chapter (see Chapter 1, “Plan to deploy IBM Tivoli License Manager,” on
page 1) and in particular the section “Plan how to install the server and database
components” on page 23.
Before commencing running any install process on the computer, perform the
following tasks:
1. Determine install sequence: Determine the order in which you are going to
install the various components (see “Plan how to install the server and
database components” on page 23).
2. Select computer: Choose a computer on which you want to install a main
component.
Ensure that the computer has a fixed or IP address, or, if you want to use
dynamic IP addresses, make a note that the computer should always be
referred to by its host name.
Note: Changing host names or IP addresses on the computers hosting the
main components is not recommended, as you will have to reconfigure
your servers and, in the case of runtime servers, redeploy their agents.
3. Check prerequisites: Check that the computer satisfies the prerequisites (see
Appendix I, “Prerequisites,” on page 317).
Make sure you have sufficient disk space for the installation you require. The
wizard checks the disk space for you, and gives a warning if the available
space is insufficient.
4. Check time zone settings:
Attention: Ensure that the time and time zone settings on this computer are
correct. If the computers where the main components are installed are not
synchronized in Universal Time Coordinates (UTC), either through incorrect
settings at installation, or by a change of settings during use, the product may
fail or its results become unreliable. From such a situation there is no recovery.
You are also strongly recommended to install a system that uses the Network
Time Protocol to maintain the correct time on the computers of your main
components.
5. Check language settings: If you are installing a server component in a
double-byte character set (DBCS) environment, ensure that the primary
language environment settings (cultural conventions, language, and keyboard)
are correct. Incorrect settings can result in communications failures between
the administration and runtime servers and between runtime servers and
agents.
6. On UNIX: Ensure availability of operating system commands: The product
installation uses native operating system commands on UNIX. In particular, it
uses the find and grep commands. This means that if you have software
installed that enables other commands with the same names as these, the
software must be uninstalled or disabled.
7. On UNIX, check for old setup files: If you are installing on a UNIX platform,
ensure that the /usr and /opt directories do not contain the untared setup file
that has been used to install WebSphere Application Server at some time, as
its presence can cause the installation to fail.
8. On UNIX, check for the existence of the DB2 configuration file: On UNIX
platforms, if DB2 is installed, you should check for the existence of the
following DB2 configuration file:
Pre-install tasks
Chapter 2. Install Tivoli License Manager main components 63
<DB2InstanceHome>/sqllib/db2profile
where <DB2InstanceHome> is the home directory of the DB2 instance owner,
for example, /home/db2inst1.
If this file is not present, it means that the original DB2 installation is not
configured correctly, and it should be uninstalled before you attempt to run
this installation.
9. On UNIX, check that the DB2 configuration file does not contain a shell
call: On UNIX platforms, if DB2 is installed, check that the
<DB2InstanceHome>/sqllib/db2profile file does not contain a shell call or
invocation. If it does it must be removed as the presence of such a call causes
the installation to go into an endless loop.
10. On Windows, check PATH if DB2 prerequisite installed: If a prerequisite
version of DB2 is installed on the computer, make sure that the PATH variable
contains the correct path for DB2, for example typing echo %PATH% at the
Windows command line. Verify the presence of the DB2 ...\bin directory (for
example, C:\Program Files\IBM\DB2\bin) in the path. If it is not there it
should be added.
11. Check computer is correctly configured for auto-installed prerequisites: If
you plan to use the auto-install facility for the prerequisite versions of DB2 or
WebSphere Application Server, ensure that you have read the documentation
for the prerequisites, have checked that there is sufficient space available, and
that the computer is correctly configured for them. For example, check that the
kernel on HP/UX and Solaris platforms is correctly configured for DB2.
12. Start DB2: If you already have a supported database prerequisite for this
installation, start the DB2 services.
13. Collect install information: Ensure that you have the required information:
v The name of the directory in which you want to install the Tivoli License
Manager components.
v Which components are to be installed on this computer.
v The password that is to be created for the tlmsrv user, and, if different and
appropriate, the passwords you want to use for the runtime server
communication, and the DB2 administration user (if the install wizard is to
install the bundled DB2 prerequisite). In addition, if you want the wizard to
install the bundled version of WebSphere Application Server in a Windows
platform, you must supply the user ID and password of an existing user
with Administrator rights, to set up WebSphere Application Server and the
HTTP Server as services.
All of these passwords have a maximum length of 20 characters and can
only use the characters A-Z, a-z, 0-9, +, -. In addition, for the tlmsrv and the
DB2 administration user passwords, you must ensure that they satisfy the
password rules on the computer where they are created, and that they are
not already present on the computer (the only exception to this is that the
tlmsrv password can already exist if you have already installed a Tivoli
License Manager server or database component on the computer).
v If you intend to let the wizard install one or both of the prerequisites,
ensure you have the CDs or CD images ready, and that you have decided
the DB2 administration user id and password, and have noted the
administrator password for the WebSphere Application Server installation.
v If you are installing one or both of the administration server or the
administration server database, prepare the following information:
Pre-install tasks
64 IBM Tivoli License Manager: Planning, Installation, and Configuration
– The host name of the computer where the administration server database
is already installed (not needed if you are installing the database on the
computer where the wizard is running)
– The port number to be used for the remote administration server
database (not needed if you are installing the database on the computer
where the wizard is running). The default port number for DB2 is 50000.
However, you should check that this is the number that has been
configured. To do this check the services file for the computer where the
DB2 server is installed:
UNIX
/etc/services
Windows
<ProgramFilesDir>\system32\drivers\etc\services
Note: <ProgramFilesDir> represents the value of the Windows
registry entry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir
It is important to use this registry entry to get the value,
because there may not be a directory named ″Program Files″
for locales other than English. For example, the German locale
installs Windows files in a directory named ″Programme″. The
value should be obtained from the registry rather than relying
on the %ProgramFiles% environment variable, because the
environment variable is not available on all Windows versions.
Search for a row with the following information:
<service> <port>/tcp # Connection port for DB2
If there is more than one entry like this, find the latest entry and note the
value for port.
– On UNIX platforms, you may be required to supply the user name and
home directory of the DB2 instance owner, depending on the type of
installation.v If you intend to install a runtime server, prepare the following information:
– The exact name of the organization for which the runtime server is being
installed. If you are adding a runtime server for an existing organization,
ensure that this name is exactly the same as the name under which the
organization has been registered on the administration server Web
interface.
– The exact name with which you intend to register the runtime server you
are installing.
– The host name of the computer where the Tivoli License Manager
administration server is installed or will be installed, and the port
number that you have or will use.
– If you are going to use SSL communication between the runtime server
and its administration server you need to prepare the SSL port to use
– On UNIX platforms, you may be required to supply the user name and
home directory of the DB2 instance owner, depending on the type of
installation.
Pre-install tasks
Chapter 2. Install Tivoli License Manager main components 65
Appendix B, “Installation parameter list and checklists,” on page 251 provides
the following useful information:
v A list of the installation parameters, showing which are required for each
installation option.
v A checklist for the installation and configuration parameters for the
administration server and database
Installing the main components
Tivoli License Manager components are installed by a single install wizard that can
be used on all supported platforms. The setup file is found in the following
directories of the server and agent CD:
AIX setup/servers/AIX/setupServers.bin
HP/UX setup/servers/Hpux/setupServers.bin
Linux setup/servers/Linux/setupServers.bin
Linux 390 setup/servers/Linux390/setupServers.bin
Linux ppc setup/servers/LinuxPPC/setupServers.bin
Sun setup/servers/Solaris/setupServers.bin
Windows setup\servers\Win32\setupServers.exe
Before proceeding with the installation you should ensure that you have read the
planning chapter (see Chapter 1, “Plan to deploy IBM Tivoli License Manager,” on
page 1) and in particular the section “Plan how to install the server and database
components” on page 23.
Using the install wizard, you can install or upgrade the Tivoli License Manager
administration and runtime server components and configure WebSphere
Application Server for these servers.
If the computer already has components of a prior version of Tivoli License
Manager installed, they must be uninstalled. See Chapter 6, “Migrate to version
2.1,” on page 201 for full details.
Choosing the install method
Before proceeding with the installation you should ensure that you have read the
planning chapter (see Chapter 1, “Plan to deploy IBM Tivoli License Manager,” on
page 1) and in particular the section “Plan how to install the server and database
components” on page 23.
There are three possible ways of running the install wizard:
Interactive mode
This uses a GUI that enables you to enter the required information
interactively on a series of panels.
It is invoked by launching the wizard’s setup command without
arguments.
It is fully described in “Using the install wizard in interactive mode” on
page 70.
Pre-install tasks
66 IBM Tivoli License Manager: Planning, Installation, and Configuration
Silent mode
When the install wizard runs in silent mode, it takes the parameters it
requires from an InstallShield response file. The response file,
recordFile_Install.txt, is provided with Tivoli License Manager in the
same directory as the wizard’s setup program. You must edit this file to
provide the values for parameters that the wizard must set.
The procedure to run the install wizard in silent mode is as follows:
1. Log on to the computer where you want to install or upgrade Tivoli
License Manager components as a user with administrator rights on
Windows platforms or as root on UNIX platforms.
2. If you are running the installation from the server and agent CD, copy
the response file recordFile_Install.txt from the setup\servers\
directory on the CD to a temporary directory on a hard disk.
Otherwise, identify the response file in the hard disk copy of the CD.
3. Edit the response file so that the parameters describe the installation
that you want to perform. A full description of the parameters is
provided in Appendix C, “Response files and software package blocks
for silent and remote installations and uninstallations,” on page 267.
4. If you want the silent installation to also install one or both of the
bundled prerequisites, you cannot run the installation from the CD, and
auto-install the bundled prerequisite software from CD as part of the
same process. Instead, you must do one of the following:
v Run the install wizard from a hard disk image of the server and
agents CD.
v Copy the install setup file for your platform, and the file CD
drive:\setup\servers\setupServers.jar onto hard disk, maintaining
the directory structure and names as they are in the CD.
v Make a hard disk image of each of the prerequisite software install
CDs you will be needing to use.
v Install the prerequisites yourself, before commencing the Tivoli
License Manager installation.5. Attention: Read the license agreement (ITLM21LICENSE.txt) in the
license directory of the servers and agents CD. By continuing with this
process and launching the setup command you are giving your implicit
agreement to the terms of the license agreement. Make sure you agree
with the terms and conditions before you proceed.
6. Launch the wizard’s setup command, as follows:
–options ″<response_file_path>\recordFile_Install.txt″ –silent
Where <response_file_path> is either the full path of
recordFile_Install.txt, or its path relative to the setup file.
For example, setupServers.exe –options
″C:\temp_silent\recordFile_Install.txt″ –silent runs the install wizard
silently, using a response file in the directory C:\temp_silent.
Notes:
a. On UNIX computers, although the korn shell must be installed and
activated, the setup command can be issued from any shell.
b. On UNIX computers, the name of the directory from which you
launch the setup file, and the names of any directories in the path
to that directory, must not contain blanks.
Choosing install method
Chapter 2. Install Tivoli License Manager main components 67
c. If you want to move the setup file from the CD on to disk before
launching it, you must move both the setup*.exe/bin and the
corresponding ../setup*.jar, and maintain their relative directory
structure.
d. On Windows computers, if Windows Terminal Server is installed on
the computer where you want to run the setup file, or you are
accessing another computer using Windows Terminal Services, you
must launch the wizard as follows:
1) Select the Add/Remove Programs option from the Control
Panel.
2) Click Add New Programs.
3) Click CD or Floppy, and the Install Program From Floppy Disk
or CD-ROM wizard window will open. Click Next.
4) Click Browse, navigate to the setup file, and select it by
highlighting it and clicking Open.
5) The path of the setup file is displayed in the wizard page (if the
path to the file contains spaces, the whole path is enclosed in
double quotation marks). Add –options
″<response_file_path>\recordFile_Install.txt″ –silent, as
appropriate, after the setup file path.
6) Click Finish to exit from the wizard and run the setup file.
This procedure ensures that the Windows computer with Terminal
Server or Terminal Services is in install mode when the setup file is
launched.
The same objective can also be achieved by changing into install
mode manually, and then back again after the installation is
complete. To change into install mode manually, issue the command
change user /install from a Windows command line. Then issue the
command to run the setup file. After the installation has completed,
you must issue the command change user /execute to return to
execute mode.
The silent wizard provides almost the full functionality of the interactive
wizard, with the following exceptions:
v You cannot browse to identify the product install directory. It must be
provided as a full pathname, and if the pathname includes directories
with spaces in their names, it must be enclosed in double quotes.
v There is no ″Typical″ install option. On the interactive wizard you can
choose between ″All components″, ″Typical″, and ″Custom″, but in the
response file you either set the setup type to ″Full″, for an ″All
components″ installation, or leave it blank and individually select the
components to install by changing their selection status to ″true″.
v The silent wizard, like the interactive wizard, installs the prerequisite
software for you, if it is not already installed (see “Obtaining and
installing the prerequisite software” on page 31 for details). If you are
certain that one or both of the product prerequisites are installed on the
target computer, you can skip the search for these items by setting one
or both of the skip-search parameters in the response file. You should
remember that if you are installing a server component on its own, it
only needs the database client software. In all other circumstances you
should have the database server software.
Choosing install method
68 IBM Tivoli License Manager: Planning, Installation, and Configuration
v When supplying customization data, such as organization, runtime
server name, and passwords, you should only use characters that are in
the codeset of the target computer. You should also remember that those
passwords which relate to any user ids that are created on the target
computer must respect the password rules of the target computer.
v Passwords are stored in the response file in clear (unencrypted). You
should be aware that this may be an infraction of the security rules at
your workplace.
The results of the installation can be seen by viewing the messages and
traces. See IBM Tivoli License Manager: Problem Determination for details.
You may find this option useful if you are installing a large number of
runtime servers and databases on different computers, as you can use the
same options file on all computers, changing only a small number of
parameters, for example, the runtime server name.
See Appendix C, “Response files and software package blocks for silent
and remote installations and uninstallations,” on page 267 for a full
description of the recordFile_Install.txt file. See also “Using the install
wizard in interactive mode” on page 70 for more information about the
values you should supply in that file.
Remote installation using Tivoli Configuration Manager
If you are a user of the Software Distribution component of Tivoli
Configuration Manager you can leverage the Software Distribution facility
to install and run a program remotely.
Tivoli License Manager is supplied with a software package block for each
platform on which you can install the servers and databases. The software
package block contains the install wizard and the response file for that
platform. It is called tlm<platform>server.spb and can be found in one of
the SPB CDs, as follows:
Software Package Block CD (Windows, AIX, HP/UX, and SUN)
AIX tlmaixserver.spb
Hpux tlmhpuxserver.spb
Solaris tlmsunserver.spb
Win32 (Windows) tlmwinserver.spb
Software Package Block CD (Linux, OS/400)
Linux tlmlinuxserver.spb
Linux390 tlmlinux390server.spb
LinuxPPC tlmlinuxppcserver.spb
You should import the software package block into a profile manager and
subscribe the target computer to the profile manager. When you distribute
the profile manager, you are asked to supply the install parameters. See
“Software package block keys for server and database installations using
Tivoli Configuration Manager” on page 280 for a full description of the
parameters. See also “Using the install wizard in interactive mode” on
page 70 for more information about the values you should supply.
The software package block is installed on the target computer, and the
install wizard is launched in silent mode. Any errors identified by software
distribution are reported through its reporting channels (for example, a
failure to install the SPB on the node). Any errors found by the installation
wizard are reported in the message and trace logs. Details of these logs,
Choosing install method
Chapter 2. Install Tivoli License Manager main components 69
and the steps to take to validate the installation can be found in IBM Tivoli
License Manager: Problem Determination.
Attention: Security considerations: The install parameters that you
supply include one or more passwords. The passwords are saved in
unencrypted form in the software package block. The software package
block itself is not an encrypted file. Thus, the moment you type those
passwords into the file you may be incurring a breach of the security rules
of your installation. The transmission of the software package block to the
target computer is managed by Tivoli Management Framework, which can
be enabled to implement 56-bit DES encryption on gateway to endpoint
unicast communication (encryption is not supported on multicast
distributions).
Installing components on the same computer in more than
one pass
You can choose to install the Tivoli License Manager components on a computer in
more than one pass. However, there are some minor changes to the procedures
when you perform the second pass, as follows:
Interactive install
v The interactive wizard offers you no choice of installation type. Instead,
a panel is displayed showing the components already installed, and you
can choose one or more of those not yet installed.
v The ″tlmsrv″ user will have already been created, so you only need to
confirm the password.
Silent install (including using Tivoli Configuration Manager)
v You should set the appropriate parameters in the response file to install
the components you require. The ″All components″ option must not be
selected; you should leave the setupType parameter blank to take the
default value of ″Custom″.
v If you select any components for installation that have already been
installed, they will not be refreshed, but the parameter will be ignored.
v The value used in the original installation for the password for the
″tlmsrv″ user must be supplied.
Using the install wizard in interactive mode
The installation of the Tivoli License Manager server or database components is
divided into these phases:
Starting the installation
Commence by following the instructions in “Starting the installation” on
page 73. The panels that are displayed in this section depend on the
installation type, the components selected to install, and whether you want
to install the bundled prerequisites. Figure 5 on page 71 helps you
understand the order in which panels will be displayed (note that in the
diagram the acronym ″WAS″ is used to indicate the WebSphere Application
Server):
Choosing install method
70 IBM Tivoli License Manager: Planning, Installation, and Configuration
Typical, Custom, or All components
Tivoli License Manager offers these ways to install the main components,
from which you should choose one:
v “Typical installation of the administration components” on page 83
v “Typical installation of the runtime components” on page 82
v “Custom installation” on page 84
v “All components installation” on page 89
The panels that are displayed in these sections depend on the installation
type and the components selected to install. Figure 6 on page 72 helps you
understand the order in which panels will be displayed:
Welcome
License agreement
Installation location
Select wizard language
Component selection
All componentsTypical
Typical componentgroups selection
Custom
Custom componentsselection
DB2prerequisite
found?
Yes
No
DB2 prerequisitesearch
WASprerequisite
found?
Yes
No
InstallbundledDB2?
Yes
No
InstallbundledWAS?
Yes
No
WAS prerequisitesearch
DB2 prerequisiteparameters
WAS prerequisiteparameters
Launchwizard
Go to nextdiagram
On this panel you eitherlocate a valid prerequisiteversion, or tell the wizardto install the bundled DB2.
On this panel you eitherlocate a valid prerequisiteversion, or tell the wizardto install the bundled WAS.
On this panel you select a “Typical”, “Custom”or “All components” installation.
On this panel you select thecomponents you want to install.
On this panel you select the“Typical” component groups(runtime server and databaseor administration server anddatabase) you want to install.
Figure 5. Starting the installation: panel flow
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 71
Completing the installation
Complete the installation by following the instructions in “Completing the
installation” on page 91. The panels that are displayed in this section
depend on the whether you want to install the bundled prerequisites.
Figure 7 on page 73 helps you understand the order in which panels will
be displayed:
Typical runtime
“Typical” runtime baseconfiguration parameters
“Typical” administration baseconfiguration parameters
Use“tlmsrv”
password forruntime communication
password?
Yes
No
Runtime communicationpassword
Are youinstalling the
administration serverwithout itsdatabase?
Yes
NoAdministration serverdatabase connection
Continue fromprevious diagram
Go to nextdiagram
Typical administration Custom
Custom base configurationparameters (varies
according to thecomponents selected
“All components” baseconfiguration parameters
All components
Are youinstalling the
runtime serverwithout itsdatabase?
Yes
NoRuntime server
database connection
Figure 6. Typical, Custom or All components installation: panel flow
Installing in interactive mode
72 IBM Tivoli License Manager: Planning, Installation, and Configuration
Before proceeding with the installation you should ensure that you have read the
planning chapter (see Chapter 1, “Plan to deploy IBM Tivoli License Manager,” on
page 1) and in particular the section “Plan how to install the server and database
components” on page 23.
Starting the installation
Follow these steps:
1. Log on: Log on to the computer where you want to install Tivoli License
Manager as a user with administrative rights (Administrator on Windows
platforms or root on UNIX platforms).
2. Check location of setup file (if installing bundled prerequisites): If you
want the Tivoli License Manager installation to also install one or both of the
bundled prerequisites (DB2 or WebSphere Application Server), you will not be
able to run the installation from the CD, and auto-install the bundled
prerequisite software from CD as part of the same process. Instead, you must
do one of the following:
v Run the install wizard from a hard disk image of the server and agents CD.
v Copy the install setup file for your platform, and the file CD
drive:\setup\servers\setupServers.jar onto hard disk, maintaining the
directory structure and names as they are in the CD.
v Make a hard disk image of each of the prerequisite software install CDs you
will be needing to use.
v Install the prerequisites yourself, before commencing the Tivoli License
Manager installation. 3. Launch: Launch the setup file for Tivoli License Manager. (the names and
locations of the setup files are given at the beginning of “Installing the main
components” on page 66).
Notes:
a. On UNIX computers, although the korn shell must be installed and
activated, the setup command can be issued from any shell.
b. On UNIX computers, the name of the directory from which you launch the
setup file, and the names of any directories in the path to that directory,
must not contain blanks.
InstallbundledDB2?
Confirm selections
Yes
No
InstallbundledWAS?
Yes
No
DB2 setup filelocation
WAS setup filelocation
Continue fromprevious diagram
Finish
Figure 7. Completing the installation: panel flow
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 73
c. If you want to move the setup file from the CD on to disk before
launching it, you must move both the setup*.exe/bin and the
corresponding ../setup*.jar, and maintain their relative directory
structure.
d. On Windows computers, if Windows Terminal Server is installed on the
computer where you want to run the setup file, or you are accessing
another computer using Windows Terminal Services, you must launch the
wizard as follows:
1) Select the Add/Remove Programs option from the Control Panel.
2) Click Add New Programs.
3) Click CD or Floppy, and the Install Program From Floppy Disk or
CD-ROM wizard window will open. Click Next.
4) Click Browse, navigate to the setup file, and select it by highlighting it
and clicking Open.
5) Click Finish to exit from the wizard and run the setup file.
This procedure ensures that the Windows computer is in install mode
when the setup file is launched.
The same objective can also be achieved by changing into install mode
manually, and then back again after the installation is complete. To change
into install mode manually, issue the command change user /install from a
Windows command line. Then issue the command to run the setup file.
After the installation has completed, you must issue the command change
user /execute to return to execute mode.
Attention: A command line window is opened prior to the display of the
first wizard panel. Do not close this window.
4. Select wizard language: The wizard starts and requests you to select the
language version of the wizard that you want to use. It then displays the
product’s splash screen.
Note: As the language selection screen is displayed before you select the
wizard language, it is displayed in the language of the locale of your
machine, provided that language is supported. Supported languages
are: Bulgarian, Croatian, Czech, Danish, Dutch, English, Finnish, French,
German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian,
Polish, Portuguese, Portuguese (Brazil), Romanian, Russian, Simplified
Chinese, Slovak, Slovenian, Spanish, Swedish, Traditional Chinese,
Turkish. If you are not in one of these locales, these screens may be
unreadable, and you should temporarily switch your computer to a
supported locale.
5. Welcome panel: The welcome panel is now displayed. It reminds you that
you should read the planning chapter of this document before starting to try
and install the product. Click Next to continue.
6. License agreement panel: The license agreement panel is now displayed.
Read the license agreement thoroughly. You must select the radio button to
accept the license agreement before you can proceed by clicking Next. Attention: The license agreement for Tivoli License Manager also contains
the restricted use license that is required if you intend to let the wizard install
DB2 or WebSphere Application Server for you. Make sure you agree with the
terms and conditions before you proceed.
7. Install location: The following panel is displayed:
Installing in interactive mode
74 IBM Tivoli License Manager: Planning, Installation, and Configuration
Accept the default location displayed, type in a different location, or click
Browse to select a different location. If the directory does not exist it will be
created.
Attention: Do not install the server and database components of Tivoli
License Manager in the same directory as any other product. In particular, do
not attempt to install any of the components that this wizard installs in the
same directory as the catalog manager component, which has its own install
wizard. The reason for these restrictions is that many products use Java
Virtual Machine (JVM), and each product must have its appropriate version
installed. Installing two products in the same directory causes just one
instance of JVM to be installed, and one of the products may have the wrong
version. Moreover, if you uninstall one of the products, the JVM is also
uninstalled, leaving the other product without a working version.
The location where the selected components are to be installed. Specify a valid
directory that does not contain any other installed product.
Click Next.
8. Component selection: The following panel is displayed:
There are three options:
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 75
Typical
Installs the administration server and its database, the runtime server and
its database, or both.
Notes:
a. SSL is not enabled with this option, but can be enabled after the
installation, if required, by changing the configuration of the servers
(see “Configure SSL” on page 98 for details).
b. The agent cannot be installed using this option. If you want to install
an agent on this computer and you do not want to use the ″All
components″ installation option, you should first install the
administration server and the runtime server to which the agent is to
belong. Then you should use one of the options for agent deployment
described in Chapter 4, “Deploy agents,” on page 139.
If you select this option, and click Next, a screen is displayed where you
select which component groups you want to install:
Select one or both of the following items:
Administration components (server and database)
Installs the administration server and its database.
Runtime components (server and database)
Installs the runtime server and its database.
If you select both component groups, the wizard installs all components
except the agent (to install an agent at the same time, use the Back button
to return to the previous screen and select the All components
installation).
Note: If you want to select both groups, follow the instructions in this
manual for making an All components installation, with the
exception that if you are making the installation on a Linux390
computer, the parameters relating to the Linux390 agent will not be
displayed.
Make your choice and click Next.
Continue at step 9 on page 78.
Installing in interactive mode
76 IBM Tivoli License Manager: Planning, Installation, and Configuration
Custom
Enables you to choose any combination of the server and database
components.
Note: The agent cannot be installed using this option. If you want to
install an agent on this computer and you do not want to use the
All components installation option, you should first install the
administration server and the runtime server to which the agent is
to belong. Then you should use one of the options for agent
deployment described in Chapter 4, “Deploy agents,” on page 139.
If you select this option, and click Next, a screen is displayed where you
select which components you want to install:
Select the components that you want to install, and click Next.
Continue at step 9 on page 78.
All components
Installs the administration server and its database, a runtime server and
its database and the agent. The installation uses default values for almost
all variables, only requiring you to supply the password to the ″tlmsrv″
user and the organization name.
Notes:
a. SSL is not enabled with this option, but can be enabled after the
installation, if required, by changing the configuration of the servers
(see “Configure SSL” on page 98 for details).
b. This option installs the agent on this computer. Be aware of the
implications of monitoring the computer on which the servers and
databases are installed. Prerequisite software, for example WebSphere
Application Server, running on this computer must not be prevented
from starting because the runtime server is not available. Using the
administration server Web UI, you must define entitlement settings
that allow prerequisite software to run offline.
Click Next.
Continue at step 9 on page 78.
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 77
9. DB2 prerequisite check: The wizard checks that a supported version of DB2
is installed on the computer (see “Plan how to install the server and database
components” on page 23 for full details of supported versions). If you are not
installing a database component it looks first for a supported DB2 client, and
only if it does not find it does it look for a supported DB2 server.
If it finds the prerequisite,
continue at step 10.
If it cannot find the prerequisite, it displays the following screen:
If you have an unsupported version of DB2 on this computer you must stop
the installation by clicking Cancel. If you do not do this, when the wizard
attempts to install version 8.1 of DB2 it fails, because different versions of DB2
cannot co-exist on the same computer.
If you know that a supported version of DB2 exists on the computer, that the
wizard has been unable to find, select Locate the DB2 install directory:. A text
field is displayed where you can enter the directory where it is installed, or
browse to it using the Browse button.
Windows
On Windows, identify the directory where DB2 is actually installed,
for example, C:\Program Files\DB2.
UNIX On UNIX, identify the home directory of the DB2 instance owner, for
example /home/db2inst1
Otherwise, select Let the wizard install IBM DB2 UDB, Enterprise Server
Edition, version 8.1.
Click Next to continue. The missing prerequisite is installed at a later stage in
the wizard. See “Auto-installation of prerequisite software” on page 32 for
more details about the auto-installation of prerequisites.
10. If server installation: WebSphere Application Server prerequisite check: If
you have selected a server component to install, the wizard checks that a
supported version of WebSphere Application Server is installed on the
computer (see “Plan how to install the server and database components” on
page 23 for full details of supported versions).
Installing in interactive mode
78 IBM Tivoli License Manager: Planning, Installation, and Configuration
If it finds the prerequisite,
continue at step 11.
If it cannot find one, it displays the following screen:
If you have an unsupported version of WebSphere Application Server on this
computer you must stop the installation by clicking Cancel. If you do not do
this, when the wizard attempts to install version 5.1 of WebSphere Application
Server it may fail, because for different versions of WebSphere Application
Server to co-exist on the same computer you have to install them in a
particular way that is not within the scope of the install wizard.
If you know that a supported version of WebSphere Application Server exists
on the computer, that the wizard has been unable to find, select Locate the
WebSphere Application Server install directory:. A text field is displayed
where you can enter the directory where it is installed, or browse to it using
the Browse button.
Otherwise, select Let the wizard install IBM WebSphere Application Server,
version 5.1.
Click Next to continue. The missing prerequisite is installed at a later stage in
the wizard. See “Auto-installation of prerequisite software” on page 32 for
more details about the auto-installation of prerequisites.
11. If required: DB2 prerequisite information: If you asked the wizard to install
the bundled prerequisite version of DB2 it now asks you for the information it
needs to install it.
If you did not ask the wizard to install DB2,
continue at step 12 on page 81.
If you asked the wizard to install DB2, it displays the following panel:
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 79
Enter the following information:
IBM DB2 path or IBM DB2 instance owner’s path
The data you enter depends on the platform, as follows:
Windows
On Windows, supply the path where you want to install DB2, for
example: C:\Program Files\IBM\DB2.
UNIX On UNIX, supply the path to the home directory of the instance
owner of DB2, for example ″/home″. The full installation path will
be created by concatenating the home instance owner’s path and
the instance owner’s name, for example /home/db2inst1.
Port number
Specify the port number that you want DB2 to use. The typical value is
50000, but you should ensure that any port you assign is available.
DB2 Administrator user or DB2 instance owner
The data you enter depends on the platform, as follows:
Windows
On Windows, supply the user ID that you want to set up as the
″DB2 administration″ user, for example: db2admin. This user will
be created on the computer. Ensure that a user with this name
does not already exist.
UNIX On UNIX, supply the instance owner of DB2, for example
″db2inst1″. The full path will be created by concatenating the
home instance owner’s path and the instance owner’s name, for
example /home/db2inst1.
Installing in interactive mode
80 IBM Tivoli License Manager: Planning, Installation, and Configuration
Password
Enter the password to be used for the ″DB2 administration″ user
(Windows) or the password of the DB2 instance owner (UNIX).
The password must satisfy the password rules of the computer on which
you are installing DB2.
To change the DB2 administration password after installation see
“Changing passwords” on page 297.
Confirm password
Confirm the password.Click Next to continue.
12. If required, WebSphere Application Server prerequisite information: If you
asked the wizard to install the bundled prerequisite version of WebSphere
Application Server, it now asks you for the information it needs to install it.
If you did not ask the wizard to install WebSphere Application Server,
continue
at step 13 on page 82.
If you asked the wizard to install WebSphere Application Server, it displays the
following panel:
Enter the following information:
IBM WebSphere Application Server path
Enter the path where you want to install WebSphere Application Server.
IBM HTTP Server path
Enter the path where you want to install IBM HTTP Server.
User
For Windows platforms only, supply an existing user id with
Administrator rights. It will be used to set up WebSphere Application
Server and IBM HTTP Server as Windows services. If you want to use a
new user for this purpose you must create it first, and then supply it here.
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 81
Password
The password of that user id.
To change the Administrator password after installation see “Changing
passwords” on page 297.
Click Next.
13. Navigating the documentation:
Separate steps are now described, depending on how you have
selected to install the product:
v If you selected a Typical installation of the Runtime components, go to
“Typical installation of the runtime components.”
v If you selected a Typical installation of the Administration components, go
to “Typical installation of the administration components” on page 83.
v If you selected a Custom installation, go to “Custom installation” on page
84.
v If you selected an All components installation, or a Typical installation of
both Runtime and Administration components, go to “All components
installation” on page 89.
Typical installation of the runtime components
1. Base configuration parameters: If you selected a Typical installation of
Runtime components, the following panel is now displayed:
Enter the following data:
″tlmsrv″ password
Create and confirm the password to be used for the ″tlmsrv″ user that
is set up on the computer by the wizard. It is used to authenticate
communications between a server and its database.
The password has a maximum length of 20 characters and can contain
only the following characters:
A-Z, a-z, 0-9, +, -
Installing in interactive mode
82 IBM Tivoli License Manager: Planning, Installation, and Configuration
It must be valid for, and respect the rules of, the operating system of
the computer where you are running the wizard.
In a Typical installation of the runtime components, the value of this
password is also used for the runtime server communication password.
To change the tlmsrv password after installation see “Changing
passwords” on page 297.
Organization name
Supply the name of the organization to which the runtime server
belongs.
Administration server address
Enter the host name or IP address of the administration server for this
runtime server.
Port Enter the insecure port that the administration server is listening on.
The standard value is 80.
The following default values are applied when running a Typical installation
for the Runtime components:
Parameter Default value provided
Runtime server name <hostName>_runtime_server (where
hostName is the host name of the computer
where the install wizard is running.
Runtime communication password Value of ″tlmsrv″ user’s password.
Runtime server port 80
SSL enabled No
Click Next to continue.
Go to “Completing the installation” on page 91.
Typical installation of the administration components
1. Base configuration parameters: If you selected a Typical installation of
Administration components, the following panel is now displayed:
Enter the following data:
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 83
″tlmsrv″ password
Create and confirm the password to be used for the ″tlmsrv″ user that
is set up on the computer by the wizard. It is used to authenticate
communications between a server and its database.
The password has a maximum length of 20 characters and can contain
only the following characters:
A-Z, a-z, 0-9, +, -
It must be valid for, and respect the rules of, the operating system of
the computer where you are running the wizard.
To change the tlmsrv password after installation see “Changing
passwords” on page 297.
The following default values are applied when running a Typical installation
for the Administration components:
Parameter Default value provided
Administration server port 80
SSL enabled No
Click Next to continue.
Go to “Completing the installation” on page 91.
Custom installation
1. Base configuration parameters: The base configuration parameters panel is
displayed. The data input fields that you see on this panel vary according to
the components you have chosen to install.
Thebase
config
uratio
npara
mete
rsva
ryacc
ording
toth
eco
mbinatio
nof co
mponents
you
selecte
don
the
custo
mco
mponent se
lection
panel.
Match
the
param
eters
displaye
don
this
panel with
the
param
eter desc
riptio
ns
detaile
dbelow, and
enter th
ere
quired
data.
Table 8 on page 85 shows, for each type of installation and combination of
components selected, the fields that appear on the base configuration
Installing in interactive mode
84 IBM Tivoli License Manager: Planning, Installation, and Configuration
parameters panel:
Table 8. Base configuration parameter panels
Administration Runtime
Server Database Server Database
″tlmsrv″ password x x x x
Use this value for all other
passwords
x x x x
Organization name x
Runtime server name x
Enable Secure Sockets Layer
(SSL) protocol
x
SSL port x
Administration server address x
Port x
The data to enter in these fields is as follows:
″tlmsrv″ password
Create and confirm the password to be used for the ″tlmsrv″ user that
is set up on the computer by the wizard. It is used to authenticate
communications between a server and its database.
The password has a maximum length of 20 characters and can contain
only the following characters:
A-Z, a-z, 0-9, +, -
It must be valid for, and respect the rules of, the operating system of
the computer where you are running the wizard.
Attention: If you install a server and its database on separate
computers, they must both have the same ″tlmsrv″ password. If you do
not set up the same password, the server is not able to communicate to
its database. However, the administration server and database can have
a different ″tlmsrv″ password than the runtime servers and their
databases, and each runtime server and its database can have a
different ″tlmsrv″ password than the other runtime servers and their
databases.
If you install the administration and runtime server components on the
same computer, this password is valid for both databases. This is true
whether you install the components in a single installation or whether
you install one first and then run the wizard again to install the other.
If a component has already been installed on the computer, and the
″tlmsrv″ user has already been created, the panel that is displayed has
a single text box asking you to confirm the password that was specified
during the first installation.
To change the tlmsrv password after installation see “Changing
passwords” on page 297.
Use this value for all other passwords
This checkbox is displayed whenever the choices you have made
require you to provide more passwords than just the ″tlmsrv″
password.
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 85
If you leave this checkbox selected, the value of the ″tlmsrv″ password
is used also for the runtime communications password.
If you clear this checkbox, after you have clicked Next a panel may be
displayed, enabling you to enter a different value for the runtime
communications password (see step 2 on page 87).
Organization name
This is required if you are installing a runtime server, either on its own
or in conjunction with other components.
Identify the organization for which the runtime server is being
installed.
If the administration server has already been installed and organization
records have been created using the administration server Web
interface, you must be sure that the name you specify exactly matches
the organization name registered on the interface. Otherwise, you must
create an organization with this name when the administration server
Web interface is available.
Runtime server name
This is required if you are installing a runtime server, either on its own
or in conjunction with other components.
Specify a name for the runtime server that has not already been
assigned to a runtime server for the same organization.
Note: The organization name and runtime server name are used to
authenticate communication between the runtime server and the
administration server. You must be careful to enter them
correctly, both here and when you later register the runtime
server on the administration server Web interface. If there is any
discrepancy between the values entered when installing and
registering the server, the runtime server cannot be plugged in to
the administration server.
Enable Secure Sockets Layer (SSL) protocol
This is required if you are installing a runtime server, either on its own
or in combination with other components.
Select this if you want to use SSL for communications from the runtime
server to the administration server. See “Configure SSL” on page 98 for
details of which communications are enabled.
If you select this, and you are installing a runtime server, either on its
own or with other components, an extra field is displayed on the panel,
as follows:
SSL port
Enter the number of the port on the administration server uses
for SSL communications.
Administration server address
This is required if you are installing a runtime server, either on its own
or with its database.
Enter the address of the administration server, either as an Internet
address or as a TCP/IP address.
Installing in interactive mode
86 IBM Tivoli License Manager: Planning, Installation, and Configuration
Port This is only required if you are installing a runtime server, either on its
own or with its database.
Enter the number of the port on the administration server that it uses
for non-SSL communications.
Click Next.
2. If required: Runtime communication password:
If you did not clear the option to use the ″tlmsrv″ password for all password values, or
are not installing a runtime server,
continue at step 3.If you cleared the option to
use the ″tlmsrv″ password for all password values, and you are installing a runtime
server, the following panel is displayed:
This panel is displayed only if you have cleared the option to use the ″tlmsrv″
password for all password values.
It enables you to enter and confirm the Runtime communication password
used between the administration server and this runtime server to authenticate
communications.
The password has a maximum length of 20 characters and can contain only the
following characters:
A-Z, a-z, 0-9, +, -
To change the runtime server communication password after installation see
“Changing passwords” on page 297.Click Next.
3. Administration database connection:
If you are not installing an administration server without its database,
go to 4 on
page 88.
If you are installing an administration server without its database, the following
panel is displayed:
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 87
Note: This panel is very similar in appearance to the Runtime database
connection panel (see next panel). If you are installing both servers
without databases, both panels appear, one after the other.
Specify information to enable the administration server to locate the
administration server database. Where appropriate, defaults are displayed, but
you must ensure that the values that you supply are valid. The fields are as
follows:
Database instance owner
This field is required on UNIX platforms only. Identify the database
instance owner on the computer on which you are installing the
administration server (not the computer where the administration server
database is installed. On other platforms, this field is not required.
Database address (host name or IP)
Identify the host computer of the administration server database by
entering the host name or the IP address.
Database port number
Specify the port being used by the instance of DB2 that is hosting the
administration server database, on the computer where this database is
installed. The usual value is 50000. Any default shown will be the port
used by the first instance of DB2 on this computer. In all cases you should
obtain the value to be entered from the computer where the administration
server database is installed.
Click Next.
4. Runtime database connection:
If you are not installing a runtime server without its database,
go to
“Completing the installation” on page 91
If you are installing a runtime server without its database, the following panel is
displayed:
Installing in interactive mode
88 IBM Tivoli License Manager: Planning, Installation, and Configuration
Note: This panel is very similar in appearance to the Administration database
connection panel (see previous panel). If you are installing both servers
without databases, both panels appear, one after the other.Specify information to enable the runtime server to locate the runtime server
database. Where appropriate, defaults are displayed, but you must ensure that
the values that you supply are valid. The fields are as follows:
Database instance owner
This field is required on UNIX platforms only. Identify the database
instance owner on the computer on which you are installing the runtime
server (not the computer where the runtime server database is installed. On
other platforms, this field is not required.
Database address (host name or IP)
Identify the host computer of the runtime server database by entering the
host name or the IP address.
Database port number
Specify the port being used by the instance of DB2 that is hosting the
runtime server database, on the computer where this database is installed.
The usual value is 50000. Any default shown will be the port used by the
first instance of DB2 on this computer. In all cases you should obtain the
value to be entered from the computer where the runtime server database
is installed.
Click Next.
Go to “Completing the installation” on page 91.
All components installation
1. Base configuration parameters: If you selected an All components installation,
the following panel is now displayed:
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 89
Enter the following data:
″tlmsrv″ password
Create and confirm the password to be used for the ″tlmsrv″ user that
is set up on the computer by the wizard. It is used to authenticate
communications between a server and its database.
The password has a maximum length of 20 characters and can contain
only the following characters:
A-Z, a-z, 0-9, +, -
It must be valid for, and respect the rules of, the operating system of
the computer where you are running the wizard.
In an All components installation, the value of this password is also
used for the runtime server communication password.
To change the tlmsrv password after installation see “Changing
passwords” on page 297.
Organization name
Supply the name of the organization for which the All components
installation is being run.
Note: If you are performing an All components installation on a Linux390
server, the panel will also contain the following three fields, which are
needed for the deployment of the agent:
Processor type
Specify if the Linux390 image is running on CP or IFL processors.
Select one of the following:
CP
Supply if the Linux390 image is running on CP processors
IFL
Supply if the Linux390 image is running on IFL processors
Installing in interactive mode
90 IBM Tivoli License Manager: Planning, Installation, and Configuration
Active processors
Specify the total number of processors (CP or IFL, as appropriate,
not both) in the CEC.
shared_pool_capacity
If the Linux390 image is configured to share processors, specify the
total number of shared processors (CP or IFL, as appropriate, not
both) in the CEC. Enter zero if no shared processors are used by this
image.
The following default values are applied when running an All components
installation:
Parameter Default value provided
Runtime server name <hostName>_runtime_server (where
hostName is the host name of the computer
where the install wizard is running
Runtime communication password Value of ″tlmsrv″ user’s password
SSL enabled No
Administration server port 80
Click Next to continue.
Go to “Completing the installation.”
Completing the installation
When you have completed the input of the Tivoli License Manager parameters, the
wizard commences the final phase, which is to install the main components and
the prerequisites, as follows:
1. Confirm selections: A panel is displayed confirming the selections you have
made and the sizing of the installation. Click Next to start the installation. Attention: If you click Next, the installation process will start, and this
process cannot be cancelled. If you decide, after clicking Next, that you do not
want to install the product as indicated on the summary screen, you must
continue the installation until it has finished, and then uninstall the product.
2. Overwrite Java Virtual Machine: If you already have a version of Java Virtual
Machine installed at the target location a message is displayed asking if you
want to overwrite it. If you do not want to overwrite the existing Java Virtual
Machine you should confirm that it is compatible with Tivoli License Manager.
3. Install Tivoli License Manager components: The wizard installs the Tivoli
License Manager components you have selected to install. This may take some
minutes.
4. DB2 prerequisite install path:
If you have not asked the wizard to install the bundled DB2 prerequisite,
go to 6
on page 92
If you have asked the wizard to install the bundled DB2 prerequisite, it displays the
following panel:
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 91
This panel enables you to launch the silent install wizard for DB2. You should
perform the following steps:
a. Locate the IBM DB2 UDB, Enterprise Server Edition, version 8.1.x
installation CD (supplied with the product) and insert it in the CD drive of
your computer. Alternatively, locate the CD image on hard disk.
Note: On Windows computers, if the autorun on the CD starts you should
exit from it at the earliest opportunity and return to the wizard.
b. Identify the setup file for DB2. Check the DB2 documentation to determine
the name of the file.
Click Next.
Attention: If you click Cancel at this point, the wizard will finish without
installing DB2. In this event, the Tivoli License Manager component or
components you have installed will not be usable. You should uninstall the
product using the uninstall wizard; see Chapter 7, “Uninstall Tivoli License
Manager,” on page 203 for details. When you have decided what to do about
DB2 you can then repeat the installation.
5. DB2 prerequisite installation: The wizard now commences a silent installation
of DB2 using the parameters already supplied.
6. WebSphere Application Server prerequisite install path:
If you have not asked the wizard to install the bundled WebSphere Application Server
prerequisite,
go to 8 on page 93.
If you have asked the wizard to install the bundled WebSphere Application Server
prerequisite, it displays a panel similar to that used for DB2. This panel enables
you to launch the silent install wizard for WebSphere Application Server. You
should perform the following steps:
a. Locate the IBM WebSphere Application Server, version 5.1 installation CD
(supplied with the product) and insert it in the CD drive of your computer.
Alternatively, locate the CD image on hard disk.
Note: On Windows computers, if the autorun on the CD starts you should
exit from it at the earliest opportunity and return to the wizard.
Installing in interactive mode
92 IBM Tivoli License Manager: Planning, Installation, and Configuration
b. Identify the setup file for WebSphere Application Server. Check the
WebSphere Application Server documentation to determine the name of the
file.
Click Next.
Attention: If you click Cancel at this point, the wizard will finish without
installing WebSphere Application Server. In this event, the Tivoli License
Manager component or components you have installed will not be usable. You
should uninstall the product using the uninstall wizard; see Chapter 7,
“Uninstall Tivoli License Manager,” on page 203 for details. When you have
decided what to do about WebSphere Application Server you can then repeat
the installation.
7. WebSphere Application Server prerequisite installation: The wizard now
commences a silent installation of WebSphere Application Server using the
parameters already supplied.
8. Final steps: The wizard then performs one or more of the following installation
and configuration activities, depending on the install options you have chosen:
v If you have chosen to install the administration server database it creates and
populates that database and links it to the administration server.
v If you have chosen to install the runtime server database it creates and
populates that database and links it to the runtime server.
v It configures WebSphere Application Server to recognize the Tivoli License
Manager server or servers.
v If you have chosen to install the administration server it starts the
administration server.
v In an ″All components″ installation, the runtime server is registered with the
administration server, and the initial organization and division are created.
v If you have chosen to install the administration server, it opens a window in
your default Web browser to enable you to work with the server.
v If you have chosen to install the runtime server it starts the runtime server.
v If you have chosen to install only the runtime server, it opens a window in
your default Web browser to enable you to work with the server.
v A backup is taken of the configuration files of each server it has installed, so
that if you change any of these files, and then want to revert, you can do so
(see “Backup and restore of configuration files” on page 246).
When these activities have been completed, the final panel is displayed. Click
Finish to exit the wizard.
See “What to do if the wizard fails” on page 94 for information about what to
do if there are problems.
9. Optional: Log in to the server: If you have installed one or more servers, the
wizard will have opened a browser window for that server. Log in to the
server. If the login is successful, the product has almost certainly been correctly
installed.
However, depending on the choices you have made, you may encounter some
apparent problems:
v If you have installed a server without its database you will see an error
message telling you that the database could not be contacted.
v If you have installed a runtime server but have not yet configured the
administration server database to recognize it, the runtime server will not be
able to plug in to the administration server
Installing in interactive mode
Chapter 2. Install Tivoli License Manager main components 93
v If you have specified that SSL is to be used between components, any
settings you have made during the installation may mean that the
components cannot communicate with each other because the SSL
configuration is not complete. If the components are working themselves but
do not appear to be communicating, check that the SSL configuration is
complete (see “Configure SSL” on page 98).
v If you have installed a server using an existing version of WebSphere
Application Server, and Java 2 Security has already been enabled on that
version, the browser will give an error when it connects to the server. You
should follow the steps described in “Optionally configure Java 2 Security for
a server” on page 135, omitting the WebSphere Application Server step, as
indicated in the note attached to that procedure.
If the wizard has finished successfully, but you think a problem has occurred, refer
to IBM Tivoli License Manager: Problem Determination. This contains a chapter on
diagnosing problems during the installation of the servers and databases.
What to do if the wizard fails
If the wizard encountered any errors it stores the details and at the end of the
install activities displays them on the final panel. Some activities may not be
performed because activities on which they depend have failed. You should note
the errors and then click on the Finish button to exit from the wizard.
Problem determination
If a problem occurs, refer to IBM Tivoli License Manager: Problem Determination. This
contains a chapter on diagnosing problems during the installation of the servers
and databases.
Installing in interactive mode
94 IBM Tivoli License Manager: Planning, Installation, and Configuration
Chapter 3. Configure Tivoli License Manager
Apart from installing the servers and databases, a number of other setup tasks
must be performed before you can start using the product. These tasks must be
performed in the order they are given here, as dependencies are created:
v “Configure the administration server”
v “Perform the organization-related initial tasks” on page 96
v “Configure the runtime servers” on page 97
v “Configure SSL” on page 98
v “Configure the mail notification settings for a server” on page 117
v “Customize the Web server” on page 118
v “Define the authentication method” on page 121
v “Configuring proxy servers” on page 131
v “Automatic computer label assignment” on page 132
v “Import an up-to-date version of the IBM Catalog” on page 134
v “Other configuration procedures” on page 134
v “Tuning your environment” on page 136
Configure the administration server
Perform the following tasks on the administration server using the Web interface,
preferably before the runtime servers have been installed.
Note: You can access the Web interfaces from any computer that can connect to
the Web administration and Web runtime servers using one of the
prerequisited browsers. See “Web user interface prerequisites” on page 41
for details of which browsers.
The browser you use must be enabled for JavaScript™ and any programs
that prevent additional windows from opening automatically must be
disabled.
The address of the page is http://<server_name>:<port>/slmadmin/login.
See the IBM Tivoli License Manager: Administration for full instructions on
using the Web interfaces.
If the URL of the administration server clashes with a URL used by another
application, you can change or remap URLs using the facilities in
WebSphere Application Server or the Web server.
1. Configure the Web interface and administration server settings: Open the
system.properties file and examine each of the parameters for the Web
interface and administration server in turn to see whether the default settings
are appropriate for your Tivoli License Manager environment (the file is
divided into labelled sections for your convenience). The system.properties file
is documented in “The system.properties file” on page 235. If you decide to
change any of the settings, and the server is already running (it may have been
started by the installation), open the administration server command line and
run the srvstop and then srvstart commands, to let the new settings take effect.
The file can be found in:
© Copyright IBM Corp. 2002, 2004 95
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\conf
2. Log on as tlmroot: Log on to the administration server as user tlmroot. The
default password is system, but you should change it as soon as possible to a
password of your own choosing.
3. If necessary, create the default organization: Either select the default initial
organization already created for you or create the initial organization:
v If you performed any of the following installations, a default organization is
created for you, and you should select it:
– Typical or Custom installation of both administration and runtime servers
– Typical or Custom installation of a runtime server on a computer with the
administration server already installed
– All components installation
In these cases the organization will have been created using default
parameters (for example, the Country field is blank), so you should check
whether these parameters need to be changed to suit your environment.
Further, in the case of an All components installation, a default division is
also created using default parameters, so you should check whether these
parameters need to be changed to suit your environment.
v If you performed any other type of installations you are immediately asked
to create the initial organization. This must be supplied, even if you only
intend to work in a single-organization environment.4. Optionally create other organizations: If you are intending to work in a
multi-organization environment, create the other organizations that you require.
5. Create administrator accounts: Create accounts for administrators to manage
their Tivoli License Manager environment, assigning the appropriate roles.
6. Assign accounts to organizations: Assign accounts to the organizations you
have created.
7. Optionally enable SSL: If you want to use SSL for communications between
the administration server and at least one of the runtime servers you should
now enable SSL on the administration server. Full details of how to set up for
using SSL are given in “Configure SSL” on page 98.
You now need to perform a series of organization-related initial tasks. You are
recommended at this point to log off and log on again as Administrator to each of
your organizations in turn.
Perform the organization-related initial tasks
Perform the following tasks on the administration server for each organization
using the Web interface, preferably before the runtime servers have been installed.
1. Log on as an administrator: For each organization, log on to the administration
server, using the Tivoli License Manager Administrator account and password
for the organization that you set up in step 5 of the previous section.
2. Register runtime servers: If any runtime servers have not been registered
during the installation, register the runtime servers with the administration
server, using the GUI.
3. Create divisions: Create divisions, using the GUI.
Administration server
96 IBM Tivoli License Manager: Planning, Installation, and Configuration
4. Schedule inventory scans: Schedule inventory scans for each division you have
created. Allow sufficient time before the scans are due to start for you to
complete the setup tasks described here, and for a reasonable number of nodes
to have registered.
5. Set up and distribute license entitlements Set up license entitlements and
distribute these to the runtime servers.
Runtime servers and their databases can be installed before implementing these
steps, while you are implementing these steps, or after these steps are complete.
However, a runtime server will not be able to plug in until it has been registered.
Once a runtime server has been installed, it must be configured, as described in
the next section.
Configure the runtime servers
The following tasks should be performed for each runtime server:
1. Configure the runtime server and agent settings: Open the system.properties
file and examine each of the parameters for the runtime server and agent in
turn to see whether the default settings are appropriate for your Tivoli License
Manager environment (the file is divided into labelled sections for your
convenience). The system.properties file is documented in “The
system.properties file” on page 235. If you decide to change any of the settings,
and the server is already running (it may have been started by the installation),
open the runtime server command line and run the srvstop and then srvstart
commands, to let the new settings take effect.
If you are using proxies for communications between runtime servers and the
administration server or between runtime servers and agents, you must define
the proxies in the runtime server configuration files. This is done in the
communication.properties file. See “Configuring proxy servers” on page 131.
The system.properties and communication.properties files can be found in:
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\conf
2. Optionally configure SSL: If you want to use SSL for communications between
the administration server and this runtime server you should now configure
the runtime server for SSL. Full details of how to set up for using SSL are given
in “Configure SSL” on page 98.
3. Start the runtime server: The runtime server may have been started by the
install wizard. If it has not, start the runtime servers. For each server, wait for
the runtime plug-in period as defined in the runtime server configuration file
(the default is shown in the documentation of the configuration file, see
“Runtime server settings” on page 239).
4. Check the runtime server has plugged in: Check that the runtime server has
correctly plugged in (an appropriate message is displayed on the
administration server GUI; select Manage Components � Servers). If a server
has not plugged in, refer to the log files on the administration server, where the
reason for failure is reported. The event#n.log file is located in the Tivoli
Common Directory (see IBM Tivoli License Manager: Problem Determination for
full details of logs and the Tivoli Common Directory).
Note: The default URL of the runtime server is
<runtimeServerName>/slmruntime/. If this clashes with a URL used by
another application, you can change or remap URLs using the facilities
in WebSphere Application Server or the Web server.
Organization-related tasks
Chapter 3. Configure Tivoli License Manager 97
5. Log on as tlmroot: Log on to each runtime server as user tlmroot. The default
password is system, but you should change it as soon as possible to a
password of your own choosing.
6. Create accounts: Create accounts for administrators who are able to request
reports and receive notifications about events that occur on the runtime servers.
Configure SSL
This section is divided into two main sub-sections:
v “Configuration procedures” describes the procedures you need to follow for
each type of communication for which you wish to enable SSL. You should
already have read “SSL” on page 16 to understand the planning considerations
for implementing SSL.
v The procedures for the different communication types require you to undertake
a series of activities. In many cases these activities are repeated in different
circumstances on different computers playing different roles. To avoid repeating
the activity descriptions each time they are needed in the procedures, the
activities are all grouped and documented together in “Configuration activities”
on page 107. Each procedure step refers to an activity, with the appropriate link.
If you have enabled secure communications but you want to switch to non secure
communications, see “Disabling secure communications” on page 115.
Configuration procedures
The configuration procedures are as follows:
v “Configuring SSL for communications from the administration server to the
runtime server” on page 99
v “Configuring SSL for communications from the runtime server to the
administration server” on page 101
v “Configuring SSL for communications from Web browsers” on page 102
v “Configuring SSL for communications from the agent to the runtime server” on
page 104
Figure 8 on page 99 illustrates the communication channels which you can
configure for SSL.
Runtime servers
98 IBM Tivoli License Manager: Planning, Installation, and Configuration
Configuring SSL for communications from the administration
server to the runtime server
To implement SSL for communications from the administration server to the
runtime server you need to configure both the administration server and all of the
runtime servers.
The details are as follows:
Runtimeserver
Administrationserver
Agents
Webinterface
Webinterface
Figure 8. SSL channel configuration possibilities
Runtimeserver
Administrationserver
Agents
Webinterface
Webinterface
- Enable SSL on Web serverDefine secure/port aliases on WASChange default SSL passwordObtain Server certificateInstall in keystore (key.kdb)
----
- Register runtime serversChange default SSL passwordInstall runtime server certificate inJava keystore (key.jks)(if self-signed or own CA)
-- ’s
Figure 9. Configuring SSL from administration server to runtime server
SSL: procedures
Chapter 3. Configure Tivoli License Manager 99
Runtime servers
Take these steps on each of the runtime servers with which the
administration server needs to communicate in SSL:
1. Enable SSL on the Web server and allocate the secure (SSL) port to be
used. See “Enabling SSL for the Web server” on page 107.
You can optionally disable encryption. See “Disabling encryption” on
page 109.
2. Ensure that WebSphere Application Server has secure-port aliases. See
“Set SSL port aliases” on page 110.
3. Change the default SSL password that allows you and the server’s Web
server to access its keystore. You can have different passwords for each
runtime server, but you may find it more convenient to have the same
password for all. See “Change the SSL password” on page 111.
4. Obtain or create a server certificate with a private key (remember that
this same certificate will be used if you also enable agent
communications in SSL).
The procedure to use depends on the type of server certificate you
want to use:
v Obtain a server certificate from a well-known trusted Certificate
Authority: see “Request a server certificate” on page 112.
v Issue a self-signed server certificate: see “Create a server certificate”
on page 113.
v Issue a server certificate as a Certificate Authority: see “Create a
server certificate as a Certificate Authority” on page 114.5. Install the server certificate in the keystore (key.kdb), replacing the test
certificate supplied with Tivoli License Manager. You should not use a
server certificate obtained for any other purpose or any other server.
If you have decided to use the same certificate for all runtime servers
(and have the same keystore password), you can install the certificate
on one server and copy the keystore and the stashed password file to
all other runtime servers.
Administration server
Take these steps on the administration server:
1. Register each of the runtime servers using the administration server
GUI, indicating for each the port you assigned for SSL at the runtime
server. See “Register the runtime server to be contacted using SSL
communication” on page 114.
2. Change the SSL password that allows you and the administration
server to access its keystore. See “Change the SSL password” on page
111.
3. This step depends on the type of server certificate you have chosen for
the runtime servers:
v Obtained a server certificate from a well-known trusted Certificate
Authority: take no action.
v Issued a self-signed server certificate: install it also on the
administration server, in the Java keystore (key.jks). See “Add a
certificate to the database” on page 114.
v Issued a server certificate as a Certificate Authority: install your
root certificate in the administration server’s Java keystore (key.jks).
See “Add a certificate to the database” on page 114.
SSL: procedures
100 IBM Tivoli License Manager: Planning, Installation, and Configuration
Configuring SSL for communications from the runtime server to
the administration server
To implement SSL for communications from the runtime server to the
administration server you need to configure both the administration server and all
of the runtime servers for which SSL is to be enabled.
The details are as follows:
Administration server
Perform these steps on the administration server:
1. Enable SSL on the administration server’s Web server and allocate the
secure (SSL) port to be used. See “Enabling SSL for the Web server” on
page 107.
You can optionally disable encryption. See “Disabling encryption” on
page 109.
2. Ensure that WebSphere Application Server on the administration server
has secure-port aliases. See “Set SSL port aliases” on page 110.
3. If you have not already done so, change the SSL password that allows
you and the administration server’s Web server to access its keystore.
See “Change the SSL password” on page 111.
4. Obtain or create a server certificate with a private key.
The procedure to use depends on the type of server certificate you
want to use:
v Obtain a server certificate from a well-known trusted Certificate
Authority: see “Request a server certificate” on page 112.
v Issue a self-signed server certificate: see “Create a server certificate”
on page 113.
v Issue a server certificate as a Certificate Authority: see “Create a
server certificate as a Certificate Authority” on page 114.
Runtimeserver
Administrationserver
Agents
Webinterface
Webinterface
- Enable SSL on Web serverDefine secure/port aliases on WASChange default SSL passwordObtain Server certificateInstall in keystore (key.kdb)
----
- Enable SSL when installingruntime serversChange default SSL passwordInstall admin server certificate inJava keystore (key.jks)(if self-signed or own CA)
-- ’s
Figure 10. Configuring SSL from runtime server to administration server
SSL: procedures
Chapter 3. Configure Tivoli License Manager 101
5. Install the server certificate in the keystore (key.kdb), replacing the test
certificate supplied with Tivoli License Manager. You should not use a
server certificate obtained for any other purpose or any other server.
Runtime servers
Take these steps on each of the runtime servers with which the
administration server needs to communicate in SSL:
1. Enable SSL when installing the runtime server, or reconfigure the
runtime server after installation so that it is enabled for SSL and has
details of the administration server’s secure port. See “Configure the
runtime server to send secure communications” on page 110.
2. If you have not already done so, change the SSL password that allows
you and the runtime server to access its keystore. See “Change the SSL
password” on page 111.
3. This step depends on the type of server certificate you have chosen for
the administration server:
v Obtained a server certificate from a well-known trusted Certificate
Authority: take no action.
v Issued a self-signed server certificate: install it also on the runtime
servers, in the Java keystore (key.jks). See “Add a certificate to the
database” on page 114.
v Issued a server certificate as a Certificate Authority: install your
root certificate in the runtime servers’ Java keystore (key.jks). See
“Add a certificate to the database” on page 114.4. Start the runtime server and check that it plugs in correctly (the plug-in
is one of the services that uses SSL).
Configuring SSL for communications from Web browsers
If you want to enable SSL when using your Web browser to work with the
administration server’s or runtime server’s Web GUI, you need to plan for the
following steps at the server and at the browser.
Runtimeserver
Administrationserver
Agents
Webinterface
Webinterface
- When you connect tothe servers use HTTPS
adminserver certificate(if self-signed or own CA)
- Optionally import ’s
For each server- Enable SSL on Web server
Define secure/port aliases on WASChange default SSL passwordObtain Server certificateInstall in keystore (key.kdb)
:
----
Figure 11. Configuring SSL from Web browser to servers
SSL: procedures
102 IBM Tivoli License Manager: Planning, Installation, and Configuration
The details are as follows:
Administration or runtime server
Take these steps on each of the servers with which the Web browser needs
to communicate in SSL (you will have probably already taken these steps
in order to enable another SSL communication, but for completeness they
are included here):
1. Enable SSL on the server’s Web server and allocate the secure (SSL)
port to be used. See “Enabling SSL for the Web server” on page 107.
2. Ensure that WebSphere Application Server on the server has secure-port
aliases. See “Set SSL port aliases” on page 110.
3. If you have not already done so, change the SSL password that allows
you and the administration server’s Web server to access its keystore.
See “Change the SSL password” on page 111.
4. If you have not already done so, obtain or create a server certificate
with a private key.
The procedure to use depends on the type of server certificate you
want to use:
v Obtain a server certificate from a well-known trusted Certificate
Authority: see “Request a server certificate” on page 112.
v Issue a self-signed server certificate: see “Create a server certificate”
on page 113.
v Issue a server certificate as a Certificate Authority: see “Create a
server certificate as a Certificate Authority” on page 114.5. Install the server certificate in the keystore (key.kdb), replacing the test
certificate supplied with Tivoli License Manager. You should not use a
server certificate obtained for any other purpose or any other server.
Web browser
Take these steps on the Web browser:
1. When you connect to the server to use the GUI, always use the HTTPS
protocol. See “Using the HTTPS protocol between browsers and
servers” on page 115.
2. If you are using a self-signed certificate, or a server certificate issued by
you as a Certificate Authority, you can choose to use the certificate
import options in the browser or browsers that you use to access the
Web GUI. These let you import the self-signed certificate. Alternatively,
you will be asked to trust the certificate each time you access the GUI.
Configuring SSL only for browser communications involving only passwords:
A configuration option exists for you to enable SSL only for browser
communications involving passwords. To do this, take the following steps:
1. Enable your Web browser, and the server or servers where you want to
implement this feature, to use both SSL and non-SSL communications (see
“Configuring SSL for communications from Web browsers” on page 102 for
details).
2. Edit the system.properties file for each of the servers where you want to
enable this facility, as follows:
v Change the value of secureData to true.
v Change the value of securePort to the port number that the server will use
to listen for the https communication from the browser (the default is 443).3. Save the system.properties file and restart the server.
SSL: procedures
Chapter 3. Configure Tivoli License Manager 103
4. Connect to the Web UI of the server or servers using the HTTP protocol. When
you login, create or change user passwords using Manage Access � Accounts,
or create or change runtime server passwords using Manage Components �
Servers, the server tells the browser to use the HTTPS protocol and also tells it
what port is in use at the server for HTTPS communications. When the
communication is completed, the browser reverts to using HTTP.
Configuring SSL for communications from the agent to the
runtime server
To implement SSL for communications from the agent to the runtime server you
need to configure all of the affected runtime servers and agents.
The details are as follows:
Administration servers
Enable or disable SSL for the organization and divisions. Each division
inherits the settings of its organization, unless specifically configured
differently. You can have any of the following combinations:
v SSL enabled for the organization and inherited in all the divisions
v SSL enabled for the organization but disabled for one or more divisions
v SSL disabled for the organization but enabled for one or more divisions
Note: Remember that, to avoid problems when using alternative servers,
the setting of the requestScope parameter in the system.properties
file must be in line with the choice you make about enabling SSL for
organizations and divisions.
To change the settings take these steps:
1. Access the administration server GUI
2. Choose Manage Organizations
3. Check if the setting for the appropriate organization is as you want it.
If not, select the organization and click Change.
Runtimeserver
Administrationserver
Agents
Webinterface
Webinterface
- Enable SSL on Web serverDefine secure/port aliases on WASChange default SSL passwordObtain Server certificateInstall in keystore (key.kdb)
----- Enable Web agent deployment to use
runtime’s server certificate (if self-signedor own CA)
- Enable other agent deployment methodsto use runtime’s server certificate(if self-signed or own CA)
- Configure agents to use or not use SSLwhen making initial plug-in
- Enable SSL for organizationsor divisions
- Optionally change SSL password at agent (after deployment)
Figure 12. Configuring SSL between agents and runtime servers
SSL: procedures
104 IBM Tivoli License Manager: Planning, Installation, and Configuration
4. Modify the organization settings to enable or disable SSL, as
appropriate.
5. Click Finish and then Close on the next screen.
6. If you want to implement SSL differently at different divisions,
continue as follows:
a. Choose Manage Resources � Divisions
b. Check if the setting for the appropriate division is as you want it. If
not, select the division and click Change.
c. Modify the division settings to inherit the value from the
organization, or to enable or disable SSL, as appropriate.
d. Click Finish and then Close on the next screen.
Runtime servers
Take these steps on each of the runtime servers with which an agent needs
to communicate in SSL. If you have planned to enable SSL for
communications from the administration server to this runtime server you
will have already completed most of the activities, and you can read on at
the description of the configuration required at the agents. If not, these are
the steps:
1. Enable SSL on the Web server and allocate the secure (SSL) port to be
used. See “Enabling SSL for the Web server” on page 107.
You can optionally disable encryption. See “Disabling encryption” on
page 109.
2. Ensure that WebSphere Application Server has secure-port aliases. See
“Set SSL port aliases” on page 110.
3. Change the default SSL password that allows you and the server’s Web
server to access its keystore. You can have different passwords for each
runtime server, but you may find it more convenient to have the same
password for all. See “Change the SSL password” on page 111.
4. Obtain or create a server certificate with a private key.
The procedure to use depends on the type of server certificate you
want to use:
v Obtain a server certificate from a well-known trusted Certificate
Authority: see “Request a server certificate” on page 112.
v Issue a self-signed server certificate: see “Create a server certificate”
on page 113.
v Issue a server certificate as a Certificate Authority: see “Create a
server certificate as a Certificate Authority” on page 114.5. Install the server certificate in the keystore (key.kdb), replacing the test
certificate supplied with Tivoli License Manager. You should not use a
server certificate obtained for any other purpose or any other server.
6. Supply the agent with the correct certificate. This step depends on the
type of server certificate you have chosen for the runtime server:
v Obtained a server certificate from a well-known trusted Certificate
Authority: take no action.
v Issued a self-signed server certificate: Copy the server certificate,
creating a base-64 encoded ASCII file called cert.arm and replace the
default test certificate installed in the agent section of the runtime
server’s files.
v Issued a server certificate as a Certificate Authority: copy the root
certificate of your Certificate Authority, creating a base-64 encoded
SSL: procedures
Chapter 3. Configure Tivoli License Manager 105
ASCII file called cert.arm and replace the default test certificate
installed in the agent section of the runtime server’s files.
The default test certificate is found at
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\webdoc\agent\security
7. Ensure that the agent deployment methods use the correct certificate.
The details of this depend on the agent deployment procedures in use:
Web deployment
No further action needed.
Agent deployment using installagent
Run the manualDeploy script to make a fresh copy of the agent
deployment files (including the new cert.arm) for each install
platform. Full details are given in “Deploying the agent
manually (installagent command)” on page 145.
Agent deployment using Configuration Manager
The software package block needs to be converted, and the
embedded test certificate replaced by the self-signed certificate.
Full details given in “Deploying agents using Tivoli
Configuration Manager” on page 152.
UNIX agent deployment using an SSH/RSH network
Each time you use the wizard it requires you to locate the
certificate to be deployed at the agent, or use the embedded
test certificate. You should locate the self-signed certificate. Full
details are given in “Deploying agents to UNIX nodes using
SSH and RSH” on page 162.
Agent deployment using Windows logon script
Run the manualDeploy script to make a fresh copy of the agent
deployment files (including the new cert.arm) for each install
platform. Full details are given in “Deploy agents using
Windows logon scripts” on page 170.
OS/400 agent deployment
Each time you use the wizard it requires you to locate the
certificate to be deployed at the agent, or use the embedded
test certificate. You should locate the self-signed certificate. Full
details are given in “Install agents on OS/400” on page 175.8. When deploying agents, configure the agent to use SSL at startup. The
implementation of this depends on the agent deployment method:
Web deployment
You can instruct users who are going to use Web deployment to
contact the runtime server using HTTPS rather than HTTP. If
the SSL port in use at the runtime server is not 443, you should
also instruct users to use this port in the URL.
HTTPS will then be used for all the communications involved
in installing the agent. However, when the agent plugs in for
the first time it will do so respecting the Agent SSL
communication parameter set for its division.
SSL: procedures
106 IBM Tivoli License Manager: Planning, Installation, and Configuration
Other deployment methods
Set the secureLevel or Startup mode parameter at agent
deployment to use or not use SSL. You should also supply the
SSL port to be used at the runtime server.
The deployment will then be carried out in SSL, up to and
including the agent plugin. At plugin, the agent downloads its
parameters, and continues communicating with the runtime
server according to the division’s SSL agent communication
setting.
Agents
The agent is installed on the target node with a key database that uses the
default SSL password, ″slmtest″. If you want to change this, use the
following procedure:
1. Use the IKEYMAN program supplied with WebSphere Application
Server, version 5.1, (or a similar application that manages .kdb files) to
open the key.kdb file at the agent (see “Agent files” on page 221 for the
location of the file on different agent platforms).
2. Change the password.
3. Stash the new password in a file called key.sth, overwriting the
existing file.
4. Close IKEYMAN.
5. If you want the agent to start using the new password immediately
you should stop and restart the agent
Configuration activities
The SSL configuration activities documented in this section are as follows:
v “Enabling SSL for the Web server”
v “Disabling encryption” on page 109
v “Set SSL port aliases” on page 110
v “Configure the runtime server to send secure communications” on page 110
v “Change the SSL password” on page 111
v “Request a server certificate” on page 112
v “Create a server certificate” on page 113
v “Create a server certificate as a Certificate Authority” on page 114
v “Add a certificate to the database” on page 114
v “Register the runtime server to be contacted using SSL communication” on page
114
v “Using the HTTPS protocol between browsers and servers” on page 115
To determine the circumstances in which to perform any of these activities, see
“Configuration procedures” on page 98.
Enabling SSL for the Web server
SSL must be enabled in the Web server of your Tivoli License Manager server. This
section describes how to enable SSL for the IBM HTTP Server, version 1.3.26.2. If
you are using a different Web server, follow the instructions in the corresponding
documentation to achieve the same objective.
Note: If you think that you might want at some future point to revert to insecure
communications, you might wish to take a backup of the configuration file,
or note the existing settings, before making any changes.
SSL: procedures
Chapter 3. Configure Tivoli License Manager 107
The procedure for the IBM HTTP Server is as follows:
1. Locate the HTTP configuration file in <HTTP_INSTALL_DIR>\conf\httpd.conf.
2. Open the file and check for the presence of the following items:
v A definition for the secure virtual host
v A ″Listen″ statement for the secure port
v A ″Listen″ statement for the insecure port (UNIX only)
v A ″LoadModule″ statement for the ibm_ssl_module
v An ″AddModule″ statement (UNIX only)
v A ″Keyfile″ statement for the server’s key database
v ″SSLV2Timeout″ and ″SSLV3Timeout″ statements
If they are not present they should be added. The parameters differ according
to the platform, and this is how they should be set:
Windows: SSL definition parameters in httpd.conf
...
LoadModule ibm_ssl_module modules\IBMModuleSSL128.dll
...
Listen <securePort>
...
<VirtualHost *:<securePort>>
SSLEnable
SSLClientAuth none
ErrorLog logs\ssl.error_log
CustomLog logs\ssl.access_log common
</VirtualHost>
...
Keyfile "<INSTALL_DIR>\<srvType>\SLM_<srvTypeUI>_Application.ear\slm_<srvType>.war\WEB-INF\keystore\key.kdb"
SSLV2Timeout 40
SSLV3Timeout 120
UNIX: SSL definition parameters in httpd.conf
...
LoadModule ibm_ssl_module libexec/mod_ibm_ssl_128.so
...
AddModule mod_ibm_ssl.c
...
Listen <securePort>
Listen <insecurePort>
...
<VirtualHost *:<securePort>>
SSLEnable
ErrorLog logs/ssl.error_log
CustomLog logs/ssl.access_log common
</VirtualHost>
...
Keyfile "<INSTALL_DIR>/<srvType>/SLM_<srvTypeUI>_Application.ear/slm_<srvType>.war/WEB-INF/keystore/key.kdb"
SSLV2Timeout 40
SSLV3Timeout 120
Where the variables are as follows:
<INSTALL_DIR>
The directory where Tivoli License Manager is installed.
<insecurePort>
The port that you are using for insecure communications. The port
must be available. The default is 80.
SSL: activities
108 IBM Tivoli License Manager: Planning, Installation, and Configuration
<securePort>
The port that you have decided is to be used for SSL communications.
The port must be available. The default is 443.
<srvType>
″admin″ or ″runtime, as appropriate.
<srvTypeUI>
″Admin″ or ″Runtime, as appropriate.For example, on Windows, the additions to the httpd.conf file for a server
where just the administration server is installed, might look as follows:
...
LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll
...
Listen 443
...
<VirtualHost *:443>
SSLEnable
SSLClientAuth none
ErrorLog logs\ssl.error_log
CustomLog logs\ssl.access_log common
</VirtualHost>
...
Keyfile "C:\Program Files\IBM\TLM\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\keystore\key.kdb"
SSLV2Timeout 40
SSLV3Timeout 120
3. Stop and restart the Web server for the changes to take effect.
Disabling encryption
If you want to use SSL but do not need encryption, you can disable it. This section
describes how to enable SSL for the IBM HTTP Server, version 1.3.26.2. If you are
using a different Web server, follow the instructions in the corresponding
documentation to achieve the same objective.
Disable encryption in the IBM HTTP Server as follows:
1. Locate the HTTP configuration file in <HTTP_INSTALL_DIR>\conf\httpd.conf.
2. Open the file and locate the virtual host definition for the secure port. It will
look something like the following:
<VirtualHost *:443>
SSLEnable
SSLClientAuth none
ErrorLog logs\ssl.error_log
CustomLog logs\ssl.access_log common
</VirtualHost>
3. Add one of the the following lines into the virtual host definition:
SSLCipherSpec 31
SSLCipherSpec 32
When you have finished, the virtual host definition should look something like
the following:
<VirtualHost *:443>
SSLEnable
SSLClientAuth none
SSLCipherSpec 31
ErrorLog logs\ssl.error_log
CustomLog logs\ssl.access_log common
</VirtualHost>
SSL: activities
Chapter 3. Configure Tivoli License Manager 109
4. Stop and restart the Web server for the changes to take effect.
Set SSL port aliases
To update the WebSphere Application Server list of host aliases, duplicate all the
virtual host entries, specifying the SSL port. Repeat the following steps on each
computer where a Tivoli License Manager server is installed:
1. Open the WebSphere Administrator’s Console.
2. In the portfolio select Environment � Virtual Hosts. and click Default_host on
the panel.
3. On the Default host panel click Host aliases.
4. Click New and define the following fields:
Host name Enter an asterisk: *
Port The port you have chosen to use for SSL
communications: normally 443.
This adds an alias for port 443 for type of alias.
5. Click Apply.
6. On the administration server computer only, you can optionally delete the
aliases that use the default port (80) or any other port used for nonsecure
communications. If you do this, only secure communications are available
between the runtime and administration servers.
Note: Do not delete the aliases used for nonsecure communications on runtime
servers, because runtime server to agent communication might not
always be secure.
7. When you have made all the changes you want to, click Save at the top of the
Default host panel, and then Save again.
8. Regenerate the plug-in. This can be done in one of two ways:
Regenerate the plug-in using the GUI
a. In the portfolio expand the Environment option.
b. Select Update Web Server Plugin.
c. On the main panel. click on the OK button.
Regenerate the plug-in using the command line
Issue the command genplugincfg from the <WEBSPHERE
INSTALL_DIR>\bin directory.9. Stop and restart the Web server, and the relevant Tivoli License Manager server.
Configure the runtime server to send secure communications
Secure communications use the secure protocol HTTPS instead of HTTP. When you
installed the runtime server you were given the choice to enable SSL for
communications with the administration server. The steps in this section are only
required if you did not enable SSL at installation, but want to enable it now.
For communications with the administration server, a runtime server uses the
values held in the communication.properties file (see “The
communication.properties file” on page 244). The values of the enableSSL and
SSLPort parameters determine whether SSL is to be used and if so, on which port.
The parameters are used to construct the URL as follows, depending on whether
SSL is being used or not:
SSL: activities
110 IBM Tivoli License Manager: Planning, Installation, and Configuration
SSL https://<server>:<SSLPort>/<URI>
No SSL
http:/<server>:<port>/<URI>
where <URI> is the parameter that defines the name of the service.
If SSL was not enabled at installation and you decide to enable it later, you must
edit the communication.properties file, and change the enableSSL parameter to
″true″ and set the sslPort parameter to the appropriate value. The
communication.properties file is stored in the following location on the runtime
server computer:
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\conf
Secure communications between the runtime and administration servers require a
password to access the key.jks keystores held on each runtime server. The SSL
password is created by the installation wizard when a server is installed. It has the
value ″slmtest″, but this value must be changed, because it is insecure (all users of
Tivoli License Manager are supplied with this password). Whether you enabled
SSL when you installed the server, or installed the server with SSL turned off and
decide to enable it later, you must change the password at the keystore using the
keystore utilities, and then reset the Tivoli License Manager SSL password using
the sslpasswd command from the appropriate server’s command line interface. For
instruction on sslpasswd see the chapter on the command line in IBM Tivoli License
Manager: Administration.
You can use the same command if you decide to change the password for security
reasons. The command only changes the value in the product’s password file; it
does not change the value of the password in the keystore, which must be changed
using the appropriate keystore utility.
Change the SSL password
This section gives instructions about changing the keystore password using the
IBM Key Management tool (IKEYMAN), which is included with the version of
IBM HTTP Server bundled with WebSphere Application Server, version 5.1. If you
are using a different Web server you will have a different tool or a different
version of the same tool; follow the instructions in the corresponding
documentation to achieve the same objective.
With IKEYMAN, you can change the password as follows, depending on whether
you are changing it in the key database (for example key.kdb) or the Java keystore
(key.jks):
Changing the password in the key database
1. On the appropriate server computer, start the IKEYMAN tool and open
the key database (for example key.kdb) which is located in the
following directory:
Administration server
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\keystore
SSL: activities
Chapter 3. Configure Tivoli License Manager 111
Runtime server
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\keystore
The initial password for this database is slmtest.
2. Use the IKEYMAN Change password function to change the password
to a value of your choice.
3. Use the IKEYMAN Stash password function to store the password in
the key.sth file.
Changing the password in the Java keystore
1. On the appropriate server computer, start the IKEYMAN tool and open
the Java keystore (key.jks), which is located in the following directory:
Administration server
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\keystore
Runtime server
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\keystore
The initial password for this database is slmtest.
2. Use the IKEYMAN Change password function to change the password
to a value of your choice.
3. Open the Tivoli License Manager command line for the server on
which you are running IKEYMAN.
4. Use the command sslpasswd to change the password on the Tivoli
License Manager server to the same value. For instruction on
sslpasswd see the chapter on the command line in IBM Tivoli License
Manager: Administration.
5. Use the sslpasswd command on the other computer to tell the Tivoli
License Manager server of the password change.
Request a server certificate
This section gives instructions about requesting a server certificate using the IBM
Key Management tool (IKEYMAN), which is included with the version of IBM
HTTP Server bundled with WebSphere Application Server, version 5.1. If you are
using a different Web server you will have a different tool or a different version of
the same tool; follow the instructions in the corresponding documentation to
achieve the same objective.
With IKEYMAN, you can request a certificate from a recognized certificate
authority, as follows:
1. On the appropriate server computer, start the IKEYMAN tool and open the key
database (key.kdb), which is located in the following directory:
Administration server
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\keystore
SSL: activities
112 IBM Tivoli License Manager: Planning, Installation, and Configuration
Runtime server
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\keystore
The initial password for this database is slmtest.
2. If you have not already changed the password to the keystore from the default
value, do so now – see “Change the SSL password” on page 111.
3. Look in the Signer Certificates section of the database, and if you find the
default Itlm test certificate, delete it, using the Delete function of IKEYMAN.
4. Use the IKEYMAN Create a certificate request function to create a certificate
request.
5. Send the certificate request to one of the well-known trusted Certificate
Authorities.
6. Exit from IKEYMAN.
7. When you receive the certificate from the Certificate Authority, go back into
IKEYMAN as described above, and use the IKEYMAN Receive function to
receive the certificate into the database.
8. Make a copy of the certificate with the name cert.arm for use on other servers.
Create a server certificate
This section gives instructions about creating a server certificate using the IBM Key
Management tool (IKEYMAN), which is included with the version of IBM HTTP
Server bundled with WebSphere Application Server, version 5.1. If you are using a
different Web server you will have a different tool or a different version of the
same tool; follow the instructions in the corresponding documentation to achieve
the same objective.
With IKEYMAN, you can create a new self-signed certificate, as follows:
1. On the appropriate server computer, start the IKEYMAN tool and open the key
database (key.kdb) , which is located in the following directory:
Administration server
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\keystore
Runtime server
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\keystore
The initial password for this database is slmtest.
2. If you have not already changed the password to the keystore from the default
value, do so now – see “Change the SSL password” on page 111.
3. Look in the Signer Certificates section of the database, and if you find the
default Itlm test certificate, delete it, using the Delete function of IKEYMAN.
4. Open the Personal Certificates section of the database and use the IKEYMAN
Create self-signed certificate function to create a new self-signed certificate.
5. Use the IKEYMAN Extract function to extract the new self-signed certificate
into a Base 64 encoded file called cert.arm.
SSL: activities
Chapter 3. Configure Tivoli License Manager 113
Create a server certificate as a Certificate Authority
The procedure for this will depend on the software you use to issue server
certificates and create your root certificate. Follow the documentation provided, but
your objective should be to finish with the following two files:
v A file containing the server certificate with its private key.
v A file containing the root certificate with its public key.
Add a certificate to the database
This section gives instructions about adding a server certificate or a root certificate
to the key database using the IBM Key Management tool (IKEYMAN), which is
included with the version of IBM HTTP Server bundled with WebSphere
Application Server, version 5.1. If you are using a different Web server you will
have a different tool or a different version of the same tool; follow the instructions
in the corresponding documentation to achieve the same objective.
With IKEYMAN, you can add a self-signed certificate, or a root certificate that you
created as a certificate authority, as follows:
1. On the appropriate server computer, start the IKEYMAN tool and open the
Java keystore (key.jks), which is located in the following directory:
Administration server
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\keystore
Runtime server
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\keystore
The initial password for this database is slmtest.
2. If you have not already changed the password to the keystore from the default
value, do so now – see “Change the SSL password” on page 111.
3. Look in the Signer Certificates section of the database, and if you find the
default Itlm test certificate, delete it, using the Delete function of IKEYMAN.
4. In the same Signer Certificates section of the database, use the IKEYMAN Add
function to add the certificate, browsing to the appropriate cert.arm file.
Register the runtime server to be contacted using SSL
communication
After you have installed a runtime server it must be registered with its
administration server. If you want the runtime server to be able to be contacted by
the administration server using SSL, either at first registration or subsequently, you
should do as follows:
1. Open the administration server GUI
2. Select the appropriate organization
3. Click on the portfolio options Manage components � Servers
4. Click on the Create button under the Available servers heading.
5. On the displayed screen, enable SSL and enter the port on the runtime server
that the administration server should use to compose the URL for secure
communications with the runtime server, as in the following example:
SSL: activities
114 IBM Tivoli License Manager: Planning, Installation, and Configuration
6. Enter and confirm the runtime communication password, and click Finish to
register the server.
Using the HTTPS protocol between browsers and servers
For secure communications, use the secure protocol HTTPS instead of HTTP.
For communications between Web browsers and the Tivoli License Manager
servers, this is done by using HTTPS when addressing the logon pages of the
server interfaces as follows:
Administration server
https://<server name>:<port>/slmadmin/login
Runtime server
https://<server name>:<port>/slmruntime/login
Disabling secure communications
If you have been using SSL secure communications and you want to switch to
nonsecure communications, do the following steps:
1. Use the HTTP protocol instead of the HTTPS protocol. See “Using the HTTP
protocol” on page 116.
2. Optionally, delete the SSL-enabled virtual host definition from the HTTP
configuration file, httpd.conf. See “Deleting the virtual host definition” on
page 116.
3. Ensure that the list of WebSphere Application Server host aliases on the
administration server computer includes aliases for the default ports. See
“Restoring default port aliases” on page 116.
SSL: activities
Chapter 3. Configure Tivoli License Manager 115
Using the HTTP protocol
For communications between Web browsers and the Tivoli License Manager
servers, to change to the HTTP protocol, use HTTP when addressing the logon
pages of the server interfaces as follows:
Administration server
http://<server name>/slmadmin/login
Runtime server
http://<server name>/slmruntime/login
For communications between the administration server and the runtime server,
stop the runtime server. Edit the communication.properties file on the runtime
server computer, and change the enableSSL parameter to use ″false″, and ensure
that the port parameter has the correct value.
The communication.properties file is stored in the following location on the
runtime server computer:
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\conf
After you have edited the communication.properties file, restart the runtime
server.
Deleting the virtual host definition
This section gives instructions about deleting the virtual host definition in the IBM
HTTP Server. If you are using a different Web server, follow the instructions in the
corresponding documentation to achieve the same objective.
Optionally, you can delete the SSL-enabled virtual host definition from the HTTP
configuration file, httpd.conf. See “Enabling SSL for the Web server” on page 107
for the description of the definition that can be deleted. Stop and restart the HTTP
server after you have edited the file.
Note: If you took a backup of the configuration file or noted its settings prior to
defining the virtual host definition, you may now be able to revert to that
version, depending on whether any other changes have been made to the
file in the meantime.
Restoring default port aliases
Check the WebSphere Application Server list of host aliases on the computer where
the administration server runs.
1. Open the WebSphere Administrator’s Console.
2. In the portfolio select Environment � Virtual Hosts. and click Default_host on
the panel.
3. On the Default host panel click Host aliases.
4. If the aliases that use the default port (80) have been deleted, click New and
define the following fields:
Host name
Enter an asterisk: *
SSL: activities
116 IBM Tivoli License Manager: Planning, Installation, and Configuration
Port The port you have chosen to use for insecure communications:
normally 80.
This adds an alias for port 80 for every type of communication from every
source.
5. Click Apply.
6. On the administration server computer only, you can optionally delete the
aliases that use the SSL port (443) or any other port used for secure
communications. If you do this, only insecure communications are available
between the runtime and administration servers.
Note: Do not delete the aliases used for secure communications on runtime
servers, because runtime server to agent communication might not
always be insecure.
7. When you have made all the changes you want to, click Save at the top of the
Default host panel, and then Save again.
8. Regenerate the plug-in by issuing the command genplugincfg from the
<WEBSPHERE INSTALL_DIR>\bin directory.
9. Stop and restart the Web server.
Configure the mail notification settings for a server
To use event notification you must specify who is to receive notifications, using the
appropriate server GUI and modifying the account settings for each user. In
addition, you must define the settings that enable the notifications to be sent
automatically.
Each Tivoli License Manager server has its own settings that control the sending of
notifications. You define the settings to be used to send notifications in the
system.properties file for each server.
Note: The Tivoli License Manager server will probably be running, because the
install wizard started it. If you define or change notification settings you
must stop the server and restart it before the settings take effect.
The following is an example of the Mail Settings section of the system.properties
file.
#Mail Settings
smtpServer=mailserv120.ibm.com
To define notification settings for a server, complete the following steps:
1. Log on to the computer where the administration or runtime server is installed.
2. Open the system.properties file in a text editor.
The location of the system.properties file is as follows:
Administration server
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\conf
Runtime server
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\conf
SSL: activities
Chapter 3. Configure Tivoli License Manager 117
Note: If the administration server is installed on the same computer as a
runtime server, system.properties files exist in both locations. You must
define settings in both files to enable both types of notification.
3. In the#Mail Settings section of the file, define the properties as follows:
smtpServer
Enter the host name or IP address of a valid Simple Mail Transfer Protocol
(SMTP) server. This server is used to forward the e-mail communications
generated by the notification component of the server. This product was
tested on the SMTP server bundled with the SUSE Linux Enterprise Server
on an Intel platform, but any SMTP server can be used.
mailSender
Enter the e-mail address that is to be used by the server as the sender
address when notifications are generated. This must be a valid e-mail
address.
mailRecipient
You can enter the e-mail address to which notifications are to be sent. This
setting is optional because you can set up Tivoli License Manager
administrators to receive notifications using the Web interfaces.4. Save the file and close it.
Note: No e-mails are generated if the settings for the SMTP server and the mail
sender are not present or not valid.Finally, do not forget that, for a user to receive notifications, you have to set up the
user’s address and enable the type of notification, using the administration or
runtime server GUI.
Customize the Web server
For the administration server and the runtime servers to function, each requires a
Web server to handle the communication protocol. In the event that the WebSphere
Application Server fails to respond correctly when the Web server passes it a
request, the Web server generates an industry-standard HTTP error with error
number 500. Tivoli License Manager enables you to customize the HTML page that
is displayed in this event, so that your users have a specific rather than a generic
message. You can create a separate message for each Web server in your Tivoli
License Manager structure.
If you want to implement this customization, take the following steps for each Web
server:
1. Locate these directories:
Administration server
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\webdoc\customerrors\
Runtime server
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\webdoc\customerrors\
Within these directories are subdirectories for each supported language (for
example, en_us, it, fr). Each subdirectory contains an itlm500.html file for the
server in question, in the appropriate language.
Mail notifications
118 IBM Tivoli License Manager: Planning, Installation, and Configuration
2. Copy all the contents of the appropriate directory identified in step 1 on page
118, including all the language subdirectories, to the document root directory of
the Web server that you want to customize (for example, for IBM HTTP Server
version 1.3.28, the document directory is called IBM HTTP SERVER
INSTALL_DIR\htdocs\<locale>).
where, <locale> is the language used by your instance of HTTP Server, for
example en_US.
Notes:
a. The document root directory of the Web server may already contain a locale
directory with the same name as one of the directories you are copying. In
this case, if the operating system identifies this fact and asks you if you
want to overwrite any existing files in it, you should reply ″Yes″. The only
circumstances in which a file with the name itlm500.html would be already
present, is if you are performing this customization more than once, in
which case the file can safely be overwritten. No other files in the locale
directory are overwritten or damaged.
b. Copy just the contents of the directory, not the directory itself. For example:
xcopy C:\Program Files\IBM\TLM\slm_admin.war\webdoc\customerrors\*.*
C:\Program Files\IBM HTTP Server\htdocs /S
When you have finished the copy you should see a structure similar to the
following (the example is for the US English locale on Windows):
C:\Program Files\IBMHttpServer\htdocs\en_US\de\itlm500.htm
\en_US\itlm500.htm
\es\itlm500.htm
\fr\itlm500.htm
\it\itlm500.htm
\ja\itlm500.htm
\ko\itlm500.htm
\pt_BR\itlm500.htm
\resources\*.*
\zh_CN\itlm500.htm
\zh_TW\itlm500.htm
3. The text of the English version of these files is as follows:
Administration server
An error has occurred at the administration server.
The server encountered an unexpected condition which
prevented it from fulfilling the request.
Contact your system administrator.
Runtime server
An error has occurred at the runtime server.
The server encountered an unexpected condition which
prevented it from fulfilling the request.
Contact your license administrator (license_administrator@domain).
If you wish to give different information to the users that are deploying agents,
(for example, the e-mail address of the license administrator), or you want to
change the message, for example, to tell the user to retry the operation after
waiting 5 minutes, edit all of the files in each of the locale subdirectories. The
fact that a copy of these files resides on each runtime server enables you to add
runtime server-specific information, if required.
4. Customize the Web server to invoke the file appropriate to your locale when
the code 500 error occurs:
Web server
Chapter 3. Configure Tivoli License Manager 119
v In the IBM HTTP server, you do the following steps:
a. Locate the following file: IBM HTTP Server INSTALL_DIR\conf\httpd.conf
b. Find the virtual host section in that file, if one exists. If you have enabled
SSL on this computer, you will have already set up a virtual host
definition for Tivoli License Manager. If you have other applications
using the HTTP server you may have already set up a virtual host
definition for the other applications. If a virtual host definition has been
set up, it will look something like the following example:
#<VirtualHost <yourServerName>:<yourServerPort>>
...
#</VirtualHost>
where yourServerName is the host name of your HTTP server and
<yourServerPort> is the port that is using.
Note: yourServerName may be just a single asterisk, indicating that all
requests, whether using the host name or the IP address, use the
same Virtual Host Definition.
There may be more than one Virtual Host definition. If you have both
HTTP and HTTPS enabled, you may have one for each, with different
values for the port. However, on some platforms there is no virtual host
definition for the insecure port.
c. If you already have one or more virtual host definitions, insert this line in
each one:
ErrorDocument 500 /locale/itlm500.html
For example, ErrorDocument 500 /en_US/itlm500.html
If you do not have a virtual host definition for the insecure port, this line
can be inserted without forming part of a virtual host definition.
However, you may prefer to create one, as follows:
<VirtualHost *:yourServerPort>
ServerAdmin webmaster@yourServerName
DocumentRoot /www/docs/yourServerName
ServerName yourServerName
ErrorLog logs/yourServerName-error.log
TransferLog logs/yourServerName-access.log
ErrorDocument 500 /locale/itlm500.html
</VirtualHost>
d. Stop and restart the HTTP server to enable the changed configuration
setting to take effect.v In other Web servers, follow the instructions in their documentation to direct
the server to display the itlm500.html file in the event of a type 500 error.5. Test that the file is available by opening a Web browser on the computer where
the Web server is running, and issuing the URL:
//localhost/itlm500.html
The customized file should be displayed.
To test that the Web server has been correctly configured, stop the Tivoli License
Manager server, and attempt to connect to the server’s Web interface. If the
customization has been completed successfully, the customized page should be
displayed, as follows (the example is for the runtime server, and the file itself has
not yet been customized):
Web server
120 IBM Tivoli License Manager: Planning, Installation, and Configuration
Define the authentication method
Tivoli License Manager includes a facility for selecting the method by which
account authentication is carried out when a user logs on to one of the server
components. The authentication method can be different for each server, even if
more than one server is installed on the same computer. In all cases, it is necessary
to create accounts in Tivoli License Manager for these users, each with an
associated password. The authentication options available for these accounts are as
follows:
XML The account names and encrypted passwords are saved in an XML
file on the server.
Database The account names and encrypted passwords are saved in the
server’s database. This adds an extra level of security, as the
database is more secure than an XML file. This is the default.
LDAP If you already use LDAP to authenticate user access to other
applications, you can also configure Tivoli License Manager to use
it. You still need to create the corresponding accounts in Tivoli
License Manager, but when a user logs in, it is the LDAP server
that authenticates the user.
Full details of the questions to take into consideration, and the prerequisites for
using LDAP, are given in “Plan to define the authentication method” on page 38.
The steps to be taken for the configuration are much more complicated for LDAP
than for the other methods, so the descriptions are divided as follows:
v “XML or Database Authentication” on page 122
v “LDAP Authentication” on page 122
Web server
Chapter 3. Configure Tivoli License Manager 121
XML or Database Authentication
The procedure to set the authentication method to XML or Database, is as follows:
1. Log on to the server component where you want to change the authentication
method as Administrator or root, or with the corresponding rights.
2. Open a command line session and navigate to one of the following directories,
as appropriate:
<INSTALL_DIR>\admin\setup
<INSTALL_DIR>\runtime\setup
3. Run one of the following commands (they are case-sensitive):
To set the XML method on the administration server
On Windows: changeAdminAuth.bat XML
On UNIX: changeAdminAuth.sh XML
To set the XML method on the runtime server
On Windows: changeRuntimeAuth.bat XML
On UNIX: changeRuntimeAuth.sh XML
To set the Database method (the default) on the administration server
On Windows: changeAdminAuth.bat DB
On UNIX: changeAdminAuth.sh DB
To set the Database method (the default) on the runtime server
On Windows: changeRuntimeAuth.bat DB
On UNIX: changeRuntimeAuth.sh DB
The command displays a message when it has finished, showing whether or
not it has succeeded in changing the authentication method.
4. Stop and restart the WebSphere Application Server to enable the command to
take effect.
5. Now commence the creation of the user accounts in Tivoli License Manager.
Note: If you have already created accounts using one method, and then change
methods, you do not need to recreate the accounts. However, the
tlmroot user must change the passwords, as the two methods use
different password encryption algorithms.
An option is available that enables you to import account information. See
“Importing account data” on page 130.
LDAP Authentication
The procedure to set the authentication method to LDAP, is as follows:
1. Create the user accounts you require in Tivoli License Manager. It is not
necessary to give these accounts the same password as they have in LDAP.
Note: If you have already created accounts using one method, and then
change methods, you need to recreate the accounts.
An option is available that enables you to import account information. See
“Importing account data” on page 130.
2. If you are able to, create an LDAP entry for the Tivoli License Manager super
administrator ″tlmroot″. For security, you should change the default Tivoli
Authentication method
122 IBM Tivoli License Manager: Planning, Installation, and Configuration
License Manager password to a password of your own choice before creating
this LDAP user, and then when you create the LDAP user you should give it
the password you have just created.
If your LDAP implementation does not allow you to set up users that are not
identified individuals, you have to change the authentication method from
LDAP to one of the other methods every time you need to use the super
administrator, and switch back again afterwards. By using the dataexp
command with an entity of –Administrator while you are still using LDAP
authentication you export the current details of administrators, and by using
the dataimp command to read in the file you created previously, you can
easily recreate the account data after returning to the LDAP method.
3. Log on to a server component as Administrator or root, or with the
corresponding rights.
4. Open a command line session and navigate to the following directory:
<INSTALL_DIR>\admin\setup
5. Run one of the following commands (they are case-sensitive):
To set the LDAP method on the administration server
On Windows: changeAdminAuth.bat LDAP
On UNIX: changeAdminAuth.sh LDAP
To set the LDAP method on the runtime server
On Windows: changeRuntimeAuth.bat LDAP
On UNIX: changeRuntimeAuth.sh LDAP
The command displays a message when it has finished, showing whether or
not it has succeeded in changing the authentication method.
6. Stop and restart the WebSphere Application Server to enable the command to
take effect.
Authentication method
Chapter 3. Configure Tivoli License Manager 123
7. Open the WebSphere Administrative Console. The following window is
opened:
Authentication method
124 IBM Tivoli License Manager: Planning, Installation, and Configuration
8. Select the following options in the portfolio pane of the window: Security �
JAAS Configuration � Application Logins. The following panel is displayed:
In this example, both the administration server and a runtime server are
installed on the same computer. If you have only one server installed you
only see one server in the Application Login Configuration list.
Authentication method
Chapter 3. Configure Tivoli License Manager 125
9. Click the server name you wish to configure (do not select the checkbox). The
following panel is displayed:
In this example, the administration server has been chosen, but the procedure
is the same for both.
10. Click the JAAS Login Modules link. The following panel is displayed:
11. Click the name of the login module proxy (in this case
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy). The
Authentication method
126 IBM Tivoli License Manager: Planning, Installation, and Configuration
following panel is displayed:
12. Click the Custom Properties link. The following panel is displayed:
On this panel may be displayed the configuration parameters that you must
modify. Alternatively, it may be like the screen sample, with none of the
values you require defined.
Authentication method
Chapter 3. Configure Tivoli License Manager 127
13. Click the name of a parameter to modify or click New to enter a parameter
that is not already in the list. The values to set are as follows:
Parameter Value to set
java.naming.provider.url ldap://<your_LDAP_server>:<your_LDAP_port>
principalDNPrefix The LDAP domain name prefix. This is normally CN=
principalDNSuffix The LDAP domain name suffix. This depends on your
LDAP directory structure. For example, for Microsoft
Active Directory, a structure of TLM.org/Users should
be set up as CN=Users,DC=TLM,DC=org, whereas for IBM
SecureWay Directory, IBM/US should be set up as
O=IBM,C=US.
For more information about these fields, see your LDAP Server
documentation.
When you click on New, a panel like the following is displayed:
Authentication method
128 IBM Tivoli License Manager: Planning, Installation, and Configuration
14. Set the value you want and click Apply. The panel is redisplayed with a
message at the top inviting you to save the configuration:
15. Click the Custom Properties link in the breadcrumbs and repeat the operation
until all properties have been defined.
Authentication method
Chapter 3. Configure Tivoli License Manager 129
16. Then click the Save link in the message at the top of the screen, and the
following panel is displayed:
17. Click the Save button to save the configuration.
18. Stop and restart the Tivoli License Manager servers controlled by this instance
of WebSphere Application Server (see “Starting and stopping a Tivoli License
Manager server” on page 295).
The Tivoli License Manager administrators that you have set up can now log on to
the server using their LDAP user ids and passwords. Changing the password in
Tivoli License Manager has no impact on the LDAP password, and deleting
accounts or changing account details has no impact on the LDAP account data.
Importing account data
An option is available for you to import user account details into the
administration server. This option requires you to be able to export them in XML
or CSV format from the database where they are stored, for example, from the
LDAP server. The DTD of the XML file, is as follows:
<!ELEMENT Administrators (Administrator)*>
<!ELEMENT Administrator (Id, FirstName, MiddleName?, LastName,
LogonName, EmailAddress?, Phone?, Fax?,
Password?, Profiles?)>
<!ELEMENT Id (#PCDATA)>
<!-- unique key within the organization -->
<!ELEMENT FirstName (#PCDATA)>
<!ELEMENT LastName (#PCDATA)>
<!ELEMENT LogonName (#PCDATA)>
<!-- user name used to log into the system -->
<!ELEMENT Password (#PCDATA)>
<!ELEMENT Profiles (Profile+)>
<!ELEMENT Profile (OrganizationName, ProfileId, HideHostInv,
HideHost, HideUser, HideGroup)>
<!ELEMENT OrganizationName (#PCDATA)>
Authentication method
130 IBM Tivoli License Manager: Planning, Installation, and Configuration
<!ELEMENT ProfileId (#PCDATA)>
<!ELEMENT HideHostInv (#PCDATA)>
<!ELEMENT HideHost (#PCDATA)>
<!ELEMENT HideUser (#PCDATA)>
<!ELEMENT HideGroup (#PCDATA)>
The minimum values that you need to supply are as follows:
v FirstName
v LastName
v LogonName
To see an example of the file in CSV or XML format, create an account on the
administration server GUI and then export it using the dataexp command with the
–administrator entity. This command is fully documented in IBM Tivoli License
Manager: Administration.
When you have created your CSV or XML file, import it into the server using the
dataimp command. This command is fully documented in IBM Tivoli License
Manager: Administration.
Configuring proxy servers
You can define proxy server settings for communications between runtime servers
and the administration server and between runtime servers and their agents.
To define a proxy for communications between a runtime server and the
administration server, complete the following steps:
1. On the runtime server computer, navigate to the <INSTALL_DIR>\runtime\conf
folder.
2. Open the communication.properties file in a text editor.
3. Scroll down to find the proxy parameters, and define them as follows:
useProxy
Modify the useProxy parameter, to the following:
useProxy = true
proxy
Modify the proxy parameter, to the following:
proxy = http://<proxy_address>:/
where <proxy_address> is the full Web address of the proxy server.
proxyPort
Modify the proxyPort parameter, to the following:
proxyPort = <proxy_port>
where <proxy_port> is the port number for the communication.4. Save the file and exit.
5. Stop and restart the runtime server.
To define a proxy for communications between a runtime server and the agents
that are assigned to it, complete the following steps before deploying agents:
Authentication method
Chapter 3. Configure Tivoli License Manager 131
1. On the runtime server computer, navigate to the <INSTALL_DIR>\runtime\conf
folder.
2. Open the agent_install.properties file in a text editor.
3. Scroll down to find the proxy parameters, and define them as follows:
# Proxy name
parm.proxyname=<proxy_address>
where <proxy_address> is the full path of the proxy.
# Proxy port
parm.proxyport=<proxy_port>
where <proxy_port> is the port number
# Proxy is enabled
parm.useproxy=y
4. Save the file and exit.
Automatic computer label assignment
On the runtime server you can set an option that allows the Web registration
process to automatically assign the Computer label field when registering an agent,
using information obtained from the operating system of the node from which the
registration is launched. This automatic assignment can be overridden manually by
the user.
This option only applies to Web registration, not to the other agent deployment
methods.
The effect of automatic computer label assignment
When a user contacts the runtime server to register, if the automatic computer
label assignment option is set the screen that is displayed is as follows:
Proxies
132 IBM Tivoli License Manager: Planning, Installation, and Configuration
This screen does not allow input in the Computer label field. Instead, a radio
button called Automatic computer label assignment is displayed, with its value
set to Yes. If the user clicks Finish, the Web registration applet uses the information
in the configuration file at the runtime server to determine what information held
by the operating system is used to form the computer label.
However, if the user wants to, he or she may select No at which time the
Computer label field is enabled, and the user can input a computer label
manually, optionally including one or more of the variables detailed in the next
section.
Implementing automatic computer label assignment
The steps to take are as follows:
1. Locate the agent_install.properties file in the configuration directory:
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\conf
2. Edit the file, changing the following parameters:
parm.automaticTagAssignment
Change the value to y.
parm.node_<platform>
For each platform, change the existing value to any combination of the
following:
Automatic computer label assignment
Chapter 3. Configure Tivoli License Manager 133
%SERIAL
The serial number of the computer.
%TYPE
The type of hardware.
%MODEL
The hardware model.
%VENDOR
The name of the hardware producer.
%HOST
The host name of the computer.
For example, to concatenate the serial number and the hardware model,
enter %SERIAL%MODEL.3. Save the file.
4. Stop and restart the runtime server using the srvrstop and srvrstart commands
from the runtime server command line.
Import an up-to-date version of the IBM Catalog
Tivoli License Manager includes a copy of the IBM Catalog, which the installation
loads into the administration server database. However, this catalog may not be
the latest version, depending on when you obtained the product CDs, or when you
downloaded the CD images. You should take an early opportunity to download an
up-to-date version of the catalog from the IBM Catalog Web site.
This can be done either through the GUI of the catalog manager (see IBM Tivoli
License Manager: Catalog Management), or by using the impcat command
(documented in IBM Tivoli License Manager: Administration, in the appendix on
end-to-end processing).
Other configuration procedures
The following configuration procedures are documented in this section:
v “Optionally configure a server on UNIX to run under a non-root user.”
v “Optionally configure Java 2 Security for a server” on page 135
Optionally configure a server on UNIX to run under a non-root
user.
The default user for running Tivoli License Manager servers on a UNIX computer
is root. If you don’t want to use the root user for this purpose you can reconfigure
WebSphere Application Server and the server to run under a non-root user. The
procedure is as follows:
1. Install a Tivoli License Manager server.
2. Create a user. For the purposes of this scenario the user is called ″was1″ and
belongs to the ″wasgroup″ user group.
3. Configure WebSphere Application Server to run from user ″was1″ in user group
″wasgroup″ (see the WebSphere Application Server documentation for details).
4. Change the owner group of the Tivoli License Manager <INSTALL_DIR> to
″wasgroup″.
5. Change the owner group of the Tivoli License Manager sub-directory COD in the
<TivoliCommonDirectory> to ″wasgroup″.
Automatic computer label assignment
134 IBM Tivoli License Manager: Planning, Installation, and Configuration
6. Give ″write″ permission to the Tivoli License Manager sub-directory COD in the
<TivoliCommonDirectory>.
7. Give ″write″ permission to the Tivoli License Manager server’s configuration
directory:
Administration server
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\conf
Runtime server
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\conf
8. Stop and restart the server using the srvstop and srvstart commands.
Optionally configure Java 2 Security for a server
If you want to configure Java 2 Security for a Tivoli License Manager server, this is
the procedure to follow
1. Locate the following directory:
<WAS_INSTALL_DIR>\config\cells\<cellName>\applications\SLM_<TLMServer>_Application.ear\deployments\SLM_<TLMServer>_Application\META-INF
The variables are as follows:
<WAS_INSTALL_DIR>
The WebSphere Application Server installation directory. For example,
on Windows this might be the following:
D:\Program Files\WebSphere5.1\AppServer
<cellName>
The hostname of the computer.
<TLMServer>
One of the following:
Administration server Admin (case sensitive)
Runtime server Runtime (case sensitive) 2. Open the file was.policy.50x or was.policy.51x (depending on the version of
WebSphere Application Server)
3. Replace the tags <CFG_TIVOLI_COMMON_DIR> and
<TIVOLI_COMMON_DIR> with the relevant paths, respecting the comments
in the file. These are, respectively, the paths to the Tivoli Common Directory
configuration file and the Tivoli Common Directory itself (see IBM Tivoli
License Manager: Problem Determination for details of how to determine these
paths on different platforms and nodes.
4. Save the file.
5. Rename the existing was.policy file as was.policy.old.
6. Rename the was.policy.50x or was.policy.51x file as was.policy.
7. Enable Java 2 Security following these steps:
a. Open the WebSphere Application Server Administrative Console
b. Click on Security � Global Security
c. Select the checkbox Enforce Java 2 Security
d. Click Apply in the lower part of the panel, and then Save in the upper
part.
Server under non-root user
Chapter 3. Configure Tivoli License Manager 135
If you have both servers running on the same computer, repeat these
operations for the other server.
8. Stop the Tivoli License Manager servers, using the srvstop command.
9. Change to the <TLM_INSTALL_DIR>\admin\was or
<TLM_INSTALL_DIR>\runtime\was directory, as appropriate,
<TLM_INSTALL_DIR> is the directory where Tivoli License Manager is
installed.
10. Delete the files stdout.txt and stderr.txt. If you have both servers running
on the same computer, repeat these last two steps for the other server.
11. Start the Tivoli License Manager servers, using the srvstart command.
Note: If you already have Java 2 Security enabled on an existing WebSphere
Application Server installation, when you installed the Tivoli License
Manager server or servers, you would not have been able to use the server’s
GUI, because Tivoli License Manager had not yet been configured for Java 2
Security. You should now perform the above procedure, excepting only step
7 on page 135, which has already been done.
Tuning your environment
This chapter gives you information about how to tune your Tivoli License Manager
environment to maximize performance. It is divided into these sections:
v “Tuning Tivoli License Manager”
v “Tuning DB2 and WebSphere Application Server”
Tuning Tivoli License Manager
Tuning information for Tivoli License Manager is given in a number of places:
v Information about the maximum capacity of the components and infrastructure
is given in “Determine the Tivoli License Manager topology” on page 9.
v Information about scheduling software scans is given in
v Information about the product’s configuration parameters is given in
Appendix A, “Configuration settings,” on page 233.
v Other tuning information that may become available during the life of the
product will be provided in the IBM Tivoli License Manager: Release Notes. The
latest version of this can be downloaded at any time from the documentation
Web sites (see “Accessing publications online” on page xvi).
Tuning DB2 and WebSphere Application Server
The following information is available to you to help you tune the prerequisites
that support Tivoli License Manager:
v Redbook: DB2/UDB/WebSphere Performance Tuning Guide
This redbook contains useful information about tuning DB2 and WebSphere
Application Server for performance. In particular, see Sections 2.7–2.10, Chapter
3, Sections 3.3-3.5; and Chapters 4 and, 5.
v Redbook: IBM WebSphere V5.0 Performance, Scalability, and High Availability:
WebSphere Handbook Series
This redbook contains useful information about tuning WebSphere Application
Server for performance. In particular, see chapter 18.
v IBM WebSphere Application Server, version 5.0.2: Monitoring and Tuning Performance
This is the original tuning guide for WebSphere Application Server, version 5.
v DB2 UDB V8 and WebSphere V5: Performance Tuning and Operations Guide
Java 2 Security
136 IBM Tivoli License Manager: Planning, Installation, and Configuration
This contains useful information for improving the performance of DB2, version
8, and WebSphere Application Server, version 5.
Tuning
Chapter 3. Configure Tivoli License Manager 137
Tuning
138 IBM Tivoli License Manager: Planning, Installation, and Configuration
Chapter 4. Deploy agents
The agent can be deployed using any of the following methods:
By Web deployment
The agent can be deployed by the user connecting to a runtime server Web
deployment page. See “Deploying an agent over the Web” on page 140.
Using installagent command
The agent can be deployed by downloading a set of files to a user’s
computer, from which the installagent command is run manually. See
“Deploying the agent manually (installagent command)” on page 145.
Using Tivoli Configuration Manager
The agent can be deployed on any endpoints in a Tivoli region using the
supplied software package block. See “Deploying agents using Tivoli
Configuration Manager” on page 152.
Using SSH or RSH for UNIX nodes
The agent can be deployed on nodes running UNIX, or a UNIX-like
operating system, leveraging an existing SSH or RSH network. See
“Deploying agents to UNIX nodes using SSH and RSH” on page 162.
Using Windows logon scripts
The agent can be deployed on all Windows nodes where users log onto a
Windows network domain with administrator rights, using the Windows
network facility that can run a script when a user logs on to the network.
See “Deploy agents using Windows logon scripts” on page 170.
On OS/400 nodes
The agent can be deployed on OS/400 nodes in several ways. It can be
deployed using a wizard on a Windows platform connected to an OS/400
node, or using a native wizard on an OS/400 node. Once installed on an
OS/400 node you can use the Save Licensed Program and Restore Licensed
Program options to copy it from node to node. See “Install agents on
OS/400” on page 175.
In addition, the agent on OS/400 can also be deployed using Tivoli
Configuration Manager. See “Deploying agents using Tivoli Configuration
Manager” on page 152.
Deploying the WebSphere Application Server agent
If you have WebSphere Application Server deployed on an agent, an
additional agent process is used, which detects products running on
WebSphere Application Server. This process is the WebSphere Application
Server agent, normally referred to as the wasagent. See “Deploying the
WebSphere Application Server agent” on page 185 for more details.
Notes:
1. There is a delay between the agent starting to monitor the node and
information from the agent being available on the servers. You must take into
account the time delays required for scanning the node and for transferring
data to the runtime server and then to the administration server. You can set
time delay parameters in the runtime server section of the system.properties
file; see “Runtime server settings” on page 239.
2. The computers where you have installed the main components can also be
monitored by deploying the agent on them. Be aware of the implications of
© Copyright IBM Corp. 2002, 2004 139
monitoring computers on which the servers and databases are installed.
Prerequisite software, for example WebSphere Application Server, running on
these computers must not be prevented from starting because the runtime
server is not available. Using the administration server Web UI, you must
define entitlement settings that allow prerequisite software to run offline.
3. When an agent is deployed it can only contact the runtime server with which it
has been registered. When it has successfully made contact, it will download
the list of alternative servers it may contact in the event of a failure to contact
the registered server. This list is saved to disk, so that on subsequent restarts it
has the full list of runtime servers available to it.
Further information about the agent is available in Chapter 9, “The agent,” on page
217. For specific information see the following list:
v A general overview of agent functionality is at “Summary of agent functionality”
on page 217.
v The deployment of an agent on an individual’s computer raises privacy issues.
See “Managing privacy policies for computers and users” on page 219.
v The deployment of the agent installs a number of files on the monitored node.
See “Agent files” on page 221.
v If you want to perform actions on the agent, like starting and stopping it,
monitoring its status, and checking its connection to the runtime server, a variety
of commands are available, depending on the platform. See “Agent commands”
on page 227.
v Once the agent has communicated with the runtime server, and the runtime
server has passed the information on to the administration server, you can view
the information about the agent on the administration server GUI. See
“Reviewing and deleting agents” on page 231.
v If you want to assign the agent to a different runtime server or division, you can
have to redeploy the agent with the new parameters. See “Redeploying an
agent” on page 231.
v After the agent is installed, you can apply any upgrades to the agent code
automatically. See “Agent self-update” on page 231.
v The agent can be uninstalled from the node. See “Uninstalling the agent” on
page 208.
v If the agent has been uninstalled, and you no longer wish to monitor that node,
you can delete it from the database. See “Reviewing and deleting agents” on
page 231.
Deploying an agent over the Web
Each runtime server hosts a Web page from which a user at a node that is to be
monitored can download the Tivoli License Manager agent and install it on the
node. This page is not password protected, so the user does not need to have the
user name and password of a Tivoli License Manager administrator to use it.
However, the user must be logged on with administrator rights to the node. The
administrator can choose to enable SSL communications between the agent and the
server, so that the deployment is secure. When the agent has been successfully
installed it starts, contacts the appropriate runtime server, and is registered by the
runtime server.
Typically, the Tivoli License Manager administrator would contact users and ask
them to deploy the agent on their machines. The administrator would probably
want to send an e-mail to all nodes that should register with the same runtime
Agent deployment
140 IBM Tivoli License Manager: Planning, Installation, and Configuration
server for the same division. The administrator should ask them to log on with
administrator rights, and supply them with the Web address of the runtime server
with which the user should register the node, and the name of the division to
which the node should belong.
The Web deployment requires the appropriate version of the Java Runtime
Environment (see “Web deployment prerequisites” on page 46). For the
deployment to be successful, the plug-in must be installed prior to commencing, or
the computer must be connected to the Internet. In this event, if the computer is
using Internet Explorer on a Windows platform to run the deployment it
downloads and installs JRE from the Sun Web site. For other browsers and
platforms you will be directed to the appropriate Web site for JRE, but must
download and install it manually.
To deploy an agent on a node, the user should complete the following steps:
1. Log on: Log on to the node as a user with administrator rights. If you are not
logged on with administrator rights, the deployment starts, but subsequently
fails.
Note: If the user deploying the agent is on a Windows node, ensure that the
user is told to close the Windows Services Administrative Tool window
before starting the deployment; otherwise the agent might not be
installed as a service and might not start.
2. Access a runtime server: Open a supported Web browser (see “Using Web
deployment” on page 46), and access the runtime server indicated by the Tivoli
License Manager administrator.
If the runtime server has been set up to support SSL communications, the
address of the page is
https://<runtime_server_address>/slmruntime/deploy
If the runtime server has not been set up to support SSL communications, the
address of the page is
http://<runtime_server_address>/slmruntime/deploy
3. Read and accept Privacy Policy information: The Privacy Policy panel is
displayed. Read the privacy policy information, and then click Deploy agent.
4. Enter deployment information: The deployment panel is displayed:
Agent deployment: Web
Chapter 4. Deploy agents 141
There is a setting in the agent_install.properties file called
parm.automaticTagAssignment. If this is set to y, the lower part of the screen
will be different, as follows:
Complete the requested information, as follows:
Agent deployment: Web
142 IBM Tivoli License Manager: Planning, Installation, and Configuration
Division
Select the division to which the agent is to belong from the drop-down list.
Server name
Select the runtime server that the agent is to use from the drop-down list.
This does not need to be the runtime server from which you are deploying
the agent.
Note: The drop-down list includes all runtime servers that have been
registered with the administration server for the selected
organization. If the server you want is not in the list, this might be
because you have installed the component but have not registered
the new server.
Computer Label
What you should do here depends on whether the
parm.automaticTagAssignment field is set, or not.
parm.automaticTagAssignment=n
Type the computer label of the node from where the deployment is
taking place. This is free-format text and represents your way to
recognize the agent. It is not case sensitive, and all lower-case
characters are converted to upper-case when the agent is registered.
You can use the following variables to make up all or part of the
computer label:
%SERIAL
The serial number of the computer.
%TYPE
The type of hardware.
%MODEL
The hardware model.
%VENDOR
The name of the hardware producer.
%HOST
The host name of the computer.
These variables can be used on Windows or UNIX, although on
some platforms certain values may be null. Thus you are advised to
combine variables always with either %SERIAL or %HOST, in order to
ensure a non-duplicate computer label.
Note: If you want to use the % character as part of the computer
label you should be aware that if the text following the
percent sign matches one of the above variables, the variable
will be used instead of your text. For example, if you try and
deploy an agent on a node with a host name of ″johndoe″
and you want to give it a label of ″50%hosted″, it will be
deployed as ″50JOHNDOEED″.
parm.automaticTagAssignment=y
If this value is set to y at the runtime server, Computer label is
disabled, and Automatic computer label assignment is enabled,
with the default value of Yes selected.
Agent deployment: Web
Chapter 4. Deploy agents 143
v If you accept the default for the radio button, the computer will
be registered with a computer label that uses a combination of
one or more of the variables detailed above, as determined by
the settings in the agent_install.properties file on the runtime
server you have contacted.
v However, if you change the selection to No, Computer label
becomes enabled, and you can type a value, using the variables
if you want to.
Click Finish.
5. Accept the security warnings: Standard security warnings for downloading
from a Web site appear.
Accept the security warnings.
Note: The number and format of warning panels differs for different browsers.
For example, for Internet Explorer, there is a single panel, and you must
click Yes to accept it. If you do not accept these warnings, the agent is
not deployed.
6. Prerequisite JRE not installed: If the prerequisite level of the Java Runtime
Environment (JRE) is not already installed the following happens:
Windows with Internet Explorer connected to the Internet
If you are using the prerequisite version of Internet Explorer on
Windows and are connected to the Internet, the applet connects to the
Sun web site and downloads and installs the correct version of JRE
before continuing with the deployment.
Other platforms and browsers connected to the Internet
The applet displays a message to indicate that the prerequisite is not
installed, and redirects the browser to the appropriate Web site. You
should download and install JRE manually and then rerun the Web
deployment.
Any platform and browser not connected to the Internet
An error page appears on your browser. You should connect to the
Internet and repeat the Web deployment.7. The agent is deployed: The applet now downloads the appropriate files and
then silently runs the installagent command to deploy the agent on the node
and start it. For information about the files created when the agent is deployed,
see “Agent files” on page 221. For information about the installagent command,
see “Deploying the agent manually (installagent command)” on page 145.
During this process, which can take some minutes, a message is displayed on
the browser window telling you that the deployment is in progress.
When the deployment is finished, an appropriate message is displayed on the
screen. You need take no further action.
Note: On Windows nodes, if the deployment operation finds that GSKit is
already in use, it cannot complete the installation until the computer is
rebooted. It creates a file in the agent’s directory called
reboot_needed.txt in which it stores this requirement by setting a
variable called GSKFilesLocked to the value 1. A message is displayed
informing the user that a reboot is required. The presence of this variable
in this file prevents the agent from starting. When the computer is
rebooted, and the GSKit files are unlocked, the installation of the agent is
completed, and the file is deleted.
Agent deployment: Web
144 IBM Tivoli License Manager: Planning, Installation, and Configuration
8. The agent starts: After the agent starts, it commences running a series of
services which pass information to the runtime server and receive information
from it. One of these services receives the divisional agent configuration
parameters, for the division selected in step 4, which are applied and saved to
disk at the agent node.
If the deployment is not successful, a message is displayed indicating the reason.
One or more trace files might have been created by the applet, and you should
examine their contents. Full details of these message and trace files is provided in
IBM Tivoli License Manager: Problem Determination.
Deploying the agent manually (installagent command)
To deploy an agent manually, perform the following steps:
1. Log on to runtime server: Log on to the appropriate runtime server with rights
that enable you to copy files to remote nodes.
2. Locate the required files: Navigate to the directory where the agent files are
stored:
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\webdoc\agent
3. Copy the files: A script is provided that collects all the files needed for a
distribution to any supported platform. It saves the files in the directory of
your choice, which has the following structure:
aix Files for AIX platforms.
hpux Files for HPUX platforms.
linux Files for all Linux Intel platforms other than Red Hat Enterprise Linux,
version 2.1.
linux21 Files for Red Hat Enterprise Linux, version 2.1 on Intel.
linux390 Files for Linux on S/390 and zSeries platforms.
linuxppc Files for Linux on iSeries and pSeries platforms.
sun32 Files for Solaris 32-bit platforms.
sun64 Files for Solaris 64-bit platforms.
win32 Files for Windows platforms.
For full details of these files see “Files required by the installagent command”
on page 219.
To run the script, issue the following command:
Windows
manualDeploy.bat <agentFilesDirectory>
UNIX manualDeploy.sh <agentFilesDirectory>
Where <agentFilesDirectory> is the path and name of any directory of your
choice, relative to the directory from where the command is being run. You are
recommended to select a location outside the Tivoli License Manager product
structure. This directory must have write permission and must have space for
at least 180 MB. It must be on the same computer as the runtime server. If it
does not exist it will be created.
The script potentially produces the following messages:
Agent deployment: Web
Chapter 4. Deploy agents 145
manualDeploy_2. Copy failed, see log file <logFile>
The script encountered a problem making the file copy. The details are
in the indicated log file that has been created in the directory from
which the script was run. Look at the log file to see if you can
determine the reason for the failure. If you can fix the problem, do so
and rerun the script. If you cannot fix the problem call IBM Software
Support.
manualDeploy_3. Copy has been successfully completed.
The files have been successfully copied to the appropriate directories.
manualDeploy_4. Making <platformDirectoryName> ...
The script is creating one of the platform directories for the agent files.
Nine of these messages are displayed to show the progress of the
command.
For example, this command would result in the following contents for
<agentFilesDirectory>\aix:
4. Package the files: Zip or tar the files in each platform directory that you need
to use. If one or more directory refers to a platform that you do not intend to
use, you can delete it (the original files are still in the product).
Note: On Windows platforms you do not need to include the directory
pdc_deploy and its contents, as this is only required for the option to
deploy agents using Windows logon scripts.
Steps 2 through 4 need only normally be run once, after which you can use the
zipped or tarred files as many times as you like. Attention: If for any reason you change any of the agent files, steps 2 through
4 must be repeated, or you will not be distributing the updated files.
5. Distribute the package: Distribute the zipped or tarred files to the node where
you want to install the agent, using ftp, for example.
6. Log on to target node: Log on to the target node with administrator (Windows)
or root (UNIX) rights. In a command line window, change to the
<NODE_INST_DIR>\<OS_FOLDER> directory on the target node (for example, cd
c:\agent files\win32).
Agent deployment: installagent
146 IBM Tivoli License Manager: Planning, Installation, and Configuration
Note: If you are deploying the agent on a Windows node, ensure that the
Windows Services Administrative Tool window is closed before running
the command.
7. Run the command: From the <NODE_INST_DIR>\<OS_FOLDER> directory, run the
installagent command with the appropriate parameters. See “Parameters of the
installagent command.”
Note: On Windows nodes, if the installagent command finds that GSKit is
already in use, it cannot complete the installation until the computer is
rebooted. It creates a file in the agent’s directory called
reboot_needed.txt in which it stores this requirement by setting a
variable called GSKFilesLocked to the value 1. A message is displayed
informing the user that a reboot is required. The presence of this variable
in this file prevents the agent from starting. When the computer is
rebooted, and the GSKit files are unlocked, the installation of the agent is
completed, and the file is deleted.
The command creates a trace file. See the chapter on installation tracing in the IBM
Tivoli License Manager: Problem Determination for a full description.
Parameters of the installagent command
The installagent command has the following parameters. You can code them
directly in the command line (“Specifying installagent parameters in the command
line” on page 149) or put them in a file that contains the parameters and their
values (“Specifying installagent parameters in a file” on page 150).
If your values for any of the installagent parameters include non-ASCII characters
that need to be in UTF-8 encoding, you should use a UTF-8 editor to create the
file.
It is important that the values of the following parameters are written correctly.
Even a minor mismatch between the values supplied to the command and the
matching values at the runtime server cause the deployment to fail.
sourcePath
The location to which you copied the agent files from the runtime server.
division
The name of the division to which the new agent is assigned. This division
must be already set up for the runtime server to which the agent is to be
attached.
nodeTag
The computer label of the node. This is free-format text and represents your
way to recognize the agent. It is not case sensitive, and all lower-case
characters are converted to upper-case when the agent is registered. You can
use the following variables to make up all or part of the node tag:
%SERIAL
The serial number of the computer.
%TYPE
The type of hardware.
%MODEL
The hardware model.
Agent deployment: installagent
Chapter 4. Deploy agents 147
%VENDOR
The name of the hardware producer.
%HOST
The host name of the computer.
These variables can be used on all platforms, although on some platforms
certain values may be null. Thus you are advised to combine variables always
with either %SERIAL or %HOST, in order to ensure a non-duplicate computer
label.
Notes:
1. If you want to use the % character as part of the node tag you should be
aware that if the text following the percent sign matches one of the above
variables, the variable will be used instead of your text. For example, if you
try and deploy an agent on a node with a host name of ″johndoe″ and you
want to give it a label of ″50%hosted″, it will be registered as
″50JOHNDOEED″.
2. If you want to include one of these variables when you issue the
installagent command at the command line you must type the ″%″ as
″%25″. Thus, for example, if you want to issue the installagent command
with the node tag ″%SERIAL″, you should type ″%25SERIAL″.
server
The host name or IP address of the runtime server that this agent is to use.
port
The runtime server’s non-secure port. The typical value is 80, but you must
determine from the runtime server’s Web server settings which is the correct
value to use. Even if you are using SSL, a value must be entered.
secure_port
The runtime server’s SSL port. The typical value is 443, but you must
determine from the runtime server’s Web server settings which is the correct
value to use. Even if you are not using SSL, a value must be entered.
uri
This must be set to /slmruntime/service.
organization
The name of the organization. This must be the same organization as that of
the runtime server to which the agent is to be attached.
useProxy
Valid values are: y or Y (use proxy) and n or N (do not use proxy).
proxyName
Enter the proxy host name or IP address of the server. You must supply a
value even if useProxy is set to N, but that value is ignored. For example, you
can enter ″none″.
proxyPort
Enter the proxy port number of the server. This must be a number greater than
0. You must supply a value even if useProxy is set to N, but that value is
ignored. For example, you can enter ″9999″.
security_level
This determines whether SSL is or is not used for the initial connection
between the agent and the runtime server. After the initial contact, the agent
runs a service which downloads the appropriate parameters for all agents in its
division, and the downloaded values overwrite the values supplied to the
Agent deployment: installagent
148 IBM Tivoli License Manager: Planning, Installation, and Configuration
installagent command. Permitted values are:
1 Insecure: HTTP is used for all communications (default). The Web server
where the runtime server is installed must have an HTTP service
enabled, and port must have the correct value for the runtime server.
4 Secure: HTTPS is used for all communications. The HTTP server where
the runtime server is installed must have an HTTPS service enabled.
gskit
The name of the authentication software used by the agent. Look in the
package of agent files you created in step 4, and use the name of the file that
commences with the string ″gsk″. For example, for Windows platforms, this
parameter would have the value gsk7bas.exe.
certificate
The name of the authentication certificate used by the agent. This must be set
to cert.arm.
scanner
The name of the scanner used by the agent. This must be set to wscanner.tar.
processor_type
Supply this field only when deploying a node on Linux390. Specify if the
Linux390 image is running on CP or IFL processors. Permitted values are
CP
Supply if the Linux390 image is running on CP processors
IFL
Supply if the Linux390 image is running on IFL processors
shared_pool_capacity
Supply this field only when deploying a node on Linux390. If the Linux390
image is configured to share processors, specify the total number of shared
processors (CP or IFL, as appropriate, not both) in the CEC. Enter zero if no
shared processors are used by this image.
system_active_processors
Supply this field only when deploying a node on Linux390. Specify the total
number of processors (CP or IFL, as appropriate, not both) in the CEC.
Specifying installagent parameters in the command line
To specify the parameters of the installagent command directly, enter the
command as follows:
Linux390 nodes
installagent sourcePath division nodeTag server port secure_port uri organization
useProxy proxyName proxyPort security_level gskit certificate scanner
processor_type shared_pool_capacity system_active_processors
Other nodes
installagent sourcePath division nodeTag server port secure_port uri organization
useProxy proxyName proxyPort security_level gskit certificate scanner
All parameters are required, and they are positional, so they must be entered in the
order shown (values not required must be given dummy values). If any of the
parameters include blank characters they must be coded as ″%20″.
To see a list of the parameters at the command line, type:
Agent deployment: installagent
Chapter 4. Deploy agents 149
installagent help
Note: If you want to include a variable in the nodeTag parameter when you issue
the installagent command at the command line you must type the ″%″ as
″%25″. Thus, for example, if you want to issue the installagent command
with the node tag ″%SERIAL″, you should type ″%25SERIAL″.
Specifying installagent parameters in a file
If you wish, you can create a file that contains all the parameters and their values.
If your values for any of the installagent parameters include non-ASCII characters
that need to be in UTF-8 encoding, you should use a UTF-8 editor to create the
file. The file should be stored in the <NODE_INST_DIR>\<OS_FOLDER> directory.
The syntax of the parameters in the file is as follows:
<variableName> = <variableValue>
Where: <variableName> and <variableValue> are the field names and values
discussed above and exampled below. There can be spaces either side of the equals
sign, but each parameter cannot be split over more than one line.
Enter the parameters in the file as in the following examples:
Linux390 nodes
division = Sales
nodeTag = sales291
server = rome_runtime.ibm.com
port = 80
secure_port = 443
uri = /slmruntime/service
organization = IBM
useProxy = y
proxyName = proxy.ibm.com
proxyPort = 3129
security_level = 4
gskit = gsk7bas-7.0-2.5.s390.rpm
certificate = cert.arm
scanner = wscanner.tar
processor_type = CP
shared_pool_capacity = 5
system_active_processors = 10
Other nodes
division = Sales
nodeTag = sales291
server = rome_runtime.ibm.com
port = 80
secure_port = 443
uri = /slmruntime/service
organization = IBM
useProxy = y
proxyName = proxy.ibm.com
proxyPort = 3129
security_level = 4
gskit = gsk7bas.exe
certificate = cert.arm
scanner = wscanner.tar
Note: This example is for a Windows node.
Notes:
1. The file does not need to contain the <sourcePath> parameter because you
supply it when you issue the installagent command.
Agent deployment: installagent
150 IBM Tivoli License Manager: Planning, Installation, and Configuration
2. The parameter names are not case sensitive.
In this case the format of the installagent command is:
installagent <sourcePath> –f <fileName>
where <fileName> is the name of the parameter file that you have created.
Examples of installagent command use
The following are two examples of how to use the installagent command to
deploy agents manually, one with and one without a proxy server between the
agents and the runtime server.
Example of installagent command without proxy
In this example, the command below deploys the agent on a Windows node with
the following characteristics:
division Sales
nodeTag sales291
server rome_runtime.ibm.com
port 80
secure_port 443
organization IBM
useProxy n
proxyName none
proxyPort 9999
security_level 1
gskit gsk7bas.exe
certificate cert.arm
scanner wscanner.tarinstallagent E:\agent_files Sales sales291 rome_runtime.ibm.com 80
443 /slmruntime/service IBM N none 9999 1 gsk7bas.exe cert.arm wscanner.tar
Example of installagent command with proxy
In this second example, the command below deploys the agent on the same node
but with different characteristics, including the requirement to use a proxy server:
division Sales
nodeTag sales291
server rome_runtime.ibm.com
port 80
secure_port 443
organization IBM
useProxy y
proxyName proxy.ibm.com
proxyPort 3129
security_level 4
gskit gsk7bas.exe
certificate cert.arm
scanner wscanner.tarinstallagent E:\agent_files Sales sales291 rome_runtime.ibm.com 80 443
/slmruntime/service IBM y proxy.ibm.com 3129 4 gsk7bas.exe cert.arm wscanner.tar
Agent deployment: installagent
Chapter 4. Deploy agents 151
Example of installagent command on Linux390 with proxy
In this third example, the command below deploys the agent on a Linux390 node
but also includes the requirement to use a proxy server:
division Sales
nodeTag sales945
server rome_runtime.ibm.com
port 80
secure_port 443
organization IBM
useProxy y
proxyName proxy.ibm.com
proxyPort 3129
security_level 4
gskit gsk7bas-7.0-2.5.s390.rpm
certificate cert.arm
scanner wscanner.tar
processor_type CP
shared_pool_capacity 5
system_active_processors 10installagent E:\agent_files Sales sales291 rome_runtime.ibm.com 80 443
/slmruntime/service IBM y proxy.ibm.com 3129 4 gsk7bas-7.0-2.5.s390.rpm
cert.arm wscanner.tar CP 5 10
Deploying agents using Tivoli Configuration Manager
This option is available only if you want to deploy the agent software on
endpoints in a Tivoli management region (Tivoli region) where you are using Tivoli
Configuration Manager.
Details of the versions of Tivoli Configuration Manager and Tivoli Management
Framework that can support this distribution, and any other prerequisites, are
provided in “Prerequisites for agent deployment using Tivoli Configuration
Manager” on page 48.
The description of this option that follows requires that you are a knowledgeable,
experienced user of Tivoli Configuration Manager.
To enable this option, Tivoli License Manager has provided software package
blocks for each operating system family, which install and customize the agent
software, and register it with the appropriate runtime server. Having software
package blocks for each operating system avoids downloading unnecessary
software to the endpoints. The software package blocks contain parameters for the
variable information (division, runtime server address, proxy address, and so on),
so that the blocks do not need to be built. You add the variable information and
then distribute the blocks to your endpoints using the standard Software
Distribution facilities and interfaces.
You cannot deploy agents to all of your endpoints in one distribution. Each
distribution must deploy the agent on endpoints that have the following common
characteristics:
v Same organization
v Same division
v Same runtime server
v Same operating system
Agent deployment: installagent
152 IBM Tivoli License Manager: Planning, Installation, and Configuration
How you achieve this within Software Distribution depends very much on the
Tivoli Management Framework environment you have created. You need to find
the easiest way to identify each group of endpoints with these common
characteristics, and then distribute them.
Let us assume that you have set up one Tivoli region for your whole organization,
Acme Company. Within Tivoli License Manager, you have also set up one
organization for your whole organization, called ″Acme Company.″ Within your
Tivoli region you have created a policy region for each administrative division of
your organization. You have also set up the same divisions in Tivoli License
Manager. Within each policy region (division) you have already created, for other
uses, profile managers for each operating system, each containing the appropriate
subscribers. Thus, for example, within the Sales division policy region you have a
policy manager for Windows 2000, containing all the subscribers (endpoints) where
Windows 2000 is installed.
You now have to make a decision. Not all of the subscribers in the Windows 2000
policy manager will be using the same runtime server. Some of them are at head
office, and will use the head office runtime server, while some are at the three
regional offices, each of which has been supplied with its own runtime server. You
have two options: either you create separate policy managers for each runtime
server for each operating system, each containing just the appropriate subscribers,
or you choose to select the subscribers for each distribution at distribution time. In
this scenario, you choose the latter option.
In this scenario, the steps to be taken are as follows:
1. Select a policy region: Open the policy region panel for the Sales region:
The policy region panel shows the profile managers you have already set up
for other purposes.
2. Create software package-type profile: Open the WindowsPM profile manager
(as this is a Windows 2000 scenario), and create a software package-type
profile. In this scenario it is called TLM_Agent^1.0.
Agent deployment: using Tivoli Configuration Manager
Chapter 4. Deploy agents 153
3. Import the platform-dependent software package block: Import the Tivoli
License Manager agent software package block for Windows (as this is a
Windows 2000 scenario). It is called winagent.spb and can be found in SPB
CD1. The generic name for the SPB is <platform>agent.spb, and they are
found in one of the SPB CDs, as follows:
Software Package Block CD (Windows, AIX, HP/UX, and SUN)
AIX aixagent.spb
Hpux hpuxagent.spb
Solaris sunagent.spb
Win32 (Windows) winagent.spb
Software Package Block CD (Linux, OS/400)
Linux linuxagent.spb
Linux390 linux390agent.spb
LinuxPPC linuxppcagent.spb
OS400 (OS/400)
os400agent.spb
In each of the platform sub-directories you will find an SPB for the server and
the agent.
Agent deployment: using Tivoli Configuration Manager
154 IBM Tivoli License Manager: Planning, Installation, and Configuration
When you have finished, the profile manager now contains the profile with
the agent software package block in it:
4. Add SSL certificate to software package block: If you want the agents
involved in this distribution to use SSL, and you want them to use a
certificate that you have purchased or generated, you will need to substitute
Agent deployment: using Tivoli Configuration Manager
Chapter 4. Deploy agents 155
this certificate for the default certificate in the software package block. The
default certificate is supplied for testing purposes only. It must not be used, as it
is insecure.
The easiest way to do this substitution is to open the software package block
with a compression/decompression tool (for example, WinZip), and replace
the SSL certificate. Replace the file cert.arm with your own certificate, which
you have created as a base64-encoded ASCII file, also called cert.arm.
Note: The same result can also be achieved using the Convert option of
software distribution to open and then close the software package
block. However, this option must not be used with the software
package block for OS/400.
5. Select the subscribers to distribute: Select the Windows profile to be
distributed:
Select the subscribers that are in the head office location and thus that are
appropriate for the head office runtime server.
6. Supply variable information: When you have selected the subscribers, you
are asked to enter the variable parameters appropriate to this group of
subscribers:
Agent deployment: using Tivoli Configuration Manager
156 IBM Tivoli License Manager: Planning, Installation, and Configuration
The parameters to enter differ, according to the platform:
Default variables for all platforms except OS/400
The parameters are as follows (the order they are presented on the
screen is determined by Tivoli Configuration Manager, and can be
dynamic – accordingly, the parameters are presented here in
alphabetic order):
divisionName
The division name (in this case it corresponds to the name of
the selected policy region: Sales Division)
nodetag
This is free-format text and represents your way to recognize
the agent. It is not case sensitive, and all lower-case characters
are converted to upper-case when the agent is registered. If
you are distributing to a specific node you can enter the actual
nodetag of that node. Otherwise, let this take the default
value, which generates a nodetag from the environment
variables at the target node. You can use the following
variables to make up all or part of the nodetag:
%SERIAL
The serial number of the computer.
%TYPE
The type of hardware.
%MODEL
The hardware model.
Agent deployment: using Tivoli Configuration Manager
Chapter 4. Deploy agents 157
%VENDOR
The name of the hardware producer.
%HOST
The host name of the computer.
These variables can be used on all platforms, although on
some platforms certain values may be null. Thus you are
advised to combine variables always with either %SERIAL or
%HOST, in order to ensure a non-duplicate nodetag.
Note: If you want to use the % character as part of the
nodetag you should be aware that if the text following
the percent sign matches one of the above variables, the
variable will be used instead of your text. For example,
if you try and register an agent on a node with a host
name of ″johndoe″ and you want to give it a nodetag of
″50%hosted″, it will be registered as ″50JOHNDOEED″.
organization
The name of the organization (in this case Acme Company)
port The port on the runtime server used for communication. The
permitted values depend on the value of startupMode:
startupMode = ssl
You should set this field to the port number of the
runtime server used for HTTPS communications.
startupMode = nossl
You should set this field to the port number of the
runtime server used for HTTP communications.
In this example, the value of 80 has been supplied.
proxyName
If useProxy is y, defines the network address of the proxy
server.
proxyPort
If useProxy is y, defines the port of the proxy server.
runtimeAddress
The host name or IP address of the runtime server that this
agent is to use (in this case it corresponds to the address of
the head office runtime server: HO_runtime.domain.com)
startupMode
Whether you want the initial contact between the agent and
the runtime server to use SSL, or not (subsequent
communications are determined by the value of the security
level for its division that the agent downloads from the
runtime server). Permitted values are:
ssl Defines that the initial communication between the
agents in this distribution and their runtime server
uses SSL. If this is chosen, when the installagent
command is run on the target node, the following
values are provided for the port and secure_port
parameters to the command:
Agent deployment: using Tivoli Configuration Manager
158 IBM Tivoli License Manager: Planning, Installation, and Configuration
port 80
secure_port The value of the port field provided
here.
nossl Defines that the initial communication between the
agents in this distribution and their runtime server
does not use SSL. If this is chosen, when the
installagent command is run on the target node, the
following values are provided for the port and
secure_port parameters to the command:
port The value of the port field provided
here.
secure_port 443
In the above example screen, the value of nossl has been
supplied.
target_dir
The name of the directory on the endpoint that is used by the
software package block to unpack its file images (in this case
taking the default of the local computer’s temporary directory)
useProxy
Specifies whether the runtime is protected by a proxy server
(in this case taking the default of n)
Additional default variables for Linux 390
processor_type
Supply this field only when deploying a node on Linux390.
Specify if the Linux390 image is running on CP or IFL
processors. Permitted values are
CP
Supply if the Linux390 image is running on CP processors
IFL
Supply if the Linux390 image is running on IFL processors
shared_pool_capacity
Supply this field only when deploying a node on Linux390. If
the Linux390 image is configured to share processors, specify
the total number of shared processors (CP or IFL, as
appropriate, not both) in the CEC. Enter zero if no shared
processors are used by this image.
system_active_processors
Supply this field only when deploying a node on Linux390.
Specify the total number of processors (CP or IFL, as
appropriate, not both) in the CEC.
Default variables for OS/400
The parameters are as follows (the order they are presented on the
screen is determined by Tivoli Configuration Manager, and can be
dynamic – accordingly, the parameters are presented here in
alphabetic order):
agentConfig.divisionName
The division name.
Agent deployment: using Tivoli Configuration Manager
Chapter 4. Deploy agents 159
agentConfig.nodeTag
This is free-format text and represents your way to recognize
the agent. It is not case sensitive, and all lower-case characters
are converted to upper-case when the agent is registered. If
you are distributing to a specific node you can enter the actual
nodetag of that node. Otherwise, let this take the default
value, which generates a nodetag from the environment
variables at the target node. You can use the following
variables to make up all or part of the nodetag:
%SERIAL
The serial number of the computer.
%TYPE
The type of hardware.
%MODEL
The hardware model.
%VENDOR
The name of the hardware producer.
%HOST
The host name of the computer.
These variables can be used on all platforms, although on
some platforms certain values may be null. Thus you are
advised to combine variables always with either %SERIAL or
%HOST, in order to ensure a non-duplicate nodetag.
Note: If you want to use the % character as part of the
nodetag you should be aware that if the text following
the percent sign matches one of the above variables, the
variable will be used instead of your text. For example,
if you try and register an agent on a node with a host
name of ″johndoe″ and you want to give it a nodetag of
″50%hosted″, it will be registered as ″50JOHNDOEED″.
agentConfig.organizationName
The name of the organization.
agentConfig.proxyAddress
If agentConfig.useProxy is y, defines the network address of
the proxy server.
agentConfig.proxyPort
If agentConfig.useProxy is y, defines the port of the proxy
server.
agentConfig.runtimeAddress
The host name or IP address of the runtime server that this
agent is to use.
agentConfig.runtimePort
The port on the runtime server used for insecure
communications.
agentConfig.sslPort
The port on the runtime server used for secure
communications (a value must be supplied, even if SSL is not
to be used at the agent – in this case you can use any numeric
Agent deployment: using Tivoli Configuration Manager
160 IBM Tivoli License Manager: Planning, Installation, and Configuration
value).
agentConfig.startupMode
Whether you want the initial contact between the agent and
the runtime server to use SSL, or not (subsequent
communications are determined by the value of the security
level for its division that the agent downloads from the
runtime server). Permitted values are:
ssl Defines that the initial communication between the
agents in this distribution and their runtime server
uses SSL.
nossl Defines that the initial communication between the
agents in this distribution and their runtime server
does not use SSL.
agentConfig.useProxy
Specifies whether the runtime is protected by a proxy server.
setLang.languageCode
This value can be left blank if the primary language used by
the operating system of your computer is among those listed
below.
If the primary language of the system is not one of those
listed, specify a language code from the list below which is
already installed as a secondary language on your system.
If none of the languages available on your system are in the
list below, you must install one of them as a secondary
language before deploying the OS/400 agent, specifying here
the language you have installed.
The supported languages are the following:
″2924″ English
″2928″ French
″2929″ German
″2932″ Italian
″2962″ Japanese
″2986″ Korean
″2980″ Portuguese (Brazil)
″2989″ Simplified Chinese
″2931″ Spanish
″2987″ Traditional Chinese
For example, to choose English language, use the following:
-W setLang.languageCode="2924"
setLang.CCSID
This defines the CCSID, which is the native character
encoding used on the OS/400 node. It is required to enable
Tivoli Configuration Manager to translate the response file
from ASCII to the native CCSID of the target node.
The default value is 00037 which is the code for EBCDIC in
USA, Canada, Netherlands, Portugal, Brazil, New Zealand,
and Australia. Other countries can have different CCSIDs. This
parameter is required for the correct processing of the silent
installation. For a complete list of CCSID see the following
Web site:
Agent deployment: using Tivoli Configuration Manager
Chapter 4. Deploy agents 161
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/nls/rbagsccsidcdepgscharsets.htm
7. Distribution: Click Set & Close and the distribution commences.
8. Monitor progress: Use the facilities of Tivoli Configuration Manager and
Tivoli Management Framework to monitor the progress of the distribution.
Notes:
a. If you are deploying the agent using Tivoli Configuration Manager on a
Windows node, and the Windows Services Administrative Tool window is
not closed when the installagent command is run, the agent is installed
but might not be registered as a service. If it is registered as a service, it
might not have been started. See IBM Tivoli License Manager: Problem
Determination for details of problem resolution when deploying the agent.
b. On Windows nodes, if the deployment operation finds that GSKit is
already in use, it cannot complete the installation until the computer is
rebooted. It creates a file in the agent’s directory called reboot_needed.txt
in which it stores this requirement by setting a variable called
GSKFilesLocked to the value 1. A message is displayed informing the user
that a reboot is required. The presence of this variable in this file prevents
the agent from starting. When the computer is rebooted, and the GSKit
files are unlocked, the installation of the agent is completed, and the file is
deleted. 9. Repeat for all runtime servers with the same operating system: Repeat steps
5 to 8 for all runtime servers with the same operating system.
10. Repeat for all operating system in the same division: Repeat steps 2 to 9 for
all operating systems in the same division.
11. Repeat for all divisions in the same organization:Repeat steps 1 to 10 for all
divisions in the organization.
Your setup of Tivoli regions, policy regions and profile managers might not match
that shown in the scenario, but the key point to remember in planning the
deployment of your agents with Tivoli Configuration Manager is that the smallest
unit of distribution is a group of endpoints that share the same runtime server,
operating system, division, and organization.
Deploying agents to UNIX nodes using SSH and RSH
To deploy agents on UNIX nodes, you can use the Tivoli License Manager agent
deployment tool, which leverages any existing remote shell (RSH) or secure shell
(SSH) networks to deploy the agent to one or more remote nodes. The tool
distributes the required files to the selected nodes, and then runs the installagent
command to install the agent and start it. See “Deploying the agent manually
(installagent command)” on page 145 for full details of how the installagent
command works.
Although the tool deploys agents to UNIX nodes, it is run from a Windows
computer, where you should make available the Tivoli License Manager server and
agent install CD image (original CD or a copy). For details of the prerequisites, see
“Prerequisites for agent deployment on RSH and SSH UNIX networks” on page 50.
The behavior of the tool depends on the type of network you have. See “Using
SSH or RSH for UNIX nodes” on page 49 for an explanation of the options
available to you.
Agent deployment: using Tivoli Configuration Manager
162 IBM Tivoli License Manager: Planning, Installation, and Configuration
Attention: The distribution information for each node includes the node’s root
password. If you allow the agent deployment tool to use an RSH network, you run
the risk that the distribution information is intercepted, compromising the security
of the node.
The steps for making this deployment are as follows. Those steps that you only
need to do the first time you run the tool on any computer are indicated.
1. Copy tool: (first time only) Copy the agent deployment wizard to a
temporary directory on your hard disk. You should copy the following files,
maintaining their relative directory structure:
<CD_drive>\setup\agent\RSH-SSH\setupAgentRSH-SSH.jar
<CD_drive>\setup\agent\RSH-SSH\Win32\setupAgentRSH-SSH.exe
2. Obtain J2SSH libraries (first time only): This deployment method requires
you to obtain and build on the computer from which you want to run the
wizard, a set of libraries that allow the computer to operate as an SSH client.
For your information, the wizard has been tested using J2SSH-Lite from 3SP.
The steps to obtain their version of the appropriate files are as follows:
a. In a Web browser, navigate to the site of 3SP.
b. Locate the products page and select J2SSH-Lite.
c. Click Downloads.
d. Download the zip to an empty temporary directory (not the one where
you put the setup file).
e. Unpack the zip file.
f. Follow the instructions in the text file in the root of the unpacked zip to
build J2SSH-Lite.
g. Locate the following files in the j2ssh\lib and j2ssh\dist\lib directories
of the unpacked zip:
j2ssh-common.jar
commons-logging.jar
j2ssh-core.jar
h. Copy these three files into the directory where you copied the agent
deployment setup executable file.
Attention: DISCLAIMER This reference to a specific software item from a
third-party in no way endorses that product, or can be construed to imply
that IBM will make available that software item or support for that software
item.
3. Launch tool: Start the tool.
Note: If Windows Terminal Server is installed on the computer where you
want to run the setup file, or you are accessing another computer using
Windows Terminal Services, you must launch the tool as follows:
a. Select the Add/Remove Programs option from the Control Panel.
b. Click Add New Programs.
c. Click CD or Floppy, and the Install Program From Floppy Disk or
CD-ROM wizard window will open. Click Next.
d. Click Browse, navigate to the setup file on your disk (where you
copied the files in step 1 – do not select the version on the CD), and
select it by highlighting it and clicking Open.
e. Click Finish to exit from the wizard and run the setup file.
Agent deployment: on UNIX nodes using SSH/RSH
Chapter 4. Deploy agents 163
This procedure ensures that the Windows computer is in install mode
when the setup file is launched.
The same objective can also be achieved by changing into install mode
manually, and then back again after the agent deployment is complete.
To change into install mode manually, issue the command change user
/install from a Windows command line. Then issue the command to
run the tool setup file. After the installation has completed, you must
issue the command change user /execute to return to execute mode.
Attention: A command line window is opened prior to the display of the
first wizard panel. Do not close this window.
4. Select language: Select the language in which the tool panels should appear,
and click OK.
5. Welcome panel: The welcome panel is now displayed. Click Next to continue.
6. Install path (first time only): The following panel is displayed:
Supply the directory name where you want the agent deployment tool to
install the agent files on the computer where you are running the tool.
Click Next.
7. Define SSL certificate to use: The following panel is displayed:
This panel enables you to determine the SSL certificate to be used at the target
nodes of the distribution.
Agent deployment: on UNIX nodes using SSH/RSH
164 IBM Tivoli License Manager: Planning, Installation, and Configuration
If you want to select a certificate that you have created or purchased, browse
to it or enter its path. The certificate must have the name cert.arm.
If you select the option to use the embedded test certificate, you should be
aware that this is the certificate issued with the product for test purposes only,
and it should not be used in a ″live″ situation, as it is distributed to all
customers, and is thus not secure.
8. Add node data: The following screen is displayed:
You use this panel to add node data. The top half of the screen enables you to
identify the topology of your Tivoli License Manager environment. By
selecting various combinations of one organization, one division and one
runtime server, you pre-determine the values to be used in the bottom half of
the panel, where you identify the individual agents.
Attention: In this panel you identify organizations, runtime servers,
divisions, node names, port numbers and passwords, all of which already
exist. There is some on-screen validation of your data to determine, for
example, that port numbers are numeric, but there is no check, for example, to
ensure that any organizations, divisions and runtime server addresses actually
exist. If you make a mistake it is only revealed when you make the
distribution and the agent plug-in fails because the data is incorrect.
There are three basic scenarios:
v Create topology and nodes. For this you need to know the required
information about all of the nodes to which you want to distribute the
agent. See “Create topology and nodes” on page 166.
v Import topology and create nodes. You can choose to export the topology
of your Tivoli License Manager environment from the administration server,
import it into the tool and then create the nodes, based on that topology.
You can both import and create topology for the same distribution. You can
import a certain topology and then use the tool to change it on the screen
before creating the nodes. See “Import topology and create nodes” on page
169.
Agent deployment: on UNIX nodes using SSH/RSH
Chapter 4. Deploy agents 165
v Import nodes. If you have a database containing the relevant details of
your nodes that can be exported into XML format, you can import the
details of these nodes. See “Import nodes” on page 169.
The tool enables you to use any combination of these methods.
Create topology and nodes
Take the following steps:
a. Add organizations: Click Add under the Organization heading,
type the name of an organization and click OK. If you want to
remove an organization that you have added, select it and click
Remove.
Note: If you remove an organization, you also remove the
divisions and runtime servers associated with it.
b. Add divisions: Select the appropriate organization. Click Add
under the Division heading, type the name of a division and click
OK. If you want to remove a division that you have added, select
it and click Remove.
c. Add runtime servers: Select the appropriate organization. Click
Add under the Runtime address heading, type the address (host
name or IP address) of a runtime server and click OK. If you want
to remove a runtime server that you have added, select it and click
Remove.
When you have finished, the panel looks something like this:
d. Add nodes: For each combination of the topology elements, add
the nodes, as follows:
1) Select topology: Select one organization, one division, and one
runtime server. Click the Add button at the foot of the Nodes
sub-panel. A row is displayed in the sub-panel with the
organization, division, and runtime server filled in.
2) Fill in values: Click on each of the blank fields in the row, and
add the appropriate data. The fields are:
Agent deployment: on UNIX nodes using SSH/RSH
166 IBM Tivoli License Manager: Planning, Installation, and Configuration
Node The host name or IP address of the node in your
network. This is needed to locate the node. This value
is not used for the computer label in the registration of
the agent. Instead, the agent will be given a computer
label of <%SERIAL><%VENDOR>, where
<%SERIAL><%VENDOR> are generated from
environment variables at the target node, as follows:
%SERIAL
The serial number of the computer.
%VENDOR
The name of the hardware producer.
Port The non-SSL port used by the runtime server. If the
runtime server does not listen on a non-SSL port, you
must still supply a dummy value.
SSL port
The SSL port used by the runtime server. If you do not
want to implement SSL between this agent and the
runtime server, you must still supply a dummy value.
Startup mode
This determines whether SSL is or is not used for the
initial connection between the agent and the runtime
server. After the initial contact, the agent runs a service
which downloads the appropriate parameters for all
agents in its division, and the downloaded values
overwrite the values supplied to the installagent
command. Permitted values are:
NO SSL
Insecure: HTTP is used for all communications
(default). The Web server where the runtime
server is installed must have an HTTP service
enabled.
SSL Secure: HTTPS is used for all communications.
The HTTP server where the runtime server is
installed must have an HTTPS service enabled.
OS Select the appropriate operating system from the
pull-down. The choices are:
aix
hpux
linux
linux_ppc
linux_rel2.1
linux_s390
sun32
sun64
Password
The root password of the node, needed for a secure
(SSH) distribution. This is a required field. If you are
certain that the distribution is only going to be made in
a non-secure way (RSH) a dummy password can be
Agent deployment: on UNIX nodes using SSH/RSH
Chapter 4. Deploy agents 167
used.
Processor Type
If you have selected Linux_s390 as OS, you must
supply this field; otherwise the value ″n/a″ will be
displayed and you will not be able to enter a value.
Specify if the Linux390 image is running on CP or IFL
processors. Permitted values are
CP
Supply if the Linux390 image is running on CP
processors
IFL
Supply if the Linux390 image is running on IFL
processors
Shared pool capacity
If you have selected Linux_s390 as OS, you must
supply this field; otherwise the value ″n/a″ will be
displayed and you will not be able to enter a value.
If the Linux390 image is configured to share processors,
specify the total number of shared processors (CP or
IFL, as appropriate, not both) in the CEC. Enter zero if
no shared processors are used by this image.
Active processors
If you have selected Linux_s390 as OS, you must
supply this field; otherwise the value ″n/a″ will be
displayed and you will not be able to enter a value.
Specify the total number of processors (CP or IFL, as
appropriate, not both) in the CEC.
The panel should now look something like the following (in this
case the user has already clicked Add to add the second node).
To remove a node you have added, select it and click Remove. Go
to step 9.
Agent deployment: on UNIX nodes using SSH/RSH
168 IBM Tivoli License Manager: Planning, Installation, and Configuration
Import topology and create nodes
Import the topology that is required for the nodes where you want to
deploy agents, and then create the nodes. The process is as follows:
a. Using the dataexp XML –topology output_directory command on
the administration server you create a file that contains an XML
definition of the topology of your Tivoli License Manager
environment. Full details of the command and how to enable the
command line are given in IBM Tivoli License Manager:
Administration.
b. Import that XML file by clicking Import in the Add node data
panel, and then browsing to locate and import the file.
The topology details are added to the upper half of the panel.
c. Create the nodes that belong to each branch of the topology, as
already described in step 8d of “Create topology and nodes” on
page 166.
Go to step 9.
Import nodes
This process requires that you have a database where you hold details
of nodes where you want to deploy agents. You need to be able to
export the node data from the database in XML format. The structure
of the XML file is shown in Appendix F, “UNIX agent deployment
wizard import file formats,” on page 303. It is quite likely that your
database does not have all the information required to create the file
with entries for all of the elements, for example, runtime server
address. In this case you can chose to edit the missing information
into the file with a text or XML editor, or import the file as it is and
add the information in the tool. It is not possible to combine the
topology import and the agent import for the same nodes. After you
have imported nodes, you can remove nodes, or change the imported
values, field-by-field, node-by-node.
The process is as follows:
a. Extract the node data from your database.
b. Edit the node data if necessary.
c. Click Import in the tool, browse to the file of node data and
import it.
d. Check the data is complete (all fields are required). 9. When you are sure that all of the data in the lower half of the panel is
complete and correct, click Next.
10. A summary panel is displayed, similar to the following:
Agent deployment: on UNIX nodes using SSH/RSH
Chapter 4. Deploy agents 169
If you are running the tool for the first time, information is displayed about
the space occupied by the agent work files.
A table is also displayed on the panel showing the distribution that will be
made. Check that the information is correct and click Next.
11. The tool installs the agent work files and then commences the distribution. A
summary of the results of the distribution is displayed, along with the name
and location of the log file where full details of the results of the distribution
and of the launch of the installagent command on the agent, are to be found.
Deploy agents using Windows logon scripts
Agents can be deployed on Microsoft Windows nodes using logon scripts. The
administrator sets up each domain such that when a user logs on, the Windows
Domain Controller automatically runs a script. The script checks to see whether
there is an agent on the node from which the user has logged on, and if there is,
whether it is the same version. If the script finds no agent or a back-level agent, it
installs the agent.
For this procedure to work, the user whose node is to be registered must log on
with administrator rights.
A log is maintained at the Windows Domain Controller of the installation attempts.
You would normally choose to run the following procedure for each unique
combination of organization, division and runtime server in your environment.
This is because you will define a single configuration file that drives the agent
deployment, and which uses values for those three entities for all the agents in the
domain. However, the possibility exists to define configuration files for individual
nodes (see step 9 on page 172 for details).
Most of the steps in this procedure should be performed by the Windows Domain
Administrator, as the steps require specialist knowledge and access to the domain.
The details are as follows:
Agent deployment: on UNIX nodes using SSH/RSH
170 IBM Tivoli License Manager: Planning, Installation, and Configuration
1. Log in: Log in to the Windows Domain Controller.
2. Set up NETLOGON shared directory: If one has not already been set up,
setup a NETLOGON shared directory. The directory should be not browsable,
with write permission for all users in the domain.
3. Optionally set up a shared directory for the log file: You can opt to log the
running of the scripts on the domain server, by setting up a shared directory
in which to store the logs. The directory should be not browsable, with write
permission for all users in the domain.
4. Access the runtime server: From the domain server, access the appropriate
Tivoli License Manager runtime server.
5. Locate the files to copy: The files that you need to copy come from the
runtime server. You should have assembled them by running the
manualDeploy script, as described in “Deploying the agent manually
(installagent command)” on page 145, and specifically in steps 2 on page 145
to 3 on page 145 of the procedure described therein. After running the script,
you will have created a directory structure containing all of the agent
deployment files for all platforms, including the Windows files that you need
to copy to the NETLOGON shared directory. The Windows files are located in
the following directory:
<agentFilesDirectory>\win32
Where <agentFilesDirectory> is the directory you chose when you ran the
manualDeploy command.
6. Copy the files: Copy the files and directories from the above directory to the
NETLOGON shared directory. After these files have been copied, the contents
of the NETLOGON shared directory should be as follows:
\pdc_deploy\profiles\default.conf
\pdc_deploy\getdt.exe
gethost.exe
getos.bat
printmsg.exe
sethostname.bat
tlm.bat
tlminstall.bat
cert.arm
codeset
gsk7bas.exe
installagent.exe
nls
tlmagent.exe
tlmlog.properties
Was_Cloning.bat
wscanner.tar
7. Define that users should use the logon script: Within the Domain User
Manager, for all users of the domain, select the User Environment Profile,
and on the Profile tab set the value of Logon script to ″pdc_deploy\tlm.bat″,
as follows:
Agent deployment: using Windows logon script
Chapter 4. Deploy agents 171
8. Configure tlm.bat: Edit the pdc_deploy\tlm.bat file in the NETLOGON
shared directory and set the values of the following environment variables:
set DOMAINSERVER=<DOMAIN_SERVER>
set NETLOGON_SHARE=<NETLOGON_SHARE>
set LOG_SHARE=<LOG_SHARE>
where:
<DOMAIN_SERVER>
The host name of the Microsoft Windows Domain Controller .
<NETLOGON_SHARE>
The name of the NETLOGON shared directory.
<LOG_SHARE>
If you have decided to use the option to create the log files on the
Windows Domain Controller (see step 3), provide the name of the
shared folder where the logs are to be stored. If you do not want to
exercise this option, change the variable to be blank.
Thus if your Windows Domain Controller is called windomain1, the
NETLOGON shared directory is called netlog and you do not want to save
logs, these variables would be as follows:
set DOMAINSERVER=windomain1
set NETLOGON_SHARE=netlog
set LOG_SHARE=
9. Customize default agent install parameters: If all of the nodes in this domain
have the same configuration parameters (apart from the Node tag), you can
supply the logon script with a single configuration file, containing the
common values. This file is called default.conf, and is stored in the profiles
directory. The default file has the following contents when you receive it:
# TLM agent deployment parameters
# Basic parameters
division=<division_name>
Agent deployment: using Windows logon script
172 IBM Tivoli License Manager: Planning, Installation, and Configuration
server=<server_name>
organization=<organization_name>
security_level=<security_level(1 or 4)>
# The following parameters rarely need to be changed
port=80
nodeTag=%serial%vendor
useProxy=no
proxyName=none
proxyPort=0
secure_port=443
# The following parameters are never to be changed
uri=/slmruntime/service
certificate=cert.arm
gskit=gsk7bas.exe
scanner=wscanner.tar
Edit this file so that all parameters contain valid values appropriate to your
agent deployment environment.
The syntax of the parameters in the file is as follows:
<variableName> = <variableValue>
Where: <variableName> and <variableValue> are the field names and values
discussed and exampled below. There can be spaces either side of the equals
sign, but each parameter cannot be split over more than one line.
If, however, within the domain, one or more nodes require different values
(for example, different divisions, runtime servers, use of SSL), you can create
individual files that apply to specific nodes. Create the individual files by
making a copy of default.conf in the profiles directory, giving the file the
name of <hostname>.conf, where <hostname> is the host name of the node in
question. Edit the <hostname>.conf file to customize the values in the file for
that node. When the logon script is running, any nodes that do not have a
<hostname>.conf file, use the values in default.conf.
The parameters are as follows:
division
The name of the division to which the agent is to belong.
server The address (host name or IP address) of the runtime server to which
the agent is to belong.
organization
The name of the organization to which the agent is to belong.
security_level
This determines whether SSL is or is not used for the initial
connection between the agent and the runtime server. After the initial
contact, the agent runs a service which downloads the appropriate
parameters for all agents in its division, and the downloaded values
overwrite the values supplied to the installagent command. Permitted
values are:
1 Insecure: HTTP is used for all communications (default). The
Web server where the runtime server is installed must have an
HTTP service enabled.
Agent deployment: using Windows logon script
Chapter 4. Deploy agents 173
4 Secure: HTTPS is used for all communications. The HTTP server
where the runtime server is installed must have an HTTPS
service enabled.
port The port on the runtime server used for communication in insecure
mode.
nodeTag
The name of the node on which you want to install the agent. The
default value is %serial%vendor. This is free-format text and represents
your way to recognize the agent. It is not case sensitive, and all
lower-case characters are converted to upper-case when the agent is
registered. You can use the following variables to make up all or part
of the nodeTag:
%SERIAL
The serial number of the computer.
%TYPE
The type of hardware.
%MODEL
The hardware model.
%VENDOR
The name of the hardware producer.
%HOST
The host name of the computer.
These variables can be used on all Windows platforms, although on
some platforms certain values may be null. Thus you are advised to
combine variables always with either %SERIAL or %HOST, in order to
ensure a non-duplicate nodeTag.
Note: If you want to use the % character as part of the nodeTag you
should be aware that if the text following the percent sign
matches one of the above variables, the variable will be used
instead of your text. For example, if you try and register an
agent on a node with a host name of ″johndoe″ and you want
to give it a nodeTag of ″50%hosted″, it will be registered as
″50JOHNDOEED″.
useProxy
Specifies whether the runtime is protected by a proxy server (y) or not
(n).
proxyName
If useProxy is y, enter the address (host name or IP address) of the
proxy server. Otherwise enter ″none″.
proxyPort
If useProxy is y, enter the port of the proxy server. Otherwise enter
any numeric value, for example ″0″.
secure_port
If security_level is 4, enter the port number used for SSL
communications. Otherwise enter any numeric value, for example
″111″.
All other keys in the file should be left with the default values.
Agent deployment: using Windows logon script
174 IBM Tivoli License Manager: Planning, Installation, and Configuration
10. Optionally monitor results: As with all forms of agent deployment, the
results can be monitored using the administration server GUI (Manage
Components � Agents) to look at agent details. In addition, if you have
enabled the logging option (see step 3), you can check the log files in this
directory to observe the results.
Note: If the deployment operation on a node finds that GSKit is already in
use, it cannot complete the installation until the computer is rebooted.
It creates a file in the agent’s directory called reboot_needed.txt in
which it stores this requirement by setting a variable called
GSKFilesLocked to the value 1. A message is displayed informing the
user that a reboot is required. The presence of this variable in this file
prevents the agent from starting. When the computer is rebooted, and
the GSKit files are unlocked, the installation of the agent is completed,
and the file is deleted.
Attention: If you implement a fix or upgrade that upgrades the agent code on
the runtime server, you must remember to upgrade the files on the Windows
Domain Controller, as well.
Install agents on OS/400
Agents can be deployed on iSeries nodes running OS/400 in the following ways:
v “Install the OS/400 agent from a Windows node”
v “Install the OS/400 agent on an iSeries node” on page 182
v “Saving and Restoring the agent to a different iSeries node” on page 183
Install the OS/400 agent from a Windows node
There are two ways to install an OS/400 agent from a connected Windows node:
v “Installing the agent interactively”
v “Installing the agent silently” on page 181
Installing the agent interactively
This uses a GUI that enables you to enter the required information interactively on
a series of panels.
1. Login Log in to the connected Windows node from where you want to install
an OS/400 agent as a user with administrator rights.
2. Locate the wizard: Navigate to the following directory:
<CD_drive>\setup\agent\OS400\Win32
3. Launch the wizard: Launch the following ISMP wizard:
setupAgentOS400.exe
Notes:
a. If you want to move the setup file from the CD on to disk before
launching it, you must move both the setup*.exe/bin and the
corresponding ../setup*.jar, and maintain their relative directory
structure.
b. If Windows Terminal Server is installed on the computer where you want
to run the setup file, or you are accessing another computer using
Windows Terminal Services, you must launch the wizard as follows:
Agent deployment: using Windows logon script
Chapter 4. Deploy agents 175
1) Select the Add/Remove Programs option from the Control Panel.
2) Click Add New Programs.
3) Click CD or Floppy, and the Install Program From Floppy Disk or
CD-ROM wizard window will open. Click Next.
4) Click Browse, navigate to the setupAgentOS400.exe file, and select it by
highlighting it and clicking Open.
5) Click Finish to exit from the wizard and run the setup file.
This procedure ensures that the Windows computer is in install mode
when the setup file is launched.
The same objective can also be achieved by changing into install mode
manually, and then back again after the agent deployment is complete. To
change into install mode manually, issue the command change user /install
from a Windows command line. Then issue the command to run the tool
setup file. After the installation has completed, you must issue the
command change user /execute to return to execute mode.
Attention: A command line window is opened prior to the display of the
first wizard panel. Do not close this window, and do not use other
applications while waiting for the wizard to initialize.
4. Login to OS/400 node: The following pop-up is displayed in the top left-hand
corner of the screen:
Attention: If, between starting the wizard and the display of the pop-up,
you switch to a different application, the pop-up is displayed behind all
current applications. To locate it use the Alt-Tab keys to list the open
applications and select the application with the Java logo and the title Signon
to the server.
Supply the following fields:
System
The name of the OS/400 node in the network
User ID
Supply the user ID of a user with sufficient rights to install programs.
Password
Enter the corresponding password. 5. Select language: Select the language to be used for the wizard and click OK.
The Welcome page is displayed.
6. View Welcome page: Press Next. The Setup Type panel is displayed:
Agent deployment: on OS/400
176 IBM Tivoli License Manager: Planning, Installation, and Configuration
7. Select Setup Type: Select the type of setup you want to use:
Typical
This installs the agent using default values for most of the fields
(details of these values are given in “Use the OS/400 agent install
wizard on a Windows computer connected to an OS/400 node” on
page 52).
Custom
This installs the agent, enabling you to customize all of the values.
Select the option you require and click Next.
8. If the primary language configured on the OS/400 node is not one of those
supported by Tivoli License Manager, the Language Selection Panel is
displayed (not shown here), asking you to select from a pull-down list one of
the supported languages for the agent to use. The language you select must
already be installed on the node as a secondary language. Click Next to
continue.
If you have selected a Custom installation go to step 10, otherwise, continue.
9. ″Typical″ install parameters: If you selected a Typical installation, the
following panel is displayed:
Supply the following parameters:
Agent deployment: on OS/400
Chapter 4. Deploy agents 177
Organization name
The name of the organization to which the agent is to belong.
Runtime server address
The address (host name or IP address) of the runtime server to which
the agent is to belong.
Division name
The name of the division to which the agent is to belong.
Details of the default values for the other agent fields are given in “Use the
OS/400 agent install wizard on a Windows computer connected to an OS/400
node” on page 52.
Click Next.
Go to step 12.
10. ″Custom″ install parameters: If you selected a Custom installation, the
following panel is displayed:
Supply the following parameters:
Organization name
The name of the organization to which the agent is to belong.
Runtime server address
The address (host name or IP address) of the runtime server to which
the agent is to belong.
Division name
The name of the division to which the agent is to belong.
Node tag
The name of the node on which you want to install the OS/400 agent.
The default value is the concatenation of the %SERIAL and the
%VENDOR variables. This is free-format text and represents your way
to recognize the agent. It is not case sensitive, and all lower-case
characters are converted to upper-case when the agent is registered.
You can use the following variables to make up all or part of the node
tag:
Agent deployment: on OS/400
178 IBM Tivoli License Manager: Planning, Installation, and Configuration
%SERIAL
The serial number of the computer.
%TYPE
The type of hardware.
%MODEL
The hardware model.
%VENDOR
The name of the hardware producer.
%HOST
The host name of the computer.
These variables can be used on all OS/400 platforms, although on
some platforms certain values may be null. Thus you are advised to
combine variables always with either %SERIAL or %HOST, in order to
ensure a non-duplicate node tag.
Note: If you want to use the % character as part of the node tag you
should be aware that if the text following the percent sign
matches one of the above variables, the variable will be used
instead of your text. For example, if you try and register an
agent on a node with a host name of ″johndoe″ and you want
to give it a node tag of ″50%hosted″, it will be registered as
″50JOHNDOEED″.
Startup mode
This determines whether SSL is or is not used for the initial
connection between the agent and the runtime server. After the initial
contact, the agent runs a service which downloads the appropriate
parameters for all agents in its division, and the downloaded values
overwrite the values supplied to the installagent command. Permitted
values are:
No SSL
Insecure: HTTP is used for all communications (default). The
Web server where the runtime server is installed must have an
HTTP service enabled.
SSL Secure: HTTPS is used for all communications. The HTTP server
where the runtime server is installed must have an HTTPS
service enabled.
Runtime server port / SSL port
If Startup Mode is No SSL, this field will be Runtime server port.
Enter the port on the runtime server used for http communication.
If Startup Mode is SSL, this field will be SSL port. Enter the port on
the runtime server used for https communication.
Use proxy server
Specifies whether the runtime is protected by a proxy server. If you
select this item, the panel is redisplayed with the proxy server fields,
as follows:
Agent deployment: on OS/400
Chapter 4. Deploy agents 179
Proxy server address
If you have selected Use proxy server, enter the address (host name or
IP address) of the proxy server.
Proxy port
If you have selected Use proxy, enter the port of the proxy server.Click Next.
11. Identify SSL certificate (optional): If you selected SSL for Startup Mode, the
following panel is displayed:
This panel enables you to determine the SSL certificate to be used at the
OS/400 target node.
If you want to select a certificate that you have created or purchased, browse
to it or enter its path. The certificate must have the name cert.arm, and is
installed in UserData.
If you select the option to use the embedded test certificate, you should be
aware that this is the certificate issued with the product for test purposes only,
and it should not be used in a ″live″ situation, as it is distributed to all
customers, and is thus not secure. Even if you select a different certificate, the
default certificate is also installed, but in ProdData.
Agent deployment: on OS/400
180 IBM Tivoli License Manager: Planning, Installation, and Configuration
12. Installation confirm: The install summary panel is now displayed, showing
you what is to be installed. Click Next to confirm your choices and go ahead
with the installation.
13. Finish: The wizard now installs the agent on the OS/400 node, and displays a
panel confirming the outcome. The wizard also starts the agent, which
connects to its runtime server and plugs itself in. Click Finish to finish.
14. Change password: During the installation, the wizard creates a user on the
OS/400 node called QITLM and gives it a password also of QITLM. You
should now change this password, for security.
To check that the agent has been correctly installed open the Installed License
Programs panel on the OS/400 node, and check that there is an entry for 1IBMTLM.
Installing the agent silently
When the install wizard runs in silent mode, it takes the parameters it requires
from an InstallShield response file. The response file, recordFile_Install.txt, is
provided with Tivoli License Manager in the <CD_drive>\setup\agent\OS400
directory. You must edit this file to provide the values for parameters that the
wizard must set.
The procedure to run the install wizard in silent mode is as follows:
1. Copy the response file: If you are running the installation from the server and
agent CD, copy the response file recordFile_Install.txt from the
\setup\agent\OS400 directory on the CD to a temporary directory on a hard
disk. Otherwise, identify the response file in the hard disk copy of the CD.
2. Edit the response file: Edit the response file so that the parameters describe the
OS/400 agent installation that you want to perform. A full description of the
parameters is provided in “Silent installation of OS/400 agent” on page 290.
3. Locate the wizard: Navigate to the following directory:
<CD_drive>\setup\agent\OS400\Win32
4. Launch the wizard: Launch the ISMP wizard:
v If you are launching the command from a hard disk, and you have edited
the response file in its original position, use the following command:
setupAgentOS400.exe <node_name> <user_id> <password> –silent –options
″..\recordFile_Install.txt″
v If you are launching the command from the server and agent CD, and you
have edited the response file in a temporary directory, use the following
arguments:
setupAgentOS400.exe <node_name> <user_id> <password> –silent –options
″<response_file_dir>\recordFile_Install.txt″
For example, setupAgentOS400.exe 9XBR344 cphillip due3four –silent
–options ″C:\temp_silent\recordFile_Install.txt″ runs the install wizard
silently, using a response file in the directory C:\temp_silent.
Notes:
a. If you want to move the setup file from the CD on to disk before launching
it, you must move both the setup*.exe/bin and the corresponding
../setup*.jar, and maintain their relative directory structure.
b. If Windows Terminal Server is installed on the computer where you want to
run the setup file, or you are accessing another computer using Windows
Terminal Services, you must launch the wizard as follows:
Agent deployment: on OS/400
Chapter 4. Deploy agents 181
1) Select the Add/Remove Programs option from the Control Panel.
2) Click Add New Programs.
3) Click CD or Floppy, and the Install Program From Floppy Disk or
CD-ROM wizard window will open. Click Next.
4) Click Browse, navigate to the setupAgentOS400.exe file, and select it by
highlighting it and clicking Open.
5) Type the appropriate arguments (<node_name> <user_id> <password>
–silent –options ″<response_file_dir>\recordFile_Install.txt″) after the
executable name.
6) Click Finish to exit from the wizard and run the setup file.
This procedure ensures that the Windows computer is in install mode when
the setup file is launched.
The same objective can also be achieved by changing into install mode
manually, and then back again after the agent deployment is complete. To
change into install mode manually, issue the command change user /install
from a Windows command line. Then issue the command to run the tool
setup file. After the installation has completed, you must issue the
command change user /execute to return to execute mode.5. Check results: The results of the installation can be seen by viewing the
messages and, if necessary, the trace logs. See IBM Tivoli License Manager:
Problem Determination for full details of these files.
6. Change password: During the installation, the wizard creates a user on the
OS/400 node called QITLM and gives it a password also of QITLM. You
should now change this password, for security.
See “Silent installation of OS/400 agent” on page 290 for a full description of the
recordFile_Install.txt file. See also “Installing the agent interactively” on page
175 for more information about the values you should supply in that file.
To check that the agent has been correctly installed open the Installed License
Programs panel on the OS/400 node, and check that there is an entry for 1IBMTLM.
Install the OS/400 agent on an iSeries node
This option runs the OS/400 install wizard in silent mode on the OS/400 node,
using a response file.
The steps are as follows:
1. Log in: Log in to the iSeries node as a user with rights to install programs.
2. Make the wizard accessible: The wizard file (setupAgentOS400.jar) can be
found on the Tivoli License Manager server and agent CD in the following
directory:
<CD_drive>\setup\agent\OS400\
Make the file accessible to the OS/400 system. The file needs to be either in the
IFS directory system, or on a device attached to the OS/400 system. If the file is
on an attached device, you need to use the Create Link (CRTLINK) command
to create a symbolic link to the file.
3. Edit the response file: Locate the response file recordFile_Install.txt. If you
are running the installation from the server and agent CD, copy the response
file from the <CD_drive>\setup\agent\OS400\ directory on the CD to a
temporary directory on a hard disk. Edit the response file, setting the
Agent deployment: on OS/400
182 IBM Tivoli License Manager: Planning, Installation, and Configuration
appropriate values for each parameter, as described in “Silent installation of
OS/400 agent” on page 290. Save the file.
4. Run the wizard in silent mode: Issue the following command:
RUNJVA CLASS(run) PARM(’-silent’ ’-options’
’<response_file_dir>/recordFile_Install.txt’)
CLASSPATH(’/setupAgentOS400.jar’)
The wizard installs the agent and starts it. The agent connects to its runtime
server and plugs itself in.
5. Change password: During the installation, the wizard creates a user on the
OS/400 node called QITLM and gives it a password also of QITLM. You
should now change this password, for security.
To check that the agent has been correctly installed open the Installed License
Programs panel on the OS/400 node, and check that there is an entry for 1IBMTLM.
Saving and Restoring the agent to a different iSeries node
Once you have installed the OS/400 agent you can copy it to a different iSeries
node running OS/400. This procedure uses the SAVLICPGM on the source node
and the RSTLICPGM command on the target node. The steps are as follows:
1. Log in to source node: Log in to the node where the OS/400 agent has already
been installed. The user ID should have rights that enable you to use the
SAVLICPGM command.
2. Copy agent configuration file to target node: When the agent was installed on
the source node, two copies of the agent configuration file were installed, as
follows:
Agent configuration template file
This is the default agent configuration file, as supplied with the
product, and it can be found in the following location:
/QIBM/ProdData/QITLM/conf/tlmagent.ini
Customized agent configuration file
This is the customized agent configuration file, as modified by the
parameters you supplied when installing the agent. It can be found in
the following location:
/QIBM/UserData/QITLM/conf/tlmagent.ini
If, on the target node, there is no file tlmagent.ini in either the /tmp/itlm
directory or in /QIBM/UserData/QITLM/conf, using the SAVLICPGM and
RSTLICPGM commands will copy the template version of the file in
/QIBM/ProdData/QITLM/conf on the source node to /QIBM/UserData/QITLM/conf
on the target node. The agent will not then be able to run because this is the
template file. In order to ensure that the agent runs after using the RSTLICPGM
command, you are recommended to copy either the template file
(/QIBM/ProdData/QITLM/conf/tlmagent.ini) or the customized file
(/QIBM/UserData/QITLM/conf/tlmagent.ini) on the source node to
/QIBM/UserData/QITLM/conf/tlmagent.ini on the target node, and then
customize it, as described in the next step.
3. Customize target agent configuration file: Edit the
/QIBM/UserData/QITLM/conf/tlmagent.ini on the target node, changing the
parameters to match your requirements for the target node, as follows:
Agent deployment: on OS/400
Chapter 4. Deploy agents 183
server The address (host name or IP address) of the runtime server to which
the agent is to belong.
port The port on the runtime server used for communication.
use_proxy
Specifies whether the runtime is protected by a proxy server (y) or not
(n).
proxy If use_proxy is y, enter the address (host name or IP address) of the
proxy server. Otherwise enter ″none″.
proxy_port
If use_proxy is y, enter the port of the proxy server. Otherwise enter
any numeric value, for example ″3128″.
secure_port
If startupMode is ssl, enter the port number used for SSL
communications. Otherwise enter any numeric value, for example
″443″.
agentid
Supply the following string:%AGENT_ID
division
The name of the division to which the agent is to belong.
organization
The name of the organization to which the agent is to belong.
startupMode
This determines whether SSL is or is not used for the initial connection
between the agent and the runtime server. After the initial contact, the
agent runs a service which downloads the appropriate parameters for
all agents in its division, and the downloaded values overwrite the
values supplied to the installagent command. Permitted values are:
nossl
Insecure: HTTP is used for all communications (default). The Web
server where the runtime server is installed must have an HTTP
service enabled.
ssl Secure: HTTPS is used for all communications. The HTTP server
where the runtime server is installed must have an HTTPS service
enabled.
tag The name of the node on which you want to install the OS/400 agent.
The default value is the concatenation of the %SERIAL and the
%VENDOR variables. This is free-format text and represents your way
to recognize the agent. It is not case sensitive, and all lower-case
characters are converted to upper-case when the agent is registered.
You can use the following variables to make up all or part of the tag:
%SERIAL
The serial number of the computer.
%TYPE
The type of hardware.
%MODEL
The hardware model.
Agent deployment: on OS/400
184 IBM Tivoli License Manager: Planning, Installation, and Configuration
%VENDOR
The name of the hardware producer.
%HOST
The host name of the computer.
These variables can be used on all OS/400 platforms, although on some
platforms certain values may be null. Thus you are advised to combine
variables always with either %SERIAL or %HOST, in order to ensure a
non-duplicate tag.
Note: If you want to use the % character as part of the tag you should
be aware that if the text following the percent sign matches one
of the above variables, the variable will be used instead of your
text. For example, if you try and register an agent on a node
with a host name of ″johndoe″ and you want to give it a tag of
″50%hosted″, it will be registered as ″50JOHNDOEED″.
All other files should be left with the indicated values, or modified as
discussed in IBM Tivoli License Manager: Problem Determination.
4. Save the agent: Use the SAVLICPGM command to save a copy of the agent in
a SAVF file. .
5. Copy agent to target node: Copy the agent SAVF file created in step 4 to the
target node.
6. Log in to target node: Log in to the target node. The user ID should have
rights that enable you to use the RSTLICPGM command.
7. Restore the agent: Use the RSTLICPGM command to restore the copy of the
agent SAVF on the target node. The agent should start automatically, connect
itself to its runtime server and plug itself in.
Note: If the command fails to find the
/QIBM/UserData/QITLM/conf/tlmagent.ini file on the source node, it
copies the template version of the file (which is included in the SAVF file
package) to that location. However, the agent cannot start using the
parameters in the template file. You should now edit the
/QIBM/UserData/QITLM/conf/tlmagent.ini file as described in step 3, and
restart the agent.
To check that the agent has been correctly installed open the Installed License
Programs panel on the OS/400 node, and check that there is an entry for 1IBMTLM.
Deploying the WebSphere Application Server agent
If you have WebSphere Application Server deployed on an agent, an additional
agent process is used, which detects products running on WebSphere Application
Server. This process is the WebSphere Application Server agent, normally referred
to as the wasagent.
The wasagent is installed automatically if the agent detects the presence of
WebSphere Application Server. This is true either if WebSphere Application Server
is present when the agent is installed, or if WebSphere Application Server is
installed after the agent has been installed.
The wasagent has a command line, from which you can perform various activities,
including supplying the wasagent with the access credentials for any WebSphere
Agent deployment: on OS/400
Chapter 4. Deploy agents 185
Application Server security cell that may be in use. You need to supply these
credentials before the wasagent can access the security cell. For full details of the
command line, see “WebSphere Application Server agent commands” on page 230.
Agent deployment: on OS/400
186 IBM Tivoli License Manager: Planning, Installation, and Configuration
Chapter 5. Install the catalog manager
This chapter provides the information and instructions required to install the
catalog manager. This information includes:
v Things that you should do or check before starting the installation. See
“Pre-install tasks.”
v Instructions for installing the catalog manager. See “Install procedures” on page
188.
v Instructions for uninstalling the catalog manager. See Chapter 7, “Uninstall Tivoli
License Manager,” on page 203.
To read an overview about the catalog manager see “Catalog management” on
page 8.
To read planning information about installing the catalog manager, including its
supported platforms and prerequisites, see “Plan how to install the catalog
manager” on page 55.
Pre-install tasks
Before you start the installation, do the following steps:
1. Select computer: Choose a computer on which you want to install the catalog
manager.
2. Check prerequisites: Check that the computer on which you plan to install
the catalog manager meets the installation prerequisites. See “Catalog manager
prerequisites” on page 55.
Make sure you have sufficient disk space for the installation you require.
3. Check time zone settings: Ensure that the time and time zone settings are
correct. It is not advisable to change these settings when Tivoli License
Manager is in use. However, if you need to change the date or time on a
computer where the catalog manager is installed, you should stop the catalog
manager, change the date or time, and then restart the catalog manager again.
4. Check language settings: If you are installing the catalog manager in a
double-byte character set (DBCS) environment, ensure that the primary
language environment settings (cultural conventions, language, and keyboard)
are correct. Incorrect settings can result in communications failures between
the catalog manager and the database.
5. On UNIX: Ensure availability of operating system commands: The catalog
manager installation uses native operating system commands on UNIX. In
particular, it uses the find and grepcommands. This means that if you have
software installed that enables other commands with the same names as these,
the software must be uninstalled or disabled.
6. On UNIX, check for the existence of the DB2 configuration file: On UNIX
platforms, if DB2 is installed, you should check for the existence of the
following DB2 configuration file:
<DB2InstanceHome>/sqllib/db2profile
where <DB2InstanceHome> is the home directory of the DB2 instance owner,
for example, /home/DB2inst1.
© Copyright IBM Corp. 2002, 2004 187
If this file is not present, it means that the original DB2 installation is not
configured correctly, and it should be uninstalled before you attempt to run
this installation.
7. On UNIX, check that the DB2 configuration file does not contain a shell
call: On UNIX platforms, if DB2 is installed, check that the
<DB2InstanceHome>/sqllib/db2profile file does not contain a shell call or
invocation. If it does it must be removed as the presence of such a call causes
the installation to fail.
8. On Windows, check PATH if DB2 prerequisite installed: If a prerequisite
version of DB2 is installed on the computer, make sure that the PATH variable
contains the correct path for DB2, for example typing echo %PATH% at the
Windows command line. Verify the presence of the DB2 ...\bin directory (for
example, C:\Program Files\DB2\bin) in the path. If it is not there it should be
added.
9. Check computer is correctly configured for auto-installed prerequisites: If
you plan to use the auto-install facility for the prerequisite version of DB2,
ensure that you have read the documentation for the prerequisite, have
checked that there is sufficient space available, and that the computer is
correctly configured for it. For example, check that the kernel on HP/UX and
Solaris platforms is correctly configured for DB2.
10. Start DB2: If you already have a supported database prerequisite for this
installation, start the DB2 services on the appropriate DB2 server.
11. Collect install information: Ensure that you have the information required to
access the database where the product information is stored. This information
comprises: the database name, the host name of the computer where the DB2
server is installed, and the port number used for communications with the
DB2 server. If you are installing on an UNIX platform, you also need the DB2
instance owner.
Note: The default port number for DB2 is 50000. However, you should check
that this is the number that has been configured. To do this check the
services file for the computer where the DB2 server is installed:
UNIX
/etc/services
Windows
<WINDOWS_INSTALL_DIR>\system32\drivers\etc\services
Search for a row with the following information:
<service> <port>/tcp # Connection port for DB2
If there is more than one entry like this, find the latest entry and note
the value for port.
Install procedures
A single install wizard that can be used to install the catalog manager on all
supported platforms. The setup file is found in the following directories of the
catalog manager CD:
AIX setup/catalog_manager/AIX/setupCatMan.bin
Pre-install tasks
188 IBM Tivoli License Manager: Planning, Installation, and Configuration
HP/UX setup/catalog_manager/Hpux/setupCatMan.bin
Linux setup/catalog_manager/Linux/setupCatMan.bin
Linux 390 setup/catalog_manager/Linux390/setupCatMan.bin
Linux ppc setup/catalog_manager/LinuxPPC/setupCatMan.bin
Sun setup/catalog_manager/Solaris/setupCatMan.bin
Windows setup\catalog_manager\Win32\setupCatMan.exe
Choosing the installation method
Before proceeding with the installation you should ensure that you have read the
planning chapter (see Chapter 1, “Plan to deploy IBM Tivoli License Manager,” on
page 1).
There are three possible ways of running the installation wizard:
Interactive mode
This uses a GUI that enables you to enter the required information
interactively on a series of panels.
It is invoked by launching the wizard’s setup command without
arguments.
It is fully described in “Using the install wizard in interactive mode” on
page 191.
Silent mode
When the install wizard runs in silent mode, it takes the parameters it
requires from an InstallShield response file. The response file,
recordFile_Install.txt, is provided with Tivoli License Manager in the
\setup\catalog_manager directory on the catalog manager CD. You must
edit this file to provide the values for parameters that the wizard must set.
To run the install wizard in silent mode, follow this procedure:
1. Log on to the computer where you want to install the catalog manager
as a user with administrative rights (Administrator on Windows
platforms or root on UNIX platforms).
2. If you are running the installation from the catalog manager CD, copy
the recordFile_Install.txt response file from the
\setup\catalog_manager directory on the CD to a temporary directory
on a hard disk.
3. Edit the response file so that the parameters describe the installation
that you want to perform. See “Catalog manager silent installation” on
page 287 for a full description of the parameters.
4. If you want the silent installation to also install the bundled
prerequisite DB2, you cannot run the installation from the CD, and
auto-install the bundled prerequisite DB2 from CD as part of the same
process. Instead, you must do one of the following:
v Run the install wizard from a hard disk image of the catalog
manager CD.
v Copy the following directory, and all its files and sub-directories onto
disk CD drive:\setup\catalog_manager\ , maintaining the directory
structure and names as they are in the CD.
v Make a hard disk image of the prerequisite software install CD you
will be needing to use.
Install catalog manager
Chapter 5. Install the catalog manager 189
v Install the prerequisite yourself, before commencing the Tivoli
License Manager installation.5. Attention: Read the license agreement (ITLM21LICENSE.txt) in the
license directory of the servers and agents CD. By continuing with this
process and launching the setup command you are giving your implicit
agreement to the terms of the license agreement. Make sure you agree
with the terms and conditions before you proceed.
6. Launch the wizard’s setup command, as follows:
–options ″<response_file_path>\recordFile_Install.txt″ –silent
Where <response_file_path> is either the full path of
recordFile_Install.txt, or its path relative to the setup file.
For example, setupCatMan.exe –options
″C:\temp_silent\recordFile_Install.txt″ –silent
Note: On Windows computers, if Windows Terminal Server is installed
on the computer where you want to run the setup file, or you
are accessing another computer using Windows Terminal
Services, you must launch the wizard as follows:
a. Select the Add/Remove Programs option from the Control
Panel.
b. Click Add New Programs.
c. Click CD or Floppy, and the Install Program From Floppy
Disk or CD-ROM wizard window will open. Click Next.
d. Click Browse, navigate to the setup file, and select it by
highlighting it and clicking Open.
e. Click Finish to exit from the wizard and run the setup file.
This procedure ensures that the Windows computer is in install
mode when the setup file is launched.
The silent wizard provides almost the full functionality of the interactive
wizard, with the following exceptions:
v You cannot browse to identify the product install directory. It must be
provided as a full pathname, and if the pathname includes directories
with spaces in their names, it must be enclosed in double quotes.
v The silent wizard, like the interactive wizard, will install the prerequisite
database software for you, if it is not already installed (see “Obtaining
and installing the prerequisite software” on page 31 for details). If you
are certain that the product prerequisite is installed on the target
computer, you can skip the search for it by setting the skip-search
parameter in the response file.
The results of the installation can be seen by viewing the messages and, if
necessary, the trace logs. See IBM Tivoli License Manager: Problem
Determination for full details of these files.
See “Catalog manager silent installation” on page 287 for a full description
of the recordFile_Install.txt file. See also “Using the install wizard in
interactive mode” on page 191 for more information about the values you
should supply in that file.
Choosing the method
190 IBM Tivoli License Manager: Planning, Installation, and Configuration
Remote installation using Tivoli Configuration Manager
If you are a user of the Software Distribution component of Tivoli
Configuration Manager you can leverage the Software Distribution facility
to install and run a program remotely.
Tivoli License Manager is supplied with a software package block for each
platform on which you can install the catalog manager. The software
package block contains the install wizard and the response file for that
platform. It is called <platform>catmgr.spb and can be found in the catalog
manager CD, in a structure that has the format
SPBs\<platform_subdirectory>. In each of the platform sub-directories will
find an SPB for the catalog manager.
You should import the software package block into a profile manager and
subscribe the target computer to the profile manager. When you distribute
the profile manager, you are asked to supply the install parameters. See
“Software package block for catalog manager installation using Tivoli
Configuration Manager” on page 288 for a full description of the
parameters. See also “Using the install wizard in interactive mode” for
more information about the values you should supply.
The software package block is installed on the target computer, and the
install wizard is launched in silent mode. Any errors identified by software
distribution are reported through its reporting channels (for example, a
failure to install the SPB on the node). Any errors found by the installation
wizard are reported in the message and trace logs. Details of these logs,
and the steps to take to validate the installation can be found in IBM Tivoli
License Manager: Problem Determination.
Attention: Security considerations: The install parameters that you
supply may include a password (for the DB2 prerequisite installation). The
password is saved in unencrypted form in the software package block. The
software package block itself is not an encrypted file. Thus, the moment
you type the password into the file you may be incurring a breach of the
security rules of your installation. The transmission of the software
package block to the target computer is managed by Tivoli Management
Framework, which can be enabled to implement 56-bit DES encryption on
gateway to endpoint unicast communication (encryption is not supported
on multicast distributions).
Using the install wizard in interactive mode
To install the catalog manager, complete the following steps:
1. Log on: Log on to the computer where you want to install Tivoli License
Manager catalog manager as a user with administrative rights (Administrator
on Windows platforms or root on UNIX platforms).
2. Check location of setup file (if installing bundled prerequisite): If you want
the Tivoli License Manager installation to also install the bundled prerequisite
DB2, you will not be able to run the installation from the CD, and auto-install
the bundled prerequisite software from CD as part of the same process.
Instead, you must do one of the following:
v Run the install wizard from a hard disk image of the server and agents CD.
v Copy the install setup file for your platform, and the file CD
drive:\setup\catalog_manager\setupCatMan.jar onto hard disk,
maintaining the directory structure and names as they are in the CD.
v Make a hard disk image of the prerequisite software install CD you will be
needing to use.
Choosing the method
Chapter 5. Install the catalog manager 191
v Install the prerequisite yourself, before commencing the Tivoli License
Manager installation. 3. Launch wizard: Launch the setup file for Tivoli License Manager.
Notes:
a. On UNIX computers, although the korn shell must be installed and
activated, the setup command can be issued from any shell.
b. On UNIX computers, the name of the directory from which you launch the
setup file, and the names of any directories in the path to that directory,
must not contain blanks.
c. If you want to move the setup file from the CD on to disk before
launching it, you must move both the setup*.exe/bin and the
corresponding ../setup*.jar, and maintain their relative directory
structure.
d. On Windows computers, if Windows Terminal Server is installed on the
computer where you want to run the setup file, or you are accessing
another computer using Windows Terminal Services, you must launch the
wizard as follows:
1) Select the Add/Remove Programs option from the Control Panel.
2) Click Add New Programs.
3) Click CD or Floppy, and the Install Program From Floppy Disk or
CD-ROM wizard window will open. Click Next.
4) Click Browse, navigate to the setup file, and select it by highlighting it
and clicking Open.
5) Click Finish to exit from the wizard and run the setup file.
This procedure ensures that the Windows computer is in install mode
when the setup file is launched.
The same objective can also be achieved by changing into install mode
manually, and then back again after the installation is complete. To change
into install mode manually, issue the command change user /install from a
Windows command line. Then issue the command to run the setup file.
After the installation has completed, you must issue the command change
user /execute to return to execute mode.
Attention: A command line window is opened prior to the display of the
first wizard panel. Do not close this window.
4. Select wizard language: The wizard starts and requests you to select the
language version of the wizard that you want to use. It then displays the
product’s splash screen.
Note: As the language selection screen is displayed before you select the
wizard language, it is displayed in the language of the locale of your
machine, provided that language is supported. Supported languages
are: Bulgarian, Croatian, Czech, Danish, Dutch, English, Finnish, French,
German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian,
Polish, Portuguese, Portuguese (Brazil), Romanian, Russian, Simplified
Chinese, Slovak, Slovenian, Spanish, Swedish, Traditional Chinese,
Turkish. If you are not in one of these locales, these screens may be
unreadable, and you should temporarily switch your computer to a
supported locale.
5. Welcome panel: The welcome panel is now displayed. Click Next to continue.
Interactive install
192 IBM Tivoli License Manager: Planning, Installation, and Configuration
6. License panel: The license agreement panel is now displayed. Read the license
agreement thoroughly. You must select the radio button to accept the license
agreement before you can proceed by clicking Next. Attention: The license agreement for the Tivoli License Manager catalog
manager also contains the restricted use license that is required if you intend
to let the wizard install DB2 for you. Make sure you agree with the terms and
conditions before you proceed.
7. Install location: The following panel is displayed:
Accept the default location displayed or click Browse to select a different
location. If the directory does not exist it will be created. If you leave this field
blank, the install location defaults to the directory where the install wizard
was started.
Attention: Do not install the Tivoli License Manager catalog manager in the
same directory as any other product. In particular, do not attempt to install
the catalog manager in the same directory as any of the Tivoli License
Manager server and database components, which have their own install
wizard. The reason for these restrictions is that many products use Java
Virtual Machine (JVM), and each product must have its appropriate version
installed. Installing two products in the same directory causes just one
instance of JVM to be installed, and one of the products may have the wrong
version. Moreover, if you uninstall one of the products, the JVM is also
uninstalled, leaving the other product without a working version.
Click Next.
8. DB2 prerequisite check: The wizard checks that a supported version of DB2
is installed on the computer. If it cannot find the prerequisite, it displays the
following panel:
Interactive install
Chapter 5. Install the catalog manager 193
If you have an unsupported version of DB2 on this computer you must stop
the installation by clicking Cancel. If you do not do this, if the wizard
attempts to install version 8.1 of DB2 it will fail, because different versions of
DB2 cannot co-exist on the same computer.
If you know that a supported version of DB2 exists on the computer, that the
wizard has been unable to find, select Locate the DB2 install directory:. A text
field is displayed where you can enter the directory where it is installed, or
browse to it using the Browse button.
Otherwise, select Let the wizard install IBM DB2 UDB, Enterprise Server
Edition, version 8.1.
Click Next to continue. The missing prerequisite is installed at a later stage in
the wizard. See “Auto-installation of prerequisite software” on page 32 for
more details about the auto-installation of prerequisites.
9. If required: DB2 prerequisite information: If you asked the wizard to install
the prerequisite version of DB2 it now asks you for the information it needs to
install DB2. It displays the following panel:
Interactive install
194 IBM Tivoli License Manager: Planning, Installation, and Configuration
Enter the following information:
IBM DB2 path or IBM DB2 instance owner’s path
The data you enter depends on the platform, as follows:
Windows
On Windows, supply the path where you want to install DB2 on
this computer, for example: C:\Program Files\IBM\DB2.
UNIX On UNIX, supply the home directory of the instance owner of
DB2 on this computer, for example \home\db2inst1.
DB2 Administrator user or DB2 instance owner
The data you enter depends on the platform, as follows:
Windows
On Windows, supply the user ID that you want to set up as the
″DB2 administration″ user, for example: db2admin. This user will
be created on the computer. Ensure that a user with this name
does not already exist.
UNIX On UNIX, supply the instance owner of DB2, for example
″db2inst1″. The full path will be created by concatenating the
home instance owner’s path and the instance owner’s name, for
example /home/db2inst1.
Password
Enter the password to be used for the ″DB2 administration″ user
(Windows) or the password of the DB2 instance owner (UNIX).
The password must satisfy the password rules of the computer on which
you are installing DB2.
To change the DB2 administration password after installation see
“Changing passwords” on page 297.
Confirm password
Confirm the password.
Click Next.
10. Database configuration: The following panel is displayed.
Interactive install
Chapter 5. Install the catalog manager 195
Supply the information required to enable communications between the
catalog manager and the database where the product information is held.
Supply the following information:
DB2 instance owner
On UNIX platforms only, supply the user name of the owner of the DB2
client instance that has been or will be created on this computer.
Database address (host name or IP)
Identify the host computer of the administration server database by
entering the host name or the IP address. If the wizard has found the
administration server database on this computer it displays ″localhost″ as
a default.
Database port number
Specify the port being used by the instance of DB2 that is hosting the
administration server database, on the computer where this database is
installed. The usual value is 50000. Any default shown will be the port
used by the first instance of DB2 on the computer where you are installing
the catalog manager, which may not be the computer where the
administration server database is installed. In all cases you should obtain
the value from the computer where the administration server database is
installed.
Click Next to continue.
11. Confirm installation: A panel is displayed confirming the details you have
entered and the sizing of the installation.
Interactive install
196 IBM Tivoli License Manager: Planning, Installation, and Configuration
Click Next to start the installation. The installation takes a few minutes.
12. If required: DB2 prerequisite install path: If the wizard has identified that a
supported level of DB2 is missing, it now attempts to install it, displaying the
following panel:
This panel enables you to launch the silent install wizard for DB2. You should
perform the following steps:
a. Locate the IBM DB2 UDB, Enterprise Server Edition, version 8.1
installation CD (supplied with the product) and insert it in the CD drive of
your computer.
b. Identify the setup file for DB2.
Click Next.
Interactive install
Chapter 5. Install the catalog manager 197
Attention: If you click Cancel at this point, the wizard will finish without
installing DB2. In this event, the catalog manager that you have installed will
not be usable. You should uninstall the catalog manager using the uninstall
wizard; see Chapter 7, “Uninstall Tivoli License Manager,” on page 203 for
details. When you have decided what to do about DB2 you can then repeat
the catalog manager installation.
13. If required: DB2 prerequisite installation: If the wizard has identified that
the DB2 prerequisite is missing, it now silently installs DB2 using the
parameters already supplied.
14. Catalog database: DB2 is started, and an alias is created (TLMCDB) which
points to the identified database. This alias points to the administration server
database you identified in step Database configuration: on page 195 (Database
configuration:). If you want to also access other databases, you should use the
DB2 facilities to create additional aliases to point to those databases.
15. Finish installation: When the installation process is complete, a confirmation
panel is displayed. Click Finish to end the installation.
Problem determination
If a problem occurs with the installation, refer to IBM Tivoli License Manager:
Problem Determination. This contains a chapter on diagnosing problems during the
installation of the catalog manager.
Configuring the catalog manager
The steps that you need to follow to configure the catalog manager after the
installation has completed, only apply if you want to use the same catalog
manager instance to access more than one administration server database.
Multi-catalog setup
If your Tivoli License Manager environment supports more than one
administration server, you can set up the catalog manager to access all of the
administration server databases that you have created.
First you install the catalog manager on the computer from where you want to use
it. During the installation, identify one of the administration server databases that
you wish to manage That database will automatically be catalogued as TLMCDB.
Then follow this procedure for all other administration server databases:
1. Open DB2 CLI: Open the DB2 command line window.
2. Catalog the node: Issue the following command to catalog the node where the
administration database server is situated:
db2 catalog tcpip node <nodeAlias> remote <adminServerDbAddress> SERVER
adminServerDbPort
Where:
nodeAlias
Supply the name that you want to give to this node in DB2.
adminServerDbAddress
Supply the address of the node where the administration server
database is installed, either a full host name or an IP address.
Interactive install
198 IBM Tivoli License Manager: Planning, Installation, and Configuration
adminServerDbPort
Supply the port that DB2 uses on that node.
For example, the following command catalogues the node with a TCP/IP host
name of BPORTAL1.rome.tivoli.com, giving it an alias of ADMIN1 and
recognizing it as a DB2 server listening on port 50000:
db2 catalog tcpip node ADMIN1 remote BPORTAL1.rome.tivoli.com SERVER 50000
3. Catalog the database: Issue the following command to catalog the
administration server database:
db2 catalog database TLMA as <databaseAlias> at node <nodeAlias>
databaseAlias
The name you want to recognize the database by. This is the name that
you provide when the catalog manager is started.
nodeAlias
Supply the name that you gave to the node in the previous step.
For example, the following command catalogues the administration server
database (always called TLMA) on the node ADMIN1 as CATALOG1:
db2 catalog database TLMA as CATALOG1 at node ADMIN1
Alternatively, the same effect can be achieved using the DB2 GUI. See the DB2
documentation for details.
Selecting the correct catalog to manage
When you start the catalog manager, the following panel is displayed:
After entering the user name and password, enter one of the following database
names:
v Either the database TLMCDB, which is the default name of the database that
was identified when the catalog manager was installed.
v Or enter the name of a database that you have cataloged using the procedure
described in the previous section.
Configure
Chapter 5. Install the catalog manager 199
Configure
200 IBM Tivoli License Manager: Planning, Installation, and Configuration
Chapter 6. Migrate to version 2.1
If you have version 1.1.1 of Tivoli License Manager you can migrate your servers,
databases and agents to version 2.1. If any of your servers or databases are at a
version prior to 1.1.1 you must upgrade them to version 1.1.1 before commencing
the migration. If any of your agents are at a version prior to 1.1.1 you must
upgrade them to version 1.1.1 before the migration, or redeploy them after the
migration as version 2.1 agents.
It is not possible to migrate to Tivoli License Manager for IBM software.
The tool that enables you to perform this migration is available from the Tivoli
License Manager support Web site. The Web address is given in “Contacting
software support” on page xvii. Select IBM Tivoli License Manager from the All
support pages in this product category drop-down. The migration package is in
the Downloads section of the page that is displayed. Download the package and
its supporting documentation. The tool is fully documented in a readme file, to
which you are referred for all information relating to the migration.
© Copyright IBM Corp. 2002, 2004 201
202 IBM Tivoli License Manager: Planning, Installation, and Configuration
Chapter 7. Uninstall Tivoli License Manager
This section includes instructions for uninstalling the following components of
Tivoli License Manager:
v The Tivoli License Manager server and database components, see “Uninstalling
the Tivoli License Manager server and database components.”
v The Tivoli License Manager agent, see “Uninstalling the agent” on page 208.
v The Tivoli License Manager catalog manager, see “Uninstalling the catalog
manager” on page 211.
Uninstalling the Tivoli License Manager server and database
components
A Tivoli License Manager server or database component can be uninstalled locally
or remotely. The steps are as follows:
1. Log on to the computer where you want to uninstall Tivoli License Manager
components as a user with administrator rights (Administrator on Windows
platforms or root on UNIX platforms).
2. If you are planning to uninstall a database component (which is installed on a
DB2 server), stop the DB2 clients that are using that DB2 server (catalog
manager, for example).
3. Run the uninstall wizard. The wizard enables you to select the components you
want to remove. If you choose to remove a server component, the wizard also
removes the WebSphere Application Server configurations for the server.
It does not remove the Tivoli License Manager log files.
There are three possible ways of running the uninstall wizard:
Interactive mode
This uses a GUI that enables you to enter the required information
interactively on a series of panels.
It is invoked by launching the uninstaller.exe (Windows) or
uninstaller.bin command (UNIX) from the <INSTALL_DIR>\_uninst
directory without arguments.
Note: On Windows computers, if Windows Terminal Server is installed
on the computer where you want to run the setup file, or you
are accessing another computer using Windows Terminal
Services, you must launch the uninstall wizard as follows:
a. Select the Add/Remove Programs option from the Control
Panel.
b. Click on Tivoli License Manager and then on Remove or
Change/Remove, whichever is displayed.
This procedure ensures that the Windows computer is in install
mode when the setup file is launched.
The same objective can also be achieved by changing into install
mode manually, and then back again after the uninstallation is
complete. To change into install mode manually, issue the
command change user /install from a Windows command line.
© Copyright IBM Corp. 2002, 2004 203
Then issue the command to run the setup file. After the
uninstallation has completed, you must issue the command
change user /execute to return to execute mode.
Using this program is fully described in “Using the uninstall wizard in
interactive mode” on page 206.
Silent mode
When the uninstall wizard runs in silent mode, it takes the parameters
it requires from an InstallShield response file. The response file,
recordFile_Uninstall.txt, is provided in the <INSTALL_DIR>\_uninst
directory. You must edit this file to provide the values for parameters
that the wizard must set. See “Server and database silent
uninstallations” on page 285 for a full description of the file.
To launch the uninstall wizard in silent mode, launch the appropriate
uninstaller command following this procedure:
a. Log on the computer where you want run the wizard with
Administrator or root rights.
b. Edit the response file so that the parameters describe the
uninstallation that you want to perform.
c. Launch the wizard’s uninstall command with the following
arguments:
–options ″<INSTALL_DIR>\_uninst\recordFile_Uninstall.txt″ –silent
Note: On Windows computers, if Windows Terminal Server is
installed on the computer where you want to run the setup
file, or you are accessing another computer using Windows
Terminal Services, you must ensure that the Windows
computer is in install mode when the setup file is launched,
as follows:
1) Change into install mode manually by issuing the
command change user /install from a Windows command
line.
2) Issue the uninstaller command with the arguments
detailed above to run the setup file.
3) After the uninstallation has completed, issue the
command change user /execute to return to execute mode.
See “Server and database silent uninstallations” on page 285 for a full
description of the recordFile_Uninstall.txt file. See also “Using the
uninstall wizard in interactive mode” on page 206 for more information
about the values you should supply in that file.
Using Tivoli Configuration Manager
If you installed Tivoli License Manager servers or databases using
Tivoli Configuration Manager, you can uninstall the same set of
components by using the uninstall option in Tivoli Configuration
Manager. You cannot choose to uninstall a subset of the components –
all that were installed will be uninstalled.
Notes:
a. If you uninstall database components with this option, their
databases are not dropped during the uninstallation. If you want to
Uninstalling: servers and databases
204 IBM Tivoli License Manager: Planning, Installation, and Configuration
drop them, you must do it manually, after the uninstallation (see
“Planning whether to drop the databases”).
b. If you want to uninstall a Tivoli License Manager server that is
running in a WebSphere Application Server secure cell, you must
stop the server using the srvstop command (supplying the required
user id and password to access the secure cell), before using Tivoli
Configuration Manager to uninstall it.
Planning whether to drop the databases
During the uninstall process, one of the questions you will be asked is whether
you wish to delete (drop) the database tables. This depends on which databases
are installed, and why you are uninstalling them, as follows:
Administration server database to be uninstalled
Dropping the administration server database will lose all data accumulated
in any previous operations of Tivoli License Manager.
If you are uninstalling the administration server database prior to
reinstalling it in the same place, you should not drop the database. It will
automatically be re-used when you re-install the component.
If you need to move the administration server database to a different
computer you should not drop the database. After uninstalling the
component you would copy the database to the new computer and install
the component on the new computer. In this case, you should then also
uninstall and reinstall the administration server component; when you
reinstall it you will give the server the new address of the computer where
its database is installed.
Thus, you would only drop the database if you were willing to
recommence Tivoli License Manager operations from scratch.
Only runtime server database to be uninstalled
If you are only uninstalling the runtime server database component, you
can always drop the database, as it will always be reconstructed from
information stored at the administration server and the agents. However, if
you are moving the runtime server database to another computer, you
should also uninstall and reinstall the runtime server, so that on the
reinstallation you can supply it with the new address of the database.
Administration and runtime database components to be uninstalled on the same
computer
The uninstall wizard treats both databases in the same manner. As you
have an administration server database you would not want to drop it, so
as not to lose the data. Thus you would not drop either database. When
the uninstallation is complete, you can issue a DB2 command to drop the
runtime server database manually. Alternatively, you can uninstall the two
databases separately, dropping the runtime server database but not the
administration server database.
Database to be uninstalled is being uninstalled by Tivoli Configuration
Manager
If you are uninstalling a database component using the Tivoli
Configuration Manager uninstall option, the databases themselves will not
be deleted (dropped), and you should do it manually.
For instructions on how to drop a database manually, see “Dropping the Tivoli
License Manager databases manually” on page 207.
Uninstalling: servers and databases
Chapter 7. Uninstall Tivoli License Manager 205
Using the uninstall wizard in interactive mode
To uninstall Tivoli License Manager server components from a computer with the
interactive wizard, complete the following steps:
1. Start the uninstall wizard.
Windows uninstaller.exe
UNIX uninstaller.bin
The wizard is located in the folder <INSTALL_DIR>\_uninst.
Notes:
a. On UNIX platforms, there is a folder called deinst. This folder is not the
uninstall folder. It contains files used in the uninstallation.
b. On Windows platforms, if Windows Terminal Server is installed on the
computer where you want to run the setup file, or you are accessing
another computer using Windows Terminal Services, you must launch the
uninstall wizard as follows:
1) Select the Add/Remove Programs option from the Control Panel.
2) Click on Tivoli License Manager and then on Remove or
Change/Remove, whichever is displayed.
This procedure ensures that the Windows computer is in install mode when
the setup file is launched.
The same objective can also be achieved by changing into install mode
manually, and then back again after the uninstallation is complete. To
change into install mode manually, issue the command change user /install
from a Windows command line. Then issue the command to run the setup
file. After the uninstallation has completed, you must issue the command
change user /execute to return to execute mode.2. The wizard detects the components that are present on the computer. Deselect
any that you do not wish to uninstall.
Note: If an agent was installed on this computer using the ″All components″
installation, the runtime server cannot be uninstalled unless the agent is
also uninstalled. If an agent was installed by as different deployment
method, it will not appear on the components section panel.
3. The wizard offers you the option to drop the databases, as discussed in
“Planning whether to drop the databases” on page 205.
4. The wizard displays a panel showing the components it intends to uninstall. If
the information is correct, click Next to commence the uninstallation.
5. If you have selected to uninstall a server, and you are operating WebSphere
Application Server in a secure cell, a panel is displayed for you to enter the
User ID and Password to access the WebSphere Application Server secure cell.
Click Next to continue the uninstallation.
6. When the uninstallation is complete, click Finish to exit from the wizard.
7. If you have uninstalled all components on a computer, you are now
recommended to delete the folder where Tivoli License Manager was installed,
to ensure that all deleted logs and data are removed from the file system.
If you are uninstalling an ″All components″ installation, and the agent was
included among the components to uninstall, you can now delete the files and
folders where the agent was installed (see “Agent files” on page 221 for full
details).
Uninstalling: servers and databases
206 IBM Tivoli License Manager: Planning, Installation, and Configuration
What to do if the uninstallation fails
The uninstallation can fail for any of the following reasons:
The wizard will not run
Ensure that you are logged on with the correct privileges. Ensure that there
is sufficient disk space on the root drive to create temporary files.
Uninstallation of a component fails
If an error message indicates that the uninstall wizard has failed while
uninstalling a component, you must restart the uninstallation, after having
resolved the problem that caused it to fail.
An error has occurred while removing the server component’s configuration
within the WebSphere Application Server
Open the WebSphere Application Server administration console and check
if the server component is still listed either as an Application Server on the
Node, or as an Enterprise Application Server. Attempt to use the remove
option, first for any entry as a Enterprise Application Server and then as an
Application Server.
You may need to close the WebSphere Application Server, or even reboot
the computer, to achieve success.
When the WebSphere Application Server configuration has been cleaned of
any references to the components, the problem has been resolved.
Dropping the Tivoli License Manager databases manually
The instructions for dropping the product databases differ, depending on the
platform on which they are installed:
Windows
See “Dropping the Tivoli License Manager databases on Windows”
UNIX See “Dropping the Tivoli License Manager databases on UNIX” on page
208
Dropping the Tivoli License Manager databases on Windows
To drop a Tivoli License Manager database on a Windows platform, complete the
following steps:
1. Log on to the DB2 server computer as Administrator or as a DB2
administrator, for example db2admin.
2. Open a DB2 command window.
3. To discover which databases are configured, enter the command:
db2 list database directory
4. To discover which nodes are configured, enter the command:
db2 list node directory
5. To drop the database, enter the command:
db2 drop database <database name>
where <database name> is one of the following names:
v tlma for the administration server database
v tlmr for the runtime server database6. To remove the database completely, enter the command:
db2 uncatalog database <database name>
where <database name> is one of the following names:
Uninstalling: servers and databases
Chapter 7. Uninstall Tivoli License Manager 207
v tlmadb for the administration server database
v tlmrdb for the runtime server database
Dropping the Tivoli License Manager databases on UNIX
To drop a Tivoli License Manager database on a UNIX platform, complete the
following steps:
1. If the DB2 server is installed on a different computer, log on to that computer
as a DB2 administrator, for example db2inst1, and load the DB2 environment
as described in step 3 on page 315 under “Disconnecting a Tivoli License
Manager database from its server” on page 315.
Alternatively, enter the command:
su – <DB2 instance owner>
The profile will automatically be loaded.
2. To discover which databases are configured, enter the command:
db2 list database directory
3. To discover which nodes are configured, enter the command:
db2 list node directory
4. On the DB2 server computer, drop the database by entering the command:
db2 drop database <database name>
where <database name> is one of the following names:
v tlma for the administration server database
v tlmr for the runtime server database
In addition, you should also drop the administration and runtime database
aliases tlmadb and tlmrdb, respectively.
5. To remove the database completely, enter the command:
db2 uncatalog database <database name>
where <database name> is one of the following names:
v tlmadb for the administration server database
v tlmrdb for the runtime server database6. You should also uncatalog the node, entering the following command:
db2 uncatalog node <database name>
where <database name> is one of the following names:
v tlmnodea for the administration server database
v tlmnoder for the runtime server database
Uninstalling the agent
The instructions for uninstalling an agent are different, depending on the platform:
v “Uninstall agents on Windows platforms” on page 209
v “Uninstall agents on UNIX platforms” on page 209
v “Uninstall agents on OS/400 platforms” on page 209
After completing the uninstallation of the agent you are recommended to reboot
the agent computer to clean the agent’s kernel extension from the operating
system’s memory.
Uninstalling: servers and databases
208 IBM Tivoli License Manager: Planning, Installation, and Configuration
Uninstall agents on Windows platforms
To uninstall the Tivoli License Manager agent from a Windows node, complete the
following steps:
1. On the node where the agent is installed, open a command prompt window.
2. Change to the directory:
%WINDIR%\itlm
3. Enter the command:
tlmunins.bat
If the agent is running it will be stopped. The agent files will be deleted.
Uninstall agents on UNIX platforms
To uninstall the Tivoli License Manager agent from a UNIX node, complete the
following steps:
1. On the node where the agent is installed, open a shell window.
2. Change to the directory:
/var/itlm
3. Enter the command:
./tlmunins.sh
If the agent is running it will be stopped. The agent files will be deleted.
Uninstall agents on OS/400 platforms
Agents can be uninstalled on iSeries nodes running OS/400 in the following ways:
v “Uninstall the OS/400 agent directly on an iSeries node”
v “Uninstall the OS/400 agent interactively from a Windows node” on page 210
v “Uninstall the OS/400 agent using DLTLICPGM” on page 211
Uninstall the OS/400 agent directly on an iSeries node
This option runs the OS/400 uninstall wizard in silent mode on the OS/400 node.
The steps are as follows:
1. Log in: Log in to the iSeries node as a user with rights to install programs.
2. Locate the uninstall wizard: The wizard file (uninstall.jar) is created when the
agent is installed in the following directory:
/QIBM/ProdData/QITLM/_uninst
3. Run the wizard in silent mode: Issue the following command:
RUNJVA CLASS(run) PARM(’-silent’)
CLASSPATH(’/QIBM/ProdData/QITLM/_uninst/uninstall.jar’)
The wizard will stop the agent and uninstall the agent files.
Note: The uninstall process does not remove the IFS directory
/QIBM/UserData/QITLM and its contents.
Uninstalling: agents
Chapter 7. Uninstall Tivoli License Manager 209
Uninstall the OS/400 agent interactively from a Windows node
The following describes the steps required to uninstall an OS/400 agent from a
connected Windows node.
1. Log in to Windows node: The Windows node must be connected to a network
in which the OS/400 node is accessible.
2. Copy the uninstall wizard files from the OS/400 node: Connect to the OS/400
node, and locate the following directory:
/QIBM/ProdData/QITLM/_uninst
This directory contains the following files:
uninstall.jar
uninstall.dat
3. Copy files to Windows computer: Copy (binary ftp) these files to a temporary
directory on the Windows computer.
4. Launch the wizard: Open a command line window, navigate to the temporary
directory and issue the following command:
java -classpath uninstall.jar run -os400
You will then be asked in a pop-up that appears in the top left corner of your
screen to identify and log in to the OS/400 node. Supply the following fields:
System
The name of the OS/400 node in the network
User ID
Supply the user ID of a user with sufficient rights to install programs.
Password
Enter the corresponding password.
Alternatively, you can add the node name, user ID, and password as variables
to the command, so that the login is performed automatically for you. In this
case, the command would have the format:
java -classpath uninstall.jar run -silent -os400 <node_name> <user_ID> <password>
For example, if the OS/400 node to which you were connected was called
″myNode″ and you wanted to log in as ″myRoot″ with a password of
″myPassword″, the command would be:
java -classpath uninstall.jar run -silent -os400 MyNode MyRoot MyPassword
However, if you choose this option, the password that you enter will be visible
as you type it in the command line. To ensure full security of the password, do
not use this option. Instead, use the option to enter the command without the
additional variables. The password is entered in the pop-up, where it is
displayed as asterisks in the standard way.
You are now logged in to the OS/400 node as the specified user. The OS/400
agent uninstall wizard window is opened and the Language Selection panel
displayed.
5. Select language: Select the language to be used for the wizard and click OK.
The Welcome page is displayed.
6. View Welcome page: Press Next.
Uninstalling: agents
210 IBM Tivoli License Manager: Planning, Installation, and Configuration
7. Uninstallation confirm: The uninstall summary panel is now displayed,
showing you what will be uninstalled. Click Next to confirm your choices and
go ahead with the uninstallation.
8. Finish: The wizard now uninstalls the agent on the OS/400 node, and displays
a panel confirming the outcome. The wizard stops the agent and deletes the
agents files. Click Finish to finish.
Note: The uninstall process does not remove the IFS directory
/QIBM/UserData/QITLM and its contents.
Uninstall the OS/400 agent using DLTLICPGM
The OS/400 agent can also be uninstalled by running the DLTLICPGM command
on the node where the agent is installed.
Note: If you want to be able to subsequently use the install wizard to install an
agent on the node, you must, after DLTLICPGM has completed successfully,
locate the file vpd.properties and delete the entry relating to the agent.
Uninstalling the catalog manager
This section describes how to uninstall the catalog manager.
You run the catalog manager uninstall wizard. The steps are as follows:
1. Log on to the computer where you want to uninstall the catalog manager as a
user with administrator rights (Administrator on Windows platforms or root
on UNIX platforms).
2. Close the catalog manager.
3. Run the uninstall wizard.
There are three possible ways of running the uninstall wizard:
Interactive mode
This uses a GUI that enables you to enter the required information
interactively on a series of panels.
It is invoked by launching the uninstaller.exe (Windows) or
uninstaller.bin command (UNIX) from the
<CATALOG_MANAGER_INSTALL_DIR>\_uninst directory without arguments.
Note: On UNIX platforms, there is a folder called deinst. This folder is
not the uninstall folder. It contains files used in the
uninstallation.
To uninstall the catalog manager from a computer with the interactive
wizard, complete the following steps:
a. Start the uninstall wizard.
Windows uninstaller.exe
UNIX uninstaller.bin
The wizard is located in the folder
<CATALOG_MANAGER_INSTALL_DIR>\_uninst.
Note: On Windows platforms, if Windows Terminal Server is
installed on the computer where you want to run the setup
file, or you are accessing another computer using Windows
Terminal Services, you must launch the uninstall wizard as
Uninstalling: agents
Chapter 7. Uninstall Tivoli License Manager 211
follows:
1) Select the Add/Remove Programs option from the
Control Panel.
2) Click on Tivoli License Manager and then on Remove or
Change/Remove, whichever is displayed.
This procedure ensures that the Windows computer is in
install mode when the setup file is launched.
The same objective can also be achieved by changing into
install mode manually, and then back again after the
uninstallation is complete. To change into install mode
manually, issue the command change user /install from a
Windows command line. Then issue the command to run the
setup file. After the uninstallation has completed, you must
issue the command change user /execute to return to execute
mode.
b. When the uninstallation is complete, delete the folder where the
catalog manager was installed, to ensure that all deleted logs and
data are removed from the file system.
Silent mode
The catalog manager uninstall wizard has no parameters. To run it in
silent mode, launch the uninstaller command with the following
argument:
uninstaller –silent
Note: On Windows platforms, if Windows Terminal Server is installed
on the computer where you want to run the setup file, or you
are accessing another computer using Windows Terminal
Services, you must launch the uninstall wizard by changing into
install mode manually, and then back again after the
uninstallation is complete.
To change into install mode manually, issue the command
change user /install from a Windows command line. Then issue
the command to run the setup file. After the uninstallation has
completed, you must issue the command change user /execute to
return to execute mode.
Using Tivoli Configuration Manager
If you installed the catalog manager using Tivoli Configuration
Manager, you can uninstall it by using the uninstall option in Tivoli
Configuration Manager.
Note: The wizard does not remove the catalog manager log files.
Uninstalling: catalog manager
212 IBM Tivoli License Manager: Planning, Installation, and Configuration
What to do if the catalog manager uninstallation fails
If the uninstallation fails, look in IBM Tivoli License Manager: Problem Determination
for details of what might have gone wrong and what remedial action to take.
Uninstalling: catalog manager
Chapter 7. Uninstall Tivoli License Manager 213
214 IBM Tivoli License Manager: Planning, Installation, and Configuration
Chapter 8. Upgrading from Tivoli License Manager for IBM
software
If you are using Tivoli License Manager for IBM software, and you have decided
to upgrade to Tivoli License Manager, the steps for performing that upgrade are
described in this section.
The steps are as follows:
1. Log on: Log on to the computer where the administration server database is
installed with Administrator (Windows) or root (UNIX) privileges.
2. Launch the wizard: Launch the install wizard, in exactly the same way as you
launched the wizard for the Tivoli License Manager for IBM software version
(see Chapter 2, “Install Tivoli License Manager main components,” on page 61
for instructions).
3. Accept the license agreement: The wizard will let you select the language,
display a welcome panel, and then a panel for the new license agreement.
When you have clicked Next on the License agreement panel, the wizard
detects that the currently installed components include the administration
server. It then installs the full version of the product on that server. No other
installation steps are required, and no interruption is made to the services being
provided by Tivoli License Manager for IBM software.
4. Optionally install the catalog manager: A catalog manager is provided with
Tivoli License Manager. You can now choose to install it, see Chapter 5, “Install
the catalog manager,” on page 187.
5. Optionally update the catalog: If you want to take advantage of the full IBM
catalog, which includes non-IBM products, download the catalog from the IBM
web site, and either use the catalog manager (described in IBM Tivoli License
Manager: Catalog Management) or the impcat command (described in IBM Tivoli
License Manager: Administration) to import the catalog file into the main
administration server catalog.
© Copyright IBM Corp. 2002, 2004 215
Upgrade from Tivoli License Manager for IBM Software
216 IBM Tivoli License Manager: Planning, Installation, and Configuration
Chapter 9. The agent
This chapter provides the following information about the agent:
v A general overview of agent functionality is at “Summary of agent
functionality.”
v For information about deploying the agent, see Chapter 4, “Deploy agents,” on
page 139.
v The deployment of an agent on an individual’s computer raises privacy issues.
See “Managing privacy policies for computers and users” on page 219.
v The deployment of the agent by other than Web registration requires you in
some way to distribute certain files from the runtime server to the agent. The
various agent deployment methods do not require you to manually copy these
files, but they are described here, for reference. See “Files required by the
installagent command” on page 219.
v The deployment of the agent installs a number of files on the monitored node.
See “Agent files” on page 221.
v If you want to perform actions on the agent, like starting and stopping it,
monitoring its status, and checking its connection to the runtime server, a variety
of commands are available, depending on the platform. See “Agent commands”
on page 227.
v Once the agent has communicated with the runtime server, and the runtime
server has passed the information on to the administration server, you can view
the information about the agent on the administration server GUI. See
“Reviewing and deleting agents” on page 231.
v If you want to assign the agent to a different runtime server or division, you can
have to redeploy the agent with the new parameters. See “Redeploying an
agent” on page 231.
v After the agent is installed, you can apply any upgrades to the agent code
automatically. See “Agent self-update” on page 231.
v The agent can be uninstalled from the node. See “Uninstalling the agent” on
page 208.
v If the agent has been uninstalled, and you no longer wish to monitor that node,
you can delete it from the database. See “Reviewing and deleting agents” on
page 231.
Summary of agent functionality
The agent component of Tivoli License Manager runs silently on the nodes where
it is deployed, performing the following tasks:
v Collect details of the node’s hardware and operating system, and of the software
installed on the node, and forward this information to the runtime server
Note: On OS/400 nodes only details of the node’s hardware and operating
system are collected.
v Identify the starting or stopping of a software product and communicate this
information to the runtime server so that a license can be assigned or released
and so that software usage information can be compiled
© Copyright IBM Corp. 2002, 2004 217
Each agent is associated with a single runtime server when it is deployed. The
agent makes the following exchanges of information with the runtime server at
regular intervals:
v It downloads the parameters defined in the agents settings section of the
system.properties configuration file held on the runtime server.
Among other things, these settings define how often uploads and downloads of
the different types of information are performed. See “Agent settings” on page
241.
v It downloads the runtime server catalog, which identifies the products that the
agent can monitor.
v It uploads information to the server about applications it has detected that are
not included in the runtime catalog.
v It downloads the definitions of monitoring system topology that have been
defined most recently.
v It uploads the information that it has collected in inventory scans.
v It communicates the starting and stopping of monitored applications and
requests the issue and release of licenses.
v It communicates usage information for monitored applications.
While the agent is running, it holds the information that it is working with in
memory. This includes the information that it has downloaded from the server, for
example, the monitoring system topology and runtime server catalog and
information that it has compiled, for example, unknown file information and
inventory scans. If the agent is stopped, the information held in memory is saved
to a cache so that it can be retrieved when the agent restarts. The agent also caches
inventory scan information if it fails to send it to the server. It will then try to
resend at a later time unless the scan has still not been sent when the next scan is
performed.
Although each agent is assigned to a specific runtime server, it does not need to be
limited to this server when requesting licenses. The agent has information about
other runtime servers in the topology information that it downloads. Depending
on the value of the requestScope parameter defined in the agent settings section of
the system.properties file, the agent can contact:
v All runtime servers
v Runtime servers that have agents in the same division
v Only the assigned runtime server
The selection of the language for the agent is based on user settings:
Windows The language selected is determined by the locale
set in the control panel Regional Options settings.
UNIX The language selected is determined by a hierarchy
of environment variables, as follows:
1. If the LC_ALL environment variable is set, the
language is determined from it.
2. If this is not set, the LC_MESSAGES environment
variable is used.
3. If this is not set, the LANG environment variable
is used.
4. If this is not set, the C locale is used.
Agent functionality
218 IBM Tivoli License Manager: Planning, Installation, and Configuration
OS/400 The language selected is determined by the
QLANGID environment variable.
You should adjust the date, time and time zone settings on each computer where
you plan to install an agent. It is not advisable to change these settings when Tivoli
License Manager is in use. However, if you need to change the date or time on a
computer where an agent is installed, you must stop the agent, change the date or
time, and then restart the agent again. See “Agent commands” on page 227 for
details of the commands to stop and start the agent.
Agent functionality on OS/400
Use metering on the OS/400 agent works in a different way than it does on the
agents on other platforms. The differences are as follows
The agent on other platforms performs use metering as follows:
v The agent downloads the entire catalog held by its runtime server
v It scans for the software on the node
v It assembles a list of recognized products
v It performs use metering on the products in the list
The agent on OS/400 performs use metering as follows:
v The agent downloads the OS/400 and Java products from the catalog held by its
runtime server
v It does not scan for software
v It performs use metering on all the OS/400 and Java products
The implication of this is that as the catalog of OS/400 and Java products grows,
so certain activities at the OS/400 agent become slower.
Managing privacy policies for computers and users
Tivoli License Manager gathers information about software usage and software
inventory on a computer, associating it with the user who logged on to the
computer. The Web UI enables the Super administrator to manage how this
information can be viewed, and by who. If this type of information gathering is
contrary to local information privacy regulations, you can prevent the information
from being available by uninstalling the agent from your computer, as described in
IBM Tivoli License Manager: Administration.
Files required by the installagent command
The installagent command requires that certain files are copied to the agent prior
to running the command (see “Deploying the agent manually (installagent
command)” on page 145). These files are normally collected together,
platform-by-platform, by a script. However, in case you need to do this activity
manually, the files are all found on the runtime server in a folder called:
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\webdoc\agent
This directory includes the following files which are required by the installagent
command:
Agent functionality
Chapter 9. The agent 219
<platform> A folder for each platform that contains the
agent code and the installagent command
files. You need not copy any subfolders in
this directory, but if you do it is no problem.
pdc_deploy In Windows only, a folder that contains the
files required by the Windows logon scripts
method of agent deployment.
security\cert.arm The SSL certificate. If you intend to use SSL
for agent communications, make sure you
have configured the product first to use SSL
between the agent and the runtime server.
That configuration may require you to
replace this file with one you have generated
or obtained yourself.
security\<platform>\gsk* A folder for the GSKit security software,
called security, which contains
sub-directories for each platform. The
appropriate GSKit software is a file in each
of these sub-directories.
wscanner\<platform>\wscanner.tar A folder for the scanner software, called
wscanner, which contains sub-directories for
each platform. The appropriate scanner
software is a file in each of these
sub-directories.
unix\Was_Cloning.sh A folder containing the WebSphere
Application Server environment
configuration file for all UNIX platforms.
Win32\Was_Cloning.bat A folder containing the WebSphere
Application Server environment
configuration file for Windows.
codeset Character conversion install file.
nls Language set install file.
tlmlog.properties Log configuration file.
Notes:
1. Each file has a corresponding file with the same name plus a .sign extension.
These files do not need also to be copied.
2. The contents of these files must not be changed by you except under the
instructions of IBM Software Support.
Collect all of the files indicated here into a flat temporary directory.
For example, on AIX, you would assemble the following files in the temporary
directory for distribution to the target node:
\security\cert.arm
\aix4\gskta.rte
\aix\installagent
tlmagent
Was_Cloning.sh
\wscanner\aix\wscanner.tar
The agent: files required by installagent
220 IBM Tivoli License Manager: Planning, Installation, and Configuration
codeset
nls
tlmlog.properties
This would result in the following temporary directory contents for AIX:
cert.arm
codeset
gskta.rte
installagent
nls
tlmagent
tlmlog.properties
Was_Cloning.sh
wscanner.tar
Agent files
The agent deployment and operation create a number of directories and files. The
logs and messages are stored in the Tivoli Common Directory; see the Appendix
on the Tivoli Common Directory in the IBM Tivoli License Manager: Problem
Determination.
The location of the other agent files depends on the platform on which the agent is
deployed.
v “AIX agent files”
v “HP/UX agent files” on page 222
v “Linux agent files” on page 223
v “OS/400 agent files” on page 224
v “Sun agent files” on page 225
v “Windows agent files” on page 226
AIX agent files
On AIX platforms, the agent files are created as follows:
Table 9. Agent files on AIX platforms
File Description
/usr/sbin/tlmagent The main agent file.
/etc/tlmagent.ini The agent configuration file.
/var/itlm/tlmunins.sh Uninstall agent script.
/var/itlm/tlmkagent.def Device configuration database definitions for
the agent kernel extension.
/dev/tlmkagent Character device file for communication
between the agent and the kernel extension.
/usr/lib/drivers/tlmkagent21xx
/usr/lib/drivers/tlmkreg21xx
/usr/lib/drivers/tlmkstub
The agent kernel extensions, where xx is the
version of the agent kernel extension.
/usr/lib/methods/deftlmkagent
/usr/lib/methods/cfgtlmkagent
/usr/lib/methods/chgtlmkagent
/usr/lib/methods/ucfgtlmkagent
/usr/lib/methods/undtlmkagent
Device configuration methods for the agent
kernel extensions.
/var/itlm/cache/ Folder for agent cache files.
The agent: files required by installagent
Chapter 9. The agent 221
Table 9. Agent files on AIX platforms (continued)
File Description
/var/itlm/codeset/ Folder containing files for conversions of
characters between different code sets.
/var/itlm/nls/ Folder containing a subfolder for each
supported language. The subfolders contain
the file where agent messages are defined.
<TivoliCommonDirectory>/COD/logs/agent/
trace/trace*.log
The agent log files. For more information see
the Appendix on the Tivoli Common
Directory in the IBM Tivoli License Manager:
Problem Determination.
<TivoliCommonDirectory>/COD/logs/agent/
messages/*.log
The agent message files. For more
information see the Appendix on the Tivoli
Common Directory in the IBM Tivoli License
Manager: Problem Determination.
<TivoliCommonDirectory>/COD/scripts/
agent/*.sh
The agent’s scripts. For more information
see the Appendix on the Tivoli Common
Directory in the IBM Tivoli License Manager:
Problem Determination.
/var/itlm/cache/licsref.dat The license status log file. It is only created
if the agent tracing is set to MAX.
/var/itlm/cache/unksref.dat The unknown files log file.
/var/itlm/wasagent/ Folder containing the files of the agent used
to identify applications running on
WebSphere Application Server.
/var/itlm/scanner/ Folder containing the software that performs
the inventory scan.
/var/itlm/keydb/ Folder for the SSL key database (key.kdb)
and password stash file (key.sth).
/etc/tlmlog.properties The configuration file for the agent logging
and tracing.
/tmp/itlm directory Contains communication socket files.
HP/UX agent files
On HP/UX platforms, the agent files are created as follows:
Table 10. Agent files on HP/UX platforms
File Description
/usr/sbin/tlmagent The main agent file.
/etc/tlmagent.ini The agent configuration file.
/var/itlm/tlmunins.sh Uninstall agent script.
/stand/dlkm/mod.d/tlmkagent21xx The agent kernel extension, where xx is the
version of the agent kernel extension.
/dev/tlmkagent21xx Character device file for communication
between the agent and the kernel extension.
/stand/system.d/tlmkagent21xx
/stand/build/mod_wk.d/tlmkagent21xx
/stand/dlkm/system.d/tlmkagent21xx
/usr/conf/master.d/tlmkagent21xx
/usr/conf/km.d/tlmkagent21xx
Files used to manage and configure the
kernel extension by the operating system.
Agent files
222 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 10. Agent files on HP/UX platforms (continued)
File Description
/var/itlm/cache/ Folder for agent cache files.
/var/itlm/codeset/ Folder containing files for conversions of
characters between different code sets.
/var/itlm/nls/ Folder containing a subfolder for each
supported language. The subfolders contain
the file where agent messages are defined.
<TivoliCommonDirectory>/COD/logs/agent/
trace/trace*.log
The agent log files. For more information see
the Appendix on the Tivoli Common
Directory in the IBM Tivoli License Manager:
Problem Determination.
<TivoliCommonDirectory>/COD/logs/agent/
messages/*.log
The agent message files. For more
information see the Appendix on the Tivoli
Common Directory in the IBM Tivoli License
Manager: Problem Determination.
<TivoliCommonDirectory>/COD/scripts/
agent/*.sh
The agent’s scripts. For more information
see the Appendix on the Tivoli Common
Directory in the IBM Tivoli License Manager:
Problem Determination.
/var/itlm/cache/licsref.dat The license status log file. It is only created
if the agent tracing is set to MAX.
/var/itlm/cache/unksref.dat The unknown files log file.
/var/itlm/wasagent/ Folder containing the files of the agent used
to identify applications running on
WebSphere Application Server.
/var/itlm/scanner/ Folder containing the software that performs
the inventory scan.
/var/itlm/keydb/ Folder for the SSL key database (key.kdb)
and password stash file (key.sth).
/etc/init.d/tlm Auto-startup script
/etc/tlmlog.properties The configuration file for the agent logging
and tracing.
Linux agent files
On Linux platforms, the agent files are created as follows:
Table 11. Agent files on Linux platforms
File Description
/usr/sbin/tlmagent The main agent file.
/etc/tlmagent.ini The agent configuration file.
/var/itlm/tlmunins.sh Uninstall agent script.
/var/itlm/tlmkagent Device configuration database definitions for
the agent kernel extension.
/lib/modules/tlmkagent-2_1_x_x.o The agent kernel extension, where x_x is the
version of the agent kernel extension.
/var/itlm/cache/ Folder for agent cache files.
/var/itlm/codeset/ Folder containing files for conversions of
characters between different code sets.
Agent files
Chapter 9. The agent 223
Table 11. Agent files on Linux platforms (continued)
File Description
/var/itlm/nls/ Folder containing a subfolder for each
supported language. The subfolders contain
the file where agent messages are defined.
<TivoliCommonDirectory>/COD/logs/agent/
trace/trace*.log
The agent log files. For more information see
the Appendix on the Tivoli Common
Directory in the IBM Tivoli License Manager:
Problem Determination.
<TivoliCommonDirectory>/COD/logs/agent/
messages/*.log
The agent message files. For more
information see the Appendix on the Tivoli
Common Directory in the IBM Tivoli License
Manager: Problem Determination.
<TivoliCommonDirectory>/COD/scripts/
agent/*.sh
The agent’s scripts. For more information
see the Appendix on the Tivoli Common
Directory in the IBM Tivoli License Manager:
Problem Determination.
/var/itlm/cache/licsref.dat The license status log file. It is only created
if the agent tracing is set to MAX.
/var/itlm/cache/unksref.dat The unknown files log file.
/var/itlm/wasagent/ Folder containing the files of the agent used
to identify applications running on
WebSphere Application Server.
/var/itlm/scanner/ Folder containing the software that performs
the inventory scan.
/var/itlm/keydb/ Folder for the SSL key database (key.kdb)
and password stash file (key.sth).
/etc/init.d/tlm Auto-startup script
/etc/tlmlog.properties The configuration file for the agent logging
and tracing.
OS/400 agent files
On OS/400 platforms, the agent files are created as follows:
Table 12. Agent files on OS/400 platforms
File Description
QITLMAGENT The main agent file (in the QITLM library).
EXITINST
EXITLANG
EXITUNINST
QITLMSTRAG
QITLMMSG
QITLMSAMSG
QITLMJOBD
WASAGTLCK
QITLMDFN
QITLMLANG
QITLMLOD
Miscellaneous agent files (in the QITLM
library).
/QIBM/UserData/QITLM/conf/tlmagent.ini The agent configuration file.
/QIBM/UserData/QITLM/cache/ Folder for agent cache files.
/QIBM/UserData/QITLM/keydb/ Folder for the SSL key database (key.kdb).
Agent files
224 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 12. Agent files on OS/400 platforms (continued)
File Description
/QIBM/UserData/QITLM/wasagent/ Folder containing the files of the agent used
to identify applications running on
WebSphere Application Server.
/QIBM/UserData/QITLM/tmp/ Temporary files.
/QIBM/ProdData/QITLM/codeset/ Folder containing files for conversions of
characters between different code sets.
/QIBM/ProdData/QITLM/keydb/ Folder for the SSL key database template file
(key.kdb).
/QIBM/ProdData/QITLM/nls/ Folder containing a subfolder for each
supported language. The subfolders contain
the file where agent messages are defined.
/QIBM/ProdData/QITLM/scripts/ Folder containing scripts.
/QIBM/ProdData/QITLM/_uninst/ Directory containing the uninstall files.
/QIBM/ProdData/QITLM/conf/tlmagent.ini The agent configuration template file.
<TivoliCommonDirectory>/COD/logs/agent/
trace/trace*.log
The agent log files. For more information see
the Appendix on the Tivoli Common
Directory in the IBM Tivoli License Manager:
Problem Determination.
Sun agent files
The agent files are created as follows:
Table 13. Agent files on Sun platforms
File Description
/usr/sbin/tlmagent The main agent file
/etc/tlmagent.ini The agent configuration file
/usr/kernel/drv/sparcv9/tlmkagent-2_1_x_x
The agent kernel extension (64 bit processor)
where x_x is the version of the agent kernel
extension.
/usr/kernel/drv/tlmkagent-2_1_x_x The agent kernel extension (32 bit processor)
where x_x is the version of the agent kernel
extension.
/usr/kernel/drv/tlmkagent-2_1_x_x.conf The agent kernel extension configuration
where x_x is the version of the agent kernel
extension.
/devices/pseudo/tlmkagent-2_1_x_x@0:0 Character device file for communication
between the agent and the kernel extension.
/var/itlm/tlmunins.sh Uninstall agent script
/var/itlm/cache/ Folder for agent cache files
/var/itlm/codeset/ Folder containing files for conversions of
characters between different code sets
/var/itlm/nls/ Folder containing a subfolder for each
supported language. The subfolders contain
the file where agent messages are defined.
Agent files
Chapter 9. The agent 225
Table 13. Agent files on Sun platforms (continued)
File Description
<TivoliCommonDirectory>/COD/logs/agent/
trace/trace*.log
The agent log files. For more information see
the Appendix on the Tivoli Common
Directory in the IBM Tivoli License Manager:
Problem Determination.
<TivoliCommonDirectory>/COD/logs/agent/
messages/*.log
The agent message files. For more
information see the Appendix on the Tivoli
Common Directory in the IBM Tivoli License
Manager: Problem Determination.
<TivoliCommonDirectory>/COD/scripts/
agent/*.sh
The agent’s scripts. For more information
see the Appendix on the Tivoli Common
Directory in the IBM Tivoli License Manager:
Problem Determination.
/var/itlm/cache/licsref.dat The license status log file. It is only created
if the agent tracing is set to MAX.
/var/itlm/cache/unksref.dat The unknown files log file.
/var/itlm/keydb/ Folder for the SSL key database (key.kdb)
and password stash file (key.sth).
/var/itlm/wasagent/ Folder containing the files of the agent used
to identify applications running on
WebSphere Application Server.
/etc/init.d/tlm Auto-startup script
/etc/tlmlog.properties The configuration file for the agent logging
and tracing.
Windows agent files
On Windows platforms, the agent files are created in the location:
%WINDIR%\itlm
Table 14. Agent files on Windows platforms
File Description
reboot_needed.txt A flag file, the presence of which tells the agent that
the node may need rebooting. The file remains in
place until the next reboot. If, when the agent was
installed, the GSKit installation was not able to
complete because a pre-existing version of GSKit was
in use on the computer, a flag is set inside the file
that tells the agent not to run. In this case, the
installation of GSKit is completed after the next
reboot, after which the agent will be able to start.
tlmagent.exe The main agent file.
tlmagent.ini The agent configuration file.
tlmkagent-2_1_x_x.sys The agent kernel extension, where x_x is the version
of the agent kernel extension.
tlmlog.properties The configuration file for the agent logging and
tracing.
tlmunins.bat Uninstall agent script.
Agent files
226 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 14. Agent files on Windows platforms (continued)
File Description
<TivoliCommonDirectory>/
COD/logs/agent/trace/trace*.log
The agent log files. For more information see the
Appendix on the Tivoli Common Directory in the
IBM Tivoli License Manager: Problem Determination.
<TivoliCommonDirectory>/
COD/logs/agent/messages/*.log
The agent message files. For more information see the
Appendix on the Tivoli Common Directory in the
IBM Tivoli License Manager: Problem Determination.
<TivoliCommonDirectory>/
COD/scripts/agent/*.sh
The agent’s scripts. For more information see the
Appendix on the Tivoli Common Directory in the
IBM Tivoli License Manager: Problem Determination.
cache\ Folder for agent cache files.
cache\licsref.dat The license status log file. It is only created if the
agent tracing is set to MAX.
cache\unksref.dat The unknown files log file.
codeset\ Folder containing files for conversions of characters
between different code sets.
keydb\ Folder for the SSL key database (key.kdb) and
password stash file (key.sth).
nls\ Folder containing a subfolder for each supported
language. The subfolders contain the file where agent
messages are defined.
scanner\ Folder containing the software that performs the
inventory scan.
tmp\ Temporary folder used by the agent.
wasagent\ Folder containing the files of the agent used to
identify applications running on WebSphere
Application Server.
Agent commands
You can perform some agent tasks from the command line. This section details the
commands that can be used on the different platforms.
The agent commands are issued by entering the following at the command line.
tlmagent <parameter>
Where <parameter> is one of the parameters described in Table 15.
Table 15. Tlmagent command parameters
Parameter Windows AIX Sun,
Linux,
HP/UX
OS/400 Agent
must be
running?
Description
–g X X No Start the agent service.
–e X X X Yes Stop the agent service.
–capture X X X X Copy the agent’s trace and message files to the
ffdc\agent sub-directory of the Tivoli Common
Directory. These files are then available for remote
support analysis.
Agent files
Chapter 9. The agent 227
Table 15. Tlmagent command parameters (continued)
Parameter Windows AIX Sun,
Linux,
HP/UX
OS/400 Agent
must be
running?
Description
–p X X X X Ask the agent to plug in to the runtime server.
The agent must be running, and the plug in will
be performed immediately.
–s X X X Yes Ask the agent to run an inventory scan and send
it to the runtime server. The command does not
execute the scan, it just requests it. The request
will be performed as soon as possible by the
agent.
–v X X X Display the agent’s version.
–r X X X No De-register the kernel extension and remove its
files. The agent must be stopped first. On
Windows the agent is also removed from the
Services list.
–reload X X X X Yes Reload the agent’s configuration file and restart
the trace using the new configuration data.
–i X Install the agent as a service on Windows
platforms.
Notes:
1. On Windows platforms, commands must be run from the %WINDIR%\itlm folder,
or the command must be included in the PATH variable. The user must be
″Administrator″.
2. On UNIX platforms, commands must be run from the /usr/sbin folder, or the
command must be included in the PATH variable. The user must be ″root″.
3. On OS/400 platforms the commands are issued with a call statement having
the syntax:
CALL QITLM/QITLMAGENT PARM(’<parameter>’)
Where <parameter> is the value of the supported parameter from the table
below. For example:
CALL QITLM/QITLMAGENT PARM(’-p’)
The user must be ″QITLM″ or must have User Class *SECOFR.
AIX – additional commands
Table 16 lists the additional commands available on AIX platforms, and which use
the AIX System Resource Controller (SRC).
Table 16. Agent commands on AIX platforms
Task Command
Start the agent /usr/bin/startsrc -s tlmagent
Stop the agent /usr/bin/stopsrc -s tlmagent
Show the status of the agent /usr/bin/lssrc -s tlmagent
Reload the agent configuration
file
/usr/bin/refresh -reload
Agent commands
228 IBM Tivoli License Manager: Planning, Installation, and Configuration
HP/UX – additional commands
Table 17 lists the additional commands available on UNIX platforms other than
AIX.
Table 17. Agent commands on UNIX platforms
Task Command
Start the agent /sbin/init.d/tlm start
Stop the agent /sbin/init.d/tlm stop
Reload the agent configuration
file
/sbin/init.d/tlm reload
kill -SIGHUP tlmagent_PID
Copy the agent’s trace and
message files to the ffdc\agent
sub-directory of the Tivoli
Common Directory. These files
are then available for remote
support analysis.
/sbin/init.d/tlm capture
Sun and Linux platforms – additional commands
Table 18 lists the additional commands available on Sun and Linux platforms
Table 18. Agent commands on Sun and Linux platforms
Task Command
Start the agent /etc/init.d/tlm start
Stop the agent /etc/init.d/tlm stop
Reload the agent configuration
file
/etc/init.d/tlm reload
kill -SIGHUP tlmagent_PID
Copy the agent’s trace and
message files to the ffdc\agent
sub-directory of the Tivoli
Common Directory. These files
are then available for remote
support analysis.
etc/init.d/tlm capture
OS/400 platforms – additional commands
Table 18 lists the additional commands available on OS/400.
Table 19. Agent commands on OS/400 platforms
Task Command
Start the agent strtcpsvr server(*itlmagent)
Stop the agent endtcpsvr server(*itlmagent)
Agent commands
Chapter 9. The agent 229
WebSphere Application Server agent commands
If you have WebSphere Application Server deployed on an agent, an additional
agent process is used, which detects products running on WebSphere Application
Server. This process is the WebSphere Application Server agent, normally referred
to as the wasagent.
The wasagent has a small set of commands available to it. To access its command
line, take the following steps:
1. Log on to the agent computer as Administrator or root.
2. Navigate to the wasagent directory. The location of the directory is indicated for
each platform in “Agent files” on page 221.
3. Run the following script to initialize the command line:
Windows WASAgentClient.bat
UNIX WASAgentClient.sh
This enables the wasagent environment.
4. Issue any of the commands in Table 20.
Table 20. Agent commands on OS/400 platforms
Task Command
Set the security cell access credentials for
any server identified by the servers
command, where:
<serverID>
From the list identified by the
servers command.
<userName>
The user name for the security cell.
<password>
The password for the security cell.
credentials <serverID> <userName>
<password>
Exit from the wasagent command line. exit
Copy the wasagent’s trace and message files
to the ffdc\wasagent sub-directory of the
Tivoli Common Directory. These files are
then available for remote support analysis.
ffdc
Display help on the wasagent command
line.
help
Reload the log configuration file (itlm.log). reloadconf
List all of the application servers discovered
by the wasagent. The information displayed
includes a unique server ID (to be used in
the credentials command), its state, and
other information.
servers
Agent commands
230 IBM Tivoli License Manager: Planning, Installation, and Configuration
Reviewing and deleting agents
You can use the administration server to review details of the agents that are
deployed and to delete the agents from the database when they are no longer
needed.
Note: You do not need to delete the agent before redeploying. The delete agent
function is intended for the situation where a node is no longer being
monitored.This function is described in full in IBM Tivoli License Manager: Administration.
Redeploying an agent
There are some circumstances in which you need to redeploy the agent on a node:
v You change the server name or port of the runtime server after the agent has
been deployed or you decide to monitor the node using a different server or to
assign the agent to a different division.
In this case, you should simply follow the deploy procedure again. You do not
need to uninstall the agent.
v A newer version of the agent is available on the runtime server with which the
agent is registered.
In this case, you can use the agent self-update facility. See “Agent self-update”
for information about this facility and how to enable it.
Agent self-update
If you receive a fix pack or interim fix that contains an upgrade to the agent, first
install the fix pack or interim fix on the runtime server. Then, on all agent
platforms except OS/400, you can automatically upgrade all the agents that are
connected to the runtime server, as follows:
1. Edit the agent settings section of the system.properties file on each runtime
server, and change the updateAgentEnabled parameter to Yes.
2. Stop and restart the runtime server so that the changed configurations take
effect.
Following the next download of agent parameters to agents, the agents will start to
check the runtime server for a changed version of the appropriate agent files. The
maximum interval between checks is defined by the updateAgentPeriod. When a
new version of the agent files is found, the agent downloads the files and applies
the new version.
To discover whether a particular agent has been upgraded look at its version
number in the agent details listing on the administration server GUI (Manage
Components � Agents, and then select an agent).
To view a listing of agents showing their version numbers, select Manage
Components � Servers � View Agents on the administration server GUI.
To see which agents are at a particular level, say version 2.1, for example, run the
following query from the DB2 command line: select
hostname,ip_address,os_version from adm.agent where version = ’2.1.0’.
When all agents have been upgraded, reset the updateAgentEnabled parameter to
No and restart the runtime server.
The agent: reviewing and deleting
Chapter 9. The agent 231
232 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix A. Configuration settings
This appendix provides information about the configuration files maintained for
each Tivoli License Manager server and how you can use some of them to tune
Tivoli License Manager to suit your needs. It includes the following information:
v A summary of the configuration files that are installed for each Tivoli License
Manager server. See “Tivoli License Manager configuration files.”
v A detailed description of the main server configuration file, the
system.properties file. See “The system.properties file” on page 235.
v A detailed description of the configuration file that controls the communications
between a runtime server and its administration server. See “The
communication.properties file” on page 244.
v A detailed description of how to backup and restore your configuration files. See
“Backup and restore of configuration files” on page 246.
Tivoli License Manager configuration files
Configuration files are installed in the following locations:
Administration server
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\conf
Runtime server
<INSTALL_DIR>\runtime\SLM_Runtime_Application.ear\slm_runtime.war\WEB-INF\conf
Table 21 provides a summary of the Tivoli License Manager configuration files that
you may edit. Not all files are present on both servers.
Table 21. Configuration files for Tivoli License Manager servers
File Server Usage
agent_install.properties Runtime Contains the information required to download and install
agents from the runtime server. Settings for debugging and
tracing deployment are described in the IBM Tivoli License
Manager: Problem Determination. Settings for proxy
communications between the runtime server and agents are
described in “Configuring proxy servers” on page 131.
Settings that determine whether the Web registration facility is
to automatically use information on the computers that are
registering is described in “Automatic computer label
assignment” on page 132.
You should not change any other parameters in this file.
© Copyright IBM Corp. 2002, 2004 233
Table 21. Configuration files for Tivoli License Manager servers (continued)
File Server Usage
communication.properties Runtime Contains the server and organization names specified when the
runtime server was installed, and the address at which the
runtime server contacts the administration server. If any of
these values are entered incorrectly at installation, or have to
change during the life of the runtime server, you can edit the
values in this file.
See “The communication.properties file” on page 244.
For more details about defining a proxy server for the
administration server communication, see “Configuring proxy
servers” on page 131.
log.properties Administration and
runtime
Defines the trace parameters for the server. See the IBM Tivoli
License Manager: Problem Determination for full details. These are
the only parameters that can be changed and reloaded while a
server is running. See the logreload command, documented in
IBM Tivoli License Manager: Problem Determination.
system.properties Administration and
runtime
See “The system.properties file” on page 235.
Attention: All other configuration files must not be edited except under direct
instruction from IBM Software Support personnel.
Default values in configuration files
The parameters in the configuration files are supplied with defaults on installation.
These defaults are shown in the tables in this appendix that describe the
parameters. The defaults are designed for a representative environment which has
the characteristics shown in Table 1 on page 10.
If your environment is significantly different to this you should look at the
description of each of the parameters provided in this appendix, and determine
whether the value should be changed, to provide enhanced performance or
more-readily-available information. For example, if your environment is much
smaller than this, and you would like usage statistics and changed inventory
information to be available to reports more quickly, you can reduce the intervals
between uploads and downloads of information between the administration and
runtime servers.
Note: Remember that for any changes to a configuration file to take effect, you
should stop and restart the appropriate component after changing the file.
Ranges in configuration file tables
In this appendix are tables of the configuration parameters that you are able to
change to control the performance of the product. In these tables, for many
parameters, are detailed ranges of values, outside which you are not recommended
to set the values. These ranges are advisory – the product does not check that the
values fall within them. You are just advised that to go outside these ranges may
adversely affect the performance of the product.
Configuration files
234 IBM Tivoli License Manager: Planning, Installation, and Configuration
The system.properties file
A system.properties file is installed on the administration server and on each
runtime server. The system.properties file has the following sections:
v Web interface settings.
These settings affect the behavior of the Web interfaces on the administration
and runtime servers. Most settings in this section should not be changed. See
“Web Interface settings” on page 236 for those that can be changed.
v Administration server settings.
The settings in this section are relevant only to the system.properties file that
resides on the administration server. See “Administration server settings” on
page 237.
v Runtime server settings.
These settings affect the behavior of the runtime server, for example, the time
delays used between repeats of a task. Each runtime server has its own
system.properties file, so settings can be different for each server. See “Runtime
server settings” on page 239.
v Agent settings.
The agent settings that are defined in the system.properties file located on a
runtime server are effective for all the agents that are registered with that server.
Agent settings are downloaded from the runtime server to the agent at defined
intervals. See “Agent settings” on page 241.
v E-mail configuration settings.
These settings enable the sending of event notifications that are generated on the
server. See “E-mail configuration settings” on page 243.
Many of the configuration parameters refer to the timing of events and services,
and these timings are discussed first, to put the individual parameters in context.
Timing of events and services
The timing of events, in particular of services, on the administration and runtime
servers is determined by two factors: the start time and the period between events.
Each event has a parameter that determines its frequency. The start time is either
determined by the time that the server last started, or by the parameters
adminBaseTime and runtimeBaseTime, respectively.
It works like this. If the frequency of an event or service is exactly 1, 2, 3, 4, 6, 8, 12
or 24 hours (whether its measurement metric is minutes, hours or days), that event
or service will use the appropriate <server>BaseTime parameter as its start time.
The <server>BaseTime parameter can take any integer value between 0 and 23, and
each integer represents an hour on the 24-hour clock of the timezone where the
server is running (thus, for example, the value 22 equates to 22:00 or 10:00 pm.)
What this means is that tasks with these frequencies will always take place at the
exact same time each day.
What about the other frequencies? Well, if the frequency of an event period is
exactly one week (10080 minutes, 168 hours or 7 days) it will take place on
Saturday at the time determined by the <server>BaseTime parameter. This also
applies if the parameter value is an exact multiple of weeks.
Finally, if the frequency of an event or service is not 1, 2, 3, 4, 6, 8, 12 or 24 hours,
or a week or a multiple of weeks, the event and service timer on the server starts
counting the frequency period from a common fixed basetime.
Configuration settings: system.properties
Appendix A. Configuration settings 235
The following are some examples:
v Service A needs to be run every 4 hours. Set the frequency to 240 minutes (most
frequencies are expressed in minutes) whatever value you give to
<server>BaseTime, the service will be run every four hours from that time. If
you set it to 22 the service will run at 02:00, 06:00, 10:00, 14:00, 18:00 and 22:00.
v Event B needs to be run weekly. Set the frequency to 10080 minutes and the
<server>BaseTime to 22, and it will be run at 10:00 pm on Saturday nights.
v Event C must be run daily. Set the frequency to 1440 hours, and the event will
be run exactly at the time specified in <server>BaseTime.
Synchronizing the servers’ base times
There are several factors that can affect the way you should set the BaseTime
parameters of the servers:
v The administration server should not have the same BaseTime as any of the
runtime servers. This is because you do not want the administration server to be
running its periodic database services while the runtime servers are trying to
send it data.
v The runtime servers’ BaseTimes should ideally be set so that they have time to
upload a day’s activities before the administration server starts to process them
(the default period for many services is one day). You will notice that the
administration server’s default setting is 23 (23:00), while the runtime server’s is
22 (22:00).
v Not more than three runtime servers should have the same BaseTimes, and if
possible they should each have their own. For example, if you had four runtime
servers, their BaseTimes could be 21, 22, 23, and 0, while the administration
server’s could be 1.
v BaseTimes apply to local time, so in making the above calculations, you should
take into account any time zone differences between the locations of the servers.
Web Interface settings
Table 22 shows parameters defined in the Web interface section of the
system.properties file that you may need to change. You should not change any
other setting in this section of the configuration file.
Table 22. Web interface parameters in the system.properties file
Parameter
Units Default Minimum Maximum
Description
maxSelectionListLength items 5000 1 65535
Defines the maximum number of items that can be displayed in a list box on the Web
interface. Probably the longest list box in use on the GUI is the list of vendors, used,
for example, on the Installs History Report.
Increasing this value can cause decreased performance of the Web interface.
privacyPolicyInfoAllowed boolean true true false
Possible values are:
true The privacy policy statement panel must be accessible from an icon on the
administration and runtime Web UI toolbars. Further, the same information
must be displayed to users when attempting to register their computers with
a runtime server.
false No privacy policy information is displayed by any server.
Configuration settings: system.properties
236 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 22. Web interface parameters in the system.properties file (continued)
Parameter
Units Default Minimum Maximum
Description
sessionTimeout minutes 30 10 30
Determines the maximum inactive time on the product’s Web user interface before a
user is automatically logged off.
minimumPasswordLength characters 6 6 10
Determines the minimum required length of the password that you create when you
use the Manage Accounts � Create facility on the Web interface to create an account.
secureData boolean false true false
If true, determines that confidential transactions (login, create and change user
password, create and change runtime password) will be sent using the HTTPS
protocol, regardless of the protocol chosen by the user in the browser (both browser
and server must be enabled to use both HTTP and HTTPS communications).
securePort integer 443 1 65535
If secureData is true, determines the server port to be used by the browser for secure
communications when performing one of the secure transactions.
Administration server settings
Table 23 shows the parameters defined in the administration server settings section
of the system.properties file.
Table 23. Administration server parameters in the system.properties file
Parameter
Units Default Minimum Maximum
Description
adminBaseTime hour of the day 23 0 23
The hour of the day (from 0 to 23) used as a base time from which to calculate when
to perform tasks that need to be performed at the same time or times each day, or
once per week on Saturdays. See “Timing of events and services” on page 235 for full
details.
cleanUsagePeriod minutes 1440 (1 day) 60 10080 (1 week)
The interval between cleanups of the unaggregated software use database tables.
Each cleanup is logged in the server trace file.
See Appendix E, “Database table cleanup,” on page 301 for more details.
Configuration settings: system.properties
Appendix A. Configuration settings 237
Table 23. Administration server parameters in the system.properties file (continued)
Parameter
Units Default Minimum Maximum
Description
maxUsageAge days 30 1 360
The number of days that software usage data will be retained in the unaggregated
software use database tables.
Once data is older than the specified number of days, it is cleared by the regular
cleanup process.
This setting has a significant impact on the performance when producing the Use
Snapshot and Use Trend reports. The fewer days data are retained, the better the
performance. However, if you don’t use these reports you may set a longer period.
To determine the maximum setting for your environment, use the following
procedure:
1. Firstly, consider that 35 to 40 million is the maximum number of lines that can
accumulate in the table where this data is stored, before a significant impact on
performance is noticed when producing these reports.
2. Determine how fast you are accumulating data by running this query at the DB2
command line:select date(END_TIME) as DATE, count(ID) as NUM from
adm.usage_comp group by date(END_TIME). This creates a list of the number of
completed software use sessions per day.
3. Use these figures to determine the average rate at which you are accumulating
data and divide that daily rate into 40 million to get the maximum number of days
data you can keep in the table before noticing a performance impact.
See also Appendix E, “Database table cleanup,” on page 301.
aggregateUsagePeriod minutes 1440 (1 day) 60 10080 (1 week)
The interval between aggregations of the unaggregated software use database tables.
The aggregation process aggregates qualifying usage information (see
maxAggregateUsageAge) by component, division, and license, and stores it in the
corresponding history tables.
Each aggregation is logged in the server trace file.
maxAggregateUsageAge days 3 1 14
The age of the usage data (in days) before it will be included in the aggregations of
the unaggregated software use database tables. This setting is used to ensure that all
the relevant data for an aggregation has arrived at the administration server, taking
into account the frequency with which it is uploaded from the agent to the runtime
server and the frequency with which it is uploaded from the runtime server to the
administration server.
Configuration settings: system.properties
238 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 23. Administration server parameters in the system.properties file (continued)
Parameter
Units Default Minimum Maximum
Description
serverWakeUpEnabled boolean true true false
Possible values are:
true The administration server checks if changes have been made to certain
information that the runtime server needs.
If changes have been made since the last contact with a runtime server, it
sends a wake-up call to the runtime server that prompts the runtime server to
start its normal download behavior from the administration server without
waiting for its own configured download wait period (adminDownloadPeriod)
to expire. The interval between the checks is determined by
serverWakeUpPeriod.
If this parameter is enabled, adminDownloadPeriod at the runtime servers can
be set to a long period, as the administration server will determine the
frequency of its downloads by issuing a wake up call.
Each wake-up call is logged in the server trace file.
false The administration server does not check for changes.
serverWakeUpPeriod minutes 120 10 1440 (1 day)
This parameter is only used if serverWakeUpEnabled is set to true. It defines the
interval between checks for changes in information of interest to runtime servers.
It should be set to less than the adminDownloadPeriod, otherwise the wake up call will
never take place.
maxServerInactivity minutes 2880 (2 days) 1440 (1 day) 129660 (3 months)
Determines the length of time that the administration server waits without receiving a
communication from a runtime server before it declares the runtime server inactive.
activateProductsEnabled boolean true true false
Determines whether to run the background task that enables license monitoring for all
product releases having at least one use license assigned to the release itself, or to the
corresponding version or product. Installation licenses are ignored, and have no
influence on this task. The task is run by default, but if you need to disable a use
license for a product, you need to set this value to ″false″ during the period you want
the use license to be disabled. You can then enable or disable the monitoring of
individual licensed releases product-by-product.
Runtime server settings
Table 24 shows the parameters defined in the runtime server settings section of the
system.properties file.
Table 24. Runtime server parameters in the system.properties file
Parameter
Units Default Minimum Maximum
Description
runtimeBaseTime hour of the day 22 0 23
The hour of the day (from 0 to 23) used as a base time from which to calculate when
to perform tasks that need to be performed at the same time or times each day, or
once per week on Saturdays. See “Timing of events and services” on page 235 for full
details.
Configuration settings: system.properties
Appendix A. Configuration settings 239
Table 24. Runtime server parameters in the system.properties file (continued)
Parameter
Units Default Minimum Maximum
Description
runtimePluginPeriod minutes 60 1 60
The interval between attempts to plug the runtime server to the administration server,
only used if a plug-in has failed.
Each plug-in attempt is logged in the server trace file.
inventoryUpdatePeriod minutes 1440 (1 day) 60 10080 (1 week)
This parameter only applies to version 1.1.1 agents. It determines the length of time
that the server waits before checking to see whether it has received any inventory
scans from 1.1.1 agents and needs to update its inventory.
When the scans arrive from the version 1.1.1 agents, they are stored until the next
update time.
Each check is logged in the server trace file.
Version 2.1 agents use a different method and do not rely on this value.
cacheUpdatePeriod minutes 1440 (1 day) 60 10080 (1 week)
The interval between updates of the runtime cache.
At this interval, the runtime server processes the unknown file information that has
arrived from the agents since the last update and determines which can be added to
the runtime catalog. It also updates the cache of products monitored, based on the
license requests it has received for uncached products.
Each update is logged in the server trace file.
adminDownloadPeriod minutes 1440 (1 day) 60 10080 (1 week)
The length of time that the server waits between requesting downloads of updated
license, catalog, and topology information from the administration server.
If you have enabled the runtime server wake-up facility on the administration server,
the runtime server will perform an additional download when it receives a wake-up
call from the administration server.
Each download is logged in the server trace file.
adminUploadPeriod minutes 1440 (1 day) 60 10080 (1 week)
The length of time that the server waits between uploading software inventory and
agent information to the administration server.
Each upload is logged in the server trace file.
licenseCleanUpPeriod minutes 360 (6 hours) 60 720 (12 hours)
The length of time that the server waits between checks on license confirmations sent
by agents.
If the server does not find a confirmation that a license is still in use, it releases the
license even if no specific release request has been received.
Each check is logged in the server trace file, and each clean-up event is logged in the
server log event file.
Configuration settings: system.properties
240 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 24. Runtime server parameters in the system.properties file (continued)
Parameter
Units Default Minimum Maximum
Description
usageSnapshotPeriod minutes 360 (6 hours) 60 720 (12 hours)
The interval between uploads of software usage snapshots to the administration
server.
Snapshots are sent periodically to enable repair of the usage history if any software
usage information is lost.
This parameter should not be set to less than 120 minutes.
Each upload is logged in the server trace file.
maxAgentInactivity minutes 10080 (1 week) 1440 (1 day) 129600 (3 months)
The maximum time that an agent does not communicate before it is considered
inactive.
This period must not be lower than the downloadParametersPeriod defined in the
agent settings section of this file.
storeHost boolean true true false
This is used to implement the privacy policy. The permitted values are:
true Information regarding the identification of the node (host) is recorded with
the usage data.
false No information regarding the identification of the node (host) is recorded
with the usage data.
storeUser boolean true true false
This is used to implement the privacy policy. The permitted values are:
true Information regarding the identification of the user is recorded with the
usage data.
false No information regarding the identification of the user is recorded with the
usage data.
storeGroup boolean true true false
This is used to implement the privacy policy. The permitted values are:
true Information regarding the identification of the user group is recorded with
the usage data.
false No information regarding the identification of the user group is recorded
with the usage data.
Agent settings
Table 25 on page 242 shows the parameters defined in the agent settings section of
the system.properties file.
Configuration settings: system.properties
Appendix A. Configuration settings 241
Table 25. Agent parameters in the system.properties file
Parameter
Units Default Minimum Maximum
Description
requestScope numeric 2 0 2
Controls the runtime servers that an agent can contact. Possible values are:
0 Only the server with which the agent is registered
1 Any server that serves agents in the agent’s division.
2 All runtime servers registered for the organization.
checkPeriod minutes 180 (3 hours) 180 (3 hours) 1440 (24 hours)
The interval between checks by the agent on licenses that have been granted.
If a license is no longer in use, the agent releases it. If the license is in use, the agent
sends a confirmation to the runtime server.
Each check is logged in the agent trace file.
pingPeriod minutes 60 (1 hour) 60 (1 hour) 360 (6 hours)
The length of time that the agent waits between checks of the connection to its
runtime server.
Each check is logged in the agent trace file.
downloadParametersPeriod minutes 1440 (1 day) 720 (12 hours) 10080 (1 week)
The interval between downloads of the agent parameters from the system.properties
file on the runtime server. In addition to the parameters, at each download the agent
checks the date of the last catalog update at the runtime server, and also downloads
the catalog if its own catalog is older.
Each download is logged in the server trace file.
downloadCatalogPeriod minutes 1440 (1 day) 720 (12 hours) 10080 (1 week)
This parameter only applies to version 1.1.1 agents. It determines the interval between
downloads of the runtime catalog from the runtime server.
Each download is logged in the server trace file.
downloadTopologyPeriod minutes 1440 (1 day) 720 (12 hours) 10080 (1 week)
The interval between downloads from the runtime server of information about the
Tivoli License Manager infrastructure.
Each download is logged in the server trace file.
offlineUsagePeriod minutes 360 (6 hours) 360 (6 hours) 10080 (1 week)
The interval between uploads of offline usage information from the agent to the
runtime server.
Each upload is logged in the server trace file.
uploadMinTime minutes 180 (3 hours) 180 (3 hours) 1440 (24 hours)
The interval between uploads of unknown file information from the agent to the
runtime server. The upload service is only run if there is information on unknown
files to upload.
Each upload is logged in the server trace file.
Configuration settings: system.properties
242 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 25. Agent parameters in the system.properties file (continued)
Parameter
Units Default Minimum Maximum
Description
updateAgentEnabled yes/no no yes no
Indicates whether self-updating by agents is enabled.
If this parameter is set, the agent regularly checks the runtime server for a new
version of the agent and if it finds one, it automatically triggers deployment using the
server and division of the current deployment.
The permitted values are YES, Yes, yes, NO, No, no.
updateAgentPeriod minutes 10080 (1 week) 10080 (1 week) 129600 (3 months)
The interval between checks for the presence of a new version of the agent on the
runtime server.
Each check is logged in the server trace file.
E-mail configuration settings
Table 26 shows the parameters defined in the e-mail configuration settings section
of the system.properties file. The settings relate to notifications generated on the
server where the system.properties file is located. On the administration server,
notifications relate to license events. On the runtime servers, notifications are
generated in response to changes in server or agent status and to the completion of
inventory scans. For more information about notifications, see the chapter on event
logging and notifications in IBM Tivoli License Manager: Problem Determination.
Table 26. E-mail configuration parameters in the system.properties file
Parameter
Units Default Minimum Maximum
Description
smtpServer text
The host name or IP address of a valid SMTP server.
The text must include only US ASCII characters.
mailSender text
The e-mail address that is to be used by the server as the sender address when
notifications are generated.
The text must include only US ASCII characters.
mailRecipient text
An e-mail address to which optional, additional notifications should be sent.
Tivoli License Manager administrators are the normal recipients of notifications, and
you can specify this when you create an administrator using the Web interfaces.
Configuration settings: system.properties
Appendix A. Configuration settings 243
The communication.properties file
The parameters defined in the communication.properties file control the
communications between the runtime server and its administration server. Some of
the parameters must not be changed if the connection to the database is to function
correctly.
Table 27 shows the parameters defined in the communications.properties file.
Table 27. Parameters in the communications.properties file
Parameter
Units Default Minimum Maximum
Description
server text Created during the
runtime server
installation.
The host name or IP address of the administration server.
This value can be changed if the wrong value is input during the runtime server
installation, or if the server address changes during normal use.
port numeric Created during the
runtime server
installation.
The port used for insecure communication with the administration server.
This value can be changed if the wrong value is input during the runtime server
installation, or if the port changes during normal use.
URI text /slmadmin/service
The administration server servlet path.
This value must not be changed.
enableSSL boolean Created during the
runtime server
installation.
true false
The permitted values are:
true SSL communication is used between the runtime server and its
administration server.
false Communication between the runtime server and the administration server
does not use SSL.
This value can be changed if an error is made during the runtime server installation,
or if you decide to change the mode of the communication during normal use.
If you change this value to true you must give correct values also for SSLPort and
forceSSL.
If you change this value to false, the other SSL parameters are ignored.
SSLPort numeric Created during the
runtime server
installation.
If enableSSL is set to true, this parameter must be set to the port used for SSL
communication with the administration server.
This value can be changed if the wrong value is input during the runtime server
installation, or if the SSL port changes during normal use.
Configuration settings: communication.properties
244 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 27. Parameters in the communications.properties file (continued)
Parameter
Units Default Minimum Maximum
Description
forceSSL boolean true true false
The permitted values are:
true The SSL protocol is used for all communication between the runtime server
and the administration server, overriding any settings to the contrary on the
runtime server.
false SSL communication is only used for selected communications between the
runtime and the administration servers, as defined by the settings on the
runtime server. For your information, these settings can be found in the file
scpServices.xml, but this file must not be modified.
useProxy boolean false true false
The permitted values are:
true The administration server is protected behind a proxy server.
false The administration server is not protected behind a proxy server.
If you change this value to true you must give correct values also for proxy and
proxyPort.
If you change this value to false, the other proxy parameters are ignored.
proxy text none
If useProxy is set to true, this parameter must be set to the host name or IP address of
the proxy server protecting the administration server.
proxyPort numeric 8080
If useProxy is set to true, this parameter must be set to the port used to communicate
with the proxy server protecting the administration server.
runtimeName text Created during the
runtime server
installation.
The name of the runtime server.
If this value needs to be changed, it must be changed both here and in the
administration server GUI (Manage Components � Servers). When the runtime server
is restarted it will plug in with its new name.
organizationName text Created during the
runtime server
installation.
The name of the organization.
This value can be changed only if the wrong value is input during the runtime server
installation. Once the runtime server has successfully plugged in to the administration
server, this value must not be changed, as it is also recorded in the administration
server database, and the two data sources must match.
If you need to change the name of the organization to which a runtime server belongs
after it has plugged in, you should uninstall it and reinstall it with a different
organization name.
Configuration settings: communication.properties
Appendix A. Configuration settings 245
Backup and restore of configuration files
Tivoli License Manager is supplied with commands that enable you to backup and
restore the configuration files.
The backup command is used by the install wizard during the server installation,
so that you have a backup of the default settings available to you, should anything
go wrong while you are making configuration changes.
Whenever you change a configuration file you should test that the desired result
has been achieved. If it has, run the command to backup the configuration files. It
copies all the configuration files to a predetermined backup directory, overwriting
whatever is already there.
If at any time you need to restore the configuration files, run the appropriate
command, and all the files will be restored.
Attention: Many of the configuration files are inter-dependent. Thus, you should
not attempt to restore files individually from the backup, as it may compromise the
viability of the configuration. The correct procedure is to backup the complete set
of files whenever you make a change, and restore a complete set whenever you
need to.
The backup and restore commands
The command line, and how to access it, is described in both IBM Tivoli License
Manager: Administration and IBM Tivoli License Manager: Problem Determination, and
the information is not repeated here.
This section documents the administration server and runtime server commands
used for the backup and restore of the product configuration, as listed in Table 28:
Table 28. Commands required to backup and restore the configuration files
Command Component Purpose See Page
backupconf v Administration server
v Runtime server
Backs up the server’s
configuration files.
247
restoreconf v Administration server
v Runtime server
Restores the server’s
configuration files.
250
Backup and restore configuration
246 IBM Tivoli License Manager: Planning, Installation, and Configuration
backupconf
Use this command on either the administration server or the runtime server to
back up the server’s configuration files. The server does not need to be stopped
before using the command.
The files are copied into a pre-determined backup location, where they overwrite
any existing versions. The files that are backed up are as follows:
Administration server
Note: The directory users contains the password files for the
administration server users.
backupconf
Appendix A. Configuration settings 247
Runtime server
Notes:
1. The directory users contains the password files for the runtime server
users.
2. The platform directories contain the platform-specific versions of the
agent_install.properties file.
Syntax: backupconf
Authorization:
Windows A user with administrator rights in the Administrators group.
backupconf
248 IBM Tivoli License Manager: Planning, Installation, and Configuration
UNIX root
See Also: restoreconf
backupconf
Appendix A. Configuration settings 249
restoreconf
Use this command on either the administration server or the runtime server to
restore the server’s configuration files from the backup taken by the command
backupconf. The server does not need to be stopped before using the command.
However, it does need to be stopped and restarted to use the restored values.
The files are copied from the pre-determined backup location, to their correct
location in the product, where they overwrite any existing versions.
Syntax: restoreconf
Authorization:
Windows A user with administrator rights.
UNIX root
See Also: backupconf
restoreconf
250 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix B. Installation parameter list and checklists
This appendix contains the following:
v A table of all parameters required for each possible install option. See “Install
parameter list.”
v A checklist for the administration server and database installation and
configuration information. See “Administration components” on page 254.
v A checklist for the runtime server and database installation and configuration
information. See “Runtime components” on page 257.
v A checklist for installing DB2 as a bundled prerequisite. See “Bundled DB2
checklist” on page 261.
v A checklist for installing WebSphere Application Server as a bundled
prerequisite. See “Bundled WebSphere Application Server checklist” on page 262.
v A checklist for installing the agent. See “Agent checklist” on page 263.
v A checklist for installing the catalog manager. See “Catalog manager checklist”
on page 265.
Install parameter list
Table 29 on page 252 helps you to understand which install parameters to use for
each combination of components you want to install on a particular computer.
Look across the column descriptions to determine the combination of components
you want to install; then look down the column to find the parameters that you
must supply.
Key:
Typical Adm ″Typical″ installation: administration server
components (server and database)
Typical Run ″Typical″ installation: runtime server components
(server and database)
Typical Aadm + Run ″Typical″ installation: administration server and
runtime server components (servers and databases,
no agent)
Custom Adm srv ″Custom″ installation: administration server
Custom Adm srv + db ″Custom″ installation: administration server and
database
Custom Adm db ″Custom″ installation: administration database
Custom Run srv ″Custom″ installation: runtime server
Custom Run srv + db ″Custom″ installation: runtime server and database
Custom Run db ″Custom″ installation: runtime database
© Copyright IBM Corp. 2002, 2004 251
Tabl
e 29
. P
aram
eter
ta
ble
for
inst
alla
tion
optio
ns
Inst
alla
tion
op
tion
s Ty
pic
al
Cu
stom
A
ll
com
pon
ents
Not
es
Ad
m
Ru
n
Ad
m
+
Ru
n
Ad
m
srv
Ad
m
srv
+
db
Ad
m
srv
+
db
+
Ru
n
srv
Ad
m
srv
+
db
+
Ru
n
srv
+
db
Ad
m
srv
+
db
+
Ru
n
db
Ad
m
srv
+
Ru
n
srv
+
db
Ad
m
srv
+
Ru
n
srv
Ad
m
srv
+
Ru
n
db
Ad
m
db
+
Ru
n
srv
+
db
Ad
m
db
+
Ru
n
srv
Ad
m
db
+
Ru
n
db
Ad
m
db
Ru
n
srv
+
db
Ru
n
srv
Ru
n
db
IBM
Ti
voli
Lic
ense
M
anag
er in
stal
l lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
x x
x
Bas
e co
nfig
urat
ion:
tl
msr
v pa
ssw
ord
x
x x
x x
x x
x x
x x
x x
x x
x x
x x
Cus
tom
: use
″t
lmsr
v″ pa
ssw
ord
fo
r al
l pa
ssw
ord
s?
x x
x x
x x
x x
x x
x x
x x
x
Cus
tom
: ad
min
istr
atio
n se
rver
: rem
ote
adm
inis
trat
ion
dat
abas
e: lo
cal
inst
ance
ow
ner
(UN
IX on
ly)
x x
x x
Cus
tom
: ad
min
istr
atio
n se
rver
: rem
ote
adm
inis
trat
ion
dat
abas
e: ad
dre
ss
x x
x x
Cus
tom
: ad
min
istr
atio
n se
rver
: rem
ote
adm
inis
trat
ion
dat
abas
e: po
rt nu
mbe
r x
x x
x
Run
tim
e se
rver
: org
aniz
atio
n x
x x
x x
x x
x x
x x
Run
tim
e se
rver
: ad
min
istr
atio
n se
rver
po
rt
x x
x x
x x
x x
x
Not
ne
eded
fo
r Ty
pica
l (A
dm
+
Run
) or
A
ll co
mpo
nent
s
Cus
tom
: run
tim
e se
rver
: SSL
en
able
d?
x x
x x
x x
x x
Cus
tom
: run
tim
e se
rver
: ad
min
istr
atio
n se
rver
SS
L
port
. x
x x
x x
x x
x
Cus
tom
: run
tim
e se
rver
: run
tim
e se
rver
na
me
x x
x x
x x
x x
Cus
tom
: run
tim
e se
rver
: run
tim
e co
mm
unic
atio
n pa
ssw
ord
. x
x x
x x
x x
x
Not
ne
eded
if
″use
’tl
msr
v’
pass
wor
d fo
r al
l pa
ssw
ord
s?″
= tr
ue
Cus
tom
: run
tim
e se
rver
: rem
ote
adm
inis
trat
ion
serv
er
add
ress
x x
x x
x
Cus
tom
: run
tim
e se
rver
: rem
ote
runt
ime
dat
abas
e:
loca
l in
stan
ce ow
ner
(UN
IX on
ly)
x x
x x
Cus
tom
: run
tim
e se
rver
: rem
ote
runt
ime
dat
abas
e:
add
ress
x x
x x
Cus
tom
: run
tim
e se
rver
: rem
ote
runt
ime
dat
abas
e:
port
nu
mbe
r x
x x
x
All
com
pone
nts:
L
inux
on
zS
erie
s: ag
ent
conf
igur
atio
n: pr
oces
sor
type
x
All
com
pone
nts:
L
inux
on
zS
erie
s: ag
ent
conf
igur
atio
n: no
de
capa
city
x
All
com
pone
nts:
L
inux
on
zS
erie
s: ag
ent
conf
igur
atio
n: sh
ared
po
ol ca
paci
ty
x
Checklists: install parameters
252 IBM Tivoli License Manager: Planning, Installation, and Configuration
Tabl
e 29
. P
aram
eter
ta
ble
for
inst
alla
tion
optio
ns (c
ontin
ued)
Inst
alla
tion
op
tion
s Ty
pic
al
Cu
stom
A
ll
com
pon
ents
Not
es
Ad
m
Ru
n
Ad
m
+
Ru
n
Ad
m
srv
Ad
m
srv
+
db
Ad
m
srv
+
db
+
Ru
n
srv
Ad
m
srv
+
db
+
Ru
n
srv
+
db
Ad
m
srv
+
db
+
Ru
n
db
Ad
m
srv
+
Ru
n
srv
+
db
Ad
m
srv
+
Ru
n
srv
Ad
m
srv
+
Ru
n
db
Ad
m
db
+
Ru
n
srv
+
db
Ad
m
db
+
Ru
n
srv
Ad
m
db
+
Ru
n
db
Ad
m
db
Ru
n
srv
+
db
Ru
n
srv
Ru
n
db
Prer
equi
site
se
arch
: IB
M D
B2
dat
abas
e se
rver
x
x x
x x
x x
x x
x x
x x
x x
x
Prer
equi
site
se
arch
: IB
M D
B2
dat
abas
e se
rver
lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
Prer
equi
site
se
arch
: IB
M D
B2
dat
abas
e cl
ient
x
x x
Prer
equi
site
se
arch
: IB
M D
B2
dat
abas
e cl
ient
lo
cati
on
x x
x
DB
2 pr
ereq
uisi
te: s
etup
fi
le lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
x x
x
DB
2 pr
ereq
uisi
te: i
nsta
ll lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
x x
x
DB
2 pr
ereq
uisi
te: D
B2
port
nu
mbe
r x
x x
x x
x x
x x
x x
x x
x x
x x
x x
DB
2 pr
ereq
uisi
te: D
B2
adm
inis
trat
or ID
x
x x
x x
x x
x x
x x
x x
x x
x x
x x
DB
2 pr
ereq
uisi
te: D
B2
adm
inis
trat
or pa
ssw
ord
x
x x
x x
x x
x x
x x
x x
x x
x x
x x
Prer
equi
site
se
arch
: IB
M W
ebSp
here
A
pplic
atio
n Se
rver
x x
x x
x x
x x
x x
x x
x x
x x
Prer
equi
site
se
arch
: IB
M W
ebSp
here
A
pplic
atio
n Se
rver
lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te: s
etup
fi
le
loca
tion
x x
x x
x x
x x
x x
x x
x x
x x
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te: i
nsta
ll lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te: H
TT
P Se
rver
in
stal
l lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te:
adm
inis
trat
or us
er ID
(W
ind
ows
plat
form
s on
ly)
x x
x x
x x
x x
x x
x x
x x
x x
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te:
adm
inis
trat
or us
er pa
ssw
ord
(W
ind
ows
plat
form
s on
ly)
x x
x x
x x
x x
x x
x x
x x
x x
Checklists: install parameters
Appendix B. Installation parameter list and checklists 253
Administration components
The following is a checklist for the administration server and its database. The first
part details the parameters that you should prepare for the administration server
and its database, prior to commencing the installation. The second part is a
checklist of the configuration steps you should perform after the installation.
Table 30. Administration components install parameter values
Install parameters
Instructions for use: Enter here the data values that you have collected.
Password for ″tlmsrv″ user
Administration
server:
Computer address:
Port number:
SSL port number:
Install location:
Administration
database:
Computer address:
Port number:
Local instance owner
(UNIX only)
Install location:
Table 31. Administration components configuration checklist
Configuration checklist See:
U Instructions for use: enter a tick in the box on the left when an action is completed.
Configure the Web interface and administration server settings in the system.properties file
“Configure the
administration
server” on page
95
If necessary, create the default organization
Optionally create other organizations
Create administrator accounts
Assign accounts to organizations
Perform the organization-related initial tasks: “Perform the
organization-related initial
tasks” on page
96
Create divisions
Schedule inventory scans
Set up and distribute license entitlements
If you want to enable the administration server to communicate in SSL with all runtime
servers, do the following:
“Configuring
SSL for
communications
from the
administration
server to the
runtime server”
on page 99
Change the default SSL password that allows you and the server’s Web server to access
its keystore.
Obtain or create a server certificate with a private key.
Install the server certificate in the keystore (key.kdb), replacing the test certificate
supplied with Tivoli License Manager.
Checklist: administration components
254 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 31. Administration components configuration checklist (continued)
Configuration checklist See:
If you want to enable at least one runtime server to communicate in SSL with the
administration server, do the following (you may have already completed some of these steps
in the previous procedures):
“Configuring
SSL for
communications
from the
runtime server
to the
administration
server” on page
101
Enable SSL on the administration server’s Web server and allocate the secure (SSL) port
to be used.
Ensure that WebSphere Application Server on the administration server has secure-port
aliases.
Change the SSL password that allows you and the administration server’s Web server to
access its keystore.
Obtain or create a server certificate with a private key.
Install the server certificate in the keystore (key.kdb), replacing the test certificate
supplied with Tivoli License Manager.
If you want to enable Web browsers to communicate in SSL with the administration server,
do the following (you may have already completed some of these steps in the previous
procedures):
“Configuring
SSL for
communications
from Web
browsers” on
page 102
Enable SSL on the server’s Web server and allocate the secure (SSL) port to be used.
Ensure that WebSphere Application Server on the administration server has secure-port
aliases.
Change the SSL password that allows you and the administration server’s Web server to
access its keystore.
Obtain or create a server certificate with a private key.
Install the server certificate in the keystore (key.kdb), replacing the test certificate
supplied with Tivoli License Manager.
In the Web browser you will use to access the administration server GUI, make a
bookmark for the administration server using the HTTPS protocol.
In the Web browser you will use to access the administration server GUI, optionally use
the certificate import options to import the self-signed certificate or the root certificate of
your own Certificate Authority.
If you don’t want to enable Web browsers to communicate normally in SSL with the
administration server, but you do want them to communicate sensitive data (such as
passwords) in SSL, do the following:
“Configuring
SSL only for
browser
communications
involving only
passwords” on
page 103
Enable your Web browser, and this server, to use both SSL and non-SSL communications.
Edit the system.properties file for this server to set the appropriate values of secureData
and securePort; save the file.
Restart the server.
If you want to enable agents to communicate in SSL with any runtime server, do the
following:
“Configuring
SSL for
communications
from the agent
to the runtime
server” on page
104
Set the SSL enablement settings for the organization and the divisions to correspond to
your requirements
Configure the notification settings for the server “Configure the
mail notification
settings for a
server” on page
117
Checklist: administration components
Appendix B. Installation parameter list and checklists 255
Table 31. Administration components configuration checklist (continued)
Configuration checklist See:
Optionally customize the html file that reports a type 500 error (server error) so that it gives
appropriate instructions to the user for your environment
“Customize the
Web server” on
page 118
Optionally redefine the authentication method in use at the server (XML, Database or LDAP) “Define the
authentication
method” on
page 121
Optionally configure a proxy server “Configuring
proxy servers”
on page 131
Optionally configure a server on UNIX to run under a non-root user “Optionally
configure a
server on UNIX
to run under a
non-root user.”
on page 134
Tune your environment “Tuning your
environment”
on page 136
Checklist: administration components
256 IBM Tivoli License Manager: Planning, Installation, and Configuration
Runtime components
The following is a checklist for each runtime server and its database. The first part
details the parameters that you should prepare for the runtime server and its
database, prior to commencing the installation. Some of these values you will take
from the administration checklist. The second part is a checklist of the
configuration steps you should perform after the installation.
Table 32. Runtime components install parameter values
Install parameters
Instructions for use: Enter here the data values that you have collected.
Password for ″tlmsrv″ user
Runtime
server:
Name:
Computer address:
Port number:
SSL port number:
Install location:
Organization:
Administration server
address:
Administration server
port:
Administration server SSL
port:
Communication password:
SSL enabled?
SSL Server certificate
identifier:
Runtime
database:
Computer address:
Port number:
Local instance owner
(UNIX only):
Install location:
Table 33. Runtime components configuration checklist
Configuration checklist See:
U Instructions for use: enter a tick in the box on the left when an action is completed.
Configure the runtime server and agent settings in the system.properties file “Configure the
runtime servers”
on page 97
Register the runtime server with the administration server; if SSL is enabled from the runtime
server to the administration server, register also the SSL port enabled
Checklist: runtime components
Appendix B. Installation parameter list and checklists 257
Table 33. Runtime components configuration checklist (continued)
Configuration checklist See:
If you want the administration server to communicate in SSL with this runtime server, do the
following:
“Configuring
SSL for
communications
from the
administration
server to the
runtime server”
on page 99
Enable SSL on the Web server and allocate the secure (SSL) port to be used.
Ensure that WebSphere Application Server has secure-port aliases.
Change the default SSL password that allows you and the server’s Web server to access
its keystore.
Obtain or create a server certificate with a private key for this server.
Install the server certificate in the keystore (key.kdb), replacing the test certificate
supplied with Tivoli License Manager.
v If the server certificate is self-signed, install the same certificate also on the
administration server, in the Java keystore (key.jks).
v If the server certificate was issued by you as a Certificate Authority, install the
Certificate Authority’s root certificate on the administration server, in the Java keystore
(key.jks).
If you want to enable this runtime server to communicate in SSL with the administration
server, do the following (you may have already completed some of these steps in the
previous procedures): “Configuring
SSL for
communications
from the
runtime server
to the
administration
server” on page
101
Enable SSL when installing the runtime server, or reconfigure the runtime server after
installation so that it is enabled for SSL and has details of the administration server’s
secure port.
Change the SSL password that allows you and the runtime server to access its keystore.
v If the administration server’s server certificate is self-signed, install the same certificate
also on the runtime server, in the Java keystore (key.jks).
v If the administration server’s server certificate was issued by you as a Certificate
Authority, install the Certificate Authority’s root certificate on the runtime server, in
the Java keystore (key.jks).
If you want to enable Web browsers to communicate in SSL with this runtime server, do the
following (you may have already completed some of these steps in the previous procedures):
“Configuring
SSL for
communications
from Web
browsers” on
page 102
Enable SSL on the server’s Web server and allocate the secure (SSL) port to be used.
Ensure that WebSphere Application Server on this runtime server has secure-port aliases.
Change the SSL password that allows you and this runtime server’s Web server to access
its keystore.
Obtain or create a server certificate with a private key.
Install the server certificate in the keystore (key.kdb), replacing the test certificate
supplied with Tivoli License Manager.
In the Web browser you will use to access this runtime server GUI, make a bookmark
for the administration server using the HTTPS protocol.
In the Web browser you will use to access this runtime server GUI, optionally use the
certificate import options to import the self-signed certificate or the root certificate of
your own Certificate Authority.
Checklist: runtime components
258 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 33. Runtime components configuration checklist (continued)
Configuration checklist See:
If you don’t want to enable Web browsers to communicate normally in SSL with this runtime
server, but you do want them to communicate sensitive data (such as passwords) in SSL, do
the following:
“Configuring
SSL only for
browser
communications
involving only
passwords” on
page 103
Enable your Web browser, and this server, to use both SSL and non-SSL communications.
Edit the system.properties file for this server to set the appropriate values of secureData
and securePort; save the file.
Restart the server.
If you want to enable agents to communicate in SSL with this runtime server, do the
following:
“Configuring
SSL for
communications
from the agent
to the runtime
server” on page
104
Enable SSL on the server’s Web server and allocate the secure (SSL) port to be used.
Ensure that WebSphere Application Server on this runtime server has secure-port aliases.
Change the SSL password that allows you and this runtime server’s Web server to access
its keystore.
Obtain or create a server certificate with a private key.
Install the server certificate in the keystore (key.kdb), replacing the test certificate
supplied with Tivoli License Manager.
v If the runtime server’s server certificate is self-signed, copy the server certificate,
creating a file called cert.arm and replace the default test certificate installed in the
agent section of the runtime server’s files.
v If the runtime server’s server certificate was issued by you as a Certificate Authority,
copy the root certificate of your Certificate Authority, creating a file called cert.arm
and replace the default test certificate installed in the agent section of the runtime
server’s files.
If the runtime server’s server certificate is self-signed, or was issued by you as a
Certificate Authority, ensure that you take the appropriate steps to use the new cert.arm
file when you deploy agents (each deployment method requires a different approach)
When deploying agents configure the agent deployment options to use or not use SSL
when first plugging in (after the first plug-in they will follow whatever is configured at
the runtime server).
Start the runtime server “Configure the
runtime servers”
on page 97
Check the runtime server has plugged in
Create accounts
Configure the notification settings for the server “Configure the
mail notification
settings for a
server” on page
117
Optionally customize the html file that reports a type 500 error (server error) so that it gives
appropriate instructions to the user for your environment
“Customize the
Web server” on
page 118
Optionally redefine the authentication method in use at the server (XML, Database or LDAP) “Define the
authentication
method” on
page 121
Optionally configure a proxy server “Configuring
proxy servers”
on page 131
Checklist: runtime components
Appendix B. Installation parameter list and checklists 259
Table 33. Runtime components configuration checklist (continued)
Configuration checklist See:
Optionally configure automatic computer label assignment for agents “Automatic
computer label
assignment” on
page 132
Optionally configure a server on UNIX to run under a non-root user “Optionally
configure a
server on UNIX
to run under a
non-root user.”
on page 134
Tune your environment “Tuning your
environment”
on page 136
Checklist: runtime components
260 IBM Tivoli License Manager: Planning, Installation, and Configuration
Bundled DB2 checklist
The following is a checklist for installing the bundled DB2 prerequisite for servers,
databases and the catalog manager. If a supported version of DB2 is already
installed, note here its install location (Windows) or the home directory of the
instance owner (UNIX).
Otherwise, fill in the parameters you require to install the bundled version:
Table 34. Bundled DB2 install parameter values
Install parameters
Instructions for use: Enter here the data values that you have collected.
Setup file location:
Install location:
Port number that DB2 should use:
DB2 administrator user id:
DB2 administrator password:
Checklist: bundled DB2
Appendix B. Installation parameter list and checklists 261
Bundled WebSphere Application Server checklist
The following is a checklist for installing the bundled WebSphere Application
Server prerequisite for servers. If a supported version of WebSphere Application
Server is already installed, note here its install location.
Otherwise, fill in the parameters you require to install the bundled version:
Table 35. Bundled WebSphere Application Server install parameter values
Install parameters
Instructions for use: Enter here the data values that you have collected.
Setup file location:
Install location:
HTTP Server install location:
Administrator user id (only on Windows)
Administrator password (only on
Windows)
Checklist: bundled WebSphere Application Server
262 IBM Tivoli License Manager: Planning, Installation, and Configuration
Agent checklist
The following is a checklist for the agent deployment parameters. Not all
parameters are requested by all agent deployment methods, as some take default
values for certain types of deployment, and some are platform-specific and so do
not apply to all methods.
The table commences with the details of the parameters that apply to groups of
agents. Then follows a table where you can enter the specific values for specific
agents. This table extends to an overflow page.
Table 36. Runtime server-specific agent deployment parameter values
Agent deploy parameters – runtime server-specific
Instructions for use: Enter here the data values that you have collected.
Install location:
Organization:
Division:
Runtime server address:
Runtime server port for insecure
communication:
Runtime server port for SSL
communication:
Use proxy server? yes / no
Proxy server address
Proxy server port
security_level (1 = insecure, 4 = secure)
Note: For most of the bulk agent
deployment methods, this is called Startup
Mode, and its values are ″No SSL″ and
″SSL″, or similar.
GSKit file name (obtain value from
runtime server – platform-specific):
Certificate file name: cert.arm
Inventory scanner file name (obtain value
from runtime server – platform-specific):
uri: /slmruntime/service
Table 37. Runtime server-specific agent deployment parameter values
Agent deployment parameters – agent-specific
Computer label Root password (only
UNIX deployment
using RSH/SSH)
Processor type (only
Linux390)
Shared pool capacity
(only Linux390)
System active
processors (only
Linux390)
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
Checklist: agent
Appendix B. Installation parameter list and checklists 263
Table 37. Runtime server-specific agent deployment parameter values (continued)
Agent deployment parameters – agent-specific
Computer label Root password (only
UNIX deployment
using RSH/SSH)
Processor type (only
Linux390)
Shared pool capacity
(only Linux390)
System active
processors (only
Linux390)
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
IFL / CP
Checklist: agent
264 IBM Tivoli License Manager: Planning, Installation, and Configuration
Catalog manager checklist
The following is a checklist for the catalog manager, detailing the parameters that
you should prepare for its installation.
Table 38. Catalog manager install parameter values
Install parameters
Instructions for use: Enter here the data values that you have collected.
Install location:
Database address (IP or host name)
Database port number
Database local instance owner (UNIX
only):
Checklist: catalog manager
Appendix B. Installation parameter list and checklists 265
Checklist: catalog manager
266 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix C. Response files and software package blocks for
silent and remote installations and uninstallations
Tivoli License Manager is provided with InstallShield response files enabling the
product to be installed or uninstalled silently. The available response files are as
follows:
v “Server and database silent installations”
v “Software package block keys for server and database installations using Tivoli
Configuration Manager” on page 280
v “Server and database silent uninstallations” on page 285
v “Catalog manager silent installation” on page 287
v “Software package block for catalog manager installation using Tivoli
Configuration Manager” on page 288
v “Silent installation of OS/400 agent” on page 290
v The software package block for agent installation using Tivoli Configuration
Manager is described in “Deploying agents using Tivoli Configuration Manager”
on page 152.
Server and database silent installations
The recordFile_Install.txt file, which is provided with Tivoli License Manager,
is an InstallShield options file. It defines arguments to set each parameter that
must be provided to the Tivoli License Manager install wizard. Some parameters
have default value that you can accept or change, while others do not have default
values, and you must provide a value.
To launch the install wizard in silent mode, follow the instructions in “Choosing
the install method” on page 66.
The command runs using the parameters that are defined in the options (or
response) file recordFile_Install.txt.
In this appendix, Table 39 on page 269 lists all of the parameters in the file,
showing which are required for each installation option.
There then follows a series of tables for each group of parameters that are used in
the same circumstances. The groups are as follows:
v “Parameters used in all installations” on page 272
v “Parameters used in all custom installations” on page 273
v “Parameters used only if you are installing either server, or both, without any
databases” on page 273
v “Parameters used only if your installation includes a database” on page 274
v “Parameters used only if your installation includes a server” on page 275
v “Parameters used in all custom installations of the administration server without
its database” on page 275
v “Parameters used in all installations that include a runtime server” on page 276
v “Additional parameters used in all custom installations that include a runtime
server” on page 276
© Copyright IBM Corp. 2002, 2004 267
v “Additional parameters used in all custom installations that include a runtime
server without the administration server” on page 277
v “Additional parameters used in all custom installations that include a runtime
server without its database” on page 277
v “Parameters used in an All components (Full) installation, on Linux for zSeries”
on page 278
v “Parameters used to install the bundled DB2 prerequisite” on page 278
v “Parameters used to install the bundled WebSphere Application Server
prerequisite” on page 279
Which installation parameters are required?
Table 39 on page 269 shows the parameters required for each combination of
components that you can install with the silent installation.
Silent installation: servers and databases
268 IBM Tivoli License Manager: Planning, Installation, and Configuration
Tabl
e 39
. P
aram
eter
s re
quire
d fo
r si
lent
in
stal
latio
n op
tions
Inst
alla
tion
op
tion
s C
ust
om
All
com
pon
ents
(Fu
ll)
Not
es
Inst
alla
tion
p
aram
eter
s
Ad
m
srv
Ad
m
srv
+
db
Ad
m
srv
+
db
+
Ru
n
srv
Ad
m
srv
+
db
+
Ru
n
db
Ad
m
srv
+
db
+
Ru
n
srv
+
db
Ad
m
srv
+
Ru
n
srv
Ad
m
srv
+
Ru
n
db
Ad
m
srv
+
Ru
n
srv
+
db
Ad
m
db
Ad
m
db
+
Ru
n
srv
Ad
m
db
+
Ru
n
db
Ad
m
db
+
Ru
n
srv
+
db
Ru
n
srv
Ru
n
srv
+
db
Ru
n
db
Par
amet
ers
use
d in
al
l in
stal
lati
ons
IBM
Ti
voli
Lic
ense
M
anag
er in
stal
l lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
Setu
p: ty
pe (a
ll co
mpo
nent
s, cu
stom
) x
x x
x x
x x
x x
x x
x x
x x
x N
ot us
ed in
sp
b.
Bas
e co
nfig
urat
ion:
tl
msr
v pa
ssw
ord
x
x x
x x
x x
x x
x x
x x
x x
x
Par
amet
ers
use
d on
ly in
C
ust
om in
stal
lati
ons
Setu
p: C
usto
m: a
dm
inis
trat
ion
serv
er co
mpo
nent
sele
ctio
n x
x x
x x
x x
x x
x x
x x
x x
Setu
p: C
usto
m: a
dm
inis
trat
ion
dat
abas
e co
mpo
nent
sele
ctio
n x
x x
x x
x x
x x
x x
x x
x x
Setu
p: C
usto
m: r
unti
me
serv
er co
mpo
nent
se
lect
ion
x x
x x
x x
x x
x x
x x
x x
x
Setu
p: C
usto
m: r
unti
me
dat
abas
e co
mpo
nent
se
lect
ion
x x
x x
x x
x x
x x
x x
x x
x
Cus
tom
: use
″t
lmsr
v″ pa
ssw
ord
fo
r al
l pa
ssw
ord
s?
x x
x x
x x
x x
x x
x x
x x
x N
ot us
ed in
sp
b.
Par
amet
ers
use
d on
ly if
yo
u ar
e in
stal
lin
g ei
ther
or
b
oth
se
rver
s, w
ith
out
any
dat
abas
es
Prer
equi
site
se
arch
: IB
M D
B2
dat
abas
e cl
ient
x
x x
Prer
equi
site
se
arch
: IB
M D
B2
dat
abas
e cl
ient
lo
cati
on
x x
x
Par
amet
ers
use
d on
ly if
yo
ur
inst
alla
tion
in
clu
des
a
dat
abas
e
Prer
equi
site
se
arch
: IB
M D
B2
dat
abas
e se
rver
x
x x
x x
x x
x x
x x
x x
Prer
equi
site
se
arch
: IB
M D
B2
dat
abas
e se
rver
lo
cati
on
x x
x x
x x
x x
x x
x x
x
Par
amet
ers
use
d on
ly if
yo
ur
inst
alla
tion
in
clu
des
a
serv
er
Prer
equi
site
se
arch
: IB
M W
ebSp
here
A
pplic
atio
n Se
rver
x
x x
x x
x x
x x
x x
x x
Prer
equi
site
se
arch
: IB
M W
ebSp
here
A
pplic
atio
n Se
rver
loca
tion
x x
x x
x x
x x
x x
x x
x
Par
amet
ers
use
d in
al
l cu
stom
in
stal
lati
ons
of th
e ad
min
istr
atio
n se
rver
w
ith
out
its
dat
abas
e
Cus
tom
: ad
min
istr
atio
n se
rver
: rem
ote
adm
inis
trat
ion
dat
abas
e: lo
cal
inst
ance
ow
ner
(UN
IX on
ly)
x x
x x
Cus
tom
: ad
min
istr
atio
n se
rver
: rem
ote
adm
inis
trat
ion
dat
abas
e: ad
dre
ss
x x
x x
Cus
tom
: ad
min
istr
atio
n se
rver
: rem
ote
adm
inis
trat
ion
dat
abas
e: po
rt nu
mbe
r x
x x
x
Par
amet
ers
use
d in
al
l in
stal
lati
ons
that
in
clu
de
a ru
nti
me
serv
er
Run
tim
e se
rver
: org
aniz
atio
n x
x x
x x
x x
x x
Silent installation: servers and databases
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 269
Tabl
e 39
. P
aram
eter
s re
quire
d fo
r si
lent
in
stal
latio
n op
tions
(c
ontin
ued)
Inst
alla
tion
op
tion
s C
ust
om
All
com
pon
ents
(Fu
ll)
Not
es
Inst
alla
tion
p
aram
eter
s
Ad
m
srv
Ad
m
srv
+
db
Ad
m
srv
+
db
+
Ru
n
srv
Ad
m
srv
+
db
+
Ru
n
db
Ad
m
srv
+
db
+
Ru
n
srv
+
db
Ad
m
srv
+
Ru
n
srv
Ad
m
srv
+
Ru
n
db
Ad
m
srv
+
Ru
n
srv
+
db
Ad
m
db
Ad
m
db
+
Ru
n
srv
Ad
m
db
+
Ru
n
db
Ad
m
db
+
Ru
n
srv
+
db
Ru
n
srv
Ru
n
srv
+
db
Ru
n
db
Run
tim
e se
rver
: ad
min
istr
atio
n se
rver
po
rt
x x
x x
x x
x x
Not
ne
eded
fo
r ″a
ll co
mpo
nent
s″
inst
alla
tion
s
Par
amet
ers
use
d ad
dit
ion
ally
in
al
l cu
stom
in
stal
lati
ons
that
in
clu
de
a ru
nti
me
serv
er
Cus
tom
: run
tim
e se
rver
: SSL
en
able
d?
x x
x x
x x
x x
Cus
tom
: run
tim
e se
rver
: ad
min
istr
atio
n se
rver
SS
L
port
. x
x x
x x
x x
x
Cus
tom
: run
tim
e se
rver
: run
tim
e se
rver
na
me
x x
x x
x x
x x
Cus
tom
: run
tim
e se
rver
: run
tim
e co
mm
unic
atio
n pa
ssw
ord
.
x x
x x
x x
x x
Not
ne
eded
if
″use
’tl
msr
v’
pass
wor
d fo
r al
l pa
ssw
ord
s?″
=
true
Not
us
ed in
sp
b.
Par
amet
ers
use
d ad
dit
ion
ally
in
al
l cu
stom
in
stal
lati
ons
that
in
clu
de
a ru
nti
me
serv
er w
ith
out
the
adm
inis
trat
ion
se
rver
Cus
tom
: run
tim
e se
rver
: rem
ote
adm
inis
trat
ion
serv
er
add
ress
x x
x x
Par
amet
ers
use
d ad
dit
ion
ally
in
al
l cu
stom
in
stal
lati
ons
that
in
clu
de
a ru
nti
me
serv
er w
ith
out
its
dat
abas
e
Cus
tom
: run
tim
e se
rver
: rem
ote
runt
ime
dat
abas
e: lo
cal
inst
ance
ow
ner
(UN
IX on
ly)
x x
x x
Cus
tom
: run
tim
e se
rver
: rem
ote
runt
ime
dat
abas
e:
add
ress
x x
x x
Cus
tom
: run
tim
e se
rver
: rem
ote
runt
ime
dat
abas
e: po
rt
num
ber
x x
x x
Par
amet
ers
use
d on
ly in
an
″A
ll co
mp
onen
ts″
inst
alla
tion
s on
L
inu
x on
zS
erie
s
All
com
pone
nts:
L
inux
on
zS
erie
s: ag
ent
conf
igur
atio
n:
proc
esso
r ty
pe
x
All
com
pone
nts:
L
inux
on
zS
erie
s: ag
ent
conf
igur
atio
n:
nod
e ca
paci
ty
x
All
com
pone
nts:
L
inux
on
zS
erie
s: ag
ent
conf
igur
atio
n:
shar
ed po
ol ca
paci
ty
x
Par
amet
ers
use
d on
ly to
in
stal
l th
e b
un
dle
d p
rere
qu
isit
e D
B2
DB
2 pr
ereq
uisi
te: s
etup
fi
le lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
DB
2 pr
ereq
uisi
te: i
nsta
ll lo
cati
on
x x
x x
x x
x x
x x
x x
x x
x x
DB
2 pr
ereq
uisi
te: D
B2
port
nu
mbe
r x
x x
x x
x x
x x
x x
x x
x x
x
Silent installation: servers and databases
270 IBM Tivoli License Manager: Planning, Installation, and Configuration
Tabl
e 39
. P
aram
eter
s re
quire
d fo
r si
lent
in
stal
latio
n op
tions
(c
ontin
ued)
Inst
alla
tion
op
tion
s C
ust
om
All
com
pon
ents
(Fu
ll)
Not
es
Inst
alla
tion
p
aram
eter
s
Ad
m
srv
Ad
m
srv
+
db
Ad
m
srv
+
db
+
Ru
n
srv
Ad
m
srv
+
db
+
Ru
n
db
Ad
m
srv
+
db
+
Ru
n
srv
+
db
Ad
m
srv
+
Ru
n
srv
Ad
m
srv
+
Ru
n
db
Ad
m
srv
+
Ru
n
srv
+
db
Ad
m
db
Ad
m
db
+
Ru
n
srv
Ad
m
db
+
Ru
n
db
Ad
m
db
+
Ru
n
srv
+
db
Ru
n
srv
Ru
n
srv
+
db
Ru
n
db
DB
2 pr
ereq
uisi
te: D
B2
adm
inis
trat
or ID
x
x x
x x
x x
x x
x x
x x
x x
x
DB
2 pr
ereq
uisi
te: D
B2
adm
inis
trat
or pa
ssw
ord
x
x x
x x
x x
x x
x x
x x
x x
x
Par
amet
ers
use
d on
ly to
in
stal
l th
e b
un
dle
d p
rere
qu
isit
e W
ebS
ph
ere
Ap
pli
cati
on S
erve
r
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te: s
etup
fi
le
loca
tion
x x
x x
x x
x x
x x
x x
x
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te: i
nsta
ll lo
cati
on
x x
x x
x x
x x
x x
x x
x
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te: H
TT
P Se
rver
in
stal
l lo
cati
on
x x
x x
x x
x x
x x
x x
x
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te: c
reat
e W
ebSp
here
A
pplic
atio
n Se
rver
an
d IB
M H
TT
P Se
rver
as se
rvic
es (W
ind
ows
plat
form
s on
ly)
x x
x x
x x
x x
x x
x x
x N
ot us
ed in
sp
b.
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te:
adm
inis
trat
or us
er ID
(W
ind
ows
plat
form
s on
ly)
x x
x x
x x
x x
x x
x x
x N
ot us
ed in
sp
b.
Web
Sphe
re A
pplic
atio
n Se
rver
pr
ereq
uisi
te:
adm
inis
trat
or us
er pa
ssw
ord
(W
ind
ows
plat
form
s on
ly)
x x
x x
x x
x x
x x
x x
x
Silent installation: servers and databases
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 271
Note: The note ″Not used in spb.″ means that the parameter in question is not
used when installing Tivoli License Manager using a software package block
in the software distribution component of Tivoli Configuration Manager. See
“Software package block keys for server and database installations using
Tivoli Configuration Manager” on page 280 for more details.
Parameters used in all installations
Table 40 shows the parameters required for all installations.
Table 40. Server and database silent install parameters: all installations
Parameter Parameter key name Default
Description
IBM Tivoli License
Manager install location
-P installLocation=
The location where the selected components are to be installed. Specify a valid directory
that does not contain any other installed product. If the directory does not exist it will
be created. If the directory path contains spaces, enclose it in double-quotes. If no value
is specified, the install location defaults to the directory where the install wizard was
started.
Setup type -W setupType.selectedSetupTypeId=
Determines the type of installation to be performed. Possible values are:
Full
Installs the administration server and its database, a runtime server and its database
and the agent. The installation uses default values for almost all variables, only
requiring you to supply the password to the ″tlmsrv″ user and the organization
name.
<blank>
This is the ″Custom″ installation. The wizard enables you to choose the components
you wish to install by setting the relevant <component>.active parameter to ″true″.
That component will then be installed.
Base configuration: tlmsrv
user password
-W baseConfig.tlmsrvPwd=
Specifies the communication password to be used in all circumstances. It is used as
follows:
v For server components, to access the associated DB2 database.
v For database components, to enable communication between the DB2 database client
and its database server. During installation the user tlmsrv is created and its
password is set to this value.
The maximum length is 20 characters and the characters allowed are: A-Z a-z 0-9 + - =.
The password must respect the rules of the computer on which it will be created.
Note: Passwords entered in this file are not encrypted. This may be a security violation
in your organization.
If a Tivoli License Manager component has already been installed on this computer, the
password supplied on that occasion must be supplied here, for authentication purposes.
Silent installation: servers and databases
272 IBM Tivoli License Manager: Planning, Installation, and Configuration
Parameters used in all custom installations
Table 41 shows the parameters required for all installations where the Setup Type
is not ″Full″.
Table 41. Server and database silent install parameters: all custom installations
Parameter Parameter key name Default
Description
Setup: Custom:
administration server
component selection
-P admin.active= false
Specifies whether or not the administration server component should be installed. The
value is used only if Setup type is not Full. Possible values are:
true The server will be installed.
false The server will not be installed.
Setup: Custom:
administration database
component selection
-P adminDB.active= true
Specifies whether or not the administration server database should be installed. The
value is used only if Setup type is not Full. Possible values are:
true The database will be installed.
false The database will not be installed.
Setup: Custom: runtime
server component
selection
-P runtime.active= false
Specifies whether or not the runtime server component should be installed. The value is
used only if Setup type is not Full. Possible values are:
true The server will be installed.
false The server will not be installed.
Setup: Custom: runtime
database component
selection
-P runtimeDB.active= false
Specifies whether or not the runtime server database component should be installed.
The value is used only if Setup type is not Full. Possible values are:
true The database will be installed.
false The database will not be installed.
Custom: use tlmsrv
password for all
passwords
-W baseConfig.useSamePwds= true
This specifies that you want to use the tlmsrv password for the other password that the
wizard needs to create; the runtime communications password. The permitted values
are:
true The wizard will use the tlmsrv password for the runtime server communiation
password.
false The wizard will use the supplied individual values for all created IDs.
Parameters used only if you are installing either server, or
both, without any databases
Table 42 on page 274 shows the parameters required when installing any
combination of servers but no databases.
Silent installation: servers and databases
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 273
Table 42. Server and database silent install parameters: any server but no databases
Parameter Parameter key name Default
Description
Prerequisite search: IBM
DB2 database client
-W databaseClientPathPanel.prerequisiteInstalled= true
If the wizard fails to find a supported DB2 database client prerequisite, specifies
whether the wizard should search for the prerequisite on the computer or should install
the bundled DB2 database client prerequisite. This DB2 client prerequisite is for all
computers where only a Tivoli License Manager server is to be installed. Possible values
are:
true The wizard will search for the DB2 database client prerequisite.
false The wizard will install the bundled DB2 database client prerequisite. If any
version of DB2 is already installed on the computer, the prerequisite installation
will fail.If this value is true, the corresponding value for the search for the DB2 database server
must be false, and vice versa.
Prerequisite location: IBM
DB2 database client
-W databaseClientPathPanel.locationPath= ″C:\Program Files″
If the wizard is required to search for the DB2 database client prerequisite, (-W
databaseClientPathPanel.prerequisiteInstalled=true), specifies the data structure within
which to search. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes. For UNIX,
supply the path of the home directory of the DB2 instance owner.
Parameters used only if your installation includes a database
Table 43
Table 43. Server and database silent install parameters
Parameter Parameter key name Default
Description
Prerequisite search: IBM
DB2 database server
-W databaseServerPathPanel.prerequisiteInstalled= true
If the wizard fails to find a supported DB2 database server prerequisite, specifies
whether the wizard should search for the prerequisite on the computer or should install
the bundled DB2 database server prerequisite. This DB2 server prerequisite is for all
computers where a Tivoli License Manager database is to be installed. Possible values
are:
true The wizard will search for the DB2 database server prerequisite.
false The wizard will install the bundled DB2 database server prerequisite. If any
version of DB2 is already installed on the computer, the prerequisite install will
fail.If this value is true, the corresponding value for the search for the DB2 database client
must be false, and vice versa.
Prerequisite location: IBM
DB2 database server
-W databaseServerPathPanel.locationPath= ″C:\Program Files″
If the wizard is required to search for the DB2 database server prerequisite, (-W
databaseServerPathPanel.prerequisiteInstalled=true), specifies the data structure within
which to search. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes. For UNIX,
supply the path of the home directory of the DB2 instance owner.
Silent installation: servers and databases
274 IBM Tivoli License Manager: Planning, Installation, and Configuration
Parameters used only if your installation includes a server
Table 44 shows the parameters required for installing any server
Table 44. Server and database silent install parameters: any server
Parameter Parameter key name Default
Description
Prerequisite search: IBM
WebSphere Application
Server
-W appServerPathPanel.prerequisiteInstalled= true
If the wizard fails to find a supported WebSphere Application Server prerequisite,
specifies whether the wizard should search for the prerequisite on the computer or
should install the bundled WebSphere Application Server prerequisite. This prerequisite
is for all computers where a Tivoli License Manager server is to be installed. Possible
values are:
true The wizard will search for the WebSphere Application Server prerequisite.
false The wizard will install the bundled WebSphere Application Server prerequisite.
Prerequisite location: IBM
WebSphere Application
Server
-W appServerPathPanel.locationPath= ″C:\Program Files″
If the wizard is required to search for the WebSphere Application Server prerequisite,
(-W appServerPathPanel.prerequisiteInstalled=true), specifies the data structure within
which to search. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes.
Parameters used in all custom installations of the
administration server without its database
Table 45 shows the parameters required to install the administration server without
its database
Table 45. Server and database silent install parameters: administration server without database
Parameter Parameter key name Default
Description
Custom: administration
server: remote
administration database:
local instance owner
(UNIX only)
-W dbInstallAdmin.dbAdminUser= ″db2inst1″
On UNIX platforms, specifies the administration user of the DB2 administration server
database.
Custom: administration
server: remote
administration database:
address
-W dbInstallAdmin.hostName= ″localhost″
The host name of the computer where the remote administration server database
resides.
This value is ignored if the Setup Type = Full, if the administration server is not being
installed, or if the administration server database is being installed with the
administration server.
Custom: administration
server: remote
administration database:
port number
-W dbInstallAdmin.portNumber=
The port number that the remote administration server database listens on.
This value is ignored if the Setup Type = Full, if the administration server is not being
installed, or if the DB2 database client prerequisite is also being installed.
Silent installation: servers and databases
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 275
Parameters used in all installations that include a runtime
server
Table 46 shows the parameters required to install a runtime server, whatever the
Setup Type
Table 46. Server and database silent install parameters: all runtime server installations
Parameter Parameter key name Default
Description
Runtime server:
organization
-W baseConfig.organizationName= ″your_organization″
Specifies the name of the organization with which runtime server and database
components are to be associated.
Runtime server:
administration server port
-W baseConfig.port= ″80″
Specifies the port on the administration server’s computer that the administration server
listens on.
This value is ignored if the Setup Type = Full, or if the runtime server is not being
installed.
Additional parameters used in all custom installations that
include a runtime server
Table 47 shows the additional parameters used in all installations that include a
runtime server where the Setup Type is not ″Full″.
Table 47. Server and database silent install parameters: custom runtime server
Parameter Parameter key name Default
Description
Custom: runtime server:
SSL enabled?
-W baseConfig.sslEnabled= false
This value is ignored if the Setup Type is Full. Indicates whether or not secure sockets
layer (SSL) communications is to used for communications emanating from the server
you are installing. If you are installing both servers, the value applies to both. Possible
values are:
true Use SSL
false Do not use SSL
Custom: runtime server:
administration server SSL
port.
-W baseConfig.sslPort= ″443″
Specifies the SSL port.
This value is ignored if the Setup Type = Full, if a server is not being installed, or if SSL
is not enabled.
Custom: runtime server:
runtime server name
-W baseConfig.runtimeName= ″your_runtime_server_name″
Specifies the name of the runtime server you are installing.
This value is ignored if the Setup Type = Full, or if the runtime server is not being
installed.
Custom: runtime server:
runtime communication
password.
-W otherPasswords.runtimeToAdminPwd=
Specifies the password to be used by the runtime server to authenticate communications
with the administration server. The maximum length is 20 characters and the characters
allowed are: A-Z a-z 0-9 + - =.
This value is ignored if the Setup Type = Full, if the runtime server is not being
installed, or if the tlmsrv password is to be used for all passwords.
Silent installation: servers and databases
276 IBM Tivoli License Manager: Planning, Installation, and Configuration
Additional parameters used in all custom installations that
include a runtime server without the administration server
Table 48 shows the additional parameters required when installing a runtime
server in a custom install and the administration server is not also being installed.
Table 48. Server and database silent install parameters: runtime server with no administration server
Parameter Parameter key name Default
Description
Custom: runtime server:
remote administration
server address
-W baseConfig.adminHost= ″localhost″
Specifies the host name or IP address of the administration server computer for this
runtime server. This value must contain only US ASCII characters.
This value is ignored if the Setup Type = Full, or if the runtime server is not being
installed.
Additional parameters used in all custom installations that
include a runtime server without its database
Table 49 shows the additional parameters required when installing a runtime
server in a custom install and the runtime database is not also being installed.
Table 49. Server and database silent install parameters: runtime server with no runtime database
Parameter Parameter key name Default
Description
Custom: runtime server:
remote runtime database:
local instance owner
(UNIX only)
-W dbInstallRuntime.dbAdminUser= ″db2inst1″
On UNIX platforms, specifies the instance owner of the local DB2 installation used to
access the runtime server database.
This value is ignored if the Setup Type = Full, or if the runtime server is not being
installed.
Custom: runtime server:
remote runtime database:
address
-W dbInstallRuntime.hostName= ″localhost″
The address of the computer where the runtime server database resides.
This value is ignored if the Setup Type = Full, if the runtime server is not being
installed, or if the runtime server is being installed at the same time as the runtime
server database.
Custom: runtime server:
remote runtime database:
port number
-W dbInstallRuntime.portNumber=
The port number of the runtime server database.
This value is ignored if the Setup Type = Full, if the runtime server is not being
installed, or if the DB2 database client prerequisite is also being installed.
Silent installation: servers and databases
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 277
Parameters used in an All components (Full) installation, on
Linux for zSeries
Table 50 shows the parameters to be used in an all components installation on
Linux for zSeries.
Table 50. Server and database silent install parameters: all components on Linux for zSeries
Parameter Parameter key name Default
Description
All components: Linux on
zSeries: agent
configuration: processor
type
-W baseConfig.procType= IFL
Specify if the Linux390 image is running on CP or IFL processors. Permitted values are:
IFL Indicates that the Linux390 image is in the IFL partition
CP Indicates that the Linux390 image is in the CP partition
This value is ignored if the Setup Type is not Full, and the platform type is not Linux on
zSeries.
All components: Linux on
zSeries: agent
configuration: node
capacity
-W baseConfig.sysActProc=
Specify the total number of processors (of type CP or IFL, as appropriate, not both) in
the CEC. This value must be greater than 0.
This value is ignored if the Setup Type is not Full, and the platform type is not Linux on
zSeries.
All components: Linux on
zSeries: agent
configuration: shared pool
capacity
-W baseConfig.sharedPoolCap=
If the Linux390 image is configured to share processors, specify the total number of
shared processors (of type CP or IFL, as appropriate, not both) in the CEC. Enter zero if
no shared processors are used by this image.
This value is ignored if the Setup Type is not Full, and the platform type is not Linux on
zSeries.
Parameters used to install the bundled DB2 prerequisite
Table 51 shows the parameters to be used if you want to install the bundled DB2
prerequisite.
Table 51. Server and database silent install parameters: bundled DB2 prerequisite
Parameter Parameter key name Default
Description
DB2 Prerequisite setup
file location: IBM DB2
-W db2SetupFile.name=
If the wizard needs to install the IBM DB2 prerequisite, specifies the location of the
setup file. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes.
Prerequisite install
location: IBM DB2
-W db2InputPanel.db2_instLoc=
If the wizard needs to install the IBM DB2 prerequisite, specifies the directory in which
to install it. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes. For UNIX,
supply the home directory of the DB2 instance owner, that, when concatenated with the
DB2 instance owner ID, gives the path to the install location of DB2. For example, if the
location is /home/db2inst1, where db2inst1 is the instance owner’s id, enter just /home.
Prerequisite install
parameters: IBM DB2
port number
-W db2InputPanel.db2_port= ″50000″
If the wizard needs to install the IBM DB2 prerequisite, specifies the port number on
which DB2 should listen.
Silent installation: servers and databases
278 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 51. Server and database silent install parameters: bundled DB2 prerequisite (continued)
Parameter Parameter key name Default
Description
Prerequisite install
parameters: IBM DB2
administrator ID
-W db2InputPanel.db2_userName= ″db2admin″
If the wizard needs to install the IBM DB2 prerequisite, specifies the DB2 administrator
user ID that the wizard will create on the computer. The ID must not exist on the
computer where it is to be created, and must respect the user id rules of that computer.
Prerequisite install
parameters: IBM DB2
administrator password
-W db2InputPanel.db2_password=
If the wizard needs to install the IBM DB2 prerequisite, specifies the DB2 administrator
password that will be used when the DB2 Administrator ID is created. The maximum
length is 20 characters and the characters allowed are: A-Z a-z 0-9 + - =. The password
must respect the rules of the computer on which it will be created.
Note: Passwords entered in this file are not encrypted. This may be a security violation
in your organization.
Parameters used to install the bundled WebSphere
Application Server prerequisite
Table 52 shows the parameters to be used if you want to install the bundled
WebSphere Application Server prerequisite.
Table 52. Server and database silent install parameters: bundled WebSphere Application Server prerequisite
Parameter Parameter key name Default
Description
WebSphere Application
Server prerequisite: setup
file location
-W wasSetupFile.name=
If the wizard needs to install the WebSphere Application Server prerequisite, specifies
the location of the setup file. It must be provided as a full pathname, and if the
pathname includes directories with spaces in their names, it must be enclosed in double
quotes.
Note: If you supply this parameter value, or any other of the WebSphere Application
Server related values, but you have not configured the parameters in this file to install a
Tivoli License Manager server, WebSphere Application Server will not be installed.
WebSphere Application
Server prerequisite: install
location
-W wasInputPanel.was_instLoc=
If the wizard needs to install the WebSphere Application Server prerequisite, specifies
the directory in which to install it. It must be provided as a full pathname, and if the
pathname includes directories with spaces in their names, it must be enclosed in double
quotes.
WebSphere Application
Server prerequisite: HTTP
Server install location
-W wasInputPanel.ihs_instLoc=
If the wizard needs to install the WebSphere Application Server prerequisite, specifies
the directory in which to install the IBM HTTP Server. It must be provided as a full
pathname, and if the pathname includes directories with spaces in their names, it must
be enclosed in double quotes.
WebSphere Application
Server prerequisite: create
WebSphere Application
Server and HTTP Server
as services (Windows
platforms only)
-W wasInputPanel.service_active= true
If the wizard needs to install the WebSphere Application Server prerequisite, for
Windows platforms only, specifies whether WebSphere Application Server and the HTTP
Server should be set up as services. The permitted values are:
true The wizard will set up the WebSphere Application Server and the HTTP Server
as services.
false The wizard will not set up the WebSphere Application Server and the HTTP
Server as services.
Silent installation: servers and databases
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 279
Table 52. Server and database silent install parameters: bundled WebSphere Application Server
prerequisite (continued)
Parameter Parameter key name Default
Description
WebSphere Application
Server prerequisite:
administrator user ID
(Windows platforms only)
-W wasInputPanel.service_userName= ″Administrator″
If the wizard needs to install the WebSphere Application Server prerequisite, for
Windows platforms only, where you have specified that the WebSphere Application
Server and HTTP Server should be set up as services, specifies the Administrator ID of
the computer on which the installation will be performed.
WebSphere Application
Server prerequisite:
administrator user
password (Windows
platforms only)
-W wasInputPanel.service_password=
If the wizard needs to install the WebSphere Application Server prerequisite, for
Windows platforms only, where you have specified that the WebSphere Application
Server and HTTP Server should be set up as services, specifies the Administrator
password for the Administrator ID.
Note: Passwords entered in this file are not encrypted. This may be a security violation
in your organization.
Software package block keys for server and database installations
using Tivoli Configuration Manager
This section documents the keys used in the software package block that allow you
to install servers and databases remotely using the Software Distribution
component of Tivoli Configuration Manager. How to use this installation method is
described in “Choosing the install method” on page 66.
Note: The software package block installation is always a ″Custom″ installation.
″All components″ and ″Typical″ are not available. You must indicate
one-by-one which components you want to install.
Use the information in Table 53 on page 281 to supply the correct values when
Software Distribution displays its Default Variables panel.
The table lists the software package block parameters in alphabetic order of the
parameter key name, so that you can find the keys more easily. Default values are
not supplied, as the defaults vary according to the platform.
Notes:
1. The order of the keys in the spb is neither alphabetic (like this table) nor logical
(like the response file). It follows the internal logic of Software Distribution.
Thus, to find the description and permitted values of a specific parameter, look
it up in alphabetical order in the table.
2. The SPB parameter key names are almost identical to the corresponding
response file parameter name. The only difference should be that the response
file parameter names have a –W or –P prefix that is not present in the SPB
parameter key names.
3. See Table 39 on page 269 for a table of the parameters required for each
permitted combination of components that you might want to install on a
computer.
Silent installation: servers and databases
280 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 53. Software package block keys for server and database installations
Parameter SPB parameter key name
Description
Install administration
server component
admin.active
Specifies whether or not the administration server component should be installed.
Possible values are:
true The server will be installed.
false The server will not be installed.
Install administration
database component
adminDB.active
Specifies whether or not the administration server database should be installed. Possible
values are:
true The database will be installed.
false The database will not be installed.
Prerequisite location: IBM
WebSphere Application
Server
appServerPathPanel.locationPath
If the wizard is required to search for the WebSphere Application Server prerequisite,
(appServerPathPanel.prerequisiteInstalled=true), specifies the data structure within
which to search. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes.
Prerequisite search: IBM
WebSphere Application
Server
appServerPathPanel.prerequisiteInstalled
If the wizard fails to find a supported WebSphere Application Server prerequisite,
specifies whether the wizard should search for the prerequisite on the computer or
should install the bundled WebSphere Application Server prerequisite. Possible values
are:
true The wizard will search for the WebSphere Application Server prerequisite.
false The wizard will install the bundled WebSphere Application Server prerequisite.
Runtime server:
administration server
address
baseConfig.adminHost
Specifies the host name or IP address of the administration server computer for this
runtime server. This value must contain only US ASCII characters.
This value is ignored if the runtime server is not being installed.
Runtime server:
organization
baseConfig.organizationName
Specifies the name of the organization with which runtime server and database
components are to be associated.
Runtime server:
administration server
port
baseConfig.port
Specifies the port on the administration server’s computer that the administration server
listens on.
This value is ignored if the runtime server is not being installed.
Runtime server: runtime
server name
baseConfig.runtimeName
Specifies the name of the runtime server you are installing.
This value is ignored if the runtime server is not being installed.
Base configuration: use
SSL
baseConfig.sslEnabled
Indicates whether or not secure sockets layer (SSL) communications is to used for
communications emanating from the server you are installing. If you are installing both
servers, the value applies to both. Possible values are:
true Use SSL
false Do not use SSL
Silent installation: servers and databases using SPB
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 281
Table 53. Software package block keys for server and database installations (continued)
Parameter SPB parameter key name
Description
Base configuration: SSL
port
baseConfig.sslPort
Specifies the SSL port.
This value is ignored if a server is not being installed, or if SSL is not enabled.
Base configuration:
tlmsrv user password
baseConfig.tlmsrvPwd
Specifies the communication password to be used in all circumstances. It is used as
follows:
v For server components, to access the associated DB2 database.
v For database components, to enable communication between the DB2 database client
and its database server. During installation the user tlmsrv is created and its password
is set to this value.
v For the runtime communication password (if a runtime server is being installed)
The maximum length is 20 characters and the characters allowed are: A-Z a-z 0-9 + - =.
The password must respect the rules of the computer on which it will be created.
Note: Passwords entered in this file are not encrypted. This may be a security violation
in your organization.
If a Tivoli License Manager component has already been installed on this computer, the
password supplied on that occasion must be supplied here, for authentication purposes.
Prerequisite location: IBM
DB2 database client
databaseClientPathPanel.locationPath
If the wizard is required to search for the DB2 database client prerequisite,
(databaseClientPathPanel.prerequisiteInstalled=true), specifies the data structure within
which to search. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes. For UNIX,
supply the home directory of the DB2 instance owner..
Prerequisite search: IBM
DB2 database client
databaseClientPathPanel.prerequisiteInstalled
If the wizard fails to find a supported DB2 database client prerequisite, specifies whether
the wizard should search for the prerequisite on the computer or should install the
bundled DB2 database client prerequisite. Possible values are:
true The wizard will search for the DB2 database client prerequisite.
false The wizard will install the bundled DB2 database client prerequisite. If any
version of DB2 is already installed on the computer, the prerequisite installation
will fail.If this value is true, the corresponding value for the search for the DB2 database server
must be false, and vice versa.
Prerequisite location: IBM
DB2 database server
databaseServerPathPanel.locationPath
If the wizard is required to search for the DB2 database server prerequisite, (-W
databaseServerPathPanel.prerequisiteInstalled=true), specifies the data structure within
which to search. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes. For UNIX,
supply the home directory of the DB2 instance owner.
Silent installation: servers and databases using SPB
282 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 53. Software package block keys for server and database installations (continued)
Parameter SPB parameter key name
Description
Prerequisite search: IBM
DB2 database server
databaseServerPathPanel.prerequisiteInstalled
If the wizard fails to find a supported DB2 database server prerequisite, specifies
whether the wizard should search for the prerequisite on the computer or should install
the bundled DB2 database server prerequisite. Possible values are:
true The wizard will search for the DB2 database server prerequisite.
false The wizard will install the bundled DB2 database server prerequisite. If any
version of DB2 is already installed on the computer, the prerequisite install will
fail.If this value is true, the corresponding value for the search for the DB2 database client
must be false, and vice versa.
Prerequisite install
location: IBM DB2
db2InputPanel.db2_instLoc
If the wizard needs to install the IBM DB2 prerequisite, specifies the directory in which
to install it. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes. For UNIX,
supply the home directory of the DB2 instance owner, that, when concatenated with the
DB2 instance owner ID, gives the path to the install location of DB2. For example, if the
location is /home/db2inst1, where db2inst1 is the instance owner’s id, enter just /home.
Prerequisite install
parameters: IBM DB2
administrator password
db2InputPanel.db2_password
If the wizard needs to install the IBM DB2 prerequisite, specifies the password for the
DB2 administrator ID.
Prerequisite install
parameters: IBM DB2
port number
db2InputPanel.db2_port
If the wizard needs to install the IBM DB2 prerequisite, specifies the port number on
which DB2 should listen.
Prerequisite install
parameters: IBM DB2
administrator ID
db2InputPanel.db2_userName
If the wizard needs to install the IBM DB2 prerequisite, specifies the DB2 administrator
user ID that the wizard will create on the computer. The ID must respect the rules of the
computer on which it will be created. For UNIX specify the user id of the DB2 instance
owner.
Prerequisite setup file
location: IBM DB2
db2SetupFile.name
If the wizard needs to install the IBM DB2 prerequisite, specifies the location of the
setup file. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes.
Administration server:
database host name
dbInstallAdmin.hostName
The host name of the computer where the remote administration server database resides.
This value is ignored if the administration server is not being installed, or if the
administration server database is being installed with the administration server.
Administration server:
database port number
dbInstallAdmin.portNumber
The port number that the remote administration server database listens on.
This value is ignored if the administration server is not being installed, or if the DB2
database client prerequisite is also being installed.
Runtime server: database
address
dbInstallRuntime.hostName
The address of the computer where the runtime server database resides.
This value is ignored if the runtime server is not being installed, or if the runtime server
is being installed at the same time as the runtime server database.
Silent installation: servers and databases using SPB
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 283
Table 53. Software package block keys for server and database installations (continued)
Parameter SPB parameter key name
Description
Runtime server: database
port number
dbInstallRuntime.portNumber
The port number used to communicate with the runtime server database.
This value is ignored if the runtime server is not being installed, or if the DB2 database
client prerequisite is also being installed.
Install location installLocation
The location where the selected components are to be installed. Specify a valid directory
that does not contain any other installed product. If the directory does not exist it will be
created. If the directory path contains spaces, enclose it in double-quotes. If no value is
specified, the install location defaults to the directory where the install wizard was
started.
Install runtime server
component
runtime.active
Specifies whether or not the runtime server component should be installed. Possible
values are:
true The server will be installed.
false The server will not be installed.
Install runtime database
component
runtimeDB.active
Specifies whether or not the runtime server database component should be installed.
Possible values are:
true The database will be installed.
false The database will not be installed.
Prerequisite install
location: IBM HTTP
Server
wasInputPanel.ihs_instLoc
If the wizard needs to install the WebSphere Application Server prerequisite, specifies
the directory in which to install the IBM HTTP Server. It must be provided as a full
pathname, and if the pathname includes directories with spaces in their names, it must
be enclosed in double quotes.
Prerequisite install
parameters: IBM
WebSphere Application
Server Administrator
password
wasInputPanel.service_password
If the wizard needs to install the WebSphere Application Server prerequisite on
Windows, specifies the Administrator password needed to install WebSphere Application
Server and the IBM HTTP Server as services.
Prerequisite install
location: IBM WebSphere
Application Server
wasInputPanel.was_instLoc
If the wizard needs to install the WebSphere Application Server prerequisite, specifies
the directory in which to install it. It must be provided as a full pathname, and if the
pathname includes directories with spaces in their names, it must be enclosed in double
quotes.
Prerequisite setup file
location: IBM WebSphere
Application Server
wasSetupFile.name
If the wizard needs to install the WebSphere Application Server prerequisite, specifies
the location of the setup file. It must be provided as a full pathname, and if the
pathname includes directories with spaces in their names, it must be enclosed in double
quotes.
Setup type *** parameter not used ***
Response file equivalent = -W setupType.selectedSetupTypeId=″Custom″
This installation method does not support an ″All components″ or ″Typical″ installation.
All installations are ″Custom″.
Silent installation: servers and databases using SPB
284 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 53. Software package block keys for server and database installations (continued)
Parameter SPB parameter key name
Description
Base configuration: use
tlmsrv password for all
passwords
*** parameter not used ***
Response file equivalent = -W baseConfig.useSamePwds=true
This option is always true, defining that the tlmsrv password is to be used for the other
password that needs to be created; the runtime communications password.
Runtime server: runtime
communication password
*** parameter not used ***
Response file equivalent = -W otherPasswords.runtimeToAdminPwd=
This value is ignored because the tlmsrv password is used for all passwords.
Prerequisite install
parameters: IBM
WebSphere Application
Server
*** parameter not used ***
Response file equivalent = -W wasInputPanel.service_active=″true″
This option is always set to true so that WebSphere Application Server and IBM HTTP
Server are always installed as services.
Prerequisite install
parameters: IBM
WebSphere Application
Server Administrator ID
*** parameter not used ***
Response file equivalent = -W wasInputPanel.service_userName=″Administrator″
This parameter does not need to be supplied. If a value for this parameter is needed by
the installation, the value ″Administrator″ is used, instead.
Administration server
database administration
user (UNIX only)
*** parameter not used ***Response file equivalent = -W dbInstallAdmin.dbAdminUser
This parameter does not need to be supplied. If a value for this parameter is needed by
the installation, the value of the parameter db2InputPanel.db2_userName is used, instead.
Runtime server database
administration user
(UNIX only)
*** parameter not used ***Response file equivalent = -W dbInstallRuntime.dbAdminUser
This parameter does not need to be supplied. If a value for this parameter is needed by
the installation, the value of the parameter db2InputPanel.db2_userName is used, instead.
Server and database silent uninstallations
The recordFile_Uninstall.txt file, which is provided with Tivoli License
Manager, is an InstallShield options file. It defines arguments to set each parameter
that must be provided to the Tivoli License Manager uninstall wizard.
To launch the uninstall wizard in silent mode, launch the uninstaller command.
See “Uninstalling the Tivoli License Manager server and database components” on
page 203 for a full description.
The command runs using all the arguments that are defined in the options file
recordFile_Uninstall.txt. See Table 54 on page 286 for descriptions of the
arguments and the possible values that you can set.
Silent installation: servers and databases using SPB
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 285
Table 54. Server and database silent uninstall parameters
Parameter Parameter key name Default
Description
Uninstall administration
server component
-P admin.activeForUninstall= true
Specifies whether or not the administration server component should be uninstalled.
Possible values are:
true The server will be uninstalled.
false The server will not be uninstalled.This parameter will be ignored if the component is not installed on the computer.
Uninstall administration
database component
-P adminDB.activeForUninstall= true
Specifies whether or not the administration server database should be uninstalled.
Possible values are:
true The database will be uninstalled.
false The database will not be uninstalled.This parameter will be ignored if the component is not installed on the computer.
Uninstall runtime server
component
-P runtime.activeForUninstall= true
Specifies whether or not the runtime server component should be uninstalled. Possible
values are:
true The server will be uninstalled.
false The server will not be uninstalled.This parameter will be ignored if the component is not installed on the computer.
Uninstall runtime database
component
-P runtimeDB.activeForUninstall= true
Specifies whether or not the runtime server database component should be
uninstalled. Possible values are:
true The database will be uninstalled.
false The database will not be uninstalled.This parameter will be ignored if the component is not installed on the computer.
Uninstall agent component -P agent.activeForUninstall= true
Specifies whether or not the agent component should be uninstalled. This option only
uninstalls the agent if it had been installed using an ″All components″ installation. If
the agent has been installed by any of the other agent deployment methods, it must
be uninstalled as described in “Uninstalling the agent” on page 208. Possible values
are:
true The agent will be uninstalled.
false The agent will not be uninstalled.This parameter will be ignored if the component is not installed on the computer.
Uninstalling databases: drop
database?
-W uninstallFeature.dbDropping= false
Specifies whether or not any Tivoli License Manager databases on this computer
should be deleted (dropped). The administration server database should only be
dropped if you are certain that you will not need any of the data it has accumulated.
The runtime server database, if it is installed on its own, should always be dropped. If
both types of database are installed, and the administration server database is to be
retained, you should not drop the databases and then, after the uninstallation has
completed, you should drop the runtime server database manually, see “Dropping the
Tivoli License Manager databases manually” on page 207. Possible values are:
true The databases will be dropped.
false The databases will not be dropped.This parameter will be ignored if no database components are being uninstalled.
Silent uninstallation: servers and databases
286 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 54. Server and database silent uninstall parameters (continued)
Parameter Parameter key name Default
Description
WebSphere Application
Server security cell user ID
-W was_credential.UserId=
Defines the user ID to be used to access WebSphere Application Server if WebSphere
Application Server is in a secure cell.
This parameter will be ignored if WebSphere Application Server is not in a secure cell.
WebSphere Application
Server security cell
password
-W was_credential.Pwd=
Defines the password to be used to access WebSphere Application Server if
WebSphere Application Server is in a secure cell.
This parameter will be ignored if WebSphere Application Server is not in a secure cell.
Catalog manager silent installation
When the install wizard runs in unattended mode, it takes the parameters it
requires from an InstallShield options file. The options file,
recordFile_Install.txt, is provided with the catalog manager. You must edit this
file to provide the values for parameters that the wizard must set.
To run the install wizard in silent mode, follow the procedure described in
“Choosing the installation method” on page 189.
The command runs using the arguments that are defined in the
recordFile_Install.txt file. Table 55 describes the contents of the file.
Table 55. Catalog manager silent install parameters
Parameter Argument Default
Description
Install location -P installLocation=
The location where the catalog manager is to be installed. Specify a valid directory that
does not contain any other installed product. If the directory does not exist it will be
created. If the directory path contains spaces, enclose it in double-quotes. If no value is
specified, the install location defaults to the directory where the install wizard was
started.
Prerequisite search: IBM
DB2 database client
-W databaseClientPathPanel.prerequisiteInstalled= true
If the wizard fails to find a supported DB2 database client prerequisite, specifies
whether the wizard should search for the prerequisite on the computer or should install
the bundled DB2 database client prerequisite. Possible values are:
true The wizard will search for the DB2 database client prerequisite.
false The wizard will install the bundled DB2 database client prerequisite. If any
version of DB2 is already installed on the computer, the prerequisite install will
fail.
Prerequisite location: IBM
DB2 database client
-W databaseClientPathPanel.locationPath= ″C:\Program Files″
If the wizard is required to search for the DB2 database client prerequisite, (-W
databaseClientPathPanel.prerequisiteInstalled=true), specifies the data structure within
which to search. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes. For UNIX,
supply the home directory of the DB2 instance owner.
Silent uninstallation: servers and databases
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 287
Table 55. Catalog manager silent install parameters (continued)
Parameter Argument Default
Description
Prerequisite setup file
location: IBM DB2
-W db2SetupFile.name=
If the wizard needs to install the IBM DB2 prerequisite, specifies the location of the
setup file. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes.
Prerequisite install
location: IBM DB2
-W db2InputPanel.db2_instLoc=
If the wizard needs to install the IBM DB2 prerequisite, specifies the directory in which
to install it. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes. For UNIX,
supply the home directory of the DB2 instance owner, that, when concatenated with the
DB2 instance owner ID, gives the path to the install location of DB2. For example, if the
location is /home/db2inst1, where db2inst1 is the instance owner’s id, enter just /home.
Prerequisite install
parameters: IBM DB2
administrator ID
-W db2InputPanel.db2_userName= ″db2admin″
If the wizard needs to install the IBM DB2 prerequisite, specifies the DB2 administrator
user ID that the wizard will create on the computer. The ID must respect the rules of the
computer on which it will be created. For UNIX specify the user ID of the DB2 instance
owner.
Prerequisite install
parameters: IBM DB2
administrator password
-W db2InputPanel.db2_password=
If the wizard needs to install the IBM DB2 prerequisite, specifies the DB2 administrator
password that will be used when the DB2 Administrator ID is created. The maximum
length is 20 characters and the characters allowed are: A-Z a-z 0-9 + - =. The password
must respect the rules of the computer on which it will be created.
Note: Passwords entered in this file are not encrypted. This may be a security violation
in your organization.
Database address -W dbCatalog.hostName= ″localhost″
Specifies the host name of the computer where the database of product information is
located.
Database port number -W dbCatalog.portNum=
Specifies the port to be used for communications between the catalog manager and the
database.
Database instance owner
(UNIX only)
-W dbCatalogAIX.dbInstOwner ″db2inst1″
On UNIX platforms, specifies the instance owner of the local DB2 database.
Software package block for catalog manager installation using Tivoli
Configuration Manager
This section documents the keys used in the software package block that allow you
to install the catalog manager remotely using the Software Distribution component
of Tivoli Configuration Manager. How to use this installation method is described
in “Choosing the installation method” on page 189.
Use the information in Table 56 on page 289 to supply the correct values when
Software Distribution displays its Default Variables panel.
Table 56 on page 289 lists the software package block parameters in alphabetic
order of the parameter key name, so that you can find the keys more easily.
Default values are not supplied, as the defaults vary according to the platform.
Silent installation: catalog manager
288 IBM Tivoli License Manager: Planning, Installation, and Configuration
Notes:
1. The order of the keys in the SPB is neither alphabetic (like this table) nor
logical (like the response file). It follows the internal logic of Software
Distribution. Thus, to find the description and permitted values of a specific
parameter, look it up in alphabetical order in the table.
2. The SPB parameter key names are almost identical to the corresponding
response file parameter name. The only difference should be that the response
file parameter names have a –W or –P prefix that is not present in the SPB
parameter key names.
Table 56. Software package block keys for catalog manager installation
Parameter SPB parameter key name
Description
Prerequisite location:
IBM DB2 database
client
databaseClientPathPanel.locationPath
If the wizard is required to search for the DB2 database client prerequisite,
(databaseClientPathPanel.prerequisiteInstalled=true), specifies the data structure within
which to search. It must be provided as a full pathname, and if the pathname includes
directories with spaces in their names, it must be enclosed in double quotes. For UNIX,
supply the home directory of the DB2 instance owner.
Prerequisite search:
IBM DB2 database
client
databaseClientPathPanel.prerequisiteInstalled
If the wizard fails to find a supported DB2 database client prerequisite, specifies whether
the wizard should search for the prerequisite on the computer or should install the bundled
DB2 database client prerequisite. Possible values are:
true The wizard will search for the DB2 database client prerequisite.
false The wizard will install the bundled DB2 database client prerequisite. If any version
of DB2 is already installed on the computer, the prerequisite install will fail.
Prerequisite install
location: IBM DB2
db2InputPanel.db2_instLoc
If the wizard needs to install the IBM DB2 prerequisite, specifies the directory in which to
install it. It must be provided as a full pathname, and if the pathname includes directories
with spaces in their names, it must be enclosed in double quotes. For UNIX, supply the
home directory of the DB2 instance owner, that, when concatenated with the DB2 instance
owner ID, gives the path to the install location of DB2. For example, if the location is
/home/db2inst1, where db2inst1 is the instance owner’s id, enter just /home.
Prerequisite install
parameters: IBM DB2
administrator
password
db2InputPanel.db2_password
If the wizard needs to install the IBM DB2 prerequisite, specifies the DB2 administrator
password that will be used when the DB2 Administrator ID is created. The maximum
length is 20 characters and the characters allowed are: A-Z a-z 0-9 + - =. The password
must respect the rules of the computer on which it will be created.
Note: Passwords entered in this file are not encrypted. This may be a security violation in
your organization.
Prerequisite install
parameters: IBM DB2
administrator ID
db2InputPanel.db2_userName
If the wizard needs to install the IBM DB2 prerequisite, specifies the DB2 administrator user
ID that the wizard will create on the computer. The ID must respect the rules of the
computer on which it will be created. For UNIX specify the user ID of the DB2 instance
owner.
Prerequisite setup file
location: IBM DB2
db2SetupFile.name
If the wizard needs to install the IBM DB2 prerequisite, specifies the location of the setup
file. It must be provided as a full pathname, and if the pathname includes directories with
spaces in their names, it must be enclosed in double quotes.
Database instance
owner (UNIX only)
dbCatalogAIX.dbInstOwner
On UNIX platforms, specifies the instance owner of the local DB2 database.
Silent installation: catalog manager using SPB
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 289
Table 56. Software package block keys for catalog manager installation (continued)
Parameter SPB parameter key name
Description
Database address dbCatalog.hostName
Specifies the host name of the computer where the database of product information is
located.
Database port number dbCatalog.portNum
Specifies the port to be used for communications between the catalog manager and the
database.
Install location installLocation
The location where the catalog manager is to be installed. Specify a valid directory that
does not contain any other installed product. If the directory does not exist it will be
created. If the directory path contains spaces, enclose it in double-quotes. If no value is
specified, the install location defaults to the directory where the install wizard was started.
Silent installation of OS/400 agent
When the installation wizard for the OS/400 agent runs in unattended mode, it
takes the parameters it requires from an InstallShield options file. The options file,
recordFile_Install.txt, is provided with the product in the \setup\agent\OS400
directory on the product CD. You must edit this file to provide the values for
parameters that the wizard must set.
To run the install wizard in silent mode, follow the instructions in “Install agents
on OS/400” on page 175.
The command runs using the arguments that are defined in the
recordFile_Install.txt file. Table 57 on page 291 describes the contents of the file.
Silent installation: catalog manager using SPB
290 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 57. OS/400 silent install parameters
Parameter Argument Default
Description
Language -W setLang.languageCode=
This value can be left blank if the primary language used by the operating system of
your computer is among those listed below.
If the primary language of the system is not one of those listed, specify a language
code from the list below which is already installed as a secondary language on your
system.
If none of the languages available on your system are in the list below, you must
install one of them as a secondary language before deploying the OS/400 agent,
specifying here the language you have installed.
The supported languages are the following:
″2924″ English
″2928″ French
″2929″ German
″2932″ Italian
″2962″ Japanese
″2986″ Korean
″2980″ Portuguese (Brazil)
″2989″ Simplified Chinese
″2931″ Spanish
″2987″ Traditional ChineseFor example, to choose English language, use the following:
-W setLang.languageCode="2924"
Setup type -W setupType.selectedSetupTypeId= ″Typical″
Permitted values are as follows:
Typical This installs the agent using default values for most of the fields (details of
these values are given in “Use the OS/400 agent install wizard on a
Windows computer connected to an OS/400 node” on page 52). If you select
this value, you only need to customize the following values, leaving the rest
to take their defaults:
v –W agentConfig.organizationName
v –W agentConfig.runtimeAddress
v –W agentConfig.divisionName
Custom
This installs the agent, enabling you to customize all of the values.
Organization name -W agentConfig.organizationName=
The name of the organization to which the agent is to belong.
Runtime address -W agentConfig.runtimeAddress=
The address (host name or IP address) of the runtime server to which the agent is to
belong.
Division name -W agentConfig.divisionName=
The name of the division to which the agent is to belong.
Silent installation: OS/400 agent
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 291
Table 57. OS/400 silent install parameters (continued)
Parameter Argument Default
Description
Startup mode -W agentConfig.startupMode= ″nossl″
This determines whether SSL is or is not used for the initial connection between the
agent and the runtime server. After the initial contact, the agent runs a service which
downloads the appropriate parameters for all agents in its division, and the
downloaded values overwrite the values supplied to the installagent command.
Permitted values are:
nossl
Insecure: HTTP is used for all communications (default). The Web server where
the runtime server is installed must have an HTTP service enabled.
ssl Secure: HTTPS is used for all communications. The HTTP server where the
runtime server is installed must have an HTTPS service enabled.
Runtime port -W agentConfig.runtimePort= ″80″
The port on the runtime server used for communication.
SSL port -W agentConfig.sslPort= ″443″
If Startup mode is ssl, enter the port number used for SSL communications.
Node tag -W agentConfig.nodeTag= ″%SERIAL%VENDOR″
The name of the node on which you want to install the OS/400 agent. If you leave the
default value, the wizard will create a node tag, concatenating the contents of the
system variables %SERIAL and %VENDOR on the OS/400 node.
Use proxy? -W agentConfig.useProxy= false
Specifies whether the runtime is protected by a proxy server. The following values are
permitted:
true The runtime is protected by a proxy server.
false The runtime is not protected by a proxy server.
Proxy address -W agentConfig.proxyAddress=
If Use proxy is true, enter the address (host name or IP address) of the proxy server.
Proxy port -W agentConfig.proxyPort=
If Use proxy is true, enter the port of the proxy server.
SSL certificate: custom SSL
certificate?
-W sslCert.searchCertDir= true
This value is ignored if Startup Mode = ″nossl″.
If you have selected Startup Mode = ″ssl″ you can choose to provide your own
certificate to be used by the agent for secure communications with the runtime server.
Permitted values are:
true Indicates that you want to provide your own certificate.
false Indicates that you want to use the embedded test certificate
You should note that the embedded test certificate may only be used for test
purposes as it is in the name of IBM and is insecure (the same certificate is
distributed to all customers).If you select the value ″true″, you must also supply the certificate pathname #
(sslCert.certFilePath).
For example, to indicate that you want to use your own certificate for SSL
communications, use -W sslCert.searchCertDir=true.
Silent installation: OS/400 agent
292 IBM Tivoli License Manager: Planning, Installation, and Configuration
Table 57. OS/400 silent install parameters (continued)
Parameter Argument Default
Description
SSL certificate: custom
certificate pathname
-W sslCert.certFilePath=
This value is ignored if custom SSL certificate = ″false″ or Startup Mode = ″nossl″.
If you have selected to supply a custom SSL certificate, (SSLsslCert.searchCertDir =
″true″), you must provide the pathname of your own certificate. The name of the
certificate must be ″cert.arm″. If the path contains spaces, enclose the whole path in
double-quotes.
For example, if the pathname of your own certificate is C:\cert.arm, use -W
sslCert.certFilePath=″C:\cert.arm″
Silent installation: OS/400 agent
Appendix C. Response files and software package blocks for silent and remote installations and uninstallations 293
Silent installation: OS/400 agent
294 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix D. Common tasks
This appendix provides instructions for performing some common tasks that you
will need to perform when installing and using Tivoli License Manager, but which
are not part of Tivoli License Manager. These include tasks related to WebSphere
Application Server, the IBM HTTP Server, and DB2.
Instructions are provided for the following tasks:
v “Starting and stopping a Tivoli License Manager server”
v “Initializing the DB2 command line” on page 296
v “Starting and stopping the IBM HTTP Server” on page 296
v “Starting the WebSphere Administrator’s Console” on page 297
v “Changing passwords” on page 297
Starting and stopping a Tivoli License Manager server
To start a Tivoli License Manager server depends on the platform:
Windows
The procedure is as follows:
1. Select Start � Programs � IBM Tivoli License Manager and then
Administration server command line or Runtime server command
line, as appropriate.
2. Enter the command srvstart in the command line window.
UNIX The procedure is as follows:
1. Navigate to the following directory:
<INSTALL_DIR>/admin/cli
2. Before using a command run the following script to set the DB2 and
WebSphere Application Server environments for the command line:
. ./tlmcli
Note: (there is a space between the two periods)
These environments will remain in force until you close the command
line window.
3. Enter the command srvstart.
To stop a Tivoli License Manager server also depends on the platform:
Windows
The procedure is as follows:
1. Select Start � Programs � IBM Tivoli License Manager and then �
Administration server command lineor Runtime server command
line, as appropriate.
2. Enter the command srvstop in the command line window.
Note: If you are operating WebSphere Application Server in a secure
cell, you will need to provide the user id and password of the
secure cell as parameters to the command. See IBM Tivoli License
Manager: Administration for full details of the command.
© Copyright IBM Corp. 2002, 2004 295
UNIX The procedure is as follows:
1. Change to the following directory:
<INSTALL_DIR>/admin/cli
2. Before using a command run the following script to set the DB2 and
WebSphere Application Server environments for the command line:
. ./tlmcli
Note: (there is a space between the two periods)
These environments will remain in force until you close the command
line window.
3. Enter the command srvstop.
Note: If you are operating WebSphere Application Server in a secure
cell, you will need to provide the user id and password of the
secure cell as parameters to the command. See IBM Tivoli License
Manager: Administration for full details of the command.
Initializing the DB2 command line
This procedure is intended for users who are not familiar with DB2, and are using
the bundled prerequisite version installed with Tivoli License Manager. If you
already have an installation of the DB2, follow the procedures you would normally
use.
To initialize the DB2 command line, do the following:
On Windows
Click Start � Programs � IBM DB2 � Command Window.
This opens the DB2 command window.
On UNIX
Type:
. /home/<DB2InstanceOwner>/sqllib/db2profile
where <DB2InstanceOwner> is the user id of the instance owner of DB2.
Starting and stopping the IBM HTTP Server
This procedure is intended for users who are not familiar with the IBM HTTP
Server, and are using the bundled prerequisite version installed with Tivoli License
Manager. If you already have an installation of the IBM HTTP Server, follow the
procedures you would normally use.
To start the IBM HTTP Server, do the following:
On Windows
Click Start � Programs � IBM HTTP Server � Start HTTP Server.
On UNIX
1. Change to the directory: <IBM_HTTP_SERVER_INSTALL_DIR>/bin
2. Type:
./apachectl start
To stop the IBM HTTP Server, do the following:
Starting and stopping the server
296 IBM Tivoli License Manager: Planning, Installation, and Configuration
On Windows
Click Start � Programs � IBM HTTP Server � Stop HTTP Server.
On UNIX
1. Change to the directory: <IBM_HTTP_SERVER_INSTALL_DIR>/bin
2. Type:
./apachectl stop
Starting the WebSphere Administrator’s Console
This procedure is intended for users who are not familiar with WebSphere
Application Server, and are using the bundled prerequisite version installed with
Tivoli License Manager. If you already have an installation of WebSphere
Application Server, follow the procedures you would normally use.
To start the WebSphere Administrator’s Console, do the following:
On Windows
Click �Start � Programs � IBM WebSphere � Application server v5.x �
Administrative Console
On UNIX
1. Locate the WebSphere Application Server install directory:
Note: If you are not sure which directory this is, follow these steps:
a. Change to one of the Tivoli License Manager server’s home
directories:
v <INSTALL_DIR>/admin
v <INSTALL_DIR>/runtimeb. View the file master.tag.
c. The install directory for WebSphere Application Server is
indicated by the key: TLM_WAS_PATH.2. Change to the WebSphere Application Server program directory:
<TLM_WAS_PATH>/bin
3. Start the server: Type:
./startServer.sh server1
4. Start your Web browser: It does not have to be on the same computer as
the server.
5. Access the server: Enter the following Web address:
http://<serverAddress>:9090/admin/
Where <serverAddress> is the host name or IP address of the server on
which you want to run the console.
Changing passwords
If you need to change the passwords for any reason, follow these procedures to
ensure that the components maintain the required access:
tlmsrv password
On every computer where you install a database component, the
installation process will create a user id called ″tlmsrv″. The user id is used
for communications between the server and database components. The
password is assigned at installation, and must also be supplied during the
installation of the corresponding server.
Starting and stopping IBM HTTP Server
Appendix D. Common tasks 297
To change the tlmsrv password after installation you have to perform the
following:
1. Use the dbpasswd command on the server (administration or runtime,
as appropriate) to change the value for the password recorded in the
product’s database
2. Stop the server.
3. Use the normal user management features on the computer where the
database is installed to change the password value of the tlmsrv user to
the value you supplied in step 1.
4. Restart the server.
Runtime server communication password
This is used to authenticate communications between a runtime server and
its administration server. Each runtime server’s communication password
is assigned at installation. It can be different from the ″tlmsrv″ password
and from any other runtime server’s password.
You can change the runtime server communication password after
installation by performing the following:
1. Run the rtpasswd command on the runtime server and supply a new
value.
2. Stop the runtime server.
3. Use the administration server GUI to change the administration server’s
password for that runtime server to the same value.
4. Restart the runtime server.
It is not important whether you change the runtime server password first
on the administration server or first on the runtime server, but once one
has been changed, no communication will take place between the servers
until you change the other to the same value.
SSL password
Each server that is enabled to use SSL communications requires a
password to access its SSL key store. The default SSL password (″slmtest″)
is assigned at installation.
You can change the SSL communications password after installation by
performing the following:
1. Run the sslpasswd command on the server to change the value of the
password. The passwords are only used by the server itself, so different
values can be selected for each server, if you wish.
2. Stop the server.
3. Use the IKeyMan utility to change the value of the keystore’s password
to the value you supplied in step 1.
4. Start the server.
DB2 administration password
The DB2 administration user has specific rights that allow you to carry out
administration tasks on DB2.
You can change the DB2 administration password after installation using
the normal user management features of the computer.
Administrator password (to set up WebSphere Application Server and the IBM
HTTP Server as services)
If you installed WebSphere Application Server and the IBM HTTP Server
on Windows platforms as part of the product installation, you supplied the
Changing passwords
298 IBM Tivoli License Manager: Planning, Installation, and Configuration
Administrator password to allow these to be set up as services. If you
installed them separately, you may have decided to set them up as
services.
If you want to change the Administrator password on a server you should
follow this procedure:
1. Use the normal user management features on the server to change the
password value.
2. Open the services panel by selecting: Start � Settings � Control Panel
� Administrative Tools � Services
3. Select each of the items relating to these products and perform the
following:
a. Right click on the item
b. Select the Properties option
c. On the Properties window that is opened, select the Log On tab.
d. If This account: is ″Administrator″, type the new password and
confirm it.
e. Click on OK.4. Close the Services window.
5. Restart the server.
Changing passwords
Appendix D. Common tasks 299
Changing passwords
300 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix E. Database table cleanup
The usage tables in the administration server database is continually added to by
internal processes, adding usage snapshot and usage update transactions. Tivoli
License Manager includes cleanup processes that you can run on a regular basis to
prevent these tables from reaching an unmanageable size.
Performance and sizing considerations
Because the internal processes are continually adding new entries to these tables,
intervention is needed to stop the tables from growing to proportions that might
affect performance.
For example, in an environment with 15 000 agents, it would require only ten
transactions per hour over a ten hour working day to add 1.5 million entries to the
usage tables in a single day. The usage tables are the source of data used in the
software usage reports, and performance of these reports would be affected if the
table became too large.
Setting parameters for cleanup processes
Tivoli License Manager provides a cleanup process for the usage tables.
The administration server section of the system.properties file includes properties
that control how often the processes are to run and the length of time for which
entries are to be retained. These properties are set to default values, but you can
define them to suit your needs.
Each server has its own system.properties file. The file in which you need to set
these parameters is located on the administration server in the directory:
<INSTALL_DIR>\admin\SLM_Admin_Application.ear\slm_admin.war\WEB-INF\conf
For information about the system.properties file, see Appendix A, “Configuration
settings,” on page 233.
The usage tables cleanup process runs regularly at intervals determined by the
cleanUsagePeriod parameter. The default for this parameter is one day (1440
minutes). If you set this value to any exact multiple of 7 days, the cleanup is done
at that frequency on a Saturday at the time indicated by the parameter
adminBaseTime. For example, if you set this parameter to 40320 (exactly four weeks
in minutes) and leave adminBaseTime to take its default of 23:00 (11 p.m.), the
cleanup will be performed every fourth Saturday at 23:00 (see “Timing of events
and services” on page 235 for full details).
The cleanup process identifies usage transactions that are older than the number of
days specified in the maxUsageAge parameter (default value 30 days). These
transactions are cleared from the table and the detailed software usage information
that they provided is no longer available to the software usage reports. However, a
less detailed record is maintained by adding entries to the usage history tables.
These tables include entries for each unique combination of license pool, date, and
time in several categories. The quantity of licenses assigned for all transactions that
© Copyright IBM Corp. 2002, 2004 301
match on all three parameters are examined and the highest value is recorded in
the usage history entries. In this way, a record of the high-water mark is
maintained at the license pool, date, and time level in these categories. This
information is accessible using DB2 queries, making reference to the table
definitions in IBM Tivoli License Manager: Data Dictionary.
Finally, one way of determining if this value is too high is to run the Use Snapshot
report. If you notice that while the report is running the performance significantly
degrades, you should lower this value. This assumes that your hardware platform
is sufficiently powerful, and that the network connection between the
administration server and its database is fast.
Parameters for cleanup
302 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix F. UNIX agent deployment wizard import file formats
The agent deployment wizard, described in Chapter 4, “Deploy agents,” on page
139, provides an option that enables you to import data to be used in agent
deployment. Two sorts of data can be imported, as follows:
Agents
This is data that describes one or more agents. It is in a flat structure that
does not represent the hierarchical topology of your Tivoli License
Manager environment.
This data is used to fill the lower half of the panel shown in step Add
node data on page 165 (Add node data)
The format of this imported data is XML, and is described in “Agents’
import format.”
Topology
This is data that represents the topology of your Tivoli License Manager
environment. It identifies one or more organizations, each of which
contains one or more divisions and one or more runtime servers.
This data is used to create the topological structure in the upper half of the
panel shown in step Add node data on page 165 (Add node data). After
importing this data you can use it as basis to define nodes, as detailed in
the panel description.
The format of this imported data is XML, and is described in “Topology
import format” on page 307.
A file in this format can be created by running the command
dataexp XML –topology output_directory from the administration server
command line (see IBM Tivoli License Manager: Administration for a full
description of the command).
Each format must be in a separate physical file and each element must be
complete, with its start tag and end tag. If any elements are missing from the
described structures when the file is imported, their values, and the value of any
child elements, will be blank.
Agents’ import format
The format for the agents is determined by a schema file called ITLMTopology.xsd,
which can be found on the product CD in the directory where the agent
deployment wizard is found. When you copy the wizard to hard disk, you should
also copy this file. The XML file produced with reference to this schema can
contain details of agents or topology, but not both.
It is important that the XML file contains no DTD or any other reference to
external files.
The following gives details of the format for agents:
<Agents>
<Agent>
<Organization>organization</Organization>
<Runtime>runtime_server_name</Runtime>
<Division>division_name</Division>
© Copyright IBM Corp. 2002, 2004 303
<Endpoint>node</Endpoint>
<PortNumber>port_number</PortNumber>
<SslPortNumber>SSL_port_number</SslPortNumber>
<SecurLevel>security_level</SecurLevel>
<OperatingSystem>operating_system</OperatingSystem>
<Password>root_password</Password>
</Agent>
</Agents>
Where:
<Agents>
Parent element: None
Occurs: Once
<Agent>
Parent element: Agents
Occurs: Many
<Organization>
Parent element: Agent
The organization to which the node belongs.
Alphanumeric
Occurs: Once per parent
<Runtime>
Parent element: Agent
The runtime server host name or IP address with which the node should
register.
Alphanumeric
Occurs: Once per parent
<Division>
Parent element: Agent
The division to which the node belongs.
Alphanumeric
<Endpoint>
Parent element: Agent
The full network id of the node.
Alphanumeric
Occurs: Once per parent
<PortNumber>
Parent element: Agent
The non-SSL port used by the runtime server.
Numeric
Occurs: Once per parent
<SslPortNumber>
Parent element: Agent
UNIX deployment wizard: import file formats
304 IBM Tivoli License Manager: Planning, Installation, and Configuration
The SSL port used by the runtime server. If you do not want to
implement SSL between this agent and the runtime server, leave this
blank.
Numeric
Occurs: Once per parent
<SecurLevel>
Parent element: Agent
The values are:
NO SSL
Insecure: HTTP is used for all communications.
SSL Secure:HTTPS is used for all communications.
Occurs: Once per parent
<OperatingSystem>
Parent element: Agent
The operating system of the node, from the following list (exactly as
written):
aix
hpux
linux
linux-s390
linux-ppc
sun32
sun64
Occurs: Once per parent
<Password>
Parent element: Agent
The root password of the node.
Alphanumeric
Occurs: Once per parent
For example:
<?xml version="1.0" encoding="UTF-8"?>
<Agents>
<Agent>
<Customer>IBM</Customer>
<Runtime>Rome_runtime</Runtime>
<Division>Sales</Division>
<Endpoint>jrgg28Tb</Endpoint>
<PortNumber>80</PortNumber>
<SslPortNumber></SslPortNumber>
<SecurLevel>1</SecurLevel>
<OperatingSystem>Sun32</OperatingSystem>
<Password>afc123thy</Password>
</Agent>
</Agents>
UNIX deployment wizard: import file formats
Appendix F. UNIX agent deployment wizard import file formats 305
Import format for agents on Linux s390
On Linux s390, there are three additional fields to supply, as follows:
<Agents>
<Agent>
<processorType>processor_type</processorType>
<sharedPoolCapacity>shared_pool_capacity</sharedPoolCapacity>
<systemActiveProcessors>system_active_processors</systemActiveProcessor>
</Agent>
</Agents>
Where:
<Agents>
Parent element: None
Occurs: Once
<Agent>
Parent element: Agents
Occurs: Many
<processorType>
Parent element: Agent
If you have supplied Linux-s390 as operating_system, you must supply
this field; otherwise leave this field blank. Specify if the Linux390 image
is running on CP or IFL processors. Permitted values are
CP
Supply if the Linux390 image is running on CP processors
IFL
Supply if the Linux390 image is running on IFL processors
Occurs: Once per parent
<sharedPoolCapacity>
Parent element: Agent
If you have supplied Linux-s390 as operating_system, you must supply
this field; otherwise leave this field blank. If the Linux390 image is
configured to share processors, specify the total number of shared
processors (CP or IFL, as appropriate, not both) in the CEC. Enter zero if
no shared processors are used by this image.
Numeric
Occurs: Once per parent
<systemActiveProcessors>
Parent element: Agent
If you have supplied Linux-s390 as operating_system, you must supply
this field; otherwise leave this field blank. Specify the total number of
processors (CP or IFL, as appropriate, not both) in the CEC.
Numeric
Occurs: Once per parent
For example, the complete file could look as follws:
<?xml version="1.0" encoding="UTF-8"?>
<Agents>
<Agent>
UNIX deployment wizard: import file formats
306 IBM Tivoli License Manager: Planning, Installation, and Configuration
<Customer>IBM</Customer>
<Runtime>Rome_runtime</Runtime>
<Division>Sales</Division>
<Endpoint>jrgg28Tb</Endpoint>
<PortNumber>80</PortNumber>
<SslPortNumber></SslPortNumber>
<SecurLevel>1</SecurLevel>
<OperatingSystem>Linux-s390</OperatingSystem>
<Password>afc123thy</Password>
<processorType>CP</processorType>
<sharedPoolCapacity>5</sharedPoolCapacity>
<systemActiveProcessors>20</systemActiveProcessor>
</Agent>
</Agents>
Topology import format
The format for the Tivoli License Manager topology is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<Topology>
<Organization>
<Name>your_organization</Name>
<Division>
<OrganizationName>your_organization</OrganizationName>
<Id>division_ID</Id>
<Name>division_name</Name>
</Division>
<Runtime>
<OrganizationName>your_organization</OrganizationName>
<Name>runtime_server_name</Name>
<Address>runtime_server_address</Address>
<PortNumber>port_number</PortNumber>
<SslPortNumber>SSL_port_number</SslPortNumber>
</Runtime>
</Organization>
</Topology>
Where:
<Topology>
Parent element: None
Occurs: Once
<Organization>
Parent element: Topology
Occurs: Many
<Name>
Parent element: Organization
The organization to which the divisions and runtime servers belong.
Alphanumeric
Occurs: Once per parent
<Division>
Parent element: Organization
Occurs: Many
UNIX deployment wizard: import file formats
Appendix F. UNIX agent deployment wizard import file formats 307
<OrganizationName>
Parent element: Division
The organization to which the divisions belong.
Alphanumeric
Occurs: Once per parent
<Id>
Parent element: Division
Not used by the import option.
Occurs: Once per parent
<Name>
Parent element: Division
The name of the division.
Alphanumeric
Occurs: Once per parent
<Runtime>
Parent element: Organization
Occurs: Many
<OrganizationName>
Parent element: Organization
The organization to which the runtime servers belong.
Alphanumeric
Occurs: Once per parent
<Name>
Parent element: Runtime
The name of the runtime server with which the node should register.
Alphanumeric
Occurs: Once per parent
<Address>
Parent element: Runtime
The network address of the runtime server with which the node
should register.
Alphanumeric
Occurs: Once per parent
<PortNumber>
Parent element: Runtime
The non-SSL port used by the runtime server.
Numeric
Occurs: Once per parent
UNIX deployment wizard: import file formats
308 IBM Tivoli License Manager: Planning, Installation, and Configuration
<SslPortNumber>
Parent element: Runtime
The SSL port used by the runtime server. If you do not want to
implement SSL between this agent and the runtime server, leave this
blank.
Numeric
Occurs: Once per parent
It is important that the XML file contains no DTD or any other reference to
external files.
For example:
<Topology>
<Organization>
<Name>IBM</Name>
<Division>
<OrganizationName>IBM</OrganizationName>
<Id>SL765898</Id>
<Name>Sales</Name>
</Division>
<Runtime>
<OrganizationName>IBM</OrganizationName>
<Name>Rome_runtime</Name>
<Address>runtime.mydomain.it</Address>
<PortNumber>80</PortNumber>
<SslPortNumber></SslPortNumber>
</Runtime>
<Runtime>
<OrganizationName>IBM</OrganizationName>
<Name>Paris_runtime</Name>
<Address>runtime.mydomain.fr</Address>
<PortNumber>80</PortNumber>
<SslPortNumber>443</SslPortNumber>
</Runtime>
</Organization>
</Topology>
UNIX deployment wizard: import file formats
Appendix F. UNIX agent deployment wizard import file formats 309
UNIX deployment wizard: import file formats
310 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix G. Enabling graphics for an administration server
on UNIX (X-display)
When the administration server is installed on an UNIX platform, the preparation
of graphical images, for example charts, depends on access to an X display server.
This procedure tells you how to enable that access, and must be repeated each
time you start the administration server. If the procedure is not run, users will
receive an error message every time they attempt to display a GUI page containing
a chart, or other graphic.
The details of the procedure depend on whether there is an X display server
running on the administration server computer.
To determine whether there is an X display server running on the computer, type:
ps -ef |grep X
If an X display server is running, the output will include some lines similar to the
following:
root 3394 2172 = Mar 20 - 5:09 /usr/lpp/X11/bin/X -x abx
-x dbe -x GLX -D /usr/lib/X11/rgb -T -force :0 - auth
/var/dt/A:= -lfchMa
If there is no X display server running, you need to locate a computer nearby in
the network, where an X display server is running. You must ensure that there are
no security settings that will prevent the opening of a connection between the
administration server computer and the X display server computer.
The procedures also depend on whether you are accessing the computer to start
the administration server locally, or through a non-graphical remote connection,
such as Telnet. The problem with these connection mechanisms is that they do not
set the DISPLAY environment variable, which, in the environment where you are
running Java, identifies the path to the X display server.
There are now four possible situations:
Is the X-display server running on the
administration server computer?
Yes Yes No
Are you accessing the administration
server remotely via a Telnet-like
connection?
No Yes Immaterial
Procedure to follow: Take no action
– the
administration
server will
locate the X
display
server..
See “Enabling
X display
locally” on
page 312
See “Enabling
X display
remotely” on
page 312
© Copyright IBM Corp. 2002, 2004 311
Enabling X display locally
If the X display server is installed on the same computer as the administration
server, and you are accessing the administration server from a remote Telnet-like
session, complete the following steps:
1. Log in to the administration server computer, using a remote Telnet-like
session, as root.
2. If the administration server is running, stop it, using the srvstop command.
3. Set the DISPLAY variable for your remote Telnet-like session, as follows:
export DISPLAY=<AdminServerHostName>:0.0where <AdminServerHostName>
is the host name of the computer where the administration server is installed.
4. Start the administration server using the srvstart command.
Enabling X display remotely
If the X display server is installed on a different computer to the administration
server, complete the following steps:
1. Log in to the computer where the X display server is installed, as root.
2. Add the host name of the computer where the administration server is installed
to the list of computers from which the X display server accepts connections, as
follows:
xhost +<AdminServerHostName>where <AdminServerHostName> is the host
name of the computer where the administration server is installed.
3. Log in to the administration server computer, either locally or remotely, as root.
4. If the administration server is running, stop it, using the srvstop command.
5. Set the DISPLAY variable on the computer where the X display server is
installed, as follows:
export DISPLAY=<XDisplayServerHostName>:0.0
6. Start the administration server using the srvstart command.
312 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix H. Running elements of the install or uninstall
procedures manually
In the event of a failure of the install wizard after the Tivoli License Manager
components have been installed, it is sometimes possible, after having corrected
the condition that caused the failure, to rerun the procedure manually. You may
also be able to manually run uninstall procedures where the uninstall wizard has
failed after the Tivoli License Manager components have been uninstalled.
This appendix details these manual procedures. See “What to do if the wizard
fails” on page 94 and IBM Tivoli License Manager: Problem Determination to
determine when and how these procedures are used.
The procedures available are as follows:
v “Creating and populating a database for Tivoli License Manager”
v “Connecting a Tivoli License Manager database to its server” on page 314
v “Disconnecting a Tivoli License Manager database from its server” on page 315
Creating and populating a database for Tivoli License Manager
If the install wizard fails to create one or other of the IBM DB2 databases, use this
procedure, once you have corrected the problem that caused the failure, to create
the database.
The procedure is as follows:
1. Resolve the problem that caused the original installation to fail. See “What to
do if the wizard fails” on page 94 for assistance with this.
2. Ensure that the DB2 instance where you want to install the product database
has been cleaned of all references to the database you are about to install. Refer
to the DB2 documentation to discover how to drop, remove and uncatalog any
databases that might have been installed previously.
3. Create the databases on the different platforms, as follows:
a. Log on to the DB2 server computer as Administrator (Windows) or root
(UNIX).
b. On Windows, from the Start menu, open a Command Prompt window.
c. Change to the product’s DB2 directory:
Administration server
<INSTALL_DIR>\admin\db\db2
Runtime servers
<INSTALL_DIR>\runtime\db\db2
d. Enter the following command:
Windows
dbrootinstall.bat
UNIX
. ./dbrootinstall.sh
© Copyright IBM Corp. 2002, 2004 313
Connecting a Tivoli License Manager database to its server
If you have verified that a Tivoli License Manager server is disconnected from its
database, these are the steps to recover the situation. The instructions for
connecting a database to a server are as follows:
1. Log on to the computer where the DB2 server is installed as a user with
administrator rights (Administrator or a DB2 administrator on Windows
platforms or root on UNIX platforms).
2. Using a text editor, open one of the following files:
UNIX
/etc/services
Windows
C:\winnt\system32\drivers\etc\services
and search for a row with the following information:
<service> <port>/tcp # Connection port for DB2
If there is more than one entry like this, find the latest entry.
3. On UNIX, note the <service> value.
On Windows, note the <port> value.
4. Log on as the DB2 instance owner to the system where the Tivoli License
Manager server is installed.
5. Load the DB2 environment. To do this, change to the DB2 home directory, for
example, /home/db2inst1/sqllib, and enter the command:
. ./db2profile
6. Enter commands as follows:
db2 catalog tcpip node <nodeName> remote <host> server <notedValue>
db2 catalog database <databaseName> as <catalogedName> at node <nodeName>
where the values of the variables are as follows:
nodeName
The name used to catalog the node where the server and database are
installed. The name to use depends on the type of database:
Administration
tlmnodea
Runtime
tlmnoder
host
The host name or IP address of the computer where the DB2 server is
installed.
notedValue
The value you found in the services file. This is a port number if the DB2
server is on a Windows computer, and a service name if the DB2 server is
on an UNIX computer.
databaseName
The name of the database: tlma for the administration server database, or
tlmr for a runtime server database.
Running procedures manually
314 IBM Tivoli License Manager: Planning, Installation, and Configuration
catalogedName
The name used to catalog the database: tlmadb for the administration
server database, or tlmrdb for a runtime server database.
You should also consult the DB2 Quick Beginnings guides for more information
about methods of connecting to databases.
Disconnecting a Tivoli License Manager database from its server
If you have verified that after uninstalling a Tivoli License Manager server, the
server is still connected to its database, these are the steps to recover the situation.
The instructions for disconnecting a database from its server are as follows:
1. Log on to the computer where the Tivoli License Manager server was installed
as the DB2 administration user, for example db2inst1.
2. Open a command line window (Windows) or a shell window (UNIX).
3. On UNIX, if the DB2 command line is not initialized, you must load the DB2
environment. To do this, change to directory /home/db2inst1/sqllib and enter
the command:
. ./db2profile
4. Uncatalog the database, using the commands:
Administration
db2 uncatalog database tlmadb
Runtime
db2 uncatalog database tlmrdb
5. Uncatalog the node, using the command:
Administration
db2 uncatalog node tlmnodea
Runtime
db2 uncatalog node tlmnoder
Running procedures manually
Appendix H. Running elements of the install or uninstall procedures manually 315
Running procedures manually
316 IBM Tivoli License Manager: Planning, Installation, and Configuration
Appendix I. Prerequisites
This appendix provides information about the operating system, software,
hardware, and space requirements for the installation of the Tivoli License
Manager components. The details provided here are correct at time of production
of this manual. However, for more the latest information about the supported
platforms and their version and fix pack levels that are required for a Tivoli
License Manager component, see the IBM Tivoli License Manager: Release Notes. This
document is obtained as described in “Accessing publications online” on page xvi.
Supported platforms
For the most recent information about platforms, consult the supported platforms
matrix on the IBM software support Web site http://www.ibm.com/support.
When you reach the Web site, select a Tivoli product’s support page. When the
page displays, click on the Supported Platforms link. Click the Tivoli Platform
and Database Support Matrix link. You will be asked for your IBM registration ID
and password.
The supported platforms for servers, databases, and agents at the time of going to
press, can be found at the following links:
Servers
“Supported platforms for servers” on page 13
Databases
“Supported platforms for databases” on page 13
Agents
“Supported platforms for agents” on page 14
Catalog manager
“Supported platforms for the catalog manager” on page 15
Supported browsers
“Web user interface prerequisites” on page 41
Other prerequisites
All prerequisite information is presented separately, in the planning chapter, for
each component and sub-component. The following is a list of links to each of
those sections. If you want to look at all of the prerequisites, follow each of these
links in turn. At the end of each section there is a link to return you to this page.
The list as follows:
v “Prerequisites for administration and runtime servers” on page 25
v “Prerequisites for databases” on page 29
The server and database components have some specific software prerequisites.
The following advice is available with respect to these:
– “Obtaining and installing the prerequisite software” on page 31
– “Auto-installation of prerequisite software” on page 32v “Additional prerequisites for installing servers and databases using Tivoli
Configuration Manager” on page 36
v “Web user interface prerequisites” on page 41
© Copyright IBM Corp. 2002, 2004 317
v “Agent prerequisites” on page 42
v “Web deployment prerequisites” on page 46
v “Installagent prerequisites” on page 48
v “Prerequisites for agent deployment using Tivoli Configuration Manager” on
page 48
v “Prerequisites for agent deployment on RSH and SSH UNIX networks” on page
50
v “Prerequisites for agent deployment using Windows logon scripts” on page 52
v “Prerequisites for deploying the OS/400 agent from a Windows node” on page
53
v “Prerequisites for deploying the OS/400 agent directly on the OS/400 node” on
page 54
v “Catalog manager prerequisites” on page 55
v “Additional prerequisites for installing the catalog manager using Tivoli
Configuration Manager” on page 57
v “Data Warehouse prerequisites” on page 58
Other prerequisites
318 IBM Tivoli License Manager: Planning, Installation, and Configuration
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user’s responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-178, U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Some states do not allow disclaimer of express or implied warranties in certain
transactions, therefore, this statement might not apply to you.
This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
© Copyright IBM Corp. 2002, 2004 319
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.
Such information may be available, subject to appropriate terms and conditions,
including in some cases, payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled
environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurement may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of
those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
Trademarks
The following terms are trademarks of the IBM Corporation in the United States or
other countries or both:
IBM
The IBM logo
AIX
DB2
DB2 Universal Database
Domino
eServer
i5/OS
iSeries
320 IBM Tivoli License Manager: Planning, Installation, and Configuration
Lotus
OS/400
Passport Advantage
pSeries
Rational
Redbooks
RS/6000
S/390
SecureWay
Tivoli
WebSphere
z/OS
zSeries
Intel, the Intel Inside logos, MMX, and Pentium are trademarks of Intel
Corporation in the United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or
registered trademarks of Sun Microsystems, Inc. in the U.S., and other
countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or
both.
Microsoft, Windows, and the Windows logo are registered trademarks, of Microsoft
Corporation in the U.S. and other countries.
SSLRef 1.0 is a trademark of Netscape Communications Corporation.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Other company, product, and service names may be trademarks or service marks
of others.
Notices 321
322 IBM Tivoli License Manager: Planning, Installation, and Configuration
Glossary
A
account. See administration account.
administrator. A role that can be assigned to a user of
the administration server Web UI. A user who is
assigned this role is able to perform all Web UI tasks
with the exception of Manage Organizations and
Manage Access.
administration server. A component that performs the
following tasks:
v Maintains a database of product, license,
organization, application user, and infrastructure
information
v Provides a Web interface where administrators can
define and update the infrastructure and license rules
for their organizations and produce historical reports
administration server database. A DB2 database
associated with the administration server. This database
stores the information about organizations, monitoring
infrastructure, and license entitlement that are defined
on the administration server as well as the historic
inventory and software usage information that is used
in the historical reports available on the administration
server Web interface.
administration account. The record of a user of the
Web UI that is stored in the database. An
administration account defines the identification details
of the user. Each account must have at least one profile,
which defines the role and privacy policy of the user
when working with a specific organization.
agent. A component that is deployed from a runtime
server to an organization node that is to be monitored.
An agent performs the following functions on the
monitored node:
v Performs regular inventory scans and forwards the
results to the runtime server
v Identifies the starting or stopping of monitored
applications and communicates to the runtime server
so that a license can be assigned or released
application user. A user who can start applications on
monitored nodes. Details of application users are
maintained to allow license pools to be restricted to
specified users.
D
division. An administrative unit of Tivoli License
Manager. Divisions are used to group agents so that
they can be selected as a group, for example when
scheduling inventory scans or specifying target
distribution rules.
distribution quota. A part of the total license quantity
that is distributed to specified targets or users.
E
event. An occurrence that causes a notification to be
generated. Events can relate to license management, for
example a usage threshold is reached, or to the
functioning of Tivoli License Manager, for example, an
agent is not responding.
H
hard stop. A property of a license pool that specifies
whether the number of licenses available in the pool is
an absolute maximum. If the property is set to Yes, it is
an absolute maximum, which means that when all
licenses are in use, no further instances of the
application can be opened. If the property is set to No,
it means that the number of licenses available can be
exceeded.
high-water mark. The maximum concurrent license
usage for a product since the high-water mark was last
reset. Depending on the context, this can refer to usage
within a specific license pool or to usage for all license
pools of the same capacity type.
I
installed software scan. An operation performed by
agents to discover all the software applications installed
on monitored nodes. installed software scans can be
scheduled to repeat at regular, defined intervals.
instrumented product. A product that relies on APIs,
embedded in its code, to communicate license requests
and license releases to the agent.
L
license administrator. A role that can be assigned to a
user of the administration server Web UI. A license
administrator is able to assign licenses to products,
distribute licenses to targets and users, define the
monitoring settings of products, and produce reports.
license and procurement manager. A role that can be
assigned to a user of the administration server Web UI.
A license and procurement manager is able to use the
© Copyright IBM Corp. 2002, 2004 323
tasks in the Manage Procurement task group, assign
licenses to products, distribute licenses to targets and
users, define the monitoring settings of products, and
produce reports.
M
procurement manager. A role that can be assigned to
a user of the administration server Web UI. A
procurement manager is able to use the tasks in the
Manage Procurement task group and produce reports.
master catalog. The central repository of product
information about all software components and related
files for products that can be monitored.
metering. A process by which software usage is
measured and recorded. The data recorded (for
example, number of sessions, number of concurrent
sessions, duration of sessions, capacity used, node ID,
user ID) may be used by licensees to assess license
requirements, or by software vendors to verify
compliance or to make billing calculations.
module. An entity, such as a file or a registry entry,
that is defined in the catalog and linked to a product to
enable the agent to identify the products that are
installed or in use on monitored nodes.
multi-instance. A property of a license that
determines whether multiple sessions of an application
can be opened using a single license. Multi-instance
licenses can apply to multiple sessions for the same
user, for users in the same user group, or for sessions
on the same node.
N
node. A computer in the network that can be
monitored by Tivoli License Manager when an agent is
deployed on it.
notification. An e-mail sent to a designated
administrator in response to a license management or
internal event.
O
organization. An organization whose license
management is controlled by Tivoli License Manager.
Each organization is the owner of a set of the Tivoli
License Manager components, including runtime
servers, divisions, agents, and application users.
P
privacy policy. A group of settings that is part of the
profile of a user of the administration or runtime server
Web UI. The privacy policy determines whether details
of the computers and users to which software use and
installed software information relate should be included
in reports produced by the user.
procurement manager. A role that can be assigned to
a user of the administration server Web UI. A
procurement manager is able to use the tasks in the
Manage Procurement task group and produce reports.
product entitlement settings. A definition that
determines whether or not the use of a product should
be monitored and the level of license compliance
checking that should be applied.
profile. settings associated with an administration
account which determine the role and privacy settings
to be applied to a user of the Web UI of the
administration or runtime server. Because the
administration server can manage multiple
organization, each account can have multiple profiles,
each one defining settings related to a different
organization.
R
role. A part of the profile of a user of the
administration server Web UI. The role determines
tasks that the user is able to perform on the interface.
Available roles are Administrator, Procurement
Manager, Software Resources Manager, License
Administrator, System Resources Manager, and
Procurement and Licensing Manager.
runtime server. A component that performs the
following functions:
v Assigns and releases licenses according to the rules
defined in the license pools when it receives a
request from the agent
v Compiles inventory information about monitored
nodes that it receives from its agents and forwards
the information to the administration server
v Generates and sends notifications in response to
events that occur on the server itself or any of its
agents
v Provides Web interfaces for the deployment of agents
and the production of real-time reports
S
signature. A file, registry entry, or other identifier that
enables Tivoli License Manager to identify products
that are installed or in use on monitored nodes.
stale license. A license that is not in use, but was in
use when the using workstation went down or the
network failed. Such licenses are cleaned up when a
license is newly requested and none is available.
procurement manager • stale license
324 IBM Tivoli License Manager: Planning, Installation, and Configuration
software recognition signature. Module defined in the
catalog and linked to a product that enables the agent
to identify a product that is installed on a monitored
node.
software resources manager. A role that can be
assigned to a user of the administration server Web UI.
A software resources manager is able to produce
reports.
system resources manager. A role that can be
assigned to a user of the administration server Web UI.
A system resources manager is create and manage the
monitoring infrastructure of servers, agents, divisions,
nodes, and application users, using tasks in the Manage
Resources and Manage Components task groups.
T
target. Any part of a license management
infrastructure that can have exclusive use of a license
pool. A target can be a division, a node, or an agent,
depending on how the target distribution rules for the
license pool are defined.
target distribution parameters. Rules associated with
a license that limit the availability of the license pool to
selected targets. The targets can be divisions, nodes, or
agents depending on the target type property of the
license pool.
target type. The property of a license pool that
specifies where the license pool is available in the
organization’s environment. The target type for a
license pool is set to one of the following values:
v Enterprise
v Division
v Node
v Agent
An enterprise license pool is available throughout the
organization. For division, node, and agent license
pools, the administrator defines the target distribution
parameters to determine the availability of the license
pool in those locations.
threshold. A percentage of the licenses available in a
license pool; if more than this percentage of licenses for
a product is in use, notifications about the level of use
are generated.
U
unit type. The property of a license pool that specifies
how to determine the number of required licenses for
an application. Depending on the unit type selected for
the pool, the number of licenses required can be based
on the number of users requesting a license or can
depend on the size of the memory, number of
processors, or number of hard disks on the node where
the application is started.
unknown module. A module that is detected by the
software use monitoring function of the agent for
which no corresponding entry was found in the
catalog.
user. See application user.
use monitoring signature. Module defined in the
catalog and linked to a product that enables the agent
to identify a product that is in use on a monitored
node.
user distribution parameters. Rules associated with a
license that limit the availability of the license pool to
selected application users. The default setting is to
allow all users of applications to access the license pool.
X
XSLM ID. An identifier that an IBM instrumented
product passes to an API when requesting, checking, or
releasing licenses. An XSLM ID uniquely identifies a
product and is made up of a publisher ID, product ID,
version ID, and feature ID, each of which is a unique
hexadecimal string. XSLM IDs are used only for use
monitoring.
software recognition signature • XSLM ID
Glossary 325
326 IBM Tivoli License Manager: Planning, Installation, and Configuration
Index
Special characters/etc/services file 314
%HOST variablein automatic computer label assignment 134
in installagent deployment 148
in OS/400 node silent install 185
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent deployment 158
in Web deployment 143
in Windows logon script agent deployment 174
%MODEL variablein automatic computer label assignment 134
in installagent deployment 147
in OS/400 node silent install 184
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent deployment 157
in Web deployment 143
in Windows logon script agent deployment 174
%SERIAL variablein automatic computer label assignment 134
in installagent deployment 147
in OS/400 node silent install 184
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent deployment 157
in Web deployment 143
in Windows logon script agent deployment 174
%TYPE variablein automatic computer label assignment 134
in installagent deployment 147
in OS/400 node silent install 184
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent deployment 157
in Web deployment 143
in Windows logon script agent deployment 174
%VENDOR variablein automatic computer label assignment 134
in installagent deployment 148
in OS/400 node silent install 185
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent deployment 158
in Web deployment 143
in Windows logon script agent deployment 174
Numerics2000
supported Windows agent platforms 14
supported Windows server platforms 13
2003supported Windows agent platforms 14
supported Windows server platforms 13
500 error, http 118
Aaccessibility xvii
accountsassign to organizations 96
create 96, 98
activateProductsEnabled parameter 239
active processorsparameter, all components installation 91
Active processorsagent parameter
RSH/SSH UNIX agent deployment 168
adminBaseTime parameter 237, 301
adminBaseTime, configuration parameter, synchronizing server
times 236
adminBaseTime, configuration parameter, used for event
timing 235
adminDownloadPeriod parameter 240
administration accountsSee accounts
administration databasesupported platforms 13
administration serveradd SSL server certificate 114
all components installation 77
base configuration parameters panel 90
backupconf command 247
CD 22
change SSL password 111
checklist 254
commands 246
components checklist 254
configuration filesdefault settings 234
location 233
ranges 234
configuration planning 37
configure 95
configure Java 2 Security 135
configure proxy server 131
configure settings 95
configure SSLfor communications from Web browsers 102
for communications with runtime server 99
create SSL server certificate 113
create SSL server certificate as a Certificate Authority 114
custom installation 77
administration server database panel 87
base configuration parameters panel 84
runtime server communication password panel 87
customizing error 500 file 119
database addressparameter, custom installation 88
database instance ownerparameter, custom installation 88
database port numberparameter, custom installation 88
dropping the database when uninstalling 205
enabling for SSL 20
enabling graphics on UNIX 311
error 500 file, customizing 119
functionality summary 2
in Tivoli License Manager structure 2
install planning 23
install using Tivoli Configuration Managerplatforms supported 36
software 36
© Copyright IBM Corp. 2002, 2004 327
administration server (continued)installation using Tivoli Configuration Manager
software package block parameters 280
installing 66
login 96
options file for silent installations 267
options file for silent uninstallations 285
packaging 22
plan to configure 37
planning 10
for SSL 17
planning to install 23
portparameter (default), all components installation 91
parameter (default), typical runtime installation 84
prerequisites 25
space 28
request SSL server certificate 112
restoreconf command 250
silent installation options file 267
silent uninstallation options file 285
space prerequisites 28
SSL configurationfor receiving secure communications from runtime
server 101
for sending secure communications to runtime
server 100
to enable secure communications from agents 104
to receive secure communications from Web
browser 103
starting 295
stopping 295
summary of functionality 2
supported platforms 13
synchronizing server times 236
system.properties file settings 237
timing of events and services 235
typical administration installationbase configuration parameters panel 83
typical installation 76
uninstall 203
UNIXconfigure to run under a non-root user 134
URL, changing 95
using HTTP from browsers, to access 116
using HTTPS from browsers, to access 115
administration server addressparameter, custom installation 86
parameter, typical runtime installation 83
administration server databaseall components installation 77
base configuration parameters panel 90
CD 22
connecting database to its server on Windows 314
creating on Windows 313
custom installation 77
base configuration parameters panel 84
runtime server communication password panel 87
disconnecting database fromits server on Windows 315
install planning 23
install using Tivoli Configuration Managerplatforms supported 36
software 36
installation using Tivoli Configuration Managersoftware package block parameters 280
installing 66
options file for silent installations 267
administration server database (continued)options file for silent uninstallations 285
packaging 22
panel 87
planning to install 23
prerequisites 29
silent installation options file 267
silent uninstallation options file 285
typical administration installationbase configuration parameters panel 83
typical installation 76
uninstall 203
Administratorpassword, changing 298
required for catalog manager uninstall on Windows 211
required for uninstall on Windows 203
administrator password, DB2parameter 81
for catalog manager 195
administrator password, WebSphere Application Serverparameter 82
Administrator rightsrequired for installation on Windows 73, 175, 191
administrator user, DB2parameter 80
for catalog manager 195
administrator user, WebSphere Application Serverparameter 81
administratorsas notification recipients 117
adminServerDbAddress parametercatalog manager 198
adminServerDbPort parametercatalog manager 199
adminUploadPeriod parameter 240
agentaccess to runtime servers 4, 242
all components installation 77
alternative runtime serversplanning for SSL 22
automatic computer label assignment 132
automatic upgrade 231
checklist 263
commands 227
configuration filesdefault settings 234
ranges 234
configure SSLfor communications with runtime server 104
configure to use proxy at runtime server 131
deleting 231
deployment 139
installagent 145
installagent, using correct SSL certificate 106
on OS/400 nodes 175
on OS/400 nodes directly 182
on OS/400 nodes using a Windows wizard 175
on OS/400 nodes using Save and Restore
Programs 183
on OS/400, platforms supported 53, 54
on OS/400, prerequisites 53
on OS/400, software required 53, 54
on OS/400, using correct SSL certificate 106
on UNIX nodes using SSH/RSH 162
on UNIX using SSH/RSH, using correct SSL
certificate 106
on Windows nodes using SSH/RSH 170
328 IBM Tivoli License Manager: Planning, Installation, and Configuration
agent (continued)deployment (continued)
on Windows using logon script, using correct SSL
certificate 106
overview 139
planning 42
platforms supported for using Tivoli Configuration
Manager for 48
prerequisites for using RSH and SSH in UNIX 50
prerequisites for using the installagent command 48
prerequisites for using Tivoli Configuration Manager
for 48
prerequisites for using Windows logon scripts 52
scheduling 54
Tivoli Configuration Manager 152
Tivoli Configuration Manager, using correct SSL
certificate 106
using SSH and RSH, software required 51
using SSL at startup 106
Web 140
Web, using correct SSL certificate 106
deployment by Tivoli Configuration ManageragentConfig.divisionName parameter 159
agentConfig.nodeTag parameter 160
agentConfig.organizationName parameter 160
agentConfig.proxyAddress parameter 160
agentConfig.proxyPort parameter 160
agentConfig.runtimeAddress parameter 160
agentConfig.runtimePort parameter 160
agentConfig.sslPort parameter 160
agentConfig.startupMode parameter 161
agentConfig.useProxy parameter 161
divisionName parameter 157
nodetag parameter 157
organization parameter 158
port parameter 158
processor_type parameter 159
proxyName parameter 158
proxyPort parameter 158
runtimeAddress parameter 158
setLang.CCSID parameter 161
shared_pool_capacity parameter 159
startupMode parameter 158
system_active_processors parameter 159
target_dir parameter 159
useProxy parameter 159
deployment on UNIX by RSH/SSHActive processors 168
Division parameter 166
Node 167
Organizations parameter 166
OS 167
Password 167
Port 167
Processor Type 168
Runtime address 166
Shared pool capacity 168
SSL port 167
Startup mode 167
deployment wizard import file formats for UNIX 303
display restrictions 236
enabling for SSL 20
files 221
fix 231
functionality on OS/400 219
functionality summary 2, 217
in Tivoli License Manager structure 2
agent (continued)inactive 240, 241
installagent deploymentcertificate parameter 149
division parameter 147
gskit parameter 149
nodeTag parameter 147
organization parameter 148
port parameter 148
processor_type parameter 149
proxyName parameter 148
proxyPort parameter 148
runtime server address parameter 148
scanner parameter 149
secure_port parameter 148
security_level parameter 148
shared_pool_capacity parameter 149
sourcePath parameter 147
system_active_processors parameter 149
uri parameter 148
useProxy parameter 148
language selection 218
maximum number displayed in list box on GUI 236
not installed with typical installation 76
number to assign to a runtime server 10
OS/400 agent deploymentagentid parameter 184
Division name parameter 178
division parameter 184
Node tag parameter 178
Organization name parameter 178
organization parameter 184
Password parameter 176
port parameter 184
proxy parameter 184
Proxy port parameter 180
Proxy server address parameter 180
proxy_port parameter 184
Runtime server address parameter 178
Runtime server port / SSL port parameter 179
secure_port parameter 184
server parameter 184
Startup mode parameter 179
startupMode parameter 184
System parameter 176
tag parameter 184
Use proxy server parameter 179
use_proxy parameter 184
User ID parameter 176
OS/400 agent uninstallationPassword parameter 210
System parameter 210
User ID parameter 210
overview 217
patch 231
planning 9
for SSL 17
planning to collect deployment information 45
platforms supported 14, 15
prerequisites 42
privacy policy 141
redeploy 231
reviewing 231
runtime servers to contact 5
runtime servers, alternative, planning for SSL 22
self-update 231, 243
software package block 154
Index 329
agent (continued)SSL configuration
to send secure communications to runtime server 107
summary of functionality 2, 217
supported platforms 14, 15
system.properties file settings 218, 241
timing of events and services 235
uninstall 208
Web deploymentcomputer label parameter 143
division parameter 143
runtime server name parameter 143
WebSphere Application Servercommands 230
deployment 185
which runtime servers to contact 5
Windows logon script deploymentdivision parameter 173
organization parameter 173
port parameter 174
proxyName parameter 174
proxyPort parameter 174
secure_port parameter 174
security_level parameter 173
server parameter 173
useProxy parameter 174
agent data formats for UNIX agent deployment wizard 303
agent data formats for UNIX agent deployment wizard, Linux
s390 306
agent deployment on OS/400 nodesprerequisites 54
agent fileson AIX 221
on HP/UX 222
on Linux 223
on OS/400 224
on Sun 225
on Windows 226
agent_install.properties fileconfigure automatic computer label assignment 133
configure proxy servers 131
purpose 233
agentConfig.divisionNameagent parameter
Tivoli Configuration Manager 159
agentConfig.nodeTagagent parameter
Tivoli Configuration Manager 160
agentConfig.organizationNameagent parameter
Tivoli Configuration Manager 160
agentConfig.proxyAddressagent parameter
Tivoli Configuration Manager 160
agentConfig.proxyPortagent parameter
Tivoli Configuration Manager 160
agentConfig.runtimeAddressagent parameter
Tivoli Configuration Manager 160
agentConfig.runtimePortagent parameter
Tivoli Configuration Manager 160
agentConfig.sslPortagent parameter
Tivoli Configuration Manager 160
agentConfig.startupModeagent parameter
Tivoli Configuration Manager 161
agentConfig.useProxyagent parameter
Tivoli Configuration Manager 161
agentidagent parameter
OS/400 agent deployment 184
aggregate software us table 238
aggregateUsagePeriod parameter 238
AIXadditional agent commands 228
agent files 221
possible conflict with Web-based System Manager 35
prerequisites for installing bundled DB2 33
prerequisites for installing bundled WebSphere Application
Server 34
processor prerequisitefor servers 27
setup file 66
catalog manager 188
software package blockfor agents 154
for servers and databases 69
supported agent platforms 14
supported platforms for SSH/RSH agent deployment 50
supported server platforms 13
aliases, default port, restoring 116
aliases, SSL port, setting 110
all components installationbase configuration parameters panel 90
servers and databases 77, 89
allrun.htm file xvi
alternative servers 140
applications, starting and stopping 217
authenticationconfigure 121
database 122
LDAP 122
XML 122
authentication methodconfiguration planning 38
plan to configure 38
automatic agent upgrade 231
automatic computer label assignment 132
configuration planning 39
plan to configure 39
automaticTagAssignmentconfiguration parameter 133
Bbackup of server configuration files 247
backupconf command 247
base configuration parameters panelall components installation 90
custom installation 84
typical administration installation 83
typical runtime installation 82
base time settingfor administration server 237
for runtime server 239
booksaccessing online xvi
online xvii
ordering xvii
330 IBM Tivoli License Manager: Planning, Installation, and Configuration
browserfor Web deployment 47
prerequisites 41
bundled DB2 checklist 261
bundled prerequisiteCD 23
DB2let the wizard install 78
prerequisite installation panel 79
prerequisite installation setup file panel 91
DB2 for catalog managerlet the wizard install 194
DB2, for catalog managerprerequisite installation panel 194
prerequisite installation setup file panel 197
WebSphere Application Serverlet the wizard install 79
prerequisite installation panel 81
prerequisite installation setup file panel 92
bundled prerequisitesautomatic install 32
installing from CD 67, 189
prerequisites for installing 33
bundled WebSphere Application Server checklist 262
CcacheUpdatePeriod parameter 240
catalog managercheck language settings 187
checking for DB2 configuration files on UNIX 187
checking PATH variable in Windows if DB2 already
installed 188
checking that DB2 configuration files on UNIX do not
contain a shell call 188
checklist 265
collect installation information 188
configure 198
connection to database panel 195
database addressparameter 196
database instance ownerparameter 196
database port numberparameter 196
date/time of computer, changing 187
ensuring availability of operating system commands for
UNIX 187
functionality summary 8
installationoverview 187
pre-install tasks 187
tasks, pre-install 187
installation planning 55
installation using Tivoli Configuration Managerplatforms supported 57
software package block parameters 288
software required 57
installing 188
interactive installation 191
packaging 23
planning 12
platforms supported 15
prerequisites 55
silent installation 189
silent installation options file 287
silent uninstallation 212
catalog manager (continued)software required 56
summary of functionality 8
time zones, changing 187
uninstallationoverview 211
catalog manager installationusing Tivoli Configuration Manager 288
catalog, IBM, import 134
CDbundled prerequisites 23
catalog manager 23
documentation 23
server and agents 22
servers and agentsspb 23
cert.arm file 105, 106, 113, 114, 165
certificateagent parameter
installagent 149
SSL, serveradd 114
create 113
create as a Certificate Authority 114
request 112
certificate authority, issuing a server certificate as 19, 20
certificate, SSLadding certificate to SSH/RSH deployment 164
adding certificate toOS/400 deployment 180
adding to software package block 155
decryption 17
encryption 17
issuing 18, 20
key database 17
password 17
keystore 17
password 17
obtaining 18, 20
overview 17
self-signed 18, 20
validation 17
certified Linux kernels for agents 43
changeAdminAuth command 122, 123
changeRuntimeAuth command 122, 123
checklists 37, 251
checkPeriod parameter 242
clean up software use table 238
clean up software use tables 237, 301
cleanUsagePeriod parameter 237, 301
CLISee command line interface
cloning, for agent deployment on OS/400planning 54
collect hardware and software at agent 217
command line interfacefor backup and restore configuration commands 246
for DB2 296
on agents 227
commandsadditional on AIX agents 228
additional on HP/UX agents 229
additional on Linux agents 229
additional on OS/400 agents 229
additional on Sun agents 229
backupconf 247
changeAdminAuth 122, 123
changeRuntimeAuth 122, 123
Index 331
commands (continued)CRTLINK 182
dataexp 169, 303
dbpasswd 298
DLTLICPGMOS/400 211
installagent 145, 147
files required 219
platforms supported 48
prerequisites 48
manualDeploy 145, 171
netstat 35
on agents 227
on servers 246
restoreconf 250
RSTLICPGM 183
rtpasswd 298
RUNJVA 183
SAVLICPGM 183
srvstart 295
srvstop 295
sslpasswd 298
tlmagent 227
tlmunins 209
WASAgentClient 230
WebSphere Application Server agentcredentials 230
exit 230
ffdc 230
help 230
reloadconf 230
servers 230
WebSphere Application Server agents 230
common tasks 295
commons-logging.jar file 163
communication password for runtime server 21
communication.properties file 244
configure proxy servers 131
configure runtime server for secure communications 110
purpose 234
communications.properties fileconfigure proxy settings 97
component group selectionservers and databases 76
component selectionservers and databases 75
componentsinstall planning 22
main 2
planning for installation 22
planning to install 23
computer labelagent parameter
Web 143
computer label assignment, automatic 132
configuration planning 39
plan to configure 39
configurationcommunication.properties file 244
files 233
settingsdefaults 234
definition 233
ranges 234
system.properties fileparameter descriptions 235
configuration filesbackup 247
restore 250
configuration files, DB2, check do not contain a shell call 64,
188
configuration files, DB2, checking for on UNIX 63, 187
Configuration ManagerSee Tivoli Configuration Manager
configuration parameters panelall components installation 90
custom installation 84
typical administration installation 83
typical runtime installation 82
configurea server on UNIX to run under a non-root user 134
administration server 95
administration server settings 95
agent settings 97
authentication method 121
database 122
LDAP 122
XML 122
automatic computer label assignment 132
catalog manager 198
event notifications 117
for SSL 19
import IBM catalog 134
Java 2 Security 135
mail notifications 117
notifications 117
organization-related tasks 96
overview 95
planning for 37
proxy server 131
runtime server settings 97
runtime servers 97
SSLSee SSL, configure
tuning your environment 136
URL of administration server, changing 95
URL of runtime server, changing 97
Web interface 95
Web server customization 118
connecting DB2 database from its server 314
connectivity planning 15
conventions, typeface xxi
copy agent’s trace and message files to ffdc command 227
CPU prerequisitesfor catalog manager 56
for databases 29
for servers 27
creating DB2 database 313
credentials, WebSphere Application Server agent
command 230
CRTLINK command 182
custominstallation type
OS/400 agent 177
custom component selectionservers and databases 77
custom installationadministration server database panel 87
base configuration parameters panel 84
runtime server communication password panel 87
runtime server database panel 88
servers and databases 77, 84
332 IBM Tivoli License Manager: Planning, Installation, and Configuration
customer supportsee Software Support xvii
Ddata warehouse enablement pack
prerequisites 58
Data Warehouse Enablement Pack 8
databaseconnecting database to its server 314
creating 313
disconnecting database from its server 315
planning 11
user authentication method 122
database addressparameter
catalog manager installation 196
parameter, custom installation 88, 89
database clientprerequisite software for catalog manager 56
prerequisite software for server components 25
database driverprerequisite software for catalog manager 56
prerequisite software for databases 29
prerequisite software for server components 25
database instance ownerparameter
catalog manager installation 196
parameter, custom installation 88, 89
database port numberparameter
catalog manager installation 196
parameter, custom installation 88, 89
database serverprerequisite software for catalog manager 56
prerequisite software for databases 29
databaseAlias parametercatalog manager 199
databasesCD 22
dropping during uninstallation 205
dropping manually during uninstallation 207
install using Tivoli Configuration Managerplatforms supported 36
software 36
installationpre-install tasks 63
planning 11
supported platforms 13
uncatalog manually during uninstallation 207
dataexp command 169, 303
date/time, of computer, changing 63
catalog manager 187
DB2administration password 34
administrator passwordparameter 81
administrator password for catalog managerparameter 195
Administrator password, to set up HTTP Server as
service 34
Administrator password, to set up WebSphere Application
Server as service 34
administrator userparameter 80
administrator user for catalog managerparameter 195
DB2 (continued)as prerequisite for catalog manger 56
as prerequisite for databases 29
as prerequisite for servers 25
auto-installing 32
CD 23
checking for configuration files on UNIX 63, 187
checking for prerequisite existence 78
catalog manager 193
checking PATH variable in Windows if already
installed 64, 188
checking that configuration files on UNIX do not contain a
shell call 64, 188
command line 296
connecting database to its server 314
creating database 313
disconnecting database from its server 315
fix pack level 25, 29, 56
install pathparameter 80
install path for catalog managerparameter 195
installing (planning) 31
installing automatically 32
instance ownerparameter 80
instance owner for catalog managerparameter 195
instance owner’s passwordparameter 81
instance owner’s password for catalog managerparameter 195
instance owner’s pathparameter 80
instance owner’s path for catalog managerparameter 195
locate prerequisite version panel 78
catalog manager 193
obtaining 31
password, administration 34
port numberparameter 80
prerequisite installation panel 79
catalog manager 194
prerequisite installation setup file panel 91
catalog manager 197
prerequisites for installing bundled version 33
version 25, 29, 56
DB2 administrationpassword, changing 298
DB2 databasepassword 272, 282
planning 11
dbpasswd command 298
dbrootinstall.bat script 313
dbrootinstall.sh script 313
decryptionSSL certificate 17
default values in configuration files 234
deleteagents 231
deploy agentsSee agent, deployment
determining topologyadministration servers 10
agents 9
catalog manager 12
Index 333
determining topology (continued)components 10
databases 11
divisions 9
hostnames 12
IP address 12
organization 9
organizational 9
runtime servers 10
SSL 11, 16
summary 9
test environment 10
time zones 12
directory names, notation xxi
disaster recoveryplan for 40
disconnecting DB2 database from its server 315
displayagents 231
display agent version 228
display prerequisitesfor servers 28
DISPLAY variable 311
divisionagent parameter
installagent 147
OS/400 agent deployment 184
RSH/SSH UNIX agent deployment 166
Web 143
Windows logon script deployment 173
create 96
created by the installation 96
in Tivoli License Manager structure 4
Name, agent parameterTivoli Configuration Manager 157
planning 4, 9
SSL enablement for agents 104
Division nameagent parameter
OS/400 agent deployment 178
DLTLICPGM commandOS/400 211
documentation, CD 23
DOMAINSERVER variable 172
downloadCatalogPeriod parameter 242
downloadParametersPeriod parameter 242
downloadTopologyPeriod parameter 242
dropping the databases during uninstallation 205
dropping the databases manually during uninstallation 207
Eeducation
see Tivoli technical training xvii
enableSSL 98
enablement pack (data warehouse)prerequisites 58
Enablement Pack, Tivoli Data Warehouse 8
enableSSL parameter 244, 245
enabling for SSL 20
encryptiondisabling 109
SSL certificate 17
summary 3
with Tivoli Configuration Manager 70, 191
entitlement settings for DB2 139
entitlement settings for WebSphere Application Server 139
entitlements, for licenses, setup 97
environment variableLANG 218
environment variables, notation xxi
error 500, http 118
event notification settingsconfiguration planning 38
plan to configure 38
event notificationsrecipients 117
server settings 117
system.properties file settings 243
eventstiming 235
synchronizing server times 236
exit, WebSphere Application Server agent command 230
Fffdc, command to copy agent’s trace and message files to 227
ffdc, WebSphere Application Server agent command 230
fileallpubs.htm xvi
log.properties 234
system.properties 117
files/etc/services 314
agent 221
agent_install.properties 233
configure automatic computer label assignment 133
configure proxy servers 131
cert.arm 105, 106, 113, 114, 165
commons-logging.jar 163
communication.properties 234, 244
configure proxy servers 131
configure runtime server for secure
communications 110
communications.propertiesconfigure proxy settings 97
configuration 233
httpd.confcustomizing for error 500 120
disabling encryption 109
disabling SSL for Web server 116
enabling SSL for Web server 107
ITLM21LICENSE.txt 67, 190
itlm500.html 118
ITLMTopology.xsd 303
j2ssh-common.jar 163
j2ssh-core.jar 163
reboot_needed.txt 162
recordFile_Install.txtcatalog manager 287
for installing catalog manager silently 189
for installing servers and databases silently 67
for installing servers and databases silently with
multiple passes 70
for OS/400 agents 181, 182
OS/400 agent 290
servers and databases 267
recordFile_Uninstall.txtfor uninstalling servers and databases silently 204
servers and databases 285
setupAgentOS400.exe 175
for OS/400 agents 181
setupAgentOS400.jar 182
334 IBM Tivoli License Manager: Planning, Installation, and Configuration
files (continued)setupCatMan.bin 188
setupCatMan.exe 189
setupServers.bin 66
setupServers.exe 66
stderr.txt, configure Java 2 Security 136
stdout.txt, configure Java 2 Security 136
system.properties 231
agent settings 218
configure for Web browsers to use secure
communications only for passwords 103
configure runtime server and agent settings 97
configure Web interface and administration server
settings 95
parameter descriptions 235
software use tables cleanup 301
tlm.bat 172
tlmagent.ini 183
uninstaller.bin 203
catalog manager 211
uninstaller.exe 203
catalog manager 211
was.policy.50x, configure Java 2 Security 135
was.policy.51x, configure Java 2 Security 135
was.policy.old, configure Java 2 Security 135
find command, ensure available in UNIX 63
fix agent 231
Fix packsfor supported agent platforms 14, 15
for supported server platforms 13
fixes, obtaining xx
for IBM software, product version 1
functionalityadministration server 2
agent 2
runtime server 2
Ggrep command, ensure available in UNIX 63
groupsdefining privacy policy 241
GSKFilesLocked variable 162
gskitagent parameter
installagent 149
GSKitas prerequisite for agent 42
in use when agent deployed remotely 162
Hhardware data, collected at agent 217
help, WebSphere Application Server agent command 230
hostdefining privacy policy 241
host servers option, for OS/400 agent deployment 53, 54
hostnameplanning 12
using 63
HPprocessor prerequisite 27
HP/UXadditional agent commands 229
agent files 222
prerequisites for installing bundled DB2 33
HP/UX (continued)prerequisites for installing bundled WebSphere Application
Server 34
setup file 66
catalog manager 189
software package blockfor agents 154
for servers and databases 69
supported agent platforms 14
supported platforms for SSH/RSH agent deployment 50
supported server platforms 13
HTTP 116
HTTP ServerSee also Web server
as prerequisite 26
install pathparameter 81
HTTP Server, possible port conflict 35
httpd.conf filecustomizing for error 500 120
disabling encryption 109
disabling SSL for Web server 116
enabling SSL for Web server 107
HTTPS 115
Ii5/OS
supported agent platforms 14
IBM catalogimport planning 40
plan to import 40
IBM catalog, import 134
IBM HTTP ServerSee also Web server
as prerequisite 26
starting 296
stopping 296
IBM software, product version 1
IBM WebSphere Application ServerSee also WebSphere Application Server
as prerequisite 26
IKEYMANadd SSL server certificate 114
change SSL password 111
create SSL server certificate 113
create SSL server certificate as a Certificate Authority 114
request SSL server certificate 112
implementation scenario 5
import file formats for UNIX agent deployment wizard 303
import IBM catalog 134
inactive agent 240, 241
information centers, searching to find software problem
resolution xix
information collection 37
install 64, 188
installadministration components 66
agentSee agent, deployment
agentsspb on CD 23
all componentsservers and databases 89
automatic, of prerequisites 32
catalog managerconnection to database panel 195
Index 335
install (continued)catalog manager (continued)
overview 187
pre-install tasks 187
procedure 188
spb on CD 23
tasks, pre-install 187
collect information 64, 188
component group selectionservers and databases 76
component selectionservers and databases 75
customservers and databases 84
custom component selectionservers and databases 77
databasesplanning 23
failures of wizard 94
interactivecatalog manager 191
servers and databases 70
language selection 74
catalog manager 192
locationcatalog manager 193
servers and databases 74
method 66
catalog manager 189
multiple passes 70
overview 61
parameters checklist 251
planning 22
pre-install tasks 63
problem determination 94
remotely 69
catalog manager 191
repeat 70
runtime components 66
scenario 61
servers 66
planning 23
spb on CD 23
silentcatalog manager 287
OS/400 agent 290
servers and databases 267
tasks, pre-install 63
typetypical 76
type, planning 24
typical administrationservers and databases 83
typical runtimeservers and databases 82
wizard failures 94
install agent as a Windows service command 228
install path, DB2parameter 80
catalog manager 195
install path, HTTP Serverparameter 81
install path, WebSphere Application Serverparameter 81
installagentcommand 147
installagent agent deploymentplanning 47
procedure 145
using correct SSL certificate 106
installagent commandfiles required 219
platforms supported 48
prerequisites 48
space 48
installationusing Tivoli Configuration Manager 280, 288
installing in more than one passplanning 59
InstallShield options filecatalog manager 287
OS/400 agent 290
servers and databases 267
uninstall 285
instance owner, DB2parameter 80
for catalog manager 195
instance owner’s password, DB2parameter 81
for catalog manager 195
instance owner’s path, DB2parameter 80
catalog manager 195
Intelsupported agent platforms 14
supported server platforms 13
Intel x86certified kernels 43
Linux forprocessor prerequisite for servers 27
interactive installationcatalog manager 191
servers and databases 70
interactive wizardfor installing catalog manager 55, 189
for installing servers and databases 24, 66
for multiple pass installations of servers and databases 70
for OS/400 agents 175
for uninstalling catalog manager 211
for uninstalling servers and databases 203, 206
Internet browseras prerequisite 41
Internet Exploreras prerequisite 41
for Web deployment 47
Internet, searching to find software problem resolution xix,
xx
inventory scanupload time, maximum 59
inventory scan command 228
inventory scansschedule 97
scheduling 58
inventoryUpdatePeriod parameter 240
IP addressplanning 12
using 63
iSeriesagent deployment
See OS/400, agent deployment
certified kernels 43
supported agent platforms 15
supported server platforms 13
336 IBM Tivoli License Manager: Planning, Installation, and Configuration
iSeries nodesagent deployment prerequisites 54
issuing an SSL server certificate 18, 20
ITLM21LICENSE.txt file 67, 190
itlm500.html file, customizing 118
ITLMTopology.xsd file, for data formats for UNIX agent
deployment wizard 303
Jj2ssh-common.jar file 163
j2ssh-core.jar file 163
J2SSH-Lite 51
obtaining 163
Java 2 Securityenablement planning 40
plan to enable 40
Java 2 Security, configure 135
Java Runtime EnvironmentSee JRE
Java Virtual MachineSee JVM
java.naming.provider.url parameter 128
JDBCas prerequisite for catalog manager 56
as prerequisite for databases 29
JDKprerequisite software for OS/400 agent deployment 53, 54
JREnot installed on Web deployment 144
prerequisite software for catalog manager 56
prerequisite software for OS/400 agent deployment 53
prerequisite software for server components 26
prerequisite software for Web deployment 47
JVMprerequisite software for catalog manager 56
prerequisite software for OS/400 agent deployment 53
prerequisite software for server components 26
prerequisite software for Web deployment 47
Kkernels, certified Linux, for agents 43
key.jks database 114
key.jks Java keystore 111
key.kdb database 111, 112, 113, 114
key.sth password stash file 111
knowledge bases, searching to find software problem
resolution xix
korn shellas prerequisite software for catalog manager 56
as prerequisite software for databases 29
as prerequisite software for server components 26
used for installing server and database components 67
LLANG environment variable 218
language selectionagent 218
catalog manager 192
installation 74
catalog manager 192
servers and databases 73
language settingscheck 63
language settings (continued)catalog manager 187
language support for OS/400 agents 44
LC_ALL environment variable 218
LC_MESSAGES environment variable 218
LDAPuser authentication method 122
licenserelease 240, 242
license agreementpanel 74
catalog manager 193
text version for silent installs 67, 190
license entitlements, setup 97
licenseCleanUpPeriod parameter 240
licenses, assigning and releasing 217
Linux390
agent installation parameters, in deployment on UNIX
by RSH/SSH 168
agent installation parameters, in installagent 149
agent installation parameters, in Tivoli Configuration
Manager 159
agent parameters in all components installation 90
setup file 66
setup file, catalog manager 189
software package block for agents 154
software package block for servers and databases 69
additional agent commands 229
agent files 223
certified kernels for agents 43
on Intel x86processor prerequisite for servers 27
on pSeriesprocessor prerequisite for servers 27
on zSeriesprocessor prerequisite for servers 27
PPCsetup file 66
setup file, catalog manager 189
software package block for agents 154
software package block for servers and databases 69
setup file 66
catalog manager 189
software package blockfor agents 154
for servers and databases 69
Linux 390See Linux
Linux PPCSee Linux
location, installcatalog manager 193
servers and databases 74
LOG_SHARE variable 172
log.properties file 234
loginauthentication method 122
to administration server 96
to runtime server 98
logon scriptsfor agent deployment on Windows 170
Windows platforms supported for agent deployment 52
Windows, for agent deploymentprerequisites 52
Windows, for agent deployment, space required 52
Index 337
logon scripts in Windowsdeployment of agent
planning 51
Mmail notification
recipients 117
mail settingsin system.properties file 117
mailRecipientconfiguration parameter 118
mailRecipient parameter 243
mailSenderconfiguration parameter 118
mailSender parameter 243
main components 2
managingprivacy policy 219
manualDeploy command 171
manualDeploy script 145
manually running procedures 313
manualsaccessing online xvi
online xvii
ordering xvii
maxAgentInactivity parameter 241
maxAggregateUsageAge parameter 238
maxSelectionListLength parameter 236
maxServerInactivity parameter 239
maxUsageAge parameter 238, 301
memory prerequisitesfor catalog manager 57
for databases 29
for servers 27
methods of installingcatalog manager 189
servers and databases 66
Microsoft Internet Exploreras prerequisite 41
for Web deployment 47
migratingto version 2.1 201
minimum password length for Web UI 237
minimumPasswordLength parameter 237
Mozillaas prerequisite 41
for Web deployment 47
multi-catalog configuration of catalog manager 198
Nnational language selection
agent 218
catalog manager 192
servers and databases 73
navigating the installation panels 70
NETLOGON shared directory 171
NETLOGON_SHARE variable 172
netstat command 35
network performance considerations 239
Network Time Protocol 63
nodedefining privacy policy 241
Nodeagent parameter
RSH/SSH UNIX agent deployment 167
Node tagagent parameter
OS/400 agent deployment 178
node_<platform>configuration parameter 133
nodeAlias parametercatalog manager 198, 199
nodetagagent parameter
Tivoli Configuration Manager 157
nodeTagagent parameter
installagent 147
notationenvironment variables xxi
path names xxi
typeface xxi
notificationrecipients 117
server settings 117
system.properties file settings 243
notification settingsconfiguration planning 38
plan to configure 38
Oobtaining an SSL server certificate 18, 20
offlineUsagePeriod parameter 242
online publications, accessing xvi
operating system data, collected at agent 217
options file for silent installationcatalog manager 287
OS/400 agent 290
servers and databases 267
options file for silent uninstallationservers and databases 285
ordering publications xvii
organizationagent parameter
installagent 148
OS/400 agent deployment 184
RSH/SSH UNIX agent deployment 166
Tivoli Configuration Manager 158
Windows logon script deployment 173
configuration tasks planning 37
configure related tasks 96
create 96
created by the installation 96
in Tivoli License Manager Structure 4
parameter, all components installation 90
parameter, custom installation 86
parameter, typical runtime installation 83
plan related configuration tasks 37
planning 4, 9
select 96
SSL enablement for agents 104
Organization nameagent parameter
OS/400 agent deployment 178
organizationName parameter 245
OSagent parameter
RSH/SSH UNIX agent deployment 167
338 IBM Tivoli License Manager: Planning, Installation, and Configuration
OS/400additional agent commands 229
agent deploymentlogin 176
prerequisites 53
procedure 175
procedure (direct) 182
procedure (using Save and Restore Programs) 183
procedure from a Windows node 175
using correct SSL certificate 106
using silent installation options file 290
variables for Tivoli Configuration Manager 159
agent files 224
agent functionality 219
agents, uninstalling 209
deployment of agentplanning 52
language support for agents 44
platforms not supported for installagent command 48
platforms not supported for Web deployment 46
platforms supported for agent deployment 54
running agent commands 228
software package blockfor agents 154
software required for agent deployment 54
space requiredfor agent deployment 53, 54
supported agent platforms 14
uninstalling agents 209
Windows platforms supported for agent deployment 53
Windows software required for agent deployment 53
wizardfor agent deployment 182
OS/400 nodesagent deployment prerequisites 54
PPA-Risc
supported HP/UX agent platforms 14
supported HP/UX server platforms 13
packaging 22
panels, for the installation, navigating 70
parameteractivateProductsEnabled 239
Active processorsRSH/SSH UNIX agent deployment 168
adminBaseTime 237, 301
adminDownloadPeriod 240
adminServerDbAddresscatalog manager 198
adminServerDbPortcatalog manager 199
adminUploadPeriod 240
agentConfig.divisionNameTivoli Configuration Manager agent deployment 159
agentConfig.nodeTagTivoli Configuration Manager agent deployment 160
agentConfig.organizationNameTivoli Configuration Manager agent deployment 160
agentConfig.proxyAddressTivoli Configuration Manager agent deployment 160
agentConfig.proxyPortTivoli Configuration Manager agent deployment 160
agentConfig.runtimeAddressTivoli Configuration Manager agent deployment 160
parameter (continued)agentConfig.runtimePort
Tivoli Configuration Manager agent deployment 160
agentConfig.sslPortTivoli Configuration Manager agent deployment 160
agentConfig.startupModeTivoli Configuration Manager agent deployment 161
agentConfig.useProxyTivoli Configuration Manager agent deployment 161
agentidOS/400 agent deployment 184
aggregateUsagePeriod 238
cacheUpdatePeriod 240
certificateinstallagent agent deployment 149
checkPeriod 242
cleanUsagePeriod 237, 301
computer labelWeb agent deployment 143
configurationautomaticTagAssignment 133
node_<platform> 133
proxy 131
proxyname 132
proxyport 132
proxyPort 131
useproxy 132
databaseAliascatalog manager 199
divisioninstallagent agent deployment 147
OS/400 agent deployment 184
Web agent deployment 143
Windows logon script deployment 173
DivisionRSH/SSH UNIX agent deployment 166
Division nameOS/400 agent deployment 178
divisionNameTivoli Configuration Manager agent deployment 157
downloadCatalogPeriod 242
downloadParametersPeriod 242
downloadTopologyPeriod 242
enableSSL 244, 245
gskitinstallagent agent deployment 149
inventoryUpdatePeriod 240
java.naming.provider.url 128
licenseCleanUpPeriod 240
mailRecipient 243
mailSender 243
maxAgentInactivity 241
maxAggregateUsageAge 238
maxSelectionListLength 236
maxServerInactivity 239
maxUsageAge 238, 301
minimumPasswordLength 237
NodeRSH/SSH UNIX agent deployment 167
Node tagOS/400 agent deployment 178
nodeAliascatalog manager 198, 199
nodetagTivoli Configuration Manager agent deployment 157
nodeTaginstallagent agent deployment 147
Index 339
parameter (continued)offlineUsagePeriod 242
organizationinstallagent agent deployment 148
OS/400 agent deployment 184
Tivoli Configuration Manager agent deployment 158
Windows logon script deployment 173
OrganizationRSH/SSH UNIX agent deployment 166
Organization nameOS/400 agent deployment 178
organizationName 245
OSRSH/SSH UNIX agent deployment 167
PasswordOS/400 agent deployment 176
OS/400 agent uninstallation 210
RSH/SSH UNIX agent deployment 167
pingPeriod 242
port 244
installagent agent deployment 148
OS/400 agent deployment 184
Tivoli Configuration Manager agent deployment 158
Windows logon script deployment 174
PortRSH/SSH UNIX agent deployment 167
principalDNPrefix 128
principalDNSuffix 128
privacyPolicyInfoAllowed 236
Processor TypeRSH/SSH UNIX agent deployment 168
processor_typeinstallagent agent deployment 149
Tivoli Configuration Manager agent deployment 159
proxy 245
OS/400 agent deployment 184
Proxy portOS/400 agent deployment 180
Proxy server addressOS/400 agent deployment 180
proxy_portOS/400 agent deployment 184
proxyNameinstallagent agent deployment 148
Tivoli Configuration Manager agent deployment 158
Windows logon script deployment 174
proxyPort 245
installagent agent deployment 148
Tivoli Configuration Manager agent deployment 158
Windows logon script deployment 174
requestScope 242
Runtime addressRSH/SSH UNIX agent deployment 166
runtime server addressinstallagent agent deployment 148
Runtime server addressOS/400 agent deployment 178
runtime server nameWeb agent deployment 143
Runtime server port / SSL portOS/400 agent deployment 179
runtimeAddressTivoli Configuration Manager agent deployment 158
runtimeBaseTime 239
runtimeName 245
runtimePluginPeriod 240
parameter (continued)scanner
installagent agent deployment 149
secure_portinstallagent agent deployment 148
OS/400 agent deployment 184
Windows logon script deployment 174
secureData 237
securePort 237
security_levelinstallagent agent deployment 148
Windows logon script deployment 173
server 244
OS/400 agent deployment 184
Windows logon script deployment 173
serverWakeUpEnabled 239
serverWakeUpPeriod 239
sessionTimeout 237
setLang.CCSIDTivoli Configuration Manager agent deployment 161
Shared pool capacityRSH/SSH UNIX agent deployment 168
shared_pool_capacityinstallagent agent deployment 149
Tivoli Configuration Manager agent deployment 159
smtpServer 243
sourcePathinstallagent agent deployment 147
SSL portRSH/SSH UNIX agent deployment 167
SSLPort 244
Startup modeOS/400 agent deployment 179
RSH/SSH UNIX agent deployment 167
startupModeOS/400 agent deployment 184
Tivoli Configuration Manager agent deployment 158
storeGroup 241
storeHost 241
storeUser 241
SystemOS/400 agent deployment 176
OS/400 agent uninstallation 210
system_active_processorsinstallagent agent deployment 149
Tivoli Configuration Manager agent deployment 159
tagOS/400 agent deployment 184
target_dirTivoli Configuration Manager agent deployment 159
updateAgentEnabled 231, 243
updateAgentPeriod 243
uploadMinTime 242
uriinstallagent agent deployment 148
URI 244
usageSnapshotPeriod 241
Use proxy serverOS/400 agent deployment 179
use_proxyOS/400 agent deployment 184
useProxy 131, 245
installagent agent deployment 148
Tivoli Configuration Manager agent deployment 159
Windows logon script deployment 174
User IDOS/400 agent deployment 176
340 IBM Tivoli License Manager: Planning, Installation, and Configuration
parameter (continued)User ID (continued)
OS/400 agent uninstallation 210
parametersactive processors
all components installation 91
administration server addresscustom installation 86
typical runtime installation 83
administration server portdefault value in all components installation 91
default value in typical runtime installation 84
all components installationactive processors 91
default value for administration server port 91
default value for runtime communication password 91
default value for runtime server name 91
default value for SSL enablement 91
organization 90
processor type 90
shared pool capacity 91
tlmsrv password 90
catalog manage installDB2 administrator password 195
DB2 instance owner’s password 195
catalog manager installDB2 administrator user 195
DB2 install path 195
DB2 instance owner 195
catalog manager installationdatabase address 196
database instance owner 196
database port number 196
configurationmailRecipient 118
mailSender 118
requestScope 104
secureData 103
securePort 103
smtpServer 118
custom installationadministration server address 86
database address 88, 89
database instance owner 88, 89
database port number 88, 89
organization 86
port 87
runtime server name 86
SSL enablement 86
SSL port 86
tlmsrv password 85
use tlmsrv password for runtime communication
password 85
database addresscatalog manager installation 196
custom installation 88, 89
database instance ownercatalog manager installation 196
custom installation 88, 89
database port numbercatalog manager installation 196
custom installation 88, 89
DB2 administrator passwordcatalog manage install 195
server and database install 81
DB2 administrator usercatalog manager install 195
parameters (continued)DB2 administrator user (continued)
server and database install 80
DB2 install pathcatalog manager install 195
server and database install 80
DB2 instance ownercatalog manager install 195
server and database install 80
DB2 instance owner’s passwordcatalog manage install 195
server and database install 81
DB2 instance owner’s pathcatalog manager install 195
server and database install 80
DB2 port numberserver and database install 80
for catalog manager installationsusing Tivoli Configuration Manager 288
for OS/400 silent installations 290
for server and database installationsusing Tivoli Configuration Manager 280
for silent catalog manager installations 287
for silent server and database installations 267
for silent server and database uninstallations 285
HTTP Server install pathserver and database install 81
organizationall components installation 90
custom installation 86
typical runtime installation 83
portcustom installation 87
typical runtime installation 83
port number, DB2server and database install 80
processor typeall components installation 90
runtime communication passworddefaulted in all components installation 91
defaulted in typical runtime installation 83
runtime server namecustom installation 86
default value in all components installation 91
default value in typical runtime installation 83
runtime server portdefault value in typical runtime installation 83
server and database installDB2 administrator password 81
DB2 administrator user 80
DB2 install path 80
DB2 instance owner 80
DB2 instance owner’s password 81
DB2 instance owner’s path 80, 195
DB2 port number 80
HTTP Server install path 81
port number, DB2 80
WebSphere Application Server administrator
password 82
WebSphere Application Server administrator user 81
WebSphere Application Server install path 81
shared pool capacityall components installation 91
SSL enablementcustom installation 86
default value in all components installation 91
default value in typical administration installation 84
Index 341
parameters (continued)SSL enablement (continued)
default value in typical runtime installation 83
SSL portcustom installation 86
tlmsrv passwordall components installation 90
custom installation 85
typical administration installation 84
typical runtime installation 82
typical administration installationdefault value for SSL enablement 84
tlmsrv password 84
typical runtime installationadministration server address 83
default value for administration server port 84
default value for runtime communication password 83
default value for runtime server name 83
default value for runtime server port 83
default value for SSL enablement 83
organization 83
port 83
tlmsrv password 82
use tlmsrv password for runtime communication passwordcustom installation 85
WebSphere Application Server administrator passwordserver and database install 82
WebSphere Application Server administrator userserver and database install 81
WebSphere Application Server install pathserver and database install 81
parameters checklist 268
passwordfor DB2 database 272, 282
key.jks Java keystore 111
key.kdb database 111
key.sth stash file 111
SSLchange 111
tlmroot 96, 98
tlmsrv 272, 282
Passwordagent parameter
OS/400 agent deployment 176
OS/400 agent uninstallation 210
RSH/SSH UNIX agent deployment 167
passwordsAdministrator password 298
administrator, to set up IBM HTTP Server as service 34
administrator, to set up WebSphere Application Server as
service 34
changing 297, 298
DB2 administration 34, 298
in clear 70, 191
planning 21
runtime communicationparameter defaulted in all components installation 91
parameter defaulted in typical runtime installation 83
runtime server communication 21, 298
panel in custom installation 87
secure communication of from browsersSSL configuration for 103
SSL 21, 298
tlmsrv 21, 297
parameter, all components installation 90
parameter, custom installation 85
parameter, typical administration installation 84
passwords (continued)tlmsrv (continued)
parameter, typical runtime installation 82
use tlmsrv for runtime communication passwordparameter, custom installation 85
patch agent 231
Patchesfor supported agent platforms 14, 15
for supported server platforms 13
path names, notation xxi
PATH variable in Windows, check, if DB2 already
installed 64, 188
path, installcatalog manager 193
servers and databases 74
performance considerations 239, 301
pingPeriod parameter 242
planning 1
administration servers 10
agent deployment 42
installagent 47
OS/400 agents 52
using SSH or RSH for UNIX nodes 49
using Tivoli Configuration Manager 48
using Windows logon scripts 51
Web 46
agent deployment information collection 45
agents 9
catalog manager 12
installation 55
checklists 37
collecting required information 37
configure 22, 37
connectivity 15
databases 11
division 9
hostnames 12
how to installdatabases 23
servers 23
information collection 37
install 22
install method 24
installingdatabases 23
servers 23
IP address 12
organization 9
passwords 21
refresh 59
runtime servers 10
SSL 11, 16
supported platforms 12
time zones 12
to populate databases 58
uninstallations 59
user interface 41
Web UI 41
platforms supportedagent deployment on OS/400 nodes 54
agent deployment on OS/400 nodes using Windows
wizard 53
database installation using Tivoli Configuration
Manager 36
for agent deployment using Tivoli Configuration
Manager 48
for agent deployment using Windows logon script 52
342 IBM Tivoli License Manager: Planning, Installation, and Configuration
platforms supported (continued)for agents 14, 15
for catalog manager installation using Tivoli Configuration
Manager 57
for installagent command 48
for SSH/RSH agent deployment 50, 51
for SSH/RSH agent deployment wizard 50
for Web deployment 46
server installation using Tivoli Configuration Manager 36
platforms supported forcatalog manager 15
databases 13
servers 13
platforms, supported 12
plug inruntime server 240
plug in to runtime server command 228
pluginruntime servers 97
portagent parameter
installagent 148
OS/400 agent deployment 184
Tivoli Configuration Manager 158
Windows logon script deployment 174
parameter, custom installation 87
parameter, typical runtime installation 83
Portagent parameter
RSH/SSH UNIX agent deployment 167
port 80, possible conflict 35
port 9090, possible conflict 35
port aliasesrestoring default 116
setting for SSL 110
port conflicts, possible, on WebSphere Application Server 35
port number, DB2parameter 80
port parameter 244
prerequisitesadministration server database 29
AIX processorfor servers 27
auto-installing 32
browser 41
bundledCD 23
checking for existence ofDB2 78
DB2, for catalog manager 193
WebSphere Application Server 78
CPUfor catalog manager 56
for databases 29
for servers 27
database driver for catalog manager 56
database driver for databases 29
databases 29
DB2 25, 29, 56
displayfor servers 28
entitlement settings 139
fix packsfor installing bundled software 33
for administration server 25
for agent 42
for agent deployment on OS/400 53
prerequisites (continued)for agent deployment on OS/400 nodes 54
for catalog manager 55
for data warehouse enablement pack 58
for installagent command 48
for runtime server 25
for using RSH and SSH in UNIX for agent deployment 50
for using Tivoli Configuration Manager for agent
deployment 48
for using Tivoli Configuration Manager for catalog
manager installation 57
for using Tivoli Configuration Manager for server and
database installation 36
for using Windows logon scripts for agent deployment 52
for Web UI 41
HP processor 27
HTTP Server 26
IBM WebSphere Application Server 26
installation panelDB2 79
DB2, for catalog manager 194
WebSphere Application Server 81
installation setup file panelDB2 91
DB2, for catalog manager 197
WebSphere Application Server 92
installing (planning) 31
installing automatically 32
Internet browser 41
Internet Explorer 41
for Web deployment 47
Java Development Kit for OS/400 agent deployment 53,
54
Java Runtime Environment for catalog manager 56
Java Runtime Environment for OS/400 agent
deployment 53
Java Runtime Environment for servers 26
Java Runtime Environment for Web deployment 47
JDBC for catalog manager 56
JDBC for databases 29
language support for OS/400 agents 44
Linuxon Intel x86 servers 27
on pSeries servers 27
on zSeries servers 27
memoryfor catalog manager 57
for databases 29
for servers 27
Microsoft Internet Explorer 41
for Web deployment 47
Mozilla 41
for Web deployment 47
obtaining 31
panel to locateDB2 78
DB2, for catalog manager 193
WebSphere Application Server 79
patchesfor installing bundled software 33
runtime server database 29
service packsfor installing bundled software 33
software for server components 25, 26
Solaris processorfor servers 27
space 36, 57
Index 343
prerequisites (continued)for agents 44
for catalog manager 57
for databases 30
for servers 28
summary 317
Tivoli Configuration Manager 49
Tivoli Configuration Manager, for installing catalog
manager 57
Tivoli Configuration Manager, for installing servers and
databases 36
Tivoli Management Framework 49
Tivoli Management Framework, for installing catalog
manager 57
Tivoli Management Framework, for installing servers and
databases 36
Web deployment 46
Web Server 26
WebSphere Application Server 26
Windows processorfor servers 27
principalDNPrefix parameter 128
principalDNSuffix parameter 128
privacy policyconfiguring 236
defining for groups 241
defining for nodes (hosts) 241
defining for user groups 241
defining for users 241
managing 219
privacy policy for agents 141
privacyPolicyInfoAllowed parameter 236
problem determinationdescribing problem for IBM Software Support xviii
determining business impact for IBM Software
Support xviii
servers and databases installation 94
submitting problem to IBM Software Support xix
processor prerequisitesfor catalog manager 56
for databases 29
for servers 27
processor typeparameter, all components installation 90
Processor Typeagent parameter
RSH/SSH UNIX agent deployment 168
processor_typeagent parameter
installagent 149
Tivoli Configuration Manager 159
product packaging 22
products, starting and stopping 217
profile managerfor catalog manager installation 191
for server and database installation 69
proxyagent parameter
OS/400 agent deployment 184
configuration parameter 131
proxy parameter 245
Proxy portagent parameter
OS/400 agent deployment 180
proxy serverconfigure 131
Proxy server addressagent parameter
OS/400 agent deployment 180
proxy serversconfiguration planning 39
plan to configure 39
proxy_portagent parameter
OS/400 agent deployment 184
proxynameconfiguration parameter 132
proxyNameagent parameter
installagent 148
Tivoli Configuration Manager 158
Windows logon script deployment 174
proxyportconfiguration parameter 132
proxyPortagent parameter
installagent 148
Tivoli Configuration Manager 158
Windows logon script deployment 174
configuration parameter 131
proxyPort parameter 245
pSeriescertified kernels 43
Linux forprocessor prerequisite for servers 27
platforms not supported for Web deployment 46
supported agent platforms 15
supported server platforms 13
PTFsfor supported agent platforms 14, 15
for supported server platforms 13
publicationsaccessing online xvi
online xvii
ordering xvii
QQITLM user 228
QLANGID environment variable 218
QShell Interpreter option, for OS/400 agent deployment 53,
54
Rranges in configuration files 234
reboot_needed.txt file 162
recipientsof event notifications 117
recordFile_Install.txtfor installing servers and databases silently with multiple
passes 70
recordFile_Install.txt filecatalog manager 287
for installing catalog manager silently 189
for installing servers and databases silently 67
for OS/400 agents 181, 182
OS/400 agent 290
servers and databases 267
recordFile_Uninstall.txt filefor uninstalling servers and databases silently 204
servers and databases 285
344 IBM Tivoli License Manager: Planning, Installation, and Configuration
recovering from disasterplanning for 40
Red Hat Enterprise Linuxcertified kernels 43
platforms not supported for Web deployment 46
prerequisites for installing bundled WebSphere Application
Server 34
supported agent platforms 15
supported platforms for SSH/RSH agent deployment 50
supported server platforms 13
redeploy agent 231
refreshing the installationplanning 59
register runtime servers 96
release license 240, 242
reload agent’s configuration file command 228
reloadconf, WebSphere Application Server agent
command 230
remote installationcatalog manager 55
servers and databases 24
remote installation using Tivoli Configuration Manager 69
catalog manager 191
remote uninstallation of catalog manager using Tivoli
Configuration Manager 212
remote uninstallation using Tivoli Configuration
Manager 204
remove agent command 228
requestScopeconfiguration parameter 104
requestScope parameter 242
response filefor installing catalog manager silently 189
for installing servers and databases silently 67
for installing servers and databases silently with multiple
passes 70
for uninstalling catalog manager silently 212
for uninstalling servers and databases silently 204
Restore Licensed Program for agent deployment on OS/400planning 54
restore of server configuration files 250
restoreconf command 250
reviewagents 231
RHELSee also Red Hat Enterprise Linux
supported agent platforms 15
supported server platforms 13
root userrequired for catalog manager uninstall on UNIX 211
required for installation on UNIX 73, 191
required for uninstall on UNIX 203
RSHfor agent deployment
prerequisites 50
for agent deployment on UNIX 162
RSH or SSH for UNIX nodesdeployment of agent
planning 49
RSH/SSH agent deploymentplatforms supported 50, 51
software required 51
space required 51
RSH/SSH agent deployment wizardplatforms supported 50
RSTLICPGM command 183
RSTLICPGM for agent deployment on OS/400planning 54
rtpasswd command 298
run inventory scan command 228
RUNJVA command 183
runtime catalogadding unknown files to 240
download to agent 242
runtime communication passwordparameter (default), all components installation 91
parameter (default), typical runtime installation 83
runtime databasesupported platforms 13
runtime serveradd SSL server certificate 114
address, agent parameterinstallagent 148
RSH/SSH UNIX agent deployment 166
agents, number of 10
all components installation 77
base configuration parameters panel 90
alternativeplanning for SSL 22
backupconf command 247
CD 22
change SSL password 111
checklist 257
commands 246
communication password 21
components checklist 257
configuration filesdefault settings 234
location 233
ranges 234
configuration planning 38
configure 97
configure Java 2 Security 135
configure proxy server 131
configure settings 97
configure SSLfor communications from Web browsers 102
for communications with administration server 101
configure to send secure communications 110
create SSL server certificate 113
create SSL server certificate as a Certificate Authority 114
custom installation 77
base configuration parameters panel 84
runtime server communication password panel 87
runtime server database panel 88
customizing error 500 file 119
database addressparameter, custom installation 89
database instance ownerparameter, custom installation 89
database port numberparameter, custom installation 89
dropping the database when uninstalling 205
enabling for SSL 20
functionality summary 2
in Tivoli License Manager structure 2
install planning 23
install using Tivoli Configuration Managerplatforms supported 36
software 36
installation using Tivoli Configuration Managersoftware package block parameters 280
installing 66
Index 345
runtime server (continued)login 98
name, agent parameterWeb 143
number of agents 10
options file for silent installations 267
options file for silent uninstallations 285
packaging 22
plan to configure 38
planning 10
for SSL 17
planning to install 23
plug in 240
plugin 97
portparameter (default), typical runtime installation 83
prerequisites 25
space 28
register 96
register, and enable to receive secure communications 114
request SSL server certificate 112
restoreconf command 250
silent installation options file 267
silent uninstallation options file 285
space prerequisites 28
SSL configurationto receive secure communications from administration
server 100
to receive secure communications from agents 105
to receive secure communications from Web
browser 103
to send secure communications to administration
server 102
starting 295
stopping 295
summary of functionality 2
supported platforms 13
synchronizing server times 236
system.properties file settings 239
timing of events and services 235
typical installation 76
typical runtime installationbase configuration parameters panel 82
uninstall 203
UNIXconfigure to run under a non-root user 134
URL for Web agent deployment 141
URL, changing 97
using HTTP from browsers, to access 116
using HTTPS from browsers, to access 115
Runtime server addressagent parameter
OS/400 agent deployment 178
runtime server communicationpassword, changing 298
runtime server communication password panelcustom installation 87
runtime server databaseall components installation 77
base configuration parameters panel 90
CD 22
connecting database to its server on Windows 314
creating on Windows 313
custom installation 77
base configuration parameters panel 84
runtime server communication password panel 87
disconnecting database from its server on Windows 315
runtime server database (continued)install planning 23
install using Tivoli Configuration Managerplatforms supported 36
software 36
installation using Tivoli Configuration Managersoftware package block parameters 280
installing 66
options file for silent installations 267
options file for silent uninstallations 285
packaging 22
panel 88
planning to install 23
prerequisites 29
silent installation options file 267
silent uninstallation options file 285
typical installation 76
typical runtime installationbase configuration parameters panel 82
uninstall 203
runtime server nameparameter (default), all components installation 91
parameter (default), typical runtime installation 83
parameter, custom installation 86
Runtime server port / SSL portagent parameter
OS/400 agent deployment 179
runtimeAddressagent parameter
Tivoli Configuration Manager 158
runtimeBaseTime parameter 239
runtimeBaseTime, configuration parameter, synchronizing
server times 236
runtimeBaseTime, configuration parameter, used for event
timing 235
runtimeName parameter 245
runtimePluginPeriod parameter 240
SS/390
certified kernels 43
platforms not supported for Web deployment 46
supported agent platforms 15
supported server platforms 13
Save Licensed Program for agent deployment on OS/400planning 54
SAVLICPGM command 183
SAVLICPGM for agent deployment on OS/400planning 54
scan inventory command 228
scan, inventoryupload time, maximum 59
scanneragent parameter
installagent 149
scans, inventorySee inventory scans
scenarioimplementation 5
scenario for installation 61
scheduleinventory scans 97
schedulingagent deployment 54
inventory scans 58
346 IBM Tivoli License Manager: Planning, Installation, and Configuration
scriptsSee also commands
dbrootinstall.bat 313
dbrootinstall.sh 313
secure communicationsSee SSL
secure data for Web UI 237
secure port used for Web UI 237
Secure Sockets LayerSee SSL
secure_portagent parameter
installagent 148
OS/400 agent deployment 184
Windows logon script deployment 174
secureDataconfiguration parameter 103
secureData parameter 237
securePortconfiguration parameter 103
securePort parameter 237
securitypasswords in clear 70, 191
security cell access in WebSphere Application Server, when
uninstalling the product 205, 206
security_levelagent parameter
installagent 148
Windows logon script deployment 173
select component groupsservers and databases 76
select componentsservers and databases 75
select custom componentsservers and databases 77
self-signed SSL certificateadd 114
create 113
request 112
self-signed SSL server certificate 18, 20
self-update of agent 231
self-updating agent 243
serveragent parameter
OS/400 agent deployment 184
Windows logon script deployment 173
server certificate, SSLadd 114
adding certificate to OS/400 deployment 180
adding certificate to SSH/RSH deployment 164
adding to software package block 155
create 113
create as a Certificate Authority 114
request 112
server installationusing Tivoli Configuration Manager 280
server parameter 244
serversalternative 140
CD 22
configuring wake-up for runtime 239, 240
install using Tivoli Configuration Managerplatforms supported 36
software 36
installationpre-install tasks 63
packaging 22
servers (continued)proxy
configuration planning 39
plan to configure 39
software prerequisites 25, 26
spb 23
starting and stopping 295
supported platforms 13
servers, WebSphere Application Server agent command 230
serverWakeUpEnabled parameter 239
serverWakeUpPeriod parameter 239
Service packsfor supported agent platforms 14, 15
for supported server platforms 13
servicestiming 235
synchronizing server times 236
ServicesWindows window that must be closed before Web agent
deployment 141
services, Windows, install agent as command 228
session timeout for Web UI 237
sessionTimeout parameter 237
setLang.CCSIDagent parameter
Tivoli Configuration Manager 161
setup files, old, checking for 63
setupAgentOS400.exefor OS/400 agents 181
setupAgentOS400.exe file 175
setupAgentOS400.jar file 182
setupCatMan.bin file 188
setupCatMan.exe file 189
setupServers.bin file 66
setupServers.exe file 66
shared pool capacityparameter, all components installation 91
Shared pool capacityagent parameter
RSH/SSH UNIX agent deployment 168
shared_pool_capacityagent parameter
installagent 149
Tivoli Configuration Manager 159
shell, UNIXas prerequisite software for catalog manager 56
as prerequisite software for databases 29
as prerequisite software for server components 26
used for installing server and database components 67
silent installationcatalog manager 287
OS/400 agent 290
servers and databases 267
silent uninstallationservers and databases 285
silent wizardfor installing catalog manager 55, 189
for installing servers and databases 24, 67
for installing servers and databases with multiple
passes 70
for OS/400 agents 181
for uninstalling catalog manager 212
for uninstalling servers and databases 204
smtpServerconfiguration parameter 118
smtpServer parameter 243
Index 347
softwaredatabase installation using Tivoli Configuration
Manager 36
for agent deployment using Tivoli Configuration
Manager 49
for agents 42, 43
for Web deployment 47
required for agent deployment on OS/400 nodes 54
required for agent deployment on OS/400 nodes using
Windows wizard 53
required for agent deployment using SSH and RSH 51
required for catalog manager 56
server installation using Tivoli Configuration Manager 36
software data, collected at agent 217
software distributionSee Tivoli Configuration Manager
software for server componentsprerequisites 25, 26
software package blockagents 154
catalog manager 288
for installingagents 23
catalog manager 23
servers 23
for installing catalog manager 191
for installing servers and databases 69
servers and databases 280
software requiredfor catalog manager installation using Tivoli Configuration
Manager 57
Software Supportcontacting xvii
describing problem for IBM Software Support xviii
determining business impact for IBM Software
Support xviii
submitting problem to IBM Software Support xix
software us tableaggregation 238
software use tablecleanup 237, 238
software use table cleanup 301
SolarisSee also Sun
supported agent platforms 15
supported server platforms 13
sourcePathagent parameter
installagent 147
spacefor agent deployment on OS/400 nodes 53, 54
for agent deployment using Tivoli Configuration
Manager 49
for agent deployment using Windows logon script 52
for installagent command 48
required for agent deployment using SSH and RSH 51
space prerequisitesfor agents 44
for catalog manager 57
for databases 30
for servers 28
installing catalog manager using Tivoli Configuration
Manager 57
installing servers and databases using Tivoli Configuration
Manager 36
SPARCsupported Solaris agent platforms 15
SPARC (continued)supported Solaris server platforms 13
srvstart command 295
srvstop command 295
SSHclient 51
for agent deploymentprerequisites 50
for agent deployment on UNIX 162
SSH or RSH for UNIX nodesdeployment of agent
planning 49
SSH/RSH agent deploymentplatforms supported 50, 51
software required 51
space required 51
SSH/RSH agent deployment wizardplatforms supported 50
SSLadding certificate to OS/400 deployment 180
adding certificate to software package block 155
adding certificate to SSH/RSH deployment 164
advantages 16
authentication 16
certificateadding certificate to OS/400 deployment 180
adding certificate to SSH/RSH deployment 164
adding to software package block 155
client 16
configuring 20
configuration planning 38
configure 98
activities 107
add server certificate 114
agent deployment, using SSL at startup 106
change SSL password 111
communication channels 98
create server certificate 113
create server certificate as a Certificate Authority 114
disabling encryption at Web server 109
disabling SSL for Web server 115
enabling SSL for Web server 107
for secure browser communications involving only
passwords 103
from administration server to runtime server 99
from agent to runtime server 104
from runtime server to administration server 101
from Web browsers to servers 102
installagent agent deployment, using correct SSL
certificate 106
OS/400 agent deployment, using correct SSL
certificate 106
procedures 98
register runtime server, and enable to receive secure
communications 114
request server certificate 112
restoring default port aliases 116
runtime server to send secure communications 110
setting SSL port aliases 110
Tivoli Configuration Manager agent deployment, using
correct SSL certificate 106
UNIX agent deployment using SSH/RSH, using correct
SSL certificate 106
using HTTP from browsers 116
using HTTPS from browsers 115
Web agent deployment, using correct SSL
certificate 106
348 IBM Tivoli License Manager: Planning, Installation, and Configuration
SSL (continued)configure (continued)
Windows agent deployment using logon script, using
correct SSL certificate 106
configuring 19
disadvantages 16
enable 98
enablementduring installation 76
parameter (default), all components installation 91
parameter (default), typical administration
installation 84
parameter (default), typical runtime installation 83
parameter, custom installation 86
functionality 16
how it works 16
implementation 17
password 21
password, changing 298
plan to configure 38
planning 11, 16
for use with alternative runtime servers 22
portparameter, custom installation 86
privacy 16
reliability 16
server 17
configuring 19
server certificatedecryption 17
encryption 17
issuing 18, 20
key database 17
key database password 17
keystore 17
keystore password 17
obtaining 18, 20
overview 17
self-signed 18, 20
validation 17
SSL portagent parameter
RSH/SSH UNIX agent deployment 167
sslpasswd command 298
SSLPort parameter 244
start agent service agent command 227
starting of applications (products), monitor 217
starting the server 295
Startup modeagent parameter
OS/400 agent deployment 179
RSH/SSH UNIX agent deployment 167
startupModeagent parameter
OS/400 agent deployment 184
Tivoli Configuration Manager 158
stderr.txt fileconfigure Java 2 Security 136
stdout.txt fileconfigure Java 2 Security 136
stop agent service agent command 227
stopping of applications (products), monitor 217
stopping the server 295
storeGroup parameter 241
storeHost parameter 241
storeUser parameter 241
structure of Tivoli License Manager 2
Sunadditional agent commands 229
agent files 225
prerequisites for installing bundled DB2 34
prerequisites for installing bundled WebSphere Application
Server 34
processor prerequisitefor servers 27
setup file 66
catalog manager 189
software package blockfor agents 154
for servers and databases 69
supported platforms for SSH/RSH agent deployment 51
Sun Solarissupported agent platforms 15
supported server platforms 13
support information, updating xx
supported platforms 12
agent deployment on OS/400 nodes 54
agent deployment on OS/400 nodes using Windows
wizard 53
database installation using Tivoli Configuration
Manager 36
for agent deployment using Tivoli Configuration
Manager 48
for agent deployment using Windows logon script 52
for agents 14, 15
for catalog manager installation using Tivoli Configuration
Manager 57
for installagent command 48
for SSH/RSH agent deployment 50, 51
for SSH/RSH agent deployment wizard 50
for Web deployment 46
server installation using Tivoli Configuration Manager 36
supported platforms forcatalog manager 15
databases 13
servers 13
SUSE LINUX Enterprise Servercertified kernels 43
platforms not supported for Web deployment 46
supported agent platforms 15
supported platforms for SSH/RSH agent deployment 50
supported server platforms 13
synchronizing server times 236
Systemagent parameter
OS/400 agent deployment 176
OS/400 agent uninstallation 210
System Manager for AIX, version 5.1, possible port
conflict 35
system_active_processorsagent parameter
installagent 149
Tivoli Configuration Manager 159
system.properties fileadministration server settings 237
agent self-update enablement 231
agent settings 218, 241
configure for Web browsers to use secure communications
only for passwords 103
configure runtime server and agent settings 97
configure Web interface and administration server
settings 95
e-mail settings 243
enable agent self-update 231
Index 349
system.properties file (continued)mail settings 117
parameter descriptions 235
runtime server settings 239
software use tables cleanup 301
Web interface settings 236
Ttag
agent parameterOS/400 agent deployment 184
target_diragent parameter
Tivoli Configuration Manager 159
taskstopology, agents 231
tasks, common 295
TCP/IP option, for OS/400 agent deployment 53
test environment for determining topology 10
time setting (base)for administration server 237
for runtime server 239
time zonechanging 63
catalog manager 187
planning 12
timing of events and services 235
synchronizing server times 236
Tivoli Common Directory 221
Tivoli Configuration Manageragent deployment
procedure 152
as prerequisite for agent deployment 49
as prerequisite for installing catalog manager 57
as prerequisite for installing servers and databases 36
deployment of agentplanning 48
encryption 70, 191
for agent deploymentusing correct SSL certificate 106
for remote installation of catalog manager 191
install main components 69
platforms supported 48
prerequisites for using for agent deployment 48
prerequisites for using for catalog manager installation 57
prerequisites for using for server and database
installation 36
remote installation of servers and databases 69
remote uninstallation of catalog manager 212
remote uninstallation of servers and databases 204
space required for agent deployment 49
uninstall catalog manager 212
uninstall optionfor remote uninstallation of catalog manager 212
for remote uninstallation of servers and databases 204
uninstall servers and databases 204
uninstallationdropping the databases 205
used to install catalog manager 191
using to install catalog manager 55
using, to install servers and databases 24
Tivoli data warehouse enablement packprerequisites 58
Tivoli Data Warehouse Enablement Pack 8
Tivoli License Manager for IBM Software, upgrade 215
Tivoli License Manager structure 2
Tivoli Management Frameworkas prerequisite for agent deployment 49
as prerequisite for installing catalog manager 57
as prerequisite for installing servers and databases 36
Tivoli Management Region 152
Tivoli Software Information Center xvi
Tivoli technical training xvii
tlm.bat file 172
tlmagent command 227
tlmagent.ini file 183
TLMCDB 199
tlmrootpassword 96, 98
user 96, 98
tlmsrvpassword 21
parameter, all components installation 90
parameter, custom installation 85
parameter, typical administration installation 84
parameter, typical runtime installation 82
password, changing 297
tlmsrv password 272, 282
tlmunins command 209
topologyadministration servers 10
agents 9, 231
catalog manager 12
component 10
components 10
databases 11
divisions 9
functionality summary 9
hostnames 12
IP address 12
organization 9
organizational 9
runtime servers 10
SSL 11, 16
summary of functionality 9
test environment 10
time zones 12
topology data formats for UNIX agent deployment
wizard 307
training, Tivoli technical xvii
tuningDB2 136
Tivoli License Manager 136
WebSphere Application Server 136
typeface conventions xxi
typicalinstallation type
OS/400 agent 177
typical administration installationbase configuration parameters panel 83
servers and databases 83
typical installationadministration server and database 76
runtime server and database 76
servers and databases 76
typical runtime installationbase configuration parameters panel 82
servers and databases 82
Uuncatalog the databases manually during uninstallation 207
350 IBM Tivoli License Manager: Planning, Installation, and Configuration
uninstallagents 208
catalog manageroverview 211
databases 203
dropping the databases during 205
dropping the databases manually during 207
remotely 204
catalog manager 212
servers 203
silentservers and databases 285
uncatalog the databases manually during 207
uninstall option of Tivoli Configuration Manager for remote
uninstallationscatalog manager 212
servers and databases 204
uninstallationsplanning 59
uninstaller.bin file 203
catalog manager 211
uninstaller.exe file 203
catalog manager 211
UNIXagent
deployment wizard import file formats 303
agent deploymentprocedure 162
agent deployment using SSH/RSHusing correct SSL certificate 106
agent language selection 218
agents, uninstalling 209
checking for DB2 configuration files 63, 187
checking for old setup files 63
checking that DB2 configuration files do not contain a shell
call 64, 188
configure a server to run under a non-root user 134
connecting DB2 database to its server 314
creating DB2 database 313
disconnecting DB2 database from its server 315
enabling graphics for administration server 311
ensuring availability of operating system commands 63
catalog manager 187
initializing the DB2 command line 296
installing server and database components using korn
shell 67
root user required for catalog manager uninstall 211
root user required for installation 73, 191
root user required for uninstall 203
running agent commands 228
shell for catalog manager 56
shell for databases 29
shell for server components 26
starting the IBM HTTP Server 296
starting the WebSphere Administrator’s Console 297
stopping the IBM HTTP Server 296
stopping the WebSphere Administrator’s Console 297
uninstalling agents 209
UNIX agent deploymentusing SSH or RSH
planning 49
unknown filesadding to runtime catalog 240
sending to runtime server 242
Update levelsfor supported agent platforms 14, 15
for supported server platforms 13
updateAgentEnabled parameter 231, 243
updateAgentPeriod parameter 243
upgrade from Tivoli License Manager for IBM Software 215
uploadMinTime parameter 242
uriagent parameter
installagent 148
URI parameter 244
URL for Web agent deployment 141
usageSnapshotPeriod parameter 241
Use proxy serveragent parameter
OS/400 agent deployment 179
use_proxyagent parameter
OS/400 agent deployment 184
useproxyconfiguration parameter 132
useProxyagent parameter
installagent 148
Tivoli Configuration Manager 159
Windows logon script deployment 174
useProxy parameter 131, 245
userAdministrator 203
required for catalog manager uninstall on
Windows 211
Administrator rights 73, 175, 191
defining privacy policy 241
QITLM 228
root 73, 191, 203
required for catalog manager uninstall on UNIX 211
tlmroot 96, 98
user authenticationSee authentication
user groupsdefining privacy policy 241
User IDagent parameter
OS/400 agent deployment 176
OS/400 agent uninstallation 210
user IDsAdministrator, to set up HTTP Server as service 34
Administrator, to set up WebSphere Application Server as
service 34
DB2 administration 34
tlmsrv 21
user interfaceSee Web user interface
UTF-8 encodinginstallagent parameters 150
Vvariable
DISPLAY 311
variables%HOST
in automatic computer label assignment 134
in installagent deployment 148
in OS/400 node silent install 185
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent
deployment 158
in Web deployment 143
in Windows logon script agent deployment 174
Index 351
variables (continued)%MODEL
in automatic computer label assignment 134
in installagent deployment 147
in OS/400 node silent install 184
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent
deployment 157
in Web deployment 143
in Windows logon script agent deployment 174
%SERIALin automatic computer label assignment 134
in installagent deployment 147
in OS/400 node silent install 184
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent
deployment 157
in Web deployment 143
in Windows logon script agent deployment 174
%TYPEin automatic computer label assignment 134
in installagent deployment 147
in OS/400 node silent install 184
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent
deployment 157
in Web deployment 143
in Windows logon script agent deployment 174
%VENDORin automatic computer label assignment 134
in installagent deployment 148
in OS/400 node silent install 185
in OS/400 node Windows wizard 179
in Tivoli Configuration Manager agent
deployment 158
in Web deployment 143
in Windows logon script agent deployment 174
DOMAINSERVER 172
GSKFilesLocked 162
LOG_SHARE 172
NETLOGON_SHARE 172
variables, notation xxi
version 1.1, migrating from 201
version 1.1.1, migrating from 201
version of agent display command 228
virtual host definition 107, 116, 120
Wwake-up (runtime), configuring for 239, 240
warehouse enablement packprerequisites 58
Warehouse Enablement Pack 8
was.policy.50x fileconfigure Java 2 Security 135
was.policy.51x fileconfigure Java 2 Security 135
was.policy.old fileconfigure Java 2 Security 135
WASAgentClient command 230
Web administration serverSee administration server
Web agent deploymentplanning 46
procedure 140
using correct SSL certificate 106
Web application serverprerequisite software for server components 26
Web browser 20
planning for SSL 17
SSL configurationfor secure communications involving only
passwords 103
to send secure communications to servers 103
Web browsersconfigure to communicate in SSL 102
Web deploymentbrowser prerequisite 47
platforms supported 46
Web deployment of agentprerequisites 46
Web runtime serverSee runtime server
Web servercustomization planning 38
disabling encryption 109
disabling for SSL 115
enabling for SSL 107
installing (planning) 31
obtaining 31
plan to customize 38
Web Serveras prerequisite 26
prerequisite software for server components 26
Web user interfaceconfiguration files
default settings 234
ranges 234
configure 95, 97
customize 118
planning 41
prerequisites 41
system.properties file settings 236
using for runtime server registration and secure
communication enablement 114
using for Web agent deployment 141
using HTTP to access the runtime server 116
using HTTPS to access the servers 115
Web-based System Manager for AIX, version 5.1, possible port
conflict 35
WebSphere Administrator’s Consolestarting 297
stopping 297
WebSphere Application Serveradministrator password
parameter 82
Administrator password, to set up WebSphere Application
Server as service 34
administrator userparameter 81
agentcommands 230
agent deploymentprocedure 185
as prerequisite 26
authentication method, LDAP, configure 122
auto-installing 32
CD 23
checking for prerequisite existence 78
configure LDAP authentication method 122
configuring for Tivoli License Manager 93
install pathparameter 81
352 IBM Tivoli License Manager: Planning, Installation, and Configuration
WebSphere Application Server (continued)installing (planning) 31
installing automatically 32
LDAP authentication method, configure 122
locate prerequisite version panel 79
obtaining 31
Plug-in Cumulative Fix for 5.0.0, 5.0.1 and 5.0.2.x 31
possible port conflicts 35
prerequisite installation panel 81
prerequisite installation setup file panel 92
prerequisites for installing bundled version 34
removing configurations for Tivoli License Manager 203
restoring default port aliases 116
security cell access when uninstalling 205, 206
setting SSL port aliases 110
WindowsAdministrator required for catalog manager uninstall 211
Administrator required for installation 191
Administrator required for uninstall 203
Administrator rights required for installation 73, 175
agent deploymentprocedure using logon scripts 170
agent deployment using logon scriptusing correct SSL certificate 106
agent files 226
agent language selection 218
agents, uninstalling 209
check PATH variable if already installed 64, 188
close Services window before Web agent deployment 141
connecting DB2 database to its server 314
creating DB2 database 313
disconnecting DB2 database from its server 315
Domain Controller 171
GSKit in use when agent deployed remotely 162
initializing the DB2 command line 296
logon scripts for agent deploymentprerequisites 52
platforms supportedagent deployment on OS/400 nodes 53
for agent deployment using logon scripts 52
platforms supported for SSH/RSH agent deployment
wizard 50
prerequisites for installing bundled WebSphere Application
Server 34
processor prerequisitefor servers 27
running agent commands 228
Services window must be closed before Web agent
deployment 141
setup file 66
catalog manager 189
software package blockfor agents 154
for servers and databases 69
software requiredfor agent deployment on OS/400 nodes 53
space requiredfor agent deployment using logon scripts 52
starting the IBM HTTP Server 296
starting the WebSphere Administrator’s Console 297
stopping the IBM HTTP Server 296
stopping the WebSphere Administrator’s Console 297
supported agent platforms 14
supported server platforms 13
Terminal Server, installed on target computer 68, 74, 163,
190, 192, 203, 204
Windows (continued)Terminal Services, installing by means of 68, 74, 163, 190,
192, 203, 204
uninstalling agents 209
wizardfor agent deployment on Windows 175
Windows logon scriptsdeployment of agent
planning 51
Windows service, agent installed as command 228
wizardfor installing catalog manager interactively 55, 189
for installing catalog manager silently 55, 189
for installing servers and databases interactively 24, 66
for installing servers and databases silently 24, 67
for installing servers and databases silently with multiple
passes 70
for multiple pass installations of servers and databases
interactively 70
for uninstalling catalog manager interactively 211
for uninstalling catalog manager silently 212
for uninstalling servers and databases interactively 203,
206
for uninstalling servers and databases silently 204
wizard failuresservers and databases installation 94
wizard, interactivefor OS/400 agents 175
wizard, silentfor OS/400 agents 181
XX display server
connecting to 311
requirement for accessing servers 28
XMLuser authentication method 122
XP, supported Windows agent platforms 14
ZzSeries
certified kernels 43
Linux forprocessor prerequisite for servers 27
platforms not supported for Web deployment 46
supported agent platforms 15
supported server platforms 13
Index 353
354 IBM Tivoli License Manager: Planning, Installation, and Configuration
���
Program Number: 5724-D33
SC32-1431-01