W PV 61 To 8 Migration Guide

Migration Step by Step Guide:
WebSphere Portal v6.1.0.5 to

WebSphere Portal v8
Author: Dhaval Patel

IBM WebSphere Portal Server Level 2 Support Specialist
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may be
used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you any
license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
The following paragraph does not apply to the United Kingdom or
any other country where such provisions are inconsistent with
local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF NONINFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some
states do not allow disclaimer of express or implied warranties in certain transactions,
therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements and/or
changes in the product(s) and/or the program(s) described in this publication at any
time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes
appropriate without incurring any obligation to you.
Any performance data contained herein was determined in a controlled environment.
Therefore, the results obtained in other operating environments may vary
significantly.
Some measurements may have been made on development-level systems and there is
no guarantee that these measurements will be the same on generally available
systems. Furthermore, some measurements may have been estimated through
extrapolation. Actual results may vary. Users of this document should verify the
applicable data for their specific environment
Information concerning non-IBM products was obtained from the suppliers of those
products, their published announcements or other publicly available sources. IBM has
not tested those products and cannot confirm the accuracy of performance,
compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those
products.
All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
All IBM prices shown are IBM's suggested retail prices, are current and are subject to
change without notice. Dealer prices may vary.
This information is for planning purposes only. The information herein is subject to
change before the products described become available.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
This information contains sample application programs in source language, which
illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to IBM,
for the purposes of developing, using, marketing or distributing application programs
conforming to the application programming interface for the operating platform for
which the sample programs are written. These examples have not been thoroughly
tested under all conditions. IBM, therefore, cannot guarantee or imply reliability,
serviceability, or function of these programs.
If you are viewing this information soft copy, the photographs and color illustrations
may not appear.
Preface This white paper assumes you have a good understanding and know the
concepts of migration. If you are not sure, please review the general
concepts of migration at the below provided location
1) WebSphere Portal 6.1 Information Center
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/index.jsp
2) WebSphere Portal 8.0 Information Center
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Migrating_wp8
SPECIAL NOTE: If you are using this guide on an operating system that is
different than the example documented, some allowances must be made to
convert commands and screens shown to your environment. This might
include changing executable script commands from batch files (.bat) to shell
scripts (.sh) or vice versa, or when using command-line utilities in place of
graphical interfaces that might be shown.
NOTE: Migrating to a WebSphere Portal V8 cluster and managed node is
supported from WebSphere Portal V6.1.x. Refer to the Migrating a V6.1.x
clustered environment in WebSphere Portal V8 Information Center for more
information.
Hence, WebSphere Portal V6.1.0.5 can be either stand-alone or clustered.
NOTE: Migrating to the empty portal 8 is not supported. Also private wires
doesn't get migrated
Migrating from version 6.0x :
Migration directly to WebSphere Portal V 8 is not supported from WebSphere
Portal Version 6.0.x.
When migrating from version 6.0.x you must first migrate to either
WebSphere Portal version 6.1.x (recommendation 6.1.0.5 or later) OR
7.x (recommendation 7.0.0.2 CF 14 or later)
Once you have migrated to WebSphere Portal version 6.1.x or 7.x, you
then migrate your data and portlets to version 8.0.
Migration is supported between equivalent offerings. For example, you can

migrate from WebSphere Portal Enable Version 6.1.0.x to WebSphere Portal
Enable Version 8.0, but not from WebSphere Portal Express Version 6.1.0.x
to WebSphere Portal Extend Version 8.0.
The table below summarizes all supported migration paths:

Table 1. Offerings and supported migration paths
Offering
WebSphere
WebSphere
Portal Express
Portal Version
Version 8.0
8.0 (Enable,
Extend)
Web Content
Management
Version 8.0
WebSphere Portal Supported

Express V6.1.x on
WebSphere
Application Server
Version 6.1
Not Supported
Not Supported
WebSphere Portal Not Supported

Server V6.1.x
(Enable, Extend)
on WebSphere
Application Server
Version 6.1
Supported
Supported
Web Content
Not Supported
Management V6.1
on WebSphere
Application Server
Version 6.1
Not Supported
Supported

Server V6.1.x
(Enable, Extend)
on WebSphere
Application Server
Version 7.0
Supported
Not Supported
Web Content
Not Supported
Manager V6.1 on
WebSphere
Application Server
Version 7.0
Not Supported
Supported
WebSphere Portal Supported

Express Version
7.x
Not Supported
Not Supported

Server Version
7.x
Supported
Not Supported
Web Content
Manager Version
7.x
Not Supported
Supported
Not Supported
Important: Migration is supported only from the two latest fix pack levels for
any listed offering. For example, if you are using WebSphere Portal Version
6.1.0.1, and the two latest available fix packs are 6.1.0.5 and 6.1.0.6, you
must apply one of those fix packs before you can migrate to WebSphere
Portal Version 8.0.
Important Note: You cannot upgrade the source portal with a fixpack after
migration if you intend to re-migrate the JCR. For example, if your source
portal is running Version 6.1.0.4 and you migrate the portal to Version 8.0,
you cannot then upgrade the source portal to Version 6.1.0.5 and migrate the
JCR again. This is not supported.
Operation System (OS) :
You can migrate from an older version of an operating system to a newer
supported version of that operating system, or from a 32bit version of an
operating system to a supported 64bit version of that operating system
Migrating between different operating systems is not supported. For example,
you cannot migrate from a Windows operating system to a UNIX operating
system.
General Note: Portlets and components in the source version are typically
not migrated if they are not available in the version to which you are migrating.
Examples include the Reminder, Document Viewer, Webpage portlet , My
Query reports, Microsoft Exchange 2003 portlets, Who is Here and Sametime
Contact List.
Also, migrated elements are not automatically upgraded to use features that
are available in the new version. Taking advantage of new functionality that
was not available in the source portal requires additional attention after
migration is complete.
WebSphere Portal also supports integration with additional products to extend
core functionality. If the earlier portal environment is configured to work with
one or more supported products that provided integrated features, you need
to follow the migration procedures for the integrated product.
Chapter 1
Getting started: WebSphere Portal migration
from V6.1.0.5 to V8
Introduction
This White paper describes the steps and best practices for migrating an
existing Standalone WebSphere Portal 6.1.0.5 + WebSphere Application
Server (WAS) 6.1.x environment to Standalone WebSphere Portal V8.
All the migration steps uses the command-line interface.
In this White Paper, the source environment that is being migrated is
configured to an DB2 database and is secured using file based
WIMUserRegistry and running on a linux. The target server has a V8 binary
build installed on the linux.
Both WebSphere Portal V.6.1.0.5 and V.8 servers are stand-alone servers
and are on different physical machines and hence would be doing remotemigration.
Pre-migration tasks
WebSphere Portal 6.1.0.5
Migration is supported only from the two latest fix pack levels
for any listed offering. So if you don't have the latest fix pack
then install it so before moving forward.
Install any recommended cumulative fixes and interim fixes on the

source server as suggested -- http://www01.ibm.com/support/docview.wss?rs=688&uid=swg27007603
Do the database transfer. I transfered from derby to DB2. Ensure

that you are running the minimum required level either V9.1 with
Fix Pack 6 or later, or V9.5 with Fix Pack 5 or later.
Installed the required fixes for migration mentioned in WebSphere

Portal 6.1 Information Center. See Section 2.2 of this white paper
Changes to the scheduled cleanup service settings are not

migrated. If you modified these settings in the earlier portal and
want to continue using the same settings in the new portal, you
must update the settings on the new portal. Keep a note to it and
update the setting on the new portal after migration.
To ensure that the wkplc_comp.properties file contains the

correct information, run the following commands:
ConfigEngine.bat validate-database-connection
Gather current statistics on all tables found in the JCR domain. We

recommend that the statistics gathering be done on all column, for
all tables and indexes and with at least a minimum level of sampling
and distribution. If you are using DB2, you need to run reorgchk
and runstats. Refer to your database documentation for details on
updating statistics.
Here are steps I did for updating database statistics on DB2 by
running the following commands:
db2 connect to <jcrdb>

where <jcrdb> is the name of the JCR domain
db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table

',concat(rtrim(tabSchema),concat('.',concat(rtrim(tabname),' on
all columns with distribution on all columns and sampled
detailed indexes all allow write access'))))) from syscat.tables
where type='T'"
This command is used to create a file, runstats.db2, which
contains all of the runstats commands for all of the tables.
db2 -v -f "runstats.db2"
This command uses the db2 command processor to run
previously created file
In WebSphere Portal Version 6.1.x, some custom JVM properties

were introduced to improve performance. Since Version 7.0, these
custom properties are no longer needed and are unavailable, hence
they need to be removed before migrating.
Log in to the WebSphere Integrated Solutions Console.
Go to Server -> Application servers -> select the appropriate

server.
Under Server Infrastructure, expand Java and Process
Management -> Process Definition.
Under Additional Properties, click Java Virtual Machine.
Under Additional Properties, click Custom Properties.
Find the javax.xml.transform.TransformerFactory property and
remove it.
If your source environment is clustered, repeat these steps for
each node in the cluster.
You need to disable JCR text search indexing. After migration is

complete, you need to re-enable JCR text search indexing.
1. Edit wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties.
2. Modify the values as follows :

key = jcr.textsearch.enabled
value = false
3. Restart portal for the changes to take effect.
If you have a large amount of content in the JCR repository (for

example, Web Content Manager data) then you want to check out
the section Preparing DB2 for large data sets migration in
WebSphere Portal 8 Information Center.
If you have created your own scripts during the Virtual Portal
creation then you want to check out the section Removing obsolete
portlets from virtual portal scripts in WebSphere Portal 8
Information Center.
See the section of Access Control in WebSphere Portal 6.1

Information Center and check the environment for any anonymous
users with the roles listed below and change them to User:
Privileged User
Editor
Manager
Delegator
Security Administrator
Administrator
Clean up your previous environment as follows:

If you deleted portal pages, use the deletion cleanup service.
See the section of Delayed cleanup of deleted portal pages in
WebSphere Portal 6.1 information center
If you deleted users or groups using your configured user

registry, make sure to deregister those users and groups using
either the XML configuration interface or the Manage Users and
Groups portlet. See the section of Deregistering users and
groups in WebSphere Portal 6.1 information center. One
should use CleanupUsers.xml file provided in their
<wp_home>\doc\xml-samples directory of WebSphere Portal
6.1.0.5.
Verify that you can stop and start WebSphere Portal and log in
to the default WebSphere Portal 6.1.0.5 welcome page.
Note - The users that are considered dead users, their artifacts will
not be migrated. This is how the migration scripts have been designed.
Hence, if you want the artifacts of the dead users to be migrated over,
administrator needs to re-enable the users that are marked as dead
users. This should be simple as administrator can just reactivate them
via LDAP.
Back up the databases and the entire directory structure for

