Sametime meeting widget on IBM Connections 5.0 CR02 – error 403

I like the integration points between Connections and Sametime. The meeting room widget is a useful bridge which allows you to create meeting rooms to be used for a community. This means there is no need to create your own and try to remember who needs access to the room, whether the content needs to be removed etc. The widget keeps the membership of the meeting room in line with the membership of the community via a member synchroniser (or synchronizer).

I had some problems with CR02. I didn’t have the same problems with 4.5 and various CRs.

Firstly, the documentation in the knowledge center is inaccurate and a bit sloppy though I think that was still the case with 4.5. You can see the various comments me and others have posted on the pages. Read these comments, as I don’t know whether IBM have updated the main text yet.

If you follow the instructions as well my comments you should get as far as getting 403 exceptions in the widget. This is an AJAX proxy error BUT based on the documentation the configuration is correct. I raised a PMR with IBM and over the weeks the following steps were taken which resolved the problem.

I will provide snippets of the various files I made changes to so please supplement the knowledge center with my findings.


There are two ifixes I applied.




The use of {communitiesSvcRef} is more in line with the other contents of this file. It avoids needing to hard code the “url” and “iconUrl” values. Also, never call the xml or jpg using c:\ or /opt/IBM/ as the images will not show properly in a web browser.

The last thing that got this working was to remove any reference to the port number from “sametimeMeetingsServerUrl.” I had followed the knowledge center and added “:443″ to the end of it.

<widgetDef defId=”Meeting Rooms” primaryWidget=”false” modes=”view fullpage” uniqueInstance=”true” url=”{communitiesSvcRef}/MeetingRoomsWidget/MeetingRoomsWidget1.xml” iconUrl=”{communitiesSvcRef}/MeetingRoomsWidget/meetings-icon.jpg”>
<item name=”sametimeMeetingsServerUrl” value=”; />
<item name=”widgetFilePath” value=”/communities/MeetingRoomsWidget/” />
<item name=”communitiesBaseUrl” value=”{communitiesSvcRef}”/>
<widgetDef defId=”Members” primaryWidget=”false” modes=”view fullpage” showInPalette=”false” uniqueInstance=”true” url=”{webresourcesSvcRef}/web/lconn.comm/communityMembers/communityMembers.xml?etag={version}” helpLink=”{helpSvcRef}/topic/”>
<item name=”membersPerPage” value=”12″/>
<item name=”membersPerPageFullPage” value=”16″/>


Be mindful of the forward slash and star in the “policy url.” Also, if you follow the example in the knowledge center then wsadmin will error when you try to check the file in because the order is incorrect (unless they have updated the entry).

<proxy:policy url=”*&#8221; acf=”none”>


IBM suggested that I add this. I added the following entries early on in the course of the PMR to rule out AJAX proxy permissions. This may not be required but I haven’t tested it without it.

allow(“.*”, “.*”, “http\\:\\/\\/meetings\\.collaborationben\\.com\\/.*”);
allow(“.*”, “.*”, “https\\:\\/\\/meetings\\.collaborationben\\.com\\/.*”);

Creating a shared library

Don’t blindly copy and paste the contents of because in a previous step you unpacked the SDK files into different directories.

Error 412

The final error I got (after the 403) was a 412 error which is mentioned in the knowledge center and one that I came across in 4.5.

412 Failure to create a meeting room.
Possible cause:

The X-ST-CSRF-Token is invalid. Connections has set the HTTPONLY flag.

Workaround for error 412:
Note: Only implement this workaround if you understand its effects and consequences.

Log in to the WebSphere Integrated Solutions Console as the WebSphere administrator. (The URL ends with /ibm/console).
Click Servers > ServerTypes > WebSphere application servers.
Select the server you are working with.
In the Container settings section, click Web container settings > Web container.
In the Additional properties section, click Session management.
Click Enable cookies hyperlink.
Ensure that the Set session cookies to HTTPOnly to help prevent cross-site scripting attacks option is NOT selected.
Click Apply.
Resynchronize the nodes, and restart the WebSphere application server.

I disabled Set session cookies to HTTPOnly to help prevent cross-site scripting attacks for all the Connections applications servers, synced and restarted.


Since I only had the one community that had the widget applied to before the final changes I can’t say for sure they you will need to remove the widget and add it again or simply refresh it. You should experiment for yourselves and be mindful of any browser caching.

With this in mind, it should be working nicely for you.


View all

I have noticed that “view all” does nothing when clicked on it. I created six meeting rooms through the widget. The widget only shows five so I expected that it should take me to the “Meeting rooms” view where all rooms are shown. In Fiddler nothing is reported. I have asked the question of IBM.


Sametime Meeting server document conversion – Linux

