Running concurrent Notes and Exchange systems introduces many risks, as well as limited interoperability. Microsoft provides the Notes Connector to assist with migration but recommends the tool not be used for long-term or permanent connectivity. In addition to Microsoft’s warnings, there are stability and scalability issues when using this tool, even in small to mid-size environments.

Companies are faced with several choices when determining how best to address their Notes-Exchange coexistence or migration:

Convert the applications to the Exchange environment	Costly and Difficult
Migrate mail to Exchange and web-enable the applications	Potentially Time Consuming
Risk a single point of failure with the Notes Connector	Risky with Limited Support
Discontinue the use of mail-enabled functions	Limiting by Nature
Or,
Migrate mail to Exchange while keeping groupware applications in Notes using SMTP as the message transport.

As a development and deployment organization, we understand the difficulty and costs associated with each choice, and have helped companies in these areas.

In this document, we will discuss the following topics:

1. Using SMTP vs. the Notes Connector as the message transport between Lotus Notes and Microsoft Exchange.
2. Synchronizing the Lotus Notes and Microsoft Exchange directories.
3. Providing the ability for Microsoft Outlook users to participate more richly in mail-enabled Notes applications without the Connector.
    

Understanding the goals

So let’s dive into the requirements for just a minute. What are our goals in long-term coexistence? Hopefully, you listed mail routing and directory updates, as those items are clearly critical. The ability for Outlook users to participate in mail-enabled applications might also be a strong objective.  For long-term coexistence, we suggest you focus on making the most critical components as failsafe as possible, keeping in mind the niceties in case time and budget allow for their incorporation.
 

SMTP is a Simple Transport

The Notes Connector does a nice job of synchronizing the directories. However, if the Connector is also configured (as it is by default) to conduct messaging, it becomes the sole transport for messages between the two systems.  This translates to a single point of failure for messaging between the Notes and Exchange environments.  The typical Connector configuration is as follows:

It is possible to configure the Connector to perform directory synchronizations without message routing, but the adjustment is kluge at best, and support becomes an even greater issue.  You also have to live with some limitations, including the lack of replication for group memberships.

By contrast, SMTP is a great message transport in a heterogeneous environment. Major software and service vendors, including Microsoft and Lotus/IBM support SMTP. If we off-load the message transportation to SMTP, we can get our systems to look more like the following diagram:

Using SMTP as our message transport, we can potentially setup each server to route mail independently, eliminating the single point of failure created by using the Notes Connector.

The next step is to create an internal SMTP routing system that will support the two internal systems (Notes and Exchange).
 

Splitting the SMTP Environment

Fortunately, we have multiple options for this task. The following are the options we have tested and used in production environments:

1. Use an Internet domain for Notes and another for Exchange. Perhaps your company is comprised of individual companies. In other words, the Notes environment collects Internet mail for company1.com and the Exchange environment collects mail for company2.com. This is the safest and easiest to configure.

2. Establish sub domains (an internal partitioning scheme) to identify each mail system. For example, notes.company.com could be used internally to identify the Notes users and exchange.company.com could be used (also internally) to identify the users on the Exchange system. The delicate areas are (1) internal naming structure and (2) how inbound mail will be processed. Many companies who use this strategy have a virus scanner or other SMTP server that scans and relays inbound mail.

A mapping table on this server would receive mail for steve@company.com, lookup the internal address of steve@exchange.company.com, and route the mail to the Exchange servers for processing. Also, these servers can be used to modify outbound mail, so if steve@exchange.company.com sends mail, the SMTP relay server would strip exchange from the address so that folks in the real world would see steve@company.com as the reply address. One drawback is that these mapping tables often require manual updates. The primary benefit is the ease at which multiple internal servers can share the domain name. We have worked with customers who have Exchange, Notes, GroupWise and various SMTP servers sharing the same domain by creating an internal partitioning scheme such as the one just mentioned.

3. Split the domain. Splitting the domain is tricky, but it provides a seamless border between multiple systems. In essence, the Exchange server will forward unresolved mail to the Notes system and visa-versa. There are several TechNet articles that describe this process from the Exchange perspective and similar documents on IBM’s web site for configuring this process to work with Notes. The routing process works as follows: 

1. Either system receives an inbound message that is not resolved to a local mailbox or person document.
2. The server then forwards the unresolved message to the IP address (of the other mail system) you specify in the Configuration document or SMTP settings.
3. The message is either delivered or a Non Delivery Report (NDR) is created.

The drawback to this option is that NDRs will be created by the alternate system, and this configuration is slightly more difficult to setup and support. This option also does not support as many internal systems types as option 2. The benefit is that everyone in the company can share the same company.com address for internal and external messages.
 

Directory Synchronization

If you use the default cc:Mail or Notes Connector to synchronize the directories, the systems do not use SMTP for message routing. Because the addresses are created with the Connector, they are configured to use the Connector as the transport. Correcting the addresses requires manual or scripted intervention.  To avoid this complication, Pro Exchange offers a service called DirSync! 

DirSync! is a process whereby your individual directory replication needs are examined, and a custom directory synchronization tool is provided.  DirSync! allows you to exchange directory information between the Notes and Exchange environments. Not only will it keep the user information in sync, it will also maintain groups and group memberships.

DirSync! is not a meta directory service, as it was designed solely for the purpose of connecting Notes and Exchange directories, including Active Directory. It is flexible enough to allow you to force the specific routing domain you want to use. DirSync! can be configured to maintain the current SMTP directory per user or to force a mail domain to be used for each system. For example, in a migration scenario, you may want to represent the NOTES addresses as @notes.company.com instead of @company.com. Routing for fictitious as well as legitimate domains can be controlled through each environment’s SMTP settings.
 

Providing Continued Access to the Mail-enabled Notes Applications

Because of the cost of converting Notes applications to Exchange and the potential time it takes to web-enable existing applications, many companies plan to maintain their Notes development investment during the migration or indefinitely. It is for these reasons that Pro Exchange developed CoExist!

CoExist! is both a tool and an analysis process.  The tool replaces (or adds to) your existing LotusScript and Formula language that appends DocLinks to messages, instructing your application to send an alternative to DocLinks for mail-enabled applications. The file attachment that is sent can be launched from Outlook or Outlook Express to open the database and document using the locally installed Lotus Notes client.  This process does not only work with Outlook and Outlook Express, it also works with virtually any mail client, including the Notes client, as long as any intermediate mail routing gateways preserve file attachments.

In order to properly configure CoExist!, your current applications must be analyzed to determine how many and which type of application changes must be made. Once the required changes are identified (using an automated utility) and a tiny component is installed on each server, a Pro Exchange consultant can assist your development team with modifying the applications to use the component instead of, or in addition to, DocLinks.

Note Because of the analysis aspect of the CoExist! process and the proprietary nature of the automated data collection utility, a Pro Exchange consultant must perform this analysis.

Pro Exchange will analyze your applications and train your development staff on the process. The analysis process can take several days depending on the number and complexity of the applications. Once identified, most application changes can be modified in under an hour.