+

Search Tips   |   Advanced Search

Set up a cluster on AIX

  1. Horizontal cluster
  2. Vertical cluster
  3. Prepare the AIX OS
  4. Install WebSphere Portal on AIX on the primary node
  5. Install with GUI
  6. Use the IBM Installation Manager for installation
  7. Install with response file
  8. Post-installation tasks
  9. Install DB2
  10. Create groups and assign users
  11. Create DB2 databases
  12. Set up DB2 using ConfigEngine
  13. Set up DB2 manually
  14. Create DB2 database schemas
  15. Grant privileges to DB2 database users
  16. Assign custom DB2 table spaces
  17. Configure JCR collation support
  18. Manual DB2 transfer - Derby to DB2
  19. Configure DB2 for large file handling in WCM
  20. Change DB2 driver types
  21. Remove search collection
  22. Augment dmgr profile with Portal
  23. Prepare to create the cluster
  24. Create a static cluster
  25. Create a dynamic cluster
  26. Configure the Web server
  27. Prepare a Tivoli Directory Server
  28. Add an LDAP user registry
  29. Add a database user registry
  30. Add realm support
  31. Adapt the attribute configuration
  32. Query the defined attributes
  33. Add attributes
  34. Configure Portal to use dynamic groups
  35. Enable referrals for your LDAP user registry
  36. Configure the portal to use LDAP referrals
  37. Prepare additional cluster members
  38. Tune the servers
  39. Configure search
  40. Set up multiple clusters
  41. Install Web Content Manager into an existing Server installation


Horizontal cluster


Horizontal cluster


Prepare the AIX OS

  1. Set file descriptor limit...

      ulimit -n 10240

  2. For IBM GPFS file sharing, set inodes limit...

      mmchfs /dev/gpfs1nsd -F 250000

    /dev/gpfs1nsd is the portal installation file system.

  3. Set maximum file size. Set higher than largest anticipated upload to WCM.

      ulimit -f max_file_size

  4. To use install GUI tool, configure X server on AIX (for example X-Windows or GNOME). Not required if installing with a response file.


Install WebSphere Portal on AIX on the primary node

  1. System requirements


Install with GUI

The bit architecture of the installation program uses:

When you install onto a 64-bit operating system, WebSphere Portal installs as a 64-bit version. We can force a 32-bit application installation onto a 64-bit operating system.


Use the IBM Installation Manager for installation

  1. Verify the fully qualified host name...

      ping myserver.myco.com

  2. Verify network configuration...

      ping localhost

  3. For servers with a firewall, antivirus, screen saver, and/or desktop search engine enabled, disable them before installing.

  4. Install IBM Installation Manager:

    • Using GUI...

        ./install

      From command line:

        ./userinstc -acceptLicense -log /tmp/install.log

    • From Portal Setup disk...

        ./setup.sh

      To change display language, add the LaunchPadLocale language code.

      To search for IBM Installation Manager updates, navigate to...

        File > Update

  5. Add the repositories where the installation media exists:

    1. Open Installation Manager...

        imcl -c

    2. Navigate to...

        File | Preferences | Repositories | Add Repositories | Browse | IBM WAS service repository | OK

    3. Ensure all required repositories are checked.

    4. To verify successful access to service repositories, click

        Test Connections

    5. Select Apply.

    6. Select OK.

  6. Select Install to begin the installation process.

    On the Select the features to install panel, keep the default selection checked to create a new Portal server profile. This profile is used as the primary node for the cluster. There is also an option to create a local dmgr profile. Only select this option in a test environment where to automate the process of creating a local dmgr profile. Expand the WebSphere Portal package and select the dmgr Profile augmented with WebSphere Portal check box. Then on the Install Packages panel: Configuration details panel, click Dmgr Profile configuration details and enter the appropriate information for the dmgr.

    1. On the Select packages to install panel, select both the WAS and WebSphere Portal packages.

    2. Click Next.

    3. Accept the license agreement and then click Next.

    4. Select shared resources directory and then click Next.

    5. Set Installation Directory:

      The installation directory must be empty and must not contain any of the following characters: ~ ! @ # $ % ^ & * ( ) _ + { } | < > ? ` = [ ] ; ' , . "

      1. Select the WAS Package Group Name and then select the installation directory path.

      2. Select the WebSphere Portal Package Group Name and then select the installation directory path.

      3. Click Next.

    6. Select the translations to install and then click Next.

    7. On the panel...

        Select the features to install

      ...expand the WAS and WebSphere Portal packages

      To force a 32-bit installation on the 64-bit operating system, expand the IBM WAS Network Deployment feature. Then expand IBM Software Development Kit. Under IBM Software Development Kit, select 32-bit SDK for Java.

    8. On the Configuration panel, select the type of profile template to install: Full, Base, or Custom.

    9. Click Profile configuration details.

    10. Select either the Standard or Advanced configuration mode.

      Select Advanced to specify URI information.

    11. Click Next.

    12. Confirm the information on the Summary panel and then click Install.

  7. After a successful installation, the summary panel displays. Choose the radio button...

      Portal First Steps

    ...and then click Finish to start the servers and begin configuring WebSphere Portal.

    To access the First Steps panels later, we can either select First Steps from the Start menu or we can run...

      WP_PROFILE/PortalServer/firststeps/firststeps.bat

    Add the LaunchPadLocale language_code to the firststeps task to change the display to the user locale or to another language.

  8. If you changed the context root on the panel...

      Configuration for IBM WebSphere Portal: Profile configuration details: Advanced panel

    ...complete the steps in the Change the portal URI.


Install with response file

First install IBM Installation Manager. Then use a response file to install IBM WebSphere Portal and IBM WAS in a clustered environment. Record response files on the same OS you plan for the installation. For multiple operating systems, record a response file for each operating system.

The bit architecture of the installation program uses:

When you install onto a 64-bit operating system, WebSphere Portal installs as a 64-bit version. We can force a 32-bit application installation onto a 64-bit operating system.

There are sample response files, located in...

Manually update these files based on the environment. Also replace the following lines in the sample response files if you installed WAS and WebSphere Portal from the live repository (Passport Advantage):


Record response file interactively using Installation Manager menus

This step does not install WebSphere Portal. You are only recording the response file used to install portal later.

  1. Run...

      ./IBMIM -record responsefile.xml -skipInstall /path/to/install/directory

  2. On the panel...

      Select the features to install

    ...keep the default selection, create a new Portal server profile.

  3. On the panel...

      Select packages to install panel

    ...select both the WAS and WebSphere Portal packages.

  4. Accept the license agreement and then click Next.

  5. Select directory for shared resources and then click Next.

  6. Set Installation Directory:

    The installation directory must be empty and must not contain any of the following characters: ~ ! @ # $ % ^ & * ( ) _ + { } | < > ? ` = [ ] ; ' , . "

    1. Select the WAS Package Group Name and then select the installation directory path.

    2. Select the WebSphere Portal Package Group Name and then select the installation directory path.

    3. Click Next.

  7. Select the translations to install and then click Next.

  8. On the panel...

      Select the features to install

    ...expand the WAS and WebSphere Portal packages

    To force a 32-bit installation on the 64-bit operating system, expand the IBM WAS Network Deployment feature. Then expand IBM Software Development Kit. Under IBM Software Development Kit, select 32-bit SDK for Java.

  9. On the Configuration panel, select the type of profile template to install: Full, Base, or Custom.

  10. Click Profile configuration details.

  11. Select either the Standard or Advanced configuration mode.

    Select Advanced to specify URI information.

  12. Click Next.

  13. Confirm the information on the Summary panel and then click Install.

  14. After the Installation Manager finishes creating the response file, click Finish and then close the Installation Manager to complete the response file recording.

  15. If installing on a different computer, copy the response file to the response file directory on that computer.

  16. If the repository URL requires authentication, create a keyring file store for credentials...
    cd IM_HOME/tools
    ./imutilsc saveCredential 
               -url repository_URL \
               -userName credential_userName \
               -userPassword password  \
               -keyring keyring_file  \
             [ -password keyringfile_password ] \
             [ -proxyHost proxy_host -proxyPort proxy_port \
             [ -proxyUsername proxy_username -proxyUserPassword proxyuser_password ] \
             [ -useSocks ] ] \
             [ -verbose ] 
    

    If installing on a different computer, copy the keyring file to that computer.

  17. Install WebSphere Portal and IBM WAS...

      ./imcl -acceptLicense -input /path/to/response.xml -log /path/to/log/files

    To use your repository keyring file...

      -keyring /path/to/keyring -password keyringfile_password

  18. Verify the installation was successful;

      http://myserver:myport/wps/portal


Post-installation tasks

  1. Enable the sample WCM content...

      ./ConfigEngine.sh configure-express -DPortalAdminPwd=foo -DWasPassword=foo

    Run configure-express before configuring the database, user registry, context root, security, etc. If you ran any tasks other than the install task, do not run this task.

    The configure-express task...

    • Creates two new Web Content Manager Libraries:

        Internet Web Content 8.0.0
        Intranet Web Content 8.0.0

      To view...

        Administration | Portal Content | Web Content Libraries

    • Creates a group called contentAuthors. To add members to this group...

        Administration | Access | Users and Groups

    • Adds a portlet filter and applies the filter to various portlets in the sample Internet and intranet sites. We can see the definition of the filter in the WAS admin console and examining the custom resources under the Environment area.

    • Creates two new theme policies:

      • InternetStyle
      • IntranetStyle

      These styles are applied to sample Internet and intranet sites. Navigate to Theme Customizer and then select the style.

    • Creates several portlet clones of the Web Content Manager rendering portlet.

      These portlet clones are used on sample Internet and intranet sites.

    • Creates two virtual portals with context roots of...

      • wps/portal/intranet
      • wps/portal/internet

      To access...

      • http://myserver:myport/wps/portal/internet
      • http://myserver:myport/wps/portal/intranet

    • Creates several sample credential slots, including...

      • Default slot for Email
      • Default slot for Feeds
      • Default slot for Miscellaneous
      • Default slot for Web Clipping
      • Default slot for Web Content Management

      To view...

        Administration | Access | Credential Vault

  2. If you ran configure-express, the owner of the items in the Web content libraries containing the Internet and Intranet Site Template content will be listed as...

      uid=wpsadmin,o=defaultWIMFileBasedRealm

    To update owner information for these items to correspond to the portal admin ID edit...

      WP_PROFILE/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties

    ...and add the following lines to the file:

      uid=wpsadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN
      cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN

    ...then run...

      ./ConfigEngine.sh express-memberfixer -DPortalAdminPwd=foo -DWasPassword=foo


Install DB2

  1. On the DB host, update OS kernel parameters based on recommendations in the DB2 Quick Beginnings guide.

  2. When you install DB2 it automatically creates a DB2 administrative user with the correct operating system rights.

  3. Verify sufficient disk space for the DB2 instance home directory to be able to create the required databases.

  4. If the DB2 instance that maintains the databases for WebSphere Portal is used by other applications, for example, another portal, accessing databases on the same DB2 instance, it maybe necessary to increase the value of NUMDB.

    To set NUMDB to 30:

    UPDATE DATABASE MANAGER CONFIGURATION USING NUMDB 30

  5. Install DB2 or DB2 client.

  6. If DB2 is installed on another system than WebSphere Portal, copy the driver jar files from the DB2 server to the Portal server. The typical location for these files on the DB2 server is in

    DB2_HOME/java
    Place these driver files under WP_PROFILE;

    • WP_PROFILE/PortalServer/dbdrivers/db2jcc4.jar
    • WP_PROFILE/PortalServer/dbdrivers/db2jcc_license_cu.jar

  7. On the DB2 system, verify the DB2 instance port was added to services during the DB2 installation.

    • Edit /etc/services and ensure that the following is set...

        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. Ensure that the port number used is not in use. If the port number is already in use, select a different port number.

  8. Modify the approriate properties files before transferring the data from the default database to the DB2 database. Property files are read by ConfigEngine when tasks are executed. They are not read during Portal appserver startup.

    Multiple databases can be used to hold information for applications such as Feedback and LikeMinds.

    • release.DbName=reldb
    • jcr.DbName=jcrdb
    • feedback.DbName=fdbkdb
    • likeminds.DbName=lmdb
    • community.DbName=commdb
    • customization.DbName=custdb

    For a remote database, enter values for the remote server. Regardless of the operating system, use a forward slash (/) instead of a backslash (\) in the property files for file system paths. Only change the properties within this task and skip all other properties.

    Depending on which database domain has to be configured, replace dbdomain with:

    • release
    • customization
    • community
    • jcr
    • feedback
    • likeminds

    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 we 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. 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.

  9. Make backup copies of the following files:

    • WP_PROFILE/ConfigEngine/properties/wkplc.properties
    • WP_PROFILE/ConfigEngine/properties/wkplc_dbdomain.properties
    • WP_PROFILE/ConfigEngine/properties/wkplc_dbtype.properties
    • For DB transfers other than Derby: WP_PROFILE/ConfigEngine/properties/wkplc_sourceDb.properties

    Default values are listed in these files. Unless otherwise noted, all values are of type alphanumeric text string. Set the appropriate values for each instance of each property. In wkplc_dbdomain.properties, most properties are repeated for each domain.

  10. Set properties in wkplc_dbdomain.properties

    dbdomain.DbType=db2
    dbdomain.DbName=domain_db_name DB2 database names cannot exceed eight (8) characters. This value is also the database element in dbdomain.DbUrl. TCP-IP alias for the database.
    dbdomain.DbSchema=domain_schema_name Some database management systems have schema name restrictions.
    dbdomain.DataSourceName=data_source_name Do not use the following reserved words: releaseDS communityDS customizationDS jcrDS lmdbDS feedback
    dbdomain.DbUrl=JDBC_DB_URL Value must conform to the JDBC URL syntax specified by the database. Database element should match the value of DbName.
    dbdomain.DbUser User ID for the database configuration user.
    dbdomain.DbPassword password for the database configuration user.
    dbdomain.DbConfigRoleName 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.
    Optional: dbdomain.DbRuntimeUser 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. If dbdomain.DbRuntimeUser is specified, set dbdomain.DbRuntimePassword to be the password of the runtime database user.
    dbdomain.DbRuntimeRoleName Name of the group for database runtime users. Database rights are granted to this group instead of individuals. The user specified for dbdomain.DbRuntimeUser must be assigned to this group.
    dbdomain.DBA.DbUser Optional. DB administrator user ID for privileged access operations during database creation and setup. Required.if you run the create-database and setup-database ConfigEngine tasks. If you do not need this parameter, we can either accept the default value or leave blank.
    dbdomain.DBA.DbPassword Optional. Database administrator password for privileged access operations during database creation. If you do not need this parameter, we can either accept the default value or leave blank.
    dbdomain.DbNode Value for the database node name. Set this value to call create-database. Required only for local databases.

  11. Save and close the file.

  12. Update the following properties in wkplc_dbtype.properties.

    db2.DbDriver Name of the JDBC driver class.
    db2.DbLibrary .zip or .jar file containing the JDBC driver class.
    db2.JdbcProviderName Name of the JDBC provided that WebSphere Portal uses to communicate with its databases.

  13. Save and close the file.

  14. Update the WasPassword value in wkplc.properties. This value is the password for the WAS security authentication used in the environment.

  15. Save and close the file.


