Portal v7002 fixpack installation fails with "Target `check-portal-level-CF' does not exist in this project

When installing the Portal v7002 fixpack on a binary Portal installation after installing any cumulative fix, the 7002 fixpack installation may fail with "Target `check-portal-level-CF' does not exist in this
project"

Symptom

In the console output at the time of the failure, you see the following exception:
=============================
Result: StdErr: BUILD FAILED
Result: StdErr: Target `check-portal-level-CF' does not exist in this project. It is used from target `action-validate-portal-version-for-multProfile-CF'.
Result: StdErr:
Result: StdErr: Total time: 4 seconds
Log: ExecCmd::launch returns 1
Task 2 out of 630; End Uninstalling fix ' PM49013', component 'wp.ptf.config'.
Task 3 out of 630; Begin Completing fix ' PM49013' subTmpDir to be cleaned up: /tmp/ptfs
The directory does not exist, or is not a directory, continue to run: /tmp/ptfs
Fix pack installation has failed. Consult
/usr/WebSphere7/PortalServer/version/log/20120217_085936_PM49013_uninsta
ll.log for error details.
chmod -R 550 /usr/WebSphere7/PortalServer done!
UpdateInstaller.puiReturnCode is 9
End of [ ./updatePortal.sh ]
=============================

A similar error can be seen in the ConfigTrace.log as well.

Cause

This issue occurs when the user has done the following:

- Installed Portal as a binary installation

- Upgraded Portal to v7001 + any CF

- Created a profile (or migrated)

- Updated the wps.properties with the new profile information

- Attempted to upgrade to v7002

The first step for any fixpack installation is to remove all fixes and cumulative fixes. The CF uninstall fails in this case and that is why the fixpack fails.

The CF uninstall fails because of a defect in the Portal Update Installer that prevents any fix or CF from uninstalling cleanly when it was originally installed on a binary install. This will be fixed in a later version of the Portal Update Installer.

Resolving the problem

If you encounter this exception, you must take the following steps to resolve it:

1. Edit the PortalServer/wps.properties file
2. Remove the ProfileName and ProfilePath parameters from it.
3. Manually uninstall the cumulative fix(es) you have applied
4. If the following file still exists after the CF uninstall, manually remove it:

PortalServer/installer/wp.config/config/includes/preconfig_cumulative_fix.xml

5. Edit the PortalServer/wps.properties file again and add ProfileName and ProfilePath back to the file.
6. Reattempt the 7002 fixpack installation.

Source :  http://www-01.ibm.com/support/docview.wss?uid=swg21585265

Creating the WebSphere Portal 7 databases

Creating DB2 database

A remote database resides on a different system than Web Sphere Portal. When you use a remote server, you must manually create the databases that are required by Web Sphere Portal.

Before creating these databases, note the following information:

o If the DB2 JDBC type 4 driver is used, only the instructions on the remote server are required. You do not need to install the DB2 client software, and you do not need to complete the steps related to the DB2 client.

o The client software, DB2 Connect, must be correctly configured to connect to the remote DB2 server instance, for example, db2inst1.

These instructions assume that a remote DB2 server and DB2 Connect are already installed and running. For information on installing DB2 Connect, see the DB2 product documentation.
These instructions assume that you are using DB2 Connect to connect to a remote DB2 server, and that WebSphere Application Server, WebSphere Portal, and DB2 Connect are installed on the same system

1. Log in to the DB2 server system as a user with sufficient database privileges.

       $ db2inst1/password (A common user name is db2inst1)

2. Ensure that the user database has been created, granted appropriate privileges, and has a password assigned to it.

    If  the user has not been created, refer to the Creating users topic for information on how to create users.

3. Initialize a DB2 command environment by opening a command prompt and typing su - db2inst1

4. Run the following commands on the DB2 server system to configure the DB2 database instance:    

      DB2 Version 9

db2set DB2_RR_TO_RS=YES

db2set DB2_EVALUNCOMMITTED=YES                                                                                                                                                                                                                                                                                                                                                     

db2set DB2_INLIST_TO_NLJN=YES

db2 "UPDATE DBM CFG USING query_heap_sz 32768"

db2 "UPDATE DBM CFG USING maxagents 500"        

db2 "UPDATE DBM CFG USING sheapthres 50000"

5. Run the following commands on the DB2 server system to create the necessary databases:

 Notes:

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

            Remember: DB2 database names cannot exceed eight characters. Therefore, consider using these database names: release, commun, custom, jcrdb, fdbkdb, and lmdb.

               I.      create release db:

