- Install Portal 18.104.22.168
- Enable your security to the same backend LDAP of which your previous server is authenticating. If it's a different LDAP, make sure that the LDAP branches (usersand groups) are the same as your previous LDAP.
- Install your target database server.
- Do the database transfer.
- Install the following fixes on your 5.1 environment : PK27753 PK28148 PK29999 PK30718 PK31425 PK32194 PK32211 PK32556 PK32626 PK34624 PK39530 PK42729 PK44723 PK47799 PK48653 PK53001 PK62044 PK63553 PK64160 PK40171
- If there's any RSS Portlet for 5.1, update it with the latest version.
- If portal 5.1 has deleted pages, ensure that you use the deleted cleanup service. Check the information center.
- If you have deleted users or groups, Deregister the users and group. Follow the procedures in Websphere Portal 5.1information center.
- stop and start your portal 5.1 to test.
- Considering that you have installed an HTTP Server, kindly change back the WpsHostPort to port 9081 instead of 80.
- Edit the file soap.clients.props and change the settings of com.ibm.SOAP.requestTimeout to a higher number than 180. (Suggests is to increase to 1800).
- Run WPmigrate with the portal-pre-upgrade task on Websphere Portal 5.1 from the CD_root/migration/portal_migration directory on the WebSphere Application Server Network Deployment Version 6.1 Supplements CD. This CD comes with WebSphere Portal and can be used on either Windows or UNIX. Run by executing below :
WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword -DGroupExport="true"
backupDirectory - The directory where data from the earlier server will be stored for subsequent use with the portal-post-upgrade task. If this directory does not exist, the portal-pre-upgrade task creates it. For example, if you specify mybackup, the migration task stores the data under the mybackup directory.
currentPortalDirectory - The directory where the earlier portal server is installed.
currentPortalAdminId - The administrator ID for the earlier portal server. This value is not required if it is already specified in the wpconfig.properties file on the earlier portal server.
currentPortalAdminPwd - The administrator password for the earlier portal server.
DbPassword - The DBMS user password for the earlier portal server. Specify this property value in the command line only if the property is not already specified as follows :
In WebSphere Portal V5.1.0, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, or 220.127.116.11, the property value is specified in the wpconfig.properties file, next to the property name DbPassword.
In WebSphere Portal V18.104.22.168 or later, the property value is specified in the wpconfig_dbdomain.properties file, next to the property name release.DbPassword.
All other database properties must be specified in the properties file.
GroupExport - This is optional. On my part, since it's integrated with LDAP, I didn't need to export the group. No errors occurred. This exports groups from the earlier version when the value is set to true. This property is set by default to false.
- Once run, check the allout.xml file to see the results.
Sunday, June 14, 2009
Saturday, June 6, 2009
Apparently, most of the U.C. solutions in the market now are half-baked, and is geered towards telecommunications and I.M. only. Given that, I have yet to see a solution which integrates I.M. communication with an email communication, other than the S.S.O, which actually just gives us presence awareness and nothing else. Some vendors are even guilty of calling their produce U.C. when in-fact, it only offers chat and Telephony and given that, there's not even a single integration between the two functionality. Some are guilty of providing everything that a communication platform can offer yet there's no single integration between them.
Anyway, here's the video of what Google Wave can offer and tell me if this is not truly a unified communications model. I, for one, particularly wanted to see how this will integrate with audio and video.
Configuring a new folder as a common shared library to deploy your shared libraries instead of using PortalServer/Shared or PortalServer/config
Article from : Websphere Portal Wiki by yours truly.
If you are a developer on a company who has a strong development process in-place, you are normally asked to deploy the shared jar files on the PortalServer/shared or PortalServer/config directory. You may have wondered, if you can actually deploy your jar files and property files in a separate folder(s) instead of those above given directory. The answer is YES. Though, this is not documented anywhere I believe.
While on the course of the portal migration project, I encountered all custom portlets to have 3 shared libraries configured on each of them. The funny thing is that all of the shared libraries configured are the same for all of the portlets. This is actually a headache for me during migration as there are more than 100 portlets deployed and I don't expect myself to configure them one by one. So, what I did was to configure 3 new shared libraries BUT configure my Portal Server to see this Shared Libraries, rather than deploying my libraries under PortalServer/shared or PortalServer/Config. I didn't deploy the shared library on the PortalServer/shared or PortalServer/config folder as what IBM manuals normally says.
But instead, this JAR files are stored on a different directory, but whenever Portal loads, it knows that this jar files are to be loaded as shared library that is to be shared by all portlets. How ? Follow the below instructions. Note that this instruction is for WAS 6.1, but the same can be found on 5.1 and 6.0 though in a different way of doing it.
- Logon to the Websphere Application Server console.
- Go to Environment -> Shared Libraries
- Create your own Shared Library. Add the classpath pointing to your JAR files.
- Apply and save this configuration.
- Now, this is the fun part. Go to Servers -> Application Servers -> Websphere_Portal -> Java and Process Management -> ClassLoader.
- Class loader may vary but it should only contain one link. Click on that class loader.
- Click on the Shared Library References
- You will notice all the shared libraries that are used by Websphere Portal. Click on Add.
- Add your shared library.
- Save and restart Websphere Portal.
So I encountered this scenario where the SSL was replaced but the site is still serving the old SSL on a site hosted on IIS 8. You keep che...
Most J2EE Applications and for that matter, any applications uses Property File to provide the properties and attributes to it's app. Wh...