How do you provide connection documents to your users?
For the purposes of this discussion, I'm temporarily stepping out of my typical role of " code monkey" and switching to my alternate (but equally important) role as system administrator. Having seen several different approaches to provisioning server connections in Notes, I'm curious how you approach it. Here are a couple examples of what I've seen in different environments:
- During workstation setup, the DNS address of the user's home/mail server is entered, establishing a connection to that server. From then on, attempts to access other servers rely on the ability of Notes to automatically request the destination server's address from the user's home server; as long as that server is accessible, the user doesn't need connections to any other servers, because their home server will tell them how to get there. NOTE: this only works if the home server can determine the destination server's address... if the user needs to get to servers not listed in the primary Domino directory (for example, servers in isolated test or development environments), this feature does them no good.
- During workstation setup, whoever is configuring Notes (or walking the user or a delegate through the process) manually defines connection documents to every server the user could ever possibly need to access. This precludes the need for the home server to be contacted to request an address the first time (per session) a new server is accessed, but if any server's network address changes, in addition to updating it in the Domino directory, the change must also somehow be pushed to all the users.
- When a user needs to access a server they don't have a connection for, an administrator sends them an email that includes a button that, when clicked by the user, programmatically creates the connection document. Typically, then, the admin doesn't know the user doesn't already have a connection until the user has already tried to connect and failed.
- When a user needs to access a server they don't have a connection for, they are instructed to enter the server's network address - instead of its name - in the "Open Application" ("Open Database", in versions prior to 8) dialog and click "Open", which automatically creates a connection document if they don't already have one. Hence, users don't need to be sent a new button each time they identify a new server they need to connect to; they just need to know its network address.
- Domino servers that are only used behind a firewall are named such that internal DNS (or WINS, or another equivalent) allows the Notes client to locate the server by its CN without even requiring a connection document. While this might lead to either Domino servers with ridiculous names the users have little hope of remembering (i.e. TNGATLDM37 might be the 37th Lotus Domino mail server added to a facility in Gatlinburg, Tennessee) in order to conform to an existing DNS naming convention, or require a compromise from the network staff (perhaps in the form of an alias mapping a "friendly" Domino name to a conforming name), this is my personal favorite. The users don't get the impression that Domino - or the network - is unreliable because they can't get to a server that they've never told Notes how to find, Notes doesn't have to query their mail server for a destination address every time they want to open an application on a server that they access infrequently, and neither admin nor user has to spend time configuring connection documents unless they're a remote user... and, while remote and offline access has long been a key strength of Notes/Domino, in the majority of organizations (in my experience, at least), the majority of users need neither.
What's your take on this? Are there other approaches you take to ensuring your users can find Domino servers? Are there specific reasons why you prefer one approach over another?
|
How do you provide connection documents to your us...
|
1 Scott Hooks Permalink You failed to mention (perhaps intentionally) a script in the PostOpen event of the mail file (which, BTW won't work in Notes 8 standard unless the script is placed in the inbox folder). Assuming that the user can at least get to their mail server or a server on which a replica resides AND that you are in the ECL, this gives you complete control to create, modify, and/or delete a user's connections, locations, etc. I bet you knew that, but were trying not to switch hats.
2 Tim Tripcony Permalink @Scott - this is true... and what I like about that approach is that, since the user is bound to open their Inbox eventually (assuming they're mail users), you can be sure their settings will be kept in sync because you're not relying on them to click something in a specific email - you can just update their settings to what they should be... with or without notifying them that anything happened.
The reason I didn't mention that approach is that I've actually
never encountered it "in the wild", so to speak. Many (though by no
means all) organizations are loathe to modify their mail template,
either because they've done so in the past and had subsequent
difficulty obtaining support from IBM, or have heard that others
have.