Every since Sametime 8.5.2 was released I have seen a continual problem with Sametime trusted ips that  is still there in Sametime 9.0.1.  The issue is that the trusted ips list (which tells the Community Server which server ips to accept connections from) is now entered into the Sametime System Console in WebSphere and not directly into the CommunityConnectivity document in stconfig.nsf.  This means that since 8.5.2  the trusted ips in the Community Server configuration in WebSphere are then written to the Domino document at intervals.

So what’s the problem?  Well when WebSphere writes the list of trusted ips into the Domino document, it does so as a string, not as a list.  A small thing but that means when the Community server restarts the trusted ips don’t work as what Sametime sees is a long string instead of multiple values.  To fix this I wait until WebSphere has updated and then open and save the CommunityConnectivity document which refreshes and parses the string with commas in it into a list (since the field is a multi value list field anyway Domino is smart enough to do that).

Of course I then have to restart the server. Below are the examples of what I mean, first how WebSphere writes the values and secondly how Sametime needs to see them written.

How WebSphere Writes The Values

How Sametime Wants To See The Values

I first opened a PMR on this back in 8.5.2 days and have tried occasionally since then  to open others but never got very far (around the time I am explaining Domino multi value fields to someone in China I lose the will to live). It always occurs if I have several ips to enter, not so much if there is just one or two.  The annoying thing is remembering to check every time I make any change to the Community Server configuration (which isn’t often once it’s setup).  Anyway, this has been my built in workaround for 3 years, it’s not hard and I know one of two other people out there have seen this too so here’s my “fix”…..

Building out another Sametime environment this week and I hit a roadblock. Fortunately because I’m a control freak I always read along with the documentation when I do an install, no matter how many times I’ve done it before.  I do this because it’s always possible IBM have updated their documentation since I last saw it…..and so I found,  buried in the documentation here, on the install page of the VMCU.. under

Deploying -

Deploying Common Component -

Deploying Audio and Video -

Sametime Media Manager on Linux or Windows -

Installing the Sametime Media Manager’s VMCU component -

Installing the Sametime the Sametime Video MCU - Step 9)

I find this

“Download and install the following prerequisite RPMs if they are not already installed.

For the list of RPMs to install, see the IBM Technote, List of RPMs to install on the Sametime Video MCU“

Yes a shiny list of pre-reqs required only by the VMCU and not on the system requirements.  Unfortunately they are all fairly old RPMs and at the current site although the packages are there, they are all newer versions of the ones needed.  The tech note is very specific about that

“Important: Each RPM’s file name includes a version number in the format X.X.X.Y, where X is a mandatory level that cannot be changed, and Y is a minimum level. If your RPM has a higher level for the value in the Y position, you can use it.”

So you may have zlib installed but if you have zlib-1.2.7-0.*.x86_64.rpm but the tech note calls for zlib-1.2.3-106.*.x86_64.rpm then you’re out of luck unless you can revert back to zlib-1.2.3. something

I assume the tech note (which is only a couple of weeks’ old) is a result of support having to deal with VMCU problems and determining those exact packages are needed for the VMCU to work.  It’s not a problem so long as you know about it and make sure those packages are in place before you start.