IBM Tivoli Business Service Manager: Installation Guide

Business Service Manager 

Version 6.1.1 

Installation Guide 

 

GI11-8054-09

Business Service Manager 

Version 6.1.1 

Installation Guide 

 

GI11-8054-09

Note 

Before using this information and the product it supports, read the information in “Notices” on page 389. 

Edition notice 

This edition applies to IBM Tivoli Business Service Manager Version 6 Release 1.1 and to all subsequent releases 

and modifications until otherwise indicated in new editions. 

© Copyright IBM Corporation 2008, 2013. 

US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract 

with IBM Corp.

Contents 

About this publication . . . . . . . . 1 

Audience . . . . . . . . . . . . . . . 1 

Publications . . . . . . . . . . . . . . 1 

TBSM library . . . . . . . . . . . . . 1 

Prerequisite publications . . . . . . . . . 1 

Related publications . . . . . . . . . . . 2 

Accessing terminology online. . . . . . . . 2 

Accessing publications online. . . . . . . . 2 

Ordering publications . . . . . . . . . . 3 

Accessibility . . . . . . . . . . . . . . 3 

Tivoli technical training. . . . . . . . . . . 3 

Support information . . . . . . . . . . . . 3 

Conventions used in this publication . . . . . . 4 

Typeface conventions . . . . . . . . . . 4 

Introduction to IBM Tivoli Business 

Service Manager . . . . . . . . . . . 5 

What's new in TBSM Version 6.1.1 . . . . . . . 5 

Technical overview of TBSM . . . . . . 7 

TBSM architecture . . . . . . . . . . . . 7 

TBSM components . . . . . . . . . . . . 8 

Integrated applications . . . . . . . . . . 11 

Operating system variables and paths . . . . . 14 

Java support . . . . . . . . . . . . . . 15 

Planning . . . . . . . . . . . . . . 17 

Prerequisite scanner . . . . . . . . . . . 17 

Download the scanner. . . . . . . . . . . 17 

Running the scanner for TBSM . . . . . . . . 17 

System requirements . . . . . . . . . . . 18 

Tivoli Common Reporting requirements . . . . . 20 

Tivoli monitoring Charting web service changes . . 20 

Installing prerequisite software . . . . . . . . 21 

Installing TBSM on an existing Tivoli Integrated 

Portal server . . . . . . . . . . . . . . 21 

TBSM installation user. . . . . . . . . . . 22 

Failover considerations . . . . . . . . . . 23 

IBM Tivoli Netcool Impact Considerations . . . . 24 

IBM Tivoli Netcool OMNIbus Considerations . . . 24 

Netcool/OMNIBus triggers . . . . . . . . 26 

User registry considerations . . . . . . . . . 27 

Dashboard server LDAP configuration . . . . 28 

Data server LDAP configuration . . . . . . 29 

Netcool/OMNIbus user registry . . . . . . 29 

Use Netcool/OMNIBus to access LDAP server 29 

Multiple user registry warnings . . . . . . 30 

TBSM users, user groups, and roles . . . . . 31 

DB2 Installation . . . . . . . . . . . . . 33 

DB2 Database Setup . . . . . . . . . . 33 

Database Disk Space Requirements . . . . . 34 

DB2 Administration and Maintenance . . . . 35 

Database Schema Descriptions . . . . . . . 35 

Other Important Considerations . . . . . . 37 

Installing TBSM . . . . . . . . . . . 39 

TBSM Launchpad . . . . . . . . . . . . 39 

Installation types . . . . . . . . . . . . 40 

Installation order . . . . . . . . . . . . 40 

DB2 schema configuration overview . . . . . . 40 

Running simple DB2 schema configuration . . . 43 

Advanced DB2 configuration . . . . . . . 45 

Creating database schema after installation . . . 49 

Installing TBSM interactively . . . . . . . . 50 

Performing a simple installation . . . . . . 50 

Performing advanced installations . . . . . . 57 

Installing the Netcool/OMNIbus Server 

component . . . . . . . . . . . . . 58 

Tivoli Event Integration Facility Probe Installation 60 

Installing the Data Server component. . . . . 64 

Installing the Dashboard server component. . . 79 

Installing TBSM in silent mode . . . . . . . . 88 

Modifying the setup.rsp file . . . . . . . 89 

Installing TBSM using the console . . . . . . 101 

Uninstalling TBSM . . . . . . . . . . . 102 

Uninstalling TBSM on Windows . . . . . . 102 

Uninstalling TBSM on UNIX . . . . . . . 103 

Reinstalling TBSM. . . . . . . . . . . . 104 

Reinstalling TBSM after a failed installation . . . 104 

Restoring system from a backup . . . 107 

Upgrading TBSM . . . . . . . . . . 109 

Upgrading a 32-bit system . . . . . . . . . 114 

Post upgrade issues . . . . . . . . . . . 116 

UI menu items do not display correctly. . . . 116 

Reinstalling TBSM after a failed upgrade . . . . 117 

Installing and configuring the TBSM 

Agent . . . . . . . . . . . . . . . 119 

Installing the TBSM agent . . . . . . . . . 119 

Configuring the TBSM agent . . . . . . . . 120 

Enabling historical reporting . . . . . . . 122 

Filtering event broker log data . . . . . . 122 

Enabling Agent Management Services for TBSM 123 

TBSM Agent installation reference . . . . . . 124 

Workspaces reference. . . . . . . . . . 124 

Attribute groups and attributes for Business 

Service Management Agent. . . . . . . . 126 

Disk capacity planning for historical data . . . 138 

Predefined situations . . . . . . . . . . 139 

Predefined take action commands . . . . . 142 

Predefined policies . . . . . . . . . . 142 

Installing the Discovery Library 

Toolkit on different system . . . . . 143 

Installing the Discovery Library Toolkit on UNIX 

and Windows . . . . . . . . . . . . . 143 

Toolkit configuration settings . . . . . . . 144 

© Copyright IBM Corp. 2008, 2013 iii

Commands used for silent installation of 

Discovery Library Toolkit . . . . . . . . 148 

Command-line (console) installation . . . . . 148 

Completing the installation of the Discovery 

Library Toolkit . . . . . . . . . . . . . 148 

Verifying the installation of the Discovery Library 

Toolkit. . . . . . . . . . . . . . . . 150 

Modifying the xmltoolkitsvc.properties file . . . 151 

Uninstalling the Discovery Library Toolkit. . . . 151 

Uninstalling the Discovery Library Toolkit on 

Windows . . . . . . . . . . . . . . 151 

Uninstalling the Discovery Library Toolkit on 

UNIX . . . . . . . . . . . . . . . 152 

National Language Support . . . . . 153 

Installing the language pack for TBSM Agent. . . 153 

Uninstalling the language pack for TBSM 

Common Agent . . . . . . . . . . . 154 

Migrating from TBSM 4.2.x . . . . . 155 

Cloning your TBSM servers . . . . . 157 

Cloning the Data server . . . . . . . . . . 157 

Preparing to backup and restore the TBSM 

database information . . . . . . . . . . 158 

Backup the TBSM database information from 

the source DB2 server . . . . . . . . . 159 

Restore the TBSM database information on the 

target DB2 server . . . . . . . . . . . 159 

Export and Import the TBSM Impact project . . 160 

Export and import TBSM data sources and data 

fetchers . . . . . . . . . . . . . . 161 

Additional considerations . . . . . . . . . 163 

Cloning a customized TBSM tree template 

policy . . . . . . . . . . . . . . . 163 

TBSM properties files. . . . . . . . . . 164 

Netcool/OMNIbus . . . . . . . . . . 164 

Discovery Library Toolkit . . . . . . . . 164 

EIF Probe. . . . . . . . . . . . . . 165 

Business Service Management agent . . . . . 166 

Additional considerations . . . . . . . . 166 

Cloning the Dashboard server . . . . . . . . 166 

Export and import the Tivoli Integrated Portal 

server instance data . . . . . . . . . . . 167 

Additional considerations . . . . . . . . . 168 

IBM Tivoli Network Manager . . . . . . . 168 

TBSM GIS maps, icons, images, and style sheets 168 

TBSM properties files. . . . . . . . . . 169 

Netcool/OMNIbus Web GUI . . . . . . . 169 

Netcool GUI Foundation . . . . . . . . 169 

Additional requirements. . . . . . . . . 170 

Configuring TBSM: post installation 171 

Installing a Java plug-in . . . . . . . . . . 171 

Installing the Historical Reports . . . . . . . 172 

TBSM reports install settings . . . . . . . 173 

Install of reports with file parameter . . . . 175 

Enabling Show 30 day History option . . . . 177 

Specifying the schema name . . . . . . . 178 

Configuring data source failover . . . . . . . 179 

iv IBM Tivoli Business Service Manager: Installation Guide 

Configuring IBM Tivoli Business Service Manager 

for failover . . . . . . . . . . . . . . 179 

Overview of the failover process . . . . . . 180 

DB2 high availability configuration . . . . . 183 

Setting up a failover environment . . . . . 186 

Preparing a configuration file for failover . . . 188 

Configuring the ObjectServer communication 

information for failover . . . . . . . . . 197 

Configuring Data servers for failover . . . . 205 

Replicating the alerts.service_deps table 

required for OMNIbus failover . . . . . . 208 

Starting the servers in a failover environment 209 

Verifying that the servers failover successfully 210 

Set up Dashboard server users on existing Tivoli 

Integrated Portal . . . . . . . . . . . . 211 

Load balancing . . . . . . . . . . . . . 212 

Exporting data from a stand-alone server to 

prepare for load balancing . . . . . . . . 215 

Setting up a load balancing cluster . . . . . 216 

Joining a node to a load balancing cluster . . . 218 

Enabling server-to-server trust. . . . . . . 221 

Verifying a load balancing implementation . . 223 

Preparing the HTTP server for load balancing 224 

Setting clone IDs for nodes . . . . . . . . 225 

Generating the plugin-cfg.xml file . . . . . 226 

Configuring SSL from each node to the IBM 

HTTP Server . . . . . . . . . . . . 229 

Importing stand-alone instance data to a cluster 231 

Removing a node . . . . . . . . . . . 232 

Removing a load balancing cluster . . . . . 232 

Monitoring a load balancing cluster . . . . . 233 

Configuring secure connections . . . . . . . 234 

Secure connections overview . . . . . . . 234 

Certificate management for TBSM servers . . . 236 

Running the secure server command . . . . 239 

Configure secure communications to 

Netcool/OMNIBus . . . . . . . . . . 242 

Securing connections to the Discovery Library 

Toolkit. . . . . . . . . . . . . . . 245 

Verifying secure connections . . . . . . . 246 

Replacing the default SSL certificates with 

certificates signed by a certificate authority . . 247 

Modifying the tivoli_eif.props file . . . . . . 252 

Ensure service templates were created . . . . . 253 

Configuring automatic startup of TBSM on UNIX 253 

Removing the automatic startup configuration on 

UNIX . . . . . . . . . . . . . . . . 254 

Troubleshooting installation issues 255 

Common installation issues. . . . . . . . . 255 

Backing up TBSM on a Network File System (NFS) 

drive . . . . . . . . . . . . . . . . 260 

Installation fails on host with existing 

Netcool/OMNIbus . . . . . . . . . . . 260 

Installation fails on new version of Tivoli 

Integrated Portal . . . . . . . . . . . . 261 

Database configuration utility issues. . . . . . 262 

Database configuration installer fails . . . . 262 

TBSM database install fails when user id 

contains a hyphen . . . . . . . . . . . 262 

Russian Windows TBSM and DB2 install fails 262

Cannot create database . . . . . . . . . 263 

Database configuration error messages . . . . 263 

Tivoli Common Reporting issues . . . . . . . 264 

Tivoli Common Reporter data source issues . . 264 

Reports do not execute. . . . . . . . . . 265 

Reports install fails on Solaris . . . . . . . 265 

Tivoli Common Reporting uninstall fails . . . 266 

Windows issues . . . . . . . . . . . . 266 

Windows Server 2008 R2 Enterprise Edition 

x86-64 installation fails during Impact 

Subversion (SVN) step . . . . . . . . . 266 

Windows installation fails . . . . . . . . 267 

Windows services are not uninstalled . . . . 267 

RAD shell issue connecting to the Data server . . 268 

Dashboard server cannot connect to the Data 

server on Linux . . . . . . . . . . . . 269 

ILOG exceptions when displaying service viewer 

or event summary applets after upgrading to 

TBSM . . . . . . . . . . . . . . . . 269 

Initialization of load balance database fails . . . 269 

Clearing the Java plug-in cache on Windows . . . 270 

Clearing the Java plug-in cache on UNIX . . . . 270 

WebSphere Business Events v6.1 fails to launch . . 270 

Default TBSM groups not created during the 

installation process . . . . . . . . . . . 271 

Netcool/OMNIbus install fails on SuSE with ssh 

access . . . . . . . . . . . . . . . . 272 

TBSM server fails after Netcool/Impact 

install/migration . . . . . . . . . . . . 272 

Separating the Data server and Dashboard server 

with a firewall . . . . . . . . . . . . . 273 

Reference . . . . . . . . . . . . . 275 

Log files that TBSM uses . . . . . . . . . 275 

Log files generated by the installation of Discovery 

Library Toolkit . . . . . . . . . . . . . 276 

Sample response file . . . . . . . . . . . 277 

Tivoli Integrated Portal overview . . . . . . . 277 

Accepting the security certificate . . . . . . 277 

Logging in . . . . . . . . . . . . . 278 

Port assignments . . . . . . . . . . . 279 

Viewing the application server profile . . . . 280 

Backing up and restoring the Deployment 

Engine . . . . . . . . . . . . . . 281 

Configuring . . . . . . . . . . . . . 282 

Administering . . . . . . . . . . . . 342 

Notices . . . . . . . . . . . . . . 389 

Trademarks . . . . . . . . . . . . . . 390 

Index . . . . . . . . . . . . . . . 393 

Contents v

vi IBM Tivoli Business Service Manager: Installation Guide

About this publication 

Audience 

Publications 

This guide contains information how to operate, maintain, and configure the 

product. 

This publication is for administrators and system programmers who need to use, 

install, maintain, or configure TBSM. 

This section lists publications in the TBSM library and related documents. The 

section also describes how to access Tivoli ® publications online and how to order 

Tivoli publications. 

TBSM library 

The following documents are available in the TBSM library: 

v Installation Guide, GI11-8054-09 

Provides information about installing the product. 

v Quick Start, GI11-8055-04 

Provides overview information about TBSM. 

v Exploring IBM Tivoli Business Service Manager , GI11-8056-07 

Provides an overview of the product features. 

v Administrator's Guide, SC23-6040-09 

Provides information about managing and configuring TBSM. 

v Service Configuration Guide, SC23-6041-09 

Provides information on how to use the features of the product console. 

v Customization Guide, SC23-6042-09 

Provides information on how to customize select features of the product. 

v Troubleshooting Guide, GI11-8057-09 

Provides information about resolving common problems with the product. 

v Release Notes, 

Provides latest information about the product discovered late in the test cycle 

that cannot be incorporated into the other publications. 

Prerequisite publications 

To use the information in this publication effectively, you must have some 

prerequisite knowledge, which you can obtain from the publications listed here. 

These publications are included on the Tivoli Documentation Central pages at: 

http://www.ibm.com/tivoli/documentation 

v IBM Tivoli Netcool/OMNIbus Version 7 Release 3.1 User Guide 

Provides an overview of Netcool/OMNIbus components, as well as a 

description of the operator tasks related to event management using the desktop 

tools. TBSM uses Netcool/OMNIbus as its event manager. 

© Copyright IBM Corp. 2008, 2013 1

v IBM Tivoli Netcool/OMNIBUS Administration Guide 

Provides information about how to perform administrative tasks using the 

Netcool/OMNIbus Administrator GUI, command line tools, and process control. 

It also contains descriptions and examples of ObjectServer SQL syntax and 

automations. 

v IBM Tivoli Netcool/OMNIBUS Probe and Gateway Guide 

Provides information contains introductory and reference information about 

probes and gateways, including probe rules file syntax and gateway commands. 

For more information about specific probes and gateways, refer to the 

documentation available for each probe and gateway. 

v IBM Tivoli Netcool/OMNIBUS Probe for Tivoli EIF 

Provides reference information about the optional Probe for Tivoli EIF that is 

included with TBSM. 

Related publications 

The following documents also provide useful information and are included in the 

TBSM Information Center. 

These publications are included on the Tivoli Documentation Central pages at: 


v IBM Tivoli Netcool/Impact Administration Guide 

Provides information about installing, configuring and running Netcool/Impact 

and its related software components. TBSM uses Netcool/Impact policies to 

parse events and other data. 

v IBM Tivoli Netcool/Impact User Interface Guide 

Provides information about using the Netcool/Impact user interface. 

v IBM Tivoli Netcool/Impact Policy Reference Guide 

Provides reference information about the Netcool/Impact Policy Language (IPL). 

It contains complete information about policy language syntax, data types, 

operators and functions. 

v IBM Tivoli Netcool/Impact Solutions Guide 

Provides information about implementing Netcool/Impact in your environment. 

v IBM Tivoli Netcool/Impact DSA Reference Guide 

Provides reference information about Netcool/Impact data source adaptors 

(DSA). 

Accessing terminology online 

The IBM Terminology Web site consolidates the terminology from IBM product 

libraries in one convenient location. You can access the Terminology Web site at the 

following Web address: 

http://www.ibm.com/software/globalization/terminology. 

Accessing publications online 

The format of the publications is PDF, HTML, or both. 

IBM ® posts publications for this and all other Tivoli products, as they become 

available and whenever they are updated, to the Tivoli Documentation Central 

Web site at http://www.ibm.com/tivoli/documentation 

2 IBM Tivoli Business Service Manager: Installation Guide

Accessibility 

Note: If you print PDF documents on other than letter-sized paper, set the option 

in the File → Print window that allows Adobe Reader to print letter-sized pages on 

your local paper. 

Ordering publications 

You can order many Tivoli publications online at http://www.ibm.com/ebusiness/linkweb/publications/servlet/pbi.wss. 

Tivoli technical training 

Support information 

You can also order by telephone by calling one of these numbers: 

v In the United States: 800-879-2755 

v In Canada: 800-426-4968 

In other countries, contact your software account representative to order Tivoli 

publications. To locate the telephone number of your local representative, perform 

the following steps: 

1. Go to http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss. 

2. Select your country from the list and click Go. 

3. Click About this site in the main panel to see an information page that 

includes the telephone number of your local representative. 

This guide contains information how to operate, maintain, and configure the 

product. 

Accessibility features help users with a physical disability, such as restricted 

mobility or limited vision, to use software products successfully. In this release, the 

TBSM console does not meet all accessibility requirements. 

For Tivoli technical training information, refer to the following IBM Tivoli 

Education Web site at http://www.ibm.com/software/tivoli/education. 

If you have a problem with your IBM software, you want to resolve it quickly. IBM 

provides the following ways for you to obtain the support you need: 

Online 

Access the IBM Software Support site at http://www.ibm.com/software/ 

support/probsub.html . 

IBM Support Assistant 

The IBM Support Assistant is a free local software serviceability workbench 

that helps you resolve questions and problems with IBM software 

products. The Support Assistant provides quick access to support-related 

information and serviceability tools for problem determination. To install 

the Support Assistant software, go to http://www.ibm.com/software/ 

support/isa. 

Troubleshooting Guide 

For more information about resolving problems, see the problem 

determination information for this product. 

About this publication 3

Conventions used in this publication 

This publication uses several conventions for special terms and actions, operating 

system-dependent commands and paths, and margin graphics. 

Typeface conventions 

This publication uses the following typeface conventions: 

Bold 

v Lowercase commands and mixed case commands that are otherwise 

difficult to distinguish from surrounding text 

v Interface controls (check boxes, push buttons, radio buttons, spin 

buttons, fields, folders, icons, list boxes, items inside list boxes, 

multicolumn lists, containers, menu choices, menu names, tabs, property 

sheets), labels (such as Tip:, and Operating system considerations:) 

v Keywords and parameters in text 

Italic 

v Citations (examples: titles of publications, diskettes, and CDs 

v Words defined in text (example: a nonswitched line is called a 

point-to-point line) 

v Emphasis of words and letters (words as words example: "Use the word 

that to introduce a restrictive clause."; letters as letters example: "The 

LUN address must start with the letter L.") 

v New terms in text (except in a definition list): a view is a frame in a 

workspace that contains data. 

v Variables and values you must provide: ... where myname represents.... 

Monospace 

v Examples and code examples 

v File names, programming keywords, and other elements that are difficult 

to distinguish from surrounding text 

v Message text and prompts addressed to the user 

v Text that the user must type 

v Values for arguments or command options 


Introduction to IBM Tivoli Business Service Manager 

This information can help you understand IBM Tivoli Business Service Manager 

(TBSM), including its business value and key technologies. 

TBSM delivers the real-time information that you need in order to respond to 

alerts effectively and in line with business requirements, and optionally to meet 

service-level agreements (SLAs). 

The TBSM tools enable you to build a service model that you integrate with IBM 

Tivoli Netcool/OMNIbus alerts or optionally with data from an SQL data source. 

TBSM includes optional components that let you access data from other IBM Tivoli 

applications such as IBM Tivoli Monitoring, and IBM Tivoli Application 

Dependency Discovery Manager. TBSM processes the external data based on the 

service model data you created in the TBSM database and returns a new or 

updated TBSM service event to Netcool/OMNIbus. 

The TBSM console provides a graphical user interface (GUI) that allows you to 

logically link services and business requirements within the service model. The 

service model provides an operator with a view of how, second by second, an 

enterprise is performing at any given moment in time or how the enterprise has 

performed over a given time period. 

What's new in TBSM Version 6.1.1 

TBSM Version 6.1.1 contains support for Jazz for Service Management and 

Netcool/Impact 6.1.1. 

Jazz for Service Management 

TBSM has been updated to integrate with Jazz for Service Management and the 

IBM Dashboard Application Services Hub. In order to use these new features, you 

also need to have Jazz for Service Management and the IBM Dashboard 

Application Services Hub installed as part of your environment. 

Jazz for Service Management employs a new deployment pattern and mechanism 

that helps you integrate shared components such as your User Interface, Linked 

Data Registry, Reporting, Security, and Administrative Services. This new 

mechanism helps you speed up delivery cycles for clients and simplify 

deployments. 

For more information see Administration Guide > TBSM and IBM Dashboard 

Application Services Hub. 

IBM Dashboard Application Services Hub 

The IBM Dashboard Application Services Hub provides user interface and 

dashboard services in Jazz for Service management. This new self-service 

dashboard capability enables you to combine a variety of visual widgets such as 

gauges, tables, charts, lists or topology views into custom dashboards using a 

guided work flow. These dashboards can also include management data from 

sources such as: 


v Service status and metrics from TBSM 

v Third-party data from Netcool/Impact 

v Performance metrics from IBM Tivoli Monitoring 

Mobile Support: The self-service dashboard enable you to view business 

dashboards on mobile devices including tablets and phones. This enables access to 

both information technology and business data anytime / anywhere and gives you 

the ability to support your customers more effectively. 

Linked data integration 

The Jazz for Service Management registry services follow the Open Services for 

Lifecycle Collaboration (OSLC) standards; which enable you to reconcile data 

across multiple sources. This capability lets you link to source data, rather than 

duplicating it locally. The data linking enables BSM users, including operators, 

subject matter experts, application owners, or line of business owners to view 

information about their managed services, applications, or resources that helps 

them isolate, diagnose, and route problems. Contextual information about these 

supporting resources can include configuration or health and performance details. 

TBSM uses the registry services to display Hover Preview help for services in the 

Service Tree and Service Navigator. 

For more information see Customization Guide > OSLC hover preview configuration. 

What's new in Netcool/Impact 

TBSM includes a full and integrated version of Netcool/Impact version 6 release 

1.1 as part of the TBSM Data Server. The new version includes these 

enhancements: 

New visualization: The new visualization include Operator View customization 

enhancements and UI Services provided by Jazz for Service Management. These 

will enable clients to link their own data accessed through Impact's proven data 

access methods with visual widgets such as gauges, tables, or lists to create 

dashboards. 

Linked data integration: Netcool/Impact can also use the Jazz for Service 

Management registry services that follow the Open Services for Lifecycle 

Collaboration (OSLC) standards. 

Service Level Objective (SLO) Reporting: Enables you to establish and report on 

service level objectives based on their own measures (for example, incidents, 

tickets, and availability). 

Consumability: Continued improvements to enhance the user experience, 

including MWM cluster replication and e-mail reader enhancements. 

Enhanced Web Services Integrations and Wizards: Enhances and simplifies access 

to web services data sources. 


Technical overview of TBSM 

TBSM architecture 

This section contains topics about the product architecture and the main software 

components. 

This section describes the basic architecture of the IBM Tivoli Business Service 

Manager (TBSM). 

Figure 1 on page 8 shows the basic architecture for TBSM. The TBSM Data server 

analyzes IBM Netcool/OMNIbus ObjectServer events or SQL data for matches 

against the incoming-status rules you configured for your service models. If the 

matching data changes the service status, the status of the TBSM service model 

changes accordingly. When a services status changes, TBSM sends corresponding 

service events back to the ObjectServer. 

You can also use data from an external database or an ObjectServer to drive 

custom views and charts. The Discovery Library Toolkit lets you create TBSM 

service objects using data from Discovery Library Adaptor (DLA) books or from 

the IBM Tivoli Application Dependency Discovery Manager. 

The TBSM users and group permissions are managed by the Tivoli Integrated 

Portal, which can authenticate users internally, or use data from an external source 

such as an ObjectServer or LDAP server. 


Figure 1. Architecture 

TBSM components 

This topic describes the components included on the product DVD. 

The following applications are included on the TBSM product DVD. These 

applications must be installed on a host that is accessible by the TBSM server. 

TBSM has the following major components: 

v Tivoli Integrated Portal 

v IBM Tivoli Netcool/OMNIbus 

v Netcool/OMNIbus Web GUI 

v TBSM Dashboard server 

v TBSM Data server 

v TBSM DB2 ® database 

v IBM Tivoli EIF Probe (optional) 

v Discovery Library Toolkit 

v Business Service Management Agent (optional) 

v IBM Tivoli Netcool/Impact 


Tivoli Integrated Portal 

Tivoli Integrated Portal enables the interaction and secure passing of data between 

Tivoli products through a common portal. You can launch from one application to 

another and within the same dashboard view to research different aspects of your 

managed enterprise. 

Tivoli Netcool/OMNIbus 

TBSM monitors the Tivoli Netcool/OMNIbus ObjectServer for incoming events. 

The ObjectServer collects events from probes, monitors, and other applications 

such as IBM Tivoli Monitoring. You use TBSM to create service models that 

respond to the data received in the incoming events. 

For example, the incoming event data can change the status of a service or start 

the tracking of a potential SLA violation. In short, if you can set up a probe or 

other application to forward data to the TBSM ObjectServer, you can use that data 

to build and monitor your service models. The TBSM installation package includes 

Netcool/OMNIbus. If you want to use the Discovery Library toolkit, or the IBM 

Tivoli Event Integration Facility (EIF) probe you need version 7.1 or higher. 

For more information see: IBM Tivoli Netcool/OMNIbus documentation 

Netcool/OMNIBus Web GUI 

The Web GUI is the browser console for Netcool/OMNIbus and TBSM uses Web 

GUI components to display events related to service models. The Active Event List 

(AEL) and Service Details portlet in TBSM are Web GUI components, and are 

installed as part of TBSM. The Tivoli Integrated Portal also includes Web GUI 

components. 

For more information see: IBM Tivoli Netcool/OMNIBus documentation 

TBSM Dashboard server 

The TBSM Dashboard server manages the TBSM console display. You can have 

multiple dashboard servers for a single data server. The dashboard server enhances 

the scalability, performance, and availability of TBSM. 

The TBSM Dashboard server communicates with the TBSM Data server to support 

the creation and visualization of service models through connected TBSM consoles. 

As console users view portions of the service model, the dashboard server will 

acquire and maintain status of services from the data server. 

TBSM Data server 

The TBSM Data server monitors the ObjectServer and external databases for data 

that affect the status of the services you configured in the TBSM console or with 

the RAD shell command line tool. The server calculates the status of these services 

by applying rules to the external data. Your service models and the rules are stored 

in the TBSM database. 

TBSM DB2 database 

The TBSM DB2 database stores all the information on the service models you 

created in the TBSM console. This data includes rules that determine how your 

Technical overview of TBSM 9

service model changes in relation to data in external data sources. This database 

also includes tables for the metrics and markers used in the Time Window 

Analyzer and demo data. A Metric History database, which has a default name of 

TBSMHIST, is also included to store the historical metric data, 

TBSM DSAs 

The optional data source adaptors (DSA) let you monitor external data sources for 

service-affecting data. You can use a DSA within an Impact policy in TBSM. The 

external data provided by the DSA allows you to build your service-model 

structure, and monitor the status of your service model. DSAs are shipped with 

IBM Tivoli Netcool/Impact. For more information, see Tivoli Documentation 

Central. Search under I. 

Tivoli EIF probe 

You can set up the optional IBM Tivoli Event Integration Facility (EIF) probe to 

access the event data from various Tivoli applications. The probe is a generic EIF 

event listener that can receive events from any application that has the capability 

to create EIF events and forward those events to a event listener. 

Discovery Library Toolkit 

The Discovery Library Toolkit enables TBSM to discovery resources and to 

automatically build service models from Discovery Library data sources. These 

sources include:IBM Tivoli Application Dependency Discovery Manager , 

Discovery Library books conforming to the common data model, Discovery Library 

books containing objects for an alternate namespace, the Discovery Library toolkit 

API, or auto-pop objects. 

Data discovered through the toolkit can be enriched through notifications sent to 

Impact. This enriched data can then be used in the automatic building of the 

service model. 

Business Service Management Agent 

The optional IBM Tivoli Business Service Management Agent provides you with 

the capability to monitor Tivoli Business Service Manager, and to perform basic 

actions within the Tivoli Enterprise Portal. 

The Business Service Management Agent provides the following functions: 

v TBSM service monitoring 

Collects and displays information on the status of services monitored by TBSM, 

key performance indicators, and root cause events for the status change, and the 

status of the TBSM Data server. 

v TBSM event broker log monitoring 

Collects and displays information on the number of events read per second and 

the amount of memory used by the TBSM event broker based on data from the 

TBSM_tbsmomnibuseventreader.log file. 

v Availability monitoring 

Collects and displays availability information separately for the monitored TBSM 

server. The agent pings the application to determine whether the TBSM Data 

server is available. 


For more information, see the "Installing and configuring the TBSM Agent" section 

in the IBM Tivoli Business Service Manager Installation Guide. 

Netcool/Impact 

Integrated applications 

Netcool/Impact is the automation, correlation, and integration engine for the IBM 

Tivoli Netcool suite of software products. You can use Netcool/Impact to automate 

event management tasks, to correlate event information with other information in 

your environment, and to integrate Netcool products with a wide variety of third 

party systems and applications. 

TBSM now includes a full and integrated version of Netcool/Impact version 6 

release 1.1 as part of the TBSM Data Server. As a consequence of this integration, 

you can now take advantage of these Netcool/Impact capabilities: 

v You can use Netcool/Impact services and policies to acquire, enrich, and pass 

data to TBSM to use for service status determination or visualization. 

v TBSM uses the same policy functions and policy language as Netcool/Impact. 

Javascript is supported as a policy language in addition to IPL (Impact Policy 

Language). 

v Event enrichment is supported as an out-of-box function. Impact policies enrich 

events before TBSM reads these same events for status determination and 

propagation. 

v The Dashboard server package includes the Impact User Interface which is 

deployed into the Tivoli Integrated Portal. This provides a common user 

interface for administration of both TBSM and Impact policies and services. 

v The Data server package includes a name server that enables you to access 

Netcool/Impact server clusters. 

For more information about Netcool/Impact, see the Tivoli Netcool/Impact 

publications at: Netcool/Impact Documentation. 

This section is an overview of the optional external applications you can integrate 

with TBSM. 

The following applications either forward data to TBSM, or receive data from 

TBSM: 

v Jazz for Service Management and the IBM Dashboard Application Services hub 

can display TBSM service data in graphical widgets and share data with other 

applications. 

v Using the IBM Tivoli EIF probe, you can forward data from IBM Tivoli 

Monitoring version 6 release 1 and above, Tivoli Enterprise Console ® version 3 

release 9 or later, IBM Tivoli Netview version 3 release 7 or later, and the IBM 

Tivoli Event Pump for z/OS ® version 4 release 2. 

v Netcool/Impact version 6.1.1 is installed as part of the TBSM data server. TBSM 

can receive data from other Netcool/Impact servers that share that same name 

service as the TBSM server. 

v IBM Tivoli Application Dependency Discovery Manager version 7 release 1.2 or 

later 

v IBM Tivoli Enterprise Portal (Tivoli Monitoring charts) 

v IBM Tivoli Composite Application Manager for Internet Service Monitoring 

(ITCAM for Internet Service Monitoring) 


v IBM Tivoli Change and Configuration Management Database (CCMDB) version 

7 releases 1 and 1.1 

v Discovery Library Adapters including those from the following products: 

– IBM Tivoli Monitoring (6.2.3 or higher is recommended) 

– IBM Tivoli Business Service Manager for z/OS 

– IBM Tivoli Composite Application Manager for SOA 

– IBM Tivoli Composite Application Manager for WebSphere ® 

– IBM Tivoli Composite Application Manager for Transaction Tracking 

– IBM Tivoli Network Manager 

– IBM Tivoli NetView ® for z/OS 

– IBM Tivoli Storage Productivity Center version 4, release 1.1 

You can launch to or from the following applications from TBSM: 

v Tivoli Monitoring 6.2 with fix pack 1 or later 

v Tivoli Application Dependency Discovery Manager 7.1 or later 

v CCMDB version 7.1 or later 

v Netcool/OMNIbus Web GUI component bundled with TBSM. 

v IBM Tivoli Network Manager IP Edition version 3 release 8 

v IBM Tivoli Composite Application Manager for Transactions version 7 release 

1.0.2 

v IBM Tivoli TotalStorage Productivity Center (TPC) 

Note: For launch support, the supported product versions may be more restrictive 

than those specified for data exchange above. 

Jazz for Service Management 

TBSM has been updated to integrate with Jazz for Service Management and the 

IBM Dashboard Application Services Hub. In order to use these new features, you 

also need to have Jazz for Service Management and the IBM Dashboard 

Application Services Hub installed as part of your environment. 

Jazz for Service Management employs a new deployment pattern and mechanism 

that helps you integrate shared components such as your User Interface, Linked 

Data Registry, Reporting, Security, and Administrative Services. This new 

mechanism helps you speed up delivery cycles for clients and simplify 

deployments. 

For more information see Administration Guide > TBSM and IBM Dashboard 

Application Services Hub. 

IBM Dashboard Application Services Hub 

The IBM Dashboard Application Services Hub provides user interface and 

dashboard services in Jazz for Service management. This new self-service 

dashboard capability enables you to combine a variety of visual widgets such as 

gauges, tables, charts, lists or topology views into custom dashboards using a 

guided work flow. These dashboards can also include management data from 

sources such as: 

v Service status and metrics from TBSM 

v Third-party data from Netcool/Impact 


v Performance metrics from IBM Tivoli Monitoring 

Mobile Support: The self-service dashboard enable you to view business 

dashboards on mobile devices including tablets and phones. This enables access to 

both information technology and business data anytime / anywhere and gives you 

the ability to support your customers more effectively. 

Tivoli Event Integration Facility (EIF) probe 

You can set up the optional IBM Tivoli Event Integration Facility (EIF) probe to 

access the event data from applications such as IBM Tivoli Monitoring, Tivoli 

Enterprise Console, and Tivoli Netview. The probe forwards the event data to the 

TBSM Netcool/OMNIbus ObjectServer. You can use TBSM to create service models 

based on the event data from the Event Pump for z/OS, Tivoli Monitoring (and 

Tivoli Monitoring agents), Tivoli Enterprise Console, and Tivoli NetView. 

Tivoli Enterprise Portal 

If you create service models with the TBSM Discovery Library integration, these 

services can represent resources monitored by Tivoli Monitoring and contain data 

about the Tivoli Enterprise Portal server used to monitor those resources. If a 

service represents an Tivoli Monitoring resource and contains this data, then the 

Tivoli Enterprise Portal can be launched from TBSM. Likewise, you can also launch 

TBSM from the Tivoli Enterprise Portal console. 

IBM Tivoli Composite Application Manager for Internet Service 

Monitoring 

From within TBSM you can automatically configure IBM Tivoli Composite 

Application Manager for Internet Service Monitoring (ITCAM for Internet Service 

Monitoring) monitors so that TBSM can receive ISM events from an ObjectServer. 

IBM Tivoli Netcool/Impact 

Netcool/Impact is the automation, correlation, and integration engine for the IBM 

Tivoli Netcool ® suite of software products. You can use Netcool/Impact to 

automate event management tasks, to correlate event information with other 

information in your environment, and to integrate Netcool products with a wide 

variety of third party systems and applications. 

You can configure Netcool/Impact to forward events to the Netcool/OMNIbus 

ObjectServer monitored by TBSM and use those events to update your service 

model. Netcool/Impact is designed for Netcool administrators who want to 

enhance, customize, and extend the capabilities of the Netcool suite. For more 

information, see the Netcool/Impact publications. 

Change and Configuration Management Database 

TBSM can launch into a Change and Configuration Management Database 

(CCMDB) associated with a Tivoli Application Dependency Discovery Manager. If 

you create service models with the TBSM Discovery Library integration, these 

services can contain data about a Tivoli Application Dependency Discovery 

Manager server. If a service contains data about a Tivoli Application Dependency 

Discovery Manager server, you can launch the Tivoli Application Dependency 

Discovery Manager and CCMDB consoles from the TBSM console. Likewise, you 


can also launch TBSM from the Tivoli Application Dependency Discovery Manager 

console. 

Operating system variables and paths 

On both the Data server and the Dashboard server a script is provided that allows 

you to set environment variables for quick access to the TBSM directory structure. 

If you do not set the variables, you can substitute directories with full path names 

when you run commands. 

You must run the script that applies to the servers that you installed. If you 

installed both servers on the same system, you must run both scripts. 

The locations of these setup scripts on UNIX systems are as follows: 

v installdirectory/tbsm/bin/setupTBSMData.sh for the Data server 

v installdirectory/tbsm/bin/setupTBSMDash.sh for the Dashboard server 

where installdirectory is the directory in which you installed the server. The default 

directory is /opt/IBM/tivoli. 

The syntax used to run the UNIX scripts is: 

. installdirectory/tbsm/bin/setupTBSMData.sh 

The locations of these setup scripts on Windows systems are as follows: 

v installdirectory\tbsm\bin\setupTBSMData.bat for the Data server 

v installdirectory\tbsm\bin\setupTBSMDash.bat for the Dashboard server 

where installdirectory is the directory in which you installed the server. The default 

directory is C:\Program Files\IBM\tivoli. 

The following environment variables are used by TBSM as system environment 

variables: 

v TBSM_HOME 

This variable is used on both the Data and Dashboard servers. By default, the 

path set for this variable on Windows is C:\Program Files\IBM\tivoli\tbsm. The 

default path on the UNIX operating system is /opt/IBM/tivoli/tbsm 

v TBSM_DATA_SERVER_HOME 

This variable is used on the Data server. By default, the path for this variable on 

Windows is: C:\Program Files\IBM\tivoli\tipv2\profiles\TBSMProfile\ 

installedApps\TBSMCell\TBSM.ear. The default path on the UNIX operating 

system is /opt/IBM/tivoli/tipv2/profiles/TBSMProfile/installedApps/ 

TBSMCell/TBSM.ear. 

v TBSM_DASHBOARD_SERVER_HOME 

This variable is used on the Dashboard server. By default, the path set for this 

variable on Windows is C:\Program Files\IBM\tivoli\tipv2\profiles\ 

TIPProfile\installedApps\TIPCell\isc.ear\sla.war. The default path on the 

UNIX operating system is /opt/IBM/tivoli/tipv2/profiles/TIPProfile/ 

installedApps/TIPCell/isc.ear/sla.war 

v TIP_HOME 

This variable is used on both the Data and Dashboard servers. By default, the 

path set for this variable on Windows is C:\Program Files\IBM\tivoli\tipv2. 

The default path on the UNIX operating system is /opt/IBM/tivoli/tipv2. 


Java support 

Variables used in TBSM Publications 

For many of the commands and paths specified in this publication, both the UNIX 

and Windows equivalents are provided. However, in instances where only the 

UNIX convention has been specified, follow these directions for Windows systems. 

When using the Windows command line, replace $variable with % variable% for 

environment variables and replace each forward slash (/) with a backslash (\) in 

directory paths. The names of environment variables are not always the same in 

the Windows and UNIX environments. For example, %TEMP% in Windows 

environments is equivalent to $TMPDIR in UNIX environments. 

Note: If you are using the bash shell on a Windows system, you can use the UNIX 

conventions. 

This topic describes the Java runtime Environment (JRE) plug-in versions that are 

required for the IBM Tivoli Business Service Manager user interface in a web 

browser. 

Supported Java runitme versions: The most up-to-date information about 

supported hardware, software, browsers and operating systems is provided by the 

IBM Software Product Compatibility Reports at: 

http://pic.dhe.ibm.com/infocenter/prodguid/v1r0/clarity/prereqsForProduct.html 

1. In the Full or partial product name: field, type Business Service and click the 

search button. 

2. From the Search Results, select Tivoli Business Service Manager. 

3. From the Version field, select 6.1.1. 

4. From Mandatory capabilities:, select Java. 

5. Click Submit. 

For more information on the Software Product Compatibility Reports, see the 

Overview and Planning topic in the TBSM Wiki: 

https://www.ibm.com/developerworks/mydeveloperworks/wikis/ 

home?lang=en#/wiki/Tivoli%20Business%20Service%20Manager1/page/Overview 

%20and%20Planning 

Note: The Java Runtime Environment that is being used should be updated to the 

most recent fix level. 

Important: These web browser settings are required: 

v JavaScript is enabled in the browser. 

v Set your browser to allow pop-up windows. If you block pop-up windows, you 

will disable features of TBSM that require pop-up windows. 

v Set your browser to accept third-party cookies. 



Planning 

Prerequisite scanner 

Download the scanner 

This section details preinstallation considerations, such as supported hardware, 

software, and operating systems. 

Download and run the IBM Prerequisite Scanner as part of your installation 

planning. 

IBM Prerequisite Scanner is a stand-alone prerequisite checking tool that analyzes 

system environments before the installation or upgrade of a Tivoli product or IBM 

solution. The scanner includes configuration files for TBSM. 

Download the scanner for your operating system. 

About this task 

This procedure describes where to find the scanner and the information needed to 

install the scanner. 

Procedure 

1. Download the scanner version for your operating system from this page: 

http://www-933.ibm.com/support/fixcentral/swg/ 

selectFixes?parent=ibm~Tivoli&product=ibm/Tivoli/Prerequisite+Scanner 

&release=All&platform=All&function=all 

2. For general instructions on downloading, installing, and running the scanner, 

click on More Information for the version you are downloading. 

3. Extract the scanner files to a location on your TBSM host. This location is called 

the ips_root directory in this topic. 

What to do next 

Run the scanner on your host system. 

Running the scanner for TBSM 

You need to use the TBSM-specific options described here when you run the 

scanner. Before you run the scanner, you must set the environment variable that 

indicates to the scanner which servers are being installed on the target computer 

and consequently, which prerequisites to check. 


This procedure describes how to set the environmental variable that instructs the 

Scanner to scan for the prerequisites of the chosen server installation specified in 

the relevant section of the configuration file. It also describes how to run the 

scanner. 


Procedure 

1. Open a command window: 

2. Change to the ips_root directory. 

3. Set the value for one of the following environmental variables to True: 

Option Description 

Data server installation only TBSM_PREREQ_DATA 

Dashboard server installation only TBSM_PREREQ_DASH 

Combined Dashboard and Data server 

installation 

TBSM_PREREQ_BOTH 

Important: The values you use to set the variable are case sensitive. For 

example, only the value True will set the variable correctly. 

For example, to set the environmental variable on a Windows system and 

instruct Prerequisite Scanner to scan for the prerequisites required for a 

Dashboard server installation, enter the following command: 

set TBSM_PREREQ_DASH=True 

4. Run the command: 

v Windows: prereq_checker.bat "BSM 06010100" detail 

v UNIX: prereq_checker.sh "BSM 06010100" detail 

Results 

System requirements 

Possible results are as follows: 

FAIL: If the target server does not meet the prerequisites specified in the cfg files, 

the scanner returns FAIL for the Tivoli Business Service Manager check. 

The failed prerequisites are displayed in the screen output. To resolve the 

failure, take the appropriate actions, for example, install the missing 

operating system packages, increase disk space and so on. 

PASS: 

If the target server has all the prerequisite specified in the cfg files, the 

scanner returns PASS for the Tivoli Business Service Manager check. If the 

scanner returns PASS for the Tivoli Business Service Manager check you 

can install, configure and start the product on the target server 

Related information: 

IBM Tivoli Prerequisite Scanner (PRS) for Tivoli Netcool/OMNIbus V7.3.1 

IBM Prerequisite Scanner Information Center 

Your environment must meet these software requirements. 

Software Product Compatibility Reports 

The most up-to-date information about supported hardware, software, browsers 

and operating systems is provided by the IBM Software Product Compatibility 

Reports at: 

http://pic.dhe.ibm.com/infocenter/prodguid/v1r0/clarity/index.html 


For more information about running the Software Product Compatibility Reports, 

see the Overview and Planning section of the TBSM Wiki. 

Preparing operating systems for installation 

TBSM is built on the WebSphere Application Server and you need to review 

information on how to prepare system before you install TBSM. 

For information on preparing your operating system, see: 

http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic= 

%2Fcom.ibm.websphere.installation.base.doc%2Finfo%2Faes%2Fae 

%2Ftins_prepare.html 

Tuning your operating system 

TBSM is built on the WebSphere Application Server and you need to review 

information on how to tune your system before you install TBSM. 

For information on tuning your operating system, see: 

http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic= 

%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftprf_tuneopsys.html 

Installer temp file space requirement 

The TBSM requires a minimum of 500 MB of temporary space to run on all 

operating systems. Otherwise, the installer will fail. 

CAUTION: 

On Unix and Linux platforms, prior to installing TBSM or 

Netcool/Impact, ensure that there is no tmp subdirectory under the /tmp directory. 

Otherwise, the installation will fail. 

Virtual machines 

For general information related to running TBSM on virtual machines, see the 

Overview and Planning section of the TBSM wiki. 


home?lang=en#/wiki/Tivoli%20Business%20Service%20Manager1 

C++ Library runtime requirement for Windows 

You must ensure that the following C++ runtime packages are installed on your 

Windows operating system: 

v Microsoft Visual C++ 2008 SP1 Redistributable Package (x86) 

v Microsoft Visual C++ 2008 SP1 Redistributable Package for (x64) 

To verify that the packages are installed on your operating system, click Control 

Panel > Programs and Features. 

If C++ runtime libraries are not installed, you can download them from the 

following links: 

Planning 19

v Microsoft Visual C++ 2008 SP1 Redistributable Package (x86): from 

http://www.microsoft.com/en-us/download/details.aspx?id=5582. 

v Microsoft Visual C++ 2008 SP1 Redistributable Package for (x64) from 


Note: You must install one of the 2008 versions of Windows Server because other 

versions are not supported. 

IBM Solutions for Business Service Management support 

If you have the Solutions for BSM on a TBSM 6.1.0.1 system, you can upgrade to 

version 6.1.1 and retain the features of the solutions. However, if you want to 

install the solutions on a newly installed 6.1.1 system, you must take additional 

steps. For more information about the Solutions for BSM and TBSM 6.1.1, see the 

Overview and Planning section of the TBSM Wiki. 

Tivoli Common Reporting requirements 

As part of your planning, review the Tivoli Common Reporting requirements. 

If you plan to install Tivoli Common Reporting, you need to know the 

requirements for this product. For the hardware and software requirements see the 

Common Reporting Information Center at: 

http://pic.dhe.ibm.com/infocenter/tivihelp/v3r1/topic/ 

com.ibm.tivoli.tcr.doc_211/rtcr_soft_and_hard_reqs.html 

Key points: 

v Download and run the IBM Prerequisite Scanner as part of your installation 

planning as described in the Common Reporting Information Center. 

v Common Reporting requires that you install the database client for the database 

you want to use. The database client is typically provided by the database 

vendor with the database package. For example, you can find the Oracle client 

on your Oracle host system. 

Tivoli monitoring Charting web service changes 

The charting Web Service was made available as of Tivoli Monitoring 6.2.2 FP2. In 

TBSM 4.2.1, the charting web service was part of the TBSM installation, in TBSM 

6.1.1, you install and configure the web service on your Tivoli Monitoring Tivoli 

Enterprise Portal Server (TEPS). 

For information on how to install and configure the web service on your TEPS 

server, see the section titles Enabling the IBM Tivoli Monitoring Charting Web Service 

in the Administration Guide for the latest version of Tivoli Monitoring version 6.x.: 


Search for Tivoli Monitoring under M. 

For information on migrating your pre-existing policy-based data fetchers, see the 

Migration section of this guide. 


Related tasks: 

“Migrating from TBSM 4.2.x” on page 155 

You must migrate to TBSM 6.1 and install Fix Pack 1 before you upgrade to 

version 6.1.1. 

Installing prerequisite software 


TBSM requires a minimum of IBM DB2 . . You install the TBSM databases on the 

DB2 instance and specify the host, port, and user information during the TBSM 

installation. 

Software Product Compatibility Reports: 



Reports at: 






Download and run the IBM Prerequisite Scanner as part of your installation 

planning as described in this guide. 

The prerequisite software in the following list is included on one of the TBSM 

product DVDs. The order in which the software is installed is important. Install the 

software in the following order: 

1. DB2 Database Configuration utility 

2. IBM Tivoli Netcool OMNIbus 

3. TBSM Data server/Discovery Library Toolkit 

4. TBSM Dashboard server 

5. EIF Probe 

Migration of Tivoli Netcool OMNIbus is not supported from the TBSM installation 

program. Follow migration procedures that are documented for that program and 

see the migration section of this guide. 

Note: If you are installing TBSM in a failover environment, see the failover 

information in the Configuring: post installation section of this guide. 

Installing TBSM on an existing Tivoli Integrated Portal server 

If you want to install TBSM on an existing Tivoli Integrated Portal server, it might 

be necessary to upgrade your Tivoli Integrated Portal version before you attempt 

the TBSM installation. TBSM requires Tivoli Integrated Portal version 2.2.0.11. 

At the time of the TBSM 6.1.1 release, version 2.2.0.11 was the latest version, but 

check the Fix Central page for a more recent version of Tivoli Integrated Portal: 

Planning 21

TBSM installation user 


Note: To obtain the latest Tivoli Integrated Portal upgrade, see the Fix Central 

page at: 

http://www-933.ibm.com/support/fixcentral/swg/selectFixes?parent=ibm~Tivoli 

&product=ibm/Tivoli/Tivoli+Integrated+Portal&release=All&platform=All 

&function=all 

The installation user is the person who installs products in the TBSM program suite. 

The installation user must install every TBSM product as the same system user. 

Note: Once you have installed a Tivoli Integrated Portal product using a certain 

user account, you must use the same user account to install, uninstall, or modify 

every subsequent Tivoli Integrated Portal product on that system. However, if the 

Tivoli Integrated Portal product installed is a different TBSM version, you must use 

a different user account to install the new version. 

On Windows platforms, the TBSM installation user can be any user on the system 

that is a member of the Administrators group. 

Restriction: You cannot install TBSM, DB2, or configure the DB2 

databases for TBSM when you are logged in with a user id containing non-English 

characters. DB2 does not recognize a user id with non-English characters, such as 

Russian. For example, the Windows Administrator userid on a Russian operating 

system has Russian characters in the name. Typically, you do not have these 

problems in UNIX because the user names have English characters. 

To install DB2, rename the user id and Administrators group to have English 

characters only. Log in with the renamed Administrator user id. Install DB2 

while logged in with the renamed Administrator id. You also need to run the 

TBSM Database Configuration utility with the same renamed Administrator user 

id. 

You must use the port used for DB2. 

However, to install TBSM, you must log in with a user id with English characters 

that is a member of the Administrators group. The user id cannot be the renamed 

non-English Administrator id. You must log in with a user id that was originally 

created with English characters. One example is to use the db2admin user id that is 

normally created during a DB2 installation. 

TBSM database user name restriction: The TBSM database does not recognize a 

user id containing the following dash/hyphen character: "-". 

Restriction: Installing TBSM as root user on Unix is valid, however 

with root user, only console mode or silent install is supported on the following 

Operating Systems: 

v AIX 

v SUSE Linux Enterprise Server (SLES) 

v Solaris 


Failover considerations 

The launchpad install will not succeed on the above operating systems, if launched 

by the root user. 

This section provides a preinstall checklist to use as a guide if you plan to 

configure failover after you install. 

Use the following preinstall checklist as a guide if you plan to configure failover 

after you install. 

v Configure directory permissions so that the non-root user ID you are installing 

with has write permissions to the installation directory. 

v Verify that your DNS configuration files, etc/hosts files, or both, on all servers 

can communicate with each other using host names. 

v Verify that a reference to the current host's name uses the actual IP address and 

not the loopback address 127.0.0.1. On many systems, you can ping 

and examine the IP address displayed as the command runs. 

v Review any operating system and firewall settings to prevent blocking 

communication among servers. 

v The same Tivoli Integrated Portal administrative userid (for example tipadmin) 

and password must be used for all TBSM Data and Dashboard servers in a 

failover configuration. 

Additional failover considerations 

There are a few additional considerations before performing the advanced 

installation. 

v The primary and backup server must be running the same version and release of 

TBSM and the same operating system. For example, you cannot use a TBSM 4.1 

backup server with a TBSM primary server. 

v Use the same non-root user ID to install TBSM on the primary and backup 

server to ensure that the user ID and password are the same for both machines. 

On Windows, choose the same user ID and password when prompted for the 

account. 

v The primary and backup TBSM installation must use the same authentication 

method, either LDAP or Tivoli Netcool OMNIbus. The file-based authentication 

method is not supported for failover configurations. 

v If you change any of the default port values during installation, use the same 

values for both installations. 

v If you use the Netcool/OMNIbus ObjectServer for authentication and the 

ObjectServer is set up for failover, you need replicate the security information in 

the ObjectServer bi-directional gateways as described in the Configuring failover 

section of this guide. 

For additional information about failover configuration see the Configuring: Post 

Installation > Configuring failover in this guide. 

Failover and ObjectServer authentication considerations 

If you intend to use IBM Tivoli Netcool OMNIbus ObjectServer authentication and 

you intend to use the Tivoli Netcool OMNIbus ObjectServer you are installing with 

TBSM as the authentication source, specify this during installation. 

Planning 23

The TBSM failover configuration procedures and scripts do not modify the 

authentication configuration of TBSM nor do they arrange for replication of 

authentication information between the primary and backup ObjectServers. If you 

are using ObjectServer authentication, consult the OMNIbus documentation for 

information about setting up replication of such information using the bidirectional 

gateway. 

IBM Tivoli Netcool Impact Considerations 

TBSM includes Tivoli Netcool Impact s version 6.1.1. 

You can install another Netcool/Impact server on the same host as TBSM, but you 

must install it in different installation directory and use different port numbers for 

the new server. The new Netcool/Impact server would be in its own cluster. 

IBM Tivoli Netcool OMNIbus Considerations 

TBSM supports Tivoli Netcool OMNIbus version 7.3.1 and later. 

Note: If you are installing Tivoli Netcool OMNIbus on Red Hat Enterprise Linux 

AS, ES, or WS 5, you must ensure that the following files are available on your 

system before the installation: 

v compat-libstdc++-33-3.2.3-61.i386.rpm 

v libXp-1.0.0-8.i386.rpm 

v openmotif22-2.2.3-18.i386.rpm 

v libXmu-1.0.2-5.i386.rpm 

v libXpm-3.5.5-3.i386.rpm 

v compat-libstdc++-296-2.96-138.i386.rpm 

These files should be available on the installation CDs for the operating system. 

Using an existing ObjectServer for TBSM 

If you plan to use an existing Netcool OMNIbus ObjectServer instead of the one 

included in your TBSM installation, you need to add the TBSM schema and have 

the ObjectServer running before you install TBSM . 

Note: If your ObjectServer requires a fix pack to support TBSM, the TBSM 

installation attempts to install the fix pack and fails. See the installation trouble 

shooting topic for more information. 

Also, if you want to use the ObjectServer that was used for TBSM 4.2x, you need 

to add the 6.1.1 schema to it before you install version 6.1.1. 

When you run the scripts to update the ObjectServer schema for TBSM, you might 

need to update the path for the schema scripts on the DVD and in the install 

directory. 

You must know the host name and port number because you will be asked to 

provide them when you are installing TBSM . 

Before you install TBSM and the Tivoli Event Integration Facility probe (EIF 

probe), you have to modify the Netcool OMNIbus ObjectServer schema. The 

command and schema files are located in the TBSM install image in the directory: 

TBSM\omnibus\schema_files 


To update an existing Netcool OMNIbus ObjectServer schema for TBSM: 

1. Copy the entire of the TBSM\omnibus\schema_files directory to the host where 

Netcool/OMNIbus is installed. 

2. Open a command or shell window. 

3. Change to the directory where you copied TBSM\omnibus\schema_files. 

4. Run the import_schema command with the schema file tbsm_db_update.sql as a 

parameter. 

.\import_schema.bat %NCHOME% tbsm_db_update.sql 

RAD ObjectServerName user password 

./import_schema.sh $NCHOME tbsm_db_update.sql 


Where: 

v NCHOME is the value of the installation directory for Netcool/OMNIbus 

v tbsm_db_update.sql is the name and location (if needed) of the schema file to 

read 

v RAD is the schema validation string 

v ObjectServerName is the name of your ObjectServer 

v user is the user name for the ObjectServer 

v password is the value of the ObjectServer password 

In this example, $NCHOME is /opt/ibm/netcool, ObjectServerName is NCOMS, 

user is root, and password is mypass, resulting in the following line: 

./import_schema.sh /opt/ibm/netcool tbsm_db_update.sql RAD NCOMS root mypass 

Note: 

You may receive error messages similar to the following when running 

tbsm_db_update.sql command: 

ERROR=Object exists on line 83 of statement 

’----------------------------------------------------------------...’, 

at or near ’BSM_Identity’ (0 rows affected) (0 rows affected) 

(0 rows affected) 

ERROR=Object not found on line 15 of statement 

’---------------------------------------------------------------------- 

...’, at or near ’service_deps’ 







These messages can be ignored. The ObjectServer will return an error if a user 

tries to add a column that already exists, which explains the error on 

BSM_Identity. It will also return an error if a user drops a table that doesn't 

exist, which explains the second error. 

5. Run the import_schema command again, but specify ClearServiceDeps.auto as 

the schema file parameter as follows: 

.\import_schema.bat %NCHOME% ClearServiceDeps.auto 


Planning 25

./import_schema.sh $NCHOME ClearServiceDeps.auto 



“Installing the Data Server component” on page 64 

You can use the installation program to install only the Data Server component, 

which includes the Discovery Library Toolkit. This is recommended in a 

production environment, where you want to install the Data Server component on 

a separate system from the other TBSM components. 

“Installing the Netcool/OMNIbus Server component” on page 58 

You can use the installation program for IBM Tivoli Business Service Manager 

(TBSM) to install only the IBM Tivoli Netcool OMNIbus Server component. This is 

useful in a production environment, where you want to install the Tivoli Netcool 

OMNIbus Server component on a separate system from the other TBSM 

components. 

“Troubleshooting installation issues” on page 255 

Netcool/OMNIBus triggers 

This topic describes the Netcool/OMNIbus triggers installed with TBSM. 

Purpose 

The triggers help manage event processing for Tivoli Netcool OMNIbus and TBSM. 

Trigger descriptions 

TBSM includes the triggers: 

rad_update_fields_on_dedup 

When TBSM updates events, this trigger specify the deduplication field 

settings. 

itm_deduplication 

Deduplication processing for alert.status for IBM ® Tivoli ® Monitoring alerts 

only. 

itm_event_clear 

Tivoli Monitoring Event Problem/Resolution. 

tec_deduplication 

Deduplication processing for alerts.status for IBM Tivoli Enterprise 

Console ® alerts only. 

updatetecstatus 

Update TECStatus field with status changes to Netcool/OMNIbus. 

synchronizetec 

Synchronize Tivoli Enterprise Console server with status/severity changes 

to Netcool/OMNIbus. 

deletetec 

Synchronize Tivoli Enterprise Console server with event deletions in 

Netcool/OMNIbus. 

ClearServiceDeps 

Removes all entries in the service_deps table that correspond to events that 


User registry considerations 

have been deleted in Netcool/OMNIbus. This automation is in the TBSM 

installation image and only used when you import the TBSM schema into 

an existing ObjectServer by hand. 

The configuration options you have when you set up IBM Tivoli Business Service 

Manager for an external user registry. 

If you are using a Lightweight Directory Access Protocol (LDAP) product, you 

must select the file-based repository option during the installation. You can then 

manually configure your LDAP repository as described in the TBSM Administration 

Guide. 

Users and user groups in external repositories 

When you use an external repository for TBSM, all the users and user groups must 

be unique across the logical, federated repository in WebSphere. WebSphere 

provides the concept of a "Federated Repository" which is a single logical view of 

potentially multiple physical repositories that could all be connected to at the same 

time - LDAP, OMNIBus, and file registry. 

You cannot have the same user or group name in both an external repository and 

the internal file-based repository. Otherwise, the user or members of the duplicated 

user groups cannot access TBSM. WebSphere cannot determine the correct login if 

the same user ID is defined in more than one user repository. For example, you 

cannot have a user ID tipadmin in both the file registry and also in your 

Netcool/OMNIbus repository. 

When a user signs in to TBSM for the first time, the system looks up the user and 

the users group assignments in the external repository. 

You assign user roles to an individual user or to a user group from the Tivoli 

Integrated Portal console or command-line tools. The user roles control the access 

privileges for each user and user group. 

Manually configuring TBSM for external user repositories 

For detailed information on configuring external user repositories. see the TBSM 

Administrator's guide here: 

Administrator's Guide > Configuring TBSM > Manually configuring TBSM for 

external user repositories 

Servers, failover, and external authentication 

When you configure an external user registry, you need to configure the registry 

for each server in your configuration. For example, if you manually configure an 

LDAP server in a failover environment, you need to configure each of these servers 

to use the LDAP server: 

1. Primary Dashboard server 

2. Backup Dashboard server 

3. Primary Data server 

4. Backup Data server 

Planning 27

Secure Sign-On and LDAP with other applications 

If you configure Single Sign On between TBSM, and IBM Tivoli Change and 

Configuration Management Database (CCMDB) and Tivoli Monitoring, the, 

wasadmin user must not be an LDAP user. If the wasadmin user is in LDAP, you 

cannot configure the WebSphere Application Server for TBSM. 

Uninstalling TBSM and the user registry 

If for any reason you need to uninstall TBSM or Netcool/Impact, do not uninstall 

the external registry, unless you are sure no other applications need that user 

registry. The TBSM Data server, Dashboard server, and Netcool/Impact servers can 

all use the same user registry. For example, if you use a Netcool/OMNIbus 

ObjectServer as your user registry for a TBSM dashboard server and 

Netcool/Impact, you will disable Netcool/Impact if you uninstall the ObjectServer 

when you uninstall a TBSM server. Use the same caution if you use an LDAP 

server as your user registry. 

Managing Netcool/OMNIbus events 

If you are using another user registry such as LDAP, you do not need to set up the 

Netcool/OMNIbus ObjectServer as an external user registry to enable users to 

manage events. You cannot have the same user in two user registries, but you can 

add users to the ObjectServer without configuring it as an external user registry. 

If you want to enable a user to manage ObjectServer events from Tivoli Integrated 

Portal, you must create a matching user in the ObjectServer that is configured for 

TBSM. The user names must match exactly in both the external user registry and 

in the ObjectServer. The ObjectServer user needs to have privileges equivalent to 

the default Normal user group in Netcool/OMNIbus. 

For example, if you have a user named jdoe1 in your LDAP user registry and 

jdoe1 needs to manage ObjectServer events, you also need to have a user named 

jdoe1 in your ObjectServer. 

Use the Netcool Suite Administrator tool to create users for your ObjectServer. For 

more information on creating ObjectServer users, see Using Netcool/OMNIbus 

Administrator to configure ObjectServers in the information center for your version of 

Netcool/OMNIbus at:. 

http://www.ibm.com/developerworks/wikis/display/tivolidoccentral/OMNIbus 

Dashboard server LDAP configuration 

If you want to use an LDAP repository, select the file-based repository option 

during the installation, and manually configure TBSM dashboard server to use an 

LDAP repository. 



“Installing the Dashboard server component” on page 79 

You can use the installation program to install only the Dashboard server 

component. This installation is useful in a production environment, where you 

want to install the Dashboard server component on a separate system from the 

other IBM Tivoli Business Service Manager (TBSM) components. 

Data server LDAP configuration 

If you selected the file-based repository option during the installation, you can 

manually configure TBSM data server to use an LDAP repository. 


“Installing the Data Server component” on page 64 





Netcool/OMNIbus user registry 

If you want to use Netcool/OMNIbusObjectServer as your external user registry, 

you can install it from the IBM Tivoli Business Service Manager installer. If you are 

familiar with the ObjectServer as a user registry, you may want to use this option. 

You can configure ObjectServer as your external user registry from the TBSM 

installer. The installer prompts you for the ObjectServer information. 


manually configure TBSM Data and Dashboard servers to use the ObjectServer 

repository. 

Use Netcool/OMNIBus to access LDAP server 

You can configure the Netcool/OMNIbusObjectServer to use an LDAP server as 

external user registry. If you are familiar with using LDAP as an external 

repository for an ObjectServer, you may want to use this option. 

In this configuration, you configure your TBSM data and dashboard servers to use 

the ObjectServer as your user registry. 

In Netcool/OMNIbus, you configure the Pluggable Authentication Module (PAM) 

for the LDAP server you want to access. When the ObjectServer is configured for 

LDAP, TBSM has access to LDAP data through the connection with the 

ObjectServer. The Websphere Application Server component of TBSM sees only a 

single authentication source. 

Planning 29

Figure 2. Netcool/OMNIBus using LDAP server as user registry for TBSM 

See the Netcool/OMNIBus information center for more information: 

http://www.ibm.com/developerworks/wikis/display/tivolidoccentral/OMNIbus 

Multiple user registry warnings 

It is possible to use multiple user registries for a given TBSM server, but this 

method can cause authentication errors if you have the same user or user group in 

multiple user registries. 

You can use more than one LDAP server or a combination of LDAP servers and a 

Netcool/OMNIbus ObjectServer. If you have multiple user registries, each user 

registry must have a unique set of users and user groups. The set of users and 

groups has to be unique across all repositories you configure for TBSM. That is, 

you cannot have the same user in two different user registries. 

For example, if the user jdoe exists in two separate LDAP user registries (or in 

LDAP and an ObjectServer), the user jdoe cannot log in to TBSM or any other 

application installed in your Tivoli Integrated Portal instance. 

Similarly, if you have a user group called managers in two separate user registries, 

users from in this group cannot authenticate to TBSM. Each registry's user group 

needs to have a unique set of users and these users need to be in the same registry 

as the user group. 

Tivoli Monitoring and Change and Configuration Management 

Database user warning 

If you set up a single user registry for TBSM, Tivoli Monitoring, and the Tivoli 

Change and Configuration Management Database (CCMDB), do not put special 

users such as tipadmin or wasadmin in the LDAP or Netcool/OMNIbus user 

registries. These users need to be authenticated within the application and the 

applications do not function if you put these users in an external user registry. 

For example, if you have the wasadmin user in both CCMDB file-based repository 

and in LDAP, the Websphere Application Server cannot authenticate the wasadmin 

user. 


TBSM users, user groups, and roles 

IBM Tivoli Business Service Manager includes predefined users and user groups. 

Each of these groups assigns certain roles to members of the group. 

Users and user groups 

Two users, tbsmadmin and tbsmuser, are created by TBSM when it is installed. The 

default password for these users is the same as the password that you specified for 

tipadmin during the installation of TBSM. Use these users or tipadmin to log in to 

TBSM for the first time. 

Important: The default login tipadmin is not defined in external repositories, such 

as LDAP or Netcool/OMNIbus, even though this default login is created during 

installation when an external repository is specified. The default login tipadmin is 

not included in any user groups when these groups are created on the external 

repository during installation. 

Users with a blank password cannot log in to the TBSM Dashboard server. The 

default password for the OMNIbus ObjectServer root user is null; therefore, if you 

want to log in as root and you have ObjectServer authority, you must specify a 

non-null password for the root user in the ObjectServer. If you need to change the 

ObjectServer password, use the procedure Configuring TBSM > Changing the TBSM 

configuration > Changing the Netcool/OMNIbus ObjectServer password or user ID. 

The TBSM users and groups are created in the repository that you select during 

the installation for an advanced installation or in the Netcool/OMNIbus repository 

during a simple installation. For more information, see the TBSM Installation Guide. 

You can assign users to the following predefined groups to define their level of 

access and authority in TBSM: 

tbsmAdmins 

Use this group for administrators. The roles assigned to this user group 

enable the group members to view and modify all TBSM objects in the 

graphical user interface (GUI). 

tbsmUsers 

Use this group for users who need to view all templates that are defined in 

the model. 

tbsmViewAllServicesUsers 

Use this group for users who only need to view all services that are 

defined in the model. 

tbsmReadOnly 

Use this group for users who you want to have only read-only access. By 

default, roles are assigned to this group that provide view-only capabilities. 

Users assigned to this group are restricted to the Service Availability page. 

These users cannot access administrative tasks. 

By default, the tbsmadmin is assigned to the tbsmAdmins group and also to the 

WebGUI Netcool_OMNIbus_Admin group. The tbsmuser is assigned to the tbsmUsers 

group and also to the WebGUI Netcool_OMNIbus_Users group. If you perform an 

advanced installation and select the file registry as the file repository, the tipadmin 

user is also added to the tbsmAdmins, WebGUI Netcool_OMNIbus_Admin, and 

Netcool_OMNIbus_Users groups. 

Planning 31

You can also manage user and group permissions for each service or service 

template in the TBSM GUI. For more information, see the TBSM Service 

Configuration Guide. 

For information about changing the default service and template privileges for 

users and groups, see Modifying the default service and template privileges in the 

Administrator's Guide. 

User roles 

You can assign any of the following roles to users or groups. These roles specify 

the authority that users or groups have to view, modify, or administer TBSM 

settings. 

Table 1. TBSM user roles 

Role Authority assigned to user or group 

tbsmAdminUser Access to both the Service Availability and Service Administration 

pages in TBSM 

tbsmSLAChartViewVisible Assigned automatically by TBSM to the necessary users and groups. 

This role does not display in the list roles for users and groups. Do 

not assign this role manually. 

tbsmViewRawEvents View ObjectServer event lists. 

Note: This role is no longer used. 

tbsmAVSaveCanvasLayoutForGroup Create a custom canvas for a user group. 

tbsmAVSaveCanvasLayoutForUser Create a custom canvas for a user. 

tbsmTemplateAdmin Add, edit, delete, or view templates. 

tbsmServiceAdmin Add, edit, delete, or view services. 

tbsmCreateTemplate Add, edit, or view templates. 

tbsmEditTemplate Edit or view templates. 

tbsmViewTemplate View templates. 

tbsmCreateService Add or view services. 

tbsmEditService Edit or view services. 

tbsmViewService View services. 

tbsmDataSourceAdmin Add, edit, delete, or view data sources. 

tbsmCreateDataSource Add, edit, or view data sources. 

tbsmEditDataSource Edit or view data sources. 

tbsmViewDataSource View data sources. 

tbsmDataFetcherAdmin Add, edit, delete, or view data fetchers. 

tbsmCreateDataFetcher Add, edit, or view data fetchers. 

tbsmEditDataFetcher Edit or view data fetchers. 

tbsmViewDataFetcher View data fetchers. 

tbsmChartAdmin Add, edit, delete, or view charts. 

tbsmCreateChart Add, edit, or view charts. 

tbsmEditChart Edit or view charts. 

tbsmViewChart View charts. 


Table 1. TBSM user roles (continued) 

Role Authority assigned to user or group 

tbsmViewDefinitionAdmin Edit or delete view definitions. 

Note: The default view definitions are read-only and cannot be edited 

or deleted. 

tbsmLaunchISMServiceReportViewer Use the ISM Service Report Viewer menu item in the pop-up menu 

for a service; this item is disabled for users who do not have this role 

assigned. 

tbsmReadOnlyUser Access to the Service Availability page only. This role is assigned by 

default to the tbsmReadOnly group; users assigned to that group 

automatically have this role. 

DB2 Installation 

TBSM requires IBM DB2 As is good practice with most software products, the 

latest maintenance should be applied. The TBSM databases may be installed on an 

existing DB2 instance or a new one can be created for the sole purpose of TBSM's 

use. 

If you choose to create a failover TBSM solution, you should place the TBSM 

database into a high availability DB2 setup. For more information see the Failover 

setup section. 

The TBSM database will need to be housed on a properly sized system. See the 

hardware requirements in this guide about TBSM machine requirements. 

Disk space needs are primarily a function of the number of service instances 

known to the TBSM Data Server and to the resource, relationship, and attribute 

information stored in the TBSM Service Component Registry. 

You should consider an install of the TBSM schema into a test environment for 

purposes of familiarizing yourself with the details of the TBSM database setup. In 

most environments this will not be necessary. 




Reports at: 






DB2 Database Setup 

TBSM provides an installation image that simplifies the setup and configuration of 

the TBSM database within the installed DB2 instance. When executing this part of 

the TBSM installation, you must be running as a DB2 user id with the full 

authority required for creating databases and all related artifacts such as buffer 

pools, table spaces, tables, and indexes. The installation application will allow you 

Planning 33

to immediately setup the database using the interface or produce setup scripts to 

disk that can be reviewed and executed at a later time. The setup will include the 

creation of all necessary database objects including databases, table spaces, 

schemas, buffer pools, tables and indexes. 

At this point, you must determine the user that the runtime TBSM Data Server will 

use to the connect to the DB2 database. Although it may be the same userid used 

to create the database setup, the primary requirement is to allow the runtime 

TBSM Data Server administrative access to the TBSM database. TBSM Service 

Component Repository is a intensive user of the database and it requires the ability 

to insert, update, drop and create indexes, and alter all TBSM database objects as 

well as run administrative commands through its SQL connection. For example, 

the SCR will frequently update table statistics by executing the following command 

- 

CALL SYSPROC.ADMIN_CMD(’RUNSTATS ON TABLE TBSMSCR.cdm_classIds AND INDEXES 

ALL’); 

This userid is required during the installation of the TBSM Data Server and Service 

Component Repository. 

Database Disk Space Requirements 

During the database installation procedure you select a small, medium, or large 

setting that best describes the environment – in terms of number of resources - that 

Tivoli Business Service Manager will manage. Follow these available disk space 

guidelines for TBSM data, depending on your choice. 

v Small - 3G of disk space 

v Medium – 6G of disk space 

v Large – 10G of disk space 

During the life of the database, monitor the database for resource usage, especially 

when service models are undergoing significant changes. 

In addition to data requirements, TBSM requires database log space during 

operations. The default log settings for TBSM database are described in this table. 

Table 2. Default log file setting for the TBSM database 

Description Property setting 

log file size (4-KB) (LOGFILSIZ) = 32000 

Number of primary log (LOGPRIMARY) = 6 

files 

Number of secondary log (LOGSECOND) = 10 

files 

The estimate for the required default log space is determined with the formula: (6 

+ 10) * 4-KB * 32000 = 2-GB log space 

Some TBSM operations require extra logs, and in these cases the number of 

secondary logs is increased. For example, the Discovery Library Toolkit can require 

a secondary log number of up to 100. With these log settings, the log space 

requirement is 11.5-GB of disk space. 


DB2 Administration and Maintenance 

One of the advantages of TBSM's move to using DB2 is that database 

administration and maintenance activities can be consolidated with other Tivoli 

product's that also use DB2 as its primary datastore. Consolidating database 

management can create a cost-efficient use of the skills required for common 

database administrative tasks such as starting and stopping a particular database, 

monitoring the health of the database, tuning, backing up and restoring, and 

maintenance of the database. 

This guide will not attempt to document DB2 procedures to accomplish database 

administrative tasks since extensive documentation is available through IBM and is 

accessed via the internet. However, it is recommended that the TBSM 

administrator become familiar with basic DB2 concepts and administrative tasks. 

An overview of DB2 administration concepts is presented at the IBM DB2 Version 

9.7 for Linux, UNIX, and Windows Information Center web site. You can access a 

complete set of documentation at http://publib.boulder.ibm.com/infocenter/ 

db2luw/v9r7/index.jsp . The Database administration section discusses essential 

administration concepts and tasks and is well worth a review. 

As is generally recommended with the latter releases of DB2, TBSM recommends 

the use of DB2's Automatic Maintenance features for many of the maintenance and 

tuning functions of the relational database. The topics which follow discuss some 

key points about how TBSM uses the DB2 database. 

Database Schema Descriptions 

Since the TBSM database setup program, will optionally set up one to four 

databases, it is best to discuss the purposes of the database through the schemas 

that are created. For a simple install a single database holds all of the following 

schemas. 

v The primary schemas will be the most demanding since they house the primary 

data typically associated with TBSM. 

v TBSMBASE 

This schema consists of the tables that are associated with the TBSM Data Server 

that contain information that includes service instance data as well as template and 

rule data. The size and volatility of these tables are most effected by the number of 

service instances that the TBSM Data Server persists and secondarily the number 

of templates and rules defined for those instances. Data access patterns are rather 

simple however in environments where services are frequently updated or 

fluctuate in number, the larger tables in this schema can quickly become 

fragmented. 

v TBSMSCR 

This schema consists of the tables that contain information imported into the TBSM 

Service Component Registry via TADDM, iDML books, or the SCR API. The 

demands on these tables are significant due to the nature of the processing of the 

Service Component Registry that is detailed in the TBSM Customization Guide. Data 

access patterns for the TBSMSCR and TBSMSAxy schemas are advanced and are 

most sensitive to database tuning. 

v TBSMUDF 

TBSM user defined functions (UDF) are defined within this schema. TBSM UDFs 

are an addition to the existing built-in DB2 functions to support TBSM-unique 

Planning 35

functions. The functions are implemented JAVA UDFs and are by default 

configured to run in fenced mode. See DB2 documentation for details concerning 

UDFs. 

v TBSMSAxy 

A set of schemas starting with 'TBSMSA' and ending with a combination of two 

characters, the first being the number of 1 or 2 and the second being one of the 

following characters T, B, A, and G, make up the SCR staging tables used for 

importing data. Multiple schemas provide each SCR import mechanism its own 

stage area as indicated by the character value. The numerical value is a grouping 

mechanism that is used in failover configurations to allow each SCR server to have 

its own staging tables to minimize the chances of accidental corruption of data 

during unusual failover scenarios. These tables are very volatile since at any point 

large amounts of data waiting to be imported could be present. However, once the 

data in the staging tables has be reconciled with information in the TBSMSCR 

schema, the data it contains is no longer relevant. At the beginning of each import 

process, all data in the appropriate staging table is deleted. 

v TBSM Configuration Artifact Schema 

v TBSMCONFIG 

This schema contains the artifact datastore used by the TBSM Import/Export 

feature described in the TBSM Administration Guide In general, the demands on 

these tables are minimal since they hold configuration artifacts that are accessed 

infrequently. Care should be taken to not accidentally overlay an older version of 

the artifacts it contains during a database restore process. 

v TBSM Schemas related to Metric History Collection and the Time Window 

Analyzer 

v TBSMHISTORY 

This schema houses metrics collected for the Time Window Analyzer portlet and 

are referred to as short-term history metrics. See the TBSM's Administrator's Guide 

-> TBSM Metric Collection for details on the feature. Specific database size 

considerations can be found in the Important metric data store issues section. Under 

heavy load, the tables in this schema will have large number of inserts, queries to 

support the Time Window Analyzer views, and deletes as a result of a pruning 

process. 

v TWAMARKER 

This schema also houses marker data that is related to the Time Window Analyzer 

portlet. See the TBSM's Administrator's Guide -> TBSM Marker Repository Service for 

details on the feature. Specific database size considerations can be found in the 

Important issues concerning the marker data store section. Access patterns are similar 

to the TWAHISTORY schema but with significantly less volume. 

v Other Schemas 

v EVENTRULES 

– This schema contains rules collected to support the Tivoli Impact EIC feature. 

This schema should have minimal maintenance issues considering the 

relatively small amount of data it contains. 

v TBSMDEMO 

– This schema contains tables that are referenced in the TBSM documentation 

for product education purposes. 


Other Important Considerations 

v Since TBSM relies on its DB2 database, the TBSM Administrator should have 

access to the database via a database query tool such as the DB2 Control Center 

or other available database query tools. TBSM does not provide any type of 

generic query mechanism for administrative or support purposes. 

v Though previous releases of TBSM provided a command line tool for resetting 

the TBSM database back to its state at installation, a similar task is accomplished 

through a best practice procedure. Once you have completed an initial install, 

take a backup of the TBSM databases for restore purposes when needed. 

v The Discovery Library Toolkit will frequently update statistics on the TBSMSCR 

schema tables. However, it is recommended that all schema table statistics are 

periodically updated. See the DB2 RUNSTATS command. 

v It is recommended that tables, especially in the TBSMBASE and TBSMSCR 

schemas, are monitored for table fragmentation or a plan is put in place to 

periodically reorganize them using the DB2 REORG function. 

Planning 37


Installing TBSM 

TBSM Launchpad 


This section details a number of installation topics and scenarios. 

The TBSM Launchpad is a graphical user interface (GUI) that launches installation 

of the TBSM system. 

If the launchpad does not open automatically when you insert the DVD or you are 

installing from a downloaded installation package, open the launchpad with the 

command: 

v On Windows systems, right-click on launchpad64.exe and click Run as 

Administrator to start the Launchpad. 

Note: If you insert the DVD, and the Launchpad automatically starts, close the 

Launchpad. Start the Launchpad with the Run as Administrator option. 

v On UNIX systems,./launchpad.sh 

UNIX double-byte language selection: If your machine does not have the 

double-byte code pages installed, the double-byte languages (Simplified Chinese, 

Traditional Chinese, Korean, Japanese) are corrupted in the language selection list. 

This issue is a display problem on the selection list and the TBSM launchpad 

functions normally otherwise. 

The launchpad provides a single mechanism for installing the TBSM product on a 

system. From the launchpad, you can launch the following: 

Welcome 

Welcomes you to the TBSM application with a brief overview. 

Release Information 

Release Notes ® for TBSM 

Systems Requirements 

System requirements for TBSM 

Install DB2 schema 

Install the TBSM database schema on an existing DB2 server. 

Install IBM Tivoli Business Service Manager 6.1.1 

Run the TBSM installation program. 

Install Business Service Manager Agent 

Install the IBM Tivoli Monitoring agent if you have IBM Tivoli Monitoring 

installed and you want to do one or both of the following: 

v Use Tivoli Monitoring to monitor the status of TBSM 

v Use the TBSM Historical Reporting function, which uses the data 

warehouse feature of Tivoli Monitoring to record historical TBSM data. 

Exit Exit the TBSM launchpad. 


Installation types 

Installation order 

When installing the TBSM product, you can select either a simple installation or an 

advanced installation. 

Simple installation 

This installation type is recommended for proof-of-concept. Simple 

installation uses a one-server configuration, and all prerequisite software is 

installed on that server. 

Notes: 

1. You cannot install the Historical Reporting feature. 

2. Advanced installation is recommended for setting up a backup or 

failover environment. 

Advanced installation 

This installation type is recommended for production environments. 

Advanced installation allows for configuration of multiple servers. 

You can also use advanced installation to install TBSM into an existing 

environment. The existing environment must include IBM Tivoli Netcool 

OMNIbus. See “Planning” on page 17 for additional information before 

performing an advanced installation in an existing environment. 

The order in which you install the TBSM components is significant. 

Always install the software features in the following order: 

1. Set up your database schema with the TBSM Database Configuration utility. 

You need an instance of DB2 installed before you can run the Database 

Configuration utility. 

2. IBM Tivoli Netcool OMNIbus 

Note: On Windows systems, if you are going to install 

additional TBSM products, reboot after installing Tivoli Netcool OMNIbus. 

3. IBM Tivoli Business Service Manager Data server and Discovery Library Toolkit 

4. IBM Tivoli Business Service Manager Dashboard server(s) 

5. EIF Probe (optional) 

DB2 schema configuration overview 

The IBM Tivoli Business Service Manager database configuration utility creates the 

files needed to configure the Data Server, Metric Marker, and Metric History 

databases for TBSM. Optionally, the installer can create the schema in DB2 for the 

TBSM databases. 

Prerequisites 

You need to run the database configuration utility on the DB2 host where you 

want to install the TBSM database. The TBSM schema contains several 

user-defined functions (UDF's), and the jar file containing these functions must 

reside on the DB2 host. You need to know the ports for the DB2 instance. 





Reports at: 






For more information on installing and using DB2, see the information center listed 

here for the version you are using: 

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/ 

com.ibm.db2.luw.common.doc/doc/t0021844.html 

If you want to create the TBSM database schema during the installation, you must 

be logged on to the DB2 host as a user who has permissions to create database 

tables (SYSADM or SYSCTRL). Optionally, the installer can create the configuration 

files, and the tbsm_db script can be run to create the tables after the installation. 

Windows command environment: 

On Windows, the installer must be run from a command window 

that has been opened by the DB2 db2cwadmin script. In Windows 2008, if you log 

in as a user other than the Windows Administrator, you must use the DB2 

command window option with the Administrator authority. Adding the user to 

the Windows Administrators group is not sufficient due to Windows 2008 User 

Access Control security functions. From the Windows start panel, click: 

v Start->All Programs->IBM DB2->Command Line Tools->Command Window 

-Adminstrator 

v Or, open a command window and enter the command: db2cwadmin. 

Attention: If you choose DB2 Command Window (DB2CW), to open a command 

window, you will not be executing in a DB2 environment and the installer will fail. 

Restriction: You cannot install TBSM, DB2, or configure the DB2 

databases for TBSM when you are logged in with a user id containing non-English 

characters. DB2 does not recognize a user id with non-English characters, such as 

Russian. For example, the Windows Administrator userid on a Russian operating 

system has Russian characters in the name. Typically, you do not have these 

problems in UNIX because the user names have English characters. 

To install DB2, rename the user id and Administrators group to have English 

characters only. Log in with the renamed Administrator user id. Install DB2 

while logged in with the renamed Administrator id. You also need to run the 

TBSM Database Configuration utility with the same renamed Administrator user 

id. 

You must use the port used for DB2. 



Installing TBSM 41

non-English Administrator id. You must log in with a user id that was originally 



The installer creates the log file .../tbsmdb/logs/db2_stdout.log. This log file 

contains the output from all of the SQL that was executed. If there are any issues 

this log file is very helpful. 

TBSM database user 

The user that TBSM uses to connect to the DB2 database needs access to the TBSM 

database. Although it can be the same user ID used to create the database setup, 

the primary requirement is to allow the runtime TBSM administrator access to the 

TBSM database. TBSM Service Component Registry is an intensive user of the 

database and it requires the ability to insert, update, and alter all TBSM database 

objects as well as run administrative commands through its SQL connection. 

As a best practice, the TBSM administrator needs access to the DB2 database via 

database query tool such as the DB2 Control Center or some other DB query tool 

that supports DB2. The Control Center or other tools are valuable for ongoing 

TBSM maintenance. 

User name restriction: Ensure that the TBSM database user name does not contain 

a hyphen. 

Creating database schema after installation 

The database configuration install utility can create the TBSM schema information 

or just install the files used to create the schema. If you just install the files, you 

use the tbsm_db script after installation to create the schema. It will create the 

TBSM databases, indexes, views, and user-defined functions, and it updates 

specific performance-related DB2 configuration parameters. 

Prior to executing tbsm_db, you can modify the parameters defined in the property 

files located in the tbsmdb/sql directory. A property file exists for each database 

(Data Server, Metric Marker, Metric History, and Demo). The values for the 

property files were set based on the user input during the installation (from the 

graphical user, console, or response file input). After the schema is created, you can 

use DB2 commands to update these configuration parameters and others not 

explicitly updated by the tbsm_db 

script. 

After the TBSM schema is created, you can also use tbsm_db script options to drop 

and recreate the schema. 

Database Checker Utility 

The TBSM Database Checker Utility verifies that the TBSM databases created with 

the Database Configuration utility are ready for use by the TBSM Data server. 

To run the utility on Windows systems: 

1. Change to the directory: \tbsmdb\bin 

The default directory is: 

C:\Program Files\IBM\tivoli\tbsmdb\bin 


2. Enter the command: 

TBSM_Check_DB.bat 

To run the utility on UNIX systems: 

1. Change to the directory: /tbsmdb/bin 

The default directory is: 

opt/IBM/tivoli/tbsmdb/bin 


TBSM_Check_DB.sh 

Follow the prompts to enter required user IDs and passwords, and to specify the 

databases to be checked. 

Note: Passwords are not hidden when entered. 

Example:: Example of the command that is run in Windows. 

C:\ibm\tivoli\tbsmdb\bin>TBSM_Check_DB.bat 

Calling ant script tbsmDatabaseChecker.xml to check the databases 

[input] Enter administrative database userid. 

This user should have SYSADMIN or SECADMIN authority and will be used 

to check authority of data server userid: 

Administrator 

[input] Enter the password for administrative database userid 

Administrator: nothidden 

[input] Enter database userid that will be used to connect the database 

from the TBSM data server: [Administrator] tbsmdataserveruser 

[input] Enter the password for data server database userid 

tbsmdataserveruser: [nothidden] dspassword 

[input] Enter database(s) to be checked: 

[input] S = Service Model 

[input] H = Metric History 

[input] M = Metric Marker 

[input] [ALL] 

Running simple DB2 schema configuration 

In a simple installation, the IBM Tivoli Business Service Manager Database 

Configuration Utility configures the DB2 schema for theTBSM Data Server, Metric 

Marker, and Metric History databases in a single database. 

Before you begin 

You need to run the database configuration utility on the DB2 host where you 

want to install the TBSM database. 

This procedure shows how to run the configuration utility from the Launchpad. 

You can also run the configuration utility from the command line. The 

configuration utility is located in the TBSM installation image at: 

/platform/DbConfig/setup-dbconfig-platform.sh/exe 

For example: 

v On Windows the command is: \windows\DbConfig\setup-dbconfig-windows.exe 

v On LINUX systems, the command is: /linux/DbConfig/setup-dbconfiglinux.bin 

Installing TBSM 43

Install Folder 

The folder where you want to store the TBSM DB2 schema configuration 

files. By default, this is set to the following locations: 

/opt/IBM/tivoli/tbsmdb 

C:\Program Files\IBM\tivoli\tbsmdb 

Directory restrictions: The directory names have these restrictions: 

v Do not specify an installation directory path that includes parenthesis, 

such as c:\Program Files (x86). The install may succeed with this path, 

but other utilities and components will fail when you attempt to run the 

application using a path with parenthesis. 

v Do not choose an installation directory name that contains an accent 

character (for example, . à, é, Ñ, ô) . Otherwise, the installation fails. 

Database name 

The database used for the TBSM Data Server, Metric Marker, and Metric 

History databases. By default, the database name is TBSM. 

Should the installer create the schema for this database? 

Yes, create the schema, including the tables, tablespaces, and views. 

If you select this option, you must be logged in as a user that has 

permission to create and drop tables in the DB2 instance. 

. 

On Windows systems, you also need to run the 

Launchpad or DB2 Schema utility from the db2cwadmin window: 

1. Open a Windows command prompt. 

2. Enter the command: db2cwadmin and a DB2 command window 

opens. 

3. Run either the Launchpad or the Schema configuration utility 

from the DB2 command window: 

To run the Launchpad, change to install image root directory 

and enter the command: launchpad.exe 

To run the schema configuration utility, change to the install 

image directory: windows\DbConfig and run the command: 

setup-dbconfig-windows.exe 

No, complete the installation and the schema will be created at a later 

time. This option creates all the configuration files needed to create the 

TBSM schema in the database. When you select this option, you 

need to use the tbsm_db command to create the TBSM schema, 

after the schema configuration utility has completed. 

Procedure 

1. Insert the TBSM installation media (DVD) into the appropriate computer. The 

TBSM launchpad opens. If the launchpad does not open automatically when 

you insert the DVD or you are installing from a downloaded installation 

package, open the launchpad with the command: 




Note: If you insert the DVD, and the Launchpad automatically starts, close 

the Launchpad. Start the Launchpad with the Run as Administrator option. 


2. On Windows systems, you need to run the Launchpad or DB2 

Schema utility from the db2cwadmin window as described in Before you 

begin. 

3. Select the language that you want to use for the installation, and then click 

OK. Only the languages supported by your system will appear in the list of 

available languages. 


double-byte code pages installed, the double-byte languages (Simplified 

Chinese, Traditional Chinese, Korean, Japanese) will be corrupted in the 

language selection list. This is a display problem on the selection list and the 

TBSM launchpad functions normally otherwise. 

4. In the Welcome window, click Next. 

5. In the Software License Agreement window, click I accept both the IBM and 

non-IBM terms in the license agreement, and then click Next. 

6. In the Select Installation Directory window, specify the installation directory. 

7. In the Installation Type window, click Simple and then click Next. 

8. Specify the database name you want. 

9. Select whether you want to create the schema in the database instance or if 

you just want install the configuration files on the host, and create the schema 

at a later time and click Next. 

10. Review the Pre-Install Summary and click Install. 

Advanced DB2 configuration 

This topic describes the information you need to run Advanced DB2 configuration 

utility. 

To configure the databases: 

v Review DB2 configuration settings 

v Run the Advanced DB2 configuration utility 

Advanced DB2 configuration settings 

Specify the connection information for the database 

Purpose 

For each database you install, you need to supply the information described in this 

topic. 

You are prompted for this information for the following databases used by TBSM. 

The information is saved in the following properties files. 

tbsmdb\sql\tbsm_db.properties 

tbsmdb\sql\tbsmudf_db.properties 

Data server database 

This is the primary database for TBSM service configuration. The 

configuration information for this database is stored in the files: 

Installing TBSM 45

Metric markers database 

The Time Window Analyzer metric marker database. The configuration 

information for this database is stored in the file: 

tbsmdb\sql\tbsmmark_db.properties 

Metric history database 

The Time Window Analyzer metric history database. The configuration 

information for this database is stored in the file: 

tbsmdb\sql\tbsmhist_db.properties 

Choices 

You can choose from the following options: 

Database Name 

The name of the database. 

By default, this is set to TBSM for all the databases, except for the Metric 

History database, which has a default name of TBSMHIST. 

Database Hostname or IP address 

The host name of the system where the DB2 is installed. 

By default, this is set to the host name of the local system. 

Database Port 

The database port number for DB2. The default is 50000. 

Database User ID 

The database user ID for DB2. This user must have permission to add and 

drop database tables. 

Database password 

Database users password. Confirm this in the Confirm password field. 

Should the installer create the schema for this database 

v If you select Yes, the installer configures the tables, tablespaces, and 

views in your DB2 instance. 

v If you select No, the installer creates the configuration files for the 

tables, tablespaces, and views, and you install the configuration on your 

DB2 instance with the tbsm_db command. 

Database path 

The path used to create the database. The value or a null value 

specifies the default database path specified by the database manager 

configuration. 

If you want to use multiple paths, the first path must contain the database, 

and the paths must be separated by commas. 

Table space configuration 

Specify the 16K and 32K table space names for the database. The default 

names are: 

Table 3. Default table space names 

Database Default table space names 

Data server TBSM16KTS and TBSM32KTS. 

Metric History THM16KTS 


Buffer pool configuration 

Specify the 16K and 32K (Data server only) buffer pool names and sizes for 

the database. 

Table 4. Default buffer pool names 

Database Default buffer pool names 

Data server TBSM16KBP and TBSM32KBP. 

Metric History THM16KBP 

Demo/Sample DEM16KBP 

Transaction log configuration 

Specify the transaction log configuration for the database. This includes the 

log buffer size, log file, size, number of primary logs, number of secondary 

logs, and the log file path. The default values will be based on the number 

of services you will have. You can view the default values for medium size 

installations (between 5000 and 20000 services) in the response file, 

dbconfig-installer.properties). 

If the transaction log file size is too small, an error is generated: 

SQL0964C The transaction log for the database is full. SQLSTATE=57011 

This error is displayed in the TBSM trace log file or the Discovery Library 

Toolkit log. To update the transaction log size to an appropriate value, 

open the DB2 command window using the db2cmd command and execute 

the command: 

UPDATE DATABASE CONFIGURATION FOR TBSM USING LOGSECOND 

where is the new transaction log file size that you require. 

To further optimize the configuration of the database, please estimate the 

expected number of service instances that will be managed 

The database is configured according the size you specify here. 

Table 5. Service instance estimates 

Size 

Number of 

services Disk space reserve 

Large More than 

25,000 

10 GB 

Medium 5,000 to 25,000 6 GB 

Small Up to 5,000 3 GB 

Running Advanced DB2 schema configuration utility 

The Database Configuration Utility enables you to configure the DB2 schema for 

the Data Server, Metric Marker, and Metric History database in a separate 

databases. 


Before you start the database configuration utility, read the Advanced DB2 

Configuration settings topic for the settings you specify for the DB2 schema 


Installing TBSM 47


This procedure shows how to run the configuration utility from the Launchpad. 

You can also run the configuration utility from the command line. The 

configuration utility is located in the TBSM installation image at: 

/platform/DbConfig/setup-dbconfig-platform.sh/exe 

For example: 

v On Windows the command is: \windows\DbConfig\setup-dbconfig-windows.exe 

v On LINUX systems, the command is: /linux/DbConfig/setup-dbconfiglinux.bin 

Procedure 










2. In the Welcome window task list, click Install DB2 Schema. 

3. In the Install DB2 Schema window, click Run the DB2 schema installation 

program. 









5. In the Introduction windows, click Next. 



7. In the Where Would You Like to Install field, type the fully qualified 

directory where you want to install TBSM. 

By default, this is set to the following locations: 

48 IBM Tivoli Business Service Manager: Installation Guide 

/opt/IBM/tivoli 

C:\Program Files\IBM\tivoli 


v Do not specify an installation directory path that includes parenthesis, such 

as c:\Program Files (x86). The install may succeed with this path, but 

other utilities and components will fail when you attempt to run the 



character (for example, . à, é, Ñ, ô) . Otherwise, the installation fails.

Attention: If you are installing TBSM using an existing Tivoli Integrated 

Portal, two radio buttons appear in the Installation Directory panel. You must 

click the second radio button and select the installation directory from the list. 

If you do not perform this action, the installation will fail. 

Click Next. 

8. In the Installation Type window, click Advanced and then click Next. 

9. Specify the database name and the other advance option parameters for the 

Data Server, Metric Marker, Metric History, and Demo databases. 

10. Select whether you want to create the schema in the database instance or if 

you just want install the configuration files on the host, and create the schema 

at a later time and click Next. 

11. Review the Pre-Install Summary and click Install. 

12. Click Finish when done. 

Creating database schema after installation 

If you decide to create the TBSM schema after you run the TBSM database 

configuration utility, you need to use the tbsm_db command to install the schema 

in your database instance. 


Before you run the tbsm_db command, you need to install the TBSM database 

configuration files with the TBSM database configuration utility and you need to 

be logged in as a user who has permissions to create and drop tables in your 

database instance. 

The tbsm_db command is in the tbsmdb/bin directory. For help, run the command: 

tbsm_db -? 


There are two types of commands you need to run with the tbsm_db script, one is 

for creating the databases and one is for creating the schema. The number of times 

you need to run the tbsm_db script depends on whether each of the TBSM 

databases resides within a single database or each TBSM database has its own 

separate database. The schema creation function of tbsm_db will be run once for 

each of the TBSM database schemas. 

Procedure 

1. To run the script, you need to have the correct permissions set, depending on 

your operating system. 

v Open a DB2 command window with the command: 

db2cwadmin. 

v Log in as a user with SYSADM or SYSCTRL authority. 

2. Create the database with the command: 

tbsm_db -s database -c 

The database is the database you want to install in DB2. 

Table 6. TBSM database values 

Database Value 

Data server ds 

Installing TBSM 49

Installing TBSM interactively 

Table 6. TBSM database values (continued) 


Metric marker tm 

Metric history mh 

Demo de 

For example, if you want to install the TBSM Data server database, the 

command is: 

tbsm_db -s ds -c 

Run this command for each database you created with the TBSM Database 

Configuration utility. 

3. Create the schema with the command: 

tbsm_db -s database_schema -fc-Udb_userid -P db_pw 

The database_schema is the database schema you want to install in DB2. 

Table 7. TBSM database schema values 


Data server ds 

Metric marker tm 

Metric history mh 

Demo de 

For example, to create the metric marker schema, the command is: 

tbsm_db -s tm -f c -U dbadmin -P dbapass123 

When the command completes, you see the message: 

DB20000I The SQL command completed successfully. 

Run this command for each database schema you created with the TBSM 

Database Configuration utility. 

TBSM has an installation program that you can use to install the application 

interactively. You can select either a simple or an advanced installation type. 

Performing a simple installation 

When you perform a simple installation, the IBM Tivoli Netcool OMNIbus 

ObjectServer, the IBM Tivoli Business Service Manager(TBSM) Data Server, and 

TBSM Dashboard Server components are installed on the same system. The Tivoli 

Event Integration Facility probe features are not installed if you use the simple 

installation. You cannot perform a simple installation if an IBM Tivoli Business 

Service Manager component was previously installed on the system. 


If you are installing TBSM using an existing Tivoli Integrated Portal, you should 

back up the DE database before the installation process makes any changes to your 

system. If you back up the database, you will have the original database 

information in the event that you need to restore the database. The commands for 

backing up the database and restoring the database are de_backupdb.cmd and 

de_restoredb.cmd. 


Note: 

v Before performing an installation on UNIX following an uninstall procedure, the 

OMNIbus process might still be running. Use the ps -ef | grep omni command 

to locate the process. End the process that appears. 

Before you start the installation, you need to know this information. 

TBSM Database Information 

For each TBSM database you need to know the name, host, port, and user 

information. This database must be configured with the TBSM database 

configuration utility before you install TBSM. 

In many cases, all the TBSM databases share the same configuration. By 

default, the option Use the same database as the TBSM Data Server is 

selected for the Metric Marker and Metric History databases. If separate 

databases have been configured, de-select this option and enter the 

information for each database. 

The Data Server database stores information such as services, templates, 

and the service component repository. 

The Metric Marker database stores metric markers configured for 

overlaying historical values in the Time Window Analyzer. 

The Metric History database stores the history of values for metrics that 

are collected for the Time Window Analyzer. 

You need to know this information for each database. 

Database name 

The name for the database. The default is TBSM. 

Database Hostname 

The host name where the Data Server database is installed. 

Database port Number 

The default is 50000. 

Use the port number for the instance of DB2 where the TBSM 

database was configured. 

Important: The TBSM installation program does not check if the 

port number is valid. As a result, you must validate the port 

number manually. 

Database Username 

The name of a user that has permission to update tables in the 

database. 


The database user password. 

Confirm Database password 

Confirm the database user password. 

Tivoli Integrated Portal Information 

The user and password information for the administrative user who creates 

the Tivoli Integrated Portal profile in the Websphere Application Server. 

The default user name is tipadmin. 

Installing TBSM 51

Procedure 










2. Click Install IBM Tivoli Business Service Manager in the navigation panel 

and then click Run the Tivoli Business Service Manager Installation 

Program. The installation process begins. 












6. Optional: The Installation Program checks if the Deployment Engine is 

installed on the system, in the Deployment Engine Initialization window. The 

Deployment Engine is installed if needed and the Installation Program 

automatically proceeds to the next step. The Installation Program also checks 

if the Deployment Engine (DE) version installed on the machine is older than 

the one the installation image. The installer prompts for a directory to backup 

the old DE before you upgrade to the newer version. 

7. In the Select Installation Directory window, specify the installation directory: 

a. In the Where Would You Like to Install field, type the fully qualified 

directory where you want to install TBSM. By default, this is set to the 

following locations: 






such as c:\Program Files (x86). The install may succeed with this 

path, but other utilities and components will fail when you attempt to 

run the application using a path with parenthesis. 




Portal, two radio buttons appear in the Installation Directory panel. You 

must click the second radio button and select the installation directory 

from the list. If you do not perform this action, the installation will fail.

. Click Next. 

8. In the Installation Type window, click Simple, and then click Next. 

9. In the TBSM Data Server Database Information window, specify the database 

information for the data server. 

10. In the TBSM Metric Marker Information window, specify the database 

information for the Metric Markers database. 

By default, the option Use the same database as the TBSM Data Server is 

selected for the Metric Marker database. If the database is the same, click Next 

to apply these settings. 

If a separate database was configured for Metric Markers, de-select this 

option, enter the information for the database, and click Next. 

11. In the TBSM Metric History Information window, specify the database 

information for the Metric History database. 

By default, the option Use the same database as the TBSM Data Server is 

selected for the Metric History database. If the database is the same, click Next 

to apply these settings. 

If a separate database was configured for Metric History, de-select this option, 

enter the information for the database, and click Next. 

12. In the TIP Information window, specify information about the Websphere 

Application Server account that is used for the Tivoli Integrated Portal profile 

and click Next. 

13. In the Data Source and Database Selections window, specify the data source 

information for the Discovery Library Toolkit. For information on these 

settings, see Discover Library Toolkit configuration. 

14. Optional: If you are installing to an existing directory (reuse scenario), the 

installation program prompts for the directory to backup the applications 

inside the existing directory. 

15. In the Pre-Installation Summary window, review the details of the installation, 

and then click Next. The installation begins, and an indicator shows the 

progress of the installation. 

16. In the Install Complete window, click Done. On Windows, when a successful 

install has been completed, the default browser is launched with the URL set 

to the Tivoli Integrated Portal logon panel (Dashboard server only). On UNIX, 

no browser is launched. On all platforms, the URL is displayed on the 

successful installation summary screen. 

Discovery Library Toolkit information 

Specify information about the Discovery Library Toolkit installation in these 

prompts. 

Purpose 

Use the Discovery Library Toolkit to import data from: 

v Tivoli Application Dependency Discovery Manager 7.1.2 or later 

v IBM common data model Discovery Library (IDML) books 

v alternate name space books 

v Discovery Library toolkit API 

v Autopopulation rules. 

During the simple installation you can choose whether Tivoli Application 

Dependency Discovery Manager and/or books will be accepted. The API is 

enabled by default, but can be disabled after installation through a property. 

Installing TBSM 53

TADDM warning: If you are installing the Discovery Library Toolkit with a Tivoli 

Application Dependency Discovery Manager server as a data source, you need to 

make sure that you have only one Discovery Library Toolkit connection to the 

Tivoli Application Dependency Discovery Manager server. Otherwise, you will get 

incorrect data from the Tivoli Application Dependency Discovery Manager . 

Note: If there is already a TBSM Discovery Library toolkit installed on this 

machine and it is installed into a non-standard location, this copy of the toolkit 

should be shutdown. A non-standard location is defined as not being in 

../tivoli/tbsm/XMLtoolkit. If a copy already resides at this location, the TBSM 

Data server install will skip the toolkit portion of the installation. 

You also specify information to enable the toolkit to export Discovery Library 

books from TBSM. 

Choices 

You need to specify the data source information for the toolkit. 

Please select the data source(s) that will be used. 

Discovery Library books 

The toolkit searches a directory you specify for new Discovery 

Library books (DLA files) and processes any files in that directory. 

Tivoli Application Dependency Discovery Manager 

If you are going to use Tivoli Application Dependency Discovery 

Manager as the source for your data, select this option. If you 

select this option, the installer prompts you for the server 

connection information. 

Enter the naming service RMI registry port 

The port number for the naming server RMI registry port. 


Discovery Library Book Import Configuration 

Configuration of the book import file system. Enter the directory name that 

the toolkit will monitor for new book files. When a new book file is 

detected in the directory you specify, the toolkit reads and processes the 

file. 

Default: $TBSM_HOME/tbsm/discovery/dlbooks 

TADDM Connectivity Configuation 

If you selected the Tivoli Application Dependency Discovery Manager as a 

data source, the installer prompts you for the server information. 

Enter the TADDM User ID 

The Tivoli Application Dependency Discovery Manager user ID. 

Specify a user ID with at least supervisory authority. 

Enter the TADDM password 

The password associated with the user ID 

Confirm the TADDM password 

Re-enter the password. 

Enter the TADDM server hostname or IP address 

The host name or IP address of the system where the server is 


unning. If the server is running on a private network and the 

TBSM server is not, then specify the external IP address of the 

TADDM server. 

Enter TADDM port 

The RMI port that Tivoli Application Dependency Discovery 

Manager (TADDM) is listening on. TADDM defines the RMI port 

in the taddmInstall/etc/collation.properties file. The property 

is com.collation.api.port. 

The default value is 9530. 

Enter the SSL port that TADDM is listening on 

The SSL RMI port that Tivoli Application Dependency Discovery 

Manager (TADDM) is listening on. TADDM defines the port in the 

taddmInstall/etc/collation.properties file. The property is 

com.collation.api.ssl.port. 


Use SSL on the connection that TADDM is listening on 

Specify whether you are using TADDM SSL listening port. 

If you select SSL, you must copy the certificate jssecacerts.certs 

from the TADDM host to the Data server in this directory: 

$TBSM_HOME\XMLtoolkit\sdk 

You can do this after the installation is complete, but you need to 

copy the file before you start the toolkit. 

TADDM Database Configuration 

This set of prompts let you specify configuration definitions for the 

TADDM database. 

Select database type 

Specify IBM DB2 or Oracle. 

If you select IBM DB2, the JDBC files are found automatically in 

the TBSM installation package. 

If you specify the Oracle database, the installer prompts you for 

the location of the directory containing the Oracle JDBC drivers. 

Check if the $TBSM_HOME/dsalib directory has the correct driver for 

your version of Oracle. 

If you do not have this file on the Data server host, find the file 

and copy it to your system. 

These files are typically provided by the database vendor with the 

database or the database client package. For example, you can find 

this file on your Oracle host system or as part of your Oracle client 

installation. 

The installer looks in the directory you specify and collects the 

names of the jars that begin with "o" and end with ".jar" and 

adds these to the toolkit's classpath. If either ojdbc6_g.jar, 

ojdbc6.jar or ojdbc5.jar is found, it is added to the classpath; if 

not then all jars matching the pattern are added. 

The reason for the additional checking on Windows is because 

problems have been seen with the 11.2.0.2.0 version of ojdbc6.jar. 

If this version of the JDBC driver is being used, it may be best to 

Installing TBSM 55

use object6_g.jar instead of ojdbc6.jar. The problem manifests 

itself on Windows with the following exception: 

Exception in thread "main" java.lang.NoClassDefFoundError: 

oracle.dms.console.DMSConsole 

at oracle.jdbc.driver.DMSFactory. 

(DMSFactory.java:51) 

at java.lang.J9VMInternals.initializeImpl(Native Method) 

at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) 

at oracle.jdbc.driver.PhysicalConnection.createDMSSensors 

(PhysicalConnection.java:3821) 

Enter the database User ID: 

The TADDM database user id. 

Note: The TADDM database user that TBSM is using needs only 

read authority on the TADDM database with two exceptions. 

1. TBSM needs read/write/analyze permission on the 

tbsm_change_history_table. If this table has not yet been 

created, the DDL in .../XMLtoolkit/sql/ 

taddm_schema_setup_oracle.sql or 

taddm_schema_setup_db2.sql can be used to create the table. 

TBSM uses this table during delta imports. 

2. If the customer was using an older version of the toolkit that 

used the generated relationships (taddm explicitrel script) in 

TADDM, these relationships must be deleted. After installing, 

run the .../XMLtoolkit/bin/purgeexplicitrel script to delete 

these relationships. The user used for this script needs write 

authority since it is deleting from the relation, persobj, and 

cmdb_guid_alias tables. Depending on the number of 

relationships that need to be deleted, this process can be 

lengthy. This is a one time process, so the user and password 

used by purgeexcplicitrel can be different than that provided 

to TBSM for general use. 

Oracle restriction: On Oracle, the user that TBSM uses to access 

the default schema for the TADDM database must be the same as 

the user who created the schema for those TADDM tables. 

Enter the database password: 

The password for the user id 

Confirm database password 

Enter the password again to confirm. 

Enter the database hostname: 

The host name for the TADDM database 

Enter the port used by the database 


Enter the database name: 

The default name is CMDB. 

Enter the database schema 

The defalut schema is dbinst1. 

Discovery Library Book Export Configuration 

Specify the toolkit export configuration settings on this screen. 

Enter the directory name: 

The directory where the toolkit writes book files created from the 


TBSM service models. This can be the same directory as import 

book directory where the toolkit reads books files. 


Enter dashboard server hostname or IP address 

Enter the Dashboard server host name you want in the book files 

generated by TBSM. Other products use this information to enable 

a launch back to TBSM in context. That is, the other applications 

can launch a TBSM page from the specified Dashboard server. 

If load balancing is set up for your Dashboard servers, specify the 

load balancer host. 

If you enter the host name, enter the fully qualified name. 

The default value is the Data server host IP address. 

Enter the Dashboard server port: 

The Dashboard sever HTTP port. 

The default is 16310 

Performing advanced installations 

When you perform an advanced installation, you select the features to install on 

your TBSM system. There are special requirements if you are installing TBSM 

using an existing Tivoli Integrated Portal. 


If you are installing TBSM using an existing Tivoli Integrated Portal, the following 

conditions apply: 

v You should back up the DE database before the installation process makes any 

changes to your system. You should back up the database before you install any 

part of TBSM. If you back up the database, you will have the original database 

information in the event that you need to restore the database. The commands 

for backing up the database and restoring the database are de_backupdb.cmd and 

de_restoredb.cmd. 

v On the Installation Directory window there are two radio buttons. You must 

click the second radio button and select the installation directory from the list so 

that you can reuse the existing Tivoli Integrated Portal. If you do not perform 

this action, the installation will fail. 

v You must use the same user ID to install all products that are used by the Tivoli 

Integrated Portal. 

Note: Before performing an installation on UNIX following an uninstall procedure, 

the OMNIbus process might still be running. Use the ps -ef | grep omni 

command to locate the process. End the process that appears. 

Procedure 

Select the installation procedure for the feature or features that you want to install. 

Feature Installation procedure 

IBM Tivoli Netcool/OMNIbus Server “Installing the Netcool/OMNIbus Server 

component” on page 58 

Tivoli Event Integration Facility probe “Tivoli Event Integration Facility Probe 

Installation” on page 60 

Installing TBSM 57

Feature Installation procedure 

Dashboard server “Installing the Dashboard server 

component” on page 79 

Data server “Installing the Data Server component” on 

page 64 

Note: Network latency might cause delays when TBSM is loading or updating. To 

minimize potential network latency between the TBSM Data server and Dashboard 

server, and to promote optimal responsiveness in your network, locate your Data 

server and Dashboard servers in the same Local Area Network or network switch 

whenever possible. 

Installing the Netcool/OMNIbus Server component 

You can use the installation program for IBM Tivoli Business Service Manager 

(TBSM) to install only the IBM Tivoli Netcool OMNIbus Server component. This is 

useful in a production environment, where you want to install the Tivoli Netcool 

OMNIbus Server component on a separate system from the other TBSM 

components. 

Procedure 
















































from the list. If you do not perform this action, the installation will fail. 

b. Click Next. 

8. In the Installation Type window, click Advanced, and then click Next. 

9. In the Feature Selection window, select the OMNIbus check box, and then 

click Next. 

10. In the ObjectServer Configuration window, specify information about the 

ObjectServer. By default, the ObjectServer name is set to the host name of the 

system on which you are running the installation program. 

a. In the ObjectServer name field, type a name for the ObjectServer. By 

default, this is set to NCOMS. This name must meet the following criteria: 

v Maximum of 11 characters in length. 

v The first character must be an uppercase letter. 

v The characters can be uppercase letters, underscores, or numbers. 

b. In the ObjectServer port number field, type a port number for the 

ObjectServer. By default, this is set to 4100. The valid range for the port 

number is 1024–65535. This port number must not be in use by another 

application. 

c. In the ObjectServer User field type the user name. The default, this is set 

to root 

d. In the ObjectServer Password and Confirmation Password fields, enter 

the ObjectServer user password. 

e. Click Next. 







13. In the Install Complete window, click Done. 

Installing TBSM 59


On Windows systems, you must restart the computer on which you installed the 

OMNIbus service to set the environment variables, to be able to start the service, 

and to make all OMNIbus batch files fully functional. Restarting the computer also 

makes it possible to uninstall the OMNIbus service. 

Related concepts: 

“IBM Tivoli Netcool OMNIbus Considerations” on page 24 

Tivoli Event Integration Facility Probe Installation 


You can install the EIF Probe using the launchpad of IBM Tivoli Business Service 

Manager (TBSM), or you can install the probe using the TBSM product DVD. 

Although you can install the Tivoli EIF probe on the TBSM server, you should 

install it on the event source server. When you install the probe on the event 

source server, the probe can provide a secure sockets layer (SSL) connection 

between itself and the TBSM server. If you decide to install the probe on the same 

server on which TBSM is installed, you cannot change the installation location; the 

probe will be installed in the directory $OMNIHOME\probes. 

Installing the Tivoli Event Integration Facility probe 

You can install the Tivoli Event Integration Facility probe (EIF probe) on the event 

source host, the TBSM host, or a third host. If you want encrypted communications 

between the ObjectServer and the EIF probe, install the probe on the event source 

host, like on the Tivoli Enterprise Console host. 

Procedure 

1. Start the installation process from the product DVD or from the launchpad: 

v To install from the launchpad, insert the DVD and use the steps which 

follow. 





















TBSM launchpad functions normally otherwise.





























9. In the Installation Type window, click Advanced, and then click Next. 

10. From the feature list, select Tivoli EIF Probe and click Next. 

11. Specify information about the ObjectServer that the EIF probe will interface 

with. All fields are required. 

For zLinux: The Tivoli EIF Probe requires a small component of 

Netcool/OMNIbus to be on the same system that the probe is running on. You 

must install Netcool/OMNIbus Confpack so that the Tivoli EIF Probe can 

function on your system. All other platforms install this component 

automatically if it is not found on the system. 

a. In the ObjectServer name field, type the name of an ObjectServer that has 

already been installed. The default value is NCOMS. 

b. In the ObjectServer hostname field, type the host name of the server to 

connect to. This option appears only if OMNIbus was not found on the 

system. 

c. In the ObjectServer port number field, type the port value. The port value 

must be in the range 1241-65535. The default value is 4100. This option 

appears only if OMNIbus was not found on the system. 

d. Click Next. 

Installing TBSM 61

Note: If Netcool/OMNIbus is not found on the machine, the probe subfeature 

is installed. This feature enables the EIF Probe to function. 

12. Specify information about the EIF probe. 

a. In the Probe Listening Port field, type the port number to which event 

source products (IBM Tivoli Enterprise Console, IBM Tivoli Monitoring, 

and IBM Tivoli Network Manager) are configured to forward events. This 

value must be in the range 1241-65535. The default value is 9998. 

b. Select Set up Tivoli EIF probe for failover if you want to set up the probe 

for failover. If you select this option, the ObjectServer server NCOMS must 

be configured with a backup ObjectServer server. 

c. Select Set up Tivoli EIF probe as a Windows service if you 

want the server to create a Windows service definition that will start the 

probe when Windows is started. The NCO NONNATIVE Probe 

(NCOTivoliEIFProbe) service is created. 

d. Click Next. 

13. If you selected Set up Tivoli EIF probe for failover, read the message that 

displays and click OK. Refer to the Configuring: post installation for 

additional information. 




15. In the preinstallation summary window, click Install. The installation 

directory, a list of features to be installed, and the total space required for the 

installation are shown in the summary window. 

16. Click Finish to complete the installation. 

17. Click Finish to exit the installation. 

Verifying installation of the Tivoli Event Integration Facility probe 

Errors in the debug output of the Tivoli Event Integration Facility probe (EIF 

probe) or the failure of the EIF probe to run are indications that the probe is not 

installed correctly. 


Note: If the probe is running as a Windows service, stop the service before 

beginning the verification procedure. Start the service after verification is complete. 

Procedure 

1. Change to the directory where the probe was installed. The default directories 

are as follows: 

/opt/IBM/tivoli/netcool/omnibus/probes 

C:\Program Files\IBM\tivoli\netcool\omnibus\probes\win32 

2. Edit the tivoli_eif.props file. 

a. At the end of the file, remove the comment symbol (#) from the beginning 

of each of the following lines: 

MessageLevel : 'debug’ 

MessageLog : 'stdout’ 

b. Save the file. 

3. Start the probe with the command: 


nco_p_tivoli_eif.bat

nco_p_tivoli_eif.sh 

4. View output in the console of the probe running. Typical output looks like this: 

D:\IBM\Netcool\omnibus\probes\win32>nco_p_tivoli_eif.bat 

Netcool/OMNIbus NON NATIVE - Version 7.1 

Copyright (C) 1994 - 2005, Micromuse Ltd. All rights reserved. 

Information: Requested to execute in CONSOLE mode 2007-01-12 13:53:13 Service 

starting in console mode 

01/12/2007 01:53:16 PM: Information: I-UNK-000-000: Connecting ... 

01/12/2007 01:53:16 PM: Debug: D-UNK-000-000: Reading D:\IBM\Netcool\omnibus\ 

probes\win32\tivoli_eif.rules 

01/12/2007 01:53:16 PM: Debug: D-UNK-000-000: Plain text rules file detected. 

01/12/2007 01:53:16 PM: Debug: D-UNK-000-000: End of D:\IBM\Netcool\omnibus\ 

probes\win32\tivoli_eif.rules 

01/12/2007 01:53:16 PM: Information: I-UNK-000-000: Using targets specified 

by properties 

01/12/2007 01:53:16 PM: Debug: D-UNK-000-000: Setting default target server 

to ’NCOMS’. 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: Attempting a connection to 

server ’NCOMS’. 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: Checking for backup ObjectServer. 

01/12/2007 01:53:29 PM: Information: I-UNK-000-000: ’NCOMS’ is a primary server. 

Polling disabled. 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: Server Verification Starting. 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: Server Verification Complete. 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: Checking for svc update support. 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: Server SUPPORTS services. 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: svc update SUPPORTED 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: Heartbeat mode is: standard 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: Heartbeat mode is standard, probe 

will function as normal without heartbeating 

01/12/2007 01:53:29 PM: Debug: D-BASE-004-049: THREAD MGR: started thread 

failover-thread (00DC0E48) 

01/12/2007 01:53:29 PM: Debug: D-BASE-004-050: THREAD MGR: thread 

failover-thread (00DC0E48) 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: NSProbe - Reentrant Version 

01/12/2007 01:53:29 PM: Information: I-UNK-000-000: Probewatch: Running ... 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: Inactivity-> 600 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: PortNumber-> 5530 

01/12/2007 01:53:29 PM: Debug: D-UNK-000-000: EIFCacheFile-> C:\Program Files\ 

Netcool\OMNIbus\var\tivoli_eif.cache 

01/12/2007 01:53:30 PM: Debug: D-UNK-000-000: EventCopies-> 1 

5. Stop the probe. 

6. Remove the two property lines that you added. 

7. Start the probe. 

Uninstalling the Tivoli Event Integration Facility probe 

You can only uninstall the EIF probe as part of the TBSM uninstallation program. 


See Uninstalling TBSM for more information. 

TBSM extensions directory 

This directory contains EIF Probe rules files that are specific to TBSM functionality. 

Purpose 

The majority of these files are related to z/OS event flow support for TBSM. There 

is also a rules file to help you filter events from ITCAM for SOA. For more 

information on using and customizing these files, see the TBSM Customization and 

Scenarios guides. 

Installing TBSM 63

Locations 

This directory can be found in the root directory of TBSM installation image: 

/tbsm_extenstions 

These files are also available in the following locations if the Tivoli EIF probe is 

installed using the TBSM installer. 

Windows 

C:\%OMNIHOME%\probes\win32\tbsm_extensions 

Note: When you use the command window, you may get a path not found error 

for %OMNIHOME%. If the path for the OMNIHOME variable contains spaces, put the 

variable name in quotes as follows: "%OMNIHOME%" 

UNIX 

$OMNIHOME/probes/arch/tbsm_extensions 

TBSM probe rules files 

The tbsm_extensions directory contains these files. 

kd4_tbsm.rules 

ITCAM for SOA BSM_Identity setting rules. 

tivoli_eif_zos_tbsm.rules 

TBSM z/OS lookup table reference rule file. 

zos_classid.lookup 

TBSM z/OS lookup table by class id. 

zos_identity.rules 

TBSM z/OS BSM_Identity rule file. 

zos_objectid.lookup 

TBSM z/OS lookup table by oject id id. 

zos_objectid.low.lookup 

TBSM z/OS lookup table by object id example of minor behavior. 

zos_objectid.medium1.lookup 

TBSM z/OS lookup table by object id example 1 of major behavior. 

zos_objectid.medium2.lookup 

TBSM z/OS lookup table by object id example 2 of major behavior. 

Installing the Data Server component 






You need to do the following before install and configure these components: 

v Configure the TBSM databases on a DB2 instance. You need to know the 

connection information for the database. 


v Install IBM Tivoli Netcool/OMNIbus ObjectServer included in the TBSM 

installation package or configure the TBSM schema on an existing ObjectServer 

as described in the Planning section of this guide. The ObjectServer must be 

running before you install the Data Server. You need to know the connection 

information for the ObjectServer. 

v Read the sections that describe all the information you need to complete each 

screen in the installation program. Once you obtain all the information you 

need, fill out the Data server installation worksheet and run the installer, using 

the worksheet as your guide. 

Note: If you choose to install the Data Server on the same host as a 4.2.1 Data 

Server, then you need to: 

1. On UNIX systems, disable older Discovery Library Toolkit 

service before you launch the installer. Disable the toolkit with the command: 

$TBSM_HOME/XMLtoolkit/bin/tbsmrdr_disable.sh 

2. Open the file .com.zerog.registry.xml file and remove all Discovery Library 

Toolkit references. This file is in a subdirectory of the $TBSM_HOME/XMLtoolkit/ 

directory. 

3. Choose a new installation directory and port numbers for the new TBSM 

server. 

4. Use a different user than the Install user that was used for version 4.2.1. 



“Data server LDAP configuration” on page 29 


manually configure TBSM data server to use an LDAP repository. 

Data server communication settings 

Specify the communication settings with the Data server. 

Purpose 

To successfully install the server, you need supply information that the Dashboard 

server needs to communicate with the Data server. 

Restriction: 

You cannot install a Backup Data Server and a Data Server at the same time. See 

Configuring post installation > Configuring IBM Tivoli Business Service 

Manager for failover for instructions about configuring a failover environment. 

Choices 


Communication port 

The port number that the Dashboard Server components will use for 

communication with the Data Server component. 

By default, this is set to 17542. The valid range for the port number is 

1241–65535. 

Impact Server Command Line Port 

The port for the Netcool/Impact command line interface. The default value 

is 2001. 

Installing TBSM 65

If failover is set up and this Data Server will be the backup server, select the 

following check box. 

If you are designating this host as the backup server in a failover 

environment, select the Designated backup server option. 

Note: When you designate this data server as a backup server, it is only 

the first step in the data server failover-configuration process. To finish the 

failover configuration, you need to run the fo_config script after you 

complete the installation. Do not install a dashboard server to connect with 

this data server until the failover procedure has been completed on this 

machine. See the Configuring post installation: Configuring failover section 

of this guide for instructions on configuring a failover environment. 


“Configuring IBM Tivoli Business Service Manager for failover” on page 179 

You can set up a TBSM environment that contains multiple instances of the TBSM 

Data server and the ObjectServer. When one of the primary servers fails, the 

backup server takes over as the primary server. Such an environment provides 

protection against data loss and ensures that TBSM is running and available. To 

provide redundancy, load balancing, or both for the Dashboard server, you can 

configure load-balancing support for one or more Dashboard servers. This 

load-balancing support applies only to the user interface; it does not affect TBSM 

event or status processing. 

User Registry selection 

Select the type of user management and authentication. 

Purpose 

To successfully install the server, you need supply information about your user 

registry. During the installation, you can choose either the default 

Netcool/OMNIbus ObjectServer user registry or the file-based user registry. 

Choices 


LDAP repository and Tivoli Integrated Portal load balancing 

If you want to use a Lightweight Directory Access Protocol (LDAP) 

product as your user registry, you must select the Local File Based option 

during the installation. You can then manually configure your LDAP 

repository after the installation is complete. The load balancing feature of 

Tivoli Integrated Portal requires an LDAP user repository. 

ObjectServer 

Select this option to use the Netcool/OMNIbus ObjectServer as your user 

registry. 

If you are familiar with the ObjectServer as a user registry, you may want 

to use this option. 

You can use this option with failover or single sign-on installations. 

Local File Based 

Useful for proof-of-concept installation. Cannot be used with failover, load 

balancing, or single sign-on installations. 

Database information 

Specify information about the TBSM databases in this window. 


Purpose 




To successfully install the server, you need supply information on the databases 

that was installed for TBSM using the database configuration utility. 

Choices 


TBSM Database Information 




In many cases, all the TBSM databases share the same configuration. By 

default, the option Use the same database as the TBSM Data Server is 

selected for the Metric Marker and Metric History databases. If separate 

databases have been configured, de-select this option and enter the 

information for each database. 

The Data Server database stores information such as services, templates, 

and the service component repository. 

The Metric Marker database stores metric markers configured for 

overlaying historical values in the Time Window Analyzer. 

The Metric History database stores the history of values for metrics that 

are collected for the Time Window Analyzer. 


Database name 




Database port Number 


Use the port number for the instance of DB2 where the TBSM 

database was configured. 

Important: The TBSM installation program does not check if the 

port number is valid. As a result, you must validate the port 

number manually. 



database. 





Installing TBSM 67

Selecting and configuring a version control 

The version control manager uses Impact Subversion (SVN) as the default version 

control which is installed automatically with the Data Server if you leave the 

default selection. 

No additional configuration steps will be required if you decide to go with the 

default setting and immediately after the installation you will be able to save 

policies, data sources, data types, and configuration properties as revisions in a 

source control archive. 

Choose another option if you want to use a different version control system. Be 

prepared to provide additional configuration information in the steps to follow: 

Version Control Path 

Provide the path to your version control. You have to provide this 

information for the Data Server when the Subversion, or CVS, or RCS or 

ClearCase ® is selected in the version Choose Version Control System step. 

Version Control Repository 

Set the repository for your version control. You have to provide this 

information for the Data Server when the Subversion or CVS is selected in 

the Version Control System step. 

Tivoli Integrated Portal information 

Specify information about the Tivoli Integrated Portal administration user in this 

window. 

Purpose 

To successfully install the server, you supply the Tivoli Integrated Portal 

administration user information. This enables the installer to add a Tivoli 

Integrated Portal profile to the Websphere Application Server. The installer uses 

this user ID to log in to the Tivoli Integrated Portal server. 

Settings 

You need to specify these settings: 

TIP User ID 

The administrator user that is created and used to log into Websphere 

Application Server. If you are reusing an existing Tivoli Integrated Portal, 

provide the existing user ID. 

Default: tipadmin 

TIP password 

The password for the user. 

Confirm password 

Enter the password here again. If this does not match the TIP Password, 

you are prompted to enter the password again. 

Note: By default, you cannot use an ! (exclamation) character in the tipadmin 

password on Windows systems. It results in errors in the TBSM trace logs, RAD 

shell does not connect to the Data server, and no RAD shell prompt is displayed. 

For information about addressing this issue, see the Troubleshooting section of the 

TBSM Installation Guide. 


WebSphere profile port information 

Specify how you want to assign ports for the WebSphere Application Server in the 

WebSphere port information window. 

Purpose 

To successfully install the server, you must configure the WebSphere ports that are 

used by the WebSphere Application Server for the TBSMProfile. 

Settings 

You must specify these settings: 

Starting port number provided 

You want to specify a port number. This number is used to generate the 

port numbers that eWAS uses to communicate with the profile for the Data 

Server component (TBSMProfile). 

If you select Starting port number that is provided, specify the starting 

port number: 

1. In the Starting port number field, type a port number in the range 

1241–65535. 

2. Click Next. The installation program uses the port number that is 

provided to generate values for the variables. 

Modified port value file 

Supply the location of a file that provides port values for WebSphere. The 

values within this file are not validated. Ensure all ports that are specified 

are available for the TIPProfile. Otherwise, the Data server does not run 

properly. Refer to the following file example: 

#Create the required WAS port properties for TIP 

WC_defaulthost=17310 

WC_defaulthost_secure=17311 

WC_adminhost_secure=17316 

WC_adminhost=17315 


BOOTSTRAP_ADDRESS=17312 

SOAP_CONNECTOR_ADDRESS=17313 

IPC_CONNECTOR_ADDRESS=17314 

SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=17321 

CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=17323 

CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=17322 

ORB_LISTENER_ADDRESS=17320 

DCS_UNICAST_ADDRESS=17318 

REST_NOTIFICATION_PORT=17324 

An example of the file named modified_port_value_file is in the Samples 

directory of the TBSM installation package. 

If you select Modified port value file, specify the full qualified name of 

the file that specifies which ports eWAS will use, and then click Next. 

Configuring the Name Server 

Configure the Name Server to provide registration functionality for the 

deployment components. 

You can define multiple Name Server-port pairs and then associate your current 

installation to multiple Name Servers. Each Name Server port that you provide 

will be tested to check if it is active. If the port is active you will proceed to the 

Installing TBSM 69

next step of the installation. If the port is not active you will see a message 

indicating that the port is not active but you will still be able to continue with the 

installation. For the installation to be successful, however, make sure that the 

server-port pair as you have defined is available. 

Important: If you are defining a TBSM server, the current host name and port 

number must be in the list. You will get an error if it is not in the list. 

If you plan to configure failover, this list needs to contain the primary followed by 

the backup for both machines and the lists need to match on both TBSM servers.. 

ObjectServer configuration 

Specify information about the Netcool/OMNIbus ObjectServer in this window. 

Purpose 

To successfully install the server, you need supply information the ObjectServer 

that sends events to Netcool/Impact. By default, the ObjectServer name is set to 

the host name of the system where you are running the installation program. 

Important: If you are using an ObjectServer which was not installed using the 

TBSM installer, you need to apply the TBSM schema changes before proceeding 

with the installation, See the Planning section for more information on 

Netcool/OMNIbus considerations. 

Restriction: You can not specify the same ObjectServer for more that one TBSM 

Data server. Otherwise, your event data will be incorrect for both servers. The only 

time you can use the same ObjectServer is for the primary and backup Data 

servers in a failover environment. 

Choices 


ObjectServer 

The name for the ObjectServer. 

By default, this is set to NCOMS. This name must meet the following criteria: 




ObjectServer host 

The host name of the system where the ObjectServer is installed. 

By default, this is the name of the local host where you are running the 

installer. 

ObjectServer port 

The port number for the ObjectServer. 


1024–65535. This port number must not be in use by another application. 

ObjectServer User 

The user name. 

The default, this is set to root. 


ObjectServer Password 

The ObjectServer user password. 

Note: TBSM can be installed with the default ObjectServer user as root 

and a null password, but users cannot use a null password to log in to the 

TBSM Dashboard Server. This is because Integrated Solutions Console and 

Tivoli Integrated Portal do not allow blank passwords. 

Confirmation Password 

Enter the ObjectServer password here again. If this does not match the 

ObjectServer Password, you are prompted to enter the password again. 

Discovery Library Toolkit information 

Specify information about the Discovery Library Toolkit installation in these 

prompts. 

Purpose 



v IBM common data model Discovery Library (IDML) books 


v Discovery Library toolkit API 


During the Data server installation you can choose whether Tivoli Application 

Dependency Discovery Manager and/or books will be accepted. The API is 

enabled by default, but can be disabled after installation through a property. 

TADDM warning: If you are installing the Discovery Library Toolkit with a Tivoli 

Application Dependency Discovery Manager server as a data source, you need to 

make sure that you have only one Discovery Library Toolkit connection to the 

Tivoli Application Dependency Discovery Manager server. Otherwise, you will get 

incorrect data from the Tivoli Application Dependency Discovery Manager . 

Note: If there is already a TBSM Discovery Library toolkit installed on this 

machine and it is installed into a non-standard location, this copy of the toolkit 

should be shutdown. A non-standard location is defined as not being in 

../tivoli/tbsm/XMLtoolkit. If a copy already resides at this location, the TBSM 

Data server install will skip the toolkit portion of the installation. 

You also specify information to enable the toolkit to export Discovery Library 

books from TBSM. 

Choices 

You need to specify the data source information for the toolkit. 







Installing TBSM 71







Discovery Library Book Import Configuration 

Configuration of the book import file system. Enter the directory name that 

the toolkit will monitor for new book files. When a new book file is 

detected in the directory you specify, the toolkit reads and processes the 

file. 














running. If the server is running on a private network and the 


TADDM server. 




















copy the file before you start the toolkit.

















installation. 



































Installing TBSM 73




























Enter dashboard server hostname or IP address 

Enter the Dashboard server host name you want in the book files 

generated by TBSM. Other products use this information to enable 

a launch back to TBSM in context. That is, the other applications 

can launch a TBSM page from the specified Dashboard server. 

If load balancing is set up for your Dashboard servers, specify the 

load balancer host. 

If you enter the host name, enter the fully qualified name. 

The default value is the Data server host IP address. 

Enter the Dashboard server port: 

The Dashboard sever HTTP port. 

The default is 16310 

Installation worksheet: Data server 

This worksheet helps guide you through the Data server installation. 

Purpose 

Fill out the worksheet before you run the installation program for the Data server. 

Save this worksheet for future reference. 


Worksheet 


Table 8. Data server installation information 

Prompt title Default value Installed value 

Installation Directory 


C:\Program 

Files\IBM\tivoli 

Data Server Information 

Communication port 17542 

Impact Server Command Line Port 2001 

Designated backup server Not selected. 

Data Backup Information Required for failover 

configuration 

Backup Data Server host 

Backup Data Server HTTP port 17310 

Backup Data Server communication 17542 

port 

User Registry Selection ObjectServer 

TBSM Data Server Database 

Information 

Database Name TBSM 


Database Port Number 50000 

Database User Name 

Database Password 

TBSM Metric Marker Database 

Information 

Use the same database as the TBSM Selected 

Data Server 

Database Name TBSM 





TBSM Metric History Database 

Information 

Use the same database as the TBSM Not selected 

Data Server 

Database Name TBSMHIST 





Installing TBSM 75

Table 8. Data server installation information (continued) 


Choose Version Control System 


Impact Subversion 

TIP User ID 

TIP password 

Websphere port information 

tipadmin 


Modified port value file (optional) 

Name Server Configuration 

17310 

Host_Name:Port_Number 

ObjectServer Configuration 

TBSM Data Server Host:17310 

ObjectServer NCOMS 

ObjectServer host Local host name where installer 

is running. 

ObjectServer port 4100 



Discovery Libray Toolkit 

Configuration 

root 

Discovery Library books data source Selected 

Tivoli Application Dependency 

Discovery Manager data source 

Not Selected 

Naming service RMI registry port 12315 

Discovery Library Book Import $TBSM_HOME/tbsm/discovery/ 

Configuration 

dlbooks 

TADDM User ID None 

TADDM password None 

TADDM server hostname or IP 

address 

None 

TADDM port 9530 

SSL port that TADDM is listening on 9531 

Use SSL on the connection that 

TADDM is listening on 

Not selected. 

TADDM database type IBM DB2 

Database User ID None 

Database password: None 

TADDM Database hostname None 

TADDM database port 50000 

TADDM database name: CMDB 

TADDM database schema dbinst1 

Book Export directory $TBSM_HOME/tbsm/discovery/ 

dlbooks 


Table 8. Data server installation information (continued) 


Dashboard server hostname or IP 

address 

Data server IP address 

Dashboard sever HTTP port. 16310 

Running the Data server installer 

You can use the installation program to install only the Data Server component. 

This is recommended for a production environment, where you want to install the 

Data Server component on a separate system from the other TBSM components. 


Before you install the Data server: 

v Configure the TBSM databases on a DB2 instance. You need to know the 

connection information for the database. 

v Install IBM Tivoli Netcool/OMNIbus ObjectServer included in the TBSM 

installation package or configure the TBSM schema on an existing ObjectServer 

as described in the Planning section of this guide. You need to know the 

connection information for the ObjectServer. 

v Read the sections that describe all the information you need to complete each 

screen in the installation program. Once you obtain all the information you 

need, fill out the Data server installation worksheet and run the installer, using 

the worksheet as your guide. 

To install the Data server: 

Procedure 










2. Click Install IBM Tivoli Business Service Manager 6.1.1 in the navigation 

panel and then click Run the Tivoli Business Service Manager 6.1.1 

Installation Program. The installation process begins. 










Installing TBSM 77




























8. In the Installation Type window, click Advanced, and then click Next. The 

installation program scans the system and determines what components need 

to be installed. 

9. In the Feature Selection window, unselect OMNIbus and Dashboard Server 

leaving Data Server selected, and then click Next. 

10. The Data Server Information window opens. 

For each of the installation screens, specify the required information and click 

Next to proceed to the next window. 







13. In the Install Complete window, click Done. 

Adding JDBC drivers to the shared library 

Use this procedure to add a JDBC driver to the TBSM shared library. 



Tivoli Business Service Manager supplies the following database JDBC drivers with 

this release: 

v DB2 

v HSQL 

v Informix 

v ObjectServer 

If you want to use other databases as data sources, you need to obtain these 

drivers from the database manufacturer and copy them to your TBSM host. 

These files are typically provided by the database vendor with the database or the 

database client package. For example, you can find the Oracle file on your Oracle 

host system or as part of your Oracle client installation. 

Procedure 

1. Obtain the appropriate JDBC driver according to the DSA specification. 

2. Stop the server. 

3. Copy the JDBC driver to the $TBSM_HOME/tbsm/dsalib directory. 

This directory is created during the installation, and initially it is empty. 

4. Restart the TBSM server. 


In a multi-host configuration you have to repeat this procedure for each server 

because JDBC drivers are not replicated between the servers. Stop the server while 

you are performing this procedure. 

Installing the Dashboard server component 






Before you install the Dashboard server: 

1. Install the Data server. The Netcool/Impact server for TBSM is installed as part 

of the Data server. 

2. If you are planning failover environment, complete the failover configuration. 

3. Read the topics that describe the installation information required to complete 

each installation window. 

4. Complete the Dashboard server installation worksheet to help guide you 

through the installation. 

Netcool/Impact Name Server: When you are prompted for the Name Server, you 

must specify the TBSM Data server host as the name server host. 

Installing TBSM 79

OS Agent restriction: If the Tivoli Monitoring Agent for Windows 

OS is installed and running on the same system as the Tivoli Integrated Portal 

server, it may lock certain Websphere Application Server dll files and cause the 

install to fail. 

To avoid this problem, stop the agent before installing the server. To stop the 

agent: 

1. In the Manage Tivoli Enterprise Monitoring Services application, select the 

Monitoring Agent for Windows OS service. 

2. Select Actions->Stop. 

You can also stop the Windows service for the agent: 

In the Windows Services applet, stop both the "Monitoring Agent for Windows 

OS - Primary" and "Monitoring Agent for Windows OS - Watchdog" services 

After the install has completed, you may restart the agent. 


Installing on an existing Tivoli Integrated Portal: If you choose to install the 

Dashboard server to an existing Tivoli Integrated Portal, you need to create the 

TBSM users and groups after the installation. You do not need to use this 

procedure if you are installing a new instance of Tivoli Integrated Portal with the 

Dashboard server. 

For information on creating the users and groups for the Dashboard server, see 

Configuring TBSM: post installation > Set up Dashboard server users on existing Tivoli 

Integrated Portal. 


“Dashboard server LDAP configuration” on page 28 

If you want to use an LDAP repository, select the file-based repository option 

during the installation, and manually configure TBSM dashboard server to use an 



“Set up Dashboard server users on existing Tivoli Integrated Portal” on page 211 

If you choose to install the Dashboard server to an existing Tivoli Integrated Portal, 

you need to create the TBSM users and groups after the installation as described in 

this procedure. You do not need to use this procedure if you are installing a new 

instance of Tivoli Integrated Portal with the Dashboard server. 

User Registry selection 

Select the type of user management and authentication. 

Purpose 

To successfully install the server, you need supply information about your user 

registry. During the installation, you can choose either the default 

Netcool/OMNIbus ObjectServer user registry or the file-based user registry. 

Choices 



LDAP repository and Tivoli Integrated Portal load balancing 

If you want to use a Lightweight Directory Access Protocol (LDAP) 

product as your user registry, you must select the Local File Based option 

during the installation. You can then manually configure your LDAP 

repository after the installation is complete. The load balancing feature of 

Tivoli Integrated Portal requires an LDAP user repository. 

ObjectServer 

Select this option to use the Netcool/OMNIbus ObjectServer as your user 

registry. 

If you are familiar with the ObjectServer as a user registry, you may want 

to use this option. 

You can use this option with failover or single sign-on installations. 

Local File Based 

Useful for proof-of-concept installation. Cannot be used with failover, load 

balancing, or single sign-on installations. 

Dashboard server configuration 


Purpose 

To successfully install the server, you need to supply information that the 

Dashboard server needs to communicate with the Data server. 

Restriction: You cannot install a Dashboard Server to connect to the Data Server 

that has been designated as a backup Data server. Please direct this dashboard 

server to connect to the primary Data server. 

You cannot install a Backup Data Server and a Dashboard Server at the same time. 

See the Configuring post installation: Configuring failover and Load Balancing 

section of the TBSM Installation guide for instructions on configuring a failover 

environment. 

Choices 


Dashboard Server communication port 

The port number that the Dashboard Server component uses for 

communication with the Data Server component. 

By default, this number is set to 17543. The valid range for the port 

number is 1241–65535. 

Data Server Host 

The host name of the system where the Data Server is installed. 

By default, this value is set to the host name of the local system. 

Data Server HTTP Port 

The port number for the Data server. 

By default, this port is set to 17310. The valid range for the port number is 

1241–65535. 

Installing TBSM 81

Data Server communication port 

The port number that the Data Server component uses for communication 

with the Dashboard Server component. 

By default, this port is set to 17542. The valid range for the port number is 

1241–65535. 

Data Server is a primary in a failover configuration 

If you have a failover environment, select this option and you will be 

prompted for information on the backup Data server. 

Dashboard Backup Information 

If you select the Data Server is a primary in a failover configuration 

option, you need to provide this host and port information for the backup 

Data server on the next screen: 


The host name of the backup Data Server. 

Backup Data Server HTTP port 

Accept the default, or enter a port number. 

By default, this is set to 17310. The valid range for the port number 

is 1241–65535. 

Backup Data Server communication port 

Accept the default, or enter a port number. 

By default, this is set to 17542. The valid range for the port number 

is 1241–65535. 












Specify information about the Tivoli Integrated Portal administration user in this 

window. 

Purpose 

To successfully install the server, you supply the Tivoli Integrated Portal 

administration user information. This enables the installer to add a Tivoli 

Integrated Portal profile to the Websphere Application Server. The installer uses 

this user ID to log in to the Tivoli Integrated Portal server. 

Settings 


TIP User ID 

The administrator user that is created and used to log into Websphere 

Application Server. If you are reusing an existing Tivoli Integrated Portal, 

provide the existing user ID. 


Default: tipadmin 

TIP password 

The password for the user. 

Confirm password 

Enter the password here again. If this does not match the TIP Password, 

you are prompted to enter the password again. 

Note: By default, you cannot use an ! (exclamation) character in the tipadmin 

password on Windows systems. It results in errors in the TBSM trace logs, RAD 

shell does not connect to the Data server, and no RAD shell prompt is displayed. 

For information about addressing this issue, see the Troubleshooting section of the 

TBSM Installation Guide. 

Websphere profile port information 

Specify how you want to assign ports for the WebSphere Application Server in the 

WebSphere port information window. 

Purpose 

To successfully install the server, you need to configure the Websphere ports used 

by Tivoli Integrated Portal. 

Settings 



You want to specify a port number. This number is used to generate the 

port numbers that the Websphere Application Server uses to communicate 

with the profile for the Dashboard Server component (TIPProfile). 

If you select Starting port number provided, specify the starting port 

number: 

1. In the Starting port number field, type a port number in the range 

1241–65535. 

2. Click Next. The installation program uses the port number provided to 

generate values for the variables. 


Supply the location of a file that provides port values for WebSphere. The 

values within this file will not be validated. Ensure all ports specified are 

available for the TIPProfile. Otherwise, the Dashboard server will not run 

properly. Refer to the following file example: 

#Thu Oct 11 13:33:31 EDT 2010 












REST_NOTIFICATION_PORT=16324 

IPC_CONNECTOR_ADDRESS=16314 

Installing TBSM 83

If you select Modified port value file, specify the full qualified name of 

the file that specifies which ports eWAS will use, and then click Next. 

Configuring the Name Server 

Configure the Name Server to provide registration functionality for the 

deployment components. 

You can define multiple Name Server-port pairs and then associate your current 

installation to multiple Name Servers. Each Name Server port that you provide 

will be tested to check if it is active. If the port is active you will proceed to the 

next step of the installation. If the port is not active you will see a message 

indicating that the port is not active but you will still be able to continue with the 

installation. For the installation to be successful, however, make sure that the 

server-port pair as you have defined is available. 

Important: If you are defining a TBSM server, the current host name and port 

number must be in the list. You will get an error if it is not in the list. 

If you plan to configure failover, this list needs to contain the primary followed by 

the backup for both machines and the lists need to match on both TBSM servers.. 

ObjectServer configuration 

Specify information about the Netcool/OMNIbus ObjectServer in this window. 

Purpose 

To successfully install the server, you need supply information the ObjectServer 

that sends events to Netcool/Impact. By default, the ObjectServer name is set to 

the host name of the system where you are running the installation program. 

Important: If you are using an ObjectServer which was not installed using the 

TBSM installer, you need to apply the TBSM schema changes before proceeding 

with the installation, See the Planning section for more information on 

Netcool/OMNIbus considerations. 

Restriction: You can not specify the same ObjectServer for more that one TBSM 

Data server. Otherwise, your event data will be incorrect for both servers. The only 

time you can use the same ObjectServer is for the primary and backup Data 

servers in a failover environment. 

Choices 


ObjectServer 

The name for the ObjectServer. 

By default, this is set to NCOMS. This name must meet the following criteria: 




ObjectServer host 

The host name of the system where the ObjectServer is installed. 

By default, this is the name of the local host where you are running the 

installer. 


ObjectServer port 

The port number for the ObjectServer. 


1024–65535. This port number must not be in use by another application. 


The user name. 

The default, this is set to root. 


The ObjectServer user password. 

Note: TBSM can be installed with the default ObjectServer user as root 

and a null password, but users cannot use a null password to log in to the 

TBSM Dashboard Server. This is because Integrated Solutions Console and 

Tivoli Integrated Portal do not allow blank passwords. 

Confirmation Password 

Enter the ObjectServer password here again. If this does not match the 

ObjectServer Password, you are prompted to enter the password again. 

Installation worksheet: Dashboard server 

This worksheet helps guide you through the Dashboard server installation. 

Purpose 

Fill out the worksheet before you run the installation program for the Dashboard 

server. Save this worksheet for future reference. 

Worksheet 


Table 9. Dashboard server installation information 

Prompt title 

Installation Directory 

Default value Installed value 


C:\Program 

Files\IBM\tivoli 

User Registry Selection ObjectServer 

Data Integration Service 

configuration 

Database type DB2 

JDBC location install_home/ 

jdbc_drivername 

Database name DIS 

Database Hostname Local host 

Database port Number 50000 



Installing TBSM 85

Table 9. Dashboard server installation information (continued) 

Prompt title 

Dashboard Server 

Configuration 

Default value Installed value 

Dashboard Server 

communication port 

17543 

Data Server Host Local host 

Data Server HTTP Port 17310 

Data Server communication 

port 

17542 

Data Server is a primary in a 

failover configuration 

Not selected 

Dashboard Backup 

Required for failover 

Information 


configuration 

Backup Data Server HTTP 

port 

17310 

Backup Data Server 

communication port 

Tivoli Integrated Portal 

information 

17542 

TIP User ID 

TIP password 

Websphere port information 

tipadmin 

Starting port number 

provided 


(optional) 

Name Server Configuration 

16310 

Host_Name:Port_Number 

ObjectServer Configuration 

TBSM Data_Server 

Host:17310 

ObjectServer NCOMS 

ObjectServer host Local host name where 

installer is running. 

ObjectServer port 4100 



root 

Backup directory for 

Deployment Engine 

Root directory 

Running the Dashboard server installer 

This section describes how to start and run the Dashboard server installation 

program. 



Read the sections that describe all the information you need to complete each 

screen in the installation program. Once you obtain all the information you need, 

fill out the Dashboard server installation worksheet and run the installer, using the 

worksheet as your guide. 

Procedure 










































Installing TBSM 87








8. In the Installation Type window, click Advanced, and then click Next. The 

installation program scans the system and determines what components need 

to be installed. 

9. In the Feature Selection window, remove the selection of OMNIbus and Data 

Server components, so that only Dashboard Server is selected and then click 

Next. 

10. The User Registry Selection window opens. 

For each of the installation screens, specify the required information and click 

Next to proceed to the next window. 

11. After you have enter all the required information, the Pre-Installation window 

opens. Click Install to complete the installation. 

Installing TBSM in silent mode 

A silent installation allows the TBSM installation to progress unattended. 


To install TBSM in silent mode, you must modify the setup.rsp file that is 

included on the product DVD. 

Important: Once you start installing, do not stop the installation or the 

deployment engine might become corrupted. 


If the command does not start, you can display debugging information while you 

run it. 

Displaying debugging information 

Procedure 

If the installer does not start in Windows, launch it while 

holding the Ctrl key to see debug information. 

If the installer does not start in UNIX or LINUX, run the 

command: export LAX_DEBUG=true and rerun the installer. 

1. Modify the setup.rsp file: 

a. Copy the setup.rsp file from the product DVD to a local drive, such as 

c:\temp or /tmp. 

b. Open the setup.rsp file in a text editor, and specify the installation values 

that you want to use for your installation. 

c. Save the modified setup.rsp file. 

2. At the command prompt, enter the command to use the modified setup.rsp 

file. 


For UNIX systems: 

You must unset the DISPLAY before launching the silent or console installation. 

To unset the DISPLAY, enter the command: 

unset DISPLAY 

The commands for each operating system are: 

v AIX ® setup-aix.bin -i silent -f /tmp/setup.rsp 

v Solaris setup-solaris.bin -i silent -f /tmp/setup.rsp 

v zLinux setup-zlinux.bin -i silent -f /tmp/setup.rsp 

v Linux setup-linux.bin -i silent -f /tmp/setup.rsp 

Attention: On UNIX systems without X11 installed, after a successful 

installation the following exception message might display in the log file. 

java.lang.NoClassDefFoundError: sun.awt.X11.XToolkit (initialization failure) 

The installation has been successful, you can ignore this message. 

For Windows systems, you need to run the command as an 

Administrator: 

a. Right-click on the Command Prompt icon and click, Run as Administrator. 

b. In the command window enter the command: 

setup-windows.exe -i silent -f C:\temp\setup.rsp 

Important: When you run the installer through the Windows command 

prompt, the installer launches and proceeds in the background. To receive a 

notification that the installation is complete and the installation log is created, 

you must leave the command prompt window open until the installation is 

completed. 

Examples: The location of the setup.rsp file must be fully qualified. 

If you copied the setup.rsp file to the C:\temp, type the 

following command: 

setup-windows.exe -i silent -f c:\temp\setup.rsp 

If you copied the setup.rsp file to the /tmp, type the following 

command: 

setup-platform.bin -i silent -f /tmp/setup.rsp 

3. Optional: At the command prompt, type the command to set the locale in silent 

mode. For example: setup-windows.exe -i silent -l de -f setup.rsp 


Checking install logs: If there are install errors in silent mode, check the main 

install log file named TBSMInstall-00.log in your home directory. 

Modifying the setup.rsp file 


To run the base installer, a sample pre-filled response file (setup.rsp) is included 

on the TBSM product DVD. The default values provided in the file run an 

advanced installation, which installs everything. 

Installing TBSM 89

To use the sample response file, you can modify default values and provide 

additional values that your installation requires for each field in the file. The file 

contains comments that explain valid values for each field. 

Security note: Because the response file will contain a password in the clear, it is 

advisable to remove the response file from the system after installation. 

Example 

The setup.rsp file contains instructions for the silent install. 

############################################################### 

## 

## InstallAnywhere variables to configure for silent install 

## 

## Usage on Windows: setup-windows.exe -f 

## Usage on Unix: setup-.bin -f 

## 

## Path should be fully-qualified. For example, on Windows, 

## setup-windows.exe -f \temp\setup.rsp 

## will NOT work. 

## setup-windows.exe -f C:\temp\setup.rsp 

## must be used. 

## 

## Notes: 

## - Do not run from terminal services unless running from the console 

## - Computer must be connected to a network and have a valid IP address 

## 

## - For Windows, 

## - Installation ID must be local (not a domain ID) and be Administrator 

## or an ID that has the following permissions: 

## - Act as part of the operating system 

## - Logon as a service 

## - Update the registry 

## - Ensure Secondary Logon service is running 

## - Ensure Server service is running 

## 

## 

## Note: If a different version of TBSM is already installed on the system 

then a new Install user must be used for the new installation. 

############################################################### 

############################################################### 

# Do not change the following line; This indicates to use 

# this file for a silent installation. 

############################################################### 

INSTALLER_UI=SILENT 

############################################################### 

# 

# Set Silent License Acceptance 

# 

# Accept license agreement: remove the number sign (#), 

# for example, LICENSE_ACCEPTED=true 

# 

# If the LICENSE_ACCEPTED is anything other than "true", 

# the installation will exit, no log will be produced, 

# and no indication of failure provided. 

# 

# By removing the number sign (#) and changing the value 

# for LICENSE_ACCEPTED from "false" to "true", you have signified 

# acceptance of the Tivoli Business Service Manager license agreement. 

# 

############################################################### 


#LICENSE_ACCEPTED=false 

############################################################### 

# 

# IBM Tivoli Business Service Manager (TBSM) Install Location 

# 

# The install location of the product. Specify a valid directory 

# into which the product should be installed. 

# To install the product to "C:\Program Files\IBM\tivoli", use 

# USER_INSTALL_DIR=C:\\Program Files\\IBM\\tivoli 

# 

# Windows platform: 

USER_INSTALL_DIR=C:\\Program Files\\IBM\\tivoli 

# UNIX platform: 

#USER_INSTALL_DIR=/opt/IBM/tivoli 

# 

# Decision related. 

# The supported values for IAGLOBAL_INSTALL_LOCATION_SELECTION are 

# "create" and "reuse". 

# 

# Select "reuse" if you want to reuse an existing TIP location. 

# 

IAGLOBAL_INSTALL_LOCATION_SELECTION=create 

# 

# If you are re-using an existing TIP, USER_INSTALL_DIR needs to be 

# set to the location of TIP_HOME for the TIP instance you are re-using. 

# Typical TIP_HOME locations are "C:\\Program Files\\IBM\\tivoli\\tipv2" 

# and "/opt/IBM/tivoli/tipv2". 

# 

############################################################### 

############################################################### 

# 

# IBM Tivoli Business Service Manager (TBSM) Backup Location 

# 

# If you are upgrading an existing TBSM or TIP installation, 

# you must specify a location to backup the product. 

# 

# Specify a valid directory into which the product should be 

# backed up. The directory can NOT contain spaces. To backup 

# the product to "C:\IBM", use BACKUP_DIR=C:\\IBM 

# 

# The directory you specify MUST already exist. 

# 

# So in the above example, the directory "IBM" must already exist 

# in order to be a valid directory for backup. 

# 

# Windows platform: 

#BACKUP_DIR=C:\\IBM 

# UNIX platform: 

#BACKUP_DIR=/opt/IBM 

# 

############################################################### 

############################################################### 

# 

# Installation Type 

Installing TBSM 91

# 

# Specify the installation type. Valid values are "default" and 

# "advanced". 

# 

# Simple (default): Install all the software using default values. 

# Not recommended for production environments. 

# 

# Advanced: Install selected software with option to change default 

# values. Recommended for production environments. 

# 

############################################################### 

IAGLOBAL_INSTALL_TYPE_SELECTION=advanced 

############################################################### 

# 

# If performing a default (simple) installation, provide the 

# user IDs and passwords; All other values will be defaulted. 

# All of the database information also needs to be provided. 

# 

############################################################### 

############################################################### 

# 

# WebSphere Information 

# 

# The following is the user ID and password for accessing the 

# TIP profile created on the TBSM Dashboard Server. 

# 

IAGLOBAL_WASUserID=tipadmin 

IALOCAL_WASPassword= 

# 

############################################################### 

######################################################################## 

# 

# Provide the following information for DB2 if installing the 

# TBSM Data Server. 

# 

# Important: The value of IAGLOBAL_DB_TBSM_HOSTNAME must be a 

# fully qualified host name or ip address to prevent the 

# installation of the Discovery Library Toolkit from failing. 

######################################################################### 

IAGLOBAL_DB_TBSM_HOSTNAME= 

IAGLOBAL_DB_TBSM_PORT=50000 

IAGLOBAL_DB_TBSM_DBNAME=tbsm 

IAGLOBAL_DB_TBSM_USERNAME=db2admin 

IALOCAL_DB_TBSM_PASSWORD= 

IAGLOBAL_DB_MARKER_HOSTNAME= 

IAGLOBAL_DB_MARKER_PORT=50000 

IAGLOBAL_DB_MARKER_DBNAME=tbsm 

IAGLOBAL_DB_MARKER_USERNAME=db2admin 

IALOCAL_DB_MARKER_PASSWORD= 

IAGLOBAL_DB_HISTORY_HOSTNAME= 

IAGLOBAL_DB_HISTORY_PORT=50000 

IAGLOBAL_DB_HISTORY_DBNAME=tbsmhist 

IAGLOBAL_DB_HISTORY_USERNAME=db2admin 

IALOCAL_DB_HISTORY_PASSWORD= 

############################################################### 


# 

# If performing an ADVANCED installation, the following can be 

# tailored to your environment; If using this file for a 

# simple installation, no further editing of this file is 

# necessary. 

# 

############################################################### 

############################################################### 

# 

# Features 

# 

# Specify the features to be installed; valid values are 

# "true" and "false". 

# 

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# 

# 

# OMNIbus Feature 

# 

IAGLOBAL_INSTALL_OMNI_FEATURE=true 

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# 

# 

# EIF Probe Feature 

# 

# Note that the variable IAGLOBAL_OBJECTSERVER_PRIMARY_HOST 

# must be set when the following variable is set to "true". 

# 

IAGLOBAL_INSTALL_EIF_PROBE_FEATURE=false 

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# 

# 

# TBSM Feature 

# 

# This should be set to "true" if installing TBSM Data 

# or Dashboard Server(s) or any subfeature of TBSM 

# Dashboard Server. 

# 

IAGLOBAL_INSTALL_TBSM_FEATURE=true 

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# 

# 

# TBSM Data Server 

# 

IAGLOBAL_INSTALL_TBSM_DATASVR=true 

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# 

# 

# TBSM Dashboard Server 

# 

IAGLOBAL_INSTALL_TBSM_DASHSVR=true 

############################################################### 

# # 

# End of features to be installed # 

# # 

############################################################### 

############################################################### 

# 

# User Registry Selection 

# 

# Provide the following if either the TBSM Data Server or 

# Dashboard Server is being installed 

Installing TBSM 93

# 

# Select the type of user registry to be used for user 

# management and authentication. 

# 

# Note: The local file based registry can be used for 

# stand-alone or proof of concept installations. The local 

# file based registry should be selected if configuring LDAP, 

# after installation is complete. The default is using OMNIbus 

# for authentication. 

# 

# The value specified for IAGLOBAL_USER_REGISTRY_FILE_SELECTED 

# should be "1" if local file based registry, "0" if OMNIbus 

# (ObjectServer) registry. 

# 

IAGLOBAL_USER_REGISTRY_FILE_SELECTED=0 

# 

############################################################### 

############################################################### 

# 

# Provide the following information if either TBSM Data Server 

# or TBSM Dashboard Server (or both) is being installed. 

# 

# Note: if installing TBSM Data Server or TBSM Dashboard Server 

# on different machines, do not use "localhost" for the host name. 

# 

# Host name for the Data Server 

IAGLOBAL_DATA_HOSTNAME= 

# Communication port that the Dashboard Server(s) will use to 

# communicate with the data server 

IAGLOBAL_DATA_RMI_PORT=17542 

# If this data server will be configured as a backup server in 

# a failover configuration, set the following to "YES" 

SVR_TYPE_CHKBOX_SELECTION=NO 

# Impact Server command line port 

IAGLOBAL_NCI_CMD_LINE_PORT=2001 

# 

############################################################### 

############################################################### 

# 

# WebSphere Port Setup 

# 

# Ports used by TBSM Dashboard Server (TIP) Profile. 

# These ports only need to be provided if installing TBSM Dashboard Server. 

# 

IAGLOBAL_WC_defaulthost=16310 

IAGLOBAL_WC_defaulthost_secure=16311 

IAGLOBAL_BOOTSTRAP_ADDRESS=16312 

IAGLOBAL_SOAP_CONNECTOR_ADDRESS=16313 

IAGLOBAL_IPC_CONNECTOR_ADDRESS=16314 

IAGLOBAL_WC_adminhost=16315 

IAGLOBAL_WC_adminhost_secure=16316 

IAGLOBAL_DCS_UNICAST_ADDRESS=16318 

IAGLOBAL_ORB_LISTENER_ADDRESS=16320 

IAGLOBAL_SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=16321 

IAGLOBAL_CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=16322 


IAGLOBAL_CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=16323 

IAGLOBAL_REST_NOTIFICATION_PORT=16324 

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# 

# 

# Specify the ports used by the TBSM Data Server Profile. 

# These ports only need to be provided if installing TBSM Data Server. 

# 

IAGLOBAL_TBSM_WC_defaulthost=17310 

IAGLOBAL_TBSM_WC_defaulthost_secure=17311 

IAGLOBAL_TBSM_BOOTSTRAP_ADDRESS=17312 

IAGLOBAL_TBSM_SOAP_CONNECTOR_ADDRESS=17313 

IAGLOBAL_TBSM_IPC_CONNECTOR_ADDRESS=17314 

IAGLOBAL_TBSM_WC_adminhost=17315 

IAGLOBAL_TBSM_WC_adminhost_secure=17316 

IAGLOBAL_TBSM_DCS_UNICAST_ADDRESS=17318 

IAGLOBAL_TBSM_ORB_LISTENER_ADDRESS=17320 

IAGLOBAL_TBSM_SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=17321 

IAGLOBAL_TBSM_CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=17322 

IAGLOBAL_TBSM_CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=17323 

IAGLOBAL_TBSM_REST_NOTIFICATION_PORT=17324 

############################################################### 

# 

# Netcool/Impact uses the Netcool Name Server to publish its services. 

# This is required to be defined for all advanced installations. 

# 

# Please provide the following information: 

# 

# - no default - provide the fully qualified 

# hostname for the data server (primary followed by backup if 

# setting up a failover environment) 

# - no default - provide the IAGLOBAL_TBSM_WC_defaulthost 

# for the data server 

# 

# Please uncomment and enter Name Server and port pairs. 

# Between each Name Server and its port a colon sign (:) is required 

# and between Name Server and port pairs a comma sign (,) is required. 

# 

# For example, 

# IAGLOBAL_NAMESERVER_HP=jimmy5.responsible.com:17310,simplysam.net 

:17310,127.0.0.1:17310 

# This is an ordered list and the first entry in the list 

# will be used as the default Name Server. 

# 

# For Dashboard Server only installs, please provide valid fully qualified 

# host name and port combination for the dataserver 

# 

# IAGLOBAL_NAMESERVER_HP=:, 

: 

# 

############################################################### 

############################################################### 

#---- 

#---- Set eWAS server initial jvm heap size. 

#---- There are 2 jvm servers that will be created on a full 

#---- install (1 for a Dash Board Server Only or Data Server Only 

#---- install). These variables will allow the customer 

#---- to adjust the jvm heap size at install time. 

#---- IAGLOBAL_EWAS_MIN_HEAP_SIZE - for Impact Server, minimum 

#---- jvm heap size, this value is for the Impact 

#---- Server - default 256 as shown 

Installing TBSM 95

#---- IAGLOBAL_EWAS_MAX_HEAP_SIZE - for Impact Server, maximum 

#---- jvm heap size, this value is for the Impact 

#---- Server - default 1200 as shown (1.2 meg) 

#---- IAGLOBAL_TIP_EWAS_MIN_HEAP_SIZE - for Impact Server, minimum 

#---- jvm heap size, this value is for the GUI (TIP-based) 


#---- IAGLOBAL_TIP_EWAS_MAX_HEAP_SIZE - for Impact Server, minimum 

#---- jvm heap size, this value is for the GUI (TIP-based) 


#---- To change the default values remove the "#" that starts the 

#---- line of the jvm heap size value you wish to modify and update 

#---- the value to the value you would like. 

#IAGLOBAL_EWAS_MIN_HEAP_SIZE=256 

#IAGLOBAL_EWAS_MAX_HEAP_SIZE=1200 

#IAGLOBAL_TIP_EWAS_MIN_HEAP_SIZE=256 

#IAGLOBAL_TIP_EWAS_MAX_HEAP_SIZE=512 

# 

############################################################### 

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- 

# 

# Discovery Library Toolkit Panels 

# 

# Provide the following information if the Discovery Library Toolkit is 

being installed, 

# The Discovery Library Toolkit always gets installed during a simple 

install or an advanved 

# install when the data server is being installed. 

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- 

#Export Information 

# 

# migrateExport41xNo=1 

# migrateExport41xYes=0 

# 

# Indicates whether or not an export file exists. Specify "1" 

# if an export file will be provided. Any other value indicates 

# that a file will not be provided. 

#-------------------------------------------------fMigrateExport=0 

# 

# If migrateExport41xYes=1 is specified, then the following variable 

# identifies the folder that contains the export file. 

#-------------------------------------------------- 

EXPORT_DIR_LOCATION=C:/Program Files/IBM/tivoli/discovery/dlbooks 

# 

# TBSM_SSL_NO=1 

# TBSM_SSL_YES=0 

# 

# Indicate whether SSL will be used when connecting to the TBSM 

# Data Server. Specify "1" if SSL should be used. Any other 

# value indicates that SSL will not be used. 

# ------------------------------------------------fTbsmSSL=0 

#TBSM Data Server Failover Connectivity 

# 

# Indicates whether TBSM has been setup in a failover configuration. 

# Specify "1" if failover has been configured. Any other value 

# indicates that failover has not been configured. 

#-------------------------------------------------- 


fTbsmFailoverConfigured=0 

# 

# If failover has been configured, this property indicates 

# whether this toolkit is the primary or backup toolkit. 

# Specify "1" if this toolkit is the primary toolkit. Any 

# other value indicates that this toolkit is the backup. 

# If failover is not configured, specify "1". 

#-------------------------------------------------fTbsmPrimaryToolkit=1 

# 

# Specifies information that will allow the toolkit to connect to 

# the second TBSM data server when failover is configured 

# If failover is not configured, then specify the same values as 

# was specified for tbsmhostname and tbsmport. 

#-------------------------------------------------tbsmhostnamefailover= 

tbsmportfailover=17310 

# 

# TBSM_FAILOVER_SSL_NO=1 

# TBSM_FAILOVER_SSL_YES=0 

# 

# Indicate whether SSL will be used when connecting to the TBSM 

# Failover Data Server. Specify "1" if SSL should be used. Any 

# other value indicates that SSL will not be used. 

# ------------------------------------------------fTbsmFailoverSSL=0 

#Data Source and Database Selections. 

# 

# Specifies whether books, TADDM, or both will be data sources for the 

# toolkit. Specify "1" for each data source that applies. 

#-------------------------------------------------- 

41sourceBooks=1 

41sourceTaddm=0 

# 

# tbsmAutoInvalidateNo=0 

# tbsmAutoInvalidateYes=1 

# 

# Indicates whether or not the toolkit should automatically invalidate 

# the TBSM service tree after importing data. Specify "1" if running 

# with a TBSM Data Server. Specify "0"if the toolkit # is running with 

# Impact and without a TBSM data server. 

#-------------------------------------------------fAutoInvalidate=1 

#TADDM Connectivity Configuration 

# 

# Specifies information for connection to the TADDM server. This is 

# required if 41sourceTaddm=1 is specified. 

#-------------------------------------------------taddmid=administrator 

taddmpw= 

taddmpw2= 

taddmhostname= 

taddmport=9530 

taddmsslport=9531 

# 

# taddmSslNo=1 

# taddmSslYes=0 

# 

# Indicate whether SSL will be used when connecting to the TADDM 

Installing TBSM 97

# Server. Specify "1" if SSL should be used. Any other 

# value indicates that SSL will not be used. 

# ------------------------------------------------fTaddmSSL= 

#TADDM Database Configuration 

# 

# Specifies information for connecting to the TADDM database 

#-------------------------------------------------taddmdbuserid=db2inst1 

taddmdbpw= 

taddmdbpw2= 

taddmdbhostname= 

taddmdbport=50000 

taddmdbname=CMDB 

taddmdbschema=db2inst1 

# 

# Specifies the type of database used by the TADDM server. 

# Speicfy "DB2" if DB2 or "Oracle" if TADDM is using Oracle. 

# ------------------------------------------------- 

IA_DLT_TADDM_DB_TYPE=DB2 

# 

# If the TADDM database is Oracle, then the location of 

# the JDBC drivers is needed. This property identifies 

# the directory containing the Oracle JDBC jar files. 

# 

# The Oracle JDBC drivers are not shipped with TBSM, 

# so a customer specific directory will be needed. 

# ------------------------------------------------oracleJdbcDirectory= 

#TBSM Discovery Library Book Import Configuration 

# 

# The directory that the toolkit will monitor for new books. 

# This will be used if 41sourceBooks=1 is specified. 

#-------------------------------------------------- 

DL_BOOK_LOCATION=C:/Program Files/IBM/tivoli/tbsm/discovery/dlbooks 

#TBSM Discovery Library Book Export Configuration 

# 

# The directory that the toolkit will write books to when 

# the genidml script is run. 

#-------------------------------------------------- 

DL_BOOK_EXPORT_LOCATION=C:/Program Files/IBM/tivoli/tbsm/discovery/dlbooks 

# 

# This information is included in the book that the genidml 

# script generates. This allows for launch-in-context back 

# to TBSM if the book is read by another product. 

#-------------------------------------------------dashboardServer= 

dashboardPort=16311 

# 

# Indicates if the DLT is being installed silently by the TBSM 

# base installer. The accepted values are : 

# true = DLT is being installed silently by the TBSM. 

# false = DLT is NOT being installed silently by the TBSM. 

# 

# The default value : false 

# 

#-------------------------------------------------- 

DL_TBSM_Silent_Install=true 

# Toolkit naming service RMI registry port 


# 

#-------------------------------------------------toolkitrmiport=12315 

############################################################### 

# 

# TBSM Dashboard Server Information 

# 

# Provide the following information if installing the TBSM 

# Dashboard Server. 

# 

# Host name of this machine 

# Note: if installing TBSM Dashboard Server and TBSM Data Server 

# on different machines, do not use "localhost" for the host name 

IAGLOBAL_DASH_HOSTNAME= 

# Communication port that the Data Server will use to 

# communicate with this Dashboard Server: 

IAGLOBAL_DASH_RMI_PORT=17543 

# HTTP port of the Data Server 

# Note: If TBSM Data Server is being installed at the same time, 

# this value was provided above. If installing only a TBSM 

# Dashboard Server, uncomment the following line and 

# provide the value for IAGLOBAL_TBSM_WC_defaulthost provided 

# during the TBSM Data Server installation 

#IAGLOBAL_DATA_HTTP_PORT=17310 

# 

# If the Data Server is running in failover, provide the 

# information for the backup Data Server. 

# 

# Host name for the backup Data Server 

IAGLOBAL_BKUP_DATA_HOSTNAME= 

# HTTP port of the backup Data Server 

# (Also known as: IAGLOBAL_TBSM_WC_defaulthost) 

IAGLOBAL_BKUP_HTTP_PORT=17310 

IAGLOBAL_BKUP_RMI_PORT=17542 

# 

############################################################### 

############################################################# 

# 

# Data Interchange Services Configuration Information 

# 

# The following information is required for an advanced install of 

# the TBSM dashboard server 

# 

# Configure Data Interchange Services database: 

# - The database type, the supported values are "DB2", "MSSQL" and "Oracle", 

# for example, IAGLOBAL_DIS_DB_TYPE=DB2 

# 

IAGLOBAL_DIS_DB_TYPE= 

# 

# - The Path to the JDBC driver jar files 

# for example, 

# IAGLOBAL_DIS_DB_DRIVER_CP=C:\\Program Files\\IBM\\SQLLIB\\java 

# should be specified if db2jcc.jar and db2jcc_license_cu.jar are located in 

# C:\Program Files\IBM\SQLLIB\java 

Installing TBSM 99

IAGLOBAL_DIS_DB_JDBC_LOCATION= 

# - Database hostname 

# - Database port for example IAGLOBAL_DIS_DB_PORT=50000 

# - Database name for example IAGLOBAL_DIS_DB_NAME=DIS 

# - The database login username 

# - The database login password 

# 

IAGLOBAL_DIS_DB_HOSTNAME= 

IAGLOBAL_DIS_DB_PORT= 

IAGLOBAL_DIS_DB_NAME= 

IAGLOBAL_DIS_DB_USER= 

IAGLOBAL_DIS_DB_PASSWORD= 

# 

############################################################### 

############################################################### 

# 

# OMNIbus (Object Server) Information 

# 

# If OMNIbus is being installed, provide the machine, 

# user ID and a password (optional). If no password is provided 

# a user ID with an empty password will be created. 

# In the case of the default (simple) installation, the user 

# and password fields cannot be provided and will default 

# to root and empty password. 

# 

# If an advanced installation is being performed and OMNIbus 

# is NOT being installed, the TBSM Data Server and/or 

# Dashboard Server will need to reference an existing OMNIbus. 

# If this is the case, provide the machine, user ID and 

# password for accessing that Object Server. 

# 

############################################################### 

IAGLOBAL_OBJECTSERVER_PRIMARY_HOST= 

IAGLOBAL_OBJECTSERVER_PRIMARY_NAME=NCOMS 

IAGLOBAL_OBJECTSERVER_USER=root 

IALOCAL_OBJECTSERVER_PASSWORD= 

IAGLOBAL_OBJECTSERVER_PRIMARY_PORT=4100 

############################################################### 

#---- 

#---- Netcool/Impact uses version control for its configuration files (property 

#---- files, data types and policies). You can use an existing version control 

#---- system or the SVN package bundled with Netcool/Impact. 

#---- Please provide the following information: 

#---- 

#---- VERSION_CONTROL_TYPE values are: 

#---- IMPACT_SVN - this is also default value 

#---- SYSTEM_SVN 

#---- SYSTEM_CVS 

#---- RCS 

# CLEARCASE 

IAGLOBAL_VERSION_CONTROL_TYPE=IMPACT_SVN 

#---- 

############################################################### 

############################################################### 

#---- 


#---- Netcool/Impact needs to know where to find your version control system. 

#---- Please enter the fully qualified path to the binaries (for example 

#---- $CVSHOME/bin for CVS). 

#---- This is defined if VERSION_CONTROL_TYPE=SYSTEM_SVN|SYSTEM_CVS|RCS|CLEARCASE 


#---- 

#---- VERCTLPATH - no default - must be fully qualified 

#---- Remove string between < and > and also remove < and > when 

#---- providing your path. 

IAGLOBAL_VERCTLPATH= 

#---- 

############################################################### 

############################################################### 

#---- 

#---- Please select the directory of your cvs repository (the same location 

#---- you would use for the CVSROOT environment variable or the -d option). 

#---- This is defined if VERSION_CONTROL_TYPE=SYSTEM_CVS 


#---- 

#---- VERCTL_REPOSITORY - no default - must be fully qualified 

#---- Remove string between < and > and also remove < and > when 

#---- providing your path. 

IAGLOBAL_VERCTL_REPOSITORY= 

############################################################### 

# 

# Tivoli EIF Probe Configuration 

# 

# Specify the following items for setting up the Tivoli EIF Probe: 

# - The listening port for the Probe to use 

# - Setup the Probe for failover ("true" or "false") 

# - Setup the Probe as a Windows service ("true" or "false") (Windows ONLY) 

# 

IAGLOBAL_PROBE_LISTENING_PORT=9998 

IAGLOBAL_PROBE_SETUP_FAILOVER=false 

IAGLOBAL_PROBE_SETUP_SERVICE=false 

# 

############################################################### 

############################################################### 

## End of silent installation information 

############################################################### 

Installing TBSM using the console 

Use the console installation when the graphical user interface is not available. 

Console installation provides command-line prompts to input data. 


The setup file for console installation is in /TBSM directory or the installation 

package or DVD. 

For UNIX systems, at the command prompt, enter the following 

commands to install TBSM in console mode: 

Installing TBSM 101

Uninstalling TBSM 

unset DISPLAY 

setup-.bin/exe –i console 

Where is one of this operating system names: 

v aix 

v solaris 

v zlinux 

v linux 

For example, on a Linux platform, the command is: 

unset DISPLAY 

./setup-linux.bin -i console 

For Windows systems, you need to run the command as an 

Administrator: 

1. Right-click on the Command Prompt icon and click, Run as Administrator. 

2. In the command window enter the command: 

setup-windows.exe -i console 

The console installation program prompts you for the same information as the 

launchpad-based installation program. 


“Command-line (console) installation” on page 148 

Command-line installation can be useful when installing from the graphical user 

interface is not feasible. Command-line installation provides prompts for your 

input data. 

This section describes procedures for uninstalling TBSM. 


The uninstall procedure is only used to remove an installation that completes 

successfully. If the install fails before it completes, use the procedure: Restoring 

system from a backup. 

The uninstall procedure removes all components that were installed with the TBSM 

installation program. 


“Upgrading TBSM” on page 109 

This section describes how to upgrade TBSM from TBSM version 6.1 If you have a 

TBSM 4.2x system, you must migrate the system to version 6.1 before you attempt 

an upgrade. 


“Restoring system from a backup” on page 107 

This topic describes how to restore the system back to the original state using the 

backup that was create during an installation or upgrade that did not complete 

successfully. 

Uninstalling TBSM on Windows 

To uninstall TBSM on windows: 



Make sure that you have rebooted the system at least once since TBSM was 

installed. Otherwise you may encounter problems during the uninstallation 

process. 

Procedure 

1. Stop all TBSM servers (Data, Dashboard) and Discovery Library toolkit 

Windows services). 

2. Change to the installDir\tbsm\_uninst\TBSMInstall611 directory and issue 

the uninstall.exe command. 

3. Read the information about the Welcome panel and click Next. 

4. If the TBSM Dashboard server or Data server have been installed, supply the 

user ID and password for Tivoli Integrated Portal. The user ID needs 

administrator permissions. For example, the tipadmin user. 

5. A screen indicating progress of the uninstall displays. The moving status bar 

is updated as the uninstallation process progresses. 

6. Read the post-uninstallation summary information and click Finish. 

7. Reboot the computer after the uninstallation process finishes. 

8. If all the Tivoli Integrated Portal products have been removed, delete the 

installDir directory. 

9. Remove installer log files. In the install user's home directory, delete all 

TBSMInstall*.log files. 

10. Uninstall the Deployment Engine. Ensure that all products that use the 

Deployment Engine have been removed before you uninstall it. To uninstall 

the Deployment Engine, run these commands: 

a. Change to the C:\Program Files (86)\IBM\Common\acsi directory: 

b. run setenv 

c. cd bin 

d. si_inst -r -f 

e. rmdir C:\Program Files\IBM\Common\acsi /s 

Uninstalling TBSM on UNIX 

Procedure 

1. Stop all TBSM servers (Data, Dashboard) and Discovery Library toolkit 

Windows services). 

2. Change to the installDir/tbsm/_uninst/TBSMInstall611 directory and issue 

the ./uninstall command. 

3. Read the information about the Welcome panel and click Next. 

4. If the TBSM Dashboard server or Data server have been installed, supply the 

user ID and password for WebSphere. WebSphere must be running for the 

login to succeed. 

5. A screen indicating progress of the uninstall is displayed. The moving status 

bar is updated as the uninstall progresses. 

6. If all the Tivoli Integrated Portal products have been removed, delete the 

directory. 

7. Remove installer log files. In the install user's home directory, delete all 

TBSMInstall*.log files. 

Installing TBSM 103

Reinstalling TBSM 

8. Uninstall the Deployment Engine. However, other products might use the 

Deployment Engine, so removing it might cause conflicts. To remove it, use the 

following manual commands. If Deployment Engine was installed from root: 

a. cd /var/ibm/common/acsi/bin 

b. . ./set inst.sh -r -f 

c. rm -rf /var/ibm 

d. rm -rf /usr/ibm 

If the Deployment Engine was installed as non-root: 

a. cd /home/user/.acsi_hostname 

b. . . /setenv.sh 

c. cd bin 

d. ./si_inst.sh -r -f 

e. rm -rf /home//.acsi_ 

Before performing an installation on UNIX following an uninstall procedure, the 

Netcool/OMNIbusprocess might still be running. Use the ps -ef | grep omni 

command to locate the Netcool/OMNIbus process. End the process that appears. 

Reinstalling TBSM after a failed installation 

If the TBSM installer fails, you can restore the system to its original state and 

install TBSM again. 

Procedure 

1. If the installer does not prompt for a backup directory during the failed 

installation, complete the following steps to restore the system back to the 

original state: 

v For Windows operating systems: 

a. Rename the deployment engine (DE) directory from c:\Program 

Files(x86)\IBM\Common\acsi to c:\Program Files(x86)\IBM\Common\ 

acsi.bak. 

b. Rename the DE directory from c:\Program Files\IBM\Common\acsi to 

c:\Program Files\IBM\Common\acsi.bak 

c. Rename the InstallAnywhere directory from c:\Program Files\Zero G 

Registry to c:\Program Files\Zero G Registry.bak 

d. Rename the InstallAnywhere directory from c:\Program Files(x86)\Zero 

G Registry to c:\Program Files(x86)\Zero G Registry.bak 

e. Rename the failed installation directory. For example, rename 

com\ibm\tivoli to com\ibm\tivoli.bak 

v For UNIX operating systems: 

a. From the user home directory, rename the DE directory from 

.acsi_ to .acsi_.bak 

b. From the user home directory, rename the DE directory from 

.acsi_ to .acsi_.bak 

c. From the user home directory, rename the InstallAnywhere directory from 

.com.zerog.registry.xml to .com.zerog.registry.xml.bak 

d. Rename the failed installation directory. For example, rename 

com/ibm/tivoli to com/ibm/tivoli.bak 


2. If the installer does prompt for a backup directory during the failed installation, 

restore the system. For more information about how to do so, see “Restoring 

system from a backup” on page 107. 

3. Install TBSM again. 

a. Navigate to the directory that contains the installation image. 

b. To run the installer again: 

v For Windows operating systems, right-click the launchpad64.exe file and 

click Run as Administrator. 

v For UNIX operating systems, From the directory that contains 

launchpad.sh, issue the command ./launchpad.sh command. 

Installing TBSM 105


Restoring system from a backup 



successfully. 


The procedure is for a TBSM system that was installed to an existing Tivoli 

Integrated Portal server directory or any installation that did not complete 

successfully. 


To restore a TBSM system, first stop all the servers. 

Procedure 

1. Stop the Tivoli Business Service Manager servers. 

Stop the services: 

v Netcool/OMNIbus Object Server 

v NCO Process Agent 

v Tivoli Business Service Manager - TBSMProfile_Port_17310 

v Tivoli Integrated Portal - V2.2_TIPProfile_Port_16310 

v If TBSM Discovery Library toolkit is also running, please also stop the 

service: Tivoli BSM Discovery Library toolkit 

$TBSM_HOME/bin/tbsm_suite.sh stop 

2. Stop all non TBSM applications that use IBM/tivoli/tipv2 directory. 

3. To restore DE and the TBSM application from backup. 

Run this command: from the TBSM DVD image: 

restore.(bat/sh)backup_directory 

where backup_directory is the directory you specified during the installation 

4. Restart the TBSM servers: 

Reboot the system. 

Start TBSM with the command: 

$TBSM_HOME/bin/tbsm_suite.sh start 





an upgrade. 


“Uninstalling TBSM” on page 102 




Upgrading TBSM 



an upgrade. 

When you upgrade a system, these items are upgraded: 

v The IBM Deployment engine 

v If the TBSM Dashboard server is installed: 

– Upgrades TBSM Dashboard server 

v If the TBSM Data Server is installed: 

– Upgrades TBSM Data server 

CAUTION: 

UNIX only - Symbolic links created "inside" the installation directory are not 

followed and thus are not included in the automatic TBSM backup. If there are 

concerns about the files being changed for the directories that are represented 

by these links, then the you must back up those directories before running the 

TBSM upgrade program. 

Upgrade prerequisites 

The following items must be completed manually before upgrading TBSM: 

1. Upgrade the Netcool/OMNIbus WebGUI to version 7.3.1 Fix Pack 5 or later. 

Check the Fix Pack down load page for the latest version. 

Netcool/OMNIbus Fix Pack download: To obtain the latest Netcool/OMNIbus 

WebGUI fix pack, see the Fix Central page at: 


selectFixes?parent=ibm~Tivoli&product=ibm/Tivoli/Tivoli+Netcool+OMNIbus 

&release=7.3.1.4&platform=All&function=all 

2. Install the latest TBSM 6.1 fix pack and Tivoli Integrated Portal 2.2 upgrade as 

needed. As of the TBSM 6.1.1 release, this was TBSM 6.1.0.1 (fix pack 1), and 

Tivoli Integrated Portal version 2.2.0.11, but check for a more recent version at: 

TBSM Fix Pack download: To obtain the latest TBSM fix pack, see the Fix 

Central page at: 

http://www-933.ibm.com/support/fixcentral/swg/selectFixes?parent=ibm/ 

Tivoli&product=ibm/Tivoli/Tivoli+Business+Service+Manager&release=All 

&platform=All&function=fixId&fixids=6.1.0-TIV-BSM-FP0001* 

&includeSupersedes=0 

Tivoli Integrated Portal upgrade download: To obtain the latest Tivoli 

Integrated Portal upgrade, see the Fix Central page at: 


selectFixes?parent=ibm~Tivoli&product=ibm/Tivoli/Tivoli+Integrated+Portal 

&release=All&platform=All&function=all 


Table 10. TBSM 6.1.1 server host prerequisites 

TBSM servers on host Upgrade prerequisite 

Data server only Install the latest TBSM Fix Pack. 

Dashboard server only v Upgrade to the latest Tivoli Integrated Portal version. 

v Install the latest TBSM Fix Pack. 

Data server and Dashboard 

server on the same host 

v Upgrade to the latest Tivoli Integrated Portal version. 

v Install the latest TBSM Fix Pack. 

3. Before you upgrade TBSM 6.1.0.1 to version 6.1.1, complete the following steps 

to prevent exceptions from occurring after you upgrade: 

a. Log in to the TBSM console as an administrative user. 

b. In the navigation tree, expand System Configuration > Event Automation 

click Data Model to open the Data Model tab. 

c. From the project list, select the project EventIsolationAndCorrelation. 

d. In the Data Model tab, double-click each of the following data sources to 

Edit and then click Save. 

v EIC_alertsdb 

v SCR_DB 

v EventrulesDB 

4. Make sure that there are no locked Netcool/Impact data files. The file 

TBSM_HOME/etc/TBSM_versioncontrol.locks shows the locked files for each user. 

To unlock files: 

a. Log in to the TBSM console as an administrative user. 

b. In the navigation tree, expand System Configuration -> Event Automation 

-> Data Model. 

c. From the Project list, select Global . 

d. Click Unlock All to unlock all files being edited by the current user. 

e. Contact any other users that have locked files and require them to follow 

these instructions to unlock files. 

f. Alternatively, the administrator can right click on any locked files and select 

Unlock from the menu. 

5. Prepare the TBSM servers for upgrade. 

a. All users must log off the TBSM consoles. The servers are restarted during 

the upgrade process. However, the server is not available for use during the 

upgrade process. 

b. Stop all the TBSM 6.1.0.1 servers. That is, stop the primary and backup Data 

servers and all the Dashboard servers. 

c. Stop the Discovery Library Toolkit. 

6. Run the version 6.1.1 Discovery Library Toolkit installer on the TBSM Data 

Server to upgrade the database schema. 

Note: Backup your TBSM DB2 databases before you run the DL toolkit 

installer. 

You can launch the Discovery Library Toolkit installer either from the 6.1.1 

launchpad or on the installation image from the directory 

/DiscoveryLibrary/setup-dltoolkit-platform. 

For example: 


Windows: 

windows\DiscoveryLibrary\setup-dltoolkit-windows_64.exe 

Linux: 

linux/DiscoveryLibrary/setup-dltookit-linux_64.bin 

7. Start the Discovery Library Toolkit. When the Discovery Library Toolkit has 

started, continue with the upgrade of the TBSM servers. 

Retaining your 6.1 system and 6.1.1 

If you want to keep your existing 6.1 system while also running the 6.1.1 release, 

you can copy your 6.1 system to another host before you upgrade. Use one of 

these methods: 

Clone your existing 6.1 system to a new host as described in Cloning your TBSM 

servers in this guide. 

OR 

Replicate your 6.1 system using your internal Disaster Recovery procedures. 

Backup directory 

During the upgrade or fix pack installation, you are prompted to select a backup 

directory for your TBSM files. 

It is best practice to manually backup the Deployment Engine (DE) and the entire 

TBSM product directory before you upgrade. Use the following procedure to back 

up DE and TBSM product: 

1. To manually back up TBSM product directory, back up the following 

directories: 

For Windows (assuming, you installed to this directory): 

c:\program files\IBM\tivoli 

For Unix (assuming, you installed to this directory): 


2. To manually back up the deployment engine (DE) directory, back up the 

following directories: 

For Windows backup 

c:\Program Files\IBM\Common\acsi 

For UNIX, back up 

.acsi_ 

where ; is the home directory of the user who installed TBSM 6.1 

and ; is host name of the server where TBSM is installed. 

You may see this error message: 

The directory is invalid. The backup cannot be created in the same path 

as the reuse of a previous install." 

Upgrading TBSM 111

The incorrect error message displays because the path you entered includes the 

installation directory: /opt/IBM/tivoli. The system finds this path and stops, 

giving the incorrect message. You must specify a directory that does not include 

the installation directory name within it. 

Important: The directory that is specified for the location of the TBSM backup 

must exist, and the user that is running the upgrade must have write permission to 

that directory. 

Maintenance directory: The maintenance directory that is created during 

installations of TBSM interim fixes is deleted during the upgrade process. The 

maintenance directory is included in the automatic TBSM backup and any data 

that is stored in that maintenance directory can be retrieved from the backup. 

Selecting the installation directory 

When you run the upgrade program, it searches your host for instances of Tivoli 

Integrated Portal and displays a list of directories in the Select Installation 

Directory window. 

Restriction: The TBSM 6.1.1 upgrade can be installed only on TBSM version 6.1.0.1 

(fix pack 1) or later. 

If any of these directories refer to a TBSM instance, the list includes a description 

of the server and version. For example: 

C:\IBM\tivoli\tipv2 -- TBSM Dashboard Server 6.1 

Select the directory that you want to use and the upgrade program checks if 

directory contains the correct version of TBSM. If it is not TBSM version 6.1.0.1 (fix 

pack 1), the upgrade program displays a warning message. Select another directory 

or install fix pack 1 on your 6.1 instance before you install the upgrade. 

TBSM 4.2.x migration 

You must migrate to TBSM 6.1 before you can upgrade to version 6.1.1. 

For more information about migration, see the TBSM Version 6.1 Fix Pack 1 

information center. 

http://www.ibm.com/developerworks/wikis/display/tivolidoccentral/ 

Tivoli+Business+Service+Manager 

Click Business Service Manager > Installation Guide > Migrating from TBSM 

4.2.x. 

Installing the TBSM 6.1.1 upgrade 

Warning:: The upgrade program may stall at the point where the 

Discovery Library Toolkit starts. Check the bottom of TBSMInstall-00.log for the 

following lines: 

FINE : Run command /opt/IBM/tivoli/tbsm/XMLtoolkit/bin/tbsmrdr_start.sh 

(from com.ibm.ac.coi.ext.ia.tasks.COIExtensionIALog.execute) 

INFO : [echo] Run command /opt/IBM/tivoli/tbsm/XMLtoolkit/bin/tbsmrdr_start.sh 

(from AntRuntime.execute) 

INFO : IALogAppendIt: (from AntRuntime.execute) 


To resume the upgrade installation, open a new command window and run the 

commands: 

$TBSM_HOME/XMLtoolkit/bin/tbsmrdr_stop.sh 

$TBSM_HOME/XMLtoolkit/bin/tbsmrdr_start.sh 

The default path for $TBSM_HOME is the /opt/IBM/tivoli/tbsm/ directory. 

To upgrade a TBSM 6.1.0.1 system: 

1. Select appropriate TBSM 6.1.1 image for your platform. 

2. Run the TBSM launchpad. 

3. In the Launchpad navigation pane, select Install IBM Tivoli Business Service 

Manager 6.1.1 Upgrade. 

4. Click Run the Tivoli Business Service Manager 6.1.1 Upgrade Program. 

5. Select the language that you want, accept the license agreement, and click 

Next when prompted. 

6. Accept the license agreement. 

7. Specify the backup path. 

8. The upgrade program automatically detects and displays the path of all TBSM 

instances previously installed on the system. 

9. Select the TBSM path that you want to upgrade. 

10. Enter the user information for the 6.1.1 system when prompted by the 

upgrade program. 

11. Review the pre-install summary and click install to proceed with the upgrade 

process. 

12. When the upgrade completes, click Done to close the upgrade program. 

13. Restart the server. 

Consitency checker interval change: In version 6.1.1, the default consistency 

checker interval has changed from 5 to 11 minutes. If you upgraded from version 

6.1 and have a different value that is already defined in the 

TBSM_consistency.props file, your value is retained. 

Uninstalling the upgrade 

To uninstall the upgrade, use the procedure that is described in: Installing TBSM > 

Uninstalling TBSM. 

Restoring from backup 

To restore from the backup that was created during the upgrade, use the procedure 

that is described in Installing TBSM > Restoring system from a backup. 

Upgrading TBSM 113

Upgrading a 32-bit system 


“Cloning your TBSM servers” on page 157 

You can clone your existing IBM Tivoli Business Service Manager Data and 

Dashboard servers by completing a sequence of defined procedures and replicating 

any manual changes you have made to the source servers on the target servers. 

However, to complete the cloning operation both the source and target TBSM 

servers must be configured in a similar manner. The steps to create a clone of your 

Data and Dashboard servers are outlined in this section. However, before you 

begin, confirm that the source and target configurations have: 


“Uninstalling TBSM” on page 102 


“Migrating from TBSM 4.2.x” on page 155 



“Restoring system from a backup” on page 107 



successfully. 

Upgrade a 32-bit TBSM version 6.1 to version 6.1.1. 


In this task, you install a new 64-bit instance of version 6.1, clone your 32-bit 

system, and upgrade the 64-bit instance to version 6.1.1. 

Procedure 

1. Install a 64-bit version of TBSM 6.1 on a new system, including a new 

database. 

2. Upgrade the 64-bit version to the latest 6.1 Fix Pack as described in the 

Upgrade prerequisites. 

3. Use the TBSM cloning procedure to copy data from the 32-bit TBSM to the 

64-bit TBSM. See Cloning your TBSM Servers. 

Important: If you have a failover configuration, you only clone the primary 

Data server and Dashboard server. 

Note: If you run TBSM after you restore the database to the 64-bit system, 

you may see the resource display names as internal IDs, rather than display 

names. The display names are restored during the last step of the upgrade 

process. When you upgrade the system to version 6.1.1, the resource display 

names are displayed correctly. 

4. Dashboard server only: If you are upgrading a Dashboard server: 

Upgrade Tivoli Integrated Portal: 

Install the latest Tivoli Integrated Portal Fix Pack on your new 64-bit 

TBSM system, as described in the Upgrade prerequisites. 

Copy Netcool/Impact Operator View files to a temporary directory: 

If you have custom Netcool/Impact Operator Views, copy the 

directory $TBSM_INSTALL_HOME/impact/opview/displays/* to a 

temporary directory. 


If you have custom Operator Views, they have associated policies. If 

these policies are not already part of your Netcool/Impact-specific 

projects, create a project that includes these policies. When you export 

and import your projects later in this procedure, make sure you export 

and import any projects that include the Operator View policies. 

5. Data server only: If you are upgrading a Data server, copy these directories to 

a temporary directory on your 32-bit system. These directories contain 

Netcool/Impact-specific files that are not included in the cloning procedure. 

DSA libraries: 

$TBSM_HOME/dsalib/* 

Web Services: 

$TBSM_HOME/wslib/* 

External DSAs: 

$TBSM_HOME/dsa/* 

HSQL database: 

Stop the Netcool/Impact database before you copy these files. 

a. In the navigation tree, expand System Configuration > Event 

Automation. Click Services to open the Services tab. 

b. Select the ImpactDatabase and stop the service. 

Copy these files database files to a temporary directory:. 

v $TBSM_HOME/db/_impact.data 

v .$TBSM_HOME/db/_impact.script 

v $TBSM_HOME/db/_impact.properties 

Note: is the name of the TBSM data server. In a failover 

environment, the primary server name is TBSM. 

Restart the Netcool/Impact database. 

6. Compress the contents of the temporary directory to a single file, such as a 

zip or gzip file. 

7. Data server only: Copy the compressed file with the Netcool/Impact Data 

Server files to the 64- bit system and unpack the file to the $TBSM_HOME 

directory. 

8. Dashboard server only: Copy the compressed Operator View files to the 

64-bit system and unpack the files to the $TBSM_INSTALL_HOME/impact/opview/ 

displays/ directory. 

9. From the 32-bit system, export the Netcool/Impact-specific projects with the 

nci_export command. The Data server must be running when you run this 

command. You must run this command for each project you want export. If 

you created custom Netcool/Impact Operator Views, make sure you export 

any projects that include the Operator View policies. 

For example, use this command to export the data from the FOO project on the 

TBSM instance to the /tmp/TBSM_export directory: 

$TBSM_HOME/bin/nci_export TBSM --project F00 /tmp/TBSM_export 

10. Compress the contents of the export directory to a single file such as a zip or 

gzip file. 

11. Copy the compressed file to the 64-bit system and unpack the compressed file. 

12. On the 64-bit system, run nci_import to copy the export file to the 64-bit 

system. 

The Data server must be running when you run this command. 

Upgrading TBSM 115

Post upgrade issues 

For example, this command imports the data to the TBSM server from the 

/tmp/TBSM_export directory. 

$TBSM_HOME/bin/nci_import TBSM /tmp/TBSM_export 

13. Upgrade the 64-bit TBSM 6.1.0.1 system to version 6.1.1. 

14. If you have a failover configuration, install your backup 6.1.1 Data server and 

complete the failover configuration. 

15. If you have a load balancing configuration, install the additional Dashboard 

servers and complete the load balancing configuration. 


“Load balancing” on page 212 

You can setup a load balancing cluster of portal nodes with identical 

configurations to evenly distribute user sessions. 

“Cloning your TBSM servers” on page 157 


















Related information: 

Netcool/Impact 6.1 Information Center 

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic= 

%2Fcom.ibm.netcoolimpact.doc6.1%2Fwelcome.html 

When you complete the upgrade, read the following information in case you need 

to make any additional changes to your environment. 

UI menu items do not display correctly 

In the Tivoli Integrated Portal UI in the treeview, after an upgrade the menu items 

might not display correctly. You may see strings similar to the following examples: 

Reporting 

portal.menu.event.auto 

portal.menu.report.acteff 

portal.menu.report.acerr 

portal.menu.report.poleff 

portal.menu.report.polerr 

portal.menu.report.nodeeff 

portal.menu.report.opeff 

portal.menu.report.roi 

portal.menu.report.profile 


System Configuration 

portal.menu.eventauto 

portal.menu.datamodels 

portal.menu.policies 

portal.menu.services 

portal.menu.opviews 

There is an issue with the UI component. To confirm the issue, you can check the 

/impact/logs/update-impactAdmin.log log file. The log file 

shows the following information: 

Tip: The default install location is C:\Program Files\IBM\tivoli for Windows and 

/opt/IBM/tivoli on UNIX based systems. 

UNIX log file location: /impact/logs/update-impactAdmin.log 

ADMA5005I: The application isc is configured in the WebSphere Application Server repository. 

ADMA5011I: The cleanup of the temp directory for application isc is complete. 

Update of isc has ended. 

com.ibm.websphere.management.exception.AdminException: AddBinaryTask failed on fineGrainUpdate. 

at com.ibm.ws.management.application.sync.AddBinaryTask.fineGrainUpdate(AddBinaryTask.java:212) 

at com.ibm.ws.management.application.sync.AddBinaryTask.performTask(AddBinaryTask.java:123) 

at com.ibm.ws.management.application.sync.AppBinaryProcessor$ExpandApp.expand 

(AppBinaryProcessor.java:1682) 

Windows log file location: \impact\logs\updateimpactAdmin.war 

org.eclipse.jst.j2ee.commonarchivecore.internal.exception. SaveFailureException: 

IWAE0017E Unable to replace original archive: 

\tipv2\profiles\TIPProfile\ 

installedApps\Cell\TIPCell\isc.ear\impactAdmin.war 

Resolution: 

v UNIX: 

From TBSM_HOME/bin, run the following command: 

./nc_ant -f ../install/updateEarWar.xml -Dnc_command=deploy -Dnc_type=module 

-Dnc_name=impactAdmin.war -Dnc_passwd= 

Where is your own tipadmin password. 

v Windows: 

From TBSM_HOME\bin, run the following command: 

nc_ant.bat -f ..\install\updateEarWar.xml -Dnc_command=deploy -Dnc_type=module 

-Dnc_name=impactAdmin.war -Dnc_passwd= 

Where is your own tipadmin password. 

Reinstalling TBSM after a failed upgrade 

If the TBSM installer fails during an upgrade, you can restore the system to its 

original state and run the upgrade again. 

Procedure 

1. Restore the system to the original state. For more information about how to do 

so, see “Restoring system from a backup” on page 107. 

2. To run the upgrade again: 

a. Navigate to the directory that contains the installation image. 

b. Run the upgrade again. For more information, see Upgrading TBSM. 

Upgrading TBSM 117


Installing and configuring the TBSM Agent 

Installing the TBSM agent 

The Tivoli Business Service Management agent (TBSM agent) is an IBM Tivoli 

Monitoring distributed agent using a distributed monitoring server. 

These topics describe how to install and configure the agent. They also describes 

the components of the agent such as its work spaces, attribute groups and 

predefined situations. 

The Tivoli Business Service Management agent (TBSM agent) is an IBM Tivoli 

Monitoring distributed agent using a distributed monitoring server. 


If there are no other agents or Tivoli Monitoring components installed prior to 

installing the TBSM agent, then the TBSM agent can be installed as root or 

non-root. In this case, shared library files will have to correct permissions. 

However, if you previously installed other agents or Tivoli Monitoring 

components, you need to install the TBSM agent as the same user that installed the 

other Tivoli Monitoring components. Otherwise, permissions on files such as 

shared libraries may be incorrect, and the TBSM agent may not start. 

You can install and deploy the TBSM agent just like any other Tivoli Monitoring 

agent in your environment. The topics in this section describe the TBSM-specific 

information you need to know to install and deploy the agent. For more 

information on installing and deploying Tivoli Monitoring agents, see Tivoli 

Monitoring information center. 

Important: It is easier to install the agent as the root user on UNIX 

systems. If you want to install as a non-root user, see the Tivoli Monitoring 

information center for detailed instructions. 


Install the TBSM agent if you have IBM Tivoli Monitoring installed at your location 

and you want to do either or both of the following: 

v Use IBM Tivoli Monitoring to monitor the status of TBSM. 

v Use the TBSM Historical Reporting function, which uses the Data Warehouse 

feature of IBM Tivoli Monitoring to record historical TBSM data. 

You can install and deploy the TBSM agent just like any other Tivoli Monitoring 

agent in your environment. The topics in this section describe the TBSM-specific 

information you need to know to install and deploy the agent. For more 

information on installing and deploying Tivoli Monitoring agents, see Tivoli 

Monitoring information center. 

To install the TBSM agent: 


Procedure 

1. From the TBSM Launchpad, click Install the Business Service Manager Agent. 

You can also start the installation from the command line: 

command: 

install.sh 

Configuring the TBSM agent 

Change to the interp/ITM_Agent directory and run the 

Change to the interp/ITM_Agent/WINDOWS directory and run the 

command: 

setup.exe 

2. Click Run the Business Service Manager Agent installation program. 

3. Follow the prompts of the installation using the following reference sections as 

your guide for TBSM-specific information. For most of the prompts, the 

installation program provides all the information and instructions you need to 

install the agent. 

Important: When you are prompted for the IP.PIPE host or IP Address value, 

the default value is the local host name. This value needs be the host where the 

Tivoli Enterprise Monitoring Server (TEMS) is installed. Otherwise, the agent 

with not work. If necessary, correct the IP.PIPE host or IP Address value from 

the Manage Tivoli Monitoring Services window. Right-click the agent and 

select Reconfigure from the menu that opens. 

4. After you install the TBSM Agent and TBSM, you must stop and start the 

TBSM data server to enable the connection between TBSM and the agent. 

The following configuration items must be performed before using the TBSM agent 

or the TBSM reporting system. 


The TBSM Agent must be configured, and you can configure the agent using one 

of the following three methods: 

v During installation, using the Agent Configuration panel. 

v After installation, using the Manage Tivoli Monitoring Services program. 

v After installation, using the itmcmd config command (Linux or UNIX only). 

The use of any one of these methods requires you to provide the following 

information: 

v Communication configuration information for the agent to contact the Tivoli 

Enterprise Monitoring Server. 

v The TBSM Server installation directory value. 

For Windows systems, the default value is C:\Program Files\IBM\tivoli\tipv2\ 

profiles\TBSMProfile\logs\tbsm. 

For non-Windows systems, the default value is /opt/IBM/tivoli/tipv2/ 

profiles/TBSMProfile/logs/tbsm. 

In addition, the itmcmd config command requires you to provide a product code 

for the agent. The product code for the TBSM agent is r9. 

The following configuration fields are specific to the TBSM agent: 


Custom Provider Client (CPC) port 

The CPC port is used to communicate between the base agent and any 

custom-data provider code that the agent uses. You can configure the 

TBSM Agent CPC port number as part of the agent configuration. When 

the TBSM agent is installed and started for the first time, it creates a file 

that specifies the CPC port named kr9_cps.properties. 

On UNIX systems, the file is created in /tmp. 

On Windows systems, this file is located in the 

CANDLE_HOME\TMAITM6 dir. 

As an example on Windows the file is located in C:\IBM\ITM\TMAITM6 and 

the file sets the value of the CPC port. The default value is: CP_PORT=2092 

TBSM_tbsmomnibuseventreader.log file monitoring and failover 

In previous versions of TBSM, only the path to the 

TBSM_tbsmomnibuseventreader.log file was requested during agent 

configuration. To allow the agent to be installed and configured correctly 

on a TBSM backup server, the name of the log file that also needs to be 

configured as its name is typically TBSM_tbsmomnibus_B_eventreader.log. 

Having just the path value will not work on a TBSM backup data server. 

The default values for the TBSM agent are now: 

$TBSM_HOME/logs/TBSM_tbsmomnibuseventreader.log 

%TBSM_HOME%\logs\tbsm\TBSM_tbsmomnibuseventreader.log 

Discovery Library Toolkit installation directory 

To monitor the msgGTM_XT.log file of the Discovery Library Toolkit, the 

path to where the msgGTM_XT.log is located must be configured properly. 

The default value is: 

/opt/IBM/tivoli/XMLtoolkit/log 

C:\Program Files\IBM\tivoli\XMLtoolkit\log 

TBSM Process Control Agent process name 

Indicates whether the TBSM Process Control Agent is installed. The default 

value of java_not_installed indicates that the Process Control Agent is 

not installed. In previous versions, the agent reported the Process Control 

Agent was down when it was not installed. 

TBSM Discovery Library Toolkit process name 

Indicates whether the TBSM Discovery Library Toolkit is installed. The 

default value of java_not_installed indicates that the Discovery Library 

Toolkit is not installed. 

CPC Port 

The Custom Provider Client port. The default is 2092. 

TBSM Data Server Service Name 

The name of the TBSM data server service. 

TBSM Dashboard Server Service Name 

The name of the TBSM Dashboard server service. 

Installing and configuring the TBSM Agent 121


On Windows 2008, after installing the agent, if the Windows service “Monitoring 

Agent for Business Service Manager Agent - Primary” fails to start, the service 

might need to be configured to run as “Administrator” and not the “Local System 

Account”. 

Enabling historical reporting 

If you intend to use the TBSM Historical Reporting feature, you must enable 

recording of data from the TBSM agent into the Tivoli Monitoring for the Tivoli 

Data Warehouse database. 


Configure Tivoli Monitoring to record the data by using the Tivoli Enterprise 

Portal user interface. 

Note: For data warehousing to collect historical data for TBSM, the Tivoli 

Monitoring for the Tivoli Data Warehouse database components must be installed, 

correctly configured, and working according to the Tivoli Monitoring 6.0 (or later) 

Installation Guide. 

Procedure 

1. Select Edit -> History Configuration from the main menu. 

2. Choose Business System Manager Common Agent from the Monitored 

Application list. 

3. Select any of the attribute groups listed and configure the attribute group for 

historical data collection (the tree shows the short name for the attribute 

group). 

4. In the Configuration panel set the Collection Interval, Collection Location 

and Warehouse Interval. 

5. On the Distribution tab add the Available Systems and/or Available 

Managed Systems groups to the Start Collection on list. 

6. Optionally on the Filter tab create a filter to be applied to the historical data 

collection. 

Filtering event broker log data 

This topic describes how filter out excess data from the event broker log. 


You need to install the TBSM agent. 


The TBSM Agent default Event Broker log view shows more data than you may 

want to see. The log view should filter out certain log lines where the value of 

Events Read = 0. For TBSM, the agent does not filter out enough data. To resolve 

this issue, complete this procedure to filter the data in the Tivoli Enterprise Portal 

the workspace for the agent. 

Procedure 

1. Open the Tivoli Enterprise Portal. 


2. From the Navigator, click on the TBSM agent host > Business Service 

Manager Agent > TBSM Event Broker log. 

3. On the TBSM Event Broker Log view, right click and select Properties from 

the menu that opens. 

4. On the Properties page, Query tab, click on Click here to assign a query. 

5. On the Query Editor navigator panel click the Create Another Query... tool 

bar button. 

6. In the window that opens, enter a new query Name value such as TBSM Event 

Broker Log Filtered. 

7. In the Specification grid click on the first blank cell under the Events Read 

column. 

8. In the Events Read column, click the operator button (such as ==) and select 

the != Not equal option from the operator list. 

9. In the empty input cell enter 0 (zero). 

10. Click OK. 

11. Verify that the query formula now says: 

( Node == $NODE$ AND Events Read != 0) 

12. Click Apply. 

13. Click OK. 

Results 

The log view now filters out log lines where the value of Events Read = 0. 

Enabling Agent Management Services for TBSM 

This topic describes how to enable Agent Management Services for TBSM on your 

systems. 


The TBSM agents can be managed by the IBM Tivoli Monitoring 6.2.1 Agent 

Management Services. These services are available in the Tivoli Monitoring OS 

Monitoring Agent for Windows and the Tivoli Monitoring 6.2.1 OS Monitoring 

Agent for Linux. 

To enable Agent Management Services for TBSM on your systems with the Tivoli 

Monitoring 6.2.1 OS Monitoring Agent for Windows or Linux, copy the kr9.xml 

file from the TBSM install media to the CAP file subdirectory created in the OS 

Monitoring Agent's file tree. These services are designed to keep the TBSM agents 

available and to provide information about their status to the Tivoli Enterprise 

Portal. 

For more information about Agent Management Services, see: 

v Chapter 11 of the IBM Tivoli Monitoring Administration Guide at: 

http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/ 

com.ibm.itm.doc_6.2.1/itm_admin.pdf 

v The 6.2.1 Windows OS User's Guide at: 


com.ibm.itm.doc_6.2.1/main_win.pdf 

v The 6.2.1 UNIX OS User's Guide at: 



com.ibm.itm.doc_6.2.1/main_unix.pdf 

TBSM Agent installation reference 

This topic describes information that is specific to the TBSM agent. 

Purpose 

The TBSM agent installation program helps you install the agent in your 

environment. See the IBM Tivoli Monitoring Installation and Setup Guide for 

additional installation requirements. 

Prerequisites 

The installation program automatically detects if you need any prerequisite 

software and makes the appropriate selections on the Install Prerequisites panel. 

Accept the defaults. 

Select Features prompt 

Select Tivoli Enterprise Monitoring Agents. Also select both the Tivoli Enterprise 

Monitoring Agent Framework and Business Service Manager Agent. 

Tivoli Monitoring links 

For information about installing, configuring, and administering monitoring agents, 

see the Tivoli Monitoring information center and these topics: 

v Deploying monitoring agents across your environment in the Tivoli 

MonitoringInstallation and Setup Guide 

v Working with monitoring agents in the IBM Tivoli MonitoringAdministrator's 

Guide. 

For more information about Agent Management Services, see: 

v In the IBM Tivoli Monitoring Administration Guide see: 


com.ibm.itm.doc_6.2.1/itm_admin.pdf 

v The 6.2.1 Windows OS User's Guide at: 


com.ibm.itm.doc_6.2.1/main_win.pdf 

v The 6.2.1 UNIX OS User's Guide at: 


com.ibm.itm.doc_6.2.1/main_unix.pdf 

Workspaces reference 

This topic describes the navigator items and workspaces for the Business Service 

Management Agent. 

Business Service Management Agent Navigator item 

This navigator item opens the Business Service Management Agent workspace. 

This workspace contains the following view: 


TBSMMAIN 

The TBSM Agent Main Workspace, shows a tabular view of the historical 

daily status values for the services monitored by TBSM. 

Availability Navigator item 

This navigator item opens the Availability workspace. The Availability workspace 

displays the overall health of the application and include logical view for both the 

TBSM Database Server and TBSM Dashboard server. 

This workspace contains the following views: 

Availability 

Displays the state of each component in the application. Each process is 

displayed using a descriptive name, the name of the running process, and 

the state of the process (UP, DOWN, or 

PROCESS_DATA_NOT_AVAILABLE). Each service is displayed using a 

descriptive name, the short name of the service, and the state of the service 

(UP, DOWN, or UNKNOWN). The state is UP if the service is running, 

DOWN if the service exists but is not running. UNKNOWN indicates that 

the service is not installed, so these elements are filtered from the view. 

When the state of the component is DOWN (for a process, or service) it is 

highlighted with a red background. 

Processor 

Displays the amount of CPU used by each process that is a component of 

the application. This displays the 2 main components of CPU usage, 

privileged time which is time spent in the kernel on behalf of the process 

and user mode time, which is the time spent running the process code. 

Threads 

Displays the number of threads used by each process that is a component 

of the application. 

Memory 

Displays the amount of memory being consumed by each process that is a 

component of the application. This total (virtual) size of the process and 

the size of the process in memory (working set) are displayed. 

TBSM Event Broker Log navigator item 

This navigator item opens the TBSM Event Broker Log workspace. It provides log 

file monitoring of the RAD_eventbroker.log file for TBSM. 


TBSMWSL 

Displays the number of events read per second and the amount of memory 

used by the TBSM event broker based on data from the 

RAD_eventbroker.log file. 

TBSM Service Indicators navigator item 

This navigator item opens the TBSM Service Indicators workspace. This workspace 

contains the following view: 

TBSMKPI 

Shows the value(s) of key performance indicators that may be optionally 


configured for monitoring by TBSM. These KPIs are defined by writing the 

output value of a TBSM rule to an additional attribute in the service 

template. 

TBSM Service Status navigator item 

This navigator item opens the TBSM Service Status workspace. This workspace 


TBSMWS 

The main workspace shows the status of services monitored by TBSM, root 

cause events for the status change, and the status of the TBSM servers. 

TBSM Status Change Event Navigator item 

This navigator item opens the Status Change Event workspace. This workspace 


TBSMWSE 

The Status Change Event workspace shows information about events that 

affected the status of TBSM 

TBSM URL Monitor Navigator item 

This navigator item opens the TBSM URL Monitor workspace. This provides basic 

URL monitoring for TBSM This workspace contains the following view: 

TBSMWSU 

Displays response time metrics for URL monitored for the TBSM server. 

Discovery Library Toolkit Log Navigator item 

This navigator item opens the TBSM Discovery Library Toolkit Log workspace. 


TBSMXML 

Provides log file monitoring of the TBSM Discovery Library Toolkit 

msgGTM_XT.log. 

Attribute groups and attributes for Business Service 

Management Agent 

Attributes are the application properties being measured and reported by the 

Business Service Management Agent (TBSM Agent). Attribute groups are tables 

that group a specific set of attributes. 

This monitoring agent contains the following attribute groups. 

v Availability 

v Performance Object Status 

v TBSM Event Broker Log 

v TBSM Service Indicators 

v TBSM Service Status 

v TBSM Status Change Event 

v TBSM URL Monitor 

v Discovery Library Toolkit Log 


The remaining sections of this chapter contain descriptions of these attribute 

groups, which are listed alphabetically. The following information is provided for 

each attribute group: 

Attributes 

List of attributes that belong to the attribute group 

Historical group 

Whether the attribute group is a historical type that you can roll off to a 

data warehouse 

Attribute descriptions 

Description and type for each attribute in the attribute group 

Availability attribute group 

This table contains the availability data for all processes and services that make up 

this application. If the warehouse default setting is enabled, data for this attribute 

group is stored in Tivoli ® Data Warehouse. 

Attributes 

Node - key attribute 

The managed system name of the agent. 

Type: String 

Timestamp 

The local time at the agent when the data was collected. 

Type : String 

Application Component - key attribute 

The descriptive name of a part of the application. 

Type: String 

Name The name of the process, service, or functionality test. This name matches 

the executable name of the process, the service short name or the name of 

the process used to test the application. 

Type: String 

Status The status of the application component. 

v For processes 'UP', 'DOWN', 'WARNING', or 

'PROCESS_DATA_NOT_AVAILABLE': 

'PROCESS_DATA_NOT_AVAILABLE' is displayed for a process when 

the matching process is running but the resource use information cannot 

be collected for that process. 

v For services 'UP', 'DOWN', or 'UNKNOWN': 'UNKNOWN' is displayed 

when the service is not installed. 

v For functionality tests: 'PASSED' or 'FAILED' is displayed. 

Type: Integer with enumerated values. The strings are displayed in the 

Tivoli Enterprise Portal. The warehouse and queries return the values 

shown in parentheses. The following values are defined: 

v DOWN (0) 

v UP (1) 

v WARNING (2) 

v UNKNOWN (3) 

v PASSED (4) 


v FAILED (5) 

v PROCESS_DATA_NOT_AVAILABLE (6) 

Any other values will display the actual value returned by the agent in the 

Tivoli Enterprise Portal. 

Full Name 

The full name of the process including the path. 

Type: String 

Type attribute 

The type of the application component. Components are processes, 

services, or functionality tests. 




v PROCESS (0) 

v SERVICE (1) 

v FUNCTIONALITY_TEST (2) 



Virtual Size 

The virtual size (in MB) of the process. 

Type: Integer (Gauge) 

Page Faults per Sec 

The rate of page faults for the process measured in faults per second. This 

attribute only contains valid data for processes. 

Type : Integer (Gauge) 

Working Set Size 

The working set size of the process in MB. This attribute only contains 

valid data for processes. 


Thread Count 

The number of threads currently allocated by this process. This attribute 

only contains valid data for processes. 


PID The process ID associated with the process. This attribute only contains 

valid data for processes. 


Percent Privileged Time 

The percentage of the available CPU time that is being used by this process 

for privileged operation. 


Percent User Mode Time 

The percentage of the available CPU time that is being used by this process 

for user mode operation. 

Type:Integer (Gauge) 


Percent Processor Time 

The percentage of the elapsed time that this process used the processor to 

execute instructions. 


Command Line 

The program name and any arguments specified on the command line 

when the process was started. This has the value N/A if this is a Service, 

or Functionality test. 

Type: String 

Functionality Test Status 

The return code of the functionality test. When the monitored application 

is running correctly, 'SUCCESS' is displayed. 'NOT_RUNNING' is 

displayed when it is not running correctly. 'N/A' is displayed when the 

row does not represent a functionality test. 

Type : Integer with enumerated values. The strings are displayed in the 



v SUCCESS (0) 

v N/A (1) 

v GENERAL_ERROR (2) 

v WARNING (3) 

v NOT_RUNNING (4) 

v DEPENDENT_NOT_RUNNING (5) 

v ALREADY_RUNNING (6) 

v PREREQ_NOT_RUNNING (7) 

v TIMED_OUT (8) 

v DOESNT_EXIST (9) 

v UNKNOWN (10) 

v DEPENDENT_STILL_RUNNING (11) 

v INSUFFICIENT_USER_AUTHORITY (12) 



Functionality Test Message 

The text message that corresponds to the Functionality Test Status. This is 

only valid for functionality tests. 

Type: String 

Performance Object Status attribute group 

This table reflects the status of other attribute groups so you can see the status of 

all of the performance objects that make up this application all at once. 

Attributes 

Each of these other performance attribute groups is represented by a row in this 

table (or other type of view). The status for an attribute group reflects the result of 

the last attempt to collect data for that attribute group, which allows you to see 

whether the agent is performing correctly. Unlike other attribute groups, the 

Performance Object Status attribute group does not reflect the state of the 

monitored application. This attribute group is most often used to determine why 


data is not available for one of the performance attribute groups. If the warehouse 

default setting is enabled, data for this attribute group is stored in Tivoli ® Data 

Warehouse. 



Type: String 

Timestamp 


Type : String 

Query Name - This attribute is a key attribute. 

The name of the attribute group. 

Type :String 

Object Name 

The name of the performance object. 

Type :String 

Object Type 

The type of the performance object. 




v WMI (0) 

v PERFMON (1) 

v WMI_ASSOCIATION_GROUP (2) 

v JMX (3) 

v SNMP (4) 

v SHELL_COMMAND (5) 

v JOINED_GROUPS (6) 

v CIMOM (7) 

v CUSTOM (8) 

v ROLLUP_DATA (9) 

v WMI_REMOTE_DATA (10) 

v LOG_FILE (11) 



Object Status 

The status of the performance object. 




v ACTIVE (0) 

v INACTIVE (1) 



Error Code 

The error code associated with the query 


Integer with enumerated values. The strings are displayed in the Tivoli 

Enterprise Portal. The warehouse and queries return the values shown in 

parentheses. The following values are defined: 

v NO_ERROR (0) 

v GENERAL_ERROR (1) 

v OBJECT_NOT_FOUND (2) 

v COUNTER_NOT_FOUND (3) 

v NAMESPACE_ERROR (4) 

v OBJECT_CURRENTLY_UNAVAILABLE (5) 

v COM_LIBRARY_INIT_FAILURE (6) 

v SECURITY_INIT_FAILURE (7) 

v PROXY_SECURITY_FAILURE (9) 

v NO_INSTANCES_RETURNED (10) 

v ASSOCIATOR_QUERY_FAILED (11) 

v REFERENCE_QUERY_FAILED (12) 

v NO_RESPONSE_RECEIVED (13) 

v CANNOT_FIND_JOINED_QUERY (14) 

v CANNOT_FIND_JOIN_ATTRIBUTE_IN_QUERY_1_RESULTS (15) 

v CANNOT_FIND_JOIN_ATTRIBUTE_IN_QUERY_2_RESULTS (16) 

v QUERY_1_NOT_A_SINGLETON (17) 

v QUERY_2_NOT_A_SINGLETON (18) 

v NO_INSTANCES_RETURNED_IN_QUERY_1 (19) 

v NO_INSTANCES_RETURNED_IN_QUERY_2 (20) 

v CANNOT_FIND_ROLLUP_QUERY (21) 

v CANNOT_FIND_ROLLUP_ATTRIBUTE (22) 

v FILE_OFFLINE (23) 

v NO_HOSTNAME (24) 

v MISSING_LIBRARY (25) 

v ATTRIBUTE_COUNT_MISMATCH (26) 

v ATTRIBUTE_NAME_MISMATCH (27) 

v COMMON_DATA_PROVIDER_NOT_STARTED (28) 

v CALLBACK_REGISTRATION_ERROR (29) 

v MDL_LOAD_ERROR (30) 

v AUTHENTICATION_FAILED (31) 



TBSM Event Broker Log attribute group 

This attribute group monitors the RAD_eventbroker.log for information related to 

the reading of events from the TBSM ObjectServer. If the warehouse default setting 

is enabled, data for this attribute group is stored in Tivoli ® Data Warehouse. 

Attributes 



Type: String 


Timestamp 


Type : String 

eb read 

Reserved for internal use. 

Type: String 

Events Read 

The number of events read during a read cycle. 

Type: Integer (Counter) 

eb newread 


Type : String 

New Events Read 

The number of new events read during a read cycle. 


eb update 


Type : String 

Updates 

The number of updates processed during a poll interval. 


Queue Name 

The name of the event queue. 

Type: String 

Queued Events 

Number of events on the event queue. 


eb readbuf 


Type : String 

Read Buffer 

The size of the event broker read buffer. 


eb polltime 


Type : String 

Poll Time 

The event broker poll time. 


eb epersec 


Type : String 


Events Read Per Second 

The number of events read per second. 


New Events Read Per Second 


Type: String 

eb nepersecval 

Number of new events read per second. 


eb memory 


Type: String 

Memory Usage 

The current amount of memory used by the event broker in bytes. 


TBSM Service Indicators attribute group 

The TBSM service indicators attribute group contains information about key 

perfomance indicators (KPIs) on the services managed by TBSM. The KPIs are 

user-defined rules and additional attributes in TBSM. If the warehouse default 

setting is enabled, data for this attribute group is stored in Tivoli ® Data Warehouse. 

Attributes 



Type: String 

Timestamp 


Type : String 

ServiceName - This is a key attribute. 

The service name in TBSM. This name is unique for each service. 

Type: String 

Primary Template Name 

The name of the primary service template assigned to the service instance. 

The template includes the rules that determine the status thresholds for the 

service. 

Type: String 

StatusTime 

The time when the status was recorded in TBSM in the MM/DD/YY 

HH:MM:SS format. 

Type: Timestamp 

Indicator Name - This is a key attribute. 

The name of key performance indicator attribute as defined in a TBSM 

rule. To pass a KPI attribute from TBSM, select the Store Data for this rule 

for TDW option in the Metric Collection section of the editor window for 

the rule. 


Alternately, you can name the rule with a suffix of _KPI. 

Type: String 

Indicator Value 

The value of key performance indicator attribute defined in TBSM. This 

attribute contains the output value from a TBSM service template rule. 


Previous Indicator Value 

The previous value of key performance indicator attribute defined in 

TBSM. 


TBSM Service Status attribute group 

The Service Status attribute group reports the current values of selected attributes 

of TBSM service instances. These values are used in the main workspace under 

TBSM Service Status History. If the warehouse default setting is enabled, data for 

this attribute group is stored in Tivoli ® Data Warehouse. 

Attributes 



Type: String 

Timestamp 


Type : String 



Type: String 

DisplayName 

The label of the service in the TBSM console. This can be different than the 

service name. 

Type: String 

ParentServiceName 

Name of parent service. The child service defined by the Service Name 

attribute affects the status of this parent service. 

Type: String 

LongParentServiceName 

Long name of parent service, used for extra long Parent Names. The child 

service defined by the Service Name attribute affects the status of this 

parent service. 

Type: String 

OverallAttribute 

The overall status of the service. The values can be Clear (0), Marginal (3), 

Unknown (1), Maintenance (2), or Bad (5). 





v Clear (0) 

v Unknown (1) 

v Maintenance (2) 

v Marginal (3) 

v Major (4) 

v Bad (5) 



BSM Identity 

Reserved. BSM Identity value correlates external events with TBSM 

services. For example, if an event is from IBM ® Tivoli Monitoring, the 

BSM_Identity attribute matches the value of the $situation_origin attribute 

for the situation event. This field is always blank. 

Type : String 

BSM ClassName 

Class identity reserved for future use. 

Type : String 

Primary Template Name 

The name of the primary service template assigned to the service instance. 

The template includes the rules that determine the status thresholds for the 

service. 

Type: String 

StatusTime 




CurrentDownTimeDuration 

Duration of current downtime in seconds. 


DownTimeInCurrentHour 

Reserved. downtime within the current hour in seconds. 


DownTimeInCurrentDay 

Reserved. downtime within current day in seconds. 

Type Integer (Counter) 

DownTimeInCurrentMonth 

Reserved. downtime within current month in seconds. 

Type : Integer (Counter) 

TBSM Service Status Change Event attribute group 

The BSM service status change event attribute group contains information on the 

IBM ® Netcool/Omnibus events that affect the status of TBSM services. If the 

warehouse default setting is enabled, data for this attribute group is stored in 

Tivoli ® Data Warehouse. 


Attributes 



Type: String 

Timestamp 


Type : String 



Type: String 

DisplayName 

The label of the service in the TBSM console. This can be different than the 

service name. 

Type: String 

BSM Identity 

Reserved. BSM Identity value correlates external events with TBSM 

services. For example, if an event is from IBM ® Tivoli Monitoring, the 

BSM_Identity attribute matches the value of the $situation_origin attribute 

for the situation event. This field is always blank. 

Type : String 

BSM ClassName 

Class identity reserved for future use. 

Type : String 

ServerName 

The ServerName field from the event. 

Type: String 

ServerSerial 

The ServerSerial field from the event. 

Type : Integer (Counter) 

StatusTime 




StatusChange 

The time when the status-change event occurred. 

Type : Timestamp 

Identifier - This is a key attribute. 

Identifier field in the event. Each event must have a unique value in the 

Identifier field. 

Type: String 

FirstOccurrence 

First Occurrence field in the event. This value shows when the event first 

occurred. 



LastOccurrence 

LastOccurrence field in the event. This value shows when the event last 

occurred. 


Severity 

The Severity level of the event. The values can be Clear (0), Indeterminate 

(1), Warning (2), Minor (3), Major (4), or Critical (5). 




v Clear (0) 

v Indeterminate (1) 

v Warning (2) 

v Minor (3) 

v Major (4) 

v Critical (5) 



Summary 

The Summary field from the event. 

Type: String 

AlertGroup 

The Alert Group field from the event. 

Type: String 

AlertKey 

The Alert Key field from the event. 

Type: String 

TBSM URL Monitor attribute group 

Response time metrics for the TBSM WEB application are maintained in the TBSM 

URL Monitor attribute group. If the warehouse default setting is enabled, data for 

this attribute group is stored in Tivoli ® Data Warehouse. 

Attributes 



Type: String 

Timestamp 


Type : String 

URL Reports the TCP/IP hostname of the TBSM server. The default is 

http://localhost:8080. 

Type: String 

HTTPResponseCode 

The HTTP response code returned from the URL availability test. 



HTTPResponseMessage - This is a key attribute. 

The HTTP response message from the URL availability test. 

Type: String 

ResponseTime 

Response time in milliseconds. Reports the number of seconds that was 

required for the transaction to complete. 


AvgResponseTime 

Average response time in milliseconds. Reports the average elapsed time 

between connecting with the Web server and downloading the Web page. 

Type : Integer (Average over time) 

MinResponseTime 

Minimum response time. Reports the minimum response time (by the 

number of seconds) for a single transaction instance during the data 

interval. 


MaxResponseTime attribute 

Maximum response time. Reports the maximum response time (by the 

number of seconds) for a single transaction instance during the data 

interval. 


Discovery Library Toolkit Log attribute group 

This attribute group monitors the TBSM Discovery Library Toolkit msgGTM_XT.log 

for information related to the processing of DLA books. 

Attributes 

xml_message_id - this is a key attribute 

The TBSM Discovery Library Toolkit message id. 

Type: String 

xml_message_txt 

The TBSM Discovery Library Toolkit message text. 

Type: String 

Disk capacity planning for historical data 

Disk capacity planning for a monitoring agent is a prediction of the amount of disk 

space to be consumed for each attribute group whose historical data is being 

collected. 

Disk capacity factors 

Required disk storage is an important factor to consider when you are defining 

data collection rules and your strategy for historical data collection. 

The table in this chapter provides the following information required to calculate 

disk space for this agent: 

v Table is the table name as it is displayed in the warehouse database, if the 

attribute group is configured to be written to the warehouse. 


v Attribute group is the name of the attribute group as it is displayed in the 

warehouse configuration panel. 

v Bytes per instance (agent) is an estimate of the record length for each row or 

instance written to the agent disk for historical data collection. This estimate can 

be used for agent disk space planning purposes. 

v Database bytes per instance (warehouse) is an estimate of the record length for 

detailed records written to the warehouse database, if the attribute group is 

configured to be written to the warehouse. Detailed records are those that have 

been uploaded from the agent for long-term historical data collection. This 

estimate can be used for warehouse disk space planning purposes. 

v Aggregate bytes per instance (warehouse) is an estimate of the record length for 

aggregate records written to the warehouse database, if the attribute group is 

configured to be written to the warehouse. Aggregate records are created by the 

Summarization agent for attribute groups that have been configured for 

summarization. This estimate can be used for warehouse disk space planning 

purposes. 

In addition to the information in the tables, you must know the number of 

instances of data that you plan to collect. An attribute group can have single or 

multiple instances of data depending on the application environment that is being 

monitored. For example, if your attribute group is monitoring each processor in 

your computer and you have a dual processor computer, the number of instances 

is 2. 

The following table contains capacity planning information for the data logged by 

the Business Service Management Agent. 

Table 11. Capacity planning for historical data logged by the Business Service Management Agent 

Database Aggregate 

Bytes per bytes per bytes per 

instance instance instance 

Table Attribute group 

(agent) (warehouse) (warehouse) 

KR9AVAIL KR9_AVAILABILITY 3272 3296 3606 

KR9POBJST KR9_PERFORMANCE_OBJECT_STATUS 288 289 326 

KR9RADLOG KR9_TBSM_EVENT_BROKER_LOG 337 351 523 

KR9KR9KPI KR9_TBSM_SERVICE_INDICATORS 481 483 550 

KR9KR9STAT KR9_TBSM_SERVICE_STATUS 1264 1277 1374 

KR9KR9SCHG KR9_TBSM_STATUS_CHANGE_EVENT 2063 2078 2130 

KR9KR9URLC KR9_TBSM_URL_MONITOR 451 454 590 

KR9TBSMXML KR9_TBSM_DISCOVERY_LIBRARY_ 

TOOLKIT_LOG 

300 310 400 

For more information about historical data collection, see the IBM Tivoli 

Monitoring Administrator's Guide. 

Predefined situations 

This monitoring agent contains predefined situations, which are organized by 

Navigator item. 


Navigator item situations 

TThis monitoring agent contains the following predefined situations, which are 

organized by Navigator item: 


o Not applicable 

Availability 

v KR9_Process_Data_Unavailable 

v KR9_TBSM_Critical 

TBSM Event Broker Log 

Not applicable 

TBSM Service Indicators 


TBSM Service Status 


TBSM Status Change Event 


TBSM URL Monitor 

KR9_TBSM_Web_App_Critical 

Discovery Library Toolkit Log 


The remaining sections of this chapter contain descriptions of each of these 

situations. The situations are organized by Navigator item. The following 

information is provided about each situation: 

Description 

Information about the conditions that the situation tests 

Formula 

Syntax that contains one or more logical expressions describing the 

conditions for the situation to monitor Run at startup Whether the 

situation is automatically distributed to instances of the agent or is 

available for manual distribution. 

Sampling interval 

Number of seconds that elapses between one sample of data that the 

monitoring agent collects for the server and the next sample 

Situation persistence 

Whether the conditions specified in the situation evaluate to "true" for the 

defined number of occurrences in a row before the situation is raised. The 

default of 1 means no persistence checking takes place. 

Severity 

Severity of the event: Warning, Informational, or Critical Clearing 

conditions Controls when a true situation closes: after a period of time, 

when another situation is true, or whichever occurs first if both are 

selected. 

Availability navigator item situations 

The Availability Navigator item contains these predefined situations: 


KR9_Process_Data_Unavailable situation 

Description 

Unable to gather process data for this process. 

Formula 

*IF *VALUE KR9_AVAILABILITY.Type *EQ PROCESS *AND 

*VALUE KR9_AVAILABILITY.Status 

*EQ PROCESS_DATA_NOT_AVAILABLE 

Distribution type 

This situation is automatically distributed to instances of this agent. 


1 minute 


The number of times the conditions of the situation must occur for the 

situation to be true is 3. 

Severity 

Informational 

Clearing conditions 

The situation clears when the condition becomes false. 

KR9_TBSM_Critical situation 

Description 

Indicates TBSM may not be available. 

Formula 

**IF *VALUE KR9_AVAILABILITY.Status *EQ DOWN 




1 minute 




Severity 

Critical 



URL Monitor navigator item situations 

The URL Monitor navigator item contains these predefined situations: 

KR9_TBSM_Web_App_Critical situation 

Description 

Indicates that the TBSM Web application may not be responding. 

Formula 

***IF *VALUE KR9_TBSM_URL_MONITOR.HTTPResponseCode *NE 200 




1 minute 





Severity 

Critical 



Predefined take action commands 

The Business Service Management Agent does not provide predefined Take Action 

commands. 

Predefined policies 

The Business Service Manager Common Agent does not provide predefined 

policies. 


Installing the Discovery Library Toolkit on different system 

The Discovery Library toolkit is installed as part of the TBSM Data Server. Use 

these procedures when you install the toolkit in an environment that does not have 

TBSM 6.1x, such as on a separate Impact server. 




v IBM common data model IDML books 


v the Discovery Library toolkit API 


During the installation you can choose whether TADDM and/or books will be 

accepted. The API is enabled by default, but can be disabled after installation 

through a property. 

Information about using the Discovery Library Toolkit is available in the TBSM 

Administrator's Guide and Customization Guide. 

Notes: 

v In a TBSM environment, the Discovery Library toolkit is installed on the TBSM 

Data Server. The toolkit can also be installed on an Impact server to help with 

root cause analysis. 

v The default installation directory for the Discovery Library Toolkit is the 

$TBSM_HOME/XMLtoolkit/ directory. Do not change the default installation 

directory. 

v Before installing the Discovery Library Toolkit: 

– It is recommended that you source $TBSM_HOME/bin/ 

setupTBSMData.sh. 

– Use a command window that has the environment variables 

defined during the base TBSM installation. 

Installing the Discovery Library Toolkit on UNIX and Windows 

This section describes how to install the Discovery Library Toolkit. 


The Discovery Library Toolkit is installed as part of the TBSM Data Server, 

however if you want to install the toolkit onto a non-TBSM Data Server 

environment, such as an Netcool/Impact server, you need to follow the 

instructions in this section. 

Important: Do not change the default installation directory or the Discovery 

Library Toolkit will not function properly. 


Before you begin, the following conditions must be met: 

v If you want to use Tivoli Application Dependency Discovery Manager as the 

source of your data, it must be installed before you install the Discovery Library 

Toolkit. You need to enter the user ID and password and a database user ID and 

password for the Tivoli Application Dependency Discovery Manager as part of 

the toolkit's installation. 

v Ensure that the BSM_Templates.radsh file was installed when the Data server 

was installed. The toolkit requires the templates that are contained in this file. 

For additional information about creating service templates, see the TBSM 

Administration Guide. 

Procedure 

1. Start the installation process from the product DVD or installation package. 

Change to the appropriate directory based on the operating system: 

introp/DiscoveryLibrary 

2. Enter the command for your operating system: 

Windows For Windows systems, you need to run the command 

as an Administrator: 

Right-click on the Command Prompt icon and click, Run as Administrator. 

setup-dltoolkit-windows_.exe 

UNIX/Linux 

setup-dltoolkit-introp.sh 

3. Select the language for the installation program to use and click OK. 

4. Read the information on the Welcome window, and click Next. 

5. After reading the license agreement, click I accept both IBM and non-IBM 

terms, and then click Next. 

6. Select the directory where you want to install the toolkit, and then click Next. 

$TBSM_HOME/XMLtoolkit 

%TBSM_HOME%\XMLtoolkit 

7. Specify information about the toolkit when prompted and click Next to proceed 

with the installation. 

8. When you have entered all the required information, click Install to complete 

the installation. 

Toolkit configuration settings 

Specify the failover information for the Discovery Library Toolkit. 

Purpose 

When you install, you need supply the information about the Discovery Library 

Toolkit configuration. 

Choices 


Is the other toolkit the primary server with this failover pair (yes/no) 

Specify whether the other toolkit server is the primary. If you select yes, 

you are prompted for additional failover information. 


Enter the Discovery Library Toolkit Host name or IP address 

Enter the fully qualified host name for the other toolkit server. 

Is the alternate toolkit the primary within the failover pair? 

If you selected yes for failover, specify if alternate server is the primary. 

Enter the alternate toolkit host name or IP address 

If you selected yes for failover, enter the fully qualified host name for the 

other toolkit server. 










Select the database that will be used by the toolkit 

This is set to IBM DB2. 




TBSM Database Connectivity 

Specify the information needed to connect to the TBSM database. 

Enter the Database User ID 


database. 

Enter the database password 




Enter the database hostname or IP address 


Enter the port used by the Database 


Enter the database name 












Installing the Discovery Library Toolkit on different system 145



running. If the server is running on a private network and the 


TADDM server. 



















copy the file before you start the toolkit. 

















installation. 
































































Commands used for silent installation of Discovery Library 

Toolkit 

An installation program response file, dltoolkit-installer.properties, is 

provided in the install image's DiscoveryLibrary directory. Copy the file and make 

the appropriate changes for your environment. 

To start an installation using a modified dltoolkit-installer.properties, issue 

the following command: 

setup-dltoolkit-platform.exe/bin -i silent –f dltoolkit-installer.properties 

In the previous example, replace platform.exe/bin with the name for your operating 

system,, such as setup-dltoolkit-aix.bin for AIX. 

The commands for each operating system are: 

Window 64-bit 

setup-dltoolkit-windows_64.exe 

AIX 64-bit 

setup-dltoolkit-aix_64.bin 

Linux 64-bit 

setup-dltoolkit-linux_64.bin 

Solaris 64-bit 

setup-dltoolkit-solaris_64.bin 

Command-line (console) installation 

Command-line installation can be useful when installing from the graphical user 

interface is not feasible. Command-line installation provides prompts for your 

input data. 

To initiate command-line mode, pass -i console to the name of the installer. 

The command is: setup-dltoolkit-platform -i console 

For example, issuing the command setup-dltoolkit-windows -i console starts 

command-line mode for the installation for Windows. 

The command is in the directory: /platform/DiscoveryLibrary 


“Installing TBSM using the console” on page 101 

Use the console installation when the graphical user interface is not available. 

Console installation provides command-line prompts to input data. 

Completing the installation of the Discovery Library Toolkit 

After you have installed the Discovery Library Toolkit, several post-installation 

steps must be completed before running the toolkit. 



If you are using Tivoli Application Dependency Discovery Manager as a data 

source then the following steps are required: 

Procedure 

1. The Tivoli Application Dependency Discovery Manager API jar files must be 

copied from the Tivoli Application Dependency Discovery Manager server to 

the TBSM server. Which jar files you copy and where you copy them to differs 

depending on the version of the Tivoli Application Dependency Discovery 

Manager server. 

v Tivoli Application Dependency Discovery Manager 7.1.1 and earlier: 

Copy all the jar files on the Tivoli Application Dependency Discovery 

Manager server from /opt/IBM/cmdb/dist/sdk/lib and put them in 

$TBSM_HOME/XMLtoolkit/sdk/lib. 

v Tivoli Application Dependency Discovery Manager 7.1.2 and later: 

Copy the jar file /opt/IBM/cmdb/dist/sdk/clientlib/taddm-api-client.jar 

to the TBSM Data server in the $TBSM_HOME/XMLtoolkit/sdk/clientlib 

directory. 

v Tivoli Application Dependency Discovery Manager 7.2 and later 

Copy the following jar files to $TBSM_HOME/XMLtoolkit/sdk/clientlib: 

a. taddm-api-client.jar 

b. platform-model.jar 

c. oal-topomgr.jar 

Note: If TADDM is 7.2.1 or later, the toolkit will automatically copy the 

required jar files from the TADDM server. The first time that the toolkit is 

started, it will copy the required jars into a temporary directory and then 

stop. Restart the toolkit and the installation of the jar files will be completed. 

2. Create the change_history_table on the TADDM database 

This table must be within the schema used by TADDM. The SQL for creating 

this table can be found in: 

DB2 .../XMLtoolkit/sql/taddm_schema_setup_db2.sql 

Oracle .../XMLtoolkit/sql/taddm_schema_setup_oracle.sql 

This SQL includes the table and index definitions. 

TBSM will copy data into this table, thus the user that TBSM uses to connect to 

the TADDM database must have write authority for this table. 

This table is required for delta imports. If this table is not created, the delta 

imports will revert back to using the TADDM API's for data retrieval but the 

bulk imports will continue to use direct access. 

3. Read and update the sync/tables_extra TADDM configuration file. Read the 

section: TADDM Configuration Update to tables_extra, for additional 

detail. 

If you cannot create the tbsm_change_history_table or update the 

tables_extra configuration, then add this property to .../XMLtoolkit/bin/ 

xmltoolkitsvc.properties file: 

DL_TADDM_JDBC_DeltaImport=false 

This property forces the toolkit to use the TADDM API's for delta imports. Bulk 

imports will continue to use direct access. 


4. When TBSM loads data into tbsm_change_history_table, it updates the 

statistics on the table. It is recommended that the user that TBSM uses to 

connect to the TADDM database have the authority to run this update. 

For DB2 

CALL ADMIN_CMD (’runstats on table tbsm_change_history_table 

and indexes all’) 

For Oracle 

ANALYZE TABLE tbsm_change_history_table COMPUTE STATISTICS 

Note: If the user does not have this authority, it will result in an exception in 

the message log, but the delta import will continue to completion. Not having 

this authority could result in degraded performance when accessing this table. 

5. If the installation was an upgrade to an existing toolkit, additional work is 

required for the XML configuration files. The toolkit has four XML files that are 

customizable: 

a. 

b. 

v EventIdentifierRules.xml, 

v LabelingRules.xml, 

v CDM_TO_TBSM4x_MAP.xml, and 

v CDM_TO_TBSM4x_MAP_Templates.xml. 

The files are kept in the $TBSM_HOME/XMLtoolkit/xml directory. If the installer 

finds existing copies of these files in this directory, it will place the latest copies 

of these files in the $TBSM_HOME/XMLtoolkit/xml/install directory. You need to 

complete the following tasks: 

a. If you have not customized any of these files, copy the files from the 

...XMLtoolkit/xml/install directory to the ...XMLtoolkit/xml directory. 

b. If you have customized these files, merge the new copies of these files with 

the customized versions and place the merged copy in the 

$TBSM_HOME/XMLtoolkit/xml directory. 

Verifying the installation of the Discovery Library Toolkit 

You can verify the installation of the Discovery Library Toolkit by running the 

sample discovery library book. The sample book creates four computer systems 

and two DB/2 databases. 


Note: In order to load the book discussed in this section, books must be defined as 

a data source for the toolkit. 

Procedure 

1. Start the toolkit service or daemon. 

2. Copy the sample discovery library book, $TBSM_HOME/XMLtoolkit/samples/ 

TMSDISC100.cvtwin05.ibm.com.2006-10-12T11 .00.00.003Z.refresh.xml, into 

the directory where the discovery library books are located. If you do not know 

the directory for the discovery library books, the location is defined in the 

xmltoolkitsvc.properties file, DL_FileSystem. 

3. Go to the TBSM console and look in the Service Component Repository 

template to view the resources that were created by the sample book (four 

computer systems and two DB/2 databases). 


4. If the resources do not appear, invalidate and refresh the Service Component 

Repository template. 

a. Select Component Registry in the Service Navigation panel. 

b. Click Invalidate in the Service Viewer panel. 

c. Refresh the Service Navigation panel. 

5. If the resources still do not appear, check the msgGTM_XT.log file for errors. The 

default log locations are as follows: 

/opt/IBM/tivoli/tbsm/XMLtoolkit/log 

C:\Program Files\IBM\tivoli\tbsm\XMLtoolkit\log 

a. Check the tbsm_42_xmltoolkit_install.log log for information and errors 

that were generated when you installed the Discovery Library Toolkit. This 

log is located in the /tmp directory. 

b. Check the setxmlaccess.out log for errors that were generated during the 

encryption of the user IDs and passwords that are collected during the 

installation process. If there are errors in this log file, you will not be able to 

connect to the database, IBM Tivoli Application Dependency Discovery 

Manager, the TBSM server, and so on. You must resolve these errors before 

you run a discovery library book or importing a book from Tivoli 

Application Dependency Discovery Manager. 

c. Check the dbUpdateldml.out log for errors that were generated when 

updating the database schema. You must resolve errors in this log before 

continuing. 

Modifying the xmltoolkitsvc.properties file 


The xmltoolkitsvc.properties file is self-documented in that it contains each 

supported property name along with its default value. All these properties are 

contained in the section that begins with these lines: 

####################################################################### 

# 

# Property Description 

# 

# Default value if applicable 

####################################################################### 

DL-####### 

It is strongly recommended that any property value that is modified from its 

default value be copied and commented out. 

Doing so ensures that the original default value and the changed value are 

available for debugging and problem support. 

Information about the properties is available in the Tivoli Business Service Manager 


Uninstalling the Discovery Library Toolkit 

This section describes how to uninstall the Discovery Library Toolkit. 

Uninstalling the Discovery Library Toolkit on Windows 

Uninstalling the Discovery Library Toolkit is a quick process. 



Procedure 

1. From a terminal window change to the %TBSM_HOME%\XMLtoolkit\_uninst 

directory. 

2. Type .\uninstall.exe 

3. When the uninstallation process completes, remove the XMLtoolkit installation 

directory from %TBSM_HOME%/. 

Uninstalling the Discovery Library Toolkit on UNIX 

This topic describes how to uninstall the Discovery Library Toolkit on UNIX 

systems. 


If /etc/init has been updated to start the toolkit, the toolkit will not uninstall 

until these definitions are removed. They can be removed in one of two ways: 

1. Before running the uninstallation program, run tbsmrdr_disable.sh as a root. 

2. Allow the uninstaller to remove the definitions. This requires that you know 

the root password, which the uninstaller will prompt for. 


To uninstall Discovery Library Toolkit, do the following steps: 

Procedure 

1. From a terminal window change to the $TBSM_HOME/XMLtoolkit/_uninst 

directory. 

2. Type ./uninstall 

3. When the uninstallation process completes, remove the XMLtoolkit/_uninst 

directory from $TBSM_HOME/. 


National Language Support 

English is the default language for Tivoli Business Service Manager (TBSM). If you 

want TBSM to display a language other than English, follow the instructions in 

this section. 

In addition to English, the following languages are supported in this release of 

TBSM: 

v Spanish 

v Brazilian Portuguese 

v German 

v French 

v Italian 

v Japanese 

v Korean 

v Simplified Chinese 

v Traditional Chinese 

v Czech 

v Hungarian 

v Polish, 

v Russian 

Turkish support: To use Turkish, install TBSM in the English language. After 

installation, change the language to Turkish. 

Note: If you encounter errors while running the database configuration utility in 

Czechoslovakian, Hungarian, or Russian, the error text may contain unreadable 

characters. If you get this error, rerun the database configuration utility in English. 

For more information on Tivoli Event Integration Facility probe language support, 

see this topic on the Netcool/OMNIbus information center under the Tivoli Event 

Integration Facility probe section: Internationalization support. 

Installing the language pack for TBSM Agent 

This topic describes how to successfully install the language pack for TBSM Agent 

using a Windows or UNIX/Linux platform. 


Before starting the National Language Support installation program , the TBSM 

agent must be installed. Also, the installation must be run under the same user ID 

as the TBSM agent installation. To install the language pack, first verify that you 

have already installed the IBM Tivoli Monitoring (English) product and a JDK/JRE, 

and then perform the following steps. You will receive an error message, and the 

installation will stop if the prerequisites are not met. 

Procedure 

1. Retrieve the installation package from installation image. The package is at 

\\NLS\Agent 

2. Launch the installation program. 

a. Execute lpinstaller.bat. 


. Execute lpinstaller.sh -c ITM Home Directory where ITM 

Home Directory is the directory where you installed the IBM Tivoli 

Monitoring product. 

3. Select the language of the installer and click OK. 

4. Click Next on the Introduction panel. 

5. Click Add/Update and click Next. 

6. Select the folder in which the National Language Support package 

(NLSPackage) files are located. 

Note: KR9_NLS.nlspkg is the default stored location. 

7. Select the language support for the agent of your choice and click Next. 

Note: Hold the Ctrl key while selecting if you want multiple language 

supports. 

8. Select the languages that you want to install and click Next. 

9. Examine the installation summary page and click Next to begin installation. 

10. Click Finish after installation completes to exit the installation program. 

11. Restart Tivoli Enterprise Portal Desktop Client, Tivoli Enterprise Portal Server, 

and/or Eclipse Help Server if they are installed. 

Note: If the agent is installed on Tivoli Enterprise Monitoring Server, you 

need to install the language pack on both Tivoli Enterprise Portal Server and 

Tivoli Enterprise Monitoring Server. 

Uninstalling the language pack for TBSM Common Agent 

Use the uninstall program to uninstall the language pack for IBM Tivoli Business 

Service Manager Common Agent. 


To uninstall the language pack, follow the steps to invoke the installation package 

for the TBSM Common Agent provided in “Installing the language pack for TBSM 

Agent” on page 153, but on step 5, select Remove rather than Add/Update. 

Procedure 

1. Retrieve the installation package from DVD #2. The package is at \NLS\Agent 

2. Launch installation package. 

a. Execute lpinstaller.bat. 

b. Execute lpinstaller.sh -c ITM Home Directory where ITM 

Home Directory is the directory where you installed the IBM Tivoli 

Monitoring product. 

3. Select the language of the installer and click OK. 

4. Click Next on the Introduction panel. 

5. Click Remove and click Next. 

6. Examine the installation summary page and click Next to begin uninstall. 

7. Click Finish after uninstall completes to exit the installation program. 


Migrating from TBSM 4.2.x 



TBSM provides utilities to help you migrate from a TBSM 4.2.x system to TBSM 

6.1. You export data from the old TBSM system and then you import the exported 

data into a newly installed TBSM system. 

Only the primary Data servers from a TBSM 4.2.x failover pair need to be 

migrated. 

The high-level tasks for migration and upgrade from TBSM 4.2.x are: 

1. Migrate a TBSM 4.2.x Data server to a TBSM 6.1 Data server 

2. Migrate a TBSM 4.2.x Dashboard server to a TBSM 6.1 Dashboard server. 

3. Follow the instructions in the Upgrading TBSM topic. 

For more information on migration, see the TBSM Version 6.1 Fix Pack 1 topic 

Installation Guide > Migrating from TBSM 4.2.x at: 

http://pic.dhe.ibm.com/infocenter/tivihelp/v3r1/topic/ 

com.ibm.tivoli.itbsm.doc_6.1.0.1/installguide/bsmi_t_migrating_to_tbsm_4.2.html 

Note: Future versions of TBSM will not support migration and cloning of the 

legacy Netcool GUI Foundation (NGF) based content. You need to ensure that all 

the elements from the original NGF migration have been replaced with equivalent 

Tivoli Integrated Portal based content and then remove the NGF migration war 

file. For more information about NGF content, see the TBSM Support site for this 

Technote at: 

http://www.ibm.com/support/docview.wss?uid=swg21628118 

Important: TBSM migration supports migrating from a single TBSM Data or 

Dashboard server to a target Data or Dashboard server. The export and import 

from multiple servers is not supported. Do not export data from more than one 

source server and then try to merge the data by importing multiple times into the 

same target server. 





an upgrade. 

“Tivoli monitoring Charting web service changes” on page 20 

The charting Web Service was made available as of Tivoli Monitoring 6.2.2 FP2. In 

TBSM 4.2.1, the charting web service was part of the TBSM installation, in TBSM 

6.1.1, you install and configure the web service on your Tivoli Monitoring Tivoli 

Enterprise Portal Server (TEPS). 



Cloning your TBSM servers 

Cloning the Data server 








v identical TBSM version and service level 

v identical TBSM components installed on the source and target Data server 

v identical Tivoli Integrated Portal modules deployed on the source and target 

Dashboard servers 

v identical Tivoli Integrated Portal administrator user and password configured on 

the source and target Dashboard servers 

v similar operating system environments that are supported by the DB2 backup 

and restore operations between operating systems. For example, a Linux source 

server can be cloned to a Linux target or a Microsoft Windows source can be 

cloned to a Windows target 

v identical external sources and providers of data, such as servers and databases 

for other applications 

The cloning process described in this section is intended to duplicate any 

customization that you have completed on the source TBSM server environments. 





an upgrade. 


“Upgrading a 32-bit system” on page 114 


This section describes how to create a clone of the IBM Tivoli Business Service 

Manager Data server. 

Note: If the source Data server is part of a failover environment, the cloning 

process described in this section must be performed using the primary Data server. 

Note: After completing the procedures applicable to your environment, stop and 

restart the target Data server. 

Prerequisites 

In addition to the requirements specified for both Data and Dashboard servers, you 

must ensure that: 

v the target Data server does not contain custom data 


v the target DB2 server for the target Data server are configured with the same 

databases and schemas as the source DB2 server for the source Data server 

Steps to clone the Data server 

To clone the Data server: 

1. Backup and restore the TBSM database information 

2. Export and import the TBSM Impact project 

3. Export and import TBSM data sources and data fetchers 

4. On the target Data server, replicate any customization that has been completed 

on the source Data server. These additional customization changes are optional 

and depend on the configuration of your environment. The areas that might be 

included in additional customization are: 

v TBSM tree template policy 

v TBSM properties file 

v Netcool/OMNIbus 

v Discovery Library Toolkit 

v EIF Probe 

v Business Service Management Agent 

Each of these steps is described in detail in subsequent topics. 

Preparing to backup and restore the TBSM database 

information 

Using DB2 database backup and restore commands, copy the TBSM database 

information from the source DB2 server to the target DB2 server. This ensures that 

this data is available to the target Data server. 

Note: To complete this procedure, you must be logged into the DB2 host as a user 

with permission to backup and restore databases. 

When you install TBSM, you must create databases to meet your requirements. A 

typical installation of TBSM creates two databases with the default names: 

TBSM This database is required and contains primary data typically associated 

with TBSM, such as service instance data, template and rule data, Service 

Component Repository (SCR) data, and configuration artifacts 

TBSMHIST 

(Optional) This database contains historical metric data. If the TBSMHIST 

database is not created, the TBSM database stores the historical metric 

data. 

On the DB2 server, run the DB2 command shown to list the databases that were 

created for your TBSM environment: 

db2 list database directory 

Note: When a required DB2 backup and restore combination is not allowed, such 

as between different operating systems, you can copy data between DB2 databases 

using the db2move command or using the DB2 export utility followed by the import 

or load utilities. For more information on the DB2 backup and restore commands, 

and other export and import capabilities, see the DB2 information center for the 

version appropriate to your requirements: http://publib.boulder.ibm.com/ 

infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.common.doc/doc/t0021844.html. 


Backup the TBSM database information from the source DB2 

server 

To backup the TBSM database information: 

Procedure 

1. Stop the source Data server and the Discovery Library Toolkit. 

2. On the source DB2 server, create a temporary directory to which you can save 

the backed-up TBSM database information. 

3. On the source DB2 server, for each of the TBSM databases created on the 

source DB2 server, execute the following command: 

db2 backup database to 

Where is the name of the source DB2 database that you 

want to backup and is the path to the target 

directory in which you want to store the database. 

4. Start the source Data server and Discovery Library Toolkit. 

5. Copy each of the backed-up TBSM database from the source DB2 server to the 

target DB2 server. 

Restore the TBSM database information on the target DB2 

server 

To restore the TBSM database information to be used by the target TBSM servers, 

perform the following steps: 

Procedure 

1. Stop the target Data server and Discovery Library Toolkit. 

2. On the target DB2 server, for each of the TBSM databases copied from the 

source DB2 server, execute the command: 

db2 restore db from 

Where is the name of the DB2 database that you want to 

restore and is the path to the backup directory in 

which you have stored the database. 

3. On the target Data server, execute the Discovery Library Toolkit commands: 

a. To view the entries in the Discovery Library Toolkit registry: 

UNIX 

$TBSM_HOME/XMLtoolkit/bin/registryupdate.sh -U db2admin_ID -P 

db2admin_password -v 

Windows 

%TBSM_HOME%\XMLtoolkit\bin\registryupdate.bat -U db2admin_ID -P 

db2admin_password -v 

where: 

-U The database administrative user ID 

-P The database administrative user password 

-v Displays the contents of the Discovery Library Toolkit registry table. 

b. To update the registry entry for the Discovery Library Toolkit instance 

installed on the target Data server, with the correct identifier specified by 

the value of the DL_Toolkit_Instance_ID property specified in the 

xmltoolkitsvc.properties file, execute the command: 

Cloning your TBSM servers 159

UNIX 

$TBSM_HOME/XMLtoolkit/bin/registryupdate.sh -U db2admin_ID -P 

db2admin_password -s ID 

Windows 

%TBSM_HOME%\XMLtoolkit\bin\registryupdate.bat -U db2admin_ID -P 

db2admin_password -s ID 

where: 

-U The database administrative user ID 

-P The database administrative user password 

-s Updates the Discovery Library Toolkit registry table based on the 

integer value that you enter. This integer represents the registry 

entry that you want to update. This list is displayed using the -v 

option. Valid values are 1 and 2. Choose the ID of the registry entry 

that represents the Discovery Library Toolkit instance running on 

the target Data server. 

4. Start the target Data server and Discovery Library Toolkit. 

Export and Import the TBSM Impact project 

Using the Netcool/Impact nci_export and nci_import commands, copy the 

policies contained in the Impact TBSM project from the source Data server to the 

target Data server. 


For more information about the nci_export and nci_import commands, see the 

Netcool/Impact Administration Guide. 

Procedure 

1. To export the TBSM Impact project, from the $TBSM_HOME/bin directory on the 

source Data server, execute the command: 

Windows 

nci_export.bat TBSM --project TBSM 

UNIX 

nci_export TBSM --project TBSM 

where the is the directory to which the source 

Data server files are copied. 

Note: You must choose an export directory name that is not already present on 

your system. If the directory does exist, the command fails. 

2. Copy the contents of the export directory from the source Data server to the 

target Data server. 

Note: If Impact artifacts related to TBSM were customized outside of TBSM or 

were not added to the TBSM project, it might be necessary to copy the artifacts 

to Impact on the target Data server. 

3. To import the TBSM project file copied from the source Data server, locate the 

export directory copied from the source Data server. 

4. Delete the DataSources directory from the export directory. 

5. Change to the Projects directory of the export directory. Edit file TBSM.proj as 

follows: 


a. Change the property impact.datasrc.numdatasrc to have a value of 2. 

b. Remove the impact.datasrc properties that define the user-defined 

datasources. Do not remove impact.datasrc.0=TBSMComponentRegistry and 

impact.datasrc.1=Internal. If the numbers associated with these two 

datasources are not 0 and 1 respectively, change the numbers to 0 and 1. 

This is as example project file before you edit it: 

impact.datasrc.4=OracleDS 

impact.datasrc.3=SybaseTBSM_ds 

impact.datasrc.numdatasrc=6 

impact.datasrc.2=OracleDS 

impact.datasrc.1=Internal 

impact.datasrc.0=TBSMComponentRegistry 

impact.policy.numpolicy=5 

impact.policy.4=SCR_GET_SEED_EVENTIDS_AND_PROPERTIES 

impact.policy.3=ESDA_Custom_SCC_TopLevelOrphan_Down_1 

impact.policy.2=ESDA_Custom_SCC_TOPLEVEL_Down_1 

impact.policy.1=ESDA_Custom_SCC_ESDA_CHILD_RETRIEVE_Down_1 

impact.policy.0=ESDA_Custom_SCC_ESDA_Parent_RETRIEVE_up_1 

impact.datasrc.5=SybaseTBSM_ds 

This is an example project file after you remove the datasource references. 

impact.datasrc.numdatasrc=2 

impact.datasrc.1=Internal 

impact.datasrc.0=TBSMComponentRegistryimpact.policy.numpolicy=5 

impact.policy.4=SCR_GET_SEED_EVENTIDS_AND_PROPERTIES 

impact.policy.3=ESDA_Custom_SCC_TopLevelOrphan_Down_1 

impact.policy.2=ESDA_Custom_SCC_TOPLEVEL_Down_1 

impact.policy.1=ESDA_Custom_SCC_ESDA_CHILD_RETRIEVE_Down_1 

impact.policy.0=ESDA_Custom_SCC_ESDA_Parent_RETRIEVE 

6. From the $TBSM_HOME/bin directory on the target Data server, execute the 

command: 

Windows 

nci_import.bat TBSM 

UNIX 

nci_import TBSM 

where the is the directory to which the source 

Data server files have been copied. 

Note: If customized policies include information specific to a server, such as 

hostnames and IP addresses, the policies might need to be updated for the 

target Data server environment. 

Export and import TBSM data sources and data fetchers 

Using the TBSM tbsm_export and tbsm_import commands, copy data sources and 

data fetchers defined on the source Data server to the target Data server. 

For more information on the tbsm_export and tbsm_import commands, see the 

TBSM Administrator's Guide. 

Export the TBSM data sources and data fetchers from the source 

Data server 

To export the TBSM data sources and data fetchers: 

Procedure 

1. From the $TBSM_HOME/XMLtoolkit/bin directory on the source Data server, 

execute the command: 


Windows 

tbsm_export.bat -category datasources -directory 

UNIX 

tbsm_export.sh -category datasources -directory 

where is a directory used to store your exported 

files. If it does not already exist, the export directory is created. 

2. From the $TBSM_HOME/XMLtoolkit/bin directory on the source Data server, 


Windows 

tbsm_export.bat -category datafetchers -directory 

UNIX 

tbsm_export.sh -category datafetchers -directory 


data source files. 

3. Copy the contents of the directory to which you have exported your files from 

the source Data server to the target Data server. 

Import the TBSM data sources and data fetchers on the target 

Data server 

To import the TBSM data sources and data fetchers: 

Procedure 

1. From the $TBSM_HOME/XMLtoolkit/bin directory on the target Data server, 


Windows 

tbsm_import.bat -directory 

UNIX 

tbsm_import.sh -directory 


files. 

2. If ITM policy-based data fetchers have been imported from the source Data 

server, the encrypted password used to connect to the ITM Charting Web 

Service must be updated in each data fetcher policy. To update encrypted 

passwords in the imported ITM data fetchers, on the target Data server: 

a. List the imported ITM policy based data fetchers by executing the Rad Shell 

command: 

listITMPolicyDataFetchers(); 

b. For each unique ITM Charting Web Service connection in the list of 

imported ITM policy data fetchers, from the $TBSM_HOME/bin directory, 


Windows 

rad_crypt.bat 

UNIX 

rad_crypt 


where web_service_password is the password to connect to the ITM 

Charting Web Service. The rad_crypt command returns an encrypted 

version of the password.

Additional considerations 

c. Using the encrypted password returned from the rad_crypt command, run 

the command shown to update the ITM Charting Web Service connection 

password for the policy in each applicable ITM policy-based data fetcher: 

updateITMPolicyDataFetchers( "", "", 

"", "", 

"", "", "", ""); 

Where: 

datafetcher 

The name of the data fetcher that you want to update. Pass a value 

of "" to update all the IBM Tivoli Monitoring (ITM) policy-based 

data fetchers. 

protocol 

The connection protocol used to connect to the ITM Charting Web 

Service. The valid values are http and https. 

web_service_host_name 

The fully qualified hostname or IP address of the Tivoli Enterprise 

Portal Server (TEPS) server where the ITM Charting Web Service is 

installed. 

web_service_port_number 

The port number on the TEPS server used to connect to the ITM 

Charting Web Service. 

web_service_name 

The name of the ITM Charting Web Service. The default name is 

TIPWebServiceHttpRouter. 

web_service_user_id 

The user ID used to connect to the ITM Charting Web Service. 

Typically, the username used is sysadmin. 

web_service_password_encrypted 

The encrypted password used to connect to the ITM Charting Web 

Service. 

single_sign_on 

Indicates whether single sign-on between TBSM and ITM is 

configured. The valid values are yes and no. 

The following procedures, which require copying of files and replication of 

contents within files, might be required to clone the Data server if the following 

components, functions or artifacts have been customized. 

Cloning a customized TBSM tree template policy 

If you have customized the TBSM tree template policy on the source Data server, 

copy the customized policy to the target Data server, with a new name, and import 

the file into your cloned environment. 

Procedure 

1. From the $TBSM_HOME/policy directory on the source Data server, copy the 

TBSM_GetTreeColumnValue.ipl policy file to a temporary directory. 

2. Rename the TBSM_GetTreeColumnValue.ipl policy file that you have copied to 

GetTreeColumnValue.ipl. 


3. Copy the GetTreeColumnValue.ipl policy file from the temporary directory on 

the source Data server to a temporary directory on the target Data server. 

4. To import the tree template policy to the target Data server, from the 

$TBSM_HOME/bin directory, execute the command: 

Windows 

nci_policy.bat TBSM push 

/GetTreeColumnValue.ipl 

UNIX 

nci_policy TBSM push 

/GetTreeColumnValue.ipl 

where and are the username and 

password for the Tivoli Integrated Portal administrator role and 

is the directory in which you have stored the tree template 

policy that you want to import. 

TBSM properties files 

If you have edited the TBSM properties files to customize the source Data server, 

and want to maintain the customization on your target environment, you must 

customize the properties files that define these custom changes on the target Data 

server. 

TBSM properties files are contained in the $TBSM_HOME/etc directory: In particular, 

review the TBSM_server.props and TBSM_sla.props files for customized properties. 

However, all files with a .props and .properties extension might have customized 

properties. 

Note: Do not copy properties files from one server to another as they might 

contain information specific to a server, such as hostnames and IP addresses. 

Instead, replicate any changes to property-values contained in source Data server 

properties files to the same file on the target Data server. 

Netcool/OMNIbus 

If the Netcool/OMNIbus ObjectServer has been installed on the source Data server 

and you have customized the configuration, you must replicate the customization 

on the target Data server if you want the target Data server to be customized in 

the same way. Examples of customization include custom tables and changes to 

procedures and triggers. 

If custom SQL files were used to customize the ObjectServer on the source Data 

server, you can use the same SQL files to customize the ObjectServer on the target 

Data server. To use these SQL files, you must use the nco_sql command. 

If the NCO Process Agent is used on the source Data server, you might want to 

replicate any customization to the configuration file on the target Data server. 

v OMNIHOME/etc/nco_pa.conf 


If you are using the Discovery Library Toolkit the Discovery Library Toolkit to 

automatically build service models from Discovery Library data sources on the 

source Data server, you might have customized the Discovery Library Toolkit to 

meet your requirements. Most Discovery Library Toolkit customization changes are 

copied from the source Data server to the target Data server by the DB2 database 

backup and restore process. However, some changes must be made manually. If 


you want to replicate the customization from the source Data server on the target 

Data server, follow the guidelines in this topic. 

Discovery Library Toolkit configuration files 

If the configuration of the Discovery Library Toolkit on the source Data server has 

been customized you can replicate the customization by making the same changes 

to the xmltoolkitsvc.properties configuration file on the target Data server. This 

file is located: 

v $TBSM_HOME/XMLtoolkit/bin/xmltoolkitsvc.properties 

Note: Do not copy properties files from the source Data server to the target Data 

server as they might contain information specific to a server, such as hostnames 

and IP addresses. Property-value changes to properties files on the source Data 

server must be replicated by editing the properties file on the target Data server. 

This can be done by opening, changing, and saving the properties file in a text 

editor. 

Tivoli Application Dependency Discovery Manager configuration 

If you are using Tivoli Application Dependency Discovery Manager version 7.2 or 

earlier as a data source for the Discovery Library Toolkit, you must copy the API 

JAR files from the Tivoli Application Dependency Discovery Manager Discovery 

Manager server on the source Data server to the same location on the target Data 

server. The Tivoli Application Dependency Discovery Manager API jar files are 

located: 

v TBSM_HOME/XMLtoolkit/sdk/clientlib 

Business Service Composer 

If Business Service Composer project files have been loaded into the Discovery 

Library Toolkit on the source Data server, you might want to maintain the same 

project files for the Discovery Library Toolkit on the target Data server. The 

Business Service Compose project files are, by default, stored in following 

directory: 

v $TBSM_HOME/XMLtoolkit/tools/crviewer/projects 

If the configuration of the Component Registry Viewer on the source Data server 

has been customized, replicate the customization on the target Data server by 

editing the file: 

v $TBSM_HOME/XMLtoolkit/tools/crviewer/CRC_config.xml 

. 

EIF Probe 

If the EIF Probe is installed on the source Data server, you might have customized 

the configuration. To maintain the customization on the target Data server, the 

changes you made to the rules and configuration files on the source Data server 

must be replicated on the target Data server. 

EIF Probe files that are commonly updated include: 

v OMNIHOME/probes//tivoli_eif.rules 

v OMNIHOME/probes//tivoli_eif.props 

v other rules files in OMNIHOME/probes/ 


Note: Do not copy properties files from the source Data server to the target Data 





editor. 

Business Service Management agent 

If the Business Service Management agent is installed on the source Data server, 

you might have customized the configuration. To maintain the customization on 

the target Data server, the changes made to the configuration files must be 

replicated on the target Data server. 

Agent files commonly updated include: 

v TMP/kr9_cps.properties 

v CANDLE_HOME//r9/bin/tbsmmonitorcdp.props 

Note: 

v The kr9_cps.properties file should only be updated using the appropriate ITM 

agent configuration process, such as the Manage Tivoli Monitoring Service 

application on Windows systems and the CANDLE_HOME/bin/itmcmd config -A 

r9command on UNIX systems. 

v Do not copy properties files from the source Data server to the target Data 





editor. 


The previous procedures refer to components, functions, and artifacts that are 

commonly customized on the Data server. It is not an exhaustive list of all 

components, functions, or artifacts that can be customized. If you have customized 

any other items on the source TBSM Data server, and want to reflect them on the 

target Data server, you must configure those items on the target Data server. 

Cloning the Dashboard server 

This section describes the procedures to create a clone of the IBM Tivoli Business 

Service Manager Dashboard server. 

Prerequisites 

v the target Dashboard server must not contain custom data 

Steps to clone the Dashboard server 

To clone the Dashboard server: 

1. Export and import the Tivoli Integrated Portal server instance data. 

2. Replicate any customization that has been completed on the source Dashboard 

server on the target Dashboard server. This might include customization to: 

v IBM Tivoli Network Manager 

v TBSM GIS maps, icons, images and style sheets 


v TBSM properties files 

v Netcool/OMNIbus WebGUI 

Note: After completing the procedures applicable to your environment, stop and 

restart the target Dashboard server. 

Export and import the Tivoli Integrated Portal server instance data 

Using the Tivoli Integrated Portal export and import commands, instance data 

related to the Tivoli Integrated Portal and defined on the source Dashboard server 

can be copied to the target Dashboard server. 


The tipcli Export and tipcli Import commands copy customized Tivoli 

Integrated Portal server instance data, including: 

v Custom pages and page elements 

v Custom views 

v Custom roles and mappings 

v Custom console preferences and properties 

For more information on the tipcli Export and tipcli Import commands, see the 

TBSM Administration Guide. 

Procedure 

1. From the $TIP_HOME/profiles/TIPProfile/bin directory on the source 

Dashboard server, execute the command: 

Windows 

tipcli.bat Export --username --password 

--settingFile %NCHOME%\omnibus_webgui\integration\plugins\OMNIbusWebGUI_clon 

e_settings.properties 

UNIX 

./tipcli.sh Export --username --password 

--settingFile $NCHOME/omnibus_webgui/integration/plugins/OMNIbusWebGUI_clon 

e_settings.properties 

where and are the user ID and 

password for the Tivoli Integrated Portal administrator role. 

When the tipcli Export command completes, a data.zip file is created in the 

$TIP_HOME/profiles/TIPProfile/output directory. 

2. Create a temporary directory on the target Dashboard server and copy the 

data.zip file to this location. 

3. Create the $TIP_HOME/profiles/TIPProfile/input directory and copy the 

data.zip file from the temporary directory on the target Data server to the 

$TIP_HOME/profiles/TIPProfile/input directory. 

Note: Do not delete the original of the data.zip from the temporary directory. 

You might require this file for subsequent import operations, for example, in 

the case of an import failure, or for use with other tipcli commands. 

4. From the $TIP_HOME/profiles/TIPProfile/bin directory on the target 

Dashboard server, execute the following command: 

Windows 



tipcli.bat Import --username --password 

--settingFile %NCHOME%\omnibus_webgui\integration\plugins\OMNIbusWebGUI_ 

clone_settings.properties 

UNIX 

./tipcli.sh Import --username --password 

--settingFile $NCHOME/omnibus_webgui/integration/plugins/OMNIbusWebGUI_ 

clone_settings.properties 

The tipcli Import command executes using the data.zip file copied into the 

$TIP_HOME/profiles/TIPProfile/input directory. 

Note: Do not use the tipcli Import command to import IBM Tivoli Network 

Manager (ITNM) configuration files. If ITNM is installed on the target 

Dashboard server, execute the tipcli Import command adding the following 

option: 

--excludePlugins ITNMGUI 

ITNM provides export and import scripts to copy any customized files. 

The following procedures, which require copying of files and replication of 

contents within files, might be required to clone the Dashboard server if the 

following components, functions or artifacts have been customized. 

IBM Tivoli Network Manager 

If IBM Tivoli Network Manager (ITNM) is installed on the source Dashboard 

server, you might have customized the configuration. To maintain the 

customization on the target Dashboard server, you must replicate the changes in 

the configuration files on the target Dashboard server. 

ITNM provides export and import scripts to allow you to replicate any 

customization that you have completed. For more information on the ITNM export 

and import scripts, see the ITNM Information Center located: http:// 

publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic= 

%2Fcom.ibm.networkmanagerip.doc_3.9%2Fitnm%2Fip%2Fwip%2Finstall%2Ftask 

%2Fnmip_upg_cloning.html 

TBSM GIS maps, icons, images, and style sheets 

If TBSM GIS maps, icons, images, or style sheet files have been customized on the 

source Dashboard server, to maintain the customization, you must replicate the 

changes to the files that configure these items on the target Dashboard server. GIS 

maps, icons, images, and style sheet files commonly updated are stored: 

v $TIP_HOME/ profiles/TIPProfile/installedApps/TIPCell/isc.ear/sla.war/av/ 

css/customer 

v $TIP_HOME/ profiles/TIPProfile/installedApps/TIPCell/isc.ear/sla.war/av/ 

css/maps 

v $TIP_HOME/ profiles/TIPProfile/installedApps/TIPCell/isc.ear/sla.war/ 

images 

v $TIP_HOME/ profiles/TIPProfile/installedApps/TIPCell/isc.ear/sla.war/ 

icons 

Note: Depending on the customization on the source server, additional changes 

might be necessary to other directories under $TIP_HOME/profiles/TIPProfile/ 

installedApps/TIPCell/isc.ear/sla.war. 


TBSM properties files 

If TBSM properties files have been customized on the source Dashboard server, to 

maintain the customization, you must replicate the changes on the target 

Dashboard server. The properties files that are commonly updated include: 

v $TIP_HOME/profiles/TIPProfile/installedApps/TIPCell/isc.ear/sla.war/etc/ 

RAD_server.props 

v $TIP_HOME/profiles/TIPProfile/installedApps/TIPCell/isc.ear/sla.war/etc/ 

RAD_sla.props 


might be necessary to other properties files in the $TIP_HOME/profiles/TIPProfile/ 

installedApps/TIPCell/isc.ear/sla.war/etc directory. 

Note: Do not copy properties files from the source Dashboard server to the target 

Dashboard server as they might contain information specific to a server, such as 

hostnames and IP addresses. Property-value changes to properties files on the 

source Dashboard server must be replicated by editing the properties file on the 

target Dashboard server. This can be done by opening, changing, and saving the 

properties file in a text editor. 

Netcool/OMNIbus Web GUI 

If Netcool/OMNIbus Web GUI properties files have been customized on your 

source Dashboard server, to maintain the customization, you must replicate the 

changes on the target Dashboard server. The properties file that must be amended 

is: 

v NCHOME/omnibus_webgui/etc/datasources/ncwDataSourceDefinitions.xml 


might be necessary to other directories under the NCHOME/omnibus and 

NCHOME/omnibus_webgui directories. 

Note: Do not copy properties files from the source Dashboard server to the target 

Dashboard server as they might contain information specific to a server, such as 

hostnames and IP addresses. Property-value changes to properties files on the 

source Dashboard server must be replicated by editing the properties file on the 

target Dashboard server. This can be done by opening, changing, and saving the 

properties file in a text editor. 

Netcool GUI Foundation 

If the source Dashboard server was migrated from a previous release of TBSM, the 

migration war file for Netcool GUI Foundation migration, if present, must be 

copied to the target Dashboard server. After you have copied it to the target 

Dashboard server, you must then deploy it. The migration war file supports pages 

originally configured using Netcool GUI Foundation in TBSM version 4.1.1 and 

earlier. To copy and deploy the Netcool GUI Foundation migration war file: 

Procedure 

1. Locate and copy the TBSM_HOME/migrate/migration_tool/backup/ 

NGF2TIPGeneratedConsoleModule.war directory, and its contents, from the source 

Dashboard server to a temporary directory on the target Dashboard server. If 

the file is not present on the source Dashboard server, ignore the remaining 

steps. 

2. On the target Dashboard server, create a new tbsm_cloning_war.jacl file: 


a. Copy the tbsm_migration_war_base.jacl file from the 

$TBSM_HOME/upgrade/etc directory to the temporary directory that contains 

the NGF2TIPGeneratedConsoleModule.war directory. 

b. Rename the copied version of the tbsm_migration_war_base.jacl file to 

tbsm_cloning_war.jacl. 

c. Open the tbsm_cloning_war.jacl file file in a text editor. Locate the line 

that contains: 

__TBSM_EXPORT_DATA_DIRECTORY__ 

d. Edit the reference to refer to the temporary directory location on the target 

Dashboard server. The resulting -contents parameter in the 

tbsm_cloning_war.jacl file reads: 

-contents /NGF2TIPGeneratedConsoleModule.war 

where is the temporary directory that contains the 

NGF2TIPGeneratedConsoleModule.war directory 

3. From the $TIP_HOME/profiles/TIPProfile/bin directory on the target 

Dashboard server, deploy the migration war file by executing the command: 

Windows 

wsadmin.bat -f %TBSM_HOME%\etc\tbsm_cloning_war.jacl -username 

-password 

UNIX 

wsadmin.sh -f $TBSM_HOME/etc/tbsm_cloning_war.jacl -username 

-password 

where and are the username and 

password for the Tivoli Integrated Portal administrator role. 

Additional requirements 

The previous procedures refer to components, functions, and artifacts that are 

commonly customized on the Dashboard server. It is not an exhaustive list of all 

components, functions, or artifacts that can be customized. If you have customized 

any other items on the source Dashboard server, and want to reflect them on the 

target Dashboard server, you must configure those items on the target Dashboard 

server. 


Configuring TBSM: post installation 

Installing a Java plug-in 

This section contains information about configuring your TBSM system. 

After you install the Dashboard server, check if you have the correct Java plug-in 

version for the IBM Tivoli Business Service Manager console. 


To determine, obtain, and install the correct version of the Java plug-in. 

Important: If you use the 64-bit version of Internet Explorer, you must use the 

64-bit version of the Java. Otherwise, use the 32-bit version of the Java. 

Determine currently installed plug-in: From a browser on the console system, 

open the link: http://www.javatester.org/version.html. 

Procedure 

1. Determine the supported plug-in versions. 




Reports at: 


For more information about running the Software Product Compatibility 

Reports, see the Overview and Planning section of the TBSM Wiki. 



2. If you want to use the Oracle plug-in: 

The Oracle Java plug-in is not supplied by IBM. To manually install the Oracle 

plug-in on a client system: 

a. Go to the download page at java.com. 

b. Click Free Java Download and follow the installation instructions. 

c. After you complete the installation, restart your web browser. 

3. If the console is on Windows and you want to use the IBM plug-in: 

Download the TBSM interim fix: 6.1.1.0-TIV-BSM-IF0001 from the IBM Fix 

Central site at: 


identifyFixes?query.parent=ibm~Tivoli&query.product=ibm~Tivoli~Tivoli 

Business Service Manager&query.release=All&query.platform=All 

To install the IBM Java plug-in on a client system, follow the instructions 

included with TBSM interim fix 6.1.1.0-TIV-BSM-IF0001. 


Installing the Historical Reports 

You can use the TBSM report installation script to install the TBSM Historical 

Reports where the Tivoli Common Reporting server is installed. 


The following conditions must be met: 

Tivoli Common Reporting must be installed. 

Tivoli Common Reporting requirements 

Install Tivoli Common Reporting version 2 release 1 or higher. Reference 

the TCR documentation for installation guidance. You can install TCR on 

different server than TBSM. 

On the Tivoli Common Reporting host, install the database client you need 

to connect to the Tivoli Data Warehouse. 

For information on installing Tivoli Common Reporting and a database 

client, see Tivoli Common Reporting information center: 


com.ibm.tivoli.tcr.doc_21/ic-home.html 


This installer imports the TBSM reports to the Tivoli Common Reporting (TCR) 

portlet. The reports use the data in the Tivoli Data Warehouse collected by the 

Tivoli Business Service Management agent. TCR provides additional functionality 

to modify and enhance reports using the Cognos-based report packages. A data 

model is provided to enable customer report development with the TBSM 

historical data and the Cognos Query Studio. 

Note: Support for Business Intelligence and Reporting Tools (BIRT) reports has 

been deprecated in TBSM 6.1.1. However, the BIRT reports provided previously 

with TBSM are available for use. An equivalent Cognos report is available for each 

of the BIRT reports. 

Procedure 

1. Copy the reports installer package from the TBSM install package to the Tivoli 

Common Reporting server host. The reports installer is located in the directory 

//Reports 

Where platform is the operating system on the host where you installed TBSM. 

For example: 

v For Windows: \windows\Reports\ 

v For LINUX: /linux/Reports/ 


v Do not specify an installation directory path that includes parenthesis, such 

as c:\Program Files (x86). The install may succeed with this path, but 

other utilities and components will fail when you attempt to run the 





2. Run the install_reports script. 

v For Windows run the script: install_reports.bat 

v For UNIX: run the script: install_reports.sh 

3. The script prompts you that the report package will be overwritten. 

TBSM History Report package will be overwritten. Continue (yes or no)? 

If you have customized the reports in the TBSM History Agent package, copy 

the customized reports to another folder to save them before installing the 

updated reports. Otherwise, the installation script over writes the existing 

package, and you will loose any customization you made. If you need to save 

the existing reports, respond no, save the reports, and run the install script 

again. Please see Tivoli Common Reporting information center for more 

information on how to save your existing reports. 

4. The script runs in a command window. Specify the information, using the 

TBSM Reports install settings topic as your guide. 

TBSM reports install settings 

This topic describes the settings for the TBSM reports installer. 

Purpose 

To install the TBSM reports, you need to specify these settings. You can provide the 

information in interactive prompts or in a properties file. 

Tivoli Integrated Portal settings 

These prompts let you specify your Tivoli Integrated Portal settings. 

Directory for Tivoli Common Reporting 

The directory where Tivoli Common Reporting component is installed. It is 

the path to bin/trcmd. 

Properties file setting: TCR_DIR 

Tivoli Integrated Portal Administrator ID 

The user ID for the Tivoli Integrated Portal administrator 

Properties file setting: TIP_ADMIN 

Tivoli Integrated Portal Administrator password 

The password for the Tivoli Integrated Portal administrator 

Properties file setting: TIP_PASSWORD 

Database settings 

These prompts let you specify your database settings. 

Database type 

The database type for the Tivoli Data Warehouse. Valid values are DB2, 

ORACLE, MSSQL for DB2, Oracle, or Microsoft SQL server. 

Properties file setting: DB_TYPE 

Configuring TBSM: post installation 173

Database user id 

This parameter is required when if you want to configure the datasource 

from the report installer. This user must have write permissions in the 

database. 

Properties file setting: DB_USER 

Database user password 

Password for the database user. 

Properties file setting: DB_USER_PASSWORD 

Configure Tivoli Data Warehouse datasource 

If you want to configure Tivoli Data Warehouse datasource from the 

installer, enter Yes/. Otherwise, enter No. You can enter No if the Tivoli 

Data Warehouse has already been defined. If you have installed other ITM 

agent reports that use the Warehouse, then the datasource has been defined 

by them. 

If you enter Yes, you need to specify a database user ID. 

Properties file setting: CONFIG_TDW 

Database name, alias 

This parameter is required when if you want to configure the datasource 

from the report installer. 

For Oracle, specify the SID. 

Properties file setting: DB_ALIAS 

JDBC driver settings 

These prompts let you specify the information on your JDBC drivers for your 

database type. The installer validates the values you enter and will prompt you if 

your entries are not valid. 

JDBC host name 

Host where Tivoli Data Warehouse resides. 

Properties file setting: JDBC_DB_HOST 

JDBC port 

Port number for the JDBC driver. 

Default = 50000 

Properties file setting: JDBC_DB_PORT. 

JDBC database name, Oracle SID or, alias 

The database name for DB2 or Microsoft Microsoft SQL server. This is 

usually WAREHOUS. 

For Oracle, specify the SID. 

Properties file setting: JDBC_DB_NAME 

For DB2, this is the catalogued name. 

Tivoli Data Warehouse SCHEMA 

The Tivoli Data Warehouse SCHEMA name. The default is ITMUSER. 


Properties file setting: JDBC_SCHEMA 

JDBC driver class name 

The driver class name for the database type. These are typically provided 

by the database vendor with the database or the database client package. 

Table 12. JDBC driver class names 

Database type Driver name 

DB2 com.ibm.db2.jcc.DB2Driver 

Oracle oracle.jdbc.driver.OracleDriver 

Microsoft SQL Server com.microsoft.sqlserver.jdbc.SQLServerDriver 

. 

Properties file setting: JDBC_CLASS_NAME 

JDBC driver jar file name 

The driver jar file name for the database type. These files are typically 

provided by the database vendor with the database or the database client 

package. 

Table 13. JDBC driver jar file names 

Database type Driver name 

DB2 db2jcc.jar,db2jcc_license_cu.jar 

Oracle ojdbc14.jar 

Microsoft SQL Server sqljdbc.jar 

. 

Properties file setting: JDBC_FILES 

JDBC driver file directory 

The directory were the JDBC driver files reside. DB2 drivers are usually 

provided at tcr_install/tipv2/universalDriver/lib. 

Properties file setting: JDBC_DIR 

Install of reports with file parameter 

You can also specify the install settings in a file when you run the installation 

program. 


To install the reports with the file parameter, edit the sample properties file and 

run the reports installer and specify the file parameter. The TBSM install package 

includes a sample properties file named install_reports.sample_properties in the 

//Reports directory. 

Procedure 

1. Make a copy of the file: install_reports_sample_properties and edit the 

properties for your environment. The properties file includes information on 

these settings and you can also see the TBSM Reports install settings topic for 

more information. 

2. Run the reports installer in silent mode, using your properties file as input: 


install_reports.bat f my_propertiesfilename 

install_reports.sh –f my_propertiesfilename 

3. The script prompts you that the report package will be overwritten. 

TBSM History Report package will be overwritten. Continue (yes or no)? 

If you have customized the reports in the TBSM History Agent package, copy 

the customized reports to another folder to save them before installing the 

updated reports. Otherwise, the installation script over writes the existing 

package, and you will loose any customization you made. If you need to save 

the existing reports, respond no, save the reports, and run the install script 

again. Please see Tivoli Common Reporting information center for more 

information on how to save your existing reports. 

Example 

This example shows the content of the sample properties file: 

# Properties file for installing TBSM historical report in silent mode 

# install_reports -f reports.properties 

# Directory where TCR component is installed. 

# Ex: c:\ibm\tivoli\tipv2Components\TCRComponent 

TCR_DIR= 

# TIP Admin userID 

TIP_ADMIN=tipadmin 

# TIP Admin password 

TIP_PASSWORD= 

# Database type: DB2 , ORACLE , MSSQL 

DB_TYPE=DB2 

# Database user id. This parameter is required 

DB_USER= 

# Database user password. This parameter is required 

DB_USER_PASSWORD= 

# Specify yes or no to configure TDW Cognos datasource (for Tivoli Data Warehouse) 

# Specify no if it is already defined 

CONFIG_TDW=yes 

# Database name alias. For oracle, specify SID. 

# This parameter is required when CONFIG_TDW=yes 

DB_ALIAS= 

# Tivoli Data Warehouse database host name 

JDBC_DB_HOST= 

# Tivoli Data Warehouse database port 

JDBC_DB_PORT=50000 

# Tivoli Data Warehouse DB2 database name or Oracle SID or MSSQL database name 

JDBC_DB_NAME=WAREHOUS 

# Tivoli Data Warehouse SCHEMA 

JDBC_SCHEMA=ITMUSER 

# JDBC driver class name 

# For DB2, specify com.ibm.db2.jcc.DB2Driver 

# For Oracle, specify oracle.jdbc.driver.OracleDriver 


# For Microsoft SQL Server, specify com.microsoft.sqlserver.jdbc.SQLServerDriver 

JDBC_CLASS_NAME=com.ibm.db2.jcc.DB2Driver 

# JDBC driver jar file 

# For DB2, specify db2jcc.jar,db2jcc_license_cu.jar 

# For Oracle, specify ojdbc6_g.jar 

# For Microsoft SQL Server, specify sqljdbc.jar 

JDBC_FILES=db2jcc.jar,db2jcc_license_cu.jar 

# JDBC driver file directory 

# Ex: c:\ibm\tivoli\tipv2\universalDriver\lib 

JDBC_DIR= 

Enabling Show 30 day History option 


To enable the Show 30 day history option for reports, assign the correct user role 

and configure the TBSM Data server for the option. To assign the 

tcrPortalOperator role: 

1. Log on to the TBSM console as a user with administration roles. 

2. In the task list, click Users and Groups --> User Roles . 

3. Assign the tcrPortalOperator role to the users that require the role. 

Configure the Data server: 

Procedure 

1. Extract the TDWHistory.xml from the DB2 database with the command: 

For UNIX and Linux hosts: 

$TBSM_HOME/XMLtoolkit/bin/getArtifact.sh -name TDWHistory.xml 

-category menuactions -subcategory action -directory /tmp 

For Windows hosts: 

%TBSM_HOME%\XMLtoolkit\bin\getArtifact.bat -name TDWHistory.xml 

-category menuactions -subcategory action -directory \tmp 

2. Edit the TDWHistory.xml located in the temporary directory you specified with 

the getArtifact command. 

3. Replace roleRequired="tbsmViewTDWHistory" with roleRequired=" 

tcrPortalOperator" and save the changes. 

4. Put the TDWHistory.xml back in the database with the command: 

UNIX 

$TBSM_HOME/XMLtoolkit/bin/putArtifact.sh -name 

/tmp/TDWHistory.xml -category menuactions -subcategory action 

Windows 

%TBSM_HOME%\XMLtoolkit\bin\putArtifact.bat -name 

\tmp\TDWHistory.xml -category menuactions -subcategory action 

5. Run the rad_reinitcanvas command. 

UNIX 

$TBSM_HOME/bin/rad_reinitcanvas tipadmin tippass 

Windows 

%TBSM_HOME%\bin\rad_reinitcanvas.bat tipadmin tippass 

6. Log on to the TBSM console and the menu should be enabled. 


Specifying the schema name 


This task describes how to specify the schema name for the Tivoli Data Warehouse. 

Procedure 

1. The TBSM History Agent Cognos-based reports are configured for the schema 

name of ITMUSER for the Tivoli Data Warehouse tables. You can specify any 

valid user ID at the prompt or with the DB_USER setting in the installation 

properties file. 

Note: For deprecated BIRT reports, specify the schema name with the 

JDBC_SCHEMA property file or at the prompt. The schema name does not need to 

be ITMUSER. 

2. If the schema name is not ITMUSER, the database administrator can create a 

database alias for the tables in the TBSM History Agent data model. DB2 and 

Oracle let you create an alias (synonym in Oracle). This example shows the 

DB2 commands that are used to create the alias that is required for the TBSM 

History Agent tables. In this example, TESTITMUSER is the user-defined schema 

for the tables. 

create alias ITMUSER."KR9_TBSM_SERVICE_STATUS" for 

TESTITMUSER."KR9_TBSM_SERVICE_STATUS"; 

create alias ITMUSER."KR9_TBSM_SERVICE_INDICATORS" for 

TESTITMUSER."KR9_TBSM_SERVICE_INDICATORS"; 

create alias ITMUSER."KR9_TBSM_STATUS_CHANGE_EVENT" FOR 

TESTITMUSER."KR9_TBSM_STATUS_CHANGE_EVENT"; 

3. If your database is MS SQL or the database administrator does not want to 

create alias names, you must update the data model with the schema name as 

follows: 

a. Install and configure the Cognos Framework Manager, which is the data 

modeling tool. See the instructions for the version of Common Reporting 

you have deployed at: http://www.ibm.com/developerworks/wikis/ 

display/tivolidoccentral/Tivoli+Common+Reporting. For instructions, go 

the information center for your version and see Configuring > 

Configuring Framework Manager connection. 

b. Open the Framework Manager. Select File > Open. Browse to the extracted 

TBSM reports package. Browse to the "model" folder and select the 

TBSM_History_Agent.cpf file. 

c. If you are prompted for login credentials, enter your tipadmin user ID and 

password. 

d. After the TBSM History Agent model in the Framework Manager opens, 

expand Data Sources under TBSM History Agent in the Project Viewer. 

e. Select TBSM_HIST_DATA under Data Sources. 

f. When you select TBSM_HIST_DATA, the Properties view is updated with 

information about the data source. By default, the Properties view is located 

at the bottom center of the screen. If you do not see it there, select View > 

Properties. 

g. In the Properties, edit the Schema field, add your schema name. 

h. Save the project. 

i. In the Project Viewer, expand Packages. 

j. Right-click IBM Tivoli Business Service Manager History Agent. 

k. Select Publish Packages. 


Configuring data source failover 

l. The Publish Wizard opens. 

m. Keep the default selection and click Next. 

n. Click Next on the next screen. 

o. Clear the Verify the package before publishing check box. 

p. Click Publish. 

q. A window is displayed that alerts you that A package with that name 

already exists and asks Do you want to publish this package? 

r. Click Yes. 

s. After the package is published, you are informed that the package has been 

published. 

t. Go back to Tivoli Common Reporting and check if the Modified field of 

"IBM Tivoli Business Service Manager History Agent" in the Public Folders 

of IBM Cognos Connection shows the time of publishing. 

Note: You can leave the schema name blank when you modify the Framework 

Manager. If it is empty, then Cognos assumes that the schema name is the same 

as the user ID specified for the Tivoli Data Warehouse data source connection. 

If you want to specify a data source connection user ID different from the 

schema name, you must explicitly specify the schema name in the Framework 

Manager data source property. 

The failover capability associated with TBSM data sources used in ESDAs and data 

fetchers and is separate from the failover support of the TBSM Data server. If a 

data source (or database) has a primary and a backup server, you can enable the 

use of the backup database. 



v You must have completed all failover configurations for your data source. 

v All the TBSM servers must be running. 

Procedure 

1. In the left navigation pane, click Administration and then click Service 

Configuration. The Service Configuration page is displayed. 

2. Under Service Navigation, select the Data navigation view. 

3. Select the data source for which you want to enable the use of the backup 

server. 

4. On the Edit tab in the Service Editor, scroll down until the primary source 

information is displayed. 

5. Clear the Disable Data Source Fail Over check box. 

6. Enter information for the backup source. 

Configuring IBM Tivoli Business Service Manager for failover 











When failover is configured for TBSM data servers, it does not mean DB2 must 

also be in failover. Also, it is possible to have DB2 failover setup without TBSM 

failover. In this case, TBSM can be configured for DB2 replication by using 

fo_config template and not setting a backup data server host, but setting a backup 

DB2 host. 




Related reference: 

“Data server communication settings” on page 65 


“Dashboard server configuration” on page 81 


Overview of the failover process 

A failover environment contains a primary and backup Data server and optionally 

a primary and backup Netcool/OMNIBus ObjectServer. The ObjectServer and Data 

server can be located on the same or on different computers. If the primary host 

fails or the network connection between the primary and backup servers is lost, 

the backup server takes over the processes of the primary server. 

TBSM Data server and ObjectServer failover provides support for TBSM event and 

status processing, ObjectServer event and status processing, or both in the event of 

a hardware or software failure that affects one of these capabilities. You can 

configure a single backup Data server, a single backup ObjectServer, or both that 

takes over processing if the primary server fails. These backup servers do not 

perform any operational processing when the primary server is functional. 

Therefore, these backup servers do not perform any load-balancing function. 

Within a few minutes of startup time, the backup server or servers loads its 

database and resynchronizes its status from events. If the primary server resumes 

function while the backup server is running as the primary server, the original 

primary server assumes the role of backup server. 

You can configure the system so that the original server assumes the role of 

primary, and the backup server returns to its backup role. This behavior is called 

fail back. 

If there is network connectivity loss between the primary and backup servers, the 

backup server assumes the role of primary server and the original primary server 

still functions as the primary server. When connectivity resumes, the backup server 

detects that the primary server is running again and it transitions back the to role 

of backup server. If the backup server is restarted, it resumes its backup role. 

A data fetcher failure in the primary server does not trigger the failover process. If 

the primary data fetcher cannot connect to the database, the backup data fetcher 

probably cannot connect either. 


Figure 3. Failover architecture 

Figure 3 illustrates the architecture of a failover environment. 

By default, both the primary and backup TBSM Data and Dashboard servers use 

the primary instances of Tivoli Netcool/OMNIbus. The backup servers for the 

supporting applications also use the primary servers of the other applications by 

default. 

Time Window Analyzer metric data store 

As with all properties files, all the TBSM Metric Collection property files must be 

kept in sync between the primary and backup TBSM Data servers. The TBSM 

Metric Collection Component does not provide any automatic processes for 

syncing these files. 

Differences between 6.1x and 4.2.1 failover 

In 4.2.1, the two failover peers needed to start up together. This is no longer the 

case. You can start the primary and it will be fully functional by itself. You can 

start the backup any time after you start the primary. If you start the backup first, 


it will wait for the primary to come up (by default 5 minutes- configurable with 

the DATA_BackupMillisecondsTillStartAsStandalone property). If the primary did 

not come up after this time, the backup will start up as the primary. 

In 4.2.1, TBSM replicated data to the primary and backup postgres databases. 

TBSM 6.1x does not replicate any data from primary to backup database. Database 

replication is now handled via HADR functionality within DB2. You configure DB2 

to be in HADR, and all data replication is handled by DB2. 

Note: You do not need database replication when you have TBSM failover. 

In 4.2.1, if the backup was the active primary and when the primary was brought 

back up, it would assume the role of the standby. TBSM 6.1x supports the failback 

option. You can configure the primary to take over the primary role when it comes 

up. 

In 4.2.1, in the event of a network outage (in which both servers assume the 

primary role), when the network was restored, the backup server would shut itself 

down. In 6.1x, it transitions into the backup role upon restoration of network 

connectivity. 

In 4.2.1, some configuration screens in the UI were disabled when the backup data 

server was acting primary. This limitation does not exist in 6.1x. In 6.1x, the data 

server you use for the backup server needs to be specified as such at install time, 

by checking the box to indicate it will be a backup server. The fo_config script 

must still be run against primary and secondary servers post-installation. 

Requirements for setting up a failover environment 

When you install a Data server as a backup server, you must indicate this during 

the install by selecting a check box.. These requirements are in addition to the 

requirements for using the TBSM database, Discovery Library Toolkit, EIF probe, 

and SLA events. 

When the servers are installed, the following requirements must be met for a 

failover configuration to function correctly: 

v The primary and backup servers must be running the same operating system 

and the same version and release of TBSM. 

v The same non-root user ID and password must be used to install TBSM on the 

primary and backup servers. 

v The primary and backup server must use the same authentication method, either 

LDAP or OMNIbus. The file-based authentication method is not supported for 

failover configurations. You must select Advanced Installation to be able to 

choose the authentication method. 

v For Netcool/OMNIBus authentication, you need to configure all the Data and 

Dashboard servers in your failover configuration for both the Primary 

(host1/port1) and backup (host2/port2) ObjectServers. For instructions on how 

to configure the TBSM servers for external authentication, see the TBSM 

Administration Guide > Configuring TBSM > Manually configuring TBSM for 

external user repositories. 

v If any default port values were changed during installation, use these same 

values for both installations. 


Discovery Library Toolkit requirements 

On both the primary and backup Data servers. both instances of the Discovery 

Library Toolkit must point to the same data source: the Discovery Library books, 

IBM Tivoli Application Dependency Discovery Manager, or both. 

Tivoli Event Integration Facility probe requirements 

If the EIF probe is installed on the primary ObjectServer, it must also be installed 

on the backup ObjectServer. 

DB2 high availability configuration 

This topic provides information on DB2 high availability. 

When failover is configured for TBSM data servers, it does not mean DB2 must 

also be in failover. Also, it is possible to have DB2 failover setup without TBSM 

failover. In this case, TBSM can be configured for DB2 replication by using 

fo_config template and not setting a backup data server host, but setting a backup 

DB2 host. 

The recommended way to configure failover for DB2 in a TBSM environment is to 

use High Availability and Disaster Recovery (HADR). This automatically replicates 

all changes from the active database to the standby database, such that when the 

standby database takes over it has the same data as was on the active database. A 

detailed description of the HADR configuration procedure can be found in the IBM 

redbook at: 

http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf 

Follow these guidelines when configuring HADR: 

Primary and standby systems need the same operating system and level. 

Ensure that the primary and standby systems have the same operating 

system and level. 

Primary and standby user credentials 

You must assign the same username and password of the instance owners 

on both the primary and secondary DB2 servers. 

HADR setup chapter notes 

The section on configuring HADR on the user interface is described in 

HADR setup chapter of the redbook. 

v The configuration is started by running db2cc, right clicking on the 

TBSM database and selecting the option for High Availability Disaster 

Recovery. 

You need to configure HADR separately on each database where you 

need failover. In a typical TBSM installation there are two databases: the 

TBSM database (which by default contains all TBSM configuration) and 

the TBSMHIST database (which by default contains metric history data). 

For most of rest of the steps you should be able to follow the 

instructions outlined in the redbook. For the screen titled Copy objects to 

the Standby System (p.64), you can simply click Next and not configure 

anything. 


v For the screen titled "Specify synchronization mode for peer state log 

writing", select "Near synchronous" as the synchronization mode. 

v In the screen titled Specify TCP/IP communication parameters (p. 65) 

enter the fully qualified domain names rather than short host names or 

IP addresses. The screen capture in the redbook (p. 67) does not contain 

the Peer Window configuration at the bottom of this screen. You should 

set this value to be 60 (do not leave it 0, which is the default). 

DB2 HADR does not provide automatic takeover of the standby when the primary 

database becomes unavailable. In order to enable automatic failover for DB2, TSA 

(Tivoli System Automation) must be configured. Read the guidelines for UNIX and 

Windows systems. 

UNIX TSA configuration guidelines 

This topic provides information on how to configure TSA (Tivoli System 

Automation) for DB2 on UNIX systems. 

In order to enable automatic failover for DB2 on UNIX systems, you need to 

configure TSA (Tivoli System Automation) using these guidelines. 

On UNIX platforms, TSA is installed with DB2 and it is configured by the IBM 

DB2 High Availability Instance Configuration Utility (db2haicu). 

The db2haicu utility is in the sqllib/bin directory. 

Documentation on using the db2haicu utility can be found in the whitepaper at: 

http://www.ibm.com/developerworks/data/library/long/dm-0907hadrdb2haicu/ 

Note: To configure TSA for DB2 9.7, you need to install fixpack3 before running 

db2haicu. 

Automatic failover configuration guidelines 

Pages 11-19 in this document describe how to configure automatic failover with 

db2haicu (from section 4.1.3 until the end of section 4). Follow these guidelines 

when you set up TSA: 

Quorum configuration 

For the quorum configuration (Section 4.2 p. 14) the simplest approach is 

to specify a single ip address that is reachable from both primary and 

standby DB2 machines as the ip for the quorum device. This is also the 

approach described in the white paper. Once the db2haicu utility has 

finished, your high availability DB2 configuration should be complete. 

Creating a Cluster Domain 

In section 4.2 (Creating a Cluster Domain subsection), if a domain already 

exists then it should be deleted using db2haicu -delete' on both instances. 

Also in this section, step 3 - the fully qualified domain name must be 

entered here. 

Network Setup 

In section 4.2 (Network Setup subsection) - if primary and standby 

instances are in different subnets then this section should not be run. 


Virtual IP Address Setup 

In section 4.2 (Virtual IP Address Setup subsection) - As above, a VIP 

cannot be created if the primary and standby instances are in different 

subnets. 

Automating HADR failover & Primary Instance Setup 

In section 4.2 (Automating HADR failover & Primary Instance Setup 

subsections) - the listed output will be different (i.e a subset) if the 

Network Setup subsection has not been run. 

Windows TSA configuration guidelines 

This topic provides information on how to configure TSA (Tivoli System 

Automation) for DB2 on Windows systems. 

In order to enable automatic failover for DB2 on Windows systems, you need to 

configure TSA (Tivoli System Automation) using these guidelines. 

On Windows platforms, TSA does not come embedded in the DB2 installation, and 

you need to download and install IBM Tivoli System Automation for Multi 

Platform (SAMP). This can be obtained online at: 

http://www-01.ibm.com/software/tivoli/products/sys-auto-multi/ 

On win2008 x64 platform, SAMP depends on SAU, which can be downloaded 

from the MicroSoft website at: 

http://www.microsoft.com/downloads/en/ 

results.aspx?freetext=subsystem+for+unix-based+applications&displaylang=en 

&stype=s_basic 

Automating DB2 HADR failover on Windows document notes 

To configure TSA for Windows (SAPM), review the online document Automating 

DB2 HADR Failover on Windows using Tivoli System Automation for Multiplatforms. 

This document can be downloaded from the url: 

http://public.dhe.ibm.com/software/data/sw-library/db2/papers/ 

hadr_tsa_win.pdf 

This document describes the procedure for installing and configuring SAMP. 

Script patches 

In Appendix C, the document details copying some necessary scripts into 

the DB2 installation. Two of those scripts that come with the SAMP 

package described earlier contain defects (mkhadr and hadr_monitor.ksh), 

and need to be updated with fixed versions of the scripts. These fixed 

versions can be found in the TBSM install in the directory: SAMP directory. 

INSTALL_HOME/tbsm/contrib/SAMP 

Script notes 

With regard to the scripts mentioned in Appendix C, the user must ensure 

they exist on both cluster nodes, otherwise the command: ./mkdb2" will 

fail. 

Script permissions 

The owner/group of directory sapolicies must be changed to 


Administrator/+Administrators, and execution permission must be given 

to it. To change permissions, run the commands: 

$ pwd 

/usr/sbin/rsct/ 

$ chmod -R 777 sapolicies 

$ chown -R Administrator:+Administrators sapolicies 

Setting up a failover environment 

After you have installed the servers and components that you use in your 

environment, you must perform some specific failover configuration tasks. 


Before you begin, all Data servers, Dashboard servers and ObjectServers that you 

use must be installed. 

If you installed the optional Tivoli Event Integration Facility probe, it must be 

installed on both the primary and backup ObjectServers. 

See the product-specific installation instructions for specific information about 

installing servers and components for a failover environment. 

In order to configure a server to be a backup data server, you need to specify the 

server as a backup when you install it. That is, select the Designated backup 

server option on the Data server configuration panel. 


To configure your environment for failover, perform the following steps: 

Procedure 

1. Stop all Data, Dashboard, and OMNIbus servers in your configuration. 

2. Prepare a configuration file for use with the fo_config script. 

3. Configure ObjectServer communications for failover. ObjectServer failover is 

optional. 

4. Configure the TBSM servers for Data server failover. 

5. Start all servers. 

6. Verify the failover configuration. 

Failover and out of memory issues 

You can configure failover to respond to out of memory issues. 

In rare situations, the TBSM data server memory heap size grows too large and an 

OutOfMemory error occurs. Following an OutOfMemory, error it is possible that the 

TBSM data server continues to run, but in a compromised state and not fully 

functional. In a failover environment, if the primary gets an OutOfMemory error, you 

need the backup server to take over if the primary server has memory issues. If 

this situation is a concern in your environment, handle it by configuring the JVM 

to run a script that kills the data server in the event of an memory error. As a 

result, if OutOfMemory occurs on the primary, it will shut itself down, and let the 

backup server take over. 

Configure Java for out of memory: 


To invoke a script to kill the TBSM data server when an OutOfMemory error occurs 

in the Data server. 


This script can be located anywhere on the filesystem. In the example below it is in 

/opt/IBM/tivoli/tbsm/shutdown.sh. The steps below outline the procedure to 

configure websphere to execute the script upon getting an OutOfMemory error. 

Procedure 

1. Backup the server.xml file found under the following directory (on both 

TBSM Data servers). 

$TBSM_INSTALL_HOME/tipv2/profiles/TBSMProfile/config/cells/ 

TBSMCell/nodes/TBSMNode/servers/server1/server.xml 

2. Start the wsadmin tool: 

$TBSM_INSTALL_HOME/tipv2/profiles/TBSMProfile/bin/wsadmin.sh -lang jython 

-conntype SOAP 

-username tipadmin -password password 

Wait until you get the wsadmin prompt before starting the next step. 

3. (Optional)To display the location of the file that contains the startup 

parameters, enter: 

AdminConfig.list("JavaVirtualMachine") 

Record the location of the file for reference. 

The system response is similar to: 

(cells/TBSMCell/nodes/TBSMNode/servers/server1|server.xml 

#JavaVirtualMachine_1287491811427) 


jvm=AdminConfig.list("JavaVirtualMachine") 

The system only displays wsadmin prompt. 


AdminConfig.showAttribute(jvm, "genericJvmArguments") 

The system only displays wsadmin prompt. 

If the response is some string of text, then you need copy the text and insert it 

as the first argument in the next command: 


IBM JVM 

AdminConfig.modify(jvm,’[[ genericJvmArguments "text_output _from_last_command" 

-Xdump:tool:events=throw,filter= 

*OutOfMemoryError,exec=/opt/IBM/tivoli/tbsm/shutdown.sh"]]’) 

Oracle JVM 

AdminConfig.modify(jvm,’[[ genericJvmArguments "text_output _from_last_command" 

-Xdump:tool:events=throw,filter= 

-XX:OnOutOfMemoryError=/opt/IBM/tivoli/tbsm/shutdown.sh"]]’) 

Note: Make sure the directory where make sure shutdown.sh is created and 

the path exists before restarting TBSM. (In the above example the shutdown.sh 

script is in /opt/IBM/tivoli/tbsm). 

7. To confirm the changes were made, enter the command: 

AdminConfig.showAttribute(jvm, "genericJvmArguments") 

IBM JVM: The system response should be similar to: 

-Xdump:tool:events=throw,filter=*OutOfMemoryError,exec= 

/opt/IBM/tivoli/tbsm/shutdown.sh 


Oracle JVM: The system response should be similar to: 

-Xdump:tool:events=throw,filter=-XX:OnOutOfMemoryError= 

/opt/IBM/tivoli/tbsm/shutdown.sh 

8. To save the changes, enter the command: 

AdminConfig.save() 

9. To close the wsadmin tool, enter the command: exit. 

10. (Optional). Backup the newly updated server.xml file 

meaningful name to indicate it has the new settings. 

The file is located in: 

Giving it a 

$TBSM_INSTALL_HOME/tipv2/profiles/TBSMProfile/config/cells/TBSMCell/nodes/ 

TBSMNode/servers/server1/server.xml 

11. Create the shutdown script. 

The example script below is named shutdown.sh uses the pid 

stored in the server1.pid file to kill the data server java process. 

#!/bin/sh 

cat $TBSM_INSTALL_HOME/tipv2/profiles/TBSMProfile/logs/server1/server1.pid 

| xargs -i kill -9 {} 

On Windows: the script could be named shutdown.bat and 

could be a single line: 

net stop "Tivoli Business Service Manager - TBSMProfile_Port_17310" 

If you used a data server http port other than the default 17310, substitute that 

port in the data server service name in the script 

12. Run the same procedure on the Backup data server to handle the case where 

the backup is running as primary. 

13. Restart all the Data servers. 

Preparing a configuration file for failover 

To configure the Data servers for failover, you must create a configuration file that 

contains information specific to your environment. 


You can use the fo_config script that is provided to generate a template that you 

can then edit to create the final configuration file. This file makes the configuration 

changes to the Data and Dashboard servers that enable Data server failover. 


If you are planning to also configure Dashboard server load balancing, then you 

must perform this procedure and the procedure described in Configuring: Post 

installation: Load Balancing. 

To prepare a failover configuration file, perform the following steps: 

Procedure 

1. Generate a template for a failover configuration script by issuing the following 

command from any TBSM Data or Dashboard server: $TBSM_HOME/bin/ 

fo_config template This script generates a file named $TBSM_HOME/bin/ 

fo_config.YYYYMMDDHHMMSS.props, where YYYYMMDDHHMMSS is a time 

stamp. You can rename this file to a more convenient name. 


2. Using a text editor, open the file and modify it as needed to suite your 

environment: 

a. Set the value of the DATA_PrimaryDataServerHostname parameter to the host 

name of the primary Data server. 

b. Set the value of the DATA_PrimaryObjectServerHostname parameter to the 

host name of the primary ObjectServer. 

c. Set the value of the DATA_BackupDataServerHostname parameter to the host 

name of the backup Data server. 

d. (Optional) Set the value of the DATA_BackupObjectServerHostname parameter 

to the host name of the backup ObjectServer. 

e. Set the value of the DASH_PrimaryDataServerHostname parameter to the host 

name of the primary Data server. 

f. Set the value of the DASH_BackupDataServerHostname parameter to the host 

name of the backup Data server. 

g. Set the value DATA_PrimaryDB2@Hostname parameter to the host name of the 

Primary DB2 server. 

You can find the host name in TBSM_HOME/etc/TBSM_TBSMDatabase.ds file on 

the primary data server. 

h. (Optional) Set the value of the DATA_BackupDB2@Hostname parameter to the 

host name of the back up DB2 server. 

After the fo_config properties file has all the appropriate values, copy this 

file to all the Data servers and Dashboard servers that are part of the failover 


If you used the default values during installation, these are the only parameters 

that you need to modify. If you did not use the default values during 

installation, then you must modify the other parameters. 

fo_config.props file 

You create the fo_config.props file using the fo_config script. If you used the 

default values when you installed TBSM, you do not have to modify most of the 

parameters in this file. 

Parameters in the fo_config.props file 

The following table lists the parameters that are set in the fo_config.props file. 

Parameter Default value Description 

DATA_PrimaryDataServerHostname None Host name of the primary Data server 

DATA_PrimaryDataServerHTTPPort 17310 HTTP port of the primary Data server. 

DATA_PrimaryDB2Hostname None 

If you changed the default value during installation, use 

the value of WC_defaulthost in $TBSM_HOME/etc/ 

TBSM_server.props. 

This is the hostname of the primary DB2 server (or 

hostname of lone DB2 server if DB2 is not in failover). 

This value can be found in TBSM_TBSMDatabase.ds in the 

installdirectory/tbsm/etc/ directory. Find the the 

property: 

TBSMDatabase.DB2.PRIMARYHOST 



DATA_PrimaryDB2Port 50000 DB2 Port of primary database. 

This value can be found in TBSM_TBSMDatabase.ds in the 

installdirectory/tbsm/etc/ directory. Find the the 

property: 

ConfigureNameServer true 

TBSMDatabase.DB2.PRIMARYPORT 

By default the fo_config script will configure the 

nameserver configuration with the host/port of the 

primary server and backup server (if failover is 

configured). 

If you have already customized the nameserver 

configuration to include an additional Impact cluster 

ASWELL as the TBSM failover pair, you should set this 

property to false. Otherwise, fo_config overwrites your 

customizations. 

DATA_PrimaryConfigureFailback false 

Additionally, you can run the 

nci_configuration_utility script to reconfigure the 

nameservers after you run fo_config. 

Failback is the behavior whereby when the default 

backup server is running as primary and the default 

primary comes back up, the default primary takes over 

as the primary TBSM server and the default backup 

transitions into the backup role. To enable this behavior 

set the following property to true. Otherwise, the default 

primary will assume the backup role if it starts up when 

the default backup server is running as primary. 

DATA_BackupMillisecondsTill 

StartAsStandalone 

300000 If there is a backup server and it is started before the 

primary server is started, by default it will wait 300 

seconds until assuming the role as the primary. This 

duration can be configured with this property. 

DATA_PrimaryObjectServerHostname None Host name of the primary ObjectServer. 

DATA_PrimaryObjectServerPort 4100 Port of the primary ObjectServer. 

DATA_PrimaryObjectServerName NCOMS 


the value of ObjectServer_DS.ObjectServer.PRIMARYPORT 

in $TBSM_HOME/etc/TBSM_ObjectServer_DS.ds. 

Name of the primary ObjectServer. 

DATA_BackupDataServerHostname None Host name of the backup Data server. 

DATA_BackupDataServerHTTPPort 17310 

This parameter is optional. If this parameter is not 

specified, the system is configured as a standalone Data 

server, whether it was previously configured as part of a 

failover pair. 

HTTP port of the backup Data server. 



the value of WC_defaulthost in $TIP_HOME/profiles/ 

TBSMProfile/properties/portdef.props on the backup 

Data server.


DATA_BackupDB2Hostname none Only configure this if DB2 is in replication (HADR is 

configured for DB2). 

Note: When failover is configured for TBSM data 

DATA_BackupDB2Port 50000 

servers, it does not mean DB2 must also be in failover. 

Also, it is possible to have DB2 failover setup without 

TBSM failover. In this case, TBSM can be configured for 

DB2 replication by using fo_config template and not 

setting a backup data server host, but setting a backup 

DB2 host. 

DB2 port of backup DB2 server. This is optional. Only 

configure this property if DB2 is in failover (HADR). 

DATA_BackupObjectServerHostname None Host name of the backup ObjectServer. 

DATA_BackupObjectServerPort 4100 

This parameter is optional. If this parameter is the not 

specified, the Data server is configured to communicate 

with a standalone ObjectServer. 

Port of the backup ObjectServer. 

DATA_BackupObjectServerName NCOMS_BKUP 

This value is typically the same value as the value of 

DATA_PrimaryObjectServerPort. 

Name of the backup ObjectServer. 

UseObjectServerFailback false 

This value must be different from the value of 

DATA_PrimaryObjectServerName. 

If the ObjectServer is configured for failback then set this 

property to true. This enables TBSM (embedded Impact) 

to connect to the primary ObjectServer if the primary 

ObjectServer comes back up, instead of continuing to use 

the backup ObjectServer. 

DATA_Bi-DirectionalGatewayName NCO_GATE Name of the bi-directional gateway 

DATA_Bi-DirectionalGatewayPort 4300 Port of the bi-directional gateway 

DASH_PrimaryDataServerHostname None Host name of the primary Data server. 

DASH_PrimaryDataServerRMIPort 17542 RMI port of the primary Data server. 

DASH_PrimaryDataServerHTTPPort 17310 HTTP port of the primary Data server. 

DASH_BackupDataServerHostname None 

This value must be the same as the value of 

DATA_PrimaryDataServerHTTPPort. 

Host name of the backup Data server. 

DASH_BackupDataServerRMIPort 17542 

This parameter is optional. If this parameter is not 

specified, the Dashboard server is configured to 

communicate with a standalone Data server. 

RMI port of the backup Data server. 

DASH_BackupDataServerHTTPPort 17310 HTTP port of the backup Data server. 

Example of the fo_config.props file 

This value must be the same as the value for 

DATA_BackupDataServerHTTPPort. 

#============================================================================ 

# TBSM 6.1 Failover Configuration Properties file 

# Template generated at 20110610074608 

#============================================================================ 


# Invoke the script with template target to generate a configuration template 

# in the local directory: 

# 

# Unix: $TBSM_HOME/bin/fo_config template 

# Windows: %TBSM_HOME%\bin\fo_config template 

# 

# Invoke the script with dashboardserver target and specifying 

# the configuration file to configure Dashboard Server: 

# 

# Unix: $TBSM_HOME/bin/fo_config dashboardserver 

-Dfo_config.props=[config-file-path] 

# Windows: %TBSM_HOME%\bin\fo_config dashboardserver 


# 

# Invoke the script with dataserver target and specifying 

# the configuration file to configure Data Server: 

# 

# Unix: $TBSM_HOME/bin/fo_config dataserver 


# Windows: %TBSM_HOME%\bin\fo_config dataserver 


# 

#------------------------------------------------------------------------ 

# Parameters used in Data Server configuration 

#------------------------------------------------------------------------ 

# Primary Data Server Hostname 

# This is a required field. Script will not run if leave blank. 

# It is set in the following locations: 

# 1. The key REPLICANT.0.HOST in the 

# $TIP_HOME/profiles/TBSMProfile/config/cells/TBSMCell/applications/ 

nameserver.ear/deployments/nameserver/nameserver.war/WEB-INF/web.xml 

# file on both the primary and the backup data server. 

# 2. The keys impact.nameserver.0.host in the 

# $TBSM_HOME/etc/nameserver.props 


# 

DATA_PrimaryDataServerHostname=tbsmprimary.mycompany.com 

#---------------------------------------------------- 

# Primary Data Server HTTP Port 

# The default value is 17310. 

# Current value can be found in the following locations: 

# 1. The key REPLICANT.0.PORT in the 




# 2. The key impact.registry.0.port in the 

# $TIP_HOME/etc/nameserver.props 


# 

DATA_PrimaryDataServerHTTPPort=17310 

#---------------------------------------------------- 

# Primary DB2 Host 


# 1. The key TBSMDatabase.DB2.PRIMARYHOST in the 

# $TBSM_HOME/etc/TBSM_TBSMDatabase.DB2.ds 

# file on the primary data server. 

# 2. The key TBSMDatabase.DB2.PRIMARYHOST in the 

# $TBSM_HOME/etc/TBSM_B_TBSMDatabase.DB2.ds 

# file on the backup data server. 

# 

DATA_PrimaryDB2Hostname=db2primary.mycompany.com 

#---------------------------------------------------- 


# Primary DB2 Port 



# 1. The key TBSMDatabase.DB2.PRIMARYPORT in the 

# $TIP_HOME/etc/TBSM_TBSMDatabase.DB2.ds 


# 2. The key TBSMDatabase.DB2.PRIMARYPORT in the 



# 

DATA_PrimaryDB2Port=50000 

#---------------------------------------------------- 

# Primary ObjectServer Hostname 

# This is a required field. Script will not run if leave blank. 


# The key ObjectServer_DS.ObjectServer.PRIMARYHOST in the 

# $TBSM_HOME/etc/TBSM_ObjectServer_DS.ds 


# 

DATA_PrimaryObjectServerHostname=tbsmprimary.mycompany.com 

#---------------------------------------------------- 

# Primary ObjectServer Port 


# Current value can be found in the key 

ObjectServer_DS.ObjectServer.PRIMARYPORT in the 


# 

DATA_PrimaryObjectServerPort=4100 

#---------------------------------------------------- 

# Primary ObjectServer Name 

# The default value is NCOMS. 


# 1. The OMNIbus server interface file 

# 2. The key Gate.ObjectServerA.Server in the 

# $OMNIHOME/gates/NCO_GATE/NCO_GATE.props 

# file on the backup ObjectServer (which will exist after 

# the gateway is configured) 

# 

DATA_PrimaryObjectServerName=NCOMS 

#---------------------------------------------------- 

# By default the fo_config script will configure the nameserver 

# configuration with the host/port of the primary server 

# and backup server (if failover is configured). 

# If you have already customized the nameserver configuration to include 

# an additional Impact cluster ASWELL as the TBSM failover pair 

# you should set the following property to false 

# so that fo_config will not overwrite your customizations. 

# Additionally, you can run the nci_configuration_utility script 

# to reconfigure the nameservers after you run fo_config. 

ConfigureNameServer=true 

# Failback is the behavior whereby when the default backup server is running 

# as primary and the default primary comes back up, the default 

# primary takes over as the primary TBSM server and the default 

# backup transitions into the backup role. To enable this behavior 

# set the following property to true. Otherwise, when the default primary 

# will assume the backup role if it starts up when the default backup 

# server is running as primary. 

DATA_PrimaryConfigureFailback=false 


# If there is a backup server and it is started before the primary 

# server is started, by default it will wait 300 seconds until assuming 

# the role as the primary. This duration can be configured with 

# the following property. 

DATA_BackupMillisecondsTillStartAsStandalone=300000 

# Backup Data Server Hostname 

# This is an optional field. Server will be configured as a standalone 

if leave blank. 


# 1. The key REPLICANT.1.HOST in the 

# $TBSM_HOME/profiles/TBSMProfile/config/cells/TBSMCell/applications/ 



# 2. The key impact.registry.1.host in the 



# 

DATA_BackupDataServerHostname=tbsmbackup.mycompany.com 

#---------------------------------------------------- 

# Backup Data Server HTTP Port 







# 2. The key impact.registry.1.port in the 



# 

DATA_BackupDataServerHTTPPort=17310 

#---------------------------------------------------- 

# Backup DB2 Host 

# Configure this property if you have DB2 replication. 


# 1. The key TBSMDatabase.DB2.BACKUPHOST in the 

# $TBSM_HOME/etc/TBSM_TBSMDatabase.DB2.ds 


# 2. The key TBSMDatabase.DB2.BACKUPHOST in the 



# 

DATA_BackupDB2Hostname=db2backup.mycompany.com 

#---------------------------------------------------- 

# Backup DB2 Port 

# Configure this property if you have DB2 replication. 



# 1. The key TBSMDatabase.DB2.BACKUPPORT in the 

# $TIP_HOME/etc/TBSM_TBSMDatabase.DB2.ds 


# 2. The key TBSMDatabase.DB2.BACKUPPORT in the 



# 

DATA_BackupDB2Port=50000 

#---------------------------------------------------- 

# Backup ObjectServer Hostname 

# This is an optional field. 

# Server will be configured as a standalone ObjectServer 


if leave blank. 

# Current value can be found in the following locations, 

if defined: 


# 2. The key Gate.ObjectServerB.Server in the 


# file on the backup ObjectServer. 

# 

DATA_BackupObjectServerHostname=tbsmbackup.mycompany.com 

#---------------------------------------------------- 

# Backup ObjectServer Port 



ObjectServer_DS.ObjectServer.BACKUPPORT in the 


# file on both the primary and the backup data server 

(TBSM_B_ObjectServer_DS.ds). 

# 

DATA_BackupObjectServerPort=4100 

#---------------------------------------------------- 

# Backup ObjectServer Name 

# Optional filed. The default value is NCOMS_BKUP. 



# 2. The key Gate.ObjectServerA.Server in the 



# 

DATA_BackupObjectServerName=NCOMS_BKUP 

#---------------------------------------------------- 

# If ObjectServer is configured for failback then 

# set the following property to true. 

UseObjectServerFailback=false 

# Bi-directional Gateway Name 

# Optional filed. The default value is NCO_GATE. 



# 2. The generated Gateway directory and file names. 

# 3. The key name in the $OMNIHOME/gates/NCO_GATE/NCO_GATE.props 


# 

DATA_Bi-DirectionalGatewayName=NCO_GATE 

#---------------------------------------------------- 

# Bi-directional Gateway Port 

# Optional filed. The default value is 4300. 

# Current value can be found in the OMNIbus server interface file 

# 

DATA_Bi-DirectionalGatewayPort=4300 

#---------------------------------------------------- 

#-------------------------------------------------------------- 

# Parameters used in Dashboard Server failover configuration 

# The value of these parameters should match those in the Data 

Server configuration 

#-------------------------------------------------------------- 

# Primary Data Server Hostname 

# This is a required field. Script will not run on dashboard 

server if leave blank. 


# 1. The key impact.rmiupdateserver.hostname in the 

# $TIP_HOME/profiles/TIPProfile/installedApps/TIPCell/isc.ear/ 

sla.war/etc/RAD_server.props 


# file on the dashboard server. 

# 2. The key impact.sla.serverhost in the 


sla.war/etc/RAD_sla.props 


# 

DASH_PrimaryDataServerHostname=tbsmprimary.mycompany.com 

#---------------------------------------------------- 

# Primary Data Server RMI Port 



impact.rmiupdateserver.port in the 




# 

DASH_PrimaryDataServerRMIPort=17542 

#---------------------------------------------------- 



# Current value can be found in the key impact.sla.serverhttpport 

in the 




# 

DASH_PrimaryDataServerHTTPPort=17310 

#---------------------------------------------------- 

# Backup Data Server Hostname 

# This is an optional field. Data server will be configured as 

a standalone if leave blank. 

# It is set in key impact.rmiupdateserver.hostname.backup in the 




# 

DASH_BackupDataServerHostname=tbsmbackup.mycompany.com 

#---------------------------------------------------- 

# Backup Data Server RMI Port 



impact.rmiupdateserver.port.backup in the 

# $TIP_HOME/profiles/TIPProfile/installedApps/TIPCell/ 

isc.ear/sla.war/etc/RAD_server.props 


# 

DASH_BackupDataServerRMIPort=17542 

#---------------------------------------------------- 




impact.sla.serverhttpport.backup in the 


isc.ear/sla.war/etc/RAD_sla.props 


# 

DASH_BackupDataServerHTTPPort=17310 

#---------------------------------------------------- 

#-------------------------------------------------------------- 

# The following parameters are not used at this release 

#-------------------------------------------------------------- 


# Primary ObjectServer Hostname - Reserved, Not used 

DASH_PrimaryObjectServerHostname= 

# Primary ObjectServer Port - Reserved, Not used 

DASH_PrimaryObjectServerPort=4100 

# Primary ObjectServer Name - Reserved, Not used 

DASH_PrimaryObjectServerName=NCOMS 

# Backup ObjectServer Hostname - Reserved, Not used 

DASH_BackupObjectServerHostname= 

# Backup ObjectServer Port - Reserved, Not used 

DASH_BackupObjectServerPort=4100 

# Backup ObjectServer Name - Reserved, Not used 

DASH_BackupObjectServerName=NCOMS_BKUP 

# Bi-directional Gateway Name - Reserved, Not used 

DASH_Bi-DirectionalGatewayName=NCO_GATE 

# Bi-directional Gateway Port - Reserved, Not used 

DASH_Bi-DirectionalGatewayPort=4300 

Configuring the ObjectServer communication information for 

failover 

If you are using a primary and a backup Netcool/OMNIBus ObjectServer, you 

must configure communication information for both the primary and backup 

ObjectServer to participate in failover. 


Check that your ObjectServer host has this subdirectory: 

$OMNIHOME/var 

If this directory is missing, create it. 

Replicating OMNIBus authentication data 

If you use the Netcool/OMNIbus ObjectServer for authentication and the 

ObjectServer is set up for failover, you need replicate the security information in 

the ObjectServer. 

To replicate the security, you need to uncomment some properties in these 

bidirectional gateway files located the directory: 

$NCHOME/omnibus/gates/objserv_bi/ 

objserv_bi.map 

Find this note about 130 lines down in the file. 

########################################################################### 

# NOTE: If replication of the user related system tables is required, 

# uncomment 

# the table mapping definitions below. The associated table replication 

# definitions will also need to be uncommented. 

############################################################################ 

Uncomment all the properties and between this note and the next note in 

the file. 


objserv_bi.objectservera.tblref.def 

Find this note about 30 lines down in the file: 

########################################################################## 


# uncomment 

# the replication definitions below. The associated maps will also need 

# to be uncommented. 

########################################################################## 


the file. 

objserv_bi.objectservb.tblref.def. 

Find this note about 30 lines down in the file: 

######################################################################## 


# uncomment 

# the replication definitions below. The associated maps will also need 

# to be uncommented. 

########################################################################## 


the file. 

Setting the FAILOVERPOLICY parameter 

If you want to configure IBM Tivoli Netcool/OMNIbus for failback with TBSM, 

you must ensure that the FAILOVERPOLICY parameter is configured correctly. 


To configure this parameter: 

Procedure 

1. Run the fo_config script located: 

Windows 

%TBSM_HOME%\bin\fo_config 

UNIX 

$TBSM_HOME/bin/fo_config 

2. Using a text editor, open the $TBSM_HOME/etc/TBSM_ObjectServer_DS.ds file. 

3. Locate the ObjectServer_DS.ObjectServer.FAILOVERPOLICY property and change 

it to FAILBACK. This change ensures that the Data server switches to the backup 

IBM Tivoli Netcool/OMNIbus server if the primary IBM Tivoli 

Netcool/OMNIbus server fails. If the Primary IBM Tivoli Netcool/OMNIbus 

server comes back up it takes over. 

Configuring ObjectServer communication information for UNIX 

systems 

To configure the ObjectServer communication information, you must configure 

both the primary and backup ObjectServers. 


Configuring the ObjectServer communications for the primary server on UNIX 

systems: 



Before you begin, you must have installed both the primary and backup 

ObjectServer. 


This procedure uses the default values for the primary ObjectServer (NCOMS), the 

backup ObjectServer (NCOMS_BKUP) and the bidirectional gateway (NCO_GATE). 

You can change these names; however, you must also change the values of the 

corresponding properties in your fo_config.props file before you run the 

fo_config script to configure failover. The properties that you must change in the 

file are as follows: 

DATA_PrimaryObjectServerName 

DATA_BackupObjectServerName 

DATA_Bi-DirectionalGatewayName 

Procedure 

1. Issue the following command: installed_directory/netcool/omnibus/bin/ 

nco_xigen. 

2. Remove all entries for NCOMS and NCO_GATE in the server list. Other entries in the 

server list, such as NCO_PA and NCO_PROXY, which are put into the table during 

installation, are not necessary for TBSM failover, but they might be used by 

other functions or products that use the ObjectServer. 

Important: This step removes the ObjectServer password that was specified 

during the installation of TBSM. When you complete the ObjectServer 

communication setup, you need to reset the ObjectServer password. For 

instructions on changing the password, see the TBSM Administration Guide 

Configuring TBSM > Changing the TBSM configuration > Changing the 

Netcool/OMNIbus ObjectServer password or user ID. 

3. Specify information about the primary ObjectServer: 

a. In the Name field, type NCOMS. 

b. In the Host field, type the host name or IP address of the primary 

ObjectServer. 

c. In the Port field, type 4100. 

d. Click Add. 

4. Specify the backup server is the backup to the primary ObjectServer: 


b. In the Host field, type the host name or IP address of the backup 

ObjectServer. 


d. Click Add. 

5. Add the backup ObjectServer: 

a. In the Name field, type NCOMS_BKUP. 


ObjectServer. 


d. Click Add. 

6. Specify the gateway information: 


a. In the Name field, type NCO_GATE. 


ObjectServer. 


d. Click Add. 

7. Verify that the server name, host name, and port numbers are correctly 

displayed in the Netcool/OMNIbus Server Editor window. At this time, the 

Test push button does not function. You can use Test to verify that servers are 

running after the configuration is complete and the servers are started. 

8. Click Apply and then click Close. 

Results 

The install_directory/netcool/etc/interfaces, file and the install_directory/ 

netcool/etc/omni.dat file are updated. On Linux systems the interfaces files is 

named: interfaces.linux2x86. See OMNIbus communications files for UNIX in the 

Reference section of the TBSM Administrator's Guide for an example of these files. 

Configuring the ObjectServer communications for the backup server on UNIX 

systems: 



ObjectServer and configured the primary ObjectServer for failover. 



backup ObjectServer (NCOMS_BKUP) and the bi-directional gateway (NCO_GATE). You 

can change these names; however, you must also change the values of the 







Procedure 

1. Issue install_directory/netcool/omnibus/bin/nco_xigen. 





Important: This step removes the ObjectServer password that was specified 

during the installation of TBSM. When you complete the ObjectServer 

communication setup, you need to reset the ObjectServer password. For 

instructions on changing the password, see the TBSM Administration Guide 

Configuring TBSM > Changing the TBSM configuration > Changing the 

Netcool/OMNIbus ObjectServer password or user ID. 




. In the Host field, type the host name or IP address of the primary 

ObjectServer. 


d. Click Add. 


a. In the Name field, type NCOMS_BKUP. 


ObjectServer. 


d. Click Add. 

5. Specify the bi-directional gateway information: 

a. In the Name field, type NCO_GATE. 


ObjectServer. 


d. Click Add. 

6. Verify that the server name, host name, and port numbers are correctly 

displayed in the Netcool/OMNIbus Server Editor window. At this time, the 

Test push button does not function. You can use Test to verify that servers are 

running after the configuration is complete and the servers are started. 

7. Click Apply and then click Close. 

Configuring ObjectServer communication information for 

Windows systems 

To configure the ObjectServer communication information, you must configure 

both the primary and backup ObjectServers. 


Configuring the ObjectServer communications for the primary server on 

Windows systems: 



ObjectServer. 











Procedure 

1. From the desktop, click Start > Programs > Netcool Suite > System Utilities > 

Server Editor. 







a. Clear the Listener check box. 

b. In the Name field, type NCOMS. 

c. In the Host field, type the host name or IP address of the primary 

ObjectServer. 

d. In the Port field, type 4100. 

e. Click Add. 

4. Add a Listener service for the same host and port as the primary ObjectServer: 

a. Select the Listener check box. 



ObjectServer. 


e. Click Add. 

5. Specify that the backup server is the backup to the primary ObjectServer: 

a. Select the primary server (NCOMS) in the list. 

b. Clear the Listener check box. 

c. In the Host field, type the host name or IP address of the backup 

ObjectServer. 

d. Change the Host value to the host name of the backup ObjectServer. Do not 

change the values in the Name or Port fields. 

e. Click Add. 



b. In the Name field, type NCOMS_BKUP. 


ObjectServer. 


e. Click Add. 



b. In the Name field, type NCO_GATE. 


ObjectServer. 


e. Click Add. 

8. Verify that the server name, host name, and port numbers are correct. At this 

time, the Test push button does not function. You can use Test to verify that 

servers are running after the configuration is complete and the servers are 

started. 

9. Click OK. 


Results 

The install_directory\netcool\ini\sql.ini file is updated. See OMNIbus 

communications files for UNIX in the Reference section of the TBSM Administrator's 

Guide for an example of these files. 

Configuring the ObjectServer communications for the backup server on 

Windows systems: 



ObjectServer and configured the primary ObjectServer for failover. 











Procedure 

1. From the desktop, click Start > Programs > Netcool Suite > System Utilities > 

Server Editor. 









ObjectServer. 


e. Click Add. 





ObjectServer. 


e. Click Add. 

5. Add a Listener service for the same host and port as the backup ObjectServer: 




ObjectServer. 



e. Click Add. 





ObjectServer. 


e. Click Add. 

7. Add a Listener service for the gateway: 




ObjectServer. 


e. Click Add. 

8. Verify that the server name, host name, and port numbers are correct. At this 

time, the Test push button does not function. You can use Test to verify that 

servers are running after the configuration is complete and the servers are 

started. 

9. Click OK. 

Results 

The install_directory\netcool\ini\sql.ini file is updated. See OMNIbus 

communications files in the Reference section of the TBSM Administrator's Guide for 

an example of this file. 

Additional configuration for Windows systems in a failover environment: 

On Windows systems, you must modify several service settings on the backup 

ObjectServer and create a Windows service to manage the OMNIbus gateway 

process. 

Procedure 

1. Modify the ObjectServer service to start the NCOMS_BKUP server by default. 

a. Issue the command installdirectory\netcool\omnibus\bin\nco_objserv/ 

REMOVE. 

b. Issue the command installdirectory\netcool\omnibus\bin\nco_objserv 

/INSTALL /CMDLINE "-name NCOMS_BKUP". 

Note: If you want to remove this service later, issue the same command 

with the /REMOVE option. 

2. Create a Windows service to manage the OMNIbus gateway process by issuing 


installdirectory\netcool\omnibus\bin\nco_g_objserv_bi /INSTALL /DEPEND NCOObjec 

tServer /CMDLINE "-name NCO_GATE" 

The service Netcool/OMNIbus Bi-Directional ObjectServer Gateway 

(NCOObjectServerGatewayBi) is created. This service depends on the 

ObjectServer service. 


Note: If you want to remove this service later, issue the same command with 

the /REMOVE option. 

Configuring Data servers for failover 

You must run the fo_config script on all hosts that have TBSM Data or Dashboard 

servers participating in the failover configuration. This script makes the necessary 

configuration changes to the Netcool/OMNIbus and to the Data and Dashboard 

servers. 

If you used the TBSM installation program to install OMNIbus, but you are 

hosting the backup ObjectServer on the same computer as one of the Data servers, 

you can still use the fo_config script to make necessary changes to the backup 

ObjectServer. In this case, you must set the environment variable OMNIHOME to 

the OMNIbus installation directory before running fo_config. 

If your configuration hosts the backup ObjectServer on a separate computer from 

the Data servers, you cannot use fo_config to configure the ObjectServer; you 

must perform a manual configuration. See “Manually configuring the ObjectServer 

for failover” on page 207 for information about how to manually configure the 

ObjectServer. 

In any scenario in which you do not use the TBSM installation program to install 

the primary ObjectServer, you need to configure it before you can use TBSM. See 

the information about Netcool OMNIbus considerations in TBSM Installation Guide. 

Configuring backup data server for a migrated system 

When setting up a backup data server in a failover pair, where the primary server 

was migrated from TBSM 4.2.x, the delta properties files created during the 

migration contain useful information. 

The migrated data server has files named TBSM_nnnn_migration_override.props 

and TBSM_nnnn_migration_add.props, where nnnn is the name of a properties file 

that is merged during migration. For example, 

TBSM_sla_migration_override.props. When setting up a backup data server in a 

failover pair, you may want to inspect these delta files and append the content to 

the corresponding properties files on the backup server. 

In addition, several properties files are copied in their entirety during migration. 

So when configuring failover, the following properties files may have updates 

made on the original 4.2.x data server that need to be added to the backup data 

server. Since the files are copied during migration, it may be appropriate to just 

copy the files to the backup data server. These properties files are: 

v TBSM_policylogger.props 

v TBSM_agentservice.props 

v TBSM_markerserver.props 

v TBSM_privs.props 

v TBSM_tbsm_marker_user.props 

v TBSM_tbsm_metric_history_user.props 

Running the fo_config script 

Run the fo_config script on all hosts that have Data or Dashboard servers 

participating in the failover configuration. The fo_config script performs basic 


consistency checking for host names (for example, it checks that primary and 

secondary backup names are different), but it does not perform any other 

validation processes. 



v If you installed OMNIbus separately, but you are hosting the backup 

ObjectServer on the same computer as one of the Data servers, you must set the 

environment variable OMNIHOME to the OMNIbus installation directory before 

running fo_config. 

v The primary and backup TBSM installation must use the same authentication 

method, either LDAP or OMNIbus; file-based authentication is not supported for 

failover configurations. 

v You must have prepared the fo_config script. 

v You must have configured the ObjectServer communications for failover. 

v If you did not use the TBSM installation program to install the primary 

ObjectServer, you need to configure this ObjectServer before you can use it. See 

the TBSM Installation Guide for information. 

v Stop all servers. 


To run the fo_config script, perform the following steps: 

Procedure 

1. Copy the configuration properties file that you created to all computers that are 

hosting a Data or Dashboard server. Use the same file and directory on all 

computers. 

2. On all computers that are hosting a Data server, run the fo_config script as 

follows: 

Change to the $TBSM_HOME/bin directory and run the following 

command: 

. ./fo_config dataserver -Dfo_config.props=full_path_of_config_file 

Change to the %TBSM_HOME%\bin directory and run the following 

command: 

./fo_config.bat dataserver -Dfo_config.props=full_path_of_config_file 

Note: If the backup OMNIbus is installed on the same computer as the backup 

Data server, the fo_config command starts the backup ObjectServer 

NCOMS_BKUP. This needs to be shut down and restarted after the failover 

configuration completes. 

3. On all computers that are hosting a Dashboard server, run the fo_config script 

as follows: 

Change to the $TBSM_HOME/bin directory and run the following 

command: 

. ./fo_config dashboardserver -Dfo_config.props=full_path_of_config_file 

Change to the %TBSM_HOME%\bin directory and run the following 

command: 

./fo_config.bat dashboardserver -Dfo_config.props=full_path_of_config_f 

ile 


Note: If the backup OMNIbus is installed on the same computer as the backup 

Data server, the fo_config command starts the backup ObjectServer 

NCOMS_BKUP. This needs to be shut down and restarted after the failover 

configuration is completed. 

Results 

The script should complete with a BUILD SUCCESSFUL message in all cases. 

Manually configuring the ObjectServer for failover 

If the backup ObjectServer is on a separate computer, you cannot use the 

fo_config script; you must perform a manual configuration. 











Attention: If you plan to use an existing Netcool OMNIbus ObjectServer instead 

of the one included in your TBSM installation, see “IBM Tivoli Netcool OMNIbus 

Considerations” on page 24 for information about using an existing ObjectServer. 

To manually configure the ObjectServer for failover, perform the following steps: 

Procedure 

1. Configure the backup ObjectServer: 

a. Stop the existing ObjectServer, if it is running. 

b. Issue the following command to create the backup ObjectServer and to 

name the backup ObjectServer NCOMS_BKUP: install_directory/ 

netcool/omnibus/bin/nco_dbinit -server NCOMS_BKUP The 

install_directory/netcool/omnibus/etc/NCOMS_BKUP.props file is created. 

c. Issue the following command to start the backup ObjectServer: 

install_directory/netcool/omnibus/bin/nco_objserv -name NCOMS_BKUP 

d. Issue the following commands to update the alerts.status table schema: 

cat install_directory/netcool/omnibus/etc/ 

tbsm_db_update.sql install_directory/netcool/omnibus/bin/nco_sql 

-server NCOMS_BKUP -user username -password password 

type install_directory\netcool\omnibus\etc\ 

tbsm_db_update.sql install_directory\netcool\omnibus\bin\isql.bat 

-server NCOMS_BKUP -user username -password password 

Note: The tbsm_db_update.sql file is only available in this location if 

Omnibus was installed using the TBSM Installer. If the Omnibus was 

installed without using the TBSM installer, this file is available in the DVD 

media in arch/TBSM/omnibus/schema_files. 


e. Update the value of BackupObjectServer from FALSE to TRUE in the 

install_directory/netcool/omnibus/etc/NCOMS_BKUP.props file. See 

NCOMS_BKUP.props file in the Reference section of the TBSM Administration 

Guide for an example of this file. 

2. Configure the bidirectional gateway for the backup ObjectServer: 

a. Create a subdirectory NCO_GATE in the install_directory/netcool/onmibus/ 

gates directory. 

b. Copy all the files in the install_directory/netcool/omnibus/gates/ 

objserv_bi directory to the install_directory/netcool/omnibus/gates/ 

NGO_GATE directory. 

c. Rename the install_directory/netcool/omnibus/gates/NCO_GATE/ 

objserv_bi.map file to install_directory/netcool/omnibus/gates/ 

NCO_GATE/NCO_GATE.map. 

d. Rename the install_directory/netcool/omnibus/gates/NCO_GATE/ 

objserv_bi.props file to install_directory/netcool/omnibus/gates/ 

NCO_GATE/NCO_GATE.props. 

e. Edit the install_directory/netcool/omnibus/gates/NCO_GATE/ 

NCO_GATE.props file to create required entries. See NCO_GATE.props file in 

the Reference section of the TBSM Administration Guide for an example of 

this file. On each line, adjust the values shown on the right side of the colon 

(:) to appropriate values for your installation. 

Important: Use the UNIX file and variable syntax in this file, even on 

Windows systems. 

f. Copy the install_directory/netcool/omnibus/gates/NCO_GATE/ 

NCO_GATE.props file to install_directory/netcool/omnibus/etc/ 

NCO_GATE.props. 

g. Edit the install_directory/netcool/omnibus/gates/NCO_GATE/NCO_GATE.map 

file on the backup ObjectServer host. See NCO_GATE.map file in the 

Reference section of the TBSM Administration Guide for an example of the 

entries to add for the default TBSM OMNIbus schema. 

Important: You must update this map whenever the alerts.status table 

schema changes. If you do not, the row in the alerts.status table is not 

synchronized. 

Replicating the alerts.service_deps table required for 

OMNIbus failover 

The fo_config script replicates the alerts.status table. However, you must 

complete this procedure to ensure that the alerts.service_deps table is also 

replicated. This is required to ensure that the Service Details portlet operates 

correctly. 


To complete this procedure, you must edit the NCO_GATE.map file. The NCO_GATE.map 

file is typically located in the installdirectory/netcool/omnibus/gates/NCO_GATE/ 

directory. For more information about this and other configuration files, see the 


Procedure 

1. Using a text editor, open the NCO_GATE.map file. Edit the file to add a section: 


CREATEMAPPING Service_deps Map 

( 

’EventKey’=’@EventKey’, 

’KeyField’=’@KeyField’, 

’Service’=’@Service’ 

); 

2. Save and close the file. 

3. You must ensure that the new mapping is referenced in the definition file for 

the gateway, for example: 

$OMNIHOME/gates/NCO_GATE/objserv_bi.objectservera.tblrep.def 

$OMNIHOME/gates/NCO_GATE/objserv_bi.objectserverb.tblrep.def 

Using a text editor open the file and add the reference: 

REPLICATE ALL FROM TABLE ’alerts.service_deps’ 

USING MAP ’Service_depsMap’; 


Starting the servers in a failover environment 

To start TBSM in a failover configuration, you need to start a primary server before 

you start the corresponding backup server. 


Start the following processes: 

v Primary ObjectServer 

v Backup ObjectServer 

v Backup OMNIbus gateway 

v Primary Data server 

v Backup Data server 

v One of more Dashboard servers 

You must start the processes in this order; a backup server stops if it cannot 

contact the primary server when it is initially started. Likewise, the OMNIbus 

gateway might stop if it cannot connect to the primary ObjectServer when it is 

initially started. 

Procedure 

1. To start all the TBSM processes at one time, issue the 

$TBSM_HOME/bin/tbsm_suite.sh start command. For more information about 

the tbsm_suite.sh script, see Starting and stopping TBSM components or services 

in the TBSM Administrator's Guide. 

2. To start individual TBSM services, issue one or more of the 

following commands: 

v To start the primary ObjectServer: net start NCOObjectServer 

v To start the backup ObjectServer: net start NCOObjectServer 

v To start the OMNIbus gateway (on the backup computer if a backup 

OMNIbus is configured): net start :NCOObjectServerGatewayBi" 

v To start the primary Data server: net start "IBMWAS70Service - 

TBSMProfile_Port_17310" 

v To start the backup Data server: net start "IBMWAS70Service - 

TBSMProfile_Port_17310" 


v To start one or more Dashboard servers: net start "IBMWAS70Service - 

V2.2_TIPProfile_Port_16310" 

Verifying that the servers failover successfully 

This section describes how to verify the entire TBSM failover environment, which 

includes the ObjectServer and the TBSM servers. 


The verification process tests the following items: 

v The TBSM failover and fail back 

v The ObjectServer synchronization through the ObjectServer bi-directional 

gateway 

If completed successfully, this procedure demonstrates that the TBSM server 

performs failover and fail back without losing data. It also demonstrates that the 

events sent to the backup ObjectServer are propagated to the primary ObjectServer 

through the synchronization process provided by the bi-directional gateway 

this example test event, the incoming status rule uses the Node field for the service 

name and the AlertKey and Severity field values to determine the service status. 

Procedure 

1. Open a Web browser and connect to the TBSM Dashboard server. You can log 

in and see the service and template in the Service Administration view. 

2. Send a test event to a service that is assigned to a template with event-based 

incoming status rules. For an example of creating a service, service templates, 

and incoming status rules, see the TBSM Scenarios Guide. 

3. Stop the primary Data server. The backup Data server assumes the active role 

and start providing service. Depending on the number of service instances, 

this might take a few minutes. 

After the failover process completes, the Dashboard server automatically 

connects to the backup Data server. The display might show a 

reconnecting... message; if this occurs, the display refreshes itself. The 

service is still displayed. 

4. Send test events to the service. Right-click the icon for auto_webserver2, and 

then select Show > Send Test Event. The message counter changes, based on 

the event that you sent. 

5. Restart the primary Data server by: 

Enter: 

$TIP_HOME/profiles/TBSMProfile/bin/startServer.sh server1 

Start the service: 

Tivoli Business Service Manager - TBSMProfile_Port_17310 

After this server starts, it must be in a backup role. 

6. Return to the Web browser session to ensure that the services are still 

displayed and that the system is responsive. 

7. Stop the backup Data server by issuing the command kill -9 $(cat 

$TIP_HOME/profiles/TBSMProfile/logs/server1/server1.pid). The primary 

Data server assumes the active role and start providing services. This might 

take a few minutes. 


8. Return to the Web browser session to ensure that the services are still 

displayed and that the system is responsive. 

9. To test the ObjectServer, issue the rad_sendevent command to send a message 

to the primary ObjectServer: 

a. Issue the following command: 

$TBSM_HOME/bin/rad_sendevent ObjectServerHost port userid password 

b. At the READY prompt, type the following field name and value pairs. 

Separate each item by pressing Enter: 

Identifier 

tbsmprimary-Id001 

Node 

node for test service 

AlertKey 

AlertKey for test service 

Severity 

5 

Note: The field name tbsmprimary is used as an example only. 

The message count for the service increases. 

10. Examine the message content and verify that the Identifier field is Id001. 

11. To test the backup ObjectServer, issue the rad_sendevent command to send a 

message to the backup ObjectServer. 

a. Issue the following command: . 

username@backup_ object_server_hostname 

installhome/tbsm/bin/rad_sendevent ObjectServer port root"" 

b. At the READY prompt, type the following field name and value pairs. 

Separate each item by pressing Enter: 

Identifier 

chin8-Id001 

Node 

node for test service 

AlertKey 

AlertKey for test service 

Severity 

5 

The message count for the service is increased again, because the primary and 

backup ObjectServers are synchronized by the bi-directional gateway. It might 

take several minutes for the increase to occur. 

12. Examine the message content and verify that the Identifier field value is 

Id001. 

Set up Dashboard server users on existing Tivoli Integrated Portal 

If you choose to install the Dashboard server to an existing Tivoli Integrated Portal, 

you need to create the TBSM users and groups after the installation as described in 

this procedure. You do not need to use this procedure if you are installing a new 

instance of Tivoli Integrated Portal with the Dashboard server. 

Procedure 

1. Change to the $TBSM_HOME/bin directory. 

2. Run the following command to create the groups: 

./vmm_create_entities.sh WAS admin userid WAS admin password 

repository user suffix repository group suffix 


Load balancing 

vmm_create_entities.bat WAS admin userid WAS admin password 

repository user suffix repository group suffix 

3. For file-based authentication, run the following command: 

./vmm_create_entities.sh tipadmin tippass "o= 

defaultWIMFileBasedRealm" "o=defaultWIMFileBasedRealm" 

vmm_create_entities.bat tipadmin tippass "o= 


4. For Netcool/OMNIbus authentication, run the following command: 

./vmm_create_entities.sh WAS admin userid WAS admin password 

"o=netcoolObjectServerRepository" "o=netcoolObjectServerRepository" 


"o=netcoolObjectServerRepository" "o=netcoolObjectServerRepository" 

5. For LDAP, use the LDAP user and group suffixes, such as ou=tivoli, dc=ibm, 

and dc=com. 

For example: 


"ou=tivoli" "dc=ibm" "dc=com" 

6. Run the following command to assign roles to the created group: 

./assign_group_roles.sh tipadmin user tipadmin user password 

assign_group_roles.bat tipadmin user tipadmin user password 


“Installing the Dashboard server component” on page 79 







Load balancing is ideal for Tivoli Integrated Portal installations with a large user 

population. When a node within a cluster fails, new user sessions are directed to 

other active nodes. 

You can create a load balanced cluster from an existing stand-alone application 

server instance, but must export its data before you configure it for load balancing. 


The exported data is subsequently imported to one of the nodes in the cluster so 

that it is replicated across the other nodes in the cluster. 

Work load is distributed by session, not by request. If a node in the cluster fails, 

users who are in session with that node must log back in to access the Tivoli 

Integrated Portal. Any unsaved work is not recovered. 

Synchronized data 

After load balancing is set up, changes in the console that are stored in global 

repositories are synchronized to all of the nodes in the cluster using a common 

database. The following actions cause changes to the global repositories used by 

the console. Most of these changes are caused by actions in the Settings folder in 

the console navigation. 

v Creating, restoring, editing, or deleting a page. 

v Creating, restoring, editing, or deleting a view. 

v Creating, editing, or deleting a preference profile or deploying preference 

profiles from the command line. 

v Copying a portlet entity or deleting a portlet copy. 

v Changing access to a portlet entity, page, external URL, or view. 

v Creating, editing, or deleting a role. 

v Changes to portlet preferences or defaults. 

v Changes from the Users and Groups applications, including assigning users and 

groups to roles. 

Note: Global repositories should never be updated manually. 

During normal operation within a cluster, updates that require synchronization are 

first committed to the database. At the same time, the node that submits the 

update for the global repositories notifies all other nodes in the cluster about the 

change. As the nodes are notified, they get the updates from the database and 

commit the change to the local configuration. 

If data fails to be committed on any given node, a warning message is logged into 

the log file. The node is prevented from making its own updates to the database. 

Restarting the Tivoli Integrated Portal Server instance on the node rectifies most 

synchronization issues, if not, the node should be removed from the cluster for 

corrective action. See “Monitoring a load balancing cluster” on page 233 for more 

information. 

Note: If the database server restarts, all connections from it to the cluster are lost. 

It may take up to five minutes for connections to be restored, so that users can 

again perform update operations, for example, modifying or creating views or 

pages. 

Manual synchronization and maintenance mode 

Updates to deploy, redeploy, or remove console modules are not automatically 

synchronized within the cluster. These changes must be performed manually at 

each node. For deploy and redeploy operations, the console module package must 

be identical at each node. 

When one of the deployment commands is started on the first node, the system 

enters maintenance mode and changes to the global repositories are locked. After 


you finish the deployment changes on each of the nodes, the system returns to an 

unlocked state. There is not any restriction to the order that modules are deployed, 

removed, or redeployed on each of the nodes. 

While in maintenance mode, any attempts to make changes in the portal that affect 

the global repositories are prevented and an error message is returned. The only 

changes to global repositories that are allowed are changes to a user's personal 

portlet preferences. Any changes outside the control of the portal, for example, a 

form submission in a portlet to a remote application, are processed normally. 

The following operations are also not synchronized within the cluster and must be 

performed manually at each node. These updates do not place the cluster in 

maintenance mode. 

v Deploying, redeploying, and removing wires and transformations 

v Customization changes to the console user interface (for example, custom images 

or style sheets) using consoleProperties.xml. 

To reduce the chance that users could establish sessions with nodes that have 

different wire and transformation definitions or user interface customizations, 

schedule these changes to coincide with console module deployments. 

Requirements 

The following requirements must be met before load balancing can be enabled: 

v If you are creating a cluster from a stand-alone instance of Tivoli Integrated 

Portal, you must export its data before you configure it for load balancing. Once 

you have configured the cluster, you can import the data to one of the nodes for 

it to be replicated across the other nodes. 

v Lightweight Directory Access Protocol (LDAP) must be installed and configured 

as the user repository for each node in the cluster. For information about which 

LDAP servers you can use, see List of supported software for WebSphere 

Application Server V7.0. See Configuring LDAP user registries for instructions 

on how to enable LDAP for each node. 

v A front-end network dispatcher (for example, IBM HTTP Server) must be setup 

to handle and distribute all incoming session requests. See Setting up 

intermediary services for more information about this task. 

v DB2 Version 9.7 must be installed within the network to synchronize the global 

repositories for the console cluster. 

v Each node in the cluster must be enabled to use the same LDAP using the same 

user and group configuration. 

v All console nodes in load balancing cluster must be installed in the same cell 

name. After console installation on each node, use the -cellName parameter on 

the manageprofiles command. 

v All console nodes in load balancing cluster must have synchronized clocks. 

v The Websphere application server and Tivoli Integrated Portal Server versions 

must have the same release level, including any fix packs. Fixes and upgrades 

for the runtime must be applied manually at each node. 

v Before joining nodes to a cluster, in each case make sure the node uses the same 

file-based repository user ID, which has been assigned the role of iscadmins. 





Exporting data from a stand-alone server to prepare for load 

balancing 

You can export date from an existing stand-alone application server instance to 

create a data file that can be imported to a load balanced cluster. 


When you are creating a new load balanced cluster from a stand-alone instance, 

you must first export all data from the stand-alone instance and subsequently 

import the previously exported data once the cluster is set up. 

Note: If you are joining the server to an existing cluster, the other nodes in the 

cluster should not contain custom data, that is, each node in the cluster should be 

clean installations. When you import data from the stand-alone server it is 

replicated across all other nodes. 

Procedure 

1. At the command line, change to the following directory: tip_home_dir/ 

profiles/TIPProfile/bin/ 

2. Run the following command to export the stand-alone server's data: 

v restcli.sh export -username 

tip_admin_username -password tip_admin_password -destination data_file 

v restcli.bat export -username tip_admin_username 

-password tip_admin_password -destination data_file 

Where: 

tip_admin_username 

Specifies the administrator user ID. 

tip_admin_password 

Specifies the password associated with the administrator user ID. 

data_file 

Specifies the path and file name for the exported data, for example, 

c:/tmp/data.zip. 

3. Create a new load balanced cluster using the stand-alone server, or join it to an 

existing cluster. 

4. Import the previously exported data to any node in the cluster. 

a. At the command line, if necessary, change to the following directory: 

tip_home_dir/profiles/TIPProfile/bin/ 

b. On one of the nodes in the cluster, run the following command to import 

the stand-alone server's data: 

restcli.sh import -username tip_admin_username -password 

tip_admin_password -source data_file 

Where: 




Results 



data_file 

Specifies the path and file name for the data to be imported, for 

example, c:/tmp/data.zip. 

Create a new load balanced cluster using the stand-alone application server, or join 

it to an existing cluster. Once the cluster is configured, you can import the data file 

to one of the nodes in the cluster. 


Setting up a load balancing cluster 

You can configure a Tivoli Integrated Portal Server instance to use a database as a 

file repository instead of a local directory. 


If you are creating a cluster from an existing Tivoli Integrated Portal Server 

instance that contains custom data, ensure that you have exported its data before 

you begin to configure it for load balancing. Once it is configured, you can import 

the data to one of the nodes in the new cluster. 

Tivoli Integrated Portal is installed on a machine using the cell name designated 

for all console nodes within the cluster. You have installed and setup a network 

dispatcher (for example, IBM HTTP Server), DB2, and an LDAP as explained in 

“Requirements” on page 214. 

Procedure 

1. On the machine where DB2 is installed, create a DB2 database (see Creating 

databases). 

2. Check that you have the JDBC driver for DB2 on the computer where Tivoli 

Integrated Portal is installed. The JDBC driver should be available at: 

tip_home_dir/universalDriver/lib. 

3. From a command prompt, change to the tip_home_dir/profiles/TIPProfile/ 

bin/ha directory and edit the settings in tipha.properties. 

Property name Description 

DBHost The hostname or IP address of the machine where the DB2 

database is installed. 

Example: tipdb.cn.ibm.com 

DBPort Port number of the DB2 server. 

Example: 50000 (default) 

DBName The name of the database that you created. 

Example: tipdb 

DBProviderClass Class name of the DB2 provider. 

Example: com.ibm.db2.jcc.DB2Driver (default) 

DBProviderName Name of the DB2 provider. 

Example: TIP_Universal_JDBC_Driver (default) 

DBDatasource JNDI name of the datasource. 

Example: jdbc/tipds 



DBDatasourceName Name of the datasource used for load balancing. 

Example: tipds 

DBHelperClassName DB2 Helper class name. 

Example: com.ibm.websphere.rsadapter. 

DB2UniversalDataStoreHelper (default) 

DBDsImplClassName DB2 datasource implementation class name. 

Example: com.ibm.db2.jcc.DB2ConnectionPoolDataSource (default) 

DBDriverVarName WebSphere environment variable name for DB2 JDBC driver class 

path. 

Example: TIP_JDBC_DRIVER_PATH 

DBJDBCDriverPath Location of DB2 JDBC driver libraries (for example, db2jcc.jar). 

Example: C:/IBM/tivoli/tipv2/universalDriver/lib 

DBDriverType JDBC driver type. 


DBType Database type. 

Example: DB2 (default) 

JaasAliaseName JAAS alias name used to store database username and password. 

Example: TIPAlias (default) 

JaasAliasDesc Description for JAAS alias name. 

Example: JAAS Alias used for load balancing 

LocalHost The hostname or IP address of the machine on which the console 

is running. LocalHost and LocalPort uniquely identify the node in 

the cluster. 

Example: tip01.cn.ibm.com 

LocalPort Administrative console secure port. LocalHost and LocalPort 

uniquely identify the node in the cluster. 

Example: 16311 

WasRoot The full system path to where the application server and console 

images were extracted during installation. 

Example: C:/IBM/tivoli/tipv2 

ProfileName The profile name that was specified on the manageprofiles 

command after installation. If no profile name was specified, the 

default is used. 

Example: TIPProfile (default) 

CellName The cell name that was specified on the manageprofiles command 

after installation. If no cell name was specified, the default is used. 

Example: TIPCell (default)This parameter is optional for a single 

node console installation. For a load balancing cluster, however, it 

is required to ensure all nodes use the same cell name. 

NodeName The application server node name. 

Example: TIPNode (default) 

ServerName The WebSphere Application Server instance name. 

Example: server1 (default) 

IscAppName The Tivoli Integrated Portal Server enterprise application name. 

The Tivoli Integrated Portal Server enterprise application is 

installed in directory the following directory: 

${WAS_ROOT}\profiles\${ProfileName}\installedApps\ 

${CellName}\${IscAppName}.ear 

Example: isc (default) 



LoggerLevel The level of logging required. The default is OFF. 

Example: FINER 

HAEnabled Indicates if load balancing is enabled. 

Attention: Do not edit this value manually. 

4. In the tip_home_dir/profiles/TIPProfile/bin directory, depending on your 

operating system, enter one of the following commands: 

v stopServer.bat server1 

v stopServer.sh server1 

Note: On UNIX and Linux systems, you are prompted to provide an 

administrator username and password. 

5. Make sure your database is empty and the server is not started. Problems may 

occur if you try to setup load balancing on a non-empty database or active 

server. 


bin/ha directory and issue this command: 

v ..\ws_ant.bat -f install.ant configHA 

-Dusername=DB2_username -Dpassword=DB2_password 

v ../ws_ant.sh -f install.ant configHA 




v startServer.bat server1 

v startServer.sh server1 

Results 

The load balancing cluster is created and the console node is joined to the cluster 

as the first node. 


Add (or join) additional nodes to the cluster. 

Joining a node to a load balancing cluster 

You can configure a Tivoli Integrated Portal Server to join an existing load 

balancing cluster. 


1. If you are joining a stand-alone Tivoli Integrated Portal Server instance to a 

cluster, ensure that you first export all of its data. Once you have joined it to 

the cluster, you can then import the previously exported data. Other nodes in 

the cluster should not contain any custom data and should effectively be new 

installed instances. 

2. Make sure you have successfully enabled load balancing following the steps in 

“Setting up a load balancing cluster” on page 216. 


3. Tivoli Integrated Portal should be installed to the node using the same cell 

name that is designated for the cluster. 

4. All console modules deployed to the cluster must be already deployed to the 

node that you intend to join. 

5. You should deploy any wires or transformations used by the nodes in the 

cluster. 

6. If the cluster is using any customization changes in consoleProperties.xml you 

must copy these changes and this file to the same location on the node that you 

intend to join. 

7. The node must be configured to the same LDAP with the same user and group 

definitions as all other nodes in the cluster. 


The following parameters are used on the join option when a node is added: 

v -Dusername - specify the DB2 administrator's username 

v -Dpassword - specify the DB2 administrator's password 

Procedure 




























path. 
















the cluster. 





































administrator username and password.

4. Make sure the Tivoli Integrated Portal Server is not started. 

5. At a command prompt, change to the tip_home_dir/profiles/TIPProfile/bin/ 

ha directory and issue this command 









Results 

The console node is joined to the cluster. 


Add another node to the cluster, or if you have completed adding nodes, enable 

server to server trust for each node to every other node in the cluster. 

Depending on the network dispatcher (for example, IBM HTTP Server) that you 

use, you might have further updates to get session requests routed to the new 

node. Refer to the documentation applicable to your network dispatcher for more 

information. 

Enabling server-to-server trust 

Use this procedure to enable load balanced nodes to connect to each other and 

send notifications. 


These steps are required to enable load balancing between the participating nodes. 

Complete these steps on each node. 

Procedure 

1. In a text editor, open the ssl.client.props file from the tip_home_dir/ 

profiles/TIPProfile/properties directory. 

2. Uncomment the section that starts with com.ibm.ssl.alias=AnotherSSLSettings 

so that it looks like this: 

com.ibm.ssl.alias=AnotherSSLSettings 

com.ibm.ssl.protocol=SSL_TLS 

com.ibm.ssl.securityLevel=HIGH 

com.ibm.ssl.trustManager=IbmX509 

com.ibm.ssl.keyManager=IbmX509 

com.ibm.ssl.contextProvider=IBMJSSE2 

com.ibm.ssl.enableSignerExchangePrompt=true 

#com.ibm.ssl.keyStoreClientAlias=default 

#com.ibm.ssl.customTrustManagers= 

#com.ibm.ssl.customKeyManager= 

#com.ibm.ssl.dynamicSelectionInfo= 

#com.ibm.ssl.enabledCipherSuites= 


3. Uncomment the section that starts with 

com.ibm.ssl.trustStoreName=AnotherTrustStore so that it looks like this: 

# TrustStore information 

com.ibm.ssl.trustStoreName=AnotherTrustStore 

com.ibm.ssl.trustStore=${user.root}/config/cells/TIPCell/nodes/TIPNode/trust.p12 

com.ibm.ssl.trustStorePassword={xor}CDo9Hgw= 

com.ibm.ssl.trustStoreType=PKCS12 

com.ibm.ssl.trustStoreProvider=IBMJCE 

com.ibm.ssl.trustStoreFileBased=true 

com.ibm.ssl.trustStoreReadOnly=false 

4. Update the location of the trust store that the signer should be added to in the 

com.ibm.ssl.trustStore property of AnotherTrustStore by replacing the 

default value com.ibm.ssl.trustStore=${user.root}/etc/trust.p12 with the 

correct path for your trust store. Example: 

com.ibm.ssl.trustStore=${user.root}/config/cells/TIPCell/nodes/TIPNode02 

/trust.p12 

After the update, the section must look like this: 







5. Save your changes to ssl.client.props. 

6. Stop and restart the Tivoli Integrated Portal Server: 

a. In the tip_home_dir/profiles/TIPProfile/bin directory, depending on your 






b. In the tip_home_dir/profiles/TIPProfile/bin directory, depending on your 




7. Complete all of the steps so far on each node before you continue with the rest 

of the steps. 

8. Run the following command on each node for each myremotehost (that is, for 

every node that you want to enable trust with) in the cluster: 

tip_home_dir\profiles\TIPProfile\bin\retrieveSigners.bat 

NodeDefaultTrustStore AnotherTrustStore -host myremotehost -port 

remote_SOAP_port 


retrieveSigners.sh NodeDefaultTrustStore AnotherTrustStore -host 

myremotehost -port remote_SOAP_port 

where myremotehost is the name of the computer to enable trust with; 

remote_SOAP_port is the SOAP connector port number (16313 is the default). If 

you have installed with non-default ports, check tip_home_dir/properties/ 

TIPPortDef.properties for the value of SOAP_CONNECTOR_ADDRESS and use that. 











Example 



In this example, the load balancing cluster is comprised of two Microsoft Windows 

nodes named myserver1 and myserver2. The command entered on myserver1: 

retrieveSigners.bat NodeDefaultTrustStore AnotherTrustStore -host myserver2 

-port 16313 

The command entered on myserver2: 


-port 16313 

Verifying a load balancing implementation 

Use the information in this topic to verify that your Tivoli Integrated Portal load 

balancing setup is working correctly once you have added all nodes to the cluster 

and enabled server-to-server trust. 


This task allows you to confirm the following functions are working correctly: 

v The database used for your load balancing cluster is properly created and 

initialized. 

v Every node in the cluster uses the database as its repository instead of its own 

local file system. 

v Server-to-server trust is properly enabled between nodes in the cluster. 

To verify your load balancing configuration: 

Procedure 

1. Ensure that each Tivoli Integrated Portal Server instance on every node in the 

cluster is running. 

2. In a browser, log into one node, create a new View and save your changes. 

3. Log into the remaining nodes and verify that the newly created view is 

available in each one. 


Preparing the HTTP server for load balancing 

Install the IBM HTTP Server and configure the Web server plug-in for passing 

requests to the Tivoli Integrated Portal Server that are part of the load balancing 



The IBM HTTP Server uses a Web server plug-in to forward HTTP requests to the 

Tivoli Integrated Portal Server. You can configure the HTTP server and the Web 

server plug-in to act as the load balancing server, that is, pass requests (HTTP or 

HTTPS) to one of any number of nodes. The load balancing methods supported by 

the plug-in are round robin and random: 

v With a round robin configuration, when a browser connects to the HTTP server, 

it is directed to one of the configured nodes. When another browser connects, it 

is directed to a different node. 

v With the random setting, each browser is connected randomly to a node. Once a 

connection is established between a browser and a particular node, that 

connection remains until the user logs out or the browser is closed. 

The HTTP server is necessary for directing traffic from browsers to the applications 

that run in the Tivoli Integrated Portal environment. The server is installed between 

the portal and the Tivoli Integrated Portal Server, and is outside the firewall. 

The Web server plug-in uses the plugin-cfg.xml configuration file to determine 

whether a request is for the application server. 


Complete this procedure to configure the Web server plug-in for load balancing for 

each node. 

Procedure 

1. If you do not already have the IBM HTTP Server installed, install it before 

proceeding. It should be installed where it can be accessed from the Internet or 

Intranet (or both). Select the link at the end of this topic for the installation 

procedure. 

2. Install IBM HTTP Server ensuring that you include the IBM HTTP Server 

Plug-in for IBM WebSphere Application Server option. For more information, 

see http://publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/ 

com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_installihs.html. 

3. Create a new CMS-type key database. For more information see 

http://publib.boulder.ibm.com/infocenter/wasinfo/fep/index.jsp?topic=/ 

com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_createkeydb.html. 

4. Create a self-signed certificate to allow SSL connections between nodes. For 

more information, see http://publib.boulder.ibm.com/infocenter/wasinfo/fep/ 

index.jsp?topic=/com.ibm.websphere.ihs.doc/info/ihs/ihs/ 

tihs_certselfsigned.html. 

5. To enable SSL communications for the IBM HTTP Server, in a text editor, open 

HTTP_server_install_dir/conf/httpd.conf. Locate the line # End of example 

SSL configuration and add the following lines, ensuring that the KeyFile line 

references the key database file created in step 3 and save your changes. 

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so 

 

Listen 443 


SSLEnable 

 

 

SSLDisable 

KeyFile "C:/Program Files/IBM/HTTPServer/bin/test.kdb" 

For more information, refer to the first example at http:// 

publib.boulder.ibm.com/infocenter/wasinfo/fep/index.jsp?topic=/ 

com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_setupssl.html. 

6. Restart the IBM HTTP Server. For more information, see http:// 

publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/ 

com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_startihs.html. 

7. On the IBM HTTP Server computer, to verify that SSL is enabled ensure that 

you can access https://localhost. 












9. Start the HTTP server: 

a. Change to the directory where it is installed. 

b. Run this command: bin/apachectl start Note you must restart the server 

after changing the plugin-cfg.xml file. 


Enter the URL for the HTTP Server in a browser http://HTTP_server_host/ 

HTTP_server_port and it will be forwarded to one of the nodes. 

Note: The default load balancing method is random, whereby each browser is 

connected randomly to a node. 


Web server plug-in tuning tips 

The Web server works with the application server to balance workload. 

Setting clone IDs for nodes 

Assign a clone ID for all nodes in the cluster. 


Complete this procedure to set clone IDs for all nodes in the cluster. You must 

carry out these steps on each node. 


Procedure 

1. In a text editor, open the server.xml file from the tip_home_dir/profiles/ 

TIPProfile/config/cells/TIPCell/nodes/TIPNode/servers/server1 directory 

2. In server.xml, locate the entry

v GenPluginCfg.sh 

This command generates a file called plugin-cfg.xml and saves it to the 

tip_home_dir/profiles/TIPProfile/config/cells directory. 

2. On the IBM HTTP Server, in the following directory, replace the existing 

plugin-cfg.xml with the version generated in step 1 on page 226: 

HTTP_web_server_install_dir/plugins/config/webserver1 

The following steps establish the new /ibm/* URI (Uniform Resource 

Identifier), which is where the plug-in will redirect requests: 

a. On the IBM HTTP Server, change to the directory where the Web server 

definition file is (such as cd plugins/config/webserver1). 

b. Open the plugin-cfg.xml file in a text editor, and in reference to the sample 

content extract provided below, edit the file to provide details of your IBM 

HTTP Server and all Tivoli Integrated Portal Server instances. 

HTTP SERVER PATH is the path to where the HTTP server is installed. 

HTTP SERVER PORT is the port for the HTTP server. 

SERVER1 is the fully qualified name of the computer where the 

application server is installed and started. 

SERVER2 is the fully qualified name of the computer where another 


CLONE_ID is the is the unique clone ID assigned to a particular node 

(server) in the cluster. 

c. In the ServerCluster section, the values for the keyring and stashfile 

properties should be HTTP SERVER PATH /plug-ins/etc/plug-in-key.kdb and 

HTTP SERVER PATH /plug-ins/etc/plug-in-key.sth respectively. 

d. Continue to add Server entries for any other nodes, following the same 

pattern. Add a new entry under PrimaryServers for each additional server. 

e. Add CloneID and LoadBalanceWeight attributes for every Server entry. 

Important: For more information on web server plug-in workload 

management policies and to help you determine the appropriate values for 

the elements LoadBalance and LoadBalanceWeight, refer to the following 

articles: 

v http://www.redbooks.ibm.com/abstracts/TIPS0235.html 

v http://www-01.ibm.com/support/docview.wss?rs=180 

&uid=swg21219567 

Attention: The HTTP and HTTPS port values for all nodes should be the 

same. 

 

 

 

 

 

 

 

 

 

 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

AffinityURLIdentifier="jsessionid" Name="/isc/*" /> 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configuring SSL from each node to the IBM HTTP Server 

For load balancing implementations, you must configure SSL between the IBM 

HTTP Server plug-in and each node in the cluster. 


This task assumes that you have already installed and configured the IBM HTTP 

Server for load balancing. 


For each node in the cluster, follow these instructions to configure the node to 

communicate over a secure (SSL) channel with the IBM HTTP Server. 


Procedure 

1. Log in to the Tivoli Integrated Portal. 

2. In the navigation pane, click Settings > Websphere Administrative Console 

and click Launch Websphere administrative console. 

3. Follow these steps to extract signer certificate from the trust store: 

a. In the WebSphere Application Server administrative console navigation 

pane, click Security > SSL certificate and key management. 

b. In the Related Items area, click the Key stores and certificates link and in 

the table click the NodeDefaultTrustStore link. 

c. In the Additional Properties area, click the Signer certificates link and in 

the table that is displayed, select the root entry check box. 

d. Click Extract and in the page that is displayed, in the File name field, enter 

a certificate file name (certficate.arm), for example, c:\tivpc064ha1.arm. 

e. From the Data Type list select the Base64-encoded ASCII data option and 

click OK. 

f. Locate the extracted signer certificate and copy it to the computer running 

the IBM HTTP Server. 

Note: This steps are particular to Tivoli Integrated Portal, for general 

WebSphere Application Server details and further information, see: 

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/ 

com.ibm.websphere.base.doc/info/aes/ae/tsec_sslextractsigncert.html 

4. On the computer running the IBM HTTP Server, follow these steps to import 

the extracted signer certificate into the key database: 

a. Start the key management utility (iKeyman), if it is not already running, 

from HTTP_SERVER_PATH/bin: 

v At the command line, enter ./ikeyman.sh 

v At the command line, enter ikeyman.exe 

b. Open the CMS key database file that is specified in plugin-cfg.xml, for 

example, HTTP_SERVER_PATH/plug-ins/etc/plug-in-key.kdb. 

c. Provide the password (default is WebAS) for the key database and click OK. 

d. From the Key database content, select Signer Certificates. 

e. Click Add and select the signer certificate that you copied from the node to 

the computer running the IBM HTTP Server and click OK. 

f. Select the Stash password to a file check box and click OK to save the key 

database file. 

Note: For more information on certificates in WebSphere Application Server, 

see: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/ 

com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_ikeyscca.html 

5. Repeat these steps for each node in the cluster. 

6. For the changes to take effect, stop and restart all nodes in the cluster and also 

restart the computer running the IBM HTTP Server. 





v stopServer.sh server1







c. Restart the IBM HTTP Server. For more information, see 

http://publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/ 



You should now be able to access the load balanced cluster through 

https://http_server_hostname/ibm/console (assuming that the default context 

root (/ibm/console) was defined in at the time of installation. 

Importing stand-alone instance data to a cluster 

If you created a cluster from a stand-alone application server instance, you can 

then import the data that you exported prior to configuring the stand-alone 

instance as a cluster node. 


Import the previously exported data file to any node in the cluster. 

Important: The instructions in this topic apply only to importing data that was 

exported when preparing to create a load balanced cluster from a stand-alone 

application server instance, as described in “Exporting data from a stand-alone 

server to prepare for load balancing” on page 215. 

Procedure 

1. At the command line, change to the following directory: 


2. On one of the nodes in the cluster (most likely the node that was previously set 

up as a stand-alone server instance), run the following command to import the 

data file: 

v restcli.sh import -username 

tip_admin_username -password tip_admin_password -source data_file 

v restcli.bat import -username tip_admin_username 

-password tip_admin_password -source data_file 

Where: 





data_file 

Specifies the path and file name to the data file that is to be imported, 

for example, c:/tmp/data.zip. 


Results 

The data from the initial application server is imported to the node and replicated 

across the other cluster nodes. 

Removing a node 

Follow these steps to remove a node from the load balancing cluster. 


The following parameters are used on the disjoin option when a node is removed. 



Procedure 



v ..\ws_ant.bat -f uninstall.ant disjoin 

-Dusername=DB2_username -Dpassword=DB2password 

v ../ws_ant.sh -f uninstall.ant disjoin 


2. Update the network dispatcher (for example, IBM HTTP Server) to remove the 

node from the configuration. 

Removing a remote node 


This command should be used only in the rare occasions where physical access to 

the node is not available or a serious hardware or software failure has occurred. If 

the node is remotely disjoined but continues to function, some problems with 

synchronization might arise that can lead to problems with data consistency and 

synchronization. 

Procedure 



v ..\ws_ant.bat -f uninstall.ant remote-disjoin 

–DremoteHost=remote_host –DremotePort=9044 -Dusername=DB2_username 

-Dpassword=DB2_password 

v ../ws_ant.sh -f uninstall.ant 

remote-disjoin –DremoteHost=remote_host –DremotePort=9044 




Removing a load balancing cluster 

Follow these steps to remove the last node from a cluster and thereby the cluster 

itself. 



Make sure you have removed all other nodes from the cluster. This command 

should be issued from the last active node remaining in the cluster. 


The following parameters are used on the join option when a node is added. 



Procedure 

From a command prompt, change to the tip_home_dir/profiles/TIPProfile/bin/ 

ha directory and issue this command: 

v ..\ws_ant.bat -f uninstall.ant uninstall 


v ../ws_ant.sh -f uninstall.ant uninstall 


Monitoring a load balancing cluster 

If synchronized data fails to be committed to a node in the cluster, that node 

should be removed from the cluster for corrective action. Use the diagnosis tool to 

identify any unsynchronized nodes in the load balancing cluster. 

To determine if changes to global data are not committed to any of the nodes, use 

the HATool command script to check the synchronization of modules and 

repositories on the nodes in a cluster. For the HATool, you must provide the DB2 

administrator's credentials. 

Query synchronization of modules 

Use this command to determine if all nodes have identical sets of modules 

deployed. 

HATool.bat/sh modules username password -byNodes -showAll 

The following parameters are optional. 

v -byNodes 

Specifies that the results of the command are ordered by the node in the 

cluster. This parameter is optional. The default is to list the results by 

module. 

v -showAll 

Specifies that all modules and nodes in the cluster should be returned. 

This parameter is optional. The default is to return only modules for 

unsynchronized nodes. 

Query the synchronization of global repositories 

Use this command to determine if all repositories are synchronized on all 

nodes. 

HATool.bat/sh repositories username password -byNodes -showAll 


v -byNodes 




repository. 

v -showAll 


This parameter is optional. The default is to return only repositories for 


Release the global lock 

Use this command to manually release the global lock placed on all of the 

console nodes when the cluster is in maintenance mode. This command is 

used when a node cannot commit a change during synchronization and 

has to be taken offline. 

HATool.bat/sh release-lock username password 

Configuring secure connections 

These topics describe how you can configure secure key connections (via SSL) for 

IBM Tivoli Business Service Manager (TBSM) servers. 


If you plan to configure TBSM failover, the failover configuration must be 

completed and verified before attempting to configure secure connections. 

Otherwise, Data server startup problems may occur. 

If you plan to secure TBSM and Tivoli Integrated Portal component connections 

to Netcool/OMNIbus, OMNIbus must be configured for secure 

communications first. The OMNIbus certificate(s) should be added to the TBSM 

Dashboard server and Data server trust stores before securing the TBSM 

connections to OMNIbus as described below. 

When securing OMNIbus, it is highly recommended that a non-SSL port on the 

OMNIbus server be left available for TBSM components to connect to until all 

certificates have been added to the TBSM server trust stores and all 

configurations have been completed as described in the following sections. 

To set up secure connections: 

1. Perform all necessary certificate exchanges. 

v Use the console for Dashboard servers 

v Use wsadmin commands for Data servers 

2. Run the secure_server_config script on each TBSM server installed. 

3. If you are securing connections between the Data server and 

Netcool/OMNIbus, ltake additional configuration steps. 

Secure connections overview 

This topic is an overview of secure connection configuration for TBSM. 

You can secure key connections (via SSL) between TBSM servers and between the 

TBSM and Tivoli Integrated Portal components and Netcool/OMNIbus. By default, 

the connections are not secured. These connections include: 

v Connections between TBSM servers where the connections are used to exchange 

data, for configuration, for status updates, and for server synchronization. 

v Connections between TBSM and TIP components and Netcool/OMNIbus where 

the connections are used for event processing, user authentication (installation 

option), and event management (Netcool/WebTop). 


Process overview 

To set up secure connections: 

1. Configure Netcool/OMNIbus for secure communications if secure channels 

between TBSM and TIP components and Netcool/OMNIbus are required. For 

more information about the Netcool/OMNIbus ObjectServer and SSL ports see: 

Netcool/OMNIbus documentation . 

2. Perform all needed certificate exchanges. 

v Use the console for dashboard servers 

v Otherwise, use wsadmin commands for data servers 

3. Run the secure_server_config script on each TBSM server installed 

4. If you are securing connections between the data server and 

Netcool/OMNIbus, you take additional configuration steps. 

5. Restart all servers. 

Time Window Analyzer marker clients and secure connections 

If the data server is configured for secure connections, there are implications to 

how Time Window Analyzer marker clients connect to it. For more information 

about HTTPS connections and Time Window Analyzer marker clients, see the 

Netcool Impact Marker Provider Library and the Marker Command Line Client Utility 

topics in the Tivoli Marker Repository Service section of the TBSM Administrator's 

Guide . 

Secure connections in earlier TBSM versions 

The connections that are or can be secured in TBSM version 4 release 2 are 

described in this table. 

Table 14. Secure connections for release 4.2 

Client Server Function Description 

Browser Dashboard server Console interface Secured by default 

with https. 

Dashboard Central user repository User authentication & Secured with 

server or Data (LDAP or OMNIbus) management 

Websphere Applicaiton 

server 

Server or Tivoli 

Integrated Portal 


plugin 

Dashboard Dashboard server Change notification Part of Tivoli 

server 

Integrated Portal Load 

Balancing 

IBM Tivoli Tivoli Monitoring web Policy-based data Provides a secure 

Monitoring service (dashboard fetchers to obtain Tivoli connection for Tivoli 

data access server) 

Monitoring data Data Warehouse and 

client (data 

server) 

requires interim fix 2. 

Secure connections for TBSM 4.2.1 and later 

In addition to the secure connections available in version 4.2, these connections can 

now be secured in TBSM version 4 release 2.1 and later as described in this table. 


Table 15. Secure connections for TBSM servers 

Client Server Function Description 

Dashboard 

server 

Data server Configuration http(s) 

Dashboard Data server Retrieval of data model RMI port 

server 

and other information 

Data server Dashboard server Status or config update 

notification 

RMI port 

Data server Data server Failover 

synchronization & 

health check 

RMI port 

Dashboard 

server – chart 

portlet 

Data server – chart 

web service 

Charting design and 

data retrieval 

http(s) 

radshell Data server Configuration http(s) 

Discovery 

Library Toolkit 

Data server Configuration http(s) 

Discovery 

Library Toolkit 

TADDM Data retrieval RMI port 

Data server Netcool/OMNIbus 

ObjectServer 

Event processing JDBC 

Certificate management for TBSM servers 

This topic describes the certificates you need for TBSM servers. 

Certificates for dashboard servers 

The trust store of each Dashboard server must contain the following signer's 

certificates for secure connections: 

v Data server (primary) 

v Data server (backup) – when configured for failover 

v OMNIbus (for WebTop and/or ObjectServer authentication) 

– Primary ObjectServer 

– Backup ObjectServer – when configured for failover 

v LDAP – for external authentication 

You retrieve certificate signer data from these servers using the Tivoli Integrated 

Portal administration console. 

Certificates for data servers 

The trust store of each Data server must contain the following signer's certificates 

for secure connections: 

v Data server peer – when configured for failover 

v Dashboard server – each for each, when there are multiple Dashboard servers 

v Netcool/OMNIbus (for event processing and/or ObjectServer authentication - 

optional) 

– Primary ObjectServer 

– Backup ObjectServer – when configured for failover 


v LDAP – for external authentication (optional) 

You list and retrieve certificate signer data from these servers using the WebSphere 

Application Server wsadmin tool. 

For more information about the SignerCertificateCommands command group, see: 

SignerCertificateCommands command group for the AdminTask object 

For more information about the WebSphere Application Server wsadmin tool, see: 

Wsadmin tool 

Retrieving signer certificate data for dashboard servers 

This topic describes how to retrieve SSL signer certificate data for Dashboard 

servers. 


You need to log into Tivoli Integrated Portal as an administrator. 


To retrieve certificate signer data: 

Procedure 

1. From the left navigation frame, select Security > SSL certificate and key 

management. 

2. Click SSL certificate and key management on the page that opens. 

3. Click Key stores and certificates on the page that opens. 

4. Click NodeDefaultTrustStore on the page that opens. 

5. Click Signer certificates on the page that opens. 

6. Click Retrieve from port on the page that opens. 

7. Enter the Host, Port, and alias values for the server where you want to retrieve 

a certificate signer. 

For example, for a Data server on the default port you enter: 

v Host: myhost.ibm.com 

v Port: 17311 

v Alias: data server 

8. Click Retrieve signer information. 

The following retrieved signer information displays on the page: 

Serial number 

Specifies the certificate serial number that is generated by the issuer of 

the certificate. 

Issued to 

Specifies the distinguished name of the entity to which the certificate 

was issued. 

Issued by 

Specifies the distinguished name of the entity that issued the certificate. 

This name is the same as the issued-to distinguished name when the 

signer certificate is self-signed. 

Fingerprint (SHA digest) 

Specifies the Secure Hash Algorithm (SHA hash) of the certificate, 


which can be used to verify the certificate's hash at another location, 

such as the client side of a connection. 

Validity period 

Specifies the expiration date of the retrieved signer certificate for 

validation purposes. 


Repeat this procedure for each server where you need to retrieve signer certificate 

information. 

For more information, see the Page help and Command assistance for the page: 

SSL certificate and key management > Key stores and certificates > 

NodeDefaultTrustStore > Signer certificates > Retrieve from port 

Example certificate exchange commands for data servers 

This topic includes examples of how you use the wsadmin tool to list and retrieve 

certificate signer data. 

For more information about the SignerCertificateCommands command group, see: 

SignerCertificateCommands command group for the AdminTask object 

For more information about the WebSphere Application Server wsadmin tool, see: 

Wsadmin tool 

Starting the wsadmin tool 

This example shows how to start the wsadmin tool. 

$TIP_HOME/bin/wsadmin.sh -profileName [TIPProfile | TBSMProfile] 

-username tipadmin -password tippass 

Listing signer certificates 

This example shows how to use the listSignerCertificates function. 

$AdminTask listSignerCertificates {-keyStoreName NodeDefaultTrustStore } 

The output for this command is similar to this example: 

{issuedTo {CN=myhost.raleigh.ibm.com, O=IBM, C=US}} 

{fingerPrint AC:3A:1A:AB:4E:DA:A9:55:9C:9D:CC:AC:9D:1A:DC:8D:CC:6E:36:89} 

{signatureAlgorithm SHA1withRSA(1.2.840.113549.1.1.5)} 

{serialNumber 4492764877969648} 

{alias data-backup} 

{validity {Valid from April 12, 2009 to April 8, 2024.}} 

{version 3} 

{issuedBy {CN=myhost.raleigh.ibm.com, O=IBM, C=US}} 

Retrieving signer certificate data 

This example shows how to use the retrieveSignerFromPort function. 

$AdminTask retrieveSignerFromPort {-host myhost.ibm.com -port 16311 

-keyStoreName NodeDefaultTrustStore –certificateAlias dash server } 

Saving the data 

To save the data and exit, issue the following command: 


$AdminConfig save 

exit 

Running the secure server command 

This topic describes how to create secure connections for a TBSM server. 


You need to list and retrieve the certificate signer data for the TBSM server. 


To set up secure communications for a TBSM server: 

Procedure 

1. Create a secure connections template file with the following command: 

%TBSM_HOME%\bin\secure_server_config.bat template 

$TBSM_HOME/bin/secure_server_config template 

The command creates a file named secure_server_config.date_time.props in 

the TBSM_HOME/bin directory. This file includes instructions about how to use 

the secure_server_config command to configure secure communications for 

your server. Read these instructions for the latest information. 

2. Rename the generated template properties file from 

secure_server_config.date-time.props to secure_server_config.props. 

3. Run the script with the secure-on (or secure-off) parameter. 

For example: 

./secure_server_config secure-on 

Example 

This example shows some sample parameters in the properties files. 

#============================================================================ 

# TBSM 6.1 Secure Server Configuration Properties file 

# Template generated at 20111016084520 

#============================================================================ 

# Invoke the script with template target to generate a configuration template 

# in the local directory: 

# 

# Unix: $TBSM_HOME/bin/secure_server_config template 

# Windows: %TBSM_HOME%\bin\secure_server_config template 

# 

# Invoke the script with secure-on target and specifying the configuration file 

# to enable TBSM server(s) for secure communications: 

# 

# Unix: $TBSM_HOME/bin/secure_server_config secure-on 

-Dsecure_server_config.props=[config-file-path] 

# Windows: %TBSM_HOME%\bin\secure_server_config secure-on 


# 

# Invoke the script with secure-off target and specifying the configuration file 

# to restore TBSM server(s) to non-secure communications: 

# 

# Unix: $TBSM_HOME/bin/secure_server_config secure-off 



# Windows: %TBSM_HOME%\bin\secure_server_config secure-off 


# 

#------------------------------------------------------------------------ 

# Informational - files/properties updated with given ports 

#------------------------------------------------------------------------ 


#------------------------------------------------------------------------ 

# The following files/properties are updated with the specified port: 




# file on both the primary and the backup data servers. 

# 2. The key impact.nameserver.0.port in the 





isc.ear/sla.war/etc/nameserver.props 


# 4. The key impact.sla.serverhttpport in the 




# 5. The key impact.server.http.port in the 





# $TBSM_HOME/etc/TBSM_server.props 


#------------------------------------------------------------------------ 


#------------------------------------------------------------------------ 

# The following files/properties are updated with the specified port: 










sla.war/etc/nameserver.props 


# 4. The key impact.sla.serverhttpport.backup in the 




# 5. The key impact.replication.replicationhttpport in the 




# 6. The key impact.replication.replicationhttpport in the 






#------------------------------------------------------------------------ 

# Dashboard Server HTTP Port 

#------------------------------------------------------------------------ 

# The dashboard server HTTP port is used when configuring the 

# TBSMChartService connection for the chart portlet. 


#------------------------------------------------------------------------ 

#------------------------------------------------------------------------ 

# Credentials needed to complete configuration. 

# TIPAdminUserid - the userid of the administrative user in Tivoli 

# Integrated Portal. **Note: This userid must have the 

# chartAdministrator role assigned. 

# 

# TIPAdminPassword - the password of the TIPAdminUserid user. The 

# password will be removed from this properties file 

# when the secure_server_config utility is run. 

#------------------------------------------------------------------------ 

TIPAdminUserid=tipadmin 

TIPAdminPassword=tipadminPassword 

#------------------------------------------------------------------------ 

# Parameters used in secure server configuration 

#------------------------------------------------------------------------ 

# Primary Data Server secure HTTP Port 


# For the actual value in use, see the WC_defaulthost_secure key in the 

# $TIP_HOME/profiles/TBSMProfile/properties/portdef.props file on the 

# primary data server. 

# 

SECURE_PrimaryDataServerHTTPPort=17311 

#---------------------------------------------------- 

# Backup Data Server secure HTTP Port 




# backup data server. 

# 

SECURE_BackupDataServerHTTPPort=17311 

#---------------------------------------------------- 

# Dashboard Server secure HTTP Port 



# $TIP_HOME/profiles/TIPProfile/properties/portdef.props file on the 

# dashboard server. 

# 

SECURE_DashboardServerHTTPPort=16311 

#---------------------------------------------------- 

#------------------------------------------------------------------------ 

# Parameters used in non-secure server configuration 

#------------------------------------------------------------------------ 

# Primary Data Server non-secure HTTP Port 


# For the actual value in use, see the WC_defaulthost key in the 


# primary data server. 

# 

OPEN_PrimaryDataServerHTTPPort=17310 

#---------------------------------------------------- 

# Backup Data Server non-secure HTTP Port 




# backup data server. 

# 

OPEN_BackupDataServerHTTPPort=17310 

#---------------------------------------------------- 


# Dashboard Server non-secure HTTP Port 



# $TIP_HOME/profiles/TIPProfile/properties/portdef.props file on the 

# dashboard server. 

# 

OPEN_DashboardServerHTTPPort=16310 

#---------------------------------------------------- 


Repeat this procedure for every server in the environment. Secure the connections 

to Netcool/OMNIbus. 

Configure secure communications to Netcool/OMNIBus 

These tasks describe how to configure secure communications between the TBSM 

servers and Netcool/OMNIbus. 

Limitation: rad_sendevent: The rad_sendevent utility does not currently support 

connecting to the Netcool/OMNIBus ObjectServer over SSL. As a result, if your 

ObjectServer is configured to only accept SSL connections, then rad_sendevent will 

fail. To work around this limitation, the ObjectServer needs to be configured to 

accept connections on an additional, non-SSL port. 

1. Start the Netcool/OMNIbus Editor 

2. Configure the NCOMS server to listen on an additional, non-SSL port. 

3. After the configuration changes are completed, restart the ObjectServer. 

4. Use the port number you specified in step 2 when you run rad_sendevent. 

For more detailed information, see the Netcool/OMNIbus documentation at: 

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic=/ 

com.ibm.netcool_OMNIbus.doc_7.2.1/install/concept/ 

omn_con_ssl_configuringserved.html 

Securing connections to Netcool/OMNIBus 

This topics describes how to secure connections to Netcool/OMNIbus. 


Before you start this task, you need to: 

1. Set up secure connections between the TBSM servers. 

2. Create a key database and a self-signed certificate for Netcool/OMNIbus as 

described here: 

Using SSL for client and server communications 


To set up secure communications with Netcool/OMNIbus, perform the following 

tasks: 

v Import ObjectServer signer's certificates into trust stores of TBSM servers 

v Configure ObjectServer data sources on Data server 

v Set up each server (primary and backup) in failover configuration 


Procedure 

1. Back up the following files on the Data server: 

v $TBSM_HOME/etc/TBSM_ObjectServer_DS.ds 

v $TBSM_HOME/etc/TBSM_OutputObjectServer_DS.ds 

v $TBSM_HOME/etc/TBSM_eventbroker.props 

2. Update the following files with change the values of the following properties 

from FALSE to TRUE as appropriate: The variable to update is listed under each 

file as follows: 

TBSM_ObjectServer_DS.ds 

USESSLPRIMARY=TRUE 

USESSLBACKUP=TRUE 

TBSM_OutputObjectServer_DS.ds 

USESSLPRIMARY=TRUE 

USESSLBACKUP=TRUE 

Note: If the USESSLPRIMARY and USESSLBACKUP properties do not exist in the 

TBSM_OutputObjectServer_DS.ds file, add them as follows: 

OutputObjectServer_DS.ObjectServer.USESSLPRIMARY=TRUE 

OutputObjectServer_DS.ObjectServer.USESSLBACKUP=TRUE 

3. If you configured the secure ObjectServer channel over a different port than the 

typical 4100, change these port number properties accordingly. 

TBSM_ObjectServer_DS.ds 

ObjectServer_DS.ObjectServer.PRIMARYPORT 

ObjectServer_DS.ObjectServer.BACKUPPORT 

TBSM_OutputObjectServer_DS.ds 

ObjectServer_DS.ObjectServer.PRIMARYPORT 

ObjectServer_DS.ObjectServer.BACKUPPORT 

4. Restart the Data server. 


Verify the configuration. 

Note: Netcool/WebTop and Tivoli Integrated Portal (authentication plug-in) 

support secure connections to Netcool/OMNIbus. 

For Netcool/WebTop, see: Creating secure connections 

Configuring data server secure connection to Netcool/OMNIbus 

as user repository 

This topic describes how to set up encrypted communications between the data 

server and the Netcool/OMNIbus ObjectServer for an environment where the 

ObjectServer is the user registry. 


It is assumed that Netcool/OMNIbus has already been configured for secure 

communications. If that is not the case, then see the Netcool/OMNIbus 


documentation to complete this configuration prior to executing the procedures in 

this task.. For more information see: Using SSL for client and server 

communications on the Netcool/OMNIBus information center. 


Follow these steps to establish a secure channel for communications between the 

TBSM data server and the ObjectServer when the ObjectServer is being used as a 

user registry. 

Procedure 

1. Retrieve the ObjectServer certificate and save it into the trust store of the data 

server as described in “Example certificate exchange commands for data 

servers” on page 238. 

2. Edit the file: 

$TIP_HOME/profiles/TBSMProfile/installedApps/TBSMCell/TBSM.ear/sla.war/etc/rad/ 

RAD_com.sybase.jdbc3.SybDriver.props 

Set the properties as follows: 

a. Enable SSL for ObjectServer primary host: USESSLPRIMARY=TRUE 

b. Enable SSL for ObjectServer backup host: USESSLBACKUP=TRUE 

3. Restart the data server. 

Configuring dashboard server secure connection to 

Netcool/OMNIbus as user repository 

This topic describes how to set up encrypted communications between the 

dashboard server and the Netcool/OMNIbus ObjectServer for an environment 

where the ObjectServer is the user registry. 


It is assumed that Netcool/OMNIbus has already been configured for secure 

communications. If that is not the case, then see the Netcool/OMNIbus 

documentation to complete this configuration before you execute the procedures in 

this task. For more information see,: Using SSL for client and server 

communications on the Netcool/OMNIbus information center. 


Follow these steps to establish a secure channel for communications between a 

TBSM dashboard server and the ObjectServer when the ObjectServer is being used 

as a user registry. 

Procedure 

1. Retrieve the ObjectServer certificate and save it into the trust store of the 

dashboard server as described in “Retrieving signer certificate data for 

dashboard servers” on page 237. 

2. Edit the file: 

$TIP_HOME/systemApps/isclite.ear/sla.war/etc/rad/ 

RAD_com.sybase.jdbc3.SybDriver.props 

Set the properties as follows: 



3. Restart the dashboard server. 


Configuring Web GUI connections to Netcool/OMNIBus 

This topic describes how to configure secure communications between the 

dashboard server's Web GUI instance and Netcool/OMNIBus. 


Netcool/OMNIbus needs to be configured to operate over SSL and the signer 

certificate for the ObjectServer (certificates for each server when configured for 

failover) has already been added to the trust store of the dashboard server. 


To configure these connections: 

Procedure 

1. Make backups of the following files: 

$NCHOME/omnibus_webgui/etc/server.init 

$NCHOME/omnibus_webgui/etc/datasources/ncwDataSourceDefinitions.xml 

2. Edit the server.init file and set the trust store password for the property: 

webtop.ssl.trustStorePassword 

The default password for WebSphere trust stores is WebAS, so the property 

would look as follows after being edited: 

webtop.ssl.trustStorePassword: WebAS 

3. Save the file changes. 

4. Edit ncwDataSourceDefinitions.xml file and change the value of the ssl 

attribute from false to true as follows: 

 

 

 

Note: The values of the port attributes in the connection information above 

may also need to be changed if Netcool/OMNIbus was configured to use SSL 

on a different port. 

5. Save the file changes. 

6. Restart the dashboard server. 

For more information about Web GUI secure connections see Creating secure 

connections on the Web GUI information center. 

Securing connections to the Discovery Library Toolkit 

The Discovery Library toolkit is capable of using Secure Socket Layer (SSL) for its 

communications with both the TBSM data server and the TADDM server. 

Enablement of these is controlled through properties in the $TBSM_HOME/ 

XMLtoolkit/bin/xmltoolkitsvc.properties file. 

Note: The SSL connection secures the communications with the TADDM server 

and the TADDM API's, but does not secure the communications with the TADDM 

DB when using the JDBC connection type. 

Properties for TADDM secure connections 

These properties control the SSL connections to TADDM. 


DL_TADDM_SSL 

Set to true for SSL 

If the DL_TADDM_SSL property is set to true, you must copy 

jssecacerts.cert file from the $TADDMHOME/dist/etc directory and place it 

in the .../XMLtoolkit/sdk/etc directory. 

DL_TADDM_SSL_Port 

Set to the port that TADDM is listening on, the default is 9531. The 

collation.properties file on the TADDM server contains the SSL port 

value. The property is: 

#Port for SSL API 

com.collation.api.ssl.port=9531 

Properties for TBSM Data Server secure connections 

These properties configure the SSL connections to the TBSM data server. 

Note: Since both the data server and the Discovery Library Toolkit are installed on 

the same machine this security option is normally not required. 

DL_TBSM_SSL 

Set to true for SSL 

DL_TBSM_HTTP_Port 

Specify the data server's SSL port. 

Verifying secure connections 

This topic describes how to verify secure connections. 

To verify that your secure connections are working properly: 

v Ensure all servers start successfully. Check SystemOut.log, trace.log, and so on. 

v View the Service Administration and Service Availability pages, portlets, and 

functions within portlets in the Tivoli Integrated Portal console. 

v Exercise failover function. 

v Exercise event processing/status updates. 

Typical errors and problems 

Typical errors and problems include: 

v Secure connections have been configured but trust has not been established 

because one or more certificates are missing from a client-side trust store – look 

for messages like “trust” could not be established 

v One end of a connection is secured but the other isn't (for example, trying to use 

http when https is required) can happen if secure server script is not run on all 

servers 

v Trying to establish SSL connection to nonsecure port; make sure that the correct 

port numbers were specified in the secure server properties file. 

Example error message 

Here is an error message indicating that no certificate was found: 

Caused by: HTTP transport error: javax.net.ssl.SSLHandshakeException: co 

m.ibm.jsse2.util.h: 

No trusted certificate found 

at com.sun.xml.rpc.client.http.HttpClientTransport.invoke(HttpClientTra 


nsport.java:140) 

at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:92) 

at com.micromuse.sla.soap.RADSoapFacadeIfc_Stub.setUserForSession(RADSoa 

pFacadeIfc_Stub.java:4379) 

Replacing the default SSL certificates with certificates signed 

by a certificate authority 

These topics describe how to switch from the default IBM supplied Secure Sockets 

Layer (SSL) certificate to a certificate signed by a certificate authority (CA). 

After you change the certificate, you will be able to secure the client browser to 

server connection. These instructions do not cover securing the backend (server to 

server) connections. 

Overview 

To use a certificate signed by a CA, open the TBSM Dashboard server console and 

perform all of the following actions. The procedures are described in more detail 

in the topics which follow. 

1. Create a personal certificate request to obtain a certificate that is signed by a 

CA. You can find the general Websphere Application Server instructions at: 

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/ 

com.ibm.websphere.express.doc/info/exp/ae/tsec_sslcreateCArequest.html 

2. Receive a certificate issued by a certificate authority. You can find the general 

Websphere Application Server instructions at: http://publib.boulder.ibm.com/ 

infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/ 

info/exp/ae/tsec_sslreceiveCAcert.html 

Note: This procedure allows you to continue using the console and access 

TBSM (with the exception of the Service Details portlet), which requires that 

the signer certificate be added to the Trust Store as described in the next step. 

Please note that TBSM cannot use this certificate until it is enabled. 

Important: In some cases, such as when a certificate authority uses 

intermediate certificates, you may receive multiple certificates. In these cases 

install all the certificates issued by the certificate authority. 

3. Adding a signer certificate to the Trust Store. You can find the general 

Websphere Application Server instructions at: http://publib.boulder.ibm.com/ 

infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/ 

info/exp/ae/tsec_ssladdsignercert.html 

Note: If you restart the TBSM Dashboard server without completing this step 

(adding the signer certificate to the Trust Store), the TBSM Dashboard will not 

be able to restart. And therefore, you'll have no access to TBSM whatsoever 

(not even the items previously accessible when step 2 was completed). 

However, please note that this step once completed, will allow the Dashboard 

server to connect to the Data server (without the need to restart any of the 

components). In this step, all we need to do, is add the CA's Intermediate 

certificate. 

4. Enable the new SSL Certificate. 

5. SSL Signer Exchange 

Note: Failure to perform this action, could result in a failure of any future 

maintenance properly installing on the Dashboard server. Where the installer 


may need to first check on the status of the Dashboard server but, cannot log 

on, due to missing Signer trust information. 

Creating a personal certificate request 

This topic describes how to create a personal certificate request to obtain a 

certificate that is signed by a CA. 


You need to log on to TBSM as a user with administrator permissions. 


Complete the following steps in the administrative console: 

Procedure 

1. Click Security > SSL certificate and key management > 

2. From the page that opens, under Related items. click Key stores and 

certificates. 

3. From the page that opens, click NodeDefaultKeyStore 

4. Under Additional Properties, click Personal certificate requests. 

5. From the page that opens, click New and the Configuration: General 

Properties window opens 

6. Type the full path of the File for certificate request file. The certificate request 

is created in this location. 

7. Type an alias name in the Key label field. The alias identifies the certificate 

request in the keystore. 

8. Type an organization value. This value is the O value in the certificate DN. 

9. You can configure one or more of the following optional values: 

a. Select a key size value. The default key size value is 1024 bits. 

b. Type an organizational unit value. This organizational unit value is the OU 

value in the certificate DN. 

c. Type a locality value. This locality value is the L value in the certificate 

DN. 

d. Type a state or providence value. This value is the ST value in the 

certificate DN. 

e. Type a zip code value. The zip code value is the POSTALCODE value in 

the certificate DN. 

f. Select a country value from the list. This country value is the C= value in 

the certificate request DN. 

10. Click Apply and the certificate request is saved displays in the panel. 

Results 

The certificate request is created in the specified file location in the keystore. The 

request functions as a temporary placeholder for the signed certificate until you 

manually receive the certificate in the keystore. 

Note: Key store tools (such as iKeyman and keyTool) cannot receive signed 

certificates that are generated by certificate requests from WebSphere Application 

Server. Similarly, WebSphere Application Server cannot accept certificates that are 

generated by certificate requests from other keystore utilities. 



At this point the request can be sent to the Certificate Authority (CA). Once you 

receive the certificate, go to the next procedure for receiving the certificate. 

Receiving the certificate 

This topic describes how to receive a certificate issued by a certificate authority 


You need to create a personal certificate request and the certificate authority needs 

to issue the certificate. 


WebSphere Application Server can receive only those certificates that are generated 

by a WebSphere Application Server certificate request. It cannot receive certificates 

that are created with certificate requests from other keystore tools, such as 

iKeyman and keyTool. 


Procedure 

1. Click Security > SSL certificate and key management 

2. On the page that opens, under Configuration, click Manage endpoint security 

configurations. 

3. On the page that opens, select either the Inbound or Outbound node SSL 

configuration, depending on the certificate you are receiving. For example: to 

select the Inbound connection, click: 

Inbound > TIPCell > Nodes > TIPNode(NodeDefaultSSLSettings.null) 

4. On the page that opens, under Related Items, click Key store and certificates, 

under 'Related Items' 

5. On the page that opens, click NodeDefaultKeyStore, 

6. On the page that opens, under Additional Properties, click Personal 

certificates. 

7. On the page that opens, click Receive a certificate from a certificate authority. 

8. On the page that opens: 

a. Type the full path and name of the certificate file. 

b. Select a data type from the list. 

9. Click Apply 

10. On the message box that opens, click Save. 

Results 

The personal certificate is added to the NodeDefaultKeystore. The keystore 

contains a new personal certificate that is issued by a CA. The original certificate 

request is changed to a personal certificate. 


Add a signer certificate to the new keystore. 


Adding a signer certificate to a keystore 

This topic describes how to add a signer certificate to the Trust Store. 


You need to receive a certificate issued by a certificate authority. 


Signer certificates establish the trust relationship in SSL communication. You can 

extract the signer part of a personal certificate from a keystore, and then you can 

add the signer certificate to other key stores. 

Note: If you restart the TBSM Dashboard server without completing this step 

(adding the signer certificate to the Trust Store, the TBSM Dashboard will not be 

able to connect to the TBSM Data server at all. And therefore, you'll have no access 

to TBSM whatsoever (not even the items previously accessible when step 2 was 

completed). However, please note that this step once completed, will allow the 

Dashboard server to connect to the Data server (without the need to restart any of 

the components). In this step, all we need to do, is add the CA's Intermediate 

certificate. 


Procedure 

1. Click Security > SSL certificate and key management. 

2. From the page that opens, under Configuration settings, click Manage 

endpoint security configurations. 


configuration, depending on the certificate you are adding. For example: to 



4. On the page that opens, under Related Items, click Key store and certificates, 

under 'Related Items' 

5. On the page that opens, click NodeDefaultTrustStore. 

6. On the page that opens, under Additional Properties, click Signer certificates. 

7. On the page that opens, click Add. 

8. From the page that opens: 

a. Enter the alias for the signer certificate in the Alias field . 

b. Enter the full path to the signer certificate file in the File name field 

c. Select the data type from the list in the Data Type field 

d. Click Apply. 

9. In the message box that opens, click Save. 

Results 

When these steps are completed, the signer from the certificate file is stored in the 

keystore. You can see the signer in the keystore files list of signer certificates. Use 

the keystore to establish trust relationships for the SSL configurations. 



You need to enable the new SSL Certificate. 

Enabling the new SSL certificate 

This topic describes how to enable an SSL certificate. 


You need to add a signer certificate to the Trust Store. 


Complete the following configuration steps in the administrative console: 

Procedure 

1. Click Security > SSL certificate and key management 

2. On the page that opens, under Configuration, click Manage endpoint security 

configurations. 


configuration, depending on the certificate you are receiving. For example: to 



4. On the page that opens, select the Certificate alias in keystore you specified 

when you added the certificate. 

5. Click Apply 

6. On the message box that opens, click Save. 

Results 

The next time a user logs into the TBSM console, the Dashboard server will return 

the new, CA-signed certificate to the browser. 


Run SSL signer exchange command to add the signer to the trust store. 

Adding SSL signer exchange 

This topic describes how to add an Secure Socket Layer signer exchange for the 

new certificate. 


The SSL certificate must be enabled. 


Complete this task at a command prompt on the Dashboard server host. 

Important: If you do not complete this task, fix packs and interim fixes may fail 

when they are applied to the Dashboard server. 


Procedure 


$TIP_HOME/bin/serverStatus.sh -all 

2. Enter 'y' when prompted to do so by the command. 

Example 

In this example the signer is added for a certificate from Verisign. 

/opt/IBM/tivoli/tipv2/bin/serverStatus.sh -all 

ADMU0116I: Tool information is being logged in file 

/opt/IBM/tivoli/tipv2/profiles/TIPProfile/logs/serverStatus.log 

ADMU0128I: Starting tool with the TIPProfile profile 

ADMU0503I: Retrieving server status for all servers 

ADMU0505I: Servers found in configuration: 

ADMU0506I: Server name: server1 

*** SSL SIGNER EXCHANGE PROMPT *** 

SSL signer from target host null is not found in trust store 

/opt/IBM/tivoli/tipv2/profiles/TIPProfile/etc/trust.p12. 

Here is the signer information (verify the digest value matches what is displayed 

at the server): 

Subject DN: CN=vmwlnx4l3j9d.tivlab.raleigh.ibm.com, OU=Terms of use at 

www.verisign.com/cps/testca (c)05, OU=TBSM, O=IBM, L=RTP, ST=NORTH CAROLINA, C=US 

Issuer DN: CN=VeriSign Trial Secure Server CA - G2, OU=Terms of use at 

https://www.verisign.com/cps/testca (c)09, OU="For Test Purposes Only. 

No assurances.", O="VeriSign, Inc."... 

Serial number: 13583817932481119925668512051223819622 

Expires: Fri Jul 17 19:59:59 EDT 2009 

SHA-1 Digest: 1D:D1:ED:0C:BF:FE:F7:B1:80:0C:03:5D:75:FF:15:6B:F9:15:8E:F8 

MD5 Digest: C7:89:4D:79:2F:0F:F6:97:04:9E:B6:2D:CC:20:D9:53 

Add signer to the trust store now? (y/n) 

Modifying the tivoli_eif.props file 


The tivoli_eif.props file is self-documented in that it contains each supported 

property name along with its default value. All of these properties are contained in 

the section that begins with the following lines: 

####################################################################### 

# 

# Property Name Default 

# 

# Generic Properties 

If not changed, the default value for any property is the value that appears in the 

Default column. 

It is strongly recommended that any property value that is modified from its 

default value be added to this section at the bottom of the file: 

####################################################################### 

# 

# Add your settings here 

# 

####################################################################### 


Doing this ensures that the original default value and the changed value are 

available for debugging and problem support. 

Ensure service templates were created 


$TBSM_HOME/install/BSM_Templates.radsh is a radshell script that defines service 

templates for common TBSM services. 

During a simple installation of the Data server, the TBSM installation program 

launches a tool to run the script, but does not wait for the tool to complete. The 

tool might not finish by the time you reboot because it must wait for the TBSM 

server to start completely. Additionally, if the tool tries to add the templates before 

TBSM initializes, you might see failure errors. 

Look at the log files templates.out and templates.err in the directory: 

$TBSM_HOME/logs/install/ 

If there are errors or exceptions in log files, run the tool manually to create the 

service templates. To run the tool: 

Type the following from a command prompt: 

%TBSM_HOME%\bin\tbsmdefaultimport 

Assuming that you have sourced /tivoli/tbsm/bin/ 

setupTBSMDash.sh or /tivoli/tbsm/bin/setupTBSMData.sh, type the 

following from a command prompt: 

$TBSM_HOME/bin/tbsmdefaultimport 

Configuring automatic startup of TBSM on UNIX 

Rebooting or logging off and then logging back on does not restart the TBSM 

servers. TBSM typically does not require configuration for automatic startup; 

however, there might be some situations in which automatic startup is useful. 


To configure automatic startup of TBSM and its associated prerequisite services on 

UNIX systems, do the following steps: 

Procedure 

1. Log in as the root user. You must log in as the root user to install the service 

startup code. 

2. Change to the /tbsm/etc/ directory. 

3. Open the tbsm_suite.props file in a text editor. 

4. Change the properties to appropriate values for your installation as described 

in Table 16. 

Table 16. Service properties for automatic startup 

Property Description 

TBSM_USER TBSM administrator's user ID. This is the user that installed TBSM and will be used to 

start all required TBSM processes. 


Table 16. Service properties for automatic startup (continued) 

Property Description 

OBJECTSERVER_NAME Name of the ObjectServer for this installation. The default value is NCOMS. If you are 

setting up a backup server in a failover configuration, enter the backup ObjectServer 

name. 

Note: If you are installing in a failover environment, see the failover information in 

the Administrator's Guide. 

START_BIDIR_GATEWAY (Optional) If you need to start a bi-directional gateway on your host, uncomment this 

value by removing the # character at the beginning of the line. 

5. Change to the directory $TBSM_HOME/bin and run the following command: 

./autostartup_enable.sh 


If the different components of TBSM have been distributed across multiple hosts, 

repeat this procedure on each host where the installation was performed. If failover 

has been configured, perform the configuration on the primary and backup 

servers. Additionally, if you start any of the TBSM services through other means or 

if IBM Tivoli Netcool OMNIbus ObjectServer is managed under process control, 

the corresponding component startup should be removed from the tbsm_suite.sh 

file located in the $TBSM_HOME/bin directory. In TBSM, the tbsm_suite.sh file is 

used for both automatic startup and shutdown. 

Removing the automatic startup configuration on UNIX 

To remove the automatic startup configuration in a distributed installation, remove 

the startup configuration on each host. 


To remove the automatic startup configuration on UNIX, perform the following 

steps: 

Procedure 

1. Log in as the root user. 

2. Change to the directory: $TBSM_HOME/bin. 

3. Run the remove service script command. For example, if your $TBSM_HOME 

directory is /opt/IBM/tivoli/tbsm, issue the following command: 

./autostartup_disable.sh /opt/IBM/tivoli/tbsm 


Troubleshooting installation issues 


Common installation issues 

This section describes symptoms of and resolutions for common installation issues. 

Log files that the TBSM installation program uses are also listed. 



Problem: Unix console install failed with these errors: 

This issue occurs in both console and silent installations. 

Thu Mar 07 07:13:25.957 EST 2013 : STDOUT : showing summary panel 

Thu Mar 07 07:13:26.620 EST 2013 : 

STDERR : java.lang.NoClassDefFoundError: 

sun.awt.X11.XToolkit (initialization failure) 

Thu Mar 07 07:13:26.620 EST 2013 : STDERR : 



at java.lang.Class.forNameImpl(Native Method) 


at java.lang.Class.forName(Class.java:139) 

Cause:: InstallAnywhere installer failed to get the X11 handle. 

Resolution:: Unset the DISPLAY. That is, enter unset DISPLAY at the 

command line prompt and run the console mode installation command 

again. 

Problem: The installer hangs at the last step of importing the templates 

The last line in TBSMInstall-00.log contains the following: 

2013-03-12 13:26:31.130-04:00 : FINE : Install TBSM default templates 

(from com.ibm.ac.coi.ext.ia.tasks.COIExtensionIALog.execute) 

Cause: The template import command does not return the control back to 

the installer. 

Resolution: Complete the following procedure to import the templates: 

1. Cancel or terminate the installer if it is running. Since this it the 

installer's last step, it's safe to terminate the installer. 

2. To import the templates, run: 

$TBSM_HOME/bin/tbsmdefaultimport 

Problem: Windows, Core dump near the end of the fresh install (or upgrade). 

The following error appears at the end of the main log file 

TBSMInstall-00.log. 

2013-03-13 03:48:45.220-12:00 : 

FINE : ** DeploymentPlanProcessor.process(INSTALL) completed with Success. 

(from com.ibm.ac.coi.ext.ia.COIWrapperPluginImpl.install) 

2013-03-13 03:48:45.220-12:00 : 

FINER : ENTRY (from COIWrapperWorkerThread.disposeSIRuntime) 

2013-03-13 03:48:45.220-12:00 : 

FINER : ENTRY (from DEOperations.disposeSIRuntime) 

2013-03-13 03:48:45.220-12:00 : 


FINER : RETURN (from DEOperations.disposeSIRuntime) 

2013-03-13 03:48:45.220-12:00 : 

FINER : RETURN (from COIWrapperWorkerThread.disposeSIRuntime) 

2013-03-13 03:48:45.220-12:00 : 

FINE : $IAGLOBAL_COI_PLAN_STATUS$=SUCCESS 

(from com.ibm.ac.coi.ext.ia.plugin.COIProcessPlan.install) 

2013-03-13 03:48:45.220-12:00 : 

FINE : $IAGLOBAL_COI_SUCCESS_MESSAGE$= 

(from com.ibm.ac.coi.ext.ia.plugin.COIProcessPlan.install) 

2013-03-13 03:48:45.220-12:00 : 

FINER : RETURN (from com.ibm.ac.coi.ext.ia.plugin.COIProcessPlan.install) 

2013-03-13 03:48:45.313-12:00 : 

STDERR : Retrying Installables deferred in pass 0 

2013-03-13 03:48:45.313-12:00 : 

STDERR : Deferral retries done because: 

2013-03-13 03:48:45.313-12:00 : 

STDERR : There were no deferrals in the last pass. 

2013-03-13 03:48:45.688-12:00 : 

FINER : ENTRY (from com.ibm.netcool.wizard.PostReuseTaskAction.install) 

Cause: The fresh installer (or upgrade installer) got the core dump while 

zipping up the install log files. 

Resolution: The overall fresh install (or upgrade) completed successfully. 

You can safely ignore the core dump. 

1. Open command line window and change to the TIP profile directory 

/tipv2/profiles/TIPProfile/bin 

Tip: The default install location is C:\Program Files\IBM\tivoli for 

Windows and /opt/IBM/tivoli on UNIX based systems. 


On Windows systems: 

tipRegister.bat 8DA4201AE37B4C459EA475F10947C716 TBSM 

"C:\Program Files\IBM\tivoli\tbsm" 6.1.1.0 product none false 

On UNIX- systems: 

tipRegister.sh 8DA4201AE37B4C459EA475F10947C716 TBSM 

"/opt/IBM/tivoli/tbsm" 6.1.1.0 product none false 

Problem: 64-bit Windows, the launchpad does not open automatically 

On 64-bit Windows, the launchpad does not open automatically when the 

DVD is inserted. To start it, use Windows explorer and click on 

launchpad64.exe or use a command prompt and run the launchpad64.exe 

command. 

Problem: Installing into existing Tivoli Integration Portal (TIP) does not display 

existing TIP directory to select. 

Cause: 

TBSM 6.1.1 requires TIP 2.2.0.11 or higher 

Solution: 

Upgrade existing TIP to 2.2.0.11 first then run TBSM 6.1.1 install. 

Problem: Error message state the step consolidate does not exist or IA log file 

reports 

A popup message occurs saying the step consolidate does not exist or IA 

log file reports, 

"...PackageSteps did not contain Deployment Step: consolidate" 


(Caused by: com.ibm.ac.coi.api.exception.MissingPackageStepException: 

The Deployment Package Steps at 

/products/home/tbsmbvt/V6.1.0/TBSM/COI/PackageSteps 

did not contain Deployment Step: consolidate) 

Cause: A step was erroneously generated. 

Solution: Rerun the installer. 

Problem: Error message when running tbsm_db_update.sql command: 

If you are importing the TBSM schema into an existing Netcool/OMNIBus 

ObjectServer, you may receive error messages similar to the following 

when running tbsm_db_update.sql command: 

ERROR=Object exists on line 83 of statement 

’----------------------------------------------------------------...’, 

at or near ’BSM_Identity’ (0 rows affected) (0 rows affected) 


ERROR=Object not found on line 15 of statement 

’---------------------------------------------------------------------- 

...’, at or near ’service_deps’ 







These messages can be ignored. The ObjectServer will return an error if a 

user tries to add a column that already exists, which explains the error on 

BSM_Identity. It will also return an error if a user drops a table that 

doesn't exist, which explains the second error. 

Problem: Space error messages when installing into an existing Tivoli Integrated 

Portal When you install into an existing TIP, a backup is taken of the existing 

Deployment Engine (DE) , TIP, and any TBSM or Impact directories. If the 

backup directory is also in the same partition as the installation directory 

and the combined space is greater than the available space, you may get an 

error message indicating a space problem. The message may show the 

available space for the /tmp partition and not for the install partition. 

To fix this issue, move the backup directory to another partition other than 

the install directory or allocate more space to the install/backup partition. 

Problem: Insufficient disk space message on Pre-Installation Summary panel 

If you get this message indicating that you need more disk space, you 

need to free up disk space before you continue with the installation. 

Insufficient disk space found for installation target 

Do not proceed with the install until after you free up disk space. Even 

if the Install button is enabled, the installation may fail. 

Do the following based on the type of installation: 

1. Free up at least 3 GB of space on the drive on where you want to 

install TBSM 

2. If you are running an upgrade installation, free up at least 3 GB of 

space on the backup destination drive 

3. Click Previous on the Pre-Installation Summary panel to return to the 

WebSphere Information panel. 

4. Click Next to proceed to the Pre-Installation Summary panel. 

Troubleshooting installation issues 257

The Insufficient disk message should now be gone, as long as you have at 

least 3 GB available in both destinations. At this point, you can click Install 

to proceed with the installation. 

Problem: Not enough space message on Pre-Installation Summary panel 

The following message appears on the pre-install summary panel: 

Not enough space. Required: 360 Available: 0 

Cause 

The deployment plan has been corrupted. 

You may also get tmp space error messages if you have a file 

or directory named /tmp/tmp. The installation will fail if you have such a 

directory or file. 

Resolution: 

Stop and restart the installer. 

Remove the file or directory named /tmp/tmp before you 

restart the installer. 

Problem: tmp space errors and installation fails 

You get tmp space error messages and the installation fails. 

Cause 

If you have a file or subdirectory named /tmp/tmp, the installation will fail. 

Resolution: 

Remove the file or subdirectory named tmp from the /tmp 

directory before you restart the installer. 

Problem: On the panel that asks for Windows Username and Windows Password 

to create a TBSM Database Windows service with, an error appears stating that: 

The password entered does not match the password for the given username. 

Enter a valid Username/Password combination. Even though the correct 

Username/Password combination was entered. 

Resolution: 

1. Verify that the username and password combination entered are 

correct. 

2. If they are correct, then it is possible that the password authentication 

on this panel is failing because of one of the following issues: 

a. Ensure that the Windows service Server is enabled. To do this: 

1) Click to Administrative Tools > Services > Services and 

Applications > Services. 

2) Right-click Server and click Properties. 

3) Ensure that Startup type is set to Automatic. If it is not, change 

it. 

4) Click Start. 

Problem: Install completes with the error 'Import of the schema failed' 

Resolution: 

Installation must be done by someone with a non-root user ID. The TBSM 

installation program does not support logging in as root and then 


switching from root to a different user ID. If you are logged in as root, 

logout and then login using a non-root user ID. 

Problem: Running the base installer a second time resulted in an error message 

appearing after the "Deployment Engine Initialization" panel which says: 

"Deployment Engine failed to initialize", and the installer shuts down. 

Resolution: 

To fix this problem, change to the acsi logs directory on your machine. 

v Windows: C:\Program Files\IBM\Common\acsi\logs 

v UNIX: 

– DE installed by root user ID: /var/ibm/common/acsi/logs 

– DE installed by non-root user ID: $HOME/.acsi_/logs 

v Erase the .lock* files. 

Problem: "DE initialization failed" appears when installing TBSM after viewing 

and accepting the license agreement panel. 

Cause 

This error can occur when you start the install, but then cancel out after 

DE had been backed up. 

Resolution 

You need to temporarily rename the DE backup directory and then install 

TBSM . To rename the DE backup directory, perform the following steps: 

1. Change to the backup directory. 

cd $HOME/.acsi_user 

cd C:\Program Files\IBM\Common\acsi 

or on Windows 64 bit: 

cd C:\Program Files (x86)\IBM\Common\acsi 

2. Change the file name. 

mv tbsm_bkup tbsm_bkup_old 

Rename tbsm_bkupto tbsm_bkup_old. 

Problem: On Sun Solaris zones sparse machine, installing as a root user, the DE 

installation fails. 

Resolution 

On a Sun Solaris zones sparse machine, the root user ID does not have 

permission to write to the /usr directory. This is the directory in which DE 

is installed by default. You must change the default installation directory 

by issuing the install command and specifying a directory to which you 

have write access: ./install.sh 

-DIAGLOBAL_DE_INSTALL_LOCATION=directory_name 

Problem: The command serverStatus.sh server1 -username -password 

returns that it cannot get the server status, even though the 

TIPProfile is running. 

Resolution 


1. Create an entry in the etc/hosts file for the host name of the machine 

like the following example: 

xyz.xyz.xyz.xyz 

2. Stop TIPProfile and restart it. 

Problem: DE initialization fails 

Resolution 

Look in the log files that are located at: 

v $HOME/.acsi_/logs/, as well as the normal 

TBSM log files under $HOME. 

v C:\Program Files\IBM\Common\acsi\logs\Administrator, 

as well as the normal TBSM log files under C:\Documents and 

Settings\Administrator. 

Backing up TBSM on a Network File System (NFS) drive 

You can manually back up IBM Tivoli Business Service Manager(TBSM) on a 

Network File System (NFS) drive. 

Procedure 

1. Stop the TBSM Server. 

2. Create a directory that is called TBSM61_BACKUP on the NFS drive. For example, 

//TBSM_BACKUP. 

3. Back up the deployment engine (DE). 

a. Open the user home directory. 

b. Go to the .asci_/bin directory. 

c. Use the following command to back up the DE: 

./de_backupdb -bfile ///IMPACT_DE.backup 

For example: 

./de_backupdb -bfile /nfs_drive/TBSM61_BACKUP/IMPACT_DE.backup 

4. Copy the installation directory, that is the directory where you installed TBSM, 

to the backup directory on the NFS drive. For example, copy the 

/opt/IBM/tivoli directory to /nfs_drive/TBSM61_BACKUP. 


After you back up TBSM, you may want to run the installer without running the 

back up. To run the installer without running the back up, go to the installation 

image directory, that is the source directory where you installed TBSM from, and 

run the appropriate command for your operating system. 

v For Windows operating systems, use the following command: 

setup-windows.exe -DNO_BACKUP=true 

v For Linux operating systems, use the following command: 

./setup-linux.bin -DNO_BACKUP=true 

Installation fails on host with existing Netcool/OMNIbus 

The TBSM installation fails on a host where a stand-alone instance of 

Netcool/OMNIbus is installed. 


Symptoms 

The TBSM server installation fails during the early installation steps. This error 

occurs only when the Netcool/OMNIbus instance needs a fix pack that is required 

for TBSM. 

Cause 

The TBSM installation program cannot install the fix pack, since it cannot stop the 

Netcool/OMNIbus ObjectServer. 

Solution 

To resolve this issue: 

1. Before you attempt to install the TBSM server, stop the ObjectServer 

2. Install the TBSM server. The installation will fail again after the 

Netcool/OMNIbus fix pack is installed, since the ObjectServer does not start. 

3. Start the ObjectServer. 

4. Install the TBSM server. The installation completes, since the fix pack was 

installed in the previous attempt. 

. 

Installation fails on new version of Tivoli Integrated Portal 

The TBSM installation fails on an existing instance of Tivoli Integrated Portal. 

Symptoms 

The TBSM installation fails when you attempt to deploy on an existing,Tivoli 

Integrated Portal whose version is higher than release 2.2.0.3 fix pack. 

Cause 

The TBSM installation program checks for the 2.2.0.3 FP version of Tivoli 

Integrated Portal. If you attempt to install on higher version, the installation fails 

on the step that validates the Tivoli Integrated Portal version. 

Solution 

Bypass the Deployment Engine validation of the Tivoli Integrated Portal version 

and remove all references to TIP2.2.0.3 in deployment plan file as follows: 

1. Locate the deployment plan file in installer image: 

TBSMGA_image/TBSM/COI/DeploymentModel.xml 

2. Comment out or remove all references to TIPFP2.2.0.3 in the file, which 

includes the sections: 

 

 

 

Database configuration utility issues 

These topics describe issue with the Database configuration utility. 

Database configuration installer fails 

Symptoms 

The database configuration installer fails. 

Solution 

The database name contains invalid characters. For example, you used Chinese 

characters in the name. If you specify an invalid name, the database configuration 

installer will fail, but the files will still be installed. You can modify the database 

name in the properties file and re-run tbsm_db script after installation to complete 

the database creation. Otherwise, uninstall the tool, and re-install specifying a valid 

database name. Valid characters for names: 

v A through Z. When used in most names, characters A through Z are converted 

from lowercase to uppercase. 

v 0 through 9. 

v !%(){}.-^~_(underscore) @, #, $, \ (backslash), and space. 

For more information about valid characters for DB2 names, see the documentation 

for the version of DB2 you are using here: 

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic= 

%2Fcom.ibm.db2.udb.doc%2Fdoc%2Ft0021844.htm 

TBSM database install fails when user id contains a hyphen 

Symptoms 

When you install the TBSM Database, the database user name you specify must 

not have a hyphen (-)inthename, otherwise some of the SQL is likely to fail. 

Cause 

The TBSM database does not recognize a user id containing a hyphen. 

Solution 

When you install the TBSM database, rename the Administrator user name and 

Administrators group and ensure they do not contain a hyphen. 

Russian Windows TBSM and DB2 install fails 

Russian Windows TBSM and DB2 install fails. 

Symptom 

You cannot install TBSM, DB2, or configure the DB2 databases for TBSM when you 

are logged in with a user id containing Russian characters. 


Cause 

DB2 does not recognize a user id with non-English characters. The Windows 

Administrator userid on a Russian operating system has Russian characters in the 

name. Typically, you do not have these problems in unix because the user names 

have English characters. 

Resolution 

To install DB2, rename the Russian Administrator user id and Administrators 

group to have english characters only. Log in with the renamed Administrator 

user id. Install DB2 while logged in with the renamed Administrator id. You also 

need to run the TBSM Database Configuration utility with the same renamed 

Administrator user id. 



Russian Administrator id. You must log in with a user id that was originally 



Cannot create database 

The database configuration installer disables the database creation option. 

Symptoms 

The installer does not allow you to select yes to create the database during the 

installation 

Solution 

On Windows, the installer must be run from a command window 

that has the DB2 command environment initialized. If the window being used was 

opened with db2cmd and the installer still does not allow you to select yes, then 

run the installer from a window opened with db2cwadmin. 

On UNIX, the user must have one of the following authorizations: 

SYSADM or SYSCTRL. 

Database configuration error messages 

Addressing errors when the database configuration completes. 

Symptoms 

The following message is displayed when the database configuration utility 

completes: 

The schema was not created successfully. 

Check the log for SQL errors (such as DB21034E SQL errors). 

Solution 

The database and schema was created, but the log contains DB2 error messages 

that indicate not all of the schema processing was successful. The DB21034E error is 

followed by a SQL error message. The error messages may not be problem 


dependent on your DB2 environment. Review each message following the 

DB21034E messages to determine if you need to correct your environment and 

re-execute the database configuration utility. 

For example, the following error scenario is ignored by the database configuration 

utility. It prompts for the userid and password to connect to the database it 

created. A GRANT command is issued to grant DBADM authority to that userid. If the 

specified userid is the same as the login userid, then the GRANT command results in 

a DB2 error and the SQL error SQL0554N that authorization cannot grant a privilege 

or authority to itself. This is an acceptable error message and has no effect on the 

database schema creation process. 

You should review the log file (db2_stdout.log) to determine if other DB21034E 

error scenarios are fatal. Similar to the GRANT error message, the other DB21034E 

error scenarios may not be a problem. Another acceptable error message if the 

tablespace already exists. This may occur if you previously executed the database 

configuration utility and did not drop the database before executing the utility 

again. An example of a problem is if the tablespace error message indicates that 

the system is full, and therefore could not create the tablespace. 

Tivoli Common Reporting issues 

These topics describe issue with the Tivoli Common Reporting installation. 

Tivoli Common Reporter data source issues 

Use this procedure to resolve data source connection problems. 


Check the Common Reporter log (cogserver.log) for the following details: 

TBSM_HIST_DATA UDA-SQL-0569 Unable to load the driver manager 

library (db2cli.dll). 

UDA-SQL-0571 The operating system returned an error message 

( The specified module could not be found. ). 

You can also test the connection through the Administration task of Common 

Reporting. 

1. In the upper right hand corner of the Common Reporting portlet, select Launch 

> Administration. 

2. On the Configuration tab, click Data Source Connection. 

3. Select More... for the TDW data source. 

4. Click View connections > More... > Test the connection... > TEST. 

To resolve and connection issue: 

Procedure 

1. Verify through the Common Reporting portlet that you have configured your 

data source with the correct parameters. If the parameters are wrong, delete the 

data source and add the data source with the appropriate parameters. : 

You can add the data source with the trcmd command (found in 

tcr_install/tipv2Components/TCRComponent/bin). 

trcmd -datasource 

-add TDW 

-dbType DB2 (or Oracle) 

-dbName 


-dbLogin < userID to access ITM WAREHOUSE> 

-dbPassword 

-user 

-password 

2. Verify you have rebooted the machine after you installed the DB2 (or Oracle) 

client to update the PATH environment variables with the DB2 (or Oracle) 

executables. 

3. If you have Cygwin on your machine, you need to remove /Cygwin/bin from 

the PATH variable. Your System Administrator can access the PATH variable as 

follows: System Properties --> Advanced --> Environment Variables. 

Reports do not execute. 

This topics describe issue when the Tivoli Common Reporting does not run reports 

after installation. 

Symptom 

Reports do not execute. 

Cause 

Common Reporting cannot access the data for the report because there is no 

database client installed. 

Resolution 

Verify you have installed the database client which Common Reporting requires to 

access the data. You can verify the connectivity to the datasource by launching the 

Administration task in the Common Reporting portlet. Then select 

Configuration->Data Source Connections. 

If you are executing on a UNIX system, you must source your database 

environment before starting TCR. Please see the TCR User's Guide for more 

troubleshooting details. 

Reports install fails on Solaris 

This topics describe issue when the IBM Tivoli Business Service Manager reports 

fail to install on a Solaris system.. 

Symptom 

The reports installation scripte (install_reports.sh) scripts fails on Solaris with 

bad substitution error. 

Cause 

There are errors in the script on lines 571 and 749. 

Resolution 

Open the install_reports.sh in a text editors and make these corrections: 

1. From the installation package root, change to the appropriate directory based 

on the operating system: 

introp/Reports 


Windows issues 

2. In a text editor, open the file: install_reports.sh. 

3. On line 571 find the text: 

while [ $i -le $count ] 

4. Edit the statement as shown here (additional quotes and brackets are needed). 

while [[ "$i" -le "$count" ]] 

5. On line 749 find the statement: 

while [ $i -le $count ] && [ "$RC" = "0" ] 

6. Edit the statement as shown here (additional quotes and brackets are needed). 

while [[ "$i" -le "$count" && "$RC" = "0" ]] 


8. Run the reports installation program again. 

Tivoli Common Reporting uninstall fails 

Tivoli Common Reporting uninstallation fails in a TBSM environment 

Symptoms 

You uninstall the Common Reporting version 2 release 1.1 that was installed on a 

Tivoli Integrated Portal host that has TBSM. The uninstaller fails to stop Tivoli 

Integrated Portal (not deterministic) and throws an exception. As the result, all the 

other products installed on the host malfunction, and the whole environment 

needs to be repaired by hand. The uninstaller cannot be run again, because the 

Deployment Engine contains Common Reporting entries and the program remains 

installed and running. 

Cause 

The uninstaller removes only the uninstaller itself and nothing else. 

Resolution 

The workaround for this problem is described in the Common Reporting 

Information Center for version 2.1.1. For detailed instruction, see Installing > 

Uninstalling > Uninstalling manually. 

The main page for the information centers is here: 

https://www.ibm.com/developerworks/wikis/display/tivolidoccentral/ 

Tivoli+Common+Reporting 

Windows installation issues. 

Windows Server 2008 R2 Enterprise Edition x86-64 installation 

fails during Impact Subversion (SVN) step 

When you install TBSM on a Windows 2008 Enterprise R2-64 operating system, the 

installer fails during the deployment engine Impact_SVN step. 

To correct this issue, you must install the following fix packs: 

v Microsoft Visual C++ 2008 SP1 Redistributable Package (x86): from 



v Microsoft Visual C++ 2008 SP1 Redistributable Package for (x64) from 


Attention: You must install one of the 2008 versions of Windows Server because 

other versions are not compatible with the SVN step. 

Windows installation fails 

When you install TBSM on a Windows system, the installation program fails. 

Symptoms 

The installation fails at the step: WebSphere Application Server Fix pack or Tivoli 

Integrated Portal Fix pack installation. 

Cause 

The WASServiceMsg.dll cannot stop because it is locked by the Windows event log. 

Resolution 

Stop Window service Event log, clean up the failed installation, and run the TBSM 

installation program again. 

Windows services are not uninstalled 

On Windows systems, if the Netcool/OMNIbus service or the NCO Process Agent 

service still appear in the Services window after the uninstallation process 

completes, manually remove these services. 

Procedure 

1. If Netcool/OMNIbus still appears in the services list after the uninstallation 

process is complete, type sc delete NCOObjectServer from the command line. 

The service should be removed from the list. 

2. If NCO Process Agent appears in the services list, type sc delete 

NCOProcessAgent from the command line. The service should be removed from 

the list. 

3. If “Tivoli Business Service Manager - TBSMProfile_Port_17310” still appears in 

the list of services, do the following steps: 

v If \tip\bin\WASService is still available on the machine, issue 

the following commands: 

cd \tip\bin 

run WASService -stop TBSMProfile_Port_17310 

run WASService -remove TBSMProfile_Port_17310 

v If \tip\bin\WASService is not available on the machine, do the 

following steps: 

a. Stop the service from the Services panel. 

b. Issue the following command: 

sc delete "IBMWAS70Service - TBSMProfile_Port_17310" 

4. If “Tivoli Integrated Portal - V2.2_TIPProfile_Port_16310” still appears in the list 

of services on the machine and all Tivoli Integrated Portal products have been 

removed, do the following steps: 

CAUTION: 

Ensure that all Tivoli Integrated Portal-based products have been removed 

before removing this service. 


v If \tip\bin\WASService is still available on the machine, issue 

the following commands: 

cd \tip\bin 

run WASService -stop V2.2_TIPProfile_Port_16310 

run WASService -remove V2.2_TIPProfile_Port_16310 

v If \tip\bin\WASService is not available on the machine, do the 

following steps: 

a. Stop the service from the Services panel. 

b. Issue the following command: 

sc delete "IBMWAS70Service - V2.2_TIPProfile_Port_16310" 

RAD shell issue connecting to the Data server 

By default, you cannot use an ! (exclamation) character in the tipadmin password 

on Windows systems. It results in errors in the TBSM trace logs and the Rad Shell 

does not connect to the Data server. This topic outlines how to encrypt the 

tipadmin passwords that contain an ! character. 

Symptoms 

You cannot connect to the Data server using Rad Shell and no Rad Shell prompt is 

displayed. An error is created in the TBSM trace logs: 

com.ibm.ws.wim.adapter.file.was.FileAdapter login 

com.ibm.websphere.wim.exception.PasswordCheckFailedException: 

CWWIM4512E The password match failed. 

Note: This issue does not occur when you log in from the TBSM user interface. 

Cause 

This is a limitation in the use of the ! character in Windows batch programming. 

Resolution 

To ensure that the correct encryption is generated for the tipadmin password when 

it contains an ! (exclamation) character, use the nci_crypt command, located in the 

$TBSM_HOME/bin directory, to generate the encrypted password and escape the ! 

character with a ^ character. For example, to encrypt a password, t!padm!m, execute 

the command: 

nci_crypt "t^!padm^!n" 

Add the output of this command as the value for property 

impact.server.vmm.admin.password in the property files in $TBSM_HOME/etc.. 

Dashboard server 

v $TBSM_HOME/etc/server.props 

v $TBSM_DASHBOARD_SERVER_HOME/etc/RAD_sla.props 

Data server 

$TBSM_HOME/etc/server.props 


Dashboard server cannot connect to the Data server on Linux 

On Linux systems, if the Dashboard server cannot connect to the Data server, the 

host name of the machine might be using the loopback address 127.0.0.1. 


To correct this problem, perform the following steps: 

Procedure 

1. Do one of the following actions to each machine on which a Data server or 

Dashboard server is installed: 

Ensure that the host name in the /etc/hosts file uses the IP address 9.x.x.x 

instead of the loopback address 127.0.0.1. 

Modify the hosts line in the /etc/nsswitch.conf file so that DNS (dns is 

accessed before local files files). 

2. Restart all TBSM components. You must restart the Data server, the Dashboard 

server, and OMNIbus. 

ILOG exceptions when displaying service viewer or event summary 

applets after upgrading to TBSM 

If you encounter errors displaying the Service Viewer or Event Summary applets 

after installing or upgrading TBSM, you might have to remove cached versions of 

code from earlier versions of the product. Typically, these files are automatically 

updated on the server when they change. 

If you see ILOG exceptions, the following procedure typically fixes the problem: 

1. Exit all browser sessions. 

2. Restart the browser. 

3. Reconnect to TBSM. 

If the problem is not fixed, use the Java Control Panel program to clear the Java 

applet cache. The exact procedure depends on the platform, and the Java version 

in use. If you have more than one JVM installed and you are not sure which one is 

being used by the browser plug-in, perform the procedure for each JVM. 

Initialization of load balance database fails 

If initialization of a new load balance database fails, the database might not be 

empty. Use the following procedure to correct this issue. 


Ensure that the Load Balance database and schema have been created using the 

Load Balancing scripts provided on the installation DVD. If you are using an 

existing Load Balance database, select the installation option to not initialize the 

Load Balance database. If initialization of a new Load Balance database fails, the 

database was not empty. 


Use the following procedure to correct the problem: 


Procedure 

1. Stop the TBSM suite using the tbsm_suite stop command. 

2. Drop the Load Balancing database. 

a. Log on to the database host as the instance owner. 

b. Execute a drop database command for the Tivoli Integrated Portal database 

(for example, drop db tipdb). 

3. Create the tipdb database using the Load Balancing script tipMakedb, as a shell 

or .bat file (for example, tipmakedb.sh tipdb). 

4. Run the following command: $TIP_HOME/profile/TIPProfile/bin/ws_ant.sh -f 

$TIP_HOME/bin/ha/install.ant install -Dusername= -Dpassword= -Dadminuser= -Dadminpass= 

5. Verify that a successful ANT build is displayed. 

6. Start TBSM using $TBSM_HOME/bin/tbam_suite.sh or tbsm_suite.bat. 

Clearing the Java plug-in cache on Windows 


1. Open Control Panel and click IBM Control Panel for Java to launch the Java 

Control Panel program. 

2. On the General tab, click Delete Files in the Temporary Internet Files section 

at the bottom of the panel. 

3. On the Delete Temporary Files window that opens, ensure that Downloaded 

Applets is checked. 

4. Click OK. 

5. Click Cancel to close the Java Control Panel program. 

Clearing the Java plug-in cache on UNIX 


1. Launch the Java Control Panel program by running $JAVA_HOME/jre/bin/ 

ControlPanel from a shell prompt. 

2. On the General tab, click Delete Files in the Temporary Internet Files section 

at the bottom of the panel. 

3. On the Delete Temporary Files window that opens, ensure that Downloaded 

Applets is checked. 

4. Click OK. 

5. Click Cancel to close the Java Control Panel program. 

WebSphere Business Events v6.1 fails to launch 

On Red Hat Enterprise Linux 5, the default settings have been known to prevent 

Java v.5 from running properly. WebSphere Business Events v6.1 bundles Java 5 

and uses it to launch the installer. 


Diagnosing the problem 



Use the following steps to recreate the error: 

Procedure 

1. Launch the WebSphere Business Events installer: # ./install.bin 

2. The following items are displayed: 

a. Preparing to install 

b. Extracting the JRE from the installer archive 

c. Unpacking the JRE 

d. Extracting the installation resources from the installer archive 

e. Launching the installer Invocation of this Java application has caused an 

InvocationTargetException. This application will now exit. Stack Trace: 

java.lang.NoClassDefFoundError: 

com.zerog.ui.gui.liteweight.ZGGridBagContainer 

Resolving the problem: 

There are two solutions available: 

v Temporarily disable SELinux by using the setenfource 0 command. Run the 

install the enable SELinux by using the setenforce 1 command. 

v Edit the ?/etc/selinux/config file and set SELINUX to either permissive or 

disabled. Restart the machine. 

Note: This solution affects the level of security for the entire system. 

Default TBSM groups not created during the installation process 

This topic describes how to manually create TBSM groups and assign roles. 

Symptoms 

Default TBSM groups are not created during installation. 

Resolution 

Completing the following procedure: 

1. Go to $TBSM_HOME/bin. 

2. Run the following commands to create TBSM groups: 

a. ./vmm_create_entities.sh 

b. ./vmm_create_entities.bat 

3. For file-based authentication, run the following command: 

./vmm_create_entities.sh tipadmin tippass "o= 


4. For OMNIbus authentication, run the following command: 

./vmm_create_entities.sh "o=netcoolObjectServerRepository" "o=netcoolObjectServerRepository" 

5. For LDAP, use the LDAP user and group suffixes, such as ou=tivoli, dc=ibm, 

dc=com. 


6. Run the following command to assign roles to the created group: 

a. ./assign_group_roles.sh tipadmin tippass 

b. assign_group_roles.bat tipadmin tippass 

Netcool/OMNIbus install fails on SuSE with ssh access 

Using an SSH session to install TBSM on some versions of SUSE Linux can result 

in a problem during the Netcool/OMNIbus. 

Symptoms 

The install fails at Netcool/OMNIbus install step on SUSE Linux when ssh is used 

to access the machine. 

The log $HOME/IA-Netcool-Omnibus.log shows: 

data/time STDERR: 

com.ibm.ac.si.tpreg.TpregRegistrationFailedException: ACUTRI0024E An error occur red 

registering the Managed Resource Properties for the resource type OSRT:PalmOS. 

Cause 

Caused by Deployment Engine and Java issues: 

1. When you run locally, the hostname will be tried to pick from the cache first and 

in this case hostname is displayed from the cache. Platform like Solaris does not 

want to give us a fully qualified domain name. Even it is the same case happening 

in SUSE linux. That is the reason why you are seeing only short name without 

in.ibm.com when you run locally. But java always try to give fully qualified 

domain name by doing reverse lookup. This will happen only when the hostname 

is resolved through DNS. Resolution of hostname through DNS is not happened 

when you ran locally because hostname is already picked from cache. 

2. But when you run from remote machine through ssh the name resolution for 

hostname will happen through DNS. So Java tries to return fully qualified domain 

name even if platform like Solaris, SUSE linux, etc does not want to give fully 

qualified domain name. Java does a reverse lookup and tries to pick the hostname 

from /etc/hosts file inorder to give fully qualified domain name. You can edit 

/etc/hosts file and change xx.in.ibm.com to xx. Then through ssh ,only short 

name is found. However, it is not recommended to change the default setting of 

/etc/hosts file. 

Resolution 

Place short name of the host in /etc/hosts file. 

TBSM server fails after Netcool/Impact install/migration 

If you install and migrate another Netcool/Impact server on a TBSM server host, 

the TBSM server can fail. 

Symptoms 

The TBSM Data or Dashboard server fails after you install and migrate another 

Netcool/Impact server. 


Cause 

TBSM and Netcool/Impact share a common keystore configuration file and the 

TBSM file was over written by Netcool/Impact. You need to follow the guidelines 

in the Planning section of this guide before you attempt to install Netcool/Impact 

on a TBSM server host. 

Resolution 

Copy the keystore file that was backed up during Netcool/Impact migration to the 

TBSM_HOME/etc directory and update property impact.keystore.location in 

TBSM_HOME/etc/TBSM_server.props to point to the new location. 

Separating the Data server and Dashboard server with a firewall 

If the Data server and Dashboard server are separated by a firewall, the connection 

between the servers is completed on a random port. If the firewall does not allow 

the connection. The Dashboard server does not initialize correctly and status and 

configuration changes are not sent to the Dashboard server. 

Symptoms 

An error message is displayed: 

Connection refused to host: 

In addition, a message similar to this is added to the Data server logs: 

updatepublish 1 com.micromuse.sla.updatepublisher.ClientUpdate 

HandlerThread run ENTER^ERROR WRITING to client 

:17543 we will remove this client updater. 

Connection refused to host: ; nested exception is: 

java.net.ConnectException: Connection timed out. 

The error message displays the port of the RMI registry, even if the communication 

fails when it is running RMI stubs using a different port. This can be misleading as 

netstat might display an established connection to port 17543. However, TBSM fails 

to run RMI stubs on a random port. 

Causes 

The RMI registry port is defined by the parameter: impact.server.rmiport. Onthe 

Data server this has a default value of 17542 and is stored in $TBSM_HOME/etc/ 

TBSM_server.props. On the Dashboard server this has a default value of 17543 and 

is stored in $TIP_HOME/profiles/TIPProfile/installedApps/TIPCell/isc.ear/ 

sla.war/etc/RAD_server.props. By default, a random port is used when the 

running RMI stubs on a remote server. This can cause issues when a firewall is 

present between the servers and the random port is blocked. 

Resolution 

If a firewall exists between the Data server and the Dashboard server, you might 

have to open and specify the server port used to run RMI stubs. To specify this 

port: 

1. On the Data server, locate the file: $TBSM_HOME/etc/TBSM_server.props. 

2. Using a text editor, open and edit the file to add the lines: 

impact.rmiPortRangeStart=17544 

impact.rmiPortRangeEnd=17544 


3. On the Dashboard server, edit the $TIP_HOME/profiles/TIPProfile 

/installedApps/TIPCell/isc.ear/sla.war/etc/RAD_server.props to add the 

lines: 

impact.rmiPortRangeStart=17544 

impact.rmiPortRangeEnd=17544 

Note: 17544 is a suggested port, use a different free port value where required. 

You can also use a range of more than 1 port if required for your 

Netcool/Impact configuration. The port you choose must be different to the 

impact.server.rmiport which is used for the RMI registry. 


Reference 

Log files that TBSM uses 

Reference information is organized to help you locate particular facts quickly. 

On both UNIX and Windows systems, TBSM log files are located in the 

installDir/tbsm/logs/logs.zip directory. 

Table 17 lists the types of logs used by TBSM, the locations of the log files, and the 

names of the log files. 

All log files are within installDir/tbsm/logs/install unless otherwise noted. 

Table 17. Log files used by TBSM 

Type of log Log files 

OMNIbus_SilentInstall omniInstall.out|errr 

InstallOMNIbus fixpack OMNIbusFPInstall.out|err 

OMNIbus_Configure omniConfig.out|err 

omniStart.out|err 

omniCheck.out|err 

EIFProbe_SilentInstall probeInstall.out|err 

EIF Probe_Configure probeService.out|err 

omniProbeConfig.out|err 

TBSM_SVN_Install svnadmin.out|err 

TBSM_eWASProfile createSymbolicLinks.out 

createTBSM_Profile.out|err 

jvm.out|err 

importTBSM_Profile.out|err 

startTBSM_Server.out 

createTBSM_Service.out|err 

modifyWASServiceName.out|err 

setStartBean.out|err 

StartWAS_TBSMProfile_* startWAS.out|err 

checkWAS.out 

TBSM_NameServer_Install setMultiHostsPorts.out|err 

setNameServerProps.out|err 

create_name_server.out|err 

StopWAS_TBSMProfile_* stopServer.out|err 

checkWAS2.out|err 

TBSM_PostProfileConfig startsvn.out|err 

patch_server.out|err 

create_new_server.out|err 

retrieveSigners.out|err 

addTBSMProfileAdminUser.out|err 

secureTBSMear.out|err (secureTBSM_Bear.out|err) 

TBSM_DataSvr_Import runNciImport.out|err 

setSharedLib.out|err 

stopServer.out|err 


Table 17. Log files used by TBSM (continued) 

Type of log Log files 

TBSM_DataSvr_Install setTraceLevel-TBSMProfile.out|err 

loadCfgDb.out|err 

setSharedLib.out|err 

TWA_Marker deployTWAMarkerEar.out|err 

addDataAdminUser.out|err 

secureTWAmarker.out|err 

setTraceLevel-TWA1.out|err 

setTraceLevel-TWA2.out|err 

twaStartEWAS.out|err 

twaStopEWAS.out|err 

TBSM_VMMObjectServerPlugin cfgTIPRealm.out|err 

registerNCOSVMMInWAS-TBSMProfile.out 

TBSM_InstallTIPFP TIPFPInstall.out|err 

ImpactCore netcoolwar.out|err 

setNameServerPropsgui.out|err 

create_gui_server_wars.out|err 

jvmTIP.out|err 

NameServerPostConfig setNameServerPropsgui.out|err 

StopWAS_TIPProfile_* stopServer.out|err 

checkWAS.out 

StartWAS_TIPProfile_* startServer.out|err 

checkWAS.out 

TBSMCore deployTBSMSlaWar.out|err 

setjvmargs.out|err 

setTraceLevel-TIPProfile.out|err 

setupdashboardserver.out|err 

TWA deployTwaWar.out|err 

BSMPostConfig propagateTIPRolesGUISERVER.out|err 

TBSMCorePostConfig chartConnection.out|err 

propagateRoles.out|err 

addTBSMgroups_assignRoles.out|err 

addTBSMgroups_createEntities_file.out|err 

addTBSMgroups_createEntities_omni.out|err 

createWebGUIViews.out|err 

TBSM_DataSvr_PostStart templates.out|err 

Log files generated by the installation of Discovery Library Toolkit 

The Discovery Library toolkit generates a single install log, IA_TBSMDL_Install6.1- 

00.log. 

On Unix systems this file is written to the user's home directory. 

On Windows systems this file is written to the user's Documents and 

Settings directory. 

In earlier releases of the toolkit, individual files were written to the 

$TBSM_HOME/log/install directory. The information that was written to these 


Sample response file 

individual files is now written to IA_TBSMDL_Install6.1-00.log. Additional 

information for post-install steps may be found in 

$TBSM_HOME/log/msgGTM_CI.log.0 or 

$TBSM_HOME/log/traceGTM_CI.log.0. 

The TBSM product DVD also includes these pre-filled response files in the TBSM 

directory: 

setup.rsp 

Response file for the TBSM main installation program 

dbconfig-installer.properties 

The sample response file for the database configuration utility is located in 

the /operatingSystem/DbConfig directory. 

Tivoli Integrated Portal overview 

Web-based products built on the Tivoli Integrated Portal framework share a 

common user interface where you can launch applications and share information. 

Tivoli Integrated Portal helps the interaction and secure passing of data between 

Tivoli products through a common portal. You can launch from one application to 

another and within the same dashboard view research different aspects of your 

managed enterprise. 

Tivoli Integrated Portal is installed automatically with the first Tivoli product using 

the Tivoli Integrated Portal framework. Subsequent products may install updated 

versions of Tivoli Integrated Portal. 

Tivoli Integrated Portal provides the following features: 

v A Web based user interface for individual products and for integrating multiple 

products. 

v A single, task-based navigation panel for multiple products. Users select actions 

based around the task that they want to complete, not by the product that 

supports that task. 

v Single sign-on (SSO), consolidated user management, and a single point of 

access for different Tivoli applications. 

v Aggregated views that span server instances, such as the Tivoli 

Netcool/OMNIbus ObjectServer and Tivoli Enterprise Portal Server. 

v Inter-view messaging between products to support contextual linkage between 

applications. 

v The ability to create customized pages and administer access to content by user, 

role, or group. 

Accepting the security certificate 

When logging in, you might see a security alert with a message that says there is a 

problem with the security certificate. This indicates that the browser application is 

verifying the security certificate of the application server. 

Reference 277

Self-signed or CA-signed certificate 

The application server uses a self-signed security certificate. You might see a 

Security Alert when you first connect to the portal that alerts you to a problem 

with the security certificate. You might be warned of a possible invalid certificate 

and be recommended to not log in. 

Although this warning appears, the certificate is valid and you can accept it. Or, if 

you prefer, you can install your own CA-signed certificate. For information on 

creating your own CA-signed certificate, go to: http://publib.boulder.ibm.com/ 

infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ 

ae/tsec_sslcreateCArequest.html 

For more information about certificates, go to the IBM WebSphere Application 

Server Community Edition Documentation Project at http:// 

publib.boulder.ibm.com/wasce/V2.1.1/en/overview.html, and search for Managing 

trust and Managing SSL certificates. 

Logging in 

Log in to the portal whenever you want to start a work session. 


The Tivoli Integrated Portal Server must be running before you can connect to it 

from your browser. 


Complete these steps to log in: 

Procedure 

1. In a Web browser, enter the URL of the Tivoli Integrated Portal Server: 

http://host.domain:16310/ibm/console or https://host.domain:16311/ibm/ 

console if it is configured for secure access. 

v host.domain is the fully qualified host name or IP address of the Tivoli 

Integrated Portal Server (such as MyServer.MySubdomain.MyDomain.com or 

9.51.111.121, or localhost if you are running the Tivoli Integrated Portal 

Server locally). 

v 16310 is the default nonsecure port number for the portal and 16311 is the 

default secure port number. If your environment was configured with a port 

number other than the default, enter that number instead. If you are not sure 

of the port number, read the application server profile to get the correct 

number. 

v ibm/console is the default path to the Tivoli Integrated Portal Server, 

however this path is configurable and might differ from the default in your 

environment. 

2. In the login page, enter your user ID and password and click Log in. This is 

the user ID and password that are stored with the Tivoli Integrated Portal 

Server. 


Attention: After authentication, the web container used by the Tivoli 

Integrated Portal Server redirects to the last URL requested. This is usually 

https://:/ibm/console, but if you manually change the page 

URL, after being initially directed to the login page, or if you make a separate 

request to the server in a discrete browser window before logging in, you may 

be redirected unexpectedly. 

Note: If you have more than one instance of the Tivoli Integrated Portal Server 

installed on your computer, you should not run more than one instance in a 

browser session, that is, do not log in to different instances on separate browser 

tabs. 

Results 

After your user credentials have been verified, the Welcome page is displayed. If 

you entered the localhost or port number incorrectly, the URL will not resolve. 

View the application server profile to check the settings for localhost, port, and 

user ID. 


Select any of the items in the navigation tree to begin working with the console. 

While you are logged into the Tivoli Integrated Portal Server, avoid clicking the 

browser Back button because you will be logged out automatically. Click Forward 

and you will see that your are logged out and must resubmit your credentials to 

log in again. 

Note: If you want to use single sign-on (SSO) then you must use the fully 

qualified domain name of the Tivoli Integrated Portal host. 


“Viewing the application server profile” on page 280 

Open the application server profile to review the port number assignments and 

other information. 

“Configuring access for HTTP and HTTPS” on page 326 

By default, the application server requires HTTPS (Hypertext Transfer Protocol 

Secure) access. If you want some users to be able to log in and use the console 

with no encryption of transferred data, including user ID and password, configure 

the environment to support both HTTP and HTTPS modes. 

Port assignments 

The application server requires a set of sequentially numbered ports. 

The sequence of ports is supplied during installation in the response file. The 

installer checks that the number of required ports (starting with the initial port 

value) are available before assigning them. If one of the ports in the sequence is 

already in use, the installer automatically terminates the installation process and 

you must specify a different range of ports in the response file. 

Reference 279


“Viewing the application server profile” 




Port number settings in WebSphere Application Server versions 

Many port values in Tivoli Integrated Portal are different. 

Viewing the application server profile 




The profile of the application server is available as a text file on the computer 

where it is installed. 

Procedure 

1. Locate the tip_home_dir/profiles/TIPProfile/logs directory. 

2. Open AboutThisProfile.txt in a text editor. 

Example 

This is the profile for an installation on in a Windows environment as it appears in 

tip_home_dir\profiles\TIPProfile\logs\AboutThisProfile.txt: 

Application server environment to create: Application server 

Location: C:\IBM\tivoli\tipv2\profiles\TIPProfile 

Disk space required: 200 MB 

Profile name: TIPProfile 

Make this profile the default: True 

Node name: TIPNode Host name: tivoliadmin.usca.ibm.com 

Enable administrative security (recommended): True 

Administrative consoleport: 16315 

Administrative console secure port: 16316 

HTTP transport port: 16310 

HTTPS transport port: 16311 

Bootstrap port: 16312 

SOAP connector port: 16313 

Run application server as a service: False 

Create a Web server definition: False 


If you want to see the complete list of defined ports on the application server, you 

can open tip_home_dir/properties/TIPPortDef.properties in a text editor: 


#Mon Oct 06 09:26:30 PDT 2008 














“Port assignments” on page 279 



“Logging in” on page 278 





Backing up and restoring the Deployment Engine 

Use the Deployment Engine (DE) backup script before installing additional 

components or other products that are based on the Tivoli Integrated Portal 

platform. If you need to recover the original configuration after a failure, you can 

then run the Deployment Engine restore script. 


The Deployment Engine performs the installation of new and upgraded products. 

It keeps track of the installed components and skips installing a given component 

if it is already present on the system. Perform the following steps to back up or 

restore the DE database. 

Procedure 

1. From the command line, change to the acsi directory: 

v cd C:\Program Files\IBM\Common\acsi 

v For Linux and UNIX-based systems, the path to 

the acsi directory varies depending on whether you are installing as root or 

as a non-root user, as follows: 

– Installing as a non-root user, the path is relative to the user's home 

directory: 

/.asci_ 

– Installing as root, the path is as follows: 

/var/ibm/common/asci 

2. Initialize the Deployment Engine environment from the command line: 

v setenv.bat 

v . setenv.sh 

3. Change to the bin directory: 

v Change to the bin child directory, that is: 

C:\Program Files\IBM\Common\acsi\bin 


the bin directory varies depending on whether you are installing as root or 


– For a non-root user, change to the bin child directory, that is: 

/.asci_/bin 

– For root, the path is as follows: 

/usr/ibm/common/asci/bin 

4. Run the backup script to back up the Deployment Engine database, as follows: 

Reference 281

v de_backupdb.cmd 

v de_backupdb 

5. If you need to restore the Deployment Engine database, from the bin directory 

run the restore script: 

v de_restoredb.cmd 

v de_restoredb 


If you backed up the Deployment Engine database, you can run the installer now 

to add additional components or products. If you restored the Deployment Engine 

database, you can resume using the original installed environment. 

Configuring 

Once you have installed Tivoli Integrated Portal, you can configure it to operate in 

a variety of ways, for example, you can enable load balancing and employ a 

central user repository. 

Adding an external LDAP repository 

After installation, you can add an IBM Tivoli Directory Server or Active Directory 

Microsoft Active Directory Server as an LDAP repository for Tivoli Integrated Portal. 


To add a new LDAP repository: 

Procedure 


2. In the navigation pane, click Settings > Websphere Admin Console and click 

Launch Websphere Admin Console. 

3. In the WebSphere Application Server administrative console, select Security > 

Global security. 

4. From the Available realm definitions list, select Federated repositories and 

click Configure. 

5. In the Related Items area, click the Manage repositories link and then click 

Add to add a new LDAP repository. 

6. In the Repository identifier field, provide a unique identifier for the 

repository. The identifier uniquely identifies the repository within the cell, for 

example, LDAP1. 

7. From the Directory type list, select the type of LDAP server. The type of 

LDAP server determines the default filters that are used by WebSphere 

Application Server. 

Note: IBM Tivoli Directory Server users can choose either IBM Tivoli 

Directory Server or SecureWay as the directory type. For better performance, 

use the IBM Tivoli Directory Server directory type. 

8. In the Primary host name field, enter the fully qualified host name of the 

primary LDAP server. The primary host name and the distinguished name 

must contain no spaces. You can enter either the IP address or the domain 

name system (DNS) name. 

9. In the Port field, enter the server port of the LDAP directory. 


The host name and the port number represent the realm for this LDAP server 

in a mixed version nodes cell. If servers in different cells are communicating 

with each other using Lightweight Third Party Authentication (LTPA) tokens, 

these realms must match exactly in all the cells. 

Note: 

The default port value is 389, which is not a Secure Sockets Layer (SSL) 

connection port. Use port 636 for a Secure Sockets Layer (SSL) connection. For 

some LDAP servers, you can specify a different port. If you do not know the 

port to use, contact your LDAP server administrator. 

10. Optional: In the Bind distinguished name and Bind password fields, enter 

the bind distinguished name (DN) (for example, cn=root) and password. 

Note: The bind DN is required for write operations or to obtain user and 

group information if anonymous binds are not possible on the LDAP server. 

In most cases, a bind DN and bind password are needed, except when an 

anonymous bind can satisfy all of the required functions. Therefore, if the 

LDAP server is set up to use anonymous binds, leave these fields blank. 

11. Optional: In the Login properties field, enter the property names used to log 

into the WebSphere Application Server. This field takes multiple login 

properties, delimited by a semicolon (;). For example, cn. 

12. Optional: From the Certificate mapping list, select your preferred certificate 

map mode. You can use the X.590 certificates for user authentication when 

LDAP is selected as the repository. 

Note: The Certificate mapping field is used to indicate whether to map the 

X.509 certificates into an LDAP directory user by EXACT_DN or 

CERTIFICATE_FILTER. If you select EXACT_DN, the DN in the certificate must 

match the user entry in the LDAP server, including case and spaces. 

13. Click OK. 

14. In the Messages area at the top of the Global security page, click the Save link 

and log out of the WebSphere Application Server console. 


Configure the Tivoli Integrated Portal Server to communicate with an external 


Reference 283


“Single sign-on” on page 290 

The single sign-on (SSO) capability in Tivoli products means that you can log on to 

one Tivoli application and then launch to other Tivoli Web-based or Web-enabled 

applications without having to re-enter your user credentials. 


“Configuring SSO between Charting and Tivoli Monitoring” on page 337 

The instructions below describe how to configure IBM Tivoli Monitoring and 

Charting for single sign on (SSO) using the ITMWebService. At the bottom are also 

instructions for how to configure Tivoli Integrated Portal to communicate with a 

remote Tivoli Monitoring Web Service, which only works in an SSO environment. 

“Configuring single sign-on” on page 291 

Use these instructions to establish single sign-on support and configure a federated 

repository. 

“Changing passwords” on page 345 

You can use the Change Your Password portlet to change your password from the 

default provided by the administrator. 

Configuring an external LDAP repository 

You can configure the Tivoli Integrated Portal Server to communicate with an 

external LDAP repository. 


In a load balanced environment, all Tivoli Integrated Portal Server instances must 

be configured separately for the LDAP server. To configure an application server to 

communicate with an external LDAP repository: 

Procedure 

1. Log in to Tivoli Integrated Portal. 


and click Launch Websphere Administrative Console. 





5. To add an entry to the base realm: 

a. Click Add Base entry to Realm. 

b. Enter the distinguished name (DN) of a base entry that uniquely identifies 

this set of entries in the realm. This base entry must uniquely identify the 

external repository in the realm. 

Note: If multiple repositories are included in the realm, use the DN field to 

define an additional distinguished name that uniquely identifies this set of 

entries within the realm. For example, repositories LDAP1 and LDAP2 

might both use o=ibm,c=us as the base entry in the repository. So 

o=ibm,c=us is used for LDAP1 and o=ibm2,c=us for LDAP2. The specified 

DN in this field maps to the LDAP DN of the base entry within the 

repository (such as o=ibm,c=us b). The base entry indicates the starting 

point for searches in this LDAP directory server (such as o=ibm,c=us c). 

c. Click OK. 

d. In the Messages area at the top of the Global security page, click the Save 

link and log out of the WebSphere Application Server console. 





click Set as current to mark the federated repository as the current realm. 












9. Verify that the federated repository is correctly configured: 

a. In the portal navigation pane, click Users and Groups > Manage Users. 

b. Select User ID from the Search by list. 

c. Click Search to search for users in the federated repository. 

d. Confirm that the list includes users from both the LDAP repository and the 

local file registry. 

On the Tivoli Integrated Portal Server, LDAP users are queried only by the 

userid attribute. When users are imported into LDAP using an LDAP Data 

Interchange Format (LDIF) file, an auxiliary class of type eperson and an uid 

attribute is added to the LDAP user ID. Note that this is to be done only if you 

want to search the LDAP repository using VMM from the server. 


To be able to create or manage users in the portal that are defined in your LDAP 

repository, in the WebSphere Application Server administrative console, you must 

specify the supported entity types. 







Managing LDAP users in the console 

To create or manage users in the portal that are defined in your LDAP repository, 

in the WebSphere Application Server administrative console specify the supported 

entity types. 


To create or manage LDAP users in the portal: 

Reference 285

Procedure 








5. In the Additional Properties area, click Supported entity types, to view a list 

of predefined entity types. 

6. Click the name of a predefined entity type to change its configuration. 

7. In the Base entry for the default parent field, provide the distinguished name 

of a base entry in the repository. This entry determines the default location in 

the repository where entities of this type are placed on write operations by 

user and group management. 

8. In the Relative Distinguished Name properties field, provide the relative 

distinguished name (RDN) properties for the specified entity type. 

Possible values are cn for Group, uid or cn for PersonAccount, and o, ou, dc, 

and cn for OrgContainer. 

Delimit multiple properties for the OrgContainer entity with a semicolon (;). 

9. Click OK to return to the Supported entity types page. 



11. For the changes to take effect, stop, and restart the Tivoli Integrated Portal 

Server. In a load balanced environment, you must stop and restart each Tivoli 

Integrated Portal Server instance. 


a. In the tip_home_dir/profiles/TIPProfile/bin directory, depending on 

your operating system, enter one of the following commands: 





b. In the tip_home_dir/profiles/TIPProfile/bin directory, depending on 


Results 



You can now manage your LDAP repository users in the portal through the Users 

and Groups > Manage Users menu items. 

Note: When you add a new user, you should check that the user ID you specify 

does not already exist in any of the user repositories to avoid difficulties when the 

new user attempts to log in. 


Restriction: You cannot currently update user IDs through the Users and Groups 

> Manage Users portlet that have been created in Microsoft Active Directory 

repositories. 







Configuring an SSL connection to an LDAP server 

If your implementation of Tivoli Integrated Portal uses an external LDAP-based user 

repository, such as Microsoft Active Directory, you can configure it to communicate 

over a secure SSL channel. 


This task assumes that you have already an existing connection to an LDAP server 

set up. 

Your LDAP server (for example, an IBM Tivoli Directory Server Version 6 or an 

Microsoft Active Directory server), must be configured to accept SSL connections 

and be running on secured port number (636). Refer to your LDAP server 

documentation if you need to create a signer certificate, which as part of this task, 

must be imported from your LDAP server into the trust store of the Tivoli 

Integrated Portal Server. 


Follow these instructions to configure the Tivoli Integrated Portal Server to 

communicate over a secure (SSL) channel with an external LDAP repository. All 

application server instances must be configured for the LDAP server. 

Procedure 

1. Log in to the portal. 

2. Follow these steps to import your LDAP server's signer certificate into the 

application server trust store. 

a. In the navigation pane, click Settings > Websphere Admin Console and 

click Launch Websphere Admin Console. 

b. In the WebSphere Application Server administrative console navigation 


c. In the Related Items area, click the Key stores and certificates link and in 


d. In the Additional Properties area, click the Signer certificates link and click 

theRetrieve from port button. 

e. In the relevant fields, provide hostname, port (normally 636 for SSL 

connections), SSL configuration details, as well as the alias of the certificate 

for your LDAP server and click the Retrieve signer information button and 

then click OK. 

3. Follow these steps to enable SSL communications to your LDAP server: 

a. In the navigation pane, click Security > Secure administration, 

applications, and infrastructure. 

Reference 287

. Select Federated repositories from the Available realm definitions drop 

down list and click Configure. 

c. Select your LDAP server from the Repository drop down list. 

d. Enable the Require SSL communications check box and the select the 

Centrally managed option. 

e. Click OK. 

4. For the changes to take effect, save, stop, and restart all Tivoli Integrated Portal 

Server instances. 


If you intend to enable single sign-on (SSO) so that users can log in once and then 

traverse to other applications without having to re-authenticate, configure SSO. 


“Changing passwords” on page 345 



Configuring an SSL connection to the ObjectServer 

For environments that include a Tivoli Netcool/OMNIbus ObjectServer user 

registry, you need to set up encrypted communications on the Tivoli Integrated 

Portal Server. 


Follow these steps to establish a secure channel for communications between the 

Tivoli Integrated Portal Server and the ObjectServer. 

Procedure 

1. Retrieve the ObjectServer certificate information, as follows: 

a. In the navigation pane, click Settings > Websphere Admin Console and 

click Launch Websphere Admin Console. 

b. In the WebSphere Application Server administrative console navigation 


c. On the SSL certificate and key management page, click Key stores and 

certificates and on the page that is displayed, click NodeDefaultTrustStore. 

d. On the NodeDefaultTrustStore page, click Signer certificates and on the 

page that is displayed, click Retrieve from port. 

e. In the relevant fields, enter Host, Port, and Alias values for the 

ObjectServer and click Retrieve signer information. 

The signer information is retrieved and stored. For your reference, when the 

signer information has been retrieved, the following details are displayed: 

Serial number 

Specifies the certificate serial number that is generated by the issuer 

of the certificate. 

Issued to 

Specifies the distinguished name of the entity to which the 

certificate was issued. 

Issued by 

Specifies the distinguished name of the entity that issued the 


certificate. This name is the same as the issued-to distinguished 

name when the signer certificate is self-signed. 

Fingerprint (SHA digest) 

Specifies the Secure Hash Algorithm (SHA hash) of the certificate, 

which can be used to verify the certificate's hash at another location, 

such as the client side of a connection. 

Validity period 

Specifies the expiration date of the retrieved signer certificate for 

validation purposes. 

2. Open tip_home_dir/profiles/TIPProfile/etc/ 

com.sybase.jdbc3.SybDriver.props in a text editor and change these 

parameters: 















IBM Tivoli Network Management Information Center 

Refer to the Netcool/OMNIbus Administration Guide for generating a trusted.txt 

file 

Configuring VMM for the ObjectServer 

When your Tivoli Netcool/OMNIbus ObjectServer is in a federated repository, use 

the script provided with Tivoli Integrated Portal to configure the Virtual Member 

Manager adapter for the ObjectServer. 


Have the following ObjectServer information at hand: administrator name and 

password, IP address, and port number. If you have a second ObjectServer for 

failover support, you need the IP address and port number. The ObjectServer must 

be running at the time of installing Tivoli Integrated Portal, as the installation 

process attempts to connect to the ObjectServer. 


The script assumes that the tip installation directory is the parent directory and 

that the profile and cell names are TIPProfile and TIPCell. Run the VMM 

configuration script on every computer where the application server is installed. 

Reference 289

Procedure 

1. Change to the install_dir\bin directory. The directory contains a script to run: 

v confvmm4ncos.bat 

v confvmm4ncos.sh 

v confvmm4ncos.sh 

2. Enter the following command at the command line: confvmm4ncos user 

password address port [address2 port2]where 

a. user is the ID of a user with administrative privileges for this ObjectServer 

b. password is the password for the user ID 

c. address is the IP address of the ObjectServer 

d. port is the port number used by the ObjectServer 

e. Optional: address2 and port2, if there is a failover server, is the IP address 

and port number of the failover ObjectServer 

Results 

The VMM adapter is configured for the ObjectServer. Thereafter, whenever the 

user registry needs to be accessed, the VMM adapter is called for this information. 

Single sign-on 




The repository for the user IDs can be the Tivoli Netcool/OMNIbus ObjectServer 

or a Lightweight Directory Access Protocol (LDAP) registry. A user logs on to one 

of the participating applications, at which time their credentials are authenticated 

at a central repository. With the credentials authenticated to a central location, the 

user can then launch from one application to another to view related data or 

perform actions. Single sign-on can be achieved between applications deployed to 

Tivoli Integrated Portal servers on multiple machines. 

Single sign-on capabilities require that the participating products use Lightweight 

Third Party Authentication (LTPA) as the authentication mechanism. When SSO is 

enabled, a cookie is created containing the LTPA token and inserted into the HTTP 

response. When the user accesses other Web resources (portlets) in any other 

application server process in the same Domain Name Service (DNS) domain, the 

cookie is sent with the request. The LTPA token is then extracted from the cookie 

and validated. If the request is between different cells of application servers, you 

must share the LTPA keys and the user registry between the cells for SSO to work. 

The realm names on each system in the SSO domain are case sensitive and must 

match exactly. See Managing LTPA keys from multiple WebSphere Application 

Server cells on the WebSphere Application Server Information Center. 



“Adding an external LDAP repository” on page 282 



“Configuring single sign-on” 


repository. 

“Changing the default security registry” on page 359 

The default security registry can be set at install time. Use this procedure to change 

the default registry after installation. 

“Protecting the vault key file” on page 325 

To keep the encryption key for the administrator password secure, establish strict 

read-only access to the vault key file. 

Configuring single sign-on: 


repository. 


Configuring SSO is a prerequisite to integrating products that are deployed on 

multiple servers. All Tivoli Integrated Portal Server instances must point to the 

central user registry (such as a Lightweight Directory Access Protocol server). 

Attention: ITM single sign on (SSO) support is only available with ITM Version 

6.2 Fix Pack 1 or higher. 


To configure the WebSphere federated repositories functionality for LDAP: 

Procedure 




3. In the WebSphere Application Server administrative console navigation pane, 

click Security > Global security. 

4. In the Authentication area, expand Web security and click Single sign-on. 

5. Click the Enabled option if SSO is disabled. 

6. Click Requires SSL if all of the requests are expected to use HTTPS. 

7. Enter the fully-qualified domain names in the Domain name field where SSO 

is effective. If the domain name is not fully qualified, the Tivoli Integrated 

Portal Server does not set a domain name value for the LtpaToken cookie and 

SSO is valid only for the server that created the cookie. For SSO to work 

across Tivoli applications, their application servers must be installed in same 

domain (use the same domain name). 

8. Optional: Enable the Interoperability Mode option if you want to support 

SSO connections in WebSphere Application Server version 5.1.1 or later to 

interoperate with previous versions of the application server. 

9. Optional: Enable the Web inbound security attribute propagation option if 

you want information added during the login at a specific Tivoli Enterprise 

Portal Server to propagate to other application server instances. 

Reference 291

10. After clicking OK to save your changes, stop and restart all the Tivoli 

Integrated Portal Server instances. 


Note: When you launch Tivoli Integrated Portal, you must use a URL in the format 

protocol://host.domain:port /*. If you do not use a fully-qualified domain name, 

Tivoli Integrated Portal cannot use SSO between Tivoli products. 















Load balancing 



Load balancing is ideal for Tivoli Integrated Portal installations with a large user 

population. When a node within a cluster fails, new user sessions are directed to 

other active nodes. 

You can create a load balanced cluster from an existing stand-alone application 

server instance, but must export its data before you configure it for load balancing. 

The exported data is subsequently imported to one of the nodes in the cluster so 

that it is replicated across the other nodes in the cluster. 

Work load is distributed by session, not by request. If a node in the cluster fails, 

users who are in session with that node must log back in to access the Tivoli 

Integrated Portal. Any unsaved work is not recovered. 

Synchronized data 

After load balancing is set up, changes in the console that are stored in global 

repositories are synchronized to all of the nodes in the cluster using a common 

database. The following actions cause changes to the global repositories used by 

the console. Most of these changes are caused by actions in the Settings folder in 

the console navigation. 

v Creating, restoring, editing, or deleting a page. 

v Creating, restoring, editing, or deleting a view. 

v Creating, editing, or deleting a preference profile or deploying preference 

profiles from the command line. 

v Copying a portlet entity or deleting a portlet copy. 

v Changing access to a portlet entity, page, external URL, or view. 


v Creating, editing, or deleting a role. 

v Changes to portlet preferences or defaults. 

v Changes from the Users and Groups applications, including assigning users and 

groups to roles. 

Note: Global repositories should never be updated manually. 

During normal operation within a cluster, updates that require synchronization are 

first committed to the database. At the same time, the node that submits the 

update for the global repositories notifies all other nodes in the cluster about the 

change. As the nodes are notified, they get the updates from the database and 

commit the change to the local configuration. 

If data fails to be committed on any given node, a warning message is logged into 

the log file. The node is prevented from making its own updates to the database. 

Restarting the Tivoli Integrated Portal Server instance on the node rectifies most 

synchronization issues, if not, the node should be removed from the cluster for 

corrective action. See “Monitoring a load balancing cluster” on page 233 for more 

information. 

Note: If the database server restarts, all connections from it to the cluster are lost. 

It may take up to five minutes for connections to be restored, so that users can 

again perform update operations, for example, modifying or creating views or 

pages. 

Manual synchronization and maintenance mode 

Updates to deploy, redeploy, or remove console modules are not automatically 

synchronized within the cluster. These changes must be performed manually at 

each node. For deploy and redeploy operations, the console module package must 

be identical at each node. 

When one of the deployment commands is started on the first node, the system 

enters maintenance mode and changes to the global repositories are locked. After 

you finish the deployment changes on each of the nodes, the system returns to an 

unlocked state. There is not any restriction to the order that modules are deployed, 

removed, or redeployed on each of the nodes. 

While in maintenance mode, any attempts to make changes in the portal that affect 

the global repositories are prevented and an error message is returned. The only 

changes to global repositories that are allowed are changes to a user's personal 

portlet preferences. Any changes outside the control of the portal, for example, a 

form submission in a portlet to a remote application, are processed normally. 

The following operations are also not synchronized within the cluster and must be 

performed manually at each node. These updates do not place the cluster in 

maintenance mode. 

v Deploying, redeploying, and removing wires and transformations 

v Customization changes to the console user interface (for example, custom images 

or style sheets) using consoleProperties.xml. 

To reduce the chance that users could establish sessions with nodes that have 

different wire and transformation definitions or user interface customizations, 

schedule these changes to coincide with console module deployments. 

Reference 293

Requirements 

The following requirements must be met before load balancing can be enabled: 

v If you are creating a cluster from a stand-alone instance of Tivoli Integrated 

Portal, you must export its data before you configure it for load balancing. Once 

you have configured the cluster, you can import the data to one of the nodes for 

it to be replicated across the other nodes. 

v Lightweight Directory Access Protocol (LDAP) must be installed and configured 

as the user repository for each node in the cluster. For information about which 

LDAP servers you can use, see List of supported software for WebSphere 

Application Server V7.0. See Configuring LDAP user registries for instructions 

on how to enable LDAP for each node. 

v A front-end network dispatcher (for example, IBM HTTP Server) must be setup 

to handle and distribute all incoming session requests. See Setting up 

intermediary services for more information about this task. 

v DB2 Version 9.7 must be installed within the network to synchronize the global 

repositories for the console cluster. 

v Each node in the cluster must be enabled to use the same LDAP using the same 

user and group configuration. 

v All console nodes in load balancing cluster must be installed in the same cell 

name. After console installation on each node, use the -cellName parameter on 

the manageprofiles command. 

v All console nodes in load balancing cluster must have synchronized clocks. 

v The Websphere application server and Tivoli Integrated Portal Server versions 

must have the same release level, including any fix packs. Fixes and upgrades 

for the runtime must be applied manually at each node. 

v Before joining nodes to a cluster, in each case make sure the node uses the same 

file-based repository user ID, which has been assigned the role of iscadmins. 




Exporting data from a stand-alone server to prepare for load balancing: 

You can export date from an existing stand-alone application server instance to 

create a data file that can be imported to a load balanced cluster. 


When you are creating a new load balanced cluster from a stand-alone instance, 

you must first export all data from the stand-alone instance and subsequently 

import the previously exported data once the cluster is set up. 

Note: If you are joining the server to an existing cluster, the other nodes in the 

cluster should not contain custom data, that is, each node in the cluster should be 

clean installations. When you import data from the stand-alone server it is 

replicated across all other nodes. 

Procedure 

1. At the command line, change to the following directory: tip_home_dir/ 

profiles/TIPProfile/bin/ 

2. Run the following command to export the stand-alone server's data: 


v restcli.sh export -username 

tip_admin_username -password tip_admin_password -destination data_file 

v restcli.bat export -username tip_admin_username 

-password tip_admin_password -destination data_file 

Where: 





data_file 

Specifies the path and file name for the exported data, for example, 

c:/tmp/data.zip. 

3. Create a new load balanced cluster using the stand-alone server, or join it to an 

existing cluster. 

4. Import the previously exported data to any node in the cluster. 

a. At the command line, if necessary, change to the following directory: 


b. On one of the nodes in the cluster, run the following command to import 

the stand-alone server's data: 

restcli.sh import -username tip_admin_username -password 

tip_admin_password -source data_file 

Where: 





data_file 

Specifies the path and file name for the data to be imported, for 

example, c:/tmp/data.zip. 

Results 

Create a new load balanced cluster using the stand-alone application server, or join 

it to an existing cluster. Once the cluster is configured, you can import the data file 

to one of the nodes in the cluster. 


Setting up a load balancing cluster: 

You can configure a Tivoli Integrated Portal Server instance to use a database as a 

file repository instead of a local directory. 


If you are creating a cluster from an existing Tivoli Integrated Portal Server 

instance that contains custom data, ensure that you have exported its data before 

you begin to configure it for load balancing. Once it is configured, you can import 

the data to one of the nodes in the new cluster. 

Reference 295

Tivoli Integrated Portal is installed on a machine using the cell name designated 

for all console nodes within the cluster. You have installed and setup a network 

dispatcher (for example, IBM HTTP Server), DB2, and an LDAP as explained in 

“Requirements” on page 214. 

Procedure 

1. On the machine where DB2 is installed, create a DB2 database (see Creating 

databases). 




























path. 
















the cluster. 





































5. Make sure your database is empty and the server is not started. Problems may 

occur if you try to setup load balancing on a non-empty database or active 

server. 





Reference 297







Results 

The load balancing cluster is created and the console node is joined to the cluster 

as the first node. 


Add (or join) additional nodes to the cluster. 

Joining a node to a load balancing cluster: 

You can configure a Tivoli Integrated Portal Server to join an existing load 

balancing cluster. 


1. If you are joining a stand-alone Tivoli Integrated Portal Server instance to a 

cluster, ensure that you first export all of its data. Once you have joined it to 

the cluster, you can then import the previously exported data. Other nodes in 

the cluster should not contain any custom data and should effectively be new 

installed instances. 

2. Make sure you have successfully enabled load balancing following the steps in 

“Setting up a load balancing cluster” on page 216. 

3. Tivoli Integrated Portal should be installed to the node using the same cell 

name that is designated for the cluster. 

4. All console modules deployed to the cluster must be already deployed to the 

node that you intend to join. 

5. You should deploy any wires or transformations used by the nodes in the 

cluster. 

6. If the cluster is using any customization changes in consoleProperties.xml you 

must copy these changes and this file to the same location on the node that you 

intend to join. 

7. The node must be configured to the same LDAP with the same user and group 

definitions as all other nodes in the cluster. 


The following parameters are used on the join option when a node is added: 



Procedure 





























path. 














the cluster. 












Reference 299



























4. Make sure the Tivoli Integrated Portal Server is not started. 

5. At a command prompt, change to the tip_home_dir/profiles/TIPProfile/bin/ 

ha directory and issue this command 









Results 

The console node is joined to the cluster. 


Add another node to the cluster, or if you have completed adding nodes, enable 

server to server trust for each node to every other node in the cluster. 


Depending on the network dispatcher (for example, IBM HTTP Server) that you 

use, you might have further updates to get session requests routed to the new 

node. Refer to the documentation applicable to your network dispatcher for more 

information. 

Enabling server-to-server trust: 

Use this procedure to enable load balanced nodes to connect to each other and 

send notifications. 


These steps are required to enable load balancing between the participating nodes. 

Complete these steps on each node. 

Procedure 

1. In a text editor, open the ssl.client.props file from the tip_home_dir/ 

profiles/TIPProfile/properties directory. 

2. Uncomment the section that starts with com.ibm.ssl.alias=AnotherSSLSettings 

so that it looks like this: 

com.ibm.ssl.alias=AnotherSSLSettings 

com.ibm.ssl.protocol=SSL_TLS 

com.ibm.ssl.securityLevel=HIGH 

com.ibm.ssl.trustManager=IbmX509 

com.ibm.ssl.keyManager=IbmX509 

com.ibm.ssl.contextProvider=IBMJSSE2 

com.ibm.ssl.enableSignerExchangePrompt=true 

#com.ibm.ssl.keyStoreClientAlias=default 

#com.ibm.ssl.customTrustManagers= 

#com.ibm.ssl.customKeyManager= 

#com.ibm.ssl.dynamicSelectionInfo= 

#com.ibm.ssl.enabledCipherSuites= 

3. Uncomment the section that starts with 

com.ibm.ssl.trustStoreName=AnotherTrustStore so that it looks like this: 

# TrustStore information 







com.ibm.ssl.trustStoreReadOnly=false 

4. Update the location of the trust store that the signer should be added to in the 

com.ibm.ssl.trustStore property of AnotherTrustStore by replacing the 

default value com.ibm.ssl.trustStore=${user.root}/etc/trust.p12 with the 

correct path for your trust store. Example: 

com.ibm.ssl.trustStore=${user.root}/config/cells/TIPCell/nodes/TIPNode02 

/trust.p12 

After the update, the section must look like this: 







5. Save your changes to ssl.client.props. 


Reference 301











7. Complete all of the steps so far on each node before you continue with the rest 

of the steps. 

8. Run the following command on each node for each myremotehost (that is, for 

every node that you want to enable trust with) in the cluster: 

tip_home_dir\profiles\TIPProfile\bin\retrieveSigners.bat 

NodeDefaultTrustStore AnotherTrustStore -host myremotehost -port 

remote_SOAP_port 


retrieveSigners.sh NodeDefaultTrustStore AnotherTrustStore -host 

myremotehost -port remote_SOAP_port 

where myremotehost is the name of the computer to enable trust with; 

remote_SOAP_port is the SOAP connector port number (16313 is the default). If 

you have installed with non-default ports, check tip_home_dir/properties/ 

TIPPortDef.properties for the value of SOAP_CONNECTOR_ADDRESS and use that. 










Example 



In this example, the load balancing cluster is comprised of two Microsoft Windows 

nodes named myserver1 and myserver2. The command entered on myserver1: 


-port 16313 

The command entered on myserver2: 


etrieveSigners.bat NodeDefaultTrustStore AnotherTrustStore -host myserver1 

-port 16313 

Verifying a load balancing implementation: 

Use the information in this topic to verify that your Tivoli Integrated Portal load 

balancing setup is working correctly once you have added all nodes to the cluster 

and enabled server-to-server trust. 


This task allows you to confirm the following functions are working correctly: 

v The database used for your load balancing cluster is properly created and 

initialized. 

v Every node in the cluster uses the database as its repository instead of its own 

local file system. 

v Server-to-server trust is properly enabled between nodes in the cluster. 

To verify your load balancing configuration: 

Procedure 

1. Ensure that each Tivoli Integrated Portal Server instance on every node in the 

cluster is running. 

2. In a browser, log into one node, create a new View and save your changes. 

3. Log into the remaining nodes and verify that the newly created view is 

available in each one. 

Preparing the HTTP server for load balancing: 

Install the IBM HTTP Server and configure the Web server plug-in for passing 

requests to the Tivoli Integrated Portal Server that are part of the load balancing 



The IBM HTTP Server uses a Web server plug-in to forward HTTP requests to the 

Tivoli Integrated Portal Server. You can configure the HTTP server and the Web 

server plug-in to act as the load balancing server, that is, pass requests (HTTP or 

HTTPS) to one of any number of nodes. The load balancing methods supported by 

the plug-in are round robin and random: 

v With a round robin configuration, when a browser connects to the HTTP server, 

it is directed to one of the configured nodes. When another browser connects, it 

is directed to a different node. 

v With the random setting, each browser is connected randomly to a node. Once a 

connection is established between a browser and a particular node, that 

connection remains until the user logs out or the browser is closed. 

The HTTP server is necessary for directing traffic from browsers to the applications 

that run in the Tivoli Integrated Portal environment. The server is installed between 

the portal and the Tivoli Integrated Portal Server, and is outside the firewall. 

The Web server plug-in uses the plugin-cfg.xml configuration file to determine 

whether a request is for the application server. 

Reference 303


Complete this procedure to configure the Web server plug-in for load balancing for 

each node. 

Procedure 

1. If you do not already have the IBM HTTP Server installed, install it before 

proceeding. It should be installed where it can be accessed from the Internet or 

Intranet (or both). Select the link at the end of this topic for the installation 

procedure. 

2. Install IBM HTTP Server ensuring that you include the IBM HTTP Server 

Plug-in for IBM WebSphere Application Server option. For more information, 

see http://publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/ 

com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_installihs.html. 

3. Create a new CMS-type key database. For more information see 

http://publib.boulder.ibm.com/infocenter/wasinfo/fep/index.jsp?topic=/ 

com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_createkeydb.html. 

4. Create a self-signed certificate to allow SSL connections between nodes. For 

more information, see http://publib.boulder.ibm.com/infocenter/wasinfo/fep/ 

index.jsp?topic=/com.ibm.websphere.ihs.doc/info/ihs/ihs/ 

tihs_certselfsigned.html. 

5. To enable SSL communications for the IBM HTTP Server, in a text editor, open 

HTTP_server_install_dir/conf/httpd.conf. Locate the line # End of example 

SSL configuration and add the following lines, ensuring that the KeyFile line 

references the key database file created in step 3 on page 224 and save your 

changes. 

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so 

 

Listen 443 

 

SSLEnable 

 

 

SSLDisable 

KeyFile "C:/Program Files/IBM/HTTPServer/bin/test.kdb" 

For more information, refer to the first example at http:// 

publib.boulder.ibm.com/infocenter/wasinfo/fep/index.jsp?topic=/ 

com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_setupssl.html. 

6. Restart the IBM HTTP Server. For more information, see http:// 

publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/ 


7. On the IBM HTTP Server computer, to verify that SSL is enabled ensure that 

you can access https://localhost. 








administrator username and password.

. In the tip_home_dir/profiles/TIPProfile/bin directory, depending on your 




9. Start the HTTP server: 

a. Change to the directory where it is installed. 

b. Run this command: bin/apachectl start Note you must restart the server 

after changing the plugin-cfg.xml file. 


Enter the URL for the HTTP Server in a browser http://HTTP_server_host/ 

HTTP_server_port and it will be forwarded to one of the nodes. 

Note: The default load balancing method is random, whereby each browser is 

connected randomly to a node. 


Web server plug-in tuning tips 

The Web server works with the application server to balance workload. 

Setting clone IDs for nodes: 

Assign a clone ID for all nodes in the cluster. 


Complete this procedure to set clone IDs for all nodes in the cluster. You must 

carry out these steps on each node. 

Procedure 

1. In a text editor, open the server.xml file from the tip_home_dir/profiles/ 

TIPProfile/config/cells/TIPCell/nodes/TIPNode/servers/server1 directory 

2. In server.xml, locate the entry

 

 

 

 

 

 

 

4. Save the changes you made to server.xml. 

Generating the plugin-cfg.xml file: 

Run GenPluginCfg.bat to generate the plugin-cfg.xml file and save it in 

tip_home_dir/profiles/TIPProfile/config/cells. 


Complete this procedure to generate the plug-cfg.xml file. You must carry out 

these steps on each node. 

Procedure 

1. On a node, change to tip_home_dir/profiles/TIPProfile/bin/ and run the 


v GenPluginCfg.bat 

v GenPluginCfg.sh 

This command generates a file called plugin-cfg.xml and saves it to the 

tip_home_dir/profiles/TIPProfile/config/cells directory. 

2. On the IBM HTTP Server, in the following directory, replace the existing 

plugin-cfg.xml with the version generated in step 1 on page 226: 

HTTP_web_server_install_dir/plugins/config/webserver1 

The following steps establish the new /ibm/* URI (Uniform Resource 

Identifier), which is where the plug-in will redirect requests: 

a. On the IBM HTTP Server, change to the directory where the Web server 

definition file is (such as cd plugins/config/webserver1). 

b. Open the plugin-cfg.xml file in a text editor, and in reference to the sample 

content extract provided below, edit the file to provide details of your IBM 

HTTP Server and all Tivoli Integrated Portal Server instances. 

HTTP SERVER PATH is the path to where the HTTP server is installed. 

HTTP SERVER PORT is the port for the HTTP server. 

SERVER1 is the fully qualified name of the computer where the 


SERVER2 is the fully qualified name of the computer where another 



CLONE_ID is the is the unique clone ID assigned to a particular node 

(server) in the cluster. 

c. In the ServerCluster section, the values for the keyring and stashfile 

properties should be HTTP SERVER PATH /plug-ins/etc/plug-in-key.kdb and 

HTTP SERVER PATH /plug-ins/etc/plug-in-key.sth respectively. 

d. Continue to add Server entries for any other nodes, following the same 

pattern. Add a new entry under PrimaryServers for each additional server. 

e. Add CloneID and LoadBalanceWeight attributes for every Server entry. 

Important: For more information on web server plug-in workload 

management policies and to help you determine the appropriate values for 

the elements LoadBalance and LoadBalanceWeight, refer to the following 

articles: 

v http://www.redbooks.ibm.com/abstracts/TIPS0235.html 

v http://www-01.ibm.com/support/docview.wss?rs=180 

&uid=swg21219567 

Attention: The HTTP and HTTPS port values for all nodes should be the 

same. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


WaitForContinue="false"> 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configuring SSL from each node to the IBM HTTP Server: 

For load balancing implementations, you must configure SSL between the IBM 

HTTP Server plug-in and each node in the cluster. 


This task assumes that you have already installed and configured the IBM HTTP 

Server for load balancing. 


For each node in the cluster, follow these instructions to configure the node to 

communicate over a secure (SSL) channel with the IBM HTTP Server. 

Procedure 




3. Follow these steps to extract signer certificate from the trust store: 

a. In the WebSphere Application Server administrative console navigation 


b. In the Related Items area, click the Key stores and certificates link and in 


c. In the Additional Properties area, click the Signer certificates link and in 

the table that is displayed, select the root entry check box. 

d. Click Extract and in the page that is displayed, in the File name field, enter 

a certificate file name (certficate.arm), for example, c:\tivpc064ha1.arm. 

e. From the Data Type list select the Base64-encoded ASCII data option and 

click OK. 

f. Locate the extracted signer certificate and copy it to the computer running 

the IBM HTTP Server. 

Reference 309

Note: This steps are particular to Tivoli Integrated Portal, for general 

WebSphere Application Server details and further information, see: 


com.ibm.websphere.base.doc/info/aes/ae/tsec_sslextractsigncert.html 

4. On the computer running the IBM HTTP Server, follow these steps to import 

the extracted signer certificate into the key database: 

a. Start the key management utility (iKeyman), if it is not already running, 

from HTTP_SERVER_PATH/bin: 



b. Open the CMS key database file that is specified in plugin-cfg.xml, for 

example, HTTP_SERVER_PATH/plug-ins/etc/plug-in-key.kdb. 

c. Provide the password (default is WebAS) for the key database and click OK. 

d. From the Key database content, select Signer Certificates. 

e. Click Add and select the signer certificate that you copied from the node to 

the computer running the IBM HTTP Server and click OK. 

f. Select the Stash password to a file check box and click OK to save the key 

database file. 

Note: For more information on certificates in WebSphere Application Server, 

see: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/ 

com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_ikeyscca.html 

5. Repeat these steps for each node in the cluster. 

6. For the changes to take effect, stop and restart all nodes in the cluster and also 

restart the computer running the IBM HTTP Server. 











c. Restart the IBM HTTP Server. For more information, see 

http://publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/ 



You should now be able to access the load balanced cluster through 

https://http_server_hostname/ibm/console (assuming that the default context 

root (/ibm/console) was defined in at the time of installation. 

Importing stand-alone instance data to a cluster: 


If you created a cluster from a stand-alone application server instance, you can 

then import the data that you exported prior to configuring the stand-alone 

instance as a cluster node. 


Import the previously exported data file to any node in the cluster. 

Important: The instructions in this topic apply only to importing data that was 

exported when preparing to create a load balanced cluster from a stand-alone 

application server instance, as described in “Exporting data from a stand-alone 

server to prepare for load balancing” on page 215. 

Procedure 

1. At the command line, change to the following directory: 


2. On one of the nodes in the cluster (most likely the node that was previously set 

up as a stand-alone server instance), run the following command to import the 

data file: 

v restcli.sh import -username 

tip_admin_username -password tip_admin_password -source data_file 

v restcli.bat import -username tip_admin_username 

-password tip_admin_password -source data_file 

Where: 





data_file 

Specifies the path and file name to the data file that is to be imported, 

for example, c:/tmp/data.zip. 

Results 

The data from the initial application server is imported to the node and replicated 

across the other cluster nodes. 

Removing a node: 

Follow these steps to remove a node from the load balancing cluster. 


The following parameters are used on the disjoin option when a node is removed. 



Procedure 



Reference 311

v ..\ws_ant.bat -f uninstall.ant disjoin 


v ../ws_ant.sh -f uninstall.ant disjoin 




Removing a remote node: 


This command should be used only in the rare occasions where physical access to 

the node is not available or a serious hardware or software failure has occurred. If 

the node is remotely disjoined but continues to function, some problems with 

synchronization might arise that can lead to problems with data consistency and 

synchronization. 

Procedure 



v ..\ws_ant.bat -f uninstall.ant remote-disjoin 

–DremoteHost=remote_host –DremotePort=9044 -Dusername=DB2_username 

-Dpassword=DB2_password 

v ../ws_ant.sh -f uninstall.ant 

remote-disjoin –DremoteHost=remote_host –DremotePort=9044 




Removing a load balancing cluster: 

Follow these steps to remove the last node from a cluster and thereby the cluster 

itself. 


Make sure you have removed all other nodes from the cluster. This command 

should be issued from the last active node remaining in the cluster. 


The following parameters are used on the join option when a node is added. 



Procedure 

From a command prompt, change to the tip_home_dir/profiles/TIPProfile/bin/ 

ha directory and issue this command: 

v ..\ws_ant.bat -f uninstall.ant uninstall 



v ../ws_ant.sh -f uninstall.ant uninstall 


Monitoring a load balancing cluster: 

If synchronized data fails to be committed to a node in the cluster, that node 

should be removed from the cluster for corrective action. Use the diagnosis tool to 

identify any unsynchronized nodes in the load balancing cluster. 

To determine if changes to global data are not committed to any of the nodes, use 

the HATool command script to check the synchronization of modules and 

repositories on the nodes in a cluster. For the HATool, you must provide the DB2 

administrator's credentials. 

Query synchronization of modules 

Use this command to determine if all nodes have identical sets of modules 

deployed. 

HATool.bat/sh modules username password -byNodes -showAll 


v -byNodes 



module. 

v -showAll 


This parameter is optional. The default is to return only modules for 


Query the synchronization of global repositories 

Use this command to determine if all repositories are synchronized on all 

nodes. 

HATool.bat/sh repositories username password -byNodes -showAll 


v -byNodes 



repository. 

v -showAll 


This parameter is optional. The default is to return only repositories for 


Release the global lock 

Use this command to manually release the global lock placed on all of the 

console nodes when the cluster is in maintenance mode. This command is 

used when a node cannot commit a change during synchronization and 

has to be taken offline. 

HATool.bat/sh release-lock username password 

Configuring Tivoli Access Manager in Tivoli Integrated Portal 

You can configure Tivoli Integrated Portal to use Tivoli Access Manager WebSEAL 

Version 6.1 to manage authentication. 

Reference 313

You must install and configure Tivoli Access Manager WebSEAL Version 6.1. To set 

up and configure Tivoli Access Manager WebSEAL, see http:// 

publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itame.doc/ 

am611_install196.htm#webseal. 

For more information on administering Tivoli Access Manager WebSEAL, see 


com.ibm.itame.doc/am611_webseal_admin.htm. 

Attention: The IBM Tivoli Netcool Impact user interface contained within IBM 

Tivoli Business Service Manager may not function within the Tivoli Access 

Manager WebSEAL environment. If you need to access the Netcool/ Impact user 

interface (for example, to edit Impact policies or access Operator Views), you must 

do so outside of the Tivoli Access Manager WebSEAL environment. 

Configuring single sign-on using ETai: 

In a WebSphere Application Server (WAS) environment, Tivoli Access Manager 

WebSEAL can be used as a reverse proxy to intercept incoming http or https 

requests to ensure that users are authenticated and authorized and are passed to 

the relevant Tivoli Integrated Portal Server . 

ETai is the component that implements the WebSphere Application Server trust 

association interceptor interface to achieve single sign on from WebSEAL to the 

Tivoli Integrated Portal Server. 

Tivoli Integrated Portal supports single sign-on (SSO) with perimeter 

authentication services such as reverse proxies through trust associations. When 

trust associations are enabled, the WebSphere Application Server is not required to 

authenticate a user if a request arrives from a trusted source that has already 

performed authentication. 

Once a trust association is configured between WebSEAL and the Tivoli Integrated 

Portal Server, a user can login into Tivoli Access Manager and then access the 

Tivoli Integrated Portal Server without having to re-authenticate. The ETai must be 

configured in Tivoli Integrated Portal Server server and is responsible for 

establishing trust against the WebSEAL server. ETai simplifies the use of Tivoli 

Access Manager and the configuration required to achieve SSO. One advantage is 

that Tivoli Access Manager and Tivoli Integrated Portal can use different user 

registries and still be able to perform SSO. It also provides the mapping between 

different registry formats. 

Installing ETai: 

Use these instructions, to install the Tivoli Access Manager Extended Trust 

Association Interceptor in a Tivoli Integrated Portal environment. 


Source a copy of com.ibm.sec.authn.tai.etai_6.0.jar from your installation 

media. 


To install ETai: 


Procedure 

1. Copy com.ibm.sec.authn.tai.etai_6.0.jar to the plugins directory. 

2. At the command line, depending on your operating system, run the relevant 

command: 

v tip_home_dir\bin\Osgicfginit.bat 

v tip_home_dir/bin/Osgicfginit.sh 

3. Copy pd.jar to tip_home_dir/java/jre/lib/ext 


Configure ETai in a Tivoli Integrated Portal environment. 

Enabling a trust association for ETai: 

You must enable a trust association between the Tivoli Access Manager Extended 

Trust Association Interceptor in the Tivoli Integrated Portal environment. 


To configure a trust association for ETai: 

Procedure 

1. Log in to the portal and click Settings > WebSphere Administrative Console. 

2. In the WebSphere Administrative Console page, click Launch WebSphere 

administrative console. 

3. In the WebSphere Administrative Console navigation pane, click Global 

security. 

4. In the Global security page, expand Web security and click Trust association. 

5. In the General Properties area, click the Enable trust association option if it is 

disabled and click Apply. 

Your update is saved and you are returned to the Global security page. 

6. In the Global security page, expand Web security and click Trust association 

to display the Trust association page. 

7. In the Additional properties area, click the Interceptors link to display the 

Interceptors page. 

8. If com.ibm.sec.authn.tai.TAMETai is not listed on the page, click New. 

9. In the Interceptor class name field enter the string 

com.ibm.sec.authn.tai.TAMETai and click Apply. 

10. In the Messages area, click the Save link to commit your change. 


Configure ETai in the a Tivoli Integrated Portal environment. 

Configuring custom properties for ETai: 

Once you have enabled a trust association for the Tivoli Access Manager Extended 

Trust Association Interceptor in the Tivoli Integrated Portal environment, you must 

configure its custom properties. 

Reference 315


To configure custom properties for the ETai: 

Procedure 

1. Log in to the portal and click Settings > WebSphere Administrative Console. 

2. In the WebSphere Administrative Console page, click Launch WebSphere 

administrative console. 

3. In the WebSphere Administrative Console navigation pane, click Global 

security. 

4. In the Global security page, expand Web security and click Trust association 

to display the Trust association page. 

5. In the Additional properties area, click the Interceptors link to display the 

Interceptors page. 

6. From the list of interceptor classes, select the com.ibm.sec.authn.tai.TAMETai 

entry. 

7. In the Additional properties area, click the Custom properties link to display 

the Custom properties page. 

8. Review the details for the custom properties listed in Table 1: 

Table 18. ETai custom properties 

Property details Notes 

Property name: 

com.ibm.websphere 

.security.webseal 

.useWebSphereUserRegistry 

Type: string 

Required: 

Yes 

Values: true or false 

Default value: 

true 




.tamUserDnMapping 

Required: 

Yes 

Value: WAS 


TAM 


ETai authenticates the trusted user against the 

WebSphere Application Server user registry or the 

Tivoli Access Manager Authorization Server. If this 

property is set to true, the resulting Subject will not 

contain a PDPrincipal as the Tivoli Access Manager 

Authorization Server is required to build the 

PDPrincipal. Any other value for this property will 

result in a PDPrincipal being added to the Subject. 

The ETai adds users' credential information into the 

JAAS Subject. This information includes the users 

dn. Maps this dn to the WebSphere Application 

Server dn, or (Value = WAS). If a mapping is 

attempted for a user that does not exist in the 

WebSphere Application Server user registry, it is 

ignored and not added to the JAAS Subject.

Table 18. ETai custom properties (continued) 





.tamGroupDnMapping 

Required: 

Yes 

Value: WAS 


TAM 




.loginId 

Type: String 

Required: 

Yes 

Value: websealSSOID 


None 




.checkViaHeader 

Type: String 

Required: 

Yes 

Value: true 


false 

The ETai adds users' credential information into the 

JAAS Subject. This information includes the group 

dn's. The ETai can be configured to either: 

Map these dn's to the WebSphere Application Server 

dn's, or (Value = WAS). 

If a mapping is attempted for a group that does not 

exist in the WebSphere Application Server user 

registry, it is ignored and not added to the JAAS 

Subject. 

The value of this property must exist as a valid user 

in the user registry. 

If necessary, create a new user in the Tivoli 

Integrated Portal registry called websealSSOID. 

The ETai must be configured with the username of 

the WebSEAL trusted user. This is the single sign-on 

user that is authenticated using the password in the 

Basic Authentication header inserted by WebSEAL in 

the request. The format of the username is the short 

name representation. 

This property interacts with the following property: 

com.ibm.websphere.security 

.webseal.useWebSphereUserRegistry 

If com.ibm.websphere.security 

.webseal.useWebSphereUserRegistry is set to true 

then the specified user must exist in either the 

WebSphere Application Server user registry or the 

Tivoli Access Manager user registry. 

The ETai can be configured so that the Via header 

can be ignored when validating trust for a request. 

This property is required, if WebSEAL is to allow 

requests into the Tivoli Integrated Portal only from 

particular hosts. 

This property interacts with the following 

properties: 

v com.ibm.websphere.security.webseal.hostnames 

v com.ibm.websphere.security.webseal.ports 


.webseal.checkViaHeader is set to false then the 

values set for the two associated properties are not 

used. 

Reference 317





.security.webseal.id 

Required: 

Yes 

Value: iv-creds 


iv-creds 




.hostnames 

Required: 

Yes 

Value: A comma separated list of 

strings. 


There is no default value 

for this property. 




.ports 

Required: 

Yes 

Value: 443 


There is no default value 

for this property. 


Iv-creds carrys end user credentials, which is used 

by Tivoli Integrated Portal for authorization. 

Note: Any additional values set for this property 

are added to a list along with Iv-creds, that is, 

Iv-creds is a required header for the ETai. 

The ETai can be configured so that the request must 

arrive from a list of expected hosts. If any of the 

hosts in the Via header of the HTTP request are not 

listed in the values set for this property, the request 

is ignored by the ETai. 


com.ibm.websphere.security.webseal.ports 

All of the values listed for 

com.ibm.websphere.security.webseal.hostnames are 

used with the ports listed for 

com.ibm.websphere.security.webseal.ports to 

indicate a trusted host. 

For example, if: 

com.ibm.websphere.security.webseal.hostnames 

is set to abc,xyz 

com.ibm.websphere.security.webseal.ports is 

set to 80,443 

Then, the Via header is checked for these 

hostname/port combinations: abc:80; abc:443; 

xyz:80; xyz:443. 


.webseal.checkViaHeader is set to false then the 

values set for 


not used. 


com.ibm.websphere.security.webseal.hostnames 

All of the values listed for 


used with the ports listed for 

com.ibm.websphere.security.webseal.ports to 

indicate a trusted host. 

For more information, see the notes for 

com.ibm.websphere.security.webseal.hostnames.






.ssoPwdExpiry 

Required: 

No 

Value: A positive integer. 


600 




.groupRealmPrefix 

Required: 

Yes 

Value: “group:” 


600 




.userRealmPrefix 

Required: 

Yes 

Value: “user:” 


600 

Once trust has been established for a request, the 

password for the Single sign-on user is cached for 

subsequent trust validation of requests. This saves 

the ETai from having to re-authenticate the single 

sign-on user with the user registry for every request, 

therefore increasing performance. The cache timeout 

period can be modified by setting this property to 

the required time in seconds. If the password expiry 

property is set to 0, the cached password does not 

expire. 

This property is needed to map the group realm 

prefix from Tivoli Access Manager to group realm 

prefix in WebSphere Application Server registry. 

This property is needed to map the user realm 

prefix from Tivoli Access Manager to group realm 

prefix in WebSphere Application Server registry. 

9. If a custom property does not exist, click New to configure a custom property 

and provide a name, value, and optional description and click Apply to add 

the custom property. 

10. If the custom property exists, but is not in line with the details provided in 

the table above, click on the custom property entry, update its details and 

click Apply to modify the custom property. 











Reference 319



Configure the Tivoli Access Manager WebSEAL by creating a WebSEAL junction 

and creating a junction mapping table. 

Checking your Tivoli Access Manager configuration: 

To ensure that your Tivoli Access Manager configuration is valid, you can carry 

out a number of checks. 


Ensure that you have the following software versions installed: 

v Tivoli Access Manager version 6.1 

v Tivoli Integrated Portal Server, version 1.1 fix pack 11 or later 


This topic describes how to check the following items: 

v The status of the Tivoli Access Manager server. 

v Connecting to the Tivoli Integrated Portal Server. 

Procedure 

1. To check the status of the Tivoli Access Manager server, at the command line, 

enter pd start status. 

The following output indicates that the Tivoli Access Manager server is 

running: 

pdmgrd yes yes 

pdacld yes no (sometimes yes) 

pdmgrproxyd no no 

webseald-ip1 yes yes 

2. To check if the Lightweight Directory Access Protocol (LDAP) user registry is 

active: 

a. At the command line, enter pdadmin -a sec_master -p 

sec_master_password. 

Note: This command assumes that pdadmin is in the path. 

Expected output: 

pdadmin -a sec_master -p sec_master_password 

b. At the command line, enter user list * 10. 

Example output: 

sec_master 

ivmgrd/master 

ivacld/ip1 

ip1-webseald/ip1 

c. To quit, at the command line, enter quit. 

3. If the Tivoli Access Manager processes are not started, at the command line 

enter pd start start. 

If the processes are already started, the following output can be expected: 

Starting the: Access Manager authorization server 

Could not start the server 


4. To check that you can connect from the Tivoli Integrated Portal Server to the 

Tivoli Access Manager computer: 

a. On the Tivoli Integrated Portal Server use a Web browser to connect to 

http://tam_server_hostname. A security message may be displayed, confirm 

the Tivoli Access Manager self-signed certificate to display an authorization 

dialog. 

b. Enter a username and password to display the Tivoli Access Manager 

WebSEAL splash screen (username = sec_master, password = 

sec_master_password). 


Configure the WebSEAL keystore. 

Configuring the WebSEAL keystore: 

To allow the application server to use Tivoli Access Manager WebSEAL, you must 

import Tivoli Integrated Portal Server security certificate to the WebSEAL keystore. 


To export the Tivoli Integrated Portal Server security certificate and import it into 

the WebSEAL keystore: 

Procedure 

1. Log in to the Tivoli Integrated Portal console. 

2. Export the Tivoli Integrated Portal X.509 certificate. The process for exporting 

varies depending on your browser. Refer to your browser documentation for 

assistance. For example, the following substeps describe how you can export 

the certificate using a Firefox browser: 

a. Double-click on lock icon on lower right hand side of browser window to 

display the Security dialog for the Web page. 

b. Click View Certificate and in the Certificate Viewer dialog and then click 

the Details tab. 

c. Click Export and in the Save Certificate To File dialog and select a directory 

to export the Tivoli Integrated Portal X.509 certificate. 

3. Copy the exported certificate file to the Tivoli Access Manager computer. 

4. On the Tivoli Access Manager computer, at the command line, change to the 

directory that hosts the IKeyman utility. For example, the following directories 

reflect typical locations for the IKeyman utility, but it may vary depending on 

your environment: 

v WAS_home/profiles/profile_name/bin/ 

v WAS_home\java\jre\bin\ 

5. Start the IKeyman utility and complete the substeps: 



a. On the toolbar, click Open to display the Open window. 

b. Select CMS as the key database type. 

Reference 321

c. Click Browse and from /var/pdweb/www-ip1/certs, select pdsrv.kdb to 

display the Password Prompt dialog. The default password reflects the file 

name, that is, pdsrv. 

d. In the Key database content section, select Signer Certificates and click 

Add. 

e. In the Add CA's Certificate from a File dialog, for the Data type, select the 

Base64-encoded ASCII data option and click Browse. 

f. Locate the Tivoli Integrated Portal X.509 certificate and enter a label for the 

certificate (for example, tipmachine). 

g. Click Save to add the certificate to the WebSEAL keystore (do not change 

the certificate's file name). 

6. To restart Tivoli Access Manager WebSEAL, at the command line, enter pdweb 

restart. 

The following is the expected output: 

Stopping the: webseald-ip1 

Starting the: webseald-ip1 


Create a WebSEAL junction. 

Creating a WebSEAL junction: 

A WebSEAL junction is an HTTP or HTTPS connection between a front-end 

WebSEAL server and a back-end Web application server, for example the Tivoli 



Junctions logically combine the Web space of the back-end server with the Web 

space of the WebSEAL server, resulting in a unified view of the entire Web object 

space. To create a junction: 

Procedure 

1. On the Tivoli Access Manager computer, at the command line, enter pdadmin -a 

sec_master_account -p sec_master_password. 

2. At the command line, enter sl. 


ivacld-ip1 

ip1-webseald-ip1 

Note: Where ip1 is the hostname of the Tivoli Access Manager computer. 

3. Enter s t ip1-webseald-ip1 list. 


/ 

4. Enter s t ip1-webseald-ip1 create -t ssl -c iv-creds -b supply -h 

tip_hostname/ip -p tip_admin_console_secure_port /tip. 

Where: 

s t = server task 

ip1-webseal-ip1 = WebSEAL instance name 

-t ssl = transport type is SSL 


-c iv-creds = needed for single sign on (SSO) to work, carry credential 

of user 

-b supply = basic authorization header needed for SSO to work 


Created junction at /tip 

Note: If you want to delete a junction, enter s t ip1-webseald-ip1 delete 

/tip. 

Note: If you want to show details for a junction, enter s t ip1-webseald-ip1 

show /tip. 


Create a WebSEAL junction mapping table. 

Creating a WebSEAL junction mapping table: 

A junction mapping table maps specific target resources to junction names. 

Junction mapping is an alternative to a cookie-based solution for filtering 

dynamically generated server-relative URLs. 


To create a WebSEAL junction mapping table: 

Procedure 

1. On the Tivoli Access Manager computer, in a text editor open the WebSEAL 

configuration file, /opt/pdweb/etc/webseald-ip1.conf. 

2. In the [junction] section, edit the jmt-map path so that it reads jmt-map = 

lib/jmt.conf. 

Note: This path is relative to the server root path. Check the server root path in 

the [server] section of the file and take a note of the full jmt-map path. For 

example, /opt/pdweb/www-ip1/lib/jmt.conf. 

3. In a text editor create or edit open the jmt.conf file and add or modify the 

following: 

v /tip /ibm/console/* 

Note: The /ibm/console/ element of the path shown assumes that the Tivoli 

Integrated Portal root context path was not reconfigured at installation time. 

v /tip /ibm/sla/* 

v /tip /TCR/reports/* 

4. To load the jmt.conf file into WebSEAL, enter s t ip1-webseald-ip1 jmt load. 


DPWWM1462I JMT Table successfully loaded 

5. To restart the WebSEAL server, enter pdweb restart. 


Stopping the: webseald-ip1 

Starting the: webseald-ip1 

Reference 323


Test the WebSEAL junction. 

Testing the WebSEAL junction: 

Once you have created a WebSEAL junction, you can test it. 


To test a WebSEAL junction: 

Procedure 

1. In your Web browser's address bar, enter https://tam_server_hostname/tip/ 

ibm/console, where tip is the name of the WebSEAL junction. The Tivoli 

Integrated Portal login page is displayed. 

2. To test if Tivoli Access Manager challenges you when you try to access the 

Tivoli Integrated Portal: 

a. Close all instances of your Web browser. 

b. Start your Web browser and go to https://tam_server_hostname/tip/ibm/ 

console/. 

Note: The /ibm/console/ element of the URL shown assumes that the 

Tivoli Integrated Portal root context path was not reconfigured at 

installation time. 

If the WebSEAL junction is working as expected, an Authentication 

Required dialog is displayed and you have to provide Tivoli Access 

Manager account (sec_master) details to proceed. 


Edit customizationProperties.xml to ensure that when you log out of Tivoli 

Integrated Portal that you also log out from Tivoli Access Manager. 

Configuring single sign off for Tivoli Access Manager and Tivoli Integrated 

Portal: 

To ensure that you when you log out from the Tivoli Integrated Portal that you 

also log out from Tivoli Access Manager, you must edit 

customizationProperties.xml. 


To configure single sign off for the Tivoli Integrated Portal Server and the Tivoli 

Access Manager computer: 

Procedure 

1. In a text editor, open tip_home_dir/profiles/TIPProfile/config/cells/ 

TIPCell/applications/isclite.ear/deployments/isclite/isclite.war/WEB- 

INF/customizationProperties.xml. 

For example: C:\IBM\tivoli\tipv2\profiles\TIPProfile\ 

config\cells\TIPCell\applications\isclite.ear\deployments\isclite\ 

isclite.war\WEB-INF\customizationProperties.xml 

2. Edit the TAMJunctionName property, as follows: 


 

Where: 

v TAMJunctionName is the junction name in Tivoli Access Manager that is 

configured to point at the Tivoli Integrated Portal Server. 

v WebSealServerName is a Tivoli Access Manager WebSEAL server instance 

name. This property allows the Tivoli Integrated Portal Server process 

requests from declared WebSEAL hosts. 

Results 

When you log out from the Tivoli Integrated Portal, a Successful Logout message 

is displayed in your browser. This indicates that you logged out from both the 

Tivoli Integrated Portal and Tivoli Access Manager. 

Setting form-based authentication for WebSEAL: 

Tivoli Access Manager provides form-based authentication as an optional 

alternative to the standard Basic Authentication mechanism. 


For information on WebSEAL authentication and changing from basic mode to the 

form-based mode refer to Tivoli Access Manager documentation at 


com.ibm.itame.doc_6.1/am61_webservers_admin74.htm#chpt4_amwebpi_authent: 

Protecting the vault key file 

To keep the encryption key for the administrator password secure, establish strict 

read-only access to the vault key file. 


The Tivoli Integrated Portal administrator ID (default is tipadmin) that was created 

during the installation needs access to the vault key file for Tivoli Integrated Portal 

applications to work properly. 


The vault key is an encryption key that is used to encrypt the administrator 

password that was provided during installation and is stored locally for Tivoli 

Integrated Portal applications. Use these steps to restrict access to the file. 

Procedure 

1. On the computer where the application server is installed, open the 

tip_home_dir/_uninst/TIPInstall2201 directory. 

2. Use the method provided by your operating system to ensure that the 

.vault.key file has read-only access. 

Example 

On Windows, for example, the attributes for the TIPInstall2201 directory are 

already set to read-only; those for the .vault.key file are set to read-only and 

hidden. 

Reference 325






Configuring access for HTTP and HTTPS 






After installing Tivoli Integrated Portal and before beginning this procedure, log in 

to the portal to ensure that it has connectivity and can start successfully. 


Configuring for HTTP and HTTPS console access involves editing the web.xml file 

of Web components. Use this procedure to identify and edit the appropriate Web 

XML files. 

Procedure 

1. Change to the following directory: tip_home_dir/profiles/TIPProfile/ 

config/cells/TIPCell/applications. 

2. From this location, locate the web.xml files in the following directories: 

v For the Integrated Solutions Console web application archive: 

isc.ear/deployments/isc/isclite.war/WEB-INF 

v For the Tivoli Integrated Portal Charts web application archive: 

isc.ear/deployments/isc/TIPChartPortlet.war/WEB-INF 

v For the Tivoli Integrated Portal Change Password web application archive: 

isc.ear/deployments/isc/TIPChangePasswd.war/WEB-INF 

3. Open one of the web.xml files using a text editor. 

4. Find the element. The initial value of all 

elements is CONFIDENTIAL, meaning that secure access 

is always required. 

5. Change the setting to NONE to enable both HTTP and HTTPS requests. The 

element now reads: NONE. 

6. Save the file, and then repeat these steps for the other web.xml deployment 

files. 

7. Log in to Tivoli Integrated Portal. 


and click Launch Websphere Administrative Console. 


Global security and click the External authorization providers link. 

10. In the External authorization providers page, select the Update with 

application names listed option. 

11. In the text pane, type isc and click Apply. 

12. In the messages area at the top of the page, click the Save link to commit your 

changes to the master configuration. 











Example 



The following example is a section of the web.xml file for TIPChangePasswd where 

the transport-guarantee parameter is set to NONE: 

 

 

ChangePasswdControllerServletConstraint 

 

ChangePasswdControllerServlet 

/* 

 

 

Roles 

administrator 

operator 

configurator 

monitor 

iscadmins 

 

 

NONE 

 

 


Users must now specify a different port, depending on the mode of access. The 

default port numbers are as follows: 

http://:16310/ibm/console 

Use the HTTP port for logging in to the Tivoli Integrated Portal on the 

HTTP port . 

https://:16311/ibm/console 

Use the HTTPS secure port for logging in to the Tivoli Integrated Portal. 



Reference 327




“Stopping and starting the application server” on page 343 

The Tivoli Integrated Portal Server starts automatically after it has been installed, 

and on systems running Windows, whenever the computer is started. 

Configuring the LPTA token timeout value 

You can configure the Lightweight Third Party Authentication (LTPA) token 

timeout value for Tivoli Integrated Portal in the WebSphere Application Server 

console. 


Tivoli Integrated Portal is enabled for single sign-on. 


The default timeout for an LTPA token is 120 minutes. An LTPA timeout causes 

you to be logged out from Tivoli Integrated Portal and can also cause an 

authentication popup message, if the first request after the timeout is an AJAX 

request from a portlet. To configure the LTPA token timeout: 

Procedure 

1. In the Tivoli Integrated Portal navigation pane, click Settings > WebSphere 

Admin Console. 

2. Click Launch WebSphere Admin Console to start the WebSphere Application 

Server console. 

3. In the WebSphere Application Server console navigation pane, click Security > 


4. In the Authentication area of the Global security page, click the LTPA link. 

5. In the LTPA timeout area of the LTPA page, edit the value for the LTPA timeout 

and click OK. 




In a load balanced environment, you must set the LTPA token timeout value on 

each of the Tivoli Integrated Portal Server instances. 

Deleting a data source definition 

Before you create a CMS data source, in some circumstance you many want to 

delete an existing data source definition. 


As part of the Data Integration Services (DIS) database creation, the DBConfig 

installer also creates an external CMS database. Tivoli Integrated Portal 

applications use an external CMS database to both publish their CMS launch 

definitions as well as to obtain the launch definitions from other products. Tivoli 

Business Service Manager creates a data source definition in WebSphere 

Application Server for the Data Integration Services (DIS) database, CMS infers the 

CMS external database location from this since the CMS tables are created in the 


DIS database. If the CMS external database tables reside in the DIS database, then 

there may not be an existing CMS data source and the DIS datasource is used 

instead. If this is the case then the data source does not need to be removed. 

To delete a data source: 

Procedure 

1. Run the following command to list existing data sources: 

$AdminConfig list DataSource ---> get DS name string 

2. Run the following command to remove the data source: 

$AdminConfig remove ds_name_string 

Where ds_name_string is the name of the data source that you want to remove. 

3. Save your changes: 

$save 

Configuring the CMS database 

The Context Menu Service (CMS) is a component of Tivoli Integrated Portal which 

can be used by TBSM to share information outside of the Tivoli Integrated Portal 

environment. 

CMS facilitates launch-in-context capability between products. The term 

launch-in-context is used to describe the ability for one application to invoke a 

function or launch a user interface provided by another application while also 

passing in data that the function or user interface may immediately process. CMS 

enables launch-in-context by allowing a product to register launch points for itself 

and locate launch points for other products. Launch points provide information to 

allow an application to invoke a function or user interface from another 

application. 

If you want to change the location of the CMS database after installation, you must 

update the Dashboard server. 

Creating a database for CMS: 

Copy CMS scripts from your Tivoli Integrated Portal installation to your remote 

computer and create a database. 


To create a remote database for CMS: 

Procedure 

1. On the computer running Tivoli Integrated Portal, at the command line, change 

to the following directory: 

tip_home_dir/profiles/TIPProfile/bin/cms 

The CMS directory contains a number of scripts that are provided by Tivoli 

Integrated Portal. The script that you use depends on the type of database and 

the operating system of the database computer: 

v db2_scripts.zip for a DB2 database 

v MsSql_scripts.zip for a Microsoft SQL Server 

database 

v Oracle_scripts.zip for an Oracle database 

Reference 329

v db2_scripts.tar for a DB2 database 

v MsSql_scripts.tar for a Microsoft SQL Server database 

v Oracle_scripts.tar for an Oracle database 

The steps described here reflect setting up a DB2 database on a on a Microsoft 

Windows system. 

2. Transfer a copy of the relevant script file from the CMS directory to your remote 

database computer and take note of the location in which you save the file. For 

example, for a DB2 database running on a Microsoft Windows system, you 

need to transfer a copy of db2_scripts.zip to the remote computer. 

3. On the remote database system, extract the file that you copied to a known 

location and at the command line change to that directory. 

For example, for a DB2 database: cd C:\demo\db2scripts\db2 

4. Open the CMS_database_type_Readme.txt file, in this case CMS_DB2_ReadMe.txt, 

in a text editor. 

This file provides instructions and samples on how to use the scripts provided. 

5. Open a database command window, so that you can execute database 

commands. 

For example, for a DB2 database running on a Windows system, click Start > 

IBM DB2 > DB2COPY1 (default) > Command Line Tools > Command 

Window. 

6. In the command window, change to the directory that contain your extracted 

script files. 

For example, cd demo\db2_scripts\db2 

7. Run the database setup command providing the relevant arguments to the 

parameters outlined in the CMS_database_type_Readme.txt file for the database 

setup command. 

For example, run CMS_DB2Setup.bat -d database_name -u database_user_name 

-p database_user_password . 

Where: 

database_name 

The name of the database that you want to create. You can also provide 

the name of an existing database. 

database_user_name 

The user name for the database. 

database_user_password 

The user password associated with the specified user name. 

The database is now ready to communicate with a Tivoli Integrated Portal data 

source. 


When you have set up a remote database, you can configure a data source in Tivoli 

Integrated Portal that CMS can use. 

Configuring a hostname to be used by CMS: 

Configure a hostname to be used by CMS. 



You need to set a hostname that CMS can use. For example, in a load balanced 

environment, it may not be obvious which hostname CMS should use. To specify a 

hostname to CMS: 

Procedure 

1. On the computer running Tivoli Integrated Portal, at the command line, change 

to the following directory: 

tip_home_dir/profiles/TIPProfile/bin/CMS 

2. Run the cmssetconf command to view details of the different options that are 

available to you in setting up CMS to use the remote database. 

./cmssetconf.sh 

cmssetconf.bat 

One of the settings that you apply using the cmssetconf command, is the 

hostname. 

3. Run the following command to specify the hostname that you want to use: 

./cmssetconf.sh -hostname hostname -port tip_port_number 

cmssetconf.bat -hostname hostname -port tip_port_number 

The hostname in now configured. 

4. Run the following command to review your CMS configuration and verify that 

you have correctly specified the hostname: 

./cmsshowconf.sh -hostname hostname -port tip_port_number 

cmsshowconf.bat -hostname hostname -port tip_port_number 













When you have configured the hostname, you can set up logging for CMS. 

Charting 

Administering charting involves assigning user IDs to roles, editing the general 

properties such as to specify the refresh interval, configuring another ITM Web 

Service, and configuring for localized charts. 

User roles for charting: 

Reference 331

Users must have the user IDs assigned to a chart role before they can see and 

work with the charting functions. 

The main administrator (tipadmin) of the application server already has the 

chartAdministrator role, and can assign users to any of the three chart roles that 

are available. Logged in users will have no access privileges to the charting 

features if their user ID has not been assigned to a chart role. These are the 

capabilities of the chart roles: 

chartAdministrator 

Users with this role can create and delete charting connections to data 

sources, download the BIRT Designer, upload charts, and can clear the 

charting cache (useful for troubleshooting). 

chartCreator 

Users with this role can download the BIRT Designer, upload charts, view, 

and edit them. They cannot create or delete chart connections nor can they 

clear the charting cache. 

chartViewer 

Users assigned to this role can select and view charts, but cannot modify 

them or their preferences. They cannot download the BIRT Designer, 

upload charts, create connections, or clear the charting cache. 

Roles are assigned through Users and Groups > Administrative User Roles. 

Modifying chart properties: 

You can change the directory where chart files are located or to fine tune the 

timing of chart refreshes. 


After a chart has been added to a console page, it is automatically refreshed with 

new data at intervals. The refresh rate is adjusted based on the response time of 

the Tivoli Integrated Portal Server. This ensures that the server is not overloaded 

with data requests and that it remains responsive. The algorithm for calculating the 

next refresh interval uses three parameters from the chart properties: 

Minimum refresh interval 

Maximum refresh interval 

Response time multiplier 


You can adjust the balance of chart refresh rate and server performance by using a 

tipcli command: 

Procedure 

1. On the command-line interface, change to the install_dir/profiles/ 

TIPProfile/bin/ directory. 

2. Run the following command declaring the chart property that you want to 

modify and its new value: 

tipcli.bat ChartProperties --[name parameter_name --value 

--parameter_value] --username user_name --password user_password 


tipcli.sh ChartProperties --[name 

parameter_name --value --parameter_value] --username user_name 

--password user_password 

The following list provides details on the arguments and parameters shown: 

parameter_name 

The chart property that you want to modify. The following parameters 

can be modified: 

v UPDATE_MAXIMUM_INTERVAL (Default value = 60) 

The default maximum interval between data refreshes is 60 seconds 

unless the server response time multiplied by the UPDATE_MULTIPLIER 

value is longer. Consider raising this number if the calculated 

interval often exceeds the maximum. 

v REPORT_OUTPUT_DIR (Default value = install_dir/temp/report) 

v AXIS_TIMEOUT (Default value = 9000) 

If the system times out or an error message is displayed while 

importing an Tivoli Monitoring chart, it is typically because the 

Tivoli Enterprise Portal Server is unavailable. You can extend the 

time period before the time out by increasing this value. 

v REPORT_INPUT_DIR (Default value = install_dir/report) 

v DBTABLE_VERSION (Default value = 1.1.1) 

v UPDATE_MINIMUM_INTERVAL (Default value = 30) 

The default shortest interval between data refreshes is 30 seconds 

unless the server response time multiplied by the UPDATE_MULTIPLIER 

value is lower. Consider raising this number if the calculated interval 

is often lower than the minimum. 

v UPDATE_MULTIPLIER (Default value = 10) 

parameter_value 

The value that you want to set for the declared property. 

user_name 

The user name of the Tivoli Integrated Portal user. 

user_password 

The password for the Tivoli Integrated Portal user. 

For example: 

tipcli.bat ChartProperties --[name UPDATE_MAXIMUM_INTERVAL 

--value --120] --username tipuser1 --password tipuserpassw0rd 

Configuring multiple ITM Web Services: 

Use this procedure if you want to display charts from more than one Tivoli 

Managed Network. 


During an advanced installation that includes the charting feature, you can also 

identify an ITM Web Service for retrieving attribute values into charts. In 

environments that have multiple managed networks, you can configure an 

additional ITM Web Service for each Tivoli Enterprise Portal Server. Follow this 

procedure to manually add another ITM Web Service to the same server instance. 

Reference 333

Procedure 

1. Copy the ITMWebServiceEAR.ear directory branch to a temporary location 

(such as c:\temp): from tip_home_dir/profiles/TIPProfile/installedApps/ 

TIPCell/. 

2. Rename the Web service in application.xml: 

a. At the command line, change to the temporary directory. 

b. In the temporary directory, open application.xml from 

tip_home_dir/profiles/TIPProfile/installedApps/TIPCell/ 

ITMWebServiceEAR.ear/META-INF/ in a text editor. 

c. Change the name ITMWebServiceEAR to 

ITMWebService2EAR. 

d. Change the name ITMWebService to 

ITMWebService2. 

3. Rename the Web service in webservice.properties.readme: 

a. At the command line, change to the temporary directory. 

b. In the temporary directory, open webservice.properties.readme from 

tip_home_dir/profiles/TIPProfile/installedApps/TIPCell/ 

ITMWebServiceEAR.ear/resources in a text editor. 

c. Change WEBSERVICE.NAME=ITMWebService to 

WEBSERVICE.NAME=ITMWebService2. 

d. Save the file as webservice.properties. 

4. Rename the ITMWebServiceEAR.ear directory to ITMWebService2EAR.ear in the 

temporary directory. 

5. Use the following example to guide you and create a script called 

installwebservice.jacl in the temporary directory : 

installwebservice.jacl: 

$AdminApp install c:/temp/ITMWebService2EAR.ear [ list -usedefaultbindings 

-defaultbinding.virtual.host default_host -MapRolesToUsers 

{{"chartViewer" No Yes "" ""}}] 

set deployment [$AdminConfig getid /Deployment:ITMWebService2EAR/] 

set deployedObject [$AdminConfig showAttribute $deployment deployedObject] 

set classloader [$AdminConfig showAttribute $deployedObject classloader] 

$AdminConfig showall $classloader 

$AdminConfig modify $classloader {{mode PARENT_FIRST}} 

$AdminConfig showall $classloader 

$AdminConfig save 

6. Use the following example to guide you and in the temporary directory create 

a script called installwebservice.cmd that will used to deploy the Web 

service: 

installwebservice.cmd: 

echo Installing Web Service 

set TIP="C:\IBM\tivoli\tipv2" 

set PROFILE=TIPProfile 

set TIPTOOLS=c:\tiptools 

set USERNAME=tipadmin 

set PASSWORD=tippass 

cd %TIP%\profiles\%PROFILE%\bin 

call wsadmin -f %TIPTOOLS%\installwebservice.jacl -username %USERNAME% 

-password %PASSWORD% 

echo All Done! 


7. Run the installwebservice.cmd script to deploy the Web service. 

8. Run these tipcli commands in tip_home_dir/bin/ to configure the username 

and password for the new Web service, adding the Web service name at the 

end of the command line: tipcli.bat ITMLogin --hostname localhost --port 

1920 --username sysadmin --password sysadm1n --servicename 

ITMWebService2 

9. Stop and then restart the Tivoli Integrated Portal Server. 

10. Add to the list of Web services in the Charting portlet, using the exact 

information as the default Web service, and changing only the Service Name. 





Configuring for localized or customized Tivoli Monitoring charts: 

National Language Version (NLV) text or customer-specific resource bundles from 

IBM Tivoli Monitoring applications are not displayed correctly in Charting. To 

include such resource bundles, you need to copy some files to your Tivoli 

Integrated Portal Server installation. 


This procedure involves copying the product resource jar files from the Tivoli 

Enterprise Portal Server to the application server and referencing them in the class 

path used by the ITM Web Service. 

Procedure 

1. Locate the *_resources.jar files on the computer where the Tivoli Enterprise 

Portal Server is installed: 

v itm_install_dir\CNB\classes 

v itm_install_dir/arch/cw/classes 

2. On the computer where the Tivoli Integrated Portal Server is installed, copy the 

*_resources.jar files to BIRTExtension/lib. 

3. Add the *_resources.jar file names to the class path in the MANIFEST.MF file of 

ITMWebService.jar: 

a. Copy ITMWebService.jar from tip_home_dir/profiles/TIPProfile/ 

installedApps/TIPCell/ITMWebServiceEAR.ear to a temporary directory. 

b. Decompress the file with this command: jar xvf ITMWebService.jar 

c. In a text editor, open MANIFEST.MF from the META-INF directory. 

d. Add the file names of the new jar files to the Class-Path entry, while being 

careful of file formatting: 

META-INF/MANIFEST.MF: 

Manifest-Version: 1.0 

Created-By: 2.3 (IBM Corporation) 

Class-Path: browser.jar cnp.jar cnp_vbjorball.jar ka4_resources.jar 

kfw_resources.jar kjrall.jar knt_resources.jar koq_resources.jar 

kor_resources.jar koy_resources.jar kp5_resources.jar kph_resources.jar 

kpk_resources.jar kpv_resources.jar kpx_resources.jar kqr_resources.jar 

kqv_resources.jar kqx_resources.jar kto_resources.jar kud_resources.jar 

kul_resources.jar kum_resources.jar kux_resources.jar kva_resources.jar 

ksy_resources.jar khd_resources.jar tap_cli.jar util.jar workspace.jar 

resources/ my_new_resources.jar 

Reference 335

e. Save and close MANIFEST.MF. 

4. From the temporary directory, compress the file with the following command 

and replace the old ITMWebService.jar with the updated file: 

jar cfm ITMWebService.jar META-INF\MANIFEST.MF com org 

5. If you are logged on to the portal, log off, and then complete the next two steps 

to restart the Tivoli Integrated Portal Server. 











Importing or exporting charts and chart customizations: 

You can import or export charts and chart customizations at the command line. 


To import or export a chart, or a chart customization: 

Procedure 

1. On the command-line interface, change to the tip_home_dir/profiles/ 

TIPProfile/bin/ directory. 

2. Run the following command to export chart data: 

tipcli.bat|.sh ChartExport --dir output_directory --type 

all|customcharts|page [--pageID page_ID | --pageName page_name] 

--username tip_username --password tip_user_password 

Export command options 

Use the Export command to create the specified directory (dir) and 

export the chart data to that directory. 

Table 19. ChartExport command arguments 

Parameter and arguments Description 

--dir output_directory Mandatory parameter. The directory where 

the exported data is saved. If the directory 

does not exist, it is created. 

--type all|customcharts|page Mandatory parameter. If you set the --type 

to all, then all charts are exported. If you 

set it to customcharts, then only customized 

charts are exported. If you set it to page, 

then you can use either the --pageID or the 

--pageName parameter to specify the page for 

which you want to export chart data. 


Table 19. ChartExport command arguments (continued) 


[--pageID page_ID | --pageName 

Optional parameter. If you set the --type 

page_name] 

parameter to page, then you can use either 

the --pageID or the --pageName parameter to 

specify the page for which you want to 

export chart data. 

--username tip_username Mandatory parameter. The user name for a 

user with either the chartAdministrator or 

chartCreator role. 

--password tip_user_password Mandatory parameter. The password for the 

specified user name. 

3. Run the following command to import chart data: 

tipcli.bat|.sh ChartImport --dir source_directory --username 

tip_username --password tip_user_password 

Import command options 

ChartImport is used to import chart data from a specified directory. 

Table 20. ChartImport command arguments 


--dir source_directory Mandatory parameter. The directory where 

the data to imported is located. BIRT 

Designer file format is .rptdesign. 






Configuring Charting and IBM Tivoli Monitoring 

You can configure a connection between a IBM Tivoli Monitoring server and a 

Charting portlet using the ITMWebService, with or without enabling single sign on 

(SSO). 

Configuring SSO between Charting and Tivoli Monitoring: 






v Install Tivoli Monitoring 6.2.2. You must configure Tivoli Monitoring Tivoli 

Enterprise Portal Server to use LDAP and SSO during the configuration step. 

Refer to Tivoli Monitoring documentation, but essentially you need to do the 

following: 

– During the Tivoli Enterprise Portal Server configuration, check the LDAP and 

SSO check boxes. Enter the information to connect to LDAP. 

– When the SSO configuration is displayed, enter defaultWIMFileBasedRealm for 

the realm name and your network domain for your domain name (for 

example, raleigh.ibm.com). 

Reference 337

– Export the LTPA keys to disk. For more information, see: 


com.ibm.websphere.express.doc/info/exp/ae/tsec_altpaexp.html. 

– Take a note of the password. 

– Copy the \ibm\itm\cnps\sqllib\kfwtipewas.properties file to the 

\ibm\itm\cnps directory and run reconfigure for the Tivoli Enterprise Portal 

Server. Once the reconfigure is complete, the web service feature is activated. 

v Install and configure Tivoli Integrated Portal to include the charting component. 


To configure SSO for the charting component and Tivoli Monitoring: 

Procedure 

1. Configure Lightweight Directory Access Protocol (LDAP) security in Tivoli 

Integrated Portal: 

a. Add and configure an LDAP repository. 

b. Configure Tivoli Integrated Portal to allow you to manage LDAP users in 

the portal. 

2. Configure Tivoli Integrated Portal for SSO. Make sure both Tivoli Monitoring 

and the embedded application server for Tivoli Integrated Portal use the same 

LTPA keys (import the LTPA keys you exported from Tivoli Monitoring), Realm 

names, and exchange SSL certificates. For more information, see: 


com.ibm.websphere.express.doc/info/exp/ae/tsec_altpaimp.html 

3. On the Tivoli Integrated Portal Server, change to tip_home_dir/profiles/ 

TIPProfile/bin and run the following command to configure Tivoli Integrated 

Portal to use SSO when communicating with Tivoli Monitoring: 

TEPS_hostname --port 15200 

tipcli.sh ITMLogin --hostname 

tipcli.bat ITMLogin --hostname TEPS_hostname --port 

15200 












5. Create the users in Tivoli Integrated Portal and assign them to a role that has 

privileges to view the charts from Tivoli Monitoring, such as 

chartAdministrator. 

6. Associate the same users that you created with a Tivoli Enterprise Portal user. 


a. Log into the Tivoli Enterprise Portal and associate that same user from 

LDAP with a Tivoli Enterprise Portal user. 

b. In Tivoli Enterprise Portal, select Edit --> Manage Users. 

c. Click the button to create a new user and enter the user ID and user name. 

To be consistent, you can use the same user ID as in Tivoli Integrated Portal. 

d. Enter the distinguished name. You can get this from the Tivoli Integrated 

Portal Manage Users panel. You may be able to find it using the Find button 

in the Tivoli Enterprise Portal. If you do not locate it with the Find button, 

copy and paste it from the Tivoli Integrated Portal Manage Users panel. It 

should look like this: uid=userID,o=IBM,c=US 

e. Give the user Workspace Administration Mode permission. 

Note: When you log into the Tivoli Integrated Portal, you cannot use sysadmin 

which is the default Tivoli Monitoring user or tipadmin which is the default 

Tivoli Integrated Portal user because neither of these users are in stored in the 

LDAP. 

7. When you have finished, follow these steps to test the configuration: 

a. Log into the Tivoli Integrated Portal as one of the users that you created with 

chart access. 

b. Create a new page using Settings > Page Management > New Page. 

c. Select the Charting portlet and click OK. 

d. Give the page a name and save it. 

e. Navigate to the charting portlet and select Tivoli Charts. 

f. In the table toolbar, click New to create a new connection and provide the 

necessary information to connect to the remote Tivoli Monitoring web 

service and click OK. For example: 

v Name: ITM 

v Protocol: http. This can be later changed to https if required but for 

testing purposes http is sufficient. 

v Hostname: TEPS_server_name.raleigh.ibm.com. This is the hostname of 

the Tivoli Enterprise Portal server, for example, tiv-isc09.ibm.com. 

v Port: 15200. If you use https, the default port is 15201. 

v Service name: TIPWebServiceHttpRouter. 

g. Select one of these groups. It will populate the table with the charts and 

tables from that Tivoli Monitoring workspace. 

h. Select a chart and click Finish. 

The chart is imported, which can take some time initially. When processing 

is complete, the chart is rendered in the portlet. If you do not see the chart, 

review any error messages and make sure you followed these steps 

correctly. 

Reference 339


“Configuring single sign-on” on page 291 


repository. 




“Configuring an external LDAP repository” on page 284 

You can configure the Tivoli Integrated Portal Server to communicate with an 

external LDAP repository. 

“Managing LDAP users in the console” on page 285 

To create or manage users in the portal that are defined in your LDAP repository, 

in the WebSphere Application Server administrative console specify the supported 

entity types. 

Configuring Charting with Tivoli Monitoring without SSO: 


Charting without single sign on (SSO) using the ITMWebService. 


v Install Tivoli Monitoring 6.2.2. Refer to Tivoli Monitoring documentation, but 

essentially you need to do the following: 

– Copy the \ibm\itm\cnps\sqllib\kfwtipewas.properties file to the 

\ibm\itm\cnps directory and run reconfigure for the Tivoli Enterprise Portal 

Server. Once the reconfigure process is complete, the web service feature is 

activated. 

Note: There are additional steps required if you have enabled SSL on the Tivoli 

Monitoring Tivoli Enterprise Portal Server. In that case, you need to install an 

interim fix available from the Tivoli Integrated Portal Level 3 support 

organization. 

v Install and configure Tivoli Integrated Portal to include the charting component. 


To configure the charting component and Tivoli Monitoring, without SSO: 

Procedure 

1. On the Tivoli Integrated Portal Server, change to tip_home_dir/profiles/ 

TIPProfile/bin and run the following command to configure Tivoli Integrated 

Portal to use the specified login and password when communicating with 

Tivoli Monitoring: 

tipcli.sh ITMLogin --hostname 

TEPS_hostname --port 15200 -–servicename service_name 

tipcli.bat ITMLogin --hostname TEPS_hostname --port 

15200 -–servicename service_name 

Where service_name is a unique text string of your choice, for example, ITM1. 

This argument allows you to connect to multiple Tivoli Monitoring systems. 

Take note of the service_name entry, as you will need it for step 7 on page 341. 

2. Verify that the itm.properties file has been created in the following directory: 


v tip_home_dir/tipv2Components/ 

BIRTExtension/integration/properties/ 

v tip_home_dir\tipv2Components\BIRTExtension\integration\ 

properties\ 

3. Log into Tivoli Integrated Portal and create a charting connection, as follows: 

a. In the navigation pane, click Settings > Pages. 

b. In the Pages page, click New Page. 

4. In the page that is displayed, provide a name for the page and select a page 

type, that is, classic or freeform and click OK. 

5. Select the Charting portlet. 

The procedure for selecting a portlet varies depending on the type of page 

you decide to create. For example, if you create a classic page, you must select 

the Charting portlet from a list and click OK, whereas, if you create a 

freeform page, you must click and drag the Charting portlet from the portlet 

palette to the content area. 

6. In the Charting portlet, click IBM Charts. 

7. In the IBM Charts page, click the New icon and provide details in the relevant 

fields to connect to the remote the ITMWebService. 

Table 21. ITM connection values. This table provides detail of the values that you should 

provide for the remote ITMWebService connection. 

Field name Description 

Name Enter the name that you specified as the 

service_name in step 1 on page 340. 

Protocol http - This can be later changed to https, if 

required, but for testing purposes http is 

sufficient. 

Hostname TEPS_hostname - This is the hostname of the 

Tivoli Enterprise Portal Server, for example, 

tiv-isc09.ibm.com. 

Port 15200 - If you use https, the default port is 

15201. 

Note: If you use https, you must also run 


v 


tipcli.sh ConfigureBIRTForSSL 

v tip_home_dir\profiles\ 

TIPProfile\bin\tipcli.bat 

ConfigureBIRTForSSL 

Service Name TIPWebServiceHttpRouter 

Credentials options Select the Always use these credentials 

option. 

Username Provide a username for connecting to the 

Tivoli Monitoring ITMWebService, for 

example, syadmin. 

Password Provide the password associated with the 

specified username. 

Reference 341

8. Click Create and save the details for the Charting portlet. The new connection 

to TIPWebServiceHttpRouter on the Tivoli Monitoring server is established. 

9. If required, create users in Tivoli Integrated Portal and assign them to a role 

that has privileges to view the charts from Tivoli Monitoring, such as 

chartAdministrator. 

10. When you have finished, follow these steps to test the configuration: 

a. Log into the Tivoli Integrated Portal as one of the users that you created 

with chart access. 

b. Create a new page using Settings > Pages > New Page. 

c. Select the Charting portlet and click OK. 

d. Give the page a name and save it. 

e. Navigate to the charting portlet and select IBM Charts. 

f. Select one of the configured connections. The table with the charts is 

populated with the charts and tables from the Tivoli Monitoring 

workspace. 

g. Select a chart and click Finish. 

The chart is imported, which can take some time initially. When processing 

is complete, the chart is rendered in the portlet. If you do not see the chart, 

review any error messages and make sure you followed these steps 

correctly. 

Administering 

The administrator tasks involve configuring and customizing the environment and 

controlling access to it. 

In a single installation the Tivoli Integrated Portal provides a product design 

environment and customization, with services that enable multiple-product 

integration. 

Logging in 



The Tivoli Integrated Portal Server must be running before you can connect to it 

from your browser. 


Complete these steps to log in: 

Procedure 

1. In a Web browser, enter the URL of the Tivoli Integrated Portal Server: 

http://host.domain:16310/ibm/console or https://host.domain:16311/ibm/ 

console if it is configured for secure access. 

v host.domain is the fully qualified host name or IP address of the Tivoli 

Integrated Portal Server (such as MyServer.MySubdomain.MyDomain.com or 

9.51.111.121, or localhost if you are running the Tivoli Integrated Portal 

Server locally). 

v 16310 is the default nonsecure port number for the portal and 16311 is the 

default secure port number. If your environment was configured with a port 


number other than the default, enter that number instead. If you are not sure 

of the port number, read the application server profile to get the correct 

number. 

v ibm/console is the default path to the Tivoli Integrated Portal Server, 

however this path is configurable and might differ from the default in your 

environment. 

2. In the login page, enter your user ID and password and click Log in. This is 

the user ID and password that are stored with the Tivoli Integrated Portal 

Server. 

Attention: After authentication, the web container used by the Tivoli 

Integrated Portal Server redirects to the last URL requested. This is usually 

https://:/ibm/console, but if you manually change the page 

URL, after being initially directed to the login page, or if you make a separate 

request to the server in a discrete browser window before logging in, you may 

be redirected unexpectedly. 

Note: If you have more than one instance of the Tivoli Integrated Portal Server 

installed on your computer, you should not run more than one instance in a 

browser session, that is, do not log in to different instances on separate browser 

tabs. 

Results 

After your user credentials have been verified, the Welcome page is displayed. If 

you entered the localhost or port number incorrectly, the URL will not resolve. 

View the application server profile to check the settings for localhost, port, and 

user ID. 


Select any of the items in the navigation tree to begin working with the console. 

While you are logged into the Tivoli Integrated Portal Server, avoid clicking the 

browser Back button because you will be logged out automatically. Click Forward 

and you will see that your are logged out and must resubmit your credentials to 

log in again. 







“Configuring access for HTTP and HTTPS” on page 326 





Stopping and starting the application server 



Reference 343


You can manually stop the Tivoli Integrated Portal Server before beginning certain 

configuration tasks or as needed. 

Note: For environments using a central user repository, for example LDAP, a user 

must be given the Administrator role in the WebSphere Application Server 

administrative console before they can stop the Tivoli Integrated Portal Server. For 

information on assigning WebSphere Application Server roles, see: 


com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_tselugradro.html 

Procedure 











Port assignments 


The sequence of ports is supplied during installation in the response file. The 

installer checks that the number of required ports (starting with the initial port 

value) are available before assigning them. If one of the ports in the sequence is 

already in use, the installer automatically terminates the installation process and 

you must specify a different range of ports in the response file. 








Viewing the application server profile 




The profile of the application server is available as a text file on the computer 

where it is installed. 


Procedure 

1. Locate the tip_home_dir/profiles/TIPProfile/logs directory. 

2. Open AboutThisProfile.txt in a text editor. 

Example 

This is the profile for an installation on in a Windows environment as it appears in 

tip_home_dir\profiles\TIPProfile\logs\AboutThisProfile.txt: 

Application server environment to create: Application server 

Location: C:\IBM\tivoli\tipv2\profiles\TIPProfile 

Disk space required: 200 MB 

Profile name: TIPProfile 

Make this profile the default: True 

Node name: TIPNode Host name: tivoliadmin.usca.ibm.com 

Enable administrative security (recommended): True 

Administrative consoleport: 16315 

Administrative console secure port: 16316 

HTTP transport port: 16310 

HTTPS transport port: 16311 

Bootstrap port: 16312 

SOAP connector port: 16313 

Run application server as a service: False 

Create a Web server definition: False 


If you want to see the complete list of defined ports on the application server, you 

can open tip_home_dir/properties/TIPPortDef.properties in a text editor: 


#Mon Oct 06 09:26:30 PDT 2008 













“Port assignments” on page 279 








Changing passwords 



Reference 345


When you log in to the portal, you can change your own password using the 

Change Your Password portlet. Administrators can change passwords for other 

users using the Manage Users portlet. 

Attention: If you are an administrator and you want to change the password for 

the tipadmin administrator and the Tivoli Netcool/OMNIbus ObjectServer root 

user, you must use the Settings > Change Your Password portlet to change their 

password. Do not use the Users and Groups > Manage Users portlet. 

Tip: For security reasons, change the password of the Tivoli Netcool/OMNIbus 

ObjectServer root user after installation. 

To change passwords: 

Procedure 

v To change your own password, follow these steps: 

1. Log in to the portal using the user ID whose password you would like to 

change. 

2. In the navigation pane, click Settings > Change Your Password. 

3. Enter your new password in the relevant fields and click Set Password. 

v As an administrator, to change the password for a user, follow these steps: 

1. In the navigation pane, click Users and Groups > Manage Users and click 

the user's name from the User ID column. A User Properties page is 

displayed. 

2. In the General tab, enter the new password in the relevant fields and click 

OK. 

Attention: 

If you authenticate to a Microsoft Active Directory server, it must be 

configured for SSL before you can use the Change Your Password portlet. If 

SSL is not enabled, you will receive an error when attempting to change the 

password for any user who is registered on the Active Directory Server. 

TIPCP0005E Could not set the password via the underlying security system. 

This could be because a password rule was not met, you do not have 

access to change the password, or another reason. 


“Configuring an SSL connection to an LDAP server” on page 287 

If your implementation of Tivoli Integrated Portal uses an external LDAP-based user 

repository, such as Microsoft Active Directory, you can configure it to communicate 

over a secure SSL channel. 




Exporting and importing 

You can export customized configuration data from an existing Tivoli Integrated 

Portal installation to another by exporting the data and subsequently importing the 

exported data. 

Exporting and importing customized settings can be done at the command line 

through the tipcli.bat|.sh Export and tipcli.bat|sh Import commands. 


Note: The tipcli.bat|.sh Export and tipcli.bat|sh Import commands are case 

sensitive. Also, if you make a typing error, that is, if you type a parameter 

incorrectly, or use the incorrect case, then the commands runs as if no parameters 

were specified and no warning message is displayed. 

You can export and import the following elements: 

v Custom pages and customized system page elements, with the exception of core 

and system pages, including: 

– Page name and layout. 

– Portlet entities. 

Note: Copies of a portlet entity are not exported; either through the console 

Export Wizard or through the tipcli.bat|.sh Export command. 

– View profiles. 

– Events and wires. 

– Access permissions. 

– Navigation structure. 

v Custom views (or customized system views). 

Note: You can also export pages associated with a view if the exportpageinview 

parameter is set to true. 

v Custom roles, including: 

– Role name, creation date, and update date. 

– Role mapping information in relation to users and groups. 

– Associated role preference, that is, the relevant console preference profile. 

v Console properties and customization properties, including: 

– Transformations. 

– Themes and images. 

– Bundles. 

In a load balanced environment the import operation migrates imported elements 

across all the computers in the pool, with following conditions: 

v All the required applications (WAR files) must be deployed on all computers in 

the pool. 

v The load balanced pool configuration must be locked during the import 

operation. 

v The import operation must be ran on one of the nodes in the pool. 

Restriction: In a load balanced environment that includes charting, the 

ListRestore command only runs successfully on the node that is used for the 

import operation because backup files are stored locally on that node and are 

not synchronized across other nodes in the cluster. 

v You must provide the load balancing manager an updated file list to update the 

load balancing scope. The migration tool plugin provides the file list. 

v The load balanced pool configuration, can then be unlocked. 

v The import of transformations in a load balanced environment is not supported. 

Transformations must be imported to each node independently. 

The haSupport command controls this aspect of the import operation: 

– IfitissettoTrue, then only load balancing information is imported, that is, 

no transformation data. 

Reference 347

– IfitissettoFalse, then only transformation data is imported, that is, no load 

balancing data. 

– IfitissettoBoth, then transformation data and load balancing data is 

imported. 


“tipcli - Export plugins” on page 382 

Use the Export command to export customization data for an instance of Tivoli 

Integrated Portal. Use the ListExportPlugins command to list plugins that are 

available for export. 

“Import tipcli commands” on page 385 

tipcli commands for importing Tivoli Integrated Portal data. 

Basic export commands: 

You can export pages, views and profile preferences using the basic export 

commands. 

Exporting pages in simplified mode: 

By using the ExportPage command you can export specific pages without having 

to provide additional qualifying parameters. 


Ensure that the Tivoli Integrated Portal Server is running. 


To export specific pages in simplified mode for an instance of Tivoli Integrated 

Portal: 

Procedure 

1. At the command line change to: tip_home_dir/profiles/TIPProfile/bin. 

2. To return a list of customized pages that can be exported, run the following 

command: 

v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat 

ListPages --customizePages true 

v tip_home_dir/profiles/TIPProfile/bin/ 

tipcli.sh ListPages --customizePages true 

Note: The page ID is the last element of the returned records, for example, the 

page ID for the following record is BIXRjLkKYngNsRavnu0fYpx1279539744250: 

com.ibm.isclite.global.custom.module-SPSVScom.ibm.isclite.admin.PortletPicker.navigationElement 

.pagelayoutA 

.modified.BIXRjLkKYngNsRavnu0fYpx1279539744250 

3. Review the list of returned page records and take note of the page IDs for the 

pages that you want to export. 

4. To export specific pages, run the following command: 



ExportPage --uniqueName pageID_1,pageID_2,pageID_3 --username 

tipadmin_user_name --password tipadmin_password


tipcli.sh ExportPage --uniqueName pageID_1,pageID_2,pageID_3 

--username tipadmin_user_name --password tipadmin_password 

Note: The file portletEntities.xml is always exported, even if you specify 

NONE as an argument to the uniqueName parameter. 

Results 

When the command completes, a Data.zip file is created in tip_home_dir/ 

profiles/TIPProfile/output/. 


Locate tip_home_dir/profiles/TIPProfile/output/Data.zip and copy it to the 

computer where you intend to apply the exported customization data. 

Exporting views in simplified mode: 

By using the ExportView command you can export specific views without having 

to provide additional qualifying parameters. 




To export specific views in simplified mode for an instance of Tivoli Integrated 

Portal: 

Procedure 


2. Optional: To return a list of customized views that can be exported, run the 



ListViews 


tipcli.sh ListViews 

3. Review the list of returned view records and take note of the view IDs for the 

views that you want to export. 

4. To export specific views, run the following command: 


ExportView --uniqueName viewID_1, viewID_2, viewID_3 


tipcli.sh ExportView --uniqueName viewID_1, viewID_2, viewID_3 



Reference 349

Results 






Exporting console preference profiles in simplified mode: 

By using the ExportProfile command you can export console preference profiles 

without having to provide additional qualifying parameters. 




To export console preference profiles in simplified mode: 

Procedure 


2. Optional: To return a list of console preference profiles that can be exported: 


ListPreferenceProfiles 


tipcli.sh ListPreferenceProfiles 

3. Review the list of returned records and take note of the unique names for the 

console preference profiles that you want to export. 

4. To export specific console preference profiles, run the following command: 


ExportProfile --uniqueName profile_ID1,profile_ID2,profile_ID3 


tipcli.sh ExportProfile --uniqueName 

profile_ID1,profile_ID2,profile_ID3 



Results 







Advanced export commands: 

You can use the advanced tipcli Export commands and apply a number of 

parameters to define which items you want to include and exclude in relation to 

the export operation. 

Exporting all customization data: 

You can export all customization data for an instance of Tivoli Integrated Portal in 

one command. 




To export all customization data for an instance of Tivoli Integrated Portal: 

Procedure 


2. Optional: To return a list of plugins that will be run during the export 

operation, run the following command: 


tipcli.sh ListExportPlugins 


ListExportPlugins 

3. To export all customization data, run the following command: 


tipcli.sh Export --username tipadmin_user_name --password 

tipadmin_password 

v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat Export 


Results 

When the Export command completes, a Data.zip file is created in 

tip_home_dir/profiles/TIPProfile/output/. 

Note: 

Refer to the links at the end of the page to view details of customs parameters that 

can be applied to the Export command. 




Exporting using a properties file: 

You can specify your export requirements in properties file instead of specifying 

your requirements using separate parameters at the command line. 

Reference 351


By default, the tipcli command uses the tip_home_dir/TIPProfile/etc/ 

tipcli.properties file unless this behavior is overridden by the specifying a 

discrete settings file using the settingFile parameter. 



To export customization data using a properties file: 

Procedure 

1. Create a properties file that specifies the data that you want to export and save 

it as export-settings.properties in a known location. 

Below is example content for an export properties file: 

import.includePlugins=ImportPagePlugin 

export.includePlugins=ExportPagePlugin 

import.backupDir=c:/tmp/bkups 

export.exportFile=c:/tmp/extest.zip 

import.importFile=c:/tmp/extest.zip 

username=tip_admin_user 

password=tip_admin_password 

import.haSupport=true 

Note: Some parameters are import or export specific. Import specific 

parameters should be prefixed by import. and export specific parameters 

should be prefixed by export.. For example, import.backupDir=c:/tmp/bkups. 


3. To export customization data based on the contents of a specific properties file, 

run the following command: 



tipadmin_password --settingFile export_properties_file 



--settingFile export_properties_file 

Where: 

export_properties_file 

An argument to the settingFile parameter that provides the location 

and name of the export properties file, for example, 

C:\\tmp\\export.properties. 

Note: You must use double backslashes characters (\\) 

when specifying the path to your settings file. 

Note: If there is a conflict between settings specified in the properties file and 

parameters provided at the command line, then the command line parameters 

take precedence. 


Results 

When the Export command completes, a extest.zip file is created in the root 

temporary directory, for example on Windows systems the file is saved in c:\tmp. 


Locate extest.zip and copy it to the computer where you intend to apply the 

exported customization data. 

Exporting specific pages: 

When exporting Tivoli Integrated Portal data, you can specify that you want to 

export particular pages. 




To export specific pages for an instance of Tivoli Integrated Portal: 

Procedure 


2. To return a list of customized pages that can be exported, run the following 

command: 


ListPages --customizePages true 


tipcli.sh ListPages --customizePages true 

Note: The page ID is the last element of the returned records, for example, the 

page ID for the following record is BIXRjLkKYngNsRavnu0fYpx1279539744250: 

com.ibm.isclite.global.custom.module-SPSVScom.ibm.isclite.admin.PortletPicker.navigationElement 

.pagelayoutA 

.modified 

.BIXRjLkKYngNsRavnu0fYpx1279539744250 

3. Review the list of returned page records and take note of the page IDs for the 

pages that you want to export. 

4. To export specified pages, run the following command: 



tipadmin_password --pages pageID_1, pageID_2, pageID_3 


--username tipadmin_user_name --password tipadmin_password --pages 

pageID_1, pageID_2, pageID_3 

Reference 353

Results 






Exporting specific views: 

When exporting Tivoli Integrated Portal data, you can specify that you want to 

export particular views. 




To export specific views for an instance of Tivoli Integrated Portal: 

Procedure 


2. Optional: To return a list of customized views that can be exported, run the 



ListViews 


tipcli.sh ListViews 

3. Review the list of returned view records and take note of the view IDs for the 

views that you want to export. 

4. To export specific views, run the following command: 



tipadmin_password --views viewID_1,viewID_2,viewID_3 

--exportpageinviews [true|false] 


--username tipadmin_user_name --password tipadmin_password --views 

viewID_1,viewID_2,viewID_3 --exportpageinviews [true|false] 

Where: 

exportpageinviews 

An optional parameter, when set to true ensures that you also export 

pages associated with the views that you have specified. 

Note: Whether the optional parameter exportpageinviews is set to true or 

false, if a view has a default node in the navigation pane associated with it, 

then the page associated with the node is always exported. This is also true, 

even if you specify NONE as the argument to the --pages parameter. 


Results 






Rules for exporting: 

When exporting customized configuration data, it is important to know the rules 

governing the export function and the options available to you. 

The following rules apply when exporting customized configuration data from a 

Tivoli Integrated Portal environment: 

Rules and options for pages 

Rule 

1. You can export a particular page by page ID or choose to export all 

pages. 

2. You can export pages associated with a particular view. 

3. You can export pages that are associated with a particular portlet from 

a particular WAR. 

4. If a page contains multiple portlets, but only some from a specified 

WAR, then all elements of the page are exported. 

5. Pages that are targets of a wire for a specified page are exported. 

6. The default export scope is All if you do not define pages to be 

exported under rule 2 and rule 3. 

7. The default export scope is NONE if you define pages to be exported 

under rule 2 and rule 3. 

Rules and options for views 

1. You can export a particular view by view ID or choose to export all 

views. 

2. You can optionally export all views that contains a specified page. 

3. The default export scope is All. 

4. You can optionally export all pages associated with the views that you 

want to export. 

5. If an view has a default node in the navigation pane associated with it, 

then that page is automatically exported with the view. 

6. Views that match the following conditions should not be exported as 

the subsequent import of that view will fail: 

v An empty view, that is, a view that contains no pages or roles. 

v A view that contains roles, but no pages. 

v A view that contains empty pages, that is, the page exists but it does 

not contain portlets. 

Rules and options for custom roles and role preferences (console preference 

profiles) 

1. You can export a particular role by role ID or choose to export all roles. 

Reference 355

2. You can export a custom role and role preference that is associated with 

a specified page or view. 

3. The default export scope is set to All, unless the 

includeEntitiesFromApps parameter has been specified for a page or 

view, whereby it is then set to REQUIRED. 

4. If a console preference profile has a custom view as its default view, 

then that view is automatically exported. If the exported view has a 

default node in the navigation pane, then the associated page is 

automatically exported with the view. 

Rules and options for user preferences 

1. You can export user preferences by user ID or choose to export 

preferences for all users. 

2. The default export scope is set to All, unless the 

includeEntitiesFromApps parameter has been specified for a page or 

view, whereby it is then set to REQUIRED. 

Rules and options for console properties and customization properties 

All console properties and customization properties are exported. 

Rules and options for transformations 

All transformations are exported. 

Import commands: 

You can use the tipcli Import commands and apply a number of parameters to 

define which items you want to include and exclude in relation to the import 

operation. 

Importing previously exported data: 

You can import data that was exported from another instance of Tivoli Integrated 

Portal. 



Ensure that you have run the export operation on an originating instance of the 

Tivoli Integrated Portal Server and that you have copy the output file (data.zip) to 

the following directory on the other instance: 

tip_home_dir/profiles/TIPProfile/output 


To import data from a data.zip file that was exported from another instance Tivoli 

Integrated Portal Server: 

Procedure 


2. Optional: To return a list of plugins that will be run during the import 

operation, run the following command: 



ListImportPlugins


tipcli.bat ListImportPlugins 

3. To import the customization data, run the following command: 

v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat Import 



tipcli.sh Import --username tipadmin_user_name --password 

tipadmin_password 

Results 

When the Import command completes, the imported data is merged with the 

existing Tivoli Integrated Portal environment. 

Rolling back imports: 

After you import data you can rollback your configuration to the pre-import state 

provided you have made no changes to the environment. 


If you have performed multiple imports, you can also consecutively rollback 

individual imports. In all cases, you must have not had made changes to the 

environment. 



To roll back imports for a Tivoli Integrated Portal environment: 

Procedure 


2. To rollback an import, run the following command: 

v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat Import 

--rollback ALL 


tipcli.sh Import --rollback ALL 

When the command completes successfully, the Tivoli Integrated Portal 

environment is restored to the state that prevailed before the latest import 

operation was performed. 

3. Optional: If you performed multiple imports and you want to roll back more 

than the most recent import operation, you can re-run the tipcli.bat Import 

--rollback ALL command. You can re-run the rollback command multiple 

times to consecutively roll back a number of import operations. 

When you re-run the rollback command a second or subsequent time, the Tivoli 

Integrated Portal environment is restored to the state that prevailed prior the 

settings for that particular import operation being applied. 

Rules for importing: 

Reference 357

When importing customized configuration data, it is important to know the rules 

governing the import function and the options available to you. 

The following rules apply when importing customized configuration data for a 

Tivoli Integrated Portal environment: 

Rules and options for pages 

Rule 

1. You can import all pages included in an exported package. 

2. You can exclude system customized pages that do not exist in the new 

environment. 

3. You can exclude pages associated with a WAR that is not deployed in 

the new environment and thereby avoid introducing empty pages. 

4. If a page contains multiple portlets and some of portlets are associated 

with a WAR that is not deployed in the new environment, the page is 

not imported. 

Rules and options for views 

1. All views included in an exported package are imported. 

2. Views that match the following conditions should not be imported as 

the import operation for the view fails: 

v An empty view, that is, a view that contains no pages or roles. 

v A view that contains roles, but no pages. 

v A view that contains empty pages, that is, the page exists but it does 

not contain portlets. 

Rules and options for custom roles and role preferences (console preference 

profiles) 

All roles included in an exported package are imported. 

Rules and options for user preferences 

All user preferences included in an exported package are imported. 

Rules and options for console properties and customization properties 

All console properties and customization properties included in an 

exported package are imported. 

Rules and options for transformations 

All transformations included in an exported package are imported, if the 

haSupport parameter is set to Both or False. 

Table 1 provides details how various elements are processed during import: 

Table 22. Rules for overwriting and merging during import 

Element Action Comments 

Pages Overwritten In relation to pages, roles are 

merged, view memberships 

remain unchanged, and 

positions are modified. 

Views Overwritten In relation to views, existing 

page memberships are 

merged with imported pages 

Roles Skipped In relation to roles, user and 

group mappings are merged. 

Console preference profiles Skipped 


Table 22. Rules for overwriting and merging during import (continued) 

Element Action Comments 

Credential data Merged 

Property files Merged 

Transformations Skipped 

Charts Overwritten 

Changing the default security registry 

The default security registry can be set at install time. Use this procedure to change 

the default registry after installation. 


These steps require that your user ID has the Administrator role and that you 

know the base entry value of your repository. For LDAP or Microsoft Active 

Directory, this is usually a string like ou=company,dc=country,dc=region. For the 

ObjectServer, the base entry is o=netcoolObjectServerRepository. 


If you want to change the default to a different registry, complete these steps: 

Procedure 

1. Log into the Tivoli Integrated Portal. Your ID must have the Administrator role. 



3. In the WebSphere Application Server administrative console navigation pane, 

click Security > Secure administration, applications, and infrastructure. 

4. In the User account repositories area, select Federated repositories from the 

Available realm definitions, then click Configure. 

5. Click Supported entity types under Additional Properties. 

6. Click the entity type, then edit the Base entry for the default parent and 

Relative Distinguished Name properties. 

7. After you click OK to save your changes, repeat the previous step to configure 

the other entity types. For Microsoft Active Directory, the entity types 

(PersonAccount, Group, and OrgContainer) must be configured with a base DN 

and the RDN for PersonAccount should be cn instead of uid. 











Reference 359







CGI support 

Use the initialization parameters to control the behavior of CGIServlet. 

CGIServlet 

CGI scripts run on a Web server and use the Common Gateway Interface (CGI) to 

perform tasks. The support for CGI in Tivoli Integrated Portal is provided by 

CGIServlet, extracted from Apache Tomcat. The Tomcat CGI support is largely 

compatible with the Apache HTTP Server but there are some limitations (such as 

only one cgi-bin directory). To change the configuration, edit web.xml in the 

directory where the CGI application is installed. 

Servlet initialization parameters 

Several initialization parameters are available for configuring the behavior of the 

CGIServlet. 

cgiPathPrefix 

The CGI search path will start at the Web application root directory + 

File.separator + this prefix. Default setting: cgiPathPrefix is Web-INF/cgi. 

debug Determines the level of debugging detail for messages that are logged by 

the servlet. Default setting: 0. 

executable 

This is type of the program to be used to run the script. Default setting: 

perl. 

parameterEncoding 

Names the parameter encoding to be used with the CGI servlet. Default 

setting: System.getProperty("file.encoding","UTF-8"). 

passShellEnvironment 

Determines whether shell environment variables, if there are any, shall be 

passed to the CGI script. Default setting: false. 

Backing up and restoring the Deployment Engine 

Use the Deployment Engine (DE) backup script before installing additional 

components or other products that are based on the Tivoli Integrated Portal 

platform. If you need to recover the original configuration after a failure, you can 

then run the Deployment Engine restore script. 


The Deployment Engine performs the installation of new and upgraded products. 

It keeps track of the installed components and skips installing a given component 

if it is already present on the system. Perform the following steps to back up or 

restore the DE database. 


Procedure 

1. From the command line, change to the acsi directory: 

v cd C:\Program Files\IBM\Common\acsi 


the acsi directory varies depending on whether you are installing as root or 


– Installing as a non-root user, the path is relative to the user's home 

directory: 

/.asci_ 

– Installing as root, the path is as follows: 

/var/ibm/common/asci 

2. Initialize the Deployment Engine environment from the command line: 

v setenv.bat 

v . setenv.sh 

3. Change to the bin directory: 

v Change to the bin child directory, that is: 

C:\Program Files\IBM\Common\acsi\bin 


the bin directory varies depending on whether you are installing as root or 


– For a non-root user, change to the bin child directory, that is: 

/.asci_/bin 

– For root, the path is as follows: 

/usr/ibm/common/asci/bin 

4. Run the backup script to back up the Deployment Engine database, as follows: 

v de_backupdb.cmd 

v de_backupdb 

5. If you need to restore the Deployment Engine database, from the bin directory 

run the restore script: 

v de_restoredb.cmd 

v de_restoredb 


If you backed up the Deployment Engine database, you can run the installer now 

to add additional components or products. If you restored the Deployment Engine 

database, you can resume using the original installed environment. 

Setting Java Virtual Machine memory for TIPProfile 

You can increase the amount of memory available to the Tivoli Integrated Portal. 


To increase (or decrease) the amount of memory available to the Java Virtual 

Machine (JVM), carry out the following steps: 

Reference 361

Procedure 

1. Manually stop the application server. 

2. Change to the tip_home_dir/profiles/TIPProfile/bin directory. 

3. Use the wsadmin command to increase the heap size for the JVM, as follows: 

wsadmin.sh -lang jython -conntype NONE 

4. At the wsadmin> prompt, issue the following commands, where xxx is the new 

heap size value, in megabytes. 

jvm=AdminConfig.list("JavaVirtualMachine") 

AdminConfig.modify(jvm, ’[[initialHeapSize xxx]]’) 

AdminConfig.modify(jvm, ’[[maximumHeapSize xxx]]’) 

AdminConfig.save() 

exit 

5. Restart the Tivoli Integrated Portal Server. The changes take effect when the 

Tivoli Integrated Portal Server is restarted. 

Attention: If you attempt to start the Tivoli Integrated Portal Server with a 

maximum heap size that is too large, error messages that are similar to the 

following are generated in the tip_home_dir/profiles/TIPProfile/logs/ 

server1/native_stderr.log file: 

JVMJ9GC019E -Xms too large for -Xmx 

JVMJ9VM015W Initialization error for library j9gc23(2): Failed to initialize 

Could not create the Java virtual machine. 





Checking hostname settings 

The value of the Hostname property in the tip_home_dir/properties/ 

tip.properties file is used by Tivoli Integrated Portal to convert incoming browser 

requests (for example, http://:16310) to the appropriate Tivoli 

Integrated Portal non-secure access (for example, http://:16315)/ 

ibm/console), which is then converted to the Tivoli Integrated Portal secure access 

(for example, https://:16316/ibm/console/login.jsp). 


The Hostname property should contain the fully qualified hostname. This is 

required if the web browser being used to access Tivoli Integrated Portal is 

running on a machine in a different DNS domain to the Tivoli Integrated Portal 

Server (application server). 

The value of the tip_home_dir/properties/tip.properties file's Hostname entry is 

set during installation by a routine built into Java that checks the /etc/hosts (or 

%WinDir%\system32\drivers\etc\hosts) entry for the system; if the fully qualified 

domain name (FQDN) is not set in /etc/hosts, the Java routine returns either the 

short name or the IP address of the machine, depending on the type of operating 

system (all but AIX). 

Therefore, before the Tivoli Integrated Portal installer is run, ensure that a line exists 

in /etc/hosts of the following form: 

IP address FQDN shortname 

For example: 9.10.11.12 yourserver.domainname.com yourserver 


This line ensures that the FQDN is set as the Hostname entry at install time in 

tip_home_dir/properties/tip.properties. 

If you try to connect to the application server and the URL conversion to the 

non-secure access appears to be working incorrectly, you should check Hostname 

property entry in tip.properties. 

Procedure 

1. Open the tip_home_dir/properties/tip.properties file in a text editor. 

2. Check the Hostname property and make sure the value can be correctly 

resolved by the web browser being used to access the application server. 

3. Edit the Hostname entry to the FQDN of the application server and save the 

changes. 

4. Stop and restart the application server. The changes take effect when the 

application server is restarted. 





Accessing Context Menu Service features 

To access Context Menu Service features from within Tivoli Integrated Portal, you 

must be assigned the Monitor role in Tivoli Integrated Portal. 


The Context Menu Service, a component of Tivoli Integrated Portal, facilitates 

launch-in-context capability between products. This capability enables one 

application to invoke a function or launch a user interface that is provided by 

another application while also passing data that the function or user interface can 

immediately process. To access Context Menu Service features, for example, CMS 

command line functions, you must be assigned the Monitor role in Tivoli Integrated 

Portal. 

To assign the Monitor role to a user in Tivoli Integrated Portal: 

Procedure 

You can assign roles to users in the portal or by using the tipcli command: 

v To assign the Monitor role to a user in the portal, from the navigation pane, click 

Users and Groups > User Roles. Search for the user, assign the Monitor role and 

save your changes. 

v To assign the Monitor role to a user using the tipcli command, at the command 

line change to tip_home_dir/profiles/TIPProfile/bin and enter the following 

command: 

tipcli.bat MapUsersToRole --username tip_username 

--password tip_user_password --roleName monitor --usersList user_ID 

tipcli.sh MapUsersToRole --username 

tip_username --password tip_user_password --roleName monitor 

--usersList user_ID 

Reference 363

Command reference 

Use the Tivoli Integrated Portal command line interface tipcli commands for 

writing scripts for passing information between applications. 

The tipcli commands are entered in the tip_home_dir/profiles/TIPProfile/bin 

directory, for example, C:\IBM\tivoli\tip\profiles\TIPProfile\bin\tipcli.bat 

on Windows or /opt/IBM/tivoli/tip/profiles/TIPProfile/bin/tipcli.sh on 

Linux or UNIX. 

The tipcli component provides help for its various commands: 

Help [--command command_name] 

Access help for all commands or optionally you can use the command 

argument to return detailed help for a specific command. 

The following returns help for the AddUpdatePreferenceProfile command: 

tipcli.bat Help --command AddUpdatePreferenceProfile 

Help 

---- 

AddUpdatePreferenceProfile --username --password 

--profileName [--newProfileName ] [--themeDir ] [--showNavTree ] [--componentDir ] [--text 

Dir ] [--views ] [--roles ] [--d 

efaultView ] 

where 

is the username on TIP that has iscadmins role. 

is the password for the user. 

is profile name which will be created or updated. 

is the new name for the existing preference profile. 

is the directory name of the installed theme. Example: TIPLight 

specify if show navigation tree by default after login the conso 

le. 

specify component direction for the console. 

specify text direction for the console. 

is views assignment for the preference profile. 

is roles assignment for the preference profile. 

specify which view is displayed by default after login the conso 

le. 

CTGWA4017I The command completed successfully. 

Working with roles: 

Use these tipcli commands for to manipulate roles. 

ListRoles: 

Use the ListRoles command to list all roles configured for a portal instance. 

Syntax 

This command has the following syntax: 

v tipcli.sh ListRoles 

v tipcli.bat ListRoles 


Example 


For example, in a UNIX or Linux environment, use 

tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRoles 

Where tip_home_dir is location of the Tivoli Integrated Portal instance that you 

want to query. 

AddRole: 

Use the AddRole command to add a specified role to the portal instance. Portal 

users are granted access to resources based on the role to which they are assigned. 

All roles created with this command have a resource type of Custom. 

Syntax 


v tipcli.sh AddRole --username tip_username 

--password tip_user_password --roleName role_name 

v tipcli.bat AddRole --username tip_username --password 

tip_user_password --roleName role_name 

Where: 

tip_username is the portal administrator user ID. 

tip_user_password is the password associated with the portal administrator user 

ID. 

role_name is the name of the role to be added. 

Note: Arguments to the rolesList parameter must not include spaces. 

Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh AddRole --username 

tip_username --password tip_user_password --roleName role_name 

Where tip_home_dir is location of the Tivoli Integrated Portal instance involved. 

UpdateRole: 

Use the UpdateRole command to change the name of a custom role. 

Syntax 


v tipcli.sh UpdateRole --username tip_username 

--password tip_user_password --roleName role_name --newRoleName 

new_role_name 

Reference 365

v tipcli.bat UpdateRole --username tip_username --password 

tip_user_password --roleName role_name --newRoleName new_role_name 

Where: 



ID. 

role_name is the name of the role to be modified. 

new_role_name is the new name you want for the specified role. 

Note: Arguments to the role_name and newRoleName parameters must not include 

spaces. 

Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh UpdateRole --username 


--newRoleName new_role_name 


DelRole: 

Use the DelRole command to delete a custom role. 

Syntax 


v tipcli.sh DelRole --username tip_username 

--password tip_user_password --roleName role_name 

v tipcli.bat DelRole --username tip_username --password 

tip_user_password --roleName role_name 

Where: 



ID. 

role_name is the name of the role to be modified. 

Note: Arguments to the rolesList parameter must not include spaces. 

Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh DelRole --username 




ListRolesFromGroup: 

Use the ListRolesFromGroup command to list all roles associated with a specified 

user group. 

Syntax 


v tipcli.sh ListRolesFromGroup --username 

tip_username --password tip_user_password --groupID group_ID 

v tipcli.bat ListRolesFromGroup --username tip_username 

--password tip_user_password --groupID group_ID 

Where: 



ID. 

group_ID is the name of the user group associated with the roles that you want 

to list. 

Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesFromGroup 

--username tip_username --password tip_user_password --groupID group_ID 


MapRolesToGroup: 

Use the MapRolesToGroup command to associate a comma-separated list of roles to 

a specified user group. 

Syntax 


v tipcli.sh MapRolesToGroup --username 

tip_username --password tip_user_password --groupID group_ID --rolesList 

role_name1, role__name2 

v tipcli.bat MapRolesToGroup --username tip_username 

--password tip_user_password --groupID group_ID --rolesList role_name1, 

role__name2 

Where: 



ID. 

Reference 367


to map. 

role_name1, role__name2 is a comma-separated list of roles that are to be 

associated with the specified user group. 

Note: Individual role name arguments to the rolesList parameter must not 

include spaces. 

Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToGroup --username 



Where tip_home_dir is location of the Tivoli Integrated Portal instance. 

RemoveRolesFromGroup: 

Use the RemoveRolesFromGroup command to disassociate a comma-separated list of 

roles from a specified user group. 

Syntax 


v tipcli.sh RemoveRolesFromGroup --username 



v tipcli.bat RemoveRolesFromGroup --username tip_username 

--password tip_user_password --groupID group_ID --rolesList role_name1, 

role__name2 

Where: 



ID. 


to list. 


associated with the specified user group. 



Example 



For example, in a UNIX or Linux environment, use

tip_home_dir/profiles/TIPProfile/bin/tipcli.sh RemoveRolesFromGroup 

--username tip_username --password tip_user_password --groupID group_ID 

--rolesList role_name1, role__name2 


ListRolesForPage: 

Use the ListRolesForPage command to list all roles associated with a specified 

page. 

Syntax 


v tipcli.sh ListRolesForPage --pageUniqueName 

page_unique_name 

v tipcli.bat ListRolesForPage --pageUniqueName 

page_unique_name 

Where: 

page_unique_name is the unique ID for the page. 

Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesForPage 

--pageUniqueName page_unique_name 


MapRolesToPage: 

Use the MapRolesToPage command to associate a comma-separated list of roles with 

a specified page and set an access level for each role. 

Syntax 


v tipcli.sh MapRolesToPage --username 

tip_username --password tip_user_password --pageUniqueName 

page_unique_name --rolesList role_name1, role__name2 --accessLevelList 

level1, level2 

v tipcli.bat MapRolesToPage --username tip_username 

--password tip_user_password --pageUniqueName page_unique_name 

--rolesList role_name1, role__name2 --accessLevelList level1, level2 

Where: 



ID. 

Reference 369

page_unique_name is the page ID with which to associate with the list of roles. 


associated with the page. 

level1, level2 is a comma-separated list of page access levels that relate to the list 

of specified roles. Each of the listed roles is assigned the access level that 

corresponds to its position in each list. For example, the second argument in the 

list associated with rolesList is assigned to the second argument associated 

accessLevelList. 



Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToPage --username 

tip_username --password tip_user_password --pageUniqueName page_unique_name 



RemoveRolesFromPage: 

Use the RemoveRolesFromPage command to disassociate a comma-separated list of 

roles with a specified page. 

Syntax 


v tipcli.sh RemoveRolesFromPage --username 

tip_username --password tip_user_password --pageUniqueName 

page_unique_name --rolesList role_name1, role__name2 

v tipcli.bat RemoveRolesFromPage --username tip_username 

--password tip_user_password --pageUniqueName page_unique_name 


Where: 



ID. 

page_unique_name is the page ID associated with the roles that you want to 

remove. 


disassociated with the page. 




Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToPage --username 

tip_username --password tip_user_password --pageUniqueName page_unique_name 



ListRolesForPortletEntity: 

Use the ListRolesForPortletEntity command to list all roles associated with a 

specified portlet. 

Syntax 


v tipcli.sh ListRolesForPortletEntity 

--portletEntityUniqueName portlet_entity_unique_name 

v tipcli.bat ListRolesForPortletEntity 

--portletEntityUniqueName portlet_entity_unique_name 

Where: 

portlet_entity_unique_name is the unique ID for the portlet. 

Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesForPage 

--pageUniqueName page_unique_name 


MapRolesToPortletEntity: 

Use the MapRolesToPortletEntity command to associate a comma-separated list of 

roles with a specified portlet. 

Syntax 


v tipcli.sh MapRolesToPortletEntity --username 

tip_username --password tip_user_password --portletEntityUniqueName 

portlet_entity_unique_name --rolesList role_name1, role__name2 

--accessLevelList level1, level2 

Reference 371

v tipcli.bat MapRolesToPortletEntity --username tip_username 

--password tip_user_password --portletEntityUniqueName 



Where: 



ID. 

portlet_entity_unique_name is the unique portlet ID with which to associate with 

the list of roles. 


associated with the portlet. 

level1, level2 is a comma-separated list of access levels that relate to the list of 

specified roles. Each of the listed roles is assigned the access level that 






Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToPortletEntity 


--portletEntityUniqueName portlet_entity_unique_name --rolesList 

role_name1, role__name2 --accessLevelList level1, level2 


RemoveRolesFromPortletEntity: 

Use the RemoveRolesFromPortletEntity command to disassociate a 

comma-separated list of roles with a specified portlet. 

Syntax 


v tipcli.sh RemoveRolesFromPortletEntity 




v tipcli.bat RemoveRolesFromPortletEntity --username 

tip_username --password tip_user_password --portletEntityUniqueName 


Where: 




ID. 

portlet_entity_unique_name is the portlet ID associated with the roles that you 

want to remove. 


disassociated with the portlet. 



Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh RemoveRolesFromPortletEntity 





ListRolesFromUser: 

Use the ListRolesFromUser command to list all roles associated with a specified 

user. 

Syntax 


v tipcli.sh ListRolesFromUser --username 

tip_username --password tip_user_password --userID user_ID 

v tipcli.bat ListRolesFromUser --username tip_username 

--password tip_user_password --userID user_ID 

Where: 



ID. 

user_ID is the unique ID for the user. 

Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesFromUser --username 

tip_username --password tip_user_password --userID user_ID 


MapRolesToUser: 

Reference 373

Use the MapRolesToUser command to associate a comma-separated list of roles with 

a specified user ID. 

Syntax 


v tipcli.sh MapRolesToUser --username 

tip_username --password tip_user_password --userID user_ID --rolesList 


v tipcli.bat MapRolesToUser --username tip_username 

--password tip_user_password --userID user_ID --rolesList role_name1, 

role__name2 

Where: 



ID. 

user_ID is the unique user ID with which to associate with the list of roles. 


associated with the user. 



Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToUser --username 




RemoveRolesFromUser: 

Use the RemoveRolesFromUser command to disassociate a comma-separated list of 

roles with a specified user ID. 

Syntax 


v tipcli.sh RemoveRolesFromUser --username 



v tipcli.bat RemoveRolesFromUser --username tip_username 

--password tip_user_password --userID user_ID --rolesList role_name1, 

role__name2 

Where: 




ID. 

user_ID is the user ID associated with the roles that you want to remove. 


disassociated with the specified user ID. 



Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh RemoveRolesFromUser 

--username tip_username --password tip_user_password --userID user_ID 



ListRolesForView: 

Use the ListRolesForView command to list all roles associated with a specified 

view. 

Syntax 


v tipcli.sh ListRolesForView --viewUniqueName 

view_name 

v tipcli.bat ListRolesForView --viewUniqueName view_name 

Where: 

view_name is the unique name for the view. 

Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesForView 

--viewUniqueName view_name 


MapRolesToView: 

Use the MapRolesToView command to associate a comma-separated list of roles with 

a specified view and set an access level for each role. 

Syntax 


Reference 375

v tipcli.sh MapRolesToView --username 

tip_username --password tip_user_password --viewUniqueName view_name 


v tipcli.bat MapRolesToView --username tip_username 

--password tip_user_password --viewUniqueName view_name --rolesList 

role_name1, role__name2 --accessLevelList level1, level2 

Where: 



ID. 

view_name is the unique view name with which to associate with the list of 

roles. 


associated with the view. 

level1, level2 is a comma-separated list of page access levels that relate to the list 

of specified roles. Each of the listed roles is assigned the access level that 






Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToView --username 




RemoveRolesFromView: 

Use the RemoveRolesFromView command to disassociate a comma-separated list of 

roles with a specified view. 

Syntax 


v tipcli.sh RemoveRolesFromView --username 



v tipcli.bat RemoveRolesFromView --username tip_username 

--password tip_user_password --viewUniqueName view_name --rolesList 


Where: 




ID. 

view_name is the unique view name associated with the roles that you want to 

remove. 


disassociated with the specified view. 



Example 



tip_home_dir/profiles/TIPProfile/bin/tipcli.sh RemoveRolesFromView 

--username tip_username --password tip_user_password --viewUniqueName 

view_name --rolesList role_name1, role__name2 


Working with views: 

tipcli commands for working with views. 





ListViews 

List all views. 

AddViewMembers --username tip_username --password tip_user_password --view 

view_unique_name [--members members1, member2] [--launchMembers 

launch_member1, launch_member2] 

Add members or launch members for a specified view. 

Important: When you add members to a view at the command line, your 

updates are not reflected in the portal until the next time that you log in. 

ListViewsForRole --roleName role_name 

List the views associated with a specified role. 

MapViewsToRole --username tip_username --password tip_user_password 

--roleName role_name --viewList view_unique_name1, view_unique_name2 


Associate a comma separated list of views with a particular role and set 

the access level for the role for each view. 

RemoveViewsFromRole --username tip_username --password tip_user_password 

--roleName role_name --viewList view_unique_name1, view_unique_name2 

Disassociate a comma separated list of views from a particular role. 

Working with users: 

tipcli commands for working with users. 

Reference 377

ListUsersFromRole --roleName role_name 

List the users associated with a specified role. 

MapUsersToRole --username tip_username --password tip_user_password 

--roleName role_name --usersList user_ID1:user_ID2 

Associate a colon (:) separated list of user IDs with a particular role. 

Note: Arguments to the usersList parameter should not include a colon 

(:). 

RemoveUsersFromRole --username tip_username --password tip_user_password 

--roleName role_name --usersList user_ID1:user_ID2 

Disassociate a colon (:) separated list of user IDs from a particular role. 

Working with preference profiles: 

tipcli commands for working with preference profiles. 

DeletePreferenceProfile --username tip_username --password 

tip_user_password --profileName profile_name 

Delete the specified preference profile. 

ListPreferenceProfiles [--name profile_name] 

Return a list of console preference profiles. Optionally, you can specify a 

comma separated lists of preference profiles, to return their unique names. 

ShowPreferenceProfile --uniqueName profile_unique_name 

List all the attributes for a specified profile preference. 

AddUpdatePreferenceProfile --username tip_username --password 

tip_user_password --profileName profile_name [--newProfileName 

new_profile_name] [--themeDir theme_dir] [--showNavTree true|false] 

[--componentDir default|ltr|rtl] [--textDir default|contextual|ltr|rtl] 

[--views view_unique_name1, view_unique_name2] --roles role_name1, 

role_name2] [--defaultView view_unique_name] 

Use the AddUpdatePreferenceProfile command to create a new profile 

preference or update an existing profile. 

Table 23. AddUpdatePreferenceProfile command arguments 


--username tip_username Mandatory parameter. A user with the 

iscadmins role. 


user with the iscadmins role. 

--profileName profile_name Mandatory parameter. The name of the 

profile that is to be created or modified. 

[--newProfileName new_profile_name] Optional parameter. The new name for the 

specified profile. 

[--themeDir theme_dir] Optional parameter. Used to specify the 

directory for the theme that you want to 

apply. 

[--showNavTree true|false] Optional parameter. Used to specify whether 

or not you want the navigation pane to be 

displayed for preference profile. 


Table 23. AddUpdatePreferenceProfile command arguments (continued) 


[--componentDir default|ltr|rtl] Optional parameter. Used to specify 

component display direction, that is, 

whether you want items to display 

left-to-right, right-to-left, or to use the 

default browser settings. 

[--textDir default|ltr|rtl] Optional parameter. Used to specify text 

direction, that is, whether you want text to 

display left-to-right, right-to-left, or to use 

the default browser settings. 

[--views view_unique_name1, 

Optional parameter. Used to specify the 

view_unique_name2] 

views that you want to assign to the 

preference profile. Comma separated list. 

--roles role_name1, role_name2] Optional parameter. Used to specify the 

roles that you want to assign to the 

preference profile. Comma separated list. 

[--defaultView view_unique_name] Optional parameter. Used to specify the 

view that you want displayed when a user 

logs into the portal. 

Working with portlets: 

tipcli commands for working with portlets. 





ListPortletEntitiesForRole --roleName role_name] 

List the portlets entities associated with a specified role. 

MapPortletEntitiesToRole --username tip_username --password 

tip_user_password --roleName role_name --portletEntityList 

portletEntity_unique_name1, portletEntity_unique_name2 --accessLevelList 

level1, level2 

Associate a comma separated list of portlets with a particular role and set 

the access level for the role for each portlet. 

RemovePortletEntitiesFromRole --username tip_username --password 

tip_user_password --roleName role_name --portletEntityList 

portletEntity_unique_name1, portletEntity_unique_name2 

Disassociate a comma separated list of portlets with from particular role. 

Working with pages: 

tipcli commands for working with pages. 

ListPages [--viewList view_unique_name1, view_unique_name2] 

[--customizePages true|false] 

List all pages. You can optionally filter the list by using the viewlist 

parameter and providing a comma separated list of views. You can also 

use the customizePages (set totrue) to return a list of custom pages only. 

ListPagesForRole --roleName role_name 

List the pages associated with a specified role. 

Reference 379

MapPagesToRole --username tip_username --password tip_user_password 

--roleName role_name --pageList page_unique_name1, page_unique_name2 


Associate a comma separated list of pages with a particular role and set 

the access level for the role for each page. 

RemovePagesFromRole --username tip_username --password tip_user_password 

--roleName role_name --pageList page_unique_name1, page_unique_name2 

Disassociate a comma separated list of pages from a particular role. 

Working with user groups: 

tipcli commands for working with user groups. 





ListGroupsFromRole --roleName role_name 

List the user groups associated with a specified role. 

MapGroupsToRole --username tip_username --password tip_user_password 

--roleName role_name --groupsList group_name1: group_name2 

Associate a colon (:) separated list of groups with a particular role. 

Note: Arguments to the groupsList parameter should not include a colon 

(:). 

RemoveGroupsFromRole --username tip_username --password tip_user_password 

--roleName role_name --groupsList group_name1: group_name2 

Disassociate a colon (:) separated list of groups from a particular role. 

Charting tipcli commands: 

tipcli commands for working with charting. 

ListCharts --username tip_username --password tip_user_password 

Use ListCharts to review the charts that are configured in the 

environment. 

ChartConnection --action action [--name name] [--protocol protocol 

--hostname hostname --port port -- serviceName serviceName --username 

username --password password--renderFormat render_format 

--Datasource_Username datasource_username --credentialType credential_type] 


ChartConnection is used to configure a connection to any IBM Tivoli 

Charting Web Service. The ITM Web Service is just one example. 

ChartExport --dir output_directory --type all|customcharts|page [--pageID 

page_ID | --pageName page_name] --username tip_username --password 

tip_user_password 

ChartExport is used to export chart data. 

Table 24. ChartExport command arguments 


--dir output_directory Mandatory parameter. The directory where 

the exported data is saved. If the directory 

does not exist, it is created. 


Table 24. ChartExport command arguments (continued) 


--type all|customcharts|page Mandatory parameter. If you set the --type 

to all, then all charts are exported. If you 

set it to customcharts, then only customized 

charts are exported. If you set it to page, 

then you can use either the --pageID or the 

--pageName parameter to specify the page for 

which you want to export chart data. 

[--pageID page_ID | --pageName 

Optional parameter. If you set the --type 

page_name] 

parameter to page, then you can use either 

the --pageID or the --pageName parameter to 

specify the page for which you want to 

export chart data. 






ChartImport --dir source_directory --username tip_username --password 


ChartImport is used to import chart data from a specified directory. 

Table 25. ChartImport command arguments 


--dir source_directory Mandatory parameter. The directory where 

the data to be imported is located. BIRT 

Designer file format is .rptdesign. 






ChartProperties [--name property_name --value property_value] --username 


ChartProperties is used to view or modify properties for charting. If you 

only provide username and password details and no other arguments, then 

the current properties are listed. It is useful to run this command first so 

that you can review the current property names and values before you 

decide to make updates. 

Table 26. ChartProperties command arguments 


--name property_name --value 

Optional parameter. The name of the 

property_value 

property that you want to update and the 

value that you want to set. For example, to 

set the timeout value to 10,000,000 

milliseconds, enter --name AXIS_TIMEOUT 

--value 10000000. 


user with the chartAdministrator role. 

Reference 381

Table 26. ChartProperties command arguments (continued) 




ListRestoreTimestamp 

Use the ListRestoreTimestamp command to return a list of charting store 

backups by timestamp. 

RestoreChartStore --BackupTimestamp backup_timestamp --username 


Use the RestoreChartStore command to restore a chart store by timestamp. 

Table 27. RestoreChartStore command arguments 


RestoreChartStore --BackupTimestamp Mandatory parameter. The timestamp of the 

charting store backup. 





Tivoli Integrated Portal Export commands: 

Use these tipcli commands for to export Tivoli Integrated Portal customized data. 

tipcli - Export plugins: 

Use the Export command to export customization data for an instance of Tivoli 

Integrated Portal. Use the ListExportPlugins command to list plugins that are 

available for export. 

Syntax 

ListExportPlugins 

Use the ListExportPlugins command to list all plugins that can be 

exported. Use the list of returned plugins to assist you when you are 

specifying plugins to be exported. 

Export [--includePlugins|--excludePlugins plugin1,plugin2] [--settingFile 

setting_file] --username tip_username --password tip_user_password 

Parameters 

If you provide no parameters to the Export command, all custom data is exported 

by default. 

Note: If you specify additional parameters for the tipcli.bat|.sh Export and 

make a typing error, that is, if you type a parameter incorrectly, or use the 

incorrect case, then the commands runs as if no parameters were specified and no 

warning message is displayed. 


Table 28. Export parameters and arguments 


[--includePlugins|--excludePlugins plugin1,plugin2] Optional parameter. You can choose to include or 

exclude a list of plugins when you run the Export 

command. 

[--settingFile setting_file] Optional parameter. You can specify your export 

requirements in properties file instead of specifying 

your requirements using separate parameters at the 

command line. Provide a path to the settings file as 

the argument to the settingFile parameter. On 

systems running Windows you must use double 

backslashes characters (\\) when specifying the path 

to your settings file, for example, 

C:\\tmp\\export.properties. Command line 

parameters take precedence over entries in the 

settings file. 

--username tip_username Mandatory parameter. The user name for a user with 

the iscadmin role. 

--password tip_user_password Mandatory parameter. The password for the specified 

user name. 

Example 1 - Return a list of plugins available for exporting 

The following example returns a list of plugins that can be exported: 

C:\IBM\tivoli\tipv22\profiles\TIPProfile\bin>tipcli.bat ListExportPlugins 

Example 2 - Export a subset of available plugins 

The following example exports the CMS plugin only: 

C:\IBM\tivoli\tipv22TWLa\profiles\TIPProfile\bin>tipcli.bat Export 

--includePlugins com.ibm.tivoli.tip.cli.cms.CmsExportPlugin 

--username tipadmins --password tippassword 


“Exporting and importing” on page 346 




tipcli - Advanced Export options: 

Use the ExportPagePlugin tipcli command to export specific Tivoli Integrated 

Portal data. 





Export [--exportFile export_file] [--pages ALL|NONE|page1,page2] [--views 

ALL|NONE|view1,view2] [--roles ALL|NONE|REQUIRED|role1,role2] 

[--exportPagesInViews true|false] [--userPreferences 

ALL|NONE|REQUIRED|user_ID1,user_ID2] [--consolePreferenceProfiles 

ALL|NONE|pref_ID1,pref_ID2] [--includeEntitiesFromApp war1,war2] 

[--includeCustomData true|false] [--includeCredentialData true|false] 

Reference 383

[--includeMytasks true|false] [--includeMyStartupPages true|false] 

[--includeTransformations true|false] --username tip_username --password 


Table 29. ExportPagePlugin command arguments 


[--exportFile export_file] Optional parameter. Specifies the path and 

file name for the exported data, for example, 

c:/tmp/extest.zip. 

[--pages ALL|NONE|page1,page2] Optional parameter. If you do not use the 

pages parameter, the default setting is ALL 

unless either exportPagesInViews or 

includeEntitiesFromApp is defined, then the 

default setting is NONE. You can also provide 

a list of pages that you want to export. 

[--views ALL|NONE|view1,view2] 

Optional parameter. If you do not use the 

--exportpageinviews [true|false] 

views parameter, the default setting is ALL. 

You can also provide a list of views that you 

want to export and optionally specify that 

you want to export all pages associated with 

the specified views. 

Note: Whether the optional parameter 

exportpageinviews is set to true or false, if 

a view has a default node in the navigation 

pane associated with it, then the page 

associated with the node is always exported. 

This is also true, even if you specify NONE as 

the argument to the --pages parameter. 

[--roles ALL|NONE|REQUIRED|role1,role2] Optional parameter. You can export no roles, 

all roles, or a specific list of roles. The 

default setting is ALL unless the pages 

parameter or the includeEntitiesFromApp 

parameter is specified. Then, the default 

setting is set to REQUIRED. 

[--exportPagesInViews true|false] Optional parameter. Use this parameter, set 

to true, to export the pages associated with 

an exported view . The default value is 

false. 

[--userPreferences 

Optional parameter. You can export 

ALL|NONE|REQUIRED|user_ID1,user_ID2] preferences for all users, no users, or for a 

specified list of users by user ID. The default 

setting is ALL. This parameter overrides the 

includeMytasks and includeMyStartupPages 

parameters. 

[--consolePreferenceProfiles 

Optional parameter. You can export no 

ALL|NONE|pref_ID1,pref_ID2] 

preference profile data, all preference profile 

data, or data for a specific list of preference 

profiles. The default setting is ALL. 

Note: If a console preference profile has a 

custom view as its default view, then that 

view is automatically exported. If the 

exported view has a default node in the 

navigation pane, then the associated page is 

automatically exported with the view. 

[--includeEntitiesFromApp war1,war2] Optional parameter. You can provide a list 

of WARs to export pages that contain 

portlets associated with the listed WARs. 


Table 29. ExportPagePlugin command arguments (continued) 


[--includeCustomData true|false] Optional parameter. The default value is 

true. Ifissettofalse, no customization 

data is exported. 

[--includeCredentialData true|false] Optional parameter. The default value is 

true. Ifissettofalse, no credential data is 

exported. 

[--includeMytasks true|false] Optional parameter. The default setting is 

true. This parameter only applies when the 

includeEntitiesFromApp parameter is also 

specified. 

[--includeMyStartupPages true|false] Optional parameter. The default setting is 

true. This parameter only applies when the 

includeEntitiesFromApp parameter is also 

specified. 

[--includeTransformations true|false] Optional parameter. The default setting is 

true. 


user with the iscadmins role. 



tipcli - Charting Export options: 

Use the ChartExportPlugin tipcli command to exportTivoli Integrated Portal chart 

data. 





Export [--includeCharts ALL|NONE|page_ID1,page_ID2] --username tip_username 

--password tip_user_password 

Table 30. ChartExportPlugin command arguments 


[--includeCharts 

Optional parameter. You can export all 

ALL|NONE|page_ID1,page_ID2] 

charts, no charts, or specify a list of charts to 

be exported. The default setting is ALL. 

Note: If you run the Export command using 

the --includeCharts parameter, it must be 

run by the same user that started the Tivoli 






Import tipcli commands: 

tipcli commands for importing Tivoli Integrated Portal data. 

Reference 385

Note: If you specify additional parameters for the tipcli.bat|.sh Import and 




ListImportPlugins 

Use the ListImportPlugins command to list all plugins that are available 

to be imported. 

Import [--includePlugins|--excludePlugins plugin1,plugin2] [--settingFile 

setting_file] [--backupDir backup_dir] --username tip_username --password 


Use the Import command to import customization data into a Tivoli 

Integrated Portal environment. If you provide no parameters to the Import 

command, all custom data is imported by default. 

Table 31. Import command arguments 


[--includePlugins|--excludePlugins Optional parameter. You can choose to 

plugin1,plugin2] 

include or exclude a list of plugins when 

you run the Import command. 

[--settingFile setting_file] Optional parameter. You can specify your 

import requirements in a properties file 

instead of specifying your requirements 

using separate parameters at the command 

line. Provide a path to the settings file as the 

argument to the settingFile parameter. On 

systems running Windows you must use 

double backslashes characters (\\) when 

specifying the path to your settings file, for 

example, C:\\tmp\\import.properties. 

Command line parameters take precedence 

over entries in the settings file. 

[--backupDir backup_dir] You can specify a directory to save the 

backup data during an import operation so 

that if it is required you can subsequently 

restore settings. 


user with the iscadmin role. 




“Exporting and importing” on page 346 




Additional commands: 

Additional tipcli commands. 

cmsUpdateRemoteEntries [--username username --password password] (-toremote 

| -fromremote | -deleteremote) [-force] 

Save system information in the file specified. 


Table 32. cmsUpdateRemoteEntries command arguments 


[--username username --password 

Optional parameters. User name and 

password] 

password for a Tivoli Integrated Portal user. 

If you do not provide user name and 

password details at the command line, you 

must enter the user name and password in 

an interactive mode. 

-toremote Optional parameter. Indicates that the 

update is to occur to the remote data store, 

that is, the local information is to be written 

to the remote database. 

-fromremote Optional parameter. Indicates that the 

update is to occur from the remote data 

store. Any information saved locally is 

downloaded and updated from the remote 

database. 

-deleteremote Optional parameter. Indicates that the 

launch entries provided by this Tivoli 

Integrated Portal instance to the remote 

database is to be deleted from the database. 

Additionally, this command prevents any 

further updates from being sent to the 

remote database. On execution, the 

cmsUpdateRemoteEntries command with the 

toremote and force options updates the 

database and re-enables automatic updates 

to the remote database. 

Note: There is no difference between 

deleteremote with the force option and 

deleteremote without the force option. 

-force Optional parameter. Indicates that any 

caching or optimization mechanisms for the 

data should be ignored and that the data 

should be updated regardless of the 

state.Any existing cached information is 

discarded. All data in the database is 

refreshed for the toremote case, including 

the resource bundles. 

Version 

List the versions of the products and components installed in the 

environment. 

SystemInfo [--outputFile outputFile] 

Save system information in the file specified. 

ITMLogin --hostname hostname --port port --username username --password 

password [--servicename] 

ITMLogin is used to configure the ITM Web Service to connect to the Tivoli 

Enterprise Portal Server. For example, this command in Windows 

configures the username and password for a new ITM Web Service to be 

added to the application server instance. 

C:\IBM\tivoli\tip\bin\tipcli.bat ITMLogin --hostname 

localhost --port 1920 --username sysadmin --password 

sysadm1n --servicename ITMWebService2 

Reference 387

You can use the ITMLogin command to change the hostname, port, 

username, and password of an existing Tivoli Enterprise Portal Server 

instance. Changing a configured ITM Web Service to a different Tivoli 

Enterprise Portal Server is not supported, because the two portal servers 

may have different configurations. If you need to use a different portal 

server, you can install another instance of the ITM Web Service and use 

this command (along with the -serviceName option) to configure. 

TADDMLogin --hostname hostname [--port port] --username username --password 

password 

Log in to the Tivoli Application Dependency Discovery 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. 

For license inquiries regarding double-byte (DBCS) information, contact the IBM 

Intellectual Property Department in your country or send inquiries, in writing, to: 

Intellectual Property Licensing 

Legal and Intellectual Property Law 

IBM Japan, Ltd. 

1623-14, Shimotsuruma, Yamato-shi 

Kanagawa 242-8502 Japan 

The following paragraph does not apply to the United Kingdom or any other 

country where such provisions are inconsistent with local law: 

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS 

PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER 

EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 

WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS 

FOR A PARTICULAR PURPOSE. 

Some states do not allow disclaimer of express or implied warranties in certain 

transactions, therefore, this statement might not apply to you. 

This information could include technical inaccuracies or typographical errors. 

Changes are periodically made to the information herein; these changes will be 

incorporated in new editions of the publication. IBM may make improvements 

and/or changes in the product(s) and/or the program(s) described in this 

publication at any time without notice. 

Any references in this information to non-IBM Web sites are provided for 

convenience only and do not in any manner serve as an endorsement of those Web 

sites. The materials at those Web sites are not part of the materials for this IBM 

product and use of those Web sites is at your own risk. 


Trademarks 

IBM may use or distribute any of the information you supply in any way it 

believes appropriate without incurring any obligation to you. 

Licensees of this program who wish to have information about it for the purpose 

of enabling: (i) the exchange of information between independently created 

programs and other programs (including this one) and (ii) the mutual use of the 

information which has been exchanged, should contact: 

IBM Corporation 

2Z4A/101 

11400 Burnet Road 

Austin, TX 78758 U.S.A. 

Such information may be available, subject to appropriate terms and conditions, 

including in some cases payment of a fee. 

The licensed program described in this document and all licensed material 

available for it are provided by IBM under terms of the IBM Customer Agreement, 

IBM International Program License Agreement or any equivalent agreement 

between us. 

Any performance data contained herein was determined in a controlled 

environment. Therefore, the results obtained in other operating environments may 

vary significantly. Some measurements may have been made on development-level 

systems and there is no guarantee that these measurements will be the same on 

generally available systems. Furthermore, some measurement may have been 

estimated through extrapolation. Actual results may vary. Users of this document 

should verify the applicable data for their specific environment. 

Information concerning non-IBM products was obtained from the suppliers of 

those products, their published announcements or other publicly available sources. 

IBM has not tested those products and cannot confirm the accuracy of 

performance, compatibility or any other claims related to non-IBM products. 

Questions on the capabilities of non-IBM products should be addressed to the 

suppliers of those products. 

All statements regarding IBM's future direction or intent are subject to change or 

withdrawal without notice, and represent goals and objectives only. 

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. 

If you are viewing this information in softcopy form, the photographs and color 

illustrations might not be displayed. 

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of 

International Business Machines Corp., registered in many jurisdictions worldwide. 

Other product and service names might be trademarks of IBM or other companies. 

A current list of IBM trademarks is available on the Web at “Copyright and 

trademark information” at www.ibm.com/legal/copytrade.shtml. 


Adobe, Acrobat, PostScript and all Adobe-based trademarks are either registered 

trademarks or trademarks of Adobe Systems Incorporated in the United States, 

other countries, or both. 

Java and all Java-based trademarks and logos are trademarks or registered 

trademarks of Oracle and/or its affiliates. 

Linux is a trademark of Linus Torvalds 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. 

UNIX is a registered trademark of The Open Group in the United States and other 

countries. 

Other product and service names might be trademarks of IBM or other companies. 

Notices 391


Index 

A 

about this profile 280, 344 

adding JDBC drivers 79 

administrator 

default user 31 

advanced commands 351 

advanced installation 40 

agent 

Business Service Management 119 

configuring 119 


attribute group 138 

disk capacity planning 138 

Event Broker Log attribute 

group 131 

installing 119 

Performance Object Status attribute 

group 129 

Service Indicators attribute 

group 133 

Service Status attribute group 134 

Service Status Change Event attribute 

group 136 

URL Monitor attribute group 137 

agent for TBSM 

workspaces 124 

Agent Management Services 

enabling 123 

application server 

ports 279, 344 

profile 280, 344 

architecture 7 

attribute groups 

Business Service Management 

Agent 126 

attributes 


Agent 126 


attribute group 138 

Event Broker Log 131 

Performance Object Status attribute 

group 129 

Service Indicators 133 

Service Status 134 

Service Status Change Event 136 

URL Monitor 137 

authentication 

user registry 27 

automatic startup 

removing on UNIX 254 

UNIX 253 

B 

back up 

server settings 361 

basic commands 348 

books 

See publications 


agent 119 

installing agent 119 


attributes 126 

C 

certificate 278 

certificate authority 

changing Secure Socket Layer 

(SSL) 247 

certificates 

signer data for dashboard 

servers 237 

CGI support 360 

chart 

roles 332 

ChartExportPlugin tipcli command 

export 385 

charting 

ITM - no SSO 340 

SSO and ITM 337 

charts 

exporting 336 

importing 336 

cloning 

server settings 361 

CMS 

access 363 

configure hostname 331 

create remote database 329 

data source 328 

commands 

tbsm_db 49 

Common Reporting 

uinstall failure 266 

configuring VMM 289 

Context Menu Service 

access 363 

conventions 

typeface 4 

core library 1 

D 

Dashboard server 

LDAP configuration 29 

data fetchers 

failover 180 

Time Window Analyzer 180 

Data server 

configuring for failover 205 

installation worksheet 74 

data source 

failover configuration 179 

data sources 

failover 180 

database 

DB2 21 

datastore 

DB2 21 

DB2 

create TBSM schema 49 

install TBSM schema 40 

installing on UNIX 40 

Tivoli System Automation 184, 185 

default groups 31 

Deployment Engine 

managing 281, 360 


completing installation 149 


installing on different system 143 

Log attribute group for agent 138 

log files 276 

requirements 182, 183 

uninstalling on UNIX 152 

uninstalling on Windows 152 

verifying installation 150 

E 

education 

See Tivoli technical training 

EIF probe 

installing 60 

environment variables, notation 14 

error 

MSIEXEC 255 

ETai 314 

Event Broker Log 

attribute group for agent 131 

events 

user permissions 31 

exporting 346, 348, 351 

basic export console preference 

profiles 350 

basic export pages 348 

basic export views 349 

charts 336 

export all 351 

export pages 353 

export views 354 

rules 355, 358 

settings file 352 

ExportPagePlugin tipcli command 

export 383 

F 

failover 180 

configuring Data servers 205 

custom canvases 180 

data source configuration 179 

environment setup 186 

limitations 180 

ObjectServer 

communication configuration 197 

manual configuration 207 


failover (continued) 

out of memory 186 

overview 180 

preparing a configuration file 188 

service trees 180 

verification 210 

view definitions 180 

failover configuration 

Windows systems 204 

failover environment 

setup requirements 182, 183 

failoverstarting servers 209 

features 

new for 6.1.1 5 

federated repositories 

VMM for ObjectServer 289 

files 

fo_config.props 189 

logs 275 

sample response 277 

setup.rsp 89 

fo_config script 206 

fo_config.props file 189 

G 

groups 

default 31 

user 31 

H 

historical data 

disk capacity for agent 138 

hostname 362 

HTTP and HTTPS 326 

HTTP server 

configuring 224, 303 

HTTP server plug-in SSL configuration 

load balancing 229, 309 

I 

IBM Tivoli Monitoring 

Agent Management Services 123 

IBM Tivoli Service Level Advisor 

event forwarding requirements 182, 

183 

importing 346, 356 

charts 336 

import data 356 

rollback 357 

installation 282, 314 

advanced 40 

command line 101 

console 101 

for single sign-on 290 

launch 39 

notes 21 

silent 88 

simple 40 

installation user 22 

ITMWebService 337 

K 

KR9_Process_Data_Unavailable 141 

KR9_TBSM_Critical 141 

KR9_TBSM_Web_App_Critical 141 

L 

language support 153 

launchpad 

TBSM 6.1.1 39 

LDAP 287 

adding 282 

configuring 284, 285 

Dashboard server 29 

SSL 285 

load balancing 180 

charting 

database tables for load 

balancing 332 

charting tables 332 

clone IDs 225, 226, 305, 306 

server-to-server trust 221, 301 

load balancing cluster 

join 223, 303 

log files 275 

Discovery Library Toolkit 276 

login 

configure for HTTP and HTTPS 326 

logon 278, 342 

M 

manuals 

See publications 

memory 

failover and out of memory 186 

migrating 155 

Monitor role 

Context Menu Service 363 

MSIEXEC 255 

N 

Netcool/Impact 

install on TBSM host 24 

installing on TBSM host 272 


secure communications 242 

Netcool/OMNIBus 

triggers 26 

notation 

environment variables 14 

path names 14 

typeface 14 

O 

ObjectServer 210, 289 

communication information 

configuring for UNIX 

systems 198 

configuring for Windows 

systems 201 

failover 

manual configuration 207 


ObjectServer (continued) 

permissions for viewing events 31 

SSL connection 288 

ObjectServer communications 

backup server configuration 

UNIX systems 200 


primary server configuration 

UNIX systems 199 


OMNIbus 

version supported 24 

online publications 

accessing 2 

operating system agents 

IBM Tivoli Monitoring 123 

ordering publications 3 

overview 277 

P 

pages 379 

password 

change 346 

encryption 325 

SSL 346 

passwords 

tipadmin 266, 267, 268 

Performance Object 


permissions 

users and groups 31 

policies 

failover 180 

port 

numbers 280, 344 

port assignments 279, 344 

Post upgrade considerations 116 

product library 1 

publications 1 

accessing online 2 

ordering 3 

R 

registry 

default security 359 

user authentication 27 

requirements 

system 18 

roles 

user 31 

S 

secure communications 

Netcool/OMNIbus 242 

secure connections 234 

certificates 236 

Secure Socket Layer (SSL) certificate 

adding signer certificate 250, 251 

adding signer exchange 251 

changing default 247 

creating certificate request 248 

receiving from certificate 

authority 249

security 

certificate 278 

default registry 359 

vault key 325 

server 

stopping or starting 344 

server settings 

cloning 361 

Service Indicators 


Service Status 


Service Status Change Event 


setup.rsp 89 

signer data for certificates 237 

silent installation 88 

simple installation 40 

single sign-on 290 

configuring 291 

ETai trust association 315, 316 

installing ETai 314 

situations 

Availability 141 

KR9_Process_Data_Unavailable 141 

KR9_TBSM_Critical 141 

KR9_TBSM_Web_App_Critical 141 

URL Monitor 141 

SQL database DSA 79 

SSH 

installing TBSM on SUSE Linux 272 

SSL 285 

configuring 229, 287, 309 

HTTP server plug-in 229, 309 

SSL 287 

to ObjectServer 288 

stopping the application server 344 

SUSE Linux 

installing TBSM over SSH 272 

T 

TBSM 

core library 1 

database requirements 182, 183 

failover 186 

installation 

firewall 273 

TBSM 6.1 

upgrade from 109 

TBSM agent 


TBSM groups 

creating manually 271 

tbsm_db 

create tbsm schema 49 

terminology 2 

Time Window Analyzer 

metric data store 180 

tipcli 

AddRole 365 

DelRole 366 

exporting plugins 382 

ListRoles 364 

ListRolesForPage 369 

ListRolesForPortletEntity 371 

ListRolesForView 375 

tipcli (continued) 

ListRolesFromGroup 367 

ListRolesFromUser 373 

MapRolesToGroup 367 

MapRolesToPage 369 

MapRolesToPortletEntity 371 

MapRolesToUser 374 

MapRolesToView 375 

RemoveRolesFromGroup 368 

RemoveRolesFromPage 370 

RemoveRolesFromPortletEntity 372 

RemoveRolesFromUser 374 

RemoveRolesFromView 376 

UpdateRole 365 

tipcli command 364, 379 

additional commands 386 

charting 380 

import 386 

ITMLogin command 386 

portlets 379 

preference profiles 378 

SystemInfo command 386 

TADDMLogin 386 

user groups 380 

users 378 

views 377 

Tivoli 

integrated applications 11 

Tivoli Access Manager WebSEAL 314 

Tivoli Common Reporter 

trouble shooting 264 

Tivoli Common Reporting 

install requirements 20 

schema name 178 

Show 30 day history 177 

Tivoli Directory Server 

installing 29 

LDAP configuration 29 

Tivoli Documentation Central 2 

Tivoli Event Integration Facility probe 

requirements 182, 183 

uninstalling 63 

verifying installation 62 

Tivoli System Automation 

UNIX configuration 184 

Windows configuration 185 

Tivoli technical training 3 

tivoli_eif.props 

modify 252 

training, Tivoli technical 3 

troubleshoot 

installation issues 255 

typeface conventions 4 

U 

uninstall 

on UNIX 103 

on Windows 103 

UNIX 

DB2 installation 40 

URL Monitor 


user 

administrator default 31 

groups and roles 31 

user registry 

default 359 

users 

external authentication 27 

registry 27 

V 

variables, notation for 14 

vault key file 325 

VMM 

for ObjectServer 289 

W 

Windows uninstallation 267 

workspaces 

TBSM agent 124 

Index 395


Product Number: 

Printed in USA 

GI11-8054-09

IBM Tivoli Business Service Manager: Installation Guide

Create successful ePaper yourself

Delete template?

Save as template?