db2 "CREATE DB release using codeset UTF-8 territory us PAGESIZE 8192"

db2 "UPDATE DB CFG FOR release USING applheapsz 4096"

db2 "UPDATE DB CFG FOR release USING app_ctl_heap_sz 1024"

db2 "UPDATE DB CFG FOR release USING stmtheap 32768"

db2 "UPDATE DB CFG FOR release USING dbheap 2400"

db2 "UPDATE DB CFG FOR release USING locklist 1000"

db2 "UPDATE DB CFG FOR release USING logfilsiz 4000"

db2 "UPDATE DB CFG FOR release USING logprimary 12"

db2 "UPDATE DB CFG FOR release USING logsecond 20"

db2 "UPDATE DB CFG FOR release USING logbufsz 32"

db2 "UPDATE DB CFG FOR release USING avg_appls 5"

db2 "UPDATE DB CFG FOR release USING locktimeout 30"

db2 "UPDATE DB CFG FOR release using AUTO_MAINT off"

             II.      create community db

db2 "CREATE DB commun using codeset UTF-8 territory us PAGESIZE 8192"

db2 "UPDATE DB CFG FOR commun USING applheapsz 4096"

db2 "UPDATE DB CFG FOR commun USING app_ctl_heap_sz 1024"

db2 "UPDATE DB CFG FOR commun USING stmtheap 32768"

db2 "UPDATE DB CFG FOR commun USING dbheap 2400"

db2 "UPDATE DB CFG FOR commun USING locklist 1000"

db2 "UPDATE DB CFG FOR commun USING logfilsiz 4000"

db2 "UPDATE DB CFG FOR commun USING logprimary 12"

db2 "UPDATE DB CFG FOR commun USING logsecond 20"

db2 "UPDATE DB CFG FOR commun USING logbufsz 32"

db2 "UPDATE DB CFG FOR commun USING avg_appls 5"

db2 "UPDATE DB CFG FOR commun USING locktimeout 30"

db2 "UPDATE DB CFG FOR commun using AUTO_MAINT off"

           III.      creating customization db

db2 "CREATE DB custom using codeset UTF-8 territory us PAGESIZE 8192"

db2 "UPDATE DB CFG FOR custom USING applheapsz 4096"

db2 "UPDATE DB CFG FOR custom USING app_ctl_heap_sz 1024"

db2 "UPDATE DB CFG FOR custom USING stmtheap 32768"

db2 "UPDATE DB CFG FOR custom USING dbheap 2400"

db2 "UPDATE DB CFG FOR custom USING locklist 1000"

db2 "UPDATE DB CFG FOR custom USING logfilsiz 4000"

db2 "UPDATE DB CFG FOR custom USING logprimary 12"

db2 "UPDATE DB CFG FOR custom USING logsecond 20"

db2 "UPDATE DB CFG FOR custom USING logbufsz 32"

db2 "UPDATE DB CFG FOR custom USING avg_appls 5"

db2 "UPDATE DB CFG FOR custom USING locktimeout 30"

db2 "UPDATE DB CFG FOR custom using AUTO_MAINT off"

          IV.      creating jcrdb db

db2 "CREATE DB jcrdb using codeset UTF-8 territory us PAGESIZE 8192"

db2 "UPDATE DB CFG FOR jcrdb USING applheapsz 4096"

db2 "UPDATE DB CFG FOR jcrdb USING app_ctl_heap_sz 1024"

db2 "UPDATE DB CFG FOR jcrdb USING stmtheap 32768"

db2 "UPDATE DB CFG FOR jcrdb USING dbheap 2400"

db2 "UPDATE DB CFG FOR jcrdb USING locklist 1000"

db2 "UPDATE DB CFG FOR jcrdb USING logfilsiz 4000"

db2 "UPDATE DB CFG FOR jcrdb USING logprimary 12"

db2 "UPDATE DB CFG FOR jcrdb USING logsecond 20"

db2 "UPDATE DB CFG FOR jcrdb USING logbufsz 32"

db2 "UPDATE DB CFG FOR jcrdb USING avg_appls 5"

db2 "UPDATE DB CFG FOR jcrdb USING locktimeout 30"

 V.      creating fdbkdb db

                                                                                                     

db2 "UPDATE DB CFG FOR jcrdb using AUTO_MAINT off"