Create groups and assign users

Before transferring the databases to DB2 , create the users and groups 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. If you have provided a value in wkplc_dbdomain.properties 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 wkplc_dbdomain.properties.

  2. If you have provided a value in wkplc_dbdomain.properties 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.


Create DB2 databases

When created DB2 databases locally, we can create these databases using a configuration task or we can create these databases manually. When created the DB2 databases remotely, we can only create the databases manually.


Create a local DB2 database automatically using ConfigEngine

We can use ConfigEngine tasks to create databases on a local DB2 installation. If we are using a remote DB2 installation, we cannot create databases using ConfigEngine. Create the databases manually. The create-database task cannot be run by a non-root user.

After completion, check the services file on the DB2 server system. If it does not specify DB2 connection and interrupt service ports, specify the ports for the operating system. Edit /etc/services and add the text...

...where db2 is the default instance. Ensure the port number used is not already in use. If 50000 is already is use, select a different port number.


Create a remote or local DB2 database manually

When we use a remote DB2 server, manually create the required databases.

If we are using DB2 JDBC Type 4 driver you do not need to install the DB2 client software. Copy the Type 4 jar files from the remote DB2 server to the WebSphere Portal server.

For Type 2 drivers, configure DB2 client to connect to the remote DB2 server instance, for example, db2inst1. To create a database, you must be a DB2 System Administrator with sufficient database privileges (SYSADM or at a minimum SYSCTRL).


Create a remote or local DB2 database manually

  1. Log in as a DB2 instance system authority.

    For example, we can log in as db2inst1 as the DB2 instance owner.

  2. Initialize a DB2 command environment.

    For example, execute...

      . /home/db2inst1/sqllib/db2profile

    db2inst1 is the DB2 instance owner of the DB2 instance.

      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"

  3. Create databases:

    • 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.

      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"
    

  4. On the DB2 server systems to create bufferpools and table spaces for the IBM Java Content Repository database (jcrdb). This step is only required for the IBM Java Content Repository database.

    jcrdb name of the database used to store user data and objects
    jcr jcr user for jcrdb
    dbpassword password for the jcr user for the jcrdb

    Run...

    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"
    

  5. For JDBC Type 2 drivers...


Set up DB2 using ConfigEngine

Create the database users, permissions, and table spaces:


Set up DB2 manually

If you have configured the database automatically by running ConfigEngine, 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 ConfigEngine.


Create DB2 database schemas

One way to create database schemas is to use SQL script templates...

Database domain Location of template
Release PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/createSchema.sql
Community PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/createSchema.sql
Customization PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/createSchema.sql
JCR PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/createSchema.sql
Feedback PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createSchema.sql
Likeminds PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createSchema.sql

Execute commands as a user that has admin rights on both the operating system (root) and the DB2 installation (SYSADM). You only need to manually create an administrator ID when you do not want to use an DB2 administrator ID created automatically by the DB2 installation program (db2inst1). 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:

User names can contain one to eight characters. Group and instance names can contain one to eight characters. Names cannot be: users admins guests public local. Names cannot begin with: IBM SQL SYS. Names cannot include accented characters. 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.


Grant 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. We 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 property...

...is assigned the same value as the property...

...and a role is created for a configuration user in each database domain.

This role is created and assigned automatically when you run...

As an alternative to creating and assigning this role automatically, we 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. Create our own version of these files to create runnable scripts.


Permissions granted to the schema-owning configuration database user

Database domain Location of template
Release PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/createConfigRoleForSameSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToConfigUser.sql
Community PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/createConfigRoleForSameSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToConfigUser.sql
Customization PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/createConfigRoleForSameSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToConfigUser.sql
JCR PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/createConfigRoleForSameSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToConfigUser.sql
Feedback PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createConfigRoleForSameSchema.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToConfigUser.sql
Likeminds PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createConfigRoleForSameSchema.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToConfigUser.sql

Non-schema-owning configuration database user:

Database domain Location of template
Release PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/createConfigRoleForDifferentSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToConfigUser.sql
Community PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/createConfigRoleForDifferentSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToConfigUser.sql
Customization PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/createConfigRoleForDifferentSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToConfigUser.sql
JCR PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/createConfigRoleForDifferentSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToConfigUser.sql
Feedback PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createConfigRoleForDifferentSchema.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToConfigUser.sql
Likeminds PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createConfigRoleForDifferentSchema.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToConfigUser.sql


Required privileges for the runtime database user

When the runtime database user is a schema owner, the 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...

before database transfer and later run grant-runtime-db-user-privileges configuration 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, we 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. Create our own version of these files to create runnable scripts.


Permissions granted to the schema-owning runtime database user

Database domain Location of template
Release PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/createInitialRuntimeRole.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/createRuntimeRoleForSameSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToRuntimeUser.sql
Community PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/createInitialRuntimeRole.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/createRuntimeRoleForSameSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToRuntimeUser.sql
Customization PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/createInitialRuntimeRole.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/createRuntimeRoleForSameSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToRuntimeUser.sql
JCR PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/createInitialRuntimeRole.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/createRuntimeRoleForSameSchema.sql
PORTAL_HOME/jcr/wp.content.repository.install/config/templates/setupdb/db2/jcr/grantPermissionsToRuntimeRoleStatic.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToRuntimeUser.sql
Feedback PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createInitialRuntimeRole.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForSameSchema.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToRuntimeUser.sql
Likeminds PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createInitialRuntimeRole.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForSameSchema.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToRuntimeUser.sql


Permissions granted to the non-schema-owning runtime database user

Database domain Location of template
Release PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/createInitialRuntimeRole.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/createRuntimeRoleForDifferentSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToRuntimeUser.sql
Community PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/createInitialRuntimeRole.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/createRuntimeRoleForDifferentSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToRuntimeUser.sql
Customization PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/createInitialRuntimeRole.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/createRuntimeRoleForDifferentSchema.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToRuntimeUser.sql
JCR PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/createInitialRuntimeRole.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/createRuntimeRoleForDifferentSchema.sql
PORTAL_HOME/jcr/wp.content.repository.install/config/templates/setupdb/db2/jcr/grantPermissionsToRuntimeRoleStatic.sql
PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToRuntimeUser.sql
Feedback PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createInitialRuntimeRole.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForDifferentSchema.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToRuntimeUser.sql
Likeminds PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createInitialRuntimeRole.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForDifferentSchema.sql
PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToRuntimeUser.sql


Assign custom DB2 table spaces

The repository of WebSphere Portal consists of many tables and indicecreated 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.

The custom table spaces must exist prior to the execution of database transfer.

To see which table spaces can be customized in each domain, reference...

The page size of table spaces used by WebSphere Portal must be 8192 bytes.

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.


Configure custom table space assignments

  1. Determine the names of the custom table spaces.

    Open the mapping file...

      WP_PROFILE/PortalServer/config/tablespaces/dbdomain.space_mapping.properties

    ...and review table space and index space property pairs for each database table...

    • dbdomain.table_name.tablespace
    • dbdomain.table_name.index_name.indexspace

    dbdomain can be any one of the following values:

    • release
    • community
    • customization
    • jcr
    • feedback
    • likeminds

    For jcr, edit mapping file:

      WP_PROFILE/PortalServer/jcr/config/jcr.space_mapping.properties

    ...which contains additional table space and index space property pairs for each jcr.table_name.tablespace database table.

  2. 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 we are transferring.

  3. Save and close dbdomain.space_mapping.properties

  4. From a command prompt, specify the option...

      -DuseCustomTablespaceMapping=true

    ...when starting the database transfer. For example,

      ./ConfigEngine.sh database-transfer -DuseCustomTablespaceMapping=true


Configure JCR collation support

JCR collation is recommended when the language locales of the users do not natively collate correctly in the DB2 database and when language locale correct ordering is important.

  1. Stop the WebSphere Portal server.

  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.

      cd db2_instance_owner_home/sqllib/function
      db2home/sqllib/java/jdk/bin/jar -xvf temporary location/wp.content.repository.install.jar icm/CollationUDF.class

  4. Change to the temporary directory where you copied the files in a previous step.

  5. Edit 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 jcr.DbSchema in wkplc_dbdomain.properties .

  6. Run...

      db2 connect to jcrdb user user_ID using password

    db2 -tvf temporary location/registerCollationUDFTemplate.sql

  7. Disconnect from the JCR database.

  8. Restart the DB2 instance.

  9. Verify the UDF is registered properly.

    Log in as the db2instanceID, open a DB2 terminal window and run...

      db2 connect to jcrdb user user_ID using password

    Connect to the JCR database as a database runtime user with the user ID and password for the WebSphere Portal JCR data source.

    Register the UDF: values schema.sortkeyj('abc','en')

  10. Edit...

      WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

    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
    

  11. Start the WebSphere Portal server.


Manual DB2 transfer - Derby to DB2

  1. To run tasks as a non-root user...

      chown -R non-root_user /path/to/my/WebSphere/AppServer

  2. If there are a lot of tables in JCR schema, increase open_cursors from default of 1500.

  3. There are additional steps for JDBC Type 2 drivers

  4. For multiple instances of WebSphere Portal, increase default configured number of databases...

      set client MAX_NETBIOS_CONNECTIONS 254

    A message indicates success if the number was increased.

  5. Validate database configuration properties...

      cd WP_PROFILE/ConfigEngine
      ./ConfigEngine.sh validate-database -DWasPassword=foo

    Add -DTransferDomainList to the validating task to specify the domains to validate. For example...

      -DTransferDomainList=jcr

    To validate all domains, do not specify this parameter.

  6. Stop the WebSphere_Portal server:

      cd WP_PROFILE/bin
      ./stopServer.sh WebSphere_Portal -username wpadmin -password foo

  7. Transfer the database:

    Do not execute the database-transfer task as a background process. This might cause the task to stall.

      cd WP_PROFILE/ConfigEngine
      ./ConfigEngine.sh database-transfer -DWasPassword=foo

    Set -DTransferDomainList to include only the domains to transfer. For example, to transfer only the JCR domain...

      ./ConfigEngine.sh database-transfer -DTransferDomainList=jcr -DWasPassword=foo

  8. If you have been storing data in Apache Derby for a long time, database transfer could fail with OutOfMemory exceptions. To fix:

      ConfigEngine.bat database-transfer -DDbtJavaMaxMemory=1536M -DWasPassword=foo

  9. Log output is written to:

      WP_PROFILE/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.

  10. If dbdomain.DbRuntimeUser is set, for the user...

    • Grant database user privileges manually:

      1. Copy SQL template files in...

        • PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/dbms/domain
        • PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/dbms/domain

        ...to a working directory.

        If the name of the database user and the schema name are not the same, copy...

          createRuntimeRoleForDifferentSchema.sql

        If the name of the database user and the schema name are the same, copy...

          createRuntimeRoleForSameSchema.sql

        ...where dbms is the database system, and domain is database domains (release, customization, community, jcr, feedback, and likeminds).

        For the JCR database domain, copy grantPermissionsToRuntimeRoleStatic.sql from...

          PORTAL_HOME/jcr/wp.content.repository.install/config/templates/setupdb/dbms/jcr/

      2. Replace all placeholder values with the values as defined in wkplc_dbdomain.properties. Placeholder values are surrounded by the character @.

      3. Execute the SQL statements.

    • Grant database user privileges automatically:

      1. Set domain.DBA.DbUser in...

          WP_PROFILE/ConfigEngine/properties/wkplc_dbdomain.properties

        For example...

          domain.DBA.DbUser=dbadmin

      2. Grant privileges...

          ./ConfigEngine.sh grant-runtime-db-user-privileges -DTransferDomainList=release,customization,community,etc...

        You only need to add -DTransferDomainList when granting privileges across specific domains.

  11. For each database, to improve performance...

      db2 connect to dbName user db2wpadmin using password
      db2 reorgchk update statistics on table all > xyz.out

    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 tablenames:

        db2 terminate
        db2rbind database_name -l db2rbind.out -u db2_admin -p password

      The file db2rbind.out is created when there is an error.

  12. Start the WebSphere Portal server.

      cd WP_PROFILE/bin
      ./StartServer.sh WebSphere_Portal

  13. On each configured node, make sure the following file is identical to the same file on the primary node...

      WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

    If the files are not identical, copy icm.properties from the primary node, the one one which you ran the database-transfer, to the node(s) with the obsolete icm.properties file..

    1. Stop the portal server on the secondary nodes.

    2. From the primary node...

        scp /path/to/PortalServer/jcr/lib/com/ibm/icm/icm.properties user@secondary_node:/path/to/PortalServer/jcr/lib/com/ibm/icm/

    3. Start the portal server on the secondary nodes.


Configure DB2 for large file handling in WCM

If we are using Web Content Manager, update the database configuration to support large files. We can update the fullyMaterializeLobData property by running a configuration task.

You only need to perform these steps if we are using Web Content Manager.


Change 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.

Prerequisites...

  1. The WebSphere Portal database has been successfully transferred to DB2 using the database-transfer configuration task.

  2. The files wkplc_dbdomain.properties and wkplc_dbtype.properties have been modified to set the correct values for the DB2 drivers that we are switching to:

    In the file wkplc_dbdomain.properties set each <Domain>.DbUrl property...

    # db2 (type 2):  { jdbc:db2:wpsdb }
    # db2 (type 4):  { jdbc:db2://<YourDatabaseServer>:50000/wpsdb:returnAlias=0; }
    

    In the file wkplc_dbtype.properties set the db2.DbLibrary property using the following format:

    # For DB2 Type 2 driver use <SQLLIB>/java/db2jcc4.jar
    # For DB2 Type 4 driver use <SQLLIB>/java/db2jcc4.jar:<SQLLIB>/java/db2jcc_license_cu.jar
    

    In the file wkplc_dbtype.properties set the db2.DbDriver property using the following format:

    # For DB2 Type 2 driver use com.ibm.db2.jcc.DB2Driver
    # For DB2 Type 4 driver use com.ibm.db2.jcc.DB2Driver
    

    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 Create 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.

    1. Export the DB2 user profile that created when installing DB2 onto the administrative user . This command exports the DB2 user's profile onto the administrative user so that they can access the DB2 utilities.

        cd WP_PROFILE/ConfigEngine
        . /home/db2inst1/sqllib/db2profile

      ...where db2inst1 represents the database instance

      Complete this step before running database tasks and before enabling security.

    2. Validate configuration properties...

        ./ConfigEngine.sh validate-database -DWasPassword=foo

      Add -DTransferDomainList to the validating task to specify the domains to validate; for example...

        -DTransferDomainList=jcr

      To validate all domains, do not specify this parameter.

    3. cd WP_PROFILE/bin

    4. Stop the WebSphere_Portal server:

        ./stopServer.sh WebSphere_Portal -username wpadmin -password foo

    5. cd WP_PROFILE/ConfigEngine

    6. 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=foo  \
                        -Dcustomization.DbPassword=foo  \
                        -Dcommunity.DbPassword=foo  \
                        -Djcr.DbPassword=foo  \
                        -Dfeedback.DbPassword=foo  \
                        -Dlikeminds.DbPassword=foo  \
                        -DWasPassword=foo 
      

    7. cd WP_PROFILE/bin

    8. Start the WebSphere Portal server.


