WP 70

Version 7 Release 0
WebSphere Portal 7.0
򔻐򗗠򙳰
ii WebSphere Portal 7.0
Contents
Product overview. . . . . . . . . . . 1 Localizing a new virtual machine instance on
What's new . . . . . . . . . . . . . . . 2 Windows . . . . . . . . . . . . . 1360
IBM WebSphere Portal new features and Setting up and maintaining a portal farm . . . 1361
improvements . . . . . . . . . . . . . 2 Choosing the type of portal farm to create 1362
Documentation improvements and changes . . . 5 Setting up the HTTP server plug-in on a portal
Documentation resources . . . . . . . . . . 6 farm . . . . . . . . . . . . . . . 1367
Versatile framework . . . . . . . . . . . . 8 Configuring search in a portal farm . . . . 1369
Customization . . . . . . . . . . . . . . 8 Setting up a highly available message bus . . 1371
Streamlined site creation . . . . . . . . . . 12 Administering a portal farm . . . . . . . 1372
Portlets . . . . . . . . . . . . . . . . 15 Maintaining a portal farm . . . . . . . . 1373
Tagging and rating portal content . . . . . . . 17 Setting up a Personalization server on WebSphere
Blogs and wikis . . . . . . . . . . . . . 19 Application Server . . . . . . . . . . . 1374
Application integration . . . . . . . . . . 20 Planning for the Personalization Server . . . 1375
Collaboration . . . . . . . . . . . . . . 21 Installing and removing a stand-alone
Accessibility features . . . . . . . . . . . 22 Personalization Server . . . . . . . . . 1376
Unsupported and deprecated features . . . . . 23 Uninstalling WebSphere Portal . . . . . . . 1378
Restrictions on moving a node to a stand-alone
Installing . . . . . . . . . . . . . . 27 configuration . . . . . . . . . . . . 1378
Uninstalling WebSphere Portal on AIX . . . 1378
Planning to install WebSphere Portal . . . . . . 27
Uninstalling WebSphere Portal on IBM i . . . 1383
System requirements . . . . . . . . . . 27
Uninstalling WebSphere Portal on Linux . . . 1388
Release notes . . . . . . . . . . . . . 27
Uninstalling WebSphere Portal on Solaris. . . 1393
WebSphere Portal Support Statement . . . . . 28
Uninstalling WebSphere Portal on Windows 1398
User IDs and passwords . . . . . . . . . 30
Applying fixes . . . . . . . . . . . . 1403
Server topologies . . . . . . . . . . . 33
Web Content Manager topologies . . . . . . 48
Web servers . . . . . . . . . . . . . 57 Migrating. . . . . . . . . . . . . 1405
Database considerations . . . . . . . . . 59 Understanding migration . . . . . . . . . 1405
User registry considerations . . . . . . . . 82 Supported migration paths . . . . . . . . 1405
Cluster considerations . . . . . . . . . . 88 High-availability systems . . . . . . . . . 1409
Virtual environment overview . . . . . . . 102 Planning for migration . . . . . . . . . . 1410
Multiple profile support . . . . . . . . . 103 Migrating V6.0.1.x . . . . . . . . . . . 1411
Installation methods, options, and sources . . . . 105 Planning checklist: V6.0.1.x portal . . . . . 1411
Installation options . . . . . . . . . . 107 V6.0.1.x production server migration scenarios 1422
Installation methods . . . . . . . . . . 108 Migrating a V6.0.1.x clustered deployment 1422
Installation source location . . . . . . . . 109 Replacing document libraries. . . . . . . 1423
Advanced installation parameters. . . . . . . 111 Preparing for migration from V6.0.1.x . . . . 1423
Installing on AIX . . . . . . . . . . . . 114 Migrating Version 6.0.1.x customized resources 1441
Setting up a stand-alone server on AIX . . . . 114 Migrating a Version 6.0.1.x product
Setting up a cluster on AIX . . . . . . . . 234 configuration . . . . . . . . . . . . 1453
Installing on IBM i . . . . . . . . . . . 396 Migrating the access control configuration . . 1472
Setting up a stand-alone server on IBM i . . . 396 Migrating additional components . . . . . 1475
Setting up a cluster on IBM i . . . . . . . 444 Migrating deprecated portlets . . . . . . 1482
Rendering documents on IBM i . . . . . . 519 Migrating documents from Portal Document
Installing on Linux . . . . . . . . . . . 521 Manager to Quickr Document Libraries . . . 1483
Setting up a stand-alone server on Linux . . . 521 Post-migration activities . . . . . . . . 1487
Setting up a cluster on Linux . . . . . . . 640 Migrating V6.1.x on a V6.1 application server 1498
Localizing a new virtual machine instance on Planning checklist: V6.1.x portal on a V6.1
Linux . . . . . . . . . . . . . . . 801 application server . . . . . . . . . . 1498
Installing on Solaris . . . . . . . . . . . 802 Premigration tasks . . . . . . . . . . 1505
Setting up a stand-alone server on Solaris . . . 803 Migrating search components from V6.1 . . . 1509
Setting up a cluster on Solaris . . . . . . . 920 Migrating a stand-alone portal that runs on a
Installing on Windows . . . . . . . . . . 1084 V6.1 application server . . . . . . . . . 1512
Setting up a stand-alone server on Windows 1084 Migrating a V6.1.x clustered portal . . . . . 1528
Setting up a cluster on Windows . . . . . 1200 Migrating V6.1.x on a V7 application server . . . 1546
iii
Planning checklist: V6.1.x portal on a V7 Configuring the IBM License Metric Tool on
application server . . . . . . . . . . 1546 Windows . . . . . . . . . . . . . 1701
Preparing for migration . . . . . . . . 1553 Setting up a remote spell checker . . . . . . 1703
Migrating V6.1 search components . . . . . 1556 Installing a remote spell checker. . . . . . 1703
Migrating a stand-alone portal that runs on a Configuring access to a remote spell checker 1704
V7 application server . . . . . . . . . 1559 Enabling Document Conversion Services . . . . 1705
Migrating a V6.1.x clustered environment . . 1568 Configuring Document Conversion Services 1708
Deploying new functionality in a migrated portal 1577 Configuring a remote Document Conversion
Adding the Page Builder theme . . . . . . 1577 Service . . . . . . . . . . . . . . 1711
Enabling mashup integration . . . . . . . 1578 Files that can be viewed as HTML . . . . . 1713
Enabling impersonation . . . . . . . . 1579 Connecting to existing database domains. . . . 1718
Updating data after migration . . . . . . 1579 Transferring data from a database other than the
Enabling new Web Content Manager features 1582 default database. . . . . . . . . . . . . 1718
Updating blog and wiki templates after Transferring data to DB2 from a non-default
migration . . . . . . . . . . . . . 1584 database. . . . . . . . . . . . . . 1719
Enabling new functionality in the Person menu 1585 Transferring data to IBM DB2 for i from a
Moving hidden pages . . . . . . . . . 1587 non-default database . . . . . . . . . 1721
Transferring data to Oracle or Oracle RAC
Configuring. . . . . . . . . . . . 1589 from a non-default database . . . . . . . 1725
Changing the portal URI . . . . . . . . . 1589 Transferring data to SQL Server from a
Configuring WebSphere Portal with the non-default database . . . . . . . . . 1728
configuration wizard . . . . . . . . . . 1595 Adding features to a base installation . . . . . 1731
Starting the configuration wizard on i . . . . 1597 Adding composite application pages and
Starting the configuration wizard on UNIX 1598 portlets to a base installation . . . . . . . 1731
Starting the configuration wizard on Windows 1598 Adding Personalization features to a base
Configuring portal behavior . . . . . . . . 1598 installation . . . . . . . . . . . . . 1731
Setting the language of the portal . . . . . 1598 Adding Common Mail support to a base
HTTP session cookie name: JSESSIONID . . . 1599 installation . . . . . . . . . . . . . 1732
Customizing the home page login URL with Adding Domino Extended Products Portlets
the Page Builder theme. . . . . . . . . 1599 support to a base installation . . . . . . . 1732
Using portal light mode . . . . . . . . 1599 Adding Web Content Manager to a base
Creating or editing a custom unique name 1601 installation . . . . . . . . . . . . . 1733
Setting the portal entry page . . . . . . . 1602 Configuring blog and wiki template libraries in
Configuring your time settings . . . . . . 1602 a base installation . . . . . . . . . . 1733
Setting the search engine that opens when Adding mashup integration to a base
users select Find . . . . . . . . . . . 1603 installation . . . . . . . . . . . . . 1734
Configuring how to handle portlets that a user
is not authorized to view . . . . . . . . 1603 Integrating . . . . . . . . . . . . 1735
Configuring your portal for the Mashup Center 1604 Integrating with collaboration software . . . . 1735
Configuring user session persistence . . . . 1605 Collaboration and Messaging portlets . . . . 1735
Configuring dynamic fragment cache . . . . 1608 Finding users . . . . . . . . . . . . 1759
Configuring portlet filtering . . . . . . . 1608 Planning for collaborative servers and portlets 1770
Configuring authentication filters . . . . . 1611 Installing Lotus Domino and the Extended
Caching . . . . . . . . . . . . . . 1614 Products . . . . . . . . . . . . . 1778
URL Mapping . . . . . . . . . . . . 1623 Integrating Lotus Domino applications and
HTTP proxy configuration. . . . . . . . 1630 mail . . . . . . . . . . . . . . . 1784
Delayed cleanup of deleted portal pages . . . 1630 Integrating with IBM Lotus Sametime . . . . 1803
Deleting orphaned data . . . . . . . . 1632 Integrating with Lotus Quickr . . . . . . 1816
Setting service configuration properties . . . 1634 Integrating Lotus Connections . . . . . . 1822
Parallel portlet rendering . . . . . . . . 1692 Collaborative Services environment properties 1823
Configuring the IBM License Metric Tool and IBM Integrating mashups . . . . . . . . . . 1831
Tivoli License Compliance Manager . . . . . 1696 Overview of portal mashup integration . . . 1832
Configuring the IBM License Metric Tool on Configuring your portal and mashups. . . . 1838
AIX . . . . . . . . . . . . . . . 1696 Working with portal and mashups . . . . . 1851
Configuring the IBM License Metric Tool on
IBM i. . . . . . . . . . . . . . . 1697 Administering. . . . . . . . . . . 1867
Configuring the IBM License Metric Tool on Portal administration tools . . . . . . . . 1867
Linux . . . . . . . . . . . . . . 1699 Portal administration portlets . . . . . . 1870
Configuring the IBM License Metric Tool on The XML configuration interface . . . . . 1876
Solaris . . . . . . . . . . . . . . 1700 Portal Scripting Interface . . . . . . . . 1920
iv WebSphere Portal 7.0

Starting and stopping servers, deployment Activating and deactivating portlet
managers, and node agents . . . . . . . . 1980 applications or portlets . . . . . . . . . 2071
Updating user ID and passwords . . . . . . 1982 Modifying portlet applications and portlets 2071
Changing the WebSphere Portal administrator Copying portlet applications . . . . . . . 2072
password . . . . . . . . . . . . . 1983 Copying portlets . . . . . . . . . . . 2072
Changing the WebSphere Application Server Updating Web modules, portlet applications,
administrator password in the file registry . . 1984 and portlets . . . . . . . . . . . . 2073
Changing the WebSphere Application Server Deleting Web modules, portlet applications, or
administrator password in the LDAP server portlets . . . . . . . . . . . . . . 2073
using the LDAP administration interface . . . 1984 Disabling anchors in portlet URLs . . . . . 2073
Replacing the WebSphere Application Server Managing pages . . . . . . . . . . . . 2074
administrator user ID . . . . . . . . . 1985 Selecting pages . . . . . . . . . . . 2074
Replacing the WebSphere Portal administrator Creating pages . . . . . . . . . . . 2074
user ID . . . . . . . . . . . . . . 1986 Creating a label . . . . . . . . . . . 2076
Changing the LDAP bind password . . . . 1987 Creating a URL . . . . . . . . . . . 2076
Changing database passwords that are used by Editing pages, labels, and URLs . . . . . . 2077
WebSphere Portal . . . . . . . . . . 1987 Searching pages . . . . . . . . . . . 2077
Users and groups . . . . . . . . . . . 1988 Ordering pages, labels, and URLs . . . . . 2078
Managing users and groups . . . . . . . 1988 Moving pages and labels . . . . . . . . 2078
Creating new users and groups . . . . . . 1989 Assigning access to pages, labels, and URLs 2079
Viewing the members of a group . . . . . 1990 Activating or deactivating a page, label, or
Editing user information . . . . . . . . 1990 URL . . . . . . . . . . . . . . . 2079
Reusing group information . . . . . . . 1990 Deleting pages, labels, and URLs . . . . . 2079
Deleting users and groups. . . . . . . . 1991 Exporting pages and labels . . . . . . . 2080
Virtual Users and Groups . . . . . . . . 1992 Setting up Manage Pages . . . . . . . . 2080
Enabling user impersonation . . . . . . . 1992 Field descriptions for the Manage Pages portlet 2081
Customize common name generation . . . . 1995 Managing your cluster . . . . . . . . . . 2081
Nested groups . . . . . . . . . . . 1995 Enabling LDAP security after cluster creation 2081
Registration/Edit My Profile and Login Renaming the node . . . . . . . . . . 2082
portlets . . . . . . . . . . . . . . 1996 Determining application sharing between
Deregistering users and groups . . . . . . 1999 clusters . . . . . . . . . . . . . . 2082
Setting limits on searches for users and groups 2000 Managing portlets in your cluster . . . . . 2083
Controlling access . . . . . . . . . . . 2000 Managing replication in your cluster . . . . 2087
Managing Access Control . . . . . . . . 2001 Managing Portal Scripting Interface in your
Resources, roles, access rights, and initial cluster . . . . . . . . . . . . . . 2088
access control settings . . . . . . . . . 2001 Managing Single sign-on settings in your
Access control scenarios . . . . . . . . 2027 cluster . . . . . . . . . . . . . . 2088
Setting user and group permissions . . . . 2029 Updating Personalization properties in a
Setting resource permissions . . . . . . . 2030 cluster . . . . . . . . . . . . . . 2089
Delegated Access Control Administration . . 2030 Managing WebSphere Application Server in
Access Control Caching . . . . . . . . 2031 your cluster . . . . . . . . . . . . 2089
Managing the Page Builder theme by Supporting multiple profiles . . . . . . . . 2090
configuration tasks . . . . . . . . . . . 2032 Creating and maintaining multiple profiles on
Task refresh-page-layout . . . . . . . . 2033 AIX . . . . . . . . . . . . . . . 2090
Task webdav-deploy-zip-file . . . . . . . 2034 Creating and maintaining multiple profiles on
Task register-iwidget-definition . . . . . . 2035 IBM i. . . . . . . . . . . . . . . 2098
Task refresh-iwidget-definitions . . . . . . 2038 Creating and maintaining multiple profiles on
Managing portal resources with policies . . . . 2040 Linux . . . . . . . . . . . . . . 2104
Policy principles . . . . . . . . . . . 2041 Creating and maintaining multiple profiles on
Policy rules and conditions . . . . . . . 2044 Solaris . . . . . . . . . . . . . . 2112
Users, tasks, and tools . . . . . . . . . 2045 Creating and maintaining multiple profiles on
Working with policies . . . . . . . . . 2047 Windows . . . . . . . . . . . . . 2120
Mail policy attributes . . . . . . . . . 2056 Portal Search . . . . . . . . . . . . . 2128
Working with Mail policy definitions . . . . 2058 Portlets for working with Search . . . . . 2128
Policy settings for mail . . . . . . . . . 2063 Planning and preparing for Portal Search. . . 2131
Policy settings for composite applications . . 2064 Administering Portal Search . . . . . . . 2143
Policy cache properties . . . . . . . . . 2066 Setting up search collections . . . . . . . 2167
Managing portlets and portlet applications . . . 2067 Searching and crawling portal and other sites 2177
Web modules, portlet applications, and portlets 2068 Search by external users on your portal site 2188
Installing a portlet . . . . . . . . . . 2068 Working with the search portlets . . . . . 2193
Deploying J2EE resources . . . . . . . . 2069 Hints and tips for using Portal Search . . . . 2226
Contents v
Managing your site . . . . . . . . . . . 2232 Restoring files, databases, and the LDAP
Enabling remote access to your servers . . . 2233 server(s). . . . . . . . . . . . . . 2462
Configuring resource management . . . . . 2234 ReleaseBuilder . . . . . . . . . . . . 2463
Managing your servers . . . . . . . . . 2235 Checklist for ReleaseBuilder . . . . . . . 2464
Publishing your page . . . . . . . . . 2237 Building a release . . . . . . . . . . 2465
Providing reviewer access to a published page 2239 Building a Release for virtual portal
Promoting your page . . . . . . . . . 2239 installations . . . . . . . . . . . . 2468
Demoting your page . . . . . . . . . 2241 Browser behavior and scenarios . . . . . . . 2472
Republishing and promoting a page . . . . 2241 View state behavior for the Page Builder theme 2472
Portal Scripting Interface extension for site Back button behavior . . . . . . . . . 2475
management . . . . . . . . . . . . 2242 Back button limitations . . . . . . . . . 2480
Tagging and rating . . . . . . . . . . . 2249 Configuring history expiration limit . . . . 2481
How tagging and rating works in the portal 2250 History expiration limit scenarios . . . . . 2481
The tagging and rating user interface . . . . 2255
Tagging and rating for static pages . . . . . 2272 Securing . . . . . . . . . . . . . 2483
Searching for tagged content . . . . . . . 2273 Security and authentication considerations . . . 2483
Allowing your own custom content to be Authentication . . . . . . . . . . . 2483
tagged and rated . . . . . . . . . . . 2274 Federal Information Processing Standards . . 2484
Configuration reference . . . . . . . . 2278 Planning for single sign-on . . . . . . . 2485
Security for tagging and rating . . . . . . 2290 Secure Socket Layer . . . . . . . . . . 2485
Using the XML configuration interface to Credential Vault . . . . . . . . . . . 2486
administer tags and ratings . . . . . . . 2291 Caching considerations . . . . . . . . . 2487
Hints and tips for tagging and rating . . . . 2295 Planning for external security managers . . . 2487
Using WebDAV with WebSphere Portal . . . . 2298 Java 2 security with WebSphere Portal . . . . 2491
Using WebDAV file store for the Page Builder Enabling step-up authentication, the Remember
theme and mashup integration . . . . . . 2299 me cookie, or both . . . . . . . . . . . 2492
Serving HTTP OPTIONS requests to the server AIX: Enabling step-up authentication, the
context root by WebDAV clients . . . . . . 2304 Remember me cookie, or both . . . . . . 2492
Working with WebDAV clients . . . . . . 2304 IBM i: Enabling step-up authentication, the
Multiple virtual portals. . . . . . . . . . 2308 Remember me cookie, or both . . . . . . 2496
Usage scenarios for virtual portals . . . . . 2308 Linux: Enabling step-up authentication, the
Planning for virtual portals . . . . . . . 2310 Remember me cookie, or both . . . . . . 2500
Administering virtual portals. . . . . . . 2323 Solaris: Enabling step-up authentication, the
Virtual portals reference . . . . . . . . 2335 Remember me cookie, or both . . . . . . 2504
Language support . . . . . . . . . . . 2343 Windows: Enabling step-up authentication, the
Supporting a new language . . . . . . . 2344 Remember me cookie, or both . . . . . . 2508
Changing the character set for a language . . 2347 Securing LTPA keys on a production environment 2512
Dynamically changing the language during the Configuring SSL . . . . . . . . . . . . 2513
session . . . . . . . . . . . . . . 2347 Setting up SSL . . . . . . . . . . . 2513
Selecting and changing the language . . . . 2348 Configuring SSL only for the login process 2517
Setting the language fallback filter . . . . . 2350 Setting up Client Certificate Authentication 2518
Using WSRP services . . . . . . . . . . 2351 Cryptographic hardware for SSL acceleration 2521
Learning about WSRP . . . . . . . . . 2352 Enabling FIPS . . . . . . . . . . . . . 2522
Planning for WSRP . . . . . . . . . . 2353 Managing user data . . . . . . . . . . . 2523
Using your portal as a WSRP Producer . . . 2358 Enabling application groups . . . . . . . 2524
Using your portal as a WSRP Consumer . . . 2376 Removing attributes . . . . . . . . . . 2525
Reference for using WSRP with the portal . . 2404 Managing your user registry on AIX . . . . 2526
Working with composite applications . . . . . 2408 Managing your user registry on i . . . . . 2553
Users, tasks, and tools for composite Managing your user registry on Linux . . . 2577
applications . . . . . . . . . . . . 2409 Managing your user registry on Solaris . . . 2604
Configuring mail service . . . . . . . . 2410 Managing your user registry on Windows . . 2631
Working with application templates . . . . 2411 Enabling HTTP Basic Authentication for simple
Working with applications . . . . . . . 2418 clients . . . . . . . . . . . . . . . 2658
Working with policies for composite The HTTP Basic Authentication Trust
applications . . . . . . . . . . . . 2445 Association Interceptor . . . . . . . . . 2658
Composite application concepts . . . . . . 2454 Configuring the HTTP Basic Authentication
Backup and restore . . . . . . . . . . . 2460 Trust Association Interceptor . . . . . . . 2659
Guidelines for clustered deployments . . . . 2460 Reference: Properties for the Trust Association
Backing up files, databases, and the LDAP Interceptor . . . . . . . . . . . . . 2660
server(s). . . . . . . . . . . . . . 2461
vi WebSphere Portal 7.0

HTTP Basic Authentication Trust Association Layout and content . . . . . . . . . . 2761
Interceptor in combination with external Locking content on a page . . . . . . . 2765
authentication servers . . . . . . . . . 2662 Connections between portlets . . . . . . 2766
Setting up custom user repositories . . . . . 2662 Themes and skins . . . . . . . . . . 2766
Creating and updating federated repositories 2663 Managing portlets on a page . . . . . . . . 2767
Creating and updating stand-alone repositories 2665 Adding portlets to a page by using the Portlet
External security managers . . . . . . . . 2668 Palette . . . . . . . . . . . . . . 2768
Enabling and configuring single sign-on for Accessible alternative for adding a portlet to a
HTTP requests using SPNEGO . . . . . . 2668 page . . . . . . . . . . . . . . . 2769
Configuring Tivoli Access Manager. . . . . 2669 Rearranging portlets on a page . . . . . . 2770
Configuring eTrust SiteMinder . . . . . . 2686 Accessible alternatives for rearranging portlets
Verifying Trust Association Interceptors for on a page . . . . . . . . . . . . . 2771
authentication . . . . . . . . . . . . 2693 Restricting the movability of portlets on a page 2771
Changing the login and logout pages . . . . 2693 Creating a category . . . . . . . . . . 2772
Managing access control with external security Searching for portlets . . . . . . . . . 2772
managers . . . . . . . . . . . . . 2694 Limiting search results . . . . . . . . . 2773
Deleting passwords from properties files . . . . 2695 Rearranging categories in the Portlet Palette 2773
Moving portlets to another category . . . . 2774
Monitoring . . . . . . . . . . . . 2697 Copying a portlet to multiple categories . . . 2774
Portlet load monitoring for WebSphere Portal 2697 Renaming a category in a palette . . . . . 2775
Configuring and administering Portlet load Setting the category titles for other languages 2776
monitoring . . . . . . . . . . . . . 2697 Resetting the Palette to the default settings 2776
Configuring Portlet load monitoring . . . . 2698 Deleting a category . . . . . . . . . . 2777
Administering Portlet load monitoring . . . 2700 Deleting a portlet from a Palette category . . 2777
Logging and auditing events . . . . . . . 2701 Modifying Palette settings . . . . . . . . 2778
API for accessing Portlet load monitoring data 2702 Access control for the Palette . . . . . . . 2779
Analyzing portal usage data . . . . . . . . 2705 Using portlet wires . . . . . . . . . . . 2781
Logging and analyzing server side site data 2705 Working with portlet wires . . . . . . . 2781
Analyzing user behavior by Active Site Selecting the matching mode . . . . . . . 2781
Analytics . . . . . . . . . . . . . 2711 Adding a wire. . . . . . . . . . . . 2782
Auditing . . . . . . . . . . . . . . 2719 Deleting a wire . . . . . . . . . . . 2783
Defining global targets . . . . . . . . . 2783
Designing and setting up a portal site . . . . . 2783
Setting up a portal site . . . . . . . 2721
Designing a site using Page Builder themes
Site wizard, sample sites, and templates . . . . 2721
and skins . . . . . . . . . . . . . 2784
Sample sites and New Site Wizard . . . . . 2721
Designing a portal site using legacy themes
Exploring the sample site templates . . . . 2723
and skins . . . . . . . . . . . . . 2816
Working with pages . . . . . . . . . . . 2724
Comparison of features support by types of
Pages, and shared, derived, and hidden pages 2724
portal pages . . . . . . . . . . . . 2901
Adding pages . . . . . . . . . . . . 2729
Adding content to the site. . . . . . . . . 2902
Creating shared pages . . . . . . . . . 2731
Creating and adding static content . . . . . 2902
Creating derived pages . . . . . . . . . 2731
Using Web clipping to import content . . . . 2932
Creating page templates . . . . . . . . 2731
Working with IBM Syndicated Feed Portlet for
Creating pages from a page template . . . . 2732
WebSphere Portal . . . . . . . . . . 2943
Working with Page Builder . . . . . . . . 2733
Adding blogs to the site . . . . . . . . 2948
Creating top level page tabs . . . . . . . 2734
Adding wikis to the site . . . . . . . . 2952
Moving page tabs . . . . . . . . . . 2734
Personalizing your content . . . . . . . 2955
Creating child pages . . . . . . . . . 2734
Installed portlets . . . . . . . . . . . 3057
Moving child pages . . . . . . . . . . 2735
Getting started with search . . . . . . . . 3060
Adding content . . . . . . . . . . . 2735
Search . . . . . . . . . . . . . . 3060
Changing page style. . . . . . . . . . 2740
Search scopes . . . . . . . . . . . . 3061
Changing page layout . . . . . . . . . 2743
Configuring external searches . . . . . . 3062
Working with page builder navigation . . . 2744
Configuring suggested links . . . . . . . 3065
Hiding content . . . . . . . . . . . 2746
Adding documents to search collections . . . 3066
Sharing pages . . . . . . . . . . . . 2747
Page builder drag-and-drop . . . . . . . 2751
Page builder menus . . . . . . . . . . 2753 Building a web content system . . . 3067
Page builder iWidgets . . . . . . . . . 2757
Using a different Dojo version . . . . . . 2759 Developing . . . . . . . . . . . . 3069
Hints and tips for page builder . . . . . . 2760 Setting up a development server . . . . . . 3069
Customizing pages . . . . . . . . . . . 2761 Preparing your Windows operating system 3069
Contents vii
Installing WebSphere Portal on Windows in a Troubleshooting. . . . . . . . . . 3537
single server environment . . . . . . . . 3070 Tools for troubleshooting and diagnostics . . . 3537
Changing to developer mode. . . . . . . . 3073 IBM Support Assistant . . . . . . . . . 3537
Configuring developer mode on AIX . . . . 3074 Data collection and symptom analysis . . . . 3538
Configuring developer mode on IBM i . . . 3074 Manual creation of aspect-enabled JAR files 3540
Configuring developer mode on Linux . . . 3075 Portal version and history information . . . 3541
Configuring developer mode on Solaris . . . 3076 Logging and tracing . . . . . . . . . . 3542
Configuring developer mode on Windows 3077 Contact support . . . . . . . . . . . . 3562
Dojo and WebSphere Portal . . . . . . . . 3077
Developing portlets . . . . . . . . . . . 3081 Reference . . . . . . . . . . . . 3563
Portlet concepts . . . . . . . . . . . 3081
Conventions . . . . . . . . . . . . . 3563
Understanding the basics . . . . . . . . 3083
Directory structure . . . . . . . . . . . 3563
Standard portlet API . . . . . . . . . 3124
Terms of use . . . . . . . . . . . . . 3569
Portlet services . . . . . . . . . . . 3127
Notices and trademarks . . . . . . . . . 3570
Struts Portlet Framework . . . . . . . . 3133
Glossary. . . . . . . . . . . . . . . 3572
Model SPI overview. . . . . . . . . . 3165
A . . . . . . . . . . . . . . . . . 3572
Navigational State SPI . . . . . . . . . 3189
B . . . . . . . . . . . . . . . . . 3572
Controller SPI . . . . . . . . . . . . 3199
C . . . . . . . . . . . . . . . . . 3573
User and group management. . . . . . . 3214
D . . . . . . . . . . . . . . . . . 3574
Portal Access Control interfaces . . . . . . 3232
E . . . . . . . . . . . . . . . . . 3574
Web 2.0 user interface features . . . . . . 3240
F . . . . . . . . . . . . . . . . . 3575
Client-side aggregation reference . . . . . 3264
G . . . . . . . . . . . . . . . . . 3575
Portlet communication . . . . . . . . . 3282
H . . . . . . . . . . . . . . . . . 3575
Drag and drop zones . . . . . . . . . 3306
I . . . . . . . . . . . . . . . . . 3575
Dynamic user interfaces . . . . . . . . 3310
J . . . . . . . . . . . . . . . . . 3575
Collaborative Services API . . . . . . . 3316
L . . . . . . . . . . . . . . . . . 3576
IBM Portlet API . . . . . . . . . . . 3325
M. . . . . . . . . . . . . . . . . 3576
Developing a personalized portlet . . . . . 3336
N . . . . . . . . . . . . . . . . . 3577
Personalization programming reference . . . 3397
O . . . . . . . . . . . . . . . . . 3577
Portlet development reference . . . . . . 3412
P . . . . . . . . . . . . . . . . . 3577
Extending tagging and rating by using service
R . . . . . . . . . . . . . . . . . 3579
APIs . . . . . . . . . . . . . . . . 3444
S . . . . . . . . . . . . . . . . . 3580
The Java API . . . . . . . . . . . . 3444
T . . . . . . . . . . . . . . . . . 3581
The REST API . . . . . . . . . . . . 3444
U . . . . . . . . . . . . . . . . . 3581
Composite Applications REST services . . . . 3458
V . . . . . . . . . . . . . . . . . 3581
Template REST services . . . . . . . . 3458
W. . . . . . . . . . . . . . . . . 3582
Application REST services. . . . . . . . 3485
X . . . . . . . . . . . . . . . . . 3583
Application Favorites REST services . . . . 3508
Roles REST services . . . . . . . . . . 3512
Members REST services . . . . . . . . 3522 Index . . . . . . . . . . . . . . 3585
REST service examples . . . . . . . . . 3533
viii WebSphere Portal 7.0

Product overview
IBM® WebSphere® Portal consists of middleware applications (called portlets), mashups, and
development tools for building and managing secure business-to-business (B2B), business-to-consumer
(B2C), and business-to-employee (B2E) portals. Web portals allow partners, employees and customers to
choose their user experience, with personalized applications based on role, context, actions, location,
preferences and team collaboration needs. IBM WebSphere Portal software provides a composite
application or business mashup framework and the advanced tooling needed to build flexible, SOA-based
solutions, as well as the unmatched scalability required by any size organization.
The Server offering of WebSphere Portal provides personalization and productivity functions along with
the scalable portal framework. IBM WebSphere Portal Server is the foundation offering of the WebSphere
Portal product family, with enterprise portal capabilities that enable you to quickly consolidate
applications and content into role-based applications, complete with search, personalization, and security
capabilities.
The Content Accelerator and Enable offerings add IBM Web Content Manager, document management,
enterprise search and enhanced workflow capabilities and the Extend offering includes powerful
collaborative features including team collaboration, electronic forms, instant messaging and presence
awareness services to enhance portal effectiveness. Additional IBM accelerator offerings provide
additional solutions that easily snap on to WebSphere Portal software and can reduce time to value,
helping customers reduce the costs of deploying content, automating business processes, collaborating
and more.
A portal is a Web site 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.
As an administrator, 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 are central to WebSphere Portal. As special reusable Java servlets 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. Portlets for accessing Lotus
Notes®, IBM Lotus® Domino® and Extended Products, IBM Lotus Sametime®, IBM Lotus Quickr®, IBM
Lotus Connections, Microsoft Exchange, and instant messaging are included. Several third-party portlets
are also available. Examples include Enterprise Resource Planning (ERP), Dashboards, Business
Intelligence, Process Management, and Customer Relationship Management (CRM) portlets. In addition,
WebSphere Portal ships an API that portlet developers can use to create custom portlets.
WebSphere Portal now includes the Lotus Mashup runtime so you can run widgets inside the portal and
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
1
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.
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.
For additional information about new features, main components, and what each component provides to
the overall solution, explore the subtopics of this section.
The following topics provide additional overview information.
What's new
Learn what's new in IBM WebSphere Portal.
IBM WebSphere Portal new features and improvements

WebSphere Portal includes new features, such as virtualization and content tagging and rating, as well as
enhancements on Page Builder and unified theme architecture, serviceability, migration and content
management among others.
ConfigEngine
A new task has been added to aid in automated log collection for problem reports opened with IBM
Support. This is in addition to the log gathering available in the ISA / ISA-lite support tools from IBM.
The ConfigEngine task does not require the installation of any additional code in order to run the log
collection.
Information portlet
There are now two Information portlets that are available. These portlets have the same function but the
original was written with the IBM API and the new portlet was written with the JSR 286 API. The new
portlet can render on both the client and server side while the original Information portlet can only
render on the server side.
Configuration wizard
The configuration wizard has been improved to make it easier to configure WebSphere Portal security
with an LDAP server. The new configuration wizard function now attempts to query the LDAP server to
provide better defaults for the various questions that need to be answered in order to successfully do an
LDAP security configuration.
2 WebSphere Portal 7.0

Learn more about the configuration wizard.
Blog and wiki
You can now easily add a blog, blog library, or wiki to a page using the Add Content widget in the Page
Builder theme. There are additional enhancements to globalization support through the utilization of new
IBM Web Content Manager API's.
Learn more about blogs and wikis.
Error reporting
To improve the "First Failure Data Capture" characteristics of WebSphere Portal for a class of problems
around heap memory usage, WebSphere Portal install will by default activate verbose garbage collection
in the WebSphere Portal JVMs. This is done by adding the appropriate settings to the JVM command line
arguments for the WebSphere Portal JVM within WebSphere Application Server, to activate the support
that is provided by the underlying JVM for writing statistics regarding Java heap garbage collection
activity to a log.
In addition, on those platforms that support it, the "log rolling" capability is activated to try to balance
capturing enough garbage collection history to be useful in debugging while conserving the amount of
actual disk space used by the logs. In normal verbose garbage collection, the log could grow without
bound. With the log rolling capability, the log is limited to a reasonable number of generations, where
each generation contains a limited number of garbage collection cycle reports. Because WebSphere Portal
is activating the support that is provided in the underlying JVM code, the details of how this support
works are documented in the appropriate Java Diagnostics Guide.
This large allocation logging is activated by a JVM command line parameter registered for the Portal
servers within WebSphere Application Server, and can be tuned or deactivated by editing or removing
the appropriate strings within the WebSphere Application Server configuration. For example, the 10 MB
threshold can be lowered to a smaller value if you suspect allocations that are "larger than expected but
not 10 MB".
Learn more about logging and tracing.
Learn more about the Java Diagnostics Guide.
Messages
Message catalog has been updated so that any new messages added have more descriptive explanations
and suggested user actions to aid in users and IBM Support problem determination procedures. In
addition to the new entries, existing common error messages have been revamped to aid in problem
determination.
Migration
Improved migration paths, now migrating from WebSphere Portal Version 6.1 is more like a software
upgrade. Database schema changes between WebSphere Portal Version 6.1 and 7.0 are automatically
processed. You can also perform in-place database upgrades.
Learn more about migration.
Multiple profiles
The virtualization technology allows you to install and configure your portal and then create multiple
profiles that you can use to create a portal farm or a clustered environment. A portal farm is a simple
Product overview 3
way to build and maintain a highly scalable, highly available server environment. It differs from the
clustered environment in that it is not maintained by a Deployment Manager.
Learn more about setting up a cluster.
Learn more about setting up and maintaining a portal farm.
Page Builder and Unified Theme Architecture
The Page Builder theme is now the default theme. The Page Builder theme has evolved into a new
unified architecture supporting portlets and widgets, as well as both server-side and client-side page
aggregation. Themes can now be fully edited and managed directly via static HTML files stored in the
WebDAV file store. Styles have been further optimized for performance and ease of customization by
exploiting the latest CSS3 features for linear gradients, drop shadows and rounded corners.
Existing Page Builder features have been improved to support the new enhanced Client Side Aggregation
architecture. The tab navigation widget, with drop-down menus, inline page creation and drag and drop
page re-ordering now supports client-side page switching without a browser full page refresh. Content
Search finds portlets and widgets to add to the page. Change Style supports and Change Layout support
static CSS and layout templates stored and configured through WebDAV.
Learn more about Page Builder.
Security
Impersonation allows a user, such as a support specialist, to access a user's workstation to test out a new
page, portlet, and so forth, and see issues as they occur on the workstation. Before you can impersonate
another user, you first must enable the impersonation feature and assign the Can Run As User role to the
appropriate user.
Learn more about impersonation and how to enable it.
Tagging and rating
Users can now tag or rate portal content and view the tags and ratings. This allows to better organize,
categorize, and find portal content, including custom content, if it is available in the portal. For example,
users can tag or rate books in an online bookstore.
Learn more about tagging and rating portal content.
Integration with workflow management systems
WebSphere Portal now provides a single point of integration with workflow management systems, such
as IBM WebSphere Process Server, through the Unified Task List. The Unified Task List is a portlet that
aggregates tasks and activities from multiple systems in a visually appealing and highly configurable
user interface. Portal users access the Unified Task List to view and claim pending tasks that they can
complete to advance workflows.
The Unified Task List is available from the WebSphere Portal Business Solutions Catalog and offers
out-of-box integration with WebSphere Process Server. However, you can customize the Unified Task List
to suit your business needs by creating unique tasks providers, or services, that access, retrieve, and
format tasks from any workflow management system.
Learn more about the Unified Task List portlet.

Virtualization
Virtualization technology can be used to mass-replicate identical operating systems installed and
configured with WebSphere Portal. VMware is fully supported in this version of WebSphere Portal.
Learn more about virtualization on Linux.
Learn more about virtualization on Windows.
Documentation improvements and changes

WebSphere Portal 7 includes more documentation improvements based on feedback from customers. Our
most exciting change is our transition to publishing the documentation in the WebSphere Portal Family
wiki.
Wiki
The wiki offers advantages to the information center. You can comment on or edit topics when you detect
an issue or see room for improvement. In the past, you have been able to submit feedback forms to IBM.
Many customers have taken the time to submit those forms, providing excellent feedback. As a result, the
documentation has been updated and improved. The new wiki delivery format means that other
customers benefit from that feedback faster.
Anyone can browse the documentation on the wiki. However to edit or comment on the content, you
must log on to the wiki using a Lotus developerWorks ID. If you already have a Lotus developerWorks
ID, your are ready to log on and add comments or edit. If you do not have a Lotus developerWorks ID,
you can quickly register and get started.
Lotus Registration
The screen capture highlights features you should know about when using the documentation.
Table 1. Screen capture legend - Do not miss these key features when using the documentation in the wiki:
Number Description
1 The breadcrumb helps you orient yourself and quickly know which documentation you are reading.
Product overview 5
Table 1. Screen capture legend - Do not miss these key features when using the documentation in the
wiki: (continued)
Number Description
2 Advanced Search opens a new screen where you can limit your search to a specific category. For
example, you can limit your search to only topics in the IBM WebSphere Portal Express 7
Documentation. You can select multiple categories or a single category. Use advanced search to find
exact phrases, search titles only, look for whole words only, and take advantage of Boolean expressions
in your search. After you search for a term or phrase, you can modify your selections and parameters
and further refine your search results.
3 The Translate page feature uses machine translation to translate all the content on the fly. Unlike many
machine translation servers, this translation server uses crowd sourcing. If you detect an inaccurate,
awkward, or confusing translation, you can correct it. Your correction is added to the translation server
and will be used for the next time the content is translated.
4 IBM still provide quality translated content. Access documentation translated by IBM translation
centers using the IBM Translated Documentation section of the navigation.
5 Use these links to quickly see the original version of the topic you are looking at.
6 Highlighting in the navigation helps you know where the current topic is in relation to other topics in
the content.
Organization
The navigation for WebSphere Portal 7 Documentation is based on task orientation to help you find
content faster. This new navigation model is more in line with other IBM products. Notice the standard
sections in the navigation such as Installing, Developing, and Troubleshooting. Additional navigation
headings were added, such as Security, Monitoring, and Setting up a portal site.
Security includes information about authentication, SSL, LDAP configuration and more.
Monitoring includes information to help you better understand usage patterns of your portal site.
Setting up a portal site combines content from to provide a more holistic view of setting up a site. It
also includes information about creating pages, adding portlets to pages, themes and skins, and
adding content to your site.
WKPLC properties
Descriptions, examples, and default values for properties have been added back to the documentation.
Find properties file documentation.
Lotus Web Content Management
If you want to set up a site that relies heavily on Web Content Management, see the IBM Lotus Web
Content Management documentation. This new documentation set combines what you must know about
WebSphere Portal and Lotus Web Content Management to set up a site.
Related information:
WebSphere Portal Family wiki
Documentation resources
The starting point for information is the product documentation. Previously the product documentation
was delivered using an information center framework. For WebSphere Portal 7.0, 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 WebSphere Portal and Lotus Web Content
Management 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 composite 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
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
Product overview 7
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
WebSphere Portal Family wiki
WebSphere Portal Support
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.
Customization
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.
Product overview 9
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
Product overview 11
v
Content Model: defines attributes about content, such as product descriptions, articles, and other
information
v
Matching Technology: engines that match users to the right 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.
Streamlined site creation

IBM WebSphere Portal comes with pre-built, sample internet and intranet websites that you can explore
to learn about authoring and managing different types of content, or use as a template to streamline
development of your own portal. You can also use the New Site Wizard to generate your own portal site.
Sample sites
The sample intranet and internet sites are not automatically installed when you install WebSphere Portal,
but you can add them after installation completes by running the configure-express task before you
configure the portal database, user registry, context root, or security. For more information, see the
instructions on setting up a stand-alone server or a clustered server on your particular platform.
You can access the sample intranet and internet sites through the More menu in the main portal banner,
or by opening the appropriate URL in a browser:
v Intranet sample site: http://hostname.example.com:10039/wps/portal/intranet

v Internet sample site: http://hostname.example.com:10039/wps/portal/internet
Use the intranet site template as a starting point for creating your own employee site. Home, Work, and
Resources pages come seeded with placeholder content that you can use as is or customize. Easy to use
list portlets let you organize and manage announcements, news, events, FAQs, and links.
Use the internet site template to get a jumpstart on building a website where customers can learn about
product offerings, marketing promotions, and company news.
More content samples are available on the IBM WebSphere Portal Business Solutions Catalog.
Product overview 13
Creating portal sites on demand
Use the New Site Wizard to generate your own site – without needing any portal development skills or
assistance from an administrator. Just select a site template from the available samples, choose the look
and feel you want, and then let the wizard do the rest.
The wizard automatically creates new sites as virtual portals; however, administrators and developers can
extend the wizard to create any type of portal site. Portal developers can also enhance the New Site
Wizard by creating custom site templates, and then adding them to the wizard.
Download the New Site Wizard from the IBM WebSphere Portal Business Solutions Catalog. Package
contents include the portlet .war (Web Application Archive) file, supporting files and directories, and
detailed instructions in a .pdf file. After deploying the wizard, you need to add the portlet to a page that
users can access. For more information, see the .pdf file that comes with the wizard.

IBM WebSphere Portal Business Solutions Catalog
IBM New Site Wizard
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.
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.
Product overview 15
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
WebSphere Portlet Factory is included with WebSphere Portal and provides a robust selection of builders
that supercharge the portlet development process without writing code. WebSphere Portlet Factory's
rapid application development technology enables portlet creation 40 – 70 percent faster than using
traditional J2EE development methods. With WebSphere Portlet 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. WebSphere
Portlet 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. Native WebSphere Portal integration enables creation of composite applications with
embedded collaboration features that facilitate real-time problem resolution.
Using WebSphere Portlet 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
WebSphere Portlet Factory can be deployed to multiple run-time environments to provide the right user
experience based on target audience, including WebSphere Portal, Mashup Center, Lotus Notes and
Expeditor and WebSphere Application Server.
WebSphere Portlet Factory applications are standards based and comply with portlet standards including
JSR 168 and JSR 286.

Related concepts:
“Developing portlets” on page 3081
Get an overview of the process of creating portlets, learn about the concepts of the APIs used to develop
portlets, and view the samples to get you started. Also, learn about integrating features such as single
sign-on, cooperative sharing of information using the property broker, and migrating Struts applications
to the portlet environment.
“Portlet services” on page 3127
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.
Related reference:
“Standard portlet API” on page 3124
The Java Portlet Specification addresses the requirements of aggregation, personalization, presentation,
and security for portlets running in a portal environment.
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 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 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.
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.
Product overview 17
– 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.
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 described above, 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 listed above.
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:
“Searching for tagged content” on page 2273
Users can search the tag space by using the browser search box.
“Extending tagging and rating by using service APIs” on page 3444
Developers can enhance and extend the tagging and rating features of the portal. For this purpose the
portal tagging and rating feature provides service APIs that you can use to enhance tagging and rating
by your requirements.
“Tagging and rating” on page 2249
Get an overview of the administrative tasks related to tagging and rating.
Related reference:
“How tagging and rating works in the portal” on page 2250
Use this topic for administrative information about tagging and rating in the portal.
“The tagging and rating user interface” on page 2255
Portal tagging and rating provides two different user interfaces.
“Configuration reference” on page 2278
This chapter provides useful information for developers for customizing the default tagging and rating
user interfaces. The parameter reference lists and explains all available configuration parameters and their
values. The topic about CSS provides information about how to change the design of the default user
interfaces.
“Allowing your own custom content to be tagged and rated” on page 2274
You can enable your own custom content to be tagged and rated by your users. To allow users to tag and
rate your own custom content, you need to integrate the necessary user interface elements and
implement some additional service interfaces.
“Tagging and rating for static pages” on page 2272
To add tagging or rating to static pages, you ad the tagging or rating widget to the HTML code.
“Security for tagging and rating” on page 2290
For administering which users can tag and rate content, the portal provides virtual resources for tagging
and rating and roles on these virtual resources.
“Hints and tips for tagging and rating” on page 2295
Learn about some hints and tips that apply to tagging and rating.
“Using the XML configuration interface to administer tags and ratings” on page 2291
You can use the XML configuration interface to manage tagging and rating in the portal. For example,
you can move tagspaces and ratings between portal versions or for staging purposes.
“CP Configuration Service for tagging and rating” on page 1676
The CP Configuration Service provides the parameters for tagging and rating.
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.
Product overview 19
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.
Related concepts:
“Learn about the template libraries used by wikis” on page 2952
Wikis use the template libraries provided by IBM Web Content Manager. Wikis use the Wiki Resources
template and the Wiki template. The page hierarchy that is provided for wikis is the common one
defined by the Web Content Manager template libraries.
“Learn about the template libraries used by blogs and blog libraries” on page 2949
Blogs and blog libraries use the template libraries provided by IBM® Lotus Web Content Management.
Blogs use the blog resources and blog solo templates. Blog libraries use the blog resources and blog
templates. The page hierarchy that is provided for these components is the common one defined by the
Web Content Management template libraries.
Related tasks:
“Adding blogs to the site” on page 2948
Use blogs and blog libraries to provide news and commentary on a variety of subjects pertinent to your
intranet and extranet sites. Blogs and blog libraries typically combine text with graphics and links to
other blogs and Web sites. Entries that you create and post are arranged in reverse-chronological order,
with the newest entry displayed first. Readers can post comments about your entries, fostering
discussions and online networking. You can manage your own blog entries and comment on other blog
entries.
“Adding wikis to the site” on page 2952
Use wikis to share community content on a variety of subjects pertinent to your intranet and extranet
sites. Wikis typically combine text with graphics and links to other wikis and Web sites. You can monitor
and manage your own wiki articles.
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.
Collaboration
Collaboration features in IBM WebSphere Portal are provided through the Domino and Extended
Products Portlets. Domino and Extended Products are the Domino Enterprise server and IBM Lotus
Sametime.
Portlets are the mechanism by which the Domino server products are fully integrated into WebSphere
Portal. Domino and Extended Products Portlets provide an online directory with people awareness, and
integrated tools for managing online meetings. All these collaboration features help people in your
organization work together and share information online to achieve their business goals. A collaborative
portal can improve your organization's responsiveness, innovation, competencies, and efficiency.
For information on supported versions of IBM Lotus Domino and IBM Lotus Sametime, see the
WebSphere Portal detailed system requirements.
Collaborative Portlets
Examples of all the Domino and Extended Products Portlets are supplied on the Collaboration page and
on the Messaging page. The portlets are installed with WebSphere Portal and deployed automatically,
requiring of the administrator only a number of server and other configuration tasks before users can
take advantage of a suite of integrated collaborative applications.
Domino and Extended Products Portlets include:

v iNotes®
v Sametime Contact List
v Lotus Notes View
v People Finder
v Who Is Here
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, composite applications, 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 Lotus 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 Lotus 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.
Product overview 21
Related concepts:
“Integrating with collaboration software” on page 1735
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 which WebSphere Portal integrates includes IBM Lotus Domino, IBM Lotus Sametime, and
IBM Lotus Quickr.
“People awareness” on page 1810
People awareness makes people's names appear as hyperlinks that users can click to display information
about the individual and gain access to actions for contacting and working with him or her. If the
administrator has configured an IBM Lotus Sametime server to work with WebSphere Portal, users can
see each other's online presence in their person links according to the status options they have set in their
Lotus Sametime client (for example, whether the person is active, away, offline, or does not want to be
disturbed). The person's online status appears only if Lotus Sametime is enabled.
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 could induce epileptic seizures
v Provides documentation in an accessible format
Note: For best results when using a screen reader to view WebSphere Portal, use Freedom Scientific
JAWS 11 or higher and Firefox 3.5 or higher.
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 IBM Human Ability and Accessibility Center for more information about the commitment that
IBM has to accessibility:

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

Exchange, Domino, and POP3 are no longer supported protocols in the Common Mail portlet.
If you had been using CPP with Exchange, you can now use the Exchange portlets
If you had been using CPP with Domino, you can now use the iNotes portlet.
RSS portlet and IBM Feed Reader portlet are no longer shipped.
If you had been using RSS Portlet or IBM Feed Reader Portlet, you can now use IBM Syndicated
Feed Portlet for WebSphere Portal. Alternatively, you can download the RSS portlet and IBM
Feed Reader portlet from IBM WebSphere Portal Business Solutions Catalog.
The Common Calendar portlet is no longer being shipped.
If you had been using CPP with Exchange, you can now use the Exchange portlets
If you had been using CPP with Domino, you can now use the iNotes portlet.
Document Manager
With this version of WebSphere Portal, Document Manager is no longer available. If you need to
keep using a document library, then you will need to move your document library to a IBM
Lotus Quickr server. See the WebSphere Portal Best Practices Wiki for further information.
Workflow for composite applications
Workflow for composite applications is no longer supported in this version.
Integration with WebSphere Process Server using the WebSphere Process Server Client and the My
Processes and My Tasks portlets
The integration with WebSphere Process Server using the WebSphere Process Server Client and
the My Processes and My Tasks portlets is being deprecated. It will be no longer supported in
future releases. Instead, the integration with Process Server can be achieved using the IBM
WebSphere Portal Unified Task List portlet, which simplifies the system setup and improves
consumability.
Collaborative portlets
The following collaborative portlets are no longer included with WebSphere Portal:
v My Lotus QuickPlaces
v Inline QuickPlace
v Domino Document Manager
v Lotus Web Conferencing
Note: My Lotus QuickPlaces can be downloaded from the IBM WebSphere Portal Solutions
Catalog. For more information, refer to the related topic IBM WebSphere Portal Solutions Catalog.
Legacy sample portlets
The following legacy sample portlets are no longer provided:
v SPFLegacyBlank.war
v SPFLegacyClock.war
v SPFLegacyCommandManager.war
v SPFLegacyEditMode.war
Product overview 23
v SPFLegacyFileUpload.war
v SPFLegacyLookupAction.war
v SPFLegacyMailReader.war
v SPFLegacyMultipleServletContexts.war
v SPFLegacyStockQuote.war
v SPFLegacyTiles.war
v SPFLegacyTransformation.war
Microsoft Exchange 2000 portlet application
The Microsoft Exchange 2000 portlet application is no longer included. This portlet application
contained the following portlets:
v MS Exchange 2000 Mail Portlet
v MS Exchange 2000 Calendar Portlet
v MS Exchange 2000 Tasks Portlet
v MS Exchange 2000 Contacts Portlet
v MS Exchange 2000 Notes Portlet
Transcoding technology
The transcoding technology previously provided with WebSphere Portal has been discontinued
with this version.
Browser support
The following browsers are no longer supported in this version:
v Mozilla
v Netscape
JACL syntax for the Portal Scripting Interface
The JACL syntax for the Portal Scripting Interface has been replaced by Jython syntax. The JACL
syntax is still supported, but this support will be discontinued in the future.
HP UX
HP UX is no longer supported in version 7.0.
Deprecated features
IBM Portlet API web content viewer portlet
The web content viewer portlet based on the IBM Portlet API has been deprecated in version 7.0
and replaced with the JSR 286 web content viewer portlet.
IBM Portlet API remote web content viewer portlet
The remote web content viewer portlet based on the IBM Portlet API has been deprecated in
version 7.0. To display web content on a portal where Web Content Manager is not installed, use
WSRP and the JSR 286 web content viewer. If you need to display web content from a remote
Web Content Manager system earlier than version 7.0, you can continue to use the IBM API
remote web content viewer portlet from the remote server.
IBM API Rendering Portlet
The IBM API Rendering Portlet has been deprecated in Portal version 7.0.
Private wire APIs
The WireModel artifacts referring to private wires have been deprecated.

Related tasks:
Solutions Catalog: WebSphere Portal
Deprecated features
Product overview 25
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.
Attention: After installing WebSphere Portal and if you plan to use Mashup integration, you will need
to run the deploy-portal-mashup-ui task listed in the Mashup integration > Configuring your portal
and mashups > Enabling mashup integration in your portal topic.
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.
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:
http://www.ibm.com/support/docview.wss?uid=swg27007791
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
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.
The following links will return the most current list of technotes for the identified area. If a technote has
not been published for a given topic area, the link will not return any technotes and you will be
instructed to refine your search.
Technotes for installation and configuration issues
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0
&tc=SSCPKQ9+SSC3QNP
Technotes for migration issues
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0&tc=SSCPKQB
Technotes for database connectivity issues
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0&tc=SSC3QNK
27
All technotes for this release
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0
You can also search the Support site directly from the information center. See the Search the IBM support
Web site for a solution topic.
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 WebSphere Portal release, of all known "Unsupported Products" published on the web 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 7.0 to 7.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 6.1 to 7.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 7.0 installed and functioning on
WebSphere Application Server version 7.0 cannot be successfully migrated to WebSphere
Application Server version 7.1 simply by using the WebSphere Application Server Migration
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:
Installing 29
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. For more information on system requirements, see
the link below. 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. For more information on system
requirements, see the link below. 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 lower case characters, upper case characters, numbers,
and the underscore.
Lower case characters {a-z}
Upper case 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 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: (UNIX 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 table below contains a list of the required fields on the user information form and the supported
characters.
Installing 31
Table 2. Valid characters and unsupported characters for user information
User information Valid characters Unsupported characters
User ID Note: The only supported characters Only ASCII characters are allowed.
in IBM i are lower case characters, Other restrictions: The user ID
upper case characters, numbers, and cannot contain spaces; for example,
the underscore. user name. User IDs cannot be longer
Lower case characters {a-z} than 200 characters.
Upper case characters {A-Z} If you enter any unsupported
Numbers {0-9} characters during the installation, you
Exclamation point {!} will receive an error message that
states which character is invalid. For
Open parenthesis {(}
example, "The special character [@]
Close parenthesis {)} was found in the administrative user
Dash {-}; this character is not ID field. Enter the administrative
supported as the first character in user ID again."
the user ID or password Important: You will receive a
Period {.}; this character is not different error message if you enter
supported as the first character in any unsupported characters when
the user ID or password creating users through the Manage
users and groups portlet.
Underscore {_}; this is the only
supported special character in i
Grave accent {`}
Tilde {~}
Commercial at {@}, this character
is not supported when creating
the WebSphere Portal and
WebSphere Application Server
administrator during installation.
Password / Confirm password Note: The only supported characters Diacritics, such as the umlaut, and
in IBM i are lower case characters, DBCS characters are not allowed.
upper case characters, numbers, and Other restrictions: The password
the underscore. cannot contain spaces; for example,
Lower case characters {a-z} pass word. Passwords cannot be
longer than 128 characters.
Upper case characters {A-Z}
Numbers {0-9} Attention: Login will fail if the
Exclamation point {!} password contains any unsupported
Open parenthesis {(} characters, including DBCS
characters. This will happen even if a
Close parenthesis {)}
user is successfully enrolled using a
Dash {-}; this character is not password containing DBCS
supported as the first character in characters.
the user ID or password
Period {.}; this character is not If you enter any unsupported
supported as the first character in characters during the installation, you
the user ID or password will receive an error message that
states which character is invalid. For
Underscore {_}; this is the only
example, "The special character [@]
supported special character in i
was found in the password field.
Grave accent {`} Enter the password again."
Tilde {~}
Commercial at {@}, this character
is not supported when creating
the WebSphere Portal and
WebSphere Application Server
administrator during installation.

Table 2. Valid characters and unsupported characters for user information (continued)
User information Valid characters Unsupported characters
First Name All characters n/a
Last Name All characters n/a
Note: The above 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 below 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 1638
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 Web Content
Management 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 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.
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 Derby that is unsuitable for production use and must be replaced by
an enterprise class 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 graphic below, 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 will participate 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.
Installing 33
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.
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.
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 88
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 administrative
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.
Installing 35
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.

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.
Installing 37
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.

“Database considerations” on page 59
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 386
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 513
already exists.
“Installing multiple clusters in a single cell on Linux” on page 792
already exists.
“Installing multiple clusters in a single cell on Solaris” on page 1075
already exists.
“Installing multiple clusters in a single cell on Windows” on page 1351
already exists.
Portal farm topology

A portal farm topology has a series of identically configured, standalone server instances. Server farms
offer a very simple way to build and maintain a highly scalable, highly available server environment.
Installing 39
Restriction: This feature does not apply to Express editions or Enable edition when installed on z/OS®.
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 below 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 below 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.
Installing 41
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
group information and participates seamlessly in the same single sign-on strategy.
“Using remote search service” on page 2134
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 103
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 1614
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 Lotus Web Content Management 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 1361
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 below under
Related concepts for additional information.
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 1614
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 Lotus Web Content Management 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
Installing 43
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.
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 1362
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 Management

Organizations that only need a small Web site or intranet site could implement a single server topology
for Web Content Management. 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 Management. A
Web server routes incoming requests from browser clients. Web Content Management, WebSphere Portal,
and 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 Management 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 will be resource intensive, so the type
of environment you deploy will need 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 Management

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 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 Web Content Management. 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 Management.
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
Installing 45
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:
– 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 JSR 286 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 50
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 55
A delivery environment is used to deliver content to your web site viewers.
Staging-server topology for Web Content Management

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 user acceptance testing (UAT) 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 and database servers. 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 47
– 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 JSR 286 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 topologies

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 49
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 all the above.
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. 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. For example:
Installing 51
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 53
Related concepts:
“Dual-server configuration for Web Content Management” on page 45
Web content testing environments

This environment is used by your UAT testers and can be as simple as an individual UAT 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 UAT 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
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
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 web site 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.
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.
Installing 55
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.
Remote web content viewer delivery
WSRP support in the JSR 286 web content viewer is used to display content on a remote WebSphere
Portal server or cluster.

Related concepts:
“Dual-server configuration for Web Content Management” on page 45
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 Application Server administrative 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 administrative 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 mashup integration.
i users: For detailed information on using an external web server with your 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 WebSphere Portal is running
Installing 57
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.
After configuring WebSphere Portal to use an external web server, you will 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.
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, as described below.
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 Application Server administrative console. If you
are using the web server in a clustered environment, use the deployment manager administrative console
to perform these steps.
1. Select 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 (for example, *:10039). If the entry does not exist, select New,
and enter the information for the host name and port you want to use.
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
machine.
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
administration console after you federate the node.

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.
The Derby database that is installed by default is not intended for use in a production environment or for
authoring web content. 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.
Installing 59
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 3. 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 Yes Yes Yes Yes Yes Yes
database
Read on all Yes Yes Yes Yes Yes Yes
tables
Write on all Yes Yes Yes Yes Yes Yes
tables
Update on all Yes Yes Yes Yes Yes Yes
tables
Delete on all Yes Yes Yes Yes Yes Yes
tables
Create tables No No No Yes No No
Create indexes No No No Yes No No
Use of No No No Yes Yes No
sequences
Table 4. List of privileges held by database configuration users for all database domains.
Permission
within the
database
Access to the Yes Yes Yes Yes Yes Yes
database

Table 4. List of privileges held by database configuration users for all database domains. (continued)
Permission
within the
database
Read on all Yes Yes Yes Yes Yes Yes
tables
Write on all Yes Yes Yes Yes Yes Yes
tables
Update on all Yes Yes Yes Yes Yes Yes
tables
Delete on all Yes Yes Yes Yes Yes Yes
tables
Quota on disk Yes Yes Yes Yes Yes Yes
to create new
objects
Create table Yes Yes Yes Yes Yes Yes
spaces
Drop table Yes Yes Yes Yes Yes Yes
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 Yes Yes Yes
Drop triggers Yes Yes Yes Yes Yes Yes
Create No No No Yes Yes No
sequences
Use of No No No Yes Yes No
sequences
Create types No No No Yes No No
Drop types No No No Yes No No
Create views No No No Yes 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.
Installing 61
Figure 1. Options for setting up databases
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.

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 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. Porltet
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.
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's 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
Installing 63
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, such as Composite
Application instances. 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
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 i.
v Other database management systems that are supported by WebSphere Portal can be configured to
work with any portal platform.
“Deleting passwords from properties files” on page 2695
The configuration tasks may 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 65
Figure 2. Local database environment
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).
Figure 3. Remote Database Environment (JDBC type 2 connection)
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.

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 reldb Depends on the number of users and portal objects,
such as pages and portlets.
Used for the portal (at a minimum) or to commdb
hold all data. Stores information about user custdb
customization, such as pages, and user
profile and login information.
Personalization,Web Content Manager jcrdb Depends on the number and size of Personalization
rules and campaigns, and the number and size of
Contains documents, personalization rules, items and elements created in Web Content Manager.
personalization campaigns, and document
library configuration information.
Feedback fdbkdb Depends on the amount of traffic to the site. The
amount of data that is logged per login-enabled page
Contains the information that is logged by can vary.
your Web site for analysis of site activity
and generating reports.
LikeMinds lmdb Depends on the amount of traffic to the site.
Contains the recommendations to be

displayed to users when their interactions
with your Web site have been analyzed
and predictions generated.
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 67
Table 7. Tables and objects owned by database users
Application Database user placeholder Function
WebSphere Portal releaseusr Core user who owns approximately
230 tables, used for WebSphere Portal
communityusr
core objects, which includes tables
customizationusr 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 right for you?
“System requirements” on page 27
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.
Figure 5. Local database environment
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.
Installing 69
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.


communityusr
made to pages.
on usage.
usage.
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 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.
Installing 71
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.
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 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 i data. It
works equally well with 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 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.

Table 10. Space required for various databases (continued)

communityusr
made to pages.
on usage.
usage.
Related tasks:
http://www.ibm.com/support/docview.wss?rs=688&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 install DB2 for z/OS to use as the database for WebSphere Portal, consider the
following:
Installing 73
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.
– 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)

– 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.
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.
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.
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 relzos Depends on the number of WebSphere
Portal users and portal objects, such as
Used for WebSphere Portal (at a minimum) or commzos
pages and portlets.
to hold all data. Stores information about user custzos
customizations, such as pages, and user
Personalization, Web Content Manager jcrdbzos Depends on the number and size of
Personalization rules and campaigns, and
Contains documents and other content, the number and size of items and
personalization rules, personalization elements created in Web Content
campaigns, and document library Manager.
configuration information.
Feedback Database: fdbkzos Depends on the amount of traffic to the
site. The amount of data that is logged
Contains the information that is logged by Table space: fdbkdbts
per login-enabled page can vary.
your Web site for generating reports for
analysis of site activity.
Installing 75
Table 12. Applications, database names, and space required (continued)
LikeMinds Database: lmdbzos Depends on the amount of traffic to the
site.
Contains the recommendations to be Table space: lmdbts
with your Web site have been analyzed and
predictions generated.
communityusr
made to pages.
on usage.
usage.
3. 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 14. 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.

Table 14. Examples on how to create a TEMP database and a TEMP tablespace by database version (continued)
Database version Example
DB2 for z/OS Version 9 in a non-data sharing The TEMP database is DSNDB07 and is created during
environment 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:

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 below. On Oracle, a single database configuration can significantly reduce
Installing 77
consumption of system resources by the database management system. Using separate table spaces for
all databases listed below can improve scalability and performance.

communityusr
made to pages.
on usage.
usage.

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 below. 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 listed below can improve scalability and performance.

Installing 79
communityusr
made to pages.
on usage.
usage.
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.

Table 19. Space required for various databases (continued)

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 20. Information by application, database schema placeholder, recommended name, and function
Application Database schema Recommended name Function
placeholder
WebSphere Portal v releaseusr <none> Core schemata. Will own
approximately 130 tables
v communityusr
for each domain. Owns
v customizationusr WebSphere Portal core
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
approximately 50 tables
used for logging site and
personalization usage.
Likeminds LIKEMINDS <none> LikeMinds schema. Will
own approximately 15
tables used to hold the web
site usage analysis routines
Installing 81
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 1768
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 21. 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.
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.
Custom security This option provides you with the ability to write a full
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 wp-modify-ldap-security task to switch to a standalone 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
perform any of the following optional tasks to fine-tune your standalone LDAP user registry:
Installing 83
Table 22. 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 Choose this option to store additional attributes inside
lookaside database 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 23. Tasks to enable a production repository
Task Description
Add a federated LDAP repository to the VMM Select this option to add an LDAP server to the federated
configuration 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 Select this option to add a database to the federated
configuration 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 24. Tasks required to remove the default file-based repository
Task Description
Change the user registry where users and groups are This task changes the default repository where new users
stored 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 This task deleted the default file-based repository from
configuration 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 25. 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.
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 Choose this option to store additional attributes inside
lookaside database 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.
Installing 85
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)
Sample custom adapters for federated repositories examples
Related tasks:
“Setting up custom user repositories” on page 2662
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 7.0 Information Center, VMM API
WebSphere Application Server 7.0 Information Center, Sample custom adapters for federated
repositories examples
WebSphere Application Server 7.0 Information Center, Repository SPI (System programming
interfaces for virtual member manager adapters)
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.
Installing 87
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.
“Clustered servers topology” on page 34
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 1200
Clusters enable you to scale your 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.
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.
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.
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
– UNIX: Selecting a Web server topology diagram and road map
– i: Selecting a Web server topology diagram and road map
Installing 89
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
– UNIX: Task overview: Managing HTTP sessions
– i: Task overview: Managing HTTP sessions
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 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 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
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 standalone node before creating a cluster; you can no longer
install WebSphere Portal into a managed node.
v 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 clustered environment.
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 Application Server administrative 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 performs 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 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 will fail.
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 i: Distributed session support
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.
Installing 91
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.
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 will remain
intact after failover.
During a failover condition, a Web Content Management 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 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
clustered environment.
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 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 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 i horizontal cluster to use a local
database for the primary node instead.
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 93
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.
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 Application Server administrative 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 2081
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's 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 will be 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 IBM WebSphere Application Server Administrative 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 Application Server Administrative Console to configure or update the
out-of-box security is NOT supported in a stand-alone environment. This is only supported in a clustered
environment that uses the Deployment Manager Administrative 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 will 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,
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.
Installing 95
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. Perform 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 2669
– Computer Associates eTrust SiteMinder: “Configuring eTrust SiteMinder for authentication and
authorization” on page 2687
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 individual 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 at
a later time that overwrites the WebSEAL junction, the WebSphere Application Server TAI properties
are not automatically updated, so you must manually ensure that all nodes are using the same
parameters. To manually ensure the nodes are the same, use the Deployment Manager administrative
console and navigate 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.
This value can be set globally for all cluster members by using the
com.ibm.websphere.security.webseal.configURL property, accessed in the Deployment Manager
administrative console by clicking 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 as
specified in the administrative console.
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.
eTrust SiteMinder cluster considerations
Ensure that you have installed and validated the eTrust SiteMinder binaries on each node in the cluster.
If you are only using eTrust SiteMinder for authentication, install and validate the Application Server
Agent.
If you are using eTrust SiteMinder for authentication and authorization, both the Application Server
Agent and the SDK must be installed and validated.
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 (Administrative 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 cell’s 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
Installing 97
Node A cell has one or more nodes, and each node is named and matches with some WebSphere
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, in the above diagram, 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 cell’s 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 WebSphere Process Server, the
server should be centralized within its own cluster, and the client install option of WebSphere
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 i; therefore, you must install WebSphere
Virtual Enterprise on a remote non-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 cluster’s 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 99
Table 26. 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.
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.
For each node that will be 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 below 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 below 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 below 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 have been completed will
insure 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.
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.
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.
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. You do not need to remove
the node from cluster to apply minor fixes; doing so may result in the inability to add the node back to
the cluster. 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
Installing 101
the case, use a procedure that ensures 24x7 availability.
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.
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 operate
above it.
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 will be 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 above 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 utilization 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.

Related tasks:
“Localizing a new virtual machine instance on Linux” on page 801
If you are using VMware ESX, you can create a virtual environment that will allow you to create virtual
machine instance. When a new virtual machine instance is created, you need to 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 1360
Multiple profile support

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.
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 different profile types can be generated:

portal.default
This is a profile holding a standalone portal server in the captured configuration. It may 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 right away 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 execute 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
Installing 103
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.

Related tasks:
“Supporting multiple profiles” on page 2090
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 2090
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.
“Creating and maintaining multiple profiles on IBM i” on page 2098
“Creating and maintaining multiple profiles on Linux” on page 2104
“Creating and maintaining multiple profiles on Solaris” on page 2112
“Creating and maintaining multiple profiles on Windows” on page 2120
“Portal farm considerations” on page 41
Installation methods, options, and sources

There are multiple installation methods (silent, graphical user interface, and console), options (base or
full), and sources (DVD or DVD images).
Installing 105
Related tasks:
“Installing WebSphere Portal on AIX on the primary node” on page 236
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.
“Installing WebSphere Portal on AIX on the additional cluster nodes” on page 366
Install IBM WebSphere Portal on your additional cluster nodes to create a highly available and scalable
environment.
“AIX stand-alone: Installing WebSphere Portal” on page 115
authentication.
“IBM i cluster: Installing WebSphere Portal” on page 446
authentication.
“Installing WebSphere Portal on IBM i on the additional cluster nodes” on page 501
environment.
“IBM i stand-alone: Installing WebSphere Portal” on page 397
authentication.
“Linux cluster: Installing WebSphere Portal” on page 642
authentication.
“Installing WebSphere Portal on Linux on the additional cluster nodes” on page 773
environment.
“Linux stand-alone: Installing WebSphere Portal” on page 523
authentication.
“Solaris cluster: Installing WebSphere Portal” on page 923
authentication.
“Installing WebSphere Portal on Solaris on the additional cluster nodes” on page 1056

environment.
“Solaris stand-alone: Installing WebSphere Portal” on page 804
authentication.
“Windows cluster: Installing WebSphere Portal” on page 1202
authentication.
“Installing WebSphere Portal on Windows on the additional cluster nodes” on page 1332
environment.
“Windows stand-alone: Installing WebSphere Portal” on page 1085
authentication.
Installation options
There are two types of installation: full and base.
Choose one of the following installation options:
Note: The bit architecture of the IBM WebSphere Portal installation program will follow the bit
architecture of the Operating System or if WebSphere Portal is being installed into an existing supported
IBM WebSphere Application Server, the installation will follow the bit architecture of the WebSphere
Application Server. For example, if you are installing onto a 64-bit Linux, WebSphere Portal will install as
a 64-bit version. You can force a 32-bit application installation onto a 64-bit operating system; see
Installation methods for information.
Base Select this option to deploy a base set of WebSphere Portal features. This option allows you to
selectively enable additional features, samples, and developed content after installation to create a
deployment that meets your business needs.
Full Select this option to deploy the full set of WebSphere Portal features and samples that are
available for your offering. This option allows you to use and test a wide range of features or to
develop a proof-of-concept deployment.
WebSphere Portal provides a portal light mode which can improve portal start up time and reduce
memory consumption in production environments; see Configuring WebSphere Portal > Configuring
portal behavior > Using portal light mode for information.
Installing 107
Related tasks:
“Using portal light mode” on page 1599
Portal now provides a portal light mode which can improve portal startup time and reduce memory
consumption in production environments.
“Adding features to a base installation” on page 1731
If you install the product using the Base option, you can add additional features as you need them. Not
all additional features can be added to all base installation types.
Installation methods
Select the appropriate installation method for your environment. You can use either a graphical interface
program, console mode, or a response file for a silent installation.
Graphical user interface
The graphical user interface program gathers essential information, such as host name and node,
and then performs the installation. Some operating systems do not support a graphical user
interface.
Console mode
The console mode is a textual representation of the graphical user interface program. Enter a
number that corresponds to your selection and then press Enter to proceed through the
installation.
Silent installation
The silent installation uses a response file to supply installation options without user interaction.
Use this option when installing or uninstalling IBM WebSphere Portal on multiple machines with
a similar setup. To configure the installation, change the options in the response file before
issuing the installation task.
Installation notes: Read the following information before installing:

v Applies to all installation methods:
– Before you begin installing or uninstalling, disable or turn off any screen saver software that is
running on the machine. This software can affect the ability of the machine to connect to the
network and sometimes interfere with the operation of the installation program.
– The installation program verifies the operating system and its prerequisites, available disk space,
and any required software prerequisites prior to 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 installation directory that you specify must NOT contain any files.
– The installation directory that you specify must NOT contain the following characters:
~
!
@
#
$
%
^
&
*
(
)
_
+

{
}
|
<
>
?
`
=
[
]
;
'
,
.
"
v Applies to both the graphical user interface and the console mode methods:
If the host name displays incorrectly, for example serve1.server1.rtp.raleigh.ibm.com, you must
correct the information; for example, change serve1.server1.rtp.raleigh.ibm.com to
server1.rtp.raleigh.ibm.com.
Note: This behavior is only found when the installation is run on a Windows server where an instance
of Microsoft Exchange server is already installed.
v Applies only when using the graphical user interface:
When a dialog is displayed and you must enter text, you must use either your pointing device or
press the TAB key to move between the entry fields.
32 bit installation on 64 bit operating system
Choose one of the following methods to install a 32 bit installation on a 64 bit operating system:
Table 27. 32 bit installation on a 64 bit operating system methods
Method Instructions
Manual installation Manually install the 32- bit IBM WebSphere Application
Server product. Then install WebSphere Portal into the
existing WebSphere Application Server installation.
Command-line installation Enter the install.bat|sh -W defaults.force32bit=true
command to install a 32- bit WebSphere Application
Server and WebSphere Portal on a 64- bit operating
system.
Note: This command is not supported on zLinux and
IBM i operating systems.
Important for IBM i: If you use IBM i and a J9 32- bit
JVM, you can enter the -W
enableClassicJVM.active=false parameter to install the
server with J9 32- bit JVM instead of Classic 64- bit JVM.
Installation source location

Before installing IBM WebSphere Portal, choose the installation source location and method that best fit
your environment. For example, you can install from the DVD-ROM or from a file system and you can
install using the graphical interface program or perform a silent installation.
Installing 109
Note: You must download, extract, and install the disc images on the same platform that is supported by
that image. For example, if you are preparing to install on a Linux platform, you must download, extract,
and install the Linux images on a Linux system.
You should take your local environment into consideration when choosing an installation source because
installation time can vary. Choose one of the following source locations:
Downloaded installation media
If you downloaded the installation media from IBM Passport Advantage, you must extract each
downloaded images into the same directory. This is particularly important if you are performing
a silent installation. If all the images are not extracted to the same directory, the silent installation
process will stop when it cannot find the required directory.
Install from the DVD
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 an installation path if a file server is not available or is slower than the DVD
Linux note: For security reasons, some Linux versions, such as Red hat Enterprise Linux Version
5, prevent programs from executing from automounted DVDs. If this is the case on your system,
you will be unable 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 the system's file system table.
Copy DVD content to a local machine
This option is not dependent on network or DVD-ROM speed and is best if repeatedly installing
the same product on the same machine:
Perform the following steps to copy DVD content to a local machine:
1. Create a directory for the product; for example, /wpversion_number
2. Copy the DVD into its own directory; for example: /wpversion_number/OS_code-Setup
The operating system codes are:
v AIX® (32-bit and 64-bit) = A
v IBM i = I
v Intel Linux (32-bit and 64-bit) = IL
v PowerPC Linux (32-bit and 64-bit) = PL
v zLinux (64-bit) = ZL
v Solaris (32-bit and 64-bit) = SS
v Solaris (64-bit) = SO
v Windows (32-bit and 64-bit) = W
Note: (UNIX only) After copying the content, set read and execute permissions for users doing
the installation.
Copy DVD content to a file server
Installing from a network drive may be faster than from a DVD-ROM drive; review your network
and hardware options to determine the best choice
Perform the following steps to copy DVD content to a file server:
Note: When installing WebSphere Portal on a Windows client using this method, you must
mount the file server to a drive letter. The install will not work from a UNC resource
(//servername/mountpoint), which does not have an assigned drive letter. You may also need to
add your network file server to the Windows list of trusted sites to suppress security prompts
during the installation.

1. Create a directory for the product; for example, /wpversion_number
2. Copy the DVD into its own directory; for example: /wpversion_number/OS_code-Setup
The operating system codes are:
v AIX (32-bit and 64-bit) = A
v IBM i = I
v Windows (32-bit and 64-bit) = W
Note: (UNIX only) After copying the content, set read and execute permissions for users doing
the installation.
Advanced installation parameters

You can add the following parameters to your installation command to customize your installation to
meet your business needs.
Display the Ports Configuration panel

-W adminPortBlock.active=false -W portalPortBlock.active=false
Add this parameter to the GUI or console mode installation command to display the Ports
Configuration panel in the GUI or console mode installation program.
Specify the WebSphere Application Server port range

-W adminPortBlockInput.startingPortToScan=port number -W
adminPortBlockInput.endingPortToScan=port number -W adminPortBlockInput.portBlockSize=block
size
Add this parameter to the silent installation command to specify the WebSphere Application Server
port range to scan for and the port block size.
Note: By default the installation program starts scanning for active ports at 10000 and ends at 65000
for WebSphere Application Server.
Note: The block size cannot be less than 25 ports for WebSphere Application Server.
Specify the IBM WebSphere Portal port range

-W portalPortBlockInput.startingPortToScan=port number -W
portalPortBlockInput.endingPortToScan=port number -W portalPortBlockInput.portBlockSize=block
size
Add this parameter to the silent installation command to specify the IBM WebSphere Portal port
range to scan for and the port block size.
Note: By default the installation program starts scanning for active ports at 10000 and ends at 65000
for WebSphere Portal.
Note: The block size cannot be less than 25 ports for WebSphere Portal.
Installing 111
Specify a specific PortalServer and AppServer installation location
-W was.location="/proj/WebSphere/portal/AppServer" -W portal.location="/proj/WebSphere/portal/
PortalServer" -W setNewWasInstallLocationValue.active="false"
Add these parameters to the install command to customize the installation directories for PortalServer
and AppServer.
Modify the port file

-W adminPortBlockInput.portsFilePath=full path to ports file
Add this parameter to the installation command or in the response file to modify the port file,
WASDefaultPortsFile.props, located on the Setup disc with the WebSphere Application Server port
range.
Note: The valid port range for WebSphere Application Server is 1 to 65535.
-W portalPortBlockInput.portsFilePath=full path to ports file
Add this parameter to the installation command or in the response file to modify the port file,
WPDefaultPortsFile.props, located on the Setup disc with the WebSphere Portal port range.
Note: The valid port range for WebSphere Portal is 1 to 65535.
Set the profile as the default profile

-W detectProfileAction.isDefault="True"
If installing coexisting installations, add this parameter to your installation command to set the
profile as the default profile.
-W detectProfileAction.isDefault="False"
If installing coexisting installations, add this parameter to your installation command to set the
profile as the non-default profile.
-W detectProfileAction.isDefault="True" -W detectProfileAction.profileName="your_profile_name"
-W detectProfileAction.profilePath="C:\full\path\your_profile_name"
If installing coexisting installations, add these three parameters to the installation command to modify
the default profile name and profile path.
Set the cellName

-W cellName.value=cellName
By default, the install sets CellName to the NodeName. Use this parameter to change the default to
something that fits your business needs.
IBM i ports configuration and profile name

-W setWASHome.startingPort=20000
For i: Add this parameter to specify the ports configuration.
-W setWASHome.wasProfile=my_profile
For i: Add this parameter to set the profile name instead of using the default.

Related tasks:
“Installing WebSphere Portal on Windows in a single server environment” on page 3070
authentication.
authentication.
authentication.
“Installing WebSphere Portal on AIX on the additional cluster nodes” on page 366
environment.
authentication.
authentication.
authentication.
authentication.
“Installing WebSphere Portal on Linux on the additional cluster nodes” on page 773
environment.
Installing 113
authentication.
“Solaris stand-alone: Installing WebSphere Portal” on page 804
authentication.
“Installing WebSphere Portal on Solaris on the additional cluster nodes” on page 1056
environment.
authentication.
“Windows stand-alone: Installing WebSphere Portal” on page 1085
authentication.
“Installing WebSphere Portal on Windows on the additional cluster nodes” on page 1332
environment.
Installing on AIX
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.
to run the deploy-portal-mashup-ui task listed in the Integrating > Integrating mashups > Configuring
your portal and mashups > Enabling mashup integration in your portal (mandatory) topic.
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 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. It
enables you to examine and test the functions and features to decide how to accomplish business goals.
The following illustrations depicts the stand-alone server configuration that will result 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

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.
Perform the following steps to prepare your AIX machine:

1. Set the file descriptor limit to 10240; for example, ulimit -n 10240.
2. 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.
3. 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 or in console mode.
AIX stand-alone: Installing WebSphere Portal

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 sources.
Perform the following steps to install WebSphere Portal:
Installing 115
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 with an existing WebSphere Application Server instance, ensure it is installed at
the supported level and has the following features installed:
v Application Server
v Administration
– Scripted Administration
– Administrative Console
v Ant and Deployment Tools
– Deploy Tool
– Ant Utilities
Restriction: WebSphere Application Server installations that have an existing WebSphere Portal
Version 7.0 profile or that do not meet the correct software versions will not be included in the list of
available, existing WebSphere Application Server instances.
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.
4. Optional: Perform the following steps if you want to install WebSphere Portal using a non-root user:
Restriction: Although it is possible to install WebSphere Application Server as a non-root user, there
are limitations to this option that can affect WebSphere Portal functionality, which is why you should
install WebSphere Application Server as a root user.
a. Install the current supported version of WebSphere Application Server as a root user.
b. Open a command prompt and perform the following steps to create a non-root user and to change
ownership:
1) Use the appropriate system commands to create a new group, to create a new user, and to add
the new user to the new group.
2) Run the following tasks to change the rights of the non-root user:
chmod -R g+rwx /usr/IBM
chgrp -R group_name /usr/IBM
chmod -R g+wr /tmp
chgrp -R group_name /tmp
chmod -R g+wr /var/tmp
chgrp -R group_name /var/tmp
3) If you are also installing WebSphere Application Server as a non-root user, choose one of the
following additional tasks based on whether you have a 32-bit or 64-bit AIX operating system:
Table 28. Additional access right tasks based on the type of operating system
Operating system type Additional task
32-bit operating system chmod -R g+rwx /A-Setup
chgrp -R group_name /A-Setup
c. Launch the installation program per the next step. During the installation, select the existing
WebSphere Application Server using the non-root user and set the installation location to a unique
location under the path where non-root permissions were granted.

5. Choose one of the following installation commands based on the installation method you want to use
to install WebSphere Portal; see Installation Methods for more information:
Advance installation parameters: To customize your installation, you can add various parameters to
your installation commands; for example, you can specify your port information. See "Advanced
installation parameters" under Related references at the end of this document for information.
Restriction: When defining your installation path, the ONLY supported characters are ASCII letters
[A-Z and a-z], numbers [0-9], slashes [/ or \, depending on your operating system], and the dash [-].
Table 29. Installation task options
Installation type Task
Graphical user interface ./install.sh
Console mode ./install.sh -console
Silent install ./install.sh -options "path_to_file/
response_filename", where path_to_file is the full path to
the response file and response_filename is the name of the
file. A sample install response file (installresponse.txt)
and a sample uninstall response file
(uninstallresponse.txt) are located in the setup CD root
directory.
Important: Do not place the response file in a path that
contains a space and do not put a space in the file name.
Note: If the installation program does not detect a WebSphere Application Server instance that you
know exists, exit the installation program and pass the WebSphere Application Server instance
location using the command line; for example, ./install.sh -W was.undetectedWas="/my/WAS/
location".
Note: If the GUI or console mode installation program fails to detect ports for either WebSphere
Application Server or WebSphere Portal, a warning message displays and the installer offers another
chance to enter the values. If the silent installation fails to detect ports for either WebSphere
Application Server or WebSphere Portal, the installer will exit.
6. Verify your installation was successful; access WebSphere Portal using the http://
yourserver:yourport/wps/portal format. Run one of the following tasks from the
wp_profile_root/ConfigEngine directory to generate the server1_PortMatrix.txt and
WebSphere_Portal_PortMatrix.txt files:
Note: The port files are located in the wp_profile_root/ConfigEngine/log/ directory and list the
WebSphere Application Server (server1) and WebSphere Portal (WebSphere_Portal) ports for your
installation.
v ./ConfigEngine.sh list-server-ports -DWasPassword=password
v ./ConfigEngine.sh list-server-ports-by-name -DServerName=server1 -DWasPassword=password
v ./ConfigEngine.sh list-server-ports-by-name -DServerName=WebSphere_Portal
-DWasPassword=password
7. 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.
Installing 117
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 7.0.0" and "Intranet Web
Content 7.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 Application Server Administration
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 E-mail", "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.
8. 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=xyzadmin,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=xyzadmin,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.
Important:
v Ensure the portal administrator you specify for portal_admin_DN is a member of the group you
specify for content_authors_group_DN, otherwise the portal administrator cannot access the Web
content libraries for the Intranet and Internet Site Templates.
v If you plan to run the express-memberfixer task in an environment with multiple realms,
remove the cn=contentauthors,o=defaultWIMFileBasedRealm group if it exists. If this group
exists in an environment with multiple realms, the Member Fixer task does not have any effect.
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.
9. Optional: Perform the following steps if you need to change the ports for WebSphere Application
Server or WebSphere Portal:
Note: The starting port parameter is required for a successful completion of the modify-ports-by-
startport task. Once you specify a start port, this port becomes the base for assigning port values.

The code increments this value as each port is assigned, which means that the WebSphere Portal ports
will be assigned incrementally starting with the port defined with the modify-ports-by-startport
task.
a. Stop the server1 and WebSphere_Portal servers.
b. Run one of the following commands for each server you need to change:
Table 30. Commands to change port numbers using the starting port number
Method Task
Starting port number ./ConfigEngine.sh modify-ports-by-startport
-DModifyPortsServer=servername -DStartPort=starting
port number
Port file ./ConfigEngine.sh modify-ports-by-portsfile
Note: Sample port files are available on the Setup disc. -DWasPassword=password
-DModifyPortsServer=servername -DPortsFile=full path
to ports file
The following is an example of the information within a

port file although the port values will be different based
on your environment:
BOOTSTRAP_ADDRESS=10035
SOAP_CONNECTOR_ADDRESS=10025
ORB_LISTENER_ADDRESS=10034
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=10041
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=10036
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=10033
WC_adminhost=10042
WC_defaulthost=10039
DCS_UNICAST_ADDRESS=10030
WC_adminhost_secure=10032
WC_defaulthost_secure=10029
SIP_DEFAULTHOST=10027
SIP_DEFAULTHOST_SECURE=10026
IPC_CONNECTOR_ADDRESS=10037
SIB_ENDPOINT_ADDRESS=10028
SIB_ENDPOINT_SECURE_ADDRESS=10038
SIB_MQ_ENDPOINT_ADDRESS=10040
SIB_MQ_ENDPOINT_SECURE_ADDRESS=10031
c. Restart the server1 and WebSphere_Portal servers.
You can create additional WebSphere Portal profiles immediately after installation and then configure
each profile individually or you can continue to configure your WebSphere Portal environment and then
create your multiple profiles so that each profile has the same configuration.
Installing 119
Related concepts:
“Installation methods, options, and sources” on page 105
“Data collection and symptom analysis” on page 3538
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:
Related reference:
“Advanced installation parameters” on page 111
“Exploring the sample site templates” on page 2723
Before you begin to work on your own, take time to test drive and explore the default internet and
intranet sites templates that are provided with the product.
AIX stand-alone: Configuring WebSphere 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:
“Preparing your AIX operating system” on page 115
AIX stand-alone: Setting up a DB2 database:
View information on installing and setting up DB2 to work with WebSphere Portal.
AIX stand-alone: Installing DB2:
View information on installing DB2 for use with 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 If you are using DB2 Version 9.1 you must use the db2jcc.jar file. You will need to replace references to
db2jcc4.jar with db2jcc.jar in this topic. If you are not using this specific version of DB2, you must use
the db2jcc4.jar file.
v If you are using DB2 for z/OS Version 8, you must use the db2jcc.jar file. You will need to replace
references to db2jcc4.jar with db2jcc.jar in this topic. If you are not using this specific version of DB2
for z/OS, you must use the db2jcc4.jar file.
v If you plan to transfer data from multiple portals sharing the same DB2 database, you should increase
the default value for the number of concurrently active databases (NUMDB). 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.
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, perform the following instructions:
v For JDBC Type 2 drivers only: The appropriate DB2 client must be installed on the same system as
WebSphere Portal and have the same name as the server profile name.
v For JDBC Type 4 drivers only: Copy the driver jar files to the Portal server. 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.
4. If you are using the JDBC driver in type 2 mode, 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 " ".
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.
Installing 121
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 approriate 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
– 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.
1. Locate the following files and create a backup 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 the steps below 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.
Installing 123
l. Optional: For dbdomain.DBA.DbUser, type the database administrator user ID for privileged access
operations during database creation. 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.XDbName, type the database loop back alias that needs to be set if you plan to use
the create-database task.
Note: Required only for local databases using a JDBC Type 2 driver.
o. 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.
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 120
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 121
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.

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.
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).
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:
Installing 125
Environment Description
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.
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. Complete the following:

a. On the DB2 server system, run the following commands. This step is only required for the IBM
Java Content Repository database (jcrdb).
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
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"
b. For JDBC Type 2 connections only: 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.
c. For JDBC Type 2 connections only: 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 above, .
d. For JDBC Type 2 connections only: On the DB2 client, set DB2COMM to TCP/IP by using the
db2set command db2set DB2COMM=tcpip.
e. For JDBC Type 2 connections only: 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.
f. For JDBC Type 2 connections only, 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"
g. For JDBC Type 2 connections only: Log out of DB2 Connect by entering db2 "terminate".
h. For JDBC Type 2 connections only, 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 above, username is the
database user, and password is the password assigned to the database user.
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.
Installing 127
Related tasks:
“AIX stand-alone: Modifying DB2 database properties” on page 122
AIX stand-alone: Setting up DB2 automatically:
This section provides instructions for automatically setting up your database using the ConfigEngine task.
As an alternative to automatically setting up the database, you can manually create users and grant
privileges. There are also optional configuration tasks that are not provided to you by running the
ConfigEngine task.
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.
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 31. 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
Installing 129
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 32. 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 33. Location of SQL script templates by database domain for non-schema-owning configuration database users
createConfigRoleForDifferentSchema.sql

Table 33. 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:
Installing 131
schema-owning runtime database users
createInitialRuntimeRole.sql
createRuntimeRoleForSameSchema.sql
grantRoleToRuntimeUser.sql
grantExtendedPermissionsToRuntimeRole.sql
granted to the non-schema-owning runtime database user:

non-schema-owning runtime database users
createRuntimeRoleForDifferentSchema.sql
AIX stand-alone: Assigning custom DB2 table spaces:
Installing 133
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
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
i: 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.
If the command completes successfully, the UDF is registered correctly as follows: 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.
Installing 135
Related tasks:
“AIX stand-alone: Creating DB2 databases” on page 124
databases manually.
AIX stand-alone: Configuring WebSphere Portal to use DB2:
This section provides information on how to manually transfer data from the default dataase to the
Oracle datase. Follow these steps to transfer WP 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. If you are running a type 2 connection, 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
2. 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.

3. Open a command prompt and change to the directory wp_profile_root/ConfigEngine.
4. Using a JDBC Type 2 driver only, 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.
5. Enter the ./ConfigEngine.sh validate-database -DWasPassword=password command to validate
configuration properties.
Tip: Add the -DTransferDomainList parameter to the above 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. From the same command prompt as the previous steps, change to the directory wp_profile_root/bin.
7. Stop both the server1 and WebSphere_Portal servers:
v ./stopServer.sh server1 -username admin_userid -password admin_password
v ./stopServer.sh WebSphere_Portal -username admin_userid -password admin_password
8. 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
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.
9. Optional: If you specified a runtime 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.
Installing 137
JCR database domain: For the JCR database domain, you must also copy
grantExtendedPermissionsToRuntimeRole.sql.
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
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.
10. 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.
11. 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.
12. 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.
Related tasks:
databases manually.
“AIX stand-alone: Setting up DB2 automatically or manually” on page 127
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. Do this by setting the fullyMaterializeLobData property in the WebSphere Application Server
administrative console.
Note: You only need to perform these steps if you are using Web Content Manager.
1. Log into the WebSphere Application Server administrative console.
2. Click Resources > JDBC > Data sources.
3. 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.
4. Select the name of the data source that is defined in wkplc_dbdomain.properties for the JCR database
domain. The default data source is wpdbDS.
5. Click Custom properties.
6. Ensure that the fullyMaterializeLobData property is set to false.
Installing 139
Related tasks:
databases manually.
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:
Note: If you are using DB2 Version 9.1 you must use the db2jcc.jar file. You will need to replace
references to db2jcc4.jar with db2jcc.jar in this topic. If you are not using this specific version of DB2,
you must use the db2jcc4.jar file.
# 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
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.
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
Installing 141
Related tasks:
databases manually.
“AIX stand-alone: Configuring WebSphere Portal to use DB2” on page 136
This section provides information on how to manually transfer data from the default dataase to the
Oracle datase. Follow these steps to transfer WP and Java Content Repository databases to DB2. As an
wizard to complete the database transfer task.
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/WP70REL
– community.DbName=hostname/WP70COM
– customization.DbName=hostname/WP70CUS
– jcr.DbName=hostname/WP70JCR
– feedback.DbName=hostname/WP70FBK
– likeminds.DbName=hostname/WP70LKM

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.
– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
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 (?)
Installing 143
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,
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.
Installing 145
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.
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.
Related tasks:
“AIX stand-alone: Modifying properties for IBM DB2 for i” on page 142
“AIX clustered server: Modifying IBM DB2 for i database properties” on page 263
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 server1 -username admin_userid -password admin_password
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:
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
4. 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.
Installing 147
Related tasks:
“AIX stand-alone: Creating user profiles for IBM DB2 for i” on page 146
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.
3. Enter the following command:
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: Creating user profiles for IBM DB2 for i” on page 146
“AIX stand-alone server: Creating and setting up IBM DB2 for i databases automatically” on page 146
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.
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:

Installing 149
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.

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
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 dataset, 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
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
Installing 151
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 36. 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.

Table 36. The templates and their descriptions. (continued)
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.
EJPSDBTC This job invokes CHECK DATA for the portal table
spaces that are in status "CHECK PENDING" right 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.
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.
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 149
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.
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 7.0 and an earlier version of WebSphere Portal coexist, the database user
IDs for WebSphere Portal Version 7.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
Installing 153
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.
Related tasks:
“AIX stand-alone: Modifying database properties for DB2 for z/OS” on page 149
AIX stand-alone: Granting privileges to DB2 for z/OS users:
Installing 155
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:
non-schema-owning configuration database users

Related tasks:
“AIX stand-alone: Using JCL templates to set up DB2 for z/OS” on page 152
AIX stand-alone: Creating remote database for DB2 for z/OS:
Installing 157
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 a TEMP database is created for your subsystem. You can use the following statements to
create a TEMP database:
CREATE DATABASE db_name AS TEMP;
CREATE TABLESPACE ts_name IN db_name;
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. Execute the steps in the topic Creating the Java Content Repository database.
5. CREATE DATABASE fdbkdbnameonzos CCSID UNICODE;
6. CREATE TABLESPACE fdbkdbts IN fdbkdbnameonzos USING STOGROUP SYSDEFLT PRIQTY 5000 SECQTY 500
LOCKSIZE ROW DEFINE NO;
7. CREATE DATABASE lmdbnameonzos CCSID UNICODE;
8. 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 153
AIX stand-alone: Creating the Java content repository database on DB2 for z/OS:
View information on setting up your Java Content Repository database to work with WebSphere Portal.
First, you need to create multiple databases for scalability.
The IBM Java Content Repository database grows in size as the IBM WebSphere Portal server is used. To
support this growth, which includes the dynamic creation of many new tables within the database, the
WebSphere Portal server allows you to create multiple databases within a single IBM DB2 Universal
Database for z/OS subsystem. A minimum of two databases is recommended, but more can be created if
necessary. A single database setup is not recommended; it will quickly become constrained. See the
Performance guides on the product documentation Web site for more information.
Each database that is created must begin with a common prefix; there is no convention required for the
remainder of the name. For example, to create xx number of databases, you may choose to use the
following commands:
CREATE DATABASE JCRDB01
...
CREATE DATABASE JCRDBxx
In this case, JCR is the common prefix. You also have to select a maximum number of user-defined tables
(UDT) that each database will be allowed to hold; the recommended value is 400.
A sample script of the commands that you can use to create the Java Content Repository database in your
DB2 for z/OS installation is shown below. The sample demonstrates the creation of a single database. To
follow the recommendation of creating at least two databases, duplicate the commands for each
additional database as indicated below. Find a template of these commands in the file
PortalServer_root/installer/wp.config/config/templates/db/db2_zos/jcr_sample.sql.
Notes:
v It is not necessary to duplicate every tablespace definition in every database.
v In order to run the commands shown in the sample, you must know the database name and the IDs of
the MVS volumes where the Java Content Repository database tables will be stored.
v Edit the template file for your installation environment before running the commands shown in the
sample:
– Replace jcrdbnameX with the name of the database. Remember that each database name must begin
with a common prefix.
– Replace stogroup with the name of your storage group.
– Replace icmvolumes with the IDs of the MVS volumes where the Java Content Repository database
tables will be stored. These values are assigned by the database administrator.
Installing 159
– Replace icmvcat with the name of the virtual catalog.
– Replace jcr with the name of database user ID.
– Replace 4kbp with the name of your 4K bufferpool.
– Replace jcrschema with the schema name of your Java Content Repository domain.
--DROP DATABASE jcrdbnameX
--DROP STOGROUP stogroup
--DROP ALIAS jcrschema.ICMFICTITIOUS
CREATE STOGROUP stogroup VOLUMES (icmvolumes) VCAT icmvcat
GRANT USE OF STOGROUP stogroup to jcr
CREATE DATABASE jcrdbnameX STOGROUP stogroup BUFFERPOOL 4kbp INDEXBP 4kbp CCSID UNICODE
Note: The following tablespace command must be created in every database:

CREATE TABLESPACE ICMLFQ32 IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO LOCKSIZE ROW SEGSIZE 32 LOCKMAX 0 CLOSE NO BUFFERPOOL 32kbp CCSID UNICODE
Note: The following tablespaces are required in the first database only:
CREATE TABLESPACE ICMVFQ04 IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
LOCKSIZE ROW SEGSIZE 32 LOCKMAX 0 CLOSE NO BUFFERPOOL 4kbp CCSID UNICODE
CREATE TABLESPACE ICMSFQ04 IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ICSTADO IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE PRIDLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 10000 SECQTY 1000 DEFINE NO
CREATE TABLESPACE PRSCLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE PRISLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE PRGCLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE PRIGLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ICSTDPV IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ACCCLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ICSDOAC IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE COLNLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE USERLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 10000 SECQTY 1000 DEFINE NO
CREATE TABLESPACE USEGLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 10000 SECQTY 1000 DEFINE NO
CREATE TABLESPACE ACCLLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE SYSCLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE CACLLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE CPERLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE ATTDLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ATTGLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE NLSLLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTy 200 DEFINE NO
CREATE TABLESPACE MAXKLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE NLSKLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ITTDLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ITVDLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ITVILSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE COMDLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE COMALSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE COMFLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE COVDLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE COVALSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ITALLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE IT11LSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE IV11LSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE LI11LSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE ITTRLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE CHEOLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE MIMTLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ITEELSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE SYAELSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE TEICLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE IDELLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 10000 SECQTY 1000 DEFINE NO
CREATE TABLESPACE XDOOLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE XDOFLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE RI11LSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE REPRLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO

CREATE TABLESPACE REPLLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE TIELLSTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE TS00200 IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ICMACTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ICMACLC IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ICMACLS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ICUT301 IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE ADDPJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE DWSLJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE GENDJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE GLBPJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE LINKJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE MAXSJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE NODDJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE NODTJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE NODRJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE NSPRJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE NSURJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE PRPDJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE ROOTJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE NODEJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE SPRTJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE TIMEJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE TSERJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE TSINJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE TSPEJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE TSTAJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE RIDSJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE WSNOJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE LOB TABLESPACE ICMLOBT1 IN jcrdbnameX BUFFERPOOL 32kbp LOG NO
CREATE TABLESPACE DLKRJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE LKRLJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE RGAPJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE SDTSFCTB IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE SDTSSBMT IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
CREATE TABLESPACE SDTSSDPG IN jcrdbnameX USING STOGROUP stogroup PRIQTY 50000 SECQTY 10000 DEFINE NO
CREATE TABLESPACE NOAPJRTS IN jcrdbnameX USING STOGROUP stogroup PRIQTY 500 SECQTY 200 DEFINE NO
Installing 161
Related tasks:
“AIX stand-alone: Granting privileges to DB2 for z/OS users” on page 155
AIX stand-alone: Assigning custom tablespaces on DB2 for z/OS:
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: Creating remote database for DB2 for z/OS” on page 157
AIX stand-alone: Configuring WebSphere 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:


Installing 163
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
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
-DTransferDomainList=jcr -DWasPassword=password
7. If a dedicated runtime 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
runtime database user name and the schema name. Open the
createRuntimeRoleForSameSchema.sql file when the same name is used for the runtime 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)
...
11. Start the WebSphere Application Server.
12. 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.
Installing 165
Related tasks:
“AIX stand-alone: Creating remote database for DB2 for z/OS” on page 157
“AIX stand-alone: Creating the Java content repository database on DB2 for z/OS” on page 159
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.
Before you begin:

v You should have reviewed the Planning for Oracle or Oracle RAC section.
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:


– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
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.
Installing 167
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.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
v The database element of this value should match the value of DbName.
v For Oracle RAC 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 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.
Restriction: The value for dbdomain.DbUser must equal the value for dbdomain.DbSchema unless

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 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
Installing 169
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
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 166
AIX stand-alone: Setting up Oracle or Oracle RAC automatically:
ConfigEngine task. To learn more about manually configuring Oracle or other optional manual
configuration tasks, refer to the manual configuration are of this section.
AIX stand-alone: Running a task to automatically setup Oracle or Oracle RAC databases:
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:
The setup-database task creates the table spaces, index spaces, and the database users as specified in
the properties files.
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.
Installing 171
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.

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 173
non-schema-owning configuration database users (continued)

Installing 175
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 below. As an alternative to
creating JCR table spaces using the steps below, 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.
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.
AIX stand-alone: Assigning custom Oracle or Oracle RAC table spaces:
Before you begin:

database transfer.

Installing 177
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 WebSphere 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 WebSphere 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 you begin:

v Property files are modified.
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 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))).
v When doing a single database, single user, and multi schema database transfer, there can be only one
files:
name are the same.
Installing 179

7. After transferring the database tables, run the dbms_stats.gather_schema_stats command to avoid
slow database response. Example:
SQL> execute dbms_stats.gather_schema_stats(ownname=> ’jcr’, cascade=> TRUE);
Related tasks:
“AIX stand-alone: Modifying Oracle or Oracle RAC database properties” on page 166
“AIX stand-alone: Creating Oracle or Oracle RAC databases” on page 169
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 either the DataDirect Connect for JDBC driver version 4.0 and higher or the
Microsoft SQL Server JDBC Driver version 2.0 and higher.
– You can obtain the DataDirect Driver from DataDirect Technologies. The JDBC driver consists of two
parts: the JDBC driver libraries and JTA libraries. The JDBC driver libraries must be put on the
WebSphere Portal system, while the JTA libraries are intended for SQL Server.
– 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. These steps are the same for both the DataDirect and Microsoft
drivers unless noted.
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 one of these methods:
v DataDirect Connect for JDBC drivers:
a. Purchase, download, and install the DataDirect Connect for JDBC; see DataDirect JDBC Drivers
for information.
b. Enable XA connections; see Understanding XA Transactions for information.
v 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
Installing 181
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
Step 2 above, 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.

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl

a. For dbdomain.DbType, type sqlserver2005.
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 183
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.
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.
Related tasks:
“AIX stand-alone: Installing SQL Server” on page 180
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: Modifying SQL Server database properties” on page 182
AIX stand-alone: Setting up SQL Server automatically:
ConfigEngine task. To learn more about manually configuring SQL Server or other optional manual
AIX stand-alone: Running a task to automatically setup SQL server databsaes:
privileges.
Installing 185
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 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.

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

Table 46. List of SQL script templates by database domain (continued)
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:
Installing 187
community/createConfigRoleForSameSchema.sql
community/grantRoleToConfigUser.sql
customization/createConfigRoleForSameSchema.sql
customization/grantRoleToConfigUser.sql
database user:

community/createConfigRoleForDifferentSchema.sql
customization/createConfigRoleForDifferentSchema.sql
Installing 189
community/createInitialRuntimeRole.sql
community/createRuntimeRoleForSameSchema.sql
community/grantRoleToRuntimeUser.sql
customization/createInitialRuntimeRole.sql
customization/createRuntimeRoleForSameSchema.sql
customization/grantRoleToRuntimeUser.sql

community/createRuntimeRoleForDifferentSchema.sql
customization/createRuntimeRoleForDifferentSchema.sql
AIX stand-alone: Assigning custom SQL Server filegroups:
Installing 191
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
AIX stand-alone: Configuring WebSphere 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 WebSphere Portal and Java Content Repository databases
to SQL Server. 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:


Tips:
Repository schema.
b. Enter the following commands:
files:
name are the same.
Installing 193

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’;
Related tasks:
“AIX stand-alone: Modifying SQL Server database properties” on page 182
“AIX stand-alone: Creating databases manually on SQL Server” on page 184
AIX stand-alone: Verifying 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 files.
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 WebSphere Application
Server, complete these steps:

1. Open the WebSphere Application Server administrative 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 administrative console.
3. Click Resources > JDBC > JDBC Providers.
5. Select the name of the data source that is defined in wkplc_dbdomain.properties. The default data
source is wpdbDS.
6. 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.
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.
Perform 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 51. 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 roadmap for information.
For Domino and Oracle iPlanet Web servers: If you plan to use the Page Builder Theme to change
your page layout, enable WebDAV on your Web server side. Please consult with your vendor and/or
vendor's documentation for more information about how to complete this action.
If using WebDAV with mashups or Page Builder: After successfully installing the Web server
plug-in, locate and open your plugin-cfg.xml file and set AcceptAllContent to true.
Installing 195
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 perform
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, perform 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 below for information.
v Follow the instructions for your Web server to enable PUT and DELETE requests.
9. Start the Web server.
Related tasks:
authentication.
Related reference:
“Switch for tunneling of HTTP methods” on page 3230
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 backup 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 WebSphere Portal to use a database” on page 120
“Managing your user registry on AIX” on page 2526
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 setup an LDAP server as a user registry to store user information and authenticate users in
your high availability production environment.
Choose the appropriate LDAP server to install and setup:
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 will communicate with IBM WebSphere Portal.
Perform the following steps to prepare Domino Directory:

1. Perform 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 perform this task.
e. Click Domino Administrator Help > Installation > Installing and setting up Domino servers >
The Domino server setup program and perform this task.
2. Perform 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 wpsbind user:
Last Name
wpsbind
User Name
wpsbind/DominoDomain, where DominoDomain is your Lotus Domino Internet domain
Installing 197
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 wpsadmin
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
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. Perform 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 will communicate with IBM WebSphere Portal.
Perform 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. Perform the following steps to create the WebSphere Portal administrative user:
a. Optional: Perform the following steps to create a new directory suffix:
1) Click the Server Administration folder, located in the left-hand navigation of the directory
server console.
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 root directory of the CD setup, 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 DB2 Content Manager group and user IDs if you
configured DB2 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. 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.
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 will communicate with IBM WebSphere Portal.
Perform the following steps to prepare Novell eDirectory:

1. Install Novell eDirectory; refer to eDirectory for information.
server console.
Installing 199
4) Click Add.
your LDAP server.
AIX stand-alone: Preparing an Oracle Directory Server:
If you plan to use a Oracle Directory Server as an LDAP user registry, you must install and set up the
Perform the following steps to prepare Oracle Directory Server:

1. Install Oracle Directory Server; refer to Oracle software for information.
server console.
4) Click Add.
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
Perform 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.
server console.
4) Click Add.
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 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:
Installing 201
Configure IBM WebSphere Portal to use a standalone LDAP user registry to store all user account
information for authorization.
You must ensure that the IDs that 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.
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
instructions below, when the step refers to the wkplc.properties file, you will 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 backup 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 parameters and for
advanced parameters.
standalone.ldap.id
standalone.ldap.host
standalone.ldap.port
standalone.ldap.bindDN
standalone.ldap.bindPassword
standalone.ldap.ldapServerType
standalone.ldap.userIdMap
standalone.ldap.groupIdMap
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.group.objectClassesForCreate
standalone.ldap.et.group.searchBases
standalone.ldap.et.personaccount.objectClasses
standalone.ldap.et.personaccount.objectClassesForCreate
standalone.ldap.et.personaccount.searchBases
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.
Attention: If you have not deleted the default file repository, WasPassword is the value entered
during installation and not a value found in your LDAP user registry.
Note: During the validation task, you may receive the following prompt: Add signer to the trust
store now?. 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 1980.
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. This step ensures that access to the Web
content libraries for the Intranet and Internet Site Templates for the contentAuthors group is
correctly mapped to the appropriate group in the LDAP directory.
Installing 203
LDAP configuration.
Important:
d. Run the ./ConfigEngine.sh express-memberfixer -DmemberfixerRealm=realm_name
-DPortalAdminPwd=password -DWasPassword=password 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:
Table 52. 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. 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.
14. 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.

Related tasks:
“AIX cluster: Adapting the attribute configuration” on page 358
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 1980
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.
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 Application Server Administrative Console.
b. Navigate 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 205
7. Required: Enter a value for the following required relative distinguished name (RDN) parameters in

8. Enter a value for the following parameters to enable Secure Socket Layers (SSL):
Required parameters:
standalone.ldap.sslEnabled
standalone.ldap.sslConfiguration
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.
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.
Perform the following tasks to add user registries to the default federated repository:
AIX stand-alone: Configuring a default federated user registry:
Installing 207
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. 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. You must also ensure that the IDs that 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.group.objectClassesForCreate

federated.ldap.et.group.searchBases
federated.ldap.et.personaccount.objectClasses
federated.ldap.et.personaccount.objectClassesForCreate
federated.ldap.et.personaccount.searchBases
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:
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:
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.
Installing 209
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:
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:
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.
Important:
Content Manager
Type of LDAP Value

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:
Installing 211
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
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 -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. In a clustered environment, restart the deployment
manager, the node agent(s), and WebSphere_Portal servers. In a standalone environment, restart
the server1 and WebSphere_Portal 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. Verify that the task completed successfully. In a clustered environment, restart the deployment
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, which is organized by operating system, for
instructions: Deleting the repository.
Related tasks:
“AIX stand-alone: Adapting the attribute configuration” on page 225
“Deleting the repository on AIX” on page 2551
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:

federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 213
federated.ldap.sslEnabled
federated.ldap.sslConfiguration
federated.ldap.certificateMapMode
federated.ldap.certificateFilter
repository.

id
baseDN
nameInRepository
groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Installing 215
the feature.
LDAP configuration.
Important:
Content Manager
Type of LDAP Value


Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 217
Related tasks:
“User IDs and passwords” on page 30
“Deleting the repository on AIX” on page 2551
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
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: The task of setting up a new database is typically
performed by a database administrator. 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 55. Steps for creating a new database to use as a database user registry.
Database Steps
DB2 Perform the following steps to create a DB2 database:
1. Install DB2.
2. Enter the following database tuning commands:
Oracle Perform 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:
v db_block_size = 8192
v db_cache_size = 300M
v db_files = 1024
v log_buffer = 65536
v open_cursors = 1500
v pga_aggregate_target = 200M
v pre_page_sga = true
v processes = 300
v shared_pool_size = 200M
SQL Server Perform 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:
a. Navigate to the following directory: wp_profile_root/ConfigEngine/properties
b. Locate and open wkplc_dbtype.properties with any text editor.
Installing 219
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: db2jcc.jar;db2jcc_license_cu.jar
DB2 for z/OS Type 2 driver: db2java.zip
DB2 for z/OS Type 4 driver: db2jcc.jar;db2jcc_license_cisuz.jar;db2jcc_javax.jar
Oracle: ojdbc14.jar
SQL Server JDBC driver provided by Microsoft: sqljdbc.jar
SQL Server JDBC driver provided by DataDirect: sqlserver.jar;base.jar;util.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.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Installing 221
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, you can perform 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.
Perform 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 had two additional base entries (base entry 1 and base entry 2) to add to the realm
you just created, you would update the wkplc.properties file with the information from base entry
1 and then run this task. Then you would update the properties file with the information for base
entry 2 and then run this task:
realm configuration heading:
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 -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 223
e. Verify that the task completed successfully. In a clustered environment, restart the deployment
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. In a clustered environment, restart the deployment
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 197
“AIX stand-alone: Adding an LDAP user registry without SSL” on page 208
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.
Installing 225
Note: This task does not validate the existence of attributes in the LDAP schema.
AIX stand-alone: Adding attributes:
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, on the primary node only, to add an LDAP user registry over SSL to the
default federated repository; you must repeat these steps for each additional LDAP you plan to add:
1. Complete the following steps to install the required Enterprise Archive (.ear) file on WebSphere
Application Server.
a. Open a command prompt.
b. Navigate to the wp_profile_root/ConfigEngine directory.
c. Run the ./ConfigEngine.sh wp-la-install-ear -DWasPassword=password task.
Property Extension Properties heading:
Note: See the properties file for specific information about the required parameters and for advanced
parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
6. Run the ./ConfigEngine.sh wp-add-property -DWasPassword=password task to add the attribute to the
user registry.
Note: This task makes an EJB call to WebSphere Application Server, which must authenticate against
WebSphere Application Server. Depending on the configuration in the sas.client.props file, you
might 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 after you 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, you will need to 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 56. 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 parameters and for advanced
parameters.
standalone.ldap.id
Federated The following parameters are found under the VMM
Federated repository properties heading:
parameters.
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 57. 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:
Installing 227
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
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 step below 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 58. Parameters to define in the wkplc.properties file to correct any issues found in the config trace file.
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 will flag certificate

and members as unsupported attributes and will 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 58. Parameters to define in the wkplc.properties file to correct any issues found in the config trace
file. (continued)
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 59. 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:
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.
Installing 229
d. Stop and restart all necessary servers to propagate your changes.
Related tasks:
“AIX stand-alone: Querying the defined attributes” on page 225
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, perform the following steps on the deployment manager and
then resynch the nodes.
1. Perform the following steps to remove an attribute stored in a property extension database; this is an
attribute that was added using the wp-add-la-property task.
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 propertiesNotSupported definitions for the attributes that you deleted from
the LAPROP table; for example:
<config:propertiesNotSupported name="attribute_name">
i. Save your changes to the wimconfig.xml file.
j. Stop and restart the server1 and WebSphere_Portal servers from the wp_profile_root/bin directory.
2. Perform 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>
</config:attributes>
f. Save your changes to the wimconfig.xml file.
g. Stop and restart the server1 and WebSphere_Portal servers.
Related tasks:
“AIX stand-alone: Querying the defined attributes” on page 225
“AIX stand-alone: Adding attributes” on page 226
AIX stand-alone: Configuring WebSphere 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. Choose the appropriate set of steps, depending on your LDAP server environment:
Table 60. Steps for enabling dynamic groups
LDAP server environment Steps to perform
Stand-alone LDAP server or federated LDAP server(s) 1. Navigate to the following directory:
wp_profile_root/cells/cell_name/wim/config.
2. Locate and open wimconfig.xml with any text editor.
3. Add the following line to the
<config:groupConfiguration> tag:
<config:dynamicMemberAttributes name="memberurl" objectClass="groupofurls"/>
4. Save and close wimconfig.xml.
Installing 231
Table 60. Steps for enabling dynamic groups (continued)
Federated LDAP server(s) 1. Log in to the administration console.
2. Select Security > Secure administration,
applications, and infrastructure.
3. Under Available realm definitions, select Federated
repositories and click Configure.
4. Under Related Items, click Manage repositories.
5. Select the appropriate repository from the list.
6. Under Additional Properties, click Group attribute
definition then click Dynamic member attributes.
7. Click New and specify values for the Name and
Object class fields as appropriate. For example,
v Name: memberurl
v Object class: groupofurls
8. Click OK and save the changes to the master
configuration.
Related tasks:
“AIX stand-alone: Choosing your user registry model” on page 201
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. Use any text editor to open the wkplc.properties file in the following directory: wp_profile_root/
ConfigEngine/properties.
3. 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
4. Save and close wkplc.properties.
5. Run the following task from the wp_profile_root/ConfigEngine directory to create an LDAP entity type:
UNIX: ./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

Related tasks:
“AIX stand-alone: Choosing your user registry model” on page 201
“AIX stand-alone: Adapting the attribute configuration” on page 225
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 233
Related tasks:
authentication.
“AIX stand-alone: Configuring WebSphere Portal to use a database” on page 120
“AIX stand-alone: Preparing a remote Web server” on page 195
Setting up a cluster on AIX

dynamic.
The following illustration depicts a horizontal cluster configuration where IBM WebSphere Portal is
installed on multiple servers. This configuration reduces single points of failure, but requires more
hardware.

To conserve hardware, you can also set up a vertical cluster with multiple portal instances on a single
node.
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.
to achieve better performance. The Base Portal Tuning scenarios in the WebSphere Portal and Lotus Web
Content Management 6.1.x Performance Tuning Guide provides information about tuning the WebSphere
Application Server, WebSphere Portal services, databases, directory servers and more. Base Portal Tuning
scenarios are the foundation to most performance tuning. In a cluster environment, there are additional
steps you should take to tune WebSphere Application Server, the Web server, and more. First review and
take the necessary steps provided in the Base Portal Tuning scenarios, then review and take additional
necessary steps in the Tuning a Cluster Environment chapter of the tuning guide.
Base Portal Tuning scenarios
Tuning a cluster environment
AIX cluster: Preparing your AIX operating system

Perform the following steps to prepare your AIX machine:

Installing 235
3. Install and configure X server on AIX (for example X-Windows or GNOME) to use the graphical user
interface the installation program provides.
Preparing the primary node on AIX

Before creating your high availability environment, you must install IBM WebSphere Portal on your
primary node and then configure your database and your network deployment manager.
Perform the following tasks to prepare your primary node:
Installing WebSphere Portal on AIX on the primary node:
authentication.
Perform the following steps to install WebSphere Portal on the primary node.
v Administration
– Deploy Tool
– Ant Utilities
levels.

ownership:
chmod -R g+rwx /usr/IBM
chgrp -R group_name /usr/IBM
chmod -R g+wr /tmp
following additional tasks based on whether you have a 32-bit or 64-bit AIX operating system:
directory.
location".
Installing 237
installation.
> Users and Groups.
Libraries.

LDAP configuration.
Important:
task.
Method Task
port number
Installing 239
Table 63. Commands to change port numbers using the starting port number (continued)
Method Task
to ports file

WC_adminhost=10042

Related concepts:
Related tasks:
“Creating a Portal custom profile on AIX” on page 2094
Custom profiles do not contain any servers or applications; they are used as runtime environments to
create additional cluster members. After creating the profile, the node needs to be federated into an
existing cell. The portal server will be added when you add the additional nodes to an existing cluster.
“Preparing the system for multiple profile support on AIX” on page 2091
IBM WebSphere Portal Version 7 ships a new configuration profile template called the portal profile
template. When the product is installed, this new profile template type is registered with IBM WebSphere
Application Server so you can create new configuration profiles based on it. Before a new portal template
can be created, the portal profile template must be primed with the baseline application server
configuration to use as a basis for the new profile. This baseline configuration is provided in the form of
a configuration archive (CAR) that is created from an existing portal profile. The CAR is created by
exporting the contents of an existing portal profile, which can be made at any time, such as immediately
after initial installation, or after the original portal is fully configured with the baseline configuration,
including security, basic application deployment, and server tuning.
Related reference:
AIX cluster: Configuring WebSphere 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,
Installing 241
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 configuration scripts.
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
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.
AIX clustered server: Setting up a DB2 database:
AIX clustered server: Installing DB2:
Before you begin:

required databases.

Portal.
AIX clustered server: Modifying DB2 database properties:

– release
– customization
– community
– jcr
– feedback
– likeminds
Installing 243
– dbdomain.DbName
– dbdomain.DbUrl
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback


driver class.
AIX clustered server: Creating groups and assigning users:
Installing 245
Related tasks:
“AIX clustered server: Installing DB2” on page 242
AIX clustered server: Creating DB2 databases:
databases manually.
Related tasks:
“AIX clustered server: Modifying DB2 database properties” on page 243
AIX clustered server: Creating a local DB2 database automatically:
AIX clustered server: Creating a remote or local DB2 database manually:


running.
instance owner.
that you run:
Notes:
six times.

Installing 247
db2 "TERMINATE"
by name.
domain.


AIX clustered server: Setting up DB2 automatically or manually:
Related tasks:
“AIX clustered server: Creating groups and assigning users” on page 245
AIX clustered server: Setting up DB2 automatically:
ConfigEngine task.
AIX clustered server: Running a task to automatically setup DB2 databases:
AIX clustered server: Setting up DB2 manually:
Installing 249
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:
database user:
Installing 251
Table 66. Location of SQL script templates by database domain for non-schema-owning configuration database users

Installing 253
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:
Installing 255
b. Run the command:
using password.

# English
# Swedish

Related tasks:
“AIX clustered server: Creating DB2 databases” on page 246
databases manually.
AIX clustered server: Configuring WebSphere 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 WebSphere Portal and Java Content Repository databases to DB2.
As an alternative to the manual database transfer procedure described here, you can use the
Before you begin:

Tips:
Repository schema.

Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
2. 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.
Installing 257
Note:
files:
name are the same.


using password
db2 terminate
-p password
Installing 259
Related tasks:
databases manually.
“AIX clustered server: Setting up DB2 automatically or manually” on page 249
AIX clustered server: Configuring DB2 for large file handling in WCM:

Related tasks:
databases manually.
AIX clustered server: Changing DB2 driver types:
configuration task.
Note:
Installing 261
JDBC driver.

Related tasks:
databases manually.
“AIX clustered server: Configuring WebSphere Portal to use DB2” on page 257
This section provides information on how to manually transfer data from the default database to the DB2
database. Follow these steps to transfer WebSphere Portal and Java Content Repository databases to DB2.
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:


Installing 263
– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
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
Installing 265
feedback
JDBC driver class.
AIX clustered server: Creating IBM DB2 for i user profiles:

Before you begin:

can be shared.
new password.
environment.
AIX stand-alone server: Creating and setting up IBM DB2 for i databases automatically:
Related tasks:
AIX clustered server: Transferring IBM DB2 for i manually:
Before you begin:

Installing 267
the task to stall.
Note:

Related tasks:
“AIX clustered server: Creating IBM DB2 for i user profiles” on page 266
AIX clustered server: Verifying IBM DB2 for i database connections:

Installing 269
Related tasks:
“AIX clustered server: Creating IBM DB2 for i user profiles” on page 266
“AIX stand-alone server: Creating and setting up IBM DB2 for i databases automatically” on page 146
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:
export EXTSHM=ON
remote database.
AIX clustered server: Using JCL templates to set up DB2 for z/OS:


created.
successfully.
authority.

on the database
authority.

Installing 271
AIX clustered server: Creating DB2 for z/OS users:
installation.

(R) - at runtime







where:
data.
Related tasks:
“AIX clustered server: Installing DB2 for z/OS” on page 270
AIX clustered server: Creating remote DB2 for z/OS databases:

machine.
Installing 273
the databases.
500 DEFINE NO;
Related tasks:
“AIX clustered server: Using JCL templates to set up DB2 for z/OS” on page 270
AIX clustered server: Granting privileges to DB2 for z/OS database administration users:

database user:
Installing 275

non-schema-owning runtime database users (continued)
Related tasks:
“AIX clustered server: Creating DB2 for z/OS users” on page 272
AIX clustered server: Creating the Java Content Repository database:
following commands:
...
Notes:
sample:
Installing 277


Installing 279
Related tasks:
“AIX clustered server: Creating remote DB2 for z/OS databases” on page 273
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

Related tasks:
“AIX clustered server: Granting privileges to DB2 for z/OS database administration users” on page 274
AIX clustered server: Configuring WebSphere Portal to use DB2 for z/OS:
Before you begin:


Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 281
domains.

...
Related tasks:
“AIX clustered server: Granting privileges to DB2 for z/OS database administration users” on page 274
AIX clustered server: Setting up an Oracle or Oracle RAC database:
AIX clustered server: Installing Oracle or Oracle RAC:
Installing 283
Before you begin:
$ gsdctl start
$ lsnrctl start
$ agentctl start
AIX clustered server: Modifying Oracle or Oracle RAC database properties:
to the Oracle or Oracle Rac database.

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl

understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
Installing 285
server.
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:
Installing 287
Note:
database.
Related tasks:
“AIX clustered server: Modifying Oracle or Oracle RAC database properties” on page 284
AIX clustered server: Setting up Oracle or Oracle RAC automatically:
AIX clustered server: Running a task to automatically setup Oracle or Oracle RAC databases:
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
Installing 289
createUsers.sql
AIX clustered server: Granting privileges to Oracle or Oracle RAC database users:

schema-owning configuration database users (continued)
database user:
Installing 291

schema-owning runtime database users (continued)
Installing 293
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
Installing 295
AIX clustered server: Configuring WebSphere Portal to use Oracle or Oracle RAC:
Oracle database. Follow these steps to transfer WebSphere Portal and Java Content Repository databases
Before you begin:

Tips:
Repository schema.


files:
name are the same.

Installing 297
Related tasks:
“AIX clustered server: Modifying Oracle or Oracle RAC database properties” on page 284
“AIX clustered server: Creating Oracle or Oracle RAC databases” on page 286
AIX clustered server: Setting up a remote SQL Server:
AIX clustered server: Installing SQL Server:


for information.
information.
steps:
sqljdbc_xa.dll
AIX clustered server: Modifying SQL Server database properties:
Installing 299
– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl

understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 301
JDBC driver class.
AIX clustered server: Creating databases manually on SQL Server:

Related tasks:
“AIX clustered server: Installing SQL Server” on page 298
AIX clustered server: Setting up SQL Server automatically or manually:
table spaces.
Note:
database.

Related tasks:
“AIX clustered server: Modifying SQL Server database properties” on page 299
AIX clustered server: Setting up SQL Server automatically:
AIX clustered server: Running a task to automatically setup SQL server databsaes:
privileges.
4. Click Files.
Autogrowth field.
AIX clustered server: Setting up SQL Server manually:
Installing 303
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 305
schema-owning configuration database users (continued)
database user:

Installing 307
schema-owning runtime database users (continued)

AIX clustered server: Assigning custom SQL Server filegroups:
Before you begin:

Installing 309
database transfer.

following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
AIX clustered server: Configuring WebSphere Portal to use SQL Server:
Before you begin:

Tips:
Repository schema.

files:
name are the same.
Installing 311

Related tasks:
“AIX clustered server: Modifying SQL Server database properties” on page 299
“AIX clustered server: Creating databases manually on SQL Server” on page 302
AIX clustered server: Verifying databases:
in a browser:

source is wpdbDS.
environment.
Creating the WebSphere Portal profile template on AIX in a clustered environment:
After installing the primary node and configuring your remote database, you should create the
configuration archive (CAR) file that you will use to create additional IBM WebSphere Portal profiles.
Perform 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 will 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 will be 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 zip 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:
authentication.
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 will need to recreate 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.
Perform the following step to remove the search collection:
Installing 313
1. Perform the following steps to prevent search collection creations:
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. Perform the following steps to delete all existing search collections from the primary node:
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:
authentication.
“AIX cluster: Configuring WebSphere Portal to use a database” on page 241
Preparing the WebSphere Application Server Deployment Manager on AIX

IBM WebSphere Portal provides a customized installation package (CIP) that includes IBM WebSphere
Application Server Network Deployment and all required maintenance packages. Use the supplied discs
to install WebSphere Application Server Network Deployment on a dedicated system.
Perform the following steps to prepare the WebSphere Application Server Deployment Manager:
Attention: If you are creating the Deployment Manager profile on the same server that contains the
WebSphere Portal binaries and the same WebSphere Application Server installation, then you can skip the
step about installing or upgrading the Deployment Manager and you can skip the step about collecting
files if the deployment manager is on a remote server.
1. Install WebSphere Application Server Network Deployment or use the CIP to upgrade an existing
installation that you will use for your cluster. Run the following command: cd_root/AIX/
architecture/ifpackage/WAS/install, where cd_root is the root directory of the disc and architecture is
the system's processor architecture.
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.

Note: If you have a 64-bit environment, only the manageprofiles command is supported when
creating profiles.
Installing 315
Table 84. Steps to create a default deployment manager profile.
Method Steps
Profile Management Tool Perform 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
316 WebSphere Portal 7.0 information collected by the wizard, and then click
Create to create the new profile based on the
supplied information.
Tip: You should remember the Administrative
3. Perform the following steps to collect files from the primary node and copy them to the remote
deployment manager:
a. An archive or compressed file will be 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 zip 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:
creating profiles.
Table 85. Choosing between the Profile Management Tool and the manageprofiles task to augment a deployment
manager profile.
Option Steps
Profile Management Tool Perform the following steps to use the Profile Management Tool:
1. Run the ./pmt.sh command from the AppServer_root/bin/
ProfileManagement directory.
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.
6. Click Finish to exit PMT.
manageprofiles command Run the following command from the AppServer_root/bin directory:
manageprofiles.sh -augment -templatePath
/usr/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment
-profileName Dmgr01
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

/usr/IBM/WebSphere/AppServer/profileTemplates directory. The existing
Deployment Manager profile is named Dmgr01 and is located under the
/usr/IBM/WebSphere/AppServer/profiles/Dmgr01 directory.
5. Stop and restart the Deployment Manager server; see "Starting and stopping servers, deployment
managers, and node agents" for information.
6. Verify that the WebSphere Portal administrative users and administrative group exist in the
Deployment Manager cell's user registry. Perform 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.
Installing 317
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 administrative console.
7. Perform 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 administrative 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 administrative console.
Related tasks:
“AIX cluster: Preparing your AIX operating system” on page 235
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.
Perform 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. Perform 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 it
compatible with WebSphere Extended Deployment Operations Optimization.

b. On the WebSphere Portal primary node, install WebSphere Virtual Enterprise and augment the
wp_profile profile to make it compatible with WebSphere Extended Deployment Operations
Optimization.
See the Planning the product installation link below 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 below, make sure
you select Operations Optimization when choosing the type of augmentation to perform. When
using the manageprofiles command as discussed in the link below, be sure to follow the instructions
to augment a stand-alone application server profile.
3. Optional: Run the following command from the wp_profile_root/bin directory to federate the primary
node:
Attention: If you chose the option to automatically federate this new profile to a Deployment
Manager as part of the profile creation, then this step is not necessary. If you are not sure, go ahead
and run the addNode command as documented below. The task will fail if the node is already
federated.
addNode.sh dmgr_hostname dmgr_port -includeapps -includebuses
-username was_admin_user
-password was_admin_password
The above 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 than the Deployment Manager administrator user ID and password, 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 perform the following steps before
rerunning the task:
a. Remove the node if the AddNode task succeeded in creating the node.
b. Log on to the deployment manager and perform 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 directly to any task that you run while creating your
cluster, you may want to add them to the properties file while creating your cluster and 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.
Installing 319
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:
Note: You will also need to run this task if you migrated the primary node from a release prior to
Version 6.1.0, even if you did not configure a database user registry or a property extension
(lookaside) database.
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 Administrative Console.
2) Click Environment > WebSphere Variables.
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/db2jcc.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 236
PK97393; 6.1.1: Utility to generate edition metadata
Planning the product installation
Using the graphical user interface to augment profiles
Using the manageprofiles command to augment and unaugment profiles
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.
Perform the following steps to create the cluster:

1. Run the ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password
task.
2. Since the WebSphere Portal node is now using security settings from the Deployment Manager cell,
you need to update the WebSphere Portal administrative user ID and password to match an
administrative user defined in the cell's user registry. Run the ./ConfigEngine.sh
-DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid task, from the wp_profile_root/
ConfigEngine directory, to update the WebSphere Portal administrative user ID if the Deployment
Manager cell is using a different user registry.
Attention: The password value for -DWasPassword is the Deployment Manager administrative
password.
instance. If the server is stopped, add the -Dskip.ldap.validation=true parameter to the task to skip
the validation.
Fast path: 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 run the ConfigEngine.bat wp-change-portal-admin-user
-DWasPassword=dmgr_password task.
Installing 321
Important: If standalone LDAP security is already enabled on the Deployment Manager cell, delay
running the wp-change-portal-admin-user task until after the cluster-node-config-cluster-setup
(static cluster) or cluster-node-config-dynamic-cluster-setup (dynamic cluster) task completes. After
running the wp-change-portal-admin-user task, start or restart the WebSphere_Portal server to use the
updated administrator user ID.
Note: The WebSphere Portal administrative user ID and administrative group must exist in the
Deployment Manager before running the wp-change-portal-admin-user task. -DnewAdminPw is an
optional parameter to update the Administrative password in the wkplc.properties file if required.
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.
5. Complete the following steps to add a new JCRSeedBus cluster bus member and remove the previous
server bus member:
Note: If you previously configured a data store type of bus member, you need to remove it first
before recreating it. Also you must complete the steps in the "The messaging engine's unique ID does
not match that found in the data store" technote to clean up the tables before recreating it. Otherwise
the recreated bus member does not properly start.
a. Log on to the Deployment Manager Administrative Console.
b. Navigate to Service Integration > Buses and then click JCRSeedBus.
c. Under the Topology heading, click Bus members.
d. Click Add.
e. Click the Cluster radio button to define the type of new bus member and then select the name of
this newly created Portal cluster from the drop-down menu. Click Next to continue.
f. Ensure that the Enable Messaging Engine Policy Assistance checkbox is checked. Then choose the
required messaging engine policy setting; refer to Messaging engine policy assistance for
information.
g. Click Next.
h. Select the Data store radio button and then click Next.
i. Click the name of the first messaging engine listed in the table.
j. Enter the following information on the Specify data store properties panel:
Table 86. Data store fields that need information.
Field Value
Data source JNDI name jdbc/data_source_name, where data_source_name is the
value for the jcr.DataSourceName property in
wkplc_dbdomain.properties file located in the
wp_profile_root/ConfigEngine/properties directory of the
primary node.
Schema name Enter the value of the jcr.DbSchema property in the
Authentication alias Choose the entry in the drop-down list whose name
contains the JCR data source name.
k. Ensure that the Create tables checkbox is checked and then click Next to continue.
l. The Configure messaging engines panel displays containing the list of messaging engines. If any
additional messaging engines are displayed, repeat the steps to configure each additional
messaging engine in the table. Then click Next to continue.
m. Review the heap sizes on the Tune performance parameters panel. Click Next to continue.

Tip: If you want to change the values, click the Change heap sizes checkbox and enter your new
values in the Proposed heap sizes text fields.
n. The Summary panel displays, which allows you to review the messaging engine configuration
changes. Click Previous if you need to go back and make additional changes or click Finish to
complete the configuration process.
o. Click Save to save the changes to the master configuration.
p. The table of bus members displays. Select the Server bus member type with the name of the
Portal server from the primary node and click Remove.
q. Click OK to verify the removal of the server bus member.
r. Navigate to Resources > JMS > Topic Connection Factories > JCRSeedTCF.
s. For the Durable Subscription Home property, select the new bus member you just created from
the menu.
t. Click Save to save the changes to the master configuration.
u. Synchronize changes to the primary node.
6. Run the following tasks to propagate your 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
Creating a dynamic cluster on AIX using WebSphere Virtual Enterprise:
After installing and configuring IBM WebSphere Portal on your primary node and all additional 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 performed 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 Extended Deployment Operations Optimization.
On the WebSphere Portal primary node, install WebSphere Virtual Enterprise, 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 below 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
you select Operations Optimization when choosing the type of augmentation to perform. When using
the manageprofiles command as discussed in the link below, be sure to follow the instructions to
augment a stand-alone application server profile.
Perform the following steps to create a dynamic cluster:

1. Perform the following steps for on the primary node of the dynamic cluster:
Installing 323
a. Run the ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password
task.
b. Since the WebSphere Portal node is now using security settings from the Deployment Manager
cell, you need to update the WebSphere Portal administrative user ID and password to match an
-DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid task, from the
wp_profile_root/ConfigEngine directory, to update the WebSphere Portal administrative user ID if
the Deployment Manager cell is using a different user registry.
running the wp-change-portal-admin-user task until after the cluster-node-config-dynamic-
cluster-setup task completes. After running the wp-change-portal-admin-user task, start or
restart the WebSphere_Portal server to use the updated administrator user ID.
optional parameter to update the Administrative password in the wkplc.properties file if
required.
2. Log on to the deployment manager administrative console.
3. Perform 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. Perform the following steps to add members to the node group:
b. Click on 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. Perform 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 will be used for the dynamic cluster member on this node.
Note: Log on to the deployment manager administrative 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.
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 but it will proceed to
create the new dynamic cluster; therefore, the warning can be ignored.
server bus member:
d. Click Add.
Installing 325
information.
g. Click Next.
Field Value
primary node.
the menu.
admin_password

Related tasks:
Recommended fixes for WebSphere Extended Deployment
Preparing a remote Web server when portal is installed on AIX in a clustered

environment
HTTPEnableConnectorHeaders and HTTPAllowDecodedUrlPercent parameters to 1. Also, if you are
using WebDav, enable it in the Lotus Domino Webserver Administrative Console.
directive.

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.
Installing 327
10. Perform the following steps to access the Web Content Manager content through an external Web
server:
a. Log on to the deployment manager administrative 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
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. Perform 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.
g. Log off of the deployment manager administrative console.
11. 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.
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:
“Preparing the WebSphere Application Server Deployment Manager on AIX” on page 314
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 318
AIX cluster: Preparing user registries:
AIX cluster: Preparing a Domino Directory Server:

Center.
Installing 329
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
user:
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:

1. Install SecureWay Security Server; refer to the IBM SecureWay Security Server for z/OS and OS/390
for information.
server console.
4) Click Add.
your LDAP server.
AIX cluster: Preparing a Novell eDirectory:

Installing 331
server console.
4) Click Add.
your LDAP server.
AIX cluster: Preparing an Oracle Directory Server:

server console.
4) Click Add.
your LDAP server.

AIX cluster: Preparing a Tivoli Directory Server:

group.
server console.
4) Click Add.
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:
Installing 333
AIX cluster: Configuring a stand-alone LDAP user registry without SSL in a clustered environment:

standalone.ldap.id

Installing 335
LDAP configuration.
Important:
Content Manager
Type of LDAP Value


Internet libraries.
If you created your clustered environment then performed the steps in this task, you must now run the
update-jcr-admin task on the secondary node. See Enabling LDAP security after cluster creation 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 337
standalone.ldap.id

instructions.
Installing 339
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
repository.
Installing 341
id
baseDN
nameInRepository
groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:

attributes.
the feature.
LDAP configuration.
Important:
Installing 343
Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:
Important:
cluster.

instructions.
Related tasks:
Adding an LDAP user registry over SSL on AIX in a clustered environment:
Installing 345
federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
Installing 347
groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.

LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.
Installing 349
LDAP user registry:
Important:
cluster.
instructions.

Related tasks:
Adding a database user registry on AIX in a clustered environment:
If you have WebSphere Application Server Version 7.0.x installed, you must install APAR PM23090 and
APAR PM24181 for WebSphere Portal prior to running this task.

Installing 351
Database Steps
1. Install DB2.

AL16UTF16.
v db_files = 1024
v processes = 300
database:
Server.

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
Installing 353
VMM database jars.
repository.
groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
instructions.

Related tasks:
Adding realm support on AIX in a clustered environment:
realmName
securityUse
delimiter
addBaseEntry
configuration.
Installing 355
realmName
realm.groupParent
realmName
addBaseEntry
configuration.

group.
Installing 357
the feature.
instructions.
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 212
“AIX stand-alone: Configuring a stand-alone LDAP user registry without SSL” on page 201
“AIX stand-alone: Configuring a stand-alone LDAP user registry over SSL” on page 205
AIX cluster: Querying the defined attributes:

Adding attributes on AIX in a clustered environment:
Application Server.
b. Navigate 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 Application Server Administrative 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 Application Server Administrative Console under System
administrator > Deployment Manager > Runtime tab > General Properties > Node Name.
Installing 359
parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
instructions.
Related tasks:
Mapping attributes on AIX in a clustered environment:
your LDAP server:

parameters.
standalone.ldap.id
parameters.
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:

Installing 361
parameters.
standalone.ldap.id

parameters.


registry:
instructions.
Related tasks:
AIX cluster: Removing attributes:
Installing 363
model directory.
directory.
AIX cluster: Configuring WebSphere Portal to use dynamic groups in a clustered environment:

nodes.

v Name: memberurl
configuration.
AIX cluster: Enabling referrals for your LDAP user registry in a clustered environment:
Installing 365
Preparing additional nodes 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.
Perform the following tasks to prepare your additional cluster node:

Related tasks:
Installing WebSphere Portal on AIX on the additional cluster nodes:
environment.


v Administration
– Deploy Tool
– Ant Utilities
levels.
ownership:
chmod -R g+rwx /opt/IBM
chgrp -R group_name /opt/IBM
chmod -R g+wr /tmp
following additional tasks based on the type of operating system that you have:
32-bit operating system chmod -R g+rwx /OS_code-Setup
chgrp -R group_name /OS_code-Setup
Enter the appropriate operating system code letter, based on whether you have a 32-bit or
64-bit operating system, where you see OS_code in the additional task:
Installing 367
Graphical user interface ./install.sh -W defaults.isBinaryInstall=true
Console mode ./install.sh -console -W
defaults.isBinaryInstall=true
directory.
Attention: Set the defaults.isBinaryInstall parameter

to true in the response file.
After the installation of the additional cluster node, no application server exists because the
defaults.isBinaryInstall parameter was set to true. The application server will be added when the
new cluster member is created.

Related concepts:
Related tasks:
Related reference:
Choosing the type of additional node 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 additional nodes to the static cluster on AIX:
After installing IBM WebSphere Portal on your additional cluster node, you must add the node to the
cluster to create a highly available environment.
Perform the following steps to add the additional cluster node to the cluster:
1. Perform the following steps to create a directory to store templates:
a. Create a directory called profileTemplates under the PortalServer_root directory.
b. Copy the profileTemplates.zip file from the PortalServer_root/profileTemplates directory on the
primary node to the same location on the additional cluster node.
c. Unzip the profileTemplates.zip file in the same location.
d. Run the chmod -R 755 PortalServer_root/profileTemplates task to change the permissions of
the files/dirs subdirectory, located in the PortalServer_root/profileTemplates directory, because
some files are set to read-only after the copy operation.
e. 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 new profile that will be used for additional cluster
members:
Installing 369
creating profiles.
Table 100. Choose between the Profile Management tool and the manageprofiles task to create a new profile that will
be used for additional cluster members.
Option Steps
4. On the Environment Selection panel, select the WebSphere Portal
7.0.0 > Custom Portal profile, and then click Next.
5. Select the Advanced profile creation radio button and then click
Next.
6. 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.
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 a 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 Security Certificate (Part 1) panel, do not modify the default
values because the security settings are imported from the Portal
configuration archive when the profile is created. Click Next to
continue.
continue.
11. If you choose to federate the profile now, the Port Values
Assignment panel displays. Change any necessary port values and
then click Next.
12. On the Profile Creation Summary panel, review the information
collected by the wizard, and then click Create to create the new
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

/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. Perform the following steps to ensure 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.
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 your wkplc_dbtype.properties file.
4. Run the ./ConfigEngine.sh 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. Run the following command from the wp_profile_root/bin directory to federate the additional cluster
node:
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.
Installing 371
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.
password.

the validation.
(static cluster) or cluster-node-config-dynamic-cluster-setup (dynamic cluster) task completes.
After running the wp-change-portal-admin-user task, start or restart the WebSphere_Portal server to
use the updated administrator user ID.
10. Run the ./ConfigEngine.sh cluster-node-config-cluster-setup-additional
-DWasPassword=dmgr_password task to add the node to your cluster.
server:
application server.
admin_password
13. 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.
Installing 373
Adding an additional node to an existing dynamic cluster on AIX:
After creating your dynamic cluster, you can add additional nodes to expand the capacity of the dynamic
cluster. Install and configure the additional node, then add it to the existing dynamic cluster node group,
and then add it to the existing IBM WebSphere Virtual Enterprise dynamic cluster.
Perform the following steps to add an additional node to an existing WebSphere Virtual Enterprise
dynamic cluster:
members:
creating profiles.

Option Steps
Next.
continue.
Next to continue.
CAUTION:
continue.
continue.
then click Next.
-cellName testCell
-nodeName testNode

directory.
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
Installing 375
augmentation to perform. 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.
additional node:
database settings.
node:

Oracle: ojdbc14.jar
jars.
Installing 377
password.
the validation.
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 will be 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. Perform 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 administrative console.
server:
application server.
admin_password
Related tasks:
Choosing the type of vertical cluster to create on AIX:
Installing 379
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 administrative 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 administrative 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 will list the new server cluster
members.
5. Complete the following steps to enable cache replication:
a. From the deployment manager Administrative Console, navigate 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.
g. Click Save to save your changes to the master configuration.
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, where 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 administrative console for the deployment manager, 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 administrative 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
administrative console on the deployment manager, 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.
f. Click OK.
Installing 381
cluster member.
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.
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.
Installing 383
Related concepts:
“Planning and preparing for Portal Search” on page 2131
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 2140
View steps to configure Portal search for remote search service.
“Configuring the Search and Browse portlet for remote search service” on page 2165
Configure the Search and Browse portlet for remote search service.
“Configuring the default location for search collections” on page 2152
You can modify the default directory location under which search collections are created on a per search
service basis. View some related information.
“Creating or resetting the portal site collection” on page 2184
If you change the configuration of the portal site search collection, you must recreate or reset the
collection.
“Configuring a remote search service” on page 2149
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 102. 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

Table 102. The format for the shared directory. (continued)
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 103. 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.
“Setting up JCR search collections” on page 2171
JCR search collections are special purpose search collections used by WebSphere Portal applications. They
are not designed to be used alongside user-defined search collections. JCR search collections require a
special set up. This includes creation of 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,
Installing 385
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 382
should be used.
Installing multiple clusters in a single cell on AIX:
already exists.
In the following steps, Cluster A will be used to describe the existing cluster. Portal B will be used to
describe the new server profile that will be the basis for the new cluster definition, Cluster B.
Perform the following steps to install multiple clusters in a single cell:

1. 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.
2. Install and configure Portal B; see the "Preparing the primary node" topic and choose the
appropriate operating system for details; you can skip the steps in the "Preparing the WebSphere
Application Server Deployment Manager" because the Deployment Manager is already operational.
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 above statement refers to both the
shared and non-shared domains; all domains should use the same names.

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 below 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 below, make sure you select Operations
Optimization when choosing the type of augmentation to perform. When using the manageprofiles
command as discussed in the link below, 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. Optional: Run the following command from the wp_profile_root\bin directory to federate Portal B:
federated.
addNode.sh dmgr_hostname dmgr_port -includeapps
Installing 387
rerunning the task:
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. Perform 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. Since the WebSphere Portal node is now using security settings from the Deployment Manager
Important: If standalone LDAP security is already enabled on the Deployment Manager cell,
delay running the wp-change-portal-admin-user task until after the cluster-node-config-
cluster-setup (static cluster) or cluster-node-config-dynamic-cluster-setup (dynamic cluster)
task completes. After running the wp-change-portal-admin-user task, start or restart the
WebSphere_Portal server to use the updated administrator user ID.

required.
d. From the administrative 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 non-default 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 Perform 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. Perform the following steps to access the Web Content Manager content through an external
Web server:
1) Log on to the deployment manager administrative console.
2) Select Environment > WebSphere Variables.
3) From the Scope drop-down menu, select the Node=nodename, Server=servername option to
application server.
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. Complete the following steps to add a new JCRSeedBus cluster bus member and remove the
previous server bus member:
Note: If you previously configured a data store type of bus member, you need to remove it
first before recreating it. Also you must complete the steps in the "The messaging engine's
unique ID does not match that found in the data store" technote to clean up the tables before
recreating it. Otherwise the recreated bus member does not properly start.
1) Log on to the Deployment Manager Administrative Console.
2) Navigate to Service Integration > Buses and then click JCRSeedBus.
3) Under the Topology heading, click Bus members.
4) Click Add.
5) Click the Cluster radio button to define the type of new bus member and then select the
name of this newly created Portal cluster from the drop-down menu. Click Next to
continue.
Installing 389
6) Ensure that the Enable Messaging Engine Policy Assistance checkbox is checked. Then
choose the required messaging engine policy setting; refer to Messaging engine policy
assistance for information.
7) Click Next.
8) Select the Data store radio button and then click Next.
9) Click the name of the first messaging engine listed in the table.
10) Enter the following information on the Specify data store properties panel:
Field Value
primary node.
11) Ensure that the Create tables checkbox is checked and then click Next to continue.
12) The Configure messaging engines panel displays containing the list of messaging
engines. If any additional messaging engines are displayed, repeat the steps to configure
each additional messaging engine in the table. Then click Next to continue.
13) Review the heap sizes on the Tune performance parameters panel. Click Next to
continue.
Tip: If you want to change the values, click the Change heap sizes checkbox and enter
your new values in the Proposed heap sizes text fields.
14) The Summary panel displays, which allows you to review the messaging engine
configuration changes. Click Previous if you need to go back and make additional
changes or click Finish to complete the configuration process.
15) Click Save to save the changes to the master configuration.
16) The table of bus members displays. Select the Server bus member type with the name of
the Portal server from the primary node and click Remove.
17) Click OK to verify the removal of the server bus member.
18) Navigate to Resources > JMS > Topic Connection Factories > JCRSeedTCF.
19) For the Durable Subscription Home property, select the new bus member you just
created from the menu.
21) Synchronize changes to the primary node.
e. Save your changes and then restart the deployment manager, the node agent(s), server1, and
the WebSphere_Portal servers.
v Perform the following steps to define a dynamic cluster using Portal B as the basis:
b. Perform 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. Perform the following steps to add members to the node group:
1) Click System administration > Node groups.
2) Click on 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. Perform 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
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 will be 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. Perform the following steps to access the Web Content Manager content through an external
Web server:
application server.
h. Complete the following steps to add a new JCRSeedBus cluster bus member and remove the
Installing 391
4) Click Add.
continue.
7) Click Next.
Field Value
primary node.
continue.
i. Save your changes and then restart the deployment manager, the node agent(s), server1, and
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 server1 and WebSphere_Portal servers on Cluster A and Cluster B.
16. After setting up your multiple clusters, there are additional tasks that you can perform 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 end-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.
Related tasks:
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, multi-cluster 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 an end 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;
Installing 393
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 100
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 perform 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.
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 perform 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.
Installing 395
Related tasks:
“AIX cluster: Tune your servers” on page 382
should be used.
“Connecting to existing database domains” on page 1718
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 on IBM i
WebSphere Portal.
Setting up a stand-alone server on IBM i


IBM i stand-alone: Preparing your System IBM i

WebSphere Portal can be installed locally or remotely using a Windows workstation.
You need the following information to install remotely:

v A supported version of Microsoft® Windows®
v Workstation CD-ROM drive
v TCP/IP connection to the IBM i system where you will install WebSphere Portal
v The IBM i server must be in an unrestricted state
v A valid user ID and password on the IBM i system
v A user profile with a user type (user class) of *SECOFR (other than QSECOFR) to install and configure
WebSphere Portal
You need the following information to install locally:

v IBM i CD-ROM drive
v A valid IBM i user ID and password
WebSphere Portal
IBM i stand-alone: Installing WebSphere Portal

Installing 397
authentication.

3. Setup a static IP address on the server where you will install WebSphere Portal.
v Administration
– Deploy Tool
– Ant Utilities
levels.
Graphical user interface install400.bat
Note: The graphical user interface option is always a
remote installation. Optional attribute: WebSphere Application Server
profiles and configurations are performed with the J9
32-bit JVM, which allows for a faster installation but
slower runtime performance. To achieve better
performance, add the -W enableClassicJVM.active=false
attribute to your installation command to install with
Classic 64-bit JVM.
Console mode remote install400.bat -console

Table 107. Installation task options (continued)
Console mode local install.sh
Optional attribute: WebSphere Application Server
Classic 64-bit JVM.
Silent install remote install400.bat -options "path_to_file\
directory.
Silent install local install.sh -options "path_to_file/
directory.
installation.
v ConfigEngine.sh list-server-ports -DWasPassword=password
v ConfigEngine.sh list-server-ports-by-name -DServerName=server1 -DWasPassword=password
v ConfigEngine.sh list-server-ports-by-name -DServerName=WebSphere_Portal
7. Optional: After the WebSphere Portal installation completes successfully, run the ConfigEngine.sh
> Users and Groups.
Installing 399
Libraries.
b. Add the following line to the file:
LDAP configuration.
Important:
d. Run the ConfigEngine.sh express-memberfixer -DPortalAdminPwd=password
Before you start the WebSphere Application Server server, you need to configure the software license
agreement to set the usage limit from the Proof of Entitlement (POE) or invoice; see Configuring software
license information for details.

Related concepts:
Related tasks:
Related reference:
IBM i stand-alone: Preparing DB2 for IBM i

Related tasks:
“IBM i stand-alone: Preparing your System IBM i” on page 397
IBM i stand-alone: Modifying properties for DB2 for IBM i:


Installing 401
– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
system:
- spaces
- null values
- asterisk (*)
- colon (:)

- vertical bar (|)
- plus sign (+)
- semicolon (;)
- question mark (?)
Notes:
IBM DB2 for i.
server.
understand.
Installing 403
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.

IBM i stand-alone: Creating user profiles for DB2 for IBM i:
Before you begin:

can be shared.
new password.
environment.
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.
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 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 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
Installing 405
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: Modifying properties for DB2 for IBM i” on page 401
IBM i stand-alone: Configuring the portal to use DB2 for IBM i:
Before you begin:


the task to stall.
Note:
Installing 407
Related tasks:
“IBM i stand-alone: Creating user profiles for DB2 for IBM i” on page 405
IBM i stand-alone: Verifying the DB2 for IBM i configuration:


Related tasks:
“IBM i stand-alone: Creating user profiles for DB2 for IBM i” on page 405
“IBM i stand-alone: Creating databases on DB2 for IBM i” on page 405
IBM i stand-alone: Preparing a remote Web server

directive.

Installing 409
Related tasks:
authentication.
Related reference:
IBM i stand-alone: Configuring WebSphere Portal to use a user registry

LDAP user registry.
information.

Related tasks:
authentication.
“IBM i stand-alone: Preparing DB2 for IBM i” on page 401
“Managing your user registry on i” on page 2553
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.
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.
your LDAP server.
Installing 411
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:

standalone.ldap.id

Installing 413
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.
Important:
d. Run the ConfigEngine.sh express-memberfixer -DmemberfixerRealm=realm_name

Content Manager
Type of LDAP Value

Internet libraries.
Related tasks:
“IBM i cluster: Adapting the attribute configuration” on page 492
IBM i stand-alone: Configuring a stand-alone LDAP user registry over SSL:

Installing 415
standalone.ldap.id

Installing 417
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 419
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.
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.
Important:
Content Manager
Type of LDAP Value
Installing 421
Content Manager (continued)
Type of LDAP Value

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 i” on page 2575
IBM i stand-alone: Adding an LDAP user registry over SSL:

Installing 423
federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
Installing 425
groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
feature.

LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:
Important:
Installing 427
cluster.

Related tasks:
“Deleting the repository on i” on page 2575
IBM i stand-alone: Adding a database user registry:

2. Perform the following steps to create the IBM DB2 for i database:
Installing 429
a. Login to a remote 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. Navigate 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:
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.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Installing 431
Related tasks:
IBM i stand-alone: Adding realm support:
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.
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 -DWasPassword=password
Installing 433
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
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 411
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:
Installing 435
Application Server.
c. Run the ConfigEngine.sh wp-la-install-ear -DWasPassword=password task.
parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
6. Run the ConfigEngine.sh wp-add-property -DWasPassword=password task to add the attribute to the
user registry.
Related tasks:
IBM i stand-alone: Mapping attributes:

your LDAP server:
parameters.
standalone.ldap.id
parameters.
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 437
parameters.
standalone.ldap.id


file. (continued)
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-
c. Run the ConfigEngine.sh wp-update-attribute-config -DWasPassword=password task, from the
Installing 439
Related tasks:
“IBM i stand-alone: Querying the define attributes” on page 435
IBM i stand-alone: Removing attributes:
model directory.
directory.

Related tasks:
“IBM i stand-alone: Querying the define attributes” on page 435
“IBM i stand-alone: Adding attributes” on page 435
IBM i stand-alone: Configuring WebSphere Portal to use dynamic groups:
nodes.

Installing 441
v Name: memberurl
configuration.
Related tasks:
“IBM i stand-alone: Choosing your user registry model” on page 412
IBM i stand-alone: Enabling referrals for your LDAP user registry:

Related tasks:
“IBM i stand-alone: Choosing your user registry model” on page 412
“IBM i stand-alone: Adapting the attribute configuration” on page 435
IBM i stand-alone: Tune your servers

should be used.
Installing 443
Related tasks:
authentication.
“IBM i stand-alone: Preparing DB2 for IBM i” on page 401
Setting up a cluster on IBM i

dynamic.
hardware.
node.

IBM i cluster: Preparing your IBM i operating system

WebSphere Portal can be installed locally or remotely using a Windows workstation.
You need the following information to install remotely:

v A supported version of Microsoft® Windows®
v Workstation CD-ROM drive
v TCP/IP connection to the IBM i system where you will install WebSphere Portal
Installing 445
v A valid user ID and password on the IBM i system
WebSphere Portal
You need the following information to install locally:

v IBM i CD-ROM drive
v A valid IBM i user ID and password
WebSphere Portal
Preparing the primary node on IBM i

IBM i cluster: Installing WebSphere Portal:
authentication.
v Administration
– Deploy Tool
– Ant Utilities

levels.
Classic 64-bit JVM.
Console mode remote install400.bat -console
Console mode local install.sh
Classic 64-bit JVM.
directory.
directory.
Installing 447
installation.
v ConfigEngine.sh list-server-ports -DWasPassword=password
v ConfigEngine.sh list-server-ports-by-name -DServerName=server1 -DWasPassword=password
v ConfigEngine.sh list-server-ports-by-name -DServerName=WebSphere_Portal
7. 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.
Important:
d. Run the ConfigEngine.sh express-memberfixer -DPortalAdminPwd=password
Installing 449
Related concepts:
Related tasks:
“Creating a Portal custom profile on IBM i” on page 2101
“Preparing the system for multiple profile support on IBM i” on page 2099
Related reference:
IBM i clustered server: Setting up a remote database:

IBM i clustered server: Preparing DB2 for IBM i:
IBM i clustered server: Modifying DB2 for IBM i database properties:


– release
Installing 451
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
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 453
JDBC driver class.
IBM i clustered server: Creating DB2 for IBM i user profiles:
Before you begin:

can be shared.

new password.
environment.
IBM i clustered server: Creating remote DB2 for IBM i databases:
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.
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 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 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
Installing 455
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: Modifying DB2 for IBM i database properties” on page 451
IBM i clustered server: Transferring DB2 for IBM i manually:
Before you begin:

the task to stall.
Note:

Related tasks:
“IBM i clustered server: Creating DB2 for IBM i user profiles” on page 454
IBM i clustered server: Verifying database connections:

Installing 457
Related tasks:
“IBM i clustered server: Creating DB2 for IBM i user profiles” on page 454
“IBM i clustered server: Creating remote DB2 for IBM i databases” on page 455
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
WebSphere 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 zip the

Related tasks:
authentication.
Removing search collections on IBM i:

Collections.
deleted.
Related tasks:
authentication.
“IBM i clustered server: Setting up a remote database” on page 450
Preparing the WebSphere Application Server Deployment Manager on IBM i

Installing 459
installation that you will use for your cluster. Run the following command: cd_root/ISERIES/
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 dmgr
-profilePath AppServer_root/dmgr
-cellName dmgrCell
-nodeName yourhostname_dmgr
-enableAdminSecurity true
-adminUserName dmgradmin
-adminPassword dmgrpass
Restriction: If you plan to use the backup and restore task documented in the Information Center,
you must use the default profile path for the deployment manager profile; otherwise, the backup and
restore tasks cannot locate the profile.
deployment manager:
for example this may be a subdirectory under the AppServer directory and it will contain the bin
and profileTemplates directories.
4. Run the following command from the AppServer_root/bin directory:
/QIBM/ProdData/WebSphere/AppServer/V7/ND/profileTemplates/management.portal.augment
-profileName Dmgr01
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 /QIBM/ProdData/WebSphere/
AppServer/V7/ND/profileTemplates directory. The existing Deployment Manager profile is named
Dmgr01 and is located under the /QIBM/ProdData/WebSphere/AppServer/V7/ND/profiles/Dmgr01
directory.
b. Click Create.

e. Click Create.
i. Click Add Users.
e. Click Apply.
Related tasks:
“IBM i cluster: Preparing your IBM i operating system” on page 445
Creating the cluster on IBM i


password.
node:
Installing 461
federated.
rerunning the task:
directory:
deployment manager.

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.
5. Run the ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password task.
administrative user defined in the cell's user registry. 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, to update
the WebSphere Portal administrative user ID if the Deployment Manager cell is using a different user
registry.
Installing 463
password.
the validation.
7. Run the ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password task.
9. Complete the following steps to add a new JCRSeedBus cluster bus member and remove the
before recreating it. Also you must complete the steps in the "The messaging engine's unique ID
does not match that found in the data store" technote to clean up the tables before recreating it.
Otherwise the recreated bus member does not properly start.
d. Click Add.
f. Ensure that the Enable Messaging Engine Policy Assistance checkbox is checked. Then choose
the required messaging engine policy setting; refer to Messaging engine policy assistance for
information.
g. Click Next.

Field Value
primary node.
Tip: If you want to change the values, click the Change heap sizes checkbox and enter your
new values in the Proposed heap sizes text fields.
the menu.
a. stopServer.sh WebSphere_Portal_servername -username admin_userid -password
admin_password
b. startServer.sh WebSphere_Portal_servername
Installing 465
Related tasks:
“Preparing the primary node on IBM i” on page 446
Preparing the Web server when portal is installed on IBM i in a clustered

environment
directive.


server:
application server.
Related tasks:
“Preparing the WebSphere Application Server Deployment Manager on IBM i” on page 459
Related reference:
IBM i cluster: Preparing user registries

Installing 467
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.
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.
your LDAP server.

Configuring WebSphere Portal to use a user registry on IBM i in a clustered
environment
LDAP user registry.
information.
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:
Installing 469
standalone.ldap.id

LDAP configuration.
Important:
Installing 471
Content Manager
Type of LDAP Value

Internet libraries.
instructions.

Related tasks:
Configuring a stand-alone LDAP user registry over SSL on IBM i in a clustered environment:

standalone.ldap.id
Installing 473

instructions.
Related tasks:
Configuring the default federated repository on IBM i in a clustered environment:
Installing 475
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:

federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
Installing 477
groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
feature.

LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.
Installing 479
LDAP user registry:
Important:
cluster.
instructions.

Related tasks:
Adding an LDAP user registry over SSL on IBM i in a clustered environment:

Installing 481
federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
groups are stored.
Installing 483
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
feature.
LDAP configuration.
Important:

Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 485
instructions.
Related tasks:
Adding a database user registry on IBM i in a clustered environment:


2. Perform the following steps to create the IBM DB2 for i database:
a. Login to a remote 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. Navigate to the following directory: wp_profile_root/ConfigEngine/properties directory.
heading:
db_type.DbDriver
db_type.DbLibrary
federated.db.DbType
federated.db.DbUrl
Installing 487
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:
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.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
instructions.
Related tasks:
Adding realm support on IBM i in a clustered environment:
Installing 489
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.

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 -DWasPassword=password
f. Run the ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password
group.
Installing 491
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
feature.
instructions.
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 418
“IBM i stand-alone: Adding an LDAP user registry over SSL” on page 423
“IBM i stand-alone: Configuring a stand-alone LDAP user registry without SSL” on page 412
“IBM i stand-alone: Configuring a stand-alone LDAP user registry over SSL” on page 415
IBM i cluster: Querying the defined attributes:
Run the ConfigEngine.sh wp-query-attribute-config -DWasPassword=password task, from the

Installing 493
Adding attributes on IBM i in a clustered environment:
1. Complete the followings steps to install the required Enterprise Archive (.ear) file on WebSphere
Application Server.
b. Navigate to the wp_profile_root/ConfigEngine directory on the primary node.
c. Run the ConfigEngine.sh wp-la-install-ear -DWasPassword=dmgr_password
parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
6. Run the ConfigEngine.sh wp-add-property -DWasPassword=password task to add the attribute to the
user registry.

instructions.
Related tasks:
Mapping attributes on IBM i in a clustered environment:
your LDAP server:
parameters.
standalone.ldap.id
Installing 495
Table 123. Identifying your LDAP server in the wkplc.properties file. (continued)
parameters.
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-


parameters.
standalone.ldap.id

parameters.


registry:
Installing 497
Stand-alone ConfigEngine.sh wp-update-standalone-ldap-attribute-
Federated ConfigEngine.sh wp-update-federated-ldap-attribute-
c. Run the ConfigEngine.sh wp-update-attribute-config -DWasPassword=password task, from the
instructions.
Related tasks:
IBM i cluster: Removing attributes:

model directory.
directory.
IBM i cluster: Configuring WebSphere Portal to use dynamic groups in a clustered environment:
Installing 499
nodes.

v Name: memberurl
configuration.
IBM i cluster: Enabling referrals for your LDAP user registry in a clustered environment:

Preparing additional nodes on IBM i


Related tasks:
Installing WebSphere Portal on IBM i on the additional cluster nodes:
environment.

v Administration
– Deploy Tool
– Ant Utilities
Installing 501
levels.
Classic 64-bit JVM.
Console mode remote install400.bat -console -W
Console mode local setup.sh -W defaults.isBinaryInstall=true
Classic 64-bit JVM.
directory.


directory.
Related concepts:
Related tasks:
Adding additional nodes to the cluster on IBM i:
e. Run the installPortalTemplates.sh AppServer_root task from the newly created
Installing 503
2. Run the following command from the AppServer_root/bin directory:
manageprofiles -create -templatePath
/QIBM/ProdData/Websphere/PortalServer/V7/portal_family/portal/profileTemplates/managed.portal
-profilePath /QIBM/Userdata/Websphere/appserver/V7/ND/profiles/testManagedPortal1
-serverName server1
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 /QIBM/ProdData/Websphere/
PortalServer/V7/portal_family/portal/profileTemplates/managed.portal directory. The new
profile is named testManagedPortal1 and is located under the /QIBM/Userdata/Websphere/appserver/
V7/ND/profiles/testManagedPortal1 directory.
additional node:
4. Run the ConfigEngine.sh validate-database -DWasPassword=password task to validate your database
settings.
node:
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
Installing 505
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.
registry.
password.
the validation.
10. Run the ConfigEngine.sh cluster-node-config-cluster-setup-additional
server:
application 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 administrative 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.
The Servers > Server Types > WebSphere application servers view will list the new server
cluster members.
Installing 507
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, where unique vertical cluster servername is the name you specified when
you created the cluster member.
setup task.
server:
application server.
Resynchronize.
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 on the additional cluster nodes” on page 501
environment.
IBM i cluster: Tune your servers

should be used.
Related tasks:
Configuring search in a cluster on i

Installing 509
Related tasks:
“Preparing additional nodes on IBM i” on page 501
Configuring Portal Search in a cluster on i:
Portal cluster.
accordingly.
Notes:

Related concepts:
Portal Search.
Related tasks:
collection.
Configuring JCR search in a cluster on i:
directory.
search
Installing 511


portlet:
e. Click OK.
deleted.
for information.
Setting up multiple clusters on IBM i

new profile.
please contact IBM.
Related tasks:
“IBM i cluster: Tune your servers” on page 509
should be used.
Installing multiple clusters in a single cell on IBM i:
already exists.

Installing 513
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.
federated.
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.
registry.
password.
the validation.
Installing 515
13. Perform 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
“Setting up multiple clusters on IBM i” on page 512
c. Perform the following steps to access the Web Content Manager content through an external Web
server:
application server.
4) Click Add.
name of this newly created Portal cluster from the drop-down menu. Click Next to continue.
7) Click Next.
Field Value
primary node.

Table 131. Data store fields that need information. (continued)
Field Value
12) The Configure messaging engines panel displays containing the list of messaging engines.
If any additional messaging engines are displayed, repeat the steps to configure each
additional messaging engine in the table. Then click Next to continue.
13) Review the heap sizes on the Tune performance parameters panel. Click Next to continue.
Tip: If you want to change the values, click the Change heap sizes checkbox and enter your
new values in the Proposed heap sizes text fields.
configuration changes. Click Previous if you need to go back and make additional changes
or click Finish to complete the configuration process.
19) For the Durable Subscription Home property, select the new bus member you just created
from the menu.
e. Save your changes and then restart the deployment manager, the node agent(s), server1, and the
WebSphere_Portal servers.
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 517
Routing requests across clusters on IBM i:
of user requests.
Sharing database domains between clusters on IBM i

Manager.
clusters:

Related tasks:
“IBM i cluster: Tune your servers” on page 509
should be used.
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
Installing 519
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 (5722SS1, Option 43) or OS/400 - Additional Fonts (5761SS1, Option 43)
installed.
Perform 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.
Configuring an HTML rendering server on IBM i

After you have installed OS/400 - Additional Fonts (5722SS1, Option 43), which is for Version 5R4, or
OS/400 - Additional Fonts (5761SS1, Option 43), which is for Version 6R1, 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.
Perform 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 may see output such as this (the number
following 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.
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.
Perform the following steps to associate the HTML rendering server (X virtual frame buffer for X server)
with WebSphere Portal:
1. Log into the IBM WebSphere Application Server administrative console.

2. Click Servers > Server Types > WebSphere application servers > WebSphere_Portal > Server
Infrastructure > Java and Process Management > Process definition > Additional Properties >
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. Perform the following steps to stop and restart the server1 and WebSphere_Portal servers, where
server1 is the name of the WebSphere Application Server and 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 server1 -username admin_userid -password admin_password command to
stop the WebSphere Application Server.
c. Enter the stopServer WebSphere_Portal -username admin_userid -password admin_password
command to stop the WebSphere Portal server.
d. Enter the startServer server1 command.
e. Enter the startServer WebSphere_Portal command.
Installing on Linux
WebSphere Portal.
Setting up a stand-alone server on Linux

Installing 521
Linux stand-alone: Preparing your Linux operating system

Perform the following steps to prepare your Linux machine:

1. Perform the steps to prepare your operating system for the IBM WebSphere Application Server
installation that comes with WebSphere Portal; see Preparing Linux systems for installation for
information.
4. Install and configure X server on Linux (for example X-Windows or GNOME) to use the graphical
user interface the installation program provides.
5. Verify your operating system meets all requirements for WebSphere Application Server in addition to
WebSphere Portal. For example, some distributions of Linux must have specific X11 libraries available
prior to installing the WebSphere Application Server. Consult the WebSphere Application Server 7.0
information center for additional information.
64-bit Red Hat Enterprise Linux 6: WebSphere Portal requires both 32-bit and 64-bit runtime support.
By default, RHEL 6 only installs 64-bit runtime support. Consult the WebSphere Application Server
7.0 information center for RHEL 6 library and package requirements.

Linux stand-alone: Installing WebSphere Portal
authentication.

v Administration
– Deploy Tool
– Ant Utilities
levels.
ownership:
chmod -R g+wr /tmp
Installing 523
directory.
location".

installation.
> Users and Groups.
Libraries.
Installing 525
LDAP configuration.
Important:
task.
Method Task
port number
to ports file

WC_adminhost=10042

Related concepts:
Related tasks:
Related reference:
Linux stand-alone: Configuring WebSphere Portal to use a database


Related tasks:
“Linux stand-alone: Preparing your Linux operating system” on page 522
Linux stand-alone: Setting up a remote DB2 database:
Linux stand-alone: Installing DB2:
Installing 527
Before you begin:
required databases.
Portal.
2. 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.
4. 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.

Linux stand-alone: Modifying DB2 database properties:

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
Installing 529
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback


driver class.
Linux stand-alone: Creating groups and assigning users:
Related tasks:
“Linux stand-alone: Installing DB2” on page 527
Linux stand-alone: Creating DB2 databases:
databases manually.
Installing 531
Related tasks:
“Linux stand-alone: Modifying DB2 database properties” on page 529
Linux stand-alone: Creating a local DB2 database automatically:
Linux stand-alone: Creating a remote or local DB2 database manually:

running.
instance owner.

that you run:
Notes:
six times.

Installing 533
db2 "TERMINATE"
by name.
domain.

Linux stand-alone: Setting up DB2 automatically or manually:

Related tasks:
“Linux stand-alone: Creating groups and assigning users” on page 531
Linux stand-alone: Setting up DB2 automatically:
ConfigEngine task.
Linux stand-alone: Running a task to automatically setup DB2 databases:
Linux stand-alone: Setting up DB2 manually:
Linux stand-alone: Creating DB2 database schemas:
Installing 535
users
admins
guests
public
local
IBM
SQL
SYS
environment.

createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
createSchema.sql
Linux stand-alone: Granting privileges to DB2 database administration users:

Table 137. Location of SQL script templates by database domain for information about specific permissions granted
to schema-owning configuration database users
database user:
users
Installing 537
users (continued)

to schema-owning runtime database users
Installing 539
to non-schema-owning runtime database users
Linux 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
Linux stand-alone: Collecting JCR collation support:
for instructions.
server:
Installing 541
b. Run the command:
using password.

# English
# Swedish

Related tasks:
“Linux stand-alone: Creating DB2 databases” on page 531
databases manually.
Linux stand-alone: Configuring WebSphere 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.

Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 543
Note:
files:
name are the same.


using password
db2 terminate
-p password
Installing 545
Related tasks:
databases manually.
“Linux stand-alone: Setting up DB2 automatically or manually” on page 534
Linux stand-alone: Configuring DB2 for large file handling in WCM:

Related tasks:
databases manually.
Linux stand-alone: Changing DB2 driver types:
configuration task.
Note:
Installing 547
JDBC driver.

Related tasks:
databases manually.
“Linux stand-alone: Configuring WebSphere Portal to use DB2” on page 543
Linux stand-aloneserver: Preparing IBM DB2 for i:
Linux stand-alone: Modifying properties for IBM DB2 for i:


Installing 549
– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)

- question mark (?)
Notes:
IBM DB2 for i.
server.
understand.
releaseDS
Installing 551
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.

Linux stand-alone: Creating user profiles for IBM DB2 for i:
Before you begin:

can be shared.
new password.
environment.
Linux stand-alone: Creating and setting up IBM DB2 for i databases automatically:
Related tasks:
“Linux stand-alone: Modifying properties for IBM DB2 for i” on page 549
Linux stand-alone: Configuring the portal to use IBM DB2 for i:
Before you begin:

Installing 553
the task to stall.
Note:

Related tasks:
“Linux stand-alone: Creating user profiles for IBM DB2 for i” on page 553
Linux stand-alone: Verifying the IBM DB2 for i configuration:

Installing 555
Related tasks:
“Linux stand-alone: Creating user profiles for IBM DB2 for i” on page 553
“Linux stand-alone: Creating and setting up IBM DB2 for i databases automatically” on page 553
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:
export EXTSHM=ON
remote database.
Linux stand-alone: Modifying properties for DB2 for z/OS:


– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
Installing 557
understand.
Note:
for the domain.
DbName.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback

this value.
driver class.
Linux stand-alone: Using JCL templates to set up DB2 for z/OS:

created.
Installing 559
successfully.
authority.

on the database
authority.

Related tasks:
“Linux stand-alone: Installing DB2 for z/OS” on page 556
Creating users:
installation.


(R) - at runtime





Installing 561

where:
data.
Related tasks:
“Linux stand-alone: Modifying properties for DB2 for z/OS” on page 556
Linux stand-alone: Creating databases on DB2 for z/OS:

machine.
the databases.

500 DEFINE NO;
Related tasks:
“Linux stand-alone: Using JCL templates to set up DB2 for z/OS” on page 559
Linux stand-alone: Granting privileges to DB2 for z/OS users:
Installing 563
database user:
to non-schema-owning configuration database users

Installing 565
Related tasks:
“Creating users” on page 560
Linux stand-alone: Creating the Java content repository database on DB2 for z/OS:
following commands:
...
Notes:
sample:


Installing 567

Related tasks:
“Linux stand-alone: Creating databases on DB2 for z/OS” on page 562
Linux stand-alone: Assigning custom tablespaces on DB2 for 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
Installing 569
Related tasks:
“Linux stand-alone: Granting privileges to DB2 for z/OS users” on page 563
Linux stand-alone: Configuring the portal to use DB2 for z/OS:
Before you begin:



Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
domains.
Installing 571
...

Related tasks:
“Linux stand-alone: Creating the Java content repository database on DB2 for z/OS” on page 566
“Linux stand-alone: Granting privileges to DB2 for z/OS users” on page 563
Linux stand-alone: Setting up a remote Oracle or Oracle RAC database:
Linux stand-alone: Installing Oracle or Oracle RAC:
Before you begin:

$ gsdctl start
$ lsnrctl start
$ agentctl start
Linux stand-alone: Modifying Oracle or Oracle RAC database properties:
to the Oracle database.

Installing 573
– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl

understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
server.
Installing 575
class.
Linux stand-alone: Creating Oracle or Oracle RAC databases:
information:
Server Mode.

pre_page_sga = true
as follows:
FORCE
EXACT
Related tasks:
“Linux stand-alone: Installing Oracle or Oracle RAC” on page 573
Linux stand-alone: Setting up Oracle or Oracle RAC automatically or manually:
Note:
database.
Installing 577
Related tasks:
“Linux stand-alone: Modifying Oracle or Oracle RAC database properties” on page 573
Linux stand-alone: Setting up Oracle or Oracle RAC automatically:
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
createUsers.sql
createUsers.sql
createUsers.sql
createUsers.sql
Linux stand-alone: Granting privileges to Oracle or Oracle RAC database users:
Installing 579
database user:

Installing 581

Linux stand-alone: Creating JCR table spaces:
Installing 583
environment.
command.
Linux 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
Linux stand-alone: Configuring WebSphere Portal to use Oracle or Oracle RAC:
Oracle database you have installed and set up. Follow these steps to transfer WebSphere 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 you begin:

Tips:
Repository schema.

Installing 585
files:
name are the same.


Related tasks:
“Linux stand-alone: Modifying Oracle or Oracle RAC database properties” on page 573
“Linux stand-alone: Creating Oracle or Oracle RAC databases” on page 576
Linux stand-alone: Setting up a SQL Server database:
Linux stand-alone: Installing SQL Server:
Installing 587

for information.
information.

steps:
sqljdbc_xa.dll
Linux stand-alone: Modifying SQL Server database properties:

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
Installing 589
– dbdomain.DbUrl
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback

JDBC driver class.
Linux stand-alone: Creating databases manually on SQL Server:

Related tasks:
“Linux stand-alone: Installing SQL Server” on page 587
Linux stand-alone: Setting up SQL Server automatically or manually:
Installing 591
table spaces.
Note:
database.
Related tasks:
“Linux stand-alone: Modifying SQL Server database properties” on page 589
Linux stand-alone: Setting up SQL Server automatically:
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 SQL Server database schemas and users:
Before you begin:

installation.

createSchema.sql
createUsers.sql
Installing 593
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 595
to non-schema-owning configuration database users (continued)

Installing 597
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
Linux stand-alone: Configuring WebSphere Portal to use SQL Server on Linux:
Before you begin:

Installing 599
Tips:
Repository schema.
files:
name are the same.


Related tasks:
“Linux stand-alone: Modifying SQL Server database properties” on page 589
“Linux stand-alone: Creating databases manually on SQL Server” on page 591
Linux stand-alone: Verifying database configuration:
Installing 601
in a browser:
source is wpdbDS.
environment.
Linux stand-alone: Preparing a remote Web server

directive.


Related tasks:
authentication.
Related reference:
Linux stand-alone: Configuring WebSphere Portal to use a user registry

LDAP user registry.
information.
Installing 603
Related tasks:
authentication.
“Linux stand-alone: Configuring WebSphere Portal to use a database” on page 527
“Managing your user registry on Linux” on page 2577
Linux stand-alone: Preparing user registries:
Linux stand-alone: Preparing a Domino Directory Server:

Center.
Server installation > Installing Domino on Linux and perform this task.
Last Name
wpsbind
User Name

wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
user:
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 605
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
Linux stand-alone: Preparing a SecureWay Security Server:

for information.
server console.
4) Click Add.
your LDAP server.
Linux stand-alone: Preparing a Novell eDirectory:

server console.

4) Click Add.
your LDAP server.
Linux stand-alone: Preparing an Oracle Directory Server:

server console.
4) Click Add.
your LDAP server.
Installing 607
Linux stand-alone: Preparing a Tivoli Directory Server:

group.
server console.
4) Click Add.
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 609

LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.
Installing 611
Related tasks:
“Linux cluster: Adapting the attribute configuration” on page 764
Linux stand-alone: Configuring a stand-alone LDAP user registry over SSL:

standalone.ldap.id

Installing 613
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
Installing 615
repository.
id
baseDN
nameInRepository

groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
Installing 617
LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:

Important:
cluster.
Installing 619
Related tasks:
“Deleting the repository on Linux” on page 2602
Linux stand-alone: Adding an LDAP user registry over SSL:

federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 621
repository.
id
baseDN
nameInRepository
groups are stored.

personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
Important:
Installing 623
Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:
Important:
cluster.

Related tasks:
“Deleting the repository on Linux” on page 2602
Linux stand-alone: Adding a database user registry:
Installing 625

Database Steps
1. Install DB2.

Table 160. Steps for creating a new database to use as a database user registry. (continued)
Database Steps
AL16UTF16.
v db_files = 1024
v processes = 300
database:
Server.
heading:
db_type.DbDriver
db_type.DbLibrary
federated.db.DbType
federated.db.DbUrl
federated.db.id
federated.db.baseDN
Installing 627
federated.db.DbUser
federated.db.DbName
database jars.
Oracle: ojdbc14.jar
VMM database jars.
repository.

groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
Linux stand-alone: Adding realm support:
Installing 629
realmName
securityUse
delimiter
addBaseEntry
configuration.
realmName
realm.groupParent

realmName
addBaseEntry
configuration.
group.
Installing 631
the feature.
Linux stand-alone: Adapting the attribute configuration:
repositories.
LDAP schema

Linux stand-alone: Querying the defined attributes:

Linux stand-alone: Adding attributes:
Application Server.
parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
Installing 633
Related tasks:
Linux stand-alone: Mapping attributes:
your LDAP server:
parameters.
standalone.ldap.id

Table 161. Identifying your LDAP server in the wkplc.properties file. (continued)
parameters.
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:

Installing 635
parameters.
standalone.ldap.id

parameters.


registry:

Linux stand-alone: Removing attributes:
model directory.
Installing 637
directory.
Linux stand-alone: Configuring WebSphere Portal to use dynamic groups:
nodes.


v Name: memberurl
configuration.
Linux stand-alone: Enabling referrals for your LDAP user registry:
Installing 639
Linux stand-alone: Tune your servers

should be used.
Related tasks:
authentication.
“Linux stand-alone: Configuring WebSphere Portal to use a database” on page 527
Setting up a cluster on Linux

dynamic.
hardware.

node.
Installing 641
Linux cluster: Preparing your Linux operating system

Perform the following steps to prepare your Linux machine:

1. Perform the steps to prepare your operating system for the IBM WebSphere Application Server
installation that comes with WebSphere Portal; see Preparing Linux systems for installation for
information.
4. Install and configure X server on Linux (for example X-Windows or GNOME) to use the graphical
user interface the installation program provides.
5. Verify your operating system meets all requirements for WebSphere Application Server in addition to
WebSphere Portal. For example, some distributions of Linux must have specific X11 libraries available
prior to installing the WebSphere Application Server. Consult the WebSphere Application Server 7.0
information center for additional information.
64-bit Red Hat Enterprise Linux 6: WebSphere Portal requires both 32-bit and 64-bit runtime support.
By default, RHEL 6 only installs 64-bit runtime support. Consult the WebSphere Application Server
7.0 information center for RHEL 6 library and package requirements.
Preparing the primary node on Linux

Linux cluster: Installing WebSphere Portal:

authentication.
v Administration
– Deploy Tool
– Ant Utilities
levels.
ownership:
chmod -R g+wr /tmp
Installing 643
directory.
location".

installation.
> Users and Groups.
Libraries.
Installing 645
LDAP configuration.
Important:
task.
Method Task
port number
to ports file

WC_adminhost=10042

Related concepts:
Related tasks:
“Creating a Portal custom profile on Linux” on page 2108
“Preparing the system for multiple profile support on Linux” on page 2104
Related reference:
Linux clustered server: Configuring WebSphere Portal to use a database:
Installing 647
Linux clustered server: Setting up a remote DB2 database:
Linux clustered server: Installing DB2:
Before you begin:

required databases.
Portal.

2. 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.
4. 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.
Linux clustered server: Modifying DB2 database properties:

– release
– customization
Installing 649
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback


driver class.
Linux clustered server: Creating groups and assigning users:
Installing 651
Related tasks:
“Linux clustered server: Installing DB2” on page 648
Linux clustered server: Creating DB2 databases:
databases manually.
Related tasks:
“Linux clustered server: Modifying DB2 database properties” on page 649
Linux clustered server: Creating a local DB2 database automatically:
Linux clustered server: Creating a remote or local DB2 database manually:


running.
instance owner.
that you run:
Notes:
six times.
Installing 653

db2 "TERMINATE"
by name.
domain.


Linux clustered server: Setting up DB2 automatically or manually:

Related tasks:
“Linux clustered server: Creating groups and assigning users” on page 651
Linux clustered server: Setting up DB2 automatically:
ConfigEngine task.
Linux clustered server: Running a task to automatically setup DB2 databases:
Linux clustered server: Setting up DB2 manually:
Installing 655
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 657
to schema-owning configuration database users (continued)
database user:
users

Installing 659
to schema-owning runtime database users (continued)

to non-schema-owning runtime database users (continued)
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
Installing 661
v likeminds
Linux clustered server: Collecting JCR collation support:
for instructions.
server:
b. Run the command:
using password.


# English
# Swedish
Related tasks:
“Linux clustered server: Creating DB2 databases” on page 652
databases manually.
Linux clustered server: Configuring WebSphere Portal to use DB2:
Before you begin:

Tips:
Installing 663
Repository schema.

Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Note:

files:
name are the same.

using password
Installing 665
db2 terminate
-p password
Related tasks:
databases manually.
“Linux clustered server: Setting up DB2 automatically or manually” on page 655
Linux clustered server: Configuring DB2 for large file handling in WCM:
Related tasks:
databases manually.
Linux clustered server: Changing DB2 driver types:
configuration task.
Note:
Installing 667
JDBC driver.

Related tasks:
databases manually.
“Linux clustered server: Configuring WebSphere Portal to use DB2” on page 663
Linux clustered server: Setting up IBM DB2 for i:
Linux clustered server: Modifying IBM DB2 for i database properties:


Installing 669
– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)

- question mark (?)
Notes:
IBM DB2 for i.
server.
understand.
releaseDS
Installing 671
communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.

Linux clustered server: Create IBM DB2 for i user profiles:
Before you begin:

can be shared.
new password.
environment.
Linux clustered server: Creating and setting up IBM DB2 for i databaes automatically:
Related tasks:
“Linux clustered server: Modifying IBM DB2 for i database properties” on page 669
Linux clustered server: Transferring IBM DB2 for i manually:
Before you begin:

Installing 673
the task to stall.
Note:

Related tasks:
“Linux clustered server: Create IBM DB2 for i user profiles” on page 673
Linux clustered server: Verifying IBM DB2 for i database connections:

Installing 675
Related tasks:
“Linux clustered server: Create IBM DB2 for i user profiles” on page 673
“Linux clustered server: Creating and setting up IBM DB2 for i databaes automatically” on page 673
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:
export EXTSHM=ON
remote database.
Linux clustered server: Using JCL templates to set up DB2 for z/OS:


created.
successfully.
authority.

on the database
authority.

Installing 677
Linux clustered server: Creating DB2 for z/OS users:
installation.

(R) - at runtime







where:
data.
Related tasks:
“Linux clustered server: Installing DB2 for z/OS” on page 676
Linux clustered server: Creating remote DB2 for z/OS databases:

machine.
Installing 679
the databases.
500 DEFINE NO;
Related tasks:
“Linux clustered server: Using JCL templates to set up DB2 for z/OS” on page 676
Linux clustered server: Granting privileges to DB2 for z/OS database administration users:

database user:
Installing 681

Related tasks:
“Linux clustered server: Creating DB2 for z/OS users” on page 678
Linux clustered server: Creating the Java Content Repository database:
following commands:
...
Notes:
sample:
Installing 683


Installing 685
Related tasks:
“Linux clustered server: Creating remote DB2 for z/OS databases” on page 679
Linux clustered server: Assigning custom DB2 for z/OS table spaces:
Before you begin:

database transfer.

following values:
v release
v community
v customization
v jcr
v feedback
v likeminds

Related tasks:
“Linux clustered server: Granting privileges to DB2 for z/OS database administration users” on page 680
Linux clustered server: Configuring WebSphere Portal to use DB2 for z/OS:
Before you begin:


Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 687
domains.

...
Related tasks:
“Linux clustered server: Granting privileges to DB2 for z/OS database administration users” on page 680
Linux clustered server: Setting up a remote Oracle or Oracle RAC database:
Linux clustered server: Installing Oracle or Oracle RAC:
Installing 689
Before you begin:
$ gsdctl start
$ lsnrctl start
$ agentctl start
Linux clustered server: Modifying Oracle or Oracle RAC database properties:

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl

understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
Installing 691
server.
class.
Linux clustered server: Creating Oracle or Oracle RAC databases:

information:
Server Mode.
pre_page_sga = true
as follows:
FORCE
EXACT
Related tasks:
“Linux clustered server: Installing Oracle or Oracle RAC” on page 689
Linux clustered server: Setting up Oracle or Oracle RAC automatically or manually:
Installing 693
Note:
database.
Related tasks:
“Linux clustered server: Modifying Oracle or Oracle RAC database properties” on page 690
Linux clustered server: Setting up Oracle or Oracle RAC automatically:
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
createUsers.sql
createUsers.sql
Installing 695
createUsers.sql
createUsers.sql
Linux clustered server: Granting privileges to Oracle or Oracle RAC database users:

database user:
Installing 697

Installing 699
Linux clustered server: Creating JCR table spaces:

environment.
command.
Linux 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
Installing 701
Linux clustered server: Configuring WebSphere Portal to use Oracle or Oracle RAC:
Before you begin:

Tips:
Repository schema.


files:
name are the same.

Installing 703
Related tasks:
“Linux clustered server: Modifying Oracle or Oracle RAC database properties” on page 690
“Linux clustered server: Creating Oracle or Oracle RAC databases” on page 692
Linux clustered server: Setting up a SQL Server database:
Linux clustered server: Installing SQL Server:


for information.
information.
steps:
sqljdbc_xa.dll
Linux clustered server: Modifying SQL Server database properties:
Installing 705
– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl

understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 707
JDBC driver class.
Linux clustered server: Creating SQL Server databases manually:

Related tasks:
“Linux clustered server: Installing SQL Server” on page 704
Linux clustered server: Setting up SQL Server automatically or manually:
table spaces.
Note:
database.

Related tasks:
“Linux clustered server: Modifying SQL Server database properties” on page 705
Linux clustered server: Setting up SQL Server automatically:
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:
Installing 709
Linux 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
Linux clustered server: Granting privileges to SQL Server database users:
Installing 711
database user:

Installing 713

Linux clustered server: Assigning custom SQL Server filegroups:
Before you begin:

Installing 715
database transfer.

following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Linux clustered server: Configuring WebSphere Portal to use SQL Server:
Before you begin:

Tips:
Repository schema.

files:
name are the same.
Installing 717

Related tasks:
“Linux clustered server: Modifying SQL Server database properties” on page 705
“Linux clustered server: Creating SQL Server databases manually” on page 708
Linux clustered server: Verifying databases:
in a browser:

source is wpdbDS.
environment.
Creating the WebSphere Portal profile template on Linux in a clustered environment:
Server directory.
Related tasks:
authentication.
Removing search collections on Linux:
Installing 719
Collections.
deleted.
Related tasks:
authentication.
“Linux clustered server: Configuring WebSphere Portal to use a database” on page 647
Preparing the WebSphere Application Server Deployment Manager on Linux

installation that you will use for your cluster. Run the following command: cd_root/Linux/

creating profiles.
Installing 721
Method Steps
Management Tool:
then click Next.
continue.
continue.
Next to continue.
continue.
to continue.
deployment manager:
creating profiles.
manager profile.
Option Steps
/opt/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment
-profileName Dmgr01

/opt/IBM/WebSphere/AppServer/profileTemplates directory. The existing
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01 directory.
b. Click Create.
Installing 723
e. Click Create.
i. Click Add Users.
e. Click Apply.
Related tasks:
“Linux cluster: Preparing your Linux operating system” on page 642
Preparing to create the cluster on Linux

want to create:
password.

Optimization.
node:
federated.
administrator
rerunning the task:
directory:
deployment manager.
Installing 725
the database jars.
Oracle: ojdbc14.jar

Related tasks:
“Preparing the primary node on Linux” on page 642
Creating a static cluster on Linux:

task.
password.
the validation.
Installing 727
information.
server bus member:
d. Click Add.
information.
g. Click Next.
Field Value
primary node.

the menu.
admin_password
Creating a dynamic cluster on Linux using WebSphere Virtual Enterprise:

Installing 729
task.
required.
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.
server bus member:
d. Click Add.
Installing 731
information.
g. Click Next.
Field Value
primary node.
the menu.
admin_password

Related tasks:
Preparing a remote Web server when portal is installed on Linux in a clustered

environment
directive.

Installing 733
server:
application server.
Related tasks:
Related reference:
Configuring WebSphere Portal to use a user registry on Linux in a clustered

environment
LDAP user registry.

information.
Related tasks:
Linux cluster: Preparing user registries:
Linux cluster: Preparing a Domino Directory server:

Center.
Server installation > Installing Domino on Linux and perform this task.
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
Installing 735
user:
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.
Linux cluster: Preparing a SecureWay Security Server:


for information.
server console.
4) Click Add.
your LDAP server.
Linux cluster: Preparing a Novell eDirectory:

server console.
4) Click Add.
your LDAP server.
Installing 737
Linux cluster: Preparing an Oracle Directory Server:

server console.
4) Click Add.
your LDAP server.
Linux cluster: Preparing a Tivoli Directory Server:


group.
server console.
4) Click Add.
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:
Installing 739

standalone.ldap.id

LDAP configuration.
Installing 741
Important:
Content Manager
Type of LDAP Value

Internet libraries.
instructions.

Related tasks:
Configuring a stand-alone LDAP user registry over SSL on Linux in a clustered environment:

standalone.ldap.id
Installing 743

instructions.
Related tasks:
Configuring the default federated repository on Linux in a clustered environment:
Installing 745
Configuring a federated LDAP user registry on Linux in a clustered environment:
Adding an LDAP user registry on Linux in a clustered environment:

federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
Installing 747
groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.

LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.
Installing 749
LDAP user registry:
Important:
cluster.
instructions.

Related tasks:
Adding an LDAP user registry over SSL on Linux in a clustered environment:

Installing 751
federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
groups are stored.
Installing 753
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
Important:

Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 755
instructions.
Related tasks:
Adding a database user registry on Linux in a clustered environment:


Database Steps
1. Install DB2.
Installing 757
Table 197. Steps for creating a new database to use as a database user registry. (continued)
Database Steps
AL16UTF16.
v db_files = 1024
v processes = 300
database:
Server.
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.
Installing 759
groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
instructions.
Related tasks:
Adding realm support on Linux in a clustered environment:

realmName
securityUse
delimiter
addBaseEntry
configuration.
realmName
realm.groupParent
Installing 761
realmName
addBaseEntry
configuration.
group.

the feature.
instructions.
Installing 763
Related tasks:
Linux cluster: Adapting the attribute configuration:
repositories.
LDAP schema

Related tasks:
“Linux stand-alone: Adding an LDAP user registry without SSL” on page 615
“Linux stand-alone: Adding an LDAP user registry over SSL” on page 620
“Linux stand-alone: Configuring a stand-alone LDAP user registry without SSL” on page 608
“Linux stand-alone: Configuring a stand-alone LDAP user registry over SSL” on page 612
Linux cluster: Querying the defined attributes:

Adding attributes on Linux in a clustered environment:
Application Server.
Installing 765
parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
instructions.
Related tasks:
Mapping attributes on Linux in a clustered environment:

your LDAP server:
parameters.
standalone.ldap.id
parameters.
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:

Installing 767
parameters.
standalone.ldap.id


file. (continued)
parameters.


registry:
Installing 769
instructions.
Related tasks:
Linux cluster: Removing attributes:
model directory.
directory.

Linux cluster: Configuring WebSphere Portal to use dynamic groups in a clustered environment:
nodes.

Installing 771
v Name: memberurl
configuration.
Linux cluster: Enabling referrals for your LDAP user registry in a clustered environment:
Preparing additional nodes on Linux


Related tasks:
Installing WebSphere Portal on Linux on the additional cluster nodes:
environment.

v Administration
– Deploy Tool
– Ant Utilities
levels.
ownership:
Installing 773
chmod -R g+wr /tmp
directory.


Related concepts:
Related tasks:
Related reference:
Choosing the type of additional node to create on Linux:
Adding additional nodes to the static cluster on Linux:
Installing 775
members:
creating profiles.
Option Steps
Next.
continue.
Next to continue.
CAUTION:
continue.
continue.
then click Next.

be used for additional cluster members. (continued)
Option Steps
/opt/IBM/WebSphere/PortalServer/profileTemplates/managed.portal
-profilePath /opt/IBM/WebSphere/PortalServer/profiles/testManagedPortal1
-cellName testCell
-nodeName testNode

/opt/IBM/WebSphere/PortalServer/profileTemplates directory. The new
/opt/IBM/WebSphere/PortalServer/profiles/testManagedPortal1
directory.
additional node:
database settings.
node:
Installing 777
Oracle: ojdbc14.jar

jars.
password.
the validation.
server:
application server.
Installing 779
admin_password
Adding an additional node to an existing dynamic cluster on Linux:
dynamic cluster:
members:
creating profiles.

Option Steps
Next.
continue.
Next to continue.
CAUTION:
continue.
continue.
then click Next.
-cellName testCell
-nodeName testNode

directory.
Installing 781
server profile.
additional node:
database settings.
node:

Oracle: ojdbc14.jar
jars.
Installing 783
password.
the validation.
task.
d. Click Add.

server:
application server.
admin_password
Related tasks:
Choosing the type of vertical cluster to create on Linux:
Installing 785
Adding vertical cluster members to a static cluster on Linux:
members.

member. You can do this by updating the default_host virtual host in the administrative 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.
cluster members.
f. Click OK.
setup task.
server:

application server.
Resynchronize.
Adding vertical cluster members to a dynamic cluster on Linux:
members.
Installing 787
f. Click OK.
cluster member.
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 application
server.
Resynchronize.
Linux cluster: Tune your servers

should be used.
Related tasks:
Configuring search in a cluster on Linux

Related tasks:
Configuring Portal Search in a cluster on Linux:
Portal cluster.
accordingly.
Notes:
Installing 789
Related concepts:
Portal Search.
Related tasks:
collection.
Configuring JCR search in a cluster on Linux:
directory.
search



portlet:
e. Click OK.
deleted.
for information.
Setting up multiple clusters on Linux

Installing 791
new profile.
please contact IBM.
Related tasks:
“Linux cluster: Tune your servers” on page 788
should be used.
Installing multiple clusters in a single cell on Linux:
already exists.


and password.
and portlets.
password.
federated.
rerunning the task:
Installing 793
directory:
deployment manager.
task.
password.
the validation.

Web server:
application server.
4) Click Add.
continue.
7) Click Next.
Installing 795
Field Value
primary node.
continue.
1) Click New.
4) Click OK.
4) Click Add.
2) Click New.
click Next.

f) Click Append.
menu.
9) Click Next.
server instances.
node.
dynamic cluster.
Web server:
application server.
4) Click Add.
continue.
Installing 797
7) Click Next.
Field Value
primary node.
continue.

in a cell.
Related tasks:
Routing requests across clusters on Linux:
of user requests.
Installing 799
cluster.
Related concepts:
Related reference:
Linux cluster: Sharing database domains between clusters

Manager.
clusters:

Related tasks:
“Linux cluster: Tune your servers” on page 788
should be used.
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.
Installing 801
Perform 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: Perform 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 will use for this instance.
Remember: This step is necessary to create a unique node name if you will be 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. Restart the server1 server and 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 102
above it.
Installing on Solaris
WebSphere Portal.

Setting up a stand-alone server on Solaris
Solaris stand-alone: Preparing your Solaris operating system

Perform the following steps to prepare your operating system:

1. Perform 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 will likely be 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.
Installing 803
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.
The command ulimit -f -1 removes any limit on file size.
4. Perform 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
Solaris stand-alone: Installing WebSphere Portal

authentication.

v Administration
– Deploy Tool
– Ant Utilities

before installing WebSphere Portal. See WebSphere Portal detailed system requirements for
supported levels.
b. Open a command prompt and perform the following steps to create a non-root user and to
change ownership:
1) Use the appropriate system commands to create a new group, to create a new user, and to
add the new user to the new group.
chmod -R g+wr /tmp
WebSphere Application Server using the non-root user and set the installation location to a
unique location under the path where non-root permissions were granted.
5. Choose one of the following installation commands based on the installation method you want to
use to install WebSphere Portal; see Installation Methods for more information:
Installing 805
directory.
Important: If you have a Solaris 9 on Sun SPARC, the WebSphere Portal installation program
automatically installs in 32-bit mode.
location".
installation.

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.
"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.
LDAP configuration.
Important:
Note: The starting port parameter is required for a successful completion of the
modify-ports-by-startport task. Once you specify a start port, this port becomes the base for
assigning port values. The code increments this value as each port is assigned, which means that the
WebSphere Portal ports will be assigned incrementally starting with the port defined with the
modify-ports-by-startport task.
Installing 807
Method Task
port number
to ports file

WC_adminhost=10042

10. To prevent Out of Memory errors, perform 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.
a. Log in to the WebSphere Application Server Administration Console.
b. Click 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 Application Server Administration Console.
h. Restart the server1 and WebSphere_Portal servers.

Related concepts:
Related tasks:
Related reference:
Solaris stand-alone: Configuring WebSphere Portal to use a database

Solaris stand-alone: Setting up a DB2 database:
Solaris stand-alone: Installing DB2:
Before you begin:

required databases.
Installing 809
Portal.
Solaris stand-alone: Modifying DB2 database properties:


– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
Notes:
understand.
Installing 811
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback

driver class.

Solaris stand-alone: Creating groups and assigning users:
Related tasks:
“Solaris stand-alone: Installing DB2” on page 809
Solaris stand-alone: Creating DB2 databases:
databases manually.
Related tasks:
“Solaris stand-alone: Modifying DB2 database properties” on page 810
Solaris stand-alone: Creating a local DB2 database automatically:
Installing 813
Solaris stand-alone: Creating a remote or local DB2 database manually:

running.
instance owner.
that you run:
Notes:

six times.

db2 "TERMINATE"
by name.
Installing 815
domain.

Solaris stand-alone: Setting up DB2 automatically or manually:

Related tasks:
“Solaris stand-alone: Creating groups and assigning users” on page 813
Solaris stand-alone: Setting up DB2 automatically:
ConfigEngine task.
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:
users
admins
guests
public
local
IBM
SQL
SYS
environment.
Installing 817
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 819

Installing 821
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
Solaris stand-alone: Configuring JCR collation support:
for instructions.
server:
b. Run the command:
using password.
Installing 823

# English
# Swedish
Related tasks:
“Solaris stand-alone: Creating DB2 databases” on page 813
databases manually.
Solaris stand-alone: Configuring WebSphere Portal to use DB2:

Before you begin:

Tips:
Repository schema.

Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 825
Note:
files:
name are the same.

using password

db2 terminate
-p password
Related tasks:
databases manually.
“Solaris stand-alone: Setting up DB2 automatically or manually” on page 816
independent of whether you created your DB2 databases locally or remotely..
Solaris stand-alone: Configuring DB2 for large file handling in WCM:

Installing 827
Related tasks:
databases manually.
Solaris stand-alone: Changing DB2 driver types:
configuration task.

Note:
JDBC driver.
Installing 829
Related tasks:
databases manually.
“Solaris stand-alone: Configuring WebSphere Portal to use DB2” on page 824
Solaris stand-alone: Preparing IBM DB2 for i:
Solaris stand-alone: Modifying properties for IBM DB2 for i:



– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
Installing 831
- question mark (?)
Notes:
IBM DB2 for i.
server.
understand.
releaseDS

communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Installing 833
Solaris stand-alone: Creating user profiles for IBM DB2 for i:
Before you begin:

can be shared.
new password.
environment.
Creating and setting up IBM DB2 for i databases automatically:
Related tasks:
“Solaris stand-alone: Modifying properties for IBM DB2 for i” on page 830
Solaris stand-alone: Configuring the portal to use IBM DB2 for i:
Before you begin:


the task to stall.
Note:
Installing 835
Related tasks:
“Solaris stand-alone: Creating user profiles for IBM DB2 for i” on page 834
Solaris stand-alone: Verifying the IBM DB2 for i configuration:


Related tasks:
“Solaris stand-alone: Creating user profiles for IBM DB2 for i” on page 834
“Creating and setting up IBM DB2 for i databases automatically” on page 834
Solaris stand-alone: Preparing DB2 for z/OS:
server.
Solaris stand-alone: Installing DB2 for z/OS:
following commands:
following commands:
export EXTSHM=ON
db2start
profile.env file:
export EXTSHM=ON
remote database.
Solaris stand-alone: Modifying properties for DB2 for z/OS:

Installing 837

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl

understand.
Note:
for the domain.
DbName.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 839
this value.
driver class.
Solaris stand-alone: Using JCL templates to set up DB2 for z/OS:

created.

successfully.
authority.

on the database
authority.

Related tasks:
“Solaris stand-alone: Installing DB2 for z/OS” on page 837
Solaris stand-alone: Creating users for DB2 for z/OS:
installation.
Installing 841

(R) - at runtime







where:
data.
Related tasks:
“Solaris stand-alone: Modifying properties for DB2 for z/OS” on page 837
Solaris stand-alone: Creating a remote database on DB2 for z/OS:

machine.
the databases.
Installing 843
500 DEFINE NO;
Related tasks:
“Solaris stand-alone: Using JCL templates to set up DB2 for z/OS” on page 840
Solaris stand-alone: Granting privileges to DB2 for z/OS users:

database user:
Installing 845

Related tasks:
“Solaris stand-alone: Creating users for DB2 for z/OS” on page 841
Solaris stand-alone: Creating the Java content repository database on DB2 for z/OS:
following commands:
...
Notes:
sample:
Installing 847


Installing 849
Related tasks:
“Solaris stand-alone: Creating a remote database on DB2 for z/OS” on page 843
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: Granting privileges to DB2 for z/OS users” on page 844
Solaris stand-alone: Configuring the portal to use DB2 for z/OS:
Before you begin:


Installing 851
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
domains.

...
Installing 853
Related tasks:
“Solaris stand-alone: Creating the Java content repository database on DB2 for z/OS” on page 847
“Solaris stand-alone: Granting privileges to DB2 for z/OS users” on page 844
Solaris stand-alone: Setting up a remote Oracle or Oracle RAC database:
Solaris stand-alone: Installing Oracle or Oracle RAC:
Before you begin:

$ gsdctl start
$ lsnrctl start
$ agentctl start
Solaris stand-alone: Modifying Oracle or Oracle RAC database properties:
to the Oracle or Oracle RAC database.


– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
Installing 855
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
server.

class.
Solaris stand-alone: Creating Oracle or Oracle RAC databases:
information:
Server Mode.
Installing 857
pre_page_sga = true
as follows:
FORCE
EXACT
Related tasks:
“Solaris stand-alone: Installing Oracle or Oracle RAC” on page 854
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 854
Solaris stand-alone: Setting up Oracle or Oracle RAC automatically:
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 approriate properties files
before transferring your data from the default database to the Oracle or Oracle RAC database.
Note:
Solaris stand-alone: Setting up Oracle manually:
Solaris stand-alone: Creating Oracle or Oracle RAC database schemas and users:
Before you begin:

Installing 859
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:

database user:
Installing 861

Installing 863
Solaris stand-alone: Creating JCR table spaces:

environment.
command.
Solaris stand-alone: Assigning custom Oracle or Oracle RAC table spaces:
Before you begin:

database transfer.

Installing 865
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
COMM8KSPACE
Solaris stand-alone: Configuring WebSphere Portal to use Oracle or Oracle RAC:
Oracle or Oracle RAC database. Follow these steps to transfer WebSphere 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 you begin:

Tips:
Repository schema.


files:
name are the same.
Installing 867

Related tasks:
“Solaris stand-alone: Modifying Oracle or Oracle RAC database properties” on page 854
“Solaris stand-alone: Creating Oracle or Oracle RAC databases” on page 857
Solaris stand-alone: Setting up a SQL Server database:
Solaris stand-alone: Installing SQL Server:


for information.
information.
Installing 869
steps:
sqljdbc_xa.dll
Solaris stand-alone: Modifying SQL Server database properties:

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName

– dbdomain.DbUrl
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 871
JDBC driver class.
Solaris stand-alone: Creating databases manually:

Related tasks:
“Solaris stand-alone: Installing SQL Server” on page 868
Solaris stand-alone: Setting up SQL Server automatically or manually:

table spaces.
Note:
database.
Related tasks:
“Solaris stand-alone: Modifying SQL Server database properties” on page 870
Solaris stand-alone: Setting up SQL Server automatically:
Solaris stand-alone: Running a task to automatically setup SQL Server databases:
privileges.
Installing 873
4. Click Files.
Autogrowth field.
Solaris stand-alone: Setting up SQL Server 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 875
database user:

Installing 877

Solaris stand-alone: Assigning custom SQL Server filegroups:
Installing 879
Before you begin:

database transfer.

following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Solaris stand-alone: Configuring WebSphere Portal to use SQL Server:
Before you begin:


Tips:
Repository schema.
files:
name are the same.
Installing 881

Related tasks:
“Solaris stand-alone: Modifying SQL Server database properties” on page 870
“Solaris stand-alone: Creating databases manually” on page 872
Solaris stand-alone: Verifying database configuration:

in a browser:
source is wpdbDS.
environment.
Solaris stand-alone: Preparing a remote Web server

directive.

Installing 883
Related reference:
Solaris stand-alone: Configuring WebSphere Portal to use a user registry

LDAP user registry.
information.
Related tasks:
“Solaris stand-alone: Configuring WebSphere Portal to use a database” on page 809
“Managing your user registry on Solaris” on page 2604
Solaris stand-alone: Preparing user registries:

Solaris stand-alone: Preparing a Domino Directory:

Center.
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
user:
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Installing 885
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.
server console.

4) Click Add.
your LDAP server.
Solaris stand-alone: Preparing a Novell eDirectory:

server console.
4) Click Add.
your LDAP server.
Solaris stand-alone: Preparing an Oracle Directory Server:
Installing 887

server console.
4) Click Add.
your LDAP server.
Solaris stand-alone: Preparing a Tivoli Directory Server:

group.
server console.
4) Click Add.
your LDAP server.
Solaris stand-alone: Choosing your user registry model:
Solaris stand-alone: Configuring a stand-alone LDAP user registry:
Solaris stand-alone: Configuring a stand-alone LDAP user registry without SSL:

Installing 889
standalone.ldap.id

LDAP configuration.
Important:
Installing 891
Content Manager
Type of LDAP Value

Internet libraries.
Related tasks:
“Solaris cluster: Adapting the attribute configuration” on page 1047
Solaris stand-alone: Configuring a stand-alone LDAP user registry over SSL:

standalone.ldap.id
Installing 893

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:
Installing 895
federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
groups are stored.
personAccountParent
groupParent
Installing 897
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
Important:

Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 899
Related tasks:
“Deleting the repository on Solaris” on page 2629
Solaris stand-alone: Adding an LDAP user registry over SSL:


federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 901
repository.
id
baseDN
nameInRepository

groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
Installing 903
LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:

Important:
cluster.
Installing 905
Related tasks:
“Deleting the repository on Solaris” on page 2629
Solaris stand-alone: Adding a database user registry:


Database Steps
1. Install DB2.

AL16UTF16.
v db_files = 1024
v processes = 300
database:
Server.
Installing 907
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.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Installing 909
Related tasks:
Solaris stand-alone: Adding realm support:
realmName
securityUse
delimiter
addBaseEntry
configuration.

realmName
realm.groupParent
realmName
addBaseEntry
configuration.
Installing 911
group.
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.
Installing 913
parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
Related tasks:
Solaris stand-alone: Mapping attributes:
your LDAP server:

parameters.
standalone.ldap.id
parameters.
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:

Installing 915
parameters.
standalone.ldap.id

parameters.


registry:
Solaris stand-alone: Removing attributes:
model directory.
Installing 917
directory.
Solaris stand-alone: Configuring WebSphere Portal to use dynamic groups:
nodes.


v Name: memberurl
configuration.
Solaris stand-alone: Enabling referrals for your LDAP user registry:
Installing 919
Solaris stand-alone: Tune your servers

should be used.
Related tasks:
“Solaris stand-alone: Configuring WebSphere Portal to use a database” on page 809
Setting up a cluster on Solaris

dynamic.
hardware.

node.
Installing 921
Solaris cluster: Preparing your Solaris operating system


1. Perform 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 will likely be 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.
The command ulimit -f -1 removes any limit on file size.

4. Perform 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
Preparing the primary node on Solaris

Solaris cluster: Installing WebSphere Portal:
authentication.
v Administration
– Deploy Tool
– Ant Utilities
before installing WebSphere Portal. See WebSphere Portal detailed system requirements for
supported levels.
Installing 923
b. Open a command prompt and perform the following steps to create a non-root user and to
change ownership:
1) Use the appropriate system commands to create a new group, to create a new user, and to
add the new user to the new group.
chmod -R g+wr /tmp
WebSphere Application Server using the non-root user and set the installation location to a
unique location under the path where non-root permissions were granted.
5. Choose one of the following installation commands based on the installation method you want to
use to install WebSphere Portal; see Installation Methods for more information:

directory.
location".
installation.
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.
Installing 925
"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.
LDAP configuration.
Important:
Note: The starting port parameter is required for a successful completion of the
modify-ports-by-startport task. Once you specify a start port, this port becomes the base for
assigning port values. The code increments this value as each port is assigned, which means that the
WebSphere Portal ports will be assigned incrementally starting with the port defined with the
modify-ports-by-startport task.

Method Task
port number
to ports file

WC_adminhost=10042

Installing 927
Related concepts:
Related tasks:
“Creating a Portal custom profile on Solaris” on page 2116
“Preparing the system for multiple profile support on Solaris” on page 2113
Related reference:
Solaris clustered server: Configuring WebSphere Portal to use a database:

Solaris clustered server: Setting up a remote DB2 database:
Solaris clustered server: Installing DB2:
Before you begin:

required databases.
Installing 929
Portal.
Solaris clustered server: Modifying DB2 database properties:

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl

Notes:
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 931

driver class.
Solaris clustered server: Creating groups and assigning users:

Related tasks:
“Solaris clustered server: Installing DB2” on page 929
Solaris clustered server: Creating DB2 databases:
databases manually.
Related tasks:
“Solaris clustered server: Modifying DB2 database properties” on page 930
Solaris clustered server: Creating a local DB2 database automatically:
Solaris clustered server: Creating a remote or local DB2 database manually:

Installing 933
running.
instance owner.
that you run:
Notes:
six times.


db2 "TERMINATE"
by name.
domain.

Installing 935
Solaris clustered server: Setting up DB2 automatically or manually:

Related tasks:
“Solaris clustered server: Creating groups and assigning users” on page 932
Solaris clustered server: Setting up DB2 automatically:
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 937
database user:

users
Installing 939

Solaris clustered server: Assigning custom DB2 table spaces:
Installing 941
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
# Swedish
Installing 943
Related tasks:
“Solaris clustered server: Creating DB2 databases” on page 933
databases manually.
Solaris clustered server: Configuring WebSphere Portal to use DB2:
Before you begin:

Tips:
Repository schema.

Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0

Note:
files:
name are the same.
Installing 945

using password
db2 terminate
-p password

Related tasks:
databases manually.
“Solaris clustered server: Setting up DB2 automatically or manually” on page 936
Solaris clustered server: Configuring DB2 for large file handling in WCM:
Installing 947
Related tasks:
databases manually.
Solaris clustered server: Changing DB2 driver types:
configuration task.
Note:

JDBC driver.
Installing 949
Related tasks:
databases manually.
“Solaris clustered server: Configuring WebSphere Portal to use DB2” on page 944
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
system:
- spaces
- null values
- asterisk (*)
- colon (:)
- vertical bar (|)
- plus sign (+)
- semicolon (;)
Installing 951
- question mark (?)
Notes:
IBM DB2 for i.
server.
understand.
releaseDS

communityDS
customizationDS
jcrDS
lmdbDS
feedback
JDBC driver class.
Installing 953
Solaris clustered server: Creating DB2 for IBM i user profiles:
Before you begin:

can be shared.
new password.
environment.
Solaris clustered server: Creating and setting up IBM DB2 for i databases automatically:
Related tasks:
“Solaris clustered server: Modifying DB2 for IBM i database properties” on page 950
Solaris clustered server: Transferring IBM DB2 for i manually:
Before you begin:


the task to stall.
Note:
Installing 955
Related tasks:
“Solaris clustered server: Creating DB2 for IBM i user profiles” on page 954
Solaris clustered server: Verifying IBM DB2 for i database connections:


Related tasks:
“Solaris clustered server: Creating DB2 for IBM i user profiles” on page 954
“Solaris clustered server: Creating and setting up IBM DB2 for i databases automatically” on page 954
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:
export EXTSHM=ON
remote database.
Solaris clustered server: Modifying DB2 for z/OS database properties:
Installing 957

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl

understand.
Note:
for the domain.
DbName.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 959
this value.
driver class.
Solaris clustered server: Using JCL templates to set up DB2 for z/OS:

created.

successfully.
authority.

on the database
authority.

Related tasks:
“Solaris clustered server: Installing DB2 for z/OS” on page 957
Solaris clustered server: Creating DB2 for z/OS users:
installation.
Installing 961

(R) - at runtime







where:
data.
Related tasks:
“Solaris clustered server: Modifying DB2 for z/OS database properties” on page 957
Solaris clustered server: Creating remote DB2 for z/OS databases:

machine.
the databases.
Installing 963
500 DEFINE NO;
Related tasks:
“Solaris clustered server: Using JCL templates to set up DB2 for z/OS” on page 960
Solaris clustered server: Granting privileges to DB2 for z/OS database administration users:

database user:
Installing 965

Related tasks:
“Solaris clustered server: Creating DB2 for z/OS users” on page 961
Solaris clustered server: Creating the Java Content Repository database:
following commands:
...
Notes:
sample:
Installing 967


Installing 969
Related tasks:
“Solaris clustered server: Creating remote DB2 for z/OS databases” on page 963
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

Related tasks:
“Solaris clustered server: Granting privileges to DB2 for z/OS database administration users” on page 964
Solaris clustered server: Configuring WebSphere Portal to use DB2 for z/OS:
Before you begin:


Installing 971
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
domains.

...
Installing 973
Related tasks:
“Solaris clustered server: Granting privileges to DB2 for z/OS database administration users” on page 964
Solaris clustered server: Setting up a remote Oracle or Oracle RAC database:
Solaris clustered server: Installing Oracle or Oracle RAC:
Before you begin:

$ gsdctl start
$ lsnrctl start
$ agentctl start
Solaris clustered server: Modifying Oracle or Oracle RAC database properties:



– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
Installing 975
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Note:
server.

class.
Solaris clustered server: Creating Oracle or Oracle RAC databases:
information:
Server Mode.
Installing 977
pre_page_sga = true
as follows:
FORCE
EXACT
Related tasks:
“Solaris clustered server: Installing Oracle or Oracle RAC” on page 974
Solaris clustered server: Setting up Oracle or Oracle RAC automatically or manually:
Note:
database.

Related tasks:
“Solaris clustered server: Modifying Oracle or Oracle RAC database properties” on page 974
Solaris stand-alone: Setting up Oracle or Oracle RAC automatically:
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:
Installing 979
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:

database user:
Installing 981

Installing 983
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.

Installing 985
following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
COMM8KSPACE
Solaris clustered server: Configuring WebSphere Portal to use Oracle or Oracle RAC:
Oracle or Oracle RAC database. Follow these steps to transfer WebSphere 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 you begin:

Tips:
Repository schema.


files:
name are the same.
Installing 987

Related tasks:
“Solaris clustered server: Modifying Oracle or Oracle RAC database properties” on page 974
“Solaris clustered server: Creating Oracle or Oracle RAC databases” on page 977
Solaris clustered server: Setting up a SQL Server database:
Solaris clustered server: Installing SQL Server:


for information.
information.
Installing 989
steps:
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.

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName

– dbdomain.DbUrl
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
Installing 991
JDBC driver class.
Solaris clustered server: Creating databases manually:

Related tasks:
“Solaris clustered server: Installing SQL Server” on page 988
Solaris clustered server: Setting up SQL Server automatically or manually:

table spaces.
Note:
database.
Related tasks:
“Solaris clustered server: Modifying SQL Server database properties” on page 990
Solaris clustered server: Setting up SQL Server automatically:
Solaris clustered server: Running a task to automatically setup SQL Server databases:
privileges.
Installing 993
4. Click Files.
Autogrowth field.
Solaris clustered server: Setting up SQL Server 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 995
database user:

Installing 997

Solaris clustered server: Assigning custom SQL Server filegroups:
Installing 999
Before you begin:

database transfer.

following values:
v release
v community
v customization
v jcr
v feedback
v likeminds
Solaris clustered server: Configuring WebSphere Portal to use SQL Server:
Before you begin:


Tips:
Repository schema.
files:
name are the same.
Installing 1001

Related tasks:
“Solaris clustered server: Modifying SQL Server database properties” on page 990
“Solaris clustered server: Creating databases manually” on page 992
Solaris clustered server: Verifying databases:

in a browser:
source is wpdbDS.
environment.
Creating the WebSphere Portal profile template on Solaris in a clustered environment:
Server directory.
Installing 1003
Related tasks:
authentication.
Removing search collections on Solaris:

Collections.
deleted.
Related tasks:
authentication.
“Solaris clustered server: Configuring WebSphere Portal to use a database” on page 928
Preparing the WebSphere Application Server Deployment Manager on Solaris


installation that you will use for your cluster. Run the following command: cd_root/Solaris/
creating profiles.
Installing 1005
Method Steps
Management Tool:
then click Next.
continue.
continue.
Next to continue.
continue.
to continue.
deployment manager:
creating profiles.
manager profile.
Option Steps
/opt/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment
-profileName Dmgr01

/opt/IBM/WebSphere/AppServer/profileTemplates directory. The existing
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01 directory.
b. Click Create.
Installing 1007
e. Click Create.
i. Click Add Users.
e. Click Apply.
Related tasks:
Preparing to create the cluster on Solaris

want to create:
password.
Optimization.

node:
federated.
administrator
rerunning the task:
directory:
deployment manager.
Installing 1009
the database jars.
Oracle: ojdbc14.jar

Related tasks:
Creating a static cluster on Solaris:

task.
password.
the validation.
information.
Installing 1011
server bus member:
d. Click Add.
information.
g. Click Next.
Field Value
primary node.
the menu.

admin_password
Creating a dynamic cluster on Solaris using WebSphere Virtual Enterprise:

task.
Installing 1013
required.
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.
server bus member:
d. Click Add.
information.
g. Click Next.
Field Value
primary node.
Installing 1015
Table 271. Data store fields that need information. (continued)
Field Value
the menu.
admin_password
Related tasks:
Preparing a remote Web server when portal is installed on Solaris in a clustered

environment

directive.

server:
application server.
Installing 1017
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
user:
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Internet password
wpsadmin
Group name
wpsadmins
Group type
Multi-purpose
Installing 1019
Members

members.
the file.
Editor access.
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
Solaris cluster: Preparing a SecureWay Security Server:

for information.
server console.
4) Click Add.
your LDAP server.

Solaris cluster: Preparing a Novell eDirectory:

server console.
4) Click Add.
your LDAP server.
Solaris cluster: Preparing an Oracle Directory Server:

server console.
4) Click Add.
Installing 1021
your LDAP server.
Solaris cluster: Preparing a Tivoli Directory Server:

group.
server console.
4) Click Add.
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 1023

LDAP configuration.
Important:
Content Manager
Type of LDAP Value
Installing 1025
Type of LDAP Value

Internet libraries.
instructions.
Related tasks:
Configuring a stand-alone LDAP user registry over SSL on Solaris in a clustered environment:


standalone.ldap.id
Installing 1027

instructions.
Related tasks:
Configuring the default federated repository on Solaris in a clustered environment:
Configuring a federated LDAP user registry on Solaris in a clustered environment:
Adding an LDAP user registry on Solaris in a clustered environment:
Installing 1029
federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
groups are stored.
personAccountParent
groupParent
Installing 1031
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
Important:

Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 1033
instructions.
Related tasks:
Adding an LDAP user registry over SSL on Solaris in a clustered environment:

federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 1035
repository.
id
baseDN
nameInRepository

groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
Installing 1037
LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.

LDAP user registry:
Important:
cluster.
instructions.
Installing 1039
Related tasks:
Adding a database user registry on Solaris in a clustered environment:


Database Steps
1. Install DB2.

AL16UTF16.
v db_files = 1024
v processes = 300
database:
Server.
Installing 1041
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.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
instructions.
Installing 1043
Related tasks:
Adding realm support on Solaris in a clustered environment:
realmName
securityUse
delimiter
addBaseEntry
configuration.

realmName
realm.groupParent
realmName
addBaseEntry
configuration.
Installing 1045
group.

the feature.
instructions.
Related tasks:
Solaris cluster: Adapting the attribute configuration:
repositories.
LDAP schema
Installing 1047
Related tasks:
“Solaris stand-alone: Adding an LDAP user registry without SSL” on page 895
“Solaris stand-alone: Adding an LDAP user registry over SSL” on page 900
“Solaris stand-alone: Configuring a stand-alone LDAP user registry without SSL” on page 889
“Solaris stand-alone: Configuring a stand-alone LDAP user registry over SSL” on page 892
Solaris cluster: Querying the defined attributes:

Adding attributes on Solaris in a clustered environment:
Application Server.

parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
user registry.
instructions.
Related tasks:
Mapping attributes on Solaris in a clustered environment:
Installing 1049
your LDAP server:
parameters.
standalone.ldap.id
parameters.
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:


parameters.
standalone.ldap.id

Installing 1051
file. (continued)
parameters.


registry:

instructions.
Related tasks:
Solaris cluster: Removing attributes:
model directory.
directory.
Installing 1053
Solaris cluster: Configuring WebSphere Portal to use dynamic groups in a clustered environment:
nodes.


v Name: memberurl
configuration.
Solaris cluster: Enabling referrals for your LDAP user registry in a clustered environment:
Preparing additional nodes on Solaris

Installing 1055
Installing WebSphere Portal on Solaris on the additional cluster nodes:
environment.

v Administration
– Deploy Tool
– Ant Utilities
levels.
ownership:
chmod -R g+wr /tmp

directory.

Installing 1057
Related concepts:
Related tasks:
Related reference:
Choosing the type of additional node to create on Solaris:
Adding additional nodes to the static cluster on Solaris:
members:

creating profiles.
Option Steps
Next.
continue.
Next to continue.
CAUTION:
continue.
continue.
then click Next.
/opt/IBM/WebSphere/PortalServer/profileTemplates/managed.portal
-profilePath /opt/IBM/WebSphere/PortalServer/profiles/testManagedPortal1
-cellName testCell
-nodeName testNode

/opt/IBM/WebSphere/PortalServer/profileTemplates directory. The new
/opt/IBM/WebSphere/PortalServer/profiles/testManagedPortal1
directory.
additional node:
Installing 1059
database settings.
node:

Oracle: ojdbc14.jar
jars.
password.
Installing 1061
the validation.
server:
application server.

admin_password
Adding an additional node to an existing dynamic cluster on Solaris:
dynamic cluster:
members:
creating profiles.
Installing 1063
Option Steps
Next.
continue.
Next to continue.
CAUTION:
continue.
continue.
then click Next.
-cellName testCell
-nodeName testNode

directory.

server profile.
additional node:
database settings.
node:
Installing 1065
Oracle: ojdbc14.jar
jars.

password.
the validation.
task.
d. Click Add.
Installing 1067
server:
application 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.

cluster members.
f. Click OK.
setup task.
server:
Installing 1069
application server.
Resynchronize.
Adding vertical cluster members to a dynamic cluster on Solaris:
members.

f. Click OK.
cluster member.
setup task.
server:
server.
Resynchronize.
Solaris cluster: Tune your servers

should be used.
Installing 1071
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:
collection.
Configuring JCR search in a cluster on Solaris:
directory.
search
Installing 1073


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 1075
and portlets.
password.
federated.
rerunning the task:
directory:
deployment manager.

task.
password.
the validation.
Installing 1077
Web server:
application server.
4) Click Add.
continue.
7) Click Next.
Field Value
primary node.
continue.

1) Click New.
4) Click OK.
4) Click Add.
2) Click New.
click Next.
f) Click Append.
menu.
9) Click Next.
server instances.
Installing 1079
node.
dynamic cluster.
Web server:
application server.
4) Click Add.
continue.
7) Click Next.
Field Value
primary node.

continue.
in a cell.
Installing 1081
Related tasks:
Routing requests across clusters on Solaris:
of user requests.

cluster.
Related concepts:
Related reference:
Sharing database domains between clusters on Solaris

Manager.
clusters:
Installing 1083
Related tasks:
Installing on Windows
WebSphere Portal.
Setting up a stand-alone server on Windows


Windows stand-alone: Preparing the Windows operating system


1. Check that the system logon user ID you will 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 Administrators group.
2. Perform 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 wpinstalllog.txt file:
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.
Windows stand-alone: Installing WebSphere Portal

authentication.

Installing 1085
v Administration
– Deploy Tool
– Ant Utilities
levels.
4. If you are installing on a server with a firewall, antivirus, 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.
Attention: If you are installing WebSphere Portal on Windows Vista or 7, right click on the Cmd
icon and select Run as administrator to start the installer from an administrator window.
Graphical user interface install.bat
Console mode install.bat -console
Silent install install.bat -options "path_to_file\
directory.
location using the command line; for example, install.bat -W was.undetectedWas="/my/WAS/
location".

wp_profile_root\ConfigEngine directory to generate the server1_PortMatrix.txt and
Note: The port files are located in the wp_profile_root\ConfigEngine\log\ directory and list the
installation.
v ConfigEngine.bat list-server-ports -DWasPassword=password
v ConfigEngine.bat list-server-ports-by-name -DServerName=server1 -DWasPassword=password
v ConfigEngine.bat list-server-ports-by-name -DServerName=WebSphere_Portal
7. 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.
a. Edit the wp_profile_root\PortalServer\wcm\shared\app\config\wcmservices\
Installing 1087
LDAP configuration.
Important:
d. Run the ConfigEngine.bat express-memberfixer -DPortalAdminPwd=password
-DWasPassword=password task, located in the wp_profile_root\ConfigEngine directory.
task.
Method Task
Starting port number ConfigEngine.bat modify-ports-by-startport
port number
Port file ConfigEngine.bat modify-ports-by-portsfile
to ports file

WC_adminhost=10042

Related concepts:
Related tasks:
Related reference:
Windows stand-alone: Configuring WebSphere Portal to use a database

Windows stand-alone: Setting up a DB2 database:
Windows stand-alone: Installing DB2:
Before you begin:

required databases.
Installing 1089
Portal.
2. 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.
Windows stand-alone: Modifying DB2 database properties:

– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
Installing 1091
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 stand-alone: Creating groups and assigning users:
Related tasks:
“Windows stand-alone: Installing DB2” on page 1089
Windows stand-alone: Creating DB2 databases:
databases manually.
Related tasks:
“Windows stand-alone: Modifying DB2 database properties” on page 1090
Windows stand-alone: Creating a local DB2 database automatically:
instance owner.
Installing 1093
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:

six times.

db2 "TERMINATE"
b. For JDBC Type 2 connections only: 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.
c. For JDBC Type 2 connections only: On the DB2 client, use a text editor to open the /etc/services
by name.
Installing 1095
d. For JDBC Type 2 connections only: Set up the correct service name by entering the following
svce_name is the connection service port name that is specified in substep b, such as db2c_db2inst1.
e. For JDBC Type 2 connections only: On the DB2 client, set DB2COMM to TCP/IP by using the
f. For JDBC Type 2 connections only: Catalog the TCP/IP node with the IP address of the remote
g. For JDBC Type 2 connections only, catalog the WebSphere Portal databases on DB2 Connect,
where:
domain.
remote_db_node_alias is the name that was used previously when you cataloged the TCP/IP
node in the previous step.

h. For JDBC Type 2 connections only: Log out of DB2 Connect by entering db2 "terminate".
i. For JDBC Type 2 connections only, on DB2 Connect, test your remote connection by issuing the
Windows stand-alone: Setting up DB2 automatically or manually:

Related tasks:
“Windows stand-alone: Creating groups and assigning users” on page 1093
Windows stand-alone: Setting up DB2 automatically:
ConfigEngine task.

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:
v User names can contain one to 20 characters.
users
admins
guests
public
local
Installing 1097
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 1099

Refer to the following locations of the SQL script templates for non-schema-owning runtime database
user:
Installing 1101
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
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:
Installing 1103
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 1093
databases manually.
Windows stand-alone: Configuring WebSphere 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.

a. Locate the file C:\Program Files\IBM\SQLLIB\db2cli.ini.
Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 1105
2. Open a command prompt and change to the directory wp_profile_root\ConfigEngine.
3. Enter the ConfigEngine.bat validate-database -DWasPassword=password command to validate
4. From the same command prompt as the previous steps, change to the directory wp_profile_root\bin.
v stopServer.bat server1 -username admin_userid -password admin_password
v stopServer.bat WebSphere_Portal -username admin_userid -password admin_password
a. Change to the directory wp_profile_root\ConfigEngine.
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:
name are the same.
Locate these files in the following directories. where dbms is your database management
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

step for each database (dbName) in the property file.
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
9. Run the ConfigEngine.bat create-jcr-jms-resources-post-dbxfer -DWasPassword=password
10. 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 1107
Related tasks:
databases manually.
“Windows stand-alone: Setting up DB2 automatically or manually” on page 1096
Windows stand-alone: Configuring DB2 for large file handling in WCM:

Related tasks:
databases manually.
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 1109
ConfigEngine.bat connect-database -Drelease.DbPassword=password
Related tasks:
databases manually.
“Windows stand-alone: Configuring WebSphere Portal to use DB2” on page 1105
Windows stand-alone: Preparing IBM DB2 for i:
Windows stand-alone: Modifying properties for IBM DB2 for i:


– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
system:
Installing 1111
- 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 1113
JDBC driver class.
Windows stand-alone: Creating user profiles for IBM DB2 for i:
Before you begin:

can be shared.
new password.
environment.
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: Modifying properties for IBM DB2 for i” on page 1110
Windows stand-alone: Configuring the portal to use DB2 for IBM i:

Before you begin:

the task to stall.
Note:
Installing 1115
Related tasks:
“Windows stand-alone: Creating user profiles for IBM DB2 for i” on page 1114
Windows stand-alone: Verifying the DB2 for IBM i configuration:


Related tasks:
“Windows stand-alone: Creating user profiles for IBM DB2 for i” on page 1114
“Windows stand-alone: Creating and setting up IBM DB2 for i databases automatically” on page 1114
Windows stand-alone: Setting up a remote DB2 for z/OS database:
Windows stand-alone: Installing DB2 for z/OS:
following commands:
following commands:
export EXTSHM=ON
db2start
profile.env file:
export EXTSHM=ON
remote database.
Windows stand-alone: Using JCL templates to set up DB2 for z/OS:
Installing 1117

created.
successfully.
authority.

on the database
authority.


Windows stand-alone: Creating DB2 for z/OS users:
installation.

(R) - at runtime


Installing 1119




where:
data.
Related tasks:
“Windows stand-alone: Installing DB2 for z/OS” on page 1117
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 1117
Windows stand-alone: Granting privileges to DB2 for z/OS database users:
Installing 1121
database user:

Installing 1123
Related tasks:
“Windows stand-alone: Creating DB2 for z/OS users” on page 1119
Windows stand-alone: Creating the Java Content Repository database:
following commands:
...
Notes:
sample:

Installing 1125

Related tasks:
“Windows stand-alone: Creating remote DB2 for z/OS databases” on page 1120
Windows stand-alone: 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 1127
Related tasks:
“Windows stand-alone: Granting privileges to DB2 for z/OS database users” on page 1121
Windows stand-alone: Configuring WebSphere 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.

Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
domains.
user name and the schema name. These files are located in PortalServer_root\base\wp.db.impl\
config\templates\setupdb\db2_iseries\domain and PortalServer_root\pzn\prereq.pzn\config\
templates\setupdb\db2_iseries\domain directories.
wkplc_comp.properties file.
Installing 1129
...
Related tasks:
“Windows stand-alone: Granting privileges to DB2 for z/OS database users” on page 1121
Windows stand-alone: Setting up a remote Oracle or Oracle RAC database:

Windows stand-alone: Installing Oracle or Oracle RAC:
Before you begin:

$ gsdctl start
$ lsnrctl start
$ agentctl start
Windows stand-alone: Modifying Oracle or Oracle RAC database properties:

– release
– customization
– community
– jcr
– feedback
– likeminds
Installing 1131
– dbdomain.DbName
– dbdomain.DbUrl
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback

Note:
server.
class.
Windows stand-alone: Creating Oracle or Oracle RAC databases:
Installing 1133
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: Setting up Oracle or Oracle RAC automatically:
Windows stand-alone: Running a task to automatically setup Oracle or Oracle RAC:
Note:
Windows stand-alone: Setting up Oracle or Oracle RAC manually:
Installing 1135
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 1137
database user:

Installing 1139
user:

Windows stand-alone: Creating JCR table spaces:
Installing 1141
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 WebSphere Portal to use Oracle or Oracle RAC:
Before you begin:

Tips:
Repository schema.

Installing 1143
files:
name are the same.


Windows stand-alone: Setting up a remote SQL Server database:
Windows stand-alone: Installing SQL Server:

Installing 1145
for information.
information.
steps:
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:


– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
Installing 1147
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
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: 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.

Related tasks:
“Windows stand-alone: Installing SQL Server” on page 1145
Windows stand-alone: Setting up SQL Server automatically or manually:
table spaces.
Installing 1149
Note:
database.
Related tasks:
“Windows stand-alone: Modifying SQL Server database properties” on page 1146
Windows stand-alone: Setting up SQL Server automatically:
Windows stand-alone: Running a task to automatically setup SQL Server databases:
privileges.
4. Click Files.
Autogrowth field.

Windows stand-alone: Setting up SQL Server manually:
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
Installing 1151
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:

community\createConfigRoleForSameSchema.sql
community\grantRoleToConfigUser.sql
customization\createConfigRoleForSameSchema.sql
customization\grantRoleToConfigUser.sql
database user:
community\createConfigRoleForDifferentSchema.sql
customization\createConfigRoleForDifferentSchema.sql
Installing 1153
community\createInitialRuntimeRole.sql
community\createRuntimeRoleForSameSchema.sql
community\grantRoleToRuntimeUser.sql

customization\createInitialRuntimeRole.sql
customization\createRuntimeRoleForSameSchema.sql
customization\grantRoleToRuntimeUser.sql
PortalServer_root\pzn\prereq.pzn\config\templates\setupdbsqlserver2005\feedback\
user:
Installing 1155
community\createRuntimeRoleForDifferentSchema.sql
customization\createRuntimeRoleForDifferentSchema.sql
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 WebSphere Portal to use SQL Server:
Before you begin:

Tip:
Repository schema.
Installing 1157
files:
name are the same.


Related tasks:
“Windows stand-alone: Modifying SQL Server database properties” on page 1146
“Windows stand-alone: Creating databases manually” on page 1149
production server.
Windows stand-alone: Verifying the database configuration:
in a browser:
Installing 1159
source is wpdbDS.
environment.
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.


Related reference:
Windows stand-alone: Configuring WebSphere Portal to use a user registry

LDAP user registry.
information.
Installing 1161
Related tasks:
“Windows stand-alone: Configuring WebSphere Portal to use a database” on page 1089
“Managing your user registry on Windows” on page 2631
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
Perform the following steps to prepare Active Directory:

1. Perform the following steps to install and configure Active Directory:
a. Install Windows 2000 or 2003 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. Required if using Active Directory 2000: Install Windows 2000 High Encryption Pack, which is
required to enable SSL. Refer to Windows 2000 High Encryption Pack for information.
d. Perform 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) Follow the instruction of the Windows Components Wizard. The Windows Server CD is
needed.
e. 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) Fill in CA identifying information and then click Next.
needed.
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. Perform 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 will communicate with IBM WebSphere Portal.
Perform 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:

Installing 1163
Center.
Server installation > Installing Domino on Windows and perform this task.
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
user:
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.
Windows stand-alone: Preparing a SecureWay Security Server:

for information.
server console.
4) Click Add.
your LDAP server.
Installing 1165
Windows stand-alone: Preparing a Novell eDirectory:

server console.
4) Click Add.
your LDAP server.
Windows stand-alone: Preparing an Oracle Directory Server:

server console.
4) Click Add.

your LDAP server.
Windows stand-alone: Preparing a Tivoli Directory Server:

group.
server console.
4) Click Add.
your LDAP server.
Installing 1167
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

8. Run the ConfigEngine.bat validate-standalone-ldap -DWasPassword=password task to validate your
Installing 1169
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.
Important:
d. Run the ConfigEngine.bat express-memberfixer -DmemberfixerRealm=realm_name
-DPortalAdminPwd=password -DWasPassword=password task, located in the wp_profile_root\
Content Manager
Type of LDAP Value

Type of LDAP Value

Internet libraries.
Related tasks:
“Windows cluster: Adapting the attribute configuration” on page 1323
Windows stand-alone: Configuring a stand-alone LDAP user registry over SSL:

Installing 1171
standalone.ldap.id

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
Installing 1173
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 1175
a. Use a text editor to open the wkplc.properties file, located in the wp_profile_root\ConfigEngine\
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.
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.
Important:
Content Manager
Type of LDAP Value
Installing 1177
Type of LDAP Value

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 2656
Windows stand-alone: Adding an LDAP user registry over SSL:

Installing 1179
federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
Installing 1181
groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.

LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:
Important:
Installing 1183
cluster.

Related tasks:
“Deleting the repository on Windows” on page 2656
Windows stand-alone: Adding a database user registry:

Installing 1185
Database Steps
1. Install DB2.

AL16UTF16.
v db_files = 1024
v processes = 300
database:
Server.
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 add the library paths to the VMM_JDBC_CLASSPATH variable:
a. Logon to the WebSphere Application Server Administrative Console.
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\db2jcc.jar;D:\IBM\SQLLIB\java\db2jcc_license_cu.jar.
Copy the above library files into the appserver/lib directory. Then stop and restart the server1 and
WebSphere_Portal servers 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
Installing 1187
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.
groups are stored.

personAccountParent
groupParent
groupRdnProperties
example:
attributes.
Related tasks:
Windows stand-alone: Adding realm support:
Installing 1189
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.
realmName
addBaseEntry
d. Run the ConfigEngine.bat wp-add-realm-baseentry -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to add an additional LDAP base entries to the realm
configuration.

d. Run the ConfigEngine.bat wp-change-was-admin-user -DWasPassword=password
from the wp_profile_root\ConfigEngine directory, to replace the old WebSphere Application Server
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.
Installing 1191
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
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. Navigate to the wp_profile_root\ConfigEngine directory.
c. Run the ConfigEngine.bat wp-la-install-ear -DWasPassword=password task.
parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
6. Run the ConfigEngine.bat wp-add-property -DWasPassword=password task to add the attribute to the
user registry.
Installing 1193
Related tasks:
Windows stand-alone: Mapping attributes:
your LDAP server:
parameters.
standalone.ldap.id
parameters.
federated.ldap.id
federated.ldap.host
federated.ldap.port
LDAP user registry:

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

Installing 1195
file. (continued)
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
c. Run the ConfigEngine.bat wp-update-attribute-config -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory.

Windows stand-alone: Removing attributes:
model directory.
directory.
Installing 1197
Windows stand-alone: Configuring WebSphere Portal to use dynamic groups:
nodes.

v Name: memberurl
configuration.

Windows stand-alone: Enabling referrals for your LDAP user registry:
Tune your servers

should be used.
Installing 1199
Related tasks:
“Windows stand-alone: Configuring WebSphere Portal to use a database” on page 1089
Setting up a cluster on Windows

dynamic.
hardware.
node.

Installing 1201
Related tasks:
Late breaking installation limitations and issues
Secondary node fails to start after being added to the cluster with javax.jcr.RepositoryException
exception
“Cluster considerations” on page 88
Windows cluster: Preparing your Windows operating system


1. Check that the system logon user ID you will 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 Administrators group.
2. Perform 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 wpinstalllog.txt file:
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.
Preparing the primary node on Windows

Windows cluster: Installing WebSphere Portal:
authentication.

v Administration
– Deploy Tool
– Ant Utilities
levels.
Graphical user interface install.bat
Console mode install.bat -console
Installing 1203
directory.
location using the command line; for example, install.bat -W was.undetectedWas="/my/WAS/
location".
wp_profile_root\ConfigEngine directory to generate the server1_PortMatrix.txt and
Note: The port files are located in the wp_profile_root\ConfigEngine\log\ directory and list the
installation.
v ConfigEngine.bat list-server-ports -DWasPassword=password
v ConfigEngine.bat list-server-ports-by-name -DServerName=server1 -DWasPassword=password
v ConfigEngine.bat list-server-ports-by-name -DServerName=WebSphere_Portal
7. 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.
Important:
d. Run the ConfigEngine.bat express-memberfixer -DPortalAdminPwd=password
-DWasPassword=password task, located in the wp_profile_root\ConfigEngine directory.
task.
Method Task
Starting port number ConfigEngine.bat modify-ports-by-startport
port number
Installing 1205
Table 324. Commands to change port numbers using the starting port number (continued)
Method Task
Port file ConfigEngine.bat modify-ports-by-portsfile
to ports file

WC_adminhost=10042

Related concepts:
Related tasks:
“Creating a Portal custom profile on Windows” on page 2124
“Preparing the system for multiple profile support on Windows” on page 2121
Related reference:
Windows clustered server: Configuring WebSphere Portal to use a database:
Installing 1207
Windows clustered server: Setting up a remote DB2 database:
Windows clustered server: Installing DB2:
Before you begin:

required databases.
Portal.
2. 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.
Windows clustered server: Modifying DB2 database properties:

– release
– customization
– community
– jcr
– feedback
Installing 1209
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
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:
Related tasks:
“Windows clustered server: Installing DB2” on page 1208
Windows clustered server: Creating DB2 databases:
Installing 1211
databases manually.
Related tasks:
“Windows clustered server: Modifying DB2 database properties” on page 1209
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.

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:
six times.

Installing 1213
db2 "TERMINATE"
b. For JDBC Type 2 connections only: 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.
c. For JDBC Type 2 connections only: On the DB2 client, use a text editor to open the /etc/services
by name.
d. For JDBC Type 2 connections only: Set up the correct service name by entering the following
svce_name is the connection service port name that is specified in substep b, such as db2c_db2inst1.
e. For JDBC Type 2 connections only: On the DB2 client, set DB2COMM to TCP/IP by using the
f. For JDBC Type 2 connections only: Catalog the TCP/IP node with the IP address of the remote
g. For JDBC Type 2 connections only, catalog the WebSphere Portal databases on DB2 Connect,
where:
domain.
remote_db_node_alias is the name that was used previously when you cataloged the TCP/IP
node in the previous step.

h. For JDBC Type 2 connections only: Log out of DB2 Connect by entering db2 "terminate".
i. For JDBC Type 2 connections only, on DB2 Connect, test your remote connection by issuing the
Windows clustered server: Setting up DB2 automatically or manually:

Related tasks:
“Windows clustered server: Creating groups and assigning users” on page 1211
Windows clustered server: Setting up DB2 automatically:
ConfigEngine task.
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:
Installing 1215
v User names can contain one to 20 characters.
users
admins
guests
public
local
IBM
SQL
SYS
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 1217

user:
Installing 1219
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:
Installing 1221
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 clustered server: Creating DB2 databases” on page 1211
databases manually.
Windows clustered server: Configuring WebSphere 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.

Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
Installing 1223
Note:
files:
name are the same.


step for each database (dbName) in the property file.
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 1225
Related tasks:
databases manually.
“Windows clustered server: Setting up DB2 automatically or manually” on page 1215
Windows clustered server: Configuring DB2 for large file handling in WCM:

Related tasks:
databases manually.
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 1227
ConfigEngine.bat connect-database -Drelease.DbPassword=password
Related tasks:
databases manually.
“Windows clustered server: Configuring WebSphere Portal to use DB2” on page 1223
Windows clustered server: Setting up a remote DB2 for IBM i database:
Windows clustered server: Modifying DB2 for IBM i database properties:


– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
system:
Installing 1229
- 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 1231
JDBC driver class.
Windows clustered server: Creating DB2 for IBM i user profiles:
Before you begin:

can be shared.
new password.
environment.
Windows clustered server: Creating and setting up IBM DB2 for i databases automatically:
Related tasks:
“Windows clustered server: Modifying DB2 for IBM i database properties” on page 1228
Windows clustered server: Transferring DB2 for IBM i manually:

Before you begin:

the task to stall.
Note:
Installing 1233
Related tasks:
“Windows clustered server: Creating DB2 for IBM i user profiles” on page 1232
Windows clustered server: Verifying DB2 for IBM i database connections:


Related tasks:
“Windows clustered server: Creating DB2 for IBM i user profiles” on page 1232
“Windows clustered server: Creating and setting up IBM DB2 for i databases automatically” on page 1232
Windows clustered server: Setting up a remote DB2 for z/OS database:
Windows clustered server: Installing DB2 for z/OS:
following commands:
following commands:
export EXTSHM=ON
db2start
profile.env file:
export EXTSHM=ON
remote database.
Windows clustered server: Using JCL templates to set up DB2 for z/OS:
Installing 1235

created.
successfully.
authority.

on the database
authority.


Windows clustered server: Creating DB2 for z/OS users:
installation.

(R) - at runtime


Installing 1237




where:
data.
Related tasks:
“Windows clustered server: Installing DB2 for z/OS” on page 1235
Windows clustered server: Creating remote DB2 for z/OS databases:

machine.

the databases.
500 DEFINE NO;
Related tasks:
“Windows clustered server: Using JCL templates to set up DB2 for z/OS” on page 1235
Windows clustered server: Granting privileges to DB2 for z/OS database users:
Installing 1239
database user:

Installing 1241
Related tasks:
“Windows clustered server: Creating DB2 for z/OS users” on page 1237
Windows clustered server: Creating the Java Content Repository database:
following commands:
...
Notes:
sample:

Installing 1243

Related tasks:
“Windows clustered server: Creating remote DB2 for z/OS databases” on page 1238
Windows 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 1245
Related tasks:
“Windows clustered server: Granting privileges to DB2 for z/OS database users” on page 1239
Windows clustered server: Configuring WebSphere 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.

Editing db2cli.ini:
[COMMON]
DYNAMIC=1
ReturnAliases=0
domains.
user name and the schema name. These files are located in PortalServer_root\base\wp.db.impl\
config\templates\setupdb\db2_iseries\domain and PortalServer_root\pzn\prereq.pzn\config\
templates\setupdb\db2_iseries\domain directories.
wkplc_comp.properties file.
Installing 1247
...
Related tasks:
“Windows clustered server: Granting privileges to DB2 for z/OS database users” on page 1239
Windows clustered server: Setting up an Oracle or Oracle RAC database:

Windows clustered server: Installing Oracle or Oracle RAC:
Before you begin:

$ gsdctl start
$ lsnrctl start
$ agentctl start
Windows clustered server: Modifying Oracle or Oracle RAC database properties:

– release
– customization
– community
– jcr
– feedback
– likeminds
Installing 1249
– dbdomain.DbName
– dbdomain.DbUrl
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback

Note:
server.
class.
Windows clustered server: Creating Oracle or Oracle RAC databases:
Installing 1251
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: Setting up Oracle or Oracle RAC automatically:
Windows clustered server: Running a task to automatically setup Oracle or Oracle RAC:
Note:
Windows clustered server: Setting up Oracle or Oracle RAC manually:
Installing 1253
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 1255
database user:

Installing 1257
user:

Windows clustered server: Creating JCR table spaces:
Installing 1259
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 WebSphere Portal to use Oracle or Oracle RAC:
Before you begin:

Tips:
Repository schema.

Installing 1261
files:
name are the same.


Windows clustered server: Setting up a SQL Server database:
Windows clustered server: Installing SQL Server:

Installing 1263
for information.
information.
steps:
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:


– release
– customization
– community
– jcr
– feedback
– likeminds
– dbdomain.DbName
– dbdomain.DbUrl
Installing 1265
understand.
releaseDS
communityDS
customizationDS
jcrDS
lmdbDS
feedback
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: Creating databases manually:
production server.

Related tasks:
“Windows clustered server: Installing SQL Server” on page 1263
Windows clustered server: Setting up SQL Server automatically or manually:
table spaces.
Installing 1267
Note:
database.
Related tasks:
“Windows clustered server: Modifying SQL Server database properties” on page 1264
Windows clustered server: Setting up SQL Server automatically:
Windows clustered server: Running a task to automatically setup SQL Server databases:
privileges.
4. Click Files.
Autogrowth field.

Windows clustered server: Setting up SQL Server manually:
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
Installing 1269
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
createSchema.sql
createUsers.sql
Windows clustered server: Granting privileges to SQL Server database users:

community\createConfigRoleForSameSchema.sql
customization\createConfigRoleForSameSchema.sql
database user:
community\createConfigRoleForDifferentSchema.sql
customization\createConfigRoleForDifferentSchema.sql
Installing 1271
community\createRuntimeRoleForSameSchema.sql

customization\createRuntimeRoleForSameSchema.sql
PortalServer_root\pzn\prereq.pzn\config\templates\setupdbsqlserver2005\feedback\
user:
Installing 1273
community\createRuntimeRoleForDifferentSchema.sql
customization\createRuntimeRoleForDifferentSchema.sql
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 WebSphere Portal to use SQL Server:
Before you begin:

Tip:
Repository schema.
Installing 1275
files:
name are the same.


Related tasks:
“Windows clustered server: Modifying SQL Server database properties” on page 1264
“Windows clustered server: Creating databases manually” on page 1267
production server.
Windows clustered server: Verifying databases:
in a browser:
Installing 1277
source is wpdbDS.
environment.
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 will use as the primary node of the
WebSphere 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 zip the
Related tasks:
authentication.
Removing search collections on Windows:


a. Open the icm.properties file, located in the wp_profile_root\PortalServer\jcr\lib\com\ibm\icm/
Collections.
deleted.
Related tasks:
authentication.
“Windows clustered server: Configuring WebSphere Portal to use a database” on page 1207
Preparing the WebSphere Application Server Deployment Manager on Windows

installation that you will use for your cluster. Run the following command: cd_root\windows\ia32\
ifpackage\WAS\install.exe or cd_root\windows\amd64\ifpackage\WAS\install.exe, where cd_root is
the root directory of the disc.
options to create a default Deployment Manager profile:
creating profiles.
Installing 1279
Method Steps
Management Tool:
1. Run the pmt.bat command from the
then click Next.
continue.
continue.
Next to continue.
continue.
to continue.
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 zip file, must be copied into the
config\.repository subdirectory under the Deployment Manager profile directory.
creating profiles.
manager profile.
Option Steps
1. Run the pmt.bat command from the AppServer_root/bin/
manageprofiles command Run the following command from the AppServer_root\bin directory:
manageprofiles.bat -augment -templatePath
C:\WebSphere\AppServer\profileTemplates\management.portal.augment
-profileName Dmgr01
In this example, the portal profile template is installed under the

C:\WebSphere\AppServer\profileTemplates directory. The existing
C:\WebSphere\AppServer\profiles\Dmgr01 directory.
b. Click Create.
e. Click Create.
Installing 1281
i. Click Add Users.
e. Click Apply.
Related tasks:
“Windows cluster: Preparing your Windows operating system” on page 1202
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.

Optimization.
3. Optional: Run the following command from the wp_profile_root\bin directory to federate the primary
node:
federated.
addNode.bat dmgr_hostname dmgr_port -includeapps -includebuses
administrator
rerunning the task:
set correctly in the wkplc.properties file, located in the wp_profile_root\ConfigEngine\properties
directory:
deployment manager.
Installing 1283
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 1202
Creating a static cluster on Windows:

1. Run the ConfigEngine.bat cluster-node-config-post-federation -DWasPassword=dmgr_password task.
administrative user defined in the cell's user registry. Run the ConfigEngine.bat wp-change-portal-
-DnewAdminGroupId=newadmingroupid task, from the wp_profile_root\ConfigEngine directory, to update
registry.
password.
the validation.
Installing 1285
3. Run the ConfigEngine.bat cluster-node-config-cluster-setup -DWasPassword=dmgr_password task.
information.
server bus member:
d. Click Add.
information.
g. Click Next.
Field Value
primary node.

the menu.
a. stopServer.bat WebSphere_Portal_servername -username admin_userid -password
admin_password
b. startServer.bat WebSphere_Portal_servername
Creating a dynamic cluster on Windows using WebSphere Virtual Enterprise:

a. Run the ConfigEngine.bat cluster-node-config-post-federation -DWasPassword=dmgr_password
task.
Installing 1287
administrative user defined in the cell's user registry. Run the ConfigEngine.bat
wp_profile_root\ConfigEngine directory, to update the WebSphere Portal administrative user ID if
required.
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:
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.
server bus member:
d. Click Add.
information.
g. Click Next.
Installing 1289
Field Value
primary node.
the menu.
admin_password

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.

Installing 1291
server:
application server.
Related tasks:
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
Perform the following steps to prepare Active Directory:

1. Perform the following steps to install and configure Active Directory:
a. Install Windows 2000 or 2003 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. Required if using Active Directory 2000: Install Windows 2000 High Encryption Pack, which is
required to enable SSL. Refer to Windows 2000 High Encryption Pack for information.
d. Perform 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.
needed.
e. 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) Fill in CA identifying information and then click Next.
needed.

Installing 1293
attribute to false.
3. Perform 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 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 will communicate with IBM WebSphere Portal.
Perform 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 perform this task.
Last Name
wpsbind
User Name
wpsbind
Short name/UserID
wpsbind
Internet password
wpsbind
user:
Last Name
User Name
wpsadmin
Short name/UserID
wpsadmin
Internet password
wpsadmin
Group name
wpsadmins
Group type
Multi-purpose
Installing 1295
Members

members.
the file.
Editor access.
GroupCreator
GroupModifier
UserCreator
UserModifier
e. Click OK.
Windows cluster: Preparing a SecureWay Security Server:

for information.
server console.
4) Click Add.
your LDAP server.

Windows cluster: Preparing a Novell eDirectory:

server console.
4) Click Add.
your LDAP server.
Windows cluster: Preparing an Oracle Directory Server:

server console.
4) Click Add.
Installing 1297
your LDAP server.
Windows cluster: Preparing a Tivoli Directory Server:

group.
server console.
4) Click Add.
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 1299

11. Run the ConfigEngine.bat wp-validate-standalone-ldap-attribute-config -DWasPassword=password
LDAP configuration.
Important:
Content Manager
Type of LDAP Value
Installing 1301
Type of LDAP Value

Internet libraries.
instructions.
Related tasks:
Configuring a stand-alone LDAP user registry over SSL on Windows in a clustered environment:


standalone.ldap.id
Installing 1303
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

instructions.
Related tasks:
Configuring the default federated repository on Windows in a clustered environment:
Configuring a federated LDAP user registry on Windows in a clustered environment:
Adding an LDAP user registry on Windows in a clustered environment:
Installing 1305
federated.ldap.id
federated.ldap.host
federated.ldap.port

repository.
id
baseDN
nameInRepository
groups are stored.
personAccountParent
groupParent
Installing 1307
groupRdnProperties
example:
attributes.
the feature.
LDAP configuration.
Important:

Content Manager
Type of LDAP Value

Internet libraries.
LDAP user registry:
Important:
cluster.
Installing 1309
instructions.
Related tasks:
Adding an LDAP user registry over SSL on Windows in a clustered environment:

federated.ldap.id
federated.ldap.host
federated.ldap.port
Installing 1311
repository.
id
baseDN
nameInRepository

groups are stored.
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
the feature.
Installing 1313
LDAP configuration.
Important:
Content Manager
Type of LDAP Value

Internet libraries.

LDAP user registry:
Important:
cluster.
instructions.
Installing 1315
Related tasks:
Adding a database user registry on Windows in a clustered environment:


Database Steps
1. Install DB2.

AL16UTF16.
v db_files = 1024
v processes = 300
database:
Server.
a. Use a text editor to open the wkplc_dbtype.properties file, located in the wp_profile_root\
ConfigEngine\properties directory.
Installing 1317
b. Enter a value for the following parameters under the appropriate database type properties
heading:
db_type.DbDriver
db_type.DbLibrary
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
Oracle: ojdbc14.jar
Complete the following steps add the library paths to the VMM_JDBC_CLASSPATH variable:
a. Logon to the WebSphere Application Server Administrative Console.
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\db2jcc.jar;D:\IBM\SQLLIB\java\db2jcc_license_cu.jar.
Copy the above library files into the appserver/lib directory. Then stop and restart the server1 and
WebSphere_Portal servers 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.
groups are stored.
Installing 1319
personAccountParent
groupParent
groupRdnProperties
example:
attributes.
instructions.
Related tasks:
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.
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.
Installing 1321
realmName
addBaseEntry
d. Run the ConfigEngine.bat wp-add-realm-baseentry -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory, to add an additional LDAP base entries to the realm
configuration.
d. Run the ConfigEngine.bat wp-change-was-admin-user -DWasPassword=password
from the wp_profile_root\ConfigEngine directory, to replace the old WebSphere Application Server
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.
instructions.
Related tasks:
Windows cluster: Adapting the attribute configuration:
Installing 1323
repositories.
LDAP schema
Related tasks:
“Windows stand-alone: Adding an LDAP user registry without SSL” on page 1174
“Windows stand-alone: Adding an LDAP user registry over SSL” on page 1179
“Windows stand-alone: Configuring a stand-alone LDAP user registry without SSL” on page 1168
“Windows stand-alone: Configuring a stand-alone LDAP user registry over SSL” on page 1171
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
parameters.
la.providerURL
la.propertyName
la.entityTypes
la.dataType
la.multiValued
6. Run the ConfigEngine.bat wp-add-property -DWasPassword=password task to add the attribute to the
user registry.
instructions.
Installing 1325
Related tasks:
Mapping attributes on Windows in a clustered environment:
your LDAP server:
parameters.
standalone.ldap.id
parameters.
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 1327
parameters.
standalone.ldap.id

parameters.


registry:

Stand-alone ConfigEngine.bat wp-update-standalone-ldap-
the wp_profile_root\ConfigEngine directory
Federated ConfigEngine.bat wp-update-federated-ldap-attribute-
c. Run the ConfigEngine.bat wp-update-attribute-config -DWasPassword=password task, from the
wp_profile_root\ConfigEngine directory.
instructions.
Related tasks:
Windows cluster: Removing attributes:
Installing 1329
model directory.
directory.
Windows cluster: Configuring WebSphere Portal to use dynamic groups in a clustered environment:

nodes.

v Name: memberurl
configuration.
Windows cluster: Enabling referrals for your LDAP user registry in a clustered environment:
Installing 1331
Preparing additional nodes on Windows


Related tasks:
Installing WebSphere Portal on Windows on the additional cluster nodes:
environment.

v Administration
– Deploy Tool
– Ant Utilities

levels.
Graphical user interface install.bat -W defaults.isBinaryInstall=true
Console mode install.bat -console -W
directory.

Installing 1333
Related concepts:
Related tasks:
Related reference:
Choosing the type of additional node to create on Windows:
Adding additional nodes to the static cluster on Windows:
b. Copy the profileTemplates.zip file from the PortalServer_root\profileTemplates directory on the
d. Run the installPortalTemplates.bat AppServer_root task from the newly created
members:
creating profiles.

Option Steps
continue.
Next to continue.
CAUTION:
continue.
continue.
then click Next.
manageprofiles.bat -create -templatePath
C:\WebSphere\PortalServer\profileTemplates\managed.portal
-profilePath C:\WebSphere\PortalServer\profiles\testManagedPortal1
-cellName testCell
-nodeName testNode

C:\WebSphere\PortalServer\profileTemplates directory. The new profile
is named testManagedPortal1 and is located under the
C:\WebSphere\PortalServer\profiles\testManagedPortal1 directory.
additional node:
4. Run the ConfigEngine.bat validate-database -DWasPassword=password task to validate your
database settings
Installing 1335
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

Oracle: ojdbc14.jar
wp_profile_root\ConfigEngine directory to create the variable used to access the VMM database
jars.
-DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid task, from the wp_profile_root\
password.
the validation.
Installing 1337
10. Run the ConfigEngine.bat cluster-node-config-cluster-setup-additional
server:
application server.
admin_password
Adding an additional node to an existing dynamic cluster on Windows:

dynamic cluster:
b. Copy the profileTemplates.zip file from the PortalServer_root\profileTemplates directory on the
d. Run the installPortalTemplates.bat AppServer_root task from the newly created
members:
creating profiles.
Installing 1339
Option Steps
continue.
Next to continue.
CAUTION:
continue.
continue.
then click Next.
manageprofiles.bat -create -templatePath
C:\WebSphere\PortalServer\profileTemplates\managed.portal
-profilePath C:\WebSphere\PortalServer\profiles\testManagedPortal1
-cellName testCell
-nodeName testNode

C:\WebSphere\PortalServer\profileTemplates directory. The new profile
is named testManagedPortal1 and is located under the
C:\WebSphere\PortalServer\profiles\testManagedPortal1 directory.
server profile.
additional node:

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 1341
Oracle: ojdbc14.jar
wp_profile_root\ConfigEngine directory to create the variable used to access the VMM database
jars.
password.

the validation.
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.
server:
Installing 1343
application 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.

cluster 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:
application server.
Installing 1345
Resynchronize.
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
cluster member.
setup task.
server:
server.
Resynchronize.
Windows cluster: Tune your servers

should be used.
Installing 1347
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:
collection.
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.
search
Installing 1349
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 1347
should be used.
Installing multiple clusters in a single cell on Windows:
already exists.

Cluster A, run the ConfigEngine.bat create-alias-multiple-cluster
-DauthDomainList=release,jcr -DWasPassword=dmgr_password task from the wp_profile_root\
Installing 1351
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. Optional: Run the following command from the wp_profile_root/bin directory to federate Portal B:
federated.
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.
password.
the validation.
Installing 1353
a. Run the ConfigEngine.bat cluster-node-config-cluster-setup -DWasPassword=dmgr_password
task.
Web server:
application server.
4) Click Add.
continue.
7) Click Next.

Field Value
primary node.
continue.
1) Click New.
4) Click OK.
4) Click Add.
2) Click New.
click Next.
Installing 1355
f) Click Append.
menu.
9) Click Next.
server instances.
node.
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:
application server.
4) Click Add.
continue.

7) Click Next.
Field Value
primary node.
continue.
Installing 1357
in a cell.
Related tasks:
Routing requests across clusters on Windows:
of user requests.

cluster.
Related concepts:
Related reference:
Sharing database domains between clusters on Windows

Manager.
clusters:
Installing 1359
Related tasks:
“Windows cluster: Tune your servers” on page 1347
should be used.
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.

Perform 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: Perform the following steps to update the node name in the IBM WebSphere Application
Server configuration:
a. Run the wsadmin -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 will use for this instance.
Remember: This step is necessary to create a unique node name if you will be 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. Restart the server1 server and 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 102
above it.
Related tasks:
WASService command
Setting up and maintaining a portal farm

and maintain a highly scalable, highly available server environment. Creating the farm requires an
Installing 1361
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.
Perform the following tasks to set up and maintain a portal farm:

“Portal farm considerations” on page 41
Choosing the type of portal farm to create

There are two supported portal farm configurations that you can choose when setting up your portal
farm. You can set up a unique installation where each farm has a unique installation or you can set up
one instance that is shared between multiple farm instances.
Choose one of the following options to set up your portal farm:
Setting up farm instances as unique installations

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.
Perform the following steps to set up farm instances as unique installations:
Note: All steps are repeated for each instance that you add to the portal farm except for the
create-wcm-jms-resources step; that step is only performed once on the server identified as the WCM
SUBSCRIBER that is used in the portal farm.
Remember: Create a different database instance for the Release database because all farm members must
have their own Release database. They can share all other databases, including the JCR database because
of the messaging support contained in the above steps. Use the connect-database task to connect these
instances to the other common database domains already established by the first farm instance.
1. Install and configure IBM WebSphere Portal on the initial system as a stand-alone server; see the
appropriate Setting up a stand-alone server topic in the Related task section below.
Remember: Create a different database instance for the Release database because all farm members
must have their own Release database. They can share all other databases.
2. Ensure the server1 and WebSphere_Portal servers are started.
3. Log on to the IBM WebSphere Application Server administrative console and perform the following
steps:
a. Navigate to Servers > Server Types > WebSphere application servers > WebSphere_Portal >
Web container settings > Web Container and then click Custom properties under the Additional
Properties section .
b. Click New and add the HttpSessionCloneId custom property with a value of WpServer1, where
WpServer1 is the correct clone ID for that server instance. This ID uniquely identifies this server to
the HTTP server plug-in for load balancing purposes.
c. Click OK.
d. Click Save to save your changes.
e. Log out of the IBM WebSphere Application Server administrative console.

4. Optional: If you are using IBM Web Content Manager, run the following task, from the
wp_profile_root/ConfigEngine directory, to set up the local messaging bus and queue:
To avoid the system receiving all content updates from the authoring system, one server outside the
farm needs to be identified as the subscriber. This server also requires a message queue where content
update messages are posted from members to the farm. All farm servers will listen for these messages
to update their own content caches.
Tip: This step is only performed once when setting up the portal farm; it is not performed on each
server in the farm. This step is only executed on the server identified as the WCM SUBSCRIBER that
is used in the portal farm.
v Windows: ConfigEngine.bat create-wcm-jms-resources -DWasPassword=password
v UNIX: ./ConfigEngine.sh create-wcm-jms-resources -DWasPassword=password
v IBM i: ConfigEngine.sh create-wcm-jms-resources -DWasPassword=password
Note: If you are using a remote content environment, see the "Working with syndicators and
subscribers" link below under Related concepts.
5. Optional: If you are using Web Content Manager, perform the following steps to set up additional
farm instances to listen for content update messages:
Tip: This step is performed on each server in the farm.

a. Open the prepreq.wcm.properties file, located in the wp_profile_root/PortalServer/wcm/config/
properties/ directory and update the following properties with the appropriate information for
the farm servers:
Note: See the prepreq.wcm.properties file for specific information about the required parameters.
remoteJMSHost
remoteJMSBootstrapPort
remoteJMSNodeName
remoteJMSServerName
b. Run the following task to set up the remote messaging bus and queue:
v Windows: ConfigEngine.bat create-wcm-jms-resources-remote -DWasPassword=password
v UNIX: ./ConfigEngine.sh create-wcm-jms-resources-remote -DWasPassword=password
v IBM i: ConfigEngine.sh create-wcm-jms-resources-remote -DWasPassword=password
WebSphere Portal is now managed the same as a stand-alone server in terms of starting, stopping, and
maintaining the configuration.
“Database sharing and load balancing for portal farms” on page 43
There are unique considerations for database sharing and load balancing in a portal farm configuration.
Setting up a virtual portal in a portal farm:
If you plan on creating and using virtual portals within a portal farm, there are additional steps that are
recommended to have a successful virtual portal within a portal farm environment. The basic problem if
this procedure is not followed is that the virtual portal artifacts have different object ID's in each Portal
farm member, which can cause problems if the initial HTTP requests prior to establishing a session end
up getting routed to different Portal farm members. By following this procedure, we ensure that all Portal
farm members can service these initial HTTP requests.
Perform the following steps to set up a virtual portal in a portal farm:
Installing 1363
Note: These instructions only apply if you create a farm with independent servers, each with its own
Release database.
1. Create and configure your virtual portal; see the "Multiple virtual portals" topic for information.
2. Change to the following directory:
v Windows: wp_profile_root/PortalServer/bin
v UNIX: wp_profile_root/PortalServer/bin
v IBM i: wp_profile_root/PortalServer/bin
3. Use the following command to export content from your virtual portal:
Table 366. Command to export content from your virtual portal by operating system
Operating system Command
Windows xmlaccess.bat -in ExportRelease.xml -user wpsadmin
-password wpsadminpwd -url http://hostname:port/wps/
config/virtualportalContext -out
virtualportal_output.xml
UNIX ./xmlaccess.sh -in ExportRelease.xml -user wpsadmin
IBM i xmlaccess.sh -in ExportRelease.xml -user wpsadmin
Note: The exported configuration is stored in the virtualportal_output.xml file.

4. Run the create-virtual-portal configuration task on each portal farm to create an empty virtual
portal, using the same name as the virtual portal you created in the first step. See the "Administering
virtual portals" and "Virtual portals reference" topics for information.
5. Use the following command to import content from the first virtual portal into the virtual portals
created on each portal farm:
Table 367. Command to import content from the first virtual portal into the virtual portals created on each portal farm
by operating system
Operating system Command
Windows xmlaccess.bat -in virtualportal_output.xml -user
wpsadmin -password wpsadminpwd -url
http://hostname:port/wps/config/virtualportalContext
-out Output.xml
UNIX ./xmlaccess.sh -in virtualportal_output.xml -user
-out Output.xml
IBM i xmlaccess.sh -in virtualportal_output.xml -user
-out Output.xml

Related concepts:
“Multiple virtual portals” on page 2308
View information on how you can scope your WebSphere Portal to have multiple virtual portals.
Related reference:
“Virtual portals reference” on page 2335
View information about configuring virtual portals, hints and tips, and known limitations.
“Administering virtual portals” on page 2323
View information to help you scope your WebSphere Portal to have multiple virtual portals.
Setting up farm instances using a shared configuration

Choose this option to set up the portal farm from a shared filesystem. This option allows you to only
maintain one image, which makes using the farm maintenance easier because multiple copies of this one
image can be used to update farm instances on a server-by-server basis. There are fewer resources to
manage and the environment is simple. The disadvantage to this option is that there is no ability to affect
specific changes on a per-server basis and most changes require a server restart.
Perform the following steps to set up farm instances using a shared configuration:
Note: The first machine where IBM WebSphere Portal is installed is used as a basis for the portal farm
and is termed the original server.
1. Create an empty file system on a central file server with enough capacity for a full installation and
then mount it on the original server as a writable file system in the location where WebSphere Portal
should be installed; for example:
v Windows: C:\
v UNIX: /opt/IBM
v AIX: /usr/IBM
v IBM i: /QIBM/IBM
2. Install WebSphere Portal on the original server into the mounted file system, which results in a set of
product binaries (AppServer and PortalServer directories) and a default configuration profile
(wp_profile). WebSphere Portal will run off the mounted file system on the original server.
3. Reconfigure the local instance to use a different TCP/IP hostname. This hostname should either be
localhost or a hostname configured in the local hosts file alias localhost. This allows the local
instance to always reference itself using the loopback address. Perform the following steps to
reconfigure the hostname:
a. Change to the wp_profile_root/bin directory.
b. Run the following task, where node_name is the node name assigned to the local node:
v Windows: wsadmin.bat –c “$AdminTask changeHostName {-nodeName node_name -hostName
localhost}; $AdminConfig save” –conntype NONE
v UNIX: ./wsadmin.sh –c “\$AdminTask changeHostName {-nodeName node_name -hostName
localhost}; \$AdminConfig save” –conntype NONE
v IBM i: wsadmin.sh –c “$AdminTask changeHostName {-nodeName node_name -hostName
localhost}; $AdminConfig save” –conntype NONE
c. Change to the wp_profile_root/ConfigEngine directory.
d. Run the following task to propagate the profile changes to the WebSphere Portal configuration:
v Windows: ConfigEngine.bat localize-clone -DWasPassword=password
v UNIX: ./ConfigEngine.sh localize-clone -DWasPassword=password
v IBM i: ConfigEngine.sh localize-clone -DWasPassword=password
Installing 1365
4. Configure this instance to represent the baseline configuration for the entire farm, including
configuring databases and configuring the user registry. See the appropriate database and user
registry topics under the Setting up a stand-alone server topic in the Related task section below.
5. Optional: If you are using IBM Web Content Manager, run the following task, from the
wp_profile_root/ConfigEngine directory, to set up the local messaging bus and queue:
To avoid the system receiving all content updates from the authoring system, one server outside the
farm needs to be identified as the subscriber. This server also requires a message queue where content
update messages are posted from members to the farm. All farm servers will listen for these messages
to update their own content caches.
Tip: This step is only performed once when setting up the portal farm; it is not performed on each
server in the farm. This step is only executed on the server identified as the WCM SUBSCRIBER that
is used in the portal farm.
v Windows: ConfigEngine.bat create-wcm-jms-resources -DWasPassword=password
v UNIX: ./ConfigEngine.sh create-wcm-jms-resources -DWasPassword=password
v IBM i: ConfigEngine.sh create-wcm-jms-resources -DWasPassword=password
Note: If you are using a remote content environment, see the "Working with syndicators and
subscribers" link below under Related concepts.
6. Optional: If you are using Web Content Manager, perform the following steps on the original server
so that all farm instances will listen for content update messages:
Tip: This step is performed only once on the original server.

a. Open the prepreq.wcm.properties file, located in the wp_profile_root/PortalServer/wcm/config/
properties/ directory and update the following properties with the appropriate information for
the farm servers:
Note: See the prepreq.wcm.properties file for specific information about the required parameters.
remoteJMSHost
remoteJMSBootstrapPort
remoteJMSNodeName
remoteJMSServerName
b. Run the following task to set up the remote messaging bus and queue:
v Windows: ConfigEngine.bat create-wcm-jms-resources-remote -DWasPassword=password
v UNIX: ./ConfigEngine.sh create-wcm-jms-resources-remote -DWasPassword=password
v IBM i: ConfigEngine.sh create-wcm-jms-resources-remote -DWasPassword=password
7. Perform the following steps to enable the server to run in farm mode, where the systemTemp
parameter specifies where the server-specific directory is located. This directory will contain all
directories and files that the running portal instance will write to, such as for logging and page
compiling:
a. Create the target directory path. For example:
v Windows: C:\temp\was_tmp
v UNIX: /var/log/was_tmp
v IBM i: /var/log/was_tmp
b. Run the following task to enable the server to run in farm mode:
v Windows: ConfigEngine.bat enable-farm-mode –DsystemTemp=C:\temp\was_tmp
v UNIX: ./ConfigEngine.sh enable-farm-mode –DsystemTemp=/var/log/was_tmp

v IBM i: ConfigEngine.sh enable-farm-mode –DsystemTemp=/var/log/was_tmp
8. On each server you plan to add to the portal farm, mount the network accessible file system on a new
system in the same location as on the original server to preserve the installation path configuration.
9. Change to the wp_profile_root/PortalServer/bin directory and run the following task to start or stop
an instance of WebSphere Portal from a farm server:
Table 368. Steps to stop and start the WebSphere_Portal server on any server in the farm by operating system.
Operating system Tasks
Windows start_WebSphere_Portal.bat
stop_WebSphere_Portal.bat
UNIX ./start_WebSphere_Portal.sh
./stop_WebSphere_Portal.sh
IBM i start_WebSphere_Portal.sh
stop_WebSphere_Portal.sh
Disabling farm mode:
After setting up your farm using a shared configuration, you may need to disable the farm mode, which
will allow you to return the original IBM WebSphere Portal instance that manages the shared file system
to a regular, stand-alone server instance. You can then make system updates, for example change the
systemTemp value, and then run the enable-farm-mode task to re-enable the farm or you can use the
instance for a different purpose.
Perform the following steps to disable the farm mode:

1. Deactivate all farm instances sharing the required server's file system.
2. Stop sharing the required server's file system.
3. Run the following task to disable the farm mode:
v Windows: ConfigEngine.bat disable-farm-mode -DWasPassword=password, from the
v UNIX: ./ConfigEngine.sh disable-farm-mode -DWasPassword=password, from the
v IBM i: ConfigEngine.sh disable-farm-mode -DWasPassword=password, from the
Setting up the HTTP server plug-in on a portal farm

You can use a Web server to handle load balancing across your portal farm. This documentation is
specific to the HTTP server but you can use any supported Web server.
Your Web server must already be configured to use the IBM WebSphere Application Server plug-in for
load balancing.
Perform the following steps to set up the HTTP server plug-in on the portal farm:
1. Generate the plug-in configuration from one of the application servers in the farm using the
GenPluginCfg script provided by WebSphere Application Server in the wp_profile_root/bin directory.
2. Modify the plugin_cfg.xml file, that was generated in the above step, to have a server entry for every
server in the farm:
Installing 1367
Note: For the purposes of this example, it is assumed every server in the farm uses the same set of
ports. The CloneID attribute must be added to each Server element with a value that uniquely
identifies this server instance. This value should be a string with no special characters or spaces and
must coincide with the value set for the HttpSessionCloneId Web Container custom property on
each farm server instance.
<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true"
Name="PortalCluster" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true"
RetryInterval="60">
<Server CloneID="server1" ConnectTimeout="5" ExtendedHandshake="false" LoadBalanceWeight="2"
MaxConnections="-1" Name="svtvm2_WebSphere_Portal" ServerIOTimeout="60" WaitForContinue="false">
<Transport Hostname="server1.mycompany.com" Port="10039" Protocol="http"/>
<Transport Hostname="server1.mycompany.com" Port="10029" Protocol="https">
<Property Name="keyring" Value="/usr/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/>
<Property Name="stashfile" Value="/usr/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/>
</Transport>
</Server>
<Server CloneID="server2" ConnectTimeout="5" ExtendedHandshake="false" LoadBalanceWeight="2"
MaxConnections="-1" Name="svtvm3_WebSphere_Portal" ServerIOTimeout="60" WaitForContinue="false">
<Transport Hostname="server2.mycompany.com" Port="10039" Protocol="http"/>
<Transport Hostname="server2.mycompany.com" Port="10029" Protocol="https">
<Property Name="keyring" Value="/usr/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/>
<Property Name="stashfile" Value="/usr/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/>
</Transport>
</Server>
</ServerCluster>
3. Replace the plugin-cfg.xml file currently used by the HTTP Server plugin with this newly edited
version.
4. Restart the HTTP Server to ensure the changes are picked up, and watch for any startup errors that
might indicate a syntax issue within the plugin-cfg.xml file.
5. Stop and restart all the WebSphere_Portal servers on the portal farm; see "Starting and stopping
servers, deployment managers, and node agents" for information.

Related tasks:
“AIX stand-alone: Preparing a remote Web server” on page 195
“IBM i stand-alone: Preparing a remote Web server” on page 409
“Linux stand-alone: Preparing a remote Web server” on page 602
“Solaris stand-alone: Preparing a remote Web server” on page 883
“Windows stand-alone: Preparing a remote Web server” on page 1160
Configuring search in a portal farm

capabilities in a portal farm environment.
Configuring Search in a portal farm

To support Search in a portal farm, you must install and configure search for remote search service on an
IBM WebSphere Application Server instance that is not part of the farm.
1. Install and configure the search service to work remotely. The service is on a remote WebSphere
Application Server instance which is not part of the portal farm. 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 instance. For details about how to do this, refer to the
WebSphere Application Server documentation.
accordingly.
Notes:
1. If you have configured a remote search service for a portal farm, you need to configure the default
farm instance, 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 instances of the farm.
Configuring JCR search in a portal farm

To enable search in a portal farm for content stored in the JCR database, you must configure each
instance in the farm to access a shared directory. JCR-based content includes content created with Web
Content Manager or Personalization.
Installing 1369
Create a shared directory called jcr/search on a server in the farm and ensure that each instance in the
farm has network access to the directory.
Set up the remote search service on the primary instance of the farm; refer to Configuring a remote
search service for information.
Note: If you are creating content in a portal farm using the authoring portlet provided with Web Content
Manager, additional configuration steps are required to enable content created by these content features
to be searchable in a farm.
Perform the following steps on each instance in the farm to configure the JCR search:
directory.
search

portlet:

e. Click OK.
deleted.
for information.
Setting up a highly available message bus

If you configured your portal farm to use a single content subscriber, you may want to create a highly
available message bus to ensure that content is always updated on the server instances, even if one
subscriber server becomes unavailable. To create a highly available message bus, you must create a
cluster of subscriber servers and then add them to the bus. If the bus is set up on the initial server from
which the cluster is based, where you ran the create-wcm-jms-resource task, then the resulting cluster
will become a member of the bus, as will all cluster members.
IBM WebSphere Application Server assigns one member of the cluster at a time to own the message
queue and will automatically reassign the queue to another cluster member if the original becomes
unavailable. Setting up a IBM Web Content Manager subscriber cluster is the same as creating a IBM
WebSphere Portal cluster; see the appropriate Setting up a cluster topic in the Related task section below.
Perform the following steps to set up a highly available message bus:
Note: These steps assume that you currently have a single messaging server set up on your farm. These
steps are either performed on each farm instance if you have a unique installation or on the master farm
instance if you have a shared configuration.
1. Perform the following steps to modify the Web Content Manager message driven bean (MDB) to
include additional service integration (SIB) endpoints, one for each cluster member in the subscriber
cluster:
a. Open the Deployment Manager administrative console.
b. Navigate to Resources > JMS > Activation specifications.
c. Select IWKItemChangeMonitorActivation and under Provider endpoints add the additional
server:port:BootstrapBasicMessaging for each cluster member in the subscriber cluster; separate
them by commas.
d. Click OK to save your changes.
e. Select IWKSyndicationMonitorActivation and under Provider endpoints add the additional
them by commas.
f. Click OK to save your changes.
g. Click Save to save your changes.
h. Log out of the Deployment Manager administrative console.
2. Perform the following steps to modify the Web Content Manager JMS Connection Factory definition
to include additional SIB endpoints, one for each cluster member in the subscriber cluster:
a. Open the Deployment Manager administrative console.
Installing 1371
b. Navigate to Resources > JMS > Topic connection factories.
c. Select IWKMessagingTopicConnectionFactory and under Provider endpoints add the additional
them by commas.
d. Click OK to save your changes.
e. Click Save to save your changes.
f. Log out of the Deployment Manager administrative console.
Related tasks:
“Setting up a cluster on Windows” on page 1200
dynamic.
Administering a portal farm

Because a farm is a series of independent server instances and not a cluster, specific procedures need to
be followed to deploy updates to the farm that are different than when administering a cluster. Updates
include any changes to the system, such as, but not limited to, using or deploying portlets, adding or
changing portal pages, changing file system resources, and changing IBM WebSphere Application Server
configurations. The procedures differ depending on the type of farm: unique installations or shared
installations.
Choose the following task depending on the type of portal farm you created:
Administering unique portal farm installations

In a farm of uniquely installed IBM WebSphere Portal instances, each instance has its own release
database while every other database domain is shared, including the JCR. Each unique installation also
has its own unique IBM WebSphere Application Server configuration profile and its own WebSphere
Application Server administration console. Therefore, application, server configuration, and service
updates must be made on each server. It is highly recommended that such updates be automated through
configuration scripts that call the appropriate command line tools for making the changes (for example
XMLAccess, wsadmin, etc), such that the exact same change can be repeated on each server without the
possibility of injecting human error.
Perform the following steps to update a single server:
Note: How you remove and restore a server from production traffic depends on the load balancing
mechanism used. If you are using the WebSphere Application Server plugin for the HTTP Server, for
example, it is a matter of temporarily removing that Server entry from the ServerCluster definition and
either restarting the HTTP Server or waiting for the HTTP Server to reload the configuration (if automatic
reload is enabled).
1. Remove the server from the production traffic.
2. Apply the update.
3. Restart the server.
4. Verify the change as appropriate.
5. Restore the server back to the production traffic.
Administering shared portal farm installations

In a shared installation farm, there is one IBM WebSphere Portal installation whose file system serves as
the configuration for the entire farm, which is referred to here as the master instance. That means that
every farm instance shares the exact same databases and IBM WebSphere Application Server
configuration profile. This one WebSphere Portal installation should have write access to the file system,

while all other farm instances that share this file system should have read-only access. This means that all
administrative actions can only be performed against the master instance.
It is recommended that the master instance either not be a part of regular production traffic, or if it is, it
be temporarily removed from production traffic when the update is made, so that the update can be
tested before the other servers are affected. After a change is made to the master, depending on the
nature of the change, it may take effect immediately across the entire farm or require that the farm
instances be restarted.
Changes made to WebSphere Portal's release configuration, such as new pages, page layout changes,
access control changes, or other updates made using the XMLAccess tool that do not involve updates to
portlet applications will take effect immediately since all farm instances share the same release database.
Changes made to the WebSphere Application Server configuration profile, which include JVM tuning
changes and JDBC datasource changes, or updates to Java resources, which include updated JAR files in
the file system, will not take effect until each server in the farm is restarted.
Likewise, updates to enterprise application or portlet EAR and WAR files will not take effect until one of
the following occurs:
v The application is restarted on each server
v Each server in the farm is restarted
To restart an application, you can either access the WebSphere Application Server administration console
on each server and restart the application, or you can use the wsadmin scripting command to restart the
application. To restart the server, use the stop_WebSphere_Portal and start_WebSphere_Portal scripts
profiled in the wp_profile_root/PortalServer/bin directory.
If the administrative action is extensive, updating several WebSphere Application Server and WebSphere
Portal assets at once, you may want to follow the instructions under the Maintaining a portal farm
section, which walks through an update procedure involving a second filesystem and database, ensuring
that the updates are isolated from the original configuration and each server can be switched to the
updated configuration, tested, and returned to production traffic without affecting other farm instances in
any way. This has the added benefit of providing a fallback configuration if the changes do not work as
expected.
Maintaining a portal farm

Maintenance can be considered any change to the system, such as the deployment of application updates,
platform configuration changes, or the application of corrective service. The mechanism used to apply
maintenance to a farm depends on the type of farm deployed: unique installations or shared
configuration.
Choose the appropriate farm type for your environment to apply maintenance procedures:
Applying maintenance to a unique portal farm configuration

When the portal farm is a series of uniquely installed IBM WebSphere Portal instances, each installation
acts as a totally independent instance from the other farm instances. The only thing in common between
farm instances are the shareable database domains (customization and community data), which are
typically not updated during maintenance operations.
To apply maintenance in such a farm configuration requires application of the changes to every server
instance, as each instance has a dedicated and isolated configuration from another instance. So whether
the change is as simple as a single tuning change to as complex as the deployment of a fix pack or new
application deployment, these changes need to be made to each server in the farm.
Since each farm instance has its own release database and JCR content repository, all that needs to be
done is to remove a server from the work load management, so that it does not receive any more user
Installing 1373
requests, allowing the individual farm instance to be updated, tested, then returned to workload
management. In this way, each farm member can be independently updated and tested, or done in
batches. Therefore, multiple farms are not required to achieve continuous availability, as long as a portion
of the farm can handle production traffic during the maintenance application process.
Applying maintenance to a shared configuration server farm

In a shared configuration environment, changes made to the shared file system are visible to all farm
instances instantaneously, but may not be activated until a portal or application instance is restarted. Such
changes include IBM WebSphere Application Server configuration changes that are made to the shared
configuration profile or updates to shared Java resources, like JAR files in a shared library or a
redeployed application. In such cases, the changes can be made to the original server configuration then
activated and tested on a farm server by taking a server out of workload management, restarting the
portal server, testing the change, and re-adding the server back to the workload management.
In the event that the installed product binaries are shared across multiple machines and profiles through
a network-accessible file system, then there is an additional option when applying maintenance or
deploying other updates such that each server can be updated independently instead of all at once. This
process involves creating a copy of the original binary file system, updating the copy, then systematically
switching the original shared binaries for the copy for each server being updated. This allows each server
to be updated and tested independently of the other. Special setup is required for a portal farm to make
future maintenance easier. These steps apply regardless of the operating system used, and therefore no
operating system specific instructions are provided. General concepts like "network sharable file systems"
can be translated to any preferred operating system specific mechanism to achieving that capability, such
as through the use of Samba or NFS for remotely accessing a common file system.
Perform the following steps to maintain a portal farm:
Note: It is assumed that a portal farm consists of independent portal profiles not belonging to a single
cluster. The rule of updating profiles at the cluster boundary still applies: if any of these profiles
contribute to a cluster, they should all be updated at the same time. Thus a cluster can be thought of a
single maintainable unit within a farm, and a farm may include several clusters, all sharing the same set
of binaries.
1. On the file server, make a copy of the IBM WebSphere Portal file system. Make this copied file system
remotely accessible just like the original.
2. On the original server, stop all application servers; for example, WebSphere_Portal and server1.
3. On the original server, mount the copied file system in place of the original file system, at the same
location. WebSphere Portal is now operating off the backup copy created in first step while all
remaining servers in the farm are still running off the original file system.
4. Update and test the original server as appropriate.
5. Perform the following steps on each additional server in the farm:
a. Stop all application servers in the local profile; for example, WebSphere_Portal and server1.
b. Mount the copied file system in place of the original file system, at the same location. The local
profile is now using the updated product binaries.
c. Apply the updates to the profile only. For product maintenance, the Portal Update Installer
documentation covers how to apply updates to the profile only, assuming the product binaries
have already been updated.
Setting up a Personalization server on WebSphere Application Server

The WebSphere Portal product installs and configures Personalization software by default. However, you
can choose to install Personalization to an instance of WebSphere Application Server. When
Personalization is installed in this way, it is referred to as the Personalization Server. The Personalization
Server enables you to deploy applications that have been developed with IBM WebSphere Application
Server, serve personalized content to users, and record site metrics, without requiring that WebSphere

Portal also be present on the server machine. While business rules may be run from any WebSphere
Application Server installation, a full WebSphere Portal installation is still required as a workspace for
authoring rules and campaigns.
Restriction: The Personalization Server is not supported on IBM System i5 as a standalone server;
Personalization is only supported on System i5 when installed with WebSphere Portal.
Planning for the Personalization Server

You might want to use the Personalization rules engine in an environment outside of WebSphere Portal.
For example, you could use Personalization in a Web service that provides a personalized XML content
stream. Alternatively, you could use it to generate an RSS feed. In these cases, Personalization is used as a
service that is consumed by other software components on other servers.
When portlet rendering is not required, such as when the output of a service is an XML or RSS feed,
deploying the Personalization rules engine in an environment outside of WebSphere Portal is an efficient
alternative to administering an installation of the portal. The servlet that receives the publishing request
can also run outside of WebSphere Portal. With the exception of pznwpsruntime.jar, which includes the
WebSphere Portal user resource collection, all the Personalization runtime libraries can run separately
from WebSphere Portal. Publishing to a server that does not have WebSphere Portal installed is no
different than publishing to a server where WebSphere Portal is installed.
Personalization no longer has an independent administrative or authoring database. Personalization uses

the IBM Java Content Repository for storage of rules, campaigns, and other objects both during the
authoring phase and runtime phase. You can install the repository, which stores the rules and campaigns,
outside of WebSphere Portal. In this configuration, the Java Content Repository does not use WebSphere
Portal Access Control, nor does it use the federated LDAP service of the portal.
The only components that are not installed when running outside of a WebSphere Portal environment are
the Personalization portlets, including the authoring portlets and the Personalized List portlet. As a
consequence, once artifacts are published to a Personalization rules engine without WebSphere Portal
installed, there is no way to view those artifacts directly on that system. You need a WebSphere Portal
installation, either a test environment installation or a full WebSphere Portal installation, in order to
author rules and campaigns.
Two optional functions of Personalization require the use of a database.

v The Feedback function uses a database to store logged information. The amount of database space that
is required for logging depends on the amount of traffic to the site. The amount of data that is logged
per login-enabled page can vary.
v The LikeMinds recommendation engine uses a database to store information gathered through the
logging APIs. LikeMinds uses this information to make recommendations of user affinities and
interests.
If you choose to deploy a Personalization Server, consider the following facts:

v There should be a WebSphere Portal installation on the same machine as the Personalization Server,
but the portal server does not have to be up and running. You update the Personalization Server by
updating WebSphere Portal.
v You do not need to install Personalization databases. When you install WebSphere Portal, an Apache
Derby database is created. The Personalization Server should be installed before WebSphere Portal is
switched to database management system other than Derby. When using the database-transfer task to
switch to any other database management system, refer to the database transfer instructions of
WebSphere Portal, but run the database-transfer task using the following command:
Windows:
Installing 1375
ConfigPzn.bat
-DparentProperties=wp_profile_root\ConfigEngine\pzn.properties
-DSaveParentProperties=false database-transfer -DTransferDomainList=jcr,feedback,likeminds
UNIX:
./ConfigPzn.sh
-DparentProperties=wp_profile_root/ConfigEngine/pzn.properties
-DSaveParentProperties=false database-transfer -DTransferDomainList=jcr,feedback,likeminds
v You do not need to configure the LikeMinds recommendation engine because it is configured by
default when you install WebSphere Portal.
v Because the stand-alone Personalization Server cannot use the federated LDAP services of WebSphere
Portal, you need to set up LDAP security for the Personalization Server in IBM WebSphere Application
Server.
Installing and removing a stand-alone Personalization Server

You can install a stand-alone Personalization server to a new IBM WebSphere Application Server profile,
which allows you to deploy WebSphere Application Server specific applications, serve personalized
content to users, and record site metrics without requiring an active IBM WebSphere Portal server.
Perform the following steps to install or uninstall a stand-alone Personalization Server:

1. Open a command prompt and change to the was_profile_root/bin directory.
2. Run the following command to create a WebSphere Application Server profile for the Personalization
server:
Option Description
Windows manageprofiles.bat -create -profileName pzn_profile
-profilePath was_profile_root\pzn_profile
-templatePath AppServer_root\profileTemplates\default
UNIX ./manageprofiles.sh -create -profileName pzn_profile
-profilePath was_profile_root/pzn_profile
-templatePath AppServer_root/profileTemplates/default
3. Change to the wp_profile_root/ConfigEngine directory and run the following command to initialize the
stand-alone Personalization Server:
Option Description
Windows ConfigEngine.bat
-DPznProfileName=target_profile_name
action-init-pzn-standalone
-DPortalAdminId=userID
-DPortalAdminPwd=password
-DWasAdminId=WASuserID -DWasPassword=WASpassword
UNIX ./ConfigEngine.sh
-DPznProfileName=target_profile_name
action-init-pzn-standalone
-DPortalAdminId=userID
-DPortalAdminPwd=password
-DWasAdminId=WASuserID
-DWasPassword=WASpassword
4. Open the wp_profile_root/ConfigEngine/pzn.properties file and edit the following properties to match
your new WebSphere Application Server profile to the initialized stand-alone Personalization Server:
WasSoapPort
Enter the SOAP_CONNECTOR_ADDRESS value found in the serverindex.xml file of the new
WebSphere Application Server profile.

WpsHostPort
Enter the WC_defaulthost value found in the serverindex.xml file of the new WebSphere
Application Server profile.
XmlAccessPort
Enter the port used by the XMLAccess configuration task to connect the XMLAccess server.
VirtualHostName
Enter the name of the new WebSphere Application Server profile virtual host.
WasUserHome
Enter the name of the directory where the new WebSphere Application Server profile was
created.
ProfileName
Enter the name of new WebSphere Application Server profile name.
CellName
Enter the name of the new WebSphere Application Server profile cell.
NodeName
Enter the name of the new WebSphere Application Server profile node.
ServerName
Enter name of the application server for the new WebSphere Application Server profile.
5. Change to the wp_profile_root/ConfigEngine directory and run the following command to install the
Option Description
Windows ConfigPzn.bat
-DSaveParentProperties=false
-DPortalAdminID=portal_uid
-DPortalAdminPwd=portal_password
-DWasAdminID=WAS_uid
-DWasPassword=WAS_password action-install-pzn-standalone
UNIX ./ConfigPzn.sh
-DPortalAdminID=portal_uid
-DPortalAdminPwd=portal_password
-DWasAdminID=WAS_uid
-DWasPassword=WAS_password action-install-pzn-standalone
6. Change to the wp_profile_root/ConfigEngine directory and run the following command to remove the
Option Description
Windows ConfigPzn.bat
-DPortalAdminId=xyzadmin
-DPortalAdminPwd=xyzadminpasssword
-DWasAdminId=xyzadmin
-DWasPassword=xyzadminpassword action-remove-pzn-standalone
UNIX ./ConfigPzn.sh
-DPortalAdminId=xyzadmin
-DPortalAdminPwd=xyzadminpasssword
-DWasAdminId=xyzadmin
-DWasPassword=xyadminpassword action-remove-pzn-standalone
Installing 1377
Uninstalling WebSphere Portal
Uninstalling IBM WebSphere Portal is a multiple step process and the method you use is dependent upon
your configuration. Removing WebSphere Portal in a single-server configuration is different from
removing WebSphere Portal from a cluster. Manual uninstallation instruction are provided for a
single-server configuration in case of an error situation.
Restrictions on moving a node to a stand-alone configuration

In a working cluster, all nodes share a common database. If you want to remove a node from a cell to use
the node in a stand-alone configuration, some restrictions apply.
The configuration of all portlets deployed in a cell are stored in a common database. When you remove a
node from a cell to use the node in a stand-alone configuration, the portlets that had been available to the
node in the cell are no longer available to it as a stand-alone server. Other changes in configuration that
were made after the node was federated to the cell, such as enabling LDAP security or applying fix pack
maintenance, can prevent the node from operating normally after it is removed from the cell. Starting or
modifying the configuration of the stand-alone node before taking steps to back up the database can
introduce conflicts between the node and the remaining nodes in the cell.
Before you start or modify the configuration of the stand-alone node, restore the WebSphere Application
Server file system and the WebSphere Portal databases using backups taken prior to federation.
Reconnect to a database that represents the portlet and page configuration of the node before it was
added to the cell. Do not reconnect to the default database.
Uninstalling WebSphere Portal on AIX

Single server: Uninstalling on AIX

You can uninstall IBM WebSphere Portal only or both WebSphere Portal and IBM WebSphere Application
Server using either the graphical user interface, console mode, or silent uninstallation program.
Preparing to uninstall a single server on AIX:
Before uninstalling IBM WebSphere Portal, you must prepare your system; for example, adding
passwords to the properties files and keeping or discarding database information.
Perform the following steps to prepare for uninstallation:

1. Optional: Make a backup of the WebSphere Portal configuration using the XML Configuration
Interface.
Important: The following information is not backed up and will be deleted if you delete the database:
v User attributes that are stored in the database and not in the user registry
v Credential data that is stored in the default vault implementation
2. Add passwords to the wkplc.properties, wkplc_dbdomain.properties, and wkplc_dbtype.properties
files, located in the wp_profile_root/ConfigEngine/properties directory, or specify passwords on the
command line.
3. Decide whether to keep your database as is to preserve WebSphere Portal information or perform the
following steps to remove the information from the database:

Note: If you choose to keep the database information, you cannot use it with subsequent installations
although you can still access the information through your database software. Also, if you keep the
information, you can always delete the WebSphere Portal databases and database tables later using
your database software.
a. Run the ./stopServer.sh WebSphere_Portal -username admin_userid -password admin_password
from the wp_profile_root/bin directory.
b. Run the ./ConfigEngine.sh remove-schema -DWasPassword=password
-Drelease.DbPassword=password -Dcustomization.DbPassword=password
-Dcommunity.DbPassword=password -Djcr.DbPassword=password -Dfeedback.DbPassword=password
-Dlikeminds.DbPassword=password task from the wp_profile_root/ConfigEngine directory to remove
all database tables.
Note: Some tables may remain in the IBM Java Content Repository database. Removing the
database will remove these tables.
Uninstalling a single server on AIX:
If you have a complete and functional uninstallation program, you can uninstall IBM WebSphere Portal
only or both WebSphere Portal and IBM WebSphere Application Server.
Perform the following steps to uninstall WebSphere Portal using the uninstallation program:
1. Ensure that you are logged in as the root user before performing the uninstallation task; this step is
especially important if you operate WebSphere Portal with a non-root user.
2. Run the ./stopServer.sh WebSphere_Portal -username admin_userid -password admin_password task,
from the wp_profile_root/bin directory, to stop the WebSphere_Portal server.
3. Verify that there are no other installations or uninstallations running.
4. Locate and delete the /tmp/portalinstall.lockfile file if present.
Note: The Portal installer creates the portalinstall.lockfile to prevent two installations or
uninstallations from running simultaneously. This is a temporary file and ordinarily gets deleted when
the installation or uninstallation successfully completes, but it may not get deleted during an aborted
or crashed procedure. Until this file is deleted, it will not be possible to initiate another installation.
5. Enter one of the following uninstallation commands:
Table 371. Uninstallation commands
Option Commands
Graphical user interface PortalServer_root/uninstall/uninstall.sh
Console mode PortalServer_root/uninstall/uninstall.sh -console
Silent PortalServer_root/uninstall/uninstall.sh -options
"path_to_file/response_filename", where path_to_file is
the full path to the response file and response_filename is
the name of the file. A sample uninstall response file
directory.
6. Remove any remaining WebSphere Portal directories from your directory structure.
7. Examine all running processes and kill any that contain the PortalServer_root/uninstall directory or
restart the machine, especially if you intend to reinstall WebSphere Portal on the same machine.
Installing 1379
Related tasks:
“Uninstalling manually on AIX”
If the uninstallation program is not present or an aborted installation did not create a complete and
functional uninstallation program, you can manually uninstall IBM WebSphere Portal.
Uninstalling manually on AIX

Perform the following steps to manually uninstall WebSphere Portal:

5. Uninstall WebSphere Application Server; if you need to manually uninstall it, refer to Uninstalling
manually.
6. Perform the following steps to edit the vpd.properties file and remove WebSphere Portal
information:
a. Open the /usr/lib/objrepos/vpd.properties file.
b. Remove all lines that contain the PortalServer_root installation string.
c. Save and close the vpd.properties file.
7. Perform the following steps to edit the .ITLMRegistry file and remove WebSphere Portal information:
a. Open the /root/.ITLMRegistry file.
c. Save and close the .ITLMRegistry file.
8. Perform the following steps to remove WebSphere Portal entries from your operating system's native
registry using the native registry tool:
a. Search for the two entries in the AIX registry:
Table 372. Entries to search for in the AIX registry
Entry Results
#lslpp -l | grep IBMWPS If there are no matching entries when using this
command, no further action is required for this entry.
The resulting list of packages are in the "IBMWPScore
7.0.0.0 COMMITTED ISMP installed entry" format.
#lslpp -l | grep WebSpherePortalProduct If there are no matching entries when using this
The resulting list of packages are in the
"WebSpherePortalProduct 7.0.0.0 COMMITTED ISMP
installed entry" format.
b. Remove the #geninstall -u IBMWPScore and #geninstall -u WebSpherePortalProduct entries.

9. Delete the PortalServer_root directory tree and the wp_profile_root directory tree.

Uninstalling from a cluster on AIX
Preparing to uninstall a cluster on AIX:
Before uninstalling your cluster, you must prepare your system; for example, adding passwords to the
properties files and keeping or discarding database information.
Important: You must issue the removeNode command to unfederate a node prior to uninstalling because
WebSphere Portal cannot uninstall a federated node.
Interface.
2. Perform the following steps to remove a node from the cell:
Note: Removing a WebSphere Portal node from the cell does not affect the cluster definition you
originally created for your cluster. The cluster definition remains intact even after removing all
WebSphere Portal nodes from the cell. In addition, removing a WebSphere Portal node from the cell
does not remove the product's enterprise applications from the deployment manager. The enterprise
applications remain and continue to be associated with the cluster definition.
a. Log in to the Deployment Manager administrative console.
b. Click Servers > Clusters > cluster_name > Cluster members, where cluster_name is the name of
your cluster, click the server you want to stop, and then click Stop.
c. Perform the following steps if you have a dynamic cluster:
1) Navigate to System Administration > Node groups > node group name > Nodes > Node
group members.
2) Select the box for the node to be uninstalled and then click Remove.
3) Save the changes to the master configuration repository.
4) Synchronize the node to be uninstalled.
d. Click System Administration > Nodes, select the node containing the server you want to remove
from the cell, and then click Remove Node to remove the node from the cell.
Important: Make sure that you choose the Remove Node option to remove the node from cell and
not the Delete option on the Cluster members view. Using the Delete option completely deletes
the node, which removes the existence of the server from the deployment manager and does not
leave a means for restoring the WebSphere Portal node to a stand-alone system. Using the Delete
option can prevent the WebSphere Portal server from working after it is deleted from the cluster. If
Remove Node does not successfully remove the node, click Force Delete to remove the node.
e. Click Save to save the changes made to the cell's configuration.
f. Repeat the above steps for each node in the cluster and cell that needs to be uninstalled.
g. Optional: Perform the following steps if you plan to convert the stand-alone server to a working
portal:
1) Use a text editor to open the wkplc.properties file.
2) Change the value of the CellName property so that it matches the cell name of the node itself.
Installing 1381
v When you remove the node from the cell, the cell name for the node reverts to the cell name
that was used before you federated the node.
v The cell name can be identified by the wp_profile_root/cells/cell_name directory on the node,
where cell_name indicates the cell to which the node belongs.
3) Change the value of the ServerName property to the original WebSphere Portal server name.
4) Ensure that the value of the PrimaryNode property is set to true.
5) Save your changes.
command line.
Related tasks:
removeNode command
Uninstalling a cluster on AIX:
only or both WebSphere Portal and IBM WebSphere Application Server from your cluster.

Option Commands
directory.
7. Restart the machine, especially if you intend to reinstall WebSphere Portal on the same machine.
8. Go to Deleting specific cluster members for information on how to delete a cluster member, if it exists,
from the deployment manager.
9. Perform the following steps to delete the WebSphere Portal server, if it exists, from the deployment
manager:
a. Click Servers > Application Servers.
b. Select the check box for the WebSphere Portal server you want to delete.
c. Click Delete.
Uninstalling WebSphere Portal on IBM i

Single server: Uninstalling on IBM i

You can uninstall IBM WebSphere Portal using either the graphical user interface, console mode, or silent
uninstallation program. You can also choose to remove the Portal information from your DB2 database
and/or to remove the IBM WebSphere Application Server profile created during the installation.
Preparing to uninstall a single server on IBM i:

Interface.
Installing 1383
Note: If you choose to keep the database information, you cannot use it with subsequent WebSphere
Portal installations although you can still access the information through your database software.
Also, if you keep the information, you can always delete the WebSphere Portal databases and
database tables later using your database software.
a. Run the stopServer WebSphere_Portal -username admin_userid -password admin_password from
the wp_profile_root/bin directory.
b. Choose one of the following options to delete the database information:
Table 374. Options to delete the database information.
If your database is a... Then perform the following steps:
Local IBM DB2 for i Run the ConfigEngine.sh remove-schema
-DWasPassword=password -Drelease.DbPassword=password
-Dcustomization.DbPassword=password
-Dcommunity.DbPassword=password
-Djcr.DbPassword=password
-Dfeedback.DbPassword=password
-Dlikeminds.DbPassword=password task from the
wp_profile_root/ConfigEngine directory to remove all
database tables.
Remote IBM DB2 for i 1. Use a 5250 PC session to log on to the system where
the remote database exists.
2. Type wrklib prefix* on the command line to display
a list of all libraries created for the remote database,
where prefix is the prefix for your database name.
3. Type 4 in the Opt field beside each library name that
you want to delete and then press Enter.
Uninstalling a single server on IBM i:
1. Run the following tasks to stop the server1 and WebSphere_Portal servers from the wp_profile_root/bin
directory:
a. stopServer server1 -username admin_userid -password admin_password
b. stopServer WebSphere_Portal -username admin_userid -password admin_password
3. Perform the following steps to delete the WebSphere Portal server installed on the WebSphere
Application Server profile created by the installation program.
a. Log on to an i 5250 session and type STRQSH to start the Qshell Interpreter.
b. Ensure that all active servers are stopped.
c. Run one of the following tasks, from the /QIBM/ProdData/WebSphere/PortalServer/V7/
product_offer/uninstall directory, for each profile you want to remove:
Note: product_offer is either Server or Content, depending on the product offering that you
purchased.

Table 375. Task options for deleting the WebSphere Portal server installed on the WebSphere Application Server
profile created by the installation program
WebSphere Application Server system type Command
WebSphere Application Server installation with default rmvwpprofile.sh -profileName wp_profile -username
ND path: /QIBM/ProdData/WebSphere/AppServer/V7/ND userid -password password
Custom WebSphere Application Server path other than rmvwpprofile.sh -profileName wp_profile -username
the ND default path (above) userid -password password -waslocation
/QIBM/ProdData/WebSphere/AppServer/V#/Base, where V#
is the WebSphere Application Server Version number
such as V7
rmvwpprofile.sh -profileName wp_profile -username

userid -password password -waslocation /MyWas
Important: Add the leavedb=true parameter to the rmvwpprofile.sh command to keep the
database information.
Note: product_offer is either Server or Content, depending on the product offering that you purchased.
Option Commands
Console mode local /QIBM/ProdData/WebSphere/PortalServer/V7/
product_offer/uninstall/uninstall.sh
Silent local /QIBM/ProdData/WebSphere/PortalServer/V7/
product_offer/uninstall/uninstall.sh -silent
Related tasks:
“Uninstalling manually on IBM i”
Uninstalling manually on IBM i


directory:
3. Locate and delete the /tmp/InstallShield/portalinstall.lockfile file if present.
4. Uninstall WebSphere Application Server; if you need to manually uninstall it, refer to Manually
uninstalling the product for IBM i
Installing 1385
5. Delete the /tmp/iseries directory, which is a temporarily copied i WebSphere Application Server
install image during the WebSphere Application Server installation, if you ran the installation using a
remote Windows workstation.
Uninstalling from a cluster on IBM i

Preparing to uninstall a cluster on IBM i:
Interface.
group members.

portal:
Note: If you choose to keep the database information, you cannot use it with subsequent WebSphere
Portal installations although you can still access the information through your database software.
Also, if you keep the information, you can always delete the WebSphere Portal databases and
database tables later using your database software.
a. Run the stopServer WebSphere_Portal -username admin_userid -password admin_password from
the wp_profile_root/bin directory.
b. Choose one of the following options to delete the database information:
Table 377. Options to delete the database information.
If your database is a... Then perform the following steps:
Local IBM DB2 for i Run the ConfigEngine.sh remove-schema
-DWasPassword=password -Drelease.DbPassword=password
-Dcustomization.DbPassword=password
-Dcommunity.DbPassword=password
-Djcr.DbPassword=password
-Dfeedback.DbPassword=password
-Dlikeminds.DbPassword=password task from the
wp_profile_root/ConfigEngine directory to remove all
database tables.
Remote IBM DB2 for i 1. Use a 5250 PC session to log on to the system where
the remote database exists.
2. Type wrklib prefix* on the command line to display
a list of all libraries created for the remote database,
where prefix is the prefix for your database name.
3. Type 4 in the Opt field beside each library name that
you want to delete and then press Enter.
Related tasks:
removeNode command
Uninstalling a cluster on IBM i:
directory:
Installing 1387
3. Perform the following steps to delete the WebSphere Portal server installed on the WebSphere
Application Server profile created by the installation program.
a. Log on to an i 5250 session and type STRQSH to start the Qshell Interpreter.
b. Ensure that all active servers are stopped.
c. Run one of the following tasks, from the /QIBM/ProdData/WebSphere/PortalServer/V7/
product_offer/uninstall directory, for each profile you want to remove:
Note: product_offer is either Server or Content, depending on the product offering that you
purchased.
Table 378. Task options for deleting the WebSphere Portal server installed on the WebSphere Application Server
profile created by the installation program
WebSphere Application Server system type Command
WebSphere Application Server installation with default rmvwpprofile.sh -profileName wp_profile -username
ND path: /QIBM/ProdData/WebSphere/AppServer/V7/ND userid -password password
Custom WebSphere Application Server path other than rmvwpprofile.sh -profileName wp_profile -username
the ND default path (above) userid -password password -waslocation
/QIBM/ProdData/WebSphere/AppServer/V#/Base, where V#
is the WebSphere Application Server Version number
such as V7
rmvwpprofile.sh -profileName wp_profile -username

userid -password password -waslocation /MyWas
Important: Add the leavedb=true parameter to the rmvwpprofile.sh command to keep the
database information.
Note: product_offer is either Server or Content, depending on the product offering that you purchased.
Option Commands
Console mode local /QIBM/ProdData/WebSphere/PortalServer/V7/
product_offer/uninstall/uninstall.sh
Silent local /QIBM/ProdData/WebSphere/PortalServer/V7/
product_offer/uninstall/uninstall.sh -silent
5. Go to Deleting cluster members for information on how to delete a cluster member, if it exists, from
the deployment manager.
manager:
c. Click Delete.
Uninstalling WebSphere Portal on Linux


Single server: Uninstalling on Linux

Preparing to uninstall a single server on Linux:

Interface.
command line.
Uninstalling a single server on Linux:
Perform the following tasks to uninstall WebSphere Portal:

Installing 1389
Option Commands
directory.
Related tasks:
“Uninstalling manually on Linux”
Uninstalling manually on Linux


manually.
information:
a. Open the /vpd.properties or /root/vpd.properties file.

Uninstalling from a cluster on Linux

Preparing to uninstall a cluster on Linux:
Interface.
group members.
portal:
Installing 1391
command line.
Related tasks:
removeNode command
Uninstalling a cluster on Linux:

Option Commands
directory.
manager:
c. Click Delete.
Uninstalling WebSphere Portal on Solaris

Single server: Uninstalling on Solaris

Preparing to uninstall a single server on Solaris:

Interface.
command line.
Installing 1393
Uninstalling a single server on Solaris:
Option Commands
directory.

Related tasks:
“Uninstalling manually on Solaris”
Uninstalling manually on Solaris


manually.
information:
a. Open the /vpd.properties or /root/vpd.properties file.
a. Search for the two entries in the Solaris registry:
Table 383. Entries to search for in the Solaris registry
Entry Results
#pkginfo | grep IBMWPS If there are no matching entries when using this
The resulting list of packages are in the "application
ISIBMWPSc WebSphere Portal Server Component"
format.
#pkginfo | grep WebSpherePortalProduct If there are no matching entries when using this
The resulting list of packages are in the "application
WebSpherePortalProduct WebSphere Portal Server
Product" format.
b. Change to the /var/sadm/pkg directory where the package information is registered.

c. Enter the #pkgrm ISIBMWPSc WebSpherePortalProduct command to remove packages.
Installing 1395
Uninstalling from a cluster on Solaris

Preparing to uninstall a cluster on Solaris:
Interface.
group members.
portal:

command line.
Related tasks:
removeNode command
Uninstalling a cluster on Solaris:
Installing 1397
Option Commands
directory.
manager:
c. Click Delete.
Uninstalling WebSphere Portal on Windows

Single server: Uninstalling on Windows

Perform the following tasks to uninstall WebSphere Portal:
Preparing to uninstall a single server on Windows:

Interface.

a. Run the stopServer.bat WebSphere_Portal -username admin_userid -password admin_password
from the wp_profile_root\bin directory.
b. Run the ConfigEngine.bat remove-schema -DWasPassword=password
-Dlikeminds.DbPassword=password task from the wp_profile_root\ConfigEngine directory to remove
Uninstalling a single server on Windows:
1. Run the stopServer.bat WebSphere_Portal -username admin_userid -password admin_password task,
from the wp_profile_root\bin directory, to stop the WebSphere_Portal server.
3. Locate and delete the portalinstall.lockfile file, if present, located in the %TEMP% directory; for
example,C:\Documents and Settings\Administrator\Local Settings\Temp\portalinstall.lockfile.
Option Commands
Add or Remove Programs Open the Add or Remove Programs application from the
Control Panel and select WebSphere Portal.
Graphical user interface PortalServer_root\uninstall\uninstall.bat
Console mode PortalServer_root\uninstall\uninstall.bat -console
Silent PortalServer_root\uninstall\uninstall.bat -options
"path_to_file\response_filename", where path_to_file is
directory.
6. Perform the following steps to remove WebSphere Application Server entries from your operating
system's native registry using the native registry tool:
a. Read the Windows help system for information about using the Windows Registry Editor.
Installing 1399
Important: When editing the Windows registry, your computer may not function properly if you
delete the wrong information. If this happens, see the Windows Help system for information on
how to restore the registry.
b. Click Start > Run and then type regedit to start the Windows Registry Editor.
c. Delete all entries under the HKEY_CURRENT_USER > SOFTWARE > IBM > WebSphere
Application Server Network Deployment, including the WebSphere Application Server entry.
d. Run the sc delete service_name from a command prompt to remove a Windows service from the
Services list and registry. Click Start > Control Panel > Administration Tools > Services to view
the WebSphere Application Server services names.
Related tasks:
“Uninstalling manually on Windows”
Uninstalling manually on Windows


manually.
5. Perform the following steps to edit the vpd.properties file, located in the %SystemRoot% or
%USERPROFILE% directory, and remove WebSphere Portal information:
a. Open the vpd.properties file.
6. Perform the following steps to edit the .ITLMRegistry file, located in the %SystemRoot% or
%USERPROFILE% directory of the login ID used to install WebSphere Portal, and remove WebSphere
Portal information:
a. Open the .ITLMRegistry file.

c. Delete all entries under the HKEY_CURRENT_USER > SOFTWARE > IBM > WebSphere Portal
Server.
the WebSphere Portal services names.
Uninstalling from a cluster on Windows

Preparing to uninstall a cluster on Windows:
Interface.
group members.
Installing 1401
portal:
a. Run the stopServer.bat WebSphere_Portal -username admin_userid -password admin_password
from the wp_profile_root\bin directory.
b. Run the ConfigEngine.bat remove-schema -DWasPassword=password
-Dlikeminds.DbPassword=password task from the wp_profile_root\ConfigEngine directory to remove
Related tasks:
removeNode command
Uninstalling a cluster on Windows:

Option Commands
Add or Remove Programs Open the Add or Remove Programs application from the
Control Panel and select WebSphere Portal.
Graphical user interface PortalServer_root\uninstall\uninstall.bat
Console mode PortalServer_root\uninstall\uninstall.bat -console
Silent PortalServer_root\uninstall\uninstall.bat -options
"path_to_file\response_filename", where path_to_file is
directory.
6. Perform the following steps to remove WebSphere Application Server entries from your operating
system's native registry using the native registry tool:
c. Delete all entries under the HKEY_CURRENT_USER > SOFTWARE > IBM > WebSphere
Application Server Network Deployment, including the WebSphere Application Server entry.
the WebSphere Application Server services names.
manager:
c. Click Delete.
Applying fixes
Periodically fix packs are released to integrate product code fixes. Between fix pack releases, interim fixes
may be recommended or required to ensure product reliability and stability.
Update Installer
To apply a fix or fix pack to WebSphere Portal 7 you must use the update installer. You will find
more information about the WebSphere Portal 7 Update Installer on the IBM Support site. You
will find instructions for installing and a link to download the update installer for your operating
system on the following page: Update installer.
Recommended fixes
The Recommended fixes page provides links to fix pack and interim fix downloads, information
about what is recommended and what is required, and links to recommended related product
fixes. To find the most current service update information, see the Recommended fixes link below.
Installing 1403
Related tasks:
Recommended fixes and updates for WebSphere Portal and Lotus Web Content Management

Migrating
Successful migration requires significant planning and preparation, understanding the tools that are
involved, and careful execution of the appropriate steps in the order provided.
Understanding migration
Migration is the process of collecting configuration data and applications from an earlier installed version
of IBM WebSphere Portal and merging them into a newer installed version, so that the new environment
is identical to the earlier environment.
Migration is different from upgrading. With upgrading, you replace an existing installed version's
out-of-date files with current files. With migration, you install the new version of a product alongside of
the earlier version and then copy data from the earlier version to the new version. Migrating information
from the earlier version to the new version lets you use that information in the new version without
having to recreate it from scratch. Migration also lets you carry forward customizations that were
implemented in the earlier portal, so that you can continue to use those customizations in the new portal.
WebSphere Portal also supports integration with additional products to extend core functionality. If the
earlier portal environment is configured to work with one or more supported products that provided
integrated features, you need to follow the migration procedures for the integrated product.
Unless otherwise noted, portlets and components in the earlier version are typically not migrated if they
are not available in the version to which you are migrating. Examples include the MarketWatch portlets,
Domino Document Manager portlet, Inline QuickPlaces portlet, Microsoft Exchange 2000 portlets, and
portlets that were developed using WebSphere Portal Application Integrator (WPAI).
Migrated elements are not automatically upgraded to use features that are available in the new version.
Taking advantage of new functionality that was not available in the earlier portal requires additional
attention after migration is complete.
You can migrate to WebSphere Portal Version 7.0 from either Version 6.0.1.x or 6.1.x. For additional
information, see Supported migration paths.
Related concepts:
“Supported migration paths”
Migration is supported from a secure server only, and between equivalent offerings. For example, you
can migrate from WebSphere Portal Enable V6.0.1.x to WebSphere Portal Enable V7, but not from
WebSphere Portal Express V6.0.1.x to WebSphere Portal Extend V7,
Migration Central for WebSphere Portal and Web Content Management
Supported migration paths

The table below summarizes supported migration paths:
1405
Table 387. Offerings and supported migration paths
WebSphere Portal Express WebSphere Portal Version Web Content Manager
Offering Version 7.0 7.0 (Enable, Extend) Version 7.0
WebSphere Portal Express Supported Not Supported Not Supported
V6.0.1.x on WebSphere
Application Server Version
6.0
WebSphere Portal Server Not Supported Supported Supported
V6.0.1.x on WebSphere
6.0
WebSphere Portal Express Supported Not Supported Not Supported
Version 6.1.x on WebSphere
6.1
WebSphere Portal Server Not Supported Supported Not Supported
V6.1.x (Enable, Extend) on
WebSphere Application
Server Version 6.1
Web Content Manager V6.1 Not Supported Not Supported Supported
on WebSphere Application
Server Version 6.1
WebSphere Portal Server Not Supported Supported Not Supported
V6.1.x (Enable, Extend) on
Server Version 7.0
Web Content Manager V6.1 Not Supported Not Supported Supported
on WebSphere Application
Server Version 7.0
Important: Migration is supported only from the two latest fix pack levels for any listed offering. For
example, if you are using WebSphere Portal Version 6.1.0.1, and the two latest available fix packs are
6.1.0.3 and 6.1.0.4, you must apply one of those fix packs before you can migrate to Version 7.0. Similarly,
if you are using WebSphere Portal Version 6.0.1.0, you must apply one of the two latest available fix
packs for that offering, which might be 6.0.1.6 and 6.0.1.7, before you can migrate to Version 7.0. See the
Related topics section below for information on available fix packs.
If you are not sure which earlier version is installed, run the following command from the
wp_profile_root/PortalServer/bin directory of the earlier portal server:
Windows: WPVersionInfo.bat
UNIX: ./WPVersionInfo.sh
i: WPVersionInfo.sh
Note: You cannot upgrade the source portal with a fixpack after migration if you intend to re-migrate the
JCR. For example, if your source portal is running Version 6.1.0.4 and you migrate the portal to Version
7.0, you cannot then upgrade the source portal to Version 6.1.0.5 and migrate the JCR again. This is not
supported.
Migrating from V6.0.1.x
Version 6.0.1.x administration pages and portlets are not migrated. Any customizations to these pages or
portlets in the earlier installed portal must be recreated in the new installed version.

Migration from V6.0 to V7 has some known limitations. For example, you cannot migrate access control
of V6.0 administrative pages, and some wires cannot be migrated. For more information, see technote
1413503.
Migrating from V6.1.x
If you are migrating from WebSphere Portal 6.1.x, the process for migrating the source (or earlier) portal
environment depends on whether the source portal uses IBM WebSphere Application Server Version 6.1
or 7.0.
Remote migration note: Remote migration is not supported if you are running WebSphere Portal V6.1.x
on WebSphere Application Server V7.0. This is because remote migration can only occur if you are
migrating the application server profile, which is not performed if WebSphere Portal is already installed
on WebSphere Application Server V7.0.
When you migrate from V6.1.x to V7, WebSphere Portal automatically migrates the following applications
and configuration data so that the new portal looks and behaves the same way as the earlier portal:
v Security configuration
v Access control
v Portal behavior
v Portlet applications
v Customized portal resources, such as themes and skins, pages, and portlets
v Personalized content
v Virtual portals
Web content server migration scenarios
The steps required to migrate your Web Content Manager data and portlets will differ depending on
which version of Web Content Manager you are migrating from.
Migrating from versions 6.0 and 6.1
Follow the WebSphere Portal migration instructions, and then perform any post-migration steps
required to update your web content as specified in the "Deploying new functionality in a
migrated portal" section.
Migrating from version 5.1
Migrating 1407
1. When migrating from version 5.1 you must first migrate to WebSphere Portal version 6.1. We
recommend migrating to version 6.1.0.4 or later. Refer to the WebSphere Portal version 6.1
Information Center for further information.
2. Once you have migrated to WebSphere Portal version 6.1.0.4 or later, you then migrate your
data and portlets to version 7.0.
Web Content Management migration notes: When you migrate your web content server, the
wp_profile_root/PortalServer/wcm/shared/app/config/wcmservices/WCMConfigSerivce.properties file is
migrated automatically. A copy of the original configuration is created in the same directory as the
backup. When the migration occurs, the following changes are made to the properties file:
v Deprecated properties are removed.
v The default values for renamed properties are updated with their new default values, where needed.
Otherwise, only the property names are changed.
v New properties are added, along with their default values.
v The properties connect.businesslogic.module and syndication.keepAliveInterval are always updated
with new default values.
v All other property names and values are preserved.
Document Manager migration
As of version 6.1, Document Manager is no longer available in WebSphere Portal. Before migrating your
data, you will need to replace Web content previously stored as documents in a document library with
either file resource components or file resource elements stored in authoring templates, content items or
site areas.
Migrating from versions 6.0
Before migrating to version 7.0, follow the instructions in the “Document migration” on page
1435 topic.
Migrating from version 5.1
As the document list portlet cannot be installed on a version 5.1 server or earlier, you will need
to first migrate your version 5.1 server to version 6.0. Refer to the WebSphere Portal version 6.0
Information Center for further information. Then, before migrating to version 7.0, follow the
instructions in the “Document migration” on page 1435 topic.

Related concepts:
“Understanding migration” on page 1405
Related tasks:
“Preparing a source portal on a V6.1 application server” on page 1506
To ensure proper migration from WebSphere Portal Version 6.1.x, clean up that environment and apply
the appropriate interim fixes.
“Preparing a source portal on a V7 application server” on page 1554
Fix List for WebSphere Portal V6.0
Fix List for WebSphere Portal V6.1.0
Technote 1413503
IBM Software Support, DB2 9
WebSphere Portal Update Installer
High-availability systems
Many solutions, especially those that use Web Content Manager, require constant access to either
authoring environments where content is constantly updated or created, or delivery environments that
render websites that cannot be taken off-line. In these cases, migration cannot be performed directly on
the local server, but must instead be performed on a remote server. The steps required to migrate your
system to a remote server will differ depending on what version you are migrating from.
Migrating a V6.0.1.x high-availability system
When migrating a V6.0.1.x you will always be migrating to a new environment, so there is little
difference between high and low availability systems. The basic process of migration is the same for both
types of systems.
During the migration process, your users will still be creating web content on the original V6.0.1.x
system. Once the V7.0 system is fully migrated and tested, you can quickly update your web content by
performing a “Updating data after migration” on page 1579. This will update the content of your V.7.0
data repository to match the latest data on your V6.0.1.x system.
Migrating a V6.1.x high-availability system
When migrating a V6.1.x you are essentially updating your current system. This migration process is not
suitable for high-availability systems because your system will not be available to your users during the
migration process. In this case, you need to do one of the following:
Take a clustered server off-line
In this scenario you have a set of clustered servers. You take one of the servers out of the cluster
and perform the migration on this server. Your users continue to use the original system until the
new system is ready to be used.
Make a clone of one of your V6.1.x servers
Migrating 1409
In this scenario, you create a copy of your V6.1.x and perform the migration on the copy. Your
users continue to use the original system until the new system is ready to be used.
Copying configuration settings:
You use “The XML configuration interface” on page 1876 to copy configuration settings
from your V6.1.x system.
Cloning web content:
You can clone your web content data repository to the remote system that will be
migrated: Cloning a web content repository
During the migration process, your users will still be creating web content on the original V6.1.x system.
Once the V7.0 system is fully migrated and tested, you can quickly update your web content by
performing a “Updating data after migration” on page 1579. This will update the content of your V.7.0
data repository to match the latest data on your V6.1.x system.
Related tasks:
“Updating data after migration” on page 1579
After you have migrated your version 6.0 or 6.1 system to Version 7.0, and successfully tested it, update
your Version 7.0 data with the latest version 6.0 or 6.1 data.
Planning for migration

Each migration is unique. Successful migration requires careful planning to understand the scope of the
effort that is required and being aware of the issues that are involved. Additional tasks may be needed
depending on how you customized the earlier portal environment and which components you used.
Prior to migrating, take time to inventory your server, assess the existing portal installation, and establish
a performance baseline. Review system requirements for the new version of IBM WebSphere Portal and
determine whether you need to upgrade any parts of your infrastructure such as database, LDAP server,
or Web server, or collaborative software such as IBM Lotus Domino, IBM Lotus Sametime, or IBM Lotus
Quickr.
Because migration may require additional tasks that affect areas such as database, Lightweight Directory
Access Protocol (LDAP), IBM WebSphere Application Server, IBM Web Content Manager, and so on, the
administrator who manages migration should coordinate with the individuals who are responsible for
these areas, to let them know when additional tasks are required.
Using the migration instructions in this information center
Migration instructions in this information center are organized according to the version from which you
can migrate:
v WebSphere Portal Version 6.0.1.x
v WebSphere Portal Version 6.1.x on WebSphere Application Server Version 6.1
v WebSphere Portal Version 6.1.x on WebSphere Application Server Version 7
The tools and steps that you use to migrate a V6.0.1.x portal are largely unchanged from previous
releases. The process for migrating a V6.1.x portal takes advantage of enhanced tools to provide an
improved migration experience with reduced downtime required. Use the planning checklist at the
beginning of the appropriate section to help plan your migration and identify issues you may need to
consider.
After you complete migration, see the section on deploying new functionality for additional information.
While these tasks are not part of the migration process, they are included here as a convenience for users
who want to enable newer functionality in their migrated portal.

Migrating V6.0.1.x
When you migrate from IBM WebSphere Portal Version 6.0.1.x, WebSphere Portal Version 7.0 uses the
same overall process and tools as Version 6.1. Only the primary node and stand-alone servers are
migrated. The deployment manager and secondary nodes cannot be migrated and must be created anew
in the new portal environment.
Notes:
v When installing the new version of WebSphere Portal, use the same operating system user ID and
access level that was used to install the earlier portal.
v When running migration commands, execute only one command at a time.
Planning checklist: V6.0.1.x portal

Use the worksheet below to plan your migration from IBM WebSphere Portal Version 6.0.1.x and identify
issues that require special attention. You might also want to print a copy of this document so that you
can add your own notes to the table below.
Table 388. Checklist for planning migration
Checkpoint Notes User Notes
Infrastructure
Product version and family Which product version and Always try to migrate to
family is deployed in the the latest release of the
existing environment? target version.
Which product version and Migration is supported

family do you want to from the two latest
migrate to? available fix pack levels of
Version 6.0.1.x and between
the same product families
(Express, Enable, Extend),
and from Express to
Enable, Express to Extend,
and Enable to Extend. For
example, if you are using
WebSphere Portal Version
6..0.1.0, and the two most
recent fix packs are 6.0.1.6
and 6.0.1.7, you must
upgrade to either fix pack
before you can migrate to
Version 7.0.
Migration is not supported

to a portal release that
contains an enabled feature
pack.
Deployment scenario Do you have a standalone You cannot configure a
server environment or a portal cluster on the target
clustered server portal until after you have
environment? migrated the stand-alone
node.
Migrating 1411
Table 388. Checklist for planning migration (continued)
Hardware What hardware does the If you plan to use the same
existing portal run on? hardware, and want to
continue running the earlier
Do you plan to migrate to source portal during
the same hardware or to migration, ensure that there
new hardware? is enough capacity to run
both the source server and
the target server.
If you plan to use new

hardware, you must update
the WebSphere Application
Server Network
Deployment Version 7
Supplements Disc 2 with
the appropriate portal
migration files, as described
in Assembling
supplementary files.

Operating system What operating system and You can migrate from an
version does the existing older version of an
environment run on? operating system to a
newer supported version of
Does the target version that that operating system, or
you want to migrate to from a 32–bit version of an
support that operating operating system to a
system and version? supported 64–bit version of
that operating system.
Migrating between different

operating systems (for
example from Windows to
i, or from z/OS to UNIX) is
not supported as a direct
migration option. If
migration to a different
operating system is
required, you would use
1. Stand-alone: Move the
previous version to the
new operating system
using staging to
production steps.
2. Stand-alone: Migrate to
the new portal on the
existing operating
system, then use the
staging to production
steps to move to the
new operating system.
3. Cluster: Create a new
cluster member in the
previous portal version
on the target operating
system, make it the
primary node, then
migrate from that node.

7.0 does not support SUSE
SLES 9. If your earlier
portal runs on SLES 9, you
need to upgrade to SUSE
SLES 10 before migrating to
7.0. See the SLES 10
documentation for
instructions on upgrading
the operating system.
Application server
Migrating 1413
User registry What does the existing Perform maintenance
portal installation use to cleanup on users and
store user account groups as needed before
information: migrating. For example,
v Lightweight Directory clean up deleted users and
Access Protocol (LDAP) their personalized pages
before starting migration.
v WebSphere Portal
database Migration assumes that the
v Custom user registry earlier installed portal and
the new installed portal use
If you use LDAP, do you the same LDAP server. If
plan to move to a different the new version of
LDAP server? WebSphere Portal does not
support the LDAP that you
used with the earlier portal
server, upgrade the LDAP
on the earlier portal server
prior to migration.
If the earlier portal and the

new portal are configured
to use a standalone LDAP
user registry, the users and
groups in the new portal
installation must be the
same as the directory users
and groups in the earlier
portal installation.

Database Does the new portal You can migrate from an
installation support the older version of a database
database that the earlier server to a newer version
portal installation uses? of that database server.
Can the database be database servers is not
upgraded if needed? supported. For example,
you cannot migrate from an
IBM DB2 Universal
Database Enterprise Server
Edition database server to
an Oracle database server.
When you migrate from

Version 6.0.x, WebSphere
Portal reuses the database
tables from the earlier
version in the new version.
If you used IBM
Cloudscape as the default
DBMS in the earlier
version, you must transfer
your data to a supported
DBMS before migrating
since the new version does
not support Cloudscape.
When migrating Microsoft

SQL Server database tables
to WebSphere Portal
Version 7.0, the minimum
level that is supported is
SQL Server 2005. If you
used Microsoft SQL Server
2000 with WebSphere Portal
version 6.0.1.3 or later, you
must install and configure
SQL Server 2005 before you
can migrate to WebSphere
Portal Version 7.0. For
details, see technote
1295590 on configuring
Microsoft SQL Server .
If you are migrating from

WebSphere Portal
configured to use DB2 V9,
ensure that your source
environment is running the
minimum required level –
either V9.1 with Fix Pack 6
or later, or V9.5 with Fix
Pack 5 or later.
Migrating 1415
Database drivers WebSphere Portal Version
7.0 requires the use of
either type 2 or type 4
database drivers, and both
the source and target
databases must use the
same driver type. Which
driver type you use is
determined by the
requirements of the target
database.
Database schemas WebSphere Portal generates
SQL scripts that
automatically upgrade
database schemas during
migration.
Web server What HTTP server does the
existing installation use?
Does the new installation

support this HTTP server?
External security Third-party security
settings are not migrated
automatically and must be
reconfigured when setting
up security in the target
portal.

Virtual portals Have multiple portals been You must manually recreate
installed? each virtual portal in the
new installation before you
can migrate its contents.
Use the
create-virtual-portal
ConfigEngine task to create
an empty virtual portal
with the corresponding
name and URL context for
each virtual portal that you
want to migrate. Virtual
portals are then migrated
separately, one at a time,
after you migrate the portal
configuration.
If a virtual portal's admin

pages are located under the
wps.administration node,
WebSphere Portal migration
automatically sets these
pages to the Version 7.0
Portal theme. If the admin
pages are located under a
different page hierarchy,
you will need to manually
set them to the Version 7.0
Portal theme following
migration. For additional
information, see “Migrating
themes” on page 1441.
If you choose to update a

custom virtual portal
admin page hierarchy,
ensure that the virtual
portal's admin page has a
unique name assigned to it
prior to migration.
Pre-built Web sites
Administration and
Maintenance
Backup Do you have a backup plan Back up the existing portal
and schedule in place for database before starting
the new portal server? migration.
Cleanup and maintenance Have you deleted any users Perform the required
from the user registry who maintenance before
were registered portal migrating. See “Preparing
users? the V6.0.1.x environment
for migration” on page
1423.
Migrating 1417
Does your portal site Perform the required
contain orphaned data? maintenance before
migrating. See “Preparing
the V6.0.1.x environment
for migration” on page
1423.
Have you installed all Install all required fixes
required fixes that apply to before migrating. See
the earlier WebSphere “Preparing the V6.0.1.x
Portal installation? environment for migration”
on page 1423.
Have you changed the Changes to the scheduled
default settings of the cleanup service settings are
scheduled cleanup service? not migrated. If you
modified these settings in
the earlier portal and want
to continue using the same
settings in the new portal,
you must update the
settings on the new portal.
Customized portal
resources
Custom themes and Does the earlier portal
administration installation use custom
themes?
Does the earlier portal use Custom themes and skins
custom administration are automatically converted
themes? into a separate file,
MigratedThemes.ear.
Does the earlier portal use Administration pages and
customized administration portlets are never migrated
portlets or pages? forward from an earlier
version. Any
customizations to these
pages or portlets in the
earlier installed portal must
be recreated in the new
installed version.
Does the earlier portal use
customized global settings?
Have any portal service
configurations been
customized?
Custom portlets WebSphere Portal Version
7.0 uses the IBM
Server portlet container for
standard portlets. Migrated
portlets that rely on the
Java Specification Request
(JSR) 168 or 286 Portlet API
will continue to work
unchanged.

Does the earlier portal have Custom portlets must be
any portlets that were manually copied to the new
developed by using Struts portal installation.
Framework?
Does the earlier portal have The IBM Portlet API is still
any portlets that were supported, but it is
developed by using IBM deprecated in WebSphere
Portlet API? Portal V6.0 and later.
If you have portlets that

use the legacy API, you are
not required to convert
them to JSR portlets before
migrating; however, after
you complete migration,
converting these portlets is
strongly recommended. See
“Converting IBM portlets”
on page 3325 for more
information.
Does the earlier portal have The pbportlet.jar file that
custom portlets that use is included in a custom
Click-To-Action (C2A)? portlet or used in a custom
application must be
updated to match the
version that WebSphere
Portal Version 7.0 uses.
Are any portlets deployed You must redeploy these
as part of an Enterprise portlets directly into
Application by using an WebSphere Application
EAR file? Server as they were
deployed into the source
server. The Portal migration
process automatically
registers these portlets for
you.
Do any custom applications You must update these
in the earlier portal use applications to use the
private IBM APIs? public version of the IBM
APIs.
Have you installed and Third-party portlets must
deployed third-party be certified for use with the
portlets? latest version of WebSphere
Portal.
Remote portlets To migrate remote portlets
(portlets that are provided
as WSRP services), you
must ensure that the WSRP
Producer is available before
you run the
portal-post-upgrade task
to import content to the
new portal installation.
Migrating 1419
Wires Wires that have declared
endpoints are successfully
migrated. However, if one
of the wiring endpoints is a
programmatically added
endpoint, it might not yet
exist when migration
attempts to create the wire;
in this case, the wire
migration fails.
Private wires Do you have portlets that Private wires cannot be
use private wires? migrated from V6.0.1.x
because of a limitation in
the earlier version.
Search Do you want to migrate Search Web collections that
custom search collections? were created in an earlier
version of WebSphere
Portal can be exported and
imported into Version 7.0.
See “Migrating web search
collections” on page 1451.
The pre-defined categorizer

option in WebSphere Portal
6.0.x is no longer available
starting in V6.1. If you used
this option to create search
collections, you can import
the search collections into
the current version after
enabling the required
parameter. For details, see
technote 1306912.
Personalization What is your migration If you are migrating from
scenario for personalized V6.0.1.3 or later, you must
portal content? connect to a copy of the
earlier portal's JCR
database domain before
running the migration
tasks. See “Reusing V6.0.1.x
JCR domain data” on page
1430. Then refer to
“Migrating V6.0.x
personalization data” on
page 1481.
Composite applications Do you have composite See “Migrating composite
applications to migrate? applications” on page 1475

Document Manager Do you have content stored Document Manager is not
in document libraries? available in WebSphere
Portal Version 7.0 and is
effectively replaced with a
stand-alone IBM Lotus
Quickr server that is
integrated with your
WebSphere Portal
environment.
For general guidance, refer

to “Migrating documents
from Portal Document
Manager to Quickr
Document Libraries” on
page 1483.
IBM Web Content Manager Web Content Manager
requires a JCR repository of
the same version. Even
though you might have
different version
repositories stored in the
same database, Web
Content Manager V7.0 only
works with the V7.0
repository.
If you have any Web

Content Manager data that
references a Portal
Document Manager library,
you must replace the Web
content that was stored as a
document in the document
library before you begin the
migration process. See
“Document migration” on
page 1435.
Business portlets See “Deprecated business
portlets” on page 1482.
Collaborative portlets iNotes, Lotus Notes View,
and Lotus Document
Viewer are migrated with
other portlet applications.
For information on
deprecated portlets
including My Lotus
QuickPlaces, Inline
QuickPlaces, Domino
Document Manager, and
Lotus Web Conferencing,
see “Deprecated
collaborative portlets” on
page 1483.
Migrating 1421
Related tasks:
“Preparing supplementary files for remote migration” on page 1463
Before migrating to a remote server on either Windows or UNIX, you need to prepare a directory that
contains required files from WebSphere Application Server combined with additional files that WebSphere
Portal provides.
Technote 1295590
Technote 1306912
V6.0.1.x production server migration scenarios

When migrating from WebSphere Portal Version 6.0.1.x, follow the overall sequence shown here to
prepare the source portal, target portal, and then migrate the core portal and other elements.
Version 6.0.1.x to 7.0 migration process

1. “Preparing for migration from V6.0.1.x” on page 1423
2. “Migrating Version 6.0.1.x customized resources” on page 1441
3. “Migrating a Version 6.0.1.x product configuration” on page 1453
4. “Migrating the access control configuration” on page 1472
5. “Migrating additional components” on page 1475
6. “Migrating deprecated portlets” on page 1482
7. “Verifying migration from V6.0.1.x” on page 1487
8. If you use Local Rendering portlets, enable syndication with either your Web content staging or
authoring server.
Migrating a V6.0.1.x clustered deployment

When you migrate from IBM WebSphere Portal V6.0.1.x, migrating to a cluster is not supported; you
must migrate to a stand-alone node where the new version of IBM WebSphere Portal is installed and then
set up the cluster.
After migrating to the stand-alone node, follow these instructions to federate the migrated node: A Step
by Step Guide to Federating a Migrated Portal v7 node.
Notes:
v Migrate the primary node (as opposed to a secondary node) from the earlier portal environment.
Migrating a secondary node can lead to security problems.
v Migrate to a new cell; do not attempt to federate a migrated node into an existing cell.
Note: This restriction does not apply if you are implementing your own custom user registry; you can
federate into an existing cell that matches the implementation of your custom user registry.
v The WebSphere Application Server Version 7.0 node name must be the same as the earlier server's
managed node. If you have already installed WebSphere Portal and did not specify the same node
name during installation as the earlier server's cluster managed node name, you can change the node
name.

Related tasks:
“Renaming the node” on page 2082
In a clustered environment, it may be necessary to rename a node because the deployment manager does
not permit duplicate node names in a cell. You must first change the name in the deployment manager
using the IBM WebSphere Application Server command renameNode. IBM WebSphere Portal stores the
node name information in the registry so after running the WebSphere Application Server command, you
would need to update the information in the registry.
Best Practices for Configuration Changes in WebSphere Application Server v6.x
Replacing document libraries

Document libraries were removed in Version 6.1. The strategy you use to replace your document library
in your Version 7.0 system depends on how you use your document library.
Keeping your entire document library
If you need to keep using a document library, you will need to move your document library to an IBM
Lotus Quickr server. Refer to the guidance for migrating documents from WebSphere Portal Document
Manager to Lotus Quickr Document Libraries.
Keeping documents displayed on Web pages
If your previous site referenced documents in IBM Web Content Manager Document Manager
components or elements, you can choose to convert these documents to file resource elements or
components. See “Document migration” on page 1435 for further information.
Preparing for migration from V6.0.1.x

Before migrating from IBM WebSphere Portal V6.0.1.x, make sure you complete the necessary tasks.
Related tasks:
“Preparing to migrate composite applications” on page 1475
Prior to running the migration tasks for composite applications, complete the prerequisite tasks. Whether
you migrate composite applications as part of the core portal migration or independently, the prerequisite
tasks will ensure successful migration of composite application artifacts and data.
Preparing the V6.0.1.x environment for migration

To ensure proper migration from IBM WebSphere Portal Version 6.0.1.x, perform the tasks described here
on the earlier portal.
Check that you have access to an administrative user ID and password for both WebSphere Portal and
IBM WebSphere Application Server.
Important: If you are running IBM WebSphere Portal on IBM i V5R4, you must apply the fix for APAR
SE34114 to the operating system to ensure successful migration. To download the fix, you can use either
the Send PTF Order (SNDPTFORD) command or the central site distribution process. For details, see the i
information center.
1. If you are using WebSphere Portal Version 6.0, 6.0.1, or 6.0.0.1, you must upgrade to one of the two
latest available fixpack levels before migrating to Version 7.0.
For instructions on upgrading, see the WebSphere Portal Version 6.0 information center. For
additional information on the WebSphere Portal update strategy, see Document 1248245, Update
Strategy for WebSphere Portal versions 5.1 and 6.0.
2. Run the WPSconfig.sh config-pk64247 command from the portal_server_root/config directory
before you begin migration. Installing the fix pack does not complete this step for you because only
installations that are supposed to be migrated require it.
Migrating 1423
3. Back up the databases and the entire directory structure for the earlier portal server installation.
4. Clean up the environment as follows:
v If you deleted portal pages, use the deletion cleanup service.
v If you deleted users or groups using your configured user registry, make sure to deregister those
users and groups using either the XML configuration interface or the Manage Users and Groups
portlet.
v Export or remove orphaned data.
5. Check for any anonymous users with the roles listed below and change them to User:
v Privileged User
v Editor
v Manager
v Delegator
v Security Administrator
v Administrator
6. To verify that the required values are specified in the wpconfig.properties file, run the
validate-database-connection-wps task on your previous environment.
7. Prepare for the WebSphere Portal update installer:
a. Create an update directory in your previous WebSphere Portal directory. For example, C:\Program
Files\WebSphere\PortalServer\update.
b. Download the WebSphere Portal Update Installer from the product support site and then unpack
the installer to the update directory that you created in the previous step.
c. Depending on the version you are migrating from, unzip the appropriate interim fixes from the
corresponding location in the current WebSphere Portal directory to the directory where you
unpacked the Update Installer:
v PortalServer_root/ui/prereq.migration.fixes/migration/fixes/6013
v PortalServer_root/ui/prereq.migration.fixes/migration/fixes/6014
8. Enter the required command to set the WAS_HOME environment variable for the previous version
directory where you will run the WebSphere Portal update installer:
v Windows: set WAS_HOME=was_old_root
For example: set WAS_HOME=C:\Program Files\WebSphere\AppServer
v UNIX: export WAS_HOME=was_old_root
For example: export WAS_HOME=/opt/Websphere/AppServer
v i: export WAS_PROD_HOME=was_old_prod_root
For example: Enter one of the following commands based on your WebSphere Application Server
level:
– For Version 6 Base, enter: WAS_PROD_HOME=/QIBM/ProdData/WebSphere/AppServer/V6/Base
– For Version 6 Network Deployment (ND), enter: export WAS_PROD_HOME=/QIBM/ProdData/
WebSphere/AppServer/V6/ND
9. Enter the appropriate command to apply the required interim fixes to your earlier portal
environment:
v Windows: updatePortal.bat -install -installDir wp_old_root -fix -fixDir
wp_old_root/update -fixes list of fixes
For example: updatePortal.bat -install -installDir "C:\Program Files\WebSphere\
PortalServer" -fix -fixDir "C:\Program Files\WebSphere\PortalServer\update" -fixes
PK07258 PK07872
v UNIX: ./updatePortal.sh -install -installDir wp_old_root -fix -fixDir wp_old_root/update
-fixes list of fixes

For example: ./updatePortal.sh -install -installDir /opt/WebSphere/PortalServer -fix
-fixDir /opt/WebSphere/PortalServer/update -fixes PK07258 PK07872
v i: updatePortal.sh -install -installDir wp_old_user_root -fix -fixDir wp_old_prod_root/
update -fixes list of fixes
For example: enter one of the following commands based on your WebSphere Application Server
level:
– For Version 6 Base: updatePortal.sh -install -installDir "QIBM/UserData/WebSphere/
AppServer/V6/Base/profiles/wp_profile/PortalServer" -fix -fixDir "/QIBM/ProdData/
PortalServer/V6/update" -fixes PK07258 PK07872
– For Version 6 Network Deployment (ND): updatePortal.sh -install -installDir
"/QIBM/UserData/WebSphere/AppServer/V6/ND/profiles/wp_profile/PortalServer" -fix
-fixDir "/QIBM/ProdData/PortalServer/V6/update" -fixes PK07258 PK07872
10. Ensure that your database in your source environment is running at the minimum required level,
including any fix packs, as specified in the WebSphere Portal detailed system requirements.
11. Migration can take awhile and interruptions to your HTTP connection during the export process or
import process can cause migration to fail. To avoid this problem, change your HTTP server timeout
to an unlimited length while performing migration. Refer to your HTTP server documentation for
information on how to change the timeout value.
12. Complete any required tasks to enable security. Migration is not supported with a non-secure server.
Note: If the portal uses eTrust SiteMinder to perform authorization, verify that the
SiteMinderLoginModule custom property is defined because any XML Configuration Interface
execution can be affected. For instructions on modifying the SiteMinderLoginModule custom property,
see the topic on Configuring eTrust SiteMinder to perform authorization for WebSphere Portal.
13. Check your LDAP server to determine the number of groups. If this number is greater than 200,
complete the performance tuning steps below:
a. Modify the wmm.xml file as follows:
1) Change to the wp_old_root/wmm directory.
Note: If using i, the directory is wp_user_old_root.

2) Open the wmm.xml file, locate the maximumSearchResults attribute, and change its value to a
number greater than the actual number of groups on the LDAP server; for example if the
LDAP server has 300 groups, enter 301.
4) If this is a clustered environment, change to the was_old_root/config/wmm directory of the
earlier version.
Note: If using i, the directory is was_user_old_root.

LDAP server has 300 groups, then enter 301.
b. If this is a clustered environment, modify the wmm.xml file for the earlier portal's deployment
manager system as follows
1) Change to the was_old_root/config/wmm directory.
LDAP server has 300 groups, enter 301.
Migrating 1425
c. Change the LDAP server search parameters based on your server's documentation to either an
unlimited value or a value large enough to handle exporting and importing large groups and
resources. For example:
v Search size limit: Unlimited
v Search time limit: Unlimited
v Idle timeout for paged searches: 172800
Note: This value should be 48 hours or more; no unlimited option is documented. The value is
in seconds.
d. Stop and restart your WebSphere Application Server administration server, if running in a base
application server node, or the deployment manager and node agent, if running in a network
deployment cell. Stop and restart the WebSphere_Portal server. If running in a clustered
environment, stop and restart all cluster members.
14. If you have customized any themes or skins in your V6.0.x environment, ensure that you have
properly deployed the themes or skins before migrating, as described in the WebSphere Portal
Version 6.0 information center. If you change the themes and skins in the wps.ear file but fail to
redeploy the EAR as documented, your changes will not be migrated, and you will have to recreate
the changes on the migrated server after you complete the migration.

Related concepts:
“Delayed cleanup of deleted portal pages” on page 1630
Get an overview of the cleanup service for portal pages and their dependent resources.
Related tasks:
“Deregistering users and groups” on page 1999
IBM WebSphere Portal stores users and groups that exist in the user registry as entries in the database.
When using the XML configuration interface or the Manage User and Groups portlet to delete users and
groups, they are deleted from the user registry as well as from the database. Deleting a user or group
directly from the configured user registry does not remove the database entry. Also, WebSphere Portal
does not remove entries from its database when users or groups are muted in the user registry, for
example, users with too many wrong password attempts. You can manually remove the users and groups
from the database.
“Deleting orphaned data” on page 1632
You use the SLCheckerTool to delete orphaned data in the database.
“Managing user data” on page 2523
Managing user data involves running configuration tasks to update or extend your user registry after the
initial installation and deployment. Learn how to remove attributes that you need to update, add
database user registries, configure property extension (lookaside) databases, and perform various other
tasks to maintain your user registry.
“Configuring eTrust SiteMinder to perform authorization” on page 2690
You can configure Computer Associates eTrust SiteMinder to perform authorization independently from
configuring it to perform authentication. However, if you use eTrust SiteMinder to perform authorization
for IBM WebSphere Portal, you should also use it to perform authentication. Using eTrust SiteMinder to
perform only authorization is not supported at this time.
Deploying customized themes and skins (WebSphere Portal 6.0 information center)
Document 1248245
PK71398
i5 information center
WebSphere Portal Product Support
Preparing your new environment for migration

Prior to migration from WebSphere Portal Version 6.0.1.x, complete the steps outlined here to prepare the
new environment.
Check that you have access to an administrative user ID and password for both WebSphere Portal and
IBM WebSphere Application Server.
Note: If you are using a WMM-based configuration on the source server, either as a database repository
or a federated LDAP directory, no additional security enablement is required on the target server. The
migration process will migrate the WMM configuration to VMM automatically. When migrating a WMM
configuration, the administrator ID and password for WebSphere Application Server on the target server
must match the values used on the source server. This does not mean that the same security be
configured on both servers but only that the same adminstrator IDs and passwords must be set before
attempting the migration.
Migrating 1427
1. Install WebSphere Portal Version 7.0, then verify that you can stop and start the portal and log in to
the default welcome page.
Important: When installing the new portal, ensure that you use the Full installation option. Using the
Base installation option can cause the migration process to fail.
Note: If you are running IBM WebSphere Portal using IBM DB2 Universal Database for i V5R4, you
must apply the fix for APAR SE34114 to the operating system of the database server to ensure
successful migration. To download the fix, you can use either the Send PTF Order (SNDPTFORD)
command or the central site distribution process. For details, see the i information center.
2. Configure the target portal to use the same security as the earlier source portal:
a. If the source portal uses a standalone LDAP registry, enable a standalone LDAP registry on the
target portal and ensure that the target portal's registry uses the same users and groups (with the
same extid) as the source portal's registry.
b. If the source portal is configured to use an external security manager and has resources that are
under the control of the external security manager, configure the target portal to use that external
security manager. Alternatively, you can bring the externalized resources back under WebSphere
Portal control in the source portal environment prior to migration, and then configure the target
portal to use the external security manager after migration is complete.
Note: If the portal uses eTrust SiteMinder to perform authorization, verify that the
SiteMinderLoginModule custom property is defined because any XML Configuration Interface
execution can be affected. For instructions on modifying the SiteMinderLoginModule custom
property, see the topic on Configuring eTrust SiteMinder to perform authorization for WebSphere
Portal.
c. Ensure that the target portal uses the same WebSphere Application Server and WebSphere Portal
administrator user names and passwords for login as the source portal.
If you are using a stand-alone LDAP user registry, this happens automatically when you configure
security on the target portal.
If you are using a WMM-based user registry, you might need to take additional steps on the 7.0
server to ensure that the portal is configured to use the same login IDs as the 6.0 portal. The 7.0
installation program does not allow certain special characters and by default sets the WebSphere
Application Server and WebSphere Portal administrator user name and password to the same
values. If the 6.0 portal administrator user ID and password contain characters that cannot be used
in the 7.0 installation program or if the logon IDs for the portal administrator and WebSphere
Application Server administrator are different, you must update the 7.0 portal to use matching
values after you install and before you attempt to migrate. Refer to Updating user ID and passwords
for details.
3. Copy and activate required database library files as noted below.
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
For all supported operating systems except i:
Oracle: ojdbc14.jar

Note: (Oracle only): During the migration process, do not use Oracle JDBC driver version 11.2.0.2.0,
because the database migration fails. If you use driver version 11.2.0.2.0, the wrong meta data
information for columns created with datatype INTEGER is returned. As an alternative to driver
11.2.0.2.0, you can use driver version 11.2.0.1.0 during the migration process. Once you have migrated
your environment, you can change the driver version from 11.2.0.1.0 to 11.2.0.2.0
For i:
Depending on the driver that you are using, copy the required files into the AppServer_root/lib
directory. Then stop and restart the server1 and WebSphere_Portal servers to load the library files.
4. Make sure that the new portal's certificate for HTTP SSL communication matches the old server's
certificate. To do this, you can retrieve the appropriate CA certificate from the previous server. For
information about how to do this, refer to the topic about Retrieving signers using the retrieveSigners
utility at the client in the WebSphere Application Server information center.
5. If you plan to migrate any virtual portals that exist in the source portal, use the create-virtual-
portal ConfigEngine task to recreate each virtual portal with the corresponding name and URL
context in the target portal. For information on the create-virtual-portal task, see Virtual portals
reference.
6. If you plan to migrate remote portlets (portlets that are provided as WSRP services), ensure that the
WSRP Producer is available before you run the portal-post-upgrade task to import content to the new
portal.
7. Migration can take awhile and interruptions to your HTTP connection during the export process or
import process can cause migration to fail. To avoid this problem, change your HTTP server timeout
to an unlimited length while performing migration. Refer to your HTTP server documentation for
information on how to change the timeout value.
8. To ensure that timeouts do not occur during SOAP connections during the migration process, it is
recommended that you increase the SOAP timeout value as follows:
a. Log in to the WebSphere Application Server administrative console.
b. Click Servers > Applications servers > WebSphere_Portal > Server Infrastructure >
Administration > Administration Services > JMX Connectors > SOAPConnector > Custom
properties.
c. Select the requestTimeout property and increase the value from 600 to 6000.
d. Save the configuration changes, and then restart the server.
9. Back up the databases and the entire directory structure for the new portal server installation prior to
running the portal-post-upgrade task.
Migrating 1429
Related concepts:
“Using WSRP services” on page 2351
IBM WebSphere Portal supports the Web Services for Remote Portlets (WSRP) standard. By using this
standard, portals can provide portlets, applications, and content as WSRP services, and other portals can
integrate the WSRP services as remote portlets for their users.
Related tasks:
“Updating user ID and passwords” on page 1982
IBM WebSphere Portal and IBM WebSphere Application Server use some accounts from the registry (for
example, the LDAP server) including administrative and bind IDs for authenticated access to databases
and LDAP severs respectively, as well as the WebSphere Portal and WebSphere Application Server
administrative IDs. Often this means that the account passwords are stored in the WebSphere Portal and
WebSphere Application Server bootstraps configuration files, which allows the authentication process to
work.
“Managing user data” on page 2523
Managing user data involves running configuration tasks to update or extend your user registry after the
initial installation and deployment. Learn how to remove attributes that you need to update, add
database user registries, configure property extension (lookaside) databases, and perform various other
tasks to maintain your user registry.
“Configuring eTrust SiteMinder to perform authorization” on page 2690
You can configure Computer Associates eTrust SiteMinder to perform authorization independently from
configuring it to perform authentication. However, if you use eTrust SiteMinder to perform authorization
for IBM WebSphere Portal, you should also use it to perform authentication. Using eTrust SiteMinder to
perform only authorization is not supported at this time.
Related reference:
IBM i5 information center
Reusing V6.0.1.x JCR domain data

To migrate from IBM WebSphere Portal V6.0.1.x, you must connect to a copy of the earlier portal's JCR
database domain before running the migration tasks. The migration process uses the earlier portal data,
converting it for use with the new, target portal. Once the data is converted, it can no longer be used by
the earlier portal.
Important:
v If the new portal installation uses the same DBMS as the earlier portal, you must use the Type 4 Spec 4
version of the same database driver to connect to the copy of the earlier portal's JCR database domain.
For example, if you configured the new portal's release domain to use DB2 with a DB2 Type 4 driver,
and the earlier portal's JCR database domain also uses DB2, you must use a DB2 Type 4 Spec 4 driver
to connect to the copy of the earlier portal's JCR database domain. If the new portal uses Oracle for the
release domain and the earlier portal's JCR database domain uses a different DBMS such as DB2, you
do not need to use the same database driver to connect to the copy of the earlier portal's JCR domain.
v Database properties stored in wkplc_comp.properties on the earlier portal are located in
wkplc_dbdomain.properties and wkplc_dbtype.properties in WebSphere Portal Version 7.0. The entire
set of database properties specified on the new portal must be valid for the current configuration of all
database domains. If you plan to connect or transfer a single database domain, you should modify
only the database properties for that domain before running the connect-database or
database-transfer tasks.
v Set the DbSafeMode value to false in the wkplc_dbtype.properties before migrating to ensure the
database tables are modified as required by the migration process.
1. Create a separate copy of the earlier WebSphere Portal JCR domain.

2. On the new portal, locate and update the properties files listed below to reflect a connection to the
JCR domain copy that you created in the previous step:
a. Use the earlier portal installation's properties files as a reference to determine the appropriate
values for these files:
Note: The value of the parameter jcr.DbSchema in the wkplc_dbdomain.properties file must be
specified in uppercase (for example, jcr.DbSchema=JCR).
b. If the portal connects to DB2 for z/OS, check wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/
icm.properties for the value of the parameter jcr.zos.database.prefix. The value of
jcr.zos.database.prefix must be set to the correct prefix for the copies of the JCR databases that
are being migrated to WebSphere Portal Version 7.0. Consult your database administrator for the
correct value to specify. This value is typically the same as the value of jcr.ZosDbPrefix in
wkplc_dbdomain.properties after modifying the jcr and customization property value to share JCR
and Customization domain data.
3. Change to the wp_profile_root/ConfigEngine directory, and then enter the following command to
validate the configuration properties:
v Windows: ConfigEngine.bat validate-database -DTransferDomainList=jcr
v UNIX: ./ConfigEngine.sh validate-database -DTransferDomainList=jcr
v i: ConfigEngine.sh validate-database -DTransferDomainList=jcr
4. Stop the WebSphere_Portal server.
5. Connect WebSphere Portal Version 7.0 to the copy of the earlier JCR domain:
v Windows: ConfigEngine.bat connect-database-jcr-migration
v UNIX: ./ConfigEngine.sh connect-database-jcr-migration
v i: ConfigEngine.sh connect-database-jcr-migration
Note: The portal-post-upgrade task uses database catalog functions during execution. These catalog
functions need to be correctly bound to the database for the portal-post-upgrade task to work. Refer
to the documentation for your DBMS to determine how to do this.
6. Update the Web Content Manager tables by running the update-wcm-schema task:
Note: You only run this task when Web Content Manager is installed. If Web Content Manager is not
installed, skip this step.
v Windows: ConfigEngine.bat update-wcm-schema
v AIX Linux Solaris: ./ConfigEngine.sh update-wcm-schema
v i: ConfigEngine.sh update-wcm-schema
7. If the new portal installation is configured to use DB2 for Linux, UNIX, and Windows, DB2 for z/OS,
IBM DB2 for i, or Oracle, check wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties
for the value of the parameter jcr.database.schema and ensure that the value is specified in
uppercase (for example, jcr.DbSchema=JCR61).
Migrating 1431
Related tasks:
“Migrating V6.0.x personalization data” on page 1481
To migrate Personalization data from an IBM WebSphere Portal Version 6.0.x environment to a Version
7.0 environment, follow the procedures for Migrating Web Content Management Version 6.0. Running the
migration tasks for Web Content Management will migrate all Personalization data. You can also publish
portal content filtered by means of the Personalization engine and rules between WebSphere Portal
Version 6.0.x and Version 7.0 environments.
Sharing V6.0.1.x Customization domain data

When migrating from IBM WebSphere Portal V6.0.1.x, you share the Customization database domain
between the earlier portal installation and the new portal installation. To enable sharing, connect to the
Customization database domain in the earlier portal installation before you run the migration tasks.
Important:
v If the new portal installation uses the same DBMS as the earlier portal, you must use the Type 4 Spec 4
version of the same database driver to connect to the earlier portal's Customization database domain.
For example, if you configured the new portal's release domain to use DB2 with a DB2 Type 4 Spec 4
driver, and the earlier portal's Customization database domain also uses DB2, you must use a DB2
Type 4 Spec 4 driver to connect to the earlier portal's Customization database domain. If the new
portal uses Oracle for the release domain and the earlier portal's Customization database domain uses
a different DBMS such as DB2, you do not need to use the same database driver to connect to the
earlier portal's Customization domain.
v Database properties stored in wkplc_comp.properties on the earlier portal are located in
wkplc_dbdomain.properties and wkplc_dbtype.properties in WebSphere Portal Version 7.0. The entire
set of database properties specified in the wkplc_dbdomain.properties and wkplc_dbtype.properties
files on the new portal must be valid for the current configuration of all database domains. If you plan
to connect or transfer a single database domain, you should modify only the database properties for
that domain before running the connect-database or database-transfer tasks.
1. On the new portal, locate and update the files listed below to reflect a connection to the WebSphere
Portal Version 6.0.1.x customization domain.
Use the earlier portal installation's properties files as a reference to determine the appropriate values.
2. Change to the wp_profile_root/ConfigEngine directory, and then enter the following command to
validate the configuration properties:
v Windows: ConfigEngine.bat validate-database -DTransferDomainList=customization
v UNIX: ./ConfigEngine.sh validate-database -DTransferDomainList=customization
v i: ConfigEngine.sh validate-database -DTransferDomainList=customization
3. Stop the WebSphere_Portal server.
4. Connect WebSphere Portal Version 7.0 to the earlier customization domain:
v Windows: ConfigEngine.bat connect-database -DTransferDomainList=customization
v UNIX: ./ConfigEngine.sh connect-database -DTransferDomainList=customization
v i: ConfigEngine.sh connect-database -DTransferDomainList=customization
Preparing for composite application migration

Understand the following restrictions before you migrate composite applications:

v Templates for composite applications cannot be migrated using the migration tasks. However, you can
manually migrate application templates by using the template Export and Import tasks that are
available from the Application Template Library.
Follow the procedure for Deploying a template to another server to export template definition files from
the source portal server running WebSphere Portal Version 6.0.1.4 or later, and copy and import the
template definition files to the target portal server running the new version of WebSphere Portal.
v The backend data of business components is not migrated. Therefore, you must explicitly transfer
business component backend data as explained in the prerequisite checklist below.
Complete the following prerequisites before you migrate composite applications:

1. On the source WebSphere Portal server, enable scripting for composite applications:
a. Create the file PortalServer_root/shared/app/config/services/ScriptingService.properties and
add the following line:
ServerExt.applications=com.ibm.wps.scripting.server.ApplicationServerExtensions
b. In the file wp_profile_root/config/cells/cell/nodes/node/libraries.xml, locate the stanza for
WPSlib. It should look like the following:
<libraries:Library xmi:id="Library_1218796172015" name="WPSlib">
<classPath>${WPS_HOME}/shared/app</classPath>
<classPath>${WPS_HOME}/shared/app/scripting/wp.link.jar</classPath>
</libraries:Library>
Change it to look as follows:
<classPath>${WPS_HOME}/shared/app/scripting/ai.xml.api.script.jar</classPath>
<classPath>${WPS_HOME}/shared/app/scripting/ai.xml.impl.script.jar</classPath>
c. Specify the path of the scripts:
Windows: In the file PortalServer_root\bin\wpscript.bat, add the line:
set SCRPATH=%SCRIBS%\scripting\wp.script.jar;%SCRIBS%\scripting\wp.link.jar;
%SCRIBS%\wp.base.jar; %SCRIBS%\wp.model.api.jar;
%SCRIBS%\wp.user.api.jar;%SCRIBS%\wp.cmd.base.jar;%
UNIX: In the file PortalServer_root/bin/wpscript.sh, add the line:
set SCRPATH=%SCRIBS%/scripting/wp.script.jar;%SCRIBS%/scripting/wp.link.jar;
%SCRIBS%/wp.base.jar; %SCRIBS%/wp.model.api.jar;
%SCRIBS%/wp.user.api.jar;%SCRIBS%/wp.cmd.base.jar;%
2. On the source WebSphere Portal server, check the settings in the file PortalServer_root/config/
wpconfig.properties:
a. Make sure that the passwords are set for WasPassword and PortalAdminPwd.
Important: If the WasUserid is different from the PortalAdminId, you must add the WasUserid to the
portal administrator group wpsadmins. An interim fix will be available soon to correct a problem
with Portal Login to the scripts that support the composite application migration tasks. Until the
interim fix is available, if you do not add WasUserid to the portal administrator group wpsadmins,
the migration tasks for composite applications will not work properly.
b. Find the SOAP port number. You will need to know the SOAP port number for Step 4b.
3. Restart the source WebSphere Portal server.
4. At least once before you migrate composite applications, run the wsadmin tool with the option to
establish a SOAP connection from the new, target WebSphere Portal server to the source WebSphere
Portal server. The IBM WebSphere Application Server administration scripting tool must work and a
SOAP connection must be established between the portal servers to update SSL trust store because the
migration task migrate-ai-export uses the Portal Scripting Interface commands for the backing up
and restoring composite applications. The Portal Scripting Interface is based on the wsadmin tool.
Migrating 1433
a. On the new WebSphere Portal server, open a command prompt and change to the directory
AppServer_root/bin/.
b. Type the following command:
wsadmin -host portalversion6014_hostname -conntype SOAP -port
portalversion6014_SOAPport_number -user was_userid -password was_password
Note: The wsadmin tool might display a warning about a version mismatch between the two
servers. This warning does not affect the operation of the tool and can be disregarded.
c. Review the SSL Signer Exchange Prompt information that is displayed in the console and verify
that the digest value matches what is displayed at the server:
Subject DN
Issuer DN
Serial Number
Expires
SHA-1 Digest
MD5 Digest
d. At the prompt Add signer to the trust store now?, type Y. Confirmation is displayed as
Connected to process WebSphere Portal on node portalversion6014_host_node_name using SOAP
connector.
e. After you receive confirmation that the SOAP connection is established between the portal servers,
at the wsadmin prompt, type exit.
5. Before you run either task, portal-pre-upgrade or migrate-ai-export, make sure that the source
WebSphere Portal server is running and that the file PortalServer_root/config/wpconfig.properties
specifies the values for the properties WasPassword and PortalAdminPwd.
6. Before you run either task, portal-post-upgrade or migrate-ai-import, make sure that the target
WebSphere Portal Version 7.0 server is running and that the file wp_profile_root/ConfigEngine/
properties/wkplc.properties specifies the values for the properties WasPassword and PortalAdminPwd.
7. Ensure that all portlet applications that are rendered on the pages of composite applications in the
source environment are installed on or migrated to the new WebSphere Portal environment before
you migrate the composite applications. If the target environment does not already have available the
portlets used by the composite applications, the migration of the composite applications will fail.
v Although the core portal migration tasks automatically migrate portlet applications, as explained in
Understanding migration, you will want to verify that all portlet applications needed by migrated
composite applications are available.
v Also refer to the topic Migrating deprecated portlets to confirm whether the composite applications
that you intend to migrate contain portlets that are removed in WebSphere Portal Version 7.0. This
topic explains how deprecated portlets are handled for transition after migration.
8. Ensure that you have explicitly transferred the backend data of the business components of composite
applications. The migration tasks for composite applications will not migrate the backend data of
business components, for example, the contents of a Web Content Manager document library.
v If the business components of an application store data in the WebSphere Portal Community
database domain, then consider using the XML Configuration Interface to transfer the backend data
from the source environment to the target environment. For example, in the case of Web Content
Manager document libraries, you might want to copy the entire WebSphere Portal Version 6.0x Java
Content Repository (JCR) to the WebSphere Portal Version 7.0 environment or configure the
WebSphere Portal Version 7.0 environment to use the Version 6.0x JCR.
v If application business components store data in repositories that are external to the WebSphere
Portal configuration, you cannot use the XML Configuration Interface and will need to use another
method of explicitly migrating application component data.
Now you are ready to run the migration tasks for composite applications.

Document migration
As of version 6.1, Document Manager is no longer available in WebSphere Portal. Before migrating your
data, you will need to replace web content previously stored as documents in a document library with
either file resource components or file resource elements stored in authoring templates, content items or
site areas.
Saving your documents as file resource elements and components
To save your documents as file resource elements or components you:

1. identify which documents need to be saved as file resource elements or components by installing and
running the document list portlet on your version 6.0 server.
2. open your document library on your version 6.0 server and save your documents to a temporary
directory.
3. create file resource elements and components on your version 6.0 server and upload your documents
from the temporary directory.
Installing the document list portlet
Before migrating documents you must install the document list portlet on your version 6.0 server. The
document list portlet is used to identify your document manager elements and components, and what
items reference your document manager elements and components. This will assist you to convert your
documents to file resource elements and components.
1. Login to WebSphere Portal as an administrator.
2. Go to the Administration view and then Portlet Management.
3. Select Web Modules.
4. Click Install.
5. Click Browse.
6. Select the file called ilwwcm-pdmdoclist.war from the PortalServer_root\wcm\prereq.wcm\
installableApps folder of your version 7.0 server.
7. Click Open.
8. Click Next.
9. Click Finish.
Using the document list portlet

1. Create a new portal page and add the document list portlet to the page.
2. Select a library to analyze.
3. Select an analysis type:
Document Manager components
Select this option to display a list of Document Manager components in the selected library. A
list of items that reference each Document Manager component are also listed. You will need
to replace each Document Manager component with a file resource component, and replace
each reference to the Document Manager component with a reference to the new file resource
component.
Document Manager elements
Select this option to display a list of sites, site areas, content items and authoring templates
that contain a Document Manager element in the selected library. You will need to replace
each Document Manager element with a file resource element. This option may take longer to
run than the options as it will search every site, site area, content item and authoring template
in the selected library.
Document Manager tags
Select this option to display a list of presentation templates and components that contain a
Migrating 1435
Document Manager element tag. You will need to replace each Document Manager element
tag with an element tag pointing to the file resource elements you created when using the
"Document Manager elements" option.
Document replacement strategies
There are three ways to replace the use of Document Manager documents:
As a file resource component
The simplest way to replace Document Manager documents is by importing them into file
resource components. The strategy is suitable if you only need to display a basic set of file
attributes, or to create a downloadable link to a file.
As a file resource element stored in a site area or content item
The benefit of this strategy is that you can add elements to an item to store additional metadata
not available in a file resource component. Downloadable links can only be used when displaying
content from a site area or content item. You cannot create a download link directly to the file
resource element.
As a file resource component referenced in a site area or content item using a component reference
element
This strategy combines elements of the first two strategies. Additional metadata can be stored in
a site area or content item, and downloadable links can be used both when displaying content
from a site area or content item, and by linking directly to the file resource component.
Storing images:
In some cases, where you don't want users to be able to download an image file but only want to render
an image on a page, you could store the image in an image component or image element instead of using
a file resource component or element.
Creating a download link to a file resource component
If you store a document in a file resource component, you use a component tag to create a download
link:
<a href="<component name="FileResource" />">Link Text</a>
This code can be referenced in any presentation template, component design or element design.
Creating a download link to a file resource element
If you store a document in a file resource element, you use an element tag to create a download link. For
example, to create a link to a file resource element stored in a content item:
<a href="<element type="content" context="current" key="FileResource" />">Link Text</a>
This link will only be displayed when the currently displayed content item contains a file resource
element named "FileResource".
Displaying the attributes of file resource components and elements
Previously it was possible to display a range of attributes of documents stored in document libraries
when displayed within web pages. When you migrate your documents to file resource components or
elements not all attributes will be available. You will need to create your own attribute fields in an
authoring template, content item, site area to replace the document attributes:

Table 389. Attributes
File resource element stored in a site
area, authoring template or content
Document attribute File resource component item
authors Add authors to the author field in Add authors to the author field in
the file resource element. Use a the authoring template, content item,
Property tag to render the authors. or site area. Use a Property tag to
render the authors.
categories Not available. You will need to create a taxonomy
to replace the categories used by
your old document library. You then
enable profiling and then assign a
category to the site area or content
item that the file resource element is
stored in.
Use a Property tag to render the

profile of the content item or site
area.
created Use a historycmpnt tag to render the Use a historycmpnt tag to render the
creation date of the file resource creation date of the content item or
component. site area.
creators Use a historycmpnt tag to render the Use a historycmpnt tag to render the
creator of the file resource creator of the content item or site
component. area.
data Not available. Not available.
You can use an element, such as a

text element, to store this information
and then use an element tag to
display this information.
dataLength Not available. Not available.

dataMimeType Not available. Not available.

description Enter text in the description field of Enter text in the description field of
the file resource element. Use a the authoring template, content item
Property tag to render the or site area. Use a Property tag to
description. render the description.
drafts Not available. Not available.

Migrating 1437
Table 389. Attributes (continued)
effectiveDate Not available. Not available.

hidden Not available. Not available.

id Use a Property tag to render the ID Use a Property tag to render the ID
of the file resource component. of the content item or site area.
isdoc Not available. Not available.

label Not available. Not available.

language Not available. Not available.

lastModified Use a historycmpnt tag to render the Use a historycmpnt tag to render the
last modified date of the file resource last modified date of the content item
component. or site area.
lastModifier Use a historycmpnt tag to render the Use a historycmpnt tag to render the
last modifier of the file resource last modifier of the content item or
component. site area.
mimeType Use a component tag to display the Use an element tag to display the
mime type of the file. mime type of the file.
owners Add owners to the owners field in Add owners to the owners field in
the file resource element. Use a the authoring template, content item
Property tag to render the owners. or site area. Use a Property tag to
render the owners.
path Use a pathcmpnt tag to render the Use a pathcmpnt tag to render the
path to the file resource component. path to the content item or site area.
permission Not available. Not available.


Table 389. Attributes (continued)
proxy Not available. Not available.

renditions Not available. Not available.

revision Not available. Not available.

searchable Not available. Not available.

size Use a component tag to display the Use an element tag to display the
size of the file. size of the file.
systemCreated Not available. Not available.

systemLastModified Not available. Not available.

title Enter text in the title field of the file Enter text in the title field of the
resource element. Use a Property tag authoring template, content item or
to render the title. site area. Use a Property tag to
render the title.
Displaying the content of file resource components and elements
File resource elements and components cannot be dynamically converted to HTML and displayed on a
web page. The following strategies can be used to display the contents of a document as HTML:
Convert your document to HTML and store it as an HTML component
1. Go to the document library on your 6.0 server and save your document to your file system.
2. Open the file and convert it to HTML. For example, if you are converting a Microsoft Word
file, open it in Microsoft Word and save it as HTML.
Migrating 1439
3. Create a new HTML component on your 6.1 server and import the HTML you created in step
2 using the Import button in the HTML component.
4. Use a component tag to reference the HTML component in any presentation template,
component design or element design. For example:
<component name="ComponentName" />
Images in your HTML:
If your HTML contains images you will need to import your images into your HTML component
separately using the button. Alternatively, you could use a Rich Text component instead of
an HTML component and the images will automatically be imported when you import your
HTML.
Convert your document to HTML and store it as an HTML element
1. Go to the document library on your 6.0 server and save your document to your file system.
2. Open the file and convert it to HTML. For example, if you are converting a Microsoft Word
file, open it in Microsoft Word and save it as HTML.
3. Create a new HTML element in a site area or content item on your 6.1 server and import the
HTML you created in step 2 using the Import button in the HTML element.
4. Use an element tag to reference the HTML element in any presentation template, component
design or element design. For example:
<element type="content" context="current" key="ElementName" />
Images in your HTML:
If your HTML contains images you will need to import your images into your HTML element
separately using the button. Alternatively, you could use a Rich Text element instead of an
HTML element and the images will automatically be imported when you import your HTML.
Use a third-party application to dynamically convert a file to HTML
Use code stored in a JSP component to call a third-party application that can dynamically convert
the file to HTML before rendering on a page. In this case you would reference your file resource
element or component in some JSP and use the third-party application to convert the file resource
to HTML before it is rendered.
Post migration alternative
You can also use the document list portlet on your 7.0 server. This allows you to migrate your data first,
and then retrospectively replace your documents on your new server. When migrated:
v Documents stored in document libraries in previous versions of WebSphere Portal will not be migrated.
v Document Manager elements and components are migrated unchanged, but you can no longer select
or replace documents.
v Web content tags that reference Document Manager elements or components are left unchanged in
presentation templates and element designs. When rendered on a web page, a message will be
displayed showing the basic information of the document previously referenced.
Preparing to migrate Web content

If you plan to migrate Web content from V6.0.1.x, complete the tasks described here before you begin
migration.
1. To reduce the load on the database during migration and syndication, it is recommended that you
disable JCR text search indexing on the WebSphere Portal Version 7.0 server before migration.

Edit wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties and set
jcr.textsearch.enabled to false. After the file is updated, restart your server for the changes to take
effect.
Note: It may take some time to rebuild the indexes when you re-enable JCR text search indexing after
migration.
2. Update the expire.blankdate.immediately property in the WCM WCMConfigService service.
In Version 6.0, items that had no expire date specified would never expire. In Version 7.0, items with
no expire date expire as soon as an expire action is triggered. If you do not configure the Version 7.0
server to use the earlier expiration behavior, all your published content may be expired when
migrated. To start using the new behavior, you can change this setting back to true after completing
migration.
a. Log in to the IBM WebSphere Application Server administration console on your Version 7.0
server.
b. Click Resources > Resource Environment > Resource Environment Providers.
c. Edit the WCM WCMConfigService service and ensure that the expire.blankdate.immediately
property is set to false.
3. On the source portal server, remove locks on all Web content items:
a. Go to the Administration view.
b. Go to Portal Content > Web Content Libraries.
c. Click View Locked Items.
d. Select all items and then click Unlock.
Related tasks:
“Setting service configuration properties” on page 1634
portals need to address. Services are available for both WebSphere Portal and IBM Web Content Manager.
You can configure some of these services.
Migrating Version 6.0.1.x customized resources

Some migration steps are optional depending on what customized resources you had in your previous
version of IBM WebSphere Portal. You only need to migrate those resources that are relevant to your
environment.
Choose the following relevant customized resources to migrate:

v Migrate customized themes and skins if you want to use new functionality with them.
v Recreate your global settings and portal service configuration.
v Migrate portlets you created using one of the following methods:
– Copy the .war files into the PortalServer_root/installableApps directory
– For predeployed portlets, install the applications to the WebSphere Application Server system and
then register them with WebSphere Portal.
Important: When choosing this method, do not copy the .war files into the PortalServer_root/
installableApps directory.
Migrating themes
When migrating themes that were developed in an earlier version, you need to be aware of general
guidelines, differences, and known issues.
With version 7.0, custom themes and skins that are present in the wps.ear file on the source server prior
to migration are consolidated in the MigratedThemes.ear file on the target server after migration. This not
Migrating 1441
only makes maintenance more straightforward, but it also provides you with an easier way of verifying
and updating your themes for the migrated environment without impacting other parts of the portal. By
starting with MigratedThemes.ear and modifying the themes and skins, you can then deploy the new
EAR and make the updated themes and skins available to the portal.
When migrating your themes, be aware of the following considerations:

v Migrated themes should be applied to the same pages that they were designed for in the earlier
version.
v Migrated themes should be used with the same skins as in the earlier version. Some skins in the
current version take advantage of functions that were not available in the earlier version.
v To ensure that the person tag works as expected, customized themes must be migrated to include
Semantic Tag Service. When you migrate customized themes, make sure that the current theme's
header file (usually either head.jspf or head_externalJS.jspf) includes the following line at the end,
just before </head>:
<script type="text/javascript"
src="/wps_semanticTag/javascript/semanticTagService.js
?language=<%= userLocale %>" ></script>
After updating the JSPF file, enter the following command to make the changes effective:
touch Default.jsp
As an alternative, you can edit (open and save) Default.jsp.

v If you created themes with a left navigation menu in a previous version, these themes will not work in
the current version because they do not have the plus (+) sign next to the page to expand the node. To
ensure that such themes function correctly, you must change the value of
navigation.expansion.defaultstate to true in WP ConfigService provider. For more information, see
Setting service configuration properties.
v If you migrate a portal page from V6.0.1.x to V7.0 and the migrated page includes a V6.0.1.x icon for
its page label, the icon for the page label might not render in the target environment as a result of
changes to handling of page metadata starting in V6.1:
– When page metadata is retrieved, if the parameter resides in the page but has no assigned value, an
empty string is returned instead of a null value.
– When labels or pages are created, the pageIcon metadata parameter is not included by default;
instead, it is included only if a value is set.
Because of these changes, migrated themes may require additional adjustment to check for an empty
string in addition to a null value. In the sample snippet below, the code that checks for an empty string
looks like this:
if(pageIcon != null && !pageIcon.toString().equals(""))
<portal-navigation:navigation startLevel="${themePolicy.rootNavigationStartLevel}"
stopLevel="${themePolicy.rootNavigationStopLevel}">
<portal-navigation:navigationLoop>
if (wpsNavNode instanceof com.ibm.portal.MetaDataProvider) {
com.ibm.portal.MetaData iMetaData = ((com.ibm.portal.MetaDataProvider) wpsNavNode).getMetaData();
...
//theme relative path to page icon is stored in page metadata
Object pageIcon = iMetaData.getValue("com.ibm.portal.PageIcon");
if(pageIcon != null && !pageIcon.toString().equals("")){%>
<c:set var="pageIconUrl" >
<portal-logic:urlFindInTheme file=’<%=pageIcon.toString()%>’ />
</c:set>
<%}else{%>
<c:set var="pageIconUrl" >
</c:set>
<%}
}
...
</portal-navigation:navigationLoop>
</portal-navigation:navigation>

v In WebSphere Portal Version 7.0, the V7.0 Portal theme must be used with the administrative portlets.
The administration page is marked with the unique name wps.administration, and pages under this
node are set to the V7.0 Portal theme.
When you migrate from an earlier version of WebSphere Portal, the old Administration pages are never
migrated forward. Virtual portals are treated differently, however, and their administration pages are
migrated. If the virtual portal's administration pages are under the wps.administration node,
WebSphere Portal migration automatically sets these pages to the V7.0 Portal theme. However, if the
virtual portal's administration pages are not under the wps.administration node, migration does not
set them to the V7.0 Portal theme. You must do this manually by using the XML configuration
interface. For example:
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
type="update" xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd">
<portal action="locate">
<skin action="locate" domain="rel" objectid="ibm.portal.skin.IBM"
uniquename="ibm.portal.skin.IBM"/>
<skin action="locate" domain="rel" objectid="wps.skin.noSkin"
uniquename="wps.skin.noSkin"/>
<theme action="locate" domain="rel" objectid="ibm.portal.theme.Portal"
uniquename="ibm.portal.theme.Portal"/>
<content-node action="update" active="true" domain="rel"
objectid="wps.Administration" themeref="ibm.portal.theme.Portal"
type="label" uniquename="<Your admin page unique name>"/>
</portal>
</request>
For more information, see the XML configuration reference topic.

v Migration does not upgrade themes from an earlier version to use new functionality that has been
introduced in more recent versions of the product.
Important: Changes that you make to migrated themes in the local file system are not automatically
applied to the portal's master configuration. The preferred way to update themes is to extract and expand
the MigratedThemes.ear file, make the required updates, and then repackage and redeploy the updated
EAR file. For an example of how this is done, refer to the Updating custom themes and skins to remove
hardcoded context root references topic.
Migrating 1443
Related tasks:
“Updating custom themes and skins to remove hardcoded context root references” on page 1495
If you have developed custom themes or skins that contain hardcoded references to the portal's context
root, this can cause problems if the context root is changed. This is particularly an issue after migration
because the context root is modified during migration, causing hardcoded references to break. Rather
than modifying your custom themes and skins manually each time you change the context root, you can
update your themes and skins to remove the hardcoded references and instead use dynamic references
that work properly regardless of the context root.
Related reference:
“XML configuration reference” on page 1894
Learn more about XML input structure, XML tags for portal resources, attributes for special purposes
such as localdata, objectid, and more. Also find information about action attributes that determine the
type of processing to be applied to the portal resource. There are syntax restrictions that should be
considered as well as information about how to determine the objectids for portal resources.
“Implementing a single level of navigation” on page 2856
View the basic steps to build a single layer of navigation using the portal JSP tags.
Migrating portlets built with Struts Portlet Framework

IBM WebSphere Portal Version 7.0 comes with Struts Portlet Framework (based on Struts 1.1), which
enables applications based on Struts 1.1 to run in the portal environment. Struts portlet applications that
use earlier versions of the Struts Portlet Framework can be migrated to the current version of WebSphere
Portal by updating the Struts Portlet Framework JAR files, TLDs, and
org.apache.commons.logging.LogFactory file. The Struts Portlet Framework version that an application
uses determines whether additional steps are required for migration.
The following Struts Portlet Framework versions have been released either in a WebSphere Portal release
or in the catalog:
v WebSphere Portal Version 7.0
– Struts Portlet Framework version: SPF 6.1
– Struts release: Struts 1.1
– Supports Struts 2.0
– Supports Struts 2.0
v WebSphere Portal Version 5.1.x
– Struts Portlet Framework version: SPF 5.1.x
v WebSphere Portal Version 5.0.x
– Struts Portlet Framework version: SPF 5.0.x
v Catalog version 5.1.0.1

– Struts Portlet Framework version: SPF 5.1.0.1
v Catalog version 5.0.3
– Struts Portlet Framework version: SPF 5.0.3
To deploy applications that package the Struts Portlet Frameworks 5.1.x, 5.0.x, or 6.0 on the current
version of WebSphere Portal, the portlet developer must migrate to the current version of the Struts
Portlet Framework (SPF 6.1).
To locate the version information for a given Struts application WAR file, inspect the contents of the
PortalStruts.jar (IBM legacy container) or wp.struts.standard.framework.jar (standard container) in
the WEB-INF/lib directory of the WAR file. The JAR file contains a version.properties file and a
version.txt file or both. If neither of these files can be found, the manifest file might contain the
necessary information.
For WebSphere Portal versions prior to 5.1, the version.txt file in the dev/struts directory provides the
version of the Struts Portlet Framework and the version of Apache Struts that is integrated in the
package. Each WAR file in the dev/struts/StrutsPortlet directory also contains the version file in the
PortalStruts.jar. The sample applications also contain the version.txt file within the PortalStruts.jar
inside the WEB-INF/lib directory of each WAR file.
If you are working with the Struts Portlet Framework from the Workplace Solutions Catalog, the version
file is in the base directory of the catalog ZIP file and also in the PortalStruts.jar or
wp.struts.standard.framework.jar located in the WEB-INF/lib directory of the sample WAR files.
Migrate portlets from earlier versions of the Struts Portlet Framework to the current version by
completing the following steps. Additional files that you need to complete the migration can be obtained
from the Struts sample portlets that are available from the IBM Lotus and WebSphere Portal Business
Solutions Catalog. For example, you can download the SPFStandardStockQuote.war portlet sample and use
that as the template application for your migration.
1. Copy the META-INF/services/org.apache.commons.logging.LogFactory file from the template
application and add it to your Struts application. Overwrite this file if it already exists.
2. Copy the files listed below from the template application to the WEB-INF/lib directory of the Struts
application that you are migrating. Overwrite the JAR files if they already exist.
v commons-beanutils.jar
v commons-collections.jar
v commons-digester.jar
v commons-fileupload.jar
v commons-lang.jar
v commons-validator.jar
v jakarta-oro.jar
v PortalStruts.jar (IBM legacy container) or wp.struts.standard.framework.jar (standard
container)
v PortalStrutsCommon.jar
v PortalStrutsTags.jar
v struts.jar
v struts-legacy.jar
v StrutsUpdateForPortal.jar
v wp.struts-commons-logging.jar
v wp.struts.tlds.common.jar
Migrating 1445
3. The following files are no longer part of the Struts packaging. Remove the files from the WEB-INF/lib
directory, if they exist.
v commons-dpcp.jar
v commons-logging.jar
v commons-pool.jar
v commons-resources.jar
v commons-services.jar
v jdbc2_0-stdext.jar
4. Remove the following Struts TLD files. Check the tag location in the Web deployment descriptor to
verify the location of the TLD files.
Note: Do not remove the app.tld file.

v struts-bean.tld
v struts-chtml.tld
v struts-html.tld
v struts-logic.tld
v struts-nested.tld
v struts-portal-html.tld
v struts-portal-wml.tld
v struts-template.tld
v struts-tiles.tld
v struts-wml.tld
5. Modify the application JSP files to use the following tag library URI convention:
Note: Do not modify <%@ taglib uri="/WEB-INF/app.tld" prefix="app" >.

v http://struts.apache.org/tags-bean
v http://struts.apache.org/tags-chtml
v http://struts.apache.org/tags-html
v http://struts.apache.org/tags-logic
v http://struts.apache.org/tags-nested
v http://portal/struts/tags-html-1.0
v http://portal/struts/tags-wml-1.0
v http://struts.apache.org/tags-template
v http://struts.apache.org/tags-tiles
v http://struts.apache.org/tags-wml-1.0
For example, in the JSP original source:
<%@ taglib uri="/WEB-INF/tld/struts-logic.tld" prefix="logic" %>
<logic:forward name="welcome"/>
Would be converted to:
<%@ taglib uri="http://struts.apache.org/tags-logic" prefix="logic" %>
<logic:forward name="welcome"/>
6. Remove the Struts tag library descriptors from the web deployment descriptor.
Note: Do not remove the following tag library:

<taglib>
<taglib-uri>/WEB-INF/app.tld</taglib-uri>
<taglib-location>/WEB-INF/app.tld</taglib-location>
</taglib>

7. Remove the following lines from the portlet.xml file:
Note: In your existing Struts portlet, check the portlet deployment descriptor to see if the Struts filter
chain is specified. In general, the Struts filter chain is not required unless the application uses static or
XML IViewCommands or the URL rewriting feature of static content. Struts Portlet Framework
releases earlier than V5.1 used transcoding to apply stylesheets to XML documents, but versions
5.1.0.1 and later offer an alternative that does not require transcoding. See the
SPFStandardTransformation sample for more details.
<config-param>
<param-name>FilterChain</param-name>
<param-value>StrutsTranscoding</param-value>
</config-param>
8. Remove the ForwardAction class, located in the WEB-INF/classes/org/apache/struts/actions
directory, if it exists.
Notes:
a. Struts V1.1 changed the name of SubApplications to Modules after the Beta 2 release. This change
lead to the renaming of the ApplicationConfig class to ModuleConfig. Some tags and actions
might use ModuleConfig to determine the current module prefix. Use the Struts application code
to see if the ApplicationConfig object has been used and should be migrated to use the
ModuleConfig object instead. The method of obtaining the ModuleConfig object from the request
object has changed. Here is an example of the new implementation: ModuleConfig config =
(ModuleConfig) pageContext.getRequest().getAttribute
(org.apache.struts.Globals.MODULE_KEY);
b. The SubApplicationSearchPath configuration parameter has been renamed to ModuleSearchPath.
For the Struts Portlet Framework to be consistent with Struts V1.1, a new initialization parameter,
ModuleSearchPath, has been added. This parameter allows for customization in which client
attributes are used for determining a module. The typical example would be ModuleSearchPath of
"mode," which would use the portlet's mode to determine the module. The
SubApplicationSearchPath initialization parameter will continue to be supported, but will
eventually be deprecated. If both the SubApplicationSearchPath and ModuleSearchPath
parameters are specified as initialization parameters, the ModuleSearchPath value is used.
c. The SubApplicationContext class has been renamed to ModuleContext. The Struts Portlet
Framework will deprecate the SubApplicationContext class and introduce the ModuleContext class
to be consistent with the Struts V1.1 name change of SubApplication to Module. The
ModuleContext object is obtained from the ExecutionContext object that is passed into those
classes that implement the IViewCommand interface. The ModuleContext is used to store
ViewCommandsFactories. The view command factories are implemented per module.
9. Use the following steps to migrate IBM legacy container Struts portlets to the standard container:
Note: If the portlet you want to migrate is not based upon Struts Portlet Framework V6.1, migrate it
to this level prior to migrating it to the standard container. The migration from the legacy version of
the Struts Portlet Framework to the standard container starts with updating files shipped with the
SPFStandardBlank.war file.
a. Copy the META-INF/services/org.apache.commons.logging.LogFactory file from the template
application and update the file in the application.
b. Copy the following JAR files from the template application to the WEB-INF/lib directory of the
Struts application you are migrating:
Note: Overwrite the JAR files if they already exist.

v commons-beanutils.jar
v commons-collections.jar
v commons-digester.jar
v commons-fileupload.jar
Migrating 1447
v commons-lang.jar
v commons-validator.jar
v jakarta-oro.jar
v PortalStrutsCommon.jar
v PortalStrutsTags.jar
v struts.jar
v struts-legacy.jar
v StrutsUpdateForPortal.jar
v wp.struts-commons-logging.jar
v wp.struts.standard.framework.jar
v wp.struts.tlds.common.jar
c. Delete the PortalStruts.jar file. It is only required on the IBM legacy container.
d. The standard container requires a Web deployment descriptor because the application is packaged
as a WAR file. However, most of the initialization parameters are now configured through the
portlet deployment descriptor. Use the following steps to modify the Web deployment descriptor:
1) Remove the servlet class from the Web deployment descriptor. The servlet class is no longer
the way to specify the portlet class for the application in the standard container. The portlet is
now specified as the portlet class in the portlet deployment descriptor.
2) Move the initialization parameters from the Web deployment descriptor to the portlet
deployment descriptor. Because the portlet class is now defined in the portlet deployment
descriptor, the initialization parameters are also specified in the portlet deployment descriptor.
Note, the initialization parameters are specified as name and value in the portlet deployment
descriptor, not param-name and param-value as they are named in the Web deployment
descriptor.
3) The <taglib> elements still remain in the Web deployment descriptor, and no changes are
required.
4) The welcome file elements still remain in the Web deployment descriptor, and no changes are
required.
e. The definition for the portlet deployment descriptor for the standard container is different than the
legacy container. Some changes are required for the migrated example to deploy in the standard
container. Use the following steps to modify the portlet deployment descriptor:
1) Ths standard container introduces the <portlet-class> element for specifying the class of the
portlet. The portlet class for the Struts Portlet Framework is
com.ibm.portal.struts.portlet.StrutsPortlet.
2) The initialization parameters for the portlet are defined in the portlet deployment descriptor.
The initialization parameters should be migrated from the Web deployment descriptor.
3) The standard container does not have the abstract and concrete separation in the portlet
deployment descriptor. The portlet element defines the supported modes and portlet
preferences.
f. Modify the Struts configuration file. The Struts Portlet Framework defines the request processor
that must be configured in the Struts configuration file. The controller attribute processClass must
be migrated to the following value to be deployed on the standard container:
<controller processorClass="com.ibm.portal.struts.portlet.WpRequestProcessor">
If the Struts application is using the Struts request processor that supports tiles, the Struts plugin
needs to be migrated:
<plug-in className="com.ibm.portal.struts.plugins.WpTilesPlugin">
g. Migrate dependencies on the portal container. The application must replace the
org.apache.jetspeed interfaces with the equivalent javax.portlet interfaces.
h. Many applications use the PortletApiUtils to obtain the portlet request and interface directly with
the portlet API. Verify that the PortletApiUtils object is obtained as follows:

com.ibm.portal.struts.common.PortletApiUtils portletUtils =
com.ibm.portal.struts.common.PortletApiUtils.getUtilsInstance();
i. Migrate any application customizations to the standard container.
StrutsPortlet
The com.ibm.wps.portlets.struts.WpsStrutsPortlet class for the legacy container extended
the PortletAdapter class. The Struts application using the Struts Portlet Framework might
have been customized by extending the WpsStrutsPortlet class. If so, those changes must be
migrated for the Sstandard container. The com.ibm.portal.struts.portlet.StrutsPortlet class
for the standard container extends the standard container's GenericPortlet.
Request processor
The com.ibm.wps.portlets.struts.WpsRequestProcessor class for the legacy container might
have been extended to customize the processing. The Request Processor class for the
standard container is com.ibm.portal.struts.portlet.WpRequestProcessor. If the legacy
interfaces were used for the customizations, these changes must be migrated to the
standard interfaces.
IBM Lotus and WebSphere Portal Business Solutions Catalog
Migrating search components

Migrating the search components in your portal might require preparation steps on the source portal and
then additional steps on the migrated portal.
Migrating portal search collections:
When you migrate or upgrade IBM WebSphere Portal to a later version, the data storage format and
index structure of Portal Search is not backward compatible between the different versions. If you
migrate your portal to a later version and want to continue using your search collections, you need to
preserve them before you migrate your portal and import them into the upgraded portal after the
migration.
This applies to migrating between versions of WebSphere Portal. Migrating your search collections might
also be required when you install an interim fix. Refer to the instructions in the ReadMe file provided
with the interim fix.
Notes:
1. If you do not want to migrate your search collections, the migration process deletes them
automatically and creates new search collections. Content is indexed in the next scheduled crawl after
migration is complete.
2. Exporting and importing portal site search collections into portal Version 7.0 is not supported.
Search collections that were created in Version 6.0.1.x require manual migration; use the Import or Export
Collection option of the Manage Search portlet to export and import the search collections as described
below. For more details about these tasks and the Manage Search portlet, see the portlet help.
To migrate your search collections, proceed by the following steps:

1. Before you migrate your portal to a later version, export your search collections. This step exports the
configuration data and all document URLs of your search collections.
Notes:
a. Before you export a collection, make sure that the portal application process has write access to
the target directory location. Otherwise you might get an error message, such as File not found.
b. When you specify the target directory location for the export, be aware that the export overwrites
files in that directory.
Migrating 1449
2. For each collection, document the following data:
v The target file names and directory locations to which you export the collection.
v Location, name, description, and language.
v Settings for the Specify collection language and Remove common words from queries options.
3. Delete the search collections from your existing portal. Otherwise they can be corrupted by the import
step that follows later. If you are upgrading from one portal version to another, you do not need to
delete the search collections, as the new collections are stored under a different directory path
location.
4. Upgrade your WebSphere Portal as required.
5. Create empty search collections that you can use later to hold the imported collections. Fill in the
following fields and select the following options according to the information that you documented in
step 2 above:
Location of Collection
The location can match the old setting, but does not have to match it.
Name of Collection
The name can match the old setting, but does not have to match it.
Description of Collection
The description can match the old setting, but does not have to match it.
Specify Collection Language
Select this to match the old setting as documented in step 2.
Select Categorizer
The value is overwritten by the import process.
Select Summarizer
Remove common words from queries (for example. in, of, on, etc.)
Check or clear this setting to match the old setting as documented in step 2.
You do not have to add content sources or documents, as that is completed by the import process.
6. Check that the target search collections that you created in step 5 are empty. Do not import collection
data into a target collection that already contains sources or documents.
7. Import the search collection data into the portal. For the import source information, use your
documented file names and directory locations to which you exported the collections before the portal
upgrade.
When you import a collection, a background process fetches, crawls, and indexes all documents which
are listed by URL in the previously exported file. Keep in mind that this process can require a large
amount of memory and an extended amount of time.
8. When importing Web Content Manager collections from portal V6.0.1.x, modify the target URL for the
affected content sources to use the IP address of the new portal server. To do this, click the content
source, select the General parameters tab, and modify the field Collect documents linked from this
URL.
Notes:
1. When you import search collection data into a collection, most of the configuration data (for example,
content sources, schedulers, filters, and language settings) are also imported. If you configured such
settings when creating the new collection, they are overwritten by the imported settings.
2. If you migrate a remote search service, use the updated file PseLibs.zip. This file is compiled by Java
5, therefore you need to have your portal running under IBM WebSphere Application Server Version
7.0. You do not need to replace the SOAP and EJB applications.

3. If you migrate to WebSphere Portal Version 7.0, you can migrate only your web collections. You
cannot migrate your portal search collections.
Related tasks:
“Migrating the Search and Browse portlet” on page 1452
To ensure that the Search and Browse portlet works as expected, verify that the CollectionLocation
parameter reflects the correct path for the new portal installation.
Migrating web search collections:
You migrate web search collections to IBM WebSphere Portal Version 7.0 by exporting each web search
collection from the earlier portal and then importing the web search collection into the new portal. You
can also use the same functionality to move web search collections to a production portal after verifying
them on a test portal, or to move web search collections to a configuration with remote search after
verifying them locally on a portal.
Note: Exporting and importing portal site search collections into portal Version 7.0 is not supported.
Related tasks:
Exporting a web collection:
Use the Manage Search portlet to export search web collections from a source portal. Before exporting a
web collection, verify that the portal application process has write access to the target directory location.
Use the Manage Search portlet to complete the following steps:

1. On the earlier portal server, select the collection that you want to export.
2. In the Search Collections box, click Export collection.
3. In the Specify Location field, enter the full directory path and XML file name to which you want to
export the document collection and its data.
4. Click Export
Importing a web collection:
After you export a search web collection from a source portal, you can import the data into a new, empty
collection on the target portal. Importing a web collection retains most of the configuration data such as
content sources, schedulers, filters, and language settings. If you configured such settings when creating
the new collection, they are overwritten by the imported settings.
When you import a web collection, a background process fetches, crawls, and indexes all documents that
are listed by URL in the previously exported file. Therefore be aware of the memory and time required
for crawls. For more information, see Hints and tips on using Portal Search.
Complete the steps below on the target portal, using the Manage Search portlet:
1. If you are migrating to a remote server, copy the XML file that contains the exported web collection to
the server where the new version of WebSphere Portal is installed.
2. In the Search Collections box, click Create Collection to create an empty collection.
3. Specify the required information in the Location of Collection, Name of Collection, and Description
of Collection fields, and then click OK.
4. Select the empty collection that you created.
5. In the Search Collections box, click Import collection.
Migrating 1451
6. In the Specify Location field, enter the full directory path and XML file name of the file that you
exported.
7. Click Import.
8. Select the collection that you created, and then click the Eyeglasses icon to search and browse the
collection.
9. Verify that the documents found are the same as the collection that you created on the earlier portal
server, and that the links work as expected. Any inconsistencies between the exported document
count and the imported document count should be resolved the next time the cleanup daemon runs.
Related tasks:
“Migrating a Version 6.0.1.x product configuration” on page 1453
Instructions for migrating IBM WebSphere Portal V6.0.1.x configuration vary slightly depending on
whether the new version is installed on the same server or on a different, remote server.
“Migrating a remote search server” on page 1453
If the source portal environment uses a remote search server, update the remote search server to work
with the current portal environment.
Related reference:
“Hints and tips for using Portal Search” on page 2226
View some useful tips for using Portal Search.
Migrating the Search and Browse portlet:
Complete the following steps:

1. In the product banner, click Administration, then under Portlet Management, click Portlets.
2. Locate the Search and Browse portlet and then click the Configure icon.
3. Verify the location of the search collection in the new portal installation and update
CollectionLocation as needed.
4. If the portal environment uses a remote search server, verify that either Soap_URL or IIO_URL is set to
the correct value.
6. Restart the portal.
7. Perform this procedure for all instances of the Search and Browse portlet that you deployed in your
portal.

Related tasks:
“Migrating a Version 6.0.1.x product configuration”
“Migrating a remote search server”
“Migrating web search collections” on page 1451
“Migrating portal search collections” on page 1449
migration.
Migrating a remote search server:
1. Update IBM WebSphere Application Server on the remote search server to the supported version.
To avoid port conflicts, ensure that the earlier installed version of WebSphere Application Server is up
and running, and then install the current version of WebSphere Application Server to a different
directory. After installation, check that both the earlier version and the newer version are running, and
then continue configuring the remote server. For more information, see Using remote search service.
2. On the migrated portal, recreate the search collections for use with the updated remote search server.
Related concepts:
Related tasks:
“Importing a web collection” on page 1451
Migrating a Version 6.0.1.x product configuration

Important: During migration, the portal may be in a state where it may or may not start. Do not attempt
to use the portal until migration is complete; the portal is not in a production-ready state until you
complete the portal-post-upgrade task.
Migrating 1453
Related tasks:
“Importing a web collection” on page 1451
“Running migration tasks for composite applications” on page 1479
Use the WPMigrate script to migrate composite applications from IBM WebSphere Portal Version 6.0.1.4 or
later to Version 7.0. When you migrate a portal environment using the portal-pre-upgrade task and the
portal-post-upgrade task, composite applications that have been enabled for backup are also migrated.
You can also choose to migrate composite applications independently of the core portal migration by
running the migrate-ai-export and migrate-ai-import tasks.
Migrating to the same server

Migrating to a new version of IBM WebSphere Portal on the same server is a combination of exporting
content from the earlier version, and then importing that content to the new version.
Exporting V6.0.1.x configuration:
To back up server artifacts, extract database information, and export content from IBM WebSphere Portal
V6.0.1.x, use the WPmigrate script to run the portal-pre-upgrade task.
Run WPmigrate with the portal-pre-upgrade task from the wp_profile_root/PortalServer/migration

directory, where wp_profile_root is the profile directory of the new WebSphere Portal version.
Run the script as follows:

Windows: WPmigrate.bat portal-pre-upgrade -Dproperty=value
UNIX: ./WPmigrate.sh portal-pre-upgrade -Dproperty=value
i: WPmigrate.sh portal-pre-upgrade -Dproperty=value
where:
property is a specific property that is used by the task
value is the property value
Migration log output for the portal-pre-upgrade task is stored in several different log files that you can
view using a text editor. For more information, see the topic on WebSphere Portal logs.
Important:
v The portal-pre-upgrade task uses the IBM WebSphere Application Server WASPreUpgrade command in
conjunction with special WebSphere Portal parameters to migrate WebSphere Application Server
configuration information from the earlier portal installation to the new portal installation. To avoid
problems, do not attempt to migrate WebSphere Application Server information yourself through
manual use of this command. For information on WASPreUpgrade, see the WebSphere Application Server
Information Center.
v To avoid OutOfMemory errors when migrating a large number of applications and associated artifacts,
add -Xmx1024M to the Java command line in AppServer_root/bin/WASPreUpgrade.sh\.bat . For example:
"$JAVA_HOME/bin/java" -Xmx1024M \

1. Stop the WebSphere Application Server and WebSphere Portal servers (server1 and WebSphere_Portal)
in the new portal installation.
2. Start the earlier WebSphere Portal server.
3. Change to the wp_profile_root/PortalServer/migration directory.
4. To export the base server, run the portal-pre-upgrade task as follows:
v Windows:
WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname

-DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword
v UNIX:
./WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname

v i:
WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname

where:
backupDirectory
The directory where data from the earlier server will be stored for subsequent use with the
portal-post-upgrade task. If this directory does not exist, the portal-pre-upgrade task creates
it.
For example, if you specify mybackup, the migration task stores the data under the mybackup
directory.
currentPortalDirectory
The directory where the earlier portal server is installed.
currentPortalAdminId
The administrator ID for the earlier portal server. This value is not required if it is already
specified in the wpconfig.properties file on the earlier portal server.
currentPortalAdminPwd
The administrator password for the earlier portal server.
DbPassword
The DBMS user password for the earlier portal server. Specify this property value in the
command line only if the property is not already specified. In WebSphere Portal V6.0.1.3 or
later, the property value is specified in the wpconfig_dbdomain.properties file, next to the
property name release.DbPassword.
All other database properties must be specified in the properties file.
The following properties are optional:
GroupExport
Exports groups from the earlier version when the value is set to true. This property is set by
default to false.
Important: GroupExport=true should only be used if you are using delegated access control
for users and groups in the portal. For typical installations where delegated access control is
not in use, exporting groups is not recommended due to its performance impact.
If you are using delegated access control, the following considerations apply:
v If the portal uses the WMM database repository for application groups, this option is not
required as the groups are migrated automatically by the WMM to VMM migration.
Migrating 1455
v The ability to export groups from the earlier portal depends on the number of groups and
the amount of time specified in the Enterprise Java Bean (EJB) transaction setting. If the
number of groups is too high to export within the amount of time specified in the EJB
transaction setting, the portal-pre-upgrade task may report an error. Try increasing the
wmmAPP EJB transaction time. For more information, see Configuring transactional
deployment attributes in the WebSphere Application Server information center.
SkipAiMigration
Suppresses migration of composite applications when set to any value. When this property is
omitted, composite applications are included in migration.
5. For each virtual portal that you want to migrate, run the portal-pre-upgrade task, as described
above, and include the additional VirtualPortal property:
v Windows:
WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=admin

v UNIX:
./WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=admi

v i:
WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminp

where:
VirtualPortal
The context extension for the virtual portal URL. See the URL Context description row in the
Virtual Portal Manager portlet.
Notes:
v The backup directory that you specify for the virtual portal must be the same backup directory that
you specified in the previous step to export the base server.
v Base server migration must be done before virtual portal migration.
v Virtual portals must be exported individually, one at a time; you cannot export a collection of
virtual portals at once.
6. Check allout.xml for any warning or error messages, and address any issues before moving on.
If you are migrating from version V6.0.1.3 or later, look for allout.xml in the backupDirectory/
profiles/<profile dir>/PortalServer/migration/work/default directory where backupDirectory is the
location that you specified in the previous step.
If allout.xml contains messages with the ID EJPXA0185W or EJPXA0186W, see Technote 1300236 for
additional information.

Related concepts:
“Installation, configuration, and migration logs” on page 3543
Learn about the different log files that WebSphere Portal provides to help administrators identify and
correct problems with installation, migration, and IBM i configuration.
Related tasks:
“Suppressing migration of composite applications” on page 1478
If you want to suppress the migration of composite applications during core portal migration, specify the
parameter DSkipAiMigration=true when you run the portal-pre-upgrade and the portal-post-upgrade
tasks.
“Preparing for migration from V6.0.1.x” on page 1423
Technote 1300236
WebSphere Application Server V7 Information Center
Updating database properties for local migration:
If the V6.0.1.x portal installation is configured to use a Member Manager lookaside, database, or database
federation repository, you must modify the appropriate property files in the wp_profile_root/ConfigEngine/
properties directory on the new portal before you run the portal-post-upgrade task to import data.
1. To determine the repository configuration that the earlier portal installation uses, open the wmm.xml file
located in the prev_wp_root/wmm directory where prev_wp_root is the location of the earlier portal
installation.
2. Locate the <repositories> section in wmm.xml.
If the portal uses a Member Manager lookaside repository, the file defines a lookAsideRepository
element. For example:
<repositories>
<lookAsideRepository name="wmmDBLookAside"
UUID="LA"
supportTransactions="true"
adapterClassName="com.ibm.ws.wmm.lookaside.db.LookAsideAdapter"
...
If the portal uses a Member Manager database repository, the file defines a databaseRepository
<repositories>
<databaseRepository name="wmmDB"
UUID="DB1"
wmmGenerateExtId="true"
adapterClassName="com.ibm.ws.wmm.db.DatabaseRepository"
...
If the portal uses a Member Manager database federation repository, the file defines a
federationRepository element. For example:
<repositories>
...
<federationRepository name="wmmDBFederation"
UUID="FD"
adapterClassName="com.ibm.ws.wmm.db.DataBaseFederationAdapter"
dataSourceName="jdbc/wp60DSwm"
databaseType="oracle"
dataAccessManagerClassName="com.ibm.ws.wmm.db.dao.oracle.WMMOracleDao"/>
3. If the portal uses a property extension (lookaside) database, verify that la.providerURL in the
wkplc.properties file is set to the correct bootstrap port address and modify the file if needed.
Migrating 1457
la.providerURL=corbaloc:iiop:localhost:port
4. If the earlier portal uses a Member Manager look aside repository, data repository, or database
federation repository, complete the steps below on the new portal:
a. Create a database, set the database information in the wkplc_dbtype.properties file, and update
the values for the la.* and federated.db.* parameters in the wkplc.properties file.
Notes:
v For reference, see the topics on creating a property extension database and adding a user
registry (for example, Configuring a property extension database on Windows, and Adding a
database user registry on Windows). Use the instructions in these topics as a guide only, since
for migration, you must create a single database that both sets of parameters point to. Complete
only the steps that explain how to set up a new database, define the DbDriver and DbLibrary
parameter values, and update the la.* parameters (as described in the property extension topic)
and the federated.db.* parameters (as described in the user registry topic).
v You must specify the same value for corresponding la and federated.db parameters. For
example, use the same value for la.DbType and federated.db.DbType.
v You may also need to update federated.db.DbSchema, which is located in the Advanced
Properties section of the wkplc.properties file. This parameter defines the VMM Federated DB
domain database schema name, and is set, by default, to federate. For example, if you are
using DB2, perform these steps to validate the schema name for the newly created VMM
database:
1) Open a DB2 command window, then type db2 "select * from syscat.schemata" to see the
current value for the VMM database schema.
2) If the schema is undefined, you can specify a new schema name by running the DB2
command db2 create schema federate where federate is the name of your schema.
v For Microsoft SQL Server Enterprise Edition, the database name must match the database
administrator name.
Note: To avoid problems that can occur if WebSphere Portal uses either Microsoft SQL Server or
DB2 for z/OS and you need to repeat a migration task, back up Virtual Member Manager
(VMM) SQL configuration files prior to any migration changes that involve the VMM database.
For more information, see technote 1326062, Security and migration tasks that run on WebSphere
Virtual Member Manager (VMM) database fail when expected values are not found.
b. Set the WMM DB parameters in the WmmVmmDBMigration.properties file.
Notes:
v Ensure that there are no trailing spaces or tabs in any of the parameter values.
v When setting migration.wmm.database.driver.path in the WmmVmmDBMigration.properties, file,
you must use the same driver that is used for the Version 7.0 lookaside or database repository.
The driver specified here should match the driver for your database type in
wkplc_dbtype.properties. You must also copy the driver that you specify here to the
AppServer_rootlib directory.
v If the portal uses both a Member Manager Lookaside repository and a Member Manager
federated repository (or database repository), you must update the la.* parameters and the
federated.db.* parameters to use the same configuration values. You cannot split the locations
of the VMM DB tables across database types.
Technote 1326062
Importing V6.0.1.x configuration:

To import backed-up artifacts and content that were exported from IBM WebSphere Portal V6.0.1.x into
Version 7.0 on the same machine, use the WPmigrate script to run the portal-post-upgrade task.
Important: Before performing the import, complete these tasks:

v Update the following properties in the wp_profile_root/ConfigEngine/properties/
WmmVmmDBMigration.properties file on the new portal: PrevPortalAdminId, PrevPortalAdminGroupId,
PrevWasUserid, PrevWasAdminGroupId. When specifying these values, keep the following conditions in
mind:
– Ensure that you specify the fully qualified distinguished name (DN) for these properties. Specifying
the short name results in a failed migration. Verify the fully qualified DN by checking the
configuration of your directory server.
– Ensure that there are no trailing spaces or tabs in the parameter values.
For any other administrator and group properties (Prev*) for the previous portal in the
WmmVmmDBMigration.properties file, specify the fully qualified DN for the values.
v The portal-post-upgrade task includes code that prompts for the IBM WebSphere Application Server
administrator ID and password. If you plan to run this stage of the migration unattended, ensure that
you add the WebSphere Application Server administrator ID and password to wp_profile_root/
properties/sas.client.props and set loginSource=properties; you must also set the administrator ID
and password in the com.ibm.CORBA.loginUserid and com.ibm.CORBA.loginPassword properties.
Note: To run the portal-post-upgrade task remotely through a telnet session, set loginSource either to
properties as described above, or to stdin.
Run WPmigrate with the portal-post-upgrade task from the wp_profile_root/PortalServer/migration


Windows: WPmigrate.bat portal-post-upgrade -Dproperty=value
UNIX: ./WPmigrate.sh portal-post-upgrade -Dproperty=value
i: WPmigrate.sh portal-post-upgrade -Dproperty=value
where:
Migration log output for the portal-post-upgrade task is stored in several different log files that you can
1. Stop the WebSphere Application Server and the earlier WebSphere Portal servers (server1 and
WebSphere_Portal) in the earlier portal version.
2. Stop the new WebSphere Portal server.
3. Before migrating exported content into a new portal installation on AIX, Linux, Solaris, or i, check
the value that is set by the ulimit command, and then increase the value to 200000.
The ulimit command determines the maximum number of open files that the operating system
supports. By increasing the value before you migrate exported content into the new portal
installation, you can avoid problems that might be caused if the value were too low. After migration
is complete, you can restore the earlier value. For more information on ulimit, see the reference
documentation for your operating system.
5. Run the portal-post-upgrade task as follows:
v Windows:
Migrating 1459
WPmigrate.bat portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid -DPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=wasp
v UNIX:
./WPmigrate.sh portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid -DPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=was

v i:
WPmigrate.sh portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid -DPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=waspa

where:
backupDirectory
The directory where the portal-pre-upgrade task stored the data that it exported from the
earlier server.
PortalAdminId
specified in the wkplc.properties file. Specify the login form of the administrator ID rather
than the fully qualified name; for example, specify wpsadmin rather than uid=wpsadmin,
o=defaultWIMFileBasedRealm
PortalAdminPwd
The administrator ID password for the earlier portal server.
WasUserid
The administrator ID for WebSphere Application Server that is used by the new portal
server. This value is not required if it is already specified in the wkplc.properties file.
Specify the login form of the administrator ID rather than the fully qualified name; for
example, specify wasadmin rather than uid=wasadmin, o=defaultWIMFileBasedRealm
Important: The administrator ID that the new portal installation uses must match the
administrator ID that the earlier portal version uses.
WasPassword
The password for the WebSphere Application Server administrator ID.
Important: The administrator password for the new portal installation must match the
administrator password used in the earlier portal version.
migration.vmm.database.admin.password
The administrator password for the VMM database that the new WebSphere Portal version
uses. This value is not required if it is already specified in wp_profile_root/ConfigEngine/
properties/WmmVmmDBMigration.properties.
migration.wmm.database.admin.password
The administrator password for the WMM database that the new WebSphere Portal version
uses.This value is not required if it is already specified in wp_profile_root/ConfigEngine/
oldProfile
The earlier portal server's profile name. The profile name must already exist in the backup
directory specified above.
This value is required if the earlier portal server's profile name is different from the new
portal server's profile name.
SkipAiMigration
Suppresses migration of composite applications when set to any value. Composite
applications are included in migration when this property is omitted.
6. Verify the migrated portal.

a. Start the portal server, if it is not running.
b. Open a web browser and enter the URL for the migrated portal.
The migrated portal URL takes this form:
http://host_name:port_number/original-context-root_migrated/portal
For example, if your original portal URL is http://www.example.com:10040/wps/portal, the URL

for the migrated portal is http://www.example.com:10040/wps_migrated/portal.
Note: During migration, the following changes are made to the wkplc.properties file stored in
the wp_profile_root/ConfigEngine/properties directory:
v The property WpsContextRootOriginal is set to the original value of the context root before
migration was performed. This property is for reference only and is not used by the migrated
portal.
v The value of the WpsContextRoot property is set to the migrated value original-context-
root_migrated (for example, wps_migrated).
7. If you have not yet created an empty virtual portal for each virtual portal that you want to migrate,
use the create-virtual-portal ConfigEngine task to create empty virtual portals with the
corresponding name and URL context. For information on the create-virtual-portal task, see
Virtual portals reference.
8. For each virtual portal that you want to migrate, run the portal-post-upgrade task, as described
v Windows:
WPmigrate.bat portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid -DPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=w

v UNIX:
./WPmigrate.sh portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid -DPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=

v i:
WPmigrate.sh portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid -DPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=wa

where:
VirtualPortal
WpsHomePage
The unique page name that you want to assign to the home page in the virtual portal.
Note: Virtual portals must be imported individually, one at a time; you cannot import a collection of
9. If you cloned the FileServer portlet in the earlier version and supplied HTML files in the
wp_old_root/installedApps/FileServer_PA_1_0_4H.ear/FileServer.war/FileServerPortlet/html
directory, you must copy those files to the PortalServer_root/installedApps/cell_name/
PA_FileServer.ear/FileServer.war/FileServerPortlet/html directory, after running the
portal-post-upgrade task and before restarting the server, to make the files accessible in the new
version.
Note: For i, the directories are wp_user_old_root and PortalServer_root_user, respectively.

10. Complete the following steps where the new version is installed:
a. Open a command prompt and change to the following directory:
Windows: wp_profile_root\bin
UNIX: wp_profile_root/bin
Migrating 1461
IBM i: wp_profile_root/bin
b. Enter the following command to stop the WebSphere_Portal server, where WebSphere_Portal is the
name of the WebSphere Portal server:
Windows: stopServer.bat WebSphere_Portal -username admin_userid -password
admin_password
UNIX: ./stopServer.sh WebSphere_Portal -username admin_userid -password
admin_password
IBM i: stopServer WebSphere_Portal -username admin_userid -password admin_password
c. Enter the following command to start the WebSphere_Portal server, where WebSphere_Portal is the
Windows: startServer.bat WebSphere_Portal
UNIX: ./startServer.sh WebSphere_Portal
IBM i: startServer WebSphere_Portal
11. If the new portal server is running on AIX, Linux, Solaris, or i, reset the ulimit to the earlier value
that you noted before you ran the portal-post-upgrade task. If needed, see the reference
documentation for your operating system for more information on ulimit.
Note: The portal-post-upgrade task changes the admin user ID and password settings for WebSphere
Portal but not for WebSphere Application Server. If needed, you can manually update the WebSphere
Application Server admin user ID and password. For instructions, see the topic on changing passwords.
Related concepts:
Related tasks:
tasks.
Related reference:
work.
Migrating to a remote server

Migrating to a new version of IBM WebSphere Portal on a different server requires exporting content
from the earlier version, moving the exported content to the machine where the new version is installed,
and then importing the content into the new version.
JDBC note: Before attempting to migrate to a remote server, ensure that you have installed the JDBC
drivers on the target server in the same directory in which they are installed on the source server.

Preparing supplementary files for remote migration:
Portal provides.
1. On the WebSphere Portal Version 7.0 server, run the following command to create the
PortalRemMigPkg.zip file:
v Windows: PortalServer_root\bin\genRemMigPkg.bat remote_zip_dir
v UNIX: PortalServer_root/bin/genRemMigPkg.sh remote_zip_dir
v i: PortalServer_root/bin/genRemMigPkg.sh remote_zip_dir
where remote_zip_dir is an existing directory that will contain the generated file. This directory
should not be the default directory and should be specified using the full path to the directory.
2. Copy the contents of the WebSphere Application Server Network Deployment Version 7 Supplements
Disc 2 for your operating system to supp_dir where supp_dir is an existing directory on the source
portal server.
Note: If you are using a 32–bit database driver on a 64–bit machine, you need to use the 32–bit
WebSphere Application Server Network Deployment Version 7 Supplements Disc 2; if you have a
64–bit database driver on a 64–bit machine, use the 64–bit WebSphere Application Server Network
Deployment Version 7 Supplements Disc 2.
3. Copy PortalRemMigPkg.zip from the WebSphere Portal Version 7.0 server into supp_dir, the directory
on the source portal server where you copied the Supplements Disc 2 files.
4. Unzip PortalRemMigPkg.zip.
5. UNIX only: Ensure that read and execute permissions are set on the extracted files. For example:
chmod -R 755 supp_dir/PortalMigration
chmod 755 supp_dir/migration/plugins/com.ibm.patch.was.plugin.jar
supp_dir/migration/plugins/com.ibm.wp.was.plugin.jar
6. To verify that the supplementary files are properly set up, change to the supp_dir/PortalMigration
directory and run the following command:
v Windows: WPmigrate.bat
v UNIX: ./WPmigrate.sh
v i: WPmigrate.sh
If the supplementary files are set up properly, you should see a response like this:
usage:
[echo] WPmigrate <migration-command> [[-Dproperty1=value1] -Dproperty2=value2]...]
BUILD SUCCESSFUL
Related tasks:
“Exporting configuration for migration to a remote server”
V6.0.1.x running on either Windows or UNIX, run the WPmigrate script with the portal-pre-upgrade task
from the previously prepared directory that contains the required supplementary files.
Exporting configuration for migration to a remote server:
Migrating 1463
Attention: These instructions are not intended for use on IBM i. To perform a remote migration on i,
you must install the new version of WebSphere Portal on the same server as the earlier version, and then
follow the steps in the topic that explains how to export core information for migration to the same
machine. After running the portal-pre-upgrade task, you can move the backup directory that contains
the exported information to the remote machine where the new portal version that you want to use is
installed, and then continue the migration process. To do this, follow the steps in the topic that explains
how to import core information for migration to a remote machine.
From the supp_dir directory on the WebSphere Portal V6.0.1.x server, run WPmigrate with the
portal-pre-upgrade task as follows:
Windows: WPmigrate.bat portal-pre-upgrade -Dproperty=value
UNIX: ./WPmigrate.sh portal-pre-upgrade -Dproperty=value
i: WPmigrate.sh portal-pre-upgrade -Dproperty=value
where:
Migration log output for the portal-pre-upgrade task is stored in several different log files that you can
Important:
v The portal-pre-upgrade task uses the IBM WebSphere Application Server WASPreUpgrade command in
conjunction with special WebSphere Portal parameters to migrate WebSphere Application Server
configuration information from the earlier portal installation to the new portal installation. To avoid
problems, do not attempt to migrate WebSphere Application Server information yourself through
manual use of this command. For information on WASPreUpgrade, see the WebSphere Application Server
Information Center.
v To avoid OutOfMemory errors when migrating a large number of applications and associated artifacts,
add -Xmx1024M to the Java command line in AppServer_root/bin/WASPreUpgrade.sh\.bat . For example:
"$JAVA_HOME/bin/java" -Xmx1024M \
1. Stop the WebSphere Application Server and WebSphere Portal servers (server1 and WebSphere_Portal)
in the new portal installation.
2. Start the earlier WebSphere Portal server and ensure that it is accessible to the network.
3. On the server where the earlier portal installation is located, change to the CD_root/
PortalMigrationPortalRemMigPkg directory that you set up in the previous task when you assembled
the supplementary files needed for migration to a remote server.
4. To export the base server, run the portal-pre-upgrade task as follows:
v Windows:
WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname

v UNIX:
./WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname

v i:
WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname

where:

backupDirectory
The directory where data from the earlier server will be stored for subsequent use with the
portal-post-upgrade task. If this directory does not exist, the portal-pre-upgrade task creates
it.
For example, if you specify mybackup, the migration task stores the data under the mybackup
directory.
currentPortalDirectory
The directory where the earlier portal server is installed.
currentPortalAdminId
specified in the wpconfig.properties file on the earlier portal server.
currentPortalAdminPwd
The administrator password for the earlier portal server.
DbPassword
The DBMS user password for the earlier portal server. Specify this property value in the
command line only if the property is not already specified. In WebSphere Portal V6.0.1.3 or
later, the property value is specified in the wpconfig_dbdomain.properties file, next to the
property name release.DbPassword.
All other database properties must be specified in the properties file.
GroupExport
Exports groups from the earlier version when the value is set to true. This property is set by
default to false.
Important: GroupExport=true should only be used if you are using delegated access control
for users and groups in the portal. For typical installations where delegated access control is
not in use, exporting groups is not recommended due to its performance impact.
If you are using delegated access control, the following considerations apply:
v If the portal uses the WMM database repository for application groups, this option is not
required as the groups are migrated automatically by the WMM to VMM migration.
v The ability to export groups from the earlier portal depends on the number of groups and
the amount of time specified in the Enterprise Java Bean (EJB) transaction setting. If the
number of groups is too high to export within the amount of time specified in the EJB
transaction setting, the portal-pre-upgrade task may report an error. Try increasing the
wmmAPP EJB transaction time. For more information, see Configuring transactional
deployment attributes in the WebSphere Application Server information center.
SkipAiMigration
Suppresses migration of composite applications when set to any value. When this property is
omitted, composite applications are included in migration.
5. For each virtual portal that you want to migrate, run the portal-pre-upgrade task, as described
v Windows:
WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adm

v UNIX:
./WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=a

v i:
Migrating 1465
WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminp
where:
VirtualPortal
Notes:
v The backup directory that you specify for the virtual portal must be the same backup directory that
you specified in the previous step to export the base server.
v Base server migration must be done before virtual portal migration.
v Virtual portals must be exported individually, one at a time; you cannot export a collection of
6. Check allout.xml for any warning or error messages, and address any issues before moving on.
If you are migrating from version V6.0.1.3 or later, look for allout.xml in the backupDirectory/
profiles/<profile dir>/PortalServer/migration/work/default directory where backupDirectory is the
location that you specified in the previous step.
If allout.xml contains messages with the ID EJPXA0185W or EJPXA0186W, see Technote 1300236 for
additional information.
Related concepts:
“Version 6.0 post migration steps for web content” on page 1490
Once you have completed the WebSphere Portal migration steps, you need to perform these additional
steps to complete your web content migration.
Related tasks:
tasks.
“Preparing supplementary files for remote migration” on page 1463
Portal provides.
“Working with the XML configuration interface” on page 1882
You can use the XML configuration interface to export and import configurations.
Technote 1300236
Updating database properties for remote migration:

If the V6.0.1.x portal installation is configured to use a Member Manager lookaside, database, or database
federation repository, you must modify the appropriate property files in the wp_profile_root/ConfigEngine/
properties directory on the new portal before you run the portal-post-upgrade task to import data.
1. To determine the repository configuration that the earlier portal installation uses, open the wmm.xml file
located in the prev_wp_root/wmm directory where prev_wp_root is the location of the earlier portal
installation.
2. Locate the <repositories> section in wmm.xml.
If the portal uses a Member Manager lookaside repository, the file defines a lookAsideRepository
<repositories>
<lookAsideRepository name="wmmDBLookAside"
UUID="LA"
adapterClassName="com.ibm.ws.wmm.lookaside.db.LookAsideAdapter"
...
If the portal uses a Member Manager database repository, the file defines a databaseRepository
<repositories>
<databaseRepository name="wmmDB"
UUID="DB1"
wmmGenerateExtId="true"
adapterClassName="com.ibm.ws.wmm.db.DatabaseRepository"
...
If the portal uses a Member Manager database federation repository, the file defines a
federationRepository element. For example:
<repositories>
...
<federationRepository name="wmmDBFederation"
UUID="FD"
adapterClassName="com.ibm.ws.wmm.db.DataBaseFederationAdapter"
dataSourceName="jdbc/wp60DSwm"
databaseType="oracle"
dataAccessManagerClassName="com.ibm.ws.wmm.db.dao.oracle.WMMOracleDao"/>
3. If the portal uses a property extension (lookaside) database, verify that la.providerURL in the
wkplc.properties file is set to the correct bootstrap port address and modify the file if needed.
la.providerURL=corbaloc:iiop:localhost:port
4. If the earlier portal uses a Member Manager look aside repository, data repository, or database
federation repository, complete the steps below on the new portal:
a. Create a database, set the database information in the wkplc_dbtype.properties file, and update
the values for the la.* and federated.db.* parameters in the wkplc.properties file.
Notes:
v For reference, see the topics on creating a property extension database and adding a user
registry (for example, Configuring a property extension database on Windows, and Adding a
database user registry on Windows). Use the instructions in these topics as a guide only, since
for migration, you must create a single database that both sets of parameters point to. Complete
only the steps that explain how to set up a new database, define the DbDriver and DbLibrary
parameter values, and update the la.* parameters (as described in the property extension topic)
and the federated.db.* parameters (as described in the user registry topic).
v You must specify the same value for corresponding la and federated.db parameters. For
example, use the same value for la.DbType and federated.db.DbType.
v You may also need to update federated.db.DbSchema, which is located in the Advanced
Properties section of the wkplc.properties file. This parameter defines the VMM Federated DB
Migrating 1467
domain database schema name, and is set, by default, to federate. For example, if you are
using DB2, perform these steps to validate the schema name for the newly created VMM
database:
1) Open a DB2 command window, then type db2 "select * from syscat.schemata" to see the
current value for the VMM database schema.
2) If the schema is undefined, you can specify a new schema name by running the DB2
command db2 create schema federate where federate is the name of your schema.
v For Microsoft SQL Server Enterprise Edition, the database name must match the database
administrator name.
Note: To avoid problems that can occur if WebSphere Portal uses either Microsoft SQL Server or
DB2 for z/OS and you need to repeat a migration task, back up Virtual Member Manager
(VMM) SQL configuration files prior to any migration changes that involve the VMM database.
For more information, see technote 1326062, Security and migration tasks that run on WebSphere
Virtual Member Manager (VMM) database fail when expected values are not found.
b. Set the WMM DB parameters in the WmmVmmDBMigration.properties file.
Notes:
v Ensure that there are no trailing spaces or tabs in any of the parameter values.
v When setting migration.wmm.database.driver.path in the WmmVmmDBMigration.properties, file,
you must use the same driver that is used for the Version 7.0 lookaside or database repository.
The driver specified here should match the driver for your database type in
wkplc_dbtype.properties. You must also copy the driver that you specify here to the
AppServer_rootlib directory.
v If the portal uses both a Member Manager Lookaside repository and a Member Manager
federated repository (or database repository), you must update the la.* parameters and the
federated.db.* parameters to use the same configuration values. You cannot split the locations
of the VMM DB tables across database types.
Technote 1326062
Importing configuration for migration to a remote machine:
To import backed-up artifacts and content that were exported from IBM WebSphere Portal V6.0.1.x, use
the WPmigrate script to run the portal-post-upgrade task.
Important: Before performing the import, complete these tasks:

v Update the following properties in the wp_profile_root/ConfigEngine/properties/
WmmVmmDBMigration.properties file on the new portal: PrevPortalAdminId, PrevPortalAdminGroupId,
PrevWasUserid, PrevWasAdminGroupId. When specifying these values, keep the following conditions in
mind:
– Ensure that you specify the fully qualified distinguished name (DN) for these properties. Specifying
the short name results in a failed migration. Verify the fully qualified DN by checking the
configuration of your directory server.
– Ensure that there are no trailing spaces or tabs in the parameter values.
For any other administrator and group properties (Prev*) for the previous portal in the
WmmVmmDBMigration.properties file, specify the fully qualified DN for the values.
v The portal-post-upgrade task includes code that prompts for the IBM WebSphere Application Server
administrator ID and password. If you plan to run this stage of the migration unattended, ensure that
you add the WebSphere Application Server administrator ID and password to wp_profile_root/
properties/sas.client.props and set loginSource=properties; you must also set the administrator ID
and password in the com.ibm.CORBA.loginUserid and com.ibm.CORBA.loginPassword properties.

Note: To run the portal-post-upgrade task remotely through a telnet session, set loginSource either to
properties as described above, or to stdin.
v Increase the lifetime timeout value. For more details about how to do this refer to the WebSphere
Application Server information center.
v If you are using DB2 type 4 driver, ensure that you have copied and pasted db2jcc4.jarand
db2jcc_license_cu.jar to the AppServer_root/lib directory.
Note: Note: If you are using DB2 Version 9.1, you must use the db2jcc.jar file. You will need to replace
v If you are using DB2 type 2 driver, ensure that you have copied and pasted db2jcc4.jarto the
AppServer_root/lib directory.
Note: Note: If you are using DB2 Version 9.1, you must use the db2jcc.jar file. You will need to replace
Run WPmigrate with the portal-post-upgrade task from the wp_profile_root/PortalServer/migration


Windows: WPmigrate.bat portal-post-upgrade -Dproperty=value
UNIX: ./WPmigrate.sh portal-post-upgrade -Dproperty=value
i: WPmigrate.sh portal-post-upgrade -Dproperty=value
where:
Migration log output for the portal-post-upgrade task is stored in several different log files that you can
1. Move the directory that contains the exported data to the remote machine where the new version of
WebSphere Portal is installed. Use a compression utility to compress the directory contents, or map a
drive to the remote machine, and then move the directory containing the exported data to the
remote machine.
2. Stop the new WebSphere Portal server.
3. Before migrating exported content into a new portal installation on AIX, Linux, Solaris, or i, check
the value that is set by the ulimit command, and then increase the value to 200000.
supports. By increasing the value before you migrate exported content into the new portal
installation, you can avoid problems that might be caused if the value were too low. After migration
is complete, you can restore the earlier value. For more information on ulimit, see the reference
documentation for your operating system.
5. Run the portal-post-upgrade task as follows:
v Windows:

v UNIX:

v i:
Migrating 1469
WPmigrate.sh portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid -DPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=waspa
where:
backupDirectory
The directory where the portal-pre-upgrade task stored the data that it exported from the
earlier server.
PortalAdminId
specified in the wkplc.properties file. Specify the login form of the administrator ID rather
than the fully qualified name; for example, specify wpsadmin rather than uid=wpsadmin,
o=defaultWIMFileBasedRealm
PortalAdminPwd
The administrator ID password for the earlier portal server.
WasUserid
The administrator ID for WebSphere Application Server that is used by the new portal
server. This value is not required if it is already specified in the wkplc.properties file.
Specify the login form of the administrator ID rather than the fully qualified name; for
example, specify wasadmin rather than uid=wasadmin, o=defaultWIMFileBasedRealm
Important: The administrator ID that the new portal installation uses must match the
administrator ID that the earlier portal version uses.
WasPassword
The password for the WebSphere Application Server administrator ID.
Important: The administrator password for the new portal installation must match the
administrator password used in the earlier portal version.
migration.vmm.database.admin.password
The administrator password for the VMM database that the new WebSphere Portal version
uses. This value is not required if it is already specified in wp_profile_root/ConfigEngine/
migration.wmm.database.admin.password
The administrator password for the WMM database that the new WebSphere Portal version
uses.This value is not required if it is already specified in wp_profile_root/ConfigEngine/
oldProfile
The earlier portal server's profile name. The profile name must already exist in the backup
This value is required if the earlier portal server's profile name is different from the new
portal server's profile name.
SkipAiMigration
Suppresses migration of composite applications when set to any value. Composite
applications are included in migration when this property is omitted.
6. Verify the migrated portal.
a. Start the portal server, if it is not running.
b. Open a web browser and enter the URL for the migrated portal.
The migrated portal URL takes this form:

For example, if your original portal URL is http://www.example.com:10040/wps/portal, the URL
for the migrated portal is http://www.example.com:10040/wps_migrated/portal.
Note: During migration, the following changes are made to the wkplc.properties file stored in
the wp_profile_root/ConfigEngine/properties directory:
v The property WpsContextRootOriginal is set to the original value of the context root before
migration was performed. This property is for reference only and is not used by the migrated
portal.
v The value of the WpsContextRoot property is set to the migrated value original-context-
root_migrated (for example, wps_migrated).
7. If you have not yet created an empty virtual portal for each virtual portal that you want to migrate,
use the create-virtual-portal ConfigEngine task to create empty virtual portals with the
corresponding name and URL context. For information on the create-virtual-portal task, see
Virtual portals reference.
8. For each virtual portal that you want to migrate, run the portal-post-upgrade task, as described
v Windows:

v UNIX:

v i:
WPmigrate.sh portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid -DPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=wa

where:
VirtualPortal
WpsHomePage
The unique page name that you want to assign to the home page in the virtual portal.
Note: Virtual portals must be imported individually, one at a time; you cannot import a collection of
9. If you cloned the FileServer portlet in the earlier version and supplied HTML files in the
wp_old_root/installedApps/FileServer_PA_1_0_4H.ear/FileServer.war/FileServerPortlet/html
directory, you must copy those files to the PortalServer_root/installedApps/cell_name/
PA_FileServer.ear/FileServer.war/FileServerPortlet/html directory, after running the
portal-post-upgrade task and before restarting the server, to make the files accessible in the new
version.
Note: For i, the directories are wp_user_old_root and PortalServer_root_user, respectively.

10. Complete the following steps on the new version only:
a. Open a command prompt and change to the following directory:
Windows: wp_profile_root\bin
UNIX: wp_profile_root/bin
IBM i: wp_profile_root/bin
b. Enter the following command to stop the WebSphere_Portal server, where WebSphere_Portal is the
Windows: stopServer.bat WebSphere_Portal -username admin_userid -password
admin_password
Migrating 1471
UNIX: ./stopServer.sh WebSphere_Portal -username admin_userid -password
admin_password
IBM i: stopServer WebSphere_Portal -username admin_userid -password admin_password
c. Enter the following command to start the WebSphere_Portal server, where WebSphere_Portal is the
Windows: startServer.bat WebSphere_Portal
UNIX: ./startServer.sh WebSphere_Portal
IBM i: startServer WebSphere_Portal
11. If the new portal server is running on AIX, Linux, Solaris, or i, reset the ulimit to the earlier value
that you noted before you ran the portal-post-upgrade task. If needed, see the reference
documentation for your operating system for more information on ulimit.
Note: The portal-post-upgrade task changes the admin user ID and password settings for WebSphere
Portal but not for WebSphere Application Server. If needed, you can manually update the WebSphere
Application Server admin user ID and password. For instructions, see the topic on changing passwords.
Related concepts:
Related tasks:
tasks.
Related reference:
work.
Migrating the access control configuration

To complete access control migration, you must perform manual steps to migrate permissions on specific
users and groups, and credential vault data.
Log onto your previous version of WebSphere Portal and go to the Manage pages portlet. View and make
note of the access control settings for your previous version.
Migrating permissions on All Authenticated Users and All Portal User Groups
On the current WebSphere Portal system, there are different ways to assign the permissions that other
users and groups have on the defined groups All Authenticated Users and All Portal User Groups. For
example, you can use the User and Group Permissions portlet, the Resource Permissions portlet, and the
XML configuration interface.
The steps below explain how to assign the principals to roles on the appropriate user groups using the
Resource Permissions portlet.
1. Log into the current version using an administrator account.

2. Open the Resource Permissions portlet.
3. Select the Resource type User Groups.
4. Select the All Authenticated Portal Users option and analyze the existing role assignments on that
user group.
5. Use the Resource Permissions portlet to create the same role assignments on the new portal.
6. Repeat these steps for All Portal User Groups.
Related concepts:
“The XML configuration interface” on page 1876
Use the XML configuration interface for exchanging portal configurations.
Migrating credential vault data using the XML configuration interface

When you migrated the configuration, credential vault slots and segments were also migrated. To
complete the process, you need to migrate existing credential secrets by exporting them from the earlier
version and importing them into the current version. If you do not migrate existing credential vault
secrets, users must provide their credential information the first time a Version 7.0 portlet attempts to use
the data.
Because credential secrets hold confidential information, their migration requires special command line
options on the XML configuration interface as well as changes to the WebSphere Portal system
configuration to retain confidentiality of the secrets. Use the XML configuration interface directly on the
system where the WebSphere Portal server resides to minimize the communication path of the
confidential information.
1. Change the configuration of the earlier version system to enable the exportation of encrypted secrets.
Add the following information to the Credential Vault service configuration:
export.userDN
The user distinguished name (DN) value of the XML access user that should be allowed to
export secrets using the XML configuration interface. This DN is usually the same user DN
string as defined in the same configuration file under the systemcred.dn key. The user needs
authority to access the XML configuration interface and must use the interface during export
operations. Expected value: user DN string; Default value: None
export.cipher
The cipher used for encryption during the export operation. This cipher must be available
using Java JCE in the earlier version.Expected value: cipher string; Default value: AES
export.keyLength
Number of bits used as the key length for the cipher.Expected value: integer; Default value:
128
For example:
export.userDN=uid=wpsadmin,o=default organization
export.cipher=AES
export.keyLength=128
2. Restart the earlier version server to save the changes.
3. Export credential secrets from the earlier system using the XML configuration interface. When using
the XML command line client for credential export, the command syntax requires additional
parameters:
xmlaccess -user user -password password -url https://myhost:10038/wps/config/
-in XML_file -out result_file.xml -credentialexport
-passphrase encryptionPassphrase -trustore truststore_file -trustpwd truststore_password
where:
credentialexport
Indicates that export of credentials should be enabled.
Migrating 1473
passphrase
Creates a key of the specified length for the encryption. The minimum length of this string is
the number of bits set as export keylength in the Credential Vault service configuration,
divided by eight.
truststore
Indicates the location of the trust store for HTTPS. This value is required for all configurations
that use a custom certificate store to store certificates that are required for secure connections.
This value is optional for configurations that use the Java standard cacerts certificate store.
trustpwd
Indicates the trust store password for HTTPS.
For example:
xmlaccess.sh -user wpsadmin -password your_password
-url https://portalhost:10038/wps/config/
-in C:/IBM/ExportVault.xml -out C:/IBM/ExportedCredentialSecrets.xml
-credentialexport
-passphrase JGD786JHgasdf8a67kjhUIT7sdj7nsh776jasdf786regUFZT756675zufurz
-truststore C:/IBM/WebSphere/profiles/wp_profile/etc/DummyClientTrustFile.jks
-trustpwd WebAS
Example file ExportVault.xml:

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.3.xsd"
type="export" export-users="true">


<credential-segment action="export" objectid="*"/>
</portal>
</request>
4. Change the configuration of the current WebSphere Portal system to enable importing of encrypted
secrets. Add the following information to the Credential Vault service configuration. For instructions,
see the topic on Setting service configuration properties.
export.userDN
The user distinguished name (DN) value of the XML access user that should be allowed to
import secrets using the XML configuration interface. This DN is usually the same user DN
string as defined in the same configuration file under the systemcred.dn key. The user needs
authority to access the XML configuration interface and must use the interface during import
operation.Expected value: user DN string; Default value: none
export.enforceSSL
This field controls if the credential import operation must be done using a secured HTTP
connection (value = "true") or if it is allowed to import credentials using an unsecured HTTP
connection (value = "false").Expected value: true or false; Default value: true
5. Restart the portal for your changes to take effect.
6. Import credential secrets into the current WebSphere Portal system using the XML configuration
interface. To retain confidentiality, use a secure connection. For example:
xmlaccess.sh -user wpsadmin -password your_password
-url https://portalhost:10040/wps/config/
-in ExportedCredentialSecrets.xml -out result.xml
-credentialexport
-passphrase JGD786JHgasdf8a67kjhUIT7sdj7nsh776jasdf786regUFZT756675zufurz
-truststore $WASHome/profiles/wp_profile/etc/DummyClientTrustFile.jks
-trustpwd WebAS
Notes:
v Use the same passphrase value that was used during the export operation.

v The import might fail if the user DN schema has been changed between the earlier version and the
current system or when credentials for users are contained in the XML file that are not present in
the current system. In this case, manually remove the obsolete credential entries from the XML file
before running the import operation.
v You should import credentials using an HTTPS connection; however, if you choose not to, set the
export.enforceSSL configuration property to
false.
7. Delete all XML files and copies that hold exported credentials. At a minimum, delete the export file
ExportedCredentialSecrets.xml from the earlier version system.
8. Delete obsolete shared credentials on the current system. Depending on the version of the earlier
system, some secrets and shared credential slots are migrated that are obsolete in the current version.
Remove these obsolete slots using the Credential Vault administrative portlet under Administration >
Access > Credential Vault. Select Manage system vault slots and delete the following slots, if they
exist:
v deployment.user
v wmm.system.id.user
v deployment.truststore
v deployment.keystore
Related concepts:
“Credential Vault” on page 2486
The Credential Vault is a service that stores credentials that allow portlets to log in to applications outside
the realm on behalf of the user. It manages multiple identities for portlets and users.
Related tasks:
Migrating additional components

When you want to migrate artifacts individually in a development environment, choose from the
following topics, depending on your migration scenario.
Migrating composite applications

You can migrate composite applications created with IBM WebSphere Portal Version 6.0.1.4 or later to
your WebSphere Portal Version 7.0 environment. When you migrate a WebSphere Portal Version 6.0.1.4 or
later environment, composite applications are also migrated. You can choose to migrate composite
applications independently of the core portal migration. Optionally, during core portal migration, you can
suppress the migration of composite applications.
Preparing to migrate composite applications:
Understand the following restrictions before you migrate composite applications:

v Templates for composite applications cannot be migrated using the migration tasks. However, you can
manually migrate application templates by using the template Export and Import tasks that are
available from the Application Template Library.
Follow the procedure for Deploying a template to another server to export template definition files from
the source portal server running WebSphere Portal Version 6.0.1.4 or later, and copy and import the
template definition files to the target portal server running the new version of WebSphere Portal.
Migrating 1475
v The backend data of business components is not migrated. Therefore, you must explicitly transfer
business component backend data as explained in the prerequisite checklist below.
Complete the following prerequisites before you migrate composite applications:

1. On the source WebSphere Portal server, enable scripting for composite applications:
a. Create the file PortalServer_root/shared/app/config/services/ScriptingService.properties and
add the following line:
ServerExt.applications=com.ibm.wps.scripting.server.ApplicationServerExtensions
b. In the file wp_profile_root/config/cells/cell/nodes/node/libraries.xml, locate the stanza for
WPSlib. It should look like the following:
Change it to look as follows:
<classPath>${WPS_HOME}/shared/app/scripting/ai.xml.api.script.jar</classPath>
<classPath>${WPS_HOME}/shared/app/scripting/ai.xml.impl.script.jar</classPath>
c. Specify the path of the scripts:
Windows: In the file PortalServer_root\bin\wpscript.bat, add the line:
set SCRPATH=%SCRIBS%\scripting\wp.script.jar;%SCRIBS%\scripting\wp.link.jar;
%SCRIBS%\wp.base.jar; %SCRIBS%\wp.model.api.jar;
%SCRIBS%\wp.user.api.jar;%SCRIBS%\wp.cmd.base.jar;%
UNIX: In the file PortalServer_root/bin/wpscript.sh, add the line:
set SCRPATH=%SCRIBS%/scripting/wp.script.jar;%SCRIBS%/scripting/wp.link.jar;
%SCRIBS%/wp.base.jar; %SCRIBS%/wp.model.api.jar;
%SCRIBS%/wp.user.api.jar;%SCRIBS%/wp.cmd.base.jar;%
2. On the source WebSphere Portal server, check the settings in the file PortalServer_root/config/
wpconfig.properties:
a. Make sure that the passwords are set for WasPassword and PortalAdminPwd.
Important: If the WasUserid is different from the PortalAdminId, you must add the WasUserid to the
portal administrator group wpsadmins. An interim fix will be available soon to correct a problem
with Portal Login to the scripts that support the composite application migration tasks. Until the
interim fix is available, if you do not add WasUserid to the portal administrator group wpsadmins,
the migration tasks for composite applications will not work properly.
b. Find the SOAP port number. You will need to know the SOAP port number for Step 4b.
3. Restart the source WebSphere Portal server.
4. At least once before you migrate composite applications, run the wsadmin tool with the option to
establish a SOAP connection from the new, target WebSphere Portal server to the source WebSphere
Portal server. The IBM WebSphere Application Server administration scripting tool must work and a
SOAP connection must be established between the portal servers to update SSL trust store because the
migration task migrate-ai-export uses the Portal Scripting Interface commands for the backing up
and restoring composite applications. The Portal Scripting Interface is based on the wsadmin tool.
a. On the new WebSphere Portal server, open a command prompt and change to the directory
AppServer_root/bin/.
b. Type the following command:
wsadmin -host portalversion6014_hostname -conntype SOAP -port
portalversion6014_SOAPport_number -user was_userid -password was_password

Note: The wsadmin tool might display a warning about a version mismatch between the two
servers. This warning does not affect the operation of the tool and can be disregarded.
c. Review the SSL Signer Exchange Prompt information that is displayed in the console and verify
that the digest value matches what is displayed at the server:
Subject DN
Issuer DN
Serial Number
Expires
SHA-1 Digest
MD5 Digest
d. At the prompt Add signer to the trust store now?, type Y. Confirmation is displayed as
Connected to process WebSphere Portal on node portalversion6014_host_node_name using SOAP
connector.
e. After you receive confirmation that the SOAP connection is established between the portal servers,
at the wsadmin prompt, type exit.
5. Before you run either task, portal-pre-upgrade or migrate-ai-export, make sure that the source
WebSphere Portal server is running and that the file PortalServer_root/config/wpconfig.properties
specifies the values for the properties WasPassword and PortalAdminPwd.
6. Before you run either task, portal-post-upgrade or migrate-ai-import, make sure that the target
WebSphere Portal Version 7.0 server is running and that the file wp_profile_root/ConfigEngine/
properties/wkplc.properties specifies the values for the properties WasPassword and PortalAdminPwd.
7. Ensure that all portlet applications that are rendered on the pages of composite applications in the
source environment are installed on or migrated to the new WebSphere Portal environment before
you migrate the composite applications. If the target environment does not already have available the
portlets used by the composite applications, the migration of the composite applications will fail.
v Although the core portal migration tasks automatically migrate portlet applications, as explained in
Understanding migration, you will want to verify that all portlet applications needed by migrated
composite applications are available.
v Also refer to the topic Migrating deprecated portlets to confirm whether the composite applications
that you intend to migrate contain portlets that are removed in WebSphere Portal Version 7.0. This
topic explains how deprecated portlets are handled for transition after migration.
8. Ensure that you have explicitly transferred the backend data of the business components of composite
applications. The migration tasks for composite applications will not migrate the backend data of
business components, for example, the contents of a Web Content Manager document library.
v If the business components of an application store data in the WebSphere Portal Community
database domain, then consider using the XML Configuration Interface to transfer the backend data
from the source environment to the target environment. For example, in the case of Web Content
Manager document libraries, you might want to copy the entire WebSphere Portal Version 6.0x Java
Content Repository (JCR) to the WebSphere Portal Version 7.0 environment or configure the
WebSphere Portal Version 7.0 environment to use the Version 6.0x JCR.
v If application business components store data in repositories that are external to the WebSphere
Portal configuration, you cannot use the XML Configuration Interface and will need to use another
method of explicitly migrating application component data.
Now you are ready to run the migration tasks for composite applications.
Migrating 1477
Related concepts:
“Understanding migration” on page 1405
“The XML configuration interface” on page 1876
Use the XML configuration interface for exchanging portal configurations.
“Migrating deprecated portlets” on page 1482
Some previously available portlets have been removed from IBM WebSphere Portal Version 7.0 because
alternative or newer functionality is available that you can use instead. If you migrate from an earlier
portal installation that used these portlets, the portlets are migrated to provide backward compatibility,
but they are treated as third-party portlets. Users are encouraged to transition to other available
technology as appropriate.
Related tasks:
“Using scripts for composite applications” on page 2439
As an alternative to using the administrative portlets, you can use the composite application scripts
provided by the Portal Scripting Interface to retrieve application metadata; to backup, archive, and restore
applications; and to delete obsolete categories for templates and applications. The scripts for managing
application lifecycle (backup, archive, restore, delete) can be automated to run at specific times using the
scheduling utility provided by your operating system.
“Deploying a template to another server” on page 2418
Deploy an application template to another sever by exporting and importing the template definition file
from the source server to the target server. Use the Application Template Library on the source server to
export the template definition file. Use the Application Template Library on the target server to import
the template definition file.
Wsadmin tool
Recommended fixes and updates for WebSphere Portal and Web Content Management
Suppressing migration of composite applications:
tasks.
To suppress the migration of composite applications during core portal migration, follow these steps:
1. To suppress the back up and export of composite application artifacts and data of the source portal
environment, run the portal-pre-upgrade task and specify the parameter DSkipAiMigration=true.
Windows: WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname
-DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid
-DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword -DGroupExport=true
-DSkipAiMigration=true

UNIX: ./WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname
-DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid
-DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword -DGroupExport=true
-DSkipAiMigration=true
i: WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname
-DGroupExport=true -DSkipAiMigration=true
2. To suppress the importing of composite application artifacts and data into the target portal
environment, run the portal-post-upgrade task and specify the parameter DSkipAiMigration=true.
Some parameters might be optional for your portal environment:
Windows: WPmigrate.bat portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid
-DPortalAdminPwd=adminpassword -Dmigration.vmm.database.admin.password=vmmdminpassword
-Dmigration.wmm.database.admin.password=wmmadminpassword -DoldProfile=oldserverprofilename
-DprofileName=newserverprofilename -DSkipAiMigration=true
UNIX: ./WPmigrate.sh portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid
i: WPmigrate.sh portal-post-upgrade -DbackupDirectory=dirname -DPortalAdminId=adminid
Related concepts:
Related tasks:
“Importing configuration for migration to a remote machine” on page 1468
To import backed-up artifacts and content that were exported from IBM WebSphere Portal V6.0.1.x, use
the WPmigrate script to run the portal-post-upgrade task.
Related reference:
Technote 1300236
work.
Running migration tasks for composite applications:
Migrating 1479
To migrate composite applications independently of the core portal migration tasks, follow these steps on
the source portal server and target portal server:
Important: Always use the forward slash (/) as the path delimiter when specifying the values of the
parameters DbackupDirectory and DcurrentPortalDirectory regardless of the operating system. If you
fail to do this, the WPmigrate.bat migrate-ai-export task will indicate timeouts.
Run WPmigrate with the portal-pre-upgrade and portal-post-upgrade tasks.

1. To back up and export the composite application artifacts and data of the source portal environment,
run the following task:
Windows: WPmigrate.bat migrate-ai-export -DbackupDirectory=dirname_exported_application_data
-DcurrentPortalDirectory=dirname_version6014_portal_server
UNIX: ./WPmigrate.sh migrate-ai-export -DbackupDirectory=dirname_exported_application_data
i5/OS: WPmigrate.sh migrate-ai-export -DbackupDirectory=dirname_exported_application_data
2. To import the backed-up artifacts and data that you exported in Step 1 into the target portal
environment, run the following task:
Windows: WPmigrate.bat migrate-ai-import -DbackupDirectory=dirname_exported_application_data
UNIX: ./WPmigrate.sh migrate-ai-import -DbackupDirectory=dirname_exported_application_data
i5/OS: WPmigrate.sh migrate-ai-import -DbackupDirectory=dirname_exported_application_data
3. After you complete the previous steps, run the script that resolves references to application categories
and template names in the business rules that are defined for application policies. If you do not run
the $Application migratepznrules script and you have defined policies for composite applications in
your source environment, the application policies will not work in the target environment because the
policy rules defined for composite applications will not be available. The script can be invoked
multiple times and will only modify policy rules if it can resolve references to application categories
and template names. Only policy rules for composite applications are modified; other business rules
defined and controlled by the Personalization component are not affected.
a. Change to the directory PortalServer_root/bin and invoke the Portal Scripting Interface for your
operating system using the appropriate command and administrator credentials:
Windows: wpscript.bat -user portal_administrator_userID -password
portal_administrator_password
UNIX: ./wpscript.sh -user portal_administrator_userID -password
i5/OS: wpscript.sh -user portal_administrator_userID -password
b. Run the following scripts:
$Portal login portal_administrator_userID portal_administrator_password
$Application migratepznrules
c. When you have finished running the scripts, log out:
$Portal logout
4. When you have finished migrating composite applications, verify the expected results:
a. Check the migration log.
b. Open the Template Library and the Application Library in the target environment (the upgraded
portal site) and verify that all composite application artifacts and data from the source
environment are available and working as expected.
c. If you discover that some application artifacts or data did not migrate completely or properly,
restore the artifacts or data from the source environment by either copying resources or resetting

properties. For example, applications marked as Favorites in the source environment lose this
designation when they are migrated. You will need to mark applications as Favorites again in the
upgrade portal environment.
Related concepts:
“Working with the Portal Scripting Interface” on page 1926
Learn more about the different modes that you can use with the Portal Scripting Interface.
Related tasks:
“Preparing to migrate composite applications” on page 1475
“Migrating a Version 6.0.1.x product configuration” on page 1453
“Exporting configuration for migration to a remote server” on page 1463
Using composite applications in a migrated virtual portal:
Before using composite applications in a migrated V6.0.1.x virtual portal, you need to run an additional
configuration task to create root folders for templates and applications, and then import the composite
application templates that you want to work with.
1. Change to the wp_profile_root/ConfigEngine directory and then run the command below:
v Windows: ConfigEngine.bat upgrade-virtual-portal-for-ai -DWasUserid=username
-DWasPassword=password -DPortalAdminId=username -DPortalAdminPwd=password
-DVirtualPortalContext=vp_context
v UNIX: ./ConfigEngine.sh upgrade-virtual-portal-for-ai -DWasUserid=username
v i: ConfigEngine.sh upgrade-virtual-portal-for-ai -DWasUserid=username
where VirtualPortalContext or VirtualPortalHost identifies the virtual portal context. For example,
executing the following command creates root folders for templates and applications in virtual portal
vp1:
./ConfigEngine.sh upgrade-virtual-portal-for-ai -DVirtualPortalContext=vp1
2. Use the Template Library to import the composite application templates that you want to work with
in the virtual portal.
Related tasks:
“Using the Application Template Library” on page 2412
The Application Template Library displays all templates that are available to you, sorted alphabetically by
template name. Use the Application Template Library to create new application templates, import
application templates, and manage application templates.
Migrating V6.0.x personalization data

To migrate Personalization data from an IBM WebSphere Portal Version 6.0.x environment to a Version
7.0 environment, follow the procedures for Migrating Web Content Management Version 6.0. Running the
migration tasks for Web Content Management will migrate all Personalization data. You can also publish
portal content filtered by means of the Personalization engine and rules between WebSphere Portal
Version 6.0.x and Version 7.0 environments.
Migrating 1481
Before you migrate Personalization data from a WebSphere PortalVersion 6.0.1.x environment, you must
connect to a copy of the JCR database domain of the source portal environment as described in Sharing
Version 6.0.1.x JCR domain data.
Related concepts:
“Personalization rules” on page 2983
WebSphere Portal Personalization sends published rules across HTTP to a servlet which resides on each
personalization server. This servlet can receive publishing data or initiate new publishing jobs. When a
user begins a publishing job from the personalization authoring environment, the local servlet is provided
with the set of information necessary to complete the job. The local servlet contacts the destination
endpoint servlet (which could be the same servlet) and sends its data to it. The destination servlet reports
success or failure.
Related tasks:
“Reusing V6.0.1.x JCR domain data” on page 1430
To migrate from IBM WebSphere Portal V6.0.1.x, you must connect to a copy of the earlier portal's JCR
database domain before running the migration tasks. The migration process uses the earlier portal data,
converting it for use with the new, target portal. Once the data is converted, it can no longer be used by
the earlier portal.
Migrating deprecated portlets

Some previously available portlets have been removed from IBM WebSphere Portal Version 7.0 because
alternative or newer functionality is available that you can use instead. If you migrate from an earlier
portal installation that used these portlets, the portlets are migrated to provide backward compatibility,
but they are treated as third-party portlets. Users are encouraged to transition to other available
technology as appropriate.
Deprecated business portlets

Some business portlets that were provided in earlier versions of IBM WebSphere Portal are deprecated in
Version 7.0 because there are other portlets available that provide similar functionality.
The table below lists the business portlets that have been removed from the current version of IBM
WebSphere Portal and identifies available portlets that you can use instead.
Table 390. A list of business portlets that have been removed from the current WebSphere Portal version
Deprecated portlet Alternative portlet
CSV Viewer Document Viewer
File Server Web Clipper
JSP Server Information
IBM My Lists IBM Reminder
IBM Newsgroup IBM Syndicated Feed
RSS IBMSyndicated Feed
IBM Feed Reader IBMSyndicated Feed
IBM Quicklinks IBM Bookmarks
Servlet Invoker IBM Web Page
IBM Application Portlet for Microsoft NetMeeting Not applicable. NetMeeting has been phased out by
Microsoft.
If you used these deprecated portlets in your earlier portal server, they are made available when you
migrate to the new portal server, but they are not supported.

Deprecated collaborative portlets
Some collaborative portlets that came with earlier versions of IBM WebSphere Portal are not provided in
Version 7.0. These deprecated portlets include My Lotus QuickPlaces, Inline QuickPlace, Domino
Document Manager, and Lotus Web Conferencing.
Although My Lotus QuickPlaces is no longer included in the product, you can download the portlet from
the WebSphere Portal Catalog. For this reason, if you migrate from an earlier version of WebSphere Portal
where My Lotus QuickPlaces was deployed, migration transfers the earlier version of this portlet to the
new portal server. You can then upgrade the portlet by downloading the WAR file from the WebSphere
Portal Catalog.
Inline QuickPlace, Domino Document Manager, and Lotus Web Conferencing are not migrated; if needed,
you can download these portlets from the WebSphere Portal Catalog.
Related tasks:
“Migrating My Lotus QuickPlaces”
My Lotus QuickPlaces, which was provided in earlier versions of IBM WebSphere Portal, is now available
only by download from the WebSphere Portal Catalog. If you migrate from an earlier portal installation
where My Lotus QuickPlaces was deployed, the earlier portlet is migrated to the new portal server. To
upgrade the portlet, you must download the new portlet WAR file from the Catalog.
IBM WebSphere Portal Catalog
Migrating My Lotus QuickPlaces

My Lotus QuickPlaces, which was provided in earlier versions of IBM WebSphere Portal, is now available
only by download from the WebSphere Portal Catalog. If you migrate from an earlier portal installation
where My Lotus QuickPlaces was deployed, the earlier portlet is migrated to the new portal server. To
upgrade the portlet, you must download the new portlet WAR file from the Catalog.
Steps for migrating My Lotus QuickPlaces are outlined below:

1. Run the portal-pre-upgrade task to export configuration information from the earlier portal server.
2. Run the portal-post-upgrade task to import the earlier server's configuration information to the new
portal server.
3. Verify that the My Lotus QuickPlaces portlet has been deployed on the new portal server.
4. Download the new portlet WAR file from the WebSphere Portal Catalog.
5. Upgrade My Lotus QuickPlaces with the new WAR file.
6. Verify the portlet settings.
Related reference:
“Deprecated collaborative portlets”
Some collaborative portlets that came with earlier versions of IBM WebSphere Portal are not provided in
Version 7.0. These deprecated portlets include My Lotus QuickPlaces, Inline QuickPlace, Domino
Document Manager, and Lotus Web Conferencing.
IBM WebSphere Portal Catalog
Migrating documents from Portal Document Manager to Quickr

Document Libraries
With IBM WebSphere Portal Version 6.1, Document Manager components are no longer installed with the
product. Document Manager features are now consolidated in IBM Lotus Quickr to provide improved
performance, scaling, and modularity; and to align with the unified strategy for document management
solutions.
Migrating 1483
Entitlements to Lotus Quickr within the WebSphere Portal offerings
The WebSphere Portal offerings now include two entitlements to Lotus Quickr. One of these entitlements
is available specifically for the offerings and products whereby WebSphere Portal Document Manager is
replaced with Lotus Quickr Document Libraries:
WebSphere Portal Enable
WebSphere Portal Express
IBM Content Accelerator
For more information on entitlements included with the offering or product you have purchased, go to
the IBM Software license agreements search site, enter the offering or product name in the Search criteria
field, and click the Search icon.
Benefits of moving documents to Lotus Quickr document libraries
Consider the benefits of replacing WebSphere Portal Document Manager with Lotus Quickr Document
Libraries:
v Scaling and performance
Because WebSphere Portal can only run in one Java Virtual Machine (JVM), additional embedded
components such as Document Manager can affect server performance negatively. Removing a large
service like Document Manager and entitling it to run on a separate, dedicated JVM will deliver
improved portal and content performance and scalability.
v Modularity
Analysis of customers using WebSphere Portal Document Manager indicates, among other
observations, that many customers deploy WebSphere Portal Document Manager to a subset of their
total portal user base. By installing Lotus Quickr on a separate system, you can deploy document
libraries in a way that affects only those users who need this capability.
v Strategic endurance
Lotus Quickr is the product that now unifies all previous document management solutions across the
IBM Lotus Domino and WebSphere Portal offerings. For this reason, WebSphere Portal Document
Manager is no longer available starting with WebSphere Portal Version 6.1.
Important: The Microsoft Windows and Microsoft Office connectors for WebSphere Portal Document
Manager are not supported for use with Lotus Quickr. At this time, the equivalent Lotus Quickr
Connectors are not entitled with any WebSphere Portal offering. Therefore, upgrading to the full Lotus
Quickr product is required.
General process for moving documents to Lotus Quickr document libraries
To replace WebSphere Portal Document Manager components with Lotus Quickr Document Libraries,
follow this general process:
1. Install Lotus Quickr Services for WebSphere Portal separately from WebSphere Portal.
There are multiple ways to achieve this, including installing Lotus Quickr on a separate logical or
virtual partition from the portal server or on a different physical server.
2. Use the Document Library template that is included in Lotus Quickr Services for WebSphere Portal.
3. After the Lotus Quickr server is installed, delete all templates except the Document Library template
from the server.
This is important because the IBM WebSphere Portal license does not entitle you to use other
templates on the Lotus Quickr server.

Note: Installing the WebSphere Portal Document Manager migration tool (described below) adds a
template that is a child of the Document Library template; this template is not subject to the
restriction above.
4. Establish single sign-on (SSO) capability between the Lotus Quickr server and the WebSphere Portal
server.
5. For complete information, refer to the IBM Lotus Quickr Information Center.
Migration and integration of document management solutions
If you are storing documents in WebSphere Portal Document Manager V5.1 or V6.0, you can use the
WebSphere Portal Document Manager migration tool to migrate library content from WebSphere Portal
Document Manager to Lotus Quickr services for WebSphere Portal. For detailed information on this
utility, see Document #4022083, WebSphere Portal Document Manager migration tool.
If you are storing documents in WebSphere Portal Document Manager from previous releases and they
are referenced by Web Content Manager, be aware that while you can store files and content outside of
Web Content Manager – for example, in Lotus Quickr – and link to them from Web Content Manager,
this technique does not provide complete integration. A future release of Web Content Manager will
support full-scale integration with Lotus Quickr.
Additionally, a migration utility will be available in the future to move documents from WebSphere
Portal Document Manager into Web Content Manager while still providing link integrity to the
documents. Details on this planned migration utility, its availability, and documentation, will be
announced as they become available.
Options for integrating Lotus Quickr within WebSphere Portal
Consider the ways in which you can integrate Lotus Quickr within the context of WebSphere Portal:
Table 391. Options for integrating Lotus Quickr
Integration option Description Reference
IBM My Places Portlet The My Places portlet provides a Download the My Places Portlet from
more integrated way to work with a the IBM WebSphere Portal Business
personalized list of Lotus Quickr Solutions Catalog.
places to which a user has access.
From the My Places portlet, you can http://catalog.lotus.com/wps/
display all Lotus Quickr places that portal/portal/
you are a member of, public places, details?catalog.label=1WP1001GJ
all places to which you have access,
and places that you have marked as
Favorites. Display a place by clicking
a place link in the My Places portlet.
An administrator can configure the
portlet to retrieve places from specific
J2EE and Domino servers.
Migrating 1485
Table 391. Options for integrating Lotus Quickr (continued)
IBM Feed Reader Portlet Any page within Lotus Quickr can be Download the Feed Reader Portlet
rendered as an ATOM feed. The IBM from the IBM WebSphere Portal
Feed Reader portlet enables users to Business Solutions Catalog.
read RSS and Atom feeds from
various content providers, including http://catalog.lotus.com/wps/
news, information, and solutions Web portal/portal/
sites. Users can add and delete details?catalog.label=1WP1001GK
multiple feeds from various content
providers. This portlet supports basic
authentication and time-out
parameters. The portlet also supports
proxy authentication. The IBM Feed
Reader portlet is AJAX-based,
providing improved client-side
performance.
To consume Lotus Quickr pages

within the context of a WebSphere
Portal page, direct the Feed Reader
portlet to Lotus Quickr content.
IBM WebSphere Portal - Lotus Quickr This integrated person card enables Download the IBM WebSphere Portal
and IBM Lotus Connections WebSphere Portal and Lotus Quickr - Lotus Quickr and IBM Lotus
Integrated Person Card users to link to the features of Lotus Connections Integrated Person Card
Connections, from within a person from theIBM WebSphere Portal
card. Integrating the person card Business Solutions Catalog.
information from Lotus Connections
with the person card information http://catalog.lotus.com/wps/
from WebSphere Portal or Lotus portal/portal/
Quickr allows you link to the Profile, details?catalog.label=1WP1001IW
Communities, Blogs, Bookmarks, and
Activities for a person from within
his or her person card in WebSphere
Portal or Lotus Quickr.
IBM Web Application Integrator for A newer capability for any Web Download the Web Application
IBM WebSphere Portal application, most notably Lotus Integrator for IBM WebSphere Portal
Quickr, is the addition of IBM Web from the IBM WebSphere Portal
Application Integrator. Web Business Solutions Catalog.
Application Integrator for IBM
WebSphere Portal is a solution that http://catalog.lotus.com/wps/
allows external Web applications to portal/portal/
be integrated with WebSphere Portal details?catalog.label=1WP1001IA
Version 6.0x and WebSphere Portal
Express Version 6.0x. The Web Also included in the catalog is
Application Integrator allows documentation on how to implement
WebSphere Portal customers to and configure the Web Application
centralize access to external Web Integrator Portlets.
applications within the enterprise.
Examples of such external Web
applications include home-grown,
in-house Web applications as well as
IBM Web-based products like Lotus
Connections, Lotus Domino Web
Application, and Lotus Quickr.

Table 391. Options for integrating Lotus Quickr (continued)
REST Services Builders for IBM Another area where the entitlement The following articles explain how to
WebSphere Portlet Factory has changed is the ability to utilize use the REST builders to create Lotus
Lotus Quickr APIs to create portlets Quickr portlets:
and widgets within the context of
WebSphere Portal. Lotus Quickr http://www.lotus.com/ldd/
implements many of its features pfwiki.nsf/dx/ibm-using-the-rest-
using a REST-based API, with more service-call-builder
REST-based features planned.
http://www.lotus.com/ldd/
WebSphere Portlet Factory provides a pfwiki.nsf/dx/-creating-a-rest-
set of builders to speed the creation service-call-with-a-wpf-model
of portlets based upon REST.
pfwiki.nsf/dx/ibm-using-rest-style-
service-calls
pfwiki.nsf/dx/ibm-using-the-rest-
service-call-builder
http://www.ibm.com/
developerworks/lotus/library/
quickr-portlet-factory/
Integrating Lotus Quickr into Set up search services for remote “Searching across Lotus Quickr
WebSphere Portal Search Lotus Quickr servers. Then make the servers” on page 2141
services available to Portal Search so
that users can search across content
on all the servers.
IBM WebSphere Portal Document Manager migration tool
Post-migration activities
After migrating from IBM WebSphere Portal V6.0.1.x, additional tasks may be needed depending on how
you customized the earlier portal environment and which components you used.
Verifying migrated repository IDs

Migration re-creates the repositories from the earlier portal in the new portal installation, and overwrites
repository IDs that were used to prepare for migration. After completing migration, use the
wp-query-repository task to check the migrated values of the LDAP repository names. Keep the list for
reference in case you need to update the wkplc.properties file, or to ensure that you specify the correct
repository ID when you execute a security configuration task that requires it.
List the names and types of configured repositories as follows:

v i: Run the configuration task ConfigEngine.sh wp-query-repository -DWasPassword=password from the
directory wp_profile_root/ConfigEngine .
v UNIX: Run the configuration task ConfigEngine.sh wp-query-repository -DWasPassword=password
from the directory wp_profile_root/ConfigEngine .
v Windows: Run the configuration task ConfigEngine.bat wp-query-repository -DWasPassword=password
from the directory wp_profile_root\ConfigEngine .
Verifying migration from V6.0.1.x

Prior to verifying the migration tasks, make sure that all manual migration steps are completed. Then use
the steps described here to verify the success of the migration tasks.
Migrating 1487
To perform the steps below, log in to the IBM WebSphere Portal Administrative Interface for the new
portal installation unless otherwise noted.
1. Verify migration of Notes and iNotes portlets.
a. Under Portlet Management, click Portlets. The portlet list includes an entry for each portlet that
existed in the previously installed version.
b. Select each migrated portlet, click Configure portlet, and verify that the portlet settings were
migrated correctly. If you migrated pages that had Notes portlets in them, the portlets should be
on the page after migration and should work as they did in the earlier version.
In some previous versions of WebSphere Portal, these portlets were individual portlets, while in
the current version, they are copies of one portlet.
2. Verify migration of portal clients.
a. Under Portal Settings, click Supported Clients.
b. Verify that the portal clients that you migrated appear in the list of supported clients.
c. Select each migrated client, click Edit selected client, and verify that all settings for the client
were migrated.
d. Verify that your migrated clients are able to access WebSphere Portal.
3. Verify migration of user customizations. User customizations are attributed to a portal user who has
edit but not manage permissions on a page, and are created when such a user changes the layout of
a page or edits portlet settings.
a. Log in to the new WebSphere Portal using the credentials of users who implemented the
customizations.
b. Verify that all user customizations from the earlier version are present in the new version. You
can also pick users at random and ensure that they see the correct customizations in the new
version by visually comparing the customizations in the new version with those in the earlier
version.
4. Verify migration of credential vault segments and slots.
a. Under Access, click Credential Vault.
b. Using the Manage vault segments and Manage system vault slots options, verify that credential
segments and slots from the earlier version are now also present in the new version.
5. Verify migration of themes and skins.
a. Under Portal user interface, click Themes and Skins.
b. Verify that the themes and skins that are listed are the ones that you migrated from the earlier
version.
c. Verify that you are able to associate migrated themes and skins to existing pages and portlets,
and that they produce the required view.
6. Verify migration of portlet applications.
a. Under Portlet Management, click Applications.
b. Verify that the portlet applications that are listed are the ones that you migrated from the earlier
version.
c. For each Web module, verify that all your portlet applications also display in the Portlet
Applications list.
d. For each portlet application that is migrated and for which you have set up parameters on the
earlier version, click Edit portlet application and verify that the parameters were migrated
correctly.
7. Verify the access control for migrated portlet application and portlets.
a. Under Access, click Resource Permissions and select Portlet Applications from the listed
resource types.
b. Click Assign Access to verify the access control information.
c. Under Access, click Resource Permissions and select Portlets from the listed resource types.

d. Click Assign Access to verify the access control information.
After migration is complete, you can also use the XML Configuration Interface to perform a full
export of the current version and verify that the roles in the exported XML file are correct. For more
information, see the XML configuration interface topic.
8. Verify migration of portlet configuration data.
a. Under Portlet Management, click Portlets.
b. To verify that each portlet's configuration data was migrated from the earlier version, select the
portlet from the list and click Configure portlet.
9. Verify migration of virtual resources.
a. Under Access, click Resource Permissions.
b. Select Virtual Resources from the list of resource types.
c. Verify that all virtual resources migrated from the earlier version are present in the new version.
10. Verify migration of pages.
11. If you migrated from WebSphere Portal V6.0.1.x and your portal environment security uses IBM
WebSphere Application Server standalone, ensure that both portal environments use the same
external ID: (extID): <config:externalIdAttributes name="distinguishedName"/>
a. On the earlier portal, check how extID is defined in portal_server_root/wmm/
wmmLDAPServerAttributes.xml.
b. On the new portal, check how extID is defined in wp_profile_root/config/cells/cell_name/wim/
config/wimconfig.xml by looking at config:externalIdAttributes inside config:repositories
xsi:type="config:LdapRepositoryType".
12. Ensure that the entities (users or groups) that were defined in WMM on the 6.0.x system are now
associated with existing entities in VMM. To resolve instances where a specified attribute value refers
to a non-existing entity, you can either perform the required cleanup or flag the properties as
unsupported. For more information, see Technote 1326687.
Technote 1326687
Ensuring proper Search behavior after migration

After you finish migrating your product configuration to the new portal environment, some manual
adjustment is required to ensure that the Search Center functions properly on the new portal.
1. Extract the MigratedThemes EAR from IBM WebSphere Application Server using the administrative
console.
2. Expand the EAR to a directory using the EARExpander command in the was_profile_root/bin directory.
3. In the path_to_expanded_ear/MigratedThemes.ear/MigratedThemes.war/themes/html/
name_of_migrated_theme directory, locate banner_searchControl.jspf, create a backup copy of the file,
and then delete banner_searchControl.jspf.
4. In the PortalServer_root/installer/wp.ear/installableApps/wps_theme.ear/wps_theme.war/themes/
html/Portal directory, locate banner_searchControl_for_migrated_themes.jspf and copy it to the
path_to_expanded_ear/MigratedThemes.ear/MigratedThemes.war/themes/html/
name_of_migrated_theme directory. Then, change the file name to banner_searchControl.jspf.
5. Repackage the MigratedThemes.war file, repackage the MigratedThemes.ear file, and deploy the EAR
in WebSphere Application Server using the administrative console.
6. To recompile Default.jsp under wp_profile_root/installedApps/node_name/MigratedThemes.ear/
MigratedThemes.war/themes/html/name_of_migrated_theme and incorporate the updates to the other
JSP files, enter:
touch Default.jsp
Migrating 1489
WebSphere Application Server: EARExpander command
Addressing inadvertent changes to the default theme

Pages that ship with the current version use a default theme. The default theme makes it easy to rebrand
the portal by assigning a new theme as the default. Administration pages are exceptions and are
explicitly assigned the default Portal theme. Doing so ensures that the Administration pages will continue
to work correctly if a non-functional theme is inadvertently applied as the default theme.
When you migrate themes to the current version, the default theme assignment from the earlier version is
retained and applied to the pages that shipped with the current version.
If you migrate themes from an earlier version and then experience problems with a page that ships with
the current version, assign the Portal theme to the page.
If the page works correctly with the Portal theme and not with the migrated theme, there might be
functional incompatibilities between the markup in the migrated theme and the content of the portlets.
Portlets on these pages might also be dependent on new function in the current version that did not exist
in the earlier version. If so, you might need to copy files from the Portal theme into the migrated theme.
Removing obsolete pages in virtual portals

When you migrate a virtual portal, IBM WebSphere Portal treats all pages in the portal as custom,
customer-created content. As a result, if the virtual portal contains pages that are associated with features
that are not available in the new installed version, WebSphere Portal migrates those pages regardless.
For example, if you migrate a virtual portal that contains a Document Libraries page, WebSphere Portal
preserves that page even though document libraries were removed from WebSphere Portal starting with
Version 6.1. You can remove these pages manually, after migrating the virtual portal.
Deploying the Directory Search portlet

In environments that are configured for multi-realm support, after migrating a virtual portal, you must
perform an additional task to ensure that the Directory Search portlet functions properly in the new
portal.
Complete the steps below for each migrated virtual portal.

1. Change to the following directory:
Windows: wp_profile_root\PortalServer\bin
UNIX: wp_profile_root/PortalServer/bin
i: wp_profile_root/PortalServer/bin
2. Run the following command:
v Windows:
xmlaccess.bat -in PortalServer_root\people\people.impl\picker\portal.scripts\DeployPages.xml -url http://servername:serverport/wps/config/VPContext -use

v UNIX:
./xmlaccess.sh -in PortalServer_root/people/people.impl/picker/portal.scripts/DeployPages.xml -url http://servername:serverport/wps/config/VPContext -us

v i:
xmlaccess.sh -in portal_server_root/people/people.impl/picker/portal.scripts/DeployPages.xml -url http://servername:serverport/wps/config/VPContext -use
Version 6.0 post migration steps for web content

Once you have completed the WebSphere Portal migration steps, you need to perform these additional
steps to complete your web content migration.

Mandatory post migration steps
After migrating from version 6.0.x, run the update-wcm-data task from the wp_profile_root/
PortalServer/migration directory of your Version 7.0 server:
Windows
WPmigrate.bat update-wcm-data -DWasUserId=username -DWasPassword=password
-DPortalAdminId=username -DPortalAdminPwd=password -DbackupDirectory=directory
UNIX ./WPmigrate.sh update-wcm-data -DWasUserId=username -DWasPassword=password
i WPmigrate.sh update-wcm-data -DWasUserId=username -DWasPassword=password
Once your have performed these steps, review the following optional post migration steps and update
your system as required.
JSP files and Web content plugins.

v Any JSP files used on your old system will need to be manually copied to your new system.
v Any Web content plugins used on your old system, such as custom workflows, will need to be
manually copied to your new system and enabled.
Search Indexes
You will need to rebuild your search indexes after migrating to Version 7.0:
1. Stop your server.
2. Delete all the index directories under wp_profile_root/PortalServer/jcr/search
3. Restart the portal server
4. The search indexes should be rebuilt the next time the index maintenance interval is reached.
5. If the index directory is not built, edit a document and save it, and tray manually rebuilding the
search index.
Remote rendering portlets
If you migrated the IBM API rendering portlets, you must update the migrated remote rendering portlets
to Version 7.0:
1. Log in to your migrated server as an administrator.
2. Go to the Administration view and then Portlet Management.
3. Select Web Modules.
4. Click Update.
5. Click Browse.
6. Select the file called ilwwcm-remoterendering-portlet.war from the PortalServer_root\wcm\
prereq.wcm\installableApps folder of your Version 7.0 server. This must be a content server
installation as this file is not installed on an administration server installation.
7. Click Open.
8. Click Next.
9. Click Finish.
The configuration settings of your remote rendering portlets on remote servers will be unchanged after
you have migrated your servers. If your migrated servers use the same naming conventions as your old
servers, then you will not have to re-configure your remote rendering portlets. If you have changed the
Migrating 1491
naming conventions of your migrated server, such as giving your migrated cluster a different name than
your old server cluster, then you will have to re-configure your remote rendering portlets.
Note: The migrated portal URL takes this form:

For example, if your original portal URL is http://www.example.com:10040/wps/portal, the URL for the
migrated portal is http://www.example.com:10040/wps_migrated/portal
If you have a small number of remote rendering portlets, you can edit the configuration settings of your
remote rendering portlets manually. If you have a large number of remote rendering portlets, then you
can use the XML configuration interface to re-configure your remote rendering portlets. To do this you
will have to export the pages containing your remote rendering portlets:
v You can use the XML configuration interface (xmlaccess command) to export the remote rendering
portlet web application and all related portal pages.
v You can also use the Export Pages portlet in the portal's administration to export the entire page
hierarchy containing the remote rendering portlets.
Once exported, change the value of the WCM_REMOTE_HOST_BASE_PATH variable for all the portlets to Version
7.0 servers. This updated XML file can then be imported using the xmlaccess command or the Import
XML portlet.
If you are migrating from version 6.0.x, a full export is also performed during a full WebSphere Portal
migration, so your remote rendering portlet changes can also be made to the allout.xml file before
running the portal-post-upgrade task.
Authoring portlet access changes from version 6.0 to 7.0
There are a number of authoring access control features which you need to plan for and implement as
part of your migration. Usage of these features depends on what pattern of authoring access control you
require.
In Version 7.0 access permissions that are set on the library are by default automatically inherited by each
new item created in the library. In previous versions, access permissions were not automatically inherited
by new library items. When you migrate content to a Version 7.0 server, the access permissions
inheritance on migrated items will not have changed. If you decide that you want to enable automatically
inherited access permissions, you will need to:
v Review your library access permissions controls and ensure propagation is enabled for your libraries.
v Enable automatic access permissions inheritance by editing the WCM WCMConfigService service and
setting default.inherit.permissions.enabled to "true". See Web content authoring options for further
information.
v As this will only apply to items created after you enable automatic access permissions inheritance, you
must also edit your existing items so that access permissions inheritance is enabled. You can also
remove existing permissions that are set at an item level, but that can now be inherited. This can be
done using one or a combination of the following methods:
– To update the access permissions for all items or all items of a given type, use the Update Security
administration task. See Using the Update Security task.
– To update the access permissions for multiple items at once, use the batch-editing access form. See
Batch-editing access controls.
– To update the access permissions for a single item, use the access section of the item form.
If you decide that you do not want to enable automatically inherited access permissions, you will need
to:

v Disable automatic access permissions inheritance by editing the WCM WCMConfigService service and
setting default.inherit.permissions.enabled to "false". See Web content authoring options for further
information.
Note: It is recommended that you use automatically inherited access, since this new feature greatly
simplifies administrating library access.
In previous versions, to access item type views in the authoring portlet the user required "contributor"
access in a library's item types settings. "User" access on the library's item type settings did not give users
access to anything in the authoring portlet. In Version 7.0, the user only requires "user" access on the
library's item type settings to access item type views in the authoring portlet. Therefore users with "user"
access to the library's item type settings who don't require access to these views in the authoring portlet
should have their "user" access removed from the library's item type settings.
The wcmadmins group changes from version 6.0 to 7.0
If you used the wcmadmins group in 6.0 you should be aware that wcmadmins does not automatically
have administrator access in Version 7.0. When you migrate from version 6.0 to 7.0, the wcmadmins
group will be migrated, but the members of this group will not have administrator access to web content.
To grant the members of your old wcmadmins group administrator access to web content you must
either assign the wcmadmins group, or the individual members of wcmadmins, to the administrator role
on your migrated web content library.
HTML encoding changes from version 6.0 to 7.0
In Version 7.0, reserved HTML characters stored in some elements are converted into character entities.
For example, '<' will be converted to '<'. This is useful if you would like to prevent users adding
malicious code, or if you want to prevent users changing the look and feel of their text using HTML. This
behavior is enabled by default. To disable this behavior you edit the WCM WCMConfigService service and
set this value to "false":
cmpnt.htmlEncodeDefault=false
Caching changes from version 6.0 to 7.0
The default resourceserver.maxCacheObjectSize setting in the WCM WCMConfigService service has been
reduced from 10000 kilobytes to 300 kilobytes to maximize cache performance.
Menu component changes from version 6.0 to 7.0
In Version 7.0, menus will return no search results if you select a search criteria but don't enter any
search parameters. For example, if the menu is configured to return results based on categories, but no
categories are specified in the menu form, then no matches will be found. In previous versions, menu
searches would ignore any selected search criteria without search parameters. You need to fix any
migrated menus that contain search criteria without search parameters. You can also configure menus to
use the search behavior available in previous versions by setting menu.executeWhenCriteriaEmpty to
"true" in the WCM WCMConfigService service.
Authoring tool component tag changes from version 6.0 to 7.0
You no longer need to use an authoring tool component tag to reference authoring tool components in
menu or navigator designs. Instead, you can use a component tag with a parameter of compute="always".
For example:
[Component name="authoringtoolname" compute="always" ]
Existing authoring tool component tags will still function correctly in your migrated data.
Migrating 1493
Expired item changes from version 6.0 to 7.0
In version 6.0, items that had no expire date specified would never expire. In Version 7.0 this has been
changed so that items with no expire date will be expired as soon as an expire action is triggered. You
can configure your Version 7.0 server to use the behavior available in previous versions by setting
expire.blankdate.immediately to "false" in the WCMConfigService.properties file.
Related tasks:
“Exporting configuration for migration to a remote server” on page 1463
Configuring resource management for site management

To ensure that the portal can retrieve metadata information for resource management on remote systems
after migration, configure the Resource Manager portlet with information about the remote system and
the settings used to handle communication with the system.
Because the Resource Manager portlet uses the AJAX proxy component to access the remote system, you
can use the global AJAX proxy configuration to customize the outgoing HTTP traffic, such as applying
specific HTTP timeout values or configuring an outbound HTTP proxy server. You must list the
individual content management servers to be accessed through the Resource Manager portlet as allowed
request targets in the AJAX proxy configuration, and enable LTPA cookie forwarding for those requests.
To do this, map the URL patterns for the content management server to the resource_manager_policy
dynamic policy using the WP ConfigService configuration service.
1. Log in to the WebSphere Application Server administrative console.
2. Click Resources > Resource Environment > Resource Environment Providers.
3. Click WP ConfigService.
4. Under Additional Properties, click Custom Properties.
5. Click New, and enter the property name
wp.proxy.config.urlreplacement.resource_manager_policy.suffix, and set the string value to the
URL pattern of the content management server; for example http://server:port/*.
For example, to enable the Resource Manager portlet to access information from the remote server
over HTTP, you would add the following property:
wp.proxy.config.urlreplacement.resource_manager_policy.1=http://server:port/*
Note: The value of the property key suffix can be any value as long as it is unique within the set of
keys mapping to the resource_manager_policy dynamic policy.
6. Create additional properties as needed for any other content management servers that you need to
access through the Resource Manager portlet.
7. Optional: If you use an alternative portal context, you need to update the site management portlet as
follows:
a. Click Administration > Portlet Management > Portlets.
b. Select Configure portlet for the Resource Manager portlet.
c. Change the value of proxy.servlet.path to the new portal context value.

8. Optional: The Resource Manager portlet can also consume arbitrary ATOM feeds. To enable this, you
can map the URL prefix of the ATOM feed to the default_policy dynamic policy.
Important: Do not perform this step if you set the resource_manager_policy for the same server by
step 5. above.
a. Click New, and enter the property name
wp.proxy.config.urlreplacement.default_policy.suffix, and set the string value to the URL
pattern of the server providing the ATOM feed.
For example, to enable the Resource Manager portlet to access ATOM feeds from the server
www.example.com, you would add the following property:
wp.proxy.config.urlreplacement.default_policy.1=http://server:port/*
The value of the property key suffix can be any value as long as it is unique within the set of
keys mapping to the default_policy dynamic policy.
Important: To prevent security token forwarding to untrusted servers, be sure that you do not use
the resource_manager_policy dynamic policy for those servers.
b. Create additional properties as needed for any other ATOM feed servers that you need to access
through the Resource Manager portlet.
9. Save your changes and restart the portal server.
Updating custom themes and skins to remove hardcoded context root references
If you have developed custom themes or skins that contain hardcoded references to the portal's context
root, this can cause problems if the context root is changed. This is particularly an issue after migration
because the context root is modified during migration, causing hardcoded references to break. Rather
than modifying your custom themes and skins manually each time you change the context root, you can
update your themes and skins to remove the hardcoded references and instead use dynamic references
that work properly regardless of the context root.
Custom themes and skins that are present in the wps.ear file on the source server prior to migration are
consolidated in the MigratedThemes.ear file on the target server after migration. By starting with
MigratedThemes.ear and modifying the themes and skins, you can then deploy the new EAR and make
the updated themes and skins available to the portal.
1. Extract the MigratedThemes EAR from IBM WebSphere Application Server using the administrative
console.
2. Expand the EAR to a directory using the EARExpander command in the was_profile_root/bin directory.
3. Update the custom themes and skins to remove any hardcoded references to the original context root.
Theme and skin artifacts that could have a hardcoded path include links to JavaScript files, CSS files,
or other JSP files.
Table 392. Examples of how to remove hardcoded references
Include statements of other JSP files in the theme can use Hardcoded example: <%@ include file="/wps/themes/
relative paths. html/ThemeName/head.jspf" %>
Corrected example: <%@ include file="./head.jspf" %>
Migrating 1495
Table 392. Examples of how to remove hardcoded references (continued)
Links to resources within the theme EAR can be Hardcoded examples:
calculated with the findInTheme tag. v <link rel="styleSheet" href="/wps/themes/html/
ThemeName/css/SomeStyles.css" type="text/css" />
v <link rel="styleSheet" href="/wps/themes/html/
css/SomeStyles.css" type="text/css" />
Corrected example:
<%@ taglib uri="http://www.ibm.com/xmlns/prod/
websphere/portal/v6.0/portal-logic"
prefix="portal-logic" %>
<link rel="styleSheet" href=’<portal-
logic:urlFindInTheme file="css/SomeStyles.css"
/>’ type="text/css" />
Links to resources in other EAR files or in a theme with Hardcoded example: <script type="text/javascript"
its own EAR file can use server-relative URLs. src="/wps/themes/html/ThemeName/js/
ThemeJavascript.js"></script>
Corrected example, after the theme is moved to its own

EAR file: <script type="text/javascript"
src="/ThemeEarContextRoot/themes/html/ThemeName/js/
ThemeJavascript.js""></script>
4. You can change the context root for the themes and skins application by modifying the
application.xml file for the EAR. You can also update the display name for the application and WAR
name associated with the web module. For example:
<?xml version="1.0" encoding="UTF-8"?>
<application id="Application_ID" version="1.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
<display-name>MigratedThemes</display-name>
<module id="WebModule_1">
<web>
<web-uri>MigratedThemes.war</web-uri>
<context-root>/wps</context-root>
</web>
</module>
<security-role id="SecurityRole_1276111387778">
<description>Everyone in the enterprise.</description>
<role-name>Everyone Role</role-name>
</security-role>
<description>All Authenticated users in the enterprise.</description>
<role-name>All Role</role-name>
</security-role>
<description>No users in the enterprise.</description>
<role-name>No Role</role-name>
</security-role>
</application>
5. After updating the application.xml file, repackage the EAR, and deploy the EAR in WebSphere
Application Server using the administrative console.
Important: If you intend to reuse the original context root for the migrated portal, you must remove
the MigratedThemes.ear application generated during migration.
6. To make the updated themes and skins available on the new context root, update the portal
configuration for any themes and skins referencing the old context root.
a. Export the themes and skins using the XML configuration interface. For example, create an XML
input file containing the following request and submit it using the xmlaccess command:

<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
type="export">


<skin action="export" objectid="*"/>
<theme action="export" objectid="*"/>
</portal>
</request>
Example command:
wp_profile_root/PortalServer/bin/xmlaccess.sh -url http://localhost:10039/wps_migrated/config
-in request_input_file.xml -out request_output_file.xml
-user portal_admin_id -password portal_admin_password
The output file generated from the xmlaccess command contains the themes and skins defined in
the portal.
b. Edit the output file and update any references to the original context root for themes and skins.
The following examples assume that the pre-migrated context root is /wps and the new context
root is /MyCompanyTheme.
Updating <skin> elements
v Example with old context root:
<skin action="update" active="true" context-root="/wps" default="true"
domain="rel" objectid="ZK_CGAH47L00G1M302N5SU00Q30C2" resourceroot="IBM"
type="default" uniquename="ibm.portal.skin.IBM">
v Example with new context root:
<skin action="update" active="true" context-root="/MyCompanyTheme"
default="true" domain="rel" objectid="ZK_CGAH47L00G1M302N5SU00Q30C2"
resourceroot="IBM" type="default" uniquename="ibm.portal.skin.IBM">
Updating <theme> elements
v Example with old context root:
<theme action="update" active="true" context-root="/wps" default="true"
defaultskinref="ZK_CGAH47L00G1M302N5SU00Q30C2" domain="rel"
objectid="ZJ_CGAH47L00G1M302N5SU00Q3010" resourceroot="Portal"
uniquename="ibm.portal.theme.Portal">
v Example with new context root:
<theme action="update" active="true" context-root="/MyCompanyTheme"
default="true" defaultskinref="ZK_CGAH47L00G1M302N5SU00Q30C2" domain="rel"
objectid="ZJ_CGAH47L00G1M302N5SU00Q3010" resourceroot="Portal"
uniquename="ibm.portal.theme.Portal">
c. After you complete the updates to the output file, you can use the file to re-import your changes
to the portal with the xmlaccess command.
7. After all hardcoded references to the old context root have been removed and the updated themes
and skins have been made available in the portal, you can change the portal context root; see
"Changing the portal URI" for information.
Migrating 1497
Related tasks:
“Changing the portal URI” on page 1589
You can change the default portal Uniform Resource Identifier (URI) after installation. There are a few
applications that have a fixed context root that cannot be changed.
WebSphere Application Server: EARExpander command
Migrating V6.1.x on a V6.1 application server

When you migrate from IBM WebSphere Portal V6.1.x on IBM WebSphere Application Server V6.1, you
can migrate either a standalone, single server or a clustered deployment with nodes distributed across
multiple servers. New tools and enhanced capabilities provide a more streamlined experience while
minimizing required downtime.
The migration process varies slightly depending on whether the earlier, source portal server uses IBM
WebSphere Application Server V6.1 or V7.
Notes:
v When installing the new version of WebSphere Portal, ensure that you use the same ID and access
level that was used to install the earlier portal.
v Use the new defaults.isBinaryInstall="true" parameter to install only the binary code. This
significantly reduces the installation time that is required during migration and helps to avoid potential
conflicts. This option cannot be used when migrating from V6.0.1.x to V7.0.
v When running migration commands, execute only one command at a time.
Planning checklist: V6.1.x portal on a V6.1 application server

Use the worksheet below to plan your migration from IBM WebSphere Portal Version 6.1.x and identify
issues that require special attention. You might also want to print a copy of this document so that you
can add your own notes to the table below.
Table 393. Checklist for planning migration
Infrastructure

Product version and family Which product version and Always try to migrate to
family is deployed in the the latest release of the
existing environment? target version.Migration is
supported from the two
Which product version and latest available fix pack
family do you want to levels of Version 6.1.x and
migrate to? between the same product
families (Express, Express
Plus, Enable, Extend), and
from Express to Enable,
Express Plus to Extend,
Express to Extend, and
Enable to Extend.
For example, if you are

using WebSphere Portal
Version 6.1 or 6.1.0.1, and
the two most recent fix
packs are 6.1.0.3 and 6.1.0.4,
you must upgrade to either
fix pack before you can
migrate to Version 7.0.
Migration is not supported

to a portal release that
contains an enabled feature
pack.
Deployment scenario Do you have a standalone
server environment or a
clustered server
environment?
Hardware What hardware does the
existing portal run on?
Do you plan to migrate to

the same hardware or to
new hardware?
Migrating 1499
Operating system What operating system and You can migrate from an
version does the existing older version of an
environment run on? operating system to a
newer supported version of
Does the target version that that operating system, or
you want to migrate to from a 32–bit version of an
support that operating operating system to a
system and version? supported 64–bit version of
that operating system

operating systems is not
supported. For example,
you cannot migrate from a
Windows operating system
to a UNIX operating
system.

7.0 does not support SUSE
SLES 9. If your earlier
portal runs on SLES 9, you
need to upgrade to SUSE
SLES 10 before migrating to
7.0. See the SLES 10
documentation for
instructions on upgrading
the operating system.
Application server

User registry What does the existing Perform maintenance
portal installation use to cleanup on users and
store user account groups as needed before
information: migrating. For example,
v Lightweight Directory clean up deleted users and
Access Protocol (LDAP) their personalized pages
before starting migration.
v WebSphere Portal
database Migration assumes that the
v Custom user registry earlier installed portal and
the new installed portal use
If you use LDAP, do you the same LDAP server. If
plan to move to a different the new version of
LDAP server? WebSphere Portal does not
support the LDAP that you
used with the earlier portal
server, upgrade the LDAP
on the earlier portal server
prior to migration.
If the earlier portal and the

new portal are configured
to use a standalone LDAP
user registry, the users and
groups in the new portal
installation must be the
same as the directory users
and groups in the earlier
portal installation.
Migrating 1501
Database Does the new portal You can migrate from an
installation support the older version of a database
database that the earlier server to a newer version
portal installation uses? of that database server.
Can the database be database servers is not
upgraded if needed? supported. For example,
you cannot migrate from an
IBM DB2 Universal
Database Enterprise Server
Edition database server to
an Oracle database server.
If you are migrating from

WebSphere Portal
configured to use DB2 V9,
ensure that your source
environment is running the
minimum required level –
either V9.1 with Fix Pack 6
or later, or V9.5 with Fix
Pack 5 or later.
If you used Derby as the

default DBMS in the earlier
version, you must transfer
your data to a supported
DBMS before executing
migration steps

7.0 requires the use of type
4 spec 4 database driver.
Database schemas WebSphere Portal generates
SQL scripts that
automatically upgrade
database schemas during
migration.
Web server What HTTP server does the
existing installation use?
Does the new installation

support this HTTP server?
External security Supported IBM and
third-party security settings
are migrated automatically.

Pre-built sample Web sites If you migrate from V6.1x
and optionally installed the
sample Intranet and
Internet sites for that
version, the target portal
server can support sample
sites from both the earlier
version and the new
version. However, to ensure
that the V7.0 sample sites
are available, you will need
to run the
configure-express task
after completing migration.
Administration and
Maintenance
Backup Do you have a backup plan Back up the existing portal
and schedule in place for database before starting
the new portal server? migration.
Cleanup and maintenance Have you installed one of
the two latest fixpacks to
bring your V6.1.x portal
installation to the required
service level for migration?
Have you changed the Changes to the scheduled
default settings of the cleanup service settings are
scheduled cleanup service? not migrated. If you
modified these settings in
the earlier portal and want
to continue using the same
settings in the new portal,
you must update the
settings on the new portal.
Customized portal
resources
Custom themes and Does the earlier portal
administration installation use custom
themes?
custom administration
themes?
customized administration
portlets or pages?
customized global settings?
Have any portal service
configurations been
customized?
Migrating 1503
Custom portlets WebSphere Portal Version
7.0 uses the IBM
Server portlet container for
standard portlets. Migrated
portlets that rely on the
Java Specification Request
(JSR) 168 or 286 Portlet API
will continue to work
unchanged.
Does the earlier portal have The IBM Portlet API is still
any portlets that were supported but it deprecated
developed by using IBM in WebSphere Portal V6.0
Portlet API? and later.
If you have portlets that

use the legacy API, you are
not required to convert
them to JSR portlets before
migrating; however, after
you complete migration,
converting these portlets is
strongly recommended.
Does the earlier portal have The pbportlet.jar file
custom portlets that use must be updated to match
Click-To-Action (C2A)? the version that WebSphere
Portal Version 7.0 uses.
Do any custom applications You must update these
in the earlier portal use applications to use the
private IBM APIs? public version of the IBM
APIs.
Have you installed and Third-party portlets must
deployed third-party be certified for use with the
portlets? latest version of WebSphere
Portal.
Remote portlets
Search Do you want to migrate Search Web collections that
custom search collections? were created in an earlier
version of WebSphere
Portal can be exported and
imported into Version 7.0.
See Migrating web
collections from V6.1.

IBM Web Content Manager Web Content Manager
requires a JCR repository of
the same version. Even
though you might have
different version
repositories stored in the
same database, Web
Content Manager V7.0 only
works with the V7.0
repository.
If you have any Web

Content Manager data that
references a Portal
Document Manager library,
you must replace the Web
content that was stored as a
document in the document
library before you begin the
migration process. See
“Document migration” on
page 1435.
Business portlets See “Deprecated business
portlets” on page 1482.
Collaborative portlets iNotes, Lotus Notes View,
and Lotus Document
Viewer are migrated with
other portlet applications.
For information on
deprecated portlets
including My Lotus
QuickPlaces, Inline
QuickPlaces, Domino
Document Manager, and
Lotus Web Conferencing,
see “Deprecated
collaborative portlets” on
page 1483.
Related tasks:
“Converting IBM portlets” on page 3325
You can convert your basic IBM portlets as well as IBM portlets that use the Struts Portlet Framework to
the standard portlet API.
Premigration tasks
Pre-migration tasks include preparing the source portal that you want to migrate and setting up the new
portal. If the two portals are located on different servers, you also need to assemble some additional,
supplementary files.
Migrating 1505
Preparing a source portal on a V6.1 application server
1. If the earlier portal server is configured to use DB2, ensure that you are running the minimum
required level – either V9.1 with Fix Pack 6 or later, or V9.5 with Fix Pack 5 or later. DB2 Fix packs
are available for download from IBM DB2 Support.
2. Back up the databases and the entire directory structure for the earlier portal server installation.
3. Ensure that the existing portal environment is at the required service level for migration.
4. To ensure that the wkplc_comp.properties file contains the correct information, run the following
commands:
v Windows:
ConfigEngine.bat validate-database-connection -DTransferDomainList=release,jcr

ConfigEngine.bat connect-database -DTransferDomainList=release,jcr
v UNIX:
ConfigEngine.sh validate-database-connection -DTransferDomainList=release,jcr

ConfigEngine.sh connect-database -DTransferDomainList=release,jcr
v i:

If you plan to migrate IBM Web Content Manager data, complete the remaining steps.
5. On the source portal server, remove locks on all Web content items:
a. Go to the Administration view.
b. Go to Portal Content > Web Content Libraries.
c. Click View Locked Items.
d. Select all items and then click Unlock.
6. If you are migrating from Version 6.1.5, you must manually update the getNlsStrings.js file in Web
Content Manager to work correctly with the Version 7.0 portal.
a. On the 6.1.5 server, click Applications > Content > Web Content Management.
b. In the authoring portlet, click Edit Shared Settings.
c. Add the blog library to the authoring portlet.
1) Click Library Selection.
2) Select Blog Resources from the list of available libraries, and click Add.
3) Click OK.
d. Update the getNlsStrings.js file.
1) Download the new version of the getNlsStrings.js file from the WebSphere Portal product
documentation.
2) Ensure that the Blog Resources library is selected in the Library drop-down menu.
3) Select Components.
4) Select the check box for FILE - Get NLS Strings JS, and click Edit.
5) In the File Resource Element section, click Browse and navigate to the updated
getNlsStrings.js file that you downloaded.
6) Click Save and read to update the file and verify your changes.
Note: If you do not update the getNlsStrings.js file before migration, the browser might display
this error when displaying a blog or wiki page: ibmPortalConfig is not defined. If the error

occurs after you update the getNlsStrings.js file, you might need to clear the browser's cache or
delete any temporary internet files to ensure that the latest version of the file is loaded from the
server.
Related concepts:
“Supported migration paths” on page 1405
Related tasks:
Setting up the target portal when the source portal runs on a V6.1 application
server
If the source portal is running on IBM WebSphere Application Server V6.1, use these instructions to set
up the new portal environment. The new portal can be on either the same server as the earlier version or
on a different (remote) server.
1. Install IBM WebSphere Portal Version 7.0 using the defaults.isBinaryInstall="true" parameter (for
example, install.bat -W defaults.isBinaryInstall="true"). This option significantly reduces
installation time and helps to avoid potential conflicts.
Attention: If you inadvertently perform a full install (instead of installing only the binary code), you
must remove the default profile as follows:
a. Use the WebSphere Application Server manageprofiles command to delete the default profile
(wp_profile). For detailed instructions, see Deleting a profile in the WebSphere Application Server
V7.0 Information Center.
b. Manually remove the remaining wp_profile_root directory. See your operating system
documentation for instructions on command syntax.
2. Upgrade the server to the latest fix pack level. Refer to the Applying fixes topic for more information,
including a link to the list of recommended fix packs and interim fixes.
3. Increase the transaction log size for the database you are using for the target server to prevent
problems during migration. Different factors can affect the transaction log file size that is appropriate
for your environment – for example, the amount of data stored in the portal databases, or the number
of primary and secondary log files in use. To avoid having migration tasks fail because the transaction
log file is too small, see your DBMS documentation to determine the best option for increasing the
transaction log size before you start migration.
4. DB2 for z/OS only: When installed for use with WebSphere Portal, DB2 for z/OS is typically
configured to grant users the ALL BUFFERPOOLS privilege. However, if you have configured your
database to grant privileges to individual buffer pools, ensure that you grant appropriate privileges to
those buffer pools to users on the target system, particularly for any buffer pools that are new in
Version 7.0 (for example, BP8Kx or BP16Kx) or are different from those used in your 6.1 system.
Migrating 1507
Related tasks:
“Applying fixes” on page 1403
Periodically fix packs are released to integrate product code fixes. Between fix pack releases, interim fixes
may be recommended or required to ensure product reliability and stability.
Deleting a profile (AIX, Linux, Solaris, Windows)
Deleting a profile (IBM i)
Migrating to a Version 7.0 standalone application server (AIX, Linux, Solaris, Windows)
Migrating to a Version 7.0 standalone application server (IBM i)
Preparing supplementary files for remote migration from V6.1

Portal provides.
1. On the WebSphere Portal Version 7.0 server, run the following command to create the
PortalRemMigPkg.zip file:
v Windows: PortalServer_root\bin\genRemMigPkg.bat remote_zip_dir
v UNIX: PortalServer_root/bin/genRemMigPkg.sh remote_zip_dir
v i: PortalServer_root/bin/genRemMigPkg.sh remote_zip_dir
where remote_zip_dir is an existing directory that will contain the generated file. This directory
should not be the default directory and should be specified using the full path to the directory.
2. Copy the contents of the WebSphere Application Server Network Deployment Version 7 Supplements
Disc 2 for your operating system to supp_dir where supp_dir is an existing directory on the source
portal server.
Note: If you are using a 32–bit database driver on a 64–bit machine, you need to use the 32–bit
WebSphere Application Server Network Deployment Version 7 Supplements Disc 2; if you have a
64–bit database driver on a 64–bit machine, use the 64–bit WebSphere Application Server Network
Deployment Version 7 Supplements Disc 2.
3. Copy PortalRemMigPkg.zip from the WebSphere Portal Version 7.0 server into supp_dir, the directory
on the source portal server where you copied the Supplements Disc 2 files.
4. Unzip PortalRemMigPkg.zip.
5. UNIX only: Ensure that read and execute permissions are set on the extracted files. For example:
chmod -R 755 supp_dir/PortalMigration
chmod 755 supp_dir/migration/plugins/com.ibm.patch.was.plugin.jar
supp_dir/migration/plugins/com.ibm.wp.was.plugin.jar
6. To verify that the supplementary files are properly set up, change to the supp_dir/PortalMigration
directory and run the following command:
v Windows: WPmigrate.bat
v UNIX: ./WPmigrate.sh
v i: WPmigrate.sh
If the supplementary files are set up properly, you should see a response like this:
usage:
[echo] WPmigrate <migration-command> [[-Dproperty1=value1] -Dproperty2=value2]...]
BUILD SUCCESSFUL

Preparing DB2 for migration of large data sets on V6.1
If you are using DB2 and have a large amount of content in the JCR repository (for example, Web
Content Manager data), it is recommended that you prepare DB2 for migration by updating several
settings related to performance.
The values described here are suggested starting points but have been used with success in IBM testing.
Exact values can vary, depending on the size of the data set being migrated. Consult your database
administrator as needed.
Important: The settings described here are optimized for migration rather than day-to-day operation.
After migration completes successfully, you can revert any changes back to the values in use before
migration.
1. Update the lock list size for the database. A value of at least 10000 is recommended.
2. Disable all automatic maintenance on the database, including health monitoring.
3. Increase the package cache size. A value of at least 24000 is recommended.
4. Increase the statistics heap size. A value of at least 16384 is recommended.
5. Perform a complete reorganization of the tables and indexes on the database to be migrated.
6. Collect detailed statistics with distribution for all tables and indexes.
Note: While the migration is in progress, it might be necessary to collect detailed statistics to continue
to allow the database optimizer to select efficient access plans.
Migrating search components from V6.1

Migrating the search components in your portal might require preparation steps on the source portal and
then additional steps on the migrated portal.
Migrating portal search collections from V6.1

migration.
This applies to migrating between versions of WebSphere Portal. Migrating your search collections might
also be required when you install an interim fix. Refer to the instructions in the ReadMe file provided
with the interim fix.
Notes:
1. If you do not want to migrate your search collections, the migration process deletes them
automatically and creates new search collections. Content is indexed in the next scheduled crawl after
migration is complete.
2. Exporting and importing portal site search collections into portal Version 7.0 is not supported.
Search collections that were created in Version 6.0.1.x require manual migration; use the Import or Export
Collection option of the Manage Search portlet to export and import the search collections as described
below. For more details about these tasks and the Manage Search portlet, see the portlet help.
To migrate your search collections, proceed by the following steps:

1. Before you migrate your portal to a later version, export your search collections. This step exports the
configuration data and all document URLs of your search collections.
Notes:
Migrating 1509
a. Before you export a collection, make sure that the portal application process has write access to
the target directory location. Otherwise you might get an error message, such as File not found.
b. When you specify the target directory location for the export, be aware that the export overwrites
files in that directory.
2. For each collection, document the following data:
v The target file names and directory locations to which you export the collection.
v Location, name, description, and language.
v Settings for the Specify collection language and Remove common words from queries options.
3. Delete the search collections from your existing portal. Otherwise they can be corrupted by the import
step that follows later. If you are upgrading from one portal version to another, you do not need to
delete the search collections, as the new collections are stored under a different directory path
location.
4. Upgrade your WebSphere Portal as required.
5. Create empty search collections that you can use later to hold the imported collections. Fill in the
following fields and select the following options according to the information that you documented in
step 2 above:
Location of Collection
The location can match the old setting, but does not have to match it.
Name of Collection
The name can match the old setting, but does not have to match it.
Description of Collection
The description can match the old setting, but does not have to match it.
Specify Collection Language
Select this to match the old setting as documented in step 2.
Select Categorizer
Select Summarizer
Remove common words from queries (for example. in, of, on, etc.)
Check or clear this setting to match the old setting as documented in step 2.
You do not have to add content sources or documents, as that is completed by the import process.
6. Check that the target search collections that you created in step 5 are empty. Do not import collection
data into a target collection that already contains sources or documents.
7. Import the search collection data into the portal. For the import source information, use your
documented file names and directory locations to which you exported the collections before the portal
upgrade.
When you import a collection, a background process fetches, crawls, and indexes all documents which
are listed by URL in the previously exported file. Keep in mind that this process can require a large
amount of memory and an extended amount of time.
8. When importing Web Content Manager collections from portal V6.0.1.x, modify the target URL for the
affected content sources to use the IP address of the new portal server. To do this, click the content
source, select the General parameters tab, and modify the field Collect documents linked from this
URL.
Notes:
1. When you import search collection data into a collection, most of the configuration data (for example,
content sources, schedulers, filters, and language settings) are also imported. If you configured such
settings when creating the new collection, they are overwritten by the imported settings.

2. If you migrate a remote search service, use the updated file PseLibs.zip. This file is compiled by Java
5, therefore you need to have your portal running under IBM WebSphere Application Server Version
7.0. You do not need to replace the SOAP and EJB applications.
3. If you migrate to WebSphere Portal Version 7.0, you can migrate only your web collections. You
cannot migrate your portal search collections.
Migrating web search collections from V6.1

Note: Exporting and importing portal site search collections into portal Version 7.0 is not supported.
Exporting a web collection from V6.1:
Use the Manage Search portlet to export search web collections from a source portal. Before exporting a
web collection, verify that the portal application process has write access to the target directory location.
Use the Manage Search portlet to complete the following steps:

1. On the earlier portal server, select the collection that you want to export.
2. In the Search Collections box, click Export collection.
3. In the Specify Location field, enter the full directory path and XML file name to which you want to
export the document collection and its data.
4. Click Export
Importing a web collection from V6.1:
When you import a web collection, a background process fetches, crawls, and indexes all documents that
are listed by URL in the previously exported file. Therefore be aware of the memory and time required
for crawls. For more information, see Hints and tips on using Portal Search.
Complete the steps below on the target portal, using the Manage Search portlet:
1. If you are migrating to a remote server, copy the XML file that contains the exported web collection to
the server where the new version of WebSphere Portal is installed.
2. In the Search Collections box, click Create Collection to create an empty collection.
3. Specify the required information in the Location of Collection, Name of Collection, and Description
of Collection fields, and then click OK.
4. Select the empty collection that you created.
5. In the Search Collections box, click Import collection.
6. In the Specify Location field, enter the full directory path and XML file name of the file that you
exported.
7. Click Import.
8. Select the collection that you created, and then click the Eyeglasses icon to search and browse the
collection.
Migrating 1511
9. Verify that the documents found are the same as the collection that you created on the earlier portal
server, and that the links work as expected. Any inconsistencies between the exported document
count and the imported document count should be resolved the next time the cleanup daemon runs.
Migrating the Search and Browse portlet from V6.1

Complete the following steps:

1. In the product banner, click Administration, then under Portlet Management, click Portlets.
2. Locate the Search and Browse portlet and then click the Configure icon.
3. Verify the location of the search collection in the new portal installation and update
CollectionLocation as needed.
4. If the portal environment uses a remote search server, verify that either Soap_URL or IIO_URL is set to
the correct value.
7. Perform this procedure for all instances of the Search and Browse portlet that you deployed in your
portal.
Migrating a remote search server from V6.1

1. Update IBM WebSphere Application Server on the remote search server to the supported version.
To avoid port conflicts, ensure that the earlier installed version of WebSphere Application Server is up
and running, and then install the current version of WebSphere Application Server to a different
directory. After installation, check that both the earlier version and the newer version are running, and
then continue configuring the remote server. For more information, see Using remote search service.
2. On the migrated portal, recreate the search collections for use with the updated remote search server.
Migrating a stand-alone portal that runs on a V6.1 application server

Migrating an IBM WebSphere Portal V6.1.x stand-alone on IBM WebSphere Application Server V6.1
involves the high-level steps outlined here.
Migrating the portal's V6.1 application server profile

The steps that you use to migrate the IBM WebSphere Application Server portal profile vary depending
on whether the target portal is on the same server as the source portal or on a remote server.
Migrating the portal's V6.1 application server profile to a local server:
If the source portal and target portal are located on the same server, you can migrate the source portal's
application server profile by completing a set of manual steps or by using the IBM WebSphere
Application Server Migration wizard to create the profile automatically for you.
Note: The command parameters documented in this topic have been tested for the migration process. It
is not recommended that you specify additional parameters for these commands, even if they are
supported by the commands, unless specifically directed to do so.
1. Create the new profile on the target portal server:
v Windows: AppServer_root\bin\manageprofiles.bat -create -defaultPorts -enableAdminSecurity
false -profileName wp_profile_name -profilePath profile_path -templatePath
AppServer_root\profileTemplates\default -nodeName source_node_name -cellName
source_cell_name -hostName host_name -isDefault -omitAction samplesInstallAndConfig
defaultAppDeployAndConfig

v UNIX: AppServer_root/bin/manageprofiles.sh -create -defaultPorts -enableAdminSecurity false
-profileName wp_profile_name -profilePath profile_path -templatePath AppServer_root/
profileTemplates/default -nodeName source_node_name -cellName source_cell_name -hostName
host_name -isDefault -omitAction samplesInstallAndConfig defaultAppDeployAndConfig
v i: AppServer_root/bin/manageprofiles.sh -create -defaultPorts -enableAdminSecurity false
where
wp_profile_name
Specifies the profile on the target server or node to which the source portal profile is to be
migrated.
profile_path
Specifies the profile location on the target server or node that is to contain the migrated
source portal profile.
source_node_name
Specifies the node name for the node that is created with the new profile. Use a unique value
within the cell or on the server.
source_cell_name
Specifies the cell name of the source portal profile.
host_name
Specifies the host name for the target server or deployment manager where you are creating
the profile.
2. Run the WASPreUpgrade command:
v Windows: AppServer_root\bin\WASPreUpgrade.bat backup_dir source_WasHome -traceString
trace_spec -traceFile trace_file -oldProfile wp_profile_name
v UNIX: AppServer_root/bin/WASPreUpgrade.sh backup_dir source_WasHome -traceString trace_spec
-traceFile trace_file -oldProfile wp_profile_name
v i: AppServer_root/bin/WASPreUpgrade.sh backup_dir source_WasHome -traceString trace_spec
-traceFile trace_file -oldProfile wp_profile_name
where
backup_dir
Specifies the directory on the source portal where the WASPreUpgrade command stores the
exported profile data. If the directory does not exist, the WASPreUpgrade command creates it.
source_WasHome
Specifies the WebSphere Application Server installation directory on the source server.
trace_spec
An optional parameter that specifies the trace information that you want to collect. To gather
all trace information, specify "*=all=enabled" (including the quotation marks). If you include
this parameter, you must also specify the trace_file.
If you do not specify the -traceString or -traceFile parameter, the command creates a trace
file by default and places it in the backupDir/logs directory. If you specify the -traceString
parameter but omit the -traceFile parameter, the command does not generate a trace file.
trace_file
An optional parameter that specifies the name of the output file where trace information is
stored.
Migrating 1513
file by default and places it in the backupDirectory/logs directory. If you specify the
-traceString parameter but omit the -traceFile parameter, the command does not generate
a trace file.
wp_profile_name
Specifies the portal profile on the target server or node to which the source portal profile is to
be migrated.
3. If the target portal is on AIX, Linux, Solaris, or i, increase the file descriptor limit on the target portal
to 200000. For example: ulimit -n 200000
supports. By increasing the value before you migrate exported content into the new portal installation,
you can avoid problems that might be caused if the value were too low. After migration is complete,
you can restore the earlier value. For more information on ulimit, see the reference documentation for
your operating system.
4. Increase the Java maximum heap size for the WasPostUpgrade command.
a. Edit the WasPostUpgrade command file.
v Windows: AppServer_root\bin\WASPostUpgrade.bat
v UNIX: AppServer_root/bin/WASPostUpgrade.sh
v i: AppServer_root/bin/WASPostUpgrade.sh
b. Update the -Xmx parameter of the Java performance options variable to have a value of at least
1024 MB. For example:
v Windows:
set PERFJAVAOPTION=-Xms512m -Xmx1024m -Xj9 -Xquickstart
v UNIX:
set PERF_JVM_OPTIONS=-Xms512m -Xmx1024m -Xj9 -Xquickstart
v Solaris:
set PERF_JVM_OPTIONS="-Xms512m -Xmx1024m -XX:PermSize=128m -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass"
5. Run the WASPostUpgrade command:
v Windows: AppServer_root\bin\WASPostUpgrade.bat backup_dir -profileName wp_profile_name
-oldProfile old_wp_profile_name -username source_admin_user -password
source_admin_password -includeApps true -backupConfig false -traceString trace_spec
-traceFile trace_file
v UNIX: AppServer_root/bin/WASPostUpgrade.sh backup_dir -profileName wp_profile_name
v i: AppServer_root/bin/WASPostUpgrade.sh backup_dir -profileName wp_profile_name -oldProfile
old_wp_profile_name -username source_admin_user -password source_admin_password
-includeApps true -backupConfig false -traceString trace_spec -traceFile trace_file
where
backup_dir
Specifies the directory where the WASPreUpgrade command stores the data that it exports from
the source server, and from which the WASPostUpgrade command reads and imports data.
wp_profile_name
Specifies the new portal profile on the target server or node to which the WasPostUpgrade
command migrates the source portal profile.

old_wp_profile_name
Specifies the source portal's profile name. The profile name must already exist in the backup
source_admin_user
Specifies the administrator ID for the source portal. Specify the login form of the
administrator ID rather than the fully qualified name; for example, specify wpsadmin rather
than uid=wpsadmin, o=defaultWIMFileBasedRealm.
source_admin_password
Specifies the administrator ID password for the source portal.
trace_spec
trace_file
stored.
a trace file.
Important: After running the WasPostUpgrade command on a local server, it is possible to start the
portal server for verification purposes. However, because the migration process is not complete, there
might be errors in the SystemOut.log file. These errors are usually resolved after the upgrade-profile
task completes. It is important that you not attempt to run in production when the migrated portal is
in this state. If you start the portal for verification at this point, you must stop the portal before
running the upgradeConfigEngine command.
6. Update wp_profile_root/ConfigEngine/properties/wkplc.properties with the correct WebSphere
Application Server administrator password for the portal that you want to migrate.
7. To upgrade the ConfigEngine tool from V6.1 to V7, run the following command:
v Windows: PortalServer_root\bin\upgradeConfigEngine.bat profile_name -user admin_name bind
-password admin_password
v UNIX: PortalServer_root/bin/upgradeConfigEngine.sh profile_name -user admin_name bind
v i: PortalServer_root/bin/upgradeConfigEngine.sh profile_name -user admin_name bind -password
admin_password
where
profile_name
Specifies the name of the WebSphere Application Server V7 profile that is the target of the
upgrade.
admin_name
Specifies the administrator user ID for the application server.
admin_password
Specifies the password for the administrator user ID.
Trace information is stored in the UpgradeConfigEngineTrace.log file in the wp_profile_root/
ConfigEngine/log directory.
Migrating 1515
WebSphere Application Server provides a Migration wizard, AppServer_root/bin/migration.bat(sh), that
automatically creates the profile in the AppServer_root/profiles directory. To create the profile in a
specified location, you can use either the Profile Management Tool (PMT) (on 32-bit application server) or
the manageprofiles command (on 64-bit application server). Then, when you use the Migration wizard,
you can select the new profile as the target profile for migration.
Note: When pre-creating a profile, create a default application server profile and install the admin
console only; do not install any sample applications.
To migrate the application server profile on i, use the manual steps provided above; WebSphere
Application Server does not provide a Migration wizard on i.
Migrating the portal's V6.1 application server profile to a remote server:
If the source portal and target portal are located on different servers, ensure that you have prepared the
supplementary files that are required for remote migration, and then follow the steps described here to
migrate the source portal profile.
Note: The command parameters documented in this topic have been tested for the migration process. It
is not recommended that you specify additional parameters for these commands, even if they are
supported by the commands, unless specifically directed to do so.
1. If the source portal is on AIX, Linux, Solaris, or i, increase the file descriptor limit on the source portal
supports. After migration is complete, you can restore the earlier value. For more information on
ulimit, see the reference documentation for your operating system.
2. On the source portal server, run the WASPreUpgrade command:
v Windows: supp_dir\migration\bin\WASPreUpgrade.bat backup_dir source_WasHome -traceString
trace_spec -traceFile trace_file -oldProfile wp_profile_name -machineChange true
v UNIX: supp_dir/migration/bin/WASPreUpgrade.sh backup_dir source_WasHome -traceString
v i: supp_dir/migration/bin/WASPreUpgrade.sh backup_dir source_WasHome -traceString
where
supp_dir
Specifies the directory on the source portal server where you assembled the supplementary
files that are required for migration to a remote server.
backup_dir
Specifies the directory on the source portal where the WASPreUpgrade command stores the
exported profile data. If the directory does not exist, the WASPreUpgrade command creates it.
source_WasHome
Specifies the WebSphere Application Server installation directory on the source server.
trace_spec

trace_file
stored.
a trace file.
wp_profile_name
Specifies the portal profile on the target server or node to which the source portal profile is to
be migrated.
3. Move the backup directory that contains the source portal's exported data to the target server where
the new version of WebSphere Portal is installed.
Use a compression utility to compress the directory contents, or map a drive to the remote server, and
then move the directory containing the exported data to the remote server.
4. Create the new profile on the target portal server:
v Windows: AppServer_root\bin\manageprofiles.bat -create -defaultPorts -enableAdminSecurity
false -profileName wp_profile_name -profilePath profile_path -templatePath
AppServer_root\profileTemplates\default -nodeName source_node_name -cellName
source_cell_name -hostName host_name -isDefault -omitAction samplesInstallAndConfig
defaultAppDeployAndConfig
v UNIX: AppServer_root/bin/manageprofiles.sh -create -defaultPorts -enableAdminSecurity false
v i: AppServer_root/bin/manageprofiles.sh -create -defaultPorts -enableAdminSecurity false
where
wp_profile_name
Specifies the profile on the target server or node to which the source portal profile is to be
migrated.
profile_path
Specifies the profile location on the target server or node that is to contain the migrated
source portal profile.
source_node_name
Specifies the node name for the node that is created with the new profile. Use a unique value
within the cell or on the server.
source_cell_name
Specifies the cell name of the source portal profile.
host_name
Specifies the host name for the target server or deployment manager where you are creating
the profile.
5. If the target portal is on AIX, Linux, Solaris, or i, increase the file descriptor limit on the target portal
supports. By increasing the value before you migrate exported content into the new portal installation,
you can avoid problems that might be caused if the value were too low. After migration is complete,
you can restore the earlier value. For more information on ulimit, see the reference documentation for
your operating system.
Migrating 1517
6. Increase the Java maximum heap size for the WasPostUpgrade command.
a. Edit the WasPostUpgrade command file.
v Windows: AppServer_root\bin\WASPostUpgrade.bat
v UNIX: AppServer_root/bin/WASPostUpgrade.sh
v i: AppServer_root/bin/WASPostUpgrade.sh
b. Update the -Xmx parameter of the Java performance options variable to have a value of at least
1024 MB. For example:
v Windows:
set PERFJAVAOPTION=-Xms512m -Xmx1024m -Xj9 -Xquickstart
v UNIX:
set PERF_JVM_OPTIONS=-Xms512m -Xmx1024m -Xj9 -Xquickstart
v Solaris:
set PERF_JVM_OPTIONS="-Xms512m -Xmx1024m -XX:PermSize=128m -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass"
7. Run the WASPostUpgrade command:
v Windows: AppServer_root\bin\WASPostUpgrade.bat backup_dir -profileName wp_profile_name
v UNIX: AppServer_root/bin/WASPostUpgrade.sh backup_dir -profileName wp_profile_name
v i: AppServer_root/bin/WASPostUpgrade.sh backup_dir -profileName wp_profile_name -oldProfile
old_wp_profile_name -username source_admin_user -password source_admin_password
-includeApps true -backupConfig false -traceString trace_spec -traceFile trace_file
where
backup_dir
Specifies the directory where the WASPreUpgrade command stores the data that it exports from
the source server, and from which the WASPostUpgrade command reads and imports data.
wp_profile_name
Specifies the new portal profile on the target server or node to which the WasPostUpgrade
command migrates the source portal profile.
old_wp_profile_name
Specifies the source portal's profile name. The profile name must already exist in the backup
source_admin_user
Specifies the administrator ID for the source portal. Specify the login form of the
administrator ID rather than the fully qualified name; for example, specify wpsadmin rather
than uid=wpsadmin, o=defaultWIMFileBasedRealm.
source_admin_password
Specifies the administrator ID password for the source portal.
trace_spec

trace_file
stored.
a trace file.
Important: After running the WasPostUpgrade command on a remote server, you cannot start the
portal server for verification purposes. At this point in the remote migration process, the required
V6.1 binary files are not located on the remote server, so the application is not yet complete. If you
attempt to start the portal after the WasPostUpgrade command and before the upgrade-profile task,
the portal will fail with numerous errors in the SystemOut.log file. This is expected behavior.
8. To upgrade the ConfigEngine tool from V6.1 to V7, run the following command:
v Windows: PortalServer_root\bin\upgradeConfigEngine.bat profile_name -hostname host_name
-user admin_name bind -password admin_password
v UNIX: PortalServer_root/bin/upgradeConfigEngine.sh profile_name -user admin_name bind
v i: PortalServer_root/bin/upgradeConfigEngine.sh profile_name -user admin_name bind -password
admin_password
where
profile_name
Specifies the name of the WebSphere Application Server V7 profile that is the target of the
upgrade.
host_name
Specifies the host name of the application server (when migrating a stand-alone server) or
Deployment Manager (when migrating a clustered environment).
admin_name
Specifies the administrator user ID for the application server.
admin_password
Specifies the password for the administrator user ID.
Trace information is stored in the UpgradeConfigEngineTrace.log file in the wp_profile_root/
ConfigEngine/log directory.
Related tasks:
“Preparing supplementary files for remote migration from V6.1” on page 1508
Portal provides.
Using copies of source database domains to minimize downtime

When you migrate from IBM WebSphere Portal V6.1.x on IBM WebSphere Application Server V6.1, the
recommended way to keep the earlier portal environment in production and reduce the amount of
downtime during migration is to copy the earlier portal server JCR and Release domains, connect to the
domain copies, and then update the new portal server using the domain copies. The process of
connecting to the domain copies must be done after you upgrade the ConfigEngine tool but before you
upgrade the V6.1.x profile.
Note:
Migrating 1519
v (Important): Copying the V6.1.x JCR and Release domains is recommended but not required. However,
if you choose to have the new portal server point directly to the V6.1.x domains (instead of to copies of
the domains), you will not be able to continue using the JCR and Release domains with the earlier
portal server.
v (DB2 only): When you are migrating a source portal to a target portal that uses a different driver type,
you must reconnect all of the domains that are affected by changing the driver type. For example, if
the source portal is using DB2 with Type 2 drivers for all domains and you plan to use a Type 4 driver
type for all of the domains in your target portal, you must reconnect all of the database domains using
the connect-database command. For more instructions, refer to the "Changing DB2 driver types" topic
for your operating system.
1. Use your database tools to copy the source portal JCR domain and Release domain.
Note: If you are using IBM DB2 Universal Database for z/OS, review the following considerations:
v If you plan to use the DB2 Administration Tool to copy the database domains, additional steps are
required to ensure that the migration process completes successfully. Refer to Technote 1441277 for
instructions on using the tool during the migration process.
v Make sure you verify that the databases are not in a COPY PENDING state before you connect to the
database copies as described below.
2. On the target portal, in wp_profile_root/ConfigEngine/properties, locate the
wkplc_dbdomain.properties file and then update the jcr.* and release.* database properties to point
to the JCR and Release domain copies that you created in the previous step.
Note: If the source portal uses the default Apache Derby database, the migration tools automatically
copy the database for you. However, if you have modified or customized the default Derby database,
you must copy the entire Derby directory to a new directory, and then update all database properties
to point to the copy of the Derby database. Ensure that derby.DBLibrary is set to use the WebSphere
Application Server Version 7 derby.jar as the JDBC driver class and includes the directory location of
the file. For example: derby.DBLibrary=WAS7_root\derby\lib\derby.jar
3. If you are migrating a stand-alone local environment, before connecting to the domain copies, change
the WebSphere Application Server and WebSphere Portal port numbers by running the
modify-ports-by-startport task. For details, see the topic that explains how to install WebSphere
Portal on your particular operating system. For example, for Windows, look for the section on setting
up a stand-alone server on Windows, and then refer to the topic called Installing WebSphere Portal on
Windows.
4. On the target portal, change to the wp_profile_root/ConfigEngine directory and then connect to the
copies of the Release domain and JCR domain:
v Windows:
ConfigEngine.bat validate-database-connection -DTransferDomainList=release,jcr
ConfigEngine.bat connect-database -DTransferDomainList=release,jcr

v UNIX:
./ConfigEngine.sh validate-database-connection -DTransferDomainList=release,jcr
./ConfigEngine.sh connect-database -DTransferDomainList=release,jcr

v i:

Technote 1441277, Error SQLCODE = -540, SQLSTATE = 57001 received when running EJPSMPRF job
during migration
Retaining custom table spaces

If a database domain in the earlier portal server uses assigned custom table spaces that you want to
retain for use on the new portal server (instead of using the default table spaces), you need to update the
table space property file and the index space property file for the database table. Complete these updates
only after you have upgraded the ConfigEngine tool.
To retain assigned custom table spaces, update these files on the target portal server:
database_domain.table_name.tablespace
database_domain.table_name.index_name.indexspace
For more information, see the topics on assigning custom table spaces using your particular database
management system.
Updating the database schemas

Database schemas that you used with the earlier source portal need to be updated for use with the new
target portal. The migration process handles these updates for you automatically. However, if the portal
uses IBM DB2 Universal Database for z/OS as the backend repository, you can choose to view the SQL
scripts that the migration process uses to update the database schemas.
1. To ensure that you connect to the appropriate database domains, review wkplc_dbdomains.properties
and update the file as needed with the correct database parameters.
2. DB2 for z/OS only: To generate the scripts that will be used to migrate the database schemas, run the
following command from the wp_profile_root/ConfigEngine directory:
v Windows: ConfigEngine.bat generate-db-migration-scripts
v UNIX: ./ConfigEngine.sh generate-db-migration-scripts
WebSphere Portal stores the generated scripts in the wp_profile_root/PortalServer/
DBMigrationScripts/db_Type where db_Type is the DBMS that the portal uses. Each script file name
reflects the domain name. For example:
db2_zos/migrate_community_wp.db.impl.sql
db2_zos/migrate_customization_wp.db.impl.sql
db2_zos/migrate_jcr_wp.db.impl.sql
db2_zos/migrate_release_wp.db.impl.sql
An additional set of files is created to drop tables that were present in 6.0.x and might exist in your
6.1.x installation if you have previously migrated from 6.0.x to 6.1.x. These files have the format
dropV6legacyTables_db_domain_wp.db.impl. For example:
db2_zos/dropV6legacyTables_community_wp.db.impl.sql
db2_zos/dropV6legacyTables_customization_wp.db.impl.sql
db2_zos/dropV6legacyTables_jcr_wp.db.impl.sql
db2_zos/dropV6legacyTables_release_wp.db.impl.sql
You can review these files to understand the schema updates that will be performed during
migration.
WebSphere Portal also saves copies of the generated scripts in wp_profile_root/PortalServer/
DBMigrationScripts/db_Type/templates; scripts in the /templates subdirectory are reserved for
internal use and should not be run by users.
3. DB2 for z/OS only: After validating the scripts generated in the previous step. You must run the
scripts to make the schema changes. Do not attempt to use your database tools to make the updates.
The scripts are provided as a reference to show what changes will be made to the database. You must
use the provided WebSphere Portal migration tooling to make the required schema changes.
Migrating 1521
v Windows: ConfigEngine.bat upgrade-database
v AIX, i, Linux, Solaris, and z/OS: ./ConfigEngine.sh upgrade-database
4. DB2 for z/OS only: Update the database schemas.
a. Table spaces that have a CHECK PENDING status can prevent migration from completing successfully.
To determine which table spaces have a CHECK PENDING status, run the query shown below from
the command line processor:
SELECT DBNAME,NAME FROM SYSIBM.SYSTABLESPACE WHERE (STATUS = 'P') OR (STATUS = 'S');
b. For each table space that the preceding query identifies, type the following command to remove

WP 70

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

WP 70

Загружено:

Авторское право:

Доступные форматы

Version 7 Release 0

WebSphere Portal 7.0

iv WebSphere Portal 7.0

vi WebSphere Portal 7.0

viii WebSphere Portal 7.0

The following topics provide additional overview information.

IBM WebSphere Portal new features and improvements

2 WebSphere Portal 7.0

Blog and wiki

Learn more about blogs and wikis.

Learn more about logging and tracing.

Learn more about the Java Diagnostics Guide.

Learn more about migration.

Learn more about setting up a cluster.

Learn more about setting up and maintaining a portal farm.

Page Builder and Unified Theme Architecture

Learn more about Page Builder.

Learn more about impersonation and how to enable it.

Tagging and rating

Learn more about tagging and rating portal content.

Integration with workflow management systems

Learn more about the Unified Task List portlet.

4 WebSphere Portal 7.0

Learn more about virtualization on Linux.

Learn more about virtualization on Windows.

Documentation improvements and changes

Lotus Web Content Management

6 WebSphere Portal 7.0

WebSphere Portal Wiki

The wiki includes:

Key points to remember about the wiki:

The Support page includes:

Key points to remember about the Support page:

8 WebSphere Portal 7.0

10 WebSphere Portal 7.0

Changing portlet layout

Streamlined site creation

12 WebSphere Portal 7.0

14 WebSphere Portal 7.0

Creating and customizing portlet applications

16 WebSphere Portal 7.0

Tagging and rating portal content

In detail, portal users can perform the following tasks:

Administrators can perform the following tasks:

Developers can perform the following tasks:

18 WebSphere Portal 7.0

Blogs and wikis

Standard Java connectors

20 WebSphere Portal 7.0

Domino and Extended Products Portlets include:

This version of IBM WebSphere Portal:

The documentation includes the following features to aid accessibility:

22 WebSphere Portal 7.0

Features no longer supported

24 WebSphere Portal 7.0

IBM WebSphere Portal provides flexible deployment options ranging from

Planning to install WebSphere Portal

See the detailed system requirements document at the following URL:

WebSphere Portal Support Statement

28 WebSphere Portal 7.0

Support for LDAP Servers

LDAP support spans two (2) categories: