Monday February 09 2004

FreeEmailMigrations.com

WHAT'S NEW

ABOUT

• Purpose & Concept
• History
• Why?
• Disclaimer

SOFTWARE

• Rocket
• Spark
• GroupWise Bulk Migration Tool
• Tools

DOCUMENTATION

• The Basics
• THE ULTIMATE ROCKET GUIDE!
• Rocket Configuration Guide
• Rocket End User Guide
• Rocket Sales Kit
• Rocket SOW
• Rocket Project Plan

KNOWLEDGE

A MIGRATION PRIMER
• A Migration Primer
• Messaging System Deployment Guide
• Migration Strategy Guide
• Coexistence Strategy Guide
• Migration Process Guide
• Migration Issues Guide


MIGRATION STUFF
• Example Migration Checklist
• Example Migration Jumpstart Guide
• Example Migration Roadmap
• Example Best Practices

RESOURCES

• Open Cranium
• IT Ethics Newsletter
• infonition

Coexistence Strategy Guide

Introduction

If the migration strategy involves coexistence, then the level of coexistence desired between the legacy email system and the new email system must be determined. Coexistence deals with how integrated the two email systems are during the interval of migration. The level of coexistence can range from none to complete coexistence of the directory, messaging and even calendaring. Organizations can pick and choose to implement specific coexistence features within this range of options.

Directory

Directory coexistence between the new messaging system and the legacy messaging system is extremely important. An accurate and complete directory is essential to ensure that users can effectively communicate with one another and to ensure address fidelity. There are several strategies for directory coexistence during migration including:

• Periodic Refresh
• Dual Administration
• Drectory Connectors
• Dual Client Address Books

