I was asked by a customer how to uninstall Process Server, while keeping your Portal Server intact. I couldn’t find any documentation or steps to do this, so I figured it out for them.
“Your mileage may vary” – give this a try on a test box first, before you try on a production box. I didn’t test clusters either, although I don’t see how they would present a problem.

These steps are valid for 6.0 .

Unfortunately, the Process Server uninstaller doesn’t do a great job of cleaning up after itself, so we need to go around after it and clean up the mess.

1. Why not confirm you have Process Server installed first? Try:

If you get back something with this in it:

Bingo! You have Process server.

2. Run the config task bpe-unconfig . This config task will uninstall Process Server related components from your Portal Server (like the Task Container Enterprise Apps) .

3.

Stop all AppServer processes and then run the Process server uninstaller, which you will find at :

Take care to make sure this box below is unticked, so your whole AppServer isn’t uninstalled.

4. After the uninstaller is completed, delete the following jars in AppServer/lib . They are Process Server jars, and the Portal Server (or server1) will not start until you do this. As you can see there are tons of them. I got the list from seeing what was on the Process Server install iso. This list worked for me in my testing (which consisted of starting Portal and the Admin Console and making sure the UI still worked), but I can’t vouch for any custom code that you are running. As always, try this out in a test environment first, and take a backup before messing around with AppServer/lib . This seems to be a superset of what was installed on my system too – so don’t be alarmed if some of the jars in this list are not present on your system.

If you don’t delete these jars, you will get the following error message after issuing startServer.sh :

