Here is the scenario; you are currently running cc:mail or Notes in your environment and you are planning to move to Exchange. You know that there are connectors that come with Exchange to make the job much easier and want to use these connectors to bring over the directory and provide a message transport during the migration. The whitepapers paint a glorious plan for you in black and white; Install the connector – provide directory sync and message transport to the other system – move accounts – disable the connector.
Having followed this procedure countless times at many customer sites I can tell you that it works famously as long as your migration goes quickly. The less you have to depend on the connectors, the happier you will be in the end. The trickiest part of the migration is the co-existence with the different systems. I have heard of improper directory updates totally wrecking both systems, I hear (and have personally experienced) the connectors lock up in the middle of the day or night. In fact, I have encouraged businesses for the last several years to build separate connector servers so that a reboot would not affect any mailboxes.
I know all of this sounds bad and some of you perhaps have had a better experience, but the bottom line is support. Microsoft provides the connector tools as a migration tool and not a long-term solution. Take a look at the readme files to learn about the support options. If you build a long-term dependency on these tools, you may be setting yourself up for trouble. Microsoft does not consider these tools for long-term use so neither should you.
Long Term Requirements
So let’s dive into the requirements for just a minute. What is our goal in long-term co-existence? Hopefully, you listed mail-routing and directory updates as those items are clearly critical. Those of you who mentioned calendar and task compatibility should be prepared to start a development project to build an in-house connector. The Notes Connector and Calendar Connectors are awesome tools for migration purposes, but you don’t want to build a long-term dependency on these tools. I suggest you plan on using the lowest common dominator which is routing and directory updates. Focus on a fast migration and not on trying to make every feature work. To make everything work, put everyone on the same system
SMTP is a Simple Transport
Now we can get to the point. The connectors do a nice job of synchronizing the directories. The problem with the connectors is that they also configure the systems to use the connectors for message transport which is the root of the problem. Personally, I love SMTP as a message transport between two systems. For one, everyone supports it. Microsoft and Lotus (IBM) will be more than happy to try and troubleshoot your SMTP problems regardless of the systems you are connecting.
So we have one half of the puzzle completed, we know we want to use SMTP. Now what do we do about the directory? We have two issues here:
We need to create an internal SMTP routing system that will support two internal systems.
We need to get the names from one system into the other.
The first item is a little tricky, but definitely works. You will probably need to logically breakup your SMTP domain into OTHER.COMPANY.COM and EXCHANGE.COMPANY.COM. By doing this, your legacy email system can route mail to the Exchange system and visa-versa. You will probably need to make some DNS changes on your internal servers to control these settings. You will also need to make some changes in respect to your inbound mail. If you are using scanning software like Minesweeper, you can alter your routing table to direct some of the mail addresses to one domain and allow the default routes to continue to point to the largest community.
In other words, if a bulk of your users will be in Exchange, allow the scanning software to continue to send SMTP mail directly to the server. You can create an alias table on the scanning machine to handle the exceptions: [email protected] routes to [email protected] which goes to the old environment.
If you do not have a separate SMTP environment, you can let Exchange handle this for you as well. A custom recipient with a default address of other.company.com can be routed as long as the Exchange system does not think he is the only server for @company.com. There are several good articles in TechNet that can describe how to share an SMTP domain in Exchange. It is not that difficult.
Here is where things get tricky. If you use the connectors to synchronize the directories, SMTP will not be the transport used for message routing. Because the addresses will be created with the connector, the systems will try to use the connector as the transport. To correct this we have two options:
Use a third-party tool to keep the directories in place
Force the directory to delete the references to the legacy system while keeping the entries synchronized between the systems.
Again, the focus here is long-term connectivity so whatever option we choose should be stable and supported be either a third-party or within the scope of Microsoft or legacy vendor support. A secondary goal is to make the solution cheap. The connectors are free, so coming up with a costly alternative may not sit will with the executives with the check-books.
There are many possible solutions including Microsoft Metadirectory Services and similar products from other vendors. Instead of posting my directory synchronization answers, I want to see if someone out there has created a better sync solution. I will post a summary in the next week or so with the ideas I have collected. I will also try to lab up these ideas so we will all know how well they work.