your existing WebSphere Portal 6.1.0.5 environment. One
would be doing this as their regular maintenance strategy.
If you plan to migrate IBM Lotus Web Content Management data,

complete the remaining steps :
1. On the WebSphere Portal 6.1.0.5 server, remove locks on all Web
content items:
Go to the Administration view.
Go to Portal Content -> Web Content Libraries.
Click View Locked Items.
Select all items and then click Unlock.
2. If you are migrating from source portal server which have feature pack
installed (for instance, Version 6.1.5, 6.1.5.1, 6.1.5.2) , you must
manually update the getNlsStrings.js file in Web Content Management
to work correctly with the Version 8.0 portal.
c. On the source server, click Applications -> Content -> Web
Content Management.
d. In the authoring portlet, click Edit Shared Settings.
e. Add the blog library to the authoring portlet.
i. Click Library Selection.
ii. Select Blog Resources from the list of available libraries,
and click Add.
iii. Click OK.
f. Update the getNlsStrings.js file.
i. Download the new version of the getNlsStrings.js file from
ii.
iii.
iv.
v.
vi.
the WebSphere Portal product documentation.

Ensure that the Blog Resources library is selected in the
Library drop-down menu.
Select Components.
Select the check box for FILE - Get NLS Strings JS, and
click Edit.
In the File Resource Element section, click Browse and
navigate to the updated getNlsStrings.js file that you
downloaded.
Click Save and read to update the file and verify your
changes.
Note: If you do not update the getNlsStrings.js file before migration, the
browser might display this error when displaying a blog or wiki page:
ibmPortalConfig is not defined. If the error occurs after you update the
getNlsStrings.js file, you might need to clear the browser's cache or
delete any temporary internet files to ensure that the latest version of
the file is loaded from the server.
3. In Version 8.0, if the name of a web content library is the same as the
URL context of a virtual portal, you can experience incorrect rendering
behavior. To prevent this issue, rename the library to a different name
before you perform the migration.
For each web content library with a name that matches the URL context of a
virtual portal, complete the following steps on the source server.
Click Administration -> Portal Content -> Web Content Libraries.
For the library that you want to rename, click the Edit Library icon.
Enter a new name for the library that is distinct from the URL context of
the virtual portal.
WebSphere Portal 8
Install IBM WebSphere Portal Version 8.0 in the binary mode using
the IBM Installation Manager.
NOTE: Make sure you have selected EJBDeploy tool for pre-EJB 3.0
Modules under WAS v8.0.0.3 package. If you do not have this module
you may encounter issues during migration.
Below are installation steps :
1. Launch IBM Installation Manager .
2. Follow the on-screen instructions to install WebSphere Portal binary
files only.
Note: When installing on z/OS, binary installation is the only
available option
a. Follow the IBM Installation Manager instructions through the

different screens.
b. While in the Features screen, make sure that Create a new
Portal Server Profile and Create a new Deployment Manager
Profile augmented with WebSphere Portal are not selected.
c. Proceed with the remaining instructions to complete the binary

installation.
This option significantly reduces installation time and helps to avoid

potential conflicts. This option cannot be used when migrating from
V6.0.1.x to V8.
Attention: If you inadvertently perform a full install (instead of installing
only the binary code), you must remove the default profile as follows:
a) Use the WebSphere Application Server manageprofiles
command to delete the default profile (wp_profile). For detailed
instructions, see Deleting a profile in the WebSphere Application
Server V8.0 Information Center.
b) Manually remove the remaining wp_profile_root directory. See
your operating system documentation for instructions on
command syntax.
Upgrade the target server to the latest fix pack level with the latest
cumulative fix available. Here is the link to the list of recommended
fix packs and interim fixes -- http://www01.ibm.com/support/docview.wss?rs=688&uid=swg27007603
If you are doing the migration on production server you can not use
derby as the database. For a production environment, you must
use one of the other supported Database Management Systems.
See the following link for more details:
http://www10.lotus.com/ldd/portalwiki.nsf/dx/Database_considerations_wp7
There are additional considerations to keep in mind around the user

IDs and passwords when compared to a regular installation. The
xyzadmin is a reserved value and cannot be used as WebSphere
Portal or WebSphere Application Server administrator name. You
must change the administrator name from your source environment
if you are using this name.
If any virtual portals that exist in your earlier WebSphere Portal

environment, then it will be automatically will be migrated to V8
when upgrade-profile task is executed. You do not need to use the
create-virtual-portal ConfigEngine task to recreate each virtual
portal in V8.
If the earlier WebSphere Portal environment is configured to use an

external security manager then supported IBM and third-party
security settings are migrated automatically.
Increase the transaction log size for the database you are using for
the target server to prevent problems during migration.
Different factors can affect the transaction log file size that is
appropriate for your environment for example, the amount of data
stored in the portal databases, or the number of primary and
secondary log files in use. To avoid having migration tasks fail
because the transaction log file is too small, see your DBMS
documentation to determine the best option for increasing the
transaction log size before you start migration.
Check out the following link
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?
topic=/com.ibm.db2.udb.spatial.doc/cfgtranslog.html
As I am using db2, from the db2 control center I right click to the db
and selected configure database logging and changed the value as
suggested in above link.
If the portal 8 server is on AIX, Linux, Solaris, or i, increase the file

descriptor limit to 200000. For example: ulimit -n 200000
The ulimit command determines the maximum number of open files
that the operating system supports. By increasing the value before
you migrate exported content into the new portal installation, you
can avoid problems that might be caused if the value were too low.
After migration is complete, you can restore the earlier value.
Back up the databases and the entire directory structure for

your existing WebSphere Portal 8 environment. One would be
doing this as their regular maintenance strategy.
Considerations Migration can take a while, and interruptions to your HTTP connection during
the export process or import process can cause migration to fail. To avoid this
problem, use the internal WAS HTTP server port. For instance, by default in
wkplc.properties -- WpsHostPort=10040. If you have changed to port 80,
then change it to 10040. Once the migration gets completed, one can change
it back.
Deprecated features and portlets Some previously available portlets and features have been removed from
WebSphere Portal 8 because alternative or newer functionality is available
that you can use instead. If you migrate from an earlier WebSphere Portal
installation that used these portlets, the portlets are migrated to provide
backward compatibility, in some case they are treated as third-party portlets
and may get migrated forward. Users are encouraged to transition to other
available technology as appropriate.
See the section of Unsupported and deprecated features in WebSphere
Portal 8 information center.
URL Mappings If you have the urlmapping to the pages within the same WebSphere Portal
(not crossing the VP boundaries) then the URL mappings gets migrated. If
you have urlmapping to any admin pages, then it will not get migrated since
the admin pages do not get migrated.
Chapter 2
2.1 Make the Portlets applications available to migration tasks
1) Make your customized resources available to migration tasks One doesn't need to copy their custom portlet war files to installableApps
directory of WebSphere Portal 8 environment. Migration scripts would be able
to take care of your custom portlets.
Some of the WAR files in the portal_server_root/installableApps directory might

have been shipped with the current version. In that case, there is no need to
manually upgrade those portlets.
Also, copy any custom-shared library Java archive (JAR) files from both the
<app_server_root>/lib and <portal_server_root>/shared/app from WebSphere
Portal 6.1.0.5 environment to <wp_profile>/PortalServer/config directory of
WebSphere Portal 8 environment.
2) If you are using Cooperative portlets (c2a click to action - using IBM API)
then update your pbjportlet.jar file with the latest version of pbportlet.jar from
the WebSphere Portal 8 - In the WebSphere Portal 8 environment, locate pbportlet.jar in the
PortalServer_root/base/wp.propertybroker.legacy.impl/pb/lib
directory.
Copy the pbportlet.jar files to the WEB-INF/lib directory of the
cooperative portlet application that you are migrating.
Overwrite the JAR files if they already exist.
3) If you have struts portlet, then it should work as normal after completing the
migration process. If it does not then upgrade it with the latest struts
framework.
2.2 Installation of Fixes

There are two things one would need Portal Update Installer and Fixes.
2.2.1 Installing fixes on WebSphere Portal 6.1.0.5 environment
1) Download the Portal update installer for WebSphere Portal 6.1.X version
http://www-01.ibm.com/support/docview.wss?uid=swg24028760
2) Download the following fixes for WebSphere Portal 6.1.0.5 -Install any recommended cumulative fixes and interim fixes on the source
server as suggested -- http://www-01.ibm.com/support/docview.wss?
rs=688&uid=swg27007603
This is the cumulative fixes I installed on WebSphere Portal 6.1.0.5 Cumulative Fix #22 (CF011_PM65704) for Portal 6.1.0.5 / 6.1.5.2
Before you install the fixes, make sure portal server and server1 is stopped.
Now run either updatePortalWizard or updatePortal (command Line) to install
the aboves fixes.
Make sure to read the ReadMe.txt for ALL the fixes that one installs.
For instance, I executed ConfigEngine.bat apply-cumfix task after installing
CF22 (PM65704)
2.2.2 Installing fixes on WebSphere Portal 8 environment

1) You can use IBM Installation Manager to install any fixes or cumulative
fixes on installed IBM WebSphere Portal Version 8.0.
2) Download the following fixes for WebSphere Portal 8 -Install any recommended cumulative fixes and interim fixes on the target
server as suggested -- http://www-01.ibm.com/support/docview.wss?
uid=swg24027857
2.3
Search Components from Portal 6.1.0.5
Migrating the search components in your portal might require preparation

steps on the source portal and then additional steps on the migrated portal.
For Migrating the search components, see the section of Migrating search
components in WebSphere Portal 8 Information Center.
Chapter 3
In this chapter we would be doing core migration of our resources from
WebSphere Portal 6.1.0.5 to 8. Remember I am doing the Remote Machine
Migration. As I did migrated from a stand-alone portal 6.1.0.5 to stand-alone
portal 8 I followed the section Migrating from WebSphere Portal V6.1.x on a
V6.1 application server in WebSphere Portal 8 Information Center.
If the source portal and target portal are located on the same server, you can
migrate the source portal's application server profile by completing a set of
manual steps or by using the IBM WebSphere Application Server
Migration wizard to create the profile automatically for you.
WebSphere Application Server provides a Migration wizard,
AppServer_root/bin/migration.bat(sh), that automatically creates the
profile in the AppServer_root/profiles directory. To create the profile in a
specified location, you can use either the Profile Management Tool (PMT) (on
32-bit application server) or the manageprofiles command (on 64-bit
application server). Then, when you use the Migration wizard, you can select
the new profile as the target profile for migration.
Note: When pre-creating a profile, create a default application server profile
and install the admin console only; do not install any sample applications.
If you used WebSphere Application Server Migration Wizard then it will
create a profile
execute WasPreUpgrade.bat(sh) task
execute WasPostUpgrade.bat(sh) task

Make sure it is successful. If you used Migration Wizard then you can jump to
Step 5. Otherwise follow the below mentioned manual steps.
Also check out - Appendix A for some general migration errors/exception
one might get.
Step 1 : Prepare files for Remote Migration

Check the following first -
Back up the databases and entire directory structure for your

WebSphere Portal 6.1.x environment.
Same Machine Migration : This step is not required if you are doing the same
machine migration.
Before migrating to a remote server, you need to prepare a directory that
contains required files from WebSphere Application Server combined with
additional files that WebSphere Portal provides
As I am doing the remote machine migration, I need to generate the zip/jar
which is required for the execution of the waspreupgrade.
First create the directory where you will be saving zip/jar file. For
instance, I created a directory called RemoteMigr.
Navigate to <PortalServer_root>\bin directory of your WebSphere

Portal 8 server and run the following task.
./genRemMigPkg.sh /portal/WebSphere/RemoteMigr
Make sure that you specify the full path to the directory.
Now copy the jar file to the source machine (portal 61x) where the
source profile resides. For instance, I copied the jar file to
<wp_profile>/temp of source server.
Extract the jar file to a temp location
Ensure that read and execute permissions are set on the extracted files
by running chmod -R 755 *
Step 2 : Execute WASPreUpgrade command

Same Machine Migration : Navigate to <Appserver_root>\bin directory of your
WebSphere Portal 8 server and run the below task without -machineChange
true parameter.
Remote Machine Migration : On Portal 61x environment first increase the
ulimit size and then navigate to the bin directory in the temp location where
you extracted jar file in step 1.
Execute the WASPreUpgrade command against the source profile to be
migrated using the -machineChange true parameter.
WASPreUpgrade.sh backup_dir source_WasHome -traceString
trace_spec -traceFile trace_file -oldProfile
wp_profile_name -machineChange true -javaoption -Xmx1024m
I executed the following command from Portal 61x environment :
ulimit -n 200000
<61_wp_profile>/temp/bin/WASPreUpgrade.sh
/portal/WebSphere/waspreupgradebk /portal/WebSphere/AppServer
-oldProfile wp_profile -machineChange true -javaoption -Xmx1024m
backup_dir
Specifies the directory on the source portal where the WASPreUpgrade
command stores the exported profile data. If the directory does not
exist, the WASPreUpgrade command creates it.
source_WasHome
Specifies the WebSphere Application Server installation directory on
the source server.
wp_profile_name
Specifies the portal profile on the source server
Optional
trace_spec
Specifies the trace information that you want to collect. To gather all
trace information, specify "*=all=enabled" (including the quotation
marks). If you include this parameter, you must also specify the
trace_file.
If you do not specify the -traceString or -traceFile parameter,
the command creates a trace file by default and places it in the
backupDir/logs directory. If you specify the -traceString
parameter but omit the -traceFile parameter, the command does
not generate a trace file.
trace_file
Specifies the name of the output file where trace information is stored.
backupDirectory/logs directory. If you specify the
-traceString parameter but omit the -traceFile parameter, the
command does not generate a trace file.
This task will create the WASPreUpgrade.<timestamp>.log file under logs of

the provided backup_dir location.
NOTE: If the WASPreUpgrade task fails with out of memory error then you
can increase the flag -javaoption to a higher value.
Move the backup directory that contains the source portal's exported data to
the target server where the new version of WebSphere Portal 8 is installed by
using a compression utility to compress the directory contents, or map a drive
to the remote server, and then move the directory containing the exported
data to the remote server.
I zipped up the entire waspreupgradebk directory on Portal 6x environment
and moved it to Portal 8x environment.
Step 3 : Create a wp_profile for Portal 8

Check the following first -
Back up the databases and entire directory structure for your

existing WebSphere Portal 8 environment.
I am using the manual steps to create the wp_profile on the target portal
server and migrating the wp_profile from the source portal server.
Create a directory wp_profile8 on your target portal server. For instance,
my wp_profile8 directory is at /portal/WebSphere/wp_profile8
Navigate to <Appserver_root>\bin directory of your WebSphere Portal 8
server and run the following task.
./manageprofiles.sh -create -defaultPorts -enableAdminSecurity false
-profileName wp_profile8 -profilePath /portal/WebSphere/wp_profile8
-templatePath /portal/WebSphere/AppServer/profileTemplates/default
-nodeName wps61 -cellName wps61 -hostName 61xTo8xMigration -isDefault
-omitAction samplesInstallAndConfig defaultAppDeployAndConfig
wp_profile_name
Specifies the profile on the target server or node to which the source
portal profile is to be migrated.
profile_path
Specifies the profile on the target server or node to which the source
portal profile is to be migrated.
source_node_name
Specifies the node name for the node that is created with the new
profile. Use a unique value within the cell or on the server.
source_cell_name
Specifies the cell name of the source portal profile.
host_name
Specifies the host name for the target server or deployment manager
where you are creating the profile.
Note: NodeName and CellName needs to be same. if not then there would
be problem with deploying the application later on.
Make sure the manageprofiles task gets completed successful as mentioned
below:
INSTCONFSUCCESS: Success: Profile wp_profile8 now exists. Please
consult /portal/WebSphere/wp_profile8\logs\AboutThisProfile.txt for more
information about this profile.
Note: If you forgot to have the parameter profileName or mispelled it, then it
will create a profile named AppSrv01.
AboutThisProfile.txt file will show the location, node name, host name and
port information that got associated when the profile got created.
For instance, this is from my AboutThisProfile.txt
Application server environment to create: Application server
Location: /portal/WebSphere/wp_profile8
Disk space required: 200 MB
Profile name: wp_profile8
Make this profile the default: True
Node name: wps61
Host name: 61xTo8xMigration
Enable administrative security (recommended): False
Administrative console port: 9060
Administrative console secure port: 9043

HTTP transport port: 9080
HTTPS transport port: 9443
Bootstrap port: 2809
SOAP connector port: 8880
Run application server as a service: False
Create a Web server definition: False
Performance tuning setting: Standard
Step 4 : Execute WASPostUpgrade command for Portal 8

Navigate to <Appserver_root>\bin directory of your WebSphere Portal 8
AppServer_root/bin/WASPostUpgrade.sh backup_dir -profileName
wp_profile_name -oldProfile old_wp_profile_name -username
source_admin_user -password source_admin_password
-includeApps true -backupConfig false -traceString
trace_spec -traceFile trace_file -javaoption -Xmx1536m
I executed the following command :
ulimit -n 200000
./WASPostUpgrade.sh /zippy/portal/WebSphere/waspreupgradebk
-profileName wp_profile8 -oldProfile wp_profile
-username wpsadmin -password wpsadmin -includeApps true -backupConfig
false -javaoption -Xmx1536m
backup_dir
Specifies the directory where the WASPreUpgrade command stores
the data that it exports from the source server, and from which the
WASPostUpgrade command reads and imports data.
wp_profile_name
Specifies the new portal profile on the target server or node to which
the WasPostUpgrade command migrates the source portal profile.
old_wp_profile_name
Specifies the source portal's profile name. The profile name must
already exist in the backup directory specified above.
source_admin_user
Specifies the administrator ID for the source portal. Specify the login
form of the administrator ID rather than the fully qualified name; for
example, specify wpsadmin rather than uid=wpsadmin,

o=defaultWIMFileBasedRealm.
source_admin_password
Specifies the administrator ID password for the source server.
Optional
trace_spec
Specifies the trace information that you want to collect. To gather all
trace information, specify "*=all=enabled" (including the quotation
marks). If you include this parameter, you must also specify the
trace_file.
backupDir/logs directory. If you specify the -traceString
parameter but omit the -traceFile parameter, the command does
not generate a trace file.
trace_file
Specifies the name of the output file where trace information is stored.
backupDirectory/logs directory. If you specify the
-traceString parameter but omit the -traceFile parameter, the
command does not generate a trace file.
NOTE: If the WASPostUpgrade task fails with out of memory error then you
can increase the flag -javaoption to a higher value.
Important Note: After running the WasPostUpgrade command on a local
server, it is possible to start the portal server for verification purposes.
However, because the migration process is not complete, there might be
errors in the SystemOut.log file. These errors are usually resolved after the
upgrade-profile task completes. It is important that you not attempt to run in
production when the migrated portal is in this state. If you start the portal for
verification at this point, you must stop the portal before running the
upgradeConfigEngine command.
This task will create the WASPostUpgrade.<timestamp>.log file under logs of
the provided backup_dir location.
Look at the logs and confirm the task got completed successfully.
You can ignore the following message if you see in the log file
WASX7017E: Exception received while running file
"/C:/wp7/waspreupgradebk/install_WebDAV_for_WebSphere_Portal.ear.jy";
exception information:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.DeploymentDescri
ptorLoadException:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.DeploymentDescri
ptorLoadException: dd_in_ear_load_EXC_
MIGR0340W: Application WebDAV_for_WebSphere_Portal.ear did not deploy
If any of the custom application failed to deploy during this task, then you
needs to investigate where it is failing. One of the common scenario it may
fail to deploy is because the custom application contains characters like
apostrophe or single quote. If this is the case, you can also look at the Jython
scripts for that custom application at
<backup_dir>\profiles\wp_profile\PortalApps. You should just fix the Jython
script instead of fixing in the source portal server and then try to run/deploy
that custom application individually using the wsadmin command.
For instance, if you want to execute Jython file ex1.py then one can do the
following wsadmin> execfile ("ex1.py") or execfile("ex1.py")
wsadmin is located in <AppServer_root>\bin directory.
For more information on wsadmin reference the following link
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=
%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae
%2Fwelc6topscripting.html
Step 5 : Execute the ConfigEngine tool on Portal 8

Navigate to <Portalserver_root>\bin directory of your WebSphere Portal 8
upgradeConfigEngine.sh profile_name -conntype
connection_type -WasRemoteHostName host_name -WasSoapPort
port_number -user admin_name -password admin_password
-LocalHostName local_host_name
I executed the following command :
./upgradeConfigEngine.sh wp_profile8 -conntype SOAP
-WasRemoteHostName 61xTo8xMigration -WasSoapPort 10005 -user
wpsadmin -password wpsadmin -LocalHostName 61xTo8xMigration
profile_name
Specifies the name of the WebSphere Application Server V7 profile
that is the target of the upgrade.
connection_type
Specifies the type of connection that should be established. Valid
connection types are SOAP and NONE.
WasRemoteHostName
Specifies the host name of the application server (when migrating a
stand-alone server) or Deployment Manager (when migrating a
clustered environment).
WasSoapPort
Specifies the port number of the application server (when migrating a
stand-alone server) or Deployment Manager (when migrating a
clustered environment). Use the value of WasSoapPort from the
wkplc.properties file.
admin_name
Specifies the administrator user ID for the application server.
admin_password
Specifies the password for the administrator user ID.
LocalHostName
Specifies the local system's host name. In a non-managed
environment, this is the same as host_name.
Trace information is stored in the UpgradeConfigEngineTrace.log file in the

