Siva R Vaka

IBM WebSphere Portal : Configure the Portal Cluster with Federated LDAP Repository (non-SSL)

Following article describes how to configure portal cluster with federated LDAP repository manually (using configengine tasks) , you can do the same from WAS Console also (Click here for how to configure from WAS Console)

Installed TDS succesfully and installed Softerra LDAP browser (or Admin) to browser LDAP users
Prior to configuring security, you should use the IBM WebSphere® Application Server backupConfig task to create and store a backup of the IBM WebSphere Portal configuration; see backupConfig command for information.

Backup Command

http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Frxml_backupconfig.html

Make sure to start DMGR, Node Agent and Portal servers.
From the primary node, Modify the following properties in wp_add_federated_ids.properties (in the <wp_profile>/ConfigEngine/config/helpers directory).

federated.ldap.id=PortalLdap

federated.ldap.host=sivapc.sivavaka.com

federated.ldap.port=389

federated.ldap.bindDN=cn=root

federated.ldap.bindPassword=Passw0rd

federated.ldap.ldapServerType=IDS

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

Execute the following ConfigEngine script to validate the properties:

./ConfigEngine.sh validate-federated-ldap -DparentProperties=<wp_profile>/ConfigEngine/config/helpers/wp_add_federated_ids.properties

-DsaveParentProperties=true -DWasPassword=wasadmin

NOTE: By using the -DparentProperties=<wp_profile>/ConfigEngine/config/helpers/wp_add_federated_ids.properties -DsaveParentProperties=true flags, ConfigEngine will automatically save the properties from the helper file into the wkplc.properties file

Execute the following ConfigEngine script to add the federated LDAP to the cluster securityconfiguration

./ConfigEngine.sh wp-create-ldap -DWasPassword=<current password>

C:\IBM\WP72\WebSphere\wp_profile\ConfigEngine>ConfigEngine.bat wp-create-ldap -DWasPassword=wasadmin

NOTE: This script does not remove or replace the out-of-the-box file user registry. Instead, it adds the ldap to the security configuration, so that both federated repository and the file based user registry are in use. Your Portal Administrator User ID, Portal Administrator Group ID and WAS User ID are still in the default out-of-the-box file user registry.

Restart the DMGR, the nodeagent on the primary node, and the WebSphere_Portal server on the primary node (Need stop in this order to populate the security information properly and start DMGR, nodeagent & websphere_portal).

IMPORTANT: If you happen to have a user in your ldap that shares the same shortname as your current Portal/WAS Administrator from the out-of-the-box-file registry, you will need to execute the following ConfigEngine script before proceding with the remaining steps:

./ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=<password>

Failure to run this script now can cause authentication problems for the remainder of these steps. Again this is only needed if you have duplicated shortname IDs. For example, your original ID is:

uid=wpadmin,o=defaultWIMFileBasedRealm

and if you have another 'wpadmin' ID in your LDAP:

uid=wpadmin,o=users,dc=mycompany,dc=com

If you try to login to Portal, you will be unable to login to Portal using the shortname. This will only be temporary and will be corrected at the end of these steps

Execute the following ConfigEngine script to verify that all defined attributes are available in your newly added ldap:

./ConfigEngine.sh wp-validate-federated-ldap-attribute-config -DWasPassword=<current password>

ConfigEngine.bat wp-validate-federated-ldap-attribute-config -DWasUserId=uid=wasadmin,o=defaultWIMFileBasedRealm -DWasPassword=wasadmin

Mapping Attributes

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

ConfigEngine.bat wp-query-attribute-config -DWasUserId=uid=wasadmin,o=defaultWIMFileBasedRealm -DWasPassword=wasadmin

Overview of the currently available attributes

