Automating best proximity and location-based connectivity for IBM Lotus Notes
In IBM Lotus Notes, end users are connected to wrong servers quite frequently (as long as you have at least a few servers and/or offices - if all your IBM Lotus Domino servers are in the same location and you don't care which servers your end users connect to, then this article isn't of much value for you ...). This is due to various reasons:
In addition, travelling and roaming users are always connected to the same servers, no matter how far they travel or roam - so if someone travels or roams from e.g. Europe to the US, s/he keeps connecting to pretty distant servers - leading to a troublesome, frustrating end-user experience.
We have come up with a solution to this connectivity problem with our client management solution panagenda MarvelClient:
MarvelClient allows you to define so called "Realtime Database Access Relocation Rules". These rules tell a Notes client to connect end users to certain targetservers for all or particular source-servers, directories and/or filenames and can be associated to IP-Ranges.
Example 1: Relocate any database access to servers with the certifier */acme to <ini:MailServer> - this generic rule relocates any traffic to any Domino server name that end's with /acme to the users mail server. The rule can easily be extended to - for example - only those databases that are in the mail directory.
Example 2: Relocate any database access to databases that are *not* in the mail directory to the nearest application server. The nearest application server can either be computed by an agent or simply be associated with a particular IP-Range.
Best of all, relocation rules dynamically adapt to an end users IP-address without having to restart the Notes client. So if a manager travels from location A to location B with hibernation, s/he is immediately connected to better servers in location B because s/he get's a new IP adress in the new location - without having to restart the Notes client.
With this optimization, end users are always connected to the best servers, no matter from where. Using IP-ranges, one can easily distinguish between different continents, countries, offices, and connection types, such as VPN, WAN and LAN.
There is much more to MarvelClient's realtime engine, such as relocating local database operations (access or creation), as well as restricting server-side or local database access, deletion or creation - independent from server configuration documents, Database ACLs and consistent ACLs - but more on this tomorrow.
If you have any comments on how you solve such problems in your Lotus Domino infrastructure from out of the box today, we'd be happy to hear ...
- When end users receive a database-, view- or document link for a replica for which they do not yet have a link on their desktop (regardless of whether they use bookmarks or not), the Notes client looks for a replica on the users mail server - since most companies have seperate mail and application servers, any application replica cannot be found on the users mailserver and the client continues as follows:
- The client then searches the catalog server (if no catalog server is specified in the users current location, it uses the users mailserver as the catalog server) for a servername for the replica to connect the end user to.
In most organizations, there is no catalog server and catalog.nsf on mailservers only contains mail-databases. Game over.
Other organisation may have a catalog server and/or all databases are listed in the mailservers catalog - still doesn't help, as the Notes client takes the first servername it can find in the catalog database (by alphabet) and connects the end user to exactly that server - and it does so for all end users that query the catalog for a servername to connect to. Game over, too.
Actually, this is much worse than "Game over" as end users are now connected to a wrong server pretty much for good - as soon as an end user has an icon on her/his desktop pointing to a server, the notes client will connect to exactly that server, no matter how many more database-, view-, or document links you send to the end user pointing to "better" servers. Bad, huh?
In addition, travelling and roaming users are always connected to the same servers, no matter how far they travel or roam - so if someone travels or roams from e.g. Europe to the US, s/he keeps connecting to pretty distant servers - leading to a troublesome, frustrating end-user experience.
We have come up with a solution to this connectivity problem with our client management solution panagenda MarvelClient:MarvelClient allows you to define so called "Realtime Database Access Relocation Rules". These rules tell a Notes client to connect end users to certain targetservers for all or particular source-servers, directories and/or filenames and can be associated to IP-Ranges.
Example 1: Relocate any database access to servers with the certifier */acme to <ini:MailServer> - this generic rule relocates any traffic to any Domino server name that end's with /acme to the users mail server. The rule can easily be extended to - for example - only those databases that are in the mail directory.
Example 2: Relocate any database access to databases that are *not* in the mail directory to the nearest application server. The nearest application server can either be computed by an agent or simply be associated with a particular IP-Range.
Best of all, relocation rules dynamically adapt to an end users IP-address without having to restart the Notes client. So if a manager travels from location A to location B with hibernation, s/he is immediately connected to better servers in location B because s/he get's a new IP adress in the new location - without having to restart the Notes client.
With this optimization, end users are always connected to the best servers, no matter from where. Using IP-ranges, one can easily distinguish between different continents, countries, offices, and connection types, such as VPN, WAN and LAN.
There is much more to MarvelClient's realtime engine, such as relocating local database operations (access or creation), as well as restricting server-side or local database access, deletion or creation - independent from server configuration documents, Database ACLs and consistent ACLs - but more on this tomorrow.
If you have any comments on how you solve such problems in your Lotus Domino infrastructure from out of the box today, we'd be happy to hear ...
Post a comment
Comment preview