db2 "CREATE DB fdbkdb using codeset UTF-8 territory us PAGESIZE 8192"  

 db2 "UPDATE DB CFG FOR fdbkdb USING applheapsz 4096"

db2 "UPDATE DB CFG FOR fdbkdb USING app_ctl_heap_sz 1024"

db2 "UPDATE DB CFG FOR fdbkdb USING stmtheap 32768"

db2 "UPDATE DB CFG FOR fdbkdb USING dbheap 2400"

db2 "UPDATE DB CFG FOR fdbkdb USING locklist 1000"

db2 "UPDATE DB CFG FOR fdbkdb USING logfilsiz 4000"

db2 "UPDATE DB CFG FOR fdbkdb USING logprimary 12"

db2 "UPDATE DB CFG FOR fdbkdb USING logsecond 20"

db2 "UPDATE DB CFG FOR fdbkdb USING logbufsz 32"

db2 "UPDATE DB CFG FOR fdbkdb USING avg_appls 5"

db2 "UPDATE DB CFG FOR fdbkdb USING locktimeout 30"

db2 "UPDATE DB CFG FOR fdbkdb using AUTO_MAINT off"

          VI.      creating lmdb db

db2 "CREATE DB lmdb using codeset UTF-8 territory us PAGESIZE 8192"

db2 "UPDATE DB CFG FOR lmdb USING applheapsz 4096"

db2 "UPDATE DB CFG FOR lmdb USING app_ctl_heap_sz 1024"

db2 "UPDATE DB CFG FOR lmdb USING stmtheap 32768"

db2 "UPDATE DB CFG FOR lmdb USING dbheap 2400"

db2 "UPDATE DB CFG FOR lmdb USING locklist 1000"

db2 "UPDATE DB CFG FOR lmdb USING logfilsiz 4000"

db2 "UPDATE DB CFG FOR lmdb USING logprimary 12"

db2 "UPDATE DB CFG FOR lmdb USING logsecond 20"

db2 "UPDATE DB CFG FOR lmdb USING logbufsz 32"

db2 "UPDATE DB CFG FOR lmdb USING avg_appls 5"

db2 "UPDATE DB CFG FOR lmdb USING locktimeout 30"

db2 "UPDATE DB CFG FOR lmdb using AUTO_MAINT off"

6. Complete the following:

          On the DB2 server system, run the following commands. This step is only required for the IBM Java Content     

          Repository database (jcrdb).

                * jcrdb is the name of the database used to store user data and objects

                * jcr is the database user for jcrdb

                  Note: This value can be replaced with any ID that has administrative authority.

                * dbpassword is the password for jcrdb

db2 "CONNECT TO jcrdb USER db2inst1 USING password"

db2 "CREATE BUFFERPOOL ICMLSFREQBP4 SIZE 1000 PAGESIZE 4 K"

db2 "CREATE BUFFERPOOL ICMLSVOLATILEBP4 SIZE 8000 PAGESIZE 4 K"

db2 "CREATE BUFFERPOOL ICMLSMAINBP32 SIZE 8000 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 "DISCONNECT jcrdb"

db2 "TERMINATE"

7. On the DB2 server system, check the services file. If it does not specify DB2 connection and interrupt service ports,

     specify the ports for your operating system:

    Use a text editor to open the file vi /etc/services and add the following text (where db2inst1 is the name of the DB2    

     instance ID on the system):

    (Shift G -- end of line in vi editor)

db2c_db2inst1 50000/tcp # DB2 connection service port

db2i_db2inst1 50001/tcp # DB2 interrupt service port

8. On the DB2 server system, set DB2COMM to TCP/IP by using the db2set command:

     db2set DB2COMM=TCPIP

9. Set up the correct service name by entering the following command on the DB2 server system:

db2 "UPDATE DBM CFG USING svcename db2c_db2inst1"

where svce_name is the connection service port name that is specified above.

DB2 Migration

In addition, the database administrator user “db2inst1” will be used as the user ID for each database.

For Cluster :All of the steps in this section will be done from the primary Portal node.

                                                                             

1. Stop the WebSphere_Portal and server1 by executing the following commands from the command window in the   

    /bin directory:

         stopServer.bat WebSphere_Portal -user -password 

         stopServer.bat server1 -user -password   pwd>

2. Ensure the database Enterprise Edition is installed and configured on the node.

    Since we are using Type 4 Drivers for DB2, all that is needed is to copy the db2jcc.jar and db2jcc_license_cu.jar   

    files from the DB2 server (/opt/ibm/db2/V9.7/java)to some directory on the primary Portal server.

