Tivoli Workload Scheduler - ibm.com · PDF fileConfigure Load Balancer to work with multiple...

Tivoli Workload Scheduler

Dynamic Workload Console

Installing and Configuring

Version: 0.1 February 10, 2012

Installing and Configuring the Dynamic Workload Console

2

Table of Contents

Installing and Configuring the Dynamic Workload Console........................................................................................ 3 Installation considerations.......................................................................................................................................... 3 Installing the Dynamic Workload Console.................................................................................................................. 4 Configuring access to the Dynamic Workload Console ............................................................................................. 6

Configuring Dynamic Workload Console to use Single Sign-On ........................................................................... 7 Configuring LDAP with Microsoft Windows Active Directory ................................................................................. 8 Configuring the use of Lightweight Third-Party Authentication (LTPA token-keys) ............................................. 10

Configuring to use the same LTPA token_keys.............................................................................................. 10 Disabling the automatic generation of LTPA token_keys ............................................................................... 12

Configuring roles to access the Dynamic Workload Console .............................................................................. 13 Configuring High Availability for the Dynamic Workload Console ....................................................................... 15

Sample Topology of Dynamic Workload Console HA Configuration .............................................................. 15 Creating Database for Tivoli Integrated Portal 2.2 HA Configuration ....................................................................... 15

Make the LDAP user the primary user in the HA environment ....................................................................... 17 Enabling HA for Tivoli Integrated Portal 2.2.................................................................................................... 18 Creating a new HA Cluster ............................................................................................................................. 18 Joining servers to the existing HA cluster....................................................................................................... 22 Enabling server-to-server trust between all Tivoli Integrated Portal 2.2 servers............................................. 22 Verifying the configuration .............................................................................................................................. 23 HA Configuration example with Cisco ACE .................................................................................................... 24 Configuration Design ...................................................................................................................................... 24 Configuration .................................................................................................................................................. 24 Configure Dynamic Workload Console to use DB2 ........................................................................................ 25 Creating a database for a Dynamic Workload Console HA cluster ................................................................ 26 Configuring SSL between DB2 and Dynamic Workload Console (optional) ................................................... 26 Enable SSL for Tivoli Integrated Portal Server ............................................................................................... 27 Creating datasource ....................................................................................................................................... 27 Creating datasource on the other Dynamic Workload Console instances ...................................................... 28 Changing the settings repository on the Dynamic Workload Console ............................................................ 29 Sharing user settings repository to multiple Dynamic Workload Consoles ..................................................... 29 Changing user of DB repository (optional)...................................................................................................... 30 Configure Load Balancer to work with multiple Tivoli Workload Scheduler for z/OS servers: ........................ 31

Getting started with the Dynamic Workload Console ............................................................................................... 32 Accessing the Dynamic Workload Console......................................................................................................... 32 Quick steps to define a Tivoli Workload Scheduler engine connection ............................................................... 33

Uninstalling the Dynamic Workload Console version 8.6 ......................................................................................... 34 Uninstalling the Dynamic Workload Console version 8.5.1 FP1 .............................................................................. 37 Troubleshooting the installation/uninstallation.......................................................................................................... 38

Installation log files .............................................................................................................................................. 38 Recovering a failed installation............................................................................................................................ 39

Stopping and resuming an interactive installation........................................................................................... 39 Correcting a failed step and continuing the installation................................................................................... 40 The Step List window ..................................................................................................................................... 40 The Step window............................................................................................................................................ 42 Deciding whether to resume the wizard or rerun it ......................................................................................... 44

Uninstalling the Dynamic Workload Console and the Tivoli Integrated Portal manually .......................................... 34 Troubleshooting Single Sign-On problems............................................................................................................... 45

Environment information ..................................................................................................................................... 45 Problem description............................................................................................................................................. 45 Solution ............................................................................................................................................................... 46

Step 1 Back up configuration.......................................................................................................................... 46 Step 2 Modify LDAP configuration on EACH node........................................................................................ 46 Step 3 Update existing role mapping on EACH node ..................................................................................... 48 Step 4 Verify local changes on EACH node ................................................................................................... 48 Step 5 Rejoin EACH node .............................................................................................................................. 49


3


This document describes how to perform a first-time installation of the current version of Dynamic Workload Console. It describes how to plan, install, configure, and uninstall the Dynamic Workload Console.

Installation considerations

Before you begin an installation, consider the following items that might apply to your specific environment.

• Only one Dynamic Workload Console can be installed on a computer.

• It will be installed as a new Tivoli Workload Automation instance

• You cannot install more than one instance of the current version of the Dynamic Workload Console on the same workstation. If you attempt to install another instance of the Dynamic Workload Console onto a workstation that already has an upgradeable version on it, you will only be able to upgrade it.

• If you plan to install the Dynamic Workload Console on already-installed Tivoli Integrated Portal, ensure that the server associated to the profile where you plan to install is active before starting the installation. Only profiles that are created as described and without customization are supported.

• You must restart the Dynamic Workload Console immediately after the installation if you plan to connect to Internet Protocol version 6 (IPv6) enabled engines.


4

Installing the Dynamic Workload Console

Perform the following steps to prepare, install the Dynamic Workload Console:

1. Check the installation prerequisites at http://www.ibm.com/support/docview.wss?rs=672&uid=swg27020800 to verify that your system is compliant.

2. Browse to the setup directory and start the installation by running the setup file. The installation wizard first checks if there is enough free space available in the Java temporary directory. If not, the installation exits, and you must increase the size of the Java temporary directory, as described in the Tivoli Workload Scheduler System Requirements Document at http://www.ibm.com/support/docview.wss?rs=672&uid=swg27019747, before rerunning the installation wizard.

3. Select the language to use while installing the Dynamic Workload Console, and follow the wizard steps by clicking Next in the welcome and accepting license.

4. When asked, choose to install a new instance of Tivoli Integrated Portal. 5. Select an installation location. Click Next. 6. Specify the user name and password of the Tivoli Integrated Portal user that you want to use as the

Dynamic Workload Console administrator. Note: The user name and password must be operating systems credentials. If the user name and password you specify do not exist, a new operating system user will be created. The User Name must be unique, 3 to 60 characters in length, and contain only the characters a-z, A-Z, 0-9, period (.), hyphen (-), underscore (_), and double-byte character set (DBCS) characters.

7. The password must be 5 to 16 characters in length and contain only the characters a-z, A-Z, 0-9, period (.), hyphen (-), and underscore (_).

8. Confirm the password and click Next 9. Choose the path where you want to install, from now on referred to as TWA_HOME or accept the default

path, and click Next. Make sure that the installation path is 32 characters or less in length and that it does not contain special characters.

10. Choose the type of installation you prefer. If you want to use the default Tivoli Integrated Portal settings, proceed with the Default Installation.

11. Check that the values displayed in the installation summary window are correct and click Install. 12. If you select the Advanced installation, specify the following port numbers for the Tivoli Integrated Portal

or accept the default values. These are embedded WebSphere Application Server ports used by Tivoli Integrated Portal:

13. When the installation completes successfully, a window opens showing links to the user interface on the Tivoli Integrated Portal. For more information, see Accessing the Dynamic Workload Console. If the


5

installation fails, the window contains the list of the items that were not installed and the location of the log file.


6

Configuring access to the Dynamic Workload Console

As soon as you finish installing the Dynamic Workload Console, you can launch it by using the link provided in the final installation panel.

However, after the installation, the administrator is the only user who can log into the console, using the credentials specified during the installation.

There are some important steps an administrator may want to perform before other users can log into and use the Dynamic Workload Console:

� Configuring Dynamic Workload Console to use Single Sign-On

� Configuring LDAP with Microsoft Windows Active Directory

� Configuring the use of Lightweight Third-Party Authentication (LTPA token-keys)

� Configuring roles to access the Dynamic Workload Console

� Configuring High Availability for the Dynamic Workload Console

For more information about configuration, see "Configuring the Dynamic Workload Console" in the Tivoli Workload Scheduler: Administration Guide: http://publib.boulder.ibm.com/infocenter/tivihelp/v47r1/index.jsp?topic=%2Fcom.ibm.tivoli.itws.doc_8.6%2Fawsadconfigtdwc.htm

Configuring Dynamic Workload Console to use Single Sign-On Single Sign-On (SSO) is a method of access control that allows a user to authenticate once and gain access the resources of multiple applications sharing the same user registry.

This means that using SSO you can run queries on the plan or manage object definitions on the database accessing the engine without authenticating, automatically using the same credentials you used to login to the Dynamic Workload Console.

After the installation completes you can configure Dynamic Workload Console and the Tivoli Workload Scheduler engine to use SSO. To do this they must share the same LDAP user registry.

The Lightweight Directory Access Protocol (LDAP) is an application protocol for querying and modifying directory services running over TCP/IP - see Configuring authentication for more details.

Note: To configure Single Sign-On between a Dynamic Workload Console 8.6 and Tivoli Workload Scheduler prior to 8.6, follow the procedure described in Configuring authentication using the Integrated Solution Console

If you configured Dynamic Workload Console to use Single Sign-On with an engine, then, the following behavior is applied:

If engine connection has the user credentials specified in its definitions

These credentials are used. This behavior regards also engine connections that are shared along with their user credentials.

If the user credentials are not specified in the engine connection

The credentials you specified when logging in to Dynamic Workload Console are used. This behavior regards also shared engine connections having unshared user credentials.

To complete the task, you must follow the procedure described in Configuring LDAP with Microsoft Windows Active Directory


8

Configuring LDAP with Microsoft Windows Active Directory This section describes how to configure authentication using LDAP (Lightweight Directory Access Protocol).

Configuring authentication using the Integrated Solution Console

On each instance of the embedded WebSphere® Application Server where you want to modify the default authentication configuration you open the Integrated Solution Console and select to configure Global Security. You choose and configure the authentication mechanism or mechanisms you use in your environment. The Integrated Solution Console is the administration interface of the Dynamic Workload Console that is automatically installed with every instance of the embedded WebSphere® Application Server. Use it to configure authentication as follows:

14. Backup the WebSphere Application Server configuration: a. Stop the WebSphere Application Server by using the command:

on Windows: <TWA_home>\wastools\stopWas.bat on UNIX and Linux <TWA_home>/wastools/stopWas.sh

b. Perform the backup by using the command: on Windows: <TWA_home>\wastools\backupConfig.bat on UNIX and Linux <TWA_home>/wastools/backupConfig.sh

c. Restart the WebSphere Application Server by using the command: on Windows <TWA_home>\wastools\startWas.bat on UNIX and Linux <TWA_home>/wastools/startWas.sh

1. Access The Integrated Solution Console using one of the following URLs:

https://<Hostname>:<adminSecurePort>/ibm/console/ http://<Hostname>:<adminPort>/ibm/console/

where: Hostname The fully qualified hostname or the IP address of the computer. adminSecurePort

If you connect with HTTPS, supply the WebSphere Application Server Administration secure port, the default value of which is 29043.

adminPort If you connect with HTTP, supply the WebSphere Application Server Administration port, the default value of which is 29060.

Example https://mypc29043/ibm/console/

Log into the console using the WebSphere Administration Server credentials. You supplied these when you installed the component on this system (they might have been modified since then).

2. Launch the administrative console:

3. Navigate to the security section: select Security ► Global security


9

4. Configure your required authentication mechanism or mechanisms:

In the User account repository section you will see the default Federated repositories option selected. Click the adjacent Configure button. Use the Integrated Solution Console to configure your authentication mechanism or mechanisms. Note: When you modify the rows in the Repositories in the realm table:

• Do not delete the value InternalFileRepository corresponding to the Repository Identifier column.

• Do not delete the TwaPAM entry until you have performed all the configuration steps. For example, click Add Base entry to Realm ... to add a new repository, such as LDAP. Use the built-in context-sensitive help to understand what information to supply in each field. In addition, all the key/value pairs output by the showSecurityProperties tool are documented in Security properties: reference http://publib.boulder.ibm.com/infocenter/tivihelp/v47r1/index.jsp?topic=%2Fcom.ibm.tivoli.itws.doc_8.6%2Fawsadsecurityprops.htm. Each key/value pair corresponds to a field or concept expressed in the GUI of the Integrated Solutions Console; the keys are mnemonic, to help you make the correspondence.

5. If you plan to configure a Dynamic Workload Console 8.6 in Single Sign-On with a Tivoli Workload Scheduler prior to 8.6, set the Distinguished name of a base entry fields with the same values, as shown in the picture below:


10

6. Click Save to save the new configuration.

7. Stop and restart the application server using the commands shown at step 14. with the original WebSphere administrator credentials.

8. Log into the Dynamic Workload Console:

http://dynamic_workload_console_system:http_port/ibm/console 15. https://dynamic_workload_console_system:https_port/ibm/console 16. by using the WebSphere Administration Server credentials (the original administrative user). 17. Assign the following roles) to the primary administrative user name (the new administrative user).

• Iscadmins

• TDWBAdministrator

• TWSWEBUIAdministrator Now, you can log into the Dynamic Workload Console as the new administrative user and delete the twaPAM entry from the repository, if you do not need it anymore.

Configuring the use of Lightweight Third-Party Authentication (LTPA token-keys) In addition to sharing the same LDAP user registry, the instance of WebSphere Application Server that supports the Dynamic Workload Console and also the instance which supports the engine where the Single Sign-On is required, must both be configured to use the same Lightweight Third-Party Authentication token-keys.

The WebSphere Application Server uses the Lightweight Third-Party Authentication (LTPA) mechanism to propagate user credentials.

Configuring for Single Sign-On, between any version of Dynamic Workload Console and any engine, whether or not they are installed on the same system, you must configure both instances of WebSphere Application Server involved to use the same LTPA token_keys, and disable their automatic regeneration on expiry, following the procedures described below.

Configuring to use the same LTPA token_keys

To use the same LTPA token_keys between WebSphere Application Servers, you must run this procedure between Dynamic Workload Console and each engine you want to connect to.

The LTPA token_keys can be either exported from Dynamic Workload Console and imported into the engine, or exported from the engine and imported into Dynamic Workload Console.

1. Use the following script to export the LTPA token_keys from the WebSphere Application Server where the Dynamic Workload Console is installed, and to import them into the other instance of WebSphere Application Server: <TWA_home>/wastools/manage_ltpa.sh or ...\manage_ltpa.bat

There is also a copy of manage_ltpa.sh and manage_ltpa.bat on each installation image.

Make sure that the user who runs this script is allowed to access the WebSphere Application Server profile that hosts the Dynamic Workload Console or the engine.

The syntax used to run the script is the following: manage_ltpa -operation import|export -profilepath profile_path -ltpafile LTPA_file_path -ltpapassword LTPA_file_password -user username -password password -port SOAP_port -server server_name

where: –operation Select export to read the LTPA token_keys from the profile and save it to a file. Select import to update the profile with the LTPA token_keys stored in a file. –profilepath Specify the path to the profile on top of which the application, either Dynamic Workload Console or Tivoli Workload Scheduler is installed. –ltpafile Specify the fully qualified path name of the file that contains, if you import, or where to encrypt, if you export, the LTPA token_keys. -ltpapassword Specify a password of your choice to encrypt the file that contains the LTPA keys when exporting them, or, when importing them, the password that was used to encrypt them when they were exported. This password is used only when importing and exporting that LTPA token_keys. It does not need to match the


11

administrator password. –user The administrator of the server hosting the Dynamic Workload Console or the engine. In the case of Tivoli Workload Scheduler, the administrator is, by default, the owner of the instance (TWS_user). –password The password of the administrator of the server defined in the selected profile. –port Specify the SOAP port used by the profile. By default the SOAP port is 28880 for Dynamic Workload Console installed on the embedded WebSphere Application Server, and 31118 for Tivoli Workload Scheduler installed on the embedded WebSphere Application Server. –server Specify the name of the server of the profile on which to import or export the LTPA tokens. The default server name varies, depending on how it was installed. See the table below.

Notes:

The server and path might have been modified from the default value after installation.

This keyword is mandatory if the Tivoli Workload Scheduler server name is different from the Dynamic Workload Console server name.

Product Version

WebSphere Application Server

version

Default server name

The embedded WebSphere Application Server installed in an instance of Tivoli Workload Automation (on which any Tivoli Workload Scheduler component, including the Dynamic Workload Console is installed).

twaserver<n>, found in the following path:

<TWA_home>/eWAS/profiles/TIPProfile/config/cells/

DefaultNode/nodes/DefaultNode/servers

Tivoli Workload Scheduler, V8.5 and 8.5.1

Your external version of the WebSphere Application Server, on which the Dynamic Workload Console is installed.

server1 ,found in the appropriate path of your external version of WebSphere Application Server

2. Stop and start each server involved in this activity to enable it, as described at step 1.a. and 1.c.

3. If you are configuring Single Sign-On, test that the configuration is correctly set between and the engine by performing the following steps:

a. Log in to Dynamic Workload Console.

b. Create an engine connection without specifying User ID and password (see Quick steps to define a Tivoli Workload Scheduler engine connection).

c. Perform a test connection

Alternatively, you perform the same LTPA token import and export operations from the Integrated Solution Console:

1. Access the Integrated Solution Console, as shown in step 1,


12

2. Click Global security > LTPA link:

4. In the displayed page, enter the path filename and password to export and then import the token, click the corresponding export and Import buttons and apply your changes.

Disabling the automatic generation of LTPA token_keys

You must disable the generation of the keys at both ends of the communication, in other words, at the Dynamic Workload Console, and at the engine of Tivoli Workload Scheduler:

At the Dynamic Workload Console

1. Log in to Dynamic Workload Console.

2. Click Settings > WebSphere Administrative Console > Launch WebSphere > Administrative Console:

3. On WebSphere Administrative Console, click SSL certificate and key management.

4. Click the Key set groups link.

5. Click on the name of the key set group displayed in the list.

6. Clear the Automatically generate keys check box.

7. Click OK.

8. Check in the list that the field Automatically generate keys beside the available key set group is set to false.


13

Configuring roles to access the Dynamic Workload Console During the Dynamic Workload Console installation, new predefined roles are created in the Tivoli Integrated Portal. They determine which console panels are available to a user, and therefore which activities that user can perform from Dynamic Workload Console. If you do not assign any of the predefined roles to a user, that user, after having logged in, will not see any entry for Tivoli Workload Scheduler in the navigation tree. To create and assign roles, perform the following procedure:

1. Log into the Dynamic Workload Console, expand Users and Groups entry in Tivoli the navigation tree and click Manage Users, as displayed below:

2. After returning in the WIM User Management panel, click the new user and in the displayed panel click Groups tab:

3. Click Add to include the user in a group and Search to display a list of the available groups:

4. Select the group with the role you want to assign to the new use and click Add. The new user is now part of the selected group and has all the authorizations and accesses associated to that group.

Tip It is not necessary to assign a role to every single user. If the user registry already contains groups of users that are properly defined for using the console, it is possible to assign roles to groups too. If groups are not available in the user registry, then the special role all authenticated portal users can be used to assign roles to all the users at once. The following lists the predefined roles created in the Tivoli Integrated Portal for accessing the Tivoli Workload Scheduler environments using Dynamic Workload Console, and the actions they can do: TWSWEBUIAdministrator Users in this group can see the entire portfolio and use all features of the Dynamic Workload Console.


14