Attributes for PersonAccount	PortalLdap	InternalFileRepository
businessAddress	not supported	✔
businessCategory	✔	✔
c	✔	✔
carLicense	✔	✔
certificate	✔	✔
changeType	✔	✔
children	✔	✔
cn	✔	✔
countryName	✔	✔
createTimestamp	✔	✔
departmentNumber	✔	✔
description	✔	✔
displayName	✔	✔
employeeNumber	✔	✔
entitlementInfo	✔	✔
facsimileTelephoneNumber	✔	✔
givenName	✔	✔
groups	✔	✔
homeAddress	not supported	✔
homePostalAddress	✔	✔
ibm-jobTitle	✔	✔
ibm-primaryEmail	✔	✔
identifier	✔	✔
initials	✔	✔
jpegPhoto	✔	✔
kerberosId	krbPrincipalName	✔
l	✔	✔
labeledURI	✔	✔
localityName	✔	✔
mail	✔	✔
manager	✔	✔
mobile	✔	✔
modifyTimestamp	✔	✔
pager	✔	✔
parent	✔	✔
partyRoles	✔	✔
password	userPassword	✔
postalAddress	✔	✔
postalCode	✔	✔
preferredLanguage	✔	✔
principalName	✔	✔
realm	✔	✔
roomNumber	✔	✔
secretary	✔	✔
seeAlso	✔	✔
sn	✔	✔
st	✔	✔
stateOrProvinceName	✔	✔
street	✔	✔
telephoneNumber	✔	✔
title	✔	✔
uid	✔	✔
viewIdentifiers	✔	✔

Attributes for Group	PortalLdap	InternalFileRepository
businessCategory	✔	✔
changeType	✔	✔
children	✔	✔
cn	✔	✔
createTimestamp	✔	✔
description	✔	✔
displayName	✔	✔
entitlementInfo	✔	✔
groups	✔	✔
identifier	✔	✔
members	✔	✔
modifyTimestamp	✔	✔
parent	✔	✔
partyRoles	✔	✔
seeAlso	✔	✔
viewIdentifiers	✔	✔

Optionally you can map the LDAP attributes to portal attributes like below , I just ignored this mapping for now.

federated.ldap.attributes.mapping.ldapName=mail, title

federated.ldap.attributes.mapping.portalName=ibm-primaryEmail, ibm-jobTitle

NOTE: For creating the portal admin users in the LDAP better import the portaluser.ldif (Click here for ldap configuration) or make sure you are using right objectClasses, objectClass for the person account should be "Internet Organization Person " this will make sure RDN for the person account will be "uid" instead of "cn".

At this stage, your WebSphere Portal environment is using two user repositories: the out-ofthe-box file registry, and the newly configured LDAP user registry. The WebSphere Application Server Administartor ID, the Portal Administrator User ID, and the Portal Administrator Group ID, are all configured for the file registry.

Execute the following ConfigEngine script to reassign the WebSphere Application Server ID as a user within your LDAP:

./ConfigEngine.sh wp-change-was-admin-user -DWasPassword=<current password> -DnewAdminId=<full distinguished name from ldap> -DnewAdminPw=<ldap ID password>

For example, this is the exact command I executed:

ConfigEngine.bat wp-change-was-admin-user -DWasPassword=wasadmin -DnewAdminId=uid=wasadmin,cn=users,dc=sivavaka,dc=com -DnewAdminPw=wasadmin

NOTE:

Make sure you have portal admin user id is LDAP repository (import the portalusers.ldif file)
If the full distinguished name of your user has a space in it, then add the 'newAdminId' and 'newAdminPw' values to your wkplc.properties file instead of passing them through the command line.
After running this script, the WasUserid value in wkplc.properties will be updated to reflect the new Was User ID you specified for “newAdminId”.

Restart the DMGR, NodeAgent and WebSphere_Portal server for the change to take effect.

NOTE:

When you stop these servers, you will need to pass in the user ID/pwd of the original WAS admin user. The new user will not take effect until the servers have been restarted.
If you ran the 'wp-modify-realm-enable-dn-login' script, then you will be required to pass in the full distinguished name of the WAS admin user (since the servers are now using it) in order for authentication to succeed. For example:

./stopManager.sh -user uid=wpadmin,o=defaultWIMFileBasedRealm -password <password>

After the servers are restarted, the WasUserId and WasPassword will be the ldap user.

NOTE

a . For me I have to execute the following to stop the DMGR even though I didn't run the "wp-modify-realm-enable-dn-login" as described above

stopManager.bat -user uid=wasadmin,o=defaultWIMFileBasedRealm -password wasadmin

stopNode.bat -user uid=wasadmin,o=defaultWIMFileBasedRealm -password wasadmin

