WebSphere Portal v6.0.1.1 to v6.1 Migration Notes

I’ve been running into several issues lately doing a WebSphere Portal v6.0.1.1 migration to WebSphere Portal v6.1 on the same server.  This should be a relatively straightforward process as far as WebSphere Portal migrations go, but we’ve run into several issues that I wasn’t able to find much or any info about.  Here are a few of the things I found while running the portal-post-upgrade task.

Use a Standalone User Repository

We started off using a Standalone User Repository in this migration. Some errors occurred early on and we switched the repository to a federated user repository configuration. This got us through the issues we were encountering. When we got to the portal-post-upgrade task, we got an exception and BUILD FAILED message. At this point, we were not able to shutdown WebSphere_Portal or server1, nor could we access the WAS Admin Console. The abbreviated exception we were facing looked something like this:

[exec] Caused by: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials

This took some tracking down. Here is how I got to the success path for resolving the issue:

1. edit the security.xml to disable security
2. kill the server1 process since ./stopServer.sh server1 throws the exception above
3. start server1
4. go into the WAS Admin Console and take a look at the security configuration for the repository (federated in our case)

I noticed that the required field Realm Name was blank and it certainly should have been filled in. The configuration also did not have our user repository associated with it.

In order to fix the issue, I reconfigured security to use a standalone repository and restarted WebSphere_Portal and server1. After I validated the login, I kicked off the portal-post-upgrade task again.

Import the source server SSL Certificate

The next run of the portal-post-upgrade task failed with some errors that looked like this:

[exec] [wplc-add-property] Add signer to the trust store now? (y/n)[exec] [wplc-add-property] [04/27/11 16:30:28.490 MDT] jndiUnavailCommErr
[exec] [wplc-add-property] [04/27/11 16:30:28.496 MDT] Can not find EJB: ejb/com/ibm/websphere/wim/ejb/WIMServiceHome
[exec] [wplc-add-property] javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context with the provider URL: "corbaloc:iiop:localhost:10031". Make sure that any bootstrap address information in the URL is correct and that the target name server is running. A bootstrap address with no port specification defaults to port 2809. Possible causes other than an incorrect bootstrap address or unavailable name server include the network environment and workstation network configuration. [Root exception is org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible:
[exec] [wplc-add-property] Forwarded IOR failed with: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET: JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: com.ibm.jsse2.util.h: No trusted certificate found
[exec] [wplc-add-property] Initial IOR failed with: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET: JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. Reason: com.ibm.jsse2.util.h: No trusted certificate found vmcid: IBM minor code: E07 completed: No]

It is fairly obvious that the v6.1 server cannot communicate with the v6.0 server because of a certificate issue. If you go through the infocenter, it looks like a real pain to get a certificate imported. You can probably do this with the “Easy Button” approach using wsadmin.sh. Just issue a command like this:

./wsadmin.sh -host <ReplaceWithYourHostName> -port <SOAP_CLIENT_ADDRESS_PORT>

When prompted to accept the certificate, enter y. This task will fail because the WAS versions are different between the target and source environments. When you are left at the wsadmin> prompt, just type exit and hit return.

Invalid Authentication Information

After another hour and a half, the portal-post-upgrade task failed again. At least this exception was something I could find with a minimum amount of Google intervention. The exception had this as the root cause:

[exec] [wplc-add-property] Caused by: org.omg.CORBA.NO_PERMISSION: JSAS0455A: Unable to login principal, invalid authentication information. vmcid: 0x49424000 minor code: 300 completed: No

The fix is to modify the sas.client.props file on the v6.1 instance under <wp_profile_root>/properties. Change these properties:

• com.ibm.CORBA.loginSource=properties (was originally set to prompt)
• com.ibm.CORBA.loginUserid=ReplaceWithFullDNToUser
• com.ibm.CORBA.loginPassword=ReplaceWithYourPassword

Rerun the portal-post-upgrade task.

WIMServiceHome Not Found

All the Googling seems to indicate there is a problem with the lookaside configuration in a clustered environment which is not my scenario. That information did not seem very useful. All it was having you do is run the Lookaside install task

./ConfigEngine.sh wp-la-install-ear -WasPassword=ReplaceWithYourPassword

which I had already done and restarted the server. I came across an IBM article that indicates after installing the Lookaside ear, you should run another task to complete the installation. That failed for me. Here is the exception that came up in the MigrationTrace.log

[exec] [wplc-add-property] javax.naming.NameNotFoundException: Context: <cell>/nodes/<nodename>/servers/WebSphere_Portal, name: ejb/com/ibm/websphere/wim/ejb/WIMServiceHome: First component in name websphere/wim/ejb/WIMServiceHome not found. [Root exception is rg.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]

Then I came across an IBM article about the wp-add-property task failing with the same error that I was getting. Their solution is to change the port configuration in the la.providerURL property in wkplc.properties. The article noted clustered configuration, but it made me realize that the port specified by default in the wkplc.properties had the default value using port 10031. This is a static port! Isn’t that special. Our 6.1 instance is running on a port range > 10050. I looked up the correct port in the v6.1 WAS Admin Console and changed the la.providerURL to point at the v6.1 port.