wp_profile_root/ConfigEngine/log directory.
Make sure the upgradeConfigEngine task gets completed successful as
mentioned below:
EJPMA6301I: The request was processed successfully see file
/portal/WebSphere/wp_profile8/ConfigEngine/log/UpgradeConfigEngineTrace.
log for details on the results.
Step 6 : Re-use copies of source database domains to

minimize downtime on Portal 8
When you migrate from IBM WebSphere Portal V6.1.x on IBM WebSphere
Application Server V6.1, the recommended way to keep the earlier portal
environment in production and reduce the amount of downtime during
migration is to copy the earlier portal server JCR and Release domains,
connect to the domain copies, and then update the new portal server using
the domain copies. The process of connecting to the domain copies must be
done after you upgrade the ConfigEngine tool but before you upgrade the
V6.1.x profile.
Important: Copying the V6.1.x JCR and Release domains is recommended
but not required. However, if you choose to have the new portal server point
directly to the V6.1.x domains (instead of to copies of the domains), you will
not be able to continue using the domains with the earlier portal server.
Below are the things i did in my environment Note: Instead of just re-using JCR and Release domain, I copied ALL of the
domains including feedback, likeminds, customization, community.
A) Make a copy of Portal 6.1.0.5 JCR DB by running backup and restore
command of db2. For instance,
db2 backup db <orig_db> to <dir>
db2 restore db <orig_db> from <dir> into <new_db>
Here is the commands which show the backup and restore for JCR and
Release domain:
$ db2 backup db jcrdb to /db2users/users/db2inst1/dhaval
$ db2 backup db reldb to /db2users/users/db2inst1/dhaval
$ db2 restore db jcrdb from /db2users/users/db2inst1/dhaval into bkjcrdb8
DB20000I The RESTORE DATABASE command completed successfully.
$ db2 restore db reldb from /db2users/users/db2inst1/dhaval into bkreldb8
DB20000I The RESTORE DATABASE command completed successfully.
DB2 only: On the database copies, verify that the Statement Heap size is set
to at least 32k.
a. List the database manager configuration parameters by running the
following command db2 get db cfg for dbname.
b. If the Statement Heap size is smaller than 32k, increase it by running
the following commanddb2 "UPDATE DB CFG FOR dbname USING
stmtheap 32768"
B) Configure your Portal 8.x envinorment by updating the following files to

reflect a connection to the ALL domain copy that you created in the previous
step:
For instance, for the JCR domain :
Open wkplc.properties file and ensure WasPassword and

PortalAdminPwd parameters are correct
Open wkplc_dbdomain.properties.properties file and configure JCR

domain db. This is what it looks like after I configured
jcr.DbName=bkjcrdb8
jcr.DbSchema=jcr (Needs to same schema value for <orig_db>)
jcr.DataSourceName=wpdbDS_bkjcrdb8
jcr.DbUrl=jdbc:db2://hostname:50000/bkjcrdb8:returnAlias=0;
NOTE : Steps C and D are ONLY needed for Same Machine Migration.
For Remote Migration continue with step E.
C) If you are migrating a stand-alone environment, before connecting to the
domain copies, change the WebSphere Application Server and WebSphere
Portal port numbers by running the modify-ports-by-startport task.
Here is reference link for modify-ports-by-startport task -- http://www10.lotus.com/ldd/portalwiki.nsf/dx/Changing_ports_wp8
Here are the things that I did :
Navigate to <wp_profile8>/ConfigEngine directory and execute the following
task :
1) ConfigEngine.bat list-server-ports-by-name -DServerName=server1
-DwasPassword=password
ConfigEngine.bat list-server-ports-by-name
-DServerName=WebSphere_Portal -DWasPassword=password
The above task will creates a server1_PortMatrix.txt and
WebSphere_Portal_PortMatrix.txt under
<wp_profile8>/ConfigEngine/log directory which will show you what are
ports that are currently configured with your server1 and
WebSphere_Portal.
Observe this will be the same ports which the wp_profile used from the
source environment.
For instance, here is the output from my server1_PortMatrix.txt :
Ports for server1 :
WC_defaulthost=15000
WC_adminhost=15001
WC_defaulthost_secure=15002
WC_adminhost_secure=15003
BOOTSTRAP_ADDRESS=15004
SOAP_CONNECTOR_ADDRESS=15005
Here is the output from my WebSphere_Portal_PortMatrix.txt :
Ports for WebSphere_Portal :
WC_defaulthost=15040
WC_adminhost=15027
WC_defaulthost_secure=15035
WC_adminhost_secure=15041
BOOTSTRAP_ADDRESS=15031
SOAP_CONNECTOR_ADDRESS=15033
Now as both source and target servers on the same machine, you can't use
the same ports between the source and target servers. If not then will cause
the port conflicts. For the target server I want to use the ports starting from
16000, hence I executed the following tasks
2) ConfigEngine.bat modify-ports-by-startport
-DWasPassword=password -DModifyPortsServer=server1
-DStartPort=16000
ConfigEngine.bat modify-ports-by-startport -DWasPassword=password
-DModifyPortsServer=WebSphere_Portal -DStartPort=16040
D) Look in the serverindex.xml file and see what are the correct ports that got
associated with server1 and WebSphere Portal server.
Now modify WasSoapPort and WpsHostPort parameter in wkplc.properties
with the correct port numbers.
For instance,
WasSoapPort=16040
WpsHostPort=16054
E) Change to the wp_profile_root/ConfigEngine directory, and then enter the
following commands to validate the configuration properties:
ConfigEngine.bat connect-database
Note: If you just copied the Release and JCR domain, then you want to use
the following commands :
-DTransferDomainList=release,jcr
ConfigEngine.bat connect-database -DTransferDomainList=release,jcr
Important: If a database domain in the earlier portal server uses assigned
custom table spaces that you want to retain for use on the new portal server
(instead of using the default table spaces), you need to update the table
space property file and the index space property file for the database table.
Check out the sections of Retaining custom table spaces in the WebSphere
Portal 8 Information center.
Note: If the portal uses IBM DB2 Universal Database for z/OS as the
backend repository then check out the sections of Updating schemas in the
WebSphere Portal 8 Information center.
F) Gather current statistics on all tables found in the JCR domain. We
recommend that the statistics gathering be done on all column, for all tables
and indexes and with at least a minimum level of sampling and distribution. If
you are using DB2, you need to run reorgchk and runstats. Refer to your
database documentation for details on updating statistics.
Here are steps I did for updating database statistics on DB2 by
running the following commands:

where <jcrdb> is the name of the JCR domain
db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table

',concat(rtrim(tabSchema),concat('.',concat(rtrim(tabname),' on
all columns with distribution on all columns and sampled
detailed indexes all allow write access'))))) from syscat.tables
where type='T'"
This command is used to create a file, runstats.db2, which
contains all of the runstats commands for all of the tables.
db2 -v -f "runstats.db2"
This command uses the db2 command processor to run
previously created file
G) Also to avoid any kind of deadlocks during the migration task, one must
adjust their db2 configuration accordingly:
db2 update db cfg using locklist 5000
db2 update db cfg using maxlocks 75
H) Note for Oracle db only : Would recommend using oracle jdbc driver
version 11.1.0.1 ,11.2.0.3, 11.2.0.4 or higher. Do not use jdbc driver version 11.2.0.1 and 11.2.0.2.
Step 7 : Upgrading the V6.1.x profile on Portal 8

In this step we will migrate properties files, upgrade database domains, and
apply other updates that are needed to bring the source profile to the V8 level
by running the upgrade-profile task.
Navigate to the wp_profile_root/ConfigEngine directory of Portal 8 server and
then run the following command:

ConfigEngine.bat upgrade-profile -DWasPassword=password
-DportalAdminPwd=password -Dwcm.transactionTimeout=1200
Very Important: It is recommended you execute step 7 F) against all the
databases, every half an hour of the upgrade-profile execution.
Important: If you updated the database schemas manually, you must include
the parameter -DDbSafeMode=true. For example: ConfigEngine.bat
upgrade-profile -DWasPassword=WasAdminPwd
-DPortalAdminPwd=PortalAdminPwd -DDbSafeMode=true
Do not specify this parameter if you want the migration process to update the
database schemas for you.
Important: If you are migrating a large amount of content in the JCR
repository (for example, Web Content Manager data), include the parameter
-Dwcm.transactionTimeout=timeout_value. A value of at least 1200 is
recommended and has been used successfully in IBM testing. For example:
ConfigEngine.bat upgrade-profile -DWasPassword=WasAdminPwd
-DPortalAdminPwd=PortalAdminPwd -Dwcm.transactionTimeout=1200.
Step 8 : Validate the migration
Make sure upgrade-profile task gets completed successfully. Also

check there are no errors in the ConfigTrace.log and
upgradeConfigEngineTrace.log in wp_profile_root/ConfigEngine/log
directory.
If you cloned the FileServer portlet in the WebSphere Portal 6.1.0.5

and supplied HTML files in the
wp_old_root/installedApps/FileServer_PA_1_0_4H.ear/FileServer.war/
FileServerPortlet/html directory, you must copy those files to the
PortalServer_root/installedApps/Cell_name/PA_FileServer.ear/FileServ
er.war/FileServerPortlet/html directory, after running the portal-postupgrade task and before restarting the server, to make the files
accessible in WebSphere Portal 8.
Start the WebSphere Portal 8 server and the hit the migrated portal
URL, which is in the following format/form:
http://host_name:port_number/original-context-root_migrated/portal
For instance, if your original portal URL is
http://www.example.com:10040/wps/portal, the URL for the migrated
portal is
http://www.example.com:10040/wps_migrated/portal.
Important: First time of the portal server after migration will take a very long
time as it is re-indexing all the JCR contents.
Note: During migration, the following changes are made to the
wkplc.properties file stored in the wp_profile_root/ConfigEngine/properties
directory:
The property WpsContextRootOriginal is set to the original value

