Gee... David

An unexpected surprise (as if there is such a thing as an 'expected' surprise?!) arose on Friday afternoon. After a successful implementation of a new version 6.0.1.1 Portal that duplicated the settings of an existing (now retired) version 5.1.3 Portal we discovered that only a fraction of the established user  community was available to the Portal.

The symptoms were a little bizarre. First, I tested my logon as well as that of the portal admin we configured during install and migration. Result: Success. Another team member similarly logged on. As both users were in the LDAP directory we rode off into the sunset on Thursday thinking we were ready to put the remaining configuration on auto pilot. Alas (I have been using that word a lot lately) we were premature in our celebration!

When my partner attempted to add users to the list of users authorized to access a portlet application he could not see them in the list. Our first reaction was that the LDAP bind user lacked sufficient permission. To confirm this or to discover the root cause we collaborated with the LDAP administrator. He helped us to clarify the problem by eliminating permission as the source of the problem and suggested that we had a problem with the search base.

We each agreed this was plausible but seemed strange since the settings were borrowed from an existing server. We did a file comparison of the wpconfig.properties file on each and found that the two were consistent. We did, however, note that the searchBases attribute for the LDAPUserSuffix was too narrow. An investigation of the wmm.xml file confirmed that the

An unexpected surprise (as if there is such a thing as an 'expected' surprise?!) arose on Friday afternoon. After a successful implementation of a new version 6.0.1.1 Portal that duplicated the settings of an existing (now retired) version 5.1.3 Portal we discovered that only a fraction of the established user  community was available to the Portal.

The symptoms were a little bizarre. First, I tested my logon as well as that of the portal admin we configured during install and migration. Result: Success. Another team member similarly logged on. As both users were in the LDAP directory we rode off into the sunset on Thursday thinking we were ready to put the remaining configuration on auto pilot. Alas (I have been using that word a lot lately) we were premature in our celebration!

When my partner attempted to add users to the list of users authorized to access a portlet application he could not see them in the list. Our first reaction was that the LDAP bind user lacked sufficient permission. To confirm this or to discover the root cause we collaborated with the LDAP administrator. He helped us to clarify the problem by eliminating permission as the source of the problem and suggested that we had a problem with the search base.

We each agreed this was plausible but seemed strange since the settings were borrowed from an existing server. We did a file comparison of the wpconfig.properties file on each and found that the two were consistent. We did, however, note that the LDAPUserSuffix was scoped to an organizational unit. We confirmed the effect of this value in wmm.xml where we found that searchBases attribute for the supportedMemberType element for "Person" was similarly scoped too narrowly.

By 'borrowing' from the 5.1 server we uncovered what appears to be an ineffective setting in the older version. Clearly, we think, the setting is not enforced in the 5.1 server as were are able to see the entire organization's directory content converse to the effect in the version 6 implementation of portal.

The good news is that a simple edit of the wmm.xml file and a restart of portal resolved the issue and the crisis abated just in time for a Friday afternoon ride into the sunset.

Je suis fine!

Oh: I almost forgot, here is the note that confirmed my suspicions: IBM Support Document

http://www-1.ibm.com/support/docview.wss?rs=2175&context=SSMHXX&dcÛ520&dcÛ560&uid=swg 21249901&loc=en_US&cs=UTF-8&lang=en&rss=ct2175lotus