WP 800

Version 8 Release 0
WebSphere Portal 8.0
ii WebSphere Portal 8.0

Contents
Overview . . . . . . . . . . . . . . 1
What's new. . . . . . . . . . . . . . . 1
Whats new for administrators . . . . . . . 1
What's new for user interface developers . . . . 5
What's changed . . . . . . . . . . . . 5
Unsupported and deprecated features . . . . . 7
Product capabilities . . . . . . . . . . . . 8
Web analytics . . . . . . . . . . . . . 9
Web content . . . . . . . . . . . . . 10
Social business . . . . . . . . . . . . 15
Integration . . . . . . . . . . . . . 19
Mobile . . . . . . . . . . . . . . . 21
Versatile framework . . . . . . . . . . 22
Documentation resources . . . . . . . . . . 26
Accessibility features . . . . . . . . . . . 28
Installing . . . . . . . . . . . . . . 31
Planning to install WebSphere Portal . . . . . . 31
System requirements . . . . . . . . . . 31
Release notes . . . . . . . . . . . . . 31
WebSphere Portal Support Statement . . . . . 32
User IDs and passwords . . . . . . . . . 34
Server topologies . . . . . . . . . . . 37
Web Content Manager environments . . . . . 54
Port assignments . . . . . . . . . . . 63
Web servers . . . . . . . . . . . . . 64
Database considerations . . . . . . . . . 66
User registry considerations . . . . . . . . 92
Cluster considerations . . . . . . . . . . 99
Virtual environment overview . . . . . . . 115
Multiple profile support . . . . . . . . . 116
Getting the software . . . . . . . . . . . 119
Physical media . . . . . . . . . . . . 119
Live repository . . . . . . . . . . . . 119
Electronic images . . . . . . . . . . . 119
Installing on AIX . . . . . . . . . . . . 145
Setting up a stand-alone production server on
AIX . . . . . . . . . . . . . . . 145
Setting up a cluster on AIX. . . . . . . . 280
Installing Web Content Manager into an existing
Server installation on AIX . . . . . . . . 460
Installing on IBM i . . . . . . . . . . . 461
IBM i . . . . . . . . . . . . . . . 462
Setting up a cluster on IBM i . . . . . . . 513
Server installation on IBM i . . . . . . . 590
Rendering documents on IBM i . . . . . . 592
Installing on Linux . . . . . . . . . . . 593
Linux . . . . . . . . . . . . . . . 594
Setting up a cluster on Linux . . . . . . . 728
Server installation on Linux . . . . . . . 909
Localizing a new virtual machine instance on
Linux . . . . . . . . . . . . . . . 910
Installing on Solaris . . . . . . . . . . . 911
Solaris . . . . . . . . . . . . . . . 911
Setting up a cluster on Solaris . . . . . . 1045
Installing Web Content Manager into an
existing Server installation on Solaris . . . . 1224
Installing on Windows . . . . . . . . . . 1225
Windows . . . . . . . . . . . . . 1225
Setting up a cluster on Windows . . . . . 1359
Installing Web Content Manager into an
existing Server installation on Windows . . . 1539
Localizing a new virtual machine instance on
Windows . . . . . . . . . . . . . 1540
Installing on z/OS . . . . . . . . . . . 1542
Enabling the IBM Subcapacity Reporting Tool 1542
Worksheets . . . . . . . . . . . . . 1543
Installing and configuring your WebSphere
Portal environment on z/OS . . . . . . . 1543
Using the Customization Dialog to configure
WebSphere Portal using WebSphere
Application Server . . . . . . . . . . 1548
Preparing the z/OS operating system . . . . 1555
Obtaining an Installation Manager installation
kit for installing the product on z/OS . . . . 1556
Creating an Installation Manager for installing
the product on z/OS . . . . . . . . . 1557
Obtaining product repositories for installing
the product on z/OS . . . . . . . . . 1559
Installing WebSphere Portal on z/OS . . . . 1560
z/OS . . . . . . . . . . . . . . . 1560
Setting up a federated unclustered production
server . . . . . . . . . . . . . . 1588
Setting up a clustered production environment
on z/OS. . . . . . . . . . . . . . 1614
Configuring databases . . . . . . . . . 1683
Supporting multiple profiles . . . . . . . . 1685
Creating and maintaining multiple profiles on
AIX . . . . . . . . . . . . . . . 1686
IBM i. . . . . . . . . . . . . . . 1695
Linux . . . . . . . . . . . . . . 1703
Solaris . . . . . . . . . . . . . . 1712
Windows . . . . . . . . . . . . . 1722
Setting up and maintaining a portal farm . . . 1731
Choosing the type of portal farm to create 1731
Setting up the HTTP server plug-in on a portal
farm . . . . . . . . . . . . . . . 1741
Configuring search in a portal farm . . . . 1742
Setting up a highly available message bus . . 1744
iii
Administering a portal farm . . . . . . . 1745
Maintaining a portal farm. . . . . . . . 1747
Setting up a Personalization server on WebSphere
Application Server . . . . . . . . . . . 1748
Planning for the Personalization Server . . . 1748
Installing and removing a stand-alone
Personalization Server . . . . . . . . . 1749
Uninstalling WebSphere Portal . . . . . . . 1751
Restrictions on moving a node to a stand-alone
configuration . . . . . . . . . . . . 1751
Uninstalling WebSphere Portal on AIX . . . 1751
Uninstalling WebSphere Portal on IBM i . . . 1756
Uninstalling WebSphere Portal on Linux . . . 1760
Uninstalling WebSphere Portal on Solaris. . . 1764
Uninstalling WebSphere Portal on Windows 1769
Uninstalling Portal on z/OS . . . . . . . 1773
Managing your WebSphere Portal environment 1774
Using the Installation Manager to install fixes 1774
Using the Installation Manager to modify your
environment . . . . . . . . . . . . 1775
Using the Installation Manager to uninstall
interim or cumulative fixes . . . . . . . 1775
Using the Installation Manager to rollback fix
packs. . . . . . . . . . . . . . . 1775
Migrating. . . . . . . . . . . . . 1777
Migration overview . . . . . . . . . . . 1777
Planning for migration . . . . . . . . . . 1777
Supported migration paths . . . . . . . 1778
Hardware considerations . . . . . . . . 1779
Operating systems considerations . . . . . 1780
Target environment . . . . . . . . . . 1780
Configuring JVM heap size from command
line . . . . . . . . . . . . . . . 1781
High availability systems . . . . . . . . 1781
Planning for migration: Security. . . . . . 1782
Local migration . . . . . . . . . . . 1783
Remote migration . . . . . . . . . . 1783
HTTP Server migration. . . . . . . . . 1783
Backup and recovery . . . . . . . . . 1784
Setting up the target environment . . . . . . 1785
Migrating Portal on AIX IBM i Linux Solaris
Windows . . . . . . . . . . . . . . 1786
Removing custom JVM properties . . . . . 1786
Migrating WebSphere Portal Server to Enable
or Extend versions . . . . . . . . . . 1786
Migrating from WebSphere Portal V6.1.x on a
V6.1 application server . . . . . . . . . 1787
V7 application server . . . . . . . . . 1844
Migrating from WebSphere Portal V7.0 . . . 1901
Deploying new functionality in a migrated
portal . . . . . . . . . . . . . . 1950
Migrating Portal on z/OS . . . . . . . . . 1959
Migrating from Websphere Portal V6.1.x on a
V6.1 application server on z/OS. . . . . . 1960
V7.0 application server on z/OS. . . . . . 1988
Migrating from WebSphere Portal V7.0 on
z/OS . . . . . . . . . . . . . . . 2016
Deploying new functionality in a migrated
portal on z/OS . . . . . . . . . . . 2038
Post-migration activities . . . . . . . . . 2044
Updating data after migration . . . . . . 2044
Enabling automatic synchronization . . . . 2045
Migration consideration for Tivoli Access
Manager integration. . . . . . . . . . 2046
Virtual Portal post migration steps . . . . . 2047
Virtual Portal Manager portlet . . . . . . 2047
Default Virtual Portal Content . . . . . . 2047
Manage Seed List portlet . . . . . . . . 2048
Migrated Virtual Portal pages with old features 2048
Update Web Content Manager pages theme 2048
Web Content Manager WCI pages . . . . . 2048
Mashup Integration Post Migration steps. . . 2049
Blogs and wikis post migration steps . . . . 2049
Updating custom theme Dojo references . . . 2049
Analytics post migration steps . . . . . . 2050
Portlets no longer available . . . . . . . 2050
Setting up Tag Center page . . . . . . . 2051
Removing Person Tag hidden pages . . . . 2051
Configuring. . . . . . . . . . . . 2053
Configuration properties reference . . . . . . 2054
Properties file: wkplc.properties . . . . . . 2054
Properties file: wkplc_dbtype.properties . . . 2118
Properties file: db.config.properties . . . . . 2123
Properties file:
wp.db.impl_dbdomain.properties . . . . . 2129
Properties file: wp.db.impl_sourceDb.properties 2151
Properties file: prereq.pzn_dbdomain.properties 2159
Properties file: prereq.pzn_sourceDb.properties 2170
Properties file:
wp.content.repository.install_dbdomain.properties 2174
Properties file: wp.ac.impl.properties . . . . 2174
Properties file: wp.auth.tai.properties . . . . 2184
Properties file: wp.ear.properties. . . . . . 2187
Properties file:
wp.processintegration.config.properties . . . 2188
Properties file: wp.wsrp.common.properties 2189
Properties file: wp.xml.client.properties . . . 2190
Properties file: wp.si.properties . . . . . . 2190
Properties file: wp_security_internal.properties 2191
Changing ports . . . . . . . . . . . . 2196
Changing the portal URI . . . . . . . . . 2197
Changing the portal URI on z/OS . . . . . . 2204
Configuration Wizard . . . . . . . . . . 2207
Accessing the configuration wizard. . . . . 2207
Installing the configuration wizard . . . . . 2208
Workflows included with the configuration
wizard . . . . . . . . . . . . . . 2209
Files created by the configuration wizard. . . 2210
Configuring portal behavior . . . . . . . . 2210
Setting the language of the portal . . . . . 2210
Renaming the HTTP session cookie. . . . . 2211
Customizing the home page login URL with
the theme . . . . . . . . . . . . . 2212
Using portal light mode . . . . . . . . 2212
Creating or editing a custom unique name 2214
Setting the portal entry page . . . . . . . 2214
Configuring your time settings . . . . . . 2215
iv WebSphere Portal 8.0
Setting the search engine that opens when
users select Find . . . . . . . . . . . 2215
Configuring how to handle portlets that a user
is not authorized to view . . . . . . . . 2216
Configuring user session persistence . . . . 2216
Configuring dynamic fragment cache . . . . 2219
Configuring portlet filtering . . . . . . . 2219
Configuring authentication filters . . . . . 2222
Caching . . . . . . . . . . . . . . 2225
URL Mapping. . . . . . . . . . . . 2234
HTTP proxy configuration. . . . . . . . 2240
Delayed cleanup of deleted portal pages . . . 2241
Deleting orphaned data . . . . . . . . 2243
Setting service configuration properties . . . 2245
Parallel portlet rendering . . . . . . . . 2304
Configuring the IBM License Metric Tool and IBM
Tivoli License Compliance Manager . . . . . 2307
Configuring the IBM License Metric Tool on
AIX . . . . . . . . . . . . . . . 2307
IBM i. . . . . . . . . . . . . . . 2309
Linux . . . . . . . . . . . . . . 2310
Solaris . . . . . . . . . . . . . . 2311
Windows . . . . . . . . . . . . . 2312
Setting up a remote spell checker . . . . . . 2314
Installing a remote spell checker. . . . . . 2315
Configuring access to a remote spell checker 2315
Enabling Document Conversion Services . . . . 2317
Configuring Document Conversion Services 2317
Supported platforms for document conversion
services . . . . . . . . . . . . . . 2320
Setting up file type definitions to enable
Document Conversion Services. . . . . . . 2321
Using Document Conversion Services with
Stellent . . . . . . . . . . . . . . 2323
Configuring a remote Document Conversion
Service . . . . . . . . . . . . . . 2324
Files that can be viewed as HTML . . . . . 2326
Connecting to existing database domains. . . . 2331
Transferring data from a database other than the
default database. . . . . . . . . . . . . 2331
Transferring data to DB2 from a non-default
database. . . . . . . . . . . . . . 2332
Transferring data to IBM DB2 for i from a
non-default database . . . . . . . . . 2334
Transferring data to Oracle or Oracle RAC
from a non-default database . . . . . . . 2338
Transferring data to SQL Server from a
non-default database . . . . . . . . . 2341
Adding features to a base installation . . . . . 2344
Adding Personalization features to a base
installation . . . . . . . . . . . . . 2344
Adding Web Content Manager to a base
installation . . . . . . . . . . . . . 2345
Adding Web Content Manager to a base
installation on z/OS. . . . . . . . . . 2345
Configuring blog and wiki template libraries in
a base installation . . . . . . . . . . 2345
Adding sample web content template items to
a base installation . . . . . . . . . . 2346
Adding feed readers to a base installation . . 2347
Configuring managed pages . . . . . . . . 2347
Enabling managed pages . . . . . . . . 2347
Disabling managed pages . . . . . . . . 2349
Transferring content associations to the Portal
Site library . . . . . . . . . . . . . 2350
Integrating . . . . . . . . . . . . 2353
Integrating with collaboration software . . . . 2353
Finding users . . . . . . . . . . . . 2353
Planning for collaborative servers and portlets 2366
Integrating with IBM Sametime . . . . . . 2374
Integrating with Lotus Quickr . . . . . . 2381
Integrating with IBM Connections . . . . . 2385
Collaborative Services environment properties 2398
Integrating business processes . . . . . . . 2402
Overview of the Unified Task List portlet . . 2402
Configuring Unified Task List portlet for single
sign-on . . . . . . . . . . . . . . 2403
Configuring Unified Task List portlet at run
time . . . . . . . . . . . . . . . 2403
Configuring an IBM Business Process Manager
task provider . . . . . . . . . . . . 2409
Integrating with the web application bridge . . . 2410
Web application bridge support . . . . . . 2411
Supporting Inter Portlet Communication in the
web application bridge . . . . . . . . . 2412
Provisioning a backend site using the Manage
web application portlet . . . . . . . . . 2414
Writing filters for the web application bridge 2417
Supporting SPNEGO in the web application
bridge . . . . . . . . . . . . . . 2418
Troubleshooting the web application bridge 2420
Integrating with SAP NetWeaver Portal . . . . 2423
Prerequisites and support for Integrator for
SAP . . . . . . . . . . . . . . . 2424
Preparing your system environment and the
prerequisites . . . . . . . . . . . . 2425
Installing Integrator for SAP . . . . . . . 2427
Configuring Integrator for SAP . . . . . . 2427
Performance tuning for Integrator for SAP 2437
Hints and tips for Integrator for SAP . . . . 2439
Using Web Application Bridge . . . . . . 2440
Administering. . . . . . . . . . . 2441
Portal administration tools . . . . . . . . 2441
Portal administration portlets . . . . . . 2444
The XML configuration interface . . . . . 2450
Portal Scripting Interface . . . . . . . . 2497
Starting and stopping servers, deployment
managers, and node agents . . . . . . . . 2550
Updating user ID and passwords . . . . . . 2552
Changing the WebSphere Portal administrator
password . . . . . . . . . . . . . 2553
Changing the WebSphere Application Server
administrator password in the file registry . . 2553
Contents v
Changing the WebSphere Application Server
administrator password in the LDAP server
using the LDAP administration interface . . . 2554
Replacing the WebSphere Application Server
administrator user ID . . . . . . . . . 2555
Replacing the WebSphere Portal administrator
user ID . . . . . . . . . . . . . . 2556
Changing the LDAP bind password . . . . 2557
Changing database passwords that are used by
WebSphere Portal . . . . . . . . . . 2557
Users and groups . . . . . . . . . . . 2559
Managing users and groups . . . . . . . 2559
Rule-based user groups . . . . . . . . 2559
Creating new users and groups . . . . . . 2564
Viewing the members of a group . . . . . 2565
Editing user information . . . . . . . . 2565
Reusing group information . . . . . . . 2565
Deleting users and groups. . . . . . . . 2566
Virtual Users and Groups . . . . . . . . 2567
Administering user impersonation . . . . . 2567
Customize common name generation . . . . 2570
Nested groups . . . . . . . . . . . 2571
Registration/Edit My Profile and Login
portlets . . . . . . . . . . . . . . 2571
Deregistering users and groups . . . . . . 2574
Setting limits on searches for users and groups 2575
Using the Solution Installer . . . . . . . . 2576
Migrating PAA content . . . . . . . . . 2576
Installing a Portal Application Archive (PAA)
file . . . . . . . . . . . . . . . 2577
Solution Installer runtime configuration . . . 2580
Developing basic solution applications . . . 2581
Developing advanced solution applications 2601
Removing a PAA assembly . . . . . . . 2638
Deleting PAA content after an uninstallation 2639
Managing portlets, portlet applications, and
iWidgets . . . . . . . . . . . . . . 2640
Web modules, portlet applications, and portlets 2640
Installing a portlet . . . . . . . . . . 2641
Deploying J2EE resources . . . . . . . . 2641
Activating and deactivating portlet
applications or portlets . . . . . . . . . 2643
Modifying portlet applications and portlets 2644
Copying portlet applications . . . . . . . 2645
Copying portlets . . . . . . . . . . . 2645
Updating Web modules, portlet applications,
and portlets . . . . . . . . . . . . 2645
Deleting Web modules, portlet applications, or
portlets . . . . . . . . . . . . . . 2646
Disabling anchors in portlet URLs . . . . . 2646
Managing iWidgets in your portal . . . . . 2646
Managing pages . . . . . . . . . . . . 2652
Pages and page types: shared, derived, and
hidden pages . . . . . . . . . . . . 2652
Selecting pages . . . . . . . . . . . 2657
Creating pages using the Manage Pages portlet 2657
Creating pages from a template using the
Manage Pages portlet . . . . . . . . . 2659
Creating shared pages . . . . . . . . . 2660
Creating derived pages. . . . . . . . . 2660
Creating a label . . . . . . . . . . . 2660
Creating a URL . . . . . . . . . . . 2661
Using friendly URLs . . . . . . . . . 2661
Creating page templates . . . . . . . . 2664
Editing pages, labels, and URLs . . . . . . 2665
Searching pages . . . . . . . . . . . 2666
Ordering pages, labels, and URLs . . . . . 2667
Moving pages and labels . . . . . . . . 2667
Assigning access to pages, labels, and URLs 2667
Activating or deactivating a page, label, or
URL . . . . . . . . . . . . . . . 2668
Deleting pages, labels, and URLs . . . . . 2668
Exporting pages and labels . . . . . . . 2668
Setting up Manage Pages . . . . . . . . 2669
Task refresh-page-layout . . . . . . . . 2669
Field descriptions for the Manage Pages portlet 2670
Customizing pages . . . . . . . . . . 2671
Managing theme capabilities . . . . . . . . 2677
Deploying themes with cacheable resources 2677
Configuration settings for capability filters 2679
Disable the automatic adding of missing
required modules . . . . . . . . . . 2679
Managing community pages . . . . . . . . 2680
Managing community associations . . . . . 2680
Creating community associations during page
template instantiation . . . . . . . . . 2682
Community associations and APIs . . . . . 2684
Managing your cluster . . . . . . . . . . 2684
Enabling LDAP security after cluster creation 2685
Renaming the node . . . . . . . . . . 2685
Determining application sharing between
clusters . . . . . . . . . . . . . . 2686
Managing portlets in your cluster . . . . . 2686
Managing replication in your cluster . . . . 2691
Managing Portal Scripting Interface in your
cluster . . . . . . . . . . . . . . 2692
Managing Single sign-on settings in your
cluster . . . . . . . . . . . . . . 2693
Updating Personalization properties in a
cluster . . . . . . . . . . . . . . 2694
Portal Search . . . . . . . . . . . . . 2694
Portlets for working with Search . . . . . 2694
Planning and preparing for Portal Search. . . 2697
Administering Portal Search . . . . . . . 2710
Setting up search collections . . . . . . . 2727
Searching and crawling portal and other sites 2737
Search by external users on your portal site 2746
Working with the search portlets . . . . . 2751
Hints and tips for using Portal Search. . . . 2773
Managing your site . . . . . . . . . . . 2779
Tagging and rating . . . . . . . . . . . 2779
How tagging and rating works in the portal 2781
The tagging and rating user interface . . . . 2786
Tagging and rating for static pages . . . . . 2804
Searching for tagged content . . . . . . . 2805
Allowing your own custom content to be
tagged and rated . . . . . . . . . . . 2806
Federating tags . . . . . . . . . . . 2809
Configuration reference. . . . . . . . . 2811
Security for tagging and rating . . . . . . 2823
Using the XML configuration interface to
administer tags and ratings . . . . . . . 2824
vi WebSphere Portal 8.0
Administration of tag federation . . . . . 2828
Hints and tips for tagging and rating . . . . 2830
Using WebDAV with WebSphere Portal . . . . 2833
Configuring the WebDAV file store. . . . . 2834
Using WebDAV file store . . . . . . . . 2834
Serving HTTP OPTIONS requests to the server
context root by WebDAV clients . . . . . . 2838
Working with WebDAV clients . . . . . . 2839
Task webdav-deploy-zip-file . . . . . . . 2839
Virtual portals. . . . . . . . . . . . . 2840
Scenarios for virtual portals . . . . . . . 2841
Planning for virtual portals . . . . . . . 2843
Virtual portals and managed pages. . . . . 2856
Configuring a virtual portal for z/OS . . . . 2856
Administering virtual portals. . . . . . . 2858
Configuration tasks for administering virtual
portals . . . . . . . . . . . . . . 2871
Hints and tips for working with virtual portals 2875
Known limitations . . . . . . . . . . 2876
Language support . . . . . . . . . . . 2877
Supporting a new language . . . . . . . 2879
Changing the character set for a language . . 2882
Dynamically changing the language during the
session . . . . . . . . . . . . . . 2882
Selecting and changing the language . . . . 2883
Setting the language fallback filter . . . . . 2885
Using WSRP services . . . . . . . . . . 2886
Learning about WSRP . . . . . . . . . 2887
Planning for WSRP . . . . . . . . . . 2889
Using your portal as a WSRP Producer . . . 2893
Using your portal as a WSRP Consumer . . . 2911
Reference for using WSRP with the portal . . 2939
Backup and restore . . . . . . . . . . . 2944
Guidelines for clustered deployments . . . . 2944
Backing up files, databases, and the LDAP
server(s). . . . . . . . . . . . . . 2945
Restoring files, databases, and the LDAP
server(s). . . . . . . . . . . . . . 2946
Browser behavior and scenarios . . . . . . . 2947
View state behavior for the Page Builder theme 2947
Back button behavior . . . . . . . . . 2950
Back button limitations. . . . . . . . . 2955
Configuring history expiration limits . . . . 2956
Administering managed pages . . . . . . . 2959
Project URL generation. . . . . . . . . 2959
Access control for managed pages . . . . . 2960
Portal Scripting Interface and project support 2964
Portal Scripting Interface and web content
libraries . . . . . . . . . . . . . . 2967
XML configuration interface and managed
pages. . . . . . . . . . . . . . . 2969
Lost-found site area . . . . . . . . . . 2970
Administering syndication . . . . . . . . 2970
Syndication overview . . . . . . . . . 2970
Creating a syndication relationship. . . . . 2974
Creating a syndication relationship from the
command line . . . . . . . . . . . . 2977
Syndication tuning . . . . . . . . . . 2980
Syndication troubleshooting . . . . . . . 2982
Securing . . . . . . . . . . . . . 2985
Security and authentication considerations . . . 2985
Authentication . . . . . . . . . . . 2985
Federal Information Processing Standards . . 2986
Planning for single sign-on . . . . . . . 2987
Secure communications using SSL . . . . . 2987
Credential Vault . . . . . . . . . . . 2988
Caching considerations . . . . . . . . . 2989
Controlling access . . . . . . . . . . . 2989
Managing Access Control . . . . . . . . 2989
Resources, roles, access rights, and initial
access control settings . . . . . . . . . 2990
Access control scenarios . . . . . . . . 3017
Setting user and group permissions . . . . 3019
Setting resource permissions . . . . . . . 3020
Delegated Access Control Administration . . 3020
Access Control Caching . . . . . . . . 3021
Java 2 security with WebSphere Portal . . . . 3023
Integrating with OpenID authentication . . . . 3024
Configuring OpenID authentication . . . . 3024
Modifying the list of OpenID providers . . . 3031
Configuring transient users . . . . . . . 3032
Disabling transient users and OpenID
authentication . . . . . . . . . . . . 3035
Enabling step-up authentication, the Remember
me cookie, or both . . . . . . . . . . . 3035
AIX: Enabling step-up authentication, the
Remember me cookie, or both . . . . . . 3035
IBM i: Enabling step-up authentication, the
Linux: Enabling step-up authentication, the
Solaris: Enabling step-up authentication, the
Windows: Enabling step-up authentication, the
z/OS: Enabling step-up authentication, the
Securing LTPA keys on a production environment 3060
Configuring SSL . . . . . . . . . . . . 3060
Setting up SSL . . . . . . . . . . . 3060
Configuring SSL only for the login process 3065
Setting up Client Certificate Authentication 3066
Cryptographic hardware for SSL acceleration 3070
Enabling FIPS . . . . . . . . . . . . . 3071
Configuring Session Security Integration . . . . 3071
Managing user data . . . . . . . . . . . 3072
Enabling application groups . . . . . . . 3073
Removing attributes . . . . . . . . . . 3074
Managing your user registry on AIX . . . . 3076
Managing your user registry on IBM i. . . . 3101
Managing your user registry on Linux . . . 3125
Managing your user registry on Solaris . . . 3150
Managing your user registry on Windows . . 3175
Managing your user registry on z/OS. . . . 3201
Enabling HTTP Basic Authentication for simple
clients . . . . . . . . . . . . . . . 3220
The HTTP Basic Authentication Trust
Association Interceptor . . . . . . . . . 3220
Configuring the HTTP Basic Authentication
Trust Association Interceptor . . . . . . . 3220
Contents vii
Reference: Properties for the Trust Association
Interceptor . . . . . . . . . . . . . 3221
Enabling the HTTP Basic Authentication Trust
Association Interceptor . . . . . . . . . 3223
HTTP Basic Authentication Trust Association
Interceptor in combination with external
authentication servers . . . . . . . . . 3224
Setting up custom user repositories . . . . . 3224
Creating and updating federated repositories 3225
Creating and updating stand-alone repositories 3227
External security managers . . . . . . . . 3230
Planning for external security managers . . . 3230
Enabling and configuring single sign-on for
HTTP requests using SPNEGO . . . . . . 3234
Configuring Tivoli Access Manager. . . . . 3235
Verifying Trust Association Interceptors for
authentication . . . . . . . . . . . . 3259
Changing the login and logout pages . . . . 3259
Managing access control with external security
managers . . . . . . . . . . . . . 3260
Deleting passwords from properties files . . . . 3261
Monitoring . . . . . . . . . . . . 3263
Portlet load monitoring for WebSphere Portal 3263
Configuring and administering Portlet load
monitoring . . . . . . . . . . . . . 3263
Configuring Portlet load monitoring . . . . 3264
Administering Portlet load monitoring . . . 3265
Logging and auditing events . . . . . . . 3267
API for accessing Portlet load monitoring data 3268
Analyzing portal usage data . . . . . . . . 3270
Logging and analyzing server side site data 3270
Analyzing user behavior by Active Site
Analytics . . . . . . . . . . . . . 3276
Auditing . . . . . . . . . . . . . . 3303
Setting up a portal site. . . . . . . 3305
Site toolbar . . . . . . . . . . . . . . 3305
Previewing as another user . . . . . . . . 3307
Pages. . . . . . . . . . . . . . . . 3308
Page creation and navigation. . . . . . . 3308
Creating a page from the site toolbar . . . . 3309
Page templates . . . . . . . . . . . 3310
Creating page from a template using the site
toolbar . . . . . . . . . . . . . . 3310
Page layout and style . . . . . . . . . 3311
Changing page style. . . . . . . . . . 3311
Changing page layout . . . . . . . . . 3311
Moving a page . . . . . . . . . . . 3312
Projects and workflows. . . . . . . . . . 3312
Projects overview . . . . . . . . . . 3312
Workflow and change management . . . . 3314
Best practices for projects . . . . . . . . 3326
Managed pages . . . . . . . . . . . . 3327
WebSphere Portal artifacts affected by
managed pages . . . . . . . . . . . 3327
Drafts and projects for changes to managed
pages. . . . . . . . . . . . . . . 3328
Scope of edits for managed pages . . . . . 3328
Edit mode and administration pages . . . . 3329
Managed pages and site management . . . . 3329
Managed pages and the authoring portlet . . 3330
System content associations . . . . . . . 3330
Best practices for managed pages . . . . . 3330
Troubleshooting managed pages. . . . . . 3331
Known issues for managed pages . . . . . 3332
Content . . . . . . . . . . . . . . . 3334
Adding content . . . . . . . . . . . 3334
Blogs . . . . . . . . . . . . . . . 3335
Wikis. . . . . . . . . . . . . . . 3338
Creating and adding static content . . . . . 3341
Installed portlets . . . . . . . . . . . 3371
Web clipping . . . . . . . . . . . . 3374
IBM Syndicated Feed Portlet for WebSphere
Portal . . . . . . . . . . . . . . 3386
Hiding content . . . . . . . . . . . 3392
Developing themes and skins . . . . . . . 3393
Understanding the Portal 8.0 modularized
theme . . . . . . . . . . . . . . 3393
The module framework . . . . . . . . 3399
Customizing the theme. . . . . . . . . 3444
Developing themes for a production portal 3531
Updating a Portal 7.0.0.2 theme to use Dojo 1.7 3538
Updating a Page Builder theme to use Dojo 1.6 3539
Customizing the site toolbar . . . . . . . 3550
Device classes . . . . . . . . . . . . 3555
Using portlet wires . . . . . . . . . . . 3557
Working with portlet wires . . . . . . . 3557
Selecting the matching mode . . . . . . . 3557
Adding a wire. . . . . . . . . . . . 3558
Deleting a wire . . . . . . . . . . . 3559
Defining global targets . . . . . . . . . 3559
Page Builder themes and skins . . . . . . . 3559
Personalization . . . . . . . . . . . . 3559
How a site is personalized . . . . . . . 3561
Personalization terms . . . . . . . . . 3563
The Personalization interface . . . . . . . 3584
Publishing personalization rules overview . . 3585
The Web Content resource collection . . . . 3596
The Portal User resource collection . . . . . 3598
LikeMinds Recommendations . . . . . . 3600
Feedback and analytics . . . . . . . . . 3627
Developing a personalized portlet . . . . . 3664
Personalization programming reference . . . 3725
Building a web content system . . . 3741
Staging to production . . . . . . . 3743
Staging to production overview . . . . . . . 3743
Staging to production list . . . . . . . . . 3747
Setting up the initial staging and production
servers . . . . . . . . . . . . . . . 3751
Updates using ReleaseBuilder . . . . . . . 3756
ReleaseBuilder . . . . . . . . . . . 3756
Making updates using ReleaseBuilder . . . . 3757
Reference: ReleaseBuilder command syntax 3760
Updates with syndication . . . . . . . . . 3761
Syndication and staging . . . . . . . . 3761
Staging artifacts that are not transferred by
syndication. . . . . . . . . . . . . 3762
viii WebSphere Portal 8.0
Staging Personalization rules to production . . . 3763
Staging and external security managers . . . . 3764
Developing . . . . . . . . . . . . 3767
Setting up a development server . . . . . . 3767
Single server: Preparing your Windows
operating system. . . . . . . . . . . 3768
Single server: Installing Portal on Windows 3768
Developer mode: Performing post-installation
tasks on Windows . . . . . . . . . . 3777
Changing to developer mode. . . . . . . . 3778
Configuring developer mode on AIX . . . . 3778
Configuring developer mode on IBM i . . . 3779
Configuring developer mode on Linux . . . 3779
Configuring developer mode on Solaris . . . 3780
Configuring developer mode on Windows 3781
Dojo and WebSphere Portal . . . . . . . . 3782
Developing portlets . . . . . . . . . . . 3785
Portlet concepts . . . . . . . . . . . 3786
Understanding the basics . . . . . . . . 3787
Standard portlet API . . . . . . . . . 3829
Portlet services . . . . . . . . . . . 3833
Struts Portlet Framework . . . . . . . . 3838
Model SPI overview. . . . . . . . . . 3870
Controller SPI . . . . . . . . . . . . 3893
User and group management. . . . . . . 3908
Portal Access Control interfaces . . . . . . 3926
Web 2.0 user interface features . . . . . . 3934
Client-side aggregation reference . . . . . 3961
Portlet communication . . . . . . . . . 3978
Dynamic user interfaces . . . . . . . . 4002
Collaborative Services API . . . . . . . 4009
IBM Portlet API . . . . . . . . . . . 4014
Portlet development reference . . . . . . 4027
Extending tagging and rating by using service
APIs . . . . . . . . . . . . . . . . 4057
The Java API . . . . . . . . . . . . 4057
The REST API . . . . . . . . . . . . 4057
Troubleshooting. . . . . . . . . . 4073
Tools for troubleshooting and diagnostics . . . 4073
IBM Support Assistant . . . . . . . . . 4073
Data collection and symptom analysis. . . . 4074
Data collection and symptom analysis for
z/OS . . . . . . . . . . . . . . . 4076
Manual creation of aspect-enabled JAR files 4077
Portal version and history information . . . 4078
Logging and tracing. . . . . . . . . . 4079
Contact support . . . . . . . . . . . . 4097
Reference . . . . . . . . . . . . 4099
Conventions . . . . . . . . . . . . . 4099
Directory structure . . . . . . . . . . . 4100
Terms of use . . . . . . . . . . . . . 4105
Notices . . . . . . . . . . . . . . . 4105
Trademarks . . . . . . . . . . . . 4107
Glossary. . . . . . . . . . . . . . . 4107
A . . . . . . . . . . . . . . . . . 4108
B . . . . . . . . . . . . . . . . . 4108
C . . . . . . . . . . . . . . . . . 4109
D . . . . . . . . . . . . . . . . . 4110
E . . . . . . . . . . . . . . . . . 4110
F . . . . . . . . . . . . . . . . . 4110
G . . . . . . . . . . . . . . . . . 4111
H . . . . . . . . . . . . . . . . . 4111
I . . . . . . . . . . . . . . . . . 4111
J . . . . . . . . . . . . . . . . . 4111
L . . . . . . . . . . . . . . . . . 4112
M . . . . . . . . . . . . . . . . . 4112
N . . . . . . . . . . . . . . . . . 4113
O . . . . . . . . . . . . . . . . . 4113
P . . . . . . . . . . . . . . . . . 4113
R . . . . . . . . . . . . . . . . . 4115
S . . . . . . . . . . . . . . . . . 4115
T . . . . . . . . . . . . . . . . . 4117
U . . . . . . . . . . . . . . . . . 4117
V . . . . . . . . . . . . . . . . . 4117
W . . . . . . . . . . . . . . . . . 4117
X . . . . . . . . . . . . . . . . . 4118
Index . . . . . . . . . . . . . . 4121
Contents ix
x WebSphere Portal 8.0
Overview
IBM WebSphere Portal provides a single access point to web content and
applications, while delivering differentiated, personalized experiences for each user.
Multiple solutions are available to fit your needs.
WebSphere Portal Server
This foundation offering provides a single access point to web content and applications and delivers
socially infused, differentiated, personalized experiences for each site visitor. WebSphere Portal Server
supports workflows, content management, simplified usability and administration, development tools
and Web 2.0, open standards, security, and scalability. The result delivers exceptional web experiences
across multiple channels, in context with the correct business applications and data, to engage and
collaborate effectively, improve business productivity, and deliver better business results.
WebSphere Portal Enable and Extend
These offerings add capability on to the foundation WebSphere Portal Server offering. The Enable and
Extend offerings add web content management capabilities. The offerings deliver the correct information
to the correct audience. They include rich text editing tools, web content templates, workflow, advanced
enterprise search, and personalization services. Used together, these features help you build rich websites
that can deliver highly targeted and dynamic content to customers, partners, and employees in more
relevant ways.
IBM Web Content Manager and Standard Edition
IBM Web Content Manager increases efficiency and accuracy of website deployments by placing content
creation in the hands of content experts to create, maintain, and deliver online content while IT retains
control.
For additional information about WebSphere Portal solutions visit: http://www.ibm.com/software/
websphere/portal/
What's new
Learn what's new in IBM
WebSphere
Portal.
Whats new for administrators
WebSphere Portal includes new features for administrators, such as easier page creation, web analytics,
easier integration with other products such as IBM Connections, and much more.
1
Managed pages
Version 8.0 introduces support for managed pages, which are portal pages that are stored in Web Content
Manager. By managing portal pages from within Web Content Manager, you can apply web content
features like workflow, version control, and syndication to portal pages. This support provides a robust
and integrated method for performing site management by ensuring that changes are coordinated and
published together.
Key benefits of managed pages:
v Any changes you make to a page are made in a draft state, without affecting the live server.
v Drafts are organized within projects in Web Content Manager. When you publish draft changes to the
live server, a project coordinates the updates and ensures that all drafts are published at the same time.
v A workflow process ensures that page changes are made available on the live server only when the
changes are approved. You can create customized workflows to suit the requirements of your site and
authoring environment.
v A graphical toolbar integrates managed pages functions directly into your portal pages. The toolbar
provides quick access to editing features, projects, and workflow actions that apply to the page. You
can also easily change the scope of your changes so that you can manage the changes with projects or
directly edit the published site.
v Syndication provides a convenient and flexible method for transferring managed pages from a staging
environment to a production environment. With syndication, all required page artifacts and content are
transferred at the same time.
v Scripting support is also available for automating managed pages tasks. The Portal Scripting Interface
includes methods for working with projects and web content libraries, and the XML configuration
interface includes similar support for projects.
Learn more about managed pages
.
OpenID
Starting with Version 8.0 you can now configure WebSphere Portal to allow external Identity Providers,
such as Google and Yahoo, to authenticate users. You can also configure WebSphere Portal to allow
registered users to define and use their Facebook credentials to sign on.
With this new feature, transient users, who are trusted and verified from an identity provider, can access
WebSphere Portal without requiring a WebSphere Portal user account.
Learn more about integrating with OpenID authentication
Federating tags
Starting with WebSphere Portal Version 8.0 you can import tags from IBM Connections into the portal tag
store. The previously introduced Tag Center now represents a central place in the portal that contains
tagged content from the portal, Web Content Manager, and IBM Connections. Users can now, from within
the portal, search for tagged content, independent of whether this content resides in the portal, Web
Content Manager, or IBM Connections. This way, the portal now provides an easy and convenient
approach for searching for content that resides inside or outside of the portal.
Learn more about it on Federating tags
Search optimization
To improve search optimization, page metadata is rendered as keywords in the HTML. The metadata is
taken from Web Content Manager and includes: title, keywords, category, and more.
2 WebSphere Portal 8.0
Web analytics: Site promotions and overlay analytic reports
More flexible options to tag pages, portlets, or web content and measure their usefulness through
Campaign and Custom tags.
New user-friendly overlay statistics provide an inline view to track effectiveness of a web property.
Learn more about:
Site Promotions
Overlaying analytics reports
.
Community pages: IBM Connections in context
Community pages are portal pages that are associated with a community in IBM Connections. You create
the association between a page and a community by adding a community association to the page. You
can also create communities automatically by adding a community association to a page template and
then creating a page from the template. Community pages let you place IBM Connections portlets in the
correct WebSphere Portal and Web Content Manager context.
For information about setting up and using the support for community pages in your portal, see the
following topics:
Configuring community pages on page 2395
Before you can use community pages, you must enable the support and configure access to your
IBM Connections servers.
Managing community associations on page 2680
You can add community associations to individual pages with the universal toolbar or with the
XML configuration interface. You can also use page templates to automatically create
communities when you create a page from the template.
Community associations and APIs on page 2684
You can access community associations programmatically with several APIs.
IBM Forms: Easy form creation
Provides agile, easy to build and manage web experiences for compelling, interactive data capture/forms
that fit within the overall portal web experience. IBM Forms offers businesses the ability to respond to
changing business requirements without expensive, time-consuming development cycles. IBM Forms also
empowers business users to build and manage their own applications to collect and analyze structured
information from customers, partners, and employees.
Learn more about IBM Forms
Integrator for SAP: Integrate SAP NetWeaver content into your portal site
Use IBM WebSphere Portal Integrator for SAP to integrate content from an SAP NetWeaver Portal into
your IBM WebSphere Portal. You can integrate navigational structures and single content pieces.
Integrator for SAP integrates the SAP NetWeaver Portal navigation into WebSphere Portal on a page
named SAP navigation. The navigation is retrieved new from the SAP NetWeaver Portal for each
WebSphere Portal session and used for the duration of that session.
For integrating individual pieces of SAP NetWeaver Portal content, WebSphere Portal provides a portlet
named IBM WebSphere Portal Integrator for SAP.
Learn more about it on Integrating with SAP NetWeaver Portal
Overview 3
Unified Task List: Simplified business process management
Access relevant tasks and activities for multiple business process management solutions from a single
user interface. The Unified Task List portlet provides a single point of integration between multiple
systems and displays tasks that WebSphere Portal users must complete to advance workflows.
Learn more about business process management integration
Web Application Bridge: Easily integrate existing web application
Use the IBM Web Application Bridge to integrate all your existing web applications, especially SharePoint
2007 sites, so your global user population can access them from multiple locations. The IBM Web
Application Bridge also supports forms, multiple context roots, and eventing.
Graphical user interface installation
WebSphere Portal Version Version 8.0 is the first version to adopt the IBM Installation Manager user
interface. The interface replaces the program based on InstallShield MultiPlatform (ISMP) that installed,
updated, and uninstalled previous versions. Installation Manager is a single installation program that can
use remote or local software flat-file repositories to install, modify, or update new WebSphere Portal
products. It determines and shows available packages -- including products, fix packs, interim fixes, and
so on -- checks prerequisites and interdependencies, and installs the selected packages. You also use the
Installation Manager to easily uninstall the packages that it installed.
IBM i Installation
If you are installing multiple WebSphere Portal profiles on IBM i, you can now specify if you want each
profile to have a unique portal binary or if you want each profile to share the portal binaries with the
first installed profile.
Installing Web Content Manager into an existing WebSphere Portal installation
If you installed WebSphere Portal using the Server license, you can now install Web Content Manager
into the existing installation.
The Solution Installer
Prior to WebSphere Portal Version 8.0, you had to install the Solution Installer from the Solutions Catalog.
You could then use the Solution Installer to install applications into your WebSphere Portal environment.
Now the Solution Installer is installed when you install WebSphere Portal.
See Using the Solution Installer on page 2576
ConfigEngine
You can run ConfigEngine tasks from a read-only ConfigEngine directory that allows you to manage
multiple profiles from one location or you can run ConfigEngine tasks from the wp_profile_root directory
that you have used in previous releases. For example, to use the ConfigEngine read-only directory, run
the ConfigEngine task in the ConfigEngine folder that is on the same level in the directory structure as
the default wp_profile directory. You can substitute the path to the ConfigEngine read-only directory in
any ConfigEngine task in the product documentation.
Configuration wizard
Configure databases, set up security, migrate to a new version, and more from the updated configuration
wizard. Try out workflows to create customized scripts for your environment for common configuration
tasks, such as changing the portal URI, changing the portlet URIs, and replacing the WebSphere Portal
administrator user ID to create customized scripts for your environment. Use the web UI for running
ConfigEngine tasks as an alternative to the command line.
Learn more about the configuration wizard
JDBC OCI Type 2 driver support for Oracle and Oracle RAC
You can use JDBC Type 4 drivers or JDBC OCI Type 2 drivers when transferring databases. To migrate
from a previous version of WebSphere Portal using JDBC Type 4 drivers, the target system must use
JDBC Type 4 drivers. Direct migration from a database using JDBC Type 4 drivers to a database using
JDBC OCI Type 2 drivers is not supported. Once migration is complete, you can continue using JDBC
Type 4 drivers or change the driver type to JDBC OCI Type 2 drivers as appropriate. Transparent
Application Failover (TAF) through JDBC OCI Type 2 drivers is not supported.
What's new for user interface developers
This release includes new features, such as enhancements to the provided theme, to make developing and
customizing your site easier.
Theme
The theme that is immediately available is optimized to separate the theme from the portal features. To
separate the design from how the site works, the theme uses a modularized framework. The modules
that you include in the theme can enable and disable features such as search. Here is an example of this
separation. In a staging or development environment, authors need the capability to edit content in
context. However, on the delivery or live site, authors should not be able to edit content. The same theme
is used in both the development environment and the live environment. The only difference is which
modules are included.
Learn more about the included theme and theme architecture.
Mobile Portal Theme
The WebSphere Portal Mobile Experience WebKit theme, also called the mobile theme, includes a code
selection for navigation and page layout that is designed specifically for WebKit mobile devices. You can
start with the sample code and then customize it for your needs. The mobile theme includes:
Sample mobile navigation widgets that follow common mobile application navigation patterns
Sample mobile page layouts that demonstrate common content interaction patterns
The mobile theme is available on the Lotus and WebSphere Portal Business Solutions Catalog.
Web Experience Factory builders
Web Experience Factory includes new smartphone builders and samples to help you generate mobile
portlets and pages faster. Builders include:
Native-looking navigation tabs, lists, buttons, and controls
Scrolling lists with display options, such as thumbnails and multiple line test with multiple styles
Access to smartphone features, such as HTML 5, orientation, and geographical location
Input UI patterns appropriate for smartphones, such as selectable lists and check box lists
What's changed
WebSphere Portal includes changes to existing features.
Overview 5
Tivoli
Access Manager WebSEAL

The following two items have changed within Tivoli Access Manager WebSEAL:
v The WebSEAL virtual host junction replaces the transparent and non-transparent junctions.
v Enhanced TAI Plus replaces TAMTrustAssociationInterceptorPlus
Installation
The following items were changed for the installation process:
v The IBM Installation Manager replaces the InstallShield for installation.
v The IBM Installation Manager replaces the WebSphere Portal Update Installer (PUI) for installing
interim fixes and fix packs.
v You can change the context root and Uniform Resource Identifier (URI) during the installation. You
must run some additional tasks after installation to change the context root for your portlets.
server1
server1 is no longer needed in WebSphere Portal Version 8.0 and has been removed.
In previous releases, you needed to start WebSphere Application Server server1 before you can start
WebSphere Portal. server1 was also needed to access the WebSphere Integrated Solutions Console. In
WebSphere Portal Version 8.0, you can start the portal server and access the WebSphere Integrated
Solutions Console directly.
Integrating with IBM Sametime
The Sametime Proxy replaced Sametime Links. As a result, set up is easier and quicker. To accommodate
that changeSametime Web 2.0 Contact List has replaced the Who Is Here and Sametime Contact List
portlets.
Portlets moved to the Business Solutions Catalog
The following Business portlets are now available for download on the Business Solutions Catalog:
v Lotus Notes View portlet
v Domino Web Access (iNotes) portlet
v Lotus Document Viewer portlet
v Lotus My Place portlet
Portal Scripting Interface continues to support JACL
WebSphere Application Server continues to support the JACL Version 7.0 syntax. Therefore WebSphere
Portal als continues JACL support. You can continue using JACL scripts with the Portal Scripting
Interface.
Client-side aggregation
The Portal 8.0 and Portal 7.0.0.2 themes do not support client-side aggregation (CSA). The Page Builder
theme, which is supported with Portal 8.0, is the primary theme that supports CSA.
Related information:
IBM WebSphere Portal Business Solutions Catalog
Unsupported and deprecated features
Make a note of the features that were available in the previous versions of IBM WebSphere Portal but are
no longer available in this version or in future versions.
As they become available, links to additional information will be provided to help you migrate away
from deprecated features.
Features no longer supported
Policy Editor portlet for Mail
CPP portlet is no longer shipped in WebSphere Portal Version 8.0
Composite applications
Starting with Version 8.0, WebSphere Portal no longer supports Composite applications. You can
still use the portal XML configuration interface to do this type of work.
Computer Associates eTrust SiteMinder
eTrust SiteMinder installations are not supported in this release.
Domino Extended Product Portlet wizard
The configuration wizard to configure the Domino and Extended Product portlet was supported
with the InstallShield. Because the IBM Installation Manager is now supported, the Domino and
Extended Product portlet configuration wizard is no longer supported.
Integration with the IBM Mashup Center
WebSphere Portal Version 8.0 provides direct support for widget integration to portal pages,
which enables development of mashup style applications. WebSphere Portal Version 8.0 does not
support promotion of assets from the IBM Mashup Center catalog directly into the portal. For
information about how to add iWidgets to your portal see Managing iWidgets in your portal. For
information about how to construct mashup page applications by using WebSphere Portal Version
8.0 features see the section about Managed pages of the WebSphere Portal and Web Content
Manager Version 8.0 product documentation.
Site management
Earlier versions of WebSphere Portal provided the Resource Manager portlet for performing site
management. With Version 8.0 of WebSphere Portal and Web Content Manager, this site
management functionality has been replaced by the new functionality for managing pages. For
more information refer to Managed pages.
Session persistence on Struts portlets
Struts portlets do not support session replication in WebSphere Portal Version 8.0.
Deprecated features
SOAP support for remote search configuration
SOAP support for remote search services has been deprecated with WebSphere Portal Version 8.0.
EJB is still supported.
Login screen
Login screens have been deprecated. If you need to customize your login process, you must use
custom authentication filters instead of login screens.
Sharing private pages
Sharing private pages has been deprecated with this version.
Overview 7
Deprecated Business portlets
The following Business portlets were removed in WebSphere Portal Version 8:
v Reminder
v Document Viewer
v Webpage portlet
v My Query reports
v Microsoft Exchange 2003
Deprecated Sametime portlets
The following Sametime portlets were removed in WebSphere Portal Version 8:
v Who Is Here (SametimeWhoIsHere.war)
v Sametime Contact List (SametimeContactList.war)
Deprecated Themes and Tags
The following portal themes and tags were removed in WebSphere Portal Version 8:
v Page Builder theme
v All Legacy themes
v <portal-core:cacheProxyUrl/> tag
Related concepts:
Managed pages on page 3327
Managed pages streamline site management in your portal by simplifying how you create pages and add
content. Because page information and content are stored in web content libraries, you can more easily
coordinate and publish changes with syndication.
Configuring authentication filters on page 2222
The portal authentication filters are a set of plug-in points. You can use them to intercept or extend the
portal login, logout, session timeout, and request processing by custom code, for example to redirect
users to a specific URL.
Related tasks:
Managing iWidgets in your portal on page 2646
You can add iWidgets to your IBM WebSphere Portal.
Solutions Catalog: WebSphere Portal
Deprecated features
Product capabilities
IBM WebSphere Portal capabilities let you quickly implement web experiences that are engaging, flexible,
and high performing.
WebSphere platform
WebSphere is IBM's integration software platform. It includes the entire middleware infrastructure - such
as servers, services, and tools - needed to write, run, and monitor 24x7 industrial-strength, on-demand
Web applications and cross-platform, cross-product solutions. WebSphere provides reliable, flexible, and
robust integration software.
WebSphere provides software for Service Oriented Architecture (SOA) environments that enables
dynamic, interconnected business processes, and delivers highly effective application infrastructures for
all business situations.
IBM WebSphere Application Server drives business agility by providing millions of developers and IT
Architects with an innovative, performance-based foundation to build, reuse, run, integrate, and manage
Service Oriented Architecture (SOA) applications and services. From business critical and key
enterprise-wide applications to the smallest departmental level applications, WebSphere Application
Server offers the highest levels of reliability, availability, security, and scalability.
Customization
You can customize WebSphere Portal to meet the needs of your organization, users, and user groups. You
can adapt the look and feel of the portal to fit the standards of your organization and to customize page
content for users and groups in accordance with business rules and user profiles. Users, such as business
partners, customers, or employees, can further customize their own views of the portal. Users can add
portlets to pages and arrange them as they want and control portlet color schemes. By aggregating
portlets in one place and giving users the power to customize their own desktops, WebSphere Portal
gives users a means for doing business efficiently and with high satisfaction.
Portlets
Portlets are central to WebSphere Portal. As special reusable Java servlet that appear as defined regions
on portal pages, portlets provide access to many different applications, services, and web content.
WebSphere Portal ships a rich set of standard portlets, including portlets for displaying syndicated
content, transforming XML, and accessing search engines and web pages. More portlet solutions are
available on the IBM Lotus and WebSphere Portal Business Solutions Catalog. These portlets are used to
access Lotus Notes
iNotes, IBM Sametime, IBM Connections, and Microsoft Exchange. Several third-party
portlets are also available. Examples include Enterprise Resource Planning (ERP), Dashboards, Business
Intelligence, Process Management, and Customer Relationship Management (CRM) portlets.
It is possible to develop custom portlets, too. WebSphere Portal supports the Java Standard API (JSR 286)
that portlet developers can use to create custom portlets.
Widgets
WebSphere Portal now includes widgets inside the portal. You can even create mashups that consist of
both portlets and widgets. Widgets are highly interactive user interface components that are written in
JavaScript. These widgets are typically very narrow in scope and can easily be created using a
script-based language. Widgets can also be a solution for creating a mashup between different backend
technologies like a Java EE-based portal server and a PHP-based server.
For additional information about new features, main components, and what each component provides to
the overall solution, explore the subtopics of this section.
Web analytics
WebSphere Portal includes a number of solutions to help you understand how visitors use your site,
including server-side analytics,and client-side analytics. Client-side analytics is also called active site
analytics.
Portal analytics allow you to:
Measure the success of your portal site.
Predict the demand to a portal in the future.
Plan for changing site visitor needs.
Overview 9
Active site analytics
Through active site analytics (client side) WebSphere Portal makes it easier to collect, process, and report
on your site usage. Integration with leading web analytics products easy. For example, Coremetrics page
view tags are immediately available on pages in your site. In addition integration with Coremetrics, you
can also integrate with other web analytics tools such as, Unica, Omniture, and Webtrends.
Active site analytics:
Captures visitor behavior data directly from the web browser to ensure that every action is recorded.
Dynamically accommodates all content changes to the site so adding a page, product, or category
typically requires no tag maintenance.
Creates a comprehensive record of visitor interactions and clients also do not have to pre-define
segments, visitor events, campaigns, or categories for analysis.
Active site analytics uses a flexible, backend business logic instead of hard-coding the logic into the site
instrumentation. As a result, you enjoy reduced IT maintenance and maximum analytical flexibility.
You can analyze web analytics reports in context, without switching to an external tool. This capability is
called overlay reports. Overlay reports provide a quick look at the success of a page, portlet, or web
content. Overlay reports are immediately available for Coremetrics, but you can extend that capability to
other analytics tools.
Server-side analytics
Using server-side analytics you can gather information about page and site visitor management activities,
site visitor page and portlet requests, and session activities. Page and visitor management activities
include creating, reading, updating, and deleting. Session activities include login, logout, timeouts, and
login failures.
Related concepts:
Logging and analyzing server side site data on page 3270
WebSphere Portal implements a logging function for your usage data. The portal writes usage records to
a dedicated log file if site analysis logging is enabled. Multiple types of site analyzer loggers allow portal
administrators to collect statistical data in various areas. The portal server manages the collection of data
on its own, but from a business point of view you can also log custom details of business events. You can
configure the portal for site analysis logging for the web content viewer.
Analyzing user behavior by Active Site Analytics on page 3276
You can collect data about user behavior in your portal and send that data to a service for analysis. For
this purpose the portal provides Active Site Analytics (ASA).
Collecting analytics data on page 3277
Before you can send data about user behavior in your portal to a service for analysis, you need to collect
that data. See the following topics for information about how to do this.
Displaying overlay analytics reports on page 3290
You can use Active Site Analytics to show graphical statistics reports about individual portal resources,
such as pages or portlets. These reports are called Active Site Analytics overlay reports.
Analytics tags and site promotions on page 3298
To obtain further analytics information from your portal, you can use analytics tags for your portal
resources. You can also use analytics tags for site promotions.
Web content
IBM WebSphere Portal and IBM Web Content Manager help you manage content, share information, and
communicate your message.
IBM Web Content Manager Multilingual Solution
IBM Web Content Manager
IBM Web Content Manager accelerates the creation, maintenance, and delivery of content across intranet,
extranet, Internet, and portal sites.
IBM Web Content Manager is a comprehensive solution for creating, managing, and delivering content on
your website.
Use Web Content Manager to publish your information and pull in content from other sources, either
RSS feeds or other content management systems. On a single page you can publish your corporate
news and highlight news from an external news source.
Authors can edit content inline on staging servers and editors can approve content inline.
Using Personalization, you can target content based on the website users authentication and
preferences. Personalization rules lets you control what information specific users or user groups can
see.
Workflows let you control how content is reviewed, approved, and published. You can create custom
workflows to reflect your existing business processes.
Use syndication to publish approved content to your live website.
Content
You can manage and store content in Web Content Manager, using an external content management
system, or both.
Set up libraries to manage and store content in Web Content Manager.
Use IBM Web Content Integrator to import content in RSS feed format.
Integrate and link directly to external content management systems using CMIS support included
with Web Content Manager.
Use WebDAV to import content from a file system.
Wikis and blogs are immediately available for you to add to pages in your site.
Management
Use projects to manage changes to a group of items. Projects can help you coordinate approvals and
publication.
Workflow is immediately available and you can develop custom workflows if needed. Workflows help
you control how content progresses from draft to publication. Projects can have associated workflows too.
Authoring
Multiple authoring home pages are immediately available. You can also develop a custom authoring
environment if needed.
In addition to the authoring home pages, authors can edit content in context on the staging servers.
Using the edit mode, authors can select to edit content on a page. Changes adhere to defined workflows
and syndication publishes changes.
Multilingual websites
The IBM Web Content Manager Multilingual Solution download, available on the solution catalog,
provides a reference implementation for a multilingual website. It includes a set of extension plugins that
you can use to configure and deliver a multilingual site.
Overview 11
Content Template Catalog
The content template catalog is a set of templates that you can use to accelerate building a website. Using
these templates you can build a basic site quickly with little or no customization.
The content template catalog is a comprehensive set of templates, pre-configured portlets,
content-oriented theme, and layouts. Use the palette of pre-configured portlets to drop components on
your pages for navigation, teasers, slide shows, carousels, and more. The template pattern supports the
creation of your own templates. A page created from a template can be modified and then turned it into
a new template. You could build up you own custom template library and provide a self-service site
development offering to your users.
You can download the content template catalog form the IBM Lotus and WebSphere Portal Business
Solution Catalog
IBM Web Content Manager Forum: Content Template Catalog Announcement
Personalization of content
Personalization allows a portal or website to choose which content should appear for a particular user.
The WebSphere PortalPersonalization component selects content for users, based on information in their
profiles and on business rules. Using Portal Personalization, business experts can classify site visitors into
segments and target relevant content to each segment. For example, a site using Personalization might
show different news articles to managers than to regular employees or different information to valued
customers. Personalization offers analytic capabilities to record site usage patterns and includes the
LikeMinds recommendation engine, which provides collaborative filtering capabilities. Collaborative
filtering uses statistical techniques to identify groups of users with similar interests or behaviors.
Inferences can be made about what a particular user might be interested in, based on the interests of the
other members of the group.
You can define content through a number of applications, including IBM Web Content Manager.
Personalization automatically detects the content definition from these applications. Definitions of
database or LDAP content types can also be made through a Personalization wizard included with IBM
Rational
Application Developer.
Once you define the content type, attributes of the content are exposed to the rule author. The rule author
can use these attributes to make conditions which define if and when certain content is displayed, or
even if certain actions like database updates and triggered emails may occur.
Benefits of Personalization
v The Personalization component selects content for users based on information in their profiles and on
business logic. With Personalization facilities, subject matter experts can select content that is suited to
the needs and interests of each site visitor. These web-based tools help companies quickly and easily
use content that is created by business and subject matter experts.
v Personalization classifies site visitors into segments and then targets relevant content to each segment.
Business experts create the rules for classifying users and selecting content, using web-based tools.
v Personalization has built in capabilities for the IBM Java Content Repository. This means that
personalization rules can easily be used in your Web Content Manager solutions.
v Personalization also includes a recommendation engine that provides collaborative filtering capabilities.
Collaborative filtering uses statistical techniques to identify groups of users with similar interests or
behaviors. Inferences can be made about what a particular user might be interested in, based on the
interests of the other members of the group.
v Campaign management tools are also included with Personalization. Campaigns are sets of business
rules that work together to accomplish a business objective. For example, a Human Resources manager
might want to run a campaign to encourage employees to enroll in a stock purchase plan or sign up
for some other new benefit which has just become available to employees. The Human Resources
manager would define a set of rules that are shown to accomplish this business objective. Campaigns
have start and stop dates and times and can be email and web-page based. Several campaigns can run
simultaneously and can be prioritized.
Related concepts:
Developing a personalized portlet on page 3664
This exercise demonstrates how to use Personalization features of WebSphere Portal and Rational
Application Developer to build your first personalized portlet. Your final result is a working portlet that
uses Personalization rules and content spots to display personal news based on user attributes (or
profiles).
Portlets
Portlets are a central part of IBM WebSphere Portal. Portlets are small applications that are independently
developed, deployed, managed, and displayed. Administrators and users compose personalized pages by
choosing and arranging portlets, resulting in customized Web pages.
WebSphere Portal ships a rich set of standard portlets. For the most up-to-date information about
portlets, including the latest portlets that are available for download, visit the IBM WebSphere Portal
Business Solutions Catalog. Or, refer to Developing portlets for information on creating custom portlets.
Portlet applications
Portlets are more than simple views of existing Web content. A portlet is a complete application,
following a standard model-view-controller design. Portlets have multiple states and view modes, plus
event and messaging capabilities.
Portlets run inside the application server, similar to the way a servlet runs on an application server, but
are aggregated to a complete Web page by the WebSphere Portal server. The portlet container provides a
run-time environment where portlets are instantiated, used, and finally destroyed. Portlets rely on the
WebSphere Portal infrastructure to access user profile information, participate in window and action
events, communicate with other portlets, access remote content, look up credentials, and store persistent
data.
Generally, portlets are administered more dynamically than servlets. For example, portlet applications
consisting of several portlets can be installed or removed while the WebSphere Portal component is
running. The settings and access rights of a portlet can be changed by an administrator while WebSphere
Portal is running, even in a production environment.
Portlet modes allow a portlet to display a different user interface, depending on the task that is required
of the portlet. A portlet has several modes of display that can be invoked by icons on the portlet title bar:
View, Help, Edit, Configure, and Edit Shared Settings.
A portlet is initially displayed in View mode. As the user interacts with the portlet, the portlet can
display a sequence of view states, such as forms and responses, error messages, and other
application-specific states. Help mode provides user assistance. Edit mode lets the user change portlet
settings. For example, a weather portlet might provide an Edit page for users to specify location. Users
must be logged in to WebSphere Portal to access Edit mode. Configure mode changes the default look of
the portlet for all portlet instances and Edit Shared Settings changes the look of the portlet on a specific
page.
Each portlet mode can be displayed in normal, maximized, or minimized state. When a portlet is
maximized, it is displayed in the entire body of a page, replacing the view of other portlets. When a
portlet is minimized, by default, only the portlet title bar is displayed on the page.
Overview 13
Portlet API
The Java Portlet Specification addresses the requirements of aggregation, personalization, presentation,
and security for portlets running in a portal environment. WebSphere Portal supports both portlet
standards JSR 168 and JSR 286. For more information about the standard portlet API, refer to the topic
about the Standard portlet API.
Portlet communications
WebSphere Portal allows portlets to communicate with each other. Portlet communication can be used to
exchange data between portlets. This makes the portal easier to use.
The portal supports events as defined in the JSR 286 specification. It allows administrators to wire
portlets by using the portal user interface.
For example, one portlet can display information about accounts, and a second portlet displays
information about transactions that have occurred for one of the accounts over the last 30 days. To do
this, the transactions portlet needs to obtain the appropriate account information when it displays the
transaction details. This is accomplished by communication between the two portlets, using events as
described in the JSR 286 specification. In this example, the account portlet defines a publishing event in
its portlet descriptor. The transaction portlet defines this event as a processing event in its portlet
descriptor. By using the portal user interface, you can now wire those two portlets together. After you did
this, when the account portlet throws an event, the transaction portlet receives this event and can show
information about the transactions of this account.
Portlet services
Portlet services are used to provide common functionality to portlets. Each portlet service has its own
service specific interface for the functionality that it offers. WebSphere Portal supports portlet services for
standard portlets. Standard portlets use a JNDI lookup to retrieve a PortletServiceHome object, which is
used to retrieve a portlet service implementation. A portlet service can be invoked only by the code
within a portlet. For more information about portlet services in the portal, refer to the topic about Portlet
services.
Creating and customizing portlet applications
Web Experience Factory is included with WebSphere Portal and provides a robust selection of builders
that supercharge the portlet development process without writing code. Web Experience Factory's rapid
application development technology enables portlet creation 40 70 percent faster than using traditional
J2EE development methods. With Web Experience Factory you can rapidly develop and deploy custom
service-oriented portlets and rich, interactive Web 2.0 style applications with features like drag-and-drop,
in-line editing, type-ahead search and intelligent page refresh functionality. Web Experience Factory
transforms operational data into high-value business information by integrating data from a wide variety
of packaged enterprise applications, repositories and data sources including SAP, Siebel, PeopleSoft,
Lotus
Domino
, Web and REST services and leading relational databases via a rich, pre-built connector
library.
Using Web Experience Factory's patented dynamic profiling functionality, developers can easily empower
business-user led portlet customization via personalization and create dynamic, micro-targeted
applications that vary portlet content based on user role, geography and more. Applications built with
Web Experience Factory can be deployed to multiple run-time environments to provide the best user
experience based on target audience, including WebSphere Portal, Mashup Center, Lotus Notes and
Expeditor and WebSphere Application Server.
Web Experience Factory applications are standards based and comply with portlet standards including
JSR 168 and JSR 286.
Social business
WebSphere Portal offers wikis, blogs, and tagging and rating capabilities. In addition, you can integrate
existing collaboration applications with your portal site, such as Lotus Connections.
IBM Connections
Integrate IBM Connections into your site using community pages andIBM Connections Portlets.
IBM Connections Portlets
Connection portlets are not installed with the portal but you can easily download them from IBM Lotus
and WebSphere Portal Business Solutions Catalog.
The portlet includes activities, blogs, blog summary, bookmarks, bookmarks summary, profiles, profiles
summary, wikis, forums, forums summary, community overview, and tags.
Community pages
Portlets on community pages are automatically scoped to the community membership and display
content from the community in the portlets. For example, if your community contains a forum you can
add the forum portlet to a community page. The portal site visitors can view and interact with the forum
content from the portal site.
You can automatically create new communities for your pages during the page template instantiation.
Search integration
Integrating IBM Connections content into your portal search makes it easier for site visitors to find
community content. Visitors can search for a term and see results from your portal site and IBM
Connections. Each IBM Connections component has a unique seedlist provider. To configure your portal
search to include IBM Connections content, you must configure a content source for each seedlist.
Instructions are provided in the IBM Connections product documentation.
Tag integration
You can configure you portal tag cloud to include tags from IBM Connections. This configuration makes
it easier for your site users to find content in the communities.
You can also add the IBM Connections Tags Portlet to a page. Then you can wire it to other IBM
Connections portlets. Then site visitors can use tags to find community content faster in blogs, wikis, and
more.
Profiles integration
You can configure your portal site to show IBM Connections business card information. Names associated
with IBM Connections profiles display as active links. Your site visitors click the name to see the business
card. From the business card visitors can link to communities, blogs, and more for the selected user.
Files integration
Content authors can easily create links to files stored on IBM Connections. From the rich text editor,
inIBM Web Content Manager, the author can browse Files. Authors can also use Web Content Manager
markup generation to render the current contents of specific IBM Connections Folders.
Integration with IBM Connections Files is based on the generic Content Management Interoperability
Services (CMIS).
Overview 15
Related concepts:
Roadmap: Integrating with IBM Connections on page 2386
IBM Connections Portlets for WebSphere Portal
How the Tags portlet interacts with the other IBM Connections portlets
IBM Sametime
The IBM Sametime portlets are installed with WebSphere Portal and deployed automatically.
The following portlets are available from the Applications > Collaboration area of the portal site.
v Sametime Web 2.0 Contact List
v People Finder
People awareness
Users can view contact and other typical business card information for a registered user by displaying the
Person card. The Person card is available through a wide range of portal components including Domino
and Sametime integration, personalization, and Web content authoring. To view the Person card, move
the cursor over an active (underlined) person's name and then select Click for Person Card.
When Sametime is enabled in your portal configuration, users can work with the complete set of people
awareness functionality, which includes instant messaging and application sharing through e-meetings.
Person names appear aware - with a dynamic online status indicator. Click Profile to display full
information about the person. Additional actions can include:
v Send Mail
v Chat
v Add as Sametime Contact
If you choose not to enable Sametime in your portal configuration, people awareness functionality is
more limited. People's names appear as hyperlinks, but with no people awareness icon next to each
name, and available actions on the Person card are limited to those that are native to WebSphere Portal.
Related concepts:
Integrating with collaboration software on page 2353
IBM WebSphere Portal integrates with collaboration software to provide you with more effective and
cost-efficient ways of accessing information, sharing ideas, communicating and working together. Key
software with that WebSphere Portal integrates with includes IBM Lotus Domino, IBM Sametime, IBM
Lotus Quickr
, and IBM Connections.

Blogs and wikis
A set of preinstalled Web content libraries are supplied to allow you to add blog and wiki features to
your Web sites. Use blogs, blog libraries, and wikis to tap into the power of the community and to
change the way you work.
Blogs are a great tool to use when you want to generate ideas around a single topic. You can use blogs
for your own individual work or to gain feedback on a single concept from the larger team. Blog libraries
take blogs to the next level. Rather than creating a blog per topic, you can use blog libraries to keep track
of multiple topics in a centralized location. Wikis also provide you with another alternative for authoring
content. Simple inline editing, including the insertion of images and links, makes authoring wikis quick
and easy. You can also tag and rate blog and wiki content.
Blogs, blog libraries, and wikis use the template libraries provided by IBM Web Content Manager. Each
blog, blog library, and wiki has its own library. The page hierarchy that is provided for these components
is the common one defined by the Web Content Manager template libraries.
Tagging and rating portal content
Users can tag or rate portal content and view the tags and ratings. Tagging and rating allows users to
better organize, categorize, and find portal content. This includes Web Content Manager , IBM
Connections, and custom content. For example, users can tag or rate books in an online bookstore.
Note: A default portal installation supports tagging and rating of pages for the Portal 8.0 theme and the
Page Builder theme only. Therefore, if you select the Portal theme as the default site theme, the Tag
Center might not be displayed as expected.
New in WebSphere Portal Version 8.0: Federating tags: Starting with WebSphere Portal Version 8.0 you
can import tags from IBM Connections into the portal tag store. The previously introduced Tag Center
now represents a central place in the portal that contains tagged content from the portal, Web Content
Manager, and IBM Connections. Users can now, from within the portal, search for tagged content,
independent of whether this content resides in the portal, Web Content Manager, or IBM Connections.
This way, the portal now provides an easy and convenient approach for searching for content that resides
inside or outside of the portal. For details see the topic about Federating tags.
Portal users can tag or rate portal content. This includes the following types of resources:
v Portal resources, such as pages and portlets
v Web Content Manager resources, such as articles or images
v Custom resources. For example, these can be items in an online store or pictures in a portlet.
Administrators can add these custom resources to the portal so that users can tag or rate them.
In general, all content in a portal that can be uniquely identified can be tagged or rated.
Users can apply tags and ratings both publicly and privately for the following purposes:
v Public tagging and rating helps users categorize, evaluate, and find portal content based on tags and
ratings by other users.
v Private tagging and rating can help users create their own personal way to categorize, evaluate, and
find portal content.
The portal provides two user interfaces for tagging and rating
v The default user interface. It allows users to tag and rate resources, and to view tags and ratings for
multiple resources.
v An alternative user interface that works with inline widgets. This shows tags and ratings for individual
resources in the context of each resource. By default this user interface is available for blogs and wikis.
Administrators can also add this user interface to other types of resources.
In detail, portal users can perform the following tasks:
v Work with tags:
Tag portal content. Users can add tags to portal content, for example, apply the tag websphere to a
page that provides information about IBM WebSphere products. Users can remove tags that they
applied themselves.
View tags and related portal content: Users can view the tags that have been applied to individual
portal resources, for example by invoking the default tag and rating widgets. Users can also work
with aggregated sets of selected tags:
- Users can view tags applied to a set of resources by using a tag cloud. The tag cloud lists the tags
in alphabetical order. Different font sizes indicate how often the tags have been applied.
Overview 17
Depending on how the administrator has configured the tag cloud, the list can be portal wide or
limited to particular items, for example, portal pages, or books available on the page where the
user clicked the tag.
- The tag cloud supports different views: users can switch between these views. For example, they
can view all tags, only tags that they themselves applied, their own private tags, or the tags that
were added most recently.
- Users can switch between different display modes. For example, they can have the tags displayed
in a cloud as previously described, or in a simple list
- Users can use the tags displayed in the tag cloud to search for content. When a user clicks a tag,
the portal shows a list of resources that have that tag applied. Clicking such a resource redirects
the user to that resource itself. Users can also click multiple tags; in this case the list shows only
resources that have all selected tags applied.
- When users work with the list of resources, they can have the list sorted by different criteria, for
example, title, date, rating. The result list portlet also supports two different view modes: a
summary and a detail view.
v Work with ratings:
Rate portal content:
- Users can apply ratings to individual resources to show how much they "like" them. For example,
a user can give a good book a rating of 4.
- Users can change or remove ratings that they applied themselves. For example, a user can update
the previous rating 4 to a 5.
View the ratings that they or other users have applied to portal content.
Administrators can perform the following tasks:
v All tasks that portal users can perform as previously listed.
v Add content that users can tag or rate, for example, books in a bookstore.
v Assign users the access rights for tagging or rating content.
v Configure the tag clouds. By default, a tag cloud shows all tags that have been applied to portal wide
resources. Administrators can add tag clouds to portal pages or themes and configure them as
required. For example, they can limit a tag cloud to display only tags that have been assigned to
resources of a certain category, such as portlets. When users click a tag from that tag cloud, the result
list shows only resources, in this case portlets.
v Move tags to a different portal system, for example, for staging or during migration.
v Obtain basic statistics about tagging and rating. For example, you can obtain the tags and tag counts
for a specific portal page, or all tags that a specific user has applied. You can write queries for more
detailed statistics, or create a user interface to visualize them.
Developers can perform the following tasks:
v Extend the tagging and rating capabilities of the portal by writing a custom user interface that uses the
Java Model API or the REST API.
v Write queries to obtain statistics about tagging and rating, and write a user interface to visualize these
statistics.
v Enable or disable filters, for example to prevent users from using unwanted words as tags. By default
the portal provides a blacklist and a whitelist filter.
Note: Depending on your portal and your user groups, administrators or developers might consider
creating user documentation for tagging and rating to their portal users.
Related concepts:
Tagging and rating on page 2779
Get an overview of the administrative tasks related to tagging and rating.
Integration
WebSphere Portal integrates with many products.
Web application bridge integration
Use the Web Application Bridge to ingrate with web applications, such as Sharepoint.
The web application bridge uses reverse proxy technology to integrate web-based content providers, such
as the Microsoft SharePoint 2007 server, with IBM WebSphere Portal. Administrators must first define the
virtual web applications or content providers. A lightweight IFrame portlet displays the content from the
backend applications. Users can then access the IFrame on a page without requiring direct network access
to the backend application. A special engine maps Uniform Resource Identifiers (URIs) on the iFrame
portlet to real URIs from the content providers.
Integrating the web application bridge with WebSphere Portal is a multistep process. The first part of the
process is creating an application component from the Web application bridge manager portlet. The
second part requires that you add the Web Dock portlet on a page and then configure it to point to the
appropriate application component.
Related concepts:
Integrating with the web application bridge on page 2410
The web application bridge uses reverse proxy technology to integrate web-based content providers, such
as the Microsoft SharePoint 2007 server, with IBM WebSphere Portal. Administrators must first define the
virtual web applications or content providers. A lightweight IFrame portlet displays the content from the
backend applications. Users can then access the IFrame on a page without requiring direct network access
to the backend application. A special engine maps Uniform Resource Identifiers (URIs) on the iFrame
portlet to real URIs from the content providers.
Process integration
Use the Unified Task List portlet to ingrate with business process solutions such as IBM Process Server,
WebSphere Lombardi Edition, and other enterprise resource planning software.
Service-oriented architecture
For greater flexibility, the Unified Task List portlet retrieves data from the configured enterprise resource
planning software. Then the retrieved data is presented in the portal. The Unified Task List portlet can
retrieve data from multiple enterprise resource planning systems and render the result in a cohesive user
interface.
Developer resources
The Unified Task List portlet was developed using Web Experience Factory. You can use Web Experience
Factory builders to develop actions, customize the Unified Task List portlet, and develop custom forms.
You can download a Unified Task List Developer Pack from IBM Lotus and WebSphere Portal Business
Solutions Catalog. The developer pack includes samples models and end-to-end business process
transactions. Learn more about the developer pack in the Web Experience Factory wiki.
Overview 19
Related concepts:
Overview of the Unified Task List portlet on page 2402
Review concepts about the Unified Task List portlet to understand the different elements.
Related tasks:
Configuring Unified Task List portlet at run time on page 2403
You can customize the Unified Task List portlet at run time as a WebSphere Portal administrator.
Customizing at run time involves accessing the deployed Unified Task List to configure the portlet
settings.
Configuring Unified Task List portlet for single sign-on on page 2403
Set up a single sign-on between Process Server, WebSphere Lombardi Edition, IBM Business Process
Manager and WebSphere Portal. Single sign-on (SSO) provides a secure method of authenticating a user
within an environment and applies that authentication to access other applications, systems, and
networks for the duration of the session.
Draft_Unified_Task_List_Developer_Pack
IBM Industry Toolboxes for WebSphere Portal
Industry Toolboxes for WebSphere Portal provide a resource forum for customers and partners. They pair
technology expertise with industry thought leadership to offer best-practice guidance optimized for the
particular business you are in.
Featured industries include:
v Government
v Healthcare
v Banking
v Insurance
v Retail
v Telecommunications
v Industrial
v Travel & Transportation
To learn more about IBM Industry Toolboxes and find available templates, visit IBM.com.
IBM Industry Toolboxes for WebSphere Portal
Application integration
A portal provides access to content, data, and services that are located throughout the enterprise. These
services include predefined connectors and portlets, and tools for creating additional connectors and
portlets.
Enterprise resource planning (ERP) and customer relationship management (CRM) systems are excellent
candidates for portlets because efficient, personalized access to these functions provides measurable
return on your portal investment. IBM provides connectors to enterprise applications using the Java
Connector Architecture (JCA).
Standard Java connectors
JCA is a standard architecture for integrating Java 2 Enterprise Edition (J2EE) applications with enterprise
information systems that are not relational databases. Each of these systems provides native APIs for
identifying a function to call, specifying its input data, and processing its output data. The goal of the
JCA is to provide an independent API for coding these functions.
JCA also defines a standard Service Provider Interface (SPI) for integrating the transaction, security, and
connection management facilities of an application server with those of a transactional resource manager.
Thus, JCA is a standards-based approach to managing connections, transactions, and secure access to
enterprise application systems. IBM JCA connectors provide access to systems such as SAP, PeopleSoft,
J.D. Edwards, Oracle Enterprise Edition, CICS, IMS, and Host-on-Demand. Leveraging its CrossWorlds
acquisition, IBM plans to develop and integrate JCA connectors to many other systems.
Rational Application Developer provides a complete development and unit test environment for
applications that use JCA connectors, Web services, and microflows. Rational Application Developer tools
include support for Web Service Definition Language (WSDL), developer versions of the connectors, the
Web Services Invocation Framework (WSIF), and the microflow engine.
Mobile
A portal is a website that provides users with a single point of access to Web-based resources by
aggregating those resources in one place and by requiring that users log in only to the portal itself, and
not to each portlet they use. WebSphere Portal can also deliver Web content to WAP-enabled devices,
i-Mode phones, Smart phones, and to various Web browsers. In addition, the IBM Mobile Portal
Accelerator multi-channel server and mobile device repository extends portal content dynamically to over
7000 mobile devices, with new updates and devices added as they reach the market.
WebSphere Portal Mobile Experience
Pages are optimized on smartphones, desktops, or almost any device. This optimization is made possible
with the WebSphere Portal Mobile Experience, IBM Web Experience Factory smartphone builders, or the
Mobile Portal Accelerator.
The Mobile Experience demonstrated how to use a lightweight architecture that provides exceptional
performance on mobile devices. You can start with the included sample code and then customize it to
meet your specific business needs.
The Mobile Experience includes:
Sample mobile navigation widgets that follow common mobile application navigation patterns
Sample mobile page layouts that demonstrate common content interaction patterns
The Mobile Experience is available on the IBM Lotus and WebSphere Portal Business Solutions Catalog.
Mobile Solutions from the IBM Lotus and WebSphere Portal Business Solutions Catalog
Mobile Portal Accelerator
If your site needs to support a broad range of mobile devices, the Mobile Portal Accelerator provides a
mobile multi-channel server solution. Mobile Portal Accelerator offers a multi-channel server and mobile
device repository capable of automating web page presentation to over 8400 mobile devices; each
optimized to the display and services capabilities of the mobile devices, including smartphones, tablets,
handheld phones, and kiosk devices. Using this approach, Site developers can author web and content
pages one time. Then, the multi-channel server solution automates the presentation for optimized display
on thousands of mobile devices
IBM Mobile Portal Accelerator information center
Development tools
Both IBM Web Experience Factory and IBM Rational Application Developer include functionality to help
you develop exceptional web experiences for your mobile site visitors.
Overview 21
Web Experience Factory
Web Experience Factory includes new smartphone builders and samples to help developers generate
mobile portlets and pages faster. Automation components include:
Native-looking navigation tabs, lists, buttons, and controls
Scrolling lists with display options, such as thumbnails and multiple line test with multiple styles
Access to smartphone features, such as HTML 5, orientation, and geographical location
Input UI patterns appropriate for smartphones, such as selectable lists and check box lists
Rational Application Developer
Web Experience Factory 8 Documentation
Versatile framework
IBM WebSphere Portal provides users a consistent view of portal applications and allows users to define
specific sets of applications that are presented in a single context. Depending on the requesting device,
the rendering of this application set has to vary to fulfill the requirements of the device.
The tasks of the aggregation, which are repeated with each request coming from the device, are:
v Gather information about the user, the device, and the selected language.
v Select the active portlets from the set of applications to which the user has access.
v Aggregate the output of the active portlets into a coherent, usable display.
WebSphere Portal also provides the ability to create a custom navigation model, which includes such
features as:
v Multilevel navigation
v Customized themes and skins
v Custom navigation - navigation tree can be contributed to by portlets themselves
v Custom arrangement of portlets (and thus content) on a page
Another aspect of the versatile framework is the ability to personalize a user's portal experience, using
"content spots" that render subscribed content based on the user and user's role in the portal.
User experience
Customizing the user's experience is one of the main goals of IBM WebSphere Portal. User and
administrative portlets are provided for customizing content and the look and layout of pages. In
addition, tools are provided that allow subject matter experts to personalize content to the needs and
interests of each site visitor.
Customizing pages
Users can have one or more custom pages and access each one through a different page. A page can
contain a group of pages that is organized for a specific purpose. Each page can have a different set of
portlets. Depending on authorizations, users can change the look and feel of their pages by using skins
and page layouts. Also, page navigation hierarchy is tree-based, allowing any depth of nested pages.
The user or an administrator can set up the contents of each page. Administrators can specify that certain
portlets be required, so that users are unable to move them or to remove them from the pages. Each page
can have its own color scheme and column layout.
Cascading authorization
An administrator can grant or revoke access to customize a page or portion of a page to other
administrators or users. The administrator can determine user's rights to modify a page. Administrators
can control the edit authority that other administrators have on a page and its contents. This is designed
to help organizations enforce policies and consistency, and create region specific portals with some
centrally managed content. This control is best explained through an example.
The first administrator can determine that a page will have three columns and not allow the column
layout to be modified by any other administrators. A second administrator with lesser access cannot
modify the column layout but can add portlets to these columns. The following figure shows a page split
into three columns. Administrators can add portlets to these columns.
The second administrator adds a stock portlet to column one and a company news portlet to column two.
This administrator wants these portlets to be available to everyone and does not want them to be
removed. However, the administrator can add portlets to the columns. Therefore, the portlets are locked
and cannot be removed by other administrators with lesser access. The following figure shows an
example of how cascading authorization from one administrator to another would look.
Overview 23
Skins and themes
WebSphere Portal uses html, cascading style sheets, images, and other standard web design artifacts to
define the look of pages. Java Server Pages (JSP) and other server-side dynamic techniques can also be
used to help define the look of a site. You can add or modify elements to control visual aspects of
WebSphere Portal, perhaps to add company-specific brand elements or to achieve a different color
scheme and visual style. The system for defining color themes and skins supports multiple skins per
theme, additional branding elements, navigation styles, and dynamic, browser-independent cascading
style sheets.
You can apply skins and themes to a page, not only to the overall product. You can apply different skins
individually to portlets as well, so that the appearance of a portal can be fine-tuned to meet any user
need. By using a different theme for each page, a single installation can give the appearance of
supporting many virtual portals.
Branding elements
You can change all visual elements of WebSphere Portal, including the masthead, the navigation areas,
graphics, portlet title areas, and style sheets, to give WebSphere Portal a custom look. You can use
standard file formats, such as JPEG, GIF, CSS, and JSP files, to define the look and layout.
The structure of the component installation folder contains folders named "skin" and "theme," with
folders "html," "wml," and "chtml." These folders contain most of the files that are used for defining the
basic structure of the home page, its color schemes, and portlet decorations. Portal designers can copy
these folders and modify their contents to create a custom look and feel. The theme administration portlet
registers the new files.
Changing portlet layout
You can change the placement of individual portlets on a page by using the drag-and-drop feature. To
rearrange a portlet on a page, click the title bar of the portlet and then drag the portlet to a new location
on the page. You can also add portlets to the page for quick and easy page customization by dragging
portlets from the Portlet Palette to the page.
Personalization
The Personalization component selects content for users, based on information in their profiles and on
business logic. With Personalization facilities, subject matter experts can select content that is suited to the
needs and interests of each site visitor. These web-based tools help companies quickly and easily use
content that is created by business and subject matter experts. Personalization involves three basic
personalization components:
v
User Profile: information about users of the site, including user attributes
Overview 25
v
Content Model: defines attributes about content, such as product descriptions, articles, and other
information
v
Matching Technology: engines that match users to the correct content; includes filtering, rules,
recommendation engines, or combinations of all three.
The Personalization and WebSphere Portal components share a common user profile and content model.
The model is based on the WebSphere resource framework interfaces classes. This means that
personalization rules can easily be added to portlets to select content and target it to WebSphere Portal
registered users.
Personalization classifies site visitors into segments and then targets relevant content to each segment.
Business experts create the rules for classifying users and selecting content, using web-based tools.
Personalization also includes a recommendation engine that provides collaborative filtering capabilities.
Collaborative filtering uses statistical techniques to identify groups of users with similar interests or
behaviors. Inferences can be made about what a particular user might be interested in, based on the
interests of the other members of the group.
New campaign management tools are also included with Personalization. Campaigns are sets of business
rules that work together to accomplish a business objective. For example, an HR manager might want to
run a campaign to encourage employees to enroll in a stock purchase plan. The HR manager would
define a set of rules that are shown to accomplish this business objective. Campaigns have start and stop
dates and times and can be email- and web-page based. Several campaigns can run simultaneously and
can be prioritized.
Implicit profiling services can collect real-time information about site visitor actions and then construct
personalization business rules using this data. To analyze the effectiveness of the site and its
personalization strategies, the server provides reports for the business owner of the site. This helps the
company measure the effectiveness of the business rules and campaigns in achieving its objectives.
Universal access
The system of page templates, themes, skins, and portlet rendering is fully enabled for
internationalization and accessibility by people with disabilities. For globally accessible portals,
WebSphere Portal searches for and selects the proper JSP pages, based on the target browser and its
settings for language and country.
Documentation resources
The starting point for information is the product documentation. The product documentation is delivered
in the WebSphere Portal Family wiki. There are still other sites and resources available to you when
working with WebSphere Portal, but this consolidation is intended to make finding information easier. It
is also intended to drive improvements into the content and let the community edit and comment on the
documentation. Knowing where to look for information can save you time and money. Learn more about
primary and secondary resources for Web Content Manager and WebSphere Portal documentation and
supplemental content.
There are two primary sources for content: the WebSphere Portal Family wiki and WebSphere Portal
Support site. An excellent secondary source is developerWorks, where you can find examples and
tutorial-based articles.
Each content source links to the other sources to help you navigate between the resources. Each content
source has a specific objective and is intended to be used with the other sources.
The product documentation delivered in the wiki (on the Product Documentation tab) is developed by
IBM to help you take advantage of features based on expected usage patterns. You can contribute to the
content to reflect your experience with the product. The wiki content accessed from the Home tab is
developed by the community, both inside and outside of IBM. The intent is to share experiences with the
product and based on actual usage patterns and use cases. The Support content is developed by IBM
Support to help you avoid and diagnose issues with the intent of being as responsive as possible.
WebSphere Portal Wiki
The wiki includes:
v Product Documentation tab which includes:
Overview of the product with new feature highlights, product features, and accessibility
Planning information for deployment
Installation instructions targeted to single server for proof-of-concepts or development servers,
stand-alone production, and clustered production environments
Configuration options that are typically done one time, or infrequently, and have global effect on the
portal
Administration tasks for day to day usage
Integration instructions
Development information to help you develop portlets and applications
Troubleshooting information with logging and tracing information
Messages to help you diagnose and troubleshoot issues
v Supplemental guides, such as the Performance and Tuning Guide
v IBM Redbooks
v Best Practices
v Deployment scenarios
Overview 27
v Multimedia offerings, such as task-based demonstrations and videos
v Reference cards
Key points to remember about the wiki:
v Information previously delivered in the information center is now delivered from the Product
Documentation tab of the wiki.
v The content is experience driven
v You can edit articles, add comments, and author your own articles
v The wiki is monitored by IBM
v You can subscribe to RSS feeds for new articles, comments, and recent edits
WebSphere Portal Support page
The Support page includes:
v Technotes written in response to issues with the product or the documentation
v Fix pack downloads including instructions for applying fixes
v Troubleshooting information
v Flashes for high priority issues
Key points to remember about the Support page:
v You can subscribe to updates and new Support content using MyNotifications
v You can download tools, such as the IBM Support Assistant
Accessibility features
Accessibility features help users who have a physical disability, such as restricted mobility or limited
vision, to use software products successfully.
This version of IBM WebSphere Portal:
v Supports installation through a command-line interface known as console mode. This is the accessible
equivalent of installing by using the graphical user interface.
v Supports interfaces commonly used by screen readers and screen magnifiers (Windows only)
v Supports use of screen-reader software and digital speech synthesizers to hear what is displayed on the
screen.
v Can be operated using only the keyboard
v Allows the user to request more time to complete timed responses
v Supports customization of display attributes such as color, contrast, and font size
v Communicates all information independently of color
v Supports the attachment of alternative input and output devices
v Supports alternatives to audio information
v Supports adjustable volume control
v Does not flash the screen at rates that can induce epileptic seizures
v Provides documentation in an accessible format
Recommended browser: Firefox 10.
Recommended screen reader: JAWS 12.
The documentation includes the following features to aid accessibility:
v All documentation is available in HTML formats to give the maximum opportunity for users to apply
screen-reader software technology.
v All images in the documentation are provided with alternative text so that users with vision
impairments can understand the contents of the images.
When appropriate, the documentation for specific product features contains additional information about
accessibility.
See the related links for information about IBMs commitment to accessibility.
IBM Human Ability and Accessibility Center
Overview 29
Installing
IBM WebSphere Portal provides flexible deployment options ranging from
proof-of-concept where you can examine and test functionality to a highly available and scalable
production environment. Review the planning information to learn more about hardware and software
requirements, high availability, scalability, supported topologies, and much more. Select your operating
system and then select the installation pattern that most reflects your business needs.
Note:
You can run ConfigEngine tasks from a read-only ConfigEngine directory that allows you to manage
multiple profiles from one location or you can run ConfigEngine tasks from the wp_profile_root directory
that you have used in previous releases. For example, to use the ConfigEngine read-only directory, run
the ConfigEngine task in the ConfigEngine folder that is on the same level in the directory structure as
the default wp_profile directory. You can substitute the path to the ConfigEngine read-only directory in
any ConfigEngine task in the product documentation.
Planning to install WebSphere Portal
Before installing IBM WebSphere Portal in a production environment, you need to assess your hardware
and software needs, possible database configurations, security options, and LDAP server options.
Skipping this important step can lead to unexpected results and costly delays.
Restriction: z/OS
does not support the Multiple Profile feature because each IBM WebSphere
Application Server instance has a single profile. However, it is possible to install multiple HFS product
instances that point to the same set of binary files in the SMP/e space. This effectively achieves the same
result as having multiple profiles. See "Installing code through SMP/e" for information about installing
coexisting WebSphere Portal instances.
System requirements
Before installing IBM WebSphere Portal, review the hardware and software requirements to ensure you
have the supported versions of prerequisite and corequisite software as well as the required hardware.
See the detailed system requirements document at the following URL:WebSphere Portal detailed system
requirements
Related tasks:
Recommended Updates for WebSphere Portal and IBM Web Content Manager
Release notes
Known issues and problems are centrally available on the support page. Links into the support
knowledge base are integrated throughout the information center to make sure you have the most current
31
information. Before you start the installation process, check the IBM Support site for the most current
information about known limitations or issues. Use the following dynamic queries to find late breaking
information about this release.
Technotes for installation and configuration issues
Technotes for migration issues
Technotes for database connectivity issues
All technotes for this release
WebSphere Portal Support Statement
This support statement proposes a revision to the definition of supported and unsupported with
respect to the various products of which IBM WebSphere Portal depends on for proper operation.
Introduction
WebSphere Portal requires the use of several collateral products for its normal operations. In particular, it
requires WebSphere Application Server, a database, a repository for user information (typically an LDAP),
and other products depending on specific customer requirements.
During the testing of a new release, Development generally tests WebSphere Portal with a prescribed list
of these collateral products. These products are designated as Supported Products in the documented
hardware and software requirements for that release.
Because the list of Supported Products cannot reasonably describe all possible configurations that a
customer may need to use, some customers have voiced concerns about the level of support that will be
provided for configurations that are not specifically designated as Supported. This document is
intended to provide clarification of the level of support that can be generally expected for the current
release with various combinations of dependent products.
Note: Although the statements in this document reflect the general level of support that can be expected for
WebSphere Portal, the terms and conditions of any specific support offering, license or other Agreement you might
have with IBM will determine the actual delivered support for the product. Nothing herein shall be construed as
supplementing, modifying or superseding the terms of your IBM license agreement for WebSphere Portal or any
other agreement you might have with IBM, nor shall it create any obligation for IBM to deliver a level of support
other than might be set forth in such Agreements.
Categories of Support
There are three (3) categories of support for collateral products to WebSphere Portal. They are Supported
Products, Newer Versions and Releases of Supported Products and Unsupported Products. The
definition and support statement for each category follows:
Supported Product
A Supported Product is a product (at a specified version, release and fix level) that was tested
by Development and is known to work with WebSphere Portal.
Products in this category are supported as per the terms of your WebSphere Portal License
Agreement. PMRs (Problem Management Records) will be accepted by IBM Support in
accordance with the conditions of the WebSphere Portal License Agreement.
Newer Versions and Releases of Supported Products
Many products outside the specific version(s), release(s) or fix pack(s) of the Supported version,
(referenced in the documented hardware and software requirements) may not have been
explicitly tested by IBM WebSphere Development, yet can reasonably be expected to perform
within the accepted bounds of reliability, function and performance by a customer.
Products that fall into this category are typically newer releases or fix levels of a product already
in the Supported Product category or a product that adheres to a standard API that WebSphere
Portal supports (such as an LDAP server). Some specific examples might include a newer
operating system fix level, a WebSphere Application Server (WAS) fix pack newer than the
original Supported fix pack level, an IBM Java (JVM) fix pack, a new fix pack or release of DB2
or an updated LDAP server.
For products that fall into this category, support is as follows:
For IBM products, such as IBM Directory Server or Domino LDAP, IBM DB2, IBM JDKs (JVMs) and
WebSphere Application Server, WebSphere Portal will fully support fix-pack, release and version updates
that do not significantly change interfaces or other underlying support that WebSphere Portal depends on
for its functionality. If and when a newer release of one of these products is shipped that WebSphere Portal
cannot accommodate, that fact will be noted as described in the next section entitled Unsupported
Products. Note that in order for WebSphere Portal to support an update to a database or LDAP product,
WebSphere Application Server must support that update as well.
For non-IBM products, the Support team will make a commercially reasonable effort to support
products in this category. Support will accept problem reports (PMRs) for the appropriate releases
using these untested products. If Support is able to re-create the reported problem using a
Supported version of the product, we will attempt to fix the problem.
If Support is not able to re-create the problem with a Supported version of the product in question and is
not able to resolve the problem on the untested version of the product in question, Support will look to the
support organization for the product in question to provide resolution. Please note that varying degrees of
customer involvement may be necessary to handle this process for non-IBM products.
If the support organization for the untested product in question is unable to resolve the problem, Support
will deem that version, release or fix pack level of the untested product in question to now be an
Unsupported Product.
Unsupported Products
An Unsupported Product is a product (at a specified version, release and fix level) that is
known to not work with WebSphere Portal and is therefore not supported. A product can be
included in this category as a result of an explicit test effort by Development or as a result of
discovery from a prior customer problem. The WebSphere Portal Support team maintains a list,
by release, of all known Unsupported Products published as a techdoc available to all
customers.
WebSphere Application Server has a similar support statement which can be found on the web.
Note: WebSphere Application Server uses specially customized builds of the IBM Java SDKs on
certain platforms. Updates to these must be obtained from WebSphere Application Server
support.
WebSphere Portal can be sensitive to changes in the underlying WebSphere Application Server.
Upgrading to a new fix pack level of the application server is well tolerated and encouraged
(such as from WebSphere Application Server version 8.0 to 8.0.x) as long as all required fixes for
WebSphere Application Server are available as integrated into that fix pack or by applying an
interim fix specifically for that maintenance level. However, upgrading from one version of
WebSphere Application Server to the next (such as from 7.0 to 8.0) is quite problematic if not
done within the context of a migration of versions and should never be attempted with an
in-place system.
For example, an existing instance of WebSphere Portal version 8.0 installed and functioning on
WebSphere Application Server version 8.0 cannot be successfully migrated to WebSphere
Application Server version 8.x simply by using the WebSphere Application Server Migration
Installing 33
Tools. Such attempts may result in a non-functional system. Consult IBM WebSphere Portal
support for more information on such scenarios, if required.
Support for LDAP Servers
LDAP support spans two (2) categories:
Fully tested and supported LDAP servers:
The list of fully tested LDAP servers for each release of WebSphere Portal is documented in the
detailed system requirements for each release. WebSphere Portal support accepts problem reports
for the appropriate WebSphere Portal releases using the tested directory servers. These problem
reports receive high-priority attention. Features that are tested with these directories include
relatively simple search and retrieval functions for user and group objects. Functions outside this
scope, such as the Active Directory Global Catalog feature, are considered advanced features and
have not been tested with WebSphere Portal. WebSphere Portal support encourages customers to
work with their LDAP provider for additional support on these advanced features.
Untested and partially supported LDAP servers:
In general, WebSphere Portal support makes a best effort to support directory servers that have
not been tested with WebSphere Portal. WebSphere Portal support accepts problem reports for the
appropriate WebSphere Portal releases using untested directory servers. If WebSphere Portal
support can re-create the reported problem using a tested LDAP server, staff will attempt to fix
the problem. If the support team is not able to re-create the problem on a tested LDAP server,
customers are referred to the LDAP provider for further assistance.
Support for External Security Managers (ESM)
ESM support spans two (2) categories:
Fully tested and supported ESM software:
The list of fully tested ESM software versions for each release of WebSphere Portal is documented
in the detailed system requirements for each release. WebSphere Portal support accepts problem
reports for the appropriate WebSphere Portal releases using the tested ESM servers. These
problem reports receive high-priority attention. Features that are tested with these software
products include authentication and authorization. Functions outside this scope, such as login
customizations, referrals, impersonation, and step up authentication are considered advanced
features and have not been tested with WebSphere Portal. WebSphere Portal support encourages
customers to work with their ESM provider for additional support on these advanced features.
Untested and partially supported ESM servers:
In general, WebSphere Portal support makes a best effort to support ESM servers that have not
been tested with WebSphere Portal when relying on the ESM for authentication only. WebSphere
Portal support accepts problem reports for the appropriate WebSphere Portal releases using
untested ESM Trust Association Interceptor (TAI) implementations. If WebSphere Portal support
can re-create the reported problem using a tested ESM, staff will attempt to fix the problem. If the
support team is not able to re-create the problem on a tested ESM, customers are referred to the
ESM provider for further assistance.
System requirements
User IDs and passwords
Understanding character limitations for user IDs and passwords is important because they are used
throughout the system to provide access and secure content. The character limitations provided here
apply to the IBM WebSphere Portal administrator, IBM WebSphere Application Server administrator,
database administrator, LDAP server administrator, and user IDs. Database and LDAP servers can have
more restrictive limitations than provided here. Therefore you should check the database and LDAP
server product documentation for restrictions. Failure to correctly define user IDs and passwords during
the installation process can result in installation failure. In addition, your company may have more
restrictive user ID and password requirements that you must also follow.
When a person signs up as a user or when an administrator enrolls a user, they must complete the user
information form. On this form, do not enter characters that might not be supported. Regardless of what
characters you are able to enter on the user information form, user ID and passwords are limited to the
valid characters described here. You can specify other characters in the First Name and Last Name fields.
If your company policy is more restrictive, you can provide that information to your users in the
enrollment form help or as inline help directly on the form.
Important: WebSphere Portal cannot create user IDs or passwords that contain spaces, although it fully
supports any existing user IDs and passwords or those created in the user repository that contain spaces.
Under normal circumstances a valid user ID and password can contain the following characters:
Note: The only supported characters in IBM i are lowercase characters, uppercase characters, numbers,
and the underscore.
Lowercase characters {a-z}
Uppercase characters {A-Z}
Numbers {0-9}
Exclamation point {!}
Open parenthesis {(}
Close parenthesis {)}
Dash {-}; this character is not supported as the first character in the user ID or password
Period {.}; this character is not supported as the first character in the user ID or password
Underscore {_}; this is the only supported special character in IBM i
Grave accent {`}
Tilde {~}
Commercial at {@}, this character is not supported when creating the WebSphere Portal and
WebSphere Application Server administrator during installation.
Important: These are all ASCII characters. Non-ASCII characters are not allowed for username or
password.
Note: (Linux only) Some tasks may require you to enter the fully qualified user ID. If your fully qualified
user ID contains a space; for example: cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software
Group,dc=ibm,dc=com, you must place the fully qualified user ID in the properties file or into a parent
properties file instead of as a flag on the command line. For example, create a parent properties file called
mysecurity.properties, enter the fully qualified user ID, and then run the task: ./ConfigEngine.sh
task_name -DparentProperties=/opt/mysecurity.properties.
Note: (Windows only) Some tasks may require you to enter the fully qualified user ID. If your fully
qualified user ID contains a space; for example:
cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com, you must place
quotes around the fully qualified user ID before running the task; for example,
"cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com".
The following table contains a list of the required fields on the user information form and the supported
characters.
Installing 35
Table 1. Valid characters and unsupported characters for user information
User information Valid characters Unsupported characters
User ID Note: The only supported characters
in IBM i are lowercase characters,
uppercase characters, numbers, and
the underscore.
Numbers {0-9}
Dash {-}; this character is not
supported as the first character in
the user ID or password
Period {.}; this character is not
Underscore {_}; this is the only
supported special character in
IBM i
Grave accent {`}
Tilde {~}
Commercial at {@}, this character
is not supported when creating
the WebSphere Portal and
WebSphere Application Server
administrator during installation.
Only ASCII characters are allowed.
Other restrictions: The user ID
cannot contain spaces; for example,
user name.
Note: User IDs cannot be longer than
200 characters.
Note: z/OS only: User IDs cannot be
longer than 8 characters and must
also conform to the appropriate
guidelines if you use SAF products
such as RACF
.
If you enter any unsupported
characters during the installation, you
will receive an error message that
states which character is invalid. For
example, "The special character [@]
was found in the administrative user
ID field. Enter the administrative
user ID again."
Important: You receive a different
error message if you enter any
unsupported characters when
creating users through the Manage
users and groups portlet.
Table 1. Valid characters and unsupported characters for user information (continued)
User information Valid characters Unsupported characters
Password / Confirm password Note: The only supported characters
in IBM i are lowercase characters,
uppercase characters, numbers, and
the underscore.
Numbers {0-9}
Dash {-}; this character is not
Period {.}; this character is not
Underscore {_}; this is the only
supported special character in
IBM i
Grave accent {`}
Tilde {~}
Commercial at {@}, this character
is not supported when creating
the WebSphere Portal and
administrator during installation.
Diacritics, such as the umlaut, and
DBCS characters are not allowed.
Other restrictions: The password
cannot contain spaces; for example,
pass word.
Note: Passwords cannot be longer
than 128 characters.
Note: Passwords cannot be longer
than 8 characters and must also
conform to the appropriate guidelines
if you use SAF products such as
RACF.
Attention: Login or ConfigEngine
tasks might fail if the password
contains any unsupported characters,
including DBCS characters. This
action happens even if a user is
successfully enrolled using a
password containing DBCS
characters.
If you enter any unsupported
characters during the installation, you
will receive an error message that
states which character is invalid. For
example, "The special character [@]
was found in the password field.
Enter the password again."
First Name All characters n/a
Last Name All characters n/a
Note: The previous characters are true if the user.UNIQUEID.charset parameter is set to ascii. If set to
unicode, the standard Java Letter definition is used and all characters that are recognized as letter or digit
by Java are allowed by default. See the Puma Validation Service section in the "Portal configuration
services" link for information about further parameters that can be modified to affect the behavior of
Portal's validation of users, groups, and passwords.
Portal configuration services on page 2248
IBM WebSphere Portal comprises a framework of services to accommodate the different scenarios that
portals of today need to address. You can configure some of these services.
Server topologies
Topology diagrams help you visualize different configurations that you can setup to support various user
and system load requirements. The topology diagrams are representative of basic configurations.
The single server topology illustrates a simple installation for demonstration, trying the product out, or
development environment purposes. The stand-alone topology illustrates a distributed configuration.
Clustered topologies illustrate more robust and load intensive hardware configurations and IBM Web
Content Manager topologies illustrate how different hardware configuration support various authoring
and system load requirements. To increase capacity and availability, multiple portal servers can be
clustered using IBM WebSphere Application Server Network Deployment, where the portals share a
Installing 37
common configuration and load is distributed evenly across all cluster instances. The high availability
and failover topology illustrates WebSphere Portal in a more complex production environment.
Tip: To increase performance and throughput in all of these topologies, see "Increasing the number of
servant regions".
Increasing the number of servant regions on page 1673
On IBM z/OS, the recommended approach for increasing performance and throughput in a vertical
scaling topology is to increase the number of servant regions for your portal. This option is available
even in a base application server node.
Single-server topology
A single instance of IBM WebSphere Portal provides a fully functional application server and a Web site
that is capable of serving a medium to small user community. Initially, a single instance is configured to
use an internal database based on the default database.
Single server deployments are ideal for development, test, demonstration and education, and, as
mentioned, some small production sites. A single server, however, presents a single point of failure and
must be converted to a cluster or server farm to improve its capacity, availability, and ability to recover
from failure conditions.
As an optional configuration, which is not depicted in the following graphic, you can configure a Web
server, with IBM WebSphere Application Server's HTTP plug-in, at the front of a typical server
deployment for test or production use. The Web server provides the ability to serve static resources, such
as images and style sheets, as well as a plug-in point for a corporate single sign-on (SSO) agent, in the
event that WebSphere Portal participates in a global SSO domain.
The following illustration displays a common topology for a single server environment. Only one server
is needed. WebSphere Portal, WebSphere Application Server, and the database are all installed on the
same server.
Stand-alone server topology
The stand-alone scenario is different from the single-server since the database server, LDAP server, and
Web server software are installed on different physical servers than the IBM WebSphere Portal. This
configuration enables you to distribute the software in your network and therefore distribute the
processing load.
For a stand-alone configuration, you can use an existing, supported database in your network and an
existing, supported LDAP directory. You can configure IBM WebSphere Portal to authenticate with the
LDAP server. The following illustration displays a common topology for a stand-alone server. The HTTP
server, (also referred to as Web server) is installed on a server in a protected network. The LDAP server
and database server are also installed on different servers. WebSphere Portal and WebSphere Application
Server are installed on the same server.
Choose this topology if you do not require a robust clustered environment. You can also use this option
to examine and test functions and features to decide how to accomplish your business goals. You can add
this stand-alone production server to a federated IBM WebSphere Application Server Network
Deployment cell. It creates a federated, unclustered production server.
z/OS only: Federated unclustered deployment
Install a federated, unclustered production server if you require the robustness of a WebSphere
Application Server Network Deployment cell but do not require a clustered environment. You can
also use this option to examine and test functions and features in a managed but unclustered
node. After determining that the functions and features work in a managed, unclustered node,
you can create a clustered environment.
Note: If you choose to install the federated, unclustered production server deployment option,
you can only install one node, referred to as the primary node. You cannot install any additional
portal nodes.
Clustered servers topology
To increase capacity and availability, multiple portal servers can be clustered using IBM WebSphere
Application Server Network Deployment, where the portals share a common configuration and load is
distributed evenly across all cluster instances.
IBM WebSphere Portal comes standard with WebSphere Application Server Network Deployment, a
distribution of IBM WebSphere Application Server that provides a Deployment Manager server type for
centrally managing and clustering a series of servers. To cluster a series of portal servers means that all
portal instances share the same configuration, including database, applications, and portlets, and site
design. The cluster provides a domain against which most administrative actions are performed once and
synchronized with each server in the cluster. This both simplifies administration as well as ensures that
all cluster members are configured and behave identically.
Installing 39
A server cluster also provides a shared domain in which session and cache data can be replicated and
kept consistent across all members of the cluster. The cluster also provides an application synchronization
mechanism that ensures consistent application management (start, stop, updates, etc.) across the cluster.
WebSphere Application Server provides an HTTP Server plug-in that can balance user traffic across all
members of the cluster, and through a feature called session affinity, ensure that a user remains bound
to a specific cluster instance for the duration of their session, to improve efficiency and performance.
Additionally, in the event a cluster member is down, the workload management features of the plug-in
will recognize that the instance is no longer available and will route traffic around it.
You can install IBM WebSphere Virtual Enterprise to create a dynamic cluster that monitors performance
and load information and is able to dynamically create and remove cluster members based on the
workload. WebSphere Virtual Enterprise provides an advanced, intelligent routing function called the On
Demand Router that has all of the features of the HTTP Server plug-in with the additional ability to
define routing and service policies. The On Demand Router is required if you are setting up a dynamic
clustered environment.
There are two types of clusters: vertical and horizontal clusters. Most large-scale deployments are
mixtures of both cluster types.
It is also possible to deploy multiple portal clusters to improve availability, failover, and disaster recovery.
Before installing WebSphere Portal and creating your cluster, you should review all the topics under
Cluster considerations to help you plan a successful cluster deployment.
Cluster considerations on page 99
Application Server Network Deployment. In a cluster the portals share a common configuration and the
load is distributed evenly across all cluster instances.
Vertical cluster topology:
A vertical cluster has more than one cluster instance within a node. A node typically represents a single
physical server in a managed cell, but it is possible to have more than one node per physical server. It is
very simple to add additional vertical clusters to a node, using the Deployment Manager WebSphere
Integrated Solutions Console, as each additional vertical cluster instance replicates the configuration of
the first instance; no additional installation or configuration is necessary.
How many vertical instances that can be created in a single node depends on the availability of physical
resources in the local system (CPU and memory). Too many vertical cluster instances could exhaust the
physical resources of the server, at which point it is appropriate to build horizontal cluster instance to
increase capacity if necessary.
The following diagram illustrates a vertical cluster. A single node has multiple instances of IBM
WebSphere Portal installed. The node is managed by the Deployment Manager. Each instance on the
node authenticates with the same LDAP server and store data in the same database server. Although not
depicted in the illustration, the database and LDAP servers could also be clustered if needed for failover,
increased performance, and high availability.
Combination of horizontal and vertical clusters:
Most large-scale portal sites incorporate a combination of horizontal and vertical clustering to take full
advantage of the resources of a single machine before scaling outward to additional machines.
This graphic depicts two horizontal cluster members, node A and B. Both node A and B have 3 vertical
cluster members.
Installing 41
Multiple clusters:
To improve server availability, failover and disaster recovery, as well as to help span large geographical
deployments, it is best to consider deploying multiple portal clusters for the same portal site. With
multiple clusters, one cluster can be taken out of production use, upgraded and tested while leaving
other clusters in production. This is the best means of achieving 100% availability without requiring
maintenance windows. It is also possible to deploy clusters closer to the people they serve, improving the
responsiveness of the content they provide.
When deploying multiple portal clusters, for the most part, each cluster should be seen as a totally
isolated system. Each cluster is administered independently and has its own configuration, isolated from
the other clusters. This improves the portal topology's ability to be maintained while protecting its high
availability. The only exception to this rule is with the sharing of some of the portal database domains,
the Community and Customization domains specifically, which are designed to be shared across multiple
clusters presenting the same portal site. These domains store portal configuration data owned by the
users themselves, and so it is important to keep this data synchronized across all identical portal clusters.
See Database considerations for more information.
Each cluster can be deployed within the same data center, to help with improving maintainability and
improve failure isolation, or across multiple data centers, to protect against natural disaster and data
center failure, or to simply provide a broader geographical coverage of your portal site. The farther apart
the clusters are, the higher the impact network latency may have between clusters and thus the less likely
you will be to want to share the same physical database between clusters for the shared domains and
will want to resort to database replication techniques to keep the databases synchronized.
Typically, in a multiple portal cluster topology, HTTP Servers are dedicated per cluster, since the HTTP
Server plug-in's configuration is cell-specific. To route traffic between data centers (banks of HTTP
Servers), a separate network load-balancing appliance is used, with rules in place to route users to
specific datacenters, either based on locality or on random site selection, such as through DNS resolution.
Domain, or locality, based data center selection is preferred because is predictably keeps the same user
routed to the same datacenter, which helps preserve session affinity and optimum efficiency. Be mindful
of the fact that DNS resolution based routing selection can cause random behavior in terms of suddenly
routing users to another datacenter during a live session. If this happens, the user's experience with the
portal site may be disrupted as the user is authenticated and attempts to resume at the last point in the
new site. Session replication and/or proper use of portlet render parameters can help diminish this effect.
You can decide to adopt one of the following configurations with your multiple portal clusters:
Active/active
In this configuration, all portal clusters are receiving user traffic simultaneously. Network load
balancers and HTTP Servers help keep the traffic balanced evenly across each server in each
cluster. If maintenance on one cluster is required, all production traffic is switched to the other
cluster. That means that the topology must be sized such that the remaining active clusters must
be able to handle all production traffic while on cluster is undergoing maintenance, or that
maintenance must be performed during off-peak hours.
Active/passive
In this configuration, under normal circumstances, all production traffic is routed to a subset of
the available portal clusters (e.g. 1 of 2, or 2 of 3). There is always one cluster not receiving any
traffic. Maintenance is typically applied first to the offline cluster, and then it is brought into
production traffic while each of the remaining clusters are taken out and maintained in a similar
fashion. This requires that a subset of the clusters be sized to handle all production traffic.
As an alternative to deploying multiple portal clusters where each cluster is in a different cell, it is also
possible to deploy multiple portal clusters in the same cell. Different cells give you total isolation between
clusters, and the freedom to maintain all aspects of each cluster without affecting the other. Different
cells, however, require different Deployment Managers and thus different Administration Consoles for
managing each cluster. Multiple clusters in the same cell reduces the administration efforts to a single
console, but raises the effort level to maintain the clusters since there is a high degree of resource sharing
between the multiple clusters.
While multiple portal clusters in a single cell has its uses, especially in consolidating content authoring
and rendering servers for a single tier, it does increase the administrative complexity significantly. It is
recommended that multiple portal clusters be deployed in multiple cells, to keep administration as
simple as possible. See Multiple portal clusters in a single cell for more details.
Installing 43
Database considerations on page 66
A simple development environment can rely on the out-of-box database configuration using Apache
Derby. Installing with Derby lets you quickly get IBM WebSphere Portal installed and running in a
proof-of-concept environment. For a production environment, you must use one of the other supported
Database Management Systems.
Installing multiple clusters in a single cell on AIX on page 452
Create a new, independent IBM WebSphere Portal cluster in a cell where a WebSphere Portal cluster
already exists.
Installing multiple clusters in a single cell on IBM i on page 584
already exists.
Installing multiple clusters in a single cell on Linux on page 901
already exists.
Installing multiple clusters in a single cell on Solaris on page 1217
already exists.
Installing multiple clusters in a single cell on Windows on page 1531
already exists.
Installing multiple clusters in a single cell on z/OS on page 1678
When creating multiple clusters in a single cell, you create the first cluster in the cell, which includes
installing the primary server, transferring your database, configuring your security, creating the cluster,
and validating the cluster. You then create the subsequent clusters, which includes installing the primary
server, transferring your database, creating the cluster, and validating the cluster; you do not configure
security on the subsequent clusters. You can then add additional nodes to the clusters that you created.
Portal farm topology
A portal farm topology has a series of identically configured, stand-alone server instances. Server farms
offer a simple way to build and maintain a highly scalable, highly available server environment.
Restriction: This feature does not apply to Express editions or Enable edition when installed on z/OS.
This graphic represents a series of identically configured, stand-alone server instances with a browser
client and network load balance on the front-end and a common database domain on the back-end.
Installing 45
When to choose a clustered or a portal farm deployment:
There are benefits to choosing a clustered deployment and there are benefits to choosing a portal farm
environment. These benefits include performance and administering benefits. This information explains
when to choose a clustered or portal farm deployment scenario.
When to choose a clustered deployment:
You may want to choose a clustered deployment if any of the following items match your business needs:
v You prefer a comprehensive central administration point (which the Deployment Manager provides)
rather than owning the responsibility of administering resources on each server separately.
v You have services that require only one instance running in the cell (such as an EJB or other service
implemented as a JCA connector) instead of on each server in the cluster.
v You have scheduled tasks that should run only in one server of the cluster instead of in each server of
a farm
When to choose a portal farm deployment:
You may want to choose a portal farm deployment if any of the following items match your business
needs:
v You require a more dynamic expansion and contraction of capacity by adding or removing machines,
such as in a cloud-computing environment.
v You have a large deployment; for example, a hundred or more server instances; that would otherwise
stretch the boundaries of a managed cell.
v You are comfortable automating administrative actions across a series of identical servers, such as
restarting servers or applications, that the Deployment Manager would otherwise perform in a cluster.
v You do not require multiple clusters to provide continuous availability during maintenance and
application updates.
Portal farm considerations:
The term "farm" refers to a series of identically configured, standalone server instances. The fact that they
are standalone allows for the farm to be increased or decreased in size without having to worry about
complex cluster configurations or inter-server awareness. Server farms offer a very simple way to build
and maintain a highly scalable, highly available server environment.
There is a cost associated with the simplicity of the portal farm, which stems from not gaining the
benefits from the application server clustering. Understanding these limitations and whether or not they
pose any business risk is imperative to understanding if a portal farm is a suitable deployment pattern.
Common operating systems (shared installations only)
Each farm instance, including the original IBM WebSphere Portal installation in the farm, must be
on the same operating system, including Linux variations, when a shared file system is used.
Session persistence and replication
Session persistence and replication is possible only through using a distributed session database.
All WebSphere Portal farm instances need to specify the same database and session table if
session persistence and replication is required. WebSphere Portal, by default, does not require an
enabled session persistence.
Dynamic cache replication
Dynamic cache replication is not supported across a farm of standalone instances; therefore, you
must independently maintain caches on each farm instance. This means cache expirations should
be configured to ensure updates to portal configuration and published content are visible within
a reasonable amount of time. What "reasonable" is depends on your business requirements. See
the "Cache management considerations for portal farms" link for additional information about
caching.
No cell to manage the synchronization of application server configuration updates (unique farm
installations only)
There is no cell to manage the synchronization of application server configuration updates, which
means that any update to the application server configuration, such as an update to an enterprise
application or change to a datasource configuration, must be repeated on every server in the
farm.
Each portal instance must have its own release database (unique farm installations only)
Each portal instance must have its own release database, which means that portal configuration
updates must be made to every portal instance on the farm.
Portal search
Portal search should be configured like it was part of a clustered environment. The search server
should be set up as a separate portal instance outside the farm, which is configured to search the
farm. See the "Using remote search service" link for information.
Shared resources (shared installation only)
Ensure that all system resources, such as Java classes and JDBC, are placed within the shared
filesystem that each server in the farm uses so that they can be found when the portal instance is
started.
Security
Every farm instance should have an identical security configuration, including identical user repository
configuration, for example LDAP server, to ensure each farm instance has access to the same user and
Installing 47
group information and participates seamlessly in the same single sign-on strategy.
Using remote search service on page 2702
You can configure the search portlets for local operation, or you can configure them for remote search
service. Depending on your configuration, remote search service might have performance benefits by
offloading and balancing system load.
Multiple profile support on page 116
IBM WebSphere Portal creates an application server configuration profile to represent its application
server configuration, such as datasource definitions, web application and portlet deployments, and Java
virtual machine configuration. A configuration profile represents the full configuration of a single portal
instance. Multiple profiles give you the ability to have multiple, independently configured portal
instances running from the same installation. Before WebSphere Portal Version 7, there was only one
configuration profile per installation, which was typically named wp_profile.
Caching on page 2225
Caching affects the performance of your IBM WebSphere Portal environment. Learn about some simple
ways to improve the caching performance. After you have reviewed this content, you should also review
the WebSphere Portal and Web Content Manager Performance Tuning Guide which provides more
information about caches for both WebSphere Portal and Web Content Manager.
Setting up and maintaining a portal farm on page 1731
and maintain a highly scalable, highly available server environment. Creating the farm requires an
established content subscriber, two or more installed instances of IBM WebSphere Portal, and a
configured Web server for load balancing; this documentation only covers the HTTP server plug-in but
you can use any supported Web server.
Cache management considerations for portal farms:
Because the server instances are independent, there is no coordination of dynamic cache content or
invalidations of that content. It is possible, therefore, for changes made on one server to not be seen
immediately on another server in the farm. For this reason, it is important to configure caches to expire
within a reasonable amount of time to ensure updates are seen in a timely manner without compromising
the benefit of caching.
Primarily, there are the following two areas of caching within WebSphere Portal:
Portal caches
Portal caches cover portal configurations, such as navigation, page layout, and access control.
These are automatically configured to expire although time varies by cache. In general, most
updates are seen immediately on a server where administrative changes are made directly and/or
when a user logs off and then back into WebSphere Portal.
In a farm of unique installations, since administrative actions are necessary against all servers and
must be applied to all servers manually, expiration of the portal caches should not be a general
concern.
For shared configurations, configuration changes will generally appear across the farm when their
caches expire, or when individual servers are restarted. See the Caching topic in the Related
information for additional details.
Content caches
Content caches require special attention. Content caches are updated when a content item
changes either through authoring activity or syndication. In a farming scenario, one server is
designated as the subscriber for content syndication. Syndication will update the cache on this
server as normal. A content cache invalidation message bean must be deployed on servers in the
farm, consuming messages from the subscriber server. By consuming content item update
messages from the subscriber, the content caches on all servers can be kept in sync and
up-to-date.
Caching on page 2225
Caching affects the performance of your IBM WebSphere Portal environment. Learn about some simple
ways to improve the caching performance. After you have reviewed this content, you should also review
the WebSphere Portal and Web Content Manager Performance Tuning Guide which provides more
information about caches for both WebSphere Portal and Web Content Manager.
Portal farm setup options:
Before you begin the installation and setup process, learn about the different configuration options for a
portal farm.
Choose one of the following approaches to setup each instance in the farm:
v WebSphere Portal can be simply installed on each server that is to contribute to the farm. This process
can be expedited using either of the following approaches:
Virtualization technology, such as VMWare, can be used to mass-replicate identical operating
systems installed and configured with WebSphere Portal.
Portal cloning, the ability to mass-replicate a fully configured WebSphere Portal installation, can be
used to quickly setup a series of identical servers without requiring virtualization technology. Go to
WebSphere Portal Zone on developerWorks and search on "cloning" to find the latest version of this
guide.
v A single installation and profile can be shared across multiple systems. With some specific
configuration changes to ensure server-specific mutable files go outside the shared filesystem, it is
possible to very quickly create new portal instances (processes) by sharing the installation and
configuration filesystem of the original server and simply starting a new server instance, as you would
on the original server. Because the server configurations are shared, all farm instances have the exact
configuration and reuse the exact some database domains.
Database sharing and load balancing for portal farms:
There are unique considerations for database sharing and load balancing in a portal farm configuration.
Database sharing
If the independent server installation approach is used for building a farm, all database domains can be
shared except for the release domain. Every farm instance requires its own release database, or more
specifically, every application server profile requires its own release database. In the case of a shared
filesystem portal farm, all database domains can be shared because the application server configuration to
which the release data is bound is also shared.
Load balancing
Maintaining affinity between a client and a particular farm server instance is important, both for efficient
caching and performance, as well as to ensure proper login function. During the login process, several
request steps are required to the same server. Moving between servers during the login process can cause
the login to fail.
There are many commercially available network appliances that support load balancing across servers
with affinity. WebSphere Portal comes with the IBM HTTP Server whose application plugin supports load
balancing across servers as well. Load balancing with the application server plugin assumes an
application server cluster is in use, so to make use of this technique requires some extra configuration.
Installing 49
See "Setting up a portal farm" for information about how to set up the HTTP Server to serve the portal
farm.
Setting up farm instances as unique installations on page 1731
Choose this option if you want all portal farm instances to be unique installations. This option allows you
to have more control over the server-specific configuration as they are unique from server to server. For
example, this allows you to easily apply and test changes or application updates to one server on the
farm at a time. The disadvantage to this option is that all administrative actions must be repeated on
every server in the farm.
Single-server topology for Web Content Manager
Organizations that only need a small web site or intranet site could implement a single server topology
for IBM Web Content Manager. In a single server configuration, authoring and delivery occur on the
same server. This configuration is not recommended for organizations that need a larger Web site or
intranet site.
The following topology diagram illustrates a single-server configuration for Web Content Manager. A
Web server routes incoming requests from browser clients. Web Content Manager, IBM WebSphere Portal,
and IBM WebSphere Application Server are installed on the same server. The LDAP server that stores
authorized user information is installed on a dedicated server. The database that stores content is also
installed an a dedicated server. Although this diagram does not illustrate a cluster configuration, the Web
Content Manager server could be clustered. Similarly the LDAP and database servers could be clustered
for failover.
The following actions occur on the single server:
v Create drafts
v Approve drafts
v Test changes
v Publish changes
v Host content
Hardware and resource considerations
v Authoring and delivering content within the same environment is resource intensive, so the type of
environment you deploy needs to be robust enough to allow authoring and delivery to occur at the
same time. Using clustered servers is a common solution for a single-server configuration.
v Content can be delivered using either a web content viewer portlet, the web content servlet or a
pre-rendered site.
Dual-server configuration for Web Content Manager
Organizations that need a large website with heavy traffic or that have multiple users authoring content
should implement a dual-server configuration. In a dual-server configuration authoring is conducted on
one server, or server cluster, and content is delivered to a different server, or server cluster. Authors
access and work on the authoring server while website users access the delivery server. This option
reduces the load on each server and allows you to locate your authoring environment behind a firewall.
This diagram illustrates a dual server environment for IBM Web Content Manager. Both the delivery and
authoring server access the same LDAP and database server in order to access common users, users
groups, and content. Using the same LDAP configuration is critical for Web Content Manager. Website
users access the site through a web server that directs the user to the delivery server. On the delivery
server you can use either the web content viewer, as illustrated in the diagram, a web content servlet, or
a pre-rendered site. New content is syndicated or published to the delivery server.
On the authoring server the following actions occur:
v Create drafts
v Approve drafts
v Test changes
v Publish changes
v Syndicate changes to the delivery server
On the delivery server the following actions occur:
v Host content
v Subscribe to content changes
v An authoring environment would normally be a clustered environment to cope with a large number of
website creators and web content authors.
v The delivery environment can be a:
Installing 51
Web content delivery server or cluster that subscribes to the authoring environment. Content can be
delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
Local WebSphere Portal production environment that subscribes to the authoring environment and
delivers web content using a web content viewer.
Remote WebSphere Portal production environment that uses WSRP and a web content viewer to
display content from the authoring environment.
v A firewall is not depicted in this illustration, but could exist between the authoring and delivery server
if required.
Syndication options
There are two syndication options to consider:
Automatic one-way syndication
With this option, changes made in the authoring environment are automatically syndicated to the
delivery environment. You would implement this option when you want changes to your content
to constantly be updated on the live site.
Manual one-way syndication
With this option, changes made in the authoring environment are syndicated to the delivery
environment in a single batch. You would implement this option when you only want to update
your live site on set dates. The changes you make on your authoring server gradually accumulate
until you are ready to go live with those changes.
Related concepts:
Web content authoring environments on page 56
An authoring environment is used to create and manage web content and is used by your content
creators and website designers.
Web content delivery environments on page 61
A delivery environment is used to deliver content to your website viewers.
Staging-server topology for Web Content Manager
If you need to deliver large complex web sites with a large number of site users and content creator,
implement a staging server configuration. Implementing a staging server provides an environment for
checking for accuracy, issues with the design, and performance. With a staging server configuration
authoring, staging and delivery are separated onto different servers. The staging environment can be
used for testing or to allow changes from the authoring environment to accumulate prior to syndicating
the changes to the delivery environment in a single batch.
The following diagram illustrates a staging server topology. There is a different server, or cluster of
servers, for the delivery, staging, and authoring environments. The delivery, staging, authoring
environment all access the same LDAP. If needed the LDAP and database servers can be clustered too.
web site users access the delivery server through the web server. Authors access the authoring server and
content is syndicated to the staging server for quality assurance verification before it is published to the
delivery server.
On the authoring server the following activities occur:
v Create drafts
v Approve drafts
v Test changes
v Publish new and changed content
v Syndicate content to the staging server
On the staging server the following activities occur
v User assurance testing
v Performance testing
v Syndicate content to the delivery server
On the delivery server, the following activities occur:
v Host content for web site users
v An authoring environment would normally be a clustered environment to cope with a large number of
web site creators and web content authors.
v The staging environment can consist of:
A web content delivery server or cluster that subscribes to the authoring environment. This would
be used when you want to allow changes from the authoring environment to accumulate prior to
syndicating your changes to your delivery environment in a single batch.
Installing 53
A complete replica of the delivery environment. This type of environment would be used for system
UAT to ensure that the web site being delivered is accurate, error-free and can perform under load.
v The delivery environment can consist of:
A web content delivery server or cluster that subscribes to the staging environment. Content can be
delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
A local WebSphere Portal production environment that subscribes to the staging environment and
delivers web content using a web content viewer.
A remote WebSphere Portal production environment. In this scenario a web content delivery server
subscribes from the staging environment, and the remote WebSphere Portal production environment
uses WSRP and a web content viewer to display content from the web content delivery server.
Syndication options
v Automatic one-way syndication from the authoring environment to the staging environment.
v Manual one-way syndication from the staging environment to the delivery environment.
Web Content Manager environments
To use a Web Content Manager system, you will need to deploy a set of Web Content Manager
environments within your overall WebSphere Portal system. Reviewing the Web Content Manager
environments help you understand what happens in each environment and how you may want to setup
your physical severs. Web Content Manager is installed using the WebSphere Portal installation user
interface.
Each server or cluster in your web content system requires a separate data repository, but they would
usually share the same LDAP. A Web Content Manager system can be deployed in isolation or in parallel
with a WebSphere Portal system.
Web content system overview
The type of web content system you deploy is determined by the size of your web content system, the
type of website being delivered and the number of users creating and viewing your web content.
Web content system types
There are three main types of web content systems:
Single environment systems
This is where authoring and delivery occur within a single environment. This type of
environment would be deployed by a small organization delivering a small website, such as an
intranet. Authoring and delivering content within the same environment can be resource
intensive, so the type of environment you deploy needs to be robust enough to allow authoring
and delivery to occur at the same time. For example, using clustered servers is a common
solution for a single instance system.
Dual environment systems
This is where authoring and delivery are split into different environments. This model reduces
the load on both authoring and delivery and also allows you to locate your authoring
environment behind a firewall. This type of system would be used when delivering externally
facing websites, or where you have many users authoring content or many users viewing a
website.
Staged systems
This is where a staging environment is added between the authoring and delivery environments.
The staging environment can be used for user acceptance testing (UAT) or to allow to accumulate
changes from your authoring environment before syndicating your changes to your delivery
environment in a single batch. This system would be deployed when delivering large, complex
sites with many content creators and you need to ensure that the website being delivered is
accurate, error-free and can perform under load.
Installing 55
Environment types
Authoring environment
An authoring environment is used to create and manage web content. This is the environment
used by your content creators and website designers. An authoring system can consist of:
v an authoring server or cluster.
v individual UAT servers where site and content updates can be tested before being syndicated
to the delivery environment.
Staging environment
A staging environment can consist of:
v individual holding servers where changes from your authoring environment can be
accumulated before syndicating your changes to your delivery environment in a single batch.
Pairs of holding servers can be used to provide you with built-in redundancy.
v a complete replica of your delivery environment where UAT can occur to both review site and
content updates, and to test the performance of your delivery environment.
Delivery environment
This environment is used by your website viewers. A delivery environment can consist of:
v pre-rendered sites where a web content site is pre-rendered as a set of HTML files which are
then used to deliver a static website.
v a WebSphere Portal server or cluster where content is delivered using a servlet. Servlet delivery
is used to deliver websites that contain dynamic content, but do not include any WebSphere
Portal content or applications.
v a WebSphere Portal server or cluster where content is delivered using either a local or remote
web content viewer portlet. web content viewer portlets are used to deliver websites that
contain dynamic web content alongside other portlets or applications.
v A combination of the previous three.
Web content authoring environments
An authoring environment is used to create and manage web content and is used by your content
creators and website designers.
Server type
Most Web Content Manager sites need to support many content creators. A clustered server solution is
the best solution for this scenario.
Standard authoring environment
A standard authoring environment consists of a single authoring cluster that syndicates directly to either
a staging or delivery environment. The authoring environment may be used to create drafts, approve
drafts, test changes, publish changes, and syndicate to the delivery environment. For example:
Authoring environment with testing
You can add a test environment to your authoring environment to enable you to perform user acceptance
testing on your content management system and website. You can create drafts, approve changes, test
changes, and syndicate to staging from the authoring environment. In the Site UAT environment, you can
publish the changes, have the system test the changes, and syndicate to the authoring environment. From
the authoring environment, you can syndicate to the delivery environment. For example:
Installing 57
Decentralized authoring environments
If you content creators are located at different locations, or you have different groups of content creators,
you might consider deploying a set of decentralized authoring clusters. This scenario works best if the
decentralized content creators work with separate content stored in different content libraries.
For example, if you have users located in different locations, it may be more efficient to install a local
authoring environment at each location. Two-way syndication is used between all authoring
environments with a centralized authoring environment to allow changes made at all remote locations to
be visible to all users.
Decentralized authoring creates the risk of conflicting updates between authoring environments. To
reduce the risk of conflicts, you can allocate different sites, or different sections of a site, to each
authoring environment. You can also use different authoring environments for different user roles. For
example, Content creators could use a different authoring environment than presentation template
designers.
Access to each decentralized authoring environment is controlled using a combination of authoring
portlet access controls and item security settings. For example, Only users requiring access to the local
authoring environment would be granted access to the local authoring portlet. Users would be given
"Read" access to all items, but only "Edit" access to items they are required to update.
Installing 59
Related concepts:
Dual-server configuration for Web Content Manager on page 51
Web content testing environments
This environment is used by your testers and can be as simple as an individual server where site and
content updates can be tested before being syndicated to the delivery environment, or as complex as
complete replica of your delivery environment where testing can occur to both review site and content
updates, and to test the performance of your delivery environment. It can also be used to accumulate
changes from your authoring environment before syndicating your changes to your delivery environment
in a single batch.
Site testing within an authoring environment
When testing within an authoring environment a testing server is paired with an authoring server. The
testing server simulates the delivery environment and is used to test major changes to a website. You can
add a testing environment to your authoring environment to enable user acceptance testing to be
performed on your content management system and your website:
System testing within a staging environment
When testing within a staging environment, data from the authoring environment is syndicated to a
staging server where user acceptance testing is performed. If all tests are passed, data is then syndicated
from the staging server to the delivery environment. You can perform system testing on a replica of your
delivery environment before syndicating your changes to the live delivery environment:
Web content delivery environments
A delivery environment is used to deliver content to your website viewers.
Pre-rendered delivery
You can pre-render a complete website into HTML and save it to disk. The pre-rendered site can then be
used as your live site and displayed to users using either Web Content Manager or a web server. You
deploy a pre-rendered site when you are not using any WebSphere Portal features, such as portlets, and
your content is static and is only updated periodically.
In a pre-rendered delivery environment, content is syndicated from the authoring server to the delivery
server. The content is converted into a set of static HTML files, which are then displayed to users through
a web server.
Installing 61
Servlet delivery
Users can access content displayed using the Web Content Manager servlet. A servlet delivered website is
used when you do not need to use any portlet-based features such as authoring tools.
In a servlet delivery environment, content is syndicated from the authoring server to the delivery server.
The content is displayed by the Web Content Manager servlet and made available to users through a web
server.
Local web content viewer delivery
Web content viewers are portlets that display content from a web content library as part of a portal page.
If your presentation is simple, a single web content viewer can be sufficient, but you can also use
multiple web content viewers to aggregate content from different libraries and provide a richer
experience for your users. A local web content view portlet is used to display content within your web
content delivery environment.
In a delivery environment using a local web content viewer, content is syndicated from the authoring
server to the delivery server. It is displayed to users through a web content viewer portlet in a portal.
When a local web content viewer is used, the web content viewer is installed on the same server as Web
Content Manager.
Remote web content viewer delivery
WSRP support in the web content viewer is used to display content on a remote WebSphere Portal server
or cluster.
In a delivery environment using a remote web content viewer, content is syndicated from the authoring
server to a Web Content Manager server in the delivery environment. The web content viewer is installed
on the Web Content Manager server. It is configured to communicate with the WSRP proxy portlet
installed on another portal server in the delivery environment. Users view web content by accessing the
proxy portlet on the remote portal server, typically through a web server.
Related concepts:
Dual-server configuration for Web Content Manager on page 51
Port assignments
Before you install IBM WebSphere Portal, you must plan the port assignments for your system to ensure
that you do not have a port conflict.
Installing 63
Review the Default port assignments file in the IBM WebSphere Application Server for z/OS Information
Center to determine what ports may already be taken.
Contact your ports administrator to request a series of ports to use for your WebSphere Portal
installation.
Web servers
By default IBM WebSphere Portal uses the internal HTTP transport within IBM WebSphere Application
Server to handle requests. However, because WebSphere Application Server also supports the use of an
external web server, you can access WebSphere Portal from your web server. You can use a local web
server on the same machine as WebSphere Portal or you can use a remote web server on a different
machine. A remote web server is typical for a production environment or other high-traffic configuration
and is also typically placed in demilitarized zones (DMZ) outside a firewall to protect portal ports.
To enable communication between the web server and WebSphere Application Server, a web server
plug-in is required. The web server plug-in determines whether a request is handled by the web server or
by the application server. The plug-in can be installed into a web server that is located either on the same
machine as WebSphere Application Server or on a separate machine. The web server plug-in uses an
XML configuration file (plugin-cfg.xml) that contains settings that describe how to handle and pass on
requests to the WebSphere Application Server made accessible through the plug-in.
In the WebSphere Integrated Solutions Console, the web server is represented as a specific server type,
and you can view or modify all of the configuration properties used in the plugin-cfg.xml file for the
web server plug-in from the WebSphere Integrated Solutions Console.
Note: For some portal functions to work you need to make sure that write and delete operations are
permitted by the web server so that the HTTP operations POST, PUT, and DELETE are enabled. For
example, this is required for the portal Universal Toolbar.
IBM i users: For detailed information on using an external web server with your IBM i system, see
Selecting a web server topology diagram and road map, in addition to the steps listed on this page.
Access WebSphere Portal through another HTTP port in a stand-alone or clustered
environment
By default WebSphere Portal is configured to be accessed through the internal HTTP port in WebSphere
Application Server. For example, http://hostname.example.com:10039/wps/portal, where
hostname.example.com is the fully qualified host name of the machine where Portal is running and 10039 is
the default transport port that is created by WebSphere Application Server; the port number may be
different for your environment. The default host name and port used by WebSphere Portal are specified
by the WpsHostName and WpsHostPort properties in the wkplc.properties file.
z/OS only: By default WebSphere Portal is configured to be accessed through the internal HTTP port in
WebSphere Application Server. For example, http://hostname.example.com:10039/wps/portal, where
hostname.example.com is the fully qualified host name of the machine where Portal is running and 10039 is
the default transport port that is created by WebSphere Application Server; the port number may be
different for your environment. WebSphere Portal uses the default host name that is specified on the
Server configuration panel when you configure the base portal. You can either accept the default port
numbers or you can specify your own port values. You can also change the port number after
configuring the base portal; see Changing ports on page 2196 for information.
After configuring WebSphere Portal to use an external web server, you access the portal with the web
server host name and port (for example, 80). For stand-alone servers or vertical cluster members, you will
be unable to access the portal using the WebSphere Portal host name and port (for example, 10039),
unless there is a corresponding virtual host definition for port 10039 in the WebSphere Application Server
configuration.
z/OS only: After configuring WebSphere Portal to use an external web server, you can access the portal
with the web server host name and port. You can not access the portal using the WebSphere Portal host
name and port (for example, 9081), unless there is a corresponding virtual host definition for that port in
the WebSphere Application Server configuration.
Many of the WebSphere Portal configuration tasks rely on the WpsHostName and WpsHostPort properties
from the wkplc.properties file. You must ensure that WebSphere Portal can be accessed using the host
name and port specified by these property values. You can do this in one of two ways:
v Modify the WpsHostName and WpsHostPort property values to specify the web server host name and
port.
v Add the appropriate virtual host definition.
If you want to access WebSphere Portal using a host name and port different from your web server, add
the required virtual host definition using the WebSphere Integrated Solutions Console. If you are using
the web server in a clustered environment, use the deployment manager WebSphere Integrated Solutions
Console to complete these steps.
1. Go to Environment > Virtual Hosts.
2. Select the default_host entry or the entry for the virtual host that is being used to access the
WebSphere Portal application.
3. Select Host Aliases, and verify whether there is a host name and port entry corresponding to the
values used to access WebSphere Portal. If the entry does not exist, select New, and enter the
information for the host name and port you want to use. The host alias examples are:
v *:10039
v *:9081
4. Save your changes.
5. Regenerate the web server plug-in.
6. If you are using a remote web server, copy the updated plugin-cfg.xml file to the web server in the
web server home directory.
7. If you are running a system under stress and are expecting requests to take longer than the
ServerIOTimeout default value, you should increase this value to avoid requests being sent twice.
8. Recycle your web server, and your portal.
9. In a clustered environment, resynchronize the nodes and restart the cluster.
Cluster considerations for web servers
When using a web server in a clustered environment with WebSphere Portal, the following considerations
apply:
v If you run the configureweb_server_name script on the deployment manager system, you must
synchronize and restart the cluster to ensure proper communication between the web server and the
cluster members.
v If a stand-alone WebSphere Portal node was previously configured for a web server and then federated
into a cell managed by the deployment manager, the web server definitions on that node are removed.
If you want to use the web server, you must re-create the definition in the deployment manager
WebSphere Integrated Solutions Console after you federate the node.
Installing 65
Database considerations
A simple development environment can rely on the out-of-box database configuration using Apache
Derby. Installing with Derby lets you quickly get IBM WebSphere Portal installed and running in a
proof-of-concept environment. For a production environment, you must use one of the other supported
Database Management Systems.
Data storage and failover become more complex as the network environment becomes complex. In a
complex and high-demand environment, data may be distributed across multiple database servers for
high-volume storage and failover configuration. For example, in a production environment, the demand
for quick response time in a high-demand situation combined with the need for failover capability
distributed across multiple database servers is likely to require transferring the database to a more robust
server. Therefore, learn the limitations of using Derby and determine how transferring to another
database affects the capacity and scalability of an environment. Also consider that the version of Derby
provided with WebSphere Portal has stress and failover limitations that are expected to be resolved in a
later release of Derby performance improvements.
Derby is a built-in Java database that provides a small footprint, is self tuning, and is ideal for solutions
where the database must be hidden. Derby works in a non-clustered environment with a small number of
users, such as a portlet development or testing environment or a proof-of-concept environment.
Web Content Manager and Derby: Although the Derby database can be sufficient for non-production
installations of WebSphere Portal, the performance of Derby with Web Content Manager is poor. A typical
cause of performance issues are transaction timeouts, which can impact a variety of features. Although
you can increase these timeouts, the resulting performance is prohibitively slow. Because of these
performance limitations, any Web Content Manager deployment requires that you use one of the other
supported database management systems to ensure proper function. In addition to production
environments, this requirement applies to proof-of-concept and development environments.
The Derby database that is installed by default is not intended for use in a production environment.
While using one database is supported, for high performance and availability, use multiple databases.
Derby does not support clustered environments, enabling security in a database-only mode, or vertical
cloned environments in which multiple application servers are configured on a single server. Use one of
the other supported databases in a production environment or when authoring web content because they
are better able to handle large amounts of data and can be tuned for performance.
With appropriate tuning, other databases can provide performance gains. Other databases support
vertical and horizontal clusters and cloning. Use multiple databases for high performance and availability.
When you choose to transfer data to another supported database, perform the database transfer before
you use the portal extensively. Large amounts of data in the databases can cause the database transfer to
fail if your Java heap size is not large enough. Because information is added to the databases as you use
the portal, perform database transfer as soon as you realize that a high volume of data needs to be stored
and failover is necessary. Transferring the database sooner rather than later avoids the problems typically
caused by transferring a high volume of data at a later stage to the other supported databases, including
not having adequate Java heap size.
Important: When using a database management system that is used by multiple applications, schedule
database transfer activities and preparation to off-peak hours or maintenance windows. Shared system
catalog tables are modified during database transfer work which prevents production applications from
accessing data.
Data can be transferred from a Derby database, but cannot be transferred to a Derby database. If you are
transferring from a database other than the default database, you will need to edit the
wkplc_sourceDb.properties, wkplc_dbdomain and wkplc_dbtype.properties files to update the source
database information as an additional step before attempting the database transfer functions.
Important: Data cannot be transferred from DB2
for z/OS to any other supported database.

Database users
There are two types of database users: database configuration users and database runtime users. Become
familiar with the privileges required for each user type to work with the database domains of IBM
WebSphere Portal and the commands for creating database configuration users and granting privileges.
Database configuration user
The database administration user that is typically created when a database management system (DBMS)
is installed is the database installation user or the database configuration user. The database configuration user
is not necessarily the user that is created by default when the database management system is installed.
The default user could be used as the database configuration user. The database configuration user is
used by WebSphere Portal for configuration tasks and creates the database structure needed by
WebSphere Portal. For example, the database configuration user can create database tables and indexes,
perform database transfer, and often times has operating system privileges, depending on the database
management system.
Database runtime user
The database runtime user has fewer privileges than the database configuration user. The runtime user has
runtime access to the data source of a database and can perform basic read and write operations on the
data. Consider creating a dedicated runtime user for each database domain of WebSphere Portal. If you
do not create runtime users, then WebSphere Portal uses the configuration user to connect to the
databases at runtime.
Privileges of database users
The following table identifies the minimum privileges needed to correct function by the two types of
database users: configuration users and runtime users. The privileges listed pertain to all WebSphere
Portal database domains.
Table 2. List of minimum privileges held by database runtime users for all database domains.
Permission
within the
database
domain Release Community Customization JCR Feedback Likeminds
Access to the
database
Yes Yes Yes Yes Yes Yes
Read on all
tables
Write on all
tables
Update on all
tables
Delete on all
tables
Create tables No No No Yes No No
Create indexes No No No Yes No No
Use of
sequences
No No No Yes Yes No
Installing 67
Table 3. List of privileges held by database configuration users for all database domains.
Permission
within the
database
domain Release Community Customization JCR Feedback Likeminds
Access to the
database
Read on all
tables
Write on all
tables
Update on all
tables
Delete on all
tables
Quota on disk
to create new
objects
Create table
spaces
Drop table
spaces
Create tables Yes Yes Yes Yes Yes Yes
Alter tables Yes Yes Yes Yes Yes Yes
Drop tables Yes Yes Yes Yes Yes Yes
Create indexes Yes Yes Yes Yes Yes Yes
Drop indexes Yes Yes Yes Yes Yes Yes
Create triggers Yes Yes Yes No Yes Yes
Drop triggers Yes Yes Yes Yes Yes Yes
Create
sequences
No No No Yes Yes No
Use of
sequences
No No No Yes Yes No
Create types No No No Yes No No
Drop types No No No Yes No No
Create views No No No No No No
Drop views No No No Yes No No
Database topologies
Consider the database configuration options in relation to your IBM WebSphere Portal deployment
scenario. The complexity of the network topology will increase as you scale from a proof-of-concept
environment using Derby to systems using vertical and horizontal clustering techniques.
WebSphere Portal data can be configured in a single store or organized into database domains to meet
different availability requirements, depending on your deployment scenarios for proof-of-concept and
production environments. The database domains provided by WebSphere Portal help you classify and
distribute portal data. Each database domain can be placed on a separate database for efficient
maintenance. Additionally, each domain can be placed on a separate database server system for
maximum performance.
Consider whether your portal deployment requires a local database for a proof-of-concept environment;
remote databases that share database domains to support normal load balancing; remote databases for
high-capacity, heavy load balancing that separate data; or a combination of database configurations.
Proof-of-concept deployment using a local database
You can install the database server on the same server machine as WebSphere Portal. This is
typically referred to as a local database. Using a local database can make administering your
environment easier; however, this setup is best used for proof-of-concept deployments only, as a
local database competes for server resources with your portal and provides a single point of
failure for your entire portal environment.
Normal load balancing using one or more remote databases
You can install the database server on a different server machine from WebSphere Portal. This is
typically referred to as a remote database. Using a remote database can provide performance
benefits, depending on the speed of the network. When multiple lines of production are involved
and each line of production is implemented as a cluster of servers, sharing database domains
ensures that the data is automatically synchronized across the lines of production. Each database
domain can be placed on a separate database for efficient maintenance.
High-capacity load balancing using one or more remote databases
When you deploy the portal in a large-scale, high-demand environment, you can dedicate a
server specifically for database transactions. As more users access the portal, the portal
application becomes database intensive. Database activity can take up CPU utilization and disk
I/O time. Separating the database from the server that the portal is running on increases its
capacity. Each domain can be placed on a separate database server system for maximum
performance.
Remember: If you install the database server on a remote system, you need to install the database client
software on the WebSphere Portal system so that the portal can communicate with the remote database
server.
Supported database transfer configurations
This topic highlights which databases you can transfer to from your current database.
Figure 1. Options for setting up databases
Installing 69
Supported database transfer configurations
The source database is the current database you are using. The target database is the database you plan
to transfer your data to from the source database. See the table for a list of supported database transfer
configurations from the source to target databases.
Table 4. Supported transfer configurations
Source database Target database
Apache Derby You can transfer your data to any database.
DB2 JDBC Type 2 You can transfer your data to any database, except for
DB2 JDBC Type 4.
DB2 JDBC Type 4 You can transfer your data to any database, except for
DB2 JDBC Type 2.
Oracle RAC JDBC OCI Type 2 You can transfer your data to any database.
Oracle or Oracle RAC JDBC Type 4 You can transfer your data to any database, except for
Oracle or Oracle RAC JDBC OCI Type 2.
Unsupported database transfer configurations
The following database transfer configurations are not supported:
v Transferring from IBM DB2 for i to any database.
v Transferring from DB2 for z/OS to any database.
v Transferring from any database to Derby.
Shared database domains
Database domains classify and help you determine how to distribute portal data. To maximize data
availability, you can distribute portal data across multiple databases and, for some domains, share data
between multiple lines of production. You can choose to transfer a single database domain or multiple
domains.
Separation of WebSphere Portal data allows you to store each category of data in its own set of database
tables or the file system. The sets of databases tables and schemas for portal resources are called database
domains. Database domains support the storage and transfer of data by category, for example,
Configuration, Release, Customization, Community, and IBM Java Content Repository (JCR). Separating
your data allows you to share domains across multiple portals. You can also spread the different domains
across different database types. For example, you can choose to leave LikeMinds data on your default
database and move all other data to another database. The separation of the domains can be used to
support production environments, where the production nodes are split into separate clusters. Each
cluster can run independently, but share the same Community and Customization database domains, for
example. Each of these clusters is called a line of production.
Preferences are kept in layers that are modifiable based on portlet modes. For example, there is one layer
of default preferences defined by the portlet deployment descriptor. This layer is modifiable within the
CONFIG mode supported by WebSphere Portal. In WebSphere Application Server, the values of the
portlet deployment descriptor are read-only. WebSphere Portal provides one additional preference layer
that enables portal administrators to specify different default values per portlet window. This capability is
supported through the portlet mode EDIT_DEFAULTS, and applies to all who use the same portlet
window. There is no such preference layer in WebSphere Application Server. Both products support the
standard modes: VIEW, EDIT, and HELP. When a user customizes a portlet on a page in any standard
mode, the user can change his personal portlet preferences. Default preferences on a per page or per
portlet base cannot be set in any standard mode; you need to use custom portlet modes instead. Portlet
preferences are stored in the customization domain when stored by users (typically in edit mode) on the
entity level whereas when using configure mode, we're working on the portlet definition level and those
are stored on the release level.
z/OS only: You can transfer data from any supported database type to any supported database type,
with the following exceptions:
v Data cannot be transferred to an Apache Derby database.
v Data cannot be transferred from an IBM DB2 Universal Database
for z/OS database.

z/OS only: The only two supported database management systems for WebSphere Portal are Derby and
DB2 for z/OS. Therefore, you can transfer data only from Derby to DB2 for z/OS.
The database domains categorize portal data into the following categories and subcategories to help you
decide how to distribute portal data into different databases:
Configuration data
This data defines the portal server setup, such as database connection, object factories, and
deployment descriptors. This type of data typically is constant during the time a server node is
running. Configuration data is typically kept in property files and is either protected by file
system security or application server administration rights.
Release data
This data includes all portal content definitions, rules, and rights that are designed externally
then brought into the portal by a staging process, such as Page Hierarchy, available Portlets and
Themes, Templates, Credential Slots, Personalization Rules, and Policies. These resources are
typically not modified during production and need administrative rights to do so. Administrators
typically create release data on an integration server and stage it to the production system.
Release data are protected by access control and contain only data, not code. In an environment
that consists of multiple lines of production, one copy of the release data exists per cluster.
Release data includes the following two separate domains:
v Release: Contains portal static site configuration, including access control, pages, and portlets.
v JCR: Contains authored content, Personalization rules, and theme policy definitions.
These should be considered release data and promoted to production lines individually.
Customization data
This data is associated with a particular user only and cannot be shared across users or user
groups. Typical examples are Portlet Data or Customized Pages (Implicitly Derived Pages).
Because this data is scoped to a single user only, access control protection is simplified.
In an environment that consists of multiple lines of production, customization data is kept in a
database that is shared across the lines of production. Therefore the data is automatically in
synchronization across the lines of production.
Community data
This data includes all resources that are usually modified during production. Typically, users and
groups are allowed to modify or delete shared resources. Community resources are protected by
access control.
The following table lists the supported database domains, whether a domain is sharable, and its storage
method.
Table 5. Supported database domains
Database domain Sharable Storage method
Release no database
Customization yes database
Community yes database
Installing 71
Table 5. Supported database domains (continued)
JCR no database
Feedback yes database
LikeMinds yes database
For maintenance and staging purposes you can take a single line of production out of service while
another line is still serving requests with the old data. After the first production line is updated and back
in service again, the second line is updated using the same approach. Updates of data in the shared
domain are critical because they influence the other production line.
The capacity of the entire environment should be greater than the intended use so that individual servers
can be taken out of production without affecting application availability. To ensure that all of the system
resources are available for the portal, production systems should be dedicated to the portal and should
not run any other server software that is not related to the portal.
For maintenance purposes, the following database domains can be taken offline:
v Community
v Customization
v Feedback
v LikeMinds
The following databases must not be taken offline at anytime when WebSphere Portal is started:
v Release
v JCR
While a database domain is offline, WebSphere Portal cannot access the corresponding data and thus
error messages may be displayed. WebSphere Portal itself remains responsive. When a database domain
becomes available again, WebSphere Portal will detect this availability, reconnect, and continue working
with the corresponding data. Regular maintenance should not affect the shared database domains because
it is imperative that this data remain available to all lines of production currently in use.
Sharing of VMM databases
The VMM database feature makes it much simpler to use multiple repositories, since this capability is
achieved through configuration, rather than development, with the use of the new VMM. In essence, this
feature provides the ability to map entries from multiple individual user repositories into a single virtual
repository. The federated repository consists of a single named realm, which is a set of independent user
repositories. Each repository may be an entire external repository or, in the case of LDAP, a subtree
within that repository. The root of each repository is mapped to a base entry within the federated
repository, which is a starting point within the hierarchical namespace of the virtual realm. The Virtual
Member Manager (VMM) databases for a full repository and for the property extension can be shared
between lines of production. If the VMM databases are out of service, WebSphere Portal will not function.
Database compatibility considerations
If you are a database administrator, consider the database requirements for IBM WebSphere Portal.
Remember that database compatibility with IBM WebSphere Portal running on the IBM i operating
system is mutually exclusive:
v IBM DB2 Universal Database for i databases are supported only on WebSphere Portal for IBM i.
v Other database management systems that are supported by WebSphere Portal can be configured to
work with any portal platform.
When planning to transfer data to IBM DB2 Universal Database for z/OS, consider the following factors:
v the domain data you are planning to transfer
v the database name for that domain
v When planning to transfer data to IBM DB2 Universal Database for z/OS, consider the following
factors:
the domain data you are planning to transfer
the database name for that domain
its user information
the space needed for the data transfer to complete successfully
Allot a higher percentage of space in the target database to allow for future scalability.
v its user information
v the space needed for the data transfer to complete successfully
Deleting passwords from properties files on page 3261
The configuration tasks might require you to write security-sensitive information, such as passwords, into
multiple properties files. When you no longer need this security-sensitive information for your
configuration, you should remove them and move the files to a safe place or set the file permissions so
that only authorized users can read them.
Planning for DB2 on Windows
When planning to transfer data to IBM DB2 Universal Database Enterprise Server Edition, you should
consider the databases and user information, such as database names, what data is stored, and the
database space needed. Some fix packs require steps prior to the transfer task to complete successfully.
Before you begin:
v WebSphere Portal supports DB2 JDBC Type 2 (CLI-based) and Type 4 (JCC) drivers.
v Review the database considerations.
v Ensure the database that you plan to use is supported by this version of WebSphere Portal. Refer to the
list of supported databases in the WebSphere Portal detailed system requirements.
The database names and users on this page are suggested values and provide consistency throughout the
documentation. Replace these values with values in your environment. The database name cannot exceed
eight characters and can only contain letters and numbers.
v When using the same database user ID, the value for the database name, database server node, or
schema name must be unique.
v When the DB2 Universal JDBC driver (type 4 mode) is used, connect to the database directly. Do not
connect to an alias database (gateway), instead specify the real database name in the JDBC connection
URL (dbdomain.DbUrl) and in the database name property (dbdomain.DbName).
In a local database environment, WebSphere Portal and DB2 are installed on the same system.
Installing 73
As shown in Figure 2, when a JDBC type 2 connections is used, WebSphere Portal and DB2 Connect are
installed on one system (the local system). The DB2 server is installed on a separate system (the remote
system).
For JDBC type 4 connections, no DB2 Connect installation is required on the system that runs WebSphere
Portal. As shown in Figure 3, the DB2 Universal JDBC driver that is supplied with DB2 is copied to this
system. It is used within the Java Virtual Machine of WebSphere Portal and connects directly to the
remote DB2 server.
Figure 2. Local database environment
Figure 3. Remote Database Environment (JDBC type 2 connection)
1. Review the different databases shown in the following table and replace these values with the values
in your environment; schema names must be different when the database is shared. While configuring
WebSphere Portal to use one database is technically possible, using separate databases can improve
scalability and performance. The architecture allows each of these databases to exist in one or many
instances. However, the recommended architecture uses the default instance (db2inst1) that is created
by the installation program.
Table 6. Space required for various databases
Application Database name Space required
WebSphere Portal
Used for the portal (at a minimum) or to
hold all data. Stores information about user
customization, such as pages, and user
profile and login information.
reldb
commdb
custdb
Depends on the number of users and portal objects,
such as pages and portlets.
Personalization,Web Content Manager
Contains documents, personalization rules,
personalization campaigns, and document
library configuration information.
jcrdb
Depends on the number and size of Personalization
rules and campaigns, and the number and size of
items and elements created in Web Content Manager.
Feedback
Contains the information that is logged by
your Web site for analysis of site activity
and generating reports.
fdbkdb
Depends on the amount of traffic to the site. The
amount of data that is logged per login-enabled page
can vary.
LikeMinds
Contains the recommendations to be
displayed to users when their interactions
with your Web site have been analyzed
and predictions generated.
lmdb
Depends on the amount of traffic to the site.
2. Review the tables and types of objects owned by each user. The architecture allows each of the
following users to exist in the same database. All table spaces are approximately 2.8 GB by default.
The size increases with the use of Java Content Repository.
Installing 75
Table 7. Tables and objects owned by database users
Application Database user placeholder Function
WebSphere Portal
releaseusr
communityusr
customizationusr
Core user who owns approximately
230 tables, used for WebSphere Portal
core objects, which includes tables
that store the user customizations
made to pages.
Java Content Repository
jcr
Java Content Repository user who
owns at least 1130 tables. The
number could be higher depending
on usage.
Feedback
feedback
Feedback user who owns
approximately 50 tables used for
logging site and personalization
usage.
LikeMinds
likeminds
LikeMinds user who owns
approximately 15 tables used to hold
the Web site usage analysis routines
and recommendation text.
Related tasks:
Which distributed edition of DB2 Universal Database Version 8 is correct for you?
System requirements on page 31
Planning for DB2 on UNIX or Linux
When planning to transfer data to IBM DB2 Universal Database Enterprise Server Edition, you should
consider the databases and user information, such as database names, what data is stored, and the
database space needed. Some fix packs require steps prior to the transfer task to complete successfully.
Before you begin:
v WebSphere Portal supports DB2 JDBC Type 2 (CLI-based) and Type 4 (JCC) drivers.
v When using the same database user ID, the value for the database name, database server node, or
schema name must be unique.
v Accessing a local DB2 database can cause shared memory problems. To correct these problems, you
must treat the local database as a remote database on the local system. Follow the instructions in the
Creating remote databases section if you are manually creating a database.
v When the DB2 Universal JDBC driver (type 4 mode) is used, connect to the database directly. Do not
connect to an alias database (gateway), instead specify the real database name in the JDBC connection
URL (dbdomain.DbUrl) and in the database name property (dbdomain.DbName).
In a local database environment, WebSphere Portal and DB2 are installed on the same system.
As shown in Figure 2, when a JDBC type 2 connections is used, WebSphere Portal and DB2 Connect are
installed on one system (the local system). The DB2 server is installed on a separate system (the remote
system).
For JDBC type 4 connections, no DB2 Connect installation is required on the system that runs WebSphere
Portal. As shown in Figure 3, the DB2 Universal JDBC driver that is supplied with DB2 is copied to this
system. It is used within the Java Virtual Machine of WebSphere Portal and connects directly to the
remote DB2 server.
Figure 5. Local database environment
Installing 77
scalability and performance. The architecture allows each of these databases to exist in one or many
instances. However, the recommended architecture uses the default instance (db2inst1) that is created
by the installation program.
WebSphere Portal
reldb
commdb
custdb
jcrdb
Feedback
fdbkdb
can vary.
LikeMinds
lmdb
WebSphere Portal
releaseusr
communityusr
customizationusr
made to pages.
jcr
on usage.
Feedback
feedback
usage.
LikeMinds
likeminds
Related tasks:
Planning for IBM DB2 for i
When planning to transfer data to IBM DB2 for i, you should consider the databases and user
information, such as database names, what data is stored, and the database space needed. Some fix packs
require steps prior to the transfer task to complete successfully.
Before you begin:
v Use the IBM i command, WRKRDBDIRE, to confirm there is a database entry for a local database
environment or for a remote database in remote environment since the default database connection is a
type 4 connection.
DB2 is integrated with IBM i, but you must create the required databases and users and grant the proper
privileges to those users. WebSphere Portal can create the databases for you.
The database names and users in this topic are suggested values and provide consistency throughout the
documentation. Replace these values with values in your environment.
WebSphere Portal uses Apache Derby during installation, and supports configuration of DB2 for an IBM
System i5
system. The Derby database is ideal for a test environment. For a production environment,
you can move from the installed Derby database to IBM DB2 for i, but note that there is no option to
transfer back to Derby.
Installing 79
The IBM DB2 for i database enables you to access and manage server data through an application or a
user interface. In addition to providing access to and protection for your data, IBM DB2 Universal
Database for i provides advanced functions, such as referential integrity and parallel database processing.
IBM DB2 for i is the relational database manager that is fully integrated on your IBM i system. IBM DB2
for i also provides features such as triggers, stored procedures, and dynamic bitmapped indexing that
serve a wide variety of application types. These applications range from traditional host-based
applications to client/server solutions to business intelligence applications.
As an interface to IBM DB2 for i, the DB2 Query Manager and Structured Query Language (SQL)
Development Kit for System i5 add an interactive query and report writing interface, and precompilers
and tools to assist in writing SQL application programs in high-level programming languages. The SQL
implementation for OS/400 allows you to define, manipulate, query, and control access to your IBM i
data. It works equally well with IBM i files and SQL tables.
If you choose to use one database to hold all WebSphere Portal, Member Manager, and content
publishing information, only one user profile is required. Additional user profiles are necessary only if
using multiple IBM i systems or separate databases are required.
When WebSphere Portal creates databases, it uses the database names that are specified in the
wkplc_dbdomain.properties file, located in the UserData directory wp_profile_root/ConfigEngine/
properties. It is possible to create up to six different databases by setting different values in the
wkplc_dbdomain.properties file.
While configuring Portal to use one database is technically possible, use separate databases for scalability
and performance tuning reasons. To use a single shared database, replace each database and user variable
with the name of your database and database user, respectively.
Note: The format for database names is *LOCAL/database_name for a Type 2 database connection, or a
fully qualified server name such as myserver.mycompany.com/database_name for a Type 4 database
connection.
In a local database environment, WebSphere Portal and IBM DB2 for i can be accessed with either a Type
4 or Type 2 connection. Type 4 is the default and recommended connection.
In a remote database environment, WebSphere Portal connects directly to the DB2 server (JDBC Type 4
connection).
in your environment; schema names must be different when the database is shared.
WebSphere Portal
reldb
commdb
custdb
jcrdb
Table 10. Space required for various databases (continued)
Feedback
fdbkdb
can vary.
LikeMinds
lmdb
WebSphere Portal
releaseusr
communityusr
customizationusr
made to pages.
jcr
on usage.
Feedback
feedback
usage.
LikeMinds
likeminds
Related tasks:
http://www.ibm.com/support/docview.wss?uid=swg27007791
Planning for DB2 for z/OS
When planning to transfer data to IBM DB2 Universal Database for z/OS, you should consider the
databases and user information, such as database names, what data is stored, and the database space
needed. Some fix packs require steps prior to the transfer task to complete successfully.
When planning to transfer data to IBM DB2 Universal Database for z/OS, consider the following factors:
v the domain data you are planning to transfer
v the database name for that domain
v its user information
v the space needed for the data transfer to complete successfully
Installing 81
When planning to install DB2 for z/OS to use as the database for WebSphere Portal, consider the
following:
v Ensure that Java Database Connectivity requirements are met. Consult the following references:
DB2 Universal Database for OS/390 and z/OS: Application Programming Guide and Reference for Java
The IBM Redbooks publication, DB2 for z/OS and OS/390: Ready for Java SG24-6435-00.
v If you plan to use IBM DB2 Universal Database for z/OS for a database transfer, as a database user
registry, or a property extension (lookaside) database, change the Common Service Area (CSA) setting
to 3500,350000. See the appropriate DB2 for z/OS Information Center topic for complete information
about calculating and setting CSA:
DB2 for z/OS Version 8, Common service area
DB2 for z/OS Version 9.1, Common service area storage requirements
v If you are planning to use Type 2 driver with DB2 for z/OS Version 9.1.2, ensure that DB2 for z/OS
APAR PK58105 is installed.
v Review the following guidelines:
If the current version of WebSphere Portal and an earlier version coexist using the same DB2 for
z/OS subsystem, the database user IDs for the current version of WebSphere Portal must be
different than the earlier version to avoid conflicts during installation. If the two versions of
WebSphere Portal connect to two different DB2 for z/OS subsystems, using the same user ID will
not cause conflict.
Except when migrating to a new release of WebSphere Portal, using the same DB2 for z/OS
subsystem for two independent lines of production should be avoided. Each line of production of
WebSphere Portal should use a subsystem of DB2 for z/OS that is dedicated exclusively to this
installation. Because the DB2 for z/OS database catalog is shared, complications may occur in a
shared environment.
Check the bufferpool allocations for your system and define the bufferpools as appropriate for your
installation and define a large enough size, for example:
-db2 display bufferpool(bp2)
-db2 alter bufferpool(bp2) vpsize(15000)
- Repeat for additional bufferpools as needed, for example:
bp3
bp4
bp5
bp32k1
bp32k2
- Update BP8K0 catalog bufferpool to 35,000 before performing database transfer. The
SYSIBM.SYSDATABASE table resides in this bufferpool and is used extensively by DB2 for z/OS
during database transfer.
During database transfer from Derby to DB2 for z/OS, a supporting low order byte table space is
created for the database tables storing documents. The PRIQTY and SECQTY for the table space are
assigned using the default values. If you plan to store a large number of documents, you should use
an automatic class selection (ACS) routine to allocate the DB2 for z/OS data sets with a primary and
secondary space allocation of at least 10 cylinders, or specify a large enough value for PRIQTY and
SEQTY in the DB2 DSNTIJUZ member. The table spaces can be identified by their name, having a
structure like JCRDB.Sxxxxxxx, where xxxxxxx is a system-assigned combination of seven numbers
and characters.
Also in member DSNTIJUZ, update the following parameters and then verify DSNTIJUZ runs
successfully:
edmdbdc = 204800
edmpool=409600
edmstmtc=204800
rrulock=no
cachedyn=yes (prepared, dynamic SQL statements are cached)
dbacrvw=yes (to allow database administrators to create Views)
+++tbsbpxml=BP16K1 (to explicitly create an XML table space. This value can be changed to any
valid 16K bufferpool where the Administrative User has the USE privilege.)
If you intend to run the LikeMinds sample, increase the NUMLKTS and NUMLKUS parameters: Ten times
the default is sufficient, more depending on your usage of the sample. For example, if NUMLKTS=1000
and NUMLKUS=10000 are the installation default values, then update these values to NUMLKTS=10000
and NUMLKUS=100000.
Ensure that the job DSNTIJSG has been executed to create the objects required for the DB2 JDBC
and ODBC metadata methods. See the DB2 Installation Guide Enabling stored procedures and tables
for JDBC and ODBC support.
Ensure that job DSNTIJMS runs successfully (re-execute binds)
Ensure that job DSNTIJEX runs successfully
Because large objects are stored in columns that can become very large, logging changes to these
columns requires a huge amount of log space. For this reason, large object (LOB) logging is disabled
by default for tablespaces that contain such data. With LOB logging disabled, you can recover full
backups, but not incremental backups that can be used for point in time recovery. To recover point
in time backups, you must enable LOB logging. For detailed instructions, see Technote 1306637,
Managing LOB logging in DB2 for z/OS.
v Changes to DB2 for z/OS Version 9.1 related to defaults bufferpools affect the CREATE LOB
TABLESPACE in that version of DB2 for z/OS. The CREATE LOB TABLESPACE will now take its
default buffer pool from ZPARM field TBSBPLOB if the buffer pool is not explicitly specified, rather
than taking the buffer pool from the database.
The WebSphere Portal Customization Dialog generates jobs for creating the databases and end users, and
granting privileges to these end users. The following table gives an overview of the databases WebSphere
Portal requires.
If you plan to use a single DB2 for z/OS subsystem to hold data for more than one portal installation,
use the same user name but a separate schema name for each database domain. For Member Manager,
the user name must match the schema; the same database user cannot be used for the Member Manager
databases of two distinct portal installations.
If you plan to use a single DB2 for z/OS subsystem to hold data for more than one portal installation,
you must create unique schema names for each portal installation to prevent table name conflicts. For
Member Manager data, you must create and use a unique Member Manager database user ID for each
portal instance, to prevent table name conflicts. You can share some of the portal databases between the
portal instances. For more information, refer to the topic that explains sharing database domains between
separate portal instances.
Each portal installation must be in separate and distinct WebSphere Application Server cells. If the portals
are installed in the same file system, each must be installed in a separate and unique directory. If the
portals are installed in different file systems, the same directory name can be used.
Installing 83
Each portal installation must be in separate and distinct WebSphere Application Server cells and in
separate and unique directories.
In a remote database environment, WebSphere Portal and DB2 Connect are installed on one machine (the
local machine) and the DB2 for z/OS server is installed on a separate machine (the remote machine).
in your environment; schema names must be different when the database subsystem is shared. You
can configure WebSphere Portal to use one database. However, using separate databases will improve
scalability and performance.
Table 12. Applications, database names, and space required
WebSphere Portal
Used for WebSphere Portal (at a minimum) or
to hold all data. Stores information about user
customizations, such as pages, and user
relzos
commzos
custzos
Depends on the number of WebSphere
Portal users and portal objects, such as
pages and portlets.
Personalization, Web Content Manager
Contains documents and other content,
personalization rules, personalization
campaigns, and document library
configuration information.
jcrdbzos Depends on the number and size of
Personalization rules and campaigns, and
the number and size of items and
elements created in Web Content
Manager.
Feedback
your Web site for generating reports for
analysis of site activity.
Database: fdbkzos
Table space: fdbkdbts
Depends on the amount of traffic to the
site. The amount of data that is logged
per login-enabled page can vary.
LikeMinds
with your Web site have been analyzed and
predictions generated.
Database: lmdbzos
Table space: lmdbts
Depends on the amount of traffic to the
site.
Table 13. WebSphere Portal applications, database names, and space required
Application and domains Database names Function Space required
v Release
v Customization
v Community
Used for WebSphere Portal
(at a minimum) or to hold
all data. Stores information
about user customizations,
such as pages, and user
profile and login
information.
WPSDBREL
WPSDBCUS
WPSDBCOM
Core user who owns
approximately 230 tables in
total for all database
domains used for
WebSphere Portal core
objects, including tables
that store the page
customizations made by
users:
Release, approximately
120
Community,
approximately 80
Customization,
approximately 30
Depends on the number of
WebSphere Portal users and
portal objects, such as
pages and portlets.
Table 13. WebSphere Portal applications, database names, and space required (continued)
Contains documents and
other content,
personalization rules,
personalization campaigns,
and document library
configuration information.
Tip: The JCR domain needs
to be unique, specifically,
the JCR prefix cannot be
the same exact (3 or 4)
letters as the beginning of
another database name; for
example, it cannot be the
same 3 or 4 letters as the
LikeMinds domain.
WPSDBJCR While only one database is
indicated here, you should
set the appropriate values
in the icm.properties file
to specify the tables for
each database and the
database prefix and create
the necessary JCR
databases.
Depends on the size and
number of documents
created and uploaded, the
number and size of
Personalization rules and
campaigns, and number of
Web Content Manager
objects.
Table 14. Feedback applications, database names, and space required
Contains the information
that is logged by your Web
site for generating reports
for analysis of site activity.
WPSDBFEE Depends on the amount of
traffic to the site. The
amount of data that is
logged per login-enabled
page can vary.
Table 15. LikeMinds applications, database names, and space required
Contains the
recommendations to be
displayed to users when
their interactions with your
Web site have been
analyzed and predictions
generated.
WPSDBLIK Depends on the amount of
traffic to the site.
WebSphere Portal
releaseusr
communityusr
customizationusr
made to pages.
jcr
on usage.
Installing 85
Table 16. Tables and objects owned by database users (continued)
Feedback
feedback
usage.
LikeMinds
likeminds
3. Review the tables and types of objects owned by each user. The WebSphere Portal architecture allows
each of the following users to be the same.
Table 17. Applications, database user placeholders, runtime database users, and functions
Application Database user placeholder Runtime database user Function
WebSphere Portal Core user who owns tables
for each domain, used for
objects, including tables
that store the page
customizations made by
users:
reladm
comadm
cusadm
An optional database user
who can connect to the
database domain to
perform configuration
tasks.
reladm owns 121 tables,
used for WebSphere
Portal core objects, for
example, page hierarchy
definitions.
comadm owns 77 tables,
used for WebSphere
Portal core objects,
cusadm owns 30 tables,
used for WebSphere
Portal core objects,
which includes tables
that store the user
customizations made to
pages.
Java Content Repository icmadmin An optional database user
database domain to
perform configuration
tasks.
user who owns at least
1130 tables; the number
could be higher depending
on usage.
Feedback feedback An optional database user
Feedback database domain
to perform configuration
tasks.
approximately 50 tables
used for logging site and
personalization usage.
LikeMinds lmadm An optional database user
LikeMinds database
domain to perform
configuration tasks.
used to hold the web site
usage analysis routines and
recommendation text.
4. If your Java Content Repository is using declared global temporary tables (DGTT), you must have the
appropriate TEMP database and TEMP tablespaces configured prior to use. The TEMP database may
also require additional allocated space. Use the following information as a guideline to create a TEMP
database and a TEMP tablespace to contain the declared temporary tables:
Table 18. Examples on how to create a TEMP database and a TEMP tablespace by database version
Database version Example
DB2 for z/OS Version 8 Create a TEMP database and tablespace if it does not already exist. The following is a
representative example of a TEMP database definition:
CREATE DATABASE TEMP AS TEMP STOGROUP SYSDEFLT;
CREATE TABLESPACE TEMP IN TEMP
USING STOGROUP SYSDEFLT
BUFFERPOOL BP8
SEGSIZE 32;
This version also requires work file database storage for SQL statements that require
working storage, such as sorts. This requires the addition of a table space to support
sorting operations in addition to the TEMP database.
DB2 for z/OS Version 9
in a non-data sharing
environment
The TEMP database is DSNDB07 and is created during database installation. Temporary
table spaces are added to the existing TEMP database. The following is a representative
example of a temporary table space:
CREATE TABLESPACE ICMTEMP IN DSNDB07
BUFFERPOOL BP8
SEGSIZE 32;
In this version the work file database and TEMP databases are combined. See the DB2
for z/OS information center for the procedures and sizing recommendations for creating
work file databases.
DB2 for z/OS Version 9
in a data sharing
environment
Create a WORKFILE database. Only one WORKFILE database can be created per
subsystem. The following is a representative example for creating a WORKFILE
database and temporary table space:
CREATE DATABASE WORKTEMP AS WORKFILE STOGROUP SYSDEFLT;
CREATE TABLESPACE ICMTEMP IN WORKTEMP
BUFFERPOOL BP8
SEGSIZE 32;
In this version the work file database and TEMP databases are combined. See the DB2
for z/OS information center for the procedures and sizing recommendations for creating
work file databases.
Refer to the DB2 for z/OS documentation for additional information on setting up the TEMP database
and TEMP tablespaces.
Related tasks:
WebSphere Portal detailed system requirements
http://www.ibm.com/software/data/pubs/
DB2 for z/OS
DB2 Installation Guide
Planning for Oracle
When planning to transfer data to Oracle, you should consider the databases and user information, such
as database names, what data is stored, and the database space needed.
Before you begin:
Installing 87
in your environment; schema names must be different when the database is shared. WebSphere Portal
can be configured to use a single shared database if different database users are chosen for each
database listed in this step. On Oracle, a single database configuration can significantly reduce
consumption of system resources by the database management system. Using separate table spaces for
all of the databases can improve scalability and performance.
WebSphere Portal
reldb
commdb
custdb
jcrdb
Feedback
fdbkdb
can vary.
LikeMinds
lmdb
WebSphere Portal
releaseusr
communityusr
customizationusr
made to pages.
jcr
on usage.
Feedback
feedback
usage.
Table 20. Tables and objects owned by database users (continued)
LikeMinds
likeminds
Related tasks:
Oracle product documentation
Planning for Oracle RAC
When planning to transfer data to Oracle RAC, you should consider the databases and user information,
such as database names, what data is stored, and the database space needed.
Before you begin:
The default tablespace size for Oracle RAC may need to be set to 1024MB with autoextend turned on for
database transfer to be successful.
in your environment; schema names must be different when the database is shared. WebSphere Portal
can be configured to use a single shared database if different database users are chosen for each
database listed in this step. On Oracle, a single database configuration can significantly reduce
consumption of system resources by the database management system. Using separate table spaces for
all databases can improve scalability and performance.
WebSphere Portal
reldb
commdb
custdb
jcrdb
Feedback
fdbkdb
can vary.
Installing 89
Table 21. Space required for various databases (continued)
LikeMinds
lmdb
WebSphere Portal
releaseusr
communityusr
customizationusr
made to pages.
jcr
on usage.
Feedback
feedback
usage.
LikeMinds
likeminds
Related tasks:
Oracle product documentation
Planning for SQL Server
When planning to transfer data to SQL Server, you should consider the databases and user information,
such as database names, what data is stored, and the database space needed.
Before you begin:
scalability and performance.
WebSphere Portal
reldb
commdb
custdb
jcrdb
Feedback
fdbkdb
can vary.
LikeMinds
lmdb
2. Connect at least one user to the SQL Server instance. A user can be granted permission to use several
schema names, so a single user for each instance is sufficient.
3. Review the tables and types of objects owned by each schema. The WebSphere Portal architecture
allows each of the following schemata to exist in the same database. All table spaces will be
approximately 2.8 GB by default. The size will increase with the use of the Java Content Repository
function.
Table 24. Information by application, database schema placeholder, recommended name, and function
Application
Database schema
placeholder Recommended name Function
WebSphere Portal
v releaseusr
v communityusr
v customizationusr
<none> Core schemata. Will own
for each domain. Owns
objects, which includes
tables that store the user
customizations made to
Pages.
Java Content Repository icmadmin <none> Java Content Repository
schema. Will own at least
1130 tables; the number
could be higher depending
on usage.
Feedback feedback <none> Feedback schema. Will own
used for logging site and
personalization usage.
Installing 91
Table 24. Information by application, database schema placeholder, recommended name, and function (continued)
Application
Database schema
placeholder Recommended name Function
Likeminds LIKEMINDS <none> LikeMinds schema. Will
own approximately 15
tables used to hold the web
site usage analysis routines
Related tasks:
http://www.datadirect.com/products/jdbc/index.ssp
Microsoft SQL Server product documentation
Registry Entries Are Required for XA Transaction Support
http://support.microsoft.com/kb/839279
User registry considerations
A user registry or repository authenticates a user and retrieves information about users and groups to
perform security-related functions, including authentication and authorization.
User registries store user account information, such as user ID and password, that can be accessed during
authentication. User repositories store user profiles and preference information. A user registry or
repository is used to:
v Authenticate a user using basic authentication, identity assertion, or client certificates
v Retrieve user and group information to perform security-related administrative functions such as
mapping users and groups to security roles
By default, IBM WebSphere Portal is installed with a federated repository with a built-in file repository.
The federated repository allows you to add various user registries, realm support for Virtual Portals,
and/or property extensions to create a single, working unit. The available user registries that you can
add to the federated repository are LDAP user registries, database user registries, and custom user
registries.
Remember: Using the built-in file repository is not recommended in a production environment. After
adding another repository and choosing the administrative users from that repository, you should remove
the file repository.
Based on the federated repository, WebSphere Portal allows you to create a user base that can be
federated over multiple repositories: LDAP, DB, and/or custom user registry. It also allows you to define
additional attributes in a separate store if your corporate LDAP directory is read-only.
If you are using a federated repository, you must plan on where you want to store new users and groups.
By default, new users and groups are stored in the default file repository. If using multiple LDAP user
registries and/or database user registries, you must figure out which user registry you want to define as
your default user registry where new users and groups are stored. After you add all user registries to
your federated repository, you can run the wp-set-entitytypes task to set a specific user registry as the
default location.
Remember: Before combining multiple user registries, review the registries for the following limitations
and correct any issues:
v Distinguished names must be unique for a realm over all registries. For example, if
uid=wpsadmin,o=yourco exists in LDAP1, it must not exist in LDAP2, LDAP3, or DB1.
v The shortname, for example wpsadmin, should be unique for a realm over all registries.
v The base distinguished names for all registries used within a realm must not overlap; for example, if
LDAP1 is c=us,o=yourco, LDAP2 should not be o=yourco.
v Do not leave the base entry blank for any of the registries used within a realm.
v If IBM Lotus Domino will be one of your user registries in a multiple registry configuration and will
share a realm with another user registry, ensure that the groups are stored in a hierarchical format in
the Domino Directory as opposed to the default flat-naming structure. For example, the flat-naming
convention is cn=groupName and the hierarchical format is cn=groupName,o=root.
v The user must exist in a user registry and not within the property extension configuration; otherwise,
the user cannot be a member of the realm.
If you have an application that does not support the federated repository, you can switch to a standalone
LDAP user registry or a standalone custom user registry.
Related reference:
Directory Search on page 2362
The Directory Search or "People Picker" portlet is a common embedded component that allows users to
search for and select names of people (individual users) and groups for which the portal is configured.
Overview of user registry options
IBM WebSphere Portal provides a variety of security configuration tasks. In the past, there was one task,
which did not let you recover from errors or allow your user registry to meet your growing business
needs. Now there are multiple tasks, which allow you to fine-tune your system to meet your business
needs.
You have the following general security options to choose from:
Table 25. Security options with explanation
Security option Explanation
Standalone LDAP security This option is a simple, single LDAP security option,
which is similar to the LDAP security option provided in
the past. With this option, you can create Virtual Portals
with a single realm and store users and groups in a
single LDAP server.
Federated security This option is an evolved option to the standalone LDAP
user registry with single realm support option. With this
option, you can create Virtual Portals with multiple
realms, you can use multiple repositories (LDAP,
database, custom), and you can add Application Groups
to your system. This option is good if you have to merge
multiple LDAP servers into one cohesive structure.
Attention: If you plan to enable the transient user
feature, you must choose the federated user registry
configuration.
Important: You must take special care that there are no
duplicate names between the various repositories. For
example, if you installed the product with a Portal
Administrator of "wpsadmin", then the user "wpsadmin"
should not exist in the corporate LDAP server.
Installing 93
Table 25. Security options with explanation (continued)
Security option Explanation
Custom security This option provides you with the ability to write a fully
controlled WebSphere Security environment by providing
a Custom User Registry and a Custom Member Adapter
for Virtual Member Manager (VMM). The abilities of this
option will depend on your implementation.
Standalone LDAP security
Out-of-the-box, WebSphere Portal is configured with the default federated repository with a built-in file
repository. Therefore, you must run the task to switch to a stand-alone LDAP user registry. In order to
ensure that your LDAP user registry runs properly with WebSphere Portal, you must then adapt the
attribute configuration to match the configured LDAP server and your business needs. After completing
the steps for these tasks, your security is ready for production.
After using your standalone LDAP user registry, you may need to manage your user registry; you can
complete any of the following optional tasks to fine-tune your stand-alone LDAP user registry:
Table 26. Optional tasks to manage the standalone user registry
Task Explanation
Update the standalone LDAP user registry You can update certain parameters such as your bind ID
and password to fix issues with your LDAP user registry.
Property extension database; formerly known as the
lookaside database
Choose this option to store additional attributes inside
the VMM property extension instead of within the LDAP
user registry. Some applications, such as Common Mail
portlet and IBM Web Content Manager use the property
extension database to store additional attributes. After
you enable the property extension database, you can add
attributes to meet your business needs.
Create the entity type Choose this option if you want to use an entity type that
exists in WebSphere Portal but not within your LDAP
user registry. This option creates the entity type in your
user registry and adds the relative distinguished name
(RDN) to map the entity type between WebSphere Portal
and your user registry.
Update an existing entity type Choose this option to update the default parent of an
existing, single entity type; for example, if you deleted a
repository and the entity type points to the deleted
repository, you will need to update the information to
point to a new repository.
Federated security
Out-of-the-box, WebSphere Portal is configured with the default federated repository with a built-in file
repository. The federated repository offers you the richest amount of options to meet your business needs
and to allow you to easily expand your business as your needs grow. For example, if your company
acquires a new business that has an existing LDAP user registry, you can just add that LDAP server to
your federated repository. Choose one of the following tasks to enable a production repository:
Table 27. Tasks to enable a production repository
Task Description
Add a federated LDAP repository to the VMM
configuration
Select this option to add an LDAP server to the federated
repository. This task does not change the current security
assignment; therefore, the administrative user defined
during installation is still active.
Add a federated database repository to the VMM
configuration
Select this option to add a database to the federated
repository. This task does not change the current security
assignment; therefore, the administrative user defined
during installation is still active.
Add a federated custom user registry Select this option to add a custom user registry that your
company created to the federated repository. This task
does not change the current security assignment;
therefore, the administrative user defined during
installation is still active.
After you add your initial LDAP user registry, database user registry, or custom user registry, you can
add additional user registries to the repository to create a multiple user registry configuration. After
configuring your repository, you must remove the default file-based repository unless this is a
development environment. The following tasks are required to remove the default file-based repository:
Table 28. Tasks required to remove the default file-based repository
Task Description
Change the user registry where users and groups are
stored
This task changes the default repository where new users
and groups are stored.
Change WebSphere Application Server administrator This task changes the WebSphere Application Server
administrator user ID and password from what was
defined during installation to the new user ID and
password required for your clustered or standalone
production environment.
Change WebSphere Portal Server administrator This task changes the WebSphere Portal administrator
user ID and password from what was defined during
installation to the new user ID and password required
for your clustered or standalone production environment.
Delete a federated repository from the VMM
configuration
This task deleted the default file-based repository from
your configuration.
After using your federated repository, you may need to manage your user registry; you can perform any
of the following optional tasks to fine-tune your federated repository:
Table 29. Optional tasks to manage the federated repository
Task Description
Updating the federated LDAP user registry Choose this option to update certain parameters such as
your bind ID and password to fix issues with your
LDAP user registry.
Updating the federated database user registry Choose this option to update certain parameters such as
the data source name, database URL, and database type
to fix issues with your database user registry.
Installing 95
Table 29. Optional tasks to manage the federated repository (continued)
Task Description
Create a new realm Choose this option to create a realm, which is a group of
users from one or more user registries that form a
coherent group within WebSphere Portal. Realms allow
flexible user management with various configuration
options. A realm must be mapped to a Virtual Portal to
allow the defined users to log in to the Virtual Portal. In
a federated repository, you can create multiple realms.
Property extension database; formerly known as the
lookaside database
Choose this option to store additional attributes inside
the VMM property extension instead of within the LDAP
user registry. Some applications, such as Common Mail
portlet and IBM Web Content Manager use the property
extension database to store additional attributes. After
you enable the property extension database, you can add
attributes to meet your business needs.
Create the entity type Choose this option if you want to use an entity type that
exists in WebSphere Portal but not within your LDAP
user registry. This option creates the entity type in your
user registry and adds the relative distinguished name
(RDN) to map the entity type between WebSphere Portal
and your user registry.
Update an existing entity type Choose this option to update the default parent of an
existing, single entity type; for example, if you deleted a
repository and the entity type points to the deleted
repository, you will need to update the information to
point to a new repository.
Virtual Member Manager integration
IBM WebSphere Application Server includes the Virtual Member Manager (VMM), which IBM WebSphere
Portal uses to access user and group information. VMM provides an interface that enables
communication between WebSphere Portal and any repository, whether federated repositories, a
stand-alone repository, or your own custom user registry.
The Virtual Member Manager (VMM) is an abstract component within the WebSphere Application Server
infrastructure. As the following diagram illustrates, WebSphere Portal uses the Portal User Management
Architecture (PUMA) System Programming Interface (SPI) to retrieve and set attributes on user objects.
PUMA passes these requests to VMM, which then passes the requests on to a corresponding registry
adaptor that connects VMM to the repository.
The preceding diagram includes the following components:
Federated Repositories
An out-of-box implementation of the UserRegistry interface that supports multiple repositories.
To communicate with the federated repositories, both WebSphere Application Server and
WebSphere Portal dispatch all operations to VMM.
Stand-alone LDAP
An out-of-box implementation of the UserRegistry interface where a single LDAP directory is the
repository. WebSphere Application Server communicates directly with the stand-alone LDAP.
WebSphere Portal communicates with the stand-alone LDAP through VMM.
VMM SPI
VMM offers a Service Provider Interface (SPI), wim.Repository, that enables communication with
repositories. WebSphere Application Server uses this SPI to connect to federated repositories.
WebSphere Portal uses this SPI to connect to all repositories, whether federated or stand-alone.
User Registry Adaptor
An implementation of the VMM SPI that enables VMM to connect to a specific repository,
whether an LDAP directory, database, files, or other repository. Registry adaptors enable
communication between WebSphere Portal and any repository.
Important: You must create a user registry adaptor if you plan to use a custom user registry or
repository that WebSphere Portal does not support out-of-box. To create a user registry adaptor,
implement the wim.Repository interface. Refer to the following topics in the WebSphere
Application Server Information Center for information and instructions:
Repository SPI (System programming interfaces for virtual member manager adapters)
Installing 97
Sample custom adapters for federated repositories examples
Related tasks:
Setting up custom user repositories on page 3224
A custom user repository is any repository that WebSphere Portal does not support out-of-box. However,
you can configure WebSphere Portal to support any type of repository in a federated or stand-alone user
registry, whether an LDAP directory, database, file system, and so on. Setting up custom user repositories
involves tasks such as defining additional repositories to the default federated user registry, creating a
custom stand-alone user repository, and updating your user repository to reflect changes in your
environment. Learn what steps are required to create and update custom user repositories and what
specific interfaces you must implement to enable communication between WebSphere Portal and a
repository.
Webcast replay of WebSphere Portal WMM to VMM comparison
Setting up a custom user repository with Virtual Member Manager for IBM WebSphere Application
Server and IBM WebSphere Portal
IBM WebSphere Developer Technical Journal: Expand your user registry options with a federated
repository in WebSphere Application Server, Using the Virtual Member Manager
WebSphere Application Server Information Center, Virtual member manager APIs
WebSphere Application Server Information Center, Sample custom adapters for federated repositories
examples
WebSphere Application Server Information Center, Repository SPI
Realm support
A realm is a collection of users or groups from one or more branches of your repository tree. Those
branches can be part of a single repository, for example an LDAP user registry, or it can be a combination
of multiple user registries. A realm is then mapped to a Virtual Portal to allow the realm's user
population to log in to the Virtual Portal. This functionality allows you to define areas within WebSphere
Portal that only a limited set of users can access.
For example, if you are an international company with employees in Asia, Europe, USA, and Canada,
you may have an application or information that only applies to a subset of these employees. You can
create a subset of employees and create a Virtual Portal that contains the application or information for
that realm. Users from one realm cannot access another realm unless they are also members of that realm.
For example, the wpsadmin user will not be able to log in to a Virtual Portal unless the wpsadmin user is
a member of the corresponding realm.
You can create a realm that combines users from your various user registries; for example, your realm can
span three LDAP user registries and a database user registry: LDAP1, LDAP2, LDAP3, and DB1.
Remember: Before combining multiple user registries, review the registries for the following limitations
and correct any issues:
v Distinguished names must be unique for a realm over all registries. For example, if
uid=wpsadmin,o=yourco exists in LDAP1, it must not exist in LDAP2, LDAP3, or DB1.
v The shortname, for example wpsadmin, should be unique for a realm over all registries.
v The base distinguished names for all registries used within a realm must not overlap; for example, if
LDAP1 is c=us,o=yourco, LDAP2 should not be o=yourco.
v Do not leave the base entry blank for any of the registries used within a realm.
v If IBM Lotus Domino will be one of your user registries in a multiple registry configuration and will
share a realm with another user registry, ensure that the groups are stored in a hierarchical format in
the Domino Directory as opposed to the default flat-naming structure. For example, the flat-naming
convention is cn=groupName and the hierarchical format is cn=groupName,o=root.
v The user must exist in a user registry and not within the property extension configuration; otherwise,
the user cannot be a member of the realm.
Property extension
The Property extension, formerly known as the lookaside database, allows you to store additional user
attributes into a database store without touching your backend user registry. You can use the Property
Extension if your LDAP is read-only but you have a requirement that allows users to specify an
additional attribute such as Timezone. You can store this additional attribute in the database store. You
can also add additional attributes for an application if you cannot change your repository Schema.
Property extension can be used with a federated repository, a stand-alone LDAP user registry, or a
custom user registry.
IBM Web Content Manager stores additional information for the following features:
v Web content user profiling
v Category selection trees
If this information cannot be stored in the main repository, for example the main repository is read-only,
a property extension configuration is required.
Cluster considerations
IBM WebSphere Portal comes standard with WebSphere Application Server Network Deployment, a
distribution of IBM WebSphere Application Server that provides a Deployment Manager server type for
centrally managing and clustering a series of servers. To cluster a series of portal servers means that all
portal instances share the same configuration, including database, applications, and portlets, and site
design. The cluster provides a domain against which most administrative actions are performed once and
synchronized with each server in the cluster. This both simplifies administration as well as ensures that
all cluster members are configured and behave identically.
A server cluster also provides a shared domain in which session and cache data can be replicated and
kept consistent across all members of the cluster. The cluster also provides an application synchronization
mechanism that ensures consistent application management (start, stop, updates, etc.) across the cluster.
WebSphere Application Server provides an HTTP Server plug-in that can balance user traffic across all
members of the cluster, and through a feature called session affinity, ensure that a user remains bound
to a specific cluster instance for the duration of their session, to improve efficiency and performance.
Additionally, in the event a cluster member is down, the workload management features of the plug-in
will recognize that the instance is no longer available and will route traffic around it.
There are two types of clusters: vertical and horizontal clusters. Most large-scale deployments are
mixtures of both cluster types.
It is also possible to deploy multiple portal clusters to improve availability, failover, and disaster recovery.
It is recommended that you review the cluster guidelines and limitations topics for more information
about what is involved in setting up a cluster.
Installing 99
Clustered servers topology on page 39
Application Server Network Deployment, where the portals share a common configuration and load is
distributed evenly across all cluster instances.
Setting up a cluster on Windows on page 1359
Clusters enable you to scale your IBM WebSphere Portal configuration. Clusters also enable enterprise
applications to be highly available because requests are automatically routed to the running servers in the
event of a failure. There are numerous cluster configuration, such as horizontal, vertical, multiple, and
dynamic.
Setting up a clustered production environment on z/OS on page 1614
When creating a cluster of IBM WebSphere Portal servers, you can start with a standalone production
server as your primary node or you can start with an existing IBM WebSphere Application Server
managed server node. After creating the cluster with either option as the starting point, you can begin to
add additional nodes to meet your business needs.
Guidelines for setting up a cluster
When planning to setup a WebSphere Portal clusters, you must take into account any cluster planning
required for the WebSphere Application Server nodes. If you are not familiar with WebSphere Application
Server clustering, find resources here to help you get started.
Before you begin
In WebSphere Application Server, a cluster is composed of multiple identical copies of an application
server. A cluster member is a single application server in the cluster. WebSphere Portal is installed as an
enterprise application server within the WebSphere Application Server infrastructure. All of the clustering
features available within the WebSphere Application Server infrastructure are also available and apply to
WebSphere Portal. Thus, a WebSphere Portal cluster is simply a collection of multiple WebSphere Portal
servers that are identically configured.
z/OS only note: The server short name must be unique within a cell. If you are planning to build a
horizontal cluster, make sure to define a unique short name for all the nodes in the cell.
For additional planning information, refer to the appropriate IBM WebSphere Application Server Network
Deployment version at http://www.ibm.com/software/webservers/appserv/was/library/.
Guidelines for implementing cluster environments
Cluster environments should be implemented according to the following guidelines:
v You can have a mixed 32-bit and 64-bit operating system environment; for example, you can have your
deployment manager installed on a 64-bit operating system and your portal node installed on a 32-bit
operating system.
IBM i limitation: Installation in a mixed node environment is not supported in an IBM i environment.
z/OS note: z/OS only supports a 64-bit architecture.
v There are several approaches you can use to configure an external Web server in a clustered
environment. The instructions provided here for installing a WebSphere Portal follow the approach
recommended by WebSphere Application Server, which involves using the Plug-ins installation wizard
to install the binary plug-in module after the cell has been set up. For a complete description of the
recommended procedure for configuring an external Web server in a clustered environment, refer to
the following information:
Windows: Selecting a Web server topology diagram and road map
Linux: Selecting a Web server topology diagram and road map
IBM i: Selecting a Web server topology diagram and road map
z/OS: Configuring a Web server and an application server on separate machines (remote)
v The deployment manager node must be installed separately before the cells and clusters can be
configured.
v WebSphere Application Server provides database session persistence and memory-to-memory
replication as techniques for HTTP session failover in a clustered environment. Review the following
information to determine whether you want to use one of these techniques in your cluster:
Windows: Task overview: Managing HTTP sessions
Linux: Task overview: Managing HTTP sessions
IBM i: Task overview: Managing HTTP sessions
z/OS: Task overview: Managing HTTP sessions
v z/OS only: WebSphere Portal provides the choice to install into a standalone profile or into the
managed profile of an existing cell. A WebSphere Portal cluster can be formed from nodes that were
installed into a standalone profile, installed into a managed profile, or installed into a combination of
standalone and managed.
v You can create an IBM WebSphere Virtual Enterprise dynamic cluster to run WebSphere Portal. For
each node that will be part of the dynamic cluster, follow the "Setting up a cluster" instructions using a
WebSphere Virtual Enterprise deployment manager.
Important for IBM i only: Dynamic clusters are not supported because WebSphere Virtual Enterprise
does not support installation on IBM i.
v The WasRemoteHostName and WasSoapPort properties, located in the wkplc.properties file, must be
accurate at all times as many ConfigEngine scripts depend on them. If you are in a standalone
environment, these parameters should point to the host name and soap port for the WebSphere_Portal
application server. If you are in a clustered environment, these parameters should point to the
Deployment manager host name and soap port. Only modify these properties when instructed to
during the installation instructions.
v If you add a node to a cell or change a node's configuration after it has been federated to the
deployment manager, synchronize the node's configuration.
v If you are planning to configure an external security manager to perform authentication or
authorization, install and configure the WebSphere Portal cluster first. Verify that the cluster is working
properly before proceeding with the configuration of any external security managers.
v IBM i: Set up a recycling procedure WebSphere Portal database with the following command; this
procedure automatically removes the unused journal files:
CHGJRN JRN(Your DB2 DB Name/QSQJRN) DLTRCV(*YES)
Your DB2 DB Name is the value of the release.DbName property, located in the
Installing 101
Related tasks:
Setting up a cluster on IBM i on page 513
dynamic.
Setting up a cluster on AIX on page 280
dynamic.
Setting up a cluster on Linux on page 728
dynamic.
Setting up a cluster on Solaris on page 1045
dynamic.
Limitations for setting up a cluster
The following limitations apply when setting up a WebSphere Portal cluster:
v You must install WebSphere Portal as a stand-alone node before creating a cluster. You can no longer
install WebSphere Portal into a managed node.
v AIX
IBM i Linux Solaris Windows: Except for the temporary state during the initial setup of the
cluster, WebSphere Portal is not supported when running on a managed node that is not part of a
Note: A cluster can be created which contains only one WebSphere Portal server, enabling a single
WebSphere Portal server to be operational in a managed cell.
v In a clustered environment, it is not possible to change settings through the Global Settings portlet or
the XML configuration interface. These changes must be made by modifying the respective properties
in the WebSphere Integrated Solutions Console.
v To support search in a clustered environment, you must install and configure search for remote search
service on an application server node that is not part of the cluster.
v Administrative actions for WebSphere Portal are immediately visible for the user who completes them.
However, another user can be assured of seeing the changes only if the user logs out of WebSphere
Portal and then logs back in. This limitation applies to both cluster and non-cluster environments.
v When creating a cluster or a cluster member, do not use spaces in the cluster name or the cluster
member name.
v IBM i limitations: Installation in a mixed node environment is not supported in an IBM i environment.
v For the deployment manager and each WebSphere Portal node to be in the cluster, verify that each
system clock is set to within 5 minutes of the others or the addNode command fails.
v z/OS limitations: If you choose to install the federated, unclustered production server deployment
option, you can only install one node, referred to as the primary node. You cannot install any
additional portal nodes.
HTTP session failover
In a clustered environment, all requests for a particular session are directed to the same server instance in
the cluster. In other words, after a user establishes a session (for example, by logging in), the user is
served by the same server instance for the duration of the session. To verify which server is handling
user requests for a session, you can view the global settings portlet, which displays the node name of the
server handling requests. If one of the servers in the cluster fails, the request is rerouted to another server
in the cluster. If distributed sessions support is enabled (either by persistent sessions or
memory-to-memory session replication), the new server can access session data from the database or
another server instance.
Distributed session support must be configured separately in WebSphere Application Server. Refer to the
WebSphere Application Server documentation for information:
v Windows and UNIX: Distributed sessions
v IBM i: Distributed session support
v Distributed sessions
By default failover support is available for WebSphere Portal and any portlets that are installed with the
product. To take advantage of failover support with your own developed portlets, you must ensure that
your portlets are implemented according to best practices.
Failover and lost data
Data that is stored within the JVM memory and not managed by the application server or the WebSphere
Portal server for replication might be lost in the case of failover. Even with the distributed session
support, during a failure, users will not be able to recover any uncommitted information that is not
stored in sessions or other replicated data areas (such as a distributed Map or render parameters). In such
cases, users might have to restart a transaction after a failover occurs. For example, if you are in the
process of working with a portlet and have navigated between several different screens when a failover
occurs, you might be placed back at the initial screen, where you would need to repeat your previous
steps. Similarly, if you are attempting to deploy a portlet when a failover occurs, the deployment might
not be successful, in which case you must redeploy the portlet. The validity of user login sessions is
maintained despite node failures with distributed session support enabled.
In cases where a portlet does not support failover, a "Portlet Unavailable" message is displayed for the
portlet after a failover occurs. If a portlet supports partial or incomplete failover, some data displayed by
the portlet before the failover could disappear after the failover occurs, or the portlet might not work as
expected. In such extreme cases, the user should log out and log back in to resume normal operation.
After a failover occurs, the request is redirected to another cluster member by the Web server plug-in.
Most browsers will issue a GET request as a response to a redirect after submitting a POST request. This
ensures that the browser does not send the same data multiple times without the user's knowledge.
However, this means that after failover, users might have to refresh the page in the browser or go back
and resubmit the form to recover the POST data.
Note: Any portlets or applications that use POST data are affected by this behavior.
Failover considerations for the Web Content Authoring Portlet
When configuring distributed session support in WebSphere Application Server, either for persistent
sessions or memory-to-memory session replication, you can configure the Custom tuning parameters
setting to determine which session attributes are replicated and how often the replication takes place. You
can select a tuning level from "Very high" to optimize for performance to "Low" to optimize for failover.
In order for session information to be preserved after failover when using the Web Content Authoring
Portlet, the custom tuning level should be set so that all session attributes are written.
Installing 103
For example, if the write frequency is set as "Time-based" with a frequency of 10 seconds, any changes to
the Web Content Authoring Portlet session within 10 seconds of the failover will be lost. If the write
frequency is set as "End of the servlet service", the Web Content Authoring Portlet session remains intact
after failover.
During a failover condition, a Web Content Manager user might be placed back at the initial navigation
screen, might have to refresh the browser window. Uncommitted data that is not stored in sessions or
other replicated data areas may be lost. However, apart from these issues, there should be no loss of
service and the user should be able to continue working.
Setting up an IBM i database in a cluster
To communicate with a database, servers running IBM i can use either of two JDBC drivers: the IBM
Toolbox for Java JDBC driver or the IBM Developer Kit for Java JDBC driver (also referred to as the
native JDBC driver). Which JDBC driver you should use depends on how you are setting up your
The JDBC driver is specified by the db2_iseries.DbDriver property in the wkplc_dbtype.properties file,
located in thewp_profile_root/ConfigEngine/properties directory. You can specify the value by editing the
file manually or by selecting the appropriate value using the configuration wizard.
v Native JDBC driver: com.ibm.db2.jdbc.app.DB2Driver
v IBM Toolbox for Java JDBC driver: com.ibm.as400.access.AS400JDBCDriver
Scaling topology considerations
Vertical and horizontal scaling topologies in an IBM i environment require different JDBC driver
configurations, according to how you deploy your database.
Scaling topology JDBC driver considerations
Vertical scaling When setting up a vertical cluster, you can install the
database locally on the same machine as your portal or
remotely on a separate machine. Use the appropriate
JDBC driver, depending on where the database is
installed.
v Local database: Either the native JDBC driver or the
IBM Toolbox for Java JDBC driver can be used.
v Remote database: The IBM Toolbox for Java JDBC
driver must be used for connections to a remote
database.
Horizontal scaling When setting up a horizontal cluster, you must use the
IBM Toolbox for Java JDBC driver. The typical
configuration is to use a remote database for primary
and secondary nodes in the cluster. If you choose, you
can use a local database for the primary node and
configure the secondary nodes to use that database, just
as you would any other remote database. However,
regardless of whether you choose to include a local
database in your environment, you must use the IBM
Toolbox for Java JDBC driver with your horizontal
cluster.
Using a local database in an IBM i horizontal cluster
Although the instructions for setting up a horizontal cluster describe how to use a remote database for
both primary and secondary nodes, you can choose to configure your IBM i horizontal cluster to use a
local database for the primary node instead. In this example, a database and Web Server are locally
installed on the system (System 1) where IBM
WebSphere
Portal and IBM WebSphere Application

Server are installed. System 1 is the primary node. System 2 is the secondary node.
Note: Although it is possible to use a local database on a secondary node instead of the primary node,
this configuration has not been tested and is not documented here.
Important: Even though you are using a local database for the primary node in this scenario, all database
connections are configured as if the database were remote. Specifically, you must use the IBM Toolbox for
Java JDBC driver (com.ibm.as400.access.AS400JDBCDriver) when configuring the database for both
primary and secondary nodes.
To use a local database with your primary node, perform the database configuration, with the following
variations when updating properties files in thewp_profile_root/ConfigEngine directory.
wkplc_dbtype.properties
v Specify the JDBC driver in the db2_iseries.DbDriver property. For example:
db2_iseries.DbDriver=com.ibm.as400.access.AS400JDBCDriver
v Specify the database location as remote in the db2_iseries.DbDriverType property. For
example:
db2_iseries.DbDriverType=4
wkplc_comp.properties
v Specify the primary node's host name for the domain.DbName properties. For example:
release.DbName=primary_host_name/wpsdb
v Specify the primary node's host name in the domain.DbUrl properties. For example:
release.DbUrl=jdbc:as400:primary_host_name/wpsdb
Note: If using the configuration wizard for database transfer, update the values in the wizard panels
rather than in the properties files.
Installing 105
Complete all other configuration as described. When configuring secondary nodes in this scenario,
perform your database configuration as you would for any remote database, using the primary node's
host name for the database transfer.
Security options
The security model in IBM WebSphere Application Server and IBM WebSphere Portal affects the planning
and implementation of security in a cluster. Security is enabled by default for the WebSphere Application
Server deployment manager; WebSphere Portal will not attempt to change the security settings in the
deployment manager cell whenever a node is federated. This means that any existing security
configuration of a stand-alone WebSphere Portal is replaced with the security settings of the deployment
manager cell when it joins that cell. If you remove the node from the deployment manager cell, the
original security settings are reinstated.
Default security settings
The default security that is enabled on the deployment manager profiles and WebSphere Portal profiles
installation is the Virtual Member Manager (VMM) federated security with a single file-based repository
configured. If you plan to add the standalone node into a deployment manager cell, there is no need to
modify this default security setting on a WebSphere Portal node when the purpose of that node is to join
a deployment manager cell and run as part of a cluster. During federation, the standalone environment
security settings are replaced with the deployment manager security settings. The original standalone
environment security settings are preserved and will revert back to the original settings if you remove the
node from the cluster.
Note: If administrative security is disabled during installation of the deployment manager or is disabled
after the deployment manager is installed, it must be enabled prior to executing the security
configuration tasks on the WebSphere Portal cluster members.
WebSphere Portal also supports the option of installing into a managed profile of an existing cell. In this
case, WebSphere Portal will inherit the security settings of the existing cell. Certain security options, such
as standalone LDAP or custom user registry, will collect information during the installation to allow
WebSphere Portal to adapt to the existing security settings.
Security options for a cluster
There are many security options that can be used in a cluster. All of the VMM federated security options,
including multiple LDAP repositories, database repositories, and the default file-based repository can be
used. Additionally there is an option to use standalone LDAP security instead of the VMM federated
security approach.
WebSphere Portal provides a number of security tasks, which can be used to modify the WebSphere
Application Server security settings and make the required updates to the WebSphere Portal
configuration in a single step. As soon as a WebSphere Portal node is federated into a deployment
manager cell, all executed WebSphere Portal security tasks will update the security configuration on the
deployment manager cell. Run security tasks after federating the WebSphere Portal node because the
Deployment Manager cell does not contain the configuration resources required to run the security tasks.
The tasks under Setting up a clustered production environment recommend configuring security before
configuring your additional nodes. If you configure your security after configuring your additional nodes
or if you need to update your security configuration after you created your clustered environment, you
will need to run an additional task to update the security settings on the secondary nodes; see
"Configuring security after cluster creation" for information.
Note: It is not recommended to use the file-based repository in a production environment. The reason is
that updates are only possible through the WebSphere Integrated Solutions Console, not through portal
user management. These updates are sent to each node in the cell using deployment manager file
synchronization. This can be time consuming for large volumes of users and groups. Also,
synchronization does not occur at the same time for all nodes in a cell, so there are time windows when
the nodes in the cell have differing security definitions. Another reason the file-based repository is not
recommended in a production environment is that the Users and Groups portlet is not available. You
must remove the file-based repository and replace it with a stand-alone LDAP user registry or a
federated LDAP user registry to have access to the Users and Groups portlet.
Related tasks:
Enabling LDAP security after cluster creation on page 2685
If you set or changed your security configuration after you created your clustered environment, you will
need to update the security configuration on all secondary nodes by updating the wkplc.properties file
and running the update-jcr-admin task.
Security Scenarios
When setting up a cluster, there are two scenarios that must be considered. There is out-of-box security
used when you first set up the cluster environment where the deployment manager has not configured
the security settings. The second scenario is when an existing deployment manager has already
configured the security settings prior to a node joining a cell.
Out-of-box security
The first scenario is when the default Virtual Member Manager (VMM) file-based repository security is
used on both the WebSphere Portal nodes and the deployment manager. When the WebSphere Portal
node is federated into the deployment manager cell, the node's security settings are replaced with the
deployment manager security settings. Thus, prior to federating the first WebSphere Portal node into the
cell, the required group for WebSphere Portal administrators and administrative user; for example,
wpsadmins and wpsadmin; must be defined in the deployment manager's security repository. Otherwise,
the WebSphere Portal administrators group and administrative user are lost when federating the node
into the deployment manager.
Once the cluster has been set up, you can modify the security settings of the cell. Although it is possible
to modify security in the cell using the WebSphere Integrated Solutions Console, you should use the
WebSphere Portal security tasks to change cell security in order to ensure that the security configuration
settings for WebSphere Application Server and WebSphere Portal are identical.
Note: Using the WebSphere Integrated Solutions Console to configure or update the out-of-box security is
NOT supported in a stand-alone environment. This option is only supported in a clustered environment
that uses the Deployment Manager WebSphere Integrated Solutions Console.
Modified security with Virtual Member Manager (VMM) federated
The second scenario is when the existing deployment manager cell has already modified its default
security setting prior to the first WebSphere Portal node joining the cell. WebSphere Portal supports the
capability of using two different sets of administrative user ID and password credentials when federating
a WebSphere Portal node into a cell one set for the WebSphere Portal node authentication and one set
for deployment manager authentication. This means that it is not necessary to define a common
administrative user ID before WebSphere Portal joins the cell. If the deployment manager cell is using
federated VMM with additional repositories, the security settings on the Portal node are replaced with
the modified deployment manager VMM federated security settings. The original stand-alone
environment security settings are preserved and revert back to the original settings if you remove the
node from the cluster.
Modified security with standalone Lightweight Directory Access Protocol (LDAP) server
If the deployment manager cell is using standalone LDAP security, it is necessary to configure the LDAP
values into the WebSphere Portal property files before federation. This enables WebSphere Portal to
dynamically adapt to the existing standalone LDAP security settings of the cell. As with the first scenario,
Installing 107
once the cluster has been set up then security changes to the deployment manager cell security settings
can be made using the WebSphere Portal security tasks, and additional WebSphere Portal nodes may be
added to the cell following the same procedures.
Using external security managers in a cluster
If you are configuring security for IBM WebSphere Portal with an external security manager, review some
additional considerations, depending on the external security manager that you are using. Complete any
configuration for an external security manager after you have completed all other setup, including
ensuring that the WebSphere Portal cluster is functional. In addition, review the "Systems requirement"
file to ensure you are using a supported level of the external security manager software.
General considerations
The following considerations apply to all external security managers:
v When setting up security in a cluster to use an external security manager, ensure that you review and,
if required, perform the security configuration on each node in the cluster, as described in the
following topics:
IBM Tivoli Access Manager: Configuring Tivoli Access Manager on page 3235
v When setting up security in a cluster to use an external security manager, ensure that you review and,
if required, perform the security configuration on each node in the cluster, as described in
Configuring Tivoli Access Manager on page 3235.
v If you make any changes to the external security manager configuration after initially setting it up, first
make the changes in the wkplc_comp.propreties on the primary node of the cluster. If additional nodes
exist in the cluster, ensure that any changes you make to the wkplc_comp.properties file on the
primary node are propagated to the wkplc_comp.properties file on other nodes in the cluster.
Tivoli Access Manager cluster considerations
v Ensure that you run the validate-pdadmin-connection task on each node in the cluster.
v If the validate-pdadmin-connection task fails, run the run-svrssl-config task before attempting to run
validate-pdadmin-connection again. Note that the wp.acc.impl.PDServerName parameter in the
wkplc_comp.properties file represents an individually configured AMJRTE connection to Tivoli Access
Manager, and each node in the cluster must have a unique value for wp.acc.impl.PDServerName before
running the run-svrssl-config task.
v If you are using an external Web server, additional configuration is required before running any task to
configure an external security manager with a WebSphere Portal cluster. Edit the
wkplc_comp.properties file on each node, and ensure that the values for the wp.ac.impl.JunctionHost
and wp.ac.impl.JunctionPort properties are set to the backend server host name and port number you
are using for your Web server.
v Ensure that the WebSEAL Trust Association Interceptor (TAI) parameters, found in the
wkplc_comp.properties file, are the same on each node in the cluster. If you run a configuration task
that overwrites the WebSEAL junction, the WebSphere Application Server TAI properties are not
automatically updated. Therefore, you must manually ensure that all nodes are using the same
parameters. To manually ensure the nodes are the same, use the Deployment Manager WebSphere
Integrated Solutions Console and go to Security > Global security > Web and SIP Security > Trust
Association > Interceptors > com.ibm.sec.authn.tai.TAMETai > Custom properties.
Note: If you are still using the deprecated Trust Association Interceptors (TAIs) implementation, go to
Security > Global security > Web and SIP Security > Trust Association > Interceptors >
com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus > Custom properties.
v Enter the file location specified by the wp.ac.impl.PDPermPath parameter in the wkplc_comp.properties
file. This property indicates the location of the Tivoli Access Manager AMJRTE properties file
(PdPerm.properties). In a cluster composed of nodes with different operating systems, the location of
the PdPerm.properties file might differ, depending on the node.
The value for wp.ac.impl.PDPermpath can be set globally for all cluster members. Use the
com.ibm.websphere.security.webseal.configURL property, accessed in the Deployment Manager
WebSphere Application Server. Go to Security > Global security > Web and SIP Security > Trust
Association > Interceptors > com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus >
Custom properties. Because the Deployment Manager security configuration is not sensitive to each
node's filesystem type, the value for the configURL property must be resolved on each node.
To ensure that the location of the PdPerm.properties file is properly specified, use one of the following
approaches:
If your nodes are all on UNIX platforms, use the UNIX link command (ln) to ensure the value for
0.om.ibm.websphere.security.webseal.configURL resolves on each node.
If the PdPerm.properties file location differs on each node and your cluster consists of different
platforms, this property can accept a WebSphere Application Server variable to establish a location
on each node's filesystem to correctly reference the file.
Planning for multiple clusters
Get an overview of the concepts associated with setting up multiple clusters. Multiple clusters are sets of
servers that are managed together within a single administrative domain known as a cell, and participate
in workload management.
IBM WebSphere Application Server Network Deployment provides the ability to manage many
application servers and application server clusters within a single administrative domain, or cell. The
single cell has the following advantages:
v A single administration User Interface (WebSphere Integrated Solutions Console)
v A single administrative scripting client (wsadmin)
v Shared resources at the cell, node, or server scope
v Replication domains for sharing application data, state information, and caches
v Work load management at the web server level providing a single server identity for all applications
hosted across the cell, enabling ease of collaboration between applications while building a rich user
application experience
An administrator's goal is to manage as many WebSphere Portal and portal-based products within the
same managed cell as possible, to take advantage of these administrative and run time features.
WebSphere Portal provides the ability to federate multiple, independently configured portals into the
same cell. While there are limitations to this support, this allows multiple clusters to be managed
together, where one portal may be providing different applications or services than another portal. With a
common server identity through the web server, these services and applications can integrate seamlessly
at the browser through the latest in Web 2.0 technology (for example through the use of Ajax and REST
services).
How multiple clusters work in a single cell
It is important to first understand that a cells configuration has the notion of scope, which controls the
visibility of that resource to other resources and application server instances. An example of a resource
might be a data source definition, or a WebSphere variable definition. Scopes are typically defined as
being one of the following:
Cell All resources defined at this scope are visible to all other resources defined in the cell, and are
thus configured globally available
Node A cell has one or more nodes, and each node is named and matches with some WebSphere
Installing 109
Application Server profile on some physical server. All resources defined at this scope are visible
only to other resources defined in this same node, including any server definitions
Server A node has one or more server definitions. All resources defined at this scope are visible only to
that server. No other server or node can make use of these resources
Cluster
A resource defined at a cluster scope is visible to all cluster members, or server instances, in this
cluster, but is not visible to any other servers in the same nodes
Note: Resources defined within a circle, can be seen by all other resources defined within that circle and
any other scopes defined within that circle.
Within this concept of scope, an important point is that all enterprise applications are cell-scoped. In
other words, there can only be one enterprise application with a given name in the cell. If multiple
servers and clusters, or multiple clusters require the use of that enterprise application, they must share it.
Note: IBM WebSphere Virtual Enterprise offers the ability manage multiple editions of the same
enterprise application, including the mapping of these editions to different servers and clusters, or to
different clusters. WebSphere Portal, however, does not currently exploit this feature.
Typically, when installing an enterprise application that will be shared across multiple clusters, the
administrator simply installs the enterprise application archive (EAR) into the cells management server,
Deployment Manager, and then maps the application to the target clusters where it will run. Since
WebSphere Portal installs several enterprise applications as part of its basic configuration and typically
before any cluster is defined, special steps have to be followed to ensure that these infrastructure
applications are appropriately shared when multiple WebSphere Portal clusters are defined within the
same cell. And by extension, since these are infrastructure applications, all WebSphere Portal-based
clusters must be at the same version.
Since portlets are enterprise applications of a special type, it is possible, but not always appropriate, to
share portlets across multiple clusters. Many portlets (for example WebSphere Portal administration) are
considered part of the infrastructure, and as a result can be shared across multiple clusters. Most user
application portlets are specific to certain clusters and are installed as such. See the Portlet deployment
best practices section for more details.
Also, the J2EE security configuration for the cell is shared by all servers and clusters managed in the cell.
Therefore, each server and cluster must share the same underlying user repository against which users
are authenticated when using any application hosted by any server and/or cluster in that same cell.
To summarize at a high level, supporting multiple clusters in the same cell involves:
v A common security model, including user repositories, for every cluster
v Some number of common enterprise applications and portlets, that must be made common as part of
the federation and clustering process
v Installing portlets into certain clusters, or across clusters, as appropriate
v Understanding how to tell if enterprise applications are shared between clusters
v Defining other resources at the appropriate scope, depending on the usage goals
Limitations
All portal clusters must be at the same maintenance levels
Because WebSphere Portal is made up of several enterprise applications, and because these
applications are tightly coupled to the underlying services and infrastructure, all portal-based
clusters in the same cell must be at the same service level.
Process Server considerations
In the case where multiple clusters need access to a common Process Server, the server should be
centralized within its own cluster, and the client install option of Process Server should be used
in conjunction with WebSphere Portal to allow remote access to the central process server cluster.
WebSphere Virtual Enterprise Static clusters
You cannot install WebSphere Virtual Enterprise on IBM i; therefore, you must install WebSphere
Virtual Enterprise on a remote non-IBM i machine and use the WebSphere Virtual Enterprise On
Demand Router (ODR) to balance workload across multiple clusters. See Routing requests across
clusters for information about ODR.
Database sharing between multiple clusters:
There are multiple database domains that are used in a typical IBM WebSphere Portal environment, such
as the release domain, customization domain, and community domain. In most cases, the relevance of
data within these domains is WebSphere Portal specific. In other words, different database domains are
used for different configurations, because the application mix and user community is likely different. In
many cases, you may want to support multiple identically configured WebSphere Portal installations in
the same cell, where many of the database domains might be shared, for ease of maintenance or failover.
In the case that two independently configured clusters exist within the same cell, each cluster should
have its own set of database domains. In the case that two clusters configured identically exist within the
same cell, all database instances should be shared except the release and JCR database domain. This
ensures that all user-specific and community data is shared between clusters, while each clusters static
configuration can be independently updated.
Special Database Considerations when Sharing Domains
When configuring multiple clusters which will reside in the same IBM WebSphere Application Server cell,
special attention must be given to the database settings.
v Based on your configuration case, determine which database domains you want to share with other
clusters which reside in the same cell (multiple cluster environment).
Important: JCR domains and release domains cannot be shared between different clusters or servers.
Each distinct cluster or server in your environment must use a separate JCR domain and a separate
release domain. For example:
Installing 111
Table 30. Examples of separate JCR or Release domains between all clusters or servers when using Web Content
Manager.
Development Server Authoring Cluster Staging Server Delivery Cluster
JCR Domain 1 JCR Domain 2 JCR Domain 3 JCR Domain 4
Release Domain 1 Release Domain 2 Release Domain 3 Release Domain 4
v Assign the data source names for the domains based on which databases should be shared between the
clusters and which should be unique per cluster. A single data source cannot be used for multiple
domains if the domains are a mixture of shared and non-shared.
v Maintain the same number of data sources with identical names in the case where enterprise
applications are to be shared across all clusters in the same cell, so that data source bindings in the
applications can be resolved on every cluster in which they run.
v When installing the primary node of the next cluster (Cluster B), the node can be configured to use the
shared database domains by setting the appropriate property values in the wkplc_dbdomain.properties
and wkplc_dbtype.properties files.
Related concepts:
Shared database domains on page 70
Database domains classify and help you determine how to distribute portal data. To maximize data
availability, you can distribute portal data across multiple databases and, for some domains, share data
between multiple lines of production. You can choose to transfer a single database domain or multiple
domains.
WebSphere Virtual Enterprise Dynamic Clusters
You can create a IBM WebSphere Virtual Enterprise dynamic cluster to run IBM WebSphere Portal.
Important for IBM i only: Dynamic clusters are not supported because WebSphere Virtual Enterprise
does not support installation on IBM i.
Restriction: z/OS only: Dynamic clusters are not supported in a cluster using a stand-alone production
server (unmanaged server node). If you plan to create a dynamic cluster using IBM WebSphere Virtual
Enterprise, you must create a cluster using managed server nodes.
For each node that is part of the dynamic cluster, follow the instructions to install and configure
WebSphere Portal in a production environment using WebSphere Virtual Enterprise as the deployment
manager. However, do not run the task to set up a static cluster. After installing and preparing all nodes,
follow the instructions provided to set up a WebSphere Virtual Enterprise node group and dynamic
cluster for WebSphere Portal.
The WebSphere Virtual Enterprise On Demand Router (ODR) component provides capabilities such as
workload balancing, prioritization, health monitoring, and dynamic operations for dynamic clusters. An
ODR can be configured to provide multi-cluster routing, including dynamic clusters located in remote
cells, and routing to other servers that are not running WebSphere Virtual Enterprise. The ODR can serve
as a replacement for the HTTP server plug-in, but in many configurations both components are used. The
HTTP server could be located in the demilitarized zone to serve static content and to provide an entry
point to the private network where the ODR resides.
Review the following considerations before configuring the On Demand Router (ODR) to route traffic to
WebSphere Portal clusters:
v Internal users can send requests directly to the ODR instead of through a front-end web server. When
sending direct requests, you must configure the ODR to append a via header to the HTTP requests. Set
the value of the ODR custom property http.compliance.via to true; see the "On demand router
settings" link in the Related section for information.
Note: This step is not required when sending user traffic through the web server to the ODR because
the web server appends the via header to the HTTP request.
v The ODR can selectively route traffic to clusters based on the incoming URL. You can configure IP alias
values for the ODR and then define routing rules to associate user traffic for each IP alias to the
appropriate WebSphere Portal cluster.
v You can use the ODR to load balance traffic among identical portal clusters. You can configure a
Multicluster Routing Policy (MCRP) for the ODR to identify the destination clusters and the type of
load balancing; see the "Configuring the on demand router for multi-cluster failover and load
balancing routing" link in the Related section for information.
Note: If you are configuring the ODR to route traffic to remote portal static clusters using Generic
Server Cluster definitions, the cell_name value used by the MCRP policy needs to be the local cellname
where the ODR resides and not the remote cell where the portal cluster resides.
v You can also use the ODR to route traffic to remote portal clusters, both static and dynamic, by
defining a generic server cluster for each target portal cluster; see the "Defining generic server clusters
for remote ODR cells" link in the Related section for information.
Note: If you are routing to remote static clusters that use vertical cluster members, you must perform
the optional step at the end to define a server custom property for each port in the generic server
cluster.
Important: When applying maintenance to upgrade the WebSphere Virtual Enterprise and WebSphere
Application Server Network Deployment version level, it is important that the deployment manager
remain inactive until both upgrades are complete because if the deployment manager is active before
both upgrades are complete it may detect an incompatible version of WebSphere Virtual Enterprise and
remove some required resources from the dynamic cluster. Keeping the deployment manager inactive
until both Network Deployment and WebSphere Virtual Enterprise updates are complete insures that this
potential problem does not occur.
See Preparing WebSphere Application Server Network Deployment to install the product for information
on the order of product installation to prepare for WebSphere Virtual Enterprise and ODR.
See Creating and configuring ODRs for information on creating an ODR.
Before creating your dynamic cluster, install the following interim fixes:
v PM58489
v PM57308
v PM59390
Go to Fix Central to find the interim fixes.
Cluster maintenance
Maintaining IBM WebSphere Portal in a cluster typically means applying corrective services (fix packs
and interim fixes) or updating the software release level on each node in the cluster. Instructions for
applying corrective service to a WebSphere Portal cluster are provided with the corrective service
package. Before applying any maintenance, it is always important to analyze any impact to your end
users and ensure that you are able to provide uninterrupted service (also referred to as 24x7 availability),
even during the maintenance phase.
For the discussion in this section, we classify fixes as "minor" if they do not update the underlying
WebSphere Portal databases or require version upgrades to other supporting software such as databases
servers or IBM WebSphere Application Server. Most of the WebSphere Portal service packs are not
considered minor and may require the use of a separate installation procedure to ensure 24x7 availability.
Installing 113
Note: If you have not implemented horizontal scaling in your environment; for example, you have only
vertical servers in your cluster, any fix that requires a restart will result in temporary outage for your end
users. Existing 24x7 install procedures do not apply to these environments.
Warning: You do not need to remove the node from the cluster when applying fixes; doing so may result
in the inability to add the node back to the cluster.
Minor fixes
All minor fixes to WebSphere Portal in a clustered environment can be deployed by simply applying the
fix on each cluster node using the install instructions supplied with the fix. When applying minor fixes
that might update previously deployed enterprise applications, be sure to turn off the
auto-synchronization feature of the deployment manager before applying the fix. After the fix is deployed
on all cluster nodes, you can force a manual synchronization using the deployment manager to ensure
that all updates are synchronized on the nodes. You can then enable the auto-synchronization feature
again.
If the documentation associated with the minor fix requires that WebSphere Portal or WebSphere
Application Server be restarted, be sure to apply the minor fix one node at a time. This will enable other
nodes to continue to provide service to your end users. However, if the fix requires an update to the
WebSphere Portal databases, you might be required to stop the cluster before applying the fix. If this is
the case, use a procedure that ensures 24x7 availability.
Fixes and service packs
There are multiple approaches to installing service packs into a WebSphere Portal clustered environment.
The recommended approach uses multiple production clusters. Installing a service pack involves
modifying the IP sprayer to remove a cluster from receiving user requests, which allows time to finish
handling existing user sessions, and upgrading that cluster to install the service pack on all nodes. After
verification testing assures that the upgraded cluster is operational, it can start receiving production
traffic while the next cluster is taken offline and goes through the upgrade process. This approach
preserves complete 24x7 availability during the upgrade process.
A separate document is available which describes the process of installing WebSphere Portal service
packs (fix packs) into an existing cluster while maintaining 24x7 availability. To briefly summarize this
procedure, you remove a node or set of nodes from the flow of user traffic by configuring the IP sprayer
and Web server. You then upgrade the node with the service packs. After upgrading is complete, you
return the node or set of nodes to the flow of user traffic, while repeating the procedure with the next
node or set of nodes. This process continues until you have upgraded all nodes in the cluster.
Important: While the upgrade process is taking place, some portlets may become temporarily unavailable
because of updates to the shared database, which are incompatible with the previous version of the
portlet. This can introduce functional limitations to the 24x7 availability when using this process.
Related tasks:
Setting up a cluster on IBM i on page 513
dynamic.
Setting up a cluster on AIX on page 280
dynamic.
Setting up a cluster on Linux on page 728
dynamic.
Setting up a cluster on Solaris on page 1045
dynamic.
Virtual environment overview
You can use virtualized environments, for example VMWare ESX, to meet your business needs such as
production server consolidation, centralized management, or dynamic test environments. The virtual
environment provides transparency to the operating systems, applications, and middleware that it uses.
There are special considerations to be made when running IBM WebSphere Portal in a virtual
environment. Virtual machines work best when used to consolidate test and development servers, where
multiple virtual machines can share physical machine resources, and even "over commit" those resources,
under the assumption that at any given time not all of the system's resources are needed. This does not
mean that virtual machines cannot be used for production delivery, except that special care must be taken
to not overcommit vital resources. Also, because of the extra processing layer, the physical system's
memory and CPU that handles the context switching and memory management for the virtual machines,
performance can start to degrade under heavy use as compared to native installations. Careful testing
needs to be done to understand WebSphere Portal's performance in your virtualized environment and to
know how far to scale WebSphere Portal to compensate for any degradations.
For virtualized test and development environments, you can overcommit the physical resources of the
machine. For production environments, ensure that there is sufficient physical CPU and memory to
service each virtual machine. A good rule for memory requirement is to double the WebSphere Portal
instance's maximum heap size and use that as the virtual machine memory configuration. Memory
paging, both within the virtual machine and in the hypervisor should be strictly avoided as that can lead
to performance degradation.
Installing 115
Related tasks:
Localizing a new virtual machine instance on Linux on page 910
If you are using VMware ESX, you can create a virtual environment that allows you to create virtual
instance. When a new virtual instance is created, you must update IBM WebSphere Portal with the
machine-specific information, such as the host and node names of the instance.
Localizing a new virtual machine instance on Windows on page 1540
Multiple profile support
Note: For more information on application server profiles, see Managing profiles on non-z/OS operating
systems.
Starting in WebSphere Portal Version 7, it is possible to create additional profiles in addition to the
default profile, which is useful in the following popular scenarios:
v Reuse a single installation for multiple independent portal instances, such as for various test or
development efforts.
v Recover from a configuration problem by deleting the current profile and re-creating it without having
to re-install the product.
v Create custom profiles to easily expand a cluster's capacity without having to manage the extra,
nonessential resources of a regular standalone instance.
v Update a Deployment Manager profile to handle portal servers and thus avoid all the manual
preparation steps.
The following profile types can be generated:
portal.default
This is a profile holding a standalone portal server in the captured configuration. It might be
used as a standalone server or after the federation as a base for a portal cluster.
managed.portal
This custom profile is enhanced with the portal run time environment but does not contain any
servers. The main purpose of this profile is to use it as a run time environment for additional
cluster members. After the federation of this custom profile, the standard portal tasks can be used
to create a portal server cluster member from an existing cluster template.
management.portal.augment
This profile is created by augmenting a standard Deployment Manager profile. The resulting
profile holds a deployment manager prepared for use with portal. It can be used to federate the
other portal profiles immediately without the need for the additional manual steps. Because the
deployment manager is often located on different hardware, there is the possibility to move this
augmentation template to another installation and run it there.
Search Collection and Multiple Profiles
When you run the enable-profiles or replace-profiles tasks, all existing Search collections are captured
in the profile template. The Search functionality does not support sharing Search collections between
multiple profiles. Before running the enable-profiles or replace-profiles tasks, you should either
delete all search collections, including the default Search collections to avoid search errors when you
create the additional profiles. You can use the back up and restore procedures to preserve the search
collections on the original profile or you can use the following export and import steps:
1. Export the existing search collections.
2. Remove the existing search collections.
3. If you installed WebSphere Portal as a non-root user, run the chmod -R g+rwx /portal_server_root
task to modify permissions for the Portal Server directory.
4. Run the enable-profiles or replace-profiles configuration task to capture the Portal configuration
in the profile template.
5. Import the saved search collections on the original profile.
6. Create new profiles using the profile templates; default search collections will be automatically created
in the new profile.
7. Run the chmod -R g+rx /portal_server_root task to restore permissions to the Portal Server directory.
If you want to share search collections between multiple Portal server instances, such as in a clustered or
Portal Farm environment, then you must configure a remote search server to support the sharing of the
search collections.
Special considerations for cluster configurations
As a best practice, you should manage all maintenance at the cluster level. That means that during
maintenance application to a cluster, the entire cluster should be taken out of service, so that cluster-wide
changes can take effect without affecting user traffic or potentially causing synchronization conflicts
between cell managed resources, like enterprise applications and portlets, and the product binary files in
the local file system. In a continuous availability environment, multiple clusters might be necessary, to
allow traffic to continue to one cluster while another is being serviced.
Maintaining a WebSphere Portal installation with multiple profiles involves applying maintenance to the
product binary files as well as applying maintenance to each profile instance. It is important that all
profile instances and the WebSphere Portal product binary files are updated at the same time to avoid
conflicts. If one of the profiles on a particular installation belongs to a cluster, then whenever that cluster
is updated, the shared WebSphere Portal product binary files and all other profiles on the system must be
updated as well to maintain synchronization.
Therefore, in the event that multiple portal profiles using a single set of product binary files are used as
part of a cluster configuration, it is strongly recommended that all profiles sharing the same product
binary files belong to the same cluster to stay consistent with the best practice of applying maintenance at
the cluster boundary.
Installing 117
Related tasks:
Supporting multiple profiles on page 1685
When installing IBM WebSphere Portal, a default configuration profile is created (wp_profile). You can
now create and maintain multiple profiles to create multiple independent portal instances, create new
profiles and delete the old to recover from configuration problems, create custom profiles to easily
expand your cluster's capacity, or update a Deployment Manager profile to handle portal servers without
manual preparation steps. To support multiple profiles you must first prepare your system, create or
augment profiles, run configuration tasks on the profiles, and then maintain the profiles if you install
maintenance packages. You may also need to update the configuration archive or delete a profile that is
no longer required.
Creating and maintaining multiple profiles on AIX on page 1686
The multiple profile feature allows you to install IBM WebSphere Portal once and then create multiple
profile instances based on the original installation. You can create additional profiles immediately after
installation if you want each profile instance to use the unmodified version of the WebSphere Portal
configuration or you can create the additional profiles after you have installed and configured WebSphere
Portal to create a customized environment that you want to use as the basis for additional profiles. You
can also augment an existing IBM WebSphere Application Server default profile to add WebSphere Portal
to that existing profile.
Creating and maintaining multiple profiles on IBM i on page 1695
Creating and maintaining multiple profiles on Linux on page 1703
Creating and maintaining multiple profiles on Solaris on page 1712
Creating and maintaining multiple profiles on Windows on page 1722
Portal farm considerations on page 47
and maintain a highly scalable, highly available server environment.
Getting the software
There are different ways for you to get WebSphere Portal and Web Content Manager version 8.0 software.
Physical media
WebSphere Portal is available on DVD. Installing from physical media is practical when installing on a
limited number of servers.
Benefits:
This option has the following benefits and is best if performing a limited number of installations:
v No prerequisite steps required before installation
v Provides a seamless way to install IBM Installation Manager if it is not currently installed
v Provides an installation path if a file server is not available or is slower than the DVD
Limitations:
v Installing from the DVD on IBM i is not supported
v Silently installing from the DVD is not supported
Linux note: For security reasons, some Linux versions, such as Red hat Enterprise Linux Version
5, prevent programs from running from automounted DVDs. Thus not allowing to run the
installer from the DVD. To fix this issue, add the /dev/hdc /media/ auto
pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0 line to the end
of the /etc/fstab file to update file system table.
Live repository
WebSphere Portal is available for downloading and installing directly from a live repository. All you need
is IBM Installation Manager and select the portal repository from the list.
After you enter your credentials in IBM Installation Manager you are able to see the software repositories
you are entitled to download and install. This option is ideal when performing installations at a large
scale.
To enter your credentials in IBM Installation Manager navigate through File > Preferences > Passport
Advantage. Select the Connect to Passport Advantage check box and enter your credentials.
Benefits:
v Automation is possible through silent installation scripts.
v There is no need to duplicate the installation media throughout the network.
Limitations:
v Network speeds might impact the installation speed.
v IBM Installation Manager must be installed on each system before installing WebSphere Portal.
Electronic images
Use Passport Advantage for downloading the electronic images of WebSphere Portal version 8.0.
Installing is simpler than ever before, IBM Installation Manager makes it easy. The following sections,
formerly referred as download documents, provide download information for the different WebSphere
Portal and Web Content Manager offerings.
Installing 119
Getting WebSphere Portal Server software
This section describes how to download and assemble IBM WebSphere Portal Version 8.0 components
using the Passport Advantage Online web site.
Downloadable eAssembly images
The IBM WebSphere Portal Version 8.0 product consists of multiple offerings and each offering includes
multiple downloadable electronic images packaged by platform. Each platform package is called an
eAssembly and each eAssembly contains all of the electronic images required for that offering to run on
that platform. The following table shows the eAssembly numbers for each of the IBM WebSphere Portal
Version 8.0 offerings.
Important: Download and expand all eAssembly files into the same directory to create a complete
installable image. Failure to expand all files in the same directory will result in an installation failure.
Required software
Table 31. List of eAssembly images for IBM WebSphere Portal and Web Content Manager V8.0 Multiplatform
Multilingual Quick Start Guide
Part number Description
CI7APML IBM WebSphere Portal and Web Content Manager V8.0 Multiplatform Multilingual Quick Start Guide
Table 32. List of eAssembly images for IBM WebSphere Portal Server Setup V8.0
CI7MYML IBM WebSphere Portal Server Setup V8.0 Multiplatform Multilingual
Table 33. List of eAssembly images for IBM WebSphere Portal and Web Content Manager Install V8.0
CI7N3ML IBM WebSphere Portal and Web Content Manager Install V8.0 (1 of 5) Multiplatform Multilingual
Table 34. List of eAssembly images for IBM WebSphere Application Server Network Deployment V8.0.0.3
CI7N8ML IBM WebSphere Application Server Network Deployment V8.0.0.3 (1 of 3) Multiplaform Multilingual
CI7NAML IBM WebSphere Application Server Network Deployment V8.0.0.3 (3 of 3) Multiplaform Multilingual
Optional software
Table 35. List of eAssembly images for IBM WebSphere Application Server V8.0.0.3
CZT7JML Quick Start for IBM WebSphere Application Server V8.0 for Multiplatform Multilingual
CZM91ML IBM WebSphere Application Server V8.0 Supplements (1 of 4) Multiplatform Multilingual
CZXR9ML IBM WebSphere Application Server V8.0 Supplements (4 of 4) Multiplatform Multilingual
Table 36. List of eAssembly images for IBM DB2 9.7.0.4
CI7NBML IBM DB2 9.7.0.4 Limited Use for 64-bit AIX Multilingual
Table 36. List of eAssembly images for IBM DB2 9.7.0.4 (continued)
CI7NCML IBM DB2 9.7.0.4 Limited Use for Linux on 32-bit AMD and Intel systems (x86) Multilingual
CI7NDML IBM DB2 9.7.0.4 Limited Use for Linux on AMD64 and Intel EM64T Multilingual
CI7NEML IBM DB2 9.7.0.4 Limited Use for Linux on POWER (System i and System p) systems Multilingual
CI7NFML IBM DB2 9.7.0.4 Limited Use for Linux on System z Multilingual
CI7NGML IBM DB2 9.7.0.4 Limited Use for Solaris on UltraSPARC systems Multilingual
CI7NHML IBM DB2 9.7.0.4 Limited Use for Solaris on x64 systems Multilingual
CI7NIML IBM DB2 9.7.0.4 Limited Use for Windows on 32-bit AMD and Intel systems (x86) Multilingual
CI7NJML IBM DB2 9.7.0.4 Limited Use for Windows on AMD64 and Intel
EM64T systems (x64) Multilingual

Table 37. List of eAssembly images for IBM Tivoli Directory Integrator V7.1
CZ9MHML IBM Tivoli Directory Integrator V7.1 Quick Start Guide
CZ9MKML IBM Tivoli Directory Integrator Identity Edition V7.1 for Windows - x86-64
CZ9MLML IBM Tivoli Directory Integrator Identity Edition V7.1 for AIX
CZ9MMML IBM Tivoli Directory Integrator Identity Edition V7.1 for Linux Linux - x86
CZ9MNML IBM Tivoli Directory Integrator Identity Edition V7.1 for Linux Linux - x86-64
CZ9MPML IBM Tivoli Directory Integrator Identity Edition V7.1 for Linux - zSeries & s/390
CZ9MQML IBM Tivoli Directory Integrator Identity Edition V7.1 for Linux - POWER (i/p Series)
CZ9MRML IBM Tivoli Directory Integrator Identity Edition V7.1 for Solaris - SPARC
CZ9MSML IBM Tivoli Directory Integrator Identity Edition V7.1 for Solaris -Opteron
Table 38. List of eAssembly images for IBM Tivol Directory Server V6.3
CZK73ML IBM Tivoli Directory Server 6.3 Client-Server with entitlement for AIX, Multilingual
CZK75ML IBM Tivoli Directory Server 6.3, DB2 v 9.7 for AIX, Multilingual
CZK76ML IBM Tivoli Directory Server 6.3, eIBM WebSphere Application Server 7.0.0.7 for AIX, Multilingual
CZK77ML IBM Tivoli Directory Server 6.3, GSKit 8.0.13.1 for AIX, Multilingual
CZK78ML IBM Tivoli Directory Server 6.3, Whitepages for AIX, Multilingual
CZK7BML IBM Tivoli Directory Server 6.3 Client-Server with entitlement for Linux-ia32, Multilingual
CZK7DML IBM Tivoli Directory Server 6.3, DB2 v 9.7 for Linux-ia32, Multilingual
CZK7EML IBM Tivoli Directory Server 6.3, eWAS 7.0.0.7 for Linux-ia32, Multilingual
CZK7FML IBM Tivoli Directory Server 6.3, GSKit 8.0.13.1 for Linux-ia32, Multilingual
CZK7GML IBM Tivoli Directory Server 6.3, Whitepages for Linux-ia32, Multilingual
CZK7HML IBM Tivoli Directory Server 6.3 with entitlement for Linux-ia32, Multilingual
CZK7JML IBM Tivoli Directory Server 6.3 Client-Server with entitlement (tar file) for Linux-ppc64, Multilingual
CZK7LML IBM Tivoli Directory Server 6.3, DB2 v9.7 (tar file) for Linux-ppc64, Multilingual
CZK7MML IBM Tivoli Directory Server 6.3 eWAS 7.0.0.7 (tar file) for Linux-ppc64, Multilingual
CZK96ML IBM Tivoli Directory Server 6.3, GSKit 8.0.13.1 (tar file) for Linux-ppc64, Multilingual
CZK97ML IBM Tivoli Directory Server 6.3, Whitepages (tar File) for Linux-ppc64, Multilingual
CZK98ML IBM Tivoli Directory Server 6.3 with entitlement (ISO File) for Linux-ppc64, Multilingual
CZK9AML IBM Tivoli Directory Server 6.3 Client-Server with entitlement (tar file) for Linux s390, Multilingual
CZK9CML IBM Tivoli Directory Server 6.3, DB2 v9.7 (tar file) for Linux s390, Multilingual
CZK9DML IBM Tivoli Directory Server 6.3, eWAS 7.0.0.7 (tar file) for Linux s390, Multilingual
CZK9EML IBM Tivoli Directory Server 6.3, GSKit 8.0.13.1 (tar file) for Linux s390, Multilingual
CZK9FML IBM Tivoli Directory Server 6.3, Whitepages (tar File) for Linux s390, Multilingual
CZK9GML IBM Tivoli Directory Server 6.3 with entitlement (ISO File) for Linux s390, Multilingual
CZK9IML IBM Tivoli Directory Server 6.3 Client-Server with entitlement (tar file) for Linux x86-64, Multilingual
CZK9KML IBM Tivoli Directory Server 6.3, DB2 v9.7 (tar file) for Linux x86-64, Multilingual
CZK9LML IBM Tivoli Directory Server 6.3, eWAS 7.0.0.7 (tar file) for Linux x86-64, Multilingual
Installing 121
Table 38. List of eAssembly images for IBM Tivol Directory Server V6.3 (continued)
CZK9MML IBM Tivoli Directory Server 6.3, GSKit 8.0.13.1 (tar file) for Linux x86-64, Multilingual
CZK9NML IBM Tivoli Directory Server 6.3, Whitepages (tar File) for Linux x86-64, Multilingual
CZK9PML IBM Tivoli Directory Server 6.3 with entitlement (ISO File) for Linux x86-64, Multilingual
CZKA2ML IBM Tivoli Directory Server 6.3 Client-Server with entitlement (tar file) for Solaris, Multilingual
CZKA4ML IBM Tivoli Directory Server 6.3, DB2 v9.7 (tar file) for Solaris, Multilingual
CZKA5ML IBM Tivoli Directory Server 6.3 eWebSphere 7.0.0.7 (tar file) for Solaris, Multilingual
CZKB1ML IBM Tivoli Directory Server 6.3, Whitepages (tar File) for Solaris, Multilingual
CZV91ML IBM Tivoli Directory Server 6.3 with Entitlement (ISO File) for Solaris, Multilingual
CZV94ML IBM Tivoli Directory Server 6.3, GSKit 8.0.13.1(tar file) for Solaris, Multilingual
CZKC3ML IBM Tivoli Directory Server 6.3 Client-Server with entitlement (zip file) for Windows 32 bit, Multilingual
CZKC5ML IBM Tivoli Directory Server 6.3, DB2 v9.7 (zip file) for Windows 32 bit, Multilingual
CZKC6ML IBM Tivoli Directory Server 6.3, eWAS 7.0.0.7 (zip file) for Windows 32 bit, Multilingual
CZKC7ML IBM Tivoli Directory Server 6.3. GSKit 8.0.13.1 (zip file) for Windows 32 bit, Multilingual
CZKC8ML IBM Tivoli Directory Server 6.3 Whitepages (Zip File) for Windows 32 bit, Multilingual
CZKC9ML IBM Tivoli Directory Server 6.3 with entitlement (ISO File) for Windows 32 bit, Multilingual
CZKE7ML IBM Tivoli Directory Server 6.3 Client-Server with entitlement (tar file) for Solaris x86-64, Multilingual
CZKE9ML IBM Tivoli Directory Server 6.3, DB2 v9.7 (tar file) for Solaris x86-64, Multilingual
CZKF0ML IBM Tivoli Directory Server 6.3, eWAS 7.0.0.7 (tar file) for Solaris x86-64, Multilingual
CZKF1ML IBM Tivoli Directory Server 6.3, GSKit 8.0.13.1 (tar File) for Solaris x86-64, Multilingual
CZKF2ML IBM Tivoli Directory Server 6.3, Whitepages (tar file) for Solaris x86-64, Multilingual
CZKF3ML IBM Tivoli Directory Server 6.3 with entitlement (ISO File) for Solaris x86-64, Multilingual
CZKF5ML IBM Tivoli Directory Server 6.3 Client ONLY for Windows IA32, Multilingual
CZKF6ML IBM Tivoli Directory Server 6.3 Client ONLY image for Windows x86-64, Multilingual
CZKF7ML IBM Tivoli Directory Server 6.3 Client ONLY for Linux x86-64, Multilingual
CZKF8ML IBM Tivoli Directory Server 6.3 Client ONLY for Linux-ppc64, Multilingual
CZKF9ML IBM Tivoli Directory Server 6.3 Client ONLY for AIX, Multilingual
CZKG0ML IBM Tivoli Directory Server 6.3 Client ONLY for Linux s390, Multilingual
CZKG2ML IBM Tivoli Directory Server 6.3 Client ONLY for Solaris x86-64, Multilingual
CZKG3ML IBM Tivoli Directory Server 6.3 Client ONLY for HPUX-IA64, Multilingual
CZKH2ML IBM Tivoli Directory Server 6.3 Client ONLY for Linux-ia32, Multilingual
CZV93ML IBM Tivoli Directory Server 6.3 Client ONLY for Solaris, Multilingual
CZKG4ML IBM Tivoli Directory Server 6.3 Client-Server with entitlement (zip file) for win-x86-64, Multilingual
CZKG6ML IBM Tivoli Directory Server 6.3, DB2 v9.7 (zip file) for Windows x86-64, Multilingual
CZKG7ML IBM Tivoli Directory Server 6.3 eWAS 7.0.0.7 (zip file) for Windows x86-64, Multilingual
CZKG8ML IBM Tivoli Directory Server 6.3, GSKit 8.0.13.1 (zip file) for Windows x86-64, Multilingual
CZKG9ML IBM Tivoli Directory Server 6.3, Whitepages (zip file) for Windows x86-64, Multilingual
CZKH0ML IBM Tivoli Directory Server 6.3 with entitlement (ISO File) for Windows x86-64, Multilingual
Table 39. List of eAssembly images for IBM Web Experience Factory V8.0
CI7R8ML IBM Web Experience Factory V8.0 Multiplatform Multilingual QuickStart
CI7R9ML IBM Web Experience Factory V8.0 Multiplatform Multilingual
Table 40. List of eAssembly images for IBM Connections V3.0.1
CZVP8ML IBM Connections 3.0.1 Quick Start Guide for AIX, Windows, Linux Multilingual
CI3XNML IBM Connections V3.0.1 for Windows Multilingual
CI3XPML IBM Connections V3.0.1 for Linux, AIX Multilingual
CI3XQML IBM Connections V3.0.1 Linux for System z Multilingual
CZVQ9ML IBM Connections 3.0.1 Wizard for Windows Multilingual
CZVR1ML IBM Connections 3.0.1 Wizard for Linux, AIX Multilingual
IBM Passport Advantage
Getting WebSphere Portal Enable software
Required software
Table 42. List of eAssembly images for IBM WebSphere Portal Enable Setup V8.0
CI7V6ML IBM WebSphere Portal Enable Setup V8.0 (1 of 2) Multiplatform Multilingual
CI7V7ML IBM WebSphere Portal Enable Setup V8.0 (2 of 2) Multiplatform Multilingual
Installing 123
Optional software

Installing 125
Table 51. List of eAssembly images for IBM Business Process Manager Express V7.5.1
CI2L7ML IBM Business Process Manager Express Version 7.5.1 Multiplatform Multilingual Quick Start Guide
CI2SRML IBM Business Process Manager Express Version 7.5.1 Windows X86 32bit/X86 64bit (1 of 3) Multilingual
CI2SSML IBM Business Process Manager Express Version 7.5.1 Windows X86 32bit/X86 64bit (2 of 3) Multilingual
CI2STML IBM Business Process Manager Express Version 7.5.1 Windows X86 32bit/X86 64bit (3 of 3) Multilingual
CI2SUML IBM Business Process Manager Express Version 7.5.1 Linux 32bit/64bit (1 of 3) Multilingual
CI2SVML IBM Business Process Manager Express Version 7.5.1 Linux 32bit/64bit (2 of 3) Multilingual
CI2SWML IBM Business Process Manager Express Version 7.5.1 Linux 32bit/64bit (3 of 3) Multilingual
Table 52. List of eAssembly images for IBM Lotus Quickr for WS Portal V8.5
CZGP8ML IBM Lotus Quickr 8.5 for WebSphere Portal Multiplatform Multilingual Quick Start Guide
CZHX4ML IBM Lotus Quickr 8.5 for WebSphere Portal Install (Setup) Multiplatform Multilingual
CZHX5ML IBM Lotus Quickr 8.5 for WebSphere Portal - WebSphere Application Server Network Deployment Windows 32-bit (W-1)
Multilingual
CZHX6ML IBM Lotus Quickr 8.5 for WebSphere Portal - DB2 UDB Enterprise Server Edition Windows 32-bit (W-2) Multilingual
Table 52. List of eAssembly images for IBM Lotus Quickr for WS Portal V8.5 (continued)
CZHX8ML IBM Lotus Quickr 8.5 for WebSphere Portal - WebSphere Application Server Network Deployment Windows 64-bit (W64-1)
Multilingual
CZHX9ML IBM Lotus Quickr 8.5 for WebSphere Portal - DB2 UDB Enterprise Server Edition Windows 64-bit (W64-2) Multilingual
CZHY0ML IBM Lotus Quickr 8.5 for WebSphere Portal - WP 1 of 3 (A-3, IL-3, W-3, ZL-3) Multiplatform Multilingual
CZHY3ML IBM Lotus Quickr Connectors 8.5 (a-6, il-6, w-6, zl-6) Multiplatform Multilingual
CZHY4ML IBM Lotus Quickr 8.5 for WebSphere Portal WAS Extras Windows 32-bit (W-7) Multilingual
CZHY5ML IBM Lotus Quickr 8.5 for WebSphere Portal WAS Extras Windows 64-bit (W64-7) Multilingual
C88UXML Edge Components V6.1, Windows 2000 Windows Server 2003, 32-bit support (for WebSphere Application Svr Network
Deployment V6.1) German English International Spanish French Italian Japanese Korean Portuguese Brazilian Chinese Simplified
Chinese Traditional
C88UYML Edge Components V6.1, Windows 2000 Windows Server 2003 IPv6 32-bit support JVM (for WebSphere Application Server
Network Deployment V6.1) Multilingual
C88XQML Edge Components V6.1, Windows Server 2003 x64, 64-bit support (for WebSphere Application Server Network Deployment V6.1)
German English Spanish French Italian Japanese Korean Portuguese Brazilian Chinese Simplified Chinese Traditional
C88XRML Load Balancer for IPv4 and IPv6 V6.1, Windows 2003 x64 , 64-bit support (for WebSphere Application Server Network
Deployment V6.1) German English Spanish French Italian Japanese Korean Portuguese Brazilian Chinese Simplified Chinese
Traditional
C88XGML WebSphere Application Server Network Deployment V6.1, Application Server Toolkit for Windows XP, Windows 2000, Windows
Server 2003 Multilingual
Table 53. List of eAssembly images for IBM OmniFind Enterprise Edition V9.1
CZH6DML IBM OmniFind Enterprise Edition V9.1 Multiplatform Quick Start Guide
CZH6EML IBM OmniFind Enterprise Edition V9.1 Windows Multilingual
CZH6FML IBM OmniFind Enterprise Starter Edition V9.1 Windows Multilingual
CZH6GML IBM OmniFind Enterprise Edition V9.1 Agent for Windows File System Crawler Multilingual
CZ22BML IBM Content Integrator V8.5.1 Windows Multilingual
CZ22DML IBM Content Integrator V8.5.1 Documentation Multiplatform Multilingual
Getting WebSphere Portal Extend software
Installing 127
Required software
Table 55. List of eAssembly images for IBM WebSphere Portal Extend Setup V8.0
CI7V8ML IBM WebSphere Portal Extend Setup V8.0 (1 of 2) Multiplatform Multilingual
CI7V9ML IBM WebSphere Portal Extend Setup V8.0 (2 of 2) Multiplatform Multilingual
Optional software

Table 60. List of eAssembly images for IBM Tivoli Directory Integrator V7.1 (continued)
Installing 129
Table 63. List of eAssembly images for IBM Connections V3.0.1 (continued)
Multilingual
Multilingual
Chinese Traditional
Traditional
Table 66. List of eAssembly images for IBM OmniFind Enterprise Edition V9.1
CZH6DML IBM OmniFind Enterprise Edition V9.1 Multiplatform Quick Start Guide
CZH6EML IBM OmniFind Enterprise Edition V9.1 Windows Multilingual
CZH6FML IBM OmniFind Enterprise Starter Edition V9.1 Windows Multilingual
CZH6GML IBM OmniFind Enterprise Edition V9.1 Agent for Windows File System Crawler Multilingual
CZ22BML IBM Content Integrator V8.5.1 Windows Multilingual
CZ22DML IBM Content Integrator V8.5.1 Documentation Multiplatform Multilingual
Table 67. List of eAssembly images for IBM WebSphere Dashboard Framework V7.0.1
CI3UKML IBM WebSphere Dashboard Framework V7.0.1 Multiplatform Multilingual Quick Start Guide
Installing 131
Table 67. List of eAssembly images for IBM WebSphere Dashboard Framework V7.0.1 (continued)
CI3ULML IBM WebSphere Dashboard Framework V7.0.1 Multiplatform Multilingual
Table 68. List of eAssembly images for IBM Sametime V8.5.2
CZY9GML IBM Sametime Standard V8.5.2 Multilingual Multiplatform Quickstart Guide
CZY9XML IBM Sametime Entry Community Server V8.5.2 Windows Multilingual
CZY9YML IBM Sametime Entry Community Server V8.5.2 AIX, Linux, Solaris SPARC Multilingual
CZY9ZML IBM Sametime Entry Community Server V8.5.2 IBM i Multilingual
CZZ92ML IBM Sametime Entry Connect Client and Network Installer V8.5.2 Multiplatform
CI3Y9ML IBM Sametime Community Server V8.5.2 IFR 1 Windows Multilingual
CI3YAML IBM Sametime Community Server V8.5.2 IFR 1 AIX, x86 Linux, Solaris Multilingual
CI3YBML IBM Sametime Community Server V8.5.2 IFR 1 IBM i Multilingual
CI3YGML IBM Sametime Connect Client V8.5.2 IFR 1 Windows, x86 Linux, Mac Multilingual
CI3YCML IBM Sametime Proxy Server V8.5.2 IFR 1 Windows, AIX, x86 Linux, Solaris, IBM i Multilingual
CZYE6ML IBM Sametime Standard Proxy Server V8.5.2 Windows Multilingual
CZYE7ML IBM Sametime Standard Proxy Server V8.5.2 AIX Multilingual
CZYE8ML IBM Sametime Standard Proxy Server V8.5.2 Linux on x86 Multilingual
CZYE9ML IBM Sametime Standard Proxy Server V8.5.2 Solaris Multilingual
CZYE1ML IBM Sametime Standard Proxy Server V8.5.2 IBM i Multilingual
CI3Y8ML IBM Sametime System Console V8.5.2 IFR 1 Windows, AIX, x86 Linux, Solaris, IBM i Multilingual
CZYF2ML IBM Sametime Standard System Console Server V8.5.2 Windows Multilingual
CZYF3ML IBM Sametime Standard System Console Server V8.5.2 AIX Multilingual
CZYF4ML IBM Sametime Standard System Console Server V8.5.2 Linux on x86 Multilingual
CZYF5ML IBM Sametime Standard System Console Server V8.5.2 Solaris Multilingual
CZYF6ML IBM Sametime Standard System Console Server V8.5.2 IBM i Multilingual
CI3YIEN IBM Sametime V8.5.2 IFR 1 SDK Multiplatform English
CZYF8EN IBM Sametime Standard V8.5.2 SDK Multiplatform English
CZIP9EN IBM Lotus Domino 8.5.2 32 bit for Windows English
CZJ99EN IBM Lotus Domino 8.5.2 for AIX 32 bit English
CZIQ2EN IBM Lotus Domino 8.5.2 32 bit Linux for xSeries English
CZIQ4EN IBM Lotus Domino 8.5.2 32 bit Solaris English
CZIQ5EN IBM Lotus Domino 8.5.2 for IBM i English
CZIF0EN IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista 3
CZIF7EN IBM Lotus Notes Client 8.5.2 Basic Configuration for Windows English
CZM9UFI IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Finnish
CZM9VDE IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista German
CZM9WKO IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista Korean
CZM9XNO IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Norwegian
CZM9YSC IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista Simplified Chinese
CZM9ZES IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Spanish
CZMA0SV IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Swedish
CZMA1FR IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista French
CZMA2TC IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista Traditional Chinese
CZMA3JA IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista Japanese
CZMA4IT IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Italian
CZMA5DA IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Danish
CZMA6BP IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Brazilian Portuguese
CZMA7NL IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Dutch
CZQ1BCS IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Czech
CZQ1CHU IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Hungarian
Table 68. List of eAssembly images for IBM Sametime V8.5.2 (continued)
CZQ1DRU IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Russian
CZQ1EEL IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Greek
CZQ1FTR IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Turkish
CZQ1GAR IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Arabic
CZQ1HPT IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Portuguese
CZQ1IPL IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Polish
CZQ1KSI IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Slovenian
CZQ1LSK IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Slovakian
CI3YHML IBM WebSphere 7.0.0.15 iFixes for IBM Sametime 8.5.2 IFR 1 Windows, AIX, x86 Linux, Solaris, IBM i Multilingual
CZ1HLML IBM DB2 for Linux, UNIX and Windows 9.7 - Limited Use for Windows on AMD64 and Intel EM64T systems (x64)
CZ1HKML IBM DB2 for Linux, UNIX and Windows 9.7 - Limited Use for Windows on 32-bit AMD and Intel systems (x64)
CZ1HPEN IBM DB2 9.7 Limited Use for Solaris on UltraSPARC systems English
CZ1HMEN IBM DB2 9.7 Limited Use for AIX
English
CZ1HSEN IBM DB2 9.7 Limited Use for Linux
on AMD64 and Intel
EM64T systems (x64) English

CZ1HREN IBM DB2 9.7 Limited Use for Linux
on 32-bit AMD and Intel systems (x86) English

CZYG1ML IBM DB2 9.7 Limited Use for Sametime Standard V8.5.2 Windows 32bit Multilingual
CZYG6ML IBM DB2 9.7 Limited Use for Sametime Standard V8.5.2 x86 Linux 32bit and 64bit Multilingual
CZYA0ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 Windows Multilingual
CZYA1ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 AIX Multilingual
CZYA4ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 Solaris SPARC Multilingual
CZYA2ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 Linux Multilingual
CZYA3ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 IBM i Multilingual
Table 69. List of eAssembly images for IBM Forms V8.0
CI6NYML IBM Forms Server V8.0 Multiplatform Multilingual Quick Start Guide
CI75FML IBM Forms Experience Builder Windows V8.0
CI6PYML IBM Forms Server V8.0 Win 64bit Multilingual
CI6PZML IBM Forms Server V8.0 Win 32bit Multilingual
CI6LYML IBM Forms Viewer V8.0 Windows Multilingual
CI6M0ML IBM Forms Designer V8.0 Windows Multilingual
CI75GML IBM Forms Experience Builder Linux V8.0
CI6Q0ML IBM Forms Server V8.0 Linux 64bit Multilingual
CI6Q1ML IBM Forms Server V8.0 Linux 32bit Multilingual
CI6Q2ML IBM Forms Server V8.0 IBMi 64bit Multilingual
CI6Q3ML IBM Forms Server V8.0 IBMi 32bit Multilingual
CI6Q4ML IBM Forms Server V8.0 AIX 64bit Multilingual
CI6Q5ML IBM Forms Server V8.0 AIX 32bit Multilingual
CI6Q6ML IBM Forms Server V8.0 Solaris 64bit Multilingual
CI6Q7ML IBM Forms Server V8.0 Solaris 32bit Multilingual
CI6Q8ML IBM Forms Server V8.0 zLinux 64bit Multilingual
CI6Q9ML IBM Forms Server V8.0 zLinux 32bit Multilingual
Installing 133
Getting WebSphere Portal Express software
Required software
Table 71. List of eAssembly images for IBM WebSphere Portal Express V8.0
CI7VAML IBM WebSphere Portal Express Setup V8.0 (1 of 2) Multiplatform Multilingual
CI7VBML IBM WebSphere Portal Express Setup V8.0 (2 of 2) Multiplatform Multilingual
CI7VCML IBM WebSphere Portal Express Install V8 (1 of 6) for Multiplatform Multilingual
CI7VDML IBM WebSphere Portal Express Install V8 (2 of 6) for Multiplatform Multilingual
CI7VEML IBM WebSphere Portal Express Install V8 (3 of 6) for Multiplatform Multilingual
CI7VFML IBM WebSphere Portal Express Install V8 (4 of 6) for Multiplatform Multilingual
CI7VGML IBM WebSphere Portal Express Install V8 (5 of 6) for Multiplatform Multilingual
CI7VHML IBM WebSphere Portal Express Install V8 (6 of 6) for Multiplatform Multilingual
Optional software
Installing 135
Table 77. List of eAssembly images for IBM Connections V3.0.1 (continued)
Multilingual
Multilingual
Chinese Traditional
Traditional
Table 80. List of eAssembly images for IBM Sametime V8.5.2
CZY9GML IBM Sametime Standard V8.5.2 Multilingual Multiplatform Quickstart Guide
CZY9XML IBM Sametime Entry Community Server V8.5.2 Windows Multilingual
CZY9YML IBM Sametime Entry Community Server V8.5.2 AIX, Linux, Solaris SPARC Multilingual
CZY9ZML IBM Sametime Entry Community Server V8.5.2 IBM i Multilingual
CZZ92ML IBM Sametime Entry Connect Client and Network Installer V8.5.2 Multiplatform
CI3Y9ML IBM Sametime Community Server V8.5.2 IFR 1 Windows Multilingual
CI3YAML IBM Sametime Community Server V8.5.2 IFR 1 AIX, x86 Linux, Solaris Multilingual
CI3YBML IBM Sametime Community Server V8.5.2 IFR 1 IBM i Multilingual
Installing 137
CI3YGML IBM Sametime Connect Client V8.5.2 IFR 1 Windows, x86 Linux, Mac Multilingual
CI3YCML IBM Sametime Proxy Server V8.5.2 IFR 1 Windows, AIX, x86 Linux, Solaris, IBM i Multilingual
CZYE6ML IBM Sametime Standard Proxy Server V8.5.2 Windows Multilingual
CZYE7ML IBM Sametime Standard Proxy Server V8.5.2 AIX Multilingual
CZYE8ML IBM Sametime Standard Proxy Server V8.5.2 Linux on x86 Multilingual
CZYE9ML IBM Sametime Standard Proxy Server V8.5.2 Solaris Multilingual
CZYE1ML IBM Sametime Standard Proxy Server V8.5.2 IBM i Multilingual
CI3Y8ML IBM Sametime System Console V8.5.2 IFR 1 Windows, AIX, x86 Linux, Solaris, IBM i Multilingual
CZYF2ML IBM Sametime Standard System Console Server V8.5.2 Windows Multilingual
CZYF3ML IBM Sametime Standard System Console Server V8.5.2 AIX Multilingual
CZYF4ML IBM Sametime Standard System Console Server V8.5.2 Linux on x86 Multilingual
CZYF5ML IBM Sametime Standard System Console Server V8.5.2 Solaris Multilingual
CZYF6ML IBM Sametime Standard System Console Server V8.5.2 IBM i Multilingual
CI3YIEN IBM Sametime V8.5.2 IFR 1 SDK Multiplatform English
CZYF8EN IBM Sametime Standard V8.5.2 SDK Multiplatform English
CZIP9EN IBM Lotus Domino 8.5.2 32 bit for Windows English
CZJ99EN IBM Lotus Domino 8.5.2 for AIX 32 bit English
CZIQ2EN IBM Lotus Domino 8.5.2 32 bit Linux for xSeries English
CZIQ4EN IBM Lotus Domino 8.5.2 32 bit Solaris English
CZIQ5EN IBM Lotus Domino 8.5.2 for IBM i English
CZIF0EN IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista 3
CZIF7EN IBM Lotus Notes Client 8.5.2 Basic Configuration for Windows English
CZM9UFI IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Finnish
CZM9VDE IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista German
CZM9WKO IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista Korean
CZM9XNO IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Norwegian
CZM9YSC IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista Simplified Chinese
CZM9ZES IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Spanish
CZMA0SV IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Swedish
CZMA1FR IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista French
CZMA2TC IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista Traditional Chinese
CZMA3JA IBM Lotus Notes, Domino Designer and Admin 8.5.2 for Windows XP and Vista Japanese
CZMA4IT IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Italian
CZMA5DA IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Danish
CZMA6BP IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Brazilian Portuguese
CZMA7NL IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP and Vista Dutch
CZQ1BCS IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Czech
CZQ1CHU IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Hungarian
CZQ1DRU IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Russian
CZQ1EEL IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Greek
CZQ1FTR IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Turkish
CZQ1GAR IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Arabic
CZQ1HPT IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Portuguese
CZQ1IPL IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Polish
CZQ1KSI IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Slovenian
CZQ1LSK IBM Lotus Notes and Domino Designer 8.5.2 for Windows XP, Vista and Windows 7 Slovakian
CI3YHML IBM WebSphere 7.0.0.15 iFixes for IBM Sametime 8.5.2 IFR 1 Windows, AIX, x86 Linux, Solaris, IBM i Multilingual
CZ1HLML IBM DB2 for Linux, UNIX and Windows 9.7 - Limited Use for Windows on AMD64 and Intel EM64T systems (x64)
CZ1HKML IBM DB2 for Linux, UNIX and Windows 9.7 - Limited Use for Windows on 32-bit AMD and Intel systems (x64)
CZ1HPEN IBM DB2 9.7 Limited Use for Solaris on UltraSPARC systems English
CZ1HMEN IBM DB2 9.7 Limited Use for AIX
English
CZ1HSEN IBM DB2 9.7 Limited Use for Linux
on AMD64 and Intel
EM64T systems (x64) English

CZ1HREN IBM DB2 9.7 Limited Use for Linux
on 32-bit AMD and Intel systems (x86) English

CZYG1ML IBM DB2 9.7 Limited Use for Sametime Standard V8.5.2 Windows 32bit Multilingual
CZYG6ML IBM DB2 9.7 Limited Use for Sametime Standard V8.5.2 x86 Linux 32bit and 64bit Multilingual
CZYA0ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 Windows Multilingual
CZYA1ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 AIX Multilingual
CZYA4ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 Solaris SPARC Multilingual
CZYA2ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 Linux Multilingual
CZYA3ML WebSphere ND V7.0.0.15 Customized Installation Package for Sametime V8.5.2 IBM i Multilingual
Getting Web Content Manager software
Required software
Table 82. List of eAssembly images for IBM Web Content Manager Setup V8.0
CI7VIML IBM Web Content Manager Setup V8.0 (1 of 2) Multiplatform Multilingual
CI7VJML IBM Web Content Manager Setup V8.0 (2 of 2) Multiplatform Multilingual
Installing 139
Optional software

Installing 141
Getting Web Content Manager Standard Edition software
Required software
Table 90. List of eAssembly images for IBM Web Content Manager Standard Edition Setup V8.0
CI7VKML IBM Web Content Manager Standard Edition Setup V8.0 (1 of 2) Multiplatform Multilingual
CI7VLML IBM Web Content Manager Standard Edition Setup V8.0 (2 of 2) Multiplatform Multilingual
Optional software

Installing 143
Installing on AIX
Select the type of setup you need from the list of options. Follow the scenario to install and configure
WebSphere Portal.
Setting up a stand-alone production server on AIX
Set up a stand-alone production environment when you do not need a robust clustered environment. A
stand-alone server deployment is also useful to determine and validate the needs of your deployment.
You can examine and test the functions and features to decide how to accomplish business goals.
Installing 145
The following illustrations depict the stand-alone server configuration that results from following the
instructions in this scenario.
After completing the installation, remember to tune the servers in your portal environment in order to
achieve better performance. The Base Portal Tuning scenarios in the IBM WebSphere Portal and IBM Web
Content Manager Performance Tuning Guide provides information about tuning the IBM WebSphere
Application Server, WebSphere Portal services, databases, directory servers and more.
Preparing your AIX operating system in a stand-alone environment
View information on setting up your operating system for IBM WebSphere Portal. Other components
might require additional steps; see the product documentation for the specific components you want to
install for information.
Complete the following steps to prepare your AIX server:
1. Set the file descriptor limit to 10240; for example, ulimit -n 10240.
2. If you are using IBM GPFS file sharing, set the file system inodes limit to 25000 or higher. For
example, run the mmchfs /dev/gpfs1nsd -F 250000 command. /dev/gpfs1nsd is the IBM WebSphere
Portal installation file system.
3. Web Content Manager only: Use the ulimit -f command to set the maximum size of files that can
be created to be at least the size of the largest file you would need to upload to the content server.
The command ulimit -f unlimited removes any limit on file size.
4. Install and configure X server on AIX (for example X-Windows or GNOME) to use the graphical user
interface the installation program provides.
Note: X server is not required if installing with a response file.
5. Complete the following steps to use the Work Load Partition (WPAR) software installed with your
AIX operating system software:
a. Read and follow the guidelines in this technote to install in a WPAR.
b. Set up the host system with enough disk space.
c. Request new IP address and host name on the same subnet as the host system.
d. After getting the new IP address and host name, run the following command to create a new
WPAR with a non-shared file system (meaning /usr and /opt are private to this new WPAR):
mkwpar -r -l -n newhostname
e. Verify that the mkwpar task completed successfully.
f. Use the host system smitty to configure network interfaces with the new information.
g. Connect and log in to the system using the telnet or ssh command as you would for any physical
or vm images.
h. Verify that the /usr and /opt directories are writable.
The WPAR instance is now ready to install IBM Installation Manager and WebSphere Portal.
Related tasks:
http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/topic/
com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_aixsetup.html
Installing WebSphere Portal on AIX
IBM WebSphere Portal is installed as a single component, complete with an integrated database for
storing information. This allows you to get WebSphere Portal up and running quickly for a proof of
concept phase where you can immediately begin building and working with it. You can also expand your
environment to include high availability failover, a more robust database, and LDAP-based
authentication.
Review the WebSphere Portal detailed system requirements for your operating system and ensure that all
hardware and software matches the minimum product level before installing WebSphere Portal. Review
Installation methods, options, and sourcesInstallation and deployment options.
Choose one of the following installation methods to install IBM WebSphere Portal:
Related concepts:
Data collection and symptom analysis on page 4074
There are two methods for collecting data and analyzing symptoms for problem determination scenarios.
The first method is IBM Support Assistant Lite for WebSphere Portal, which provides automatic data
collection and symptom analysis support for problem determination scenarios. This tool collects and
analyzes information pertinent to a problem scenario to help identify the origin of the problem being
encountered. The second method is running a task that can collect and optionally send the data for you.
Related tasks:
Stand-alone: Installing with the Installation Manager on AIX:
You can use the IBM Installation Manager to help you install IBM WebSphere Portal and IBM WebSphere
Application Server in a stand-alone environment. The IBM Installation Manager gathers essential
information, such as host name and node, and then performs the installation.
The installation program verifies the operating system and its prerequisites, available disk space, and any
required software prerequisites before installation. You cannot install two instances of the server at the
same time, even if you are installing to different directories. You must install each server completely
before installing the next one. The bit architecture of the installation program uses one of the following
options:
v The bit architecture of the operating system
Installing 147
v The bit architecture of the existing WebSphere Application Server
For example, if you are installing onto a 64-bit operating system, WebSphere Portal installs as a 64-bit
version. You can force a 32-bit application installation onto a 64-bit operating system.
Complete the following steps to use the IBM Installation Manager for installation:
1. Type ping yourserver.yourcompany.com on a command line to verify that your fully qualified host
name is properly configured.
2. Type ping localhost on a command line to verify that your network is properly configured.
3. If you are installing on a server with a firewall, antivirus, screen saver, and/or desktop search engine
enabled, disable them before installing. If you do not disable them and the installation program
detects them, a warning message displays during the installation.
4. Choose the appropriate installation task to install or upgrade the IBM Installation Manager:
v Run the ./install task to install the IBM Installation Manager from the IBM Installation Manager
media.
v Run the ./setup.sh task from the Portal Setup disk if you want to start the launchpad to complete
all necessary installation steps.
Tip: Add the LaunchPadLocale language_code to the setup task to change the display to your user
locale or to another language. See the following table for the supported language codes:
WebSphere Portal language codes:
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
pt_BR = Brazilian Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
zh = Simplified Chinese
zh_TW = Traditional Chinese
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
Note: After completing all necessary steps from the launchpad, verify that your installation was
successful.
v If you have an existing IBM Installation Manager, open the IBM Installation Manager and navigate
to File > Updates to search for updates to the latest supported version.
5. After installing or upgrading the IBM Installation Manager, complete the following steps to add the
repositories where the installation media exists:
a. Open the IBM Installation Manager and navigate to File > Preferences > Repositories.
b. Select Add Repositories.
c. Select Browse and navigate to the IBM WebSphere Application Server service repository and then
click OK.
d. Ensure that all required repositories are checked. Then click Test Connections to ensure that the
IBM Installation Manager can successfully access the directory where the service repositories are
stored.
e. Select Apply.
f. Select OK.
6. On the main IBM Installation Manager panel, select Install to begin the installation process.
Attention: On the Install Packages: Select the features to install panel, keep the default selection
checked to create a new Portal server profile.
a. On the Install Packages: Select packages to install panel, select both the WebSphere Application
Server and WebSphere Portal packages.
b. Click Next.
c. On the Install Packages: Select the fixes to install panel, select the following fixes based on how
you are accessing the repository:
When you install WebSphere Application Server and WebSphere Portal together from the live
repository (Passport Advantage)
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WASProd-IFPM60134
v 8.0.0.3-WS-WAS-IFPM61934
When you install WebSphere Application Server and WebSphere Portal together from the local
repository (DVD or downloaded eImage from the web-site)
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WASProd-TFPM60134
v 8.0.0.3-WS-WAS-TFPM61934
d. Accept the license agreement and then click Next.
e. Select the directory where you want to store shared resources and then click Next.
f. Complete the following steps on the Install Packages: Installation Directory panel:
The installation directory that you specify must NOT contain any files or the following characters:
~
Installing 149
!
@
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
1) Select the WebSphere Application Server Package Group Name and then select the installation
directory path.
2) Select the WebSphere Portal Package Group Name and then select the installation directory
path.
3) Click Next.
g. Select the translations to install and then click Next.
h. On the Install Packages: Select the features to install panel, expand the WebSphere Application
Server and WebSphere Portal packages to modify the features you want to install and then click
Next.
32-bit installation on a 64-bit operating system: To force a 32-bit installation on your 64-bit
operating system, expand the IBM WebSphere Application Server Network Deployment feature.
Then expand IBM Software Development Kit. Under IBM Software Development Kit, select
32-bit SDK for Java.
Note: As you select the items, read the Details section for information about the selections.
i. On the Install Packages: Configuration panel, select the type of profile template to install: Full,
Base, or Custom.
j. Click Profile configuration details.
k. On the Profile configuration details panel, select either the Standard or Advanced configuration
mode and then enter the parameter details for the selected configuration mode.
Tip: Select Advanced if you want to specify Uniform Resource Identifier (URI) information that is
appropriate for your company.
l. Click Next.
m. Confirm the information on the Summary panel and then click Install.
Complete the following steps after a successful installation:
1. After a successful installation, the summary panel displays. Choose the Portal First Steps radio button
and then click Finish to start the servers and begin configuring WebSphere Portal.
Tip: To access the First Steps panels later, you can either select First Steps from the Start menu or
you can run the firststeps.bat task from the wp_profile_root/PortalServer/firststeps directory. Add
the LaunchPadLocale language_code to the firststeps task to change the display to your user locale
or to another language.
2. If you changed the context root on the Configuration for IBM WebSphere Portal: Profile configuration
details: Advanced panel during installation, complete the steps in the Changing the portal URI on
page 2197.
Stand-alone: Installing with the response file on AIX:
First install IBM Installation Manager. Then use a response file to install IBM WebSphere Portal and IBM
WebSphere Application Server in a stand-alone environment. Record a response file on the same
operating system you plan for the installation. If you have multiple operating systems, you must record a
response file for each operating system.
options:
There are sample response files, located in the setup_root/responsefiles directory. Manually update
these files based on your environment. Also replace the following lines in the sample response files if you
installed WebSphere Application Server and WebSphere Portal from the live repository (Passport
Advantage):
Existing lines in the response file
v <offering id=8.0.0.3-WS-WAS-TFPM59935 version=8.0.3.20120309_1201 profile=IBM
WebSphere Application Server Network Deployment V8.0 features=-/>
v <offering id=8.0.0.3-WS-WASProd-TFPM60134 version=8.0.3.20120312_1656 profile=IBM
Replace with
Installing 151
v <offering id=8.0.0.3-WS-WAS-IFPM59935 version=8.0.3.20120424_1630 profile=IBM
v <offering id=8.0.0.3-WS-WASProd-IFPM60134 version=8.0.3.20120425_1032 profile=IBM
Complete the following steps to use a response file for installation:
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
5. Complete the following steps to record a response file based on your environment:
Attention: This step does not install WebSphere Portal. You are only recording the response file that
you will use to install WebSphere Portal later.
a. Run the following task from the InstallationManager_root/eclipse directory to create the
response file:
./IBMIM -record pathtoresponsexmlfile -skipInstall tempinstalldirectory
-record
This parameter indicates recording the actions and parameters into the response file.
pathtoresponsexmlfile is the name of the response file, for example Wp8SampleResp.xml.
tempinstalldirectory is the directory where the response file is recorded.
-skipInstall
This parameter indicates no actual installation is performed even though it leads to the
final panel.
tempinstalldirectory
This value is a directory where the installation saves the history and data when recording
response files.
b. Navigate through the IBM Installation Manager panels and set the values for your environment.
Tip: Before adding the repositories, make sure they are located in a directory that is accessible to
all required computers.
c. On the Install Packages: Select packages to install panel, select both the WebSphere Application
d. Click Next.
e. On the Install Packages: Select the fixes to install panel, select the following fixes based on how
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
Installing 153
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
f. Accept the license agreement and then click Next.
g. Select the directory where you want to store shared resources and then click Next.
h. Complete the following steps on the Install Packages: Installation Directory panel:
directory path.
path.
3) Click Next.
i. Select the translations to install and then click Next.
j. On the Install Packages: Select the features to install panel, expand the WebSphere Application
Next.
Attention: On the Install Packages: Select the features to install panel, expand the WebSphere
Portal package and deselect the Create a new Portal Server Profile feature. A full WebSphere
Portal server is not currently required. You create the custom profile later.
k. Confirm the information on the Summary panel and then click Install.
l. After the Installation Manager finishes creating the response file, click Finish and then close the
Installation Manager to complete the response file recording.
m. If installing on a different computer, copy the response file to the response file directory on that
computer.
6. If the repository URL requires authentication, use the IBM Installation Manager command-line tool to
create a keyring file store.
The keyring file stores the credentials required for the repositories. The IBM Installation Manager
command-line tool imutilsc is available from the installation tools directory. The following is an
example of the imutilsc keyring file command:
./imutilsc saveCredential -url repository_URL -userName credential_userName
-userPassword password -keyring keyring_file [ -password keyringfile_password ]
[ -proxyHost proxy_host -proxyPort proxy_port
[ -proxyUsername proxy_username -proxyUserPassword proxyuser_password ]
[ -useSocks ] ]
[ -verbose ]
Note: If installing on a different computer, copy the keyring file to that computer.
7. From your installation tools directory, run the ./imcl -acceptLicense input pathtoresponse.xml
-log pathtologfiles task to install WebSphere Portal and IBM WebSphere Application Server.
Tip: Add the -keyring pathtokeyring -password keyringfile_password parameters to the imcl
command if you are using a keyring file to store credentials.
8. Verify that your installation was successful; access WebSphere Portal using the http://
yourserver:yourport/wps/portal format.
Stand-alone: Performing post-installation tasks on AIX
Depending on your business needs, there are additional tasks that you can run post-installation to
configure your stand-alone environment.
Complete the following post-installation tasks that are required for your business needs:
1. Optional: After the WebSphere Portal installation completes successfully, run the ./ConfigEngine.sh
configure-express -DPortalAdminPwd=password -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, if you want to enable the sample IBM Web Content Manager
content, such as internet and intranet sample sites.
Restriction: Run the configure-express task before configuring your database, user registry, context
root, security, etc. If you ran any tasks other than the install task, do not run this task.
Note: See Exploring the sample site templates for tutorials on how to use the sample content; a link
to the file is provided at the end of this document.
The sample content includes:
v Creates a group called contentAuthors; members of this group are given privileges to create content
in the sample Internet and intranet sites. Navigate to the Administration area and then click Access
> Users and Groups.
v Creates two new Web Content Manager Libraries: "Internet Web Content 8.0.0" and "Intranet Web
Content 8.0.0". Navigate to the Administration area and then click Portal Content > Web Content
Libraries.
v Adds a portlet filter and applies the filter to various portlets in the sample Internet and intranet
sites. You can see the definition of the filter in the WebSphere Integrated Solutions Console and
examining the custom resources under the Environment area.
v Creates two new theme policies: InternetStyle and IntranetStyle. These styles are applied to sample
Internet and intranet sites. Navigate to Theme Customizer and then select the style.
v Creates several portlet clones of the Web Content Manager rendering portlet. These portlet clones
are used on sample Internet and intranet sites.
v Creates two virtual portals with context roots of wps/portal/intranet and wps/portal/internet.
These are the sample Internet and intranet sites. Go to http://yourserver:yourport/wps/portal/
internet and http://yourserver:yourport/wps/portal/intranet to access them.
v Creates several sample credential slots, including "Default slot for Email", "Default slot for Feeds",
"Default slot for Miscellaneous", "Default slot for Web Clipping", and "Default slot for Web Content
Management". Navigate to the Administration area and then click Access > Credential Vault >
Manage System Vault Slots.
2. Optional: If you ran the configure-express task, the owner of the items in the Web content libraries
containing the Internet and Intranet Site Template content will be listed as
uid=wpsadmin,o=defaultWIMFileBasedRealm. To update the owner information for these items to
correspond to your portal administrator ID, complete the following steps:
a. Edit the wp_profile_root/PortalServer/wcm/shared/app/config/wcmservices/
MemberFixerModule.properties file.
b. Add the following lines to the file:
uid=wpsadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN
cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN
Where portal_admin_DN is the distinguished name of the portal administrator and
content_authors_group_DN is the distinguished name of the content authors group used during
LDAP configuration.
c. Save your changes and close the file.
d. Run the ./ConfigEngine.sh express-memberfixer -DPortalAdminPwd=password
-DWasPassword=password task, located in the wp_profile_root/ConfigEngine directory.
Installing 155
Related tasks:
Preparing your AIX operating system in a stand-alone environment on page 146
AIX stand-alone: Configuring Portal to use a database
Before transferring default data to the production database server, you need to prepare the database
server. Database preparation includes creating user IDs and databases. For this installation path,
stand-alone production server, remote databases servers are used.
Select the database server that are using.
Related tasks:
Installing WebSphere Portal on AIX on page 147
authentication.
AIX stand-alone: Setting up a DB2 database:
View information on installing and setting up DB2 or DB2 PureScale that works with WebSphere Portal.
All DB2 instructions apply to DB2 pureScale except where specifically noted.
The instructions in this section apply to a Type 4 configuration except where noted. If you are using the
JDBC driver in Type 2 mode, you need to perform additional steps. For topics that require additional
instructions, see the Type 2 configuration section for the Type 2 version of the instructions.
AIX stand-alone: Installing DB2:
View information on installing DB2 or DB2 pureScale for use with IBM WebSphere Portal.
Before you begin:
v Make sure the operating system is set up with updated kernel parameters according to the
recommendations in the DB2 Quick Beginnings guide at DB2 Technical Support.
v When you install DB2 using the DB2 installation program, it automatically creates a DB2
administrative user with the correct operating system rights.
v Ensure that you have enough disk space for the DB2 instance home directory to be able to create the
required databases.
v A DB2 instance supports a limited number (NUMDB) of concurrently active databases. If the DB2
instance that maintains the databases for WebSphere Portal is used by other applications accessing
databases on the same DB2 instance, it maybe necessary to increase the NUMDB parameter from the
default value to a higher value. Examples of concurrent usage of a DB2 instance include two portals
accessing the same DB2 instance or transferring data from multiple portals using the same DB2
instance. The value for NUMDB depends on how many databases are concurrently used on the DB2
instance which also maintains the databases for WebSphere Portal. For example, to change the default
number (NUMDB) to 30, enter the following command at the database prompt: UPDATE DATABASE
MANAGER CONFIGURATION USING NUMDB 30. You will receive a message that confirms a successful
completion of the update.
Note:
v All DB2 instructions apply to DB2 pureScale except where specifically noted.
v If you are using the JDBC driver in Type 2 mode, you need to perform additional steps. See the Type 2
configuration section for more instructions.
1. To install DB2 or the DB2 client and the required fix pack, follow the instructions that are provided
with the DB2 documentation.
2. If DB2 is installed on another system than WebSphere Portal, copy the driver jar files from the DB2
server to the Portal server. The typical location for these files on the DB2 server is in the
db2_home/java directory. It is recommended that you place these driver files within the wp_profile_root
directory; for example:
wp_profile_root/PortalServer/dbdrivers/db2jcc4.jar
wp_profile_root/PortalServer/dbdrivers/db2jcc_license_cu.jar
3. Open the services file on the DB2 system. Ensure that the DB2 instance port was added to the services
file during the DB2 installation.
v Use a text editor to open the file /etc/services.
v Ensure that DB2_db2inst1 50000/tcp, where db2inst1 is the DB2 instance name, is in the services
file. If you do not see DB2_db2inst1 50000/tcp in the services file, add this entry to the services file.
Note: Ensure that the port number used is not in use. If your port number is already in use, select
a different port number.
Related tasks:
DB2 Quick Beginnings guide
AIX stand-alone: Creating groups and assigning users:
Before transferring the databases to DB2, you must first create the users and groups you have specified in
wkplc_dbdomain.properties and assign the users to their corresponding group. The user and group
names must comply with both the database management system software requirements and WebSphere
Portal requirements.
1. Create a user for dbdomain.DbUser. If you have provided a value in the wkplc_dbdomain.properties
file indicating that a runtime user should be used to connect to the database at runtime, create a user
for dbdomain.DbRuntimeUser. When creating these users, use the same user ids and passwords
entered in the wkplc_dbdomain.properties file.
2. Create a group for dbdomain.DbConfigRoleName. If you have provided a value in the
wkplc_dbdomain.properties file for dbdomain.DbRuntimeRoleName, create a group for
dbdomain.DbRuntimeRoleName.
3. Assign the created user for dbdomain.DbUser to the created group for dbdomain.DbConfigRoleName.
4. If dbdomain.DbRuntimeUser is specified, assign the created user for dbdomain.DbRuntimeUser to the
created group for dbdomain.DbRuntimeRoleName.
AIX stand-alone: Modifying DB2 database properties:
You must modify the appropriate properties files before transferring your data from the default database
to the DB2 database.
Working with properties files:
v Multiple databases can be used to hold information for applications such as Feedback and LikeMinds.
For example, you could use the following property values:
release.DbName=reldb
jcr.DbName=jcrdb
feedback.DbName=fdbkdb
Installing 157
likeminds.DbName=lmdb
community.DbName=commdb
customization.DbName=custdb
v If you are using a remote database, enter the values for the remote server.
v Regardless of the operating system, use a forward slash (/) instead of a backslash (\) in the property
files for file system paths.
v There might be additional database properties other than those listed here. Only change the properties
within this task and skip all other properties.
v Property files provide default values. These values are not correct for all databases. Enter values in
accordance with the database management system that you are using.
v Some values, shown here in italics, might need to be modified to your specific environment.
v The recommended value listed for each property represents the specific information that is required to
configure WebSphere Portal to your target database.
v Depending on which database domain has to be configured, replace dbdomain with:
release
customization
community
jcr
feedback
likeminds
v The values for at least one of the following properties must be unique for the release, customization,
community, and JCR domains:
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
If you use the same values for all three properties across the release, customization, community, and
JCR domains, the database-transfer task fails due to ambiguous database object names.
v If DbUser, DbUrl, and DbPassword are not the same across domains, the value for DataSourceName
must differ from the DataSourceName of the other domains. In other words, this value must be unique
for the database domain.
If you are using the JDBC driver in Type 2 mode, you need to perform additional steps. See the Type 2
1. Locate the following files and create a back up copy of each before changing any values:
v wp_profile_root/ConfigEngine/properties/wkplc.properties
v wp_profile_root/ConfigEngine/properties/wkplc_dbdomain.properties
v wp_profile_root/ConfigEngine/properties/wkplc_dbtype.properties
v If you are transferring from a database other than Derby: wp_profile_root/ConfigEngine/properties/
wkplc_sourceDb.properties
Default values are listed in these files. Unless otherwise noted, all values are of type alphanumeric
text string. Print out this topic for reference before modifying the properties files. Make sure to enter
the appropriate values for each instance of each property. In wkplc_dbdomain.properties, most
properties are repeated for each domain.
2. Use a text editor to open the properties file wkplc_dbdomain.properties and modify the values to
correspond to your environment.
a. For dbdomain.DbType, type db2.
b. For dbdomain.DbName, type the name of the WebSphere Portal domain database. DB2 database
names cannot exceed eight (8) characters.
Notes:
v This value is also the database element in the dbdomain.DbUrl property.
v This value is the TCP-IP alias for the database.
c. For dbdomain.DbSchema, type the schema name of the database domain.
Note: Review your target database management system documentation to define a valid schema
name. Some database management systems have schema name restrictions that you need to
understand.
d. For dbdomain.DataSourceName, type the name of the data source that WebSphere Portal uses to
communicate with its databases. Do not use the following reserved words:
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
e. For dbdomain.DbUrl, type the database URL used to access the WebSphere Portal database with
JDBC. The value must conform to the JDBC URL syntax specified by the database.
Note: The database element of this value should match the value of DbName.
f. For dbdomain.DbUser, type the user ID for the database configuration user.
g. For dbdomain.DbPassword, type the password for the database configuration user.
h. For dbdomain.DbConfigRoleName, type the name of the group for database configuration users.
Database rights are granted to this group instead of individuals. The user specified for
dbdomain.DbUser must be assigned to this group.
i. Optional: For dbdomain.DbRuntimeUser, type the user ID of the database user that should be used
by WebSphere Portal to connect to the database at runtime. If no value is specified for this setting,
the database configuration user will be used to connect to the databases at runtime.
j. If dbdomain.DbRuntimeUser is specified, you must set dbdomain.DbRuntimePassword to be the
password of the runtime database user.
k. For dbdomain.DbRuntimeRoleName, type the name of the group for database runtime users.
dbdomain.DbRuntimeUser must be assigned to this group.
l. Optional: For dbdomain.DBA.DbUser, type the database administrator user ID for privileged access
operations during database creation and setup. This property is required if you run the
create-database and setup-database ConfigEngine tasks referenced later in this section. If you do
not need this parameter, you can either accept the default value or leave blank.
m. Optional: For dbdomain.DBA.DbPassword, type the database administrator password for
privileged access operations during database creation. If you do not need this parameter, you can
either accept the default value or leave blank.
n. For dbdomain.DbNode, type the value for the database node name. Set this value if you want to
call create-database.
Note: Required only for local databases.
3. Save and close the file.
4. Update the following properties in the file wkplc_dbtype.properties.
a. For db2.DbDriver, type the name of the JDBC driver class.
b. For db2.DbLibrary, type the directory and name of the .zip or .jar file that contains the JDBC
driver class.
Installing 159
c. For db2.JdbcProviderName, type the name of the JDBC provider that WebSphere Portal uses to
communicate with its databases.
6. Update the WasPassword value in the wkplc.properties file. This value is the password for the
WebSphere Application Server security authentication used in your environment.
Related tasks:
AIX stand-alone: Installing DB2 on page 156
AIX stand-alone: Creating DB2 databases:
You can create the DB2 databases that are required by IBM WebSphere Portal locally or remotely. When
you create DB2 databases locally, you can create these databases using a configuration task or you can
create these databases manually. When you create the DB2 databases remotely, you can only create the
databases manually.
Related tasks:
AIX stand-alone: Creating groups and assigning users on page 157
AIX stand-alone: Creating a local DB2 database automatically:
This section provides information on using ConfigEngine tasks to create databases when using a local
DB2 installation. If you are using a remote DB2 installation, you must create your databases manually
and cannot create databases using the ConfigEngine task.
Before you begin, ensure that the following prerequisites are met:
v The database management system software is installed.
Note: The create-database task cannot be run by a non-root user.
1. Change to the directory wp_profile_root/ConfigEngine
2. To create the databases, type the following command:
./ConfigEngine.sh create-database -DWasPassword=password
3. Check the services file on the DB2 server system. If it does not specify DB2 connection and interrupt
service ports, specify the ports for your operating system.
a. Use a text editor to open the file /etc/services.
b. Add the text db2c_db2 50000/tcp, where db2 is the default instance.
Note: Ensure the port number used is not already in use. If 50000 is already is use, select a
different port number.
AIX stand-alone: Creating a remote or local DB2 database manually:
A remote database resides on a different system than WebSphere Portal. When you use a remote DB2
server, you must manually create the databases that are required by WebSphere Portal.
Before creating these databases, note the following information:
v If you are using DB2 JDBC Type 4 driver, note the following items:
Only the instructions on the remote server are required. You do not need to install the DB2 client
software, and you do not need to complete the steps related to the DB2 client.
You must copy the Type 4 jar files from the remote DB2 server to the WebSphere Portal server. The
typical location is db2_home/java directory. Record the location of the Type 4 jar files on your local
machine for reference.
These instructions assume that a remote DB2 server is already installed and running.
v If you are using Type 2 drivers, note the following items:
The DB2 client software must be correctly configured to connect to the remote DB2 server instance,
for example, db2inst1.
These instructions assume that a remote DB2 server and DB2 client are already installed and
running.
To create a database, you must be a DB2 System Administrator with sufficient database privileges
(SYSADM or at a minimum SYSCTRL).
Note: All DB2 instructions in this topic apply to DB2 PureScale except where specifically noted.
1. Log in as a DB2 instance system authority. For example, you can log in as db2inst1 as the DB2
instance owner.
2. Initialize a DB2 command environment by opening a command prompt and executing the db2profile
of the DB2 instance. For example, execute . /home/db2inst1/sqllib/db2profile, where db2inst1 is the
DB2 instance owner of your DB2 instance.
The prompt changes to your operating system shell prompt, for example: $. In this mode, you must
type db2 at the beginning of each command and use double quotation marks ("") around the entire
command. The following example shows how to use the double quotes; it is not an actual command
that you run:
db2 "CREATE REGULAR TABLESPACE SMS PAGESIZE 4 K MANAGED BY SYSTEM USING (sms) BUFFERPOOL SMSPOOL"
Note: If you are using the Command Line Processor (CLP), refer to your DB2 documentation for
details. The command prompt is db2=>. In this mode, commands can be entered without the db2 prefix
or the double quotation marks. However, the following steps assume you are not using the CLP and
are entering commands from your operating system shell prompt, for example: $.
3. Run the following commands on the DB2 server system to configure the DB2 database instance:
Environment Commands
DB2 db2set DB2COMM=TCPIP
db2set DB2_EVALUNCOMMITTED=YES
db2set DB2_INLIST_TO_NLJN=YES
db2 "UPDATE DBM CFG USING query_heap_sz 32768"
db2 "UPDATE DBM CFG USING sheapthres 0"
4. (Important) Failure to complete this step will result in an unsuccessful database transfer. Run the
following commands on the DB2 server system to create the necessary databases:
Notes:
v Replace dbname with the actual name of the database. Run the commands and each time replace
dbname with the actual values for release, community, customization, Java Content Repository,
Feedback, and Likeminds. You will need to run the commands once for each database for a total of
six times.
Remember: DB2 database names cannot exceed eight characters. Therefore, consider using these
database names: release, commun, custom, jcrdb, fdbkdb, and lmdb.
Installing 161
db2 "CREATE DB dbname using codeset UTF-8 territory us PAGESIZE 8192"
db2 "UPDATE DB CFG FOR dbname USING applheapsz 4096"
db2 "UPDATE DB CFG FOR dbname USING app_ctl_heap_sz 1024"
db2 "UPDATE DB CFG FOR dbname USING stmtheap 32768"
db2 "UPDATE DB CFG FOR dbname USING dbheap 2400"
db2 "UPDATE DB CFG FOR dbname USING locklist 1000"
db2 "UPDATE DB CFG FOR dbname USING logfilsiz 4000"
db2 "UPDATE DB CFG FOR dbname USING logprimary 12"
db2 "UPDATE DB CFG FOR dbname USING logsecond 20"
db2 "UPDATE DB CFG FOR dbname USING logbufsz 32"
db2 "UPDATE DB CFG FOR dbname USING avg_appls 5"
db2 "UPDATE DB CFG FOR dbname USING locktimeout 30"
db2 "UPDATE DB CFG FOR dbname using AUTO_MAINT off"
5. On the DB2 server system, run the following commands to create bufferpools and table spaces for the
IBM Java Content Repository database (jcrdb). This step is only required for the IBM Java Content
Repository database.
v jcrdb is the name of the database used to store user data and objects
v jcr is the jcr user for jcrdb
Note: This value can be replaced with any ID that has administrative authority.
v dbpassword is the password for the jcr user for the jcrdb
Note: The commands in this step are different for DB2 and DB2 pureScale. Run the appropriate
commands for your environment.
DB2
db2 "CONNECT TO jcrdb USER jcr USING dbpassword"
db2 "CREATE BUFFERPOOL ICMLSFREQBP4 SIZE 1000 PAGESIZE 4 K"
db2 "CREATE BUFFERPOOL ICMLSVOLATILEBP4 SIZE 16000 PAGESIZE 4 K"
db2 "CREATE BUFFERPOOL ICMLSMAINBP32 SIZE 16000 PAGESIZE 32 K"
db2 "CREATE BUFFERPOOL CMBMAIN4 SIZE 1000 PAGESIZE 4 K"
db2 "CREATE REGULAR TABLESPACE ICMLFQ32 PAGESIZE 32 K MANAGED BY SYSTEM USING (ICMLFQ32) BUFFERPOOL ICMLSMAINBP32"
db2 "CREATE REGULAR TABLESPACE ICMLNF32 PAGESIZE 32 K MANAGED BY SYSTEM USING (ICMLNF32) BUFFERPOOL ICMLSMAINBP32"
db2 "CREATE REGULAR TABLESPACE ICMVFQ04 PAGESIZE 4 K MANAGED BY SYSTEM USING (ICMVFQ04) BUFFERPOOL ICMLSVOLATILEBP4"
db2 "CREATE REGULAR TABLESPACE ICMSFQ04 PAGESIZE 4 K MANAGED BY SYSTEM USING (ICMSFQ04) BUFFERPOOL ICMLSFREQBP4"
db2 "CREATE REGULAR TABLESPACE CMBINV04 PAGESIZE 4 K MANAGED BY SYSTEM USING (CMBINV04) BUFFERPOOL CMBMAIN4"
db2 "CREATE SYSTEM TEMPORARY TABLESPACE ICMLSSYSTSPACE32 PAGESIZE 32 K MANAGED BY SYSTEM USING (icmlssystspace32) BUFFERPOOL ICMLSMAINBP32"
db2 "CREATE SYSTEM TEMPORARY TABLESPACE ICMLSSYSTSPACE4 PAGESIZE 4 K MANAGED BY SYSTEM USING (icmlssystspace4) BUFFERPOOL ICMLSVOLATILEBP4"
db2 "CREATE USER TEMPORARY TABLESPACE ICMLSUSRTSPACE4 PAGESIZE 4 K MANAGED BY SYSTEM USING (icmlsusrtspace4) BUFFERPOOL ICMLSVOLATILEBP4"
db2 "UPDATE DB CFG FOR jcrdb USING DFT_QUERYOPT 2"
db2 "UPDATE DB CFG FOR jcrdb USING PCKCACHESZ 16384"
db2 "DISCONNECT jcrdb"
db2 "TERMINATE"
DB2 pureScale
db2 "CREATE SYSTEM TEMPORARY TABLESPACE ICMLSSYSTSPACE32 PAGESIZE 32 K BUFFERPOOL ICMLSMAINBP32"
db2 "CREATE SYSTEM TEMPORARY TABLESPACE ICMLSSYSTSPACE4 PAGESIZE 4 K BUFFERPOOL ICMLSVOLATILEBP4"
db2 "CREATE USER TEMPORARY TABLESPACE ICMLSUSRTSPACE4 PAGESIZE 4 K BUFFERPOOL ICMLSVOLATILEBP4"
db2 "TERMINATE"
6. If you are using the JDBC driver in Type 2 mode, you need to perform additional steps. See the Type
2 configuration section for more instructions.
AIX stand-alone: Setting up DB2 automatically or manually:
After you have created the DB2 databases, you can set up your databases automatically using a
configuration task or manually. The setup path that you choose after your DB2 database is created is
independent of whether you created your DB2 databases locally or remotely. As an alternative to
automatically setting up the database, you can manually grant privileges and create Java Content
Repository table spaces. There are also optional configuration tasks that are not provided to you by
running the ConfigEngine task.
Related tasks:
AIX stand-alone: Modifying DB2 database properties on page 157
AIX stand-alone: Running a task to automatically setup DB2 databases:
This topic provides instructions on automatically setting up your database using the ConfigEngine task.
As an alternative to automatically setting up the database, you can manually grant privileges and create
Java Content Repository table spaces.
You must create your DB2 databases before running the configuration task in this topic.
2. To create the database users, type the following command:
Note: The task setup-database assigns the minimum database privileges to the database
configuration and runtime database users.
./ConfigEngine.sh setup-database -DWasPassword=password
Note: This task will automatically create the necessary users, permissions, and table spaces.
AIX stand-alone: Setting up DB2 manually:
As an alternative to automatically setting up the database, you can manually configure the DB2 database.
If you have configured your database automatically by running the ConfigEngine task, you do not need
to run manual tasks for granting privileges or creating table spaces, but you may decide to perform
additional manual configuration for items that are not provided to you when you automatically when
you run the ConfigEngine task. For example, assigning custom table spaces is an optional task that is not
covered by the automated ConfigEngine task.
AIX stand-alone: Creating DB2 database schemas:
To create database schemas, you can create a copy of the template SQL scripts and edit this copy to
manually create the database schemas. The template SQL scripts should be used as a guide for creating
executable scripts and contain invalid SQL syntax.
Before you begin: You should have completed Installing DB2.
For all databases, use one user with administrative rights on the operating system and the DB2
installation. This user can be the database administrative user that is created automatically by the DB2
installation program. This user is the database configuration user that will be used for configuration
tasks: creating database tables and performing database transfer. If you choose to have WebSphere Portal
also create the databases, the database user should be given SYSADM rights. You only need to manually
create an administrator ID when you do not want to use an existing DB2 administrator ID.
A common user name is db2inst1, but you can assign any user name as long as it has administrative
access and follows the limitations listed here. Do not change the user name after creating it.
Installing 163
The user and group names must comply with both the database management system software
requirements and WebSphere Portal requirements. The limitations on user names are:
v User names can contain one to eight characters.
v Group and instance names can contain one to eight characters.
v Names cannot be any of the following:
users
admins
guests
public
local
v Names cannot begin with:
IBM
SQL
SYS
v Names cannot include accented characters.
v Create users in an environment that has the same settings as the actual runtime environment. For
example, avoid creating a user in an English environment if you plan to use that user in a Turkish
environment.
Refer to the following locations to refer to the SQL script templates:
Table 97. List of SQL script templates by database domain
Database domain Location of template
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/
createSchema.sql
Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/
createSchema.sql
Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/
createSchema.sql
JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/
createSchema.sql
Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/
createSchema.sql
Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/
createSchema.sql
AIX stand-alone: Granting privileges to DB2 database users:
Configuration and runtime database users are granted a different set of privileges, depending on whether
these users are schema owners or not. You can create a copy of the SQL scripts and edit this copy to
manually grant permissions to configuration and runtime database users.
Required privileges of the configuration database user
When a configuration database user is a schema owner, the domain.DbUser property is assigned the same
value as the domain.DbSchema property, and a role is created for a configuration user in each database
domain. This role is created and assigned automatically when you run the setup-database configuration
task. As an alternative to creating and assigning this role automatically, you can create a copy of the SQL
scripts templates located in the installation directory of IBM WebSphere Portal to use as a guide for
creating executable scripts for manually granting permissions. These read-only templates should not be
modified and contain invalid SQL syntax. To grant privileges manually, you must create your own
version of these files to create runnable scripts.
Refer to the following locations of the SQL script templates to learn more about the specific permissions
granted to the schema-owning configuration database user:
Table 98. Location of SQL script templates by database domain for information about specific permissions granted to
schema-owning configuration database users
createConfigRoleForSameSchema.sql
PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/
grantRoleToConfigUser.sql
PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/
PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/
PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/
PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/
PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/
Refer to the following locations of the SQL script templates for non-schema-owning configuration
database user:
Table 99. Location of SQL script templates by database domain for non-schema-owning configuration database users
createConfigRoleForDifferentSchema.sql
Installing 165
Table 99. Location of SQL script templates by database domain for non-schema-owning configuration database
users (continued)
Required privileges for the runtime database user
When the runtime database user is a schema owner, the domain.DbUser property is assigned the same
value as the properties domain.DbRuntimeUser and domain.DbSchema. The runtime database user typically
does not create tables used to query and manipulate data and does not by default have access to these
tables. To grant minimum privileges to a runtime database user to work with these tables, access needs to
be provided for the objects individually. A role is created for runtime database users in each database
domain. These roles are created and assigned automatically when you run the setup-database
configuration task before database transfer and later run the grant-runtime-db-user-privileges
configuration task after database transfer. Before you run these configuration tasks, the runtime database
user can only access the database to validate configurations. As an alternative to creating and assigning
this role automatically, you can create a copy of the SQL scripts templates located in the installation
directory of IBM WebSphere Portal to use as a guide for creating executable scripts for manually granting
permissions. These read-only templates should not be modified and contain invalid SQL syntax. To grant
privileges manually, you must create your own version of these files to create runnable scripts.
granted to the schema-owning runtime database user:
Table 100. Location of SQL script templates by database domain for information about specific permissions granted
to schema-owning runtime database users
createInitialRuntimeRole.sql
createRuntimeRoleForSameSchema.sql
grantRoleToRuntimeUser.sql
to schema-owning runtime database users (continued)
PortalServer_root/jcr/wp.content.repository.install/config/templates/setupdb/db2/
jcr/grantPermissionsToRuntimeRoleStatic.sql
granted to the non-schema-owning runtime database user:
Installing 167
to non-schema-owning runtime database users
createRuntimeRoleForDifferentSchema.sql
Related concepts:
Database users on page 67
AIX stand-alone: Assigning custom DB2 table spaces:
The repository of WebSphere Portal consists of many tables and indices that are created in default table
spaces. When using an existing set of table spaces for the objects of the repository, specify this when
executing the database transfer to the target database system.
Before you begin:
v The custom table spaces must exist prior to the execution of database transfer.
v To see which table spaces can be customized in each domain, refer to the wp_profile_root/PortalServer/
config/tablespaces/dbdomain.space_mapping.properties file.
v The page size of table spaces used by WebSphere Portal must be 8192 bytes.
v For details on creating table spaces refer to the documentation for the database.
If custom table spaces are assigned, each must be assigned explicitly. The default table spaces can be used
to contain database objects; however the name of the default table space must be specified in the
corresponding mapping files. This applies to all database domains that are transferred in a single
database transfer.
To configure custom table space assignments:
1. Determine the names of your custom table spaces.
2. Open the mapping file wp_profile_root /PortalServer/config/tablespaces/
dbdomain.space_mapping.properties that specifies the table space and index space property pairs for
each database table:
dbdomain.table_name.tablespace
dbdomain.table_name.index_name.indexspace
For the file name and each table space and index space property pair, dbdomain can be any one of the
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Note: For jcr, you need to open an additional maping file: wp_profile_root/PortalServer/jcr/config/
jcr.space_mapping.properties. This mapping file contains additional table space and index space
property pairs for each jcr.table_name.tablespace database table.
3. Assign a table space to each entry in the mapping file. The table space name must be prepended by
the keyword IN and a space. For example: community.COMP_INST.tablespace=IN COMM8KSPACE
Repeat this step for each domain that you are transferring.
4. Save and close dbdomain.space_mapping.properties.
5. From a command prompt, specify the option -DuseCustomTablespaceMapping=true when starting the
database transfer. For example,
Windows: ConfigEngine.bat database-transfer -DuseCustomTablespaceMapping=true
UNIX: ./ConfigEngine.sh database-transfer -DuseCustomTablespaceMapping=true
Installing 169
IBM i: ConfigEngine.sh database-transfer -DuseCustomTablespaceMapping=true
z/OS: ./ConfigEngine.sh database-transfer -DuseCustomTablespaceMapping=true
AIX stand-alone: Configuring JCR collation support:
View the steps to set up JCR collation to work with your DB2 database. JCR collation is recommended
when the language locales of your users do not natively collate correctly in the DB2 database and when
language locale correct ordering is important.
1. Stop the WebSphere Portal server. See Starting and stopping servers, deployment managers, and node agents
for instructions.
2. Copy the following files from the WebSphere Portal server to a temporary directory on the DB2
server:
PortalServer/jcr/wp.content.repository.install/lib/wp.content.repository.install.jar
wp_profile/PortalServer/jcr/config/registerCollationUDFTemplate.sql
3. Set up collation on the database where the JCR domain is located.
a. Change to the directory db2_instance_owner_home/sqllib/function.
b. Run the command:
db2home/sqllib/java/jdk/bin/jar -xvf temporary location/wp.content.repository.install.jar
icm/CollationUDF.class
c. Change to the temporary directory where you copied the files in a previous step.
d. Open the file registerCollationUDFTemplate.sql and change all SCHEMA references to the JCR
schema; for example, JCR.
The value set for SCHEMA should match the value set for the jcr.DbSchema property. You specify
jcr.DbSchema in the configuration file wkplc_dbdomain.properties when you modify database
properties. See Modifying database properties for more information.
e. Run the following command to connect to the JCR database: db2 connect to jcrdb user user_ID
using password.
f. Run the script with the following command:
db2 -tvf temporary location/registerCollationUDFTemplate.sql
g. Disconnect from the JCR database.
h. Restart the DB2 instance.
4. Verify that the UDF is registered properly.
a. Log in as the db2instanceID.
1) Open a DB2 terminal window.
2) Run the following command: db2 connect to JCRDB user user_ID using password. You must
connect to the JCR database as a database runtime user with the user ID and password for the
WebSphere Portal JCR data source.
3) Once you have connected to the JCR database you need to register the UDF. To register the
UDF you run the following command: values schema.sortkeyj(abc,en)
5. Edit the icm.properties file, located in wp_profile_root\PortalServer\jcr\lib\com\ibm\icm directory.
Add the following section to the end of the file:
# Enable/Disable collation support for all DB2 platforms
# Disabled by default
jcr.query.collation.db2.enabled = true
# Database specific collation mappings
# These mappings apply map a Java locale name into a collation name
# supported by the underlying database.
# Example mappings for DB2 platform
# English
jcr.query.collation.en = en
# Swedish
jcr.query.collation.sv = sv
jcr.query.collation.zh = zh
jcr.query.collation.de = de
jcr.query.collation.da = da
jcr.query.collation.hu = hu
jcr.query.collation.jp = jp
6. Start the WebSphere Portal server. See Starting and stopping servers, deployment managers, and node
agents for instructions.
Related tasks:
AIX stand-alone: Creating DB2 databases on page 160
databases manually.
AIX stand-alone: Configuring Portal to use DB2:
This section provides information on how to manually transfer data from the default database to the DB2
database. Follow these steps to transfer portal and Java Content Repository databases to DB2. As an
alternative to the manual database transfer procedure described here, you can use the configuration
wizard to complete the database transfer task.
Before you begin:
Ensure that the following prerequisites are met:
v Supported database software is installed.
v Databases and users are set up.
Tips:
v To run these tasks as a non-root user, you must first run the task chown -R non-root_user WebSphereDir.
v If you are transferring from Oracle or Oracle RAC, the open_cursors setting should be set to 1500 by
default. However, you might need to increase this value based on the table count in the Java Content
Repository schema.
1. Perform this step only if you are installing multiple instances of WebSphere Portal. Change the
maximum number of databases MAX_NETBIOS_CONNECTIONS to increase the default configured
number of databases. For example, enter the following command at the database prompt: set client
MAX_NETBIOS_CONNECTIONS 254 A message indicates success if the number was increased.
2. Open a command prompt and change to the directory wp_profile_root/ConfigEngine.
3. Enter the ./ConfigEngine.sh validate-database -DWasPassword=password command to validate
configuration properties.
Installing 171
Tip: Add the -DTransferDomainList parameter to the validating task to specify the domains you
want to validate; for example: -DTransferDomainList=jcr. If you want to validate all domains, you
do not need to specify this parameter on the command line.
4. From the same command prompt as the previous steps, change to the directory wp_profile_root/bin.
5. Stop the WebSphere_Portal server:
v ./stopServer.sh WebSphere_Portal -username admin_userid -password admin_password
6. Transfer the database:
Note: Important: Do not execute the database-transfer task as a background process. This might
cause the task to stall.
a. Change to the directory wp_profile_root/ConfigEngine.
b. Enter the following command: ./ConfigEngine.sh database-transfer -DWasPassword=password
Note:
v To select specific database domains to transfer, modify the -DTransferDomainList specified in
the command to include only the domains that you want to transfer. For example, to transfer
only the JCR domain you can enter the following command: ./ConfigEngine.sh
database-transfer -DTransferDomainList=jcr -DWasPassword=password
v If you have been storing data in Apache Derby for a long time, database transfer could fail
with OutOfMemory exceptions. If database transfer fails, add the following property to the
command in this step: ConfigEngine.bat database-transfer -DDbtJavaMaxMemory=1536M
-DWasPassword=password
c. After running the task, a message is added to the following log file for you to verify the task ran
successfully: wp_profile_root/ConfigEngine/log/ConfigTrace.log If the configuration fails, verify
the values in the wkplc.properties, wkplc_dbdomain.properties, and wkplc_dbtype.properties
files and then repeat this step.
7. Optional: If you specified a run time database user for the dbdomain.DbRuntimeUser parameter, that
user must have sufficient database user privileges. To grant the database user privileges, choose
either the manual steps or the command line steps:
a. Complete these steps to manually grant database user privileges:
1) Copy the appropriate template files to a work directory. Choose one of the following template
files:
v createRuntimeRoleForDifferentSchema.sql if the name of the database user and the
schema name are not the same.
v createRuntimeRoleForSameSchema.sql if the name of the database user and the schema
name are the same.
Locate these files in the following directories, where dbms is your database management
system, and domain represents the database domains you are configuring. Substitute domain
with release, customization, community, jcr, feedback, and likeminds as appropriate:
PortalServer_root/base/wp.db.impl/config/templates/setupdb/dbms/domain
PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/dbms/domain
JCR database domain: For the JCR database domain, you must also copy
grantPermissionsToRuntimeRoleStatic.sql from the following directory:
PortalServer_root/jcr/wp.content.repository.install/config/templates/setupdb/dbms/
jcr/grantPermissionsToRuntimeRoleStatic.sql .
2) Replace all placeholder values with the values as defined in wkplc_dbdomain.properties.
Placeholder values are surrounded by the character @.
3) Run these statements.
b. Complete these steps to grant database user privileges with the ConfigEngine task:
1) Ensure the database administrator user ID is specified for domain.DBA.DbUser in
wp_profile_root/ConfigEngine/properties/wkplc_dbdomain.properties. For example,
domain.DBA.DbUser=dbadmin.
2) Run the following task: ./ConfigEngine.sh grant-runtime-db-user-privileges
-DTransferDomainList=comma_separated_list_of_domains
Note: You only need to add -DTransferDomainList=comma_separated_list_of_domains to this
task when granting privileges across specific domains.
8. After transferring the database tables, perform a reorg check to improve performance. Perform this
step for each database in the property file.
a. Connect to a database with the following command:
db2 connect to dbName user db2admin_userid
using password
Note: Additional options might be required if additional security has been installed. Refer to
DB2 Universal Database commands by example for links to the command reference.
b. After it is connected, run the following commands from the DB2 prompt:
db2 reorgchk update statistics on table all > xyz.out
c. Look in the reorg column for entries marked with a star or asterisk * in the file xyz.out.
1) For each line with *, note the tablename and run the following command for each tablename:
db2 reorg table tablename
2) After you have run the reorg command for each tablename, run the following commands:
db2 terminate
db2rbind database_name -l db2rbind.out -u db2_admin
-p password
d. The output file db2rbind.out is only created when there is an error for the db2rbind command.
9. Change to the directory wp_profile_root/bin.
If you have additional nodes already configured, you need to compare the following file on all nodes
with the file from the primary node. Ensure all instances of the file are identical: wp_profile_root/
PortalServer/jcr/lib/com/ibm/icm/icm.properties. If the files are not identical, copy icm.properties
from the primary node on which you ran the database-transfer task to the node.
1. Stop the portal server on the secondary node.
2. Copy wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties from the primary node and
replace icm.properties on the secondary node.
3. Start the portal server on the secondary node.
Installing 173
Related tasks:
databases manually.
AIX stand-alone: Setting up DB2 automatically or manually on page 162
AIX stand-alone: Enabling DB2 pureScale load balancing feature:
For multithreaded Java applications, set enableSysplexWLB to true in the connection string to take
advantage of transaction level workload balancing feature for DB2 pureScale. As additional members are
started, clients automatically route to the new member without any interruption of service. Members can
be stopped without the application knowing.
1. Log into the WebSphere Integrated Solutions Console on the deployment manager server by entering
http://your_server:9060/ibm/console/ in a browser.
2. Click Resources > JDBC > Data Sources.
3. Click Data sources > data source name > Custom properties.
4. Search for enableSysplexWLB.
5. Click enableSysplexWLB, and enter true in the Value field.
6. Click OK.
Related tasks:
databases manually.
AIX stand-alone: Configuring DB2 for large file handling in WCM:
If you are using Web Content Manager, you must update the database configuration to support large
files. You can update the fullyMaterializeLobData property by running a configuration task.
Note: You only need to perform these steps if you are using Web Content Manager.
2. Enter the following command:
v AIX: ./ConfigEngine.sh datasource-enable-fully-materialize-lob-data -DWasPassword=password
v Linux: ./ConfigEngine.sh datasource-enable-fully-materialize-lob-data
v Solaris: ./ConfigEngine.sh datasource-enable-fully-materialize-lob-data
v Windows: ConfigEngine.bat datasource-enable-fully-materialize-lob-data
v IBM i: ConfigEngine.sh datasource-enable-fully-materialize-lob-data -DWasPassword=password
Installing 175
Related tasks:
databases manually.
AIX stand-alone: Configuring Portal to use DB2 on page 171
AIX stand-alone: Type 2 driver support:
To use JDBC Type 2 drivers for DB2, you must perform additional configuration steps. If you are
currently using Type 4 drivers, you must follow the instructions in this section to change drivers from
Type 4 to Type 2 drivers.
Related tasks:
databases manually.
AIX stand-alone: Configuring Portal to use DB2 on page 171
AIX stand-alone: Enabling DB2 pureScale load balancing feature on page 174
AIX stand-alone: Changing DB2 driver types:
WebSphere Portal requires the use of either the IBM DB2 Legacy JDBC driver in type 2 mode or the IBM
DB2 Universal JDBC driver in type 4 mode when connecting to DB2.
Before you begin, ensure that the following conditions are met:
v The WebSphere Portal database has been successfully transferred to DB2 using the database-transfer
configuration task.
v The files wkplc_dbdomain.properties and wkplc_dbtype.properties have been modified to set the
correct values for the DB2 drivers that you are switching to:
In the file wkplc_dbdomain.properties set each <Domain>.DbUrl property using the following formats:
# db2 (type 2): { jdbc:db2:wpsdb }
# db2 (type 4): { jdbc:db2://<YourDatabaseServer>:50000/wpsdb:returnAlias=0; }
In the file wkplc_dbtype.properties set the db2.DbLibrary property using the following format:
# For DB2 Type 2 driver use <SQLLIB>/java/db2jcc4.jar
# For DB2 Type 4 driver use <SQLLIB>/java/db2jcc4.jar:<SQLLIB>/java/db2jcc_license_cu.jar
In the file wkplc_dbtype.properties set the db2.DbDriver property using the following format:
# For DB2 Type 2 driver use com.ibm.db2.jcc.DB2Driver
Installing 177
Note:
If WebSphere Portal is installed on the same machine as the DB2 server and you switch from a JDBC
Type 4 connection to a JDBC Type 2 connection, verify that you have created the alias names for the DB2
databases as described in Creating remote databases and that the alias names are specified for the databases
in the file wkplc_dbdomain.properties.
When switching from a JDBC Type 2 connection to a JDBC Type 4 connection, remove the database alias
names and refer to the databases directly. This is required because of a limitation in the DB2 Universal
JDBC driver.
2. Export the DB2 user profile that you created when installing DB2 onto the administrative user using
the following command. This command exports the DB2 user's profile onto the administrative user so
that they can access the DB2 utilities.
. /home/db2inst1/sqllib/db2profile
where db2inst1 represents your database instance
Note: You must complete this step before running database tasks and before enabling security.
Tip: Add the -DTransferDomainList parameter to the validating task to specify the domains you want
to validate; for example: -DTransferDomainList=jcr. If you want to validate all domains, you do not
need to specify this parameter on the command line.
6. Change to the directory wp_profile_root/ConfigEngine.
7. To change from one supported driver to the other, run the following task to connect the database,
including only the domains that require the switch.
./ConfigEngine.sh connect-database -Drelease.DbPassword=password
-Dcustomization.DbPassword=password -Dcommunity.DbPassword=password
-Djcr.DbPassword=password -Dfeedback.DbPassword=password
-Dlikeminds.DbPassword=password
AIX stand-alone: Configuring Type 2 DB2 drivers:
If you are using the JDBC driver in Type 2 mode for DB2, you need to perform additional steps. This
topic contains the instructions for a Type 2 configuration when the instructions differ from the Type 4
instructions. For general prerequisites and notes for each section, see the Type 4 version of topics using
the same titles as the section headers. All topics in the DB2 section that are not in the Type 2 driver
support section, are for a Type 4 configuration.
Installing DB2
2. If DB2 is installed on another system than WebSphere Portal, ensure the appropriate DB2 client is
installed on the same system as WebSphere Portal and have the same name as the server profile
name.
3. Open the services file on the DB2 system. Ensure that the DB2 instance port was added to the
services file during the DB2 installation.
file. If you do not see DB2_db2inst1 50000/tcp in the services file, add this entry to the services
file.
4. Configure your DB2 client with the following commands. If you are using a remote database,
complete this step separately from the WebSphere Portal installation.
v db2 update dbm cfg using tp_mon_name WAS
v db2 update dbm cfg using spm_name hostname, where hostname is the host name of WebSphere
Portal.
Because the default for spm_name is the hostname itself, specifying the hostname parameter is
optional. If your hostname is more than eight characters, use empty double quotes (" "). For example,
db2 update dbm cfg using spm_name " ".
Modifying database properties
v If you are transferring from a database other than Derby: wp_profile_root/ConfigEngine/
properties/wkplc_sourceDb.properties
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
Installing 179
feedback
privileged access operations during database creation. If you do not need this parameter, you
can either accept the default value or leave blank.
n. For dbdomain.XDbName, type the database loop back alias that needs to be set if you plan to use
the create-database task.
o. For dbdomain.DbNode, type the value for the database node name. Set this value if you want to
driver class.
Creating a remote or local DB2 database manually
instance owner.
of the DB2 instance. For example, execute . /home/db2inst1/sqllib/db2profile, where db2inst1 is
the DB2 instance owner of your DB2 instance.
that you run:
details. The command prompt is db2=>. In this mode, commands can be entered without the db2
prefix or the double quotation marks. However, the following steps assume you are not using the
CLP and are entering commands from your operating system shell prompt, for example: $.
Notes:
Feedback, and Likeminds. You will need to run the commands once for each database for a total
of six times.
The following steps are only required for the IBM Java Content Repository database.
16. On the DB2 server system, run the following commands to create bufferpools and table spaces for
the IBM Java Content Repository database (jcrdb).
DB2
Installing 181
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
17. On the DB2 client, use a text editor to open the /etc/services file. If it does not specify the DB2
connection service port, add the following text to specify the port for the remote DB2 instance:
DB2_db2inst1 port1/tcp # DB2 connection service port
where db2inst1 is the name of the DB2 instance on the system, and port1 with the actual port number
that is assigned to the DB2 connection service in your DB2 server installation . The connection
service port on the DB2 Client system, WebSphere Portal server, must match the connection service
port on the DB2 server. The ports should match by number but not necessarily by name.
18. Set up the correct service name by entering the following command on the DB2 server system: db2
"UPDATE DBM CFG USING svcename svce_name" where svce_name is the connection service port name
that is specified previously.
19. On the DB2 client, set DB2COMM to TCP/IP by using the db2set command db2set DB2COMM=tcpip.
20. Catalog the TCP/IP node with the IP address of the remote database server on DB2 Connect: db2
"catalog tcpip node remote_db_node_alias remote database_server_node server
connection_service_port" where:
remote_db_node_alias is the alias name of the database server that you are defining for the
WebSphere Application Server node name. The alias name can contain one to eight characters.
database_server_node is the fully qualified host name of your database server system.
connection_service_port is the name of the DB2 connection service port that is configured in the
/etc/services file on the database server system.
21. Catalog the WebSphere Portal databases on DB2 Connect, where:
remote_db_name_domain, is the cataloged name of the databases on the server system for each
domain.
domain_alias_name, is the database alias names that you are defining.
remote_db_node_alias is the name that was used previously when you cataloged the TCP/IP node
in the previous step.
The alias for each database must be different from the actual database name and can only contain up
to eight characters.
db2 "catalog db remote_db_name_release as release_alias_name at node remote_db_node_alias"
db2 "catalog db remote_db_name_community as comm_alias_name at node remote_db_node_alias"
db2 "catalog db remote_db_name_customization as cust_alias_name at node remote_db_node_alias"
db2 "catalog db remote_db_name_fdbkdb as fdbkdb_alias_name at node remote_db_node_alias"
db2 "catalog db remote_db_name_lmdb as lmdb_alias_name at node remote_db_node_alias"
db2 "catalog db remote_db_name_jcrdb as jcrdb_alias_name at node remote_db_node_alias"
22. Log out of DB2 Connect by entering db2 "terminate".
23. On DB2 Connect, test your remote connection by issuing the following command in the DB2
command window: db2 "connect to alias_name user username using password", where alias_name
is the alias name that you defined previously, username is the database user, and password is the
password assigned to the database user.
Configuring a portal to use your database
24. Edit the db2cli.ini file that resides on the local system, where WebSphere Portal is installed, before
you transfer data.
Important: The database transfer becomes unresponsive at task action-process-constraints if you
do not complete these steps.
a. Locate the file /home/db2inst1/sqllib/cfg/db2cli.ini.
b. Add the following lines to the end of the file:
Editing db2cli.ini:
If a section named [COMMON] already exists in the file, extend that section by adding the
following lines. Otherwise, add a [COMMON] section to the file.
Leave an empty line after ReturnAliases=0.
[COMMON]
DYNAMIC=1
ReturnAliases=0
Note:
Installing 183
files:
name are the same.
using password
db2 terminate
-p password
AIX stand-alone: Preparing IBM DB2 for i:
To setup a remote IBM DB2 for i database, create user IDs and databases on a remote server. Tasks are
provided to assist with creating the user IDs and the databases. Before you can use the tasks, you must
modify properties files.
AIX stand-alone: Modifying properties for IBM DB2 for i:
Learn how to modify the wkplc.properties, wkplc_dbdomain.properties, and wkplc_dbtype.properties
files to work with your database. Modify these property files before running tasks to create databases,
create users, or transfer data.
v The WebSphere Portal database can be used to hold information for applications such as
Personalization (Feedback) and LikeMinds. To prepare the database to hold such application
information, you should use similar naming conventions for property values such as release.DbName.
Here are some examples:
release.DbName=hostname/WP80REL
community.DbName=hostname/WP80COM
customization.DbName=hostname/WP80CUS
jcr.DbName=hostname/WP80JCR
feedback.DbName=hostname/WP80FBK
likeminds.DbName=hostname/WP80LKM
v Property files provide default values that may not be correct for the database that you are using. Enter
values in accordance with the database management system that you are using.
v Password considerations: For security reasons, you should not store passwords in the
wkplc.properties, wkplc_dbdomain.properties, and wkplc_dbtype.properties files. It is recommended
that you edit each of the properties files prior to running a configuration task, inserting the passwords
needed for that task. Then, after the task has run, you should delete all passwords from each file.
Installing 185
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
v When you create a schema, you must use the following schema naming conventions on the IBM i
system:
Note: The default schema names may be used with the product.
Length cannot exceed 10 characters
All alphanumerical characters are allowed ( "A" through "Z" and "1" through "0")
The following characters are invalid:
- spaces
- null values
- asterisk (*)
- quotation marks (")
- colon (:)
- greater than symbol (>)
- less than symbol (<)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
- single quotation mark (')
- question mark (?)
Notes:
- Make sure you know what valid schema names are and do not use a schema name which already
exists on the local or remote system. Follow the documentation of the target database
management system in order to define a valid schema name as restrictions apply. Note that the
Create WebSphere Portal wizard will automatically check schema names for you.
- For more information on database and schema naming conventions, refer to the DB2 Universal
Database for System i5 content in the System i5 information center.
2. Use a text editor to open the properties files and enter the values that are appropriate for your
environment. You can also modify each properties file locally on your System i5 system by typing the
following on an OS/400 command line in a 5250 session:
Note: This step only applies when WebSphere Portal is installed on IBM i, and you are transferring to
IBM DB2 for i.
EDTF wp_profile_root/ConfigEngine/properties/property filename.properties
where property filename is wkplc_dbdomain, wkplc, or wkplc_dbtype.
Note: You must have a user profile on the IBM i server and must have at least *USE special authority
to edit the properties file.
Tip: The steps for transferring data to another supported database section provide instructions for
manually transferring data. Instead of performing the following steps, you can use the configuration
wizard, which is a graphical user interface, to transfer data to another supported database.
Properties must be changed before creating a database name and schema on a local or remote IBM i
server.
a. For dbdomain.DbType, type db2_iseries.
b. For dbdomain.DbName, type the name of the WebSphere Portal domain database.
Note: This value is also the database element in the dbdomain.DbUrl property.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC. The value must conform to the JDBC URL syntax specified by the database. The connection
property metadata source=1 must be specified for databases running on systems older than IBM i
V7R1. Refer to the following example when WebSphere Portal is installed on IBM i and you
transferring data remotely or locally to IBM DB2 for i:
dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1" Refer to the
following example when WebSphere Portal is installed on Windows and you transferring data
remotely to IBM DB2 for i: dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata
source=1" Refer to the following example when WebSphere Portal is installed on a UNIX platform,
Installing 187
and you are transferring data to IBM DB2 for i: dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/
WPDBREL;metadata source=1;prompt=false" If the X11 DISPLAY is set and active, do not add the
;prompt=false to the URL.
Note: You must download the jt400.jar file prior to database transfer. Refer to
wkplc_dbtype.properties for more information on downloading the jt400.jar file.
a. For db2_iseries.DbDriver, type the name of the JDBC driver class.
b. For db2_iseries.DbLibrary, type the directory and name of the .zip or .jar file that contains the
JDBC driver class.
c. For db2_iseries.JdbcProviderName, type the name of the JDBC provider that WebSphere Portal
uses to communicate with its databases.
d. For db2_iseries.DbDriverType, type the number representing the driver type for the database.
AIX stand-alone: Creating groups and assigning users for IBM DB2 for i:
Before transferring the databases to IBM DB2 Universal Database for i, you must first create the users and
groups you have specified in wkplc_dbdomain.properties and assign the users to their corresponding
group. The user and group names must comply with both the database management system software
requirements and WebSphere Portal requirements.
Note: You do not need to create a group for dbdomain.DbConfigRoleName for IBM DB2 for i.
2. If you have provided a value in the wkplc_dbdomain.properties file for
dbdomain.DbRuntimeRoleName, create a group for dbdomain.DbRuntimeRoleName.
Note:
v The length of group names that you create cannot exceed 10 characters to ensure successful
database transfer.
v Group names must exist before running the create-database configuration task.
v Database rights are granted to the group instead of individuals.
Note: You must set dbdomain.DbRuntimeUser to be the password of the runtime database user.
AIX stand-alone: Creating user profiles for IBM DB2 for i:
View information on setting up user profiles for IBM DB2 for i to work with WebSphere Portal.
Before you begin:
v The user profile for the database owner should be different from the administrator user profile used to
perform the installation. The administrator user profile may have more authority than is required and
usually belongs to an individual, where as the database user profile may have minimal authority and
can be shared.
v Create a database user profile that does not require a password change over a period of time. If the
password for the database user profile changes, WebSphere Portal must be re-configured to use the
new password.
environment.
To create user profiles, follow the instructions that are provided with the IBM DB2 for i documentation.
Related tasks:
AIX stand-alone: Modifying properties for IBM DB2 for i on page 185
AIX stand-alone server: Creating and setting up IBM DB2 for i databases automatically:
This section provides information on using a ConfigEngine task to create and setup IBM DB2 for i
databases and users.
The following steps are the same for root and non-root users, except that the create-database task cannot
be run by a non-root user.
Installing 189
Related tasks:
AIX stand-alone: Creating groups and assigning users for IBM DB2 for i on page 188
AIX stand-alone: Granting privileges to IBM DB2 for i database users:
domain. This role is created and assigned automatically when you run the following configuration task:
create-database
To learn more about the specific permissions granted to the configuration database user, navigate to the
SQL script templates in the installation directory of IBM WebSphere Portal. These read-only templates
should not be modified. To grant these privileges, you can create a copy of the SQL scripts and use this
copy to grant permissions manually.
to schema-owning configuration database users
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2_iseries/release/
Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2_iseries/community/
Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2_iseries/
customization/createConfigRoleForSameSchema.sql
JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2_iseries/jcr/
Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2_iseries/feedback/
Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2_iseries/likeminds/
database user:
to non-schema-owning configuration database users
customization/createConfigRoleForDifferentSchema.sql
domain. These roles are created and assigned automatically when you run the following configuration
tasks:
create-database
grant-runtime-db-user-privileges
Before you run these configuration tasks, the runtime database user can only access the database to
validate configurations. To learn more about the specific permissions granted to the runtime database
user, navigate to the SQL script templates in the installation directory of WebSphere Portal. These
read-only templates should not be modified. To grant these privileges, you can create a copy of the SQL
scripts and use this copy to grant permissions manually.
to schema-owning configuration runtime database users
customization/createRuntimeRoleForSameSchema.sql
PortalServer_root/jcr/wp.content.repository.install/config/templates/setupdb/
db2_iseries/jcr/grantPermissionsToRuntimeRoleStatic.sql
Installing 191
to schema-owning configuration runtime database users (continued)
Release PortalServer_rootbase/wp.db.impl/config/templates/setupdb/db2_iseries/release/
customization/createRuntimeRoleForDifferentSchema.sql
Related concepts:
Related tasks:
AIX stand-alone: Creating user profiles for IBM DB2 for i on page 189
AIX stand-alone: Configuring the portal to use IBM DB2 for i:
View the steps to manually transfer data to the IBM DB2 Universal Database for i database you have set
up. As an alternative to the manual database transfer procedure described here, you can use the
configuration wizard to complete the database transfer task. However, you cannot specify all settings
through the configuration wizard. For example, regardless of the method used to transfer data, you must
run a configuration task to create JMS resources as described in this topic.
Before you begin:
v stopServer WebSphere_Portal -username admin_userid -password admin_password
2. Validate configuration properties using the ConfigEngine.sh validate-database
-DWasPassword=password command.
Note: Important: Do not execute the database-transfer task as a background process. This might cause
the task to stall.
a. Enter the following command: ConfigEngine.sh database-transfer -DWasPassword=password
Note:
only the JCR domain you can enter the following command: ConfigEngine.sh database-transfer
-DTransferDomainList=jcr -DWasPassword=password
v This note only applies when transferring databases from IBM DB2 for i to another server with
IBM DB2 for i. If you are transferring databases from a database other than IBM DB2 for i, you
can skip this note. Use SBMJOB to submit the Qshell script as a batch job to run in *BASE pool
when *INTERACT pool does not have 1GB or more of allocated memory. For example: SBMJOB
CMD(STRQSH CMD(ConfigEngine.sh database-transfer -DWasPassword=password))
b. After running the task, a message is added to the following log file for you to verify the task ran
Installing 193
Related tasks:
AIX stand-alone server: Creating and setting up IBM DB2 for i databases automatically on page 189
AIX stand-alone: Verifying the IBM DB2 for i configuration:
After WebSphere Portal is configured to work with your database, test the database connection to ensure
that it operates correctly.
You can verify the connection from a browser or from a command line.
To verify that WebSphere Portal is running from a browser, open the portal in a Web browser:
http://hostname.yourco.com:port_number/wps/portal, where hostname.yourco.com is the fully qualified
host name of the machine where WebSphere Portal is running and port_number is the transport port that
is created by IBM WebSphere Application Server.
There may be an error if any of the following conditions appear.
v When trying to access the portal you get a 503 error.
v If you had any locale problems with your database, you could see invalid characters, such as ????, after
logging in. This may happen if the character set of the database is not UTF-8 compliant.
v If something went wrong with the data that was transferred, you may not be able to login. WebSphere
Portal will indicate you entered an invalid user ID and password even though you know it is valid.
Verify the connection from a command line by completing the following steps:
1. Open a command line on the local machine whereWebSphere Portal is installed.
2. For WebSphere Portal on WebSphere Application Server (UserData path), enter the following on the
command line: cd wp_profile_root/ConfigEngine.
ConfigEngine.sh validate-database-connection
-DTransferDomainList=release,community,customization,jcr,feedback,likeminds
For security reasons, you should not leave passwords in the wkplc_dbdomain.properties file. Edit the file
prior to running a configuration task and insert the passwords that are needed for that task. After the
task has run, delete all passwords from the file.
Alternatively, you can specify the password on the command line rather than update the
wkplc_dbdomain.properties file. For example: ConfigEngine.sh -DPortalAdminPwd=password
-DWasPassword=password validate-database
When installing WebSphere Portal, the passwords in the wkplc_dbdomain.properties file are
automatically removed after configuration.
Related tasks:
AIX stand-alone server: Creating and setting up IBM DB2 for i databases automatically on page 189
AIX stand-alone: Granting privileges to IBM DB2 for i database users on page 190
AIX stand-alone: Preparing DB2 for z/OS:
Setting up the DB2 for z/OS database includes creating user IDs, databases, and table spaces on a remote
server.
AIX stand-alone: Installing DB2 for z/OS:
View information on how to install DB2 for z/OS for use with IBM WebSphere Portal.
The following prerequisites must exist separately from the WebSphere Portal installation:
v If you are using the DB2 Legacy Type 2 JDBC driver, configure your DB2 Connect client with the
following commands:
db2 update dbm cfg using tp_mon_name WAS
db2 update dbm cfg using spm_name hostname, where hostname is the host name for the machine
where the DB2 Connect client is installed (same as portal machine).
v If you are using the DB2 Legacy Type 2 JDBC driver, enable extended shared memory usage with the
following commands:
export EXTSHM=ON
db2set DB2ENVLIST=EXTSHM
db2start
To make the change permanent, you must add the environment variable by adding the following to the
profile.env file:
DB2ENVLIST=EXTSHM
in /home/db2inst/sqllib/userprofile add:
export EXTSHM=ON
Note: The shell must be reopened before restarting DB2 for z/OS.
Installing 195
v Both type 2 and type 4 drivers are supported. If you are using the DB2 Legacy Type 2 JDBC driver, the
DB2 Connect client must be installed on the same machine as WebSphere Portal to connect to the
remote database.
v The DB2 subsystem must be on a supported z/OS platform.
v Update the BP8K0 catalog bufferpool to 35,000 buffers before performing database transfer. You should
change this value based on your environment. The SYSIBM.SYSDATABASE table resides in this
bufferpool and is used extensively by DB2 for z/OS during database transfer.
To use DB2 for z/OS as the database software for WebSphere Portal, you must have DB2 for z/OS
installed on your z/OS system. Refer to the DB2 for z/OS product documentation for instructions. Refer
to the Planning for DB2 for z/OS topic for additional considerations for configuring DB2 for z/OS as the
WebSphere Portal database.
AIX stand-alone: Modifying database properties for DB2 for z/OS:
This section provides information on how to modify the wkplc.properties, wkplc_dbdomain.properties,
and wkplc_dbtype.properties files to work with your database. Modify these property files before
running tasks to create databases, create users, or transfer data.
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Note: To successfully transfer data from the JCR domain, you must use the DDF location value for the
value of jcr.DbName field when setting up IBM DB2 Universal Database for z/OS. You can locate the
name of the DDF location value in the IBM DB2 Universal Database for z/OS sdsnsamp data set,
member DSNTIJUZ, or by running the following DB2 command:
db2 subsystem prefix display ddf
a. For dbdomain.DbType, type db2_zos.
understand.
d. For dbdomain.DbNameOnZos, type the name of the WebSphere Portal database on DB2 for z/OS.
Note:
v If running DB2 for z/OS as a remote database, set the value to the name of the remote database
for the domain.
v If WebSphere Portal is running on z/OS with DB2 for z/OS, set the value equal to the value of
DbName.
e. For dbdomain.DataSourceName, type the name of the data source that WebSphere Portal uses to
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
f. For dbdomain.DbUrl, type the database URL used to access the WebSphere Portal database with
Installing 197
g. For dbdomain.DbUser, type the user ID for the database configuration user.
h. For dbdomain.DbPassword, type the password for the database configuration user.
i. For dbdomain.DbConfigRoleName, type the name of the group for database configuration users.
j. Optional: For dbdomain.DbRuntimeUser, type the user ID of the database user that should be used
k. If dbdomain.DbRuntimeUser is specified, you must set dbdomain.DbRuntimePassword to be the
l. For dbdomain.DbRuntimeRoleName, type the name of the group for database runtime users.
m. For dbdomain.DbTablespace, type the name of the DB2 for z/OS tablespace.
n. For dbdomain.DbStorageGroup, type the name of the storage group for the database.
o. For dbdomain.DbVolumes, type the volumes for the database.
p. For dbdomain.DbVcat, type the VCAT for the database.
q. For dbdomain.Db4KBufferPoolName, type the 4K bufferpool name for the database.
r. For dbdomain.Db32KBufferPoolName, type the 32K bufferpool name for the database.
s. For dbdomain.DbIndex4KBufferPoolName, type the 4K bufferpool name for the database. If you
choose to use the default bufferpool value BP3, verify that this bufferpool is active.
t. For dbdomain.TablespaceTrackMod, set the value to determine TRACKMOD attribute of all
tablespaces to use the specified value. Refer to the DB2 for z/OS documentation before changing
this value.
a. For db2_zos.DbDriver, type the name of the JDBC driver class.
b. For db2_zos.DbLibrary, type the directory and name of the .zip or .jar file that contains the JDBC
driver class.
c. For db2_zos.JdbcProviderName, type the name of the JDBC provider that WebSphere Portal uses
to communicate with its databases.
d. For db2_zos.DbDriverType, type the number of the driver type for the database.
AIX stand-alone: Using JCL templates to set up DB2 for z/OS:
If you plan to use a DB2 for z/OS database, you can use JCL template files to help you customize the
database based on your configuration prior to using your DB2 for z/OS database.
Perform the following steps to use the JCL templates to set up your DB2 for z/OS database:
1. Make a copy of the template files you plan to use; the following templates exist in the
PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2_zos_remote directory:
Table 106. The templates and their descriptions.
Template Description
EJPSRACD This job executes the RACF commands required for the
IBM WebSphere Portal for z/OS database user IDs and
schemas. Review with your RACF administrator and,
where required, modify the job before submitting. For
example, if you have specified database user IDs that are
already defined in your RACF, remove the ADDUSER
commands for them from the job. If you have some other
security product such as Top Secret or ACF2 instead of
RACF, then translate the RACF commands in the job into
the appropriate syntax before submitting.
User ID requirement: RACF special authority.
Run this job on the server where the database will be
created.
EJPSCRDB This job defines and creates the WebSphere Portal for
z/OS database. The job has the following two steps:
1. Delete the existing database. If you have never run
this job before, the attempt will not be successful.
This is expected and can be ignored.
2. Define the database. This step must complete
successfully.
User ID requirement: Connected to DB2 SYSADM
authority.
created. Review the output from this job to verify all
messages and SQL codes are expected/acceptable.
EJPSMCKD This job invokes CHECK DATA for the portal table
spaces that are in status "CHECK PENDING" after
database transfer. It also executes the RUNSTATS utility
on the database
authority.
Run this job on the server where the database exists.
Upon completion, examine job output. Success is
indicated with "rc=4" in the job output.
Note: Review the requirements of the EJPDBQRY
program before attempting to run this job.
EJPDBQRY This program is executed by the EJPSMCKD job. It
performs the DB2 CHECK DATA and RUNSTATS
commands as required. Prior to executing this program
for the first time you must run the DSNTIJRX job that is
created when installing DB2 for z/OS. This job makes
the DB2 REXX function package required by EJPDBQRY
available at runtime.
2. Modify the template copy with the appropriate information for your configuration.
Tip: Customization variables have the format, !!VARIABLE!! where "VARIABLE" is the descriptive
name of what should go in place of the variable name. For example, replace all occurrences of
!!LM_DB_NAME!! with the name of your LikeMinds database.
4. Allocate a data set from your z/OS system to contain the modified JCL jobs. It should have a fixed
block (FB) record format length of 80.
Installing 199
5. Use FTP, or a similar utility, to upload the files and convert them from ASCII to EBCDIC.
6. Run the JCL jobs on your z/OS system.
Related tasks:
AIX stand-alone: Installing DB2 for z/OS on page 195
AIX stand-alone: Creating users for DB2 for z/OS:
Create users for IBM DB2 Universal Database for z/OS to work with IBM WebSphere Portal. The
Customization Dialog generates job EJPSRACD that you use to create users. Review the generated job and
update it as appropriate for your installation requirements. If you use a security product such as Top
Secret or ACF2 instead of RACF, modify the job as appropriate. After you run the job, grant the necessary
access rights to all users who require them. Depending on the architecture that you choose, these users
might include Java Content Repository and Feedback users.
Complete the installation of DB2 for z/OS.
This topic provides instructions on creating a configuration database user. To create a runtime database
user, repeat the steps in this topic.
v If WebSphere Portal Version 8.0 and an earlier version of WebSphere Portal coexist, the database user
IDs for WebSphere Portal Version 8.0 must be different than earlier versions to avoid conflicts during
installation.
v If you are configuring multiple WebSphere Portal instances to use a single DB2 for z/OS subsystem,
you must create a unique database user for each WebSphere Portal instance. By default all database
table names include the name of the database user used to access the data. Therefore, to prevent table
name conflicts, you must create a unique database user for each WebSphere Portal instance on the
shared DB2 for z/OS subsystem.
v Take care to create users in an environment that has the same settings as the actual runtime
environment. For example, avoid creating a user in an English environment if you plan to use that user
in a Turkish environment.
Use the following steps to grant access permissions to the database users. Repeat these steps for each
WebSphere Portal instance you are setting up.
1. Create all database user IDs in the security product you are using on z/OS. For jcrschema, the
database schema name for IBM Java Content Repository data, create a group and connect it to the
database user ID for Java Content Repository data, jcr. The following sample shows the RACF
definition of such a user ID and group, where jcr is the database user ID for Java Content Repository
data, yourDefaultUserGroup is your default RACF group for database user IDs, jcrschema is the
database schema name for Java Content Repository data, and yourDefaultGroup is your default RACF
group for groups. If you have some other security product such as Top Secret or ACF2 instead of
RACF, translate the sample RACF definition into the appropriate syntax before running the job.
ADDUSER jcr DFLTGRP(yourDefaultUserGroup) NAME(WAS DB2 ACCESS USER)
PW USER(jcr) NOINTERVAL
ALU jcr PASSWORD(********) NOEXPIRED
ADDGROUP jcrschema SUPGROUP(yourDefaultGroup)
CONNECT jcr GROUP(jcrschema)
2. Run the following SQL statements using a tool like SPUFI while logged on to the DB2 subsystem to
grant appropriate rights on the newly created databases. If you are configuring multiple WebSphere
Portal instances to use a single DB2 for z/OS subsystem, be sure to use the database user associated
with the WebSphere Portal instance you are setting up.
(C) create/alter tablespaces
(C) create/alter tables
(C) create/alter indice;
(C+R) read/write data
(C) - at configuration time
(R) - at runtime
GRANT USE OF ALL BUFFERPOOLS TO releaseusr;
GRANT USE OF ALL BUFFERPOOLS TO communityusr;
GRANT USE OF ALL BUFFERPOOLS TO customizationusr;
GRANT DBADM ON DATABASE jcrdbnameonzos TO jcr;
GRANT USE OF ALL BUFFERPOOLS TO jcr;
GRANT DBADM ON DATABASE fdbkdbnameonzos TO feedback;
GRANT USE OF ALL BUFFERPOOLS TO feedback;
GRANT DBADM ON DATABASE lmdbnameonzos TO lmdbusr;
GRANT USE OF ALL BUFFERPOOLS TO lmdbusr;
GRANT SELECT ON SYSIBM.SYSCOLUMNS TO releaseusr;
GRANT SELECT ON SYSIBM.SYSCOLUMNS TO communityusr;
GRANT SELECT ON SYSIBM.SYSCOLUMNS TO customizationusr;
GRANT SELECT ON SYSIBM.SYSTABLES TO releaseusr;
GRANT SELECT ON SYSIBM.SYSTABLES TO communityusr;
GRANT SELECT ON SYSIBM.SYSTABLES TO customizationusr;
GRANT SELECT ON SYSIBM.SYSCOLUMNS TO jcr;
GRANT SELECT ON SYSIBM.SYSTABLES TO jcr;
GRANT SELECT ON SYSIBM.SYSCOLUMNS TO fdbkdbusr;
GRANT SELECT ON SYSIBM.SYSTABLES TO fdbkdbusr;
GRANT SELECT ON SYSIBM.SYSCOLUMNS TO lmdbusr;
GRANT SELECT ON SYSIBM.SYSTABLES TO lmdbusr;
GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO releaseusr;
GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO communityusr;
GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO customizationusr;
GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO jcr;
GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO fdbkdbusr;
GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO lmdbusr;
GRANT SELECT ON SYSIBM.SYSRELS TO releaseusr;
GRANT SELECT ON SYSIBM.SYSRELS TO communityusr;
GRANT SELECT ON SYSIBM.SYSRELS TO customizationusr;
GRANT SELECT ON SYSIBM.SYSRELS TO jcr;
GRANT SELECT ON SYSIBM.SYSRELS TO fdbkdbusr;
GRANT SELECT ON SYSIBM.SYSRELS TO lmdbusr;
GRANT USE OF STOGROUP jcrstogroup TO jcr;
GRANT CREATEIN, DROPIN ON SCHEMA jcrschema TO jcr;
GRANT SELECT ON SYSIBM.SYSTABLESPACE TO jcr;
GRANT SELECT ON SYSIBM.SYSVIEWS TO jcr;
GRANT SELECT ON SYSIBM.SYSTRIGGERS TO jcr;
GRANT SELECT ON SYSIBM.SYSINDEXPART TO jcr;
GRANT SELECT ON SYSIBM.SYSINDEXES TO jcr;
GRANT SELECT ON SYSIBM.SYSSYNONYMS TO jcr;
where:
v releasenameonzos, communitynameonzos, customizationnameonzos, and releaseusr, communityusr,
customizationusr represent the databases and database users, respectively, of the WebSphere Portal
instance you are setting up. (These users must be created on the host system.)
v jcrdbnameonzos and jcr are the database and database user, respectively, for Content Repository
data.
v fdbkdbnameonzos and feedback are the database and database user, respectively, for Feedback data.
v lmdbnameonzos and lmdbusr are the database and database user, respectively, for Likeminds data.
v jcrschema is the database schema name for Content Repository data.
3. Grant the necessary access rights to all users who might require them. Depending on the architecture
that you choose, these users might include Java Content Repository and Feedback users.
Installing 201
Related tasks:
AIX stand-alone: Modifying database properties for DB2 for z/OS on page 196
AIX stand-alone: Granting privileges to DB2 for z/OS users:
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2_zos/release/
Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2_zos/community/
Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2_zos/customization/
JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2_zos/jcr/
Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2_zos/feedback/
Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2_zos/likeminds/
database user:
to non-schema-owning configuration database users (continued)
db2_zos/jcr/grantPermissionsToRuntimeRoleStatic.sql
Installing 203
Related concepts:
Related tasks:
AIX stand-alone: Using JCL templates to set up DB2 for z/OS on page 198
AIX stand-alone: Creating remote database for DB2 for z/OS:
A remote database resides on a different machine than WebSphere Portal. You must manually create the
required databases before configuring WebSphere Portal to work with DB2 for z/OS.
Before you begin, complete the following prerequisites:
v These instructions assume that you will use a local IBM DB2 Universal Database Enterprise Server
Edition Connect to connect to a remote IBM DB2 Universal Database for z/OS server, and that IBM
WebSphere Application Server, WebSphere Portal, and DB2 Connect will be installed on the same
machine.
v To run SQL statements, you can use a tool like SPUFI. The specified statements include CREATE
STOGROUP, CREATE DATABASE and CREATE TABLESPACE. For CREATE STOGROUP you have to
replace the icmvolumes and icmvcat variables with volume serial numbers and a catalog name for your
environment. For CREATE TABLESPACE you can specify a specific BUFFERPOOL. Refer to the DB2
for z/OS SQL Reference for a description of these options.
v Ensure that the tablespace ts_name is available in either DSNDB07 or a WORKFILE DATABASE.
Availability depends on whether or not you are using a data-sharing environment.
v Log on to the DB2 subsystem on the host server. DB2 system administrator rights are needed to create
the databases.
v Replace variables as follows:
releasenameonzos, communitynameonzos, and customizationnameonzos are the WebSphere Portal
databases for WebSphere Portal and Member Manager data.
fdbkdbnameonzos and fdbkdbts are the database and table space, respectively, for Feedback data.
lmdbnameonzos and lmdbts are the database and table space, respectively, for LikeMinds data.
v Because large objects are stored in columns that can become very large, logging changes to these
columns requires a huge amount of log space. For this reason, large object (LOB) logging is disabled by
default for tablespaces that contain such data. With LOB logging disabled, you can recover full
backups, but not incremental backups that can be used for point in time recovery. To recover point in
time backups, you must enable LOB logging. For detailed instructions, see Technote 1306637, Managing
LOB logging in DB2 for z/OS.
Use the following steps to set up WebSphere Portal with a remote instance of DB2 for z/OS. Refer to
Planning for DB2 for z/OS for a list of databases and table space names. If you are configuring multiple
WebSphere Portal instances to use a single DB2 subsystem, be sure to use the database and table space
names associated with the WebSphere Portal instance you are setting up.
1. CREATE DATABASE releasenameonzos CCSID UNICODE;
2. CREATE DATABASE communitynameonzos CCSID UNICODE;
3. CREATE DATABASE customizationnameonzos CCSID UNICODE;
4. CREATE DATABASE fdbkdbnameonzos CCSID UNICODE;
5. CREATE TABLESPACE fdbkdbts IN fdbkdbnameonzos USING STOGROUP SYSDEFLT PRIQTY 5000 SECQTY 500
LOCKSIZE ROW DEFINE NO;
6. CREATE DATABASE lmdbnameonzos CCSID UNICODE;
7. CREATE TABLESPACE lmdbts IN lmdbnameonzos USING STOGROUP SYSDEFLT PRIQTY 5000 SECQTY
500 DEFINE NO;
Related tasks:
AIX stand-alone: Creating users for DB2 for z/OS on page 200
AIX stand-alone: Assigning custom tablespaces on DB2 for z/OS:
Installing 205
Before you begin:
v When using IBM DB2 Universal Database for z/OS as a data store, WebSphere Portal requires that its
indexes are not padded. Therefore, you must set the DSNZPARM parameters to RETVLCFK=NO or
PADIX=NO, or both.
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
3. Assign a table space to each .tablespace entry in the mapping file. Assignments to .indexspace
entries are ignored. The table space name must be qualified by the database name and prepended by
Related tasks:
AIX stand-alone: Granting privileges to DB2 for z/OS users on page 202
AIX stand-alone: Configuring Portal to use DB2 for z/OS:
View information on manually transferring data to theDB2 for z/OS you have installed and set up.
Follow these steps to transfer WebSphere Portal, and Java Content Repository to DB2 for z/OS. As an
wizard to complete the database transfer task. However, you cannot specify all settings through the
configuration wizard. For example, regardless of the method used to transfer data, you must run a
configuration task to create JMS resources as described in this topic.
Before you begin:
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 207
Note: To select specific database domains to transfer, modify the -DTransferDomainList specified
in the command to include only the domains that you want to transfer. For example, to transfer
only the JCR domain you can enter the following command: ./ConfigEngine.sh database-transfer
7. If a dedicated run time database user has been specified (domain.DbRuntimeUser), ensure that this
user has sufficient database privileges. Refer to the appropriate template file
(grantRoleToConfigUser.sql or grantRoleToRuntimeUser.sql) containing the required GRANT
statements for each of the db domains.
v Open the createRuntimeRoleForDifferentSchema.sql file when different names are used for the
run time database user name and the schema name. Open the
createRuntimeRoleForSameSchema.sql file when the same name is used for the run time database
user name and the schema name. These files are located in PortalServer_root/base/wp.db.impl/
config/templates/setupdb/db2_zos/domain and PortalServer_root/pzn/prereq.pzn/config/
templates/setupdb/db2_zos/domain directories.
v Replace all placeholders (surrounded by '@' characters) with the values defined in the
v Execute these statements in the createRuntimeRoleForDifferentSchema.sql or
createRuntimeRoleForSameSchema.sql file as appropriate.
8. From the command line processor, reset the check pending status on the WebSphere Portal table
spaces listed here. CHECK DATA is a DB2 batch utility that is invoked through JCL or through the
DB2 utility panels. Type the following utility commands to check pending status:
check data tablespace releasenameonzos.TS320A
check data tablespace communitynameonzos.TS8000B
check data tablespace customizationnameonzos.TS2110C
check data tablespace jcrdbnameonzos.ICMSFQ04
check data tablespace jcrdbnameonzos.TS2110D
where releasenameonzos, communitynameonzos, and customizationnameonzos are the names of your
WebSphere Portal databases, and jcrdbnameonzos is the name of your JCR database. Refer to the
Utility Guide and Reference for DB2 for z/OS for additional details.
9. Run the RUNSTATS utility as shown in the following example:
LISTDEF JCRDBZOS INCLUDE TABLESPACE JCRDBZOS.* BASE
RUNSTATS TABLESPACE LIST JCRDBZOS INDEX(ALL) KEYCARD TABLE(ALL)
LISTDEF JCRDB01 INCLUDE TABLESPACE JCRDB01.* BASE
RUNSTATS TABLESPACE LIST JCRDB01 INDEX(ALL) KEYCARD TABLE(ALL)
...
10. Start the WebSphere Application Server.
11. Verify that the WebSphere Portal application server is running by opening the following URL in a
browser: http://hostname.companyname.com:port_number/wps/portal, where
hostname.companyname.com is the fully qualified host name of the machine where WebSphere Portal is
running and port_number is the transport port that is created by WebSphere Application Server.
Related tasks:
AIX stand-alone: Creating remote database for DB2 for z/OS on page 204
AIX stand-alone: Granting privileges to DB2 for z/OS users on page 202
AIX stand-alone: Setting up Oracle or Oracle RAC database:
View information on installing and setting up Oracle to work with WebSphere Portal.
AIX stand-alone: Installing Oracle or Oracle RAC:
You can use Oracle or Oracle RAC as the database software. You must install Oracle or Oracle RAC
before performing a database transfer.
Installing 209
Before you begin:
Review the Planning for Oracle or Oracle RAC section.
Considerations:
v Install the Oracle client and any required fix packs. Follow the instructions that are provided with the
Oracle documentation.
v Install Oracle JDBC Type 4 drivers or Oracle JDBC OCI Type 2 drivers as appropriate.
Note: To migrate from a previous version of IBM WebSphere Portal using JDBC Type 4 drivers, the
target system must use JDBC Type 4 drivers. Once migration is complete, you can continue using JDBC
Type 4 drivers or change the driver type to JDBC OCI Type 2 drivers as appropriate. Direct migration
from a previous installation of WebSphere Portal using JDBC Type 4 drivers to an installation using
JDBC OCI Type 2 drivers is not supported. See the Oracle documentation for details.
v JDBC OCI Type 2 drivers only: Set the environment variable on the IBM WebSphere Portal server to
point to the directory where you downloaded and extracted the compressed Oracle client files.
LIBPATH=/u01/app/oracle/product/11.2.0/client_1;export LIBPATH
v (Oracle RAC) Ensure the Oracle CRS (Cluster Ready Service) and Oracle RAC databases have been
installed and configured on the primary and secondary nodes.
v (Oracle RAC) Run the following commands on both RAC nodes to start global services daemon (GSD),
oracle listeners, and agents.
$ gsdctl start
$ lsnrctl start
$ agentctl start
Refer to the Oracle or Oracle RAC product documentation for installation instructions.
AIX stand-alone: Modifying Oracle or Oracle RAC database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
When doing a single database, single user, and multi schema database transfer, there can be only one
user for each domain (release, community, customization, JCR, Feedback, and LikeMinds), and the
schema for each database must be different. The user must be a superuser or DBA and must have
authority over all other schemas for the transfer to work.
a. For dbdomain.DbType, type oracle.
understand.
Restriction: The value for dbdomain.DbSchema must equal the value for dbdomain.DbUser unless
you are using a single user to manage all of the database schemas.
Installing 211
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
v The database element of this value should match the value of DbName.
v Oracle JDBC OCI Type 2 drivers: For example, the Oracle database URL should use the
following format: jdbc:oracle:oci:@//YourDatabaseServer:1521/service_name
v Oracle JDBC Type 4 drivers: For example, the Oracle database URL should use the following
format: jdbc:oracle:thin:@YourDatabaseServer:1521:service_name.
v Oracle RAC JDBC OCI Type 2 drivers only: For example, the Oracle RAC database URL should
use the following format: jdbc:oracle:oci:@//NODE_HOSTNAME:1521/NODE_INSTANCENAME
v Oracle RAC JDBC Type 4 drivers only: The WebSphere Portal server must explicitly connect to
one RAC node during database transfer. You need to specify the information of one Oracle RAC
node as if it is the only database server. For example, the Oracle RAC database URL should use
the following format: Oracle RAC URL :
jdbc:oracle:thin:@NODE_HOSTNAME:1521:NODE_INSTANCENAME. Use this format since the database
transfer script does not parse the full Oracle RAC URL due to multiple host names. When
database transfer is completed, the WebSphere Portal server will be configured to use this single
database server. After transferring your data, use the WebSphere Integrated Solutions Console to
access the datasource definition, and update the URL to use the format of a RAC URL.
The value for service_name in the database URL is the same value used for the service name value
in the tnsnames.ora file on your Oracle database.
Restriction: The value for dbdomain.DbUser must equal the value for dbdomain.DbSchema unless
create-database and setup-database ConfigEngine tasks referenced later in this section. The
database administrator must have SYSDBA permissions. If you do not need this parameter, you can
n. For dbdomain.DbHome, type the root location for the database.
Note: This value is used to specify the location to create the tablespaces.
a. For oracle.DbDriver, type the name of the Oracle JDBC driver class.
b. For oracle.DbLibrary, type the directory and name of the .jar file that contains the JDBC driver
class.
c. For oracle.JdbcProviderName, type the name of the JDBC provider that WebSphere Portal uses to
AIX stand-alone: Creating Oracle or Oracle RAC databases:
View some important considerations before setting up Oracle databases to work with WebSphere Portal.
For information about creating databases, refer to the Oracle product documentation. For information on
the recommended database architecture and the databases you will need to create, see the Planning for
Oracle topic. Be sure that all databases to be used with WebSphere Portal are created as UNICODE
character set databases.
If you are using Oracle 10g databases, you must also obtain a copy of the ojdbc6.jar file from the Oracle
JDBC driver download site, copy it to the WebSphere Portal machine, and update the
wkplc_dbtype.properties file with oracle.DbLibrary=(the path to the local ojdbc6.jar). If you are using
Oracle 11g databases, you must also copy the ojdbc6.jar file from the Oracle server to the WebSphere
Portal machine and update the wkplc_dbtype.properties file with oracle.DbLibrary=(the path to the local
ojdbc6.jar). The typical location is the oracle_home/sqldeveloper/jdbc/lib directory. Record the copy
location on your local machine for future reference.
When creating Oracle databases for use with WebSphere Portal, you should consider the following
information:
v The Oracle databases must be created manually before configuring WebSphere Portal.
v All databases must be created using UNICODE Database and National character sets such as UTF8,
AL32UTF8, or AL16UTF16.
v It is recommended that all databases to be used with WebSphere Portal are configured in Dedicated
Server Mode.
v Determine if your Oracle server will be remote or local to the WebSphere Portal installation.
v Ensure the database is registered with the Oracle listener. Use the tnsnames.ora file to describe this
database and recycle the listener.
v After installing the database software for WebSphere Portal, you will need to set the buffer pools
allocated to the Oracle database in order for WebSphere Portal to communicate with the Java Content
Repository database. Use the following recommended values as a guide. Refer to the Oracle product
documentation for information on how to set the buffer pools. Recommended initial buffer pool sizes:
db_block_size = 8192 bytes
db_cache_size = 307,200 bytes
db_files = 1024 files
log_buffer = 65536 bytes
Installing 213
open_cursors = 1500 cursors
pga_aggregate_target = 204,800 bytes
pre_page_sga = true
processes = 300 processes
shared_pool_size = 204,800 bytes
Note: If you are using IBM Java Content Repository, the open_cursors value may need to be increased
based on the table count in the Java Content Repository schema.
v Raise the number of parallel servers as appropriate. For example, if you have more than 875 parallel
servers, you should set the parallel_max_servers to 1200.
v The Oracle parameter CURSOR_SHARING allows similar SQL Statements to be shared when possible,
which prevents parsing and establishing a new execution plan. The execution plan is used by Oracle to
gather the data needed to satisfy a request. There are two options for CURSOR_SHARING, which are
as follows:
FORCE
When you select this option, Oracle uses the same execution plan for all SQLs that are similar
in value even if the values are different. When you use this option, the execution plan may not
provide optimum performance. For example, similar SQLs with different values may behave
differently when executed running the same plan.
EXACT
When you select this option, Oracle only shares the same execution plan for SQLs that are
identical and use the same values. This option removes the risk of a SQL statement being
executed when optimum performance conditions do not exist.
WebSphere Portal supports both options. Regardless of the option selected, portlet applications should
not be affected. Contact your database administrator for further assistance on these options.
AIX stand-alone: Setting up Oracle or Oracle RAC automatically or manually:
You can set up Oracle Enterprise Edition to work with WebSphere Portal automatically or manually.
When setting up Oracle automatically, the database administrator runs a ConfigEngine task to create
users, grant privileges, and create JCR table spaces. As an alternative to automatically setting up the
database, you can manually run scripts to create users, grant privileges, and create JCR table spaces.
Automatic configuration provides a faster path for database administrators for setting up Oracle, but
does not provide in depth knowledge of how the database is configured. Manual configuration allows
database administrators to understand what is going on at each end of the process. If you want the speed
of automatic database setup but you would like to gain a better understanding of what is happening
during the automatic configuration process, you can review the steps in the manual configuration section
and then return to the automatic configuration steps.
Note:
v You must log in as the system administrator to run the ConfigEngine task or to manually set up the
database.
v If you have configured your database automatically by running the ConfigEngine task, you do not
need to run manual tasks for creating users, privileges, or table spaces, but you may decide to refer to
the manual configuration section to perform the optional step of assigning custom table spaces.
Related tasks:
AIX stand-alone: Modifying Oracle or Oracle RAC database properties on page 210
AIX stand-alone: Running a task to automatically setup Oracle or Oracle RAC databases:
As an alternative to automatically setting up the database, you can manually create users and grant
privileges.
1. On the database server, make sure the subfolders your_oracle_instance/data and
your_oracle_instance/index exist. If this folder hierarchy does not exist, create it manually before
you run the setup-database task. The setup-database task requires these folders to create table
spaces. If these folders do not exist, the setup-database task will fail.
Note:
v The setup-database task creates the table spaces, index spaces, and the database users as specified
in the properties files.
v If you are using Oracle Automatic Storage Management, you must set up the databases manually.
AIX stand-alone: Setting up Oracle or Oracle RAC manually:
As an alternative to automatically setting up the database, you can manually configure the Oracle
database to create users and grant privileges. If you have configured your database automatically by
running the ConfigEngine task, you should not manually create users, privileges, or table spaces. You
may decide to perform additional manual configuration for items that are not provided to you when you
automatically when you run the ConfigEngine task. For example, assigning custom table spaces is an
optional task that is not covered by the automated ConfigEngine task. To learn more about automatically
configuring Oracle, refer to the Configuring Oracle automatically section in the information center.
AIX stand-alone: Creating Oracle or Oracle RAC database schemas and users:
To create database schemas and users, you can create a copy of the template SQL scripts and edit this
copy to manually create the database schemas and users. The template SQL scripts should be used as a
guide for creating executable scripts and contain invalid SQL syntax.
Before you begin:
v You should have installed Oracle.
installation.
Ensure that you create users and grant the appropriate privileges in Oracle before configuring WebSphere
Portal to work with Oracle.
Take care to create users in an environment that has the same settings as the actual runtime environment.
For example, avoid creating a user in an English environment if you plan to use that user in a Turkish
environment.
Installing 215
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/oracle/release/
createRuntimeUsers.sql
PortalServer_root/base/wp.db.impl/config/templates/setupdb/oracle/release/
createUsers.sql
Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/oracle/community/
PortalServer_root/base/wp.db.impl/config/templates/setupdb/oracle/community/
createUsers.sql
Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/oracle/customization/
PortalServer_root/base/wp.db.impl/config/templates/setupdb/oracle/customization/
createUsers.sql
JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/oracle/jcr/
PortalServer_root/base/wp.db.impl/config/templates/setupdb/oracle/jcr/
createUsers.sql
Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/oracle/feedback/
PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/oracle/feedback/
createUsers.sql
Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/oracle/likeminds/
PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/oracle/likeminds/
createUsers.sql
AIX stand-alone: Granting privileges to Oracle or Oracle RAC database users:
database user:
Installing 217
oracle/jcr/grantPermissionsToRuntimeRoleStatic.sql
Installing 219
Related concepts:
AIX stand-alone: Creating JCR table spaces:
This topic provides manual instructions for creating JCR table spaces for Oracle.
If you have run the setup-database script, you should not perform the steps in this topic. As an
alternative to creating JCR table spaces, you can run the setup-database script to create the required JCR
table spaces. In addition to creating JCR table spaces, the setup-database script automatically creates users
and grants privileges.
Note: Oracle Automatic Storage Management users should use the following instructions only as a
reference. As you manually create your table spaces, create the exact table space names listed in this topic
with the recommended sizes.
1. In the database directory, create the data directory data and the index directory index.
2. Create tablespaces using the following commands as examples:
Substitute the values of your environment for the following variables:
v &jcrdb. is the name of the database you created to store user data.
v &dbpath. is the directory where you created the database; the default path is /oracle/oradata.
Ensure that the '.' is included in the variables when you substitute the values of your environment
with these variables.
Important: You must use the same table space names listed in the commands. The table space names
cannot be customized or modified.
create tablespace ICMLFQ32 datafile '&dbpath./&jcrdb./data/&jcrdb._ICMLFQ32_01.dbf' size
300M reuse autoextend on next 10M maxsize UNLIMITED extent management local autoallocate;
create tablespace ICMLNF32 datafile '&dbpath./&jcrdb./data/&jcrdb._ICMLNF32_01.dbf' size 25M
reuse autoextend on next 10M maxsize UNLIMITED extent management local autoallocate;
create tablespace ICMVFQ04 datafile '&dbpath./&jcrdb./data/&jcrdb._ICMVFQ04_01.dbf' size 25M
create tablespace ICMSFQ04 datafile '&dbpath./&jcrdb./data/&jcrdb._ICMSFQ04_01.dbf' size
create tablespace ICMLSNDX datafile '&dbpath./&jcrdb./index/&jcrdb._ICMLSNDX_01.dbf' size
a. Set the size, autoextend, and maxsize values according to your environment. For example, you
may want to change the maxsize to a set value rather than UNLIMITED.
b. Consult your Database Administrator for specific guidance about creating tablespaces for your
environment.
c. Refer to the Oracle command reference for more information about using the create tablespaces
command.
3. Ensure the database is registered with the Oracle listener. Use the tnsnames.ora file to describe this
AIX stand-alone: Assigning custom Oracle or Oracle RAC table spaces:
Installing 221
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
the keyword TABLESPACE and a space. For example: community.COMP_INST.tablespace=TABLESPACE
COMM8KSPACE
AIX stand-alone: Configuring Portal to use Oracle or Oracle RAC:
This section provides information on how to manually transfer data from the default database to the
Oracle database. Follow these steps to transfer Portal and Java Content Repository databases to Oracle.
As an alternative to the manual database transfer procedure described here, you can use the
configuration wizard to complete the database transfer task.
Before your begin:
v Property files are modified.
v Your databases are UTF compliant. Verify compliance before transferring your databases by using the
SQL statements in Technote 1317981.
Tips:
Repository schema.
For Oracle RAC only:
v The WebSphere Portal server must explicitly connect to one RAC node during database transfer. You
need to specify the information of one Oracle RAC node as if it is the only database server. For
example, the Oracle database URL should look like the following:
jdbc:oracle:thin:@PRIMARY_NODE_HOSTNAME:1521:PRIMARY_NODE_INSTANCENAME. When database transfer
is completed, the WebSphere Portal server will be configured to use this single database server.
v When doing a single database, single user, and multi schema database transfer, there can be only one
Installing 223
files:
name are the same.
7. After transferring the database tables, run the dbms_stats.gather_schema_stats command to avoid
slow database response. Example:
Start sqlplus and log in to the jcr.DbName database as the jcr.DbUser
SQL> execute dbms_stats.gather_schema_stats(ownname=> jcr.DbUser, cascade=> TRUE);
SQL > commit;
Exit sqlplus
In this example, jcr.DbName is the value you specified for jcr.DbName in the
wkplc_dbdomain.properties file. jcr.DbUser is the value you specified for jcr.DbUser in the
10. (Oracle RAC only) Manually specify an RAC datasource URL in the WebSphere Application Server
console. The URL should look like the following:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_NODE_HOSTNAME)
(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=SECONDARY_NODE_HOSTNAME)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=DATABASE_SERVICENAME))).
Related tasks:
AIX stand-alone: Creating Oracle or Oracle RAC databases on page 213
Technote 1317981
AIX stand-alone: Changing Oracle or Oracle RAC driver types:
IBM WebSphere Portal requires the use of either Oracle JDBC Type 4 drivers or JDBC OCI Type 2 drivers
when connecting to Oracle or Oracle RAC. You may need to change driver types after a migration. Direct
migration from a previous installation of WebSphere Portal using JDBC Type 4 drivers to an installation
using JDBC OCI Type 2 drivers is not supported. To migrate from a previous version of WebSphere
Portal using JDBC Type 4 drivers, the target system must use JDBC Type 4 drivers. Once migration is
complete, you can continue using JDBC Type 4 drivers or change the driver type to JDBC OCI Type 2
drivers as appropriate.
v You have completed one of the following goals:
You have successfully transferred your data to Oracle or Oracle RAC using the database-transfer
configuration task.
The WebSphere Portal migration has been successfully transferred to Oracle or Oracle RAC using
the Type 4 JDBC driver.
correct values for the Oracle drivers that you are switching to:
Note: The value for service_name in the database URL is the same value used for the service name
value in the tnsnames.ora file on your Oracle database.
In the file wkplc_dbdomain.properties set each domain.DbUrl property using the following formats:
Table 116. Format for domain.DbUrl
Database Format for domain.DbUrl
Oracle (JDBC OCI Type 2) jdbc:oracle:oci:@//YourDatabaseServer:1521/service_name
Oracle (JDBC Type 4) jdbc:oracle:thin:@YourDatabaseServer:1521:service_name
Oracle RAC (JDBC OCI Type 2) jdbc:oracle:oci:@//NODE_HOSTNAME:1521/NODE_INSTANCENAME
Oracle RAC (JDBC Type 4) jdbc:oracle:thin:@NODE_HOSTNAME:1521:NODE_INSTANCENAME
2. Enter the ./ConfigEngine.sh validate-database command to validate configuration properties.
Installing 225
Related tasks:
AIX stand-alone: Creating Oracle or Oracle RAC databases on page 213
AIX stand-alone: Setting up Oracle or Oracle RAC automatically or manually on page 214
AIX stand-alone: Setting up a SQL Server database:
View information on installing and setting up SQL Server to work with WebSphere Portal.
AIX stand-alone: Installing SQL Server:
View the steps to install SQL Server for use with WebSphere Portal.
Before you begin this task, complete the following prerequisites:
v You should have completed reviewing the Planning for SQL Server topic.
v You must install SQL Server separately from WebSphere Portal.
v WebSphere Portal requires Microsoft SQL Server JDBC Driver. You can obtain the Microsoft SQL
Server JDBC Driver from Microsoft. See the Microsoft SQL Server product documentation for
installation details
Note: The driver must be a JDBC 4.0 compliant driver.
The following section provides instructions for installing SQL Server for use with IBM WebSphere
Application Server and WebSphere Portal.
1. Install SQL Server and all required patches.
2. Select the Mixed Mode (Windows Authentication and SQL Server Authentication) authentication
mode for this installation.
Important: Mixed Mode authentication allows either a Windows user or an SQL Server user, or both,
to log in to the SQL Server; however, WebSphere Portal requires the user to be an SQL Server user.
3. In the SQL Server Set up panel, Components to Install, select the following components, which are
required services for WebSphere Portal:
v SQL Server Database Services
4. Complete the installation using SQL Server documentation as a guide.
5. Enable TCP/IP connectivity in the SQL Server Configuration Manager.
6. Install the JDBC driver using Microsoft SQL Server JDBC drivers and enabling XA connections:
a. Download and install the Microsoft SQL Server JDBC driver; see Microsoft Download Center for
information.
b. Copy file sqljdbc_xa.dll from the xa subdirectory to the C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\Binn\sqljdbc_xa.dll directory of the SQL Server installation.
c. Start the database server.
d. Ensure that the Distributed Transaction Coordinator has been started. The status can be verified in
the list of services in the Computer Management console.
e. Start the Microsoft SQL Server Management Studio and connect to the local database engine as the
system administrator, sa.
f. Select File > Open > File and select xa_install.sql from the subdirectory of the downloaded and
extracted JDBC driver.
g. Execute the script by selecting Query > Execute.
Note: Any warnings that appear in the messages section of the application window that say that
stored procedures cannot be found can be safely ignored.
h. For Microsoft SQL Server JDBC drivers: If you are running Windows XP SP2, Windows XP 64-Bit
Edition, or Windows Server 2003, refer to the Registry Entries Are Required for XA Transaction
Support document for information on a new security constraint and how to set SQL Server on
Windows XP SP2, Windows XP 64-Bit Edition, or Windows Server 2003.
Create a additional value in the Windows registry for WebSphere Portal by following these steps:
1) Open theWindows Registry Editor (regedit) and navigate to the element HKEY_LOCAL_MACHINE\
SOFTWARE\Microsoft\MSDTC\XADLL
2) From the menu bar, select Edit > New > String Value to create a new parameter named
sqljdbc_xa.dll in that element.
3) Change the value of the new parameter to the location of the sqljdbc_xa.dll file copied in the
previous substep, for example: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\
sqljdbc_xa.dll
7. Start SQL Server.
AIX stand-alone: Modifying SQL Server database properties:
to the SQL database.
jcr.DbName=jcrdb
Installing 227
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
a. For dbdomain.DbType, type sqlserver2005.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note: This value is the location to store the database files locally.
o. For dbdomain.AdminUrl, type the sqlserver URL without a database attached. This value is used to
connect to the server for database administration operations.
p. For dbdomain.DbHostName, type the hostname of the database.
a. For sqlserver2005.DbDriver, type the name of the JDBC driver class.
b. For sqlserver2005.DbLibrary, type the directory and name of the .zip or .jar file that contains the
JDBC driver class.
c. For sqlserver2005.JdbcProviderName, type the name of the JDBC provider that WebSphere Portal
d. For sqlserver2005.DbConnectionPoolDataSource, type the name of the implementation class of the
connection pool data source.
Installing 229
AIX stand-alone: Setting up SQL Server automatically or manually:
You can set up Microsoft SQL Server Enterprise Edition to work with WebSphere Portal automatically or
manually. When setting up SQL Server automatically, the database administrator runs a ConfigEngine
task to create users, grant privileges, and create JCR table spaces. As an alternative to automatically
setting up the database, you can manually run scripts to create users, grant privileges, and create JCR
table spaces.
Automatic configuration provides a faster path for database administrators for setting up SQL Server, but
Note:
database.
Related tasks:
AIX stand-alone: Installing SQL Server on page 226
AIX stand-alone: Running a task to automatically setup SQL server databsaes:
privileges.
Important: After setting up your databases, enable the autogrowth feature for the log associated with the
JCR database. This will ensure that uploading large files (approximately 100 MB or larger) to Web
Content Manager works properly.
1. Start the Microsoft SQL Server Management Studio.
2. Expand the Databases folder.
3. Right-click on the JCR database and select Properties.
4. Click Files.
5. Locate the database log row and click the details button (...) located immediately after the
Autogrowth field.
6. Check the Enable Autogrowth check box and set the autogrowth properties as needed. When using
Restricted File Growth, set the value to at least 100 MB.
7. Click OK to save your changes to the Change Autogrowth screen.
8. Click OK to save your changes to the Database Properties screen.
9. Exit the Microsoft SQL Server Management Studio.
AIX stand-alone: Setting up SQL Server manually:
As an alternative to automatically setting up the database, you can manually configure the SQL Server
running the ConfigEngine task, you do not need to run manual tasks for creating users, privileges, or
table spaces, but you may decide to perform additional manual configuration for items that are not
provided to you when you automatically when you run the ConfigEngine task. For example, assigning
custom table spaces is an optional task that is not covered by the automated ConfigEngine task.
AIX stand-alone: Creating databases manually on SQL Server:
This section provides information on setting up SQL Server for WebSphere Portal.
Before you begin, you must create the databases.
1. Expand the nodes to see Databases.
2. Right-click Databases to see New database.
3. Enter the database name. For information on the recommended database architecture and the
databases you will need to create, see Planning for SQL Server
4. On the Options page, select Collation Name from the drop-down list that matches your environment.
Set the collation to case-sensitive. For example, on an English system: SQL_Latin1_General_CP1_CS_AS
Note: For LikeMinds, CI is the default setting; however, CS can also be used.
5. Click OK to save the database changes.
AIX stand-alone: Creating SQL Server database schemas and users:
Before you begin:
v You should have completed installing SQL Server and creating databases.
installation.
At least one user is required for each SQL Server instance. Take care to create users in an environment
that has the same settings as the actual runtime environment. For example, avoid creating a user in an
English environment if you plan to use that user in a Turkish environment.
Installing 231
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/sqlserver2005/release/
createSchema.sql
PortalServer_root/base/wp.db.impl/config/templates/setupdb/sqlserver2005/release/
createUsers.sql
Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/sqlserver2005/
community/createSchema.sql
PortalServer_root/base/wp.db.impl/config/templates/setupdb/sqlserver2005/
community/createRuntimeUsers.sql
community/createUsers.sql
Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/sqlserver2005/
customization/createSchema.sql
customization/createRuntimeUsers.sql
customization/createUsers.sql
JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/sqlserver2005/jcr/
createSchema.sql
PortalServer_root/base/wp.db.impl/config/templates/setupdb/sqlserver2005/jcr/
createUsers.sql
Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/sqlserver2005/feedback/
createSchema.sql
PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/sqlserver2005/feedback/
createUsers.sql
Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/sqlserver2005/likeminds/
createSchema.sql
PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/sqlserver2005/likeminds/
createUsers.sql
AIX stand-alone: Granting privileges to SQL Server database users:
community/createConfigRoleForSameSchema.sql
community/grantRoleToConfigUser.sql
customization/grantRoleToConfigUser.sql
database user:
Installing 233
community/createConfigRoleForDifferentSchema.sql
community/createInitialRuntimeRole.sql
community/createRuntimeRoleForSameSchema.sql
community/grantRoleToRuntimeUser.sql
customization/createInitialRuntimeRole.sql
customization/grantRoleToRuntimeUser.sql
sqlserver2005/jcr/grantPermissionsToRuntimeRoleStatic.sql
Installing 235
community/createRuntimeRoleForDifferentSchema.sql
Related concepts:
AIX stand-alone: Assigning custom SQL Server filegroups:
The repository of WebSphere Portal consists of many tables and indices that are created in default
filegroups. When using an existing set of filegroups for the objects of the repository, specify this when
executing the database transfer to the target management database system.
Before you begin:
v The custom filegroups must exist prior to the execution of the database transfer.
v For details on creating filegroups refer to the documentation for the database.
If custom filegroups are assigned, each must be assigned explicitly. The default filegroups can be used to
contain database objects; however the name of the default file group must be specified in the
database transfer.
To configure custom filegroups:
1. Determine the names of your custom filegroups.
2. Open the mapping file wp_profile_root /PortalServer/config/tablespaces that specifies the table space
and index space for each property pairs for each database table:
dbdomain.table_name.indexspace.indexspace
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
3. Assign a filespace to each entry in the mapping file. The filegroup name must be prepended by the
keyword ON and a space. For example: community.COMP_INST.tablespace=ON COMM8KSPACE
Installing 237
AIX stand-alone: Configuring Portal to use SQL Server:
This section provides information on how to manually transfer data from the default database to the SQL
Server database. Follow these steps to transfer Portal and Java Content Repository databases to SQL
Server. As an alternative to the manual database transfer procedure described here, you can use the
Before you begin:
Tips:
Repository schema.
b. Enter the following commands: ./ConfigEngine.sh database-transfer -DWasPassword=password
files:
name are the same.
7. Run the ./ConfigEngine.sh create-jcr-jms-resources-post-dbxfer -DWasPassword=password
command to create JMS resources in the new database.
Note: Regardless of the method used to transfer data (configuration wizard or the steps in this
topic), you must run this task to create JMS resources.
10. Update the SQL Server 2005 statistics for Portal, and JCR databases by opening SQL Server
Management Studio, selecting New Query, and running the following query: use db_name exec
sp_updatestats @resample=resample;
Installing 239
Related tasks:
AIX stand-alone: Installing SQL Server on page 226
AIX stand-alone: Modifying SQL Server database properties on page 227
AIX stand-alone: Verifying the database configuration:
After you configure IBM WebSphere Portal to work with your database, test the database connection to
ensure that it operates correctly. Then verify that all database transactions work properly within the
WebSphere Portal environment. For example, all portal pages should display without HTTP 404 errors,
and there should be no database layer-related exceptions in the SystemOut.log and SystemErr.log
filesPortalServer joblog.
You can verify the database connection using IBM WebSphere Application Server or by opening
WebSphere Portal in a browser.
v To verify that the WebSphere Portal application server is running by using the WebSphere Integrated
Solutions Console, complete these steps:
1. Open the WebSphere Integrated Solutions Console by entering the following address in a browser:
http://hostname.example.com:10042/ibm/console
where hostname.example.com is the fully qualified host name of the machine where WebSphere Portal
is running and 10042 is the default transport port that is created by WebSphere Application Server.
2. Log into the WebSphere Integrated Solutions Console.
3. Click Resources > JDBC > JDBC Providers.
4. Select all scopes (the default setting) or select a specific cell, node, or node/server. Select the scope
that corresponds to your instance of WebSphere Portal. The view refreshes.
Stand-alone WebSphere Portal: Select Server scope.
Clustered WebSphere Portal: Select Cluster scope.
5. Select the name of the JDBC provider that is specified in wkplc_dbtype.properties. The default
JDBC provider is wpdbJDBC_dbtype, where dbtype is replaced by the value that matches your
environment.
6. Select the name of the data source that is defined in wkplc_dbdomain.properties. The default data
source is wpdbDS.
7. Click Test Connection to verify the database connection. If configuration parameters have been
changed, you might need to restart WebSphere Application Server for the test to complete.
v To verify that the WebSphere Portal application server is running by opening WebSphere Portal in a
browser, enter the following URL in a supported browser:
http://hostname.example.com:10039/wps/portal
where hostname.example.com is the fully qualified host name of the machine where WebSphere Portal is
running and 10039 is the default transport port that is created by WebSphere Application Server.
AIX stand-alone: Preparing a remote Web server
Install and configure the Web server plug-in, provided by IBM WebSphere Application Server, to set up
your Web server to communicate with IBM WebSphere Portal.
Complete the following steps to install and configure your Web server:
1. Install and configure the Web server; refer to the Web server documentation for information.
2. If using IBM Lotus Domino, edit the NOTES.INI file on the Web server. Set the
HTTPEnableConnectorHeaders and HTTPAllowDecodedUrlPercent parameters to 1. Also, if you are
using WebDav, enable it in the Lotus Domino Webserver Administrative Console.
3. If using IBM HTTP Server or Apache Server, edit the httpd.conf file on the Web server. Set the
AllowEncodedSlashes directive to On; the directive should be added at the root level as a global
directive.
Table 122. Links to HTTP and Apache server documentation
HTTP server type Documentation link
See the appropriate HTTP Server documentation IBM HTTP Server
See the appropriate Apache Server documentation AllowEncodedSlashes directives
4. Stop the Web server.
5. Install and configure the Web server plug-in on the system where the Web server is located using the
Plug-ins installation wizard provided with WebSphere Application Server. Refer to Selecting a Web
server topology diagram and road mapCommunicating with Web servers for information.
If using WebDAV with mashups: After successfully installing the Web server plug-in, locate and
open your plugin-cfg.xml file and set AcceptAllContent to true.
Important: Depending on how you use the Web server, you may need to adjust the ServerIOTimeout
value, which defines how long the plug-in should wait for a response from the application. The
recommended minimum value is 60 but you may need to adjust this value higher if you are
retrieving data from a database. To update this value, locate and open your plugin-cfg.xml file and
set ServerIOTimeout to a value that is appropriate for your business needs. For additional
information, see Common questions about the Web server plug-in.
6. If you are using a Oracle iPlanet Web Server, some portlets require that you disable the
unix-uri-clean or nt-uri-clean directives to operate properly. You can enable/disable these
directives by editing the obj.conf file. Refer to the Oracle iPlanet Web Server documentation to
determine the appropriate setting for your environment.
Note: If you are using Oracle iPlanet Web Server Version 7, you must disable uri-clean.
7. If you are using Oracle iPlanet Web Server Version 7 update 8, read Technote 1448262 and complete
the steps to resolve the HTTP 408/409 error.
8. Some features, such as portal mashups and change layout for pages with the Page Builder theme
using an IIS web server, require an enabled PUT and DELETE method. If your Web server has these
methods disabled, complete one of the following options:
v Enable HTTP tunneling to simulate PUT and DELETE requests, which means that POST requests
are used instead. See the "Switch for tunneling of HTTP methods" link for information.
v Follow the instructions for your Web server to enable PUT and DELETE requests.
9. Start the Web server.
10. Optional: Complete the following steps if you plan to use the Web application bridge integration
feature:
a. Log on to the WebSphere Integrated Solutions Console.
b. Go to Applications > Application Types > WebSphere enterprise applications.
c. Find and click the wp.vwat.servlet.ear application link.
d. Under the Web Module Properties heading, click Context Root For Web Modules.
e. Change the context root to /.
f. Click OK.
g. Click Save to save your changes to the master configuration.
h. Stop and restart the wp.vwat.servlet.ear application.
Installing 241
Related tasks:
authentication.
Related reference:
Switch for tunneling of HTTP methods on page 3924
The portal implementation allows you to simulate PUT and DELETE requests by tunneling, that is by
using POST requests instead.
AIX stand-alone: Configuring portal to use a user registry
Configure user registry security on IBM WebSphere Portal to protect your server from unauthorized
users. You can configure a stand-alone LDAP user registry or you can add LDAP user registries and/or
database user registries to the default federated repository. After configuring your user registry, you can
add realms for Virtual Portals or a lookaside database to store attributes that cannot be stored in the
LDAP user registry.
Prior to configuring security, you should use the IBM WebSphere Application Server backupConfig task to
create and store a back up of the IBM WebSphere Portal configuration; see backupConfig command for
information.
Complete the following tasks to configure WebSphere Portal to use a user registry:
Related tasks:
authentication.
AIX stand-alone: Configuring Portal to use a database on page 156
Managing your user registry on AIX on page 3076
After installing and deploying IBM WebSphere Portal, which includes installing and configuring the user
registry, you can manage the user registry by running various update and/or delete tasks. These tasks
include, but are not limited to, adding a property extension (lookaside) database, updating or deleting the
entity type, and deleting the registry.
AIX stand-alone: Preparing user registries:
Install and set up an LDAP server as a user registry to store user information and authenticate users in
your clustered environment.
Choose the appropriate LDAP server to install and set up:
AIX stand-alone: Preparing a Domino Directory:
If you plan to use a Domino Directory as an LDAP user registry, you must install and set up the server
so that it communicates with IBM WebSphere Portal.
Complete the following steps to prepare Domino Directory:
1. Complete the following steps to install the Domino Directory:
a. Go to Lotus Domino documentation.
b. Select the appropriate version tab for your product.
c. Click the Download/View online link for the Lotus Domino for multiple platforms Information
Center.
d. Click Domino Administrator Help > Installation > Installing and setting up Domino servers >
Server installation > Installing Domino on UNIX and complete this task.
e. Click Domino Administrator Help > Installation > Installing and setting up Domino servers >
The Domino server setup program and complete this task.
2. Complete the following steps as a guide to create the WebSphere Portal administrative user:
a. Navigate to the People view of the Domino Directory and then click Add Person.
b. Enter the following values in the New Person form to create the LDAP bind user. The following
example will use wpsbind to represent the LDAP bind user:
Last Name
wpsbind
User Name
wpsbind/DominoDomain, where DominoDomain is your Lotus Domino Internet domain
wpsbind
Note: Make sure you enter two values in the User Name field, where the first value
includes the Lotus Domino domain.
Short name/UserID
wpsbind
Internet password
wpsbind
c. Click Save and Close to save the new person record for wpsbind and return to the People view.
d. Click Add Person and enter the following values in the New Person form to create the Portal
administration user. The following example will use wpsadmin to represent the Portal
administration user:
Last Name
wpsadmin, where wpsadmin in the user ID for the WebSphere Portal Administrator
User Name
wpsadmin/DominoDomain, where DominoDomain is your Lotus Domino Internet domain
wpsadmin
Short name/UserID
wpsadmin
Installing 243
Internet password
wpsadmin
e. Click Save and Close to save the new person record for wpsadmin and return to the People view.
f. Navigate to the Groups view and click Add Group.
g. Enter the following values in the New Group form on the Basic tab.
Group name
wpsadmins
Note: If you plan to configure WebSphere Portal for multiple user registries and your
Lotus Domino LDAP will share a realm with another user registry, you must use the
hierarchical naming convention for the group names, for example: wpsadmins/
DominoDomain, to avoid unexpected results during WebSphere Portal runtime.
Group type
Multi-purpose
Members
wpsbind/DominoDomain
wpsadmin/DominoDomain
Note: You can add additional administrator users if required.
h. Click Save and Close to save the wpsadmins group with the wpsbind and wpsadmin users as
members.
3. Complete the following steps to update the access control list for the Domino Directory:
a. Open the names.nsf file in the Lotus Domino Administrator or Lotus Notes client.
b. Click File > Application > Access Control from the main menu to open the access control list for
the file.
c. In the Access Control List > Basics panel, ensure that the wpsadmins group has either Author or
Editor access.
d. Add the following Role Types to the wpsadmins group:
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
AIX stand-alone: Preparing a SecureWay Security Server:
If you plan to use a SecureWay Security Server as an LDAP user registry, you must install and set up the
server so that it communicates with IBM WebSphere Portal.
Complete the following steps to prepare SecureWay Security Server:
1. Install SecureWay Security Server; refer to the IBM SecureWay Security Server for z/OS and OS/390
for information.
2. Complete the following steps using the Tivoli Directory Server Web Administration Tool to create the
WebSphere Portal administrative user:
a. Optional: Complete the following steps to create a new directory suffix:
1) Click the Server Administration folder, located in the directory server console navigation.
2) Click the Manage Server Properties folder under the Server Administration folder and then
select Suffixes on the main page.
3) Type the Base DN name for the suffix; for example: dc=yourcompany,dc=com.
4) Click Add.
5) Click OK to save your changes.
b. Open the appropriate LDIF file, located in the PortalServer_root/installer/wp.iim/ldif directory,
with a text editor:
Use the PortalUsers.ldif file as a working example and adapted appropriately to work with
your LDAP server.
Use the ContentUsers.ldif file for the IBM Content Manager group and user IDs if you
configured IBM Content Manager.
c. Replace every dc=yourco,dc=com with your suffix.
d. Replace any prefixes and suffixes that are unique to your LDAP server.
e. You can specify user names other than wpsadmin and wpsbind. For security reasons, specify
nontrivial passwords for these administrator accounts.
f. Save your changes.
g. Follow the instructions provided with your directory server to import the LDIF file.
AIX stand-alone: Preparing a Novell eDirectory:
If you plan to use a Novell eDirectory as an LDAP user registry, you must install and set up the server so
that it communicates with IBM WebSphere Portal.
Complete the following steps to prepare Novell eDirectory:
1. Install Novell eDirectory; refer to eDirectory for information.
4) Click Add.
with a text editor:
your LDAP server.
AIX stand-alone: Preparing an Oracle Directory Server:
If you plan to use a Oracle Directory Server, formerly known as Sun Java System Directory Server, as an
LDAP user registry, you must install and set up the server so that it communicates with IBM WebSphere
Portal.
Installing 245
Complete the following steps to prepare Oracle Directory Server:
1. Install Oracle Directory Server; refer to Oracle software for information.
4) Click Add.
with a text editor:
your LDAP server.
AIX stand-alone: Preparing a Tivoli Directory Server:
If you plan to use a Tivoli Directory Server as an LDAP user registry, you must install and set up the
Complete the following steps to prepare Tivoli Directory Server:
1. Install Tivoli Directory Server; refer to the Tivoli Directory Server Installation and Configuration
Guide for instructions.
Note: Due to a restriction in Tivoli Directory Server, users or groups must not contain a Turkish
uppercase dotted I or lowercase dotted i in the DN as this will prevent correct retrieval of that user or
group.
4) Click Add.
with a text editor:
your LDAP server.
AIX stand-alone: Choosing your user registry model:
Choose between securing IBM WebSphere Portal with a standalone LDAP user registry or by adding
LDAP user registries and/or database user registries to the default federated repository. Choose the
federated repository if you plan to enable the transient user feature.
Choose one of the following user registry models:
AIX stand-alone: Configuring a stand-alone user registry:
Depending on the type of data that is exchanged between IBM WebSphere Application Server, IBM
WebSphere Portal, and your LDAP server, you can either configure your LDAP server over SSL or
configure it to have direct access to IBM WebSphere Application Server and IBM WebSphere Portal.
Choose one of the following options to configure your LDAP server:
AIX stand-alone: Configuring a stand-alone LDAP user registry without SSL:
Configure IBM WebSphere Portal to use a standalone LDAP user registry to store all user account
information for authorization.
In a stand-alone server environment, you can complete the following task when the servers are either
stopped or started. In a clustered environment, start the deployment manager and nodeagent and verify
that they are able to synchronize before starting the following task.
If you need to rerun the wp-modify-ldap-security task to change the LDAP repositories or because the
task failed, you must choose a new name for the realm using the standalone.ldap.realm parameter or
you can set ignoreDuplicateIDs=true in the wklpc.properties file, before rerunning the task.
Complete the following steps to configure a standalone LDAP user registry:
Note: Use the wp_security_xxx.properties helper file, located in the wp_profile_root/ConfigEngine/
config/helpers directory, when completing this task to ensure the correct properties are entered. In the
following instructions, where the step refers to the wkplc.properties file, use your
wp_security_xxx.properties helper file.
1. Prior to configuring security, you should use the IBM WebSphere Application Server backupConfig
task to create and store a back up of the IBM WebSphere Portal configuration; see backupConfig
command for information.
2. Use a text editor to open the wkplc.properties file, located in the wp_profile_root/ConfigEngine/
properties directory.
3. Required: Enter a value for the following required parameters in the wkplc.properties file under the
Stand-alone security heading:
Note: See the properties file for specific information about the required and advanced parameters.
standalone.ldap.id
Installing 247
standalone.ldap.host
standalone.ldap.port
standalone.ldap.bindDN
standalone.ldap.bindPassword
standalone.ldap.ldapServerType
standalone.ldap.userIdMap
standalone.ldap.groupMemberIdMap
standalone.ldap.userFilter
standalone.ldap.groupFilter
standalone.ldap.serverId
standalone.ldap.serverPassword
standalone.ldap.realm
standalone.ldap.primaryAdminId
standalone.ldap.primaryAdminPassword
standalone.ldap.primaryPortalAdminId
standalone.ldap.primaryPortalAdminPassword
standalone.ldap.primaryPortalAdminGroup
standalone.ldap.baseDN
4. Required: Enter a value for the following required entity types parameters in the wkplc.properties
file under the LDAP entity types heading:
standalone.ldap.et.group.objectClasses
standalone.ldap.et.personaccount.objectClasses
5. Required: Enter a value for the following required group member parameters in the
wkplc.properties file under the Group member attributes heading:
standalone.ldap.gm.groupMemberName
standalone.ldap.gm.objectClass
standalone.ldap.gm.scope
standalone.ldap.gm.dummyMember
6. Required: Enter a value for the following required relative distinguished name (RDN
) parameters in
the wkplc.properties file under the Default parent, RDN attribute heading:
standalone.ldap.personAccountParent
standalone.ldap.groupParent
standalone.ldap.personAccountRdnProperties
standalone.ldap.groupRdnProperties
7. Save your changes to the wkplc.properties file.
8. Run the ./ConfigEngine.sh validate-standalone-ldap -DWasPassword=password task to validate
your LDAP server settings.
Note: In an environment configured with an LDAP with SSL, during the validation task, you will
be prompted to add a signer to the truststore. For example, Add signer to the truststore now?. If
you do, press y then Enter.
9. Run the ./ConfigEngine.sh wp-modify-ldap-security -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to set the stand-alone LDAP user registry.
10. Stop and restart the appropriate servers to propagate the changes. For specific instructions, see
Starting and stopping servers, deployment managers, and node agents on page 2550.
11. Run the ./ConfigEngine.sh wp-validate-standalone-ldap-attribute-config
-DWasPassword=password task, from the wp_profile_root/ConfigEngine directory, to check that all
defined attributes are available in the configured LDAP user registry.
Important: When you finish configuring your LDAP user registry, see "Adapting the attribute
configuration" for information about adding and mapping attributes to ensure proper communication
between WebSphere Portal and the LDAP server.
12. Required: Run the Member Fixer task to update the member names used by Web Content Manager
with the corresponding members in the LDAP directory.
LDAP configuration.
Note: The MemberFixerModule.properties file already contains lines for xyzadmin. You can
ignore this line.
d. Run the ./ConfigEngine.sh run-wcm-admin-task-member-fixer -DallLibraries=true -Dfix=true
-DaltDn=update -DmismatchedId=update -DinvalidDn=update -DnoRealmDn=true
-DPortalAdminPwd=wpsadmin task, located in the wp_profile_root/ConfigEngine directory.
Portal administrator ID note: If the portal administrator ID is not unique to your environment,
either provide the fully qualified ID as the value for the PortalAdminID parameter in the
wkplc.properties file or specify the fully qualified ID as part of the command. For example, if
the portal administrator ID is wpsadmin and your LDAP directory contains wpsadmin as the ID
for a different user, this task does not run successfully. Therefore, you must specify a fully
qualified portal administrator ID such as uid=wpsadmin,cn=users,ou=test,o=retail,o=ibm.
Note: Choose the appropriate value to enter for realm_name depending on the type of LDAP
user registry you configured. Search wkplc.properties for .realm and find the appropriate
parameter for your LDAP user registry configuration:
Table 123. Value for realm_name when running the Member Fixer task to update the member names used by Web
Content Manager
Type of LDAP Value
Standalone LDAP The value specified for realm_name should match the
value for standalone.ldap.realm in the
wkplc.properties file.
Federated LDAP The value specified for realm_name should match the
value for federated.realm in the wkplc.properties file.
If the value for federated.realm is empty, use
defaultWIMFileBasedRealm as the default value.
13. Update the SearchAdminUser alias to match your WebSphere Portal administrator information. See
the related links for information.
Installing 249
14. Optional: Assign access to the Web content libraries.
a. Log in as a portal administrator.
b. Navigate to Administration > Portal Content > Web Content Libraries.
c. Click the Set permissions icon for the Web library.
d. Click the Edit Role icon for Editor.
e. Add the group you specified for content_authors_group_DN as an Editor for the Intranet and
Internet libraries.
f. Click Apply then Done.
15. If you have created any additional Web Content Manager libraries, run the Web content member
fixer task to update the member names used by the libraries.
16. WebSphere Application Server stores the credentials for scheduler tasks. To establish the correct
information, all schedulers must be reregistered. Restart your system and verify that the new
security configuration is active. Then, execute the following task.
ConfigEngine.sh reregister-scheduler-tasks -DPortalAdminId=yourportaladminid -DPortalAdminPwd=yourportaladminpw
Related tasks:
AIX cluster: Adapting the attribute configuration on page 420
After installing IBM WebSphere Portal and configuring your LDAP user registries, you will need to adapt
the attribute configuration to match the configured LDAP server(s) and your business needs. However,
you do not need to perform these steps if you are using either a database user registry or the default
federated file-based repository for out-of-box installations.
Starting and stopping servers, deployment managers, and node agents on page 2550
There are various installation and configuration tasks that require you to start and stop IBM WebSphere
Application Server and the IBM WebSphere Portal application servers, deployment managers, and node
agents. If you are not familiar with how to start and stop these servers, deployment managers, or node
agents, you can refer to this file for the necessary steps.
Replacing the search administrator user ID on page 2706
If you changed the portal administrator user ID or password, you need to update the search
administrator user ID to match the same values.
How to fix Portal Access Control settings after user/group external identifiers have changed
AIX stand-alone: Configuring a stand-alone LDAP user registry over SSL:
Configure IBM WebSphere Portal to use a standalone LDAP user registry over SSL to store all user
account information for secure authorization.
Complete the following steps to configure a standalone LDAP user registry over SSL:
2. Complete the following steps to retrieve the SSL certificate from the port:
a. Log in to the WebSphere Integrated Solutions Console.
b. Go to Security > SSL certificate and key management > SSL configurations.
c. Click the appropriate SSL configuration from the list. For example: NodeDefaultSSLSettings
d. Click Key stores and certificates.
e. Click the appropriate truststore from the list; for example, NodeDefaultTrustStore.
f. Click Signer certificates, click Retrieve from port, and then enter the following information:
Type the Host name used when attempting to retrieve the signer certificate from the SSL port.
Type the SSL Port used when attempting to retrieve the signer certificate.
Type the Alias the key store uses for the signer certificate.
g. Click Retrieve signer information to retrieve the certificate from the port.
h. Click OK and then click Save to save the changes to the master configuration.
standalone.ldap.id
Installing 251
7. Required: Enter a value for the following required relative distinguished name (RDN) parameters in
8. Enter a value for the following parameters in the wkplc.properties file under the Advanced
Properties heading to enable Secure Socket Layers (SSL):
Required parameters:
standalone.ldap.sslEnabled
standalone.ldap.sslConfiguration
Tip: To enable the SSL configuration for the LDAP user registry, change the value of the
standalone.ldap.sslEnabled parameter to true.
Optional parameters:
standalone.ldap.certificateMapMode
standalone.ldap.certificateFilter
configuration" for information about adding and mapping attributes to ensure proper
communication between WebSphere Portal and the LDAP server.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Installing 253
Related tasks:
AIX stand-alone: Configuring the default federated repository:
Add an LDAP user registry and/or a database user registry to the default federated repository to create
seamless authentication within the repository.
Complete the following tasks to add user registries to the default federated repository:
AIX stand-alone: Configuring a default federated user registry:
AIX stand-alone: Adding an LDAP user registry without SSL:
Add an LDAP user registry to the default federated repository to store user account information for
authorization. You can add multiple LDAP user registries to the default federated repository although
you can only add one LDAP server at a time. For example, the flat-naming convention is cn=groupName
and the hierarchical format is cn=groupName,o=root. You must also ensure that the IDs are unique
between the default federated repository and the LDAP you are adding. For example, if the default
federated repository contains an ID such as wpsadmin, this ID cannot exist in the LDAP you are adding.
Complete the following steps to add an LDAP user registry to the default federated repository; you must
repeat these steps for each additional LDAP user registry that you plan to add:
Note: Use the wp_add_federated_xxx.properties helper file, located in the wp_profile_root/ConfigEngine/
wp_add_federated_xxx.properties helper file.
VMM Federated LDAP Properties heading:
federated.ldap.id
federated.ldap.host
federated.ldap.port
federated.ldap.bindDN
federated.ldap.bindPassword
federated.ldap.ldapServerType
federated.ldap.baseDN
federated.ldap.et.group.objectClasses
federated.ldap.et.personaccount.objectClasses
wkplc.properties file under the Group member attribute heading:
federated.ldap.gm.groupMemberName
federated.ldap.gm.objectClass
federated.ldap.gm.scope
federated.ldap.gm.dummyMember
7. Run the ./ConfigEngine.sh validate-federated-ldap -DWasPassword=password task to validate your
LDAP server settings.
8. Run the ./ConfigEngine.sh wp-create-ldap -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to add an LDAP user registry to the default federated
repository.
Note: Users who are not in an LDAP do not have awareness and cannot see if other users are
online. This can happen if you install WebSphere Portal and then enable a Federated LDAP or
Federated database user repository that does not contain that user. Also, users who sign up using the
Self Care portlet do not have awareness.
10. Optional: Complete the following steps to create additional base entries within the LDAP user
registry; repeat these steps for each base entry that you want to create for multiple realm support:
Installing 255
a. Use a text editor to open the wkplc.properties file, located in the wp_profile_root/ConfigEngine/
b. Enter a value for the following required parameters in the wkplc.properties file under the VMM
repository base entry configuration heading to create additional base entries within the LDAP
user registry to use when creating realms:
Note: See the properties file for specific information about the required and advanced
parameters.
id
baseDN
nameInRepository
c. Save your changes to the wkplc.properties file.
d. Run the ./ConfigEngine.sh wp-create-base-entry -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to create a base entry in a repository.
e. Stop and restart all necessary servers to propagate your changes.
11. Optional: Run the ./ConfigEngine.sh wp-query-repository -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to list the names and types of configured repositories.
12. Run the ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config
13. Complete the following steps to update the user registry where new users and groups are stored:
Note: If you are using multiple LDAP user registries and/or a database user registry, only run this
task for the user registry that you want to define as the default user registry where new users and
groups are stored.
supported entity types configuration heading:
parameters.
personAccountParent
groupParent
personAccountRdnProperties
groupRdnProperties
The parameters groupParent and personAccountParent must be set to the same value. For
example:
personAccountParent=dc=yourco,dc=com
groupParent=dc=yourco,dc=com
d. Run the ./ConfigEngine.sh wp-set-entitytypes -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to delete the old attributes before adding the new
attributes.
14. Optional: Complete the following steps to enable the full distinguished name login if the short
names are not unique for the realm:
Tip: Run this task if the administrator name is in conflict with another user name in the attached
repository. This command allows the Administrator to log in using the fully distinguished name
instead of the short name.
b. Enter a value for realmName or leave blank to update the default realm.
d. Run the ./ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=password task,
located in the wp_profile_root/ConfigEngine directory, to enable the distinguished name login.
Note: After running this task to enable the full distinguished name login, you can run the
./ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=password task to disable
the feature.
15. Optional: Run the Member Fixer task to update the member names used by Web Content Manager
Note: This step is only needed if you have installed the product with Web Content Manager and
intend to use the Intranet and Internet Site Templates that were optionally installed with the product
by running the configure-express task.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Installing 257
Internet libraries.
18. Optional: This step is required in a production environment. Before removing the file system
repository, complete the following steps to replace the WebSphere Application Server and WebSphere
Portal administrator user ID and administrative group ID with users and groups that exist in the
LDAP user registry:
Important:
v Before changing the user ID and password, review Special characters in user ID and passwords
located under Planning for WebSphere Portal.
v Ensure the new user ID of the WebSphere Application Server administrator is not identical to the
one that you are replacing. Duplicate user IDs cause authentication problems with the WebSphere
Integrated Solutions Console.
Note: If you run these tasks after you create your cluster, you must run them on all nodes in the
cluster.
a. Run the following task from the wp_profile_root/ConfigEngine directory: ./ConfigEngine.sh
wp-change-was-admin-user -DWasUser=adminid -DWasPassword=password
-DnewAdminId=newadminid -DnewAdminPw=newpassword
Important: You must provide the full distinguished name (DN) for the newAdminId parameter.
b. Verify that the task completed successfully. Stop and restart all required servers.
c. Run the following task from the wp_profile_root/ConfigEngine directory: ./ConfigEngine.sh
wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid
-DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid
Important: You must provide the full distinguished name (DN) for the newAdminId and
newAdminGroupId parameters.
Additional parameter for stopped servers: This task verifies the user against a running server
instance. If the server is stopped, add the -Dskip.ldap.validation=true parameter to the task to
skip the validation.
d. Update the SearchAdminUser alias to match your WebSphere Portal administrator information.
See the related links for information.
e. Verify that the task completed successfully. Stop and restart all required servers.
19. Optional: This step is required in a production environment. Remove the file system repository if
you do not use it. The federated file system user repository that was the default security setting
might not be required after federating the user repository. If the file system repository is no longer
needed, removing it can help prevent conflicts created by duplicate user identities existing in
multiple repositories. See the following topic under Related information for instructions: Deleting the
repository, which is listed with the appropriate operating system.
Related tasks:
AIX stand-alone: Adapting the attribute configuration on page 270
Deleting the repository on AIX on page 3099
If you have made changes to your company and no longer require the use of a repository within your
default federated repository, you can delete the repository from your configuration.
AIX stand-alone: Adding an LDAP user registry over SSL:
Add an LDAP user registry over SSL to the default federated repository to store user account information
for secure authorization. You can add multiple LDAP user registries to the default federated repository
although you can only add one LDAP server at a time.
Complete the following steps to add an LDAP user registry over SSL to the default federated repository;
you must repeat these steps for each additional LDAP user registry that you plan to add:
Installing 259
federated.ldap.id
federated.ldap.host
federated.ldap.port
federated.ldap.sslEnabled
federated.ldap.sslConfiguration
federated.ldap.sslEnabled parameter to true.
federated.ldap.certificateMapMode
federated.ldap.certificateFilter
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
Installing 261
attributes.
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 263
Related tasks:
User IDs and passwords on page 34
Deleting the repository on AIX on page 3099
AIX stand-alone: Adding a database user registry:
Add a database user registry to the default federated repository to store user account information for
authentication and authorization. You can add multiple database user registries to the default federated
repository although you can only add one database user registry at a time.
Complete the following steps to add a database user registry to the default federated repository; you
must repeat these steps for each additional database user registry that you plan to add:
Note: Use the wp_add_DB.properties helper file, located in the wp_profile_root/ConfigEngine/config/
helpers directory, when completing this task to ensure the correct properties are entered. In the following
instructions, where the step refers to the wkplc.properties file, use your wp_add_DB.properties helper
file.
2. Set up a new database, including creating a new user with appropriate database privileges for
accessing the database:
Instructions for setting up databases: Refer to the appropriate documentation for the type of
database you want to set up.
Consulting your database administrator: A database administrator typically completes the task of
setting up a new database. However, the following steps are provided for your reference in the event
you are creating a stand-alone database for testing or demonstration purposes. Consult your
database administrator before proceeding with the following steps if you plan to create a database
for a production environment.
Table 127. Steps for creating a database to use as a database user registry.
Database Steps
DB2 Complete the following steps to create a DB2 database:
1. Install DB2.
2. Enter the following database tuning commands:
Oracle Complete the following steps to create an Oracle database:
1. Install Oracle using UNICODE Database and National character sets such as UTF8, AL32UTF8, or AL16UTF16.
2. Configure the database in Dedicated Server Mode.
3. Enter the recommended initial buffer pool sizes or set them according to your business needs:
db_block_size = 8192
db_cache_size = 300M
db_files = 1024
log_buffer = 65536
open_cursors = 1500 open_cursors = 1500
pga_aggregate_target = 200M
pre_page_sga = true
processes = 300
shared_pool_size = 200M
SQL Server Complete the following steps to create an SQL Server database:
1. Install SQL Server.
2. Set Collation to case-sensitive.
Note: Install SQL Server with the appropriate portal database collation so that your tempdb collation setting matches
the collation you use for the property extension database. The tempdb collation is inherited from the master database,
which you set when you install SQL Server.
3. Complete the following steps to define the DbDriver and DbLibrary parameter values:
Installing 265
a. Go to the following directory: wp_profile_root/ConfigEngine/properties
b. Locate and open wkplc_dbtype.properties with any text editor.
c. Enter a value for the following parameters under the appropriate database type properties
heading:
db_type.DbDriver
db_type.DbLibrary
d. Save your changes.
5. Enter a value for the following required parameters in the wkplc.properties file under the VMM
Federated Database Properties heading:
federated.db.DataSourceName
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbPassword
federated.db.DbName
6. Change the value for the com.ibm.SOAP.requestTimeout parameter to 1000.
a. Navigate to the following directory: wp_profile_root/properties
b. Locate and open soap.client.props with any text editor.
c. Locate the com.ibm.SOAP.requestTimeout parameter and ensure the value is greater than 1000.
d. Save and close soap.client.props.
7. Complete the following steps in a clustered environment:
a. Run the ./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password
-DDbDomain=federated.db -Ddb_type.DmgrDbLibrary=local path of the database jars on the
Deployment Manager -DDmgrNodeName=dmgr_node_name task from the wp_profile_root/ConfigEngine
directory to create the local Deployment Manager WebSphere variable used to access the
database jars.
Note: The db_type in db_type.DmgrDbLibrary should be set to the type of database you are using,
for example db2. The local full path of the database jars on the Deployment Manager should be one of
the following options:
DB2 Type 2 driver: db2java.zip
DB2 Type 4 driver: db2jcc4.jar;db2jcc_license_cu.jar
DB2 for z/OS Type 2 driver: db2java.zip
DB2 for z/OS Type 4 driver: db2jcc4.jar;db2jcc_license_cisuz.jar
Oracle: ojdbc14.jar
SQL Server JDBC driver provided by Microsoft: sqljdbc.jar
b. Run the following task. Include each node name as a comma separated list in the command:
Running the task: You do not have to run this task more than once. You can run this task from
any node in the cluster.
1) Set the property value for federated.db.DbType in the wkplc.properties file if using a
database user registry or if the cell is migrated from a previous version.
2) Run the ./ConfigEngine.sh wp-node-prep-vmm-db-secured-environment
-DWasPassword=password -DDbDomain=federated.db -DVmmNodeName=node_name
-Ddb_type.NodeDbLibrary=local full path of the database jars task from the
wp_profile_root/ConfigEngine directory on each node to create the variable used to access the
VMM database jars.
Note: VmmNodeName is a list of one or more WebSphere Portal nodes names in the cell which
share the same database driver paths. The db_type in db_type.NodeDbLibrary should be set to
the type of database you are using, for example db2.
c. Stop and restart all necessary servers to propagate your changes.
8. Run the ./ConfigEngine.sh wp-create-db -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to add a database user registry to the default federated
repository.
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Installing 267
Related tasks:
AIX stand-alone: Adding realm support:
A realm is a group of users from one or more user registries that form a coherent group within IBM
WebSphere Portal. Realms allow flexible user management with various configuration options. A realm
must be mapped to a Virtual Portal to allow the defined users to log in to the Virtual Portal. When
configuring realm support, complete these steps for each base entry that exists in your LDAP and/or
database user registry to create multiple realm support.
Before configuring realm support, you must add all LDAP user registries and/or database user registries,
that you will use to create a single realm or multiple realms, to the federated repository. If you are going
to create multiple realms, you must create all required base entries within your LDAP user registries
and/or database user registries. All base entry names must be unique within the federated repository.
Complete the following steps to add realm support to your user registry model:
VMM realm configuration heading:
realmName
securityUse
delimiter
addBaseEntry
5. Run the ./ConfigEngine.sh wp-create-realm -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to add a new realm to the Virtual Member Manager
configuration.
Important: To create multiple realms, ensure that your federated repository contains the required
unique base entries. Stop and restart the appropriate servers for your installation environment, and
then update the wkplc.properties file with the base entry information and rerun the
wp-create-realm task. Repeat these steps until all realms are created.
realm configuration heading and then save your changes:
realmName
realm.personAccountParent
realm.groupParent
realm.orgContainerParent
8. Run the ./ConfigEngine.sh wp-modify-realm-defaultparents -DWasPassword=password task, from
the wp_profile_root/ConfigEngine directory, to update the default parents per entity type and realm.
Important: Stop and restart the appropriate servers for your installation environment before
rerunning this task for any additional entity types and realms.
10. Optional: Complete the following steps to add additional base entries to the realm configuration; for
example, if you have two additional base entries (base entry 1 and base entry 2) to add to the realm
you just created, you need to update the wkplc.properties file with the information from base entry
1 and then run this task. Then update the properties file with the information for base entry 2 and
then run this task:
realm configuration heading:
parameters.
realmName
addBaseEntry
d. Run the ./ConfigEngine.sh wp-add-realm-baseentry -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to add additional LDAP base entries to the realm
configuration.
11. Optional: Complete the following steps to replace the WebSphere Application Server and WebSphere
Portal administrator user ID; this step is required if you change the default realm:
a. Create a new user in the Manage Users and Groups portlet to replace the current WebSphere
Application Server administrative user.
b. Create a new user in the Manage Users and Groups portlet to replace the current WebSphere
Portal administrative user.
c. Create a new group in the Manage Users and Groups portlet to replace the current group.
d. Run the ./ConfigEngine.sh wp-change-was-admin-user -DWasUser=adminid
-DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword
-DnewAdminGroupId=newadmingroupid task, from the wp_profile_root/ConfigEngine directory, to
replace the old WebSphere Application Server administrative user ID and group ID with the new
user and group.
Installing 269
f. Run the ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password
-DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid task to
replace the old WebSphere Portal administrative user ID and group ID with the new user and
group.
g. Verify that the task completed successfully. Stop and restart all required servers.
12. Optional: Complete the following steps to set the realm you created as the default realm:
Remember: Only users defined in base entries that exist in the default realm are able to log into
WebSphere Portal. If you find that a user cannot log in to WebSphere Portal, check to see if the base
entry that contains the user exists in the default realm. You can run the wp-query-realm-baseentry
task to see what base entries are part of the default realm. If the default realm is missing the base
entry, run the wp-add-realm-baseentry task to add the base entry to the default realm.
b. For defaultRealmName, type the realmName property value you want to use as the default realm.
d. Run the ./ConfigEngine.sh wp-default-realm -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to set this realm as the default realm.
13. Optional: Complete the following steps to query a realm for a list of its base entries:
b. For realmName, type the name of the realm you want to query.
d. Run the ./ConfigEngine.sh wp-query-realm-baseentry -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to list the base entries for a specific realm.
the feature.
AIX stand-alone: Adapting the attribute configuration:
After installation, IBM WebSphere Portal has a predefined set of attributes for users and groups. Your
LDAP server may have a different set of predefined user and group attributes. To ensure proper
communication between WebSphere Portal and your LDAP server, you can configure additional attributes
and flag existing attributes as required or unsupported on a per repository basis or for all configure
repositories.
LDAP servers can only handle attributes that are explicitly defined in their schema. The LDAP server's
schema is different from the WebSphere Portal schema but the two schemas should match for proper
communication between WebSphere Portal and the LDAP server. The task to add the LDAP user registry
does some basic attribute configurations depending on the type of LDAP server that you choose. You
may, however, still need to adapt the WebSphere Portal configuration to match the LDAP schema; for
example, if an attribute is defined in WebSphere Portal but not in the LDAP server, you will need to
perform one of the following tasks to resolve this mismatch
v Flag the attribute as unsupported for the LDAP server
v Introduce an attribute mapping that maps the WebSphere Portal attribute to an attribute defined in the
LDAP schema
Perform the following tasks to adapt the attribute configuration to match the configured LDAP server(s)
and your business needs:
Related tasks:
AIX stand-alone: Preparing user registries on page 242
AIX stand-alone: Adding an LDAP user registry without SSL on page 254
AIX stand-alone: Querying the defined attributes:
After installing IBM WebSphere Portal and configuring your LDAP user registries, you can query the
defined attributes to see what attributes are flagged as unsupported or if the attribute is mapped to a
different LDAP attribute.
Run the ./ConfigEngine.sh wp-query-attribute-config -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, any time during the configuration process or at runtime to query
an overview of the currently defined attributes. This task creates the availableAttributes.html report,
located in the wp_profile_root/ConfigEngine/log directory. The report contains one table that lists the
available attributes for Users (PersonAccount) and one table that lists the available attributes for Groups.
For each configured repository there is a column that indicates if the attribute is flagged as unsupported
or if the attribute is mapped to a different LDAP attribute.
Note: This task does not validate the existence of attributes in the LDAP schema.
AIX stand-alone: Adding attributes:
Installing 271
The VMM is configured with a default attribute schema that might not be compatible with your LDAP
server. If this is the case, extend the VMM attribute schema by adding new attributes that you can map
between IBM WebSphere Portal and your user registry.
Complete the following steps to add new attributes to your user registry:
2. Complete the following steps to install the required Enterprise Archive (.ear) file on WebSphere
Application Server.
a. Open a command prompt.
b. Go to the wp_profile_root/ConfigEngine directory.
c. Run the ./ConfigEngine.sh wp-la-install-ear -DWasPassword=password task.
Property Extension Properties heading:
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
7. Run the ./ConfigEngine.sh wp-add-property -DWasPassword=password task to add the attribute to the
user registry.
Note: This task calls an EJB to WebSphere Application Server, which must authenticate against
WebSphere Application Server. Depending on the configuration in the sas.client.props file, you may
receive a popup window or a command line prompt asking for user identity and password. Enter the
WebSphere Application Server user ID and password.
Remember: If you have multiple properties to add, repeat all steps, except for the wp-la-install-ear
task, until all new attributes are added.
Related tasks:
AIX stand-alone: Mapping attributes:
After you install and configure your LDAP user registry and query the defined attributes, you can map
the attributes so they match the configured LDAP servers and your business needs.
Complete the following steps to map attributes between WebSphere Portal and your LDAP server; if you
have multiple LDAP servers, complete these steps for each LDAP server:
2. Enter a value for one of the following sets of parameters in the wkplc.properties file to identify
your LDAP server:
Note: Make sure you use the same values you used to configure your LDAP server.
Table 128. Identifying your LDAP server in the wkplc.properties file.
Repository type Parameters
Stand-alone The following parameters are found under the LDAP
attribute configuration heading:
Note: See the properties file for specific information
about the required and advanced parameters.
standalone.ldap.id
Federated The following parameters are found under the VMM
Federated repository properties heading:
federated.ldap.id
federated.ldap.host
federated.ldap.port
3. Run one of the following tasks to check that all defined attributes are available in the configured
LDAP user registry:
Table 129. Task to check that all defined attributes are available in the configured LDAP user registry.
Repository type Task
Stand-alone ./ConfigEngine.sh wp-validate-standalone-ldap-
attribute-config -DWasPassword=password task, from
the wp_profile_root/ConfigEngine directory.
Federated ./ConfigEngine.sh wp-validate-federated-ldap-
4. Open the ConfigTrace.log file, located in the wp_profile_root\ConfigEngine\log directory, to review
the following output for the PersonAccount and Group entity type:
The following attributes are defined in WebSphere Portal but not in the LDAP server
This list contains all attributes that are defined in WebSphere Portal but not available in the
LDAP. Flag attributes that you do not plan to use in WebSphere Portal as unsupported. Map
Installing 273
the attributes that you plan to use to the attributes that exist in the LDAP; you must also
map the uid, cn, firstName, sn, preferredLanguage, and ibm-primaryEmail attributes if they
are contained in the list.
The following attributes are flagged as required in the LDAP server but not in WebSphere Portal
This list contains all attributes that are defined as "MUST" in the LDAP server but not as
required in WebSphere Portal. You should flag these attributes as required within WebSphere
Portal; see the following step about flagging an attribute as either unsupported or required.
The following attributes have a different type in WebSphere Portal and in the LDAP server
This list contains all attributes that WebSphere Portal might ignore because the data type
within WebSphere Portal and within the LDAP server do not match.
6. Enter a value for one of the following sets of parameters in the wkplc.properties file to correct any
issues found in the config trace file:
Table 130. Parameters to define in the wkplc.properties file to correct any issues found in the config trace file.
Stand-alone The following parameters are found under the LDAP attribute configuration heading:
parameters.
standalone.ldap.id
standalone.ldap.attributes.nonSupported
standalone.ldap.attributes.nonSupported.delete
standalone.ldap.attributes.mapping.ldapName
standalone.ldap.attributes.mapping.portalName
standalone.ldap.attributes.mapping.entityTypes
For example, the following values flag certificate and members as unsupported
attributes and map ibm-primaryEmail to mail and ibm-jobTitle to title for both the
PersonAccount and Group entityTypes:
standalone.ldap.attributes.nonSupported=certificate, members
standalone.ldap.attributes.nonSupported.delete=
standalone.ldap.attributes.mapping.ldapName=mail, title
standalone.ldap.attributes.mapping.portalName=ibm-primaryEmail, ibm-jobTitle
standalone.ldap.attributes.mapping.entityTypes=PersonAccount, Group
Table 130. Parameters to define in the wkplc.properties file to correct any issues found in the config trace
file. (continued)
Federated The following parameters are found under the VMM Federated repository properties
heading:
parameters.
federated.ldap.attributes.nonSupported
federated.ldap.attributes.nonSupported.delete
federated.ldap.attributes.mapping.ldapName
federated.ldap.attributes.mapping.portalName
federated.ldap.attributes.mapping.entityTypes
federated.ldap.attributes.nonSupported=certificate, members
federated.ldap.attributes.nonSupported.delete=
federated.ldap.attributes.mapping.ldapName=mail, title
federated.ldap.attributes.mapping.portalName=ibm-primaryEmail, ibm-jobTitle
federated.ldap.attributes.mapping.entityTypes=PersonAccount, Group
8. Run one of the following tasks to update the LDAP user registry configuration with the list of
unsupported attributes and the proper mapping between WebSphere Portal and the LDAP user
registry:
Table 131. Task to update the LDAP user registry configuration with the list of unsupported attributes and the proper
mapping between Portal and the LDAP user registry.
Stand-alone ./ConfigEngine.sh wp-update-standalone-ldap-
the wp_profile_root/ConfigEngine directory
Federated ./ConfigEngine.sh wp-update-federated-ldap-
10. Optional: Complete the following steps to flag an attribute as either unsupported or required for the
entire WebSphere Portal environment instead of just for the specified LDAP:
a. Enter a value for the following required parameters in the wkplc.properties file:
parameters.
user.attributes.required
user.attributes.nonsupported
b. Save your changes to the wkplc.properties file.
c. Run the ./ConfigEngine.sh wp-update-attribute-config -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory.
d. Stop and restart all necessary servers to propagate your changes.
Installing 275
Related tasks:
AIX stand-alone: Querying the defined attributes on page 271
AIX stand-alone: Removing attributes:
Due to a Virtual Member Manager (VMM) limitation, there is currently no task to update an attribute.
Therefore, if you added an attribute to your property extension database or when adapting attributes to
match your LDAP server that were spelled incorrectly or already added due to migration, you must
remove the attribute from the database. Use caution when performing these steps.
Perform the following steps to remove an attribute from your database:
Important: Do not remove attributes that have already been populated with user values because this can
cause database inconsistencies.
Cluster note: In a clustered environment, complete the following steps on the deployment manager and
then resynch the nodes.
2. Complete the following steps to remove an attribute stored in a property extension database:
a. Open the tool you use to edit your database.
b. Verify that your attribute name is available in the LAPROP table.
c. Delete the required attributes from the LAPROP table.
d. Open the wimxmlextension.xml file, located in the wp_profile_root/config/cells/cellname/wim/
model directory.
e. Locate and delete the propertySchema definition for the attributes that you deleted from the
LAPROP table; for example:
<wim:propertySchema nsURI="http://www.ibm.com/websphere/wim" dataType="String"
multiValued="true" propertyName="attribute_name">
<wim:applicableEntityTypeNames>PersonAccount</wim:applicableEntityTypeNames>
</wim:propertySchema>
f. Save your changes to the wimxmlextension.xml file.
g. Open the wimconfig.xml file, located in the wp_profile_root/config/cells/cellname/wim/config
directory.
h. Locate and delete the attributes or propertiesNotSupported definitions for the attributes that you
deleted from the LAPROP table. For example:
<config:attributes name="attribute_name" propertyName="attribute_name">
<config:entityTypes> PersonAccount </config:entityTypes>
<config:entityTypes> Group </config:entityTypes>
</config:attributes>
or
<config:propertiesNotSupported name="attribute_name">
i. Save your changes to the wimconfig.xml file.
j. Stop and restart the WebSphere_Portal server from the wp_profile_root/bin directory.
3. Complete the following steps to remove an attribute that is not stored in a property extension
database:
a. Open the wimxmlextension.xml file.
b. Locate and delete the propertySchema definition for the attributes you previously added:
c. Save your changes to the wimxmlextension.xml file.
d. Open the wimconfig.xml file.
e. Locate and delete the stanza that corresponds to the custom attribute you deleted from the
wimextension.xml file; for example:
<config:attributes name="attribute_name" propertyName="property_name">
<config:entityTypes>PersonAccount</config:entityTypes>
f. Save your changes to the wimconfig.xml file.
g. Stop and restart the WebSphere_Portal server.
Related tasks:
AIX stand-alone: Querying the defined attributes on page 271
AIX stand-alone: Adding attributes on page 271
AIX stand-alone: Configuring Portal to use dynamic groups:
By default, WebSphere Portal is enabled for static groups. However, the Virtual Member Manager (VMM)
allows users to be members of either static or dynamic groups. Static groups are those where a persistent
binding exists between a group and its members. Dynamic groups are those where a search query is
defined to retrieve the members of a group. If you have your LDAP server configured to use dynamic
groups, complete the steps in this task for WebSphere Portal to use dynamic group queries when you
setup your LDAP server.
Perform the required tasks to configure either a stand-alone or federated LDAP server security.
The steps in this task use groupOfURLs as the object class for dynamic groups and memberURL as the
dynamic membership attribute. The actual values for object classes and dynamic membership attributes
can vary depending on your LDAP server. For this reason, you should export an LDIF file to verify the
object classes and dynamic membership attributes. Either refer to your LDAP documentation or ask your
LDAP administrator for instructions on exporting an LDIF file.
Clustered environments: Perform the following steps on the Deployment Manager then synchronize the
nodes.
To configure WebSphere Portal to use dynamic groups, do the following:
1. If you are using a Stand-alone LDAP server, follow these steps.
a. Navigate to the following directory: wp_profile_root/cells/cell_name/wim/config.
b. Locate and open wimconfig.xml with any text editor.
c. Add the following line to the <config:groupConfiguration> tag:
<config:dynamicMemberAttributes name="memberurl" objectClass="groupofurls"/>
d. Save and close wimconfig.xml.
2. If you are using a Federated LDAP server, follow these steps.
b. Select Security > Global security.
Installing 277
c. In Available realm definitions, select Federated repositories and click Configure.
d. In Related Items, click Manage repositories.
e. Select the appropriate repository from the list.
f. In Additional Properties, click Group attribute definition then click Dynamic member attributes.
g. Click New and specify values for the Name and Object class fields as appropriate. For example,
v Name: memberurl
v Object class: groupofurls
h. Click OK and save the changes to the master configuration.
Related tasks:
AIX stand-alone: Choosing your user registry model on page 247
AIX stand-alone: Enabling referrals for your LDAP user registry:
Referrals redirect object requests from one LDAP server to another when objects do not exist or cannot be
located in a particular directory tree. You should enable referrals if your environment has more than one
user registry existing on multiple servers or domains.
Complete the following steps to configure your portal to use LDAP referrals:
2. Open a UNIX System Services (USS) command prompt.
Note: If you are instructed to open a properties file, please note that the files are ASCII files and
should be opened using the appropriate tool.
3. Use any text editor to open the wkplc.properties file in the following directory: wp_profile_root/
ConfigEngine/properties.
4. Specify values for the following parameters:
v et.ldap.id=ID_of_your_LDAP_server
v et.ldap.host=hostname_of_your_LDAP_server
v et.ldap.referral=follow
5. Save and close wkplc.properties.
6. Run the following task from the wp_profile_root/ConfigEngine directory to create an LDAP entity type:
AIX Solaris Linux: ./ConfigEngine.sh wp-update-et-ldap -DWasPassword=password
Windows: ConfigEngine.bat wp-update-et-ldap -DWasPassword=password
IBM i: ConfigEngine.sh wp-update-et-ldap -DWasPassword=password
z/OS: ./ConfigEngine.sh wp-update-et-ldap -DWasPassword=password
Related tasks:
AIX stand-alone: Choosing your user registry model on page 247
AIX stand-alone: Adapting the attribute configuration on page 270
AIX stand-alone: Tune your servers
Tuning the servers is important to the performance of your WebSphere Portal environment. WebSphere
Portal is not tuned for a production environment out of the box, so to ensure optimal performance,
review and complete the steps in the IBM WebSphere Portal Tuning Guide. Even if a tuning guide is not
available for the current release of WebSphere Portal, the tuning guide for the previous product version
should be used.
Tuning a WebSphere Portal environment involves tuning and configuring the various systems and
components of the environment. The tuning guide provides general concepts and details specifics
configuration instructions. Instructions are included for:
v Configuring the application server and the resources defined for that application server
v Determining the cloning strategy for expanding or extending the environment
v Tuning the database(s) and database server
v Tuning the directory server and its database
v Tuning the Web server
v Tuning the operating system and network
v Tuning the WebSphere Portal services
Installing 279
Related tasks:
authentication.
AIX stand-alone: Configuring Portal to use a database on page 156
AIX stand-alone: Preparing a remote Web server on page 240
Setting up a cluster on AIX
dynamic.
The following illustration depicts a horizontal cluster configuration where WebSphere Portal is installed
on multiple servers or on multiple profiles within the same physical server. The multiple servers
configuration reduces single points of failure, but requires more hardware, such as additional servers. The
multiple profiles configuration also reduces single points of failure; it requires less additional hardware
than the multiple servers configuration but you may still need more hardware such as additional
memory. The deployment manager manages a cell for horizontal cluster nodes.
To conserve hardware, you can also set up vertical cluster members on a single node. Typically, large
portal clusters include both horizontal and vertical scaling; for instance, you may have four portal nodes
and each of those nodes may contain five cluster members for a total of twenty cluster members.
Installing 281
In response to customer requests, the instructions to setup WebSphere Portal has been improved to
provide operating system specific instructions for setting up a production environment. Select your
operating system to get started.
Preparing your AIX operating system in a clustered environment
Complete the following steps to prepare your AIX server:
1. Set the file descriptor limit to 10240; for example, ulimit -n 10240.
3. Web Content Manager only: Use the ulimit -f command to set the maximum size of files that can
be created to be at least the size of the largest file you would need to upload to the content server.
The command ulimit -f unlimited removes any limit on file size.
4. Install and configure X server on AIX (for example X-Windows or GNOME) to use the graphical user
interface the installation program provides.
Related tasks:
com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_aixsetup.html
Preparing the primary node on AIX
Before creating your clustered environment, you must install IBM WebSphere Portal on your primary
node and then configure your database and your network deployment manager.
Complete the following tasks to prepare your primary node:
Installing WebSphere Portal on AIX on the primary node:
storing information. After installation, you can expand your environment to include high availability
failover, a more robust database, and LDAP-based authentication.
Related concepts:
Related tasks:
Creating a Portal custom profile on AIX on page 1689
Custom profiles do not contain any servers or applications; they are used as run time environments to
create additional cluster members. After creating the profile, the node must be federated into an existing
cell. The portal server is added when you add the additional nodes to an existing cluster.
Preparing the system for multiple profile support on AIX on page 1686
IBM WebSphere Portal provides several profile templates that you can use to create a new WebSphere
Portal profile or to augment an existing profile with WebSphere Portal. To use these profile templates,
you must first run the enable-profiles task to configure the profile templates, register these templates
with IBM WebSphere Application Server, and save the current WebSphere Portal baseline configuration.
The baseline configuration is provided in the form of a configuration archive (CAR) that is created by
exporting the contents of an existing profile. You can create the CAR any time, such as immediately after
the initial installation or after the original portal is fully configured with security, database, basic
application deployment, and server tuning.
Clustered environment: Installing with the Installation Manager on AIX:
You can use the IBM Installation Manager to install IBM WebSphere Portal and IBM WebSphere
Application Server in a clustered environment. The IBM Installation Manager gathers essential
options:
Installing 283
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
click OK.
stored.
e. Select Apply.
f. Select OK.
checked to create a new Portal server profile. This profile is used as the primary node for the cluster.
There is also an option to create a local Deployment Manager profile. Only select this option in a test
environment where you want to automate the process of creating a local Deployment Manager profile.
Expand the WebSphere Portal package and select the Deployment Manager Profile augmented with
WebSphere Portal check box. Then on the Install Packages panel: Configuration details panel, click
Dmgr Profile configuration details and enter the appropriate information for your Deployment
Manager.
b. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
Installing 285
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
l. Click Next.
page 2197.
Clustered environment: Installing with the response file on AIX:
First you must install IBM Installation Manager. Then use a response file to install IBM WebSphere Portal
and IBM WebSphere Application Server in a clustered environment. Record a response file on the same
options:
Advantage):
Replace with
Installing 287
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
response file:
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
Installing 289
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
k. On the Install Packages: Configuration panel, select the type of profile template to install: Full,
Base, or Custom.
l. Click Profile configuration details.
m. On the Profile configuration details panel, select either the Standard or Advanced configuration
n. Click Next.
o. Confirm the information on the Summary panel and then click Install.
p. After the Installation Manager finishes creating the response file, click Finish and then close the
q. If installing on a different computer, copy the response file to the response file directory on that
computer.
[ -useSocks ] ]
[ -verbose ]
Clustered environment: Performing post-installation tasks on AIX:
configure your clustered environment.
Installing 291
> Users and Groups.
Libraries.
LDAP configuration.
AIX cluster: Configuring Portal to use a database:
For high availability, using a remote database is preferred. For improved performance databases can be
distributed across multiple database servers. Databases should also be configured for failover.
Configuring the database for failover is beyond the scope of this documentation. Refer to the database
product documentation for the most authoritative guidance about setting up databases for fail over.
Refer to the following password considerations when transferring data manually:
For security reasons, you should not store passwords in the wkplc.properties and
wkplc_dbdomain.properties. Edit each of the properties files prior to running a configuration task,
inserting the passwords needed for that task. After the task has run, delete all passwords from each file.
For more information, see Deleting passwords from property files.
Alternatively, you can specify the password on the command line using the following syntax:
Windows:ConfigEngine.bat task_name -Dpassword_property_key=password_value
UNIX: ./ConfigEngine.sh task_name -Dpassword_property_key=password_value
IBM i: ConfigEngine.sh task_name -Dpassword_property_key=password_value
As with other properties, each password property must have the -D prefix and be set equal to (=) a value.
If you have multiple properties in a single command, use a space character between each
-Dproperty=value setting.
Remember: Install the database drivers under the wp_profile_root directory so the drivers will
automatically be copied to the additional cluster node profiles.
Related tasks:
Installing WebSphere Portal on AIX on the primary node on page 282
AIX clustered server: Setting up a DB2 database:
AIX clustered server: Installing DB2:
Before you begin:
required databases.
Note:
Installing 293
Related tasks:
AIX clustered server: Modifying DB2 database properties:
You must modify the approriate properties files before transferring your data from the default database
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 295
driver class.
AIX clustered server: Creating groups and assigning users:
Related tasks:
AIX clustered server: Installing DB2 on page 293
AIX clustered server: Creating DB2 databases:
databases manually.
Related tasks:
AIX clustered server: Modifying DB2 database properties on page 294
AIX clustered server: Creating a local DB2 database automatically:
AIX clustered server: Creating a remote or local DB2 database manually:
Installing 297
running.
instance owner.
that you run:
Notes:
six times.
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
AIX clustered server: Setting up DB2 automatically or manually:
Installing 299
Related tasks:
AIX clustered server: Creating groups and assigning users on page 296
AIX clustered server: Running a task to automatically setup DB2 databases:
AIX clustered server: Setting up DB2 manually:
AIX clustered server: Creating DB2 database schemas:
users
admins
guests
public
local
IBM
SQL
SYS
environment.
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
AIX clustered server: Granting privileges to DB2 database users:
Installing 301
database user:
users
users (continued)
Installing 303
Installing 305
Related concepts:
AIX clustered server: Assigning custom DB2 table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
AIX clustered server: Configuring JCR collation support:
for instructions.
server:
b. Run the command:
using password.
# English
Installing 307
# Swedish
Related tasks:
AIX clustered server: Creating DB2 databases on page 297
databases manually.
AIX clustered server: Configuring Portal to use DB2:
database. Follow these steps to transfer Portal and Java Content Repository databases to DB2. As an
Before you begin:
Tips:
Repository schema.
Note:
files:
name are the same.
Installing 309
using password
db2 terminate
-p password
Related tasks:
databases manually.
AIX clustered server: Setting up DB2 automatically or manually on page 299
AIX clustered server: Enabling DB2 pureScale load balancing feature:
6. Click OK.
Installing 311
Related tasks:
databases manually.
AIX clustered server: Configuring DB2 for large file handling in WCM:
Related tasks:
databases manually.
AIX clustered server: Configuring Portal to use DB2 on page 308
AIX clustered server: Type 2 driver support:
Installing 313
Related tasks:
databases manually.
AIX clustered server: Configuring Portal to use DB2 on page 308
AIX clustered server: Enabling DB2 pureScale load balancing feature on page 311
AIX clustered server: Changing DB2 driver types:
configuration task.
Note:
JDBC driver.
AIX clustered server: Configuring Type 2 DB2 drivers:
Installing DB2
name.
Installing 315
file.
Portal.
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
n. For dbdomain.XDbName, type the database loop back alias that needs to be set if you plan to use
the create-database task.
o. For dbdomain.DbNode, type the value for the database node name. Set this value if you want to
driver class.
instance owner.
Installing 317
that you run:
Notes:
of six times.
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
domain.
Installing 319
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Note:
files:
name are the same.
using password
Installing 321
db2 terminate
-p password
AIX clustered server: Setting up a remote IBM DB2 for i:
View information on installing and setting up IBM DB2 for i to work with WebSphere Portal.
AIX clustered server: Modifying IBM DB2 for i database properties:
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
- question mark (?)
Notes:
Installing 323
IBM DB2 for i.
server.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
AIX clustered server: Creating groups and assigning users for IBM DB2 for i:
Installing 325
Note:
database transfer.
AIX clustered server: Creating IBM DB2 for i user profiles:
Before you begin:
can be shared.
new password.
environment.
Related tasks:
AIX clustered server: Modifying IBM DB2 for i database properties on page 322
AIX clustered server: Creating and setting up IBM DB2 for i databases automatically:
Related tasks:
AIX clustered server: Creating groups and assigning users for IBM DB2 for i on page 325
AIX clustered server: Granting privileges to IBM DB2 for i database users:
create-database
database user:
Installing 327
tasks:
create-database
Related concepts:
Related tasks:
AIX clustered server: Creating IBM DB2 for i user profiles on page 326
AIX clustered server: Transferring IBM DB2 for i manually:
Installing 329
Before you begin:
the task to stall.
Note:
Related tasks:
AIX clustered server: Creating and setting up IBM DB2 for i databases automatically on page 326
AIX clustered server: Verifying IBM DB2 for i database connections:
Installing 331
Related tasks:
AIX clustered server: Creating and setting up IBM DB2 for i databases automatically on page 326
AIX clustered server: Granting privileges to IBM DB2 for i database users on page 327
AIX clustered server: Setting up a remote DB2 for z/OS:
View information on installing and setting up DB2 for z/OS to work with WebSphere Portal.
AIX clustered server: Installing DB2 for z/OS:
following commands:
following commands:
export EXTSHM=ON
db2start
profile.env file:
DB2ENVLIST=EXTSHM
export EXTSHM=ON
remote database.
AIX clustered server: Modifying DB2 for z/OS database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Installing 333
understand.
Note:
for the domain.
DbName.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
this value.
driver class.
AIX clustered server: Using JCL templates to set up DB2 for z/OS:
Installing 335
created.
successfully.
authority.
on the database
authority.
Related tasks:
AIX clustered server: Installing DB2 for z/OS on page 332
AIX clustered server: Creating DB2 for z/OS users:
installation.
Installing 337
(R) - at runtime
where:
data.
Related tasks:
AIX clustered server: Modifying DB2 for z/OS database properties on page 333
AIX clustered server: Creating remote DB2 for z/OS databases:
machine.
the databases.
500 DEFINE NO;
Installing 339
Related tasks:
AIX clustered server: Using JCL templates to set up DB2 for z/OS on page 335
AIX clustered server: Granting privileges to DB2 for z/OS database administration users:
database user:
Installing 341
Related concepts:
Related tasks:
AIX clustered server: Creating DB2 for z/OS users on page 337
AIX clustered server: Assigning custom DB2 for z/OS table spaces:
Before you begin:
PADIX=NO, or both.
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Installing 343
Related tasks:
AIX clustered server: Creating remote DB2 for z/OS databases on page 339
AIX clustered server: Configuring Portal to use DB2 for z/OS:
Before you begin:
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 345
...
Related tasks:
AIX clustered server: Creating remote DB2 for z/OS databases on page 339
AIX clustered server: Granting privileges to DB2 for z/OS database administration users on page 340
AIX clustered server: Setting up an Oracle or Oracle RAC database:
AIX clustered server: Installing Oracle or Oracle RAC:
Before you begin:
Considerations:
LIBPATH=/u01/app/oracle/product/11.2.0/client_1;export LIBPATH
$ gsdctl start
$ lsnrctl start
$ agentctl start
AIX clustered server: Modifying Oracle or Oracle RAC database properties:
to the Oracle or Oracle Rac database.
jcr.DbName=jcrdb
Installing 347
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
Installing 349
class.
AIX clustered server: Creating Oracle or Oracle RAC databases:
information:
Server Mode.
pre_page_sga = true
as follows:
FORCE
EXACT
AIX clustered server: Setting up Oracle or Oracle RAC automatically or manually:
Note:
database.
Related tasks:
AIX clustered server: Modifying Oracle or Oracle RAC database properties on page 347
AIX clustered server: Running a task to automatically setup Oracle or Oracle RAC databases:
Installing 351
privileges.
Note:
AIX clustered server: Setting up Oracle or Oracle RAC manually:
AIX clustered server: Creating Oracle or Oracle RAC database schemas and users:
Before you begin:
installation.
environment.
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
AIX clustered server: Granting privileges to Oracle or Oracle RAC database users:
Installing 353
database user:
Installing 355
Installing 357
Related concepts:
AIX clustered server: Creating JCR table spaces:
environment.
command.
AIX clustered server: Assigning custom Oracle or Oracle RAC table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
COMM8KSPACE
AIX clustered server: Configuring Portal to use Oracle or Oracle RAC:
Oracle database. Follow these steps to transfer Portal and Java Content Repository databases to Oracle.
Before your begin:
Installing 359
Tips:
Repository schema.
files:
name are the same.
SQL > commit;
Exit sqlplus
Installing 361
Related tasks:
AIX clustered server: Creating Oracle or Oracle RAC databases on page 350
Technote 1317981
AIX clustered server: Changing Oracle or Oracle RAC driver types:
configuration task.
Related tasks:
AIX clustered server: Creating Oracle or Oracle RAC databases on page 350
AIX clustered server: Setting up Oracle or Oracle RAC automatically or manually on page 351
AIX clustered server: Setting up a remote SQL Server:
AIX clustered server: Installing SQL Server:
Installing 363
information.
sqljdbc_xa.dll
AIX clustered server: Modifying SQL Server database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
Installing 365
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
AIX clustered server: Setting up SQL Server automatically or manually:
table spaces.
Note:
database.
Related tasks:
AIX clustered server: Installing SQL Server on page 363
AIX clustered server: Running a task to automatically setup SQL server databsaes:
privileges.
4. Click Files.
Autogrowth field.
Installing 367
AIX clustered server: Setting up SQL Server manually:
AIX clustered server: Creating databases manually on SQL Server:
AIX clustered server: Creating SQL Server database schemas and users:
Before you begin:
installation.
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
AIX clustered server: Granting privileges to SQL Server database users:
Installing 369
database user:
Installing 371
Installing 373
Related concepts:
AIX clustered server: Assigning custom SQL Server filegroups:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
AIX clustered server: Configuring Portal to use SQL Server:
Server database. Follow these steps to transfer Portal and Java Content Repository databases to Oracle.
Before you begin:
Tips:
Repository schema.
files:
Installing 375
name are the same.
Related tasks:
AIX clustered server: Installing SQL Server on page 363
AIX clustered server: Modifying SQL Server database properties on page 364
AIX clustered server: Verifying the database configuration:
environment.
source is wpdbDS.
Removing search collections on AIX:
If you plan to use search in a cluster, you must configure a remote search server; see Configuring Portal
Search in a cluster for information. If you created any search collections, you must re-create them on the
remote search server. If your search collection has data, export the collection before deleting it and then
import the data on the remote server.
Complete the following step to remove the search collection:
1. Complete the following steps to prevent search collection creations:
Installing 377
a. Open the icm.properties file, located in the wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/
directory, and set the jcr.textsearch.enabled property to false.
b. Restart the WebSphere_Portal server.
2. Complete the following steps to delete all existing search collections from the primary node:After
submitting all customized jobs for this task, complete the following steps to delete all existing search
collections from the primary node:
Important: If you plan to use search in a cluster, you must configure a remote search server; see
Configuring Portal Search in a cluster on z/OS on page 1675 for information. If you created any
search collections, you need to re-create them on the remote search server. If your search collection
has data, export the collection before deleting it and then import the data on the remote server.
a. Log on to WebSphere Portal.
b. Navigate to Administration > Search Administration > Manage Search and then click Search
Collections.
c. Click the Delete Collection icon for each search collection and then click OK until they are all
deleted.
d. Restart the WebSphere_Portal server and then navigate back to the Search Collections page to
verify that all search collections have been deleted.
Related tasks:
Clustered environment: Performing post-installation tasks on AIX on page 291
Creating the WebSphere Portal profile template on AIX in a clustered environment:
After installing the primary node and configuring your remote database, you can create the configuration
archive (CAR) file that you can use to create additional IBM WebSphere Portal profiles.
Complete the following steps to creating the WebSphere Portal profile template:
1. If you installed WebSphere Portal as a non-root user, run the chmod -R u+rwx PortalServer_root/ task
to modify permissions for the Portal Server directory.
2. Run the ./ConfigEngine.sh enable-profiles -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory of the profile that you use as the primary node of the cluster.
This command creates a configuration archive (CAR) file that is used to create additional WebSphere
Portal profiles. The Portal.car file is saved to the PortalServer_root/profileTemplates/
default.portal/configArchives directory.
Type 4 database drivers only: If you configured WebSphere Portal for a remote database and placed
your database drivers inside of the wp_profile_root/PortalServer directory, they are included in the
configuration archive file that is created when running the enable-profiles script.
3. Run the ./ConfigEngine.sh package-profiles -DWasPassword=password task to compress the
profileTemplates directory and create a profileTemplates.zip file in the PortalServer_root/
profileTemplates directory.
4. Run the chmod -R u+rx PortalServer_root/ task to restore the non-root permissions to the Portal
Server directory.
Related tasks:
Clustered environment: Performing post-installation tasks on AIX on page 291
AIX cluster: Configuring Portal to use a database on page 292
Creating and augmenting a new Deployment Manager profile on AIX
For a production environment you should install your Deployment Manager on a server that is remote
from your IBM WebSphere Portal installation. Use the Profile Management Tool or the manageprofiles
command to create the remote Deployment Manager profile. In a test or development environment, you
can install your Deployment Manager locally using the IBM Installation Manager. Complete the steps to
creating and augmenting a new Deployment Manager profile if you are installing a remote Deployment
Manager profile. Skip these steps if you are using the Installation Manager to install a local Deployment
Manager profile on your primary node.
Choose the appropriate installation option to install your Deployment Manager profile:
Complete the following steps to create and augment the Deployment Manager profile:
1. Complete the following steps if IBM WebSphere Application Server is not installed on the system you
plan to use for the Deployment Manager:
a. Click the appropriate link under "Prerequisites" for installation instructions.
b. Install or update the IBM Installation Manager on your Deployment Manager server.
c. Add the same repositories that you used when installing WebSphere Portal on your primary node.
d. Begin the installation process.
e. Select the WebSphere Application Server Network Deployment installation package only and
complete the installation process.
2. You can either use an existing Deployment Manager profile or you can choose one of the following
options to create a default deployment manager profile:
Restriction: If you are using an existing Deployment Manager profile, the profile must have been
created with the "Management" profile template and not the "Cell" profile template. If your profile
was created with the "Cell" profile template, you must follow the instructions to create a default
Deployment Manager profile.
Important: While creating the default Deployment Manager profile, enable administrative security. If
you use the Profile Management Tool, check the enable administrative security check box. If you use
the manageprofile command, add the -enableAdminSecurity true parameter to the command line.
Installing 379
Table 157. Steps to create a default deployment manager profile.
Method Steps
Profile Management Tool Complete the following steps to use the Profile Management Tool:
1. Run the ./pmt.sh command from the AppServer_root/bin/ProfileManagement directory.
2. Click Launch Profile Management Tool.
3. Click Create to create a new profile.
4. On the Environment Selection panel, select Management, and then click Next.
5. Select Deployment Manager as the server type and then click Next.
6. Select the Advanced profile creation radio button and then click Next.
7. Check the Deploy the administrative console check box and then click Next.
8. On the Profile Name and Location panel, provide the name for the new profile and its location in the file
system. The name and location must be unique from other existing profiles. Click Next to continue.
Note: You can also choose to select the Create the server using the development template check box to enable
developer mode for this profile and the Make this profile the default check box to specify that this profile is the
default profile in the system.
9. On the Node, Host Names, and Cell Names panel, provide the node name and TCP/IP host name for the new
profile. If you plan to federate this profile, the node name must be unique from other profiles in the same
management cell (under Deployment Manager control). The host name must be a valid and reachable over the
network. Enter the cell name for this deployment manager. Click Next to continue.
10. On the Administrative Security panel, make sure that the Enable administrative security checkbox is checked.
Enter values for the User name, Password, and Confirm password fields. Click Next to continue.
11. On the Security Certificate (Part 1) panel, choose either the Create a new default personal certificate or the
Import an existing default personal certificate radio button and choose either the Create a new root signing
certificate or the Import an existing root signing certificate radio button. Click Next to continue.
12. On the Security Certificate (Part 2) panel, either provide the new certificate information or verify the existing
certificate information. Click Next to continue.
13. On the Port Values Assignment panel, change any necessary port values and then click Next.
14. On the Service Definition panel, specify whether or not the WebSphere Portal server in this profile is to be
registered and controlled as a service. Click Next to continue.
15. On the Profile Creation Summary panel, review the information collected by the wizard, and then click Create
to create the new profile based on the supplied information.
Tip: You should remember the WebSphere Integrated Solutions Console port value and the Deployment
Manager SOAP connector port values as you need these values in the future.
Note: The port values presented in the summary value are overridden by the port values used by the servers
present in the configuration archive provided as part of the portal profile template. These port values need to be
adjusted after profile creation if they are in conflict with other ports on the local system.
16. Click Finish to exit PMT.
manageprofile command ./manageprofiles.sh -create -templatePath AppServer_root/profileTemplates/management
-hostName hostname
-profileName Dmgr01
-profilePath AppServer_root/Dmgr01
-enableAdminSecurity true
-adminUserName dmgradmin
-adminPassword dmgrpass
3. Complete the following steps to collect files from the primary node and copy them to the remote
deployment manager:
a. An archive or compressed file is placed in the PortalServer_root/filesForDmgr directory during
installation; the file is called filesForDmgr.zip. Copy the filesForDmgr.zip file to the remote
Deployment Manager server.
b. Stop the deployment manager.
c. Expand the filesForDmgr.zip file into the installation root directory of the Deployment Manager;
for example in the /opt/IBM/WebSphere/AppServer directory.
Note: If the Deployment Manager profile was not created in the default AppServer\profiles\
Dmgr01 directory, then the metadata_wkplc.xml file, located in the AppServer/profiles/Dmgr01/
config/.repository\metadata_wkplc.xml directory in the compressed file, must be copied into the
config/.repository subdirectory under the Deployment Manager profile directory.
d. Start the deployment manager.
4. Choose one of the following methods to augment a deployment manager profile:
Table 158. Choosing between the Profile Management Tool and the manageprofiles task to augment a deployment
manager profile.
Option Steps
3. Select your Deployment Manager profile and then click Augment.
4. On the Augment Selection panel, select Deployment Manager for Portal, and then click Next.
5. On the Profile Augmentation Summary panel, review the information collected by the wizard, and then click
Augment to augment the Deployment Manager profile with WebSphere Portal.
manageprofiles command Run the following command from the AppServer_root/bin directory:
./manageprofiles.sh -augment -templatePath
AppServer_root/profileTemplates/management.portal.augment
-profileName dmgr
Tip: If you have a long command, use the continuation character "\" to avoid seeing the "not found" error
message.
In this example, the profile template is installed under the AppServer_root/profileTemplates directory. The existing
Deployment Manager profile is named dmgr and is located under the AppServer_root/profiles/dmgr directory.
5. Stop and restart the Deployment Manager server; see "Starting and stopping servers, deployment
managers, and node agents" for information.
6. Complete the following steps if there are common shortnames between the default Deployment
Manager security configuration and the LDAP server:
a. Log on to the Deployment Manager WebSphere Integrated Solutions Console.
b. Navigate to Security > Global security.
c. Under User account repository, click Configure.
d. In the Primary administrative user name field, alter the user ID so that is using the full
distinguished user name. For the default file user registry, the syntax is
uid=userID,o=defaultWIMFileBasedRealm; for example: uid=wpadmin,o=defaultWIMFileBasedRealm.
e. Click Apply.
f. Enter the password for the user and then confirm the password.
g. Save all changes.
h. Log out of the WebSphere Integrated Solutions Console.
7. Complete the following steps if you changed the context root on the Configuration for IBM
WebSphere Portal: Profile configuration details: Advanced panel during installation:
b. Go to Security > Global security.
c. Click Trust association in the Web and SIP security section.
d. Click Interceptors in the Additional Properties section.
e. Click com.ibm.portal.auth.tai.HTTPBasicAuthTAI.
f. Edit the urlBlackList and urlWhiteList parameters with the new context path; for example:
v urlBlackList: /wpsmodified/myportal*
v urlWhiteList: /wpsmodified/mycontenthandler*
g. Click Apply.
h. Save all changes.
i. Log out of the Deployment Manager WebSphere Integrated Solutions Console.
Installing 381
Related tasks:
Preparing your AIX operating system in a clustered environment on page 282
Clustered environment: Installing with the Installation Manager on AIX on page 283
Clustered environment: Installing with the response file on AIX on page 287
Preparing to create the cluster on AIX
If you installed a IBM WebSphere Application Server Network Deployment, create a static cluster to
handle failover requests. If you installed a IBM WebSphere Virtual Enterprise, create a dynamic cluster to
balance member workloads.
Complete the following steps to prepare for creating your cluster and then choose the type of cluster you
want to create:
1. If the Deployment Manager is configured to use a stand-alone LDAP user registry, update the
wkplc.properties file, located in the wp_profile_root/ConfigEngine/properties directory, on the
primary node with the stand-alone LDAP user registry property values from the Deployment
Manager. You can find these settings under the VMM Stand-alone LDAP configuration heading.
Important: Ensure that you set WasUserid and WasPassword to the Deployment Manager user ID and
password.
2. Complete the following steps on the Deployment Manager server if you are creating a dynamic
cluster:
a. Install WebSphere Virtual Enterprise and augment the deployment manager profile to make them
compatible.
b. On the WebSphere Portal primary node, install WebSphere Virtual Enterprise and augment the
wp_profile profile to make them compatible.
See the Planning the product installation Related link for information about installing WebSphere
Virtual Enterprise. Profile augmentation is performed using the Profile Management Tool (PMT)
graphical interface on systems that support it or through the manageprofiles command that is
available on all systems. When using the graphical interface as discussed in the Related link, make
sure you select Operations Optimization when choosing the type of augmentation to complete. When
using the manageprofiles command as discussed in the Related link, be sure to follow the instructions
to augment a stand-alone application server profile.
3. Run the following command from the wp_profile_root/bin directory to federate the primary node:
./addNode.sh dmgr_hostname dmgr_port -includeapps
-username was_admin_user
-password was_admin_password
The variables are defined as:
v dmgr_hostname is the TCP/IP host name of the Deployment Manager server
v dmgr_port is the SOAP port number of the Deployment Manager server
v was_admin_user and was_admin_password are the user ID and password for the Deployment Manager
administrator
If the WebSphere Application Server administrator user ID and password for the local node are
different from the Deployment Manager, add the following parameters to the addNode task:
v -localusername local_was_admin_user
v -localpassword local_was_admin_password
Tip: See the addNode command file for more information about the addNode command and other
optional parameters.
Warning: If the addNode task fails for any reason, you must complete the following steps before
rerunning the task:
a. Remove the node from the cell using the removeNode task if the addNode task succeeded in
federating the node.
b. Log on to the deployment manager and complete the following steps if the items exist:
1) Remove all enterprise applications.
2) Remove the WebSphere_Portal server definition.
3) Remove the WebSphere Portal JDBC Provider.
4. Stop the WebSphere_Portal server on the primary node and ensure that the following parameters are
set correctly in the wkplc.properties file, located in the wp_profile_root/ConfigEngine/properties
directory:
Note: Although you can add these parameters (particularly passwords) directly to any task while
creating your cluster, you might want to temporarily add them to the properties file. You can then
remove them when you are finished to keep your environment secure.
a. Set WasSoapPort to the port used to connect remotely to the deployment manager.
b. Set WasRemoteHostName to the full host name of the server used to remotely connect to the
deployment manager.
c. Verify that WasUserid is set to your Deployment Manager administrator user ID.
d. Verify that WasPassword is set to your Deployment Manager administrator password.
e. Verify that PortalAdminPwd is set to your WebSphere Portal administrator password.
f. Verify that ClusterName is set.
g. Verify that PrimaryNode is set to true.
5. Optional: If you configured a database user registry or a property extension (lookaside) database on
the Deployment Manager, run the following task to set up access to the database drivers:
a. Set the property value for federated.db.DbType if using a database user registry or set the
property value for la.DbType if using a property extension database in the wkplc.properties file.
Note: If you migrated the primary node from a version prior to Version 6.1.0 and you are not
using a database user registry or a property extension database, set the property value for
federated.db.DbType to the same value that is in the wkplc.properties file on the primary node.
b. Complete the following steps to add the library paths to the VMM_JDBC_CLASSPATH variable:
1) Log on to the WebSphere Application Server WebSphere Integrated Solutions Console.
2) Click Environment > WebSphere Variables.
Installing 383
3) Select scope: cell.
4) Select the VMM_JDBC_CLASSPATH variable. If this variable does not exist, click New to
create the variable.
5) Enter the complete paths to the library files in Value. Separate multiple files with a colon (:);
for example, enter SQLLIB/java/db2jcc4.jar:SQLLIB/java/db2jcc_license_cu.jar.
6) Copy the files that you entered in for the VMM_JDBC_CLASSPATH variable into the
appserver/lib directory.
7) Stop and restart the appropriate servers to propagate the changes.
c. Run the ./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password
-DDbDomain=la|federated.db -Ddb_type.NodeDbLibrary=local full path of the database jars
on the Deployment Manager -DDmgrNodeName=dmgr_node_name task from the wp_profile_root\
ConfigEngine directory to create the local Deployment Manager WebSphere variable used to access
the database jars.
for example db2. The local path of the database jars on the Deployment Manager should be one of
Oracle: ojdbc14.jar
d. Run the ./ConfigEngine.sh wp-node-prep-vmm-db-secured-environment
-DWasPassword=dmgr_password -DDbDomain=la|federated.db -DVmmNodeName=node_name
wp_profile_root/ConfigEngine directory to create the variable used to access the VMM database jars.
Note: VmmNodeName is a list of one or more WebSphere Portal nodes names in the cell which share
the same database driver paths. The db_type in db_type.NodeDbLibrary should be set to the type of
database you are using, for example db2.
6. Choose one of the following options to create your cluster:
v Creating a static cluster: Choose this option to handle failover requests.
v Creating a dynamic cluster: Choose this option to dynamically balance member workloads.
Related tasks:
Preparing the primary node on AIX on page 282
Middleware nodes and servers
Planning the product installation
Creating a static cluster on AIX:
After installing IBM WebSphere Portal on the primary node, configuring a remote database, and
preparing the primary node to communicate with the Deployment Manager, you can create your static
cluster to handle failover requests.
Complete the following steps to create the cluster:
1. Run the ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password
task.
2. The WebSphere Portal node is federated and using the Deployment Manager cell and its user registry.
If the administrative user ID and group name are different in the WebSphere Portal and Deployment
Manager configurations, choose one of the following options depending on your security policies:
v Add the existing administrative user ID and group to the Deployment Manager security
configuration
v Complete the following steps to change the values in the WebSphere Portal configuration to match
the Deployment Manager values:
Restriction: If your Deployment Manager cell is using a stand-alone LDAP user registry, complete
these steps after the cluster-node-config-cluster-setup (static cluster) or cluster-node-config-
dynamic-cluster-setup (dynamic cluster) task completes.
a. If necessary, start the WebSphere_Portal server.
b. Verify that the required WebSphere Portal administrative user ID and group ID are defined in the
Deployment Manager user registry that provides security for the cell.
c. Run the ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password
-DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid task,
from the wp_profile_root/ConfigEngine directory, where:
Important: If the value for newAdminGroupId contains a space; for example Software Group, open
the wkplc.properties file and add the values for newAdminId, newAdminPw, and newAdminGroupId.
Save your changes and then run the ./ConfigEngine.sh wp-change-portal-admin-user
-DWasPassword=dmgr_password task.
v WasPassword is set to the administrative password for the Deployment Manager cell
v newAdminId is set to the fully qualified distinguished name (DN) of the WebSphere Portal
administrative user ID in the cell
v newAdminGroupId is set to the fully qualified DN of the group for the WebSphere Portal
d. After the task completes, stop the WebSphere_Portal server.
3. Run the ./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password task.
4. If you entered passwords in any of the properties files while creating your cluster, you should remove
them for security purposes. See "Deleting passwords from properties files" under Related tasks for
information.
Creating a dynamic cluster on AIX using WebSphere Virtual Enterprise:
After installing and configuring IBM WebSphere Portal on your primary node and all horizontal nodes,
you can create a new dynamic cluster. A dynamic cluster monitors performance and load information and
is able to dynamically create and remove cluster members based on the workload.
Before creating your dynamic cluster, you should have already installed and configured the Deployment
Manager and completed all the tasks under Preparing the primary node. On the Deployment Manager
system, install WebSphere Virtual Enterprise, apply all required ifixes, and augment the deployment
manager profile to make it compatible with WebSphere Portal. On the WebSphere Portal primary node,
Installing 385
install WebSphere Virtual Enterprise, apply all required ifixes, and augment the wp_profile profile to
make it compatible with WebSphere Portal. See the Planning the product installation Related link for
information about installing WebSphere Virtual Enterprise. Profile augmentation is completed using the
Profile Management Tool (PMT) graphical interface on systems that support it or through the
manageprofiles command that is available on all systems. When using the graphical interface as
discussed in the Related link, make sure you select Operations Optimization when choosing the type of
augmentation to complete. When using the manageprofiles command as discussed in the Related link, be
sure to follow the instructions to augment a stand-alone application server profile.
Complete the following steps to create a dynamic cluster:
1. Complete the following steps for on the primary node of the dynamic cluster:
a. Run the ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password
task.
b. The WebSphere Portal node is federated and using the Deployment Manager cell and its user
registry. If the administrative user ID and group name are different in the WebSphere Portal and
Deployment Manager configurations, choose one of the following options depending on your
security policies:
configuration
v Complete the following steps to change the values in the WebSphere Portal configuration to
match the Deployment Manager values:
1) If necessary, start the WebSphere_Portal server.
2) Verify that the required WebSphere Portal administrative user ID and group ID are defined in
the Deployment Manager user registry that provides security for the cell.
3) Run the ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password
-DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid
task, from the wp_profile_root/ConfigEngine directory, where:
Important: If the value for newAdminGroupId contains a space; for example Software Group,
open the wkplc.properties file and add the values for newAdminId, newAdminPw, and
newAdminGroupId. Save your changes and then run the ./ConfigEngine.sh
wp-change-portal-admin-user -DWasPassword=dmgr_password task.
4) After the task completes, stop the WebSphere_Portal server.
2. Log on to the deployment manager WebSphere Integrated Solutions Console.
3. Complete the following steps to create a node group:
a. Click System administration > Node groups.
b. Click New.
c. Type the node group Name.
d. Optional: Type any information about the node group in the Description text box.
e. Click OK.
f. Click the Save link to save your changes to the master configuration.
4. Complete the following steps to add members to the node group:
b. Click the name of the node group that you want to add members to.
c. Click Node group members under Additional Properties.
d. Click Add.
e. Select the primary node and then click Add.
5. Complete the following steps to create a dynamic cluster in the node group:
a. Click Servers > Clusters > Dynamic clusters.
b. Click New.
c. Select WebSphere Application Server from the Server Type pull-down menu and then click Next.
d. Select the Automatically define cluster members with rules radio button.
e. Type the cluster name in the Dynamic cluster name text box and then click Next. Type the same
value that you provided for the ClusterName parameter in the wkplc.properties file of your
primary node.
f. Remove all default membership policies and then click Subexpression builder.
g. Enter the following information in the Subexpression builder window:
1) Select and from the Logical operator pull-down menu.
2) Select Nodegroup from the Select operand pull-down menu.
3) Select Equals (=) from the Operator pull-down menu.
4) Type the nodegroup name you created in the previous step in the Value text box.
5) Click Generate subexpression.
6) Click Append.
h. Click Preview membership to verify that all nodes included in the nodegroup display and then
click Next.
i. Click the Create the cluster member using an existing server as a template radio button and then
select the WebSphere_Portal server for the primary node from the pull-down menu.
j. Click Next.
k. Specify the required dynamic cluster properties for minimum and maximum number of server
instances.
Note: If you choose to configure vertical stacking to allow multiple server instances on a single
node, see Adding vertical cluster members to a dynamic cluster for information on additional
required configurations.
l. When you are done configuring the dynamic cluster properties, click Next.
m. Review the summary page to verify your actions and then click Finish.
n. Click the Save link to save your changes to the master configuration.
6. Define or verify the following parameters in the wkplc.properties file, located in the
wp_profile_root/ConfigEngine/properties directory:
a. Verify that CellName is set to the deployment manager cell.
b. Verify that NodeName is set to the local WebSphere Portal node.
c. Set ServerName to the server that is used for the dynamic cluster member on this node.
Note: Log on to the deployment manager WebSphere Integrated Solutions Console and click
Servers > Clusters > Dynamic Clusters > PortalCluster > Dynamic cluster members to find the
name of the server used for the dynamic cluster.
d. Verify that PrimaryNode is set to true.
Installing 387
7. Run the ./ConfigEngine.sh cluster-node-config-dynamic-cluster-setup
-DWasPassword=dmgr_password task from the wp_profile_root/ConfigEngine directory to create the
dynamic cluster.
Note: This task may display a warning message since the cluster already exists. The task proceeds to
create the new dynamic cluster. Therefore, the warning can be ignored.
8. Run the following tasks to pick up the configuration changes:
Note: WebSphere_Portal_servername is the name of the node's WebSphere Portal server; but if you
customized the server name, the default name changes. If you are uncertain of the server name, run
the serverstatus -all task to get a list of the server names and their status.
a. ./stopServer.sh WebSphere_Portal_servername -username admin_userid -password
admin_password
b. ./startServer.sh WebSphere_Portal_servername
Related tasks:
Preparing a remote Web server when portal is installed on AIX in a clustered
environment
directive.
feature:
f. Click OK.
11. Complete the following steps to access the Web Content Manager content through an external web
server:
a. Log on to the deployment manager WebSphere Integrated Solutions Console.
b. Select Environment > WebSphere Variables.
c. From the Scope drop-down menu, select the Node=nodename, Server=servername option to
narrow the scope of the listed variables, where Node=nodename is the node that contains the
WebSphere Portal application server.
d. Update the WCM_HOST variable with the fully qualified host name used to access the WebSphere
Portal server through the web server or On Demand Router.
e. Update the WCM_PORT variable with the port number used to access the WebSphere Portal server
through the web server or On Demand Router.
f. Update the WCM_HOST and WCM_PORT variable for each additional WebSphere Portal application
server that already exists in the cluster.
g. Complete the following steps to synchronize the node with the deployment manager:
1) Select System Administration > Nodes.
2) Select the node that you want to synchronize from the list.
3) Click Full Resynchronize.
h. Log off of the deployment manager WebSphere Integrated Solutions Console.
12. If you have a dynamic cluster and you are using a web server to connect to the On Demand Router
(ODR), configure the web server as a trusted proxy on the ODR. Refer to Configuring a web server
as a trusted proxy server for instructions.
Installing 389
Tip: You can also configure the ODR to dynamically update the web server configuration when
changes occur. Refer to Configuring an on demand router to dynamically update the web server
plug-in configuration for instructions.
Related tasks:
Creating and augmenting a new Deployment Manager profile on AIX on page 379
Related reference:
Configuring WebSphere Portal to use a user registry on AIX in a clustered
environment
LDAP user registry.
information.
Related tasks:
Preparing to create the cluster on AIX on page 382
AIX cluster: Preparing user registries:
AIX cluster: Preparing a Domino Directory Server:
Center.
Last Name
wpsbind
User Name
Installing 391
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Internet password
wpsadmin
Group name
wpsadmins
Group type
Multi-purpose
Members
members.
the file.
Editor access.
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
AIX cluster: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
AIX cluster: Preparing a Novell eDirectory:
Installing 393
4) Click Add.
with a text editor:
your LDAP server.
AIX cluster: Preparing an Oracle Directory Server:
Portal.
4) Click Add.
with a text editor:
your LDAP server.
AIX cluster: Preparing a Tivoli Directory Server:
group.
4) Click Add.
with a text editor:
your LDAP server.
Choosing your user registry model on AIX in a clustered environment:
Choosing your stand-alone LDAP user registry on AIX in a clustered environment:
AIX cluster: Configuring a stand-alone LDAP user registry without SSL in a clustered environment:
Installing 395
standalone.ldap.id
LDAP configuration.
ignore this line.
Installing 397
Content Manager
Type of LDAP Value
Internet libraries.
If you created your clustered environment, including the additional nodes, and then completed the steps
in this task, you must now run the update-jcr-admin task on the secondary node. See the related links
section for instructions.
Related tasks:
Configuring a stand-alone LDAP user registry over SSL on AIX in a clustered environment:
c. Click the appropriate SSL configuration from the list. For example: CellDefaultSSLSettings
Clustered environments: Ensure the setting for SSL configuration for outbound connection
matches your SSL settings.
e. Click the appropriate truststore from the list; for example, CellDefaultSSLSettings.
Installing 399
standalone.ldap.id
LDAP configuration.
ignore this line.
Installing 401
Content Manager
Type of LDAP Value
Internet libraries.
Related tasks:
Configuring the default federated repository on AIX in a clustered environment:
Configuring a federated LDAP user registry on AIX in a clustered environment:
Adding an LDAP user registry on AIX in a clustered environment:
Tip: Complete these steps on the primary node only.
federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 403
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
Installing 405
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 407
Related tasks:
Adding an LDAP user registry over SSL on AIX in a clustered environment:
federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 409
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
Installing 411
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Related tasks:
Adding a database user registry on AIX in a clustered environment:
Installing 413
file.
Database Steps
1. Install DB2.
Table 164. Steps for creating a database to use as a database user registry. (continued)
Database Steps
db_files = 1024
log_buffer = 65536
pre_page_sga = true
processes = 300
heading:
db_type.DbDriver
db_type.DbLibrary
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbName
Installing 415
database jars.
Oracle: ojdbc14.jar
VMM database jars.
repository.
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
Adding realm support on AIX in a clustered environment:
Installing 417
realmName
securityUse
delimiter
addBaseEntry
configuration.
realmName
realm.groupParent
then run this task:
parameters.
realmName
addBaseEntry
configuration.
user and group.
group.
Installing 419
the feature.
Related tasks:
AIX cluster: Adapting the attribute configuration:
repositories.
LDAP schema
Related tasks:
AIX stand-alone: Adding an LDAP user registry over SSL on page 259
AIX stand-alone: Configuring a stand-alone LDAP user registry without SSL on page 247
AIX stand-alone: Configuring a stand-alone LDAP user registry over SSL on page 250
AIX cluster: Querying the defined attributes:
Adding attributes on AIX in a clustered environment:
Application Server.
Installing 421
b. Go to the wp_profile_root\ConfigEngine directory on the primary node.
c. Run the ./ConfigEngine.sh wp-la-install-ear -DWasPassword=dmgr_password
-DServerName=dmgr_server_name -DNodeName=node_name task.
Where the default value for dmgr_server_name is dmgr; you can find the dmgr_server_name value in
the WebSphere Integrated Solutions Console under System administrator > Deployment Manager
> Configuration tab > General Properties > Name.
Where node_name is the name of the node where the deployment manager resides; you can find
the node_name value in the WebSphere Integrated Solutions Console under System administrator >
Deployment Manager > Runtime tab > General Properties > Node Name.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
Related tasks:
Mapping attributes on AIX in a clustered environment:
your LDAP server:
standalone.ldap.id
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:
Installing 423
parameters.
standalone.ldap.id
file. (continued)
heading:
parameters.
registry:
parameters.
Installing 425
Related tasks:
AIX cluster: Removing attributes:
model directory.
directory.
or
database:
AIX cluster: Configuring Portal to use dynamic groups in a clustered environment:
nodes.
Installing 427
v Name: memberurl
AIX cluster: Enabling referrals for your LDAP user registry in a clustered environment:
Preparing additional cluster members on AIX
After installing and configuring your primary node, you can create your additional cluster nodes. You
must install IBM WebSphere Portal on each node and then configure the node to access the database and
user registry before adding it to the cluster.
Complete the following tasks to prepare your additional cluster node:
Related tasks:
Installing WebSphere Portal on AIX for the horizontal cluster nodes:
Install IBM WebSphere Portal on your additional cluster nodes to create a highly available and scalable
environment. On additional nodes, you only need to install the WebSphere Portal product binary files.
The WebSphere Portal application server and applications are added after the node is federated and a
new cluster member is created.
Related concepts:
Related tasks:
Additional node: Installing with the Installation Manager on AIX:
Installing 429
Application Server on your additional nodes. The IBM Installation Manager gathers essential information,
such as host name and node, and then performs the installation. The main difference when installing
your additional nodes, select the Product binaries only option when selecting the type of installation.
options:
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
click OK.
stored.
e. Select Apply.
f. Select OK.
b. On the Install Packages: Select the fixes to install panel, select the following fixes based on how
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
Installing 431
v 8.0.0.3-WS-WAS-TFPM61934
c. Click Next.
directory path.
path.
3) Click Next.
Next.
i. Confirm the information on the Summary panel and then click Install.
7. Verify that your installation successfully created the WebSphere Portal file system.
WARNING: Because the WebSphere Portal profile was not created, the WebSphere_Portal server does
not exist. You create the server when adding the node to the cluster.
Additional node: Installing with the response file on AIX:
WebSphere Application Server on your additional nodes. The main difference when installing your
additional nodes, you must specify the product binary installation parameter. Record a response file on
the same operating system you plan for the installation. If you have multiple operating systems, you
must record a response file for each operating system.
options:
Advantage):
Replace with
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
Installing 433
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
response file:
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
directory path.
path.
3) Click Next.
Next.
computer.
[ -useSocks ] ]
[ -verbose ]
Installing 435
Choosing the type of horizontal cluster to create on AIX:
If you created a static cluster using the IBM WebSphere Application Server Network Deployment, add
additional static nodes to the cluster. If you created a dynamic cluster using IBM WebSphere Virtual
Enterprise, add additional dynamic nodes to the cluster.
Choose one of the following options to add additional nodes to your cluster:
Adding horizontal nodes to the static cluster on AIX:
After installing IBM WebSphere Portal for your horizontal cluster node, you must add the node to the
cluster to create a highly available environment.
Complete the following steps to add the horizontal cluster node to the cluster:
1. Complete the following steps to create a directory to store templates:
a. Copy the profileTemplates.zip file from the PortalServer_root/profileTemplates directory on the
primary node to the same location on the additional cluster node.
b. Extract the profileTemplates.zip file in the same location. If any of the templates already exist
in your profileTemplates directory, overwrite them.
c. Run the chmod -R 755 PortalServer_root/profileTemplates task to change the permissions of
the files and directories, located in the PortalServer_root/profileTemplates directory, because some
files are set to read-only after the copy operation.
d. Run the ./installPortalTemplates.sh AppServer_root task from the newly created
profileTemplates directory to install the copied profile template. This task localizes the profile
templates to the current environment and registers them with the Profile Management Tool if it
exists on your server.
2. Choose one of the following methods to create a profile that is used for additional cluster members:
Important: Choose a Node Name that is different from what you entered for the primary node.
Table 169. Choose between the Profile Management tool and the manageprofiles task to create a profile that is used
for additional cluster members.
Option Steps
3. Click Create to create a profile.
4. On the Environment Selection panel, select the WebSphere Portal 8.0.0 > Custom Portal profile, and then
click Next.
7. On the Node and Host Names panel, provide the node name and TCP/IP host name for the new profile. If
you plan to federate this profile, the node name must be unique from other profiles in the same management
cell (under Deployment Manager control). The host name must be valid and reachable over the network.
Click Next to continue.
8. On the Federation panel check the Federate this node later check box to federate the node in the future.
CAUTION:
Do not enter the values for the Deployment Manager to federate now as this will cause an unusable portal
node.
9. On the Profile Creation Summary panel, review the information collected by the wizard, and then click
Create to create the profile with WebSphere Portal.
./manageprofiles.sh -create -templatePath
/usr/IBM/WebSphere/PortalServer/profileTemplates/managed.portal
-profileName testManagedPortal1
-profilePath /usr/IBM/WebSphere/PortalServer/profiles/testManagedPortal1
-cellName testCell
-nodeName testNode
-hostName myportal.myco.com
message.
In this example, the profile template is installed under the /usr/IBM/WebSphere/PortalServer/profileTemplates
directory. The new profile is named testManagedPortal1 and is located under the /usr/IBM/WebSphere/
PortalServer/profiles/testManagedPortal1 directory.
3. Complete the following steps to ensure that your database information is correct and to ensure a
successful additional node:
a. Ensure that the wkplc_dbdomain.properties and wkplc_dbtype.properties files have the correct
database information in them.
Tip: The wkplc_dbdomain.properties and wkplc_dbtype.properties files should match the
database information defined in the primary node.
b. Copy the database drivers on the primary node to the same location on the additional cluster
node. You can find the location of your database drivers in the wkplc_dbtype.properties file.
4. Run the ./ConfigEngine.sh validate-database -DWasPassword=password task to validate your
database settings.
Tip: Add the -DTransferDomainList parameter to the validate-database task to specify the domains
you want to validate; for example: -DTransferDomainList=jcr. If you want to validate all domains,
you do not need to specify this parameter on the command line.
5. Open the icm.properties file, located in the wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/
6. Run the following command from the wp_profile_root/bin directory to federate the additional cluster
node:
Installing 437
./addNode.sh dmgr_hostname dmgr_port
v was_admin_user and was_admin_password are the user ID and password for the Deployment
Manager administrator
7. Ensure that the following parameters are set correctly in the wkplc.properties file, located in the
wp_profile_root\ConfigEngine\properties directory of the additional cluster node:
a. Verify that WasUserid is set to your deployment manager administrator ID.
b. Verify that WasPassword is set to your deployment manager administrator password.
c. Verify that WasRemoteHostName is set to the fully qualified host name of the deployment manager.
d. Verify that WasSoapPort is set to the SOAP port that the deployment manager is using; the
default value is 8879.
e. Verify that ServerName is set to the correct server name. The default is WebSphere_Portal but you
can change this on your additional nodes.
f. Verify that PrimaryNode is set to false.
g. Verify that ClusterName is set to the primary node's ClusterName.
ConfigEngine directory to create the local Deployment Manager WebSphere variable used to
access the database jars.
for example db2. The local path of the database jars on the Deployment Manager should be one
of the following options:
Oracle: ojdbc14.jar
wp_profile_root/ConfigEngine directory to create the variable used to access the VMM database
jars.
the same database driver paths. The db_type in db_type.NodeDbLibrary should be set to the type
of database you are using, for example db2.
9. The WebSphere Portal node is federated and using the Deployment Manager cell and its user
security policies:
configuration
these steps after the cluster-node-config-cluster-setup-additional (static cluster) or
cluster-node-config-dynamic-cluster-setup-additional (dynamic cluster) task completes.
Installing 439
10. Run the ./ConfigEngine.sh cluster-node-config-cluster-setup-additional
-DWasPassword=dmgr_password task to add the node to your cluster.
11. If the profile templates were copied from a server with a different profile directory, complete the
following steps:
a. Log on to the Deployment Manager integrative console.
b. Go to Servers > Server Types > Application servers.
c. Select the additional cluster member server.
d. Go to Java and Process Management > Process definition > Environment Entries.
e. Delete the following environment entries:
v LD_LIBRARY_PATH
v LIBPATH
v PATH
v SHLIB_PATH
f. Open a command prompt and change to the wp_profile_root/ConfigEngine directory.
g. Run the ./ConfigEngine.sh profile-update-entries task to update these entries with the correct
profile paths.
server:
13. Run the following tasks to propagate your changes:
admin_password
14. If you entered passwords in any of the properties files while creating your cluster, you should
remove them for security purposes. See "Deleting passwords from properties files" under Related
tasks for information.
Adding a horizontal node to the dynamic cluster on AIX:
After creating your dynamic cluster, you can add horizontal nodes to expand the capacity of the dynamic
cluster. Install and configure the horizontal node, then add it to the existing dynamic cluster node group,
and then add it to the existing IBM WebSphere Virtual Enterprise dynamic cluster.
Complete the following steps to add an horizontal node to the WebSphere Virtual Enterprise dynamic
cluster:
Option Steps
click Next.
CAUTION:
node.
Installing 441
for additional cluster members. (continued)
Option Steps
-cellName testCell
-nodeName testNode
message.
3. Install WebSphere Virtual Enterprise and augment the newly created profile. See the "Planning the
product installation" link in the Related information section for information about installing
WebSphere Virtual Enterprise. Profile augmentation is performed using the Profile Management Tool
(PMT) graphical interface on systems that support it or through the manageprofiles command that is
available on all systems. When using the graphical interface as discussed in the link in the Related
information section, make sure you select Operations Optimization when choosing the type of
augmentation to complete. When using the manageprofiles command as discussed in the link in the
Related information section, be sure to follow the instructions to augment a stand-alone application
server profile.
database settings.
node:
Installing 443
Oracle: ojdbc14.jar
jars.
security policies:
configuration
task.
d. Click Add.
e. Select the additional node you want to add into the node group and then click Add.
a. Verify that ClusterName is set to the name of the existing dynamic cluster.
b. Verify that CellName is set to the deployment manager cell.
c. Verify that NodeName is set to the local WebSphere Portal node.
d. Set ServerName to the server that is used for the dynamic cluster member on this node.
e. Verify that PrimaryNode is set to false because this is an additional node.
14. Run the ./ConfigEngine.sh dynamic-cluster-setup-additional -DWasPassword=dmgr_password task
to tune your additional cluster resources.
15. Complete the following steps to start the cluster member:
b. Navigate to Servers > Dynamic clusters > cluster name > Dynamic cluster members.
c. Select the cluster member and click Start.
d. Log off of the deployment manager WebSphere Integrated Solutions Console.
server:
admin_password
Installing 445
Related tasks:
Choosing the type of vertical cluster to create on AIX:
If you are using the IBM WebSphere Application Server Network Deployment, you can add vertical
cluster members to your static cluster. If you are using IBM WebSphere Virtual Enterprise, you can add
vertical cluster members to your dynamic cluster.
Choose one of the following options to add vertical cluster members to your cluster.
Adding vertical cluster members to a static cluster on AIX:
You can add vertical cluster members to share the workload demands of your cluster across multiple
members running on the same physical machine.
Complete the following steps to add a vertical cluster member to your clustered environment:
1. Log into the deployment manager WebSphere Integrated Solutions Console.
2. Click Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster
members.
3. Click New to create the cluster member.
a. Define the name of cluster member.
Note: Do not use spaces in the cluster member name.
b. Select an existing node where IBM WebSphere Portal is installed.
c. Check the box Generate Unique HTTP Ports.
d. Click Add Member and then click Next to view the summary.
Important: You must update the virtual host entries for the new port created when adding a cluster
member. You can do this by updating the default_host virtual host in the WebSphere Integrated
Solutions Console and adding a new alias entry for the port number (use an "*" wildcard character
for the host name). See Configuring virtual hosts for information.
4. Click Finish, and save the changes.
The new cluster topology can be viewed from the Servers > Clusters > Cluster Topology view.
The Servers > Server Types > WebSphere application servers view lists the new server cluster
members.
5. Complete the following steps to enable cache replication:
a. From the deployment manager WebSphere Integrated Solutions Console, go to Servers > Server
Types > WebSphere application servers and then click the new vertical cluster member(s).
b. Click Dynamic cache service under Container services.
c. Change Cache size to 3000 entries.
d. Check the Enable cache replication check box.
e. Select NOT_SHARED from the Replication type drop-down menu.
f. Click OK.
6. Complete the following steps on each vertical cluster member to clean up the server-scoped resources,
caches, and resource providers:
a. Run the ./ConfigEngine.sh cluster-node-config-vertical-cluster-setup -DServerName=unique
vertical cluster servername -DWasPassword=password task, from the wp_profile_root/ConfigEngine
directory on the node where you created the vertical cluster. unique vertical cluster servername is the
name you specified when you created the cluster member.
b. Restart the vertical cluster member referenced in the cluster-node-config-vertical-cluster-
setup task.
7. Save your changes and resynchronize the nodes.
a. In the deployment manager WebSphere Integrated Solutions Console, click Save on the task bar,
and save your administrative configuration.
b. Select System Administration > Nodes, select the node from the list, and click Full
Resynchronize.
a. Regenerate the web server plug-in using the deployment manager WebSphere Integrated Solutions
Console.
b. If you are using a remote web server, copy the updated plug-in configuration file (plugin-cfg.xml)
to the web server's plug-in configuration directory.
9. Stop and start the web server.
Adding vertical cluster members to a dynamic cluster on AIX:
1. Open a browser and enter http://DM01:9060/ibm/console in the address bar to access the deployment
manager WebSphere Integrated Solutions Console, where DM01 is the deployment manager node or
host name. The port number might differ based on your installation.
2. Complete the following steps to allow vertical clusters on your dynamic cluster:
a. Navigate to Servers > Clusters > Dynamic clusters and select the appropriate dynamic cluster.
b. Select the Allow more than one instance to start on the same node check box under Vertical
stacking of instances on node.
c. Enter a new value in the Number of instances text box to determine the number of vertical cluster
members allowed on each node.
d. Click Apply and then click Save to save the changes to the master configuration.
e. Optional: Navigate to Servers > Clusters > Dynamic Clusters > clustername > Cluster Members
view to view the list of new cluster members.
members.
Installing 447
f. Click OK.
setup task.
Resynchronize.
AIX cluster: Tune your servers
should be used.
Related tasks:
All Tuning Guides and resources
Configuring search in a cluster on AIX
IBM WebSphere Portal provides two distinct search capabilities. You can use both types of search
capabilities in a clustered environment.
Related tasks:
Configuring Portal Search in a cluster on AIX:
To support Portal Search in a clustered environment, you must install and configure search for remote
search service on an IBM WebSphere Application Server node that is not part of the IBM WebSphere
Portal cluster.
Installing 449
To install and configure the search service remotely, perform the following tasks:
1. Install and configure the search service to work remotely, that is, on a remote WebSphere Application
Server node which is not part of the portal cluster. You can provide the remote search service either as
an EJB or as a web service via SOAP. Deploy the appropriate EJB or SOAP EAR file on the remote
WebSphere Application Server node. For details about how to do this, refer to the WebSphere
Application Server documentation.
2. Configure the search portlets for remote search service so that they access the remote server
accordingly.
Notes:
1. If you have configured a remote search service for a portal cluster, you need to configure the default
location for search collections to a directory on the remote server that has write access.
2. The portal site default search collection is created only once at the first time when an administrator
selects the search administration portlet Manage Search. If this occurred before you configure the
portlet for remote search, then the default portal site search collection is only available on the primary
node of the cluster, but not on the remote server. In this case you need to re-create the portal site
collection to make it available for search on all nodes of the cluster.
Related concepts:
Planning and preparing for Portal Search on page 2697
Learn about some planning considerations and first steps that you need to apply before working with
Portal Search.
Related tasks:
Configuring Portal Search for remote search service on page 2708
View steps to configure Portal search for remote search service.
Configuring the default location for search collections on page 2717
You can modify the default directory location under which search collections are created on a per search
service basis. View some related information.
Resetting the default search collection on page 2744
Under certain circumstances you might want to change the configuration of the portal site search
collection. In this case you need to recreate the collection, as search collections cannot be modified.
Configuring a remote search service on page 2716
Configure a remote search service for Portal Search.
Configuring JCR search in a cluster on AIX:
To enable search in a cluster for content stored in the JCR database, you must configure each server in the
cluster to access a shared directory. JCR-based content includes content created with Web Content
Manager or Personalization.
Create a shared directory called jcr/search on a server in the network and ensure that each node in the
cluster and the Deployment Manager has network access to the directory.
Set up the remote search service on the primary node of the cluster; refer to Configuring a remote search
service for information.
Perform the following steps on each server in the cluster to configure Search in a clustered environment:
1. Edit the icm.properties file, located in the wp_profile_root/PortalServer/jcr/lib/com/ibm/icm
directory.
2. Change the value of the jcr.textsearch.indexdirectory property to the shared directory; for
example, jcr.textsearch.indexdirectory=\\\\your_server\\your_share\\jcr\\search. You can
specify the shared directory value in one of the following formats:
Table 171. The format for the shared directory.
Format Shared directory
Universal Naming Convention (UNC) format \\\\your_server\\your_share\\jcr\\search
Example: \\\\hostname.example.com\\share\\jcr\\
search
Mounted resource format (with forward slashes) /your_share/jcr/search
For example: /mnt/jcr/search
Important: This format requires that you mount the
shared directory to the local server (for example, through
a mapped network drive or a mounted directory). When
using the mounted resource format, always use forward
slashes instead of back slashes, regardless of the native
operating system path format.
3. Based on the configuration of your remote search service, change the jcr.textsearch.PSE.type
property to either EJB or SOAP; then choose the appropriate additional steps:
Table 172. The steps depending on the value for the jcr.textsearch.PSE.type property.
Value Additional steps
EJB Perform the following steps if you have an EJB service:
1. Change the jcr.textsearch.EJB.IIOP.URL property to
the URL of the naming service used to access the
WebScanner EJB; for example iiop://localhost:2811.
2. change the jcr.textsearch.EJB.EJBName property to
the name of the WebScanner EJB; for example
ejb/com/ibm/hrl/portlets/WsPse/
WebScannerLiteEJBHome.
SOAP If you have a SOAP service, change the
jcr.textsearch.SOAP.url property to the SOAP URL of
the WebScanner for the search service.
4. Change the jcr.textsearch.enabled value in the icm.properties file to true.
5. Required: Perform the following steps to delete the default search collections from the Manage Search
portlet:
a. Log on to WebSphere Portal as an administrator.
b. Click Administration > Search Administration > Manage Search.
c. Click Search Collections.
d. Click the Delete Collection icon for the Portal Content search collection.
e. Click OK.
f. Restart the WebSphere_Portal server.
g. Go to the Manage Search portlet and confirm that the Portal Content search collection was
deleted.
h. Manually create a JCR Collection called JCRCollection1; refer to Setting up JCR Search Collection
for information.
Installing 451
Setting up a JCR search collection on page 2729
A JCR search collection is a special purpose search collections used by WebSphere Portal applications. It
is not designed to be used alongside user-defined search collections. A JCR search collection requires a
special setup. This includes the creation of a new content source for the search collection.
Setting up multiple clusters on AIX
The majority of the steps to build another cluster are the same as when building the first cluster in the
same cell, with a few exceptions. Basically, the new profile will be designated as the primary profile,
using IBM WebSphere Portal clustering terminology, and will then be used as the basis for the new
cluster definition. This duplicates the build process of the first cluster in the cell. During the federation
process, if any applications on this new node already exist in the cell (because they are in use by the first
cluster), then Deployment Manager will not allow them to be added. After federation, the applications
that already exist in the cell are not mapped to the WebSphere_Portal server on the newly federated
node, and thus the existing applications must be remapped to this newly federated server to restore its
application list. Therefore, depending on the configuration of the new profile, there will likely be some
combination of applications shared with the other existing cluster, and some applications unique to this
new profile.
Before attempting alternative approaches for building multiple portal-based clusters within a single cell,
please contact IBM.
Related tasks:
AIX cluster: Tune your servers on page 448
should be used.
Installing multiple clusters in a single cell on AIX:
already exists.
In the following steps, Cluster A is used to describe the existing cluster. Portal B is used to describe the
new server profile that is the basis for the new cluster definition, Cluster B.
Complete the following steps to install multiple clusters in a single cell:
1. If necessary, upgrade Cluster A, including the Deployment Manager node, to the current, supported
hardware and software levels and to the current version of IBM WebSphere Portal. Only upgrade if
Cluster B is at a higher version than the existing Cluster A.
2. Complete the following tasks to install and configure Portal B; see the links in Related tasks:
Important: Maintain the same number of data sources with identical names to the Cluster A data
sources so that data source bindings in the applications can be resolved on every cluster in which
they run. If implementing database sharing across the clusters, the previous statement refers to both
the shared and non-shared domains; all domains should use the same names.
v Installing WebSphere Portal on the primary node
v Configuring Portal to use a database
3. Optional: Using the same database user ID and password for each identically named domain/data
source will allow the existing JAAS Authentication Aliases to be functional. If unique database user
ID and password are required, additional manual configuration is needed to create new JAAS
Authentication Aliases for each data source and map these accordingly. On the primary node of
Cluster A, run the ./ConfigEngine.sh create-alias-multiple-cluster
-DauthDomainList=release,jcr -DWasPassword=dmgr_password task from the wp_profile_root/
ConfigEngine directory to create the new JAAS Authentication Aliases.
where authDomainList is set to a list of domains which use unique database user ID and passwords
and those domain properties are set correctly in the wkplc_comp.properties file, including user ID
and password.
4. Optional: If necessary, upgrade Portal B to the current cumulative fix.
5. If you are adding a dynamic cluster and IBM WebSphere Virtual Enterprise is not already installed
on Portal B, install it, apply all required ifixes, and augment the wp_profile profile to make it
compatible with WebSphere Extended Deployment Operations Optimization. See the "Planning the
product installation" link in Related section for information about installing WebSphere Virtual
Enterprise. Profile augmentation is completed using the Profile Management Tool (PMT) graphical
interface on systems that support it or through the manageprofiles command that is available on all
systems. When using the graphical interface, make sure you select Operations Optimization when
choosing the type of augmentation to complete. When using the manageprofiles command, be sure
to follow the instructions to augment a stand-alone application server profile.
6. Run the ./ConfigEngine.sh mapped-app-list-create -DWasPassword=password task from the
wp_profile_root/ConfigEngine directory to build an inventory list of Portal B enterprise applications
and portlets.
password.
8. Run the following command from the wp_profile_root\bin directory to federate Portal B:
addNode.sh dmgr_hostname dmgr_port -includeapps
Installing 453
different than the Deployment Manager administrator user ID and password, add the following
parameters to the addNode task:
rerunning the task:
a. Remove the node if the AddNode task succeeded in creating the node.
directory:
deployment manager.
10. Run the ./ConfigEngine.sh map-apps-to-server -DWasPassword=password task to determine which
applications from the inventory list are no longer mapped to Portal B. The task uses the application
profiles already in the cell to restore the mappings. Wait 30 minutes after running this task to allow
all EAR files to expand before proceeding to the next step.
11. Complete the following post-federation configuration steps for Portal B:
a. Ensure that all database parameters are correctly set, including passwords, in the
wkplc_comp.properties and wkplc_dbtype.properties files.
b. Run the ./ConfigEngine.sh cluster-node-config-post-federation
c. The WebSphere Portal node is federated and using the Deployment Manager cell and its user
security policies:
Restriction: If your Deployment Manager cell is using a stand-alone LDAP user registry,
complete these steps after the cluster-node-config-cluster-setup (static cluster) or
cluster-node-config-dynamic-cluster-setup (dynamic cluster) task completes.
d. From the WebSphere Integrated Solutions Console, click System Administration > Node Agents.
e. Check the box next to the required node agent and then click Restart.
f. Stop and restart the deployment manager.
g. Stop and restart the WebSphere_Portal server on Portal B
12. Restart the WebSphere_Portal server on Cluster A. Verify that Cluster A is functionally intact by
spot checking pages and portlets and then verify that Portal B is functionally intact by spot checking
pages and portlets that you deployed into Portal B before it was federated. Any discrepancies or
errors should be corrected now before continuing.
Note: If Portal B is using a nondefault Portal server administrative ID, not wpsadmin, the server will
not be functional until the cluster configuration is complete and the Portal administrative ID has
been configured to match the Cells security settings.
13. Choose one of the following options to define a cluster using Portal B as the basis:
v Complete the following steps to define a static cluster using Portal B as the basis:
a. Run the ./ConfigEngine.sh cluster-node-config-cluster-setup
b. Configure the cluster to use an external web server to take advantage of features such as
workload management. Choose one of the following options:
Configuring a web server and an application server on separate machines (remote)
Configuring a web server and an application server profile on the same machine
Configuring a web server and a deployment manager profile on the same machine
Note: Start with the step about launching the Plug-ins installation wizard.
c. Complete the following steps to access the Web Content Manager content through an external
web server:
1) Log on to the deployment manager WebSphere Integrated Solutions Console.
2) Select Environment > WebSphere Variables.
3) From the Scope drop-down menu, select the Node=nodename, Server=servername option to
4) Update the WCM_HOST variable with the fully qualified host name used to access the
WebSphere Portal server through the web server or On Demand Router.
5) Update the WCM_PORT variable with the port number used to access the WebSphere Portal
server through the web server or On Demand Router.
d. Save your changes and then restart the deployment manager, the node agent(s), and the
WebSphere_Portal servers.
Installing 455
v Complete the following steps to define a dynamic cluster using Portal B as the basis:
b. Complete the following steps to create a node group:
1) Click New.
2) Type the node group Name.
3) Type any information about the node group in the Description text box.
4) Click OK.
5) Click the Save link to save your changes to the master configuration.
c. Complete the following steps to add members to the node group:
1) Click System administration > Node groups.
2) Click the name of the node group that you want to add members to.
3) Click Node group members under Additional Properties.
4) Click Add.
5) Select the primary node and then click Add.
d. Complete the following steps to create a dynamic cluster in the node group:
1) Click Servers > Clusters > Dynamic clusters.
2) Click New.
3) Select WebSphere Application Server from the Server Type pull-down menu and then
click Next.
4) Type the cluster name in the Dynamic cluster name text box and then click Next. Type
the same value that you provided for the ClusterName parameter in the wkplc.properties
file of your primary node.
5) Remove all default membership policies and then click Subexpression builder.
6) Enter the following information in the Subexpression builder window:
a) Select and from the Logical operator pull-down menu.
b) Select Nodegroup from the Select operand pull-down menu.
c) Select Equals (=) from the Operator pull-down menu.
d) Type the nodegroup name you created in the previous step in the Value text box.
e) Click Generate subexpression.
f) Click Append.
7) Click Preview membership to verify that all nodes included in the nodegroup display
and then click Next.
8) Click the Create the cluster member using an existing server as a template radio button
and then select the WebSphere_Portal server for the primary node from the pull-down
menu.
9) Click Next.
10) Specify the required dynamic cluster properties for minimum and maximum number of
server instances.
11) Review the summary page to verify your actions and then click Finish.
e. Define or verify the following parameters in the wkplc.properties file, located in the
1) Verify that CellName is set to the deployment manager cell.
2) Verify that NodeName is set to the local WebSphere Portal node.
3) Set ServerName to the server that is used for the dynamic cluster member on this node.
4) Verify that PrimaryNode is set to true.
f. Run the ./ConfigEngine.sh cluster-node-config-dynamic-cluster-setup
dynamic cluster.
g. Complete the following steps to access the Web Content Manager content through an external
web server:
h. Save your changes and then restart the deployment manager, the node agent(s), and the
14. Install any additional nodes to the cell to support additional cluster members for Cluster B
identically to the primary node, and then federate as them as secondary nodes and define as cluster
members on these nodes. For information about adding additional nodes navigate to Installing
WebSphere Portal > Setting up a cluster. Select the appropriate operating system and navigate to
Preparing additional nodes. You can add additional nodes to a static or dynamic cluster, and you
can also add additional vertical cluster members to an existing node in a static or dynamic cluster to
provide vertical scaling.
Remember: If you are creating a multiple, dynamic cluster, remember to install WebSphere Virtual
Enterprise on the additional node and augment the Portal profile with WebSphere Virtual Enterprise.
15. Restart the WebSphere_Portal server on Cluster A and Cluster B.
16. After setting up your multiple clusters, there are additional tasks that you can complete to ensure a
balanced workload and failover support.
v Update the web server configuration to enable user requests to be routed to the new cluster. Refer
"Routing requests across clusters" for information about using a web server with multiple clusters
in a cell.
v Update your database configuration to share database domains between clusters. Refer to "Sharing
database domains between clusters for information about redundancy and failover support.
Installation of Cluster B is complete. It is now an independent cluster from Cluster A, which means that
Cluster B can have its own configuration, set of user portlets, and target community. Any applications
that are common between Cluster A and Cluster B are most likely infrastructure or related to
administration, and special care needs to be taken to preserve their commonality between clusters and
correct maintenance levels.
Installing 457
Related tasks:
AIX cluster: Configuring Portal to use a database on page 292
Recommended fixes for WebSphere Extended Deployment
Routing requests across clusters on AIX:
The HTTP Server plug-in that comes with IBM WebSphere Application Server is typically used to balance
requests for applications across members of the cluster. You can also use the On Demand Router (ODR)
in dynamic, multicluster environments for routing. While an application can be mapped to more than one
cluster, automatic plug-in generation does not provide routing or balancing traffic for the same
application across multiple clusters. Multiple cluster environments with shared applications therefore
cannot rely solely on WebSphere Application Server automatic plug-in generation to be able to route
requests using a web server. One option in this scenario is developing a customized method for defining
and maintaining the plug-in configuration file used by the web server to provide for the required routing
of user requests.
An important consideration in a multiple cluster environment is ensuring that all subsequent HTTP
requests for a user are routed to the same cluster that processed the first HTTP request. The WebSphere
Portal login processing depends upon preserving this cluster affinity during this initial time until the user
has successfully logged in and session cookies maintain affinity. In order to guarantee that affinity is
preserved during login, set the Navigator Service public.session parameter to a value of true; you
should also set this parameter to true if you are using an ODR. Refer to "Portal Configuration Services"
for information on how to configure this parameter.
cluster.
Related concepts:
WebSphere Virtual Enterprise Dynamic Clusters on page 112
Related reference:
Sharing database domains between clusters on AIX
To help provide redundancy and failover support in production environments composed of multiple
clusters in a single cell and multiple clusters in different cells, you can share database domains between
those clusters. IBM WebSphere Portal data is organized into different database domains, with different
availability requirements depending on how the production environment is set up. When multiple lines
of production are involved and each line of production is implemented as a cluster of servers, sharing
database domains ensures that the data is automatically synchronized across the lines of production.
Manager.
Complete the following steps to share database domains when setting up an environment with multiple
clusters:
1. Set up the first cluster (referred to as Cluster A in these instructions).
2. Determine which database domains you want to share with any other clusters in the environment.
3. Install the primary node of the next cluster (Cluster B), and complete the following steps to configure
the node to use the shared database domains.
a. Complete a partial database transfer of the database domains that you are not sharing.
For example, if you are sharing only the Customization and Community domains, you would
transfer the remaining domains to the database you are using for Cluster B.
b. Re-configure the shared database domains on the node to connect to the shared database domains
you are using for Cluster A.
Installing 459
For example, to connect to the Customization and Community domains for Cluster A, you would
connect to those domains from Cluster B.
4. Continue setting up the primary node as described in the cluster instructions.
5. Install the secondary node of Cluster B, and complete the following steps to configure the node to use
the shared database domains.
a. For those database domains that you are not sharing between clusters, re-configure the domains to
connect to the database domains you are using for Cluster B.
As in the example for the primary node, if you are sharing only the Customization and
Community domains, re-configure the remaining domains on the secondary node to use the
domains of the primary node for Cluster B.
6. Continue setting up the secondary node as described in the cluster instructions.
Related tasks:
AIX cluster: Tune your servers on page 448
should be used.
Connecting to existing database domains on page 2331
View the steps to share a database domain between two separate WebSphere Portal instances (instance1
and instance2), where instance2 is connected to a instance1 database domain.
Installing Web Content Manager into an existing Server installation on
AIX
If you initially installed the IBM WebSphere Portal Server installation, you can purchase the Content
license agreement and install the IBM Web Content Manager features into your existing installation.
Complete the following steps to install Web Content Manager into an existing Server installation:
Cluster note: In a clustered environment, complete these steps on all the nodes.
Response file note: You can record and run a response file to install the Web Content Manager features
on your existing Server installation. See Use response files to install for information. Use the following
steps when recording your response file. Ensure that you exit from the IBM Installation Manager program
to complete your recording.
1. Stop all the application servers.
2. Open the IBM Installation Manager and complete the following steps to add the content repository:
a. Go to File > Preferences > Repositories.
c. Select Browse and navigate to the WebSphere Portal content repository.
d. Select the content repository file.
e. Click OK.
f. Ensure that all required repositories are checked.
g. Ensure that the content repository is after the Server repository in the list.
h. Click Test Connections to ensure that the IBM Installation Manager can successfully access the
directory where the repository is stored.
i. Select Apply.
j. Select OK.
4. On the Install Package: Select packages to install panel, check the box for the additional package that
you purchased. Then click Next.
5. Accept the license agreement and then click Next.
6. On the Location panel, select the Use the existing package group radio button. Select the IBM
WebSphere Portal V8 package group name and then click Next.
7. On the Features panel, check the box for the additional feature that you purchased. Then click Next.
8. Verify the information on the Summary panel and then click Install.
9. After the installation successfully completes, stop and restart the appropriate servers to propagate
the changes. For specific instructions, see Starting and stopping servers, deployment managers, and
node agents on page 2550.
10. Complete the following steps if you created multiple profiles outside of the IBM Installation
Manager:
a. Open a command prompt in the wp_profile_root/ConfigEngine directory of each profile.
b. Run the ./ConfigEngine.sh enable-wcm -DWasPassword=password task on each profile.
c. Stop and restart the appropriate servers to propagate the changes. For specific instructions, see
Starting and stopping servers, deployment managers, and node agents.
Installing on IBM i
Installing 461
WebSphere Portal.
Setting up a stand-alone production server on IBM i
Preparing your IBM i operating system in a stand-alone environment
You need the following information to install locally:
v IBM i CD-ROM drive
v The IBM i server must be in an unrestricted state
v A valid IBM i user ID and password
v A user profile with a user type (user class) of *SECOFR (other than QSECOFR) to install and configure
WebSphere Portal
Related tasks:
com.ibm.websphere.installation.nd.iseries.doc/info/iseriesnd/ae/tins_is_prep.html
Installing WebSphere Portal on IBM i
authentication.
Related concepts:
Related tasks:
Stand-alone: Installing with the response file on IBM i:
WebSphere Application Server in a stand-alone environment. Modify the appropriate sample response
file, located in the setup_root/responsefiles/iseries directory.
options:
Installing 463
4. Run the installc -acceptLicense task to install the IBM Installation Manager from the IBM
Installation Manager media.
Note: If you have an existing IBM Installation Manager, search for updates to the latest supported
version.
5. Manually update the appropriate sample response file, located in the setup_root/responsefiles/
iseries directory, based on your offering.
Attention: Replace the following lines in the sample response files if you installed WebSphere
Application Server and WebSphere Portal from the live repository (Passport Advantage):
v <offering id=8.0.0.3-WS-WASProd-TFPM60134 version=8.0.3.20120312_1656
profile=IBM WebSphere Application Server Network Deployment V8.0 features=-/>
Replace with
v <offering id=8.0.0.3-WS-WASProd-IFPM60134 version=8.0.3.20120425_1032
Use the IBM Installation Manager command-line tool imutilsc from the installation tools directory to
encrypt the WebSphere Portal administrator password string. Enter the encrypted password in the
response file. The following is an example of the imutilsc encryption command:
imutilsc encryptString stringToEncrypt
Note: If installing on a different computer, copy the updated response file to the response file
directory on that computer.
Tip: If you want to record a custom response file, you can record a response file using a different
operating system. After recording the response file on the other operating system, you must modify
the file for IBM i. Then copy the response file to your IBM i server.
imutilsc saveCredential -url repository_URL -userName credential_userName
[ -useSocks ] ]
[ -verbose ]
7. From your installation tools directory, run the imcl -acceptLicense input pathtoresponse.xml -log
pathtologfiles task to install WebSphere Portal and IBM WebSphere Application Server.
details: Advanced panel during installation, complete the steps in Changing the portal URI on page
2197.
2. Complete the following steps if you want to configure the Portal application server to use a 64-bit
SDK:
a. Stop the WebSphere_Portal server.
b. Open a command prompt and change to the following directory: AppServer_root/bin.
c. Run the managesdk -enableProfile -profileName profile -sdkname 1.6_64 task to switch the
Portal profile to a 64-bit SDK.
d. Change to the wp_profile_root/ConfigEngine directory.
e. Run the ConfigEngine.sh modify-jvm-heap-size -DWasPassword=password task to adjust the JVM
max heap size to support the 64-bit SDK.
SDK:
Related tasks:
Installing Web Content Manager into an existing Server installation on IBM i on page 590
Stand-alone: Performing post-installation tasks on IBM i
Installing 465
1. Optional: After the WebSphere Portal installation completes successfully, run the ConfigEngine.sh
> Users and Groups.
Libraries.
b. Add the following line to the file:
LDAP configuration.
d. Run the ConfigEngine.sh express-memberfixer -DPortalAdminPwd=password
Related tasks:
Preparing your IBM i operating system in a stand-alone environment on page 462
IBM i stand-alone: Preparing DB2 for IBM i
Related tasks:
Installing WebSphere Portal on IBM i on page 463
authentication.
IBM i stand-alone: Modifying properties for DB2 for IBM i:
Installing 467
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
- question mark (?)
Notes:
IBM DB2 for i.
server.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 469
JDBC driver class.
IBM i stand-alone: Creating groups and assigning users for IBM DB2 for i:
Note:
database transfer.
IBM i stand-alone: Creating user profiles for DB2 for IBM i:
Before you begin:
can be shared.
new password.
environment.
Related tasks:
IBM i stand-alone: Modifying properties for DB2 for IBM i on page 467
IBM i stand-alone: Creating databases on DB2 for IBM i:
A remote database resides on a different system than WebSphere Portal. When you use a remote server,
you must manually create the databases that are required by WebSphere Portal.
Before you begin:
v The user ID and password used must have the authority to create database libraries on the remote
System i5 machine.
v For every property instance of a database that uses *LOCAL/schema, replace it with HostName/schema.
Installing 471
For example, the default database and database library name for WebSphere Portal release domain is
release.DbName=wpsdb. If you wanted to create this database library on a remote database, change the
default value to release.DbName=hostname/wpsdb
To create all the domain database libraries, perform the following steps:
1. Start a 5250 session on the remote database machine.
2. Type the IBM i command WRKRDBDIRE to display the Relational Database Directory Entry for Remote
Location *LOCAL and make a note of the value displayed.
3. Sign off from the 5250 session.
4. Start a 5250 session on the local machine where WebSphere Portal is installed.
5. Create a Relational Database Directory Entry on the local system for the remote system using IBM i
command WRKRDBDIRE.
6. Add an entry with the following values:
Relational database
The remote relational database. Use the value noted from the prior step.
Relational database alias
The hostname. Use the short TCP/IP hostname of the remote system
Remote location
The domain qualified hostname. Use the full TCP/IP hostname of the remote system
Type IP
Port number or service name
DRDA
Remote authentication method
Preferred method: ENCRYPTED
Allow lower authentication: ALWLOWER
7. Create the required DB2 packages on the remote database machine by running the following
command from the local machine: JAVA CLASS(com.ibm.db2.jdbc.app.DB2PackageCreator)
PARM('rdb_alias' 'userid' 'password') PROP((jdbc.drivers
'com.ibm.as400.access.AS400JDBCDriver'))where rdb_alias matches the name of the Relational
Database Entry you created in step 2, where userid is the database administrator user ID on the
remote machine, and where password is the database administrator password on the remote machine.
The output should be: Java program completed
8. Press F3 to exit Java Shell Display.
11. Verify the required DB2 packages were created by running the command WRKOBJ OBJ(QGPL/QSQCL*)
OBJTYPE(*SQLPKG) The output should be:
Opt Object Type Library Attribute Text
QSQCLIPKGA *SQLPKG QGPL PACKAGE
QSQCLIPKGC *SQLPKG QGPL PACKAGE
QSQCLIPKGL *SQLPKG QGPL PACKAGE
QSQCLIPKGN *SQLPKG QGPL PACKAGE
QSQCLIPKGS *SQLPKG QGPL PACKAGE
13. On the command line, enter the following to change directories: cd wp_profile_root/ConfigEngine.
14. Press Enter.
15. Change the property values in the configuration properties files before entering the following on the
command line: ConfigEngine.sh create-database
16. Press Enter.
Related tasks:
IBM i stand-alone: Creating groups and assigning users for IBM DB2 for i on page 470
IBM i stand-alone: Granting privileges to IBM DB2 for i database users:
create-database
database user:
Installing 473
tasks:
create-database
Related tasks:
IBM i stand-alone: Creating user profiles for DB2 for IBM i on page 471
IBM i stand-alone: Configuring the portal to use DB2 for IBM i:
Installing 475
Before you begin:
the task to stall.
Note:
Related tasks:
IBM i stand-alone: Creating databases on DB2 for IBM i on page 471
IBM i stand-alone: Verifying the DB2 for IBM i configuration:
Installing 477
Related tasks:
IBM i stand-alone: Creating databases on DB2 for IBM i on page 471
IBM i stand-alone: Granting privileges to IBM DB2 for i database users on page 473
IBM i stand-alone: Preparing a remote Web server
directive.
server topology diagram and road map for information.
feature:
f. Click OK.
Related tasks:
authentication.
Related reference:
IBM i stand-alone: Configuring Portal to use a user registry
LDAP user registry.
Installing 479
information.
Related tasks:
authentication.
IBM i stand-alone: Preparing DB2 for IBM i on page 467
Managing your user registry on IBM i on page 3101
IBM i stand-alone: Preparing a Tivoli Directory Server:
1. Customize the LDAP directory servers settings using the Directory Services Configuration Wizard.
You must have *ALLOBJ and *IOSYSCFG special authority to use the wizard. Go to IBM System i and
IBM i Information Center, select the appropriate Information Center version and navigate to
e-business and Web serving > Security and IBM Tivoli Directory Server for i5/OS (LDAP) > IBM
Tivoli Directory Server for i5/OS (LDAP) for information.
group.
2. Complete the following steps to create the WebSphere Portal administrative user:
1) Go to IBM System i and IBM i Information Center, select the appropriate Information Center
version and navigate to Networking > TCP/IP applications, protocols, and services > IBM
Directory Server for iSeries (LDAP) > Administering Directory Server > General
administration tasks > Adding and Removing Directory Server suffixes for information.
2) Stop and restart the LDAP server.
with a text editor:
your LDAP server.
f. Optional: If using IBM Tivoli Access Manager Version 5.1, set the objectclasses to accessGroup. If
using Tivoli Access Manager Version 6, set the objectclasses to groupOfNames.
g. Save your changes.
h. Follow the instructions provided with your directory server to import the LDIF file.
IBM i stand-alone: Choosing your user registry model:
IBM i stand-alone: Configuring a stand-alone LDAP user registry:
IBM i stand-alone: Configuring a stand-alone LDAP user registry without SSL:
Installing 481
standalone.ldap.id
8. Run the ConfigEngine.sh validate-standalone-ldap -DWasPassword=password task to validate your
9. Run the ConfigEngine.sh wp-modify-ldap-security -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to set the standalone LDAP user registry.
11. Run the ConfigEngine.sh wp-validate-standalone-ldap-attribute-config -DWasPassword=password
task, from the wp_profile_root/ConfigEngine directory, to check that all defined attributes are available
in the configured LDAP user registry.
LDAP configuration.
ignore this line.
d. Run the ConfigEngine.sh run-wcm-admin-task-member-fixer -DallLibraries=true -Dfix=true
Content Manager
Type of LDAP Value
Installing 483
Internet libraries.
Related tasks:
IBM i cluster: Adapting the attribute configuration on page 564
IBM i stand-alone: Configuring a stand-alone LDAP user registry over SSL:
standalone.ldap.id
Installing 485
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Installing 487
Related tasks:
IBM i stand-alone: Configuring the default federated repository:
IBM i stand-alone: Configuring a federated LDAP user registry:
IBM i stand-alone: Adding an LDAP user registry without SSL:
federated.ldap.id
federated.ldap.host
federated.ldap.port
7. Run the ConfigEngine.sh validate-federated-ldap -DWasPassword=password task to validate your
8. Run the ConfigEngine.sh wp-create-ldap -DWasPassword=password task, from the
repository.
Installing 489
parameters.
id
baseDN
nameInRepository
d. Run the ConfigEngine.sh wp-create-base-entry -DWasPassword=password task, from the
11. Optional: Run the ConfigEngine.sh wp-query-repository -DWasPassword=password task, from the
12. Run the ConfigEngine.sh wp-validate-federated-ldap-attribute-config -DWasPassword=password
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
d. Run the ConfigEngine.sh wp-set-entitytypes -DWasPassword=password task, from the
attributes.
d. Run the ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=password task,
ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=password task to disable the
feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Installing 491
Internet libraries.
LDAP user registry:
Important:
cluster.
a. Run the following task from the wp_profile_root/ConfigEngine directory: ConfigEngine.sh
c. Run the following task from the wp_profile_root/ConfigEngine directory: ConfigEngine.sh
Related tasks:
Deleting the repository on IBM i on page 3123
IBM i stand-alone: Adding an LDAP user registry over SSL:
Installing 493
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
Installing 495
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 497
Related tasks:
Deleting the repository on IBM i on page 3123
IBM i stand-alone: Adding a database user registry:
file.
2. Complete the following steps to create the IBM DB2 for i database:
a. Login to a remote IBM i session.
b. Enter the strsql command to start the interactive sql session.
c. Enter the create schema database_name command, where database_name is the name you want to
use for the database.
a. Go to the following directory: wp_profile_root/ConfigEngine/properties directory.
heading:
db_type.DbDriver
db_type.DbLibrary
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbName
Installing 499
a. Run the ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password
database jars.
for example db2_iseries. The local path of the database jars on the Deployment Manager should be
one of the following options:
IBM DB2 for i Type 2 driver: /QIBM/ProdData/Java400/ext/db2_classes.jar
IBM DB2 for i Type 4 driver: /QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar
1) Set the property value for federated.db.DbType if using a database user registry or if the cell
is migrated from a previous version and set the property value for la.DbType if using a
property extension database in the wkplc.properties file.
2) Run the ConfigEngine.sh wp-node-prep-vmm-db-secured-environment
VMM database jars.
8. Run the ConfigEngine.sh wp-create-db -DWasPassword=password task, from the
repository.
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
IBM i stand-alone: Adding realm support:
Installing 501
realmName
securityUse
delimiter
addBaseEntry
5. Run the ConfigEngine.sh wp-create-realm -DWasPassword=password task, from the
configuration.
realmName
realm.groupParent
8. Run the ConfigEngine.sh wp-modify-realm-defaultparents -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to update the default parents per entity type and realm.
then run this task:
parameters.
realmName
addBaseEntry
d. Run the ConfigEngine.sh wp-add-realm-baseentry -DWasPassword=password task, from the
configuration.
d. Run the ConfigEngine.sh wp-change-was-admin-user -DWasUser=adminid
user and group.
f. Run the ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password
group.
d. Run the ConfigEngine.sh wp-default-realm -DWasPassword=password task, from the
Installing 503
d. Run the ConfigEngine.sh wp-query-realm-baseentry -DWasPassword=password task, from the
feature.
IBM i stand-alone: Adapting the attribute configuration:
repositories.
LDAP schema
Related tasks:
IBM i stand-alone: Preparing a Tivoli Directory Server on page 480
IBM i stand-alone: Querying the define attributes:
Run the ConfigEngine.sh wp-query-attribute-config -DWasPassword=password task, from the
IBM i stand-alone: Adding attributes:
Application Server.
c. Run the ConfigEngine.sh wp-la-install-ear -DWasPassword=password task.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
7. Run the ConfigEngine.sh wp-add-property -DWasPassword=password task to add the attribute to the
user registry.
Installing 505
Related tasks:
IBM i stand-alone: Mapping attributes:
your LDAP server:
standalone.ldap.id
Table 183. Identifying your LDAP server in the wkplc.properties file. (continued)
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:
Stand-alone ConfigEngine.sh wp-validate-standalone-ldap-
Federated ConfigEngine.sh wp-validate-federated-ldap-
Installing 507
parameters.
standalone.ldap.id
heading:
parameters.
registry:
Stand-alone ConfigEngine.sh wp-update-standalone-ldap-attribute-
config -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory
Federated ConfigEngine.sh wp-update-federated-ldap-attribute-
parameters.
c. Run the ConfigEngine.sh wp-update-attribute-config -DWasPassword=password task, from the
Related tasks:
IBM i stand-alone: Querying the define attributes on page 505
IBM i stand-alone: Removing attributes:
model directory.
Installing 509
directory.
or
database:
Related tasks:
IBM i stand-alone: Querying the define attributes on page 505
IBM i stand-alone: Adding attributes on page 505
IBM i stand-alone: Configuring Portal to use dynamic groups:
nodes.
v Name: memberurl
Related tasks:
IBM i stand-alone: Choosing your user registry model on page 481
IBM i stand-alone: Enabling referrals for your LDAP user registry:
Installing 511
Related tasks:
IBM i stand-alone: Choosing your user registry model on page 481
IBM i stand-alone: Adapting the attribute configuration on page 504
IBM i stand-alone: Tune your servers
should be used.
Related tasks:
authentication.
IBM i stand-alone: Preparing DB2 for IBM i on page 467
Setting up a cluster on IBM i
dynamic.
Installing 513
Preparing your IBM i operating system in a clustered environment
You need the following information to install locally:
v IBM i CD-ROM drive
v The IBM i server must be in an unrestricted state
v A valid IBM i user ID and password
v A user profile with a user type (user class) of *SECOFR (other than QSECOFR) to install and configure
WebSphere Portal
Related tasks:
com.ibm.websphere.installation.nd.iseries.doc/info/iseriesnd/ae/tins_is_prep.html
Preparing the primary node on IBM i
Installing WebSphere Portal on IBM i on the primary node:
Related concepts:
Related tasks:
Creating a Portal custom profile on IBM i on page 1698
Preparing the system for multiple profile support on IBM i on page 1696
Clustered environment: Installing with the response file on IBM i:
and IBM WebSphere Application Server in a clustered environment. Modify the appropriate sample
response file, located in the setup_root/responsefiles/iseries directory.
options:
Installing 515
version.
Replace with
[ -useSocks ] ]
[ -verbose ]
details: Advanced panel during installation, complete the steps in Changing the portal URI on page
2197.
SDK:
SDK:
Clustered environment: Performing post-installation tasks on IBM i:
Installing 517
1. Optional: After the WebSphere Portal installation completes successfully, run the ConfigEngine.sh
> Users and Groups.
Libraries.
b. Add the following line to the file:
LDAP configuration.
d. Run the ConfigEngine.sh express-memberfixer -DPortalAdminPwd=password
IBM i clustered server: Setting up a remote database:
Related tasks:
Installing WebSphere Portal on IBM i on the primary node on page 515
IBM i clustered server: Preparing DB2 for IBM i:
IBM i clustered server: Modifying DB2 for IBM i database properties:
Installing 519
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
- question mark (?)
Notes:
IBM DB2 for i.
server.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 521
JDBC driver class.
IBM i clustered server: Creating groups and assigning users for IBM DB2 for i:
Note:
database transfer.
IBM i clustered server: Creating DB2 for IBM i user profiles:
Before you begin:
can be shared.
new password.
environment.
Related tasks:
IBM i clustered server: Modifying DB2 for IBM i database properties on page 519
IBM i clustered server: Creating remote DB2 for IBM i databases:
Before you begin:
Installing 523
v The user ID and password used must have the authority to create database libraries on the remote
System i5 machine.
v For every property instance of a database that uses *LOCAL/schema, replace it with HostName/schema.
For example, the default database and database library name for WebSphere Portal release domain is
release.DbName=wpsdb. If you wanted to create this database library on a remote database, change the
default value to release.DbName=hostname/wpsdb
To create all the domain database libraries, perform the following steps:
2. Type the IBM i command WRKRDBDIRE to display the Relational Database Directory Entry for Remote
Location *LOCAL and make a note of the value displayed.
5. Create a Relational Database Directory Entry on the local system for the remote system using IBM i
command WRKRDBDIRE.
6. Add an entry with the following values:
Relational database
The remote relational database. Use the value noted from the prior step.
Relational database alias
The hostname. Use the short TCP/IP hostname of the remote system
Remote location
The domain qualified hostname. Use the full TCP/IP hostname of the remote system
Type IP
Port number or service name
DRDA
Remote authentication method
Preferred method: ENCRYPTED
Allow lower authentication: ALWLOWER
7. Create the required DB2 packages on the remote database machine by running the following
command from the local machine: JAVA CLASS(com.ibm.db2.jdbc.app.DB2PackageCreator)
PARM('rdb_alias' 'userid' 'password') PROP((jdbc.drivers
'com.ibm.as400.access.AS400JDBCDriver'))where rdb_alias matches the name of the Relational
Database Entry you created in step 2, where userid is the database administrator user ID on the
remote machine, and where password is the database administrator password on the remote machine.
The output should be: Java program completed
8. Press F3 to exit Java Shell Display.
11. Verify the required DB2 packages were created by running the command WRKOBJ OBJ(QGPL/QSQCL*)
OBJTYPE(*SQLPKG) The output should be:
Opt Object Type Library Attribute Text
QSQCLIPKGA *SQLPKG QGPL PACKAGE
QSQCLIPKGC *SQLPKG QGPL PACKAGE
QSQCLIPKGL *SQLPKG QGPL PACKAGE
QSQCLIPKGN *SQLPKG QGPL PACKAGE
QSQCLIPKGS *SQLPKG QGPL PACKAGE
13. On the command line, enter the following to change directories: cd wp_profile_root/ConfigEngine.
14. Press Enter.
15. Change the property values in the configuration properties files before entering the following on the
command line: ConfigEngine.sh create-database
16. Press Enter.
Related tasks:
IBM i clustered server: Creating groups and assigning users for IBM DB2 for i on page 522
IBM i clustered server: Granting privileges to IBM DB2 for i database users:
create-database
database user:
Installing 525
tasks:
create-database
Related tasks:
IBM i clustered server: Creating DB2 for IBM i user profiles on page 523
IBM i clustered server: Transferring DB2 for IBM i manually:
Installing 527
Before you begin:
the task to stall.
Note:
Related tasks:
IBM i clustered server: Creating remote DB2 for IBM i databases on page 523
IBM i clustered server: Verifying the DB2 for IBM i configuration:
Installing 529
Related tasks:
IBM i clustered server: Creating remote DB2 for IBM i databases on page 523
IBM i clustered server: Granting privileges to IBM DB2 for i database users on page 525
Removing search collections on IBM i:
Collections.
deleted.
Related tasks:
Clustered environment: Performing post-installation tasks on IBM i on page 517
Creating the WebSphere Portal profile template on IBM i in a clustered environment:
1. Run the ConfigEngine.sh enable-profiles -DWasPassword=password task, from the
Portal profiles. The Portal.car file is saved to the PortalServer_root/offer/portal/profileTemplates/
default.portal/configArchives directory, where offer is either content or server.
2. Run the ConfigEngine.sh package-profiles -DWasPassword=password task to compress the
Related tasks:
Clustered environment: Performing post-installation tasks on IBM i on page 517
IBM i clustered server: Setting up a remote database on page 518
Creating and augmenting a new Deployment Manager profile on IBM i
Installing 531
2. You can either use an existing Deployment Manager profile or you can run the following command
from the AppServer_root/bin directory:
manageprofiles -create -templatePath AppServer_root/profileTemplates/management
-hostName hostname
-profileName Dmgr01
Restriction: If you plan to use the back up and restore task documented in the product
documentation, you must use the default profile path for the deployment manager profile; otherwise,
the back up and restore tasks cannot locate the profile.
deployment manager:
for example this may be a subdirectory under the AppServer directory and it contains the bin and
profileTemplates directories.
4. Run the following command from the AppServer_root/bin directory:
manageprofiles.sh -augment -templatePath AppServer_root/profileTemplates/management.portal.augment
-profileName dmgr
Tip: If you have a long command, use the continuation character "\" to avoid seeing the "not found"
error message.
In this example, the portal profile template is installed under the AppServer_root/profileTemplates
directory. The existing Deployment Manager profile is named dmgr and is located under the
AppServer_root/profiles/Dmgr01 directory.
e. Click Apply.
g. Click Apply.
Related tasks:
Preparing your IBM i operating system in a clustered environment on page 514
Clustered environment: Installing with the response file on IBM i on page 515
and IBM WebSphere Application Server in a clustered environment. Modify the appropriate sample
response file, located in the setup_root/responsefiles/iseries directory.
Creating the cluster on IBM i
Installing 533
password.
addNode dmgr_hostname dmgr_port -includeapps
administrator
rerunning the task:
directory:
deployment manager.
c. Run the ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password
the database jars.
Oracle: ojdbc14.jar
d. Run the ConfigEngine.sh wp-node-prep-vmm-db-secured-environment -DWasPassword=password
-DDbDomain=la|federated.db -DVmmNodeName=node_name -Ddb_type.NodeDbLibrary=local full
path of the database jars task from the wp_profile_root/ConfigEngine directory to create the
variable used to access the VMM database jars.
5. Run the ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password task.
configuration
these steps after the cluster-node-config-cluster-setup task completes.
Installing 535
Save your changes and then run the ConfigEngine.sh wp-change-portal-admin-user
7. Run the ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password task.
information.
Related tasks:
Preparing the primary node on IBM i on page 514
Preparing the Web server when portal is installed on IBM i in a clustered
environment
directive.
server topology diagram and road map for information.
feature:
f. Click OK.
server:
Installing 537
Related tasks:
Creating and augmenting a new Deployment Manager profile on IBM i on page 531
Related reference:
IBM i cluster: Preparing user registries
Related tasks:
IBM i cluster: Preparing a Tivoli Directory Server for IBM i:
1. Customize the LDAP directory servers settings using the Directory Services Configuration Wizard.
You must have *ALLOBJ and *IOSYSCFG special authority to use the wizard. Go to IBM System i and
IBM i Information Center, select the appropriate Information Center version and navigate to
e-business and Web serving > Security and IBM Tivoli Directory Server for i5/OS (LDAP) > IBM
Tivoli Directory Server for i5/OS (LDAP) for information.
group.
2. Complete the following steps to create the WebSphere Portal administrative user:
1) Go to IBM System i and IBM i Information Center, select the appropriate Information Center
version and navigate to Networking > TCP/IP applications, protocols, and services > IBM
Directory Server for iSeries (LDAP) > Administering Directory Server > General
administration tasks > Adding and Removing Directory Server suffixes for information.
2) Stop and restart the LDAP server.
with a text editor:
your LDAP server.
f. Optional: If using IBM Tivoli Access Manager Version 5.1, set the objectclasses to accessGroup. If
using Tivoli Access Manager Version 6, set the objectclasses to groupOfNames.
g. Save your changes.
h. Follow the instructions provided with your directory server to import the LDIF file.
Configuring WebSphere Portal to use a user registry on IBM i in a clustered
environment
LDAP user registry.
information.
Installing 539
Related tasks:
Choosing your user registry model on IBM i in a clustered environment:
Choosing your stand-alone LDAP user registry on IBM i in a clustered environment:
IBM i cluster: Configuring a stand-alone LDAP user registry without SSL:
standalone.ldap.id
Installing 541
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Content Manager (continued)
Type of LDAP Value
Internet libraries.
Related tasks:
Configuring a stand-alone LDAP user registry over SSL on IBM i in a clustered environment:
Installing 543
standalone.ldap.id
Installing 545
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Related tasks:
Configuring the default federated repository on IBM i in a clustered environment:
Configuring a federated LDAP user registry on IBM i in a clustered environment:
Adding an LDAP user registry on IBM i in a clustered environment:
Installing 547
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
Installing 549
attributes.
feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 551
Related tasks:
Adding an LDAP user registry over SSL on IBM i in a clustered environment:
federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 553
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
feature.
Installing 555
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 557
Related tasks:
Adding a database user registry on IBM i in a clustered environment:
file.
2. Complete the following steps to create the IBM DB2 for i database:
a. Login to a remote IBM i session.
b. Enter the strsql command to start the interactive sql session.
c. Enter the create schema database_name command, where database_name is the name you want to
use for the database.
a. Go to the following directory: wp_profile_root/ConfigEngine/properties directory.
heading:
db_type.DbDriver
db_type.DbLibrary
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbName
a. Run the ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password
database jars.
for example db2_iseries. The local path of the database jars on the Deployment Manager should be
one of the following options:
Installing 559
1) Set the property value for federated.db.DbType if using a database user registry or if the cell
is migrated from a previous version and set the property value for la.DbType if using a
property extension database in the wkplc.properties file.
2) Run the ConfigEngine.sh wp-node-prep-vmm-db-secured-environment
VMM database jars.
8. Run the ConfigEngine.sh wp-create-db -DWasPassword=password task, from the
repository.
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
Adding realm support on IBM i in a clustered environment:
realmName
securityUse
delimiter
addBaseEntry
Installing 561
5. Run the ConfigEngine.sh wp-create-realm -DWasPassword=password task, from the
configuration.
realmName
realm.groupParent
8. Run the ConfigEngine.sh wp-modify-realm-defaultparents -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory, to update the default parents per entity type and realm.
then run this task:
parameters.
realmName
addBaseEntry
d. Run the ConfigEngine.sh wp-add-realm-baseentry -DWasPassword=password task, from the
configuration.
d. Run the ConfigEngine.sh wp-change-was-admin-user -DWasUser=adminid
user and group.
group.
d. Run the ConfigEngine.sh wp-default-realm -DWasPassword=password task, from the
d. Run the ConfigEngine.sh wp-query-realm-baseentry -DWasPassword=password task, from the
Installing 563
feature.
Related tasks:
IBM i cluster: Adapting the attribute configuration:
repositories.
LDAP schema
Related tasks:
IBM i stand-alone: Adding an LDAP user registry without SSL on page 488
IBM i stand-alone: Adding an LDAP user registry over SSL on page 493
IBM i stand-alone: Configuring a stand-alone LDAP user registry without SSL on page 481
IBM i stand-alone: Configuring a stand-alone LDAP user registry over SSL on page 484
IBM i cluster: Querying the defined attributes:
Run the ConfigEngine.sh wp-query-attribute-config -DWasPassword=password task, from the
Adding attributes on IBM i in a clustered environment:
2. Complete the followings steps to install the required Enterprise Archive (.ear) file on WebSphere
Application Server.
b. Go to the wp_profile_root/ConfigEngine directory on the primary node.
c. Run the ConfigEngine.sh wp-la-install-ear -DWasPassword=dmgr_password
Installing 565
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
7. Run the ConfigEngine.sh wp-add-property -DWasPassword=password task to add the attribute to the
user registry.
Related tasks:
Mapping attributes on IBM i in a clustered environment:
your LDAP server:
standalone.ldap.id
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:
Stand-alone ConfigEngine.sh wp-validate-standalone-ldap-
Federated ConfigEngine.sh wp-validate-federated-ldap-
Installing 567
parameters.
standalone.ldap.id
heading:
parameters.
registry:
Stand-alone ConfigEngine.sh wp-update-standalone-ldap-attribute-
Federated ConfigEngine.sh wp-update-federated-ldap-attribute-
parameters.
c. Run the ConfigEngine.sh wp-update-attribute-config -DWasPassword=password task, from the
Related tasks:
IBM i cluster: Removing attributes:
Installing 569
model directory.
directory.
or
database:
IBM i cluster: Configuring Portal to use dynamic groups in a clustered environment:
nodes.
v Name: memberurl
IBM i cluster: Enabling referrals for your LDAP user registry in a clustered environment:
Installing 571
Preparing additional cluster members on IBM i
Related tasks:
Installing WebSphere Portal on IBM i for the horizontal cluster nodes:
Related concepts:
Related tasks:
Additional node: Installing with the response file on IBM i:
additional nodes, you must specify the product binary installation parameter. Modify the appropriate
sample response file, located in the setup_root/responsefiles/iseries directory.
options:
version.
Installing 573
Replace with
[ -useSocks ] ]
[ -verbose ]
Adding horizontal nodes to the cluster on IBM i:
manageprofiles -create -templatePath
/QIBM/ProdData/WebSphere/PortalServer/V8/portal_family/profileTemplates/managed.portal
-profilePath /QIBM/UserData/WebSphere/AppServer/V8/ND/profiles/testManagedPortal1
-cellName testCell
-nodeName testNode
error message.
In this example, the portal profile template is installed under the /QIBM/ProdData/WebSphere/
PortalServer/V8/portal_family/profileTemplates/managed.portal directory. The new profile is
named testManagedPortal1 and is located under the /QIBM/UserData/WebSphere/AppServer/V8/ND/
profiles/testManagedPortal1 directory.
4. Run the ConfigEngine.sh validate-database -DWasPassword=password task to validate your database
settings.
Installing 575
node:
addNode dmgr_hostname dmgr_port
profiles/wp_profile/ConfigEngine/properties directory of the additional cluster node:
c. Run the ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password
Oracle: ojdbc14.jar
d. Run the ConfigEngine.sh wp-node-prep-vmm-db-secured-environment -DWasPassword=password
-DDbDomain=la|federated.db -DVmmNodeName=node_name -Ddb_type.NodeDbLibrary=local full
path of the database jars task from the wp_profile_root/ConfigEngine directory to create the
variable used to access the VMM database jars.
security policies:
configuration
these steps after the cluster-node-config-cluster-setup-additional task completes.
Installing 577
10. Run the ConfigEngine.sh cluster-node-config-cluster-setup-additional
following steps:
v LD_LIBRARY_PATH
v LIBPATH
v PATH
v SHLIB_PATH
g. Run the ConfigEngine.sh profile-update-entries task to update these entries with the correct
profile paths.
server:
a. stopServer.sh WebSphere_Portal_servername -username admin_userid -password
admin_password
b. startServer.sh WebSphere_Portal_servername
Adding vertical cluster members to a static cluster on IBM i:
members.
d. Click Apply and then click Next to view the summary.
Important: If you are not using an external web server in your clustered environment, you must
update the virtual host entries for the new port created when adding a cluster member. You can do
this by updating the default_host virtual host in the WebSphere Integrated Solutions Console and
adding a new alias entry for the port number (use an "*" wildcard character for the host name). See
Configuring virtual hosts for information.
members.
f. Click OK.
6. Complete the following steps on each vertical cluster member to clean up the server-scoped
resources, caches, and resource providers:
a. Run the ConfigEngine.sh cluster-node-config-vertical-cluster-setup -DServerName=unique
vertical cluster servername -DWasPassword=password task, from the wp_profile_root/
ConfigEngine directory on the node where you created the vertical cluster. unique vertical cluster
servername is the name you specified when you created the cluster member.
Installing 579
setup task.
server:
Resynchronize.
a. Regenerate the web server plug-in using the deployment manager WebSphere Integrated
Solutions Console.
b. If you are using a remote web server, copy the updated plug-in configuration file
(plugin-cfg.xml) to the web server's plug-in configuration directory.
Related tasks:
Installing WebSphere Portal on IBM i for the horizontal cluster nodes on page 572
IBM i cluster: Tune your servers
should be used.
Related tasks:
Configuring search in a cluster on IBM i
Related tasks:
Preparing additional cluster members on IBM i on page 572
Configuring Portal Search in a cluster on IBM i:
Installing 581
Portal cluster.
accordingly.
Notes:
Related concepts:
Portal Search.
Related tasks:
Configuring JCR search in a cluster on IBM i:
directory.
search
portlet:
e. Click OK.
deleted.
for information.
Installing 583
Setting up multiple clusters on IBM i
new profile.
please contact IBM.
Related tasks:
IBM i cluster: Tune your servers on page 580
should be used.
Installing multiple clusters in a single cell on IBM i:
already exists.
Cluster A, run the ConfigEngine.sh create-alias-multiple-cluster -DauthDomainList=release,jcr
-DWasPassword=dmgr_password task from the wp_profile_root/ConfigEngine directory to create the new
JAAS Authentication Aliases.
and password.
5. Run the ConfigEngine.sh mapped-app-list-create -DWasPassword=password task from the
wp_profile_root/ConfigEngine directory to build an inventory of Portal B enterprise applications and
portlets.
password.
Installing 585
rerunning the task:
directory:
deployment manager.
9. Run the ConfigEngine.sh map-apps-to-server -DWasPassword=password task to determine which
10. Run the ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password task.
security policies:
configuration
these steps after the cluster-node-config-cluster-setup task completes.
13. Complete the following steps to define a cluster using Portal B as the basis:
a. Run the ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password
task.
Recommended remote distributed installation
Local distributed installation
web server:
WebSphere Portal > Setting up a cluster on IBM i > Preparing additional nodes on IBM i. You can
add additional nodes and/or vertical clusters.
in a cell.
Installing 587
Related tasks:
IBM i clustered server: Setting up a remote database on page 518
Routing requests across clusters on IBM i:
of user requests.
Sharing database domains between clusters on IBM i
Manager.
clusters:
Installing 589
Related tasks:
IBM i cluster: Tune your servers on page 580
should be used.
IBM i
Response file note: Run the sample response file to install the Web Content Manager features on your
existing Server installation. See Use response files to install for information. For IBM i you should edit the
appropriate sample response file located in the setup_root/responsefiles/iseries directory because you
can not record the response file from your operating system. You can record a response file on another
operating system using the following steps when recording your response file. Ensure that you exit from
the IBM Installation Manager program to complete your recording. You must edit the response file that
you recorded to add your IBM i specific parameters.
Replace with
[ -useSocks ] ]
[ -verbose ]
5. After the installation successfully completes, stop and restart the appropriate servers to propagate the
changes. For specific instructions, see Starting and stopping servers, deployment managers, and node
agents on page 2550.
Installing 591
6. Complete the following steps if you created multiple profiles outside of the IBM Installation Manager:
b. Run the ConfigEngine.sh enable-wcm -DWasPassword=password task on each profile.
Rendering documents on IBM i
In order to enable document preview functionality for IBM Web Content Manager and the Common Mail
portlet, you must set up an HTML rendering server to work with WebSphere Portal. Because IBM i does
not contain native graphics support, you must install additional fonts to perform the document
conversion required by these functions. Document conversion enables WebSphere Portal to convert
documents produced by commonly used office programs into Web pages, so that they can be viewed and
searched by users online. The additional fonts include an HTML rendering server known as X virtual
frame buffer for the X server.
Before you begin, you must have:
A WebSphere Portal profile running on your IBM i system; record the name of your WebSphere Portal
profile for future reference.
OS/400 - Additional Fonts (5761SS1, Option 43) or OS/400 - Additional Fonts (5770SS1, Option 43).
After setting up your HTML rendering server, you must also enable the Document Conversion Services.
See Related tasks for the link to Document Conversion Services.
Complete the following tasks on each WebSphere Portal node to render documents on IBM i:
Note: The HTML rendering server (X virtual frame buffer for X server) that you associate with your
WebSphere Portal profile should only be used for WebSphere Portal. Using the HTML rendering server
with other applications may cause problems.
Related tasks:
Enabling Document Conversion Services on page 2317
Document Conversion Services are used when working with the Common Mail Portlet, WCM authoring
and previewing, and search.
Configuring an HTML rendering server on IBM i
After you have installed OS/400 - Additional Fonts (5761SS1, Option 43), which is for Version 6R1, or
OS/400 - Additional Fonts (5770SS1, Option 43), which is for Version 7R1, on your IBM i system, an
HTML rendering server (X virtual frame buffer for X server) is present. You must select a display number
for the HTML rendering server.
Complete the following steps to configure an HTML rendering server:
1. If the QShell Interpreter is running, perform the following commands on the IBM i command line to
stop it:
QSH
Press F3
2. Type CALL QP2TERM on the command line to start the OS/400 Portable Application Solutions
Environment (OS/400 PASE) console.
3. Type ps gaxuw | grep Xvnc ; ps gaxuw | grep vfb on the command line to list all active HTML
rendering servers:
Note: If other rendering servers are already active, you might see output such as this (the number
after the colon is the display number already in use):
v2kea554 40571 0.0 0.0 12484 0 - A Jul 13 4:08
/QOpenSys/QIBM/ProdData/DeveloperTools/vnc/Xvnc :6 -desktop X -httpd
4. Select any number from 1 to 99 that is not in use.
5. Press F3 to return to the command line interface.
6. Type SBMJOB CMD(CALL PGM(QP2SHELL) PARM('/usr/bin/X11/X' '-vfb' ':N')) JOB(XVFB)
JOBQ(QSYSNOMAX) ALWMLTTHD(*YES) on the command line to start the HTML rendering server, where N
is the display number.
7. Verify that the HTML rendering server is started by repeating the prior steps to start PASE and list
the active servers, confirming that an HTML rendering server with your display number is in the list.
After rendering your documents, you must enable the document conversion services. See Enabling
Document Conversion Services on page 2317 for information.
Associating an HTML rendering server with WebSphere Portal on IBM i
After selecting a display number for the HTML rendering server (X virtual frame buffer for X server),
you must associate this server with the installed IBM WebSphere Portal profile.
Complete the following steps to associate the HTML rendering server (X virtual frame buffer for X
server) with WebSphere Portal:
1. Log on to the WebSphere Integrated Solutions Console.
2. Go to Servers > Server Types > WebSphere application servers > WebSphere_Portal > Server
Infrastructure > Java and Process Management > Process definition > Environment Entries.
3. Click New.
4. In the Name field type DISPLAY.
5. In the Value field type host_name:n, where host_name is the TCP/IP host name of your system and n
is the display number of the HTML rendering server. (Example: mysystem.xland.company.com:1).
6. Click OK.
7. Save your changes to the master WebSphere Application Server configuration file.
8. Complete the following steps to stop and restart the WebSphere_Portal server, where WebSphere_Portal
is the name of the WebSphere Portal server:
a. Open a command prompt and change to the wp_profile_root/bin directory.
b. Enter the stopServer WebSphere_Portal -username admin_userid -password admin_password
command to stop the WebSphere Portal server.
c. Enter the startServer WebSphere_Portal command.
After rendering your documents, you must enable the document conversion services. See Enabling
Document Conversion Services on page 2317 for information.
Installing on Linux
Installing 593
WebSphere Portal.
Setting up a stand-alone production server on Linux
Preparing your Linux operating system in a stand-alone environment
Complete the following steps to prepare your Linux operating system:
1. The IBM Installation Manager is a 32-bit application and requires 32-bit versions of the operating
system libraries. These libraries are not installed on RHEL 6.x x86_64 (64-bit) by default. You must
install them on your system before you run the Installation Manager. Run the following tasks to
install the libraries:
v yum install gtk2.i686
v yum install libXtst.i686
v yum install gtk2-engines.i686
v yum install libcanberra-gtk2.i686
v yum install PackageKit-gtk-module.i686
Tip: Alternatively, you can install all the libraries with one task:
yum install gtk2.i686 libXtst.i686 gtk2-engines.i686 libcanberra-gtk2.i686 PackageKit-gtk-module.i686
3. Web Content Manager only: Complete the following steps to remove any file size limits:Use the
ulimit -f command to set the maximum size of files that can be created to be at least the size of the
largest file you would need to upload to the content server. The command ulimit -f unlimited
removes any limit on file size.
b. Run the ulimit -a command to get a list of all the ulimit settings.
c. Find the -f parameter. If the value is unlimited, no further action is required.
d. If the -f parameter is not unlimited, choose one of the following options:
v Set the ulimit -f unlimited value permanently on your Linux box. See your system
documentation for information.
v Run the ulimit -f unlimited command for each session without making the change
permanent.
4. Install and configure X server on Linux (for example X-Windows or GNOME) to use the graphical
user interface the installation program provides. See your system documentation for information on
adding packages.
Related tasks:
com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_linuxsetup.html
Installing WebSphere Portal on Linux
authentication.
Installing 595
Related concepts:
Related tasks:
Stand-alone: Installing with the Installation Manager on Linux:
options:
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
click OK.
stored.
e. Select Apply.
Installing 597
f. Select OK.
b. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
l. Click Next.
page 2197.
Stand-alone: Installing with the response file on Linux:
Installing 599
options:
Advantage):
Replace with
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
response file:
Installing 601
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
directory path.
path.
3) Click Next.
Next.
computer.
[ -useSocks ] ]
[ -verbose ]
Stand-alone: Performing post-installation tasks on Linux
> Users and Groups.
Libraries.
Installing 603
LDAP configuration.
Related tasks:
Preparing your Linux operating system in a stand-alone environment on page 594
Linux stand-alone: Configuring your portal to use a database
Related tasks:
Installing WebSphere Portal on Linux on page 595
authentication.
Linux stand-alone: Setting up a remote DB2 database:
Linux stand-alone: Installing DB2:
Before you begin:
required databases.
Note:
1. Before installing DB2, log in with a user ID that has administrative authority.
The system user ID and password must match the database user ID and password for the WebSphere
Portal databases. If you do not use the default DB2 database user ID, or if you must access a remote
database, create the system user ID before installing DB2.
3. Perform the following steps to set up the environment for the database access:
a. 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.
b. After you create the system user ID and password for the DB2 installation, add the user ID to the
DB2 administration group (such as db2adm) for that system.
To ensure that the user is set up correctly, login with this user ID and start the DB2 command line
processor by executing the command: db2. If the command line processor displays, the user ID is set
up correctly.
Installing 605
Related tasks:
Linux stand-alone: Modifying DB2 database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 607
driver class.
Linux stand-alone: Creating groups and assigning users:
Related tasks:
Linux stand-alone: Installing DB2 on page 605
Linux stand-alone: Creating DB2 databases:
databases manually.
Related tasks:
Linux stand-alone: Modifying DB2 database properties on page 606
Linux stand-alone: Creating a local DB2 database automatically:
Linux stand-alone: Creating a remote or local DB2 database manually:
running.
Installing 609
instance owner.
that you run:
Notes:
six times.
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
Linux stand-alone: Setting up DB2 automatically or manually:
Related tasks:
Linux stand-alone: Creating groups and assigning users on page 608
Linux stand-alone: Running a task to automatically setup DB2 databases:
Installing 611
Linux stand-alone: Setting up DB2 manually:
Linux stand-alone: Creating DB2 database schemas:
users
admins
guests
public
local
IBM
SQL
SYS
environment.
createSchema.sql
Table 203. List of SQL script templates by database domain (continued)
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
Linux stand-alone: Granting privileges to DB2 database administration users:
Installing 613
to schema-owning configuration database users (continued)
database user:
users
Installing 615
to non-schema-owning runtime database users (continued)
Related concepts:
Linux stand-alone: Assigning custom DB2 table spaces:
Before you begin:
database transfer.
Installing 617
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Linux stand-alone: Configuring JCR collation support:
for instructions.
server:
b. Run the command:
using password.
# English
# Swedish
Installing 619
Related tasks:
Linux stand-alone: Creating DB2 databases on page 608
databases manually.
Linux stand-alone: Configuring your portal to use DB2:
View the steps to manually transfer data to the DB2 database you have installed and set up. Follow these
steps to transfer WebSphere Portal, and Java Content Repository databases to DB2. As an alternative to
the manual database transfer procedure that this topic describes, you can use the configuration wizard to
complete the database transfer task. However, you cannot specify all settings through the configuration
wizard. For example, regardless of the method used to transfer data, you must run a configuration task
to create JMS resources as described in this topic. For this reason, you must specify the required settings
in the appropriate property files before transferring the database with the configuration wizard.
Before you begin:
Tips:
Repository schema.
the task to stall.
Note:
v If you have been storing data in Apache Derby for a long time, database transfer could fail with
OutOfMemory exceptions. If database transfer fails, add the following property to the command
in this step: ConfigEngine.bat database-transfer -DDbtJavaMaxMemory=1536M
user must have sufficient database user privileges. To grant the database user privileges, choose either
the manual steps or the command line steps:
files:
v createRuntimeRoleForDifferentSchema.sql if the name of the database user and the schema
name are not the same.
v createRuntimeRoleForSameSchema.sql if the name of the database user and the schema name
are the same.
PortalServer_root/jcr/wp.content.repository.install/config/templates/setupdb/dbms/jcr/
grantPermissionsToRuntimeRoleStatic.sql .
Note: You only need to add -DTransferDomainList=comma_separated_list_of_domains to this task
when granting privileges across specific domains.
Installing 621
using password
Note: Additional options might be required if additional security has been installed. Refer to DB2
Universal Database commands by example for links to the command reference.
db2 terminate
-p password
Related tasks:
databases manually.
Linux stand-alone: Setting up DB2 automatically or manually on page 611
Linux stand-alone: Enabling DB2 pureScale load balancing feature:
6. Click OK.
Installing 623
Related tasks:
databases manually.
Linux stand-alone: Configuring DB2 for large file handling in WCM:
Related tasks:
databases manually.
Linux stand-alone: Configuring your portal to use DB2 on page 620
Linux stand-alone: Type 2 driver support:
Installing 625
Related tasks:
databases manually.
Linux stand-alone: Configuring your portal to use DB2 on page 620
Linux stand-alone: Enabling DB2 pureScale load balancing feature on page 623
Linux stand-alone: Changing DB2 driver types:
configuration task.
Note:
JDBC driver.
Linux stand-alone: Configuring Type 2 DB2 drivers:
Installing DB2
Installing 627
Portal.
The system user ID and password must match the database user ID and password for the
WebSphere Portal databases. If you do not use the default DB2 database user ID, or if you must
access a remote database, create the system user ID before installing DB2.
up correctly.
name.
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
driver class.
instance owner.
Installing 629
that you run:
Notes:
of six times.
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
domain.
Installing 631
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
the following command. This command exports the DB2 user's profile onto the administrative user
so that they can access the DB2 utilities.
Note:
files:
name are the same.
using password
Installing 633
db2 terminate
-p password
Linux stand-aloneserver: Preparing IBM DB2 for i:
Linux stand-alone: Modifying properties for IBM DB2 for i:
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
Installing 635
- question mark (?)
Notes:
IBM DB2 for i.
server.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Installing 637
Linux stand-alone: Creating groups and assigning users for IBM DB2 for i:
Note:
database transfer.
Linux stand-alone: Creating user profiles for IBM DB2 for i:
Before you begin:
can be shared.
new password.
environment.
Related tasks:
Linux stand-alone: Modifying properties for IBM DB2 for i on page 634
Linux stand-alone: Creating and setting up IBM DB2 for i databases automatically:
Related tasks:
Linux stand-alone: Creating groups and assigning users for IBM DB2 for i on page 638
Linux stand-alone: Granting privileges to IBM DB2 for i database users:
create-database
Installing 639
database user:
tasks:
create-database
Installing 641
Related concepts:
Related tasks:
Linux stand-alone: Creating user profiles for IBM DB2 for i on page 638
Linux stand-alone: Configuring your portal to use IBM DB2 for i:
Before you begin:
the task to stall.
Note:
Related tasks:
Linux stand-alone: Creating and setting up IBM DB2 for i databases automatically on page 638
Linux stand-alone: Verifying the IBM DB2 for i configuration:
Installing 643
Related tasks:
Linux stand-alone: Creating and setting up IBM DB2 for i databases automatically on page 638
Linux stand-alone: Granting privileges to IBM DB2 for i database users on page 639
Linux stand-alone: Preparing DB2 for z/OS:
server.
Linux stand-alone: Installing DB2 for z/OS:
following commands:
following commands:
export EXTSHM=ON
db2start
profile.env file:
DB2ENVLIST=EXTSHM
export EXTSHM=ON
remote database.
Linux stand-alone: Modifying DB2 for z/OS properties:
jcr.DbName=jcrdb
Installing 645
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
Note:
for the domain.
DbName.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
this value.
driver class.
Installing 647
Linux stand-alone: Using JCL templates to set up DB2 for z/OS:
created.
successfully.
authority.
on the database
authority.
Table 212. The templates and their descriptions. (continued)
Related tasks:
Linux stand-alone: Installing DB2 for z/OS on page 644
Linux stand-alone: Creating DB2 for z/OS users:
installation.
Installing 649
(R) - at runtime
where:
data.
Related tasks:
Linux stand-alone: Modifying DB2 for z/OS properties on page 645
Linux stand-alone: Creating databases on DB2 for z/OS:
machine.
the databases.
Installing 651
500 DEFINE NO;
Related tasks:
Linux stand-alone: Using JCL templates to set up DB2 for z/OS on page 648
Linux stand-alone: Granting privileges to DB2 for z/OS users:
database user:
Installing 653
Related concepts:
Related tasks:
Linux stand-alone: Creating DB2 for z/OS users on page 649
Linux stand-alone: Assigning custom DB2 for z/OS tablespaces:
Before you begin:
PADIX=NO, or both.
database transfer.
following values:
Installing 655
v release
v community
v customization
v jcr
v feedback
v likeminds
Related tasks:
Linux stand-alone: Creating databases on DB2 for z/OS on page 651
Linux stand-alone: Configuring your portal to use DB2 for z/OS:
Before you begin:
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 657
...
Related tasks:
Linux stand-alone: Creating databases on DB2 for z/OS on page 651
Linux stand-alone: Granting privileges to DB2 for z/OS users on page 652
Linux stand-alone: Setting up a remote Oracle or Oracle RAC database:
Linux stand-alone: Installing Oracle or Oracle RAC:
Before you begin:
Considerations:
LD_LIBRARY_PATH=/u01/app/oracle/product/11.2.0/client_1;export LD_LIBRARY_PATH
Installing 659
$ gsdctl start
$ lsnrctl start
$ agentctl start
Linux stand-alone: Modifying Oracle or Oracle RAC database properties:
to the Oracle database.
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
Installing 661
class.
Linux stand-alone: Creating Oracle or Oracle RAC databases:
information:
Server Mode.
pre_page_sga = true
as follows:
FORCE
Installing 663
EXACT
Related tasks:
Linux stand-alone: Installing Oracle or Oracle RAC on page 659
Linux stand-alone: Setting up Oracle or Oracle RAC automatically or manually:
Note:
database.
Related tasks:
Linux stand-alone: Modifying Oracle or Oracle RAC database properties on page 660
Linux stand-alone: Running a task to automatically setup Oracle or Oracle RAC:
privileges.
Note:
Linux stand-alone: Setting up Oracle or Oracle RAC manually:
Linux stand-alone: Creating Oracle or Oracle RAC database schemas and users:
Before you begin:
installation.
environment.
createUsers.sql
createUsers.sql
Installing 665
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
Linux stand-alone: Granting privileges to Oracle or Oracle RAC database users:
database user:
Installing 667
Installing 669
Related concepts:
Linux stand-alone: Creating JCR table spaces:
environment.
command.
Linux stand-alone: Assigning custom Oracle or Oracle RAC table spaces:
Before you begin:
Installing 671
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
COMM8KSPACE
Linux stand-alone: Configuring your portal to use Oracle or Oracle RAC:
Oracle database you have installed and set up. Follow these steps to transfer Portal, and Java Content
Repository databases to Oracle. As an alternative to the manual database transfer procedure described
here, you can use the configuration wizard to complete the database transfer task.
Before your begin:
Tips:
Repository schema.
Installing 673
files:
name are the same.
SQL > commit;
Exit sqlplus
Related tasks:
Linux stand-alone: Creating Oracle or Oracle RAC databases on page 663
Technote 1317981
Linux stand-alone: Changing Oracle or Oracle RAC driver types:
configuration task.
Installing 675
Related tasks:
Linux stand-alone: Creating Oracle or Oracle RAC databases on page 663
Linux stand-alone: Setting up Oracle or Oracle RAC automatically or manually on page 664
Linux stand-alone: Setting up a SQL Server database:
Linux stand-alone: Installing SQL Server:
information.
sqljdbc_xa.dll
Linux stand-alone: Modifying SQL Server database properties:
jcr.DbName=jcrdb
Installing 677
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Linux stand-alone: Setting up SQL Server automatically or manually:
Installing 679
table spaces.
Note:
database.
Related tasks:
Linux stand-alone: Installing SQL Server on page 676
Linux stand-alone: Setting up SQL Server automatically:
This section provides instructions for automatically setting up your database using the ConfigEngine task.
privileges. There are also optional configuration tasks that are not provided to you by running the
ConfigEngine task. To learn more about manually configuring SQL Server or other optional manual
configuration tasks, refer to the manual configuration are of this section.
Linux stand-alone: Running a task to automatically setup SQL server databsaes:
privileges.
4. Click Files.
Autogrowth field.
Linux stand-alone: Setting up SQL Server manually:
Linux stand-alone: Creating databases manually on SQL Server:
Linux stand-alone: Creating SQL Server database schemas and users:
Before you begin:
installation.
Installing 681
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
Linux stand-alone: Granting privileges to SQL Server database users:
database user:
Installing 683
Installing 685
Related concepts:
Linux stand-alone: Assigning custom SQL Server filegroups:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Installing 687
Linux stand-alone: Configuring your portal to use SQL Server:
Before you begin:
Tips:
Repository schema.
files:
name are the same.
Installing 689
Related tasks:
Linux stand-alone: Installing SQL Server on page 676
Linux stand-alone: Modifying SQL Server database properties on page 677
Linux stand-alone: Verifying the database configuration:
environment.
source is wpdbDS.
Linux stand-alone: Preparing a remote Web server
directive.
feature:
f. Click OK.
Installing 691
Related tasks:
authentication.
Related reference:
Linux stand-alone: Configuring Portal to use a user registry
LDAP user registry.
information.
Related tasks:
authentication.
Linux stand-alone: Configuring your portal to use a database on page 604
Managing your user registry on Linux on page 3125
Linux stand-alone: Preparing user registries:
Linux stand-alone: Preparing a Domino Directory Server:
Center.
Server installation > Installing Domino on Linux and complete this task.
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Installing 693
Internet password
wpsadmin
Group name
wpsadmins
Group type
Multi-purpose
Members
members.
the file.
Editor access.
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
Linux stand-alone: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
Linux stand-alone: Preparing a Novell eDirectory:
4) Click Add.
with a text editor:
your LDAP server.
Linux stand-alone: Preparing an Oracle Directory Server:
Portal.
Installing 695
4) Click Add.
with a text editor:
your LDAP server.
Linux stand-alone: Preparing a Tivoli Directory Server:
group.
4) Click Add.
with a text editor:
your LDAP server.
Linux stand-alone: Choosing your user registry model:
Linux stand-alone: Configuring a stand-alone LDAP user registry:
Linux stand-alone: Configuring a stand-alone LDAP user registry without SSL:
standalone.ldap.id
Installing 697
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Installing 699
Internet libraries.
Related tasks:
Linux cluster: Adapting the attribute configuration on page 869
Linux stand-alone: Configuring a stand-alone LDAP user registry over SSL:
standalone.ldap.id
Installing 701
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Installing 703
Related tasks:
Linux stand-alone: Configuring the default federated repository:
Linux stand-alone: Configuring a federated LDAP user registry:
Linux stand-alone: Adding an LDAP user registry without SSL:
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
Installing 705
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Installing 707
Internet libraries.
LDAP user registry:
Important:
cluster.
Related tasks:
Deleting the repository on Linux on page 3148
Linux stand-alone: Adding an LDAP user registry over SSL:
Installing 709
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
Installing 711
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 713
Related tasks:
Deleting the repository on Linux on page 3148
Linux stand-alone: Adding a database user registry:
file.
Database Steps
1. Install DB2.
db_files = 1024
log_buffer = 65536
pre_page_sga = true
processes = 300
Installing 715
Database Steps
heading:
db_type.DbDriver
db_type.DbLibrary
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbName
database jars.
Oracle: ojdbc14.jar
VMM database jars.
repository.
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
Installing 717
attributes.
Related tasks:
Linux stand-alone: Adding realm support:
realmName
securityUse
delimiter
addBaseEntry
configuration.
realmName
realm.groupParent
then run this task:
parameters.
realmName
addBaseEntry
configuration.
user and group.
Installing 719
group.
the feature.
Linux stand-alone: Adapting the attribute configuration:
repositories.
LDAP schema
Linux stand-alone: Querying the defined attributes:
Linux stand-alone: Adding attributes:
Installing 721
Application Server.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
Related tasks:
Linux stand-alone: Mapping attributes:
your LDAP server:
standalone.ldap.id
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:
Installing 723
parameters.
standalone.ldap.id
heading:
parameters.
registry:
parameters.
Linux stand-alone: Removing attributes:
model directory.
Installing 725
directory.
or
database:
Linux stand-alone: Configuring your portal to use dynamic groups:
nodes.
v Name: memberurl
Linux stand-alone: Enabling referrals for your LDAP user registry:
Installing 727
Linux stand-alone: Tune your servers
should be used.
Related tasks:
authentication.
Linux stand-alone: Configuring your portal to use a database on page 604
Setting up a cluster on Linux
dynamic.
Installing 729
Preparing your Linux operating system in a clustered environment
Complete the following steps to prepare your Linux operating system:
permanent.
3. Install and configure X server on Linux (for example X-Windows or GNOME) to use the graphical
user interface the installation program provides. See your system documentation for information on
adding packages.
Related tasks:
com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_linuxsetup.html
Preparing the primary node on Linux
Installing WebSphere Portal on Linux on the primary node:
Related concepts:
Related tasks:
Creating a Portal custom profile on Linux on page 1706
Preparing the system for multiple profile support on Linux on page 1704
Clustered environment: Installing with the Installation Manager on Linux:
options:
Installing 731
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
click OK.
stored.
e. Select Apply.
f. Select OK.
Manager.
b. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
Installing 733
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
l. Click Next.
page 2197.
Clustered environment: Installing with the response file on Linux:
options:
Advantage):
Replace with
Installing 735
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
response file:
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
Installing 737
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
n. Click Next.
computer.
[ -useSocks ] ]
[ -verbose ]
Clustered environment: Performing post-installation tasks on Linux:
Installing 739
> Users and Groups.
Libraries.
LDAP configuration.
Linux clustered server: Configuring your portal to use a database:
Related tasks:
Installing WebSphere Portal on Linux on the primary node on page 730
Linux clustered server: Setting up a remote DB2 database:
Linux clustered server: Installing DB2:
Before you begin:
required databases.
Note:
Installing 741
The system user ID and password must match the database user ID and password for the WebSphere
Portal databases. If you do not use the default DB2 database user ID, or if you must access a remote
database, create the system user ID before installing DB2.
up correctly.
Related tasks:
Linux clustered server: Modifying DB2 database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Notes:
understand.
releaseDS
Installing 743
communityDS
customizationDS
jcrDS
lmdbDS
feedback
driver class.
Linux clustered server: Creating groups and assigning users:
Related tasks:
Linux clustered server: Installing DB2 on page 741
Linux clustered server: Creating DB2 databases:
databases manually.
Related tasks:
Linux clustered server: Modifying DB2 database properties on page 742
Linux clustered server: Creating a local DB2 database automatically:
Linux clustered server: Creating a remote or local DB2 database manually:
Installing 745
running.
instance owner.
that you run:
Notes:
six times.
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
Linux clustered server: Setting up DB2 automatically or manually:
Installing 747
Related tasks:
Linux clustered server: Creating groups and assigning users on page 744
Linux clustered server: Running a task to automatically setup DB2 databases:
Linux clustered server: Setting up DB2 manually:
Linux clustered server: Creating DB2 database schemas:
users
admins
guests
public
local
IBM
SQL
SYS
environment.
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
Linux clustered server: Granting privileges to DB2 database users:
Installing 749
database user:
users
users (continued)
Installing 751
Installing 753
Related concepts:
Linux clustered server: Assigning custom DB2 table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Linux clustered server: Collecting JCR collation support:
for instructions.
server:
b. Run the command:
using password.
# English
Installing 755
# Swedish
Related tasks:
Linux clustered server: Creating DB2 databases on page 745
databases manually.
Linux clustered server: Configuring your portal to use DB2:
Before you begin:
Tips:
Repository schema.
the task to stall.
Note:
files:
are the same.
Installing 757
using password
db2 terminate
-p password
Related tasks:
databases manually.
Linux clustered server: Setting up DB2 automatically or manually on page 747
independent of whether you created your DB2 databases locally or remotely.
Linux clustered server: Enabling DB2 pureScale load balancing feature:
6. Click OK.
Installing 759
Related tasks:
databases manually.
Linux clustered server: Configuring DB2 for large file handling in WCM:
Related tasks:
databases manually.
Linux clustered server: Configuring your portal to use DB2 on page 756
Linux clustered server: Type 2 driver support:
Installing 761
Related tasks:
databases manually.
Linux clustered server: Configuring your portal to use DB2 on page 756
Linux clustered server: Enabling DB2 pureScale load balancing feature on page 759
Linux clustered server: Changing DB2 driver types:
configuration task.
Note:
JDBC driver.
Linux clustered server: Configuring Type 2 DB2 drivers:
Installing DB2
Installing 763
Portal.
The system user ID and password must match the database user ID and password for the
WebSphere Portal databases. If you do not use the default DB2 database user ID, or if you must
access a remote database, create the system user ID before installing DB2.
up correctly.
name.
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
driver class.
instance owner.
Installing 765
that you run:
Notes:
of six times.
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
domain.
Installing 767
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Note:
files:
name are the same.
using password
Installing 769
db2 terminate
-p password
Linux clustered server: Setting up IBM DB2 for i:
Linux clustered server: Modifying IBM DB2 for i database properties:
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
- question mark (?)
Notes:
Installing 771
IBM DB2 for i.
server.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Linux clustered server: Creating groups and assigning users for IBM DB2 for i:
Installing 773
Note:
database transfer.
Linux clustered server: Create IBM DB2 for i user profiles:
Before you begin:
can be shared.
new password.
environment.
Related tasks:
Linux clustered server: Modifying IBM DB2 for i database properties on page 770
Linux clustered server: Creating and setting up IBM DB2 for i databaes automatically:
Related tasks:
Linux clustered server: Creating groups and assigning users for IBM DB2 for i on page 773
Linux clustered server: Granting privileges to IBM DB2 for i database users:
create-database
Installing 775
database user:
tasks:
create-database
Installing 777
Related concepts:
Related tasks:
Linux clustered server: Create IBM DB2 for i user profiles on page 774
Linux clustered server: Transferring IBM DB2 for i manually:
Before you begin:
the task to stall.
Note:
Related tasks:
Linux clustered server: Creating and setting up IBM DB2 for i databaes automatically on page 774
Linux clustered server: Verifying IBM DB2 for i database connections:
Installing 779
Related tasks:
Linux clustered server: Creating and setting up IBM DB2 for i databaes automatically on page 774
Linux clustered server: Granting privileges to IBM DB2 for i database users on page 775
Linux clustered server: Setting up a remote DB2 for z/OS database:
Linux clustered server: Installing DB2 for z/OS:
following commands:
following commands:
export EXTSHM=ON
db2start
profile.env file:
DB2ENVLIST=EXTSHM
export EXTSHM=ON
remote database.
Linux clustered server: Modifying DB2 for z/OS database properties:
jcr.DbName=jcrdb
Installing 781
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
Note:
for the domain.
DbName.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
this value.
driver class.
Installing 783
Linux clustered server: Using JCL templates to set up DB2 for z/OS:
created.
successfully.
authority.
on the database
authority.
Related tasks:
Linux clustered server: Installing DB2 for z/OS on page 780
Linux clustered server: Creating DB2 for z/OS users:
installation.
Installing 785
(R) - at runtime
where:
data.
Related tasks:
Linux clustered server: Modifying DB2 for z/OS database properties on page 781
Linux clustered server: Creating remote DB2 for z/OS databases:
machine.
the databases.
Installing 787
500 DEFINE NO;
Related tasks:
Linux clustered server: Using JCL templates to set up DB2 for z/OS on page 784
Linux clustered server: Granting privileges to DB2 for z/OS database administration users:
database user:
Installing 789
Related concepts:
Related tasks:
Linux clustered server: Creating DB2 for z/OS users on page 785
Linux clustered server: Assigning custom DB2 for z/OS table spaces:
Before you begin:
database transfer.
following values:
v release
v community
Installing 791
v customization
v jcr
v feedback
v likeminds
Related tasks:
Linux clustered server: Creating remote DB2 for z/OS databases on page 787
Linux clustered server: Configuring your portal to use DB2 for z/OS:
Before you begin:
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 793
...
Related tasks:
Linux clustered server: Creating remote DB2 for z/OS databases on page 787
Linux clustered server: Granting privileges to DB2 for z/OS database administration users on page 788
Linux clustered server: Setting up a remote Oracle or Oracle RAC database:
Linux clustered server: Installing Oracle or Oracle RAC:
Before you begin:
Considerations:
Installing 795
$ gsdctl start
$ lsnrctl start
$ agentctl start
Linux clustered server: Modifying Oracle or Oracle RAC database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
Installing 797
class.
Linux clustered server: Creating Oracle or Oracle RAC databases:
information:
Server Mode.
pre_page_sga = true
as follows:
FORCE
Installing 799
EXACT
Related tasks:
Linux clustered server: Installing Oracle or Oracle RAC on page 795
Linux clustered server: Setting up Oracle or Oracle RAC automatically or manually:
Note:
database.
Related tasks:
Linux clustered server: Modifying Oracle or Oracle RAC database properties on page 796
Linux clustered server: Running a task to automatically setup Oracle or Oracle RAC:
privileges.
Note:
Linux clustered server: Setting up Oracle or Oracle RAC manually:
Linux clustered server: Creating Oracle or Oracle RAC database schemas and users:
Before you begin:
installation.
environment.
createUsers.sql
createUsers.sql
Installing 801
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
Linux clustered server: Granting privileges to Oracle or Oracle RAC database users:
database user:
Installing 803
Installing 805
Related concepts:
Linux clustered server: Creating JCR table spaces:
environment.
command.
Linux clustered server: Assigning custom Oracle or Oracle RAC table spaces:
Before you begin:
Installing 807
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
COMM8KSPACE
Linux clustered server: Configuring your portal to use Oracle or Oracle RAC:
Before your begin:
Tips:
Repository schema.
Installing 809
files:
name are the same.
SQL > commit;
Exit sqlplus
Related tasks:
Linux clustered server: Creating Oracle or Oracle RAC databases on page 799
Technote 1317981
Linux clustered server: Changing Oracle or Oracle RAC driver types:
configuration task.
Installing 811
Related tasks:
Linux clustered server: Creating Oracle or Oracle RAC databases on page 799
Linux clustered server: Setting up Oracle or Oracle RAC automatically or manually on page 800
Linux clustered server: Setting up a SQL Server database:
Linux clustered server: Installing SQL Server:
information.
sqljdbc_xa.dll
Linux clustered server: Modifying SQL Server database properties:
jcr.DbName=jcrdb
Installing 813
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Linux clustered server: Setting up SQL Server automatically or manually:
Installing 815
table spaces.
Note:
database.
Related tasks:
Linux clustered server: Installing SQL Server on page 812
Linux clustered server: Running a task to automatically setup SQL server databases:
privileges.
4. Click Files.
Autogrowth field.
Linux clustered server: Setting up SQL Server manually:
Linux clustered server: Creating SQL Server databases manually:
Linux clustered server: Creating SQL Server database schemas and users:
Before you begin:
installation.
Installing 817
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
Linux clustered server: Granting privileges to SQL Server database users:
database user:
Installing 819
Installing 821
Related concepts:
Linux clustered server: Assigning custom SQL Server filegroups:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Installing 823
Linux clustered server: Configuring your portal to use SQL Server:
Before you begin:
Tips:
Repository schema.
files:
name are the same.
Installing 825
Related tasks:
Linux clustered server: Installing SQL Server on page 812
Linux clustered server: Modifying SQL Server database properties on page 813
Linux clustered server: Verifying the database configuration:
environment.
source is wpdbDS.
Removing search collections on Linux:
Collections.
deleted.
Related tasks:
Clustered environment: Performing post-installation tasks on Linux on page 739
Creating the WebSphere Portal profile template on Linux in a clustered environment:
Server directory.
Installing 827
Related tasks:
Clustered environment: Performing post-installation tasks on Linux on page 739
Linux clustered server: Configuring your portal to use a database on page 740
Creating and augmenting a new Deployment Manager profile on Linux
Method Steps
-hostName hostname
-profileName Dmgr01
deployment manager:
Installing 829
manager profile.
Option Steps
-profileName dmgr
message.
e. Click Apply.
g. Click Apply.
Related tasks:
Preparing your Linux operating system in a clustered environment on page 730
Clustered environment: Installing with the Installation Manager on Linux on page 731
Clustered environment: Installing with the response file on Linux on page 735
Preparing to create the cluster on Linux
want to create:
password.
cluster:
compatible.
Installing 831
administrator
rerunning the task:
directory:
deployment manager.
the database jars.
Oracle: ojdbc14.jar
Related tasks:
Preparing the primary node on Linux on page 730
Creating a static cluster on Linux:
Installing 833
task.
configuration
information.
Creating a dynamic cluster on Linux using WebSphere Virtual Enterprise:
task.
security policies:
configuration
b. Click New.
e. Click OK.
Installing 835
d. Click Add.
b. Click New.
primary node.
6) Click Append.
click Next.
j. Click Next.
instances.
dynamic cluster.
admin_password
Related tasks:
Preparing a remote Web server when portal is installed on Linux in a clustered
environment
directive.
Installing 837
feature:
f. Click OK.
server:
Related tasks:
Creating and augmenting a new Deployment Manager profile on Linux on page 828
Related reference:
Configuring WebSphere Portal to use a user registry on Linux in a clustered
environment
LDAP user registry.
information.
Installing 839
Related tasks:
Linux cluster: Preparing user registries:
Linux cluster: Preparing a Domino Directory server:
Center.
Server installation > Installing Domino on Linux and complete this task.
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Internet password
wpsadmin
Group name
wpsadmins
Group type
Multi-purpose
Members
members.
the file.
Editor access.
GroupCreator
GroupModifier
Installing 841
UserCreator
UserModifier
e. Click OK.
Linux cluster: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
Linux cluster: Preparing a Novell eDirectory:
4) Click Add.
with a text editor:
your LDAP server.
Linux cluster: Preparing an Oracle Directory Server:
Portal.
4) Click Add.
with a text editor:
your LDAP server.
Linux cluster: Preparing a Tivoli Directory Server:
Installing 843
group.
4) Click Add.
with a text editor:
your LDAP server.
Choosing your user registry model on Linux in a clustered environment:
Choosing your stand-alone LDAP user registry on Linux in a clustered environment:
Linux cluster: Configuring a stand-alone LDAP user registry without SSL:
standalone.ldap.id
Installing 845
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Related tasks:
Configuring a stand-alone LDAP user registry over SSL on Linux in a clustered environment:
Installing 847
standalone.ldap.id
Installing 849
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Related tasks:
Configuring the default federated repository on Linux in a clustered environment:
Configuring a federated LDAP user registry on Linux in a clustered environment:
Adding an LDAP user registry on Linux in a clustered environment:
Installing 851
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
Installing 853
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 855
Related tasks:
Adding an LDAP user registry over SSL on Linux in a clustered environment:
federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 857
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
Installing 859
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 861
Related tasks:
Adding a database user registry on Linux in a clustered environment:
file.
Database Steps
1. Install DB2.
db_files = 1024
log_buffer = 65536
pre_page_sga = true
processes = 300
heading:
db_type.DbDriver
db_type.DbLibrary
Installing 863
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbName
database jars.
Oracle: ojdbc14.jar
VMM database jars.
repository.
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
Adding realm support on Linux in a clustered environment:
Installing 865
realmName
securityUse
delimiter
addBaseEntry
configuration.
realmName
realm.groupParent
then run this task:
parameters.
realmName
addBaseEntry
configuration.
user and group.
group.
Installing 867
the feature.
Related tasks:
Linux cluster: Adapting the attribute configuration:
repositories.
LDAP schema
Installing 869
Related tasks:
Linux stand-alone: Adding an LDAP user registry without SSL on page 704
Linux stand-alone: Adding an LDAP user registry over SSL on page 709
Linux stand-alone: Configuring a stand-alone LDAP user registry without SSL on page 697
Linux stand-alone: Configuring a stand-alone LDAP user registry over SSL on page 700
Linux cluster: Querying the defined attributes:
Adding attributes on Linux in a clustered environment:
Application Server.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
Related tasks:
Mapping attributes on Linux in a clustered environment:
Installing 871
your LDAP server:
standalone.ldap.id
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:
parameters.
standalone.ldap.id
heading:
parameters.
Installing 873
registry:
parameters.
Related tasks:
Linux cluster: Removing attributes:
model directory.
directory.
or
database:
Installing 875
Linux cluster: Configuring Portal to use dynamic groups in a clustered environment:
nodes.
v Name: memberurl
Linux cluster: Enabling referrals for your LDAP user registry in a clustered environment:
Preparing additional cluster members on Linux
Related tasks:
Installing WebSphere Portal on Linux for the horizontal cluster nodes:
Installing 877
Related concepts:
Related tasks:
Additional node: Installing with the Installation Manager on Linux:
options:
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
click OK.
Installing 879
stored.
e. Select Apply.
f. Select OK.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
c. Click Next.
directory path.
path.
3) Click Next.
Next.
Additional node: Installing with the response file on Linux:
options:
Advantage):
Replace with
media.
Installing 881
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
response file:
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
directory path.
path.
3) Click Next.
Next.
Installing 883
computer.
[ -useSocks ] ]
[ -verbose ]
Choosing the type of horizontal cluster to create on Linux:
Adding horizontal nodes to the static cluster on Linux:
Option Steps
click Next.
CAUTION:
node.
/opt/IBM/WebSphere/PortalServer/profileTemplates/managed.portal
-profilePath /opt/IBM/WebSphere/PortalServer/profiles/testManagedPortal1
-cellName testCell
-nodeName testNode
message.
In this example, the profile template is installed under the /opt/IBM/WebSphere/PortalServer/profileTemplates
directory. The new profile is named testManagedPortal1 and is located under the /opt/IBM/WebSphere/
database settings.
Installing 885
node:
Oracle: ojdbc14.jar
jars.
security policies:
configuration
Installing 887
following steps:
v LD_LIBRARY_PATH
v LIBPATH
v PATH
v SHLIB_PATH
profile paths.
server:
admin_password
Adding a horizontal node to the dynamic cluster on Linux:
cluster:
Installing 889
Option Steps
click Next.
CAUTION:
node.
-cellName testCell
-nodeName testNode
message.
server profile.
database settings.
node:
Installing 891
Oracle: ojdbc14.jar
jars.
security policies:
configuration
task.
d. Click Add.
server:
Installing 893
admin_password
Related tasks:
Choosing the type of vertical cluster to create on Linux:
Adding vertical cluster members to a static cluster on Linux:
members.
members.
f. Click OK.
setup task.
server:
Resynchronize.
Installing 895
Solutions Console.
Adding vertical cluster members to a dynamic cluster on Linux:
members.
f. Click OK.
setup task.
server:
c. From the Scope drop-down menu, select the Node=nodename, Server=servername option to narrow
the scope of the listed variables, where Node=nodename is the node that contains the WebSphere
Portal application server.
Resynchronize.
Linux cluster: Tune your servers
should be used.
Installing 897
Related tasks:
Configuring search in a cluster on Linux
Related tasks:
Configuring Portal Search in a cluster on Linux:
Portal cluster.
accordingly.
Notes:
Related concepts:
Portal Search.
Related tasks:
Configuring JCR search in a cluster on Linux:
directory.
Installing 899
search
portlet:
e. Click OK.
deleted.
for information.
Setting up multiple clusters on Linux
new profile.
please contact IBM.
Related tasks:
Linux cluster: Tune your servers on page 897
should be used.
Installing multiple clusters in a single cell on Linux:
already exists.
Installing 901
and password.
and portlets.
password.
rerunning the task:
directory:
deployment manager.
task.
security policies:
configuration
Installing 903
web server:
1) Click New.
4) Click OK.
4) Click Add.
2) Click New.
click Next.
f) Click Append.
menu.
9) Click Next.
server instances.
dynamic cluster.
web server:
Installing 905
in a cell.
Related tasks:
Linux clustered server: Configuring your portal to use a database on page 740
Routing requests across clusters on Linux:
of user requests.
cluster.
Related concepts:
Related reference:
Linux cluster: Sharing database domains between clusters
Installing 907
Manager.
clusters:
Related tasks:
Linux cluster: Tune your servers on page 897
should be used.
Linux
e. Click OK.
i. Select Apply.
Installing 909
j. Select OK.
Manager:
Localizing a new virtual machine instance on Linux
You must install and configure VMware ESX to create a virtual machine environment. You must also
have WebSphere Portal installed and if appropriate configured before localizing your virtual machine
instance.
Complete the following steps to localize a new virtual machine instance:
1. Stop the WebSphere_Portal server running on the virtual machine.
2. Verify that the server1 server is running on the virtual machine. If it is not running, start the server.
3. Update the host name for the virtual machine instance per the instructions of the operating system.
4. Run the ./wsadmin.sh -c "\$AdminTask changeHostName {-nodeName node_name -hostName
new_host_name}" command from the wp_profile_root\bin directory to update the WebSphere Portal host
name in the IBM WebSphere Application Server configuration.
node_name is the node name of the current configuration and new_host_name is the TCP/IP host name
of the new virtual machine instance.
5. Optional: Complete the following steps to update the node name in the IBM WebSphere Application
Server configuration:
a. Run the ./wsadmin.sh -c "\$AdminTask renameNode {-nodeName old_node_name -newNodeName
new_node_name}" command to update the node name in the IBM WebSphere Application Server
configuration.
old_node_name is the original node name of the current configuration and new_node_name is the
new node name you use for this instance.
Remember: This step is necessary to create a unique node name if you are federating and
clustering this node.
b. Edit the ./setupCmdLine.sh file, located in the wp_profile_root\bin directory and modify the SET
WAS_NODE=node_name entry to specify the updated node name.
c. Run the ./ConfigEngine.sh rename-node-in-cell-registry -DWasPassword=password
-DpreviousNodeName=oldNodeName, from the wp_profile_root/ConfigEngine directory, where
oldNodeName is the prior value of the node name.
6. Run the ./ConfigEngine.sh localize-clone -DWasPassword=password command from the
wp_profile_root/ConfigEngine directory to update WebSphere Portal with the information from the IBM
WebSphere Application Server configuration.
7. Run the ./ConfigEngine.sh action-clean-scheduled-tasks -DWasPassword=password command to
clear any scheduled tasks. Existing scheduled tasks might reference the old hostname.
8. Start the WebSphere_Portal server on the virtual machine.
WebSphere Portal is now ready to be used in this virtual machine instance.
Related concepts:
Virtual environment overview on page 115
Installing on Solaris
WebSphere Portal.
Setting up a stand-alone production server on Solaris
Installing 911
Preparing your Solaris operating system in a stand-alone environment
Complete the following steps to prepare your operating system:
1. Complete the following steps to prepare your Solaris kernel settings:
Several Solaris kernel values are typically too small for the messaging requirements of WebSphere
Portal. Starting the internal JMS server or client with insufficient kernel resources produces a First
Failure Support Technology (FFST) file in the /var/errors directory. Before installing WebSphere
Portal, review the machine's configuration.
Note: The values described here are a starting point for messaging in WebSphere Portal only. If your
system has other applications installed, the value requirements are likely different. For example, if
values that are already set are higher than the settings listed here, the values should not be lowered.
Be sure to check the requirements made on /etc/system by other already-installed applications before
altering existing values.
a. Type the sysdef -i command to review the configuration.
b. Set shmsys:shminfo_shmmax (valid for Solaris Version 9 only) to 4294967295.
c. Set shmsys:shminfo_shmmni (valid for Solaris Version 9 only) to 1024.
d. Set semsys:seminfo_semaem (valid for Solaris Version 9 only) to 16384.
e. Set semsys:seminfo_semmni (valid for Solaris Version 9 only) to 1024.
f. Set semsys:seminfo_semmns (valid for Solaris Version 9 only) to 16384.
g. Set semsys:seminfo_semmsl (valid for Solaris Version 9 only) to 100.
h. Set semsys:seminfo_semopm (valid for Solaris Version 9 only) to 100.
i. Set semsys:seminfo_semmnu (valid for Solaris Version 9 only) to 2048.
j. Set semsys:seminfo_semume (valid for Solaris Version 9 only) to 256.
k. Set msgsys:msginfo_msgmap (valid for Solaris Version 9 only) to 1026.
l. Set msgsys:msginfo_msgmax (valid for Solaris Version 9 only) to 65535.
m. Set rlim_fd_cur to 1024.
n. Reboot the operating system to apply the updates.
permanent.
3. Complete the following steps to prepare for non-global zone:
a. Do not inherit package directories when you create the non-global zone because the inherited
software packages will be read-only.
b. Stop WebSphere Portal and all related processes before installing or uninstalling.
c. Verify that the following processes are stopped:
/opt/IBM/WebSphere/AppServer/java/bin/java
/opt/IBM/WebSphere/AppServer/java/jre/bin/java
Related tasks:
com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_solsetup.html
Installing WebSphere Portal on Solaris
authentication.
Installing 913
Related concepts:
Related tasks:
Stand-alone: Installing with the Installation Manager on Solaris:
options:
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
click OK.
stored.
e. Select Apply.
Installing 915
f. Select OK.
b. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
l. Click Next.
page 2197.
Stand-alone: Installing with the response file on Solaris:
Installing 917
options:
Advantage):
Replace with
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
response file:
Installing 919
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
directory path.
path.
3) Click Next.
Next.
computer.
[ -useSocks ] ]
[ -verbose ]
Stand-alone: Performing post-installation tasks on Solaris
> Users and Groups.
Libraries.
Installing 921
LDAP configuration.
Solaris stand-alone: Configuring Portal to use a database
Solaris stand-alone: Setting up a DB2 database:
Solaris stand-alone: Installing DB2:
Before you begin:
required databases.
Note:
Related tasks:
Solaris stand-alone: Modifying DB2 database properties:
jcr.DbName=jcrdb
release
Installing 923
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
driver class.
Solaris stand-alone: Creating groups and assigning users:
Installing 925
Related tasks:
Solaris stand-alone: Installing DB2 on page 922
Solaris stand-alone: Creating DB2 databases:
databases manually.
Related tasks:
Solaris stand-alone: Modifying DB2 database properties on page 923
Solaris stand-alone: Creating a local DB2 database automatically:
Solaris stand-alone: Creating a remote or local DB2 database manually:
running.
instance owner.
that you run:
Notes:
six times.
Installing 927
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
Solaris stand-alone: Setting up DB2 automatically or manually:
Related tasks:
Solaris stand-alone: Creating groups and assigning users on page 925
Solaris stand-alone: Running a task to automatically setup DB2 databases:
Solaris stand-alone: Setting up DB2 manually:
Solaris stand-alone: Creating DB2 database schemas:
Installing 929
users
admins
guests
public
local
IBM
SQL
SYS
environment.
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
Solaris stand-alone: Granting privileges to DB2 database users:
database user:
users
Installing 931
users (continued)
Installing 933
Related concepts:
Solaris stand-alone: Assigning custom DB2 table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Installing 935
Solaris stand-alone: Configuring JCR collation support:
for instructions.
server:
b. Run the command:
using password.
# English
# Swedish
Related tasks:
Solaris stand-alone: Creating DB2 databases on page 926
databases manually.
Solaris stand-alone: Configuring Portal to use DB2:
Before you begin:
Tips:
Repository schema.
Installing 937
the task to stall.
Note:
files:
are the same.
using password
db2 terminate
-p password
Installing 939
Related tasks:
databases manually.
Solaris stand-alone: Setting up DB2 automatically or manually on page 928
running the ConfigEngine task..
Solaris stand-alone: Enabling DB2 pureScale load balancing feature:
6. Click OK.
Related tasks:
databases manually.
Solaris stand-alone: Configuring DB2 for large file handling in WCM:
Installing 941
Related tasks:
databases manually.
Solaris stand-alone: Configuring Portal to use DB2 on page 937
Solaris stand-alone: Type 2 driver support:
Related tasks:
databases manually.
Solaris stand-alone: Configuring Portal to use DB2 on page 937
Solaris stand-alone: Enabling DB2 pureScale load balancing feature on page 940
Solaris stand-alone: Changing DB2 driver types:
configuration task.
Installing 943
Note:
JDBC driver.
Solaris stand-alone: Configuring Type 2 DB2 drivers:
Installing DB2
name.
file.
Portal.
Notes:
understand.
releaseDS
Installing 945
communityDS
customizationDS
jcrDS
lmdbDS
feedback
driver class.
instance owner.
that you run:
Notes:
of six times.
DB2
Installing 947
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
domain.
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Note:
Installing 949
files:
name are the same.
using password
db2 terminate
-p password
Solaris stand-alone: Preparing IBM DB2 for i:
Solaris stand-alone: Modifying properties for IBM DB2 for i:
Installing 951
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
- question mark (?)
Notes:
IBM DB2 for i.
server.
understand.
releaseDS
communityDS
customizationDS
jcrDS
Installing 953
lmdbDS
feedback
JDBC driver class.
Solaris stand-alone: Creating groups and assigning users for IBM DB2 for i:
Note:
database transfer.
Solaris stand-alone: Creating user profiles for IBM DB2 for i:
Before you begin:
can be shared.
new password.
environment.
Related tasks:
Solaris stand-alone: Modifying properties for IBM DB2 for i on page 951
Creating and setting up IBM DB2 for i databases automatically:
Installing 955
Related tasks:
Solaris stand-alone: Creating groups and assigning users for IBM DB2 for i on page 955
Solaris stand-alone: Granting privileges to IBM DB2 for i database users:
create-database
database user:
tasks:
create-database
Installing 957
Related concepts:
Related tasks:
Solaris stand-alone: Creating user profiles for IBM DB2 for i on page 955
Solaris stand-alone: Configuring the portal to use IBM DB2 for i:
Before you begin:
the task to stall.
Note:
Installing 959
Related tasks:
Creating and setting up IBM DB2 for i databases automatically on page 955
Solaris stand-alone: Verifying the IBM DB2 for i configuration:
Related tasks:
Creating and setting up IBM DB2 for i databases automatically on page 955
Solaris stand-alone: Granting privileges to IBM DB2 for i database users on page 956
Solaris stand-alone: Preparing DB2 for z/OS:
server.
Solaris stand-alone: Installing DB2 for z/OS:
following commands:
Installing 961
following commands:
export EXTSHM=ON
db2start
profile.env file:
DB2ENVLIST=EXTSHM
export EXTSHM=ON
remote database.
Solaris stand-alone: Modifying properties for DB2 for z/OS:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
Note:
Installing 963
for the domain.
DbName.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
this value.
driver class.
Solaris stand-alone: Using JCL templates to set up DB2 for z/OS:
created.
successfully.
authority.
on the database
authority.
Installing 965
Related tasks:
Solaris stand-alone: Installing DB2 for z/OS on page 961
Solaris stand-alone: Creating users for DB2 for z/OS:
installation.
(R) - at runtime
Installing 967
where:
data.
Related tasks:
Solaris stand-alone: Modifying properties for DB2 for z/OS on page 962
Solaris stand-alone: Creating a remote database on DB2 for z/OS:
machine.
the databases.
500 DEFINE NO;
Related tasks:
Solaris stand-alone: Using JCL templates to set up DB2 for z/OS on page 965
Solaris stand-alone: Granting privileges to DB2 for z/OS users:
Installing 969
database user:
Installing 971
Related concepts:
Related tasks:
Solaris stand-alone: Creating users for DB2 for z/OS on page 966
Solaris stand-alone: Assigning custom tablespaces for DB2 on z/OS:
Before you begin:
PADIX=NO, or both.
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Related tasks:
Solaris stand-alone: Creating a remote database on DB2 for z/OS on page 968
Solaris stand-alone: Configuring the portal to use DB2 for z/OS:
Installing 973
Before you begin:
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
...
Installing 975
Related tasks:
Solaris stand-alone: Creating a remote database on DB2 for z/OS on page 968
Solaris stand-alone: Granting privileges to DB2 for z/OS users on page 969
Solaris stand-alone: Setting up a remote Oracle or Oracle RAC database:
Solaris stand-alone: Installing Oracle or Oracle RAC:
Before you begin:
Considerations:
$ gsdctl start
$ lsnrctl start
$ agentctl start
Solaris stand-alone: Modifying Oracle or Oracle RAC database properties:
to the Oracle or Oracle RAC database.
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Installing 977
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
class.
Installing 979
Solaris stand-alone: Creating Oracle or Oracle RAC databases:
information:
Server Mode.
pre_page_sga = true
as follows:
FORCE
EXACT
Related tasks:
Solaris stand-alone: Installing Oracle or Oracle RAC on page 976
Solaris stand-alone: Setting up Oracle or Oracle RAC automatically or manually:
Note:
database.
Related tasks:
Solaris stand-alone: Modifying Oracle or Oracle RAC database properties on page 977
Solaris stand-alone: Running a task to automatically setup Oracle or Oracle RAC:
When you set up Oracle or Oracle RAC automatically, you must modify the appropriate properties files
before transferring your data from the default database to the Oracle or Oracle RAC database.
Note:
Installing 981
Solaris stand-alone: Setting up Oracle manually:
Solaris stand-alone: Creating Oracle or Oracle RAC database schemas and users:
Before you begin:
installation.
environment.
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
Solaris stand-alone: Granting privileges to Oracle or Oracle RAC database users:
Installing 983
database user:
Installing 985
Related concepts:
Solaris stand-alone: Creating JCR table spaces:
Installing 987
environment.
command.
Solaris stand-alone: Assigning custom Oracle or Oracle RAC table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
COMM8KSPACE
Solaris stand-alone: Configuring Portal to use Oracle or Oracle RAC:
Oracle or Oracle RAC database. Follow these steps to transfer Portal and Java Content Repository
databases to Oracle. As an alternative to the manual database transfer procedure described here, you can
use the configuration wizard to complete the database transfer task.
Before your begin:
Installing 989
Tips:
Repository schema.
files:
name are the same.
SQL > commit;
Exit sqlplus
Installing 991
Related tasks:
Solaris stand-alone: Creating Oracle or Oracle RAC databases on page 980
Technote 1317981
Solaris stand-alone: Changing Oracle or Oracle RAC driver types:
configuration task.
Related tasks:
Solaris stand-alone: Creating Oracle or Oracle RAC databases on page 980
Solaris stand-alone: Setting up Oracle or Oracle RAC automatically or manually on page 981
Solaris stand-alone: Setting up a SQL Server database:
Solaris stand-alone: Installing SQL Server:
Installing 993
information.
sqljdbc_xa.dll
Solaris stand-alone: Modifying SQL Server database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
Installing 995
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Solaris stand-alone: Setting up SQL Server automatically or manually:
table spaces.
Note:
database.
Related tasks:
Solaris stand-alone: Installing SQL Server on page 993
Solaris stand-alone: Running a task to automatically setup SQL Server databases:
privileges.
4. Click Files.
Autogrowth field.
Installing 997
Solaris stand-alone: Setting up SQL Server manually:
Solaris stand-alone: Creating databases manually:
Solaris stand-alone: Creating database schemas and users:
Before you begin:
installation.
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
Solaris stand-alone: Granting privileges to SQL Server database users:
Installing 999
database user:
Installing 1001
Installing 1003
Related concepts:
Solaris stand-alone: Assigning custom SQL Server filegroups:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Solaris stand-alone: Configuring Portal to use SQL Server:
Before you begin:
Tips:
Repository schema.
files:
Installing 1005
name are the same.
Related tasks:
Solaris stand-alone: Installing SQL Server on page 993
Solaris stand-alone: Modifying SQL Server database properties on page 994
Solaris stand-alone: Verifying the database configuration:
environment.
source is wpdbDS.
Solaris stand-alone: Preparing a remote Web server
Installing 1007
directive.
feature:
f. Click OK.
Related reference:
Solaris stand-alone: Configuring Portal to use a user registry
LDAP user registry.
information.
Related tasks:
Solaris stand-alone: Configuring Portal to use a database on page 922
Managing your user registry on Solaris on page 3150
Solaris stand-alone: Preparing user registries:
Solaris stand-alone: Preparing a Domino Directory:
Center.
Installing 1009
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Internet password
wpsadmin
Group name
wpsadmins
Group type
Multi-purpose
Members
members.
the file.
Editor access.
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
Solaris stand-alone: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
Solaris stand-alone: Preparing a Novell eDirectory:
Installing 1011
4) Click Add.
with a text editor:
your LDAP server.
Solaris stand-alone: Preparing an Oracle Directory Server:
Portal.
4) Click Add.
with a text editor:
your LDAP server.
Solaris stand-alone: Preparing a Tivoli Directory Server:
group.
4) Click Add.
with a text editor:
your LDAP server.
Solaris stand-alone: Choosing your user registry model:
Solaris stand-alone: Configuring a stand-alone LDAP user registry:
Installing 1013
Solaris stand-alone: Configuring a stand-alone LDAP user registry without SSL:
standalone.ldap.id
LDAP configuration.
Installing 1015
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Related tasks:
Solaris cluster: Adapting the attribute configuration on page 1185
Solaris stand-alone: Configuring a stand-alone LDAP user registry over SSL:
Installing 1017
standalone.ldap.id
LDAP configuration.
ignore this line.
Installing 1019
Content Manager
Type of LDAP Value
Internet libraries.
Related tasks:
Solaris stand-alone: Configuring the default federated repository:
Solaris stand-alone: Configuring a federated LDAP user registry:
Solaris stand-alone: Adding an LDAP user registry without SSL:
federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 1021
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
Installing 1023
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 1025
Related tasks:
Deleting the repository on Solaris on page 3173
Solaris stand-alone: Adding an LDAP user registry over SSL:
federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 1027
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
Installing 1029
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Related tasks:
Deleting the repository on Solaris on page 3173
Solaris stand-alone: Adding a database user registry:
Installing 1031
file.
Database Steps
1. Install DB2.
db_files = 1024
log_buffer = 65536
pre_page_sga = true
processes = 300
Database Steps
heading:
db_type.DbDriver
db_type.DbLibrary
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbName
database jars.
Installing 1033
Oracle: ojdbc14.jar
VMM database jars.
repository.
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
Solaris stand-alone: Adding realm support:
realmName
securityUse
delimiter
addBaseEntry
configuration.
Installing 1035
realmName
realm.groupParent
then run this task:
parameters.
realmName
addBaseEntry
configuration.
user and group.
group.
Installing 1037
the feature.
Solaris stand-alone: Adapting the attribute configuration:
repositories.
LDAP schema
Solaris stand-alone: Querying the defined attributes:
Solaris stand-alone: Adding attributes:
Application Server.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
Related tasks:
Solaris stand-alone: Mapping attributes:
Installing 1039
your LDAP server:
standalone.ldap.id
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:
parameters.
standalone.ldap.id
heading:
parameters.
registry:
Installing 1041
parameters.
Solaris stand-alone: Removing attributes:
model directory.
directory.
or
database:
Solaris stand-alone: Configuring Portal to use dynamic groups:
Installing 1043
nodes.
v Name: memberurl
Solaris stand-alone: Enabling referrals for your LDAP user registry:
Solaris stand-alone: Tune your servers
should be used.
Related tasks:
Solaris stand-alone: Configuring Portal to use a database on page 922
Setting up a cluster on Solaris
dynamic.
Installing 1045
Preparing your Solaris operating system in a clustered environment
1. Complete the following steps to prepare your Solaris kernel settings:
Several Solaris kernel values are typically too small for the messaging requirements of WebSphere
Portal. Starting the internal JMS server or client with insufficient kernel resources produces a First
Failure Support Technology (FFST) file in the /var/errors directory. Before installing WebSphere
Portal, review the machine's configuration.
Note: The values described here are a starting point for messaging in WebSphere Portal only. If your
system has other applications installed, the value requirements are likely different. For example, if
values that are already set are higher than the settings listed here, the values should not be lowered.
Be sure to check the requirements made on /etc/system by other already-installed applications before
altering existing values.
a. Type the sysdef -i command to review the configuration.
b. Set shmsys:shminfo_shmmax (valid for Solaris Version 9 only) to 4294967295.
c. Set shmsys:shminfo_shmmni (valid for Solaris Version 9 only) to 1024.
d. Set semsys:seminfo_semaem (valid for Solaris Version 9 only) to 16384.
e. Set semsys:seminfo_semmni (valid for Solaris Version 9 only) to 1024.
f. Set semsys:seminfo_semmns (valid for Solaris Version 9 only) to 16384.
g. Set semsys:seminfo_semmsl (valid for Solaris Version 9 only) to 100.
h. Set semsys:seminfo_semopm (valid for Solaris Version 9 only) to 100.
i. Set semsys:seminfo_semmnu (valid for Solaris Version 9 only) to 2048.
j. Set semsys:seminfo_semume (valid for Solaris Version 9 only) to 256.
k. Set msgsys:msginfo_msgmap (valid for Solaris Version 9 only) to 1026.
l. Set msgsys:msginfo_msgmax (valid for Solaris Version 9 only) to 65535.
m. Set rlim_fd_cur to 1024.
n. Reboot the operating system to apply the updates.
permanent.
3. Complete the following steps to prepare for non-global zone:
a. Do not inherit package directories when you create the non-global zone because the inherited
software packages will be read-only.
Installing 1047
b. Stop WebSphere Portal and all related processes before installing or uninstalling.
c. Verify that the following processes are stopped:
/opt/IBM/WebSphere/AppServer/java/bin/java
/opt/IBM/WebSphere/AppServer/java/jre/bin/java
Related tasks:
com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_solsetup.html
Preparing the primary node on Solaris
Installing WebSphere Portal on Solaris on the primary node:
Related concepts:
Related tasks:
Creating a Portal custom profile on Solaris on page 1716
Preparing the system for multiple profile support on Solaris on page 1713
Clustered environment: Installing with the Installation Manager on Solaris:
options:
Installing 1049
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
click OK.
stored.
e. Select Apply.
f. Select OK.
Manager.
b. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
Installing 1051
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
l. Click Next.
page 2197.
Clustered environment: Installing with the response file on Solaris:
options:
Advantage):
Replace with
Installing 1053
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
response file:
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
Installing 1055
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
n. Click Next.
computer.
[ -useSocks ] ]
[ -verbose ]
Clustered environment: Performing post-installation tasks on Solaris:
Installing 1057
> Users and Groups.
Libraries.
LDAP configuration.
Solaris clustered server: Configuring Portal to use a database:
Related tasks:
Installing WebSphere Portal on Solaris on the primary node on page 1048
Solaris clustered server: Setting up a remote DB2 database:
Solaris clustered server: Installing DB2:
Before you begin:
required databases.
Note:
Installing 1059
Related tasks:
Solaris clustered server: Modifying DB2 database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 1061
driver class.
Solaris clustered server: Creating groups and assigning users:
Related tasks:
Solaris clustered server: Installing DB2 on page 1059
Solaris clustered server: Creating DB2 databases:
databases manually.
Related tasks:
Solaris clustered server: Modifying DB2 database properties on page 1060
Solaris clustered server: Creating a local DB2 database automatically:
Solaris clustered server: Creating a remote or local DB2 database manually:
Installing 1063
running.
instance owner.
that you run:
Notes:
six times.
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
Solaris clustered server: Setting up DB2 automatically or manually:
Related tasks:
Solaris clustered server: Creating groups and assigning users on page 1062
Solaris clustered server: Setting up DB2 automatically:
Installing 1065
This section provides instructions for automatically setting up your database using the ConfigEngine task.
privileges. There are also optional configuration tasks that are not provided to you by running the
ConfigEngine task.
Solaris clustered server: Running a task to automatically setup DB2 databases:
Solaris clustered server: Setting up DB2 manually:
Solaris clustered server: Creating DB2 database schemas:
users
admins
guests
public
local
IBM
SQL
SYS
environment.
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
Solaris clustered server: Granting privileges to DB2 database users:
Installing 1067
database user:
users
users (continued)
Installing 1069
Installing 1071
Related concepts:
Solaris clustered server: Assigning custom DB2 table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Solaris clustered server: Configuring JCR collation support:
for instructions.
server:
b. Run the command:
using password.
# English
Installing 1073
# Swedish
Related tasks:
Solaris clustered server: Creating DB2 databases on page 1063
databases manually.
Solaris clustered server: Configuring Portal to use DB2:
Before you begin:
Tips:
Repository schema.
the task to stall.
Note:
files:
are the same.
Installing 1075
using password
db2 terminate
-p password
Related tasks:
databases manually.
Solaris clustered server: Setting up DB2 automatically or manually on page 1065
Solaris clustered server: Enabling DB2 pureScale load balancing feature:
6. Click OK.
Installing 1077
Related tasks:
databases manually.
Solaris clustered server: Configuring DB2 for large file handling in WCM:
Related tasks:
databases manually.
Solaris clustered server: Configuring Portal to use DB2 on page 1074
Solaris clustered server: Type 2 driver support:
Installing 1079
Related tasks:
databases manually.
Solaris clustered server: Configuring Portal to use DB2 on page 1074
Solaris clustered server: Enabling DB2 pureScale load balancing feature on page 1077
Solaris clustered server: Changing DB2 driver types:
configuration task.
Note:
JDBC driver.
Solaris clustered server: Configuring Type 2 DB2 drivers:
Installing DB2
name.
Installing 1081
file.
Portal.
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
driver class.
instance owner.
that you run:
Installing 1083
Notes:
of six times.
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
domain.
Installing 1085
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Note:
files:
name are the same.
using password
Installing 1087
db2 terminate
-p password
Solaris clustered server: Setting up a remote DB2 for IBM i database:
Solaris clustered server: Modifying DB2 for IBM i database properties:
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
- question mark (?)
Notes:
Installing 1089
IBM DB2 for i.
server.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Solaris clustered server: Creating groups and assigning users for IBM DB2 for i:
Installing 1091
Note:
database transfer.
Solaris clustered server: Creating DB2 for IBM i user profiles:
Before you begin:
can be shared.
new password.
environment.
Related tasks:
Solaris clustered server: Modifying DB2 for IBM i database properties on page 1088
Solaris clustered server: Creating and setting up IBM DB2 for i databases automatically:
Related tasks:
Solaris clustered server: Creating groups and assigning users for IBM DB2 for i on page 1091
Solaris clustered server: Granting privileges to IBM DB2 for i database users:
create-database
database user:
Installing 1093
tasks:
create-database
Related concepts:
Related tasks:
Solaris clustered server: Creating DB2 for IBM i user profiles on page 1092
Solaris clustered server: Transferring IBM DB2 for i manually:
Installing 1095
Before you begin:
the task to stall.
Note:
Related tasks:
Solaris clustered server: Creating and setting up IBM DB2 for i databases automatically on page 1092
Solaris clustered server: Verifying IBM DB2 for i database connections:
Installing 1097
Related tasks:
Solaris clustered server: Creating and setting up IBM DB2 for i databases automatically on page 1092
Solaris clustered server: Granting privileges to IBM DB2 for i database users on page 1093
Solaris clustered server: Setting up a remote DB2 for z/OS database:
Solaris clustered server: Installing DB2 for z/OS:
following commands:
following commands:
export EXTSHM=ON
db2start
profile.env file:
DB2ENVLIST=EXTSHM
export EXTSHM=ON
remote database.
Solaris clustered server: Modifying DB2 for z/OS database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Installing 1099
understand.
Note:
for the domain.
DbName.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
this value.
driver class.
Solaris clustered server: Using JCL templates to set up DB2 for z/OS:
Installing 1101
created.
successfully.
authority.
on the database
authority.
Related tasks:
Solaris clustered server: Installing DB2 for z/OS on page 1098
Solaris clustered server: Creating DB2 for z/OS users:
installation.
Installing 1103
(R) - at runtime
where:
data.
Related tasks:
Solaris clustered server: Modifying DB2 for z/OS database properties on page 1099
Solaris clustered server: Creating remote DB2 for z/OS databases:
machine.
the databases.
500 DEFINE NO;
Installing 1105
Related tasks:
Solaris clustered server: Using JCL templates to set up DB2 for z/OS on page 1101
Solaris clustered server: Granting privileges to DB2 for z/OS database administration users:
database user:
Installing 1107
Related concepts:
Related tasks:
Solaris clustered server: Creating DB2 for z/OS users on page 1103
Solaris clustered server: Assigning custom DB2 for z/OS table spaces:
Before you begin:
PADIX=NO, or both.
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Installing 1109
Related tasks:
Solaris clustered server: Creating remote DB2 for z/OS databases on page 1105
Solaris clustered server: Configuring Portal to use DB2 for z/OS:
Before you begin:
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 1111
...
Related tasks:
Solaris clustered server: Creating remote DB2 for z/OS databases on page 1105
Solaris clustered server: Granting privileges to DB2 for z/OS database administration users on page
1106
Solaris clustered server: Setting up a remote Oracle or Oracle RAC database:
Solaris clustered server: Installing Oracle or Oracle RAC:
Before you begin:
Considerations:
$ gsdctl start
$ lsnrctl start
$ agentctl start
Solaris clustered server: Modifying Oracle or Oracle RAC database properties:
jcr.DbName=jcrdb
Installing 1113
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
Installing 1115
class.
Solaris clustered server: Creating Oracle or Oracle RAC databases:
information:
Server Mode.
pre_page_sga = true
as follows:
FORCE
EXACT
Related tasks:
Solaris clustered server: Installing Oracle or Oracle RAC on page 1112
Solaris clustered server: Setting up Oracle or Oracle RAC automatically or manually:
Note:
database.
Installing 1117
Related tasks:
Solaris clustered server: Modifying Oracle or Oracle RAC database properties on page 1113
Solaris clustered server: Running a task to automatically setup Oracle or Oracle RAC:
When you set up Oracle or Oracle RAC automatically, you must modify the approriate properties files
before transferring your data from the default database to the Oracle or Oracle RAC database.
Note:
Solaris clustered server: Setting up Oracle manually:
Solaris clustered server: Creating Oracle or Oracle RAC database schemas and users:
Before you begin:
installation.
environment.
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
Solaris clustered server: Granting privileges to Oracle or Oracle RAC database users:
Installing 1119
database user:
Installing 1121
Installing 1123
Related concepts:
Solaris clustered server: Creating JCR table spaces:
environment.
command.
Solaris clustered server: Assigning custom Oracle or Oracle RAC table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
COMM8KSPACE
Solaris clustered server: Configuring Portal to use Oracle or Oracle RAC:
Oracle or Oracle RAC database. Follow these steps to transfer Portal and Java Content Repository
databases to Oracle. As an alternative to the manual database transfer procedure described here, you can
use the configuration wizard to complete the database transfer task.
Before your begin:
Installing 1125
Tips:
Repository schema.
files:
name are the same.
SQL > commit;
Exit sqlplus
Installing 1127
Related tasks:
Solaris clustered server: Creating Oracle or Oracle RAC databases on page 1116
Technote 1317981
Solaris clustered server: Changing Oracle or Oracle RAC driver types:
configuration task.
Related tasks:
Solaris clustered server: Creating Oracle or Oracle RAC databases on page 1116
Solaris clustered server: Setting up Oracle or Oracle RAC automatically or manually on page 1117
Solaris clustered server: Setting up a SQL Server database:
Solaris clustered server: Installing SQL Server:
Installing 1129
information.
sqljdbc_xa.dll
Solaris clustered server: Modifying SQL Server database properties:
When you set up SQL Server automatically, you must modify the approriate properties files before
transferring your data from the default database to the SQL database.
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Installing 1131
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Solaris clustered server: Setting up SQL Server automatically or manually:
table spaces.
Note:
database.
Related tasks:
Solaris clustered server: Installing SQL Server on page 1129
Solaris clustered server: Running a task to automatically setup SQL Server databases:
privileges.
Installing 1133
4. Click Files.
Autogrowth field.
Solaris clustered server: Setting up SQL Server manually:
Solaris clustered server: Creating databases manually:
Solaris clustered server: Creating database schemas and users:
Before you begin:
installation.
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
Solaris clustered server: Granting privileges to SQL Server database users:
Installing 1135
database user:
Installing 1137
Installing 1139
Related concepts:
Solaris clustered server: Assigning custom SQL Server filegroups:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Solaris clustered server: Configuring Portal to use SQL Server:
Before you begin:
Tips:
Repository schema.
files:
Installing 1141
name are the same.
Related tasks:
Solaris clustered server: Installing SQL Server on page 1129
Solaris clustered server: Modifying SQL Server database properties on page 1130
When you set up SQL Server automatically, you must modify the approriate properties files before
transferring your data from the default database to the SQL database.
Solaris clustered server: Verifying the database configuration:
environment.
source is wpdbDS.
Removing search collections on Solaris:
Installing 1143
Collections.
deleted.
Related tasks:
Clustered environment: Performing post-installation tasks on Solaris on page 1057
Creating the WebSphere Portal profile template on Solaris in a clustered environment:
Server directory.
Related tasks:
Clustered environment: Performing post-installation tasks on Solaris on page 1057
Solaris clustered server: Configuring Portal to use a database on page 1058
Creating and augmenting a new Deployment Manager profile on Solaris
Note: If you have a 64-bit environment, only the manageprofiles command is supported when
creating profiles.
Installing 1145
Method Steps
-hostName hostname
-profileName Dmgr01
deployment manager:
creating profiles.
manager profile.
Option Steps
-profileName dmgr
message.
e. Click Apply.
g. Click Apply.
Installing 1147
Related tasks:
Clustered environment: Installing with the Installation Manager on Solaris on page 1049
Clustered environment: Installing with the response file on Solaris on page 1053
Preparing to create the cluster on Solaris
want to create:
password.
cluster:
compatible.
administrator
rerunning the task:
directory:
deployment manager.
Installing 1149
the database jars.
Oracle: ojdbc14.jar
Related tasks:
Creating a static cluster on Solaris:
task.
configuration
information.
Creating a dynamic cluster on Solaris using WebSphere Virtual Enterprise:
Installing 1151
task.
security policies:
configuration
b. Click New.
e. Click OK.
d. Click Add.
b. Click New.
primary node.
6) Click Append.
click Next.
j. Click Next.
instances.
dynamic cluster.
Installing 1153
admin_password
Related tasks:
Preparing a remote Web server when portal is installed on Solaris in a clustered
environment
directive.
feature:
f. Click OK.
server:
Installing 1155
Related reference:
Configuring WebSphere Portal to use a user registry on Solaris in a clustered
environment
LDAP user registry.
information.
Solaris cluster: Preparing user registries:
Solaris cluster: Preparing a Domino Directory server:
Center.
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Internet password
wpsadmin
Group name
wpsadmins
Group type
Multi-purpose
Members
members.
the file.
Editor access.
Installing 1157
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
Solaris cluster: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
Solaris cluster: Preparing a Novell eDirectory:
4) Click Add.
with a text editor:
your LDAP server.
Solaris cluster: Preparing an Oracle Directory Server:
Portal.
4) Click Add.
with a text editor:
your LDAP server.
Solaris cluster: Preparing a Tivoli Directory Server:
Installing 1159
group.
4) Click Add.
with a text editor:
your LDAP server.
Choosing your user registry model on Solaris in a clustered environment:
Choosing your stand-alone LDAP user registry on Solaris in a clustered environment:
Solaris cluster: Configuring a stand-alone LDAP user registry without SSL:
standalone.ldap.id
Installing 1161
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Installing 1163
Related tasks:
Configuring a stand-alone LDAP user registry over SSL on Solaris in a clustered environment:
standalone.ldap.id
Installing 1165
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Related tasks:
Configuring the default federated repository on Solaris in a clustered environment:
Installing 1167
Configuring a federated LDAP user registry on Solaris in a clustered environment:
Adding an LDAP user registry on Solaris in a clustered environment:
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
parameters.
id
baseDN
nameInRepository
Installing 1169
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
Installing 1171
cluster.
Related tasks:
Adding an LDAP user registry over SSL on Solaris in a clustered environment:
Installing 1173
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
Installing 1175
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 1177
Related tasks:
Adding a database user registry on Solaris in a clustered environment:
file.
Database Steps
1. Install DB2.
Installing 1179
Database Steps
db_files = 1024
log_buffer = 65536
pre_page_sga = true
processes = 300
heading:
db_type.DbDriver
db_type.DbLibrary
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbName
database jars.
Oracle: ojdbc14.jar
VMM database jars.
repository.
groups are stored.
Installing 1181
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
Adding realm support on Solaris in a clustered environment:
realmName
securityUse
delimiter
addBaseEntry
configuration.
realmName
realm.groupParent
then run this task:
parameters.
Installing 1183
realmName
addBaseEntry
configuration.
user and group.
group.
the feature.
Related tasks:
Solaris cluster: Adapting the attribute configuration:
repositories.
Installing 1185
LDAP schema
Related tasks:
Solaris stand-alone: Adding an LDAP user registry without SSL on page 1021
Solaris stand-alone: Adding an LDAP user registry over SSL on page 1026
Solaris stand-alone: Configuring a stand-alone LDAP user registry without SSL on page 1014
Solaris stand-alone: Configuring a stand-alone LDAP user registry over SSL on page 1017
Solaris cluster: Querying the defined attributes:
Adding attributes on Solaris in a clustered environment:
Application Server.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
Installing 1187
Related tasks:
Mapping attributes on Solaris in a clustered environment:
your LDAP server:
standalone.ldap.id
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:
parameters.
standalone.ldap.id
Installing 1189
file. (continued)
heading:
parameters.
registry:
parameters.
Related tasks:
Solaris cluster: Removing attributes:
model directory.
directory.
Installing 1191
or
database:
Solaris cluster: Configuring Portal to use dynamic groups in a clustered environment:
nodes.
v Name: memberurl
Solaris cluster: Enabling referrals for your LDAP user registry in a clustered environment:
Preparing additional cluster members on Solaris
Installing WebSphere Portal on Solaris for the horizontal cluster nodes:
Installing 1193
Related concepts:
Related tasks:
Additional node: Installing with the Installation Manager on Solaris:
options:
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
Installing 1195
click OK.
stored.
e. Select Apply.
f. Select OK.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
c. Click Next.
directory path.
path.
3) Click Next.
Next.
Additional node: Installing with the response file on Solaris:
options:
Advantage):
Replace with
Installing 1197
media.
ar = Arabic
ca = Catalan
cs = Czech
da = Danish
nl = Dutch
en = English
fi = Finnish
fr = French
de = German
el = Greek
iw = Hebrew
hr = Croatian
hu = Hungarian
it = Italian
ja = Japanese
kk = Kazakh
ko = Korean
no = Norwegian
pl = Polish
pt = Portuguese
ro = Romanian
ru = Russian
sk = Slovak
sl = Slovenian
es = Spanish
sv = Swedish
th = Thai
tr = Turkish
uk = Ukrainian
successful.
response file:
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
directory path.
path.
3) Click Next.
Installing 1199
Next.
computer.
[ -useSocks ] ]
[ -verbose ]
Choosing the type of horizontal cluster to create on Solaris:
Adding horizontal nodes to the static cluster on Solaris:
creating profiles.
Option Steps
click Next.
CAUTION:
node.
-cellName testCell
-nodeName testNode
message.
Installing 1201
database settings.
node:
Oracle: ojdbc14.jar
jars.
security policies:
configuration
Installing 1203
following steps:
v LD_LIBRARY_PATH
v LIBPATH
v PATH
v SHLIB_PATH
profile paths.
12. To prevent Out of Memory errors, complete the following steps to set the MaxPermSize:
Tip: If Maximum Heap Size is set to 2048 M or higher, set the MaxPermSize to a quarter of the value
entered for the Maximum Heap Size; for example, if your Maximum Heap Size is 3000 M, set
MaxPermSize to 750 M. If your Maximum Heap Size is less than 2048 M, set MaxPermSize to 512 M.
b. Go to Servers > Server Types > WebSphere application servers > WebSphere_Portal.
c. Under Server Infrastructure, click Java and Process Management > Process Definitions >
Additional Properties > Java Virtual Machine.
d. In the Generic JVM arguments field, change the MaxPermSize value to -XX:MaxPermSize=numeric
value, where numeric value is a quarter of the value entered for the Maximum Heap Size.
Important: If MaxPermSize does not exist in the Generic JVM arguments field, add it to the field
but do not replace existing information in the Generic JVM arguments field with the
MaxPermSize information.
e. Click OK to save your changes.
f. Click Save to save your changes to the master configuration.
g. Log out of the WebSphere Integrated Solutions Console.
h. Restart the WebSphere_Portal server.
server:
admin_password
Adding a horizontal node to the dynamic cluster on Solaris:
cluster:
Installing 1205
creating profiles.
Option Steps
click Next.
CAUTION:
node.
-cellName testCell
-nodeName testNode
message.
server profile.
database settings.
node:
Installing 1207
Oracle: ojdbc14.jar
jars.
security policies:
configuration
task.
d. Click Add.
Installing 1209
server:
admin_password
Related tasks:
Choosing the type of vertical cluster to create on Solaris:
Adding vertical cluster members to a static cluster on Solaris:
members.
members.
f. Click OK.
setup task.
server:
Installing 1211
Resynchronize.
Solutions Console.
Adding vertical cluster members to a dynamic cluster on Solaris:
members.
f. Click OK.
setup task.
server:
Resynchronize.
Solaris cluster: Tune your servers
should be used.
Installing 1213
Related tasks:
Configuring search in a cluster on Solaris
Configuring Portal Search in a cluster on Solaris:
Portal cluster.
accordingly.
Notes:
Related concepts:
Portal Search.
Related tasks:
Configuring JCR search in a cluster on Solaris:
directory.
search
Installing 1215
Table 354. The format for the shared directory. (continued)
portlet:
e. Click OK.
deleted.
for information.
Setting up multiple clusters on Solaris
new profile.
please contact IBM.
Installing multiple clusters in a single cell on Solaris:
already exists.
and password.
Installing 1217
and portlets.
password.
rerunning the task:
directory:
deployment manager.
task.
security policies:
configuration
Installing 1219
web server:
1) Click New.
4) Click OK.
4) Click Add.
2) Click New.
click Next.
f) Click Append.
menu.
9) Click Next.
server instances.
dynamic cluster.
web server:
in a cell.
Installing 1221
Related tasks:
Solaris clustered server: Configuring Portal to use a database on page 1058
Routing requests across clusters on Solaris:
of user requests.
cluster.
Related concepts:
Related reference:
Sharing database domains between clusters on Solaris
Manager.
clusters:
Installing 1223
Related tasks:
Solaris
e. Click OK.
i. Select Apply.
j. Select OK.
Manager:
Installing on Windows
WebSphere Portal.
Setting up a stand-alone production server on Windows
Installing 1225
Preparing your Windows operating system in a stand-alone environment
1. Check that the system logon user ID you plan to use during installation has the following permissions
and rights:
v The user ID must already exist prior to installation.
v The user ID must belong to the Windows local Administrators group.
2. Complete the following steps to determine if a user account is a member of the Administrators group:
a. Click Start > Programs > Administrative Tools > Computer Management.
b. Expand Local Users and Groups and select Groups.
c. Open the Administrators group to see what members belong to it.
d. Add the user to the Administrators group if necessary.
3. Consider the following recommendations when installing to avoid excessively long path names:
Note: If you exceed the 259 maximum character length, you may receive one of the following error
messages during configuration or in the IBM Installation Manager log files:
v The input line is too long.
v The syntax of the command is incorrect.
v The filename is too long.
a. Use a short installation path. For example, use C:\WebSphere instead of C:\Program
Files\IBM\WebSphere.
b. Specify node names; do not use names longer than 5 characters. For example, you might use node1
instead of longnodename01.
c. Name WAR files with less than 21 characters. If necessary, modify the file name before installing.
Related tasks:
com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_winsetup.html
Installing WebSphere Portal on Windows
authentication.
Related concepts:
Related tasks:
Stand-alone: Installing with the Installation Manager on Windows:
options:
Installing 1227
v Run the install task to install the IBM Installation Manager from the IBM Installation Manager
media.
v Run the setup.exe task from the Portal Setup disk if you have a Windows 32-bit operating system
and you want to start the launchpad to complete all necessary installation steps.
v Run the setup64.exe task from the Portal Setup disk if you have a Windows 64-bit operating
system and you want to start the launchpad to complete all necessary installation steps. Right-click
on setup64.exe, then select "Run as administrator", to launch.
v ar = Arabic
v ca = Catalan
v cs = Czech
v da = Danish
v nl = Dutch
v en = English
v fi = Finnish
v fr = French
v de = German
v el = Greek
v iw = Hebrew
v hr = Croatian
v hu = Hungarian
v it = Italian
v ja = Japanese
v kk = Kazakh
v ko = Korean
v no = Norwegian
v pl = Polish
v pt = Portuguese
v pt_BR = Brazilian Portuguese
v ro = Romanian
v ru = Russian
v sk = Slovak
v sl = Slovenian
v es = Spanish
v zh = Simplified Chinese
v zh_TW = Traditional Chinese
v sv = Swedish
v th = Thai
v tr = Turkish
v uk = Ukrainian
successful.
click OK.
stored.
e. Select Apply.
f. Select OK.
b. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
#
$
%
^
&
*
Installing 1229
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
Attention: If the host name is incorrect, you must correct the information. For example, if the
host name displays: serve3.server3.rtp.raleigh.ibm.com, change it to server3.rtp.raleigh.ibm.com
l. Click Next.
you can run the firststeps.bat task from the wp_profile_root\PortalServer\firststeps directory. Add
page 2197.
Stand-alone: Installing with the response file on Windows:
options:
Advantage):
Replace with
Installing 1231
media.
v ar = Arabic
v ca = Catalan
v cs = Czech
v da = Danish
v nl = Dutch
v en = English
v fi = Finnish
v fr = French
v de = German
v el = Greek
v iw = Hebrew
v hr = Croatian
v hu = Hungarian
v it = Italian
v ja = Japanese
v kk = Kazakh
v ko = Korean
v no = Norwegian
v pl = Polish
v pt = Portuguese
v ro = Romanian
v ru = Russian
v sk = Slovak
v sl = Slovenian
v es = Spanish
v sv = Swedish
v th = Thai
v tr = Turkish
v uk = Ukrainian
successful.
Note: See Use response files to install for additional information.
a. Run the following task from the InstallationManager_root/eclipse directory to record the
response file:
IBMIM.exe -record pathtoresponsexmlfile -skipInstall tempinstalldirectory
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
Installing 1233
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
n. Click Next.
computer.
[ -useSocks ] ]
[ -verbose ]
Stand-alone: Performing post-installation tasks on Windows
1. Optional: After the WebSphere Portal installation completes successfully, run the ConfigEngine.bat
wp_profile_root\ConfigEngine directory, if you want to enable the sample IBM Web Content Manager
Installing 1235
> Users and Groups.
Libraries.
a. Edit the wp_profile_root\PortalServer\wcm\shared\app\config\wcmservices\
LDAP configuration.
d. Run the ConfigEngine.bat express-memberfixer -DPortalAdminPwd=password
-DWasPassword=password task, located in the wp_profile_root\ConfigEngine directory.
Windows stand-alone: Configuring your portal to use a database
Windows stand-alone: Setting up a DB2 database:
Windows stand-alone: Installing DB2:
Before you begin:
required databases.
Note:
1. Before installing DB2, log in with a user ID that has administrative authority. This user should have
the following specifications:
v Belong to the local Administrator group
v Act as part of the operating system
v Have permissions to create a token object
v Windows 2003 only: Have permissions to adjust memory quotas for a process
v Have permissions to replace a process level token
To edit user rights:
v For the first two specifications: Click Start > Programs > Administrative Tools > Computer
Management > Local Users and Groups.
v For the last four specifications: Click Start > Programs > Administrative Tools > Local Security
Policy. Then, click Local Policies > User Rights Assignment.
Related tasks:
Windows stand-alone: Modifying DB2 database properties:
Installing 1237
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Note: This value is also the database element in the dbdomain.DbUrl property. DB2 database
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
driver class.
Installing 1239
Windows stand-alone: Creating groups and assigning users:
Related tasks:
Windows stand-alone: Installing DB2 on page 1236
Windows stand-alone: Creating DB2 databases:
databases manually.
Related tasks:
Windows stand-alone: Modifying DB2 database properties on page 1237
Windows stand-alone: Creating a local DB2 database automatically:
instance owner.
ConfigEngine.bat create-database -DWasPassword=password
Windows stand-alone: Creating a remote or local DB2 database manually:
running.
instance owner.
2. Ensure that the database user has been created, granted appropriate privileges, and has a password
assigned to it. If the user has not been created, refer to the Creating users topic for information on
how to create users.
3. Initialize a DB2 command environment by opening a command prompt and typing db2cmd.
In this mode, you must type db2 at the beginning of each command and use double quotation marks
("") around the entire command. The following example shows how to use the double quotes; it is not
an actual command that you run:
are entering commands from the $ prompt.
Notes:
Installing 1241
six times.
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
Windows stand-alone: Setting up DB2 automatically or manually:
Related tasks:
Windows stand-alone: Creating groups and assigning users on page 1240
Windows stand-alone: Running a task to automatically setup DB2 databases:
This topic provides instructions on automatically setting up your database using the ConfigEngine task to
create users, grant permissions, and create Java Content Repository table spaces.
As an alternative to automatically setting up the database, you can manually set up your database by
referring to the link in the related tasks section of this topic.
ConfigEngine.bat setup-database -DWasPassword=password
Windows stand-alone: Setting up DB2 manually:
Windows stand-alone: Creating DB2 database schemas:
Installing 1243
v User names can contain one to 20 characters.
users
admins
guests
public
local
IBM
SQL
SYS
environment.
Release PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2\release\
createSchema.sql
Community PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2\community\
createSchema.sql
Customization PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2\customization\
createSchema.sql
JCR PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2\jcr\
createSchema.sql
Feedback PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\db2\feedback\
createSchema.sql
Likeminds PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\db2\likeminds\
createSchema.sql
Windows stand-alone: Granting privileges to DB2 database users:
PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2\release\
PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2\community\
PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2\customization\
PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2\jcr\
PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\db2\feedback\
PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\db2\likeminds\
database user:
Installing 1245
PortalServer_root\jcr\wp.content.repository.install\config\templates\setupdb\db2\
jcr\grantPermissionsToRuntimeRoleStatic.sql
Refer to the following locations of the SQL script templates for non-schema-owning runtime database
user:
Installing 1247
Related concepts:
Windows stand-alone: Assigning custom DB2 table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Installing 1249
Windows stand-alone: Configuring JCR collation support:
for instructions.
server:
3. Set up collation on the database where the JCR domain is located. Log in to the database machine
with a user ID that is authorized and configured to use the appropriate DB2 instance. For example, a
common user ID is db2inst1.
a. Change to the directory db2home/function.
b. Run the command:
db2home/java/jdk/bin/jar -xvf temporary location/wp.content.repository.install.jar
The value set for SCHEMA should match the value set for the jcr.DbSchema property..
using password.
# English
# Swedish
Related tasks:
Windows stand-alone: Creating DB2 databases on page 1240
databases manually.
Windows stand-alone: Configuring your portal to use DB2:
View information on manually transferring data to the DB2 database you have installed and set up.
Follow these steps to transfer WebSphere Portal, and Java Content Repository databases to DB2. As an
alternative to the manual database transfer procedure that this topic describes, you can use the
through the configuration wizard. For this reason, you must specify the required settings in the
appropriate property files before transferring the database with the configuration wizard.
Before you begin:
Tips:
Repository schema.
v Be sure that DB2 is started by checking the service. If attempts to restart result in a logon failure
message, then go to the DB2 properties and reenter the password.
1. Open a command prompt and change to the directory wp_profile_root\ConfigEngine.
2. Enter the ConfigEngine.bat validate-database -DWasPassword=password command to validate
Installing 1251
3. From the same command prompt as the previous steps, change to the directory wp_profile_root\bin.
v stopServer.bat WebSphere_Portal -username admin_userid -password admin_password
the task to stall.
a. Change to the directory wp_profile_root\ConfigEngine.
b. Enter the following command: ConfigEngine.bat database-transfer -DWasPassword=password
Note:
only the JCR domain you can enter the following command: ConfigEngine.bat
successfully: wp_profile_root\ConfigEngine\log\ConfigTrace.log If the configuration fails, verify
files:
are the same.
with release, customization, community, jcr, feedback, and likeminds as appropriate.
PortalServer_root\base\wp.db.impl\config\templates\setupdb\dbms\domain
PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\dbms\domain
wp_profile_root\ConfigEngine\properties\wkplc_dbdomain.properties. For example,
2) Run the following task: ConfigEngine.bat grant-runtime-db-user-privileges
db2 connect to dbName user db2admin_userid using
password
b. After it is connected, run the following command from the DB2 prompt:
db2 terminate
-p password
8. Change to the directory wp_profile_root\bin.
with the file from the primary node. Ensure all instances of the file are identical: wp_profile_root\
PortalServer\jcr\lib\com\ibm\icm\icm.properties. If the files are not identical, copy icm.properties
2. Copy wp_profile_root\PortalServer\jcr\lib\com\ibm\icm\icm.properties from the primary node and
Installing 1253
Related tasks:
databases manually.
Windows stand-alone: Setting up DB2 automatically or manually on page 1242
Windows stand-alone: Enabling DB2 pureScale load balancing feature:
6. Click OK.
Related tasks:
databases manually.
Windows stand-alone: Configuring DB2 for large file handling in WCM:
Installing 1255
Related tasks:
databases manually.
Windows stand-alone: Configuring your portal to use DB2 on page 1251
Windows stand-alone: Type 2 driver support:
Related tasks:
databases manually.
Windows stand-alone: Configuring your portal to use DB2 on page 1251
Windows stand-alone: Enabling DB2 pureScale load balancing feature on page 1254
Windows stand-alone: Changing DB2 driver types:
configuration task.
# For DB2 Type 4 driver use <SQLLIB>/java/db2jcc4.jar;<SQLLIB>/java/db2jcc_license_cu.jar
Installing 1257
ConfigEngine.bat connect-database -Drelease.DbPassword=password
Windows stand-alone: Configuring Type 2 DB2 drivers:
Installing DB2
Portal.
name.
instance owner.
("") around the entire command. The following example shows how to use the double quotes; it is
not an actual command that you run:
CLP and are entering commands from the $ prompt.
Notes:
of six times.
Installing 1259
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
11. On the DB2 client, check the services file. If it does not specify DB2 connection and interrupt service
ports, specify the ports for your operating system:
Use a text editor to open the file /etc/services and add the following text:
db2c_db2inst1 port1/tcp
where db2inst1 is the default instance and port1 is the TCP port DB2 listens on. Replace port1 with
the actual port number that assigned to the DB2 connection service in your DB2 server installation
The /etc/services file is located under %systemroot%/system32/drivers/, where %systemroot% is the
location of the operating system. For example C:\Windows\system32\drivers\etc\services.
that is specified in substep b, such as db2c_db2inst1.
domain.
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 1261
Note:
files:
name are the same.
using password
db2 terminate
-p password
Windows stand-alone: Preparing IBM DB2 for i:
Installing 1263
Windows stand-alone: Modifying properties for IBM DB2 for i:
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
- question mark (?)
Notes:
IBM DB2 for i.
Installing 1265
server.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Windows stand-alone: Creating groups and assigning users for IBM DB2 for i:
Note:
database transfer.
Windows stand-alone: Creating user profiles for IBM DB2 for i:
Installing 1267
Before you begin:
can be shared.
new password.
environment.
Related tasks:
Windows stand-alone: Modifying properties for IBM DB2 for i on page 1264
Windows stand-alone: Creating and setting up IBM DB2 for i databases automatically:
This section provides information on using a ConfigEngine task to create databases and users.
Related tasks:
Windows stand-alone: Creating groups and assigning users for IBM DB2 for i on page 1267
Windows stand-alone: Granting privileges to IBM DB2 for i database users:
domain. This role is created and assigned automatically when you run the create-database configuration
Release PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2_iseries\release\
Community PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2_iseries\community\
Customization PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2_iseries\
customization\createConfigRoleForSameSchema.sql
JCR PortalServer_root\base\wp.db.impl\config\templates\setupdb\db2_iseries\jcr\
Feedback PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\db2_iseries\feedback\
Likeminds PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\db2_iseries\likeminds\
database user:
customization\createConfigRoleForDifferentSchema.sql
Installing 1269
domain. These roles are created and assigned automatically when you run the create-database
customization\createRuntimeRoleForSameSchema.sql
PortalServer_root\jcr\wp.content.repository.install\config\templates\setupdb\
db2_iseries\jcr\grantPermissionsToRuntimeRoleStatic.sql
user:
Release PortalServer_rootbase\wp.db.impl\config\templates\setupdb\db2_iseries\release\
customization\createRuntimeRoleForDifferentSchema.sql
Related concepts:
Related tasks:
Windows stand-alone: Creating user profiles for IBM DB2 for i on page 1267
Windows stand-alone: Configuring your portal to use DB2 for IBM i:
Before you begin:
the task to stall.
Note:
Installing 1271
Related tasks:
Windows stand-alone: Creating and setting up IBM DB2 for i databases automatically on page 1268
Windows stand-alone: Verifying the DB2 for IBM i configuration:
Related tasks:
Windows stand-alone: Creating and setting up IBM DB2 for i databases automatically on page 1268
Windows stand-alone: Granting privileges to IBM DB2 for i database users on page 1268
Windows stand-alone: Setting up a remote DB2 for z/OS database:
Windows stand-alone: Installing DB2 for z/OS:
following commands:
following commands:
Installing 1273
export EXTSHM=ON
db2start
profile.env file:
DB2ENVLIST=EXTSHM
export EXTSHM=ON
remote database.
Windows stand-alone: Modifying DB2 for z/OS database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
Note:
for the domain.
DbName.
Installing 1275
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
this value.
driver class.
Windows stand-alone: Using JCL templates to set up DB2 for z/OS:
created.
successfully.
authority.
on the database
authority.
Installing 1277
Related tasks:
Windows stand-alone: Installing DB2 for z/OS on page 1273
Windows stand-alone: Creating DB2 for z/OS users:
installation.
(R) - at runtime
where:
data.
Installing 1279
Related tasks:
Windows stand-alone: Modifying DB2 for z/OS database properties on page 1274
Windows stand-alone: Creating remote DB2 for z/OS databases:
machine.
the databases.
500 DEFINE NO;
Related tasks:
Windows stand-alone: Using JCL templates to set up DB2 for z/OS on page 1277
Windows stand-alone: Granting privileges to DB2 for z/OS database users:
database user:
Installing 1281
Related concepts:
Related tasks:
Windows stand-alone: Creating DB2 for z/OS users on page 1278
Windows stand-alone: Assigning custom DB2 for z/OS table spaces:
Installing 1283
Before you begin:
PADIX=NO, or both.
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Related tasks:
Windows stand-alone: Creating remote DB2 for z/OS databases on page 1280
Windows stand-alone: Configuring your portal to use DB2 for z/OS:
Follow these steps to transfer WebSphere Portal, and Java Content Repository databases to DB2 for z/OS.
Before you begin:
Tips:
Repository schema.
you transfer data.
a. Locate the file C:\Program Files\IBM\SQLLIB\db2cli.ini.
Editing db2cli.ini:
Installing 1285
[COMMON]
DYNAMIC=1
ReturnAliases=0
(createRuntimeRoleForDifferentSchema.sql or createRuntimeRoleForSameSchema.sql) containing the
required GRANT statements for each of the db domains.
user name and the schema name. These files are located in PortalServer_root\base\wp.db.impl\
config\templates\setupdb\db2_zos\domain and PortalServer_root\pzn\prereq.pzn\config\
templates\setupdb\db2_zos\domain directories.
createRuntimeRoleForSameSchema.sql file as appropriate. For the JCR domain, make sure that the
runtime user (jcr.DbRuntimeUser) is added to runtime group (jcr.DbRuntimeRoleName). Execute
the file PortalServer_rootPortalServer_root\jcr\wp.content.repository.install\config\
templates\setupdb\db2_zos\jcr\grantPermissionsToRuntimeRoleStatic.sql.
...
Installing 1287
Related tasks:
Windows clustered server: Installing DB2 for z/OS on page 1409
Windows clustered server: Modifying DB2 for z/OS database properties on page 1410
Windows clustered server: Using JCL templates to set up DB2 for z/OS on page 1413
Windows clustered server: Creating DB2 for z/OS users on page 1414
Windows clustered server: Creating remote DB2 for z/OS databases on page 1416
Windows stand-alone: Granting privileges to DB2 for z/OS database users on page 1281
Windows clustered server: Granting privileges to DB2 for z/OS database users on page 1417
Windows stand-alone: Setting up a remote Oracle or Oracle RAC database:
Windows stand-alone: Installing Oracle or Oracle RAC:
Before you begin:
Considerations:
$ gsdctl start
$ lsnrctl start
$ agentctl start
Windows stand-alone: Modifying Oracle or Oracle RAC database properties:
jcr.DbName=jcrdb
Installing 1289
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
Installing 1291
class.
Windows stand-alone: Creating Oracle or Oracle RAC databases:
information:
Server Mode.
pre_page_sga = true
as follows:
FORCE
EXACT
Windows stand-alone: Setting up Oracle or Oracle RAC automatically or manually:
Note:
database.
Windows stand-alone: Running a task to automatically setup Oracle or Oracle RAC:
Installing 1293
Note:
Windows stand-alone: Setting up Oracle or Oracle RAC manually:
Windows stand-alone: Creating Oracle or Oracle RAC database schemas and users:
Before you begin:
installation.
environment.
Release PortalServer_root\base\wp.db.impl\config\templates\setupdb\oracle\release\
PortalServer_root\base\wp.db.impl\config\templates\setupdb\oracle\release\
createUsers.sql
Community PortalServer_root\base\wp.db.impl\config\templates\setupdb\oracle\community\
PortalServer_root\base\wp.db.impl\config\templates\setupdb\oracle\community\
createUsers.sql
Customization PortalServer_root\base\wp.db.impl\config\templates\setupdb\oracle\customization\
PortalServer_root\base\wp.db.impl\config\templates\setupdb\oracle\customization\
createUsers.sql
JCR PortalServer_root\base\wp.db.impl\config\templates\setupdb\oracle\jcr\
PortalServer_root\base\wp.db.impl\config\templates\setupdb\oracle\jcr\
createUsers.sql
Feedback PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\oracle\feedback\
PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\oracle\feedback\
createUsers.sql
Likeminds PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\oracle\likeminds\
PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\oracle\likeminds\
createUsers.sql
Windows stand-alone: Granting privileges to Oracle or Oracle RAC database users:
Installing 1295
database user:
Installing 1297
oracle\jcr\grantPermissionsToRuntimeRoleStatic.sql
user:
Installing 1299
Related concepts:
Windows stand-alone: Creating JCR table spaces:
environment.
command.
Windows stand-alone: Assigning custom Oracle or Oracle RAC table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
COMM8KSPACE
Windows stand-alone: Configuring your portal to use Oracle or Oracle RAC:
Before your begin:
Installing 1301
Tips:
Repository schema.
files:
name are the same.
SQL > commit;
Exit sqlplus
Installing 1303
Related tasks:
Technote 1317981
Windows stand-alone: Changing Oracle or Oracle RAC driver types:
IBM WebSphere Portal requires the use of either JDBC Type 4 drivers or JDBC OCI Type 2 drivers when
connecting to Oracle or Oracle RAC. You may need to change driver types after a migration. To migrate
JDBC Type 4 drivers. Once migration is complete, you can continue using JDBC Type 4 drivers or change
the driver type to JDBC OCI Type 2 drivers as appropriate. Direct migration from a previous installation
of WebSphere Portal using JDBC Type 4 drivers to an installation using JDBC OCI Type 2 drivers is not
supported.
configuration task.
2. Enter the ConfigEngine.bat validate-database command to validate configuration properties.
Windows stand-alone: Setting up a remote SQL Server database:
Windows stand-alone: Installing SQL Server:
information.
Installing 1305
sqljdbc_xa.dll
7. Perform the following steps to enable XA Transactions in Windows Component Services:
a. Click Start > Settings > Administrative Tools > Component Services.
b. Expand the tree view to locate the computer where you want to turn on support for XA
transactions (for example, My Computer).
c. Display the menu for the computer name and click Properties.
d. Click Options and tune the Transaction Timeout that suits your environment. (The recommended
minimum is 180 seconds).
e. Click MSDTC and click Security Configuration.
f. Under Security Settings, select XA Transactions to enable this support.
g. Click OK to save your changes.
Windows stand-alone: Modifying SQL Server database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 1307
Note:
v This value is the location to store the database files locally.
v This path must use two backslashes (\\) instead of a forward slash (/).
JDBC driver class.
Windows stand-alone: Setting up SQL Server automatically or manually:
table spaces.
Note:
database.
Related tasks:
Windows stand-alone: Installing SQL Server on page 1305
Windows stand-alone: Running a task to automatically setup SQL Server databases:
privileges.
4. Click Files.
Autogrowth field.
Installing 1309
Windows stand-alone: Setting up SQL Server manually:
Windows stand-alone: Creating databases manually:
Use this alternative method for creating databases if you have problems running the create-database task
that is documented for setting up a remote SQL Server database on Windows for a stand-alone
production server.
Windows stand-alone: Creating SQL Server database schemas and users:
Before you begin:
installation.
Release PortalServer_root\base\wp.db.impl\config\templates\setupdb\sqlserver2005\release\
createSchema.sql
PortalServer_root\base\wp.db.impl\config\templates\setupdb\sqlserver2005\release\
createUsers.sql
Community PortalServer_root\base\wp.db.impl\config\templates\setupdb\sqlserver2005\
community\createSchema.sql
PortalServer_root\base\wp.db.impl\config\templates\setupdb\sqlserver2005\
community\createRuntimeUsers.sql
community\createUsers.sql
Customization PortalServer_root\base\wp.db.impl\config\templates\setupdb\sqlserver2005\
customization\createSchema.sql
customization\createRuntimeUsers.sql
customization\createUsers.sql
JCR PortalServer_root\base\wp.db.impl\config\templates\setupdb\sqlserver2005\jcr\
createSchema.sql
PortalServer_root\base\wp.db.impl\config\templates\setupdb\sqlserver2005\jcr\
createUsers.sql
Feedback PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\sqlserver2005\feedback\
createSchema.sql
PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\sqlserver2005\feedback\
createUsers.sql
Likeminds PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\sqlserver2005\likeminds\
createSchema.sql
PortalServer_root\pzn\prereq.pzn\config\templates\setupdb\sqlserver2005\likeminds\
createUsers.sql
Windows stand-alone: Granting privileges to SQL Server database users:
Installing 1311
community\createConfigRoleForSameSchema.sql
community\grantRoleToConfigUser.sql
customization\grantRoleToConfigUser.sql
database user:
community\createConfigRoleForDifferentSchema.sql
Installing 1313
community\createInitialRuntimeRole.sql
community\createRuntimeRoleForSameSchema.sql
community\grantRoleToRuntimeUser.sql
customization\createInitialRuntimeRole.sql
customization\grantRoleToRuntimeUser.sql
sqlserver2005\jcr\grantPermissionsToRuntimeRoleStatic.sql
PortalServer_root\pzn\prereq.pzn\config\templates\setupdbsqlserver2005\feedback\
user:
community\createRuntimeRoleForDifferentSchema.sql
Installing 1315
Related concepts:
Windows stand-alone: Assigning custom SQL Server filegroups:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Windows stand-alone: Configuring your portal to use SQL Server:
Before you begin:
Tip:
Repository schema.
the task to stall.
only the JCR domain you can enter the following command: ConfigEngine.bat database-transfer
files:
Installing 1317
are the same.
Related tasks:
Windows stand-alone: Installing SQL Server on page 1305
Windows stand-alone: Modifying SQL Server database properties on page 1306
Windows stand-alone: Verifying the database configuration:
environment.
source is wpdbDS.
Windows stand-alone: Preparing a remote Web server
2. If using Microsoft Internet Information Server, we recommend updating the UrlSegmentMaxLength
Registry key to a value of 0 to eliminate potential problems in a WebSphere Portal environment with
the default IIS limitation on the length of URL path segments. We also recommend updating the
AllowRestrictedChars Registry key to a value of 1 to accept hex-escaped characters in request URLs
that decode to the U+0000 - U+001F and U+007F - U+009F ranges.
Note: Refer to Http.sys registry settings for IIS for information.
directive.
Installing 1319
feature:
f. Click OK.
Related reference:
Windows stand-alone: Configuring Portal to use a user registry
LDAP user registry.
information.
Related tasks:
Windows stand-alone: Configuring your portal to use a database on page 1236
Managing your user registry on Windows on page 3175
Windows stand-alone: Preparing user registries:
Windows stand-alone: Preparing an Active Directory Server:
If you plan to use Active Directory as an LDAP user registry, you must install and set up the server so
that it will communicate with IBM WebSphere Portal.
Complete the following steps to prepare Active Directory:
1. Complete the following steps to install and configure Active Directory:
a. Install Windows 2003 or 2008 Server, which includes Active Directory. Refer to
http://www.microsoft.com/windows2000/technologies/directory/ad/default.asp for information.
b. Install required Service Packs.
c. Complete the following steps to install Internet Information Services (IIS), which is required to
export server certificates and must be installed before installing Certificate Services:
1) Open the Control Panel and select Add/Remove Programs.
2) Choose Add/Remove Windows Components.
3) Choose the Internet Information Services (IIS) component and then click Next.
4) Complete the Windows Components Wizard instructions. The Windows Server CD is needed.
Installing 1321
d. Use the following steps to install Certificate Services if you plan on using Active Directory over
SSL:
3) Select Certificate Services and then click Next.
4) Select Stand-alone root CA and then click Next. You can also choose other options depends on
you needs.
5) Enter CA identifying information and then click Next.
a. Create a new user with the Windows administrative tools.
Note: There is a 20 character limitation for the user account name.
b. Set the password for the new user.
c. Activate the new user with the Windows administrative tools. Set the msDS-UserAccountDisabled
attribute to false.
3. Complete the following steps to enable SSL for Active Directory; this step is required to set passwords
during sign up and user creation:
a. Install an Enterprise Certificate Authority on a Windows 2000 Domain Controller, which installs a
certificate on a server or install a third-party certificate on the Domain Controller.
b. Click Start > All Programs > Administrative Tools > Active Directory Users and Computer.
c. In the Active Directory Users and Computers window, right-click on your domain name and select
Properties.
d. In the Domain Properties dialog box, select the Group Policy tab.
e. Select the Default Domain Policy group policy and then click Edit.
f. Select Windows Settings under Computer Configuration.
g. Select Security Settings and then select Public Key Policies.
h. Select Automatic Certificate Request Settings.
i. Use the wizard to add a policy for Domain Controllers.
Note: When these requirements are complete, all domain controllers request a certificate and
support LDAP over SSL using port 636.
Windows stand-alone: Preparing an Active Directory-Lightweight-Directory-Services:
If you plan to use an Active Directory-Lightweight-Directory-Services as an LDAP user registry, you must
install and set up the server so that it communicates with IBM WebSphere Portal.
Complete the following steps to prepare Active Directory-Lightweight-Directory-Services:
1. Download Active Directory Application Mode and then install it; refer to Windows Server 2003 Active
Directory-Lightweight-Directory-Services for information.
Attention: By default, Active Directory-Lightweight-Directory-Services requires an enabled SSL to set
and update user passwords. If you do not want to enable SSL, go to Active Directory-Lightweight-
Directory-Services Frequently Asked Questions and click How do I enable password changes on an
unencrypted connection to Active Directory-Lightweight-Directory-Services.
attribute to false.
Windows stand-alone: Preparing a Domino Directory:
Center.
Server installation > Installing Domino on Windows and complete this task.
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Installing 1323
Internet password
wpsadmin
Group name
wpsadmins
Group type
Multi-purpose
Members
members.
the file.
Editor access.
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
Windows stand-alone: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
Windows stand-alone: Preparing a Novell eDirectory:
4) Click Add.
with a text editor:
your LDAP server.
Windows stand-alone: Preparing an Oracle Directory Server:
Portal.
Installing 1325
4) Click Add.
with a text editor:
your LDAP server.
Windows stand-alone: Preparing a Tivoli Directory Server:
group.
4) Click Add.
with a text editor:
your LDAP server.
Windows stand-alone: Choosing your user registry model:
Windows stand-alone: Configuring a stand-alone LDAP user registry:
Windows stand-alone: Configuring a stand-alone LDAP user registry without SSL:
2. Use a text editor to open the wkplc.properties file, located in the wp_profile_root\ConfigEngine\
standalone.ldap.id
Installing 1327
8. Run the ConfigEngine.bat validate-standalone-ldap -DWasPassword=password task to validate your
9. Run the ConfigEngine.bat wp-modify-ldap-security -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to set the stand-alone LDAP user registry.
11. Run the ConfigEngine.bat wp-validate-standalone-ldap-attribute-config -DWasPassword=password
task, from the wp_profile_root\ConfigEngine directory, to check that all defined attributes are available
LDAP configuration.
ignore this line.
d. Run the ConfigEngine.bat run-wcm-admin-task-member-fixer -DallLibraries=true -Dfix=true
-DPortalAdminPwd=wpsadmin task, located in the wp_profile_root\ConfigEngine directory.
Content Manager
Type of LDAP Value
Installing 1329
Internet libraries.
Related tasks:
Windows cluster: Adapting the attribute configuration on page 1500
Windows stand-alone: Configuring a stand-alone LDAP user registry over SSL:
standalone.ldap.id
Installing 1331
13. Run the ConfigEngine.bat wp-validate-standalone-ldap-attribute-config
-DWasPassword=password task, from the wp_profile_root\ConfigEngine directory, to check that all
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Installing 1333
Related tasks:
Windows stand-alone: Configuring the default federated repository:
Windows stand-alone: Configuring a federated LDAP user registry:
Windows stand-alone: Adding an LDAP user registry without SSL:
federated.ldap.id
federated.ldap.host
federated.ldap.port
7. Run the ConfigEngine.bat validate-federated-ldap -DWasPassword=password task to validate your
8. Run the ConfigEngine.bat wp-create-ldap -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to add an LDAP user registry to the default federated
repository.
Installing 1335
a. Use a text editor to open the wkplc.properties file, located in the wp_profile_root\ConfigEngine\
parameters.
id
baseDN
nameInRepository
d. Run the ConfigEngine.bat wp-create-base-entry -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to create a base entry in a repository.
11. Optional: Run the ConfigEngine.bat wp-query-repository -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to list the names and types of configured repositories.
12. Run the ConfigEngine.bat wp-validate-federated-ldap-attribute-config -DWasPassword=password
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
d. Run the ConfigEngine.bat wp-set-entitytypes -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to delete the old attributes before adding the new
attributes.
d. Run the ConfigEngine.bat wp-modify-realm-enable-dn-login -DWasPassword=password task,
located in the wp_profile_root\ConfigEngine directory, to enable the distinguished name login.
ConfigEngine.bat wp-modify-realm-disable-dn-login -DWasPassword=password task to disable
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Installing 1337
Internet libraries.
LDAP user registry:
Important:
cluster.
a. Run the following task from the wp_profile_root\ConfigEngine directory: ConfigEngine.bat
c. Run the following task from the wp_profile_root\ConfigEngine directory: ConfigEngine.bat
Related tasks:
Deleting the repository on Windows on page 3199
Windows stand-alone: Adding an LDAP user registry over SSL:
Installing 1339
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
Installing 1341
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 1343
Related tasks:
Deleting the repository on Windows on page 3199
Windows stand-alone: Adding a database user registry:
file.
Database Steps
1. Install DB2.
db_files = 1024
log_buffer = 65536
pre_page_sga = true
processes = 300
Installing 1345
Database Steps
a. Use a text editor to open the wkplc_dbtype.properties file, located in the wp_profile_root\
ConfigEngine\properties directory.
b. Enter a value for the following parameters under the appropriate database type properties
heading:
db_type.DbDriver
db_type.DbLibrary
c. Save your changes.
Limitation: The WebSphere Application Server UserManagement component (VMM) requires access
to the following database libraries to use the VMM database functions such as Property Extension
and database user registry, however, if the Portal is using the DB2 Type 2 driver, due to functional
limitations, VMM must use the DB2 Type 4 driver; see Configuring a JDBC provider and datasource
for federated repositories for additional information:
Oracle: ojdbc14.jar
Complete the following steps to add the library paths to the VMM_JDBC_CLASSPATH variable:
a. Log on to the WebSphere Integrated Solutions Console as the administrator.
b. Click Environment > WebSphere Variables.
c. Select scope: cell.
d. Select the VMM_JDBC_CLASSPATH variable or click New to create the variable if it does not
exist.
e. Enter the complete paths to the library files, separated by ';", in the Value field; for example,
enter D:\IBM\SQLLIB\java\db2jcc4.jar;D:\IBM\SQLLIB\java\db2jcc_license_cu.jar.
Copy the library files into the appserver/lib directory. Then stop and restart the WebSphere_Portal
server to load the library files. In a clustered environment, you must also stop and restart the
Deployment Manager and the nodeagents.
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbName
a. Navigate to the following directory: wp_profile_root\properties
a. Run the ConfigEngine.bat wp-prep-vmm-db-secured-environment -DWasPassword=password
-DDbDomain=federated.db -Ddb_type.DmgrDbLibrary=local full path of the database jars on
the Deployment Manager -DDmgrNodeName=dmgr_node_name task from the wp_profile_root\
Oracle: ojdbc14.jar
1) Set the property value for federated.db.DbType in wkplc.properties if you are using a
2) Run the ConfigEngine.bat wp-node-prep-vmm-db-secured-environment
-DWasPassword=password -DDbDomain=federated.db
-DVmmNodeName=node_name,node_name,node_name -Ddb_type.NodeDbLibrary=local full path
of the database jars task from the wp_profile_root\ConfigEngine directory on each node to
create the variable used to access the VMM database jars.
8. Run the ConfigEngine.bat wp-create-db -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to add a database user registry to the default federated
repository.
Installing 1347
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
Windows stand-alone: Adding realm support:
realmName
securityUse
delimiter
addBaseEntry
5. Run the ConfigEngine.bat wp-create-realm -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to add a new realm to the Virtual Member Manager
configuration.
realmName
realm.groupParent
8. Run the ConfigEngine.bat wp-modify-realm-defaultparents -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to update the default parents per entity type and realm.
then run this task:
parameters.
Installing 1349
realmName
addBaseEntry
d. Run the ConfigEngine.bat wp-add-realm-baseentry -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to add additional LDAP base entries to the realm
configuration.
d. Run the ConfigEngine.bat wp-change-was-admin-user -DWasUser=adminid
-DnewAdminGroupId=newadmingroupid task, from the wp_profile_root\ConfigEngine directory, to
user and group.
f. Run the ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=password
group.
d. Run the ConfigEngine.bat wp-default-realm -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to set this realm as the default realm.
d. Run the ConfigEngine.bat wp-query-realm-baseentry -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to list the base entries for a specific realm.
the feature.
Windows stand-alone: Adapting the attribute configuration:
repositories.
LDAP schema
Installing 1351
Windows stand-alone: Querying the defined attributes:
Run the ConfigEngine.bat wp-query-attribute-config -DWasPassword=password task, from the
Windows stand-alone: Adding attributes:
Application Server.
b. Go to the wp_profile_root\ConfigEngine directory.
c. Run the ConfigEngine.bat wp-la-install-ear -DWasPassword=password task.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
7. Run the ConfigEngine.bat wp-add-property -DWasPassword=password task to add the attribute to the
user registry.
Related tasks:
Windows stand-alone: Mapping attributes:
your LDAP server:
standalone.ldap.id
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:
Installing 1353
Stand-alone ConfigEngine.bat wp-validate-standalone-ldap-
the wp_profile_root\ConfigEngine directory.
Federated ConfigEngine.bat wp-validate-federated-ldap-
parameters.
standalone.ldap.id
file. (continued)
heading:
parameters.
registry:
Stand-alone ConfigEngine.bat wp-update-standalone-ldap-
the wp_profile_root\ConfigEngine directory
Federated ConfigEngine.bat wp-update-federated-ldap-attribute-
wp_profile_root\ConfigEngine directory
parameters.
c. Run the ConfigEngine.bat wp-update-attribute-config -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory.
Installing 1355
Windows stand-alone: Removing attributes:
model directory.
directory.
or
database:
Windows stand-alone: Configuring your portal to use dynamic groups:
nodes.
v Name: memberurl
Windows stand-alone: Enabling referrals for your LDAP user registry:
Installing 1357
Tune your servers
should be used.
Related tasks:
Windows stand-alone: Configuring your portal to use a database on page 1236
Setting up a cluster on Windows
dynamic.
Installing 1359
Related tasks:
Late breaking installation limitations and issues
Secondary node fails to start after being added to the cluster with javax.jcr.RepositoryException
exception
Preparing your Windows operating system in a clustered environment
1. Check that the system logon user ID you plan to use during installation has the following permissions
and rights:
v The user ID must already exist prior to installation.
v The user ID must belong to the Windows local Administrators group.
3. Complete the following steps to determine if a user account is a member of the Administrators group:
a. Click Start > Programs > Administrative Tools > Computer Management.
b. Expand Local Users and Groups and select Groups.
c. Open the Administrators group to see what members belong to it.
d. Add the user to the Administrators group if necessary.
4. Consider the following recommendations when installing to avoid excessively long path names:
Note: If you exceed the 259 maximum character length, you may receive one of the following error
messages during configuration or in the IBM Installation Manager log files:
v The input line is too long.
v The syntax of the command is incorrect.
v The filename is too long.
a. Use a short installation path. For example, use C:\WebSphere instead of C:\Program
Files\IBM\WebSphere.
b. Specify node names; do not use names longer than 5 characters. For example, you might use node1
instead of longnodename01.
c. Name WAR files with less than 21 characters. If necessary, modify the file name before installing.
Related tasks:
com.ibm.websphere.installation.nd.doc/info/ae/ae/tins_winsetup.html
Preparing the primary node on Windows
Installing WebSphere Portal on Windows on the primary node:
Installing 1361
Related concepts:
Related tasks:
Creating a Portal custom profile on Windows on page 1725
Preparing the system for multiple profile support on Windows on page 1722
Clustered environment: Installing with the Installation Manager on Windows:
options:
media.
v ar = Arabic
v ca = Catalan
v cs = Czech
v da = Danish
v nl = Dutch
v en = English
v fi = Finnish
v fr = French
v de = German
v el = Greek
v iw = Hebrew
v hr = Croatian
v hu = Hungarian
v it = Italian
v ja = Japanese
v kk = Kazakh
v ko = Korean
v no = Norwegian
v pl = Polish
v pt = Portuguese
v ro = Romanian
v ru = Russian
v sk = Slovak
v sl = Slovenian
v es = Spanish
v sv = Swedish
Installing 1363
v th = Thai
v tr = Turkish
v uk = Ukrainian
successful.
click OK.
stored.
e. Select Apply.
f. Select OK.
Manager.
b. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
3) Click Next.
Next.
Base, or Custom.
Installing 1365
Attention: If the host name is incorrect, you must correct the information. For example, if the
host name displays: serve3.server3.rtp.raleigh.ibm.com, change it to server3.rtp.raleigh.ibm.com
l. Click Next.
you can run the firststeps.bat task from the wp_profile_root\PortalServer\firststeps directory. Add
page 2197.
Clustered environment: Installing with the response file on Windows:
options:
Advantage):
Replace with
media.
v ar = Arabic
v ca = Catalan
v cs = Czech
v da = Danish
v nl = Dutch
v en = English
v fi = Finnish
v fr = French
v de = German
v el = Greek
v iw = Hebrew
v hr = Croatian
v hu = Hungarian
v it = Italian
v ja = Japanese
v kk = Kazakh
v ko = Korean
Installing 1367
v no = Norwegian
v pl = Polish
v pt = Portuguese
v ro = Romanian
v ru = Russian
v sk = Slovak
v sl = Slovenian
v es = Spanish
v sv = Swedish
v th = Thai
v tr = Turkish
v uk = Ukrainian
successful.
response file:
-record
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
~
!
@
#
$
%
^
&
*
(
)
_
+
{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
directory path.
path.
Installing 1369
3) Click Next.
Next.
Base, or Custom.
n. Click Next.
computer.
[ -useSocks ] ]
[ -verbose ]
Clustered environment: Performing post-installation tasks on Windows:
1. Optional: After the WebSphere Portal installation completes successfully, run the ConfigEngine.bat
wp_profile_root\ConfigEngine directory, if you want to enable the sample IBM Web Content Manager
> Users and Groups.
Libraries.
LDAP configuration.
d. Run the ConfigEngine.bat express-memberfixer -DPortalAdminPwd=password
-DWasPassword=password task, located in the wp_profile_root\ConfigEngine directory.
Windows clustered server: Configuring your portal to use a database:
Installing 1371
Related tasks:
Installing WebSphere Portal on Windows on the primary node on page 1361
Windows clustered server: Setting up a remote DB2 database:
Windows clustered server: Installing DB2:
Before you begin:
required databases.
Note:
Related tasks:
Windows clustered server: Modifying DB2 database properties:
jcr.DbName=jcrdb
Installing 1373
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
Note: This value is also the database element in the dbdomain.DbUrl property. DB2 database
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
driver class.
Windows clustered server: Creating groups and assigning users:
Installing 1375
Related tasks:
Windows clustered server: Installing DB2 on page 1372
Windows clustered server: Creating DB2 databases:
databases manually.
Related tasks:
Windows clustered server: Modifying DB2 database properties on page 1373
Windows clustered server: Creating a local DB2 database automatically:
instance owner.
Windows clustered server: Creating a remote or local DB2 database manually:
running.
instance owner.
("") around the entire command. The following example shows how to use the double quotes; it is not
an actual command that you run:
are entering commands from the $ prompt.
Notes:
six times.
Installing 1377
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
Windows clustered server: Setting up DB2 automatically or manually:
Related tasks:
Windows clustered server: Creating groups and assigning users on page 1375
Windows clustered server: Running a task to automatically setup DB2 databases:
Windows clustered server: Setting up DB2 manually:
Windows clustered server: Creating DB2 database schemas:
v User names can contain one to 20 characters.
users
admins
guests
public
local
IBM
SQL
SYS
Installing 1379
environment.
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
Windows clustered server: Granting privileges to DB2 database users:
database user:
Installing 1381
user:
Installing 1383
Related concepts:
Windows clustered server: Assigning custom DB2 table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Windows clustered server: Configuring JCR collation support:
for instructions.
server:
3. Set up collation on the database where the JCR domain is located. Log in to the database machine
with a user ID that is authorized and configured to use the appropriate DB2 instance. For example, a
common user ID is db2inst1.
a. Change to the directory db2home/function.
Installing 1385
b. Run the command:
db2home/java/jdk/bin/jar -xvf temporary location/wp.content.repository.install.jar
The value set for SCHEMA should match the value set for the jcr.DbSchema property..
using password.
# English
# Swedish
Related tasks:
Windows clustered server: Creating DB2 databases on page 1376
databases manually.
Windows clustered server: Configuring Portal to use DB2:
Before you begin:
Tips:
Repository schema.
v Be sure that DB2 is started by checking the service. If attempts to restart result in a logon failure
message, then go to the DB2 properties and reenter the password.
Installing 1387
the task to stall.
Note:
files:
are the same.
db2 connect to dbName user db2admin_userid using
password
b. After it is connected, run the following command from the DB2 prompt:
db2 terminate
-p password
Installing 1389
Related tasks:
databases manually.
Windows clustered server: Setting up DB2 automatically or manually on page 1378
Windows clustered server: Enabling DB2 pureScale load balancing feature:
6. Click OK.
Related tasks:
databases manually.
Windows clustered server: Configuring DB2 for large file handling in WCM:
Installing 1391
Related tasks:
databases manually.
Windows clustered server: Configuring Portal to use DB2 on page 1387
Windows clustered server: Type 2 driver support:
Related tasks:
databases manually.
Windows clustered server: Configuring Portal to use DB2 on page 1387
Windows clustered server: Enabling DB2 pureScale load balancing feature on page 1390
Windows clustered server: Changing DB2 driver types:
configuration task.
# For DB2 Type 4 driver use <SQLLIB>/java/db2jcc4.jar;<SQLLIB>/java/db2jcc_license_cu.jar
Installing 1393
Windows clustered server: Configuring Type 2 DB2 drivers:
Installing DB2
Portal.
name.
instance owner.
("") around the entire command. The following example shows how to use the double quotes; it is
not an actual command that you run:
CLP and are entering commands from the $ prompt.
Notes:
of six times.
Installing 1395
DB2
db2 "TERMINATE"
DB2 pureScale
db2 "TERMINATE"
11. On the DB2 client, check the services file. If it does not specify DB2 connection and interrupt service
ports, specify the ports for your operating system:
Use a text editor to open the file /etc/services and add the following text:
db2c_db2inst1 port1/tcp
where db2inst1 is the default instance and port1 is the TCP port DB2 listens on. Replace port1 with
the actual port number that assigned to the DB2 connection service in your DB2 server installation
The /etc/services file is located under %systemroot%/system32/drivers/, where %systemroot% is the
location of the operating system. For example C:\Windows\system32\drivers\etc\services.
that is specified in substep b, such as db2c_db2inst1.
domain.
you transfer data.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 1397
Note:
files:
name are the same.
using password
db2 terminate
-p password
Windows clustered server: Setting up a remote DB2 for IBM i database:
Windows clustered server: Modifying DB2 for IBM i database properties:
Installing 1399
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
- question mark (?)
Notes:
IBM DB2 for i.
Installing 1401
server.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Windows clustered server: Creating groups and assigning users for IBM DB2 for i:
Note:
database transfer.
Windows clustered server: Creating DB2 for IBM i user profiles:
Before you begin:
Installing 1403
can be shared.
new password.
environment.
Related tasks:
Windows clustered server: Modifying DB2 for IBM i database properties on page 1399
Windows clustered server: Creating and setting up IBM DB2 for i databases automatically:
Related tasks:
Windows clustered server: Creating groups and assigning users for IBM DB2 for i on page 1403
Windows clustered server: Granting privileges to IBM DB2 for i database users:
domain. This role is created and assigned automatically when you run the create-database configuration
database user:
domain. These roles are created and assigned automatically when you run the create-database
Installing 1405
user:
Release PortalServer_rootbase\wp.db.impl\config\templates\setupdb\db2_iseries\release\
Related concepts:
Related tasks:
Windows clustered server: Creating DB2 for IBM i user profiles on page 1403
Windows clustered server: Transferring DB2 for IBM i manually:
Before you begin:
the task to stall.
Note:
Installing 1407
Related tasks:
Windows clustered server: Creating and setting up IBM DB2 for i databases automatically on page 1404
Windows clustered server: Verifying DB2 for IBM i database configuration:
Related tasks:
Windows clustered server: Creating and setting up IBM DB2 for i databases automatically on page 1404
Windows clustered server: Granting privileges to IBM DB2 for i database users on page 1404
Windows clustered server: Setting up a remote DB2 for z/OS database:
Windows clustered server: Installing DB2 for z/OS:
following commands:
following commands:
Installing 1409
export EXTSHM=ON
db2start
profile.env file:
DB2ENVLIST=EXTSHM
export EXTSHM=ON
remote database.
Windows clustered server: Modifying DB2 for z/OS database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
Note:
for the domain.
DbName.
Installing 1411
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
this value.
driver class.
Windows clustered server: Using JCL templates to set up DB2 for z/OS:
created.
successfully.
authority.
on the database
authority.
Installing 1413
Related tasks:
Windows clustered server: Creating DB2 for z/OS users:
installation.
(R) - at runtime
where:
data.
Installing 1415
Related tasks:
Windows clustered server: Creating remote DB2 for z/OS databases:
machine.
the databases.
500 DEFINE NO;
Related tasks:
Windows clustered server: Granting privileges to DB2 for z/OS database users:
database user:
Installing 1417
Related concepts:
Related tasks:
Windows clustered server: Assigning custom DB2 for z/OS table spaces:
Installing 1419
Before you begin:
PADIX=NO, or both.
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Related tasks:
Windows stand-alone: Configuring your portal to use DB2 for z/OS:
Follow these steps to transfer WebSphere Portal, and Java Content Repository databases to DB2 for z/OS.
Before you begin:
Tips:
Repository schema.
you transfer data.
a. Locate the file C:\Program Files\IBM\SQLLIB\db2cli.ini.
Editing db2cli.ini:
Installing 1421
[COMMON]
DYNAMIC=1
ReturnAliases=0
(createRuntimeRoleForDifferentSchema.sql or createRuntimeRoleForSameSchema.sql) containing the
required GRANT statements for each of the db domains.
user name and the schema name. These files are located in PortalServer_root\base\wp.db.impl\
config\templates\setupdb\db2_zos\domain and PortalServer_root\pzn\prereq.pzn\config\
templates\setupdb\db2_zos\domain directories.
createRuntimeRoleForSameSchema.sql file as appropriate. For the JCR domain, make sure that the
runtime user (jcr.DbRuntimeUser) is added to runtime group (jcr.DbRuntimeRoleName). Execute
the file PortalServer_rootPortalServer_root\jcr\wp.content.repository.install\config\
templates\setupdb\db2_zos\jcr\grantPermissionsToRuntimeRoleStatic.sql.
...
Installing 1423
Related tasks:
Windows stand-alone: Granting privileges to DB2 for z/OS database users on page 1281
Windows clustered server: Granting privileges to DB2 for z/OS database users on page 1417
Windows clustered server: Setting up an Oracle or Oracle RAC database:
Windows clustered server: Installing Oracle or Oracle RAC:
Before you begin:
Considerations:
$ gsdctl start
$ lsnrctl start
$ agentctl start
Windows clustered server: Modifying Oracle or Oracle RAC database properties:
jcr.DbName=jcrdb
Installing 1425
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
Installing 1427
class.
Windows clustered server: Creating Oracle or Oracle RAC databases:
information:
Server Mode.
pre_page_sga = true
as follows:
FORCE
EXACT
Windows clustered server: Setting up Oracle or Oracle RAC automatically or manually:
Note:
database.
Windows clustered server: Running a task to automatically setup Oracle or Oracle RAC:
Installing 1429
Note:
Windows clustered server: Setting up Oracle or Oracle RAC manually:
Windows clustered server: Creating Oracle or Oracle RAC database schemas and users:
Before you begin:
installation.
environment.
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
Windows clustered server: Granting privileges to Oracle or Oracle RAC database users:
Installing 1431
database user:
Installing 1433
user:
Installing 1435
Related concepts:
Windows clustered server: Creating JCR table spaces:
environment.
command.
Windows clustered server: Assigning custom Oracle or Oracle RAC table spaces:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
COMM8KSPACE
Windows clustered server: Configuring your portal to use Oracle or Oracle RAC:
Before your begin:
Installing 1437
Tips:
Repository schema.
files:
name are the same.
SQL > commit;
Exit sqlplus
Installing 1439
Related tasks:
Technote 1317981
Windows clustered server: Changing Oracle or Oracle RAC driver types:
IBM WebSphere Portal requires the use of either JDBC Type 4 drivers or JDBC OCI Type 2 drivers when
connecting to Oracle or Oracle RAC. You may need to change driver types after a migration. To migrate
JDBC Type 4 drivers. Once migration is complete, you can continue using JDBC Type 4 drivers or change
the driver type to JDBC OCI Type 2 drivers as appropriate. Direct migration from a previous installation
of WebSphere Portal using JDBC Type 4 drivers to an installation using JDBC OCI Type 2 drivers is not
supported.
configuration task.
2. Enter the ConfigEngine.bat validate-database command to validate configuration properties.
Windows clustered server: Setting up a SQL Server database:
Windows clustered server: Installing SQL Server:
information.
Installing 1441
sqljdbc_xa.dll
7. Perform the following steps to enable XA Transactions in Windows Component Services:
a. Click Start > Settings > Administrative Tools > Component Services.
b. Expand the tree view to locate the computer where you want to turn on support for XA
transactions (for example, My Computer).
c. Display the menu for the computer name and click Properties.
d. Click Options and tune the Transaction Timeout that suits your environment. (The recommended
minimum is 180 seconds).
e. Click MSDTC and click Security Configuration.
f. Under Security Settings, select XA Transactions to enable this support.
g. Click OK to save your changes.
Windows clustered server: Modifying SQL Server database properties:
jcr.DbName=jcrdb
release
customization
community
jcr
feedback
likeminds
dbdomain.DbName
dbdomain.DbUrl
dbdomain.DbSchema
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 1443
Note:
v This value is the location to store the database files locally.
v This path must use two backslashes (\\) instead of a forward slash (/).
JDBC driver class.
Windows clustered server: Setting up SQL Server automatically or manually:
table spaces.
Note:
database.
Related tasks:
Windows clustered server: Installing SQL Server on page 1441
Windows clustered server: Running a task to automatically setup SQL Server databases:
privileges.
4. Click Files.
Autogrowth field.
Installing 1445
Windows clustered server: Setting up SQL Server manually:
Windows clustered server: Creating databases manually:
production server.
Windows clustered server: Creating SQL Server database schemas and users:
Before you begin:
installation.
createSchema.sql
createUsers.sql
community\createSchema.sql
community\createRuntimeUsers.sql
community\createUsers.sql
customization\createSchema.sql
customization\createRuntimeUsers.sql
customization\createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
Windows clustered server: Granting privileges to SQL Server database users:
Installing 1447
community\createConfigRoleForSameSchema.sql
database user:
community\createConfigRoleForDifferentSchema.sql
Installing 1449
community\createRuntimeRoleForSameSchema.sql
PortalServer_root\pzn\prereq.pzn\config\templates\setupdbsqlserver2005\feedback\
user:
community\createRuntimeRoleForDifferentSchema.sql
Installing 1451
Related concepts:
Windows clustered server: Assigning custom SQL Server filegroups:
Before you begin:
database transfer.
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Windows clustered server: Configuring your portal to use SQL Server:
Before you begin:
Tip:
Repository schema.
the task to stall.
only the JCR domain you can enter the following command: ConfigEngine.bat database-transfer
files:
Installing 1453
are the same.
Related tasks:
Windows clustered server: Installing SQL Server on page 1441
Windows clustered server: Modifying SQL Server database properties on page 1442
Windows clustered server: Verifying the database configuration:
environment.
source is wpdbDS.
Removing search collections on Windows:
a. Open the icm.properties file, located in the wp_profile_root\PortalServer\jcr\lib\com\ibm\icm/
Installing 1455
Collections.
deleted.
Related tasks:
Clustered environment: Performing post-installation tasks on Windows on page 1370
Creating the WebSphere Portal profile template on Windows in a clustered environment:
1. Run the ConfigEngine.bat enable-profiles -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory of the profile that you use as the primary node of the cluster.
Portal profiles. The Portal.car file is saved to the PortalServer_root\profileTemplates\
default.portal\configArchives directory.
2. Run the ConfigEngine.bat package-profiles -DWasPassword=password task to compress the
Related tasks:
Clustered environment: Performing post-installation tasks on Windows on page 1370
Windows clustered server: Configuring your portal to use a database on page 1371
Creating and augmenting a new Deployment Manager profile on Windows
options to create a default Deployment Manager profile:
Installing 1457
Method Steps
Profile
Management Tool
Complete the following steps to use the Profile Management Tool:
1. Run the pmt.bat command from the AppServer_root/bin/ProfileManagement directory.
8. On the Profile Name and Location panel, provide the name for the new profile and its location in the file system. The name and location must be
unique from other existing profiles. Click Next to continue.
Note: You can also choose to select the Create the server using the development template check box to enable developer mode for this profile and
the Make this profile the default check box to specify that this profile is the default profile in the system.
9. On the Node, Host Names, and Cell Names panel, provide the node name and TCP/IP host name for the new profile. If you plan to federate this
profile, the node name must be unique from other profiles in the same management cell (under Deployment Manager control). The host name must
be a valid and reachable over the network. Enter the cell name for this deployment manager. Click Next to continue.
10. On the Administrative Security panel, make sure that the Enable administrative security checkbox is checked. Enter values for the User name,
Password, and Confirm password fields. Click Next to continue.
11. On the Security Certificate (Part 1) panel, choose either the Create a new default personal certificate or the Import an existing default personal
certificate radio button and choose either the Create a new root signing certificate or the Import an existing root signing certificate radio button.
12. On the Security Certificate (Part 2) panel, either provide the new certificate information or verify the existing certificate information. Click Next to
continue.
14. On the Service Definition panel, specify whether or not the WebSphere Portal server in this profile is to be registered and controlled as a service.
15. On the Profile Creation Summary panel, review the information collected by the wizard, and then click Create to create the new profile based on
the supplied information.
Tip: You should remember the WebSphere Integrated Solutions Console port value and the Deployment Manager SOAP connector port values as
you need these values in the future.
Note: The port values presented in the summary value are overridden by the port values used by the servers present in the configuration archive
provided as part of the portal profile template. These port values need to be adjusted after profile creation if they are in conflict with other ports on
the local system.
manageprofile
command
manageprofiles.bat -create -templatePath AppServer_root/profileTemplates/management
-hostName hostname
-profileName Dmgr01
deployment manager:
for example in the C:\IBM\WebSphere\AppServer directory.
Note: If the Deployment Manager profile was not created in the default AppServer/profiles/
Dmgr01 directory, then the metadata_wkplc.xml file, located in the AppServer\profiles\Dmgr01\
config\.repository\metadata_wkplc.xml directory in the compressed file, must be copied into the
config\.repository subdirectory under the Deployment Manager profile directory.
manager profile.
Option Steps
manageprofiles command Run the following command from the AppServer_root\bin directory:
manageprofiles.bat -augment -templatePath
AppServer_root\profileTemplates\management.portal.augment
-profileName dmgr
In this example, the portal profile template is installed under the AppServer_root\profileTemplates directory. The
existing Deployment Manager profile is named dmgr and is located under the C:\WebSphere\AppServer\profiles\
dmgr directory.
e. Click Apply.
g. Click Apply.
Installing 1459
Related tasks:
Preparing your Windows operating system in a clustered environment on page 1360
Clustered environment: Installing with the Installation Manager on Windows on page 1362
Clustered environment: Installing with the response file on Windows on page 1366
Preparing to create the cluster on Windows
want to create:
wkplc.properties file, located in the wp_profile_root\ConfigEngine\properties directory, on the
password.
cluster:
compatible.
3. Run the following command from the wp_profile_root\bin directory to federate the primary node:
addNode.bat dmgr_hostname dmgr_port -includeapps
administrator
rerunning the task:
set correctly in the wkplc.properties file, located in the wp_profile_root\ConfigEngine\properties
directory:
deployment manager.
Installing 1461
c. Run the ConfigEngine.bat wp-prep-vmm-db-secured-environment -DWasPassword=password
-DDbDomain=la|federated.db -Ddb_type.DmgrDbLibrary=local full path of the database jars
the database jars.
Oracle: ojdbc14.jar
d. Run the ConfigEngine.bat wp-node-prep-vmm-db-secured-environment
wp_profile_root\ConfigEngine directory to create the variable used to access the VMM database jars.
Related tasks:
Preparing the primary node on Windows on page 1361
Creating a static cluster on Windows:
1. Run the ConfigEngine.bat cluster-node-config-post-federation -DWasPassword=dmgr_password task.
configuration
c. Run the ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=password
from the wp_profile_root\ConfigEngine directory, where:
Save your changes and then run the ConfigEngine.bat wp-change-portal-admin-user
e. Additional parameter for stopped servers: This task verifies the user against a running server
3. Run the ConfigEngine.bat cluster-node-config-cluster-setup -DWasPassword=dmgr_password task.
information.
Creating a dynamic cluster on Windows using WebSphere Virtual Enterprise:
Installing 1463
a. Run the ConfigEngine.bat cluster-node-config-post-federation -DWasPassword=dmgr_password
task.
security policies:
configuration
3) Run the ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=password
task, from the wp_profile_root\ConfigEngine directory, where:
newAdminGroupId. Save your changes and then run the ConfigEngine.bat wp-change-portal-
admin-user -DWasPassword=dmgr_password task.
b. Click New.
e. Click OK.
d. Click Add.
b. Click New.
primary node.
6) Click Append.
click Next.
j. Click Next.
instances.
wp_profile_root\ConfigEngine\properties directory:
Installing 1465
7. Run the ConfigEngine.bat cluster-node-config-dynamic-cluster-setup
-DWasPassword=dmgr_password task from the wp_profile_root\ConfigEngine directory to create the
dynamic cluster.
a. stopServer.bat WebSphere_Portal_servername -username admin_userid -password
admin_password
b. startServer.bat WebSphere_Portal_servername
Related tasks:
Preparing a remote Web server when portal is installed on Windows in a clustered
environment
2. If using Microsoft Internet Information Server, we recommend updating the UrlSegmentMaxLength
Registry key to a value of 0 to eliminate potential problems in a WebSphere Portal environment with
the default IIS limitation on the length of URL path segments. We also recommend updating the
AllowRestrictedChars Registry key to a value of 1 to accept hex-escaped characters in request URLs
that decode to the U+0000 - U+001F and U+007F - U+009F ranges.
Note: Refer to Http.sys registry settings for IIS for information.
feature:
f. Click OK.
server:
Installing 1467
Related tasks:
Creating and augmenting a new Deployment Manager profile on Windows on page 1456
Related reference:
Configuring WebSphere Portal to use a user registry on Windows in a clustered
environment
LDAP user registry.
information.
Related tasks:
Windows cluster: Preparing user registries:
Windows cluster: Preparing an Active Directory Server:
If you plan to use Active Directory as an LDAP user registry, you must install and set up the server so
that it will communicate with IBM WebSphere Portal.
Complete the following steps to prepare Active Directory:
1. Complete the following steps to install and configure Active Directory:
a. Install Windows 2003 or 2008 Server, which includes Active Directory. Refer to
http://www.microsoft.com/windows2000/technologies/directory/ad/default.asp for information.
b. Install required Service Packs.
c. Complete the following steps to install Internet Information Services (IIS), which is required to
export server certificates and must be installed before installing Certificate Services:
3) Choose the Internet Information Services (IIS) component and then click Next.
d. Use the following steps to install Certificate Services if you plan on using Active Directory over
SSL:
3) Select Certificate Services and then click Next.
4) Select Stand-alone root CA and then click Next. You can also choose other options depends on
you needs.
5) Enter CA identifying information and then click Next.
attribute to false.
3. Complete the following steps to enable SSL for Active Directory; this step is required to set passwords
during sign up and user creation:
a. Install an Enterprise Certificate Authority on a Windows 2000 Domain Controller, which installs a
certificate on a server or install a third-party certificate on the Domain Controller.
b. Click Start > All Programs > Administrative Tools > Active Directory Users and Computer.
c. In the Active Directory Users and Computers window, right-click on your domain name and select
Properties.
d. In the Domain Properties dialog box, select the Group Policy tab.
e. Select the Default Domain Policy group policy and then click Edit.
f. Select Windows Settings under Computer Configuration.
g. Select Security Settings and then select Public Key Policies.
h. Select Automatic Certificate Request Settings.
Installing 1469
i. Use the wizard to add a policy for Domain Controllers.
Note: When these requirements are complete, all domain controllers request a certificate and
support LDAP over SSL using port 636.
Windows cluster: Preparing an Active Directory-Lightweight-Directory-Services:
If you plan to use an Active Directory-Lightweight-Directory-Services as an LDAP user registry, you must
install and set up the server so that it communicates with IBM WebSphere Portal.
Complete the following steps to prepare Active Directory-Lightweight-Directory-Services:
1. Download Active Directory Application Mode and then install it; refer to Windows Server 2003 Active
Directory-Lightweight-Directory-Services for information.
Attention: By default, Active Directory-Lightweight-Directory-Services requires an enabled SSL to set
and update user passwords. If you do not want to enable SSL, go to Active Directory-Lightweight-
Directory-Services Frequently Asked Questions and click How do I enable password changes on an
unencrypted connection to Active Directory-Lightweight-Directory-Services.
attribute to false.
Windows cluster: Preparing a Domino Directory server:
Center.
Server installation > Installing Domino on Windows and complete this task.
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Internet password
wpsadmin
Group name
wpsadmins
Group type
Multi-purpose
Members
members.
the file.
Editor access.
Installing 1471
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
Windows cluster: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
Windows cluster: Preparing a Novell eDirectory:
4) Click Add.
with a text editor:
your LDAP server.
Windows cluster: Preparing an Oracle Directory Server:
Portal.
4) Click Add.
with a text editor:
your LDAP server.
Windows cluster: Preparing a Tivoli Directory Server:
Installing 1473
group.
4) Click Add.
with a text editor:
your LDAP server.
Choosing your user registry model on Windows in a clustered environment:
Choosing your stand-alone LDAP user registry on Windows in a clustered environment:
Windows cluster: Configuring a stand-alone LDAP user registry without SSL:
standalone.ldap.id
Installing 1475
11. Run the ConfigEngine.bat wp-validate-standalone-ldap-attribute-config -DWasPassword=password
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Installing 1477
Related tasks:
Configuring a stand-alone LDAP user registry over SSL on Windows in a clustered environment:
standalone.ldap.id
Installing 1479
13. Run the ConfigEngine.bat wp-validate-standalone-ldap-attribute-config
-DWasPassword=password task, from the wp_profile_root\ConfigEngine directory, to check that all
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
Related tasks:
Configuring the default federated repository on Windows in a clustered environment:
Installing 1481
Configuring a federated LDAP user registry on Windows in a clustered environment:
Adding an LDAP user registry on Windows in a clustered environment:
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
parameters.
id
baseDN
nameInRepository
Installing 1483
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
Installing 1485
cluster.
Related tasks:
Adding an LDAP user registry over SSL on Windows in a clustered environment:
Installing 1487
federated.ldap.id
federated.ldap.host
federated.ldap.port
repository.
parameters.
id
baseDN
nameInRepository
groups are stored.
Installing 1489
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 1491
Related tasks:
Adding a database user registry on Windows in a clustered environment:
file.
For information about creating databases manually on a Windows clustered server, see the related links.
Database Steps
1. Install DB2.
Installing 1493
Database Steps
db_files = 1024
log_buffer = 65536
pre_page_sga = true
processes = 300
a. Use a text editor to open the wkplc_dbtype.properties file, located in the wp_profile_root\
ConfigEngine\properties directory.
b. Enter a value for the following parameters under the appropriate database type properties
heading:
db_type.DbDriver
db_type.DbLibrary
c. Save your changes.
Limitation: The WebSphere Application Server UserManagement component (VMM) requires access
to the following database libraries to use the VMM database functions such as Property Extension
and database user registry, however, if the Portal is using the DB2 Type 2 driver, due to functional
limitations, VMM must use the DB2 Type 4 driver; see Configuring a JDBC provider and datasource
for federated repositories for additional information:
Oracle: ojdbc14.jar
exist.
e. Enter the complete paths to the library files, separated by ';", in the Value field; for example,
enter D:\IBM\SQLLIB\java\db2jcc4.jar;D:\IBM\SQLLIB\java\db2jcc_license_cu.jar.
Copy the library files into the appserver/lib directory. Then stop and restart the WebSphere_Portal
server to load the library files. In a clustered environment, you must also stop and restart the
Deployment Manager and the nodeagents.
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
federated.db.DbUser
federated.db.DbName
a. Navigate to the following directory: wp_profile_root\properties
a. Run the ConfigEngine.bat wp-prep-vmm-db-secured-environment -DWasPassword=password
-DDbDomain=federated.db -Ddb_type.DmgrDbLibrary=local full path of the database jars on
the Deployment Manager -DDmgrNodeName=dmgr_node_name task from the wp_profile_root\
Oracle: ojdbc14.jar
1) Set the property value for federated.db.DbType in wkplc.properties if you are using a
2) Run the ConfigEngine.bat wp-node-prep-vmm-db-secured-environment
-DWasPassword=password -DDbDomain=federated.db
-DVmmNodeName=node_name,node_name,node_name -Ddb_type.NodeDbLibrary=local full path
of the database jars task from the wp_profile_root\ConfigEngine directory on each node to
create the variable used to access the VMM database jars.
Installing 1495
8. Run the ConfigEngine.bat wp-create-db -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to add a database user registry to the default federated
repository.
groups are stored.
parameters.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
Windows clustered server: Creating databases manually on page 1446
production server.
Adding realm support on Windows in a clustered environment:
realmName
securityUse
delimiter
addBaseEntry
5. Run the ConfigEngine.bat wp-create-realm -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to add a new realm to the Virtual Member Manager
configuration.
Installing 1497
realmName
realm.groupParent
8. Run the ConfigEngine.bat wp-modify-realm-defaultparents -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to update the default parents per entity type and realm.
then run this task:
parameters.
realmName
addBaseEntry
d. Run the ConfigEngine.bat wp-add-realm-baseentry -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to add additional LDAP base entries to the realm
configuration.
d. Run the ConfigEngine.bat wp-change-was-admin-user -DWasUser=adminid
-DnewAdminGroupId=newadmingroupid task, from the wp_profile_root\ConfigEngine directory, to
user and group.
f. Run the ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=password
group.
d. Run the ConfigEngine.bat wp-default-realm -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to set this realm as the default realm.
d. Run the ConfigEngine.bat wp-query-realm-baseentry -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to list the base entries for a specific realm.
Installing 1499
the feature.
Related tasks:
Windows cluster: Adapting the attribute configuration:
repositories.
LDAP schema
Related tasks:
Windows stand-alone: Adding an LDAP user registry without SSL on page 1334
Windows stand-alone: Adding an LDAP user registry over SSL on page 1339
Windows stand-alone: Configuring a stand-alone LDAP user registry without SSL on page 1327
Windows stand-alone: Configuring a stand-alone LDAP user registry over SSL on page 1330
Windows cluster: Querying the defined attributes:
Run the ConfigEngine.bat wp-query-attribute-config -DWasPassword=password task, from the
Adding attributes on Windows in a clustered environment:
Application Server.
c. Run the ConfigEngine.bat wp-la-install-ear -DWasPassword=dmgr_password
Installing 1501
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
7. Run the ConfigEngine.bat wp-add-property -DWasPassword=password task to add the attribute to the
user registry.
Related tasks:
Mapping attributes on Windows in a clustered environment:
your LDAP server:
standalone.ldap.id
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:
Stand-alone ConfigEngine.bat wp-validate-standalone-ldap-
Federated ConfigEngine.bat wp-validate-federated-ldap-
Installing 1503
parameters.
standalone.ldap.id
heading:
parameters.
registry:
Stand-alone ConfigEngine.bat wp-update-standalone-ldap-
the wp_profile_root\ConfigEngine directory
Federated ConfigEngine.bat wp-update-federated-ldap-attribute-
wp_profile_root\ConfigEngine directory
parameters.
c. Run the ConfigEngine.bat wp-update-attribute-config -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory.
Related tasks:
Windows cluster: Removing attributes:
Installing 1505
model directory.
directory.
or
database:
Windows cluster: Configuring your portal to use dynamic groups in a clustered environment:
nodes.
v Name: memberurl
Windows cluster: Enabling referrals for your LDAP user registry in a clustered environment:
Installing 1507
Preparing additional cluster members on Windows
Related tasks:
Installing WebSphere Portal on Windows for the horizontal cluster nodes:
Related concepts:
Related tasks:
Additional node: Installing with the Installation Manager on Windows:
media.
v ar = Arabic
v ca = Catalan
v cs = Czech
Installing 1509
v da = Danish
v nl = Dutch
v en = English
v fi = Finnish
v fr = French
v de = German
v el = Greek
v iw = Hebrew
v hr = Croatian
v hu = Hungarian
v it = Italian
v ja = Japanese
v kk = Kazakh
v ko = Korean
v no = Norwegian
v pl = Polish
v pt = Portuguese
v ro = Romanian
v ru = Russian
v sk = Slovak
v sl = Slovenian
v es = Spanish
v sv = Swedish
v th = Thai
v tr = Turkish
v uk = Ukrainian
successful.
click OK.
stored.
e. Select Apply.
f. Select OK.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
c. Click Next.
directory path.
path.
3) Click Next.
Next.
Additional node: Installing with the response file on Windows:
Installing 1511
options:
Advantage):
Replace with
media.
v ar = Arabic
v ca = Catalan
v cs = Czech
v da = Danish
v nl = Dutch
v en = English
v fi = Finnish
v fr = French
v de = German
v el = Greek
v iw = Hebrew
v hr = Croatian
v hu = Hungarian
v it = Italian
v ja = Japanese
v kk = Kazakh
v ko = Korean
v no = Norwegian
v pl = Polish
v pt = Portuguese
v ro = Romanian
v ru = Russian
v sk = Slovak
v sl = Slovenian
v es = Spanish
v sv = Swedish
v th = Thai
v tr = Turkish
v uk = Ukrainian
successful.
response file:
-record
Installing 1513
-skipInstall
final panel.
response files.
d. Click Next.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
directory path.
path.
3) Click Next.
Next.
computer.
[ -useSocks ] ]
[ -verbose ]
Choosing the type of horizontal cluster to create on Windows:
Adding horizontal nodes to the static cluster on Windows:
a. Copy the profileTemplates.zip file from the PortalServer_root\profileTemplates directory on the
c. Run the installPortalTemplates.bat AppServer_root task from the newly created
Installing 1515
Option Steps
click Next.
cell (under Deployment Manager control). The host name must be valid and reachable over the network. Click
Next to continue.
CAUTION:
node.
to create the profile with WebSphere Portal.
manageprofiles.bat -create -templatePath
C:\WebSphere\PortalServer\profileTemplates\managed.portal
-profilePath C:\WebSphere\PortalServer\profiles\testManagedPortal1
-cellName testCell
-nodeName testNode
In this example, the portal profile template is installed under the C:\WebSphere\PortalServer\profileTemplates
directory. The new profile is named testManagedPortal1 and is located under the C:\WebSphere\PortalServer\
profiles\testManagedPortal1 directory.
4. Run the ConfigEngine.bat validate-database -DWasPassword=password task to validate your
database settings
5. Open the icm.properties file, located in the wp_profile_root\PortalServer\jcr\lib\com\ibm\icm/
6. Optional: Run the following command from the wp_profile_root\bin directory to federate the
additional cluster node:
addNode.bat dmgr_hostname dmgr_port
Installing 1517
Oracle: ojdbc14.jar
wp_profile_root\ConfigEngine directory to create the variable used to access the VMM database
jars.
security policies:
configuration
10. Run the ConfigEngine.bat cluster-node-config-cluster-setup-additional
following steps:
v LD_LIBRARY_PATH
v LIBPATH
v PATH
v SHLIB_PATH
f. Open a command prompt and change to the wp_profile_root\ConfigEngine directory.
g. Run the ConfigEngine.bat profile-update-entries task to update these entries with the correct
profile paths.
server:
admin_password
Adding a horizontal node to the dynamic cluster on Windows:
Installing 1519
cluster:
a. Copy the profileTemplates.zip file from the PortalServer_root\profileTemplates directory on the
c. Run the installPortalTemplates.bat AppServer_root task from the newly created
Option Steps
click Next.
cell (under Deployment Manager control). The host name must be valid and reachable over the network. Click
Next to continue.
CAUTION:
node.
to create the profile with WebSphere Portal.
manageprofiles.bat -create -templatePath
C:\WebSphere\PortalServer\profileTemplates\managed.portal
-profilePath C:\WebSphere\PortalServer\profiles\testManagedPortal1
-cellName testCell
-nodeName testNode
In this example, the portal profile template is installed under the C:\WebSphere\PortalServer\profileTemplates
directory. The new profile is named testManagedPortal1 and is located under the C:\WebSphere\PortalServer\
profiles\testManagedPortal1 directory.
server profile.
5. Run the ConfigEngine.bat validate-database -DWasPassword=password task to validate your
database settings
6. Optional: Run the following command from the wp_profile_root\bin directory to federate the
additional cluster node:
addNode.bat dmgr_hostname dmgr_port
Installing 1521
Oracle: ojdbc14.jar
wp_profile_root\ConfigEngine directory to create the variable used to access the VMM database
jars.
security policies:
configuration
10. Run the ConfigEngine.bat cluster-node-config-post-federation -DWasPassword=dmgr_password
task.
d. Click Add.
14. Run the ConfigEngine.bat dynamic-cluster-setup-additional -DWasPassword=dmgr_password task to
tune your additional cluster resources.
Installing 1523
server:
admin_password
Related tasks:
Choosing the type of vertical cluster to create on Windows:
Adding vertical cluster members to a static cluster on Windows:
members.
members.
f. Click OK.
a. Run the ConfigEngine.bat cluster-node-config-vertical-cluster-setup -DServerName=unique
vertical cluster servername -DWasPassword=password task, from the wp_profile_root\
setup task.
server:
Installing 1525
Resynchronize.
Solutions Console.
Adding vertical cluster members to a dynamic cluster on Windows:
members.
f. Click OK.
a. Run the ConfigEngine.bat cluster-node-config-vertical-cluster-setup -DServerName=unique
vertical cluster servername -DWasPassword=password task, from the wp_profile_root\ConfigEngine
setup task.
server:
Resynchronize.
Windows cluster: Tune your servers
should be used.
Installing 1527
Related tasks:
Configuring search in a cluster on Windows
Related tasks:
Configuring Portal Search in a cluster on Windows:
Portal cluster.
accordingly.
Notes:
Related concepts:
Portal Search.
Related tasks:
Configuring JCR search in a cluster on Windows:
Created a shared directory called jcr\search on a server in the network and ensure that each node in the
1. Edit the icm.properties file, located in the wp_profile_root\PortalServer\jcr\lib\com\ibm\icm
directory.
Installing 1529
search
For example: Y:/share/jcr/search
portlet:
e. Click OK.
deleted.
for information.
Setting up multiple clusters on Windows
new profile.
please contact IBM.
Related tasks:
Windows cluster: Tune your servers on page 1527
should be used.
Installing multiple clusters in a single cell on Windows:
already exists.
Installing 1531
Cluster A, run the ConfigEngine.bat create-alias-multiple-cluster
-DauthDomainList=release,jcr -DWasPassword=dmgr_password task from the wp_profile_root\
and password.
6. Run the ConfigEngine.bat mapped-app-list-create -DWasPassword=password task from the
wp_profile_root\ConfigEngine directory to build an inventory of Portal B enterprise applications and
portlets.
wkplc.properties file, located in the wp_profile_root\ConfigEngine\properties directory, on the
password.
8. Run the following command from the wp_profile_root/bin directory to federate Portal B:
addNode.bat dmgr_hostname dmgr_port -includeapps
rerunning the task:
set correctly in the wkplc.properties file, located in the wp_profile_root\ConfigEngine\properties
directory:
deployment manager.
10. Run the ConfigEngine.bat map-apps-to-server -DWasPassword=password task to determine which
11. Run the ConfigEngine.bat cluster-node-config-post-federation -DWasPassword=dmgr_password
task.
security policies:
configuration
Installing 1533
e. Additional parameter for stopped servers: This task verifies the user against a running server
a. Run the ConfigEngine.bat cluster-node-config-cluster-setup -DWasPassword=dmgr_password
task.
web server:
e.
1) Click New.
4) Click OK.
4) Click Add.
2) Click New.
click Next.
f) Click Append.
menu.
9) Click Next.
server instances.
f. Run the ConfigEngine.bat cluster-node-config-dynamic-cluster-setup
-DWasPassword=dmgr_password task from the wp_profile_root\ConfigEngine directory to create the
dynamic cluster.
web server:
Installing 1535
in a cell.
Related tasks:
Windows clustered server: Configuring your portal to use a database on page 1371
Routing requests across clusters on Windows:
of user requests.
Installing 1537
cluster.
Related concepts:
Related reference:
Sharing database domains between clusters on Windows
Manager.
clusters:
Related tasks:
Windows cluster: Tune your servers on page 1527
should be used.
Windows
Installing 1539
e. Click OK.
i. Select Apply.
j. Select OK.
Manager:
a. Open a command prompt in the wp_profile_root\ConfigEngine directory of each profile.
b. Run the ConfigEngine.bat enable-wcm -DWasPassword=password task on each profile.
Localizing a new virtual machine instance on Windows
You must install and configure VMware ESX to create a virtual machine environment. You must also
have WebSphere Portal installed and if appropriate configured before localizing your virtual machine
instance.
Complete the following steps to localize a new virtual machine instance:
1. Stop the WebSphere_Portal server running on the virtual machine.
2. Verify that the server1 server is running on the virtual machine. If it is not running, start the server.
3. Update the host name for the virtual machine instance per the instructions of the operating system.
4. Run the wsadmin -c "$AdminTask changeHostName {-nodeName node_name -hostName new_host_name}"
command from the wp_profile_root/bin directory to update the WebSphere Portal host name in the
IBM WebSphere Application Server configuration.
node_name is the node name of the current configuration and new_host_name is the TCP/IP host name
of the new virtual machine instance.
5. Optional: Complete the following steps to update the node name in the IBM WebSphere Application
Server configuration:
a. Run the wsadmin.bat -c "$AdminTask renameNode {-nodeName old_node_name -newNodeName
new_node_name}" command to update the node name in the IBM WebSphere Application Server
configuration.
old_node_name is the original node name of the current configuration and new_node_name is the
new node name you use for this instance.
Remember: This step is necessary to create a unique node name if you are federating and
clustering this node.
b. Edit the setupCmdLine.bat file, located in the wp_profile_root\bin directory and modify the SET
WAS_NODE=node_name entry to specify the updated node name.
c. Run the ConfigEngine.bat rename-node-in-cell-registry -DWasPassword=password
-DpreviousNodeName=oldNodeName, from the wp_profile_root\ConfigEngine directory, where
oldNodeName is the prior value of the node name.
6. Run the ConfigEngine.bat localize-clone -DWasPassword=password command from the
wp_profile_root\ConfigEngine directory to update WebSphere Portal with the information from the IBM
WebSphere Application Server configuration.
7. Run the ConfigEngine.bat action-clean-scheduled-tasks -DWasPassword=password command to clear
any scheduled tasks. Existing scheduled tasks might reference the old hostname.
8. Optional: If you had an existing Windows Service set up for the WebSphere_Portal server, it will still
reference the old host name and node name. If you want to continue using the Windows Service to
start and stop your servers, you must re-create the services using the WASService command. See the
'WASService Command' link for information.
9. Start the WebSphere_Portal server on the virtual machine.
WebSphere Portal is now ready to be used in this virtual machine instance.
Installing 1541
Related concepts:
Virtual environment overview on page 115
Related tasks:
WASService command
Installing on z/OS
WebSphere Portal.
Enabling the IBM Subcapacity Reporting Tool
The IBM Subcapacity Reporting Tool (SCRT) is a no-charge IBM tool that reports required license capacity
for subcapacity eligible products that run on IBM z/OS. For information on SCRT, refer to
http://www.ibm.com/servers/eserver/zseries/swprice/scrt/. For information on zSeries
software
pricing, refer to http://www.ibm.com/servers/eserver/zseries/swprice/. The input for SCRT tool is a
sequential data set containing SMF 89 records, subtypes 1 and 2, for all the LPARs on the specified CPCs.
At start up, IBM WebSphere Portal writes a string into SMF. Later, when the SCRT tool is invoked to
process the SMF records, the tool recognizes that WebSphere Portal is installed in the LPAR(s) and is
eligible for subcapacity pricing.
To use SCRT with WebSphere Portal, SCRT must be already installed on your z/OS base environment.
The string provided by the portal to the SCRT for SMF 89 records includes the following information:
v Product owner: IBM CORP
v Product number: 5655-Y16
v Product name: IBM WebSphere Portal
v Product version: Version 8.0
v Product function: IBM WebSphere Portal
In addition, WebSphere Portal also reports SMF89-1 data through a registration with IBM WebSphere
Application Server. During the start up time, WebSphere Application Server detects a registrar file that is
part of the configuration filesystem and then produces the appropriate records.
To enable WebSphere Portal for SCRT, configure the z/OS system to record SMF 89 records.
Worksheets
IBM WebSphere Portal provides worksheets that will assist you when defining variables within the
Customization Dialog. The worksheets are available on the WebSphere Portal wiki. Choose the worksheet
that matches the task within the Customization Dialog.
Installing and configuring your WebSphere Portal environment on z/OS
This section describes how to establish application-serving capability in new and existing environments.
The information includes planning, preparing, completing, and maintaining product installations.
Road map for installing on z/OS
This article describes the process of installing and configuring IBM WebSphere Portal.
This article introduces the context of installing and customizing WebSphere Portal, including the tasks
you need to perform before and after installing.
To create a complete and customized application serving environment, you need to install the product
code, prepare the z/OS operating system and subsystems, run the Customization Dialog, follow the
customized instructions and run the generated jobs, and bring up your servers.
Complete the following tasks to create a running version of the product on your machine:
1. Plan your product code installation.
v Order or acquire the IBM WebSphere Application Server and WebSphere Portal products.
v Review the system requirements and prepare for the WebSphere Application Server and WebSphere
Portal installation.
v Use SMP/e to install the IBM Installation Manager.
v Use SMP/e to install the WebSphere Application Server and WebSphere Portal product repositories.
2. Prepare your z/OS operating system.
v Prepare your RACF security settings.
v Other business specific preparations.
3. Install the WebSphere Application Server and WebSphere Portal product files.
v Use the IBM Installation Manager to install the WebSphere Application Server product code into the
/usr/lpp/zWebSphere/V8R0 directory and the WebSphere Portal code into the /usr/lpp/
zPortalServer/V8R0 directory.
v Customize and run the JCL provided for installation with each product repository.
v Complete the installation of both sets of product files if creating a standalone profile.
v You can delay the installation of the WebSphere Portal product files until after step 4 if installing
into a managed profile.
4. Choose your topology and plan its initial characteristics before configuring WebSphere Portal.
v Base or Full installation
v Standalone environment
v Managed, non-clustered environment
v Managed, clustered environment
5. Configure WebSphere Portal.
v Use the Customization Dialog to create customization instructions/jobs.
Note: The exact configuration steps depend on the topology you selected. Review the appropriate
installation scenario to plan the order of customization instructions/jobs to create:
Setting up a stand-alone production server on z/OS on page 1560
Setting up a federated unclustered production server on page 1588
Installing 1543
Setting up a clustered production environment on z/OS on page 1614
v Run the WebSphere Application Server and WebSphere Portal configuration jobs to create the
WebSphere Application Server and WebSphere Portal runtime configurations.
6. To create additional environments, repeat these steps.
7. Tune for performance.
You are ready to deploy and run applications with WebSphere Portal.
Skill requirements
In assembling your project team, you should consider the skills you need to implement IBM WebSphere
Portal. This article discusses the recommended skill set necessary to support basic and production
configurations.
Documentation to support the z/OS skills described in this article can be found at the following website:
z/OS Internet Library
For basic configurations:
Below are the recommended skills necessary to support a basic configuration:
v z/OS UNIX System Services, hierarchical file systems (HFS) and zSeries File System (ZFS) - to set up a
functional HFS, ZFS and UNIX environment
v eNetwork Communications Server (TCP/IP) or equivalent - to configure connectivity for WebSphere
Portal clients and servers
v Resource recovery services (RRS) - to implement resource recovery services and to support two-phase
commit transactions
v Security Server (RACF), or the security product you use - to authenticate WebSphere Portal clients and
servers, and authorize access to resources
v Secure Sockets Layer (SSL) - to enable security if required (recommended)
v IBM Installation Manager, SMP/E, and JCL
v System logger - to set up log streams for RRS and the WebSphere Portal error log
v Web server - to support HTTP clients if desired
v Workload management (WLM)
v Java and WebSphere Portal tooling - to support application development and deployment
v Ability to navigate on a 3270 Terminal emulator using MVS
v Familiarity with TSO/E OMVS to access the z/OS shell
Depending on the needs of the applications you deploy, you might also need skills to configure the
resource managers your applications require, such skills might include CICS
, DB2, IMS
, and MQ.
For production environments:
As you move your system toward a production environment, you need to have the following system
skills available:
v Automatic restart management (ARM)
v System Automation, if you have it installed, or whichever automation you prefer to use
v Sysplex if you plan to use WebSphere Portal in a cell that spans systems
v Sysplex Distributor (part of eNetwork Communications Server), if you plan to create a high availability
environment
v RMF
or other performance measurement systems

Creating implementation plans on z/OS
Create a plan for implementing your IBM WebSphere Portal application serving environment.
We assume that you have a z/OS system on which you will implement WebSphere Portal.
To get started, plan to build your initial WebSphere Portal application serving environment servers on
one system, then replicate them on other systems as you expand into a cell. This procedure first guides
you through initial planning and implementation of WebSphere Portal on a monoplex. Then, it guides
you through setting up your application development and client environments. Finally, the procedure
guides you through planning for optional advanced system configurations.
Perform the following steps to implement your plan, checking off each item as you complete it:
1. Determine the skills that you need.
2. Determine the hardware and software requirements.
3. Understand the security options and prepare for securing your system.
4. Implement Workload Management in goal mode on each z/OS system if necessary.
5. Implement Resource Recovery Services (if not already implemented) on each z/OS system.
6. Plan for your performance monitoring systems.
7. Plan and define your problem diagnosis procedures.
8. Consider automatic restart management before you install WebSphere Portal.
9. Plan your product dataset and HFS naming conventions.
10. Install the WebSphere Portal product.
11. Prepare your z/OS target systems to run WebSphere Portal.
12. Learn about configuring application serving environments.
13. Set up a simple standalone application server to verify system readiness and gain experience with a
basic application serving environment.
14. Plan and define your system backup procedures.
15. Plan and define your software service procedures.
16. (Optional) Plan for testing and production systems.
17. Plan and configure the application serving environments that you want.
18. Review your administration and application security requirements and settings.
19. Develop and deploy applications.
20. Review WebSphere Portal requirements for application development and client environments.
21. (Optional) Implement Sysplex Distributor, and set up a high-availability environment.
22. (Optional) Expand your application serving environments as needed.
23. Tune system performance.
Once you have identified the elements you want to incorporate in your implementation plan, you are
ready to install and configure the product.
Planning for product installation on z/OS
IBM WebSphere Portal Version 8 is installed using IBM Installation Manager. This article outlines the
issues that you should consider in planning your product installation.
Overview of IBM Installation Manager
IBM Installation Manager is a general-purpose software installation and update tool that runs on a range
of computer systems. Installation Manager can be invoked through a graphical user interface (GUI) or a
command-line interface. You can also create response files in XML and use them to direct the
performance of Installation Manager tasks in silent mode.
Installing 1545
Restrictions:
v The Installation Manager GUI is not available on z/OS; all interaction with Installation Manager is
done through the command line or response files.
v Installation Manager console mode, which is included in Installation Manager Version 1.4.3 and later,
does not work with WebSphere Portal offerings.
For more information on using Installation Manager, read the IBM Installation Manager Information
Center.
Packages and package groups
Each software product that can be installed with Installation Manager is referred to as a "package." An
installed package has a product level and an installation location. A package group consists of all of the
products that are installed at a single location.
To manage multiple copies of a software producta test copy and a production copy for exampleyou
install the product several times and into separate package groups, each with a distinct installation
location. The different copies of the product can be maintained or upgraded separately.
Installation Manager modes
IBM Installation Manager can be installed in one of the following three modes:
v In administration mode, the Installation Manager is installed from a superuser ID and can be invoked
by any superuser.
A file pointing to the Installation Manager is created in /etc/.ibm/registry; therefore, there can only
be one admin-mode Installation Manager on a z/OS operating system.
v In non-administration mode (also called "user mode"), the Installation Manager can be invoked only by
the user that installed it.
A file pointing to the Installation Manager is created in $HOME/etc/ibm/registry; therefore, there can
only be one user-mode Installation Manager for a user.
v In group mode, the Installation Manager can be invoked by any user ID that is connected to the
default group of the user that installed it.
A file pointing to the Installation Manager is created in appdata_location/etc/.ibm/registry. So there
is no limit to the number of group-mode Installation Managers per system or user as long as each has
its own appdata location.
How many Installation Managers do I need?
You only need to run Installation Manager on those systems on which you install or update product
code. You normally need only one Installation Manager on a system because one Installation Manager
can keep track of any number of product installations.
Getting the Installation Manager installation kit
IBM Installation Manager comes in the form of an installation kit, which contains a set of Installation
Manager binaries and a repository for the Installation Manager product. On z/OS, the Installation
Manager installation kit normally resides at /usr/lpp/InstallationManager/V1R5. A copy of the
Installation Manager installation kit is provided in SMP/E format with the WebSphere Portal product.
The installation kit is only used for setup and maintenance of the Installation Manager .
Creating an Installation Manager
When the installation kit is available on your z/OS system, you can create an Installation Manager. An
Installation Manager consists of a set of binaries that are copied from the installation kit and a set of
runtime data that describe the products that have been installed by this particular Installation Manager.
Before creating an Installation Manager, you must decide in which mode the Installation Manager will
run as well as where the binaries and runtime datacalled "agent data" or "appdata"will reside. Then,
you issue the Installation Manager installc, userinstc, or groupinstc command from the appropriate
user ID to create the Installation Manager.
Accessing product repositories
All software materials that will be installed with IBM Installation Manager are stored in repositories. Each
repository contains program objects and metadata for one or more packagesthat is, software products
at a particular level. Repositories can also contain product maintenance, such as fix packs and interim
fixes.
The initial product repository for administration is installed on your system with SMP/E. This
SMP/E-installed repository will be updated over time to include regular product service in the form of
fix packs.
You can also have Installation Manager download product fix packs and interim fixes from an IBM
service website. Interim fixes are available only through the service website or from the IBM Support
Center.
Whenever you install a new product, you can choose from any of the available product levels in any
accessible repository.
Installing the product
After you have created an Installation Manager and have access to all necessary product repositories, you
can use Installation Manager command-line commands or response files to perform the actual product
installations. When you install a product, you provide the package name, optionally the product level to
be installed, the product location, and any other optional properties. For example, some products have
optional features that you can select at installation time or a list of optional supported language packs
from which you can select.
Each copy of a product must be installed at a separate installation location (file system path). Certain
products might be intended to be installed together into a common location.
Choosing installation locations is a critical part of product planning. These installation locations will
normally be distinct from the locations at which the products are mounted when actually in use.
Working with installed products
You can use Installation Manager commands to list installed products and product levels. You can also
obtain this information for installed copies of WebSphere Portal products by issuing the versionInfo.sh
command from the product file system.
After products are installed, you can unmount them from the locations at which they are known to
Installation Manager and remount them at other production locations or you can copy them to other
computer systems. If you copy the Installation Manager binaries and runtime data along with the product
file system, you can apply maintenance to the installed products on any computer system that has access
to the product and service repositories.
Installing 1547
You can use Installation Manager commands or response files to install a new product level, roll back to
a previous level, or modify the product by adding or removing optional features or language packs.
Product file system on z/OS
The z/OS file system contains the IBM WebSphere Portal product directory and at least one or more
configuration directory.
WebSphere Portal product directory
All WebSphere Portal product files are in the product directory and its subdirectories. Throughout the
product and documentation, install_root is used to represent the fully qualified path name of the
WebSphere Portal product directory. In the examples in the documentation, the path
/usr/lpp/zPortalServer/V8R0 is used as the location of the product file system.
Locate the product directory and all of its subdirectories in the same hierarchical file system (HFS) or
zSeries file system (ZFS) data set. This data set can be the same as the WebSphere Portal root or version
data set, which is not the preferred option. It can also be a separate data set that is used just for
WebSphere Portal. The installation jobs and program directory assume that such a separate data set is
allocated. This data set is named portal_hlq.SEJPZFS, where portal_hlq represents the product data set
name high-level qualifiers. This directory gets created during the installation process.
Product directory and configuration directory
Each WebSphere Portal application server environment (stand-alone application server node or Network
Deployment cell) has configuration files in one or more configuration directory. These configuration
directories are created through the configuration process and contain symbolic links to files in the
product directory.
Using indirection to isolate product directories
Instead of pointing directly to these product directories, application server environments can point to an
intermediate symbolic link. The intermediate symbolic link then points to a particular product directory.
You can use this level of indirection to switch to a new WebSphere Portal server level by stopping the
servers that use that intermediate symbolic link. You then change the link to point to the new product
directory and restart the affected servers.
Use the customization process for automatic creation of these intermediate symbolic links.
Using the Customization Dialog to configure WebSphere Portal using
Customization is the process during which you make your installed IBM WebSphere Portal code work for
you. This topic outlines the steps you follow to configure your WebSphere Portal using the Customization
Dialog. Some of these tasks are completed during installation, as directed in the documentation, and
other tasks are completed later when configuring the portal.
Before you begin to use the WebSphere Portal Customization Dialog, it is important that you read the
section Tips for using the Customization Dialog on page 1549. This provides valuable information
which is essential to help prevent you having difficulty when customizing your portal.
Note: You have several tools on your system that you can use to determine or verify this information.
Those tools include z/OS and TSO commands, ISPF, SDSF, and other tools such as MXI.
Important: In order to use the Customization Dialog, you must know or be able to find the system
characteristics for the system on which WebSphere Portal will run.
Complete the following steps to use the Customization Dialog to configure your WebSphere Portal:
Using the Customization Dialog
Customizing IBM WebSphere Portal is performed using the Customization Dialog. It is an ISPF Dialog
that eliminates the need to tailor sample jobs supplied with the product. Through a series of panels, you
choose options and define variables. The Customization Dialog tailors the WebSphere Portal
customization jobs for your variables. It provides a custom set of instructions for you to follow to run the
associated tailored jobs to complete the product customization. The Customization Dialog is intended for
the system programmer or administrator responsible for installing and customizing WebSphere Portal.
Note: In order to use the Customization Dialog, you must know or be able to find the system
characteristics for the system on which WebSphere Portal will run.
The Customization Dialog covers a portion of the customization process. Specifically, it creates tailored
jobs to do the following:
v Set up WebSphere Portal security controls (RACF)
v Define the WebSphere Portal runtime configuration
v Modify the WebSphere Portal runtime configuration
v Migrate the basic configuration of WebSphere Portal and its components
v Collect data pertinent to a problem scenario to help identify the source of the problem
The Customization Dialog also produces a set of instructions for you to follow in order to effectively run
these tailored jobs.
Tips for using the Customization Dialog
The Customization Dialog coordinates the specification of customized variables, and its usage is
enhanced by careful planning and understanding of the z/OS environment. Here are some suggestions:
v Develop a good naming convention for long and short server names, cell and node names, user IDs,
WLM application environments, and other profiles.
v Choose unique UIDs and GIDs for any new user IDs defined in the Customization Dialog. Use the
ISHELL User List and sort on UIDs using the File pull-down to get a list of all UIDs assigned in your
system.
v Validate the customized variables with your communication specialist, database administrator, and
security administrator.
v Before installing WebSphere Portal, ensure your customization variables are current. Since portal uses
many WebSphere Application Server for z/OS customization variables, the variables must match your
target system and must be available when you start customizing your portal. When configuring your
portal into a base application server node, load the WebSphere Application Server for z/OS
customization variables you used when configuring that base application server node.
v When configuring your portal into a managed node, you may be prompted to load the WebSphere
Deployment Manager for z/OS customization variables in addition to the dataset member containing
the customization variables for WebSphere Application Server for z/OS. The extra member is required
depending on the template path selected when installing WebSphere Portal and if you are installing
into a secondary node.
v If you use an existing user ID in a new WebSphere Portal release, you may receive an error message
when attempting to load saved variables. To avoid or clear this error, you must either use a new APPL
value or erase your ISPF profile.
v It is important to ensure that variables that apply to the primary node can never be mixed up with
variables that apply to the secondary node. Therefore, it is essential when you start the Customization
Dialog to make sure that you specify a unique APPL() parameter for each portal node that you
configure. For example, when starting to configure the primary node in a cluster, you might specify
APPL(nda). When you start to work on the secondary node, start the Customization Dialog using
Installing 1549
APPL(ndb). Never try to configure a secondary node after starting the Customization Dialog using an
APPL() that was used to configure the primary node.
v Each application name that used (APPL()) will store information in the user's *.SPF.ISPPROF dataset,
and it needs to have enough space to allow for the storage of this information. If insufficient space is
provided, you will get ISPF errors while using the Customization Dialog and might see errors while
trying to generate the appropriate jobs for a step (for example, TBOPEN WRITE errors) or while
navigating to various panels. The amount of space used is determined by the variety of panels
traversed during the customization itself. The minimum should be 2 tracks and 1 directory block per
application name but it could require more, depending on the configuration (for example, federation,
security).
v Never load saved variables that apply to the wrong node. For example, do not configure a secondary
node by loading variables that were saved when you configured the portal in the primary node. If you
do this the secondary node will have several WebSphere variables set to the primary node and you
will find that jobs run against the incorrect node, possibly damaging the primary node configuration.
v Use the same ISPF application name -- APPL(xxxx), or load the saved variables when you move from
option to option (for example, from "Configure base portal" to "Enable portal security".)
v Take advantage of the help screens (via PFKey 1) for useful information about the panel.
v Examine the members in the target .CNTL and .DATA partitioned data sets and the .SAVECFG data set
where you saved them.
v Understand how your customized variables affect the generated jobs and data files by browsing each
one using the customized instructions in the EJPI* members of the .CNTL data set as a guide.
v It is recommended to regenerate all the jobs and data after changing values on the Customization
Dialog. Changing the values in the Customization Dialog after generating the jobs and data, and then
attempt to make manual corrections to the target CNTL or DATA members can cause problems.
Starting the Customization Dialog
This topic explains how to start the Customization Dialog, which is used to customize your IBM
WebSphere Portal environment.
You must have the product code installed and have access to the product data sets for both IBM
WebSphere Application Server for z/OS and IBM WebSphere Portal.
Restrictions:
v Your logon display must support 3270 emulation and be set to a minimum of 32 rows by 80 columns
(32 x 80) in order for the ISPF WebSphere Portal Customization Dialog to run.
v If you have a 32-row display and use the ISPF split screen function, deselect "Always show split line"
on the ISPF Settings panel to prevents the split screen line from displaying and lines in the
Customization Dialog panel from being obscured. Other uses of split screen will obscure lines in the
Customization Dialog.
v If you have a 32-row display, you cannot display the PF key settings. Displaying the PF key settings
will obscure lines on the Customization Dialog panels. Issue PFSHOW OFF.
Complete the following steps to start the Customization Dialog:
1. Type the TSO or Workstation command on the ISPF command line: ex 'hlq.sejpclib(ejpstart)'
'options', where:
hlq High-level qualifier for the SEJPCLIB data set of WebSphere Portal, for example ejp.
options
Command options. Enclose any and all options in a single set of quotes.
appl(value)
Specifies the ISPF application name. This option creates unique ISPF profiles, usually stored in
the "userid.ISPF.ISPFPROF" data set, that are useful when you want to keep saved variables
separate from those in other target environments. The default value is: EJP7.
Note: It is strongly recommended to always specify an ISPF application name, and not stay
with the default. This allows you to easily differentiate between customization variables for
different nodes.
Important: If you use an existing user ID in a new WebSphere Portal release, you may receive
an error message when attempting to load saved variables. To avoid or clear this error, you
must either use a new APPL value or erase your ISPF profile.
For example, type the ex ejp.sejpclib(ejpstart)' 'appl(wp8c)' command.
2. Press Enter; the copyright panel of the WebSphere Portal Customization Dialog displays.
3. Press Enter; the WebSphere Portal Configuration for WebSphere Application Server Customization
Dialog panel displays.
Note: The WebSphere Portal license agreement displays on the first invocation with a new appl ID.
Press PF3 or PF12 to review and accept the license agreement.
----------------- WebSphere Portal for z/OS Customization ------------------
Option ===> Appl: EJP8
Portal configuration for WebSphere Application Server 8.0
Use this dialog to load the WebSphere Application Server configuration
data in order to install and configure WebSphere Portal for z/OS for
the first time. You must load the WebSphere data as the first step.
Afterwards, you may continue to use these panels to configure your portal.
Specify an option and press ENTER.
Complete?
1 Load base configuration data from z/PMT
2 Configure WebSphere Portal for z/OS
4. Choose option 1, and press Enter; the Load customization variables dialog displays.
You must complete this step in order to preload the WebSphere Application Server customization data
before customizing WebSphere Portal. Type the fully-qualified member name of the data set member
containing the WebSphere Application Server customization data created and uploaded from the
z/PMT tool. For example, you might enter 'MYWAS.WASV8.DATA(PMTCELL)'.
Option ===>
Load WebSphere Application Server Customization Variables
Specify the name of a data set containing the customization variables,
then press Enter to continue.
Data set name: MYWAS.WASV8.DATA(PMTCELL)
If this data set is not cataloged, specify the volume.
Volume:
Note: You will be prompted later for the name of the data set member
containing the WebSphere Deployment Manager settings if you are
loading the data associated with a managed node install scenario.
5. After entering the data set name, press Enter to load the variables and return to the previous panel.
Note: Depending on the WebSphere Application Server template path that you use, you may also be
prompted for the Deployment Manager values; this is a separate dataset member.
Installing 1551
6. Choose option 2, and press Enter; the Portal configuration panel displays.
7. Choose one of the following options, and then press Enter:
Note for first time uses: If you are logging in for the first time, you must first define variables using
the Basic configuration tasks panel before you can choose options 2, 3, 4, or 5.
v If you choose option 1, you see the Basic configuration tasks panel. You can configure a base
portal, uninstall the portal, or install and configure a feature pack.
v If you choose option 2, you see the Advanced configuration tasks panel. You can configure a
virtual portal, configure portal paths (change the Portal URI), run security configuration tasks,
transfer a database, and run advanced cluster scenarios.
v If you choose option 3, you see the Application configuration tasks panel. You can configure
Productivity Components, LikeMinds samples, Web Content Manager, Personalization, and Solution
Installer.
v If you choose option 4, you see the Portal migration tasks panel. You can complete pre-upgrade
actions, post-upgrade actions, WMM to VMM security migration, and post migration data updates.
v If you choose option 5, you see the Collect diagnostics panel. You can collect diagnostic
information regarding a problem or other issue with your portal. This option is always selectable,
even if you have not completed option 1.
8. Press PF3 to exit the WebSphere Portal Customization Dialog.
Allocating the target data sets
This section tells you how to complete the Allocate target data sets option that is in all of the main tasks
you can perform.
Perform the following steps to allocate the target data sets:
1. On the main Customization Dialog panel, type 1 in the Option field to select "Allocate target data
sets".
2. Press Enter. You see a panel that looks similar to the following:
Option ===>
Allocate target data sets
Specify a high level qualifier (HLQ) and press ENTER to allocate the
data sets to contain the generated WebSphere jobs and instructions.
You can specify multiple qualifiers, (up to 39 characters).
High level qualifier: .CNTL
.DATA
The dialog will display data set allocation panels. You can make
changes to the default allocations, however you should not change
the DCB characteristics of the data sets.
.CNTL - a PDS with fixed block 80-byte records to
contain customization jobs.
.DATA - a PDS with variable length data to contain
other data produced by the Customization Dialog.
3. Follow the options in order and then press Enter.
Defining variables
This section describes how to complete the "Define variables" option that is in all of the main tasks.
Complete the following steps to define variables:
1. On the main Customization Dialog panel for the task you are performing, type 2 in the Option field
to select "Define variables".
2. Press Enter. The following screen displays:
Option ===>
Configure a base portal into a base node
Specify a number and press ENTER to define the WebSphere Portal
variables. You should review all of the variables in each of the
sections, even if you are using all of the IBM-supplied defaults.
Once you complete all sections, press PF3 to return to the main menu.
Changed?
1 - Review WebSphere variables (mandatory) Y
2 - System locations (directories, HLQs, etc) Y
3 - Server configuration Y
4 - Portal configuration Y
Note: This example is from the "Configure a base portal into a base node" option, but the steps are
relatively the same regardless of which option you choose.
Saving the customization variables
This topic provides information on saving the customization variables after you define variables in the
Customization Dialog panels. When loading and saving variables it is important that you only ever load
and save variables that apply to the node you are working on. For example, when saving variables that
apply to the portal customization for the primary node in a cluster, make sure you save variables to a
data set whose name indicates that it is a primary node. For example, when saving the variables you
used to configure the base portal into the primary node, A, of an network deployment configuration, you
might save to hlq.nodea.SAVECFG. Then when saving variables for configuring the base Portal into the
secondary node, B, you might save to hlq.nodeb.SAVECFG.
You must have completed the definition of the variables, as described in Defining variables on page
1552.
Perform the following steps to save the customization variables:
1. On the main Customization Dialog panel for the task you are performing, type S in the Option field
to select "Save customization variables".
2. Press Enter.
You see the Save customization variables panel, which looks similar to this:
Option ===>
Save customization variables
Specify the name of a sequential data set to contain the customization
variables, then press Enter to continue. If the data set does not
exist, the dialog displays the Allocate New Data Set panel, through
which you can allocate a data set.
Data set name:
3. Follow the options in order. Be sure to enclose your data set name in single quotes, then press Enter.
Generating customization jobs
This topic provides information on generating the customization jobs after you define variables in the
Customization Dialog panels.
You must complete the definition of the variables, as described in Defining variables on page 1552.
Installing 1553
Perform the following steps to generate customization jobs:
Recommendation: When you have finished entering all your customization data, before you generate the
customization jobs, use the "Save customization variables" option to save your customization variables for
future reference.
to select "Generate customization jobs".
2. Press Enter.
3. Choose option 1 or 2, depending on whether you want to generate customization jobs for this task
only or all customization jobs. For more information on these options, see the panel Help.
4. Press Enter.
Note: Pay particular attention to the displayed target data sets.
5. Fill in the job card information using the Generate customization jobs worksheet, then press Enter.
Viewing and following the generated customization instructions
This topic provides information on viewing and following the customization jobs that you created after
defining variables in the Customization Dialog panels.
You must complete the generation of the customization jobs, as described in Generating customization
jobs on page 1553.
Perform the following steps to view and follow the generated customization instructions:
to select "View instructions".
2. Press Enter; the generated instructions file displays.
3. View the instructions.
4. Check the instructions for any typographical errors you may have introduced when entering your
variables or other information. If necessary, modify your variables using the Customization Dialog,
regenerate the instructions, and review the results again.
Important: Do not attempt to fix a typo or make a change by modifying the generated output. Many
of the variables are used in multiple members of the target datasets, so it is best to regenerate the
customization jobs through the customization dialog.
5. Print the instructions according to your local printing procedures.
Loading customization variables
This section tells you how to complete the "Load customization variables" option that is on all of the
main configuration tasks. If you save your variables, you can follow these instructions to reload those
variables. When loading and saving variables it is important that you only ever load and save variables
that apply to the node you are working on. For example, when customizing the secondary node, do not
load the variables from the primary node. Instead load the last variables you saved for configuring the
secondary node. These are usually the variables you saved when configuring the application server on
the secondary node. You can also load the variables used to federate the secondary node.
When you first run the Customization Dialog, you must point to the data set member created by the
zPMT tool. This must be done before you can configure WebSphere Portal.
Complete the following steps to load customization variables:
1. Navigate to a customization panel where you are required to enter variables, you can load your
customization variables from a data set. Type L in the Option field to select "Load customization
variables".
The following is an example of a customization panel where you are required to enter variables:
----------------- WebSphere Portal for z/OS Customization -----------------
Option ===> Appl: EJP7
Configure a base portal into a base node
Use this dialog to define WebSphere Portal for z/OS variables and
generate customization jobs for your installation.
Specify an option and press ENTER.
1 Allocate target data sets. The data sets will contain the
WebSphere Portal customization jobs and data generated by the dialog.
2 Define variables. Define your installation-specific information
for WebSphere Portal customization.
3 Generate customization jobs. Validate your customization
variables and generate jobs and instructions.
4 View instructions. View the generated customization instructions.
Options for WebSphere Portal customization variables
S Save customization variables. Save your WebSphere Portal customization
variables in a data set for later use.
L Load customization variables. Load your WebSphere Portal customization
variables from a data set.
2. Press Enter.
You see the Load customization variables panel, which looks similar to this:
Option ===>
Load customization variables
Specify the name of a data set containing the customization variables,
then press Enter to continue.
IBM-supplied defaults are in:
BBO.SEJPEXEC(EJPWVARS)
Data set name:
If this data set is not cataloged, specify the volume.
Volume:
3. Follow the options in order and enter information from the Load customization variables worksheet.
Be sure to enclose your data set name in single quotes, then press Enter.
4. Return to customizing IBM WebSphere Portal and continue with the next step.
Preparing the z/OS operating system
The base z/OS environment and all of the subsystems associated with z/OS must be able to support
your IBM WebSphere Portal installation. This topic provides information on prerequisite products and
z/OS subsystem prerequisites with which you must comply before installation.
Complete the following steps to prepare the z/OS operating system:
1. Ensure that you comply with all hardware and software requirements.
Installing 1555
2. Ensure that your WebSphere Application Server instance is installed at the supported level and has
the following features installed:
Important: Besides ensuring that the existing WebSphere Application Server instance is at the
supported level, you will also need to ensure that Apache Derby is installed at the supported level
before installing WebSphere Portal. See WebSphere Portal detailed system requirements for supported
levels.
v Application Server
v Administration
Scripted Administration
WebSphere Integrated Solutions Console
v Ant and Deployment Tools
Deploy Tool
Ant Utilities
3. Ensure that all subsystems, such as Resource Recovery Services (RRS), are set up to your environment
requirements for the portal installation.
4. Comply with preinstallation security considerations; for example, verify your security setup on
WebSphere Application Server for z/OS. This can be performed either before or after the SMP/E
installation of the code.
5. Ensure Java Database Connectivity requirements are met.
For information, see DB2 Universal Database for OS/390 and z/OS: Application Programming Guide and
Reference for Java(TM). Also refer to the Redbooks publication DB2 for z/OS and OS/390: Ready for Java
SG24-6435-00.
6. If you plan on using DB2 for z/OS for a database transfer or as a database user registry or a property
extension (lookaside) database, change the Common Service Area (CSA) setting; see the appropriate
link for information about calculating and setting the CSA value to meet your business needs:
v DB2 for z/OS Version 9.1: Common service area storage requirements
v DB2 for z/OS Version 10: Common service area
Related tasks:
com.ibm.websphere.installation.zseries.doc/info/zseries/ae/tins_preparez.html
Obtaining an Installation Manager installation kit for installing the
product on z/OS
The installation kit for the IBM Installation Manager is provided with the IBM WebSphere Portal product
as FMID HGIN140. You can also download the IBM Installation Manager installation kit to your z/OS
system.
v To install the IBM Installation Manager installation kit with SMP/E:
If you ordered the WebSphere Portal product as part of a ServerPac or SystemPac, the IBM
Installation Manager installation kit will already be installed.
Mount the installation kit file system at /usr/lpp/InstallationManager/V1R5 or a location of your
choice.
If you ordered the WebSphere Portal product as part of a Custom-Built Product Delivery Offering
(CBPDO), the IBM Installation Manager installation kit will be included in the CBPDO as FMID
HGIN140. Install this product following the instructions in the Installation Manager program
directory.
Mount the installation kit file system at /usr/lpp/InstallationManager/V1R5 or a location of your
choice.
v To install the IBM Installation Manager installation kit from a downloaded compressed file:
See the IBM Installation Manager Information Center for download and extraction instructions.
Mount the resulting installation kit file system at /usr/lpp/InstallationManager/V1R5 or a location of
your choice.
The installation kit file system can be mounted read-only after it is installed with SMP/E or
downloaded and extracted. It is not modified during Installation Manager processing.
When the Installation Manager installation kit is available on your z/OS system, you can use it to create
an Installation Manager.
Creating an Installation Manager for installing the product on z/OS
You can create one or more Installation Managers on your z/OS system to install and maintain software
products.
Decide how you want to run the Installation Manager:
admin mode
In admin mode, the Installation Manager is installed from a superuser ID (uid=0) and can be
invoked from any superuser ID. There can only be one admin-mode Installation Manager on a
system.
user mode
In user mode (also called "nonAdmin mode"), the Installation Manager can be invoked only by
the user that installed it. There can only be one user-mode Installation Manager for a user.
group mode
In group mode, the Installation Manager can be invoked by any user ID that is connected to the
"owning group" for the Installation Manager (the default group of the user ID that creates it).
There is no limit to the number of group-mode Installation Managers that you can have on a
system.
The Installation Manager consists of two sets of files: a set of executable files that are copied or updated
from the installation kit and a set of runtime data files that describe the products installed by this
Installation Manager. Both sets of files must be writeable by the Installation Manager. You must select
locations for both the executable and runtime data for each Installation Manager.
Table 433. Default locations for Installation Manager files. The following table shows the default locations for the
Installation Manager executable files ("binary files") and runtime data on z/OS.
Files Admin or group mode User mode
Binary files /InstallationManager/bin $HOME/InstallationManager/bin
Runtime data (also called "agent data") /InstallationManager/appdata $HOME/InstallationManager/appdata
These locations are assumed in the Installation Manager documentation and sample jobs. If these names
are not appropriate for your system or if you choose to have several Installation Managers, you can
choose different names and specify them when you create the Installation Manager.
1. Create a user ID and group to own the Installation Manager.
This user ID must have the following attributes:
v Read/write home directory
v Read access to FACILITY profile BPX.FILEATTR.APF
v Read access to FACILITY profile BPX.FILEATTR.PROGCTL
v Read access to FACILITY profile BPX.FILEATTR.SHARELIB
v Read access to UNIXPRIV profile SUPERUSER.FILESYS.CHOWN
v Read access to UNIXPRIV profile SUPERUSER.FILESYS.CHANGEPERMS
Installing 1557
The user ID that creates the Installation Manager becomes the initial (possibly only) user ID that can
invoke that particular Installation Manager. If you create an Installation Manager in group mode, the
default group for this user becomes the "owning group" for the Installation Manager.
You can use an existing user ID if it meets these requirements.
If you installed the Installation Manager installation kit with SMP/E, you can use the Installation
Manager sample job GIN2ADMN in SGINJCL to create this user ID and group as well as to assign
appropriate permissions.
Tip: If you are creating a group-mode Installation Manager, consider putting the following line in a
.profile script in the home directory for each user ID that invokes the Installation Manager:
umask 002
This command ensures that all files created in the Installation Manager runtime data and installed
products are group writable. Otherwise, you might have to issue chmod 775 commands against these
directories whenever you use a different user ID to invoke the group-mode Installation Manager.
2. If the Installation Manager binary files and runtime data does not reside in existing read/write file
systems, create file systems for the data and mount the file systems read/write.
The file systems should be owned by the user ID and group that creates the Installation Manager and
have permissions 755 for an admin or user-mode Installation Manager or 775 for a group-mode
Installation Manager.
If you installed the Installation Manager installation kit with SMP/E, you can use the Installation
Manager sample job GIN2CFS in SGINJCL to allocate and mount a file system to hold the binary files
and runtime data.
The Installation Manager creation process creates the binary files and runtime data directories if they
do not already exist.
3. Log in to the UNIX system services shell using the user ID for the Installation Manager, and change
the directory to the location of the Installation Manager installation kit.
cd /usr/lpp/InstallationManager/V1R5
4. Run the installc, userinstc, or groupinstc command from the installation kit to create the
v To create an Installation Manager in admin mode, issue the following command from the shell:
installc -acceptLicense
-installationDirectory binaries_location
-dataLocation appdata_location
v To create an Installation Manager in user mode, issue the following command from the shell:
userinstc -acceptLicense
v To create an Installation Manager in group mode, issue the following command from the shell:
groupinstc -acceptLicense
You can omit the -installationDirectory and -dataLocation parameters if you use the default
locations.
If you used SMP/E to install the Installation Manager installation kit, you can use sample job
GIN2INST in SGINJCL to create an Installation Manager.
You can verify that the Installation Manager is correctly installed by logging in to the UNIX System
Services shell using the user ID that created the Installation Manager and running the Installation
Manager imcl command from the eclipse/tools subdirectory of the Installation Manager's binary files
location. For example:
cd /InstallationManager/bin/eclipse/tools
imcl -version
You are now ready to install products using IBM Installation Manager.
Authorizing additional users to a group-mode Installation Manager: To allow additional users to access
a group-mode Installation Manager, make sure that they meet the requirements listed in the first step of
the procedure and then connect them to the owning group for the Installation Manager using the TSO
CONNECT command:
CONNECT user2 GROUP(IMGROUP)
To create an additional Installation Manager, follow the steps in the procedure, selecting a new user ID
and group (if appropriate) and new binary files and runtime data locations. Do not share binary files or
runtime data locations between separate Installation Managers.
Correcting file ownership or permission problems: If you accidentally invoke an Installation Manager
from the wrong user ID, some files might end up with ownerships that prevent normal use of the
Installation Manager. To correct this problem, log on to a super user or other privileged user ID and reset
the file ownership and permissions for the Installation Manager binary files and runtime data. For
example:
chown IMADMIN:IMGROUP /InstallationManager/bin
chmod 775 /InstallationManager/bin
chown IMADMIN:IMGROUP /InstallationManager/appdata
chmod 775 /InstallationManager/appdata
If the users of a group-mode Installation Manager do not have umask set to allow group-write permission
on created files, you might also have to perform this step when switching from one user ID to another.
You might also need to set permissions and owners for the product files that you install with the
Installation Manager to ensure that maintenance can be performed from other user IDs in the group.
Upgrading the Installation Manager: To upgrade an Installation Manager to a new level of the
Installation Manager product, download or install the new level of the IBM Installation Manager
installation kit and mount it on your system. Then, change directory to the new level of the installation
kit and reissue the same installc, userinstc, or groupinstc command that you used to create the
Installation Manager. This action updates the Installation Manager's binary files from the new installation
kit.
Obtaining product repositories for installing the product on z/OS
IBM WebSphere Portal products are distributed as IBM Installation Manager repositories. These
repositories contain the metadata and files that are required to create one or more levels of a particular
product.
The initial repository for the WebSphere Portal product is installed using SMP/E. These SMP/E-installed
product repositories are updated through normal service to include additional WebSphere Portal fix packs
and feature packs as they become available. Fix packs, feature packs, and interim fixes can also be
downloaded directly with the IBM Installation Manager from a central IBM service website as needed.
Perform this procedure to obtain the repository for WebSphere Portal.
v If you ordered the WebSphere Portal product as part of a ServerPac or SystemPac
, the WebSphere
Portal product repository will already be installed.
Mount the repository at /usr/lpp/InstallationManagerRepository/HPTL800 or a location of your
choice.
v If you ordered the WebSphere Portal product as part of a Custom-Built Product Delivery Offering
(CBPDO), the IBM Installation Manager installation kit will be included in the CBPDO as FMID
HPTL800. Install this product following the instructions in the program directory.
Mount the repository at /usr/lpp/InstallationManagerRepository/HPTL800 or a location of your
choice.
This repository contains the necessary files to install the product code.
Installing 1559
When you use IBM Installation Manager to install WebSphere Portal, specify the path to the appropriate
repository in the -repositories parameter of the imcl command.
Installing WebSphere Portal on z/OS
Use the IBM Installation Manager to install the IBM WebSphere Portal product code.
Create an Installation Manager on your z/OS system. You must know the location of the binaries
directory for the Installation Manager. You must also have access to a user ID that can start the
Obtain the product repository for WebSphere Portal. These instructions assume that the repository is
mounted at /usr/lpp/InstallationManagerRepository/HPTL800. The mounted repository can be read-only.
The following sample jobs exist in the EJPJCL data set to perform the product installation and
uninstallation:
v EJP1CFS (zCreateFileSystem command)
v EJP1INST (imcl install command)
v EJP1UNIN (imcl uninstall command)
The sample jobs are shipped along with the WebSphere Portal repository as part of the product offering.
Complete the following steps to install WebSphere Portal on z/OS:
1. Ensure that the IBM WebSphere Application Server product file system is mounted as read/write.
WebSphere Portal must be able to write additional files into this file system location.
2. Customize and save the sample jobs for your environment according to the instructions in the jobs.
3. Run the EJP1CFS sample job in the SEJPJCL data set to allocate a zfs and mount it at a specific mount
point.
4. Run the EJP1INST sample job to run the Installation Manager installation command.
5. Product installation is complete when the EJP1INST sample job or Installation Manager commands
complete without error messages.
Logs for the installation can be found in the logs subdirectory of the Installation Manager runtime
data location.
6. When the installation is complete, change the WebSphere Portal product file system to read-only. This
step allows WebSphere Portal nodes and servers to use the file system.
You can now install other components or configure an application-serving environment using the
Customization Dialog.
Setting up a stand-alone production server on z/OS
stand-alone server deployment is also useful to determine and validate the needs of your deployment. It
enables you to examine and test the functions and features to decide how to accomplish business goals.
Related tasks:
Late breaking installation limitations and issues
WebSphere Portal Enable for zOS worksheets
Setting up a stand-alone server on z/OS
After you have prepared the operating system you are ready to install WebSphere Portal.
Select the operating system on which you are installing WebSphere Portal.
Configuring a base portal into a base node:
Perform this task during installation when you configure a base portal into a base application server
node. You also perform this task if installing a portal practice runtime. This option configures a base
portal into a base IBM WebSphere Application Server for z/OS node. This is supported with Apache
Derby as the underlying database, which can be later transferred to IBM DB2 Universal Database for
z/OS. It will give you a working base portal.
Before you begin ensure you have completed all of the previous steps in the installation.
The following prerequisites apply for installing WebSphere Portal in the base application server node:
v The requirements specified in the topic Preparing the z/OS operating system on page 1555 are
complied with, including the requirement that WebSphere Application Server for z/OS is installed.
v A base application server node is already set up.
v The WebSphere Portal code is already installed through SMP/E.
v The RACF settings are already verified.
Installing 1561
Before completing this task, you might want to view and print the appropriate worksheet that IBM
WebSphere Portal provides on the wiki to help you define your variables; see WebSphere Portal Enable
for zOS worksheets.
Perform these steps to configure a base portal into a base application server node.
1. Start the WebSphere Portal Customization Dialog.
2. In the Portal configuration panel, select Basic configuration tasks.
3. Select Configure base portal into a standalone WebSphere application server profile.
4. Select Define variables.
Reminder: Press F1 to display the help panel if you need assistance defining the variables.
5. Select the option for the variables you want to define and follow the panels to define the variables.
The following options are available:
v Review WebSphere variables (mandatory)
v System locations (directories, HLQs, etc)
v Server configuration
v Portal configuration
6. Generate the customization jobs.
7. Follow the Customization Dialog instructions for submitting the customization jobs.
Related tasks:
Stand-alone server: Verifying your RACF security settings:
Review the WebSphere configuration information to verify that all values on the Customization Panels
are correct, particularly the port values. You should also review the type of security that was specified
during the zPMT configuration.
Stand-alone server: Tuning your z/OS environment:
You must tune your environment before installing and customizing IBM WebSphere Portal to ensure
optimal performance between your z/OS and WebSphere Portal.
Complete the following steps to tune your z/OS environment:
1. Use the following URL to launch and log on to the WebSphere Integrated Solutions Console:
v Standalone environment: http://hostname:10041/ibm/console, where hostname is the fully
qualified host name for the IBM WebSphere Application Server.
v Clustered environment: http://dmgr_hostname:9060/ibm/console, where dmgr_hostname is the fully
qualified host name for the WebSphere Application Server Network Deployment
2. Increase the HTTP connection timeouts.
Note: See HTTP transport channel custom properties for additional information.
a. Click Servers > Server Types > WebSphere application servers > WebSphere_Portal > Container
settings > Web Container Settings > Web container transport chains.
b. Increase the timeout values. For the WCInboundAdmin and WCInboundAdminSecure entries
listed in the web container transport chains section, complete the following steps to increase the
timeout values:
1) Click HTTP Inbound Channel.
2) Change the Read timeout value to 0.
3) Change the Write timeout value to 0.
4) Save the configuration changes.
3. Restart the WebSphere_Portal server.
Stand-alone server: Enabling sample Web Content Manager content:
You can add the sample IBM Web Content Manager content into IBM WebSphere Portal. The job to add
sample content is included in the generated installation instructions.
Note: See Exploring the sample site templates for tutorials on how to use the sample content; a link to
the file is provided at the end of this document.
The following information is about the sample content:
v Creates a group called contentAuthors; members of this group are given privileges to create content in
the sample Internet and intranet sites. Navigate to the Administration area and then click Access >
Users and Groups.
Libraries.
v Adds a portlet filter and applies the filter to various portlets in the sample Internet and intranet sites.
You can see the definition of the filter in the WebSphere Integrated Solutions Console and examining
the custom resources under the Environment area.
Note: This information is valid only if you are using an old Portal theme for the sample sites.
v Creates several portlet clones of the Web Content Manager rendering portlet. These portlet clones are
used on sample Internet and intranet sites.
v Creates two virtual portals with context roots of wps/portal/intranet and wps/portal/internet. These
are the sample Internet and intranet sites. Go to http://yourserver:yourport/wps/portal/internet
and http://yourserver:yourport/wps/portal/intranet to access them.
v Modifies the portlet palette to include some new portlets. Click the Portlets link to see the portlet
palette.
Stand-alone server: Configuring databases:
Stand-alone server: Preparing DB2 for z/OS:
server.
Stand-alone server: Installing DB2 for z/OS:
Installing 1563
following commands:
following commands:
export EXTSHM=ON
db2start
profile.env file:
DB2ENVLIST=EXTSHM
export EXTSHM=ON
remote database.
Stand-alone server: Creating users on DB2 for z/OS:
installation.
(R) - at runtime
Installing 1565
where:
data.
Stand-alone server: Creating remote databases:
machine.
the databases.
500 DEFINE NO;
Related tasks:
Stand-alone server: Installing DB2 for z/OS on page 1563
Stand-alone server: Assigning custom table spaces:
Before you begin:
PADIX=NO, or both.
database transfer.
following values:
v release
v community
v customization
v jcr
Installing 1567
v feedback
v likeminds
Related tasks:
Stand-alone server: Creating users on DB2 for z/OS on page 1564
Stand-alone server: Configuring Portal to use DB2 for z/OS:
Transfer data from the Apache Derby database to the IBM DB2 Universal Database for z/OS database
that you have installed and set up.
Before transferring the data, ensure that you have met the following prerequisites:
v WebSphere Portal for z/OS is installed with supported database software, Apache Derby.
v IBM DB2 Universal Database for z/OS is installed.
v Make sure that your portal configuration is ready for database transfer. You should have completed the
Customization Dialog tasks for installing and preparing DB2 for z/OS for your deployment scenario:
A stand-alone production server
A federated, unclusered production server
Clustered, production servers
v If you are using a remote database server, make sure that you ran the jobs on the remote database
server or copied the *.CNTL and *.DATA data sets to the remote database server.
v Refer to the worksheets and definitions for the Transfer database task.
The worksheets for the first two panels of the Customization Dialog help you specify database driver
configuration properties. The worksheets for the subsequent panels of the Customization Dialog help
you specify the configuration properties of the WebSphere Portal database domains: Release,
Customization, Community, IBM Java Content Repository, Feedback, and LikeMinds. Refer to the
definitions of configuration properties that are provided in each worksheet.
Perform the following steps to transfer the database:
1. Perform the following steps to avoid a user prompt that causes the system to hang:
a. Open a UNIX System Services (USS) command prompt.
b. Change to the wp_profile_root/properties/ directory.
c. Open the sas.client.props file.
d. Update the following properties:
Table 434. sas.client.props file properties that need to be updated
Property New value
com.ibm.CORBA.loginSource properties
com.ibm.CORBA.loginUserid was_user_id
com.ibm.CORBA.loginPassword was_password
Note: If necessary, you can encode your plain text
passwords; see the "PropFilePasswordEncoder command
reference" link for information.
e. Save your changes.
3. In the Portal configuration panel, select Advanced configuration tasks.
4. Select Transfer database. Use the information that you prepared in the following worksheets to guide
your input when defining variables:
Database driver configuration
Database configuration
Remember: In the future, if you need to change your driver type, you will need to run the EJPSDBTV
job that is generated with the database transfer instructions. Regenerate these instructions using the
new drive type.
8. After you run the database transfer tasks, run the EJPSWCMR job to reset the web content event log.
9. To verify that WebSphere Portal is running, open the portal in a Web browser: http://
hostname.yourco.com:port_number/wps/portal, where hostname.yourcompany.com is the fully qualified
host name of the machine where WebSphere Portal is running and port_number is the transport port
that is created by WebSphere Application Server.
An error might occur if any of the following conditions exist:
v You receive a 503 error when trying to open WebSphere Portal.
v You have locale problems with your database or invalid characters such as ???? display after you
log in. This may happen if the character set of the database is not UTF-8 compliant.
v A problem with the data itself or the data transfer process prevents you from logging in.
WebSphere Portal indicates that you entered an invalid user ID and password even though you
know the credentials that you entered are valid.
v If the checkdata job does not run successfully or is skipped, WebSphere Portal initializes
successfully, but attempts to connect to the portal URL will fail.
Installing 1569
Related tasks:
Stand-alone server: Creating remote databases on page 1566
PropFilePasswordEncoder command reference
Stand-alone server: Verifying database connections:
To verify the connection from the Customization Dialog, submit the customization job EJPSDBTV. See job
EJPIDBT for more instructions.
Related tasks:
Stand-alone server: Creating remote databases on page 1566
Stand-alone server: Preparing a remote Web server when portal is installed on z/OS:
directive.
Installing 1571
feature:
f. Click OK.
Related reference:
Stand-alone server: Configuring Portal to use a user registry:
A user registry prevents unauthorized access to the server and protects your data.
information.
Select the operating system of the server where you have the user registry installed.
Related tasks:
Stand-alone server: Configuring databases on page 1563
Stand-alone server: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
Stand-alone server: Choosing your user registry model on z/OS:
Stand-alone server: Configuring a stand-alone LDAP user registry:
Installing 1573
Stand-alone server: Configuring a stand-alone LDAP user registry without SSL:
for zOS worksheets.
3. Select Security configuration tasks.
4. Select Enable portal security.
5. Select Configure Portal to use a standalone LDAP registry.
v Basic LDAP settings
v Portal user IDs
v Advanced LDAP settings
10. Required: After running all the customization jobs to configure a standalone LDAP user registry, you
must adapt the attribute configuration to match the configured LDAP server with your business
needs; see the "Adapting the attribute configuration" topic for information.
Related tasks:
Stand-alone server: Configuring a stand-alone LDAP user registry over SSL:
for zOS worksheets.
v Portal user IDs
needs; see Stand-alone server: Adapting the attribute configuration on page 1583 for information.
12. Run the Member Fixer task to update the member names used by Web Content Manager with the
corresponding members in the LDAP directory.
LDAP configuration.
ignore this line.
Installing 1575
Content Manager
Type of LDAP Value
Related tasks:
Stand-alone server: Configuring the default federated repository:
Stand-alone server: Configuring a federated LDAP user registry:
Stand-alone server: Adding an LDAP user registry without SSL:
for zOS worksheets.
5. Select Add a federated repository to the VMM configuration.
a. Specify the following option: Add a federated repository residing in an LDAP server.
10. After running all the customization jobs to configure a federated LDAP user registry, perform the
following tasks if appropriate to your business needs to complete the configuration of your LDAP
user registry:
Option Description
REQUIRED: Adapt attribute configurations to match
the configured LDAP server with your business needs
See the "Adapting the attribute configuration" topic for
information.
Support multiple realms Perform the following tasks to support multiple realms:
1. See Creating additional base entries on page 3208
for information.
2. See Stand-alone server: Adding realm support on
page 1582 for additional information.
Enable the full distinguished name login if the short
names are not unique for the realm
See Enabling the distinguished name login on page
3215 for information.
Update where new users and groups are stored Set this user registry as the default location where new
users and groups are stored, see Updating where new
users and groups are stored on page 3212 for
information.
Note: If you are adding multiple LDAP user registries or
a database user registry to your federated repository,
ensure that you select the appropriate LDAP or database
user registry where you want to store new users and
groups.
Remove the default file repository
Note: You should remove the default file repository in a
Perform the following tasks to remove the default file
repository:
1. Change the WebSphere Application Server user ID;
see Updating user ID and passwords on page 2552
for information.
2. Change the WebSphere Portal user ID; see Updating
user ID and passwords on page 2552 for
information.
3. Delete the file repository; see Deleting the repository
on z/OS on page 3216 for information.
Related tasks:
Stand-alone server: Adding an LDAP user registry over SSL:
Installing 1577
for zOS worksheets.
11. Required: Adapt attribute configurations to match the configured LDAP server with your business
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
13. Perform the following tasks if appropriate to your business needs to complete the configuration of
your LDAP user registry:
Option Description
for information.
information.
groups.
Installing 1579
Option Description
repository:
for information.
information.
Related tasks:
Stand-alone server: Adding a database user registry:
for zOS worksheets.
1. Complete the following steps to use the VMM database functions:
exist.
e. Enter the complete paths to the library files, separated by a colon (:) in the Value field; for
example, enter dbinstallpath/db2jcc4.jar:dbinstallpath/db2jcc_license_cisuz.jar, where
dbinstallpath is the DB2 jcc home directory.
Link the library files into the appserver/lib directory; for example, run the ln -s
dbinstallpath/classes/db2jcc4.jar db2jcc4.jar command. Then stop and restart the
WebSphere_Portal server to load the library files.
a. Specify the following option: Add a federated repository residing in a DB2 for z/OS database.
v Review Database driver configuration
v VMM database configuration
v Repository configuration
11. After running all the customization jobs to configure a database user registry, complete the following
task if appropriate to your business needs to complete the configuration of your database user
registry:
Option Description
Support multiple realms Complete the following tasks to support multiple realms:
for information.
Related tasks:
Stand-alone server: Adding a federated repository residing in the System Authorization Facility:
You can use your local operating system to create a read-only System Authorization Facility (SAF) user
registry that seamlessly maps RACF user IDs to your federated user registries for WebSphere cell
administration purposes. An SAF user registry authenticates using basic authentication, identity assertion,
or client certificates. It also stores information about users and groups, retrieves information about users
and groups to perform security-related administrative functions including mapping users and groups to
security roles, and controls access to resources such as datasets, commands, and ports.
for zOS worksheets.
Perform the following steps to add a federated repository residing in the System Authorization Facility
(SAF):
6. Select Add a federated repository residing in the Local Operating System.
Set Switch WebSphere Application Server Administrative User to Y to indicate that you changed the
administrative user ID and password to a user from the SAF.
Restriction: A user ID can only exist once in the entire federated repository.
Installing 1581
Stand-alone server: Adding realm support:
for zOS worksheets.
Note: To create multiple realms, you will need to perform these steps for each realm you want to add.
4. Select Advanced security tasks.
5. Select Manage realms.
6. Select Create a new realm.
10. After running all the customization jobs to add realm support, perform the following tasks if
appropriate to your business needs to complete the configuration of your realm support:
Option Description
Update default parents for a realm See Updating the default parents for a realm on page
Query the base entries for a specific realm See Querying the base entry on page 3210 for
information.
Add additional base entries See Creating additional base entries on page 3208 for
information.
Change the WebSphere Application Server and
WebSphere Portal administrator user ID
See Updating user ID and passwords on page 2552 for
information.
Set the realm your created as the default realm See Setting the default realm on page 3210 for
information.
name is not unique for the realm
Related tasks:
Stand-alone server: Adapting the attribute configuration:
the attribute configuration to match the configured LDAP server(s) and your business needs.
After installation, WebSphere Portal has a predefined set of attributes for users and groups. Your LDAP
server may have a different set of predefined user and group attributes. To ensure proper communication
between WebSphere Portal and your LDAP server, you can configure additional attributes and flag
existing attributes as required or unsupported on a per repository basis or for all configure repositories.
Therefore after installing WebSphere Portal and configuring your LDAP user registry, you will need to
manage the attributes between the two servers to ensure proper communication.
LDAP schema
Stand-alone server: Querying attributes:
for zOS worksheets.
Perform the following steps to query the defined attributes:
5. Select Miscellaneous tasks.
6. Select Manage attributes.
7. Select Query attributes.
Installing 1583
Related tasks:
Stand-alone server: Validating attributes:
After querying your LDAP for a list of attributes within your user registry, you must validate the
attributes defined within your user registry with the attributes defined within IBM WebSphere Portal.
for zOS worksheets.
Perform the following steps to validate the defined attributes:
7. Select Validate attributes.
Related tasks:
Stand-alone server: Adding attributes:
for zOS worksheets.
7. Select Add attributes.
Related tasks:
Stand-alone server: Mapping attributes:
for zOS worksheets.
7. Select Map attributes.
Related tasks:
Stand-alone server: Removing attributes:
Installing 1585
model directory.
directory.
or
database:
Stand-alone server: Configuring Portal to use dynamic groups on z/OS:
nodes.
v Name: memberurl
Stand-alone server: Enabling referrals for your LDAP user registry on z/OS:
Installing 1587
Setting up a federated unclustered production server
Set up a federated, unclustered production environment when you need a robust environment but do not
require a clustered production environment.
Perform the following tasks to set up a federated, unclustered production server:
Related tasks:
Federated, unclustered server: Preparing prerequisite and corequisite software
Before creating your high availability production environment, you must prepare your database, your
user registry, your deployment manager, and your remote Web server.
Complete the following tasks to prepare prerequisite and corequisite software:
Federated, unclustered server: Preparing the z/OS operating system:
levels.
v Administration
Deploy Tool
Ant Utilities
SG24-6435-00.
Federated, unclustered server: Setting up a network deployment cell:
This topic provides instructions and links for setting up a network deployment cell.
Perform the following steps to set up a network deployment cell:
1. Verify that the WebSphere Application Server for z/OS product level is correct and supported for this
release.
v All WebSphere Application Server for z/OS nodes must be at the same product revision level and
have the same corrective service levels applied.
v Ensure that you have applied any fix packs and interim fixes to WebSphere Application Server for
z/OS that are required for use with IBM WebSphere Portal.
2. Create the network deployment cell (DMCell) using the WebSphere Application Server for z/OS
customization dialog. This creates the network deployment cell, the deployment manager node, and
the deployment manager server in your WebSphere configuration.
3. When an additional node is added to a network deployment cell, it inherits the existing security
settings of the network deployment cell; therefore, the WebSphere Portal administrative users defined
for that node must exist in the network deployment cell's user registry. When using the WebSphere
Portal security configuration to update security settings on a WebSphere Portal server that is part of a
network deployment cell, you must realize that the updated security configuration will be used by the
Deployment Manager and by all other nodes in the cell.
4. Ensure the deployment manager is operating properly and is started.
Federated, unclustered server: Preparing the WebSphere Application Server Network Deployment:
Configure the Deployment Manager that is provided with WebSphere Application Server for z/OS and
then prepare the Deployment Manager for use with IBM WebSphere Portal.
Complete the following steps to prepare the WebSphere Application Server Deployment Manager:
1. Use the following URL to launch the deployment manager WebSphere Integrated Solutions Console:
http://dmgr_hostname:9060/ibm/console, where dmgr_hostname is the fully qualified host name for
the WebSphere Application Server Network Deployment.
3. Increase the HTTP connection time-outs for the deployment manager.
a. Click System Administration > Deployment Manager > Web container transport chains.
timeout values:
Installing 1589
4. Change the timeout request period for the Java Management Extensions (JMX) connector.
a. Click System administration > Deployment Manager > Administration Services > JMX
connectors > SOAPConnector > Custom Properties.
b. Select the requestTimeout property, and increase the value from 600 to 6000.
c. Save the configuration changes.
5. Update the maximum Java heap size used by the deployment manager:
a. Update the heap size in the following two locations:
v Click System administration > Deployment manager > Java and Process Management >
Process Definition > Control > Java Virtual Machine.
Process Definition > Servant > Java Virtual Machine.
b. Update the value in the Maximum Heap Size field. For information about appropriate heap sizes
see the documentation for your operating system and the Performance Guides located on the
WebSphere Portal and Web Content Manager Product Documentation page.
c. Click OK and then save your changes.
6. Click Security > Global security and select Enable Application Security. Then save the
configuration changes.
7. If creating a federated node, navigate to System administration > Deployment Manager > ORB
Services > z/OS additional settings and change the value of Workload manager timeout to 1200.
8. Verify that the WebSphere Portal administrative users and administrative group exist in the
Deployment Manager cell's user registry. Complete the following steps if you need to create the
administrative users and group:
a. Click Users and Groups > Manage Users.
b. Click Create.
c. Type the information for the WebSphere Portal administrative users; for example wpsadmin and
wpsbind, and then click Create.
d. Click Users and Groups > Manage Groups.
e. Click Create.
f. Type wpsadmins as the name of the WebSphere Portal administrative group and then click Create.
g. Click the group you just created; for example wpsadmins.
h. Click the Members tab.
i. Click Add Users.
j. Search for the users.
k. Select the users you want to add to the group.
l. Click Add to add the users to the group.
m. Click Close when you are done adding users to the group.
n. Log out of the WebSphere Integrated Solutions Console.
e. Click Apply.
10. Stop and restart the deployment manager; see Working with your new deployment manager for
additional information.
Federated, unclustered server: Installing WebSphere Portal
After you have prepared the operating system you are ready to install IBM WebSphere Portal on a
federated, standalone production environment.
Perform the following tasks to install WebSphere Portal on a federated, standalone production
environment:
Federated, unclustered server: Installing code through SMP/E:
This topic provides you with instructions for installing the IBM WebSphere Portal code using SMP/E.
Complete the following steps to install the code through SMP/E:
Restriction: z/OS does not support the Multiple Profile feature because each IBM WebSphere Application
Server instance has a single profile. However, it is possible to install multiple HFS product instances that
point to the same set of binaries in the SMP/e space. This effectively achieves the same result as having
multiple profiles. See the step about installing coexisting WebSphere Portal instances for information.
1. Ensure that you have completed all the necessary prerequisite steps for installing WebSphere Portal.
2. Make sure that the prerequisite products are installed, for example, IBM WebSphere Application
Server for z/OS, IBM DB2 Universal Database for z/OS, JAVA, and the LDAP server.
Note: In a clustered environment, you only have to install the database, JAVA, and LDAP server on
the primary node.
3. If you are installing from a driving system, make sure the maintenance level of the target system
meets the requirements for WebSphere Portal.
4. Follow the instructions in the Program Directory for IBM WebSphere Portal . You can find further
information on the Support Web site for WebSphere Portal at http://www.ibm.com/software/
genservers/portalzos/support/. Also, check the PSP bucket and, optionally, contact the IBM Software
Support Center.
5. Complete the following steps if you want to install coexisting instances of WebSphere Portal:
a. Install a WebSphere Application Server for z/OS cell. This can be either the cell of a stand-alone
base application server node or a network deployment cell. Make sure that the WebSphere
Application Server for z/OS home directory is separate from all other cells on the system and that
there are no port conflicts with other cells on the system. When installing WebSphere Application
Server for z/OS your data is uploaded from zPMT and this information should be saved for use
when installing WebSphere Portal.
b. Complete the following steps to verify that you can start and access the WebSphere Application
Server for z/OS administrative server:
1) Log on to the WebSphere Integrated Solutions Console. Use http://hostname:port/ibm/
console/ URL from a browser; where hostname is the node host name and port the HTTP port
of the administrative server you configured. For example, http://www.ibm.com:10041/ibm/
console/.
2) Figure out the port numbers for all your WebSphere Portal instances and specify the
information on the appropriate installation panel.
3) Install WebSphere Portal as if you were installing the only instance on the system.
4) Start the WebSphere Portal server.
Installing 1591
5) Access WebSphere Portal by requesting the http://hostname.yourco.com:port_number/wps/
portal URL from a browser; where hostname.yourco.com is the fully-qualified node host name of
the WebSphere Application Server for z/OS cell and port_number is the HTTP transport port of
your portal. For example, http://www.ibm.com:10041/wps/portal.
6. After installing WebSphere Portal, if you have a port conflict, see Changing ports for information.
Federated, unclustered server: Verifying your RACF security settings:
Federated, unclustered server: Enlarging the WebSphere Application Server configuration HFS:
Before starting the Portal configuration, you will need to verify that your IBM WebSphere Application
Server for z/OS configuration HFS has enough space. This is necessary because when Portal is
configured, the configuration data will be placed in the WebSphere Application Server for z/OS
configuration HFS data set. Depending on the type of deployment scenario you choose, you may need to
increase the HFS size to ensure there is enough space.
Perform the following steps to verify and, if required, enlarge the WebSphere Application Server for z/OS
configuration HFS prior to installing WebSphere Portal:
Important: If you plan to install into a network deployment cell, enlarge the deployment manager
configuration HFS.
1. Verify that the WebSphere Application Server for z/OS configuration HFS has at least a primary
allocation of at least 500 cylinders. Also consider defining secondary extents to allow for growth to
1200 - 1600 cylinders.
2. Verify the amount of free space in the HFS mounted as /tmp hfs. You might need to increase the
allotted free space. Consider allowing 500 - 600 cylinders of free space.
Federated, unclustered server: Configuring the primary node to communicate with
the deployment manager
After installing IBM WebSphere Application Server Network Deployment and installing IBM WebSphere
Portal on the primary node, you must configure the primary node and the deployment manager to
communicate with each other.
for zOS worksheets.
Complete the following steps to configure WebSphere Portal to communicate with the deployment
manager:
1. Optional: Complete the following steps if all of the following statements are true:
Portal is being installed into a managed node system
The deployment manager is on a different z/OS system than the system where the WebSphere
Portal product directory is located
The deployment manager system does not have access to the WebSphere Portal product directory
file system
a. Create a temporary directory on the deployment manager system.
b. Copy the following files from the WebSphere Portal product directory into a directory on the
deployment manager system:
filesForDmgr.pax
bin/ejpdmgr1.sh
c. When you complete the following steps to Configure Deployment Manager, input the directory
information local to the deployment manager system when prompted.
d. After generating the customized jobs, execute the EJPSCFGD job per the instructions in the
EJPINDM file on the z/OS system where the deployment manager is located.
3. Load the WebSphere Application Server variables for the Deployment Manager node.
5. Select Configure base portal into a federated WebSphere Application Server profile.
6. Select Configure Deployment Manager.
Related tasks:
Federated, unclustered server: Configuring a base portal into a primary node
You are asked to perform this task during installation to configure the primary node if installing in a
network deployment cell. This option configures a base portal into the primary node of a IBM WebSphere
Application Server for z/OS network deployment cell. This is supported with Apache Derby as the
underlying database, which must be later transferred to IBM DB2 Universal Database for z/OS. It will
give you a working base portal in the WebSphere Application Server for z/OS network deployment cell.
for zOS worksheets.
Perform the following steps to configure a base portal into the primary node:
1. Start the WebSphere Portal Customization Dialog using an APPL() parameter that is unique for the
primary node. For example, for the primary node in cell DM you might start the dialog using
APPL(DMNA). This ensures that ISPF variables relating to the primary node do not become
confused with those that apply to any secondary nodes.
5. Select Configure base portal into primary node.
Installing 1593
Collections.
deleted.
Related tasks:
Federated, unclustered server: Installing WebSphere Portal on page 1591
Federated, unclustered server: Tuning your z/OS environment
timeout values:
Related tasks:
Federated, unclustered server: Transferring data
Property New value
Installing 1595
new drive type.
Related tasks:
Federated, unclustered server: Preparing a remote Web server when portal is
installed on z/OS
directive.
feature:
f. Click OK.
Installing 1597
Related tasks:
Related reference:
Federated, unclustered server: Configuring WebSphere Portal to use a user
registry
information.
Related tasks:
Federated, unclustered server: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
Federated, unclustered server: Choosing your user registry model:
Federated, unclustered server: Configuring a stand-alone LDAP user registry:
Federated, unclustered server: Configuring a stand-alone LDAP user registry without SSL:
for zOS worksheets.
v Portal user IDs
Installing 1599
Related tasks:
Federated, unclustered server: Configuring a stand-alone LDAP user registry over SSL:
for zOS worksheets.
v Portal user IDs
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Related tasks:
Federated, unclustered server: Configuring the default federated repository:
Federated, unclustered server: Configuring a federated LDAP user registry:
Federated, unclustered server: Adding an LDAP user registry without SSL:
Installing 1601
for zOS worksheets.
user registry:
Option Description
information.
for information.
information.
groups.
Option Description
repository:
for information.
information.
Related tasks:
Federated, unclustered server: Adding an LDAP user registry over SSL:
for zOS worksheets.
Installing 1603
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Option Description
for information.
information.
groups.
repository:
for information.
information.
Related tasks:
Federated, unclustered server: Adding a database user registry:
for zOS worksheets.
exist.
Installing 1605
11. After running all the customization jobs to configure a database user registry, complete the following
registry:
Option Description
Support multiple realms Complete the following tasks to support multiple realms:
for information.
Related tasks:
Federated, unclustered server: Adding a federated repository residing in the System Authorization Facility in a
federated unclustered environment:
for zOS worksheets.
(SAF):
Set Switch WebSphere Application Server Administrative User to Y to indicate that you changed the
administrative user ID and password to a user from the SAF.
Federated, unclustered server: Adding realm support:
for zOS worksheets.
Installing 1607
Option Description
information.
information.
information.
information.
Related tasks:
Federated, unclustered server: Adapting the attribute configuration:
LDAP schema
Federated, unclustered server: Querying attributes:
for zOS worksheets.
Related tasks:
Federated, unclustered server: Validating attributes:
for zOS worksheets.
Related tasks:
Federated, unclustered server: Adding attributes:
Installing 1609
for zOS worksheets.
Related tasks:
Federated, unclustered server: Mapping attributes:
for zOS worksheets.
Related tasks:
Federated, unclustered server: Removing attributes:
model directory.
directory.
or
database:
Installing 1611
Federated, unclustered server: Configuring WebSphere Portal to use dynamic groups:
nodes.
v Name: memberurl
Federated, unclustered server: Enabling referrals for your LDAP user registry:
Federated, unclustered server: Tune your servers
should be used.
Installing 1613
Related tasks:
Setting up a clustered production environment on z/OS
When creating a cluster of IBM WebSphere Portal servers, you can start with a standalone production
server as your primary node or you can start with an existing IBM WebSphere Application Server
managed server node. After creating the cluster with either option as the starting point, you can begin to
add additional nodes to meet your business needs.
Choose one of the following options to set up your clustered production environment on z/OS:
Creating a cluster using a standalone production server
After configuring your standalone production server, you may find that your business needs have grown
and that a clustered production server will meet your company's growing demands. With a few
additional steps, you can cluster your standalone production server.
You must have a working standalone production server; see Setting up a stand-alone production server
Restriction: Dynamic clusters are not supported in a cluster using a stand-alone production server
(unmanaged server node). If you plan to create a dynamic cluster using IBM WebSphere Virtual
Enterprise, you must create a cluster using managed server nodes. See the related task link for
information.
CAUTION:
If you are using RACF, you should consider following the Creating a cluster using managed server
nodes on page 1635 path. The stand-alone production server path should work but there might be
residual RACF considerations afterwards.
Complete the following tasks to cluster your stand-alone production server:
z/OS clustered, stand-alone server: Preparing prerequisite and corequisite software on z/OS:
z/OS clustered, stand-alone server: Preparing the operating system:
levels.
v Administration
Deploy Tool
Ant Utilities
SG24-6435-00.
z/OS clustered, stand-alone server: Preparing a remote Web server when portal is installed on z/OS:
directive.
Installing 1615
feature:
f. Click OK.
Related reference:
z/OS clustered, stand-alone server: Setting up a network deployment cell:
release.
z/OS clustered, stand-alone server: Preparing the WebSphere Application Server Network Deployment:
timeout values:
Installing 1617
b. Click Create.
e. Click Create.
i. Click Add Users.
e. Click Apply.
z/OS clustered, stand-alone server: Configuring the primary node to communicate with the deployment manager:
for zOS worksheets.
manager:
file system
filesForDmgr.pax
bin/ejpdmgr1.sh
Related tasks:
Federating a standalone profile:
After you have decided to cluster your standalone production server and before you create your cluster,
you must federate the existing standalone profile.
Perform the following steps to federate your standalone profile:
3. Select Federate an existing standalone Portal profile into a Network Deployment cell.
v Deployment Manager variables
v Node agent port assignments
Installing 1619
z/OS clustered, stand-alone server: Creating a static cluster:
After the primary node is installed and running as a managed node under deployment manager control,
create the static cluster. You create a static cluster that uses the portal server in the primary node as a
template. Later, you clone a new portal server for the secondary node.
Complete the following steps to create a static cluster:
Note: Creating a static cluster in IBM WebSphere Application Server for z/OS needs to be done with
care, because cluster creation cannot be easily undone when a problem has occurred. Therefore, ensure
that you carefully follow the instructions. Furthermore, to simplify backing out of an erroneous cluster,
save the configuration repository of your deployment manager. Use the WebSphere Application Server for
z/OS shell script backupConfig.sh to save the configuration repository of your deployment manager
before cluster creation; see backupConfig command, and restoreConfig.sh to restore the configuration
repository of your deployment manager when cluster creation has failed; see restoreConfig command.
Both shell scripts are located in the WebSphere Application Server for z/OS home directory of the
deployment manager in subdirectory bin. After running the restoreConfig.sh task, you need to fully
synchronize the nodes. To do so, log in to the deployment manager WebSphere Integrated Solutions
Console. Go to System Administration > Nodes. Select all nodes, and click Full Resynchronize.
3. Select Advanced Cluster Scenarios.
4. Select Configure a WebSphere Portal static cluster.
8. Configure the cluster to use an external Web server.
By default, WebSphere Portal uses its own HTTP service for client requests. However, an external
Web server is required to take advantage of features such as workload management.
If you are using the recommended approach of installing and configuring the external Web server
after the creation of the cell, see Communicating with Web servers for information.
server:
Related tasks:
z/OS clustered, stand-alone server: Configuring Portal to use a user registry:
information.
z/OS clustered, stand-alone server: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
z/OS clustered, stand-alone server: Choosing your user registry model:
Installing 1621
z/OS clustered, stand-alone server: Configuring a stand-alone LDAP user registry:
z/OS clustered, stand-alone server: Configuring a stand-alone LDAP user registry without SSL:
for zOS worksheets.
v Portal user IDs
z/OS clustered, stand-alone server: Configuring a stand-alone LDAP user registry over SSL:
for zOS worksheets.
v Portal user IDs
LDAP configuration.
ignore this line.
Installing 1623
Content Manager
Type of LDAP Value
z/OS clustered, stand-alone server: Configuring the default federated repository:
z/OS clustered, stand-alone server: Configuring a federated LDAP user registry:
z/OS clustered, stand-alone server: Adding an LDAP user registry without SSL:
for zOS worksheets.
user registry:
Option Description
information
for information.
information.
groups.
repository:
for information.
information.
Installing 1625
z/OS clustered, stand-alone server: Adding an LDAP user registry over SSL:
for zOS worksheets.
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Option Description
for information.
Installing 1627
Option Description
information.
groups.
repository:
for information.
information.
z/OS clustered, stand-alone server: Adding a database user registry:
for zOS worksheets.
exist.
11. After running all the customization jobs to configure a database user registry, perform the following
registry:
Option Description
for information.
z/OS clustered, stand-alone server: Adding realm support:
for zOS worksheets.
Installing 1629
Option Description
information.
information.
information.
information.
z/OS clustered, stand-alone server: Adapting the attribute configuration:
LDAP schema
z/OS clustered, stand-alone server: Querying attributes:
for zOS worksheets.
Related tasks:
z/OS clustered, stand-alone server: Validating attributes:
for zOS worksheets.
Installing 1631
Related tasks:
z/OS clustered, stand-alone server: Adding attributes:
for zOS worksheets.
z/OS clustered, stand-alone server: Mapping attributes:
for zOS worksheets.
z/OS clustered, stand-alone server: Removing attributes:
model directory.
directory.
or
Installing 1633
database:
z/OS clustered, stand-alone server: Configuring Portal to use dynamic groups:
nodes.
v Name: memberurl
z/OS clustered, stand-alone server: Enabling referrals for your LDAP user registry:
Creating a cluster using managed server nodes
You can install and configure IBM WebSphere Portal into a IBM WebSphere Application Server for z/OS
managed server node in an existing Network Deployment cell instead of creating a standalone
WebSphere Portal production server. You can then proceed to create a cluster using the primary node and
adding additional nodes to the cluster now or in the future to meet your needs for a highly available
Perform the following tasks to create a cluster using managed server nodes:
z/OS clustered managed server node: Preparing prerequisite and corequisite software:
Installing 1635
z/OS clustered managed server node: Preparing the operating system:
levels.
v Administration
Deploy Tool
Ant Utilities
SG24-6435-00.
z/OS clustered managed server node: Preparing a remote Web server when portal is installed on z/OS:
directive.
feature:
f. Click OK.
server:
Installing 1637
Related reference:
z/OS clustered managed server node: Installing code through SMP/E:
the primary node.
Support Center.
console/.
z/OS clustered managed server node: Verifying your RACF security settings:
z/OS clustered managed server node: Enlarging the WebSphere Application Server configuration HFS:
Before starting the Portal configuration, you will need to verify that your IBM WebSphere Application
Server for z/OS configuration HFS has enough space. This is necessary because when Portal is
configured, the configuration data will be placed in the WebSphere Application Server for z/OS
configuration HFS data set. Depending on the type of deployment scenario you choose, you may need to
increase the HFS size to ensure there is enough space.
Perform the following steps to verify and, if required, enlarge the WebSphere Application Server for z/OS
configuration HFS prior to installing WebSphere Portal:
Important: If you plan to install into a network deployment cell, enlarge the deployment manager
configuration HFS.
1. Verify that the WebSphere Application Server for z/OS configuration HFS has at least a primary
allocation of at least 500 cylinders. Also consider defining secondary extents to allow for growth to
1200 - 1600 cylinders.
2. Verify the amount of free space in the HFS mounted as /tmp hfs. You might need to increase the
allotted free space. Consider allowing 500 - 600 cylinders of free space.
z/OS clustered managed server node: Setting up a network deployment cell:
release.
Installing 1639
z/OS clustered managed server node: Preparing the WebSphere Application Server Network Deployment:
timeout values:
b. Click Create.
e. Click Create.
i. Click Add Users.
e. Click Apply.
z/OS clustered managed server node: Preparing the primary node:
z/OS clustered managed server node: Overview of installing the primary node:
In this approach to clustering, IBM WebSphere Portal is first installed and then configured into an
existing IBM WebSphere Application Server for z/OS managed server node, which resides in the existing
network deployment cell.
Installing 1641
The cluster environment setup in the clustering topics is described according to the following topology:
v DMCell - the network deployment cell
v DM01 - the deployment manager node
v WP01 on NODEA - the first WebSphere Portal in the cell
v WP02 on NODEB - the second WebSphere Portal in the cell (horizontal scaling only)
You will install and configure each WebSphere Portal instance into a separate WebSphere Application
Server for z/OS managed server node. The managed server node is created in the network deployment
cell you created using the WebSphere Application Server for z/OS customization dialog. Once WebSphere
Portal has been installed and configured into an existing managed server node, you can proceed with
creating a new WebSphere Portal cluster or adding an additional member to an existing WebSphere
Portal cluster.
Note: The instructions in this topic can be used to set up a cluster in either a horizontal or vertical
scaling topology. If you are installing WebSphere Portal in a vertical cluster, you can disregard the
instructions for installing node NODEB and proceed to the creation of the cluster after completing the
installation of node NODEA. Where appropriate, differences between the steps required for horizontal
scaling and vertical scaling are noted.
z/OS clustered, managed server node: Configuring the primary node to communicate with the deployment
manager:
for zOS worksheets.
manager:
file system
filesForDmgr.pax
bin/ejpdmgr1.sh
Related tasks:
z/OS clustered, managed server node: Configuring a base portal into a primary node:
You are asked to perform this task during installation to configure the primary node if installing in a
network deployment cell. This option configures a base portal into the primary node of a IBM WebSphere
Application Server for z/OS network deployment cell. This is supported with Apache Derby as the
underlying database, which must be later transferred to IBM DB2 Universal Database for z/OS. It will
give you a working base portal in the WebSphere Application Server for z/OS network deployment cell.
for zOS worksheets.
Perform the following steps to configure a base portal into the primary node:
1. Start the WebSphere Portal Customization Dialog using an APPL() parameter that is unique for the
primary node. For example, for the primary node in cell DM you might start the dialog using
APPL(DMNA). This ensures that ISPF variables relating to the primary node do not become
confused with those that apply to any secondary nodes.
5. Select Configure base portal into primary node.
Installing 1643
Collections.
deleted.
Related tasks:
z/OS clustered managed server node: Tuning your environment:
timeout values:
z/OS clustered managed server node: Transferring data:
Property New value
new drive type.
Installing 1645
Related tasks:
Choosing the type of cluster to create on z/OS:
want to create:
Creating a static cluster:
After the primary node is installed and running as a managed node under deployment manager control,
create the static cluster. You create a static cluster that uses the portal server in the primary node as a
template. Later, you clone a new portal server for the secondary node.
Complete the following steps to create a static cluster:
Note: Creating a static cluster in IBM WebSphere Application Server for z/OS needs to be done with
care, because cluster creation cannot be easily undone when a problem has occurred. Therefore, ensure
that you carefully follow the instructions. Furthermore, to simplify backing out of an erroneous cluster,
save the configuration repository of your deployment manager. Use the WebSphere Application Server for
z/OS shell script backupConfig.sh to save the configuration repository of your deployment manager
before cluster creation; see backupConfig command, and restoreConfig.sh to restore the configuration
repository of your deployment manager when cluster creation has failed; see restoreConfig command.
Both shell scripts are located in the WebSphere Application Server for z/OS home directory of the
deployment manager in subdirectory bin. After running the restoreConfig.sh task, you need to fully
synchronize the nodes. To do so, log in to the deployment manager WebSphere Integrated Solutions
Console. Go to System Administration > Nodes. Select all nodes, and click Full Resynchronize.
8. Configure the cluster to use an external Web server.
By default, WebSphere Portal uses its own HTTP service for client requests. However, an external
Web server is required to take advantage of features such as workload management.
If you are using the recommended approach of installing and configuring the external Web server
after the creation of the cell, see Communicating with Web servers for information.
server:
Related tasks:
Creating a new WebSphere Extended Deployment dynamic cluster on z/OS:
Installing 1647
4. Select Configure a WebSphere Portal dynamic cluster.
v Database variables
v Stand-alone LDAP variables
v VMM database variables
b. Click New.
e. Click OK.
d. Click Add.
b. Click New.
primary node.
6) Click Append.
click Next.
i. Click the Create the cluster member using an existing server as a template radio button and
then select the WebSphere_Portal server for the primary node from the pull-down menu.
j. Click Next.
instances.
13. Return to the Customization Dialog instructions and complete the remaining jobs before returning to
this file and performing the remaining steps.
server:
Related tasks:
z/OS clustered managed server node: Configuring Portal to use a user registry:
Installing 1649
information.
Related tasks:
z/OS clustered managed server node: Preparing a SecureWay Security Server:
for information.
4) Click Add.
with a text editor:
your LDAP server.
z/OS clustered managed server node: Choosing your user registry model:
z/OS clustered managed server node: Configuring a stand-alone LDAP user registry:
z/OS clustered managed server node: Configuring a stand-alone LDAP user registry without SSL:
for zOS worksheets.
v Portal user IDs
Related tasks:
z/OS clustered managed server node: Configuring a stand-alone LDAP user registry over SSL:
for zOS worksheets.
Installing 1651
v Portal user IDs
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Related tasks:
z/OS clustered managed server node: Configuring the default federated repository:
z/OS clustered managed server node: Configuring a federated LDAP user registry:
z/OS clustered managed server node: Adding an LDAP user registry without SSL:
Installing 1653
for zOS worksheets.
user registry:
Option Description
information
for information.
information.
groups.
Option Description
repository:
for information.
information.
Related tasks:
z/OS clustered managed server node: Adding an LDAP user registry over SSL:
for zOS worksheets.
Installing 1655
LDAP configuration.
ignore this line.
Content Manager
Type of LDAP Value
Content Manager (continued)
Type of LDAP Value
Option Description
for information.
information.
groups.
repository:
for information.
information.
Related tasks:
z/OS clustered managed server node: Adding a database user registry:
Installing 1657
for zOS worksheets.
exist.
11. After running all the customization jobs to configure a database user registry, perform the following
registry:
Option Description
for information.
z/OS clustered managed server node: Adding a federated repository residing in the System Authorization Facility:
for zOS worksheets.
(SAF):
Set Switch WebSphere Application Server Administrative User to Y to change the administrative
user ID and password to a user from the SAF.
z/OS clustered managed server node: Adding realm support:
for zOS worksheets.
Installing 1659
Option Description
information.
information.
information.
information.
Related tasks:
z/OS clustered managed server node: Adapting the attribute configuration:
LDAP schema
z/OS clustered managed server node: Querying attributes:
for zOS worksheets.
Related tasks:
z/OS clustered managed server node: Validating attributes:
for zOS worksheets.
Installing 1661
Related tasks:
z/OS clustered managed server node: Adding attributes:
for zOS worksheets.
Related tasks:
z/OS clustered managed server node: Mapping attributes:
for zOS worksheets.
Related tasks:
z/OS clustered managed server node: Removing attributes:
Installing 1663
model directory.
directory.
or
database:
z/OS clustered managed server node: Configuring Portal to use dynamic groups:
nodes.
v Name: memberurl
z/OS clustered managed server node: Enabling referrals for your LDAP user registry:
Installing 1665
Preparing additional nodes on z/OS
After installing and configuring your primary node and creating the cluster, using either the standalone
server or a managed server node, you can create your secondary nodes. You must install IBM WebSphere
Portal on each node and then configure the node to access the database and user registry before adding it
to the cluster.
z/OS clustered, managed server node: Installing code through SMP/E:
the primary node.
Support Center.
console/.
Configuring a secondary node:
You are asked to perform this task during installation to configure the secondary node into a federated
IBM WebSphere Application Server profile or to federate an existing standalone IBM WebSphere Portal
profile into a Network Deployment cell. The database must be connected later to the database of the
primary node.
Ensure that you have configured your primary node.
for zOS worksheets.
Perform the following steps to configure the base portal into a secondary node:
Vertical cluster note: If you intend to create a WebSphere Portal cluster using a vertical scaling topology
on a single node, you can disregard the steps for installing a secondary node and proceed to Adding
vertical static cluster members on page 1670.
Tip: When choosing the long name for the portal server in a secondary node, use a name that does not
match your naming conventions. When you configure the portal into a secondary node, that portal server
can be considered temporary because a new portal server will be cloned into the new node when you
create a cluster later. Therefore, it is best to use a name for the secondary node that does not match your
naming conventions so that you will be able to choose the name that matches your naming conventions
when you create the cluster (or add an additional cluster member) later.
3. Choose one of the following options to configure a secondary node:
Option Description
Configure base portal into a federated WebSphere
Application Server profile
Perform the following steps to configure the base portal
into a federated WebSphere Application Server profile:
1. Select Configure base portal into a federated
WebSphere Application Server profile.
2. Select Configure base portal into secondary node.
4. Select the option for the variables you want to define
and follow the panels to define the variables. The
following options are available:
Installing 1667
Option Description
Federate an existing standalone Portal profile into a
Network Deployment Cell
Perform the following steps to federate an existing
standalone Portal profile into a Network Deployment
cell:
1. Select Federate an existing standalone Portal profile
into a Network Deployment Cell.
3. Select the option for the variables you want to define
and follow the panels to define the variables. The
following options are available:
4. Perform the following steps before running the jobs to configure the secondary node:
b. Go to Servers > Server Types > WebSphere application servers > server1.
c. Under the Server Infrastructure heading, select Administration > Custom properties >
ClusterTransitionName.
d. Set ClusterTransitionName to a unique name for the server1 instance; the default value is
BBOC001.
e. Click OK.
Related tasks:
Adding cluster members:
After you have created the cluster, you can add additional cluster members to perform workload
management and improve the availability of your applications. You can add horizontal cluster members
on different nodes or vertical cluster members on the same node. Use the information in this section to
add cluster members. Information is also provided for increasing the number of servant regions for your
portal server.
Choosing the type of additional node to create on z/OS:
Adding horizontal static cluster members:
If you have installed IBM WebSphere Portal on a secondary node, you can add the node as a horizontal
static cluster member to distribute a portion of the workload in the cluster to the secondary node.
for zOS worksheets.
Complete the following steps to add horizontal static cluster members:
8. Restart the Web server.
Important: If you are not using an external web server, you must update the virtual host entries for
the new port created when adding a cluster member. You can do this by updating the default_host
virtual host in the WebSphere Integrated Solutions Console and adding a new alias entry for the port
number (use an "*" wildcard character for the host name). For details, see Configuring virtual hosts.
9. Restart all nodes in the cluster.
Related tasks:
Adding an additional node to an existing dynamic cluster:
cluster:
4. Select Configure a WebSphere Portal dynamic cluster.
v Stand-alone LDAP variables
v VMM database variables
Installing 1669
d. Click Add.
11. Return to the Customization Dialog instructions and complete the remaining jobs before returning to
this file and performing the remaining steps.
server:
Choosing the type of vertical cluster to create on z/OS:
Adding vertical static cluster members:
Cluster members in a vertical scaling topology reside on the same node in the cell. Because WebSphere
Application Server for z/OS allows the increase of the number of servant regions per server, vertical
static clusters are redundant on IBM z/OS.
If you plan to use cache replication or Dynamic Replication Service (DRS), log on to the Deployment
Manager and navigate to Application servers > WebSphere_Portal > Process Definition > Servant >
Java Virtual Machine > Custom Properties and change the
com.ibm.ws.cache.CacheConfig.propogateInvalidationsNotShared parameter to false. Setting this
parameter to false will improve performance issues.
1. Open a browser and enter http://DM01:9060/ibm/console in the address bar to access the
deployment manager WebSphere Integrated Solutions Console, where DM01 is the deployment
manager node or host name. The port number might differ based on your installation.
members.
members.
f. Click OK.
setup task.
server:
Installing 1671
Resynchronize.
Solutions Console.
The recommended topology for vertical scaling is to increase the number of servant regions per server.
Adding vertical cluster members to a dynamic cluster on z/OS:
If you plan to use cache replication or Dynamic Replication Service (DRS), log on to the Deployment
Manager and navigate to Application servers > WebSphere_Portal > Process Definition > Servant >
Java Virtual Machine > Custom Properties and change the
com.ibm.ws.cache.CacheConfig.propogateInvalidationsNotShared parameter to false. Setting this
parameter to false will improve performance issues.
members.
f. Click OK.
setup task.
Resynchronize.
Increasing the number of servant regions:
On IBM z/OS, the recommended approach for increasing performance and throughput in a vertical
scaling topology is to increase the number of servant regions for your portal. This option is available
even in a base application server node.
Read Multiple servant regions for information about workload management and servant regions.
Complete the following steps to increase the number of servant regions:
1. Access the deployment manager WebSphere Integrated Solutions Console by opening a browser and
entering http://DM01:10040/admin in the address bar, where DM01 is the deployment manager node
or host name. The port number might differ based on your installation.
2. Go to Servers > Application Servers > WebSphere_Portal > Server Infrastructure > Java and Process
Management > Server Instance.
3. Check the Multiple Instances Enabled checkbox to allow multiple instances.
4. Set the Minimum number of Instances and Maximum number of Instances according to your
requirements.
5. Click OK and save your changes.
Installing 1673
Related tasks:
Multiple servant regions
Workload management (WLM) for z/OS
Configuring the HTTP session failover
Enable HTTP session failover in your cluster to enable multiple cluster members to serve data in the
event that one of them fails. Use the following information to configure your IBM WebSphere Portal for
HTTP session failover. This information includes instructions on configuring the HTTP server for the
sysplex distributor. If horizontal clustering is used in a sysplex, it is recommended to configure an
internal or external HTTP server with the WebSphere Application Server for z/OS plug-in and the
sysplex distributor. The sysplex distributor provides real load balancing and high availability within a
sysplex and defines a Dynamic Virtual IP Address (DVIPA). DVIPA is also called a cluster address. The
DVIPA distributes TCP/IP requests within a sysplex depending on the workload.
Note: Ensure that the sysplex distributor and the internal or external HTTP server set up work properly
before any kind of WebSphere Application Server for z/OS session persistence, such as distributed
session support, is enabled. Otherwise, the HTTP response performance could be adversely affected.
Verify that WebSphere Portal is operational.
It is necessary to configure an HTTP server with the WebSphere Application Server for z/OS plug-in if
the sysplex distributor is used because the latter does not manage session affinity. Therefore, the plug-in
checks the HTTP request header and reroutes the HTTP request by avoiding the sysplex distributor if the
HTTP request header contains session affinity data. Only a request without any session data is routed to
the sysplex distributor, which distributes the request to the Web container of one of the portal cluster
members.
WebSphere Application Server for z/OS provides the functionality to generate a plugin-cfg.xml file that
is used by the internal or external HTTP server. However, this means the plug-in file controls the
distribution of HTTP requests to the Web containers within the cluster by the "round-robin" method that
makes the sysplex distributor inadequate. The plugin-cfg.xml needs to be manually changed to prevent
this.
In a clustered environment, all requests for a particular session are directed to the same server instance in
the cluster. In other words, after a user establishes a session with a portal (for example, by logging in to
the portal), the user is served by the same server instance for the duration of the session.
To verify which server is handling user requests for a session, you can view the global settings portlet in
WebSphere Portal, which displays the node name of the server handling requests.
If one of the servers in the cluster fails, the request is rerouted to another server in the cluster. If
distributed sessions support is enabled (either by persistent sessions or memory-to-memory session
replication), the new server can access session data from the database or another server instance.
Distributed session support is not enabled by default and must be configured separately in IBM
WebSphere Application Server for z/OS. Refer to Distributed sessions for information.
Note: If you use the IBM DB2 Universal Database for z/OS JDBC type 2 driver you must set the JDBC
driver custom property fullyMaterializeLobData to false. For information on data sources, see Data
sources.
By default, failover support is available for WebSphere Portal and any portlets that are installed with the
product. To take advantage of failover support with your own developed portlets, you must ensure that
your portlets are implemented according to best practices.
Data that is stored within the JVM memory and not managed by the application server or the WebSphere
Portal server for replication might be lost in the case of failover. Even with the distributed session
support, during a failure, users will not be able to recover any uncommitted information that is not
stored in sessions or other replicated data areas (such as a distributed Map or render parameters).
In such cases, users might have to restart a transaction after a failover occurs. For example, if you are in
the process of working with a portlet and have navigated between several different screens when a
failover occurs, you might be placed back at the initial screen, where you would need to repeat your
previous steps. Similarly, if you are attempting to deploy a portlet when a failover occurs, the
deployment might not be successful, in which case you must redeploy the portlet. However, with
distributed session support enabled, the validity of user log in sessions is maintained despite node
failures.
In cases where a portlet does not support failover, a "Portlet Unavailable" message is displayed for the
portlet after a failover occurs. If a portlet supports partial or incomplete failover, some data displayed by
the portlet before the failover could disappear after the failover occurs, or the portlet might not work as
expected. In such extreme cases, the user should log out and log back in to resume normal operation.
After a failover occurs, the request is redirected to another cluster member by the Web server plug-in.
Most browsers will issue a GET request as a response to a redirect after submitting a POST request. This
ensures that the browser does not send the same data multiple times without the user's knowledge.
However, this means that after failover, users might have to refresh the page in the browser or go back
and resubmit the form to recover the POST data.
Perform the following steps to configure the HTTP server for the sysplex distributor:
1. Copy the generated plugin-cfg.xml file to a directory where the WebSphere Application Server for
z/OS plug-in configuration task cannot changed it.
2. Search in the file for the <ServerCluster... statement, which contains the string Name="#your Portal
cluster name#".
3. Remove the LoadBalance="Round Robin" string.
4. Insert the following lines immediately under the <ServerCluster... statement:
<ClusterAddress Name="ClusterAddr">
<Transport Hostname="#your DVIPA/cluster address#"
Port="#your Portal webcontainer port#" Protocol="http"/>
</ClusterAddress>
Tip: You can enter any value that is appropriate for your business for ClusterAddress Name.
Transport Hostname should be the Dynamic Virtual IP Address (DVIPA) of the Sysplex Distributor.
Port is the port used for HTTP traffic at the Sysplex Distributor DVIPA.
5. Search for all <Server CloneID=... statements, which belongs to the cluster, and remove the string
LoadBalanceWeight="2".
For additional information about configuring the HTTP session failover, see Setting up a highly available
sysplex environment
Configuring search in a cluster on z/OS
Configuring Portal Search in a cluster on z/OS:
Portal cluster.
Installing 1675
accordingly.
Notes:
Related concepts:
Portal Search.
Related tasks:
Configuring JCR search in a cluster on z/OS:
directory.
search
portlet:
e. Click OK.
deleted.
for information.
Installing 1677
Setting up multiple clusters on z/OS
When configuring multiple clusters, you must plan for this configuration in advance. In a single cluster
deployment, you create the primary server and secondary, or additional, nodes. In a multiple cluster
deployment, you create the primary (or first) cluster and then you create secondary (or subsequent)
clusters. First you install the primary server to create the first cluster in the cell. All multiple clusters are
installed into a managed node.
There are two parameters that you must ensure are properly set to have a successful multiple cluster
deployment. The first parameter is Multiple cluster configuration, which should be set to Y if you plan
to configure multiple clusters. The second parameter is Node is the first cluster, which should be set
to Y on the primary (or first) cluster and set to N on the secondary (or subsequent) clusters.
Perform the following tasks to set up multiple clusters:
Installing multiple clusters in a single cell on z/OS:
1. Perform the following steps to create the first cluster in the cell:
a. Start the WebSphere Portal Customization Dialog.
b. In the Portal configuration panel, select Basic configuration tasks.
c. Select Configure base portal into a federated WebSphere Application Server profile.
d. Select Configure base portal into primary node.
e. Select Define variables.
Remember: On the Server configuration panel, set Multiple cluster configuration and Node is
in the first cluster to Y.
f. Generate the customization jobs.
g. Follow the Customization Dialog instructions for submitting the customization jobs.
h. After running all required jobs to install the primary server, set up your database, change your
driver type, if necessary, and transfer your data. See Related tasks for links to the appropriate
information.
i. After running all required jobs to transfer your database, configure your security. See Configuring
WebSphere Portal to use a user registry in a cluster.
j. After running all required jobs to configure your security, perform the following steps to create a
new cluster in a Network Deployment cell:
1) Start the WebSphere Portal Customization Dialog.
2) In the Portal configuration panel, select Advanced configuration tasks.
3) Select Advanced Cluster Scenarios.
4) Select one of the following options depending on the type of cluster you are creating:
v Configure a WebSphere Portal static cluster
v Configure a WebSphere Portal dynamic cluster
5) Select Define variables.
6) Select the option for the variables you want to define and follow the panels to define the
variables. The following options are available:
v Deployment manager variables
v Stand-alone LDAP variables (conditionally)
v VMM database variables (conditionally)
7) Generate the customization jobs.
8) Follow the Customization Dialog instructions for submitting the customization jobs.
k. Validate the cluster.
2. If you are adding a dynamic cluster and IBM WebSphere Virtual Enterprise is not already installed on
Portal B, install it, apply all required ifixes, and augment the wp_profile profile to make it compatible
with WebSphere Extended Deployment Operations Optimization. See the "Planning the product
installation" link in Related section for information about installing WebSphere Virtual Enterprise.
Profile augmentation is completed using the Profile Management Tool (PMT) graphical interface on
systems that support it or through the manageprofiles command that is available on all systems.
When using the graphical interface, make sure you select Operations Optimization when choosing
the type of augmentation to complete. When using the manageprofiles command, be sure to follow
the instructions to augment a stand-alone application server profile.
3. Perform the following steps to create the next cluster in the cell:
Note: Repeat this step until all required clusters are created in the cell.
d. Select Configure base portal into primary node.
Remember: On the Server configuration panel, set Multiple cluster configuration to Y and set
Node is in the first cluster to N.
h. After running all required jobs to install the primary server, set up your database, change your
driver type, if necessary, and transfer your data. See Related tasks for links to the appropriate
information.
Installing 1679
i. After running all required jobs to transfer your database, perform the following steps create a new
cluster in the Network Deployment cell:
j. Validate the cluster.
4. Perform the following steps to configure additional cluster nodes for the first and subsequent clusters:
Note: Repeat this step until all additional nodes are configured for the required clusters in the cell.
Restriction: If your primary node is a static cluster, you must choose the static option for your
additional cluster nodes. If your primary node is a dynamic cluster, you must choose the dynamic
option for your additional cluster nodes.
d. Select Configure base portal into secondary node.
Remember: On the Server configuration panel, set Multiple cluster configuration to Y.
h. Perform the following steps to add the additional node into the appropriate existing cluster:
Enterprise on the additional node and augment the Portal profile with WebSphere Virtual
Enterprise.
i. Validate the cluster.
The multiple cluster configuration is now complete. Each cluster is independent from the other clusters,
which means that each cluster can have its own configuration, set of end-user portlets, and target
community. Applications that are common between the clusters are most likely infrastructure or related to
administration and special care needs to be taken to preserve their commonality.
Related tasks:
z/OS clustered managed server node: Transferring data on page 1644
z/OS clustered managed server node: Configuring Portal to use a user registry on page 1649
Routing requests across clusters on z/OS:
of user requests.
Installing 1681
cluster.
Related concepts:
Related reference:
Clustered server: Tune your servers on z/OS
should be used.
Configuring databases
Use the WebSphere Portal Customization Dialog to create, configure, and transfer databases. You can
optionally configure database domains to share across separate portal instances and configure separate
portal instances to use the same database subsystem.
Related tasks:
DB2 for z/OS
Sharing database domains between separate portal instances
Domains are the database or schema objects that can be managed separately and shared between
different portal instances. The domains provided by WebSphere Portal for z/OS are Release, Community,
Customization, IBM Java Content Repository (JCR), Feedback, and LikeMinds. Data that is managed by
domains can be shared across multiple instances of WebSphere Portal, for example, instance1 and
instance2, where instance2 is connected to the database domains of instance1. A WebSphere Portal instance
can be either a single server or WebSphere Portal cluster.
To maximize the availability of WebSphere Portal data that can be distributed across multiple databases
and shared between multiple lines of production, determine how you want to distribute the following
categories of data into different databases.
Community data
Is typically modified during production, for example, shared documents or application resources.
Usually, administrators are allowed to modify or delete shared resources. Community data is
protected by access control.
Configuration data
Is system properties of the WebSphere Portal server, for example, database connection, object
factories, and deployment descriptors. This type of data is stored in the file system and is
typically constant over the uptime of a server node.
Customization data
Is associated with a particular user and cannot be shared among users and user groups, for
example, portlet data and implicitly derived pages. Customization data is protected by access
control.
Release data
Is typically not modified during production, for example, administrator-defined pages, portlets,
and portlet instances. Usually, administrators create release data on an integration server and
stage it to the production system. Release data can be protected by access control.
Restriction:
v Release and JCR data cannot be shared between separate WebSphere Portal instances.
v When two portal instances share data, they must be installed into the same IBM DB2 Universal
Database for z/OS subsystem. That is, when you run the database transfer task, the database driver
configuration in the Customization Dialog must be the same for both portal instances.
Note: For maintenance purposes, the following database domains can be taken offline:
v Community
v Customization
Installing 1683
v Feedback
v LikeMinds
The following databases must not be taken offline at anytime when WebSphere Portal is started:
v Release
v JCR
While a database domain is offline, WebSphere Portal cannot access the corresponding data and thus
error messages may be displayed. WebSphere Portal itself remains responsive. When a database domain
becomes available again, WebSphere Portal will detect this availability, reconnect, and continue working
with the corresponding data. When WebSphere Portal is being started all database domains must be
accessible.
Sharing of VMM databases: The VMM databases for a full repository and for the property extension can
be shared between lines of production. If the VMM databases are out of service, WebSphere Portal will
not function.
To share database domains when setting up an environment with multiple instances of WebSphere Portal
for z/OS, follow these steps:
1. Set up the first portal instance, instance1. When installing the first portal instance, follow the
instructions in Configuring a base portal into a base node on page 1561 or Setting up a clustered
production environment on z/OS on page 1614, depending on whether instance1 is a stand-alone
portal in a base application server node or a portal cluster in a network deployment cell.
2. Determine which database domains you want to share with any other portal instances in the
environment.
The following table lists the supported database domains, whether a domain is sharable, and its
storage method.
Table 451. List of supported database domains and whether they are sharable and the storage method for each
domain
Release no database
Customization yes database
Community yes database
JCR no database
Feedback yes database
LikeMinds yes database
3. Install the second portal instance, instance2. Follow the instructions in Configuring a base portal into
a base node on page 1561 or Setting up a clustered production environment on z/OS on page
1614, depending on whether instance2 is a stand-alone portal in a base application server node or a
portal cluster in a network deployment cell. Ensure that the portal home directory is separate from all
other cells on the system and that there are no port conflicts with other cells on the system. For
details, see Configuring a base portal into a base node on page 1561.
4. The steps for configuring instance2 to use the shared database domains are the same as the steps for
installing instance1, with one important exception. When performing database transfer for instance2,
specify that you want to connect to the domains of instance1 for the shared domains in the
Customization Dialog of WebSphere Portal for z/OS. For each domain you want to share, follow these
steps:
a. Set the field Connect to existing domain to Y in the Customization Dialog panels of WebSphere
Portal for z/OS.
b. Enter the same database configuration values for the domain that you entered for the domain for
instance1.
5. For additional portal instances, use the same procedure that you used for installing instance2.
Related tasks:
DB2 for z/OS
Configuring two portal instances using the same database subsystem
You can install two separate instances of IBM WebSphere Portal, portal_instance1 and portal_instance2, into
the same IBM DB2 Universal Database for z/OS subsystem.
Understand how to share database domains between separate portal instances.
A WebSphere Portal for z/OS instance can be either a single server or a WebSphere Portal for z/OS
cluster. The portal instances can be completely separate or can share database domains.
v For shared domains, use the same schema name and the same database configuration values for
portal_instance1 and portal_instance2.
v For separate domains, use different schema names.
v WebSphere Virtual Member Manager (VMM) must be configured separately because it is no longer
part of the WebSphere Portal database. However, there are database domains related to WebSphere
Virtual Member Manager (VMM) for database user registry and property extension. WebSphere Virtual
Member Manager (VMM) does not support different schema names; therefore, the second instance
must point to a different VMM database.
Supporting multiple profiles
When installing IBM WebSphere Portal, a default configuration profile is created (wp_profile). You can
now create and maintain multiple profiles to create multiple independent portal instances, create new
profiles and delete the old to recover from configuration problems, create custom profiles to easily
expand your cluster's capacity, or update a Deployment Manager profile to handle portal servers without
manual preparation steps. To support multiple profiles you must first prepare your system, create or
augment profiles, run configuration tasks on the profiles, and then maintain the profiles if you install
maintenance packages. You may also need to update the configuration archive or delete a profile that is
no longer required.
Before creating new profiles, you must delete any existing search collections.
Choose the appropriate operating system to create and maintain multiple profiles:
Tip: Release data cannot be shared between multiple profiles. Each profile must have its own database
for Release.
Restriction: This feature does not apply to Express editions or Enable edition when installed on z/OS.
Installing 1685
Related concepts:
Creating and maintaining multiple profiles on AIX
Complete the following tasks to create and maintain additional WebSphere Portal profiles:
Related concepts:
Related tasks:
Installing WebSphere Portal on AIX for the horizontal cluster nodes on page 429
authentication.
Preparing the system for multiple profile support on AIX
WebSphere Application Server uses the wsadmin scripting interface to support the CAR creation.
WebSphere Portal provides a configuration task that creates the CAR and also captures additional
portal-specific files that must be kept with the CAR. The task also places the CAR and any associated
files in the correct directory.
Many portal customizations, such as new pages, blogs, and wikis, are stored in the WebSphere Portal
release database, which uses the Derby database after the initial installation. Any customizations made to
the Derby database prior to running the enable-profiles task are included in the additional profiles
created later. However, if you complete a database transfer to set up the release database on an external
server before running the enable-profiles task, then any customizations made between the transfer and
when the enable-profiles task is run are NOT picked up by additional profiles. Therefore, you should
complete all customizations that you want included on the additional profiles before transferring your
release database domain to an external database server.
Restriction: Your environment MUST be a stand-alone profile. If you have a node federated to a
Deployment Manager, you must remove the node from the cell. If you have a web server node, you must
remove the node before running enable-profiles.
Restriction: Search Collections cannot be shared between multiple profiles. Before running
enable-profiles, remove existing search collections from the default profile. You can re-create the search
collections after you run enable-profiles.
Complete the following steps to prepare the system for multiple profile support:
wp_profile_root/ConfigEngine directory of the configuration profile whose configuration will form the
basis for the portal profile template, to create the CAR. The Portal.car file is saved to the
PortalServer_root/profileTemplates/default.portal/configArchives directory.
Server directory.
After completing the initial profile template generation with your required configuration, you should
only make further customization changes to the wp_profile directory that are intended to be included in
all additional Portal profiles. This approach allows the portal profile template configuration to be
immediately updated after applying maintenance, because it will already contain the required
configuration to be saved with the Portal profile templates.
Related tasks:
Creating or augmenting profiles on AIX
You can create new profiles or augment existing IBM WebSphere Application Server default profiles or
Deployment Manager profiles with IBM WebSphere Portal. You can use the Profile Management Tool
(PMT), if supported, to enter all required parameters on a graphical user interface (GUI). The PMT is the
preferred method for beginners because it uses automatically created default values. You can also use the
manageProfiles command to enter all required parameters on a command line. This method allows you
Installing 1687
to automate the process. If you have an existing WebSphere Application Server default profile, you must
use the manageProfiles command. The PMT interface is not supported for augmentation in this scenario.
Creating or augmenting a profile requires a profile template, which is used to execute the required
actions. The templates can be found in the PortalServer_root/profileTemplates directory. Choose the
appropriate file to create or augment your profile:
Creating a Portal application server profile on AIX:
The IBM WebSphere Portal installation registers the WebSphere Portal application server profile template
with IBM WebSphere Application Server. You can then create new profiles based on the template. You can
use the manageprofiles command. You can also use the Profile Management Tool, which is a graphical
user interface. The newly created profile's WebSphere Application Server administrator ID and password
are set according to the input given. The portal still has the same security and database configurations,
including the portal administrator ID and password, as the initial profile used to run the enable-profiles
task. If your initial profile was using the Derby database, a fresh copy is automatically created with the
new profile. If your initial profile was configured to use a non-Derby database, then all the database
domains of the new profile are identically configured. Likewise, any security configurations (like a
stand-alone or federated LDAP) that were made before running the enable-profiles task are preserved
with the new profile.
Complete the following steps to create a profile:
1. Choose one of the following methods to create a profile:
Table 452. Choose between the Profile Management Tool and the manageprofiles task to create a portal profile.
Option Steps
4. On the Environment Selection panel, expand WebSphere Portal Server 8.0.0 and select WebSphere Portal
Server, and then click Next.
Note: You can choose to select the Create the server using the development template check box to enable
developer mode for this profile. You can choose to select the Make this profile the default check box to
specify that this profile is the default profile in the system.
6. On the Node, Host, and Cell Names panel, provide the node name and TCP/IP host name for the new
management cell (under Deployment Manager control). The host name must be valid and reachable over the
network. Click Next to continue.
7. On the Administrative Security panel, make sure that the Enable administrative security checkbox is
unchecked. The new profile is then created using the same security settings that are saved in the Portal
profile template. After the new Portal profile is created, the security configuration of the new profile can then
be modified as required. Click Next to continue.
8. On the Service Definition panel, specify whether the WebSphere Portal server in this profile is to be registered
and controlled as a service. Click Next to continue.
Create to create the profile based on the supplied information.
Note: The port values presented in the summary value is overwritten by the port values used by the servers
present in the configuration archive provided as part of the portal profile template. These port values will
must be adjusted after profile creation if they are in conflict with other ports on the local system.
Important: The creation summary shows a "server name" value of null. You can ignore this summary since
the application server name was not requested on previous panels and always defaults to WebSphere_Portal.
Table 452. Choose between the Profile Management Tool and the manageprofiles task to create a portal
profile. (continued)
Option Steps
/usr/IBM/WebSphere/PortalServer/profileTemplates/default.portal
-profileName testPortal1
-profilePath /usr/IBM/WebSphere/testportal1
-cellName testCell
-nodeName testNode
message.
In this example, the portal profile template is installed under the /usr/IBM/WebSphere/PortalServer/
profileTemplates/default.portal directory. The new profile is testportal1 and is located under the
/usr/IBM/WebSphere/testportal1 directory.
You can also use the following parameters:
-isDefault: signifies that this profile is to serve as the default profile for the installation
-isDeveloperServer: indicates that WebSphere Portal is to be configured for development mode in this profile.
-nodeName: provides a node name for the new profile; if not provided, the node name defaults to a value based
on the local host name. This parameter is required if federating this profile into a managed cell because this
value must be unique from other nodes in the cell.
See manageprofiles command for a complete list of parameters.
2. Because all database domains are identically configured for each profile, you must modify the
database configuration for database domains that cannot be shared or that you do not want to share.
Creating a Portal custom profile on AIX:
Complete the following steps to create a profile that is used as an additional node:
Choose one of the following methods to create a profile that is used for additional cluster members:
Installing 1689
Option Steps
click Next.
CAUTION:
node.
-cellName testCell
-nodeName testNode
message.
Related tasks:
Augmenting a stand-alone default profile with WebSphere Portal on AIX:
You can augment an existing IBM WebSphere Application Server default profile running in a stand-alone
(non-federated) environment with IBM WebSphere Portal. The augmentation adds the WebSphere Portal
configurations, applications, and application server that were saved from the baseline WebSphere Portal
configuration.
Note: Augmenting profiles that contain specialized application server instances installed by other
products with WebSphere Portal could potentially introduce some configuration conflict. You should
contact IBM before proceeding in such an environment to determine if any support limitations exist.
A valid IBM WebSphere Application Server default profile must exist.
The WebSphere Portal installation registers the WebSphere Portal default profile augmentation template
with WebSphere Application Server. You can then augment existing default profiles with WebSphere
Portal based on this template. You must use the manageprofiles command to complete this profile
augmentation. The portal still has the same database configuration, including the portal Administrator ID
and password as the initial profile used to run the enable-profiles or replace-profiles tasks. If your
initial profile was using the Derby database, a fresh copy is automatically created with the new profile. If
your initial profile was configured to use a non-Derby database, then all the database domains of the new
profile are identically configured. Profile augmentation does not modify the security settings that are
configured for the existing profile.
click OK.
stored.
e. Select Apply.
f. Select OK.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
c. Click Next.
directory path.
path.
3) Click Next.
Installing 1691
Next.
b. Extract the profileTemplates.zip file in the same location. If any of the templates already exist in
your profileTemplates directory, overwrite them.
c. Run the chmod -R 755 PortalServer_root/profileTemplates task to change the permissions of the
files and directories, located in the PortalServer_root/profileTemplates directory, because some files
are set to read-only after the copy operation.
4. Complete the following steps to create a profile:
Table 454. Running the manageprofiles task to create a profile.
Option Steps
/usr/IBM/WebSphere/PortalServer/profileTemplates/default.portal.augment
-profileName AppSrv01
-cellName testCell
-nodeName testNode
-hostName myHost.xxx.com
message.
In this example, the portal profile template is installed under the /usr/IBM/WebSphere/PortalServer/
profileTemplates directory. The existing default profile is named AppSrv01.
5. Complete the following steps to replace the WebSphere Application Server and WebSphere Portal
administrator user ID; this step is required if you change the default realm:
user and group.
group.
Augmenting a Deployment Manager profile on AIX:
An existing Deployment Manager profile can be augmented with the configuration settings required to
set up an IBM WebSphere Portal cluster.
Augmenting the Deployment Manager profile enables your Deployment Manager to manage portal nodes
and to modify the following values to fit your portal usage:
v The HTTP connection timeout for read and write are set to 180.
v If less than 300 MB, the minimum Heap Size are set to 300 MB.
v If less than 1000 MB, the maximum Heap Size are set to 1024 MB.
v If not already active, the application security are turned on.
v The group cn=wpsadmins are created in the file-based registry and the IBM WebSphere Application
Server administrative ID are added to it. This change will have no effect if security is already changed
to something other than the file-based repository.
v The com.ibm.SOAP.requestTimeout property are set to 6000 in the soap.client.props file to allow for
longer timeouts.
v SWAMAuthentication are added to the available authentication mechanisms.
v The com.ibm.portal.auth.tai.HTTPBasicAuthTAI class are registered as TAInterceptor.
v trustAssociation are enabled.
Complete the following steps to augment an existing Deployment Manager profile:
Choose one of the following methods to augment a deployment manager profile:
manager profile.
Option Steps
Installing 1693
manager profile. (continued)
Option Steps
-profileName dmgr
message.
AIX: Running configuration tasks in a multiple profile environment
Each portal profile maintains its own independent configuration. Therefore, IBM WebSphere Portal
configuration tasks are executed against only one profile with separate property files maintained in each
profile. As with a single-profile system, navigate to the ConfigEngine directory within the required profile
to execute the configuration task per that tasks's instructions.
Maintaining multiple profiles on AIX
If you created additional IBM WebSphere Portal profiles or augmented existing default profiles with
WebSphere Portal, the profiles now share the product installed files (binary files); therefore, any updates
must be coordinated with the users of the various profiles because these updates can affect the run time
behavior of each profile. You must stop all servers across all profiles sharing the same set of binary files
while the updates are occurring. Similarly, if the product binary files are shared across several systems
supporting their own portal profiles, all IBM WebSphere Portal instances across these servers should be
stopped during the update process. It is also probable that updates to each profile will be needed,
especially in the case of product maintenance application. Updates to the profiles might require that
application server instances be restarted in those profiles. In this case, user traffic can be prevented to
these server instances during the maintenance window by temporarily removing the target servers from
any web servers or load balancers.
When additional WebSphere Portal profiles are based on shared product binary files across multiple
servers, it is required that the shared file system that contains the product binary files are shared at the
same location on each server and that the location reflects the original installation location, so that the
install location is consistent across each profile configuration. For instance, if WebSphere Portal is
installed under the /opt/IBM/WebSphere directory, then that directory must be shared with other systems
as /opt/IBM/WebSphere.
Complete the following steps to maintain additional WebSphere Portal profiles:
1. Modify the web servers or load balancer that routes requests to the application servers in these
profiles to temporarily quiesce traffic to these servers, if applicable.
2. Run the following tasks from the wp_profile_root/bin directory to stop all application server instances
of each profile:
3. If the profiles are federated to a cell, run the ./stopNode.sh -username admin_userid -password
admin_password task from the wp_profile_root/bin directory of each nodeagent.
4. Apply the changes to the product binary files as appropriate, such as product maintenance for
WebSphere Application Server or WebSphere Portal.
Applying WebSphere Portal maintenance will automatically update the initial profile created by
product installation (wp_profile). When product binary files are shared across multiple machines, it is
assumed that the default installed profile, wp_profile, is present on the source server from which
these product binary files are shared. This sharing allows wp_profile to be updated when the product
binary files are updated. Follow the instructions included with the product maintenance and the
product update installer for updating the product binary files and the default wp_profile profile.
Customer supplied binary files, such as custom JAR files, properties files, or other file system updates,
must be added to the binary files at this time as well.
5. Apply changes to each profile.
Depending on the change required, you might have to start the application server instances. If
WebSphere Portal maintenance is applied to the profile, instructions are provided with the fix on how
to update just a profile without reapplying the updates to the product binary files. Customer supplied
updates to enterprise applications, portlets, and other J2EE resource configurations must be applied at
this time as well.
6. After updating each profile, verify the change. Then start any stopped servers and, if applicable, the
nodeagent, and then return user traffic to the application server instances.
Updating the configuration archive on AIX
After customizing your IBM WebSphere Portal environment or installing an iFix that requires a
configuration change to your WebSphere Portal environment, run the replace-profiles task. The readme
file for the iFix must explicitly mention that configuration changes are introduced with the iFix. The
replace-profiles task does not affect your existing profiles. It is used when creating new profiles. You
must manually apply your changes to each existing profile.
If your business practice requires version control of all systems and files, you must create a back up copy
of the CAR before running the replace-profiles task.
Perform the following steps to update the configuration archive:
2. Run the ConfigEngine.sh replace-profiles -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory of the configuration profile that was used to create the CAR.
The Portal.car file is updated on the PortalServer_root/profileTemplates/default.portal/
configArchives directory.
Server directory.
Installing WebSphere Portal fix packs require that the WebSphere Portal profile templates are regenerated
to upgrade to the new fix pack level. Run the enable-profiles task after the upgrade completes to
regenerate the profile templates. Refer to the fix pack readme file for information about how to upgrade
the profile templates when applying a fix pack.
Deleting a profile on AIX
If your business needs change, you can delete a profile from the profiles that you created.
Complete the following steps to delete a profile:
1. Stop all server instances in the profile that you plan to delete.
2. Run the ./manageprofiles.sh -delete -profileName profilename task from the AppServer_root/bin
directory, where profilename is the name of the profile that you are deleting.
Note: Deleting a profile takes several minutes to complete.
3. Delete the profile directory because it contains files that the manageprofiles command cannot delete,
such as extraneous log files.
Creating and maintaining multiple profiles on IBM i
Installing 1695
Related concepts:
Related tasks:
Installing WebSphere Portal on IBM i for the horizontal cluster nodes on page 572
authentication.
Preparing the system for multiple profile support on IBM i
v WebSphere Application Server uses the wsadmin scripting interface to support the CAR creation.
release database, which uses the Derby database after the initial installation. Any customizations made
to the Derby database prior to running the enable-profiles task are included in the additional profiles
created later. However, if you complete a database transfer to set up the release database on an
external server before running the enable-profiles task, then any customizations made between the
transfer and when the enable-profiles task is run are NOT picked up by additional profiles.
Therefore, you should complete all customizations that you want included on the additional profiles
before transferring your release database domain to an external database server.
Deployment Manager, you must remove the node from the cell. If you have a web server node, you
must remove the node before running enable-profiles.
enable-profiles, remove existing search collections from the default profile. You can re-create the
search collections after you run enable-profiles.
v Run the ConfigEngine.sh enable-profiles -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory of the configuration profile whose configuration form the basis
for the portal profile template, to create the CAR. The Portal.car file is saved to the
PortalServer_root/offer/portal/profileTemplates/default.portal/configArchives directory, where offer
is either content or server.
Related tasks:
Creating or augmenting profiles on IBM i
You can create new profiles or augment an existing Deployment Manager profile. You can use the
to automate the process.
Creating a Portal application server profile on IBM i:
The IBM WebSphere Portal installation registers the application server profile template with IBM
WebSphere Application Server. You can use the manageprofiles command to create new profiles based on
the template. The newly created profile's WebSphere Application Server administrator ID and password
Installing 1697
/QIBM/ProdData/WebSphere/PortalServer/V8/Content/Portal/profileTemplates/default.portal
-profilePath /QIBM/UserData/WebSphere/AppServer/V8/ND/profiles/testportal1
error message.
In this example, the portal profile template is installed under the /QIBM/UserData/WebSphere/
AppServer/V8/ND/profiles/wp_profile/PortalServer/profileTemplates/default.portal directory.
The new profile is testportal1 and is located under the /QIBM/UserData/WebSphere/AppServer/V8/ND/
profiles/testportal1 directory.
-isDeveloperServer: indicates that WebSphere Portal is to be configured for development mode in
this profile.
-nodeName: provides a node name for the new profile; if not provided, the node name defaults to a
value based on the local host name. This parameter is required if federating this profile into a
managed cell because this value must be unique from other nodes in the cell.
Creating a Portal custom profile on IBM i:
Run the following command from the AppServer_root/bin directory:
/QIBM/ProdData/WebSphere/PortalServer/V8/portal_family/profileTemplates/managed.portal
-profilePath /QIBM/UserData/WebSphere/AppServer/V8/ND/profiles/testManagedPortal1
-cellName testCell
-nodeName testNode
error message.
In this example, the portal profile template is installed under the /QIBM/ProdData/WebSphere/
PortalServer/V8/portal_family/profileTemplates/managed.portal directory. The new profile is named
testManagedPortal1 and is located under the /QIBM/UserData/WebSphere/AppServer/V8/ND/profiles/
testManagedPortal1 directory.
Related tasks:
Augmenting a stand-alone default profile with WebSphere Portal on IBM i:
configuration.
Replace with
Installing 1699
[ -useSocks ] ]
[ -verbose ]
d. Run the installPortalTemplates.sh AppServer_root task from the newly created
manageprofiles -augment -templatePath
/QIBM/ProdData/WebSphere/PortalServer/V8/Content/Portal/profileTemplates/default.portal.augment
-cellName testCell
-nodeName testNode
error message.
In this example, the portal profile template is installed under the /QIBM/UserData/WebSphere/
AppServer/V8/ND/profiles/wp_profile/PortalServer/profileTemplates directory. The existing default
profile is named AppSrv01.
d. Run the ConfigEngine.sh wp-change-was-admin-user -DWasUser=adminid -DWasPassword=password
from the wp_profile_root/ConfigEngine directory, to replace the old WebSphere Application Server
administrative user ID and group ID with the new user and group.
group.
Augmenting a Deployment Manager profile on IBM i:
longer timeouts.
Run the following command from the AppServer_root/bin directory:
manageprofiles.sh -augment -templatePath AppServer_root/profileTemplates/management.portal.augment
-profileName dmgr
error message.
Installing 1701
In this example, the portal profile template is installed under the AppServer_root/profileTemplates
directory. The existing Deployment Manager profile is named dmgr and is located under the
AppServer_root/profiles/Dmgr01 directory.
IBM i: Running configuration tasks in a multiple profile environment
Maintaining multiple profiles on IBM i
of each profile:
3. If the profiles are federated to a cell, run the stopNode -username admin_userid -password
this time as well.
Updating the configuration archive on IBM i
Run the ConfigEngine.sh replace-profiles -DWasPassword=password task, from the wp_profile_root/
ConfigEngine directory of the configuration profile that was used to create the CAR. The Portal.car file
is updated on the PortalServer_root/profileTemplates/default.portal/configArchives directory.
Deleting a profile on IBM i
2. Run the manageprofiles -delete -profileName profilename task from the AppServer_root/bin
Creating and maintaining multiple profiles on Linux
Installing 1703
Related concepts:
Related tasks:
Installing WebSphere Portal on Linux for the horizontal cluster nodes on page 877
authentication.
Preparing the system for multiple profile support on Linux
WebSphere Application Server uses the wsadmin scripting interface to support the CAR creation.
release database, which uses the Derby database after the initial installation. Any customizations made to
the Derby database prior to running the enable-profiles task are included in the additional profiles
created later. However, if you complete a database transfer to set up the release database on an external
server before running the enable-profiles task, then any customizations made between the transfer and
when the enable-profiles task is run are NOT picked up by additional profiles. Therefore, you should
complete all customizations that you want included on the additional profiles before transferring your
release database domain to an external database server.
Deployment Manager, you must remove the node from the cell. If you have a web server node, you must
remove the node before running enable-profiles.
enable-profiles, remove existing search collections from the default profile. You can re-create the search
collections after you run enable-profiles.
Complete the following steps to prepare the system for multiple profile support:
wp_profile_root/ConfigEngine directory of the configuration profile whose configuration will form the
basis for the portal profile template, to create the CAR. The Portal.car file is saved to the
PortalServer_root/profileTemplates/default.portal/configArchives directory.
Server directory.
Related tasks:
Creating or augmenting profiles on Linux
You can create new profiles or augment existing IBM WebSphere Application Server default profiles or
Deployment Manager profiles with IBM WebSphere Portal. You can use the Profile Management Tool
(PMT), if supported, to enter all required parameters on a graphical user interface (GUI). The PMT is the
preferred method for beginners because it uses automatically created default values. You can also use the
to automate the process. If you have an existing WebSphere Application Server default profile, you must
use the manageProfiles command. The PMT interface is not supported for augmentation in this scenario.
Creating a Portal application server profile on Linux:
The IBM WebSphere Portal installation registers the WebSphere Portal application server profile template
with IBM WebSphere Application Server. You can then create new profiles based on the template. You can
use the manageprofiles command. You can also use the Profile Management Tool, which is a graphical
user interface. The newly created profile's WebSphere Application Server administrator ID and password
Installing 1705
1. Choose one of the following methods to create a profile:
Table 456. Choose between the Profile Management Tool and the manageprofiles task to create a portal profile.
Option Steps
4. On the Environment Selection panel, expand WebSphere Portal Server 8.0.0 and select WebSphere Portal
Server, and then click Next.
Note: You can choose to select the Create the server using the development template check box to enable
developer mode for this profile. You can choose to select the Make this profile the default check box to
specify that this profile is the default profile in the system.
6. On the Node, Host, and Cell Names panel, provide the node name and TCP/IP host name for the new
management cell (under Deployment Manager control). The host name must be valid and reachable over the
network. Click Next to continue.
7. On the Administrative Security panel, make sure that the Enable administrative security checkbox is
unchecked. The new profile is then created using the same security settings that are saved in the Portal
profile template. After the new Portal profile is created, the security configuration of the new profile can then
be modified as required. Click Next to continue.
8. On the Service Definition panel, specify whether the WebSphere Portal server in this profile is to be registered
and controlled as a service. Click Next to continue.
Create to create the profile based on the supplied information.
Note: The port values presented in the summary value is overwritten by the port values used by the servers
present in the configuration archive provided as part of the portal profile template. These port values will
must be adjusted after profile creation if they are in conflict with other ports on the local system.
Important: The creation summary shows a "server name" value of null. You can ignore this summary since
the application server name was not requested on previous panels and always defaults to WebSphere_Portal.
/opt/IBM/WebSphere/PortalServer/profileTemplates/default.portal
-profilePath /opt/IBM/WebSphere/testportal1
-cellName testCell
-nodeName testNode
message.
In this example, the portal profile template is installed under the /opt/IBM/WebSphere/PortalServer/
profileTemplates/default.portal directory. The new profile is testportal1 and is located under the
/opt/IBM/WebSphere/testportal1 directory.
-isDeveloperServer: indicates that WebSphere Portal is to be configured for development mode in this profile.
-nodeName: provides a node name for the new profile; if not provided, the node name defaults to a value based
on the local host name. This parameter is required if federating this profile into a managed cell because this
value must be unique from other nodes in the cell.
Creating a Portal custom profile on Linux:
Choose one of the following methods to create a profile that is used for additional cluster members:
Option Steps
click Next.
CAUTION:
node.
-cellName testCell
-nodeName testNode
message.
Related tasks:
Augmenting a stand-alone default profile with WebSphere Portal on Linux:
configuration.
Installing 1707
click OK.
stored.
e. Select Apply.
f. Select OK.
v 8.0.0.3-WS-WAS-IFPM59935
v 8.0.0.3-WS-WAS-IFPM60670
v 8.0.0.3-WS-WAS-IFPM61934
v 8.0.0.3-WS-WAS-TFPM59935
v 8.0.0.3-WS-WAS-TFPM60670
v 8.0.0.3-WS-WAS-TFPM61934
c. Click Next.
directory path.
path.
3) Click Next.
Next.
4. Complete the following steps to create a profile:
Table 458. Running the manageprofiles task to create a profile.
Option Steps
/opt/IBM/WebSphere/PortalServer/profileTemplates/default.portal.augment
-cellName testCell
-nodeName testNode
message.
In this example, the portal profile template is installed under the /opt/IBM/WebSphere/PortalServer/
profileTemplates directory. The existing default profile is named AppSrv01.
user and group.
Installing 1709
group.
Augmenting a Deployment Manager profile on Linux:
longer timeouts.
Choose one of the following methods to augment a deployment manager profile:
manager profile.
Option Steps
manager profile. (continued)
Option Steps
-profileName dmgr
message.
Linux: Running configuration tasks in a multiple profile environment
Maintaining multiple profiles on Linux
When additional WebSphere Portal profiles are based on shared product binary files across multiple
servers, it is required that the shared file system that contains the product binary files are shared at the
same location on each server and that the location reflects the original installation location, so that the
install location is consistent across each profile configuration. For instance, if WebSphere Portal is
installed under the /opt/IBM/WebSphere directory, then that directory must be shared with other systems
as /opt/IBM/WebSphere.
of each profile:
3. If the profiles are federated to a cell, run the ./stopNode.sh -username admin_userid -password
Installing 1711
this time as well.
Updating the configuration archive on Linux
Perform the following steps to update the configuration archive:
2. Run the ConfigEngine.sh replace-profiles -DWasPassword=password task, from the
wp_profile_root/ConfigEngine directory of the configuration profile that was used to create the CAR.
The Portal.car file is updated on the PortalServer_root/profileTemplates/default.portal/
configArchives directory.
Server directory.
Deleting a profile on Linux
2. Run the ./manageprofiles.sh -delete -profileName profilename task from the AppServer_root/bin
Creating and maintaining multiple profiles on Solaris
Related concepts:
Related tasks:
Installing WebSphere Portal on Solaris for the horizontal cluster nodes on page 1193
Installing WebSphere Portal on Solaris on page 913
authentication.
Preparing the system for multiple profile support on Solaris
The baseline configuration is provided in the form of a configuration archive (CAR) that is creat

WP 800

Uploaded by

Copyright:

Available Formats

You might also like

WP 800

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WP 800

Uploaded by

Copyright:

Available Formats

Version 8 Release 0

WebSphere Portal 8.0

ii WebSphere Portal 8.0

Access Manager WebSEAL

, and IBM Connections.

for z/OS to any other supported database.

for z/OS database.

Portal and IBM WebSphere Application

EM64T systems (x64) Multilingual

EM64T systems (x64) Multilingual

EM64T systems (x64) Multilingual

on AMD64 and Intel

EM64T systems (x64) English

on 32-bit AMD and Intel systems (x86) English

on AMD64 and Intel

EM64T systems (x64) English

on 32-bit AMD and Intel systems (x86) English

EM64T systems (x64) Multilingual

EM64T systems (x64) Multilingual

or other performance measurement systems

You might also like