3. From the /ConfigEngine/properties directory, make a backup of the following files:

wkplc.properties

wkplc_dbtype.properties

wkplc_dbdomin.properties

4. Edit the wkplc_dbtype.properties file and make the following changes:

    copy jars from db2 server to portal and give the path here:

             db2.DbDriver=com.ibm.db2.jcc.DB2Driver

             db2.DbLibrary=C:/IBM/db2drivers/db2jcc.jar;C:/IBM/db2drivers/db2jcc_license_cu.jar

             db2.JdbcProviderName=wpdbJDBC_db2

NOTE: The entry for db2.DbLibrary is an example only. Please ensure this is a valid path on your system.For Windows the separator is ; and Unix its : (e.g /opt/db2jars/db2jcc4.jar:/opt/db2jars/db2jcc_license_cu.jar)

5. Edit the wkplc_comp.properties file and make the following changes: ( Use wkplc_dbdomain.properties in Portal 7.0    

    instead wkplc_comp)

feedback.DbType=db2

feedback.DbName=fdbkdb    

feedback.DbSchema=FEEDBACK

feedback.DataSourceName=wpdbDS_fdbk

feedback.DbUrl=jdbc:db2://mydbserver.ibm.com:50000/fdbkdb:returnAlias=0;

feedback.DbUser=db2inst1

feedback.DbPassword=password

feedback.DBA.DbUser=db2inst1

feedback.DBA.DbPassword=password

likeminds.DbType=db2

likeminds.DbName=lmdb

likeminds.DbSchema=likeminds

likeminds.DataSourceName=wpdbDS_lmdb

likeminds.DbUrl=jdbc:db2://mydbserver.ibm.com:50000/lmdb:returnAlias=0;   

likeminds.DbUser=db2inst1

likeminds.DbPassword=password

likeminds.DBA.DbUser=db2inst1

likeminds.DBA.DbPassword=password

release.DbType=db2

release.DbName= release

release.DbSchema=release

release.DataSourceName=wpdbDS_release

release.DbUrl=jdbc:db2://mydbserver.ibm.com:50000/release:returnAlias=0;

release.DbUser=db2inst1

release.DbPassword=password

release.DBA.DbUser=db2inst1

release.DBA.DbPassword=password

community.DbType=db2

community.DbName=commun

community.DbSchema=community

community.DataSourceName=wpdbDS_commun

community.DbUrl=jdbc:db2://mydbserver.ibm.com:50000/commun:returnAlias=0;

community.DbUser=db2inst1

community.DbPassword=password

community.DBA.DbUser=db2inst1

community.DBA.DbPassword=password

customization.DbType=db2

customization.DbName=custom

customization.DbSchema=customization

customization.DataSourceName=wpdbDS_custom

customization.DbUrl=jdbc:db2://mydbserver.ibm.com:50000/custom:returnAlias=0;

customization.DbUser=db2inst1

customization.DbPassword=password

customization.DBA.DbUser=db2inst1

customization.DBA.DbPassword=password

jcr.DbType=db2

jcr.DbName=jcrdb

jcr.DbSchema=jcr

jcr.DataSourceName=wpdbDS_jcrdb

jcr.DbUrl=jdbc:db2://mydbserver.ibm.com:50000/jcrdb:returnAlias=0;

jcr.DbUser=db2inst1

jcr.DbPassword=password

jcr.DBA.DbUser=db2inst1

jcr.DBA.DbPassword=password

Update the following property in the file wkplc.properties.

 For WasPassword, type the password for the WebSphere Application Server security authentication used in your  

 environment.

PortalAdminPwd=password

WasPassword=password

6. From a command window, change directories to /ConfigEngine

7. Execute the following ConfigEngine scripts to validate the database properties:

ConfigEngine.bat validate-database-driver

ConfigEngine.bat validate-database-connection

8. Execute the following ConfigEngine script to transfer the database from Derby to DB2:

ConfigEngine.bat database-transfer -DPortalAdminPwd= -DWasPassword=

9.Restart all servers and check the logs. (server1 and WebSphere_Portal)

source : http://www-10.lotus.com/ldd/portalwiki.nsf/dx/ConfigureWeb_Sphere_Portal_to_use_DB2

Caching Issue in WebSphere Portal version 6.1, 7.0 and 8.0

