For organizations operating more than one messaging system, especially those as diverse as Lotus Domino and Microsoft Exchange, seamless messaging and calendaring coexistence between messaging systems is no longer a 'nice to have,' it's a 'must have.' The success of these initiatives is directly correlated to the experience of the end users and very often it's specific to how well the calendars work between users on different email platforms. Users can become quite vocal if meetings disappear from their calendar or they can't schedule a meeting because they can't look up the availability of the other users. As Vadim Gringolts discussed in his blog post last week on coexistence:
" ...users insist on perfect functionality of ALL calendar entries, complete and continuous synchronization of ALL directory entries, instantaneous and accurate free/busy lookup, and uninterrupted workflow of mail-enabled applications with their custom emails, forms, and approval buttons."
Keeping up with new software releases, features, and integrations is a constant challenge for IT Administrators. They need to be able to easily and efficiently perform smooth and seamless transitions from one platform/release/upgrade to another. Tack on the responsibility for establishing and maintaining interoperability between two different messaging systems, whether due to a merger, an acquisition, or a platform migration, and their job can quickly become overwhelming. Even so, it's vital that companies with differing email and calendaring systems are able to harmoniously coexist and that users are able to work without interruption.
So what should the end user experience look like when an organization is coexisting with Domino and Exchange? And what are the planning best practices for administrators to ensure that their hybrid environment is fully interoperable and their users are not disrupted?
READ MORE >>
by Robert Martin, Lead Principal Consultant
Introduction
Given the complexity of integrating Microsoft Exchange and IBM Domino environments in a cohesive coexistence solution, it’s not surprising that one thing Messaging Engineers struggle with is providing for Highly Available and Load Balanced designs in their coexistence infrastructure.
In the following post, I will describe the various techniques for providing both High Availability and Load Balancing in a coexistence design utilizing the Binary Tree CMT for Coexistence toolset. I’ll discuss the major components of coexistence and how each component can be configured to provide the necessary level of availability and throughput required by the customer. The major components are:
- Mail/Calendar Routing
- Free/Busy Connectivity
- Directory Synchronization
- Application Remediation
In some instances, providing for one need (such as load balancing) will naturally follow through with the other (high availability). In other instances, this will not be the case, and each need will have to be configured and will operate independently of the other.
Load Balancing and Fault Tolerance of Mail and Calendar Message Routing
This post will discuss setting up a load-balanced solution within a single Domino Domain. I will discuss leveraging it for multiple Domino Domains in a future post. Because CMT for Coexistence utilizes native transport protocols for both IBM Domino and Microsoft Exchange, the techniques for providing load balancing differ significantly depending on the direction of message flow. The following describes how to configure load balancing in each direction:
Domino to Exchange Message Load Balancing
In most coexistence scenarios, message traffic requirements and the duration that coexistence must be maintained does not warrant the use of more than one CMT for Coexistence Domino server acting as the messaging coexistence gateway. Other scenarios may require the deployment of more than one CMT for Coexistence Domino server to serve a Domino Domain.
An example of one such instance may be when the Domino environment is geographically separated by slow or saturated WAN links. If the corresponding Exchange servers are deployed to mirror the Domino environment, it may not make sense for a message from one site to traverse a slow WAN link in order to cross the coexistence gateway, only to have to traverse the same WAN link to be relayed to the intended recipient. This is extremely inefficient and a large amount of traffic can quickly overwhelm the link. Optimally, the message traffic should be relayed to a coexistence server within the same site as illustrated below.
Another scenario may be that the high volume of mail traffic necessitates the deployment of multiple Messaging Coexistence servers. Although a properly sized and configured Domino Coexistence server can easily process and relay more than 20,000 messages per hour, extremely large organizations can quickly reach this level of messaging traffic once they’ve migrated a large number of their users to Microsoft Exchange. In this scenario, a single Domino Coexistence gateway is not enough to handle the amount of mail traffic generated. Message traffic from mail servers in the environment needs to be balanced across multiple coexistence servers as illustrated below:
Both scenarios involve deploying multiple Coexistence servers within the Domino Domain and then directing a subset of mail servers to specifically use one of them and not the other.
Because
CMT for Coexistence requires that Notes routing (NRPC) be used between Domino mail and coexistence servers, deploying multiple coexistence servers requires creating multiple
Foreign Domain documents. Since there is no field within a Foreign Domain document to restrict its use to a particular mail server, and because the Mail Server field within that document does not support Domino Cluster or Server Group names, we must limit which Foreign Domain document is replicated to any given mail server.
Limiting the replication of a Foreign Domain document is accomplished by setting the '$Readers' field within the document to allow only specific servers to have read access to it. There are three (3) other standard readers fields on the Foreign Domain document that may allow a user or server to read the document. They are the:
- DocumentAccess
- LocalAdmin
- ListOwner
The DocumentAccess field is set to [NetModifier] by default. The LocalAdmin and ListOwner fields correspond to the Owner and Administrators fields on the Administration tab. Because all servers within a Domino Domain are members of the LocalDomainServers group by default, and that group is assigned the [NetModifier] role, it is necessary to change the DocumentAccess field to some other value to keep it from replicating to all servers in the Domain. Unfortunately, there is no direct way to edit this field, as it is not included on the Foreign Domain document form. A simple action agent can be written to adjust this field to another value, such as a distribution hub server.
The following steps describe how to deploy two (2) different Foreign Domain documents within a Domino Domain in support of the mail flow shown in the illustration above:
READ MORE >>