Automatic rule-based database access relocation and restriction in Lotus Notes
by florian vogler :: Lotus Notes Client Management
I promised yesterday to post some more details on panagenda MarvelClients realtime Lotus Notes client - or rather connectivity - management feature.
The business cases for the features described today are:
(We haven't found a way to do this from out of the box with Lotus Notes / Domino - this is not about bluntly advertising panagenda MarvelClient, but documenting real-world needs for client management and control in Lotus Notes / Domino environments. If you think this feature isn't really needed in your environment, or know of cool alternatives from out of the box, or have a great idea on how to take the realtime control feature of MarvelClient even further, please post a comment!)
Business case #1: Relocating end users to a local replica no matter how hard they try to open a corresponding serverside replica
This is not as easy as it may seem on first sight, because relocating all database operations from a server to local raises the following issues:
You shouldn't relocate database deletion or creation. Imagine wanting to delete a database on server x and the relocation rule deletes your local replica (or a replica on a different server) - fun!.
If you relocate all (nrpc) traffic, the background replicator can't replicate anymore (it would replicate local with local). So you need to explicitly relocate everything except for the background replicator.
MarvelClient can easily distinguish between Notes component (Replicator vs. Notes Client UI), connection types (e.g. LAN, WAN, VPN) through e.g. IP-Addresses, Laptop, Desktop and Citrix workstations without the need for any groups or specific environment variables (such as identifying a Laptop based on the computer name; but more on this in one of the next posts) - these are just a few examples of what can be used to create your own rules on when an end user should be relocated to a particular, best server or local replica.
Business case #2: Ensuring that end users do not delete (any or specific) local databases.
Ok, that's a "relatively easy one", as you just block database deletions based on certain file criterias through the Notes API; btw: all described realtime relocation is also done through the Notes API, although that's far from being easy ...
Preventing the deletion of local databases (local including databases on a network drive within Citrix, for example) can save you a tremendous amount of helpdesk calls.
You can even prevent the deletion of server-side mailfiles to which users have Manager access - and preventing local database deletion also does not require a consistent ECL.
Business case #3: Ensuring that end users do not create local replicas on network drives.
(Some) end users think that creating a local replica on a network drive is a good idea, as "it's being backed up then" and/or "I've then got a local copy" and/or "it's faster then" - wheeee, if access to a SAN/NAS is faster than to your Domino servers, something's wrong, I guess.
I'd assume that Domino databases are being backed up on the server, so it won't be backed up any better on a network drive, will it? - just redundantly.
A "local" replica on a network drive actually kind of doubles traffic in a Notes environment as the end user replicates the database to the network drive and then accesses the database "locally" on the network drive.
This is not just a pain in Citrix environments, where end users shouldn't create any local replicas at all in my opinion, but in any environment where people can (and do) create replicas on network drives.
MarvelClient can detect whether the target of a database operation (delete or create) is a network drive, so you don't have to enter all your drive letters that point to fixed disks (which can differ, by the way, across all your end user clients). What's more, you can even seamlessly relocate the creation of databases on network drives to a local fixed disk automatically, so that the creation does not fail but works just fine for both the end user and administrators/helpdesk staff.
Last but not least, traffic relocation in Notes not only spans desktop icons, bookmarks and/or replicator page entries, but also redirects traffic generated from LotusScript or Java code, as well as from inside composite applications. If you only repoint the link to a composite application in Notes 8, the entire connectivity inside remains untouched, as it's design and not configuration that determines the connectivity inside of a composite application (I'm only referring to NRPC stuff here, NOT SAP, DB2 or whatever non-Notes connection a composite app might initiate).
The benefit to realtime Notes traffic control (or is that a kind of traffic shaping?) is that you better, optimize the entire traffic between both Lotus Notes clients and Domino servers, as well as Lotus Notes Clients and "local" storage, where local includes network drives, too.
The only potential shortcoming of "all or nothing" traffic relocation for a given database is just that: You cannot have Script or Java code connect to replicas of the parent database on other servers than what is defined for the respective database.
I have, however, not yet come across a situation where that could be a problem - can you imagine a situation where you'd want a database to do lookups to a replica of itself on a different server than the one it is actually being accessed on?
If you have any ideas on how to take the idea of realtime database access/operation relocation and/or restriction even further, we'd be happy to hear!
The business cases for the features described today are:
(We haven't found a way to do this from out of the box with Lotus Notes / Domino - this is not about bluntly advertising panagenda MarvelClient, but documenting real-world needs for client management and control in Lotus Notes / Domino environments. If you think this feature isn't really needed in your environment, or know of cool alternatives from out of the box, or have a great idea on how to take the realtime control feature of MarvelClient even further, please post a comment!)
- Ensuring that end users access nothing but a local replica for certain databases, in certain locations, or with certain connection types (e.g. WAN).
Even if you could change the links on the desktop for a given replica stack to a local icon only (which you can with MarvelClient), this would still not prevent end-users from directly opening a server-side replica. - Ensuring that end users do not delete (any or specific) local databases
- Ensuring that end users do not create local replicas on network drives - a pain not just in Citrix / Windows Terminal Server (WTS) environments, but any infrastructure where end users use network drives
Business case #1: Relocating end users to a local replica no matter how hard they try to open a corresponding serverside replica
This is not as easy as it may seem on first sight, because relocating all database operations from a server to local raises the following issues:
You shouldn't relocate database deletion or creation. Imagine wanting to delete a database on server x and the relocation rule deletes your local replica (or a replica on a different server) - fun!.
If you relocate all (nrpc) traffic, the background replicator can't replicate anymore (it would replicate local with local). So you need to explicitly relocate everything except for the background replicator.
MarvelClient can easily distinguish between Notes component (Replicator vs. Notes Client UI), connection types (e.g. LAN, WAN, VPN) through e.g. IP-Addresses, Laptop, Desktop and Citrix workstations without the need for any groups or specific environment variables (such as identifying a Laptop based on the computer name; but more on this in one of the next posts) - these are just a few examples of what can be used to create your own rules on when an end user should be relocated to a particular, best server or local replica.
Business case #2: Ensuring that end users do not delete (any or specific) local databases.
Ok, that's a "relatively easy one", as you just block database deletions based on certain file criterias through the Notes API; btw: all described realtime relocation is also done through the Notes API, although that's far from being easy ...
Preventing the deletion of local databases (local including databases on a network drive within Citrix, for example) can save you a tremendous amount of helpdesk calls.
You can even prevent the deletion of server-side mailfiles to which users have Manager access - and preventing local database deletion also does not require a consistent ECL.
Business case #3: Ensuring that end users do not create local replicas on network drives.
(Some) end users think that creating a local replica on a network drive is a good idea, as "it's being backed up then" and/or "I've then got a local copy" and/or "it's faster then" - wheeee, if access to a SAN/NAS is faster than to your Domino servers, something's wrong, I guess.
I'd assume that Domino databases are being backed up on the server, so it won't be backed up any better on a network drive, will it? - just redundantly.
A "local" replica on a network drive actually kind of doubles traffic in a Notes environment as the end user replicates the database to the network drive and then accesses the database "locally" on the network drive.
This is not just a pain in Citrix environments, where end users shouldn't create any local replicas at all in my opinion, but in any environment where people can (and do) create replicas on network drives.
MarvelClient can detect whether the target of a database operation (delete or create) is a network drive, so you don't have to enter all your drive letters that point to fixed disks (which can differ, by the way, across all your end user clients). What's more, you can even seamlessly relocate the creation of databases on network drives to a local fixed disk automatically, so that the creation does not fail but works just fine for both the end user and administrators/helpdesk staff.
Last but not least, traffic relocation in Notes not only spans desktop icons, bookmarks and/or replicator page entries, but also redirects traffic generated from LotusScript or Java code, as well as from inside composite applications. If you only repoint the link to a composite application in Notes 8, the entire connectivity inside remains untouched, as it's design and not configuration that determines the connectivity inside of a composite application (I'm only referring to NRPC stuff here, NOT SAP, DB2 or whatever non-Notes connection a composite app might initiate).
The benefit to realtime Notes traffic control (or is that a kind of traffic shaping?) is that you better, optimize the entire traffic between both Lotus Notes clients and Domino servers, as well as Lotus Notes Clients and "local" storage, where local includes network drives, too.
The only potential shortcoming of "all or nothing" traffic relocation for a given database is just that: You cannot have Script or Java code connect to replicas of the parent database on other servers than what is defined for the respective database.
I have, however, not yet come across a situation where that could be a problem - can you imagine a situation where you'd want a database to do lookups to a replica of itself on a different server than the one it is actually being accessed on?
If you have any ideas on how to take the idea of realtime database access/operation relocation and/or restriction even further, we'd be happy to hear!
Post a comment
Comment preview