I read with interest Carl Tyler’s recent blog entry Sametime Proxy in which he talks about the Sametime Proxy. I agree with Carl that the Proxy is a great piece of technology and a great replacement for STLinks.

I demo’d in my blog entry Sametime Proxy in iNotes – death of STLinks? how the Proxy can be used to replace STLinks in iNotes which should be supported in Sametime 8.5.2 (from what I was told last)…..

Not being of a development mindset I do not fully appreciate it as a toolkit but I do appreciate it from an infrastructure and functionality standpoint and the customers who have adopted it appreciate it’s features.

I look forward to Carl’s forthcoming blog entries so keep an eye on his blog.

I noticed that a white paper from Andy Yiu was released two weeks ago focusing on the architecture of Sametime 8.5x. There is some good information in there and I’d recommend that anyone working with the technology should read it. It’s good to see that information is continuing to be released.

developerWorks article

An IBM’er dropped me an email this afternoon about a portlet which has been released for Portal 7 which integrates with the STProxy. This looks to replace the out dated Sametime Contact List portlet and remove STLinks from Portal.

Now, I haven’t had the chance to try it out but I will soon and post more information.

If someone gets the chance to deploy it please let me know how you get on.

You can get it from the Greenhouse

More information has  become available this morning and a Wiki article has been written.

I’m not sure when this became available but you can now download the PDF from the link below.

Sametime 8.5 Enterprise Scale Deployment

A new document “Deploying a scalable IBM Lotus Sametime 8.5.1 environment for small-to-medium businesses” was released recently written by Andy Yiu.

The document is extremely useful and most importantly has the following paragraph.

“In Lotus Sametime 8.5, certain configuration limitations prevented multiple nodes of different component types from being installed on the same server. These limitations in node-based installations have been corrected for all components, allowing multiple components to coexist on the same server without the limitations for clustering and management of a cell installation.”

The fact that with version 8.5.1 you can install multiple components on the same server is a god send because it made no sense as to why with earlier releases you had to install a cell for each component. This means that multiple primary nodes can be installed on the same server and federated to the SSC removing the overhead of multiple deployment managers and various cells.

I wish this nugget of information was available some time ago or if it was I wish I had stumbled across it sooner.

An updated version of the Sametime 7.5 Redbook has been released which is great news.

The information is extremely useful and even a skim through has uncovered a few useful titbits of information I wasn’t aware of.


PDF version will appear soon.

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

A customer was having a problem with getting the SSC to return users or groups using the “Manage Users” section after connecting to an LDAP source. When trying to search for a user they were getting the following errors in the SSC.

CWWIM4548E The LDAP attribute used as an external identifier ‘dominounid’ has a null value for entity ‘CN=Ben Williams,O=Acme’.

The Domino LDAP repository was managed by another company so we couldn’t see the schema but running an LDIF showed we weren’t seeing all the user attributes. To work around this the customer edited the wimconfig.xml (making a backup first!) and adding the line in bold below.

<config:externalIdAttributes name=”distinguishedName”/>
<config:attributes name=”userPassword” propertyName=”password”/>
<config:attributes name=”krbPrincipalName” propertyName=”kerberosId”>

Make sure the change is synchronised to all the nodes and the DM is then shut down and then started again. If you have any application servers installed then make sure the node agents and application servers are also restarted.

The customer was eventually provided with a bind account to use and the above change was undone.

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.

I needed to create a cluster of Sametime Meeting servers to ensure high availability. With WebSphere (like Domino) this is relatively easy but what about the database? DB2 HADR (High Availability and Disaster Recovery) ensures that two databases are kept in sync with each other in case one of the databases fails.

HADR does this by creating a primary and standby database. The primary is always in use whilst the standby is kept in sync using internal processes to ship database log buffers to it. A process at the standby server then replays the log records directly to the standby database. If the primary fails the standby database can be promoted to primary to take over responsibilities.

  • This is not a seamless fail over, it requires manual interaction to promote the standby database.
  • To achieve seamless fail over other tools such as TSA or HACMP must be used.
  • The standby cannot be accessed, only the primary can be read or written to.
  • In DB2 v9.7 the standby can be used for reads but if you cannot write to it I am unsure of the effect this might have on Sametime.

Instead of installing the limited use (CZLF7ML) version of DB2 for Linux I opted to use the full version (C1X0UEN) which gave me greater control over user accounts and install directory. I decided to use the GUI to set up HADR, good thing about it is that at almost every step you can see the command that the GUI is compiling should you wish to script it next time round.

Screen shots detailing HADR set up.

The deployment plans for the Meeting servers both have to point to the same DB2 fqhn as defined in the “Connect to DB2 databases” in the SSC. If the primary DB2 server should fail WebSphere will not be able to read/write to it even if the standby has been promoted to the primary. To fix this Automatic Client Reroute can be used within WebSphere.

You need to make each DB2 server aware of the other so that when a client connects it knows how to reroute it should it fail. You need to run the following command on each server referencing the other in the command line.

./db2 update alternate server for database STMS using hostname db2.acme.com port 50000

Log in to the SSC and go to Resources – JDBC – Data sources. You will see a number of JDBC data sources, normally two for each Meeting node and two for the cluster.

Click on each (checking at the bottom of the page that it references STMS and not STSC) and then select “WebSphere Application Server data source properties” on the right hand side.

Under “DB2 automatic client reroute options” you have options of adding alternate servers and the ports they listen on. You configure your second database here. Make sure the changes synchronise with your nodes and that the applications servers are restarted afterwards.

If your primary database fails WebSphere will then connect to the alternate DB2 server as long as the alternate server has been made the primary.


Get every new post delivered to your Inbox.

Join 56 other followers