Currently Committed database setting - Applies to DB2 v9.7 or higher and WebSphere Portal version 6.1 and 7.0

 

DB2 V9.7 introduced a new default behaviour for isolation level cursor stability (CS) (see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.config.doc/doc/r0053556.html).
In WebSphere Portal this has implications for the cache invalidation strategy related to transactions. The new DB2 default behaviour for isolation level cursor stability (CS) is to NOT block code that wants to read data which is still being worked on in an uncommitted transaction in another thread (DB2 returns the result, as if the other transaction would not exist). But WebSphere Portal version 6.1 and 7.0 cache invalidation and refill strategies rely on the blocking at database level. With the new 'currently committed' default setting, stale data in Portal caches can occur.

Starting with Portal version 8.0 the setting of CUR_COMMIT to ENABLED is supported.

Besides the fact that CUR_COMMIT must be set to DISABLED for WebSphere Portal version 6.1 and 7.0, WebSphere Portal development does not expect a performance degradation when changing the value of CUR_COMMIT from ENABLED to DISABLED. For some scenarios with long database transactions, it could be that response times increase due to additional waits for updated data.

The setting of CUR_COMMIT is applied at database level. Therefore it is required to set CUR_COMMIT to DISABLED for the Portal database(s), containing the Portal database domains release, community, customization, jcr, feedback, and likeminds.

Disabling CUR_COMMIT in DB2 Version 9.7:

Ask your DB2 administrator to ensure that CUR_COMMIT is disabled by carrying out the following steps (for each of the Portal databases):

1. Connect to the runtime database:
   $ db2 connect to
   where represents the name of the database.
   
2. List the CUR_COMMIT parameter:
   $ db2 get db cfg show detail | grep CUR_COMMIT
   The output should look like this:
   Currently Committed (CUR_COMMIT) = DISABLED DISABLED
   
3. If the values are anything other than two times DISABLED (one for the current setting used, the other for the delayed setting specified in the configuration), change the value to DISABLED:
   $ db2 update db cfg using CUR_COMMIT DISABLED
   
4. Close the database connection:
   $ db2 connect reset
   
5. Check that no other application is connected to the database,to make the change effective (This e.g. requires to stop the Websphere Portal Server that uses the database). List the connected applications like this:
   $ db2 list applications for db
   where represents the name of the database.
   The output should look like this:
   SQL1611W No data was returned by Database System Monitor.
   
6. Ensure that the settings are correct by repeating the steps 1. and 2.

Full technote and source : http://www-01.ibm.com/support/docview.wss?uid=swg27037929&myns=swgws&mynp=OCSSHRKX&mync=E#!

Wpcollector tool, new in WebSphere Portal 7.0 and 8.0

Wpcollector is a new command line tool that automates the collection of portal logs and configuration files and optionally assists the customer with sending those files to IBM Support, saving valuable time. Using automated log collection early in the PMR life cycle can greatly reduce the number of doc requests that are made by Support. Wpcollector is an excellent tool for those customers that are not able to download and install ISA Lite in their portal environment.

Wpcollector is delivered with WebSphere Portal beginning with the 7.0 release. A significant difference between wpcollector and ISA Lite is that ISA Lite will automatically enable the correct traceString and collect the appropriate files based on the problem type selected in the ISA Lite GUI. Wpcollector, however, does not currently have a mechanism for the user to specify the problem type. Therefore, if tracing is required for the problem, the customer must manually enable traceStrings and recreate the problem PRIOR to running wpcollector. Similarly, because wpcollector consists of only 1 script, it collects all of the files for all of the various problem types each time the tool is run.

To run wpcollector, please follow the steps, below:

• If IBM Support has requested tracing, enable it as instructed by the L2 Support Engineer and then recreate the problem. If no tracing is requested, proceed to the step, below:

• If using Microsoft Windows, Unix/Linux, or IBM i, run the following script from the /PortalServer/bin/ directory to begin the collection:
  
  Windows: wpcollector.bat
  Unix/Linux: wpcollector.sh
  i: wpcollector.sh
  Tip: To specify the option for automatically sending the collection to IBM Support via FTP, use the "pmr" parameter. This will associate the collection with the PMR (Problem Management Record) specified. Be sure to format the number using either periods or commas. For example:
  wpcollector.bat -Dpmr=nnnnn.bbb.ccc (nnnnn=PMR number, bbb=branch, ccc=country code)
  Tip: To specify the option for collecting files for the Deployment Manager profile, use the "dmgr.root" parameter. For example:
  wpcollector.bat -Ddmgr.root=/opt/IBM/WebSphere/profiles/dmgr_profile