of the context root before migration was performed. This
property is for reference only and is not used by the migrated
portal.
The value of the WpsContextRoot property is set to the migrated
value original-context-root_migrated (for example,
wps_migrated).
Chapter 3
3.1 WCM Migration By completing above steps you have completed the WebSphere Portal
migration steps. If you have Web Content Management (WCM) data then
need to perform additional steps to complete your web content migration as
mentioned in the section of Web content post migration steps in WebSphere
Portal 8 Information Center.
3.2 Updating portlets URL In some cases the URLs of the portlet are incorrect after the migration. URLs
can be easily corrected using the XML configuration interface to export,
update, and import the configurations.
For the detail steps please see the section of Updating portlets URL in
WebSphere Portal 8 Information Center.
3.3 Updating Themes and Skins 3.3.1 Custom themes and skins
As the context root has been changed for the custom themes and skins this
can cause problems if you have developed custom themes or skins that
contain hardcoded references to the portal's context root. (This is particularly
an issue after migration because the context root is modified during migration,
causing hardcoded references to break.) You can update your themes and
skins to remove the hardcoded references and instead use dynamic
references that work properly regardless of the context root as mentioned in
the section of Updating custom themes and skins for hardcoded context root
references in WebSphere Portal 8 Information Center.
Also the above section talks about how you can change the context root for
your custom themes and skins application so that you can use desired context
root.
3.3.2 Modifing the context uri
Note: If your intention is to change the context root of migrated portal server
to /wps then first make sure you have changed the context root of the
MigratedThemes.war from /wps to /xyz or whatever you want.
You can change the context root for the Migrated Portal server by editing
wkplc.properties for WpsContextRoot and wkplc_comp.properties for
WpsDefaultHome and then executing modify-servlet-path configuration
task to modify the portal URI.
Navigate to the wp_profile_root/ConfigEngine directory of Portal 8 server and
then run the following command:
ConfigEngine.sh(bat) modify-servlet-path -DPortalAdminPwd=password
-DWasPassword=password
3.4 Deploying new functionality on Portal 8 Migration process doesn't incorporate the new Portal 8 functionalities by
default. As a result when you hit your migrated Portal 8 server it will look
identical as of your source environment. Hence you would execute few
manual tasks to take advantage of new functionality on migrated Portal 8
server as mentioned in the section of Deploying new functionality in a
migrated portal in WebSphere Portal 8 Information Center.
Appendix A Common Migration Messages

Below contains information about various migration messages and the
content in the log file that one might received during the migration.
1. If the source portal server was installed using the content build (Portal +
WCM) and if the target server was installed only by using Portal server binary
code as WCM is not been used in source, then during the upgrade-profile task
the target portal server would not start cleanly. As a result the task will fail
with Error 404: javax.servlet.UnavailableException: Initialization of one or
more services failed
Also the systemout logs will show ClassNotFoundException during the wps
application startup as seen below :
Servlet E com.ibm.wps.engine.Servlet init EJPFD0016E: Initialization of
service failed.
java.lang.ClassNotFoundException:
com.ibm.workplace.wcm.api.WebContentCustomWorkflowService
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:139)
at
com.ibm.wps.services.ServiceManager.initInternal(ServiceManager.java:260)
at
com.ibm.wps.services.ServiceManager.init(ServiceManager.java:173)
at
com.ibm.wps.services.ServiceManager.init(ServiceManager.java:115)
at com.ibm.wps.engine.Servlet.init(Servlet.java:252)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:35
8)
Migrating from environment which contains WCM to an environment which
doesnot contain WCM is not supported. Refer to the section of Supported
Migration Paths in Portal 8 infocenter http://www10.lotus.com/ldd/portalwiki.nsf/dx/Supported_migration_paths_wp8
2. One may see the following error in the systemout.log file while executing
upgrade-profile task --DataStoreCont E com.ibm.wps.datastore.impl.DataStoreContext
handleException EJPDB0001E:
Error occurred during database access. Last SQL statement is [SELECT
OID, CREATED, MODIFIED, RESOURCE_ROOT, IS_ACTIVE,
IS_DEFAULT, DEFAULT_LOCALE, TYPE, CONTEXT_ROOT,
THEME_SCOPE_OID FROM release.SKIN_DESC ].
com.ibm.wps.datastore.impl.DataBackendException: EJPDB0002E: Error
occurred during database access.
at
com.ibm.wps.datastore.impl.DataStoreContext.handleException(DataStoreCo
n
text.java:337)
at
com.ibm.wps.datastore.impl.ResourcePersister.findInternal2(ResourcePersi
ster.java:1150)
at
com.ibm.wps.datastore.impl.ResourcePersister.findInternal(ResourcePersis
ter.java:1050)
at
com.ibm.wps.datastore.impl.ResourcePersister.findAll(ResourcePersister.j
ava:1715)
...............
...............
Caused by: java.sql.SQLException: ORA-00904: "THEME_SCOPE_OID":
invalid identifier
at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:11
2)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)
The above error most likely points that one have missed out the steps on
database copy and connection task that needs to be executed on the portal 8
server.
3. One may see the following error in the systemout.log file while executing
upgrade-profile task --InternalGetSc E
com.ibm.wps.command.scheduler.internal.InternalGetSchedulerTaskComma
nd
AbstractCommand.throwCommandException EJPDD0009E: JNDI naming
lookup failed for name = [ejb/wpsSchedulerManager].
javax.naming.NameNotFoundException:
Context: <cell_name>/nodes/<node_name>/servers/WebSphere_Portal,
name:
ejb/wpsSchedulerManager: First component in name wpsSchedulerManager
not
found. [Root exception is
org.omg.CosNaming.NamingContextPackage.NotFound:
IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at
com.ibm.ws.naming.jndicos.CNContextImpl.mapNotFoundException(CNCont
extImpl.java:4365)
at
com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:17
94)
at
com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:17
49)
The above is wps_scheduler.ear application. Because this application does
not start, the wps app fails to start:
The reason wps_scheduler.ear does not start is because of this exception
here:
FileDocument E ADMR0104E: The system is unable to read document
cells/dmnalx0267/cus/wps_scheduler/cver/BASE/cu.xml:
java.io.IOException: Permission denied
at java.io.File.checkAndCreate(File.java:1704)
at java.io.File.createTempFile(File.java:1792)
at
com.ibm.ws.management.repository.FileDocument.createTempFile(FileDocu
ment.java:564)
Similar exceptions would appear for few other applications.
The problem appears to be file permissions. Somehow the file permissions
have become corrupted. Easiest way to fix this is to figure out which user is
supposed to be running the WebSphere_Portal server, and run chown -R for
whatever this user is over his entire Portal file structure (AppServer,
wp_profile, PortalServer).
4. In UpgradeConfigEngineTrace.log file one could see the following

exceptions :mig-stop-admin-server:
[echo] 'server1' seems being started.
[echo] Stopping 'server1' ...
mig-set-instance-properties:
mig-stop-server-helper:
[exec] ADMU0116I: Tool information is being logged in file
[exec]
C:\IBM\WebSphere\wp_profile\logs\server1\stopServer.log
[exec] ADMU0128I: Starting tool with the wp_profile profile
[exec] ADMU3101I: Using explicit host and port localhost:10005 for
server: server1
[exec] ADMU0111E: Program exiting with error:
javax.management.JMRuntimeException:
[exec]
ADMN0022E: Access is denied for the stop
operation on Server MBean
[exec]
because of insufficient or empty credentials.
[exec] ADMU4113E: Verify that username and password information is

correct. If
[exec]
running tool from the command line, pass in the
correct -username
[exec]
and -password. Alternatively, update the
<conntype>.client.props
[exec]
file.
[exec] ADMU1211I: To obtain a full trace of the failure, use the
-trace option.
[exec] ADMU0211I: Error details may be seen in the file:
[exec]
C:\IBM\WebSphere\wp_profile\logs\server1\stopServer.log
BUILD FAILED
C:\IBM\WEBSPH~1\PORTAL~1\installer\wp.migration.framework\config\inclu
des\mig_cfg.xml:294: The following error occurred while executing this
line:
des\mig_cfg.xml:404: The following error occurred while executing this
line:
des\mig_cfg.xml:435: exec returned: -1
Also checking the stopServer.log file :WsServerStop E ADMU3002E: Exception attempting to process server
server1
WsServerStop E ADMU3007E: Exception
javax.management.JMRuntimeException: ADMN0022E: Access is denied for
the stop operation on Server MBean because of insufficient or empty
credentials.
WsServerStop A ADMU3007E: Exception
javax.management.JMRuntimeException: ADMN0022E: Access is denied for
the stop operation on Server MBean because of insufficient or empty
credentials.
at
com.ibm.ws.management.connector.soap.SOAPConnectorClient.handleAdmi
nFault(SOAPConnectorClient.java:933)
at
com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemp
lateOnce(SOAPConnectorClient.java:901)
at
late(SOAPConnectorClient.java:667)
Most likely one used the incorrect port while executing upgradeConfigEngine
task. Try using the value of WasSoapPort from the wkplc.properties file for
the -port parameter.