OK, this really stumped me until I did a bit of searching and found some really useful posts which I have listed below.

The documentation in the infocenter tells you to copy true type fonts to the Linux server and set a number of paths:

export PATH

After adding the paths ensuring the paths were set permanently documents still wouldn’t convert. Reading the links below I found that I also had to add a path for Java to run, I used “/opt/IBM/WebSphere/AppServer/java/jre/bin” since it was installed with WAS. It would be nice if IBM updated their documentation.

Sametime forum post

German Notes forum

Meeting federation/clustering fails with multiple IPs

I was asked to visit a customer who was having problems federating a primary node (Meeting server) with the SSC. They had some other problems as well which meant that I thought it was best to uninstall, clean up and reinstall.

After the two Meeting servers were reinstalled I hit the same problem when trying to federate the primary node. I looked in the addnode.log and noticed an error with an exception, unfortunately I didn’t take a note of the error but the crux of it was that during the addnode process the IP address the DM was resolving for the PN was incorrect.

Looking at the Windows 2008 server I noticed that it had two NICs, a primary and a management LAN. I added host file entries for the SSC and the two Meeting servers to all three servers after which federation worked fine.

I do not know why WAS picked the management IP, there is probably an algorithm it uses to decide but it is wise to be mindful of this if installing on a server with multiple IPs.

Portal to Sametime – SSO & LTPAToken issue

I had a customer get in touch with me about a problem they were having when trying to start Sametime Classic meetings from IBM WebSphere Portal. They have a link in Portal to a load balancer which then directed HTTP traffic to one of two Sametime Classic Meeting servers.

When logging into Portal and selecting the link a browser would launch and the user would be logged into STCenter.nsf via SSO. When scheduling a meeting the Meeting Room Client (MRC) would load but as soon as the MRC tries to connect to Sametime Community services (chat) an error appears on the user’s screen.

I took this into a development environment and replicated the behaviour. After enabling debugging on the Sametime server I saw the following output in the stusers*.txt

101117_095933.869,INF,Users   ,VpUsrAuthenticate::handleCheckUser: authenticating user with loginName=CN=Ben Williams/O=ACME by a single token
101117_095933.869,FTL,LDAP Aut,authenticating user by tokens
101117_095933.869,INF,LDAP Aut,Starting auth by tokens for [CN=Ben Williams/O=ACME] in org[]
101117_095933.869,FTL,LDAP Aut,checking LDAP format….
101117_095933.884,FTL,LDAP Aut,token verification failed. [4098]
101117_095933.884,INF,LDAP Aut,AuthTokenContext::authenticateBeforeDirSearch verifyTokenAndExtractUserId failed with reason 4098
101117_095933.884,FTL,LDAP Aut,AuthContext::start: authenticateBeforeDirSearch failed with reason 4098
101117_095933.884,INF,Users   ,VpUsrAuthenticate::checkedUser: VpUsrAuthenticate: bad login

I added debug_sso_trace_level=7 and Websess_verbose_Trace=1 to the Notes.ini but again nothing showed apart from when the browser opened STCenter.nsf, so on the Domino side of things SSO is working as expected.

Looking at the Java console output in the web browser when the MRC loaded I noticed “reverse proxy support disabled and detected” appear a few times. I observed this in the customer’s production environment and not in development so I ignored it which turned out to be a red herring.

It got me thinking about a problem I had with Sametime 8.0.2 and an LTPA parsing issue which produced similar errors although not exactly the same. That problem was fixed with a Sametime hot fix and was included in later versions of Sametime so it couldn’t be the same but must be along the same lines.

I exported the LTPAToken from the Portal deployment manager (DM) and imported it back into the Domino web SSO configuration document and restarted but this didn’t resolve the problem.

I then took more time looking at the Portal DM and noticed that Interoperability Mode was enabled which means that LTPAToken and LTPAToken2 are created.

Looking at the web SSO configuration document it was set to LTPAToken only.

After changing it to LTPAToken and LTPAToken2 and restarting things started working and users could now schedule and start meetings.

No awareness in Sametime 8.5.1 Meeting – /C=US

I set up for a customer a Sametime 8.5.1 proof of concept environment consisting of two Linux servers hosting all the WAS components, Domino LDAP and a Windows Sametime Community server. This install was the “Cell Profile” which means that all components run with their own Deployment Manager and Node Agent and you can install multiple components on the same physical server.

Having been bitten in the early days by the Base DN issue I installed all components with a blank base DN because I was using a Domino directory as my LDAP repository. All components installed fine and when accessing the individual DM’s ISC’s and navigating to Users and Groups – Manage Users/Manage Groups I could search and return those users/groups I wanted.

The problem I came across is after enabling integration with the Meeting server and the Proxy server to power awareness in Meetings, awareness just didn’t work.