stopServer.bat WebSphere_Portal -user uid=wasadmin,o=defaultWIMFileBasedRealm -password wasadmin

Execute the following ConfigEngine script to reassign the WebSphere Portal Administrator ID and Group ID to a user and group within your LDAP:

./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=<password> -DnewAdminId=<full distinguished name from ldap> -DnewAdminPw=<ldap ID

password> -DnewAdminGroupId=<full distinguished name from ldap>

For example, this is the exact command I executed:

ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=wasadmin -DnewAdminId=uid=wasadmin,cn=users,dc=sivavaka,dc=com -DnewAdminPw=wasadmin -DnewAdminGroupId=cn=wpadmins,cn=groups,dc=sivavaka,dc=com

NOTE:

If the full distinguished name of your user has a space in it, then add the 'newAdminId', 'newAdminPw', and 'newAdminGroupId' values to your wkplc.properties file instead of passing them through the command line.

After running this script, the PortalAdminId value in wkplc.properties will be automatically updated to reflect the ID value specified for 'newAdminId' and the PortalAdminGroupId value will be automatically updated to reflect the 'newAdminGroupId'.

In the current state, it is not possible to stop the servers cleanly via the command line. You must kill the Java processes for the respective servers via your operating system administrative utilities (in a standalone environment: WebSphere_Portal and server1; in a clustered environment: Deployment Manager, node agent, and cluster members such as WebSphere_Portal.)

Start the servers. In a clustered environment, restart the Deployment Manager, the node agent, and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers. Confirm you can now log into the ISC by using the full DN for your administrative user.

Remove the file registry from the federated repository by doing the following:

-- Ensure the following properties are specified in wkplc.properties:

federated.delete.baseentry=o=defaultWIMFileBasedRealm

federated.delete.id=InternalFileRepository

-- Run the following ConfigEngine task:

ConfigEngine.sh wp-delete-repository

Restart the servers. In a clustered environment, restart the Deployment Manager, the node agent, and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers. Confirm that login with the login attribute succeeds to the ISC.

Referernces

http://publib.boulder.ibm.com/infocenter/wcmdoc/v6r0/index.jsp?topic=/com.ibm.lotus.wcm.doc/install/standalone_cfg_wp_ureg.html

http://infolib.lotus.com/resources/portal/8.0.0/doc/nl_NL/PT800ACD001/install/linux_ureg_model_clus.html

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/configuring-a-federated-custom-user-registry

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

IBM WebSphere Portal 7 Clustering : Create DMGR Profile and Agument

Backup and enable portal profile (wp_profile)

1. Following ConfigEngine task will create the backup of the the primary node i.e. wp_profile and also enables the portal profile templates within the WAS profile Management tool. This will let you create the new portal profile in the future.

./ConfigEngine.sh enable-profiles -DWasPassword=wasadmin

this will create the PofileTemplates directory under the <PortalServer root> and wp_profile backup will be created (portal.car) and saved under <PortalServer_root>/ProfileTemplates/default.portal/configarchives

2. Execute the following ConfigEngine to package all profile templates into single

./ConfigEngine.sh package-profiles -DWasPassword=wasadmin

Creates <PortalServer_root>/profileTemplates/profileTemplates.zip

Creating DMGR and Augmenting the profile

DMGR profile can be create in two ways

a). Install the DMGR on separate server (for this you need install the WAS ND ).
b). Create DMGR profile on existing WAS server installation (Where portal server installed, I have used this approach , Clustering guide explains to install the ND fresh )

Create DMGR profile

WebSphere 64-bit is not compatible with the Profile Management Tool. (The Profile Management Tool is not available on Linux PPC 64-bit, Linux AMD 64-bit, and Windows AMD 64-bit systems.) , So had to create the DMGR node manually using the profile management tool (manageprofiles) from command prompt

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

Following will give all available optiones (required /optional ..etc).

manageprofiles.bat -create -templatePath C:\IBM\WebSphere\AppServer\profileTemplates\management -help

Execute the following

manageprofiles.bat -create

-templatePath C:\IBM\WebSphere\AppServer\profileTemplates\management

-profilePath C:\IBM\WebSphere\AppServer\profiles\Dmgr01