5. After migration is completed one may notice the following messages in the
systemout.log files when they navigate various pages on the migrated portal
server.
servlet I
com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I:
[MigratedThemes] [/xxxthemes] [/themes/html/xxx/Default.jsp]:
Initialization successful.
[10/5/11 10:20:26:376 EDT] 00000040 StorageApi E
com.ibm.wps.policy.commands.StorageApi getPolicyRoot EJQAB0067E: An
error occurred while getting the policy root.
com.ibm.portal.WpsException:
EJQAB0067E: An error occurred while getting the policy root.
at
com.ibm.wps.policy.commands.StorageApi.getPolicyRoot(StorageApi.java:35
6)
at
com.ibm.wps.policy.commands.StorageApi.getPolicyRootName(StorageApi.ja
va :284)
at
com.ibm.wps.policy.commands.StorageApi.getPvsProperties(StorageApi.java
: 1363)
at
com.ibm.wps.policy.services.PolicyService.getPolicy(PolicyService.java:193)
at
com.ibm.wps.policy.services.PolicyCacheManager.getPoliciesFromResposito
ry(PolicyCacheManager.java:425)
.....
.....
Caused by: java.lang.NullPointerException
at
com.ibm.content.util.internal.InternalTypeRegistry.getEClassifier(Intern
alTypeRegistry.java:341)
at
com.ibm.content.util.internal.JcrInternalTypeRegistry.getType(JcrInterna
lTypeRegistry.java:222)
at
com.ibm.content.mediator.handler.jcr.cm.DataObjectHandlerImpl.createData
Object(DataObjectHandlerImpl.java:1036)
PolicyService E com.ibm.wps.policy.services.PolicyService getPolicy
Exception calling storage api: com.ibm.portal.WpsException: EJQAB0067E:
An error occurred while getting the policy root.
PolicyManager E
com.ibm.wps.policy.services.PolicyManagerServerSideImpl getPVSByPath
throwing exception. PVS type not found for theme/SingleTopNavMinimal
ThemePolicyMa E com.ibm.wps.theme.policy.ThemePolicyManager
getThemePolicyValueSet(String themepolicypath) EJPNG0003E: Unable to
retrieve the assigned theme policy value set. Default values will be used.
com.ibm.wps.policy.services.exception.PolicyNodeNotFoundException
at
com.ibm.wps.policy.services.PolicyManagerServerSideImpl.getPVSByPath(P
olicyManagerServerSideImpl.java:363)
at
com.ibm.wps.theme.policy.ThemePolicyManager.getThemePolicyValueSet(T
hemePolicyManager.java:227)
The error messages may not be breaking any functionalities in the migrated
environment but just filling the log files.
Most likely the issue is happening because the migrated environment is
missing a application content_j2ee.ear
So first make sure one do indeed have content_j2ee application
installed on their environment. Go to
<wp_profile_home>\config\cells\<cellname>\applications and one should
see the content_j2ee application.
If you donot see content_j2ee application in the above folder that means one
does not have content_j2ee application installed on this environment.
Run the following task to install the content_j2ee application :
ConfigEngine.sh/bat action-create-ear-contentapi.j2ee
Restart the portal server for the testing purpose.
6. One may get the following error related with SOAP connection issue or
some timeout issue during upgrade-profile task.
Caused by:
com.ibm.wps.pe.mgr.exceptions.AppServerAdminCheckException:
EJPPH0005E: Failed to check if application PA_WCM_Authoring_UI is
installed or not installed.
at
com.ibm.wps.pe.mgr.appserveradmin.utils.AdminUtils.check(AdminUtils.java:
242)
.....
.....
Caused by: com.ibm.websphere.management.exception.AdminException:
at
com.ibm.websphere.management.application.AppManagementProxy.proxyIn
voke(AppManagementProxy.java:175)
....
....
Caused by: com.ibm.websphere.management.exception.ConnectorException:
ADMC0009E: The system failed to make the SOAP RPC call: invoke
at
at
at
....
....
Caused by: [SOAPException: faultCode=SOAP-ENV:Protocol;
msg=Unsupported response content type "text/html", must be:
"text/xml". Response was:
<HTML><TITLE>408 - Request
Timeout</TITLE><BODY><h1>408 Connection timed out while
reading request</h1></BODY></HTML>
]
at org.apache.soap.rpc.Call.getEnvelopeString(Call.java:241)
at org.apache.soap.rpc.Call.WASinvoke(Call.java:458)
at
com.ibm.ws.management.connector.soap.SOAPConnectorClient$8.run(SOA
PConnectorClient.java:831)
To resolve the above error do the following -A) Go to the DMGR/WAS administration console -- Application servers >
WebSphere_Portal > Administration services > JMX connectors >
SOAPConnector > Custom properties
Select the requestTimeout property, and increase the value from 600 to
6000 and Save configuration changes.
B) Go to the DMGR/WAS administration console -- Application servers >
WebSphere_Portal > Transaction service
Increase the value for Total transaction lifetime timeout from 120 to 6000
Increase the value for Maximum transaction timeout from 900 to 36000
Save configuration changes.
C) Restart the portal server
7. One may get the following error during upgrade-profile task especially when
using oracle as the database.
From failure.log :
/opt/IBM/WebSphere/APP/WP7/PortalServer/jcr/wp.content.repository.instal
l/config/includes/jcr.mig_cfg.xml:20: The following error occurred while
executing this line:
/opt/IBM/WebSphere/APP/WP7/PortalServer/jcr/wp.content.repository.instal
l/config/includes/jcr.mig_cfg.xml:343: The JCR migrator utility failed
to run successfully.
at
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHe
lper.java:539)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:384)
from migration.log :
2011-11-10 10:25:58 Migration: TRACE -> Connecting to Database
...............
2011-11-10 10:25:58 Migration: TRACE -> DBUSER :: APP_JCR
2011-11-10 10:25:58 Migration: TRACE -> DBDRIVER ::
oracle.jdbc.OracleDriver
2011-11-10 10:25:58 Migration: TRACE -> DBURL ::
jdbc:oracle:thin:@xxx:1937:aaa
2011-11-10 10:25:58 Migration: TRACE -> loading jdbc driver :
oracle.jdbc.OracleDriver
2011-11-10 10:25:58 Migration: TRACE -> Connecting to ....
2011-11-10 10:25:58 Migration: TRACE -> Connected to !
2011-11-10 10:25:58 Migration: ERROR ->Failed to migrate workspace to
support full link relation!!!
2011-11-10 10:25:58 Migration: ERROR
->oracle.jdbc.driver.OracleStatementWrapper.isClosed()Z
2011-11-10 10:25:58 Migration: ERROR
->oracle.jdbc.driver.OracleStatementWrapper.isClosed()Z
java.lang.AbstractMethodError:
oracle.jdbc.driver.OracleStatementWrapper.isClosed()Z
One should confirm that the userid/pwd values are correct in wkplc.properties
and icm.properties file.
In the above error, it seems like one is using the wrong oracle dbdriver and
dblibrary
One needs to use oracle.jdbc.driver.OracleDriver instead of
oracle.jdbc.OracleDriver as well as one should be using ojdbc6.jar
instead of using ojdbc5.jar based on --
http://www10.lotus.com/ldd/portalwiki.nsf/dx/Database_properties_for_the_Solution_Inst
aller_wp8
In order to check if one is using the correct dbdriver and dblibrary take a look
at <wp_profile>\ConfigEngine\properties\wkplc_dbtype.properties file
Once making the appropriate changes, ran the following task -ConfigEngine.bat validate-database-connection
ConfigEngine.bat connect-database
Once done, re-ran the upgrade-profile task.
8. One may get the following error related with SSLHandshake issue during
the SOAP connection while executing upgrade-profile task.
One may see the following error in the systemout.log file -0000003e NotificationU W
com.ibm.wps.pe.mgr.appserveradmin.notify.NotificationUtils
uregisterApplicationNotificationListener EJPPH0024E: Notification error
from application PA_Policy_Status.
com.ibm.websphere.management.exception.ConnectorException:
ADMC0009E:
The system failed to make the SOAP RPC call: removeNotificationListener
at
at
..........
...........
Caused by: [SOAPException: faultCode=SOAP-ENV:Client; msg=Error
opening
socket: javax.net.ssl.SSLException: Received close_notify during
handshake; targetException=java.lang.IllegalArgumentException: Error
opening socket: javax.net.ssl.SSLException: Received close_notify during
handshake]
at
org.apache.soap.transport.http.SOAPHTTPConnection.send(SOAPHTTPCon
nection.java:475)
at org.apache.soap.rpc.Call.WASinvoke(Call.java:451)
at
com.ibm.ws.management.connector.soap.SOAPConnectorClient$8.run(SOA
PConnectorClient.java:831)
at
com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.
java:118)
at
... 67 more
One would get this error when one does not have enough RAM on the
machine. It is similar to the issue mentioned in this technote - https://www304.ibm.com/support/docview.wss?uid=swg21292821
9. upgrade-profile task fails with the following error :
from configtrace.log :
[echo] Deploying consolidated web-app update script
[xmlaccess] EJPXB0006I: Connecting to URL
http://localhost:10040/wps/config/
[xmlaccess] EJPXB0004I: Writing output file
/opt/WebSphere7/AppServer/profiles/wp_profile/ConfigEngine/log/consolida
tedXMLAccessResult.xml
[xmlaccess] EJPXB0002I: Reading input file
/opt/WebSphere7/AppServer/profiles/wp_profile/ConfigEngine/config/work/c
onsolidatedXMLAccess.xml
[xmlaccess] EJPXB0019E: Server response indicates an error. For status
and details of the XmlAccess error look at file
tedXMLAccessResult.xml.
tedXMLAccessResult.xml.
from consolidatedXMLAccessResult.xml file :
<status element="[web-app com.ibm.wps.portlets.portletmanager
uid=com.ibm.wps.portlets.portletmanager]" result="failed">
<message
id="EJPXA0043E">com.ibm.wps.command.xml.XmlCommandException:
EJPXA0043E:
An error occurred while creating or updating the resource. [web-app
com.ibm.wps.portlets.portletmanager
uid=com.ibm.wps.portlets.portletmanager]</message>
<message
id="EJPPD0015E">com.ibm.wps.command.CommandFailedException:
EJPPD0015E:
Portlet application manager failed when user xmlaccess scripting user

executed command UpdateWebApplication.
WrappedException is:
com.ibm.wps.pe.mgr.exceptions.AppServerWarUpdateException:
EJPPH0044E:
Redeployment of Web Module id in WAR file
/opt/WebSphere7/AppServer/profiles/wp_profile/PortalServer/deployed/Port
letManager.war (application display name: PA_Portlet_Manager) didi not
complete successfully when invoking the WebSphere Application Server
administration interface.</message>
<message
id="EJPPH0044E">com.ibm.wps.pe.mgr.exceptions.AppServerWarUpdateEx
ceptio
n: EJPPH0044E: Redeployment of Web Module id in WAR file
/opt/WebSphere7/AppServer/profiles/wp_profile/PortalServer/deployed/Port
letManager.war (application display name: PA_Portlet_Manager) did not
complete successfully when invoking the WebSphere Application Server
administration interface.</message>
<message>com.ibm.websphere.management.exception.AdminException:
</message>
</status>
To resolve this issue increase the was.notification.timeout to 1200 or higher
(seconds) in WP DeploymentService via the DMGR/WAS Administration
Console.
If the property is not listed under custom properties (which may be
the default), please add it and set the value to 1200 (in order to change the
default value of 60 seconds).
Re-run migration task to continue.
10. One may get the following error during upgrade-profile task especially
when using db2 as the database with SQLCODE=-443
From the configtrace.log -action-update-icm-properties-db2:
[echo] Updating 'icm.properties' for db2
Target finished: action-update-icm-properties-db2
Target finished: action-update-icm-properties
[echo] Migrating JCR schema from JCR6.1.0.3 to JCR8.0.0.0 ...
[echo]
traceDDL=false,ddlscript.name=E:/IBM/WebSphere/AppServer/Profiles/wp_pr
o
file/PortalServer/DBMigrationScripts/db2/jcr/db2_jcr_dbmig_jcr.sql
[java] Executing java with empty input string

