When the default isn’t enough – creating a new Lotus Connections Files policy

As posted earlier today I had to change the default maximum library size of in Lotus Connections Files to accommodate a particular user. Of course 1 GB (double of the default) wasn’t enough so I created a new policy for that particular user and assigned it. I was very easy as well. Below are the wsadmin commands.

wsadmin<FilesPolicyService.add("2GB Policy", 2097152000)
A policy was added with the new id 584f818a-106c-4343-
8f40-63ceb0ac5c5f .

wsadmin<FilesLibraryService.assignPolicy(
   "1a60c8d1-fc59-41bc-9d89-c266a9709230",
   "584f818a-106c-4343-8f40-63ceb0ac5c5f")
The policy with the id 584f818a-106c-4343-8f40-
63ceb0ac5c5f is now assigned to the library with the id
1a60c8d1-fc59-41bc-9d89-c266a9709230.

Lotus Connections and extending Files Library Sizes

Funny thing at a Lotus Connections customer today. A user was complaining that he wasn’t able to upload a new version of a file into his Files due to size restrictions. After poking around I found out that the user had uploaded 492 mb of data into Files. After poking some more I found out that a maximum library size is enforced based on policy. By default all users are assigned a policy that allows for 524 mb of data hence why he was unable to upload any more data.

To solve it I changed the default policy to allow for 1 gb of data per user (after asking management). This is done using the administrative service API for Lotus Connections which is quite extensive. Below are my steps with the key values in bold.

The steps are as follows:

  1. Initialize the wsadmin environment
  2. Get access to the Files administrative services
  3. Find the user id using FilesMemberService.getByEmail(email) (user id is f631a9d9-07c4-4dcc-b820-1fdaefc4895c)
  4. Find the users library id using FilesLibraryService.getPersonalByOwnerId(id) usig the just found user id (library id is 1a60c8d1-fc59-41bc-9d89-c266a9709230). This also shows the user is controlled by the default policy (policy id 00000000-0000-0000-0000-000000000000) and that he is using 93% of the allotted space)
  5. Edit the default policy using FilesPolicyService.edit(id, name, size) to set a new size of twice the original size)
  6. Refetch information about the users library using FilesLibraryService.getPersonalByOwnerId(id) to see that the new library size has been applied

D:IBMWASprofilesAppSrv01bin>wsadmin -username wasadmin
-password <password> -lang jython
WASX7209I: Connected to process "server1" on node SDKFU016Node01
using SOAP connector;  The type of process is: UnManagedProcess
WASX7031I: For help, enter: "print Help.help()"

wsadmin>execfile("filesAdmin.py")
Files Administration initialized.

wsadmin>FilesMemberService.getByEmail("jdoe@example.com")
{isOprhan=false, email=jdoe@example.com,
directoryLastUpdate=2011-01-04 17:07:57.167,
id=f631a9d9-07c4-4dcc-b820-1fdaefc4895c, name=John Doe,
createDate=2010-02-19 13:04:36.404, communityLastUpdate=2011-01-04
17:12:25.084, lastVisit=2011-01-04 17:07:57.167,
directoryGroupLastUpdate=2011-01-04 17:12:25.084}

wsadmin>FilesLibraryService.
   getPersonalByOwnerId("f631a9d9-07c4-4dcc-b820-1fdaefc4895c")
{lastUpdate=2010-02-19 13:04:36.467, externalInstanceId=null,
id=1a60c8d1-fc59-41bc-9d89-c266a9709230, type=personal,
ownerUserId=f631a9d9-07c4-4dcc-b820-1fdaefc4895c, title=John Doe,
label=24924863-F97C-C455-C125-74C9004077E4, externalContainerId=null,
policyId=00000000-0000-0000-0000-000000000000, createDate=2010-02-19
13:04:36.467, summary=, percentUsed=0.9382985649108887,
maximumSize=524288000, size=491938678}

wsadmin>FilesPolicyService
   .edit("00000000-0000-0000-0000-000000000000",
   "Default Policy", 1048576000)
The policy with the id 00000000-0000-0000-0000-000000000000 was
   updated successfully.

wsadmin>FilesLibraryService
   .getPersonalByOwnerId("f631a9d9-07c4-4dcc-b820-1fdaefc4895c")
{lastUpdate=2010-02-19 13:04:36.467, externalInstanceId=null,
id=1a60c8d1-fc59-41bc-9d89-c266a9709230, type=personal,
ownerUserId=f631a9d9-07c4-4dcc-b820-1fdaefc4895c, title=John Doe,
label=24924863-F97C-C455-C125-74C9004077E4, externalContainerId=null,
policyId=00000000-0000-0000-0000-000000000000, createDate=2010-02-19
13:04:36.467, summary=, percentUsed=0.46914928245544435,
maximumSize=1048576000, size=491938678}

wsadmin>

Solving a Lotus Connections 2.5 login performance issue

During the last week I have been diagnosing a login performance issue at a Lotus Connections 2.5 customer. The issue manifested itself by it taking around a minute for some users to login. It was only an issue for the initial login hence it was caused by something that the Websphere server cached on subsequent login attempts.

After diagnosing and making sure the install was at the latest fixpack and fixlevel from Fix Central, I finally found out what was going on. By using the Websphere Application Server trace functionality it became apparent that it was the Waltz / Directory Service Extension (DSX) component of Lotus Connections that was causing the problem. The issue was that Waltz took a very long time to resolve the groups the user belonged to and hence login took forever.

Waltz is using the federated repository LDAP setup from Websphere so for starters I found a workaround. The workaround was to disable group support in the Integrated Solutions Console (ISC) by setting a custom group search filter (e.g. objectClass=dummy). This works but also means you’re turning of group support completely.

A better solution which also works is to modify the Waltz setup in the directory.services.xml file in the LotusConnections-config directory. By default the top section looked like this:

<!-- *************************** -->
<!--   Waltz Profile Provider    -->
<!-- *************************** -->
<profileProvider
   class="com.ibm.connections.directory.
      services.provider.WaltzServiceProvider" />

Reading through the file and using the schema as a guideline I could add an option to disable the group expansion i Waltz by embedding a property-tag beneath the profileProvider-tag as shown below.

<!-- *************************** -->
<!--   Waltz Profile Provider    -->
<!-- *************************** -->
<profileProvider
   class="com.ibm.connections.directory.
      services.provider.WaltzServiceProvider">
   <property name="com.ibm.connections.directory.
      services.ldap.group.membership.service.enabled">false</property>
</profileProvider>

Lotus Connections seems to be working just fine despite this option being set though I’m not completely sure of all side effects. I’ll post more if/when I learn more.