• If using IBM z/OS, proceed as follows:
  
  Start the WebSphere Portal Customization Dialog.
  In the Portal configuration panel, select Collect Diagnostics.
  Follow the Customization Dialog instructions for submitting the Collect Diagnostics job (EJPSLOGS).
  Tip: To specify the option for automatically sending the collection to IBM Support via FTP, respond to the "Transmit PMR Data" prompt with "Y" in the ISPF panel as follows:
  Transmit PMR data to IBM .................................: Y
  Tip: To collect data from the Deployment Manager, the only requirement is to submit the job from the system where the Deployment Manager is installed (i.e. so it can access the files). There is no prompt in the ISPF panel for this.
  
  
• If the automatic send/FTP option was not specified, a manual transfer of the collection to IBM will be necessary. Locate the wp.mustgather-.zip file or the -wp.mustgather-.zip file in the <wp_profile_root>/filesForAutoPD/ directory and follow the instructions in "Exchanging information with IBM Technical Support for problem determination" to manually FTP the collection to IBM. If using z/OS, there may be additional z/OS-specific files required, such as WebSphere Portal servant region or controller region joblogs. Wpcollector currently does not collect these files. Your L2 Support Engineer will inform you in the event these files are needed and provide instructions for collecting them. 

Do not underestimate this tool as when raising a PMR it is best to ensure that IBM support have all the information they need.

Happy Trails
Jerome Slinger

IBM WebSphere Portal ConfigEngine Tasks

action-deploy-portlets-prereq.pzn

If you install Portal or WCM using the administration option, or base install, the Personalization features, including the Personalization Navigator and Personalization Editor, are not installed. However, you can add these features manually after installation by deploying the Personalization portlets and adding the Personalization Navigator and Personalization Editor to a page. This task deploys the personalization portlets.
Examples:

UNIX:

./ConfigEngine.sh action-deploy-portlets-prereq.pzn -DPortalAdminPwd=password -DWasPassword=password

Windows:

ConfigEngine.bat action-deploy-portlets-prereq.pzn -DPortalAdminPwd=password -DWasPassword=password

i5/OS:

ConfigEngine.sh action-deploy-portlets-prereq.pzn -DPortalAdminPwd=password -DWasPassword=password

Note that if you want to follow a common structure that IBM uses when personalization is installed, you could use an XMLAccess export from the ContentRoot > Applications > Content > Personalization node taken from a portal instance that has those pages with the portlets deployed on them.

activate-portlets

Auto-synchronization of the Web modules to each node in the cluster might not happen immediately, or at all, depending on how the administrator has auto-synchronization configured in the deployment manager. For this reason, WebSphere Portal cannot guarantee that the portlet has been successfully synchronized to each node in the cluster and thus cannot automatically activate the portlet during deployment.
Perform the following steps to manage your portlets:
Deploy your portlets using either the WebSphere Portal Administration page or the XML configuration interface utility (xmlaccess command).

Run this task to activate the deployed portlets and to synchronize the changes across all cluster members.

Example:

ConfigEngine.bat activate-portlets -DWasPassword=password task from the wp_profile_rootConfigEngine directory

add-wcm-la-attributes

Adds the look-aside (property extension) database attributes necessary for WCM. You have to create the look-aside database first. See: http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Configuring_a_property_extension_database_on_Windows_wp7. Example command:

ConfigEngine.bat add-wcm-la-attributes -DWasPassword=password -DparentProperties=full path to wp_profile_root\\ConfigEngine\\config\\helpers\\wp_add_LA.properties

checkin-wp-proxy-config

This task activates changes made to the WebSphere Portal Ajax proxy configuration (wp.proxy.config.xml) file.

Example:

ConfigEngine.sh|bat checkin-wp-proxy-config -DProxyConfigFileName=dir_path/your_updated_proxy_file.name

cluster-node-config-cluster-setup

Example:

ConfigEngine.bat cluster-node-config-cluster-setup -DWasPassword=wpsadmin

create-jcr-jms-resources-post-dbxfer

