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:
1)
We need to create an internal SMTP routing system
that will support two internal systems.
2)
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:
jdoe@company.com routes to
jdoe@other.company.com 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.
See
http://support.microsoft.com/support/kb/articles/Q278/8/38.ASP
| 