Quick Tip: Seriously consider NOT using directory synchronization products. Instead, use disconnected directories and create a quick dual administration system. Directory synchronization software takes control away from the migration process and basically causes nothing but headaches. Absolute control over all aspects of the migration process is so fundamental, especially in terms of timing to avoid bounced messages (NDR's), that it is almost never a good idea to relinquish control to a secondary, automated process such as directory synchronization software.

Periodic Refresh

Periodic refresh assumes disconnected directories. Under periodic refresh, modifications are handled in batch by removing and then completely rebuilding the directories entries for each foreign system. That is, the new messaging system has a list of all “foreign” e-mail addresses, the e-mail addresses of users still on the legacy messaging system. In turn, the legacy messaging system has a list of all “foreign” e-mail addresses on the new messaging system. These foreign address lists are completely removed, new exports taken from the respective systems and then imported into the corresponding messaging system. Periodic refresh frequency will vary depending upon the frequency of changes in the systems but generally does not happen more frequently than once per day.

Dual Administration

Dual administration also assumes disconnected directories. Under this strategy, the foreign mail system directories are loaded into the respective systems once. After the initial load of the directory entries, the two directories must be kept in sync with the changes made to one another’s directories. For users being migrated between the systems, this is typically performed as part of the migration process. For new users, the removal of users or changes to existing users, this is accomplished through dual administration of the systems, meaning that the operation of creating a mailbox, removing a mailbox or modifying a mailbox is performed manually on both directories or via a central directory or process created specifically for this purpose.

Quick Tip: For a cheap, easy way of performing dual administration, consider using a Microsoft Access database. Just export the directories and load them up into a table or two. A little VB scripting and presto, a quick, easy and cheap dual administration system.

Directory Connectors

Directory connectors automatically synchronize directories between two systems. Directory connectors provide the advantage of bi-directional synchronization such that administrators can make modifications from either directory system and the changes automatically propagate to the other directory. This involves the use of third-party software or native tools to run a process that automatically keeps the two directories in sync with one another. Under this scenario, the tool takes care of the initial directory load and automatically synchronizes changes that occur within the two directories.

Most modern messaging systems provide connectors to one another that are designed to perform this function. It should be noted that while synchronization tools reduce the manual effort involved in keeping both directories in sync, it generally has a negative effect on the email migration process because it takes away absolute control of the migration of end users from the migration process. Essentially, the migration process loses control of when and how updates to the email directories takes place and must work around this automatic update process. In some circumstances, this can pose significant issues for the migration process.

Dual Client Address Books

Another interesting method of achieving directory coexistence is to install an address book provider for each directory on the email client. Most modern email clients support this kind of thing but this generally requires software deployment to the client and starts getting fairly complex when more than two directories are involved.

Messaging

Messaging coexistence between the new messaging system and the legacy messaging system is also extremely important. Messaging coexistence provides a means of email message transport between the two email systems and can be accomplished in a variety of ways including:

• SMTP
• Native
• Other

SMTP

SMTP is the de facto standard for Internet messaging transport and is an issue that generally must be addressed regardless of whether or not SMTP mail is the primary means of achieving email message transport coexistence between the legacy and target email systems.

Using SMTP is the easiest way to achieve email message transport coexistence between two email systems because it utilizes the native SMTP connectors of the legacy and target email systems. Using SMTP means that users within either messaging system can simply send email to the SMTP address of the recipients and the native SMTP transport mechanisms of the respective email systems take care of routing these messages to the correct recipients.

The primary issue with SMTP, which must be solved regardless of whether or not SMTP is the primary means of email transport coexistence, is having two email systems that “own” the domain portion of the SMTP address. Most organizations typically have a single, primary SMTP domain address, the portion of the SMTP email address after the “@” sign. The issue becomes one of how the email systems know which email system to route the SMTP messages for delivery.

This issue can be solved in a variety of ways including the creation of a sub-domain for each email system such as @gw.domain.com and @ex.domain.com. However, an easier method for solving this issue involves configuring an Exchange server to act as a “smart-host” for the routing of SMTP messages. In short, this involves configuring the Exchange server in such a way that incoming SMTP messages bound for local Exchange users are delivered via normal means and messages bound for non-local Exchange users are then forwarded on to the legacy email system. Here the term “non-local Exchange users” refers to users for whom Exchange is responsible for message delivery, but who do not have a mailbox on the Exchange email system.

Native

The native option utilizes native connectors within the email systems to tie the two email systems together in terms of message transport delivery. Both Microsoft Exchange and Novell GroupWise include native connectors for achieving this purpose. These connectors create new address spaces that control the routing of messages between the two systems. So, for instance, in GroupWise a new address space of “EXCHANGE” would be created and in Exchange a new address space of “GWISE” would be created. Email messages in GroupWise addressed to a recipient that has an “EXCHANGE” address space will be routed to the connector and delivered to the Microsoft Exchange system. Conversely, email messages in Exchange addressed to a recipient that has a “GWISE” address space will be routed to the connector and delivered to the Novell GroupWise system.

Other

There are other messaging transport standards that can be used instead of SMTP or native messaging transports. Chief among these is X400. X400 connectors can be installed on both systems and corresponding X400 address spaces created that handle the routing of email messages between the two systems. This alternative exists but generally involves much more work than either SMTP or native messaging coexistence and is therefore generally not the recommended approach.

Calendaring

Calendaring coexistence is a relatively new form of coexistence that seeks to solve the problem of users being able to schedule and accept meeting appointments and perform other calendaring functions regardless of the attendees’ email systems. There is really only one choice for calendaring coexistence, using native connectors although calendaring standards are beginning to mature and some third-party products have begun to appear.

Native

Native calendaring coexistence involves the installation of a native connector within the email systems that provides translation of meeting requests, meeting acceptance and other calendaring functions. Both Microsoft Exchange and Novell GroupWise have native calendaring connectors designed for this purpose but calendaring connectors in general remain fairly rare. Achieving calendaring coexistence then involves the installation and configuration of one of these connectors.

Contact:  Gregory J. Deckler