You are on page 1of 330

Front cover

Introducing IBM Tivoli License Manager


How-to guide for setting up your license management environment Achieve proactive license management Generate reports and identify trends towards license violations

Edson Manoel John Aronis Ron Falciani Sebastien Fardel Aniruddha Parnaik

ibm.com/redbooks

International Technical Support Organization Introducing IBM Tivoli License Manager March 2003

SG24-6888-00

Note: Before using this information and the product it supports, read the information in Notices on page xvii.

First Edition (March 2003) This edition applies to Version 1.1 of IBM Tivoli License Manager. Note: This book is based on a pre-GA version of a product and may not apply when the product becomes generally available. We recommend that you consult the product documentation or follow-on versions of this redbook for more current information.
Copyright International Business Machines Corporation 2003. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii Chapter 1. Introduction to license management . . . . . 1.1 Software License Use Management requirements . . . 1.2 Asset Management and Asset Protection . . . . . . . . . . 1.3 License Use Management. . . . . . . . . . . . . . . . . . . . . . 1.4 License management system . . . . . . . . . . . . . . . . . . . 1.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....... ....... ....... ....... ....... ....... ...... ...... ...... ...... ...... ...... ... ... ... ... ... ... 1 2 5 6 7 9

Chapter 2. IBM Tivoli License Manager general overview. . . . . . . . . . . . . 11 2.1 IBM Tivoli License Manager overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 IBM Tivoli License Manager physical components . . . . . . . . . . . . . . . . . . 16 2.2.1 IBM Tivoli License Manager Master Catalog . . . . . . . . . . . . . . . . . . 19 2.2.2 Network communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.3 Data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3 IBM Tivoli License Manager logical components . . . . . . . . . . . . . . . . . . . 23 2.4 IBM Tivoli License Manager interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.4.1 Web interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.4.2 XML interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5 Licence Management process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5.1 Software entitlement process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.6 Example scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.6.1 Microsoft license management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.6.2 Oracle license management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.6.3 IBM Tivoli software license management . . . . . . . . . . . . . . . . . . . . . 45 Chapter 3. Implementation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.1 Physical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Copyright IBM Corp. 2003. All rights reserved.

iii

3.1.1 ITLM Administration Server considerations . . . . . . . . . . . . . . . . . . . 52 3.1.2 ITLM Runtime Server considerations . . . . . . . . . . . . . . . . . . . . . . . . 52 3.1.3 Scalability limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.1.4 Network considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.1.5 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.1.6 Hardware considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.1.7 File systems considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.1.8 Physical design example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.2 Logical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.2.1 Naming convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.2.2 Customer considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.2.3 Division considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.2.4 Monitored Nodes considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.2.5 Administrator considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.2.6 Logical design example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.3 Disaster and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.3.1 Backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.3.2 Failover considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.4 Planning for IBM Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.4.1 Planning overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.4.2 Planning for IBM DB2 Universal Database Enterprise Edition . . . . . 71 3.4.3 Planning for HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 3.4.4 Planning for Proxy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.4.5 Planning for IBM WebSphere Application Server . . . . . . . . . . . . . . . 80 3.4.6 Planning for IBM Tivoli License Manager Administration server . . . . 86 3.4.7 Planning for IBM Tivoli License Manager Runtime Server . . . . . . . . 90 3.4.8 Planning for IBM Tivoli License Manager Agent . . . . . . . . . . . . . . . . 92 3.4.9 Planning for IBM Tivoli License Manager Catalog Manager . . . . . . . 96 Chapter 4. Getting IBM Tivoli License Manager up and running . . . . . . . 99 4.1 Example scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.2 Setting up the ITLM Administration server . . . . . . . . . . . . . . . . . . . . . . . 102 4.2.1 IBM DB2 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.2.2 IBM DB2 Fixpack 7 installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.2.3 IBM WebSphere installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.2.4 IBM WebSphere Fixpack 4 installation . . . . . . . . . . . . . . . . . . . . . . 107 4.2.5 ITLM Administration server installation . . . . . . . . . . . . . . . . . . . . . . 108 4.2.6 Creating DB2 schema for Administration server on AIX . . . . . . . . . 113 4.2.7 Connecting DB2 database to Administration server on AIX . . . . . . 114 4.2.8 Setting up SSL configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.2.9 Setting up event notification for Administration server . . . . . . . . . . 117 4.3 Setting up the ITLM Runtime server on AIX . . . . . . . . . . . . . . . . . . . . . . 118 4.3.1 ITLM Runtime server installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 119

iv

Introducing IBM Tivoli License Manager

4.3.2 Creating DB2 schema for Runtime server on AIX. . . . . . . . . . . . . . 124 4.3.3 Connecting DB2 database to Runtime server on AIX . . . . . . . . . . . 125 4.3.4 Setting up event notification for Runtime server . . . . . . . . . . . . . . . 126 4.3.5 Registering Runtime server to the Administration server . . . . . . . . 128 4.4 Setting up the ITLM Runtime server on Windows . . . . . . . . . . . . . . . . . . 131 4.4.1 IBM DB2 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 4.4.2 IBM DB2 Fixpack 7 installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 4.4.3 IBM WebSphere installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 4.4.4 IBM WebSphere Fixpack 4 installation . . . . . . . . . . . . . . . . . . . . . . 136 4.4.5 ITLM Runtime Server Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 136 4.4.6 Creating database schema for Runtime server on Windows . . . . . 141 4.4.7 Setting up event notification for ITLM Runtime server . . . . . . . . . . 141 4.4.8 Registering Runtime server to the Administration server . . . . . . . . 142 Chapter 5. Administering IBM Tivoli License Manager . . . . . . . . . . . . . . 143 5.1 Case study: Physical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 5.2 Analysis and planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 5.3 Infrastructure build and design process . . . . . . . . . . . . . . . . . . . . . . . . . 147 5.4 Test scenarios and pilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 5.5 Case study: Logical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 5.6 Managing Customers and administrators . . . . . . . . . . . . . . . . . . . . . . . . 150 5.6.1 Adding a Customer to the Administration server. . . . . . . . . . . . . . . 150 5.6.2 Creating and adding administrators accounts . . . . . . . . . . . . . . . . . 152 5.6.3 Updating or deleting administration account details . . . . . . . . . . . . 153 5.6.4 Creating administrator accounts on the Runtime server . . . . . . . . . 155 5.7 Managing IBM Tivoli License Manager components. . . . . . . . . . . . . . . . 156 5.7.1 Registering a Runtime server with the Administration server . . . . . 156 5.7.2 Creating Divisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 5.7.3 Deploying an Agent on a node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 5.7.4 Scheduling an inventory scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 5.7.5 Adding application users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 5.8 Managing software entitlement and license pool . . . . . . . . . . . . . . . . . . 166 5.8.1 Gathering customer licensing and procurement information. . . . . . 166 5.8.2 Selecting a product for entitlement or license pool maintenance . . 167 5.8.3 Creating a license pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 5.9 Managing software product components . . . . . . . . . . . . . . . . . . . . . . . . 174 5.9.1 Updating the Master Catalog from the Unknown file table . . . . . . . 176 5.9.2 Importing new releases of the ITLM catalog . . . . . . . . . . . . . . . . . . 182 Chapter 6. Reporting with IBM Tivoli License Manager. . . . . . . . . . . . . . 185 6.1 ITLM pre-defined reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 6.1.1 ITLM Administration server reports . . . . . . . . . . . . . . . . . . . . . . . . . 186 6.1.2 ITLM Runtime Server report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Contents

6.2 6.3 6.4 6.5 6.6

Tivoli Data Warehouse integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Tivoli Data Warehouse overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Tivoli Data Warehouse concepts and components . . . . . . . . . . . . . . . . . 212 ITLM and TDW integration components . . . . . . . . . . . . . . . . . . . . . . . . . 215 Installation and configuration for TDW integration . . . . . . . . . . . . . . . . . 217 6.6.1 ITLM Warehouse enablement pack installation . . . . . . . . . . . . . . . 217 6.6.2 ITLM Warehouse enablement pack configuration. . . . . . . . . . . . . . 221 6.7 TDW reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 6.7.1 Accessing the reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 6.7.2 Reports available with IBM Tivoli License Manager . . . . . . . . . . . . 231 Chapter 7. Performance maximization techniques . . . . . . . . . . . . . . . . . 235 7.1 Initial considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 7.2 IBM DB2 Performance tuning considerations . . . . . . . . . . . . . . . . . . . . . 239 7.2.1 Small ITLM environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 7.2.2 Medium ITLM environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 7.2.3 Large ITLM environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 7.3 IBM WebSphere performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 7.4 IBM HTTP Server performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 246 7.5 ITLM components performance considerations . . . . . . . . . . . . . . . . . . . 247 7.6 Operating system performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 251 7.6.1 Windows environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 7.6.2 AIX environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Software Package structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Software Package variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Software Package version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Software Package definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Installation script structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Agents definition file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Appendix B. SSL key creation for IBM Tivoli License Manager . . . . . . . 275 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Creating the SSL key files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Creating the server certificate file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Creating the key trusted store file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Appendix C. IBM Tivoli License Manager databases. . . . . . . . . . . . . . . . 281 The ITLM Administration server database . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 The ITLM Runtime server database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

vi

Introducing IBM Tivoli License Manager

Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 System requirements for downloading the Web material . . . . . . . . . . . . . 290 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Contents

vii

viii

Introducing IBM Tivoli License Manager

Figures
2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 3-1 3-2 3-3 4-1 4-2 4-3 4-4 4-5 4-6 4-7 4-8 4-9 4-10 4-11 4-12 4-13 4-14 4-15 4-16 4-17 4-18 4-19 4-20 4-21 4-22 5-1 5-2 5-3 5-4 Software licensing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Software licensing solution: IBM Tivoli License Manager . . . . . . . . . . . 15 Three-tiered client/server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 17 IBM Tivoli License Manager physical components . . . . . . . . . . . . . . . . 18 IBM Tivoli License Manager logical components . . . . . . . . . . . . . . . . . . 24 IBM Tivoli License Manager software entitlement process . . . . . . . . . . 33 IBM Tivoli License Manager license pool process . . . . . . . . . . . . . . . . . 35 IBM Passport Advantage relationship volume price band level . . . . . . . 47 IBM Passport Advantage aggregation example. . . . . . . . . . . . . . . . . . . 48 IBM Tivoli License Manager physical design example . . . . . . . . . . . . . 58 IBM Tivoli License Manager logical design example . . . . . . . . . . . . . . . 64 Planning overview for IBM Tivoli License Manager . . . . . . . . . . . . . . . . 70 ITLM installation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Install DB2 V7 - DB2 UDB Enterprise Edition . . . . . . . . . . . . . . . . . . . 103 Create DB2 Services - DB2 Instance db2inst1 . . . . . . . . . . . . . . . . . . 103 Administration Server screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 IBM WebSphere Application Server configuration window . . . . . . . . . 106 IBM WebSphere Application Server Admin console . . . . . . . . . . . . . . 109 Installation type: Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Confirmation of installation options Administration server. . . . . . . . 111 Administration Server in WebSphere Administration Console . . . . . . . 112 Add host alias for port 443 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Type of installation: Runtime server. . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Runtime server installation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Runtime server communication options . . . . . . . . . . . . . . . . . . . . . . . . 122 Confirmation of installation options Runtime server . . . . . . . . . . . . 123 Tivoli Runtime server in WebSphere administration console. . . . . . . . 124 Select customer to register a Runtime server . . . . . . . . . . . . . . . . . . . 128 Register first Runtime server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Runtime server form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Server is registered (plugged in) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Select DB2 Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Confirmation of installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Runtime server in WebSphere administration console . . . . . . . . . . . . 140 Typical implementation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Creating a customer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Providing customer details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Creating a customer/license administrator account . . . . . . . . . . . . . . . 153

Copyright IBM Corp. 2003. All rights reserved.

ix

5-5 5-6 5-7 5-8 5-9 5-10 5-11 5-12 5-13 5-14 5-15 5-16 5-17 5-18 5-19 5-20 5-21 5-22 5-23 6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 6-10 6-11 6-12 6-13 6-14 6-15 6-16 6-17 6-18 6-19 6-20 6-21 6-22 6-23 6-24

Updating an administration account. . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Runtime server administrator account details . . . . . . . . . . . . . . . . . . . 155 Registering a Runtime server on the Administration server. . . . . . . . . 157 Registering the Runtime server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Shows the status of the Runtime server . . . . . . . . . . . . . . . . . . . . . . . 159 Adding the Division details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Deploying an Agent on a node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Sample Agent deployment communication letter. . . . . . . . . . . . . . . . . 163 Enter the details for the inventory scan . . . . . . . . . . . . . . . . . . . . . . . . 165 Creating a software entitlement setting for a product . . . . . . . . . . . . . 168 Selecting details of the entitlement settings . . . . . . . . . . . . . . . . . . . . . 169 Provide details for the license pool . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Setting distribution parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 IBM catalog manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Searching the unknown file table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Details to create a new software product . . . . . . . . . . . . . . . . . . . . . . . 180 Information on the new software product . . . . . . . . . . . . . . . . . . . . . . . 181 Select the file to import and update the Master Catalog . . . . . . . . . . . 182 Begin the process to update the Master Catalog . . . . . . . . . . . . . . . . . 183 Parameters for historic snapshot -1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Parameters for historic snapshot -2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Historic snapshot report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Historic snapshot - product / license details - 1 . . . . . . . . . . . . . . . . . . 190 Historic snapshot - product / license details - 2 . . . . . . . . . . . . . . . . . . 191 Historic snapshot - product / license details - 3 . . . . . . . . . . . . . . . . . . 192 Parameters for trend analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Parameters for trend analysis - 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Trend analysis report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Trend analysis report parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Parameters for level analysis - 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Parameters for level analysis - 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Parameters for level analysis - 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Level analysis report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Parameters for software inventory - 1 . . . . . . . . . . . . . . . . . . . . . . . . . 201 Parameters for software inventory - 2 . . . . . . . . . . . . . . . . . . . . . . . . . 203 Software inventory report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Parameters for real-time report - 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Parameters for real-time report - 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Real-time report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Details of software In Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Section of Real-time report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Section of Real-time report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 A typical Tivoli Data Warehouse environment . . . . . . . . . . . . . . . . . . . 213

Introducing IBM Tivoli License Manager

6-25 6-26 6-27 6-28 6-29 6-30 6-31 6-32 6-33 6-34 6-35 6-36 6-37 6-38 6-39 6-40 7-1 7-2 7-3 A-1 A-2 C-1 C-2

IBM Tivoli License Manager warehouse environment . . . . . . . . . . . . . 216 Path to the installation media for the COD. . . . . . . . . . . . . . . . . . . . . . 219 IBM Tivoli License Manager warehouse pack installation . . . . . . . . . . 220 Installation summary window ITLM warehouse enablement pack . 220 IBM Tivoli License Manager Source ETLs . . . . . . . . . . . . . . . . . . . . . . 223 COD_TLMA_Source user ID information. . . . . . . . . . . . . . . . . . . . . . . 223 IBM Tivoli License Manager Target ETLs . . . . . . . . . . . . . . . . . . . . . . 224 COD_TWH_CDW_Target user ID information . . . . . . . . . . . . . . . . . . 225 Schedule COD_m05_Populate_Mart_Process . . . . . . . . . . . . . . . . . . 226 Schedule configuration for COD_m05_Populate_Mart_Process . . . . . 226 Promoting scheduled processes to production status . . . . . . . . . . . . . 227 Logging on to the IBM Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 IBM Console report menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Report list for IBM Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . 232 Summary report: Products Installed by Division . . . . . . . . . . . . . . . . . 233 Extreme case Report: ITLM Agents Installed by Division . . . . . . . . . . 234 ITLM implementation for small environment . . . . . . . . . . . . . . . . . . . . 236 ITLM implementation for medium environment . . . . . . . . . . . . . . . . . . 237 ITLM implementation for large environment . . . . . . . . . . . . . . . . . . . . 238 Software Package for ITLM Agent installation . . . . . . . . . . . . . . . . . . . 255 Software Package variables definition . . . . . . . . . . . . . . . . . . . . . . . . . 257 ITLM Administration server database schema. . . . . . . . . . . . . . . . . . . 285 ITLM Runtime server database schema . . . . . . . . . . . . . . . . . . . . . . . 288

Figures

xi

xii

Introducing IBM Tivoli License Manager

Tables
2-1 2-2 2-3 2-4 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 3-9 3-10 3-11 3-12 3-13 3-14 C-1 C-2 Select License 6.0 price level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Software entitlement example for Microsoft Excel . . . . . . . . . . . . . . . . . 41 Software entitlement example for Oracle Database Enterprise Edition . 45 Software entitlement example for IBM Tivoli Configuration Manager . . 49 Planning for Administrator definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Hardware requirements IBM DB2 UDB Enterprise Edition . . . . . . . . 72 Software requirements IBM DB2 UDB Enterprise Edition . . . . . . . . . 73 DB2 network ports for UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 DB2 network ports for Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Hardware requirements for IBM WebSphere Application Server . . . . . 81 Software requirements for IBM WebSphere Application Server . . . . . . 82 WebSphere network ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Hardware requirements for ITLM Administration server . . . . . . . . . . . . 87 Software requirements for ITLM Administration server. . . . . . . . . . . . . 87 IBM Tivoli License Manager Administration server network port . . . . . . 89 IBM Tivoli License Manager Runtime server network port . . . . . . . . . . 90 Hardware requirements for IBM Tivoli License Manager Agent . . . . . . 93 Software requirements for IBM Tivoli License Manager Agent . . . . . . . 94 TLMA database tables for the ADM schema . . . . . . . . . . . . . . . . . . . . 282 TLMR database tables for the RTM schema . . . . . . . . . . . . . . . . . . . . 286

Copyright IBM Corp. 2003. All rights reserved.

xiii

xiv

Introducing IBM Tivoli License Manager

Examples
4-1 5-1 5-2 5-3 7-1 7-2 A-1 A-2 A-3 B-1 B-2 Changes in the httpd.conf file for UNIX environment . . . . . . . . . . . . . . 115 Setting up the ITLM CLI environment . . . . . . . . . . . . . . . . . . . . . . . . . 176 The expcat command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 The impcat output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 httpd.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Changes in the system.properties file . . . . . . . . . . . . . . . . . . . . . . . . . 250 Software Package definition for ITLM Agent installation . . . . . . . . . . . 259 Installation script for ITML Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Definition file for the ITLM Agent installation . . . . . . . . . . . . . . . . . . . . 273 SSL key files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Server certificate file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Copyright IBM Corp. 2003. All rights reserved.

xv

xvi

Introducing IBM Tivoli License Manager

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-1785 U.S.A. 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 may 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. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. 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. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.

Copyright IBM Corp. 2003. All rights reserved.

xvii

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX 5L AIX Balance CT DB2 Universal Database DB2 eServer IBM IBM eServer Lotus Notes Lotus Notes Perform Redbooks Redbooks (logo) RS/6000 SLC SP SP1 SP2 Tivoli Enterprise Tivoli TME WebSphere XT z/OS

The following terms are trademarks of other companies: ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft 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 United States, other countries, or both. C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.

xviii

Introducing IBM Tivoli License Manager

Preface
One of the main portions of the investment required to set up an IT infrastructure now is related to software. The software Asset Management process is becoming more and more important. From a business point of view, this process includes tasks, such as software and vendor evaluation, contract negotiation, budget planning, hardware compliance analysis, software life cycle planning, and software monitoring. There is a need to know exactly what software is installed within the enterprise and, more importantly, how this software is being utilized within the IT infrastructure. Sometimes, enterprises buy corporate licenses, even though the licenses are procured for some specific divisions and wont be used by the rest of the enterprise. Often, organizations are overbuying licenses so as not to expose the enterprise to the risk of non-compliance usage of software products, simply because they are not able to prove or to evaluate how many licenses they really need or use. The license procurement information must be properly reconciled with the software usage and inventory data. This is the only way an enterprise can tell whether it is paying more license fees than necessary or whether it should buy new licenses to be compliant with the product license policies. Currently, many software vendors leave the responsibilities of licence management to enterprises that buy the products. They often dont provide technical support to maintain or apply the product license policies. Furthermore, the organizations have to prove that they are not using more licenses than they are authorized to. IBM Tivoli License Manager offers a technical way to control and apply the software vendors pre-defined licensing policies. It allows the Administrator to easily manage different products in different ways, reflecting the rules of each product license agreement. The primary objective of this redbook is to introduce the new IBM offering for designing and creating a license management solution, and it is targeted at the technical professional responsible for providing license management services in an IT organization. It can be used as a reference book for the deployment of IBM Tivoli License Manager Version 1.1, guiding you during the planning, installation, configuration, administration, tuning, and general product usage phases, focusing on how to effectively deploy this product in a way that quickly generates real business value for customers.

Copyright IBM Corp. 2003. All rights reserved.

xix

This redbook is a valuable addition to the existing product documentation and should be read in conjunction with the official product documentation, which complements the concepts explained in this book.

The team that wrote this redbook


This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Edson Manoel is a Software Engineer at IBM Corporation - International Technical Support Organization, Austin Center, working as an IT Specialist in the Systems Management area. Prior to joining the ITSO, Edson worked in the IBM Software Group as a Tivoli Technology Ambassador and in IBM Brasil Professional Services Organization as a Certified IT Specialist. He was involved in numerous projects, designing and implementing systems management solutions for IBM customers and Business Partners. Edson holds a bachelors degree in Applied Mathematics from Universidade de Sao Paulo, Brazil. John Aronis is an IT Specialist at IBM Canada with the Enterprise Event Management (EEM) team in Toronto, Canada. He has worked in various roles over the last six years with IBM, from Deskside Support, ESM Tools and Development team, to his current role with the EEM team. He holds a bachelors degree from the University of Toronto. Ron Falciani is an Executive Project Manager in SWG at Research Triangle Park near Raleigh, North Carolina. He has several years of experience in hardware and software sales, hardware development management, and hardware and software marketing, including seven years experience in license use management and related IBM strategy and policies development. He is currently chairman of IBM's worldwide License Use Management Project Office. He holds a degree in Electrical Engineering from Duke University. Sebastien Fardel is an Advisory IT Specialist at IBM Corporation - Global Services - Switzerland, acting as a Tivoli Architect in the Performance and Availability, and Configurations and Operations areas. He has been in the IT industry since 1996 and has experience in IT infrastructure management, programming, and systems management area. Aniruddha Parnaik (also known as Ani) is a Technical Executive in IBM Global Services India. He provides technical support in the areas of systems management and system administration. His areas of expertise includes Windows NT and 2000, Microsoft Exchange Server, and Tivoli Enterprise. He holds a masters degree in Computer Systems Management.

xx

Introducing IBM Tivoli License Manager

The team would like to express special thanks to Domenico Di Giulio, Software Engineer - IBM Rome, for his major contribution and support to this book. Thanks to the following people for their contributions to this project: Joanne Luedtke, Lupe Brown, Wade Wallace, Chris Blatchley, and Budi Darmawan IBM Austin, International Technical Support Organization Gabrielle Velez IBM Rochester, International Technical Support Organization Sandra Freudenberg IBM Boulder, IGS SDTC Pierre-Andr Schranz IBM Switzerland Terry Paul, Murray Taylor, James Jones, Paul Jacobs, Yang Fan, Carolanne Graham, Jayne Muise-Brown IBM Canada Ulrik Soerensen IBM Denmark Carlo Romano IBM Rome David Ertl ITLM Product Manager, IBM Austin

Become a published author


Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html

Preface

xxi

Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at:
ibm.com/redbooks

Send your comments in an Internet note to:


redbook@us.ibm.com

Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493

xxii

Introducing IBM Tivoli License Manager

Chapter 1.

Introduction to license management


This introductory chapter focuses on the IBM strategy and technology direction for customers to manage the use of software. It explains the concepts of license use management, the value to the customer and IBM, the underlying technology, and how the technology will be exploited by IBM products. The general goal for IBM is to create a consistent license management system across all its and other vendors' operating system environments giving customers one method for managing software licenses. This chapter discusses: Software License Use Management requirements Asset Management and Asset Protection information License Use Management and License management system concepts IBM viewpoint and approach to License management

Copyright IBM Corp. 2003. All rights reserved.

1.1 Software License Use Management requirements


The topic of software license use management has been discussed and debated, and tools have been developed and redeveloped over the past 15 years or so, with various technologies employed by many companies to fulfill either perceived or requested customer needs and software publisher wants. In an effort to resolve these issues, a customer group initiated a work effort which led to the creation of A Requirement for Software License Use Management, a 1996 document (copyrighted by the international user group SHARE Inc.), which subsequently led to the development of the international standard for license use management, XSLM, from The Open Group. A Requirement for Software License Use Management is available on the Internet at:
http://www.xslm.org/html/Something_about_XSLM/About_XSLM/Original_Requirements/ original_requirements.html

To help put the topic in perspective, the following materials in this section are excerpted from A Requirement for Software License Use Management, which are copyrighted in the License Use Management Project of GUIDE International Corporation, August 29, 1996 , and are included herein with the express permission of the copyright holder: The key factors driving the need for comprehensive license use management are: Escalating software costs The high administrative burden of license compliance control The lack of effective customer control over the use of software Customers must deal with multiple products, from multiple software suppliers, on multiple platforms, with multiple licensing models. Given the exponential growth in complexity, there is a clear requirement for an overall framework for license use management that is: Extensible, flexible and comprehensive Independent of software supplier Independent of platform Independent of operating environment Independent of implementation Adaptable to future technologies

License use management tools, processes, products, and systems must: Meet the needs of both customers and software suppliers Be cost-effective for both customers and software suppliers Provide facilities to define license terms and conditions Record and report use level data Determine, report on, and verify compliance to license terms

Introducing IBM Tivoli License Manager

Allow customers to control and optimize the use of licenses within the terms and conditions of the license policy Customers and software suppliers agree that software charges should directly correspond to the value or expected value of the software. There is, however, no single universal value metric or way of measuring value. The value metric will differ from product to product and even from customer to customer. In addition, software suppliers are entitled to a fair return on their investments and require assurance that their software assets are protected against intentional and unintentional misuse.

Improved price to value


For example, a customer wants to acquire a customer service package for each of its branch offices. Some branches have mainframe systems, some have RISC systems and others have PC networks. The number of users varies greatly by branch so the customer wants a choice of licensing models. The customer wants to manage user authorizations centrally. Finally, corporate headquarters wants to charge back usage based on the number of invoices printed per month. The software supplier offers a choice of licensing alternatives for this product that assures reasonable protection of the software supplier's assets. The software supplier not only offers a choice of licensing models, but also allows customers to acquire generic user authorizations, that is, a user authorization can be applied to any of the three platforms. Additionally, the software supplier has designed the product to collect information on invoices printed as well as information on the number of users.
Price to value: Customer X supplier
Customer Perspective Choice of licensing models Better cost to value relationship Central management of users and operational efficiency Support for multiple use metrics Software Supplier Perspective Improved customer satisfaction Cost recovery and fair return on investment Assurance of asset protection

Reduced administrative burden


As licensing practices have become more diverse and environments more complex, customers have developed costly, people-intensive methodologies to manage software licenses. Customers' license management environments often mirror their operating environments: a hybrid of uncoupled software, some internally developed, others acquired.

Chapter 1. Introduction to license management

This problem is illustrated in the following example: A customer has a mobile workforce where each member has the capability of selecting the software best suited for the territory. All software is acquired and controlled centrally. This results in hundreds of software licenses that must be managed, involving management of keys, if required, and running tallies of the number of licenses to take advantage of discounts. The implementation of license use management tools and processes is key to the customer in a decentralized, multiple platform environment.
Administrative burden: Customer X supplier
Customer Perspective Use staff to develop applications, not tools Capture all data from all applications on all platforms from all software suppliers within a single framework Select applications on the merit of the application and not if it fits into the existing license management tool Cost-effective customer managed use Software Supplier Perspective Use staff to focus on core business competencies Reduced infrastructure required to support keys and product registration Increased probability that customers will acquire the appropriate number of licenses (or authorizations)

Enhanced interoperability
Customers are faced with heterogeneous, distributed computing environments that challenge their ability to monitor and control the use of licensed software. They need the ability to capture use level data to facilitate product acquisition justification, planning and budgeting for software, implementation of charge-back systems to recover software costs, and workload balancing. They also need the ability to ensure that their use of software products complies with license terms and conditions. For example, a customer has hardware servers from two different suppliers installed at two locations at corporate headquarters. This customer has acquired licenses for 150 users of a software product. Performance on one of the servers has been slow, resulting in multiple user complaints. Without access to use level data, the customer is unaware that 125 users are using the server that has the noted performance problems and only 50 users are accessing the other server. The customer is also unaware that 175 users, which is 25 users beyond the entitled number, are using the application. With the capture of and access to use level data, the customer will have the data necessary to charge the appropriate departments for usage, to balance the workload, and to fairly compensate the software supplier for use.

Introducing IBM Tivoli License Manager

Administrative burden: Customer X supplier


Customer Perspective Balance the workload, resulting in better performance Acquire additional 'user authorizations' (licenses), as needed, to comply with the terms and conditions of the license Charge the appropriate departments for usage Optimize use of licenses (End of excerpt) Software Supplier Perspective Potential for minimizing the overuse of software Improved ability for fair return on investments and cost recovery Increased customer satisfaction

1.2 Asset Management and Asset Protection


More broadly, a primary concern of customers, Asset Management refers to the customers' ability to understand the inventory of software installed. For a more complete solution, the customer often wants to understand the use of that software and its association with the various hardware identifiable boxes together with the relationship of that data to a customer's contracts with vendors regarding software acquisition and entitlements. Software shipments from vendors (physically and online), software inventory records for asset and tax purposes, software deployment records regarding who is assigned the right to use each piece of software and for how long by individual and/or department and/or identifiable hardware box are also relevant associations in a vibrant Asset Management system. As such, an integrated asset management system manages the physical, financial and contractual information about software assets. It covers the total customer view of its (software) assets, including elements such as product inventory and use that match against entitlement, contracts, purchasing and accounts payable. The customer aim of good asset management is to: Avoid compliance issues Achieve maximum use of the assets (software) at minimum cost Take advantage of knowledge of product use levels and contract expiration dates Similarly, as a primary concern of software vendors, Asset Protection refers to the vendors' ability to ensure the customers' use of the vendors' products is in compliance with the contract terms and conditions, the pricing models, and the

Chapter 1. Introduction to license management

agreed contractual entitlements. This would typically be managed or controlled through license management tools. The basic challenge to balance both the customers' and the vendors' needs is the need to bridge between contractually defined entitlement levels and the real physical customer IT environments, where actual license deployment and use takes place. This ideally implies on one side a basic requirement for detailed, well-maintained record of entitlements, inventory and use for the customer, and on the other side the presence of license management tools in the customers' IT environment capable of monitoring and counting in a way reflecting the contractually defined rules.

1.3 License Use Management


License Use Management includes tools and processes to: Enable, without serious risk of revenue loss to vendors, the implementation of products priced on their use rather than on potential processor capacity, and so on (for example, the number of concurrent or registered users or resources) Provide customers with tools to manage the access to and usage of software products Enable, without risk of revenue loss to vendors, supply before buy merchandising (for example, trial, pre-packaged, pre-loaded or electronically transmitted software) License Use Management, correctly implemented, serves the interests of both customers and software vendors. License Use Management assists Customers by enabling use-based charging and: Collecting basic use statistics and monitoring use levels Informing customers when entitled use levels have been or are about to be exceeded Measuring resource use for the purpose of establishing software charges Generating reports and statistics on use Providing data to both enable customer charge back systems and leverage software volume Opportunities Providing a means to demonstrate license compliance to external and internal auditors License Use Management assists software vendors by:

Introducing IBM Tivoli License Manager

Adding assurance that intellectual property is protected and that software licenses are used within entitled limits Enabling software family packaging and supply before buy merchandising Potentially reducing software distribution costs Regarding license use management, generally IBM's announced direction is to implement self-compliance, that is, Customer Managed Use for IBM-owned use-based priced software products, whereby a customer will not need to request a use-key from IBM which controls the use-levels for which the customer is licensed (a process and license management tool capability known as vendor managed use). During an enrollment process the customer administrator is asked to enter the overall licensed use-level for each product and then the customer can track product use with the license management system by using the administrative tools supplied. Other software contains the ability to communicate product use with the license use management system, allowing a customer to be able to receive information about the licenses used (for example, the number of users or number of resources used or managed) by these products. Changes and/or usage data is logged in special files, which can be used for internal and external audit purposes. A customer can also use the license use management administrative tools to receive reports of use and compare this information to the use levels that have been licensed. As a result customers are able to take action to either increase or decrease product use and license use payments to their suppliers.

1.4 License management system


A license management system controls or allows the customer to control the execution of a product based on the entitlement for which the customer has contracted. In the context of widely distributed products, Web-based and client-server implementations, and in the presence of a wide variety of pricing models, the ability of a customer to manage the installation is virtually impossible without a tool. Therefore, a well-conceived license management tool will allow customers to operate within their entitlements and allow vendors to recover revenue which would have been lost without such a tool, independent of customers' basic honesty. An effective license management system, designed to support both the customer's asset management needs and the vendor's asset protection wants, typically requires initial product enrollment in the form of an electronic file, or key, with data relevant to the entitlement agreed to by the customer, in a license management system repository. At product execution time, a license server is asked to validate that the request is within the entitled levels. The license

Chapter 1. Introduction to license management

management system informs the product of the status; and the product, in an ideal implementation, executes accordingly. The license management system does not directly effect the product execution. It is the product that decides to execute or not, based on information received from the license management system and the license management policy of the vendor. Relevant data is then logged to allow effective customer management and audit capability. Within that context, the following brief descriptive terms are commonly used:

Vendor policies
These policies can be categorized as follows: Customer Managed Use (CMU) This vendor policy requires the customer to set the entitlement against which the license management system will manage compliance. This policy allows two types of implementation, hard and soft compliance. Vendor Managed Use (VMU) Vendors provide customers with product keys reflecting the customer entitlement, against which the license management system will manage compliance. This policy has only one implementation hard compliance. The purpose is vendor asset protection, affording the customer no latitude in managing the installation.

Compliance
Various approaches may be perceived in achieving customer compliance: Trust Completely trust the customer to manage without tools. Soft The customer is provided tools to manage by warning if an (often self-declared) entitlement level is exceeded. An audit trail is established through a secure, audit log of all relevant events. Hard The customer, through use of license management tools, is precluded from non-compliant use. Hard and soft compliance are implemented in the same way with respect to the license management system, which simply determines whether a requested use authorization is within the stated entitlement. It is the reflection of the vendor policy (hard or soft compliance) within the application product being managed that dictates whether the product will execute or not, based on the response from the license management system to the request to execute. Therefore, with Hard

Introducing IBM Tivoli License Manager

compliance, if the requested execution exceeds the entitlement, the product will not go into execution. If, on the other hand, the vendor policy is Soft compliance, under the same circumstance, the product will go into execution anyway and inform the license system of this fact for logging in its audit database.

1.5 Conclusion
In any definition of asset protection schema and related license management policies, a number of factors should be considered. The challenge for the vendor is to achieve the optimal balance between maximizing revenue recovery against both the administrative cost for the vendor and the potential customer satisfaction impacts due to cost, operational burden, and perceived intrusion. In addition, the balance must consider practical aspects of the business models, such as requirements on vendor operational processes, availability and quality of collected data, rolls of the Business Partners, and the competitive environment. Care must be taken to ensure that any attempt to eliminate software product over-use (willful or overt) will likely require implementation of additional control measures that are not only costly but will also be likely to place an unwarranted burden on all customers. Compliance enforcement should also serve to protect the interests of the compliant customer, and should not willingly favor the non-compliant customer. Another basic parameter to consider is customer and business partner satisfaction. The customer satisfaction considerations for a given compliance enforcement schema will need to include both tangible factors, such as the administrative burden and potential operational limitations imposed, but also less tangible factors, such as the potential perception of a scheme as being intrusive or spying" on the customer. For some customers imposing any level of license management discipline, however reasonable from a vendor's view, might be perceived as painful; while for others, the technical personnel making, for instance, operational capacity allocations potentially affecting software compliance may not be those that manage software entitlements or acquisitions. The compliance enforcement schema therefore needs to be sufficiently robust to cover the great span in the (broad) customer base in terms of business processes and organization, technical capabilities, and particular license management practices. Further, the vendor's asset protection process requirements imposed on the customer need to be balanced as to appear reasonable and a logical component of the over-all business model and the benefits the customer receives from it. A strong logical correlation to the business model will also alleviate at least the rational concerns over potential vendor "spying."

Chapter 1. Introduction to license management

With the advent of IBM Program License Agreement (IPLA), software terms and conditions and pricing models are geared to reflect more directly the customer-perceived value of software, together with capacity-on-demand hardware for distributed systems products. As in the case of z/OS and Workload License Charges (WLC), the dynamic aspect of software execution and pricing demands a consistent, easy-to-use, cross-platform license management tool. The IBM direction to fulfill this quintessential business need is IBM Tivoli License Manager. Ultimately, the customer will be looking for value in terms of help to manage over-all software costs; a successful schema and tool set must therefore provide support for the customer's own asset management processes while ensuring the vendor's asset protection. It is with this intent that IBM Tivoli License Manager is offered.

10

Introducing IBM Tivoli License Manager

Chapter 2.

IBM Tivoli License Manager general overview


IBM Tivoli License Manager is a Web-based solution that faces the challenge to support the complex software asset management process. It provides the software metering and license allocation services on different host platforms. This chapter contains the following: An overview of IBM Tivoli License Manager explaining the main benefits and defining the main functions of IBM Tivoli License Manager. A detailed description of the Physical and Logical components of IBM Tivoli License Manager. An introduction to the Web and XML interfaces provided with the product. A complete overview of the License management process and realistic examples about the Microsoft, Oracle and IBM Tivoli Software licenses management process.

Copyright IBM Corp. 2003. All rights reserved.

11

2.1 IBM Tivoli License Manager overview


License Management is one of the many processes involved in the delivery of IT services. By having a real-time control on software assets, an enterprise could understand exactly what resources are needed to support its business. Currently the main portion of the investment required to set up an IT infrastructure is related to software, not to hardware. Figure 2-1 on page 13 shows an example of an ineffective licensing process for a fictitious company called ACME enterprise. ACME enterprise needs to buy the most recent version of the CSI HR software that has already been tested and deployed in about 100 machines of both the HR and Finance departments of the ACME enterprise. The pricing policy for the CSI HR software is based on the number of concurrent users. Since the IT department of ACME enterprise, in this scenario, is not able to control how many licenses are concurrently in use by the HR and Finance departments, a total of 100 licenses need to be acquired as the ACME enterprise wont be able to prove the makers of the CSI HR software how many licenses will be used concurrently.

12

Introducing IBM Tivoli License Manager

CSI HR Software Sales Specialist

4
The IT Operator starts making an Inventory but as the Software is installed on all machines, the IT Operator requests 100 licences because he could not control how many license are used concurrently. IT Operator

20 users in the HR Division

1
There is a need to buy the new version of the CSI HR Software

6
The IT Manager signs the license contract for 100 licenses.

3
The IT Administrator asks the IT Operator to count the number of required licenses for this new version. 80 users in the Financial Division

The IT Administrator, based on the information of the IT Operator, requests 100 licenses.

2
IT Manager

The IT Manager asks the IT Administrator for the number of required licenses for this new version.

IT Administrator

Figure 2-1 Software licensing requirements

IBM Tivoli License Manager (ITLM) can help enterprises meet the software assets management objectives by accomplishing, often silently, a certain number of tasks described as follows: Collecting information about installed products using an inventory scan technology. Identifying the start and the stop of a software on any machines. Comparing the installed, used and procured licenses. Metering software usage even for products that have no license requirements. Informing Administrators when license usage reaches a defined level. Enforcing license agreements by refusing to start a application in case there are no licenses available. Assigning pool of licenses to users and/or machines.

Chapter 2. IBM Tivoli License Manager general overview

13

Maintaining a historical software usage information and providing reports allowing the planning of license needs. Providing real-time reports for inventory and software usage information. Continuing with our example using the ACME enterprise, as shown in Figure 2-2, one year has past since ACME enterprise acquired the CSI HR software and now, it is time to negotiate the maintenance contract for this software. The maintenance pricing policy is still based on the number of concurrent users. During the past year, ACME enterprise has deployed the IBM Tivoli License Manager solution. Using this technology, the IT Administrator doesnt need to ask the IT Operator to make an inventory, because IBM Tivoli License Manager makes it automatically. Furthermore, as IBM Tivoli License Manager is able to analyze the start and the stop of software, the IT Administrator analyzes, within the reports provided by IBM Tivoli License Manager, that the average of the concurrent users is 45. So, the maintenance contract could be signed for only 45 licenses instead of 100. This way, ACME enterprise has saved the cost of 55 licenses that have never been used.

14

Introducing IBM Tivoli License Manager

CSI HR Software Sales Specialist

ITLM collects usage of CSI HR using inventory information and Software entitlement.

5
ITLM stores all information in a RDBMS and can provide historical or/and realtime reports.

20 users in the HR Division

1
It is time to negotiate the maintenance contract for the 100 licences of CSI HR Software

7
The IT Manager could negotiate the maintenance contract for only 45 licenses instead of 100.

3
The IT Administrator defines the Software entitlement in ITLM for CSI HR.

6
The IT Administrator reads in the report that only 45 licenses are concurrently used.

80 users in the Financial Division

IT Manager

The IT Manager asks the IT Administrator if the 100 licenses are still needed.

IT Administrator

Figure 2-2 Software licensing solution: IBM Tivoli License Manager

An IBM Tivoli License Manager solution can be seen as a three part solution: IBM Tivoli License Manager Components IBM Tivoli License Manager Software Entitlement IBM Tivoli License Manager Reports

IBM Tivoli License Manager Components


The IBM Tivoli License Manager solution is composed of two types of components: Physical and Logical. This is discussed in more detail in 2.2, IBM Tivoli License Manager physical components on page 16 and 2.3, IBM Tivoli License Manager logical components on page 23.

Chapter 2. IBM Tivoli License Manager general overview

15

IBM Tivoli License Manager Software Entitlement


The IBM Tivoli License Manager provides a way to create software entitlement and licensing policies for any kind of software. This allows you to strictly apply licensing contract policies or to measure software usage. Software entitlement is part of the IBM Tivoli License Manager logical components and is detailed in 2.5, Licence Management process on page 30.

IBM Tivoli License Manager Reports


The IBM Tivoli License Manager solution provides some predefined reports and a full integration with the IBM Tivoli Data Warehouse product. Reports are part of the IBM Tivoli License Manager Logical components and are introduced in 2.3, IBM Tivoli License Manager logical components on page 23. Detailed information for Reports will be provided in Chapter 6, Reporting with IBM Tivoli License Manager on page 185.

2.2 IBM Tivoli License Manager physical components


A common way of organizing software to run on distributed systems is to separate functionality into two parts: clients and servers. A client is a program that uses services provided by other programs called servers. The client makes a request for a service, and a server performs that service. Server functionality often involves some sort of resource management, in which a server synchronizes and manages access to the resource, responding to client requests with either data or status information. Client programs typically handle user interactions and often request data or initiate some data modification on behalf of a user. A common design of client/server systems uses three tiers: a client that interacts with the user, an application server that contains the business logic of the application, and a resource manager that stores data. In the context of an IBM Tivoli License Manager solution, which is also based on a three tier architecture, an Administration server acts as the resource manager, a Runtime server as the application server, and agents as clients, as shown in Figure 2-3.

16

Introducing IBM Tivoli License Manager

Tier 3

Tier 2

Tier 1

DB2 RDBMS

Agents (Clients)

Runtime server (Application server) DB2 RDBMS (Resource) Administration server (Resource Manager)
DB2 RDBMS

Agents (Clients)

Agents (Clients)

Runtime server (Application server)

Agents (Clients)

Figure 2-3 Three-tiered client/server architecture

The IBM WebSphere Application Server provides the middle tier in this architecture, allowing clients to interact with data resources as a Relational Database Management System (RDBMS). IBM WebSphere Application Server is an environment for open distributed computing. Users and processes on a wide variety of platforms can interact by using the facilities provided by WebSphere. Both the IBM Tivoli License Manager Administration and Runtime servers are applications running on top of IBM WebSphere Application Server. These applications consist of object-oriented business logic that use a RDBMS for data storage. An application running on IBM WebSphere Application Server consists of the following components, each performing a different function: HTML and JSP pages providing the user interface and program flow. Enterprise beans containing the applications business logic that handle transactional operations and access to databases. Servlets coordinate work between the other components of the application. They also can dynamically generate Web page contents. JavaBean components enable the other types of components to work together.

Chapter 2. IBM Tivoli License Manager general overview

17

Relational Databases implement persistence and query functions for enterprise beans. In the context of IBM Tivoli License Manager, the RDBMS is provided by IBM DB2 Universal Database Enterprise Edition. Figure 2-4 shows you the complete IBM Tivoli License Manager physical architecture and components. In addition to that, it also describes the complete data flow between the components of each tier as well as between the internal component of the IBM Tivoli License Manager Administration and Runtime servers.

Web Browser B M N

Web Browser

HTTP(s) HTTP(s) A F L HTTP(s)

HTTP

C E G I K D H J O

HTTP Server WebSphere Plugin HTTP(s) IBM WebSpere Application Server Administration Server JDBC IBM DB2 WAS40 ITLM Administration server TLMA JDBC

HTTP Server WebSphere Plugin HTTP(s) IBM WebSpere Application Server Runtime Server JDBC IBM DB2 WAS40 ITLM Runtime server TLMR JDBC Agent

Scan Engine Licence Usage Control Process

ITLM Agent

Master Catalog

Runtime Catalog

Agent Catalog

Figure 2-4 IBM Tivoli License Manager physical components

Figure 2-4 is discussed in more detail in the following sections.

18

Introducing IBM Tivoli License Manager

2.2.1 IBM Tivoli License Manager Master Catalog


IBM Tivoli License Manager maintains a Master Catalog where details of all the products that can be monitored are stored. This Catalog resides on the Administration server and a subset of it is periodically downloaded to each Runtime server. This subset of the Master Catalog, called Runtime Catalog, only includes those entries from the Master Catalog that relate to products that have been discovered running on nodes by Agents that are assigned to the Runtime server. A copy of the Runtime Catalog is also downloaded to each node where the Agent is installed. The IBM Tivoli License Manager Catalog Manager application enables you to add entries to the Master Catalog, using information from the following sources: The Unknown file table, which contains entries for all applications that were detected by Agents but that were not already in the Master Catalog. The IBM Tivoli License Manager Catalog updates that will be provided by IBM on a regular basis. For information on managing the IBM Tivoli License Manager Master Catalog, refer to 5.9, Managing software product components on page 174.

2.2.2 Network communication


This section provides information regarding the protocols used to communicate between each different component that makes up the IBM Tivoli License Manager solution.

Support applications
As shown in Figure 2-4 on page 18, the IBM Tivoli License Manager solutions are composed of the following support applications: HTTP Server IBM WebSphere Application Server IBM DB2 Universal Database Enterprise Edition An IBM Tivoli License Manager solution mainly uses HyperText Transfer Protocol (HTTP) for its communications. In some cases, HTTPs, which is a secure HTTP, can be used to secure the communication between the Administration server and the Runtime server. The communication among the Web Browsers and the Administration and Runtime servers can also be encrypted. However, there is no possibility of using HTTPs to secure the communication between Agents and Runtime servers. The HTTP requests made by an Agent or by a Runtime server are first received by an HTTP server which must be installed on each Administration and Runtime

Chapter 2. IBM Tivoli License Manager general overview

19

server. The HTTP server must forward the HTTP request either to the Administration Application server if the request is issued by a Runtime server or to the Runtime Application server if the request is issued by an Agent. To allow such transfer, the IBM WebSphere Application Server application installs a WebSphere plug-in on the HTTP server. This plug-in is able to transfer the HTTP request to the IBM WebSphere Application Server. The following link provides more information about the WebSphere plug-in:
http://www7.software.ibm.com/vadd-bin/ftpdl?1/vadc/wsdd/pdf/presents/WS40ST08.p df

IBM Tivoli License Manager Administration and Runtime servers, as well as the IBM WebSphere Application Server Administration server need to store data in a RDBMS. To access this RDBMS, IBM WebSphere Application Server uses the Java DataBase Connectivity (JDBC) technology. The following link provides more information about JDBC:
http://java.sun.com/docs/books/tutorial/jdbc/

IBM Tivoli License Manager components


As we can see in Figure 2-3 on page 17 IBM Tivoli License Manager uses a three tiered architecture. Each tier is composed of the following elements: ITLM Agent (tier 1) ITLM Runtime servers (tier 2) ITLM Administration server (tier 3) The communication processes between the IBM Tivoli License Manager elements are mainly upcalls, that is, communication between the ITLM Agents and the ITLM Runtime server is often initiated by the ITLM Agents, and the communication between ITLM Runtime server and ITLM Administration server is mainly triggered by the ITLM Runtime server. The downcall is only used by the Administration server only to inform a Runtime server that an update of the licensing information is available for download. So, the Runtime server can trigger a new call without waiting for the next scheduled one to happen. Generally, the Runtime server downloads any update from the Administration server by performing an update request. There are separate communication services used to update information of different types, and the Runtime server downloads only the data that have been changed after the last synchronization call. The update rate for each service could be configured on the Runtime server and all the communication is handled on the same port (normally 80). Agents periodically request the updated information to the Runtime server and download only the data that have been changed after the last synchronization call. As already mentioned for the communication between the Administration

20

Introducing IBM Tivoli License Manager

and Runtime server, there are separate communication services used to update information of different types. The update rates could be configured on the Runtime server and are common for all Agents connected to the same server. After an inventory scan, upcalls are made by Agents to the Runtime server in order to store the result of the scan.

2.2.3 Data flow


To fully understand the Physical architecture of an IBM Tivoli License Manager solution, it is important to know, in detail, the whole Data flow between the different elements of IBM Tivoli License Manager. Based on the Figure 2-4 on page 18, here we detail each step from the Runtime servers and Agents registration process data flow to the license management process data flow. The legend used in Figure 2-4 on page 18 is explained as follows: A B At the very first time the Runtime server starts, it sends to the Administration server, only one time, a Registration request. Once the Runtime server is registered, the Administration server sends the respective portion of the ITLM Database. This information is stored into the local Runtime Database. As the Runtime server is only in charge of part of the environment, only information that concerns that Runtime server is transferred. For more information about Data stored in the Administration Database, refer to Administration server on page 24. The Administration server also downloads a subset of its Master Catalog, which will become the local Runtime Catalog. This one contains only the products that will be discovered by the Agents and will be updated during each Runtime server update request. At the very first time the ITLM Agent starts, it sends to the Runtime server Registration request. This operation happens only once. After the Agent is registered, the Runtime server transfers to the Agent the Agent setting file, defined specifically for this Runtime server. It also downloads the License monitoring Topology and the Runtime Catalog that will be used during the inventory scanning and license control processes. For more information about monitoring Topology, refer to Customer on page 27. All of this information will be updated during the Agent update request. The Agent starts an inventory scan, if configured, on a regular basis. At the end of the scan, the Agent performs an update request to upload the inventory data to the Runtime server database. Software that does not match any entry in the local Catalog is classified as

C D

Chapter 2. IBM Tivoli License Manager general overview

21

Unknown. This information can later be used to update the Master Catalog. F The Runtime server then performs an update request to upload new Agents registration and Agents inventory information. The update rate for each service can be configured on the Runtime server. Every so often, the Agent performs an update request to know if there is something to download from the Runtime server. The update rate for each service is configured on the Runtime server. The Runtime server downloads all updates, if any, to the requesting Agents. If a new version of the ITLM Agent code is available, it will be automatically downloaded and installed on the requesting Agents at this time, depending on configuration of the Runtime server. Whenever an application is started on the Agent, the Agent informs the Runtime server about the software usage and performs, depending on configuration of the License control in the License pool, a License request. This operation happens even if the application is not part of the Catalog. With this information, the Runtime server has the control, in Real Time, of the software usage in all Agents. The Runtime server responds to the License request and depending on configuration, decides whether the application is allowed to run on the Agent or not. Whenever an application is deployed/installed on the machine where the ITLM Agent is running, the Agent informs the Runtime server about the new software release. Runtime server will send this information back to the Administration server at regular intervals. Every so often, the Runtime server performs an update request to find out if there is something to download from the Administration server. The update rate for each service is configured on the Runtime server. The Administration server then downloads all the updates, if any, to the requesting Runtime server. Every so often, the Administration server informs all Runtime servers that an update of the Licensing information, is available for download. This is the only case where the Administration server contacts the Runtime servers. After receiving the notice from the Administration servers, Runtime servers trigger a new call to download Licensing information without waiting for the next scheduled request.

M N

22

Introducing IBM Tivoli License Manager

2.3 IBM Tivoli License Manager logical components


Understanding the IBM Tivoli License Manager logical components helps with the definition of the supervising structure that will help you to: Manage and organize, in a logical point of view, the monitored components of IBM Tivoli License Manager Define software entitlements helping to specify rules to be used on monitored software uses Each ITLM logical component must belong to a Customer, with the exception of the ITLM Administration server, which covers all Customers. A Customer is the highest level of the ITLM logical architecture and, whenever you log on to the Administration server, you must select a Customer in order to manage only its Licenses and supervising structure. A supervising structure, or mainly called Topology, is composed by two types of components: Components that form the monitoring structure. For each Customer, a monitoring structure must be defined. This structure includes the following Logical components: Runtime servers Runtime servers must be first registered with the Administration server before they can be used. Agents Agents must be deployed on Nodes that are to be monitored. You must decide on the distribution of Agents among the Runtime servers to make the most efficient use of resources. Divisions Divisions are used to divide Agents into logical groupings. Components that record demographic information. For each Customer, data regarding demographic information can be stored in the Administration server Database. This information includes the following Logical components: Nodes A Node is a machine that needs to be monitored. Users A User is a person able to start applications on the Nodes. A software entitlement is the way to define which software you want to manage within your enterprise by providing basic information, such as product name,

Chapter 2. IBM Tivoli License Manager general overview

23

version, and so on. It is the starting point of software monitoring, because you can decide to get statistics of a specific software usage or to strictly apply licensing rules to force the appliance of business licensing requirements. These rules are defined in the license pools which are part of the software entitlement logical component. Licence pools can only be applied to a specific software entitlement and can not be used as reference for others entitlements. Figure 2-5 provides you with an overview of all ITLM logical components and the links between them.

Administration server

Administrator

Customer

Inv. Schedule Runtime server Division Nodes

End Users

Software Reports Software Entitlement

Agents

Figure 2-5 IBM Tivoli License Manager logical components

Figure 2-5 is discussed in more detail in the following sections.

Administration server
An IBM Tivoli License Manager environment can only have a single Administration server. This server is the core of the solution and works as the central arbitrator within the license management strategy. It can manage more than one
Administration server

24

Introducing IBM Tivoli License Manager

Customer and therefore is not part of a Customers topology, as seen in Figure 2-5 on page 24. This server provides the following functions: Stores and maintains the available information about products catalog, license agreements, license usage, license pool and Customer information in a central repository organized by Customer. Gathers the software usage and installation data collected by the Agents and processed by the Runtime server. Provides a Web interface that can be used to perform administration tasks and produce historical reports of license usage and nodes inventory over time. Forwards e-mail notifications to the licenses administrators upon detection of unlicensed usage of software products and/or information about the status of the Administration server itself. Section 3.1.1, ITLM Administration Server considerations on page 52 provides information on planning the deployment of ITLM Administration servers.

Runtime server
An IBM Tivoli License Manager environment must have at least one Runtime server but more servers can be set up to scale the solution and cover large sites. They are managed directly by the Administration server and they are in charge of the Agents registration process and Agents License Runtime server request. Furthermore, a Runtime server can only be attached to one Customers Topology and therefore only manages the Agents of this Customer. So, a Runtime server is a part of the Customers topology. Each Runtime server provides the following functions:

Receives the results of software scans from the Agents and processes them to build a view of the software installed on each machine. Assigns, releases or blocks at run time the licenses that have been distributed to the server, according to the rules defined by the license procurement information. Monitors the activity of the Agents, notifying the system administrator when an Agent has been stopped or removed from the system. Provides a Web interface that can be used to produce real time reports of license usage. Forwards e-mail notifications to the licenses Administrator upon detection of events that have occurred on the server and its Agents. Section 3.1.2, ITLM Runtime Server considerations on page 52 provides information on planning the deployment of ITLM Runtime servers.

Chapter 2. IBM Tivoli License Manager general overview

25

Agents
An Agent is a part of the Customers Topology. A small agent footprint must be deployed on each of the Customer machines that are to be monitored by IBM Tivoli License Manager. Agents provide the primary interface of License Agents management. Agents run a very small amount of software, less than 400 Kb of executable on all platforms. Each Agent performs silently and without any user intervention the following functions: Performs a complete inventory of the target machine, providing the Runtime server with the software and hardware information collected. Identifies the starting and the stopping of a software products and communicates this information to the Runtime server so that licenses can be assigned or released at run time. Periodically checks for a software upgrade, so that the user intervention on the target machine is not needed. When planning a IBM Tivoli License Manager deployment, Agents are part of both physical and logical design phases. Refer to 3.1.2, ITLM Runtime Server considerations on page 52 for more information regarding Agents from a physical design point of view and to 3.2.4, Monitored Nodes considerations on page 61 regarding Agents from a logical design point of view.

Administrator
An ITLM Administrator is a user who manages the entire IBM Tivoli License Manager solution or who is in charge of a specific Customer. The ITLM Administrator must be in charge of at least one Customer, but can be responsible for Administrator many different ones. An Administrator is either defined at the ITLM Administration server level and is able to manage the Customer, or is defined at a ITLM Runtime server level and is only able to produce real time reports for the Agents registered to that server. A default ITLM Root user, named tlmroot, is defined by the application and cannot be renamed. This login, and only this, is used to create new Administrators and new Customers. An Administrator performs the following tasks for a Customer: Manages the license management environment including registration of Runtime servers, Divisions, Nodes and Agents. Manages the license entitlement and license pool definition. Produces reports. Receives and reacts to notifications of events.

26

Introducing IBM Tivoli License Manager

Section 3.2.5, Administrator considerations on page 62 provides observances when planning the deployment of an IBM Tivoli License Manager environment.

Customer
As seen in Figure 2-5 on page 24, a Customer is the owner of all components of its topology, which consists in Runtime Servers, Divisions, Nodes, Agents and Users. Furthermore, Reports, Inventory and software entitlements are part of the Customer Customer organization. As soon as an Administrator is logged on to the IBM Tivoli License Manager environment through one of the Web interfaces, he/she will be asked to select the Customer he/she is in charge of in order to access the specific Customer working area. From there, any changes made on any objects are only applied to that current Customer configuration. Customers are part of the logical design of an IBM Tivoli License Manager solution. Additional information is provided in 3.2.2, Customer considerations on page 60.

Division
A Division is part of the Customers Topology. It is used to group Agents so that they can be logically organized. Division can be selected for some Administration tasks, for example, to define different frequencies of inventory scans, to create specific reports and, especially, to limit access to license pools to a specific group of Agents.

Division

Divisions are part of the logical design of a IBM Tivoli License Manager solution. Additional information is provided in 3.2.3, Division considerations on page 61.

Nodes
Nodes are part of the Customers Topology. A Node is a physical asset representation in an IBM Tivoli License Manager structure. It can be any workstation or server of a Customer organization. For IBM Tivoli License Manager, the Nodes details, such as the location or description fields, of a Node should be related to the Asset Management and/or financial information implemented at the Customers site. This information can be imported from an Asset Management tool or from an Inventory solution already deployed using the IBM Tivoli License Manager XML interface. For more information about the IBM Tivoli License Manager XML interface, refer to 2.4.2, XML interface on page 30. It is important to notice that each Agent of the Customer's Topology will have a corresponding Node. If a Node doesn't already exist for an Agent, during the Agent registration process, a new Node is

Chapter 2. IBM Tivoli License Manager general overview

27

automatically created in the IBM Tivoli License Manager. However, if a Node is manually created, the Agent is not automatically registered and associated to that Node. For additional information on Nodes and the planning phase of your IBM Tivoli License Manager deployment, refer to 3.2.4, Monitored Nodes considerations on page 61.

Users
Users are part of the Customers Topology. The details of a User correspond to the ones defined for the specific Operating System login used by an end user. License pools restrictions can be applied on Users and, therefore, will allow or will not allow a User to start applications on monitored End Users nodes. Additional information can be found in 5.7.5, Adding application users on page 166.

Inventory Schedule
Before performing Licensing control on an Agent, IBM Tivoli License Manager needs to know what software is installed on that particular node. Inventory scan can be scheduled to repeat at regularly, defined intervals. However, it is planned by Division and, therefore, is related to one Customer only.

Inv. Schedule

Inventory Schedule is part of the Administration Design and more information can be found in 5.7.4, Scheduling an inventory scan on page 164.

Software Entitlement
A software entitlement is a set of rules that defines how software is monitored and under which Licenses conditions are allocated. These rules can be applied on the entire Customer organization or only on a particular Division, Node Software Entitlement or Agent of a specific Customer. Therefore, one software entitlement cannot be applied across multiple Customers. One important part of the software entitlement is the license pool definition. A license pool is a set of licenses for a specific product that are administered as a group with a set of rules governing thresholds, hard stops, license allocation to multiple sessions of the same product, and the availability of the product to Users and Nodes. Software Entitlement is discussed in more detail in 2.5, Licence Management process on page 30, and more information regarding the creation of a software entitlement is provided in 5.8.2, Selecting a product for entitlement or license pool maintenance on page 167.

28

Introducing IBM Tivoli License Manager

Software Reports
IBM Tivoli License Manager provides two types of reports: real-time and historical information. Real-time reports can be obtained from the Runtime servers and provide information about software usage on a monitored node. Software Reports Historical reports can be obtained only from the Administration server and provide information about software usage for a specified period of time. As shown in Figure 2-5 on page 24, reports are related to a specific Customer. In addition to the reports provided by the Administration and Runtime servers, IBM Tivoli License Manager provides a full integration with IBM Tivoli Data Warehouse. This integration offers additional reports and the capability to create your own. For more information about software Reports, refer to Chapter 6, Reporting with IBM Tivoli License Manager on page 185.

2.4 IBM Tivoli License Manager interfaces


IBM Tivoli License Manager provides two different interfaces for license management and administration purposes. These are: The Web interface, used to manage the IBM Tivoli License Manager environment. The XML interface, used to exchange IBM Tivoli License Manager information with other applications.

2.4.1 Web interface


IBM Tivoli License Manager provides Web interfaces that allow access to the Administration and Runtime servers without the need to install a client software on administration machines; only a Web browser is required. Both the Administration and Runtime servers provide Web interfaces. All administration and licensing tasks are performed using the Administration server Web interface. This interface can also be used to browse aggregated or detailed reports of software usage and inventory information. The Runtime server Web interface only allows you to browse real-time usage reports. Using a Web browser, you access the Web interfaces using the following URLs: For Administration server
http://<Administration server name>:<port>/slmadmin/login

For Runtime server


http://<Runtime server name>:<port>/slmruntime/login

Chapter 2. IBM Tivoli License Manager general overview

29

Note: The default HTTP port is 80, for a non-secure connection; and 443, for a secure connection. If you plan to use the SSL encryption, you have to specify https instead of http. When logging in for the first time, you must use the default root user which is tlmroot and the default password which is system. For more information regarding how to use the Web interface, refer to IBM Tivoli License Manager License Administrators Guide, GC23-4833

2.4.2 XML interface


Extensible Markup Language (XML) describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. XML is an application profile or restricted form of the Standard Generalized Markup Language (SGML). XML is a project of the World Wide Web Consortium (W3C, http://www.w3.org), and the development of the specification is being supervised by their XML Working Group. The IBM Tivoli License Manager XML import feature allows you to import department, user, and node information from an external Asset Management repository using XML. This provides a way to match the IBM Tivoli License Manager software usage and inventory information shown in IBM Tivoli License Manager reports to physical assets and people information. IBM Tivoli License Manager also provides the Document Type Definitions (DTDs), which describe the structure and data within the XML documents, to export the following reports: The software usage snapshot The software usage trend analysis The software usage level analysis The software inventory information For more information regarding these DTDs, refer to the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.

2.5 Licence Management process


As mentioned previously in this chapter, the main portion of the investment required to set up an IT infrastructure is related now to software. Regarding this information, the software Asset Management process is becoming more and more important. In a Business point of view, this process includes the software

30

Introducing IBM Tivoli License Manager

and vendors evaluation, contracts negotiation, budget planning, hardware compliance analysis, software life cycle planning, and so on. However, one of the most important steps of this Business process is software monitoring. This is the only way to exactly know what software is installed within an enterprise and, more importantly, which software and how many pieces of it is used within the IT infrastructure. Sometimes, enterprises buy Corporate licenses even though licenses are procured for some specific Divisions and wont be used by the rest of the enterprise. Many organizations are overbuying licenses so as to not expose the enterprise to the risk of non-compliance usage of software products, merely because they are not able to prove or to evaluate how many licenses they really need or use. The license procurement information must be properly reconciled with the software usage and inventory data. This is the only way an enterprise has to tell whether it is paying more license fees than necessary or whether it should buy new licenses to be compliant with the product license policies. Currently, many software vendors leave the responsibilities of license management to the enterprises that buy the products. They often dont provide technical support to maintain or apply the product license policies. Furthermore, the organizations have to prove that they are not using more licenses than they are authorized for. IBM Tivoli License Manager offers a technical way to control and apply the software vendors pre-defined policies. It allows the Administrator to easily manage different products in different ways, reflecting the rules of each products License agreement. Some software requests a License compliance enforcement in risk of facing financial penalties. IBM Tivoli License Manager can apply License enforcement by prohibiting the start of a certain software. The technique used to prevent software usage is a non-intrusive technique, avoiding any risk of damaging application files and data. All software vendors apply pricing policies. However, the License counting process depends on each software vendor. Sometimes, the License counting is based on the number of concurrent users, number of installed or configured processors on machines, number of installed Hard Disks, on the amount of memory, and so on. Furthermore, for the same software, the rules can differ if the License is limited to a user, a group of users, or a Division.

2.5.1 Software entitlement process


Creating software entitlement using IBM Tivoli License Manager helps you define many different combinations of License counting processes. However, it is important to understand that the process to create software entitlement within your enterprise becomes an important one. License enforcement can, for

Chapter 2. IBM Tivoli License Manager general overview

31

example, prevent the usage of critical software that is used for your business production. Hereafter, you will find the complete process that is used to define software entitlement within your IBM Tivoli License Manager solution. This process should also be included in your existing Change Management and Life Cycle strategy so that the software entitlement process can be used in every situation that suggests a software licensing policy change, a new licensing negotiation, or when a new software purchase occurs. We advise you to define and document each process for each software that needs a software entitlement. This information can be used in case of an audit, a skill transfer, a licensing negotiation, a software migration, or any event that solicits knowing the licensing policies of a software. Based on the definition provided in Software Entitlement on page 28, a software entitlement is a set of rules that defines how software is monitored. It is important to understand that a software entitlement is simply a definition of the software you want to monitor. If you want to enforce Licensing restrictions, you need to create license pools within the software entitlement. A license pool is a set of rules governing thresholds, hard stops, license allocation to multiple sessions of the same product, and the availability of the product to Users and Nodes. Figure 2-6 is the process of creating a new software entitlement, and as seen in Figure 2-2 on page 15, the software entitlement is entirely part of the software Asset Management process.

32

Introducing IBM Tivoli License Manager

New Software

No End

Manage License ?

Yes

Create a Software Entitlement

Enable Default

Disable Server response No Wait for License authorization? Yes

Enable Run offline No Apply License checks ? Yes

Disable Software monitoring No Monitor SW usage ? Yes

No Apply License restriction? Yes

Enable User defined

Enable Server response

Disable Run offline

Enable Software monitoring

License Pool creation process

Figure 2-6 IBM Tivoli License Manager software entitlement process

Hereafter, the software entitlement definition process is explained in detail. However, for more information regarding each IBM Tivoli License Manager software entitlement option and how to create a software entitlement, refer to 5.8, Managing software entitlement and license pool on page 166. As shown in Figure 2-6 each of the following steps are mandatory to enable a software entitlement: Manage License? The first question is to answer whether or not the software needs to be entitled. For example, an In-House application may not need any licensing

Chapter 2. IBM Tivoli License Manager general overview

33

policy enforcement, but still you want to get statistics of its usage. In this case you have to create a software entitlement. Monitor SW Usage? You have to decide whether or not you want to track the presence and use of a product. Enabling this option can help you to get software statistics, and more importantly, software usage reports. Apply license checks? This point is important because if you want to apply licensing policies or software usage monitoring, you have to enable license checks. Otherwise, if you dont apply any checks, even if the Agent informs its Runtime server of a start or stop of an application, the Runtime server will not use this information and the end user will be able to start the application, even if there is no communication between the Agent and the Runtime server. Wait for license authorization? This point is dependent on your license policies. It means that the end user will not be able to start the application without receiving authorization from the Runtime server. This is valid for the software or any application defined in a license pool. Apply license restriction? As explained earlier, some software products are subject to strict licensing policies. If you need to apply these polices, you have to create specific license pools. Otherwise, if you only want to monitor software usage and dont want to apply any licensing restriction, you can use the default option and no licensing policies will be applied. If you want to apply licensing rules in your environment, you have to create license pools within a software entitlement. A license pool can be applied to only one software entitlement, therefore, to only one software at a time. However, many license pools can be created for the same software entitlement. This allows you to define many different rules for the same software that have different licensing policies regarding how the software is used. Figure 2-7 shows the process of creating license pools. This process immediately follows the software entitlement definition process.

34

Introducing IBM Tivoli License Manager

Software Entitlement process

Create a License pool

Select a Capacity Type

Users Memory Proc. Online Proc. Conf. Disks

Disabled Same user Same group Same node

Select a Quantity

Apply Maximum License usage?

No

Disable Hard Stop

Select a Multi instance

Enterprise Division Node Agents

Yes

Enable Hard Stop

Select a Target Type

Select an Expiration Date

Select a Start Date

Select a Threshold for warnings

Is Target Type Enterprise ? Yes

No

Is Target Type Division ? Yes Assign Division Name

No

Is Target Type Node ? Yes

No

Is Target Type Agent ? Yes Assign Agent Label

Assign Node Tag

Assign Login Name

Need to create a new pool ? Yes

No

End

Figure 2-7 IBM Tivoli License Manager license pool process

Chapter 2. IBM Tivoli License Manager general overview

35

Hereafter, the definition process is explained in detail. However, for more information regarding each IBM Tivoli License Manager license pool option and how to create a license pool, refer to 5.8, Managing software entitlement and license pool on page 166. Notice that each of these steps are mandatory to enable a license pool: Select a Capacity Type If a software vendor has defined licensing policies, he needs to provide the counting method he uses to exactly determine the number of licenses you are allowed to use within your enterprise. Normally, such methods are based on the number of concurrent users, the amount of memory installed on a node where the software will be executed, the numbers of online processors, the number of configured processors, or the number of hard disks installed on the machine. Used in conjunction with the IBM Tivoli License Manager license pool quantity option, you can define the upper license limit for a type of counting method. For example, if the capacity type is the number of processors online and the quantity is 10, this license pool will limit the number of licenses to only 10 processors, this could be 10 machines with one processor or 2 machines with 5 processors. Apply Maximum License usage? This is a critical decision, because if it is not correctly evaluated, it could impact your business production. By choosing to apply the maximum license usage, IBM Tivoli License Manager will refuse to serve a new license request by hard stopping the software if the maximum of allowed licenses has already been reached. It means no one will be able to start that particular application if the threshold has been reached. Select a Multi-instance Some software may only count that one license is being used if a new instance of the same software has been started for a second time, or more, on the same machine or same user ID, for example. Another example may be if the software needs to be used by a group of users and is only considered as one license. Select a Target Type The rules you defined for a license pool need to be applied in your monitoring structure, called Topology. However, you are able to apply a set of rules to your entire Customer using the Enterprise option. You can also be more specific in the application of your rules by choosing to limit the availability of a software to one or several Divisions, to one or several Nodes, or to one or several Agents. Using one of these three options, you will be asked to provide an exhaustive list of object names.

36

Introducing IBM Tivoli License Manager

Assign Login Name In any case and independently of which Target type you choose, you need to provide one User name or a list of Users who will be subject to this License restriction. However, you can select the All option to enable a license pool for every User within your enterprise. Need to create a new License Pool? As already mentioned, the software can respond to many different licensing policies depending in which situation it is used. Within a software entitlement, you are able to define several license pools. Going back to the example of ACME enterprise and the CSI HR software we used in Figure 2-1 on page 13 and in Figure 2-2 on page 15, the license policies for the CSI HR software maybe different for the HR and Financial Divisions, because different modules of the software are used. You can create one license pool with a User Capacity limitation and assign it to the HR Division and create a second one with a Memory Capacity limitation and assign it to the Agents that are part of the Financial Division.

2.6 Example scenarios


This section provides information about the Microsoft, Oracle, and IBM Tivoli Software Licensing policies. Some examples are based on realistic case studies and should help you to understand how to integrate these licensing policies in the IBM Tivoli License Manager software entitlements.

2.6.1 Microsoft license management


This section discusses the Microsoft licensing portfolio. Nevertheless, we dont provide detailed explanations about the Microsoft license programs. In fact, only some of Licensing programs that Microsoft offers are explained. Our aim is to provide a realistic example of a Microsoft product license management. The following information concerning various licensing schemes for Microsoft applications was derived from publicly available information obtained from http://www.microsoft.com/licensing/, as of the date of publication of this document. It is offered as a partial summary of some of Microsoft's licensing programs and policies solely for illustrative purposes and does not purport to be a full, complete, or comprehensive representation of those programs and policies. For a full description of Microsoft's licensing terms, contact Microsoft or your Microsoft vendor.

Chapter 2. IBM Tivoli License Manager general overview

37

Note: The information provided in this section is for illustration and educational purposes only. It may not be used or incorporated in any document as official Microsoft information. The Microsoft License program is called Microsoft Volume Licensing Program. Here are some of the licensing options provided by the Microsoft Volume Licensing program that are dedicated to business organizations and offer different ways to acquire multiple product licenses: Open License 6.0 Select License 6.0 Enterprise Agreement 6.0 Enterprise Subscription Agreement 6.0

Open License 6.0


Open License 6.0 is a software volume licensing program designed for corporate, government, charity, and academic customers who order as few as five licenses.

Select License 6.0


Select license is based on a forecast of the total volume of Microsoft software licenses an enterprise expects to acquire over a three year period. Forecasts are made by product pools: applications, systems, and servers. These product pools make it possible for an enterprise to aggregate purchases across an entire category of products to achieve better volume pricing. Because certain licenses represent a greater investment than others, the select license forecast is based on the point value of each license forecasted, not the number of product licenses. Under the select license program, a license part number will be the only part number needed to acquire the most current version of all Microsoft products. Here you will find a list of the three product pools with examples of the types of products included in each pool and their associated point value: For applications Microsoft Office XP Professional Microsoft Excel Microsoft Project For systems Microsoft Windows XP Professional Upgrade For servers Microsoft Windows 2000 Server Microsoft Windows 2000 Client Access License 15 points/license 1 point/license 2 points/license 2 points/license 1 point/license 1 point/license

38

Introducing IBM Tivoli License Manager

There are four price levels (Table 2-1) for all select license products acquired within each product pool. The price level is determined by a three year forecast.
Table 2-1 Select License 6.0 price level

Price Level
A B C D

Minimum Unit Forecast per Pool

1,500 points 12,000 points 30,000 points 75,000 points

On an annual basis, Microsoft will review the purchase history for the preceding 12 months against the forecasted price level for each product pool. For the first year end review, Microsoft will check to see if 1/3 of the total forecast was met to determine whether the price level needs to be reset. For the second year end review, Microsoft will check that 2/3 of the forecast was met. Depending on the actual purchase history, the price level may be raised upwards, downwards, or remain the same.

Enterprise Agreement 6.0


With Enterprise Agreement, pricing levels for the enterprise products are determined by the total number of qualified desktops. It simplifies license administration by only requiring a single transaction to acquire licenses across the entire enterprise and therefore helps to ensure compliancy. Enterprise Agreement 6.0 offers a flexible way to standardize the company on the following enterprise platform of Microsoft products: Microsoft Office Professional Microsoft Windows Professional Desktop Upgrade Microsoft Core Client Access License (CAL) A broad selection of software titles, including Visio, Project, Windows Servers, and Exchange Servers are available as additional products. There are four price levels for each of the enterprise products: Level A B C D PC's 250-2,399 2,400-5,999 6,000-14,999 15,000+

Chapter 2. IBM Tivoli License Manager general overview

39

Enterprise Subscription Agreement 6.0


If an enterprise is interested in leasing rather than purchasing perpetual Microsoft software licenses as covered in the Enterprise Agreement 6.0 program, the Enterprise Subscription Agreement program offers the possibility of leasing the Microsoft software. However, software licenses offered through this program are non-perpetual, meaning that product use rights are only in effect for the term of the enrollment. This program covers the same products scope than the Enterprise Agreement 6.0 program. The price paid for selected software is based on the quantity of qualified desktops. The Enterprise Subscription Agreement program establishes the price level at the beginning of the enrollment. The price for selected enterprise products and additional products will not fluctuate unless the number of qualified desktops that are reported annually changes, and the price level changes as a consequence. Desktops added between Annual PC Counts are automatically covered for enterprise products selected on the Enterprise Subscription enrollment. The price level at the following Annual PC Count is determined by the amount of qualified desktops for that year and that year alone.

Microsoft license entitlement case study


This example should help you understand how to integrate the Microsoft License program policies in software entitlements. The ACME enterprise needs to buy new spreadsheet software. After a period of evaluation, the ACME enterprise decided to buy the Microsoft Excel product. The software needs to be deployed on all machines, because it will be the standard application for back office operations. The ACME enterprises has 3,900 desktops. After some negotiation with Microsoft and as the ACME enterprise already acquired the Windows Operating System using the Select License 6.0 option of the Microsoft Volume Licensing program, the Microsoft Excel Licenses will be included in this same licensing program. The enterprise bought the Microsoft Windows XP Professional upgrade some months ago for a total of 7,800 points based on the calculation method used for this Licensing program. Therefore, the ACME enterprise is part of the pricing level A. By adding the 3,900 points of the new Microsoft Excel Licenses, the ACME enterprise now has 11,700 Microsoft License points and is still in pricing level A. Using the Select License 6.0 Licensing program from Microsoft Volume Licensing program, Microsoft will review the purchase history each year over the three year

40

Introducing IBM Tivoli License Manager

contract period. The ACME enterprise wants to precisely know how many Microsoft Excel licenses are used within the enterprise per year to be sure that the licenses fees match the budget planned. Furthermore, if the ACME enterprise were to purchase 300 additional Microsoft license points, the pricing level would change from A to B, and maybe the pricing conditions could be better. By enabling the software usage, the ACME enterprise will know, before buying new Microsoft Licenses, if the 4,500 Microsoft Excel Licenses are really used, and if by buying only 300 Microsoft points more, the enterprise could saved money.

Software Entitlement definition


To control the Microsoft Excel usage, the ACME enterprise has to entitle the software using the Software entitlement process. As this software is subject to license policies, the license checks should be enabled and each usage of the Microsoft Excel application must be reported. However, it is not mandatory for the user to wait for a license request acknowledgement from the server to know if he/she is able or not to use the software, because as Microsoft will review the software usage each year, no hard stop is needed, and software usage could overload the number of defined Licenses. Table 2-2 provides a summary of the software entitlement that needs to be defined in IBM Tivoli License Manager.
Table 2-2 Software entitlement example for Microsoft Excel

Software Entitlement for Microsoft Excel Version Vendor Platform


2002 Microsoft Windows

Software Usage Monitoring License checks License authorization waiting License Pools

Yes Yes No

Name
Select License 6.0

Type
User

Quantity
3,900

Target
Enterprise

Instance
Disabled

Users
All

Hard Stop
No

2.6.2 Oracle license management


This section discusses the Oracle pricing and licensing process. Nevertheless, we dont provide detailed explanations about the Oracle License programs. Oracle applies different licensing policies on each brand of developed products: Technology, Applications and Services. In fact, only the Database category of the Technology Licensing process is explained, and our aim is to provide a realistic example of an Oracle Database license management. The following information concerning various licensing schemes for Oracle applications was derived from publicly available information obtained from

Chapter 2. IBM Tivoli License Manager general overview

41

http://www.oracle.com/corporate/pricing/, as of the date of publication of this document. It is offered as a partial summary of some of Oracles licensing programs and policies solely for illustrative purposes and does not purport to be a full, complete, or comprehensive representation of those programs and policies. For a full description of Oracles licensing terms, contact Oracle or your Oracle vendor.

The information provided in this section is for illustration and educational purposes only. It may not be used or incorporated in any document as official Oracle information. The Oracle Database category includes four distinct editions each suitable for different development and deployment scenarios. Enterprise Edition Standard Edition Lite Edition Personal Edition The Oracle Database products are licensed using the two metrics described here: Named User Plus Metric Processor Metric

Named User Plus Metric


This metric is used in environments where users can be identified and counted. Named User Plus includes both humans and non-human operated devices. All human users and non-human operated devices that are accessing the program must be licensed. A non-human operated device can be many things, like a temperature device. It is important to note that if the device is operated by a person, then this person must be licensed.

Processor Metric
This metric is mostly used in environments where the software users cannot be easily identified or counted, like in Internet-based applications. The Processor metric is also used when it is more cost effective than Named User Plus licenses. All processors where the Oracle programs are installed and/or running must be licensed. If the server where the program is installed can be hardware-partitioned and the customer can provide enough information to Oracle to confirm that only part of the server is being used by the Oracle program, then only the part that is being used must be licensed.

42

Introducing IBM Tivoli License Manager

The Oracle Database products are also licensed, in conjunction with the previous methods, depending in which IT environment they will be used: Development Test/Staging Production Standby

Development
Set up, customization, and modification of software is done in a development environment. Any person doing development work using the software must be licensed. Oracle software for development is governed by a special agreement called the OTN Development License. This agreement grants the individual the right to use the programs only in a development environment. Licenses obtained under this agreement may not be used in test, production, failover or any other environments.

Test/Staging
Test/staging environments are used to verify that new or customized code runs properly. Test/staging environments can be staged on separate servers or on the same servers used to run a development or production environment. Any Oracle software used in test/staging environment must be properly licensed with a full use license under an Oracle license agreement. If a test/staging environment is maintained on the same server as a production or development environment, and that server is fully licensed for all relevant programs on a per processor metric, then no additional Licenses are required for the test/staging environment.

Production
The environment used by end users for business or other operations is called a production environment. All programs used in the production environment must be properly licensed based on the applicable license metrics under an Oracle license agreement.

Standby
In this environment, both the primary and the standby databases must be fully licensed. Additionally, the same metric must be used when licensing the databases in a standby environment.

Oracle license entitlement case study


This example should help you understand how to integrate the Oracle Database license policies in software entitlements. The ACME enterprise has developed an in-house application to manage its trading business. This application mainly stores information in an Oracle RDBMS and ACME enterprise needs to buy licenses for this product.

Chapter 2. IBM Tivoli License Manager general overview

43

Staging, test, and production environments are installed and running on a server, which has six processors. 10 developers are working on the staging, test, and production environments 500 traders are using the Web site that resides on the production environment The Oracle product that need to be licensed is the Oracle Database Enterprise Edition for the three environments: Test, Staging, and Production. This product can be licensed by Processor or by Named User Plus metric: If licensing by Processor, all processors where the Database is installed and/or running must be licensed. Number of Processor Licenses required: 6 If licensing by Named User, the number of Licenses required is the Named User Plus minimum (25 Named Users Plus per Processor) or the total number of actual users accessing the Database, whichever is greater: a. Named User Plus minimum: 25 * 6 Processors = 150 Named Users Plus b. Total Users: 500 traders + 10 Developers = 510 Named Users Plus Number of Named User Plus Licenses required: 510 If the server is fully licensed by processor then no additional licenses are required to install and/or run other environments that are configured on the same server. The ACME enterprise opted for a Named User Plus License metric and need to achieve 510 Name Users Plus licenses.

Software Entitlement definition


To control the Oracle Database Enterprise Edition usage, the ACME enterprise has to entitle the software using the Software entitlement process. As this software is subject to license policies, the license checks should be enabled and each usage of the Oracle Database application must be reported. The ACME enterprise has forced each user to wait for a license request acknowledgement from the server, because the enterprise has to enforce the license usage for the Development Division in order to respect the Oracle Database license policies. However, the trading business is much too critical to enforce this License usage. It would be much less expensive for the ACME enterprise to pay penalties, if any, to Oracle than to let a trader wait for the next free Oracle License. Table 2-3 provides a summary of the software entitlement that needs to be defined in IBM Tivoli License Manager.

44

Introducing IBM Tivoli License Manager

Table 2-3 Software entitlement example for Oracle Database Enterprise Edition

Software Entitlement for Oracle Database Enterprise Edition Version Vendor Platform
9i Oracle Windows

Software Usage Monitoring License checks License authorization waiting License Pools

Yes Yes Yes

Name
Developers Traders

Type
Users Users

Quantity
10 500

Target
Develop. Division Trading Division

Instance
Disabled Disabled

Users
All All

Hard Stop
Yes No

2.6.3 IBM Tivoli software license management


This section discusses the IBM Tivoli software pricing and licensing process. Nevertheless, we dont provide detailed explanations about the IBM license programs. IBM applies different licensing policies on each brand of software. In fact, only the IBM Tivoli software products licensing process will be explained. Our aim is to provide a realistic example of an IBM Tivoli Software product license management. The following information concerning various licensing schemes for IBM applications was derived from publicly available information obtained from http://www-3.ibm.com/software/passportadvantage/, as of the date of publication of this document. It is offered as a partial summary of some of IBMs licensing programs and policies solely for illustrative purposes and does not purport to be a full, complete, or comprehensive representation of those programs and policies. For a full description of IBM's licensing terms, contact IBM or your IBM representative. The information provided in this section is for illustration and educational purposes only. It may not be used or incorporated in any document as official IBM information. IBM Tivoli Software products are licensed using the Enhanced Value-Based Pricing model. They are mostly based on a single per-processor licensing metric, which applies to all processors and all platforms including servers and managed clients. However, some of them need to use different metrics as the processor metric could not be applied. For example, some network monitoring programs

Chapter 2. IBM Tivoli License Manager general overview

45

use network nodes or switch ports as metric while some security products use a metric based on the number of user accounts that have to be managed. Some IBM Tivoli Software products are also available on IBM ^ z-Series platforms. They are based on the same processor licensing metric. Furthermore, processor licenses for a distributed IBM Tivoli product can be used on zOS and vice-versa as the licenses are based on hardware, not on Operating System, and are interchangeable. Nevertheless, IBM Tivoli Software products that are part of the Host edition or for z-Series brand are priced per Management Services Unit (MSU). It is important to notice that production and test environments both require IBM Tivoli licensed products. If a server is split in several physical partitions, IBM Tivoli Software products will be counted per processor in each physical partition. However, if the server is split in several logical partitions, the products will be counted per processor or per MSU for the entire system. The Enhanced Value-Based Pricing model defines the number of needed IBM Tivoli Software product Licences that a customer environment requires. However, IBM Tivoli Software products are part of the IBM Passport Advantage program, which rewards customers with better pricing based on the volume of their IBM software acquisition and the type of organization. The initial customer order determines the pricing level received by the customer. This is known as the Relationship Suggested Volume Price band level. Passport Advantage is a point-based offering, which means that every product and service listed within the price list carries a predefined point value. The customer's initial order is converted into points, which sets the Relationship Suggested Volume Price band level. There are 10 band levels "A" through "J". See Figure 2-8.

46

Introducing IBM Tivoli License Manager

Figure 2-8 IBM Passport Advantage relationship volume price band level

Passport Advantage allows the customer to have a common anniversary date for software Maintenance renewals, simplifying management and budgeting for eligible new versions and releases for covered products. The anniversary date is established at the start of the Passport Advantage Agreement. Aggregation on Passport Advantage occurs each quarter. This quarterly aggregation can only better the customer's price level for the remainder of an anniversary period. Figure 2-9 shows an example of a Passport Advantage Aggregation.

Chapter 2. IBM Tivoli License Manager general overview

47

Figure 2-9 IBM Passport Advantage aggregation example

In this example, the customer makes an initial transaction of 1,000 points. This sets the customer's Relationship Suggested Volume Price band level to "E". During the first quarter, the customer made two additional product purchases: one equal to 500 points, and another equal to 1,000 points, for a total of 1,500 points. At the end of the quarter the customer's purchases are aggregated for that quarter. In this example, the initial transaction of 1,000 points is added to the additional transactions of 1500 points for a total of 2,500 points. This aggregation causes the customer's Relationship Suggested Volume Price to be recalculated to band level "F" for the remainder of the anniversary period, unless additional purchases are made and aggregated forcing the customer's Relationship Suggested Volume Price band level even higher. In the third quarter, the customer made additional product purchases of 1,500 points and 1,000 points, for a total of 2,500 points. This is aggregated to the total number of points earned during the current anniversary, for example, 2,500 points plus 2,500 points. Therefore, aggregation after third quarter will recalculate the customer's Relationship Suggested Volume Price to band level "G" for the remainder of the anniversary period.

48

Introducing IBM Tivoli License Manager

IBM Tivoli Software license entitlement case study


This example should help you understand how to integrate the IBM Tivoli Configuration Manager License policies in software entitlements. The ACME enterprise needs to deploy Configuration Management solution to automate the software distribution and inventory processes. The enterprise chose the IBM Tivoli Configuration Management product. The software needs to be deployed on the 3,900 desktops installed within the enterprise, but also on the 50 Windows enterprise servers. The ACME enterprise has already subscribed to the IBM Passport Advantage program. The current Relationship Suggested Volume Price level for ACME is D. By acquiring new IBM Tivoli Configuration Manager Licenses, the level is recalculated to band E. By tracking the IBM Tivoli Configuration Manager Licenses, ACME will be able to know if the software distribution and inventory processes are correctly executed and applied on all machines within the enterprise.

Software Entitlement definition


To control the IBM Tivoli Configuration Manager usage, the ACME enterprise has to entitle the software using the Software entitlement process. As this software is subject to license policies, the license checks should be enabled and each usage of the IBM Tivoli Configuration Manager application must be reported. However, as the configuration management processes are often silently executed, it is not mandatory to wait for a license request acknowledgement from the server. Furthermore, the hard stop option must be disabled in order to let, for example, the IBM Tivoli Configuration Manager install new software on a machine even if the licenses quantity is exceed. Table 2-4 provides a summary of the software entitlement that needs to be defined in IBM Tivoli License Manager.
Table 2-4 Software entitlement example for IBM Tivoli Configuration Manager

Software Entitlement for IBM Tivoli Configuration Manager Version Vendor Platform
4.2 IBM Windows

Software Usage Monitoring License checks License authorization waiting License Pools

Yes Yes No

Name
Servers

Type
Processor

Quantity
50

Target
Server Agents

Instance
Disabled

Users
All

Hard Stop
No

Chapter 2. IBM Tivoli License Manager general overview

49

Software Entitlement for IBM Tivoli Configuration Manager


Workstations Processor 3,900 Desktop Agents Disabled All No

50

Introducing IBM Tivoli License Manager

Chapter 3.

Implementation planning
This chapter provides considerations to ensure an effective implementation of IBM Tivoli License Manager (ITLM) across your enterprise. IBM Tivoli License Manager is dependent on a number of supporting applications and components which makes planning an essential task in order to ensure a successful deployment. Before installing IBM Tivoli License Manager, you should consider designing your licence management architecture. This should include a high level design in which the physical and logical design will be defined. You should also consider the hardware and software requirements and their dependencies of the various functional pieces on the other applications that support the IBM Tivoli License Manager solution. The main topics concerned with planning discussions in this chapter are: Considerations regarding the physical design and logical design Disaster Recovery plan Planning overview for the entire IBM Tivoli License Manager solution Planning for supporting applications Planning for IBM Tivoli License Manager

Copyright IBM Corp. 2003. All rights reserved.

51

3.1 Physical design


This section addresses the physical design for the implementation of IBM Tivoli License Manager. The physical design develops the underlying physical infrastructure on which the solution will operate. Sufficient time needs to be allocated to ensure that the correct design has been developed, because when deployed and operational, the physical design may be difficult to change without a disruption of the IBM Tivoli License Manager environment. The physical design process includes the following high-level considerations: IBM Tivoli License Manager Administration and Runtime servers Network and Security Hardware and File Systems Backup and Recovery process Physical Design example

3.1.1 ITLM Administration Server considerations


There is only one Administration server per IBM Tivoli License Manager environment. The Administration server is generally placed close to where the ITLM Administrators are located. It should also be connected to a network segment that could easily serve all Runtime Servers. However, one of the most important requirements for the Administration server placement is the location of the Database server. If you plan to install the Database server on a different machine as the Administration server, you should ensure that there is a high-speed network connection between the two machines.

3.1.2 ITLM Runtime Server considerations


The IBM Tivoli License Manager environment must have at least one Runtime server defined because only a Runtime server could manage Agents. However, the environment could have several Runtime servers. The following rules need to be defined in order to know if there is a need to install a new Runtime sever in your environment: When scalability limits require a new Runtime server When network topologies require a new Runtime server (that is, WAN location) When a particular Runtime server is overloaded with licence requests When a new customer needs to be managed

52

Introducing IBM Tivoli License Manager

Assigning Agents to Runtime servers is a critical portion of the physical design. Performance and scalability are the main points for the Runtime servers placement. Note: Before starting the evaluation of the number of Runtime servers for your environment, you must notice that a Runtime Server can be part of only one Customer topology. For more information about the Customer design, refer to 3.2.2, Customer considerations on page 60. The placement of the Runtime servers must respect the rules defined here: Performance Scalability Physical licence requests management

Performance
Each Runtime Server will be connected directly to the Administration server, and they should be located relatively close to their agents within the physical network. So, you may place Runtime servers across a Wide Area Network (WAN) from the Administration server, which makes the Runtime server closer to their monitored nodes. This minimizes network traffic when requesting licence status and should also decrease the security risks, because the communications between the Agents and the Runtime server are not encrypted. Another reason for putting the Runtime servers close to the Agents is the flow of inventory data back from the Agents to the Runtime server Database. This information is then forwarded to the Administration server Database but is encrypted if you decide to enable SSL, and only the differences are sent back to the main Database. For these reasons, if your implementation covers more than one location, we advise that you have a least one Runtime Server at each location. However, for small WAN locations, it makes no sense to deploy a Runtime Server. You may plan to dedicate a Runtime Server on your main site only to manage these WAN locations, and you may place this server in a zone protected by a Firewall or force the usage of a Proxy server.

Scalability
The Runtime server component can also be installed on the same physical machine as the Administration server to support Agents within the same network. However, this configuration is not recommended. From the point of view of scalability, if you install both servers on the same machine, each one of them can only use a share of the hardware and network resources. It is important to notice that the resource usage of the machine during the inventory scan and licence

Chapter 3. Implementation planning

53

usage control process can be very demanding and other processes on the same machine can be drastically impacted. Furthermore, by installing both servers on the same machine, they will rely on the same incoming method to accept requests, which is the HTTP server. Therefore, if one of the two becomes overloaded, and the HTTP server starts having some problems with the number of pending requests, the other one may start to have overloading problems too. Another point that can impact the Runtime server scalability is the inventory scan process. It is only possible to schedule inventory scans by Division. If all Agents registered on a Runtime server are part of the same Division, the inventory scan process will start for all Agents at the same time, which can overload the Runtime server. An option is to register Agents belonging to large Divisions to multiple Runtime servers. Note that the decision about how to distribute the Agents among Runtime servers does not need to reflect the organizational structure.

Physical licence requests management


The Runtime servers is also in charge of licence requests from the Agents. If a Runtime Server cannot satisfy a licence request from its licence pools, the Agent should be able to contact another Runtime server, if the Agent is configured to do so. Here are the options for Agent configuration: Contact all Runtime servers within the same customer organization. Contact all Runtime servers which also serve Agents that are part of the same Division as the requester Agent. Contact only its own Runtime server. This structure provides a way to separate the physical design from the logical design without sacrificing licence usage efficiency.

3.1.3 Scalability limits


The limitation on the Administration server is to due to the maximum amount of data that it can store and manage correctly. This number depends on the total number of Agents regardless of the number of Runtime servers. There is a recommended maximum of 7500 Agents assigned per Runtime Sever. There is a recommended maximum of 15000 Agents assigned per Administration Server. There is a recommended maximum of 10 Runtime servers per IBM Tivoli License Manager environment, but the number of Runtime servers should not be a great issue.

54

Introducing IBM Tivoli License Manager

3.1.4 Network considerations


IBM Tivoli License Manager mainly uses the HyperText Transfer Protocol (HTTP) for communication. Therefore, the amount of network traffic that can be sustained by the networking interfaces on IBM Tivoli License Manager Administration and Runtime servers represents a practical limit to the number of Agents that can be reasonably serviced by a single Administration server. When planning your IBM Tivoli License Manager solution, consider these points to improve Administration and Runtime servers networking performance: Introduce high-speed network adapters on all IBM Tivoli License Manager servers. Use local file system storage for binaries, libraries and data. Place the Administration in a high-speed segment so that it serves the different requests from Runtime servers faster. Place the Runtime server of remote locations in the same network segment as the remote router. Because IBM Tivoli License Manager communication is based on HTTP, some TCP/IP ports will be used to initiate the links. The default port for HTTP is 80 and for HTTPs is 443. These ports are officially reserved as a TCP service. You may plan to use different ports. However, it is important to notice that if you change the communication port of a production Runtime server serving a number of Agents, you also have to reconfigure the Agents with the corresponding TCP/IP port.

3.1.5 Security considerations


Security is also an important factor impacting the physical design. For IBM Tivoli License Manager, some implications of security choices are as follows: Encryption As seen in 2.2, IBM Tivoli License Manager physical components on page 16, there are two data flows in a IBM Tivoli License Manager solution; between the Administration server and the Runtime servers, and between Runtime servers and Agents. The communication between the Administration and Runtime servers can be encrypted using SSL. We recommend that you use this encryption method to protect the Customers information and the licence pool definition, because this can be related to financial information. The communication between Runtime servers and Agents cannot be encrypted. However, only inventory scan information and licence usage authorization is exchanged in this data flow.

Chapter 3. Implementation planning

55

Firewall IBM Tivoli License Manager allows you to use a Proxy server to filter the HTTP communication between the Administration server and the Runtime server and between the Runtime server and its Agents.

3.1.6 Hardware considerations


Because IBM Tivoli License Manager depends on a number of support applications, you should first consider the hardware requirements for those applications and refer to their respective product documentation. Here we provide only some generic considerations and suggestions for the IBM Tivoli License Manager product. It is important to notice that all support applications and IBM Tivoli License Manager components are Java based applications. Regarding this information, the Java memory usage for: The IBM WebSphere Application Server Administration Console is at least 50 MB of RAM. The IBM DB2 Universal Database Enterprise Edition Control Center is at least 60 MB of RAM. The IBM Tivoli License Manager Administration server is about 180 MB. The IBM Tivoli License Manager Runtime server is around 170 MB. These amounts of memory usage can increase depending on the number of concurrent connections. Some others processes, like IBM WebSphere Application Server and the IBM DB2 Universal Database Enterprise Edition server, may also use a considerable amount of memory. As a general rule, virtual memory or swap size must set to double of the physical RAM to avoid a machine crash in case of RAM shortage. For more information about hardware and software requirements, refer to 3.4, Planning for IBM Tivoli License Manager on page 69.

3.1.7 File systems considerations


A file system is the way in which files are named and where they are placed logically for storage and retrieval. In the context of an IBM Tivoli License Manager project, it is important to correctly separate the different applications to avoid any disruption of an application caused, for example, by a problem with corrupted

56

Introducing IBM Tivoli License Manager

files of other applications. Furthermore, it is also important that such an application doesnt interfere with the operating system files. The following file systems structure is only an example based on best practices and is only a suggestion for an installation of IBM Tivoli License Manager. For UNIX: /usr/local/DB2/<DB2 instance name> This file system contains the databases definition for the IBM DB2 Universal Database Enterprise Edition instance you will use for the IBM Tivoli License Manager Administration and Runtime Databases. This is specified by <DB2 instance name>. /usr/local/DB2/<DB2 Administration server name> This file system contains the IBM DB2 Universal Database Enterprise Edition binaries and configuration files. /usr/local/HTTPServer This file system contains the IBM HTTP server binaries and configuration files. /usr/local/WebSphere This file system contains the IBM WebSphere Application Server binaries and configuration files. /usr/local/ITLM This file system contains the binaries and configuration files for either the IBM Tivoli License Manager Administration or Runtime server or both. For Windows: E:\lBM\DB2 This file system contains the databases definition for the IBM DB2 Universal Database Enterprise Edition instance you will use for the IBM Tivoli License Manager Administration and Runtime Databases and also the binaries and configuration file for the application. E:\IBM\HTTPServer This file system contains the IBM HTTP server binaries and configuration files. E:\IBM\WebSphere This file system contains the IBM WebSphere Application Server binaries and configuration files.

Chapter 3. Implementation planning

57

E:\IBM\ITLM This file system contains the binaries and configuration files for either the IBM Tivoli License Manager Administration or Runtime server or both.

3.1.8 Physical design example


Here we provide an example of an IBM Tivoli License Manager physical architecture across an enterprise, which is distributed in several sites: The main site, a middle sized site, and two small ones. In this case, the connection to the nodes in small remote sites must be filtered using a Proxy server and some nodes in the De-Militarized Zone (DMZ) located in the main site have to be monitored. Figure 3-1 depicts the above example and shows the chosen ITLM physical design.

E
Medium Site Runtime server Main Site

B
Monitored nodes

Runtime server

C
Monitored nodes Runtime server

Monitored nodes

Administration server

D
Small Site

De-Militarized Zone (DMZ)

Monitored nodes

Firewall Runtime server

Small Site Proxy server

Monitored nodes

Proxy server

Monitored nodes

Figure 3-1 IBM Tivoli License Manager physical design example

58

Introducing IBM Tivoli License Manager

The legend used Figure 3-1 is related to specific decisions of the servers placement and explained as follows: A The IBM Tivoli License Manager Administration server is located in the main site. The machine is attached to a Fast Ethernet network segment dedicated for the enterprise servers. As all Runtime Servers will make a certain number of requests, the network needs to be fast enough not to be a bottle neck. The first IBM Tivoli License Manager Runtime server is in charge of the Agents located in the main site. As this Runtime server will serve a large number of Agents, for scalability and performance reasons, this Runtime server needs to be installed in a dedicated machine. It is also attached to the Fast Ethernet network segment dedicated for the enterprises servers. The second IBM Tivoli License Manager Runtime server is in charge of the Agents located in the DMZ. These Agents will go through a Proxy server to filter the data flow between the enterprise and the DMZ. This Runtime server will also serve as secondary Runtime server for the Agents located in the main site, in case the first Runtime server is overloaded and is not able to answer to all licence requirements. This server could also be located in the same network segment as the previous Runtime server. The third IBM Tivoli License Manager Runtime server is in charge of the WAN Agents. For small remote sites, which can have less than 20 agents, in this case, cost factors were considered and it was decided not to install dedicated Runtime servers on each of the small sites. In this example, all small sites are managed by a dedicated Runtime server. This offers the possibility of using a proxy server to filter the WAN addresses that can use this Runtime server. A fourth IBM Tivoli License Manager Runtime server is installed on the medium remote site. This will increase the performance of the management of that site. Otherwise, if no Runtime is installed on the medium remote site, each agent would contact the Runtime server and upload information across a small bandwidth network which could created a network bottle neck for all others applications.

3.2 Logical design


This section addresses the logical design for the IBM Tivoli License Manager implementation. The logical design identifies how the IBM Tivoli License Manager topology will be configured. Although the logical design can be modified more easily after it is in place than the physical design, careful thought should be given in developing the logical

Chapter 3. Implementation planning

59

design. The design becomes more complex over time and therefore is harder to modify. A good physical design could be easily invalidated if the logical design is not well planned and executed. The logical design process includes the following high-level considerations: Naming convention Customers and Divisions Monitored Nodes Administrators Logical Design example

3.2.1 Naming convention


It is extremely important that a naming convention for each element of the logical architecture be defined. It is also important that all personnel who create new resources understand and adhere to this naming convention. If a naming convention is not followed, the Tivoli administrators will eventually lose track of the internal structure of the IBM Tivoli License Manager environment. A benefit of following a well-constructed naming convention is that the environment becomes almost self-documenting, and limited additional documentation is required to understand the relationships of the different parts of the environment. Also, a good naming convention within the Tivoli environment lends itself to automation through scripting.

Naming policies
During the logical design phase, you should define naming policies based on the following examples. They must be respected during the whole life of the solution and reviewed during each phase of the IBM Tivoli License Manager solution life cycle. For example: Names must not contain spaces or special characters. Names must consist of alphanumeric characters, dash (-) or underscore (_). Names must contain only US ASCII characters (based on the product limitation).

3.2.2 Customer considerations


As seen in Chapter 2, IBM Tivoli License Manager general overview on page 11, Customers are the highest level of the IBM Tivoli License Manager Topology hierarchy. The Customer owns all components of the Topology, the Runtime servers, the Agents, the Divisions and the Licence entitlements. You can have more than one Customer in your architecture.

60

Introducing IBM Tivoli License Manager

The Topology hierarchical structure has and must have only two levels. The first being the Customer, the second is defined by Divisions. If you plan to use IBM Tivoli License Manager to manage different business customers, each of these have to be defined as an ITLM Customer in the logical design and their business Divisions should become ITLM Divisions. However, if you plan to only manage your enterprise and in fact only one business customer, you may plan to define business Divisions as Customers in the logical design and some business sub-divisions as Divisions. This can offer you a higher level of granularity in licence management within your enterprise. You need to provide an Account ID for each Customer. For business customer management, this can be the customer number. Otherwise, the cost center can be used if you plan to use Customers for your business Divisions.

3.2.3 Division considerations


Divisions are the second level of the hierarchical structure. You should have at least one Division defined per Customer. Each Agent should be subscribed to one and only one Division. They will be used to define the inventory scan frequencies, reports, and licence pool assignments. Each Customer can have only one Division. However, by splitting the structure to more than one Division will give you more flexibility to manage the flow of inventory data, because the inventory scan frequency can only be applied by Division. Otherwise, all Agents within your organization will upload the scanned information at the same time and may create a network bottle neck.

3.2.4 Monitored Nodes considerations


Agents are the resources to be monitored for licence usage. They must be subscribed physically to one Runtime server and logically to one Division; the first subscription not being linked with the second. The Agent can be connected to a remote Runtime Server in case its Division is logically split into different physical locations. For more information about the placement of Runtime servers, refer to 3.4.7, Planning for IBM Tivoli License Manager Runtime Server on page 90. When you register a new Agent, you need to provide a Computer Label, which is also referred to as the Tag in a Node definition. This information must be unique for each Agent and must be based more on business information than on technical characteristics. For example, if you already deployed an Asset Management in your enterprise, each machine must have an Asset Tag which is normally linked with financial information and/or a cost center. By using the same information as a Computer Label in your IBM Tivoli License Manager

Chapter 3. Implementation planning

61

environment, you will be able to integrate the two solutions more easily, in order, for example, to charge the software licence usages to a cost center.

3.2.5 Administrator considerations


Tivoli Administrators are responsible for managing various aspects of enterprise wide licence management. IBM Tivoli License Manager allows administrative functions that may be performed at the highest level of the organization, which is the Administration server, or at the lowest level, which is the Runtime server. To define an ITLM Administrator, it is necessary to understand the roles and the responsibilities that a given administrator will endorse. The definition of administrators is best addressed by asking the questions: What management tasks will the administrators perform? Where will the administrator have to manipulate the information? Within the IBM Tivoli License Manager environment, the scope of access control to resources is defined as follows: At the Administration server level: The Administrator defined at the Administration server level is only able to use the Administration server interface and to receive notifications generated by the Administration server. The different users roles at the Administration server level are: Administrator Licensing manager The Administrator can perform all tasks on the Administration server Web interface. The Administrator can perform the licensing tasks that are accessed using the Software Entitlement menu option of the Administration server Web interface. The Administrator can request any report that is accessed using the Software usage and Software inventory menu options of the Administration server Web interface.

Other

At the Runtime server level: The Administrator defined at the Runtime server level is only able to use the Runtime server Web interface and to receive notifications generated by the Runtime server.

62

Introducing IBM Tivoli License Manager

Note: An Administrator defined at the Administration server level cannot access the Runtime server Web interface. The same is valid for an Administrator defined at the Runtime server level accessing the Administration server Web interface. If an Administrator should access the ITLM servers, he/she needs to be defined on each server. The default Root user is tlmroot and its default password is system. This user ID cannot be deleted nor can its logon name be changed. However, we strongly recommend that its password is changed. This user ID is also defined on each Runtime server and even if you change the password at the Administration server level, you need to change its password on each Runtime server. We recommend that the use of the tlmroot user is restricted only for operations that need these types of privileges, for example, the Administrator definition on Runtime servers. Furthermore, if you plan to audit the security access, we recommend that each user has its own login. We also recommend if a Security Officer is in charge of all IT Security aspects within your enterprise to let him/her manage the Administrator definitions. Some information regarding the financial aspect of the licences can be confidential and may not be accessed by non-authorized persons. Table 3-1 can help you to plan and manage the Administrator definition.
Table 3-1 Planning for Administrator definition

IBM Tivoli License ManagerAdministrator definition User Name Logon Name E-Mail
<Full name of the user> <The name that will be used to access the Web interface> <For servers notification>

Administration Sever Role


<Administrator / Licence Manager / Other>

Notification

<Yes/No>

Customer

<list of all customer managed by this Administrator>

Runtime Server Server Name Server Name


<Server 1> <Server 2>

Notification Notification

<Yes/No> <Yes/No>

Chapter 3. Implementation planning

63

3.2.6 Logical design example


Here we provide a fictitious example of managing the licenses of a subset of IBM Corporation. Instead of defining IBM Corporation as the Customer, we decided to define the IBM countries, in an IBM physical organization point of view, and the IBM regions, in an IBM logical organization point of view, as Customers because some IBM Divisions are not dependent on a country. However, Figure 3-2 is only a part of the IBM Corporation license management example.

C
IBM EMEA Adm.

D
IBM Tivoli Adm.

E
IBM Switzerland Adm.

F
IBM Switzerland Adm.

IBM EMEA Customer

IBM Switzerland Customer

HR Division

Financial Division

Consulting Division

IT Division

HR Spec. Admin Users Controllers Financiers

Analysts

Consultants

Operators

IT Spec.

K
EMEA Runtime server

L
Swiss Runtime server

M
Swiss Runtime server

Figure 3-2 IBM Tivoli License Manager logical design example

64

Introducing IBM Tivoli License Manager

The legend used in that example is related to specific decisions of the logical design and explained as follows: A B C This customer groups all EMEA Divisions that are not specifically related to country. This customer groups all Switzerland Divisions that act only for this country. Because the customer defined in A doesnt have a large number of Nodes and Runtime servers, we decided that one ITLM Administrator is enough. However, this Administrator will have only the Licensing Manager role. The administration tasks of the IBM Corporation environment will be assumed by a World Wide Administration team. We also decided to create the same user on the Customers Runtime server in order for him to get the real time reports. Even if the administration management is made from a central location, we have defined a specific Tivoli Administrator in charge of all administration tasks for these two customers. This Administrator has the Administration server level. We havent created the same user on the Runtime server, because he is in charge of only administration tasks, and doesnt need access the Real time reports. The customer defined in B is bigger than A. We decided to split the responsibilities of the IBM Tivoli License Manager administration for this customer. The first Administrator is in charge of the licence management and has only the Licensing Manager role. The second one is in charge of the Real Time reports on the Runtime servers and is only defined on those servers. To gain more flexibility in licence management, we decided that each business Division of each IBM country or region will be represented as a Division. During the Physical Design phase, we analyzed that, for Customer A, one Runtime Server would be enough regarding the number of nodes to manage and the small network requirements. This Runtime server is defined to support the Divisions G and H. Furthermore, the inventory scan frequency will be different for each Division. This will avoid the overload of the Runtime server during the inventory scan. The Division J has a large number nodes to be managed. Based on this, and the fact that there is no network constraints, we decided to implement two Runtime Servers for the Customer B. In order to avoid an overload of the Runtime server M, some nodes of the Division J are registered to the Runtime server L, which can easily support this overload even if it manages the nodes of Division I. Therefore, the management of Division J is split in two Runtime servers.

E, F

G, H, I, J

L, M

Chapter 3. Implementation planning

65

3.3 Disaster and recovery


As organizations become more dependent on information and communication technology to conduct their business and to stay competitive, the availability of the computer systems have become crucial. If computer systems become unavailable, the business processes can come to a halt. A lengthy outage in a computing environment can result in significant financial losses. More importantly, you can lose customer credibility and subsequent market share. In some cases, such losses can lead to the total failure of the business. The following reasons are examples that can be used as requirements in order to define a Disaster Recovery plan for an IBM Tivoli License Manager solution: The ITLM environment contains the definition of the licences agreements. The ITLM environment may contain important financial information. Users may not be able to start applications if the ITLM environment cannot reply to licence requests. The outage could be due to numerous reasons such as hardware failure, software failure or deletion, a security breach, a disaster at the site, and so on. This section addresses the situation where the IBM Tivoli License Manager environment failed due to a disaster. Unless you have a recovery system in place, you will have difficulty in recovering within a reasonable period of time. The recovery planning is a large subject in itself; however, use this information as a guideline while planning your IBM Tivoli License Manager solution. The more preventative measures you plan, the lower the chances are of a situation resulting in a disaster to the organization. No matter how sophisticated your preventative measures, there is always some risk of an outage. You can reduce the risk of outages as you increase the cost of preventing them, but you cannot totally eliminate the possibility. Therefore, the recovery system should be a crucial element of an organization's strategic business plan.

3.3.1 Backup and restore


When hardware or software failures occur, backups provide the necessary means for quick and simple recovery. It is essential to create a recovery plan that defines what backups are performed and at what time interval they run in the IBM Tivoli License Manager environment. A good and recent backup of the different components of the whole IBM Tivoli License Manager solution allows a quick and easy recovery back to normal operations.

66

Introducing IBM Tivoli License Manager

A high-availability design provides protection against hardware failures primarily through the use of redundant hardware. Sometimes, however, a high availability configuration is not available or it does not work in situations where software has failed, databases have become corrupt, or files have been accidentally deleted. The way to recover from these software failures is to prepare regular maintenance procedures. For every failure scenario, develop and design a corresponding plan of action to recover from these failures. The following section provides a specific maintenance overview for each of the IBM Tivoli License Manager components.

Backup and restore for support applications


This section provides backup and restore information for the IBM Tivoli License Manager support applications.

IBM DB2 Universal Database Enterprise Edition


The IBM Tivoli License Manager Administration and Runtime servers store all information in a RDMS system. To restore this information as fast as possible if a recovery process must be started, it is important to back up the databases on a daily basis. Furthermore, we recommend that you keep at least five different levels of backup files. For more information regarding how to back up and restore the IBM DB2 Universal Database Enterprise Edition Databases, refer to this documentation:
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2hae71.pdf

In case of a problem with the IBM DB2 Universal Database Enterprise Edition application itself, you can reinstall the software using the procedure described in Chapter 4, Getting IBM Tivoli License Manager up and running on page 99. When the RDBMS is up and running again, you can restore the Administration and/or Runtime Server databases. However, if you have no back up of these databases, all information regarding the logical design is lost. Important: A database is present on all Runtime Servers and contains information regarding the Agents managed by each of them. Each database on Runtime servers needs to be backed up.

IBM WebSphere Application Server


The IBM Tivoli License Manager servers are running on top of the IBM WebSphere Application Server. If this support application must be reinstalled, you only need to register the IBM Tivoli License Manager servers once again using the procedure in Chapter 4, Getting IBM Tivoli License Manager up and running on page 99. However, you should at least save the IBM WebSphere Application Server configuration files as soon as the servers registrations are

Chapter 3. Implementation planning

67

done. For more information about how to back up and restore IBM WebSphere Application Server configuration files, refer to this documentation:
http://www-3.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/was/061 0.html

Backup and recovery for ITLM components


IBM Tivoli License Manager doesnt provide any backup tool/script, because all relevant information is stored in the RDBMS. However, it is important to back up all configuration files of the Administration and Runtime servers as soon as you have modified them. Configuration files are installed in the following location: Administration server <TLM_INSTALL_DIR>/admin/conf, where <TLM_INSTALL_DIR> is the ITLM installation directory Runtime server <TLM_INSTALL_DIR>/runtime/conf, where <TLM_INSTALL_DIR> is the ITLM installation directory If the IBM Tivoli License Manager application needs to be reinstalled, you can restore the configuration files in the same directory from where you backed them up to again apply your customizations. Because the monitored nodes inherit the Agent settings from their Runtime server, there is no need to save any local configuration file.

3.3.2 Failover considerations


A failover solution is generally designed to help ensure the availability of specific systems. The complexity of a failover solution mainly depends on how long you accept a disruption of the IBM Tivoli License Manager environment, by knowing that a user may not start its application, because no server could answer its licence request. In the context of the IBM Tivoli License Manager application, a high availability solution must include too many applications and will be very costly. A less expensive solution can be designed if a Storage Area Network (SAN) is already deployed in your enterprise. The File Systems of the Administration server can be created on a SAN partition. So, in case of a hardware problem, the physical machine can be rapidly replaced and there will be no need to reinstall the system, because the data will accessed from the SAN partition. Furthermore, the SAN topology offers a good hard disk mirroring solution. Of course, this does not avoid the utility of a regular backup of main configurations files.

68

Introducing IBM Tivoli License Manager

If no SAN solution is deployed in your enterprise, we recommend that the Administration server machine supports at least RAID 0 or RAID 5 capability.

3.4 Planning for IBM Tivoli License Manager


IBM Tivoli License Manager runs on top of the IBM WebSphere Application Server and stores relevant licensing information into a RDBMS. In this first release, only IBM DB2 Universal Database Enterprise Edition is supported as the RDBMS. Support for additional RDBMS may be addressed in future releases. IBM Tivoli License Manager is shipped with a Limited Use license for both IBM WebSphere Application Server Advanced Edition and IBM DB2 Universal Database Enterprise Edition (DB2). These may only be installed for direct use with IBM Tivoli License Manager. This section gives a brief introduction into planning for supporting applications and for the different components of IBM Tivoli License Manager. For specific information, refer to the product support manuals and related publication for each application. As mentioned in Chapter 2, IBM Tivoli License Manager general overview on page 11, IBM Tivoli License Manager uses the following support applications, which must be correctly installed and configured before the installation of IBM Tivoli License Manager can commence: IBM DB2 Universal Database Enterprise Edition HTTP Server Proxy Server This application is not mandatory but can be used to filter the communication between the Administration server and the Runtime server and between the Runtime server and its Agents. IBM WebSphere Application Server After the installation of the supporting applications, you need to install the different components of IBM Tivoli License Manager before starting using it: IBM Tivoli License Manager Administration server IBM Tivoli License Manager Runtime server IBM Tivoli License Manager agents IBM Tivoli License Manager Catalog Manager

Chapter 3. Implementation planning

69

3.4.1 Planning overview


This section provides an overview of the complete IBM Tivoli License Manager installation process. This includes the order of the installation of supporting applications which could assure a viable IBM Tivoli License Manager solution and also the order of the IBM Tivoli License Manager components installation, which could assure a successful registration process. Figure 3-3 shows the entire installation process and the order of the supporting application and IBM Tivoli License Manager components installation.

Phase 1
1. Install IBM DB2 UDB EE & FP 2. Install HTTP Server 3. Install IBM WebSphere Application Server & FP 4. Install ITLM Administration server 5. Populate ITLM Administration DB 6. Deploy the Logical Design: create Administrators, Customers, Divisions and Runtime Servers. 6a. Nodes and Users could be created if designed

Administration server

TLMA (from 5)

Phase 2
7. Install IBM DB2 UDB EE & FP 8. Install HTTP Server 9. Install IBM WebSphere Application Server & FP 10. Install ITLM Runtime server 11. Populate ITLM Runtime DB N.B.: Physical Design must be respected

Runtime server

TLMR (from 11)

Runtime server

TLMR (from 11)

Phase 3
11.(opt.) Create Nodes 12. Deploy ITLM Agents

Monitored node

Monitored node

Monitored node

Monitored node

Figure 3-3 Planning overview for IBM Tivoli License Manager

70

Introducing IBM Tivoli License Manager

3.4.2 Planning for IBM DB2 Universal Database Enterprise Edition


IBM Tivoli License Manager Administration and Runtime Server databases runs in an IBM DB2 Universal Database Enterprise Edition environment allowing them to store all Customers licensing information. IBM Tivoli License Manager ships a version of the IBM DB2 Universal Database Enterprise Edition. You are authorized to install and use one copy of these components per IBM Tivoli License Manager Administration Server and one copy of these components per IBM Tivoli License Manager Runtime Server only in association with your licensed use of the IBM Tivoli License Manager for the storage and management of data generated and used by the IBM Tivoli License Manager, and not for other data management purposes. You are authorized to install and use DB2 components only with and on the same machine as the IBM Tivoli License Manager. This license does not include data manipulation or reporting by programs not provided as part of the IBM Tivoli License Manager solution. If you have already deployed an IBM DB2 Universal Database Enterprise Edition production environment in your enterprise, for performance reasons, we recommend that you do not share it with the IBM Tivoli License Manager environment and use a brand new installation of IBM DB2 Universal Database Enterprise Edition. Because we recommend that you install a new environment, we also recommend that you use the IBM DB2 Universal Database Enterprise Edition installation media provided with the IBM Tivoli License Manager product. This ensures that you get the correct version and fixes for this support application. However, if you decide to use the IBM DB2 Universal Database Enterprise Edition already deployed in your environment, its version must be 7.2.7 and you need to install the IBM DB2 Universal Database Enterprise Edition Runtime Client 7.2.7 on each IBM Tivoli License Manager Administration and Runtime server. To access the complete IBM DB2 Universal Database Enterprise Edition reference library visit the DB2 Technical Support at the following link:
http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7pubs.d2w/ en_main

Hardware requirements
The hardware requirements mainly depend on the size of your databases and on the administration tools you will use, however Table 3-2 lists the minimum requirements. These requirements are only for the IBM DB2 Universal Database Enterprise Edition, and you should also take in consideration the hardware requirements for the others components.

Chapter 3. Implementation planning

71

Table 3-2 Hardware requirements IBM DB2 UDB Enterprise Edition

HW
Processor RAM Hard Disk

Intel Platforms
500Mhz Pentium 128 MB minimum 256 MB recommended Server: A typical installation requires a minimum of 245 MB of disk space, this includes the online product documentation, tools, and the Java Runtime Environment. Client: 475 MB of disk space, this includes tools and documentation Total: 720 MB of disk space

Non-Intel Platforms
AIX: RS/6000 at 375Mhz 128 MB RAM minimum 256 MB recommended Server: A typical installation requires a minimum of 300 MB of disk space, this includes the online product documentation, tools, Client: 270 MB of disk space, this includes tools and documentation Total: 570 MB of disk space

Other Network

CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet

CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet

For more information concerning the Hardware requirements for IBM DB2 Universal Database Enterprise Edition 7.2.7 visit the DB2 Technical Support at the following links: For Windows
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2v6e70.pdf

For UNIX
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2v3e70.pdf

Software requirements
Before starting the installation of the IBM DB2 Universal Database Enterprise Edition, you should have installed the minimum product levels listed in the Table 3-3. Because only the Microsoft Windows NT Server, Microsoft Windows 2000 Server, and the IBM AIX operating systems are supported by IBM Tivoli License

72

Introducing IBM Tivoli License Manager

Manager for the Administration and the Runtime servers, only information regarding these operating systems is provided.
Table 3-3 Software requirements IBM DB2 UDB Enterprise Edition

SW
AIX 4.3 or later Windows NT Server 4.0 SP 5 or later Windows 2000 Advanced Server 2000 SP1 or SP2 Windows 2000 Server 2000 SP1 or SP2

WNT Server

W2000 Server

IBM AIX
X

For a complete list of software requirements for IBM DB2 Universal Database Enterprise Edition visit the DB2 Technical Support at the following links: For Windows
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2v6e70.pdf

For UNIX
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2v3e70.pdf

It is also important to notice that the installation sequence is IBM DB2 Universal Database Enterprise Edition 7.2 first, and then the IBM DB2 Universal Database Enterprise Edition 7.2 Fix Pack 7. The Fix Pack can be found on the IBM Tivoli License Manager installation media or can be downloaded from the following link:
http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2 w/report

Attention: If you installed the IBM DB2 Universal Database Enterprise Edition 7.2, in a 32 bit version on an AIX 5L version, you need to install the IBM DB2 Universal Database Enterprise Edition 7.2 Fix Pack 7 also in a 32 bit version instead of IBM DB2 Universal Database Enterprise Edition 7.2 Fix Pack 7, in a 64 bit version. The Release Notes for the IBM DB2 Universal Database Enterprise Edition 7 can be downloaded from the following link:
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2ire72.pdf

Chapter 3. Implementation planning

73

The Release Notes for the IBM DB2 Universal Database Enterprise Edition 7.2 Fix Pack 7 can be downloaded from the following link:
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2ir_v7fp7.pdf

Network considerations
The IBM DB2 Universal Database Enterprise Edition utilizes some specific TCP/IP ports. You can then change these ports, but you need to carefully read the DB2 documentation on how to make the changes. For UNIX: Consider these ports (Table 3-4). The services file for UNIX can be located in the /etc directory.
Table 3-4 DB2 network ports for UNIX

Port
50000

Service Name
db2cdb2<your DB2 instance name> (default is db2cdb2inst1) db2cdb2<your DB2 instance name> (default is db2idb2inst1)

Notes
Connection port used for communication with your DB2 instance. This port is reserved in the services files but is not an official reserved port. Interrupt port used for communication with your DB2 instance. This port is reserved in the services files but is not an official reserved port.

50001

For Windows: Consider these ports (Table 3-5). The services file for Windows could be located in the %SYSTEM32%\drivers\etc directory.
Table 3-5 DB2 network ports for Windows

Port
523

Service Name
db2cDB2DAS00

Notes
Connection port used for communication with the DB2 instance DBsDAS00. This port is officially reserved in the services files. Interrupt port used for communication with the DB2 instance DBsDAS00. This port is officially reserved in the services files. Connection port used for communication with the DB2 instance. This port is reserved in the services files but is not an official reserved port.

524

db2iDB2DAS00

50000

db2cDB2

74

Introducing IBM Tivoli License Manager

Port
50001

Service Name
db2iDB2

Notes
Interrupt port used for communication with the DB2 instance. This port is reserved in the services files but is not an official reserved port. Connection port used for communication with the DB2CTLSV instance. This port is reserved in the services files but is not an official reserved port. Interrupt port used for communication with the DB2CTLSV instance. This port is reserved in the services files but is not an official reserved port.

50002

db2cDB2CTLSV

50003

db2iDB2CTLSV

What information you need for installation


The IBM DB2 Universal Database Enterprise Edition installation process will ask you to provide some information. The following list provides you all of the information that you will be requested to fill in and some advice about the values you can use. During the IBM DB2 Universal Database Enterprise Edition 7.2 installation: As a user with the Administration role on the server, you want to install the IBM DB2 Universal Database Enterprise Edition. For Windows: This user must also have at least these user rights defined in the local security settings of the server: Act as part of the operating system Create a token object Increase quotas Replace a process level token

For Unix: This user must have the root authority. To select the products you are licensed to install. Regarding the licence agreement provided with IBM Tivoli License Manager for IBM DB2 Universal Database Enterprise Edition, you can install the DB2 UDB Enterprise Edition.

Chapter 3. Implementation planning

75

For Unix only, to define a new user that will be used for the DB2 Instance. We recommend that you use the default db2inst1 user with its default db2iadm1 group. If this user doesnt exist on your system, the installation process will create it. The destination directory for the installation. Refer to 3.1.7, File systems considerations on page 56 for recommendations. To create a new user which will be used by the Control Center Server to log on to the system. For Windows: We recommend that you use the default db2admin user. If this user doesnt exist on your system, the installation process will create it. You can also decide to use the same user for the following services to log on your system: Administration Server Default instance Console Server instance

You can also decide to create a new user for each service. Except for strong Security requirements, we advise that you use the same user for all of these services. For UNIX: We recommend that you use the default db2as user with its default db2asgrp group. If this user doesnt exist on your system, the installation process will create it. Definition of a Control Database. For Windows: If you decided to use a different user for all services, you will be asked to define a Control Database. We recommend that you use the default values for the database and just change the user who will be become the owner of this Control Database. You will also be asked to define the DB2 super user in this case. For UNIX: We recommend that you use the default name for the Control Database which is dwcntrl. OLAP installation option. You dont need to install the OLAP Starter Kit.

76

Introducing IBM Tivoli License Manager

Product Registration. This part is important if you want to get product information or support news, but it is not mandatory. During the IBM DB2 Universal Database Enterprise Edition Fix Pack 7 installation: For Windows only, the Control Database Owner password. If you decided to use the default DB2 user, which is db2admin, you need to provide the password of this user. Otherwise, if you have configured a specific user for this Control Database, you should provide the password of this user. For Unix only, the DB2 Instance Owner password. If you decided to use the Default DB2 Instance user, which is db2inst1, you need to provide the password of this user. Otherwise, if you have configured a specific user for this DB2 Instance, you should provide the password of this user.

3.4.3 Planning for HTTP Server


IBM Tivoli License Manager Version 1.1 only supports two HTTP Servers: the IBM HTTP Server from IBM Corporation and the Internet Information Services (ISS) Server from Microsoft Corporation. The supported HTTP Servers are: IBM HTTP Server 1.3.12.6 (packaged with WebSphere 3.5.6) IBM HTTP Server 1.3.19.3 (packaged with WebSphere 4.0.4) Microsoft ISS Version 5.0 (packaged with Windows 2000 Server / Advanced Server) If you plan to use the ISS Server for Windows platforms, you dont need to install the IBM HTTP Server from the IBM WebSphere Application Server installation process. Otherwise, you can install the IBM HTTP Server using the IBM WebSphere Application Server installation process. Nevertheless, by default, the IBM Tivoli License Manager servers are configured to use the standard HTTP port which is 80. If you have more than one HTTP server running on the IBM Tivoli License Manager servers, we advise you to configure the HTTP server used by IBM Tivoli License Manager to use port 80 in order to simplify the installation process. However, you can change the default port for the supported HTTP servers using the following procedures: For the IBM HTTP Server, you have to edit the httpd.conf file and change the Port value from 80 to the desired one.

Chapter 3. Implementation planning

77

For the ISS server, refer to the Microsoft Knowledge Base Article - 149605 which is located at the following link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;149605

Important: If you plan to use the default HTTP port either for ISS server or IBM HTTP Server, make sure that no other HTTP server installed on your machine is also using the default HTTP port. If there are other HTTP servers installed, you need to change the ports of your other HTTP servers by carefully reading the documentation provided with the application. However, if you decide to change the default HTTP port for the HTTP server you plan to use, you need to report this change also in the VirtualHost section of the WebSphere Administration console. To access the complete IBM HTTP Server reference library visit the IBM HTTP Server InfoCenter at the following link: http://www-3.ibm.com/software/webservers/httpservers/doc/v1319/index.ht ml To access the complete Microsoft Internet Information Services reference library visit the Microsoft support site at the following link: http://support.microsoft.com/default.aspx?scid=fh%3Ben-us%3Biis50&x=4&y =7#faq605

Secure Sockets Layer


SSL is an encryption system used on servers to ensure privacy when transmitting information across the Internet. SSL-enabled servers encrypt sensitive data into ciphertext before sending it to clients, preventing third parties from reading the data, even if it is intercepted. Clients receiving data from the server then decrypt the ciphertext to read the data. SSL uses a security handshake to initiate a secure connection between the client and the server. During the handshake, the client and server agree on the security keys they will use for the session and the algorithms they will use for encryption. The client authenticates the server; optionally, the server can request the client certificate. After the handshake, SSL is used to encrypt and decrypt all the information in both the HTTPS request and the server response, including: The URL the client is requesting The contents of any form being submitted Access authorization information, such as user names and passwords All data sent between the client and the server

78

Introducing IBM Tivoli License Manager

HTTPs is a unique protocol that combines SSL and HTTP. A client user can open a URL by specifying https:// to request an SSL-protected document. The standard SSL protocol can be used to encrypt the communication between the Administration and Runtime Server and between the IBM Tivoli License Manager servers and the Web browsers accessing ITLMs Web Interfaces. If you plan to use SSL, you need to configure your HTTP server in order to accept SSL requests. For more information about how to configure the IBM HTTP server for SSL, refer to 4.2.8, Setting up SSL configuration on page 115. Note: SSL uses the port 443 as the default port. This port is officially registered in the services file located in /etc for UNIX and in %SYSTEM32%\drivers\etc for Windows. If you plan to use another default port for SSL, you need to specified this port during the installation of the IBM Tivoli License Manager Runtime Server.

Note: If you plan to use the SSL encryption, you need to configure the VirtualHost section of the WebSphere Administration console with the port you defined for SSL.

3.4.4 Planning for Proxy server


A Proxy server is a server that acts as an intermediary between a workstation requester and the Internet or intranet so that the enterprise can ensure security, administrative control, and caching service. It is associated with or part of a gateway server that separates the enterprise network from the outside network or from other enterprise networks and a firewall server that protects the enterprise network from outside intrusion. A Proxy server can be used either to filter the request from a Runtime server to the Administration and/or the request from an Agent to its Runtime server. It receives a request for an Internet service from a Runtime server or an Agent. If it passes filtering requirements, the Proxy server, acting as a client on behalf of the requester, uses one of its own IP addresses to request the information from the Administration or Runtime server. When the information is returned, the Proxy server relates it to the original request and forwards it on to the Runtime server or the Agent. You can use whatever Proxy server you want or use one you already deployed in your enterprise. If you plan to use a Proxy server in your IBM Tivoli License Manager environment, you need to update the Runtime and Agent configuration files

Chapter 3. Implementation planning

79

according to the instructions in the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.

3.4.5 Planning for IBM WebSphere Application Server


IBM Tivoli License Manager Administration and Runtime Servers components run on the top of the IBM WebSphere Application Server, allowing them to be accessed through a supported Web browser. The supported versions are: IBM WebSphere Application Server Advanced Edition 3.5.6. IBM WebSphere Application Server Advanced Edition 4.0.4 IBM Tivoli License Manager ships a copy of IBM WebSphere Application Server Advanced Edition. For each IBM Tivoli License Manager server Proof of Entitlement (PoE), you are entitled to install and use, from the media provided with the IBM Tivoli License Manager, one copy of each of the IBM WebSphere Application Server components required to support your licensed use of the IBM Tivoli License Manager. Your use of the IBM WebSphere Application Server components is limited to use in support of IBM Tivoli License Manager and may not be used for any other purpose. If you have already deployed an IBM WebSphere Application Server production environment in your enterprise, for performance reasons, we recommend that you do not share it with the IBM Tivoli License Manager environment and use a brand new installation of IBM WebSphere Application Server. If you decide to use the existing WebSphere Application Server environment, ensure that it has the correct level required by IBM Tivoli License Manager. Because we recommend that you install a new environment, we also recommend that you use the IBM WebSphere Application Server installation media provided with the IBM Tivoli License Manager product. This ensures that you get the correct version and Fix Pack of this support application. However, we advise that you install the IBM WebSphere Application Server Advanced Edition 4.0.4 instead of IBM WebSphere Application Server Advanced Edition 3.5.6. To access the complete IBM WebSphere Application Server reference library visit the WebSphere Infocenter at the following link:
http://www-3.ibm.com/software/webservers/appserv/infocenter.html

80

Introducing IBM Tivoli License Manager

Hardware requirements
The hardware requirements mainly depend on the number of users accessing the IBM Tivoli License Manager Administration and Runtime Server, and Table 3-6 lists the minimum requirements. These requirements are only for the IBM WebSphere Application Server, you should also take into consideration the hardware requirements of the others components.
Table 3-6 Hardware requirements for IBM WebSphere Application Server

HW
Processor RAM Hard Disk

Intel Platforms
500Mhz Pentium 384 MB minimum 512 MB recommended 180 MB free disk space for the base application server 2 GB recommended for a full installation (including DB2 and HTTP server) CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet

Non-Intel Platforms
AIX: RS/6000 at 375Mhz 384 MB RAM minimum 512 MB recommended 220 MB free disk space for the base application server 2 GB recommended for a full installation (including DB2 and HTTP server) CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet

Other Network

For more information concerning the hardware requirements for IBM WebSphere Application Server Advanced Edition 4.0.4 visit the WebSphere Infocenter at the following link:
http://www-3.ibm.com/software/webservers/appserv/doc/v40/prereqs/hardware.htm

Software requirements
Before starting the installation of the IBM WebSphere Application Server Advanced Edition 4.0.4, you should have installed the minimum product levels listed in the Table 3-7. Because only the Microsoft Windows NT Server, Microsoft Windows 2000 Server, and the IBM AIX operating systems are supported by IBM Tivoli License Manager for the Administration and the Runtime servers, only information regarding these operating systems is related.

Chapter 3. Implementation planning

81

Table 3-7 Software requirements for IBM WebSphere Application Server

SW
AIX 4.3.3 4330-09 Maintenance Level + APAR IY19277 AIX 5.1 ML1 + APAR IY19236 Windows NT Server 4.0 SP 6a Windows 2000 Advanced Server 2000 SP1 or SP2 Windows 2000 Server 2000 SP1 or SP2 HTTP Server 1.3.19.3 Internet Information Server 5.0 (ISS) DB2 Enterprise Edition 7.2 FP7

WNT Server

W2000 Server

IBM AIX
X

X X X

X X

For a complete list of software requirements for IBM WebSphere Application Server Advanced Edition 4.0.4 visit the WebSphere Infocenter at the following link: http://www-3.ibm.com/software/webservers/appserv/doc/v40/prereqs/ae_v40 4.htm Notice that you need to first install IBM WebSphere Application Server 4.0.1 and secondly to install the IBM WebSphere Application Server 4.0 FixPack 4 to get IBM WebSphere Application Server 4.0.4. The FixPack can be found on the IBM Tivoli License Manager installation media or downloaded from the following link:
http://www-1.ibm.com/support/docview.wss?uid=swg24001635

The Release Notes for the IBM WebSphere Application Server Advanced Edition 4.0.1 can be downloaded from the following link: http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/ was/relnotes401.html

82

Introducing IBM Tivoli License Manager

The Release Notes for the IBM WebSphere Application Server Advanced Edition 4.0.4 can be downloaded from the following link: http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/ was/404RN.html

Network considerations
The IBM WebSphere Application Server utilizes some specific TCP/IP ports. Refer to the guidelines in Table 3-8 for port assignment, particularly notes about the effects of port changes on other WebSphere components.
Table 3-8 WebSphere network ports

Port
900

Service Name
Bootstrap

Notes
One for each application server. To change it, use the administrative console to modify ORB properties or update the orbSettings object in the application server configuration file. One for each application server. To change it, use the administrative console to modify OLT and Debugger properties. One for each application server. To change it, use the administrative console to modify the trace properties or modify the application server configuration file directly. One for each application server. To change it, use the administrative console to modify LSD properties or update the location service object in the service configuration in the application server configuration file. One for each application server. One for each product installation. To change it, modify the application server configuration file. One for each application server.

2012

Object Level Trace and Debugger DrAdmin

7000

9000

Location Service Daemon (LSD)

9080 9090

internal HTTP transport Administrative application Secure internal HTTP transport

9443

Chapter 3. Implementation planning

83

Port
Random

Service Name
ORB listener port for RMI/IIOP

Notes
One for each application server. To make the value static, add -Dcom.ibm.CORBA.ListenerPort=xxxx where xxxx is a valid TCP port (see guidelines below). For application servers, add the argument to the Command Line Arguments setting of the application server properties.

Important: If you are using or plan to use the WebSM (WEB Systems Management) on AIX 4.x or 5L, it is important to notice that WebSM uses 9090 as the default TCP/IP port. WebSphere also uses TCP/IP port 9090 for its Administration application. You can either change the WebSM default port by updating the websm.cfg file located in /usr/websm, or change the WebSphere default port by carefully reading the information below and the WebSphere documentation. Some considerations on TCP/IP ports: Ports can range from 1024 to 64000. Choose a port that does not conflict with existing ports in use. To check ports in use: Use the netstat -a command View the /etc/services file on UNIX View the %SYSTEM32%\drivers\etc\services file on Windows Ports must be unique in the scope of each physical host. That is, two servers on the same machine cannot have the same port values. The same port numbers can be used for servers running on different physical hosts. Remember to configure firewalls to allow traffic to pass for each assigned port. For security, try to minimize ports.

What information you need for installation


The IBM WebSphere Application Server Advanced Edition installation process will ask you to provide some information. The following list provides you all of the information that you will be requested to fill in and some advice about the values you can use. During the IBM WebSphere Application Server Advance Edition installation: As a user with the Administration role on the server you want to install the IBM WebSphere Application Server.

84

Introducing IBM Tivoli License Manager

For Windows: This user must also have at least the Act as part of the operating system and the Logon as a service rights defined in the local security settings of the server. For Unix: This user must have the root authority. A Typical or Custom installation. The IBM HTTP Server is part of the IBM WebSphere Application Server Typical Installation. If you plan to use another HTTP Server, you need to use the Custom Installation process and leave the IBM HTTP Server option unchecked. For Windows only, a user already existing on the machine, and its password, which will have the authorities to start the IBM WebSphere Application Server service and/or the IBM HTTP Server service. This user must have at least the Act as part of the operating system and the Logon as a service rights defined in your local security settings. The destination directory for the installation. Refer to 3.1.7, File systems considerations on page 56 for recommendations. A Database to store IBM WebSphere Application Server information. Because the IBM WebSphere Application Server will use an RDBMS to as support database, you should provide the following information: The Type of Database Please refer to the IBM WebSphere Application Server Advanced Edition product documentation for a list of supported databases. The Database name We recommend that you use the standard database name which should be was40. The Database user ID This user must have sufficient authorization to create a database in your database context. We advise that you use the default instance owner user ID, db2admin for Windows, or db2inst1 for UNIX. Directory or URL to access the data Depending on the type of database to de used, you need to provide the full path of the directory in which the database files will be stored or the URL, the name, and the port to access your database.

Chapter 3. Implementation planning

85

The Hostname of the server on which you plan to install the IBM WebSphere Application Server. The full path of the directory in which the file db2java.zip is located. During the IBM WebSphere Application Server Advance Edition FixPack 4 installation: Licence Acceptance Select the modules to update The following modules must be upgraded: Application Server You need to provide the full path where you have installed the IBM WebSphere Application Server Advance Edition. Application Server JDK JDK IBM HTTP Server If you have installed and decided to use the IBM HTTP Server, you need to upgrade it. You need to provide the full path where you have installed the IBM HTTP Server. Connector Architecture for WebSphere (J2C) Application Server Logs Backups installation file You need to provide a backup directory even if you dont want to backup the files during the upgrade process. The other IBM WebSphere Application Server modules dont need to be installed or upgraded.

3.4.6 Planning for IBM Tivoli License Manager Administration server


Only one Administration server can be installed in an IBM Tivoli License Manager environment. This server will be the central repository for all information regarding the licence management.

Hardware requirements
Hardware requirements mainly depend on the number of users accessing the IBM Tivoli License Manager Administration server, on the number of IBM Tivoli License Manager Runtime servers to be served, and on the number of Agents that will be managed. Table 3-9 lists the minimum hardware requirements and

86

Introducing IBM Tivoli License Manager

also includes the requirements of the other components, such as IBM DB2 Universal Database Enterprise Edition and IBM WebSphere Application Server.
Table 3-9 Hardware requirements for ITLM Administration server

HW
Processor RAM Hard Disk

Intel Platforms
1.5 Ghz Pentium 1 GB minimum 1 GB recommended 10 GB free disk space for the base application server, for the catalog manager, the components and for the data saved in the RDBMS

Non-Intel Platforms
AIX: RS/6000 at 450 Mhz 1 GB RAM minimum 1 GB recommended 10 GB free disk space for the base application server, for the catalog manager, the components and for the data saved in the RDBMS 100 MB more for the /tmp directory CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet

Other Network

CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet

For more information concerning the Hardware requirements for IBM Tivoli License Manager, refer to IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.

Software requirements
Before the installation of the IBM Tivoli License Manager Administration server, you should have installed the minimum product levels listed in the Table 3-10. Because only the Microsoft Windows NT Server, Microsoft Windows 2000 Server, and the IBM AIX operating systems are supported by IBM Tivoli License Manager for the Administration server, only information regarding these operating systems is listed.
Table 3-10 Software requirements for ITLM Administration server

SW
AIX 4.3.3 4330-02 Maintenance Level AIX 5.1 Windows NT Server 4.0 SP 6a

WNT Server

W2000 Server

IBM AIX
X X

Chapter 3. Implementation planning

87

SW
Windows 2000 Advanced Server 2000 SP1 or SP2 Windows 2000 Server 2000 SP1 or SP2 HTTP Server 1.3.19.3 Internet Information Server 5.0 (ISS) DB2 Enterprise Edition 7.2 FP7 WebSphere Application Server AE 3.5.6 WebSphere Application Server AE 4.04 Microsoft Internet Explorer 5.5 or higher Netscape Navigator 6.2 or higher

WNT Server

W2000 Server
X

IBM AIX

X X

X X

X X

X X

For a complete list of software requirements for IBM Tivoli License Manager, refer to the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.

Network considerations
The IBM Tivoli License Manager Administration server utilizes specific TCP/IP ports listed in Table 3-11.

88

Introducing IBM Tivoli License Manager

Table 3-11 IBM Tivoli License Manager Administration server network port

Port 9085

Service Name
WebSphere Administration port

Notes
This port is used by WebSphere to manage the IBM Tivoli License Manager Administration server. To change this port, read the procedure described in the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.

Note: The IBM Tivoli License Manager Administration Web interface will be accessed using the standard HTTP port 80 of the HTTP Server. If you have changed this port to another value, you need to use this new port in order to access the IBM Tivoli License Manager Administration Web interface.

What information you need for installation


The IBM Tivoli License Manager Administration installation process will ask for some information. The following list provides you all of the information you will be requested to fill in and some advice about the values you can use. As a user with the Administration role on the server you want to install the IBM Tivoli License Manager Administration. Licence Acceptance. You have to accept the licence agreement. Type of installation. Select only the Administration server installation type. To create the user tlmsrv. You need to have this user created, because it will be used to access the RDBMS. By editing the db.properties file in the <TLM_INTALL_DIR>/admin/conf directory of the Administration server. You will be able to specify a different user by changing the value of the dbUser clause. However, we recommend that you use the standard tlmsrv user to have the correct rights to access the RDBMS. Note: At the end of the IBM Tivoli License Manager Administration server installation, you need to create and populate the DB2 Database that will be used by the Administration server. Refer to 4.2.6, Creating DB2 schema for Administration server on AIX on page 113 for details.

Chapter 3. Implementation planning

89

3.4.7 Planning for IBM Tivoli License Manager Runtime Server


An IBM Tivoli License Manager environment can have several Runtime servers, but must have at least one. These servers will manage a group of Agents and will be the remote repository of the Administration database for all information regarding these Agents. Note: Before starting the installation of the Runtime servers, we strongly recommend that you first register these servers in the Customers topology. For more information, refer to 4.4, Setting up the ITLM Runtime server on Windows on page 131. The hardware and software requirements for the IBM Tivoli License Manager Runtime server are the same as the requirements for the IBM Tivoli License Manager Administration server. Refer to Table 3-9 on page 87 for hardware requirements and to Table 3-10 on page 87 for software requirements.

Network considerations
The IBM Tivoli License Manager Runtime server uses specific TCP/IP port as shown in Table 3-12.
Table 3-12 IBM Tivoli License Manager Runtime server network port

Port 9086

Service Name
WebSphere Runtime port

Notes
This port is used by WebSphere to manage the IBM Tivoli License Manager Runtime server. To change this port, refer to the procedure described in the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.

Note: The IBM Tivoli License Manager Runtime Web interface will be accessed using the standard HTTP (80) or HTTPs (443) port of the HTTP Server. If you have changed these ports to other values, you need to use these new ports in order to access the IBM Tivoli License Manager Runtime Web interface.

What information you need for installation


The IBM Tivoli License Manager Runtime installation process will ask you to provide some information. The following provides you all of the information you will be requested to fill in and some advice about the values you can use. As a user with the Administration role on the server you want to install the IBM Tivoli License Manager Runtime server.

90

Introducing IBM Tivoli License Manager

Licence Acceptation. You have to accept the licence agreement. Type of installation. Select only the Runtime server installation type. To create the user tlmsrv. This user ID has to be created for RDBMS access. If this user doesnt exist on our system, the installation process will create it. By editing the db.properties file in the <TLM_INTALL_DIR>/admin/conf directory of the Runtime server, you will be able to specify a different user by changing the value of the dbUser clause. However, we recommend that you use the standard tlmsrv user to have the correct rights to access the RDBMS. Configuration of the Runtime server. This step is very important. This will allow the Runtime server to be registered in the IBM Tivoli License Manager environment. However, it is important that the Runtime server is first defined in the Customers Topology at the Administration server before starting the installation. In this case, the Runtime server will be registered at the end of the installation process automatically. Otherwise, you will need to manually start the Runtime server once you have defined it in the Customers Topology. For more information about the Runtime server registration process, refer to 4.4, Setting up the ITLM Runtime server on Windows on page 131. You should provide the following information regarding the Registration process: Customer Name. A Runtime server must be part of only one Customer organization. The value provided must respect the physical and logical policies you defined, according to the description in Physical design on page 52 and Logical design on page 59. Runtime server name. A Runtime server must have a logical name to be identified by the Administration server. This name must be unique for each Runtime server of your entire IBM Tivoli License Manager environment. We advise that you use the fully qualified host name, because this one must be unique in your network environment, according to the description in Physical design on page 52. Runtime server password. This password must be the same as used during the Runtime server definitions in the Customers Topology. If you have decided to create the Runtime server after the installation, you should provide the same

Chapter 3. Implementation planning

91

password during the registration process. We advise you to use the same password for all Runtime servers within the same Customer organization. However, in case of strong security requirements, one different password can be provided for each Runtime server. Administration server access. In order for the Runtime server to contact the Administration server, you should provide the following: Administration server IP address. You need to provide the IP address of the Administration server. The fully qualified hostname may also be used. Administration server TCP port. This port will be used to communicate with the Administration server. We recommend the use of the default HTTP or HTTPs ports. In case you plan to use a port other than the HTTP and HTTPS default ports, specify the new ports using this parameter. SSL activation. If you plan to use SSL as the communication protocol, you need to provide an SSL password. It will be used to encrypt the communication between the Administration server and the Runtime server. This password can be changed by using the command rtpasswd.bat in the <ITLM_INSTALL_DIR>/runtime/cli directory of the Runtime server. Note: At the end of the IBM Tivoli License Manager Runtime server installation, you need to create and populate the DB2 Database that will be used by the Runtime server. Refer to 4.3.2, Creating DB2 schema for Runtime server on AIX on page 124 for details.

3.4.8 Planning for IBM Tivoli License Manager Agent


IBM Tivoli License Manager Agent runs silently on the machine and mainly performs inventory scan and software usage identification. An Agent can only be connected to one Runtime Server at the same time. The Agent can be deployed using two different strategies: 1. Installation from the Runtime Server, called Web-based installation 2. Installation using silent mode. This mode can be done in several ways, for example: Installation from a login script Installation from a script

92

Introducing IBM Tivoli License Manager

Installation using a Software Distribution tool like IBM Tivoli Configuration Manager or Microsoft Systems Management Server. Note: Appendix A, ITLM Agent installation using IBM Tivoli Configuration Manager on page 253 provides an example of an IBM Tivoli Configuration Manager Software package to install Agents.

Hardware requirements
Table 3-13 lists the hardware requirements for the IBM Tivoli License Manager Agent.
Table 3-13 Hardware requirements for IBM Tivoli License Manager Agent

HW
Processor RAM Hard Disk Other Network

Intel Platforms
Any Any 10 MB N/A Ethernet or Token Ring card Network connectivity to the internet

Non-Intel Platforms
Any Any 10 MB N/A Ethernet or Token Ring card Network connectivity to the internet

For more information concerning the hardware requirements for IBM Tivoli License Manager, refer to the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.

Software requirements
The IBM Tivoli License Manager Agent is currently supported on the following platforms. Support for additional platforms may be addressed in future releases: Windows 95/98 Windows ME Windows 2000 Windows NT 4 Linux Red Hat 7.0 for Intel-kernel 2.2.16-22 Linux SuSE 7.2 for s390-kernel 2.2.16 Linux Red Hat 7.0 for s390-kernel 2.4.9-17 Sun Solaris 2.7/2.8 (64 bit kernel) IBM AIX 4.3/5.1 (32 bit kernel) Before starting the installation of the IBM Tivoli License Manager Agent, you should have installed the minimum product levels listed in Table 3-14.

Chapter 3. Implementation planning

93

Table 3-14 Software requirements for IBM Tivoli License Manager Agent

SW
Microsoft Internet Explorer 5.0 or higher Netscape Navigator 4.7.x or higher Netscape Navigator 4.7.9

Windows
X

Linux/SUN

IBM AIX

For a complete list of software requirements for IBM Tivoli License Manager, refer to the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.

Network considerations
The IBM Tivoli License Manager Agent doesnt listen on any TCP port. In fact the Runtime server never contacts the Agent; it is the agent itself which contacts the Runtime server at each defined elapsed time. During this connection, the Runtime server down calls some information on the Agent using ephemeral TCP ports.

What information you need for installation


The IBM Tivoli License Manager Agent installation process will ask you to provide some information. The following list provides information that you will be requested to fill in and some advice about the values you can use independently of the strategy you will use to install the Agents.

Installing from the Runtime server


A Division An Agent must belong to only one Division in the Customers organization. The value provided must respect the physical and logical policies you defined, according to the description in Physical design on page 52 and Logical design on page 59. A Runtime server name By providing a Server Name, the agent will try to register to this server and will become an object of the Customers topology. The value provided must respect the physical and logical policies you defined, according to the description in Physical design on page 52 and Logical design on page 59.

94

Introducing IBM Tivoli License Manager

A Computer label Each agent needs to be uniquely identified. This value can be based, for example, on the following information: Asset Tag number Fully qualified host name Serial number of the machine Logical name depending on the capabilities of the machine

This value will be used to match the Node object of the Customers Topology. If this Tag doesnt correspond to any Nodes, the Agent deployment process will create it.

Using silent installation mode


Source path It is the location of the Agent installation files. A Division An Agent must belong to only one Division in the Customers organization. The value provided must respect the physical and logical policies you defined, according to the description in Physical design on page 52 and Logical design on page 59. A Computer label Each agent needs to be uniquely identified. This value can be based, for example, on the following information: Asset Tag number Fully qualified host name Serial number of the machine Logical name depending on the capabilities of the machine

This value will be used to match the Node object of the Customers Topology. If this Tag doesnt correspond to any Nodes, the Agent deployment process will create it. A Runtime Server By providing a Server Name, the agent will try to register to this server and will become an object of the Customers topology. The value of this field must be either the fully qualified host name or the IP address of the Runtime server. The value provided must respect the physical and logical policies you defined, according to the description in Physical design on page 52 and Logical design on page 59.

Chapter 3. Implementation planning

95

A TCP port This must be the Runtime server port. By default, the port is the default HTTP port which is 80. If you have planned to use another port the HTTP server, you have to provide the new value for this field. An URL This is the URL of the service process of the Runtime Server. The value must be set to /slmruntime/service. Customer name Even if an Agent will be part of a Division, you still need to provide the name of the Customer. The value you provided for the Division field must also be part of this Customers topology. The value provided for the Customer name must respect the physical and logical policies you defined, according to the description in Physical design on page 52 and Logical design on page 59. Proxy utilization This field cannot be empty, you have to provide either Yes or No as the value. The name of the proxy If you plan to use a proxy server to manage the data flow between the Runtime server and the Agent, you should provide either the fully qualified host name or the IP address of the Proxy server. If you dont plan to use a Proxy server, this field cannot be empty. You have to set this value to none. The port of the Proxy If you plan to use a proxy server to manage the data flow between the Runtime server and the Agent, you should provide the TCP port of the Proxy server. If you dont plan to use a Proxy server, this field cannot be empty. You have to set this value to 0. The trace activation You can enable the trace of the silent installation process. The possible value is y for yes and n for no. The name of the trace file is tlmia.trc and is located in the directory from where you start the installation of the Agent. Note: We advise you to put all of these arguments in double quotation marks ().

3.4.9 Planning for IBM Tivoli License Manager Catalog Manager


The Catalog Manager is a standalone tool that you can use to expand and make changes to the Master Catalog. The Master Catalog stores details of all products that can be monitored by IBM Tivoli License Manager.

96

Introducing IBM Tivoli License Manager

You can install this tool on any machine, but this component is normally installed on the same machine as the Administration server. The installation of the Catalog Manager doesnt require any specific information. To use it, you must extract the Catalog and Unknown File table from the Administration server Database. Once the changes are made, you must re-import the Catalog to the Administration server database.

Chapter 3. Implementation planning

97

98

Introducing IBM Tivoli License Manager

Chapter 4.

Getting IBM Tivoli License Manager up and running


This chapter describes the installation and configuration procedures to get IBM Tivoli License Manager (ITLM) up and running. The installation process is presented using a typical environment, as an example. The installation and configuration of the following IBM Tivoli License Manager components and prerequisite applications are discussed: IBM DB2 Universal Database Enterprise Edition IBM WebSphere Application Server Advanced Edition IBM HTTP Server (Included in IBM WebSphere Application Server) IBM Tivoli License Manager Administration Server IBM Tivoli License Manager Runtime Server

Copyright IBM Corp. 2003. All rights reserved.

99

4.1 Example scenario


In this section we present the scenario used to describe the installation process of the various components and prerequisite applications of an IBM Tivoli License Manager environment. This may be used as a starting point for anyone responsible for the deployment of the IBM Tivoli License Manager product. We assume that no pre-existing components will be used, and we describe the steps for a brand new installation. Please refer to Chapter 3, Implementation planning on page 51, for hardware and software requirements, as well as for tips and hints on how to best design your IBM Tivoli License Manager environment and leverage existing production environments.
ITLM Administration server
- RS6000 AIX 5.1 - IBM DB2 EE Server 7.2.7 - IBM WAS Adv Edition 4.0.4 - IBM HTTP Server 1.3.19.2 - ITLM Administration server 1.1 Accessing the Web interface

ITLM Runtime server


- RS6000 AIX 4.3.3 - IBM DB2 EE Server 7.2.7 - IBM WAS Adv Edition 4.0.4 - IBM HTTP Server 1.3.19.2 - ITLM Runtime server 1.1

ITLM Runtime server


- MS Windows 2000 Advanced Server - IBM DB2 EE Server 7.2.7 - IBM WAS Adv Edition 4.0.4 - IBM HTTP Server 1.3.19.2 - ITLM Runtime server 1.1

LAN

ITLM Agents - Platforms


- RS6000 AIX 4.3.3 - MS Windows 2000 Advanced Sever -MS Windows 2000 Professional

Figure 4-1 ITLM installation scenario

As shown in Figure 4-1, our environment is composed of five machines, as follows: 1. IBM Tivoli License Manager Administration Server machine RS6000 running AIX 5.1

100

Introducing IBM Tivoli License Manager

IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7) IBM WebSphere Application Server Advanced Edition Version 4.0 (plus Fixpack 4) IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Server Advanced Edition Version 4.0) IBM Tivoli License Manager Administration Server Version 1.1 2. IBM Tivoli License Manager Runtime Server machine RS6000 running AIX 4.3.3 IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7) IBM WebSphere Application Server Advanced Edition Version 4.0 (plus Fixpack 4) IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Server Advanced Edition Version 4.0) IBM Tivoli License Manager Runtime Server Version 1.1 3. IBM Tivoli License Manager Runtime Server machine Intel machine running Windows 2000 Advanced Server (plus Service pack 3) IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7) IBM WebSphere Application Server Advanced Edition Version 4.0 (plus Fixpack 4) IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Advanced Server Edition Version 4.0) IBM Tivoli License Manager Runtime Server Version 1.1 4. IBM Tivoli License Manager Agent machines (5 Nos.) Intel machines running Windows 2000 Professional, Windows 2000 Advanced Server, AIX IBM Tivoli License Manager Agent Software 5. IBM Tivoli License Manager Web Client machines(2 Nos.) Intel machines running Windows 2000 Professional Internet Explorer 5.5

Chapter 4. Getting IBM Tivoli License Manager up and running

101

The installation process for each of the Administration and Runtime server machines will be explained in the following sections. The installation process for the IBM Tivoli License Manager Agents will be covered in 5.7.3, Deploying an Agent on a node on page 160.

4.2 Setting up the ITLM Administration server


This machine, running the AIX 5.1 operating system, will serve as Administration server for the ITLM environment. It will contain a DB2 server hosting the Administration server database. The following components are needed: IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7) IBM WebSphere Application Advanced Server Edition Version 4.0 (plus Fixpack 4) IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Advanced Server Edition Version 4.0) IBM Tivoli License Manager Administration Server Version 1.1

4.2.1 IBM DB2 Server installation


This section describes the IBM DB2 Universal Database Enterprise Edition Server Version 7.2 installation process on AIX. Note: Use the DB2 installation media provided with the IBM Tivoli License Manager product. This ensures that you get the correct version and Fixpack of DB2 installed.

1. Log in as a user with root authority, move to the directory where the DB2 7.2 Server for AIX CDROM is mounted, and start the DB2 setup utility, as follows:
# ./db2setup

2. The Install DB2 V7 screen, as shown in Figure 4-2, appears. Select the DB2 UDB Enterprise Edition option.

102

Introducing IBM Tivoli License Manager

Figure 4-2 Install DB2 V7 - DB2 UDB Enterprise Edition

3. A New DB2 instance should be created for the Administration server database. We specified the DB2 instance name db2inst1, as shown in Figure 4-3.

Figure 4-3 Create DB2 Services - DB2 Instance db2inst1

Chapter 4. Getting IBM Tivoli License Manager up and running

103

4. Next, Figure 4-4 shows the values we used on the option Create the user ID for the DB2 Administration Server.

Figure 4-4 Administration Server screen

5. The installation process creates and sets the values of several environment variables, DB2SYSTEM, for example. 6. At the end of the installation process, you may check the installation log file created at /tmp/db2setup.log. 7. The installed JDBC code level needs to be upgraded to Version 2.0. You should log on to the system with a valid DB2 user ID, and issue the following commands: For bash, Bourne, or Korn shell:
# . INSTHOME/sqllib/db2profile # cd /INSTHOME/sqllib/java12/ # . ./usejdbc2

Where, INSTHOME is the home directory of the instance. Verify that the JDBC level is correct by entering the following command:
# echo $CLASSPATH

The output must include the following path:


INSTHOME/sqllib/java12/db2java.zip

104

Introducing IBM Tivoli License Manager

4.2.2 IBM DB2 Fixpack 7 installation


This session describes installation of DB2 Fixpack 7 on AIX. Here are the steps for installing IBM DB2 Fixpack 7. 1. Stop all database activity before applying this Fixpack. To stop all database activity, issue the commands:
# db2stop # db2admin stop

2. Unzip the Fixpack using the following command to get a tar file.
# gzip FP7_U484480.tar.Z

3. Un-tar the Fixpack using the following command to extract the file Fixpack files.
# tar -xvf FP7_U484480.tar

4. Run the following command to install Fixpack from the location you un-tar the Fixpack files.
# ./installFixpack

5. Key in the DB2 instance password if prompted. 6. The installation wizard copies the files and finishes the installation of Fixpack. Note: If you are using a 32-bit IBM DB2 Server, make sure to install the 32-bit Fixpack 7. Or if you are using a 64-bit IBM DB2 Server, make sure to install the 64-bit Fixpack 7.

4.2.3 IBM WebSphere installation


For our environment, we decided to use the IBM WebSphere Application Server Advanced Edition Version 4.0. In this section we describe the IBM WebSphere Application Server Advanced Edition Version 4.0 installation steps on AIX. To install IBM WebSphere Application Server Advanced Edition Version 4.0, perform the following steps: 1. Logged in as a user with root authority, issue the following command from the directory where the IBM WebSphere Application Server CD-ROM is mounted:
# ./install.sh.

2. You are then prompted to select the type of installation. We have selected Typical Installation, because it will automatically install all the required components, such as the WebSphere Application Assembly Tool (AAT). If you decide to use a different installation method, make sure you select the AAT option.

Chapter 4. Getting IBM Tivoli License Manager up and running

105

3. In the next panel, the installation wizard asks for the database information. WebSphere Server uses this database repository to store configuration information. In our scenario we used the local DB2 Server installed on the Administration machine.
Database type: DB2

You should also provide the database name to be created:


Database name (SID): was40

The DB2 instance owner home directory:


DB home: /home/db2inst1

And the user ID and password of the DB2 instance owner:


Database user id: db2inst1 Database password: ****

4. On the next panel you need to specify the installation directories. We used the default values /usr/WebSphere/AppServer and /usr/HTTPServer. 5. A final installation window informs you that the setup program has finished. 6. When the installation of WebSphere completes successfully, the window shown in Figure 4-5 appears. Select Start the Application Server.

Figure 4-5 IBM WebSphere Application Server configuration window

7. Open a Web Browser and type in the following URL:


http://WebSphere_Server:9090/admin

106

Introducing IBM Tivoli License Manager

Where, WebSphere_Server can either be the Administration servers host name or IP address. 8. This step is for IBM WebSphere Application Server Version 3.5.6 only. On the Administrator Console window, expand Resources -> JDBC Drivers -> Db2JdbcDriver. Click Db2JdbcDriver. Update the Server Class Path with the fully qualified path of the DB2 file db2java.zip. 9. You should recycle the IBM WebSphere Application Server by issuing the following commands:
# cd /<WebSphere_AppServer_Install_Directory>/bin # ./stopServer.sh # ./startServer.sh

Where, <WebSphere_AppServer_Install_Directory> is the directory where you installed the IBM WebSphere Application Server. 10.The IBM WebSphere Application Server runs as root and requires access to the IBM DB2 environment. You should insert the following line at the end of roots .profile file:
./home/db2inst1/sqllib/db2profile

(Assuming that the db2inst1 is the IBM DB2 instance owner.)

4.2.4 IBM WebSphere Fixpack 4 installation


Because IBM Tivoli License Manager Version 1.1 requires IBM WebSphere Application Server Advance Server 4.0.4, here we provide the steps for installing IBM WebSphere Fixpack 4. 1. Make sure you stop IBM HTTP Server and IBM WebSphere Application Server before installing the Fixpack, as follows: a. To stop the HTTP Server, type:
# cd /usr/HTTPServer/bin # ./apachectl stop

b. To stop the IBM WebSphere Application Server, type:


# cd /WebSphere_AppServer_Install_Directory/bin # ./stopServer.sh

2. Un-tar the Fixpack using the following command to extract the file Fixpack files.
# tar -xvf was40_ae_ptf_4_aix.tar

3. Run the following command to install Fixpack from the location you un-tar the Fixpack files.
# ./install.sh

Chapter 4. Getting IBM Tivoli License Manager up and running

107

4. During the installation of this Fixpack, the setup prompts for many questions. These questions allow you to select the modules that the Fixpack will update. In our case, we answered No to iPlanet and Apache updates, because we were using IBM HTTP Server. 5. Start the WebSphere Server manually.
# cd /<WebSphere_AppServer_Install_Directory>/bin # ./startServer.sh

Where, <WebSphere_AppServer_Install_Directory> is the directory where you installed the IBM WebSphere Application Server. Note: In order to have both the IBM HTTP Server and the IBM WebSphere Application Server you may add startup entries in the inetd.conf file.

4.2.5 ITLM Administration server installation


In this section we describe the steps to install IBM Tivoli License Manager Administration Server on AIX. Before starting the installation of IBM Tivoli License Manager on AIX, we recommend that you check the following: 1. Make sure IBM DB2 is running. To initialize the DB2 command line, type:
# ./home/db2inst1/sqllib/db2profile

2. Make sure IBM HTTP Server is running. To start the HTTP Server, type:
# cd /usr/HTTPServer/bin # ./apachectl start

3. Make sure IBM WebSphere Application Server is running. To start it, type:
# cd /usr/WebSphere/AppServer/bin # ./startupServer.sh

4. To monitor the Administration server installation, you may run the IBM WebSphere Application Server Administration console, as shown in Figure 4-6. In case of a successful installation, the ITLM Administration server will show up in the list of Application Servers, right after the Default Server entry.
# cd usr/WebSphere/AppServer/bin # ./adminclient.sh

108

Introducing IBM Tivoli License Manager

Figure 4-6 IBM WebSphere Application Server Admin console

To install IBM Tivoli License Manager Administration server on AIX, go through the following steps: 1. From the directory where the IBM Tivoli License Manager CDROM is mounted, enter the following command to initialize the installation wizard. For AIX, run the setupaix.bin script. It is located in setup directory of your CDROM.
# cd TLM11/setup # ./setupaix.bin

2. When the installation wizard displays the welcome to the IBM Tivoli License Manager Version 1.1 - server installation window, click Next to continue. 3. The installation wizard displays the next panel that shows you the License Agreement Panel. Click the option I accept, then Next to continue. 4. The dialog window for the IBM Tivoli License Manager installation directory appears. We used the default value /opt/IBM/TLM. Click Next. 5. The next panel enables you to select the installation type. There are three options. Administration, Runtime, and Custom. Select Administration,

Chapter 4. Getting IBM Tivoli License Manager up and running

109

because we are installing the Administration server. This is shown in Figure 4-7. Click Next to continue.

Figure 4-7 Installation type: Administration

6. The next window prompts you for the home directory of DB2 instance. We used the default: /home/db2inst1. Click Next. 7. The installation wizard then asks for the password for the user tlmsrv. This user will be used to connect and access the Administration database. This user will be created during the installation. Click Next. Note: In case you decide to install Administration Server and Runtime Server in the same machine, this password is valid for both databases. 8. The confirmation dialog window of the various ITLM features to be installed appears, as shown in Figure 4-8. Click Next to start the installation.

110

Introducing IBM Tivoli License Manager

Figure 4-8 Confirmation of installation options Administration server

9. This completes the first phase of the Administration server installation. In the next window, the installation wizard displays the message saying it has successfully completed the installation. Click Next to proceed with the installation process. Note: At this point you have to make sure WebSphere is running. If WebSphere is not running, the WebSphere configuration will fail and you will not be able to have the Administration server connected to the IBM WebSphere Application Server.

10.The installation wizard will now configure IBM WebSphere Application Server to recognize the newly installed ITLM Administration server. The configuration process may take a few minutes to complete. After completing the configuration, the installation wizard informs you it has successfully completed the configuration. Click Finish to exit the installation.

Chapter 4. Getting IBM Tivoli License Manager up and running

111

Note: If WebSphere is not running during this phase, the installation will immediately finish the WebSphere configuration stating it has successfully configured the application server. The configuration, of course has not occurred. 11.Now you should start Tivoli License Manager Administration server component. Open the WebSphere Administration Console and check if Tivoli License Manager Administration Server appears below the WebSphere Default Server, as shown in Figure 4-9. It will be in the list of Application Servers. To start the WebSphere Administration Console, issue the following commands:
# cd usr/WebSphere/AppServer/bin # ./adminclient.sh

In order to start the Administration server, press the Play button.

Figure 4-9 Administration Server in WebSphere Administration Console

112

Introducing IBM Tivoli License Manager

If you are not able to see the Administration Server in the WebSphere Administration Console, refer the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834, for troubleshooting.

4.2.6 Creating DB2 schema for Administration server on AIX


The next step is to create the database to be used by the Administration server. In our scenario, the DB2 server is installed on the same machine as the Administration server. In case you decide to use a separate DB2 server, this procedure should be performed on that machine. For creating DB2 database schema, you have to run dbsetup.sh script. This script will create a database named tlma and is located in the opt/IBM/TLM/admin/db/db2/ directory. Follow the procedure here to create and populate the database: 1. Log on to the DB2 server machine with a user with root authority. 2. Switch to DB2 instance owner, in our case db2inst1:
# su - db2inst1

3. Check that the DB2 command line is initialized. To do this, enter the command:
$ db2

You should see the DB2 Command Line Processor.


db2 =>

Type quit to exit and return to the $ shell. 4. 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

5. Change to following directory:


# cd /opt/IBM/TLM/admin/db/db2

And enter the command:


# . ./dbsetup.sh

6. Enter the password for the DB2 instance owner when requested.

Chapter 4. Getting IBM Tivoli License Manager up and running

113

Note: In case you enter the wrong password, you have to drop the database and run the dbsetup.sh script again:
# db2 drop database tlma # . ./dbsetup.sh

4.2.7 Connecting DB2 database to Administration server on AIX


On AIX, even though the tlma database was created on the same machine as the database server, it is still required to catalog the database. To catalog the tlma database, follow these steps: 1. Log on to the machine where the DB2 server is installed as a user with root authority. 2. Check the contents of the services file:
# more /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 one. 3. Note the <service> value. 4. Log on as the DB2 instance owner to the system where the DB2 Server and Administration server is installed. 5. Load the DB2 environment:
# cd /home/db2inst1/sqllib # . ./db2profile

6. Catalog the tlma database: Because we installed our Administration server and the tlma database on the same machine, we used the following commands:
# db2 uncatalog node <host> # db2 catalog tcpip node <host> remote 127.0.0.1 server <noted value> # db2 catalog database tlma as tlmadb at node tlmnode

If you have the database and server installed on different machines, you have to follow these commands instead:
# db2 catalog tcpip node <host> remote <remote host> server <noted value> # db2 catalog database <database name> as <cataloged name> at node <host>

Where, the values of variables are as follows: <host> The host name or IP address of the machine where the DB2 Server is installed.

114

Introducing IBM Tivoli License Manager

<noted value> The value you found in the services file. This is a port number if the DB2 Server is on a Windows machine, and a server name if the DB2 server is on an AIX machine.

4.2.8 Setting up SSL configuration


In this section we describe the steps to configure the SSL Configuration on the Administration Server to secure communication between the Administration Server and Runtime Servers. This is an optional step only required if the Administration Server and the Runtime Servers need to communicate using SSL. Follow the steps here to configure SSL: 1. Edit the HTTP Configuration file httpd.conf on the Administration server. On AIX the path is:
\usr\HTTPServer\conf\httpd.conf

It is a good idea to backup this file in the same directory before you make any changes to this file.
# cp httpd.conf httpd.conf.ori

2. Example 4-1 shows the entries to added at the end of the http.conf file.
Example 4-1 Changes in the httpd.conf file for UNIX environment
# Load the SSL module for ITLM data encryption between Admin Server and # Runtime Server LoadModule ibm_ssl_module libexec/mod_ibm_ssl_128.so AddModule mod_ibm_ssl.c Listen 443 <VirtualHost IPADDR:443> SSLEnable SSLClientAuth none ServerName HOSTNAME ErrorLog logs/ssl.error_log CustomLog logs/ssl.access_log common Keyfile "/opt/IBM/TLM/admin/keystore/key.kdb" SSLV2Timeout 40 SSLV3Timeout 120 LogLevel debug </VirtualHost> SSLDisable

In Example 4-1, replace IPADDR and HOSTNAME with the IP address and host name of your Administration server. In the Keyfile entry, make sure you use your Administration server installation directory. You must restart the HTTP Server for the changes to take effect.

Chapter 4. Getting IBM Tivoli License Manager up and running

115

Note: If you plan to install the Administration server on Windows, your http.conf file needs to changed with the following entries:
# Load the SSL module for ITLM data encryption between Admin Server and Runtime Server LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll Listen 443 <VirtualHost IPAADDR:443> SSLEnable SSLClientAuth none ServerName HOSTNAME ErrorLog logs/ssl.error_log CustomLog logs/ssl.access_log common Keyfile "c:/IBM/TLM/admin/keystore/key.kdb" SSLV2Timeout 40 SSLV3Timeout 120 LogLevel debug </VirtualHost> SSLDisable

3. Open the WebSphere Administration Console on the Administration server. 4. Select Virtual Hosts. Make sure there is a host alias entry for the port 443, as shown in Figure 4-10.

116

Introducing IBM Tivoli License Manager

Figure 4-10 Add host alias for port 443

4.2.9 Setting up event notification for Administration server


In this section we describe the steps to configure event notification for the Administration Server on AIX. To configure event notification on Administration server, you should define some parameters to be used to send notifications in the system.properties file of the Administration server. These parameters include: 1. The name of the mail server 2. The mail engine to be used 3. The e-mail address to which notifications are to be sent You can also set one mail recipient to receive notifications in addition to the administrators you have defined. This additional recipient does not need to be an administrator. To define notification settings for the Administration server, complete these steps: 1. Log on to the Administration Server with an user with root authority.

Chapter 4. Getting IBM Tivoli License Manager up and running

117

2. Open the system.properties file in a text editor.


vi /opt/IBM/TLM/admin/conf/system.properties

3. Change the #Mail Settings section with appropriate values: smtpServer Enter the host name or IP address of a valid SMTP server. This server will be used to forward the e-mail communications generated by the servers notification component. You can enter the e-mail address to which notifications are to be sent. This setting is optional. Enter the e-mail address that is to be used by the server as the sender address when notifications are generated.

mailRecipient mailSender For example:

#Mail Settings smtpServer=itlm_mail.itlm.com mailEngine=Internal mailRecipient=ani@itlm.com mailSender=itlm_a_aix@itlm.com

Note: If the Administration server is installed on the same machine as a Runtime server, there are two system.properties files, one in each installation directory. You must define settings in both files to enable both types of notification. The e-mail is not generated if the settings for the SMTP server and the mail sender are not present or not valid.

4.3 Setting up the ITLM Runtime server on AIX


In this section we describe the steps to install the IBM Tivoli License Manager Runtime Server on AIX. Most of the steps are similar as described in previous sections for the installation of the Administration server. This machine will serve as the host for the Agents connected to it. The following components are needed: IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7). For the installation procedure, refer to 4.2.1, IBM DB2 Server installation on page 102 and 4.2.2, IBM DB2 Fixpack 7 installation on page 105. IBM WebSphere Application Server Advanced Edition Version 4.0 (plus Fixpack 4). For installation procedures, refer to 4.2.3, IBM WebSphere installation on page 105 and 4.2.4, IBM WebSphere Fixpack 4 installation on page 107.

118

Introducing IBM Tivoli License Manager

IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Server Advanced Edition Version 4.0). IBM Tivoli License Manager Runtime Server Version 1.1.

4.3.1 ITLM Runtime server installation


In this section we describe the steps to install IBM Tivoli License Manager Runtime server on AIX. Before starting the installation of IBM Tivoli License Manager on AIX, we recommend that you check the following: 1. Make sure IBM DB2 is running. To initialize DB2 command line, type:
# ./home/db2inst1/sqllib/db2profile

2. Make sure IBM HTTP Server is running. To start the HTTP Server, type:
# cd /usr/HTTPServer/bin # ./apachectl start

3. Make sure IBM WebSphere Application Server is running. To start it, type:
# cd /usr/WebSphere/AppServer/bin # ./startupServer.sh

4. To monitor the Runtime server installation, you may run the IBM WebSphere Application Server Administration console, as shown in Figure 4-6 on page 109. In case of a successful installation, the ITLM Runtime server will show up in the list of Application Servers, right after the Default Server entry.
# cd usr/WebSphere/AppServer/bin # ./adminclient.sh

To install IBM Tivoli License Manager Runtime server on AIX, go through these: 1. From the directory where the IBM Tivoli License Manager CDROM is mounted, enter the following command to initialize the installation wizard. For AIX, run the setupaix.bin script. It is located in setup directory of your CDROM.
# cd TLM11/setup # ./setupaix.bin

2. When the installation wizard displays the welcome to the IBM Tivoli License Manager Version 1.1 - server installation window, click Next to continue. 3. The installation wizard displays the next panel that shows you the License Agreement Panel. Click the option I accept, and then Next to continue. 4. The dialog window for the IBM Tivoli License Manager installation directory appears. We used the default value /opt/IBM/TLM. Click Next.

Chapter 4. Getting IBM Tivoli License Manager up and running

119

5. The next window enables you to select the installation type. There are three options: Administration, Runtime, and Custom. Select Runtime, because you are installing the Runtime server. This is shown in Figure 4-11. Click Next to continue. .

Figure 4-11 Type of installation: Runtime server

6. The next panel prompts you for the home directory of DB2 instance. We used the default: /home/db2inst1. Click Next. 7. The installation wizard then asks for the password for the user tlmsrv. This user will be used to connect and access the Administration database. This user will be created during the installation. Click Next. 8. The following window, shown in Figure 4-12, appears specifically for the Runtime Server installation. These settings are used to authenticate communication between the Runtime server and Administration server. In this window, the installation wizard displays the following options. Click Next to continue. Customer name Mention the name of customer for whom you are installing this Runtime Server. In case this customer has already been defined in the

120

Introducing IBM Tivoli License Manager

Administration server, the name must match exactly. Runtime Server name Runtime server password Enter the host name for this Runtime server. Specify the password. This password will be used to authenticate this Runtime server when communicating with the Administration server.

Figure 4-12 Runtime server installation details

Note: These settings 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 into the Administration server. The values you enter for Customer name and Runtime server name must contain only US ASCII characters.

Chapter 4. Getting IBM Tivoli License Manager up and running

121

9. In the next window, shown in Figure 4-13, you need to specify information to enable the Runtime server to communicate with the Administration server. Enter the following: a. Identify the host machine of the Administration server by entering the host name or the IP address in the Administration server address field. b. The port number for communication. The default for un-encrypted communications is 80. For secure (SSL) communications enter 443. c. Choose the appropriate radio button to specify whether communications with the Administration server, initiated by this Runtime server, should be encrypted. d. If encrypted, enter the SSL Password and confirm it. After the installation, you must follow the instructions given in 4.2.8, Setting up SSL configuration on page 115 to enable the Administration server for SSL and complete the configuration of the Runtime server as an SSL client.

Figure 4-13 Runtime server communication options

10.The confirmation dialog window of the various ITLM features to be installed appears as shown in Figure 4-14. Click Next to start the installation.

122

Introducing IBM Tivoli License Manager

Figure 4-14 Confirmation of installation options Runtime server

11.This completes the first phase of the Runtime server installation. In the next panel, the installation wizard displays the message saying it has successfully completed the installation. Click Next to proceed with the installation process. Note: At this point you have to make sure WebSphere is running. If WebSphere is not running, the WebSphere configuration will fail and you will not be able to have the Runtime server connected to the IBM WebSphere Application Server.

12.The installation wizard will now configure IBM WebSphere Application Server to recognize the newly installed ITLM Runtime server. The configuration process may take a few minutes to complete. After completing the configuration, the installation wizard informs you it has successfully completed the configuration. Click Finish to exit the installation. Note: If WebSphere is not running during this phase, the installation will immediately finish the WebSphere configuration stating it has successfully configured the application server. The configuration, of course, has not occurred.

Chapter 4. Getting IBM Tivoli License Manager up and running

123

13.Now you should start Tivoli License Manager Runtime server component. Open the WebSphere Administration Console and check if Tivoli License Manager Runtime Server appears below the WebSphere Default Server, as shown in Figure 4-15. It will be in the list of Application Servers. To start the WebSphere Administration Console, issue the following commands:
# cd usr/WebSphere/AppServer/bin # ./adminclient.sh

To start the Runtime server, press the Play button.

Figure 4-15 Tivoli Runtime server in WebSphere administration console

If you are not able to see the Runtime server in the WebSphere Administration Console, refer to the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834, for troubleshooting.

4.3.2 Creating DB2 schema for Runtime server on AIX


The next step is to create the database to be used by the Runtime server. In our scenario, the DB2 server is installed on the same machine as the Runtime

124

Introducing IBM Tivoli License Manager

server. In case you decide to use a separate DB2 server, this procedure should be performed on that machine. For creating the DB2 database schema, you have to run the dbsetup.sh script. This script will create a database named tlmr and is located in the opt/IBM/TLM/runtime/db/db2/ directory. Follow this procedure to create and populate the database: 1. Log on to the DB2 server machine with a user with root authority. 2. Switch to DB2 instance owner, in our case db2inst1:
# su - db2inst1

3. Check that the DB2 command line is initialized. To do this, enter the command:
$ db2

You should see the DB2 Command Line Processor.


db2 =>

Type quit to exit and return to the $ shell. 4. 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

5. Change to the following directory:


# cd /opt/IBM/TLM/runtime/db/db2

And enter the command:


# . ./dbsetup.sh

6. Enter the password for the DB2 instance owner when requested. Note: In case you enter the wrong password, you have to drop the database and run the dbsetup.sh script again:
# db2 drop database tlmr # . ./dbsetup.sh

4.3.3 Connecting DB2 database to Runtime server on AIX


On AIX, even though the tlmr database was created on the same machine as the database server, it is still required to catalog the database.

Chapter 4. Getting IBM Tivoli License Manager up and running

125

To catalog the tlmr database, follow these steps: 1. Log on to the machine where the DB2 server is installed as a user with root authority. 2. Check the contents of the services file:
# more /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 one. 3. Note the <service> value. 4. Log on as the DB2 instance owner to the system where the DB2 Server and Runtime server is installed. 5. Load the DB2 environment:
# cd /home/db2inst1/sqllib # . ./db2profile

6. Catalog the tlmr database: Because we installed our Runtime server and the tlmr database on the same machine, we used the following commands:
# db2 uncatalog node <host> # db2 catalog tcpip node <host> remote 127.0.0.1 server <noted value> # db2 catalog database tlmr as tlmrdb at node tlmnode

If you have the database and server installed on different machines, you have to use these commands instead:
# db2 catalog tcpip node <host> remote <remote host> server <noted value> # db2 catalog database <database name> as <cataloged name> at node <host>

Where, the values of variables are as follows: <host> The host name or IP address of the machine where the DB2 Server is installed.

<noted value> The value you found in the services file. This is a port number if the DB2 Server is on a Windows machine, and a server name if the DB2 server is on an AIX machine.

4.3.4 Setting up event notification for Runtime server


In this section we describe the steps to configure event notification for the Runtime Server on AIX.

126

Introducing IBM Tivoli License Manager

To configure event notification on Runtime server, you should define some parameters to be used to send notifications in the system.properties file of the Runtime server. These parameters include: 1. The name of the mail server 2. The mail engine to be used 3. The e-mail address to which notifications are to be sent You can also set one mail recipient to receive notifications in addition to the administrators you have defined. This additional recipient does not need to be an administrator. To define notification settings for the Runtime server, complete these steps: 1. Log on to the Runtime server with a user with root authority. 2. Open the system.properties file in a text editor.
vi /opt/IBM/TLM/runtime/conf/system.properties

3. Change the #Mail Settings section with appropriate values: smtpServer Enter the host name or IP address of a valid SMTP server. This server will be used to forward the e-mail communications generated by the servers notification component.

mailRecipient You can enter the e-mail address to which notifications are to be sent. This setting is optional. mailSender For example:
#Mail Settings smtpServer=itlm_mail.itlm.com mailEngine=Internal mailRecipient=ani@itlm.com mailSender=itlm_a_aix@itlm.com

Enter the e-mail address that is to be used by the server as the sender address when notifications are generated.

Note: If the Administration server is installed on the same machine as a Runtime server, there are two system.properties file, one in each installation directory. You must define settings in both files to enable both types of notification. The e-mail is not generated if the settings for the SMTP server and the mail sender are not present or not valid.

Chapter 4. Getting IBM Tivoli License Manager up and running

127

4.3.5 Registering Runtime server to the Administration server


After installing a Runtime server in your environment, it must be registered to the correspondent Administration server, so that new Agents can be monitored by this Runtime server. We often refer to a connected Runtime server as plugged. Note: You cannot register a Runtime server to the Administration server unless you have at least one customer created in the Administration server. Refer to Chapter 5, Administering IBM Tivoli License Manager on page 143 for guidance on creating a customer. To register a Runtime server with the Administration server, complete these steps: 1. Open your Web browser and open the Administration server Web interface using the following in URL:
http://<host_name_of_administration_server>/slmadmin/login

2. Key in the appropriate user name and password. The default user name is tlmroot and default password is system. 3. As shown in Figure 4-16, select the customer for which you want to register the Runtime server.

Figure 4-16 Select customer to register a Runtime server

128

Introducing IBM Tivoli License Manager

4. In the portfolio, click Topology. When the Topology item expands to show a list of sub-items, click Servers. 5. Because this is the first Runtime server in the organization, you will see the following window as shown in Figure 4-17. Click Create.

Figure 4-17 Register first Runtime server

6. Complete the form with the requested details as shown in Figure 4-18. Click Finish. Name Password The host name of the Runtime server you wish to register with the Administration server. The password of the Runtime server you entered during the installation process. This password is used for the communication between Runtime and Administration server. The IP address of the Runtime server Port is 80 by default. This port is used for the communication between the Runtime server and the agents that will be connected to it.

Address port

Chapter 4. Getting IBM Tivoli License Manager up and running

129

Figure 4-18 Runtime server form

When you submit the server information, the Runtime server will be plugged in to the Administration server and is ready for use. This is shown in Figure 4-19.

130

Introducing IBM Tivoli License Manager

Figure 4-19 Server is registered (plugged in)

These are common causes of failure when plugging in Runtime servers: The Runtime server name entered does not match the name of any installed server. The Runtime server name entered identifies a server that does not belong to the customer you are working with. The password you entered does not match the Runtime password that was specified when the server was installed. If any of these problems occur, an entry is made in the event.log file, which is located on the Administration server machine, in the folder: <TLM_INSTALL_DIR>\admin\log

4.4 Setting up the ITLM Runtime server on Windows


In this section we describe the steps to install the IBM Tivoli License Manager Runtime Server on MS Windows 2000 Advanced Server.

Chapter 4. Getting IBM Tivoli License Manager up and running

131

This machine will serve as the host for the Agents connected to it. The following components are needed: IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7) IBM WebSphere Application Advanced Server Edition Version 4.0 (plus Fixpack 4) IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Advanced Server Edition Version 4.0) IBM Tivoli License Manager Runtime Server Version 1.1

4.4.1 IBM DB2 Server installation


This section describes the IBM DB2 Universal Database Enterprise Edition Server Version 7.2 installation process on Windows. Note: Use the DB2 installation media provided with the IBM Tivoli License Manager product. This ensures that you install the correct version and Fixpack of DB2. 1. Load the DB2 installation media provided with IBM Tivoli License Manager. 2. Select Start -> Run. Type in D:\setup.exe and click OK to start the installation. From the Installation window, select Install. 3. The Select Products window opens. From this window you can select the component(s) of DB2 for Windows that you want to install. Select DB2 Enterprise Edition as shown in Figure 4-20. Click Next.

132

Introducing IBM Tivoli License Manager

Figure 4-20 Select DB2 Enterprise Edition

4. The Select Installation Type window opens. Select the installation type you prefer. We selected Typical. 5. For the installation directory we used C:\db2. 6. For the DB2 administrative user, we selected db2admin. 7. After the installation wizard copies the DB2 files onto the machine, the Install OLAP Starter Kit window opens. Select Do not install the OLAP Starter Kit and then Finish. 8. Update Java. The installed JDBC code level needs to be upgraded to Version 2.0. You should open a DOS-command prompt window and issue the following commands:
cd DB2_DIR\java12 usejdbc2

Where, DB2_DIR is the DB2 installation directory. The usejdbc2 command will copy the appropriate version of db2java.zip into the DB2_DIR\java12 directory. 9. Reboot the machine.

4.4.2 IBM DB2 Fixpack 7 installation


This section describes installation of IBM DB2 Fixpack 7 on Windows.

Chapter 4. Getting IBM Tivoli License Manager up and running

133

If you are installing the Fixpack by using the Administrator account of Windows 2000 Advanced Server, please make sure you complete the following steps. Click on Start -> Programs -> Administrative Tools -> Local Security Settings -> User Rights Assignment. In the window you will see lists of user rights. Make sure the Administrator account has the following rights: Act as part of Operating System Create a token object Increase quotas Replace a process level token Note: Once you have installed a Fixpack, you wont be able to un-install it. 1. Stop all database activity before applying this Fixpack. To stop all database activity, enter this in a DB2 command window:
c:\db2\sqllib\bin:\>db2stop c:\db2\sqllib\bin:\>db2admin stop

2. Unzip and extract the Fixpack files to a temporary directory. 3. Run the following command to install the Fixpack from the Fixpack directory.
c:\fp7_wr21311\setup.exe

4. Key in the DB2 instance owner password if the setup prompts for it and click Next. 5. The wizard shows the selection window, click Next to continue. 6. As soon as the installation ends, reboot the machine.

4.4.3 IBM WebSphere installation


For our environment, we decided to use the IBM WebSphere Application Server Advanced Edition Version 4.0 (plus Fixpack 4). In this section we describe the IBM WebSphere Application Server Advanced Edition Version 4.0 installation steps on Windows. To install IBM WebSphere Application Server Advanced Edition Version 4.0, perform these steps: 1. When logged in as Administrator, issue the following command from the directory, where the IBM WebSphere Application Server CD-ROM is mounted:
setup.exe

134

Introducing IBM Tivoli License Manager

2. You are then prompted to select the type of installation. We have selected Typical Installation, because it will automatically install all the required components, such as the WebSphere Application Assembly Tool (AAT). If you decide to use a different installation method, make sure you select the AAT option. 3. In the following window you should specify the installation directories. We used the default values C:\WebSphere\AppServer and C:\IBM HTTPServer. 4. In the next panel, the installation wizard asks for the database information. WebSphere uses this database repository to store configuration information. In our scenario we used the local DB2 Server installed on the Runtime server machine.
Database type: DB2

You should also provide the database name to be created:


Database name (SID): was40

The DB2 instance owner user ID, password, and home directory:
Database user id: db2admin Database password: Database Path: c:\db2\sqllib

5. A final installation window informs you that the setup program has finished. 6. When the installation of WebSphere completes successfully, the screen, shown in Figure 4-5 appears. Select Start the Application Server. 7. Open a Web Browser and type in the following URL:
http://WebSphere_Server:9090/admin

Where, WebSphere_Server can either be the Runtime server host name or IP address. 8. This step is for IBM WebSphere Application Server Version 3.5.6 only. On the Administrator Console window, expand Resources -> JDBC Drivers -> Db2JdbcDriver. Click Db2JdbcDriver. Update the Server Class Path with the fully qualified path of the DB2 file db2java.zip. 9. You should recycle the IBM WebSphere Application Server by issuing the following commands:
Start Menu -> Programs -> IBM WebSphere -> Application Server V4.0 AE ->Stop Admin Server

Then issue:
Start Menu -> Programs -> IBM WebSphere -> Application Server V4.0 AE ->Start Admin Server

Chapter 4. Getting IBM Tivoli License Manager up and running

135

Note: IBM HTTP Server and IBM WebSphere may not start automatically after restarting the machine. In this case you will have to start it manually. For Windows you may open the Services panel and change the startup option for IBM HTTP Server and IBM WebSphere from Manual to Automatic. On Windows, if you plan to use IBM HTTP Server, you may have to either stop MS IIS Server or change its HTTP port.

4.4.4 IBM WebSphere Fixpack 4 installation


Because IBM Tivoli License Manager Version 1.1 requires IBM WebSphere Application Server Advanced Server 4.0.4, here we provide the steps for installing the WebSphere Fixpack 4. 1. Make sure you stop the IBM HTTP Server and IBM WebSphere Application Server before installing the Fixpack. 2. Unzip the Fixpack was40_ae_ptf_4.zip to a temporary directory. 3. Run the following command to install Fixpack from the Fixpack directory.
c:\was40_ae_ptf_4\install.bat

4. During the installation of this Fixpack, the setup prompts many questions. These questions allow you to select the modules that the Fixpack will update. In our case we answered No to iPlanet updates and Apache updates, because we use the IBM HTTP Server.

4.4.5 ITLM Runtime Server Installation


In this section we describe the steps to install the IBM Tivoli License Manager Runtime Server on Windows 2000 Advanced Server. Before starting the installation of IBM Tivoli License Manager on Windows 2000, We recommend that you check the following. 1. Make sure IBM DB2 is running. The following option opens the DB2 Command window. 2. Make sure IBM HTTP Server is running. 3. Make sure IBM WebSphere is running. To install the IBM Tivoli License Manager Runtime server on Windows 2000, go through the following steps.

136

Introducing IBM Tivoli License Manager

1. From the directory where the IBM Tivoli License Manager CDROM is mounted, enter the following command to initialize the installation wizard. It is located in setup directory of your CDROM.
setupwin32.exe

2. When the installation wizard displays the welcome to the IBM Tivoli License Manager Version 1.1 - server installation window, click Next to continue. 3. The installation wizard displays the next panel that shows you the License Agreement Panel. Click the option I accept and then Next to continue. 4. The dialog window for the IBM Tivoli License Manager installation directory appears. We used the default value C:\IBM\TLM. Click Next. 5. The next panel enables you to select the installation type. There are three options: Administration, Runtime, and Custom. Select Runtime, because you are installing the Runtime server. This is shown in Figure 4-11 on page 120. Click Next to continue. 6. The next panel prompts you for the home directory of DB2 instance. We used C:\DB2\SQLLIB. Click Next. 7. The installation wizard then asks for the password for the user tlmsrv. This user will be used to connect and access the Administration database. This user will be created during the installation. Click Next. 8. The following panel, shown in Figure 4-12 on page 121, appears specifically for Runtime server installation. These settings are used to authenticate communication between Runtime server and Administration server. In this panel, the installation wizard displays the following options. Click Next to continue. Customer name Mention the name of customer for whom you are installing this Runtime Server. In case this customer has already been defined in the Administration server, the name must match exactly. Enter the host name for this Runtime server. Specify the password. This password will be used to authenticate this Runtime server when communicating with the Administration server.

Runtime Server name Runtime server password

Chapter 4. Getting IBM Tivoli License Manager up and running

137

Note: These settings 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. The values you enter for Customer name and Runtime server name must contain only US ASCII characters. 9. In the next panel (as shown in Figure 4-13 on page 122), you need to specify information to enable the Runtime server to communicate with the Administration server. Enter the following: a. Identify the host machine of the Administration server by entering the host name or the IP address in the Administration server address field. b. The port number for communication. The default for un-encrypted communications is 80. For secure (SSL) communications enter 443. c. Choose the appropriate radio button to specify whether communications with the Administration server, initiated by this Runtime server, should be encrypted. d. If encrypted, enter the SSL Password and confirm it. After the installation, you must follow the instructions given in 4.2.8, Setting up SSL configuration on page 115 to enable the Administration server for SSL and complete the configuration of the Runtime server as an SSL client. 10.The confirmation dialog window appears, as shown in Figure 4-21. Click Next to start the installation.

138

Introducing IBM Tivoli License Manager

Figure 4-21 Confirmation of installation

11.This completes the first phase of the Runtime server installation. In the next panel, the installation wizard displays the message saying it has successfully completed the installation. Click Next to proceed with the installation process. Note: At this point you have to make sure WebSphere is running. If WebSphere is not running, the WebSphere configuration will fail and you will not be able to have the Runtime server connected to the IBM WebSphere Application Server.

12.The installation wizard will now configure the IBM WebSphere Application Server to recognize the newly installed ITLM Runtime server. The configuration process may take a few minutes to complete. After completing the configuration, the installation wizard informs you it has successfully completed the configuration. Click Finish to exit the installation. Note: If WebSphere is not running during this phase, the installation will immediately finish the WebSphere configuration stating it has successfully configured the application server. The configuration, of course, has not occurred.

Chapter 4. Getting IBM Tivoli License Manager up and running

139

13.Now you should start the Runtime server. Open the WebSphere Administration Console and check if the Runtime Server appears below the WebSphere Default Server (as shown in Figure 4-15 on page 124). It will be in the list of Application Servers. To start the WebSphere Administration Console, issue these commands:
Start Menu -> Programs -> IBM WebSphere -> Application Server V4.0 AE -> Administrators Console

To start the Runtime server, press the Play button.

Figure 4-22 Runtime server in WebSphere administration console

If you are not able to see the Tivoli License Manager Administration Server in WebSphere Administration Console, refer the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834, for troubleshooting.

140

Introducing IBM Tivoli License Manager

4.4.6 Creating database schema for Runtime server on Windows


For each IBM Tivoli License Manager Runtime server you install you must create an associated database. In our scenario, the DB2 Server is installed on the same machine as the Runtime server. On the IBM Tivoli License Manager Server the following script should be run in order to create the database schema: dbsetup.bat. It is located in the c:\IBM\TLM\runtime\db\db2 directory. Follow the procedure here to create and populate the Runtime server database: 1. Log on to the DB2 server machine as administrator or as a DB2 administrator (db2admin). 2. From the Start Menu, open the DB2 Command window. 3. Issue these commands:
cd \IBM\TLM\runtime\db\db2 dbsetup.bat

4. When requested, enter the password for the user you have logged on as. Note: In case you entered the wrong password, just drop the database and run the dbsetup.bat script again:
db2 drop database tlmr dbsetp.sh

Note: In case your DB2 Server and Runtime server are installed in different machines, you need to create an ODBC connection on the Runtime server to the tlmr database: 1. Run the DB2 Client Configuration Assistant. 2. Click Add and select Search the network. 3. Find the DB2 server machine and select the tlmr database from the list of local databases. 4. In the ODBC folder, clear the check box Register this Database for ODBC. 5. Click Finish.

4.4.7 Setting up event notification for ITLM Runtime server


In case you decide to have event notifications coming from this Runtime server, follow the steps described in 4.3.4, Setting up event notification for Runtime

Chapter 4. Getting IBM Tivoli License Manager up and running

141

server on page 126 and use the system.properties file located at the C:\IBM\TLM\runtime\conf\ directory.

4.4.8 Registering Runtime server to the Administration server


The last step is registering this Runtime Server to Tivoli License Manager Administration Server. To register the Runtime server, follow the steps described in 4.3.5, Registering Runtime server to the Administration server on page 128.

142

Introducing IBM Tivoli License Manager

Chapter 5.

Administering IBM Tivoli License Manager


This chapter provides an overview of the administrative tasks to be performed to manage the IBM Tivoli License Manager environment. We look at the tasks involved based on a case study that was created in our lab environment. From this case study we describe the best practices involved in the administration of IBM Tivoli License Manager. The previous chapters provided a great deal of information on the IBM Tivoli License Manager concepts, planning the physical and logical design, and the subsequent implementation of this design. This chapter provides an example that demonstrates these concepts and processes and the administration of the IBM Tivoli License Manager environment. We discuss these topics: Case study of the physical design Analysis and planning Infrastructure build and design process Test scenarios and pilot Case study of the logical design Managing customers and administrators

Copyright IBM Corp. 2003. All rights reserved.

143

Managing IBM Tivoli License Manager components Managing software entitlement and license pool details Managing software product components

144

Introducing IBM Tivoli License Manager

5.1 Case study: Physical design


Figure 5-1 depicts our lab environment and what a typical IBM Tivoli License Manager environment looks like in a customer implementation. In our lab environment we came up with a fictitious customer called CSI Corp. (CanSwissInd Corporation) which represents the three countries from where the redbook team comes, and it does not represent any real company or organization.

ITLM Administration server

CSI Administrators accessing the Web interface

ITLM Runtime server

LAN

ITLM Runtime server

Finance

HR

IT

Legal

Divisions - ITLM Agents


Figure 5-1 Typical implementation scenario

As shown in Figure 5-1, a typical IBM Tivoli License Manager environment consists of: 1. One Administration Server 2. One or more Runtime Servers depending on the number of agents deployed 3. Agents deployed to the various nodes within the customer organization Once the infrastructure has been built, the key aspect in the administration of the IBM Tivoli License Manager environment is analyzing and understanding the customer environment. Through this due diligence, we can begin configuring the

Chapter 5. Administering IBM Tivoli License Manager

145

administration pieces of IBM Tivoli License Manager. Also from this initial leg work we can determine the following: How the Divisions will be configured in the IBM Tivoli License Manager environment Scheduling of the inventory scans by Division Establish appropriate license pools based on the customers contractual license agreements with software vendors

5.2 Analysis and planning


Analysis and planning is the initial step needed to deliver IBM Tivoli License Manager. The objectives here are to: Analyze the customer environment Collect baseline data Define license entitlement policies The first step in establishing the baseline requires the analysis of the customer environment. This exercise should include at a minimum the following components. The existence and quality of the following components will impact the ability to do subsequent work. Understand the current IT environment, determine the average number of applications per endpoint for example. This data is important when designing the IBM Tivoli License Manager infrastructure and determining the appropriate number of Runtime servers. Refer to 3.1, Physical design on page 52 for details. License Management Business process documentation Organization charts and business units Define the customers business structure and identify how the customer requires reporting by Business Unit. There is also the need to consider how the licenses are procured (at corporate level, business unit or otherwise). This step will help to determine how the Divisions are configured in IBM Tivoli License Manager and the scheduling of the inventory scans by business unit. Software inventory A listing of all the technologies in use and any known information regarding its selection, long term viability, maintenance, and impact on the project objectives.

146

Introducing IBM Tivoli License Manager

IT standards All the support documentation already in place that may direct the configuration of IBM Tivoli License Manager in the IT infrastructure already in place. Define the customers security and privacy requirements. This will determine who has access to reports and what level of detail should be included in the reports.

5.3 Infrastructure build and design process


For a detailed description of the Infrastructure build of IBM Tivoli License Manager, refer to Chapter 4, Getting IBM Tivoli License Manager up and running on page 99. Proper implementation of the design process involves: Understanding the customers policy for the use of software. It is important that the customer has a clear policy statement. The statement should express the companys goals to manage software and what benefits they expect as a result. It should include their policy for acquisition of software and the repercussions for use of illegal software. Take a baseline of what the customer believes their software inventory looks like. This is an excellent measure to show improvement once the real time reporting capabilities are in place. This data may be obtained from the customer procurement records, spreadsheets of data, or any previous scanning technology that may have been used. During this step determine if the customer maintains a list of approved (supported) software. If so, document the process for exceptions. Gather details about the customers contractual license agreements terms and conditions. Only the terms and conditions specified in these agreements can enable you or the customer to properly perform license compliance. This is a critical step to configure the license management service and establish appropriate license pools to be managed. The final step is to ensure that the process guarantees continuous process improvement. This step is needed to design how escapes will be handled (illegally acquired software, for example). This may also include policies for reusing licenses when employees leave the company and so on.

Chapter 5. Administering IBM Tivoli License Manager

147

5.4 Test scenarios and pilot


As an administrator for IBM Tivoli License Manager, an important part of the job is to test the product prior to production in the customer environment. This will allow you to validate that the solution is configured right, and also to prove that the right solution was designed to meet the customer requirements. Therefore in a small pilot situation or UAT (User Acceptance Test) environment the following scenarios should be tested: Registration of the agent on an endpoint Usage data reports Inventory scheduling and collection Entry of procured licenses Event notification Entry of unknown products using the catalog manager

5.5 Case study: Logical design


In our example of the CSI Corporation, with the physical design already in place the next step was to perform the logical design. The considerations for the logical design are as follows: Adding Customers to the Administration server Administrative roles and responsibilities Defining and creating Divisions Selecting products for entitlement and license pools Produce reports

Adding Customers to the Administration Server


According to the logical design of the IBM Tivoli License Manager that, at this point, should already be defined and presented, the IT Administrator will be defining the Customers in the ITLM Administrator server. For our example scenario, there is only one Customer: CSI. We present how to perform this definition in 5.6.1, Adding a Customer to the Administration server on page 150.

Administrative Roles and Responsibilities


What has been decided for the CSI Corp. was to create various roles to manage the IBM Tivoli License Manager environment. The roles and responsibilities of each are described below. Refer to 5.6.2, Creating and adding administrators accounts on page 152 for more about how to perform this task.

148

Introducing IBM Tivoli License Manager

Hub Support/System Architect This persons main role is to configure, install, and test the IBM Tivoli License Manager infrastructure. They develop and maintain the IBM Tivoli License Manager infrastructure including manually deploying, installing, and configuring the ITLM Administration and Runtime servers. Customer Administrator/License Administrator This is the primary individual responsible for the delivery of all the license management services to the account according to contractually defined service level agreements. Responsibilities also include: They identify customer requirements for software license allocations Manually load the information pertaining to procured licenses Audit software licenses Monitor software usage Reconciling and reporting exceptions Allocating and recording software licenses Report Administrator This role can be given to a number of individuals and they are responsible for running the reports that are available within the IBM Tivoli License Manager application. Some run the realtime reports from the Runtime servers, others also run the historical reports available from the Administration server, as well as extract/create new reports using the Tivoli Data Warehouse Reports Interface.

Defining and creating Divisions


Also based on the Logical design developed for the Customer, one should define all Divisions within the IBM Tivoli License Manager environment. For the CSI Corp. example, we decided to define the Divisions based on the various departments within a corporation. Therefore we created the following Divisions: Legal - Legal department Finance - Finance department HR - Human Resources department IT - Information Technology department Refer to 5.7.2, Creating Divisions on page 159.

Selecting products for entitlement and license pools


When it comes to this step in the scope of the project, a key point to remember is that it will vary from customer to customer. This is a very subjective area and a

Chapter 5. Administering IBM Tivoli License Manager

149

unique area for each and every customer. The definition and scope of this part of the logical design will be driven out from the analysis and planning part of the project. For the CSI Corp example we decided to concentrate on a few well known software applications. The applications and their licenses are listed below: IBM Lotus Notes 5.0 - 5000 licenses Microsoft Internet Explorer 6.0 - 1000 licenses Oracle 8 Enterprise Edition 8.0.4 - 50 licenses Adobe Framemaker 6.0 - 3 licenses In our lab we created entitlement settings and license pools based on this licensing information. Refer to 5.8, Managing software entitlement and license pool on page 166.

Produce reports
In our CSI Corp. example the report administrator produced the reports for the fictitious customer. The Customer administrator created the report administrators and they subsequently logged on to the Administration server or Runtime server to generate the reports depending on whether they needed to provide the customer with historical usage reports or real time usage reports.

5.6 Managing Customers and administrators


In this section we explain how to manage customers and administrators in the IBM Tivoli License Manager environment. All the administration tasks are performed using a Web interface that is available either on the Administration or Runtime server. Therefore the various administrators are able to manage the IBM Tivoli License Manager environment, all through a Web interface. This makes it very convenient to manage the customer environment efficiently. They can sit at any workstation with Web access and perform their administration tasks in the IBM Tivoli License Manager environment after a login process.

5.6.1 Adding a Customer to the Administration server


One of the first steps of the Hub Support/System Architect is to define a Customer on the ITLM Administration server. After the infrastructure has been built the Hub Administrator will logon to the Administration server through a Web interface and create a Customer as follows:

150

Introducing IBM Tivoli License Manager

Note: IBM Tivoli License Manager is a Web-based solution and therefore, through a Web browser, all administration tasks can be performed by accessing the IBM Tivoli License Manager Web interfaces. 1. Using a browser, access the Administration server logon page:
http://<server name>:<port>/slmadmin/logon

Upon initial login to IBM Tivoli License Manager we must use the following: User Name: tlmroot Password: system The user name and password are the defaults provided by the IBM Tivoli License Manager product and allows us to login and create Customer accounts and administrator accounts for these Customers. 2. In the portfolio (My Work area), click Administration, then when the Administration item expands to show a list of sub-items, as shown in Figure 5-2, click Customers, and then click Create.

Figure 5-2 Creating a customer

Chapter 5. Administering IBM Tivoli License Manager

151

3. As shown in Figure 5-3, enter the details of a customer whose licenses you are managing. As you can see we used a fictional company called CSI (CanSwissInd Corp.). When selecting Finish, the Customer details are recorded in the Administration server database. You will receive a validation window that the Customer has been created.

Figure 5-3 Providing customer details

For more detailed instructions, refer to the IBM Tivoli License Manager License Administrators Guide, GC23-4833.

5.6.2 Creating and adding administrators accounts


Now that the Customer has been created in the Administration server database, the next step for the Hub Administrator is to create the various administrator accounts that are associated with that Customer to support them through the IBM Tivoli License Manager Web interface. The first account created will be the customer/license administrator account, for which the login will be csiadmin. This account will give access to the user to manage all aspects of administration for that particular Customer. The steps involved in creating this account are as follows:

152

Introducing IBM Tivoli License Manager

1. In the portfolio, click Administration. The Administration item expands to show a list of sub-items. Click Accounts and then click Create. A window similar to Figure 5-4 appears.

Figure 5-4 Creating a customer/license administrator account

2. Enter the details of the user who is to be allowed access to the Web interface. If the administrator is to receive notifications, you must specify the e-mail address to which the notifications are to be sent. 3. Click Finish, and the account details will be recorded in the Administration server database, and you will receive a validation screen that the account has been created.

5.6.3 Updating or deleting administration account details


Once you have created the administration account as outlined above, the account has no Customers assigned and no profile to assign an access level. Therefore you must assign to the administrator account, a Customer and also a role, whether that be Customer/license administrator or report administrator. The profile is the users level of access to Web interface functions. In order to do this the following steps must be completed:

Chapter 5. Administering IBM Tivoli License Manager

153

1. In the portfolio, click Administration. The Administration item expands to show a list of sub-items. Under Accounts there will be the list of existing accounts. In our example we selected csiadmin and Change.

Figure 5-5 Updating an administration account

2. Since csiadmin is a new account we must select a Customer that this administrator will manage. We must also select a profile for this account, as shown in Figure 5-5. The role defines the users level of access to the Administration server functions, as follows: Administrator Licensing Manager Other The user can perform all tasks on the Administration server Web interface. The user can perform the licensing tasks that are accessed using the Software Entitlement menu option. The user can request any report.

3. Click Finish, and a validation screen will appear confirming the account has been updated.

154

Introducing IBM Tivoli License Manager

5.6.4 Creating administrator accounts on the Runtime server


On each Runtime server, we must define administrators who are to use the Runtime server Web interface and receive notifications generated by that server. The steps involved to create the accounts are as follows: 1. Using a browser, access the Runtime server logon page.
http://<server name>:<port>/slmruntime/login

2. In the portfolio, click Administration. A list of accounts is shown. Select Create. Enter the details of the user who is to be allowed to access the Web interface on the Runtime server and who will receive event notifications from the Runtime server. In our example, to ease administration, we decided on creating all ITLM administrator using the same login name: csiadmin.

Figure 5-6 Runtime server administrator account details

Note: You will notice that the portfolio options are much fewer on the Runtime server than on the Administration server. From the Runtime server the only options available are the administration option to create administrators and the Software Usage option to run realtime software usage reports on all agents registered with that Runtime server.

Chapter 5. Administering IBM Tivoli License Manager

155

3. Click Finish. You will receive a validation window that the account has successfully been created.

5.7 Managing IBM Tivoli License Manager components


In this section we look at the administration tasks that are involved in managing the IBM Tivoli License Manager components. These tasks involve: Registering the Runtime server(s) with the Administration servers Creating Divisions that divide Agents into logical groupings Deploying Agents to nodes Scheduling inventory scans Adding application users

5.7.1 Registering a Runtime server with the Administration server


Once we have gone through the physical design planning and the installation of the Runtime server component, you must register the new Runtime server on the Administration server before it can be used by Agents. The connection between the ITLM Administration server and the Runtime servers can be plain HTML or secured communications using SSL. To Register a Runtime server with the Administration server complete these steps: 1. In the portfolio on the Administration server, click Topology. When the Topology item expands to show a list of sub-items, click Servers. Since this is the first Runtime server for CSI corporation, a window similar to Figure 5-7 appears. Click Create.

156

Introducing IBM Tivoli License Manager

Figure 5-7 Registering a Runtime server on the Administration server

2. Complete the form with the requested details. For more information on completing this form, refer to Chapter 4, Getting IBM Tivoli License Manager up and running on page 99. Information can also be found in the IBM Tivoli License Manager License Administrators Guide, GC23-4833.

Chapter 5. Administering IBM Tivoli License Manager

157

Figure 5-8 Registering the Runtime server

3. Click Finish. You will receive a validation window that the server has been successfully created. Once you submit the server information, the Runtime server is plugged in to the Administration server and is then ready for use. Note: There is a configuration setting in the system.properties file for the time period for the Runtime server to try a plugin, therefore depending on this setting the Runtime server may not plug in right away. Figure 5-9 shows that the Runtime server (TLM02) from our lab environment defined for the CSI Corp. has been successfully plugged.

158

Introducing IBM Tivoli License Manager

Figure 5-9 Shows the status of the Runtime server

If any problems occur and the Runtime server fails to plugin to the Administration server, an entry is made in the event.log file, which is located on the Administration server machine, in the folder: <TLM_INSTALL_DIR>\admin\log. This log file can be used for problem determination by the Hub administrator.

5.7.2 Creating Divisions


Divisions are organizational units within a Customer implementation of IBM Tivoli License Manager. They are used to group agents. The creation of these Divisions will be driven out by the customer and how they want their license management environment grouped into organizational units. These could be departments or cost centers or any other grouping the customer desires. In our example of CSI Corp., we created Divisions based on departments: Legal, Finance, HR, and IT. As an example, here we show the creation of the Finance Division of CSI Corp:

Chapter 5. Administering IBM Tivoli License Manager

159

1. On the Administration server when you first login, select the Customer from the pull down menu then in the portfolio, click Topology. When the Topology item expands to show a list of sub-items, click Divisions and then Create.

Figure 5-10 Adding the Division details

2. Assign a name and description for that Division. Click Finish, and you will receive a validation window that the Division has been successfully created. The creation of Divisions is integral in the IBM Tivoli License Manager environment, it is a logical grouping for the agents. Having agents grouped makes it possible to define different frequencies of inventory scans for different groups, select groups of agents for reporting, and limit access to license pools to a specific group or groups of agents.

5.7.3 Deploying an Agent on a node


This is the key part in bringing a customer onto the IBM Tivoli License Manager environment. Deploying the agent onto nodes in the customer environment involves registering the agent with a Runtime server. As described in 3.4.8, Planning for IBM Tivoli License Manager Agent on page 92, there are a couple of ways to do this, depending on the agreement between the IT department or

160

Introducing IBM Tivoli License Manager

the outsourcer and the customer. The methods are either Web-based or silent mode. Both of these methods require working closely with the customer to gather pertinent information and are described as follows:

Deploying an Agent via Web-based method


One of the simplest ways to deploy an agent on the nodes in the customer environment is to allow the end users to register their own workstations with a Runtime server. Because the actual registration process is so straight forward we believe that this method could work quite well. The only concern is that this method requires end-user interaction. The actual registration process is as follows: 1. Logon as a user with administration rights to the node where the ITLM Agent is to be deployed, and access the following URL of the Runtime server, where <servername> is the Runtime server hostname or IP address:
http://<servername>/slmruntime/register

Figure 5-11 Deploying an Agent on a node

2. Complete the requested information, as follows:

Chapter 5. Administering IBM Tivoli License Manager

161

Division

Select the Division from the drop down list, this will usually be the department the end-user belongs to or any grouping that the customer has decided to use. Select the Runtime server that the Agent will use from the drop down list, this information will have to be provided to the end user.

Server

Computer Label This will be the unique identifier that will be used in the customer environment. It could be an asset tag or any other unique identifier that the customer already is using within their environment or asset management system. 3. Click Finish. Standard security warnings for downloading from a Web site appear. Accept the security warnings by clicking Yes and the registration process will complete with a successful message. As you can see the registration process is quite straight forward, where an end user would not have much difficulty performing this task. If this method is the one to be used to deploy the agents, then the process is as follows: Work with the customer to define Divisions prior to deployment Draft communications letter and send out to the end-users members of each Division within the customer organization Have a company resource designated to respond to problems during deployment The communications letter can contain a link to the Runtime registration URL and the name of the Runtime server that the individual can select from the pull down menu once at the registration page. A sample communications letter may look something like the one shown in Figure 5-12.

162

Introducing IBM Tivoli License Manager

Sample Communications Letter


Service Announcement Software License Management

Beginning contract start date __, 2002, CSI Corporation has contracted with the IT company to provide multiple IT services in an effort to reduce costs, improve IT effectiveness, etc. The IT company, in response for customer requirements is deploying an unique management mechanism to aid us in optimizing our Software Licenses.

This is to inform you that you have been selected for the rollout of this leading-edge technology used for Software License Management. The deployment will begin DATE . You will see no major changes to your IT environment, you simply need to register for the service as follows:

http://<servername>/slmruntime/register Please select the following options from the drop down menus: Division===========> Your department Server============> tlm02.csi.com Computer Label=====> Asset Tag affixed on your machine Fill the web form and click the register button
This transition to a Software License Management strategy is consistent with CSI Corps goals to standardize and improve effectiveness of our IT Hardware and Software environment in support of our business objectives.

Additional information about the Software License Management service may be directed to customer contact and phone or email address. For inquiries or problems experienced during the rollout, you may contact agreed-to help desk, or other IT company resource designated to respond to problems. Thank you for your cooperation.
Figure 5-12 Sample Agent deployment communication letter

Chapter 5. Administering IBM Tivoli License Manager

163

Deploying an Agent via the silent mode method


As described in 3.4.8, Planning for IBM Tivoli License Manager Agent on page 92, if the customer which IBM Tivoli License Manager is about to be deployed already has a Tivoli infrastructure, then another way to deploy the agent is through a software distribution package to the Agents that are already Tivoli Endpoints. For those Agents that are not part of the Tivoli infrastructure, using scripts may be a more appropriate way. The advantage here is no user intervention is required. The process involved to use this method of deployment is as follows: Work with the customer to define Divisions prior to deployment. Define which Divisions will be assigned to which Runtime servers. Define which method of Agent installation will be utilized. Gather the unique identifier which will be used as the computer label in the registration process. This will probably come from an existing asset management system within the customer environment. Gathering the Division information and unique identifier to be used is predominant when using this method to deploy the agent, because these are two key parameters that must be used when creating the script to run once the software distribution takes place. Appendix A, ITLM Agent installation using IBM Tivoli Configuration Manager on page 253 describes the methodology and provides the scripts and packages for installing the ITLM Agent. In our lab environment using the fictional CSI customer we tested both methods and both worked equally as well. It is a matter of understanding the customers needs and preferences.

5.7.4 Scheduling an inventory scan


The next step, once the Agents have been deployed, is to schedule inventory scans; one of the functions of the agent is to make regular inventory scans of the products installed on the node it is monitoring. Going back to our example of the CSI corporation, using the Web interface hosted on the Administration server, the ITLM administrator can schedule separate inventory scans for the Legal, Finance, HR and IT Divisions, specifying for each one of them a different scan date, time, and frequency. Inventory scans are scheduled by Division. Therefore some of the points to consider when deciding on the timing and frequency of inventory scans are: Make sure to create the schedule for scanning in advance of the time specified for scanning, so that the schedule details will reach all Agents within the Division.

164

Introducing IBM Tivoli License Manager

Schedule the scans of different Divisions at different times, to reduce network traffic. We advise you to schedule the scans at off hour times or if a wake on lan (meaning a machine that is not active, but awakes in the event of a request) solution is deployed in the customer environment, then schedule the scans at times when the network traffic is a minimum. To schedule inventory scans, complete these steps on the Administration server: 1. In the portfolio, click Software Inventory, and then when the configuration item expands to show a list of sub-items, click Scheduling. Select a Division from the drop down list and click Next.

Figure 5-13 Enter the details for the inventory scan

2. Complete the requested information based on what has been decided for that particular Division, and then select Finish. A message stating the inventory scan schedule has been successfully completed appears.

Chapter 5. Administering IBM Tivoli License Manager

165

5.7.5 Adding application users


This function within IBM Tivoli License Manager allows an administrator to record details of users who are entitled to run applications on monitored nodes. The purpose of registering users in the Administration server database is to allow license pools to be restricted to specified users. The users can be populated into the administration database from an external asset management system if the data is provided in an XML format. For instructions on adding application users, refer to the IBM Tivoli License Manager License Administrators Guide, GC23-4833.

5.8 Managing software entitlement and license pool


In this section we describe the steps involved in the administration of licenses and the metering of software within IBM Tivoli License Manager, which is based on the license pools defined by the customer on a product-by-product basis. The tasks involved to manage software entitlement and license pool details are: Gather procurement and licensing information from the customer on all products that they want to have tracked. Select a product for entitlement or license pool maintenance. Create new license pools for a product. As described in 2.5, Licence Management process on page 30, details of license entitlement and license pool information relates to a specific contract between the customer and the software provider. All the procurement details and license agreements the customer has made with the software vendors will drive out what will be the entitlement and license pool settings in IBM Tivoli License Manager. This has to be organized and analyzed on a case-by-case basis.

5.8.1 Gathering customer licensing and procurement information


The purpose of this step is to understand which products the customer wants tracked and for which products they have actually procured licenses. The procurement information will be entered manually into the IBM Tivoli License Manager Administration database through the creation of license pools for those particular products. The customer can define a license pool to enforce an existing license agreement or just let IBM Tivoli License Manager monitor the usage of software, using a default set of rules and without applying any limits. By default, licenses are available to all users on the monitored Agents. However, it is possible to limit the license pool availability to selected users if the customer desires. An example is

166

Introducing IBM Tivoli License Manager

the application AutoCad for this application only a select number of users may need access to this application, those users can belong to the same Division or they can belong to different Divisions throughout the company. Therefore one way to control the use of this application is to create a license pool that is available only to those particular users, instead of allowing the defaults which means that the license is available to the entire enterprise. As already stated, this is driven by the customer and their particular needs. Therefore it is extremely important to understand what the customers needs and expectations are and they will vary from one customer to the next, but IBM Tivoli License Manager is flexible to cater to each and every customers desires.

5.8.2 Selecting a product for entitlement or license pool maintenance


As described in 2.2.1, IBM Tivoli License Manager Master Catalog on page 19, IBM Tivoli License Manager provides a Master Catalog of more than 12,000 products. It would be a very daunting task to manage all of those products. This is where software entitlement and license pools come into play. When the initial analysis of the customer environment takes place, there should be an agreement on which products the customer wants metered and reported on. For illustration purposes, in our case study scenario with CSI Corp., we have come to an agreement that: CSI Corp. wants 10 products actually tracked and metered 6 products have corporate licenses 4 products have been procured by different departments that require them In this case, what we want to do is create software entitlement settings for all 10 of the products. This allows CSI to meter the usage and produce reports for these products. Now, for the four products that have been purchased by the individual departments, we create license pools which limits the use of these applications to those particular Divisions or users. To define software entitlements, you must complete these tasks on the Administration server: 1. In the portfolio, click Software Entitlement.

Chapter 5. Administering IBM Tivoli License Manager

167

Figure 5-14 Creating a software entitlement setting for a product

2. Complete the form shown in Figure 5-14 as follows, and then click Next: SW Vendor Select All to allow selection of products from all vendors or select one or more vendors and limit selection of products supplied by those vendors. Select All to allow selection of products installed on all platforms or select one or more platforms and limit selection to products installed on those platforms.

Platform

Product Name To limit the selection criteria by product name matching, enter part of a product name, preceded, followed, or surrounded by wildcard characters (%). All products that have names that match the characters you enter are available for selection on the next form. Leave the field blank if you do not want to use product name matching. Include Indicate whether your selection should include products that already have settings, or products that do not have settings, by selecting the appropriate radio button.

168

Introducing IBM Tivoli License Manager

3. Select the desired product from the scroll down list provided, and then click Next to show the license information about the product you selected.

Figure 5-15 Selecting details of the entitlement settings

4. Complete the Product Settings section, shown in Figure 5-15, by selecting radio buttons as follows: Software monitoring Select Enabled if you want to track the presence and use of this product using IBM Tivoli License Manager. Otherwise, select Disabled. Select User-defined if you want to define license pools for this product. Select Default to use default license pool settings. In this case there is no need to create any license pools as a set of default license rules applies, which states that the entire enterprise can use this product and it is not restricted to a particular Division or set of users. Any license pools that exist are ignored. Run offline Select Yes if the product can be used when there is no connection between the Agent and the Runtime server. Otherwise select No.

License control

Chapter 5. Administering IBM Tivoli License Manager

169

If you select Yes, the product can be used in off-line mode and no license checks will be made. License rules can be applied only when the Agent is connected to the Runtime server. Server Response Select Required if the agent must wait for a server response before allowing the application to start. Select Not required if the application can start before a response from the Runtime server has been received.

5. Click Finish to record these settings, a confirmation page appears

5.8.3 Creating a license pool


Each product with software entitlements that specify User Defined license settings must have at least one license pool associated. When you create a license pool, you define a set of rules that is to be applied when administering the licenses assigned to the pool. Once all software entitlements are defined, it is time to define license pools for the products that CSI Corp. has acquired. For illustration purposes, we used Oracle 8 Enterprise Edition with 50 licenses and made it available to the entire enterprise. To create a license pool, complete these steps: 1. Select the product for which you want to create a license pool, by first clicking on Software Entitlement, and then finding the software entitlement for product in question. Click Create.

170

Introducing IBM Tivoli License Manager

Figure 5-16 Provide details for the license pool

2. Complete the Manage License Settings form, shown in Figure 5-16, as follows: Capacity Type Select a capacity type from the drop-down list. The capacity type controls how the number of licenses required is determined when a product starts. There are a number of options, which are: Users Memory Processors Online Processors Configured Disks

Each of these options allows for how a license is assigned when a product starts, for instance, if we select Disks then the number of licenses assigned is equal to the number of hard disks on the requesting node; and, if we select Users, then a license is assigned for each node that starts the application. This allows for different types of license assignment. For instance, if we wanted to monitor the licenses on a mainframe, then we can use either the memory or processors online options. But for the majority of the customers many select the users option. In our case scenario with CSI Corp., we chose

Chapter 5. Administering IBM Tivoli License Manager

171

Users as the capacity type. Refer to the IBM Tivoli License Manager License Administrators Guide, GC23-4833, for a full description of the options. Hard Stop If you select Yes, the number of licenses available is an absolute maximum. It means that once all licenses are in use, the next license request is refused and the application cannot start. If you select No, the number of licenses available is not an absolute maximum. Once all licenses are in use, the next license request causes a warning event to be generated, but the application is allowed to start. Multi-instance This setting controls the situation where a single license can be used for multiple instances of the product. Select the default, Disabled, if multi-instance licenses are not allowed. Otherwise, select one of the other options from the drop-down list. For a full description of those options, refer to the IBM Tivoli License Manager License Administrators Guide, GC23-4833. Quantity Specify the volume of licenses available in this license pool. This will be the number of licenses that the customer has procured for this particular product. Threshold Specify the percentage of the total licenses in the pool at which to set a threshold for warnings. When the volume of licenses that are in use reaches this percentage, a warning event is generated. Target Type The target type indicates availability of the license pool within the customer monitoring environment. Select Enterprise to make the license pool available to all nodes in the customer environment, or select Division, Node, or Agent to limit availability to selected components. If you choose anything other than Enterprise, you must specify which Divisions, Nodes, or Agents can use this license pool. Start Date Specify the date from which the license pool is available. Expiration Date Specify the date when the license pool will stop being available, this will probably happen when the maintenance agreement of the purchased license ends. Usually a maintenance agreement will allow for free upgrades if a newer version is released for the period of that license agreement. This will all be brought to the forefront during the discussions with the customer. Description Enter a short description of the license pools that will help you to recognize the license pool when it appears in the software usage reports.

172

Introducing IBM Tivoli License Manager

Creation Mode This is whether you want to create the distribution parameters now or not, by defining the Divisions or users that are entitled to use the license pool and then it will be distributed from the Administration server to the Runtime servers and the metering of that particular license pool takes effect. Select Set distribution now if you want to go immediately to the form where distribution details are defined. Select Set distribution later if you want to defer setting the distribution details. 3. Click Finish to create the license pool. In our example we chose to Set distribution now, which then took us to the next window where we were required to fill in the distribution parameters, as shown in Figure 5-17.

Figure 5-17 Setting distribution parameters

4. Since in our example we decided that the Oracle 8 Enterprise Edition software will be available for all users of CSI Corp., we chose the Allow all option. Otherwise the distribution settings wizard would allow us to select the Divisions, Nodes, and Agents that would be affected by this license pool distribution. Once the distribution settings are done, a confirmation window appears stating that the license pool and the distribution parameters for that license pool were created.

Chapter 5. Administering IBM Tivoli License Manager

173

IBM Tivoli License Manager is a very dynamic application, and with that flexibility it is adaptable in all types of customer environments, whether they are rapidly changing environments or static environments, therefore IBM Tivoli License Manager has the solution for each of them. One of the primary examples of this flexibility is the updating of the software entitlement, license pool, and distribution parameter settings. As the customer environment rapidly evolves and licenses are procured or expire, IBM Tivoli License Manager allows you to quickly make changes to the software entitlement and license pools. Therefore as the customer needs are continuously changing IBM Tivoli License Manager allows you to stay on top of these changes with simple updates to the software entitlement, license pool, and distribution parameter settings.

5.9 Managing software product components


In this section we describe the use and management of software product information with IBM Tivoli License Manager. We specifically look at how to add new products to the Master Catalog using the IBM catalog manager component. We discuss the following: The Master Catalog The Runtime Catalog The unknown file table and unknown file lists Using the IBM catalog manager component to update the Master Catalog

Master Catalog
IBM Tivoli License Manager provides an initial Master Catalog when it is installed. The Master Catalog is a central repository of product information. It is created and maintained on the Administration server and a copy is dowloaded to each Runtime server. The Master Catalog contains information about all the software components and related files for the products that are to be monitored. The IBM Tivoli License Manager catalog manager component allows you to add new information to the Master Catalog. There are two sources of new information: The unknown file table, which contains entries for all applications that were detected by agents, but there are no entries already defined in the Master Catalog. The unknown file table is useful in a customer environment for many reasons. One is that a particular customer may have many in-house applications that they want tracked, so this provides a method to identify that software and then

174

Introducing IBM Tivoli License Manager

merge it into the Master Catalog, therefore providing a way to monitor and report on the usage of this in-house software. New releases/updates of the IBM Tivoli License Manager catalog, which you can merge with the Master Catalog, so that it contains all the entries from the most up to date IBM Tivoli Software Inventory catalog. Updating the ITLM Master Catalog with the latest catalog provided by IBM is essential for new software components and related files recognition, and proper reporting on their usage.

Runtime Catalog
A Runtime Catalog is automatically created on each Runtime Server. It is a subset of the Master Catalog that resides in the Administration server, which contains only information about those products that are installed and discovered by the ITLM Agents that are managed by the Runtime Server. New entries are added to the Runtime Catalog when the Runtime Server receives license entitlement details from the Administration server and when the unknown file table identifies an new application, which has been discovered on a monitored node, that is not in the catalog.

Unknown file table and unknown file lists


The unknown file table and unknown file lists provide a way of identifying software that is not included in the Runtime Catalog and which may not contain an entry in the Master Catalog. The Agent, running on a node, identifies any applications that are not included in the Runtime Catalog and adds them to the unknown file list. The lists compiled by all Agents are communicated to the Runtime server where they are merged to form the unknown file table. The information in the table is used to identify entries in the Master Catalog, which should be added to the Runtime Catalog. Unknown file tables from the Runtime servers are periodically uploaded to the Administration server, where they are merged to form a single unknown file table. You can add any of the unknown files to the Master Catalog using the IBM catalog manager.

Using the IBM catalog manager to update the Master Catalog


The IBM catalog manager is a standalone tool that you can use to expand and make changes to the Master Catalog. In order to use it, you must extract the Master Catalog and unknown file table from the Administration server database. You can then perform a number of tasks, the most frequent of which is adding the unknown files, discovered by the Agents, to the Master Catalog. When you have finished making changes, you must re-import the catalog to the Administration server database.

Chapter 5. Administering IBM Tivoli License Manager

175

Most common tasks that can be done using the IBM catalog manager are: Update the Master Catalog from entries of the Unknown file table. Import new releases of the IBM Tivoli License Manager catalog. Modify existing entries in the master catalog.

5.9.1 Updating the Master Catalog from the Unknown file table
This is an important aspect that shows how flexible IBM Tivoli License Manager is. Many enterprises want to monitor software and applications that have been custom-developed by either a software provider or in-house. By doing so, enterprises have the ability to monitor and meter these applications usage and produce reports efficiently. In our case study we provided an example of an application that was developed by CSI Corp., called CSI HR Tool. The CSI HR Tool has been deployed and used within the enterprise, and has now been discovered by the ITLM Agents. Therefore, there is an entry in the Unknown file table that corresponds to the CSI HR Tool. The steps involved to add CSI HR Tool to the Master Catalog are performed on the Administration server as follows: 1. Initialize the IBM Tivoli License Manager CLI environment. 2. Extract the Master Catalog and the Unknown file table from the ITLM Administration server database into merged catalog file. 3. Modify the existing entry in the Unknown file table for the CSI HR Tool application and make the appropriate changes, for example, identifying it as being developed by the CSI Corp. 4. Import the newly created catalog into the IBM Tivoli License Manager Administration server database. 5. Define software entitlements for the new application, if necessary.

Initializing the IBM Tivoli License Manager CLI environment


Before using the IBM catalog manager tool, some environment variables and settings have to be established, namely the ITLM CLI environment. To initialize the ITLM CLI environment use the tlmcli command, as follows:
Example 5-1 Setting up the ITLM CLI environment
# cd /opt/IBM/TLM/admin/cli # . ./tlmcli **************************************************************************** * IBM Tivoli License Manager Administration server v1.1 * Command line for AIX * (c) Copyright IBM Corporation 2001 - 2002

176

Introducing IBM Tivoli License Manager

* * For general help, type: help * For more detailed help, refer to the System Administrator's Guide. ***************************************************************************** #

Extracting the Master Catalog and Unknown file table


To extract the Master Catalog and Unknown file table from the IBM Tivoli License Manager Administration server use the expcat command as follows:
Example 5-2 The expcat command output
# cd /opt/IBM/TLM/admin/cli # expcat Connected to database Exporting software catalog ... Software catalog successfully saved into 'catalog.dat' file Software vendors:27 Software products:12089 Modules:20050 Unknown files:423 #

At this point, using the expcat command, we have created a new file named catalog.dat stored in /opt/IBM/TLM/admin/cli directory. This file contains all the entries of both the Master Catalog and the Unknown file table merged in a format understandable by the IBM catalog manager tool. Our next step is to find and modify the entry for the CSI HR Tool application.

Modifying the application entry


To find and create an entry in Master Catalog for the unknown application we have to use the IBM catalog manager application. Still in the ITLM CLI environment start the IBM catalog manager tool by using the catman command. The catman command is located in the <tlm_inst_dir>/catmgr directory, where <tlm_inst_dir> is the directory where the Administration server is installed. This will start a Java based application, as follows:
# cd <tlm_inst_dir>/catmgr # . ./catman

For a detailed description of performing the tasks using the catalog manager, refer to the IBM Tivoli License Manager License Administrators Guide, GC23-4833.

Chapter 5. Administering IBM Tivoli License Manager

177

Figure 5-18 IBM catalog manager

Now we can begin creating software products from the unknown file table as follows: 1. Click Unknown Files Manager. This will take you to the Unknown Files Manager working environment. Next, you can perform a search by either using a name of description, and selecting the corresponding operating system. If you do not use any argument for search, this will bring up a list of all unknown files, by operating system, that were picked up from all the nodes that have ITLM Agents running on them. An example is shown in Figure 5-19.

178

Introducing IBM Tivoli License Manager

Figure 5-19 Searching the unknown file table

2. Now scroll through the list, select the executable file you want to add to the Master Catalog, and click New. In our example we selected CSI.EXE. This will take us to the Create a new software product window, as shown in Figure 5-20, where we can fill in some pertinent information about that product, such as the name, version, and description of the product, as well as the vendor, and most importantly, the licensing level. Click Create.

Chapter 5. Administering IBM Tivoli License Manager

179

Figure 5-20 Details to create a new software product

3. The next panel, shown in Figure 5-21, allows you to edit the application information once again and, if necessary, make any changes to the information you just entered. Click Close to return to the IBM catalog manager window.

180

Introducing IBM Tivoli License Manager

Figure 5-21 Information on the new software product

Now you have successfully created an entry for the CSI HR tool in the merged catalog. The next step is to import this new catalog with the all the changes into the IBM Tivoli License Manager Administration database.

Importing the catalog into the Administration server database


To import the newly created catalog into the IBM Tivoli License Manager Administration server database, use the ITLM impcat command as follows:
Example 5-3 The impcat output
# cd /opt/IBM/TLM/admin/cli # . ./impcat Connected to database Admin server ID: 642757 Admin server timestamp: 2002-12-06-18.07.25.077657 Reading header Administration server check OK Importing vendors

Chapter 5. Administering IBM Tivoli License Manager

181

Importing products .............................................................................. .............................................................................. ........................................................... Updating timestamps

Software catalog imported successfully Vendors: 28(read) 1(new) 0(updated) Products: 12090(read) 1(new) 1(updated) Modules: 20051(read) 1(new) 0(updated) #

5.9.2 Importing new releases of the ITLM catalog


In this section we show how to update the Master Catalog with the new ITLM signature files provided by IBM. Updates to the ITLM catalog will be provided by IBM on a regular basis and can be obtained from the IBM Tivoli License Manager support page at:
http://www-3.ibm.com/software/sysmgmt/products/support/IBMTivoliLicenseManager. html

Launch the IBM Tivoli License Manager catalog manager as shown in Figure 5-18 on page 178 and click Import IBM Catalog. This will take you to a file search window.

Figure 5-22 Select the file to import and update the Master Catalog

Search for and select the new catalog file that you want to import to update the Master Catalog and click Open. Click OK to initiate the import process.

182

Introducing IBM Tivoli License Manager

Figure 5-23 Begin the process to update the Master Catalog

This process automatically updates the Administration server database and may take several minutes to complete. IBM will provide updates to the IBM Tivoli License Manager Master Catalog on a regular basis.

Chapter 5. Administering IBM Tivoli License Manager

183

184

Introducing IBM Tivoli License Manager

Chapter 6.

Reporting with IBM Tivoli License Manager


IBM Tivoli License Manager provides both real-time and historical reporting mechanisms where you can proactively control the software usage in your enterprise. In terms of reporting, we can also fully leverage the Tivoli Data Warehouse (TDW) product through the IBM Tivoli License Manager Warehouse Enablement Pack which populates the TDW databases with software usage data so that you can further drill-down into license management and software usage information. In this chapter we detail what the predefined IBM Tivoli License Manager reports are, how they leverage integration with the Tivoli Data Warehouse, and how to obtain the Tivoli Data Warehouse reports. The topics include: ITLM pre-defined reports Tivoli Data Warehouse Integration overview ITLM reports using Tivoli Data Warehouse

Copyright IBM Corp. 2003. All rights reserved.

185

6.1 ITLM pre-defined reports


To ease license management tasks, IBM Tivoli License Manager provides a set of pre-defined reports. These reports provide both real-time and historical information data. Depending on the users role, one can access software and license usage as well as software inventory information for a particular Customer, as defined by the IBM Tivoli License Manager administrator. Real time reports on the status of software usage are provided by the content of a particular IBM Tivoli License Manager Runtime server. Historical reports of software inventory and usage information are available on the IBM Tivoli License Manager Administration server. Now we provide details about the reports provided by both the IBM Tivoli License Manager Administration server and the various Runtime servers.

6.1.1 ITLM Administration server reports


The IBM Tivoli License Manager holds the central data repository of software, license agreement, license usage, inventory and Customer information. It also provides a Web interface that can be used to perform administrative tasks, such as to produce historical reports of license usage and inventory information on the monitored nodes. These reports are available on the IBM Tivoli License Manager Administration server: Snapshot of software usage Software usage trend analysis Software usage level analysis Software inventory

Snapshot of software usage report


This report provides detailed information about the software and their level of usage during a specified period of time, the ITLM Agents of these products are installed, their respective available license pools in terms of how many have been installed, and how many licenses of that particular software have been procured. To work on Snapshot of software usage, follow these steps: 1. Log on to the ITLM Administration Server Web interface. To access the login screen, type this URL in your Web browser.
http://<admin_server_hostname:80/slmadmin/login

186

Introducing IBM Tivoli License Manager

If you are using SSL, to access the login window, use this URL, instead:
https://<admin_server_hostname:443/slmadmin/login

Upon initial login to IBM Tivoli License Manager Web interface, you must use the following: User Name: tlmroot Password: system 2. The next window is a Welcome window. If you have more than one Customer defined, select the Customer for which you want to take the snapshot report. Click Software Usage -> Snapshot. 3. To produce a historical snapshot for the Customer, select the criteria shown as an example in Figure 6-1. Click Next.

Figure 6-1 Parameters for historic snapshot -1

Where, the values of variables are as follows: SW Vendor Platform The selection list includes publishers of software whose products can be included in the report. The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager.

Chapter 6. Reporting with IBM Tivoli License Manager

187

Product name Division

Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions. If you want to obtain reports for a particular Agent, or a group of Agents belonging to the same search criteria entered, wildcard characters (%) are allowed.

Agent name

4. In the next window, shown in Figure 6-2, Product name and Agent name drop-down boxes appear. Select the appropriate software for which the report is to be made. On the Agent name, you can select All, showing the usage for all Agents of that particular Division, or select one specific Agent. In the Define the reporting time section, enter the effective date and time for which you want to make the report. By default, the date and time are current. Click Next.

188

Introducing IBM Tivoli License Manager

Figure 6-2 Parameters for historic snapshot -2

5. Figure 6-3 displays the resulting report. The report includes the following sections: A list of the products that meet the selection criteria entered, showing the level of usage of each product at the specified time. Product details of each product included in the report. A list of Agents where each product was in use at the specified time. Details of license pools available for each product at the specified time. A list of sessions that were open at the specified time for each product.

Chapter 6. Reporting with IBM Tivoli License Manager

189

Figure 6-3 Historic snapshot report

You are able to view more report information by scrolling down in the report window. This additional information is shown in subsequent figures in this section. This information is also available by selecting the hyper links in the report page. Figure 6-4 displays the product information and a few parameters set for products Microsoft Internet Explorer and Microsoft PowerPoint, respectively, when creating license pools for these.

Figure 6-4 Historic snapshot - product / license details - 1

190

Introducing IBM Tivoli License Manager

Figure 6-5 displays the detailed license information for products Microsoft Internet Explorer and Microsoft Power Point, respectively.

Figure 6-5 Historic snapshot - product / license details - 2

Figure 6-6 displays the list of Agents for that Customer on which Microsoft Internet Explorer and Microsoft PowerPoint are installed, respectively. It also gives you detailed information about the Agents.

Chapter 6. Reporting with IBM Tivoli License Manager

191

Figure 6-6 Historic snapshot - product / license details - 3

Software usage trend analysis report


This report provides detailed information about the software usage trend analysis by giving graphical representation of the trend of software usage of a selected product, during a specified period of time. The report also gives you a detailed chart of trend usage values by date and time. To obtain the software usage trend analysis report, follow these steps: 1. Log on to the ITLM Administration Server Web interface. 2. Select the Customer for which you want to take the software usage trend analysis report. Click Software Usage -> Trend Analysis. 3. To produce a historical trend analysis for the selected Customer, select the criteria shown as an example in Figure 6-7. Click Next.

192

Introducing IBM Tivoli License Manager

Figure 6-7 Parameters for trend analysis

Where, the values of variables are as follows: SW Vendor Platform Product name Division The selection list includes publishers of software whose products can be included in the report. The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager. Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions. If you want to obtain reports for a particular Agent, or a group of Agents belonging to the same search criteria entered, wildcard characters (%) are allowed.

Agent name

4. In the next window, shown in Figure 6-8, Product name and Agent name drop-down boxes appear. Select the proper software for which the report is to be made. On the Agent name, you can select All, showing the trend for all Agents of a particular Division, or select one specific Agent. In the Define the

Chapter 6. Reporting with IBM Tivoli License Manager

193

report breakdown section, select the level at which software usage information is to be broken down into separate charts, as follows: Capacity A chart is produced for each different capacity type that is used for the product. For example, if the product has some license pools with capacity type Users and some with capacity type Memory, the report includes two charts, each of which could include usage from several license pools. License A chart is produced for each license pool defined for the product. In the Define the reporting time section, enter the effective date and time for which you want to make the report. By default, the date and time are current. Click Next.

Figure 6-8 Parameters for trend analysis - 2

194

Introducing IBM Tivoli License Manager

5. Figure 6-9 shows the resulting report. This report shows you the software usage by capacity for a selected product. You can also have a report of software usage by license for a selected product.

Figure 6-9 Trend analysis report

The latter section of the report is visible by scrolling down the report screen. This additional information is shown in Figure 6-10. You also can redefine the report by changing the Date, Time, and Query by options.

Chapter 6. Reporting with IBM Tivoli License Manager

195

Figure 6-10 Trend analysis report parameters

Software usage level analysis report


This report provides detailed information about the software usage level analysis. It gives the level of usage of product during the specified time duration. The usage level analysis can be Average Usage or High water mark. To obtain the software usage trend analysis report, follow these steps: 1. Log on to the ITLM Administration Server Web interface. 2. Select the Customer for which you want to make the software usage trend analysis report. Click Software Usage -> Level Analysis. 3. To produce a historical level analysis for the selected Customer, select the criteria shown as an example in Figure 6-11. Click Next.

196

Introducing IBM Tivoli License Manager

Figure 6-11 Parameters for level analysis - 1

Where, the values of variables are as follows: SW Vendor Platform Product name Division The selection list includes publishers of software whose products can be included in the report. The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager. Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions.

Chapter 6. Reporting with IBM Tivoli License Manager

197

Agent name

If you want to obtain reports for a particular Agent, or a group of Agent belonging to the same search criteria entered, wildcard characters (%) are allowed.

4. In the next window, shown in Figure 6-12, Product name and Agent name drop-down boxes appear. Select the proper software for which the report is to be made. On the Agent name, you can select All, showing the trend for all Agents of a particular Division, or select one specific Agent. In the Define the reporting period, enter the effective date and time for which you want to make the report. Click Next.

Figure 6-12 Parameters for level analysis - 2

198

Introducing IBM Tivoli License Manager

5. In the next window, select the values for the usage level threshold (high water mark or average usage), Capacity Type, and report order, as shown in Figure 6-13.

Figure 6-13 Parameters for level analysis - 3

6. Figure 6-14 shows the resulting report. The report gives you the level of usage of selected products on selected nodes. This is for the period you specified. The report presented here is based on the high water mark.

Chapter 6. Reporting with IBM Tivoli License Manager

199

Figure 6-14 Level analysis report

200

Introducing IBM Tivoli License Manager

Software inventory report


This report provides detailed information about the software inventory, that is the details of software products installed on the ITLM Agents. You can generate report for a particular Agent or for multiple Agents of a Division. The report can be generated product-wise or agent-wise. To work on Software Inventory report, follow these steps: 1. Log on to the ITLM Administration Server Web interface. 2. Select the Customer for which you want to make the software usage trend analysis report. Click Software Inventory -> Report. 3. To produce a software inventory for the selected Customer, select the criteria shown, as an example, in Figure 6-15. Click Next.

Figure 6-15 Parameters for software inventory - 1

Where, the values of variables are as follows: SW Vendor Platform The selection list includes publishers of software whose products can be included in the report. The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager.

Chapter 6. Reporting with IBM Tivoli License Manager

201

Product name Division

Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions. If you want to obtain reports for a particular Agent, or a group of Agents belonging to the same search criteria entered, wildcard characters (%) are allowed.

Agent name

4. In the next window, shown in Figure 6-16, Product name and Agent name drop-down boxes appear. Select the proper software for which the report is to be made. On the Agent name, you can select All, showing the trend for all Agents of a particular Division, or select one specific Agent. Select also whether the report will be ordered by product or Agent. In the Define the reporting time, enter the effective date and time for which you want to make the report. Click Next.

202

Introducing IBM Tivoli License Manager

Figure 6-16 Parameters for software inventory - 2

5. Figure 6-17 displays the resulting report. This example report shows the software inventory for a particular Node of the Finance Division and software vendor Adobe.

Chapter 6. Reporting with IBM Tivoli License Manager

203

Figure 6-17 Software inventory report

6.1.2 ITLM Runtime Server report


ITLM Runtime server holds information on software usage for its Agents. This information is always up to date due to the control the Runtime server has over its Agents. The reports provided by the Runtime server are real-time software usage and are available from the Web interface on Runtime servers. The report includes a snapshot of detailed information about the products and their current level of usage, the license pools that are available, and the sessions that are active. To work on real-time software usage report, follow these steps: 1. Log on to the ITLM Runtime Server Web interface. To access the login window, type this URL in your Web browser.

204

Introducing IBM Tivoli License Manager

http://<runtime_server_hostname:80/slmruntime/login

If you are using SSL, to get the login window use this URL, instead:
https://<runtime_server_hostname:443/slmruntime/login

Upon initial login to IBM Tivoli License Manager Web interface, you must use the following: User Name: tlmroot Password: system 2. The next window is a Welcome window. If you have more than one Customer defined, select the Customer for which you want to make the snapshot report. Click Software Usage. 3. To produce a historical snapshot for Customer, select the criteria shown as an example in Figure 6-18. Click Next.

Figure 6-18 Parameters for real-time report - 1

Where, the values of variables are as follows: SW Vendor The selection list includes publishers of software whose products can be included in the report.

Chapter 6. Reporting with IBM Tivoli License Manager

205

Platform Product name Division

The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager. Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions. If you want to obtain reports for a particular Agent, or a group of Agents belonging to the same search criteria entered, wildcard characters (%) are allowed.

Agent name

4. In the next window, shown in Figure 6-19, Product name and Agent name drop-down boxes appear. Select the proper software for which the report is to be made. On the Agent name, you can select All, showing the trend for all Agents of a particular Division, or select one specific Agent. Click Next.

Figure 6-19 Parameters for real-time report - 2

5. Figure 6-20 displays the resulting report. In this example the report shows the real-time software usage for a particular Node in the Finance Division and

206

Introducing IBM Tivoli License Manager

software vendor Adobe. Products may or may not be being used at that particular time. For example, the report shows that the product Adobe Framemaker Version 6.0 was being used (it is highlighted in the figure by a circle).

Figure 6-20 Real-time report

6. You can drill-down into the report by clicking the hyper-link values in the In Use column. It will take you to the details about that particular product usage, as shown in Figure 6-21. In this report, details of the product and Agent are displayed. The report also shows the user name which is logged in this Agent and the grant date. The grant date is the date and time the licence was assigned. Click Back to go back to the main report page.

Chapter 6. Reporting with IBM Tivoli License Manager

207

Figure 6-21 Details of software In Use

7. By scrolling down the report window shown in Figure 6-20, you will be able to it view the details of each software listed. This is shown in Figure 6-22 and Figure 6-23. You will also be able to access this information if you click on the software name hyper-links. The information provided there displays product, software entitlement, and license pool information.

208

Introducing IBM Tivoli License Manager

Figure 6-22 Section of Real-time report

Chapter 6. Reporting with IBM Tivoli License Manager

209

Figure 6-23 Section of Real-time report

6.2 Tivoli Data Warehouse integration


The Tivoli Data Warehouse (TDW) is an infrastructure used to collect and manage data from various Tivoli and non-Tivoli system management applications. The data is imported into the Tivoli Data Warehouse databases through specialized programs called extract, transform, and load (ETL)

210

Introducing IBM Tivoli License Manager

programs, from the management application data sources, and further processed for historical analysis and evaluation. Tivolis strategy is to have most of its products providing ETLs so that the Tivoli Data Warehouse databases can be populated with meaningful systems management data. IBM Tivoli License Manager is one of the many products to fully leverage and utilize Tivoli Data Warehouse. The following sections explain how the integration with the Tivoli Data Warehouse can be achieved and how to obtain the IBM Tivoli License Manager reports through Tivoli Data Warehouse.

6.3 Tivoli Data Warehouse overview


Customers can benefit from using Tivoli Data Warehouse in various ways, such as: Tivoli Data Warehouse collects historical data from many applications into one central place. Tivoli Data Warehouse collects the underlying data about Customers network devices/connections, desktops/servers, applications/software, and the problems and activities that have gone on to manage the infrastructure. This allows the Customers to construct an end-to-end view of their enterprise and view the components independent of specific applications used to monitor and control resources. Tivoli Data Warehouse adds value to raw data. Tivoli Data Warehouse performs data aggregation in hourly levels in the central data repository and can be restricted to other levels, such as daily and weekly, for data reporting in the data marts. The data is also cleaned and consolidated to allow the data model of the central repository to share common dimensions. For example, Tivoli Data Warehouse ensures that time, host name, and IP address are the same dimensions across all of the applications. Tivoli Data Warehouse allows the correlation of information from many Tivoli applications. Tivoli Data Warehouse can also be used to derive added value by correlating data from many Tivoli applications. It allows reports to be written, which correlate cross application data. Tivoli Data Warehouse uses open, proven interfaces for extracting, storing, and sharing the data.

Chapter 6. Reporting with IBM Tivoli License Manager

211

Tivoli Data Warehouse can extract data from any application (Tivoli and non-Tivoli) and store it in a common central database. Tivoli Data Warehouse also provides transparent access for third-party Business Intelligence (BI) solutions (CWM standard), such as IBM DB2 OLAP, Crystal Decisions, Cognos, BusinessObjects, Brio Technology, and Microsoft OLAP Server. CWM stands for Common Warehouse Metadata, an industry standard specification for metadata interchange defined by the Object Management Group (see http://www.omg.org). Tivoli Data Warehouse provides a Web-based reporting front end, called the Reporting Interface, but the open architecture provided by the Tivoli Data Warehouse allows other BI front ends to be used to access the data in the central warehouse. The value here is flexibility. Customers can use the reporting application of their choice; they are not limited to any one. Tivoli Data Warehouse provides a robust security mechanism. Tivoli Data Warehouse provides a robust security mechanism by allowing data marts to be built with data from subsets of managed resources. By providing database level authorization to access those data marts, Tivoli Data Warehouse can address most of the security requirements related to limiting access to specific data to those Customers/business units with a need to know. Tivoli Data Warehouse provides a scalable architecture. Since Tivoli Data Warehouse depends on the proven and industry standard RDBMS technology, it provides a scalable architecture for storing and retrieving the data.

6.4 Tivoli Data Warehouse concepts and components


In this section, we describe the key concepts and the various components of Tivoli Data Warehouse in the logical order that the measurement data flows: from raw data being collected by applications such as IBM Tivoli License Manager to the final detailed report. Figure 6-24 depicts a typical Tivoli Data Warehouse configuration that can be used as an illustration.

212

Introducing IBM Tivoli License Manager

Source Applications TEDW Environment

ITM

ITM Database

Data Mart

TEC

TEC Database

Data Mart

TEDW Central Data Warehouse

Target ETLs

Data Mart

TEDW Reporting Interface

IBM Tivoli License Manager

TLMA Database

Source Appls ETLs

Data Mart

Data Mart

Business Intelligence and Reporting Tools


ITSLA
ITSLA Database
TEDW Control (Metadata)
IBM BRIO

Cognos

TEDW Control Center

Business Objects

Crystal Reports

Third Party

Third-Party Database

Figure 6-24 A typical Tivoli Data Warehouse environment

It is common for enterprises to have various distributed performance and availability monitoring applications deployed that collect some sort of measurement data and provide some type of threshold management, central event management, and other basic monitoring functions. These applications are referred to as source applications. The first step in obtaining management data is to enable the source applications. This means providing all tools and customizations necessary to import the source operational data into the Tivoli Data Warehouse central data warehouse. All components needed for that task are collected in a so-called warehouse enablement package for each source application. In this chapter, IBM Tivoli License Manager is the source application providing license management and software entitlement information through each of its application components: Administration and Runtime servers. All the data needed for reporting is stored in the TLMA database in the IBM Tivoli License Manager Administration server and is then loaded into the TDW databases. One important part of the warehouse packages are the extract, transform, and load data programs, or, simply, ETL programs. In general, ETL programs process data in three steps. First, they extract the data from a source application database called data source. Then the data is validated, transformed, aggregated, and/or cleansed so that it fits the format and needs of the data target. Finally, the data is loaded into the target database.

Chapter 6. Reporting with IBM Tivoli License Manager

213

In Tivoli Data Warehouse, there are two types of ETLs: central data warehouse ETL and data mart ETL. Central data warehouse ETL The central data warehouse ETL pulls the data from the source applications and loads it into the central data warehouse, as shown in Figure 6-24. The central data warehouse ETL is often referred to as source ETL or ETL1. Data mart ETL As shown in Figure 6-24, the data mart ETL extracts a subset of historical data from the central data warehouse, which contains data tailored to and optimized for a specific reporting or analysis task. This subset of data is used to populate data marts. The data mart ETL is also known as target ETL or ETL2. IBM Tivoli License Manager provides a TDW enablement pack composed by source and target ETLs as explained above. As a generic concept, a data warehouse is a structured extensible database environment designed for the analysis of consistent data. The data that is inserted in a data warehouse is logically and physically transformed from multiple source applications, updated and maintained for a long time period, and summarized for quick analysis. The Tivoli Data Warehouse central data warehouse (CDW) is the database that contains all enterprise-wide historical data (with hour as the lowest granularity). This data store is optimized for the efficient storage of large amounts of data and has a documented format that makes the data accessible to many analysis solutions. The database is organized in a very flexible way, which lets you store data from new applications without adding or changing tables. The Tivoli Data Warehouse server is an IBM DB2 Universal Database Enterprise Edition server that hosts the Tivoli Data Warehouse Central Data Warehouse databases. These databases are populated with operational data from Tivoli and/or other third-party applications for historical analyses. A data mart is a subset of the historical data that satisfies the needs of a specific department, team, or Customer. A data mart is optimized for interactive reporting and data analysis. The format of a data mart is specific to the reporting or analysis tool you plan to use. Each application that provides a data mart ETL creates its data marts in the appropriate format. Tivoli Data Warehouse provides a Report Interface (RI) that creates static two-dimensional reports of your data using the data marts. The Report Interface is a role-based Web interface that can be accessed with a simple Web browser without any additional software installed on the client. You can also use other tools to perform OLAP analysis, business intelligence reporting, or data mining.

214

Introducing IBM Tivoli License Manager

The Tivoli Data Warehouse Control Center is the IBM DB2 Universal Database Enterprise Edition server containing the Tivoli Data Warehouse control database that manages your Tivoli Data Warehouse environment. From the Tivoli Data Warehouse Control Center, you can see all source applications databases in your environment. The default internal name for the Tivoli Data Warehouse Control database is TWH_MD. The Tivoli Data Warehouse Control Center also manages the communication between the various components, such as the Tivoli Data Warehouse Central Data Warehouse, the data marts, and the Report Interfaces. The Tivoli Data Warehouse Control Center uses the DB2 Data Warehouse Center utility to define, maintain, schedule, and monitor the ETL processes. The Tivoli Data Warehouse stores cleansed historical data from all Tivoli and third-party application databases in the Tivoli Data Warehouse Central Data Warehouse database. The database name of the Tivoli Data Warehouse Central Data Warehouse database is TWH_CDW. Once the data has been inserted into the TWH_CDW database, it is available for either the Tivoli Data Warehouse ETLs to load to the Tivoli Data Warehouse Data Mart database (the database name of the Tivoli Data Warehouse Data Mart database is TWH_MART) or to any other application-specific ETL to process the data and load the application-specific Data Mart database. All Tivoli Data Warehouse ETL programs follow a naming convention using a three letter application-specific product code known as measurement source code. Specifically, the measurement source code of the TDW enablement pack for IBM Tivoli License Manager is COD.

6.5 ITLM and TDW integration components


Figure 6-25 shows the structure of the IBM Tivoli License Manager and Tivoli Data Warehouse integration components deployed in our ITSO lab environment. The steps for how to get this integration environment up and running will be explained later in this chapter.

Chapter 6. Reporting with IBM Tivoli License Manager

215

TLMA Database

Windows 2000 SP3 DB2 EE Server 7.2 FP6 TEDW 1.1 FP2 Server ITLM ETLs
TEDW Server

ITLM Admin Server

TWH_MD

Web Browsers connecting to the Report Interface

1
TLMR Database ITLM Runtime Server ITLM Runtime Server TLMR Database
TWH_CDW

TWH_MART

ITLM Agent

ITLM Agent

Reporting data using OLAP and business intelligence tools

Figure 6-25 IBM Tivoli License Manager warehouse environment

From Figure 6-25, the warehouse processing goes through the following steps: 1. All the software usage, license agreement, license usage, Customer information, and inventory information data is rolled up from the Agents to the ITLM Runtime server databases, named TLMR. All the data is then moved to the ITLM Administration server and stored in a central repository database, named TLMA. 2. Using the IBM Tivoli License Manager enablement pack source ETLs, data from the ITLM Administration server database is loaded to the central data warehouse. 3. From this central data warehouse database, the IBM Tivoli License Manager enablement pack target ETL can extract data related to license management and load the TDW data mart database (TWH_MART). 4. Data in the TWH_MART can be shown using the IBM Tivoli License Manager enablement pack predefined reports using the TDW reporting interface. The TDW reporting interface runs on top of the IBM console application. Now, we can start installing the components.

216

Introducing IBM Tivoli License Manager

6.6 Installation and configuration for TDW integration


In this section, we describe the necessary steps to configure the data gathering process in your TDW environment. The high level steps are as follows: 1. Have the environment with the IBM Tivoli License Manager installed and working properly. Refer to Chapter 4, Getting IBM Tivoli License Manager up and running on page 99 for details. 2. Have the Tivoli Data Warehouse server or servers installed properly with the necessary patches; details can be found in the redbook Introduction to Tivoli Enterprise Data Warehouse, SG24-6607. 3. Install and configure the IBM Tivoli License Manager enablement pack component; see 6.6.1, ITLM Warehouse enablement pack installation on page 217. 4. Display and view the reports using the IBM console; refer to 6.7.1, Accessing the reports on page 228. Before going into the details of each step, refer to Figure 6-25 where we present the environment used in the ITSO lab. This can be used as a start point for setting up the data gathering process. We assume no pre-existing components will be used and describe the steps of a brand new installation. As you may have noticed, we install most of the data warehouse components on a single machine; however, for a production environment, you may want to have the following separate machines: Tivoli Data Warehouse Server machine hosting the Central Warehouse and the Warehouse data mart databases; this needs the largest disk capacity and the fastest processor. Tivoli Data Warehouse Control Center machine hosting the Warehouse metadata database and handling all the ETLs scheduling. Tivoli Data Warehouse Reporting Interface machine allowing end users to obtain reports from data stored in the IBM Tivoli Monitoring data marts.

6.6.1 ITLM Warehouse enablement pack installation


In this section we assume that your Tivoli Data Warehouse version 1.1 environment already has been installed and is up and running. Prior to the installation of the Warehouse packs programs, perform these required tasks, if you have not already done so during the TDW installation: Upgrade IBM DB2 Universal Database Enterprise Edition Version 7.2 to at least FixPack 6 level on your Tivoli Data Warehouse environment.

Chapter 6. Reporting with IBM Tivoli License Manager

217

FixPack6 for IBM DB2 Universal Database Enterprise Edition can be downloaded from the official IBM DB2 technical support Web site at:
http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7fphis t.d2w/report

Apply the 1.1-TDW-0002 fix for the Tivoli Data Warehouse and one of the following fixes: 1.1-TDW-0005E and 1.1-TDW-FP01a 1.1-TDW-FP02 Note: At the time of writing this book, the TDW fix 1.1-TDW-FP02 was in the beta development phase. You should apply this fix, as soon as it becomes available, because it supersedes the fixes 1.1-TDW-0005E and 1.1-TDW-FP01a. These fixes for Tivoli Data Warehouse can be downloaded from the IBM Tivoli Software support Web site, under the Tivoli Data Warehouse category at:
http://www.ibm.com/software/sysmgmt/products/support/TivoliEnterpriseDataWa rehouse.html

The documentation that accompanies the fixes, provides considerable detail of the steps for installation. Important: The redbook Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, mentions that the Windows Services Warehouse Server and Warehouse Logger must be reconfigured to run as the db2admin user. If you have not made this change, you will see failures when trying to import data into the TWH_CDW database. Please confirm that you have reconfigured these services and restarted them.

The installation can be done using the Tivoli Data Warehouse CLI or the GUI installation program. Here we describe the process using the GUI method. The following steps should be performed in the Tivoli Data Warehouse Control Center server. You need both the Tivoli Data Warehouse and the IBM Tivoli License Manager products installation media. 1. Run the setup.exe from the Tivoli Data Warehouse CD-ROM and click OK to start the installation. 2. When the InstallShield Wizard dialog window for Tivoli Data Warehouse Installation appears, click Next.

218

Introducing IBM Tivoli License Manager

3. The dialog window for the type of installation appears. Select Application installation only and the directory name where the Tivoli Data Warehouse components are installed. As our TDW Control Center server is installed on a Windows 2000 machine, we used C:\TWH. Click Next to continue. 4. The host name dialog window appears. Verify that this is the correct host name for the Tivoli Data Warehouse Control Center server. Click Next. 5. The local system DB2 configuration dialog window appears. The installation process asks for a valid DB2 user ID. Enter the valid DB2 user ID and password that were created during the DB2 installation on your local system. In our case, we used db2admin. Click Next. 6. The path to the installation media for the application packages dialog window appears, as shown in Figure 6-26. You should provide the location of the IBM Tivoli License Manager warehouse enablement pack program. Change out the Tivoli Data Warehouse CD in the CD-ROM drive with the IBM Tivoli License Manager warehouse enablement pack installation CD. Specify the path to the twh_app_install_list.cfg file (by default, in the CD_drive:\tedw_apps\cod\ directory) in the directory name field. Leave the Now (prevents typing errors) option checked, to verify that the source directory is immediately accessible and that it contains the correct files. Click Next.

Figure 6-26 Path to the installation media for the COD

7. The overview of selected features dialog window appears, as shown in Figure 6-27. Click Install to start the installation.

Chapter 6. Reporting with IBM Tivoli License Manager

219

Figure 6-27 IBM Tivoli License Manager warehouse pack installation

8. Once the installation is finished, the Installation summary window appears, as shown in Figure 6-28. If the installation was not successful, check the TWHApp.log file for any errors. This log file is located in <TWH_inst_dir>\apps\COD\, where <TWH_inst_dir> is the Tivoli Data Warehouse installation directory.

Figure 6-28 Installation summary window ITLM warehouse enablement pack

220

Introducing IBM Tivoli License Manager

9. After the pack installation conclusion, you must reboot the Tivoli Data Warehouse Control Center server.

6.6.2 ITLM Warehouse enablement pack configuration


There is a need to change some configuration settings for the IBM Tivoli License Manager warehouse enablement pack to function properly. They are: Change the control heap size in the TWH_CDW database Create a new ODBC connection to the TLMA database Define user authority to the Warehouse Sources and Targets ETLs Schedule the Sources and Targets ETLs Change the Sources and Targets ETLs status to Production

Changes on the TWH_CDW database


To improve performance, we advise you to change the applications control heap size on the TWH_CDW database to be set to at least 512, as follows: 1. Logged in as your DB2 administrator user ID on your Tivoli Data Warehouse Server machine (in our case db2admin), connect to the TWH_CDW database:
db2 connect to TWH_CDW user db2admin using <db2pw>

Where, <db2pw> is the database administrator password. 2. To determine the actual heap size, issue:
db2 get db cfg for TWH_CDW | grep CTL_HEAP

The output should be similar to this:


Max appl. control heap size (4KB) (APP_CTL_HEAP_SZ) = 128

3. If the heap size is less that 512, change it by performing:


db2 update db cfg for TWH_CDW using APP_CTL_HEAP_SZ 512

The output should be similar to this:


DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. DB21026I For most configuration parameters, all applications must disconnect from this database before the changes become effective.

4. You should now restart DB2 by issuing:


db2 disconnect THW_CDW db2 force application all db2 terminate db2stop db2admin stop db2admin start

Chapter 6. Reporting with IBM Tivoli License Manager

221

db2start

Creating an ODBC connection to the TLMA database


The Tivoli Data Warehouse Control Center server hosts all the ETL programs, and it needs to have access to the various databases that the SQL scripts deal with. In the case of the IBM Tivoli License Manager source and target ETLs, a connection to the TLMA database should be defined. On the Tivoli Data Warehouse Control Center server, using a DB2 command line window, issue the following commands:
db2 catalog tcpip node CAT_ODBC remote <ITLM_ADM> server <DB2_PORT> db2 catalog database TLMA at node CAT_ODBC db2 catalog system odbc data source TLMA

Where, <ITLM_ADM> is the Tivoli Data Warehouse Server host name, and <DB2_PORT> is the TCP/IP port used by DB2 (the default is 50000). Tip: You can also perform this task using the DB2 Client Configuration Assistant.

Defining user authority to the Source and Target ETLs


You should inform the Tivoli Data Warehouse Control Center server of user access information for every Source and Target ETL process installed by the IBM Tivoli License Manager warehouse enablement pack. The following steps should be taken: 1. Start the IBM DB2 Control Center utility by selecting Start -> Programs -> IBM DB2 -> Control Center. 2. On the IBM DB2 Control Center utility, start the IBM DB2 Data Warehouse Center utility by selecting Tools -> Data Warehouse Center. The Data Warehouse Center logon windows appears. 3. Log into the IBM DB2 Data Warehouse Center utility using the local DB2 administrator user ID, in our case, db2admin. 4. In the Data Warehouse Center window, expand the Warehouse Sources folder. As shown in Figure 6-29, there are three entries for the IBM Tivoli License Manager source ETL programs that need to be configured, as follows: COD_TLMA_Source COD_TWH_CDW_Source COD_TWH_MD_Source

222

Introducing IBM Tivoli License Manager

Figure 6-29 IBM Tivoli License Manager Source ETLs

You should edit the properties of each one of the above entries. To do this, right-click on an entry and select Properties and then select the Database tab. Fill in the database instance owner user ID information. For our environment, the values are shown in Figure 6-30, using the COD_TLMA_Source as an example.

Figure 6-30 COD_TLMA_Source user ID information

Chapter 6. Reporting with IBM Tivoli License Manager

223

5. For the IBM Tivoli License Manager Targets, shown in Figure 6-31, expand the Warehouse Target folder. There are three entries for the IBM Tivoli License Manager target ETL programs that need to be configured, as follows: COD_TWH_CDW_Target COD_TWH_MART_Target COD_TWH_MD_Target

Figure 6-31 IBM Tivoli License Manager Target ETLs

You should edit the properties of each of the above entries. For example, right-click the COD_TWH_CDW_Target, select Properties, and then select the Database tab. Fill in the user ID information as appropriate for your environment, as shown in Figure 6-32.

224

Introducing IBM Tivoli License Manager

Figure 6-32 COD_TWH_CDW_Target user ID information

Scheduling the source and target ETL processes


There are two processes that need to be scheduled for the IBM Tivoli License Manager warehouse enablement pack ETL processes to run. They are: COD_c05_Extract_TLM_Data_Process This process is linked to the source ETL. COD_m05_Populate_Mart_Process This process is linked to the target ETL. The following steps are similar for both processes and we use COD_m05_Populate_Mart_Process to describe them: 1. On the Tivoli Data Warehouse Control Center server, using the Data Warehouse Center window, expand Subject Areas. Select COD_TivoliLicenseManager_V1.1.0_Subject_Area -> Processes and right-click COD_m05_Populate_Mart_Process. Choose Schedule, as shown in Figure 6-33.

Chapter 6. Reporting with IBM Tivoli License Manager

225

Figure 6-33 Schedule COD_m05_Populate_Mart_Process

2. Selecting Schedule will open up a dialog box, as shown in Figure 6-34.

Figure 6-34 Schedule configuration for COD_m05_Populate_Mart_Process

226

Introducing IBM Tivoli License Manager

You should schedule the ETL to run daily during off-hours.

Changing the source and target ETL status to Production


Both the COD_c05_Extract_TLM_Data_Process and the COD_m05_Populate_Mart_Process are composed by process steps that have the Development status set as the default. In order for them to run, their status need to be changed from Development to Production. They are: COD_c05_Extract_TLM_Data_Process COD_c05_s010_Extract_TLM_Data COD_m05_Populate_Mart_Process COD_m05_s010_Populate_Mart COD_m05_s020_Populate_Mart The following step must be performed for all processes described above. Here we use COD_c05_Extract_TLM_Data_Process to describe it. On the Tivoli Data Warehouse Control Center server, using the Data Warehouse Center window, select the above processes and right-click on them. Select Mode -> Production, as shown in Figure 6-35.

Figure 6-35 Promoting scheduled processes to production status

Chapter 6. Reporting with IBM Tivoli License Manager

227

6.7 TDW reports


IBM Tivoli License Manager provides a set of data marts and predefined reports that allow you to use the IBM console for viewing and creating reports. The TDW Report Interface is not meant to replace OLAP or business intelligence tools. If you have multidimensional reporting requirements or need to create a more sophisticated analysis of your data, Tivoli Data Warehouse's open structure provides you an easy interface to plug into OLAP or other business intelligence tools. Nevertheless, for two dimensional reporting requirements, TDW Reporting Interface provides you a powerful tool. The Reporting Interface of Tivoli Data Warehouse provides three types of reports: Summary reports The summary report is typically used to display a many measurements versus a many components relation. The result is a table where the rows show components or groups of components and the columns typically show the measurements. Additionally, summary values for all components and all groups of components are shown. This kind of report can be used if, for example, you want to create an overview of the workload of servers or server groups. Extreme case reports The extreme case report is a one measurement versus many components report. With this type of report, you can find the components or component groups with the highest or lowest values of a certain metric. The result will be a graph with the worst or best components in the x-axis and the corresponding metric values in the y-axis. Health reports The health report is typically used to display many measurements against many components versus time relation. The result is a graph where the x-axis shows the time and the y-axis typically shows the measurements. This kind of report is used to show the time-development of a metric. This allows you to recognize a trend and to predict possible health problems of a component in the future.

6.7.1 Accessing the reports


To access the reports available through the reporting interface of the Tivoli Enterprise Warehouse Manager, use the IBM Console which is also a part of the Tivoli Data Warehouse solution.

228

Introducing IBM Tivoli License Manager

Typically you access the IBM Console through the URL:


http://<tedwserver>/IBMConsole

Where, <tedwserver> is the name of your warehouse server providing the IBM Console support.

Figure 6-36 Logging on to the IBM Console

After you log on, you can access the menus on the left side to manage reports, as shown in Figure 6-37.

Chapter 6. Reporting with IBM Tivoli License Manager

229

Figure 6-37 IBM Console report menu

Tip: For users logged on as superadmin, the portfolio and the context menus for reports contain multiple menus. For example, the context menus contain two Create a Report entries and three entries for Properties. Use the first entry in the list of duplicate entries that represents the highest level role authorized to perform that function. At this point, you can create your own reports (assuming you have proper authority), or access existing reports.

230

Introducing IBM Tivoli License Manager

If you choose to create your own report, you will see a series of dialog boxes that allow you to choose the type of report, the data mart containing the data you want to create the report from, and a variety of other options to enable you to select the actual data and report options you desire. Your options will vary, based on the type of report you are creating.

6.7.2 Reports available with IBM Tivoli License Manager


IBM Tivoli License Manager provides four predefined reports that can be accessed through the Tivoli Data Warehouse reporting interface. These reports and their types are as follows: Agents Installed by Division Summary Report Products Installed by Division Summary Report Products Installed by Division Extreme Report Agents Installed by Division Extreme Report To access these reports, use the browser interface to the IBM Console. After you log on to the IBM Console, select the Work with Reports option. Depending on what other products you have installed, you may see several screens of available reports; however, you can set filters to make it easier to select the specific reports you are interested in. Figure 6-38 shows a list of the available reports related to IBM Tivoli License Manager.

Chapter 6. Reporting with IBM Tivoli License Manager

231

Figure 6-38 Report list for IBM Tivoli License Manager

After you select a specific report, you still have options to customize the specific data you want to see. For example, you may want to select a specific time frame or aggregation level. Here we provide two reports as an example: Figure 6-39 shows the Product Installed by Division summary report. Figure 6-40, shows an example of an extreme case report showing IBM Tivoli License Manager Agent Installed by Division.

232

Introducing IBM Tivoli License Manager

Figure 6-39 Summary report: Products Installed by Division

Chapter 6. Reporting with IBM Tivoli License Manager

233

Figure 6-40 Extreme case Report: ITLM Agents Installed by Division

The two sample reports shown here are meant to provide you with an idea of the types of reports that are available out-of-the-box with the IBM Tivoli License Manager warehouse enablement pack. There are several other reports that can also be created, and more importantly, the data associated with the monitoring of your software and license management is also available to be accessed by other business intelligence and reporting tools.

234

Introducing IBM Tivoli License Manager

Chapter 7.

Performance maximization techniques


IBM Tivoli License Manager is dependent on a number of supporting applications and components that need to be tuned up for proper performance. This chapter gives tips and hints for performance enhancement of critical components and supporting applications of an IBM Tivoli License Manager environment. The focus regarding performance tuning discussed in this chapter are for the following components: IBM DB2 Universal Database Enterprise Edition IBM WebSphere Application Server IBM HTTP Server IBM Tivoli License Manager Administration and Runtime servers Supported operating systems

Copyright IBM Corp. 2003. All rights reserved.

235

7.1 Initial considerations


The following sections provide performance tuning tips for small, medium, and large configurations. Because these may not be the best settings for your environment, a suggested approach would be to use these values as a starting point and then to monitor system performance, making changes where necessary. For the purposes of this chapter, a small, medium, and large environment is defined as follows.

Small ITLM environment


Figure 7-1 shows an example of an ITLM implementation for a small customer site.

ITLM Administration server ITLM Runtime server Database server

ITLM Agents Email notification server

Figure 7-1 ITLM implementation for small environment

In this scenario, the customer is operating from a single location, with few Divisions. There are no WAN connections. The characteristics of small environment are: Less than 2500 nodes No WAN connections Administration server, Database server, and Runtime server on the same physical machine The Runtime server component, on this machine, communicates with the Agents installed on the end user machines. Runtime server also communicates with the external notification system.

236

Introducing IBM Tivoli License Manager

The Administration server component communicates with the Runtime server on the same machine. Browsers can access the machine where the Administration server and the Runtime server components are installed so that the administrator can view the historical and real-time reports that are available.

Medium ITLM environment


Figure 7-2 shows an example of an ITLM implementation for a medium size customer site.

ITLM Runtime server Database server ITLM Administration server Database server ITLM Agents

Remote Site

Email Notification server

ITLM Agents

ITLM Runtime server Database server

Figure 7-2 ITLM implementation for medium environment

In this scenario, the structure is expanded to deal with additional Agents, up to 5000. To maintain performance levels, the Administration server and its database are installed on separate machines and additional a Runtime server is installed for remote site which is connected to the main site via WAN. Each Runtime server is assigned a set of Agents. The characteristics of medium environment are: Up to 5000 nodes Different machines for Administration server and Runtime Up to two remote locations An interface to the notification system is provided on both Runtime servers. Browsers can access the Administration server for maintenance and historical reporting tasks, and the Runtime servers for real-time reports.

Chapter 7. Performance maximization techniques

237

Large ITLM environment


Figure 7-3 shows an example of an ITLM implementation for a large environment.

Largest location in organization with large number of Agents

Agents

Runtime

Agents

Runtime

Admin

Database server

Notification
High Speed

WAN

Agents

Runtime Notification

Agents

Runtime Notification

Agents

Runtime Notification

Smaller locations on WAN with small number of Agents

Figure 7-3 ITLM implementation for large environment

In the scenario, the administration functions provided by the Administration server are located at a major site. This site has the majority of the nodes. All other sites are geographically away from each other, and are connected to the main site via WAN. Demographic information for all the sites served by the Hub site is collected in the centralized database. The administrators of this site can then access Administration server for maintenance and reporting functions. The characteristics of a large environment are: Total number of nodes up to 15000 Number of nodes up to 2500 per remote site per Runtime server Notification server at each site Can have more than one customer defined in ITLM Administration server, Database server, and Runtime servers installed on different physical machines

238

Introducing IBM Tivoli License Manager

7.2 IBM DB2 Performance tuning considerations


Depending on the size of your environment, there are many options available when tuning your IBM DB2 Universal Database Enterprise Edition servers performance. Follow the recommendations given in the following sections to help maximize your DB2 servers potential. Here are some of the factors affecting DB2 performance. This is based on the information provided by the redbook Database Performance Tuning on AIX, SG24-5511. Database Size The performance of the Administration server Web interface will be reduced if table sizes in the administration database (TLMA) become too large. Most of the database tables are reasonably static, because they include information that the administrator defines. Buffer pools A buffer pool is an area of memory. In this area, database pages of user table data, index data, and catalog data are temporarily moved from disk storage. DB2 Agents read and modify data pages in the buffer pool. The buffer pool is a key influence of overall database performance, because data can be accessed much faster from memory than from a disk. If most of the data required by applications is present in the buffer pool, then less time is needed to access this data. This improves performance. Buffer pools can be defined with varying page sizes including 4K, 8K, 16K and 32K. Prefetchers Prefetchers are present to retrieve data from disk and move it into the buffer pool before applications need the data. For example, applications needing to scan through large volumes of data would have to wait for data to be moved from disk into the buffer pool if there were no data prefetchers. Prefetchers are designed to improve the read performance of applications as well as utilities such as backup and restore, since they prefetch index and move data pages into the buffer pool, thereby reducing the time spent waiting for I/O to complete. The number of prefetchers may be controlled by the database configuration parameter NUM_IOSERVERS. Page cleaners Page cleaners are present to make room in the buffer pool, before Agents and prefetchers read pages from disk storage and move them into the buffer pool. For example, if an application has updated a large amount of data in a table, many of the updated data pages in the buffer pool may not yet have been written on to disk storage. Such pages are called dirty pages. Since prefetchers cannot place fetched data pages on to the dirty pages in the

Chapter 7. Performance maximization techniques

239

buffer pool, these dirty pages must first be flushed to disk storage and become clean pages, so that prefetchers can find room to place fetched data pages from disk storage. The number of page cleaners may be controlled by the database configuration parameter NUM_IOCLEANERS. This parameter allows you to specify the number of asynchronous page cleaners for a database. These page cleaners write changed pages from the buffer pool to disk before the space in the buffer pool is required by a database Agent. As a result, database Agents should not have to wait for changed pages to be written out so that they may use the space in the buffer pool. This improves overall performance of the database applications. If you set the parameter to zero (0), no page cleaners are started and as a result, the database Agents will perform all of the page writes from the buffer pool to disk. This parameter can have a significant performance impact on a database stored across many physical storage devices; since in this case there is a greater chance that one of the devices will be idle. If no page cleaners are configured, your applications may encounter periodic log full conditions. Logs Changes to data pages in the buffer pool are logged. Agent processes updating a data record in the database update the associated page in the buffer pool, and write a log record into a log buffer. To optimize performance, neither the updated data pages in the buffer pool, nor the log records in the log buffer are written to disk immediately. They are asynchronously written to disk by page cleaners, and the logger, respectively. The logger and the buffer pool manager cooperate and ensure that an updated data page is not written to disk storage before its associated log record is written to the log. This ensures database recovery to a consistent state from the log in the event of a crash such as a power failure. logfilsiz: Represents the size of the log files. logprimary: The primary log files establish a fixed amount of storage allocated to the recovery log files. This parameter allows you to specify the number of primary log files to be preallocated. logsecond: This parameter specifies the number of secondary log files that are created and used for recovery log files (only as needed). Java Heap parameters In general, increasing the size of the Java heap improves throughput until the heap no longer resides in physical memory. After the heap begins swapping to disk, Java performance deteriorates drastically. Therefore, the maximum heap size needs to be low enough to contain the heap within physical memory. MON_HEAP_SZ indicates the amount of memory (in 4K pages) which is allocated for database monitor data (at db2start). The amount of

240

Introducing IBM Tivoli License Manager

memory needed will depend on the number of snapshot switches which are turned on and active Event Monitors. If the memory heap is insufficient, an error will be returned when trying to activate a monitor and it will be logged to the db2diag.log file. Database heap There is one database heap per database, and the database manager uses it on behalf of all applications connected to the database. It contains control block information for tables, indexes, table spaces, and buffer pools. It also contains space for event monitor buffers, the log buffer (logbufsz), and temporary memory used by utilities. Therefore, the size of the heap will be dependent on a large number of variables. The control block information is kept in the heap until all applications disconnect from the database. Sort Heap Size (sortheap) If the rows to be sorted occupy more than the space available in the sort heap, several sort passes are performed, where each pass sorts a subset of the entire set of rows. Each sort pass is stored in a temporary table in the buffer pool, which might be written to disk. When all the sort passes are complete, these sorted subsets are merged into a single sorted set of rows. A sort is considered to be piped if it does not require a temporary table to store the final, sorted list of data. That is, the results of the sort can be read in a single, sequential access. Piped sorts result in better performance than non-piped sorts and will be used if possible. I/O Servers Configuring enough I/O servers with the num_ioservers configuration parameter can greatly enhance the performance of queries for which prefetching of data can be used. To maximize the opportunity for parallel I/O, set num_ioservers to at least the number of physical disks in the database. It is better to overestimate the number of I/O servers than to underestimate. If you specify extra I/O servers, these servers are not used, and their memory pages are paged out. As a result, performance does not suffer.

7.2.1 Small ITLM environments


If your environment can be categorized as a small environment according to 7.1, Initial considerations on page 236, consider making the following changes to your IBM DB2 Universal Database Enterprise Edition servers: Specify the number of asynchronous page cleaners for the TLMA database. It will significantly help tuning performance if you have more than one CPU:
db2 connect to TLMA user <DB2_user> using <DB2_password> db2 update db cfg for TLMA using num_iocleaners 2

Chapter 7. Performance maximization techniques

241

The following values can be set to prevent transaction failure with an out of transaction space on the DB error. The logfilsiz parameter specifies the amount of disk storage in pages that is allocated to the log files that are used for data recovery. The logprimary and logsecond parameters determine the number of primary and secondary log files that will be used for database recovery. Their size is determined by the number specified when setting the logfilsiz parameter. We recommend that you keep primary and secondary log files on different physical drives. So in case one drive is unusable, you can have access to the log files on another drive. The log file size can be increased or decreased depending on the frequency of updates.
db2 update db cfg for TLMA using logfilsiz 2500 db2 update db cfg for TLMA using logprimary 5 db2 update db cfg for TLMA using logsecond 5

For more information on the database and database manager parameter configurations, refer to the DB2 UDB Command Reference Version 7, SC09-2951.

7.2.2 Medium ITLM environments


If your environment is categorized as a medium-sized environment according to 7.1, Initial considerations on page 236, consider making the changes listed below to your IBM DB2 Universal Database Enterprise Edition servers, in addition to the recommendations described in 7.2.1, Small ITLM environments on page 241. In a medium environment, we also recommend that you take advantage of multiple hard disks, which will allow you to define multiple ioservers and iocleaners. Make the following changes to the TLMA database configuration on your ITLM Administration server: In small environment it does not make much sense to tune avg_appls parameter, because the Runtime server is in the same machine as Administration server and its the only one application accessing the TLMA database. It makes more sense to tune this parameter when the process is multi threaded.
db2 connect to TLMA user <DB2_user> using <DB2_password> db2 update db cfg for TLMA using avg_appls 5

The sortheap parameter is normally kept 20% of your largest and most accessed table. It may vary according to the environment.
db2 update db cfg for TLMA using sortheap 8000

242

Introducing IBM Tivoli License Manager

The iocleaners parameter will significantly help tuning performance if you have more than one CPU.
db2 update db cfg for TLMA using num_iocleaners 6

The ioservers parameter tunes the performance of writing to disk. It will significantly help tuning performance if you have more than one physical disks.
db2 update db cfg for TLMA using num_ioservers 5

The prefetch size parameter is normally kept at half of your largest table. It may vary according to the environment.
db2 update db cfg for TLMA using dft_prefetch_sz 32

IBMDEFAULTBP is a default bufferpool, and is normally kept at one fifth of your database size. It may vary according to the environment.
db2 alter bufferpool IBMDEFAULTBP size 25000

The following values can be set to prevent transaction failure with an out of transaction space on the DB error. The logfilsiz parameter specifies the amount of disk storage in pages that is allocated to the log files used for data recovery. The logprimary and logsecond parameters determine the number of primary and secondary log files that will be used for database recovery. Their size is determined by the number specified when setting the logfiles parameter. We recommend that you keep primary and secondary log files on different physical drives. So in case one drive is unusable, you can have access to the log files on another drive. The log file size can be increased or decreased depending on the frequency of updates as follows:
db2 db2 db2 db2 connect to TLMA user <DB2_user> using <DB2_password> update db cfg for TLMA using logfilsiz 2500 update db cfg for TLMA using logprimary 10 update db cfg for TLMA using logsecond 10

To optimize your IBM DB2 Universal Database Enterprise Edition environment for querying, perform the following: 1. Execute the runstats and reorgchk commands on the TLMA database, as it will significantly improve performance. The runstats command will provide statistics on particular database tables and indexes. The reorgchk utility will provide you with the amount of free space available and the amount of space being used. 2. Create a new temporary tablespace using one SMS container on a different operating system file system located on a separate physical disk. Drop the original temporary tablespace so that the new temporary tablespace is used. By simply moving the temporary tablespace to a different physical disk, elapsed time for a query can be cut by almost 25 percent.

Chapter 7. Performance maximization techniques

243

3. Use a TEMPSPACE tablespace with four container directories. Place the containers on disks that are not otherwise being used by the database. 4. The standard DB2 EXTENTSIZE and PREFETCHSIZE for the TEMPSPACE is 32 - 4 KB pages. DB2 has the ability to prefetch data asynchronously in anticipation of the CPU's ability to process it, therefore minimizing the impact of I/O service delays. PREFETCHSIZE dictates the quantity of data to asynchronously retrieve for each prefetch request. Generally, PREFETCHSIZE should be a multiple of EXTENTSIZE, and the multiple should be equal to the number of containers. 5. Enable intrapartition parallelism using the following command. This will be useful if you have Symmetric Multiprocessing. Do not do this if you have a machine with a single processor.
db2 update dbm cfg using INTRA_PARALLEL YES

Set the default degree of parallelism for the database to X# (where X# equals the number of system processors) using the following command:
db2 update db cfg for TLMA using DFT_DEGREE X#

7.2.3 Large ITLM environments


If your environment is categorized as a large environment according to 7.1, Initial considerations on page 236, follow the recommendations described in 7.2.2, Medium ITLM environments on page 242, and make the following additional changes: Make the following changes to the TLMA database configuration:
db2 alter bufferpool IBMDEFAULTBP size 10000 db2 alter tablespace USERSPACE1 prefetchsize 64

If you partition database across different physical disks, enable parallel I/O for every table space by issuing the following command:
db2set DB2_PARALLEL_IO=*

For more information regarding the topics found in the DB2 performance tuning section, refer to these documents:

DB2 UDB Version 7.1 Performance Tuning Guide, SC09-2945 DB2 UDB Administration Guide: Implementation Version 7, SC09-2944 DB2 UDB Command Reference Version 7, SC09-2951 Database Performance on AIX for DB2 UDB and Oracle Environments Redbook, SG24-5511 DB2 UDB Version 7.1 Performance Tuning Guide Redbook, SG24-6012
http://www.db2mag.com/db_area/archives/2001/q1/hayes.shtml

244

Introducing IBM Tivoli License Manager

http://www.db2mag.com/db_area/archives/2001/q4/hayes.shtml

7.3 IBM WebSphere performance tuning


The default values and setup of IBM WebSphere Application Server Advanced Edition V 4.0 are suitable for small environments, and no changes are necessary. For large ITLM environments, as described in 7.1, Initial considerations on page 236, we recommend that you set two related values on the WebSphere console for each server: initial and maximum Java heap sizes. The initial Java heap size sets the amount of memory that is initially reserved for the application, while the maximum Java heap size determines the largest amount of memory the application will be allowed to consume. To change the Java heap size settings for a Runtime server, complete the following steps. 1. Open the WebSphere administrative console and select either the Administration or Runtime server for which you want to change settings. 2. Select the JVM settings tab and change the following parameters: Initial Java heap size to 256 MB Maximum Java heap size to 786 MB 3. Observe the performance. If required you may change these values accordingly. We also recommend that you follow the instructions provided in the IBM WebSphere Application Server product documentation. Here is a brief description of some of the tools used to measure and tune WebSphere performance. 1. Resource Analyzer This is a stand-alone runtime performance monitor for WebSphere Application Server. It provides a Graphical User Interface (GUI) console that is available on Windows and UNIX platforms. Resource Analyzer can also be used remotely and across platforms. Another ability of this tool is to record the collected information and replay it without connecting to WebSphere Application Server. 2. PM PMI is a set of packages and libraries designed to assist with gathering, delivering, processing and displaying performance data in WebSphere Application Server domains. PMI uses a client/server architecture. In PMI terms, a server is any application that uses the PMI API to collect

Chapter 7. Performance maximization techniques

245

performance data. Servers can include application servers, Web servers, and Java applications. WebSphere Application Server provides a service named PmiService that is responsible for retrieving performance data from other servers in the domain and making the data available to interested clients. 3. Performance tuner wizard The Performance tuner wizard is a tool included in WebSphere Application Server Advanced Edition that includes the most common performance related settings associated with the application server. Use Performance Tuner Wizard to optimize the settings for applications, servlets, enterprise beans, data sources and expected load. Parameters that can be set include: Web container: Maximum thread size ORB properties: Pass-by-reference, ORB thread pool size Data source: Connection pool size, statement cache size Database (DB2 only): This calls the DB2SmartGuide, which, in turn, tunes the DB2 database associated with the data source Java Virtual Machine (JVM): Initial and maximum heap size For more information regarding the topics found in this performance tuning section, refer to the IBM WebSphere Application Server product documentation.

7.4 IBM HTTP Server performance tuning


For small, medium, and large configurations, we recommend that you change the following options in the httpd.conf file. The httpd.conf is located in the /http_server_dir/conf directory:
Example 7-1 httpd.conf parameters
KeepAlive Off MinSpareServer 2 MaxSpareServer 10 StartServers 2 MaxClients 150

246

Introducing IBM Tivoli License Manager

7.5 ITLM components performance considerations


On top of the considerations for tuning the support applications described in earlier sections, there are also options available for tuning your IBM Tivoli License Manager servers performance. In this section we discuss some of the possibilities to help maximize your IBM Tivoli License Manager environment performance.

Range of Runtime servers that an Agent can contact


This structure provides the benefits of improved performance provided by multiple Runtime servers without sacrificing license usage efficiency. Each Agent is assigned to a specific Runtime server. 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. Possible settings are: Allow the Agent to contact all Runtime servers. This is the default setting. Allow the Agent to contact Runtime servers that have Agents in the same Division. Restrict the Agent to its own Runtime server. In large environments (refer to Figure 7-3 on page 238), there are usually more than one Runtime server. The Agent can contact either of the Runtime servers. Allowing Agents, for example, to contact an alternative Runtime server in case its original Runtime server is heavily overloaded, can reduce waiting time for license requests, therefore improving end-user productivity.

Distribution of Agents between Runtime servers


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 always be assigned to a Runtime server that is local to them, so that response time when requesting licenses is kept to a minimum, as well as for security reasons, communication between Agents and Runtime servers do not need to be encrypted. There is also a recommended maximum of 7500 Agents assigned per Runtime server. Care should be taken to ensure that the Runtime 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.

Chapter 7. Performance maximization techniques

247

Overloading Administration server


Care should be taken to ensure that the Administration server is not likely to become overloaded because of too many Agents. There is a recommended maximum of 15000 Agents managed per Administration server. For example, five Runtime servers, each with 3000 Agents.

Separate ITLM servers and Database servers


In case of large environments, the Administration server may have to coordinate with many requests from Runtime servers and Agents. We recommend that the RDBMS serving the Administration server be installed on a separate machine. In this case, RDBMS server and Administration server may be connected via a high speed network so that network will not be a bottleneck causing performance to decrease a great extent.

Administration and Runtime on a single machine


Unless the Runtime server is to support a small number of Agents (fewer than 1000), we recommend that you do not install a Runtime server and the Administration server on the same machine.

Runtime servers at smaller sites that are geographically away


Even though it would be possible, in terms of capacity, for a single Runtime server to cover two small sites, each site should have a local Runtime server. Runtime servers should be local to the Agents they are dealing with to avoid excessive network traffic, to optimize performance, and for security reasons.

Number of Agents per Division


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 assigned to a single Runtime server. A Division can be split over more than one server, but it is not advisable to split it over too many. Number of Agents per Division greatly affects the flow of inventory data gathered during inventory scans.

Inventory scans
The number of Agents within a single Division assigned to a single Runtime server can be critical to the performance of the server. This is because the largest load on Runtime server occurs during the inventory scan. Inventory scan is scheduled Division-wise. You must determine an acceptable amount of time for an inventory scan of a Division to be completed, for example, a working day, and then estimate how many Agents in the same Division can be assigned to a single Runtime server.

248

Introducing IBM Tivoli License Manager

The Agent properties section of the system.properties file for each Runtime server includes settings that define the amount of time required to scan a node. These properties are pcInventoryDuration and serverInventoryDuration. Other considerations are: Inventory scans should be scheduled for times when other Agent activity is low. Scans for Divisions that have Agents assigned to the same Runtime server should not be scheduled so that they coincide or overlap. Before the information is available for reporting it must be transferred to the Runtime server and then to the Administration server.

Database Drivers
You should use the JDBC driver 2.0, because it provides advanced database capabilities (query optimized execution, data sources) that are not available with the version 1.2 driver. This version is a prerequisite of WebSphere 4.0, but not of WebSphere 3.5.6. If you are using WebSphere 3.5.6, you should switch to the JDBC driver 2.0. Instructions for this task are provided in 4.2, Setting up the ITLM Administration server on page 102.

Database Table Clean-up


The following tables in the Administration server database (TLMA) are continually added to by internal processes. Intervention is needed to stop the tables from growing to proportions that could affect performance: USAGE This table stores the information sent from Runtime servers to the Administration server in usage snapshot and usage update transactions. The usage snapshot contains information about the licenses in use at a point in time and is sent at regular intervals. It is the source of data used in the software usage reports, and performance of these reports would be affected if the table became too large. SERVICE This table maintains a history of requests for services. An entry is added to the table each time there is an inventory scan by an Agent, a update of Agent information, or a download of topology information from the Administration server to Runtime servers. Tivoli License Manager provides a clean-up process for USAGE table and another for the SERVICE table. 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.

Chapter 7. Performance maximization techniques

249

The cleaning process for the USAGE table runs regularly at intervals determined by the cleanUsagePeriod property in the system.properties file. The default for this property is one day. You can disable the process by changing the setting of the cleanUsageEnabled property to false. The clean-up process identifies usage transactions that are older than the number of days specified in the maxUsageAge property. 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_H table. This table includes an entry for each unique combination of license pool, date, and time. The quantity of licenses assigned values for all transactions that match on all three parameters are considered and the highest value is recorded in the USAGE_H entry. In this way, a record of high-water mark is maintained at license pool, date, and time level. This information is accessible using DB2 queries. The cleaning process for the SERVICE table runs regularly at intervals determined by the cleanServicePeriod property. The default for this property is six hours. You can disable the process by changing the setting of the cleanServiceEnabled property to false. The clean-up process identifies entries that are older than the number of days specified in the maxServiceAge property and deletes them. Example 7-2 shows the system.properties file on the Administration server. The parameters which were discussed are highlighted.
Example 7-2 Changes in the system.properties file
################################################################ # ADMIN SERVER SETTINGS # # The following settings affect the behavior of the admin server, and # # have no meaning on the Runtime server. # ################################################################ # Time interval for license usage checking (minutes) hwmScanPeriod=240 # Usage table clean-up enablement cleanUsageEnabled=true # Time interval for usage table cleanup execution (days) cleanUsagePeriod=1 # Max age for the data in the usage table: old data are cleaned (days) maxUsageAge=30 # Server wake-up enablement adminWakeUpEnabled=true # Time interval before Runtime servers are called for update (minutes) adminWakeUpPeriod=15 # Service table clean-up enablement cleanServiceEnabled=true # Time interval for service table cleanup execution (hours) cleanServicePeriod=6

250

Introducing IBM Tivoli License Manager

# Max age for the data in the service table: old data are cleaned (days) maxServiceAge=7

7.6 Operating system performance tuning


Depending on your operating system, consider making the following changes to enhance the performance of your IBM Tivoli License Manager environment. Because we have only worked with Windows and AIX environments in the ITSO lab, we do not provide performance suggestions for the other supported platforms. For additional information on performance optimizations, refer to the official operating system documentation.

7.6.1 Windows environments


If you are using a Windows NT or Windows 2000 server for the ITLM Administration server, you can significantly improve performance by optimizing your system traffic. Perform the following steps to make these changes: 1. Navigate through the path Start -> Settings -> Control Panel -> Network and Dial-up Connections -> Local Area Connection. 2. Click Properties on the Local Area Connection window, and select File and Printer Sharing for Microsoft Networks. 3. Select the option Maximize data throughput for networking applications.

7.6.2 AIX environments


To enable large file support, ensure that the Soft FILE size value is set to -1 for the IBM DB2 Universal Database Enterprise Edition administrative user. This parameter defines the largest soft file size, in 512-byte blocks, that this user can create or extend when invoking a process. Perform the following steps to make this change: From the SMIT menu, navigate through the path Security & Users -> Users -> Change/Show Characteristics of a User. Type in the name of the IBM DB2 administrative user in the entry field. Scroll down to the Soft FILE size line and change the value listed to -1.

Chapter 7. Performance maximization techniques

251

252

Introducing IBM Tivoli License Manager

Appendix A.

ITLM Agent installation using IBM Tivoli Configuration Manager


As described in Chapter 3, Implementation planning on page 51, there are several way to deploy the ITLM Agent on nodes. If a software distribution solution has already been deployed, one could easily create software packages and installation scripts to install Agents on a large scale. Here we provide an example of such a solution using IBM Tivoli Configuration Manager. We provide this information "AS IS" and it may be used as a start point for your particular environment. This appendix covers the installation of the IBM Tivoli License Manager Agent using IBM Tivoli Configuration Manager and contains the following topics: Structure and definition of the Software Package Structure of the installation script Structure of the ITLM Agent definition file The Software Package Definition file, the script, and the Agent definition file are provided as-is and as an example of a way to install the ITLM Agent using a Software Distribution strategy and can be further enhanced to fit your particular needs. Refer to Appendix D, Additional material on page 289 for instructions on how to obtain the related files.

Copyright IBM Corp. 2003. All rights reserved.

253

This appendix will not discuss how to create a IBM Tivoli Configuration Manager Software Package that uses IBM Tivoli Configuration Manager version 4.1. Information and instructions on how to create the Software Package can be found in the Users Guide for Software Distribution Version 4.2, SC23-4711.

254

Introducing IBM Tivoli License Manager

Software Package structure


The scope of this package is to install the IBM Tivoli License Manager Agent Version 1.1. The version of the Software Package presented here is only supported for the installation of the ITLM Agent for Windows NT/2000. However, a similar package can be defined for UNIX platforms as well. The installation script described in Installation script structure on page 268, can also easily be adapted to run on UNIX platforms. Figure A-1 shows the Software Package structure on the Software Package Editor tool.

Figure A-1 Software Package for ITLM Agent installation

The containers used in the above example are related to specific usages and explained as follows: Checking_Prereq This container contains the Check Disk action. It verifies if the amount of free Hard Disk space for the installation files is available. If this prerequisite is missed, the package will stop and its status will be set to IC--E. For more

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

255

information regarding the ITLM Agent prerequisites, refer to 3.4.8, Planning for IBM Tivoli License Manager Agent on page 92. Package_Files_distribution Once the requirements are fulfilled, we can distribute the image files. If a problem occurs during the files transfer, we have to stop the package and set its status to IC--E. If the complete set of image files is not on the local machine, the installation would fail in any case. Enable_Auto_logon The Windows Agent installation process needs to be authenticated with credentials of either a local or a domain user with Administration rights to the target machine where the ITLM agent is about to be installed. The Software Package must first log on with a pre-defined maintenance user using the Windows Autologon process. If the Autologon activation process fails, we have to stop the package process and set its status to IC--E. Otherwise, the Software Package wont have the proper users rights to proceed with the installation process. Agent_Installation As soon as Auto-logon process succeeds, the installation process can be initialized. However, even if an error occurs during the installation, we would not be able to set the package on failure because we have to turn off the Autologon process. Nevertheless, the installation status is checked at the end of the Software Package process and if the Agent is not correctly installed, its status will be set to IC--E. Before_Installation In this section, we specify the directory for the log files to be used for both the package and the installation script. This needs to be done at this time because the Software Distribution process would not create it. Agent_Setup In this section, we start the installation script which will be explained in the next section. The script is coded using the Perl language. Despite the fact that the Tivoli Endpoint should be capable to start Perl scripts, we have included a Perl version in the package to be sure that the script will be executed. Disable_Auto_Logon Once the installation finished, we have to turn off the Auto-logon process. Remove_Installation_Files We remove the set of installation files to avoid the Hard Disk space usage for useless files.

256

Introducing IBM Tivoli License Manager

Control_Agent_Installation Because it is not possible to set the package in an error state during the installation process, due to the Auto-logon process, we need to verify if the ITLM Agent has been properly installed. One method is to check the Windows Registry information. If the ITLM Agent PATH variable is correctly set, we assume that the installation was successful. Otherwise, we write an informational message in the log file and set the state of the package to IC--E.

Software Package variables


In this package, we take the advantage of the variables facilities offered by IBM Tivoli Configuration Manager. Figure A-2 shows the Software Package variables we defined.

Figure A-2 Software Package variables definition

The variables used in the above example are related to specific usages and explained as follows: The name of the package This is especially useful for troubleshooting purposes.
sp_name = "ITLMAgent.1.1"

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

257

The path of installation files set This variable will be used by other variables that need to refer to a file or a directory within the installation package.
agent_image_path = "c:\temp\itlm_agent_v1r1"

Scripts variables These are variables to be passed on to the installation script. Instead of hard coding them in the Exectue_Program action, we decided to set variables. This offers a more flexible way to adapt the Software Package to any environment.
agent_source_path = "$(agent_image_path)\win32" agent_def_file = "$(agent_image_path)\cust\itlm_agent.def" agent_inst_file = "$(agent_image_path)\win32\installagent.exe" target_log_file = "c:\temp\ITCM_install_logs\zinst_itlm_agent.log"

Registry key To be able to test the viability of the installation, we need to get information from the Windows Registry. This variable refers to the information that the ITLM installation process saves in the Registry for the ITLM Agent.
registry_key_agent="$(REG:HKEY_LOCAL_MACHINE\SOFTWARE\IBM\TLMAgent\AgentPath)"

Flag variables Each container is subject to different condition. For troubleshooting purposes, we set the possibility to execute a container or not. Otherwise, you should delete the container in case you dont want it to be executed. If the value of a flag is different than 0, the Software Package process will not execute the actions defined in that particular container.
flag_checking_prereq = "0" flag_before_installation = "0" flag_enable_auto_login = "0" flag_agent_setup = "0" flag_remove_installation_files = "0" flag_control_agent_installation = "0" flag_disable_auto_logon = "0" flag_package_files_distribution = "0" flag_agent_installation = "0"

Software Package version


Versionning is a method of managing and tracking software levels, which can apply to any software, data or operating systems. It allows updates to base software levels or packages and ensures that an incorrect level is not deployed. This versionning technique can be used to establish and ensure the correct Software Package level for all Tivoli Administrators.

258

Introducing IBM Tivoli License Manager

The file name of the Software Package contains the level and the release, if it exists, of the Software and the level and the release of the Software Package levels in the following format:
<Package Name>_v<Software version>r<Software release>_p<Software Package version>r<Software Package release>

Here are examples of names of the ITLM Agent installation packages:


ITLM_Agent_v1r1_p1r1.sp ITLM_Agent_v1r1_p1r1.spd ITLM_Agent_v1r1_p1r1.spb

Software Package definition


Hereafter, you will find the complete definition of the Software Package for the installation of the ITLM Agent:
Example: A-1 Software Package definition for ITLM Agent installation
"TIVOLI Software Package v4.1 - SPDF" package name = "ITLM_Agent" title = "ITLM Agent 1.1 installation" description = "The scope of this package is to install the the IBM Tivoli Licence Manager Agent.

version 1.1 of

The installation is made in a Maintenance Mode using a specific user dedicated only for installation and maintenance machine mode. Version 1.0 - 11.25.2002 - ITSO Lab The information that the Agents needs for its Runtime connection is in a Definition file which should be maintained on a regularly basis. " version = "1.1" copyright = "(C) COPYRIGHT IBM Corporation All Rights Reserved Licences Material - Property of IBM Corporation" web_view_mode = "hidden" undoable = "n" committable = "o" history_reset = n save_default_variables = n creation_time = "2002-11-26 16:53:39" last_modification_time = "2002-11-26 16:54:03" default_variables flag_checking_prereq = "0"

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

259

flag_before_installation = "0" sp_name = "ITLMAgent.1.1" flag_enable_auto_login = "0" registry_key_agent = "$(REG:HKEY_LOCAL_MACHINE\SOFTWARE\IBM\TLMAgent\Agent path)" target_log_file = "c:\temp\ITCM_install_logs\zinst_itlm_agent.log" agent_def_file = "$(agent_image_path)\cust\itlm_agent.def" flag_agent_setup = "0" agent_image_path = "c:\temp\itlm_agent_v1r1" flag_remove_installation_files = "0" agent_inst_file = "$(agent_image_path)\win32\installagent.exe" flag_control_agent_installation = "0" agent_source_path = "$(agent_image_path)\win32" flag_disable_auto_logon = "0" flag_package_files_distribution = "0" flag_agent_installation = "0" end

log_object_list location = "c:\temp\ITCM_Install_logs" unix_user_id = 0 unix_group_id = 0 unix_attributes = "rwx,rx," end move_removing_host = y no_check_source_host = y lenient_distribution = n default_operation = "install" server_mode = "all|force|force" operation_mode = "not_transactional" log_path = "D:\Tivoli\TivoliCustom\logs\SWD\itlm_agent_v1r1.log" log_mode = "0" log_user_id = 0 post_notice = n before_as_uid = 0 skip_non_zero = n after_as_uid = 0 no_chk_on_rm = n log_gid = 0 log_host_name = "tlm01" versioning_type = "swd" package_type = "refresh" stop_on_failure = y generic_container stop_on_failure = y name = "Checking_Prereq"

260

Introducing IBM Tivoli License Manager

condition = "$(flag_checking_prereq) check_disk_space volume = c:\,20M end end

== 0"

generic_container stop_on_failure = y name = "Package_Files_distribution" condition = "$(flag_package_files_distribution) add directory stop_on_failure = n location = "E:\products\ITLM\Agent" name = "win32" destination = "$(agent_image_path)\win32" add = y descend_dirs = y remove_extraneous = n substitute_variables = n remove_empty_dirs = y unix_owner = "root" unix_user_id = 0 unix_group_id = 0 create_dirs = y remote = n compute_crc = n verify_crc = n compression_method = "stored" delta_compressable = d rename_if_locked = y replace_if_existing = y replace_if_newer = y remove_if_modified = n is_shared = n end

== 0"

add directory stop_on_failure = n location = "E:\products\ITLM\Agent" name = "cust" destination = "$(agent_image_path)\cust" add = y descend_dirs = y remove_extraneous = n

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

261

substitute_variables = n remove_empty_dirs = y unix_owner = "root" unix_user_id = 0 unix_group_id = 0 create_dirs = y remote = n compute_crc = n verify_crc = n compression_method = "stored" delta_compressable = d rename_if_locked = y replace_if_existing = y replace_if_newer = y remove_if_modified = n is_shared = n end end

generic_container stop_on_failure = y name = "Enable_Auto_Logon" condition = "$(flag_enable_auto_login)

== 0"

add win_registry_key parent_key = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" key = "Winlogon" add = n override_permissions = y stop_on_failure = y name = "Winlogon" replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DefaultUserName" type = "string" position = "replace" data = "<Administrator User>" end

262

Introducing IBM Tivoli License Manager

value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DefaultPassword" type = "string" position = "replace" data = "<Administrator User Password>" end

value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "AutoAdminLogon" type = "string" position = "end" data = "1" end

value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DontDisplayLastUserName" type = "string" position = "replace" data = "0" end end

restart during_install = "immediately" during_remove = "after" during_undo = "after" end end

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

263

generic_container stop_on_failure = n name = "Agent_Installation" condition = "$(flag_agent_installation) == 0" generic_container stop_on_failure = n name = "Before_Installation" condition = "$(flag_before_installation)

== 0"

execute_user_program name = "Create the log dir on the machine" transactional = n during_install exit_codes success = 0,0 warning = 1,65535 end path = "$(system_dir)\cmd.exe" arguments = '/c "md $(target_log_dir)"' timeout = 60 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = n reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = n retry = 1 end end end

generic_container stop_on_failure = n name = "Agent_Setup" condition = "$(flag_agent_setup)

== 0"

execute_user_program name = "Installation of ITLM Agent 1.1"

264

Introducing IBM Tivoli License Manager

transactional = n during_install exit_codes success = 0,0 warning = 1,65535 end path = "$(agent_image_path)\cust\perl.exe" arguments = '$(agent_image_path)\cust\zinst_itlm_agent.pl "$(hostname)" "$(agent_def_file)" "$(agent_inst_file)" "$(agent_source_path)" "$(target_log_file)"' timeout = 360 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = y reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = n retry = 1 end end end end

generic_container stop_on_failure = n name = "Disable_Auto_Logon" condition = "$(flag_disable_auto_logon)

== 0"

add win_registry_key parent_key = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" key = "Winlogon" add = n override_permissions = y stop_on_failure = y name = "Winlogon" replace_if_existing = y replace_if_newer = n

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

265

remove_if_modified = n is_shared = n value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DefaultPassword" type = "string" position = "replace" data = "none" end

value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "AutoAdminLogon" type = "string" position = "replace" data = "0" end

value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DontDisplayLastUserName" type = "string" position = "replace" data = "1" end end

restart during_install = "immediately" during_remove = "after" during_undo = "after" end end

266

Introducing IBM Tivoli License Manager

generic_container stop_on_failure = n name = "Remove_Installation_Files" condition = "$(flag_remove_installation_files)

== 0"

execute_user_program name = "Remove read-only attrib on temp installation files" transactional = n during_install exit_codes success = 0,0 warning = 1,65535 end path = "$(system_dir)\attrib.exe" arguments = '-r "$(agent_image_path)\*.*" /S' timeout = 60 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = n reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = n retry = 1 end end

remove directory location = "$(agent_image_path)" name = "$(agent_image_path)" destination = "$(agent_image_path)" remove = y descend_dirs = y remove_empty_dirs = y rename_if_locked = n stop_on_failure = n end end

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

267

generic_container stop_on_failure = y name = "Control_Agent_Installation" condition = "$(flag_control_agent_installation) (NOT ($(registry_key_agent) LIKE '*itlm'))"

== 0 AND

execute_user_program name = "Force the package failure and show information message" transactional = n during_install exit_codes failure = 0,65535 end path = "$(system_dir)\cmd.exe" arguments = '/c "echo During the control phase, it seems that the ITLM Agent is not right installed."' timeout = 60 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = y reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = n retry = 1 end end end end

Installation script structure


The standard ITLM Agent installer needs a large amount of information about each node. To ease the deployment of large numbers of nodes, we decided to centralize the information for each Agent in a common definition file, which will be maintained in a central location and distributed to each Agent along with the

268

Introducing IBM Tivoli License Manager

installation files set. However, to extract the information corresponding to the Agent on which the package installation has taken place, we have to read the information provided in the definition file. The installation script is in charge of getting this information from the definition file and starting the standard ITLM Agent installer with the correct arguments for that particular Agent on which the installation is about to begin. The pseudo-code structure for the script is: Test the number of input argument Open the debug log file Open the definition file Read the definition, take out comment lines and save the rest in a table Close the definition file Find the line corresponding to the current Agent Check if Proxy will be used and set correct default value if not Start the standard ITLM Agent installer with specific Agent arguments Check the return code of the standard installation Close the debug log file Hereafter, you will find the complete definition of the installation script for the installation of the ITLM Agent:
Example: A-2 Installation script for ITML Agent
#!/usr/bin/perl # # Product: zinst_itlm_agent.pl # # Description: this script install the ITLM Agent using information stored # in a definition file # # Parameter: # # First: Host name of the machine where the Agent will be installed # Second: Definition file name # Third: Official installation file # Forth: Path of the source dir # Fifth: log file # # Output : 0 = no error during the complete process # 1 = some errors during the complete process # # Author : ITLM Redbook Team

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

269

# # Date : 11.25.2002 # # Revision : 1.0 # # History : # # (C) COPYRIGHT IBM Corporation # All Rights Reserved # Licensed Material - Property of IBM Corporation # ################################################ # CONFIGURATION PARAMETERS ################################################ $SCRIPT_NAME="zinst_itlm_agent"; $NO_PROXY="no"; $NO_PROXY_NAME="none"; $NO_PROXY_PORT="0"; $RUNTIME_URL="/slmruntime/service"; $AGENT_INST_TRACE="y"; #Enable or disable tracing $DEBUG=1; ################################################ # Main ################################################ if ($#ARGV != 4) { print "Error - Usage: $0 <Machine Host name> <Agent Definition file> <Official installation file> <Source path> <Log file>\n"; exit 1; } ($agent_name,$agent_def_file,$agent_inst_file,$agent_source_path,$debug_file) = @ARGV; #We open the Log file if debug is turned on. open(DBG,">> $debug_file") if ($DEBUG); #Extracting date and time and set the format for month and year ($sec,$min,$hour,$day,$month,$year,$wday,$yday,$isdst)=localtime(time); $month++; $year+=1900; print DBG "***Start $SCRIPT_NAME at $month/$day/$year - $hour:$min***\n" if ($DEBUG);

270

Introducing IBM Tivoli License Manager

#We open the Agent list file definition if (open(openAgentDefFile,$agent_def_file) == 0) { print DBG "The $agent_def_file File can't be opened.\n" if ($DEBUG); print DBG "***End $SCRIPT_NAME***\n" if ($DEBUG); close(DBG); exit 1; } #We put the content of the file in a table to search the data and take out comment lines #@tmpFile=<openAgentDefFile>; @tmpFile=grep(!/^#/,<openAgentDefFile>); #As the information is saved in the table, the file could be closed close(openAgentDefFile); #We get the parameter line corresponding to the machine where we install the Agent #In this case, we assume that the Agent is unique in the file. if there is more than one, we take the first one. #The i after the closing / is to ignore the Case. @AgentLine=grep(/^$agent_name/i, @tmpFile); #We take out the last carriage (in Perl v5. better to use chomp) chop ($AgentLine[0]); #We put each Agent parameter in a list @AgentAttrib =split(/;/, $AgentLine[0]); #We need to control if the Agent should use a Proxy or not, otherwise we should provide the right default value if ($AgentAttrib[6] eq $NO_PROXY ) { $PROXY_NAME=$NO_PROXY_NAME; $PROXY_PORT=$NO_PROXY_PORT; } else { $PROXY_NAME=$AgentAttrib[7]; $PROXY_PORT=$AgentAttrib[8]; } #For debugging purpose, we save the executed line print DBG "$agent_inst_file \"$agent_source_path\" \"$AgentAttrib[1]\" \"$AgentAttrib[2]\" \"$AgentAttrib[3]\" \"$AgentAttrib[4]\" \"$RUNTIME_URL\" \"$AgentAttrib[5]\" \"$AgentAttrib[6]\" \"$PROXY_NAME\" \"$PROXY_PORT\" \"$AGENT_INST_TRACE\"\n";

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

271

#We prepare the complete list of the parameters that are necessary for the official agent installation procedure @args = ($agent_inst_file, "$agent_source_path", "$AgentAttrib[1]", "$AgentAttrib[2]", "$AgentAttrib[3]", "$AgentAttrib[4]", "$RUNTIME_URL", "$AgentAttrib[5]", "$AgentAttrib[6]", "$PROXY_NAME", "$PROXY_PORT", "$AGENT_INST_TRACE"); #We execute the official agent installation process $RC=system(@args); #Of course, we need to know if the intsallation is right made or not. if ( $RC != 0 ) { print DBG "There was an error (RC=$RC) during the execution of the official Agent installation script.\n" if ($DEBUG); print DBG "***End $SCRIPT_NAME***\n" if ($DEBUG); close(DBG); exit $RC; } else { print DBG "No error during the execution of the official Agent installation script.\n" if ($DEBUG); } print DBG "***End $SCRIPT_NAME***\n" if ($DEBUG); close(DBG); exit 0;

Agents definition file structure


As already mentioned above, the standard ITLM Agent installer must know node-specific attributes in order for the installation to proceed. A node definition file has been created and contains specific information for all Agents within your infrastructure. This file contains the following information per record: The fully qualified host name of the Agent The Division ID (not the Division Name) The Agent Tag (or Computer Label) which you have defined during the Logical Design phase The fully qualified host name of the Runtime server The TCP port defined for the Runtime server (default is 80) The Customer name

272

Introducing IBM Tivoli License Manager

The Proxy usage. If you dont plan to use a Proxy server, you dont need to specify the next two fields The fully qualified host name of the Proxy server if you plan to use one (optional) The TCP port of the Proxy server if you plan to use one (optional) The file could be generated from a Workbook tool like Microsoft Excel or from an Asset Management tool already deployed in your environment. Hereafter, you will find an example of the Agent definition file for the installation of the ITLM Agent:
Example: A-3 Definition file for the ITLM Agent installation
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # Product : itlm_agent.def Description : This file contains the definition of the ITLM agents in order to provide the right parameters for the installation process. For more information regarding each parameters, please refer to the IBM Tivoli Licence Manager System Administrator's Guide, GC23-4834-00 Line syntax: First field: Name of machine where the Agent will be installed fully qualified host name) Second field: Division ID Third fields: Tag of the node Forth field: Runtime server host name Fifth field: Runtime server port (default is 80) Sixth field: Customer name Seventh field: Proxy usage (only yes or no. If no, the next field are optionals) Eighth field: Proxy name Ninth field: Proxy port All fields must be separated by a ";" !! The last line must be a blank line !! The # is used to comment a line Author : ITLM Redbook team Date : 11.25.2002 Revision : 1.0

Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager

273

# History : # # (C) COPYRIGHT IBM Corporation # All Rights Reserved # Licensed Material - Property of IBM Corporation # tlm13.itsc.austin.ibm.com;3;TAG_TLM13;9.3.4.248;80;IBM Corporation;no tlm14.itsc.austin.ibm.com;3;TAG_TLM14;9.3.4.248;80;IBM Corporation;yes;tlm04;334

274

Introducing IBM Tivoli License Manager

Appendix B.

SSL key creation for IBM Tivoli License Manager


This appendix provides the procedures to create an SSL key to be used for communication between the ITLM Administration and Runtime servers.

Copyright IBM Corp. 2003. All rights reserved.

275

Overview
As described in Chapter 2, IBM Tivoli License Manager general overview on page 11 the following communications may be secured over an SSL link: Between the ITLM Administration and Runtime servers Between the ITLM Administration server and Web browsers on the ITLM administrators desktops Between the ITLM Runtime server and Web browsers on the ITLM administrators accessing reports For these communications to be established, an SSL key needs to be used. This key may contain an official certificate issued by an official Certificate Authority or contain your own self-signed certificate. The following sections explain how to create a self-signed certificate to be used in a IBM Tivoli License Manager deployment. For information on how to configure your IBM Tivoli License Manager environment to be SSL enabled, refer to Chapter 4, Getting IBM Tivoli License Manager up and running on page 99.

Creating the SSL key files


The first step is to create the SSL key database files and site certificates. These files will contain the newly created certificate. Perform the following steps: 1. Create a temporary directory on the ITLM Administration server to hold the SSL files. This directory will be referred herein as tmpkeydir. 2. Start the IBM Key Management utility gsk5ikm. Our ITLM Administrator server is installed on a AIX machine, so the gsk5ikm command is located in the /usr/opt/ibm/gskkm/bin directory. On AIX, issue the following commands:
# export JAVA_HOME=<java_rte_dir> # /usr/opt/ibm/gskkm/bin/gsk5imk

Where, <java_rte_dir> is the directory where Java runtime is installed, for example /usr/java130/jre. 3. On the gsk5ikm IBM Key Management utility main menu, select Key Database File->New. 4. On the New Key dialog box, choose CMS Key database file as the key database type and fill out with the name of the key file: /tmpkeydir/key.kdb. 5. Click OK.

276

Introducing IBM Tivoli License Manager

6. In the Password Prompt dialog box enter the password that will be used to encrypt and decrypt the key database files. Also, select Stash the password to a file option. 7. On the Create New Self-Signed Certificate window, fill out at least the following fields: Key Label Common Name Organization The label to identify the key and the certificate, for example, ITLMKEY. The fully qualified hostname of your ITLM Administration Server. In our example, tlm04. Your organization name. For example, IBM Corporation.

8. On the gsk5ikm IBM Key Management utility main menu, select Key Database File->Close. 9. Confirm the SSL files creation as shown in Example B-1.
Example: B-1 SSL key files
# cd /tmpkeydir # ls -lt total 200 -rwxrwxrwx 1 root -rwxrwxrwx 1 root -rwxrwxrwx 1 root -rwxrwxrwx 1 root #

system system system system

5080 70080 129 80

Dec Dec Dec Dec

03 02 02 02

08:51 18:44 18:39 18:39

key.rdb key.kdb key.sth key.crl

Creating the server certificate file


The second step is to extract the self-signed certificate to a temporary certificate holder file. Perform the following steps: 1. Start the IBM Key Management utility gsk5ikm on the ITLM Administration server. 2. On the gsk5ikm IBM Key Management utility main menu, select Key Database File->Open. 3. Select the key.kdb file located at the tmpkeydir directory. 4. Enter the password that has been used during the creating of the key.kdb file. 5. On the Key Database Content window, select the correspondent Key Label. In our example, ITLMKEY. 6. Select Extract Certificate.

Appendix B. SSL key creation for IBM Tivoli License Manager

277

7. On the Extract Certificate to a file window, make sure you select Data Type equals to Base64-encode ASCII data, the certificate file name (*.arm) and directory location. For example, itlmcert.arm stored at tmpkeydir. 8. Choose Save. 9. On the gsk5ikm IBM Key Management utility main menu, select Key Database File->Close. 10.The content of the server certificate file will be similar to Example B-2.
Example: B-2 Server certificate file
# cd /tmpkeydir # cat itlmcert.arm -----BEGIN CERTIFICATE----MIIBzTCCATagAwIBAgIEPev+bjANBgkqhkiG9w0BAQQFADArMQswCQYDVQQGEwJV UzEMMAoGA1UEChMDSUJNMQ4wDAYDVQQDEwV0bG0wNDAeFw0wMjEyMDIwMDQ0MzBa Fw0wMzEyMDMwMDQ0MzBaMCsxCzAJBgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0xDjAM BgNVBAMTBXRsbTA0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDG1OareK0q 3QHvkL46cieICTRS979lClS8JzpXwrhDx5RdPenzwyGRELx64mWuDNh4NIUtqklL RcRLvSF2KHheC0j/V1m61jGVz3cIWU8qSe1rxEmzPxuwpGSsbL6KUXV/sVWu5OPJ mTqH4nceTuSzc3ZZqnR7o0cVvt89CI8EJwIDAQABMA0GCSqGSIb3DQEBBAUAA4GB AAATQH6LvzNiMjr4mydKq/haD2wflgN3otvL2UtU9gaXd881dpTu3uacYkESzIxP W+g+fd01Py+qWWpGjLXsVGycAKvOSLVEIuSyooSQB2GUZtqt3E6Vrlm81tQDhtup tNbfgRy3VqsfRFLGwnWIPejzHp/tZhi4LfbJtNpHe1aB -----END CERTIFICATE----#

Creating the key trusted store file


The last step is to create the key trusted store file using the server certificate file information. Perform the following steps: 1. On the ITLM Administrator server, start the IBM Key Management utility ikeyman. Our ITLM Administrator server is installed on a AIX machine, so this is performed by the ikeyman.sh command, which is located at the /usr/WebSphere/AppServer/bin directory. On AIX, issue the following commands:
# export JAVA_HOME=<java_rte_dir> # /usr/WebSphere/Appserver/bin/ikeyman.sh

Where, <java_rte_dir> is the directory where Java runtime is installed, for example, /usr/java130/jre. 2. On the ikeyman IBM Key Management utility main menu, select Key Database File->New.

278

Introducing IBM Tivoli License Manager

3. On the New Key dialog box, choose JKS as the key database type and fill out with the name and location of the key file: key.jks and the tmpkeydir directory. 4. Click OK. 5. In the Password Prompt dialog box enter the password that will be used to encrypt and decrypt the key database file. We recommend that you do not set the expiration time. 6. The Key Database Content area may show several certifications already defined. Click Add to import your own self-signed certificate. Fill in the self-signed certificate file name (*.arm) and location. In our example, the self-signed certificate file name is itlmcert.arm and is stored at tmpkeydir. 7. Enter the label for the self-signed certificate. It should be the same one used during the key database files definition. For example, ITLMKEY. 8. Save the key.jks file by selecting Key Database File->Save.

Appendix B. SSL key creation for IBM Tivoli License Manager

279

280

Introducing IBM Tivoli License Manager

Appendix C.

IBM Tivoli License Manager databases


This appendix contains a reference to the databases created during the installation of IBM Tivoli License Manager Version 1.1, as follows: ITLM Administration Server database: TLMA ITLM Runtime Server database: TLMR The information provided by this appendix is particularly useful when you are interested in creating license management reports.

Copyright IBM Corp. 2003. All rights reserved.

281

The ITLM Administration server database


As explained in Chapter 4, Getting IBM Tivoli License Manager up and running on page 99, the ITLM Administration server database is created using the <ITLMinstdir>/dbsetup.sh script, where <ITLMinstdir> is the location of the ITLM Administration server installation. This script defines and creates a database called TLMA defined under the ADM schema. Table C-1 provides a description of the TLMA database tables for the ADM schema.
Table C-1 TLMA database tables for the ADM schema

Table name
ADMIN_CUST_REL ADMINISTRATOR

Description
Maps ITLM Administrators to Customers Keeps information about the ITLM Administration and Runtime Servers Administrators Stores information on installed ITLM Agents Stores historical information on the relationship between ITLM Agents and Divisions Keeps ITLM Agents events Maintains a history of changes to ITLM Agents Stores information on the products installed on the ITLM Agents Software product categories Keeps the commands issued to ITLM Agents and ITLM Administration and Runtime Servers Maintains software products and its executable modules relation. Stores software products information Keeps configuration data Country (or region) information Keeps information about ITLM Customers, such as Customer name, account ID, and an unique Customer identifier

AGENT AGENT_DIV_HREL

AGENT_EVENT AGENT_H AGENT_INV CATEGORY COMMAND

COMP_MOD_REL COMPONENT CONTROL COUNTRY CUSTOMER

282

Introducing IBM Tivoli License Manager

Table name
DIVISION DIVISION_H ENDUSER

Description
Represents the ITLM Customer logical organization Keeps historical information of changes to Divisions Keeps information about the ITLM users, such as user ID, name, email address, employee number, etc. Maintains information about software entitlement per ITLM Customer Keeps historical information about the availability of licenses to Divisions, Nodes, or ITLM Agents. Represents the License enrollments of a Division, Nodes, or ITLM Agents Keeps historical information about the availability of licenses to Users Maintains the relationship between licenses and users Stores information about licenses defined in ITLM Represents licenses available to the ITLM Runtime Servers Historical information about licenses, such as volume of licenses in the pool, usage thresholds, etc. Keeps information about the modules used by the applications in order to be identified by the ITLM Agents Stores information about the machines where the ITLM Agent is installed Internal control table Keeps the profiles of the ITLM Administrators Keeps actions not allowed for the ITLM Administrator profile

ENTITLEMENT LIC_TARGET_H

LIC_TARGET_REL LIC_USER_HREL LIC_USER_REL LICENSE LICENSE_DISTRIBUTION LICENSE_H

MODULE

NODE OID PROFILE PROFILE_ACTION

Appendix C. IBM Tivoli License Manager databases

283

Table name
SERVER SERVER_H SERVICE UNKNOWN

Description
Maintains information about the ITLM Runtime Servers Historical information about changes to the ITLM Runtime Servers Historical information about services requested to the ITLM Servers Keeps information on the executable files running on the ITLM Agents that have not been yet recognized Maintains information about license usage on ITLM Agents Keeps historical information about license usage on ITLM Agents Summary snapshots of the USAGE_H Table Keeps information about the software vendors

USAGE USAGE_H USAGE_H_TIME VENDOR

284

Introducing IBM Tivoli License Manager

Figure C-1 ITLM Administration server database schema

Appendix C. IBM Tivoli License Manager databases

285

The ITLM Runtime server database


As explained in Chapter 4, Getting IBM Tivoli License Manager up and running on page 99, the ITLM Runtime server database is created using the <ITLMinstdir>/dbsetup.sh script, where <ITLMinstdir> is the location of the ITLM Runtime server installation. This script defines and creates a database called TLMR defined under the RTM schema. Table C-2 provides a description of the TLMR database tables for the RTM schema.
Table C-2 TLMR database tables for the RTM schema

Table name
ADMINISTRATOR

Description
Keeps information about the ITLM Administration and Runtime Servers Administrators Stores information on installed ITLM Agents Keeps the relationship information between ITLM Agents and the products installed on them Keeps the relationship information between ITLM Agents and the products installed on them that are not yet being controlled by the ITLM Agent Keeps the commands issued to ITLM Agents and ITLM Runtime Servers Maintains software products and its executable modules relation. Stores software products information Keeps configuration data Represents the ITLM Customer logical organization Keeps information about the ITLM users, such as user ID, name, email address, employee number, etc. Represents the License enrollments of a Division, Nodes, or ITLM Agents Maintains the relationship between licenses and users

AGENT AGENT_COMP_REL

AGENT_UNK_REL

COMMAND COMP_MOD_REL COMPONENT CONTROL DIVISION ENDUSER

LIC_TARGET_REL LIC_USER_REL

286

Introducing IBM Tivoli License Manager

Table name
LICENSE MODULE

Description
Stores information about licenses defined in ITLM Keeps information about the modules used by the applications in order to be identified by the ITLM Agents Stores information about the machines where the ITLM Agent is installed Keeps the profiles of the ITLM Administrators Keeps actions not allowed for the ITLM Administrator profile Maintains information about the ITLM Runtime Servers Keeps the relationship information between ITLM Runtime Servers and Divisions Keeps information on the executable files running on the ITLM Agents that have not been yet recognized Keeps information about the software vendors

NODE PROFILE PROFILE_ACTION SERVER SERV_DIV_REL

UNKNOWN

VENDOR

Appendix C. IBM Tivoli License Manager databases

287

Figure C-2 ITLM Runtime server database schema

288

Introducing IBM Tivoli License Manager

Appendix D.

Additional material
This redbook refers to additional material that can be downloaded from the Internet as described below.

Locating the Web material


The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246888

Alternatively, you can go to the IBM Redbooks Web site at:


ibm.com/redbooks

Select the Additional materials and open the directory that corresponds with the redbook form number, SG246888.

Using the Web material


The additional Web material that accompanies this redbook includes the following files:

File name SG246888.zip

Description ITLM Agent installation Software Package Definitions

Copyright IBM Corp. 2003. All rights reserved.

289

System requirements for downloading the Web material


The following system configuration is recommended: Hard disk space: Operating System: Processor: Memory: 1 MB minimum Windows or UNIX Any Any

How to use the Web material


Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder.

290

Introducing IBM Tivoli License Manager

Abbreviations and acronyms


ACL API ARM CMU CORBA CORP DB2 DM DMZ DNS EP ETL FTP GUI GW HTML HTTP HTTPS IBM ICMP IETF INV IOM IPLA IPX
Access Control List Application Programming Interface Application Response Measurement Customer Managed Use Common Object Request Broker Architecture Corporate Network IBM DB2 Universal Database Enterprise Edition Distributed Monitoring Demilitarized Zone Domain Name Server Endpoint Extract, Transform and Load File Transfer Protocol Graphical User Interface Gateway Hypertext Markup Language Hypertext Transfer Protocol HTTP runnning under the SSL International Business Machines Corporation Internet Control Message Protocol Internet Engineering Task Force Inventory Inter Object Messaging IBM Program License Agreement Internetwork Packet Exchange

ISO ISP ITCM ITLM ITSO JDBC JDK JVM LAN MN NAT NFS ODBC OLAP RDBMS RFC RPC SNMP SSL SWD TCP/IP TDW TMA TME TMF TMR

International Organization for Standardization Internet Service Provider IBM Tivoli Configuration Manager IBM Tivoli License Manager International Technical Support Organization Java Database Connectivity Java Development Kit Java Virtual Machine Local Area Network Managed Node Network Address Translation Network File System Open Database Connectivity Online Analytical Processing Relational Database Management System Request for Comments Remote Procedure Call Simple Network Management Protocol Secure Sockets Layer Software Distribution Transmission Control Protocol/Internet Protocol Tivoli Data Warehouse Tivoli Management Agent Tivoli Management Environment Tivoli Management Framework Tivoli Management Region

Copyright IBM Corp. 2003. All rights reserved.

291

UDP URL VMU VPN WAN WAN WAS WLC XML XSLM

User Datagram Protocol Universal Resource Locator Vendor Managed Use Virtual Private Network Wide Area Network Wide Area network IBM WebSphere Application Server Workload License Charges eXtensible Markup Language X-Open Software License use Management

292

Introducing IBM Tivoli License Manager

Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.

IBM Redbooks
For information on ordering these publications, see How to get IBM Redbooks on page 295.

Introduction to Tivoli Enterprise Data Warehouse, SG24-6607

Other publications
These publications are also relevant as further information sources:

Installing and Configuring Tivoli Enterprise Data Warehouse, GC32-0744 Tivoli Enterprise Data Warehouse Release Notes, GI11-0857 IBM Tivoli License Manager License Administrators Guide, GC23-4833 IBM Tivoli License Manager Warehouse Enablement Pack Implementation Guide (this book is available within the products installation CD-ROMs) IBM Tivoli License Manager Data Dictionary, GC23-4835 IBM Tivoli License Manager Systems Administrators Guide, GC23-4834 IBM Tivoli Configuration Manager Users Guide for Software Distribution Version 4.2, SC23-4711

Online resources
These Web sites are also relevant as further information sources: IBM Tivoli License Manager
http://www-3.ibm.com/software/sysmgmt/products/support/IBMTivoliLicenseMana ger.html

Tivoli Enterprise Data Warehouse


http://www.ibm.com/software/sysmgmt/products/support/TivoliEnterpriseDataWa rehouse.html

Copyright IBM Corp. 2003. All rights reserved.

293

Java Tutorial provided by Sun Microsystems


http://java.sun.com/docs/books/tutorial/jdbc

World Wide Web Consortium


http://www.w3.org

Microsoft Web site on licensing


http://www.microsoft.com/licensing

Oracle Web site on licensing


http://www.oracle.com/corporate/pricing

IBM Web site on licensing


http://www-3.ibm.com/software/passportadvantage

IBM DB2 Universal Database Enterprise Edition support Web site


http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/downloa d.d2

IBM WebSphere Application Server InfoCenter


http://www-3.ibm.com/software/webservers/appserv/infocenter.html

Microsoft Support Web site


http://support.microsoft.com/default.aspx?scid=kb

Object management group Web site


http://www.omg.org

DB2 magazine Web site


http://www.db2mag.com/db_area/archives/2001/q1/hayes.shtml

Index of /html/Something_about_XSLM/About_XSLM
http://www.xslm.org/html/Something_about_XSLM/About_XSLM/Original_Requireme nts

IBM HTTP Server


http://www-3.ibm.com/software/webservers/httpservers

HTTP Server Plug-in


http://www7.software.ibm.com/vadd-bin/ftpdl?1/vadc/wsdd/pdf/presents/WS40ST 08.pdf

Microsoft Knowledge Base Article - 149605


http://support.microsoft.com/default.aspx?scid=kb;en-us;149605

WebSphere Application Server Version 4.0 FixPak4 (Version 4.0.4)


http://www-1.ibm.com/support/docview.wss?uid=swg24001635

294

Introducing IBM Tivoli License Manager

DB2 Technical Support


http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7pubs .d2w/en_main http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7fphi st.d2w/report

How to get IBM Redbooks


You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site:
ibm.com/redbooks

Related publications

295

296

Introducing IBM Tivoli License Manager

Index
Numerics
1.1-TDW-0002 218 1.1-TDW-0005E 218 1.1-TDW-FP01a 218 1.1-TDW-FP02 218

C
capacity type 36, 171, 194 capacity-on-demand 10 catalog import 181 Catalog Manager 69 catalog.dat 177 catman 177 CDW 214 central data warehouse, see CDW Checking_Prereq 255 clean pages 240 COD 215 Cognos 212 Common Warehouse Metadata, see CWM 212 communications letter 162 compliance 8 Connector Architecture 86 containers 255 contracts negotiation 31 contractual license agreement 147 Control_Agent_Installation 257 CORBA 84 correlation 211 Creation Mode 173 Crystal Decisions 212 Customer 27, 61, 150 Customer Managed Use 8 customer-perceived value 10 CWM 212 CWM standard 212

A
access control 62 ADM schema 282 Administration server 24 Administration server installation 102 administrative burden 3 Administrator 26 Agent deploying 160 Agent install software package 255 Agent trace file 96 Agent_Installation 256 Agents 23, 26 AIX 5L 73 Application Server JDK 86 Asset Management 5, 30, 61 Asset Protection 5 AutoCad 167

B
backup and restore 66 Base64-encode ASCII data 278 baseline data 146 best practices 57 BI 212 bootstrap 83 bottle neck 59 Brio Technology 212 budget planning 31 buffer pool 239 Business Intelligence reporting 214 Business Intelligence, see BI 212 Business Objects 212

D
data mart 214 data mining 214 data warehouse 214 database heap 241 db.properties 89, 91 DB2 Fixes 71 DB2 hardware requirements 71 DB2 installation 102 DB2 instance 103 DB2 performance 239 DB2 schema 113

Copyright IBM Corp. 2003. All rights reserved.

297

DB2 TCP/IP ports 74 db2java.zip 86, 107 DB2SmartGuide 246 DB2SYSTEM 104 dbsetup.bat 141 dbUser 89, 91 de-militarized zone 58 design process 147 dirty pages 239 disaster and recovery 66 disruption 56 Divisions 23, 27, 61, 149 creating 159 DMZ 58 DYK_DM 244

graphical representation 192 grouping Agents 23, 27, 159 gsk5ikm 276

H
hard stop 32, 172 hardware compliance analysis 31 health reports 228 historical data 211 historical reports 237 host name 211 HTTP Server 69 HTTP Server performance 246 httpd.conf 115 Hub Administrator 152 Hub Support 149 HyperText 55

E
Enable_Auto_logon 256 encryption 55 end-to-end view 211 entitlement 149 entitlement policies 146 ETL 210 ETL programs 213 event notification 117, 126, 155 expcat 177 Expiration Date 172 EXTENTSIZE 244 Extract Transform Load, see ETL extreme case reports 228

I
I/O Servers 241 IBM catalog manager 174 IBM DB2 instance 103 IBM Key Management utility 277 IBM License Policy 45 IBMDEFAULTBP 243 IBMModuleSSL128.dll 116 ikeyman 278 illegal software 147 impcat 181 implementation scenario 145 installation scenario 100 instance 103 INSTHOME 104 interoperability 4 inventory scan 28, 54, 156 scheduling 164 iocleaners 242243 ioservers 242243 IP address 211 IPLA 10 IT standards 147 ITLM reports 228 ITLM Administrator 62 ITLM Agent software package 255 ITLM Agent installer 268 ITLM CLI environment 176

F
failover 68 failure scenario 67 family packaging 7 fictitious company 12 file systems 57 financial information 5 firewall 56

G
gateway server 79 generic authorizations 3 getting statistics 34 governing thresholds 28 grant date 207 granularity 61

298

Introducing IBM Tivoli License Manager

ITLM commands catman 177 impcat 181 ITLM Enablement Pack 185 ITLM hierarchy 60 ITLM logical components 24 ITLM pack configuration 221 install 217 ITLM performance 247 ITLM root user 30 ITLM topology 60 ITLMKEY 277 ITML commands expcat 177 tlmcli 176 ITML hardware requirements 86

management 166 license use management 2, 6 Licensing Manager 154 licensing policies 146 logbufsz 241 logfilsiz 240, 242 logical design 59, 148 logprimary 240 logsecond 240 LSD 83

M
mailRecipient 118, 127 mailSender 118, 127 Master Catalog 96, 174 extracting 177 importing 182 updating 176 measurement source code 215 metadata interchange 212 Microsoft License Management 37 mod_ibm_ssl_128.so 115 MON_HEAP_SZ 240 monitored nodes 61 multi-instance 36, 172

J
J2C 86 java heap 240 java heap size 245 Java memory usage 56 JDBC code level 104 JDK 86 JVM 246

K
kernel 93 key database 276 key factors 2 Key management utility 276 key trusted store 278 key.jks 279 key.kdb 277 Knowledge base 78

N
naming convention 60 naming policies 60 network considerations 83 Nodes 27 nodes 23, 27 NUM_IOCLEANERS 240 NUM_IOSERVERS 239

O
Object Management Group 212 ODBC 222 OLAP analysis 214 open interface 211 Oracle License Management 41 ORB listener port 84 ORB thread 246 OS performance 251

L
licence requests 54 licence usage efficiency 54 license allocation 32 license authorization 34 license checks 34 license management system 7 license pool 32, 34, 149 creating 170 maintenance 167

Index

299

P
Package_Files_distribution 256 page cleaners 239 parallel I/O 244 performance 53 DB2 239 WebSphere 245 performance tips 236 physical design 52, 145 piped sorts 241 plugged 128 plugged sever 158 PMI 245 PmiService 246 pools 149 prefetch 243 prefetchers 239 PREFETCHSIZE 244 price to value 3 procurement information 166 Proxy server 56, 69

software usage 186, 192, 196, 204 RI 214 roles 62 RTM schema 286 runstats 243 Runtime Catalog 174 Runtime server 23, 25

S
Scalability 53 self-signed certificate 277 Server Certificate file 277 SGML 30 SHARE Inc. 2 silent mode deployment 164 smtpServer 118, 127 software entitlement 23, 31, 149 creating 170 maintenance 167 management 166 software inventory 147 software inventory report 201 software life cycle planning 31 software management 174 software package 255 containers 255 definition 259 level 258 variables 257 version 258 Software Reports 29 software usage reports level analysis 196 real-time usage 204 snapshot 186 trend analysis 192 sortheap 241 source ETL scheduling 225 status 227 spying 9 SSL 156 SSL encryption 55 SSL key database 276 SSL-enabled 78 Standard Generalized Markup Language, see SGML 30 Start Date 172

Q
qualified desktops 39 quantity 172 quarterly aggregation 47 Query by option 195 query functions 18 quick analysis 214 quick recovery 66 quintessential business 10 quotas 75

R
raw data 211 RDBMS 212 real-time reports 237 real-time software usage 155 recovery system 66 Redbooks Web site 295 Contact us xxii reorgchk 243 Report Interface, see RI reports Administration server 186 real-time usage 204 Runtime server 204 software inventory 201

300

Introducing IBM Tivoli License Manager

summary reports 228 supply before buy 7

T
Tag 61 target ETL scheduling 225 status 227 Target Type 36, 172 TDW 185, 210 configuration 212, 217 TDW Control Center 215 The Open Group 2 Threshold 172 Tivoli Data Warehouse 214 data mart 214 ETL processes 215 ETL programs 213 source applications 213 warehouse packs 213 Tivoli Data Warehouse, see TDW Tivoli Endpoints 164 TLMA 222 TLMA database 282 tlmcli 176 tlmia.trc 96 TLMR database 286 tlmroot 30, 63, 151, 187, 205 tlmsrv 89, 91 Topology 156 tuning DB2 239 tuning HTTP Server 246 tuning ITLM 247 tuning OS 251 tuning tips 236 tuning WebSphere 245 TWH_CDW 215 changes 221 TWH_MART 215 TWH_MD 215 types of ETLs Central Data Warehouse 214

modifying 177 up and running 99 update JDBC level for DB2 104 Users 23, 28 users roles 62

V
validate the solution 148 value metric 3 value-oriented pricing 9 variables 257 Vendor Managed Use 8 vendor policies 8 vendor's asset protection 10 vendor's view 9 vendors policies 31 version 258 viewing reports 228 virtual memory 56 VirtualHost 78 volume licensing program 38 volume pricing 38

W
W3C 30 warehouse pack 213 was40 85 web interface 150 Web-based deployment 161 Web-based solution 11 WebSM 84 WebSphere Application Server hardware requirements 81 WebSphere Application Server TCP/IP ports 83 WebSphere performance 245 WebSphere resource analyzer 245 Wide Web Consortium 30 WLC 10 workforce 4 workload balancing 4 Workload License Charges, see WLC 10

U
Unknown file list 174 Unknown file table 174 extracting 177 managing 176

X
XML documents 30 XML interfaces 11 XSLM 2

Index

301

Z
z/OS 10 zone 53, 58 zSeries 46

302

Introducing IBM Tivoli License Manager

Introducing IBM Tivoli License Manager

(0.5 spine) 0.475<->0.875 250 <-> 459 pages

Back cover

Introducing IBM Tivoli License Manager


How-to guide for setting up your license management environment Achieve proactive license management Generate reports and identify trends towards license violations
IBM Tivoli License Manager is a new IBM product that fills a growing need to reconcile software licenses that are already in use in an organization, with the licenses owned by the organization. It offers a technical way to control and apply the software vendors pre-defined licensing policies. It allows the Administrator to easily manage different products in different ways, reflecting the rules of each products license agreement. The primary objective of this IBM Redbook is to introduce the new IBM offering for designing and creating a license management solution, and it is targeted at the technical professional responsible for providing license management services in an IT organization. It can be used as a reference book for the deployment of IBM Tivoli License Manager Version 1.1, guiding you during the planning, installation, configuration, administration, tuning, and general product usage phases focusing on how to effectively deploy this product in a way that quickly generates real business value for customers. This redbook is a valuable addition to the existing product documentation and should be read in conjunction with the official product documentation, which complements the concepts explained in this book.

INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION

BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information: ibm.com/redbooks


SG24-6888-00 ISBN 073842823X