Victor Toal April 24 2008 12:12:03 PM
I am working at a client currently that is doing some interesting things with Sametime. We are creating a new Sametime environment to replace their current one instead of upgrading it. The reason is that we are jumping two versions and we wanted to use a totally new Domino domain to make sure that there is no garbage left over and we can be sure the of the chain of custody of the Domino cert IDs etc. This creates some unique challenges and some issues you have to be aware of, especially when dealing with buddy lists and changes in community configurations. In this document I will be concentrating on the buddy list theme and what to watch out for.
VPUSERINFO.NSF – what is it and how does it deal with buddy lists? The vpuserinfo.nsf is simply a database, it really has no direct relationship to what the community is set in an environment but rather which server it resides on and where the user is logging into.
You could replicate the vpuserinfo.nsf between servers that are members of multiple communities, it then will simply contain the buddy lists of both communities. It gets a bit more complicated if you have a scenario like the one I am in where the names in both communities are the same.
Note: replicating the vpuserinfo.nsf between communities is not a configuration supported by IBM
Scenario 1:
Environment: - One vpuserinfo.nsf database replicated between server A, server B, server C and server D
- Server A and B are member of community 1,
- Server C is member of community 2
- Server D is member of community 3
Users: - Joe Shmoe is member of community 1 using address < joe.shmoe@domain1.com>
- Jack Flack is member of community 1: and community 2
- Mary.Barry is member of community 2 and community 3
note: both community 2 and community 3 use the same addresses for authentication (it does not necessarily need o be the same directory).
What happens: - Joe Shmoe has 1 buddy list document in the vpuserinfo.nsf
- Jack Flack has 2 buddy list documents in the database, each is used only when the corresponding community/address is used for log-in
- Mary Barry has only one buddy list document because she uses the same name in both communities. She will have issues with inconsistent awareness to and from other users in this case.
Synapsis: Normally, vpuserinfo.nsf databases are not replicated between separate ST communities and to do so is not a supported configuration. It is sometimes done in times of cut-overs or upgrades but usually never otherwise. I only brought this up to demonstrate how it is just a container that relies on the server it is on and contains buddy list documents that relate to specific account names that log in. It really has no other function and is quite dumb.
Name changes etc. are done by outside programs simply use the vpuserinfo.nsf as a container in which they look for specific names to run specific functions against. This is also where problems can arise as name changes and OU changes could be run against wrong entries, which is why replicating vpuserinfo.nsf files between different communities is not supported.
Scenario 2:
Environment: - One vpuserinfo.nsf database is not a replica, all servers have their individual vpuserinfo.nsf
- Server C is member of community 2
- Server D is member of community 3
Users: For simplicity’s sake, we will look at Mary only:
- Mary.Barry is member of community 2 and community 3 >
note: both community 2 and community 3 use the same addresses for authentication (it does not necessarily need o be the same directory).
Log-ins: - Mary user her client to log into BOTH communities at the same time. She always logs into community 2 first and then into community 3
What happens: - Mary Barry has only one buddy list document on server C/community 2
- Marry will not have a buddy list on server D/community 3
Why? This is easy to understand once you know how the buddy list gets created and when. I will keep it simple here, it is much more complicated but we don't need all the back-ground information for our level of discussion:
A buddy list is created when the user logs into a server/community for which it has no list yet. The client will send the server a request to hand over the buddy list. If there is none there, then the server creates one on the fly and this list will be empty. There is some more stuff that goes on when the entries in the lists are different, but we will ignore that for now.
Now, if the servers in both communities resolve to the same directory (or at the least use the same account names for authentication) AND Mary ALWAYS logs into community 2 first and then into community 3 after that, the Sametime connect client will have a buddy list it considers to belong to it's user's name and will not request one from the server in community 3. Ergo, the document is never is created on server D.
This is where all the gotchas will start happening: - If sever C is ever down, a new buddy list will be created on server D.
- If the log-in order changes, a buddy list will be created.
- If the community settings change (community cluster membership, Sametime server entry in the LDAP account for Mary changes, etc.) then buddy lists will be created
The gotchas go on and on for this. You can see why this is confusing and will create problems down the road. Buddy list changes will not be consistent as the clint will become confused. Buddy lists will revert to older versions from time to time, they might become empty, name changes of buddy list entries will be inconsistent (as far as the end-user is concerned) etc., etc., etc. …….
Conclusion:
Don’t have separate Sametime communities that use the same directory or even just the same name structure and identical names and have your users be members of both. You will see all kinds of problems arise. The buddy lists are just a start, policy documents will do a whole other number on your users and you will not like the outcome. Actually, you will like the outcome even less than your users because they will be screaming into your ear and be stalking the hallways holding axes and they will be looking for you!
When doing upgrades or cut-over scenarios it is important to think about these kind of issues and think your strategy through very well. You can probably take care of these issues for a small number of test users, but only if these users have been forewarned. Make them make local back-ups of their buddy lists on a regular basis so they don’t lose everything. Losing a large buddy list is akin to losing cell phone for many Sametime users - they are lost without it.