TWSWEBUIConfigurator Users in this group can manage Dynamic Workload Console scheduler connections, user preferences, and scheduling environment design. TWSWEBUIOperator Users in this group can see Dynamic Workload Console: * All Monitor tasks * Jobs and job streams to be submitted on request * Manage User Preferences TWSWEBUIDeveloper Users in this group can create, list, and edit workload definitions, workstations, and event rule definitions in the Tivoli Workload Scheduler database. TWSWEBUIAnalyst Users in this group can manage Dynamic Workload Console reports and user preferences.


15

Configuring High Availability for the Dynamic Workload Console You can configure High Availability (HA) for portal nodes with identical configurations to evenly distribute user sessions.

By leveraging HA configuration on Tivoli Integrated Portal, it is possible to meet High Availability requirements for the Dynamic Workload Console.

High Availability is ideal for Tivoli Integrated Portal installations with a large user population. When a node fails, new user sessions are directed to other active nodes. You can create a HA configuration from an existing stand-alone application server instance, but must export its data before you configure it for HA. The exported data is subsequently imported to one of the nodes so that it is replicated across the other nodes.

Workload is distributed by session, not by request. If a node 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.

Sample Topology of Dynamic Workload Console HA Configuration

A sample topology of a Dynamic Workload Console HA configuration is shown below for reference:

In this topology DB2 V9.7 FP2 is installed on a Windows machine, and a DB instance named tipdb is created from the DB2 Control Center. Make sure that DB2 supports XML. The LDAP server is already available and functional.

Two Dynamic Workload Console servers are installed on two Windows machines and one server on an AIX machine with the default options. The servers are configured to create an HA configuration after the installation.

NOTE: Install every Dynamic Workload Console server using the same user name (for example, tip21ha1)

If you plan to configure the Load Balancer to work with clusters, at installation time, remember that the http and https ports of all the Dynamic Workload Console servers to be load-balanced must be the same.

Creating Database for Tivoli Integrated Portal 2.2 HA Configuration

Before you start to configure the HA configuration, you must first create the database to use, and assign a hostname to the DB2 machine.


16

To create the database, perform the following procedure:

1. Open the DB2 Control Center, right-click All Databases, and select Create Database � Standard…:

2. The Create Database Wizard panel opens as shown below. Type “tipdb” as the database name and click

Finish to accept all default options.

When completed, the result below is shown:


17

Make the LDAP user the primary user in the HA environment

After you have configured all the Dynamic Workload Console servers to use the same LDAP server as the security repository, you must make the LDAP user, the primary administrative user.

Note: Do not use the installation user to configure the HA environment.

To make the LDAP user the primary administrative user, run the following steps:

1. Open Dynamic Workload Console and click Settings > Websphere Administrative Console > Launch WebSphere Administrative Console to open the WebSphere Application Server Administrative Console.

2. Click Security > Global Security to open the page from the Navigation panel and click Configure :

3. Modify the Primary Administrative user name to the LDAP user:


18

4. Restart the WebSphere Application Server by using the command: on Windows <TWA_home>\wastools\startWas.bat on UNIX and Linux <TWA_home>/wastools/startWas.sh

The following steps are needed only on Windows operating systems. To update the embedded WebSphere Application Server services with the new Administrative user, perform the following procedure:

a. Locate the script updateWasService.bat in the <TWA_HOME>\wastools directory

and run the following command: updateWasService -userid <username> -password <password> -wasuser <wasuser> -waspassword <waspassword>

giving the new LDAP userid as the <WAS_user>

and the new LDAP password as the <WAS_user_password>.

Example, updateWasService.bat -userid tip21ha1 -password tip21ha1 -wasuser newwasuser -waspassword newwaspwd

b. Stop WebSphere Application Server using the command: stopWas.bat -direct -user ldapuser -password ldpapwd

(locate the stopWas.bat in <TWA_HOME>\wastools directory) c. Start WebSphere Application Server using the command: startWas.bat

(locate the startWas.bat in <TWA_HOME>\wastools directory) When you have configured all the Dynamic Workload Console servers to use the same LDAP server as the security repository, you can enable the HA feature for Dynamic Workload Console using the LDAP user previously granted.

Enabling HA for Tivoli Integrated Portal 2.2

NOTE: The Tivoli Integrated Portal server cluster must be configured using DB2 without an SSL connection. If you need to configure an SSL connection, you can enable it only after having successfully enabled the HA, as described in Enable SSL for Tivoli Integrated Portal Server . To enable HA for Tivoli Integrated Portal server you must perform the following steps:

1. Creating a new HA Cluster 2. Joining servers to the existing HA cluster 3. Enabling server-to-server trust between all Tivoli Integrated Portal 2.2 servers

Creating a new HA Cluster

This task initializes the database created and enables the Tivoli Integrated Portal 2.2 server to use the database as


19

the master repository instead of using local files.

Note: If you want Tivoli Integrated Portal to access the database repository with a user without database administrator privileges, you must create a new DB2 user, give the CONNECT,CREATETAB,LOAD permissions to the new user, and run the following steps using this new user.

1. Edit tipha.properties to fill in the correct values.

tipha.properties is located in the <TWA_HOME>\eWAS\profiles\TIPProfile\bin\ha directory.

Open the file with a text editor and provide the correct values for all the properties.

Example:

##############################################################################

##############

# High Availability DB2 Database and Datasource Properties ############################################################################################ ################################################################### # Host name of DB2 server # Example: DBHost=tipdb.ibm.com # DBHost=@hostname ################################################################### # Port opened for DB connections # Default: 50000 # DBPort=50000 ################################################################### # Database name for TIP HA # Example: DBName=tipdb # DBName=@DB_name ################################################################### # Class name of DB provider # Default for DB2 V9.x: com.ibm.db2.jcc.DB2Driver # DBProviderClass=com.ibm.db2.jcc.DB2Driver ################################################################### # DB provider name # Default for DB2 V9.x: TIP_Universal_JDBC_Driver # DBProviderName=TIP_Universal_JDBC_Driver ################################################################### # JNDI name of datasource used for TIP HA # Exmaple: DBDatasource=jdbc/tipds # DBDatasource=@datasource_JNDI_name ################################################################### # Name of the datasource used for TIP HA # Example: DBDatasourceName=tipds # DBDatasourceName=@datasource_name ################################################################### # DB2 Helper class name


20

# Default for DB2 V9.x: com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper # DBHelperClassName=com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper ################################################################### # DB2 datasource implementation class name # Default for DB2 V9.x: com.ibm.db2.jcc.DB2ConnectionPoolDataSource # DBDsImplClassName=com.ibm.db2.jcc.DB2ConnectionPoolDataSource ################################################################### # WebSphere environment variable name for DB2 JDBC driver class path # Example: DBDriverVarName=TIP_JDBC_DRIVER_PATH # DBDriverVarName=TIP_JDBC_DRIVER_PATH ################################################################### # Directory of DB2 JDBC driver libraries. # pay attention to use “/” specifying windows path # Example: DBJDBCDriverPath=C:/IBM/tivoli/tip/universalDriver/lib # DBJDBCDriverPath=@jdbc_lib_path ################################################################### # JDBC driver type. # Default for DB2 V9.x: 4 # DBDriverType=4 ################################################################### # Database type # Default: DB2 # DBType=DB2 ################################################################### # JAAS alias name used to store database username and password # Example: JaasAliaseName=TIPAlias # JaasAliaseName=TIPAlias ################################################################### # Description for JAAS alias name # Example: JaasAliasDesc=TIP JAAS Alias used for High Availability # JaasAliasDesc=TIP JAAS Alias used for High Availability ############################################################################################ # High Availability Local Node Properties ############################################################################################ ################################################################### # Hostname of local TIP node # Exmpale: LocalHost=tip01.ibm.com LocalHost=@localhost ################################################################### # TIP SSL port (HTTPs port) # Default value: 29443 # Note: When Dynamic Workload Console is installed with # default ports, the value of this property in tipha.properties # must be 29443. LocalPort=@localport


21

################################################################### # TIP install path # Example: WasRoot=C:/IBM/tivoli/tip # pay attention to use “/” specifying windows path # WasRoot=@TIP_install_path ################################################################### # TIP profile name # Example: ProfileName=TIPProfile # ProfileName=@TIP_profile_name ################################################################### # TIP cell name # Example: CellName=TIPCell # CellName=@TIP_cell_name ################################################################### # TIP node name # Example: NodeName=TIPNode # NodeName=@TIP_node_name ################################################################### # WAS server name # Default: server1 # ServerName=server1 ################################################################### # TIP enterprise application name. TIP enterprise application is installed in # directory # ${WAS_ROOT}\profiles\${ProfileName}\installedApps\${CellName}\${IscAppName}.ear # Default value: isc # IscAppName=isc ################################################################### #High Availability Logging #Change the next line if you want to enable logging into file and console, e.g. # LoggerLevel=FINER # LoggerLevel=OFF ################################################################### #High Availability Status #Do not edit the value manually. #It is used to decide whether HA is enabled or not # HAEnabled=false

2. Initialize HA Cluster:

a) Stop the Websphere Application Server, using the LDAP user to stop the service: On UNIX systems:

./stopWas.sh –direct –user LDAPuser –password LDAPpwd On Windows systems:

stopWas.bat. –direct –user LDAPuser –password LDAPpwd

b) Open a command line, and

On Windows systems, change the directory to

<TWA_HOME>\eWAS\profiles\TIPProfile\bin\ha, and run the command:

..\ws_ant.bat -f install.ant configHA -Dusername=<dbUsername> -


22

Dpassword=<dbPassword>

On UNIX systems, change the directory to ${tip_profile}/bin/ha, and run the command:

../ws_ant.sh -f install.ant configHA -Dusername==<dbUsername> -

Dpassword=<dbPassword>

An example is shown below:

Start the WebSphere Application Server if the step above completes successfully.

Joining servers to the existing HA cluster

To join any other Tivoli Integrated Portal 2.2 servers to the HA cluster created in the previous section, the

configuration steps are the same as those described above.

