Active users showing as inactive in All Connections search

A customer was seeing some users marked as inactive when using the All Connections search but when clicking through to the user’s profile they were active and active in communities and all over areas of Connections.

Looking into the database tables I found that the “state” of these users were correct, for example, in the EMPINST.GIVEN_NAME a particular user had a PROF_USRSTATE equalling 0 which means he’s active. In the EMPINST.EMPLOYEE table affected users had their email addresses which are normally removed when they are made inactive.

After some investigation I found that by simply activating them would mark them as active without any changes to the various tables in PEOPLEDB.

This got me thinking that the problem was an index issue and without knowing how many people were affected I suggested that the customer recreate the index. I provided them with steps of how to back it up, delete it from the file system and create a new one but even after the index created users were still showing as inactive.

Thankfully I had access to the Control Center and decided to look at all the PEOPLEDB tables, none were useful. I then started looking at the next logical database, HOMEPAGE. Interestingly, in the HOMEPAGE.PERSON table there is a column called STATE and the affected users had a value of 1 in that column. Running the following command changed the STATE to 0 and then searching for the user using the All Connections search showed him as active.

wsadmin.bat -lang jython -port 8879
ProfilesService.activateUserByUserId(“E4BB9E9D-43D3-B5A4-8025-7433003EFACB”,email=””, displayName=”Ben Williams”)

Going further I had to identify how many users were affected and the below query gave me the column values I needed to activate users who were marked inactive.


The above query helped but there were still a number of users that were not in HOMEPAGE.PERSON and are in PEOPLEDB. These people were showing as inactive in the All Connections search BUT had never logged into Connections and hence their email addresses had not populated the HOMEPAGE database. These I had cross referenced manually as I don’t have the know how to build a query over different databases 😦

There is a bit of history here. The customer is importing users manually via populate_from dn_file because they want to control who is being added until their Connections 4 environment has been signed off for production and a custom TDI assembly line has been created. A few months ago sync_all_dns was run accidentally which meant that a 1000 or so users had to be identified and then removed from Connections. I believe that this (in some) way caused these problems.

Installing Sametime Bandwidth Manager

A customer has raised some interest in Bandwidth Manager to help monitor and control the bandwidth being used between their various offices in various locale so I went about installing it on my home environment. I won’t add all the screen shots but I will run through the high level steps and add my thoughts.

Before you start though you will want to raise a PMR and reference LO67698: BANDWIDTH MANAGER MODULES DO NOT START UP WITH THE BANDWIDTH MANAGER WAS SERVER which describes a problem where the BWM modules do not start automatically. I noticed this after I installed BWM and have been sent the hot fix which requires a reinstall.


You are required to create a new database. I installed on CentOS 6.4 (64bit) and running the Control Center is difficult. So below is the command you can run using the DB2 command line. This assumes that you already have DB2 installed and that your instance owner is db2inst1.



I used the part number CZYA2ML to instal WAS and CZYH1ML for the iFixes.


The wiki insinuates that you need to use a bind account that has read and write access to LDAP. This is not the case, a read only bind account is fine.

“The bandwidth manager requires an LDAP server to which it has administrative “read/write” access since it looks up, creates, and modifies both users and groups while applying bandwidth management policies. This LDAP server can be any supported LDAP server using the Virtual Member Manager through federated repositories in WebSphere Application Server; use the same LDAP server that is used by the rest of the Sametime deployment. Configuring the WebSphere Application Server LDAP directory for bandwidth manager requires a Bind DN that is a valid LDAP user with administrative privileges.”


When at the “Verifying the SIP Proxy and Registrar virtual host used by the Bandwidth Manager” step of the wiki make a note of the port number for SIP_ProxyRegHOST of the SIP Proxy and Registrar.

When creating the two rules in “Setting up routing from the SIP Proxy and Registrar to the Bandwidth Manager” then use the port number for the port name SIP_DEFAULTHOST of the Conference Manager in the “Conditions” section and also SIP_DEFAULTHOST for the BWM in the “Destination” section.


