Thursday, December 27, 2007

Sametime Directory Decision

As I mentioned in my previous post I am in the process of designing a Sametime infrastructure for our environment. I think the biggest and toughest decision when designing Sametime is the directory decision. Based on Chris Miller's repeated statement to use LDAP as the access method this is an easy choice but the question is, which LDAP directory? We have 2 in our environment, AD and Domino, and they are not synchronized.

When deciding on a directory I had a few deciding factors; which password will be used, which groups will be accessible, and ease of directory administration going forward. We don't currently use the Internet Password field in Domino for anything. This means if we use the Domino directory we can populate this field with anything we want. At first I thought we should use AD so we can use the Windows password for authentication but the down sides to AD were; not able to easily manage Sametime information within AD, Sametime would be limited to only seeing AD groups and getting the infrastructure team to extend the LDAP schema. With the Domino directory most of the Sametime info for a user is already there and the e-mail groups would be the most logical groups for Sametime to use. However, there is the issue with what password to use with the Domino directory.

When using the Internet Password field in the Domino directory I have 3 options; enter a completely separate password in the field (last choice), use the built-in functionality in Domino to synch the Notes ID password with the Internet Password field or use a 3rd party product such as Tivoli Directory Integrator to synch the Windows password with the Internet Password field.

I'm currently leaning toward using the Domino directory with the native Notes ID password synch option since it doesn't require any additional cost or infrastructure.

Anyone using the native Notes ID and Internet password synch function in Domino? Is it reliable? How about other password synch options for Sametime use?

Thursday, December 13, 2007

On to the next project...

We are finally starting to plan for a Sametime implementation within our organization. It has been on the back burner for a while waiting on other projects and is now moving forward. I'm still in the research and planning stage but have an initial conceptual diagram done. Hopefully this post and future ones can help people who may be going through the same process in the future.

I have been attending the Sametime sessions given by Chris Miller and Carl Tyler at the ADMIN conference for a few years now as well as pouring over the manuals and the Sametime 7.5.1 BP redbook. This has provided a lot of help getting started but there are still some organization specific questions that need to be answered. Below and in future posts are some decisions we had to make up front. Some have been decided and some are still be thought over.

Overall Sametime network design
Our organization tends to be overly redundant so I set out planning the Sametime network with redundancy in mind. I think it will take off once we implement it and will eventually become a business (if not mission) critical application. We have multiple offices worldwide but have been centralizing most applications in the Chicagoland area with high speed WAN links to the offices.

The conceptual diagram I came up with has 2 Sametime servers clustered in the Chicago area and 2 Sametime servers clustered in London. I also have Multiplexers positioned in each local office because I like the idea of keeping the user connections local and having a single connection to the Sametime servers over the WAN. The Sametime servers will connect to load balancers for connections to multiple LDAP servers for directory lookups.

A single Samtime server can more than handle our entire user base (~3500 users) but as I mentioned earlier we are all about redundancy and response time. This setup still has a single point of failure with the Multiplexers but I thought load balancing multiple MUX's in each office would be a little over the top even for us.

This setup is only for chat (IM) services and not meetings. We will add separate meeting servers in the future for online meetings.

I'll have additional posts regarding directory and OS decisions shortly.

Wednesday, December 5, 2007

Upgraded to Notes 8 client

I went ahead and upgraded to the Notes 8 client a few days ago without upgrading my mail template or the server. I was pleased to discover the things Notes 8 brings to the table just by installing the client itself. Using Notes 8 with the R7 mail template you still get in-line spell checking, drop down type-ahead, and my favorite, the ability to shift-click multiple documents. As an administrator I can't tell you how many times I have longed for the ability to shift-click when selecting hundreds or thousands of documents. I'm sure there are other features there but these are the ones I notice most.

I did have to get used to looking for the term 'Application' versus 'Database'. I also long for the return of the right-click option 'Open in designer'.

The client has been stable except for the one crash I experienced when switching to a different Location/ID and then back to the original Location and ID. It does seem a little slower to load the standard client but once it's up it works well. Our R7 mail template has integration with Interwoven WorkSite which still works with the Notes 8 client.

As for our organization, we are waiting for 8.0.1 to seriously look at upgrading but I wanted to get a jump on the client features. Upgrading our mail template will be interesting as we have integration with multiple 3rd party products.