Enabling server-to-server trust between all Tivoli Integrated Portal 2.2 servers

For every two Tivoli Integrated Portal 2.2 servers in the cluster, you must enable the trust between them before the HA feature can work. Every Tivoli Integrated Portal 2.2 server in the cluster must be configured to trust all other servers in the cluster. For every Tivoli Integrated Portal 2.2 server in the cluster, perform the steps below to enable mutual trust:

1. Update file ssl.client.props in the <TWA_HOME>\eWAS\profiles\TIPProfile\properties

directory.

Uncomment the following lines in the file:

#com.ibm.ssl.alias=AnotherSSLSettings

#com.ibm.ssl.protocol=SSL_TLS

#com.ibm.ssl.securityLevel=HIGH

#com.ibm.ssl.trustManager=IbmX509

#com.ibm.ssl.keyManager=IbmX509

#com.ibm.ssl.contextProvider=IBMJSSE2

#com.ibm.ssl.enableSignerExchangePrompt=true

Uncomment and modify the following lines in the file: #com.ibm.ssl.trustStoreName=AnotherTrustStore #com.ibm.ssl.trustStore=${user.root}/etc/trust.p12 #com.ibm.ssl.trustStorePassword={xor}CDo9Hgw= #com.ibm.ssl.trustStoreType=PKCS12 #com.ibm.ssl.trustStoreProvider=IBMJCE #com.ibm.ssl.trustStoreFileBased=true #com.ibm.ssl.trustStoreReadOnly=false

with the following values: com.ibm.ssl.trustStore=${user.root}/etc/trust.p12 to ${USER_INSTALL_ROOT}/etc/TWSClientTrustFile.jks com.ibm.ssl.trustStorePassword={xor}CDo9Hgw= to {xor}Ozo5PiozKw== com.ibm.ssl.trustStoreType=PKCS12 to JKS For example: com.ibm.ssl.trustStore=/opt/IBM/DWC_CAT/eWAS/profiles/TIPProfile/etc/TWSClientTrustFile.jks com.ibm.ssl.trustStorePassword={xor}Ozo5PiozKw==

com.ibm.ssl.trustStoreType=JKS


23

Note: This is a valid example if default Tivoli Workload Scheduler certificates have been used.

2. Stop and restart the Tivoli Integrated Portal 2.2 server if it is running.

Note: Do not start next step until previous steps have been completed on every Tivoli Integrated Portal 2.2 machine.

3. On every Tivoli Integrated Portal 2.2 machine, open a command line, change the directory to <TWA_HOME>\eWAS\bin, and run the command:

On Windows systems: retrieveSigners.bat NodeDefaultTrustStore AnotherTrustStore -host <remote server

address> -port <SOAP_PORT>”

On UNIX systems: ./retrieveSigners.sh NodeDefaultTrustStore AnotherTrustStore -host <remote server address> -port <SOAP_PORT> for every <remote server address> to add signers of other Tivoli Integrated Portal 2.2 servers to the local trust store.

The <remote server address> is the hostname of another Tivoli Integrated Portal 2.2 machine and –port is the SOAP PORT (default = 28880)

Verifying the configuration

This section describes how you can ensure successful configuration:

• The database used for the Tivoli Integrated Portal 2.2 HA cluster is correctly created and initialized.

• Every Tivoli Integrated Portal 2.2 server in the cluster uses the database as the repository instead of a local file system.

• Server-to-server trust is correctly enabled between every two Tivoli Integrated Portal 2.2 servers in the cluster.

To simply and quickly verify the configuration perform the following steps:

1. Keep all Tivoli Integrated Portal 2.2 servers in the HA cluster running. 2. Open an internet browser window to access one of the Dynamic Workload Console servers in the cluster,

click My Startup Pages, create a new View, and save the changes. 3. Open another internet browser window to access another Dynamic Workload Console server in the

cluster, and the new view created in step2 should be available on this server .


24

HA Configuration example with Cisco ACE The following sections describe an example of Dynamic Workload Console in HA configuration using Cisco ACE Application Control Engine Module. Load balancing with source NAT is configured so that traffic on the client VLAN that enters the Application Control Engine (ACE) is sent out the same VLAN to the servers using source Network Address Translation (NAT).

Configuration Design

Clients send requests to the application servers which are routed to the virtual IP address on the ACE. The VIP is associated to the Admin context of the ACE in this example. Client requests that arrive at the ACE will be routed to the servers using round-robin load balancing. There are several algorithms that can be used to balance traffic to the servers. With the IP address of the destination server in place the ACE will then replace the source IP address with one from the NAT pool. With this done, the ACE will send the request out to the server. For the return from the server, the NAT IP address will then be replaced with the VIP address and then the request will be routed to the originating client.

Configuration

1. The ACE operates in a deny any mode so as a first step, configure an access control list (ACL) that permits traffic to flow thru the ACE. In the example below all traffic is permitted but in a production

implementation, the ACL should only permit traffic that needs to be allowed thru the ACE. access-list everyone line 8 extended permit ip any any access-list everyone line 16 extended permit icmp any any

2. This ACL is then applied to the interface:

interface vlan 51 description Client side connectivity ip address 172.31.230.162 255.255.255.0 access-group input everyone service-policy input REMOTE_MGMT_ALLOW_POLICY no shutdown

3. The real servers (application servers) must be defined. The convenience of defining servers in this manner allows users to take application servers out of service for maintenance or other reasons by simply

issuing a “no inservice” command for that server. rserver host server_two ip address 9.168.4.249 inservice rserver host server_rtp ip address 9.42.48.165 inservice

4. These servers are then collected into a serverfarm. Load balancing is applied against serverfarms in the ACE.

serverfarm host TDWC_server

rserver server_two

inservice

rserver server_rtp


25

inservice

5. Use of a class-map helps identify the traffic destination for the clients. In this example all traffic is matched making this a layer 3 class-map. Matching only HTTP traffic for example would then characterize this as a Layer 4 class-map (match virtual-address 172.31.230.149 tcp eq 80).

class-map match-all DEST_SERVER 2 match virtual-address 172.31.230.149 any

6. To prevent TCP resets from closing the connection and losing the authenticated session, the ACE is configured to persist this connection based on IP address with the use of “stickiness”. Once a connection is established between the client and real server, this connection is maintained until a session timeout occurs (configurable) or the client closes the connection.

a. First the context needs to be instructed that it will be using sticky resources and the desired amount of sticky entries are allocated to the context.

context Admin member stickieness resource-class stickieness limit-resource all minimum 0.00 maximum unlimited limit-resource sticky minimum 10.00 maximum equal-to-min

b. Then session persistence is defined with the sticky command. Here IP address is the means to

ensure that the session stays connected. sticky ip-netmask 255.255.255.0 address both ip_sticky timeout 720 serverfarm TDWC_server

7. Use of a policy-map will create the action to send the traffic to the serverfarm.

policy-map type loadbalance first-match COMPRESS-TDWC class class-default sticky-serverfarm ip_sticky

The ACE uses a multi-match policy-map to bring together the L3 collection and load balancing actions. Additionally the NAT statement directs the ACE to apply NAT to the client requests. policy-map multi-match L3-7_compress class DEST_SERVER loadbalance vip inservice loadbalance policy COMPRESS-TDWC loadbalance vip icmp-reply active loadbalance vip advertise active nat dynamic 100 vlan 51

8. The NAT pool is defined at the interface (highlighted below) with this configuration statement. In the

example below, only a single address was used for the pool. Implementations with larger numbers of clients and servers would require a larger pool, but not huge as we are using port translation to minimize the impact on IP address use.

interface vlan 51 description Client side connectivity ip address 172.31.230.162 255.255.255.0 no normalization no icmp-guard access-group input everyone nat-pool 100 172.31.230.150 172.31.230.150 netmask 255.255.255.255 pat service-policy input REMOTE_MGMT_ALLOW_POLICY no shutdown

9. Finally a service-policy is applied to “implement” the load balancing scenario. This was applied in a global manner but it can be applied to the interface as well.

service-policy input L3-7_compress

Configure Dynamic Workload Console to use DB2

After configuring Load Balancer and Tivoli Integrated Portal (Dynamic Workload Console) to work in High Availability mode, you can configure all the Dynamic Workload Console instances to use the database as the settings repository, to have all the consoles share the same settings, thus providing high scalability and availability.


26

Creating a database for a Dynamic Workload Console HA cluster

To create the database used as repository for the Dynamic Workload Consoles, open the DB2 control center, right-click All Databases > Create Database > Standard… Note: For Dynamic Workload Console, you can use the same database created for Tivoli Integrated Portal 2.2, but

it is recommended that you use a different one.

The Create Database Wizard opens. Type the database name and click Finish to accept all default options.

To perform these tasks you need the TWSWEBUIAdministrator role.

Configuring SSL between DB2 and Dynamic Workload Console (optional)

To set up your DB2 server for SSL support, log in as the DB2 instance owner and set the following configuration parameters and the DB2COMM registry variable. Use the db2 update dbm cfg parameter_name using parameter_value command, where parameter_name is the name of the parameter to be set. parameter_value is the value of the parameter to be set.

1. Set the ssl_svr_keydb configuration parameter to the fully qualified path of the key database file. For example:

C:\TWS\installations\tws850cli\TWS\ssl\gskit\TWSClientKeyStore.kdb where:

TWSClientKeyStore.kdb

is the fully-qualified file name of the KeyStore that stores the DB2 certificate, and the trusted certificates.

Note that it must be recognized by the JKS WebSphere Application Server certificate. If ssl_svr_keydb is null (unset), SSL support is not enabled.

2. Set the ssl_svr_stash configuration parameter to the fully qualified path of the stash file. For example,

C:\TWS\installations\tws850cli\TWS\ssl\gskit\TWSClientKeyStore.sth

If ssl_svr_stash is null (unset), SSL support is not enabled.