5. It’s also a good idea to clean out wp_profile/logs/* as there is a cache of jar file paths and their associated classes (the preload cache) that will need to be regenerated after deleting those jars.

6. The only thing the bpe-unconfig task doesn’t seem to do is delete the BPE shared library. To do this, start server1, and log in to the admin console. Navigate to Environment -> Shared Libraries and highlight the BPE library and click delete.

7. You’re done, start Portal and test everything works!

I also wrote a little script that does some checks and then does all this for you (except for step 6 which I couldn’t be inspired enough to write a jacl script for). It’s fairly quick and dirty, but if nothing else it will give you an idea of what has to happen to remove Process Server. You can get it here. Just rename the suffix after you download it. Understandably, WordPress would not yet me save a shell script up to my server.

But my Was Password was correct. I had set it myself and just used it to log into the admin console.

The key is the “MethodDelegat” part of the log message. This column is the source of the log message. “Delegate method” made me think of bundled applications that use the RunAsRole . The pznscheduler application runs on a schedule, and sure enough also has a RunAsRole associated with it.

So what has happened, is that the WAS password has changed but the password is also saved with the pznscheduler application, and that saved password hasn’t been changed. Quite simply, there is a mismatch. This can happen on 6.1 and 7.0, and may also be related to the Portal Admin Password – it just depends which user is mapped as the RunAsRole . There are more applications that use the RunAsRole for Portal 6.0 .

For 6.0 here are the default out of the box applications you need to worry about when changing the password. LWP_TAI, pznscheduler, LWP_CAI, LWP_Security_Ext.

Of course, you may have other custom applications you need to worry about. The LWP apps use the Portal Admin user by default, so that’s why I didn’t have to change them.

For 6.1 you should check pznscheduler and CatalogHandler and for 7.0 the pznscheduler application is the only one you need to worry about.

So to fix it up, if you log into the WAS Admin Console and look for the pznscheduler app in the list of Enterprise Applications, you will see the “Map RunAs roles to users” link like in the picture below.

Then in the next dialog, reenter the new password.

This dialog can be a bit funny so you may have to play around with it a bit. Restart Portal and the error should be gone!

After installing 6.0.1.4-WP-IFPK83731.zip and 6.0.1.4-WP-IFPK70263.zip on a machine here I got this error message, and a 404 when I tried to hit portal. These fixes update the version of WMM to the (current) latest version. Here’s what was in my SystemOut.log

[12/14/09 17:31:09:618 EST] 0000002a SystemOut O WMM Implementation Version: WMM5.6_PK83731 (April 1 2009)
[12/14/09 17:31:09:618 EST] 0000002a WSMM Message E com.ibm.ws.wmm.MemberRepositoryManager init() Initialization failed due to invalid property “supportedMemberTypes”.
[12/14/09 17:31:09:653 EST] 0000002a WSMM Message E com.ibm.ws.wmm.objectimpl.MemberServiceBeanBase ejbCreate() com.ibm.websphere.wmm.exception.InitializationException: Initialization failed due to invalid property “supportedMemberTypes”.
[12/14/09 17:31:09:655 EST] 0000002a ExceptionUtil E CNTR0019E: EJB threw an unexpected (non-declared) exception during invocation of method “getConfigurationData”. Exception data: com.ibm.ejs.container.CreateFailureException: ; nested exception is:
java.lang.reflect.InvocationTargetException
at com.ibm.ejs.container.StatelessBeanO.(StatelessBeanO.java:172)
at com.ibm.ejs.container.CMStatelessBeanO.(CMStatelessBeanO.java:58)
at com.ibm.ejs.container.CMStatelessBeanOFactory.create(CMStatelessBeanOFactory.java:40)
at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome.java:913)
at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome.java:1016)
at com.ibm.ejs.container.activator.UncachedActivationStrategy.atActivate(UncachedActivationStrategy.java:83)
at com.ibm.ejs.container.activator.Activator.activateBean(Activator.java:595)
at com.ibm.ejs.container.EJSContainer.preInvokeActivate(EJSContainer.java:3439)
at com.ibm.ejs.container.EJSContainer.preInvoke(EJSContainer.java:2836)
at com.ibm.ejs.container.EJSContainer.preInvoke(EJSContainer.java:2745)
at com.ibm.websphere.wmm.objects.EJSRemoteStatelessMemberService_14d751a3.getConfigurationData(Unknown Source)
at com.ibm.websphere.wmm.objects._MemberService_Stub.getConfigurationData(_MemberService_Stub.java:2292)
at com.ibm.wps.services.puma.SystemWMMAccessBean$39.run(SystemWMMAccessBean.java:906)
at com.ibm.ws.security.auth.distContextManagerImpl.runAs(distContextManagerImpl.java:2771)
at com.ibm.ws.security.auth.distContextManagerImpl.runAsSystem(distContextManagerImpl.java:2651)
at com.ibm.wps.services.puma.SystemWMMAccessBean.getConfigurationData(SystemWMMAccessBean.java:912)
at com.ibm.wps.services.puma.RealmAwareURManager.initRealms(RealmAwareURManager.java:117)
at com.ibm.wps.services.puma.RealmAwareURManager.(RealmAwareURManager.java:103)
at com.ibm.wps.services.puma.PumaServiceImpl.init(PumaServiceImpl.java:215)
at com.ibm.wps.services.Service.init(Service.java:107)
at com.ibm.wps.services.Service.init(Service.java:83)
at com.ibm.wps.services.ServiceManager.createService(ServiceManager.java:400)
at com.ibm.wps.services.ServiceManager.getService(ServiceManager.java:527)
at com.ibm.wps.services.ServiceManager.getService(ServiceManager.java:553)
at com.ibm.wps.services.puma.Puma.(Puma.java:52)
at com.ibm.wps.ac.impl.AccessControlDataManagementServiceImpl.initializeDomainConfig(AccessControlDataManagementServiceImpl.java:885)
at com.ibm.wps.ac.impl.AccessControlDataManagementServiceImpl.reinit(AccessControlDataManagementServiceImpl.java:792)
at com.ibm.wps.ac.impl.AccessControlDataManagementServiceImpl.init(AccessControlDataManagementServiceImpl.java:439)
at com.ibm.wps.services.ServiceManager.createService(ServiceManager.java:400)
at com.ibm.wps.services.ServiceManager.getService(ServiceManager.java:527)
at com.ibm.wps.ac.impl.AccessControlDataManagement.(AccessControlDataManagement.java:41)
at com.ibm.wps.ac.impl.AccessControlServiceImpl.initializeServices(AccessControlServiceImpl.java:138)
at com.ibm.wps.ac.impl.AccessControlServiceImpl.init(AccessControlServiceImpl.java:114)
at com.ibm.wps.services.ServiceManager.createService(ServiceManager.java:400)
at com.ibm.wps.services.ServiceManager.getService(ServiceManager.java:527)
at com.ibm.wps.ac.internal.AccessControlLookupManager.getAccessControlLookup(AccessControlLookupManager.java:37)
at com.ibm.wps.ac.ACManager.getAccessControl(ACManager.java:132)
at com.ibm.hrl.siapi.search.admin.utils.PortletUtils.getPortalAdminUserID(PortletUtils.java:321)
at com.ibm.hrl.siapi.search.admin.portlets.manage.SearchAdminPortletManager.(SearchAdminPortletManager.java:64)
at com.ibm.hrl.siapi.search.admin.portlets.SiapiSearchAdminPortlet.init(SiapiSearchAdminPortlet.java:532)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:320)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:1821)
at com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper(WebExtensionProcessor.java:141)
at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:885)
at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings(WebApp.java:612)
at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:479)
at com.ibm.ws.webcontainer.webapp.WebGroup.addWebApplication(WebGroup.java:123)
at com.ibm.ws.webcontainer.VirtualHost.addWebApplication(VirtualHost.java:146)
at com.ibm.ws.webcontainer.WebContainer.addWebApp(WebContainer.java:940)
at com.ibm.ws.webcontainer.WebContainer.addWebApplication(WebContainer.java:893)

I’m not sure what was updated in WMM for this one, but the solution is simple: install WAS 6.0.2.37 to fix it.

Now copy this file to your oracle system and run this:

Pow! All done.

It looked like the problem I’d seen on Ubuntu, where the database password was hashed with an unsupported scheme, but it couldn’t be, because this was on a plain old RHEL system. The difference was that I’d recently changed DB2′s database manager settings from AUTHENTICATION = SERVER to AUTHENTICATION = DATA_ENCRYPT . DATA_ENCRYPT is good because it will send your sql data and your authentication details encrypted across the wire.

Anyway, to make the validation work on a system where you have enabled the DATA_ENCRYPT parameter, just add securityMechanism=13; to the end of the database url. So mine becomes:

So how would the system work in any case, if the database url was wrong?!? The answer is clear after delving into the WebSphere admin console a little bit. I’d configured the custom properties of each Portal datasource post database transfer to work with DATA_ENCRYPT, but not the database urls in wkplc_comp.properties. Here’s where you would set it.

It is important to emphasize that the wkplc*.properties file in ConfigEngine are templates only, and don’t affect the running of the system, until you run a ConfigEngine task against them. Only then do their values get copied to the actual Portal server.

When you edit the user’s properties this nasty error can appear if your Portal server is connected to an LDAP.

Error entering mail address into Self Care Portlet

Btw, this is a 6.1 or Portal.Next beta specific error, it should work fine on 6.0.

Here’s the full text of the error:

The reason this happens is that the portlet ( the self care portlet in this case)  is wired up to write the email address you entered in the form to a VMM attribute called ibm-primaryEmail . If your ldap schema doesn’t have a user attribute in it called ibm-primaryEmail , then you’re going to get an error when you try and write something to it.

Just to check it out, let’s look at the LDAP schema on this server (which is IBM Tivoli Directory Server 6.0)  . I’m using the awesome and free Apache Directory Studio to investigate the LDAP schema here.  Once the connection to the ldap is defined, go LDAP -> Open Schema Browser , and select the tab attribute types.

TDS ldap schema

Ok, so we have an attribute type ‘drink, favouriteDrink’ ;o) , but no ibm-primaryEmail . No matter, there is a ‘mail’ attribute there. We can make Portal use that to save email related attributes.

Open up wkplc.properties and find the section entitled LDAP Attribute Configuration (it’s near the bottom) . Here’s my completed one:

Cool, now run the task :

If you are using a federated ldap setup, edit the corresponding federated properties instead, and then run the following task:

. Restart the server and try the form again. It should correctly save the email attribute for the user and you can get on with sending email through Portal. Just for kicks, lets look at what that task did. It just edits the wimconfig file, which defines how VMM interacts . Open wimconfig.xml (wp_profile/config/cells/<cellname>/wim/config/wimconfig.xml) and search for ibm-primaryEmail.

Here is the part that does the mapping:

So the task is really just a (welcome) convenience, all it does it edit the xml file for you. Anyone who has tried to set up multirealms on 6.0 would be grateful for that!

Two posts in one day, wow. It’s all part of our special series: how to install and configure WebSphere Portal 6.1 on Ubuntu. This isn’t a Portal only issue, rather it’s a DB2+Ubuntu issue.

After getting Portal installed on this Ubuntu machine, you’re probably going to want to transfer the default Derby database to something more robust like DB2. So you edit wkplc_comp.properties and wkplc_dbtype.properties, and start to run:

And you get this in the ConfigTrace.log

Hmm, ok, I thought db2 was working. A good habit when debugging these things is to take the piece that ConfigEngine is trying run and run it independently. So right now I want ConfigEngine to create an empty db2 database that I can run database-transfer against. Try this:

And that comes back successfully. However, that command sequence is not an accurate representation of what ConfigEngine is actually doing. We’re running ConfigEngine as root. But the ConfigEngine script is using the “user db2inst1 using ” modifiers on the end of the database create command. So how about this?

Ah ha, a failure. In the first example, DB2 already trusts the user that we’re logged is as (db2inst1), so it doesn’t need to go back to the operating system and authenticate it. In the second example, we are logged in as root, so db2 needs to go to the operating system and authenticate the user. Ubuntu uses the tried and true passwd + shadow file combo to store usernames and their associated passwords. The trouble is since Ubuntu 8.10, it uses the newer and more secure SHA512 hashing function to store the passwords, and DB2 doesn’t understand SHA512. So the workaround is to change the hashing function in use on the machine, reset the password and then we should be able to use the “user db2inst1 using ” type commands again.

Open /etc/pam.d/common-password in a text editor and change this line:

to

Then run passwd db2inst1 and put the same or a new password. If you look at the shadow file , the hash will change from something like this:
SHA512

MD5

(The unencrypted password here is ‘password’ – don’t get too excited!) .

Now try running ConfigEngine.sh create-database again. It should work. Make sure you change the system /etc/pam.d/common-password back to sha512, as you want the rest of your users to use this hashing function as it is more secure than md5sum . Hopefully DB2 should address this in a fixpack.

To check it out, unzip the driver and read the META-INF/MANIFEST.MF file. Here’s mine:

Also Portal (and regular ol’ Appserver) will tell you as they initialize in the SystemOut.log, just try this trusty command :

cat SystemOut.log | grep -A 2 “Oracle JDBC”

and you get back something like :

What! 9.2.0.8! Looks like I’ve got the wrong one on there.