I enabled debugging on the Community server and found output such as the following in STUsers*.txt which shows that it is appending C=US to the dn which means that the Community server cannot resolve the name and hence why awareness is not working. I also found that SSO worked only in the one direction, Meetings –> STCenter.

101021_134743.595,INF,Users   ,got a request to get the home cluster for CN=Ben Williams,O=ACME
101021_134743.595,INF,LDAP Aut,getting tokens for [CN=Ben Williams,O=ACME]
101021_134743.595,INF,Token Au,get tokens – userId: CN=Ben Williams,O=ACME
101021_134743.595,INF,Token Au,getTokenFromDomino: getting tokens for: CN=Ben Williams,O=ACME
101021_134743.704,INF,Token Au,SECTokenListGenerate returned with status <0>
101021_134743.704,INF,Token Au,LTPA token was successfully generated
101021_134743.704,INF,LDAP Aut,stGetTokens returned [0]
101021_134743.704,FTL,LDAP Aut,authenticating user by tokens
101021_134743.704,INF,LDAP Aut,Starting auth by tokens for [CN=Ben Williams,O=ACME] in org[]
101021_134743.704,FTL,LDAP Aut,checking LDAP format….
101021_134743.704,INF,Token Au,Received token with type <1>
101021_134743.704,INF,Token Au,Validating LTPA/LTPA2 tokens
101021_134743.704,INF,Token Au,Created token entry of type <1>
101021_134743.704,INF,Token Au,SECTokenListValidate returned with status (0)
101021_134743.704,INF,Token Au,User ID extracted from the token is – CN=Ben Williams/O=ACME
101021_134743.704,INF,Token Au,Verify LTPA/LTPA2 token succeeded
101021_134743.704,INF,Token Au,getUserIdSubStrAccordingToConfig: full userId is CN=Ben Williams/O=ACME
101021_134743.704,INF,Token Au,getUserIdSubStrAccordingToConfig: the userId extracted according to uid_prefix and uid_postfix is CN=Ben Williams/O=ACME
101021_134743.704,INF,Token Au,authentication returned code ST_DDA_API_OK for name: CN=Ben Williams/O=ACME
101021_134743.704,INF,LDAP Aut,token for user user [CN=Ben Williams/O=ACME] was successfully verified
101021_134743.704,INF,LDAP Aut,AuthTokenContext::operationBeforeDirSearch verifyTokenAndExtractUserId has returned successfully.
Original login name – <CN=Ben Williams,O=ACME>, extracted user id – <CN=Ben Williams/O=ACME>.
Using the extracted user id.
101021_134743.704,INF,LDAP    ,Entering to isChild
101021_134743.704,INF,LDAP    ,dn = CN=Ben Williams,O=ACME, base =
101021_134743.704,INF,LDAP Aut,Looking up [req -1] [CN=Ben Williams,O=ACME] in []
101021_134743.704,INF,ASYNC   ,VpUsrAuthenticate::getUserDetail: pass to authentication BB
101021_134743.704,INF,CRASH   ,ReqMgr::addAuthReq: got new reqId <0xffffffff>
101021_134743.704,INF,LDAP Aut,—- Thread ID: 2844
101021_134743.704,INF,LDAP Aut,Looking up CN=Ben Williams,O=ACME
101021_134743.704,INF,CRASH   ,—- Thread ID: 6128
101021_134743.704,INF,CRASH   ,ReqMgr::addAuthReq:added
101021_134743.704,INF,LDAP Aut,—- Thread ID: 636
101021_134743.704,INF,LDAP Aut,User CN=Ben Williams,O=ACME looked up
101021_134743.704,INF,LDAP Aut,user [CN=Ben Williams/O=ACME] successfully authenticated by token
101021_134743.704,INF,LDAP Aut,Async auth done. [req -1]