3. Set the ssl_svr_label configuration parameter to the label of the digital certificate of the server.


27

If ssl_svr_label is not set, the default certificate in the key database is used. If there is no default certificate in the key database, SSL is not enabled. For example, client.

4. Set the ssl_svcename configuration parameter to the port that the DB2 database system listens on for SSL

connections. If TCP/IP and SSL are both enabled (the DB2COMM registry variable is set to TCPIP, SSL), set ssl_svcename to a different port from the port to which svcename is set. The svcename configuration parameter sets the port that the DB2 database system listens on for TCP/IP connections. If you set ssl_svcename to the same port as svcename, neither TCP/IP or SSL are enabled. If ssl_svcename is null (unset), SSL support is not enabled.

Note: When the DB2COMM registry variable is set to TCPIP,SSL, if TCPIP support is not properly enabled, for example, due to the svcename configuration parameter being set to null, the error SQL5043N is returned and SSL support is not enabled.

5. Add the value SSL to the DB2COMM registry variable. For example:

db2set -i db2inst1 DB2COMM=SSL The database manager can support multiple protocols at the same time. For example, to enable both TCP/IP and SSL communication protocols: db2set -i db2inst1 DB2COMM=SSL,TCPIP where: db2inst1 is the DB2 instance name.

6. Restart the DB2 instance. For example: db2stop db2start

Enable SSL for Tivoli Integrated Portal Server

Note: These steps must be run only after having successfully configured Tivoli Integrated Portal server HA without SSL connection. To enable SSL for Tivoli Integrated Portal server, run the following steps:

1. Open a command line, change dir to {TWA_HOME}\wastools, and run the command below: On Windows systems:

changeTIPDatasource.bat <datasourceName> <useSsl> <portNumber>

On UNIX systems: ./ changeTIPDatasource.sh <datasourceName> <useSsl> <portNumber>

where:

< datasourceName > is the JNDI name of the datasource used for TIP HA (specified in tipha.properties. For example, DBDatasource=jdbc/tipds) < useSsl > can be true or false. Specify true to enable SSL <portNumber> specifies the SSL port number (the same value specified in ssl_svcename parameter) Example:

./changeTIPDatasource.sh tipds true 60000


Creating datasource

1. Edit TDWCDatasource.properties to fill in the correct values (the connection parameters to the created

DB). TDWCDatasource.properties is located in directory <TWA_HOME>\wastools. A sample is

provided here for reference:

################################# # Datasource properties template #################################


28

# Host name of the server on which the DB2 is installed databaseServerName=localhost # Port used by DB2 databasePort=50000 # Name of the database to use (must exist) databaseName=TDWC # If true, when a JDBC provider with provided name is found in the configuration, it is deleted and re-created. # type in “true” just the first time you create the datasource deleteAndRecreate=false ################################# # Optional properties ################################# # Use SSL connection (FIPS mode). If true, secure connection socket is used to communicate with DB2 (default false) #useSslConnection=false # JNDI name to associate with datasource (to be specified in the DWC configuration) #datasourceJndiName=jdbc/TDWC # Name of the Websphere JBDC provider to create #providerName=tdwcDriver # Name of the datasource to create #datasourceName=tdwcDatasource # Name of the Websphere node on which is running the DWC. #nodeName=TIPNode ################################# # Connection pool properties # # These properties are optional. # # Look at "connection pool" settings on WAS infocenter for more info # http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/udat_conpoolset.html ################################# #connectionTimeout = 180 #maxConnections = 20 #minConnections=1 #reapTime=180 #unusedTimeout=1800 #agedTimeout=0 #purgePolicy=EntirePool

2. Open a command line, change directory to <TWA_HOME>\wastools, and run the command below to create

the data source: On Windows systems: installTDWCDataSource.bat TDWCDatasource.properties On UNIX systems: ./installTDWCDataSource.sh TDWCDatasource.properties 3. Restart WebSphere Application Server by using the command:

on Windows <TWA_home>\wastools\startWas.bat on UNIX and Linux <TWA_home>/wastools/startWas.sh.

Creating datasource on the other Dynamic Workload Console instances

Because the TDWCDatasource.properties file is a local file, you must edit it and run the above steps on all the Dynamic Workload Console instances.


29

Changing the settings repository on the Dynamic Workload Console

You need to have access to an installed DB2 where a database has already been created. If you need information about how to create a DB2 database, see IBM DB2 Database for Linux, UNIX, and Windows

Information Center.

User settings such as user preferences, saved tasks, and engine connections are stored in the settings repository, which by default is a local file. However, you can decide to have your settings repository on a database for all Dynamic Workload Console operations that involve user settings.

To use a database for your settings repository, you must configure the database settings, as described in the following procedure:

1. Run the wastool: a. Specify the connection details of the DB2 database in TDWCDatasource.properties file,

located in TWA_HOME\wastools directory. 2. Restart the Dynamic Workload Console. 3. Export your settings:

a. From the Dynamic Workload Console portfolio, click Settings > Manage Settings:

b. Optionally, in the Manage Settings panel, click Export Settings and save the XML file in a directory of your choice. In this way you save your user settings in a local file to load them on the database, when it becomes your settings repository.

4. Switch repository to DB2. a. In the same panel, click Configure Settings Repository > Use database as repository to

specify that settings must be saved in the database instead of in a local file. b. In the Database Settings section, specify the credentials required to connect to the database.

Note: For all the details about options and fields displayed in the panels, see the online help by clicking the question mark located at the top-right corner of each panel.

c. Optionally, you can test the connection. d. Save the new configuration.

5. Import your settings or initialize the database: a. Optionally, click Import Settings to import your user settings from the XML file to the database

repository. During the import operation, keep the default choice, which overwrites the existing settings with the new settings. Performing this step, the database is automatically initialized.

b. If you have not performed previous step, click Create Database to initialize the database.

As a result, all your existing user settings relating to current Dynamic Workload Console are saved in the database, and all the operations involving user settings are run using the settings in this repository.

Sharing user settings repository to multiple Dynamic Workload Consoles

Ensure that all the Dynamic Workload Console instances that are to share the same settings repository also use the same user registry. You must configure the database settings, as described in the following procedure:


30

1. From the Dynamic Workload Console navigation tree, click Settings > Manage Settings. 2. On the same panel, click Configure Settings Repository > Use database as settings repository to

specify that settings must be saved in the database instead of in a local file. 3. In the Database Settings section, specify the credentials required to connect to the database.

4. Optionally, you can test the connection to ensure that you can connect to the database. 5. Save the new configuration to create the db.properties file in the

<TWA_HOME>\eWAS\profiles\TIPProfile\registry. 6. Only on the first Dynamic Workload Console that you configure, click “Initialize Database” to initialize it

(click “Initialize Database” to drop and re-create the database anytime, losing the saved user preferences).

Note: To be synchronized, all Dynamic Workload Console instances must switch to DB2 configuration. If you switch one Dynamic Workload Console you must also switch the others.

You can now connect to Dynamic Workload Consoles configured to use DB2, by accessing the load balancer link.

Changing user of DB repository (optional)

If you want the Dynamic Workload Console to access the database repository with a user without database administrator privileges, you must perform the following procedure: Note: There is currently no official Tivoli Integrated Portal procedure to change the Tivoli Integrated Portal DB user, but you can change it by following these steps:

1. Create a new DB2 user 2. Create a new database and give the CONNECT,CREATETAB,LOAD permissions to the new user:

For example, db2 GRANT CONNECT,CREATETAB,LOAD ON DATABASE TO USER db2user2 These are the default permissions. However, if you need to restrict your policy, you can give the following permissions to the new db2user:

revoke connect,bindadd, createtab, implicit_schema on database from public; revoke use of tablespace USERSPACE1 from public; grant use of tablespace userspace1 to user twsdb2; grant createtab on database to user twsdb2; grant implicit_schema on database to user twsdb2; grant connect on database to user twsdb2;

On each TIP node, reconfigure the high availability system by following the steps in Enabling HA for Tivoli Integrated Portal 2.2, changing the parameters in tipha.properties file with the new information. For example, if the new database name is tipdb2, it is sufficient to set only the properties below:


31

DBName=tipdb2 DBDatasource=jdbc/tipds2 DBDatasourceName=tipds2 HAEnabled=false Also run the ws.ant script specifying the new DB2 user: For example, ../ws_ant.sh -f install.ant configHA -Dusername=db2user2 -Dpassword=<pass>

Configure Load Balancer to work with multiple Tivoli Workload Scheduler for z/OS servers:

To have load balancing in a z/OS environment and distribute the workload across multiple Dynamic Workload Console and multiple Tivoli Workload Scheduler for z/OS servers, follow the steps below. Note: These steps can be run only after having completed the Load Balancer configuration.

1. Install the Tivoli Workload Scheduler for z/OS Connector sharing Websphere Application Server with Dynamic Workload Console already installed. Note: During the installation, use the same ports and the same user names on each node.

2. On each Tivoli Workload Scheduler for z/OS Connector, create an engine using the same name for the engine (for example, ZCL1), the same hostname but different port numbers, so that the connections point to different Tivoli Workload Scheduler z/OS servers for the same controller. In <TWA_HOME>\wastools folder locale and run the createZosEngine.sh(.createZosEngine.bat on Windows) script to create the connection as follows:

./createZosEngine.sh -name ZCL1 -hostName x.xxx.xxx.xx -portNumber 3446 Repeat this operation with a different engine name to create additional connections if you want to connect to multiple Controllers. When you finish, each connector has the same set of engines defined, with all engines using the same name pointing to the same controller via a different server.

3. Using one of the Dynamic Workload Consoles, create an engine connection specifying the Remote Server Name

just defined in the connector (for example, ZCL1). In the Host Name field, specify “localhost” to use the Connector installed locally with the Dyanmic Workload Console. Define one engine connection for each engine name defined in the previous step.

