Saturday, June 20, 2009

Restricting authentication based on group membership when configured for standalone LDAP

How do you configure IBM WebSphere Portal so that only members of a specific group can log in if WebSphere Portal security is configured to use a standalone LDAP?


The same general steps will be taken for each supported LDAP although the specific userFilter will differ depending on the LDAP brand and/or version.

First, check with your LDAP administrator to confirm that your LDAP implements an attribute whereby group membership is specified within each user record. The IBM® Redbooks® publication, "IBM WebSphere Portal V6 Self Help Guide", lists the default attributes used for memberOfAttributeName support in several supported LDAPs in table 5-15 on page 155.

If your LDAP implements one of these attributes, verify that it can be used to properly identify the subset of users who should be allowed to authenticate to the Portal server. Check the userFilter in the file: (This assumes the userFilter in was not edited since originally enabling security. You can likewise refer to the ConfigEngine helper files for your LDAP to help construct your userFilter.)


Test the search filter using ldapsearch prior to making any changes to the WebSphere Portal configuration. Your ldapsearch might look something like:

ldapsearch -x -v -D -w -h -p -b (&(objectclass=inetOrgPerson)(groupMembership=))

(This example uses Novell eDirectory's groupMembership attribute.)

If the search succeeds, add the (cn=%v) back to the userFilter, then back up and update as follows:


( is a distinguished name and might be something like cn=portalgroup,o=yourOrganization.)

Update the WebSphere Portal and WebSphere Application Server security configurations by running wp-modify-ldap-security as described in the Information Center v6.1:

WebSphere Portal > Installing WebSphere Portal > Setting up WebSphere Portal > Setting up a (standalone/clustered) production server > Configuring WebSphere Portal to use a user registry > Configuring WebSphere Portal to use a user registry on (your OS) > Choosing your user registry model on (your OS) > Configuring a stand-alone LDAP user registry on (your OS)

Users should now be authenticated only if they belong to the group identified by above.

How to forward search requests to the Search Center Portlet

This technote discusses how to create a search box that will forward search requests to the Search Center Portlet.

Resolving the problem
Search functionality is often crucial but there are times when placing the default Search Center portlet on a page does not fit with the plan and design of a portal. The solution is to write a simple search box that can be conveniently put on your Portal page that will forward the query to the complete Search Center Portlet on a new page.
In IBM WebSphere Portal 6.1, this can be accomplished with code similar to the following.

Add the code to the banner_searchControl.jspf file (located in \profiles\wp_profile\installedApps\\wps.ear\wps.war\themes\html\):

<%@taglib uri="/WEB-INF/tld/portal.tld" prefix="wps"%>

Wednesday, June 17, 2009

Portal 6.1 will not start after enabling runtime Warning tracing level

IBM WebSphere Portal version 6.1 or higher is installed successfully, however during the startup of the server, users are unable to access the login page and receive an error of 404: Page Not Found. The SystemOut.log file shows an error message of EJPFD0016E: Initialization of service failure while the Portal appserver was starting. This Technote explains how to resolve this error so users can successfully access the portal's login page.


Actions Taken to Induce Behavior
1) Login to the WebSphere Application Sever Administrative console for the WebSphere_Portal
server (i.e. http://hostname:10027/ibm/console by default).
2) Navigate to Troubleshooting -> Runtime Messages -> Runtime Warning
3) Select Warning from the pull down menu and click apply.

4) Review and Save the changes.
5) Restart the WebSphere Portal server.

*Note: This behavior will only be induced if logging into the Application Server Administrative console that is running in the WebSphere_Portal application server, for example:

It will not be induced if logging into the Application Server Administrative console that is running in the server1 application server, for example:

Look in the serverindex.xml file to confirm which WC_adminhost_secure port numbers are being used for server1 and WebSphere_Portal.

Review of the Portal SystemOut.log File
The file SystemOut.log records many activities that the portal undertakes during
startup and runtime. Reviewing this file, the following might be observed:
[4/21/09 17:49:27:438] 00000014 Servlet E init EJPFD0016E:
Initialization of service failed.
Caused by: java.lang.ClassNotFoundException:
[4/21/09 17:49:27:486] 00000014 ServletWrappe E Deregister the mbean because of uncaught init()
exception thrown by servlet portal: javax.servlet.UnavailableException: Initialization of one or more
services failed.
Caused by: java.lang.NoClassDefFoundError:

Resolving the Errors
1) Locate the following file:
2) Make a backup of this file.
3) Open this file in an ASCII text editor
4) Locate the following line in the server.xml file:
5) Add the following line JUST after this line in the server.xml file:
value="${WPS_HOME}/shared/ext" description="Internal Portal component"
*Be SURE the xmi:id= does NOT match any other items in this file.
6) Save the server.xml file.
7) Stop and start the Portal server.

APAR Fix Available
WebSphere Application Server (WAS) APAR PK79875 will prevent this behavior from occurring. This APAR is scheduled for inclusion in the WAS and fixpacks. If runtime warning messages are required in the affected environment, it is STRONGLY recommend the interim APAR fix be installed to prevent the ws.ext.dirs property from being overwritten.

Technical Explanation: Missing Java .jar File During Startup
WebSphere Portal is dependent on correctly loading a number of Java .jar files during startup to
correctly function. In this instance, the NoClassDefFoundError indicates the Portal system is either using
an incorrect Java classloader to load the .jar file, or, is unable to locate a .jar file needed for proper

Reviewing the Portal SystemOut.log file, the following may be observed during a previous startup

ws.ext.dirs = /opt/IBM/WebSphere/PortalExpress/AppServer/java/lib:[...]:/opt/IBM/WebSphere

Reviewing the Portal SystemOut.log file, the following may be observed during a current startup attempt:

ws.ext.dirs = /opt/IBM/WebSphere/PortalExpress/AppServer/java/lib:[...]:/opt/IBM/WebSphere

Observe the missing /opt/IBM/WebSphere/PortalExpress/PortalServer/shared/ext value in the ws.ext.dirs parameter. This parameter is built from the WebSphere Portal server.xml file. The actions taken section caused an update to occur to the WebSphere Portal server.xml file. This update inadvertently overwrote the property which specified the ws.ext.dirs parameter.

Tuesday, June 9, 2009

Overriding the Web Content Management (WCM) presentation template by way or URL parameter in v6 functions differently from v5

You utilize the pageDesign= URL parameter to control which presentation template to display at time or rendering in Web Content Management (WCM) v6 and receive unexpected results compared to v5

The solution varies depending on where you call the URL command your version of Web Content Management.

To override or to specify a specific presentation template (or page design) to a WCM object at time of rendering, append the following URL parameter depending on the request context.

For a servlet: some_url?pageDesign=my_template

For a portlet: some_url&pageDesign=my_template


To override or to specify a specific presentation template (or page design) to a WCM object at time of rendering, append the following URL parameter depending on the request context.

Scenario 1: If you are loading the presentation template from the same library as the object you are rendering:

For a servlet: some_url?pageDesign=my_template

For a portlet: some_url&pageDesign=my_template

Scenario 2: If you are loading the presentation template from a library that is different than that of the object being rendered:

For a servlet: some_url?pageDesign=my_library/my_template

For a portlet: some_url&pageDesign=my_library/my_template

Monday, June 8, 2009

Retrieving the rendering context within a WCM .jsp component

How do you retrieve the rendering context within a Lotus Web Content Management (WCM) .jsp component?

Sample .jsp:
1. For the preview to work, place the code in the following directory:

2. Access via a .jsp component configured with the following path: /jsp/html/render.jsp.
    Note that this .jsp will not work if accessed directly using a URL in a browser such as xxxx/wps/wcm/jsp/html/render.jsp. The .jsp must be accessed via Preview or a rendering portlet.

    If you are accessing the content via the Web Content Viewer local rendering portlet, you must also place the .jsp in the war/jsp/html directory for the local rendering portlet. Here is a sample location:

    If you use the Remote Rendering Portlet, you must place it there as well.
    <%@ taglib uri="/WEB-INF/tld/wcm.tld" prefix="wcm" %>
    <%@ page language="java" contentType="text/html; charset=ISO-8859-1" %>
    <%@ page import="*" %>
    ">Cannot get Workspace


    RenderingContext currentRenderingContext = (RenderingContext) pageContext.getRequest().getAttribute(Workspace.WCM_RENDERINGCONTEXT_KEY);

    out.println("APP PATH: " +currentRenderingContext.getWcmWebAppPath() + "

    out.println("Servlet PATH: " +currentRenderingContext.getWcmServletPath() + "

    out.println("Rendering Context " +currentRenderingContext.getPath());


    Note: if the rendering context is returning %2F instead of "/", you may want to use the string replaceAll method to modify. For example:

    String myContext = currentRenderingContext.getPath();
    String myModifiedContext = myContext.replaceAll("%2F", "/");

Determining if WebSphere Portal security configuration is standalone or federated

How do you determine if your IBM WebSphere Portal security configuration is standalone or federated?

Open the security.xml file.

Standalone: /config/cells//security.xml
Cluster: /config/cells//security.xml

The activeUserRegistry property appears on line 2.

If the configuration is federated (which is the out-of-the-box default), the value will be WIMUserRegistry_1.

If the configuration is standalone, the value will be LDAPUserRegistry_1.

Running the Portal configuration task, wp-modify-ldap-security, will change the security configuration to standalone. Among other things, a standalone configuration does not support multiple repositories, including multiple LDAP servers. If your architecture requires multiple LDAP servers and you have a standalone security configuration, run the config task wp-modify-federated-security to "switch" or convert to a federated configuration before running any tasks to add another repository.

Refer to Configuring WebSphere Portal to use a user registry for details

How to disable unused applications in WebSphere Portal v6.1.x.

What is the minimum set of applications needed to run IBM® WebSphere® Portal v6.1.x? How can you disable or uninstall extra applications that are not in use? Will this improve the startup performance and decrease the total startup time of the Portal 6.1.x system?

This technote provides detail about what applications should run to enable WebSphere Portal v6.1.x to function correctly and how to safely disable applications that are not in use.


WebSphere Portal and Lotus® Web Content Management (WCM) version 6.1 can be installed in a number of different configurations. In a default full installation including both Portal and WCM v6.1.0.1, a total of 103 applications are installed. In many scenarios, it is not desirable to run all 103 applications simultaneously.

WARNING about disabling applications:
This technote provides details on how to disable or uninstall applications in a Portal environment. Making such changes may have unintended side effects on the Portal environment. It is STRONGLY recommended that any changes first be applied in a sandbox or test environment where such changes and the potential for unintended side effects will have minimal impact prior to being attempted in a development, quality assurance, or production environment.

Limitations of IBM Support
IBM Support cannot recommend which specific applications should be disabled in a given environment. Each customer's environment is unique and any recommendations would require a detailed analysis and customization per environment. Such a customization is provided by IBM Services but not by IBM Support. The minimal set of applications is noted in this technote. Thorough testing should be done to ensure that disabling an application does not adversely affect other applications operating in the same Portal environment.

Method #1: Automatically disabling applications via the Portal configuration task
The "enable-develop-mode-startup-performance" configuration task will automatically disable all applications except the bare minimum needed to run WebSphere Portal v6.1.0.1. As described in the Portal 6.1.x Information Center, this task performs the following actions:
    Java Virtual Machine (JVM):
    JVM will be switched to development mode and the initial heap size will be set to the maximum heap size to reduce the amount of garbage collection during start up.

    Portlets and Web Applications will be activated on first access and not at start up. Since some of the portlets and applications are required at start up, a white list will hold the applications still started at start up.

    NOTE 1: The configuration task will disable MANY applications and break functionality including Portal search functionality, Web Content Management (WCM), custom applications, and so on. To prevent the configuration task from disabling functions such as custom applications and search, the Portal 6.1.x Information Center contains information to whitelist applications so they are not disabled by the configuration task.

    NOTE 2: To add applications to the white list, modify the profile\PortalServer\config\StartupPerformance\ wp.base_ProfileEarAttributesTargetMapExclList.jacl file. Add a line such as lappend WarFileNameList App_name, where App_name is the name of the application. Log into the WebSphere Application Server console mode and navigate to Applications --> Application Types --> WebSphere Enterprise Applications to get a list of available applications.

    On a Portal system, all applications EXCEPT the following will be disabled:

    NOTE 3: It is recommended this configuration task be run with an administration installation although it can be successfully run with a full installation of Portal 6.1.x.

Method #2: Disabling applications manually:
    If it is not desirable to automatically disable 91 applications from auto-starting, it is possible to perform this task manually and disable each application one at a time. To perform this task of preventing the applications from auto-starting:

    1. Start the WebSphere Application Server associated with WebSphere Portal( server1).

    2. Log into the WebSphere Application Server administration console
    (https:/ /

    3. Go to Applications --> Enterprise Applications --> individual application such as PA_Search_Center.

    4. Click "Target specific application status" --> Disable Auto Start.

    5. Optional: Go back to the application listing and click Stop to stop the application that is currently running on the Portal server.
Technical considerations:

Disabling vs. uninstalling applications:
In general, once applications are uninstalled, they can be very difficult to redeploy correctly, especially if the system was upgraded. Therefore, it is STRONGLY recommend that instead of uninstalling applications permanently, the applications should be disabled from auto-starting when the Portal server is started. The applications will take a minimal amount of storage space on the Portal system (and on the Deployment Manager if in a cluster) and will not be in use by the Portal system during startup or normal operations.

Should business needs change, the applications will be available and can be enabled at a moment's notice. Further, if an application is uninstalled and there is a hidden dependency that is unknown, it can be painful to attempt to reinstall the application instead of simply restarting the application if it is disabled and not auto-started.

Portal startup performance time
At the time of this writing, a limited amount of testing was done on a test lab machine in which the applications were disabled using the Portal configuration task, "enable-develop-mode-startup-performance", explained in Method #1 above:

With a default installation of the Portal Content Server with all 103 applications enabled, reviewing the SystemOut.log file for a startup time displayed a total startup time of approximately 3 minutes, 10 seconds:
    [datetime] 0000000a ManagerAdmin I TRAS0017I: The startup trace state is *=info.
    [datetime] 0000000a WsServerImpl A WSVR0001I: Server WebSphere_Portal open for e-business

With a default installation of Portal Content Server with 91 of 103 applications disabled via Method #1, reviewing the SystemOut.log file for a startup time displayed a total startup time of approximately 1 minute, 39 seconds:
    [datetime] 0000000a ManagerAdmin I TRAS0017I: The startup trace state is *=info.
    [datetime] 0000000a WsServerImpl A WSVR0001I: Server WebSphere_Portal open for e-business

Exact performance gains or losses will be environment-specific. However, in general, the fewer applications started by the Portal server during startup, the quicker the Portal server startup time should be.

Thursday, June 4, 2009

Customizing the Portlet Unavailable message

How can you provide a different error message than Portlet Unavailable, based upon the portlet involved?

You have a few options to customize the Portlet Unavailable message. First, look at one of your skins, such as the following one:


In that location is the control.jsp file that calls the portlet to render with the following tag:

Therefore, the body of the tag is only rendered if the portlet has a problem. The program uses a key passed by the portal engine to determine what value to pull from the resource bundle. More information on the problem format tag can be found in the Information Center topic " tags."

So, you could create a new skin for your specific portlets and enter your own custom text there. Or you can use the fmt tags and pull a different key from the regular text bundle.

All of these resource bundles are stored in the wp.ui.jar file in the portalserver/shared/app directory.

For the English language, you use the file. In that file, you see the following line:

    portlet.not.available = This portlet is unavailable.

You can change that text to whatever you wish. Note that the text you enter will be the same for every portlet that is unavailable.

If you want only the Web Content Management (WCM) portlets to return a different message, you need to replace this line:

With something like the following:

Then you add a line to the file in wp.ui.jar like this:

    wcmproblem = The WCM portlet could not be rendered

You would need to add a line like that to every language file for

You can also suppress the Portlet Unavailable error messages.

How to tell that search indexing has completed in IBM Web Content Management (WCM)

As the system administrator of an IBM® Web Content Management (WCM), you are interested in learning if the product's search index can completed being processed. How does one verify that the search indexing has completed?

The WCM system's SystemOut.log and trace.log files can be used to indicate the status of the search index's state of completion.

Search stringMeaning
IndexMaintainer.processPendingUpdates. ProcessedThis entry in the WCM SystemOut.log indicates that the index maintainer task is completed.
[12/4/07 19:45:58:734 IST] 0000013e JCRCFLLoggerI I [java.lang.ThreadGroup[name=icmciWorkManager: icmjcrear,maxpri=10]] [java.lang.ThreadGroup[name=icmciWorkManager: icmjcrear,maxpri=10]]: - IndexMaintainer.processPendingUpdates. Processed 149 events for index: 1

Search stringMeaning
IndexMaintainer.runIndexMaintenance() (*** no pending updates***)This entry in the WCM trace.log indicates that there are no events needing to be processed.
This output written to the trace.log requires that the following configuration be enabled:*=finest