Remove search collection

  1. Edit...

      WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

    ...and set...

      jcr.textsearch.enabled = false

  2. Restart the WebSphere_Portal server.

  3. Log on to WebSphere Portal and navigate to...

      Administration | Manage Search | Search Collections

  4. Click the Delete Collection icon for each search collection and then click OK until they are all deleted.

  5. Restart the WebSphere_Portal server and then navigate back to the Search Collections page to verify that all search collections have been deleted.


Augment dmgr profile with Portal

  1. Install portal on the primary node

  2. Install Installation Manager on the dmgr host.

  3. Add WebSphere Portal repositories to IM on the dmgr host.

  4. Install WAS ND on the dmgr

  5. Create a dmgr profile using the Management profile template

    Make sure that cell name and node name are different than the cell and node name used in portal. If they are the same, federation will fail. There is a way to change the dmgr cell name after creation of dmgr.

    • Using manageprofiles.sh...
      ./manageprofiles.sh -create 
                          -templatePath WAS_HOME/profileTemplates/management 
                          -hostName hostname
                          -cellName cellname
                          -nodeName nodename
                          -profileName Dmgr01 
                          -profilePath WAS_HOME/Dmgr01 
                          -enableAdminSecurity true 
                          -adminUserName dmgradmin 
                          -adminPassword dmgrpass
      

    • Using Profile Management Tool (pmt.sh)

      1. Run...

          cd WAS_HOME/bin/ProfileManagement
          ./pmt.sh

        ...and select...

          Profile Management Tool | Create | Environment Selection | Management | Next | dmgr | Next | Advanced profile creation

      2. Check the box...

          Deploy the administrative console

      3. On the panel...

          Profile Name and Location

        ...provide the name for the new profile and its location in the file system.

      4. Select...

          Make this profile the default

      5. On the Node, Host Names, and Cell Names panel, provide the node name and TCP/IP host name for the new profile.

      6. On the Administrative Security panel, check the box...

          Enable administrative security

        Enter values for the User name, Password, and Confirm password fields.

      7. On the Port Values Assignment panel, change any necessary port values and then click Next.

      8. On the panel...

          Profile Creation Summary

        ...review the information collected by the wizard, and then click Create to create the new profile based on the supplied information.

        The port values presented in the summary value are overridden by the port values used by the servers present in the configuration archive provided as part of the portal profile template. These port values need to be adjusted after profile creation if they are in conflict with other ports on the local system.

      9. Click Finish to exit PMT.

  6. Stop the deployment manager.

    If installing on dmgr co-located with portal, stop WebSphere_Portal as well.

  7. From portal host, scp...

      PORTAL_HOME/filesForDmgr/filesForDmgr.zip

    ...to the remote dmgr server.

  8. Expand the filesForDmgr.zip file into the installation root directory of the dmgr; for example in directory...

      /opt/IBM/WebSphere/AppServer

    If the dmgr profile was not created in the default Appserver/profiles/Dmgr01 directory, then copy...

      Appserver/profiles/Dmgr01/config/.repository/metadata_wkplc.xml

    ...to...

      DMGR_PROFILE/config/.repository

  9. Start the deployment manager.

  10. Review dmgr logs

  11. Augment the dmgr profile:

    • Using manageprofiles.sh...
      cd WAS_HOME/bin
      ./manageprofiles.sh -augment  \
                          -templatePath WAS_HOME/profileTemplates/management.portal.augment \
                          -profileName Dmgr01
      

    • Run...

        cd WAS_HOME/bin/ProfileManagement
        ./pmt.sh

    • Click Launch Profile Management Tool

    • Select the dmgr profile and then click Augment.

    • On the Augment Selection panel, select dmgr for Portal, and then click Next.

    • On the Profile Augmentation Summary panel, review the information collected by the wizard, and then click Augment.

    • Click Finish to exit PMT.

  • Stop and restart the dmgr server

  • If there are common shortnames between the default dmgr security configuration and the LDAP server:

    1. Log on to the dmgr console.

    2. Navigate to Security > Global security.

    3. Under User account repository, click Configure.

    4. 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.

    5. Click Apply.

    6. Enter the password for the user and then confirm the password.

    7. Save all changes.

    8. Log out of the WAS admin console.

  • If you changed the context root on the panel...

      Configuration for IBM WebSphere Portal: Profile configuration details: Advanced

    ...during installation:

    1. Log on to the dmgr console and go to...

    2. Edit urlBlackList and urlWhiteList with the new context path. For example...

      • urlBlackList: /wpsmodified/myportal*
      • urlWhiteList: /wpsmodified/mycontenthandler*

    3. Click Apply | Save

    4. Log out of the dmgr console.


    Prepare to create the cluster

      Set WasUserid and WasPassword to the dmgr user ID and password.

    1. To create a dynamic cluster:

      1. Install WebSphere Virtual Enterprise and augment the dmgr profile.
      2. On the WebSphere Portal primary node, install WebSphere Virtual Enterprise and augment the wp_profile profile.

      When using the GUI for profile augmentation, select type of augmentation..

        Operations Optimization

      Use manageprofiles.sh to augment a stand-alone application server profile from the command-line

    2. Federate the primary node:

        cd WP_PROFILE/bin
        ./addNode.sh dmgr_hostname dmgr_port -includeapps -username wasadmin -password foo

      If the WAS administrator user ID and password for the local node are different from the dmgr, add the following parameters:

      • -localusername local_wasadmin
      • -localpassword local_foo

      If addNode.sh fails for any reason, before rerunning the task:

      1. If federation succeeded, run removeNode.sh

      2. If items exist, log on to the dmgr and...

        1. Remove all enterprise applications.
        2. Remove the WebSphere_Portal server definition.
        3. Remove the WebSphere Portal JDBC Provider.

    3. Stop the WebSphere_Portal server on the primary node and verify the following parameters are set correctly in wkplc.properties:

      Although we can add these parameters (particularly passwords) directly to any task while creating the cluster, we might want to temporarily add them to the properties file. We can then remove them when we are finished to keep the environment secure.

      1. Set WasSoapPort to the port used to connect remotely to the dmgr.

      2. Set WasRemoteHostName to the full host name of the server used to remotely connect to the dmgr.

      3. Verify that WasUserid is set to the dmgr administrator user ID.

      4. Verify that WasPassword is set to the dmgr administrator password.

      5. Verify that PortalAdminPwd is set to the WebSphere Portal administrator password.

      6. Verify that ClusterName is set.

      7. Verify that PrimaryNode is set to true.

    4. If we configured a database user registry or a property extension database on the dmgr, set up access to the database drivers:

      1. 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 wkplc.properties.

        If you migrated the primary node from a version prior to Version 6.1.0 and we 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 wkplc.properties on the primary node.

      2. To add the library paths to the VMM_JDBC_CLASSPATH variable:

        1. Log on to the WAS WAS admin 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/db2jcc4.jar:SQLLIB/java/db2jcc_license_cu.jar

        6. Copy files set for the VMM_JDBC_CLASSPATH variable into the appserver/lib directory.

        7. Stop and restart the appropriate servers to propagate the changes.

      3. Create the local dmgr WebSphere variable used to access the database jars...

        ./ConfigEngine.sh wp-prep-vmm-db-secured-environment \ 
                          -DWasPassword=foo\ 
                          -DDbDomain=la|federated.db \ 
                          -Ddb_type.NodeDbLibrary=/path/to/dmgr/jars \ 
                          -DDmgrNodeName=dmgr_node_name

        Set db_type to your database type, for example db2. The /path/to/db/jars should be one of the following options:

          DB2 Type 2 driver db2java.zip
          DB2 Type 4 driver db2jcc4.jar;db2jcc_license_cu.jar
          DB2 for z/OS Type 2 driver db2java.zip
          DB2 for z/OS Type 4 driver db2jcc4.jar;db2jcc_license_cisuz.jar
          Oracle ojdbc14.jar
          SQL Server JDBC driver sqljdbc.jar

      4. Create the variable used to access the VMM database jars...

        ./ConfigEngine.sh wp-node-prep-vmm-db-secured-environment \ 
                          -DWasPassword=dmgr_password \ 
                          -DDbDomain=la|federated.db \ 
                          -DVmmNodeName=node_name \ 
                          -Ddb_type.NodeDbLibrary=/path/to/db/jars

        VmmNodeName is a list of one or more 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 we are using, for example db2.


    Create a static cluster

    After installing IBM WebSphere Portal on the primary node, configuring a remote database, and preparing the primary node to communicate with the dmgr, we can create the static cluster to handle failover requests.

    1. Run cluster node configuration task...

        ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password

    2. If the admin user ID and group name are different in the WebSphere Portal and dmgr configurations, choose one of the following options depending on the security policies:

      • Add the existing admin user ID and group to the dmgr security configuration
      • To change the values in the WebSphere Portal configuration to match the dmgr values:

      If the dmgr cell is using a stand-alone LDAP user registry, complete these steps after the cluster-node-config-cluster-setup (static cluster) or cluster-node-config-dynamic-cluster-setup (dynamic cluster) task completes.

      1. Start the WebSphere_Portal server.

      2. Verify the required WebSphere Portal admin user ID and group ID are defined in the dmgr user registry that provides security for the cell.

      3. Run...

         
        cd WP_PROFILE/ConfigEngine  
        ./ConfigEngine.sh wp-change-portal-admin-user  \
                          -DWasPassword=foo  \
                          -DnewAdminId=newadminid  \
                          -DnewAdminPw=newpassword  \
                          -DnewAdminGroupId=newadmingroupid 
        

        ...where...

        WasPassword administrative password for the dmgr cell
        newAdminId fully qualified DN of the WebSphere Portal admin user ID in the cell
        newAdminGroupId fully qualified DN of the group for the WebSphere Portal admin user ID in the cell

        If the value for newAdminGroupId contains a space; for example Software Group, edit wkplc.properties file and add the values for newAdminId, newAdminPw, and newAdminGroupId.

        Save the changes and then run...

          ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=dmgr_password

      4. After the task completes, stop the WebSphere_Portal server.

    3. Run...

        ./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password

    4. If you entered passwords in any of the properties files while creating the cluster, you should remove them for security purposes.


    Create a dynamic cluster on AIX using WebSphere Virtual Enterprise

    After installing and configuring IBM WebSphere Portal on the primary node and all horizontal nodes, we 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 dmgr and completed all the tasks under “Preparing the primary node.” On the dmgr system, install WebSphere Virtual Enterprise, apply all required ifixes, and augment the dmgr profile to make it compatible with WebSphere Portal. 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 Portal.

    Profile augmentation is completed using the pmt.sh GUI on systems that support it or through manageprofiles.sh available on all systems. When using the GUI, select...

      Operations Optimization

    ...when choosing the type of augmentation to complete. Use manageprofiles.sh to augment a stand-alone application server profile from the command-line

    1. Complete the following steps for on the primary node of the dynamic cluster:

      1. Run...

          ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password

      2. The node is federated and using the dmgr cell and its user registry. If the admin user ID and group name are different in the WebSphere Portal and dmgr configurations, choose one of the following options depending on your security policies:

        • Add the existing admin user ID and group to the dmgr security configuration

        • To change the values in the WebSphere Portal configuration to match the dmgr values:

        If the dmgr cell is using a stand-alone LDAP user registry, complete these steps after the cluster-node-config-cluster-setup (static cluster) or cluster-node-config-dynamic-cluster-setup (dynamic cluster) task completes.

        1. Start the WebSphere_Portal server.

        2. Verify the required WebSphere Portal admin user ID and group ID are defined in the dmgr user registry that provides security for the cell.

        3. Run...

            ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

          If the value for newAdminGroupId contains a space; for example Software Group, open wkplc.properties and add the values for newAdminId, newAdminPw, and newAdminGroupId. Save the changes and then run...

            ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=dmgr_password

          • WasPassword is set to the administrative password for the dmgr cell
          • newAdminId is set to the fully qualified DN of the WebSphere Portal admin user ID in the cell
          • newAdminGroupId is set to the fully qualified DN of the group for the WebSphere Portal admin user ID in the cell

        4. After the task completes, stop the WebSphere_Portal server.

    2. Log on to the dmgr console.

    3. To create a node group:

      1. Click System administration > Node groups.

      2. Click New.

      3. Type the node group Name.

      4. Optional: Type any information about the node group in the Description text box.

      5. Click OK.

      6. Click the Save link to save the changes to the master configuration.

    4. To add members to the node group:

      1. Click System administration > Node groups.

      2. Click the name of the node group to add members to.

      3. Click Node group members under Additional Properties.

      4. Click Add.

      5. Select the primary node and then click Add.

      6. Click the Save link to save the changes to the master configuration.

    5. To create a dynamic cluster in the node group:

      1. Click Servers > Clusters > Dynamic clusters.

      2. Click New.

      3. Select WAS from the Server Type pull-down menu and then click Next.

      4. Select the Automatically define cluster members with rules radio button.

      5. 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 wkplc.properties of the primary node.
      6. Remove all default membership policies and then click Subexpression builder.

      7. 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 created in the previous step in the Value text box.
        5. Click Generate subexpression.
        6. Click Append.

      8. Click Preview membership to verify that all nodes included in the nodegroup display and then click Next.

      9. 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.

      10. Click Next.

      11. Specify the required dynamic cluster properties for minimum and maximum number of server instances.

        T 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.

      12. When we are done configuring the dynamic cluster properties, click Next.

      13. Review the summary page to verify your actions and then click Finish.

      14. Click the Save link to save the changes to the master configuration.

    6. Define or verify the following parameters in wkplc.properties:

      1. Verify that CellName is set to the dmgr cell.

      2. Verify that NodeName is set to the local node.

      3. Set ServerName to the server used for the dynamic cluster member on this node.

        To find the name of the server used for the dynamic cluster...

          Servers | Clusters | Dynamic Clusters | PortalCluster | Dynamic cluster members

      4. Verify that PrimaryNode is set to true.

    7. Create the dynamic cluster...

        ./ConfigEngine.sh cluster-node-config-dynamic-cluster-setup -DWasPassword=dmgr_password

      This task may display a warning message since the cluster already exists. The task proceeds to create the new dynamic cluster. Therefore, the warning can be ignored.

    8. Run the following tasks to pick up the configuration changes:

      WebSphere_Portal is the name of the node's WebSphere Portal server; but if you customized the server name, the default name changes. If we are uncertain of the server name, run the task...

        serverstatus -all

      ...to get a list of the server names and their status.

        ./stopServer.sh WebSphere_Portal -username wpadmin -password foo
        ./startServer.sh WebSphere_Portal


    Configure the Web server

    1. Install and configure the Web server;

    2. For Lotus Domino...

      • Edit notes.ini on the Web server
      • Set HTTPEnableConnectorHeaders and HTTPAllowDecodedUrlPercent to 1

      If we are using WebDav, enable it in the Lotus Domino Webserver Administrative Console.

    3. For IHS or Apache Server, edit httpd.conf and set AllowEncodedSlashes to On; the directive should be added at the root level as a global directive.

      HTTP server type Documentation link
      HTTP Server IBM HTTP Server
      Apache Server AllowEncodedSlashes directives

    4. Stop the Web server.

    5. Install and configure the Web server plug-in

      If using WebDAV with mashups: After installing the Web server plug-in, edit plugin-cfg.xml and set AcceptAllContent to true.

      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. Adjust higher if we are retrieving data from a database. To update, edit plugin-cfg.xml and set ServerIOTimeout . See Common questions about the Web server plug-in.

    6. If we are using a Oracle iPlanet Web Server, some portlets require disabling the unix-uri-clean or nt-uri-clean directives to operate properly. We can enable/disable these directives by editing obj.conf.

      If we are using Oracle iPlanet Web Server v7, disable uri-clean.

    7. If we are using Oracle iPlanet Web Server v7 update 8, read Technote 1448262 and complete the steps to resolve the HTTP 408/409 error.

    8. Some features, such as portal mashups and change layout for pages with the Page Builder theme using an IIS web server, require an enabled PUT and DELETE method. If the Web server has these methods disabled:

      • Enable HTTP tunneling to simulate PUT and DELETE requests, which means that POST requests are used instead.

        See the "Switch for tunneling of HTTP methods" link for information.

      • Enable PUT and DELETE requests.

    9. Start the Web server.

    10. To use the Web application bridge feature, from the WAS admin console select...

        Applications | Application Types | WebSphere enterprise applications | wp.vwat.servlet.ear | Web Module Properties | Context Root For Web Modules

      ...and change the context root to /. Save changes and then restart wp.vwat.servlet.ear.

    11. To access WCM content through an external web server:

      1. Log on to the dmgr console and select...

          Environment | WebSphere Variables | Scope drop-down menu | Node=nodename, Server=servername

      2. Update the WCM_HOST variable with the fully qualified host name used to access the portal server through the web server or On Demand Router.

      3. Update the WCM_PORT variable with the port number used to access the portal server through the web server or On Demand Router.

      4. Update the WCM_HOST and WCM_PORT variable for each additional portal server that already exists in the cluster.

      5. Synchronize the node with the dmgr:

          System Administration | Nodes | node | Full Resynchronize

      6. Log off of the dmgr console.

    12. If you have a dynamic cluster and we are using a web server to connect to the On Demand Router (ODR), configure the web server as a trusted proxy on the ODR.

      We can also configure the ODR to dynamically update the web server configuration when changes occur.


    Prepare a Tivoli Directory Server

    1. Install Tivoli Directory Server

    2. Create a directory suffix.

      From the TDS Web Administration Tool, go to...

        Server Administration folder | Manage Server Properties | Suffix

      ...and set the Base DN name for the suffix; for example...

        dc=myco,dc=com

    3. Create custom LDIF files in...

        PORTAL_HOME/installer/wp.iim/ldif

      For templates, we can use PortalUsers.ldif and ContentUsers.ldif for groups and user IDs. Replace dc=myco,dc=com with your suffix. Replace any prefixes and suffixes that are unique to your LDAP server. Specify user names other than wpsadmin and wpsbind

    4. Import the LDIF files into Tivoli Directory Server.


    Add an LDAP user registry

    We can add multiple LDAP user registries to the default federated repository although we can only add one LDAP server at a time.

    The flat-naming convention is...

      cn=groupName

    ...the hierarchical format is...

      cn=groupName,o=root

    Ensure IDs are unique between the default federated repository and the LDAP we are adding. For example, if the default federated repository contains an ID such as wpsadmin, this ID cannot exist in the LDAP we are adding.

    In a clustered environment, start the dmgr and nodeagent and verify they are able to synchronize.

    Complete these steps on the primary node only.

    Use the helper file...

      WP_PROFILE/ConfigEngine/config/helpers/wp_add_federated_xxx.properties


    Add an LDAP user registry to the default federated repository

    Repeat these steps for each additional LDAP user registry to add:

    1. Run backupConfig

    2. Edit wkplc.properties

    3. Set parameters under the VMM Federated LDAP Properties heading:

      For example...

        federated.ldap.baseDN=dc=myco,dc=com

    4. Set entity types parameters...

    5. Set group member parameters...

    6. Save changes to wkplc.properties.

    7. Validate the LDAP server settings...

        ./ConfigEngine.sh validate-federated-ldap -DWasPassword=foo

      In an environment configured with an LDAP with SSL, during the validation task, you will be prompted to add a signer to the truststore.

      For example...

        Add signer to the truststore now?

      If you do, press y then Enter.

    8. Add the LDAP user registry to the default federated repository...

        ./ConfigEngine.sh wp-create-ldap -DWasPassword=foo

      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.

    9. Stop and restart servers, dmgrs, and node agents.

    10. To create additional base entries within the LDAP user registry; repeat these steps for each base entry:

      1. Edit wkplc.properties

      2. To create additional base entries within the LDAP user registry to use when creating realms, set parameters.

        For example...

          id=MyCo_LDAP1
          baseDN=ou=admins,dc=myco,dc=com
          nameInRepository=ou=admins,dc=myco,dc=com

      3. Save changes to wkplc.properties.

      4. To create a base entry in a repository...

          ./ConfigEngine.sh wp-create-base-entry -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

    11. List the names and types of configured repositories...

        ./ConfigEngine.sh wp-query-repository

    12. To check that all defined attributes are available in the configured LDAP user registry...

        ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config

      See Adapting the attribute configuration

    13. To update the user registry where new users and groups are stored:

      If we are using multiple LDAP user registries and/or a database user registry, only run this task for the user registry to define as the default user registry where new users and groups are stored.

      1. Edit wkplc.properties

      2. Set the following required parameters under the VMM supported entity types configuration heading:

        The parameters groupParent and personAccountParent must be set to the same value.

        For example:

      3. Save changes to wkplc.properties.

      4. To delete the old attributes before adding the new attributes...

          ./ConfigEngine.sh wp-set-entitytypes -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

      To enable the full distinguished name login if the short names are not unique for the realm:

      Run this task if the administrator name is in conflict with another user name in the attached repository. This command allows the Administrator to log in using the fully distinguished name instead of the short name.

      1. Edit wkplc.properties

      2. Enter a value for realmName or leave blank to update the default realm.

      3. Save changes to wkplc.properties.

      4. To enable the distinguished name login...

          ./ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=foo

        To disable this feature...

          ./ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

    14. Optional: Update the member names used by WCM with the corresponding members in the LDAP directory.

      This step is only needed if you have installed the portal with WCM and intend to use the Intranet and Internet Site Templates that were optionally installed with the product by running configure-express.

      1. Edit...

          WP_PROFILE/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties

      2. Add the following lines to the file:

          uid=wpsadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN
          cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN

        The MemberFixerModule.properties file already contains lines for xyzadmin. We can ignore this line.

      3. Save the changes and close the file.

      4. Run...
         
        ./ConfigEngine.sh run-wcm-admin-task-member-fixer  \
                          -DallLibraries=true  \
                          -Dfix=true  \
                          -DaltDn=update  \
                          -DmismatchedId=update  \
                          -DinvalidDn=update  \
                          -DnoRealmDn=true  \
                          -DPortalAdminPwd=wpsadmin
        

        realm_name should match the value for federated.realm in wkplc.properties. If value is empty, use defaultWIMFileBasedRealm.

    15. Optional: Assign access to the Web content libraries.

      1. Log in as a portal administrator and navigate to...

          Administration | Portal Content | Web Content Libraries | web_library | Set permissions

      2. Click the Edit Role icon for Editor.

      3. Add the group specified for content_authors_group_DN as an Editor for the Intranet and Internet libraries.

      4. Click Apply then Done.

    16. If you have created any additional WCM libraries, run the Web content member fixer task to update the member names used by the libraries.

    17. Optional. Replace the WAS and portal administrator user and group IDs with users and groups that exist in the LDAP user registry. Ensure the new user ID of the WAS administrator is not identical to the one that we are replacing.

      This step is required in a production environment.

      If you run these tasks after created the cluster, run them on all nodes in the cluster.

      1. Run...
         
        ./ConfigEngine.sh wp-change-was-admin-user  \
                          -DWasUser=adminid  \
                          -DWasPassword=foo  \
                          -DnewAdminId=newadminid  \
                          -DnewAdminPw=newpassword
        

        Provide the full DN for the newAdminId parameter.

      2. Verify the task completed successfully. Stop and restart all required servers.

      3. Run...
         
        ./ConfigEngine.sh wp-change-portal-admin-user  \
                          -DWasPassword=foo  \
                          -DnewAdminId=newadminid  \
                          -DnewAdminPw=newpassword  \
                          -DnewAdminGroupId=newadmingroupid
        

        Provide the full DN for the newAdminId and newAdminGroupId parameters.

        This task verifies the user against a running server instance. If the server is stopped, to skip the validation...

          -Dskip.ldap.validation=true

      4. Update the SearchAdminUser alias to match the WebSphere Portal administrator information.

      5. Verify the task completed successfully. Stop and restart all required servers.

    18. This step is required in a production environment. Remove the file system repository if you do not use it. The federated file system user repository that was the default security setting might not be required after federating the user repository. If the file system repository is no longer needed, removing it can help prevent conflicts created by duplicate user identities existing in multiple repositories.

      See the following topic under Related for instructions: Delete the repository, which is listed with the appropriate operating system.

    If created a cluster, including additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

    How to fix Portal Access Control settings after user/group external identifiers have changed


    Add 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. We can add multiple LDAP user registries to the default federated repository although we can only add one LDAP server at a time.

    In a clustered environment, start the dmgr and nodeagent and verify they are able to synchronize.

    Use the helper file...

      WP_PROFILE/ConfigEngine/config/helpers/wp_add_federated_xxx.properties


    Add an LDAP user registry over SSL to the default federated repository

    Repeat these steps for each additional LDAP user registry to add:

    Complete these steps on the primary node only.

    1. Run backupConfig

    2. Retrieve the WAS SSL certificate

      1. Log in to the WAS admin console and go to...

          Security | SSL certificate and key management | SSL configurations

      2. Click the appropriate SSL configuration from the list. for example...

          CellDefaultSSLSettings

        Ensure the setting for SSL configuration for outbound connection matches the SSL settings.

      3. Click Key stores and certificates.

      4. Click the appropriate truststore from the list; for example...

          CellDefaultSSLSettings

      5. Click...

        ...and then enter the following information:

        • Host name used when attempting to retrieve the signer certificate from the SSL port.

        • SSL Port used when attempting to retrieve the signer certificate.

        • Alias the key store uses for the signer certificate.

      6. Click Retrieve signer information to retrieve the certificate from the port.

      7. Click OK and then click Save to save the changes to the master configuration.

    3. Edit wkplc.properties

    4. Set parameters under the VMM Federated LDAP Properties heading:

    5. Set entity types parameters...

    6. Set group member parameters...

    7. Set advanced parameters for SSL:

      Required...

      To enable the SSL configuration for the LDAP user registry, set federated.ldap.sslEnabled=true.

      Optional...

    8. Save changes to wkplc.properties.

    9. Validate the LDAP server settings...

        ./ConfigEngine.sh validate-federated-ldap -DWasPassword=foo

      In an environment configured with an LDAP with SSL, during the validation task, you will be prompted to add a signer to the truststore.

      For example...

        Add signer to the truststore now?

      If you do, press y then Enter.

    10. To add an LDAP user registry to the default federated repository...

        ./ConfigEngine.sh wp-create-ldap -DWasPassword=foo

      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.

    11. Stop and restart servers, dmgrs, and node agents.

    12. To create additional base entries within the LDAP user registry; repeat these steps for each base entry:

      1. Edit wkplc.properties

      2. To create additional base entries within the LDAP user registry to use when creating realms, set parameters.

      3. Save changes to wkplc.properties.

      4. To create a base entry in a repository...

          ./ConfigEngine.sh wp-create-base-entry -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

    13. List the names and types of configured repositories...

        ./ConfigEngine.sh wp-query-repository

    14. To check that all defined attributes are available in the configured LDAP user registry...

        ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config

      See Adapting the attribute configuration

    15. To update the user registry where new users and groups are stored:

      If we are using multiple LDAP user registries and/or a database user registry, only run this task for the user registry to define as the default user registry where new users and groups are stored.

      1. Edit wkplc.properties

      2. Set the following required parameters under the VMM supported entity types configuration heading:

        The parameters groupParent and personAccountParent must be set to the same value.

        For example:

      3. Save changes to wkplc.properties.

      4. To delete the old attributes before adding the new attributes...

          ./ConfigEngine.sh wp-set-entitytypes -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

      To enable the full distinguished name login if the short names are not unique for the realm:

      Run this task if the administrator name is in conflict with another user name in the attached repository. This command allows the Administrator to log in using the fully distinguished name instead of the short name.

      1. Edit wkplc.properties

      2. Enter a value for realmName or leave blank to update the default realm.

      3. Save changes to wkplc.properties.

      4. To enable the distinguished name login...

          ./ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=foo

        To disable this feature...

          ./ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

    16. Optional: Update the member names used by WCM with the corresponding members in the LDAP directory.

      This step is only needed if you have installed the portal with WCM and intend to use the Intranet and Internet Site Templates that were optionally installed with the product by running configure-express.

      1. Edit...

          WP_PROFILE/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties

      2. Add the following lines to the file:
        uid=wpsadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN 
        cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN

        The MemberFixerModule.properties file already contains lines for xyzadmin. We can ignore this line.

      3. Save the changes and close the file.

      4. Run...

         
        ./ConfigEngine.sh run-wcm-admin-task-member-fixer  \
                          -DallLibraries=true  \
                          -Dfix=true  \
                          -DaltDn=update  \
                          -DmismatchedId=update  \
                          -DinvalidDn=update  \
                          -DnoRealmDn=true  \
                          -DPortalAdminPwd=wpsadmin
        

        realm_name should match the value for federated.realm in wkplc.properties. If value is empty, use defaultWIMFileBasedRealm.

    17. Optional: Assign access to the Web content libraries.

      1. Log in as a portal administrator and navigate to...

          Administration | Portal Content | Web Content Libraries | web_library | Set permissions

      2. Click the Edit Role icon for Editor.

      3. Add the group specified for content_authors_group_DN as an Editor for the Intranet and Internet libraries.

      4. Click Apply then Done.

    18. If you have created any additional WCM libraries, run the Web content member fixer task to update the member names used by the libraries.

    19. Optional. Replace the WAS and portal administrator user and group IDs with users and groups that exist in the LDAP user registry.

      Before starting...

      • Review Special characters in user ID and passwords located under Planning for WebSphere Portal.
      • Ensure the new user ID of the WAS administrator is not identical to the one that we are replacing.

      This step is required in a production environment.

      If you run these tasks after created the cluster, run them on all nodes in the cluster.

      1. Run...

          ./ConfigEngine.sh wp-change-was-admin-user -DWasUser=adminid -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword

        Provide the full DN for the newAdminId parameter.

      2. Verify the task completed successfully. Stop and restart all required servers.

      3. Run...

          ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

        Provide the full DN for the newAdminId and newAdminGroupId parameters.

        This task verifies the user against a running server instance. If the server is stopped, to skip the validation...

          -Dskip.ldap.validation=true

      4. Update the SearchAdminUser alias to match the WebSphere Portal administrator information.

      5. Verify the task completed successfully. Stop and restart all required servers.

    20. This step is required in a production environment. Remove the file system repository if you do not use it. The federated file system user repository that was the default security setting might not be required after federating the user repository. If the file system repository is no longer needed, removing it can help prevent conflicts created by duplicate user identities existing in multiple repositories.

      See the following topic under Related for instructions: Delete the repository, which is listed with the appropriate operating system.

    If created a cluster, including additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.


    Add a database user registry

    Add a database user registry to the default federated repository to store user account information for authentication and authorization. We can add multiple database user registries to the default federated repository although we can only add one database user registry at a time.

    In a clustered environment, start the dmgr and nodeagent and verify they are able to synchronize.


    Add a database user registry to the default federated repository

    Repeat these steps for each additional database user registry to add.

    Complete these steps on the primary node only.

    To help ensure correct properties, we can use...

      WP_PROFILE/ConfigEngine/config/helpers/wp_add_DB.properties

    1. Run backupConfig

    2. Set up a new database, including creating a new user with appropriate database privileges:

      Database Steps
      DB2 Create a DB2 database:

      1. Install DB2.

      2. Enter the following database tuning commands:
        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"
        
      Oracle 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 the business needs:

        • db_block_size = 8192
        • db_cache_size = 300M
        • db_files = 1024
        • log_buffer = 65536
        • open_cursors = 1500
        • pga_aggregate_target = 200M
        • pre_page_sga = true
        • processes = 300
        • shared_pool_size = 200M

      SQL Server Create an SQL Server database:

      1. Install SQL Server.

      2. Set Collation to case-sensitive.

      Install SQL Server with the appropriate portal database collation so that your tempdb collation setting matches the collation we use for the property extension database. The tempdb collation is inherited from the master database, which you set when you install SQL Server.

    3. Define the DbDriver and DbLibrary parameter values:

      1. cd WP_PROFILE/ConfigEngine/properties

      2. Edit wkplc_dbtype.properties

      3. Set the following parameters under the appropriate database type properties heading:

        • db_type.DbDriver

        • db_type.DbLibrary

      4. Save the changes.

    4. Edit wkplc.properties

    5. Set parameters under the VMM Federated Database Properties heading:

    6. Set SOAP request timeout...

      1. cd WP_PROFILE/properties

      2. Edit soap.client.props

      3. Locate com.ibm.SOAP.requestTimeout and ensure the value is greater than 1000.

      4. Save and close soap.client.props.

    7. Complete the following steps:

      1. Create the local dmgr WebSphere variable used to access the database jars...

          ./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=foo -DDbDomain=federated.db -Ddb_type.DmgrDbLibrary=/path/to/db/jars -DDmgrNodeName=dmgr_node_name

        Set db_type to your database type, for example db2.

        Set path to DB jar files on the dmgr host:

        • DB2 Type 2 driver: db2java.zip
        • DB2 Type 4 driver: db2jcc4.jar;db2jcc_license_cu.jar
        • DB2 for z/OS Type 2 driver: db2java.zip
        • DB2 for z/OS Type 4 driver: db2jcc4.jar;db2jcc_license_cisuz.jar
        • Oracle: ojdbc14.jar
        • SQL Server JDBC driver: sqljdbc.jar

      2. Include each node name as a comma separated list in the command:

        Run the task: You do not have to run this task more than once. We can run this task from any node in the cluster.

        1. Set the property value for federated.db.DbType in wkplc.properties if using a database user registry or if the cell is migrated from a previous version.

        2. To create the variable used to access the VMM database jars...

            ./ConfigEngine.sh wp-node-prep-vmm-db-secured-environment -DWasPassword=foo -DDbDomain=federated.db -DVmmNodeName=node_name -Ddb_type.NodeDbLibrary=/path/to/db/jars

          VmmNodeName is a list of one or more 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 we are using, for example db2.

      3. Stop and restart all necessary servers to propagate the changes.

    8. To add a database user registry to the default federated repository...

        ./ConfigEngine.sh wp-create-db -DWasPassword=foo

      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.

    9. Stop and restart servers, dmgrs, and node agents.

    10. To update the user registry where new users and groups are stored:

      If we are using multiple LDAP user registries and/or a database user registry, only run this task for the user registry to define as the default user registry where new users and groups are stored.

      1. Edit wkplc.properties

      2. Set the following required parameters under the VMM supported entity types configuration heading:

        The parameters groupParent and personAccountParent must be set to the same value.

        For example:

      3. Save changes to wkplc.properties.

      4. To delete the old attributes before adding the new attributes...

          ./ConfigEngine.sh wp-set-entitytypes -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

    11. List the names and types of configured repositories...

        ./ConfigEngine.sh wp-query-repository

    If created a cluster, including additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.


    Add realm support

    A realm is a group of users from one or more user registries that form a coherent group within IBM WebSphere Portal. A realm must be mapped to a Virtual Portal to allow the defined users to log in to the Virtual Portal. When configuring realm support, complete these steps for each base entry that exists in the LDAP and/or database user registry to create multiple realm support.

    Before configuring realm support, 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 we are going to create multiple realms, create all required base entries within the LDAP user registries and/or database user registries. All base entry names must be unique within the federated repository.

    In a clustered environment, start the dmgr and nodeagent and verify they are able to synchronize.

    Add realm support to the user registry model:

    1. Run backupConfig.sh

    2. Edit wkplc.properties

    3. Create a new realm with default base entry.

      Set the following required parameters under the VMM realm configuration heading:

    4. Save changes to wkplc.properties.

    5. Add your new realm to the Virtual Member Manager configuration...

        ./ConfigEngine.sh wp-create-realm -DWasPassword=foo

      To create multiple realms, ensure that the federated repository contains the required unique base entries. Stop and restart the appropriate servers for the installation environment, and then update wkplc.properties with the base entry information and rerun the wp-create-realm task. Repeat these steps until all realms are created.

    6. Stop and restart servers, dmgrs, and node agents.

    7. Set the parent person, parent group, and parent organization values for your new realm...

    8. Update the default parents per entity type and realm...

        ./ConfigEngine.sh wp-modify-realm-defaultparents -DWasPassword=foo

      If you have to re-run this task to add additional entity types and realms, first stop and restart the appropriate appservers

    9. Stop and restart servers, dmgrs, and node agents.

    10. Query realm for a list of base entries:

      1. Edit wkplc.properties

      2. For realmName, set the name of the realm to query.

      3. Save changes to wkplc.properties.

      4. List the base entries for a specific realm...

          ./ConfigEngine.sh wp-query-realm-baseentry

    11. Add any additional base entries to the realm configuration.

      For example, if you have two additional base entries (base entry 1 and base entry 2) to add to the realm you just created, update wkplc.properties with the information from base entry 1 and then run this task. Then update the properties file with the information for base entry 2 and then run this task:

      1. Edit wkplc.properties

      2. Set value for new base entry under VMM realm configuration heading:

      3. Save changes to wkplc.properties.

      4. Add your LDAP base entry to the realm configuration...

          WP_PROFILE/ConfigEngine,
          ./ConfigEngine.sh wp-add-realm-baseentry -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

    12. Optional: Set the realm created as the default realm:

      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 containing the user exists in the default realm. To see what base entries are part of the default realm...

        wp-query-realm-baseentry

      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.

      1. Edit wkplc.properties

      2. For defaultRealmName, type the realmName property value to use as the default realm.

      3. Save changes to wkplc.properties.

      4. Set this realm as the default realm...

          ./ConfigEngine.sh wp-default-realm -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

    13. If you change the default realm, replace the WAS and WebSphere Portal administrator user ID to reflect the new realm:

      1. Create a new user in the Manage Users and Groups portlet to replace the current WAS administrative user.

      2. Create a new user in the Manage Users and Groups portlet to replace the current WebSphere Portal administrative user.

      3. Create a new group in the Manage Users and Groups portlet to replace the current group.

      4. Replace the old WAS admin user ID and group ID with the new user and group...

          ./ConfigEngine.sh wp-change-was-admin-user -DWasUser=adminid -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

        Provide the full DN for the newAdminId and newAdminGroupId parameters.

        To verify the user against a running server instance, run add...

          -Dskip.ldap.validation=true

      5. Verify the task completed successfully. Stop and restart all required servers.

      6. Replace the old WebSphere Portal admin user ID and group ID with the new user and group...

          ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

        Provide the full DN for the newAdminId and newAdminGroupId parameters.

        This task verifies the user against a running server instance. If the server is stopped, to skip the validation...

          -Dskip.ldap.validation=true

      7. Verify the task completed successfully. Stop and restart all required servers.

    14. If the short names are not unique for the realm, enable the full distinguished name login

      Run this task if the administrator name is in conflict with another user name in the attached repository. This command allows the Administrator to log in using the fully distinguished name instead of the short name.

      1. Edit wkplc.properties

      2. Enter a value for realmName or leave blank to update the default realm.

      3. Save changes to wkplc.properties.

      4. To enable the distinguished name login...

          ./ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=foo

        To disable this feature...

          ./ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=foo

      5. Stop and restart all necessary servers to propagate the changes.

    If created a cluster, including additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.


    Adapt the attribute configuration

    After installing IBM WebSphere Portal and configuring the LDAP user registries, adapt the attribute configuration to match the configured LDAP server(s) and the business needs.

    You do not need to perform these steps if we are using either...

    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 the LDAP server, we 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

    • Flag the attribute as unsupported for the LDAP server
    • Introduce an attribute mapping that maps the WebSphere Portal attribute to an attribute defined in the LDAP schema


    Query the defined attributes

    After installing IBM WebSphere Portal and configuring the LDAP user registries, we can query the defined attributes to see what attributes are flagged as unsupported or if the attribute is mapped to a different LDAP attribute.

    To query an overview of the currently defined attributes...

      ./ConfigEngine.sh wp-query-attribute-config -DWasPassword=foo

    This task creates the availableAttributes.html report, located in

      WP_PROFILE/ConfigEngine/log

    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.

    This task does not validate the existence of attributes in the LDAP schema.


    Add attributes

    The VMM is configured with a default attribute scheme that might not be compatible with the LDAP server. If this is the case, extend the VMM attribute schema by adding new attributes that we can map between IBM WebSphere Portal and the user registry.


    Add new attributes to the user registry

    1. Run backupConfig.sh

    2. Log on to the primary node and run...
       
      cd WP_PROFILE\ConfigEngine 
      ./ConfigEngine.sh wp-la-install-ear  \
                        -DWasPassword=dmgr_password  \
                        -DServerName=dmgr_server  \
                        -DNodeName=node_name 
      

    3. Edit wkplc.properties

    4. Set parameters under the VMM Property Extension Properties heading:

    5. Save changes to wkplc.properties.

    6. Add the attribute to the user registry...

      This task calls an EJB to WAS, which must authenticate against WAS. Depending on the configuration in the sas.client.props file, you may receive a popup window or a command line prompt asking for user identity and password. Enter the WAS user ID and password.

      Remember: For multiple properties to add, repeat all steps, except for the wp-la-install-ear task, until all new attributes are added.

    7. Stop and restart servers, dmgrs, and node agents.

    If created a cluster, including additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.


    Mapping attributes

    After configuring the LDAP user registry and querying the defined attributes, map attributes between portal and the LDAP server; for multiple LDAP servers, complete these steps for each LDAP server:

    1. Edit wkplc.properties

    2. Identify the LDAP server:

    3. Check that all defined attributes are available in the configured LDAP user registry:

        cd WP_PROFILE/ConfigEngine
        ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config -DWasPassword=foo

    4. Edit...

        WP_PROFILE/ConfigEngine/log/ConfigTrace.log

      ......and review the following output for the PersonAccount and Group entity type:

        The following attributes are defined in WebSphere Portal but not in the LDAP server

        This list contains attributes 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 to use to the attributes that exist in the LDAP; 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 attributes defined as "MUST" in the LDAP server but not as required in WebSphere Portal. You should flag these attributes as required within WebSphere Portal;

        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.

    5. Edit wkplc.properties

    6. Enter a value for one of the following sets of parameters in wkplc.properties to correct any issues found in the config trace file:

      For example, the following values flag certificate and members as unsupported attributes and map ibm-primaryEmail to mail and ibm-jobTitle to title for both the PersonAccount and Group entityTypes:

    7. Save changes to wkplc.properties.

    8. Update the LDAP user registry configuration with the list of unsupported attributes and the proper mapping between WebSphere Portal and the LDAP user registry:

        cd WP_PROFILE/ConfigEngine
        ./ConfigEngine.sh wp-update-federated-ldap-attribute-config -DWasPassword=foo

    9. Stop and restart servers, dmgrs, and node agents.

    10. Optional: Flag an attribute as either unsupported or required for the entire WebSphere Portal environment instead of just for the specified LDAP:

      1. Set parameters in wkplc.properties:

      2. Save changes to wkplc.properties.

      3. cd WP_PROFILE/ConfigEngine
        ./ConfigEngine.sh wp-update-attribute-config -DWasPassword=foo

      4. Stop and restart all necessary servers to propagate the changes.

    If created a cluster, including additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.


    Remove attributes

    Due to a Virtual Member Manager (VMM) limitation, there is currently no task to update an attribute. If we added an attribute to the property extension database or when adapting attributes to match the LDAP server that were spelled incorrectly or already added due to migration, remove the attribute from the database. Use caution when performing these steps.

    To remove an attribute from the database:

    Do not remove attributes that have already been populated with user values because this can cause database inconsistencies.

    Cluster note: In a clustered environment on the dmgr and then resynch the nodes.

    1. Run backupConfig

    2. To remove an attribute stored in a property extension database:

      1. Open the tool we use to edit the database.

      2. Verify the attribute name is available in the LAPROP table.

      3. Delete the required attributes from the LAPROP table.

      4. Edit WP_PROFILE/config/cells/cellname/wim/model/wimxmlextension.xml

      5. Delete the propertySchema definition for the attributes 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>
        

      6. Save the changes to wimxmlextension.xml.

      7. Edit WP_PROFILE/config/cells/cellname/wim/config/wimconfig.xml

      8. Delete the attributes or propertiesNotSupported definitions for the attributes deleted from the LAPROP table.

        For example:

        <config:attributes name="attribute_name" propertyName="attribute_name">
        <config:entityTypes> PersonAccount </config:entityTypes>
        <config:entityTypes> Group </config:entityTypes>
        </config:attributes>
        
        or
        <config:propertiesNotSupported name="attribute_name">
        

      9. Save the changes to wimconfig.xml.

      10. Stop and restart the WebSphere_Portal server

    3. To remove an attribute that is not stored in a property extension database:

      1. Open wimxmlextension.xml.

      2. Delete the propertySchema definition for the attributes you previously added:
        <wim:propertySchema nsURI="http://www.ibm.com/websphere/wim" dataType="String"
                multiValued="true" propertyName="attribute_name">
           <wim:applicableEntityTypeNames>PersonAccount</wim:applicableEntityTypeNames>
            </wim:propertySchema>
        

      3. Save the changes to wimxmlextension.xml.

      4. Edit wimconfig.xml

      5. Delete the stanza that corresponds to the custom attribute you deleted from wimextension.xml; for example:
        <config:attributes name="attribute_name" propertyName="property_name">
                    <config:entityTypes>PersonAccount</config:entityTypes>
         </config:attributes>
        

      6. Save the changes to wimconfig.xml.

      7. Stop and restart the WebSphere_Portal server.


    Configure 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 the LDAP server configured to use dynamic groups, complete the steps in this task for WebSphere Portal to use dynamic group queries when you setup the LDAP server.

    Perform the required tasks to configure either a stand-alone or federated LDAPserver 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 the LDAP server. For this reason, you should export an LDIF file to verify the object classes and dynamic membership attributes.

    Perform the following steps on the dmgr then synchronize the nodes.

    1. Log in to the WAS admin console.

    2. Select Security > Global security.

    3. In Available realm definitions, select Federated repositories and click Configure.

    4. In Related Items, click Manage repositories.

    5. Select the appropriate repository from the list.

    6. In 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,

      • Name: memberurl
      • Object class: groupofurls

    8. Click OK and save the changes to the master configuration.

    9. Stop and restart servers, dmgrs, and node agents.


    Enable 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 the environment has more than one user registry existing on multiple servers or domains.


    Configure the portal to use LDAP referrals

    1. Run backupConfig

    2. Open a UNIX System Services (USS) command prompt.

    3. Edit wkplc.properties

    4. Specify values for the following parameters:

    5. Save and close wkplc.properties.

    6. Create an LDAP entity type:

        ./ConfigEngine.sh wp-update-et-ldap -DWasPassword=foo

    7. Stop and restart servers, dmgrs, and node agents.


    Prepare additional cluster members

    After installing and configuring the primary node, we can create the additional cluster nodes. 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.


    Install WebSphere Portal on AIX for the horizontal cluster nodes

    Install IBM WebSphere Portal on the additional cluster nodes to create a highly available and scalable environment. On additional nodes, you only need to install the WebSphere Portal product binary files. The WebSphere Portal application server and applications are added after the node is federated and a new cluster member is created.

    Review the System requirements for the operating system and ensure that all hardware and software matches the minimum product level before installing WebSphere Portal.


    Additional node: Install with GUI

    We can use the Installation Manager to help install IBM WebSphere Portal and IBM WAS on your additional nodes. The Installation Manager gathers essential information, such as host name and node, verifies the operating system and its prerequisites, available disk space, and any required software prerequisites, and then performs the installation.

    The main difference when installing additional nodes, select option: Product binaries only

    The bit architecture of the installation program uses:

    • The bit architecture of the operating system
    • The bit architecture of the existing WAS

    When you install onto a 64-bit operating system, WebSphere Portal installs as a 64-bit version. We can force a 32-bit application installation onto a 64-bit operating system.


    Use the IBM Installation Manager for installation

    1. Verify the fully qualified host name...

        ping myserver.myco.com

    2. Verify network configuration...

        ping localhost

    3. For servers with a firewall, antivirus, screen saver, and/or desktop search engine enabled, disable them before installing.

    4. Install IBM Installation Manager:

      • GUI...

          ./install

      • Silently...

          ./userinstc -acceptLicense \ -log /tmp/install.log

      • From Portal Setup disk...

          ./setup.sh

        To change display language, add the LaunchPadLocale language code.

        To search for IBM Installation Manager updates, navigate to...

          File > Update

    5. Add the repositories where the installation media exists:

      1. Open the IBM Installation Manager and navigate to...

          File > Preferences > Repositories > Add Repositories > Browse > IBM WebSphere Application service repository > OK

      2. Ensure all required repositories are checked.

      3. Click Test Connections.

      4. Select Apply.

      5. Select OK.

    6. On the main IBM Installation Manager panel, select Install to begin the installation process.

      1. On the panel...

          Select packages to install

        ...select both the WAS and WebSphere Portal packages.

      2. Click Next.

      3. Accept the license agreement and then click Next.

      4. Select shared resources directory and then click Next.

      5. Set Installation Directory:

        1. Select the WAS Package Group Name and then select the installation directory path.

        2. Select the WebSphere Portal Package Group Name and then select the installation directory path.

        3. Click Next.

      6. Select the translations to install and then click Next.

      7. On the panel...

          Select the features to install

        ...expand the WAS and WebSphere Portal packages

        Expand the WebSphere Portal package and deselect the feature...

          Create a new Portal Server Profile

        A full WebSphere Portal server is not currently required. We create the custom profile later.

      8. Confirm the information on the Summary panel and then click Install.

    7. Verify the installation successfully created the WebSphere Portal file system.

      Because the WebSphere Portal profile was not created, the WebSphere_Portal server does not exist. We create the server when adding the node to the cluster.


    Additional node: Install with response file

    First install IBM Installation Manager. Then use a response file to install IBM WebSphere Portal and IBM WAS on your additional nodes.

    Install type should be Portal Server Binary.

    Record response files on the same OS you plan for the installation. For multiple operating systems, record a response file for each operating system.

    The bit architecture of the installation program uses:

    • The bit architecture of the operating system
    • The bit architecture of the existing WAS

    When you install onto a 64-bit operating system, WebSphere Portal installs as a 64-bit version. We can force a 32-bit application installation onto a 64-bit operating system.


    Use a response file for installation

    1. Verify the fully qualified host name...

        ping myserver.myco.com

    2. Verify network configuration...

        ping localhost

    3. For servers with a firewall, antivirus, screen saver, and/or desktop search engine enabled, disable them before installing.

    4. Install IBM Installation Manager:

      • GUI...

          ./install

      • Silently...

          ./userinstc -acceptLicense -log /tmp/install.log

      • From Portal Setup disk...

          ./setup.sh

        To change display language, add the LaunchPadLocale language code.

        To search for IBM Installation Manager updates, navigate to...

          File > Update


    Record a response file using Installation Manager menu

    To record our own reponse file using Installation Manager menus...

    1. Launch installation manager with -record option...

        ./IBMIM -record responsefile.xml -skipInstall /path/to/install/directory

      This step does not install WebSphere Portal. You are only recording the response file used to install portal later.

    2. Navigate through the IBM Installation Manager panels and set values for the environment.

      Before adding the repositories, make sure they are located in a directory accessible to all required computers.

      On the panel...

        Select the features to install

      ...keep the default selection checked to create a new Portal server profile.

    3. On the panel...

        Select packages to install

      ...select both the WAS and WebSphere Portal packages.

    4. Click Next.

    5. Accept the license agreement and then click Next.

    6. Select shared resources directory and then click Next.

    7. Set Installation Directory:

      1. Select the WAS Package Group Name and then select the installation directory path.

      2. Select the WebSphere Portal Package Group Name and then select the installation directory path.

      3. Click Next.

    8. Select the translations to install and then click Next.

    9. On the panel...

        Select the features to install

      ...expand the WAS and WebSphere Portal packages

      Expand the WebSphere Portal package and deselect the feature...

        Create a new Portal Server Profile

      A full WebSphere Portal server is not currently required. We create the custom profile later.

    10. Confirm the information on the Summary panel and then click Install.

    11. After the Installation Manager finishes creating the response file, click Finish and then close the Installation Manager to complete the response file recording.

    12. If installing on a different computer, copy the response file to the response file directory on that computer.

    13. If the repository URL requires authentication, use imutilsc.sh to create a keyring file store for credentials.

      The keyring file stores the credentials required for the repositories. The IBM Installation Manager command-line tool imutilsc is available from the installation tools directory.

      ./imutilsc saveCredential  \
                 -url repository_URL  \
                 -userName credential_userName \
                 -userPassword password  \
                 -keyring keyring_file  \
                 [ -password keyringfile_password ] \
                 [ -proxyHost proxy_host -proxyPort proxy_port \
                 [ -proxyUsername proxy_username -proxyUserPassword proxyuser_password ] \
                 [ -useSocks ] ] \
                 [ -verbose ]
      

      If installing on a different computer, copy the keyring file to that computer.

    14. Install WebSphere Portal and IBM WAS...

        ./imcl -acceptLicense -input /path/to/response.xml -log /path/to/log/files

      To use your repository keyring file...

        -keyring /path/to/keyring -password keyringfile_password

    15. Verify the installation successfully created the WebSphere Portal file system.

      Because the WebSphere Portal profile was not created, the WebSphere_Portal server does not exist. We create the server when adding the node to the cluster.

    Sample response files are in SETUP_ROOT/responsefiles.


    Add the horizontal cluster node to the cluster

    1. Log on to primary node and copy profileTemplates.zip to secondary node...

        cd $PORTAL_HOME/profileTemplates/
        scp profileTemplates.zip addtl_host:$PORTAL_HOME/profileTemplates

    2. Extract the profileTemplates.zip file in the same location.

      If any of the templates already exist in the profileTemplates directory, overwrite them.

    3. Because some files are set to read-only after the copy operation, open permissions...

        chmod -R 755 PORTAL_HOME/profileTemplates

    4. Install the copied profile template...

        cd PORTAL_HOME/profileTemplates
        ./installPortalTemplates.sh

      This task localizes the profile templates to the current environment

    5. Create a profile wp_profile...
      cd WAS_HOME/bin
      ./manageprofiles.sh -create  \
                          -templatePath /usr/IBM/WebSphere/PortalServer/profileTemplates/managed.portal \
                          -profileName testManagedPortal1 \
                          -profilePath /usr/IBM/WebSphere/PortalServer/profiles/testManagedPortal1 \
                          -cellName testCell \
                          -nodeName testNode02 \
                          -hostName myportal.myco.com
      

      We use a Node Name that is different than what was used for primary node.

      Ensure wkplc_dbdomain.properties and wkplc_dbtype.properties files have correct database information. These files should match the database information defined in the primary node. Copy the database drivers on the primary node to the same location on the additional cluster node. We can find the location of the database drivers in wkplc_dbtype.properties.

    6. Validate the database settings...

        ./ConfigEngine.sh validate-database -DWasPassword=foo

    7. Edit...

        WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

      ...and set...

        jcr.textsearch.enabled = false

    8. Federate the additional cluster node:

        ./addNode.sh dmgr_hostname dmgr_port -username wasadmin -password foo

      If the WAS administrator user ID and password for the local node are different from the dmgr, add the following parameters:

      • -localusername local_wasadmin
      • -localpassword local_foo

    9. Ensure the following parameters are set correctly in wkplc.properties:

        WasUserid = dmgr administrator ID.
        WasPassword = dmgr administrator password.
        WasRemoteHostName = fully qualified host name of the dmgr.
        WasSoapPort = SOAP port that the dmgr is using; the default value is 8879.
        ServerName = Default is WebSphere_Portal. We can change this on additional nodes.
        PrimaryNode = false
        ClusterName = primary node's ClusterName.

    10. Add the node to your cluster...

        ./ConfigEngine.sh cluster-node-config-cluster-setup-additional -DWasPassword=dmgr_password

    11. To access the WCM content through an external web server:

      1. Log on to the dmgr console and select...

          Environment | WebSphere Variables | Scope drop-down menu | Node=nodename, Server=servername

        Set variables...

          WCM_HOST - fully qualified host name used to access the portal server through the web server or On Demand Router.
          WCM_PORT - port number used to access the portal server through the web server or On Demand Router.
          WCM_HOST and WCM_PORT - for each additional portal server that already exists in the cluster.

      2. Synchronize the node with the dmgr:

          System Administration | Nodes | node | Full Resynchronize

      3. Log off of the dmgr console.

    12. Propagate changes:

      WebSphere_Portal is the name of the node's WebSphere Portal server; but if you customized the server name, the default name changes. If we are uncertain of the server name, run the task...

        serverstatus -all

      ...to get a list of the server names and their status.

        ./stopServer.sh WebSphere_Portal -username wpadmin -password foo
        ./startServer.sh WebSphere_Portal


    Add a horizontal node to the dynamic cluster

    After creating the dynamic cluster, we can add horizontal nodes to expand the capacity of the dynamic cluster. Install and configure the horizontal node, then add it to the existing dynamic cluster node group, and then add it to the existing IBM WebSphere Virtual Enterprise dynamic cluster.


    Add an horizontal node to the WebSphere Virtual Enterprise dynamic cluster

    1. To create a directory to store templates:

      1. Copy...

          PORTAL_HOME/profileTemplates/profileTemplates.zip

        ...on the primary node to the same location on the additional cluster node.

      2. Extract the profileTemplates.zip file in the same location. If any of the templates already exist in the profileTemplates directory, overwrite them.

      3. Because some files are set to read-only after the copy operation, open permissions...

          chmod -R 755 PORTAL_HOME/profileTemplates

      4. To install the copied profile template...

          cd PORTAL_HOME/profileTemplates
          ./installPortalTemplates.sh

        This task localizes the profile templates to the current environment and registers them with the pmt.sh if it exists on the server.

    2. Create a profile used for additional cluster members:

      Choose a Node Name that is different from what you entered for the primary node.

      • pmt.sh

        1. Run...

            cd WAS_HOME/bin/ProfileManagement
            ./pmt.sh

        2. Click Launch Profile Management Tool

        3. Click Create to create a profile.

        4. On the Environment Selection panel, select the...

            WebSphere Portal 8.0.0 | Custom Portal profile

        5. Select the button...

            Advanced profile creation

        6. On the panel...

            Profile Name and Location

          ...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 panel...

            Node and Host Names

          ...provide the node name and TCP/IP host name for the new profile.

          To federate this profile, the node name must be unique from other profiles in the same management cell (under dmgr control). The host name must be valid and reachable over the network. Click Next to continue.

        8. On the Federation panel to federate the node in the future, check the check box...

            Federate this node later

          Do not enter the values for the dmgr to federate now as this will cause an unusable portal node.

        9. On the panel...

            Profile Creation Summary

          ...review the information collected by the wizard, and then click Create to create the profile with WebSphere Portal.

        10. Click Finish to exit PMT.

      • manageprofiles.sh
        cd WAS_HOME/bin
        ./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 \
        

    3. Install WebSphere Virtual Enterprise and augment the newly created profile.

      See the "Planning the product installation" link in the Related section for information about installing WebSphere Virtual Enterprise. Profile augmentation is performed using the pmt.sh GUI on systems that support it or through manageprofiles.sh available on all systems. When using the GUI select type of augmentation..

        Operations Optimization

      Use manageprofiles.sh to augment a stand-alone application server profile from the command-line

    4. To ensure that the database information is correct and to ensure a successful additional node:

      1. Ensure that the wkplc_dbdomain.properties and wkplc_dbtype.properties files have the correct database information in them.

        The wkplc_dbdomain.properties and wkplc_dbtype.properties files should match the database information defined in the primary node.

      2. Copy the database drivers on the primary node to the same location on the additional cluster node. We can find the location of the database drivers in wkplc_dbtype.properties.

    5. Validate the database settings...

        ./ConfigEngine.sh validate-database -DWasPassword=foo

      Add -DTransferDomainList to the validate-database task to specify the domains to validate; for example...

        -DTransferDomainList=jcr

      To validate all domains, you do not need to specify this parameter on the command line.

    6. Federate the additional cluster node:
        ./addNode.sh dmgr_hostname dmgr_port -username wasadmin -password foo

    7. Ensure the following parameters are set correctly in wkplc.properties:

      Although we can add these parameters (particularly passwords) directly to any task while creating the cluster, we might want to temporarily add them to the properties file. We can then remove them when we are finished to keep the environment secure.

      1. WasUserid is set to the dmgr administrator ID.
      2. WasPassword is set to the dmgr administrator password.
      3. WasRemoteHostName is set to the fully qualified host name of the dmgr.
      4. WasSoapPort is set to the SOAP port that the dmgr is using; the default value is 8879.
      5. ServerName is set to the correct server name. The default is WebSphere_Portal but we can change this on the additional nodes.
      6. PrimaryNode is set to false.
      7. ClusterName is set to the primary node's ClusterName.

    8. If we configured a database user registry or a property extension database on the dmgr, set up access to the database drivers:

      1. 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 wkplc.properties.

        If you migrated the primary node from a version prior to Version 6.1.0 and we 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 wkplc.properties on the primary node.

      2. To add the library paths to the VMM_JDBC_CLASSPATH variable:

        1. Log on to the WAS WAS admin 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/db2jcc4.jar:SQLLIB/java/db2jcc_license_cu.jar

        6. Copy files set for the VMM_JDBC_CLASSPATH variable into the appserver/lib directory.

        7. Stop and restart the appropriate servers to propagate the changes.

      3. Create the local dmgr WebSphere variable used to access the database jars...

          ./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=foo -DDbDomain=la|federated.db -Ddb_type.NodeDbLibrary=/path/to/dmgr/jars -DDmgrNodeName=dmgr_node_name

        Set db_type to your database type, for example db2. The /path/to/db/jars should be one of the following options:

        • DB2 Type 2 driver: db2java.zip
        • DB2 Type 4 driver: db2jcc4.jar;db2jcc_license_cu.jar
        • DB2 for z/OS Type 2 driver: db2java.zip
        • DB2 for z/OS Type 4 driver: db2jcc4.jar;db2jcc_license_cisuz.jar
        • Oracle: ojdbc14.jar
        • SQL Server JDBC driver: sqljdbc.jar

      4. Create the variable used to access the VMM database jars...

          ./ConfigEngine.sh wp-node-prep-vmm-db-secured-environment -DWasPassword=dmgr_password -DDbDomain=la|federated.db -DVmmNodeName=node_name -Ddb_type.NodeDbLibrary=/path/to/db/jars

        VmmNodeName is a list of one or more 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 we are using, for example db2.

    9. The node is federated and using the dmgr cell and its user registry. If the admin user ID and group name are different in the WebSphere Portal and dmgr configurations, choose one of the following options depending on your security policies:

      • Add the existing admin user ID and group to the dmgr security configuration

      • To change the values in the WebSphere Portal configuration to match the dmgr values:

      If the dmgr cell is using a stand-alone LDAP user registry, complete these steps after the cluster-node-config-cluster-setup-additional (static cluster) or cluster-node-config-dynamic-cluster-setup-additional (dynamic cluster) task completes.

      1. Start the WebSphere_Portal server.

      2. Verify the required WebSphere Portal admin user ID and group ID are defined in the dmgr user registry that provides security for the cell.

      3. Run...

          ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

        If the value for newAdminGroupId contains a space; for example Software Group, open wkplc.properties and add the values for newAdminId, newAdminPw, and newAdminGroupId. Save the changes and then run...

          ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=dmgr_password

        • WasPassword is set to the administrative password for the dmgr cell
        • newAdminId is set to the fully qualified DN of the WebSphere Portal admin user ID in the cell
        • newAdminGroupId is set to the fully qualified DN of the group for the WebSphere Portal admin user ID in the cell

      4. After the task completes, stop the WebSphere_Portal server.

    10. Run...

        ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password

    11. Log on to the dmgr console.

    12. To add members to the node group:

      1. Click System administration > Node groups.

      2. Click the name of the node group to add members to.

      3. Click Node group members under Additional Properties.

      4. Click Add.

      5. Select the additional node to add into the node group and then click Add.

      6. Click the Save link to save the changes to the master configuration.

    13. Set the following parameters in wkplc.properties:

      1. Verify that ClusterName is set to the name of the existing dynamic cluster.

      2. Verify that CellName is set to the dmgr cell.

      3. Verify that NodeName is set to the local node.

      4. Set ServerName to the server used for the dynamic cluster member on this node.

        Log on to the dmgr console find the name of the server used for the dynamic cluster...

          Servers | Clusters | Dynamic Clusters | PortalCluster | Dynamic cluster members

      5. Verify that PrimaryNode is set to false because this is an additional node.

    14. Tune the additional cluster resources...

        ./ConfigEngine.sh dynamic-cluster-setup-additional -DWasPassword=dmgr_password

    15. To start the cluster member:

      1. Log on to the dmgr console.

      2. Navigate to Servers > Dynamic clusters > cluster name > Dynamic cluster members.

      3. Select the cluster member and click Start.

      4. Log off of the dmgr console.

    16. To access the WCM content through an external web server:

      1. Log on to the dmgr console.

      2. Select Environment > WebSphere Variables.

      3. From the Scope drop-down menu, select the option...

          Node=nodename, Server=servername

        ...where Node=nodename is the node containing the portal application server.

      4. Update the WCM_HOST variable with the fully qualified host name used to access the portal server through the web server or On Demand Router.

      5. Update the WCM_PORT variable with the port number used to access the portal server through the web server or On Demand Router.

      6. Update the WCM_HOST and WCM_PORT variable for each additional portal server that already exists in the cluster.

      7. Synchronize the node with the dmgr:

        1. Select System Administration > Nodes.

        2. Select the node to synchronize from the list.

        3. Click Full Resynchronize.

      8. Log off of the dmgr console.

    17. Propagate changes:

      WebSphere_Portal is the name of the node's WebSphere Portal server; but if you customized the server name, the default name changes. If we are uncertain of the server name, run the task...

        serverstatus -all

      ...to get a list of the server names and their status.

        ./stopServer.sh WebSphere_Portal -username wpadmin -password foo
        ./startServer.sh WebSphere_Portal

    18. If you entered passwords in any of the properties files while creating the cluster, you should remove them for security purposes. See "Deleting passwords from properties files" under Related for information.


    Add vertical cluster members to a static cluster

    We can add vertical cluster members to share the workload demands of the cluster across multiple members running on the same physical machine.

    1. Log into the dmgr console.

    2. Click...

        Servers > Clusters > WebSphere appserver clusters > cluster_name > Cluster members

    3. Click New to create the cluster member.

      1. Define the name of cluster member.

        Do not use spaces in the cluster member name.

      2. Select an existing node where IBM WebSphere Portal is installed.

      3. Check the box...

          Generate Unique HTTP Ports

      4. Click Add Member and then click Next to view the summary.

      Update the virtual host entries for the new port created when adding a cluster member. We can do this by updating the default_host virtual host in the WAS admin console and adding a new alias entry for the port number (use an "*" wildcard character for the host name). See Configure 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 appservers view lists the new server cluster members.

    5. To enable cache replication:

      1. From the dmgr console, go to Servers > Server Types > WebSphere appservers and then click the new vertical cluster member(s).

      2. Click Dynamic cache service under Container services.

      3. Change Cache size to 3000 entries.

      4. Check the Enable cache replication check box.

      5. Select NOT_SHARED from the Replication type drop-down menu.

      6. Click OK.

      7. Click Save to save the 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:

      1. On the node where created the vertical cluster...

          ./ConfigEngine.sh cluster-node-config-vertical-cluster-setup -DServerName=unique vertical cluster servername -DWasPassword=foo

        unique vertical cluster servername is the name you specified when created the cluster member.

      2. Restart the vertical cluster member referenced in the cluster-node-config-vertical-cluster-setup task.

    7. Save the changes and resynchronize the nodes.

      1. In the dmgr console, click Save on the task bar, and save the administrative configuration.

      2. Select System Administration > Nodes, select the node from the list, and click Full Resynchronize.

    8. Regenerate the web server plug-in.

      1. Regenerate the web server plug-in using the dmgr console.

      2. If we 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.


    Add a vertical cluster member to the clustered environment

    1. Open a browser and enter http://DM01:9060/ibm/console in the address bar to access the dmgr console, where DM01 is the dmgr node or host name. The port number might differ based on the installation.

    2. To allow vertical clusters on the dynamic cluster:

      1. Navigate to Servers > Clusters > Dynamic clusters and select the appropriate dynamic cluster.

      2. Select the Allow more than one instance to start on the same node check box under Vertical stacking of instances on node.

      3. Enter a new value in the Number of instances text box to determine the number of vertical cluster members allowed on each node.

      4. Click Apply and then click Save to save the changes to the master configuration.

      5. Optional: Navigate to Servers > Clusters > Dynamic Clusters > clustername > Cluster Members view to view the list of new cluster members.

      • The new cluster topology can be viewed from the Servers > Clusters > Cluster Topology view.

      • The Servers > Server Types > WebSphere appservers view lists the new server cluster members.

      Update the virtual host entries for the new port created when adding a cluster member. We can do this by updating the default_host virtual host in the WAS admin console and adding a new alias entry for the port number (use an "*" wildcard character for the host name). See Configure virtual hosts for information.

    3. To enable cache replication:

      1. From the dmgr console, go to Servers > Server Types > WebSphere appservers and then click the new vertical cluster member(s).

      2. Click Dynamic cache service under Container services.

      3. Change Cache size to 3000 entries.

      4. Check the Enable cache replication check box.

      5. Select NOT_SHARED from the Replication type drop-down menu.

      6. Click OK.

      7. Click Save to save the changes to the master configuration.

    4. Complete the following steps on each vertical cluster member to clean up the server-scoped resources, caches, and resource providers:

      1. On the node where created the vertical cluster...

          ./ConfigEngine.sh cluster-node-config-vertical-cluster-setup -DServerName=unique vertical cluster servername -DWasPassword=foo

        unique vertical cluster servername is the name you specified when created the cluster member.

      2. Restart the vertical cluster member referenced in the cluster-node-config-vertical-cluster-setup task.

    5. Save the changes and resynchronize the nodes.

      1. In the dmgr console, click Save on the task bar, and save the administrative configuration.

      2. Select System Administration > Nodes, select the node from the list, and click Full Resynchronize.

    6. Stop and start the web server.


    Tune the servers

    WebSphere Portal is not tuned for a production environment out of the box. To ensure optimal performance, review and complete the steps in the Portal Tuning Guide. If a tuning guide is not available for the current release, the tuning guide for the previous product version should be used.

    The tuning guide will help you to:

    • Configure the application server and the resources defined for that application server
    • Determine the cloning strategy for expanding or extending the environment
    • Tune the database
    • Tune the directory server and its database
    • Tune the Web server
    • Tune the operating system and network
    • Tune the WebSphere Portal services


    Configure search in a cluster

    IBM WebSphere Portal provides two distinct search capabilities. We can use both types of search capabilities .


    Configure remote search

    1. Install and configure the search service to work remotely, that is, on a remote WAS node which is not part of the portal cluster. We 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 WAS node.

    2. Configure the search portlets for remote search service so that they access the remote server accordingly.

    1. If you have configured a remote search service for a portal cluster, 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 configuring 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.


    Configure JCR search in a cluster

    To enable search in a cluster for content stored in the JCR database, 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 dmgr 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...

        WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

    2. Change the value of the property...

        jcr.textsearch.indexdirectory

      ...to the shared directory; for example...

      jcr.textsearch.indexdirectory=\\\\your_server\\your_share\\jcr\\search. We can specify the shared directory value in one of the following formats:

      Format Shared directory
      UNC \\\\your_server\\your_share\\jcr\\search

      Example: \\\\hostname.example.com\\share\\jcr\\search

      Mounted resource /your_share/jcr/search

      For example: /mnt/jcr/search

      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 the remote search service, change the property...

        jcr.textsearch.PSE.type

      ...to either EJB or SOAP; then choose the appropriate additional steps:

      Value Additional steps
      EJB

      1. Change property...

          jcr.textsearch.EJB.IIOP.URL

        ...to the URL of the naming service used to access the WebScanner EJB; for example...

          iiop://localhost:2811

      2. Change property...

          jcr.textsearch.EJB.EJBName

        ...to the name of the WebScanner EJB; for example...

          ejb/com/ibm/hrl/portlets/WsPse/WebScannerLiteEJBHome

      SOAP Change the property...

        jcr.textsearch.SOAP.url

      ...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: To delete the default search collections from the Manage Search portlet:

      1. Log on to WebSphere Portal as an administrator.

      2. Click...

      3. Restart the WebSphere_Portal server.

      4. Go to the Manage Search portlet and confirm that the Portal Content search collection was deleted.

      5. Manually create a JCR Collection called JCRCollection1; refer to Setting up JCR Search Collection for information.


    Set up multiple clusters

    The majority of the steps to build another cluster are the same as when building the first cluster in the same cell, with a few exceptions. Basically, the new profile will be designated as the primary profile, using IBM WebSphere Portal clustering terminology, and will then be used as the basis for the new cluster definition. This duplicates the build process of the first cluster in the cell. During the federation process, if any applications on this new node already exist in the cell (because they are in use by the first cluster), then dmgr 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.


    Install multiple clusters in a single cell - multiple clusters

    Create a new, independent IBM WebSphere Portal cluster in a cell where a WebSphere Portal cluster already exists.

    In the following steps, Cluster A is used to describe the existing cluster. Portal B is used to describe the new server profile that is the basis for the new cluster definition, Cluster B.

    To install multiple clusters in a single cell:

    1. If necessary, upgrade Cluster A, including the dmgr node, to the current, supported hardware and software levels and to the current version of IBM WebSphere Portal. Only upgrade if Cluster B is at a higher version than the existing Cluster A.

    2. Complete the following tasks to install and configure Portal B; see the links in Related:

      Important: Maintain the same number of data sources with identical names to the Cluster A data sources so that data source bindings in the applications can be resolved on every cluster in which they run. If implementing database sharing across the clusters, the previous statement refers to both the shared and non-shared domains; all domains should use the same names.

      • Install WebSphere Portal on the primary node

      • Configure Portal to use a database

    3. Optional: Use 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 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 wkplc_comp.properties, including user ID and password.

    4. If necessary, upgrade Portal B to the current cumulative fix.

    5. If we are adding a dynamic cluster and IBM WebSphere Virtual Enterprise is not already installed on Portal B, install it, apply all required ifixes, and augment the wp_profile profile to make it compatible with WebSphere Extended Deployment Operations Optimization.

      See the "Planning the product installation" link in Related section for information about installing WebSphere Virtual Enterprise. Profile augmentation is completed using the pmt.sh (PMT) GUI on systems that support it or through manageprofiles.sh available on all systems. When using the GUI, make sure we select type of augmentation..

        Operations Optimization

      When using manageprofiles.sh, be sure to follow the instructions to augment a stand-alone application server profile.

    6. To build an inventory list of Portal B enterprise applications and portlets...

        ./ConfigEngine.sh mapped-app-list-create -DWasPassword=foo

    7. If the dmgr is configured to use a stand-alone LDAP user registry, update wkplc.properties, located in...

        WP_PROFILE/ConfigEngine/properties

      on the primary node with the stand-alone LDAP user registry property values from the dmgr.

      Set WasUserid and WasPassword to the dmgr user ID and password.

    8. Federate Portal B...
      cd WP_PROFILE/bin 
      ,/addNode.sh dmgr_hostname  \
                 dmgr_port  \
                 -includeapps \
                 -username wasadmin   \
                 -password foo
      
      dmgr_hostname is the TCP/IP host name of the dmgr server. dmgr_port is the SOAP port number of the dmgr server. wasadmin and foo are the user ID and password for the dmgr administrator

      If the WAS administrator user ID and password for the local node are different than the dmgr administrator user ID and password, add the following parameters:

      • -localusername local_wasadmin
      • -localpassword local_foo

      See the addNode command file for more information about the addNode command and other optional parameters.

      If addNode.sh fails for any reason, complete the following steps before rerunning the task:

      1. Remove the node if the AddNode task succeeded in creating the node.

      2. If items exist, log on to the dmgr and...

        1. Remove all enterprise applications.

        2. Remove the WebSphere_Portal server definition.

        3. Remove the WebSphere Portal JDBC Provider.

    9. Stop the WebSphere_Portal server on the primary node and verify the following parameters are set correctly in wkplc.properties:

      Although we can add these parameters (particularly passwords) directly to any task while creating the cluster, we might want to temporarily add them to the properties file. We can then remove them when we are finished to keep the environment secure.

      1. Set WasSoapPort to the port used to connect remotely to the dmgr.

      2. Set WasRemoteHostName to the full host name of the server used to remotely connect to the dmgr.

      3. Verify that WasUserid is set to the dmgr administrator user ID.

      4. Verify that WasPassword is set to the dmgr administrator password.

      5. Verify that PortalAdminPwd is set to the WebSphere Portal administrator password.

      6. Verify that ClusterName is set.

      7. Verify that PrimaryNode is set to true.

    10. ./ConfigEngine.sh map-apps-to-server -DWasPassword=foo task to determine which applications from the inventory list are no longer mapped to Portal B. The task uses the application profiles already in the cell to restore the mappings. Wait 30 minutes after running this task to allow all EAR files to expand before proceeding to the next step.

    11. Complete the following post-federation configuration steps for Portal B:

      1. Ensure all database parameters are correctly set, including passwords, in the wkplc_comp.properties and wkplc_dbtype.properties files.

      2. Run...

          ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password

      3. The node is federated and using the dmgr cell and its user registry. If the admin user ID and group name are different in the WebSphere Portal and dmgr configurations, choose one of the following options depending on your security policies:

        If the dmgr cell is using a stand-alone LDAP user registry, complete these steps after the cluster-node-config-cluster-setup (static cluster) or cluster-node-config-dynamic-cluster-setup (dynamic cluster) task completes.

        1. Start the WebSphere_Portal server.

        2. Verify the required WebSphere Portal admin user ID and group ID are defined in the dmgr user registry that provides security for the cell.

        3. Run...

            ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

          If the value for newAdminGroupId contains a space; for example Software Group, open wkplc.properties and add the values for newAdminId, newAdminPw, and newAdminGroupId. Save the changes and then run...

            ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=dmgr_password

          • WasPassword is set to the administrative password for the dmgr cell
          • newAdminId is set to the fully qualified DN of the WebSphere Portal admin user ID in the cell
          • newAdminGroupId is set to the fully qualified DN of the group for the WebSphere Portal admin user ID in the cell

        4. After the task completes, stop the WebSphere_Portal server.

      4. From the WAS admin console, click System Administration > Node Agents.

      5. Check the box next to the required node agent and then click Restart.

      6. Stop and restart the dmgr.

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

      If Portal B is using a nondefault Portal server administrative ID, not wpsadmin, the server will not be functional until the cluster configuration is complete and the Portal administrative ID has been configured to match the Cells security settings.

    13. Choose one of the following options to define a cluster using Portal B as the basis:

      • To define a static cluster using Portal B as the basis:

        1. ./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password task.

        2. Configure the cluster to use an external web server to take advantage of features such as workload management. Choose one of the following options:

          Start with the step about launching the Plug-ins installation wizard.

        3. To access the WCM content through an external web server:

          1. Log on to the dmgr console.

          2. Select Environment > WebSphere Variables.

          3. From the Scope drop-down menu, select the option...

              Node=nodename, Server=servername

            ...where Node=nodename is the node containing the portal application server.

          4. Update the WCM_HOST variable with the fully qualified host name used to access the portal server through the web server or On Demand Router.

          5. Update the WCM_PORT variable with the port number used to access the portal server through the web server or On Demand Router.

        4. Save the changes and then restart the dmgr, the node agent(s), and the WebSphere_Portal servers.

      • To define a dynamic cluster using Portal B as the basis:

        1. Log on to the dmgr console.

        2. 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 the changes to the master configuration.

        3. To add members to the node group:

          1. Click System administration > Node groups.

          2. Click the name of the node group to add members to.

          3. Click Node group members under Additional Properties.

          4. Click Add.

          5. Select the primary node and then click Add.

          6. Click the Save link to save the changes to the master configuration.

        4. To create a dynamic cluster in the node group:

          1. Click Servers > Clusters > Dynamic clusters.

          2. Click New.

          3. Select WAS 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 wkplc.properties of the primary node.
          5. Remove all default membership policies and then click Subexpression builder.

          6. 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 created in the previous step in the Value text box.

            5. Click Generate subexpression.

            6. Click Append.

          7. Click Preview membership to verify that all nodes included in the nodegroup display and then click Next.

          8. Click the Create the cluster member using an existing server as a template radio button and then select the WebSphere_Portal server for the primary node from the pull-down menu.

          9. Click Next.

          10. Specify the required dynamic cluster properties for minimum and maximum number of server instances.

          11. Review the summary page to verify your actions and then click Finish.

        5. Set the following parameters in wkplc.properties:

          1. Verify that CellName is set to the dmgr cell.

          2. Verify that NodeName is set to the local node.

          3. Set ServerName to the server used for the dynamic cluster member on this node.

          4. Verify that PrimaryNode is set to true.

        6. Create the dynamic cluster...

            ./ConfigEngine.sh cluster-node-config-dynamic-cluster-setup -DWasPassword=dmgr_password

        7. To access the WCM content through an external web server:

          1. Log on to the dmgr console.

          2. Select Environment > WebSphere Variables.

          3. From the Scope drop-down menu, select the option...

              Node=nodename, Server=servername

            ...where Node=nodename is the node containing the portal application server.

          4. Update the WCM_HOST variable with the fully qualified host name used to access the portal server through the web server or On Demand Router.

          5. Update the WCM_PORT variable with the port number used to access the portal server through the web server or On Demand Router.

        8. Save the changes and then restart the dmgr, the node agent(s), and the WebSphere_Portal servers.

    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 Prepare additional nodes. We can add additional nodes to a static or dynamic cluster, and we can also add additional vertical cluster members to an existing node in a static or dynamic cluster to provide vertical scaling.

      Remember: If we are creating a multiple, dynamic cluster, remember to install WebSphere Virtual Enterprise on the additional node and augment the Portal profile with WebSphere Virtual Enterprise.

    15. Restart the WebSphere_Portal server.

      on Cluster A and Cluster B.

    16. After setting up the multiple clusters, there are additional tasks that we can complete to ensure a balanced workload and failover support.

      • 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.

      • Update the database configuration to share database domains between clusters. Refer to "Sharing database domains between clusters for information about redundancy and failover support.

    17. If you entered passwords in any of the properties files while creating the cluster, you should remove them for security purposes. See "Deleting passwords from properties files" under Related for information.

    Installation of Cluster B is complete. It is now an independent cluster from Cluster A, which means that Cluster B can have its own configuration, set of user portlets, and target community. Any applications that are common between Cluster A and Cluster B are most likely infrastructure or related to administration, and special care needs to be taken to preserve their commonality between clusters and correct maintenance levels.


    Route requests across clusters - multiple clusters

    The HTTP Server plug-is that comes with IBM WebSphere Application Server is typically used to balance requests for applications across members of the cluster. We can also use the ODR in dynamic, multicluster environments for routing. While an application can be mapped to more than one cluster, automatic plug-in generation does not provide routing or balancing traffic for the same application across multiple clusters. Multiple cluster environments with shared applications therefore cannot rely solely on WAS automatic plug-in generation to be able to route requests using a web server. One option in this scenario is developing a customized method for defining and maintaining the plug-in configuration file used by the web server to provide for the required routing of user requests.

    An important consideration in a multiple cluster environment is ensuring that all subsequent HTTP requests for a user are routed to the same cluster that processed the first HTTP request. The WebSphere Portal login processing depends upon preserving this cluster affinity during this initial time until the user has successfully logged in and session cookies maintain affinity. To guarantee that affinity is preserved during login, set the Navigator Service public.session parameter to a value of true; you should also set this parameter to true if we are using an ODR. Refer to "Portal Configuration Services" for information on how to configure this parameter.

    Review the following considerations before configuring the ODR to route traffic to Portal clusters:

    • Internal users can send requests directly to the ODR instead of through a front-end web server. When sending direct requests, configure the ODR to append a via header to the HTTP requests. Set the value of the ODR custom property http.compliance.via to true; see the "On demand router settings" link in the Related section for information.

      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.

    • The ODR can selectively route traffic to clusters based on the incoming URL. 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.

    • We can use the ODR to load balance traffic among identical portal clusters. Configure a Multicluster Routing Policy (MCRP) for the ODR to identify the destination clusters and the type of load balancing; see the "Configuring the on demand router for multi-cluster failover and load balancing routing" link in the Related section for information.

      If we 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.

    • We can also use the ODR to route traffic to remote portal clusters, both static and dynamic, by defining a generic server cluster for each target portal cluster; see the "Defining generic server clusters for remote ODR cells" link in the Related section for information.

      If we are routing to remote static clusterm that use vertical cluster members, perform the optional step at the end to define a server custom property for each port in the generic server cluster.


    Share database domains between clusters on AIX - multiple clusters

    To help provide redundancy and failover support in production environments composed of multiple clusters in a single cell and multiple clusters in different cells, we 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.

    JCR domains and release domains cannot be shared between different clusters or servers. Each distinct cluster or server in the environment must use a separate JCR domain and a separate release domain.

    For example:

    of separate JCR or Release domains between all clusters or servers
    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
    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 to share with any other clusters in the environment.

    3. Install the primary node of the next cluster (Cluster B), and complete the following steps to configure the node to use the shared database domains.

      1. Complete a partial database transfer of the database domains that we are not sharing.

        For example, if we are sharing only the Customization and Community domains, you would transfer the remaining domains to the database we are using for Cluster B.

      2. Re-configure the shared database domains on the node to connect to the shared database domains we 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 complete the following steps to configure the node to use the shared database domains.

      1. For those database domains that we are not sharing between clusters, re-configure the domains to connect to the database domains we are using for Cluster B.

        As in the example for the primary node, if we 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.

      2. Re-configure the shared database domains on the node to connect to the shared database domains we 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.

    6. Continue setting up the secondary node as described in the cluster instructions.


    Install Web Content Manager into an existing Server installation

    If you initially installed the IBM WebSphere Portal Server installation, we can purchase the Content license agreement and install the IBM Web Content Manager features into your existing installation.

    To install Web Content Manager into an existing Server installation:

    Cluster note: In a clustered environment, complete these steps on all the nodes.

    Response file note: We can record and run a response file to install Web Content Manager features on the existing Server installation. See Use response files to install for information.

    Use the following steps when recording the response file. Exit from the IBM Installation Manager program to complete the recording.

    1. Stop all the appservers.

    2. Open the IBM Installation Manager and complete the following steps to add the content repository:

      1. Go to File > Preferences > Repositories.

      2. Select Add Repositories.

      3. Select Browse and navigate to the WebSphere Portal content repository.

      4. Select the content repository file.

      5. Click OK.

      6. Ensure all required repositories are checked.

      7. Ensure that the content repository is after the Server repository in the list.

      8. Click Test Connections to ensure that the IBM Installation Manager can successfully access the directory where the repository is stored.

      9. Select Apply.

      10. Select OK.

    3. On the main IBM Installation Manager panel, select Install to begin the installation process.

    4. On the Install Package: Select packages to install panel, check the box for the additional package that you purchased. Then click Next.

    5. Accept the license agreement and then click Next.

    6. On the Location panel, select the Use the existing package group radio button. Select the IBM WebSphere Portal V8 package group name and then click Next.

    7. On the Features panel, check the box for the additional feature that you purchased. Then click Next.

    8. Verify the information on the Summary panel and then click Install.

    9. After the installation successfully completes, stop and restart the appropriate servers to propagate the changes. For specific instructions, see Start and stop servers, dmgrs, and node agents.

    10. Complete the following steps if created multiple profiles outside of the IBM Installation Manager:

    11. For each profile...

        cd WP_PROFILE/ConfigEngine
        ./ConfigEngine.sh enable-wcm -DWasPassword=foo

      Stop and restart the appropriate servers to propagate the changes.