I have had quite a lot to do with roaming. In the company in which I am responsible for the Domino administration and Domino environment we introduced roaming as it came in the early N/D 6 release (I was not employed at that time). It was not implemented quite by the book so consequently it didn't work as it should.
I have read a lot of information about roaming and have come to the understanding that not too many companies use roaming as roaming should be used. All of our employees move around the office using a different computer every day. I believe the roaming feature was released too soon. There are still things that don't work in a logic way and I will talk about roaming and my/our experience of roaming from time to time.
But for now let me just give you facts about roaming that I know at least two very experienced Domino administrators didn't know of. Maybe you have missed it too...
- The user id located on the client (usually in Document & Settings/
/Local Settings/Application Data/Lotus/Notes/Data/) must be named "user.id" with lower case letters - Three databases are sent to and from the server during the roaming, that usually takes place when starting and when shutting the client down. These are names.nsf, journal.nsf and bookmark.nsf). names.nsf is the personal addressbook. When roaming down to the client these databases are copied to the directory mentioned above together with the user.id and other local stuff.
In the personal addressbok located on the server (the roaming folder), the user.id is attached with double encryption. You can take a look at it using for example notespeek and actually even see some information about the id.
It is important to remove the user id from the person document to make the roaming work correctly, but before doing that make sure the id has been copied to a safe location or at least be sure that it has been attached to the personal addressbok or else the roaming will not work.
2 comments:
If the password is somehow changed on the id on the server in the address book (just assume you can - we want to automate this) - will it pass down to the client machine on replication? I am wondering if a change happens to the id on the server, does it overwrite the local user.id with that change or is it only if changed on the client, it pushes onto the nab and thus up to the server?
I have not tried this myself, but I can give you my guesses.
My thoughts and discussion are as follows:
- Changes made to any of the roaming databases directly on the roaming server; names.nsf, bookmark.nsf or journal.nsf will overwrite the settings in the clients when logging on and replicating these down to the clients. We have tried this several times either manually or by using agents for example when changing settings in the location document in the personal nab for our roaming users.
- When the feature is turned on the id is attached to the personal nab and thus treated as a part of that database.
- Any changes made to the user's local id file (via the Notes Client), such as importing new certificates or changing the password, is automatically replicated up to the roaming server as a part of that database (that is the attached id file contains the changes). When the user after this comes to another client machine the latest changes, residing on the server, are replicated down to the client overwriting any old settings saying otherwise.
Having this in mind it is my guess that a change made to the id on the server level works the same way as changing a roaming database on the server level, that is the changes made to the id on the server level will overwrite local id file settings. However it might be a problem making those changes to the id since it is double encrypted when attached to the personal nab.
Hope this helps and please let me know the results if you try it out!
/ Nick
Post a Comment