BinaryTree

by Joel Greenwell, Owner, Pearbrook Management Consultancy and Information Technology & Services Consultant

Binary Tree would like to welcome Joel Greenwell as our guest blogger. Joel is the owner of Pearbrook Management Consultancy in the United Kingdom and is an expert information technology and services consultant. Joel, along with Pearbrook, provides personal consulting services, and will works to help customers discover new business opportunities, reduce costs, and improve efficiencies wherever possible.

Clients always want to maximise the efficiency of their infrastructure, and this is especially true with migration projects to a new Exchange environment.

 

One particular project that I recently worked on started with a Lotus Domino environment that had 8TB of mail data, and the challenge was to migrate all 3,500 users to an Exchange installation that had only 4TB of storage in total. Before I go any further, the client was also implementing an archive solution on Exchange, so this wasn’t going to be an 

impossible exercise, but more of a clever execution of migration techniques and leveraging the capability of advanced features in the Binary Tree migration products. 

 

Knowing what Binary Tree’s software tools are capable of, I came up with the concept of SNAP and DELTA, a two-stage migration methodology that staged a partial migration of data to the new Exchange platform, and then at a later date allowed for the final cutover of the users and their remaining data. The SNAP stage of data migration focused specifically on migrating email content delivered to a users’ mailboxes up to 6 months prior to being switched over to Exchange and Outlook.

The DELTA stage of migration covered all the remaining mail, calendaring, and contact data and was performed when users were actually being switched between email environments.

 

Microsoft Exchange environments are dependent on log files for their operation, and when migrating large amounts of data, there are plenty of log files being generated.  SNAP migrations allowed us to manage the generation of log files, thereby ensuring Exchange was always available during the course of the DELTA migrations. 

The SNAP migration also allowed us to assess the performance of the new Exchange environment with live data, not only with the delivery of service to end users, but also impact of tertiary activities such as Indexing, Backup, Archiving, and Anti-Virus scanning of content. Thereby we could address any issues encountered with the Exchange environment and underlying architecture (Virtual Machines, Server Blades, SANs etc) with genuine data with no risk to the business.

 

There is no question; the requirements for seamless messaging and calendaring coexistence between Lotus Domino and Microsoft Exchange have kept pace with technology advancements. It seems that only yesterday users were satisfied with the ability to send simple emails and basic calendar invitations back and forth, and then, all of the sudden, virtually in a blink of an eye, it's all about full transparency. Users insist on perfect functionality of ALL calendar entries, complete and continuous synchronization of ALL directory entries (that's right, don't forget about Groups and Members!), instantaneous and accurate free/busy lookup, and uninterrupted workflow of mail-enabled applications with their custom emails, forms, and approval buttons. The scale of demands can only be matched by the creativity and ingenuity of the product creators with whom I have the privilege to work with everyday.  

To experience what our customers live through on a daily basis, Binary Tree runs a mixed Domino/Exchange environment (even better, a hybrid on-premises/Office 365 Exchange environment, but more details about it later). So, we’re certainly familiar with the most annoying limitations of coexistence between these complex and significantly different environments. One limitation that really had us pulling our hair out over the years was being able to add Exchange users to existing Domino repeating meetings. For example, imagine that a standing Domino repeating meeting called “Weekly Sales Pipeline Review“ has existed for a while. A new sales person joins the team, so he or she is added to the meeting - what can be simpler, right? Actually, if the new Sales person is using Exchange for mail and calendaring, it’s not simple at all. It so happens that when you add a participant to an existing repeating meeting in Domino, the new invitee just receives a series of dates instead of a recurrence pattern like "every week on Mondays". Notes can handle these pattern-less invitations, but Outlook cannot - it wants to know the original pattern. 


 

 

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: