Professional Documents
Culture Documents
Tip Admin Config 22
Tip Admin Config 22
Tip Admin Config 22
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
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.
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.
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
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
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
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.
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.
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".
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
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.
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:
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
Chapter 3. Installing 9
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.
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
Important: WebSphere Application Server fix packs and interim fixes are not
removed when you uninstall Tivoli Integrated Portal.
Chapter 3. Installing 11
In this particular circumstance, the error message may be ignored and no further
action is required.
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.
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: 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
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 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.
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.
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.
Back up the current tip_home_dir directory branch in case you want to revert to
that installation.
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 3. Installing 13
14 Tivoli Integrated Portal Administration and configuration guide
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.
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.
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.
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.
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
Back up the deployment engine database in case you want to revert to that
installation.
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
What to do next
Back up the deployment engine database for the new in case you want to roll back
from the upgrade.
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.
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:
v tip_home_dir/profiles/TIPProfile/upgrade/bin/
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
The account details for the Tivoli Integrated Portal administrator.
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
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.
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
The account details for the Tivoli Integrated Portal administrator.
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.
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.
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
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.
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
v tip_home_dir/profiles/TIPProfile/upgrade/bin/
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.
If you have installed Tivoli Integrated Portal in a distributed scenario, perform these
steps for each Tivoli Integrated Portal instance.
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.
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.
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
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
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
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.
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. 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.
6. In the WebSphere Application Server administrative console, select Security >
Global security.
7. From the Available realm definitions list, select Federated repositories and
click Set as current to mark the federated repository as the current realm.
8. 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
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:
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.
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 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.
Chapter 5. Configuring 29
10. 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.
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.
12. 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
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 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.
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.
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
You can use the Change Your Password portlet to change your password from the
default provided by the administrator.
Chapter 5. Configuring 31
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:
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. 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
3. 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
Single sign-on
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.
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.
Chapter 5. Configuring 33
Related tasks:
Adding an external LDAP repository on page 26
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.
Configuring single sign-on
Use these instructions to establish single sign-on support and configure a federated
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
Locate and review the logs and related files after an installation to confirm that the
components were successfully installed.
Attention: ITM single sign on (SSO) support is only available with ITM Version
6.2 Fix Pack 1 or higher.
Procedure
1. Log in to the Tivoli Integrated Portal.
2. In the navigation pane, click Settings > Websphere Administrative Console
and click Launch Websphere administrative console.
3. 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).
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:
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.
Adding an external LDAP repository on page 26
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.
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.
Chapter 5. Configuring 35
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.
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.
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
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.
Chapter 5. Configuring 37
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
Installing the IBM HTTP Server
Creating a new key database
Creating a new key database
Creating a self-signed certificate
Creating a self-signed certificate
Setting up SSL for IBM HTTP Server
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.
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.
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
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.
Chapter 5. Configuring 39
3. From a command prompt, change to the tip_home_dir/profiles/TIPProfile/
bin/ha directory and edit the settings in tipha.properties.
${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.
Results
The load balancing cluster is created and the console node is joined to the cluster
as the first node.
What to do next
Chapter 5. Configuring 41
Joining a node to a load balancing cluster
You can configure a Tivoli Integrated Portal Server to join an existing load
balancing cluster.
The following parameters are used on the join option when a node is added:
v -Dusername - specify the DB2 administrator's username
v -Dpassword - specify the DB2 administrator's password
Procedure
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.
2. From a command prompt, change to the tip_home_dir/profiles/TIPProfile/
bin/ha directory and edit the settings in tipha.properties.
${WAS_ROOT}\profiles\${ProfileName}\installedApps\
${CellName}\${IscAppName}.ear
Example: isc (default)
Chapter 5. Configuring 43
Property name Description
LoggerLevel The level of logging required. The default is OFF.
Example: FINER
HAEnabled Indicates if load balancing is enabled.
Results
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.
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.
Chapter 5. Configuring 45
tip_home_dir\profiles\TIPProfile\bin\retrieveSigners.bat
NodeDefaultTrustStore AnotherTrustStore -host myremotehost -port
remote_SOAP_port
tip_home_dir/profiles/TIPProfile/bin/
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.
9. 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
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
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.
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.
The IBM HTTP Server uses a Web server plug-in to forward HTTP requests to the
Tivoli Integrated Portal Server. You can configure the HTTP server and the Web
server plug-in to act as the load balancing server, that is, pass requests (HTTP or
HTTPS) to one of any number of nodes. The load balancing methods supported by
the plug-in are round robin and random:
v With a round robin configuration, when a browser connects to the HTTP server,
it is directed to one of the configured nodes. When another browser connects, it
is directed to a different node.
v With the random setting, each browser is connected randomly to a node. Once a
connection is established between a browser and a particular node, that
connection remains until the user logs out or the browser is closed.
The HTTP server is necessary for directing traffic from browsers to the applications
that run in the Tivoli Integrated Portal environment. The server is installed between
the portal and the Tivoli Integrated Portal Server, and is outside the firewall.
The Web server plug-in uses the plugin-cfg.xml configuration file to determine
whether a request is for the application server.
Complete this procedure to configure the Web server plug-in for load balancing for
each node.
Procedure
1. If you do not already have the IBM HTTP Server installed, install it before
proceeding. It should be installed where it can be accessed from the Internet or
Intranet (or both). Select the link at the end of this topic for the installation
procedure.
2. Install IBM HTTP Server ensuring that you include the IBM HTTP Server
Plug-in for IBM WebSphere Application Server option. For more information,
see http://publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/
com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_installihs.html.
3. Create a new CMS-type key database. For more information see
http://publib.boulder.ibm.com/infocenter/wasinfo/fep/index.jsp?topic=/
com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_createkeydb.html.
Chapter 5. Configuring 47
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"
What to do next
Note: The default load balancing method is random, whereby each browser is
connected randomly to a node.
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="
Chapter 5. Configuring 49
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.
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.
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="*:80" />
<VirtualHost Name="*:16311" />
<VirtualHost Name="*:5060" />
<VirtualHost Name="*:5061" />
<VirtualHost Name="*:443" />
<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"/>
<Transport Hostname="SERVER1" Port="16311"
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">
<Transport Hostname="SERVER2" Port="16310"
Protocol="http"/>
<Transport Hostname="SERVER2" Port="16311"
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"/>
Chapter 5. Configuring 51
</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/*" />
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
Name="/IBM_WS_SYS_RESPONSESERVLET/*" />
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
Name="/IBM_WS_SYS_RESPONSESERVLET/*.jsp" />
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
Name="/IBM_WS_SYS_RESPONSESERVLET/*.jsv" />
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
Name="/IBM_WS_SYS_RESPONSESERVLET/*.jsw" />
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
Name="/IBM_WS_SYS_RESPONSESERVLET/j_security_check" />
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
Name="/IBM_WS_SYS_RESPONSESERVLET/ibm_security_logout" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ibm/console/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ibm/help/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ibm/action/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ISCWire/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/isc/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ISCHA/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/tip_ISCAdminPortlet/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ISCAdminPortlets/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/mum/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ibm/TIPChangePasswd/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ibm/TIPExportImport/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ibm/tivoli/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/proxy/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/TIPWebWidget/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ibm/dbfile/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/ibm/TIPChartPortlet/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/TIPUtilPortlets/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
AffinityURLIdentifier="jsessionid" Name="/WIMPortlet/*" />
<Uri AffinityCookie="JSESSIONID_ibm_console_16310"
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" />
This task assumes that you have already installed and configured the IBM HTTP
Server for load balancing.
For each node in the cluster, follow these instructions to configure the node to
communicate over a secure (SSL) channel with the IBM HTTP Server.
Procedure
1. Log in to the Tivoli Integrated Portal.
2. In the navigation pane, click Settings > Websphere Administrative Console
and click Launch Websphere administrative console.
3. Follow these steps to extract signer certificate from the trust store:
a. In the WebSphere Application Server administrative console navigation
pane, click Security > SSL certificate and key management.
b. In the Related Items area, click the Key stores and certificates link and in
the table click the NodeDefaultTrustStore link.
c. In the Additional Properties area, click the Signer certificates link and in
the table that is displayed, select the root entry check box.
d. Click Extract and in the page that is displayed, in the File name field, enter
a certificate file name (certficate.arm), for example, c:\tivpc064ha1.arm.
e. From the Data Type list select the Base64-encoded ASCII data option and
click OK.
f. Locate the extracted signer certificate and copy it to the computer running
the IBM HTTP Server.
Note: This steps are particular to Tivoli Integrated Portal, for general
WebSphere Application Server details and further information, see:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
com.ibm.websphere.base.doc/info/aes/ae/tsec_sslextractsigncert.html
4. On the computer running the IBM HTTP Server, follow these steps to import
the extracted signer certificate into the key database:
a. Start the key management utility (iKeyman), if it is not already running,
from HTTP_SERVER_PATH/bin:
Chapter 5. Configuring 53
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.
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.
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.
Results
The data from the initial application server is imported to the node and replicated
across the other cluster nodes.
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
Chapter 5. Configuring 55
HATool.bat/sh repositories username password -byNodes -showAll
Removing a node
Follow these steps to remove a node from the load balancing cluster.
The following parameters are used on the disjoin option when a node is removed.
v -Dusername - specify the DB2 administrator's username
v -Dpassword - specify the DB2 administrator's password
Procedure
1. 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 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.
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
1. 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 remote-disjoin
DremoteHost=remote_host DremotePort=9044 -Dusername=DB2_username
-Dpassword=DB2_password
Make sure you have removed all other nodes from the cluster. This command
should be issued from the last active node remaining in the cluster.
The following parameters are used on the join option when a node is added.
v -Dusername - specify the DB2 administrator's username
v -Dpassword - specify the DB2 administrator's password
Procedure
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.
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.
Chapter 5. Configuring 57
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.
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
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.
What to do next
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:
Chapter 5. Configuring 59
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.
If com.ibm.websphere.security
.webseal.checkViaHeader is set to false then the
values set for
com.ibm.websphere.security.webseal.hostnames are
not used.
Chapter 5. Configuring 61
Table 1. ETai custom properties (continued)
Property details Notes
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.
11. Stop and restart the Tivoli Integrated Portal Server:
What to do next
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.
Chapter 5. Configuring 63
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
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.
What to do next
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.
The following is the expected output:
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.
The following is the expected output:
/
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
Chapter 5. Configuring 65
-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
The following is the expected output:
Created junction at /tip
What to do next
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.
The following is the expected output:
DPWWM1462I JMT Table successfully loaded
5. To restart the WebSEAL server, enter pdweb restart.
The following is the expected output:
Stopping the: webseald-ip1
Starting the: webseald-ip1
What to do next
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
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:
Chapter 5. Configuring 67
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.
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:
The Tivoli Integrated Portal administrator ID (default is tipadmin) that was created
during the installation needs access to the vault key file for Tivoli Integrated Portal
applications to work properly.
The vault key is an encryption key that is used to encrypt the administrator
password that was provided during installation and is stored locally for Tivoli
Integrated Portal applications. Use these steps to restrict access to the file.
Procedure
1. On the computer where the application server is installed, open the
tip_home_dir/_uninst/TIPInstall2201 directory.
2. Use the method provided by your operating system to ensure that the
.vault.key file has read-only access.
Example
On Windows, for example, the attributes for the TIPInstall2201 directory are
already set to read-only; those for the .vault.key file are set to read-only and
hidden.
After installing Tivoli Integrated Portal and before beginning this procedure, log in
to the portal to ensure that it has connectivity and can start successfully.
Configuring for HTTP and HTTPS console access involves editing the web.xml file
of Web components. Use this procedure to identify and edit the appropriate Web
XML files.
Procedure
1. Change to the following directory: tip_home_dir/profiles/TIPProfile/
config/cells/TIPCell/applications.
2. From this location, locate the web.xml files in the following directories:
v For the Integrated Solutions Console web application archive:
isc.ear/deployments/isc/isclite.war/WEB-INF
v For the Tivoli Integrated Portal Charts web application archive:
isc.ear/deployments/isc/TIPChartPortlet.war/WEB-INF
v For the Tivoli Integrated Portal Change Password web application archive:
isc.ear/deployments/isc/TIPChangePasswd.war/WEB-INF
3. Open one of the web.xml files using a text editor.
4. Find the <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.
8. In the navigation pane, click Settings > Websphere Administrative Console
and click Launch Websphere Administrative Console.
9. In the WebSphere Application Server administrative console, select Security >
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.
Chapter 5. Configuring 69
13. 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
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.
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
and click Launch Websphere administrative console.
c. In the WebSphere Application Server administrative console navigation
pane, click Security > SSL certificate and key management.
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.
Chapter 5. Configuring 71
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.
a. In the navigation pane, click Settings > Websphere Admin Console and
click Launch Websphere Admin Console.
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
tip_home_dir/profiles/TIPProfile/
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:
v startServer.bat server1
v startServer.sh server1
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
click Launch Websphere Admin Console.
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
Example
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.
6. 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.
Chapter 5. Configuring 73
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.
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.
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
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.
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.
Chapter 5. Configuring 75
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
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.
What to do next
When you have configured the data source in Tivoli Integrated Portal, you can
configure the hostname.
Chapter 5. Configuring 77
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
You need to set a hostname that CMS can use. For example, in a load balanced
environment, it may not be obvious which hostname CMS should use. To specify a
hostname to CMS:
Procedure
1. On the computer running Tivoli Integrated Portal, at the command line, change
to the following directory:
tip_home_dir/profiles/TIPProfile/bin/CMS
2. Run the cmssetconf command to view details of the different options that are
available to you in setting up CMS to use the remote database.
./cmssetconf.sh
cmssetconf.bat
One of the settings that you apply using the cmssetconf command, is the
hostname.
3. Run the following command to specify the hostname that you want to use:
./cmssetconf.sh -hostname hostname -port tip_port_number
cmssetconf.bat -hostname hostname -port tip_port_number
The hostname in now configured.
4. Run the following command to review your CMS configuration and verify that
you have correctly specified the hostname:
./cmsshowconf.sh -hostname hostname -port tip_port_number
cmsshowconf.bat -hostname hostname -port tip_port_number
5. 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
What to do next
When you have configured the hostname, you can set up logging for CMS.
Procedure
1. Log in to the Tivoli Integrated Portal.
2. In the navigation pane, click Settings > Websphere Administrative Console
and click Launch Websphere administrative console.
3. In the WebSphere Application Server administrative console navigation pane,
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.
14. 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
Chapter 5. Configuring 79
v startServer.bat server1
v startServer.sh server1
What to do next
When you have configured the logging for CMS, you verify your configuration.
Procedure
1. On the computer running Tivoli Integrated Portal, at the command line, change
to the following directory:
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.
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
Roles are assigned through Users and Groups > Administrative User Roles.
After a chart has been added to a console page, it is automatically refreshed with
new data at intervals. The refresh rate is adjusted based on the response time of
the Tivoli Integrated Portal Server. This ensures that the server is not overloaded
with data requests and that it remains responsive. The algorithm for calculating the
next refresh interval uses three parameters from the chart properties:
Minimum refresh interval
Maximum refresh interval
Response time multiplier
You can adjust the balance of chart refresh rate and server performance by using a
tipcli command:
Procedure
1. On the command-line interface, change to the install_dir/profiles/
TIPProfile/bin/ directory.
2. Run the following command declaring the chart property that you want to
modify and its new value:
tipcli.bat ChartProperties --[name parameter_name --value
--parameter_value] --username user_name --password user_password
tipcli.sh ChartProperties --[name parameter_name --value
--parameter_value] --username user_name --password user_password
The following list provides details on the arguments and parameters shown:
parameter_name
The chart property that you want to modify. The following parameters
can be modified:
v UPDATE_MAXIMUM_INTERVAL (Default value = 60)
The default maximum interval between data refreshes is 60 seconds
unless the server response time multiplied by the UPDATE_MULTIPLIER
value is longer. Consider raising this number if the calculated
interval often exceeds the maximum.
v REPORT_OUTPUT_DIR (Default value = install_dir/temp/report)
v AXIS_TIMEOUT (Default value = 9000)
If the system times out or an error message is displayed while
importing an Tivoli Monitoring chart, it is typically because the
Tivoli Enterprise Portal Server is unavailable. You can extend the
time period before the time out by increasing this value.
v REPORT_INPUT_DIR (Default value = install_dir/report)
v DBTABLE_VERSION (Default value = 1.1.1)
Chapter 5. Configuring 81
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
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.
$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%
Chapter 5. Configuring 83
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.
6. 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
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.
Chapter 5. Configuring 85
Table 3. ChartImport command arguments (continued)
Parameter and arguments Description
--password tip_user_password Mandatory parameter. The password for the
specified user name.
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:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
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
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.
Chapter 5. Configuring 87
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
Use these instructions to establish single sign-on support and configure a federated
repository.
Adding an external LDAP repository on page 26
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.
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.
Logging in
Log in to the portal whenever you want to start a work session.
The Tivoli Integrated Portal Server must be running before you can connect to it
from your browser.
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.
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:
Viewing the application server profile on page 92
Open the application server profile to review the port number assignments and
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.
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.
Roles are assigned through Users and Groups > Administrative User Roles.
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:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_tselugradro.html
Procedure
1. 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
Chapter 6. Administering 91
v startServer.sh server1
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 application server requires a set of sequentially numbered ports.
The sequence of ports is supplied during installation in the response file. The
installer checks that the number of required ports (starting with the initial port
value) are available before assigning them. If one of the ports in the sequence is
already in use, the installer automatically terminates the installation process and
you must specify a different range of ports in the response file.
Related tasks:
Viewing the application server profile
Open the application server profile to review the port number assignments and
other information.
Related reference:
Port number settings in WebSphere Application Server versions
Many port values in Tivoli Integrated Portal are different.
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
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:
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 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
You can use the Change Your Password portlet to change your password from the
default provided by the administrator.
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.
Chapter 6. Administering 93
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:
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.
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.
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.
Chapter 6. Administering 95
Exporting pages in simplified mode
By using the ExportPage command you can export specific pages without having
to provide additional qualifying parameters.
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
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh
ExportPage --uniqueName pageID_1,pageID_2,pageID_3 --username
tipadmin_user_name --password tipadmin_password
Results
What to do next
Procedure
1. At the command line change to: tip_home_dir/profiles/TIPProfile/bin.
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
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh
ListViews
3. Review the list of returned view records and take note of the view IDs for the
views that you want to export.
4. To export specific views, run the following command:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat ExportView
--uniqueName viewID_1, viewID_2, viewID_3
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh
ExportView --uniqueName viewID_1, viewID_2, viewID_3
Results
What to do next
Procedure
1. At the command line change to: tip_home_dir/profiles/TIPProfile/bin.
2. Optional: To return a list of console preference profiles that can be exported:
Chapter 6. Administering 97
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat
ListPreferenceProfiles
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh
ListPreferenceProfiles
3. Review the list of returned records and take note of the unique names for the
console preference profiles that you want to export.
4. To export specific console preference profiles, run the following command:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat ExportProfile
--uniqueName profile_ID1,profile_ID2,profile_ID3
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh
ExportProfile --uniqueName profile_ID1,profile_ID2,profile_ID3
Results
What to do next
Procedure
1. At the command line change to: tip_home_dir/profiles/TIPProfile/bin.
2. Optional: To return a list of plugins that will be run during the export
operation, run the following command:
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh
ListExportPlugins
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat
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
Results
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
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
Chapter 6. Administering 99
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat Export
--username tipadmin_user_name --password tipadmin_password
--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: 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.
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
Results
What to do next
Procedure
1. At the command line change to: tip_home_dir/profiles/TIPProfile/bin.
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
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh
ListViews
3. Review the list of returned view records and take note of the view IDs for the
views that you want to export.
4. To export specific views, run the following command:
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh Export
--username tipadmin_user_name --password tipadmin_password --views
viewID_1,viewID_2,viewID_3 --exportpageinviews [true|false]
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat Export
--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.
Results
What to do next
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.
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.
Ensure that you have run the export operation on an originating instance of the
Tivoli Integrated Portal Server and that you have copy the output file (data.zip) to
the following directory on the other instance:
tip_home_dir/profiles/TIPProfile/output
To import data from a data.zip file that was exported from another instance Tivoli
Integrated Portal Server:
Procedure
1. At the command line change to: tip_home_dir/profiles/TIPProfile/bin.
2. Optional: To return a list of plugins that will be run during the import
operation, run the following command:
v tip_home_dir\profiles\TIPProfile\bin\tipcli.bat
ListImportPlugins
Chapter 6. Administering 103
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
--username tipadmin_user_name --password tipadmin_password
v tip_home_dir/profiles/TIPProfile/bin/tipcli.sh Import
--username tipadmin_user_name --password tipadmin_password
Results
When the Import command completes, the imported data is merged with the
existing Tivoli Integrated Portal environment.
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.
Procedure
1. At the command line change to: tip_home_dir/profiles/TIPProfile/bin.
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.
The following rules apply when importing customized configuration data for a
Tivoli Integrated Portal environment:
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
These steps require that your user ID has the Administrator role and that you
know the base entry value of your repository. For LDAP or Microsoft Active
Directory, this is usually a string like ou=company,dc=country,dc=region. For the
ObjectServer, the base entry is o=netcoolObjectServerRepository.
If you want to change the default to a different registry, complete these steps:
Procedure
1. Log into the Tivoli Integrated Portal. Your ID must have the Administrator role.
2. In the navigation pane, click Settings > Websphere Admin Console and click
Launch Websphere Admin Console.
3. In the WebSphere Application Server administrative console navigation pane,
click Security > Secure administration, applications, and infrastructure.
4. In the User account repositories area, select Federated repositories from the
Available realm definitions, then click Configure.
5. Click Supported entity types under Additional Properties.
6. Click the entity type, then edit the Base entry for the default parent and
Relative Distinguished Name properties.
7. After you click OK to save your changes, repeat the previous step to configure
the other entity types. For Microsoft Active Directory, the entity types
(PersonAccount, Group, and OrgContainer) must be configured with a base DN
and the RDN for PersonAccount should be cn instead of uid.
8. 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
CGI support
Use the initialization parameters to control the behavior of 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.
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.
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>
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
The Tivoli Integrated Portal platform is laid down during product installation. You
can install additional products and they will all share the same platform.
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.
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.
Procedure
1. On the command-line interface, change to the tip_home_dir/profiles/
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.
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.
Important: The target server instance should not be configured for load balancing.
The cloning process imports data for a local server instance only.
Procedure
1. On the command-line interface, change to the tip_home_dir/profiles/
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.
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")
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:
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.
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).
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:
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.
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.
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.
Command reference
Use the Tivoli Integrated Portal command line interface tipcli commands for
writing scripts for passing information between applications.
ListRoles
Use the ListRoles command to list all roles configured for a portal instance.
Example
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
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.
Example
UpdateRole
Use the UpdateRole command to change the name of a custom role.
Syntax
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 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
DelRole
Use the DelRole command to delete a custom role.
Syntax
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 modified.
Example
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
group_ID is the name of the user group associated with the roles that you want
to list.
Example
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesFromGroup
--username tip_username --password tip_user_password --groupID group_ID
MapRolesToGroup
Use the MapRolesToGroup command to associate a comma-separated list of roles to
a specified user group.
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
group_ID is the name of the user group associated with the roles that you want
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.
RemoveRolesFromGroup
Use the RemoveRolesFromGroup command to disassociate a comma-separated list of
roles from a specified user group.
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
group_ID is the name of the user group associated with the roles that you want
to list.
role_name1, role__name2 is a comma-separated list of roles that are to be
associated with the specified user group.
Note: Individual role name arguments to the rolesList parameter must not
include spaces.
Example
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh 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
Where:
page_unique_name is the unique ID for the page.
Example
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesForPage
--pageUniqueName page_unique_name
MapRolesToPage
Use the MapRolesToPage command to associate a comma-separated list of roles with
a specified page and set an access level for each role.
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
page_unique_name is the page ID with which to associate with the list of roles.
role_name1, role__name2 is a comma-separated list of roles that are to be
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.
Note: Individual role name arguments to the rolesList parameter must not
include spaces.
Example
RemoveRolesFromPage
Use the RemoveRolesFromPage command to disassociate a comma-separated list of
roles with a specified page.
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
page_unique_name is the page ID associated with the roles that you want to
remove.
role_name1, role__name2 is a comma-separated list of roles that are to be
disassociated with the page.
Note: Individual role name arguments to the rolesList parameter must not
include spaces.
Example
ListRolesForPortletEntity
Use the ListRolesForPortletEntity command to list all roles associated with a
specified portlet.
Syntax
Example
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesForPage
--pageUniqueName page_unique_name
MapRolesToPortletEntity
Use the MapRolesToPortletEntity command to associate a comma-separated list of
roles with a specified portlet.
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
portlet_entity_unique_name is the unique portlet ID with which to associate with
the list of roles.
role_name1, role__name2 is a comma-separated list of roles that are to be
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
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.
Note: Individual role name arguments to the rolesList parameter must not
include spaces.
Example
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh MapRolesToPortletEntity
--username tip_username --password tip_user_password
RemoveRolesFromPortletEntity
Use the RemoveRolesFromPortletEntity command to disassociate a
comma-separated list of roles with a specified portlet.
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
portlet_entity_unique_name is the portlet ID associated with the roles that you
want to remove.
role_name1, role__name2 is a comma-separated list of roles that are to be
disassociated with the portlet.
Note: Individual role name arguments to the rolesList parameter must not
include spaces.
Example
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh RemoveRolesFromPortletEntity
--username tip_username --password tip_user_password
--portletEntityUniqueName portlet_entity_unique_name --rolesList
role_name1, role__name2
ListRolesFromUser
Use the ListRolesFromUser command to list all roles associated with a specified
user.
Syntax
Example
MapRolesToUser
Use the MapRolesToUser command to associate a comma-separated list of roles with
a specified user ID.
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
user_ID is the unique user ID with which to associate with the list of roles.
role_name1, role__name2 is a comma-separated list of roles that are to be
associated with the user.
Note: Individual role name arguments to the rolesList parameter must not
include spaces.
Example
RemoveRolesFromUser
Use the RemoveRolesFromUser command to disassociate a comma-separated list of
roles with a specified user ID.
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
portlet_entity_unique_name is the user ID associated with the roles that you want
to remove.
role_name1, role__name2 is a comma-separated list of roles that are to be
disassociated with the portlet.
Note: Individual role name arguments to the rolesList parameter must not
include spaces.
Example
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh RemoveRolesFromUser
--username tip_username --password tip_user_password --userID user_ID
--rolesList role_name1, role__name2
ListRolesForView
Use the ListRolesForView command to list all roles associated with a specified
view.
Syntax
Where:
view_name is the unique name for the view.
Example
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh ListRolesForView
--viewUniqueName view_name
MapRolesToView
Use the MapRolesToView command to associate a comma-separated list of roles with
a specified view and set an access level for each role.
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
view_name is the unique view name with which to associate with the list of
roles.
role_name1, role__name2 is a comma-separated list of roles that are to be
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
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.
Note: Individual role name arguments to the rolesList parameter must not
include spaces.
Example
RemoveRolesFromView
Use the RemoveRolesFromView command to disassociate a comma-separated list of
roles with a specified view.
Syntax
Where:
tip_username is the portal administrator user ID.
tip_user_password is the password associated with the portal administrator user
ID.
view_name is the unique view name associated with the roles that you want to
remove.
role_name1, role__name2 is a comma-separated list of roles that are to be
disassociated with the portlet.
Note: Individual role name arguments to the rolesList parameter must not
include spaces.
Example
tip_home_dir/profiles/TIPProfile/bin/tipcli.sh RemoveRolesFromView
--username tip_username --password tip_user_password --viewUniqueName
view_name --rolesList role_name1, role__name2
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
--accessLevelList level1, level2
Associate a comma separated list of views with a particular role and set
the access level for the role for each view.
ListRestoreTimestamp
Use the ListRestoreTimestamp command to return a list of charting store
backups by timestamp.
RestoreChartStore --BackupTimestamp backup_timestamp --username
tip_username --password tip_user_password
Use the RestoreChartStore command to restore a chart store by timestamp.
Table 9. RestoreChartStore command arguments
Parameter and arguments Description
RestoreChartStore --BackupTimestamp Mandatory parameter. The timestamp of the
charting store backup.
--username tip_username Mandatory parameter. The user name for a
user with the chartAdministrator role.
--password tip_user_password Mandatory parameter. The password for the
specified user name.
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.
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.
Export [--exportFile export_file] [--pages ALL|NONE|page1,page2] [--views
ALL|NONE|view1,view2] [--roles ALL|NONE|REQUIRED|role1,role2]
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.
Export [--includeCharts ALL|NONE|page_ID1,page_ID2] --username tip_username
--password tip_user_password
Note: If you specify additional parameters for the tipcli.bat|.sh Import 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.
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
Parameter and arguments Description
[--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.
Related concepts:
Exporting and importing on page 94
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.
Note: If you specify additional parameters for the tipcli.bat|.sh Import 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.
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
Parameter and arguments Description
[--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.
where export_directory is the location where you want the output files to be
saved.
For example:
Exported CMS data can be subsequently imported to another Tivoli Integrated Portal
instance.
Where:
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:
Once the command completes, CMS data is imported into the Tivoli Integrated
Portal environment and the relevant menus are updated.
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
Parameter and arguments Description
[--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.
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.
Installation errors
Review the Preparing to install topics before starting an installation; review the
topics here for handling errors that might arise during the installation.
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.
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
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
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.
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]"
Log files
Locate and review the logs and related files after an installation to confirm that the
components were successfully installed.
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
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
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.
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.
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:
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:
Running pre-upgrade for an existing installation on page 15
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.
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.
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
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.
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.
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.
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
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.
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:
Viewing the application server profile on page 92
Open the application server profile to review the port number assignments and
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
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
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:
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.
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
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.
The properties files are on the computer where the Tivoli Integrated Portal Server
is installed.
Setting a trace
Enable a trace of the Tivoli Integrated Portal Server when you want to keep a
record of activity.
The portal has a Troubleshooting Logs and Trace option for enabling a trace.
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
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
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.
9. 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
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:
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.
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.
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.
154 Tivoli Integrated Portal Administration and configuration guide
6. In the Windows Components Wizard dialog, click Next and once your settings
have been applied, click Finish.
Results
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
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:
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
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.
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.
COPYRIGHT LICENSE:
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.
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