-hostName sivapc.sivavaka.com

-profileName Dmgr01

-cellName SivaPCCell01

-nodeName SivaPCNode01

-enableAdminSecurity true

-adminUserName wasadmin

-adminPassword wasadmin

C:\IBM\WebSphere\AppServer\bin>manageprofiles.bat -create -templatePath C:\IBM\WebSphere\AppServer\profileTemplates\management -profilePath C:\IBM\WebSphere\AppServer\profiles\Dmgr01 -hostName sivapc.sivavaka.com -profileName Dmgr01 -cellName SivaPCCell01 -nodeName SivaPCNode01 -enableAdminSecurity true -adminUserName wasadmin -adminPassword wasadmin

INSTCONFSUCCESS: Success: Profile Dmgr01 now exists. Please consult C:\IBM\WebSphere\AppServer\profiles\Dmgr01\logs\AboutThisProfile.txt for more information about this profile.

Found the port details in above log file (you need SOAP port details while federating node)

Application server environment to create: Management

Location: C:\IBM\WebSphere\AppServer\profiles\Dmgr01

Disk space required: 30 MB

Profile name: Dmgr01

Make this profile the default: False

Node name: SivaPCNode01

Cell name: SivaPCCell01

Host name: sivapc.sivavaka.com

Enable administrative security (recommended): True

Administrative console port: 9060

Administrative console secure port: 9043

Management bootstrap port: 9809

Management SOAP connector port: 8879

Run Management as a service: False

Augmenting profile (or Configuring DMGR profile to manage portal nodes)

Extract the files from "fileForDmgr.zip" file (located under C:\IBM\WebSphere\PortalServer\filesForDmgr) to "C:\IBM\WebSphere\AppServer" assuming that your DMGR profile is created under the "C:\IBM\WebSphere\AppServer\profiles\Dmgr01" .

NOTE:

I had to replace some of the existing files while copying to appserver directory.
If the Deployment Manager profile was not created in the default AppServer/profiles/Dmgr01 directory, then the metadata_wkplc.xml file, located in the AppServer\profiles\Dmgr01\config\.repository\metadata_wkplc.xml directory in the zip file, must be copied into the config\.repository subdirectory under the Deployment Manager profile directory.
Just make sure DMGR is stopped at this point(execute the stopManager.bat from /profiles/Dmgr01/bin)

Execute the following to augment the DMGR profile

manageprofiles.bat -augment -templatePath C:\IBM\WebSphere\AppServer\profileTemplates\management.portal.augment -profileName Dmgr01

C:\IBM\WebSphere\AppServer\bin>manageprofiles.bat -augment -templatePath C:\IBM\WebSphere\AppServer\profileTemplates\management.portal.augment -profileName Dmgr01

INSTCONFSUCCESS: Profile augmentation succeeded.

Start the Deployment Manager

C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin>startManager.bat

Verify that the WebSphere Portal administrative users and administrative group exist in the Deployment Manager cell's user registry

Add the full user DN in the "Primary administrative user name" filed to avoid the userid conflicts when configured with federated LDAP.

Save and restart the deployment manager.

References

1. To create and augment the profile manually.

http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=IBM+WebSphere+Portal+7+Product+Documentation#action=openDocument&res_title=Preparing_the_WebSphere_Application_Server_Deployment_Manager_on_Windows_wp7&content=pdcontent

2. http://www-01.ibm.com/support/docview.wss?uid=swg21408010
3. www-10.lotus.com/ldd/portalwiki.nsf/xsp/.ibmmodres/domino/openattachment/ldd/portalwiki.nsf/1ce09486e05fc916852577a70072d757/attach/wpv7_clusterguide.pdf

Update

Recently (Mid July 2013) IBM has posted "Manage Profiles Interactive" tool to create new profiles in WebSphere Application Server (this is useful to create the profile in 64-bit environments)

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

IBM HTTP Server (IHS) v7 Plugin generation for the WebSphere Portal

Copy the configurewebserver1.sh script from the <plugin root>/bin (C:\IBM\HTTPServer\Plugins\bin) directory to the <dmgr_profile>/bin directory on your Deployment Manager server. (webserver1 is name of webserver definition)