In this way the load balancer routes the user to different dynamic Workload Console servers, each console uses the connector installed locally on the same WebSphere Application Server and a different Tivoli Workload Scheduler for z/OS server.


32

Getting started with the Dynamic Workload Console

After you have configured Dynamic Workload Console, this section explains how to get started with it.

When you connect to the Dynamic Workload Console, you see a navigation tree on the left with an entry for each Tivoli product installed inside the Tivoli Integrated Portal, such as, Tivoli Workload Scheduler.

You can access the Dynamic Workload Console from any computer in your environment using a web browser through both the secure HTTPS or HTTP protocol.

For an interactive overview of the product and its features, you can view several demo scenarios, available (in English only) on the product information center at the following link: https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/Tivoli%20Workload%20Scheduler/page/Media%20Gallery

Accessing the Dynamic Workload Console 18. When the installation of the Dynamic Workload Console completes successfully, a message with links to

the Integrated Solutions Console portal is displayed. 19. From a supported browser, access one of the following links provided by the installation program:

http://dynamic_workload_console_system:http_port/ibm/console 20. https://dynamic_workload_console_system:https_port/ibm/console

where: dynamic_workload_console_system

21. The hostname or IP address of the system where you installed the Dynamic Workload Console. http_port

22. The port number used to access the Dynamic Workload Console using an unsecure connection over HTTP. The default value for this port number is 29080.

23. https_port 24. The port number used to access the Dynamic Workload Console using a secure connection over HTTPS.

The default value for this port number is 29443. 25. 26. When connecting to the Tivoli Integrated Portal using an HTTPS connection, if you receive a security

alert, proceed with the Dynamic Workload Console working session. If you receive security information windows while navigating through the Tivoli Integrated Portal, choose to display nonsecure items to proceed. If you are using Internet Explorer, you can prevent these windows from opening by setting Display mixed content to Enable in the Security settings.

27. 28. In the Tivoli Integrated Portal login panel, enter the user ID and password you specified during the

installation, and click Log in. 29. 30. On the navigation tree on the left, expand the Tivoli Workload Scheduler. 31. 32. To effectively use the functions of the product, you must define connections to the Tivoli Workload

Scheduler engines. Without defining engine connections, you can perform only this limited set of operations.

33. 34. If the user ID you used to connect to the Dynamic Workload Console has been assigned a role different

from TWSWEBUIAdministrator, you will see a subset of the available panels. This subset depends on the authorizations assigned to the role associated to your user ID. For more information about access and roles, see Configuring roles to access the Dynamic Workload Console

35. 36. If the user ID you used to connect to the Dynamic Workload Console has no role assigned, you do not see

the entries for Tivoli Workload Scheduler in the Tivoli Integrated Portal navigation tree. 37. 38. For more information about configuring the Dynamic Workload Console, see

http://publib.boulder.ibm.com/infocenter/tivihelp/v47r1/index.jsp?topic=/com.ibm.tivoli.itws.doc_8.6/welcome_TWA.


33

Quick steps to define a Tivoli Workload Scheduler engine connection After logging in to the Dynamic Workload Console using the administrator userid or another userid with assigned TWSWEBUIAdministrator or TWSWEBUIConfigurator roles, use the following steps to create an engine connection to one of your supported Tivoli Workload Scheduler engines.

1. Log in to the Dynamic Workload Console

2. In the navigation tree, click Tivoli Workload Scheduler >Settings > Manage Engines:

3. In the displayed panel, click New, and in the Engine Connection Properties panel, assign a name to the engine connection and specify:

Engine Type Distributed. This is the type of the Tivoli Workload Scheduler engine to connect to. Hostname The hostname or IP address of system where the distributed engine runs. Port Number The bootstrap port number for the Tivoli Workload Scheduler engine. Default values are 31117. Userid and Password The user ID and password that are used to connect to the engine. This setting allows access to Tivoli Workload Scheduler from the Dynamic Workload Console. The authorization assigned to the user in the Tivoli Workload Scheduler security file determines the operations allowed.

4. If you want to test the connection to the Tivoli Workload Scheduler database (mandatory for managing reporting and event management functions), you must select Enable reporting and specify the user credentials.

5. Click Test Connection to check that the configuration was successful and that the Dynamic Workload Console is communicating with the selected engine. If the test connection fails, see Tivoli Workload Scheduler: Troubleshooting Guide: http://9.168.82.32:9872/help/index.jsp?topic=/com.ibm.tivoli.itws.doc_8.6/awstrtroublesciot.htm


34

Uninstalling the Dynamic Workload Console version 8.6 automatically

To uninstall the Dynamic Workload Console using the wizard, perform the following steps:

1. Log into the Dynamic Workload Console.

2. Start the uninstall as follows:

On Windows operating system:

Perform one of the following:

• From the TWA_home\TDWC directory, run the command:

uninstall.bat

• From the Control Panel >Add/Remove Programs, scroll down the list of software, and select the Dynamic Workload Console. Click Change/Remove.

On UNIX operating systems:

From the TWA_home/TDWC directory, run the command:

uninstall.sh

3. Select the language.

4. Click Next in the Dynamic Workload Console uninstall welcome window.

5. Provide the external or embedded WebSphere Application Server administrator user name and password, and click Next.

6. In the uninstall summary window, check that the directory from where the product is to be removed and the features to be removed are correct, and then click Uninstall. Both the Dynamic Workload Console and the Tivoli Integrated Portal, are uninstalled.

7. When the uninstall completes, a window showing a message about the success of the operation is displayed. Click Finish to exit the InstallShield Wizard.

Uninstalling the Dynamic Workload Console 8.6 manually

Perform the following steps to manually remove an instance of Tivoli Workload Automation that contains the Dynamic Workload Console and uses the embedded Tivoli Integrated Portal. In the case of a failed installation, you may find some of the steps are unnecessary, depending on when the installation failed.

1. Uninstall Tivoli Workload Scheduler as described in http://publib.boulder.ibm.com/infocenter/tivihelp/v47r1/index.jsp?topic=%2Fcom.ibm.tivoli.itws.doc_8.6%2Fawspimst169.htm

2. Remove the Dynamic Workload Console by performing the steps described in the procedure below. If you want to remove the Dynamic Workload Console from an instance of Tivoli Workload Automation without removing the Tivoli Workload Automation instance, contact IBM Software Support.

On Windows operating system:

1. Run the following command:

a. If you have already removed the Dynamic Workload Console, using the installation DVD or the downloaded eImages, run the following command from the \tdwc\webui\<operating_system>\scripts\ directory:

# ./clean.bat - installRoot <eWAS_installation_directory> -force true

b. If, instead, the Dynamic Workload Console is still installed but not working, run the following command from the TWA\tdwc\_tdwcutils\scripts\ directory:

# ./cleanDE.bat - installRoot <eWAS_installation_directory> -force true

2. Stop the service by running: TWA_HOME\bin\WASService -stop TIPProfile_Port_defaulthost_port

3. Remove the service by running: TWA_HOME\bin\WASService –remove


35

4. Navigate to the TWA_HOME and note the name of the ID file twainstancexxx.id. You will need this information later in the procedure.

5. Remove the directory: TWA_HOME

6. Remove the directory: C:\Program Files\Common Files\InstallShield\Universal\TDWC

7. Delete the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\e625666383dedb70850864e2a6feaa2e1371705039

8. Remove the file: %windir%\TWA\twainstancexxx.properties

9. Restart the system.

On UNIX and Linux operating systems:

1. Run the following command:

a. If you have already removed the Dynamic Workload Console, using the installation DVD or the downloaded eImages, run the following command from the /tdwc/webui/<operating_system>/scripts/ directory:

#./clean.sh - installRoot <eWAS_installation_diretory> -force true

b. If, instead, the Dynamic Workload Console is still installed but not working, run the following command from the TWA/tdwc/_tdwcutils/scripts directory:

# ./cleanDE.sh - installRoot <eWAS_installation_diretory> -force true

2. Stop the server by running the command: TWA_HOME/wastools/stopWas.sh

3. Navigate to the TWA_HOME and note the name of the ID file twainstancexxx.id. You will need this information later in the procedure.


5. Remove the directory:

On AIX /usr/lib/objrepos/InstallShield/Universal/TDWC

On all UNIX (no AIX) ROOT_USER_HOME/InstallShield/Universal/TDWC

6. Remove the file: etc/TWA/twainstancexxx.properties


36


37

Uninstalling the Dynamic Workload Console version 8.5.1 FP1

Perform the following steps to manually remove an instance of Tivoli Workload Automation that contains the Dynamic Workload Console and uses the embedded WebSphere Application Server. In the case of a failed installation, you may find some of the steps are unnecessary, depending on when the installation failed.

On Windows:

1. Stop the server by running the command: TWA_HOME\wastools\stopWas.bat

2. If you configured to start and stop the Dynamic Workload Console as a service, remove the service by running the command: cd TWA_HOME\eWAS\AppServer\bin\ wasservice.exe -remove TDWC_admin_username

3. Navigate to the TWA_HOME and take note of the name of the .id file twainstancexxx.id. You will need this information later in the procedure.


5. Remove the directory: C:\Program Files\Common Files\InstallShield\Universal\TDWC

6. Delete the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ e625666383dedb70850864e2a6feaa2e1371705039

7. Remove the file: %ProgramFiles%\TWA\twainstancexxx.properties

8. Restart the system.

On UNIX:

1. Stop the server by running the command: TWA_HOME/wastools/stopWas.sh

2. Navigate to the TWA_HOME and take note of the name of the .id file twainstancexxx.id. You will need this information later in the procedure.


4. Remove the directory:

• On AIX /usr/lib/objrepos/InstallShield/Universal/TDWC

• On all UNIX (no AIX) ROOT_USER_HOME/InstallShield/Universal/TDWC

5. Remove the file: opt/IBM/TWA/twainstancexxx.properties

To remove just the Dynamic Workload Console and leave the embedded WebSphere Application Server, perform just the following steps:

• On Windows, perform steps 5 and 6.

• On UNIX, perform step 4


38

39. 40.

Troubleshooting the installation/uninstallation

This chapter describes how to troubleshoot the installation, upgrade, and uninstallation of the Dynamic Workload Console.

Installation log files You can check the following log files for information about the installation. Details of the installation process are recorded in log files on the local computer in the following directories:

Note: The following values are valid only if you have not changed the default value of the TEMP system variable.

Windows operating system:

%Temp%\TWA\tdwc86

UNIX and Linux operating systems:

/tmp/TWA/tdwc86

The following table lists the InstallShield wizard log files:

Log file name Content

tdwcstatus.log Dynamic Workload Console installation status log file. It reports if the installation completed successfully or with errors. In case of errors it indicates if the error is due to an incorrect field value or to a failed step.

tdwcinstall.log Dynamic Workload Console installation log file.

tdwcuninstall.log Dynamic Workload Console uninstallation log file.

securityConfignnnn.log Dynamic Workload Console log file containing details about the Tivoli Integrated Portal security configuration performed during installation. The numeric value nnnn is automatically assigned. Access the tdwcinstall.log file to see the filename of the securityConfignnnn.log file.

Wsadmin.log Dynamic Workload Console log file containing details about the interaction of the installation with WebSphere Application Server.

TIPInstaller-00.log Tivoli Integrated Portal installation log file.

For multiple installations on the same workstation, the log header and footer indicate the user ID (TWS_user) for which the installation was performed.


39

Recovering a failed installation This section describes how to recover a failed interactive installation. If an operation fails during the installation, the wizard opens the following panel:

Note: Do not close the wizard panel by clicking the Close icon: Note:

If you are using the interactive wizard, do not close the wizard panel by clicking on the Close icon: . If you do, the wizard is unable to save the troubleshooting information that you need for a resume. Instead, if you are sure you want to quit the installation, click Quit installation.

You can use the debug mode of the wizard to see which steps of the installation have failed. You can correct errors that have occurred and resume those installation steps that have not completed successfully, without leaving the wizard.

You can choose to do this immediately the failure occurs, or close the window and recover the situation later.

Stopping and resuming an interactive installation

You can stop and resume an installation at any time. For example:

• The installation is running successfully but you want to pause it and resume it later

• The installation has failed and you want to reboot the computer to correct a problem To stop an interactive installation that is running click Stop. The wizard asks you if you want to quit the installation after the current step is completed. If you reply Yes, the installation completes the step being performed and then displays a summary panel of the completed activities. Click Finish to exit. To stop an installation that has just failed, select Quit installation, click Next, and confirm your decision. To stop an installation that is on the Step List window, click Cancel, and confirm your decision. To resume the installation, enter the following command: <setup_file_name> -resume

where <setup_file_name> is one of the following: Windows operating system setup.exe

UNIX and Linux operating systems SETUP.bin The InstallShield wizard recognizes that a previous installation has not completed, and the The Step List window opens. From here you can continue the previous installation at the point where it stopped. If the steps in the Step List window have no errors, you can resume the installation; otherwise you must correct the error that caused the installation steps to fail, before resuming those steps. See The Step List window for details.


40

Correcting a failed step and continuing the installation

To correct a failed step and continue the installation, use the following procedure:

1) Open the Step list window

2) Double-click a step to view its details (see: The Step window)

3) Use the Output tab to determine what problem occurred.

4) Consult the sections in this guide that describe how to resolve problems found with the installation or the help for the error message that has been displayed.

5) If the solution to the problem requires you to change one of the values that you entered in the installation wizard, consult Deciding whether to resume the wizard or rerun it and determine from the guidelines there, if you should rerun the wizard from scratch, or if it is appropriate to correct the value and resume the wizard. If the latter, follow this procedure:

1) Select the Properties tab and make the required changes. Click Apply. The error description might make reference to a property that is not available for editing in the step that failed. In this case you must do the following:

a) Close the Step window.

b) Double-click the preceding step and check if the Properties tab contains the property you require. If it does not, then close the Step window and try the next preceding step, continuing until you locate the property to change. When you find the property, change its value and then continue with the rest of the steps in this procedure, from the step that you have modified, not from the step that failed.

2) Double-click each of the other steps in the installation in turn and click the Properties tab for the step. If the step includes the property whose value you changed above, change the value of the property accordingly and click Apply. This is necessary because the step properties are not interlinked.

3) The values used in each step for the Dynamic Workload Console are all stored in one place - Step 0. So if you discover, for example, that the step that configures the embedded Tivoli Integrated Portal has failed because a port is in use, you must go to Step 0 and modify the value for the port in that step.

4) Set the status of Step 0, plus the status of the step that failed, to Ready.

5) In all cases, run Step 0 in the Step List, using the Run next option. Step 0 uses the original data, as modified by you, to regenerate all of the scripts that run the steps.

6) Resume the wizard from the failed step, either running Run all to complete the installation without stopping at each step, or Run next, to complete the installation step by step.

The Step List window

The Step List window opens either when an installation fails, or when you are resuming an installation that had previously been stopped. The following figure shows an example of the Step List window when an installation step has failed:


41

The Step List window is organized as follows: Step # The installation sequence. Description The description of the installation step. Target The workstation where the installation is being run. Status The step status. It can be one of the following: Ready The step is ready to be installed. Success The step has successfully completed. Error The step completed, but errors were detected. Held A step that prerequisites another step has failed. Do not set this state. Run next Start the next step in the list that has a status set to Ready. Run all Start, in sequence, all the steps in the list that have a status set to Ready. Stop Use this to stop the step processing while a step is being processed. The step returns to the Ready status. Stop on error If selected, stops the processing of any step or steps that you run in the event of an error. Search by status Select the status you want to view, then click Search. The step list displays the first step in the step list with the selected status. Status The status of the installation processing engine. It can be one of the following: Waiting User action is required. Running Installation of a step is in progress. Stopping After the current step, the engine stops. Searching The engine is searching for product images. Details For each status, shows the number of steps in that status. Also displays the total number of steps. For information about each individual step, double-click the step to open The Step window.


42

The Step window

If you double-click a step in the Step List window, The Step window opens. It has three tabs:

Status tab

The Status tab shows the status of the installation step (Ready, Success, Error, or Held). You can change the status from Error to Ready if the condition that caused a step to fail has been removed. This is an example of the tab:

Properties tab

The Properties tab shows the user parameters required by the step. These might be the parameters you have input in the installation wizard, or values that the wizard has determined according to the logic of its operations. This is an example of the tab:

The properties are of three types:

A command Some of the steps have properties that include a command string. This must never be edited. The command string has positional parameters and generated parameters. If you change even one character the command might fail.

Editable parameters These are parameters that are used by the step, but can be edited by you. The name of the parameter is the same as the name used on the wizard panel when you input the data.

Internal parameters These are parameters generated by the wizard. They are recognizable because you did not input them in the wizard panels. For example, the DB2 Client Flag in the above example screen is an internal flag which tells the step whether it is to install the DB2 Server or DB2 Client. These must never be edited. They might be linked to other parameters in a way that is not obvious to you.


43

Output tab

The Output tab shows the output and any errors that occurred for the installation step, and also the commands that were performed by the installation. This is an example of the tab:

The Output tab has the following entries:

Time Stamp The time that the command was run.

Return code The return code for the operation: 0 OK 1 - 9 Error

DiagRecord A unique point of failure identification. This can be quoted to IBM Software Support if you need to request assistance.

Command The command that failed.

Command output Any output from the command (such as a return code or an error message number)

Error log Shows a list of errors that occurred during the installation of the step.


44

Deciding whether to resume the wizard or rerun it

The fact that the wizard has a facility that allows you to diagnose the problem, correct it, and resume it, does not mean that you must do so. There are a number of scenarios when it is quicker to rerun the wizard, or you are surer of success by doing so. This section helps you to decide which is the best action to take. The facility to diagnose, correct, and resume a failed installation can be very useful for you, but if it is not done correctly can require more work than rerunning it. The following sections detail different installation scenarios and suggest the best way to proceed. Non-valid installation data If the wizard fails because data supplied to the wizard is not valid, you must consider which data is not valid: <TWS_user> ID or password If there are any problems with the <TWS_user> ID or password, you must quit the installation and rerun it. Many of the steps have the <TWS_user> as a property, and because many crucial factors in the installation are linked to the <TWS_user>, you must not try to change the ID and then resume. Installation directory Like the <TWS_user> ID, this is important to the installation. If the supplied value has some problem you must quit the installation and rerun it. Ports The ports used by the embedded WebSphere Application Server are checked at the moment you input them, but if one of them becomes busy by the time the wizard starts to configure the embedded WebSphere Application Server, the installation stops. In this case, you can proceed to change the value of the port being used in the step and resume the installation, because the ports are only used in one step. Database data The data relating to the configuration of the RDBMS support and the installation of the Tivoli Workload Scheduler database might be used in any or all of the database-related steps. Look at the names of the steps to determine which they are. If you change a value in one, open them all and check if the value is used in others. Other data For all other installation data, check every step to determine where the data item is being used. If in doubt, rerun the installation. Generally, if the problem occurs in one of the early steps, it is almost as quick, and generally more reliable, to rerun the installation, than correct the data and resume it. If you decide to rerun, there should be no need to clean up anything. All the data structures that are installed can be overwritten.


45

Troubleshooting Single Sign-On problems

This troubleshooting scenario explains how to solve the problem on an environment with multiple Dynamic Workload Console instances configured in cluster but a similar solution can be applied in the case of one single Dynamic Workload Console connected to Tivoli Workload Scheduler master, set up in LDAP and Single Sign-On configurations.

Environment information Dynamic Workload Console 8.6 on AIX 6.1 configuration:

� Federated Repository (LDAP Active Directory) � SSO enabled (LTPA keys taken from TWS 851 FP1 engine and imported into Dynamic Workload

Console) � High Availability (TIP/Dynamic Workload Consoles are in cluster with a common database user -

no db administrator user) TWS Master 851 FP 1 on AIX 6.1, configuration:

� Standalone LDAP Active Directory � SSO enabled (LTPA keys taken from TWS 851 FP1 engine and imported into Dynamic Workload

Console) � TWS native security authorize LDAP groups

Problem description A user logs into the Dynamic Workload Console and accesses a Tivoli Workload Scheduler engine without providing credentials, leveraging the Single Sign-On feature. However, when he tries to perform an operation on the engine (such as opening the Workload Designer to create and save a job stream) he fails because the authorization by group is rejected. Tivoli Workload Scheduler traces on WebSphere Application Server log an exception because the group to which the user belongs cannot be recognized. See the following sample exception: [1/31/12 9:20:11:403 CST] 00000032 LdapRegistryI E SECJ0340E: Could not get the uniqueId for the group CN=developers,CN=Users,o=LDAP_TIP. [1/31/12 9:20:11:420 CST] 00000032 LdapRegistryI < getUniqueGroupId Exit com.ibm.websphere.security.CustomRegistryException: No group CN=developers,CN=Users,o=twaLDAP found at com.ibm.ws.security.registry.ldap.LdapRegistryImpl.getUniqueGroupId(LdapRegistryImpl.java:697) at com.ibm.ws.security.registry.ldap.LdapRegistryImpl.getGroupSecurityName(LdapRegistryImpl.java:1134) at com.ibm.ws.security.registry.UserRegistryImpl.getGroupSecurityName(UserRegistryImpl.java:621) at com.ibm.websphere.security._UserRegistry_Stub.getGroupSecurityName(_UserRegistry_Stub.java:742) at com.ibm.tws.util.UserRegistries.getGroupName(UserRegistries.java:85) at com.ibm.tws.util.UserRegistries.getCallerGroups(UserRegistries.java:162) at com.ibm.tws.conn.model.ConnModelBean.getModelImpl(ConnModelBean.java:289) at com.ibm.tws.conn.model.ConnModelBean.addTWSObject(ConnModelBean.java:172)

Based on the error, the unrecognized group is: 'CN=developers,CN=Users,o=LDAP_TIP'

However, on the Active Directory server, the full Distinguished Name of the group developer of this example is: 'CN=developers,CN=Users,DC=TEST,DC=IT'

On the Dynamic Workload Console, the federated repository had the base entry for this Active Directory repository set as follows Distinguished name of a base entry that uniquely identifies this set of entries in the realm:,o=LDAP_TIP Distinguished name of a base entry in this repository: ,DC=TEST,DC=IT Therefore, we must replace o=LDAP_TIP with DC=TEST,DC=IT so as to correctly find the user.


46

Solution All the steps below must be performed on EACH Dynamic Workload Console node. Before taking the steps below, ensure that the LPTA keys are aligned between all the nodes (Dynamic Workload Consoles and Tivoli Workload Scheduler). This means that the LTPA key file has been exported from a WebSphere Application Server and imported into all the others (for example exported from TWS engine and imported into the Dynamic Workload Console.

Step 1 Back up configuration

1. Stop WebSphere Application Server and backup the current configuration on EACH node: a. Stop the server by using the command: ./stopWas.sh -direct -user wasprimaryadminuser -password password

b. Make a backup copy of the following directory: TWA_home/eWAS/profiles/TIPProfile/config

c. Run the command to back it up: TWA_home/wastools/backupConfig.sh 2. Run this step only in case of Dynamic Workload Console in cluster configuration.

Disjoin each node from the cluster by running the following command: ./stopWas.sh -direct -user wasprimaryadminuser -password password cd TWA_DIR/eWAS/profiles/TIPProfile/bin/ha Note: on ALL nodes of the cluster except for the last one, run:

../ws_ant.sh -f uninstall.ant disjoin -Dusername=dbuser -Dpassword=dbuserpwd

on *** LAST *** node of the cluster only, run ../ws_ant.sh -f uninstall.ant uninstall-Dusername=dbuser -Dpassword=dbuserpwd

3. Run this step only in case of Dynamic Workload Console in cluster configuration. Verify the disjoin by ensuring that Tivoli Integrated Portal tables have been dropped: Run db2 "list tables for all" | grep dbuser

where dbuser is your current database user.

Step 2 Modify LDAP configuration on EACH node

1. Restart WebSphere Application Server by using the command: on Windows: <TWA_home>\wastools\startWas.bat on UNIX and Linux: <TWA_home>/wastools/startWas.sh

2. Change the distinguished name of the base entry of the repository related to the LDAP repository and set to: LDAP base dn, For example, change o=LDAP_TIP ===> DC=TEST,DC=IT

Note: DC=TEST,DC=IT -- no space after comma

a) To perform this step, log into the Dynamic Workload Console as the primary administrator and

open WebSphere Administrative Console as follows: https://hostname:adminSecurePort/ibm/console default port is 29043 The actual port can be retrieved running: on Windows: <TWA_home>\wastools\showHostProperties.bat on UNIX and Linux <TWA_home>/wastools/showHostProperties.sh

b) Click Global Security > Federated Repository and click the name of the entry o=LDAP_TIP like in the picture below:


47

c) Edit the highlighted field by inserting DC=TEST,DC=IT

Note: DC=TEST,DC=IT -- no space after comma

d) Click Apply > Save (hyperlink) >OK.

3. From the Federated Repository configuration panel, click Supported Entity Types and modify the user and group entities. Modify the mapping to ensure that user;User and group;Group are correctly set in the Object classes.

Note: Use semicolons in the user;User and group;Group fields not colons:

4. Stop the WebSphere Application Server by using the command: on Windows: <TWA_home>\wastools\stopWas.bat on UNIX and Linux <TWA_home>/wastools/stopWas.sh


48

Step 3 Update existing role mapping on EACH node

To recover all the roles that have been assigned, you must replace all the strings o=LDAP_TIP with the LDAP base DN value:

a) Verify the exact string to replace by opening a bash shell and going to the following directory:

TWA_HOME/eWAS/profiles/TIPProfile/config/cells/TIPCell/commonauthz b) Run both the commands (with lower and upper case “o”):

find ./ -type f -exec grep -r "O=LDAP_TIP" '{}' \; find ./ -type f -exec grep -r "o=LDAP_TIP" '{}' \; One of the commands must return a result.

c) Assuming that a string with upper case “O” has been found, replace all the occurrences of the found string with the correct LDAP base DN value on all the xml files under the directory:

TWA_home/eWAS/profiles/TIPProfile/config/cells/TIPCell/commonauthz To do this run the following bash command in the above directory: Note: DC=TEST, DC=IT -- with a space after comma: for i in `find . -name "*.xml" -print`

do cat $i | sed 's/O=LDAP_TIP/DC=TEST, DC=IT/g'> /tmp/tempfile19 cp /tmp/tempfile19 $i done

d) Verify the exact string to replace by opening a bash shell and going to the following directory: TWA_HOME/eWAS/profiles/TIPProfile/config/cells/TIPCell/ and running both commands (with lower and upper case “o”): find ./ -type f -exec grep -r "O=LDAP_TIP" '{}' \; find ./ -type f -exec grep -r "o=LDAP_TIP" '{}' \; One of the commands must return a result.

e) Assuming that a string with lower case “o” has been found, replace all the occurrences of the found string with the correct LDAP base DN value on all the xml files under the directory:

TWA_HOME/eWAS/profiles/TIPProfile/config/cells/TIPCell/ All occurrences of o=LDAP_TIP must be replaced with: DC=TEST,DC=IT

Note: DC=TEST,DC=IT -- no space after comma. To do this, run the following bash command under the directory: TWA_HOME/eWAS/profiles/TIPProfile/config/cells/TIPCell cat admin-authz.xml | sed 's/o=LDAP_TIP/DC=TEST,DC=IT/g'> /tmp/tempfile1 ; cp /tmp/tempfile1 admin-authz.xml

NOTE: Verify that the usual XML header is present as first line of the file admin-authz.xml f) Verify that all the occurrences have been correctly replaced by running the following command

from the directory: TWA_HOME/eWAS/profiles/TIPProfile/config/cells/TIPCell/

run: find ./ -type f -exec grep -r "O=LDAP_TIP" '{}' \;

find ./ -type f -exec grep -r "o=LDAP_TIP" '{}' \;

The command must return no results. Verify: find ./ -type f -exec grep -r "DC=TEST,DC=IT" '{}' \; and find ./ -type f -exec grep -r "DC=TEST, DC=IT" '{}' \; The commands must return results.

Step 4 Verify local changes on EACH node


2. Log in and verify that you can log in with a previous granted LDAP user and that you can correctly access to the navigation tree.

3. Stop the WebSphere Application Server by using the command: on Windows <TWA_home>\wastools\stopWas.bat on UNIX and Linux <TWA_home>/wastools/stopWas.sh


49

Step 5 Rejoin EACH node

Perform this step only in case Dynamic Workload Console is configured in cluster

1. Rejoin EACH node to the cluster by issuing the following command: ../ws_ant.sh -f install.ant configHA -Dusername=dbuser -Dpassword=dbuserpwd

2. Only on the first rejoin of the first node, verify that Tivoli Integrated Portal tables have been created by running the following command: db2 "list tables for all" | grep dbuser

(Verify grant on the database user if needed) 3. Verify that you can log into the Dynamic Workload Console with a previous granted LDAP user and can

correctly access to the navigation tree.


50

Tivoli Workload Scheduler - ibm.com · PDF fileConfigure Load Balancer to work with multiple...

Documents

Transcript of Tivoli Workload Scheduler - ibm.com · PDF fileConfigure Load Balancer to work with multiple...