At first I couldn’t get the traffic filtering from the SIP Proxy Registrar through the BWM. I wasn’t sure whether it was due to mismatch with SIP and TLS. The clients were using TLS to connect to the SIP Proxy Registrar and I configured the routing between the SIP Proxy Registrar and the BWM using SIP over TCP. I wanted to take encryption and certificate exchange out of the equation so I did the following.

Disabled TLS by following the steps in Using the Transport Layer Security (TLS) protocol with Sametime Audio/Video in a load balancing environment. I also changed from TLS to TCP in the screen shot below which is also documented in Changing the SIP transport protocol in the Sametime Media Manager.


I also added the BWM to the trusted IP list as mentioned in Configuring the trusted IP list for the SIP Proxy/Registrar server.

I restarted the Community server as well as BWM and Media Manager components and it still didn’t work.

I then changed from using IP addresses to using host names in both rules on the SIP Proxy Registrar and the configuration section of the BWM and after a restart it started working.


Increasing library size for Connections communities using policies

A customer wanted more files to be added to a particular five communities. The default is a cumulative 512MB allowed to be uploaded to a community library. Changing the global value from 512MB to 1GB wasn’t the way to go about it so a new policy needed to be created to be applied to these five communities.

The customer wasn’t allowed access to the communities so the easiest way was to use the browse option as we only had the user’s word on what the name of all five were and searching on the name would require the syntax to be correct which it turns out was not the case…..

Start wsadmin


FilesLibraryService.browseCommunity(“title”, “true”, 1, 20)

FilesLibraryService.browseCommunity(“title”, “true”, 2, 20)

And so forth
FilesLibraryService.browseCommunity(“title”, “true”, 3, 20)

As I mentioned above, the communities were not listed. I’m not sure why as I do not have access to the servers nor saw the output.

As a catch all I asked the customer to dump all the communities using the following command

FilesLibraryService.exportSyncedResourceInfo(“c:/community_output.xml”, “community”)

(Note – It is meant to be a forward slash as it’s an xml).

This listed all their communities and from it I was able to find that the community names provided by the user were incorrect.

Now the syntax of the community names were corrected the following command was used which provided the community information.

commList = FilesLibraryService.browseCommunity(“title”, “true”, 1, FilesLibraryService.getCommunityCount())

FilesUtilService.filterListByString(commList, “title”, “Community”)

Output of the command is as follows (actual output after new policy applied):

{maximumSize=1073741824, size=523164256, percentUsed=0.4872346818447113, summary
=, createDate=Tue Feb 05 12:02:54 CET 2013, policyId=a4785094-6804-40a0-b68c-005
8e0541d91, externalContainerId=c702d7f1-c297-418e-b4a8-50ac1ee0aff2, themeName=d
efault, label=W59c3266be40d_4d80_925a_e8e85a278ec2, title=Community, own
erUserId=00000000-0000-0000-0000-000000000000, type=community, id=66530fc2-2859-
, externalInstanceId=W59c3266be40d_4d80_925a_e8e85a278ec2,
lastUpdate=Tue Apr 16 14:09:51 CEST 2013}

The libraryid is listed “id” in bold above, that is the value needed.

You can also get this value (which I didn’t realise at the time) in community_output.xml which was run earlier. The xml produced below shows the libraryid which is in bold.

