Glen Urban May 19 2011 02:02:02 PM
When you generate emails with doclinks are users complaining it takes them to a server on the other side of the world? If so, take a look at the Catalog on the server specified as the "Catalog/domain search server" in your Location Document. Look at the "Applications by Title" view. Are there multiple servers listed for the application (database) where the doclinks came from? This could be a problem...
What Should Happen With DocLinks?
from IBM lists the steps Notes takes to determine which server to use:
1) Use the icon for the replica on the user's workspace if one exists.
Assuming the user hasn't opened the application before then they won't have an icon on their workspace so the search goes to step 2.
2) If using Catalog/Domain Search, this will be used to locate* a replica.
This is further qualified by the statement: The search will open the catalog and find the "best" server choice containing a replica, searching by server name alphabetically. The best choice considers server availability.
A Potential Problem
When the search gets to step 2 you may be using, for example, server "USA1" but if the first server under your application in the "Applications by Title" view is called "AUSTRALIA1" then the doclink will be opened on AUSTRALIA1. I've also seen this cause embedded views to open on the wrong server and @DBlookups, where the database was specified using a replica ID, to lookup to the wrong server.
What about the statement The best choice considers server availability
? The technote doesn't elaborate on how Notes evaluates "availability". I suspect it chooses the first server in the same Notes Network. In the organisations that I've come across this problem all the servers we're in the same Notes Network (which is probably not recommended).
How Can I Fix It?
I resolved this by re-configuring the catalog to show only applications that have replicas on that server. For example, on server USA1 the catalog would only list replicas found on USA1. So when the Notes client looks for the location of an application in the catalog (step 2 above) it will always return a replica on USA1. In a typical Hub and Spoke topology this can be achieved using the ACL of the catalog. On the spoke servers, e.g. USA1, I ensured the Hub server is restricted to reader access and USA1 had manager access. This prevented the Hub server from adding entries to USA1's catalog but allowed it to read them and compile a full list of all applications, and their servers, on the Hub.
This solution resolved the issue for new users, or existing users opening applications they hadn't used before. But it didn't resolve the problem where users already had icons on their workspace that point to the wrong server. In this instance you can write code to re-stack the workspace icons, for example, something like this
from Tommy Valand.
A Word of Warning About Testing
If you delete all the workspace icons for an application and then change the catalog server specified in your Location Document then you may think that Notes should start looking in the new catalog. But it doesn't! Even if you delete desktop8.ndk and bookmark.nsf Notes will still remember where it's been before.
If you look at the document properties for your Location Document then you'll find several fields that are used for caching e.g. $LastFileNames and $StackFileNames. There's all sorts of caching going on in there. So it's best to delete desktop8.ndk, bookmark.nsf and create a new Location Document. This does make testing a pain!