[java] Please refer to log
File::E:/IBM/WebSphere/AppServer/Profiles/wp_profile/ConfigEngine\log\Mi
gration.log
[java] Java Result: 1
From the migration.log --Migration: TRACE -> DBURL ::
jdbc:db2://localhost:50000/JCRDB:returnAlias=0;
Migration: TRACE -> loading jdbc driver :
com.ibm.db2.jcc.DB2Driver
Migration: TRACE -> Connecting to ....
Migration: TRACE -> Connected to !
.........
........
MigrateToSeedlist.checkTableExistence(): TRACE ->
Error querying table metadata:DB2 SQL Error: SQLCODE=-443,
SQLSTATE=38553,
SQLERRMC=SYSIBM.SQLTABLES;TABLES;SYSIBM:CLI:-805,
DRIVER=3.63.75
Plugin :: com.ibm.cm.jcr.migrator.MigrateToSeedlist:
ERROR ->null
Migration: DEBUG -> null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
r
Impl.java:37)
.........
.........
Caused by: com.ibm.db2.jcc.am.SqlException: DB2 SQL Error: SQLCODE=443, SQLSTATE=38553,
SQLERRMC=SYSIBM.SQLTABLES;TABLES;SYSIBM:CLI:-805,
DRIVER=3.63.75
at com.ibm.db2.jcc.am.fd.a(fd.java:682)
at com.ibm.db2.jcc.am.fd.a(fd.java:60)
To resolve this issue one should follow the technote -https://www-304.ibm.com/support/docview.wss?uid=swg21396915 -- atleast
for the JCR db
Re-run the migration task after one have executed steps in above
technote.
11. One may get the following error during upgrade-profile task especially
when using db2 as the database with SQLCODE=-552
From the migration.log :
Migration: TRACE -> Executing :: CREATE USER
TEMPORARY TABLESPACE ICMLSUSRTSPACE4 PAGESIZE 4K
MANAGED BY SYSTEM USING
('icmlsusrtspace4') BUFFERPOOL ICMLSVOLATILEBP4
Migration: TRACE -> SQL Execution Failed ???
MigrationSQLExecutor: ERROR ->DB2 SQL Error:
SQLCODE=-552, SQLSTATE=42502, SQLERRMC=DB2ADMIN1;CREATE
TABLESPACE,
DRIVER=3.63.75
Migration: TRACE -> Starting rolling back
transaction
SQLCODE=-552 means the user which is attempting to
execute the above query doesn't have required access -- based on
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%
2Fcom.ibm.db2z9.doc.codes%2Fsrc%2Ftpc%2Fn552.htm
It is similar to the issue mentioned in the technote -https://www-304.ibm.com/support/docview.wss?uid=swg21268735 which
says "The dbuser does not have the required SYSADM rights to create the
tablespace (SQLCODE: -552, SQLSTATE 42502) "
Hence two options to resolve the issue :
A) Connect to the db directly ( db2://localhost:50000/JCRDB ) using the
userid/pwd that one have configured and try to execute the following task
from db2 command line :
CREATE USER TEMPORARY TABLESPACE ICMLSUSRTSPACE4
PAGESIZE 4K MANAGED BY
SYSTEM USING ('icmlsusrtspace4') BUFFERPOOL ICMLSVOLATILEBP4
If successful one can try to re-run the migration task.
OR
B) one can give the dbuser full admin rights and re-run the task.
12. While running upgrade-profile task and it may fails :

action-modify-HTTP-Inbound-Channel-timeout:
Target finished: action-modify-HTTP-Inbound-Channel-timeout
[xmlaccess] EJPXB0006I: Connecting to URL
http://xxxx:10040/wps/config/
[xmlaccess] EJPXB0004I: Writing output file
/data/dev/candidate/WebSphere/AppServer/profiles/wp_mig_profile/ConfigEn
gine/config/work/deployedWebAppXmlAccess-PTF/preExistingWebApps.xml
[xmlaccess] EJPXB0002I: Reading input file
/data/dev/candidate/WebSphere/PortalServer/installer/wp.migration.core/m
igration/components/wp.migration.core/exportWebApps.xml
gine/config/work/deployedWebAppXmlAccess-PTF/preExistingWebApps.xml.
gine/config/work/deployedWebAppXmlAccess-PTF/preExistingWebApps.xml.
Looking further, the root exception is the error:
======================
[7/22/12 21:03:05:771 CDT] 00000011 EJBMDOrchestr E CNTR0075E: The
user-provided class
"com.ibm.wps.datastore.ejb.cleanup.EJSRemoteStatelessSchedulerManager
_03598d10" needed by the EnterpriseBean could not be found or loaded.
======================
This class is supposed to be part of the wp.ejb.scheduler.jar file
within the wps_scheduler application.
During migration it reinstalled wps_scheduler application.
======================
[wsadmin] ADMA0245W: EJBDeploy feature is not installed. Cannot
execute "deploy enterprise beans" option.
[wsadmin] ADMA5016I: Installation of wps_scheduler started.
[wsadmin] ADMA5058I: Application and module versions are validated
with versions of deployment targets.
[wsadmin] ADMA5005I: The application wps_scheduler is configured in
the WebSphere Application Server repository.
======================
The WAS v8 installation does NOT have EJBDeploy feature enabled. This is
a required feature for Portal v8 and is preventing upgrade-profile from
successfully setting up the wps_scheduler application.
One should be able to add this without reinstalling WAS/Portal by taking the
following steps:
1. Stop the Portal server
2. Launch Installation Manager and go to Modify
3. Select the WAS v8.0.0.3 package
4. Expand the WAS feature list and select "EJBDeploy tool for pre-EJB 3.0
Modules"
5. Click Next.
6. IMPORTANT. On the Summary screen, make sure that NO features are
being REMOVED. We should only be adding EJBDeploy.
7. Once ejbdeploy has been added, redo the upgrade-profile script.
Make sure this starts from the beginning because we need it to redo the
wps_scheduler installation.
13. While running upgrade-profile task and it may fail with the following :
From ConfigTrace.log:
import-nodetypes:
[echo] importing nodeTypes using
/data/dev/candidate/WebSphere/PortalServer/bin/../wcm/prereq.wcm/config/
nodetypes/ibmcontentwcm_v3tov4.nodetypes file
--- Exception Thrown --/data/dev/candidate/WebSphere/PortalServer/jcr/wp.content.repository.ins
tall/config/includes/jcr.install_cfg.xml:868: Import node types task
failed
at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:139)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
.........
.........
Caused by:
/data/dev/candidate/WebSphere/PortalServer/jcr/wp.content.repository.ins
tall/config/includes/jcr.install_cfg.xml:693: The following error
occurred while executing this line:
tall/config/includes/jcr.install_cfg.xml:868: Import node types task failed
at
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHe
lper.java:539)
at
org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:107)
at
.........
.........
Caused by:
tall/config/includes/jcr.install_cfg.xml:868: Import node types task failed
at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:139)
at
Looking further in Systemout.log file :
ERROR:
[7/24/12 15:57:15:096 CDT] 00000008 TimeoutManage I WTRN0006W:
Transaction
00000138BAC5B396000000026807A180E6E09168ED9CA8A5315BC4B051
E9668DFD945B33
00000138BAC5B396000000026807A180E6E09168ED9CA8A5315BC4B051
E9668DFD945B330000000100000008 TimeoutManage I WTRN0124I:
When the timeout occurred the thread with which the transaction is, or was
most recently, associated was Thread[WebContainer : 0,5,main]. The stack
trace of this thread when the timeout occurred was:
org.apache.derby.impl.sql.execute.NoPutResultSetImpl.setCurrentRow(Unkn
own Source)
org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextR
ow Core(Unknown Source)
To resolve this increase the global transaction lifetime timeout and transaction
timeout.
Go to the DMGR/WAS administration console -- Application servers >
WebSphere_Portal > Transaction service
Increase the value for Total transaction lifetime timeout from 120 to 6000
Increase the value for Maximum transaction timeout from 900 to 36000
Save configuration changes.
Re-run upgrade-profile task.
14. One is doing portal migration from Portal 6.1.0.5 to 8 on Linux Redhat OS
and both servers are using derby as db. One is doing remote migration on the
standalone server.
While executing upgrade-profile task it fails with following :
run-wcm-admin-task:
[echo] VirtualPortalContext = , VirtualPortalHost =
[echo] Initialized: host abc.efg.com vpContext
[echo] To call ConfigModuleClient: host abc.efg.com
vpContext [ConfigModuleClient] Connecting to login address:
http://host abc.efg.com:10040/wps_migrated/wcm/login
[ConfigModuleClient] Connecting to task address:
http://host abc.efg.com:10040/wps_migrated/wcm/myconnect?
MOD=RefreshAllItems&allLibraries=true&scheduleOnly=true&loadResources
=false with user name: CN=xyz
[ConfigModuleClient] No output will be shown while this task is
running. Check the SystemOut.log for progress information.
--- Exception Thrown --/data/dev/candidate/WebSphere/PortalServer/wcm/prereq.wcm/config/include
s/prereq.wcm_cfg.xml:3643: An exception occurred while executing the
task: null
at
com.ibm.workplace.wcm.maintenance.module.ConfigModuleClient.execute(C
onfigModuleClient.java:103)
........
........
Caused by: java.lang.NullPointerException
at
com.ibm.workplace.wcm.maintenance.module.ConfigModuleClient.runModule
(ConfigModuleClient.java:184)
at
com.ibm.workplace.wcm.maintenance.module.ConfigModuleClient.runPlutoM
odule(ConfigModuleClient.java:116)
In the systemout.log :
[7/25/12 16:01:04:263 CDT] 000000d6 filter E
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper service SRVE8109W:
Uncaught exception thrown by filter Extensible Filter:
java.io.FileNotFoundException: SRVE0190E: File not found: /wcm/login
at
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor._processED
R(
DefaultExtensionProcessor.java:893)
at
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.processEDR
(DefaultExtensionProcessor.java:874)
at
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequ
est(DefaultExtensionProcessor.java:434)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilt
erChain.java:125)
.........
..........
[7/25/12 16:01:04:274 CDT] 000000d6 FfdcProvider W
com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident
emitted on
/logs/dev/candidate/ffdc/WebSphere_Portal_1b22f8f1_12.07.25_16.01.04.266
5715963793481933105.txt
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter 149
emitted on
3587448887358887405.txt
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter 82
emitted on
7236863168190859820.txt
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest() 309
The 'run-wcm-admin-task-schedule-actions' task is being executed, which
in turns attempts to run the RefreshAllItems module via the servlet:
http://abc.efg.com:10040/wps_migrated/wcm/myconnect?
MOD=RefreshAllItems&allLibraries=true&scheduleOnly=true&loadResources
=false
Servlet exception is then thrown (12.07.25 16.01.04):
javax.servlet.ServletException: java.io.FileNotFoundException:
SRVE0190E: File not found: /wcm/login
So it looks like the servlet is not available/ready at all on the server.
Additionally, many instances of the following were also seen:
TCPC0003E: TCP Channel TCP_3 initialization failed. The socket bind
failed for host * and port 10041. The port may already be in use. For
instance,
[7/25/12 15:57:08:557 CDT] 00000000 JMXConnectors I ADMC0058I: The
JMX JSR160RMI connector is available at port 10031
[7/25/12 15:57:13:011 CDT] 00000027 TCPPort
E TCPC0003E: TCP
Channel TCP_3 initialization failed. The socket bind failed for host * and port
10041. The port may already be in use.