-<snx:resource xmlns:snx=”; name=”Community” widgetInstanceId=”W59c3266be40d_4d80_925a_e8e85a278ec2″ id=”c702d7f1-c297-418e-b4a8-50ac1ee0aff2″ type=”community”>-<snx:creator xmlns:snx=””><email xmlns=””/><snx:userid xmlns:snx=””>00000000-0000-0000-0000-000000000000</snx:userid></snx:creator>-<snx:lastmodby xmlns:snx=””><email xmlns=””></email><snx:userid xmlns:snx=””>88aff0d8-465d-4987-bb4e-c3eea13b51be</snx:userid></snx:lastmodby><snx:property xmlns:snx=”; name=”communityType”>private</snx:property><snx:property xmlns:snx=”; name=”communityThemeId”>default</snx:property><snx:property xmlns:snx=”; name=”contentApproval”>false</snx:property><snx:property xmlns:snx=”; name=”contentFlagging”>false</snx:property><snx:objectIdentifyingTerm xmlns:snx=””>Community</snx:objectIdentifyingTerm><snx:objectIdentifyingId xmlns:snx=””&gt;66530fc2-2859-48aa-a376-8ade74782611</snx:objectIdentifyingId></snx:resource>

Now the libraryid is obtained you have to create a new policy.

Create the policy

FilesPolicyService.add(“1GB Community Policy”, 1073741824)

Take a note of the UUID created (in this format 00000000-0000-0000-0000-000000000000) as this will need to be applied replacing the values in red.

Apply the new policy to the community

FilesLibraryService.assignPolicy(“66530fc2-2859-48aa-a376-8ade74782611”, “string policyId“)

Check that the community is now applied


You should see that the values in blue below have changed and are in line with the new policy.

{maximumSize=1073741824, size=523164256, percentUsed=0.4872346818447113, summary
=, createDate=Tue Feb 05 12:02:54 CET 2013, policyId=a4785094-6804-40a0-b68c-005
8e0541d91, externalContainerId=c702d7f1-c297-418e-b4a8-50ac1ee0aff2, themeName=d
efault, label=W59c3266be40d_4d80_925a_e8e85a278ec2, title=Community, own
erUserId=00000000-0000-0000-0000-000000000000, type=community, id=66530fc2-2859-
, externalInstanceId=W59c3266be40d_4d80_925a_e8e85a278ec2,
lastUpdate=Tue Apr 16 14:09:51 CEST 2013}

Unlocking and locking Places during an upgrade using an xml

During an upgrade from Quickr on Domino 8.5.1 to 8.5.3 FP37 I noticed that the customer had a large amount of locked Places. I didn’t want to lock them after the upgrade manually so a little Googling found some old wikis detailing the upgrade from QuickPlace to Quickr which contained the following commands.

The following commands allow you to write to xml the locked Places and then after the upgrade use that same xml to lock the Places.

load qptool report -q [PlaceIsLocked]=1 -o qptool.lockedplaces.xml
Provides a report of the locked places

load qptool lock -i qptool.lockedplaces.xml
locks the places listed in the xml

Sametime Gateway federation with Google now working

A few weeks ago I blogged that Sametime Gateway federation with Google not working. It turns out it is now working. I was waiting for this to be fixed by Google and incidentally had to restart a customer’s Gateway server and on restart I noticed whilst tailing the trace.log that there were no errors like I had seen before.

I emailed IBM as I had two PMR’s open (for separate customers) and told them that it is now working. Shortly afterwards I received the following official response from IBM.

The connectivity issues reported last month seems to be not relevant anymore. It seems Google rolled back their changes and currently customers can federate with them (unless something will be changed again on Google end)

The symptoms of issue were:
1) Google community could connect (indicated as Green)
2) In traces, there was “cancel” response for any traffic targeted to gmail users:
<presence to=”…” from=”…” type=”error”><error code=”503″ type=”cancel”><service-unavailable  xmlns=”urn:ietf:params:xml:ns:xmpp-stanzas”/></error></presence>

About issue reported below, Google IPs are not validated by the gateway through the dialback (XMPP handshake), but customers firewall may block Google response from these IPs in case it not modified by the customer and the dialback will fail. While Google modifying their servers list sometimes, customers should open their firewall to specific IPS range and follow the changes by themselves.

Federation with Google is so flaky and the biggest frustration with this piece of technology. Well at least it is working….. for now.