[user CN=Ben Williams,O=ACME] [name Ben Williams] [home ] [organization ]
101021_134743.767,INF,Users   ,VpUsrAuthenticate::handleCheckUser: authenticating user with by a single token
101021_134743.767,FTL,LDAP Aut,authenticating user by tokens
101021_134743.767,INF,LDAP Aut,Starting auth by tokens for [] in org[]
101021_134743.767,INF,Token Au,Received token with type <0>
101021_134743.767,INF,Token Au,Validating LTPA/LTPA2 tokens
101021_134743.767,INF,Token Au,Created token entry of type <0>
101021_134743.767,INF,Token Au,SECTokenListValidate returned with status (0)
101021_134743.767,INF,Token Au,User ID extracted from the token is – CN=Ben Williams/O=ACME/C=US
101021_134743.767,INF,Token Au,Verify LTPA/LTPA2 token succeeded
101021_134743.767,INF,Token Au,getUserIdSubStrAccordingToConfig: full userId is CN=Ben Williams/O=ACME/C=US
101021_134743.767,INF,Token Au,getUserIdSubStrAccordingToConfig: the userId extracted according to uid_prefix and uid_postfix is CN=Ben Williams/O=ACME/C=US
101021_134743.767,INF,Token Au,authentication returned code ST_DDA_API_OK for name: CN=Ben Williams/O=ACME/C=US
101021_134743.767,INF,LDAP Aut,token for user user [CN=Ben Williams/O=ACME/C=US] was successfully verified
101021_134743.767,INF,LDAP Aut,AuthTokenContext::operationBeforeDirSearch verifyTokenAndExtractUserId has returned successfully.
Original login name – <>, extracted user id – <CN=Ben Williams/O=ACME/C=US>.
Using the extracted user id.
101021_134743.767,INF,LDAP    ,Entering to isChild
101021_134743.767,INF,LDAP    ,dn = CN=Ben Williams,O=ACME,C=US, base =
101021_134743.767,INF,LDAP Aut,Looking up [req -2] [CN=Ben Williams,O=ACME,C=US] in []
101021_134743.767,INF,ASYNC   ,VpUsrAuthenticate::authenticateByToken: pass to authentication BB reqId <0xfffffffe>
101021_134743.767,INF,CRASH   ,ReqMgr::addAuthReq: got new reqId <0xfffffffe>
101021_134743.767,INF,LDAP Aut,—- Thread ID: 2844
101021_134743.767,INF,LDAP Aut,Looking up CN=Ben Williams,O=ACME,C=US
101021_134743.767,INF,CRASH   ,—- Thread ID: 6128
101021_134743.767,INF,CRASH   ,ReqMgr::addAuthReq:added
101021_134743.767,FTL,LDAP Aut,—- Thread ID: 636
101021_134743.767,FTL,LDAP Aut,Failed looking up [CN=Ben Williams,O=ACME,C=US]. Trying directory-wide search
101021_134743.767,INF,LDAP Aut,—- Thread ID: 2844
101021_134743.767,INF,LDAP Aut,Searching [base ] [filter (&(objectclass=organizationalPerson)(|(mail=CN=Ben Williams/O=ACME/C=US)(cn=CN=Ben Williams/O=ACME/C=US)(uid=CN=Ben Williams/O=ACME/C=US)))] [scope Subtree]
101021_134743.767,INF,LDAP Aut,—- Thread ID: 636
101021_134743.767,INF,LDAP Aut,Search of [CN=Ben Williams/O=ACME/C=US] failed because the user was not found
101021_134743.767,INF,LDAP Aut,AuthContext::changeConversionFlagIfSearchAllowed()=> all the attempts to search for a LDAP record of [CN=Ben Williams,O=ACME,C=US] has been finished
101021_134743.767,INF,LDAP Aut,AuthContext::nextDir – done dir =
101021_134743.767,INF,LDAP Aut,Async auth failed. [req -2]

With a bit of help from IBM we were able to resolve the issue by making the following changes.

Make the following changes to the Meeting server DM as well as the SSC and remember to ensure that you make a backup of the wimconfig.xml and that you synchronise after each change and restart.

Log into the ISC
Go to Global Security –> Federated Repositories –>

for the Domino Federated Repository –

1.)Setting – Distinguished name of a base entry that uniquely identifies this set of entries in the realm  – to match the Domino org.

2.)Setting – “Distinguished name of a base entry in this repository” – to blank (empty)

3.) Edit the DM’s wimconfig.xml file under the profile_root/config/cells/cell_name/wim/config directory as follows (this example changes the mapping to “externalName”);

<config:uniqueUserIdMapping propertyForInput=”uniqueName” propertyForOutput=”uniqueName”/>

<config:uniqueUserIdMapping propertyForInput=”externalName” propertyForOutput=”externalName”/>

This is the key piece to prevent the appending of the O=ACME to the value in the token generated by WAS.

And then synchronise and restart the nodes and deployment manager.

Please note – if you make subsequent changes to the Global Security Federated Repository area using the ISC – Step 3 may need to be redone as changes may be lost.

What this does –

Step 1.) Insures that the username in the LTPA token created from Domino map to an existing repository in WAS – If there is no match, you get the “user not in defined realm” error in the logs.

Step 2.) Insures that Domino Flat groups can be found for policies

Step 3.) Insures that the username in the  LTPA token that WAS generates is resolvable by the Sametime Community Server. In general, Domino does not validate the username contained within the LTPA token, it grants the user “default” level access to the database based on the validity of the token.

The above has found it’s way into an APAR and should feature in a Technote soon and future releases of 8.5 should be configured this way out of the box.

Again, much thanks to IBM for assisting in fixing this.