The Java Content Repository (JCR) TextSearch functions are used for searching for content in the Lotus Web Content Management (WCM) Authoring user interface.As part of the install of IBM WebSphere Portal V7.0, all environments should be running the JMS task, "create-jcr-jms-resources-post-dbxfer," to move the JCR TextSearch resources from an Apache Derby Datasource/database configuration to the Datasouce/database that is used for the JCR repository. Failure to run this task can leave the datasource definitions pointing to Derby or cause the JCR TextSearch to not function properly.

Example:

create-jcr-jms-resources-post-dbxfer -DWasPassword=replaceWithWasPassword

configure-wcm-authoring

Installs the Web Content Management Authoring Portlet, Local Rendering Portlet and Web Content Manager Portal pages. This task can be run, for example, to install WCM atop a base portal install if the licensed edition allows for use of WCM.

Example:

ConfigEngine.bat configure-wcm-authoring -DPortalAdminPwd=xxx -DWasPassword=xxx

Lesson Learned: If the WCM Authoring portlet is invisible after running this task, try going into Portal Admin > Web Modules and make sure the modules for WCM are started (if they have the lightning bolt icon, you need to start them).

create-virtual-portal

Use this task to create a virtual portal. Additional parameters can be passed to the task, so please refer to the Virtual portals reference for details.

create-jcr-jmstopics

Recreates the bus and bus member used for JCR text search functionality.

database-transfer

Transfers the portal database from one to another depending on the settings in your configuration files (typically from the default Derby database to another such as DB2). You typically want to run the validate-database-driver and validate-database-connection tasks before this one.

delete-virtual-portal

Use this task to delete a virtual portal by using its object ID. To determine the correct object ID of the virtual portal, use the task list-all-virtual-portals.

deploy-full-profile-7002-theme

This config task applies the full profile to the WebSphere Portal7.0.0.2 theme.

deploy-lightweight-profile-7002-theme

This config task applies the lightweight profile to the WebSphere Portal7.0.0.2 theme

deploy-deferred-profile-7002-theme

This config task applies the deferred profile to the WebSphere Portal7.0.0.2 theme.

enable-identityprovider-tai

Enables a Trust Association Interceptor (TAI) for allowing OpenID authentication with an identity provider such as Google, Yahoo, or Facebook.

AIX:

./ConfigEngine.sh enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

IBM® i:

ConfigEngine.sh enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

Linux:

./ConfigEngine.sh enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

Solaris:

./ConfigEngine.sh enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

Windows:

ConfigEngine.bat enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

For the additional parameters that must be added to this command for proper function, please refer to the product documentation: Configuring OpenID authentication

enable-profiles

This command creates a configuration archive (CAR) file that is used to create additional WebSphere Portal profiles. The Portal.car file is saved to the PortalServer_root
profileTemplates
default.portal
configArchives directory. This is typically done as a step in the process of creating the WebSphere Portal profile template in a clustered environment.

enable-wcm

Installs Web Content Manager into an existing Server installation. In a clustered environment, this must be executed on each node.

See: Installing Web Content Manager into an existing Server installation on Windows

export-library-copy

Exports a copy of a web content library. See: Exporting and importing a web content library copy

export-wcm-data

Exports a web content library. Several things need to be in place for this task to be executed properly, so please refer to: Exporting and importing web content libraries

import-library-copy

Imports a copy of a web content library. See: Exporting and importing a web content library copy

import-wcm-data

Imports a web content library. Several things need to be in place for this task to be executed properly, so please refer to: Exporting and importing web content libraries

list-all-virtual-portals

This tasks lists all your virtual portals, together with the following information:

• The title of the virtual portal
• The description of the virtual portal
• The realm of the virtual portal
• The object ID of the virtual portal.

See: Virtual portals reference for details.

list-server-ports

Example:

ConfigEngine.bat list-server-ports -DWasPassword=password

list-server-ports-by-name

Examples:

ConfigEngine.bat list-server-ports-by-name -DServerName=server1 -DWasPassword=password

ConfigEngine.bat list-server-ports-by-name -DServerName=WebSphere_Portal -DWasPassword=password

modify-servlet-path

Changes the default portal Uniform Resource Identifier (URI) after installation.
Example:

./ConfigEngine.sh modify-servlet-path -DPortalAdminPwd=password -DWasPassword=password

Note that additional steps are typically required. See the topic, Changing the portal URI, in the appropriate product documentation for your software version.

modify-virtual-portal

Use this task to modify a virtual portal by using its object ID. To determine the correct object ID of the virtual portal, use the task list-all-virtual-portals .

package-profiles

