In today's blog post we will explain a few lessons around WebSphere Portal and Web Content Manager Administration:

1. How to exclude the friendly name of a page in the path:
When building the friendly URL for a page, WebSphere Portal will add the friendly names of all pages in the hierarchy to the final URL. For example in a content structure Content Root -> Home -> MyPage the URL for the page MyPage would look like /wps/portal/Home/MyPage (or /wps/myportal/Home/MyPage for an authenticated user) -
note that it is possible to configure a different context root if needed.
Now if one wants to exclude a page in the hierarchy it is possible to set the friendly name of the page to the following value: com.ibm.portal.friendly.wildcard
In our sample above by setting the friendly name com.ibm.portal.friendly.wildcard for the label Home the resulting URL for the page MyPage would be /wps/portal/MyPage (or /wps/myportal/MyPage for an authenticated user).
This is documented in more detail here:http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=IBM+Web+Content+Manager+8+Product+Documentation#action=openDocument&res_title=About_friendly_URLs_for_web_content_wcm8&content=pdcontent

2. How to exclude a page / hierarchy from being managed by managed pages:
If you do not want parts of your page hierarchy to be managed pages - meaning stored in WCM in the Portal Site library and syndicated if syndication is configured - it is possible to exclude pages / page hierarchies by setting a configuration flag for the page. Reasons for excluding pages from being managed could be the need to not syndicate certain pages to production since they are not needed there or a desire for moving those pages manually via XMLAccess.
Note: There is no indication in the UI if a page is managed in WCM or not. Thus excluding parts of a site may lead to a very confusing end user experience. Ideally all pages that can be edited by non admin users should be managed pages.

To exclude a page from being managed, use XMLAccess to configure the setting has-system-mapping = false as a property of the content-mapping-info tag for the page in question.
Our recommendation is to create a root page with the has-system-mapping = false setting via XMLAccess and have all the "un-managed" pages below.

4. Is it possible to install 8.0.0.1 fix pack and the latest cumulative fix in one step?
Yes - we support installing both via the IBM Installation Manager in one step. Note that when using the command line to install the maintenance packages you will need to download both repositories.

5. Issues with maintenance installs if the basic authentication TAI is disabled
Among other things the basic authentication Trust Association Interceptor is used to authenticate requests for the theme resources stored in webdav. As part of maintenance we sometimes update the default theme
files in webdav. If the TAI has been disabled for the mycontenthandler URLs the authentication will fail and the webdav update will not take place. That can lead to issues later on.

8. Create a javacore, heapdump, system core from the WAS Console
With WebSphere Application Server 8 and higher it is now possible to trigger the creation of a heapdump, javacore or system dump from within the Websphere Application Server Admin Console for any process in the currently managed cell or standalone server.
The feature is available under Troubleshooting -> Java dumps and cores.

9. Modifying contenthandler / mycontenthandler URLs via ConfigService setting
If you would like the contenthandler / mycontenthandler URLs to change to e.g. trigger a reload of certain theme resources from the server you can trigger that by modifying the WP ConfigService and setting a key "digest.seed" to any string, which will then be used on next portal restart to seed the digest used in the URLs.

We receive a lot of questions related to the Remote Search features available with WebSphere Portal. We have summarized a few frequent ones and the answer below:

- If using a cluster or farm with more than one node and want to use Portal Search do I need a remote Search server?

Yes. The local Search feature can only search a single node in a cluster and since indexes are stored locally other nodes would not be able to leverage those.

- What is the difference between Authoring Search and Rendering Search?

Authoring Search is used by the WCM Authoring Portlet - it is implemented using JCR (Java Content Repository) Text Search that relies upon the Portal Search Service. Rendering Search does not leverage the JCR text search feature but leverages the Portal Search indexing feature.

-If I want to use Authoring Search in a cluster or farm with more than one node what are the high level steps required?

It is required to setup and configure a remote search server (including remote document conversions services). In addition one needs to configure the icm.properties file to point to the remote search service.

The nodes need to be able to communicate with each other so you will need to exchange SSL certificates and LTPA tokens. After these steps have been taken the JCRCollection1 resource collection should be recreated.

- What do I need to configure for rendering search?

Just a remote search service needs to be configured and leveraged when creating the collections. We recommend to not configure authoring search for the production rendering systems due to the performance impact and it not being required since authoring should happen on an authoring system.

- Should I remove local search collections after configuring remote search collections?

Yes.

- Is a shared file system required for authoring search in a clustered or farmed system topology with more than one node?

No. The documentation has been updated to reflect this.

- Should remote search be configured via EJB (Enterprise Java Beans) or SOAP?
We recommend to use EJB as communication mechanism between Portal and Remote Search.

- How to achieve failover with a remote search server?

Right now it is not supported to cluster a remote search server. One possible solution is to configure a primary and secondary remote search server. One can then use access control to manually switch between the different servers when needed (e.g. when maintenance is applied to one of them) without requiring a restart. There are other approaches possible as well as discussed in the document "High availability options for IBM WebSphere Portal 6.1 search".

- What are the most common issues related to remote search?
1. Communication Issues between the remote search server and Portal due to firewalls, incorrect seedlist URLs, timeouts, SSL certificates, ...
2. Security challenges with the remote search server not being able to authenticate to Portal and vice versa. Check the LTPA tokens, used userid's and passwords.
If possible use the same user registry for both Portal and remote search.
3. Document Conversion not being correctly configured on the remote search server.
4. Resource contention issues on the remote search server - ensure a 64 bit JVM is used and that enough heap has been assigned and that the file system has sufficient space.
Also do not forget about the remote search server(s) - it should be a managed server that is monitored for log errors, service availability.

- Are there alternatives to remote search?
IBM Omnifind is an enterprise search solution that can be leveraged with WebSphere Portal and that has Out of the Box integration options with Portal.
It is also possible to use third party search solutions but one would need to handle the integration effort.