Tip Admin Config 22

Tivoli Integrated Portal

Administration and configuration guide
Version 1.0 Tivoli Integrated Portal 2.2


Administration and configuration guide
Version 1.0 Tivoli Integrated Portal 2.2
Note
Before using this information and the product it supports, read the information in Notices on page 157.
This edition applies to version 2, release 1 of Tivoli Integrated Portal and to all subsequent releases and
modifications until otherwise indicated in new editions.
Copyright IBM Corporation 2009, 2012.
US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Chapter 1. Tivoli Integrated Portal Removing a load balancing cluster . . . . . 57
overview . . . . . . . . . . . . . . 1 Configuring Tivoli Access Manager in Tivoli
Integrated Portal. . . . . . . . . . . . . 57
Configuring single sign-on using ETai . . . . 57
Chapter 2. Tivoli Integrated Portal Checking your Tivoli Access Manager
components . . . . . . . . . . . . . 3 configuration . . . . . . . . . . . . . 63
Configuring the WebSEAL keystore . . . . . 64
Chapter 3. Installing . . . . . . . . . 5 Creating a WebSEAL junction . . . . . . . 65
Preparing for installation . . . . . . . . . . 5 Creating a WebSEAL junction mapping table . . 66
Preparing a WebSphere Application Server Testing the WebSEAL junction . . . . . . . 67
environment before reinstalling Tivoli Integrated Configuring single sign off for Tivoli Access
Portal . . . . . . . . . . . . . . . .6 Manager and Tivoli Integrated Portal . . . . . 67
Charting . . . . . . . . . . . . . . .6 Setting form-based authentication for WebSEAL 68
Memory needed on Linux for zSeries . . . . .7 Protecting the vault key file . . . . . . . . . 68
Installing in silent mode . . . . . . . . . .7 Configuring access for HTTP and HTTPS . . . . 69
Silent mode response file parameters . . . . .9 Enabling FIPS on the application server . . . . . 71
Accepting the security certificate . . . . . . . 11 Configuring the LPTA token timeout value . . . . 73
Uninstalling Tivoli Integrated Portal . . . . . . . 11 Configuring CMS to use a remote database . . . . 74
Uninstalling in silent mode . . . . . . . . 12 Creating a database for CMS . . . . . . . 74
Running the installer in an existing environment . . 13 Deleting a data source definition . . . . . . 75
Creating a data source for a remote database . . 76
Chapter 4. Upgrading Tivoli Integrated Configuring a hostname to be used by CMS . . 78
Configuring logging for CMS . . . . . . . 79
Portal . . . . . . . . . . . . . . . 15
Verifying your CMS configuration . . . . . . 80
Running pre-upgrade for an existing installation . . 15
Charting . . . . . . . . . . . . . . . 80
Exporting central user repository data . . . . 17
User roles for charting . . . . . . . . . . 80
Upgrading a base installation . . . . . . . . 18
Modifying chart properties . . . . . . . . 81
Manually rolling back an upgrade installation . . 19
Configuring multiple ITM Web Services . . . . 82
Performing post-upgrade steps . . . . . . . . 20
Configuring for localized or customized Tivoli
Importing LDAP data . . . . . . . . . . 20
Monitoring charts . . . . . . . . . . . 83
Configuring the timeout session setting . . . . 22
Importing or exporting charts and chart
Reconfiguring Tivoli Integrated Portal to run on a
customizations . . . . . . . . . . . . 84
higher version of Tivoli Integrated Portal . . . . 22
Configuring SSO between Charting and Tivoli
Monitoring . . . . . . . . . . . . . . 86
Chapter 5. Configuring . . . . . . . . 25
Central user registry . . . . . . . . . . . 25 Chapter 6. Administering . . . . . . . 89
Adding an external LDAP repository . . . . . 26
Logging in. . . . . . . . . . . . . . . 89
Configuring an external LDAP repository . . . 27
System user roles in Tivoli Integrated Portal . . . 90
Managing LDAP users in the console. . . . . 29
Stopping and starting the application server . . . 91
Configuring an SSL connection to an LDAP
Port assignments . . . . . . . . . . . . 92
server . . . . . . . . . . . . . . . 30
Viewing the application server profile . . . . . 92
Configuring an SSL connection to the
Changing passwords . . . . . . . . . . . 93
ObjectServer . . . . . . . . . . . . . 31
Exporting and importing . . . . . . . . . . 94
Single sign-on . . . . . . . . . . . . . 33
Basic export commands . . . . . . . . . 95
Configuring single sign-on . . . . . . . . 34
Advanced export commands . . . . . . . 98
Load balancing . . . . . . . . . . . . . 35
Import commands . . . . . . . . . . . 103
Exporting data from a stand-alone server to
Changing the default security registry . . . . . 106
prepare for load balancing . . . . . . . . 38
CGI support . . . . . . . . . . . . . . 106
Setting up a load balancing cluster . . . . . 39
Backing up and restoring the Deployment Engine 107
Joining a node to a load balancing cluster . . . 42
System Cloning Solution . . . . . . . . . 108
Enabling server-to-server trust . . . . . . . 44
Running SCS to export data . . . . . . . 109
Verifying a load balancing implementation . . . 46
Running SCS to import data . . . . . . . 110
Preparing the HTTP server for load balancing . . 47
Setting Java Virtual Machine memory for TIPProfile 110
Importing stand-alone instance data to a cluster 54
Checking hostname settings . . . . . . . . 111
Monitoring a load balancing cluster . . . . . 55
Accessing Context Menu Service features . . . . 112
Removing a node . . . . . . . . . . . 56
Copyright IBM Corp. 2009, 2012 iii

Command reference . . . . . . . . . . . 113 Setting the libstdc++ level for Linux systems 145
Working with roles . . . . . . . . . . 113 Installation fails with error code ADMR0104E in
Working with views . . . . . . . . . . 125 SystemOut.log . . . . . . . . . . . . 146
Working with users . . . . . . . . . . 126 Login errors . . . . . . . . . . . . . . 146
Working with preference profiles . . . . . . 126 Harmless authentication messages . . . . . 146
Working with portlets . . . . . . . . . 127 Already logged in . . . . . . . . . . . 147
Working with pages . . . . . . . . . . 127 No user role assigned . . . . . . . . . 147
Working with user groups . . . . . . . . 128 Slow network response . . . . . . . . . 147
Charting tipcli commands . . . . . . . 128 System in maintenance mode . . . . . . . 147
Tivoli Integrated Portal Export commands. . . 130 Viewing TIPProfile logs for login errors . . . 147
Import tipcli commands . . . . . . . . 134 Chart errors . . . . . . . . . . . . . . 148
Context Menu Service tipcli commands . . . 136 Tivoli Enterprise Portal Server is offline . . . 152
Additional commands . . . . . . . . . 137 Editing a properties file . . . . . . . . . . 152
Setting a trace . . . . . . . . . . . . . 153
Chapter 7. Troubleshooting . . . . . 139 Considerations when changing a user ID . . . . 154
Installation errors . . . . . . . . . . . . 139 Disabling Internet Explorer Enhanced Security
Harmless installation messages . . . . . . 139 Configuration . . . . . . . . . . . . . 154
Insufficient disk space for install . . . . . . 139 Resolving the FileNotFound Exception error on
TIPProfile_create log . . . . . . . . . . 139 UNIX and Linux systems . . . . . . . . . 155
Installation failure scenario . . . . . . . . 140
Log files . . . . . . . . . . . . . . 142 Notices . . . . . . . . . . . . . . 157
Install fails after deployment engine upgrade 143 Trademarks . . . . . . . . . . . . . . 158
Installation fails on a HP Integrity server . . . 144
Installation fails on Windows Server 2008 . . . 144 Index . . . . . . . . . . . . . . . 159
Preupgrade steps fails on HP Itanium (ia64)
systems . . . . . . . . . . . . . . 144
iv Tivoli Integrated Portal Administration and configuration guide

Chapter 1. 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.
Related reference:
Chapter 2, Tivoli Integrated Portal components, on page 3
Your Tivoli Integrated Portal installation has a core set of components that provide
such administrative essentials as network security and database management.
Copyright IBM Corp. 2009, 2012 1

2 Tivoli Integrated Portal Administration and configuration guide
Chapter 2. Tivoli Integrated Portal components
Your Tivoli Integrated Portal installation has a core set of components that provide
such administrative essentials as network security and database management.
Core components
IBM Deployment Engine
The first core component installed is the deployment engine because it
determines what needs to be installed.
Tivoli Integrated Portal Server
The application server is a J2EE lightweight implementation of the
WebSphere Application Server. It provides a single sign-on service based
on the WebSphere security module and Lightweight Third Party
Authentication (LTPA).
Integrated Solutions Console
The Integrated Solutions Console is the administrative console for your
applications. It is a Web-based portal component that provides common
task navigation for products, aggregation of data from multiple products
into a single view, and message passing between views from different
products.
IBM HTTP Server
The Web server is installed with the Tivoli Integrated Portal Server.
Common Gateway Interface Server
The CGI server enables external programs to interact with information
servers such as HTTP servers. You can write scripts for the CGI.
Optional components
These are the components that you can choose whether to install. It is possible that
not every optional component listed here is offered for your product. See your
product documentation for more information.
WebSphere federated repository functionality
Environments that have external user registries can participate in a
federated repository. You can configure a Lightweight Directory Access
Protocol server or Tivoli Netcool/OMNIbus ObjectServer or both as a
central user registry. For load balancing or single sign-on capability, an
external authentication source is required.
Load balancing
Load balancing allows several application server instances to run and share
the load. It requires an external user authentication source: LDAP or
ObjectServer.
Charting
When included as part of your product installation, charting provides for
the creation of custom charts and retrieval of data from supported Tivoli
products into chart types of your choosing: bar, pie, and line charts or table
views. The Charting service interacts with the BIRT Designer and ITM Web
Service to render the data in charts.

ITM Web Service is a J2EE application for accessing IBM Tivoli Monitoring
query information. It extends the charting features to display data from
any of the Tivoli monitoring and analytics products.
The Business Intelligence and Reporting Tools Designer is an Eclipse-based
tool that is provided as a compressed file and installed with the application
server. This stand-alone tool runs on Windows only and is available as
soon as you extract it.
Related concepts:
Chapter 1, Tivoli Integrated Portal overview, on page 1
Web-based products built on the Tivoli Integrated Portal framework share a
common user interface where you can launch applications and share information.
Chapter 3, Installing, on page 5
Tivoli Integrated Portal is installed in silent mode as part of a product installation.
Preparing for installation on page 5
Learn what hardware and software is required and the information you need to
have before beginning an installation. There might also be services that must be
running and available for the installation.

Chapter 3. Installing
Tivoli Integrated Portal is installed in silent mode as part of a product installation.
Important: If your are installing into an existing Tivoli Integrated Portal instance,
you should install the new instance using the user details that were used to install
the initial instance.
Attention: If your are installing into an existing Tivoli Integrated Portal instance,
only those components that have been updated since the previous instance was
installed will have version numbering that reflects the latest release.
After the installation, the Tivoli Integrated Portal administrator and any registered
users can log in to the Tivoli Integrated Portal by entering the URL in a browser,
for example, if you installed using default port numbers, you would access the
console using the following web address:
v http://localhost:16310/ibm/console
Preparing for installation

The following requirements and restrictions must be considered when you install
Tivoli Integrated Portal:
v WebSphere Application Server Version 7.0 (7.0.0.15) hardware and software
requirements apply, for more information, see http://publib.boulder.ibm.com/
infocenter/wasinfo/v7r0/topic/com.ibm.websphere.installation.express.doc/
info/exp/ae/rtop_reqs.html
v At least 1024 MB of RAM is required, but 2048 MB is preferred.
v 800 MB of disk space available to the installation process.
v To use Tivoli Integrated Portal with Internet Explorer Version 7, you must disable
Internet Explorer Enhanced Security Configuration
v On Linux systems, the Deployment Engine component does not
support the libstdc++.so.6 standard library, that is, you must use
libstdc++.so.5 or lower.
v For zLinux systems, the libstdc++.so.6 standard library is required.
v For Solaris 9 operating systems the JRE package should be uncompressed to a
separate subfolder under /usr
v For S390x Redhat 6.0 Linux systems, you need install the following RPM
Package Managers:
1. yum install glibc-2.12-1.7.el6_0.3.s390
2. yum install compat-libstdc++-33-3.2.3-69.el6.s390
For additional hardware and software requirements, refer to your product

documentation.

Related tasks:
Disabling Internet Explorer Enhanced Security Configuration on page 154
Internet Explorer Enhanced Security Configuration is an option that is provided in
Windows Server 2003 operating systems and above. To use Tivoli Integrated Portal
with Internet Explorer Version 7, you must disable Internet Explorer Enhanced
Security Configuration.
Setting the libstdc++ level for Linux systems on page 145
The Deployment Engine component does not support libstdc++.so.6 or higher on
Linux systems.
Preparing a WebSphere Application Server environment

before reinstalling Tivoli Integrated Portal
Prepare the environment before you reinstall Tivoli Integrated Portal in an existing
WebSphere Application Server environment.
About this task
To prepare the WebSphere Application Server base environment:
Procedure
1. Using the command line, uninstall the previous instance of Tivoli Integrated
Portal and any other Tivoli Integrated Portal related products.
2. Once the uninstallation has completed, you must delete the following Tivoli
Integrated Portal and Tivoli Integrated Portal related directories:
v was_home_dir/_uninst
v was_home_dir/profiles/TIPProfile
v was_home_dir/profiles/productIDProfile_dir
Where productIDProfile_dir is a product specific profile directory. If more than
one Tivoli Integrated Portal related product is installed, you must delete all
product specific directories.
3. Delete the following log file directories:
v was_home_dir/logs/install
v was_home_dir/logs/manageprofiles
v was_home_dir/logs/profiles
4. Delete all log files within the following directory:
was_home_dir/logs
Results
The WebSphere Application Server environment is now ready to reinstall Tivoli

Integrated Portal.
Related tasks:
Uninstalling in silent mode on page 12
Use the silent uninstaller to remove Tivoli Integrated Portal from a computer if you
no longer need it.
Charting
Charting is a component that enables you to display charts from supported Tivoli
products and charts that were created with the Business Intelligence and Reporting
Tools Designer.

The Charting component also installs the ITM Web Service with the Tivoli
Integrated Portal Server. When Tivoli Management Services is part of your
networked enterprise, the ITM Web Service is used to query attribute values
collected by your IBM Tivoli Monitoring or OMEGAMON XE products and
retrieve them to chart portlets in the console.
Important: If your installation will use the ITM Web Service, be sure to read
Configuring SSO between Charting and Tivoli Monitoring on page 86 before
installing Tivoli Integrated Portal.
Your product may already come with predefined charts or perhaps the chart
format is not appropriate for your product. In either case, you will not see the
Charting option during an advanced installation if it is not offered with your
product.
Secure Web service connection
Charting supports the HTTPS protocol for confidentiality. When requests are made
to retrieve Tivoli Monitoring data into a chart portlet, the user name and password
that were provided at installation time are passed to the Tivoli Enterprise Portal
Server, and a Lightweight Third Party Authentication (LTPA) token is passed to the
backend Web service.
To participate in this secure connection, the ITM Web Service must be installed and
run on the same Tivoli Integrated Portal Server instance.
Related reference:
IBM Tivoli Monitoring and OMEGAMON XE information center
For details about the Administration Mode Eligible permission, search for
"Permissions tab".
Memory needed on Linux for zSeries

In preparing for a Tivoli Integrated Portal installation on Linux for zSeries, make
sure that the temporary directory has at least 500 MB of space available.
After you start a Tivoli Integrated Portal installation on Linux for zSeries if your
system does not have at least 500 MB /tmp space, you might get a message to set
IATEMPDIR. Sometimes setting this environment variable will not allow you to
continue installation. You can either increase the space available to at least 500 MB
in the temporary directory or link /tmp to a directory with at least 500 MB free
space as shown in the example.
rm -rf /tmp
mkdir /dir-with-large-space/tmp
ln -s /dir-with-large-space/tmp /tmp
Installing in silent mode

A silent mode installation uses a response file that is included with your
installation media that you can edit as needed. Run the installation in silent mode
if you want to deploy the product with identical installation configurations on
multiple computers. In silent mode, the installation process obtains the installation
settings from a predefined response file and does not prompt you for any
information.
Chapter 3. Installing 7
Before you begin
After reading the "Preparing for installation" topics and satisfying any
prerequisites, you are ready to start the installation procedure.
About this task
A silent installation proceeds automatically, using the settings as they are set a
response file (for example, sample_response.txt). Edit this file to specify the
choices and values to be used by the silent installer. The response file can be
re-used on other computers where you would like the same kind of product
installation. In these steps, be sure to provide the complete (absolute) path of the
response file for the silent installer. Otherwise, the installer will not find the
response file and the installer will fail.
Procedure
1. Open your response file in a text editor (in these steps, it is called
sample_response.txt) and review the configuration settings. Edit as needed,
then save and close the file.
2. Provide values for the following settings, which determine account details for
the administrative user:
v IAGLOBAL_WASUserID
v IAGLOBAL_WASPassword
3. Optional: Edit the default port number settings as required.
4. You can install Tivoli Integrated Portal with an embedded WebSphere
Application Server or alternatively into an existing WebSphere Application
Server base installation.
v To use an embedded WebSphere Application Server, set
IAGLOBAL_INSTALL_INTO_WAS_HOME to false and set IAGLOBAL_TIP_HOME path to
where you would like to install Tivoli Integrated Portal, for example:
C:\\IBM\\tivoli\\tipv2
Note: The \ (backslash) character is seen as an escape character. Use two

\\ as shown above when defining the path.
/opt/IBM/tivoli/tip
v To install in an existing WebSphere Application Server base, set
IAGLOBAL_INSTALL_INTO_WAS_HOME to true and set IAGLOBAL_TIP_HOME to the
existing WebSphere Application Server location, which is often called the
WAS_HOME.
5. At the command line, change to directory that contains your response file, for
example, C:\tipinstall\cdimage
6. Enter the following at the command line:
Important: To set up and run this function on a Microsoft Windows

operating system, your user ID must belong to the administrator group and
have the following advanced user rights:
v Act as part of the operating system
v Log on as a service
Note:

For systems running Microsoft Windows Vista or Microsoft Windows Server
2008, you must run install.bat as an administrator, that is, right click on the
command file (or a shortcut to it) and select Run as administrator before you
run this command.
v install.bat full_path_to_JRE sample_response.txt
v ./install.sh full_path_to_JRE sample_response.txt
Note: full_path_to_JRE should not include the bin subdirectory.

Ensure that you enter escape characters the way the Java properties expects
them. Non-text characters must be UTF-8 escaped (such as \u0022 for the "
double-quote character).
Note: Installation logs are saved to TIPInstaller-xx.log located in the ia

directory contained in the following zip archive: tip_home_dir/logs.zip.
What to do next
The passwords entered in the response file can be seen by anyone who reads the
file. When you are done using this file, delete it or move it to a secure place to
keep passwords secure.
Related concepts:
Installation errors on page 139
Review the Preparing to install topics before starting an installation; review the
topics here for handling errors that might arise during the installation.
Port assignments on page 92
The application server requires a set of sequentially numbered ports.
Related tasks:
Logging in on page 89
Log in to the portal whenever you want to start a work session.
Viewing the application server profile on page 92
Open the application server profile to review the port number assignments and
other information.
Running the installer in an existing environment on page 13
The Tivoli Integrated Portal platform is laid down during product installation. You
can install additional products and they will all share the same platform.
Related reference:
Silent mode response file parameters
Silent mode response file parameters

IAGLOBAL_INSTALL_INTO_WAS_HOME=true
When set to true, it indicates your intent to install into an existing WebSphere
Application Server base installation. A setting of false indicates your intent to
install Tivoli Integrated Portal with an embedded WebSphere Application Server.
IAGLOBAL_TIP_HOME=C:\\IBM\\tivoli\\tipv2
Set this to indicate where you want to install Tivoli Integrated Portal. If you are
installing into an existing WebSphere Application Server base provide the base
WebSphere Application Server location (also called the WAS_HOME). When
you are installing using an embedded WebSphere Application Server, the
default directory is:
v C:\\IBM\\tivoli\\tip. The \ backslash is seen as an escape
character. Use \\ two backslashes when defining the path.
v /opt/IBM/tivoli/tip
If Tivoli Integrated Portal has been installed before, you can specify the
existing location to reuse the instance.
IAGLOBAL_WASUserID=tipadmin
IALOCAL_WASPassword=mypassword
These parameters are for defining the administrator ID for the application
server profile. The tipadmin ID is the default user ID, which you can change to
another name. The password entered here will be required when you log in to
the portal.
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
These are the default port numbers to use for the application server profile.
You can change the port numbers so long as they are not already in use.
IAGLOBAL_CONSOLE_CONTEXT_ROOT=/ibm/console
If no value is set, the default context root (/ibm/console) is used. Values
should not include:
v Special characters, such as % & ^ ` * ( ) - + = @ ! ~ #
v Double slashes, such as //ibm/console
v spaces, such as / ibm/console
IAGLOBAL_COI_SELECTED_LOGICAL_COMPONENTS=Common,TIPFinal
This parameter indicates which components are to be installed. You must at
least include the default values (Common,TIPFinal). Ensure that the additional
components are available to the installer at cdimage/COI/PackageSteps. For
example, to install the BIRTExtension component enter a value of
Common,TIPFinal,BIRTExtension.
IAGLOBAL_LOCALE=en
This parameter indicates the locale of the resource bundle for the installer to
load.

Related concepts:
Installation errors on page 139
Related tasks:
Installing in silent mode on page 7
A silent mode installation uses a response file that is included with your
installation media that you can edit as needed. Run the installation in silent mode
if you want to deploy the product with identical installation configurations on
multiple computers. In silent mode, the installation process obtains the installation
settings from a predefined response file and does not prompt you for any
information.
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.
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.
Uninstalling Tivoli Integrated Portal

Uninstall Tivoli Integrated Portal when you no longer need it on a computer.
Important: WebSphere Application Server fix packs and interim fixes are not
removed when you uninstall Tivoli Integrated Portal.
Important: If you are uninstalling Tivoli Integrated Portal as a non-administrative

user and you previously installed this instance of Tivoli Integrated Portal into an
existing Tivoli Integrated Portal environment that had been installed by an
administrative user, you may see the following error in the log files:
Caused by: com.ibm.ac.si.install.InstallUnauthorizedException: ACUINI0040W

User, user_ID, does not have proper authority!
In this particular circumstance, the error message may be ignored and no further
action is required.
Uninstalling in silent mode

Use the silent uninstaller to remove Tivoli Integrated Portal from a computer if you
no longer need it.
About this task
The silent mode uninstaller removes Tivoli Integrated Portal using the
uninstall_response.txt file. The file has three parameters: INSTALLER_UI=SILENT,
IAGLOBAL_WASUserID=tipadmin, and IALOCAL_WASPassword=mypassword.
To uninstall Tivoli Integrated Portal in silent mode:
Procedure
1. From the command line, change to the uninstall directory:
cd tip_home_dir/_uninst/TIPInstall2201 For example: /opt/IBM/tivoli/tip/
_uninst/TIPInstall2201 or c:\IBM\tivoli\tip\_uninst\TIPInstall2201.
2. Enter this command:
v uninstall.bat full_path__to_JRE
full_path_to_uninstall_response\uninstall_response.txt
v ./uninstall.sh full_path__to_JRE
full_path_to_uninstall_response/uninstall_response.txt
Note: Uninstallation logs are saved to TipInstaller-xx.log that is located in

the ia directory contained in the following zip archive: tip_home_dir/logs.zip.
Note: Charting data associated with load balanced installations is not removed
from the DB2 database when you uninstall Tivoli Integrated Portal.
3. After the process is complete, delete the tip_home_dir branch from the tivoli
directory (such as C:\IBM\ and /opt/IBM/) if it still remains and there are no
previously installed applications in that branch that you want to keep.
What to do next
Related tasks:
Preparing a WebSphere Application Server environment before reinstalling Tivoli
Integrated Portal on page 6
Prepare the environment before you reinstall Tivoli Integrated Portal in an existing
WebSphere Application Server environment.
Stopping the ITM Monitoring Agent for Windows OS after

uninstalling
If Tivoli Integrated Portal and the IBM Tivoli Monitoring Agent for Windows OS
are installed on a computer running Windows Server 2003, after uninstalling Tivoli
Integrated Portal, tip_home_dir\bin\WASServiceMsg.dll cannot be deleted.

Before you begin
This problem exists only when you uninstall Tivoli Integrated Portal from a
computer running Windows Server 2003 and the IBM Tivoli Monitoring Agent for
Windows OS is also installed.
About this task
If after uninstalling Tivoli Integrated Portal, you cannot delete

tip_home_dir\bin\WASServiceMsg.dll, you must first stop the IBM Tivoli
Monitoring Agent for Windows OS service:
Procedure
1. In Control Panel, open the Administrative Tools panel and then open the
Services panel.
2. In the list of services, locate and stop the Monitoring Agent for Windows OS
service.
3. Delete the tip_home_dir directory.
Running the installer in an existing environment

Before you begin
Back up the current tip_home_dir directory branch in case you want to revert to
that installation.
About this task
When a product is installed into an existing Tivoli Integrated Portal environment,

some options might be disabled, depending on what was installed before. When
you rerun the installer, the product installation runs in maintenance mode.
Procedure
1. Back up the deployment engine database in case you want to revert to that
installation. You might also want to back up the tip_home_dir directory for any
data files that you need to retrieve.
2. If you will be running in silent mode, update the sample_response.txt file with
the features to be installed.
3. Run the installation program in silent mode.
Related tasks:
Backing up and restoring the Deployment Engine on page 107
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.
Chapter 4. Upgrading Tivoli Integrated Portal
Existing Tivoli Integrated Portal installations can be upgraded to run in a higher
version of the Tivoli Integrated Portal.
You can upgrade a application server instance and transfer data to the upgraded
instance. With release of Tivoli Integrated Portal Version 2.2 you can also upgrade
an instance of the application server between different platforms, for example,
from a 32 bit platform to a 64 bit platform.
Note: You can also use the upgrade process to transfer data from an instance of
Tivoli Integrated Portal to another computer running another instance of Tivoli
Integrated Portal of the same version level.
The upgrade process includes a number of steps:

Pre-upgrade
Export instance specific information from the earlier version of the Tivoli
Integrated Portal installation.
Important: Ensure that you have the latest Tivoli Integrated Portal fix pack
installed on the originating Tivoli Integrated Portal installation
Installation
Install the higher version of Tivoli Integrated Portal.
Upgrade
Import the information gathered in the pre-upgrade step to the new
instance of Tivoli Integrated Portal.
Post-upgrade
Configure the new Tivoli Integrated Portal instance to replicate the initial
environment setup.
Important: When you are upgrading a Tivoli Integrated Portal instance, you should
install the new instance using the user details that were used to install the initial
instance.
After the upgrade, the Tivoli Integrated Portal administrator and any registered
users can log in to the portal by entering the URL in a browser, for example, if you
installed using default port numbers, you would access the portal using the
following web address:
v https://localhost:16311/ibm/console/
Important: For Tivoli Integrated Portal instances running in a load balanced cluster,
each node should disjoined from the original cluster and upgraded separately.
Once all the nodes have been upgraded, a new cluster can be created.
Running pre-upgrade for an existing installation

To upgrade Tivoli Integrated Portal to a new version, you have to perform some
pre-upgrade steps on the original Tivoli Integrated Portal instance so that the new
installation can be configured with similar settings and customizations.

Before you begin
Back up the current tip_home_dir and prod_home_dir directory branches in case

you want to revert to that installation.
Back up the deployment engine database in case you want to revert to that
installation.
Locate the product_IDpreupgrade.zip from your Tivoli Integrated Portal Version X.X
installation media.
About this task
To run the pre-upgrade process on your originating Tivoli Integrated Portal instance:
Procedure
1. On the computer running the originating version of Tivoli Integrated Portal,
extract product_IDpreupgrade.zip to tip_home_dir/profiles/TIPProfile.
2. At the command line, run the following command:
v tip_home_dir\profiles\TIPProfile\upgrade\bin\preupgrade.bat
[tip_home_dir] [--username username --password password] [--productId
productId] [--ignoreTIP true||false]
v tip_home_dir/profiles/TIPProfile/upgrade/bin/
preupgrade.sh [tip_home_dir] [--username username --password password]
[--productId productId] [--ignoreTIP true||false]
Where:
username and password
The account details for the Tivoli Integrated Portal administrator.
tip_home_dir
The installation directory for your originating Tivoli Integrated Portal
instance.
Note: This argument is not required if you run the command in the
tip_home_dir/profiles/TIPProfile directory.
productId
Your Tivoli Integrated Portal-specific product identifier.
Note: This argument is not required if you want to include Tivoli

Integrated Portal data only, that is custom pages that users may have
created using Tivoli Integrated Portal portlets only.
ignoreTIP
This argument is optional (set to false by default, so that Tivoli
Integrated Portal data is gathered). Include the argument and set its
value to true so that Tivoli Integrated Portal data is excluded.
When the command completes, an upgradeData.zip file is created in

tip_home_dir/profiles/TIPProfile/upgrade/data/.
What to do next
Locate upgradeData.zip and copy it to the computer where you intend to install
the higher Tivoli Integrated Portal version. Also, if your originating Tivoli Integrated
Portal installation uses a central user repository (Lightweight Directory Access

Protocol or Tivoli Netcool/OMNIbus ObjectServer), you can export that data and
move it to the computer where you intend to install the higher version.
Related tasks:
Upgrading a base installation on page 18
After you have performed the pre-upgrade steps on the originating Tivoli Integrated
Portal instance and installed a higher version in a new location, whether on the
same computer or on a separate one, you can complete the upgrade process and
populate the new installation with data from the originating older instance.
Preupgrade steps fails on HP Itanium (ia64) systems on page 144
The Tivoli Integrated Portal preupgrade step may fail on HP Itanium (ia64) systems
running UNIX, whereby the systems appears to lock up or hang.
Related reference:
tipcli - Export plugins on page 130
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.
Exporting central user repository data

To export data specific to an installation of Tivoli Integrated Portal that uses a central
user repository (Lightweight Directory Access Protocol or Tivoli Netcool/OMNIbus
ObjectServer), you must run a script on the originating computer.
Before you begin
Back up the current tip_home_dir and prod_home_dir directory branches in case

you want to revert to that installation.
Back up the deployment engine database in case you want to revert to that
installation.
Depending on the central user repository that you use, locate

exportLDAPconfig.bat|.sh or exportVMMObjectServerConfig.bat|.sh from your
Tivoli Integrated Portal Version X.X installation media.
About this task
To run the central user repository export process, on your originating Tivoli
Integrated Portal instance:
Procedure
1. On the computer running the originating version of Tivoli Integrated Portal,
depending on your central user repository, copy the relevant operating system
version of exportLDAPconfig.bat|.sh or exportLDAPconfig.bat|.sh to
tip_home_dir/profiles/TIPProfile.
2. At the command line, change to: tip_home_dir/profiles/TIPProfile/
3. At the command line, depending on the central user repository, run one the
relevant command:
v For an LDAP repository:
tip_home_dir\profiles\TIPProfile\exportLDAPconfig.bat
install_dir export_dir
tip_home_dir/profiles/TIPProfile/
exportLDAPconfig.sh install_dir export_dir
Chapter 4. Upgrading Tivoli Integrated Portal 17

v For an ObjectServer repository:
tip_home_dir\profiles\TIPProfile\
exportVMMObjectServerConfig.bat install_dir export_dir
exportVMMObjectServerConfig.sh install_dir export_dir
Where:
tip_home_dir
The installation directory for your originating Tivoli Integrated Portal
instance.
export_dir
The directory where you want to output data to be saved.
When the command completes, an repository_name.properties file is created

in export_dir.
What to do next
Copy the repository_name.properties file to the computer where you intend to

install the higher Tivoli Integrated Portal version and take a note of its location. You
are now ready to install the higher version of your product, be it on the same
computer or on a separate one.
Related tasks:
Importing LDAP data on page 20
To import Lightweight Directory Access Protocol data specific to a previous
installation of Tivoli Integrated Portal, you must run a script.
Upgrading a base installation

After you have performed the pre-upgrade steps on the originating Tivoli Integrated
Portal instance and installed a higher version in a new location, whether on the
same computer or on a separate one, you can complete the upgrade process and
populate the new installation with data from the originating older instance.
Before you begin
Install the higher version of Tivoli Integrated Portal on a separate computer to

originating instance or on the same computer. If you install the new instance on
the same computer, ensure that you specify different port numbers during the
installation, so that the new instance does not conflict with the older instance.
Back up the deployment engine database for the new in case you want to roll back
from the upgrade.
Back up the current tip_home_dir directory branch.
Back up the current prod_home_dir directory branch.
Ensure that Tivoli Integrated Portal Server is running.
Ensure that you have copy of upgradedata.zip from the originating Tivoli Integrated
Portal instance available on the computer where you installed the higher version.

About this task
To perform the upgrade process for your new Tivoli Integrated Portal instance:
Procedure
1. On the computer where you installed the new version of Tivoli Integrated Portal,
at the command line, run the following command:
upgrade.sh [tip_home_dir] [--username username --password password]
[--productId productId] [--upgradeDataFile upgradeDataFile_path]
v tip_home_dir\profiles\TIPProfile\upgrade\bin\upgrade.bat
[tip_home_dir] [--username username --password password] [--productId
productId] [--upgradeDataFile upgradeDataFileName]
Where:
username and password
tip_home_dir
The installation directory for your Tivoli Integrated Portal instance.
Note: This argument is not required if you run the command in the
tip_home_dir/profiles/TIPProfile/upgrade/bin directory.
productId
The Tivoli Integrated Portal-specific product identifier.
upgradeDataFile
The path to the upgrade data file that you generated during the
pre-upgrade process for your originating Tivoli Integrated Portal instance
(for example, on a Windows system, C:\upgradedata.zip).
2. If your product is installed in a shared environment, you can check if the
previous Tivoli Integrated Portal installation had other products installed. To
check if any other products need to be configured in the new environment, run
the following command:
v tip_home_dir/profiles/TIPProfile/bin/
productSummary.sh
v tip_home_dir\profiles\TIPProfile\bin\productSummary.bat
A list of products that were installed in the originating Tivoli Integrated Portal
environment but are not present in the current environment is returned.
3. Repeat step 1 for each of the listed products returned at step 2 (if any).
What to do next
Perform post upgrade steps to complete the configuration of your new Tivoli
Integrated Portal installation.
Related tasks:
Running pre-upgrade for an existing installation on page 15
Manually rolling back an upgrade installation

The upgrade process upgrades products in a shared environment on a product by
product basis. If the upgrade fails for a product or component, the upgrade

process is automatically rolled back for all installed products and components. If
the automatic rollback fails, you can manually roll back the upgrade.
About this task
To manually roll back an upgrade installation, run the roll back for each product or
component:
Procedure
1. On the computer where you installed the new version of Tivoli Integrated Portal,
in a text editor, locate and open tip_home_dir\profiles\TIPProfile\backups\
rollbackSequencetimestamp.txt
2. Take note of the sequence in which the components and products are listed.
Products and components need to be rolled back in the order that they are
listed in this file.
3. At the command line, change to: tip_home_dir\profiles\TIPProfile\bin
4. At the command line, run the following command for each of the listed
products and components:
v tipcli.bat Import --rollback all --username tip_admin_user
--password tip_admin_password --backupDir tip_home_dir\profiles\
TIPProfile\backups\productId --productId productId --includePlugins
failed_rollback
v tipcli.sh Import --rollback all --username
tip_admin_user --password tip_admin_password --backupDir
tip_home_dir/profiles/TIPProfile/backups/productId --productId
productId --includePlugins failed_rollback
Where:
tip_admin_user and tip_admin_password
tip_home_dir
The installation directory for your Tivoli Integrated Portal instance.
productId
The product or component-specific identifier.
What to do next
Once you have manually rolled back the upgrade for all listed components and
products (including the Tivoli Integrated Portal installation), you can rerun the
upgrade process.
Performing post-upgrade steps

After you have successfully performed the upgrade steps for your new Tivoli
Integrated Portal instance, you can complete any additional configuration, for
example, import data related to a central user repository.
Importing LDAP data

To import Lightweight Directory Access Protocol data specific to a previous
installation of Tivoli Integrated Portal, you must run a script.

Before you begin
Back up the current tip_home_dir directory branch in case you want to revert to
that installation.
Locate the repository_name.properties file that was created when you exported
LDAP data from the originating Tivoli Integrated Portal installation.
Back up the deployment engine database.
About this task
To run the LDAP import script, on the computer running the new version of Tivoli
Integrated Portal:
Procedure
1. At the command line, depending on your operating system, run one the
relevant command:
v tip_home_dir\profiles\TIPProfile\bin\configureVMMLDAP.bat
tip_home_dir ldap_bind_dn_pwd repository_name.properties
v tip_home_dir/profiles/TIPProfile/bin/
configureVMMLDAP.sh tip_home_dir ldap_bind_dn_pwd
repository_name.properties
Where:
tip_home_dir
The Tivoli Integrated Portal installation directory.
ldap_bind_dn_pwd
The LDAP bind password.
repository_name.properties
The location of the LDAP properties file that was created when you
exported LDAP data from the originating Tivoli Integrated Portal
installation.
2. Stop and restart the Tivoli Integrated Portal Server:
a. 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.
b. In the tip_home_dir/profiles/TIPProfile/bin directory, depending on your
v startServer.bat server1
v startServer.sh server1
Results
Your new Tivoli Integrated Portal installation is now configured for the same user
repository that was used for the originating instance of your product.

Related tasks:
Exporting central user repository data on page 17
To export data specific to an installation of Tivoli Integrated Portal that uses a central
user repository (Lightweight Directory Access Protocol or Tivoli Netcool/OMNIbus
ObjectServer), you must run a script on the originating computer.
Configuring the timeout session setting

To configure the timeout session setting, as a post-upgrade task, you must run a
script.
About this task
To set the session timeout, on the computer running the new version of Tivoli
Integrated Portal:
Procedure
At the command line, depending on your operating system, run one the relevant
command:
v tip_home_dir\profiles\TIPProfile\upgrade\bin\configSesTimeOut.bat
tip_home_dir application_name TimeOutValue
configSesTimeOut.sh tip_home_dir application_name TimeOutValue
Where:
tip_home_dir
The Tivoli Integrated Portal installation directory.
application_name
The EAR application name of product for which you want to set the
timeout session value.
TimeOutValue
The time in minutes that you want to set for the timeout session.
Reconfiguring Tivoli Integrated Portal to run on a higher version of

Reconfigure an instance of Tivoli Integrated Portal to use a higher version of Tivoli
Integrated Portal, which is installed on the same computer as the current Tivoli
Integrated Portal Server instance.
Before you begin
Provide all the necessary credentials in the prod_home_dir/integration/

reconfiguration/reconfiguration.properties file.
If you have installed Tivoli Integrated Portal in a distributed scenario, perform these
steps for each Tivoli Integrated Portal instance.
No additional configuration is necessary for the reporting engine.

About this task
Tivoli Integrated Portal can only work on one Tivoli Integrated Portal instance at a
time. You can choose to configure it to operate on a higher version of Tivoli
Integrated Portal than the one you are currently using.
Procedure
1. Run the reconfigure.bat script, specifying the path to the new Tivoli
Integrated Portal Server instance as the argument:
v prod_home_dir\integration\reconfiguration\
reconfigure.battip_home_dir
v prod_home_dir/integration/reconfiguration/
reconfigure.sh tip_home_dir
2. In your web browser, log in to the newly upgraded Tivoli Integrated Portal
console by entering http://hostname:port/ibm/console. Verify that Tivoli
Integrated Portal is working properly.
Note: Pay attention to the port number that you enter to ensure that you are
logging in to the upgraded Tivoli Integrated Portal Server instance.
3. Depending on the result of your verification:
v Save the changes by running the following script:
prod_home_dir\integration\reconfiguration\
commitReconfiguration.bat
prod_home_dir/integration/reconfiguration/
commitReconfiguration.sh
Important: If you decide to save the changes, the Tivoli Integrated Portal
instance installed on the previous version of Tivoli Integrated Portal no
longer works, that is, it now works only on the upgraded Tivoli Integrated
Portal.
v Roll back the changes by running:
prod_home_dir\integration\reconfiguration\
rollbackReconfiguration.bat
prod_home_dir/integration/reconfiguration/
rollbackReconfiguration.sh
Important: If you choose to roll back the changes, Tivoli Integrated Portal
works only on the previous version of Tivoli Integrated Portal. It does not
work on the upgraded Tivoli Integrated Portal instance.
4. Restart Tivoli Integrated Portal.

Chapter 5. 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.
Central user registry

As a post-installation task you can configure a central user registry for user
management and authentication. You can configure an LDAP server or Tivoli
Netcool/OMNIbus ObjectServer registry (or both).
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.
In a network environment that includes a user registry on an LDAP server or

Tivoli Netcool/OMNIbus ObjectServer, you can configure Tivoli Integrated Portal to
use either or both types. In fact, these functions require a central user registry:
v Load balancing, which requires that each Tivoli Integrated Portal server instance
in the cluster use the same central user repository, whether that be anLDAP
server or an ObjectServer.
v Single sign-on, which authenticates users at the central repository during login
and whenever they launch into other authorized Tivoli applications.
Before configuring a central user registry, be sure that the user registry or registries
that you plan to identify are started and can be accessed from the computer where
you have installed the Tivoli Integrated Portal.
For central user repositories, unique IDs are composed of keys and values
separated by a comma (,), that is, "key1=value1,key2=value2,key3=value3". For
example, "uid=my_name,ou=my_ou_value,dc=ibm,dc=com". Tivoli Integrated Portal is
currently limited to using lower case keys in relation to unique IDs. For example,
the following unique IDs do not work:
v UID=my_name,OU=my_ou_value,DC=ibm,DC=com
v uid=my_name,ou=my_ou_value,DC=ibm,DC=com
Attention: When Tivoli Integrated Portal is configured with multiple central user
repositories, you cannot login if one remote user repository becomes inaccessible
from Tivoli Integrated Portal, even if your user ID exists in one of the other
repositories. If you need access is this situation, you have to run WebSphere
Application Server commands to allow access when all repositories are available,
or the federated repositories will not function properly. For more information, refer
to the following links:
v http://www-01.ibm.com/support/docview.wss?uid=swg1PK78677
v http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/
com.ibm.websphere.web20fep.multiplatform.doc/info/ae/ae/
rxml_atidmgrrealmconfig.html
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:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_tselugradro.html
Related reference:
Log files on page 142
Locate and review the logs and related files after an installation to confirm that the
components were successfully installed.
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.
About this task
To add a new LDAP repository:
Procedure
1. Log in to the Tivoli Integrated Portal.
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.
What to do next
Configure the Tivoli Integrated Portal Server to communicate with an external

LDAP repository.
Related concepts:
Single sign-on on page 33
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.
Related tasks:
Configuring SSO between Charting and Tivoli Monitoring on page 86
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 34
Use these instructions to establish single sign-on support and configure a federated
repository.
Changing passwords on page 93
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.
Chapter 5. Configuring 27
About this task
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.
2. In the navigation pane, click Settings > Websphere Administrative Console
and click Launch Websphere Administrative Console.
Global security.
click Configure.
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.
Global security.
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.
What to do next
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.
Related tasks:
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.
About this task
To create or manage LDAP users in the portal:
Procedure
Global security.
click Configure.
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.
Related tasks:
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.
Before you begin
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.

About this task
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
pane, click Security > SSL certificate and key management.
c. In the Related Items area, click the Key stores and certificates link and in
the table click the NodeDefaultTrustStore link.
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.
b. 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.
What to do next
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.
Related tasks:
Changing passwords on page 93
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.
About this task
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:
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:
a. Enable SSL for ObjectServer primary host: USESSLPRIMARY=TRUE
b. Enable SSL for ObjectServer backup host: USESSLBACKUP=TRUE


Related reference:
IBM Tivoli Network Management Information Center
Refer to the Netcool/OMNIbus Administration Guide for generating a trusted.txt
file
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.
Related tasks:
Adding an external LDAP repository on page 26
Configuring single sign-on
repository.
Changing the default security registry on page 106
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 68
To keep the encryption key for the administrator password secure, establish strict
read-only access to the vault key file.
Related reference:
Log files on page 142
Configuring single sign-on

repository.
Before you begin
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.
About this task
To configure the WebSphere federated repositories functionality for LDAP:
Procedure
and click Launch Websphere administrative console.
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.
10. After clicking OK to save your changes, stop and restart all the Tivoli
Integrated Portal Server instances.
What to do next
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.
Related concepts:
Related tasks:
Load balancing
You can setup a load balancing cluster of portal nodes with identical
configurations to evenly distribute user sessions.
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 55 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.
Related tasks:
Preparing the HTTP server for load balancing on page 47
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
configuration.
Installing the IBM HTTP Server
Creating a new key database
Creating a self-signed certificate
Setting up SSL for IBM HTTP Server
Related reference:
IBM DB2 Database for Linux, UNIX, and Windows Information Center
Consult the IBM DB2 Database Information Center to learn more about installation
requirements and how to use DB2.
Exporting data from a stand-alone server to prepare for load

balancing
You can export data from an existing stand-alone application server instance to
create a data file that can be imported to a load balanced cluster.
About this task
When you are creating a new load balanced cluster, 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:
tip_admin_username
tip_admin_password
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.
What to do next
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.
Before you begin
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 37.
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


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
-Dusername=DB2_username -Dpassword=DB2_password
Results
The load balancing cluster is created and the console node is joined to the cluster
as the first node.
What to do next
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.
Before you begin

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 39.
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.
About this task
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
1. 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.
bin/ha directory and edit the settings in tipha.properties.

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.
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. 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
v ..\ws_ant.bat -f install.ant configHA -Dusername=DB2_username
v ../ws_ant.sh -f install.ant configHA
Results
The console node is joined to the cluster.
What to do next
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.
About this task
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:

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
5. Save your changes to ssl.client.props.

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:

retrieveSigners.bat NodeDefaultTrustStore AnotherTrustStore -host myserver1
-port 16313
Related reference:
System in maintenance mode on page 147
A message about the system in maintenance mode in a load balancing
configuration can indicate that the servers have not had trust enabled between
them.
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.
About this task
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
configuration.
Before you begin
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.
About this task
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 47 and save your
changes.
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
<IfModule mod_ibm_ssl.c>
Listen 443
<VirtualHost *:443>
SSLEnable
</VirtualHost>
</IfModule>
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.
What to do next
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.

Related tasks:
Related reference:
IBM DB2 Database for Linux, UNIX, and Windows Information Center
Consult the IBM DB2 Database Information Center to learn more about installation
requirements and how to use DB2.
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.
About this task
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 <components
xmi:type="applicationserver.webcontainer:WebContainer.
3. Within the components element, add the following entry:
<properties xmi:id="WebContainer_1183077764084" name="HttpSessionCloneId"
value="12345" required="false"/>
Where:
value is the clone ID for the node, for example, value="12345". The clone ID
must be unique to each node. An example of an updated components element is
provided here:
<components xmi:type="applicationserver.webcontainer:WebContainer"
xmi:id="WebContainer_1183077764084" enableServletCaching="false"
disablePooling="false">
<stateManagement xmi:id="StateManageable_1183077764087"
initialState="START"/>
<services xmi:type="applicationserver.webcontainer:SessionManager"
xmi:id="SessionManager_1183077764084" enable="true" enableUrlRewriting="false"
enableCookies="true" enableSSLTracking="false"
enableProtocolSwitchRewriting="false"
sessionPersistenceMode="NONE" enableSecurityIntegration="false"
allowSerializedSessionAccess="false" maxWaitTime="5"
accessSessionOnTimeout="true">
<defaultCookieSettings xmi:id="Cookie_1183077764084" domain=""
maximumAge="-1" secure="false"/>
<sessionDatabasePersistence
xmi:id="SessionDatabasePersistence_1183077764084"
datasourceJNDIName="jdbc/
Sessions" userId="db2admin" password="{xor}Oz1tPjsyNjE="
db2RowSize="ROW_SIZE_4KB" tableSpaceName=""/>
<tuningParams xmi:id="TuningParams_1183077764084"
usingMultiRowSchema="false" maxInMemorySessionCount="1000"
allowOverflow="true" scheduleInvalidation="false"
writeFrequency="TIME_BASED_WRITE" writeInterval="10"
writeContents="ONLY_UPDATED_ATTRIBUTES" invalidationTimeout="30">
<invalidationSchedule xmi:id="InvalidationSchedule_1183077764084"
firstHour="14" secondHour="2"/>
</tuningParams>
</services>
<properties xmi:id="WebContainer_1183077764084" name="HttpSessionCloneId"
value="12345" required="false"/>
</components>
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.
About this task
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
following command:
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:
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
application server is installed and started.
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.
<Config ASDisableNagle="false" IISDisableNagle="false"
IgnoreDNSFailures="false" RefreshInterval="60"
ResponseChunkSize="64" AcceptAllContent="false"
IISPluginPriority="High" FIPSEnable="false"
AppServerPortPreference="HostHeader" VHostMatchingCompat="false"
ChunkedResponse="false">
<Log LogLevel="Trace" Name="HTTP SERVER PATH/Plugins/logs/webserver1/
http_plugin.log"/>
<Property Name="ESIEnable" Value="true" />
<Property Name="ESIMaxCacheSize" Value="1024" />
<Property Name="ESIInvalidationMonitor" Value="false" />
<Property Name="ESIEnableToPassCookies" Value="false" />
<Property Name="PluginInstallRoot" Value="HTTP SERVER PATH/Plugins" />
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:16310" />
<VirtualHost Name="*:HTTP SERVER PORT"/>
</VirtualHostGroup>
<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false"
IgnoreAffinityRequests="true" LoadBalance="Round Robin"
Name="server1_Cluster" PostBufferSize="64" PostSizeLimit="-1"
RemoveSpecialHeaders="true" RetryInterval="60">
<Server Name="TIPNode1_server1"
ConnectTimeout="0" CloneID="CLONE_ID" ExtendedHandshake="false"
ServerIOTimeout="0" LoadBalanceWeight="100" MaxConnections="-1"
WaitForContinue="false">
<Transport Hostname="SERVER1" Port="16310"
Protocol="http"/>
Protocol="https">
<Property name="keyring" value="HTTP SERVER PATH\Plugins\config
\webserver1\plugin-key.kdb"/>
<Property name="stashfile" value="HTTP SERVER PATH\Plugins\config
\webserver1\plugin-key.sth"/>
</Transport>
</Server>
<Server Name="TIPNode1_server2"
ConnectTimeout="0" CloneID="CLONE_ID" ExtendedHandshake="false"
ServerIOTimeout="0" LoadBalanceWeight="100" MaxConnections="-1"
WaitForContinue="false">
Protocol="http"/>
Protocol="https">
<Property name="keyring" value="HTTP SERVER PATH\Plugins\config
\webserver1\plugin-key.kdb"/>
<Property name="stashfile" value="HTTP SERVER PATH\Plugins\config
\webserver1\plugin-key.sth"/>
</Transport>
</Server>
<PrimaryServers>
<Server Name="TIPNode1_server1" />
<Server Name="TIPNode1_server2" />
</PrimaryServers>
</ServerCluster>
<UriGroup Name="server1_Cluster_URIs">
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
Name="/ivt/*" />
Name="/IBM_WS_SYS_RESPONSESERVLET/*" />
Name="/IBM_WS_SYS_RESPONSESERVLET/*.jsp" />
Name="/IBM_WS_SYS_RESPONSESERVLET/*.jsv" />
Name="/IBM_WS_SYS_RESPONSESERVLET/*.jsw" />
Name="/IBM_WS_SYS_RESPONSESERVLET/j_security_check" />
Name="/IBM_WS_SYS_RESPONSESERVLET/ibm_security_logout" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ibm/console/*" />
AffinityURLIdentifier="jsessionid" Name="/ibm/help/*" />
AffinityURLIdentifier="jsessionid" Name="/ibm/action/*" />
AffinityURLIdentifier="jsessionid" Name="/ISCWire/*" />
AffinityURLIdentifier="jsessionid" Name="/isc/*" />
AffinityURLIdentifier="jsessionid" Name="/ISCHA/*" />
AffinityURLIdentifier="jsessionid" Name="/tip_ISCAdminPortlet/*" />
AffinityURLIdentifier="jsessionid" Name="/ISCAdminPortlets/*" />
AffinityURLIdentifier="jsessionid" Name="/mum/*" />
AffinityURLIdentifier="jsessionid" Name="/ibm/TIPChangePasswd/*" />
AffinityURLIdentifier="jsessionid" Name="/ibm/TIPExportImport/*" />
AffinityURLIdentifier="jsessionid" Name="/ibm/tivoli/*" />
AffinityURLIdentifier="jsessionid" Name="/proxy/*" />
AffinityURLIdentifier="jsessionid" Name="/TIPWebWidget/*" />
AffinityURLIdentifier="jsessionid" Name="/ibm/dbfile/*" />
AffinityURLIdentifier="jsessionid" Name="/ibm/TIPChartPortlet/*" />
AffinityURLIdentifier="jsessionid" Name="/TIPUtilPortlets/*" />
AffinityURLIdentifier="jsessionid" Name="/WIMPortlet/*" />
AffinityURLIdentifier="jsessionid" Name="/SysMgmtCommonTaskGroups/*" />
</UriGroup>
<Route ServerCluster="server1_Cluster" UriGroup="server1_Cluster_URIs"
VirtualHostGroup="default_host" />
<RequestMetrics armEnabled="false" newBehavior="false" rmEnabled="false"
traceLevel="HOPS">
<filters enable="false" type="URI">
<filterValues enable="false" value="/snoop" />

<filterValues enable="false" value="/hitcount" />
</filters>
<filters enable="false" type="SOURCE_IP">
<filterValues enable="false" value="255.255.255.255" />
<filterValues enable="false" value="254.254.254.254" />
</filters>
<filters enable="false" type="JMS">
<filterValues enable="false" value="destination=aaa" />
</filters>
<filters enable="false" type="WEB_SERVICES">
<filterValues enable="false" value="wsdlPort=aaa:op=bbb:nameSpace=ccc" />
</filters>
</RequestMetrics>
</Config>
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.
Before you begin
This task assumes that you have already installed and configured the IBM HTTP
Server for load balancing.
About this task
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
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:
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.

c. 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.
What to do next
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.
About this task
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 38.

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:
tip_admin_username
tip_admin_password
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.
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
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
repository.
v -showAll
Specifies that all modules and nodes in the cluster should be returned.
This parameter is optional. The default is to return only repositories for
unsynchronized nodes.
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
Removing a node
Follow these steps to remove a node from the load balancing cluster.
About this task
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
-Dusername=DB2_username -Dpassword=DB2password
2. Update the network dispatcher (for example, IBM HTTP Server) to remove the
node from the configuration.
Removing a remote node

About this task
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

v ../ws_ant.sh -f uninstall.ant remote-disjoin
DremoteHost=remote_host DremotePort=9044 -Dusername=DB2_username
2. Update the network dispatcher (for example, IBM HTTP Server) to remove the
node from the configuration.
Removing a load balancing cluster

Follow these steps to remove the last node from a cluster and thereby the cluster
itself.
Before you begin
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.
About this task
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 -Dusername=DB2_username
v ../ws_ant.sh -f uninstall.ant uninstall
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.
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

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/
com.ibm.itame.doc/am611_webseal_admin.htm.
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.
Before you begin
Source a copy of com.ibm.sec.authn.tai.etai_6.0.jar from your installation

media.
About this task
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
What to do next
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.
About this task
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.
What to do next
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.
About this task
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 1. ETai custom properties
Property details Notes
ETai authenticates the trusted user against the
Property name:
WebSphere Application Server user registry or the
com.ibm.websphere
Tivoli Access Manager Authorization Server. If this
.security.webseal
property is set to true, the resulting Subject will not
.useWebSphereUserRegistry
contain a PDPrincipal as the Tivoli Access Manager
Type: string Authorization Server is required to build the
PDPrincipal. Any other value for this property will
Required: result in a PDPrincipal being added to the Subject.
Yes
Values: true or false
Default value:
true
The ETai adds users' credential information into the
Property name:
JAAS Subject. This information includes the users
com.ibm.websphere
dn. Maps this dn to the WebSphere Application
.security.webseal
Server dn, or (Value = WAS). If a mapping is
.tamUserDnMapping
attempted for a user that does not exist in the
Required: WebSphere Application Server user registry, it is
Yes ignored and not added to the JAAS Subject.
Value: WAS
Default value:
TAM
The ETai adds users' credential information into the
Property name:
JAAS Subject. This information includes the group
com.ibm.websphere
dn's. The ETai can be configured to either:
.security.webseal
.tamGroupDnMapping Map these dn's to the WebSphere Application Server
Required: dn's, or (Value = WAS).
Yes
If a mapping is attempted for a group that does not
Value: WAS exist in the WebSphere Application Server user
registry, it is ignored and not added to the JAAS
Default value:
Subject.
TAM
The value of this property must exist as a valid user
Property name:
in the user registry.
com.ibm.websphere
.security.webseal If necessary, create a new user in the Tivoli
.loginId Integrated Portal registry called websealSSOID.
Type: String
The ETai must be configured with the username of
Required: the WebSEAL trusted user. This is the single sign-on
Yes user that is authenticated using the password in the
Basic Authentication header inserted by WebSEAL in
Value: websealSSOID
the request. The format of the username is the short
Default value: name representation.
None
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.

Table 1. ETai custom properties (continued)
The ETai can be configured so that the Via header
Property name:
can be ignored when validating trust for a request.
com.ibm.websphere
This property is required, if WebSEAL is to allow
.security.webseal
requests into the Tivoli Integrated Portal only from
.checkViaHeader
particular hosts.
Type: String
This property interacts with the following
Required: properties:
Yes
v com.ibm.websphere.security.webseal.hostnames
Value: true v com.ibm.websphere.security.webseal.ports
Default value:
false
.webseal.checkViaHeader is set to false then the
values set for the two associated properties are not
used.
Iv-creds carrys end user credentials, which is used
Property name:
by Tivoli Integrated Portal for authorization.
com.ibm.websphere
Note: Any additional values set for this property
.security.webseal.id
are added to a list along with Iv-creds, that is,
Required: Iv-creds is a required header for the ETai.
Yes
Value: iv-creds
Default value:
iv-creds
The ETai can be configured so that the request must
Property name:
arrive from a list of expected hosts. If any of the
com.ibm.websphere
hosts in the Via header of the HTTP request are not
.security.webseal
listed in the values set for this property, the request
.hostnames
is ignored by the ETai.
Required:
Yes This property interacts with the following property:
com.ibm.websphere.security.webseal.ports
Value: A comma separated list of
strings. All of the values listed for
Default value: com.ibm.websphere.security.webseal.hostnames are
There is no default value used with the ports listed for
for this property. 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
com.ibm.websphere.security.webseal.hostnames are
not used.
Table 1. ETai custom properties (continued)
This property interacts with the following property:
Property name:
com.ibm.websphere com.ibm.websphere.security.webseal.hostnames
.security.webseal
All of the values listed for
.ports
com.ibm.websphere.security.webseal.hostnames are
Required: used with the ports listed for
Yes com.ibm.websphere.security.webseal.ports to
indicate a trusted host.
Value: 443
Default value: For more information, see the notes for
There is no default value com.ibm.websphere.security.webseal.hostnames.
for this property.
Once trust has been established for a request, the
Property name:
password for the Single sign-on user is cached for
com.ibm.websphere
subsequent trust validation of requests. This saves
.security.webseal
the ETai from having to re-authenticate the single
.ssoPwdExpiry
sign-on user with the user registry for every request,
Required: therefore increasing performance. The cache timeout
No period can be modified by setting this property to
the required time in seconds. If the password expiry
Value: A positive integer. property is set to 0, the cached password does not
Default value: expire.
600
This property is needed to map the group realm
Property name:
prefix from Tivoli Access Manager to group realm
com.ibm.websphere
prefix in WebSphere Application Server registry.
.security.webseal
.groupRealmPrefix
Required:
Yes
Value: group:
Default value:
600
This property is needed to map the user realm
Property name:
prefix from Tivoli Access Manager to group realm
com.ibm.websphere
prefix in WebSphere Application Server registry.
.security.webseal
.userRealmPrefix
Required:
Yes
Value: user:
Default value:
600
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.


What to do next
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.
Before you begin
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
About this task
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).
What to do next
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.
About this task
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.
5. Start the IKeyman utility and complete the substeps:
v At the command line, enter ./ikeyman.sh
v At the command line, enter ikeyman.exe
a. On the toolbar, click Open to display the Open window.

b. Select CMS as the key database type.
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
What to do next
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
About this task
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 s l.
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.
What to do next
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.
About this task
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
What to do next
Test the WebSEAL junction.

Testing the WebSEAL junction
Once you have created a WebSEAL junction, you can test it.
About this task
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.
What to do next
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

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.
About this task
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:
<consoleproperties:console-property id="TAMJunctionName" value="tip"/>
<consoleproperties:console-property id="WebSealServerName" value=""/>
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.
About this task
For information on WebSEAL authentication and changing from basic mode to the
form-based mode refer to Tivoli Access Manager documentation at
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/
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.
Before you begin
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.
About this task
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.

Related concepts:
Configuring access for HTTP and HTTPS

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.
Before you begin
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.
About this task
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 <transport-guarantee> element. The initial value of all
<transport-guarantee> 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: <transport-guarantee>NONE</transport-guarantee>.
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:
<security-constraint>
<display-name>
ChangePasswdControllerServletConstraint</display-name>
<web-resource-collection>
<web-resource-name>ChangePasswdControllerServlet</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<description>Roles</description>
<role-name>administrator</role-name>
<role-name>operator</role-name>
<role-name>configurator</role-name>
<role-name>monitor</role-name>
<role-name>iscadmins</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
What to do next
Users must now specify a different port, depending on the mode of access. The
default port numbers are as follows:
http://<host_name>:16310/ibm/console
Use the HTTP port for logging in to the Tivoli Integrated Portal on the
HTTP port .
https://<host_name>:16311/ibm/console
Use the HTTPS secure port for logging in to the Tivoli Integrated Portal.
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.

Related tasks:
Stopping and starting the application server on page 91
The Tivoli Integrated Portal Server starts automatically after it has been installed,
and on systems running Windows, whenever the computer is started.
Enabling FIPS on the application server

You can configure the application server to use a Federal Information Processing
Standard (FIPS) approved cryptographic provider.
About this task
Tivoli Integrated Portal password encryption algorithms on the application server

use FIPS approved cryptographic providers regardless of whether FIPS is enabled
for the entire application server. However, enabling FIPS on the application server
ensures that the encryption used to support SSL communications, as well as Single
Sign On, uses a FIPS-approved cryptographic provider.
Follow these steps to enable FIPS 1402 for the application server.
Procedure
1. Configure the application server to use FIPS.
a. Log in to the Tivoli Integrated Portal.
b. In the navigation pane, click Settings > Websphere Administrative Console
c. In the WebSphere Application Server administrative console navigation
d. Select the Use the United States Federal Information Processing Standard
(FIPS) algorithms option and click Apply. This option makes IBMJSSE2 and
IBMJCEFIPS the active providers.
e. In the Messages area at the top of the page, click the Save link and log out
of the WebSphere Application Server console.
2. Configure the application server to use FIPS algorithms for Java clients that
must access enterprise beans:
a. Open the tip_home_dir/profiles/TIPProfile/properties/ssl.client.props
file in a text editor.
b. Change the com.ibm.security.useFIPS property value from false to true.
3. Configure the application server to use FIPS algorithms for SOAP-based
administrative clients that must access enterprise beans:
a. Open the tip_home_dir/profiles/TIPProfile/properties/
soap.client.props file in a text editor.
b. Add this line:com.ibm.ssl.contextProvider=IBMJSSEFIPS.
4. Configure java.security to enable IBMJCEFIPS:
a. Open the tip_home_dir/java/jre/lib/security/java.security file in a text
editor.
b. Insert the IBMJCEFIPS provider
(com.ibm.crypto.fips.provider.IBMJCEFIPS) before the IBMJCE provider,
and also renumber the other providers in the provider list. The IBMJCEFIPS
provider must be in the java.security file provider list. See the example at
the end of this topic.
5. Enable your browser to use Transport Layer Security (TLS) 1.0:
a. Microsoft Internet Explorer: Start Internet Explorer and click Tools >
Internet Options. On the Advanced tab, select the Use TLS 1.0 option.
b. Firefox: Start Firefox and click Tools > Options. In the toolbar, click the
Advanced icon and select the Encryption tab. In the Protocols frame, select
the Use TLS 1.0 option.
6. Export Lightweight Third Party Authentication keys so applications that use
these LTPA keys can be reconfigured.
b. In the WebSphere Application Server administrative console, select Security
> Global security.
c. In the Global security page, from the Authentication area, click the LTPA
link.
d. Under Cross-cell single sign-on, specify a key file and provide a filename
and password for the file that will contain the exported LTPA keys.
e. Click Export keys. By default the exported file is saved to
7. Reconfigure any applications that use application server LTPA keys: To
reconfigure the Tivoli SSO service with the updated LTPA keys, run this script:
tip_home_dir/profiles/TIPProfile/bin/setAuthnSvcLTPAKeys.jacl.
a. Change directory to tip_home_dir/profiles/TIPProfile/bin/
b. If the application server is not running, start it using the following
command:
c. Run the following command:
wsadmin -username tipadmin -password tipadmin_password -f
setAuthnSvcLTPAKeys.jacl exported_key_path key_password
Where:
exported_key_path is name and full path to the key file that was exported.
key_password is the password that was used to export the key.
8. For SSO, enable FIPS for any other application server instances, then import the
updated LTPA keys from the first server into these servers:
a. Copy the LTPA key file from step 6 above to another application server
computer.
b. In the navigation pane, click Settings > Websphere Admin Console and
c. In the WebSphere Application Server administrative console, select Security
> Global security.
d. In the Global security page, from the Authentication area, click the LTPA
link.
e. Under Cross-cell single sign-on, provide the filename and password from
above for the file that contains the exported LTPA keys.
f. Click Import keys.
9. Run the ConfigureCLI command:
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh
ConfigureCLI --useFIPS true

tip_home_dir\profiles\TIPProfile\bin\tipcli.bat ConfigureCLI
--useFIPS true
Example
The IBM SDK tip_home_dir/java/jre/lib/security/java.security file looks like

this when IBMJCEFIPS is enabled.
security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS
security.provider.2=com.ibm.crypto.provider.IBMJCE
security.provider.3=com.ibm.jsse.IBMJSSEProvider
security.provider.4=com.ibm.jsse2.IBMJSSEProvider2
security.provider.5=com.ibm.security.jgss.IBMJGSSProvider
security.provider.6=com.ibm.security.cert.IBMCertPath
security.provider.7=com.ibm.crypto.pkcs11.provider.IBMPKCS11
security.provider.8=com.ibm.security.cmskeystore.CMSProvider
security.provider.9=com.ibm.security.jgss.mech.spnego.IBMSPNEGO
Related reference:
Federal Information Processing Standard support
Federal Information Processing Standards (FIPS) are issued by the United States
National Institute of Standards and Technology (NIST) for federal government
computer systems.
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.
Before you begin
Tivoli Integrated Portal is enabled for single sign-on.
About this task
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 >
Global 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.
What to do next
In a load balanced environment, you must set the LTPA token timeout value on
each of the Tivoli Integrated Portal Server instances.
Configuring CMS to use a remote database

The Context Menu Service (CMS) is a component of Tivoli Integrated Portal and it
can be configured to use a remote database, which can be used by product 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 UI from another application.
To configure CMS to use a remote database, you must create a database and then
create a data source within Tivoli Integrated Portal that CMS can use.
Creating a database for CMS

Copy CMS scripts from your Tivoli Integrated Portal installation to your remote
computer and create a database.
About this task
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
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.
What to do next
When you have set up a remote database, you can configure a data source in Tivoli
Integrated Portal that CMS can use.
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.
About this task
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
Creating a data source for a remote database

Create a CMS datasource on your Tivoli Integrated Portal instance that a remote
database can use.
About this task
To create a data source:
Procedure
1. On the computer running Tivoli Integrated Portal, at the command line, create
a new directory:
For example, mkdir tip_home_dir/profiles/TIPProfile/bin/cms/demo
2. Extract the relevant database_type_scripts file from the CMS directory to the
new directory.
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
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
For example, if the new directory is located in the CMS directory, run
the following command:
$ tar -xf ../db2_scripts.tar
3. Change directory to the extracted the database_type directory (for example,
db2) that is created in the directory that you created in 1.
For example, cd db2/
4. Open the CMS_database_type_DataSource.txt file, for example,
CMS_DB2_DataSource.txt, in a text editor.
This file provides instructions on how to set up the data source.
5. Change to directory to the location of the wsadmin command.
For example, cd tip_home_dir/profiles/TIPProfile/bin.
6. Run the wsadmin command to create the datasource.
Tip: Use the example in the CMS_database_type_DataSource.txt file to assist

you with the command syntax.
The following is an extract from CMS_DB2_DataSource.txt:

./wsadmin.sh -lang jython -user tip_user_name -password
tip_user_password -f path_to_createCMSDataSource_TIP.py
tip_home_dir/universalDriver/lib/db2jcc.jar:tip_home_dir/
universalDriver/lib/db2jcc_license_cu.jar database_user_name
database_user_password database_name database_hostname
database_port_number
wsadmin.bat -lang jython -user tip_user_name -password
tip_user_password -f path_to_createCMSDataSource_TIP.py
tip_home_dir\universalDriver\lib\db2jcc.jar;tip_home_dir\
universalDriver\lib\db2jcc_license_cu.jar database_user_name
database_user_password database_name database_hostname
Where:
jython The script language type.
tip_user_name
The Tivoli Integrated Portal administrator user name.
tip_user_password
The Tivoli Integrated Portal administrator user password.
path_to_createCMSDataSource_TIP.py
The file path and name of the createCMSDataSource_TIP.py. For
example, in Linux ./cms/demo/db2/createCMSDataSource_TIP.py.
tip_home_dir/universalDriver/lib/db2jcc.jar;tip_home_dir/universalDriver/lib/
db2jcc_license_cu.jar
The file path and name of the database Jar file and license Jar file.
Note: The file paths should be separated by a : on Linux systems and

by a ; on Windows systems.
database_user_name
The database user name that you used when you created, or specified
the database.
database_user_password
The password associated with the database user name.
database_name
The database name that you created, or specified.
database_hostname
The database hostname or IP address.
The port number that allows you to communicate with the database.
For example, the default DB2 database port number is 50000.
The data source in Tivoli Integrated Portal is configured.
What to do next
When you have configured the data source in Tivoli Integrated Portal, you can
configure the hostname.
Removing a data source

If required you can remove an existing 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
Results
The specified data source is removed.
Configuring a hostname to be used by CMS

Configure a hostname to be used by CMS.
About this task
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
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


What to do next
When you have configured the hostname, you can set up logging for CMS.
Configuring logging for CMS

Configure a logging for CMS.
About this task
To configure logging for CMS:
Procedure
click Troubleshooting > Logs and Trace.
4. In the Logging and Tracing page, select the Tivoli Integrated Portal Server
(server1).
5. In the General Properties area, select the Change Log Detail Levels link.
6. Under the text panel, expand the All components link.
7. Scroll down and expand the com.ibm.isclite.* entry and then expand the
com.ibm.isclite.service.* entry.
8. Under the com.ibm.isclite.service.* entry, expand the
com.ibm.isclite.service.datastore* entry and click on the
com.ibm.isclite.service.datastore.contextmenu.* entry.
9. From the menu that is displayed, select All Messages and Traces.
10. Scroll to the top of the page and confirm that the text panel includes the
following entry:
*=info:com.ibm.isclite.service.datastore.contextmenu.*=all
11. Click OK and in the Logging and Tracing page, in the Message panel, click
Save.
Logging is now enabled for CMS.
12. Log out of the Websphere Administrative Console and close it.
13. Log out of the Tivoli Integrated Portal and close it.

What to do next
When you have configured the logging for CMS, you verify your configuration.
Verifying your CMS configuration

Verify your CMS configuration.
About this task
To verify your CMS configuration:
Procedure
tip_home_dir/profiles/TIPProfile/logs/server1
2. Open the trace.log in a text editor and search for the following string:
local updates to database You should find an entry in the log file similar to
the following, which indicates that you have correctly configured CMS with the
remote database.
00000020 CMSSynchroniz 1
CMSSynchronizer.localXMLUpdatesAvailable()-----------> Initializing,
sending local updates to database!!!
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

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.
Before you begin
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
About this task
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.
About this task
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.
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 <display-name>ITMWebServiceEAR</display-name> to
<display-name>ITMWebService2EAR</display-name>.
d. Change the name <context-root>ITMWebService</context-root> to
<context-root>ITMWebService2</context-root>.
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.
Related tasks:
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.
About this task
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
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.

About this task
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 2. 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.
[--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 3. ChartImport command arguments
--dir source_directory Mandatory parameter. The directory where
the data to imported is located. BIRT
Designer file format is .rptdesign.
chartCreator role.
Table 3. ChartImport command arguments (continued)
Configuring SSO between Charting and Tivoli Monitoring

Before you begin

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).
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.
About this task
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 communication with Tivoli Monitoring:
tipcli.bat ITMLogin -hostname <TEPS_hostname> -port 15200

tipcli.sh 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 enterr the user ID and user name.
To be consistent, you can use the same user ID as in Tivoli Integrated
Portal.
d. Enter the distinguised 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 he 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.
Related tasks:
Configuring single sign-on on page 34
repository.
Configuring an external LDAP repository on page 27
You can configure the Tivoli Integrated Portal Server to communicate with an
external LDAP repository.
Managing LDAP users in the console on page 29
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.

Chapter 6. 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
Before you begin
The Tivoli Integrated Portal Server must be running before you can connect to it
from your browser.
About this task
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://<host>:<port>/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.
What to do next
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.
Related concepts:
Login errors on page 146
Anything from an unassigned user role to a loss of connectivity with the user
repository can cause a login error. Read the TIPProfile logs for help in diagnosing
the cause.
Related tasks:
other information.
Configuring access for HTTP and HTTPS on page 69
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.
System user roles in Tivoli Integrated Portal

application server provides a number of system roles by default.
The main administrator (that is, user ID called tipadmin) of the application server
already has the chartAdministrator and the iscadmins roles, 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 system roles and their capabilities:
iscusers
iscusers is set to All Authenticated users. All users have this role by default.
Users belonging to this role have access to the Welcome page and
Credential Store portlets.
operator
Legacy role with no special privileges.

monitor
configurator
administrator
iscadmins
This is the super user and has administrative access to all pages and
portlets defined in Tivoli Integrated Portal.
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.
Stopping and starting the application server

About this task
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

Chapter 6. Administering 91
Related tasks:
Setting a trace on page 153
Enable a trace of the Tivoli Integrated Portal Server when you want to keep a
record of activity.
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.
Related tasks:
Viewing the application server profile
other information.
Related reference:
Port number settings in WebSphere Application Server versions
Many port values in Tivoli Integrated Portal are different.
Viewing the application server profile

other information.
About this task
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

What to do next
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:
#Create the required WAS port properties for TIP
#Mon Oct 06 09:26:30 PDT 2008
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=16323
WC_adminhost=16315
DCS_UNICAST_ADDRESS=16318
BOOTSTRAP_ADDRESS=16312
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=16321
SOAP_CONNECTOR_ADDRESS=16313
ORB_LISTENER_ADDRESS=16320
WC_defaulthost_secure=16311
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=16322
WC_defaulthost=16310
WC_adminhost_secure=16316
Related concepts:
Related tasks:
Viewing TIPProfile logs for login errors on page 147
In the event of a login error, review the system outage and system error logs to
help determine the cause.
Related reference:
Port number settings in WebSphere Application Server versions
Many port values in Tivoli Integrated Portal are different.
Changing passwords
About this task
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.
Related tasks:
Configuring an SSL connection to an LDAP server on page 30
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:
If it is set to True, then only load balancing information is imported, that is,
no transformation data.
If it is set to False, then only transformation data is imported, that is, no load
balancing data.
If it is set to Both, then transformation data and load balancing data is
imported.
Related reference:
tipcli - Export plugins on page 130
Import tipcli commands on page 134
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.
Before you begin
Ensure that the Tivoli Integrated Portal Server is running.
About this task
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-SPSVS-
com.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:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat ExportPage
--uniqueName pageID_1,pageID_2,pageID_3 --username tipadmin_user_name
--password tipadmin_password
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/.
What to do next
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.

Before you begin
About this task
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
following command:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat ListViews
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:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat ExportView
--uniqueName viewID_1, viewID_2, viewID_3
ExportView --uniqueName viewID_1, viewID_2, viewID_3

Results

What to do next

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.
Before you begin
About this task
To export console preference profiles in simplified mode:
Procedure
2. Optional: To return a list of console preference profiles that can be exported:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat
ListPreferenceProfiles
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:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat ExportProfile
--uniqueName profile_ID1,profile_ID2,profile_ID3
ExportProfile --uniqueName profile_ID1,profile_ID2,profile_ID3

Results

What to do next

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.
Before you begin
About this task
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:
ListExportPlugins
ListExportPlugins
3. To export all customization data, run the following command:
v tip_home_dir/profiles/TIPProfile/bin/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.
What to do next

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.
Before you begin
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.
About this task
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:
--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.
What to do next
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.
Before you begin
About this task
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:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat ListPages
--customizePages true
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-SPSVS-
com.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:
--username tipadmin_user_name --password tipadmin_password --pages
pageID_1, pageID_2, pageID_3
--username tipadmin_user_name --password tipadmin_password --pages
pageID_1, pageID_2, pageID_3
Results

What to do next

Exporting specific views

When exporting Tivoli Integrated Portal data, you can specify that you want to
export particular views.
Before you begin
About this task
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
following command:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat ListViews
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:
--username tipadmin_user_name --password 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

What to do next

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.
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.
Before you begin
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
About this task
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
v tip_home_dir/profiles/TIPProfile/bin/tipcli.bat
ListImportPlugins
3. To import the customization data, run the following command:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat Import
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh Import
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.
Before you begin
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.
About this task
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
v tip_home_dir/profiles/TIPProfile/bin/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

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 4. 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
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.
Before you begin
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.
About this task
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.
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.

Related concepts:
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.
About this task
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:
<non-root user home directory>/.asci_<user_name>

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
v For Linux and UNIX-based systems, the path to the bin
directory varies depending on whether you are installing as root or as a
non-root user, as follows:
For a non-root user, change to the bin child directory, that is:
<non-root user home directory>/.asci_<user_name>/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
What to do next
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.
Related tasks:
Running the installer in an existing environment on page 13
System Cloning Solution

Use the System Cloning Solution (SCS) to clone instances of Tivoli Integrated
Portal Server.
Both the source Tivoli Integrated Portal Server and the target Tivoli Integrated
Portal Server instance must be similarly configured in these areas:
v Same version and fix level this may require the application of service to the
target Tivoli Integrated Portal Server to ensure it has the same fixes as the source
Tivoli Integrated Portal Server. This must be completed before proceeding.
v Same Tivoli Integrated Portal administrator user and password
v Same product modules deployed
The default authentication mechanism for Tivoli Integrated Portal is a local file
based user repository, in this case, cloning a server instance also exports the local
file based repository.

Important: The Tivoli Integrated Portal Server instance must not be configured for
load balancing. The cloning process exports data for a local server instance only.
Data stored in a database (as required for load balancing) can not be reliably
exported.
Cloning a server instance copies the following types of resources from the source
system to the target system:
v page definitions
v view definitions
v portlet entities
v user preferences and defaults
v chart definitions
These resources might have been defined by modules deployed on the system or
created manually by administrators.
Authorization in Tivoli Integrated Portal consists of user to role mappings and role
to resource mappings. Cloning a Tivoli Integrated Portal Server instance copies
both types of mappings to the target system.
Tivoli Common Reporting is provided as part of the Tivoli Integrated Portal. Tivoli
Common Reporting report artifacts are included in the export/import of a server
instance as they are present in the set of cloned files. However, Tivoli Common
Reporting stores additional information in the database used by eWAS, as does the
Tivoli Scheduling Service. SCS uses explicit commands to export and import Tivoli
Common Reporting data and Tivoli Scheduling Service data from the database so
that the necessary information is cloned as well as the files.
Running SCS to export data

Use the System Cloning Solution (SCS) to export instances of the Tivoli Integrated
Portal Server. Exported settings can be later applied to another server instance at
the same version level with the same products deployed.
About this task
To export settings for a Tivoli Integrated Portal Server instance:
Procedure
TIPProfile/bin directory. The tip_home_dir directory defaults to
C:\IBM\tivoli\tipv2 on Windows and /opt/IBM/tivoli/tipv2 on UNIX/Linux
2. Run the following command:
ws_ant.bat|sh -f tipExportImport.xml export -DarchiveDir=dir
-DtipAdmin=tipadmin -DtipPassword=tippass
The export argument results in the script copying all required data from the
TIPProfile profile into the directory specified by dir in the archiveDir option.
Note: To avoid the accidental loss of existing user data, the export script fails if
the specified archive directory exists. Please specify a nonexistent directory for
the archiveDir option.
Replace tipadmin with the Tivoli Integrated Portal administrator ID and
tippass with the Tivoli Integrated Portal administrator password.

Run the command with the export argument on the source Tivoli Integrated
Portal Server server.
Running SCS to import data

Use the System Cloning Solution (SCS) to import settings to a target Tivoli
Integrated Portal Server instance. The target server instance must have the same
configuration as the server instance from which the settings were sourced.
Before you begin
The Tivoli Integrated Portal cloning procedure does not automatically perform a
backup of the target system in a cloning import operation. It is recommended that
you export the target system as a backup operation.
This is accomplished by running the System Cloning Solution export option on the
target server before running the import of the data exported from the source
system. If the import fails, the backup archive can be imported to restore the
system to its original state.
About this task
Important: The target server instance should not be configured for load balancing.
The cloning process imports data for a local server instance only.
To import settings for a Tivoli Integrated Portal Server instance:
Procedure
TIPProfile/bin directory. The tip_home_dir directory defaults to
C:\IBM\tivoli\tipv2 on Windows and /opt/IBM/tivoli/tipv2 on UNIX/Linux
2. Run the following command:
ws_ant.bat|sh -f tipExportImport.xml import -DarchiveDir=dir
-DtipAdmin=tipadmin -DtipPassword=tippass -DexcludesFile=TBSM_HOME/etc/
cloneExcludesFile
The import argument is used to import data from an existing archive directory,
specified by replacing dir in the archiveDir option, which overwrites the Tivoli
Integrated Portal Server instance to complete the cloning. Run the command
with the import argument on the target Tivoli Integrated Portal Server instance.
Replace tipadmin with the Tivoli Integrated Portal administrator ID and
tippass with the Tivoli Integrated Portal administrator password. They must
have the same values as the source Tivoli Integrated Portal Server instance.
The excludesFile option must be provided and must point to the file specified
above. This file is provided with TBSM 4.2.1 Fix Pack 1 and is located in
TBSM_HOME/etc. Replace TBSM_HOME with the TBSM install directory for your
server. The default for Windows is C:\IBM\tivoli\tbsm and
/opt/IBM/Tivoli/tbsm for UNIX and Linux operating systems. This file gives
TBSM the flexibility to exclude some configuration files from being imported
by the utility.
Setting Java Virtual Machine memory for TIPProfile

You can increase the amount of memory available to the Tivoli Integrated Portal.

About this task
To increase (or decrease) the amount of memory available to the Java Virtual
Machine (JVM), carry out the following steps:
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.
Related tasks:
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://<SystemName>:16310) to the appropriate Tivoli
Integrated Portal non-secure access (for example, http://<HostnameValue>:16315)/
ibm/console), which is then converted to the Tivoli Integrated Portal secure access
(for example, https://<HostnameValue>:16316/ibm/console/login.jsp).
About this task
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.
Related tasks:
Editing a properties file on page 152
Properties files describe the environment and their settings are usually predefined
or added during installation. You do not need to change these files unless
instructed by IBM Software Support.
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.
About this task

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
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 <TIPusername> --password <passwordForUser>
--profileName <profileName> [--newProfileName <newProfileName>] [--themeDir <th
emeDir>] [--showNavTree <true|false>] [--componentDir <default|ltr|rtl>] [--text
Dir <default|contextual|ltr|rtl>] [--views <viewList>] [--roles <roleList>] [--d
efaultView <defaultView>]
where
<TIPusername> is the username on TIP that has iscadmins role.
<passwordForUser> is the password for the user.
<profileName> is profile name which will be created or updated.
<newProfileName> is the new name for the existing preference profile.
<themeDir> is the directory name of the installed theme. Example: TIPLight
<showNavTree> specify if show navigation tree by default after login the conso
le.
<componentDir> specify component direction for the console.
<textDir> specify text direction for the console.
<viewList> is views assignment for the preference profile.
<roleList> is roles assignment for the preference profile.
<defaultView> 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 the following

command:
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
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

command:
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
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

command:
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
v tipcli.bat DelRole --username tip_username --password
Where:
ID.
role_name is the name of the role to be modified.
Note: Arguments to the rolesList parameter must not include spaces.
Example

command:
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

command:
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.
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

command:
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToGroup --username

tip_username --password tip_user_password --groupID group_ID --rolesList
role_name1, role__name2
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 tip_username
role__name2
v tipcli.bat RemoveRolesFromGroup --username tip_username
role__name2
Where:
ID.
to list.
associated with the specified user group.
include spaces.
Example

command:
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

command:
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.
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.
include spaces.
Example

command:

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
v tipcli.bat RemoveRolesFromPage --username tip_username
Where:
ID.
page_unique_name is the page ID associated with the roles that you want to
remove.
disassociated with the page.
include spaces.
Example

command:
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

command:
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
v tipcli.bat MapRolesToPortletEntity --username tip_username
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
accessLevelList.
include spaces.
Example

command:
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToPortletEntity

--portletEntityUniqueName portlet_entity_unique_name --rolesList
RemoveRolesFromPortletEntity
Use the RemoveRolesFromPortletEntity command to disassociate a
comma-separated list of roles with a specified portlet.
Syntax

v tipcli.sh RemoveRolesFromPortletEntity --username
tip_username --password tip_user_password --portletEntityUniqueName
v tipcli.bat RemoveRolesFromPortletEntity --username tip_username
Where:
ID.
portlet_entity_unique_name is the portlet ID associated with the roles that you
want to remove.
disassociated with the portlet.
include spaces.
Example

command:
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh RemoveRolesFromPortletEntity
--portletEntityUniqueName portlet_entity_unique_name --rolesList
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

command:
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesFromUser --username

tip_username --password tip_user_password --userID user_ID
MapRolesToUser
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 role_name1,
role__name2
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.
include spaces.
Example

command:
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToUser --username

tip_username --password tip_user_password --userID user_ID --rolesList
RemoveRolesFromUser
Use the RemoveRolesFromUser command to disassociate a comma-separated list of
roles with a specified user ID.

Syntax

v tipcli.sh RemoveRolesFromUser --username tip_username
role__name2
v tipcli.bat RemoveRolesFromUser --username tip_username
role__name2
Where:
ID.
portlet_entity_unique_name is the user ID associated with the roles that you want
to remove.
include spaces.
Example

command:
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

command:
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

v tipcli.sh MapRolesToView --username tip_username
--password tip_user_password --viewUniqueName view_name --rolesList
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 user.
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
accessLevelList.
include spaces.
Example

command:
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToView --username

tip_username --password tip_user_password --viewUniqueName view_name
RemoveRolesFromView
Use the RemoveRolesFromView command to disassociate a comma-separated list of
roles with a specified view.
Syntax

v tipcli.sh RemoveRolesFromView --username tip_username

v tipcli.bat RemoveRolesFromView --username tip_username
Where:
ID.
view_name is the unique view name associated with the roles that you want to
remove.
include spaces.
Example

command:
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.

Linux or UNIX.
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.
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 5. 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.

Table 5. AddUpdatePreferenceProfile command arguments (continued)
[--showNavTree true|false] Optional parameter. Used to specify whether
or not you want the navigation pane to be
displayed for preference profile.
[--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.

Linux or UNIX.
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.
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.

Linux or UNIX.
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 6. 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.
--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.
chartCreator role.
ChartImport --dir source_directory --username tip_username --password

tip_user_password
ChartImport is used to import chart data from a specified directory.
Table 7. ChartImport command arguments
--dir source_directory Mandatory parameter. The directory where
the data to be imported is located. BIRT
Designer file format is .rptdesign.
chartCreator role.
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 8. 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.

Table 8. ChartProperties command arguments (continued)
user with the chartAdministrator role.
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 9. 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

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 10. 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
Related concepts:
Exporting and importing on page 94
exported data.
Related tasks:
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]
[--includeMytasks true|false] [--includeMyStartupPages true|false]
[--includeTransformations true|false] --username tip_username --password
tip_user_password
Table 11. 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.

Table 11. ExportPagePlugin command arguments (continued)
[--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.
[--includeCustomData true|false] Optional parameter. The default value is
true. If is set to false, no customization
data is exported.
[--includeCredentialData true|false] Optional parameter. The default value is
true. If is set to false, 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 12. 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.
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
tip_user_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 13. 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.

Table 13. Import command arguments (continued)
user with the iscadmin role.
Related concepts:
Exporting and importing on page 94
exported data.
ImportPagePlugin tipcli command

Use the ImportPagePlugin tipcli command to import previously exported Tivoli
Integrated Portal data.
Note: If you specify additional parameters for the tipcli.bat|.sh Import and
Import [--importFile import_file] [--rollback ALL] [--haSupport
both|true|false] --username tip_username --password tip_user_password
Example command: tipcli.bat Import --importFile
c:/tmp/extest.zip --username sampleuser --password samplepassword
In this example, extest.zip, which is the output an ExportPagePlugin
operation, is imported into the target Tivoli Integrated Portal instance.
Table 14. ImportPagePlugin command arguments
[--importFile import_file] Optional parameter. Specifies the path and
file name for the data to be imported, for
example, c:/tmp/extest.zip.
[--rollback ALL] Optional parameter. Use the rollback
parameter if you want to restore a Tivoli
Integrated Portal environment to its
pre-import state. You can only roll back an
import if you have made no changes to the
environment since you performed the
import.
[--haSupport both|true|false] Optional parameter. You can set this
parameter to both, true, or false. The
setting indicates whether to include load
balancing data, the default value is both. If
you set it to false, only non-load balancing
data is imported, that is, transformations. If
is set to true, only load balancing base data
is imported. When it is set to both, both
types of data are imported. This parameter
can also be used in non-load balanced
environments. If is set to true, only base
data is imported. If you set it to false, only
non-base data is imported, that is,
transformations.

Context Menu Service tipcli commands
tipcli commands for working with the Context Menu Service (CMS).
Exporting CMS data
There are two menu element types available in cms.xml:

System menu
Menus generated by deploying an application are called system menus.
Custom menu
Menus added through a Representational State Transfer (REST) service are
called custom menus. The export function migrates only custom launch
entries from cms.xml.
Exported CMS data includes two files:

cms.xml
This file when exported, contains all the custom launch entry details from
the original cms.xml. The exported cms.xml is formatted slightly different
from the original cms.xml in order for it to be imported more easily.
navigation.xml
Some details for launch entries are stored in navigation.xml, for example,
wscRole, wscRoleType, and launchType. The exported navigation.xml
contains only details from the original navigation.xml that relate to the
custom launch entries exported in cms.xml
CMS export command
CMSExport --dir export_directory
where export_directory is the location where you want the output files to be
saved.
For example:
tip_home_dir\profiles\TIPProfile\bin\tipcli.bat CMSExport --dir

C:\cms_ei
Once the command completes, a file called cms.zip is created in the

export_directory that you specified. cms.zip contains all the exported CMS data,
which can be subsequently imported to another instance of Tivoli Integrated Portal.
Importing CMS data
Exported CMS data can be subsequently imported to another Tivoli Integrated Portal
instance.
CMS import command
CMSImport --username tip_username --password tip_user_password --dir

import_directory
Where:

v --dir import_directory specifies the directory that contains the cms.zip file that
was copied from the export_directory on the source Tivoli Integrated Portal
instance.
Note: If you omit the --dir argument from the command, you can provide the
export_directory path in interactive mode.
v --username tip_username --password tip_user_password specifies a valid
username and password for theTivoli Integrated Portal instance.
Note: If you omit the --username and --username arguments from the
command, you must provide the tip_username and tip_user_password in
interactive mode.
For example:
tip_home_dir\profiles\TIPProfile\bin\tipcli CMSImport --dir

C:\cms_ei
Once the command completes, CMS data is imported into the Tivoli Integrated
Portal environment and the relevant menus are updated.
Importing using a properties file
You can also optionally use a --settingsFile settings_file properties file with
the CMSImport command to create a CMS datasource and update
consoleProperties.xml.
Additional commands
Additional tipcli commands.
cmsUpdateRemoteEntries [--username username --password password] (-toremote
| -fromremote | -deleteremote) [-force]
Save system information in the file specified.
Table 15. 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.

Table 15. cmsUpdateRemoteEntries command arguments (continued)
-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
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.

Chapter 7. Troubleshooting
Consult these troubleshooting notes to help determine the cause of the problem
and what to do about it.
Installation errors
Related concepts:
Memory needed on Linux for zSeries on page 7
In preparing for a Tivoli Integrated Portal installation on Linux for zSeries, make
sure that the temporary directory has at least 500 MB of space available.
Harmless installation messages

A review of the installation log might show error messages that are actually
harmless.
After installing Tivoli Integrated Portal, you might encounter a reflection error when
reviewing the installation logs. The installation is successful, but the log shows
variations of this error:
+++ Warning +++: IWAV0003E Could not reflect methods for com.ibm.sec.iauthz.
InstanceAuthzServiceLocalHome because one of the methods references a type that
could not be loaded.
Exception: java.lang.NoClassDefFoundError: com.ibm.sec.iauthz.InstanceAuthorization
+++ Warning +++: IWAV0002E Failed reflecting values
+++ Warning +++: java.lang.NoClassDefFoundError: com.ibm.sec.
iauthz.InstanceAuthorization
This error can be safely ignored.
Insufficient disk space for install

Have enough space in the temporary directory for the installation or it will fail.
Your product installation requires at least 500 MB of disk space for the temporary
files that are used during installation. On Linux and UNIX, allocate enough space
in the /tmp or /opt directory of the computer.
TIPProfile_create log
Review the TIPProfile_create log when your installation ends in error.
Purpose
The TIPProfile_create log records the messages that result from the successful or
failed completion of a task in the process of creating the Tivoli Integrated Portal
profile during installation.
Sample
This is a sample of the final records of a TIPProfile_create.log where errors were

encountered.

<record>
<date>2008-05-19T01:20:43</date>
<millis>1211185243859</millis>
<sequence>1007</sequence>
<logger>com.ibm.ws.profile.cli.WSProfileCLIModeInvoker</logger>
<level>INFO</level>
<class>com.ibm.ws.profile.cli.WSProfileCLIModeInvoker</class>
<method>areCommandLineArgumentsValid</method>
<thread>10</thread>
<message>Validation Error for profilePath: The profile path is not valid.
</message>
</record>
<record>
<date>2008-05-19T01:20:43</date>
<level>SEVERE</level>
<method>invokeWSProfile</method>
<thread>10</thread>
<message>Argument Validation Failed.</message>
</record>
<record>
<date>2008-05-19T01:20:43</date>
<level>INFO</level>
<thread>10</thread>
<message>Returning with return code: INSTCONFFAILED</message>
</record>
<record>
<date>2008-05-19T01:20:43</date>
<logger>com.ibm.wsspi.profile.WSProfileCLI</logger>
<level>INFO</level>
<class>com.ibm.wsspi.profile.WSProfileCLI</class>
<thread>10</thread>
<message>Returning with return code: INSTCONFFAILED</message>
</record>
Installation failure scenario

Review the IA-TIPInstall-xx.log for any errors that might have occurred during
installation.
IA-TIPInstall-xx.log
Typically, the installation process stops when a failure occurs. But it can also
appear to complete successfully and then later, such as when attempting to log in,
you find that there is a problem. Review the IA-TIPInstall-xx.log in your home
directory to confirm that the installation was successful. For example, if you are
logged in as Administrator on a Windows system, then you would look in
C:\Documents and Settings\Administrator.

Log review scenario
In this example on a Windows system, the ESSServerConfig.xml step failed and

IA-TIPInstall-xx.log as shown here appears to have a COI (Composite Offering
Installer) failure at line 134.
C:\IBM\tivoli\tip\_uninst\ITNM\plan\install\MachinePlan_localhost\
0011_IAGLOBAL_COI_STEP_ESSServerConfig\IAGLOBAL_COI_STEP_ESSServerConfig.xml:134:
xec returned: 105
Wed May 28 15:25:54.078 EDT 2008 : STDERR :
at org.apache.tools.ant.ProjectHelper.
addLocationToBuildException(ProjectHelper.java:539)
at org.apache.tools.ant.taskdefs.Ant.
execute(Ant.java:384)
at org.apache.tools.ant.Task.perform
(Task.java:364)
at com.ibm.ac.coi.impl.utils.
AntHelper.ant(AntHelper.java:88)
Wed May 28 15:25:54.078 EDT 2008 : STDERR : ... 3 more
The log provides you with the full path to the location of the failing file. Navigate
to that location, open the file indicated, and check the line that failed. In this
example you would navigate to:
C:\IBM\tivoli\tip\_uninst\ITNM\plan\install\MachinePlan_localhost\
00011_IAGLOBAL_COI_STEP_ESSServerConfig\IAGLOBAL_COI_STEP_ESSServerConfig.xml
and study line 134. At line 134 of target configureESS, the following command did
not execute successfully
<target name="configureESS" depends="setProperties">
<echo message="Start to configure Authentication Service..."/>
<iaecho message="$ESSSERVER_CONFIGURING$"/>
......................
line134: <exec
dir="${IAGLOBAL_installLocation}/bin"
executable="${IAGLOBAL_installLocation}/bin/wsadmin${platform.script.ext}"
failonerror="true">
<redirector output="${IAGLOBAL_installLocation}/logs/
ESSConfiguration.out" error="${IAGLOBAL_installLocation}/logs
/ESSConfiguration.err"/>
...
As you can see, the wsadmin call from Ant sends stdout to tip_home_dir/logs/
ESSConfiguration.out and stderr to tip_home_dir/logs/ESSConfiguration.err. A
review of the ESSConfiguration.out file shows that the Tivoli Integrated Portal
Server (WAS) might have a problem:
WASX7209I: Connected to process "server1" on node TIPNode using SOAP connector;
The type of process is: UnManagedProcess
WASX7303I: The following options are passed to the scripting environment and
are available as arguments that are stored in the argv variable:
"[C:/IBM/tivoli/tip/logs/ltpaOutput.txt, 1ntegrate]"
WASX7017E: Exception received while running file "C:\IBM\tivoli\tip\bin
\configureESS.jacl";
exception information: com.ibm.bsf.BSFException: error while evaling
Jacl expression:
no accessible method "isESSConfigured" in class
com.ibm.ws.scripting.adminCommand.AdminTask
while executing
"$AdminTask isESSConfigured"
invoked from within
"set essCheck [$AdminTask isESSConfigured]"
Chapter 7. Troubleshooting 141

Check the tip_home_dir/profiles/TIPProfile/logs/server1/SystemOut.log for
any exceptions that might be related to the Authentication Service. If you are not
able to assess this, ask the resident Tivoli Integrated Portal Server expert or gather
the Tivoli Integrated Portal logs, including SystemOut.log, and contact IBM Support.
Related reference:
Log files
Log files
Here are the logs created during a Tivoli Integrated Portal installation. The installer
creates a log called IA-TIPInstall-xx.log, which is located in the user's home
directory. This should be the first log reviewed. It shows the installation as it
progresses, giving tracing information. Each step that is executed in the installation
creates a log in the tip_home_dir/logs directory.
Administrative console
createProfile.err
createProfile.out
createTIPService.err
createTIPService.out
deleteProfile.err (uninstall)
deleteProfile.out
enableAppSecurity.err
enableAppSecurity.out
extendJaveMemory.err
extendJaveMemory.out
modifyWASServiceName.err
modifyWASServiceName.out
removeTIPService.err (uninstall)
removeTIPService.out
Common Gateway Interface Server
CGIServer.err
CGIServer.out
configureIAuthzShLib.err
configureIAuthzShLib.out
deployiAuthzEar.err
deployiAuthzEar.out
Enterprise Storage Server
deployESSApplication.err
deployESSApplication.out
ESSConfiguration.err
ESSConfiguration.out
osgiCfgInit.err
osgiCfgInit.out
IBM Tivoli Monitoring Web Service
ITMWebServiceEAR.err
ITMWebServiceEAR.out
Load Balancing
createTipDataSource.err
createTipDataSource.out
HADBInstall.err
HADBInstall.out
HADBJoin.err
HADBJoin.out

Charting
assignChartAdminRole.err
assignChartAdminRole.out
TIPChartPortlet.err
TIPChartPortlet.out
Reporting Time Scheduling Services
TipTssEar.err
TipTssEar.out
TipTssEWASScheduler.err
TipTssEWASScheduler.out
TipTssJDBC.err
TipTssJDBC.out
TipTssSharedLibraries.err
TipTssSharedLibraries.out
Tivoli Common Reporting
tcr.err
tcr.out
tcrConfigClient.err
tcrConfigClient.out
tcrsPostConfig.err
tcrsPostConfig.out
configureTIPTransformationShLib.err
configureTIPTransformationShLib.out
deployTIPChangePassdWar.err
deployTIPChangePassdWar.out
deployTIPRedirectorEar.err
deployTIPRedirectorEar.out
renameIdMgrRealm.err
renameIdMgrRealm.out
Virtual Member Manager
VMM.err
VMM.out
VMM LDAP Configuration
configureVMMLDAP.err
configureVMMLDAP.out
VMM ObjectServer Plugin
VMMObjectServerPlugin.err
VMMObjectServerPlugin.out
WebSphere
checkWAS.err
checkWAS.out
startWAS.err
startWAS.out
Related reference:
Installation failure scenario on page 140
Review the IA-TIPInstall-xx.log for any errors that might have occurred during
installation.
Install fails after deployment engine upgrade

Running the installer on a computer that has an existing Tivoli Integrated Portal
environment can fail if the deployment engine (DE) was upgraded from a very
early version.
If you have an old version of the DE installed, the Tivoli Integrated Portal installer
will upgrade it and continue with the installation. On rare occasions certain older
versions of the DE might not be upgraded successfully. When this happens, the

installation can fail. If you are aware that your product uses a very old version of
the DE (such as Version 1.2), you can install on the same machine, but sign on to
the portal with a different user name. If your old version of the DE was initially
installed as root user on the Linux or UNIX operating system, consider uninstalling
it if your new installation is failing after the DE upgrade.
Installation fails on a HP Integrity server

To install Tivoli Integrated Portal on a HP Integrity server (ia64) running HP-UX,
you must comment out a variable in the install.sh file.
If you install Tivoli Integrated Portal on a HP Integrity server (ia64) running HP-UX,
you will see the following error in the installation log:
Install.sh can not be launch because ERROR: The /usr/user_name
/cdimage/COI/PackageSteps/eWAS/FILES/eWAS-HPUXIA32-7.0.0.7.zip
must present on this media
To be able to install Tivoli Integrated Portal in this situation you must open a copy
of the file install.sh, which was delivered with your installation media, in a text
editor.
You must comment out the validateMedia ${defaultEWASFile} element and re-run
the installation.
Installation fails on Windows Server 2008

If you add a non-admin user to the Administrators group in Windows Server 2008,
you must disable the User Account Control setting for that user in order to install
Tivoli Integrated Portal.
You can disable the User Account Control setting for a user, as follows:
1. Log on to the Windows Server 2008 computer as an administrator.
2. In the Control Panel, click User Accounts and Family Safety.
3. Click User Accounts.
4. Click Turn User Account Control on or off.
5. If User Account Control is currently configured in Admin Approval Mode, a
User Account Control message is displayed. Click Continue.
6. Clear the Use User Account Control (UAC) to help protect your computer
check box, and then click OK.
7. Restart the server to commit your changes.
You can now re-run the Tivoli Integrated Portal installation using the updated user's
account.
Preupgrade steps fails on HP Itanium (ia64) systems

The Tivoli Integrated Portal preupgrade step may fail on HP Itanium (ia64) systems
running UNIX, whereby the systems appears to lock up or hang.
About this task
This problems relates to the Deployment Engine listIU command failing during
the preupgrade step. If the preupgrade step fails and your systems locks up, you
can stop and restart the Tivoli Integrated Portal Server and try again:

Procedure
1. In the tip_home_dir/profiles/TIPProfile/bin directory, the following
command:
stopServer.sh server1
Note: You are prompted to provide an administrator username and password.

2. In the tip_home_dir/profiles/TIPProfile/bin directory, enter the following
command:
startServer.sh server1
Results
The Tivoli Integrated Portal Server and you can try to run the preupgrade step
again.
Note: If your system locks up when you run the Deployment Engine listIU
command independently of the preupgrade step, you can also restart the Tivoli
Integrated Portal Server and try it again.
Related tasks:
Setting the libstdc++ level for Linux systems

The Deployment Engine component does not support libstdc++.so.6 or higher on
Linux systems.
About this task
Your Tivoli Integrated Portal installation may fail on Linux systems if the libstdc++
level is at /usr/lib/libstdc++.so.6 or higher. You must install the
compat-libstdc+-33 packages to successfully install Tivoli Integrated Portal:
Procedure
1. On 32 bit and 64 bit systems, run the following command:
$yum install compat-libstdc++-33.i686
2. On 64 bit systems, you must also run the following command:
$yum install compat-libstdc++-33.x86_64
3. When the command completes, check that the /usr/lib directory for the
presence of libstdc++.so.5.0.7 and that a symbolic link from libstdc++.so.5
to libstdc++.so.5.xx.xx is created.

Related concepts:
Installation fails with error code ADMR0104E in SystemOut.log

An installation will fail if a file is created in, or manually added to, a specific
WebSphere Application Server configuration directory. An error with the code
ADMR0104E is written to SystemOut.log, which provides details for file that caused
the problem.
An installation will fail if a file was created in, or manually added to the following
directory, and if the new file's access permissions differ to those of the other files in
the directory:
tip_home_dir/profiles/TIPProfile/config/cells/TIPCell/applications/
isclite.ear/deployments/isclite/isclite.war/WEB-INF
In such cases, the following error is written to tip_home_dir/profiles/TIPProfile/

logs/server1/SystemOut.log:
ADMR0104E: The system is unable to read document file path:
java.io.FileNotFoundException: file path (Permission denied)
To resolve this issue you must move the file indicated in the error message from
the WebSphere Application Server configuration directory, or ensure that the file is
granted file access permissions similar to those of the other files in the directory.
Once the file is removed or has had its file access permissions updated, you must
restart the installation process.
Login errors
Anything from an unassigned user role to a loss of connectivity with the user
repository can cause a login error. Read the TIPProfile logs for help in diagnosing
the cause.
Harmless authentication messages

Certain sign-on messages are routine and might not indicate that a problem has
occurred.
For installations that have been configured to use the Tivoli Integrated Portal
authentication service, it is possible that an authentication client receives
CTGES1504E and CTGES1505E messages. These messages are generated when an
unused single sign-on LTPA token is discarded, and might be insignificant.
An authentication client attempts to use all single sign-on tokens provided to it

when authenticating to an authentication service. Some of these tokens might not
apply to the configured authentication service, causing CTGES1504E and
CTGES1505E messages to be generated on the client and CTGES1089E on the
server. When not accompanied by other CTGES0008E authentication client errors,
these messages indicate only that a particular single sign-on token was discarded.

Already logged in
Read this topic if you closed your work session and then tried to log in again, but
received a message that the user ID was already logged in.
If you are logged in to the portal and close the browser window, you might not be
logged out. Because you closed the browser, though, you need to log in again to
start another work session. If, while logging in, you get a message that the user ID
is already logged in and do you want to log out the other user, accept the request.
No user role assigned

Users should have the minimum required product level roles assigned or they
might not see the contents of their default product pages after logging in.
Slow network response

Performance issues can cause an unresponsive script message to display after
login.
If, immediately after logging in, you get a message about an unresponsive script
and you are asked whether to continue or cancel opening the Web page, click
Continue. After a short time, the welcome page for the console is displayed.
Such messages can indicate a slow network link between your computer and the
application server. Ping the server computer to see the round trip response time.
Use response times of 40 ms or better.
Try using a remote desktop connection to a computer that has a better response
time with the application server and logging in from there.
Consider using a caching HTTP proxy to improve speed and reduce network
traffic.
Related reference:
IBM caching proxy
Webcast replay: Introduction to IBM Caching Proxy and troubleshooting
System in maintenance mode

A message about the system in maintenance mode in a load balancing
configuration can indicate that the servers have not had trust enabled between
them.
If you get a message in the portal, "The system is in maintenance mode. Please
contact your administrator and try again later", it most likely means that the
procedure for enabling trust between load balancing servers has not been
completed.
Related tasks:
Enabling server-to-server trust on page 44
Use this procedure to enable load balanced nodes to connect to each other and
send notifications.
Viewing TIPProfile logs for login errors

In the event of a login error, review the system outage and system error logs to
help determine the cause.

About this task
Follow these steps to open the system outage and system error logs:
Procedure
1. At the command line, change to the tip_home_dir/profiles/TIPProfile/logs/
server1 directory.
2. Open SystemOut.log and SystemErr.log in a text editor. On Windows, for
example, the command notepad systemout.log opens the log in Windows
Notepad.
3. Review the errors.
4. If the cause and solution to your login error is not apparent, send the
SystemOut.log and SystemErr.log from this directory and the
server1_exception.log (and any other files that were modified within a few
minutes of this one) from the sibling ffdc directory to your security
administrator for further examination.
Related tasks:
other information.
Chart errors
Consult this list of possible causes of charting errors and suggested solutions.
BIRT charts do not display if Java 2 security is enabled in WebSphere
Application Server
Java 2 security in WebSphere Application Server prevents the BIRT
charting component from running correctly. To view BIRT charts, ensure
that Java 2 security is disabled. For more information on Java 2 security,
see http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
com.ibm.websphere.express.doc/info/exp/ae/csec_rsecmgr2.html
BIRT report design format is not valid
The report designs that you create in the BIRT Designer should contain a
single data set and a single chart or table and nothing else. Other items in
the report might cause the error,
TIPCH0005E The design format for the chart or table is not valid
If you receive this error, modify your chart .rptdesign, upload it again, and
open it in a chart portlet.
Chart does not render or is very slow to render because the amount of data is
too large
When you open a BIRT designed chart that has a large amount of data, it
is possible to exceed the capacity of the application server. If this happens,
you will get an error message. Try pre-filtering the data so that only values
of interest get retrieved.
Also, be sure to single-click pages that have chart portlets in them. The
page might not display correctly or render the chart when it is
double-clicked from the navigation tree.
Chart portlet might not display in portlet list
While working in with a charting portlet, you can change the type of chart
by selecting another one from a list of available charts. Although it is

unlikely, it is possible for the list to not populate with the available charts.
If this happens, log out of the portal, restart your browser, and log in
again.
Cannot copy and add the charting portlet to a new page
When copying the Charting portlet and adding it to a new page, you
might get this message:
CWLAA6003 Could not display the portlet,
the portlet may not be started. Check the error logs
If this happens, ensure the charting role that your user ID is assigned to
has the Editor access level assigned.
Error messages while using the Charting portlet
While using the charting portlet, you could get this error message:
TIPMSG1003E An error occurred while making the server request.
Error: dojo.byId(...) is null or not an object
Alternatively, it might be an EOF (End Of File) exception that appears. If

either of these errors occurs, close the error message window and proceed.
Most of the time the chart will load; if it does not, you can either click
Refresh in the portlet or reload the chart from the selection.
Many users are loading to the same page that has charting portlets
This error can be displayed if too many users attempt to open a chart in
the same page at the same time:
TIPCH0006E An error occurred while collecting data for the chart,
check the web service data source.
Cannot set the string value () to parameter 1 java.rmi.RemoteException:
KFWITM220E Request failed during execution;
nested exception is: KFWITM220E Request failed during execution.
This error can happen when the system is overloaded with requests. Close
the error message window, then click Refresh in the chart portlet.
Closing many chart portlet pages in quick succession gives an error
When running the portal in the Firefox browser, you might get this error if
you quickly close many pages that have chart portlets:
TIPMSG1003E An error occurred while making the server request.
Error: dojo.byId(this.namespace + "chartNameH") has no properties
If this happens, close the error message window and proceed. The pages
will eventually close without error.
Cannot get the result set metadata from the ITM Web Service
When you connect to the ITM Web Service from the BIRT Designer to
create a custom chart, you might receive an error message, Cannot get the
result set metadata while creating a chart. Here are some possible causes
to review with your Tivoli Monitoring administrator:
v The IBM Tivoli Monitoring agent (or agents) is stopped or has
connectivity problems.
v The query is not supported by the Charting portlet or BIRT Designer.
The Charting portlet uses the view's definition, including any filters
applied. The BIRT Designer enables you to modify the query. You can
check the BIRT Designer log file at <BIRTDesigner>\workspace\
.metadata\.log for exception details. If you see this exception, the query
might not be supported in this release:

Caused by: org.apache.axis2.AxisFault: java.rmi.RemoteException:
KFWITM220E Request failed during execution.
In the Tivoli Enterprise Portal, click Query editor and look for the
query in the navigation tree. If the query is not listed, it will not be
available to the BIRT Designer or Charting portlet. Ask your
administrator to check the log files.
v If this is long-term historical data that is being retrieved, the Tivoli Data
Warehouse Proxy agent is stopped or has connectivity problems. These
are examples of errors that can occur when a view type is chosen that
queries historical data, but no data exists to return.
TIPCH0006E An error occurred while collecting data for the chart:
Cannot get the result set metadata.java.rmi. RemoteException:
KFWITM220E Request failed during execution; nested exception is:
KFWITM220E Request failed during execution.
Historical data queries require that historical data collection be

configured and started for the attribute groups and that sufficient data
bas been gathered to render a historical view. Furthermore, summarized
historical data requires that the Summarization and Pruning agent also
be configured and the process completed at least once before querying
summarized and pruned data.
Timeout or message about not connecting to the server
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 for some reason. Check that the portal server is
online and start it if it is not. Then try importing the chart again. If the
error is
TIPMSG1000E Detail: AxisFault
open tip_home_dir/properties/charts.properties in a text editor and

increase the value of this parameter (180000 is 3 minutes):
AXIS_TIMEOUT=180000.
Unable to view Tivoli Monitoring charts after installing the Web GUI followed
by Tivoli Business Service Manager
This error can be displayed when you attempt to load a chart from the
ITM Web Service:
Axis Fault: Error initializing ITM Import Manager
The ITM Web Service needs to be configured with the login ID for the
Tivoli Enterprise Portal Server. Use the ITMLogin command as described
in the Additional commands on page 137.
Loading a chart from an ITM Web Service continues indefinitely
This error can happen in a saved chart page when the administrative
console is running in the Firefox browser and the Page persistence setting
in the General properties is set to None. You can click Refresh in the
browser toolbar. You can also change Page persistence to Client, and then
Save the page with this setting.
Avoid double-clicking pages in the navigation tree. If you double-click a
page that contains a charting portlet, the page might not display correctly
or render the chart. A single click is all you need to do.
Problems loading a page after changing to another ITM Web Service
After adding the ITM Web Service and populating charts with data from

Tivoli Enterprise Monitoring Agents and OMEGAMON XE agents, do not
switch to a different ITM Web Service because there is no guarantee that
the same charts and queries will be available and there might be problems
loading the page.
Use the chart selector from the chart toolbar to load a different chart. In
addition, the ITM Web Service must be installed in the same instance as
the application server.
Cannot connect to an ITM Web Service from a remote Tivoli Integrated Portal
Server Connection to an ITM Web Service from a remote application server will
not be successful and is not supported in this release. The remote server
must define its own Web service connection to be able to import charts
from that Web service.
Imported charts are inconsistent with their Tivoli Monitoring counterpart
Many of the Tivoli Enterprise Portal workspaces are designed for showing
data from all the managed systems within the enterprise. When these
charts are imported into the console, users might notice that some of the
charts show data for all managed systems, without grouping data under
each managed system name.
To view a subset of the data for the chart, right-click the chart portlet and
click Preferences. Specify the managed system name in the Parameters tab.
The result will be a chart showing data for only the managed system name
that was specified. Ensure that the text entered matches the managed
system name as it appears in the Tivoli Enterprise Portal client, such as
myhostname:NT.
Tivoli Business Service Manager users can import Tivoli Monitoring
resources into the Service Component Registry using the Xmltoolkit.
Whenever the service is clicked in the service tree, the charting portlet
automatically receives the managed system name as context (no need to
specify the name in Preferences > Parameters).
Too many active report queries
When importing charts from a Tivoli Enterprise Portal Server that is at
Version 6.2 (not Version 6.2 Fix Pack 1 or later), the portal server might get
a message about too many active report queries. If this happens, add the
following environment variable to the portal server environment file:
KFW_REPORT_REQUEST_LIMIT=100
where 100 is the maximum number of outstanding requests that the portal
server will allow from each agent. The default value for IBM Tivoli
Monitoring V.6.2 is 15. The environment file is opened in a text editor
through Manage Tivoli Monitoring Services or the command line:
itm_install_dir\cnps\kfwenv
itm_install_dir/config/cq.ini
itm_install_dir/config/cq.ini
After editing the environment file, and recycling the Tivoli Enterprise
Portal Server, try importing charts again. Adjust the report request limit if
you continue to get the same error.
EmbedSQLException error when creating charting portlet
This occurs when a user starts the Tivoli Business Service Manager
Dashboard server as root and then later restarts as another user. Root
becomes owner of the derby files on disk and then the other user no
longer has write access to those files.

1. Do not start Tivoli Business Service Manager Dashboard server as root.
2. If you do so by accident, then you can correct the problem by changing
the owner of the derby files back the appropriate Tivoli Business
Service Manager user, as root, run the following commands:
chown -R tbsm_user tip_home_dir/derby
chgrp -R tbsm_user tip_home_dir/derby
Where:
tbsm_user is the user name of the appropriate Tivoli Business Service
Manager user.
tip_home_dir is the directory where Tivoli Integrated Portal is
installed.
Save to text option for a chart does not work in Internet Explorer 7
By default Internet Explorer is not configured to automatically prompt you
to download a file. To configure Internet Explorer 7 to prompt you to
download a file:
1. Click Tools > Internet Options.
2. In the Internet Options dialog, click the Security tab and click Custom
Level.
3. In the Settings panel scroll to the Downloads section and enable the
Automatic prompting for file downloads option and click OK.
4. Click OK in the Internet Options dialog to return the browser window.
IBM Tivoli Monitoring charts display differently in theTivoli Integrated Portal
environment
Some colors from Tivoli Monitoring charts may display differently in the
Tivoli Integrated Portal due to differences in their respective color palettes.
Tivoli Enterprise Portal Server is offline

You need connectivity with the Tivoli Enterprise Portal Server when installing the
ITM chart feature and when importing Tivoli monitoring agent data for rendering
charts.
Importing a Tivoli Monitoring chart
To retrieve Tivoli Monitoring agent attribute values for rendering in a chart, a

query is sent to the Tivoli Enterprise Portal Server. If the portal server is
unavailable for some reason, the message number TIPMSG1000E is displayed.
Check that the server is online and start it if it is not.
Editing a properties file

Properties files describe the environment and their settings are usually predefined
or added during installation. You do not need to change these files unless
instructed by IBM Software Support.
About this task
The properties files are on the computer where the Tivoli Integrated Portal Server
is installed.

Procedure
1. Locate the tip_home_dir/properties directory, where tip_home_dir represents
the installation path for the application server. For example,
C:\IBM\tivoli\tipv2 is the default installation path on Windows;
/opt/IBM/tivoli/tipv2/ is the default installation path on Linux or UNIX.
2. Open the desired properties file in a text editor.
3. Edit the file as needed, and then save and close it.
4. Stop the application server, and then restart it.
Related tasks:
Checking hostname settings on page 111
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://<SystemName>:16310) to the appropriate Tivoli
Integrated Portal non-secure access (for example, http://<HostnameValue>:16315)/
ibm/console), which is then converted to the Tivoli Integrated Portal secure access
(for example, https://<HostnameValue>:16316/ibm/console/login.jsp).
Setting a trace
Enable a trace of the Tivoli Integrated Portal Server when you want to keep a
record of activity.
Before you begin
The portal has a Troubleshooting Logs and Trace option for enabling a trace.
About this task
Follow these steps to set a trace that will record the Tivoli Integrated Portal Server
actions in a log file: tip_home_dir/profiles/TIPProfile/logs/server1/trace.log.
Procedure
3. In the WebSphere Application Server administrative console, select
Troubleshooting > Logs and traces.
4. Select the Tivoli Integrated Portal Server name (such as server1) in the Logging
and Tracing portlet.
5. In the Configuration tab, click Change Log Detail Levels.
6. In the Groups list, expand com.ibm.tivoli.* and click com.ibm.tivoli.tip.*.
7. Select a log level (such as All Messages and Traces) and click OK or Apply.
8. When prompted to save the configuration, click Save.


Results
After the server has been stopped and restarted, trace entries are saved to the
tip_home_dir/profiles/TIPProfile/logs/server1/trace.log file.
Related tasks:
Considerations when changing a user ID

Changing a user ID in the console is equivalent to creating new user that is
assigned only the default role of iscusers.
You can change a user ID in the Manage Users panel accessed through Users and
Groups > Manage Users. If you change a user ID then it is equivalent to creating
new user and the updated user ID is only assigned the default iscusers role.
Additional roles for the updated user ID can be configured through Users and
Groups > User Roles.
Important: If you change a user ID, any roles that were mapped for it, remain
associated with the previous user ID. So if you intend to change or delete a user
ID, you should first remove any role mappings that are associated with it. Once
you have made you change, you can re-apply the role mapping to the new user
ID.
Disabling Internet Explorer Enhanced Security Configuration

Internet Explorer Enhanced Security Configuration is an option that is provided in
Windows Server 2003 operating systems and above. To use Tivoli Integrated Portal
with Internet Explorer Version 7, you must disable Internet Explorer Enhanced
Security Configuration.
About this task
When Internet Explorer Enhanced Security Configuration is enabled, it can create

problems in viewing charts and some portlets. Follow these steps to disable
Internet Explorer Enhanced Security Configuration:
Procedure
1. Close all instances of Internet Explorer.
2. Click Start > Settings > Control Panel and open Add or Remove Programs.
3. In the left panel of the Add or Remove Programs window, click Add/Remove
Windows Components.
4. In the Windows Components Wizard dialog that is displayed, in the
Components panel, select the Internet Explorer Enhanced Security
Configuration entry and click Details.
5. In the Internet Explorer Enhanced Security Configuration dialog that is
displayed, clear the check boxes for the listed user groups and click OK.
6. In the Windows Components Wizard dialog, click Next and once your settings
have been applied, click Finish.
Results
Internet Explorer Enhanced Security Configuration is disabled.

Related concepts:
Resolving the FileNotFound Exception error on UNIX and Linux

systems
When a lot of files are open in Tivoli Integrated Portal you may encounter a
FileNotFound Exception error message. This problem arises only for computers
running UNIX or Linux operating systems.
About this task
This is a known issue with WebSphere Application Server environments, for more
details see http://www-01.ibm.com/support/docview.wss?uid=swg21067352.
In relation to a particular Tivoli Integrated Portal instance, carry out the following
steps to resolve the issue:
Procedure
1. Open the following file in a text editor:
v /etc/security/limits.conf
2. Add the following lines to limits.conf and save the updated file:
* soft nofile 32768
* hard nofile 65536
3. Restart the computer.
Results
The FileNotFound Exception issue is now resolved.

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 grant 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:
IBM World Trade Asia Corporation

Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, 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 may not apply to you.
This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.

All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which

illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs.
Trademarks
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.
Internet Explorer is a trademark of Microsoft Corporation in the United States,

other countries, or both

Index
A export
server settings 109
L
about this profile 92 exporting 94, 96, 98 LDAP 30
advanced commands 98 basic export console preference adding 26
application server profiles 97 configuring 28, 29
FIPS enablement 71 basic export pages 96 SSL 29
ports 92 basic export views 97 libstdc++ 145
profile 92 charts 85 Linux for zSeries 7
authentication export all 98 ListIU command 144
client messages 146 export pages 100 load balancing
export views 101 charting
rules 102, 104 database tables for load
B settings file 99 balancing 81
charting tables 81
back up ExportPagePlugin tipcli command
export 131 clone IDs 49, 50
server settings 109, 111
server-to-server trust 44
base charting 7
troubleshooting 147
basic commands 96
load balancing cluster
F join 46
FileNotFound Exception 155 log
C FIPS support 71 TIPProfile_create 139
certificate 11 log files 142
CGI support 107 login
chart H configure for HTTP and HTTPS 69
errors 148 hostname 111 errors 146
roles 80 HTTP and HTTPS 69 product roles 147
troubleshooting HTTP server slow response 147
chart errors 148 configuring 47 troubleshooting 148
ChartExportPlugin tipcli command HTTP server plug-in SSL configuration users 147
export 133 load balancing 53 logon 89
charting
SSO and ITM 86
charts
exporting 85 I M
importing 94, 103 maintenance mode error 147
importing 85
charts 85 Monitor role
cloning
import data 103 Context Menu Service 112
server settings 109, 110, 111
CMS rollback 104
access 112 server settings 110
configure hostname 78 infrastructure 3 O
configure logging 79 install 9 ObjectServer
create remote database 74 errors 139 SSL connection 32
data source 75, 76 preparation 5 overview 1
verify configuration 80 remove by console mode 12
components 3 remove by silent mode 12
console commands 9
console mode commands 9
silent 8
installation 5, 25, 57
P
deployment engine pages 127
Context Menu Service
failure after upgrade 143 password
access 112
error code ADMR0104E 146 change 93
CTGES1504E and CTGES1505E 146
errors 140 encryption 68
existing 13 SSL 93
port
D failure after DE upgrade 143
failure HP Integrity (ia64) server 144 numbers 92
Deployment Engine for single sign-on 33, 74 port assignments 92
managing 107 harmless messages 139 post-upgrade
log files 140 upgrade 20
troubleshooting preparing to install 5, 7
E installation errors 140 Preupgrade
Fails 144
editing Windows Server 2008 144
Internet Explorer Enhanced Security properties
properties files 152
Configuration 154 editing files 152
ETai 57

R tipcli command (continued)
portlets 127
registry preference profiles 126
default security 106 SystemInfo command 137
reinstall 6 TADDMLogin 137
roles user groups 128
system 90 users 126
views 125
tipcli ImportPagePlugin command
S import 135
SCS TIPIN0032E 152
See System Cloning Solution TIPMSG1000E 152
security TIPProfile_create.log 139
certificate 11 Tivoli Access Manager WebSEAL 57
default registry 106 Tivoli Enterprise Portal Server
vault key 68 connectivity errors 152
server trace 153
set a trace 153 troubleshooting 139
stopping or starting 91 installation errors 139
server settings login errors 146, 148
back up 109
clone 109
cloning 110, 111 U
export 109 uninstall 11, 12
importing 110 ITM Agent for Windows OS 13
silent install 8 upgrade
single sign-on 33, 74 post-upgrade LDAP 21
configuring 34 post-upgrade session timeout 22
ETai trust association 58, 59 pre-upgrade 16, 17
installing ETai 58 rollback 20
SSL 29 upgrading 18
configuring 30, 53 upgrading 15
HTTP server plug-in 53 user registry
SSL 30 default 106
to ObjectServer 32 users
stopping the application server 91 change user ID 154
System Cloning Solution 108
T V
vault key file 68
tipcli
AddRole 114
DelRole 115
exporting plugins 130
ListRoles 114
ListRolesForPage 117
ListRolesForPortletEntity 119
ListRolesForView 123
ListRolesFromGroup 116
ListRolesFromUser 121
MapRolesToGroup 116
MapRolesToPage 118
MapRolesToPortletEntity 120
MapRolesToUser 122
MapRolesToView 124
RemoveRolesFromGroup 117
RemoveRolesFromPage 119
RemoveRolesFromPortletEntity 121
RemoveRolesFromUser 123
RemoveRolesFromView 124
UpdateRole 114
tipcli command 113, 127
additional commands 137
charting 128
CMS 136
import 134
ITMLogin command 137

Printed in USA

Tip Admin Config 22

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tip Admin Config 22

Transféré par

Droits d'auteur :

Formats disponibles

Tivoli Integrated Portal

Tivoli Integrated Portal

Copyright IBM Corp. 2009, 2012 iii

iv Tivoli Integrated Portal Administration and configuration guide

Tivoli Integrated Portal provides the following features:

Copyright IBM Corp. 2009, 2012 1

Copyright IBM Corp. 2009, 2012 3

4 Tivoli Integrated Portal Administration and configuration guide

Preparing for installation

For additional hardware and software requirements, refer to your product

Copyright IBM Corp. 2009, 2012 5

Preparing a WebSphere Application Server environment

About this task

To prepare the WebSphere Application Server base environment:

The WebSphere Application Server environment is now ready to reinstall Tivoli

6 Tivoli Integrated Portal Administration and configuration guide

Secure Web service connection

Memory needed on Linux for zSeries

Installing in silent mode

About this task

Note: The \ (backslash) character is seen as an escape character. Use two

Important: To set up and run this function on a Microsoft Windows

8 Tivoli Integrated Portal Administration and configuration guide

Note: full_path_to_JRE should not include the bin subdirectory.

Note: Installation logs are saved to TIPInstaller-xx.log located in the ia

Silent mode response file parameters

10 Tivoli Integrated Portal Administration and configuration guide

Accepting the security certificate

Self-signed or CA-signed certificate

For more information about certificates, go to the IBM WebSphere Application

Uninstalling Tivoli Integrated Portal

Important: If you are uninstalling Tivoli Integrated Portal as a non-administrative

Caused by: com.ibm.ac.si.install.InstallUnauthorizedException: ACUINI0040W

Uninstalling in silent mode

About this task

To uninstall Tivoli Integrated Portal in silent mode:

Note: Uninstallation logs are saved to TipInstaller-xx.log that is located in

Stopping the ITM Monitoring Agent for Windows OS after

12 Tivoli Integrated Portal Administration and configuration guide

About this task

If after uninstalling Tivoli Integrated Portal, you cannot delete

Running the installer in an existing environment

Before you begin

About this task

When a product is installed into an existing Tivoli Integrated Portal environment,

The upgrade process includes a number of steps:

Running pre-upgrade for an existing installation

Copyright IBM Corp. 2009, 2012 15

Back up the current tip_home_dir and prod_home_dir directory branches in case

About this task

Note: This argument is not required if you want to include Tivoli

When the command completes, an upgradeData.zip file is created in

16 Tivoli Integrated Portal Administration and configuration guide

Exporting central user repository data

Before you begin

Back up the current tip_home_dir and prod_home_dir directory branches in case

Depending on the central user repository that you use, locate

About this task

Chapter 4. Upgrading Tivoli Integrated Portal 17

When the command completes, an repository_name.properties file is created

Copy the repository_name.properties file to the computer where you intend to

Upgrading a base installation

Before you begin

Install the higher version of Tivoli Integrated Portal on a separate computer to