Zips the profileTemplates directory and creates a profileTemplates.zip file in the PortalServer_root/profileTemplates directory. This is typically done after the enable-profiles task as a step in the process of creating the WebSphere Portal profile template in a clustered environment.

remove-wcm-authoring

Uninstalls the Web Content Management Authoring Portlet, Local Rendering Portlet and Web Content Manager Portal pages.

run-wcm-admin-task-member-fixer

Creates a report of users or groups referenced in Web Content Manager items that need fixing. See product documentation: Using the web content member fixer task

Example:

ConfigEngine.bat run-wcm-admin-task-member-fixer -DPortalAdminId=username -DPortalAdminPwd=password -DWasUserId=username -DWasPassword=password -Dlibrary="MyLibrary"

To actually run the module and make the fixes, add -Dfix=true as shown below:

ConfigEngine.bat run-wcm-admin-task-member-fixer -DPortalAdminId=username -DPortalAdminPwd=password -DWasUserId=username -DWasPassword=password -Dlibrary="MyLibrary" -Dfix=true

si-remove-setup

Removes the Solution Installer PAAs and their registrations as part of the uninstallation procedure for the IBM WebSphere Portal Solution Installer. For more information, refer to the official documentation for the Solution Installer, which is a PDF file contained within the application that can be obtained from the IBM Lotus and WebSphere Portal Business Solutions Catalog. See also: si-setup.

si-setup

This task is executed as a part of the installation procedure for the IBM WebSphere Portal Solution Installer. After the SolutionInstaller.zip has extracted on a node, and the install script has been run, this task is then executed to set up and register the PAA offering directory that the Solution Installer uses. For more information, refer to the official documentation for the Solution Installer, which is a PDF file contained within the application that can be obtained from the IBM Lotus and WebSphere Portal Business Solutions Catalog. See also: si-remove-setup.

start-portal-server

Starts the portal server. Note that the portal admin user id and password should be set in wkplc.properties before executing this task.
Example:

./ConfigEngine.sh start-portal-server

stop-portal-server

Stops the portal server. Note that the portal admin user id and password should be set in wkplc.properties before executing this task.
Example:

./ConfigEngine.sh stop-portal-server

validate-database-connection

Typically ran after the validate-database-driver task and before the database-transfer task to validate successful connection to database.
Example:

ConfigEngine.bat validate-database-connection -DTransferDomainList=release,customization,community,jcr,feedback,likeminds

validate-database-driver

Typically ran before the database-transfer task to validate your database driver configuration.
Example:

ConfigEngine.bat validate-database-driver -DTransferDomainList=release,customization,community, jcr,feedback,likeminds

validate-federated-ldapValidates your LDAP server settings. Typically run before the wp-create-ldap task.validate-standalone-ldapValidates configuration settings for stand-alone LDAP.
Example:

ConfigEngine.bat validate-standalone-ldap -DWasPassword=wpsadmin -DparentProperties=Z:\helpers\wp_security_ids.properties

webdav-deploy-zip-file

Use this configuration task to manage theme artifacts and to deploy iWidgets. This task uploads archive or compressed files to portal WebDAV folders.
This task has parameters; please see IBM documentation: Task webdav-deploy-zip-file

wp-node-prep-vmm-db-secured-environment

wp-prep-vmm-db-secured-environment

wp-query-attribute-config

Run the ConfigEngine.bat wp-query-attribute-config -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory, any time during the configuration process or at runtime to query an overview of the currently defined LDAP attributes. This task creates the availableAttributes.html report, located in the wp_profile_root/ConfigEngine/log directory. The report contains one table that lists the available attributes for Users (PersonAccount) and one table that lists the available attributes for Groups. For each configured repository there is a column that indicates if the attribute is flagged as unsupported or if the attribute is mapped to a different LDAP attribute.

wp-query-repository

Lists the names and types of configured user repositories.

wp-update-standalone-ldap-attribute-config

Applies the settings from wkplc.properties related to marking LDAP attributes as unsupported or mapping the portal attributes to attributes in your LDAP. For example, you might need to map the "ibm-primaryEmail" attribute that portal uses to the "mail" attribute in your own LDAP.
See: http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Mapping_attributes_on_Windows_in_a_clustered_environment_wp7. This task may do more, but at the time I wrote this, it was documented in this particular context.

wp-validate-federated-ldap-attribute-config

Validates that all defined attributes are available in the configured LDAP user registry.

Source : https://wiki.base22.com/

---