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!

I’m doing a bit of work on Portal 6.0.  for a customer, and have installed my test environment on Redhat Enterprise 5.3 . I don’t often use a GUI for these machines and sometimes run into problems. On this one I ran the configure-wcm-authoring WPSConfig.sh task but navigated to the WCM Authoring Portlet and found a blank page. The portlet was on the page, but it wasn’t being rendered. A quick look through the SystemErr.log show the culprit:

WRepositoryBrowser is the class that renders the main view of the authoring portlet. Looks like it requires some extra packages to work if you haven’t installed xorg with your Redhat Server. A quick search of pbone.net reveals I need two additional packages: libXmu-1.0.2-5.i386.rpm and libXtst-1.0.1-3.1.i386.rpm .  I always install compat-libstdc++-296, compat-libstdc++-33 and libXp on Redhat 5 machines as well. (I think if you don’t have  libXp you get a pretty similar error). I hadn’t seen this specific one before, I think it’s because I used the ‘skipx’ directive in the kickstart file for the machine. Long story short, install those packages on your headless redhat machine.

I think this problem isn’t limited to Portal either. When I was trying to install IBM Http Server on the same machine, I kept getting the same error when the Install Shield installer would load (in -console mode, no less), so I guess it would be good to install these packages whenever you’re going to use Java Apps and use the skipx parameter.