[7/25/12 15:57:13:014 CDT] 00000027 TCPPort
E TCPC0003E: TCP
[7/25/12 15:57:13:962 CDT] 00000000 WsServerImpl A WSVR0001I:
Server WebSphere_Portal open for e-business
[7/25/12 15:57:18:016 CDT] 00000057 TCPPort
E TCPC0003E: TCP
[7/25/12 15:57:18:018 CDT] 00000057 TCPPort
E TCPC0003E: TCP
[7/25/12 15:57:18:921 CDT] 000000c5 authz
I CWWIM2000I
Initialization of the authorization component completed successfully.
[7/25/12 15:57:23:020 CDT] 00000009 TCPPort
E TCPC0003E: TCP
[7/25/12 15:57:23:464 CDT] 00000027 TCPPort
E TCPC0003E: TCP
[7/25/12 15:57:28:030 CDT] 00000027 TCPPort
E TCPC0003E: TCP
[7/25/12 15:57:28:470 CDT] 00000079 TCPPort
E TCPC0003E: TCP
[7/25/12 15:57:33:034 CDT] 00000079 TCPPort
E TCPC0003E: TCP
[7/25/12 15:57:33:486 CDT] 00000057 TCPPort
E TCPC0003E: TCP
[7/25/12 15:57:38:043 CDT] 00000057 TCPPort
E TCPC0003E: TCP
This is a linux specific issue in which the following may be of use:
http://www-01.ibm.com/support/docview.wss?uid=swg21239026
Once the port issue is resolved and the errors are no longer being seeing
during the Portal startup, then please re-run the upgrade-profile task
again.
15. One may experience dead lock issue during the execution of the
upgrade-profile task.
From ConfigTrace.log :
Target started: wcm-run-ejb-task

wcm-run-ejb-task:
[echo]
[echo]
Script Values
[echo]
orb host:
61xTo8xMigration
[echo]
orb port:
10034
[echo]
task:
update-wcm-preset-folders
[echo]
arguments:
[echo]
..........
...........
[java] Jul 25, 2012 6:22:35 PM null null
[java] INFO: Client code attempting to load security configuration
[java] objref:
com.ibm.workplace.wcm.app.migration.ejb._MigrationServiceHome_Stub
[java] 23 preset folders in the library Web Content were updated with
classification.Total time to process the item: 112344 ms.
[java] 23 preset folders in the library Blog Solo Template were updated
with classification.Total time to process the item: 22677 ms.
[java] Failed to process item. Error message: Failed to update preset
folders with the folders classification. Library wiki resources. Error message:
RT0002E: Error while calling a function updateItems of PLS data manager.
[java] Failed to process item. Error message: Failed to update preset
folders with the folders classification. Library blog template. Error message:
WSP2021E: Instance of workspace ROOTWORKSPACE has been marked
invalid and should be discarded..
[java] 23 preset folders in the library Wiki Template were updated with
[java] 23 preset folders in the library Blog Resources were updated with
[java] total task(s): 6
[java] total error(s): 2
[java] Total time to process all items: 227647 ms.
[java] removing the stateful bean.
[java] java.lang.Exception: Failed to process 2 item(s). See SystemOut.log
file for more details.
[java]
at
com.ibm.workplace.wcm.app.migration.ejb.MigrationBeanClient.runTask(Migr
ationBeanClient.java:161)
[java]
at
com.ibm.workplace.wcm.app.migration.ejb.MigrationBeanClient.main(Migratio
nBeanClient.java:204)
--- Exception Thrown --/
zippy/portal/WebSphere/PortalServer/wcm/prereq.wcm/config/includes/prereq
.wcm_cfg.xml:3774: Java returned: 1
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:87)
at
com.ibm.wps.config.tasks.JavaEmptyInputStringTask.execute(JavaEmptyInp
utStringTask.java:16)
..........
...........
Caused by:
/zippy/portal/WebSphere/PortalServer/wcm/prereq.wcm/config/includes/mig_c
fg.xml:708: The following error occurred while executing this line:
/
zippy/portal/WebSphere/PortalServer/wcm/prereq.wcm/config/includes/prereq
.wcm_cfg.xml:3774: Java returned: 1
at
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelp
er.java:539)
..........
...........
Caused by:
/zippy/portal/WebSphere/PortalServer/wcm/prereq.wcm/config/includes/prere
q.wcm_cfg.xml:3774: Java returned: 1
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:87)
at
com.ibm.wps.config.tasks.JavaEmptyInputStringTask.execute(JavaEmptyInp
utStringTask.java:16)
at
DB2 is sufferring from Lock Escalation which is going to produce Deadlock
when JCR write operations are done under load. Here is a sample from the
db2diag.log:
2011-12-02-21.15.47.313005+660 E32523247E993
LEVEL: Warning
PID : 8552
TID : 140737064724224PROC : db2sysc
INSTANCE: db2inst1
NODE : 000
DB : WP80
APPHDL : 0-58494
APPID: 9.185.229.82.42617.111201220237
AUTHID : DB2INST1
EDUID : 6186
EDUNAME: db2agent (WP80)
FUNCTION: DB2 UDB, data management, sqldEscalateLocks, probe:1
MESSAGE : ADM5501I DB2 is performing lock escalation. The affected
application
is named "db2jcc_application", and is associated with the workload
name "SYSDEFAULTUSERWORKLOAD" and application ID
"9.185.229.82.42617.111201220237" at member "0". The total number of
locks currently held is "15145", and the target number of locks to
hold is "7572". The current statement being executed is "DELETE FROM
JCR.ICMUTMWIDE0 WHERE EXISTS ( SELECT 1 FROM
SESSION.ICMTTJCRREMOVEHLP WHERE WSID = XWSID AND XIID = IID
)".
To avoid this, you must adjust your db2 configuration accordingly:

db2 update db cfg using locklist 5000
db2 update db cfg using maxlocks 75
16. If you have DMGR + primary node on the same machine, upgrade-profile
may fail with the following :
wsadmin>Portal.login('myusername', 'mypassword')
WASX7015E: Exception running command: "Portal.login('abcd', 'xyz')";
exception information:
com.ibm.bsf.BSFException: exception from Jython: Traceback (innermost
last): File "<input>", line 1, in ?
java.lang.reflect.UndeclaredThrowableException
at com.ibm.wps.scripting.script.PortalBean.login(PortalBean.
java:224)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
Caused by: java.lang.ClassNotFoundException: com.ibm.ffdc.config.
Formattable
at org.eclipse.osgi.internal.loader.BundleLoader.
findClassInternal(BundleLoader.java:506)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass
(BundleLoader.java:422)
To resolve this do the following :
a) Remove the file wp.base.jar from AppServer/libs
b) Run /AppServer/bin/osgiCfgInit.sh -all
c) Re-run upgrade-profile task
17. Portal migration task may hang if you pass ampersand (&) at the end of
the command. Hence to avoid any kind of wired situation do not pass
ampersand at the end of the command.
Appendix B Portal v8 Tuning Guide

Please check out the tuning guide at
http://www10.lotus.com/ldd/portalwiki.nsf/dx/IBM_WebSphere_Portal_V_8.0_Perfor
mance_Tuning_Guide

W PV 61 To 8 Migration Guide

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

W PV 61 To 8 Migration Guide

Încărcat de

Drepturi de autor:

Formate disponibile

Migration Step by Step Guide:

WebSphere Portal v6.1.0.5 to

Author: Dhaval Patel

Migration is supported between equivalent offerings. For example, you can

The table below summarizes all supported migration paths:

WebSphere Portal Supported

WebSphere Portal Not Supported

WebSphere Portal Not Supported

WebSphere Portal Supported

WebSphere Portal Not Supported

WebSphere Portal 6.1.0.5

Install any recommended cumulative fixes and interim fixes on the

Do the database transfer. I transfered from derby to DB2. Ensure

Installed the required fixes for migration mentioned in WebSphere

Changes to the scheduled cleanup service settings are not

To ensure that the wkplc_comp.properties file contains the

Gather current statistics on all tables found in the JCR domain. We

db2 connect to <jcrdb>

db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table

In WebSphere Portal Version 6.1.x, some custom JVM properties

Log in to the WebSphere Integrated Solutions Console.

Go to Server -> Application servers -> select the appropriate

You need to disable JCR text search indexing. After migration is

2. Modify the values as follows :

If you have a large amount of content in the JCR repository (for

See the section of Access Control in WebSphere Portal 6.1

Clean up your previous environment as follows:

WebSphere Portal 6.1 information center

If you deleted users or groups using your configured user

Back up the databases and the entire directory structure for

If you plan to migrate IBM Lotus Web Content Management data,

the WebSphere Portal product documentation.

a. Follow the IBM Installation Manager instructions through the

c. Proceed with the remaining instructions to complete the binary

This option significantly reduces installation time and helps to avoid

There are additional considerations to keep in mind around the user

If any virtual portals that exist in your earlier WebSphere Portal

If the earlier WebSphere Portal environment is configured to use an

If the portal 8 server is on AIX, Linux, Solaris, or i, increase the file

Back up the databases and the entire directory structure for

doing this as their regular maintenance strategy.

Some of the WAR files in the portal_server_root/installableApps directory might

2.2 Installation of Fixes

2.2.2 Installing fixes on WebSphere Portal 8 environment

Search Components from Portal 6.1.0.5

Migrating the search components in your portal might require preparation

If you used WebSphere Application Server Migration Wizard then it will

execute WasPreUpgrade.bat(sh) task

execute WasPostUpgrade.bat(sh) task

Step 1 : Prepare files for Remote Migration

Back up the databases and entire directory structure for your

Navigate to <PortalServer_root>\bin directory of your WebSphere

Extract the jar file to a temp location

Step 2 : Execute WASPreUpgrade command

not generate a trace file.

This task will create the WASPreUpgrade.<timestamp>.log file under logs of

Step 3 : Create a wp_profile for Portal 8

Back up the databases and entire directory structure for your

Administrative console secure port: 9043

Step 4 : Execute WASPostUpgrade command for Portal 8

example, specify wpsadmin rather than uid=wpsadmin,

Step 5 : Execute the ConfigEngine tool on Portal 8

connection types are SOAP and NONE.