IBM WebSphere Portal V4.1 Handbook Volume 1

ibm.com/redbooks

IBM WebSphere Portal V4.1 HandbookVolume 1

Rufus CredleDenise Hendriks Hatzidakis

Sunil HiranniahGord Niguma

Dwight NorwoodRoshan Rao

Bernhard Stimpfle

Understand the IBM WebSphere Portal architecture

Step-by-step installation instructions for IBM WebSphere Portal

Front cover

Implement new and enhanced capabilities of IBM WebSphere Portal

IBM WebSphere Portal V4.1 Handbook Volume 1

January 2003

International Technical Support Organization

SG24-6883-00

© Copyright International Business Machines Corporation 2003. All rights reserved.Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADPSchedule Contract with IBM Corp.

First Edition (January 2003)

This edition applies to IBM WebSphere Application Server Advanced Edition V4.0.2, IBM SecurewayDirectory V3.2.2, IBM WebSphere Personalization V4.0, DB2 Universal Database V7.2, IBM WebSphere Studio Application Developer V4.02, and IBM WebSphere Portal for Multiplatform V4.1.2.

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

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Chapter 1. Introduction to WebSphere Portal V4.1 . . . . . . . . . . . . . . . . . . . 11.1 WebSphere Portal Enable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 WebSphere Portal Extend. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 WebSphere Portal Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Industry impact and acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2. The WebSphere Portal architecture . . . . . . . . . . . . . . . . . . . . . . 72.1 WebSphere Portal software topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 WebSphere Portal architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Operational aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 3. WebSphere Portal prerequisites and planning . . . . . . . . . . . . 193.1 WebSphere Portal offerings and CDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Portal capabilities and components . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Content of the CD set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 WebSphere Portal for Windows 2000 prerequisites . . . . . . . . . . . . . . . . . 223.2.1 Hardware requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.3 Pre-installed components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 WebSphere Portal for Linux prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . 353.3.1 Uninstall Linux LDAP package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.2 Memory requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.3 Disk space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.4 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.5 Hardware requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.6 Configuring the Linux kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4 WebSphere Portal for AIX prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . 393.4.1 Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4.2 Software level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4.3 Remote display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.4.4 Description of how to set up AIX 5.1 prerequisites . . . . . . . . . . . . . . 42

© Copyright IBM Corp. 2003. All rights reserved. iii

3.5 Deploying WebSphere Portal in a production environment. . . . . . . . . . . . 473.6 Planning: general considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.6.1 Installing the Loopback Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.6.2 Network requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.6.3 Installation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.6.4 Installation planning worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Chapter 4. WebSphere Portal Setup Manager . . . . . . . . . . . . . . . . . . . . . . 774.1 Installing with Setup Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.2 Setup Manager pre-installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.2.1 Starting with Setup Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.2 The IBMWPO directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2.3 IBM Cross Platform Technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3 Determining the type of install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.4 Installation configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.4.1 IBM HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.4.2 DB2 Universal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.4.3 IBM SecureWay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.4.4 WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.4.5 Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.4.6 WebSphere Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094.4.7 Lotus Domino Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274.4.8 Web Content Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354.4.9 Lotus Sametime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384.4.10 Lotus Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414.4.11 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

4.5 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Chapter 5. WebSphere Portal: Windows installation with Setup Manager . 147

5.1 General considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485.1.1 Prerequisites check before installation . . . . . . . . . . . . . . . . . . . . . . 1485.1.2 Installing Loopback Adapter (optional) . . . . . . . . . . . . . . . . . . . . . . 148

5.2 Installing WebSphere Portal with SecureWay using the Setup Manager 1505.2.1 Installation topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515.2.2 Starting WebSphere Portal Setup Manager . . . . . . . . . . . . . . . . . . 1515.2.3 IBM Cross Platform Technologies for Windows V2.0 . . . . . . . . . . . 1525.2.4 Secureway LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1545.2.5 IBM HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575.2.6 DB2 Universal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605.2.7 SecureWay Directory Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625.2.8 WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635.2.9 WebSphere Personalization Server . . . . . . . . . . . . . . . . . . . . . . . . 167

iv IBM WebSphere Portal V4.1 Handbook Volume 1

5.2.10 WebSphere Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685.2.11 Installation procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

5.3 Installing WebSphere Portal on Windows 2000 with Domino LDAP using the Setup Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

5.3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945.3.2 Removing Lotus Notes clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945.3.3 Installing DB2, IBM HTTP Server and WebSphere

Application Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1955.3.4 Generating keys in WebSphere Application Server . . . . . . . . . . . . 1975.3.5 Install Domino components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2015.3.6 Configuring Domino Administration client . . . . . . . . . . . . . . . . . . . . 2115.3.7 Configuring WebSphere Application Server security . . . . . . . . . . . 2195.3.8 Configuring Domino for WebSphere Portal . . . . . . . . . . . . . . . . . . . 2225.3.9 Installing WebSphere Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2385.3.10 Verifying the WebSphere portal install . . . . . . . . . . . . . . . . . . . . . 250

5.4 Installing WebSphere Portal with Active Directory using the Setup Manager251

5.4.1 WebSphere Portal with Active Directory using Setup Manager . . . 2525.5 Testing for successful installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

5.5.1 Checking the installation log file . . . . . . . . . . . . . . . . . . . . . . . . . . . 2585.5.2 Testing steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

5.6 Common installation questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2625.7 Post-installation instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

5.7.1 WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2655.7.2 SecureWay Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2665.7.3 Changing passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

5.8 Uninstalling WebSphere Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Chapter 6. WebSphere Portal: Windows manual installation . . . . . . . . . 2756.1 Installation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2766.2 Server environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2776.3 DB2 Universal Database V7.2 installation. . . . . . . . . . . . . . . . . . . . . . . . 277

6.3.1 DB2 Universal Database V7.2 Fixpack installation . . . . . . . . . . . . . 2836.4 WebSphere Application Server V4.0 and IBM HTTP Server installation 285

6.4.1 Upgrade the DB2 JDBC drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . 2936.4.2 WebSphere Application Server 4.0 FixPack2 installation . . . . . . . . 2956.4.3 IBM SecureWay V3.2.2 installation. . . . . . . . . . . . . . . . . . . . . . . . . 2986.4.4 IBM SecureWay Directory administration . . . . . . . . . . . . . . . . . . . . 3096.4.5 Importing the Portal Server LDIF file . . . . . . . . . . . . . . . . . . . . . . . . 314

6.5 WebSphere Portal install using IBM SecureWay Directory . . . . . . . . . . . 3186.5.1 Deploying base portlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

6.6 Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3626.7 WebSphere Portal install using Lotus Domino LDAP Directory . . . . . . . 370

Contents v

6.7.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3726.7.2 Begin WebSphere installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3726.7.3 Domino installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3736.7.4 Configure the Domino Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3786.7.5 Install a Domino Administration Client . . . . . . . . . . . . . . . . . . . . . . 3846.7.6 Configure the Administration client . . . . . . . . . . . . . . . . . . . . . . . . . 3906.7.7 Create required users and configuration for LDAP . . . . . . . . . . . . . 3976.7.8 Configure server for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4036.7.9 Install WebSphere Personalization . . . . . . . . . . . . . . . . . . . . . . . . . 4086.7.10 Configure Global Security on WebSphere . . . . . . . . . . . . . . . . . . 4086.7.11 Configure Single Sign-On in Domino . . . . . . . . . . . . . . . . . . . . . . 4136.7.12 Install WebSphere Portal using Domino LDAP . . . . . . . . . . . . . . . 4176.7.13 Test WebSphere with Domino LDAP . . . . . . . . . . . . . . . . . . . . . . 438

6.8 WebSphere Portal install using Microsoft Active Directory . . . . . . . . . . . 4496.8.1 Installing Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4516.8.2 Installing Windows 2000 Support and Administration tools . . . . . . 4586.8.3 Validating the domain and DNS install . . . . . . . . . . . . . . . . . . . . . . 4596.8.4 Configuring Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4616.8.5 Install WebSphere Portal using Active Directory. . . . . . . . . . . . . . . 4706.8.6 Testing considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484

Chapter 7. WebSphere Portal: Linux installation . . . . . . . . . . . . . . . . . . . 4857.1 WebSphere Portal installation overview . . . . . . . . . . . . . . . . . . . . . . . . . 4857.2 Sample two-tier installation with Setup Manager . . . . . . . . . . . . . . . . . . 486

7.2.1 Installing the LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4887.2.2 WebSphere Portal installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495

7.3 Verifying product installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5187.3.1 Checking the installation log file . . . . . . . . . . . . . . . . . . . . . . . . . . . 526

7.4 A sample single-tier installation with Setup Manager . . . . . . . . . . . . . . . 5277.5 Sample single-tier installation without

Setup Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5327.5.1 Installing and configuring DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5347.5.2 Installing and configuring Domino LDAP. . . . . . . . . . . . . . . . . . . . . 5427.5.3 Installing and configuring IBM HTTP Server . . . . . . . . . . . . . . . . . . 5497.5.4 Installing and configuring WebSphere Application Server . . . . . . . 5517.5.5 Installing and configuring WebSphere Personalization. . . . . . . . . . 5587.5.6 Installing and configuring WebSphere Portal . . . . . . . . . . . . . . . . . 560

Chapter 8. WebSphere Portal: AIX installation . . . . . . . . . . . . . . . . . . . . . 5738.1 Pre-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

8.1.1 Installation planning worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5748.1.2 Consideration for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578

8.2 WebSphere Portal installation using Setup Manager . . . . . . . . . . . . . . . 580

vi IBM WebSphere Portal V4.1 Handbook Volume 1

8.2.1 Information collection for WebSphere Portal installation. . . . . . . . . 5808.2.2 IBM HTTP Server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 5858.2.3 IBM SecureWay Directory Server configuration . . . . . . . . . . . . . . . 5868.2.4 WebSphere Application Server configuration . . . . . . . . . . . . . . . . . 5888.2.5 Personalization Server configuration . . . . . . . . . . . . . . . . . . . . . . . 5918.2.6 WebSphere Portal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 5928.2.7 Final configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6018.2.8 WebSphere Portal installation process . . . . . . . . . . . . . . . . . . . . . . 603

8.3 Post-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6108.3.1 DB2 Universal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6108.3.2 WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6158.3.3 SecureWay Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617

8.4 Installing WebSphere Portal in a non-graphical environment . . . . . . . . . 6188.4.1 Installation and setup of WebSphere Portal prerequisites . . . . . . . 6198.4.2 Silent installation of WebSphere Portal . . . . . . . . . . . . . . . . . . . . . . 6458.4.3 Required WebSphere Portal add-ons . . . . . . . . . . . . . . . . . . . . . . . 655

8.5 Changing passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6608.5.1 Change password for wpsadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 6608.5.2 Change password for wpsbind . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6618.5.3 Change password for the DB2 user wasuser . . . . . . . . . . . . . . . . . 6648.5.4 Change password for LDAP Admin user cn=ldapadmin . . . . . . . . . 6708.5.5 Change password for the users ldapdb2, ldap . . . . . . . . . . . . . . . . 6738.5.6 Change password for the users db2as, db2fenc1, db2inst1 . . . . . . 6738.5.7 Change password for the user httpd . . . . . . . . . . . . . . . . . . . . . . . . 6738.5.8 Change LTPA password of Application Server Security . . . . . . . . . 674

Chapter 9. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6759.1 Configuration of WebSphere Portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675

9.1.1 Modifying property files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6759.1.2 Managing portal logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

9.2 Improving portlet performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6809.2.1 Programming portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6809.2.2 Administration of portlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682

9.3 Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6839.4 Tuning WebSphere Portal components . . . . . . . . . . . . . . . . . . . . . . . . . 683

Chapter 10. Problem determination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68510.1 Testing your WebSphere Portal installation . . . . . . . . . . . . . . . . . . . . . 685

10.1.1 Hello World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68510.1.2 New user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

Appendix A. db2admin and wasadmin user IDs . . . . . . . . . . . . . . . . . . . 693A.1 Create the db2admin user for DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693A.2 Create wasadmin for WebSphere Application Server. . . . . . . . . . . . . . . 696

Contents vii

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701

Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705

viii IBM WebSphere Portal V4.1 Handbook Volume 1

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.

© Copyright IBM Corp. 2003. All rights reserved. ix

TrademarksThe following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

IBM HTTP Server ™pSeries™Redbooks (logo)™Redbooks™RS/6000®SecureWay®SP™Tivoli®VisualAge®WebSphere®xSeries™AIX®

AIX/L™AIX 5L™Database 2™DB2®DB2 Connect™DB2 Universal Database™Domino™eServer™Everyplace™Home Director™Hummingbird®IBM®

Lotus Discovery Server™Lotus Notes®Lotus Workflow™Lotus®MQSeries®Netfinity®Notes®PC 300®QuickPlace™Sametime®Word Pro®

The following terms are trademarks of other companies:

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.

Unix is a registered trademark of The Open Group in the United States and other countries.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC.

Other company, product, and service names may be trademarks or service marks of others.

x IBM WebSphere Portal V4.1 Handbook Volume 1

Preface

The IBM WebSphere Portal V4.1 Handbook is available in three volumes of Redbooks. This is volume 1.

These Redbooks position the IBM WebSphere Portal for Multiplatforms as a solution that provides a single point of interaction with dynamic information, applications, processes and people to help build successful business-to-employee (B2E), business-to-business (B2B), and business-to-consumer (B2C) portals.

WebSphere Portal consists of three packaged offerings:

� Portal Enable� Portal Extend� Portal Experience

In the three volumes of the IBM WebSphere Portal V4.1 Handbook, we cover WebSphere Portal Enable and Extend.

The IBM WebSphere Portal V4.1 Handbook will help you to understand the WebSphere Portal architecture, how to install and configure WebSphere Portal, how to administer portal pages using WebSphere Portal; it will also discuss the development of WebSphere Portal portlets and how to use specific WebSphere Portal applications.

Across the volumes of the IBM WebSphere Portal, you will find step-by-step examples and scenarios showing ways to rapidly integrate your enterprise applications into an IBM WebSphere Portal Server environment using state-of-the-art technologies, such as portlets, and implementing new and enhanced capabilities incorporated in the current releases of IBM WebSphere Portal Server offerings, such as access controls and page customization using themes and skins.

In this redbook, we discuss the installation of WebSphere Portal within the Windows 2000, Linux and AIX environments. In addition, we discuss the automated installation of WebSphere Portal using Setup Manager and manual installations.

A basic knowledge of Java technologies such as servlets, JavaBeans, EJBs, JavaServer Pages (JSPs), as well as XML applications and the terminology used in Web publishing, is assumed.

© Copyright IBM Corp. 2003. All rights reserved. xi

Figure 0-1 The team (left to right), Gord Niguma, Roshan Rao, Denise Hendriks Hatzidakis, Rufus Credle, Sunil Hiranniah, Dwight Norwood, and Bernhard Stimpfle.

The team that wrote this redbookThis redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Raleigh Center.

Rufus Credle is a Senior I/T Specialist and certified Professional Server Specialist at the International Technical Support Organization, Raleigh Center. He conducts residencies and develops Redbooks about network operating systems, ERP solutions, voice technology, high availability and clustering solutions, Web application servers, pervasive computing, and IBM and OEM e-business applications, all running ^ xSeries systems. Rufus’s various positions during his IBM career have included assignments in administration and asset management, systems engineering, sales and marketing, and IT services. He holds a BS degree in business management

xii IBM WebSphere Portal V4.1 Handbook Volume 1

from Saint Augustine’s College. Rufus has been employed at IBM for 22 years.

Denise Hendriks Hatzidakis is a managing director and WebSphere Architect with Perficient, Inc. Denise has a BS in Physics and a BS in Computer Science, as well as an MS in Electrical and Computer Engineering. She joined IBM and spent ten years as a lead developer for VisualAge and WebSphere in various capacities. She has recently joined Perficient, Inc., where she makes extensive use of her skills as a consultant in WebSphere and J2EE technologies.

Sunil Hiranniah is a Software Engineer and works for IBM Developer Relations Technical Support Center in Dallas, USA. He has over five years of experience in the software industry working within various commercial projects. He has wide experience with WebSphere Portal, WebSphere Application Server, J2EE and databases. He has written and published extensively on the WebSphere family of products.

Gord Niguma is an IT Specialist for the Vancouver Innovation Centre in IBM Canada. He has six years of experience in the Web development field, working for customers such as Air Canada and the NHL Players Association. He holds an MS in Computer Science from Simon Fraser University and a BS in Computer Science from Dalhousie University. His areas of expertise include portals and Web content management.

Dwight Norwood is a Director and Senior Consultant for Courtbridge Consulting Group, an IBM Business Partner located in East Granby, Connecticut (U.S.A.). He has 30 years of experience in information technology, with ten years of Lotus Notes and Domino experience. A graduate of the University of Notre Dame, he holds an MS in Computer Science from Rensselaer Polytechnic Institute and an MS in Business Administration from the University of Connecticut. He has written extensively about Notes and Domino development. He has special interests in enterprise knowledge management and publishing, as well as Web-related security.

Roshan Rao is a Senior Consultant with Perficient Inc., with approximately three years of experience in design and development of object-oriented systems. He has a degree in Commerce from the University of Mumbai and is currently pursuing an MS in Computer Science from Maharishi University of Management. He is an IBM Certified Specialist for WebSphere Application Server and MQSeries. His key areas of work include Java technologies, portals, messaging and enterprise application development and integration.

Bernhard Stimpfle is a Pervasive Solutions Architect for the Pervasive Computing Division in Boeblingen, Germany. He reviews architectures, implements customer-specific product add-ons and supports major customers on-site in critical situations. He has spent eight years within the IT industry,

Preface xiii

working for DaimlerChrysler Aerospace and managing his own business. His areas of expertise include Pervasive Computing, Unix, Java 2 Enterprise Edition (J2EE) programming, and Solution architectures. He is a Red Hat Certified Engineer (RHCE) and holds a Diplom-Ingenieur degree in Computer Science from Berufsakademie Ravensburg, Germany.

Thanks to the following people for their contributions to this project:

Gail Christensen, Cecilia Bardy, Margaret Ticknor, Tamikia Barrow, Diane O’SheaInternational Technical Support Organization, Raleigh Center

Mark C Fullerton, Consulting I/T ArchitectIBM Ontario

Vishy Gadepalli, Stacy Joines and Sung-Ik So - IBM WebSphere Enablement and Consulting TeamIBM Raleigh

Axel Buecker, ITSO Project LeaderIBM Austin

Stefan Schmitt, Marian Puhl, Ingo Schuster, David S. Faller, WebSphere Portal DevelopmentIBM Boeblingen

Theodore Buckner, IBM Pervasive Computing DivisionIBM Raleigh

Frank Seliger, IBM Pervasive Computing DivisionIBM Boeblingen

xiv IBM WebSphere Portal V4.1 Handbook Volume 1

Become a published authorJoin us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Comments welcomeYour comments are important to us!

We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways:

� Use the online Contact us review redbook form found at:

ibm.com/redbooks

� Send your comments in an Internet note to:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HQ7 Building 662P.O. Box 12195Research Triangle Park, NC 27709-2195

Preface xv

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/

http://www.ibm.com/redbooks/


http://www.redbooks.ibm.com/contacts.html

xvi IBM WebSphere Portal V4.1 Handbook Volume 1

Chapter 1. Introduction to WebSphere Portal V4.1

IBM WebSphere Portal for Multiplatforms provides a single point of interaction with dynamic information, applications, processes and people to help build successful business-to-employee (B2E), business-to-business (B2B) and business-to-consumer (B2C) portals. WebSphere Portal also supports a wide variety of pervasive devices enabling users to interact with their portal anytime, anywhere, using any device, wired or wireless.

WebSphere Portal consists of three packaged offerings: the Portal Enable offering is the base offering; Portal Extend and Portal Experience both add more functionality. In this chapter, we will discuss the three offerings. However, much of our attention in this redbook is focused toward the Portal Enable and Extend offerings.

1.1 WebSphere Portal EnableThe IBM WebSphere Portal Enable offering allows you to quickly build scalable portals to simplify and speed your access to personalized information and applications. WebSphere Portal Enable provides common services including:

1

© Copyright IBM Corp. 2003. All rights reserved. 1

� Connectivity and integration to allow access to enterprise data, external newsfeeds or even your trading partners’ applications.

� Presentation and administration to enable computing desktop customization to match your own work patterns and needs, while providing:

– Improved productivity with access to enterprise resource planning (ERP), customer relationship management (CRM) and supply chain management (SCM) enterprise applications.

– Increased security features that include an authentication layer to provide controlled access to the portal, and user information is stored in a Lightweight Directory Access Protocol (LDAP) directory.

With WebSphere Portal Enable, you can build a Web site that allows users to select which applications they view and how they want to view them. Your site becomes easier to use. Any irrelevant content is filtered out and pertinent content can be quickly located. WebSphere Portal Enable provides two personalization technologies to tailor Web content, including:

� Rules-based filtering to determine which Web content is displayed for a particular user.

� Advanced statistical models and matching techniques to extract visitor behavior and trends, so you can tailor displayed content by individual portlets to different users and groups.

Listed are the WebSphere Portable Enable components:

� WebSphere Portal

� WebSphere Application Server

� WebSphere Personalization

� IBM SecureWay Directory

� IBM DB2

� IBM Web Content Publisher

� WebSphere Application Developer

Target: Personalized e-business portals that manage content and process transactions.

1.2 WebSphere Portal ExtendBuilt on the portal framework in the WebSphere Portal Enable offering, the IBM WebSphere Portal Extend offering adds collaborative components and Web

2 IBM WebSphere Portal V4.1 Handbook Volume 1

analytics coupled with additional tools to access, organize, and share information. Its features include:

� Parallel, distributed, heterogeneous searching capability

� Individual and shared team workspaces with built-in collaborative capabilities

� Collaboration software components

� Web site analyses

Using collaboration technology, WebSphere Portal Extend allows portal users to be more productive because they can collaborate and act on the information they are viewing. Out-of-the-box Web workspaces provide:

� Customizable work environments for individuals, teams or communities.

� The ability to create discussion areas for collaboration about documents stored in document libraries.

� The ability to set up group calendars, assign tasks and communicate through instant messaging.

� Individual collaborative components to make portal and portlet development easy.

WebSphere Portal Extend provides extended search capabilities that allow you to search across an expanded variety of data stores, including relational databases such as IBM DB2 Universal Database, Oracle, Lotus Notes and Lotus Domino databases, popular Web search engines and text or HTML documents.

WebSphere Portal Extend includes robust Web analysis technology to help you obtain and leverage critical knowledge to optimize your portal. This offering enables you to:

� Make informed decisions about Web initiatives.

� Maximize B2E, B2C and B2B Web site effectiveness for IT, marketing and sales executives.

� Capture, store, measure, report and chart Web site visitor trends and preferences.

Chapter 1. Introduction to WebSphere Portal V4.1 3

WebSphere Portal Extend adds more functionality to WebSphere Portable Enable. Listed are WebSphere Portal Extend components:

� IBM Lotus Collaborative Places

� IBM Lotus Collaborative Components

� IBM Lotus Extended Search

� IBM Tivoli Site Analyzer

Target: B2E and E2E portals requiring robust collaboration with plans to grow on the platform.

1.3 WebSphere Portal ExperienceIn addition to the tools and capabilities contained in IBM WebSphere Portal Extend and IBM WebSphere Portal Enable, IBM WebSphere Portal Experience adds advanced collaboration, content management and security policy management, creating the most comprehensive portal offering in the market. WebSphere Portal Experience allows you to develop, deploy and maintain enterprise portals that provide a first-class experience for employees, trading partners and customers. WebSphere Portal Experience features include:

� Advanced collaboration features for e-meetings, application sharing and whiteboarding enable effective online collaboration as well as the ability to take team rooms offline.

� Data storage for a broad spectrum of digital information including facsimiles, images, PC files, XML, and multimedia.

� Content infrastructure for applications including call centers, high-volume claims processing, and accounts payable.

� Folder management and document workflow.

� Sample Java applications as well as advanced application development tools.

� Security policy management tools for e-business and distributed applications.

WebSphere Portal Experience adds advanced collaboration capabilities and enterprise content management functions, and ensures a more secure portal with security-rich access to information through IBM security management products.

� Advanced collaboration features improve collaboration for mobile users by allowing them to share a screen frame, their desktop, presentations or applications through e-meetings, application sharing and whiteboarding capabilities. Features allow users to create a secure Web workspace


instantly, where other users can share ideas and documents and even go off-line.

� Enterprise content management features index, store and distribute digital content quickly and provide the enterprise content management infrastructure to access digital assets created by other business applications. An enterprise-scalable repository allows you to index, store, search and distribute virtually any type of digital content, including HTML and XML Web content, document images, electronic office documents and richmedia like digital audio and video.

� Security policy management tools take security to the next level by providing a robust and secure policy management tool that supports e-business and distributed applications. In addition, the secure policy management tool addresses the challenges of escalating security costs, growing complexity and cross-platform security policies.

WebSphere Portal Experience adds more functionality to WebSphere Portable Enable and WebSphere Portal Extend. Listed are WebSphere Portal Experience components:

� IBM Content Manager

� IBM Tivoli Access Manager

� IBM Lotus Sametime

� IBM Lotus QuickPlace

Target: Comprehensive e-business portals requiring advanced security, content management and collaboration capabilities.

1.4 Industry impact and acceptanceIndustry research has indicated that IBM has significantly improved its product offering of WebSphere Portal requiring much less services for deployment. The significant achievements that have been made are listed:

� IBM has constructed an Enterprise Portal solution which is very impressive; its technology has a wealth of features that are not available, at least together, in competitive products.

� The ease with which WebSphere Portal may be managed and its comprehensive capabilities to delegate administration of sections of the portal environment are impressive. This ensures that flexible, secure and manageable portal environments can be created in a cost effective, responsive manner.

Chapter 1. Introduction to WebSphere Portal V4.1 5

� WebSphere Portal is a solution for business-to-business (B2B) and business-to-consumer (B2C) environments and it provides application integration for all enterprise Web-based environments.

� IBM provides a range of product offerings, ranging from entry-level portals to those with a true enterprise-wide scope making WebSphere Portal available to business of all sizes.

� The fact that WebSphere Application Server forms the foundation of this solution means that issues such as security, scalability and reliability should not be an issue. WebSphere Portal is built on top of WebSphere Application Server Version 4 technology ensuring compliance with J2EE standards.

For more information about IBM WebSphere Portal position in the marketplace visit the following Web sites:

http://www-3.ibm.com/software/info1/websphere/index.jsp?tab=landings/portalkit&S_TACT=102BBW01&S_CMP=campaign

http://www-3.ibm.com/software/info1/websphere/index.jsp?tab=highlights





Chapter 2. The WebSphere Portal architecture

This chapter examines the WebSphere Portal architecture from several aspects including:

� WebSphere Portal software topology

� WebSphere Portal architecture

� WebSphere Portal operational aspects

The WebSphere Portal software topology is explored with respect to the WebSphere Portal software itself and its partner and prerequisite software.

Next, we examine the WebSphere Portal architecture and the components that make up the WebSphere Portal solution.

Finally, this chapter addresses some of the operational aspects of WebSphere Portal such as creating user IDs, the use of data sources, etc.

2


2.1 WebSphere Portal software topologyThis section addresses the software topology of WebSphere Portal and its prerequisite software. The WebSphere Portal overall software topology can be seen in Figure 2-1.

Figure 2-1 WebSphere Portal software topology

WebSphere Portal installs and runs on the WebSphere Application Server platform. A database subsystem such as DB2 Universal Database or Oracle is used as repository software for storing WebSphere Application Server and WebSphere Portal configuration data. An LDAP source, such as IBM SecureWay Directory, Lotus Domino Directory Services, or Microsoft Active Directory is used by WebSphere Application Server and WebSphere Portal for authentication and authorization within the portal.

Lotus Domino Server

Lotus Domino Server

WebSphere Application Server

WebSphere Personalization

WebSphere Portal

WAS40

WPS41

WMS

DB2 Universal Database

LDAP

IBM HTTP Server

WebSphere Member Services

Transcoding Publisher

Lotus Domino Server

Lotus Sametime

Lotus Discovery Server

Lotus QuickPlace

Lotus Workflow Architect

IBMWeb Content

Publisher

IBM SecureWay

Portlet

Lotus Workflow

Lotus Domino Server

Directory Services

MicrosoftActive Directory

Lotus Domino Server

Lotus Domino Server

Lotus Extended Search

JURU Search


WebSphere Portal has built-in portlets that interface with tooling that extends the WebSphere Portal functionality. The Lotus products, such as QuickPlace and Sametime, are used with WebSphere Portal to provide collaborative services, as an example of the WebSphere Portal extended functionality. Portlets are also provided to integrate with extended search capabilities.

Also part of the WebSphere Portal software topology is IBM Web Content Publisher. IBM Web Content Publisher is tooling for contributing content and documents to the portal.

WebSphere Portal installs as a component in WebSphere Application Server. As seen in Figure 2-2, WebSphere Portal is a combination of four Enterprise Applications on one application server, the WebSphere Portal application server:

� WebSphere Member Subsystem

� WebSphere Portal Server Enterprise Application

� WCM Publish WebApp

� WS Proxy

These four applications make up the WebSphere Portal software as installed in WebSphere Application Server.

Chapter 2. The WebSphere Portal architecture 9

Figure 2-2 WebSphere Portal base install

The installation of WebSphere Portal also installs several portlets for accessing third party software such as Lotus collaboration.

Portlets are installed in WebSphere Portal as enterprise applications. Figure 2-3 displays a list of the enterprise applications installed with the base install of WebSphere Portal Extend.


Figure 2-3 WebSPhere Portal portlet install


2.2 WebSphere Portal architectureArchitecturally, WebSphere Portal is comprised of presentation services, portal infrastructure and access to enterprise resources. The overall architecture can be seen in Figure 2-4.

Figure 2-4 WebSphere Portal architecture

Presentation servicesWebSphere Portal presentation services provide customized and personalized pages for users through aggregation. Page content is aggregated from a variety of sources via content and applications.

The portal engine WebSphere Portal provides a pure Java engine whose main responsibility is to aggregate content from different sources and serve the aggregated content to multiple devices. The portal engine also provides a framework that allows the presentation layer of the portal to be decoupled from the portlet implementation details. This allows the portlets to be maintained as discrete components. Figure 2-5 shows the WebSphere Portal engine components.

Aut

hent

icat

ion

Portal Aggregation

Themes and

Skins

TagLibraries

Tran

sco

ding

Tran

slat

ion

Cre

dent

ial V

ault

Co

nten

t Acc

ess

Sea

rch

Por

tlet D

ata

Loc

al P

ort

let

Po

rtle

t P

roxy

Web

Clip

per

Org

aniz

er

Co

llabo

rati

on

Adm

inis

trat

ion

Portlet API

RemotePortlet

Requedst

Authorization

WebSphereMemberServices

WebSpherePortal

Database

UDDIDirectory

J2E

E A

PIs

JCA

Web Services

JMS

EJB

JDBC

Enterprise Data and

Applications

Internet or IntranetContent


Figure 2-5 WebSphere Portal engine

The Authentication Server is a third party authentication proxy server that sits in front of the Portal Engine. Access to portlets is controlled by checking access rights during page aggregation, page customization, and other access points.

The Portal Servlet is the main component of the portal engine. The portal servlet handles the requests made to the portal. The portal requests are handled in two phases. The first phase allows portals to send event messages among themselves. In the second phase, the appropriate Aggregation Module for the requesting device renders the overall portlet page by collecting information from all the portlets on the page and adding the standard decoration such as title bar, edit button, etc.

The portal servicesPortal services are components of WebSphere Portal and are used to extend the portal functionality. Key functionality is provided with WebSphere Portal for personalization, search, content management, site analysis, enterprise application integration collaboration and Web services.

Portal infrastructureWebSphere Portal infrastructure is the framework that provides the internal features of the portal. Functionality such as user and group management via self registration and portal administration are provided by the WebSphere Portal infrastructure.

Portal Servlet

Aggregation Modules

User Bean

LDAP Directory

Relational Database

Management System

Portal Registry

portlets

services

Access ControlTrust Association interceptor

Authentication Server

Portal Engine Full Page View


Security servicesAs WebSphere Portal runs within the WebSphere Application Server platform, it makes use of the standard Java Security APIs to provide authentication and authorization. The WebSphere Portal is configured so that incoming requests pass through an authentication component such as WebSphere Application Server, WebSEAL (a component of SecureWay) or other proxy servers.

User Beans are provided to allow programmatic access to the user information for use within the portal.

Page transformationWebSphere Transcoding Publisher is integrated with WebSphere Portal to transform the portal markup produced by WebSphere Portal to additional devices such as mobile phones and PDAs.

For performance aspects and to reach better output results, portlet developers are encouraged to produce the correct output inside the portlets instead of using transcoders to change the created output afterwards.

Figure 2-6 Leveraging transcoding capabilites in portal/portlet filters

WebSphere Portal provides filters that can be leveraged for all request and response flows of the portal or of specific portlets. A typical use of these filters would be markup transformation.

Figure 2-6 shows a possible request or response flow scenario using a PortalFilter as well as a PortletFilter. Both are symbolized by red triangles. The Transcoding Adapter symbolizes a filter implementation that leverages the WebSphere Transcoding Publisher.

These WebSphere Portal filters are designed for and are extensively used in the WebSphere Everyplace Access product which is based on WebSphere Portal.

TranscodingAdapter

WebSphere Transcoding Publisher Beans and Components

PortalAggregation

Module

PortletInvocationInterface

Portlet(Not using

PortletFilter)

Portlet(Using

PortletFilter)Transcoding

Adapter

ServletRequest

ServletResponse

PortletRequest

PortletResponse

ServletRequest

ServletResponse

MightUse


2.3 Operational aspectsThis section is intended to give WebSphere Portal administrators an overview of the components that are part of a typical WebSphere Portal installation and to explain how they relate to each other.

Figure 2-7 WebSphere Portal operational aspects

Figure 2-7 illustrates the parts of WebSphere Portal in a multi-layered order.

The IBM HTTP Server only talks to the WebSphere Application Server. Even though the WebSphere Portal product comes with a specific implementation of the HTTP Server plug-in, it does not enhance the functionality to talk (for example, in a proprietary way to some portal parts). Therefore, any HTTP Server that is supported by WebSphere Application Server can be used.

The WebSphere Application Server requires a database to operate. On a Windows environment, it is usually named WAS40. In a Unix environment, it

WMS

WPS41

WAS40

WebSphere Portal Core


Directory Services

wpsadmin

wpsbind

IBM HTTP Server

db2admin

wasadmin

SecureWay, Domino, ActiveDirectory


WebSphere SecurityadminRole

WebSphere Portal Application

wpsadmins

Member Services

Databases

DB2, Oracle OS Users


usually has an alias called WASDB. It usually points to a physical database named WASDBL. In a Windows environment, the WebSphere Application Server is usually operated by a user named wasadmin. In a Unix environment, it is usually the root user that operates WebSphere Application Server.

The databases are usually operated by a user named db2admin in a Windows environment. In a Unix environment, it is not uncommon to operate the various databases through various instances and therefore through various operating system users. The default Unix DB2 instance user is named db2inst1.

In using Oracle instead of IBM DB2, this might differ.

The WebSphere Application Server security is a required component for WebSphere Portal, except when it is configured for a development installation only. To provide its authentication functionality, WebSphere security uses a directory service as the user administration repository and communicates with it using the open, standardized LDAP protocol. The wpsbind LDAP user is habitually used to establish a connection to the directory service and to leverage it. Users or groups that are linked with the AdminRole definition in WebSphere security will be allowed to leverage full access functionality for the applications that are secured by WebSphere security. This means that only users who have this label will be able to change secured applications or add new applications into the WebSphere security area.

The WebSphere Portal application is in the WebSphere security secured area.

As a final portion of the operational aspects of WebSphere Portal, Figure 2-8 contains the directory structure associated with a WebSphere Portal Extend installation.


Figure 2-8 WebSphere Portal Extend directory structure

wp_root Root directory for Portal Server _uninst Files used to uninstall Portal Server app | +-- WCMPznPublish.ear Root directory for Content Organizer enterprise application | | | +-- wms.ear Root directory for WebSphere Member Services enterprise

application | | | +-- wps.ear Root directory for portal enterprise application | | | | | +-- META-INF Metadata for portal enterprise application | | +-- wps.war Root directory for portal Web module | | | | | +-- doc WebSphere Portal InfoCenter and Javadoc | | +-- dtd Document Type Definitions (DTDs) for Portal Server | | +-- html HTML files for the portal | | +-- images Graphics for the portal | | +-- menu Files for MenuService | | +-- META-INF Metadata for the portal Web application | | +-- peopleawareness Files for PeopleService | | +-- screens Java Server Pages for the portal | | | +-- markup_name Subdirectory for each markup type | | | | | +-- skins Skins for portlets | | | +-- markup_name Subdirectory for each markup type | | | | | +-- themes Themes for the portal | | | +-- markup_name Subdirectory for each markup type | | | | | +-- WEB-INF Resources for the Portal Server Web application | | | | | +-- conf Portal configuration directory | | +-- tld Tag Library Descriptors | | | +-- wsproxy.ear Root directory for Web services proxy enterprise application | | | +-- META-INF Metadata for Web services proxy enterprise application | | | +-- wsproxy.war Root directory for Web services proxy Web module | | | +-- META-INF Metadata for Web services proxy Web module | | | +-- WEB-INF Resources for Web services proxy Web module | +-- bin Portal configuration interface and other portal utilities


Chapter 3. WebSphere Portal prerequisites and planning

The requirements, prerequisites, procedures and issues related to the installation process of WebSphere Portal are documented in this chapter.

3.1 WebSphere Portal offerings and CDsIn this section, we will discuss the WebSphere Portal offerings and the content of the product CDs.

3.1.1 Portal capabilities and componentsThe WebSphere Portal Enable offering is the base offering. The Extend and Experience offerings both provide more functionality. In Table 3-1, we have provided a list of IBM products included in each offering.

3


Table 3-1 WebSphere Portal offerings

3.1.2 Content of the CD setIBM WebSphere Portal V4.1.2 is available in a set of CDs. There are a number of CDs contained in WebSphere Portal since each component has an additional set of equivalent CDs for its release fixes, platforms, and languages. In this section, only the base sets and the products are specified. The following components are included in the Extend offering.

Enable Extend Experience

IBM WebSphere Application Server Advanced Edition V4.0.2

X X X

IBM Secureway Directory V3.2.2 X X X

IBM WebSphere Personalization V4.0 X X X

DB2 Universal Database V7.2+Fixpack 5 X X X

IBM WebSphere Studio Application Developer V4.02

X X X

Web Content Publisher X X X

Lotus Collaborative Places X X

Lotus Collaborative Components X X

Lotus Extended Search R3.6 X X

Tivoli Web Site Analyzer V4.1 X X

Lotus Sametime R2.6 ** X

Lotus Quickplace R2.5 ** X

IBM Content Manager V7 X

Tivoli Access Manager V3.9* X

EIP Client Kit X

Note: *Formerly Tivoli Policy Director

**In Extend, Sametime and Quickplace are limited to portal use only and have limited functionality.

**In Experience, customers can use Sametime and Quickplace inside or outside of the portal for up to 1000 users.


Disk Products

1 � IBM JRE Version JDK V1.3.0 (Service13a)� WebSphere Portal Setup Manager� e-Fix 3.2.2-SWD-002. The e-Fix contains fixes for several problems

encountered in SecureWay Directory. See the release notes on the disk for the list of problems fixed and additional notes.

� IBM HTTP Server powered by Apache for AIX, HP, Linux, Solaris and Windows NT, Version 1.3.19.1

2 � DB2 Universal Database Version 7.2 Enterprise Edition� DB2 Fixpack 5

3 � WebSphere Application Server Version 4.0.1� WebSphere Application Server Fixpack 2 - upgrades the application

server to v4.02� WebSphere Application Server e-fixes

– PQ55941 - support DataSource as custom registry– PQ56615 - fixes the problem of not be able to share JSP Tag (.tld) files

across webapps– PQ57814 - fix for with servlet caching enabled WebSphere Application

Server 4.02 has problems with servlets and JSPs– PQ58289 - fix for Security fails after a period of time– PQ58678 - fix for Authorization fails for an enterprise application

installed through XMLConfig– PQ58795 - fix for an empty string as the attribute value for a custom

tag UNABLE TO CONVERT TO STRING message on browser– PQ59932 - fix for try/finally blocks for JSP custom tags causing

performance problems during garbage collection using Solaris JDK 1.3.0/1.3.1

– PQ60787 - fix for creation/destruction of alarm threads results in increasing thread IDs, and may ultimately result in JVM crash/hang

Note: The required e-Fix PQ60461 (fix for LDAP performance issues) is not available on CD-ROMs and has to be downloaded from the IBM Web site.

� IBM HTTP Server plugins

4 � WebSphere Personalization Version 4.0 - Server and Workspace� LikeMinds Recommendation Engine Version 4.0

5 � IBM SecureWay Directory Version 3.2.2

6 � (6-1) WebSphere Studio Application Developer for Windows V4.0.3

7 � WebSphere Portal V4.1� WebSphere Transcoding Publisher V4.1� License Use Management

Chapter 3. WebSphere Portal prerequisites and planning 21

3.2 WebSphere Portal for Windows 2000 prerequisitesThis section describes the prerequisites for WebSphere Portal on Windows 2000.

3.2.1 Hardware requirementsThe following hardware are minimum requirements for a one machine installation of WebSphere Portal 4.1.2.

8 � Domino Application Server V5.0.8, includes:– Domino Mail Server– Domino Application Server– Domino Enterprise Server

9 � Web Content Publisher v4.0 (see prerequisites)� Lotus Workflow v3.0a

10 � WebSphere Site Analyzer Version V4.1

11 � Lotus QuickPlace Release V2.0.8

12 � Lotus Sametime V2.5� Fix Pack 1 - See release notes for problems fixed� STLinks - provides links to Sametime services from Web pages

13 � IBM Lotus Extended Search R3.7 / Collaborative Places/Components/ WebSphere Portal V4.1.2 for Win(13)

Disk Products

Property Requirement Notes

Hardware IBM-compatible PC

In general, WebSphere Portal can run on the AIX, Linux Intel, Solaris, and Windows platforms that WebSphere Application Server supports.

Memory 1 GB or more Additional memory is recommended for performance.


3.2.2 Software requirementsThe following software is required to install WebSphere Portal 4.1.2. If the software is being installed with an existing product installation, please consult the specific product prerequisites outlined in 3.2.3, “Pre-installed components” on page 23.

3.2.3 Pre-installed componentsThe WebSphere Portal 4.1.2 Setup Manager installation process installs individual components such as DB2, WebSphere Application Server, IBM HTTP Server and Domino Server. The Setup Manager will ensure the proper versions are installed on the system and install many of the required fixpacks.

However, in many environments these components may already be installed and in production. This section describes what versions, fixpacks and configuration must be implemented in order for the components to work with WebSphere Portal 4.1.2.

Disk space 2 GB The disk space shown is adequate if you plan to use Setup Manager to install WebSphere Portal, Personalization, WebSphere Application Server, IBM HTTP Server, and the IBM Java Runtime Environment (JRE). In addition, 100 MB in the home directory of the current user is recommended. For Windows, the C partition should have more than 100 MB if the Windows system directory is not C.


Property Requirement Comments

Operating System

Windows NT Server with fixpack 6aWindows 2000 Server with Service Pack 2

Web browser

� Microsoft Internet Explorer versions 5.0, 5.5 and 6.0

� Mozilla 5.0� Netscape 6.1 and 6.2 is

recommended� Opera 5.0

A Web browser is required to administrate and test WebSphere Portal.

Note that Netscape Communicator 4.7x is not recommended for portal.


IBM HTTP ServerWebSphere Portal recommends using IBM HTTP Server 1.3.19.1, although any Web server that runs with WebSphere Application Server 4.0.2 will be supported.

Setup Manager Upgrade SupportAlthough Setup Manager provides a version upgrade option for some software, an upgrade from a previous version of IBM HTTP Server to version 1.3.19.1 is not supported by Setup Manager. You can uninstall the previous version and then use Setup Manager to install IBM HTTP Server Version 1.3.19.1.

Fixpacks and e-FixesThe e-Fix PQ54931 is recommended, but it must be installed manually. It is not installed with Setup Manager. The e-Fix can be downloaded at:

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

Installing HTTP Server with WebSphere Application ServerWebSphere Portal provides an Advanced installation, during which the WebSphere Application Server installation attempts to install IBM HTTP Server. If you have the correct level of IBM HTTP Server installed before the WebSphere Application Server installation, do not attempt to install IBM HTTP Server during the WebSphere Application Server installation.

Other Web serversAlthough IBM HTTP Server 1.3.19.1 is recommended, WebSphere Portal supports all Web servers that WebSphere Application Server 4.0.2 supports. If you want to use a Web server other than Microsoft Internet Information Services (IIS), make sure that features of IIS are disabled before installation.

WebSphere Application Server Advanced Edition 4.0.2WebSphere Portal runs as an application server on IBM WebSphere Application Server Advanced Edition 4.0.2. Your system must have the required level of WebSphere Application Server prior to installing WebSphere Portal. Please read and follow the directions in the following table before you install WebSphere Portal.

Fixpacks and eFixesFixpack 2 must be installed along with the following e-Fixes. If you install WebSphere Application Server with Setup Manager, the following e-Fixes are installed.

� PQ55941� PQ56615� PQ57814� PQ58289



� PQ58678� PQ58795� PQ59932� PQ60787

The e-Fix PQ60461 is required, but it must be installed manually.

For Japanese environments, manually install the e-Fix PQ57024.

You can download these e-fixes from:

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

See the README file that is associated with the e-Fix for more information.

Upgrade support with Setup ManagerSetup Manager provides a software upgrade option for some components. Note the following:

� If you are running WebSphere Application Server Version 4.0.1 without fixpack 2, you can use Setup Manager to upgrade with fixpack 2.

� An upgrade from a version of WebSphere Application Server prior to 4.0.1 to WebSphere Application Server Version 4.0.2 is not supported.

Installing Cache Plug-In for IBM HTTP ServerIn a portal production environment, it is more efficient to serve static content (HTML, CSS, and so on) from a Web server and not the application server. To improve performance for your portal, install the IBM HTTP Server caching plug-in to serve static content from the Web server plug-in and not WebSphere Application Server.

The following instructions assume that you have already installed IBM HTTP Server and that you did not use Setup Manager to install Application Server. If you install Application Server with Setup Manager, the caching plug-in is automatically installed for you.

The following instructions are intended for IBM HTTP Server only and do not support other Web servers.



To install the caching plug-in:

1. Stop the Web server, all application servers, and the WebSphere Administrative Server service.

2. Back up the following files and then copy them as shown in the following environments:

– Windows

Copy mod_ibm_app_server_http.dll and plugin_common.dll to the was_root\bin directory.

– Unix

Copy mod_ibm_app_server_http.so to the was_root/bin directory.

3. Copy the jar file FileServingServletWithESI.jar to the was_root\classes directory.

4. Enable file serving for any portal (Web) applications that will use the cache plug-in to serve static files. You can use the Application Assembly Tool provided by WebSphere Application Server if file serving by the portal application is not already set.

Restart the Web server, the WebSphere Administrative Server service, and the application servers.

Increasing memory allocation for Java Virtual MachineBefore you install WebSphere Portal, you can do the following to reserve 128 MB for the Java Virtual Machine of WebSphere Application Server.

1. Open file was_root/bin/adminserver.sh

2. Locate the ${JAVA_EXE} entry.

3. Add the following parameter to this entry: -Xmx128M

Save the file and restart WebSphere Application Server.

DB2DB2 Universal Database version 7.2 with fixpack 5 is provided with WebSphere Portal and is recommended for use with WebSphere Portal.


Upgrade support with Setup ManagerSetup Manager provides a software upgrade option for some components. Note the following:

� If you are running DB2 Version 7.2 without fixpack 5, you can use Setup Manager to upgrade with fixpak 5.

� An upgrade from a version of DB2 prior to 7.2 to DB2 Version 7.2 is not supported.

Create and update WebSphere Portal and Member Services databases

During the portal installation, you are provided with the option to create new databases or initialize existing databases that store portal data. If you choose to create the WebSphere Portal and Member Services databases before you install the portal, you must manually update the configuration of the databases prior to the portal installation.

The following instructions assume that you have already installed DB2 server and you intend to install WebSphere Application Server and WebSphere Portal on the same Windows machine.

Windows

To create and update the databases prior to the Portal installation on Windows platform, do the following:

1. Issue the following commands for the WebSphere Portal database:

$ db2 create database wps using codeset UTF-8 territory us$ db2 update database configuration for wps using applheapsz 1024 app_ctl_heap_sz 1024

2. Issue the following commands for the Member Services database:

$ create database wms using codeset UTF-8 territory US;$ update database configuration for wms using applheapsz 16384;$ update database configuration for wms using stmtheap 60000;$ update database configuration for wms using app_ctl_heap_sz 8192;$ update database configuration for wms using locklist 400;$ update database configuration for wms using indexrec RESTART;$ update database configuration for wms using logfilsiz 1000;$ update database configuration for wms using logprimary 12;$ update database configuration for wms using logsecond 10;

3. Install WebSphere Application Server.


Install WebSphere Portal, and during the installation, select Initialize an existing database for both the WebSphere Portal and Member Services databases.

Unix:

The following instructions assume that you have already installed DB2 server and you intend to install WebSphere Application Server and WebSphere Portal on the same Unix machine.

To create and update the databases prior to the Portal installation on Unix platform, do the following:

1. Create the databases and configuration.

a. Issue the following commands for the WebSphere Portal database:

$ db2 create database wps using codeset UTF-8 territory us$ db2 update database configuration for wps using applheapsz 1024 app_ctl_heap_sz 1024

b. Issue the following commands for the Member Services database: $ create database wms using codeset UTF-8 territory US;$ update database configuration for wms using applheapsz 16384;$ update database configuration for wms using stmtheap 60000;$ update database configuration for wms using app_ctl_heap_sz 8192; $ update database configuration for wms using locklist 400; $ update database configuration for wms using indexrec RESTART; $ update database configuration for wms using logfilsiz 1000; $ update database configuration for wms using logprimary 12; $ update database configuration for wms using logsecond 10;

2. Configure the database manager to use TCP/IP to connect to WebSphere Application Server remotely. Because you are using a local DB2 database with WebSphere Application Server, you will perform all of the steps in the following procedure on the same machine.

a. Ensure that you are logged into the machine with superuser (root) privileges.

b. Use a text editor to open the /etc/services file. If it does not specify DB2 connection and interrupt service ports, add the following text to specify the ports:

server1 50000/tcp # DB2 connection service port server1i 50001/tcp # DB2 interrupt connection service port

c. Log in as the DB2 instance owner. In this example, the DB2 instance owner name is db2inst1.

# su - db2inst1


Logging in as the instance owner places you automatically in the home directory of the instance owner. The command prompt changes in appearance to indicate the change in your login identity.

d. Set DB2COMM to TCP/IP by using the db2set command, as follows:

$ db2set DB2COMM=tcpip

e. Update the database manager configuration by using the db2 update command, as follows:

$ db2 update dbm cfg using svcename connection_service_port

where connection_service_port represents the name of the DB2 connection service port you specified in the /etc/services file (for example, server1).

f. Catalog the TCP/IP node with IP address 127.0.0.1, as follows:

$ db2 catalog tcpip node was_node remote 127.0.0.1 server connection_service_port

where was_node represents your node name and connection_service_port represents the name of the DB2 connection service port you specified in the /etc/services file.

g. Catalog both databases as follows:

$ db2 catalog database wps as alias_name$ db2 uncatalog database wps$ db2 catalog database alias_name as wps at node was_node$ db2 catalog database wms as alias_name$ db2 uncatalog database wms$ db2 catalog database alias_name as wms at node was_node

where alias_name represents your database alias and was_node represents your node name.

h. Stop and start DB2 for your changes to take effect by using the db2stop and db2start commands, as follows:

$ db2stop$ db2start

i. To log out as the DB2 instance owner, enter the following command:

$ exit

The DB2 server remains active unless you stop it by using the db2stop command.

3. Install WebSphere Application Server and WebSphere Portal. During the WebSphere Portal installation, you must select Initialize an existing database for both the WebSphere Portal and Member Services databases and use the alias as the database name.


To drop the databases and the TCP/IP redirection, type the following DB2 commands:

$ db2 uncatalog database wps$ db2 drop database alias_name$ db2 uncatalog database wms$ db2 drop database alias_name

Configuring a remote DB2 databaseThe following instructions assume that you will use a DB2 client to connect to a remote DB2 server. The following instructions assume that you will install WebSphere Application Server and WebSphere Portal on the same machine where the DB2 client is installed. Perform the steps in this section prior to installing WebSphere Portal.

1. Create a WebSphere Application Server database at the remote server with a DB2 instance other than db2inst1.

By default, the DB2 server installation creates db2inst1 as the instance and the user. If you use Setup Manager to install WebSphere Application Server on a DB2 client machine, you cannot use db2inst1 as the user. You must create a user other than db2inst1, for example dbusr. After you create the alternate DB2 instance, the Application Server installation will catalog to the remote DB2 server using the database user db2inst1.

2. Configure the DB2 client to access the remote database.

Follow step 2 on page 30 in the preceding section to configure TCP/IP remote connections and catalog the portal databases as remote databases to be communicated through TCP/IP.

3. Install WebSphere Application Server and WebSphere Portal.

During the WebSphere Portal installation, you must select Initialize an existing database for both the WebSphere Portal and Member Services databases and use the alias as the database name.

User ID for WebSphere Portal databasesThere must be a system user ID (with administrative authority) and password that match the database user ID and password for the WebSphere Portal databases. If you do not use the default DB2 database user ID, or you need to access a remote database, create the system user ID before you start the installation. To set up the environment for the database access, the initialization script for this user (for example, user-home/.profile) must contain a call to the db2profile script in the db-home/sqllib directory. After you create the system user ID and password for the DB2 instance, add the user ID to the DB2 administration group (such as db2adm) for that system.


Do not install the OLAP starter kitA prompt displays that asks you to install or not install the DB2 OLAP Starter Kit. Because WebSphere Portal does not include the OLAP Starter Kit, select Do not install the OLAP Starter Kit and continue.

Oracle 8.1.7Although not shipped with WebSphere Portal, you can also use Oracle Version 8.1.7 as the database software for WebSphere Portal. If you use Oracle, you must do the following:

1. Install Oracle before installing WebSphere Portal.

2. If you have set up your database with a different name for the System Identifier (SID) and the Global Database Name, type the SID during the portal installation.

3. To install and run the WebSphere Portal, you need to create the following users:

– A user that is used by the portal to connect to the databases and to store the portal database tables. In the following commands, a user (WPS) is created to connect to the WebSphere Portal database and a separate user (WMS) is created to connect to the Member Services (WMS) database. During the WebSphere Portal installation, the WebSphere Portal Server and WMS users need the create all tables, delete all tables, create all index, and update all authorities.

– A user that is used to store the tables of the Portal Content Organizer. This user is not used to log on but only as a separate schema identifier.

To create the users in the database, follow these steps:

a. Start SQL*Plus (the Oracle SQL command line tool):

$ sqlplus system/manager

where manager is the default password of user system

b. In the SQL*Plus tool, enter the following commands:

SQL> create user WPS identified by WPS_password;SQL> grant dba, connect, resource to WPS;SQL> create user WMS identified by WMS_password;SQL> grant dba, connect, resource to WMS;SQL> create user WPSPCO identified by WPSPCO_password;SQL> grant resource to WPSPCO;SQL> quit

c. When you are asked for the database user ID and password during the WebSphere Portal installation, enter WPS and the password that you created. WPSPCO is the schema name for Portal Content Organizer. During installation, grant the users the three roles, CONNECT,


RESOURCE, and DBA, and afterwards, if required, these privileges can be reduced to a role which has select, update, insert, and delete privileges.

4. For Linux, Oracle 8.1.7 includes the files classes111.zip and nls_charset11.zip. WebSphere Application Server requires classes12.zip and nls_charset12.zip. Copy these two files to $ORACLE_HOME/jdbc/lib before you install WebSphere Application Server.

IBM Secureway Directory v 3.2.2IBM SecureWay Directory Version 3.2.2 is provided and recommended for use with WebSphere Portal. If you currently use an implementation of IBM SecureWay Directory, read the instructions and follow the procedures provided in the following table.

Upgrade support through Setup ManagerAlthough Setup Manager provides a version upgrade option for some software, an upgrade from a previous version of SecureWay Directory to version 3.2.2 is not supported by Setup Manager. You can uninstall the previous version and then use Setup Manager to install SecureWay Directory version 3.2.2.

Using an existing SecureWay installationIf you already have SecureWay Directory version 3.2.2 installed, you do not have to install it with Setup Manager. To use your existing copy of SecureWay Directory, do one of the following:

� Use Setup Manager to install WebSphere Portal and follow the on-screen instructions to configure WebSphere Portal with your SecureWay Directory settings.

� Manually add a suffix, and then edit and import an LDIF file before you install WebSphere Portal.

– Add a suffix:

i. In the SecureWay Directory console, click the Settings folder, and then click Suffixes.

ii. Type the name of the Base DN to be used as the suffix (for example, dc=yourco,dc=com), and click Update.

iii. Stop and start the LDAP server.

– Edit and import an LDIF file with your values into SecureWay Directory. A sample LDIF file, WPSconfig.ldif, is provided with WebSphere Portal. If you use this file, do the following:

i. Locate the file WPSconfig.ldif in the /wps directory on WebSphere Portal CD 7, and open it in a text editor.


ii. Replace all occurrences of dc=yourco,dc=com with the suffix that you are using, and save your changes.

iii. Follow the instructions provided with SecureWay Directory to import the file WPSconfig.ldif. Stop and restart the LDAP server.

Domino LDAPWebSphere Portal has been tested to support the LDAP server provided with Lotus Domino Server version 5.0.5 or higher.

A minimum of one group and two users are required for WebSphere Portal. Before you install WebSphere Portal, create the following group and users in the LDAP directory.

� A group named wpsadmins must exist in the directory. � Two users that belong to wpsadmins must also exist. One user must be

named wpsbind with the password wpsbind. User wpsbind must have bind authority. Another user must be named wpsadmin with the password wpsadmin. User wpsadmin must have administrative authority.

� During the initial portlet installation, you must enter wpsadmin as the authentication ID to install the portlets.

� After the portal installation, it is recommended that you change the passwords for these user IDs.

� The following assumes that your Domino Directory is set up with the usual defaults. Specify the portal administrator as CN=wpsadmin,O=dominoDomain, and add it to the portal administrator group, CN=wpsadmins. Also add a user ID of CN=wpsbind,O=dominoDomain to use as a sample user ID. If you do not have the specific administrator IDs or group in your Domino Directory, use the Domino user-management processes to add these administrator IDs and group before you install WebSphere Portal. During the portal installation, type the DNs on the appropriate panel. Adjust the DNs as necessary for your Domino Directory configuration.

During the WebSphere Portal installation, you will define the Distinguished Name (DN) of the LDAP administrator. Before you install WebSphere Portal, ensure that the ID of the LDAP administrator (that you will enter during the WebSphere Portal installation) exists in names.nsf (Domino Directory).

Also ensure that this user has Manager access and that the roles GroupCreator and GroupModifier are set. If you intend to use the self-care and self-registration functions provided with WebSphere Portal, enable LDAP users write access.

In Domino, you can set the Allow LDAP users write access field to Yes. Locate this field in the Configuration document, on the LDAP tab. You can use the ldapsearch utility to verify your user and group DN information.


iPlanet LDAP serverWebSphere Portal has been tested to support the LDAP server provided with iPlanet 5.1.

A minimum of one group and two users is required for WebSphere Portal. Before you install WebSphere Portal, create the following group and users in the LDAP directory.





� The group wpsadmins and the users, wpsbind and wpsadmin, are part of the default settings in the WPSconfig-netscape.ldif file provided with WebSphere Portal. If you import this file, note the following: – WPSconfig-netscape.ldif is located in the /wps directory on WebSphere

Portal CD 7. – Follow the instructions provided with iPlanet to import the file

WPSconfig-netscape.ldif. Stop and restart the LDAP server. – It is recommended that you change the passwords for these users

wpsbind and wpsadmin after the portlet installation.

During the WebSphere Portal installation, you will define the Distinguished Name (DN) of the LDAP administrator who has Directory Manager rights. For example, if you use the default administrator identity offered by iPlanet, type: cn=Directory Manager. You can use the ldapsearch utility to verify your user and group DN information.

Microsoft Active Directory serverWebSphere Portal has been tested to support the version of Active Directory that is provided with Microsoft Windows 2000 Server Service Pack 2.

A minimum of one group and two users are required for WebSphere Portal. Before you install WebSphere Portal, create the following group and users in the LDAP directory.

Note: Note that the LDIF files supplied by WebSphere Portal are not intended for use with the Domino LDAP server






During the WebSphere Portal installation, you must type the user name and password of a user with administrator rights.

3.3 WebSphere Portal for Linux prerequisitesThis section provides detailed prerequisite information for WebSphere Portal and general requirements for additional software components included within WebSphere Portal.

Table 3-2 describes the minimum requirements that must exist on the portal machine prior to installing WebSphere Portal in a Linux environment.

Table 3-2 Installation prerequisites

Requirement Comments

Platforms Red Hat Linux 7.2The following packages are required before you install WebSphere Portal:� ncurses4-5.0-4.i386.rpm � pdksh-5.2.14.13.i386.rpm

IBM WebSphere Application ServerAdvanced Edition 4.0 +Fix Pack 2 including the required e-fixes

The following e-fixes are required before you can install WebSphere Portal. If you install WebSphere Application Server with Setup Manager, all of the following e-fixes are installed:

� PQ55941, PQ56615, PQ57814, PQ58289, PQ58678, PQ58795, PQ59932, PQ60787

The e-Fix PQ60461 is required, but it must be installed manually. You can download this e-Fix from the WebSphere Application Server Support Web site.

For Japanese environments, manually install the e-Fix PQ57024: WebSphere 4.0.2, AdminConsole displays incorrectly in Japanese. You can download this e-Fix from the WebSphere Application Server Support Web site.


The following steps can be executed to verify that a package has been installed in your system:

1. Verify whether a package is installed in your system:

# rpm --verify ncurses4-5.0-4# rpm --verify pdksh-5.2.14-13

If no output is generated, the package is already installed. Otherwise, the Red Hat Package Manager (RPM) will return an error similar to the following statements:

package ncurses4-5.0-4 is not installedpackage pdksh-5.2.14-13 is not installed

2. If a required package is not installed, then you must install it before you start the WebSphere Portal installation. For example, if you have the original Red Hat CD, follow the next step (if not, refer to the next pdksh installation and follow the way you will install from the Web site):

a. Insert the Linux Red Hat V7.2 second CD into the CD-ROM drive (the ncurses4 package is located in this CD).

b. If the CD does not automatically mount, you will need to mount it by issuing the following command as root:

# mount /mnt/cdrom

c. If you are running X Windows with either KDE or Gnome desktop, these tools can automatically mount the CD-ROM device for you.

d. Once you have the RPM file, use the following command to install or upgrade the packages:

# rpm -vih /mnt/cdrom/RedHat/RPMS/ncurses4-5.0-4.i386.rpm

IBM HTTP Server1.3.19.1 is recommended.

The e-Fix PQ54931 is recommended, but it must be installed manually. See IBM HTTP Server tips for more information in WebSphere Portal InfoCenter.

Important: When installing Red Hat Linux V7.2 operating system, the following two packages may not be installed by default:

� ncurses4-5.0-4 (Linux CD 2)

� pdksh-5.2.14-13 (download from Web site)

Both of these packages are required to complete WebSphere Portal installation.

Requirement Comments


3. Install pdksh5.2.14-13 package from the Web site:

a. Go to:

http://rpmfind.net/

b. Enter kdsh into the search box and click Search, then download the RPM package.

c. Once you have saved the file somewhere on your system, use the following command to install or upgrade the packages:

# rpm -vih <path_to_file>/pdksh5.2.14.13.i386.rpm

3.3.1 Uninstall Linux LDAP packageIf you are installing a server such as IBM SecureWay Directory or Lotus Domino for your LDAP Directory Services, you must remove any other LDAP products that might have been installed previously. If you try to install the IBM SecureWay Directory over an existing LDAP service, such as OpenLDAP, the SecureWay Directory will not install correctly.

For example, to determine if you have a previously installed version of LDAP, issue the following command:

rpm -qa |grep -i ldap

This command finds any installed applications containing the name ldap. This method works only if you have a version of LDAP that has the string ldap in its application names.

Some packages such as openldap may be installed by default and have to be removed using the KDE Package Manager tool.

You can also use the following command to remove packages:

# rpm -e <package_name># rpm -e --nodeps <package_name>

3.3.2 Memory requirementsTo install WebSphere Portal, it is recommended that your system have a minimum of 1024 MB.

Note: Some applications may have a dependency with some libraries in the openldap (base) package. In such cases, rather than removing the base package, make sure that openldap is not running at any time.


http://rpmfind.net/

3.3.3 Disk spaceThe disk space mentioned in 3.3.3, “Disk space” on page 38 is adequate in most cases if you plan to use Setup Manager to install WebSphere Portal, Personalization, WebSphere Application Server, IBM HTTP Server, and the IBM Java Runtime Environment (JRE).

However, if for any reason you need to change the file system size, the Linux’s ext2 file system (which is used by default) does not allow you to change it. Therefore, you should carefully plan in advance for the size of your file system in order to avoid related problems. The following disk space is required for each directory:

� /: 1.5 GB or more (root directory)

� /usr: 2 GB or more (usr directory)

� /home: 500 MB or more (home directory)

For further information, refer to the Redpaper WebSphere Application Server V4 for Linux Implementation and Deployment Guide, REDP0405.

3.3.4 Network configurationSee 3.6.2, “Network requirements” on page 59.

3.3.5 Hardware requirements

The following hardware represents minimum requirements for a single tier, Linux-based installation of WebSphere Portal 4.1.2.

Note: The current Linux ext2 file system does not provide the capability to change the file system size once it has been created. However, there are third-party tools, such as PowerQuest Partition Magic, that can be used to change and resize your file system.

Note: For a basic installation in a Linux environment, you will need CD1, CD2-3, CD2-13, CD3-2, CD4, CD5, and CD7.


3.3.6 Configuring the Linux kernelWe had to change a kernel parameter in order to allow DB2 to permit multiple client connections. Execute the command below to find the current value for the msgmni parameter for the kernel.

Figure 3-1 Query the msgmni parameter

The recommended value for this parameter is atleast 128. You can change it by issuing the command:

sysctl -w kernel.msgmni=128

or, update the /etc/sysctl.conf file to include

kernel.msgmni = 128

3.4 WebSphere Portal for AIX prerequisitesThis section allows you to take into consideration those hardware and software factors that will allow you to set up and configure your WebSphere Portal solution for operation. The following hardware and software items listed here were used to build the WebSphere Portal solution illustrated in 3.6, “Planning: general considerations” on page 50.


Hardware IBM-compatible PC

In general, WebSphere Portal can run on the AIX, Linux Intel, Solaris, and Windows platforms that WebSphere Application Server supports.

Memory 1 GB or more Additional memory is recommended for performance.

Disk Space 2 GB Depending upon the type of partitioning, ensure the following free space exist for the directories below:� /: 1.5 GB or more (root directory)� /usr: 2 GB or more (usr directory)� /home: 500 MB or more (home

directory)

[root@m23vnx55 root]# sysctl -a | grep msgmnikernel.msgmni = 16


Make sure that you read and understand 3.6, “Planning: general considerations” on page 50 for prerequisites that apply to all operating systems.

3.4.1 HardwareThe hardware used in these scenarios is as follows:

� IBM ~ pSeries (RS/6000) 44p Model 170

– 1x 450 MHz POWER3-II-Processor– 2 GB RAM– 2x 18 GB hard disk– 1x SCSI CD-ROM drive– 1x 100 Mbps Ethernet– 1x GXT300P Graphics Adapter

Installing WebSphere Portal on a machine that has less than 1 GB RAM is not recommended.

The amount of RAM should be sized dependent on the amount of software packages and the amount of Portlets and Portal add-ons that should go into the system. The same applies for processor speed and hard disk size. Generally, more than one hard disk on a SCSI subsystem provides better performance, if they are reasonably configured.

Any network adapter can be used as long as there is a static IP address with a fully-qualified hostname assigned to it (see 3.6.2, “Network requirements” on page 59).

It is reasonable to have a graphics adapter installed. If the target machine does not have a graphics adapter, make sure that all graphics-related AIX packages are installed, nevertheless.

3.4.2 Software levelThe operating system used in these scenarios was AIX 5L Maintenance Level 2.

See the Release Notes and the section under Planning -> Requirements, for the latest prerequisite information of the WebSphere Portal InfoCenter on the Internet at:

Tip: To ensure that graphics-related AIX packages are installed, compare the installed packages on the target machine with an AIX machine that has a graphics adapter. To compare the packages, issue the command lslpp -L and look for package names that start with X11.


http://www.ibm.com/software/webservers/portal/library/enable/InfoCenter/

Also, see 3.4.4, “Description of how to set up AIX 5.1 prerequisites” on page 42 to understand how to setup your environment.

The software applications to be installed are:

� DB2 Universal Database V7.2 Enterprise Edition� WebSphere Application Server 4.02� WebSphere Portal V4.1� SecureWay Directory Server V3.2.2� WebSphere Personalization V4.0

Additional toolsAdditional Unix tools, such as various GNU tools, are helpful during the daily work of a system administrator. Table 3-3 lists a couple of tools that are not installed by default. They are supported by AIX 4.3.3 and AIX 5L, and they are located on the AIX Toolbox for Linux Applications disk.

Table 3-3 Short selection of useful Unix/Linux tools

3.4.3 Remote displayAs AIX Server machines tend to be located in server rooms, it is very likely that you do not sit in front of the physical machine, but work remotely from a PC.

The following points should be considered:

� As the X Client-Server connection creates quite an amount of network traffic, a fast and stable network connection is required.

Software Description

bash Bourne Again Shell is more user friendly than the Korn Shell and comes with features like command completion.

ethereal Graphical sniffer tool that can be very helpful in understanding the network flow.

gzip The GNU data compression program (by default installed at AIX 5L).

unzip A utility for unpacking zip files.

Note: None of these tools are really required, but they are helpful.



� Windows clients require an additional X Server software installed, such as Hummingbird Exceed. These X Servers usually require a valid license that can be requested from the appropriate vendor.

� Unix clients such as Linux based PCs do not require additional software. Furthermore, the connection seems to be faster and more stable than using X Servers on Windows clients.

� Be aware that a sudden network interrupt can corrupt your installation. Please note that some X Servers (including the built-in version of Linux) are able to refresh as soon as the network is up again. It is therefore worthwhile to check in advance with your X Server vendor. If you loose your Display in the middle of the installation process, we highly recommend that you start again from scratch.

Due to a number of problems that can occur using a Remote Display, it may not be reasonable to go with this approach, which would then require an installation in front of the target machine or a non-graphical installation.

The following example shows how to export the Display from the target AIX machine (IP address 9.24.105.133) to another machine, such as a Linux system (IP address 9.24.104.152).

Example 3-1 Export Display to a PC with Linux OS

bernie@stimpfle:~> xhost +9.24.105.1339.24.105.133 added to access control listbernie@stimpfle:~> telnet 9.24.105.133login: rootroot’s Password: # DISPLAY=9.24.104.152:0.0# export DISPLAY#

You can verify the setup by issuing the command xclock. An analog clock should then appear at your screen.

3.4.4 Description of how to set up AIX 5.1 prerequisitesThis section is intended to show how an AIX 5.1 machine (default installation) was prepared for WebSphere Portal installation.

This procedure may differ depending on the hardware you use. Consult your AIX Administrator if you feel unqualified to prepare the operating system for installation.


Installation of non-default packagesWebSphere Portal requires AIX packages that are not installed automatically on most hardware. We recommend adding three packages:

� X11.adt� X11.compat� bos.adt

To install these packages, open the AIX System Management Interface Tool (SMIT) and select them for installation.

1. Insert AIX 5.1 Disk #1 into your CD-ROM drive and make sure the disk is not mounted.

2. Open SMIT with a fastpath: smit install_software.

3. Choose your CD-ROM drive from the list (usually /dev/cd0).

4. Click List in the row of SOFTWARE to install.

5. Select all of the upper three packages as done with the X11.adt package in Figure 3-2.

Figure 3-2 Selecting additional AIX packages

Note: All procedures in this chapter must be done as root user.


6. Click OK to leave the package selection window and click OK again to start installing the selected software packages.

7. SMIT will ask you to insert another disk (see Figure 3-3). Make sure you click in the Output window to be sure it has the focus and then press Enter.

Figure 3-3 Changing disks for installation

8. After successful installation, leave the tool by clicking Done and then Cancel.

Resizing the file systemsThe default file system sizes are too small to install WebSphere Portal. It is required to add more space to the file systems.


Table 3-4 contains the file system sizes we recommend.

Table 3-4 Recommended values for the sample WebSphere Portal installation

Use SMIT to change a file system size. Issuing the command smit chfs leads to a window similar to Figure 3-4.

Figure 3-4 Changing the file system size using SMIT

1. Click Change Characteristics of a Journaled File System.

File system Original size New size Description

/ 32 MByte 320 MByte Have at least 100 MByte free

/usr 600 MByte 5.5 GByte Installation will use 2.5 GByte

/var 32 MByte 320 MByte Almost no space is required during installation process

/tmp 32 MByte 1.3 GByte Make sure you have plenty of space free (> 600 MByte)

/home 32 MByte 1.3 GByte Database will be created at this mount point

/opt 32 MByte 800 MByte About 100 MByte are required during installation


2. Select the mount point you intend to change.

3. Enter a new value in the field, SIZE of file system (in 512-byte blocks).

4. Click OK.

5. Close SMIT.

Do this for every mount point that requires a file system size change. You can check the file system sizes using the command df -k.

Announcing a CD-ROM drive to the operating systemTo be able to install WebSphere Portal from a CD-ROM drive, you must define a mount point inside AIX for it.

1. Open SMIT with the command smit.

2. Click System Storage Management (Physical & Logical Storage).

3. Click File Systems.

4. Click Add / Change / Show / Delete File Systems.

5. Click CDROM File Systems.

6. Click Add a CDROM File System.

7. Click List in the DEVICE name row to select your CD-ROM drive (for example cd0).

8. Choose a mount point by adding a value in the field MOUNT POINT (for example /cdrom).

9. Click OK.

10.Close SMIT.

Upgrading to the latest maintenance levelTo upgrade your operating system to the latest maintenance level, consult the documentation that should be part of the maintenance level package. If you did download the maintenance level from the Internet, make sure you follow the instructions that are provided on the Download page.

For this sample installation, the following procedure was used to install maintenance level 2 for AIX 5.1:

cd /usr/sys/inst.imagesgzip -d -c /tmp/510002.tar.gz | tar -xvf -

inutoc /usr/sys/inst.imagesinstallp -acgXd /usr/sys/inst.images bos.rte.installsmit update_all


As INPUT device/directory for software enter /usr/sys/inst.images.

Click OK to update all software packages.

3.5 Deploying WebSphere Portal in a production environment

There are various topologies that can be considered when deploying WebSphere Portal in a production environment. In Figure 3-5, we have provided a typical example of a WebSphere Portal topology and discuss how you might deploy each component displayed.

Figure 3-5 WebSphere Portal topology

Starting from left to right, we have the outer Firewall, securing your deployment from Internet or intranet. Inside the DMZ, we have a Proxy cascade followed by a Web server. Understand that you may only have a Network Dispatcher in the

Outbound Firewall DMZ Firewall Data Center Firewall

Rev

erse

Aut

hent

icat

ion

Pro

xy

IBMHTTP Server

Rev

erse

Cac

hin

g P

roxy

Rev

erse

Tra

nsc

odi

ng

Pu

blis

her

Pro

xy




WebSphere Portal

WebSphere Transcoding

Publisher

High Performance Clusters

User Registry Directory

User Registry Directory

Networked User Directories

Enterprise Data

High Availability Cluster

Outgoing Proxy

WebSphere Transcoding

Publisher

WebSphere Data


DMZ and all components, including the AuthProxy, behind the DMZ. You might also think about an inner DMZ and an outer DMZ, where the inner DMZ separates your environment from the intranet and the outer DMZ from the Internet. Consult one of the various documentations about deploying components in the DMZ. We intended to show what components you might consider in this zone.

Reverse Authentication ProxyA typical reverse proxy might be the WebSEAL component of Tivoli Access Manager. It authenticates users already at this point and decides if the request is allowed to be passed to the backend.

Ideally, this Authentication Proxy has a trust relationship with the WebSphere Application Server. Various Authentication Proxies come with a ready-to-use Trust Association Interceptor (TAI) for WebSphere Application Server. This is required to reach the status of a Single Sign-On solution. For more information, see Section 16.1, “3A: Authentication, Authorization and Administration of Chapter 16, “Portal Security” in the redbook IBM WebSphere Portal V4.1 Handbook Volume 3, SG24-6921.

Reverse Caching ProxyA typical reverse caching proxy would be the IBM Caching Proxy that is part of the IBM WebSphere EdgeServer product. It prevents forwarded requests for static content from going to the backend. Additionally, the IBM Caching Proxy can be used in conjunction with the WebSphere Application Server DynaCache functionality. DynaCache can help to cache even dynamically created parts of your page. WebSphere Portal is prepared to leverage the DynaCache functionality. Therefore, make sure your portlets use this functionality.

It is often seen that the caching and authentication proxy is deployed as a single software product. For IBM WebSphere EdgeServer, there is a authentication plug-in.

Reverse Transcoding Publisher ProxyDeploying WebSphere Transcoding Publisher in Server mode, it will act as a reverse proxy. You would choose this option if you want a transcoding capability in front of the WebSphere Portal to transform the complete output of the Portal. This is only recommended for page adjustments. That means, for example, making sure that a WML deck for a specific device exceeds not a certain number of bytes or transforming certain tags so that they are compliant for specific browser types. It is discouraged to transform complete pages from one markup to another, for example HTML to WML, as our experience showed that satisfying results were rare and performance impact is quite high.


You would only use such a proxy if there a valid reasons, such as scaling, to not use a portal filter instead.

Outgoing (forward) proxyAn outgoing proxy, usually a simple caching proxy that acts in forward mode, might be required by some of your Portlet applications. Portlets might require content or any other information from servers that are not inside your intranet section, where you deployed WebSphere Portal. So use such a proxy to be able to get data from such usually unavailable network segments.

WebSphere Application Server High Performance ClusterRefer to WebSphere Application Server scaling and clustering documents to understand the implications of vertical WebSphere Portal scaling.

It is important to understand that you must not separate the products as described in the box. So all vertical clusters do run the services of WebSphere Portal Core, WebSphere Personalization, WebSphere Member Services and WebSphere Transcoding Publisher.

Investigate carefully how to deploy the databases that most belong to those applications. You will especially need to consider the trade-off between performance and data integrity. You might for instance not want to share the WebSphere Application Server database to gain performance and consider it a reasonable trade-off, if the session data gets lost or in case one Application Server goes down for some reason. Depending on your applications, this will lead to a notable performance improvement. Use only this type of deployment if you fully understand the impact of session data loss.

For the WebSphere Portal and the WebSphere Member Services database, you are expected to have a high availability database cluster to be sure of your data integrity.

WebSphere Transcoding Publisher Backend ProxySome portlet applications might access backend applications and do nothing but transform the output from a specific markup to another. Using the Transcoding Publisher beans might lead to a notable performance, obviously depending on the amount of data that has to be transformed. In such a case, it might make sense to push the transcoding functionality again away from the servers that hosts WebSphere Portal. Reasons are usually not driven by developers but come more from an administrative (easier scaling of a certain functionality) or business (license costs) point of view.

You will, however, rarely find the requirement for such a high performance proxy cluster. We also had a positive experience with using application specific,


precompiled XSLT stylesheets and recommend those over markup transformation done by WebSphere Transcoding Publisher.

User Registry DirectoriesLDAP servers are used to host the user registries. It is common to not use a High Availability cluster for the LDAP server but use instead a network dispatcher in front of it and have a replicating LDAP server in standby mode beside it. As WebSphere Portal and other applications might access your LDAP directory frequently, it is recommended to host them nearby and to spread LDAP servers in your intranet landscape that replicate each other. This concept will also allow additional security rules.

Figure 3-5 on page 47 closes with a Datacenter Firewall that is often seen in environments that use ERP or similar backend systems. It was added to complete our sample topology picture.

3.6 Planning: general considerationsThis section documents several items to be considered before starting the WebSphere Portal install. These considerations apply to all operating systems unless otherwise noted.

3.6.1 Installing the Loopback AdapterIf you are planning to run stand-alone (on a single machine not connected to a network), you will need to simulate the network and a static IP address via a Loopback Adapter in order to install and run WebSphere Portal properly. In Linux the Loopback Adapter is usually already configured for the base Linux install.

For Windows, this is done by using the Microsoft Loopback Adapter which you need to install and configure. This section explains how to install and configure the Microsoft Loopback Adapter in Windows.

1. Select Start -> Settings-> Control Panel -> Add/Remove Hardware. This will invoke the Add/Remove Hardware Wizard (Figure 3-6).


Figure 3-6 Add/Remove Hardware Wizard invoked

2. Select Add/Troubleshoot a device and click Next.

3. While Windows searches for new hardware, you will see a window similar to Figure 3-7.


Figure 3-7 Hardware Device selection window

4. Select Add a new device and click Next. You will see a window similar to Figure 3-8.

Figure 3-8 Find New Hardware window


5. Select No, I want to select the hardware from a list. Click Next. You will see a window similar to Figure 3-9.

Figure 3-9 Hardware type selection window

6. Select Network adapters and click Next. After a few moments, you will see a window similar to Figure 3-10.


Figure 3-10 Network Adapter selection window

7. Select Microsoft from the left panel, then Microsoft Loopback Adapter from the right-hand panel. Click Next. You will see a window similar to Figure 3-11.

Figure 3-11 Start Hardware Installation window


8. Click Next to continue. After completion of the installation, you will see a window similar to Figure 3-12.

Figure 3-12 Hardware Addition completion

9. Click Finish to complete the installation.

10.Next, from your Windows desktop, click Start -> Settings -> Network and Dial-up Connections. You will see the new adapter installed as a new connection. You may confirm the device type by selecting it; it will be displayed at the bottom of the window (see Figure 3-13), or look in the Device Name column of the window.


Figure 3-13 Selection of the new connection displays type

11.You will need to specify the same DNS settings for the MS Loopback Adapter as you have specified in your Token Ring or Ethernet adapters. Right-click the connection and select Properties from the menu. Select Internet Protocol (TCP/IP) from the list of components and click the Properties button. You will see a window similar to Figure 3-14.

Figure 3-14 Setting IP Address for Loopback Adapter


12.Choose Use the following IP address then enter 10.10.0.1 for the IP address. Enter 255.255.255.0 for the Subnet mask.

13.Choose Use the following DNS server addresses and click Advanced. You will see a window similar to Figure 3-15.

Figure 3-15 Secondary IP address

14.Click Add, then enter 10.10.0.2 for the IP address and 255.255.255.0 for the Subnet mask as shown in Figure 3-15.

a. Click Add to close the pop-up window.

b. Click OK to close the Advanced TCP/IP Settings window.

c. Click OK to close the Internet Protocol (TCP/IP) Properties window.

15.Click OK to close the Local Area Connection Properties window.

Update hosts fileUpdate your hosts file to set IP address for your Loopback adapter (c:\winnt\system32\drivers\etc\hosts).

1. Add to your host file:


10.1.1.1 domain_name node_name

(example: 10.1.1.1 testitso.ibm.com testitso)

2. Then reboot Windows for this to become effective.

Additional optional stepThis step will help you to access remote Web sites and still utilize Microsoft Loopback adapter by auto-deleting route entry for the Loopback IP Gateway entry.

1. Run in a DOS window:

– ipconfig /all

Look for the MS Loopback adapter and note the IP address

(for example, 10.1.1.1)

– route print

This prints the IP routing in the window:

2. Create a batch file in the root directory.

– Create delroute.bat and enter the following:

@echo offroute delete 10.1.1.0 10.1.1.1 >c:\delroute.log 2>&1echo "delroute.bat has run" >> c:\delroute.log

3. Update the registry to call this batch file during Windows startup:

a. In DOS Window, call regedit

b. In regedit, navigate to:

KHEY_LOCAL_MACHINE -> Software -> Microsoft -> Windows ->CurrentVersion -> Run

c. Right-click Run and select New -> String Value

d. Name the new string value: DelRoute

e. In the right hand panel, right-click DelRoute -> Modify

f. In the modify field, enter: c:\delroute.bat

g. Close regedit

Reboot and then check the delRoute.log.

You should then be able to get to the outside Web and still use the Microsoft Loopback Adapter.


3.6.2 Network requirementsThere are only two major requirements towards the network setup for a WebSphere Portal installation.

� Fixed IP address

It is not sufficient, if you configure the server, to get an IP address from a DHCP server.

� Configured fully-qualified host name

It is required that the server know itself by the fully-qualified host name, also sometimes called fully-qualified domain name(FQDN). To be sure that this is configured correctly, you can check with a simple ping before you start installation. For our sample environment, the correct command would be

ping hostname.yourco.com

3.6.3 Installation optionsIn this section, we discuss the installation options.

Setup ManagerThe Setup Manager will install and assist in configuring all or part of the IBM and Lotus prerequisite products for WebSphere Portal including WebSphere Portal itself. Non-IBM or Lotus software, Microsoft Active Directory as an LDAP source for example, will be installed outside the Setup Manager. Setup Manager will assist in configuring some of the non-IBM/Lotus software.

The Setup Manager will install all these products on the same machine that is running the Setup Manager itself (a single tier topology). If a multi-tier topology is desired, a non Setup Manager install is required.

Important: Prior to your WebSphere Portal installation, disable your Token Ring adapter and Ethernet adapter. Having both the Loopback Adapter and Token Ring/Ethernet adapters enabled has been known to cause problems during installation. To disable your Token Ring and Ethernet adapters:

� Click Start -> Settings -> Network and Dial up-Connections.

� If Token Ring or Ethernet adapters appear, right-click the icon and disable them.


QuickA Quick install using the Setup Manager uses configuration information stored in a response file to install the WebSphere Portal components.

StandardA Standard install using Setup Manager allows the option of specifying a response file like the Quick Install, but also allows you to enter all the configuration information by going through the Setup Manager wizard. Setup Manager will install and configure the chosen components on the machine running Setup Manager (a single tier topology).

AdvancedIn an Advanced install using Setup Manager, you do not have an option of using a response file and Setup Manager invokes each prerequisite installation program as if you are installing it outside Setup Manager. Setup Manager still only installs the products on the machine running Setup Manager itself (a single tier topology).

Non Setup ManagerDoing a non Setup Manager installation, you are installing each prerequisite product independently (no Setup Manager is involved). For example, you would install IBM DB2, WebSphere Application Server, IBM Secureway Directory, WebSphere Personalization and WebSphere Portal all independently configuring them yourself as you proceed.

3.6.4 Installation planning worksheetsIn order to ensure a successful install it is highly recommended to do a planning worksheet before installation. An empty form is provided by the InfoCenter of WebSphere Portal at:

http://www-3.ibm.com/software/webservers/portal/library/enable/InfoCenter/wpf/inst_infotable.html

This worksheet gives you an overview of the values that get created on your system during the installation.

This section takes the installation planning worksheet from the InfoCenter and describes each value and gives some sample values.

Note: The following planning worksheets have been modified from the InfoCenter to include only the required values for WebSphere Portal.





IBM HTTP Server installationThis section describes all the values necessary for the WebSphere Portal install with respect to the IBM HTTP Server. If you are unsure of these values for your install, check with your Web administrator.

Table 3-5 Planning worksheet for IBM HTTP Server

IBM HTTP Server

Target data Example value Description

Installation directory /usr/HTTPServer (AIX)c:\IBM HTTP Server (Windows)/opt/IBMHTTPServer (Linux)

Directory where the IBM HTTP Server will be installed.AIX /Linux- you will not be asked for this value and it cannot be changed unless you are doing an advanced install or a non Setup Manager install.

IBM HTTP Server user name

httpadmin User that gets created and will own the IBM HTTP Server process (httpd).

IBM HTTP Server user group

httpgroup Group that gets created for the IBM HTTP Server user

� AIX- This is the name used for the Unix group that gets created.

� Windows - This value is not used. The HTTP Server user will automatically be added to the Administrators group.

� Linux - This value is not used. By default Linux installs as root.

IBM HTTP Server user password

Password for the IBM HTTP Server user..


DB2 installationThis section describes all the values necessary for the WebSphere Portal install with respect to DB2. Values and descriptions apply to AIX, Linux and Windows unless otherwise specified. If you are unsure of these values for your installation, contact your DB2 Administrator.

Table 3-6 Planning worksheet for DB2

WebSphere Application ServerThis section describes the values necessary for WebSphere Portal with respect to WebSphere Application server. Note that because our installations performed in this book were done using IBM DB2, we did not include the values for Oracle. We also documented the values for a local database used with WebSphere Application Server. See IBM Redbook, IBM WebSphere V4.0 Advanced Edition Handbook, SG24-6176 for installing WebSphere Application Server with a remote database.

Table 3-7 Planning worksheet for WebSphere Application Server

DB2


Installation directory /usr/lpp/db2_07_01(AIX)c:\SQLLIB (Windows)/usr/IBMdb2 (Linux)

The installation directory for DB2.AIX/Linux - you will not be allowed to specify this directory unless you are doing a non Setup Manager install or Advanced Setup Manager Install.

DB2 Administration User name

db2admin (Windows)db2as(Linux, AIX)

The administrative user for DB2.

DB2 Administration User password

The password for the DB2 administrative user.



WebSphere Application Server installation directory

/usr/WebSphere/AppServer (AIX)c:\WebSphere\AppServer(Windows)/opt/WebSphere/AppServer(Linux)

The installation directory for WebSphere Application Server.


WebSphere Application Server node name

hostname The node name is often identical to your host name and is case sensitive.

LTPA password ltpapwd The password WebSphere Application Server uses to bind to the LTPA source. Also the password WebSphere AppServer uses to create the private key (certificate) for the Single Sign On LTPA token.

WebSphere Application Server user name

wasadmin (Windows)root (Linux, AIX)

User that gets created and will own the WebSphere Admin Server processLinux/AIX - You are not asked for this value. It is assumed to be root.

WebSphere Application Server user name

Password for the WebSphere Application Server user

WebSphere Application Server - Database

Local Database user ID db2admin The user ID that will be used to connect to the WebSphere AppServer administration database.

Local Database password The password for the local database user.

Local Database name wasdbl (Linux, AIX)was40(Windows)

The name of the WebSphere AppServer administration database.

Local Database Alias name

wasdb (Linux, AIX)was40(Windows)

Name of the alias, that WebSphere Application Server uses to access its administration database.


LDAPThis section contains the LDAP values pertinent to working with WebSphere Portal. These values and descriptions apply to IBM SecureWay, Microsoft Active Directory and Lotus Domino unless otherwise indicated. If you are unsure of these values, contact your LDAP administrator.

For more information on setting up your LDAP structure, see “Determining a reasonable LDAP structure for WebSphere Portal” on page 66.

Table 3-8 Planning worksheet for LDAP (SecureWay, Domino and Active Directory)

Database Node Name LOOPBACK (AIX, Windows)“network id” (Linux)

DB2 node name used to connect from the database alias to the physical database. It is possible and save to change this value. Valid entries include IP addresses, hostnames and fully-qualified hostnames.AIX/Windows - LOOPBACK is an internal alias for the value 127.0.0.1.

Database Server Port 55555 The port, DB2 uses to connect from the DB2 client to the DB2 Server.

LDAP


LDAP installation directory /usr/ldap (AIX/Linux, SecureWay)c:\IBM\LDAP (Windows, SecureWay)/opt/lotus (Linux, Domino)

Installation directory for the LDAP software.AIX - you will not be allowed to specify this directory unless you are doing a non Setup Manager install or and Advanced Setup Manager Install.

LDAP Suffix dc=yourco, dc=com(Secureway)dc=itso, dc=ibm, dc=com (Active Directory)o=yourco (Domino)

The branch of the LDAP tree that WebSphere Portal will use to add its information.


Administrative user DN cn=root (Secureway)cn=administrator(Active Directroy, Domino)

The user that has authority to administer the LDAP source. The LDAP Administrative user name.

Administrative user password

Password for the Administrative user.

TCPIP port 389 The port that the LDAP source listens on for requests.

LDAP Proxy host proxy.yourco.com A proxy host that allows connections to other network resources.

LDAP server ldap.yourco.com The fully-qualified name of your LDAP server.

User DN Prefix uid(Secureway)cn (Active Directroy)cn (Domino)

See Determining a reasonable LDAP structure for WebSphere Portal

User DN Suffix dc=yourco, dc=com(Secureway)dc=itso,dc=ibm,dc=com(Active Directroy)o=yourco(Domino)


User Object Class inetOrgPerson(Secureway)user(Active Directroy)dominoPerson(Domino*)

See Determining a reasonable LDAP structure for WebSphere PortalDomino* - If using Domino Directroy Assistance (Domino LDAP referrals) use inetOrgPerson for interoperability across LDAP sources

Group DN Prefix cn(Secureway)cn(Active Directroy)cn(Domino)


Group DN Suffix cn=groups,ou=itso, o=ibm, c=us(Secureway)cn=users, dc=itso, dc=ibm, dc=com(Active Directroy)none(Domino)

See Determining a reasonable LDAP structure for WebSphere Portal Domino - no suffix


Determining a reasonable LDAP structure for WebSphere PortalThis section will give you enough background for using LDAP with WebSphere Portal. For further information on LDAP, you may refer to your LDAP documentation or the Redbooks:

� Using LDAP for Directory Integration, SG24-6163

� Understanding LDAP, SG24-4986

Depending on the type of installation, the WebSphere Portal core component requires a ready-to-use Lightweight Directory Access Protocol (LDAP) structure with at least two users inserted, the WebSphere Portal administrator and the user ID to bind to the LDAP source. These are commonly known as wpsadmin and wpsbind.

WebSphere Portal needs to know about your LDAP structure, since it has to write and read from it if you tell WebSphere Portal at installation to use an LDAP directory.

As the user directory is quite important to your business, you should consider how to build up a reasonable structure. If you feel that this is unnecessary, you may take the default values WebSphere Portal offers you during installation.

Most companies already use a LDAP directory and want to put users that are created by WebSphere Portal into a certain branch of their LDAP directory tree.

Listed below are a number of important terms that are used during installation of WebSphere Portal. If you do not understand a description, consult the documentation of your LDAP directory implementation guide and the Redbooks that are mentioned at the beginning of this section.

� User Object Class

All major LDAP directory implementations have pre-setup object class schemas, which are common. Such schemas define what entries a specific leaf in the LDAP branch is able to access. Example of entries would be surname, telephone, fax or even object class. Some of the fields can be

Group Object Class groupOfUniqueNames(Secureway)group(Active Directroy)dominoGroup(Domino*)

See Determining a reasonable LDAP structure for WebSphere PortalDomino* - If using Domino Directroy Assistance (Domino LDAP referrals) use groupOfUniqueNames for interoperability across LDAP sources


marked as required for this schema. So you might need to provide a value for a surname but not necessarily for the field of fax, for example.

The User Object Class defines which schema WebSphere Portal should assume for users. If possible, do not change this value, unless you know what you are doing.

� User DN prefix

Let us say you create a new user with the user ID stimpf86. The user ID will be used by your user to log in to your Portal.

At the creation of this user, WebSphere Portal will create a new leaf in the LDAP Directory. The name of the entry will be ‘User DN prefix’=’user id’,’User DN suffix’.

For example, with IBM SecureWay, if you leave the default value, which is uid, the entry will be called uid=stimpf86.

It is fairly common to have as User DN prefix cn instead of uid. This might however lead to confusion, as it should be possible to distinguish the common name clearly from the userid attribute.

� User DN suffix

This is the branch in the LDAP Directory, in which WebSphere Portal will look for users and to which it will add users.

The user Distinguished Name entry is ‘User DN prefix’=’user id’,’User DN suffix’.

Thus, if your DN is cn=mickey, cn=users, dc=youco, dc=com, WebSphere Portal creates a sub-branch (cn=users) by default to save your users. This is reasonable behavior, if you do not want to have group and user entries in the same place in your LDAP tree.

� Group Object class

Similar to the User Object Class, the Group Object Class defines where WebSphere Portal places groups. There are not many requirements to this schema. It just needs to be able to hold a list of User Object Class entries.

� Group Member

WebSphere Application Server Security will go for members of particular groups with an ID map request, ‘Group Object class’:’Group Member’, to find a specific user.

� Group DN prefix

This is the prefix used in front of groups. The default value is cn, which should be in most cases fine. So the name of a group would be for example cn=wpsadmins.

� Group DN suffix


This is the branch in the LDAP Directory, in which WebSphere Portal will look for groups and to which it will add groups.

Thus if your suffix is cn=groups,dc=yourco, dc=com, WebSphere Portal will create a sub-branch (cn=groups) by default to save your groups. This is reasonable behavior, if you do not want to have group and user entries in the same place in your LDAP tree.

Domino Application ServerThis section addresses the relevant values for Lotus Domino Application Server and WebSphere Portal.

Table 3-9 Planning worksheet for Lotus Domino Application Server

Domino Application Server


Path for program files c:\Lotus\Domino (Windows)/usr/lotus(AIX)/opt/lotus (Linux)

Installation path for the Lotus Domino Application Server program files.

Path for data files c:\Lotus\Domino\Data (Windows)/usr/notesdata(AIX)/local/notesdata (Linux)

Installation path for the Lotus Domino Application Server data files

Certifier Organization itso.ibm.com Creates the certificate used in the certifier id file for the notes network.

Certifier password Password used to access the certifier id

Host Name domino.yourco.com fully-qualified Internet host name of the Domino Server.

Server Name Domino/Yourco, Sametime/YourcoQuickPlace/Yourco

Abbreviated name of the server.


Web Content PublisherThis section contains the necessary information from Web Content Publisher for within WebSphere Portal. All descriptions and values apply to AIX, Linux and Windows unless otherwise noted.

Table 3-10 Planning worksheet for WebSphere Personalization

Administrative user:FirstNameMiddle NameLast Name

The first, middle and last name of the user who has authority to administer the Domino server. Note, to have an admin id of something like “dominoadmin”, enter only the last name as “dominoadmin” (leaving first name and middle initial blank).

Administrative user password

Password for the Administrative user.

LTPA keys file The full path name specified when the Export key... action was performed from the WebSphere Application Server Administration Console. File containing the SingleSignOn keys. These are imported into the Domino configuration record to generate the certificates.

LTPA password Password for the LTPA file.

Token domain yourco.com Domain or Realm for the SingleSignOn LTPA token.

Web Content Publisher


Database Administrator user

db2admin(Windows)db2as(Linux, AIX)

User ID to connect to the WCM Content Publisher database


WebSphere PersonalizationThis section details the WebSphere Personalization values needed for use with WebSphere Portal.

Table 3-11 Planning worksheet for WebSphere Personalization

Database Administrator password

Password for the Database administrator

Lotus Architect Installation directroy - Windows only

c:\lotus\architect (Windows)

Installation directory for Lotus Architect



Application Server Name WebSphere Portal Name of the Application Server, Personalization Server gets installed to. Do not change this value

Installation Directory Personalization will install the info center in the document root of the Web Server install and the rest of its components under the Application Server install directory.

Database Name By default with Setup Manager this cannot be changed and the WebSphere Administration database is used. Installing Personalization outside Setup Manager allows you to specify all the database properties.


Lotus CollaborationThis section details the values necessary for working with Lotus Collaboration in conjunction with WebSphere Portal. If you are unsure of these values, please check with your Lotus administrator.

Table 3-12 Planning worksheet for Lotus Collaboration

Lotus Collaboration


Discovery Server URL kds.yourco.com The fully-qualified name of the Discovery Server.

QuickPlace Server URL quickplace.yourco.com The fully-qualified name of the QuickPlace Server.

Sametime Server sametime.yourco.com The fully-qualified name of the Sametime Server.

Sametime Server HTTP Port

80 (unless HTTP tunneling is configured)

The HTTP port that Sametime is listening on. There are two options to installing the HTTP support with Sametime, direct HTTP (multiple HTTP ports) or with HTTP tunneling (one HTTP port).

WebSphere Portal root /usr/WebSphere/PortalServer (AIX)c:\WebSphere\PortalServer (Windows)/opt/WebSphere/PortalServer (Linux)

WebSphere Portal root used to find configuration files that are updated by Sametime(wps.war and hostAddress.xml).

WebSphere Application Server root

/usr/WebSphere/AppServer (AIX)c:\WebSphere\AppServer(Windows)/opt/WebSphere/AppServer(Linux)

WebSphere Application Server Install root. Collaboration updates the files CSEnvironment.properties so the Application Server can find the Collaboration components.

DB2 User name db2admin Collaboration updates the Member Services Database. This needs to be a user id with Authority to access the WMS database.


WebSphere PortalThis section details the values necessary for installing WebSphere Portal. Many of these values are derived from the previous tables for the WebSPhere Portal prerequisite products.

Table 3-13 Planning worksheet for WebSphere Portal

DB2 User password Password for the DB2 User above.

JDBC driver COM.ibm.db2.jdbc.app.DB2Driver

JDBC drive for accessing the WMS database.

JDBC URL jdbc:db2:wms JDBC URL for the WMS database

JDBC Driver location <databsehome>\java\db2java.zip

JDBC driver location

WebSphere Portal


Install Directory /usr/WebSphere/PortalServer (AIX)c:\WebSphere\PortalServer (Windows)/opt/WebSphere/PortalServer (Linux)

Installation directory for the WebSphere Portal.

Hostname portal.yourco.com This value requires the fully-qualified hostname of your server (see “Network requirements” on page 59).

Base URI /wps The prefix value of the Portal Application, that will appear in the URL right after the hostname. http://hostname/wps/portal

Home page /portal This is the shortcut to the Portal’s first page, which would then be here hostname/wps/portal.


Customized page /myportal This is the shortcut to the Portal’s secured pages, which would then be here hostname/wps/myportal. If you are not already authorized, you would be redirected to the login page.

Proxy host A proxy host, that allows connections to another network.

Proxy port The appropriate port for the above declared proxy host.

Portal - LDAP

Important: The values for the WebSphere Portal LDAP configuration must match the ones in Table 3-8 on page 64.

LDAP server ldap.yourco.com The fully-qualified host name of your LDAP server.

Administrative DN uid=wpsadmin, cn=user dc=yourco, dc=com(Secureway)cn=wpsadmin, cn=users, dc=itso, dc=ibm,dc=com (Active Directory)cn=wpsadmin (Domino)

The DN of the WebSphere Portal administration user.

Administrative Group DN cn=wpsadmins, cn=groups ou=itso, o=ibm, c=us (Secureway)cn=wpsadmins, cn=users, dc=itso, dc=ibm,dc=com (Active Directory)cn=wpsadmins(Domino)

The DN of the WebSphere Portal administration group.

Portal Database - DB2


Database name wpsdbWPS41

Name of the alias that gets created to connect to a local or remote WebSphere Portal database.

Database user db2admin (Windows)db2as(AIX,Linux)

This user will not be created by the Setup Manager. Therefore it must be a pre-existing DB2 user or a DB2 user, that gets created by other parts of the installer. A safe value is to use the same value used for the database user in Table 3-7 on page 62.

Database user password Password for the DB2 user above. Make sure you have this correct.

JDBC database driver COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource

The JDBC driver used to access the WebSphere Portal database.

JDBC URL prefix jdbc:db2 The prefix of the JDBC URL used to access the WebSphere Portal Database.

JDBC driver library /home/db2as/sqllib/java12/db2java.zip (AIX, Linux)c:\SQLLIB\java\db2java.zip (Windows)

Location of the JDBC libraries. On Unix systems the instance user is the same user as specified as Database user.

Portal Member Services Database - DB2

Database name wmsdb Name of the alias that gets created to connect to a local or remote WebSphere Member Services database.


Database user db2admin This user will not be created by the Setup Manager. Therefore it must be a pre-existing DB2 user or a DB2 user, that gets created by other parts of the installer. A safe value is to use the same value used for the database user in Table 3-7 on page 62.

Database user password Password for the DB2 user above. Make sure you have this correct.

JDBC database driver COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource

The JDBC driver used to access the WebSphere Member Services database.

JDBC URL prefix jdbc:db2 The prefix of the JDBC URL used to access the WebSphere Member Services Database.


Chapter 4. WebSphere Portal Setup Manager

WebSphere Portal now ships with a built-in installation tool called Setup Manager. In this chapter, we explore the WebSphere Portal Setup Manager. We examine the workings of the Setup Manager independent of the operating system. This is not an exhaustive exploration of Setup Manager, but you should be able to extrapolate the information presented in this chapter to your installation.

The WebSphere Portal Setup Manager goes through four basic phases:

� Pre-installation

All the steps necessary to set up Setup Manager.

� Determining the type of install

Determines the type of installation to be implemented along with the software to be installed and configured.

4


� Installation configuration

Collection of all the configuration information necessary to complete the desired type of installation.

� Installation

The actual installation of WebSphere Portal and the prerequisite products you have chosen to configure in the installation configuration phase.

The goal of this chapter is to provide some insight into what information Setup Manager is collecting with respect to the installations it perform for you. We also tie this information back to the installation planning worksheets found in 3.6.4, “Installation planning worksheets” on page 60.

It is highly recommended that you complete the planning worksheets (3.6.4, “Installation planning worksheets” on page 60) before starting an install.

4.1 Installing with Setup ManagerThe WebSphere Portal Setup Manager can automatically install WebSphere Portal and all of its prerequisite products. Following is a list of software products the Setup Manager assists in installing and configuring (this varies slightly based on operating system) for WebSphere Portal:

� WebSphere Studio Application Developer� WebSphere Site Analyzer� WebSphere Portal� WebSphere Personalization� WebSphere Application Server, Advanced Edition� Web Content Publisher� SecureWay Directory� Lotus Workflow� Lotus Sametime� Lotus Domino Application Server� Lotus Architect� IBM HTTP Server� DB2 Universal Database

There are several approaches to using Setup Manager to install WebSphere Portal and its prerequisite products.

Installing everything at onceSetup Manager can install WebSphere Portal and all its prerequisite products in one step. Setup manager collects all the necessary information for installing and configuring the desired software and then guides you through the install by telling


you what CDs to use, when to reboot and providing any necessary manual configuration steps.

Installing in stepsSetup Manager can also be used to install software in multiple steps. Using Setup Manager in this fashion, you can install and configure one or more elements at a time and then return at a later point using Setup Manager to add elements to your install.

Experienced installIn the same manner as installing in steps, Setup Manager can be used to install components on top of existing installs done outside of Setup Manager. For example, if you already have a WebSphere installation, you can use Setup Manager to add WebSphere Portal and collaboration to it.

In all cases, Setup Manager will install and configure the chosen components on the machine running Setup Manager, which can pose some challenges in building a multitier topology.

The first approach is the most automated approach; however, it is a very lengthy process and given its all-in-one nature, if there are problems, once completed they are sometimes more difficult to resolve. Thus, if new to WebSphere Portal, the second approach is recommended so that you can install in small steps, testing at each stage of the process to ensure that you are building a solid installation.

4.2 Setup Manager pre-installationIn this section, we discuss the pre-installation of Setup Manager.

4.2.1 Starting with Setup ManagerThe WebSphere Portal Setup Manager can be found on CD1 of the WebSphere Portal CDs. It is launched by one of the following commands based on operating systems:

� Windows - install.bat

� Linux, AIX, Solaris - install.sh

The WebSphere Portal Setup Manager then goes through a few pre-installation steps before the actual collection of installation information begins.

Chapter 4. WebSphere Portal Setup Manager 79

4.2.2 The IBMWPO directoryFirst, the Setup Manager process creates a directory on your machine and copies some files into it to be used during installation. You have no choice over where this directory is created. It is created for you as:

� Windows - c:\Program Files\IBMWPO

� AIX - /usr/IBMWPO

� Linux - /opt/IBMWPO

Setup Manager uses this directory for temporary files and as a work area during the install.

4.2.3 IBM Cross Platform TechnologiesThe majority WebSphere Portal Setup Manager is itself a Java application and therefore must have Java installed to run. The first thing Setup Manager does is to determine whether you have Java installed on your machine.

This is done by executing the Java version command and examining the result for the string java version 1.3. If the result does not contain the string or there is no result, then the Java installed is the wrong version or there is no Java installed, respectively, and Setup Manager will install the proper version of Java for you.

If it is determined that Java needs to be installed for use by Setup Manager, you will be informed as shown in Example 4-1 and the installation of Java will be started for you.

Example 4-1 Setup Manager - Could Not Find Java

Could not find Java. Setup will install one for you.

Setting up installation...done

Installing Java...

If on a Unix platform, the Java is installed via a silent installation. On Windows, the Java support for Setup Manager is installed via the IBM Cross Platform

Important: This directory will not be deleted upon the completion of the install. Do not delete this directory unless you are planning to reinstall. If you are going to reinstall with Setup Manager, you must delete this directory before you reinstall.


Technologies for Windows. The IBM Cross Platform Technologies for Windows will help you install the latest and IBM supported version of the Java Development Kit (JDK) under Windows. This install starts with the language selection as shown in Figure 4-1.

Figure 4-1 Cross Platform Technologies on WIndows - Choose Language

Once you have chosen the language for your install, you are walked through a standard JDK install on Windows starting with the Welcome window shown in Figure 4-2.

Figure 4-2 Cross Platform Technologies Install on Windows

After accepting the license agreement and specifying the install directory, the key thing to note is that you only need to install the CPT Toolkit Program Files, as shown in Figure 4-3.


Figure 4-3 Java Components needed by Setup Manager

Installing the other components does not affect the working of Setup Manager.

Also, when prompted to make this Java install your system JVM, as shown in Figure 4-4, you may choose either option. Selecting Yes will set this JVM as your default system JVM. This is not necessary for use with Setup Manager.

Figure 4-4 Install as System JVM

After completing the rest of the install, you will see a window similar to Figure 4-5 indicating that the install is complete.


Figure 4-5 Cross Platform Technologies installed successfully

Clicking Finish will close the IBM Cross Platform Technologies for the Windows install and return you to the command window as shown in Example 4-2, where the install program indicates the completion with the word done.

Example 4-2 Setup Manager - done



Installing Java...done

Once the IBM Cross Platform Technologies install is complete, WebSphere Setup Manager has everything it needs to proceed with the install.

4.3 Determining the type of installOnce the WebSphere Portal Setup Manager has everything it needs to run, Setup Manager proceeds with determining the type of install that needs to be performed.


The first window of the Setup Manager is shown in Figure 4-6, welcoming you to the install.

Figure 4-6 Checking prerequisites

Clicking the Prerequisites button will take you to the page (from the install CD) that has links to useful prerequisite information, as shown in Figure 4-7.


Figure 4-7 WebSphere Portal Prerequisite Information

Clicking Next on the Welcome window (Figure 4-6), the Setup Manager examines your system for the necessary prerequisite software. You will be informed if you are not compliant with the software prerequisites (for example, if you have an incorrect operating system version). Note that the only check done at this point is a check for the operating system requirements.

You must fix the prerequisites before Setup Manager allows you to proceed.

Once you are compliant with the prerequisite software, you are asked to accept the license agreement as shown in Figure 4-8.


Figure 4-8 License Agreement

Accepting the license agreement, you are prompted to enter your installation key.


Figure 4-9 Installation key

Your installation key is provided to you with your software and directly correlates to the version of WebSphere Portal you have purchased. Depending on your key, the Setup Manager will guide you through the install for WebSphere Portal Enable, Extend or Experience. For the purposes of this chapter, we have used a WebSphere Portal Extend key.

Enter your installation key; you are prompted for the type of install (see Figure 4-10).


Figure 4-10 Select Type of Install

There are three types of install that Setup Manager can perform:

� Quick install

� Standard install

� Advanced install

Each type of install gives varying degrees of flexibility on the install, but the only topology supported by allowing the Setup Manager to install a prerequisite software is a single tier topology.

For the purposed of this discussion we chose a Standard install.

Note: Setup Manager can configure some multitier topologies, having installed the tiers independent of Setup Manager.


� Quick install:

The Quick installation uses configuration information stored in a response file to automatically install the WebSphere Portal components. An example response file, <cddrive>\install\responsefile\wporecord.script, is on CD 1. If you choose to use the example response file, you must modify it as it is simply an example and cannot be used as is.

During a Quick Installation, Setup Manager prompts you to change CDs, but you are not required to enter any configuration information. Configuration information is obtained from the response file in conjunction with predefined defaults.

Setup Manager creates a response file at <ibmwpo_dir>\responsefile\wporecord.script during a Standard install that can be used later.

� Standard install:

With Standard installation, you can choose to use a response file or not. Whether or not you choose to use a response file, you will still be prompted for configuration information. In the case of using a response file, the configuration information is prefilled with the information from the response file and you have the opportunity to override it for this particular install.

In a Standard install, you choose the products you would like to install and Setup Manager collects configuration information based on the products you have chosen.

During a Standard install, a response file is generated during the installation process that can be used for future installs.

� Advanced install:

An Advanced install does not use a response file. In performing an advanced install, the individual installation programs for each piece of software you have chosen to install are invoked. Information concerning the interdependencies of the software is collected by the Setup Manager but the majority of the configuration information is collected via the individual install programs of each piece of software.

An Advanced install is very much like installing without the use of Setup Manager.

Once you have chosen the type of install you would like to perform, you are prompted for the response file as shown in Figure 4-11.


Figure 4-11 Select a response file

You may choose a response file if you wish. If you are not using a response file, leave this field blank and continue by clicking Next.

The last part of determining the install type is selecting the components you want to install. Figure 4-12 and Figure 4-13 show all the components available for installation on Windows. Note that the list varies slightly by install platform.

Tip: Setup Manager will create a response file during this installation procedure and place it in:

� AIX - /usr/IBMWPO/scripts/wprecord.script

� Linux - /opt/IBMWPO/scripts/wprecord.script

� Windows - c:\Program Files\IBMWPO\scripts\wpsrecord.script

This file might be used with the Quick install option on the same machine or with slight changes on a similar machine.


Figure 4-12 Component selection

Notice that the components selection will indicate the appropriate version of part of a component software may already be installed. This can be seen for the Domino Clients software shown in Figure 4-13.

Important: If you plan to install WebSphere Site Analyzer, please read 18.4, “Planning” and 18.5, “Installation using Portal Setup Manager” in the IBM Redbook, IBM WebSphere Portal V4.1 Handbook Volume 3, SG24-6921.


Figure 4-13 Component selection

Once all of the components have been selected, the type of install is completely determined and configuring the installation starts.

4.4 Installation configurationThe next phase of the Setup Manager process is collecting all the configuration information for the components to be installed. This section walks through each component available on the Windows platform. Per platform, the available


component list varies slightly. However, most of the configuration information is the same for each platform.

You will notice that the left panel of the Setup Manager install window (Figure 4-14) contains a list of all the components to be installed. As we proceed through the install, this panel will show us where we are in the configuration process. This is a complete list of all the components we have chosen to install. This list will vary depending on what components were chosen as shown in Figure 4-12 on page 91 and Figure 4-13 on page 92.

The first step of installation configuration is to check the previous installs (see Figure 4-14). This check examines the machine for any of the components Setup Manager knows about to determined in they are already installed.

If an incompatible version of a component software is discovered, you are prompted to uninstall it.

Figure 4-14 Checking the previous installations

In our example, Setup Manager has found the Global Security Toolkit and Domino Clients already installed and the versions of this software are fine, so no


action will be taken. We previously noted Domino Clients was installed in Figure 4-13 on page 92.

Clicking Next, the system requirements are checked. The check done at this point is for disk space and memory.

If you satisfy the system requirements, then Setup Manager starts asking for configuration information for each of the selected components.

The following sections examine each of the Setup Manager components with respect to their configuration information.

4.4.1 IBM HTTP ServerThis section examines the installation of the IBM HTTP Server via the WebSphere Portal Setup Manager.

The IBM HTTP Server will be installed if:

� You choose it directly as a component

� You choose the WebSphere Application Server component

� You choose the SecureWay Directory component

You can deselect the IBM HTTP Server in the case of choosing the WebSphere Application Server or SecureWay.

The information Setup Manager requires to install and configure the IBM HTTP Server is the same information collected in the planning worksheet for the IBM HTTP Server in “IBM HTTP Server installation” on page 61.

To install the IBM HTTP Server with Setup Manager, first enter the installation directory for the IBM HTTP Server (see Figure 4-15).


Figure 4-15 IBM HTTP Server Installation

Click Next, and enter the administration ID that is used for the IBM HTTP Server.


Figure 4-16 IBM HTTP Server Administration ID

This is the user ID that will own and manage the IBM HTTP Server process. Setup Manager will create the user ID giving the appropriate permissions for the given operating system. On Unix-based platforms, the user’s group will also be created and the user will be placed in that group if appropriate.

It is recommended that you change the permissions on this user ID to meet your security guidelines once the installation is complete.

This completes the configuration of the IBM HTTP Server through WebSphere Portal Setup Manager.

4.4.2 DB2 Universal DatabaseDB2 Universal Database is a Web-enabled relational database management system. In the WebSphere Portal environment, DB2 stores portal configuration data, as well as portal-specific data, access-control data, and user data.

Setup Manager will install and configure DB2 if it was chosen directly as a component or if you have chosen SecureWay as a component to install.


The configuration information collected by Setup Manager for the DB2 install corresponds to the information collected in the planning worksheet for DB2 in “DB2 installation” on page 62.

Setup Manager first collects the installation directory for DB2 (see Figure 4-17).

Figure 4-17 DB2 installation directory

Following the installation directory for DB2, Setup Manager collects the user ID and password of the user that will administer DB2 (see Figure 4-18).

Note that this user ID will be created for you with the appropriate permissions for the given operating system.


Figure 4-18 DB2 administration ID

WebSphere Portal requires DB2 UDB 7.2 FP5, so you will see DB2 Universal Database Fixpack 5 in the installation list (Figure 4-18). However, you will not be asked for any configuration information with respect to the fixpack because Setup Manager has all the information it needs to install the fixpack already.

4.4.3 IBM SecureWayWebSphere Portal will install two LDAP sources, Domino and Secureway. This section addresses the installation of IBM SecureWay for use with WebSphere Portal using Setup Manager.

IBM SecureWay Directory is a lightweight directory access protocol (LDAP) directory that runs as a stand-alone daemon. In the WebSphere Portal environment, it stores, updates, and retrieves user-specific data related to authentication, such as user IDs and passwords.

Setup Manager first asks for the installation directory for SecureWay (see Figure 4-19).


Figure 4-19 SecureWay Directory installation location

Setup Manager then requires the LDAP configuration information. This is the same information you collected in the LDAP planning worksheet found in “LDAP” on page 64.

Figure 4-20 shows the LDAP configuration information required by Setup Manager for installing and configuring SecureWay.


Figure 4-20 SecureWay LDAP Suffix Information

As shown in Figure 4-20, you must specify:

� LDAP Suffix

This is the branch of the LDAP tree where WebSphere Portal will place its information.

� Administrative user and password

The user with authority to administer your SecureWay LDAP.

� TCPIP port

The TCPIP port SecureWay will use to listen for request. This can be changed, but it is not recommended.

You will be asked for the WebSphere Portal specific information when Setup Manager collects the information for installing and configuring WebSphere Portal.

Important: It is recommended that the suffix be entered in lowercase; it must contain no spaces.


4.4.4 WebSphere Application ServerIBM WebSphere Application Server V4.0, Advanced Edition (V4.0.2) is a Web application server that provides J2EE services for the WebSphere Portal environment. It executes the Java portlets, JavaBeans, JavaServer Pages (JSP) files, and Enterprise JavaBeans (EJBs) used by WebSphere Portal. This component is the platform on which the WebSphere Portal component runs.

This section details the configuration information required by Setup Manager to install and configure WebSphere Application Server. This information corresponds directly to the information collected in the planning worksheet found in the section “WebSphere Application Server” on page 62.

The first piece of information required for the installation and configuration of WebSphere Application Server is the administration ID and password (see Figure 4-21).

Figure 4-21 WebSphere administration ID

Following the Setup Manager requires the installation directory for WebSphere Application Server (see Figure 4-22).


Figure 4-22 WebSphere Application Server installation directory

Next, Setup Manager collects the configuration information for the WebSphere Application Server administration database. This is the database used by the application server to store configuration, security and administration information. For more information on the use of this database see the IBM WebSphere V4.0 Advanced Edition Handbook, SG24-6176.

The first piece of information for the WebSphere Application Server administration database whether or not the database is local. There are two choices for the location, local and remote. In Figure 4-23, Setup Manager asks if the administration database is remote.


http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246176.pdf

Figure 4-23 WebSphere Application Server install with local database

Answering No to the question in Figure 4-23 says that the WebSphere administration database is local. Setup Manager will create and catalog the database locally for you.

If you answer Yes to the question in Figure 4-23, Setup Manager will simply catalog the remote database for you. Setup Manager cannot create the WebSphere administration database on a remote machine for you. You must create the database prior to this install and then Setup Manager can set up and configure WebSphere Application Server to use it.

Next, you must specify the administration database type. Setup Manager supports installing the administration database with DB2 and Oracle as seen in Figure 4-24. Note, Oracle is not covered in the scope of this book.

Configuring any other database type for the WebSphere Application administration database requires a non Setup Manager installation of WebSphere Application Server.


Figure 4-24 WebSphere Application Server database type

Next, you must specify the user ID and password that the WebSphere Application Server will use to connect to the administration database. This is the instance owner of the DB2 database. This user will be created by Setup Manager and placed in the appropriate operating system user groups (on the Unix based platforms you are required to specify the group, on Windows the user is added to the administrators group). This is the user ID that will be used to manage the WebSphere Application Server administration database.


Figure 4-25 WebSphere Application Server database administration id

Finall, Setup Manager collects the configuration for the WebSphere Application Server administration database. This configuration information differs, depending on whether the administration database is local or remote (specified in Figure 4-23).

Figure 4-26 shows the configuration information for a local administration database. These values correspond directly to what you collected in the planning worksheet for WebSphere Application Server (“WebSphere Application Server” on page 62). You must specify:

� Local Database name

Name of the local administration database.

� Local Taxable alias

Alias for the local administration database.

� Node name

The DB2 node name used to connect from the alias to the physical database.


� Database server port

The port used to connect to the DB2 server.

Figure 4-26 WebSphere Application Server local database settings

Figure 4-26 shows the configuration information for a remote administration database. These values correspond directly to what you collected in the planning worksheet for WebSphere Application Server (“WebSphere Application Server” on page 62). You must specify:

� Local Database name

Name of the local administration database on the remote machine. The name of the database as the remote machine knows it.

� Remote Database name

Remote name of the administration database. The name of the databases as known by remote machines.

� Remote Database user ID

The user ID used to connect to the remote database.


� Node name

The DB2 node name used to connect from the alias to the physical database.

� Database server port

The port used to connect to the DB2 server.

Figure 4-27 WebSphere Application Server remote database settings

The Setup Manager install list also contains the WebSphere Application Server Security and the WebSphere Application Server fixpack. Setup Manager enables security to work with WebSphere Portal for you if you choose to do so. The WebSphere Application Server fixpack is installed since it, along with several eFixes, is required by WebSphere Portal. You are not asked for any more configuration information with respect to these two options. Setup Manager has already collected the necessary information.

4.4.5 PersonalizationWebSphere Personalization is a browser-based development tool and runtime environment that enables developers who use WebSphere Application Server and IBM WebSphere Studio Application Developer to create personalized portal


pages. It includes tools for customizing WebSphere Portal for each site visitor and supports two personalization technologies: rules-based personalization and recommendation engine collaborative filtering.

WebSphere Portal Setup Manager will install and configure WebSphere Personalization. WebSphere Personalization and WebSphere Portal are codependent with respect to install.

� To install WebSphere Personalization so that is usable with WebSphere Portal, you must have Application inside the WebSphere Application Server called WebSphere Portal. Note that it must have this name.

� To install WebSphere Portal requires WebSphere Personalization since WebSphere Portal uses libraries of WebSphere Personalization even during the installation process.

To avoid this problem, Setup Manager chooses the first option of installing WebSphere Personalization into an existing Application Server named WebSphere Portal.

Therefore, to install WebSphere Personalization with Setup Manager, enter the Application Server name as WebSphere Portal (see Figure 4-28).


Figure 4-28 WebSphere Personalization Server

This is the only information Setup Manager requires for installing and configuring WebSphere Personalization.

4.4.6 WebSphere PortalThis section examines all the configuration information collected by Setup Manager for the install and configuration of WebSphere Portal.

The first step for installing WebSphere Portal is the selection for the type of install to be performed (see Figure 4-29).

Important: The Application Server name must be WebSphere Portal.


Figure 4-29 WebSphere Portal install type

There are two types of installs supported by WebSphere Portal:

� Typical

A Typical install requires that you use a relational database and an LDAP directory. This is usually used for a runtime environment setup.

� Development

A Development install does not require an LDAP source. All user information is stored in a database. A development install is done for use with WebSphere Application Server Single Server for use in development environment.

Next, Setup Manager requires you to determine how your Portal Member Services stores its authentication information (see Figure 4-30).


Figure 4-30 WebSphere Portal Authentication Mode

Member Services is a WebSphere Portal component that manages users and groups. It is the component that keeps track of all the Portal members and their attributes including group membership (for more information on Member Services See the WebSphere Portal InfoCenter).

There are three options for storing Member services authentication information:

� Database only mode:

All users will be stored in a proprietary format in one of the internal tables of the WebSphere Portal database. No other applications will be able to access user information without going through WebSphere Portal. For this installation mode, no LDAP Directory is required. Please refer to the product guide to understand the various restrictions that might apply using this installation type.

� Database and LDAP Directory mode:

This is the standard mode to use with WebSphere Portal. Basic user information, such as name and password are stored in a LDAP Directory and


http://www7b.software.ibm.com/wsdd/zones/portal/V41InfoCenter/InfoCenter/wpf-ext/en/InfoCenter/index.html

can be accessed by all applications that support the open LDAP protocol and have permissions to access the information.

Extended user information and Portal specific data will be held by WebSphere Portal database or WebSphere Member Service database.

This installation mode requires an LDAP directory such as the SecureWay Directory Server, Active Directory, iPlanet or Domino.

� Custom User Registry mode:

A custom user registry allows you to use, for example, a legacy system to hold your users. You would need to provide a proper Custom User Registry implementation. Check the WebSphere Application Server documentation to get more information about how to implement a custom user registry or check the WebSphere Application Server InfoCenter.

If you intend to use a Custom User Registry, do the following:

a. Install WebSphere Application Server on its own first.

b. Implement the Custom User Registry code into WebSphere Application Server and make sure your code works without any problems.

c. After you have a proper setup established, install WebSphere Portal.

Setup Manager can configure WebSphere Application Security. If you want Setup Manager to configure global security in for the WebSphere Application Server, select Now (seen Figure 4-31).

Only choose Later if you have WebSphere Application Server already installed and global security is enabled, otherwise Setup Manager will fail.


http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/was/0502.html

Figure 4-31 WebSphere Portal Security Configuration

Setup Manager next asks for the LTPA password (Figure 4-32). This is the password that WebSphere Application Server will use to bind to the LDAP source. This value LTPA password that was collected in Table 3-7 on page 62.

Important: If you use a preexisting WebSphere Application Server which had global security configured, you must provide exactly the same LTPA password that you have entered before. This does also apply if security is currently disabled. Otherwise, you will not be able to start WebSphere Application Server and it will cause an install failure.


Figure 4-32 WebSphere Portal LTPA password

In the next step of Setup Manager, the WebSphere Portal configuration parameters are collected (Figure 4-33). These are the values determined from the planning worksheet in Table 3-13 on page 72.


Figure 4-33 WebSphere Portal configuration

� Install Directory:

The directory WebSphere Portal will be installed. The default directory on AIX is /usr/WebSphere/PortalServer and is a good choice. Changes to the default will not lead to problems.

� Hostname:

The fully-qualified hostname of the WebSphere Portal machine. If the value Setup Manager recommends is not correct (for example it shows only the hostname instead of the fully-qualified hostname) you should double check your network environment. Your prerequisites might not be correct.

� Base URI:

The base URI that will appear in all links that point to WebSphere Portal. If you do not like to have this prefix to all URLs, you may insert a slash (/) only. Please note that Setup Manager will then need to change the settings of the Default Server in the WebSphere Application Server as it already occupies the resource slash (/).


� Home page:

The Portal URL includes the fully-qualified host name of your WebSphere Portal appended with a Web path (base URI) and the name of the default page. Make sure that no other Web application in your WebSphere Application Server uses a Web path that you want to use for the portal. This value defines the last part of the URL that is used to access the public resources of WebSphere Portal. Public resources are resources that do not require authentication. This value must not be empty.

If you want to install the portal with the root Web path, for example, to get the home page http://server.yourco.com/myportal, you must redirect the application that normally uses this path. This is generally the default_app. To do this, you must already have WebSphere Application Server installed.

Before you install WebSphere Portal, make sure that no other Web application in your WebSphere Application Server uses a Web path that you want to use for the portal. The configuration instructions in this section are required if the following is true:

– Default Server is installed on WebSphere Application Server.

– You want to install your portal with a URI that does not contain wps as a domain component in the URI. For example, you want to set up your portal as www.yourco.com/portal, and not with a URI such as www.yourco.com/wps/portal.

If the preceding is true, you can change the Web Application Web Path of a Web Application called default_app to obtain the desired URI. To do this, perform the following steps:

• Start the Administrative Console.

• Select Node Default Server Default Servlet Engine default_app.

• Change the Web Application Web Path from "/" to any unique value, for example /default. Make sure that you do not use a URI that is already in use within Application Server.

• Click Apply.

• Restart the Web Application default_app.

� Customized page:

This value defines the last part of the URL that is used to access non-public resources that is resources that require authentication. The value must not be empty and must differ from the value above.

� Proxy host:

If your WebSphere Portal host does not have direct access to a certain network, like the Internet, but resources such as portlets shall have access to


the Internet you need to provide a Proxy hostname that allows that access. You can easily configure this after installation as well.

You cannot provide here a SOCKS Server hostname.

� Proxy port:

The appropriate port for the Proxy host as described above.

Next, you specify configuration parameters for the LDAP server to be used with WebSphere Portal as seen in Figure 4-34.

Figure 4-34 WebSphere Portal LDAP server type

First, you select the LDAP server type. Setup Manager can install and configure SecureWay Directory (4.4.3, “IBM SecureWay” on page 98) and Lotus Domino Application Server (4.4.7, “Lotus Domino Server” on page 127) for you. iPlanet and Active Directory must be installed an configured outside Setup Manager to be used with WebSphere Portal.


Setup Manager can, however, configure WebSphere Portal to work with any of the four LDAP sources once they are installed and configured. To specify the necessary information for this task, specify the following:

� LDAP Server:

The fully-qualified hostname of the LDAP Server. Installation will fail if you only use the short name, such as localhost (Table 3-13 on page 72).

� User DN:

This is the distinguished name of the LDAP Administrative User. If you need to change this value, remember to not put in just the user name but the distinguished name of the user (Table 3-13 on page 72 and Table 3-8 on page 64).

� User password:

The proper password for the LDAP Administrative User (Table 3-8 on page 64).

� Suffix:

The base tree in which WebSphere Portal will add its branches. This value corresponds to the value used in configuring the LDAP source (for example, as seen in Figure 4-20 on page 100 for SecureWay) and is also the same as collected in the LDAP planning worksheet (Table 3-8 on page 64).

� LDAP port number:

Leave this value to 389, as it is the default port for LDAP to communicate unencrypted.

Next, Setup Manager collects all the LDAP configuration information WebSphere Portal will use to communicate with the LDAP source. See Figure 4-35.


Figure 4-35 WebSphere Portal LDAP configuration

The User and Group information is collected as specified in the LDAP planning worksheet, Table 3-8 on page 64.

The Administrator DN and Administrative Group DN are the user and group that will be used to administer the WebSPhere Portal itself. These are the values we chose in the WebSphere Portal planning worksheet, Table 3-13 on page 72.

Next, we specify all the configuration information for the WebSphere Portal database in Figure 4-36.


Figure 4-36 WebSphere Portal database selection

� Database backend

Setup Manager can configure the WebSphere Portal database in DB2 or Oracle. Our examples in this book apply to DB2.

� WebSphere Portal database configuration scripts

– Create and initialize a new database (DB2 only)

If we have chosen DB2 as our backend data source, Setup Manager can create and initialize the WebSphere Portal Database for us. Note, this will be a local database. If we want a remote database, we must create the database outside Setup Manager and choose the following option to initialize the database.

If we have chosen Oracle, we need to create the database outside Setup Manager and choose the following option to initialize the database.


– Initialize an existing database

Use this option if you have already created the database. Setup Manager will then populate the tables and the appropriate data. This option can be used to configure a remote database.

– Use an existing and initialized database

Setup Manager assumes you have already set up your database correctly. It will therefore not touch it, as it should be ready to use.

� Do you want to share the database with Member Service?

Either way, you will end up with a problem that might be an issue in a frequently used installation, for example one with production purposes. In the post-installation instructions, we show how to solve it. Both, however, are fully supported setup variations. Discuss with your Database Administrator the most reasonable setup. In this example we will share the database.

– Share the database

Setup Manager will only create a single database that is used by WebSphere Portal and WebSphere Member Service. If you choose to share the database, make sure you follow the post install instructions for your installation to update the database configuration.

– Do not share the database

Setup Manager will create two separate databases: the WebSphere Portal database (commonly known as WPS41) with 63 tables and the WebSphere Member Service database (commonly known as WMS) with 40 tables.

In a production situation, you generally do not want to share the database because the access patterns of the WebSphere Member Services database and the WebSphere Portal database are different and would be tuned differently.

However, Oracle has substantial overhead in creating a database, for example, in which case the overhead may not outweigh the tuning advantages; thus you would want to share the database.

Next we specify the additional configuration parameters for the WebSphere Portal database (Figure 4-37).


Figure 4-37 WebSphere Portal Additional Database Configuration

These configuration values correspond to the ones in the WebSphere Portal planning worksheet (Table 3-13 on page 72).

� Database name:

It is really the database alias name, the name of the database, as WebSphere Portal sees it.

Do consult the DB2 Administration Handbook, if you need more background information on databases and database aliases.

� Database user:

This user will not be created by the Setup Manager. Therefore, the user must be preexisting or must be created by another subcomponent of the Setup Manager. The user needs to be a valid DB2 instance user, as it will be required to own the appropriate DB2 processes. Its task is to manage the database(s) for WebSphere Portal.

Important: The name can only contain 1-8 characters! To avoid potential problems, do not use special characters such as @, #, and $.


� User password:

Use an appropriate password if you use the same user as for WebSphere Application Server.

� JDBC database driver:

Use the appropriate JDBC database driver for your database. See the configuration information in the WebSphere Portal planning worksheet (Table 3-13 on page 72).

� JDBC URL prefix:

For DB2, leave the default value, which is jdbc:db2

� JDBC driver library:

Make very sure you issue a correct path to your JDBC driver. For DB2 it consists of:

<DB2 install directroy>/sqllib/java12/db2java.zip

For example, a path like:

/home/db2inst1/sqllib/java/db2java.zip

could have two mistakes incorporated.If we want to use the Unix user wasuser to manage the databases, it would point to the wrong home directory and as it states java instead of java12 it would point to the wrong version of the JDBC driver. A JDBC 2.0 driver is required for WebSphere Portal.

The correct path for our example would be:

/home/wasuser/sqllib/java12/db2java.zip

Note: It is highly recommended that you use the same user name that is used for the WebSphere Application Server. This will let you bypass potential problems.


Figure 4-38 WebSphere Portal WMS Shared database options

Next, we configure the WebSphere Member Services databases. If we chose to share the databases in Figure 4-36 on page 120, we have the choice of initializing the Member Services database or using an existing one.

If we have chosen not to share the databases in Figure 4-36 on page 120, we have another option available to create the database and will then need to specify the configuration information for the Member Services database (see Figure 4-39).


Figure 4-39 WebSphere Portal WMS not shared configuration options

The last piece of information to be configured for WebSphere Portal with Setup Manager is the License server, Figure 4-40.


Figure 4-40 WebSphere Portal License Use Management

License Use Management (LUM) is an IBM tool for managing and extending software licenses. When you install the WebSphere Portal component, Setup Manager prompts you either to install a LUM server (locally) or to point to an existing one elsewhere on your network.

If you choose to point to an existing LUM server, you are prompted for its fully-qualified hostname and can use the licenses previously enrolled on it. If you choose to install LUM locally, the LUM installation program installs and configures LUM as a network license server, enrolls the WebSphere Portal product in the LUM database, and then checks out the number of licenses corresponding to the number of processors you have online on the local server machine. The program also installs LUM client code that enables the LUM server to communicate with WebSphere Portal.

After you install the LUM server, you can use the LUM Basic License Tool to view the license usage and run reports. For more information about LUM, see Using License Use Management Runtime (available in PDF format) at the following:

http://www.ibm.com/software/is/lum/library.html




4.4.7 Lotus Domino ServerWebSphere Portal Setup Manager will install and configure the Lotus Domino Server. Lotus Domino Application Server is a collaborative application server that provides a secure infrastructure for all sorts of collaborative applications. In this section, we examine the installation and configuration of Lotus Domino for use with WebSphere Portal.

The Lotus Domino install starts with Figure 4-41, where you choose the type of configuration you would like for the Domino Server.

Figure 4-41 Lotus Domino Server Configuration Type

There are three configuration choices with the Domino Server:

� Default Configuration

Installation of Lotus Domino as an Application Server

� LDAP Server

Installation of Lotus Domino as an LDAP Server


� Web Content Publisher

Lotus Domino will be installed with Work Flow to be used with Web Content Publisher.

Once you have chosen the type of Lotus Domino configuration, Setup Manager asks for the server configuration. There are three choices, as seen in Figure 4-42.

Figure 4-42 Lotus Domino Install Type

� Domino Application Server

Provides the most generalized settings for Domino Server. Domino Server will be configured for mail and applications, such as Sametime and Quickplace.

� Domino Mail Server

Domino Application Server will be installed and optimized for use as a mail server. In general, you would not choose this option because most shops that use Domino as a mail server already have the Domino Mail Server installed and configured and it can be used with WebSphere Portal.


� Domino Enterprise Server

This is a Domino Application Server with added support for clustering to provide high availability servers. It allows for partitioned servers, multiple domain servers on the same machine, to be configured once the Setup Manager installation and configuration are completed.

Once the installation and configuration options for the Lotus Domino Server have been identified, you must specify where the program and data files are installed as seen in Figure 4-43. These are the same directories you specified in the planning worksheet in Table 3-9 on page 68.

Figure 4-43 Lotus Domino Install Location

Setup Manager then needs all the Server configuration information. This information was identified in the Lotus Domino planning worksheet Table 3-9 on page 68.


You must specify the following information concerning the Lotus Domino domain:

� Domino Name

The name of your Domino domain.

� Certifier Organization

The organization will be used to create the certificate in the certifier ID file (by default cert.id) to be used in your Domino domain.

� Certifier Password

The password used to access the certificate in the certifier ID file.

� Server Name

The abbreviated name of your server.

� Hostname

The fully-qualified Internet host name of the Domino Server.


Figure 4-44 Lotus Domino Server information

In Figure 4-44, you must also specify the administrative information for your Domino server. As seen, you specify the first name, middle name and last name of the administrative user along with the administrators password.

The last piece of information for the Domino Server configuration is whether to allow an anonymous login. Choosing not to allow an anonymous login shuts off

Important: If your Domino administrator ID is a single name, such as dominoadmin, enter the name in the last name field leaving the first and middle names blank.


anonymous login and adds enables extra security to lock down the Domino Server. This is not a problem if using Domino as an LDAP server. If Domino collaboration is going to be used, this will cause collaboration not to work. To make sure your configuration works effectively with the Collaboration components, make sure to consult the step for integrating with Domino in the WebSphere Portal Collaborative Components Redpaper.

Next, you must specify the services you want the Lotus Domino server to run, as seen in Figure 4-45.

Figure 4-45 Lotus Domino Server Services


http://www.redbooks.ibm.com/redpieces/pdfs/redp0319.pdf

The Domino Server can function in two basic capacities with respect to WebSphere Portal, as a LDAP Source or a Data Source.

� Lotus Domino Server as a Data source

WebSphere Portal uses Lotus Domino as a data source when accessing Domino data via Domino XML. This is done over HTTP an thus the Web Service (for example, HTTP) is necessary for working with WebSphere Portal.

THe lists displayed in the Collaborative portlets such as Domino servers, database views, etc., are populated by communicating with the Domino server via DIIOP so this service is also required for working with Collaborative components.

� Lotus Domino Server as an LDAP source

Domino Server can be used as an LDAP source for WebSphere Portal much as SecureWay, iPlanet or Active Directory. To do this, the LDAP service must be enabled.

Domino LDAP is also used to look up user attributes and values such as mailfile and mail server. THe collaborative portlets use these values.

In Figure 4-45, you must also specify the configuration of Single Sign On. It should be configured so you have Single Sign On functionality across the WebSPhere Portal portlets that access Lotus Domino resources.

Choosing to enable Single Sign On then requires that you configure the Single Sign On functionality, as seen in Figure 4-46.


Figure 4-46 Lotus Domino Single Sign On

� LTPA File

The Single Sign On keys from WebSPhere Application Server are exported to a file. This is the fully-qualified path to the key file exported from WebSphere Application Server.

� LTPA Password

The password needed to access the certificate created by the key file.

� Token Domain

The Single Sign On domain.

Note: Domino requires the starting “.” in the Token Domain.


This completes the information needed by Setup Manager to install and configure Lotus Domino Server.

4.4.8 Web Content PublisherWebSphere Content Publisher is a development tool that provides developers with the means of creating templates and workflows so that business users can publish their own template-based content without having to worry about formatting. Content Publisher extends the WebSphere Portal development environment by enabling less technical users to contribute content to a site without going to developers for help.

Web Content Publisher (WCP) works with the Content Organizer portlet. WebSphere Content Publisher stores its administrative information in a database. Setup Manager first needs to configure the database used by WebSphere Content Publisher (see Figure 4-47).

Figure 4-47 WebSphere Content Publisher database type

The WebSphere Content Publisher database can be either DB2 or Oracle.


Once specifying the type of database used to support WebSphere Content Publisher, you must configure the database connection as see in Figure 4-48.

Figure 4-48 WebSphere Content Publisher Database Configuration

Setup Manager needs the user ID and password that will be used to connect to the WebSphere Content Publisher database. These values were collected in the Web Content Publisher planning worksheet (Table 3-10 on page 69).

Lotus Workflow is an application development tool that is integrated with the Content Publisher component to provide the ability to develop the content publishing process and eliminate paper-based workflows. Lotus Workflow runs on the Domino Application Server component.

Setup Manager needs to know if the Lotus Workflow server will be local or remote to the Web Content Publisher. This is specified in Figure 4-49.

Note: Lotus Workflow is included only to support the Web Content Publisher component and is not for standalone use.


Figure 4-49 WebSphere Content Publisher workflow connection

To complete the Web Content Publisher installation and configuration, Setup Manager requires the hostname of the Lotus Workflow Server, as seen in Figure 4-50.


Figure 4-50 WebSphere Content Publisher Workflow Hostname

For more information on installing and working with Web Content Publisher, see the Web Content Management chapter in the IBM Redbook IBM WebSphere Portal V4.1 Handbook Volume 3, SG24-6921.

4.4.9 Lotus SametimeLotus Sametime provides instant messaging, shared white boards, and application sharing for electronic meetings. Sametime functionality is integrated for access to chat sessions and buddy lists with people awareness. People awareness is the ability to tell who the place members are and to find out whether they are online, offline, or not available. Sametime provides other services that can also be integrated through portlets: application sharing, white boarding, and online meetings.

Setup Manager installs and configures Lotus Sametime for use with WebSphere Portal’s Collaboration features.

There are two ways to install the Lotus Sametime Server, Core and Complete, as seen in Figure 4-51.


Figure 4-51 Lotus Sametime Server Install Type

A Lotus Sametime Complete install is an install of the Core components along with some Multimedia components. If you do not need the Multimedia support, you can specify installing just the Core components for Lotus Sametime.

Next, Setup Manager needs to know the directory where Lotus Sametime is to be installed, as seen in Figure 4-52.


Figure 4-52 Lotus Sametime Server Installation Directory

Setup Manager also installs a Sametime Server Public Fix necessary for running Sametime with WebSphere Portal. The fix is pertinent to the LDAP source you are using with Lotus Sametime, so you must specify the type of directroy service you will be using with Lotus Sametime. You may specify a Domino Directory service or another LDAP source, as seen in Figure 4-53.


Figure 4-53 Lotus Sametime Server Installation type

This completes the installation and configuration information required for use with Setup Manager. For more detailed information on installing, configuring and using Lotus Sametime with WebSphere Portal see “Collaboration” in the IBM Redbook IBM WebSphere Portal V4.1 Handbook Volume 3, SG24-6921 and the WebSphere Portal Collaborative Components.

4.4.10 Lotus CollaborationLotus Collaborative Components are UI-neutral API methods and tag libraries that allow developers who are writing portlets for WebSphere Portal to add Lotus Software collaborative functionality to their portlets. Application developers using Collaborative Components can design and implement UI extensions that leverage the features of Domino, Lotus QuickPlace, Lotus Sametime, Lotus Discovery Server, and Lotus Communities.

In order to use Lotus Collaboration for WebSphere Portal, you must specify the location of your WebSphere application and WebSphere Portal because Setup Manager will configure them to work with the Lotus Collaboration components, as seen in Figure 4-54 on page 142.


http://www.redbooks.ibm.com/redpieces/pdfs/redp0319.pdf

Figure 4-54 Collaboration Server Setup

Note that in this case, with Setup Manager, you are not installing anything, but simply configuring WebSphere Application and WebSphere Portal to work with Lotus Collaboration.

For WebSphere Portal, these must be the same values you used in the WebSphere Portal install (4.4.6, “WebSphere Portal” on page 109) and can also be found in the WebSphere Portal planning worksheet (Table 3-13 on page 72). Setup Manager requires the following for WebSphere Portal:

� WebSphere Portal Root

The WebSphere Portal install directory.

� WebSphere Portal Hostname

Hostname of the WebSphere Portal.

� WebSphere Portal Base URI and Home page.

THe WebSphere Portal URI and Home page for unsecured access.

For WebSphere Application Server, Setup Manager only needs the installation root of the WebSphere Application Server software.

Note that specifying these installation directories here indicates that you have access to the drives that the WebSphere Application Server uses.


You must also specify the locations of the servers you are using for collaboration, as seen in Figure 4-55.

Figure 4-55 Lotus Collaboration servers

These values are placed in the cs.properties file to be used when access to the Collaborative Components is needed from WebSphere Portal.

4.4.11 SummaryThe final portion of collecting all the installation and configuration information used by Setup Manager is to display the summary page(s). The contents of these pages depends on the components you have installed.

Figure 4-56, Figure 4-57 and Figure 4-58 show examples of what you will see in the summary pages, based on the different components. Check these values carefully since this is the last chance to back up and change any incorrect values before proceeding with the actual install.


Figure 4-56 Installation summary



4.5 InstallationOnce the installation and configuration information has been collected, Setup Manager then proceeds with the install of the chosen components.

Setup Manager will prompt you for rebooting, inserting CDs and a few manual configuration steps throughout the installation process.

The installation process will not be explored in detail here but is covered in detail in the individual installation chapters throughout the book.


Chapter 5. WebSphere Portal: Windows installation with Setup Manager

In this chapter, step-by-step procedures are discussed for installing WebSphere Portal 4.1 on a Windows platform using Setup Manager.

� IBM recommends that WebSphere Portal be installed using Setup Manager. For the purpose of providing readers an opportunity to set up WebSphere Portal in a multi-tier environment, installation guidelines for individual Portal components are discussed in Chapter 6, “WebSphere Portal: Windows manual installation” on page 275.

� It is assumed that you will be using some sort of security functionality with WebSphere Portal. For a Development type of installation, follow the same procedure as described in this chapter but excluding security components.

� A single-tier installation approach is followed in this chapter, where all the WebSphere Portal core components are installed on one machine.

� This chapter highlights the general Setup Manager configuration for WebSphere Portal, provides instructions on using different LDAP Servers like SecureWay LDAP, Domino LDAP and Microsoft Active Directory and walks you through the installation of WebSphere Portal components.

5


The intention of this installation description is to provide a broad overview of possible installation values. Readers may not find a mirror image of the setup scenario at their site. However, the description should be sufficient to guide them through successful WebSphere Portal installation and resolve common installation problems.

5.1 General considerationsIn this section, we will review the general considerations pertinent to this topic.

5.1.1 Prerequisites check before installationBefore you begin using Setup Manager for WebSphere Portal installation, check for the following:

� Have all the users been created and assigned privileges as explained in Chapter 3, “WebSphere Portal prerequisites and planning” on page 19?

� Have all the hardware and software requirements been met, as specified in 3.2, “WebSphere Portal for Windows 2000 prerequisites” on page 22?

� Do you have WebSphere Portal Setup Manager - CD-1 (contains IBM JRE/SetupManager/HTTP Server) or have you downloaded the WebSphere Portal Setup Manager code?

5.1.2 Installing Loopback Adapter (optional) Purpose: Microsoft Loopback Adapter works well for standalone installations, such as a standalone Thinkpad installation. The main advantage of using the Loopback Adapter is to help users install WebSphere Portal on a stand-alone machine. This will also be helpful if a target machine does not have a static IP address. Before using the Setup Manager for installing WebSphere Portal, install Windows Loopback adapter and make sure it is running.

Important: WebSphere Personalization 4.0.1 is a requirement for installing WebSphere Portal. If WebSphere Personalization is not installed, installation will fail.


1. Install the Loopback Adapter.

a. Select Start -> Settings -> Control Panel.b. Double-click Add/Remove Hardware. This will start the Add/Remove

Hardware Wizard. Click Next. c. Select Add/Troubleshoot a device and click Next.d. Select Add a new device and click Next.e. Select No, I want to select the hardware from a list and click Next.f. Select Network Adapters. g. From the Manufacturers column, select Microsoft and from the Network

Adapter column select Microsoft Loopback Adapter, then click Next.h. The Loopback adapter will install.

2. Configure the adapter:

Specify the same DNS settings for the MS Loopback Adapter as you already specified in your Token ring or Ethernet adapters.

a. Select Start -> Settings -> Network Adapters -> MS Loopback adapter (or whatever you named it) -> Internet Protocol (TCP/IP) -> Properties

b. Update DNS settings to match your Token-ring or Ethernet adapter.

3. Update the hosts file.

Update your hosts file to set IP address for your Loopback Adapter (c:\winnt\system32\drivers\etc\hosts).

Example 5-1 Hosts file

� add to your host file:

10.1.1.1 domain_name node_name

(example: 10.1.1.1 testitso.ibm.com testitso))

� ->Then reboot windows for this to become effective.

Important: Prior to the Loopback Adapter installation disable your Token Ring adapter or Ethernet adapter

Choose Start -> Settings -> Network and Dial-up Connections.

If Token Ring or Ethernet adapters appear, right-click the icon and disable them.

Chapter 5. WebSphere Portal: Windows installation with Setup Manager 149

4. Additional optional step:

This step will help you to access remote Web sites and still utilize Microsoft Loopback adapter by auto-deleting the route entry for the Loopback IP Gateway entry.

a. Run in a DOS window:

• ipconfig /all

Look for the MS Loopback adapter and note the IP address ( for example: 10.1.1.1).

• route print

This prints the IP routing in the window.

b. Create a batch file in the root directory:

• Create a text file, delroute.bat, and enter the following:

@echo offroute delete 10.1.1.0 10.1.1.1 >c:\delroute.log 2>&1echo "delroute.bat has run" >> c:\delroute.log

c. Update the registry to call this batch file during Windows startup:

i. In a DOS window, call regedit.exe.ii. In regedit, navigate to: KHEY_LOCAL_MACHINE -> Software ->

Microsoft -> Windows -> CurrentVersion -> Run.iii. Right-click Run and select New -> String Value.iv. Name the new string value: DelRoutev. In the right hand panel, right-click DelRoute. Select Modify.vi. In the modify field, enter: c:\delroute.batvii. Close Regedit.

d. Reboot and then check the delRoute.log

You should be able to get to the outside Web and still use the Microsoft Loopback adapter.

5.2 Installing WebSphere Portal with SecureWay using the Setup Manager

In this section, we will install WebSphere Portal and all its prerequisite software using Setup Manager. We use SecureWay as our LDAP source in this section. The majority of the install is the same independent of the LDAP source.

5.3, “Installing WebSphere Portal on Windows 2000 with Domino LDAP using the Setup Manager” on page 193 details the differences for this procedure using


Domino as the LDAP source. Likewise, the instructions for installing WebSphere Portal with Active Directory via Setup Manager can be found in 5.4, “Installing WebSphere Portal with Active Directory using the Setup Manager” on page 251.

5.2.1 Installation topologySince we are installing WebSphere Portal and all its prerequisite products via Setup Manager, all products will be installed on the same server machine. A single tier topology as shown in Figure 5-1 is the only way to install all WebSphere Portal and its prerequisite products using the Setup Manager.

Figure 5-1 WebSphere Portal single-tier topology for installing with Setup Manager and Secureway

5.2.2 Starting WebSphere Portal Setup ManagerInsert CD #1, which includes the WebSphere Portal Setup Manager. Setup Manager will automatically start. If you have downloaded the code, run install.bat from the install directory.


WAS40

WPS41

WMS


LDAP

IBM HTTP Server

IBM SecureWay

Windows 2000 Server


WebSphere Portal



Portlet


5.2.3 IBM Cross Platform Technologies for Windows V2.0 IBM Cross Platform Technologies for Windows installation will help you to install the latest and IBM supported version of JDK on your system.

1. Setup Manager will look for the correct version of Java. If you have the correct version of Java, Setup Manager will continue with the installation (5.2.4, “Secureway LDAP” on page 154) or else will prompt you for installing Java as shown in Example 5-2.

Example 5-2 Setup Manager will look for Java



Installing Java...

2. IBM Cross Platform Technologies for Windows V2.0 Setup will open as shown in Figure 5-2. Click Next to continue.

Note: The WebSphere Portal installation takes a considerable amount of time to load due to the number of products you need to install. It is highly recommended that you follow each step as described in this chapter carefully for a successful installation.


Figure 5-2 Install IBM Cross Platform for Windows Technologies V2.0

3. Select the destination folder for your IBM Cross Platform Technologies V2.0 and click Next to proceed; the installation will proceed. Later, you will see a window similar to Figure 5-3.


Figure 5-3 Successful installation of IBM Cross Platform Technologies for Windows

4. Click Finish for the Setup Manager to start your WebSphere Portal installation.

5.2.4 Secureway LDAPThis section walks you through the Setup Manager configuration using SecureWay LDAP.

1. Once Setup Manager has found or installed the correct JDK, installation will start and you will see a window similar to Figure 5-4.


Figure 5-4 Check for Portal Prerequisites before you proceed with installation

2. At this stage, check for product prerequisites. Click Next to proceed.

Note: It is recommended that you check for the WebSphere Portal Prerequisites at this stage. Refer to Chapter 3, “WebSphere Portal prerequisites and planning” on page 19 for additional information. Setup Manager will not allow you to proceed with the installation if the product prerequisites are not met.

For example, if you are using Windows 2000 Service Pack 3, Setup Manager will not allow you to proceed with the installation. It is required that you install Win 2000 SP 2 to install WebSphere Portal 4.1.2.

However, an alternative to having SP 3 already installed is to modify the registry. If you are experienced with using the registry, you can access HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft -> Windows NT-> CurrentVersion -> CSDVersion and change the version from 3 to 2.


3. Accept the License agreement. Click Next to proceed.

4. The following window will ask for your WebSphere Portal Installation Key. Insert the key and click Next.

5. Select Standard Install for the installation type and click Next.

6. The next window will ask you for a location of the Response file. As we did not create one, we will leave the field blank and click Next.

7. The next window will ask you to select the components that should be installed, as shown in Figure 5-5.

Note: We will use a key that starts the installation of WebSphere Portal Enable Edition. Other installations will give you more options.

Note:

� Setup Manager will create a Response file during this installation procedure and place it in /programfiles/IBMWPO/wprecord.script. This file may be used for WebSphere Portal installation on the same machine or on a different machine with slight modifications.

� Setup Manager will come with a default script. However, in order to use this, significant modifications would have to be made; we will not use it for this installation.


Figure 5-5 Select the products to install

We will select WebSphere Portal (click the check box to select) and Secureway Directory. The prerequisite package that WebSphere Portal requires will be selected by the Setup Manager automatically. Select the LDAP Server that you want to use. All the components will be installed on a single machine.

8. Setup Manager will detect any previous installation of the prerequisite products on the machine and provide a status. Perform any action requested by the Setup Manager and click Next. Setup Manager will check for the System requirements. Once when this is completed, you will proceed to configure the HTTP Server.

5.2.5 IBM HTTP ServerComplete the following instructions to install the IBM HTTP Server:

1. Continuing with the installation, you will see a window similar to Figure 5-6 asking you to select the directory where you would like your IBM HTTP Server to be installed.


Figure 5-6 Select a directory for installing IBM HTTP Server

2. Click Next. You will see a window similar to Figure 5-7.


Figure 5-7 Provide a user name and password for managing IBM HTTP Server

3. Enter your user name and password information for IBM HTTP Server. This will be the user name for managing IBM HTTP Server. In our example, we used wpsadmin as both user name and password for this installation. Click Next to configure DB2.

Note: In this case, we used wpsadmin for both user name and password. It is recommended that you use wpsadmin as the user name as Setup Manager uses this ID internally for configuring. This user ID can be changed after installing the product. The user name and password combination can also be used for the IBM default HTTP Administrative Server that runs on port 9080.


5.2.6 DB2 Universal DatabaseIn this section, we will proceed with the configuration of DB2. Complete the following instructions:

1. Beginning the configuration of DB2, you will see a window similar to Figure 5-8.

Figure 5-8 DB2 Universal Database install directory

1. Accept the default or enter the root directory where you would like to install DB2. In our example, we accepted the default. Click Next. You will see a window similar to Figure 5-9.


Figure 5-9 Provide a user name and password for DB2 Control Center

2. Enter the user name and password that the DB2 control center will use for logging into the system. For our example, we used db2admin for both the user name and password. Click Next to continue.

Note: Make sure you select the user name and password for DB2 based on the criteria described in Chapter 3, “WebSphere Portal prerequisites and planning” on page 19. In this case, we have used db2admin for both the user name and password. The DB2 Universal Database Fixpack 5 will be automatically installed.


5.2.7 SecureWay Directory ServerIn this section, we configure the IBM SecureWay Directory Server. Complete the following steps:

1. To continue with the configuration of IBM SecureWay Directory Server, select where you would like your LDAP directory to be installed and click Next. You will see a window similar to Figure 5-10.

Figure 5-10 LDAP Suffix information

2. Enter the LDAP suffix information and details about administrative user and password along with the TCP/IP port to use and click Next. In our example, we entered the following information:

– Suffix: dc=svo,dc=dfw,dc=ibm,dc=com

– Administrative name: cn=wpsadmin

– Password for Administrative user: wpsadmin


– Confirm password: wpsadmin

– TCP/IP port to use: 389

5.2.8 WebSphere Application ServerIn this section, we configure the WebSphere Application Server. Complete the following instructions:

1. Enter the user name and password that the administrator will use for WebSphere Application Server and click Next. You will see a window similar to Figure 5-11.

Important:

� It is recommended that the suffix that you enter consist of a domain controller (dc=xyz,dc=abc). This is less likely to cause Setup Manager to fail when inserting required users into the Secureway Directory.

� Make sure that there are no blank spaces in your suffix. If a blank space is inserted, installation will fail.

� It is necessary to have cn= in front of the username, for example, cn=username.

� Password for administrative user: any character set is fine, excluding open curly brackets ({) at the beginning and white spaces in general.

� TCP/IP port: if you want to use a port other than port 389, it is recommended that you change it after completing the installation.

Note: In this case, we have used wpsadmin for both user name and password.


Figure 5-11 WebSphere Application Server install directory

2. Specify the WebSphere Application Server installation directory. For our example, we accept the default. Click Next.

3. Select No for remote database. This will allow Setup Manager to create a local database and catalog that database, since we want to have all the components installed on a single box.

4. Select DB2 as the database you will be configuring with WebSphere Application Server and click Next. You will see a window similar to Figure 5-12.


Figure 5-12 User name and password entry

5. Enter the DB2 user name and password that will be used for the WebSphere Application Server and click Next. For our example, we used db2admin for both the user name and password.


Figure 5-13 DB2 database settings

6. Enter the DB2 database settings. For our example, we entered:

– Local Database Name: wasdbl

– Local Database Alias Name: wasdb

– Node Name: LOOPBACK

– Database Server Port: 55555

We kept the default fields generated by Setup Manager.

The local database name will be created by Setup Manager.

The Database Alias Name, which is different from the Database Name, is used to access the database. As we have specified the database and database alias on the same machine and have installed the Loopback adapter, we used LOOPBACK as the entry for the node name.

Make sure that the database port you specify for the DB2 Server to listen on is not used by any other application.


7. Click Next to configure the WebSphere Personalization Server. The WebSphere Application Server Fix Pack 2 along with the e-Fixes will automatically be installed.

5.2.9 WebSphere Personalization ServerIn this section, enter the Application Server where you would like to install WebSphere Personalization Server. For example, we entered WebSphere Portal. Click Next to configure WebSphere Portal.

Figure 5-14 Choose Application Server

Tip: Run netstat -an from a DOS prompt to check port bindings. The fifth figure in the first column of IP addresses is the port number.


5.2.10 WebSphere PortalIn this section, we will configure WebSphere Portal. Complete the following instructions:

1. Select Typical for the WebSphere Portal installation and click Next.

2. Choose Database and LDAP Directory mode as the authentication mechanism for Member Services and click Next.

3. Select Now to configure Security and click Next.

4. Provide the LTPA password in the window and click Next. In our example, we used wpsbind for the LTPA password.

Important: You should install WebSphere Personalization Server under WebSphere Portal and not under the default server. If you install under the default server, WebSphere Portal installation will fail.

Important: This also applies if security is currently disabled. If a wrong password is entered, you will not be able to start WebSphere Application Server and installation will fail.


Figure 5-15 WebSphere Portal Security Settings

5. The default settings (Figure 5-15) provided by Setup Manager are used in our installation, but these settings can be changed according to your requirements. Click Next to proceed to LDAP Server settings.

Important:

� You must provide a fully-qualified hostname to the WebSphere Portal machine. Any short name (just the host name) will cause installation failure. Normally, Setup Manager will provide the fully-qualified hostname. If you do not see that, make sure you check your network configuration and settings. For example, check your hostfile settings under \winnt/system32/drivers/etc/hosts

� You can change the base URI. Before you do so, make sure that you are not using the settings used by Default Server.

� Home page and Customized page fields should not be empty.


Setup Manager will allow you to choose between various LDAP Directory Server Implementations. Later in this chapter, we shall illustrate how we used different LDAP Servers with WebSphere Portal such as Domino LDAP and Microsoft Active Directory.

Using SecureWay LDAPUsing the configuration information that was provided to SecureWay Directory as shown in 5.2.7, “SecureWay Directory Server” on page 162, Setup Manager fills the window with appropriate values.

1. Choose the LDAP Server type you intend to install. Select Secureway Directory and accept the defaults (Figure 5-16).

Figure 5-16 WebSphere Portal Configured to Secureway LDAP Directory

Important: Make sure that you provide a fully-qualified hostname for the LDAP Server. Installation will fail if you use a short name such as localhost. For our example, we used sunil2.svo.dfw.ibm.com.


2. Check the Administrator Password, Suffix and LDAP port as specified earlier.

3. Click Next to proceed.

Once you have selected and configured SecureWay LDAP Server, proceed with the next step to configure LDAP Configuration Parameters.

Figure 5-17 LDAP Configuration

4. Specify the LDAP Configuration Parameters as shown in Figure 5-17. In this scenario, all default values were accepted. You can change the specifications to your requirements. Click Next to proceed to WebSphere Portal Database Selection. You will see a window similar to Figure 5-18.



5. Choose DB2 Universal Database Server as the back-end database. Choose Create and Initialize a new database (DB2 only) for the Portal Server Database Configuration options and choose Share the Database for the Do you want to share the database with Member Services option.

6. Click Next to proceed to Additional Database Configuration. You will see a window similar to Figure 5-19.


Figure 5-19 Additional Database Configuration window

7. Accept the default and re-type your password. Click Next. You will see a window similar to Figure 5-20.

Important:

� It is highly recommended that you use the same user name that is used for the WebSphere Application Server.

� Make sure your database directory is pointing to the right directory.

� If you have specified the values correctly during DB2 configuration, Setup Manager should automatically bring up the correct default values.


Figure 5-20 Database option for Member Services

8. On the Database option for Member Services, choose Initialize an existing database. Click Next to proceed to the License User Configuration (Figure 5-21).

Note: As we chose to share a single database between WebSphere Portal and WebSphere Member Services, we do not get the option to create a database here. This additional option would appear if you had chosen not to share a single database.


Figure 5-21 License Use Management install type

9. Select Local License Server for the License Use Management install type. Click Next to proceed to the Summary page.


Figure 5-22 Display summary of products

10.Figure 5-22 shows the summary of products that will be installed. It is recommended that you store this information for reference since it has the install directory and username information.

Click Next to start the actual installation of components.

5.2.11 Installation procedureThe WebSphere Portal Setup Manager installation procedure will ask you to insert various CDs during the installation of various products. At each step of the installation, before you proceed with inserting the next CD, you can perform a test to check whether the previous phase of installation was successful or you can

Note: This is the last point at which you can go back and make changes to your installation information.


perform the test after installing all the components as described in 5.5, “Testing for successful installation” on page 258.

Complete the following instructions:

1. The IBM HTTP Server will be installed from CD-1. You will be prompted to insert the DB2 CD. The DB2 installation will begin. You can check the status of the installation as shown in Figure 5-23.

Figure 5-23 DB2 installation status

Note: In the following section, we will assume that you are installing from product CDs. If you have downloaded the code, you will be asked to change the path to the appropriate directory before the installation can proceed.

Note: Figure 5-23 shows that the IBM HTTP Server has been successfully installed. You can click View Log to check the status of the installation or for any error messages during the installation.


Test: Open a Web browser and type http://localhost. If the IBM HTTP Server installation was successful, you should see the Welcome to the IBM HTTP Server window.

Once DB2 has been installed, you should see a window similar to Figure 5-24.

Figure 5-24 Successful installation of DB2

2. Reboot the machine and Setup Manager will prompt you for DB2 Fixpack Installation CD.

Note: We have seen the Setup Manager process stall after the reboot and re-login following the installation of DB2. This is characterized by a long hang-time after logging in when the installation does not proceed but the java.exe is ticking over. The recovery is to stop the Java process, then start the installation again. This is a slight inconvenience, but note that Setup Manager will ignore anything which has already been installed. It will actually resume by installing the DB2 fix-pack.

Tip: At this point, you can open Windows Services and check for DB2 Services. DB2 Services should be visible and should have started.


Test:

To verify that your DB2 installation has completed successfully, create the database SAMPLE used by the WebSphere Application Server samples. To create the database SAMPLE, follow these steps:

a. Click Start -> Programs -> IBM DB2 -> First Steps. The First Steps window will be displayed.

b. Click Create Sample Databases. The First Steps - Create Sample Databases window is displayed.

c. Click DB2 UDB Sample and click OK. The SAMPLE database is added to the default instance that was created by the setup.exe program.

d. If you receive an error message stating that the database was not created, go to the Services dialog box accessible from the Control Panel and ensure that the DB2 parameters are set as follows:

• The DB2-DB2 service is Started.

• The startup type for the DB2-DB2 service is Automatic.

• The hardware profile is Enabled.

After ensuring these parameters are set correctly, try creating the database SAMPLE again.

e. To ensure that the database SAMPLE was created, go to the DB2 Control Center (Start -> Programs -> IBM DB2-> Control Center) and ensure that the name of the DB2 database SAMPLE is shown in the tree.

f. After you finish, close the DB2 dialog box.

3. WebSphere Setup Manager will start installing the Secureway LDAP Directory.

Test:

a. Open Start-> Programs ->IBM SecureWay Directory->Directory Management Tool.

b. Check under Introduction - Server - Rebind and authenticate using the User DN and password that you had specified during the configuration. If the installation is successful, you should be able to browse the tree. We used wpsadmin for both user and password.

Note: Based on the system resource consumption, sometimes it appears as though Secureway installation is stuck at 65%. Be patient and the installation will complete successfully. If you are concerned about progress, you may want to check the processor activity.


c. WebSphere Application Server will be installed followed by WebSphere Application Server Fixpack 2 as shown in Figure 5-25.

Figure 5-25 Installing WebSphere Application Server

Test:

a. Open the Control Panel and select Services. Stop all DB2 services. Go to a command prompt and run the usejdbc2.bat program prior to starting the WebSphere Admin Server.

b. Run C:\Program Files\SQLLIB\java12> usejdbc2

c. Restart DB2 services.

d. Check that WebSphere Administrative Server has been registered in the Windows Services dialog. Within Services, scroll down to see that IBM WS AdminServer V 4.0 is started.

e. Go to the Administrator’s Console to start the default server. Click Start -> Programs -> IBM WebSphere -> Application Server V4.0 AE -> Administrator’s Console.


f. Open a browser and go to http://localhost/servlet/snoop, which is a standard sample servlet installed by default. You should see information on /servlet/snoop.

4. Setup Manager will now ask you for the CD to install WebSphere Personalization Server. You can check the status of WebSphere Personalization Server as shown in Figure 5-26.

Figure 5-26 Status of WebSphere Personalization Server installation

Note: The instructions above can also be viewed in the manual installation of WebSphere Portal at step 2 on page 294.

More information on WebSphere Application Server can be obtained from:\

http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/index.html




Test:

Open WebSphere Admin Console and check for WebSphere Personalization applications installed under WebSphere Portal. If you have WebSphere Personalization workspace installed, open in a browser using the following URL: http://<host_name>/PersWorkspace/index.jsp and log in with the user having administrative privileges. If the installation is successful, it should open the WebSphere Personalization Workspace for you.

5. Setup Manager will begin installing WebSphere Portal as shown in Figure 5-27.

Important:

� WebSphere Personalization Server installation requires you to have WebSphere Application Server running.

� You should see the IBM WS Admin Server 4.0 status as started in the Windows Services.

� In case you find this service to be stopped, right-click IBM WS Admin Server 4.0 and click Start. The status of this service should be started.


Figure 5-27 WebSphere Portal installation

During this installation phase, applications are imported and configuration changes are made to the WebSphere Application Server. When the installation is about 65% complete, you will have to alter Security Settings on the WebSphere Application Server. At this stage, a message window will pop up with instructions for setting up the admin role as shown in Figure 5-28.


Figure 5-28 AdminRole configuration settings

6. As per Figure 5-28, you must complete the following instructions:

AdminRole brief instructions

a. Restart your Web Server

You must stop the external Web server and restart the Web server before you continue.

Important:

� Read the following instructions carefully. Do not click OK without performing the AdminRole configuration. Otherwise, the installation will fail.

� In the following steps, we have provide brief and detailed instructions.


b. Setting the AdminRole

If you are performing a typical installation for the Portal Server and have not already set the AdminRole in WebSphere Application Server for use with WebSphere Portal, perform the following steps:

i. Verify that the Administrative Server for WebSphere Application Server is started.

ii. Open the Administrative Console for WebSphere Application Server.

iii. On the main menu, click Console -> Security Center.

iv. On the General tab, verify that the option Enable Security is selected.

v. Click the Administrative Role tab.

vi. In the list of Roles, click the AdminRole and then click Select. The SelectUsers/Groups- AdminRole dialog is displayed.

vii. Click the option Select users/groups and then type * (the asterisk character) in the Search field. Click Search to display a list of users and groups.

viii.In the list of Available Users/Groups, click the user wpsadmin and then click the Add button. Click OK to add the AdminRole to the user wpsadmin. Be sure that the domain suffix does not contain a blank character. A blank will cause the base portlet deployment to fail.

ix. Click the Apply button or the OK button. Close the Security Center and then close the Administrative Console.

x. Stop Administrative Server for WebSphere Application Server and start it again.

xi. Open the Administrative Console again.

xii. Verify that the application server named WebSphere Portal Server has restarted. If it has not restarted, start it again.

xiii.After the application server WebSphere Portal Server is restarted, click the OK button on this install panel to continue.

AdminRole detailed instructions

a. Restart your Web Server. Click Start -> Settings - Control Panel. Click Administrative Tools - Services. Right-click IBM HTTP Server and click Stop. Wait for the services to stop and then right-click IBM HTTP Server and click Start.

You must stop the external Web server and restart the Web server before you continue.

b. Start WebSphere Admin Console. Choose Start -> Programs -> IBM WebSphere -> Application Server 4.0 AE -> Administrator’s Console.


If the WebSphere Admin Console does not start, check for Troubleshooting tips provided under the IBM WebSphere V4.0 Advanced Edition Handbook.

c. Open the Security Center by clicking Console -> Security Center.... You will see a window similar to Figure 5-29.

Figure 5-29 Security Center

d. In the Security Center window, make sure that Enable Security is selected. Setup Manager should automatically enable this. If this option is not checked, stop your installation.





e. Click the Authentication tab in the Security Center. You will see a window similar to Figure 5-30.

Tip: How can you continue with your WebSphere Portal 4.1 installation when security is not enabled by the installation process and you are asked to deal with Admin Role settings?

This problem generally occurs during an installation failure. If security is not enabled, it is very likely that the Setup Manager did not get a connection to your LDAP directory. To overcome this problem and to proceed with the installation without having to reinstall any of the components, manually perform the following:

1. Import the LDIF file to your suffix under LDAP.

2. Import the enablegs.xml file (available under \WebSphere\PortalServer\install\xml) to your xmlconfig. This xml file will ensure that security settings are set.

3. Stop and start your WebSphere admin server.

4. Specify the Admin Role in the security center.

5. Start and stop the admin server for the changes to take effect.

6. Continue the installation with Setup Manager


Figure 5-30 Authentication in WebSphere Security Center

i. Verify that you have checked Enable Single Sign On (SSO) and you have provided a domain name.

ii. Check the LDAP Settings and make sure that suffix information is provided correctly.

iii. Select Custom as the directory type.

f. Click Administrative Role tab. Select AdminRole in the Roles list. Click Select and you will see a window similar to Figure 5-31.


Figure 5-31 Select Users/Groups - AdminRole window

g. Perform a blind (*) search. Click Search.

h. At least two users and one group will appear in the available Users/Groups list.

i. Under Users, select uid = wpsadmin and click Add.

ii. Under Groups, select cn= wpsadmins and click Add.

Both wpsadmin user and wpsadmins group will appear in the right-hand list of the Selected Users/Groups.

i. Click OK and click Apply, close the security center window and the WebSphere Administrative Console.

j. Stop and restart the WebSphere Admin Server.

Important: Be sure that the domain suffix does not contain a blank character. A blank will cause the base portlet deployment to fail.


7. Reopen the WebSphere Administrative console, open the Nodes folder and then go to the Node name of your Application Server. Check whether WebSphere Portal is started as shown in Figure 5-32. If it is stopped (red color, next to WebSphere Portal) right-click it and select Start. Starting the node may take a minute.

Figure 5-32 Make sure you have WebSphere Portal Started

8. At this stage, come back to the Setup Manager window and click OK on the install panel. Setup Manager will continue with the WebSphere Portal installation and complete it.

Note: Based on hardware and processors currently running, you may want to make sure that all java.exe are stopped before you attempt to start.


Figure 5-33 Installing License Verification Manager

9. Setup Manager will then install the License Verification Manager as shown in Figure 5-33 and the Productivity Portlets. Afterwards, you will see a window similar to Figure 5-34.


Figure 5-34 Successful installation of WebSphere Portal

10.Click OK as shown in Figure 5-34 to exit from the Setup Manager. You have finished installing WebSphere Portal.

You have now successfully installed WebSphere Portal on Windows 2000 using Setup Manager.

For details on testing your install and post installation instructions, see 5.5, “Testing for successful installation” on page 258 and 5.7, “Post-installation instructions” on page 265.


5.3 Installing WebSphere Portal on Windows 2000 with Domino LDAP using the Setup Manager

WebSphere Portal leverages the capabilities of the Domino Application Server by integrating its own services with Domino. This section describes a scenario where WebSphere Portal is installed with Domino, providing the authentication through its LDAP server. This is a one-tier architecture, where Domino is installed on the same server as WebSphere (Figure 5-35). A two-tier architecture with Domino installed on a separate server is described in 6.7, “WebSphere Portal install using Lotus Domino LDAP Directory” on page 370.

Figure 5-35 WebSphere Portal one-tier topology with Domino


WAS40

WPS41

WMS


LDAP

IBM HTTP Server

Windows 2000 Server

Directory Services

Lotus Domino Server




WebSphere Portal

Portlet


5.3.1 PrerequisitesIn this section, we discuss prerequisites for our Domino setup.

Patched rt.jar fileAs of the writing of this redbook, a patched file, rt.jar, is required for the installation of the WebSphere Portal in section 5.3.9 Installing WebSphere Portal on page 238. You will need to obtain this from IBM support.

5.3.2 Removing Lotus Notes clientsIf you are installing this on a machine where you are currently using your Notes client, you can use the following procedure to remove Notes before installing WebSphere Content Publisher and install another copy afterwards. Note that this will result in having two copies of Notes.

If you have any questions about this process, please contact your Notes system administrator.

1. Make a backup of your Lotus Notes Data directory (typically c:\lotus\notes\data or C:\Notes\data).

2. Make sure your ID file is in that backup. The ID file is used to uniquely identify the user and usually has an id suffix. If not, copy into the backup data directory.

3. Record your IBM Notes Server name.

4. Uninstall Lotus Notes and remove the directory in which it was installed. This is typically C:\Notes or C:\Lotus\notes

5. Perform the WebSphere Portal install described in this document.

Once the WebSphere Portal install has completed, you may reinstall the Lotus Notes client. To avoid overwriting the Domino install used for WebSphere Portal, you must:

� Specify a separate location from the Notes that was installed for WebSphere Portal. Do not use C:\Notes or C:\Lotus\Notes.

� Specify a different folder for the Program menu. Do not use Lotus Notes.

Once you have completed the reinstall, you may restore Notes.

1. Copy the contents of the backup Data directory made in Step 1 on page 194 to the Data directory for your new install.

2. Start Notes and configure it to your Mail Server.


5.3.3 Installing DB2, IBM HTTP Server and WebSphereApplication Server

The first step of our installation is to install the following components:

� DB2� IBM HTTP Server� WebSphere Application Server

WebSphere Application Server is installed before Domino Application Server, because keys used to create single sign-on communication between them must be created by the WebSphere Application Server prior to the install of Domino. The generation of the keys is not manually performed by Setup Manager.

The installation is identical to 5.2, “Installing WebSphere Portal with SecureWay using the Setup Manager” on page 150, except for step 7 on page 156 of 5.2.4, “Secureway LDAP” on page 154 when components are being selected. Only DB2, IBM HTTP Server and IBM WebSphere Application Server should be selected. Do not select Domino Application Server at this time.

The selected components should appear as shown in Figure 5-36.

Important: Make sure you do not try to use two Lotus clients pointing to different servers at the same time. For example, do not have a Domino Administrator open against the WebSphere Content Publisher Domino Server and then try to start Notes against the IBM Mail server.


Figure 5-36 Select components DB2, WebSphere and IBM HTTP Server

The installation values will be identical for the various components. The final Display summary at step 10 on page 176 of the displayed summary should appear as shown in Figure 5-37.


Figure 5-37 Display Summary

Once the installation process has completed, test that WebSphere Application Server is working correctly using the snoop servlet described in 5.2.11, “Installation procedure” on page 176, step a on page 180.

5.3.4 Generating keys in WebSphere Application ServerWebSphere Application Server will provide single sign-on between itself and Domino Application Server by sharing Lightweight Third Party Authentication (LTPA) tokens. LTPA tokens contain user data, expiration time and a digital

Tip: Make sure that your browser cache has been cleared before performing any testing throughout this installation process.


signature that is signed with a private key of the authenticating user. They are stored as encrypted cookies.

A key for decrypting the cookie is shared by WebSphere Application and added to Domino Application Server.

This section describes how WebSphere Application Server creates the key that will be shared by Domino.

1. Click Start -> Settings -> Control Panel. Double-click Administrator Tools. Double-click Services. Check to see that IBM WS AdminServer 4.0 has started. If it has not, right-click IBM WS ADminServer and select Start.

2. Start the WebSphere Application Server by clicking Start-> IBM WebSphere -> Application Server V4.0 -> Administrator's Console.

3. Select Console -> Security Center. Click the Authentication tab. Select Lightweight Third Party Authentication (LTPA). Enter the domain of your machine in the Domain field. Select Enable Single Sign On (SSO). See Figure 5-38 for details.


Figure 5-38 Generating LTPA keys in WebSphere Application Server

4. Click the Generate Keys... button. You will see a prompt asking for an LTPA password as shown in Figure 5-39.


Figure 5-39 Enter the LTPA password

5. Enter the password. Click OK and the LTPA password window will close.

6. Click Export Key... You will see a window similar to Figure 5-40.

Figure 5-40 Exporting the DOMWAS.key file

7. Select a location and create a file name. In our instance, we selected the C:\ directory and created the file name DOMWAS.key. Click Save.

8. Reboot the machine.

The key file DOMWAS.key is required during the installation of Domino Application Server. Now that it has been generated, we can continue to install Domino Application Server and other components.


5.3.5 Install Domino components We will now install the Domino Application Server. Perform the following steps:

1. Start the installation process by inserting CD1 and executing the install.bat file.

2. Read and select the Accept the program license agreement. Click Next.

3. Enter your license key. Click Next.

4. Select Standard Installation for the install type and click Next.

5. Leave the response file location empty and click Next.

6. Select WebSphere Personalization, then deselect Personalization Workspace and Personalization Infocenter. WebSphere Application Server (previously installed) will be automatically selected. Select Lotus Domino Application Server. IBM HTTP Server (previously installed) will be automatically selected. The window will appear similar to Figure 5-41.


Figure 5-41 Selecting Domino components to install

7. Click Next.

8. A window will display a list of all previous installed components. Click Next.

9. The system will now check previous installations. Note that IBM HTTP Server, Global Security Toolkit, WebSphere Application Server, WebSphere Application Server Fixpack 2 are already installed and will take no action. Click Next.


10.Click No for Is WebSphere Application Server Security enabled?. Click Next.

11.Enter wasadmin for the administrator ID and wasadmin as the password. Click Next.

12.Leave the default WebSphere Portal for the application server where Personalization server will run. Click Next. You will see a window similar to Figure 5-42.

Figure 5-42 Select Domino Configuration Type

13.Choose LDAP Server. Click Next. You will now see a window similar to Figure 5-43.


Figure 5-43 Selecting Domino Configuration

14.Leave the default Domino Application Server as the Domino Server. Click Next. You will now see a window similar to Figure 5-44.


Figure 5-44 Select Domino install location

15.Accept the defaults. This defines the installation path for the Domino Server. Click Next. You will now see a window similar to Figure 5-45.


Figure 5-45 Domino Server information

16.Enter passwords for the Certifier Password and Domino Administrator Password fields, and confirm them. These are passwords used to administer and manage the Domino server. Ensure that the Domain name, Certifier organization, server name and hostname are correct. The server name should be the name of the node where you are installing. The hostname should be the fully-qualified domain name for the installation machine. Accept the remainder of the defaults. In our example, we used password as the password. Click Next. You will see a window similar to Figure 5-46.


Figure 5-46 Domino services

17.Accept the defaults. Select Web Server, DIIOP and LDAP. Ensure that Configure SSO Support at this time is set to Yes. Selecting Web Server will utilize the HTTP server from Domino. Domino Directory Services also provides an implementation of LDAP. This must be selected if you intend to perform authentication and authorizing through Domino. Click Next. You will see a window similar to Figure 5-47.

Tip: The Domino Administrator account will be created with a user ID and Shortname of dadmin. When you see this user ID further on in the installation, it is referring to the Domino Administrator account.


Figure 5-47 HTTP Server Ports for Domino

18.Accept the default port, 8080. Port 80 will not be used by Domino because the IBM HTTP Server is currently using it. Note that you may not see this window if you did not install the Web Server as shown in step 17 on page 207. Click Next. You will see a window similar to Figure 5-48.


Figure 5-48 Configuring Single Sign-On during installation

19.Enter C:\DOMWAS.key in the LTPA File field. This is where the key file that was created using WebSphere Administration Console is used as covered in Figure 5-40 on page 200. Enter the LTPA password and the token domain. In our example, we have used our domain itso.ral.ibm.com. This domain must match the domain specified in Figure 5-38. Click Next. You will see a window similar to Figure 5-49.


Figure 5-49 Domino Client install location

20.Accept the default locations for the Domino clients to be installed. Click Next.

The installation will begin.

When the installation is complete, you will see a dialog box similar to Figure 5-50.

Note: The default token domain may appear as above, preceded by a period. This will be accepted by the installation process.


Figure 5-50 Installation is complete

5.3.6 Configuring Domino Administration clientThis section describes how to configure the Domino Administrator client that allows us to manage and configure the Domino server. This applies to both Domino LDAP and WebSphere Content Publisher installations. This step must be performed by anyone who will administer the Domino Application server.

1. Click Start-> Lotus Applications-> Lotus Domino Server. This will start the Domino Server without using the services window. Do not start using the services window. However, note that the server may already be running from the installation process.

2. Click Start ->Programs ->Lotus Applications -> Lotus Domino Administrator. This will start the Domino Administrator. You will see a window similar to Figure 5-51.

Figure 5-51 Welcome window for configuring Lotus Notes client


3. The Lotus Notes Client Configuration dialog appears. Click Next. You will see a window similar to Figure 5-52.

Figure 5-52 Connect to Domino server

4. Select I want to connect to a Domino Server and click Next. You will see a window similar to Figure 5-53.

Figure 5-53 Configure connection to Domino through a LAN


5. Select Set up a connection to a local area network (LAN) and click Next. You will see a window similar to Figure 5-54.

Figure 5-54 Configure Domino server name

6. Enter your server name where it asks for the Domino server name. In our example, we selected m23wpn62/itso.ral.ibm.com. Click Next.

Figure 5-55 Select the Domino Admin as the user


7. Select Use my name as identification. Type your Domino Administrator name. This was Domino Admin, and was specified in step 16 on page 206. Click Next. You will see a window similar to Figure 5-56.

Figure 5-56 Connection to Domino is complete


Figure 5-57 Set up a mail account


9. Select I don't want to create an Internet mail account. Click Next. You will see a window similar to Figure 5-58.

Figure 5-58 Set up connection to news server

10.Select I don't want to connect to a news server. Click Next. You will see a window similar to Figure 5-59.

Figure 5-59 Connect to another directory server


11.Select I don't want to connect to another directory server. Click Next. You will see a window similar to Figure 5-60.

Figure 5-60 Connection through proxy server

12.This window determines whether you will connect through a proxy server. Select the choice that is appropriate for your installation. For our example, we did not connect to the Internet via a proxy server. If you are unsure, ask your system administrator. Click Next. You will see a window similar to Figure 5-62.

If you choose to connect to the Internet through a proxy server, then you will have an additional window shown in Figure 5-61. Fill it out appropriately and click Next.

Tip: If your installation requires a proxy server, you may obtain the necessary information through the IE browser by choosing Tools -> Internet Options... ->Connections (tab) -> LAN Settings....(button). This will also indicate whether or not you are using a proxy server.


Figure 5-61 Configuring proxy settings

Figure 5-62 Select the Internet connection type

13.Select Connect over local area network (or cable modem) and click Next. You will see a window similar to Figure 5-63.


Figure 5-63 Successful install of Lotus Notes

14.You should receive a notice that you have successfully set up Lotus Notes. Click Finish. Next, you will be prompted for the password (see Figure 5-64).

Figure 5-64 Password prompt for Domino Admin

15.Enter the password and click OK.

16.The server will create your address book and you will see a note saying Notes setup is complete!. Click OK.

17.Close the Domino Administrator.

Note: If you receive the message Notes Error - Specified Command is not available from the Workspace, you can ignore this error message. Click OK.


5.3.7 Configuring WebSphere Application Server securityWe will now configure WebSphere Application Server security. By enabling security, WebSphere will begin to use Domino LDAP for authentication.

1. Click Start -> Programs -> IBM WebSphere -> Application Server V4.0 -> Start Admin Server to ensure that the Admin Server is running. This will open a command prompt. Wait until it has disappeared before continuing. If it disappears immediately, the Admin Server may already be running.

2. Click Start -> Programs -> IBM WebSphere -> Application Server V4.0 -> Administrator's Console. You should see a window similar to Figure 5-65.

Figure 5-65 WebSphere Advanced Administrative Console

3. Select Console-> Security Center. You will see a window similar to Figure 5-66.


Figure 5-66 Enable security in WebSphere Application Server

4. Select the General tab, and then select Enable Security as shown in Figure 5-66.

5. Select the Authentication tab. You will see a window similar to Figure 5-67.


Figure 5-67 Configured WebSphere Application Server authentication for Domino Admin user

6. Under Authentication Mechanism, ensure Lightweight Third Party Authentication (LTPA) is selected.

7. Under LTPA Settings, ensure Enable Single Sign On (SSO) is selected and the domain name is in the Domain field. For our example, this is itso.ral.ibm.com.

8. In the lower left section of the window, select LDAP. In the Security Server ID field, enter dadmin. dadmin is the short user ID for the Domino Administrator. Enter the Domino Administrators password in the password field. Enter your fully-qualified host name in the host field. Select Domino 5.0 as the directory type. Leave all other fields set to default and click OK. If you are prompted, enter the LTPA password, which we had configured as password. The message The changes will not take effect until the admin server is


restarted will appear. Your window should look similar to Figure 5-67. Click OK.

9. Close the WebSphere Advanced Administrative Console.

10.Click Start -> Settings Control Panel. Double-click Administrative Tools. Double-click Services. Right-click IBM WD AdminServer and select Stop. Once the process has stopped, right-click IBM WS AdminServer and select Start.

11.Click Start -> Programs -> IBM WebSphere -> Application Server V4.0 -> Administrator's Console. A password is now required. Enter dadmin as the user identity and the Domino Administrator password (the default during install was password) as the user password. Click OK. The administrative console should now appear. This verifies that WebSphere Application Server is using Domino as its LDAP source.

If the server was requested to start but a message displays saying the service did not respond in a timely fashion, this usually means Domino has problems or is not running or is taking longer than the normal waiting period. Wait a while and refresh the Services Window to see if it is started.

5.3.8 Configuring Domino for WebSphere PortalBefore installing WebSphere Portal, it is necessary to make manual configuration changes to Domino. This section describes what changes are required.

1. Click Start -> Programs -> Lotus Applications -> Lotus Domino Administrator to start the Domino Administrator. You will be prompted for a password. Enter the password for the appropriate ID and click OK.

2. If you are not using the Domino Administrator ID, switch to it. Click File -> Tools -> Switch ID… This will open a window similar to Figure 5-68. Navigate to the C:\Lotus\Domino\data folder and select user.id. This is the Domino Administrators ID. Click Open and enter the password.


Figure 5-68 Switch user ID to Domino Admin user ID

3. Click File -> Open Server. Select your server as in Figure 5-69.

Figure 5-69 Select Domino server to administer

4. Do not select the local server. Click OK.


Figure 5-70 Internet Protocols configuration

5. Go to Administration view to edit server. Click the Configuration tab. From the navigation on the left, expand Server and then click Current Server Document.

6. Click the Internet Protocols tab. Enter the fully-qualified host name in the Host name(s) field. In our example, we entered, m23wpn62.itso.ral.ibm.com as shown in Figure 5-70. Click Save and Close. This will save the document, but the document will not close.

7. Click Configurations in the left-hand panel underneath the Server twisty (see Figure 5-71).


Figure 5-71 Domino server configuration

8. Click Add Configuration in the right-hand panel. You will see a window similar to Figure 5-72.


Figure 5-72 Editing basic server configurations

9. Select Yes for the question Use these settings as the default settings for all servers:.

10.Click the LDAP tab. You will see a window similar to Figure 5-73.


Figure 5-73 Modifying LDAP settings

11.Click the Choose Fields that anonymous users can query via LDAP: button. You will see a window similar to Figure 5-74.

Figure 5-74 Adding LDAP fields


12.Click Show Fields button and select the following fields: MailFile and MailServer. Click Add to add them to the already selected list.

13.Click New. You will see a window similar to Figure 5-75.

Figure 5-75 Adding a new field to LDAP

14.A pop-up window titled New Field will appear. Enter HTTP_HostName and click OK. You will see a window similar to Figure 5-76.

15.Click OK in the LDAP Field list window.

Figure 5-76 Allowing LDAP users write access


16.In the Allow LDAP users write access field, insert Yes as shown in Figure 5-76. Click Save and Close. You will see a window similar to Figure 5-77.

Figure 5-77 Current Domino user groups

17.Click the People & Groups tab. Click Groups in the left-hand panel. Your window should look similar to Figure 5-77.

18.Click Add Group in the right-hand panel. You will see a window similar to Figure 5-78.


Figure 5-78 Add the wpsadmins group to Domino

19.Enter wpsadmins in the Group name field. Click Save and Close. You will see a window similar to Figure 5-79.


Figure 5-79 Selecting the Register button

20.Click the People & Groups tab. On the right-hand side of the tool bar, open the Tools menu, from the People menu and click Register.... You will see a window similar to Figure 5-80.

Figure 5-80 Selecting the certifier ID


21.A pop-up window titled Choose Certifier ID will appear. Select the cert.id file in C:\Lotus\Domino\data and click Open.

22.A password prompt will appear. Enter the certifier ID as specified during the install of Domino. We used password. Click OK. A warning may pop up claiming that the current certifier ID contains no recovery information. Click Yes and continue.

Figure 5-81 Create the wpsadmin user for WebSphere Portal

23.Select the Advanced checkbox in the top left corner. Leave the first name blank and enter wpsadmin as the last name. Also ensure that the short name is wpsadmin. Enter wpsadmin as the password. Select the Set Internet Password option. Enter an Internet address and Internet Domain based on your hostname (see Figure 5-81). The password must be wpsadmin for the install to work properly.


Figure 5-82 wpsadmins group added to wpsadmin user

24.Click Groups. Select wpsadmins and click the Add button. Next, click Add Person button.

25.Click Basics on the left of the Register Person window. Repeat the process using wpsbind instead of wpsadmin (as in Figure 5-81). Ensure the password is wpsbind and that Set Internet Password is set. Ensure that the shortname is also wpsbind. The password must be wpsbind for the install to work properly. Add wpsbind to the wpsadmins group as described in step 24 on page 233. Click Add Person when you are done.

26.Click Register All. This will now create the wpsadmin and wpsbind users and make them available to the Domino LDAP system. WebSphere Portal requires these users to install the portal.

27.You will see a pop-up window stating All two people registered successfully!. Click OK to continue. Close the Add Person window. You will return to a window similar to Figure 5-83.


Figure 5-83 Manage the ACL’s for names.nsf database

28.In the Administration view, click the Files tab. There is a file, names.nsf, that is located under the Filename column. Click it with the right mouse button and click Access Control -> Manage as shown in Figure 5-83.


Figure 5-84 Access Control List for names.nsf

29.Click the Add… button. You will see a window similar to Figure 5-85.

Figure 5-85 Adding a user to the names.nsf database

30.Click the blue person button and you will see a window titled Names.


Figure 5-86 Adding wpsadmin access to names.nsf

31.Select the hostname address book from the top left pull down menu. Select wpsadmin user from the scrolling frame on the left and click Add. Click OK.

Figure 5-87 Permissions granted to wpsadmin in the names.nsf database

32.Select the wpsadmin/itso.ral.ibm.com user in the Access Control List window. In the User pull-down menu, select Person. In the Access pull-down


menu, select Manager. Leave the delete documents selected. Select each Role in the Roles menu that is checked.

33.Click the Add… button. This will bring up an Add User button.

Figure 5-88 Adding permissions for wpsadmins group

34.Click the blue person button and select the wpsadmins group as we have done in step 29 on page 235. Click Add and click OK.

35.In the Access field, select Manager. Ensure all Roles are selected and Delete Documents is selected.

36.Click OK.

37.In the command prompt where the Domino server was started, type quit and click Enter. Restart the Domino server from the menu. This will allow all changes to take place.

Verifying users have been added to Domino LDAPWe will now verify that the wpsadmins group, wpsadmin user and wpsbind user required by WebSphere Portal have been successfully added to Domino’s LDAP. Perform the following steps:

1. Click Start-> Programs -> Accessories -> Command Prompt.

2. Navigate to the C:\lotus\Domino directory. Enter the command:

Ldapsearch -h hostName/domainName cn=wps*


where hostname/domainName is your fully-qualified Domino Server name.

3. You should see entries similar to those shown in Figure 5-89. The certificate field will not be the same, but ensure that the wpsadmin and wpsbind users and wpsadmins group are created.

Figure 5-89 LDAP search

Domino has now been configured for WebSphere Portal installation.

5.3.9 Installing WebSphere PortalThe final step in our installation is to install WebSphere Portal.

Replacing rt.jar in WebSphere Application Server1. Contact IBM support and obtain the latest copy of rt.jar for WebSphere. If you

do not do this, you may encounter an error that looks like this:

(Sep 23, 2002 5:00:33 PM), install, com.ibm.wps.install.LdapCheckPanel, msg2, Calling LDAP check with itso-0n5i4hw5xh.dominotest.com:389;


cn=wpsadmin(o=dominotest;cn=wpsbind,o=dominotest;cn=wpsadmin,o=dominotest;cn=wpsadmins) Checking for 'o=dominotest' Checking for 'cn=wpsbind,o=dominotest' javax.naming.CommunicationException: Socket closed [Root exception is java.net.SocketException: Socket closed]; remaining name 'cn=wpsbind,o=dominotest' (Sep 23, 2002 5:00:33 PM), install, com.ibm.wps.install.LdapCheckPanel, err, Code 2

This file will be used temporarily for the installation, then replaced with the original.

2. If the WebSphere Administrative Console is open, close it.

3. Click Start -> Settings -> Control Panel. Double-click Administrative Tools. Double-click Services. In the services window, right-click WS Admin Server and select Stop (if it is not already stopped).

4. Rename c:\WebSphere\AppServer\java\jre\lib\rt.jar to rt.old.

5. Copy the patched rt.jar file to c:\WebSphere\AppServer\java\jre\lib\rt.jar.

6. Return to the services window. Right-click Lotus Domino Server (dominodata) and select Start. This will bring up a command prompt. Ensure that the start-up has run to completion and all tasks are enabled as shown in Figure 5-90.

Tip: If you cannot rename rt.jar, close any other programs which might be related to WebSphere, then try rebooting your server.

Tip: It is important to note that Domino Server may appear to be started in the services panel, but has not yet been completely initialized and therefore, is not available. When the Lotus Domino Server is started, a command prompt will appear with information on the server's status. Ensure that it looks like Figure 5-90 where it says that HTTP Server is running and that LDAP Server has started.


Figure 5-90 Domino Application Server is running

7. Right-click WS Admin Server 4.0 in the Services window and select Start.

Disabling security in WebSphere Application ServerWebSphere Application Server security will be disabled. Perform the following steps:

1. Click Start -> Programs -> IBM WebSphere -> Application Server V4.0 -> Administrator's Console. Password prompt will request a User Identity and User Password. Use dadmin and password if using the Domino Administrator's default password.

2. Select Console -> Security Center… This will open a window as shown in Figure 5-91.


Figure 5-91 Disabling security in WebSphere Application Server

3. Deselect Enable Security as shown in Figure 5-91. Click Apply. A warning message will pop up saying that changes will not take effect until the admin server is restarted. Click OK.

4. Click OK in the Security Center and exit the WebSphere Administrator’s Console.

5. Return to the services window. Stop and restart the WS Admin Server.

Install PortalBegin the Portal installation. Complete the following steps:

1. Insert Disk 1 into CD ROM. Installer should begin to run.

2. Accept license, enter license key, and select the standard install. These steps are identical to those in section 5.2.4, “Secureway LDAP” on page 154. Continue to step 7 on page 156, where components are being selected.


3. In our install, select only WebSphere Portal. This will automatically include WebSphere Personalization, WebSphere Application Server and IBM HTTP Server. WebSphere Application Server and IBM HTTP Server were already installed previously and will not be installed again. Ensure that Lotus Collaborative Places and Components is not selected (it will be by default). You should have WebSphere Portal, WebSphere Portal -> Productivity Portlets, Portal Server checked. You should have WebSphere Personalization, WebSphere Personalization -> Personalization Server, checked, as well as WebSphere App Server (Fixpack2 and WebSphere Application Server) and IBM HTTP Server. Your window selection will look similar to Figure 5-92. Click Next.

Figure 5-92 Selecting components for WebSphere Portal install


4. You will see that some products have already been installed, as shown in Figure 5-93. In this particular scenario, Global Security Toolkit, IBM HTTP Server, WebSphere Application Server, Personalization Server and others had already been installed in previous steps. Click Next.

Figure 5-93 Checking previous installations

5. Select No for the option WebSphere Application Server Security enabled. Security was shut off in “Disabling security in WebSphere Application Server” on page 240. Security is disabled for the WebSphere Portal install.

6. Choose Typical for the installation type, click Next.

7. Choose Database and LDAP Directory and click Next.


Figure 5-94 Configure WebSphere security later

8. Choose Later for enabling security configuration as shown in Figure 5-94. We will configure security after our install; you should not do it now. Click Next.

9. Allow the default values for the Server configuration as shown in Figure 5-15 on page 169. Modify the proxy host or port if necessary and click Next.


Figure 5-95 Select Domino as LDAP server and configure

10.Select Lotus Domino Application as the LDAP server. Update User_DN to cn=wpsadmin,o=<yourDomainName>. You must use the values from the ldapsearch performed in “Verifying users have been added to Domino LDAP” on page 237. The password to be entered is wpsadmin. Leave Suffix blank and ensure LDAP port number is 389. Your window should look similar to Figure 5-95. This step is configuring wpsadmin to administer the Domino server. Click Next.

11.Use these values to modify the next panel as needed.

Table 5-1

Field Value

User ObjectClass inetOrg Person

User DN prefix cn

User DN suffix o=<your domain>

Group Object Class groupOfNames

Group Member member

Group DN prefix cn


Note that the group setting is for wpsadmins, and not for the user wpsadmin, as shown in Figure 5-96. Click Next.

Figure 5-96 LDAP Configuration for Domino

12.Choose DB2 Universal Database Server as the back-end database, Create and Initialize a new Database(DB2 only) for the Portal Server Database Configuration options and Share the Database for the Do you want to share

Group DN suffix <empty>

Administrator DN cn=wpsadmin,o=<your domain>

Administrative group DN cn= wpsadmins

Field Value


the database with Member Services option. This is shown in Figure 5-18 on page 172. Click Next to proceed.

13.Enter db2admin as Database user with a password of db2admin. This is depicted in Figure 5-19 on page 173. Click Next.

14.Select Initialize an existing database as shown in Figure 5-20 on page 174. Click Next.

15.Select Local License Server as shown in Figure 5-21 on page 175. Click Next.

16.You will now see a window similar to Figure 5-97.

Figure 5-97 Checking previous installations

17.Verify that Domino Application Server is running by clicking Start -> Settings ->Control Panel. Double-click Administrative Tools and then double-click Services. The Lotus Domino Server (LotusDominodata) service must be running. If it is not, right-click and select Start.

This is necessary for WebSphere Portal to access LDAP. If it is not running, a dialog box will appear that says Check if your LDAP server is running when you start the installation. If you see this dialog, restart Domino and click OK.


Click Next and the installation will begin.

18.Part way through the install, you will then get a message to configure Admin Roles as shown in Figure 5-98. Follow the instructions in step 5 on page 182 of 5.2.11, “Installation procedure” on page 176. When following these instructions, you should not expect the Enable Security box to be selected, since we deselected it ourselves in Figure 5-91.

Important: While adding wpsadmin to the administrative role, also add wpsbind and wpsadmins.

If you didn’t read the above: If you are installing just Domino LDAP and you do not add wpsbind and wpsadmins to the administrative role, you will get a message when you proceed indicating that the WebSphere Server could not be restarted. If you try to access the Administrative Console you will find that you are unable to connect.

To recover from this error:

1. Edit the file \WebSphere\AppServer\properties\sas.client.props.2. Set: com.ibm.CORBA.loginSource=prompt3. Save the file.4. Log in to the Administrative Console as wpsadmin.5. Access the security panel via Console ->Security Center...6. Disable security on the General tab and click Apply.7. Exit the Administrative Console.8. Stop and restart WebSphere via the Services panel.9. Uninstall WebSphere Portal via the menu command: Start -> Programs ->

IBM WebSphere -> Portal Server -> Uninstall WebSphere Portal.10.Start this section 5.3.9, “Installing WebSphere Portal” on page 238, again.


Figure 5-98 Instructions on Configuring Admin roles in WebSphere Application Server

11.After completing the steps and before clicking OK, make sure that you can access the following URL:

http://<yourFullyQualifiedHostName>/wps/portal

You should get a WebSphere Portal Server window that says Your portal does not have any page groups as shown in Figure 5-99.

If your receive any errors, the WebSphere Portal Application Server was probably not started correctly. You may need to stop and start the WebSphere


Portal App Server again. The Portlets install will fail if WebSphere Portal App Server is not started.

Click OK when this is working correctly.

Figure 5-99 Portal page groups

WebSphere Portal will continue to install. It may take over thirty minutes. If the Installing Productivity Portlets section goes fast, there might be an error, so check the WPO Setup Manager log and look at the output logs.

12.When install is completed, an Installation is complete box will come up as in Figure 5-100. Click OK and click Finish.

Figure 5-100 Installation is complete!

13.You will need to replace the temporary rt.jar file with the original. Stop the WebSphere Admin Server as described in step 3 on page 239. Delete the file WebSphere\AppServer\java\jre\lib\rt.jar. Rename rt.old in the same directory to rt.jar. Restart the WebSphere Admin Server.

5.3.10 Verifying the WebSphere portal installVerify the portal installation as described in 5.5.2, “Testing steps” on page 259.


5.4 Installing WebSphere Portal with Active Directory using the Setup Manager

Microsoft makes use of Active Directory to provide directory services for the Windows platform. Active Directory is designed to be a consolidation point for isolating, migrating, centrally managing, and reducing the number of directories that companies require. Active Directory provides a single point of management for Windows-based user accounts, clients, servers, and applications. In this role, Active Directory can be used as an LDAP source for WebSphere and in turn WebSphere Portal. This section details the use of Active Directory with WebSphere Portal.

More information on Active Directory can be found at:

http://www.microsoft.com/windows2000/technologies/directory/ad/default.asp

Figure 5-101 WebSphere Portal two tier topology with Active Directory

In this section, we are installing Active Directory to work in a two-tier WebSphere Portal topology as seen in Figure 5-101. The details of the topology are seen in


WAS40

WPS41

WMS


LDAP

IBM HTTP Server

Windows 2000 Server

MicrosoftActive Directory

Windows 2000 Server




WebSphere Portal

Portlet


http://www.microsoft.com/windows2000/technologies/directory/ad

http://www.microsoft.com/windows2000/technologies/directory/ad/default.asp.


Table 5-2. We are setting up a new domain with Active Directory as the name service.

Table 5-2 Active Directory - WebSphere Portal Topology

5.4.1 WebSphere Portal with Active Directory using Setup ManagerThe process for setting up WebSphere Portal with Active Directory via Setup Manager is the same as the process for setting up WebSphere Portal with any other LDAP source with the exception of a couple of steps. The basic steps for setting up with Active Directory are the same as with any other LDAP source except for the fact that Active Directory has its own schema, and thus the entered values are different for Active Directory. The information collected by the Setup Manager for installing with Active Directory is the same as the information collected when installing WebSphere Portal outside of Setup Manager (see 6.8.5, “Install WebSphere Portal using Active Directory” on page 470).

Setup Manager also assumes you have Active Directory installed and configured. Setup Manager does not install and configure Active Directory for you as it does SecureWay. For more information of setting up Active Directory under Windows 2000, see 6.8.1, “Installing Active Directory” on page 451.

Machine Role Active Directory Server WebSphere Portal

DNS Name mars.itso.ral.ibm.com venus.itso.ral.ibm.com

IP address 10.10.0.1 10.10.0.2

Domain itso.ral.ibm.com itso.ral.ibm.com

Domain Role Domain ControllerDomain Name System (DNS) COntroller

Member Server

Operating System Windows 2000 ServerService Pack 3

Windows 2000 ServerService Pack 3

Additional Windows Components

Active DirectoryWindows 2000 Support ToolsWindows 2000 Administrative Tools

Additional Software

DB2WebSphere Application ServerWebSphere PersonalizationWebSphere Portal


Section 6.8.4, “Configuring Active Directory” on page 461 then details the configuration of Active Directory for use with WebSphere Portal.

Once your Active Directory is set up and configured, the following section details the portion of Setup Manager that is unique for configuring with Active Directory.

Upon reaching the LDAP Selection panel in the Setup Manager process, as seen in Figure 5-102, you start the configuration of WebSphere Portal for Active Directory. At this point, you have just completed the WebSphere Portal Security Settings as seen in Figure 5-15 on page 169.

To configure WebSphere Portal with Active Directory, start on the LDAP Server selection window as seen in Figure 5-102.

Figure 5-102 LDAP Server Selection


1. Select the Microsoft Active Directory server type and complete the rest of the fields as follows:

– LDAP Server name

This is the fully-qualified name of your LDAP server. In our example, the fully-qualified name of the LDAP server (from Table 5-2 on page 252) is mars.itso.ral.ibm.com.

Enter your fully-qualified LDAP server name.

– User DN

This is the fully-qualified name of the user that has authorization to read and update the Active Directory data. From our install of Active Directory (6.8.1, “Installing Active Directory” on page 451), our user DN is

cn=administrator, cn=users, dc=itso, dc=ral, dc=ibm, dc=com.

Note that with Active Directory, there is not an unqualified user name for the administrator as in SecureWay. Therefore cn=administrator is not valid with Active Directory and will cause the installation to fail.

If you are unsure of your fully-qualified User DN, see Step 2 on page 471 for details on how to find it in Active Directory.

Enter your User DN.

– User password

This is the password for the user specified in the User DN field.

Enter your password.

– Suffix

This is the base tree in LDAP that WebSphere Portal will add its information. We defined this as dc=itso, dc=ral, dc=ibm, dc=com in our Active Directory install.

If you are unsure of your suffix, see 2 on page 471 for determining your suffix.

Enter your suffix.

Important: This must be the fully-qualified name of the server. Using a short name here, such as mars in ours case, will cause the install to be incorrect. WebSphere security will not be configured properly which will cause a failure on the restart of the application server during install.


– LDAP port number

This is the port number that the LDAP server uses to listen for requests. By default this is port 389. We used a default install so we will not change this value.

Enter your LDAP port number.

Click Next to continue.

2. We now proceed to the LDAP configuration as shown in Figure 5-103.

Figure 5-103 LDAP Configuration

We have to configure the DN entries for the users, groups and the portal administrator.


3. Define the User Distinguished Name (DN) information

– User Object Class

The Object class defines which schema WebSphere Portal will use for storing the user information. Active Directory by default uses the user object class.

Enter user for the user object class, or if you have defined your own user class in Active Directory, enter your user class.

– User DN Prefix

This is the DN prefix for the user IDs that will be stored in LDAP. By default, this is cn for Active Directory.

If you are unsure of your prefix, see step 5 on page 476, to determine your user prefix.

Enter your user prefix in the User DN prefix field.

– User DN Suffix

This is the branch of the LDAP directory that WebSphere Portal will use to add users and look up users. By default Active Directory puts its users in

cn=users, dc=itso, dc=ral, dc=ibm, dc=com.

If you are unsure of your suffix, see 5 on page 476, to determine your user suffix.

Enter your user suffix in the User DN suffix field.

4. Define the Group Distinguished Name (DN) information.

– Group Object Class

The Object class defines which schema WebSphere Portal will use for storing the group information. Active Directory by default uses the group object class.

Enter group for the user object class, or if you have defined your own group class in Active Directory, enter your group class.

– Group DN Prefix

This is the DN prefix for the groups that will be stored in LDAP. By default this is cn for Active Directory.

If you are unsure of your prefix, see step 6 on page 477, to determine your user prefix.

Enter your group prefix in the User DN prefix field.


– Group DN Suffix

This is the branch of the LDAP tree that WebSphere Portal will use to add groups and look up groups. By default Active Directory puts its groups in the same branch as its users so the suffix would be

cn=users, dc=itso, dc=ral, dc=ibm, dc=com.

If you are unsure of your suffix, see step 6 on page 477 to determine your user suffix.

Enter your user suffix in the Group DN suffix field.

5. Finally, define the user for administering the WebSphere Portal.

We defined the wpsadmin user when we configured our Active Directory for use with WebSphere Portal in 6.8.4, “Configuring Active Directory” on page 461.

– Administrator DN

This is the fully-qualified name of the WebSphere Portal administrator. Our administrators fully-qualified name is

cn=wpsadmin, cn=users, dc=itso, dc=ral, dc=ibm, dc=com.

Enter the fully-qualified name of your portal administrator.

– Administrative group

This is the fully-qualified name of the group defined for the portal administrators. We configured the group wpsadmins when we configured Active Directory in 6.8.4, “Configuring Active Directory” on page 461, so our fully-qualified administrative group name is

cn=wpsadmins, cn=users, dc=itso, dc=ral, dc=ibm, dc=com.

Enter your fully-qualified administrative group name.

Click Next.

This completes the portion of Setup Manager that is configured for Active Directory. Continue now with the rest of the WebSphere Portal install in the same way it was done with SecureWay in 5.2, “Installing WebSphere Portal with SecureWay using the Setup Manager” on page 150. The next window you will see is the Portal Server Database Selection in Step 5 on page 172.


5.5 Testing for successful installationUse the following sections to test your installation.

5.5.1 Checking the installation log fileDuring WebSphere Portal installation, all actions and outcomes are recorded in the log files as listed in Table 5-3 and available under the <wps_home>/install/ directory listed in Table 5-3. These files contains information that can assist you in identifying and analyzing problems.

Table 5-3 Installation log files

Log file name Description Problem symptoms

ConfigureAppServer.log Contains messages that were generated when the installer attempts to configure the WebSphere Portal Application Server under WebSphere Application Server.

Check this log if the portal installation stops before successful completion.

DbCreate.logDbInit.log WmsDbCreate.logWmsDbInit.logWmsDbPopulate.log

Contains messages that were generated by the scripts used to create and initialize the WebSphere Portal and WebSphere Member Service database instances.

Check these logs for error messages if you have problems logging in as the portal administrator after the portal is installed.

DeployAdminPortlets.log Contains a message that indicates whether the base administration and customization portlets were successfully deployed. This file is updated whenever you install the portal using the automated installer. The log is also updated whenever you use the portal configuration interface to manually configure a portal.

If you need to determine whether the portal installation was successful, view this file to determine the status of the installation.

RegenerateHTTPServerPlugin.log

During portal installation, if the WebSphere Application Server plug-in cannot be regenerated, an entry is made in this log.

Check this log if problems occur during the portal installation or if you have portal problems after installation.


5.5.2 Testing stepsFollow these steps to test your WebSphere Portal installation.

1. To check whether you have installed WebSphere Portal successfully, use any machine on the network that has access to the installed server and has a Web browser installed.

2. Enter the URL http://<completedomainname>/wps/myportal in the browser as shown in Figure 5-104. Select the key icon in the upper right-hand corner of the portal window, then enter the user name and password wpsadmin to log in (this was the user name and password that we used for the installation).

StartWPS.log Contains messages generated when the portal installer attempts to start the WebSphere Portal Application Server running under WebSphere Application Server.

Check this log if you cannot open the portal after a successful installation.


Note: After the WebSphere Portal 4.1 install, a restart command has been issued to restart WebSphere Application Server Service. You must wait until this finishes before testing WebSphere Portal 4.1.


Figure 5-104 Login to WebSphere Portal

3. If all the Portlets are installed properly and if the installation is successful, you should see the WebSphere Portal Welcome page as shown in Figure 5-105.

Note: You should be able to create a new user and log in with this new user. Since we have the user wpsadmin already defined in the adminrole, we can use this new user ID for testing purpose


Figure 5-105 WebSphere Portal Welcome Page

4. Additional Test (optional)

You can select the Portal Administration Portlet option from the drop-down menu at the top left hand corner of the page. If all of the administrative portlets are installed successfully, you should see the page as shown in Figure 5-106.


Figure 5-106 WebSphere Portal Administration Page

5.6 Common installation questionsFollowing are some of the common installation questions that we have come across:

1. I have installed WebSphere Portal 4.1 and when I click Web Clipping portlet on the Portal Administration, I get the message This Portlet is unavailable. How do I resolve this?

A. Web Clipping uses Transcoding Publishing technology. Make sure that you install Transcoding Publisher and this problem should be resolved.

2. I have mapped an external static IP to the computer. WebSphere Portal 4.1 is serving all of the pages by referencing the computer name and the domain name rather than the TCP/IP address. How do I resolve this problem?


A. Add the external IP address in the configservice.prop file available under, was_root\appserver\lib\app and this should resolve the problem.

3. I have WebSphere Portal 4.1.1 installed; how can I upgrade to WebSphere Portal 4.1.2?

A. Here are some of the steps that you will have to follow:

a. Uninstall WebSphere Portal 4.1.1 and WebSphere Personalization Server 4.0.1

b. Use the Setup Manager for WebSphere Portal 4.1.2 and install WebSphere Personalization and WebSphere Portal and you should have a successful installation of WebSphere Portal 4.1.2.

4. I've just finished installing WebSphere Portal Server through the Setup Manager and the installation logfiles shows the message Installation completed Successfully. When I go to the default portal http://mycompletedomain name/wps/portal/, I get a page with the message Your portal does not have any page groups. Please check if there is a page group defined for the markup of your client device. Do I need to reinstall the product?

A. No. You will not be required to reinstall the product. This message explains that Portlets did not get installed completely during installation process from the Setup Manager.

– Solution: Don't panic. Execute runXMLAccess.bat file, which will be under Was_root\PortalServer\install directory.

– This step takes a long time to complete. Be patient.

– You should see numbers increasing to "<!—214/214-->.

– You can watch the progress in the Task Manager under the Performance Tab.

5. I am unable to install a portlet since there is no Portlets tab on my Portal Administration page. I see all other tabs such as Portal Setting, Users and Groups, Security, Portal Content. Is there a way to fix this problem?

A. This problem occurs when you don't have access rights to the Portlet. Go to Security Portlet and provide access to Portlets. For this operation, you should have logged in as user with admin rights.

6. I have Windows Service Pack 3 Installed and I when I try to install WebSphere Portal 4.1.2, WebSphere Portal Setup Manager is not allowing me to proceed with the installation. Is there any workaround for this problem?

A. Yes. Proceed as follows:


a. Open Registry in Windows and find HEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersioCSDVersion.

b. Change the value to Service Pack 2. You need to click the CSDVerision to change the value. Once the WebSphere Portal installation is complete, change to the settings to the default value.

7. I have WebSphere Application Server Security enabled and I do not recollect my password. I am stuck with WebSphere Portal installation; is there any way that I can turn WebSphere Application Server security off?

A.:

a. If you enable security in WebSphere Application Server, and forget your password, follow these steps to disable security on the server without requiring a re-install:

i. Stop the WebSphere Application Server.

ii. Go to the DB2 command line processor (if you are using a version of WebSphere which uses DB2 as its administration database).

iii. Connect to the WebSphere Application Server database (or another name if you customized this).

iv. Run the following SQL command:

UPDATE EJSADMIN.SECURITYCFG_TABLESET SECURITYENABLED=0

b. Edit the properties/sas.server.props file, and change the following property to false: com.ibm.CORBA.securityEnabled=false

c. Restart WebSphere Application Server.

d. Security should now be disabled.

8. My WebSphere Portal installation hangs and gives a no class definition error:

COM/IBM/WEBSPHERE/PERSONALIZATION/RESOURCES/RESOURCE.

A. This error happens when:

– You do not have WebSphere Personalization installed.

– WebSphere Personalization is not installed under WebSphere Portal.

9. WebSphere Portal installed failed with the message Could not find: wpsadmin and wpsbind. What might be the reason?

A. Make sure you have set the Global Security in WebSphere Application Server. Also, if you have specified the LDAP server name incorrectly, XMLConfig cannot verify the security and would not enable it using the createSecurity.xml file. Modify the server name, re-run the security


configuration and install WebSphere Portal again from the Setup Manager; this should resolve the problem.

10.I am having problems during WebSphere Personalization Server installation. After the progress bar indicates 25% complete, disk activity ceases and a few minutes after that, the installer reports a failure. At no point does the View Log button become enabled so I can see what error is occurring. What might be the reason?

A. WebSphere Personalization is having a problem locating your host.WebSphere Application Server requires inquiries to be case sensitive and Personalization Server can have difficulties installing if the case isn't just right when resolving the names for WebSphere Application Server.

11.I am running runXMLAccess.bat file and I get this error at Step 56.

<request>

<status element="package" refname="com.ibm.wps.portlets.install"result="failed"><message>com.ibm.wps.command.xml.XmlCommandException: Error duringexecution: [package globalid="com.ibm.wps.portlets.install"

handle="com.ibm.wps.portlets.install"] Nestedexception is: com.ibm.wps.command.CommandFailedException: InstallPortletApplicationfailed.-------some more lines ----

</status></request>

A. You need to set the Admin Role for the Group along with the User. Open WebSphere Admin Console - Security Center and set the Admin Role for the user. Once you do this, stop and start Admin Console for the changes to take effect and run the runXMLAccess.bat file again and it should not have the errors.

5.7 Post-installation instructionsOnce you have WebSphere Portal successfully installed, you may wish to perform any of the Post-Installation procedures as described. These steps are optional and depend on individual requirements.

5.7.1 WebSphere Application Server

Updating sas.client.propsIf you frequently use the WebSphere Administration Console, it might be worth getting rid of the Admin Console window that asks for a user name and password

when you start the WebSphere Admin Console. To do so, open the sas.client.props file in the /WebSphere/ApplicationServer/properties directory. We need to modify this file. Search for each of the following lines:

com.ibm.CORBA.loginSource=promptcom.ibm.CORBA.loginTimeout=300com.ibm.CORBA.securityEnabled=truecom.ibm.CORBA.loginUserid=com.ibm.CORBA.loginPassword=

Change the values for those lines to:

com.ibm.CORBA.loginSource=propertiescom.ibm.CORBA.loginTimeout=300com.ibm.CORBA.securityEnabled=truecom.ibm.CORBA.loginUserid=wpsbindcom.ibm.CORBA.loginPassword=wpsbind

5.7.2 SecureWay Directory

Apply SecureWay 3.2.2 e-Fix 2It is required to apply e-Fix 2, which is included on CD-ROM #1 in the subdirectory /swd-eFix/win. Read the installation instructions (WIN-128-2.txt) carefully and apply the fix as described.

Using a different user schema If you want to use an LDAP schema that differs from inetOrgPerson, you must make Java programming changes to the User bean and User EJB (provided with WebSphere Portal).

To add an attribute not currently in inetOrgPerson, or not currently exposed, do the following:

1. Update User.java, which you can find in wps.ear, with a get<attribute> and a set<attribute> method for the properties you want to add.

Note: No administration client requests issued from this particular machine to the WebSphere Application Server will require authorization any more. Make sure this configuration change does not breach your security guidelines.

Note: Stop all processes (including WebSphere Portal and WebSphere Application Server) which might access the LDAP Server before applying the e-Fix.


2. Update UserLdapBean.java, which you can find in wps.ear, to add the attribute name or names to the USER_BASIC_ATTRIBUTES structure, within the static block near the top of the class.

3. Update entries in the um.properties \WebSphere\PortalServer\wms\xml file. Update the user.inherit and group.inherit entries to reflect the object types that make up your user and group schemas in the LDAP directory.

5.7.3 Changing passwordsThis section is intended to show how to change some passwords after installation.

wpsadmin1. Use any Web browser to go to the WebSphere Portal page, for example

http://fully qualified domain name/wps/myportal

2. Log in as the wpsadmin user.

3. Click the Edit my profile button, which is located on the upper right corner of the Portal Web page.

4. Enter your new password in the fields Password and Confirm Password. Click Continue to set the new password.

wpsbind1. Start the WebSphere Admin Console.

2. Go to the Security Center.

3. Go to the Authentication tab and change the value of the field Security Server Password to a new password according to your requirement.

4. Start the Directory Management Tool (DMT).

Note: If you want to store the attributes in the relational database (DB2 or Oracle) instead within the LDAP directory, you do not have to make this update.

Note: The password change will be applied to the users that we used during our WebSphere Portal installation.

Important: Do not click OK or Apply button in the Security Console at this moment! Wait till you complete the configuration modifications with LDAP.


5. Rebind as Administrative User, based on the ID used for installing LDAP.

6. Browse in the directory tree to the user wpsbind, select it and click the Edit button.

7. Go to the end of the list in the window and change the value in the field userPassword. Click OK to set the new value.

8. Close the DMT.

9. Once you finish making these changes in LDAP, open the Security Center window in the WebSphere Admin Console. Click the Apply button to set and validate the new password.

10.Stop the WebSphere Application Server node.

11.Update your sas.client.props, if you made any changes.

12.Start the WebSphere Application Server and WebSphere Portal; changes should come into effect.

Changing the database password for WebSphere Application Server

This process involves two steps: changing the admin.config file of WebSphere Application Server and changing the password in the appropriate DataSources inside WebSphere Application Server.

1. Stop WebSphere Application Server.

2. Create a file (for example /tmp/filename) with a single line:

com.ibm.ejs.sm.adminServer.dbpassword=newpassword

3. Run the following command:

java -classpath /WebSphere/AppServer/lib/security.jar com.ibm.ws.security.util.PropFilePasswordEncoder /tmp/filename com.ibm.ejs.sm.adminServer.dbpassword

4. Replace the line that starts with com.ibm.ejs.sm.adminServer.dbpassword in the file /WebSphere/AppServer/bin/admin.config with the line in the changed file /tmp/filename.

5. Start the WebSphere Application Server.

6. Start the WebSphere Application Server Admin Console.

7. To change the password for the PersDataSource that is required by WebSphere Personalization Server, open the folder Resources in WebSphere Admin Console, then the folder JDBC Providers and then Pers DB Driver folder. Click the Data Sources folder.


8. Change the value in the field password and click the Test Connection button. If you issued the correct password, a pop-up window will tell you that the connection was successful.

9. Click the Apply button.

10.Close the Admin Console.

Changing the database password for WebSphere PortalWebSphere Portal uses DataStoreService.properties file to look for the password information. This file is available under <was_home>/lib/app/config/services/DataStoreService.properties, where <was_home> is the home directory of the WebSphere Application Server.

The values for datasource.userid and datasource.password are by default empty. We recommend not changing this default setting.

� If the values are not empty, you have to change them here.

� If the values are empty, you have to change the password setting in the wps40DS DataSource of WebSphere Application Server.

� To do so, follow these steps:

a. Start the WebSphere Admin Console.

b. Make sure that the WebSphere Portal application is not started.

c. Open the folder Resources, then the folder JDBC Providers, and after that the wps40JDBC folder.

d. Select wps40DS and change the value in the field password, then click the Test Connection button. If you issued the correct password, a pop-up window will tell you that the connection was successful.

e. Click the Apply button.

f. Close the AdminConsole.

Changing the database password for WebSphere Member Service

The password for the WebSphere Member Service database is an encrypted value in the field DBUserPwd that can be found in the file

Note: If WebSphere Member Service uses the same database user, as we have it in our sample installation, make sure you also change the passwords for WebSphere Member Service as described below, before starting the WebSphere Portal application.


<was_home>/lib/app/xml/wms.xml, where <was_home> is the home directory of WebSphere Application Server.

Incidentally, the database user ID and password are also defined in the deployed Enterprise Java Bean. To implement the password change, you will need to remove these entries.

Following are the steps required to update the password:

1. Create a new encrypted value by using a command as root user, as shown below:

C:\WebSphere\PortalServer\bin>wms_encrypt.bat newpassword

2. Replace the old value of DBUserPwd in wms.xml with the new generated ASCII value from the response. Use an editor to do this.

3. Remove the username/password entries in the installed Enterprise Java Beans (EJB) of WebSphere Member Service.

a. Start the WebSphere Application Server Admin Console. Open the Enterprise Applications folder, then the WebSphere Member Subsystem folder and click the EJB Modules folder. Select WCSCommon EJB and the General tab.

b. Remove the user ID and Password and click the Apply button

c. Do the same with WCSServer EJB and the WCSUser EJB.

4. Ensure that wmsDS has the correct password

a. Open the folder Resources in WebSphere Admin Console, then the JDBC Providers and wps40JDBC folder. Click Data Sources.

b. Select wmsDS, retype the password for the database user in the field and click the Test Connection button. If you issued the correct password, a pop-up window will tell you that the Connection was successful.

c. Click Apply and close the AdminConsole.

cn=ldapadminTwo steps are required to change the password of your Administrative Distinguished Name (DN) of your SecureWay Directory Server. The first is to update the password in the LDAP Server itself, the second is to update that password in the settings of WebSphere Member Service.

Note: If you do not have SecureWay Directory, but another LDAP Server, refer to the documentation of this product on how to change the password for the Administrative user.


Here is how to change the Administrative DN password in the SecureWay Directory Server:

1. Start the IBM SecureWay Directory Configuration Utility

2. Select only the checkbox Set the directory administrator name and password. Click Next.

3. The next window has the current Administrative user inserted in the field Administrative DN:. Make sure the field includes what you expect. For our example, the correct value is cn=ldapadmin.

4. Insert your new password in both the Administrator Password: field and the Type the password again to confirm field. Click Next to continue.

5. The next window gives you a summary of the action that you intend to set up. Click Configure to make those changes happen.

6. A window with a message will appear if your setup change was applied successfully.

7. Close the SecureWay Directory Configuration Utility.

8. Restart SecureWay Directory Server.

Changing the Administrative DN password for WebSphere MemberService

To change the password for the Administrative DN user in the WebSphere Member Service configuration, you would need to update the file <was_home>/lib/app/xml/wms.xml, where <was_home> is the home directory of WebSphere Application Server.

The password for the database is an encrypted value in the field LdapAdminPW.

There are two steps required to update this password value:

1. Create a new encrypted value by using a command as root user as

C:\WebSphere\PortalServer\bin>wms_encrypt.bat newpassword

2. Replace the old value of LdapAdminPW in wms.xml with the new generated ASCII value from the response. Use an editor to do this.

Important: The change of the Administrative DN password will take effect at the moment you start the SecureWay Directory Server again.


Changing the LTPA passwordKeep in mind that if you change the LTPA password, your exported LTPA Security keys are no longer valid. This is because changing the LTPA password means regenerating the Security keys.

1. To do this, open the WebSphere Admin Console and Security Center.

2. Click the Authentication tab.

3. Click the Generate Keys... button that is located in the center of the window.

4. You will get a pop-up window. Insert a new LTPA password, confirm it and click the OK button.

5. Restart WebSphere Application Server by stopping the node.

5.8 Uninstalling WebSphere PortalIn this section, we discuss the steps for uninstalling WebSphere Portal. Complete the following steps:

1. Use the uninstaller that comes with WebSphere Portal 4.1.

Click Start -> Programs -> WebSphere -> Portal Server -> Uninstall Portal Server

or Start -> Programs -> Control Panel -> Add/Remove Programs

2. Uninstall all the products installed with Setup Manager.

a. Use Start Programs ->Control Panel -> Add/Remove Programs.

b. Select WebSphere Portal ->Uninstall.

c. Select WebSphere Personalization Server -> Uninstall.

d. Select WebSphere Application Server -> Uninstall.

e. Select Secureway LDAP ->Uninstall.

f. Select DB2 ->Uninstall.

g. Select HTTP Server ->Uninstall.

Note: You can read Chapter 6.1, “Installation overview” on page 276 for additional post-installation instructions for WebSphere Portal.

Note: WebSphere Portal uninstallation requires you to have WebSphere Application Server up and running. If you drop the databases during uninstall, Setup Manager will allow you to create these databases during install.


h. Select IBM Cross Platform V 2.0 for Technologies ->Uninstall.

3. Once when you finish the above steps, reboot the machine and remove the physical directories of the products.

4. Check the registry under HKEY_LOCAL_MACHINE = SOFTWARE = IBM and make sure that none of the products that you uninstalled are visible. If you find any product that is, you can right-click the product and select Delete.

Important: It is recommended that you follow the order for uninstalling due to interdependency of the products. This will allow for complete and successful removal of the product.

Note: It is essential that you remove IBMWPO directory, which will be under C:\Programfiles\IBMWPO.


Chapter 6. WebSphere Portal: Windows manual installation

This chapter provides a set of procedures to help you set up and install WebSphere Portal V4.1 in a Microsoft Windows 2000 environment using IBM Secureway. This process does not include the use of the Setup Manager tool, so you can witness all activities involved in building your WebSphere Portal solution.

6


6.1 Installation overviewThis section provides a look at the manual installation of WebSphere Portal in a Microsoft Windows environment utilizing the IBM SecureWay Directory. Figure 6-1 is a pictorial diagram of the WebSphere Portal topology and IBM SecureWay Directory.

Figure 6-1 WebSphere Portal topology using IBM SecureWay

To prepare for the WebSphere Portal installation, you should acquire a set of WebSphere Portal for Multiplatform 4.1.2 CDs. After verifying your hardware and software requirements and checking that your target system has a static IP address assigned, you should proceed to 6.3, “DB2 Universal Database V7.2 installation” on page 277 to begin your installation.


WAS40

WPS41

WMS


LDAP

IBM HTTP Server

Windows 2000 Server

IBM SecureWay


WebSphere Portal


Portlet


6.2 Server environmentFor our setup of WebSphere Portal, we used the following hardware and software:

Hardware:

� IBM Netfinity8658-51Y:

– 1x Pentium III 933MHz w/ Front Side Bus: 133MHz

– 1 GB RAM, type = SDRAM ECC

– 1x 18 GB hard disk

– 1x 40X CD-ROM drive

– 1x 100 Mbps Ethernet

– 1x S3 Inc. S3 Trio3D graphics card

Software:

� Microsoft Windows 2000 with Service Pack 3

� DB2 Universal Database V7.2 Enterprise Edition

� WebSphere Application Server 4.02

� WebSphere Portal V4.1

� SecureWay Directory Server V3.2.2

� WebSphere Personalization V4.0

6.3 DB2 Universal Database V7.2 installationIn order to install IBM DB2 Universal Database, Enterprise Edition for Windows, perform the following steps on the database server machine:

1. Log on as the db2admin user.

Note: During the installation of DB2 and WebSphere Application Server, the users db2admin and wasadmin are created automatically for you. However, some administrators choose to create these user IDs prior to installing DB2 and WebSphere Application Server. If you choose to do so, the instructions are found in Appendix A, “db2admin and wasadmin user IDs” on page 693.

Chapter 6. WebSphere Portal: Windows manual installation 277

2. Insert the WebSphere Portal Multiplatform V4.1.1 Disk 2-1 CD (DB2 Universal Database Enterprise Edition for Windows) into your CD-ROM drive and navigate to the db2\win subdirectory.

3. Run the DB2 Setup.exe file. You will see a window similar to Figure 6-2.

Figure 6-2 DB2 installation window

4. Click Install. You will see a window similar to Figure 6-3.


Figure 6-3 Select Products window

5. Accept the default, DB2 Enterprise Edition and click Next. You will see a window similar to Figure 6-4.

Figure 6-4 Select Installation Type window


6. Select Custom and click Next. You will see a window similar to Figure 6-5.

Figure 6-5 Select Components window

7. At the Select Components window, select only the following components:

– Application Development Interfaces

– Documentation (optional)

– Base DB2 UDB Support

– Administration and Configuration Tools (optional)

– Getting Started (optional)

Click Next. You will see a window similar to Figure 6-6.


Figure 6-6 Create DB2 Instance window

8. Accept the default response, Yes, to create the default DB2 instance and click Next. You will see a window similar to Figure 6-7.

Figure 6-7 Configure DB2 Services window


9. Accept the default, DB2 Instance, and click Next. You will see a window similar to Figure 6-8.

Figure 6-8 Control Center Server window

10.Accept the default Username, db2admin. In the Password and Confirm password field, type db2admin. Click Next and you will see a window similar to Figure 6-9.

Figure 6-9 Question window

11.Click Yes to have DB2 Setup create the db2admin username. You will see a window similar to Figure 6-10.

Note: You will normally see this question asked when you are working on a pristine system or a system where DB2 has not been previously installed.


Figure 6-10 Current Setting window

12.Take a moment to familiarize yourself with the components that will be installed. Click Next to continue. DB2 Setup will be copying files to your systems hard drive. Click Finish when DB2 has completed its installation.

13.Complete and submit the IBM Product Registration then Exit. Exit the First Steps window if it is shown. Remove the CD from the CD-ROM drive.

6.3.1 DB2 Universal Database V7.2 Fixpack installationIn order to install IBM DB2 UDB V7.2 Fixpack, perform the following steps on the database server machine:

1. Insert the WebSphere Portal Multiplatform V4.1.1 Disk 2-10 CD (DB2 Universal Database Fixpack for Windows) into your CD-ROM drive and navigate to the db2fp\win subdirectory.

2. Run the DB2 Setup.exe file. You will see a window similar to Figure 6-11.

Note: For our example, we installed DB2 Universal Database V7.2 Fixpack 5 Service Level WR21294.


Figure 6-11 Warning window

3. If you receive a warning that several DB2 processes are running, click Yes to proceed. DB2 Fixpack will shut down these services for you before continuing with the installation. Next, you will see a window similar to Figure 6-12.

Figure 6-12 Choose Destination Location window

4. Accept the default and click Next. Again, click Next to begin the copying of files to your system.


5. Once files have complete copying and your system files are updated, click Finish. Exit the First Steps and Product Registration.

6.4 WebSphere Application Server V4.0 and IBM HTTP Server installation

Pre-installation tasks Prior to installing IBM HTTP Server V1.3.19, the following checks and tasks must be completed on the IBM HTTP Server machine:

1. Create groups and users.

2. Check that IP ports are unused.

Create groups and usersTo create the required groups and users, perform the following steps:

1. Create a Windows 2000 user with the following settings:

– Locally defined (not a member of a Windows domain)

– Member of Administrators group.

You can create local users and assign group memberships by clicking Control Panel -> Administrative Tools -> Computer Management -> System Tools -> Local Users and Groups.

2. Assign the following rights to this user:

– Act as part of the Operating System

– Log on as a Service

You can assign user rights by clicking Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment.

Note: We suggest creating the user wasadmin to run both the IBM HTTP Server and WebSphere. The remainder of this chapter assumes that wasadmin is used.


Check that IP ports are unusedTo check that the required ports are not in use, perform the following steps:

1. Check that there are no existing services on the server that use the following IP ports:

– 80 (standard HTTP port)

– 443 (standard HTTPS port)

– 8008 (IBM HTTP Server Administration port)

1. Click Start -> Settings -> Control Panel -> Administrative Tools -> Services to verify that DB2 is running.

1. Insert the WebSphere Portal Multiplatform V4.1.2 Disk 3-2 CD (WebSphere Application Server Advanced Edition for Windows and Linux) into your CD-ROM drive and navigate to the was\win subdirectory.

2. Run the WebSphere Application Server Setup.exe file. You will see a window similar to Figure 6-13.

Figure 6-13 Choose Setup Language window

3. Accept the default, English, and click OK.


Note: Before you proceed with the installation, you must shut down any Web servers you plan to use with WebSphere. In addition, you shut down all Windows programs before running the WebSphere Application Server setup.


4. Click Next to continue. You will see a window similar to Figure 6-14.

Figure 6-14 Installation Options window

5. Select Custom Installation and click Next. You will see a window similar to Figure 6-15.


Figure 6-15 Choose Application Server Components window

6. Ensure all components have been selected. Click Next. You will see a window similar to Figure 6-16.


Figure 6-16 Choose Webserver Plugins window

7. Accept the default, IBM HTTP Server. Click Next to continue. You will see a window similar to Figure 6-17.

Figure 6-17 Security Options window


8. Type in the username and password under which the Application Server Service will run. For our example, we used the username db2admin and its password. Click Next to continue. You will see a window similar to Figure 6-18.

Figure 6-18 Severe dialog window

If you get this message, indicating that Setup can verify specific privileges for the user, click OK to continue. You will see a window similar to Figure 6-19.

Figure 6-19 Product Directory window

9. Accept the default directory locations and click Next. You will see a window similar to Figure 6-20.


Figure 6-20 Database Options window

10.Accept the defaults and type in the Database User ID and Password. For our example, we typed db2admin and its password. Click Next to continue. You will see a window similar to Figure 6-21.


Figure 6-21 Select Program Folder window

11.Accept the default for the Program Folder name and click Next to continue. You will see a window similar to Figure 6-22.

Figure 6-22 Install Options Selected window


12.Take a moment to review and verify the options you chose and those listed as default. Click Next to begin the copying of files and the installation of WebSphere Application Server V4.0 and IBM HTTP Server to your system. Afterwards, you will see a window similar to Figure 6-23.

Figure 6-23 Warning dialog window

13.This warning indicates that you must run the usejdbc2 script after the installation to upgrade the JDBC drivers to the 2.0 level. Click OK.

14.Deselect the option Yes, I want to view the README file now and click Finish.

15.Accept the default, No, I will restart my computer later, and click OK.

6.4.1 Upgrade the DB2 JDBC driversComplete the following instructions to insert the JDBC drivers.

1. Click Start -> Settings -> Control Panel. Double-click Administrative Tools -> Services. You will see a window similar to Figure 6-24.


Figure 6-24 Services window

2. Stop all DB2 services. Open a Command Prompt and change the directory to C:\Program Files\SQLLIB\java12. Run the command usejdbc2. You will see a window similar to Figure 6-25.

Figure 6-25 Command Prompt window

3. Verify that the script file ran successfully and that no errors appeared.


6.4.2 WebSphere Application Server 4.0 FixPack2 installationIn this section, we will install the WebSphere Application Server 4.0 FixPack2. Complete the following instructions:

1. From the WebSphere Portal Multiplatform V4.1.2 Disk 3-2 CD (WebSphere Application Server Advanced Edition for Windows and Linux), copy the was\win\fixpack2 directory to C:\temp.

2. From the C:\temp\fixpack2 directory, run install.bat. You will see a window similar to Figure 6-26.

Figure 6-26 Executed install.bat window

3. Follow the instructions shown in Figure 6-26. Click Start -> Settings -> Control Panel and double-click Administrative Tools -> Services. You will see a window similar to Figure 6-27.


4. In the Services window, verify that IBM HTTP Server and IBM WS AdminServer 4.0 are not started. If they are started, stop them. Return to the command prompt where you executed install.bat and press the Enter key. You will see a window similar to Figure 6-28.


Figure 6-28 WebSphere Application Server install directory window

5. Enter the directory where WebSphere Application Server 4.0 is installed. In our example, we typed C:\WebSphere\AppServer. Press the Enter key to install the fixpack2 files. While the installation is taking place, be sure to watch for errors. The install process will have several prompts to which you will have to respond (see Figure 6-29).

Figure 6-29 Fixpack2 installation window

6. At the Please view the log for details stage, notice the line above it, where jdk_ptf_2.jar installed with no errors. Press Enter to continue.

7. Next, you are asked if you would like to upgrade the IBM HTTP Server. Type Yes and press the Enter key.


8. Next, you are asked to enter the directory where the IBM HTTP Server 1.3.19 is installed. In our example, we typed C:\IBM HTTP Server and pressed the Enter key. You will see a window similar to Figure 6-30.

Figure 6-30 Connector Architecture for WebSphere (J2C) window

9. Type Yes and press Enter to install the Connector Architecture for WebSphere (J2C). The fixpack2 will complete its installation.

10.Now reboot your system.

11.When the system has been restarted, you should see a window similar to Figure 6-31.

Figure 6-31 Create database window

12.Also note that the WebSphere First Steps window has been launched. Close this window.

13.Open a command prompt.

Figure 6-32 Run adminserver window

db2startSQL1026N The database manager is already active.

CREATE DATABASE was40


14.Change the directory to C:\WebSphere\AppServer\bin and run the adminserver.bat file. Allow the file to run until you see a window similar to Figure 6-33.

Figure 6-33 Adminserver open for e-business window

15.When the last line of the window reads: adminServer open for e-business, minimize this window.

6.4.3 IBM SecureWay V3.2.2 installationThe IBM SecureWay Directory V3.2.2 consists of the following components:

� slapd: the server executable

� Command line import/export utilities

� A server administration tool with a Web browser based interface for configuration and administration of the directory

� A Java-based directory content management tool and online user guide

� On-line Administration Help

� On-line LDAP Programming References (C, Server Plug-ins, and Java/JNDI)

� SecureWay Directory Client Software Development Kit (SDK) that includes C runtime libraries and Java(TM) classes


It includes a Lightweight Directory Access Protocol (LDAP) Version 3 server that supports IETF LDAPv3 (RFC 2251) protocol, schema, RootDSE, UTF-8, referrals, Simple Authentication and Security Layer (SASL) authentication mechanism and related specifications. In addition, it includes support for Secure Socket Layer (SSL), replication, access control, client certificate authentication, CRAM MD5 authentication, change log, password encryption, server plugins, enhanced search capability for compound Relative Distinguish Name (RDN), Web-based server administration GUI, LDAP V3 schema definitions, IBM common schema definitions, schema migration and performance improvements.

Enhancements in the 3.2 release include attribute-level ACLs, an improved server threading model, auditing, limited transaction support, event notification, and GSSAPI (Kerberos) authentication.

The SecureWay Directory Client SDK includes a Java-based Directory Management Tool, APIs to locate LDAP servers that are published in DNS, client-side caching for the Java-based JNDI interface, as well as other JNDI enhancements.

This version translates messages for Group 1 national languages on Windows NT, AIX and Solaris, including Brazilian Portuguese, French, German, Italian, Spanish, Japanese, Korean, Simplified Chinese, and Traditional Chinese. In addition, this product on AIX also translates messages in Czech, Polish, Hungarian, Russian, Catalan and Slovakian.

The directory provides scalability by storing information in the IBM DB2 Universal Database. DB2 is packaged with the directory product.

These sections outline the installation and configuration of SecureWay for use with WebSphere Portal.

Before installing Secureway V3.2.2, you must have a fully-qualified host name for your computer.

Complete the following steps to install and configure IBM Secureway V3.2.2:

1. From your Windows Services Panel, shut down your IBM HTTP Server.

2. Proceed to click Start -> Settings -> Control Panel and double-click Administrative Tools -> Services. You will see a window similar to Figure 6-34.

Note: You may only use the DB2 component in association with your licensed use of the SecureWay Directory.



3. In the Services window, stop the IBM HTTP Server.

4. To shut down the WebSphere Admin Server, click Start -> Programs -> IBM WebSphere -> Application Server V4.0 AE -> Administrator’s Console. You will see a window similar to Figure 6-35.

Figure 6-35 WebSphere Advanced Administrative Console window

5. Navigate to the system under Nodes. Right-click the system to bring up the menu and click Stop (in our example, the system is ibm662e305). If you look back at the adminserver.bat command prompt that was minimized, you will see where the adminserver has been stopped (see Figure 6-36).


Figure 6-36 adminserver.bat file command prompt window

6. Insert the WebSphere Portal for Multiplatform V4.1.1 Disk 5 CD (Secureway Directory) into your CD-ROM drive and navigate to the swd\win\ldap32_us subdirectory. Double-click Setup.exe.

7. Accept the default language, English, and click OK.

8. Click Accept to advanced beyond the Software License Agreement window.

9. Click Next to begin the installation of Lightweight Directory Access Protocol (LDAP). You will see a window similar to Figure 6-37.


Figure 6-37 Installed applications window

10.Review the applications that have been installed and click Next to continue. You will see a window similar to Figure 6-38.

Figure 6-38 Select Components window


11.Select Custom. You will see a window similar to Figure 6-39.

Figure 6-39 Choose Destination Location window

12.Accept the default to install LDAP and click Next. You will see a window similar to Figure 6-40.

Figure 6-40 Custom Installation window


13.Accept the defaults and click Next.

14.Accept the default for the name of the program folder, IBM Secureway Directory, and click Next. You will see a window similar to Figure 6-41.

Figure 6-41 Configure window

15.Ensure all three checkboxes have been selected. Click Next to continue. You will see a window similar to Figure 6-42.


Figure 6-42 Administrator distinguished name and password window

16.Accept cn=root for the Administrator distinguished name and enter a password in the Administrator password field. Enter the password again to confirm fields. In our example, we used the word password for cn=root. Click Next. You will see a window similar to Figure 6-43.


Figure 6-43 Create the IBM SecureWay Directory DB2 database window

17.Accept the default, Create a native language DB2 database (UTF-8), and click Next. You will see a window similar to Figure 6-44.

Figure 6-44 Configure new database window


18.Unless you have several options as to where to create your database, accept the default and click Next. You will see a window similar to Figure 6-45.

Figure 6-45 Location of configuration file window

19.Accept the default location of your httpd.conf file and click Next. You will see a window similar to Figure 6-46.


Figure 6-46 Start copying files for IBM SecureWay Directory and Client SDK window

20.Take a moment to review your current settings and then click Next to continue.

21.If you are interested in reviewing the README file, click Yes. In our example, we chose No and continued to see a window similar to Figure 6-47.


Figure 6-47 Setup Complete window

22.Accept the default, Yes, I want to restart my computer now and click Finish.

6.4.4 IBM SecureWay Directory administrationOn the reboot, IBM SecureWay Directory will configure a DB2 instance and create a database (see Figure 6-48). Before proceeding, please wait until this process has been completed.


Figure 6-48 ldapcfg.exe window

1. Navigate to the Windows Services window to start the IBM Secureway Directory Service. Click Start -> Settings -> Control Panel. Double-click Administrative Tools -> Services.

********************************************************************Starting IBM SecureWay Directory Configuration

*** DO NOT CANCEL THIS WINDOW ***

*** This could take several minutes ***********************************************************************

Creating the directory DB2 default database. This operation may take a few minutes.

Configuring the database.Adding user account: ldapdb2.Adding user account, ldapdb2, to the Administrators group.Adding account rights to account: ldapdb2.Added account rights to account: ldapdb2.Creating database instance: ldapdb2.Created database instance: ldapdb2.Logging on user: ldapdb2.Logged on user: ldapdb2.Impersonating user.Impersonated user.Logging on user: ldapdb2.Logged on user: ldapdb2.Impersonating user.Impersonated user.Cataloging node: ldapdb2.Cataloged node: ldapdb2.Starting database manager for instance: ldapdb2.Started database manager for instance: ldapdb2.Attaching to instance: ldapdb2.Attached to instance: ldapdb2.Creating database: ldapdb2.



2. Right-click IBM SecureWay Directory V3.2.2 and click Start.

3. Start up a browser and go to the URL http://ibm662e305/ldap. You will see a window similar to Figure 6-50.

Note: ibm662e305 is the host name of the system where we are installing the WebSphere Portal solution.


Figure 6-50 SecureWay Directory Server Web Admin: ibm662e305 window

4. In the Admin ID field, type cn=root. In the password field, type password. Click Logon. You will see a window similar to Figure 6-51.



5. In the left panel under Directory Server, click Settings -> Suffixes.

6. At the right of the Directory Server under Suffixes, you must add the distinguished name of the suffix you plan to use. Our computer name is ibm662e305.itso.ral.ibm.com. Therefore, our suffix should be dc=ibm, dc=com. Type dc=ibm,dc=com into the Suffix DN field and click Update. You will see a window similar Figure 6-52.



7. Click the black circle in the upper right-hand corner of the browser to restart the LDAP server.

8. Do not close the browser window. It will be needed in the next section.

6.4.5 Importing the Portal Server LDIF file1. Insert the IBM WebSphere Portal V4.1.2 CD Disk 7 (Portal Server) into your

CD-ROM drive. Copy the PortalServer\wps\WPSconfig.ldif file to a temp directory.

2. Open the WPSConfig.ldif file using WordPad. From the menu bar, click Edit -> Replace.


Figure 6-53 Replace window

3. Perform a global search of the WPSConfig.ldif file and replace the string yourco with the string which matches your suffix (see Figure 6-53). In our example, our suffix is ibm. Afterwards, you will see a window similar to Figure 6-54.

Figure 6-54 WPSconfig.ldif window


4. Review the changes you have made to the WPSConfig.ldif file and click File -> Save (you will need to remove the ‘read only’ attributes for the file). Make sure that you save the file as WPSConfig.ldif and not WPSConfig.ldif.txt.

5. Return to your opened browser, SecureWay Directory Server Web Admin: ibm662e305 (see Figure 6-55).

Figure 6-55 Import LDIF window

6. From the Directory Server panel, click Database -> Import LDIF. Enter the path and file name of the modified WPSConfig.ldif file. For our example, we

Note: If you used WordPad instead of another editing tool, you will need to rename the WPSConfig.ldif.txt to WPSConfig.ldif.


typed C:\temp\WPSConfig.ldif. Click Import. You will see a window similar to Figure 6-56.

Figure 6-56 Import LDIF window

7. In the Completed task messages box, you will see that six entries have been added. Close your browser at this time.

You have completed the install and configuration of SecureWay for use with WebSphere Portal. See 6.5, “WebSphere Portal install using IBM SecureWay Directory” on page 318 to continue your installation.


6.5 WebSphere Portal install using IBM SecureWay Directory

We have now installed the prerequisite products for WebSphere Portal. In this section, we install WebSphere Portal. Perform the following instructions.


1. From your Windows Services Panel, check to see whether your IBM HTTP Server and IBM WS AdminServer services are running. If they are, stop the IBM HTTP Server and AdminServer.

2. Insert the WebSphere Portal V4.1.2 CD Disk 3-2 (WebSphere Application Server Advanced Edition for Windows and Linux) into the CD-ROM drive. Navigate to the was\eFixes directory.

3. Copy the eFixes folder to your C:\WebSphere\AppServer directory.

4. Open up a command prompt and go to the C:\WebSphere\AppServer\eFixes directory. You will see a window similar to Figure 6-58.

Figure 6-58 Run Java window


5. Run the command:

C:\WebSphere\AppServer\java\jre\bin\java -jar C:\WebSphere\AppServer\Efixes\PQ56615_eFix_AEServer_AEsServer.jar

You will see a window similar to Figure 6-59.

Figure 6-59 Run Java window

6. Enter C:\WebSphere\AppServer as the target directory and press Enter. The Efix should now install with no errors.

7. Return to the Windows Services panel as shown in Figure 6-60.


8. Verify that your IBM Secureway Service is running and start your IBM HTTP Server and WebSphere AdminServer.


We now start the install of WebSphere Portal. The following instructions detail the install process.

1. Insert the IBM WebSphere Portal V4.1.2 CD Disk 7 (Portal Server) in the CD-ROM drive, navigate to the wps directory and run install.bat. You will see a window similar to Figure 6-61.

Figure 6-61 IBM WebSphere Portal welcome window


Note: When you notice a command prompt running in the background during your WebSphere Portal installation, do not stop the command prompt window from running. It must continue to run until your WebSphere Portal installation has been fully completed.


Figure 6-62 WebSphere Portal prerequisites window

3. Review the Prerequisites window to verify that you have complied with the required list of products. Click Next.

4. Select I accept the terms in the license agreement and click Next. You will see a window similar to Figure 6-63.


Figure 6-63 WebSphere Portal type of install window

5. Select the Standard installation and click Next. You will see a window similar to Figure 6-64.


Figure 6-64 Authentication mode for Members Services window

6. Select Database + LDAP as an authentication mode and click Next. You will see a window similar to Figure 6-65.


Figure 6-65 Global security window

7. Select Configure global security and click Next. You will see a window similar to Figure 6-66.


Figure 6-66 LTPA password for WebSphere Application Server security window

8. Enter wpsbind for the Lightweight Third Party Authentication (LTPA) password and click Next to continue. You will see a window similar to Figure 6-67.


Figure 6-67 Third party authorization and authentication window

9. Accept the default, No, and click Next. You will see a window similar to Figure 6-68.


Figure 6-68 LDAP type of server window

10.Select IBM SecureWay Directory as your LDAP Directory Server and click Next. You will see a window similar to Figure 6-69.


Figure 6-69 Access information for LDAP Server window

11.Complete the fields with the information provided below:

Server hostname = ibm662e305.itso.ral.ibm.com

Port = 389

User DN = cn=root

Password = password

Click Next to continue. You will see a window similar to Figure 6-70.


Figure 6-70 Connection data window

12.Type the suffix in the Suffix field. In our example, we typed dc=ibm,dc=com. The suffix should map back to your host domain. Click Next. You will see a window similar to Figure 6-71.


Figure 6-71 Customize LDAP settings window

13.Accept the default, Use default LDAP settings and click Next. You will see a window similar to Figure 6-72.


Figure 6-72 Administration node name window

14.Enter the node name of our system running WebSphere Application Server. In our example, it is ibm662e305. Click Next. You will see a window similar to Figure 6-73.


Figure 6-73 URL of the portal home page window

15.Enter the fully-qualified hostname in the hostname field. For our example, we typed ibm662e305.itso.ral.ibm.com. Accept the default Base URI, /wps. Click Next to continue. You will see a window similar to Figure 6-74.


Figure 6-74 Home page and customized page window

16.Accept the defaults, /portal and /myportal. Click Next. You will see a window similar to Figure 6-75.


Figure 6-75 Proxy server and proxy port window

17.Leave both fields blank and click Next to continue. You will see a window similar to Figure 6-76.


6.5.1 Deploying base portlets

Figure 6-76 Deploy base portlets window

18.Accept the default, Deploy base portlets into Portal Server and click Next. You will see a window similar to Figure 6-77.


Figure 6-77 Database selection window

19.Accept the default, IBM DB2 and click Next. You will see a window similar to Figure 6-78.


Figure 6-78 Storing portal data window

20.Accept the default, Create and initialize a new database and click Next. You will see a window similar to Figure 6-79.


Figure 6-79 Database access or creation information window

21.Accept the default, db2admin as your database user. Enter db2admin in the Database password and Confirm password fields. For our example, db2admin is the password we selected. Click Next. You will see a window similar to Figure 6-80.


Figure 6-80 JDBC library path window

22.Accept the default paths for the JDBC driver and library source and click Next. You will see a window similar to Figure 6-81.


Figure 6-81 Option for storing Member Services data window

23.Accept the default, Create and initialize a new database and click Next. You will see a window similar to Figure 6-82.


Figure 6-82 Database access or creation information window

24.Accept the default entries for Database user, Database password and Confirm password. db2admin is the entry for all fields. Accept the default Database name, WMS. Click Next to continue. You will see a window similar to Figure 6-83.


Figure 6-83 JDBC URL window

25.Accept the default JDBC URL prefix, jdbc:db2. Click Next. You will see a window similar to Figure 6-84.


Figure 6-84 Installation directory window

26.Accept the default Directory name, C:\WebSphere\PortalServer. Click Next. You will see a message stating that the directory does not exist. Click Yes to create it. You will see a window similar to Figure 6-85.


Figure 6-85 Install program window

27.Click Next to install WebSphere Portal. After copying the files, you will see a window similar to Figure 6-86.


Figure 6-86 Database WPS41 creation window

28.Click Next to continue. The database will be initialized. Wait for a message indicating that the database has been initialized successfully (see Figure 6-87).


Figure 6-87 Database initialized successfully window

29.Click Next. WebSphere Portal installation will now create the WMS database. You will see a window similar to Figure 6-88.


Figure 6-88 WMS database created successfully window

30.Click Next to initialize the database. You will see a window similar to Figure 6-89.



31.Click Next. You will see a window similar to Figure 6-90.



32.Click Next and the application server will begin its configuration. You will see a window similar to Figure 6-91.


Figure 6-91 application server configuration complete window

33.Click Next. You will see a message indicating that the HTTP plugin is being regenerated. Afterwards, you will receive another message stating that the configuration of the application server is complete (see Figure 6-92).


Figure 6-92 Application server configuration complete window

34.Click Next and you will see a window similar to Figure 6-93.


Figure 6-93 Stop the IBM HTTP Server window

35.At this time, stop and restart the IBM HTTP Server. Click Start -> Settings -> Control Panel. Double-click Administrative Tools -> Services. Right-click IBM HTTP Server and click Stop. After the server stops, right-click IBM HTTP Server and click Start.

36.Return to WebSphere Portal Installer (Figure 6-93) and click Next. The Installer will begin to back up your configuration. You will see a window similar to Figure 6-94.


Figure 6-94 Back up files window

37.Click Next and the installer will once again configure the application server. Be prepared to stop and check your Services window. You will see a window similar to Figure 6-95.


Figure 6-95 Application server configuration complete window

38.In Figure 6-95, the installer indicates that the administration server needs to be restarted. Note that the installer will automatically do this for you. Before going on to the next step, take a moment to view your Services window to ensure that the IBM WS AdminServer 4.0 has been started (click the Refresh button to be sure).

39.Click Next to continue. You will see a window similar to Figure 6-96.


Figure 6-96 Setting the Admin Role window

40.At this time, we must set the admin role.

41.Stop and start your HTTP server. Click Start -> Settings -> Control Panel. Double-click Administrative Tools -> Services. Right-click IBM HTTP Server and click Stop. After the server stops, right-click IBM HTTP Server and click Start.


42.Open the Administrative Console for WebSphere Application Server. Click Start -> Programs -> IBM WebSphere -> Application Server V4.0 AE -> Administrator’s Console. You will see a window similar to Figure 6-97.

Figure 6-97 Login window

43.When prompted for a user ID and password, type wpsbind in the User Identity field and type wpsbind in the User Password field. Click OK. You will see a window similar to Figure 6-98.



44.From the action bar, click Console -> Security Center. You will see a window similar to Figure 6-99.

Figure 6-99 Security Center window

45.In the General tab, verify that the option Enable Security is selected.

46.Click the Administrative Role tab.

47.In the list of Roles, select AdminRole and then click Select. The Select Users/Groups - AdminRole dialog is displayed (see Figure 6-100).



48.Click Select users/groups and then type * (the asterisk character) in the Search field. Click Search to display a list of users and groups. You will see a window similar to Figure 6-101.



49.In the list of Available Users/Groups, click uid=wpsadmin under Users and then click the Add button.

50.In the list of Available Users/Groups, click cn= wpsadmins under Groups, which is the group for portal administrators. Click the Add button. Adding the group wpsadmins enables all administrators to deploy portlets.

51.Click OK to add the AdminRole to the user wpsadmin and the group wpsadmins.

52.Click OK to close the Security Center. You will see a window similar to Figure 6-102.


Figure 6-102 JVM Settings window

53.Verify that the maximum Java heap size is at least 256 MB:

a. In the left navigation area of the Administrative Console, expand Nodes -> portal_node (for example, ibm662e305) -> Application Servers -> WebSphere Portal, where portal_node is the node for the WebSphere Portal installation.

b. In the right pane for the WebSphere Portal application server, click the JVM Settings tab.

c. Verify that the field Maximum java heap size is set to 256 or a higher value. If you change the field, click the Apply button to apply the change.

54.Now, go to the portal-node, in our example, ibm662e305 (see Figure 6-103).



55.Stop the Administrative Server for WebSphere Application Server. Right-click ibm662e305 and click Stop. Click Yes. This will cause the console to exit after the node is stopped.

56.From the Services window, restart the Administrative Server for WebSphere Application Server. Click Start -> Settings -> Control Panel. Double-click Administrative Tools -> Services. Right-click IBM WS AdminServer 4.0 and click Start. Once the IBM WS AdminServer 4.0 is started, continue with this installation.

57.Return to the IBM WebSphere Portal Installer. However, do not close it.

Note: If you look at your Services window, you will see that IBM WS AdminServer 4.0 is no longer running.


6.6 PersonalizationIn this section, we will begin the installation of WebSphere Personalization.

1. Insert the IBM WebSphere Portal V4.1.2 CD Disk 4 (WebSphere Personalization Recommendation Engine) into the CD-ROM drive. Navigate to the personalization directory. Copy the personalization directory to your C:\temp directory.

2. Place the IBM WebSphere Portal V4.1.2 CD Disk 7 (Portal Server) back into the CD-ROM drive after you have copied the personalization directory.

3. Navigate to the C:\temp\personalization\silent\response_files\nt directory. Remove read-only attributes on the directory and the files it contains (see Figure 6-104).

Figure 6-104 nt Properties window

Note: Do not stop the command prompt window from running in the background.


4. Right-click nt and click Properties. Deselect the Read-only box. Click Apply. You will see a window similar to Figure 6-105.

Figure 6-105 Confirm Attribute Changes window

5. Select Apply changes to this folder, subfolders and files. Click OK twice.

6. Go to the nt directory (see Figure 6-106).

Figure 6-106 nt directory window

7. In the nt directory, edit the pzn_silent_server.txt file (see Figure 6-107).


Figure 6-107 pzn_silent_server.txt - WordPad

8. Change the line:

-W bean28.appServer=”Default Server” to

-W bean28.appServer=”WebSphere Portal”

and save the file.

9. Navigate to the C:\temp\personalization\silent\nt directory. You will see a window similar to Figure 6-108.

Figure 6-108 silent\nt directory window

10.Run the pzn_silent_server.bat file.


Figure 6-109 Personalization Install window

11.After the Personalization install window closes, start the administrator’s console. Click Start -> Programs -> IBM WebSphere -> Application Server V4.0 AE -> Administrator’s Console. At the login window, enter wpsbind for the user ID and password. Click OK.

Note: The running of the pzn_silent_server.bat file will take several minutes to complete. This launches the Personalization Install window. Please be patient.

Note: Do not delete the Personalization directory image from your temp directory. You will need it again to install Personalization Workspace.



12.Stop and re-start WebSphere Portal. Right-click WebSphere Portal and click Stop. Click OK when the information dialog window indicates that WebSphere Portal.stop completed successfully. Right-click WebSphere Portal and click Start. Click OK when the information dialog window indicates that WebSphere Portal.start completed successfully.

13.Start your Internet browser and verify that you can get to the following URL: http://<your server>/wps/portal. In our example this is: http://ibm662e305/wps/portal.

14.You will see a window similar to Figure 6-111.


Figure 6-111 IBM WebSphere Portal - Microsoft Internet Explorer window

15.Return to the WebSphere Portal Installer. (refer to Figure 6-96). Click Next to continue. You will see a window similar to Figure 6-112.

Figure 6-112 Deployment of portlets window


16.When the portlet deployment is complete, click Next. You will see a window similar to Figure 6-113.

Figure 6-113 WebSphere Portal Final installation action window

17.Click Next. You will see a window similar to Figure 6-114.


Figure 6-114 Installation complete window

18.Click Finish. The IBM WebSphere Portal Installer will close as well as its associated command prompt window.

19.Test your install. From an browser, enter the following URL again:

http://<your server>/wps/portal

In our example this is http://ibm662e305/wps/portal

You will see a window similar to Figure 6-115.


Figure 6-115 WebSphere Portal Welcome window

This concludes the installation of Personalization.

6.7 WebSphere Portal install using Lotus Domino LDAP Directory

This section will address the steps necessary to configure WebSphere Portal to work with a Lotus Domino LDAP directory service. Directions are provided for a two-tier architecture, with Domino installed on one server and WebSphere Portal installed on another.

Directions for installing the WebSphere Portal detailed in section 6.3, “DB2 Universal Database V7.2 installation” on page 277, 6.4, “WebSphere Application


Server V4.0 and IBM HTTP Server installation” on page 285, and 6.6, “Personalization” on page 362 will be used for the WebSphere portion of the installation. Instructions for establishing a simple Domino Server configuration will be provided in this section, as well as test procedures to ensure that WebSphere is working correctly with the Domino LDAP service after you have completed installation of the WebSphere Portal.

If you already have a Domino Server installed, you should still read all the way through these directions carefully to ensure that all necessary users, groups, permissions, and services have been correctly provided and configured so that your WebSphere Portal installation will function correctly.

Figure 6-116 depicts a two-tier architecture, with WebSphere installed on one server and Domino providing LDAP services from a different server.

Figure 6-116 WebSphere Portal two tier topology with Domino



WAS40

WPS41

WMS


LDAP

IBM HTTP Server

WebSphere Portal

Portlet

Windows 2000 Server

Windows 2000 Server

Directory Services

Lotus Domino Server



6.7.1 Prerequisites

Windows 2000 administrationMake sure that Active Directory is not in use. This is an LDAP service which will conflict with Domino LDAP by binding to port 389. Also, make sure that no other service is binding to port 80 which will be needed by Domino’s HTTP service.

If you are using Active Directory on the Domino server then you will need to specify another port for the LDAP settings in the Domino server document, such as 386, since the port for AD cannot be changed; if you change the Domino LDAP port, be sure to adjust the directions for the configuration of WebSphere accordingly.

Users and groups requiredCreate the users wpsadmin and wpsbind on the Domino server; create the group wpsadmins and make both wpsadmin and wpsbind members of the group. These are users and groups that must be in the LDAP directory.

Patched rt.jar fileAs of this writing, a patched rt.jar file is required for the installation of the WebSphere Portal in section 6.7.12, “Install WebSphere Portal using Domino LDAP” on page 417. You will need to obtain this from IBM support.

6.7.2 Begin WebSphere installationExecute the installation instructions in sections 6.3, “DB2 Universal Database V7.2 installation” on page 277, through 6.4.2, “WebSphere Application Server 4.0 FixPack2 installation” on page 295, then stop. Do not proceed with the IBM Secureway installation (section 6.4.4, “IBM SecureWay Directory administration” on page 309). Instead, continue with the instructions provided here.


Warning: If you enable Active Directory on a Domino server which is already the LDAP server for WebSphere, and the Domino LDAP port is 389, you will lock yourself out of the WebSphere administrative console. This is because Active Directory will preemptively bind to port 389 and it will receive any authentication requests from WebSphere.


6.7.3 Domino installationIn this section, we will install Lotus Domino. This will be a simple installation, accepting most default settings for the establishment of a Domino Application Server. Complete the following instructions:

1. Log in to the designated Domino server using the Administrator ID for that server.

2. Insert the Domino CD (IBM WebSphere Portal V4.1.1 Disk 8-2 Lotus Domino Application Server for Windows & Linux) and navigate to the \domino\win\servers\wintel directory. Run setup.exe, and you will be presented with the R5 Splash window. Next, you will see a window similar to Figure 6-117.

Figure 6-117 Domino Setup Welcome window



Figure 6-118 License Agreement

4. Click Yes. You will see a window similar to Figure 6-119.

Figure 6-119 Company information window


5. Fill in the name of your organization and company, then click Next. You will see a window similar to Figure 6-120.

Figure 6-120 Setup Destination window

You may change the target locations if you wish, but it is advisable to accept the defaults.



Figure 6-121 Setup Type selection window

7. Accept the default installation, Domino Application Server, by clicking Next. You will see a window similar to Figure 6-122.


Figure 6-122 Program Folder selection

8. Accept the default by clicking Next, and the server installation will begin. You will see a window similar to Figure 6-123.

Figure 6-123 Domino installation complete window

9. You may choose to register now, or click Finish to exit the installation.


6.7.4 Configure the Domino ServerComplete the following steps to set up the Domino Server and LDAP services:

1. From the Start menu, click Start -> Programs -> Lotus Applications -> Lotus Domino Server. A DOS window will appear briefly, then you will be presented with the first configuration window (Figure 6-124).

Figure 6-124 Domino Server Setup window

2. Accept the default; this is our First Domino Server. Click the > button. You will see a window similar to Figure 6-125.


Figure 6-125 Domino Server Setup window 2

3. Select Advanced Configuration, then click the > button. You will see a window similar to Figure 6-126.


Figure 6-126 Domino Server Setup

4. Set additional configuration parameters:

a. Under Web Browsers select: HTTP.

b. Under Web Browsers select: IIOP.

c. Under Internet Directory Services select: LDAP.

You may configure additional services at this time, such as Enterprise Connection Services, or activate them later. Your configuration should look similar to those shown in Figure 6-126.

d. Click the > button to continue. You will see a window similar to Figure 6-127.


Figure 6-127 Domino Server Setup

5. Enter the password for the certifier ID (password, for this example), the name of the administrator and associated password (wpsadmin, for both in this example). Clear the Administrator’s First name and Middle Initial if there is anything present. The window should look similar to Figure 6-127.

Important: The certifier ID is the key to security for Domino. It is very important to make sure that this file is accessible only to designated administrators. It is equally important to ensure that you assign a password which would be difficult to guess and that the password be stored in a very secure place.


6. Click Finish to complete the configuration. A summary window will appear similar to Figure 6-128.

Figure 6-128 Domino Server Setup summary window

7. Stop! Click Set Access Control List Entry. You will see a window similar to Figure 6-129.

Note: The name and locations of the server, certifier, and administrator IDs. If you haven’t taken steps to record and secure the passwords, do so now (the server ID was created without a password).


Figure 6-129 Set Default Database Access window

8. Select Add a group, then enter wpsadmins as the name of the group. Click OK. You will be returned to the Domino Server Setup summary window (see Figure 6-130).

Figure 6-130 Final Domino Server Setup summary window

9. Now click Exit Configuration.

10.The server is now ready to start. From the Start menu, click Start -> Programs -> Lotus Applications -> Lotus Domino Server. A DOS window will appear and persist. It will take a while to load all of the services. For our example, it took about 90 seconds on the test machine. When it has finished loading, you will see a screen similar to Figure 6-131.

wpsadmins


Figure 6-131 Domino Server startup window

You have now successfully installed the Domino server.

6.7.5 Install a Domino Administration ClientIn this section, we will install the Domino Administration Client. Complete the following steps:

1. Make sure the Domino Server is running. If you have just finished installing and starting the Domino Server, you should see a window similar to Figure 6-131. If it has been running for some time since the original installation, you should have a DOS window open similar to Figure 6-132.

Important: You will not be able to proceed with the Administration Client installation unless the Domino Server is running.


Figure 6-132 Domino Server window after time has passed since startup

If you do not see such a window, go to the Start menu and choose Star t-> Programs -> Lotus Applications -> Lotus Domino Server.

2. Insert the CD WebSphere Portal 4.1.1 Disk 8-3 (Domino Administrator Notes) and navigate to the Lotus \win\clients\w32intel directory. Double-click Setup.exe to begin the installation. You will see the R5 splash and then a window similar to Figure 6-133.

Figure 6-133 Lotus Notes Installation Welcome window



Figure 6-134 Lotus Notes Installation Licensing Agreement window

4. Click Yes. You will see a window similar to Figure 6-135.

Figure 6-135 Lotus Notes Installation User Information window


e. Enter the name or organization and company information, then click Next. The installation folder selection window will appear (Figure 6-136).

Figure 6-136 Lotus Notes install destination

5. Accept the defaults or change the installation folders, then click Next. You will see a window similar to Figure 6-137.


Figure 6-137 Lotus Notes Installation Type Selection window

6. Select Domino Administrator and click Next. The folder installation window will appear.


Figure 6-138 Lotus Notes Installation Folder Selection window

7. You may accept the default or enter a new Program Folder name, then click Next. Files will be copied, and finally the Finish window will appear (Figure 6-139).

Figure 6-139 Lotus Notes Installation Finish window


8. Click Finish. You have completed the installation of the Domino Administration client.

6.7.6 Configure the Administration clientIn this section, we will configure the administration client. Complete the following instructions:

1. Start the Administration client by selecting Start -> Programs -> Lotus Applications -> Lotus Domino Administrator. You will see a window similar to Figure 6-140.

Figure 6-140 Client Configuration Setting Up Connections window



Figure 6-141 Client Configuration connection method window

3. Select I want to connect to a Domino server. and click Next. You will see the Connection Method window (Figure 6-142).

Figure 6-142 Connection method window

4. Choose Set up a connection to a local area network (LAN), then click Next. You will see a window similar to Figure 6-143.


Figure 6-143 Domino Server Name window

5. Enter the qualified name of your Domino server. For our example, we entered itso-0n5i4hw5xh/Dominotest. Click Next. You will see a window similar to Figure 6-144.

Figure 6-144 Administrator personal information window

6. Select Use my name as identification. In the User name field, enter the name of an administrator. In our example, we used the same ID as the WebSphere Portal administrator, wpsadmin. Click Next. The setup program


will establish a connection to your server and you will see a window similar to Figure 6-145.

Figure 6-145 Connection completion window


Figure 6-146 Internet Mail query window

8. In our example, we did not create an Internet mail account. Click Next.


Figure 6-147 News Server query window

9. In our example, we did not connect to a news server. Click Next.

Figure 6-148 Internet Directory query window

10.In our example, we did not connect to another directory server. Click Next.


Figure 6-149 Proxy Server query window

11.In our example, we did not connect to the Internet through a proxy server. Click Next. You will see a window similar to Figure 6-150.

Figure 6-150 Internet Connection Type window

Tip: If your installation requires a proxy server, you may obtain the necessary information through the IE browser by choosing Tools -> Internet Options... ->Connections (tab) -> LAN Settings....(button).


12.Choose Connect over local area network (or cable modem). Click Next. You will see a window similar to Figure 6-151.

Figure 6-151 Client Configuration completion window

13.You have finished the installation of the Administration client. Click Finish and you will see a window similar to Figure 6-152.

Figure 6-152 Password entry dialog box

14.Enter the password. For our example, we entered wpsadmin as the password. Note that this password can be changed later. Click OK and you will see a dialog box (Figure 6-153).

Figure 6-153 Notes setup completion message


15.Click OK. You have completed the configuration of the Administration client.

6.7.7 Create required users and configuration for LDAP

In this section, we will use the Administration Client to establish additional users in Domino and set the initial parameters. Complete the following steps:

1. To get started, click Start -> Programs -> Lotus Applications -> Lotus Domino Administrator, then enter the wpsadmin password. For our example, this is wpsadmin. You will see a window similar to Figure 6-154.

Figure 6-154 Domino Administrator welcome window

2. Click the Administration tab and you will see a window similar to Figure 6-155.


Figure 6-155 Administration People & Groups page

3. From the left-hand panel, select Domino Directories -> <your server’s > Address Book. Right-click People. You will see a window similar to Figure 6-156.

Figure 6-156 How to register a person

4. Select Register Person.... It will bring up a dialog box (Figure 6-157).


Figure 6-157 Certifier ID file browser

5. Select the certifier ID. In this case, it is cert.id. Click Open.

Figure 6-158 Password challenge for certifier ID

6. Enter the password. For this example, it is password. Click OK.

Figure 6-159 Password recovery warning

7. If you get this warning, click either button to continue. You will be presented with a registration window (see Figure 6-159).


Figure 6-160 Person registration - Basics data entry window

8. Check Advanced. Enter wpsbind into the Last name field. Enter wpsbind into the Password field. Check Set Internet password, then click the Groups icon on the left-hand side. You will see a window similar to Figure 6-161.


Figure 6-161 Person registration - Advanced data entry window

9. Under Assign person to group(s), select wpsadmins from the list. Click the Add--> button and wpsadmins will appear in the right-hand list. Click the Add person button and you will see a window similar to Figure 6-162.


Figure 6-162 Person registration window - with queue

10.Click Register All. You will see a window similar to Figure 6-163.

Figure 6-163 Successful person registration message

11.Click OK.


6.7.8 Configure server for LDAPIn this section, we will continue the configuration of the server for the LDAP directory. Complete the following instructions:

1. Security must be configured to allow access using IIOP. Select the Configuration tab in the administration console. Click Current Server Document in the left-hand panel, then click Edit Server. See Figure 6-164.

Figure 6-164 Administrator Current Server Configuration page

2. Choose the Security tab. You are going to make entries in the Java/COM restrictions section.This section is located in the lower right-hand side of the server document (Figure 6-165). Enter an asterisk in the Restricted/Java/Javascript/COM field and Administrators in the Unrestricted/Java/Javascript/COM field. It should look similar to Figure 6-165.

Figure 6-165 Java/COM Restrictions entries on server document Security page

3. Click Save and Close (if the application fail to close, press Ctrl+S, then press the Esc key). You will see a window similar to Figure 6-166.

Important: If this step (configuration of Java/COM restrictions) is not performed correctly, WebSphere applications which attempt to open an IIOP session to Domino will fail with error message number 4488.


Figure 6-166 Administrator Configurations page

4. Choose Configurations from the left-hand panel, then click Add Configuration as illustrated in Figure 6-166. Afterwards, you will see a window similar to Figure 6-167.


Figure 6-167 Administrator New Configuration window

5. Select the LDAP tab. You will see a window similar to Figure 6-168.


Figure 6-168 Administrator New Configurations page - LDAP tab

6. In the Choose fields that anonymous users can query via LDAP section, click the <<>> button. A dialog box similar to Figure 6-169 appears.

Figure 6-169 LDAP Field List dialog box

7. Add or remove fields as necessary for your installation, or just accept the defaults and click OK. You will be returned to the LDAP window which will now look similar to Figure 6-170.


Figure 6-170 New Configuration LDAP settings page - complete

8. Click Save and Close.

9. Close the Administrative console. Go to the Domino server window and type quit, then press the Enter key. Domino will shut down.

10.Restart the Domino server. Select Start -> Programs -> Lotus Applications -> Lotus Domino Server.

11.Type show tasks in the server window and press Enter. You should see a list that includes the LDAP server and HTTP server (Figure 6-171).


Figure 6-171 Partial list of Domino tasks - including LDAP and HTTP

6.7.9 Install WebSphere PersonalizationInstall WebSphere Personalization by completing the directions in 6.6, “Personalization” on page 362.

6.7.10 Configure Global Security on WebSphereIn this section, we will configure Global Security for the WebSphere Portal solution. Perform the following instructions:

1. Contact IBM support and obtain the latest copy of the rt.jar file for WebSphere.

Note: This file will be used temporarily for the installation, then replaced with the original.

Tip: If you do not replace the rt.jar file for the installation you may encounter an error that looks like this:

(Sep 23, 2002 5:00:33 PM), install, com.ibm.wps.install.LdapCheckPanel, msg2, Calling LDAP check with itso-0n5i4hw5xh.dominotest.com:389; cn=wpsadmin(o=dominotest;cn=wpsbind,o=dominotest;cn=wpsadmin,o=dominotest;cn=wpsadmins) Checking for 'o=dominotest' Checking for 'cn=wpsbind,o=dominotest' javax.naming.CommunicationException: Socket closed [Root exception is java.net.S ocketException: Socket closed]; remaining name 'cn=wpsbind,o=dominotest' (Sep 23, 2002 5:00:33 PM), install, com.ibm.wps.install.LdapCheckPanel, err, Code 2


2. Stop the Admin server via the Services panel. Select Start -> Settings -> Control Panel -> Administrative Tools -> Services. Select IBM WS AdminServer 4.0. Right-click and select Stop.

3. Rename the file WebSphere\AppServer\java\jre\lib\rt.jar to rt.old. Copy the latest copy of rt.jar into the same directory.

4. Restart the Admin server via the Services panel. Select Start->Settings -> Control Panel ->Administrative Tools -> Services. Select IBM WS AdminServer 4.0. Right-click and select Restart.

5. Open the Administrative console on WebSphere by selecting Start -> Programs -> IBM WebSphere -> Application Server V40 AE -> Administrator’s Console. You will see a window similar to Figure 6-172.

Figure 6-172 WebSphere Administrative Console - Security Center selection

6. Select Console -> Security Center. You will see a window similar to Figure 6-173.


Figure 6-173 WebSphere Security Center - General information tab

7. Click Enable Security.

8. Click the Authentication tab. You will see a window similar to Figure 6-174.


Figure 6-174 WebSphere Administration - Security Center - Authentication tab

9. Select Enable Single Sign-On. Enter the name of your Domino domain. In our example, it is dominotest. Select Enable Web trust association. Select LDAP.

10.In the Security Server ID field, enter wpsadmin. In the Security Server Password field, enter wpsadmin.

11.Enter the fully-qualified Domino server name in the Host field; for our example, it is itso-0n5i4hw5xh.dominotest.com. In the Directory type, select Domino 5.0. Because we are using the default Domino port for this installation, 389, we can leave the Port field blank; if using another, it must be entered.

12.Click Generate Keys. You will see a window similar to Figure 6-175.


Figure 6-175 LTPA keys password entry

13.Enter the password. In our example, we are using password as the password. Click OK. You will see a window similar to Figure 6-177.

Confirm in the lower console window of the WebSphere Administrator (which appears in its own window) that the keys were generated successfully. You should see a view similar to Figure 6-176.

Figure 6-176 WebSphere Administration - lower console message

Figure 6-177 File export browser window

14.Choose a location and file name for the key. We entered WPSDomino.key.

15.Click Save.

16.Now click Apply.


Figure 6-178 LTPA keys warning

17.Click OK.

18.Restart the WebSphere administrative server (IBM WS AdminServer 4.0) via the Windows Services panel.

6.7.11 Configure Single Sign-On in DominoIn this section, we will step through the configuration of Domino to enable Single Sign-On. Complete the following steps:

1. Open the Domino Administration console. Select All Server Documents from the left panel, and your Domino server on the right.

Figure 6-179 Domino Administrator - Configuration page

2. Click the Web icon in the right-hand panel. You will see a window similar to Figure 6-180.


Figure 6-180 Create Web SSO Configuration selection

3. Select Create Web SSO Configuration. You will see a window similar to Figure 6-181.

Figure 6-181 Import WebSphere LTPA Keys selection

4. In the Token Name field, enter the name of your domain (dominotest.com for this example). In the Domino Server Names field, enter the name of the server you will be using for LDAP.

5. Click the Keys... icon at the top of the form and select Import WebSphere LTPA Keys. You will see a window similar to Figure 6-182.

Figure 6-182 LTPA Import file path entry

6. Enter a path to the keys file. For our example, this is h:\wpsdomino.key. Click OK. You will see a window similar to Figure 6-183.


Figure 6-183 LTPA Import File Password entry

7. Enter the password for the keys file and click OK. You will see a key similar to Figure 6-184.

Figure 6-184 LTPA keys successful import message

8. Click OK.

Figure 6-185 Web SSO Configuration page

9. Make sure the LDAP Realm includes the fully-qualified server name. For our example, this is itso-0n5i4hw5xh.dominotest.com. Click Save and Close.


10.Double-click the LDAP server document in the right-hand panel. Click the Edit icon at the top of the form, then navigate to the Internet Protocols - Domino Web Engine panel as shown in Figure 6-186.

Figure 6-186 Internet Protocols - Domino Web Engine panel

11.For Session authentication, choose Multi-server. Click Save and Close.

12.Restart HTTP. Go to the Domino server window and type tell http quit. After you see the message HTTP Web Server shut down, type load http. You will see a window similar Figure 6-187.

Figure 6-187 Domino server window

You have finished the configuration of Single Sign-On.

13.Obtain LDAP schema.


Type this command in a DOS prompt window in the Lotus\Notes or Lotus\Domino directory to obtain the distinguished names in use on your Domino LDAP server:

ldapsearch -h yourserver -p 389 -d cn=wpsadmin,o=yourdomain -w wpsadmin -b o=yourdomain cn=* dn

You will get a response similar to Figure 6-188.

Figure 6-188 Ldapsearch results in a DOS window

From this example we can determine that the User Distinguished Name prefix for wpsadmin is CN, and the User Distinguished Name suffix is O=Dominotest. We will use this information to complete the setup of WebSphere security.

6.7.12 Install WebSphere Portal using Domino LDAPIn this section, we prepare for the installation of WebSphere Portal using the Domino LDAP.

1. Make sure that the Domino server is running and that LDAP is loaded. You may do this very simply by typing show tasks in the server window. LDAP and HTTP should both appear in the list of tasks, like this:

Figure 6-189 Partial list of tasks displayed by the Domino Server

2. Make sure that the WebSphere server is running.

3. Complete the WebSphere installation.


4. Load the IBM WebSphere Portal V4.1.2 CD Disk 7 (Portal Server) in the CD-ROM drive and navigate to the wps directory. Run install.bat. You will see a window similar to Figure 6-190.

Figure 6-190 WebSphere Portal Installer Welcome page

5. Click Next. The Prerequisites window will appear (Figure 6-191).


Figure 6-191 WebSphere Portal Installer Prerequisites window

6. Click Next. The Installation selection window will appear (Figure 6-192).


Figure 6-192 Installation Selection window

7. Select Standard and click Next. The Authentication Mode selection window will appear (Figure 6-193).


Figure 6-193 Authentication mode selection window

8. Select Database + LDAP and click Next. The Global Security modification window will appear (Figure 6-194).


Figure 6-194 Global Security configuration selection window

9. Select Do not modify global security settings and click Next. You will see a window similar to Figure 6-195.


Figure 6-195 Third-party authentication product query

10.Select No and click Next. You will see a window similar to Figure 6-196.


Figure 6-196 LDAP directly server type selection

11.Select Lotus Domino and click Next. You will see a window similar to Figure 6-197.


Figure 6-197 LDAP Access Information entry window

12.Enter the fully-qualified name of the Domino server. We are using port 389 (default) for this installation. We are using wpsadmin as the Domino administrator with a password of wpsadmin. Click Next when finished. You will see a window similar to Figure 6-198.


Figure 6-198 User Distinguished Name prefix and suffix entries

13.Enter the User DN prefix and suffix. For our example, this is cn for User DN prefix and o=dominotest for the User DN suffix. Click Next. You will see a window similar to Figure 6-199.


Figure 6-199 Group Distinguished Name prefix and suffix entries

14.Enter the Group DN prefix, cn. Click Next. You will see a window similar to Figure 6-200.


Figure 6-200 Object class information entry for LDAP schema

15.Accept the defaults and click Next. You will see a window similar to Figure 6-201.


Figure 6-201 Distinguished name entry of the portal administrator and administrative group

16.Enter the distinguished name of your portal administrator. In this example, we are using wpsadmin throughout the Portal installation. Click Next. You will see a window similar to Figure 6-202.


Figure 6-202 Entry of administration node name for the WebSphere server

17.Enter the name of the node; this may be obtained by opening the WebSphere Administrative Console. Click Next. You will see a window similar to Figure 6-203.


Figure 6-203 Entry of WebSphere Portal home page URL

18.Enter the fully-qualified host name of your WebSphere server. It is a good idea to test this by opening a DOS window and pinging it. Accept the Base URL of /wps and click Next. You will see a window similar to Figure 6-204.


Figure 6-204 Entry of portal page names

19.You may enter new names here or accept the default. For our example, we accepted the default. Click Next. You will see a window similar to Figure 6-205.


Figure 6-205 Proxy server information entry

20.We are not using a proxy server in our example. If you are using one, you would enter the Proxy server hostname and Proxy port at this time. Click Next. You will see a window similar to Figure 6-206.

21.Select Deploy base portlets into portal server. Click Next.

22.Select IBM DB2. Click Next.

23.Select Create and initialize a new database. Click Next.

Tip: If your installation requires a proxy server, you may obtain the necessary information through the IE browser by choosing Tools -> Internet Options... ->Connections (tab) -> LAN Settings....(button).

Note: Since the installation of WebSphere Portal using Domino LDAP is nearly identical to the installation using Secureway from this point forward, refer to section 6.5.1, “Deploying base portlets” on page 335 if you wish to see window images that are not included here.


24.Enter the name of the database administrator, db2admin in our example, with a password of db2admin. Accept the default database name. Click Next.

25.Accept the defaults and click Next.

26.Select Create and initialize a new database. Click Next.

27.Enter the name of the database administrator, db2admin in our example, with a password of db2admin. Accept the default database name. Click Next.

28.Accept the default JDBC URL prefix and click Next.

29.Accept the default or specify a new installation folder name. Click Next.

30.Click Yes to create the directory.

31.Click Next to begin the installation. This may take several minutes.

32.After database WPS41 has been created, click Next to continue. Continue to click Next as the database is initialized and the next database is created. Eventually you will be asked to log in.

33.Log in as wpsadmin with a password of wpsadmin. You will be asked to log in at several more points in the installation. Continue to use wpsadmin. Click OK.

34.When configuration of the application server is complete, you will get a message that says so. Check for errors, then click Next to continue.

35.Wait until the HTTP Server plugin has been regenerated. When the window appears warning you to restart any external HTTP servers, stop and restart the IBM HTTP Server via the Windows services console.

36.The installer will perform some backup services. When it has finished, click Next to continue.

37.You will receive a message indicating that configuration of the application server is complete. Check the output window for errors, then click Next to continue.

38.Portlets will now be deployed. This may take several minutes. When finished, click Next to continue.

39.At this point, a non-harmful error may occur as the installer attempts to display some useful information. It will look something like this.


Figure 6-206 Installer error - unable to display “secureFilesPanel”

40.If the message displays properly, you will be cautioned to change the passwords for your administrators (db2admin, wpsadmin, and wpsbind) if you followed these instructions for installation and used password or the administrator’s short name for a password. You are also advised to move the file wps_root/install.log and the contents of the wps_root/install directory to a secure location. Click Next to continue.

41.Click Finish.

42.Stop the WebSphere Admin server from the Services panel. Select Start -> Settings -> Control Panel -> Administrative Tools -> Services. Select IBM WS AdminServer 4.0. Right-click and select Stop.

43.Replace the patched rt.jar file with the original. Delete the file WebSphere\AppServer\java\jre\lib\rt.jar. Rename rt.old in the same directory to rt.jar.

44.Restart the Admin server via the Services panel. Select IBM WS AdminServer 4.0. Right-click and select Start.

45.Test the installation by opening a browser on the server. Enter the fully-qualified name of your server followed by /wps/portal and you should be able to see the portal default page (Figure 6-207).


Figure 6-207 Anonymous portal server page

46.Click the login icon in the upper right-hand corner of the window. You will be presented with a challenge (Figure 6-208).


Figure 6-208 WebSphere Portal challenge window

47.Enter wpsadmin for the User ID and Password, then click the Log in icon. You will be returned to the portal window, but you should see Welcome wpsadmin! in the upper right-hand corner (Figure 6-209).


Figure 6-209 WebSphere Portal welcome window for authenticated user

48.Click the exit icon (immediately below the Welcome message) to log out.

6.7.13 Test WebSphere with Domino LDAPIt should be possible to add user access from either the Domino Administrator client or from WebSphere if the installation is working correctly. We will add a test user from each, and check to make sure that they can both gain access to the WebSphere Portal.

Add a new user from WebSphereComplete the following steps to add a new user:

1. From the WebSphere Portal window, select the Sign up icon (paper and pencil). See Figure 6-210.


Figure 6-210 WebSphere Portal with Sign up icon highlighted

2. Afterwards, you will see a window similar to Figure 6-211.


Figure 6-211 WebSphere Portal sign-up window

3. Enter the required information as indicated by asterisks. We will use test1 for a user ID, and also for the password, followed by a first and last name. Click Continue when finished. You will see a window similar to Figure 6-212.


Figure 6-212 WebSphere Portal sign-up information confirmation

4. Click Continue. You will see a window similar to Figure 6-213.


Figure 6-213 WebSphere Portal sign-up success message.

5. Click Continue. You will be returned to the anonymous WebSphere Portal access window. Click the Log in icon (key on the right-hand side). You will see a window similar to Figure 6-214.


Figure 6-214 WebSphere log-in challenge window

6. Enter test1 for the User ID and Password. Click Log in. You will see a window similar to Figure 6-215.


Figure 6-215 WebSphere Portal welcome window for enrollment test user

7. This indicates that the test user was successfully registered with Domino LDAP. Access the Administrator client on the Domino server.

Figure 6-216 Domino People view showing new WebSphere registrant

8. Select the People and Groups tab, select People from the left-hand panel, and you should see the newly registered user (Alpha Tester) in the right-hand panel (Figure 6-216).

This concludes the first portion of our test.

Add new user from DominoComplete the following steps to add a new user from Domino:

1. Right-click People in the left-hand panel and select Register Person.... See Figure 6-217.


Figure 6-217 Domino person registration selection

2. Fill in the information for a new user in the same fashion used to register wpsbind in 6.7.7, “Create required users and configuration for LDAP” on page 397. You will see a window similar to Figure 6-218.


Figure 6-218 Domino person registration window

3. We will use BTester for the ID and password. Click the Add Person button when finished.

4. Click Register or Register All. Click Done. The people view should show the new registrant, similar to Figure 6-219.


Figure 6-219 Domino People view after adding second test registrant

5. Return to WebSphere Portal and log in using the ID created in Domino, BTester with a password of BTester.


Figure 6-220 WebSphere Portal log-in challenge window

6. Click Log in. You will see a window similar to Figure 6-221 showing the name of the test user created through Domino.


Figure 6-221 WebSphere welcome window for second authenticated test user.

This concludes the test for creation of a new WebSphere user through Domino.

6.8 WebSphere Portal install using Microsoft Active Directory

Microsoft makes use of Active Directory to provide directory services for the Windows platform. Active Directory is designed to be a consolidation point for isolating, migrating, centrally managing, and reducing the number of directories that companies require. Active Directory provides a single point of management for Windows-based user accounts, clients, servers, and applications. In this role, Active Directory can be used as an LDAP source for WebSphere and in turn WebSphere Portal. This section details the use of Active Directory with WebSphere Portal.

More information on Active Directory can be found at the following Web site:



http://www.microsoft.com/windows2000/technologies/directory/ad


http://www.microsoft.com/windows2000/technologies/directory/ad/default.asp.

Figure 6-222 WebSphere Portal topology using Microsoft Active Directory

In this section, we are installing Active Directory to work in a two-tier WebSphere Portal topology. The details of the topology are seen in Table 6-1. We are setting up a new domain with Active Directory as the name service.

Table 6-1 Active Directory - WebSphere Portal topology


DNS Name mars.itso.ral.ibm.com venus.itso.ral.ibm.com

IP address 10.10.0.1 10.10.0.2

Domain itso.ral.ibm.com itso.ral.ibm.com

Domain Role Domain ControllerDomain Name System (DNS) Controller

Member Server

Operating System Windows 2000 ServerService Pack 3

Windows 2000 ServerService Pack 3



WAS40

WPS41

WMS


LDAP

IBM HTTP Server


WebSphere Portal

Portlet

Windows 2000 Server

Windows 2000 ServerMicrosoft

Active Directory


6.8.1 Installing Active DirectoryFirst, we walk through the install of Microsoft Active Directory on Windows 2000 Server. Active Directory requires Windows 2000 Server. The following details a typical installation of Active Directory on Windows 2000 Server using the default schema. You must be logged on with administration privileges on the server to complete this install.

1. From the command line, run the dcpromo command. This launches the installation of the Active Directory Install action wizard as seen in Figure 6-223.

.

Figure 6-223 Active Directory Installation wizard

Additional Windows Components

Active DirectoryWindows 2000 Support ToolsWindows 2000 Administrative Tools

Additional Software

DB2WebSphere Application ServerWebSphere PersonalizationWebSphere Portal



2. Click Next to start the installation. You will see a window similar to Figure 6-224.

Figure 6-224 Choose domain controller for a new domain

3. The machine containing Active Directory will be the domain controller so select Domain controller for a new domain and click Next. You will see a window similar to Figure 6-225.


Figure 6-225 Create a new domain tree

4. Next, we create the new domain tree for our domain. Select Create a new domain tree and click Next. You will see a window similar to Figure 6-226.

Figure 6-226 Create a new forest of domain trees


5. In Figure 6-226, we create a new forest of domain trees. Select Create a new forest of domain trees and click Next. You will see a window similar to Figure 6-227.

Figure 6-227 New domain name DNS name

6. We now enter our the DNS name for the domain. From Table 6-1 on page 450, our domain name is itso.ral.ibm.com.

Enter your domain name, in the Full DNS name for new domain field and click Next. You will see a window similar to Figure 6-228.


Figure 6-228 Domain NetBIOS name

7. In the Domain NetBIOS window (Figure 6-228), leave the default value for the Domain NetBIOS name.

Ours will default to itso. Click Next.

Figure 6-229 Active Directory default database and log directories


8. We will accept the default values for the Active Directory database and log file as seen in Figure 6-229. You may choose to specify a different location if you desire.

Click Next when you have completed the specification of database and log directories.

Figure 6-230 Active Directory default volume

9. Accept the default folder location to be shared as a system volume and click Next.

10.Next a warning message appears indicating that the Active Directory wizard cannot contact the necessary DNS server for this domain. This is okay because we have not installed the DNS server. We are installing the DNS server as part of the Active Directory install.

Figure 6-231 Active Directory wizard unable to contact DNS

11.Click OK. You will see a window similar to Figure 6-232.


We want compatibility with pre-Windows 2000 servers for our user and group object permissions.

Figure 6-232 User and group object permissions

12.In the Permissions window (Figure 6-232), select Permissions compatible with pre-Windows 2000 servers and click Next.

13.Now set the Administrator’s password. The user ID assumed here is the one with which you are currently logged into Windows, in our case Administrator. Our Administrator’s password is password. Enter your administrator’s password and click Next.

14.Finally, review the installation summary as seen in Figure 6-233.

Note: This user ID and password combination will be used in the WebSphere Portal install, specifically in enabling global security. Make note of it for use during the WebSphere Portal install.


Figure 6-233 Active Directory install summary

15.Click Next when you are ready to begin the installation.

16.When the installation is complete, click Finish and restart the server.

We next install the Windows 2000 Support and Administration Tools to use in validating the install and configuring Active directory for use with WebSphere Portal.

6.8.2 Installing Windows 2000 Support and Administration toolsThis section details the installation instructions for installing the Windows 2000 Support Tools and the Windows 2000 Server Administration tools.

Windows 2000 Support ToolsThe Windows 2000 Support Tools contain the LDAP Utility and the ADSI Edit MMC snap-in tools, which we will use in configuring and validating the Active Directory and DNS install.

To install the Windows 2000 Support Tools, you must be logged on with administrator privileges. Install the Windows 2000 Support Tools as follows:


1. Run the following command from the Windows 2000 Server CD.

<CD Drive>:\Support\tools\setup.exe

where <CD Drive> is the drive letter where you have the Windows 2000 Server CD.

2. Supply the user information, name and organization. Click Next.

3. Select Typical install. Click Next to begin the installation.

4. When complete, click Finish to complete the install.

Windows 2000 Administration ToolsThe Windows 2000 Administration Tools includes the Active Directory Users and Computer Management console that is used in configuring Active Directory for use with WebSphere Portal.

To install the Windows 2000 Administration Tools:

1. Run the following command to invoke the administrative tools Install wizard.

<system drive>:\WINNT\System32\adminpak.msi

where <system drive> is the drive letter where you have Windows installed.

2. Select Install all of the Administrative Tools and click Next to start the installation.

3. When the installation is complete, click Finish to close the wizard.

Before you can use the ADSI Edit MMC snap-in tool, you must also register the schmmgt.dll with Windows. To register the DLL, run the following command:

regsvr32 schmmgt.dll

6.8.3 Validating the domain and DNS install

Validating the domainIn order to have a successful install of WebSphere Portal, the Active Directory server and WebSphere Portal must be in the same domain. To validate that both machines are in the same domain, do the following on each machine:

1. Open the server’s properties by selecting My Computer -> Properties.

2. Open the Network Identification tab, and validate that both machines are part of the same domain. From Table 6-1 on page 450, our machines names are venus and mars and they are both part of the itso.ral.ibm.com domain, so the Network Identification tab for the venus machines should look like Figure 6-234. Yours should look similar based on your machine names and domain names.


3. It is necessary that both machines have the same domain name. If this is the case, you are ready to proceed in the validation for the WebSphere Portal install.

Figure 6-234 Network Identification - Domain verification

Validating DNSIn order to have a successful install of WebSphere Portal with Active Directory, it is necessary that the WebSphere Portal be able to contact the Active Directory server via name through Directory Naming Service (DNS).

In our example, the WebSphere Portal machine is named venus and the Active Directory machine is mars, both in the itso.ral.ibm.com domain. In our example, we validate that the WebSphere Portal (venus) can contact the Active Directory server (mars) through a simple TCP/IP ping. Ping your Active Directory server from your WebSphere Portal using the fully-qualified name of the Active Directory server. For our configuration, we run the following command from the WebSphere Portal:

ping mars.itso.ral.ibm.com

and the results appear as shown in Figure 6-235.


Your results should be the same. If you receive a Request Timed Out message instead of a positive Reply from ... message, your name server is not working properly. Correct this problem before proceeding.

Figure 6-235 DNS verification

We have now confirmed that the DNS is working properly and that the WebSphere Portal and the Active Directory server are in the same domain.

6.8.4 Configuring Active DirectoryWe must now configure Active Directory to work with our WebSPhere Portal install. To do this, we need to create the wpsbind and wpsadmin IDs in Active Directory. The wpsbind ID will be used to configure security and wpsadmin will be used for administering the portal. Thus we need to create two IDs and the wpsadmins group to be used in the WebSphere administration security role.

In summary, we will be defining the groups and IDs summarized in Table 6-2 and Table 6-3.

Table 6-2 Portal administration group

Table 6-3 Portal User ids

Group Name Description Member of

wpsadmins Portal administration group Administrators group

User Name Description Member of

wpsadmin Portal administrator wpsadmins

wpsbind WebSphere security administrator


We use the Active Directory Users and Computers tool to manage the users in Active Directory that was installed with the Windows 2000 Administration Tools.

Define the wpsadmin user and wpsadmins groupTo define the wpsadmins group and wpsadmin user, perform the following steps:

1. Make sure you are logged on as a user with administration privileges. For example, you may use the same user you were logged on as to install Active Directory.

2. To open the Active Directory Users and Computers tool from the Windows program menu click Start -> Programs -> Administrative Tools -> Active Directory Users and Computers.

Figure 6-236 Active Directory User and Computers invocation

This opens the Active Directory Users and Computers tool as seen in Figure 6-237.


Figure 6-237 Active Directory User and Computers invocation

3. Expand the contact of the domain you created. During the install, we created the domain itso.ral.ibm.com as seen in Figure 6-237.


Figure 6-238 Create new group

4. Create the wpsadmins group by selecting Users -> New -> Group. You will see a window similar to Figure 6-239.


.

Figure 6-239 Wpsadmins group properties

5. Enter the details for the wpsadmins group as seen in Figure 6-239 and click OK. You will see a window similar to Figure 6-240.


Figure 6-240 Add the wpsadmins group to the Administrator group

6. Add the wpsadmins group to the administrators group by selecting Properties from the context menu of the group you just created.

In the Properties window, select the Members of tab and click Add.

Add the Administrators group and click OK.

7. Create the wpsadmin user for administering the Portal by selecting Users -> New-> User.

8. Complete the update by clicking OK.


Figure 6-241 New Object - User window for wpsadmin

9. Complete the New Object - User window as shown in Figure 6-241. Click Next. You will see a window similar to Figure 6-242.

Figure 6-242 wpsadmin password


10.Set the password for the wpsadmin user. In our example, we use the password of wpsadmin. Complete the password information as seen in Figure 6-242. Click Next and you will see a window similar to Figure 6-243.

Figure 6-243 Wpsadmin summary

11.Review the summary and click Finish.

Finally, add the wpsadmin user to the wpsadmins group.

1. Select Properties from the context menu of the wpsadmin user you just created. You will see a window similar to Figure 6-244.


Figure 6-244 Adding the wpsadmin user to the wpsadmins group

2. In the Members of tab, click Add.

3. Select the wpsadmins group and click OK.

4. Click OK to make the change effective.

Define the wpsbind userCreate the wpsbind user just as we created the wpsadmin user, as seen in Figure 6-245. The wpsbind user, however does not need to be added to the wpsadmins group.

In our example, we have set the wpsbind user’s password to wpsbind.


Figure 6-245 Wpsbind user properties

We have now installed Active Directory and configured the users and groups needed to install WebSphere Portal with Active Directory.

6.8.5 Install WebSphere Portal using Active DirectoryInstalling WebSphere Portal with Active Directory follows the same installation path as other LDAP servers except for the LDAP configuration itself. The following section details the steps unique to installing WebSphere Portal with Active Directory as opposed to the default of SecureWay.

1. During the WebSphere Portal install, when prompted for the LDAP directory server to configure, select Microsoft Active Directory (Figure 6-246) and click Next.


Figure 6-246 Configure Active Directory as the LDAP server

2. In the next window of the WebSphere Portal install (Figure 6-247), we specify the LDAP access information.

When asked for the LDAP access information, enter:

a. The fully-qualified name for the LDAP server, which is the fully-qualified name of the Active Directory server. In our example, this is:

mars.itso.ral.ibm.com.

b. The port number as 389.

The default port number for LDAP is 389. Enter your LDAP port number if you have configured your Active Directory server for a different LDAP port.

Note: You cannot use an IP address here. This is the reason we had to make sure that the WebSphere Portal and the Active Directory server were in the same domain and the WebSphere Portal could access the Active Directory server via its name (through DNS).


Figure 6-247 LDAP access information for Active Directory

c. Enter the fully-qualified user name and password of the user that has administration authority for the Active Directory.

This is the same user ID and password used to administer the users and computers in 6.8.4, “Configuring Active Directory” on page 461. In our example, the user ID and password are administrator and password, respectively.

The user ID has to be the fully-qualified user ID as defined by the schema in Active Directory. To determine the fully-qualified name of your administrator user, open the ADSI edit tool installed with the Windows 2000 Support Tools by clicking Start -> Programs -> Windows Support Tools -> Tools ->ADSI Edit as shown in Figure 6-248.


Figure 6-248 ADSI Edit tool invocation

This invokes the ADSI Edit tool as seen in Figure 6-249. This is where we discover the fully-qualified name of the Active Directory administrator’s ID, administrator in our case.

Expand the Domain NC where your user was created. In our case, expand dc=itso, dc=ral, dc=ibm, dc=com. Then expand the Users to see the administrator’s entry as seen in Figure 6-249 on page 474 for our user, administrator.

A user’s distinguished name can be determined by joining, in inverse order, the object the user belongs to. So in our case the administrator’s distinguished name is:

cn=administrator, cn= users, dc=itso, dc= ral, dc=ibm, dc= com

Determine the fully-qualified name of your user with authority to administer Active Directory and enter it into the User ID field of the WebSphere Portal access information window.

d. Finally, enter the password for the administration user. This is the same password used during the install of Active Directory (step 13 on page 457). In our example, the password is password.

e. Click Next.


Figure 6-249 Active Directory administrators fully-qualified name

3. Complete the suffix for the server that has been configured. This is the name for the Domain NC in Figure 6-249. In our case, it is:

dc=itso, dc=ral, dc=ibm, dc=com

as seen in Figure 6-250.

Click Next.


Figure 6-250 LDAP connection suffix

4. In the next window (Figure 6-251), we cannot use the default LDAP settings because we are not using Secureway.


Figure 6-251 Customize LDAP settings

Select Customize LDAP and click Next.

5. We start the Customized LDAP settings by specifying the Distinguished Name (DN) of the users that will be accessing the Portal (Figure 6-252).


Figure 6-252 User’s Distinguished Name

a. The User Distinguished Name (DN) Prefix is the prefix seen in the user name in Figure 6-249 on page 474. It is the identifier immediately preceding the user name. In our example, the User DN Prefix is cn.

Enter your prefix in the User DN Prefix field.

b. The User Distinguished Name (DN) Suffix is the remainder of the user’s distinguished name. This is formed by the inverse of the nodes in the tree (Figure 6-249 on page 474) containing the user names. In our tree, the User DN suffix is cn=users, dc=itso, dc=ral,dc=ibm,dc=com as seen in Figure 6-252.

Enter your suffix in the User DN suffix field and click Next.

6. In the next step (Figure 6-253), we enter the Group Distinguished Name, as we did for the User Distinguished Name.


Figure 6-253 Group Distinguished Name

a. The Group Distinguished Name (DN) Prefix is the prefix seen in the group name in Figure 6-249 on page 474. The only group we have defined is wpsadmins. It is the identifier immediately preceding the user name. In our example, the User DN Prefix is cn.

Enter your prefix in the User DN Prefix field.

b. The User Distinguished Name (DN) Suffix is the remainder of the user’s distinguished name. This is formed by the inverse of the nodes in the tree (Figure 6-249 on page 474) containing the user names. In our tree the User DN suffix is cn=users, dc=itso, dc=ral, dc=ibm, dc=com as seen in Figure 6-252. Note that Active Directory stores groups under the users part of the schema as opposed to a separate part of the schema as other LDAP sources do.

Enter your suffix in the User DN suffix field and click Next.

7. Next, enter the object class information for the Active Directory LDAP schema. As seen in Figure 6-254, the defaults are fine for Active Directory.


Figure 6-254 Active Directory object classes

Accept the defaults and click Next.

8. Next, we need to specify the Distinguished Name (DN) of the portal administrator and the administrative groups, as shown in Figure 6-255.


Figure 6-255 Portal administrator and administrative group DN

In 6.8.4, “Configuring Active Directory” on page 461, we configured the WebSphere Portal administrator and the administrators group as wpsadmin and wpsadmins, respectively.

We now use these values in the WebSphere Portal install.

a. Using the ADSI Edit tool as we did in Step 2 on page 471, determine the fully-qualified name of the WebSPhere POrtal administrator. In our example the fully-qualified name is:


Determine the fully-qualified name of your portal administrator and enter it in the Administrator DN field.

b. We next specify the password for the portal administrator. This is the password we specified when we created the administrator’s ID in Active Directory (6.8.4, “Configuring Active Directory” on page 461). When we created the wpsadmin ID for our example, we set the password to wpsadmin.

Enter your administrators password in the Administrator Password field and again in the Confirm password field.


c. Lastly, determine the fully-qualified name of the portal administrator’s group using the ADSI Edit Tool as we have before. This is the group your portal administrator ID belongs to.

Our portal administrators group is wpsadmins so our fully-qualified name is:


Determine the fully-qualified name of your administrators group and enter it in the Administrator group DN field.

Click Next.

9. Next, we specify the Administrative Node name for the application server that is running WebSphere Portal as seen in Figure 6-256.

Figure 6-256 WebSphere Portal Administration node

Your portal administration node can be found in the WebSphere Administrators console. If you are unsure of your administration node name, open the WebSphere Advanced Administrative Console by clicking:

Start -> Programs -> IBM WebSphere ->Application Server 4.0 AE -> Administrator’s Console

and the WebSphere Advanced Administrative Console will start as seen in Figure 6-257.



Your administrative node can be found by locating the WebSphere Portal Application server, WebSphere Portal in our example, and identifying the node running the portal application server. As seen in Figure 6-257, our node name is venus, so we have typed venus in the Node name field in Figure 6-256 on page 481.

Determine your node name and enter it in the Node name field, then click Next.

10.We will now specify the portal URL as we would for installing WebSphere Portal with any LDAP source (Figure 6-258).


Figure 6-258 WebSphere Portal URL configuration

You have completed the portion of the WebSphere Portal install with Active Directory. Continue now through the rest of the WebSphere Portal install with step 18 on page 431.


6.8.6 Testing considerationsAt this point, you can test your portal installation via the Hello World portlet described in the IBM Redbook IBM WebSphere Portal V4.1 Handbook Volume 2, SG24-6920. See the Portlet Development chapter for details.

At the writing of this book, we found that we were unable to define users via WebSphere Portal with Active Directory. The only way to have users recognized by WebSphere Portal, as of the writing of this book, is to define them in Active Directory.

Users can be defined as we defined the wpsbind and wpsadmin IDs in 6.8.4, “Configuring Active Directory” on page 461. If you have many users to add, this would be a fairly tedious job. The alternative is using the LDIF capabilities of Active Directory. For information on using LDIF capabilities of Active Directory to create users, see the documentation at:

http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/bulksteps.asp.


http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/bulksteps.asp



Chapter 7. WebSphere Portal: Linux installation

This chapter provides guidelines and recommendations for installing WebSphere Portal software components in a Linux environment both with and without Setup Manager, the software installer provided with WebSphere Portal and supported by IBM.

The chapter is organized in the following sections:

� WebSphere Portal installation overview� Two tier install with SecureWay using Setup Manager� Verifying product installation� Single tier install with SecureWay using Setup Manager� Single tier install with Domino LDAP not using Setup Manager

7.1 WebSphere Portal installation overview WebSphere Portal provides multiple software components that you can install, and each component has various requirements and prerequisites. You are strongly urged to use the Setup Manager to install these components. Before you install a WebSphere Portal software component, you should also read the information provided in the planning section of the WebSphere Portal V4.1

7


InfoCenter. The InfoCenter contains enhanced installation information related to planning, requirements, and security information.

In addition, the release notes document contains information related to workarounds for known defects and supplemental information on topics that might also be covered in the WebSphere Portal InfoCenter.

You can access the release notes at the following URL:

http://www.ibm.com/software/info1/websphere/solutions/offerings/portallibrary.jsp

WebSphere Portal contains a number of components, such as Lotus QuickPlace, Lotus Sametime, IBM Content Manager, Tivoli Access Manager, and so on. However, as a starting point in an initial sample scenario, the basic components such as IBM WebSphere Portal, IBM WebSphere Personalization, IBM WebSphere Application Server, DB2 Universal Database, and IBM SecureWay Directory in a Red Hat Linux environment are installed.

7.2 Sample two-tier installation with Setup Manager

Note: Before you begin the WebSphere Portal installation, it is important to gather enough information about the specific components you want to install. To help you collect this information into a single document, you may want to use the planning worksheet lists provided in the planning section of the WebSphere Portal InfoCenter. Fill out the table entries with appropriate values for your configuration and keep the worksheet for future reference.

Tip: Before you attempt to install WebSphere Portal, you should be very clear on which version of the product you wish to install. For example, if you install the WebSphere Portal Enable offering and build some portlet capabilities, and then at a later date you want to get WebSphere Portal Extend offering capabilities, there is currently no way to upgrade from the Enable offering to the Extend offering. In this case, you will need to uninstall and re-install, doing some work to export and import your portal and portlets settings.

Note: The install procedures described in this section are for the WebSphere Portal Enable offering only. There are different install procedures for the Extend and Experience offerings. In addition, there are many different install considerations for Extend to properly tie into its collaborative functionality.




In this section, a sample environment is presented. Figure 7-1 illustrates the WebSphere Portal components that will be installed for this sample scenario. For example, Setup Manager will be used to install the LDAP Server and WebSphere Portal in a two-tier runtime environment.

In this scenario, the WebSphere Portal is installed on machine A, and the LDAP Server is installed on a separate system, machine B. Desktop browsers are connected to the WebSphere Portal machine as client devices.

Figure 7-1 WebSphere Portal sample scenario

Software used in this sample scenarioThe following software will be installed:

� Red Hat Linux V7.2.2

� Windows 2000 Server + Service Pack 2

� IBM HTTP Server V1.3.19.1

� IBM DB2 Universal Database V7.2 + Fix Pack 5

� IBM WebSphere Application Server V4.0.1

� IBM WebSphere Portal Extend V4.1.2

� IBM SecureWay Directory V3.2.2

m23x2636.itso.ral.ibm.comPort 80

IBM HTTP Server

WebSphere Application Server V4.0.2

WebSphere Portal V4.1.2

Desktop browser(Netscape, IE)

Linux 7.2 (Red Hat)

LDAPSecureWay

Directory V3.2.2

DB2

m23vnx55.itso.ral.ibm.comPort 389

portlets Linux 7.2 (Red Hat)

HTTP

Chapter 7. WebSphere Portal: Linux installation 487

� Microsoft Internet Explorer V5.5 + Service Pack 1

� Netscape Communicator V4.78

Hardware used in this sample scenarioThe following hardware is used:

� WebSphere Portal

– IBM Netfinity 5100

• 1 GHZ Pentium ||| CPU• 4 GB RAM• 18 GB hard disk• 1 Ethernet (built-in)

� LDAP server

– IBM xSeries Server 230


� Desktop browser

– IBM PC 300PL

• 733 GHZ• 512 MB RAM• 20 GB DASD• 1 IBM Etherjet 100/10

In this scenario, the WebSphere Portal is installed on machine A, and the LDAP Server is installed on a separate system, machine B. When you install the separate system, you must install and start the LDAP Server before you start the WebSphere Portal installation.

7.2.1 Installing the LDAP ServerIn this section, we describe the recommended steps to install your LDAP Server.

1. Start the WebSphere Portal installation

In this step, you invoke the installation shell script. The tasks performed by the script include the verification process to make sure the installation runs with user root and with the correct JDK and JRE levels.


As a sample procedure, use the following command sequence to confirm and start the WebSphere Portal installation program:

# cd# mount /mnt/cdrom# pwd/# ./mnt/cdrom/install.sh

This will result in the following output:

Collecting installation files....Didn’t find java of proper version; will install oneInstalling javaPreparing... ###############################################[100%]1:IBMJava2-SDK #############################################[100%]# WebSphere Portal Server 4.1 Setup Manager starting .......................Copyright (C) IBM 2001-2002Unpacking JAR File ............................................

The WebSphere Portal installation process installs and configures the JDK and JRE. Then, the welcome window is displayed, as shown in Figure 7-2. Click Next.

Note: You need to be sure you issue these commands from the root directory. Use the cd command to get to the root directory. For example, if the command window is in the /mnt/cdrom directory, you will not be able to unmount the CD.


.

Figure 7-2 WebSphere Portal installation program welcome window

2. License agreement

If required, the license agreement window is displayed. Select Accept and then click Next.

3. License key

The installer prompts for the license key. Enter your license key number and click Next.

4. Selection of installation type

WebSphere Portal includes three different types of installation procedures as follows:

– Quick install: the Quick installation uses configuration information stored in a response file to automatically install the WebSphere Portal components. The response file, wporecord.script, is on CD 1. You must modify the response file and store it on your system before you install WebSphere Portal.

Note: There are separate license keys for different WebSphere Portal offerings and the products that can be installed using the Setup Manager vary according to the key provided.


– Standard install: the Standard installation uses configuration information stored in a response file to automatically install the WebSphere Portal components. The response file is generated during the installation process and provides the needed information so you do not need to enter information during the actual installation.

– Advanced install: the Advanced installation lets you select the components you want to install. Selected components can be installed on different systems. If you want to add some components after initial install, this selection will be chosen.

Figure 7-3 Installation type selection

Note: Standard install is recommended for most installations, as shown in Figure 7-3.

Tip: Since you are prompted for a fairly large amount of information during the installation process, it is recommended that you gather your answers before you start the installation. You should also record and keep your answers in your planning worksheet for future reference.


Select Standard Install and then click Next.

5. Load a response file

Since this is a first installation, there is no response file at this time and the check box option is left deselected. However, you can install WebSphere Portal using an existing response file. If you already have a response file, browse the file and select it. All components provided with the WebSphere Portal will automatically install.

After the installation, all the configuration information that you type during the installation will be stored in the response file, /opt/IBMWPO/scripts/wprecord.script. This file can be used for future installations, for example when you install again with the same configuration values. You can also use this response file when you perform another installation with the Quick install option.

Click Next.

6. Selection of components

Choose the WebSphere Portal components by selecting the check boxes of the Portal components you wish to install in a specific machine. In this sample installation, the following components are selected:

– SecureWay Directory

• SecureWay Directory Server

• SecureWay Directory Client

– DB2 Universal Database

• DB2 Universal Database Server

• DB2 Universal Database Client (optional)

• DB2 Universal Database Fix Pack 5

Then, click Next.

7. Remove the old LDAP

If you are going to use IBM SecureWay Directory for your LDAP Directory Server, you must remove any non-IBM versions of LDAP that might have been previously installed in your system.

8. Collect the LDAP suffix

Enter the configuration for the LDAP Server. As illustrated in Figure 7-4, in this sample scenario the following values are used:

– Suffix: dc=ibm,dc=com

– Administrative usr: cn=root


– Administrative password: ***** (enter a proper password)

– TCP/IP port to use: 389

Then, click Next.

Figure 7-4 Collect LDAP suffix information

9. Display the summary

Setup Manager displays a summary list with all the components to be installed. Click Next.

Note: User DN must be specified in the following format: cn= xxx. The user DN is used to bind the LDAP Server. The default LDAP port number is 389.

Note: When you specify the LDAP suffix (such as dc=xx, cn=yy), be sure to enter it in lowercase. Uppercase or mixed cases can cause problems with WebSphere Member Services.


10.Prompt to load the next CD

Setup Manager prompts you to unmount, remove, mount, and insert the CDs of the components to install. Click Unmount, change the disc, click Mount and then click OK.

Figure 7-5 Remove CD

11.Verify the LDAP installation

The following is a recommended procedure to verify the LDAP installation:

a. Log in as root on the system where LDAP server is installed, and start a terminal session.

b. Check the process by entering the command:

# ps -ef |grep slapd

c. If no slapd process is shown, start LDAP and check the process again. For example, use the following command to start LDAP:

# slapd

Tip: If for any reason you are not be able to unmount the CD, issue the unmount command from a terminal session and then continue to install.


7.2.2 WebSphere Portal installation1. Starting the WebSphere Portal installation

Start install.sh using the following commands:

# cd# mount /mnt/cdrom# pwd/# ./mnt/cdrom/install.sh

2. Welcome window

The welcome window is displayed. Click Next.

3. License agreement

If required, the license agreement window is displayed. Click Next.

4. License key

Enter your license key number into the box and click Next.

5. Selection of installation type

Select Standard installation and click Next.

6. Load the response file

There is no existing response file in this sample installation. Click Next.

7. Selection of components

Choose the WebSphere Portal components by selecting the check boxes of the Portal components you wish to install. As shown in Figure 7-6 on page 496, the following components are selected in this sample configuration:

– WebSphere Portal

• Productivity Portlet

• Portal Server

– WebSphere Personalization

• Personalization Server

– WebSphere Application Server Advanced

• WebSphere Application Server Fix Pack 2

• WebSphere Application Server

– IBM HTTP Server


• DB2 Universal Database Server

• DB2 Universal Database Client (optional)


• DB2 Universal Database Fix Pack 5

Figure 7-6 Components and subcomponents selection

8. Check for a previous installation

The WebSphere Portal install process performs a check for any previously installed WebSphere Portal components on the machine.

9. IBM HTTP Server directory

Browse the directory where you want to install IBM HTTP Server. The default location is /opt/IBMHTTPServer.

10.Collect the administration user name for IBM HTTP Server

Enter a user name, group, and password that will be managing IBM HTTP Server on this server (see Figure 7-7 on page 497). Setup Manager

Note: The installation of WebSphere Personalization includes rules-based personalization and a recommendation engine for collaborative filtering. If you also want to develop campaigns using Campaign Manager tools, you will need to install the Personalization Workspace subcomponent. This is a browser-based graphical tool that allows you to define, control, and preview a Web site’s personalization behavior.


automatically creates a user and group that you specified in this step. For example:

– User name: inst1

– Group: inst1g

Figure 7-7 Collecting the administration user name for IBM HTTP Server

11.installation directory

Enter the location where you want to install WebSphere Application Server.

12.Specify a database location

Select the database location. In this scenario (see Figure 7-8 on page 498) a local database is used. Therefore, select No to a remote database in this scenario.


Figure 7-8 Choose database location

13.Choose a database type

Choose a database type. In this scenario, DB2 will be used. Although not shipped with WebSphere Portal, you can also use Oracle Version 8.1.7 as the database software for Portal Server. If you want to use an Oracle database, the installation instructions are included in the InfoCenter.

14.Collect database user information

Enter the database information for WebSphere Application Server. In this sample installation, as shown in Figure 7-9 on page 499, the following values are used:

– Local Database Name: wasdbl

– Local Database Alias Name: wasdb

– Node Name: m23x2636

– Database Server Port: 55555

Note: If you will be using a remote database, you are prompted for local client settings and remote server settings. For further information, refer to the InfoCenter, DB configuration and tips in the Requirements section.


Figure 7-9 Collect database user info

15.Choose application server for personalization server

Choose a WebSphere Application Server to install the Personalization component.

Note: If you need to make sure that the database server port is not in use by another process, issue the following command to verify the port is not in use:

#netstat -a |grep 55555


Figure 7-10 Choose application server

16.Install type selection

Select the install type for this installation. Choose the Typical install mode. The development installation does not have Application Server or third-party authentication proxy to verify proof of identity.

17.Authentication mode

Select the authentication mode for Portal member services. Authentication for the Portal member services function is done using a database and LDAP Directory mode.


Figure 7-11 Authentication mode

18.Security configuration

If this is a first WebSphere Application Server install on your system or global security is not enabled, select Now. Otherwise, select Later if you have already enabled security.

19.LTPA password

Enter the LTPA password for WebSphere Application Server security (see Figure 7-12 on page 502). If you have just installed WebSphere Application Server or if you have not enabled security, you can enter a valid password.

Important: If global security has already been configured, you must provide exactly the same LTPA password that you have entered before, even if security is disabled. Otherwise, you will not be able to start WebSphere Application Server and it will cause an install failure.


Figure 7-12 LTPA password

20.Server configuration

As illustrated in Figure 7-13 on page 503, enter the following WebSphere Portal configuration values:

– Install directory: Default value is /opt/WebSphere/PortalServer.

– Hostname: Portal server’s fully-qualified host name.

– Base URI: Default value is /wps.

– Home page: Default value is /portal.

– Customized page: Default value is /myportal.

– For a connection through a proxy, enter the proxy information.

Note: Setup Manager sets these values based on your previous input. Also, if your network configuration is correct, the host name value will automatically appear in the box. In addition, the host name should be a fully-qualified host name (case sensitive).


Figure 7-13 Server configuration

21.Selection of LDAP server

Next, as shown in Figure 7-14 on page 504, the WebSphere Portal installation process prompts you to enter which LDAP server you want to use for WebSphere Portal. IBM Secureway Directory is the recommended LDAP server but the following servers are also supported:

– IBM SecureWay Directory

– Lotus Domino Application Server

– iPlanet

– Microsoft Active Directory

Select your LDAP server type and fill in the boxes with the name of the LDAP Server, user DN, password, suffix, and LDAP port. You should be aware of the following considerations:

– The user DN must be specified in the following format: cn= xxx. The user DN is used to bind the LDAP Server.

– The default LDAP port number is 389.


Figure 7-14 Selection of LDAP Server

When you enter the LDAP suffix (for example dc=xx, cn=yy), be sure to use lowercase. Using uppercase or mixed case can cause problems with WebSphere Member Services.

22.LDAP configuration

Figure 7-15 on page 505 shows the window where you will enter the LDAP configuration. Setup Manager sets the default values based on your previous input. Therefore, in most cases you can use these values.

In this installation, the following values are used:

– User Object Class: inetOrgPerson

– User DN prefix: uid

Note: If you want to use other LDAP servers for WebSphere Portal, there are known defects described in the Release notes. If you need some workaround, refer to the Release notes in IBM WebSphere Portal InfoCenter.


– User DN suffix: cn=users,dc=ibm,dc=com

– Group Object Class: groupOfUniqueNames

– Group of Member: uniqueMember

– Group DN prefix: cn

– Group DN suffix: cn=groups,dc=ibm,dc=com

– Administration DN: uid=wpsadmin,cn=user,dc=ibm,dc=com

– Administrative group DN: cn=wpsadmins,cn=groups,dc=ibm,dc=com

Figure 7-15 LDAP configuration

23.WebSphere Portal database selection

Select the database type and option for creating the WebSphere Portal database. For a new installation, choose the Create and Initialize a new database (DB2 Only) option.



24.Additional database Information

Figure 7-17 on page 507 shows the panel where you will enter any additional database configuration. You will need to specify an existing database user ID and password. Other related information has been set by Setup Manager.

In this sample installation, the following values are used:

– Database name: wpsdb

– Database user: wasinst

– User password: a proper password

– JDBC database driver: COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource

Important: Do not share the database with Member Services. Setup Manager creates the database for WebSphere Portal, but not for WebSphere Member Services. If you use a remote database, you will need to create and catalog a database.


– JDBC URL prefix: jdbc:db2

– JDBC driver library: /home/db2inst1/sqllib/java12/db2java.zip

Figure 7-17 Additional database information

25.Database option for member services

As illustrated in Figure 7-18 on page 508, for a new installation select Create and Initialize a new database (DB2 Only).

Note: Setup Manager will not create a database user for WebSphere Portal and Member Services. You must use an existing database user name such as wasinst for WebSphere Application Server. Otherwise, you need to install the DB2 database and create the user prior to WebSphere Portal installation.


Figure 7-18 Database option for member services

26.Install type selection

As shown in Figure 7-17 on page 507, enter the DB2 database user ID and password for Member Services.

In this installation, the following values are used:

– Database Name: wmsdb


– User password: *****

– JDBC database driver: COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource

– JDBC URL prefix: jdbc:db2

– JDBC driver library: /home/db2inst1/sqllib/java12/db2java.zip


Figure 7-19 Database configuration for Member Services

27.License Use Management (LUM)

Select the License Use Management install type and fill in the name of the Remote LUM Server.

Licence Use Management (LUM) is an IBM tool for managing and extending software licenses. If you choose to install LUM locally, the LUM installation program installs and configures LUM as a network license server, enrolls the WebSphere Portal product in the LUM database, and checks out the number of licenses corresponding to the number of processors you have online on the local server machine.

For example, as illustrated in Figure 7-20 on page 510, Local License Server is used for this sample installation.


Figure 7-20 License Use Management (LUM)

28.Display summary

In this step, Setup Manager displays a summary list with all the components to be installed. All the selected components, subcomponents, and configuration information are displayed as illustrated in Figure 7-21 on page 511.

In addition, the following actions can be executed:

– Click the Back button to go back to the component selection window to add or remove components from the list, or to change other configuration information.

– When the Next button is clicked, the installation process starts.


Figure 7-21 Display summary

29.Installation progress

As the installation process starts, a progress indicator is displayed that shows the status of the install (see Figure 7-22 on page 512). Any errors or problems that occur during the install process are displayed here. They are logged in the path <wp_root>/install.


Figure 7-22 Installation progress

30.Enable WebSphere Application Server security

During the installation of CD #7, Setup Manager prompts you to log in to the target server and configure the Administrative Role for WebSphere Application Server. The Administrative Role includes stopping and restarting the Web Server that the portal will use.

At this time, do not close the install window but execute the following suggested steps.

Important: When WebSphere Application Server Fix Pack 2 is installed, you must wait until the installation navigation bar reaches 100%. The removal CD window prompts you to change CD #4 for Personalization, but WebSphere Application Server Fix Pack 2 installation is still in progress. Be sure that you wait and then change the CD once WebSphere Application Server Fix Pack 2 is installed completely.


To check that IBM WebSphere Admin Service has been started, perform the following steps:

a. Log in as root.

b. Start the terminal session.

c. Stop IBM HTTP Server by using the following command:

# cd <http_server_install_path>/bin/ # ./apachectl stop

d. Check that the HTTP Server process is stopped by issuing the following command:

# ps -ef |grep httpd

e. Start IBM HTTP Server by entering the following command:

# cd <http_server_install_path>/bin/ <http_server_install_path># ./apachectl start

f. Check that the HTTP Server process is stopped by entering the following command:


The output of this command should list several processes.

g. Check that the IBM WebSphere AdminService has been started by executing the following command:

# ps -ef |grep java

The output of this command should list several processes.

h. If IBM WebSphere AdminService has not been started, issue the following command:

# cd <WAS_HOME>/bin# ./startupServer.sh &

Note: This configuration step is critical. IBM WebSphere AdminService has been stopped and restarted by Setup Manager. Then, you must wait and ensure that the IBM WebSphere AdminService has restarted completely before continuing.

Note: The administrative server is up and running when you can see the following statement in the <WAS_HOME>/logs/tracefile:

A WSVR0023I: Server _adminServer open for e-business


Once you have checked that the IBM WebSphere Admin Service has been restarted, perform the following steps:

a. Start IBM WebSphere Administrative Console by entering the following commands:

# cd <WAS_HOME>/bin# ./adminclient.sh &

b. From the WebSphere Administrative Console main menu, start the Security Center by selecting Console -> Security Center.

c. When the Security Center starts, check that the Enable Security option is selected on the General tab, as shown in Figure 7-23.

Figure 7-23 Enable security

d. Go to the Authentication tab, and make sure that Enable Single Sign On (SSO) is selected, as illustrated in Figure 7-24 on page 515.

Tip: To check the output sent to tracefile, use the following commands:

# cd <WAS_HOME>/logs# tail -f tracefile


Figure 7-24 Authentication

e. Next, go to the Administrative Role tab. In the Role, click the Admin Role and then click Select.

f. Check the option Select users/groups and then type * (the asterisk character) in the box and click Search.

g. In the list of available users and groups, click wpsadmin and wpsbind, and then click the Add button. See Figure 7-25 on page 516.


Figure 7-25 Select Users/Groups

h. Click OK to apply the changes on the Administrative tab.

i. Close the Security Center and IBM WebSphere Administrative Console.

j. Stop and start IBM WebSphere Admin Service as follows:

# cd <WAS_HOME>/bin# wscp.shwscp> Node listwscp> <node_name>wscp> Node stop /Node:<node_name>/wscp> exit

It may take a while for the process to be stopped. You will need to wait until the IBM WebSphere Admin Service has been stopped.

Tip: In order to verify that IBM WebSphere Admin Service has properly stopped, you can verify that the IP listening port is not in use by entering the following command:

# netstat -a |grep 9000

There will be no output generated when the IBM WebSphere Admin Service has really stopped. In some cases, this process may take some time.


k. Once you have checked that the IBM WebSphere Admin Service has stopped, start the IBM WebSphere AdminService by entering the following commands:

# cd <WAS_HOME>/bin# ./startupServer.sh &

l. Check that the IBM WebSphere AdminService has been started by entering the following command:

# ps -ef |grep java

The output of this command should list a number of processes.

m. When the administrative server is up and running, you will see the following statement in the <WAS_HOME>/logs/tracefile:


n. If IBM WebSphere AdminService has not been started, issue the following command:

# cd <WAS_HOME>/bin# ./ startupServer.sh &

o. Start IBM WebSphere Administrative Console by entering the following commands:


p. As shown in Figure 7-26 on page 518, from the left pane of the WebSphere Administrative Console, click WebSphere Administrative Domain -> Nodes -> <node_name> and start WebSphere Portal.

Tip: To see any output sent to the trace file, issue the following commands:



Figure 7-26 WebSphere Administrative Console

q. Close the IBM WebSphere Administrative Console.

31.Deploying portlets

Click OK to continue the installation. This step will take a long time to complete since all portlets will be deployed at this time.

32.Exit install

When you se the message The install Shield Wizard has successfully installed IBM WebSphere Portal..., click Finish.

7.3 Verifying product installationThis section describe how to validate your WebSphere Portal installation. It is important that all components be verified in order to make sure that all

Note: After the installation process, it is recommended that you reboot the WebSphere Portal machine.


components are working correctly. Please note that this section provides verification instructions for all installations described in this chapter.

All the following processes must be started before WebSphere Portal is started. Check all the processes first, and start WebSphere Portal and finally you will be able to access WebSphere Portal pages using a Web browser.

Check each process by using the ps command. The output may list a number of processes depending on the component. For example:

1. Verify the DB2 process by entering the following command:

# ps -ef |grep db2

2. Verify the SecureWay LDAP Server process by entering the following command:


3. Verify the IBM HTTP Server process by entering the following command:

# ps -ef |grep httpd process by the following command:

4. Verify the IBM WebSphere Application process by entering the following command:

# ps -ef |grep java

If any of these processes are not started, perform the verification procedure listed in this section.

DB2 verificationFollow this procedure to verify your DB2 installation:

1. Log in as root, and start a terminal session.

2. Change to user <db2_instance _owner>:

# su - <db2_instance_owner>

For example:

# su - wasinst

3. Check the process:

# ps -ef |grep db2

4. If no DB2 process is shown, start DB2 and check the process again:

# db2start

5. List all DB2 databases for the DB2 instance:

# db2 list db directory


This command should give you the following output:

Database 1 entry : Database alias = WPSDBDatabase alias = XWPSDBNode name = XWPSNODEDatabase drive = 9.00Comment = Directory entry type = IndirectCatalog node number = -1

6. List all DB2 nodes for the DB2 instance:

# db2 list db directory

This command should give you the following output:

Node 1 entry : Node name = M23X2636Comment = Protocol = TCPIPHostname = 127.0.0.1Service name = 55555

7. Test the connectivity to the database:

# db2 connect to <wps_db> user <db2_instance_owner> using <password>

For example:

# db2 connect to wpsdb user wasinst using password

SecureWay LDAP server verificationFollow this procedure to verify your LDAP installation:

1. Log in as root on the system that LDAP server is installed, and start a terminal session.



3. If no slapd process is shown, start LDAP and check the process again:

# slapd

4. Start the Directory Management Tool (DMT). As shown in Figure 2-24, a DMT window will appear.

5. Click Rebind and type your user DN and password that you configured during the installation, in step 21 on page 503.

6. Click Directory tree -> Browse tree. You can browse wpsadmin and wpsbind.


Figure 7-27 Directory Management Tool (DMT) window

Verify the IBM HTTP ServerFollow this procedure to verify your IBM HTTP server installation:




3. If no httpd process is shown, start IBM HTTP Server and check the process again:

# cd <http_server_install_path>/bin/

For example:

# cd /opt/IBMHTTPServer/bin# ./apachectl start


4. Check that the HTTP Server processes is stopped using the following command:


The output should list a number of processes.

5. Check request handling:

Using a Web browser, request the following URL representing the IBM HTTP Server Web root for the home page:

http://<http_server_hostname>/

Figure 7-28 IBM HTTP Server home page verification

IBM WebSphere Application Server verificationFollow this procedure to verify your WebSphere Application Server installation:



# ps -ef |grep java

This output should list a number of processes.


3. If no Java process is shown, start IBM WebSphere AdminService and check the process again:

# cd <WAS_HOME>/bin# ./startupServer.sh

4. Check the output sent to tracefile, using the following commands:


When the administrative server is up and running, you will see the following line in the <WAS_HOME>/logs/tracefile:


5. The WebSphere Application Server installation sets up a default application server (Default Server) in the administrative domain. This application server and its servlet are used to check that the WebSphere Application Server is working correctly.

– Start the WebSphere Administrative Console by issuing the following commands:


As illustrated in Figure 7-29, you will be asked to enter the user identity and password to log in to WebSphere Administrative Console.

Figure 7-29 Login prompt for WebSphere Administrative Console

When global security is not enabled, you will not be asked to enter the user name and password to log in to WebSphere Administrative Console. In order to log in to WebSphere Portal, it is necessary that global security be enabled.


– Click and expand WebSphere Administrative Domain -> Nodes -> <hostname> -> Application Server.

– Select Default Host, and right-click Start, if it is not already started.

– Run the snoop servlet by entering the following URL from a Web browser:

http://<hostname>/servlet/snoop

A page as shown in Figure 7-30 should be displayed after the login prompt.

You enter the same user name and password with the WebSphere Administrative Control login.

Figure 7-30 Snoop window

IBM WebSphere Portal verificationFinally, you can have your portal welcome window by going to:

http://<fully_qualified_host_name>/wps/portal

Note: Be sure the global security is enabled before WebSphere Portal is started.


Click the key icon located at the right corner of window as shown in Figure 7-31 and the login window will appear.

Figure 7-31 IBM WebSphere Portal Welcome page

Enter a user ID (wpsadmin) and password to log in to WebSphere Portal.


Figure 7-32 WebSphere Portal login window

7.3.1 Checking the installation log fileDuring the installation, all actions and outcomes are logged to install the log files in <wps_home>/install/ listed in Table 7-1. These files contain information that can assist you in identifying and analyzing problems.

Table 7-1 Installation log files


ConfigureAppServer.log Contains messages that were generated when the installer attempts to configure the WebSphere Portal Application Server under WebSphere Application Server.

Check this log if the portal installation stops before successful completion.

DbCreate.logDbInit.log WmsDbCreate.logWmsDbInit.logWmsDbPopulate.log

Contains messages that were generated by the scripts used to create and initialize the WebSphere Portal and WebSphere Member Service database instances.

Check these logs for error messages if you have problems logging in as the portal administrator after the portal is installed.


7.4 A sample single-tier installation with Setup Manager

This section provides guidelines to install WebSphere Portal in a single-tier environment. As illustrated in Figure 7-33, the standard WebSphere Portal components are all installed on the same server. Although this is not a recommended scenario for a production server, this configuration can be very useful for development platforms, testing, and proof of concept scenarios.

DeployAdminPortlets.log Contains a message that indicates whether the base administration and customization portlets were successfully deployed. This file is updated whenever you install the portal using the automated installer. The log is also updated whenever you use the portal configuration interface to manually configure a portal.

If you need to determine whether the portal installation was successful, view this file to determine the status of the installation.

RegenerateHTTPServerPlugin.log

During portal installation, if the WebSphere Application Server plug-in cannot be regenerated, an entry is made in this log.

Check this log if problems occur during the portal installation or if you have portal problems after installation.

StartWPS.log Contains messages generated when the portal installer attempts to start the WebSphere Portal Application Server running under WebSphere Application Server.

Check this log if you cannot open the portal after a successful installation.


Note: The install procedures described in this section are for WebSphere Portal Enable offering only.


Figure 7-33 Sample WebSphere Portal single-tier scenario

Software used in this sample scenarioThe following software will be installed:

� Red Hat Linux V7.2.2

� Windows 2000 Server + Service Pack 2

� IBM HTTP Server V1.3.19.1

� IBM DB2 Universal Database V7.2 + Fix Pack 5

� IBM WebSphere Application Server V4.0.1

� IBM WebSphere Portal Extend V4.1.2

� IBM SecureWay Directory V3.2.2

� Microsoft Internet Explorer V5.5 + Service Pack 1

� Netscape Communicator V4.78

Note: Details related to component installation are included in Section 7.2, “Sample two-tier installation with Setup Manager” on page 486.

m23x2636.itso.ral.ibm.comPort 80

IBM HTTP Server

WebSphere Application Server V4.0.2

WebSphere Portal V4.1.2

Desktop browsers

Linux 7.2 (Red Hat)

LDAPSecureWay Directory

V3.2.2

DB2

HTTP


Hardware used in this sample scenarioThe following hardware is used:

� WebSphere Portal and LDAP server

– IBM xSeries Server 230


� Desktop browser

– IBM PC 300PL

• 733 GHZ• 512 MB RAM• 20 GB DASD• 1 IBM Etherjet 100/10

The installation steps are as follows:

1. Launch the installation script for Setup Manager.

2. IBM JRE is automatically installed.

3. Setup Manager is automatically launched.

4. View information and click Next..

5. Read the software license, check Accept, and click Next.

6. Validate the installation key. Enter the product installation key, and click Next.

7. Select the installation type Standard install and click Next.

8. Loading Response file: leave the response file location blank and click Next.

9. Components: select the following components and subcomponents:

– WebSphere Portal

• WebSphere Portal• Portlets

– WebSphere Personalization

• Personalization Server

– WebSphere Application Server

• WebSphere Application Server• WebSphere Application Server Fix Pack 2

– IBM HTTP Server


– IBM SecureWay Directory

• IBM SecureWay Directory Client• IBM SecureWay Directory Server


• DB2 Universal Database Fix Pack 5• DB2 Universal Database Client• DB2 Universal Database Server

10.Enter the administration user name for IBM HTTP Server. For example, enter the following information and click Next:

– User name: inst1– Group: inst1g– Password: <your_password>

11.You will need to remove any previously installed LDAP server. Click Next.

12.Enter the LDAP suffix information. For example, fill in the following information and click Next:

– Suffix: dc=ibm,dc=com– Administrative user: cn=root– Password for administrative user: password– Confirm password: password– TCP/IP port to use: 389

13.Installation directories: enter the WebSphere Application Server installation path and click Next.

14.Choose database location: select No (no remote database) and click Next.

15.Choose database type: select DB2 and click Next.

16.Enter database user information. For example, fill in the following information and click Next.

– Local database user ID: wasinst – Local database group: wasgrp – Local database password: <your_password>

17.Enter database settings. For example, fill in the following information and click Next:

– Local database name: wasdbl – Local database alias name: wasdb – Node name: m23x2636 – Database server port: 5555

18.Choose Application Server: keep the default value WebSphere Portal and click Next.

19.Install type selection: select Typical and click Next.


20.Authentication mode: select Database and LDAP directory mode and click Next.

21.Security configuration: select Now and click Next.

22.LTPA password: Fill in your LTPA password and click Next.

23.Server configuration: fill in your server configuration and click Next.

– Installation directory: /opt/WebSphere/AppServer – hostname: <your hostname> – basic URL: /wps – Home Page: /portal – Customized Page: /myportal – Proxy host: (blank)– Proxy port: (blank)

24.Selection of LDAP server: select SecureWay Directory and fill in the following LDAP configuration and click Next:

– LDAP server: <your local hostname>– DN of user: cn=root– User password: <your_password>– Suffix: dc=ibm, dc=com– TCP/IP port to use: 389

25.LDAP configuration: keep default values in all fields and click Next.

26.Portal Server database selection: select the following items and click Next:.

– Database backend: DB2 Universal Database

– Portal Server Database configuration option

– Create a new database and do initialization

– Share the database

Note: Make sure that the option Share the database is also selected.

27.Additional database configuration: for example, enter the following values and click Next:

– Database name: wpsdb


– User's password: <your_password>

– JDBC database driver: COM.ibm.db2.jdbc.DB2ConnectionPoolDatasource

– JDBC_URL prefix: jdbc:db2

– JDBC driver library: /home/wasint/sqllib/java12/db2java.zip

28.Database option for Member Services: select initialize existing database and click Next.


29.License Use Management: fill in the following items and click Next:

– Installation type for license use: License server

– License Server: <your license hostname>

30.Display Summary: check the list of components and click Next.

31.The installation process will start. When a CD-ROM change is required, unmount and change the CD and then click OK to continue.

32.At the Configuring for Admin Role window, follow the messages in the install window and when you finish the configuration for AdminRole, click OK.

33.At the Finish to install window, click OK and close Setup Manager.

34.Restart WebSphere Application Server Administration Server.

35.Launch WebSphere Application Server administrative console and start the Web application called "WebSphere Portal".

36.Launch a Web browser, then access the portal page by entering:

http://<your host>/wps/portal

7.5 Sample single-tier installation withoutSetup Manager

At this point, it is necessary to emphasize that IBM recommends using the Setup Manager to install any/all products that form a part of the WebSphere Portal bundle. However, this section is targeted at installations where one or more prerequisite products are already installed. In such cases, some of the installed products might need to be configured for WebSphere Portal.

Even though the instructions in this section are meant for a single-tier installation, instructions for a multi-tier installation would be very similar.


Figure 7-34 Single-tier installation roadmap

Figure 7-35 shows the different products that would be installed in this sample scenario.


Figure 7-35 Products installed in this scenario

At this point, we assume that IBM Java Runtime v1.3 has been installed on the Linux server and the JAVA_HOME environment variable has been set. All installation tasks are performed from console(s) started from within an X-Windows manager (KDE).

Also, the Domino Administrator client and Internet Explorer should have been installed on the workstation running Windows 2000.

7.5.1 Installing and configuring DB2

Note: You can verify the installation for any of the products other than Domino by referring to the instructions in 7.4, “A sample single-tier installation with Setup Manager” on page 527.

Note: Detailed instructions on installing the product/fixpack can be found in the release notes accompanying the product/fixpack.


Installing DB2 UDB v7.1 Enterprise Edition

1. Log in as root.

2. Mount disc #2-9, which has IBM DB2 UDB Enterprise Edition for Linux, and start the DB2 setup utility.

Figure 7-36 Start the DB2 setup utility

3. On the main setup window, select the Install option to install the DB2 components.

Figure 7-37 DB2 setup main window

4. Select the option to install DB2 UDB Enterprise Edition.

Note: On the DB2 setup windows, the options can be highlighted using the Tab key and selections can be made by pressing the Enter key.

[root@m23vnx55 root]# mount /mnt/cdrom[root@m23vnx55 root]# cd /mnt/cdrom/db2/linux[root@m23vnx55 root]# ./db2setup


5. Similarly, select the option for DB2 Administration Client.

6. Using the Tab key, move the highlight to the Customize option adjacent to the DB2 UDB Enterprise Edition option and then press the Enter key.

7. Select/de-select the required sub-components and then select OK to continue.

Figure 7-38 Customize selected components

8. Select OK to continue.

9. You will see a summary of the list of components that would be installed. Select Continue. Choose OK when asked to confirm the installation.


Figure 7-39 Installing DB2

10.Once the products are installed, select OK and return to the main window.

11.Now select the Create option. This option will allow you to create a database instance and the administration server.

12.Select the option to Create a DB2 Instance. You will be presented with windows for creating the instance owner (db2inst1) and the owner of the database stored procedures (db2fenc1). Retain the default options and continue by selecting OK.

13.In the DB2 Warehouse Control Database window, you can choose Do not set up DB2 Warehouse Control. Select OK.

Important: By default, the password is set to ibmdb2.


Figure 7-40 Do not set up Warehouse Control DB

14.Then, on the Create Db2 Services window select the option to Create the Administration Server.


Figure 7-41 Create DB2 Administration Server

15.Retain the default settings for the administrative user (db2as) and then select OK. The variable DB2SYSTEM will be set to the machine’s host name. Select OK.


Figure 7-42 Keep default settings for the administration server

16.On the Create DB2 Services window, select OK to proceed.

17.You will be shown a Summary Report of the services to be created. Select Continue. Choose OK when asked to confirm the creation of the services.


Figure 7-43 Services successfully created

18.Select OK on the Status Report window to return to the main DB2 Setup window. Select Close -> OK to exit from the utility.

Installing DB2 Fixpack 51. Stop all DB2 instances and the administrative service before starting the

fixpack installation.

Figure 7-44 Stop DB2 services

2. Mount disk #2-13, and start the fixpack installation.

[root@m23vnx55 root]# su - db2inst1[root@m23vnx55 root]# terminate[root@m23vnx55 root]# db2stop[root@m23vnx55 root]# exit[root@m23vnx55 root]# su - db2as[root@m23vnx55 root]# db2admin stop[root@m23vnx55 root]# exit


Figure 7-45 Start the fixpack installation

3. After the patch is installed successfully, you will need to update all DB2 instances and the administrative service.

Figure 7-46 Update existing services

7.5.2 Installing and configuring Domino LDAP

[root@m23vnx55 root]# /usr/IBMdb2/V7.1/instance/db2iupdt db2inst1[root@m23vnx55 root]# /usr/IBMdb2/V7.1/instance/db2iupdt db2as

Important: These instructions for installing the fixpack are applicable only to a fresh DB2 installation like the one installed above. The release notes accompanying the fixpack specify additional instructions which might be applicable if you are using a prior DB2 installation.

Important: The recommended Java runtime for running Domino is JRE V1.1.8. However, we have used V1.3 for the purpose of this installation without any problems.


Installing Domino Mail Server v5.0.81. Before you start the installation, you must add a system user (notes) and

group.

Figure 7-47 Create the notes user

2. Mount disc #8-2, and start the Domino installation script.

Figure 7-48 Start domino installation

3. Use the Tab key to proceed through the installation windows. Since we are using Domino only as an LDAP server, select Domino Mail Server as the setup type when prompted and then press Tab.

Figure 7-49 Select Setup type as Domino Mail Server

[root@m23vnx55 root]# adduser notes[root@m23vnx55 root]# passwd notesChanging password for user notesNew password:Retype new password:passwd: all authentication tokens updated successfully

[root@m23vnx55 root]# /mnt/cdrom/domino/linux/LINUX/INSTALL


4. Follow the instructions provided on window and retain all the default settings to complete the basic installation.

Figure 7-50 Basic installation completed

5. Update the .bash_profile file for the user notes with the following lines. The file can be located in the user’s home directory (/home/notes).

Figure 7-51 Update .bash_profile for notes

Domino v5.08 does not support Linux kernels versions higher than 2.2.5. The LD_ASSUME_KERNEL environment variable informs Domino that it is running under a compatible version of the kernel.

The LD_LIBRARY_PATH variable has the path to the Java library, libjitc.so. This file is dynamically loaded by the Domino to run its Java agents.

6. Log in as the user notes and start the HTTP setup for Domino.

PATH=$PATH:$HOME/bin:/opt/IBMJava2-13/binLD_LIBRARY_PATH=/opt/IBMJava2-13/jre/binLD_ASSUME_KERNEL=2.2.5

export PATH LD_ASSUME_KERNEL LD_LIBRARY_PATH


Figure 7-52 Start httpsetup

7. Open the URL http://<your.server.com>:8081 in a Web browser to complete Domino setup. On the welcome window, select First Domino Server and then click >>.


Figure 7-53 Setup domino using a Web browser

8. Select the audience for the Domino server. Essentially, select the services that would be provided by the server. For our purpose, we would require LDAP, HTTP (for porlet applications), POP3 and SMTP. Deselect all other options and then click >>.


Figure 7-54 Audience for the Domino server

9. On the Administrative settings page, specify:

– Domain Name as ibmportal.

– Certified ID option as Allow Setup to create a new Certifier ID.

– Certifier Name as ibmportal and the Password.

– Server ID option as Allow Setup to create a new server ID.

– Server Name as the network ID for the server.

– Server Hostname would be the fully-qualified name for the server.

– Administrator’s Name: First as domino and Last as admin.

– Administrator’s ID option as Allow Setup to create a new Administrator ID.

– Password for the Administrator.


Figure 7-55 Admin settings for Domino

Then, click >>.

10.You will be prompted for the ports to be used. Keep the defaults and click Finish.

11.Note the settings on the confirmation window and then click Exit. The setup would then restart the Domino server.

12.Now, access the name and address book for the server using a Web browser (http://<my.server.com>/names.nsf). Select the People view and open the profile for domino admin by double-clicking it.

13.Detach the ID file for domino admin by clicking it and selecting Save to disk. Store the ID file for domino admin and for the certifier (/local/notesdata/cert.id) in a safe place. You will need these ID files for using a Notes Client/Domino Administrator client to administer the Domino server.


14.See 6.7.3, “Domino installation” on page 373 for information on installing a Notes Client on Windows (step #3) and creating the users and groups for WebSphere Portal (step #5).

7.5.3 Installing and configuring IBM HTTP Server

1. Install the RPM files for IBM HTTP Server and the Admin Server from disc #1.

Figure 7-56 Install the RPM files

2. Open the httpd.conf file located in /opt/IBMHTTPServer/conf directory and update the ServerName directive with your machine’s fully-qualified host name.

3. Change the owner of the IBM HTTP daemon (ibmhttpd) to nobody.

Figure 7-57 Change the owner for the HTTP daemon

4. The HTTP Server can be started automatically at boot time. To do this, use a tool such as the SysV Init Editor (ksysv) in KDE. You can drag the ibmhttpd service from the list of Available Services and drop it to the required Runlevel.

Important: Before installing IBM HTTP Server, any existing Web servers should be removed.

[root@m23vnx55 root]# cd /mnt/cdrom/ihs/linux[root@m23vnx55 root]# rpm -i IBM_HTTP_Server-1.3.19-1.rpm[root@m23vnx55 root]# rpm -i IBM_ADMIN_Server-1.3.19-1.rpm

Important: If you want to configure the HTTP server for SSL, you would also need to install the file IBM_SSL_Base-1.3.19-1.rpm. The file IBM_SSL_128-1.3.19-1.rpm would also be required for using 128-bit encryption.

[root@m23vnx55 root]# chown nobody.nobody /etc/rc.d/init.d/ibmhttpd


Figure 7-58 Sysv Init Editor

Save the configuration before you exit.

If there is no X-windows capable workstation, you can add ibmhttpd in the

startup by performing the following steps:

a. Check that there is an executable script file called ibmhttpd located in

/etc/rc.d/init.d. If not, copy this script file over from /opt/IBMHTTPServer/bin.

b. Issue the following commands to create the symbolic links in the various rc.d directories for the appropriate runlevels:

Figure 7-59 Creating symbolic links for ibmhttpd

[root@m23vnx55 root]# cd /etc/rc.d[root@m23vnx55 root]# ln -s init.d/ibmhttpd rc0.d/K15ibmhttpd[root@m23vnx55 root]# ln -s init.d/ibmhttpd rc1.d/K15ibmhttpd[root@m23vnx55 root]# ln -s init.d/ibmhttpd rc2.d/K15ibmhttpd[root@m23vnx55 root]# ln -s init.d/ibmhttpd rc3.d/S85ibmhttpd[root@m23vnx55 root]# ln -s init.d/ibmhttpd rc4.d/S85ibmhttpd[root@m23vnx55 root]# ln -s init.d/ibmhttpd rc5.d/S85ibmhttpd


5. Any other configuration changes such as configuring SSL should be done at this point.

7.5.4 Installing and configuring WebSphere Application ServerIn this section, we begin installing and configuring WebSphere Application Server.

Creating the WebSphere Application Server database in DB2Perform the following instructions to install DB2:

1. Log on to Linux as a DB2 instance owner (db2inst1) and start the DB2 command line console by executing the command db2.

2. Create a database WASDBL and update the application heap size parameter to 256.

Figure 7-60 Create and configure WASDBL

3. Find the TCP/IP port used by the database manager for providing client services. Note the TCP/IP service name set for the SVCENAME parameter.

Figure 7-61 Find the value for SVCENAME parameter

db2 => create db wasdblDB20000I The CREATE DATABASE command completed successfully.

db2 => update db cfg for wasdbl using applheapsz 256DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.DB21026I For most configuration parameters, all applications must disconnect from this database before the changes become effective.

db2 => get dbm cfg

Database Manager Configuration.... SPM log path (SPM_LOG_PATH) =

TCP/IP Service name (SVCENAME) = db2cdb2inst1 APPC Transaction program name (TPNAME) =....


4. Create a TCP/IP node, WASNODE, for applications to connect to the database. Note that the remote service name would be the hostname of your DB2 server.

Figure 7-62 Create the TCP/IP node

5. Create an alias, WASDB, for accessing the database. All client connections through the database should be made only through the alias. This is recommended for performance reasons.

Figure 7-63 Create the DB alias

6. The database is created and configured and now you can quit from the DB2 command line.

Installing WebSphere Application ServerPerform the following instructions to install WebSphere Application Server:

1. Stop the IBM HTTP server and start the WebSphere Application Server install script from disc #3-2.

Figure 7-64 Run WebSphere Application Server installation script

2. The installer starts up and displays a graphical installation window. Click Next.

3. Choose Custom Installation as the installation type and then click Next.

4. From the list of components to be installed, deselect IBM HTTP Server and click Next.

5. From the list of Web server plug-ins to install, select the IBM HTTP Server Plugin. You do not need to install the Apache Web Server plugin. Click Next.

db2 => catalog tcpip node wasnode remote m23vnx55 server db2cdb2inst1DB20000I The CATALOG TCPIP NODE command completed successfully.DB21056W Directory changes may not be effective until the directory cache is refreshed.

db2 => catalog db wasdbl as wasdb at node wasnodeDB20000I The CATALOG DATABASE command completed successfully.DB21056W Directory changes may not be effective until the directory cache is refreshed.

[root@m23vnx55 root]# /etc/init.d/ibmhttpd stop[root@m23vnx55 root]# cd /mnt/cdrom/was/linux[root@m23vnx55 root]# ./install.sh


6. On the application database configuration window, provide the following details for the database (WASDB) created while configuring DB2, then click Next.

– Ensure that the Remote DB option is not selected.

– Specify the Database Name as WASDB.

– The Database User ID is db2inst1 and the Password would be ibmdb2

7. Specify the destination directory for installing WebSphere Application Server, by default, /opt/WebSphere/AppServer. Click Next..

8. Verify the components that would be installed from the summarized list of components and then click Next to start copying the files.

9. Once WebSphere Application Server is successfully installed, click Finish.

Installing WebSphere Application Server Fixpack 2Perform the installation of WebSphere Application Server Fixpack 2:

1. Copy the fixpack files from disc #3-2 to a temporary directory.

Figure 7-65 Copy the fixpack files to a temporary directory

2. Set the following environment variables required for silent installation and start the install.

Figure 7-66 Start silent installation

[root@m23vnx55 root]# mkdir ptf2[root@m23vnx55 root]# cp /mnt/cdrom/was/linux/fixpack2/* ptf2/

Note: Set the IHS_INSTALL variable only if you want to install the fixpack for IBM HTTP Server. Though this is not required, it is recommended.

[root@m23vnx55 root]# export WAS_DIR=/opt/WebSphere/AppServer[root@m23vnx55 root]# export IHS_INSTALL=true[root@m23vnx55 root]# cd ptf2[root@m23vnx55 ptf2]# ./install.sh -silent


Installing the e-FixesPerform the installation of the e-Fixes:

1. Copy all e-Fixes from disc #3-2 to a temporary directory. You will also have to copy eFix PQ60461 to this directory.

Figure 7-67 Copy all efixes to a temporary directory

2. You can either install each eFix individually or execute the following commands:

Figure 7-68 Install all e-Fixes

[root@m23vnx55 root]# mkdir efixes[root@m23vnx55 root]# cp /mnt/cdrom/eFixes/*.jar efixes/

[root@m23vnx55 root]# cd eFixes[root@m23vnx55 eFixes]# find . -name “*.jar” -exec java -jar {} \;


Configuring WebSphere SecurityPerform the configuration of WebSphere Security:

1. Start WebSphere administration server and then the administration client.

Figure 7-69 Start the WebSphere Application Server administration server and the console

2. In the WebSphere Application Server console, click Console -> Security.

3. In the General tab for the security setting, select the Enable Security option.

4. Click the Authentication tab and select Lightweight Third Party Authentication (LTPA) as the Authentication Mechanism.

[root@m23vnx55 root]# /opt/WebSphere/AppServer/bin/adminserver.sh &......[9/25/02 15:49:45:616 EDT] 760e33f1 Server U Version : 4.0.2[9/25/02 15:49:45:619 EDT] 760e33f1 Server U Edition: Advanced Edition for Multiplatforms[9/25/02 15:49:45:620 EDT] 760e33f1 Server U Build date: Tue Dec 18 00:00:00 EST 2001[9/25/02 15:49:45:621 EDT] 760e33f1 Server U Build number: a0150.05[9/25/02 15:49:46:217 EDT] 760e33f1 ORBRas W com.ibm.CORBA.iiop.Util Util P=385748:O=0:CT JORB0012: Pass by reference has been set to: true (NoLocalCopies = true)[9/25/02 15:49:51:002 EDT] 760e33f1 DrAdminServer I WSVR0053I: DrAdmin available on port 32888[9/25/02 15:49:51:016 EDT] 760e33f1 AdminServer I ADMS0008I: Initializing WebSphere Administration server[9/25/02 15:49:54:336 EDT] 760e33f1 ResourceBinde I WSVR0049I: Binding SM_DATASOURCE as jdbc/SM_Datasource[9/25/02 15:49:55:008 EDT] 760e33f1 EJBEngine I WSVR0037I: Starting EJB jar: Name Service[9/25/02 15:49:56:447 EDT] 760e33f1 EJBEngine I WSVR0037I: Starting EJB jar: Secure CosNaming[9/25/02 15:49:56:874 EDT] 760e33f1 EJBEngine I WSVR0037I: Starting EJB jar: Repository[9/25/02 15:50:06:700 EDT] 760e33f1 EJBEngine I WSVR0037I: Starting EJB jar: Tasks[9/25/02 15:50:12:593 EDT] 760e33f1 Server A WSVR0023I: Server __adminServer open for e-business[root@m23vnx55 root]# /opt/WebSphere/AppServer/bin/adminclient.sh


Figure 7-70 WebSphere Application Server Security Authentication settings

5. Select the option to Enable Single Sign On (SSO). For example, if the fully-qualified hostname is m23vnx55.itso.ral.ibm.com, the Domain value would generally be itso.ral.ibm.com.

6. Select LDAP as the user registry.

7. Provide an ID (wpsbind) and a password (wpsbind) for the Security Server.

8. The value for Host will be the fully-qualified host name of our Domino LDAP server.

9. Select the Directory Type as Domino 5.0.

10.The default Port for LDAP is 389. The Base Distinguished Name (DN) for our installation is o=ibmportal.

11.The Bind DN can be any user with manager permissions on the LDAP registry. We use the DN, cn=domino admin,o=ibmportal. Specify the password for the user.

12.Click OK.

13.You will be prompted to create an LTPA password. Set and confirm the password.


14.You now have to specify the users who have administrative privilege for WebSphere Application Server objects. But before you do this, restart WebSphere administration server and start the console.

15.In the WebSphere Application Server console, click Console -> Security.

16.Click the Administrative Role tab.

Figure 7-71 Administrative Role tab in WebSphere Security

17.Select AdminRole from the list and then click Select.

Note: When you start the console this time, you will be prompted for the security server user ID and password.


Figure 7-72 Select users for AdminRole

18.Provide a pattern for searching users in the LDAP registry for example, ‘wps*’. Click Search.

19.You should be shown the users wpsbind and wpsadmin in the list of available users. Add the users to the list of Selected Users/Groups. Click OK.

20.Click OK to close the Security settings window.

7.5.5 Installing and configuring WebSphere PersonalizationIn this section, we will install and configure WebSphere Personalization.

Configuring WebSphere Application Server for Personalization

The WebSphere Portal virtual server is generally created during Portal installation. However, since we want to the personalization engine to run on this server, we need to create the server before we install personalization. Follow the instructions below to setup this server.

1. Ensure that WebSphere administration server has been started and then start the WebSphere Application Server console.


2. Stop any Application Server that might have been started.

3. Right-click Application Servers and then click New.

Installing WebSphere PersonalizationPerform the installation of WebSphere Personalization:

1. Mount disc #4 and start the installation script for WebSphere Personalization. This will start up the graphical installation for Personalization. Click Next.

2. From the list of products to be installed, choose Personalization Server. This is required by WebSphere Portal. Click Next.

Figure 7-73 Select the components that you want to install

3. Provide the user ID and password that you had set for WebSphere security, for example, wpsbind/wpsbind. Click Next.

Note: You might also want to install Personalization Workspace for managing the rules on the Personalization Server. In that case, the installer would show some additional windows. Choose the defaults and install the workspace on the WebSphere Portal virtual application server when prompted.


4. On the database configuration window, specify the database to use for storing personalization information and the user ID and password for that database. This information should be pre-filled from the database settings that we had specified for WebSphere Application Server. Click Next.

5. From the list of virtual application servers, select WebSphere Portal as the application server on which to install the Personalization Server. Then, click Next to start file copying.

6. Once the installation is completed, click Finish.

7.5.6 Installing and configuring WebSphere PortalIn this section, we will install and configure WebSphere Portal.

Creating the Portal database in DB2Perform the following instruction to create the Portal database:

1. Log on to Linux as a DB2 instance owner (db2inst1) and start the DB2 command line console by executing the command db2.

2. Create a database XWPSDB and update the application heap size parameter to 1024.

Figure 7-74 Create and configure XWPSDB

3. Find the TCP/IP port used by the database manager for providing client services. Note the TCP/IP service name set for the SVCENAME parameter.

Important: By default, WebSphere Personalization uses the same database as WebSphere Application Server. However, it is advisable to use a separate database for Personalization, especially, if the applications that would be hosted on the application server are Personalization-intensive. This would allow the administrator to tune and manage each database independently. Also note that this would require creation of the additional database before starting installation.

Note: 7.5.4, “Installing and configuring WebSphere Application Server” on page 551 has detailed window captures for creation of a database.

db2 => create db xwpsdbdb2 => update db cfg for somedb using applheapsz 1024


Figure 7-75 Find the value for SVCENAME parameter

4. Create a TCP/IP node, XWPSNODE, for applications to connect to the database. Note that the remote service name would be the hostname of your DB2 server.

Figure 7-76 Create the TCP/IP node

5. Create an alias, WPSDB, for accessing the database. All client connections through the database should be made only through the alias. This is recommended for performance reasons.

Figure 7-77 Create the DB alias

Installing WebSphere PortalInstall WebSphere Portal using the Setup Manager CD.

db2 => get dbm cfg

Database Manager Configuration.... SPM log path (SPM_LOG_PATH) =

TCP/IP Service name (SVCENAME) = db2cdb2inst1 APPC Transaction program name (TPNAME) =....

db2 => catalog tcpip node xwpsnode remote m23vnx55 server db2cdb2inst1

db2 => catalog db xwpsdb as wpsdb at node xwpsnode

Note: Manual installation of WebSphere Portal with Domino as the LDAP directory would require you to update the Java runtime (rt.jar) used by WebSphere Application Server during installation. The instructions for doing this can be found in 5.3.9, “Installing WebSphere Portal” on page 238. The manual installation procedure for the Portal on Linux is similar to the procedure provided in 6.7.12, “Install WebSphere Portal using Domino LDAP” on page 417.


Complete the following instructions:

1. Log on to Linux as root and start the WebSphere Portal installer from disc #1.

Figure 7-78 Start the Portal installer

2. A graphical welcome window is displayed. Click Next.

3. We have already installed all the pre-requisites for WebSphere Portal. Click Next.

4. Read through the Program License Agreement. Select Accept and then click Next.

5. Specify the Portal Extend license key and then click Next.

6. Choose Advanced Installation as the install type. Click Next.

7. From the list of components/products, select only WebSphere Portal and its sub-components for installation. Clear the check marks against all other components. Then, click Next.

Figure 7-79 Select the components to install

[root@m23vnx55 root]# /mnt/cdrom/install.sh


8. The installer checks for the products that have been previously installed and then displays a list of products that would or would not be installed. Click Next.

9. We have already enabled WebSphere Application Server security. So, choose Yes on the security window and click Next.

10.You will now be asked to provide the user ID and password for WebSphere Application Server security server. Specify this as wpsbind/wpsbind and click Next.

Figure 7-80 Specify the user ID and password for WebSphere Application Server security

11.Choose Typical for the Portal install type. A development install does not provide support for LDAP/custom user registries. Click Next.

12.When asked for the Authentication mode, choose Database and LDAP Directory mode. Then, click Next.

13.Provide the Server configuration information for the Portal. You will need to provide the fully-qualified hostname for the server. It is recommended that you retain the defaults for the other values. Click Next.


Figure 7-81 Basic portal server information

14.From the list of LDAP servers supported by WebSphere Portal, choose Lotus Domino Application Server as our LDAP server.


Figure 7-82 Domino LDAP configuration

15.Specify the fully-qualified hostname of the LDAP server.

16.The user specified in User DN field should be a user who has Manager access to the LDAP registry. We used domino admin as the user. Specify the password for the user.

17.The Suffix is the suffix for the LDAP server. Notice that in our Domino server document, the server is listed as <servername>/ibmportal. Domino uses the organization name and country as the suffix. Since we did not specify a country when installing Domino, the suffix is only o=ibmportal. For example, if the country was set to US during Domino setup, the suffix would be o=ibmportal,c=US.

18.The default port for the LDAP registry is 389. Click Next..

19.On the LDAP configuration window, confirm that the Administrator DN is cn=wpsadmin,o=ibmportal and the Administrative group DN is cn=wpsadmins. Click Next.

Note: Domino does not use a suffix for groups by default.


Figure 7-83 Confirm the LDAP configuration

20.Select DB2 UDB as the database to use. Choose Initialize an existing Database in the Portal database configuration options. Also, choose the option to Share the database with Member Services. Click Next.


Figure 7-84 Select the database for portal

21.In the Additional Database Configuration window, specify the DB2 instance (db2inst1) and the database (wpsdb) to use for portal. Specify a valid user ID and password for accessing the DB2 instance (db2inst1/ibmdb2).

22.Since we had chosen to share the portal database with member services, the installer does not provide the option to create a database for member services. Choose the option to Initialize an existing database and then click Next.

23.On the License Use Management (LUM) window, select the option for a Local LUM server. Specify the fully-qualified hostname for the local machine and then click Next.


Figure 7-85 LUM options

24.The installer will now check for any previous database installations. Click Next.

25.On the Server Setup window for Lotus Collaborative Places and Components, provide the fully-qualified hostname of our Domino server. Clear the check marks for the Sametime/Quickplace options. Click Next.


Figure 7-86 Server setup for Lotus collaboration

26.On the Collaborative Places Configuration window, provide the fully-qualified hostname of our Domino server. Clear the check marks for Lotus Discovery Server, Sametime and Quickplace options. Click Next to start installing the files for WebSphere Portal.

Note: We discuss the WebSphere Portal configuration for Lotus Collaboration in the IBM Redbook, IBM WebSphere Portal V4.1 Handbook Volume 3, SG24-6921.


Figure 7-87 Collaborative Places Configuration

27.The installer will prompt for changing to disc #13. Click Unmount, change to disc #13, click Mount and then click OK to continue.

28.After the installer has installed around 65% of the Portal enterprise applications, it will show a window as below. Simply restart IBM HTTP Server using the SysV-Init Editor. Open the WebSphere Application Server console and ensure that the virtual Application Server, WebSphere Portal, has been started and then click OK.

Note: We have already configured WebSphere Application Server security and specified the users with Admin Role, so we do not need to configure anything on WebSphere Application Server.


Figure 7-88 Restart the HTTP server

29.The installer then installs the productivity portlets and Lotus collaborative portlets. Click OK to return to the installer.


Figure 7-89 Installed successfully

30.You can view the log files that have been generated and then click Finish.


Chapter 8. WebSphere Portal: AIX installation

This chapter provides guidelines, recommendations and tips for installing WebSphere Portal software in an AIX environment. As installations in this field will vary greatly, we have focused on two approaches.

� One describes the installation using WebSphere Portal Setup Manager. This is the only IBM recommended installation approach and should be sufficient in less complex scenarios, and therefore in the majority of scenarios.

� In the other approach, every single component gets installed individually in a silent mode, that is, without using a graphical display. This description is intended to be a helping hand for administrators in more complex scenarios.

The goal of this description is to provide as much background for the installation values as possible. Even though you may not find the exact mirror of your setup in one of the scenarios, the description should help to work through common problems.

8.1 Pre-installation tasksBefore you start with either installation approach, make sure you have read and understood the AIX dependent and operating system independent parts of Chapter 3, “WebSphere Portal prerequisites and planning” on page 19.

8


8.1.1 Installation planning worksheetWe highly recommend that you develop a planning worksheet specific to your topology setup before installation. Based on 3.6, “Planning: general considerations” on page 50, we created a proper planning worksheet for this installation in Table 8-1. Such a table can also be a good reference installation description for after-installation usage.

Furthermore, it will give you an overview of the values that are created on your system and should be therefore very valuable to your AIX system administrator.

Table 8-1 Planning worksheet for the installation in this chapter

Note: The values that do not apply for our installation have been left out. Unfortunately, the sheet in the InfoCenter appears misleading, so make sure you use the description in 3.6.4, “Installation planning worksheets” on page 60.

Target data Our value Description

IBM HTTP Server installation directory

/usr/HTTPServer You will not be asked for this value and you cannot change it.

IBM HTTP Server user name

httpd User that gets created and will own the httpd process (see 4.4.1, “IBM HTTP Server” on page 94).

Group of IBM HTTP Server user

httpd Group that gets created (see 4.4.1, “IBM HTTP Server” on page 94).

Password of IBM HTTP Server user

httpd See 8.5.7, “Change password for the user httpd” on page 673 on how to change this password after installation.

IBM SecureWay Installation directory

/usr/ldap It is not possible to change this value during installation.

SecureWay Suffix ou=itso,o=ibm,c=us See “LDAP” on page 64 to get more background information about the Suffix.

SecureWay Administrative User

cn=ldapadmin The root user inside SecureWay. It is possible and save to change this value (see Figure 8-12 on page 596), but its value must always start with cn=


SecureWay Password for Administrative User

ldapadmin See 8.5.5, “Change password for the users ldapdb2, ldap” on page 673 on how to change this password after installation.

WebSphere Application Server Installation directory

/usr/WebSphere/AppServer

It is possible and safe to change this location during setup.

WebSphere Application Server node name

m10df55f You will not be asked to change this value. By default, the value is equal to your hostname.

LTPA password ltpa See 8.5.8, “Change LTPA password of Application Server Security” on page 674 on how to change this password after installation.

WebSphere Application Server: Local Database user ID

wasuser This value applies to both the Unix user and the DB2 instance name.

WebSphere Application Server: Local Database password

wasuser This value applies to both the Unix user and the DB2 instance name. See 8.5.3, “Change password for the DB2 user wasuser” on page 664 on how to change this password after installation.

WebSphere Application Server: Local Database name

wasdbl Name of the DB2 database that gets created. It is possible and safe to change this value (see Figure 8-7 on page 590).

WebSphere Application Server: Local Database Alias name

wasdb Name of the alias that WebSphere Application Server uses to access its database. It is possible and safe to change this value (see Figure 8-7 on page 590).

WebSphere Application Server: Database Node Name

LOOPBACK DB2 node name used to connect from the database alias to the physical database. It is possible and safe to change this value. Valid entries include IP addresses, hostnames and fully-qualified hostnames. LOOPBACK is an internal alias for the value 127.0.0.1.


Chapter 8. WebSphere Portal: AIX installation 575

WebSphere Application Server: Database Server Port

55555 The port DB2 uses to connect from the DB2 client to the DB2 Server. It is possible and safe to change this value (see Figure 8-7 on page 590).

Personalization: Application Server Name

WebSphere Portal The Application to which Personalization Server gets installed. Do not change this value (see Figure 8-8 on page 592).

Portal: Install Directory

/usr/WebSphere/PortalServer

It is possible and safe to change this location during setup.

Portal: Hostname m10df55f.itso.ral.ibm.com

This value must be the fully-qualified hostname of your server (see 3.6.2, “Network requirements” on page 59).

Portal: Base URI /wps The prefix value of the Portal Application that will appear in the URL right after the hostname. It is possible and safe to change this value (see Figure 8-11 on page 595).

Portal: Home page /portal This is the shortcut to the Portal’s first page which would then be in our example, hostname/wps/portal. It is possible and save to change this value (see Figure 8-11 on page 595).

Portal: Customized page

/myportal This is the shortcut to the Portal’s secured pages which would then be in our example, hostname/wps/myportal. If you are not already authorized, you will be redirected to the login page. It is possible and safe to change this value (see Figure 8-11 on page 595).

Portal: Proxy host A proxy host that allows connections to another network. It is possible to change this value at any time.

Portal: Proxy port The appropriate port for the above declared proxy host. It is possible to change this value at any time.

Portal: LDAP server

m10df55f.itso.ral.ibm.com

This value must be the fully-qualified hostname of your server (see 3.6.2, “Network requirements” on page 59).



Make sure you check the section “LDAP” on page 64 to gather information regarding the setup of your LDAP structure.

The following list gives a summary of items that get created by the Setup Manager:

� Unix users that are created:

– httpd– wasuser– ldap– ldapdb2– db2fenc1– db2inst1– db2as

Portal: User DN cn=ldapadmin Must equal the value as defined above in “SecureWay Administrative User”.

Portal: User password

ldapadmin Must equal the value as defined in this table at “SecureWay Password for Administrative User”.

Portal: Suffix ou=itso,o=ibm,c=us Must equal the value as defined in this table at “SecureWay Suffix”.

Portal: LDAP port number

389 The port WebSphere Portal will expect the LDAP Server. Do not change this value during installation.

Portal: Database name

wpsdb Name of the database alias that gets created to connect to a remote database or the XWPSDB database. It is possible and safe to change this value (see Figure 8-15 on page 599).

Portal: Database user

wasuser This user will not be created by the Setup Manager. Therefore it must be a pre-existing DB2 user or a DB2 user that gets created by other parts of the installer. A safe value is to use the same user as defined in “WebSphere Application Server: Local Database user ID” in this table.

Portal: Database user password

wasuser Make sure to enter a correct password here, as it is for an already existing user.



� Unix groups that are created:

– httpd– wasgrp– ldap– db2fadm1– db2iadm1– db2asgrp– dbsysadm

� DB2 databases that are created:

– LDAPDB2: used to store LDAP directory– WASDBL: used by WebSphere Application Server– XWPSDB: used by WebSphere Portal and WebSphere Member Service– DWCNTRL: not used

� TCP/IP ports in use:

– 80 (IBM HTTP Server)– 389 (SecureWay Directory Server)– 900 (WebSphere Application Server Administrative Server)– 8008 (IBM HTTP Administration Server)– 90xx (WebSphere Application Server)– 55555 (DB2 Universal Database Server)

8.1.2 Consideration for LDAPThis section will certainly not be enough to acquire background about the IBM SecureWay Directory and LDAP directories in general. Please refer to documentation describing LDAP or the Redbooks:

� Using LDAP for Directory Integration, SG24-6163

� Understanding LDAP, SG24-4986

Depending on the type of installation, WebSphere Portal core component requires a ready-to-use Lightweight Directory Access Protocol (LDAP) structure with at least two users inserted. We will show a way of inserting these users. “LDAP” on page 64 discusses the structure that WebSphere Portal assumes if you use the default values. Make sure you read and understand this section, especially if you intend to change the default structure.

Creation of a Lightweight Directory Interchange Format (LDIF) fileAll major LDAP Server products support dumping the structure in its content to a plain text file supporting the LDIF file format. Such an LDIF file can, on the other hand, be used to fill an LDAP Server with a proper structure.


WebSphere Portal comes with two example LDIF files, one ready to fill into a SecureWay Directory Server, another targeting iPlanet Directory.

To use the file for your purposes, you have to edit it manually. Compare the one that comes on the CD (for example, CD # 13, /wps2/WPSconfig.ldif) with the one that is printed below and that we use for the installation.

Example 8-1 LDIF file for SecureWay Directory

version: 1

# NOTE: make sure, you use the correct objectclass types!# for o= use organization# for ou= use organizationalUnit# for dc= use domainController# Do not just copy and paste this! First think about a good structure and# then change the file that comes with the product.

dn: ou=itso,o=ibm,c=usobjectclass: oranizationalUnitobjectclass: top# Add lines according to this scheme that correspond to your suffixou: itso,o=ibm,c=usou: itso

dn: cn=users,ou=itso,o=ibm,c=usobjectclass: containerobjectclass: topcn: users

dn: cn=groups,ou=itso,o=ibm,c=usobjectclass: topobjectclass: containercn: groups

dn: uid=wpsadmin,cn=users,ou=itso,o=ibm,c=usobjectclass: organizationalPersonobjectclass: personobjectclass: topobjectclass: inetOrgPersonuid: wpsadminuserpassword: {iMASK}>16LcsthnrncZ0VioPS+CLJI+WYQiLJ7QNwP1ymxBnPPfdak794823fyV 9dHh8wk76EcRs9NSrNN9PIKGpqNSs/gnaMbPvTkAp9BJ9uqudufBMcUdpjGBdjpcpe/Ai8dOe3TM anELn9qKYXdyzan/rE/ksPyMvQ1Dv9<sn: admingivenName: wpscn: wps admin


dn: uid=wpsbind,cn=users,ou=itso,o=ibm,c=usobjectclass: topobjectclass: personobjectclass: organizationalPersonobjectclass: inetOrgPersonuid: wpsbinduserpassword: {iMASK}>1As640BgqGSOYRnxNxa/VZbxYOH29yF9zM+ZqI4C53TGRvCko5DnYEH0 8PC7jFc5i1O0nV1Fm54FE2Ftlc/1n3z4tUfNGYrklliuwksTTeU/xZM00YfLQe+y7km8QsEWoZFp qrtsysnpjYvYeVodYZSD6i15iKL6H4<sn: bindgivenName: wpscn: wps bind

dn: cn=wpsadmins,cn=groups,ou=itso,o=ibm,c=usobjectclass: groupOfUniqueNamesobjectclass: topuniquemember: uid=wpsadmin,cn=users,ou=itso,o=ibm,c=uscn: wpsadmins

8.2 WebSphere Portal installation using Setup Manager

This section is intended to give a helping hand in successfully stepping through a WebSphere Portal installation. Intentionally, we have used values that seem to be problematic from practical customer experiences, thereby enhancing your experience of a successful installation.

We will use the Extend Edition of WebSphere Portal, but installing the Collaboration Features will not be covered in this chapter. Some windows might differ from the Enable or Experience Edition, but not the installation process itself.

8.2.1 Information collection for WebSphere Portal installationBefore starting WebSphere Portal Setup Manager, make sure you have read both 3.4, “WebSphere Portal for AIX prerequisites” on page 39 and 8.1, “Pre-installation tasks” on page 573.

Note: Usage of WebSphere Portal Setup Manager is in most cases Operating System independent. Refer to Chapter 4, “WebSphere Portal Setup Manager” on page 77 for a detailed description of all Setup Manager options.


1. Insert WebSphere Portal Disk 1 into the CD-ROM drive of the machine as it includes the Setup Manager. Open a terminal as root user, and start the Setup Manager with commands as listed below:

# cd# iduid=0(root) gid=0(system)# mount /cdrom# /cdrom/install.sh

If the latest maintenance level is not installed, Setup Manager will now install an update of the JDK.

2. A Welcome window is displayed, as shown in Figure 8-1.

Figure 8-1 WebSphere Portal Setup Manager welcome window

This window will inform you about prerequisites for the product. Click Next to continue.

Note: Do not start the install.sh script from the directory where it is located. The Setup Manager will not be able to unmount the directory if it is in use, for example, by the Shell.


3. The next window will show the Program License Agreement. Click Accept and then click Next.

4. The following window will ask you for your WebSphere Portal Installation Key. Enter the Key and click Next. You will see a window similar to Figure 8-2.

Figure 8-2 Installation type selection

Note: The Installation Key implies that the edition that you have of WebSphere Portal, which is dependent on your Installation Key Setup Manager, will select the correct option for the edition you purchased.

The Installation Key is included with your set of CD-ROMs. If you cannot find your Installation Key, ask your IBM representative for assistance.

We will use a key that starts the Installation of WebSphere Portal Extend Edition. Other installations will give you more or fewer options.


5. Figure 8-2 allows you to select the installation options. As you can see in the window, WebSphere Portal allows three types of installation procedures. Read 4.3, “Determining the type of install” on page 83 to get a detailed description on the available options.

We recommend the Standard procedure. Therefore, select Standard Install and then click Next.

6. You will be asked for the location of the Response File. In our example, we did not create a Response File and left the field blank. Click Next.

Tip: Setup Manager will create a Response File during this installation procedure and place it in /usr/IBMWPO/scripts/wprecord.script.

This file might be used with the Quick Install option on the same machine or with slight changes on a similar machine.


Figure 8-3 Selecting components


7. You will see a window similar to Figure 8-3, where you are asked to select the components that should be installed. By selecting components, Setup Manager will recognize automatically which prerequisite packages it will require.

Therefore, it is enough for our sample installation to select only the following two packages:

– Select WebSphere Portal

– Select SecureWay Directory

As we will not cover the installation of the Collaboration Feature in this chapter, we explicitly deselect the following checkbox:

– Deselect Lotus Collaborative Places and Components.

8. Click Next to start the prerequisite information collection of the WebSphere Portal Setup Manager.

9. Prerequisite information collection: in this step of the process, Setup Manager will check for previous installations of WebSphere Portal. You will be informed about dependencies and whether Setup Manager can resolve it without help.

It will also check for missing prerequisites of the operating system and finally check for problems with the License Use Management.

If you are missing obvious prerequisites, Setup Manager will tell you about it in the displayed information window and ask you to cancel the installation, solve the problem, and then start the installation again.

If Setup Manager does not explicitly tell you differently, click Next to start the configuration of the individual products inside WebSphere Portal Setup Manager.

8.2.2 IBM HTTP Server configurationIn the window shown in Figure 8-4, insert the user information of the user that will own the httpd process. Setup Manager will create the user and group that you

Note: After clicking one of the checkboxes, the Java GUI will need some time to refresh.

We will install SecureWay Directory Server on the same machine as WebSphere Portal. However, WebSphere Portal InfoCenter (http://www.ibm.com/software/webservers/portal/library/enable/InfoCenter/) might still state in the Release Notes that SecureWay Directory and WebSphere Portal being on the same machine is not supported.



specify on the AIX platform for you. In our example, we use httpd for both user and group.

We recommend that you change the user’s system rights after installation to fit your security guidelines.

The issued user name and password combination will also be used for the IBM Administration Server of the IBM HTTP Server that will run by default on port 8008.

Figure 8-4 Collecting Admin Username for IBM HTTP Server

Click Next to configure the installation information of SecureWay Directory.

8.2.3 IBM SecureWay Directory Server configurationYou will see a window as shown in Figure 8-5, to configure the IBM SecureWay Directory Server. All fields require values, as shown in the following steps.


Figure 8-5 Collect LDAP Suffix Information

1. Enter the Suffix for your IBM Secureway configuration.

The Suffix you are requested to insert in the first field of Figure 8-5 is a branch that WebSphere Portal will use to add its information.

Inside that branch WebSphere Portal will by default add two sub-branches. They are:

cn=users Here, it will later add the users like leaves.

cn=groups Here, it will expect the groups to which the users belong.

You can change this behavior in one of the following configuration windows (see Figure 8-13 on page 597).

Note: If the Suffix you enter does not solely consist of domain controller branches (dc=blabla,dc=bla), Setup Manager will very likely fail to insert the required users into SecureWay Directory. Intentionally, we use a difficult setup to show how to bypass potential problems.


For this sample installation we will use as our Suffix, ou=itso,o=ibm,c=us. In the Suffix (example: dc=yourco,dc=com) field, enter ou=itso,o=ibm,c=us.

2. The administrative user is the root user inside SecureWay Directory. This user will not appear in the AIX user environment.

We use the name ldapadmin for the LDAP Administrative user. In the Administrative user field, enter cn=ldapadmin.

For system administrators: Two AIX users will be created by the SecureWay installation.

ldap This will be the process owner of the SecureWay Directory Server daemon process (slapd).

ldapdb2 This will also appear as a DB2 instance and will therefore own the appropriate DB2 processes. Its task is to manage the database LDAPDB2 that gets created during SecureWay Directory installation.

These two values are hard-coded and cannot be changed if using WebSphere Portal Setup Manager. Consider installing SecureWay Directory manually if you feel you cannot keep these values.

It is recommended that you change the user’s rights after installation to fit your security guidelines.

3. In the Password for administrative user and Confirm password fields, enter a password for your directory server. You may use any character set, excluding an opening curly bracket ({) at the beginning and white spaces in general.

4. In the TCP/IP port to use field, leave the default value 389.

Port 389 is the default port to use for LDAP directory servers.

Click Next to provide information for the WebSphere Application Server.

8.2.4 WebSphere Application Server configurationTo configure WebSphere Application Server with WebSphere Portal Setup Manager, you must complete or change the default values of several windows.

1. The first window asks for the WebSphere Application Server home directory. Accept the default value for AIX Systems, /usr/WebSphere/AppServer and click Next.

Important: Do not forget to have cn= in front of the username.


2. In the following window, you have to select whether your DB2 Server installation is on a remote host. Choose No to have all components installed on a single machine and click Next to continue.

A detailed description of the choices can be found at the description of Figure 4-23 on page 103.

3. The next Window asks you to choose the Database Type. Oracle Databases will not be covered in this book. Choose DB2 and click Next.

Figure 8-6 Collecting information about WebSphere Application Server database owner

4. In Figure 8-6, you are asked to insert the DB2 Instance owner to be used for WebSphere Application Server.

– In the Local Database User ID field, type wasuser.

This user will be created in the AIX environment by the Setup Manager. It will also appear as DB2 instance and will therefore own the appropriate DB2 processes. Its task is to manage the database for WebSphere Application Server and we also use it to manage and own the WebSphere Portal databases which will be configured on one of the later windows.


– In the Local Database Group field, type wasgrp.

This AIX environment group will be created by Setup Manager and the above user will be assigned to it. So it is really a Unix group.

– In the Local Database Password field, enter a password.

This password is used for both the AIX user wasuser and the DB2 Instance owner. Therefore, you also need this password to connect to the databases that will be created.

We recommend that you change the user’s permissions after installation to fit your security guidelines.

Click Next to switch to the Collection of the database information window.

Figure 8-7 Collect information for the WebSphere Application Server database

5. Complete the following fields as shown in Figure 8-7:

– Local Database Name: type wasdbl.

The name of the database as it will be created by the Setup Manager.


– Local Database Alias Name: type wasdb.

The name of the alias that will be used to access the database. This name must differ from the above value.

– Node Name: leave the default value LOOPBACK.

The DB2 name that indicates where to find the physical database. Since the database and the database alias exist on the same machine, LOOPBACK is a good name. It indicates that the database is connected via the loopback device.

– Database Server Port: leave the default value 55555.

This is the port that the DB2 Server will listen on. It is used for the connection between the database alias and the database itself. Usually, this is configured with a Unix service name, but we recommend that you add a port number. We recommend that you add this port to your /etc/services file after installation. This port must not be in use by any other application!

Click Next to move to the Personalization Server Setup information.

8.2.5 Personalization Server configurationShown in Figure 8-8 is the window for choosing the Application Server Name to which Personalization Server should be installed.

Important: The names you specify can only contain one to eight characters! To avoid potential problems, do not use special characters such as @, #, and $.

Important: Do not change the default value! Leave it as WebSphere Portal.


Figure 8-8 Configuration of WebSphere Personalization Server

Click Next to move to the Portal Server information gathering section.

8.2.6 WebSphere Portal configurationTo configure WebSphere Application Server with WebSphere Portal Setup Manager, you have to complete or change the default values of several windows. To do so, complete the following steps:

1. The first window prompts you for the type of installation. Choose Typical and click Next to proceed.

The Development Install Type is used by a developer who wants to set up his PC for Portlet development purposes only. As we rarely find such a situation in an AIX environment, this install type will not be used in our configuration.


Figure 8-9 Select the type of user registry

2. Figure 8-9 shows the window that prompts you to select the Authentication Mode. For our sample installation, we select Database and LDAP Directory mode. Click Next to continue to the Security configuration.



Figure 8-10 WebSphere Application Server Security Configuration

3. Figure 8-10 shows the window that lets you choose whether or not to enable WebSphere Application Server Security during the installation.

Please note that WebSphere Application Server Security has nothing to do with SSL or https. WebSphere Application Server supports securing certain resources, which means that those cannot be accessed without the right permission. This capability is used by WebSphere Portal to distinguish between public resources and resources (for example Portlets) that can only be accessed by specific users.

If you do not have WebSphere Application Server already installed and have not enabled Security in that installation, then choose Now. Only if you had WebSphere Application Server already installed and at this installation Security is already enabled, would you choose Later.

We did not have any WebSphere product on our system prior to installation, therefore, we choose Now and click Next.

4. The next window will ask you for the LTPA password. Type in a proper password and make sure you remember it!


Click Next to move to the Portal Server configuration window.

Figure 8-11 Portal Server configuration

5. As shown in Figure 8-11, Setup Manager will prompt you for configuration settings related to the Portal application itself. For our example installation, we used the values shown in Figure 8-11.


Click Next to move to the LDAP Server Access configuration.

Important: If you use a pre-existing WebSphere Application Server and it had global security configured, you must provide exactly the same LTPA password that you entered before. This applies also if security is currently disabled. Otherwise, you will not be able to start WebSphere Application Server and it will cause an install failure.


Figure 8-12 LDAP Server Access information

6. Figure 8-12 shows that Setup Manager allows you choose among various LDAP Directory Server implementations.

As we intend to install SecureWay Directory using the Setup Manager, select the radio button SecureWay Directory and complete the following fields with appropriate values:

– LDAP Server: type m10df55f.itso.ral.ibm.com

The fully-qualified hostname of the LDAP Server. Installation will fail if you only use the short name, such as localhost. So we use m10df55f.itso.ral.ibm.com

– User DN: type cn=ldapadmin

This is the distinguished name of the LDAP Administrative User (see the description in “LDAP” on page 64 about the LDAP Administrative User and 8.2.3, “IBM SecureWay Directory Server configuration” on page 586, where we defined this user). The default value is the one used during SecureWay Directory Server configuration, which is in our case cn=ldapadmin. If you need to change this value, remember not to put in just


the user name but the distinguished name of the user. Another example would be cn=Manager,dc=ibm,dc=com.

– User password: enter password.

The proper password for the LDAP Administrative User.

– Suffix: type ou=itso,o=ibm,c=us

The base tree in which WebSphere Portal will add its branches. See 8.2.3, “IBM SecureWay Directory Server configuration” on page 586, where we defined this Suffix.

– LDAP port number: use the default value.

Leave this value as 389, as it is the default port for LDAP to communicate unencrypted.

Click Next to go to the Portal LDAP configuration.

Figure 8-13 WebSphere Portal related LDAP configuration options

7. Figure 8-13 shows the window for an extended configuration of the LDAP settings to use with WebSphere Portal.


Make sure you have read and understood “LDAP” on page 64 before changing any values on this window. If you do not have a reason to change these values, the defaults will be fine.

Click Next to move to the Portal Server Database Selection.

Figure 8-14 Portal Server database selection

8. You have to select three options via radio buttons. We used the options shown in Figure 8-14. A detailed description of the choices can be found at the description of Figure 4-36 on page 120.

Click Next to insert the WebSphere Portal Database Configuration information.

Note: If you are unsure of which database setup might best fit your installation, consult your AIX and database administrator.


Figure 8-15 Portal Server database configuration

9. The Additional Database Configuration window lets you insert important information for WebSphere Portal to access its database. For our example installation, we chose the parameters displayed in Figure 8-15.

A detailed description of the choices can be found in the description of Figure 4-37 on page 122

Click Next to go to the database option for Member Services.


Figure 8-16 Database option for member service

10.On the Database option for WebSphere Member Services window, we are presented with two choices as shown in Figure 8-16. Select Initialize an existing database and click Next.

– Initialize an existing database

Setup Manager will populate the tables and the appropriate data to the database that gets created for the WebSphere Portal database.

– Use an existing and initialized database

Setup Manager assumes you have already set up and populated your databases correctly. It therefore will not touch it, as it should be ready to use.

As we chose to share a single database between WebSphere Portal and WebSphere Member Services (see Figure 8-14 on page 598), we do not get the option to create a database here. This additional option would have appeared if you had chosen not to share a single database.


8.2.7 Final configuration stepsIn the last configuration steps, you have to select a server machine as License Server and check your configuration settings as shown in Figure 8-17 and Figure 8-18.

Figure 8-17 Select a valid License Server

1. Selec the Local License Server install type.

License Use Management (LUM) is an IBM tool for managing and extending software licenses. If you choose to install LUM locally, the LUM installation program installs and configures LUM as a network license server, enrolls the WebSphere Portal product in the LUM database, and checks out the number of licenses corresponding to the number of processors you have online on the local server machine.

For example, as illustrated in Figure 8-17, a Local License Server is used for this sample installation.

Click Next and you will see the Summary of the Installation Information window.

2. Figure 8-18 shows our Configuration Summary window.


Make very sure that each value displayed is spelled correctly and all values were issued correctly.

Figure 8-18 Installation Information summary

Click Next to start the installation process.

Note: This window is the last opportunity for you to go back and make changes to your installation settings.


8.2.8 WebSphere Portal installation processThe WebSphere Portal Setup Manager installation process will prompt you to inser the t proper CDs during its installation of the various products.

Each time you are prompted to insert a new CD, do the following.

Figure 8-19 Pop-up window to change the inserted CD-ROM

� Click Unmount in the pop-up window (shown in Figure 8-19). You will not be able to remove the disk from the CD-ROM drive unless you unmount it. Make sure you use the pop-up window instead of a Unix Shell to mount and unmount your disks.

If you decided to copy the CD-ROMs to a hard disk location, you will be prompted to change the path to the proper directory.

In our sample installation, you will be asked for the following CDs:

� WebSphere Portal Family CD #2-3 (DB2 Universal Database)� WebSphere Portal Family CD #2-11 (DB2 Fixpack 5)� WebSphere Portal Family CD #5 (SecureWay Directory Server)� WebSphere Portal Family CD #3-1 (WebSphere Application Server)

Note: If you click the Mount button too quickly (and in other rare cases), the mount command of the Setup Manager might fail and the pop-up window might show you the wrong button, for example an Unmount button, even though the disk was already unmounted. Correct such a problem with a proper command from a shell.

It may also happen that the pop-up window appears to be underneath another window. If your installation seems to be stuck, check whether the pop-up window is only hidden.


Make sure that the WebSphere Application Server installation has enough time to finish. The pop-up window that prompts you to insert a new CD-ROM might appear before the installation of the WebSphere Application Server Fixpacks is finished.

After Setup Manager installed WebSphere Application Server for you, you should populate the LDAP Server with a valid LDIF file. Follow these instructions.

� Adding entries to the LDAP directory

See “Creation of a Lightweight Directory Interchange Format (LDIF) file” on page 578 for instructions on creating a proper LDIF file.

Do not close any of the install windows, but open a new Terminal as root user and execute the following command:

ldif2db -i WPSconfig_itso.ldif

If you added the entries of your LDIF file successfully to the SecureWay Directory Server, you can close that Terminal and continue with the installation process.

The pop-up window prompting you for the next CD should still be open. So continue with the same procedure as described above for the following upcoming CDs:

� WebSphere Portal Family CD #4 (WebSphere Personalization Server)� WebSphere Portal Family CD #13 (WebSphere Portal Extend Edition)

During installation of the WebSphere Portal core component, applications are imported and configuration changes are made to the WebSphere Application Server. WebSphere Application Server will also be restarted several times by WebSphere Portal Setup Manager during this process.

If a pop-up window appears as shown in Example 8-20 and prompts you for identification, do the following:

� Enter wpsbind in both fields and click OK.

Important: The LDIF file must be imported to the SecureWay directory before the WebSphere Portal Core CD-ROM (#7 or #13) is inserted!

If you do not manually import an LDIF file, you risk having the installation fail. This happens frequently if you do not have an LDAP structure with domainController schemas only (dc=blabla,dc=bla).


Figure 8-20 Login window for the WebSphere Application Server Administration Console

Finally, an information window with the title “Configuring for Admin Role” will appear.

Setup of Admin RoleThe information window will guide you through the following process.

1. Restart your HTTP Server

Without closing any of the windows, open a new Terminal window as root user and issue the commands:

/usr/HTTPServer/bin/apachectl stop/usr/HTTPServer/bin/apachectl start

Do not close the Terminal window.

2. Start the WebSphere Application Server Administration Console (AdminConsole)

In the Terminal window enter the command:

/usr/WebSphere/AppServer/bin/adminclient.sh

If the AdminConsole does not start, your graphical environment might not be set up correctly (see 3.4.3, “Remote display” on page 41) or your WebSphere Application Server might not be running.

3. Open the AdminConsole Security Center. Click the Console menu tab and then the entry labeled Security Center.

4. In the Security Center window, as shown in Figure 8-21, make sure that Security is enabled in the General tab. If Security is enabled, continue with the next step.

Important: Do not close this information window for the following process! After finishing that process, you will need to click OK in this window.


Figure 8-21 Make sure the Enable Security box is checked in the Security Center

If Security is not enabled, it is very likely that the Setup Manager could not get a connection to your LDAP directory. If security is not enabled, do the following:

a. Select the Enable Security box.

b. Change to the Authentication tab and supply appropriate values. Consult your WebSphere Application Server Expert about appropriate values or check the IBM WebSphere V4.0 Advanced Edition Handbook, SG24-6176.

c. Click the Apply button and then continue with the next step.

5. Click the Administrative Role tab, then select AdminRole in the Roles list.


Figure 8-22 Select a user and group for the Administrative Role

6. Click Select. You will see a window similar to Figure 8-23.

Figure 8-23 Selecting wpsadmin out of the users and wpsadmins out of the groups


7. In the Select Users/Groups - AdminRole window, insert a * in the Search field and click Search. At least two users and one group will appear in the Available Users/Groups list.

a. Select uid=wpsadmin and click Add >>

b. Select cn=wpsadmins and click Add >>

Do this so that both the wpsadmin user and the wpsadmins group will appear in the right list of the Selected Users/Groups as shown in Figure 8-23. Click OK to leave this window.

8. Click the Apply button of the Security Center. If no error occurs, close the Security Center.

If you get an error, it usually means that the binding to your LDAP Server did not work correctly.

9. Stop the WebSphere Application Server by stopping its node. Do this by opening the Nodes folder, right-clicking the node name (for example, m10df55f), and clicking Stop (see Figure 8-24).

Figure 8-24 Stopping the Administration Server

10.As you stop your WebSphere Application Server node, your AdminConsole will close automatically. Restart WebSphere Application Server by issuing this command from the directory /usr/WebSphere/AppServer/bin:

./startupServer.sh &

If WebSphere Application Server has successfully restarted (see 8.3.2, “WebSphere Application Server” on page 615 on how to start WebSphere Application Server), open the AdminConsole again.


11.Open the Nodes folder and then the node name of your Application Server. After that, open the Application Server folder and check to see if the WebSphere Portal application has restarted (see Figure 8-25).

Figure 8-25 Make sure WebSphere Portal application is running

If not, select WebSphere Portal and start it manually (for example, right-click the name and then click Start).

Continuing with the installation processAs soon as WebSphere Portal is started, you can close the AdminConsole and continue with the installation process by clicking OK in the information window.

Setup Manager will now import the Portlets into WebSphere Portal.

A pop-up window will prompt you for another CD. Continue with the unmounting/mounting procedure as described in the beginning of this section for the following CD:

� WebSphere Portal Family CD #7 (WebSphere Transcoding Publisher)

Note: Depending on the configuration of the setup, you might be prompted for more or fewer CDs.


If Setup Manager completes the steps successfully, it will show a final window as shown in Figure 8-26 and you can continue with verifying your installation.

Figure 8-26 Information Window of a successful installation

Verify whether the installation process was successfulUse any machine on the network that has access to the installed server and has a Web browser installed to check if WebSphere Portal was installed correctly.

For this example, enter the Web address:

http://m10df55f.itso.ibm.com/wps/portal into the browser URL address field.

If you can log on and enroll a new user, you have proven that your installation was successful.

8.3 Post-installation tasksEven though it appears that you now have a ready-to-use WebSphere Portal installation, we recommend some manual post-installation steps.

8.3.1 DB2 Universal DatabaseIn this section, we discuss some suggested activity you should perform for your DB2 Universal Database.

Updating the WebSphere Portal database configurationIf you have decided to share a single database for WebSphere Portal database tables and WebSphere Member Services database tables, you have to update the database configuration of the database that was created by Setup Manager.

Note: Understand that the first request to each page takes a while to process and appear, as the JSPs require compilation at the moment of the first access.


Log in as your database user and issue the commands as shown in Example 8-2 to update your WebSphere Portal database settings. In this example, we list the databases and the catalogs that were created, connect to the xwpsdb database, and then update its configuration.

Important: Make sure all applications are disconnected from the databases before you issue the db2stop command. That means WebSphere Application Server needs to be stopped.

Important: These steps are required if you chose to share a database, due to a flaw in an installation script.

Note: If you chose not to share a database (see Figure 8-14 on page 598) between WebSphere Portal and WebSphere Member Services, you do not need to update your database settings.


Example 8-2 Updating database configuration for WebSphere Portal

# su - wasuser$ cd$ iduid=8(wasuser) gid=13(wasgrp) groups=0(system),103(db2asgrp)$ db2 list db directory

System Database Directory

Number of entries in the directory = 4

Database 1 entry:

Database alias = WPSDB Database name = XWPSDB Node name = XWPSNODE Database release level = 9.00 Comment = Directory entry type = Remote Catalog node number = -1

Database 2 entry:

Database alias = XWPSDB Database name = XWPSDB Local database directory = /home/wasuser Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0

Database 3 entry:

Database alias = WASDB Database name = WASDBL Node name = LOOPBACK Database release level = 9.00 Comment = Directory entry type = Remote Catalog node number = -1

Database 4 entry:

Database alias = WASDBL Database name = WASDBL Local database directory = /home/wasuser Database release level = 9.00 Comment =


Directory entry type = Indirect Catalog node number = 0

$$ db2 connect to xwpsdb user wasuser using wasuser

Database Connection Information

Database server = DB2/6000 7.2.3 SQL authorization ID = WASUSER Local database alias = XWPSDB

$ db2 update db cfg for xwpsdb using applheapsz 16384$ db2 update db cfg for xwpsdb using stmtheap 60000$ db2 update db cfg for xwpsdb using app_ctl_heap_sz 8192$ db2 update db cfg for xwpsdb using locklist 400$ db2 update db cfg for xwpsdb using indexrec RESTART$ db2 update db cfg for xwpsdb using logfilsiz 1000$ db2 update db cfg for xwpsdb using logprimary 12$ db2 update db cfg for xwpsdb using logsecond 10$$ db2set DB2_RR_TO_RS=yes$ db2setDB2ENVLIST=EXTSHMDB2_RR_TO_RS=yesDB2COMM=tcpip$

Removing unnecessary databasesDuring installation, the DB2 instance owner db2inst1 was created and a sample database (DWCNTRL) inside that instance was created. As those are not used by WebSphere Portal, they can be deleted as shown in Example 8-3.

In this example, we remove the dwcntrl database and then delete the db2inst1 instance in the DB2 environment. In the AIX environment, we remove the db2inst1 user and appropriate group and then remove the entry in the /etc/services file that was created for this DB2 instance.

The db2fenc1 user is not removed in this example, because it takes almost no resources and might be helpful for future use.

Removing the user and the associated sample database is not required, but reasonable if you do not have any additional use for them.


Example 8-3 Removing unnecessary DB2 instance db2inst1

# cd# iduid=0(root) gid=0(system) groups=101(db2iadm1),103(db2asgrp),400(dbsysadm)# su - db2inst1$ db2startSQL1063N DB2START processing was successful.$ db2 drop db dwcntrlDB20000I The DROP DATABASE command completed successfully.$ db2 list db directorySQL1057W The system database directory is empty. SQLSTATE=01606$ db2stopSQL1064N DB2STOP processing was successful.$ exit# cd /usr/lpp/db2_07_01/instance# ./db2ilistdb2inst1ldapdb2wasuser# ./db2idrop db2inst1DBI1070I Program db2idrop completed successfully.

# ./db2ilistwasuserldapdb2# userdel -r db2inst1# rmgroup db2iadm1# cd /etc# cp -p services services.old# grep 50000 servicesdb2cdb2inst1 50000/tcp # Connection port for DB2 instance db2inst1# sed -e 's/^db2cdb2inst1.*$//' < services.old > services#

Starting and stopping DB2 Universal DatabaseOnly the instances used by WebSphere Portal must be started. The DB2 admin user (db2as) is only required for certain tasks, such as using the DB2 Graphical Administration Interface (db2cc). Therefore, the admin instance is optional.

To start DB2 for WebSphere Portal:

su - db2as -c ‘db2admin start’su - ldapdb2 -c ‘db2start’su - wasuser -c ‘db2start’


To stop DB2 processes again (all applications must be disconnected):

su - ldapdb2 -c ‘db2stop’su - wasuser -c ‘db2stop’su - db2as -c ‘db2admin stop’

8.3.2 WebSphere Application ServerIn this section, we discuss some actions you might need to perform for your WebSphere Application Server.

Updating sas.client.propsIf you frequently use the Administration Console, it might be worth getting rid of the window (see Figure 8-20 on page 605) that asks for a user name and password. To do so, the sas.client.props file in /usr/WebSphere/ApplicationServer/properties requires an update.

Search for each of the following lines:

com.ibm.CORBA.loginSource=promptcom.ibm.CORBA.loginTimeout=300

com.ibm.CORBA.securityEnabled=truecom.ibm.CORBA.loginUserid=com.ibm.CORBA.loginPassword=

Change the values for those lines to:

com.ibm.CORBA.loginSource=propertiescom.ibm.CORBA.loginTimeout=300

com.ibm.CORBA.securityEnabled=truecom.ibm.CORBA.loginUserid=wpsbindcom.ibm.CORBA.loginPassword=wpsbind

Starting and stopping applications from the command lineEven if you are able to use a graphical administration tool like the WebSphere Administration Console, it is helpful if you are able start and stop the WebSphere Application Server and WebSphere Portal from the command line.

Note: No administration client requests issued from this particular machine to the WebSphere Application Server will require authorization any more. Make sure this configuration change does not breach your security guidelines.


� To start WebSphere Application Server, use the command:

/usr/WebSphere/AppServer/bin/startupServer.sh &

With the command tail -f /usr/WebSphere/AppServer/logs/tracefile you can see the progress of program start. As soon as the line “... open for e-business” appears, WebSphere Application Server is started.

� To stop WebSphere Application Server, create a file as shown in Example 8-4. You will need to replace the value of name in section node with the appropriate node name.

You know the name of the node from the AdminConsole (see Figure 8-24 on page 608) and this name is usually equal to your hostname. To get your hostname, type:

uname -n

To use the newly created file that we call stopwas.xml, change to the directory /usr/WebSphere/AppServer/bin and enter the command:

# ./XMLConfig.sh -import stopwas.xml -adminNodeName m10df55f

Example 8-4 Sample XML file to stop the WebSphere Application Server node

<?xml version="1.0"?><!DOCTYPE websphere-sa-config SYSTEM "file:///$XMLConfigDTDLocation$$dsep$xmlconfig.dtd" ><websphere-sa-config> <node name="m10df55f" action="stop"> </node></websphere-sa-config>

Even though processing of the command is finished, WebSphere Application Server and the dependent processes of WebSphere Portal might not be stopped completely. Check the operating system for remaining Java processes:

ps -ef | grep java

Note: All actions need to be performed as user root!

Always replace the sample node name (m10df55f) with your node name.

Make sure you updated the sas.client.props file as described above before using the XMLConfig.sh tool which is used in this section.

Note: These examples use the node name m10df55f. Make sure you replace this value with your own node name!


� To start WebSphere Portal as an application inside WebSphere Application Server, use the following command (with the XML file as shown in Example 8-5):

./XMLConfig.sh -import wps.xml -adminNodeName m10df55f -substitute “paction=start”

� To stop WebSphere Portal without stopping WebSphere Application Server, use the same XML file as before, but import it with:

./XMLConfig.sh -import wps.xml -adminNodeName m10df55f -substitute “paction=stop”

Example 8-5 Sample XML file (wps.xml) to start WebSphere Portal

<?xml version="1.0"?><!DOCTYPE websphere-sa-config SYSTEM "file:///$XMLConfigDTDLocation$$dsep$xmlconfig.dtd" ><websphere-sa-config> <node name="m10df55f" action="update"> <application-server action="$paction$" name="WebSphere Portal"> </application-server> </node></websphere-sa-config>

Starting and stopping the IBM HTTP ServerAfter regenerating the HTTP Server plugin of the WebSphere Application Server, it is required to stop and start the IBM HTTP Server.

� Use the following command to start the IBM HTTP Server:

/usr/HTTPServer/bin/apachectl start

� Use the following command to stop the IBM HTTP Server:

/usr/HTTPServer/bin/apachectl stop

8.3.3 SecureWay DirectoryIn this section, we discuss suggested activity you should perform for your SecureWay Directory.

Apply SecureWay 3.2.2 eFix 2You must apply eFix 2, which is included on CD-ROM #1 in the subdirectory /swd-eFix/aix. Carefully read the installation instructions (AIX-128-2.txt) and apply the fix as described.


Stopping and starting SecureWay DirectoryFollow these procedures to stop and start the SecureWay Directory.

Stopping SecureWay Directory ServerThe recommended way to stop SecureWay Directory from a Shell is to send the main process a terminate task signal (TERM):

kill -15 ‘cat /etc/slapd.pid‘

Starting SecureWay Directory ServerThe SecureWay Directory daemon process can be started issuing the command slapd from any directory. It comes with some command line tools, such as ldapsearch, ldapxcfg, ldapadd, ldapdelete, etc. Those programs can all be found in the /usr/bin directory and are therefore in the default PATH.

8.4 Installing WebSphere Portal in a non-graphical environment

There are two general approaches for performing an installation in an environment where you do not have the option of using any graphical tools.

� One would be to use the SetupManager and create a input file with your appropriate server setup. The Installation CD does come with an example file, wposetup.script. If you have successfully finished your installation with WebSphere Portal Setup Manager as discussed in 8.2, “WebSphere Portal installation using Setup Manager” on page 580, Setup Manager will place a file with values as entered during configuration on the filesystem under /usr/IBMWPO/responsefile/wporecord.script.

We will not cover this possibility in this book.

� The other possibility is to install all prerequisite products individually and then feed the Installer of the WebSphere Portal framework with an installation file that is a mirror of our environment.

We will cover this scenario in the book, as we feel this will happen more commonly. The main reason for this is that customers of WebSphere Portal

Note: Stop all processes, including WebSphere Portal and WebSphere Application Server, that might access the LDAP Server before applying the eFix.

Note: Use backticks, not single-quotes for this command!


might already be happy customers using other IBM products and might want to reuse their already installed products.

8.4.1 Installation and setup of WebSphere Portal prerequisitesThe prerequisites installation steps are examples only. Unless you already know what you are doing, it is highly recommended to check the appropriates product documentations and the Redbooks which are relevant for those products.

The assumption for this chapter is that you already have some of the products in place and just need to add parts of the prerequisites. It is, however, recommended that you read all sections of this chapter in order to understand the example setup. This will enable you to discover to differences with the setup of the products you have already in place and adjust your installation or the example instructions accordingly.

Create databases on the DB2 UDB ServerFor more background on the following steps, refer to the DB2 documentations such as the DB2 for Unix Quick Beginnings Guide and the DB2 Command Reference, V7.2 that can be downloaded from http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7pubs.d2w/en_main

1. Check DB2 Version level

Log in as DB2 Administrative user or any DB2 instance user and check the DB2 level

# su - db2as$ db2levelDB21085I Instance "db2as" uses DB2 code release "SQL07023" with levelidentifier "03040105" and informational tokens "DB2 v7.1.0.55", "s011211" and "U480359".$ exit

Important: Even we do not use any graphical tool and do not see any graphical window during the installation, the install tool of WebSphere Transcoding Publisher will check whether it would be theoretically able to use X , and stops, if it cannot. Therefore, it might be worthwhile to check step 7 on page 659 of the WebSphere Transcoding Publisher installation before selecting this type of installation.

Important: It is important that you use the same DB2 level on the DB2 UDB Server as on the DB2 Enterprise Connect Client. The required level for WebSphere Portal is Version 7 Fixpack 5.


Make sure the informational token says DB2 V7.1.0.55 or something higher than 55 at the end. If not, upgrade your DB2 Installation to Version 7 Fixpack 5.

2. Create a DB2 instance owner

In our example, we will use db2ixwps as the name for the instance owner.

a. Log in as root user to create the instance owner.

# iduid=0(root) gid=0(system) groups=103(db2asgrp),400(dbsysadm)# mkgroup wpsfgrp# mkuser pgrp=wpsfgrp home=/home/wpsfuser wpsfuser# mkgroup wpsigrp # mkuser pgrp=wpsigrp home=/home/wpsuser wpsuser# /usr/lpp/db2_07_01/instance/db2icrt -a SERVER -u wpsfuser wpsuserDBI1070I Program db2icrt completed successfully.# su - wpsuser# passwd wpsuserChanging password for “wpsuser”wpsuser’s New password:Enter the new password again:# su - wpsuser$ passwdChanging password for “wpsuser”wpsuser’s Old password:wpsuser’s New password:Enter the new password again:$ exit#

b. Log in as instance owner and update the instance settings.

Before updating, make sure the service name is not used by any other instance or application yet. We will use the name db2cdb2ixwps.

# su - wpsuser$ db2 update dbm cfg using svcename db2cwpsuserDB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.DB21025I Client changes will not be effective until the next time the application is started or the TERMINATE command has been issued. Server

Note: If you already have a DB2 instance, you might want to reuse it and therefore skip this step. Continue with the second step if this is the case.

Note: If you set the password of the user only as root user, it will be expired after logging in the first time. You would need to reset it as user.


changes will not be effective until the next DB2START command.

$ db2set -i wpsuser db2comm=tcpip$ db2 terminateDB20000I The TERMINATE command completed successfully.$ exit

c. Update the operating system settings for the newly created instance.

d. Before updating your /etc/services file, make sure the service names and ports are not used by any other instance or application.

# netstat -an |grep 55000# netstat -an |grep 55001# grep db2cwpsuser /etc/services# grep db2iwpsuser /etc/services# # echo "db2cwpsuser 55000/tcp # Connection port for DB2 instance wpsuser" >> /etc/services# echo "db2iwpsuser 55001/tcp # Interrupt port for DB2 instance wpsuser" >> /etc/services# # /usr/lpp/db2_07_01/instance/db2iset DB2AUTOSTART=TRUE -i wpsuser

3. Create the WebSphere Application Server database (for example: xwas) as the shared administrative repository.

# su - wpsuser$ db2start$ db2 create database xwas$ db2 update database configuration for xwas using applheapsz 256

4. Create the WebSphere Portal database (for example: xwps) for Portal data.

$ db2 create database xwps using codeset UTF-8 territory US$ db2 update database configuration for xwps using applheapsz 1024$ db2 update database configuration for xwps using app_ctl_heap_sz 1024


5. Create the WebSphere Member Services database (for example : xwms).

$ db2 create database xwms using codeset UTF-8 territory US$ db2 update database configuration for xwms using applheapsz 16384$ db2 update database configuration for xwms using stmtheap 60000$ db2 update database configuration for xwms using app_ctl_heap_sz 8192$ db2 update database configuration for xwms using locklist 400$ db2 update database configuration for xwms using indexrec RESTART$ db2 update database configuration for xwms using logfilsiz 1000$ db2 update database configuration for xwms using logprimary 12$ db2 update database configuration for xwms using logsecond 10$ db2stop$ db2 terminate$ db2start$ exit#

Install DB2 Connect Client and connect to DB2 UDB ServerThe goal of the description is to give an example. To get more background on the following steps, refer to the DB2 documentations such as the DB2 Connect Enterprise Edition for Unix and the DB2 Command Reference, V7.2 that can be downloaded from:

http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7pubs.d2w/en_main

Tip: Each database can also be handled by an individual DB2 instance owner.

Important: If you install DB2 from the CD set that comes with WebSphere Portal, make sure you create the necessary instances before adding the required Fixpack 5 to the installation. After upgrading, your db2setup tool will not work with AIX 5L as the operating system any more (see Figure 8-27). If you still require a working db2setup tool, contact your IBM representative.



Figure 8-27 Version mismatch of the DB2 Fixpack 5 CD and AIX 5L

If you already have DB2 Connect Client installed and only want to upgrade your db2level, you might want to start with Step 16 on page 629.

To install the DB2 Enterprise Connect Client, complete the following steps:

1. Insert WebSphere Portal CD #2-3 (DB2 UDB EE for AIX) and issue the following commands as root user:

# mount /cdrom# cd /cdrom/db2/aix# ./db2setup

This will start the DB2 Setup Tool as shown in Figure 8-29.

2. Select two options:

– DB2 Administrative Client

– DB2 Connect Enterprise Edition

The selection of the options will lead you automatically to the customize settings window, as shown in Figure 8-28, for the DB2 Connect Enterprise Client option.

We also selected the default values the Control Center and deselected the Code Page Conversion Support for eastern languages (see Figure 8-28). Leaving the default values on these windows , however, would work just as well.


Check the DB2 documentation on background information for the available options.

Figure 8-28 Customize the installation options for the DB2 Connect Enterprise Edition

After selecting OK, you will be returned to the main setup page. If you have selected and customized both the DB2 Administrative Client and DB2 Connect Enterprise Edition options, you can select additional information pages by customizing the DB2 Product Messages and DB2 Product Library option.


Figure 8-29 Main window of DB2 Setup Tool

3. Return to the main setup page as shown in Figure 8-29, select the OK field to continue installation.

The upcoming window has the headline Create DB2 Services and lets you create a DB2 instance and the Administration Server.

4. Select the Create a DB2 instance option. A window will be displayed as shown in Figure 8-30.


Figure 8-30 Create a DB2 instance user

Insert proper values in the fields User Name, Group Name, Home Directory and Password. We will use the values as shown in Figure 8-30.

The values do not need to be pre-existing on your system, nor does there need to exist the same group on the DB2 UDB Server machine. Also, the password for the user is allowed to differ.

If you do not set a value for Password, the default password, which is ibmdb2, will be set for you.

5. Select the Properties... field and select Enter as shown in Figure 8-30.

This will bring up a window with the headline DB2 Instance Properties.

Make sure

– Server is selected as the Authentication Type

– TCP/IP is selected as the Communications Protocol

Important: The User Name must not differ from the User Name of the DB2 instance on the DB2 Server installation.

The reason is a flaw in the Concept of the WebSphere Portal Installer.


Figure 8-31 Selecting a Service Name and Port Number for the DB2 instance

6. Select the Properties... field that is on the same line as TCP/IP and click Enter to see the window shown in Figure 8-31.

Enter an alphanumeric value in Service Name and a decimal value in Port Number.

– Service Name can be any name that is not yet in use. Check your /etc/services file for names in use.

– Port Number must be equal to the port number defined during the DB2 instance configuration in DB2 UDB Server setup (see step 2 on page 620).

We will use db2cwpsuser as Service Name and 55000 as Port Number.

7. Select OK to close the TCP/IP window and select OK to close the DB2 Instance Properties window.

8. Select OK to accept the settings for the DB2 Instance. A window will be displayed as shown in Figure 8-32.


Figure 8-32 Create a DB2 fenced user

Insert proper values in the fields User Name, Group Name, Home Directory and Password. We will use the values as shown in Figure 8-32.

The values do not need to be pre-existing on your system, nor does there need to be the same user or group on the DB2 UDB Server machine.

If you do not set a value for Password, the default password, which is ibmdb2, will be set for you.

9. Select OK to accept the values and to return to the window with the headline Create DB2 Services.

10.Select the option Create the Administration Server, which will lead you to a window that is headlined with Administration Server.

11.In that window, we leave all default values unchanged. That means:

– User Name: db2as

– Group Name: db2asgrp

– Home Directory: /home/db2as

– Password: password

– Verify Password: password

12.Select OK to accept the values and to return to the window with the headline Create DB2 Services.

13.Select OK to move to the Summary report.


14.Select Continue to start the installation.

15.Select OK to leave the db2setup tool after successful installation.

16.Before upgrading your DB2 installation with Fixpack 5, make sure that no DB2 processes are running. Use for example the command:

ps -ef | grep db2

17.To upgrade your DB2 Enterprise Connect Client installation with Fixpack 5, insert the CD # 2-11 (DB2 UDB EE for AIX Fixpack 5) into your CD drive and issue the following commands as root user:

# cd# umount /cdrom# mount /cdrom# cd /cdrom/db2fp/aix# smitty update_all

18.The cursor-based AIX System Management Interface Tool starts and asks you to provide information to update software. We use the values as shown in Figure 8-33.

– INPUT device/directory for software: . (insert a single dot)

– SOFTWARE to update: _update_all (leave default value)

– PREVIEW only?: no (change this value, if it does not already say no)

Note: If any DB2 files are opened or in use, your upgrade will fail.


Figure 8-33 Upgrade DB2 with Fixpack 5, using smitty

19.After smitty has successfully updated DB2, close the smitty tool.

20.After updating your DB2 files, you must update your instances and your Administrative Server. Therefore, issue the following commands as root user:

# cd# umount /cdrom# /usr/lpp/db2_07_01/instance# ./db2iupdt -ewpsuserDBI1070I Program db2iupdt completed successfully. # # ./dasiupdt db2asDBI1070I Program dasiupdt completed successfully.

21.Test the update of your DB2 instance. Log in as DB2 instance user and check the DB2 level with the following commands.

# su - wpsuser$ db2levelDB21085I Instance "db2as" uses DB2 code release "SQL07023" with levelidentifier "03040105" and informational tokens "DB2 v7.1.0.55", "s011211" and "U480359".$ exit#


22.Update your DB2 instance to use the JDBC2 driver. To do this, log in as your DB2 instance user and add a line to the user’s profile using the following commands:

# su - wpsuser$ echo ". sqllib/java12/usejdbc2" >> .profile$ exit#

23.Start the DB2 instance with the following commands:

# su - wpsuser$ db2start$

24.Catalog a TCP/IP node in the DB2 instance users environment. Issue the following commands as instance user (here: wpsuser):

$ db2 catalog tcpip node DBSERVER remote m10df55f.itso.ral.ibm.com server db2cwpsuser$ db2 list node directoryNode DirectoryNumber of entries in the directory = 1Node 1 entry:Node name = DBSERVER Comment = Protocol = TCPIP Hostname = m10df55f.itso.ral.ibm.com Service name = db2cwpsuser$

The short syntax for the command is:

db2 catalog tcpip node <nodename> remote <hostname> server <servicename>

where <nodename> can be any name, <hostname> is the name or IP-Address of the Server with the DB2 Server Installation and <servicename> is the Port number or the Service Name for the Port, as we defined it in step 6 on page 627.

25.Catalog the databases that we created on this DB2 instance. To do this, use the following commands as instance user (here: wpsuser):

$ db2 catalog database xwas as was at node DBSERVER$ db2 catalog database xwps as wps at node DBSERVER$ db2 catalog database xwms as wms at node DBSERVER$

Note: Make sure the informational token says DB2 V7.1.0.55 or something higher than 55 at the end. The DB2 level must be equal to the one from the DB2 Server installation.


26.Terminate and restart the DB2 instance with the following commands as instance user (here: wpsuser):

$ db2 terminate$ db2stop$ db2start$

27.Test the connection to the database on the DB2 Server through the catalogs at the DB2 Client installation. Use the following commands as instance user (here: wpsuser) to do this:

$ db2 connect to was user db2ixwps using password$ db2 disconnect current$ db2 connect to wps user db2ixwps using password$ db2 disconnect current$ db2 connect to wms user db2ixwps using password$ db2 disconnect current$

If one of the connects fail, there might be a problem with the database you want to connect to. If all connects fail, there is very likely a network configuration error or another problem with the network.

Installation of WebSphere Application Server V4.02 and eFixesTo get more background on the following steps, refer to the WebSphere Application Server documentations such as the WebSphere Application Server V4.0 Handbook (SG24-6176) and the WebSphere Application Server InfoCenter that can be accessed at:

http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter

To install WebSphere Application Server Version 4.02 and eFixes, complete the following steps:

1. Insert WebSphere Portal CD #3-1 (WebSphere Application Server Advanced Edition for AIX) and issue the following commands as root user to copy the sample responsefile to a writable directory:

# mount /cdrom# cd /cdrom/was/aix# cp install.script /tmp/install.script.new

2. Use an Editor to edit the sample responsefile so that it fits to your needs.

Note: The following instructions will therefore intentionally not go into detail. They will only serve as an example.




3. The following name/value pairs were changed for this installation (only the new values are listed):

destinationDirectory=/usr/WebSphere/AppServerInstallOption=CustomSelect4.config.apserv.httpserv=/usr/HTTPServer/conf/httpd.confDBName=wasDBUser=wpsuserDBPassword=wpsuserDBHome=/home/wpsuser

To understand all options of this file in-depth, consult the description in the WebSphere Application Server InfoCenter:


4. Start the installation of the WebSphere Application Server with the edited file by issuing the following command as root user:

# cd /cdrom/was/aix# ./install.sh -silent -responseFile /tmp/install.script.new

5. Check whether the WebSphere Application Server plugin was correctly added to your IBM HTTP Server. You can check this with a tail on your httpd.conf file, as the following command shows:

# tail /usr/HTTPServer/conf/httpd.conf

If the httpd.conf file does not include the following three lines, add them to this file.

LoadModule ibm_app_server_http_module /usr/WebSphere/AppServer/bin/mod_ibm_app_server_http.soWebSpherePluginConfig /usr/WebSphere/AppServer/config/plugin-cfg.xmlAddModule mod_app_server_http.c

6. Start your IBM HTTP Server by using the following command as root user:

# /usr/HTTPServer/bin/apachectl start

7. Check the correct installation of IBM HTTP Server by using a Web browser, pointing to the machine where WebSphere Application Server was just installed. You should see a window as shown in Figure 8-34.



Figure 8-34 Welcome Page of the IBM HTTP Server

8. Start your IBM WebSphere Application Server by using the following command as root user:

# /usr/WebSphere/AppServer/bin/startupServer.sh &

9. Create an XML file to start your Default Server. In our example installation, we pasted the following text into a file named /usr/WebSphere/AppServer/bin/default_start.xml:

<websphere-sa-config> <node name="m10df4ff" action="update"> <application-server action="start" name="Default Server"> </application-server> </node></websphere-sa-config>


10.Start the Default Server by importing the created default_start.xml file. The following command shows an example of how to do that:

# cd /usr/WebSphere/AppServer# ./XMLConfig.sh -import default_start.xml -adminNodeName m10df4ff[02.09.17 18:00:11:691 EDT] 72a7e944 NodeConfig A XMLC0053I: Importing Node : m10df4ff[02.09.17 18:00:12:593 EDT] 72a7e944 ApplicationSe A XMLC0053I: Importing ApplicationServer : Default Server#

11.Check the WebSphere Application Server Installation by accessing the Snoop Servlet. Use a Web browser and enter the URL: http://<fqdn>/servlet/snoop, where <fqdn> is the fully-qualified domain name of your server. In our case, we use http://m10df4ff.itso.ral.ibm.com/servlet/snoop to get to a Browser window as shown in Figure 8-35.

Figure 8-35 Check WebSphere Application Server Installation with the Snoop Servlet

Important: Make sure to always replace the nodename of these examples (m10df4ff) with your nodename!


12.Create an XML file to stop your WebSphere Application Server. In our example installation, we put the following text into a file named /usr/WebSphere/AppServer/bin/node_stop.xml:

<websphere-sa-config> <node name="m10df4ff" action="stop"> </node></websphere-sa-config>

13.Stop the WebSphere Application Server node by importing the created node_stop.xml file. The following command shows an example of how to do that:

# ./XMLConfig.sh -import node_stop.xml -adminNodeName m10df4ff [02.09.17 18:03:46:155 EDT] 72abe9d1 NodeConfig A XMLC0053I: Importing Node : m10df4ff#

14.Stop the IBM HTTP Server, using the command

# /usr/HTTPServer/bin/apachectl stop

15.Stop the IBM HTTP Administrative Server, using the command

# /usr/HTTPServer/bin/adminctl stop

16.Start WebSphere Application Server Fixpack installation using the following commands as root user:

# cd /cdrom/was/aix/fixpack2# ./install.sh -TmpDir /tmp

The assumption is that WebSphere Portal CD #3-1 (WebSphere Application Server Advanced Edition for AIX) is still mounted and that the directory /tmp can be used for temporary files.

17.Insert the root directory of WebSphere Application Server and select Enter as soon as the installer asks you for it. In our example it would be /usr/WebSphere/AppServer.

18.Type y for yes and select Enter, when the update installer asks you if it should install the IBM HTTP Server PTF (see Figure 8-36).

Important: It is very important that no process of IBM HTTP Server or WebSphere Application Server be running during installation of a Fixpack.


Figure 8-36 Installing Fixpack 2 for WebSphere Application Server

19.Type y for yes and select Enter when the update installer asks you if it should install the Java Connector Architecture (J2C) update.

20.Start the installation of WebSphere Application Server eFixes by changing to the directory of the eFixes and checking the PATH for java. To do this, use the following commands:

# cd /cdrom/was/eFixes# which java/usr/WebSphere/AppServer/java/bin//java

The assumption is that WebSphere Portal CD #3-1 (WebSphere Application Server Advanced Edition for AIX) is still mounted and that the directory /tmp can be used for temporary files.

21.Install all eFixes that come with the product. To do this, use the following commands:

# java -jar PQ55941_eFix.jar -TmpDir /tmp# java -jar PQ56615_eFix_AEServer_AEsServer.jar -TmpDir /tmp# java -jar PQ57814_eFix_AEServer.jar -TmpDir /tmp# java -jar PQ58289_eFix.jar -TmpDir /tmp# java -jar PQ58678_eFix.jar -TmpDir /tmp# java -jar PQ58795_Test_AEServer_AEsServer.jar -TmpDir /tmp# java -jar PQ59932_eFix_AEServer_AEsServer.jar -TmpDir /tmp# java -jar PQ60787_eFix.jar -TmpDir /tmp


22.Start your IBM WebSphere Application Server by using the following command as root user:

# /usr/WebSphere/AppServer/bin/startupServer.sh &

23.Start your IBM HTTP Server by using the following command as root user:

# /usr/HTTPServer/bin/apachectl start

24.Check the correct installation of IBM HTTP Server by using a Web browser, pointing to your Server. You should see a window as shown in Figure 8-34 on page 634.

25.Start the Default Server by importing the created default_start.xml file. The following command shows an example of how to do that:

# cd /usr/WebSphere/AppServer# ./XMLConfig.sh -import default_start.xml -adminNodeName m10df4ff

26.Check the updated WebSphere Application Server Installation by accessing the Snoop Servlet. Use a Web browser and enter the URL: http://<fqdn>/servlet/snoop, where <fqdn> is the fully-qualified domain name of your server. That means, in our case we use http://m10df4ff.itso.ral.ibm.com/servlet/snoop to get to a Browser window as shown in Figure 8-35 on page 635.

27.Create an XML file to stop your Default Server. In our example installation, we put the following text into a file named /usr/WebSphere/AppServer/bin/default_stop.xml:

<websphere-sa-config> <node name="m10df4ff" action="update"> <application-server action="stop" name="Default Server"> </application-server> </node></websphere-sa-config>

Note: Make sure you install all required eFixes for your WebSphere Application Server version. Check the latest Release Notes of WebSphere Portal to understand which eFixes you will require.

An incomplete set of eFixes will prevent your successful installation or lead to an unreliable WebSphere Portal installation.

Note: It is important that this test works with the fully-qualified domain name. WebSphere Portal will require a fully-qualified domain name!


28.Stop the Default Server by importing the created default_stop.xml file. The following command shows an example of how to do that:

# cd /usr/WebSphere/AppServer# ./XMLConfig.sh -import default_stop.xml -adminNodeName m10df4ff

Use of an LDAP ServerAs LDAP is an open protocol and it should not matter which implementation of the various vendors you choose.

The supported LDAP Server implementations are:

� IBM SecureWay Directory Server

� Lotus Domino LDAP Service

� iPlanet Directory Server

� Microsoft Active Directory (limitations apply)

The assumption for this chapter is that you already have an LDAP Directory implementation successfully in use. The following two sections will, nevertheless, provide a very brief description of how to install IBM SecureWay Directory or, as an alternative, OpenLDAP.

Installation of SecureWay DirectoryMake sure that you have read the documentation which is part of the SecureWay Directory Server product. An installation description is also included in the products documentation.

1. Make sure you have DB2 UDB Server 7.2 installed on the server where you intend to install SecureWay Directory.

2. You may also want to install the IBM HTTP Server that is required for the SecureWay Directory Server HTTP Administration interface. Consult the product documentation for your decision.

3. Insert and mount WebSphere Portal CD #5 (IBM SecureWay Directory). Open a Terminal as root user and issue the following commands:

# mount /cdrom

Note: OpenLDAP is not included in the list of LDAP Servers supported by WebSphere Portal, but is known to work.

Note: SecureWay Directory requires DB2 UDB Server to hosts its tables for the LDAP Directory. You cannot use another RDBMS or use a remote DB2 Server installation.


# cd /cdrom/swd/aix/ldap32_us

4. Use the AIX tool smitty to install the packages you require. To do this, start smitty with the command:

# smitty install_package

5. Smitty will start with a command prompt for the INPUT directory as shown in Figure 8-37. Insert a dot (plus) to mark the current directory and press Enter.

Figure 8-37 Selecting the software installation input directory at smitty

6. Select F4 to list the packages in that directory.

7. Make sure you select at least the ldap.server package as shown in Figure 8-38. You might optionally select more modules, such as the ldap.client or the modules for strong encryption. Consult the product documentation to make your decision.


Figure 8-38 Selecting software packages for installation in smitty

8. After selecting all software packages, press Enter to continue.

9. Select Enter to start the installation of the selected packages.

10.Leave the smitty tool.

11.Create a DB2 instance owner and the DB2 database.

In our example, we will use ldapdb2 as the name for the instance owner. Log in as root user to create the instance owner.

# ldapcfg -l /home/ldapdb2 -c

12.Set the LDAP Administrative User

In our example, we will use cn=ldapadmin as the full name of the Administrative User and will use ldapadmin as password.

# ldapcfg -u”cn=ldapadmin” -pldapadmin

13.Start SecureWay Directory Server with the command slapd (see “Starting SecureWay Directory Server” on page 618).

14.Create an LDIF file as described in “Creation of a Lightweight Directory Interchange Format (LDIF) file” on page 578.

15.Open a Terminal as root user and execute the command as shown below:

# ldif2db -i WPSconfig_itso.ldif


16.If you added the entries of your LDIF file successfully to the SecureWay Directory Server, you can close the Terminal and continue with the installation process.

Installation of OpenLDAPOpenLDAP is a resource-saving, open source LDAP Server implementation. You will find very good information about this LDAP implementation and about LDAP in general on the Web ste of OpenLDAP:

http://www.openldap.org

1. Download OpenLDAP and its prerequisite, the Berkeley database libraries from the IBM Web site:

http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html

db The Berkeley Database, the Open Source embedded database system.

openldap LDAP servers, libraries, utilities, tools and sample clients.

2. Install the downloaded RedHat Package Manager Archives. To do this, open a Terminal as root user and issue the following commands:

# rpm -hiv db-3.3.11-1.aix4.3.ppc.rpmdb ################################################### rpm -hiv openldap-2.0.21-3.aix4.3.ppc.rpmopenldap ###################################################

3. Change the default configuration of OpenLDAP by editing the /etc/openldap/slapd.conf file.

a. Make sure you add three additional schema definitions:

include /opt/freeware/etc/openldap/schema/corba.schemainclude /opt/freeware/etc/openldap/schema/cosine.schemainclude /opt/freeware/etc/openldap/schema/inetorgperson.schema

b. Choose a base suffix for your LDAP directory, for example:

suffix "o=ibm,c=us"

c. Select a full name for the LDAP Administrative name, for example:

rootdn "cn=ldapadmin"

d. Select a password for the LDAP Administrative user:

rootpw {SSHA}eUPD9tV7a61HZyaiiPd1fZibaqRlqIdX

The password can also be allowed to be in plain text. To create a encrypted value, use the following commands in a Terminal as root user:




# slappasswdNew password:Re-enter new password:{SSHA}eUPD9tV7a61HZyaiiPd1fZibaqRlqIdX#

e. Select a directory where the LDAP Directory database shall be located, for example:

directory /opt/freeware/var/openldap-ldbm

If the directory does not already exist, make sure you create it, for example using the following commands in a terminal as root user:

cd /opt/freewaremkdir varcd varmkdir openldap-ldbm

4. Start the OpenLDAP daemon with the command slapd. The start/stop procedure is similar to the one for SecureWay Directory (see 8.3.3, “SecureWay Directory” on page 617).

5. Create a proper LDIF file. The naming of object classes differs from the SecureWay Directory implementation. Therefore, use corbaContainer instead of container in OpenLDAP. Example 8-6 provides a LDIF file for OpenLDAP with the same values as the ones in Example 8-1 on page 579 for SecureWay.

6. Import the created LDIF file to OpenLDAP. Use the following command in a Terminal as root user:

# ldapadd -x -D "cn=ldapadmin" -W -f /tmp/WPSconfig_itso_openldap.ldifEnter LDAP Password: adding new entry "o=ibm,c=us"adding new entry "ou=itso,o=ibm,c=us"adding new entry "cn=users,ou=itso,o=ibm,c=us"adding new entry "cn=groups,ou=itso,o=ibm,c=us"adding new entry "uid=wpsadmin,cn=users,ou=itso,o=ibm,c=us"adding new entry "uid=wpsbind,cn=users,ou=itso,o=ibm,c=us"adding new entry "cn=wpsadmins,cn=groups,ou=itso,o=ibm,c=us"#


Example 8-6 LDIF file for OpenLDAP

# NOTE: you must edit this file before importing it and replace all# occurrences of the default suffix "ou=itso,o=ibm,c=us" with the suffix# that your LDAP server is configured for.

version: 1dn: o=ibm,c=usobjectClass: organizationo: ibm,c=uso: IBM Corporation

dn: ou=itso,o=ibm,c=usobjectclass: organizationalUnitobjectclass: top# Add lines according to this scheme that correspond to your suffixou: itso,o=ibm,c=usou: International Technical Support Organization

dn: cn=users,ou=itso,o=ibm,c=usobjectclass: corbaContainerobjectclass: topcn: users

dn: cn=groups,ou=itso,o=ibm,c=usobjectclass: topobjectclass: corbaContainercn: groups

dn: uid=wpsadmin,cn=users,ou=itso,o=ibm,c=usobjectclass: organizationalPersonobjectclass: personobjectclass: topobjectclass: inetOrgPersonuid: wpsadminuserpassword: {SSHA}crsnj5JTv1dIgMLQzYiJf8iPOVBKXqcvsn: admingivenName: wpscn: wps admin

dn: uid=wpsbind,cn=users,ou=itso,o=ibm,c=usobjectclass: topobjectclass: personobjectclass: organizationalPersonobjectclass: inetOrgPersonuid: wpsbinduserpassword: {SSHA}zWnS3XtPb+bsL34ZbIbG9KjhBJSjZLLgsn: bindgivenName: wps


cn: wps bind

dn: cn=wpsadmins,cn=groups,ou=itso,o=ibm,c=usobjectclass: groupOfUniqueNamesobjectclass: topuniquemember: uid=wpsadmin,cn=users,ou=itso,o=ibm,c=uscn: wpsadmins

Installation of WebSphere Personalization ServerThe relationship of WebSphere Personalization with WebSphere Portal can be compared to the chicken-egg problem.

� To install WebSphere Personalization so that it is usable with WebSphere Portal, you require an application inside the WebSphere Application Server that is called WebSphere Portal.

� To install WebSphere Portal, you require WebSphere Personalization since WebSphere Portal uses libraries of WebSphere Personalization even during the installation process.

All manual installation approaches in this book provide an implicit workaround for this problem. WebSphere Portal Setup Manager also uses such a workaround undercover.

As the Windows installation section relies on creating an empty Application called WebSphere Portal, we will use the approach of copying the required files to the WebSphere Application Server PATH. The following lines show how to do that:

# mount /cdrom# cd /cdrom/personalization/utils# cp personalization.jar /usr/WebSphere/AppServer/lib# cp prCommon.jar /usr/WebSphere/AppServer/lib# cd# umount /cdrom

8.4.2 Silent installation of WebSphere PortalThe buildup of a WebSphere Portal responsefile from scratch, as we do it here, can be somewhat cumbersome, but it offers you maximum flexibility regarding the options WebSphere Portal offers during installation. We will describe the options briefly and point to the first part of this chapter where appropriate.

The recommended solution to install WebSphere Portal is to use Setup Manager as described in 8.2, “WebSphere Portal installation using Setup Manager” on page 580. Such an installation will also create a responsefile, similar to the one


we will manually build in this chapter. You can find this file at /usr/IBMWPO/responseFiles/wpsSilent.rsp.

Understanding the responsefile parametersTable 8-2 gives an overview of the possible parameters in the responsefile. The goal is that you copy this table and mark or insert the values that would be appropriate for your setup.

Table 8-2 Possible parameters for a WebSphere Portal response file

No. Parameter Name possible Value Description

1 wpsCfgType ext, dev Installation type for Developers (dev) will not be covered here. Would require various values for other properties as wmsNone(at No. 2), no(at No. 3), wpsadmin(at No. 20), wpsadmins(at No. 21). Always use the typical installation form (ext).

2 wmsAuthMode wmsDbOnly, wmsDbLdap, wmsCur,wmsNone

See Figure 4-30 on page 111 for a corresponding description on the options within Setup Manager. wmsNone does not install WebSphere Member Service and must not be chosen for a typical installation.

3 thirdPartyAuthMode

yes, no As external Security Manager are not covered here, we will not use this property variable.

4 thirdPartyAuthorization

none, accessmgr, siteminder

If said yes (at No. 3) for an external Security Manager, choose between Tivoli Access Manager [accessmgr] or Netegrity Siteminder [siteminder]. The value none requires no(at No. 3).

5 wasAdminNode The nodename of your WebSphere Application Server.

6 wasConfigureGlobalSecurity

yes, no WebSphere Portal requires WebSphere Application Server Security for a typical installation, so choose yes or configure manually. See also Figure 4-23 on page 103. In any case read the disclaimer at the end of this table.


7 wasLtpaPassword If said yes(at No. 6) for WebSphere Application Server Security, a value for the LTPA password is required.

8 wasLtpaConfirmPassword

required to be equal with 7

9 ldapType swd, domino, iplanet, activated

Choose between SecureWay Directory (swd), Lotus Domino (domino), iPlanet LDAP Server (iplanet) and Microsoft Active Directory (actived) as LDAP Server. Using OpenLDAP you would choose swd. See also Figure 8-12 on page 596.

10 ldapServer The fully qualified hostname of your LDAP Server. See also Figure 8-12 on page 596.

11 ldapPortNumber The port number, the LDAP Server is accepting requests. Usually 389.

12 ldapUser The full name of the LDAP Administrative DN. See also Figure 8-12 on page 596 and Section “LDAP” on page 64.

13 ldapPassword The password of the LDAP Administrative DN.

14 ldapSuffix The base LDAP Suffix or branch to be used for WebSphere Portal. See also Section “LDAP” on page 64.

15 ldapCfgMode default, extended For silent installation it is recommended to leave this property value out or choose extended.

16 ldapUserPrefix The User DN prefix (See page 67)

17 ldapUserSuffix The User DN suffix (See page 67)

18 ldapGroupPrefix The Group DN prefix (See page 67)

19 ldapGroupSuffix The Group DN suffix (See page 67)



20 ldapAdminUser The full LDAP name of the WebSphere Portal Admin user.

21 ldapAdminGroup The full LDAP name of the WebSphere Portal Admins group

22 ldapUserObjectClass

The User Object Class (see page 66). Should be always inetOrgPerson or a schema, that includes inetOrgPerson.

23 ldapGroupObjectClass

The Group Object Class (see page 67)

24 ldapGroupMember The Group Member (see page 67)

25 dbType db2, oracle Choose between DB2 Universal Database(db2) and Oracle(oracle) as database server. For oracle, you do not have the options of create(at No. 26) and createWms(at No. 34).

26 dbCreateMode create, initialize, use

Create and Initialize a new database (create), Initialize an existing database (initialize) or Use an existing and initialized database (use) for the WebSphere Portal database. See also Figure 8-14 on page 598.

27 dbUser Local instance user name and database user that will be used to connect to WebSphere Portal database.

28 dbPassword Password of the database user.

29 dbConfirmPassword

requires to be equal with 28.

30 dbName Alias name of the WebSphere Portal database.

31 dbDriver Java driver used to connect to the database. Usually COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource with DB2 and oracle.jdbc.pool.OracleConnectionPoolDataSource with Oracle.



32 dbBaseUrl JDBC URL, that is used to access database. Usually jdbc:db2 with DB2 and jdbc:oracle:thin:@HOST:1521 with Oracle.

33 dbLibPath Local operating system PATH to the location of the JDBC2 driver.

34 wmsDbCreateMode

createWms, initializeWms, useWms

Create and Initialize a new database (createWms), Initialize an existing database (initializeWms) or Use an existing and initialized database (useWms) for the WebSphere Portal database. See also Figure 8-16 on page 600.

35 wmsDbName Name of the WebSphere Member Service database.

36 wmsDbUser Database user name that will be used to connect to database and Local instance user name.

37 wmsDbPassword Password of the database user.

38 wmsDbConfirmPassword

requires to be equal with No. 37.

39 wmsDbDriver Java driver used to connect to the database. Usually COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource with DB2 and oracle.jdbc.pool.OracleConnectionPoolDataSource with Oracle.

40 wmsDbBaseUrl JDBC URL, that is used to access database. Usually jdbc:db2 with DB2 and jdbc:oracle:thin:@HOST:1521 with Oracle.

41 wmsDbLibPath Local operating system PATH to the location of the JDBC2 driver.



Important information regarding WebSphere Application Server Security:

� If you choose No for wasConfigureGlobalSecurity (No. 6 of Table 8-2), you have to configure Security manually before starting the installation. Do not forget to also set the Admin-Role in the WebSphere Application Server Security Center.

� If you choose Yes for wasConfigureGlobalSecurity (No. 6 of Table 8-2), you have to keep in mind that the installation will look as though it failed and you have to set the Admin-Role and import the WebSphere Portal resources manually after installation.

� If you choose Yes for wasConfigureGlobalSecurity (No. 6 of Table 8-2) and you have never had enabled Security before in your WebSphere Application Server, make sure you use the same LTPA password as you did in your last setup.

42 wpsHostName The fully-qualified hostname of the server, where WebSphere Portal is supposed to be accessed. See also Figure 8-11 on page 595.

43 wpsBaseHome The Base URI for the WebSphere Portal Application. See also Figure 8-11 on page 595.

44 wpsDefaultHome The last URI part of the Home Page for the public pages. See also Figure 8-11 on page 595.

45 wpsPersonalizedHome

The last URI part of the Home Page for the customized user pages. See also Figure 8-11 on page 595.

46 wpsProxy Hostname of a Proxy, that will be used to request contents from a different network.

47 wpsProxyPort Port of the Proxy defined in No. 46.

48 wpsCfgBasePortlets

true, false Decide, if the installer should deploy(true) the base Portlets, that come with the product or not (false).

49 product.installLocation

Local operating system PATH to where the WebSphere Portal code should be copied to. Please note, that this property parameter has not the CfgProps prefix (see last line of Example 8-7 on page 651).



Be careful with your WebSphere Application Server Security settings, as many installations fail due to such configuration problems.

Building up the responsefileExample 8-7 shows the responsefile that is used for this sample installation.

Note the four lines that start with -W at the beginning of Example 8-7. They are required. Otherwise, the WebSphere Portal Installer will not read some property values.

Please note that all but the last property parameter do have the prefix -P CfgProps.. The order of the properties is not important.

Do not forget the -silent switch (first line of Example 8-7).

Example 8-7 Response file for WebSphere Portal

-silent-W LdapDefaultSequence.active=false-W SetExtLdapDefaults.active=false-W SetDefaultInput.active=false-W SetDBDefaultInput.active=false-P CfgProps.wpsCfgType="ext"-P CfgProps.wmsAuthMode="wmsDbLdap"-P CfgProps.wasAdminNode="m10df4ff"-P CfgProps.wasConfigureGlobalSecurity="yes"-P CfgProps.wasLtpaPassword="ltpapwd"-P CfgProps.wasLtpaConfirmPassword="ltpapwd"-P CfgProps.ldapType="swd"-P CfgProps.ldapServer="m10df55f.itso.ral.ibm.com"-P CfgProps.ldapPortNumber="389"-P CfgProps.ldapUser="cn=ldapadmin"-P CfgProps.ldapPassword="ldapadmin"-P CfgProps.ldapSuffix="ou=itso,o=ibm,c=us"-P CfgProps.ldapUserPrefix="uid"-P CfgProps.ldapUserSuffix="cn=users,ou=itso,o=ibm,c=us"-P CfgProps.ldapGroupPrefix="cn"-P CfgProps.ldapGroupSuffix="cn=groups,ou=itso,o=ibm,c=us"-P CfgProps.ldapAdminUser="uid=wpsadmin,cn=users,ou=itso,o=ibm,c=us"-P CfgProps.ldapAdminGroup="cn=wpsadmins,cn=groups,ou=itso,o=ibm,c=us"-P CfgProps.ldapUserObjectClass="inetOrgPerson"-P CfgProps.ldapGroupObjectClass="groupOfUniqueNames"-P CfgProps.ldapGroupMember="uniqueMember"-P CfgProps.dbCreateMode="initialize"-P CfgProps.dbType="db2"-P CfgProps.dbUser="wpsuser"-P CfgProps.dbPassword="wpsuser"-P CfgProps.dbConfirmPassword="wpsuser"


-P CfgProps.dbName="wps"-P CfgProps.dbDriver="COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource"-P CfgProps.dbBaseUrl="jdbc:db2"-P CfgProps.dbLibPath="/home/wpsuser/sqllib/java12/db2java.zip"-P CfgProps.wmsDbCreateMode=initializeWms-P CfgProps.wmsDbName="wms"-P CfgProps.wmsDbUser="wpsuser"-P CfgProps.wmsDbPassword="wpsuser"-P CfgProps.wmsDbConfirmPassword="wpsuser"-P CfgProps.wmsDbDriver="COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource"-P CfgProps.wmsDbBaseUrl="jdbc:db2"-P CfgProps.wmsDbLibPath="/home/wasuser/sqllib/java12/db2java.zip"-P CfgProps.wpsHostName="m10df4ff.itso.ral.ibm.com"-P CfgProps.wpsBaseHome="/wps"-P CfgProps.wpsDefaultHome="/portal"-P CfgProps.wpsPersonalizedHome="/myportal"-P CfgProps.wpsProxy=""-P CfgProps.wpsProxyPort=""-P CfgProps.wpsCfgBasePortlets="true"-P product.installLocation="/usr/WebSphere/PortalServer"

Installing WebSphere Portal with a responsefileDuring installation, the install tool will not perform any checks. It will take your values for granted. Therefore, make very sure that they are correct.

Also ensure that your LDAP Server and WebSphere Application Server is up and running and that the DB2 instances are started.

Insert WebSphere Portal CD #7 (WebSphere Portal for Multiplatform) and issue the following commands as root user to run the installation with the created responsefile:

# mount /cdrom# cd /cdrom/wps# ./install.sh -options /tmp/silent.rsp |tee /tmp/silent.out


Figure 8-39 Resource deployment without setting the Admin-Role

Finally, the installation process will show an error as shown in Figure 8-39, and stop. The source for the problem is the Admin-Role that could not be set during installation.

To reach a successful installation, set up the Admin-Role and then deploy the resources manually. Complete the following steps to do this.

1. Install (on a PC that allows a Graphical User Interface) the WebSphere Application Server Administrative Console (AdminConsole). It can be of any Operating System that supports WebSphere Application Server. In our example, we will use a PC with Linux OS.

2. Start the AdminConsole with the hostname and the administrative port number as parameters. In our example this would be:

# cd /opt/WebSphere/AppServer/bin# ./adminclient.sh m10df4ff.itso.ral.ibm.com 900

The default administrative port number is 900.

3. Complete all steps of the Section “Setup of Admin Role” on page 605to set the Admin-Role.

4. Close the AdminConsole.


5. Change the sas.client.props file (see “Updating sas.client.props” on page 615). This is required if you want to use XMLConfig.sh but cannot use a Graphical User Interface.

6. Restart IBM HTTP Server (see “Starting and stopping the IBM HTTP Server” on page 617).

7. Restart WebSphere Application Server (see “Starting and stopping applications from the command line” on page 615).

8. Finish deploying the WebSphere Portal resources. Do this by issuing the following commands in a Terminal as root user:

# sh /usr/WebSphere/PortalServer/bin/xmlaccess.sh /usr/WebSphere/PortalServer/install/SetupPortal.xml wpsadmin:wpsadmin m10df4ff.itso.ral.ibm.com/wps/config 50

You will find the correct command for your installation in the fifth last line of the file /usr/WebSphere/PortalServer/install.log.

9. Test the basic installation of WebSphere Portal

Open a Web browser and enter the URL: http://<fqdn>/<base_uri>/<home_page>, where <fqdn> is the fully-qualified domain name of your server, <base_uri> is the WebSphere Portal URI prefix as defined in 43 of Table 8-2 on page 646 and <home_page> is the WebSphere Portal default URI suffix as defined in item 44 of Table 8-2 on page 646. That means that in our case, we use http://m10df4ff.itso.ral.ibm.com/wps/portal to get to a browser window as shown in Figure 8-41.

Note: If you want to use XMLConfig.sh in a non-graphical environment, and you have WebSphere Application Server Security turned on, you must edit the sas.client.props file as shown in “Updating sas.client.props” on page 615. Otherwise, you will be prompted with a GUI-based window that asks for a user name and password.


Figure 8-40 WebSphere Portal default page

8.4.3 Required WebSphere Portal add-onsEven your WebSphere Portal seems to be working correctly, some components are missing, compared to the installation we did with WebSphere Portal Setup Manager. These components are:

� WebSphere Personalization Server

� WebSphere Transcoding Publisher

Additionally, you might want to replace the IBM HTTP Server plugin with the improved version that comes with WebSphere Portal (see “Installing Cache Plug-In for IBM HTTP Server” on page 25).

Note: Do not stop at this point of the installation! Continue with the following chapters and then do the installation check as shown in 5.5.2, “Testing steps” on page 259.


WebSphere Personalization ServerTo install WebSphere Personalization Server correctly for WebSphere Portal, complete the following steps.

1. Insert and mount WebSphere Portal CD #4 (WebSphere Personalization for Multiplatform). Copy the WebSphere Personalization Server files to a temporary directory. To do this, open a Terminal as root user and issue the following commands:

# mount /cdrom# cp -r /cdrom/personalization /tmp#

2. Double file some directories. You can also change various PATH settings in the installation scripts, if you do not like to do this. Do not move the install scripts instead because you would run into even more PATH problems. To copy, run the following:

# cd /tmp/personalization/silent# cp -r ../utils .# cp -r ../infocenter .# cp -r ../PersSample .# cp -r ../pznload .# cp ../wasstyle.css .# cp ../*HTM .#

3. Copy necessary jar files to the lib path of your WebSphere Application Server:

# cp /tmp/personalization/utils/brbClient.jar /usr/WebSphere/AppServer/lib# cp /tmp/personalization/utils/brbServer.jar /usr/WebSphere/AppServer/lib#

4. Change to the directory of the response files:

# cd /tmp/personalization/silent/response_files/aix#

Note: We were not able to get any description of this specific HTTP Server plugin. We assume it is not possible to configure it. It is intended to give you performance improvements for static content, but it does not enhance functionality.

Especially if you already have a Caching Proxy in place, decide for yourself whether you want to use it.

Note: For the following steps, you will require around 300 MB of free space on your temporary drive (/tmp).


5. Change the bean28.appServer property line in the pzn_silent_server.txt file so that it points to the WebSphere Portal application. Therefore this line should always say:


6. Change the bean15.defaultValue property line in the pzn_silent_workspace.txt file so that it points to your wpsadmin user. Therefore this line should say:

-W bean15.defaultValue=”wpsadmin”

7. Change the bean15.sysVariableValue property line in the pzn_silent_workspace.txt file so that it points to your wpsadmin user. Therefore this line should say:

-W bean15.defaultValue=”wpsadmin”

8. Change the bean28.appServer property line in the pzn_silent_workspace.txt file so that it points to the WebSphere Portal application. Therefore this line should always say:


9. Change to the silent Installer of the WebSphere Personalization Server.

# cd /tmp/personalization/silent/aix

10.Run the Personalization Runtime installation:

# ./PznServerSilent.shfind: 0652-010 The starting directory is not valid.WASROOT = /usr/WebSphere/AppServer/JAVAVER = FOUND#

The installation might take several minutes. You will not see any output as it is printed to the file /tmp/PznServerInst.log.

11.Run the Personalization Workspace installation.

# ./PznWorkspaceSilent.shfind: 0652-010 The starting directory is not valid.WASROOT = /usr/WebSphere/AppServer/JAVAVER = FOUND#

The installation might take several minutes. In our example installation, it took 40 minutes. You will not see any output as it is printed to the file /tmp/PznWorkspaceInst.log

12.Run the installation of the WebSphere Personalization Server InfoCenter files.

# ./PznInfoCenterSilent.shfind: 0652-010 The starting directory is not valid.WASROOT = /usr/WebSphere/AppServer/


JAVAVER = FOUND#

You will not see any output as it is printed to the file /tmp/PznInfoCenterInst.log

13.Test the correct installation of WebSphere Personalization Server

Open a Web browser and enter the URL: http://<fqdn>/PersAdmin/frame.jsp, where <fqdn> is the fully-qualified domain name of your server. That means that in our case, we use http://m10df4ff.itso.ral.ibm.com/PersAdmin/adminframe.jsp to get to a browser window as shown in Figure 8-41.

Figure 8-41 Administration page for WebSphere Personalization Server

14.You can delete the temporary files after successful installation.

# cd /tmp# rm -r personalization

WebSphere Transcoding PublisherTo install WebSphere Transcoding Publisher correctly for WebSphere Portal, complete the following steps:

1. Insert and mount WebSphere Portal CD #7 (WebSphere Portal for Multiplatform). To do this, open a Terminal as root user and issue for example the command:

# mount /cdrom


2. Copy the family.rsp file to the /tmp directory:

# cp /cdrom/wtp/sun/IBMWTPadm/reloc/IBMTrans/family.rsp /tmp

3. Copy the family.script file to the /tmp directory:

# cp /cdrom/wtp/instmgr/family.script /tmp

4. Change TranspubDestination property line in the family.script file so that it points to the directory where WebSphere Transcoding Publisher will be installed. In our example, it would be:

TranspubDestination=/usr/IBMTrans

5. Change PackageJavaHome property line in the family.script file so that it points to the Java Home Path of the WebSphere Application Server installation. In our example it would be:

PackageJavaHome=/usr/WebSphere/AppServer/java

6. Change to the directory of the WebSphere Transcoding Publisher Install Manager in your Terminal window:

# cd /cdrom/wtp/instmgr

7. Set the DISPLAY environment variable to a fake value. A reasonable setting is:

# export DISPLAY=:0.0

or

# export DISPLAY=anyotherserver:0.0

If this does not work with your environment, you have to find a way that is best for your environment.

The installation will not display any graphical window. The Installer routine, however, will check whether it could display a graphical user interface.

If your setup is not correct, the next step will not do anything, but only produce an empty /tmp/IBMTransTrace.log file or stop before installation with a Java exception.

8. Perform the basic installation of WebSphere Transcoding Publisher, using the command:

# ./instaix.sh /p /tmp/family.script

The installation might take several minutes. You will not see any output as it is printed to the file /tmp/IBMTransTrace.log.

Note: Unfortunately, it is not possible to use smitty for installation instead of the install tool, as the install tool creates required jar files during its installation process.


9. Change to the directory where WebSphere Transcoding Publisher was installed. This is the directory that you provided in the TranspubDestination property value. In our example that is:

# cd /usr/IBMTrans

10.Configure your WebSphere Transcoding Publisher installation for usage with WebSphere Portal

# ./SetupWizard.sh -d -f /tmp/family.rsp

The installation might take several minutes. You will not see any progress. However, you can check the tracefiles of WebSphere Portal since it will restart the Application several times.

11.To test the correct installation of WebSphere Transcoding Publisher, use the Web Clipping Portlet as described in the IBM Redbook WebSphere Portal Volume 3, SG24-6921. Web Clipping makes extensive use of the WebSphere Transcoding beans, so it is a good proof for a correct installation.

8.5 Changing passwordsThis section is intended to show how to change some passwords after installation.

8.5.1 Change password for wpsadminIn this section, we show how to change the password for the wpsadmin user, which is by default wpsadmin. We highly recommend that you change it. Therefore, complete the following instructions:

1. Use any Web browser to go to the WebSphere Portal page. In our sample setup that would be:http://m10df55f.itso.ral.ibm.com/wps/myportal

2. Log in as wpsadmin user.

3. Click Edit my profile, which is located in the upper right corner of the Portal Web page. You will see a window similar to Figure 8-42.

Note: The password change was applied to the users installed during this sample installation. Even though your users may be named differently, the same rules apply.


Figure 8-42 Personal Setup of any user can be change, including the wpsadmin user

4. Enter your new password in the Password and Confirm Password fields. Click Continue to set the new password.

8.5.2 Change password for wpsbindIn this section, we show how to change the password wpsbind user. To change it, complete the following instructions:

1. Start the AdminConsole.

2. Go to the Security Center.

3. Go to the Authentication tab and change the value of the field Security Server Password as seen in Figure 8-43.

Important: Do not click OK or Apply yet!


Figure 8-43 Setting a new password for the Security Server ID

4. Start the Directory Management Tool (DMT). You will see a window similar to Figure 8-44.


Figure 8-44 Open the LDAP directory tree, find and select the wpsbind user

5. Rebind as Administrative User, which would be in our sample installation cn=ldapadmin

6. Browse the directory tree for the user wpsbind, select it and click Edit (see the red circle in Figure 8-44). Next, you will see a window similar to Figure 8-45.

Tip: You can start the DMT on a remote machine, such as a Linux or Windows PC and then connect to the machine where SecureWay Directory Server is installed. To do this, click the Add Server button in the lower left corner.

DMT does not support usage of a Remote Display.


Figure 8-45 Edit the LDAP entry of the user wpsbind

7. Go to the end of the list in the window and change the value in the userPassword field. Click OK to set the new value. You can close the DMT, as it is not required any more.

8. Change back to the window of the Security Center in the AdminConsole (see Figure 8-43). Click Apply to set and validate the new password.

9. Stop the WebSphere Application Server node.

10.Update your sas.client.props, if you have changed it manually.

11.Start the WebSphere Application Server and the WebSphere Portal, for example as described in “Starting and stopping applications from the command line” on page 615.

8.5.3 Change password for the DB2 user wasuserIn this section, we provide an example of changing the wasuser password. The user, wasuser, was used during installation as the DB2 instance for all databases. Complete the following instructions:

1. Change the user password on the AIX operating system.

Open a Terminal as root user and change the password of the wasuser as shown below:

# su - wasuser$ passwdChanging password for “wasuser”


wasuser’s Old password:wasuser’s New password:Enter the new password again:$ exit#

2. Change the database password for WebSphere Application Server.

This procedure includes two steps: changing the admin.config file of WebSphere Application Server and changing the password in the appropriate DataSources inside WebSphere Application Server.

a. Make sure WebSphere Application Server is not running.

b. Create a file (for example /tmp/filename) with a single line:

com.ibm.ejs.sm.adminServer.dbpassword=newpassword

c. Run the following command:

java -classpath /usr/WebSphere/AppServer/lib/security.jar com.ibm.ws.security.util.PropFilePasswordEncoder /tmp/filename com.ibm.ejs.sm.adminServer.dbpassword

d. Replace the line that starts with com.ibm.ejs.sm.adminServer.dbpassword in the file /usr/WebSphere/AppServer/bin/admin.config with the line in the changed file /tmp/filename.

e. Start the WebSphere Application Server.

f. Start the AdminConsole of WebSphere Application Server.

g. To change the password for the Pers DataSource that is required by WebSphere Personalization Server, open the folder Resources, then the folder JDBC Providers and then the Pers DB Driver folder. Click Data Sources folder to view a window similar to Figure 8-46.

Note: This will not only change the Unix password of this user, but also alter the password used to connect to the databases.


Figure 8-46 Changing the password for the Personalization Data Source

h. To change the password of the Pers DataSource.

Change the value in the field password and click the Test Connection button (see Figure 8-46). If you issued the correct password, a pop-up window will tell you that the connection was successful.

i. Click Apply.

j. You might want to run the same procedure for the Sample DB Driver, even though this is not required to run WebSphere Portal.

k. Close the AdminConsole.

3. Change the database password for WebSphere Portal.

The primary source that WebSphere Portal uses to look up the password is the property file <was_home>/lib/app/config/services/DataStoreService.properties, where


<was_home> is the home directory of the WebSphere Application Server. In our sample installation, that would be /usr/WebSphere/AppServer.

The values for datasource.userid and datasource.password are, by default, empty. We do not recommend changing this default setting.

– If the values are not empty, you have to change them in this property file.

– If the values are empty, you have to change the password setting in the wps40DS DataSource of WebSphere Application Server.

To do so, follow these steps:

i. Start the AdminConsole of WebSphere Application Server.

ii. Make sure the WebSphere Portal application is not started.

iii. Open the folder Resources, then the folder JDBC Providers and after that the wps40JDBC folder. Click Data Sources and you will see a window similar to Figure 8-47.

Figure 8-47 Change the password for accessing the WebSphere Portal database


iv. Select wps40DS and change the value in the field password then click the Test Connection button. If you issued the correct password, a pop-up window will tell you that the Connection was successful.

v. Click Apply.

vi. Close the AdminConsole.

4. Change the database password for WebSphere Member Services.

You cannot change the password for the database WebSphere Member Services uses by updating the database properties in the proper WebSphere Application Server Data Resource.

The password for the database is an encrypted value in the field DBUserPwd that can be found in the file <was_home>/lib/app/xml/wms.xml, where <was_home> is the home directory of WebSphere Application Server.

Incidentally, the database user ID and password are also defined in the deployed Enterprise Java Bean. To make the password change happen, you will need to remove these entries.

There are three steps required to update the password:

a. Create a new encrypted value by using a command as root user as shown here:

# cd /usr/WebSphere/PortalServer/bin# ./wms_encrypt.sh newpasswordIBM*Licensed Materials - Property of IBM5697-A16(C) Copyrights by IBM and by other(s) 1978, 1997. All Rights Reserved.* Trademark of International Business Machines Corp.ASCII encrypted string : o78nO8D0o8nfEdlaGcU9fw==HEX encrypted string : 6F37386E4F3844306F386E6645646C614763553966773D3D#

b. Replace the old value of DBUserPwd in wms.xml with the new generated ASCII value. Use an editor such as vi to do this. The commands may look like the following:

# cd /usr/WebSphere/AppServer/lib/app/xml# vi wms.xml-> use Editor to replace the old value with the new one and save# grep DBUser wms.xml

Note: If WebSphere Member Services uses the same database user as we have in our sample installation, make sure you also change the passwords for WebSphere Member Services as described below before starting the WebSphere Portal application.


DBUserID="wasuser" DBUserPwd="o78nO8D0o8nfEdlaGcU9fw=="#

c. Remove the user name/password entries in the installed Enterprise Java Beans (EJB) of WebSphere Member Service.

i. Start the WebSphere Application Server AdminConsole.

ii. Open the Enterprise Applications folder, then the WebSphere Member Subsystem folder and click the EJB Modules folder.

iii. Click WCSCommon EJB and select the General tab. A window will appear, as shown in Figure 8-48.

Figure 8-48 Removing the UserId and Password entries in the WebSphere Member Service

iv. Remove the user ID and password stated there and click Apply.

v. Click WCSServer EJB, remove the user ID and password and click Apply.

vi. Click WCSUser EJB, remove the user ID and password and click the Apply button.

vii. Ensure that the wmsDS has the correct password.


Open the folder Resources, then the folder JDBC Providers, and after that the wps40JDBC folder. Click Data Sources to get to a window as shown in Figure 8-47 on page 667.

Select wmsDS, retype the password for the database user in the field password and click the Test Connection button. If you issued the correct password, a pop-up window will tell you that the Connection was successful.

viii.Click Apply and close the AdminConsole.

8.5.4 Change password for LDAP Admin user cn=ldapadminIn this section, we provide an example of changing the ldapadmin password.

Two steps are required to change the password of your Administrative Distinguished Name (DN) of your SecureWay Directory Server. First is to update the password in the LDAP Server itself, the second is to update that password in the settings of WebSphere Member Service.

1. Change Administrative DN password in SecureWay Directory Server.

a. Start as root user the IBM SecureWay Directory Configuration Utility by using the command ldapxcfg. If you are unable to use graphical tools, use ldapcfg instead.

Figure 8-49 Set or change the Administrative DN for SecureWay Directory

Note: If you do not have SecureWay Directory, but another LDAP Server, refer to the documentation of this product on how to change the password for the Administrative user.

Make sure WebSphere Portal is not running during configuration change.


b. Select Set the directory administrator name and password as shown in Figure 8-49 and click Next.

Figure 8-50 Insert a new password for the LDAP Administrative DN

c. Figure 8-50 has the current Administrative user inserted in the Administrative DN field. Make sure the field includes what you expect. For our example, the correct value is cn=ldapadmin.

d. Insert your new password in both the Administrator Password field and the Type the password again to confirm field as shown in Figure 8-50. Click Next to continue.

e. A summary of the actions you intend to set up will appear. Click Configure to execute the changes.

Figure 8-51 Information window in LDAP Configuration Utility about the setup change


f. A window as shown in Figure 8-51 informs you as to whether your setup changes were applied successfully.

g. Close the SecureWay Directory Configuration Utility.

h. Stop and start the SecureWay Directory Server. For instructions, see “Stopping and starting SecureWay Directory” on page 618.

2. Change the Administrative DN password for WebSphere Member Services.

To change the password of the Administrative DN user in the WebSphere Member Service configuration you will need to update the file <was_home>/lib/app/xml/wms.xml, where <was_home> is the home directory of WebSphere Application Server.

The password for the database is an encrypted value in the field LdapAdminPW.

There are two steps required to update this password value:

a. Create a new encrypted value by issuing a command as root user as shown below:

# cd /usr/WebSphere/PortalServer/bin# ./wms_encrypt.sh newpasswordIBM*Licensed Materials - Property of IBM5697-A16(C) Copyrights by IBM and by other(s) 1978, 1997. All Rights Reserved.* Trademark of International Business Machines Corp.ASCII encrypted string : o78nO8D0o8nfEdlaGcU9fw==HEX encrypted string : 6F37386E4F3844306F386E6645646C614763553966773D3D#

b. Replace the old value of LdapAdminPW in wms.xml with the new generated ASCII value. Use an editor such as vi to do this. The commands may look like the following:

# cd /usr/WebSphere/AppServer/lib/app/xml# vi wms.xml-> use Editor to replace the old value with the new one and save# grep LdapAdmin wms.xml LdapAdminDN="wasuser" LdapAdminPW="o78nO8D0o8nfEdlaGcU9fw=="#

Note: The change of the Administrative DN password will take effect when you start the SecureWay Directory Server again.


8.5.5 Change password for the users ldapdb2, ldapThese users currently have no password and they are not allowed to log in. This is a secure and reasonable default value. Setting up a password with the standard Unix command passwd does not hurt functionality.

8.5.6 Change password for the users db2as, db2fenc1, db2inst1The default password of these automatically generated users is ibmdb2. We highly recommend that you change these values. To do so, log in as the appropriate user and change the password as shown in the example below:

# su - db2as$ passwdChanging password for “db2as”db2as’s Old password:db2as’s New password:Enter the new password again:$ exit#

8.5.7 Change password for the user httpdTo change the password for the IBM HTTP Server (IHS) user, you have to make two configuration changes. One is to change the Unix user password, and the other is to change the IHS Administrator password. The changes can be done independently of one another.

� Change the password in the Unix environment

Log in as httpd user and use the passwd command as shown in the example below:

# su - httpd$ passwdChanging password for “httpd”httpd’s Old password:httpd’s New password:Enter the new password again:$ exit#


� Change the password for the IHS Administrator

Use the following command as root user to change the password for the Administrator, that is, in our example, the user httpd.

# /usr/HTTPServer/bin/htpasswd -m /usr/HTTPServer/conf/admin.passwd httpdNew password:Re-type new password:Updating password for user httpd#

8.5.8 Change LTPA password of Application Server Security

Keep in mind that if you change the LTPA password, your exported LTPA Security keys are no longer valid. That is because changing the LTPA password requires regenerating the Security keys.

Figure 8-52 Setting a new LTPA Password by generating new security keys

To change the LTPA Password, complete the following steps:

1. Open the AdminConsole and from there, open the Security Center.

2. Click the Authentication tab to get a window as shown in Figure 8-43 on page 662.

3. Click the Generate Keys button that is located in the center of the window.

4. You will get a pop-up window as shown in Figure 8-52. Insert a new LTPA password, confirm it, and click OK.

5. Restart WebSphere Application Server by stopping the node.


Chapter 9. Performance

This chapter shows different ways to improve performance in a WebSphere Portal environment.

9.1 Configuration of WebSphere PortalWebSphere Portal can be configured to handle your workload, environment and architecture. This section describes specific modifications that can be made to WebSphere Portal to improve performance.

9.1.1 Modifying property filesThe following table describes the properties in WebSphere Portal that may affect performances. The property files listed are located at <was-root>/lib/app/config/services, unless otherwise specified.

9

Note: Changes to the property files will not take place until WebSphere Application Server is restarted.


Property Description Property Filename

public.expires Determines cache expiration time (in seconds) for the unauthenticated portal page. Increase the cache time if the unauthenticated page does not rely heavily on up-to-date information.

NavigatorServices.properties

accesscontrol.maxcacheage

Determines the maximum cached age of ACL permissions. If the system does not require that users immediately have access added or revoked to portlets, you can increase this value.

AccessControlService.properties

persistent.session.option

Determines whether the user gets the option to resume the session. The default value of '2' allows a user to resume an existing session. This function, however, hurts performance as WebSphere Portal must write the user’s state to its database when the user logs our or the user’s session timeouts.

ConfigService.properties

default.intervalbucket.<name>.interval

Determines the interval (in seconds) to refresh one of the listed buckets. Buckets include items such as skins, themes, clients and components. If a bucket does not have an associated interval, the default will be used. The respective bucket’s information will be read from the cache until the time interval has elasped. If there are certain buckets that are not changed often, you may want to increase the interval to reduce the amount of database reads. For example, if you will not modify the skins, set the interval very high.

RegistryService.properties

services.PortletRegistry.refreshRate

Controls the time of a total refresh of the PortletDescriptor and ApplicationDescriptor cache in seconds.

JetspeedResources.propertiesa

uri.requestid This option determines the support of URL addressability. URL addressibility allows users to bookmark specific portal pages. To set URL addressability on, set this property to false, which means Ids are not requested.If users do not need to bookmark pages, set the value to false for improvement gains.

ConfigService.properties


9.1.2 Managing portal loggingThe portal must consider the amount of logging performed in a high workload or production environment. Tradeoffs must be made between the amount of logging needed during production and the overhead of logging.

The administrator can configure the amount of message logging and trace logging. These values can be configured in the <was_root>\lib\app\config\jlog.properties file, where <was_root> is the WebSphere Application Server root directory. All message loggers are enabled by default. Settings in this file are applied whenever the portal is running.

WebSphere Portal maintains logs for WebSphere Portal and logs for Site Analyzer. The WebSphere Portal logs are stored in while the site analysis log files are located at <wp_root>\log\sa_<date>_<time>.log where <wp_root> is the Portal Server root directory and <date> and <time> represent the time the file was created.

For maximum performance, the portal should minimize the amount of logging. The following table describes which trace logger to use for a given problem.

services.PortletInvoker.useparallelrendering2

Allows portlets on the page to be rendered concurrently depending on the level of mode used, and thus increase performance. There are several modes for parallel portlet rendering. 9.2.2, “Administration of portlets” on page 682 describes the details. To allow support of parallel portlet rendering for a particular portlet, enable the parallel parameter in the portlet’sportlet.xml file to true. Configuring individual portlets for parallel portlet rendering is discussed in 9.2.1, “Programming portlets” on page 680.

JetspeedResources.propertiesb

a. The portlet registry settings are located in the Jetspeed.properties file in<wp_root>/app/wps.ear/wps.war/WEB-INF/conf directory.b. The portlet registry settings are located in the Jetspeed.properties file in<wp_root>/app/wps.ear/wps.war/WEB-INF/conf directory.

Property Description Property Filename

Chapter 9. Performance 677

Trace logger When to use Additional Comments

AccessControlTraceLogger Enable this tracer if you want permissions for resources to be explained in detail, need to verify the correctness of a permission, or need to isolate a defect in access control.

The traces are easier to evaluate while the portal usage is low.

AggregationTraceLogger Enable these messages if you want to get more information on how places and pages are constructed, need to verify place lists and page lists displayed on the portal page for correctness, or need to isolate an error in the portal page aggregation component.

The traces are easier to evaluate while the portal usage is low.

CommandTraceLogger Use to turn on all command trace loggers.

EngineTraceLogger Use to enable all engine trace loggers.

EngineCommandsTraceLogger Use to diagnose problems with logging in, enrollment, and portal navigation.

EngineTemplatesTraceLogger Use to diagnose problems with internationalization and selecting device-dependent templates.

EngineTagsTraceLogger Use to diagnose problems with tags within Java Server Pages.

PortletTraceLogger Use to diagnose problems with portlets. Enables tracing for all portlets. Therefore, place the suspect portlet on a separate page for testing.

SSOTraceLogger Use to turn on all SSO tracer loggers listed after this trace logger.

Use this logger if errors occur when use the Security Vault task on the Security page of the Portal Administration pages.


To remove tracing for a particular logger, modify the file <was_root>\lib\app\config\jlog.properties. Each logger will have an entry that will look similar to :

Example 9-1 jlog.properties

basegroup.<messageloggername>.parent=MessageLoggerbasegroup.<messageloggername>.isLogging=true

basegroup.<traceloggername>.parent=TraceLoggerbasegroup.<traceloggername>.isLogging=true

To shut off logging, change the value from true to false. The message logger handles the logging of messages, while the trace logger is used for traces. You must restart the WebSphere Application Server for the changes to take place.

Administrators may only want to enable tracing and messaging for a particular session. This allows them to track their messages, without interference from other sessions. This can be a.ccomplished by Enable Tracing as discussed in

SSOVaultServiceTraceLogger Use to turn on all SSO tracer loggers listed after this trace logger.

Use this logger if you are developing a portlet that uses the vault and credential services.

SSOCredentialVaultTraceLogger Use to diagnose tracing for credentials. Use this logger if you are developing a vault adapter.

CommandCredentialVaultTraceLogger Use to trace the command API that interfaces with the vault and credential services. Those commands are issued by the portal configuration interface and the portlets that support the Security Vault task in the Portal Administration pages.

UMTraceLogger Use to trace problems with the user subsystem, such as problems with logging in, enrollment and access control.

SiteAnalyzerLogTraceLogger Use to trace problems with logging site analysis logging data for the portal.

Trace logger When to use Additional Comments


the Enable Tracing section documented in the IBM Redbook IBM WebSphere Portal V4.1 Volume 2, SG24-6920.

For additional information on logs, please see:

http://www7b.software.ibm.com/wsdd/zones/portal/V41InfoCenter/InfoCenter/wpf-ena/en/InfoCenter/wps/trouble.html#portal_log

9.2 Improving portlet performancePortlets are applications that the portal aggregates together to create a portal page. Typically, multiple portlets are invoked to a given portal page. The portlet provides a portion of the markup that is aggregated with the markup of other portlets to build the portal page.

This section describes programming and administrative options to increase the performance of portlets.

9.2.1 Programming portletsThe following are tips for portlet developers:

� Portlets are servlets and share a limited number of threads for processing. It is important that portlets complete their tasks as quickly as possible. Portlets should limit:– Synchronized methods– Expensive String operations– Long loops– Creation of many small objects– Instance variables

Additional tips are available at:

http://www-3.ibm.com/software/webservers/appserv/ws_bestpractices.pdf

� Consider carefully where state information is held. Do not place information that may be stored in PortletConfig in objects such as PortletData because it will create replicated information.

� Portlets on the unauthenticated page should not use sessions. Each request to the unauthenticated page requires a new session, even if the user has visited the page before.

� PortletSession should only store transient information that is essential for the portlet’s session. All objects in the portlet session will be serialized to the database if the application is configured for failover.




� The PortletLog class should be used to write message and trace information to logs, rather than using native calls to System.out.println or System.err.println. Log files are maintained in wp_root/log directory.

� PortletLog supports writing messages and trace information to four separate logs: debug(), info(), error() and warn(). Logs should be nested to write messages based on the level of the tracking message to avoid needless logging. An example is shown in Example 9-2.

Example 9-2 Code to write to logger file

if( getPortletLog().isDebugEnabled() ) { myLogRef.debug("Warning, Portlet Resources are low!"); }

� A portlet container can provide per portlet cache that stores the content of a portlet. The portlet can be cached based on the configuration in the portlet’s deployment descriptor (portlet.xml). The portlet can be configured as a shared or unshared cache. The expiry of the cache can be configured.

Do not use caching if the output of the of the portlet is very small. The overhead of executing DynaCache compared to the cost of rendering the small amounts of locally-stored content is too great for any substantial benefits to be derived.

Do not use caching if the portlet requires real-time data.

� Portlets may be rendered in parallel for improved performance, as long as they are thread-safe. By default, the portal is configured to render portlets in parallel, however, individual portlets are configured not to be rendered concurrently. This configuration is stored in a portlets deployment descriptor. Setting this parameter in the <concrete-portlet> tag of the portlet deployment descriptor.

Example 9-3 Setting parallel rendering parameter in portlet.xml

<config-param><param-name>parallel</param-name><param-value>true</param-value>

</config-param>

However, note that portlets must be thread-safe to be rendered in parallel; for example, portlets that access protected resources or which use Enterprise Java Beans may not be run in parallel..


9.2.2 Administration of portletsSeveral considerations should be made by the portal administrator, such as the following.

� If possible, do not add particularly slow portlets on the default page. By placing slow portlets on separate pages, they will only be rendered when the user specificially requests that page.

� Where possible, use portlet caching. The rules for portlet caching is in the web.xml file.

To change the main setting for a portlet to parallel rendering, an administrator can use the Manage portlets tab in Portal Administration and change the value of the parallel parameter to true, rather than modifying the portlet.xml file and importing the portlet. If the property does not exist, you can add it.

The main properties for parallel portlet rendering are arranged in a decision tree as follows:

services.PortletInvoker.useParallelRendering acts as the main switch for parallel portlet rendering.

If is set to true, the services.PortletInvoker.parallelRenderingMode determines how the portlet will be rendered.

Value Description

false No parallel rendering

true Parallel rendering controlled by services.PortletInvoker.parallelRenderingMode

Value Description

0 Forced parallel rendering mode. All portlets that can be rendered concurrently are in fact rendered concurrently.

1 Defensive portlet rendering mode. All portlets that can be rendered concurrently are rendered concurrently only if the rendering time is above the specified portletRenderTimeMark, or if the current workload of the threadpool is below the specified threadpoolWorkloadMark


9.3 CloningWebSphere Portal can improve performance by utilizing WebSphere Application Servers’ ability to create clones. Clones are copies of an application server (such as WebSphere Portal) and its contents.

Clones can be implemented horizontally or vertically. Horizontally cloning distributes workload by creating clones on separate machines. This is appropriate when multiple, less powerful machines are available. Vertical cloning improves performance by creating clones of the WebSphere Portal application server on a single, high-powered machine. This is useful when a system cannot utilize all system resources, such as the CPU.

For examples on cloning WebSphere Portal, see the WebSphere Develop Domain Library at http://www7b.software.ibm.com/wsdd/library/ and search on cloning. The article is titled Cloning WebSphere Portal Version 4.1 for Failover and Scalability.

9.4 Tuning WebSphere Portal componentsTuning your WebSphere Portal environment for optimal performance requires monitoring and testing WebSphere Portal and the components of WebSphere Portal. The exact values for tuning are specific to your architecture and environment.

Here are some recommended resources for configuring WebSphere Portal components:

2 Defensive page rendering mode. All portlets that can be rendered concurrently are rendered concurrently only if the sum of all estimated portlet rendering times is above the specified pageResponseTimeMark, or if the current workload of the threadpool is below the specified threadpoolWorkloadMark.

Value Description


http://www7b.software.ibm.com/wsdd/library/

Additional Redbooks are available at:


Resource Location

WebSphere and DB2 Performance Tuning Guide

http://www.redbooks.comSearch for SG24-6417-00 to find the redbook.

WebSphere Application Infocenter

http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/Tuning documents are accessible by navigating through the left hand navigation menu.

Cloning WebSphere Portal Version 4.1 for Failover and Scalability

http://www7b.software.ibm.com/wsdd/library/Go to the above URL and search for Cloning WebSphere Portal Version 4.1 for Failover and Scalability


http://www.redbooks.com





http://www7b.software.ibm.com/wsdd/library/


Chapter 10. Problem determination

This chapter focuses on the functions provided by WebSphere Portal to facilitate problem determination, for example, logging and tracing.

10.1 Testing your WebSphere Portal installation

10.1.1 Hello WorldInstall and test the Hello World portlet developed in the IBM Redbook IBM WebSphere Portal V4.1 Handbook Volume 2, SG24-6920. See the Portlet Development chapter.

10.1.2 New userIn order to test your WebSphere Portal installation to make sure the install has been successful, you can perform a simple test of creating a user and then making sure you can log in with that user. This section walks you through that process.

1. Start by invoking the newly installed portal via the URL

http://<yourhost>/wps/portal

where <yourhost> is your fully-qualified host name. Or use the URL you have configured for your portal entry page.

10


You will be presented with the WebSphere Portal Welcome window as seen in Figure 10-1.

Figure 10-1 WebSphere Portal Welcome page

2. Start the self registration process by clicking the Sign-up icon in the upper right corner of the WebSphere Portal Welcome Page.

This will invoke the self registration page as seen in Figure 10-2.


Figure 10-2 Self Registration

3. Complete the self registration form by completing the fields. User ID, Password, First and Last names are required. This is indicated by the * in front of each required field.

For our example, we have created the fictitious user Mic Credle.

When complete, click the Continue button, . This will display the registration confirmation page as seen in Figure 10-3.

miccredle

Credle

[email protected]

Chapter 10. Problem determination 687

Figure 10-3 Self Registration Confirmation

4. Confirm your registration by again clicking .

When the registration process is complete, you will be presented with the enrollment confirmation page as seen in Figure 10-4.

miccredle

Mic

Credle

[email protected]


Figure 10-4 Enrollment Successful

Once the enrollment is successful, you can verify that the user was created in your LDAP source by examining the users. Figure 10-5 shows our new user mickymouse in the SecureWay directory.

You should see your newly created user in your LDAP source, similar to what we have seen.


Figure 10-5 New user in SecureWay after self registration

The final test of the new user is to try and log in to the Portal. The following steps walk you through logging in to WebSphere Portal.

1. Click the Log-in icon, , in the upper right corner of the portal page as seen in Figure 10-4 on page 689.

You will be presented with the WebSphere Portal Log in page as seen in Figure 10-6 on page 691.

miccredle


Figure 10-6 WebSphere Portal Login Page

2. Enter the user ID and password of your newly created user.

Click to log in to the portal.

3. A successful login will present you with the WebSphere Portal Welcome page as we have seen in Figure 10-1 on page 686, with the addition of a welcome message to the newly logged in user in the top right corner, as seen in Figure 10-7.

miccredle


Figure 10-7 Welcome for a logged in portal user

This completes the simple test you can use to make sure your WebSphere Portal installation is set up properly. By creating a new user and then logging in with that user, we are assured that the basic installation of WebSphere Portal is successful. Further detailed testing may be required, depending on the other WebSphere Portal features you have installed.

Mic Credle


Appendix A. db2admin and wasadmin user IDs

During the installation of WebSphere Portal, there are two user IDs that are created automatically, but some administrators prefer to create these user IDs manually before the installation of WebSphere Portal begins. If you prefer to create the db2admin and the wasadmin user IDs at this time, please follow the steps in the upcoming sections.

A.1 Create the db2admin user for DB2The first step in the installation is to create the required users and groups. We are creating a user ID that will act as the administrator of DB2. This process is as follows:

1. Log in as an administrator of the machine that WebSphere Portal Server will be installed on. Create a Windows 2000 user with the following settings:

– User ID = db2admin


– Member of Administrators group

A


You can create local users and assign group memberships by clicking Control Panel -> Administrative Tools -> Computer Management -> System Tools -> Local Users and Groups.

2. Assign the proper permissions to the db2admin user. This is done as follows:

a. Click Start -> Settings -> Control Panel. Double-click Local Security Policy. You will see a window similar to Figure A-1.

Figure A-1 Local Security Settings in Windows environment

b. Double-click Local Policies of the left and then double-click User Rights Assignment. You will see a window similar to Figure A-2.

ibm662e305\db2...

ibm662e305\db2...


Figure A-2 Displaying the User Rights

c. Double-click Act as Part of the operating system and select Add. This will bring up a new window that looks similar to Figure A-3. Locate the db2admin account. Select the account then click Add. Multiple accounts may be selected by holding down the Ctrl key when selecting.

Click OK when finished. Click OK again to exit the Local Security Policy Setting for Act as part of the operating system.

ibm662e305\db2...

ibm662e305\db2...

Appendix A. db2admin and wasadmin user IDs 695

Figure A-3 Selecting Users or Groups to Local Security Policy

Repeat the process for the following User Rights Assignments:


– Create a token object

– Increase quotas

– Replace a process level token

A.2 Create wasadmin for WebSphere Application ServerIn this section, we will create the user ID wasadmin. The wasadmin user will be used to run both the IBM HTTP Server and WebSphere Application Server. The remainder of this chapter assumes that wasadmin is used. Perform the following steps:

1. Create the Windows 2000 user with the following settings:

– User ID = wasadmin


– Member of Administrators group

ibm662e305ibm662e305

ibm662e305ibm662e305

ibm662e305\Administrators; ibm662e305\Administrator


You can create local users and assign group memberships by clicking

Control Panel -> Administrative Tools -> Computer Management -> System Tools -> Local Users and Groups.

2. Assign the following rights to this user:

– Act as part of the Operating System


You can assign user rights by clicking Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment.

Reboot the system to ensure that the User Rights Assignments have taken place.

Appendix A. db2admin and wasadmin user IDs 697

acronyms
L
B2B Business-to-Business

B2C Business-to-Customer

B2E Business-to-Employee

CRM Customer Relationship Management

DMT Directory Management Tool

DN Distinguished Name

DNS Directory Naming Service

DNS Domain Name Services

EJB Enterprise JavaBeans

ERP Enterprise Resource Planning

GNOME GNU Network Object Model Environment

GNU Unix-like operating system

HTML Hypertext Markup Language

IBM International Business Machines Corporation

IHS IBM HTTP Server

IIOP Internet Inter-ORB Protocol

ITSO International Technical Support Organization

J2EE Java 2 Platform, Enterprise Edition

JDBC Java Database Connectivity

JDK Java Development Kit

JRE Java Runtime Environment

JSP Java Server Pages

JVM Java Virtual Machine

KDE K Desktop Environment

LDAP Lightweight Directory Access Protocol

LTPA Lightweight Third Party Authentication

LUM License Use Management

Abbreviations and

© Copyright IBM Corp. 2003. All rights reserved.

PDA Personal Digital Assistant

RDN Relative Distinguish Name

RPM Red Hat Package Manager

SASL Simple Authentication and Security Layer

SCM Supply Chain Management

SMIT System Management Interface Tool

SSL Secure Socket Layer

URI Uniform Resource Identifier

URL Uniform Resource Locator

WCM WebSphere Content Manager

WCP Web Content Publisher

WML Wireless Markup Language

WMS WebSphere Member Services

WPS WebSphere Portal

XML Extensible Markup Language

XSLT Extensible Stylesheet Language Transformations

699

Related publications

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

IBM RedbooksFor information on ordering these publications, see “How to get IBM Redbooks” on page 703.

� IBM WebSphere Portal V4.1 Handbook Volume 2, SG24-6920

� IBM WebSphere Portal V4.1 Handbook Volume 3, SG24-6921

� IBM WebSphere V4.0 Advanced Edition Handbook, SG24-6176

� IBM WebSphere V4.0 Advanced Edition Security, SG24-6520

� WebSphere Portal V4.1 AIX 5L Installation, REDP3594

� WebSphere Portal V4.1 Windows 2000 Installation, REDP3593

� IBM WebSphere Portal V4.1.2 in a Linux Environment, REDP0319

� WebSphere Portal Collaborative Components, REDP0319

Other resourcesThese publications are also relevant as further information sources:

� WebSphere Portal Primer, ISBN: 1-931182-13-2

Referenced Web sitesThese Web sites are also relevant as further information sources:

� IBM Portal Information Kit:


� IBM WebSphere Software Platform:

http://www-3.ibm.com/software/info1/websphere/index.jsp?tab=highlights/

� IBM HTTP Server Support:




http://www-3.ibm.com/software/info1/websphere/index.jsp?tab=highlights/


� IBM WebSphere Application Server Support:


� Rpmfind.net Server

http://rpmfind.net/

� IBM WebSphere Portal Enable - InfoCenter:


� IBM WebSphere Portal Planning Worksheet:


� IBM License Use Management Web site:


� IBM WebSphere Application Server AE - InfoCenter:

http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/index.htmlu

� Microsoft Active Directory:


� IBM WebSphere Portal for Multiplatform:


� IBM DB2 Technical Support:


� WebSphere Application Server using Silent Installation on AIX:


� OpenLDAP Web site:


� AIX toolbox for Linux applications


� Using WebSphere Portal log files


� WebSphere Application Server Best Practices


702 IBM WebSphere Portal V4.1 Handbook Volume 1702 IBM WebSphere Portal V4.1 Handbook Volume 1


http://rpmfind.net/




http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/index.htmlu









� WebSphere Developer Domain - Search

http://www7b.software.ibm.com/webapp/dd/transform.wss?URL=/wsdd/library/index.xml&xslURL=/wsdd/xsl/document.xsl&format=two-column&site=wsdd

� WebSphere Portal Primer book:

http://mc-store.com/bookfromibmp.html

How to get IBM RedbooksYou can order hardcopy Redbooks, as well as view, download, or search for Redbooks at the following Web site:

ibm.com/redbooks

You can also download additional materials (code samples or diskette/CD-ROM images) from that site.

IBM Redbooks collectionsRedbooks are also available on CD-ROMs. Click the CD-ROMs button on the Redbooks Web site for information about all the CD-ROMs offered, as well as updates and formats.

Related publications 703




http://www7b.software.ibm.com/webapp/dd/transform.wss?URL=/wsdd/library/index.xml&xslURL=/wsdd/xsl/document.xsl&format=two-column&site=wsdd

http://mc-store.com/bookfromibmp.html

704 IBM WebSphere Portal V4.1 Handbook Volume 1704 IBM WebSphere Portal V4.1 Handbook Volume 1

Index

Aaccess points 13access-control data 96accesscontrol.maxcacheage 676AccessControlTraceLogger 678administration client 390administration database 102administrative DN 73administrative Group DN 119administrative group DN 73administrative user DN 65administrative user password 65, 69administrator distinguished name 305administrator DN 119AdminRole configuration 184AdminRole definition 16ADSI Edit tool 480advanced installation 89aggregation module 13AggregationTraceLogger 678AIX 39, 41–42, 573AIX 5L maintenance level 40anonymous login 131application sharing 138authentication 8, 14, 16authentication information 110authentication proxy 48authentication server 13authorization 8, 14AuthProxy 48

Bbackend proxy 49backend systems 50Base URI 115base URI 72basic user information 111BM Java Runtime Environment (JRE) 23Bourne Again Shell 41business-to-business (B2B) 1, 6business-to-consumer (B2C) 1, 6business-to-employee (B2E) 1

© Copyright IBM Corp. 2003. All rights reserved.

Ccache plug-in 25certifier ID 381certifier id file 130certifier organization 68, 130, 206certifier password 68, 130clones 683cluster 49collaborative components 2collaborative portlets 133CommandCredentialVaultTraceLogger 679CommandTraceLogger 678content organizer portlet 135CPT Toolkit Program Files 81custom user registry mode 112customer relationship management (CRM) 2customized page 73, 116customized pages 12

Ddatabase and LDAP directory mode 111database backend 120database configuration scripts 120database name 74, 122database node name 64database only mode 111database server port 64, 106–107database user 74, 122database user password 74datacenter firewall 50DB2 administration user 62DB2 connection service port 29DB2 Universal Database 20–21, 26, 41, 62, 78, 96, 160, 486DB2 user name 71DB2 user password 72db2adm) 30db2admin 16, 62–63, 69, 74db2admin user 693db2as 62, 69, 74db2inst1 16default.interval bucket.<name>.interval 676delRoute.log 150

705

development install 110directory management tool 299Directory Management Tool (DMT) 520Discovery Server 71distinguished name 429Distinguished Name (DN) 33DMZ 47DNS settings 149Domain name 206Domino 112Domino administration client 211Domino Administrator Client 438Domino Application Server 22, 128, 195Domino Clients 93Domino components 201Domino Directory 33Domino domain 130Domino Enterprise Server 22, 129Domino LDAP 33, 133, 219Domino LDAP Directory 372Domino Mail Server 22, 128Domino name 130Domino Server 378Domino Server setup 378Domino Web Engine 416Domino XML 133DynaCache 48, 681

EeFix 21, 24e-fixes 21electronic meetings 138Enable Single Sign On (SSO) 556EngineCommandsTraceLogger 678EngineTagsTraceLogger 678EngineTemplatesTraceLogger 678EngineTraceLogger 678Enterprise Information Portal Client Kit 20Enterprise JavaBeans 101Enterprise JavaBeans (EJBs) 101enterprise resource planning (ERP) 2, 50export key 200

FFull DNS name 454fully-qualified domain name 206fully-qualified hostname 115

GGlobal Security 421global security 112Global Security Toolkit 93, 202Gnome 36GNU tools 41group DN prefix 65group DN suffix 65group object class 66GroupCreator 33GroupModifier 33

HHello World portlet 685home page 72, 116host name 130hostname 63, 68, 72hosts file 149HTML 48HTTP 380HTTP Server plug-in 15httpadmin 61httpgroup 61

IIBM Caching Proxy 48IBM Content Manager 5, 20, 486IBM Cross Platform Technologies for Windows 152IBM DB2 UDB 2IBM DB2 Universal Database 8, 21, 299IBM HTTP Server 15, 21, 23–24, 38, 61, 78, 94, 159, 177, 202IBM HTTP Server (IHS) 673IBM JRE Version JDK 21IBM Lotus Collaborative Components 4IBM Lotus Collaborative Places 4IBM Lotus Extended Search 4, 22IBM Lotus QuickPlace 5IBM Lotus Sametime 5IBM SecureWay Directory 2, 8, 21, 32, 94, 112, 117, 133, 298, 309, 486, 492IBM Secureway Directory 20, 304IBM SecureWay Directory Server 162IBM Tivoli Access Manager 5IBM Tivoli Site Analyzer 4IBM Web Content Publisher 2, 9IBM WebSphere Application Server 2, 6, 15, 21IBM WebSphere Application Server V4.0, Advanced


Edition 101IBM WebSphere EdgeServer 48IBM WebSphere Everyplace Access 14IBM WebSphere Personalization 2, 20–21, 486IBM WebSphere Portable 2IBM WebSphere Portal 1, 5, 12, 15, 20–21, 72, 486

prerequisites 22IBM WebSphere Portal Enable 4IBM WebSphere Portal Experience 4IBM WebSphere Portal Extend 4IBM WebSphere Portal for Multiplatforms 1IBM WebSphere Studio Application Developer 20, 107IBM WebSphere Transcoding Publisher 14, 21IBMWPO directory 80IIOP 380, 403InfoCenter 40, 60installation key 87installation log file 526installation planning worksheet 60instant messaging 138iPlanet 112, 117, 133iPlanet LDAP 34

JJ2EE 6J2EE services 101Java 152java - version command 80Java portlets 101Java Runtime Environment (JRE) 38Java Security APIs 14Java Virtual Machine (JVM) 26JAVA_HOME environment variable 534JavaBeans 101JavaServer 101JDBC database driver 74–75, 123JDBC driver 72, 339JDBC driver library 74, 123JDBC driver location 72JDBC URL 72JDBC URL prefix 74–75, 123

KKDE 36key file 200

LLDAP 64, 380LDAP administrative user 118LDAP administrator 33LDAP configuration 99LDAP directories 578LDAP directory 37, 50, 112LDAP Directory Server 492LDAP installation directory 64LDAP protocol 16LDAP proxy host 65LDAP Realm 415LDAP Server 118, 488LDAP server 65, 73LDAP server type 117LDAP services 378LDAP source 8, 110, 113, 140, 449LDAP Suffix 100LDAP suffix 64, 504LDAP suffix information 162LDAP tree 100ldapAdminGroup 648ldapAdminUser 648ldapCfgMode 647ldapGroupPrefix 647ldapGroupSuffix 647ldapPassword 647ldapPortNumber 647ldapServer 647ldapSuffix 647ldapType 647ldapUser 647ldapUserPrefix 647ldapUserSuffix 647LDIF capabilities 484LDIF file 32, 314, 578Licence Use Management (LUM) 509license use management 21, 175License Use Management (LUM) 126License Use Management Runtime 126lightweight directory access protocol (LDAP) 2, 66, 98, 299, 301lightweight third party authentication (LTPA) 197LikeMinds 21Linux 39

WebSphere Portal 485local database alias name 63local database name 63, 105–106local database password 63

Index 707

local database user ID 63local taxable alias 105LOOPBACK 64loopback adapter 50, 148Loopback IP Gateway 150Lotus Architect 78Lotus Architect installation directory 70Lotus Collaboration 71Lotus Collaborative Components 20Lotus Collaborative components 141Lotus Collaborative Places 20, 569Lotus Communities 141Lotus Discovery Server 141, 569Lotus Domino Application Server 78, 117, 127, 136

default configuration 127LDAP Server 127Web Content Publisher 128

Lotus Domino Directory Services 8Lotus Domino LDAP directory 370Lotus Domino Server 378Lotus Extended Search 20Lotus QuickPlace 22, 141, 486Lotus Quickplace 20Lotus Sametime 20, 22, 78, 138, 141, 486, 569

complete install 139core install 139

Lotus Workflow 22, 78, 136–137LTPA file 134, 209LTPA keys file 69LTPA password 63, 69, 113, 134, 674LTPA tokens 197ltpapwd 63LUM Basic License Tool 126LUM server 126

MMember Services 27, 111, 124, 168, 174memory allocation 26Microsoft Active Directory 8, 34, 112, 117, 133, 372, 449, 451, 470Microsoft Internet Explorer 23Microsoft Internet Information Services (IIS) 24Microsoft Loopback Adapter 50, 148Mozilla 23multitier topology 79

NNetscape 23

node name 105, 107nstall 60

Ooffering

IBM WebSphere Portal Enable 1WebSphere Portal Enable 486WebSphere Portal Enable offering 2WebSphere Portal Experience 4WebSphere Portal Extend 2

offeringsWebSphere Portal offerings 19

one-tier architecture 193OpenLDAP 37, 642Oracle 8, 16, 31, 62outgoing proxy 49

Ppage aggregation 13page content 12page customization 13PDA 14performance 675permissions 96persistent.session.option 676personalized pages 12portal configuration data 96portal engine 12–13portal logging 677Portal Member Services 110portal services 13portal servlet 13Portal URL 116PortalFilter 14portal-specific data 96portlet container 681portlet performance 680PortletFilter 14PortletLog 681portlets 10, 12, 116PortletSession 680PortletTraceLogger 678PQ55941 21, 24PQ56615 21, 24PQ57024 25PQ57814 21, 24PQ58289 21, 24PQ58678 21, 25


PQ58795 21, 25PQ59932 21, 25PQ60461 25PQ60787 21, 25prerequisites 19

WebSphere Portal for AIX 39WebSphere Portal for Linux 35WebSphere Portal for Windows 2000 22

problem determination 685procedures 19property files 675proxy host 73, 116proxy hostname 117proxy port 73, 117, 433proxy server 433public.expires 676

Qquick installation 89QuickPlace Server 71

RRed Hat Linux 35, 486–487Redbooks Web site 703

Contact us xvrelational database management system 96Relative Distinguish Name (RDN) 299remote database name 106remote database user ID 106requirements 19Response file 156response file 89–90reverse authentication proxy 48reverse caching proxy 48reverse transcoding publisher proxy 48rt.jar file 194, 372

SSametime Server 71Sametime Server HTTP Port 71Secure Socket Layer (SSL) 299SecureWay Directory 32, 37, 78, 299, 578SecureWay Directory Client SDK 299SecureWay Directory console 32SecureWay Directory Server 41SecureWay Directory Server Web Admin 316security 16

WebSphere Application Server 219security services 14self registration form 687server name 68, 130services.PortletInvoker.useparallelrendering 2 677services.PortletRegistry.refreshRate 676servlets 680Setup Manager 23–24, 27, 32, 35, 59, 77–78

Advanced install 88advanced install 60DB2 Universal Database 96IBM Cross Platform Technologies for Windows 83IBM SecureWay Directory 98Installation 78installation approaches

experienced install 79installing everything at once 78installing in steps 79

Installation configuration 78installation configuration 92installation key 86pre-installation 77, 79Quick install 88quick install 60Standard install 88standard install 60type of install 77, 84WebSphere Personalization 107

Setup Manager components 94shared white boards 138simple authentication and security layer (SASL) 299single sign on 133single sign-on 48single tier topology 60SiteAnalyzerLogTraceLogger 679smitty 641SOCKS Server 117software prerequisites 85Solaris 39SSOCredentialVaultTraceLogger 679SSOTraceLogger 678SSOVaultServiceTraceLogger 679stand-alone daemon 98standard installation 89STLinks 22suffix 32supply chain management (SCM) 2

Index 709

System JVM 82System Management Interface Tool (SMIT) 43system requirements 94

TTCP/IP 56TCPIP port 65, 100temporary files 80third party authentication proxy server 13thirdPartyAuthMod 646thirdPartyAuthorization 646Tivoli Access Manager 20, 48, 486Tivoli Policy Director 20Tivoli Web Site Analyzer 20token domain 69, 134topologies 47transcoding adapter 14Trust Association Interceptor (TAI) 48tuning 683two-tier architecture 193

UUI extensions 141UI-neutral API methods 141UMTraceLogger 679UNIX 15–16UNIX DB2 instance user 16UNIX tools 41uri.requestid 676User Beans 14user data 96User DN 118user DN prefix 65user DN suffix 65user object class 65user registry directories 50

WWAS40 15was40 63wasadmin 63, 696wasAdminNode 646wasConfigureGlobalSecurity 646WASDB 16wasdb 63WASDBL 16wasdbl 63

wasLtpaConfirmPassword 647wasLtpaPassword 647WCM Content Publisher 69WCM Publish WebApp 9Web Content Publisher 20, 22, 69, 78, 128Web Content Publisher (WCP) 135WebSEAL 14, 48WebSphere Administrative Console 430WebSphere Administrative Server 180WebSphere Application Developer 2WebSphere Application Server 2, 15, 21, 24, 38, 41, 94, 163, 197WebSphere Application Server DynaCache 48WebSphere Application Server installation directory 62WebSphere Application Server node name 63WebSphere Application Server roo 71WebSphere Application Server security 219WebSphere Application Server user name 63WebSphere Application Server, Advanced Edition 78WebSphere Content Publisher 135WebSphere Develop Domain Library 683WebSphere EdgeServer 48WebSphere Everyplace Access 14WebSphere Member Services 49, 504WebSphere Member Subsystem 9WebSphere Personalization 2, 21, 23, 38, 41, 49, 70, 78, 107–108, 148, 362, 486, 496, 558, 645WebSphere Personalization Server 167WebSphere Portal 2, 15, 21, 23, 27, 38, 41, 72, 77–78, 109, 133, 168, 275, 362, 370, 449, 470, 486

AIX 573base URI 142development installation 110home page 142hostname 142installation 168Linux 485manual installation 276prerequisite products 78prerequisites 22, 155root 142Setup Manager 77–79, 83, 94, 108, 148, 176

Advanced install 89Quick install 89Standard install 89

typical installation 110WebSphere Personalization 107


WebSphere Portal architecture 7, 12WebSphere Portal Content Organizer 31WebSphere Portal Core 49WebSphere Portal Enable 1–2, 19WebSphere Portal Experience 19WebSphere Portal Extend 2, 16, 19WebSphere Portal for Multiplatform 301WebSphere Portal InfoCenter 486WebSphere Portal infrastructure 13WebSphere Portal installation overview 485WebSphere Portal log 690WebSphere Portal offerings 19WebSphere Portal operational aspects 7, 15WebSphere Portal presentation services 12WebSphere Portal root 71WebSphere Portal Setup Manager 21WebSphere Portal software topology 7–8WebSphere Portal topology 47WebSphere Site Analyzer 22, 78, 677WebSphere Studio Application Developer 78WebSphere Transcoding Publisher 14, 21, 48–49Windows 2000 Administration Tools 459Windows 2000 administration tools 459Windows 2000 support tools 458WML 48WMS 31wmsAuthMode 646wmsdb 74work area 80WPS 31WPS Enterprise Application 9WPS41 74wpsadmin 33–34, 66wpsadmins 34wpsbind 16, 33–34, 66wpsCfgType 646WPSConfig.ldif 316WPSconfig.ldif 32WPSconfig-netscape.ldif 34wpsdb 74WS Proxy 9

XX Client 41X Server 42XSLT 50X-Windows 534

Index 711

(1.0” spine)0.875”<

->1.498”460 <

-> 788 pages

IBM W

ebSphere Portal V4.1 Handbook Volum

e 1

®

SG24-6883-00 ISBN 0738428094

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICALINFORMATION BASED ONPRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information:ibm.com/redbooks

IBM WebSphere PortalV4.1 HandbookVolume 1Understand the IBM WebSphere Portal architecture

Step-by-step installation instructions for IBM WebSphere Portal

Implement new and enhanced capabilities of IBM WebSphere Portal

The IBM WebSphere Portal V4.1 Handbook is available in three volumes of Redbooks. This is volume 1.These Redbooks position the IBM WebSphere Portal for Multiplatforms as a solution that provides a single point of interaction with dynamic information, applications, processes and people to help build successful business-to-employee (B2E), business-to-business (B2B), and business-to-consumer (B2C) portals. WebSphere Portal consists of three packaged offerings:- Portal Enable- Portal Extend- Portal ExperienceIn the three volumes of the IBM WebSphere Portal V4.1 Handbook, we cover WebSphere Portal Enable and Extend.

The IBM WebSphere Portal V4.1 Handbook will help you to understand the WebSphere Portal architecture, how to install and configure WebSphere Portal, how to administer portal pages using WebSphere Portal; it will also discuss the development of WebSphere Portal portlets and how to use specific WebSphere Portal applications.

In this redbook, we discuss the installation of WebSphere Portal within the Windows 2000, Linux and AIX environments. In addition, we discuss the automated installation of WebSphere Portal using Setup Manager and manual installations.

Back cover

IBM WebSphere Portal V4.1 Handbook Volume 1

Documents

Transcript of IBM WebSphere Portal V4.1 Handbook Volume 1