Today's blog post was originally posted on June 21, 2011 on Perry Hiltz's wildly popular blog, Domino Diversions. As most of you may know, Perry is a Solutions Architect at Binary Tree and a long-time
IBM Domino solutions expert. Today, Perry is heavily involved
in the success of Binary Tree's pre-sales, technical, and support teams, and focuses primarily on educating and supporting customers during their Microsoft Exchange migrations.
The thought of renaming a Domino Server is a daunting task at best. There are innumerable considerations to address when undertaking this task. There is the server security, groups, connection documents, mail-in-databases, access control lists, and not to mention the user desktop icons. As I continue to work with various organizations, the thought of Domino server virtual clustering has proven to be a way to simplify some of these processes.
The concept entails an Enterprise version of Domino. The administrator will still need to register a new server in the Address book. This will be the new name of the server. Then the next step is to create a cluster with the old server name, then the new server name. Once the cluster directory and cluster replicator tasks are initiated, the cluster directory database will contain cluster information for only the old server. 
The next step involves the creation of agents to scan all ACL’s to add the new server entry. Beware of roles, the agents will likely not associate the new server listing with any roles the old server had. Then connection documents to and from the old server need to be copied, and modified to use the new server name. Similarly group membership of the old server will require the new server to be added. Next will be to copy and paste, then modify all of the mail-in-database names. This will need to reflect the new server name. Once all of these aspects are in place, then the server’s Notes.ini can be modified to use the new server ID file for serverid= and keyidfile= to use the new server ID file.
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 >>