E-Pro: Sys Admin Newsletter Jul 2004
Tags :E-Pro Articles
Chris's 0.0606584 BRL
Deep breath here as the first newsletter is over and you have not complained
to me about content. So we are off and running together on what will
be, as I mentioned in the inaugural newsletter, a wide topic array.
I spent about four days this month at a new customer site working on a
project. What I discovered while there was a lesson we should all
learn from. It deals with company mergers and integrating two Domino
systems. I watched this from a distance (as my project was not part
of the merger) as they had meetings, conference calls and invested incredible
amounts of time in talks over management of the systems. Now you
might be saying to yourself this is common and has to be done. You
are absolutely correct. Except for the fact that the two organizations
had entirely different models for security and administration in Domino.
This left one group dissatisfied no matter which direction got chosen.
It seemed that no one wanted to give in and cooperation would not
be easy to make the changes.
So the lesson I took away was that your security, architecture and deployment
plans should have been well documented and presented to each other already.
Each team should have reviewed the others in advance to see where
they could come together and make changes or concede. Harmony would
take some time, but at least singing the same song would be a great start.
Choosing the Right Directory for Sametime
If you are just getting into installing Sametime (Lotus Instant Messaging
and Web Conferencing) due to business demand or simply because they offer
the chat services free, making the directory choice on installation is
a more important decision that you may think. The easy solution is
to simply choose the Domino Directory as the source for your user information,
add a home Sametime server to the person document and be on your way to
endless hours of chatting with co-workers on what is for lunch today.
But your other option, LDAP, is far more powerful and has greater reach
later. One key portion to choosing LDAP is if you plan to integrate
Sametime with Quickplace or any of the other extended products. LDAP
is now a requirement for awareness in the recent releases. In older
versions, you had some manual work to do replicating databases (stauths.nsf
for example) and manually copying some system level files to get it to
work. Now LDAP allows you to bring all types of systems together
for authentication and presence awareness. If your organization has
Active Directory users not in Domino or simply a customer and partner directory
that can serve LDAP (even their own at their site), you can now offer and
integrate that service into numerous applications and website pages. Imagine
your partners that log into a special part of your website being able to
see you on-line and have secure messaging not over public networks as many
of you do now? Sounds like a dream right? Not anymore.
A few things to mention though. Your LDAP directories should contain
a home Sametime server field for authenticating users. This can be
done simply by extending the schema of any directory. (This link
gives an example on how to extend Active Directory schemas http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnactdir/html/adschemaext.asp
). Second is that you should select a standard field that will
be used for authentication across all the directories. Whether it
is the shortname (uid in many systems) or email address itself, a common
schema across all the directories will make your management easier.
FROM A READER: If we have multiple Sametime servers and do a calendar invitation,
can each user attend on their own home server?
This is a dual sided question. Yes each user could attend the meeting
on their home Sametime server. But it is how the meeting is set up
that is important here. Using the standard calendar invitation that
now includes the ability to establish a live Sametime session, it would
only create that meeting on the home Sametime server of the chairperson
of the meeting. This would not then propagate out to all the other
servers as you desire. However, creating a meeting in advance on
your home Sametime server, inviting all the necessary other servers that
people can attend from and then including that meeting link in your calendar
invitation would get the result you desire.
Vpuserinfo.nsf and multiple servers
While at the client site I mention in my 0.0606584 BRL I was
working on the theory (and live production in place) of multiple Sametime
servers. One interesting thing to note is the vpuserinfo.nsf database
that stores all the user buddy lists. I was asked about clustering
the database and had to go look up the Lotus answer for this on whether
they suggest or support this approach. Here is what I found and thought
I would share this since so many companies are finding Sametime a business
necessity tool.
Technote #1171770
It is not recommended that the vpuserinfo.nsf database be replicated unless in a clustered environment where Domino clustering is setup so that the vpuserinfo.nsf can be replicated in real-time. Replicating vpuserinfo.nsf outside of a cluster is not supported. Additionally, even in clustered environments, the vpuserinfo.nsf should be replicated within a cluster only.
In a multiple Sametime server environment, it is recommended that the user's Sametime Server field in their Person document is populated. Once that field is populated, users will always be re-directed to their home server so there is no need to replicate the vpuserinfo.nsf, as the user will always connect to the same server every time.
blog comments powered by Disqus
On Thursday, July 8th, 2004 by Chris Miller