Run the following script(While DMGR is running) to create the web server definition in the DMGR configuration and map all of the installed applications to the web server.

./configurewebserver1.sh -user <was_admin_user> -password password

C:\IBM\WP72\WebSphere\AppServer\profiles\Dmgr01\bin>configurewebserver1.bat -user wpsadmin -password wpsadmin

Using WebSphere admin userID wpsadmin

Above command execute the following tasks

Creates the web server definition for webserver1
Compute and generate plugin properties ID.
Gets the list all installed apps and updates the target mapping (includes webserver1 in target mappings)

From DMGR console -->Servers → Server Types → Web Servers , Select the Checkbox for the new web server definition, Click the “Generate Plug-in” button

This will generate <dmgr_profile>/config/cells/<cellname>/nodes/<nodename>/servers/webserver1/plugincfg.xml (C:\IBM\WebSphere\wp_profile\config\cells\SivaPCCell01\nodes\SivaPC\servers\webserver1\plugincfg.xml) file and also generated a file under C:\IBM\HTTPServer\Plugins\config\webserver1\plugincfg.xml

NOTE :

While generating plugin I have webserver stopped (you don't need to have webserver started while generating plugin).
As I have HTTP server locally its updated the plugincfg.xml file under the webserver, but if HTTP server on the remote server then need to copy the plugin-cfg.xml file to the remote web server at the following directory, overwriting the existing one: <plugin_root>/config/webserver1

Restart the DMGR, web server, and nodeagents, and WebSphere_Portal.

IBM Tivoli Directory Server (TDS) v6.2 : Configuring instance for the WebSphere Portal

Add the suffix (dc=sivavaka, dc=com)

Open the "Instance Administration Tool" (run as administrator if you are using the windows) and suffix.

Importing following ldif file with portal admin id and group (optionally ldap bind id) or creating them manually using some LDAP admin tool.

NOTE: portalusers.ldif file import may fail if you are running DB2 v9.7 with fix pack 1 , you need to upgrade that to fix pack level 2 (Check appendix for more details)

Pasting contents of portalusers.ldif file below (didn't include wpsbind user as I have used root user "cn=root" for the ldap binding).

version: 1

dn: dc=sivavaka,dc=com

objectclass: domain

objectclass: top

dc: sivavaka

dn: cn=users,dc=sivavaka,dc=com

cn: users

objectclass: container

objectclass: top

dn: cn=groups,dc=sivavaka,dc=com

objectclass: container

objectclass: top

cn: groups

dn: cn=wpsadmins,cn=groups,dc=sivavaka,dc=com

objectClass: top

objectClass: groupOfUniqueNames

cn: wpsadmins

uniquemember: uid=wpsadmin,cn=users,dc=sivavaka,dc=com

dn: uid=wpsadmin,cn=users,dc=sivavaka,dc=com

cn:: wpsadmin

sn: wpsadmin

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

uid: wpsadmin

mail: wpsadmin@sivavaka.com

userPassword: wpsadmin

displayName:: wpsadmin

If you use the LDAP bind id that is different from LDAP admin id , then make sure assign the ACL's properly to provide the read and write access to branch. (Generally if you do this you might error while adding groups or users from the portal admin console).

After installation of the Tivoli directory server web administration tool (IDSWebApp) successfully , login with TDS admin user and password

https://sivapc.sivavaka.com:10002/IDSWebApp/

Edit ACL for the suffix that we have added initially

On the left hand side, click on the Non-filtered ACLs. Select the Propagate ACLs check box to allow descendants without an explicitly defined ACL to inherit from this entry. Enter the distinguished name of the wpsbind user like uid=wpsbind, cn=users, dc=sivavaka, dc=com

Appendix

Problem Importing LDIF file, Even after successful installation of TDS and directory server instance creation, I am not able to import the sample portalusers.ldif , upon quick research came to know that it is known problem with running with DB2 v9.7 at fix pack level 1.

GLPSRV200I Initializing primary database and its connections.

GLPRDB001E Error code -1 from function:"SQLConnect " dsrdbm01 .

GLPRDB004E The directory server is unable to connect to the database.

Solution:

Found that this is issue with DB2 Fixpack 1 and need to upgrade to fixpack 2 (Check DB2 Upgrdate instructions to Install DB2 fix pack 2)

After installing the fixpack 2 (DB2 9.7), Now I am don't see "unable to connect to database error" anymore and I am able to import the sample portalusers.ldif successfully

References:

Issues with fixpack 1 http://www-01.ibm.com/support/docview.wss?uid=swg1IC66807
Fixes location : http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg27007053
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/cfg_ids.html

DB2 v9.7 Issues faced and while doing Websphere Portal DB Transfer

Got the following errors while doing the DB transfer

Failed with following error .

Error Details

2012-03-13 05:22:59 cmcfgls: TRACE -> source --> C:/IBM/WP72/WebSphere/wp_profile/PortalServer/jcr\config\icmplsct.ddl

2012-03-13 05:22:59 cmcfgls: DEBUG -> Executing:

CREATE TABLE jcr.ICMSTADMINDOMAINS ( DOMAINID INTEGER NOT NULL, PRIMARY KEY (DOMAINID) ) IN ICMSFQ04

2012-03-13 05:22:59 cmcfgls: ERROR ->Fail to execute:

CREATE TABLE jcr.ICMSTADMINDOMAINS ( DOMAINID INTEGER NOT NULL, PRIMARY KEY (DOMAINID) ) IN ICMSFQ04

com.ibm.cm.dbutil.ICMDBUtilsException: DB2 SQL Error: SQLCODE=-204, SQLSTATE=42704, SQLERRMC=ICMSFQ04, DRIVER=4.8.87

at com.ibm.cm.dbutil.ICMDBUtilsCommon.executeSQL(ICMDBUtilsCommon.java:1110)

at com.ibm.cm.dbutil.ICMDBUtilsCommon.executeSQL(ICMDBUtilsCommon.java:999)

at com.ibm.cm.dbutil.ICMConfigureLSDB.createDB(ICMConfigureLSDB.java:306)

at com.ibm.cm.dbutil.ICMConfigureLSDB.configureLSDB(ICMConfigureLSDB.java:1160)

at com.ibm.cm.dbutil.ICMConfigureLSDB.start(ICMConfigureLSDB.java:2119)

at com.ibm.cm.dbutil.cmcfgdbu.startSilentMode(cmcfgdbu.java:154)

at com.ibm.cm.dbutil.cmcfgdbu.startConfig(cmcfgdbu.java:278)

at com.ibm.cm.dbutil.cmcfgdbu.main(cmcfgdbu.java:295)

com.ibm.cm.dbutil.ICMDBUtilsException: DB2 SQL Error: SQLCODE=-204, SQLSTATE=42704, SQLERRMC=ICMSFQ04, DRIVER=4.8.87

at com.ibm.cm.dbutil.ICMDBUtilsCommon.executeSQL(ICMDBUtilsCommon.java:1135)

at com.ibm.cm.dbutil.ICMDBUtilsCommon.executeSQL(ICMDBUtilsCommon.java:999)

at com.ibm.cm.dbutil.ICMConfigureLSDB.createDB(ICMConfigureLSDB.java:306)

at com.ibm.cm.dbutil.ICMConfigureLSDB.configureLSDB(ICMConfigureLSDB.java:1160)

at com.ibm.cm.dbutil.ICMConfigureLSDB.start(ICMConfigureLSDB.java:2119)

at com.ibm.cm.dbutil.cmcfgdbu.startSilentMode(cmcfgdbu.java:154)

at com.ibm.cm.dbutil.cmcfgdbu.startConfig(cmcfgdbu.java:278)

at com.ibm.cm.dbutil.cmcfgdbu.main(cmcfgdbu.java:295)

com.ibm.cm.dbutil.ICMDBUtilsException: Fail to create database

at com.ibm.cm.dbutil.ICMConfigureLSDB.createDB(ICMConfigureLSDB.java:326)

at com.ibm.cm.dbutil.ICMConfigureLSDB.configureLSDB(ICMConfigureLSDB.java:1160)

at com.ibm.cm.dbutil.ICMConfigureLSDB.start(ICMConfigureLSDB.java:2119)

at com.ibm.cm.dbutil.cmcfgdbu.startSilentMode(cmcfgdbu.java:154)

at com.ibm.cm.dbutil.cmcfgdbu.startConfig(cmcfgdbu.java:278)

at com.ibm.cm.dbutil.cmcfgdbu.main(cmcfgdbu.java:295)

Reason/Solution:

This is caused when I didn't executed/created the tablespaces for the JCR .

Failed with following error

Error Details
C:\IBM\WebSphere\wp_profile\ConfigEngine\log\portal-database-transfer.log

[sqlproc] Error during statement execution!

[sqlproc] com.ibm.db2.jcc.am.vo: DB2 SQL Error: SQLCODE=-286, SQLSTATE=42727, SQLERRMC=8192;DB2ADMIN, DRIVER=4.8.87

[sqlproc] at com.ibm.db2.jcc.am.gd.a(gd.java:676)

…….

[sqlproc] at com.ibm.wps.config.launch.ConfigEngineLauncher.main(ConfigEngineLauncher.java:311)

[sqlproc] (ErrCode=-286, SqlState=42727)

Reason/Solution

This error occurred before I use proper SQL's to create the database instance .

Problem is with page size on database , need to set the higher pagesize and SQLERRMC generally gives what need to be the actual page size (Pagesize is SQLERRMC i.e. 8192).

To solve this , delete the database that is already created and recreate with larger page size. For example, enter the command CREATE DB database_name PAGESIZE size

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

DB2 v9.7 Augmenting/Configuring database instance specific to the WebSphere Portal

Following two ways to create the database instance specific to WebSphere Portal

You can create the database instance for websphere portal in following ways

By executing the IBM provided DB2 commands directly
Using "ConfigEngine" task

Using the DB2 Commands

NOTE: Cluster Guide explains how to create the separate DB instance for the each schema (Release, jcr, feedback, customization, likeminds and community) but as I'm not using it for heavy use I have created all schemas in single database instance (WP7DB)

Required commands are specified in the Appendix section of the Cluster Guide page@64, included same here for convenience.

From the command prompt

Type "db2cmd" brings up the DB2 command line processing (DB2CLP) and then type db2

db2 "CREATE DATABASE WPS7DB AUTOMATIC STORAGE YES ON 'C:\' using codeset UTF-8 territory us PAGESIZE 8192"

db2 "UPDATE DB CFG FOR WPS7DB USING AUTO_MAINT OFF"

db2 "UPDATE DB CFG FOR WPS7DB USING applheapsz 4096"

db2 "UPDATE DB CFG FOR WPS7DB USING app_ctl_heap_sz 1024"

db2 "UPDATE DB CFG FOR WPS7DB USING stmtheap 32768"

db2 "UPDATE DB CFG FOR WPS7DB USING dbheap 2400"

db2 "UPDATE DB CFG FOR WPS7DB USING locklist 1000"

db2 "UPDATE DB CFG FOR WPS7DB USING logfilsiz 4000"

db2 "UPDATE DB CFG FOR WPS7DB USING logprimary 12"

db2 "UPDATE DB CFG FOR WPS7DB USING logsecond 20"

db2 "UPDATE DB CFG FOR WPS7DB USING logbufsz 32"

db2 "UPDATE DB CFG FOR WPS7DB USING avg_appls 5"

db2 "UPDATE DB CFG FOR WPS7DB USING locktimeout 30"

db2 "UPDATE DB CFG FOR WPS7DB using AUTO_MAINT off"

IMPORTANT:

Create the following tablespaces in your JCR database. If you are using one database for all domains, then create these tablespaces in that database
Failure to create these tablespaces will cause the database-transfer to fail
These tablespace names cannot be altered. You must use the names listed below.

db2 "CONNECT TO WPS7DB USER db2admin USING db2admin"

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 WPS7DB USING DFT_QUERYOPT 2"

db2 "UPDATE DB CFG FOR WPS7DB USING PCKCACHESZ 16384"

db2 "DISCONNECT WPS7DB "

db2 "TERMINATE"

Executed all above

db2 => CREATE DATABASE WPS7DB AUTOMATIC STORAGE YES ON 'C:\' using codeset UTF-8 territory us PAGESIZE 8192

DB20000I The CREATE DATABASE command completed successfully.

db2 => UPDATE DB CFG FOR WPS7DB USING AUTO_MAINT OFF