The Fast Road to Exchange Server 2003
You'll never truly see the beauty of Exchange 2003 unless you migrate. Here are five tools to make that move quicker and easier.
Names, characters, places and incidents reported here are the product
of the authors' imagination and any resemblance to actual persons, living
or dead, business establishments, events or locales is purely coincidental.
Donald P. Apscott, MCSE, is a happy man. Or at least he was until
a few minutes ago when his boss at T&T Corp. left Don's office. It turns
out the boss just came back from a conference on Exchange migrations.
In Don's opinion, it may have been more a marketing session than an actual
conference, but as usual that won't matter… You see, a couple of months
ago, Don started his Windows Server 2003 migration project. This involved
moving from Windows NT and other obsolete server and workstation operating
systems to Windows Server 2003 and Windows XP. Once his new infrastructure
was in place, it was part of his plan to proceed with the replacement
of his outdated e-mail system and the deployment of a new version of productivity
software, Microsoft Office 2003.
Since his project plan called for an Active Directory (AD) migration
as the first step, Don began with the evaluation of AD migration tools.
He studied the requirements and set up his lab accordingly. He then proceeded
with the evaluation of five different products as well as some no-cost
migration options. Many of the products he tested were more complete migration
suites than single-purpose tools. After a thorough testing program of
both free and commercial tools, Don selected what turned out to be a complete
migration suite from NetIQ. Because the entire suite cost less than any
of the other tools tested, Don purchased all three products in the suite:
Domain Migration Administrator, Server Consolidator and Exchange Migrator.
Since the suite could support three of his migration objectives
security principal migration, file and print server migration and mailbox
migration Don thought he was ahead of the game. Not only did he
have his AD migration tool, but he also had two more tools to support
future migration phases. That is, until today.
Trust his boss to let himself be drawn into an Exchange Migration Conference,
a conference given by a competitor to the product Don chose, of course.
It isn't surprising that BindView Corporation, the conference sponsors,
would argue that security principal migration is one thing, but when it
comes to Exchange, it's another story completely. According to Don's boss,
BindView states that Exchange migrations should not be taken lightly because
e-mail systems have become mission-critical in most organizations, especially
organizations such as T&T Corporation which must manage a mobile sales
force. Today's companies cannot afford to have any e-mail downtime. BindView
thinks e-mail is so important that they do not sell their migration tool,
bv-Admin for Microsoft Exchange Migration, without also including professional
services. They claim their professionals can draw upon the migration experience
of millions of mailboxes and that this experience can save both time and
money. They may have a point. After a few investigations, Don is beginning
to realize that Exchange will be a bit more complex to migrate than Active
Don knew that he wanted to invest special efforts in making the Exchange
migration smooth, but he didn't think his boss would demand a total re-evaluation
of the migration tool he had already selected. Now, much to his chagrin,
he has to perform a whole new migration tool evaluation.
So he did a little research and found that as far as Exchange is concerned,
there is a plethora of migration tools. He has narrowed his search down
to five tools: NetIQ Exchange Migrator, Aelita Exchange Migration Wizard,
Quest Migrator, Compusven Email Shuttle, and Transend Migrator. He wanted
to include BindView in the evaluation, but they would not provide a tool
to review because they claimed, they would prefer to provide consulting
services with the tool. As an MCSE, even an MCSE that is not certified
in Exchange 2003, Don felt that he should have the skills and knowledge
required to perform a proper evaluation without hand-holding from external
consultants. But, he'll wait until his evaluation is complete before bringing
this up with his boss.
Exchange Migration Options
Don has some 1,250 mailboxes to move from Exchange 5.5 to Exchange Server
2003. T&T's users are scattered all over the country. T&T's activities
cover several areas: manufacturing, scientific research, marketing and
travel a lot of travel since T&T's clients are all over
the world. T&T will have to work hard to coordinate the migration with
its business processes which aren't letting up even in today's tight business
market. Don will have to keep all of these aspects in mind when developing
his migration strategy.
The first thing Don has to decide is how to migrate. Exchange supports
two migration strategies: intra-organizational and inter-organizational.
Both have advantages and drawbacks (see "Choosing
a Migration Strategy").
Another option Don has is to simply perform an upgrade of his Exchange
5.5 servers. But that's not easy. First of all, Exchange Server 2003 only
runs on two platforms: Windows 2000 Server with Service Pack 3 or more
and Windows Server 2003, while Exchange 5.5 doesn't run on Windows Server
2003. Besides, the recommended upgrade path involves an upgrade to Exchange
2000, then an upgrade to Exchange 2003 because there is no direct upgrade
path from 5.5 to 2003. For Don, this would mean upgrading his e-mail servers
to Windows 2000 Server first, applying Service Pack 3 (unless he can build
a slipstreamed edition of Windows 2000 Server), running the upgrade from
Exchange 5.5 to Exchange 2000, then the upgrade from Exchange 2000 to
Exchange 2003,m and finally upgrading his servers to Windows Server 2003.
Quite a process. In addition, this means running two series of forest
and domain preparations, one for Exchange 2000 and one for Exchange 2003.
All in all, Don doesn't even think this is a consideration. Besides, he
used the parallel network approach to create a pristine Active Directory
as well as making sure that all of his servers had new installations of
Windows Server 2003. Given this approach, he won't use the upgrade for
Exchange. It's just too complicated.
a Migration Strategy
To evaluate his migration options, Don had to determine
whether he was going to perform an intra- or inter-organization
migration. The first involves the reuse of the original
organization T&T used when installing Exchange Server
5.5 followed by a mailbox move from Exchange 5.5 to
Exchange 2003 servers. The second involves the creation
of a new organization during the installation of Exchange
2003 Server followed by a mailbox migration from the
Exchange 5.5 organization to the new Exchange 2003 organization.
To support his decision, Don focused on the following
- Support for multiple mailbox sources
- Support for restructure of Exchange Organization
- Rename Exchange Organization
- Parallel Content Synchronization
- Mixed versus Native Mode
The first item is important to Don because he knows
that T&T will be merging with another firm in the near
future. If he uses an intra-organizational migration
now, it will not help him when the time comes to merge
the email infrastructures between T&T and the new company.
On the other hand, if he chooses an inter-organizational
migration, he will gain valuable experience that can
be reused when he needs to merge the new company with
his new Exchange 2003 organization.
The second is also important. Despite their best efforts,
Don's Exchange administration staff has made a few mistakes
in the way they originally set up their Exchange 5.5
environment. He knows this was mostly due to lack of
time for proper planning. This time, they can prepare
their Exchange 2003 architecture well before its implementation
so the ability to restructure the organization is important
to them. If Don chooses an intra-organizational migration,
he will have to wait until all Exchange 5.5 servers
are decommissioned before he can begin to restructure
his Exchange organization. In an inter-organizational
migration, Don can begin his restructure immediately.
The third item is also of value. The original Exchange
5.5 organization's name stemmed from a former company
name. Now that the company is called T&T Corporation,
Don would like to rename his Exchange organization to
match. This cannot be done in an intra-organizational
migration since you join the Exchange 5.5 structure
and organizations cannot be renamed once they are in
use. With an inter-organizational migration, Don can
rename the Exchange organization during its installation.
The fourth item, parallel content synchronization,
is essential if Don uses two different organizations
since he needs to make sure the e-mail service is continually
available to users during the migration. In an intra-organizational
migration, this item is of little importance since the
migration has little impact on user configuration. But
in an inter-organizational migration, it is essential.
E-mail that is sent to the former user's address must
automatically be forwarded to the new e-mail address
until the new DNS address of the server has been propagated
on the Internet. If Don chooses an inter-organizational
migration, he will have to manage this issue with care.
The final item relates to the relationship between
the old and the new infrastructure. In an intra-organizational
migration, Don knows that he will not be able to move
to a native Exchange 2003 organization until all Exchange
5.5 servers are removed. He also knows that he will
have to run special services such as the Site Replication
Service as well as the Active Directory Connector to
maintain consistency between his Exchange 5.5 and 2003
servers during their coexistence. In an inter-organizational
migration, he can set his new organization to native
mode as soon as he implements it. This would give him
greater flexibility in the configuration of his routing
and administrative groups as well as allowing him to
have immediate access to the new query-based distribution
groups, something he knows his company will require
in the short term.
After weighing the value of each consideration, Don
has decided to proceed with an inter-organizational
migration. In a way, this approach will mirror the approach
he used for his Active Directory migration, letting
him prepare a pristine new environment supporting all
of the new features Exchange 2003 offers. This will
temper the way he evaluates each of the migration tools
on his list.
This leaves him with his two original choices: intra versus inter-organizational
migration. The intra-organizational approach is fairly easy. Install Exchange
2003 on new servers running Windows Server. Make sure they are joined
to the existing 5.5 organization, and then move the mail boxes from the
5.5 servers to the 2003 servers. But once again, this doesn't give him
the same type of advantages he gained with his AD migration; that is,
to have a new, pristine environment running native features; at least,
not until all of his Exchange 5.5 servers are decommissioned. So he's
going to opt for the inter-organizational migration. It follows the same
basic approach as his AD migration and it also gives his team valuable
experience that can be used in the case of acquisitions and mergers, because
it is based on the same scenario (see "Mixed versus
Native Exchange Modes"). In addition, he wants to avoid running
the Active Directory Connector for Exchange if at all possible. He plans
to keep the migration timing very short and knows that he is heading towards
a fairly stable season in terms of employee mobility so he believes that
he can always create the user accounts in NT and migrate them as needed
to Active Directory. This way, they automatically have a mailbox created
in Exchange 5.5 which they can continue to access once from within the
Windows Server 2003 forest.
To prepare for his inter-organizational migration, Don has installed
new servers running Windows Server 2003, Enterprise Edition. He has also
installed Internet Information Services 6.0 enabling the World Wide Web,
Simple Mail Transfer Protocol (SMTP), and Network News Transfer Protocol
(NNTP) services as well as ASP.NET. He has prepared his test forest, extending
both the configuration and schema containers of Active Directory with
the ForestPrep setup program. He has also modified the domain containers
through the domain preparation tool in each domain that will include either
Exchange servers or mail-enabled objects as well as in the root domain
to create special Exchange security groups. Since his new servers are
clustered, he has elected to use the Enterprise Edition of Exchange Server
2003. He may end up using a front-end and back-end architecture later
to have a more resilient email infrastructure. This would let him use
the Standard Edition for the front-end servers and provide load balancing
through the Network Load Balancing (NLB) service, but since his immediate
goal is to test the migration process, he will leave off the final architecture
testing for now. Finally, he has modified his Exchange Server 2003 installation
to operate in native mode (see Figure 1).
|Figure 1. Going Native. Exchange Server 2003
is installed in mixed mode by default, but when you install it into
a new organization running on Windows Server 2003, you can set it
to native mode. This gives you access to Exchange 2003's full feature
set. To do so, view the organization's properties and click Change
Mode on the General Tab.
All security principals are migrated with SID history from the NT domain
running Exchange 5.5 to the new AD forest running Exchange 2003. All test
workstations have been upgraded to Windows XP and are running Office 2003.
Outlook 2003 is configured to connect to the Exchange 5.5 organization.
His testing ground is now ready and he can proceed with the evaluations
(see Figure 2).
|Figure 2. Don's Migration Strategy. Don has decided
to proceed with a set strategy for his Exchange migration. It involves
10 steps. First he needs to prepare both the schema and configuration
containers in Active Directory. This is done with the ForestPrep switch
for Setup. Next, he needs to prepare the domain container in AD. Each
domain that will either include an Exchange server or mail-enabled
objects must be prepared as well as the root domain to contain special
Exchange objects. So Don's next step is to run DomainPrep where appropriate.
Once this is done, he can install Exchange 2003 in his production
domain. Then he needs to set up connectivity between his two Exchange
organizations. He can then migrate public folders, followed by mailboxes
and calendars. Finally, he can modify the Outlook configuration on
his client computers and decommission his 5.5 servers.
NetIQ Exchange Migrator
After setting up his entire environment and making sure that both
the Exchange 5.5 and the Exchange Server 2003 organizations can communicate
with each other, Don began his installation of the NetIQ Exchange Migrator
(NEM). Knowing that the migration process is resource intensive, Don chose
to install NEM on a separate Windows Server 2003 machine. He installed
the Exchange System Manager on his server to make sure he had access to
the Exchange Server 2003 organization. He felt confident that all was
in place to run NEM. Besides, he had already used the NetIQ Domain Migration
Administrator to perform his security principal migration; he was used
to NetIQ interfaces.
Once he inserted the CD, NEM displayed the familiar NetIQ startup screen.
Don checked to make sure he had the latest version. It turns out he needed
to download both a service pack and some hotfixes for the version he was
using. After obtaining all the components he needed, he checked the system
prerequisites. Two prerequisites are verified: operating system version
and MAPI32.DLL compatibility. His system passed, though it thought he
was using Windows XP instead of 2003. Weird. He then launched the setup
program. He immediately received an error stating that Setup required
the presence of Outlook 2000 on his system.
He was seriously surprised since he knows there is a known issue between
Outlook and Exchange System Manager coexisting on the same machine. Each
uses a different version of the MAPI32.DLL and since both are in Windows
Installer format, they would want to replace the other's DLL each time
they are launched. After further research, Don discovered that Exchange
Migrator actually requires the presence of Outlook to create profiles
for both the source and target organizations. In addition, Exchange Migrator
version 2.21 with Service Pack 1 is not supported on the Windows Server
2003 platform or with Outlook 2003. To get it to work, he has to install
it on a Windows 2000 machine with Outlook 2000.
Don was quite disappointed by this discovery. His environments include
only Windows NT, XP or 2003 machines. His team has no experience with
Windows 2000 nor do they want to gain any. In addition, he has no installation
of Outlook 2000 available anywhere. After contacting the manufacturer,
he discovered that even after Exchange Server 2003 has been out for eight
months and Windows Server 2003 for more than a year, NetIQ has not seen
fit to release an updated version of the Migrator that runs on this platform.
He was less than impressed, but he bit the bullet and installed a Windows
2000 machine with the appropriate prerequisites; after all, he already
owns this tool.
After finally managing to install the product it requires a SQL Server
database, but can install the Microsoft SQL Server Desktop Engine (MSDE) Don
discovered that despite the odd prerequisites, NetIQ Exchange Migrator
presents a very nice interface (see Figure 3).
|Figure 3. Using the NetIQ Exchange Migrator.
Despite the odd prerequisites for its use, Exchange Migrator provides
a very nice interface clearly outlining the steps required to run
a migration from one Exchange organization to another.
To begin, you must prepare a project which lets you set both source and
target organizations. Once this is done, NEM presents a step-by-step migration
procedure that is wizard-based and easy to follow. In the end, NEM worked
very well and supported each of the steps in his migration project, including
the provision of a command-line interface to support scheduled migrations
as well as support for a scripting language to perform pre- or post-migration
Aelita Exchange Migration Wizard
The first thing Don noticed about this product is that it offers a very
nice quick start tutorial that displays the key elements of a migration
using the Exchange Migration Wizard (EMW). This clearly identifies what
he needs to do. The installation is fairly simple, just follow the instructions
on the Autoplay screen. The version Don was using required an update which
was included on the installation CD, however, the installation screen
listed the installation of the resource kit before the installation of
the update. This should be reversed on the startup screen since the resource
kit does not install without the update.
Don also had a bit of trouble installing the Aelita Reporting Console.
This tool is based on the Microsoft SQL Server Desktop Engine (MSDE).
MSDE is installed automatically by the reporting tool, but during the
installation of the tool itself, it requires a connection to the SQL database.
To do so, Don needed to input several values which were not immediately
apparent. These included SQL Server name, database name and SQL account
to use for the Web reporting engine. The first two were easy, but the
third was impossible for Don to know since the MSDE installation was automated
and he did not know any of the parameters of this installation. So he
decided to add his own installation of SQL Server 2000 with Service Pack
3. This way, he could control all the parameters of the installation and
ensure it was secure.
One of the nicest features of EMW is its interface (see Figure 4).
|Figure 4. Using Aelita Exchange Migration Wizard.
The Exchange Migration Wizard provides a simple, step-by-step approach
to Exchange migrations. Each step is clearly outlined and easily accessible
from the startup screen.
When you first launch the Project Manager, you need to connect to a SQL
Server database. If the database does not exist, EMW will create and populate
it automatically. Once this is done, the Project Manager interface appears.
It nicely lays out what needs to be done: register source and target organizations,
set up directory synchronization, then migrate public folders, mailboxes
and calendars (see Figure 4). This fits very nicely with Don's own migration
plans (see Figure 2). The configuration of each element is also very straight
forward, at least, once you know what you're doing. When directory synchronization
is set up, it installs an agent on a machine you specify. This agent will
synchronize all objects between the 5.5 and the 2003 organizations. Don
opted for X.400 synchronization since he was using the Enterprise Edition
of Exchange Server 2003 and it was much easier to set up than the SMTP
protocol. Synchronization can work in three modes: from 5.5 to 2003, from
2003 to 5.5 or in both directions. It also supports mail redirection,
automatically forwarding mail from one system to the other. This is a
great feature since it will take between two to three days for Don's DNS
server to propagate the new Exchange 2003 address to the Internet. Finally,
synchronization can automatically create objects in AD if they don't exist.
You have to be careful with this option though, because if you have more
than one 5.5 server replicating to AD, you may be creating duplicate objects.
Synchronization can be done continuously or at scheduled intervals. By
default it runs every few minutes.
Once synchronization was set up, Don started creating some synchronization
jobs: one for public folders, one for mailboxes and one for calendars.
While creating a job for mailbox migration, Don was allowed to automatically
create collections of mailboxes that could be targeted to different mailbox
stores. He could select the members of each collection if he wanted, but
instead he opted for automatic mailbox store creation based on the number
of users migrated. This let him immediately profit from the new features
of Exchange 2003.
In addition to the EMW, Aelita provides a Resource Kit for Exchange migrations.
The resource kit includes several tools, but the most useful one is the
EMWProf Configuration Wizard. This tool is designed to modify profiles
on client computers. When run, the wizard lets you create a batch file
that can be added to a login script to run the profile updater on each
client machine once the migration is complete. Pretty nifty. Overall,
EMW provided a simple migration process that was nicely detailed and outlined
in a step by step format.
Don was glad he set up his own SQL Server 2000 environment in the test
lab because Quest Migrator also requires access to a SQL database to store
project information. Installation was easy; simply follow the instructions
provided by Windows Installer. Once installed, he launched the Migrator.
The first thing the Migrator does is request that he create a project.
Don remembered that he really liked the approach this product suggested
for directory migration; a simple three step process that was well documented.
That's why he was a bit surprised that this wasn't the approach used in
support of Exchange migrations.
Instead, Migrator provides six wizards for the migration of Exchange
5.5 to 2003 (see Figure 5) this product is the first so far that actually
mentions 2003. The wizards are designed to migrate objects such as mailboxes,
mailbox messages, distribution lists and custom recipients as well as
public folders. One wizard is also designed to move mailboxes from one
server to another during an intrasite migration. The final two provide
an auto forwarding service to coordinate messages during the migration
and a service designed to update security descriptors on mailboxes and
other objects once they have been moved.
|Figure 5. Using Quest Migrator. Migrator uses
a series of different wizards to perform an e-mail migration. Simply
select the appropriate wizard from the command tree in the left pane
and launch it from the right pane. In addition, the right pane provides
useful information for the operation of each wizard.
Don began with the object migration wizard. He found its use very straight
forward, but one thing he didn't like was the requirement to select each
one of the objects individually. This means he would have to click on
each of his 1,250 user objects to move their mailboxes, not a very practical
approach, especially if you have tens of thousands of objects. He also
really liked the message migration wizard, especially the fact that it
supports the migration of any object in the mailboxnotes, tasks,
messages, deleted messages, and more…but once again, he found it
odd that he had to click on each one of eleven objects to move for each
one of his 1,250 users; a very tedious job with a very high potential
for error. At least in the auto forward wizard, he was able to use the
Shift key to select more than one person at a time. But despite these
inconveniences, the Migrator worked very well moving mailboxes and mailbox
content on schedule. Don was also able to update client Outlook profiles
using the Resource Updater.
Perhaps the nicest feature of Quest Migrator was its ability to run migration
tasks from the command line. This allowed Don to create a series of special
migration tasks and schedule them for later operation by placing them
in command files and using the Windows Task Scheduler to launch each job.
It also allowed him to create command files that for the modification
of user Outlook profiles at the end of the migration. Overall, Quest Migrator
performed very well and migrated Exchange objects as predicted.
Compusven Email Shuttle
CompSven is a company that has made its name with Email Shuttle, a specialize
e-mail migration tool that supports the migration of such disparate systems
as Lotus Notes, Novell Groupwise, Exchange and other IMAP4 compliant email
systems to new versions of the same products. The Email Shuttle provides
the capability to both transfer and synchronize information from Exchange
5.5 to Exchange Server 2003. Installation is straightforward but like
the NetIQ product, Email Shuttle requires the presence of Outlook. The
documentation states Outlook 2000, but since Don does not have or intend
to use this version of Outlook, he has installed Outlook 2003. He also
configured a special "eshuttle" profile in Outlook to give Email Shuttle
the rights to access the target Exchange system. Finally, he had to add
the administrative account he was using in the target system to the Exchange
5.5 organization and give it full administrative permissions.
Once this was done, he went on to install the Email Shuttle. Since all
the prerequisites were met and it detected Outlook, the installation proceeded
with no issues. As soon as the installation was complete, he chose to
automatically run the Email Shuttle LaunchPad (ESL). This wizard allowed
him to select both source and target systems, assign the appropriate Outlook
profile, configure how objects would be migrated and select the users
to migrate (see Figure 6).
|Figure 6. Using Compusven's Email Shuttle. The
Email Shuttle runs through a wizard called the LaunchPad. Simply follow
the onscreen instructions to migrate selected mailboxes. Once you
have finished with the wizard, it will open two command windows to
run both the Extractor and the Loader.
He could have moved all users at once, but opted to try out a move of
260 users at first. Once everything was configured, the migration job
was run. ESL uses two services to run a migration: the Exchange Extractor
and the Exchange Loader. The Extractor proceeds to open and export all
data (according to LaunchPad selections) from the legacy e-mail system
(Exchange 5.5). Then, Loader proceeds to load this information into the
new system. Both processes run in command mode, opening command windows
to display the progress of the job.
The jobs ran with no errors. This was by far the simplest migration Don
had tested to date, but there were some drawbacks. ESL does not include
any tool for the modification of user Outlook profiles to retarget the
new Exchange Server. This means that Don would either have to educate
his users or write a script that would do it for him. Second, ESL does
not include any synchronization tools to resynch the mailboxes once they
are moved. This is required due to the time it takes to propagate the
new Exchange organization's address to the Internet. Fortunately, ESL
runs from the command line so Don could use it to create a batch migration
file that would re-migrate users' mailbox contents during the time it
takes to update their addresses. This way, if mail is sent to their 5.5
mailbox, it can be automatically transferred to the new 2003 mailbox.
This job would have to run every hour or half-hour to make sure e-mail
boxes were in synch. Don also discovered that CompuSven can add new features
"on the fly" if they are required by clients.
One major drawback of the ESL is that Don couldn't find any way to uninstall
the program. It does not include an Uninstall option in the menu items
it creates nor is it listed in Add or Remove Programs in the Control Panel.
This means that you have to be careful where you install the Shuttle if
you want to remove it once the migration is complete.
Don also decided to test out Transend's Migrator. This product has won
some awards and he was eager to see why. Migrator works differently than
any other product Don tested. This tool is designed to migrate mailboxes
from each user's computer to a new Exchange store. It is really designed
to migrate disparate e-mail systems, not from Exchange 5.5 to 2003. But
it does support this migration mode by storing the e-mail data in an interim
file before inputting it into the new Exchange organization.
One great advantage of Transend is that it migrates everything it finds
on the user computer, including personal mail files that may have been
extruded from the Exchange 5.5 servers. This is the only tool Don found
that supports this. But because it works from the client system, care
must be taken when running the tool. It must be done through a job that
is setup on a central system a system that has access to all others. In
addition, the account used must have local administrative rights to be
able to perform work on other user's machines. Once this is set up, the
migration can proceed as planned. However, this must be done in off hours
since it requires access to user PCs.
When used in its graphical mode, Migrator only lets you migrate one type
of Outlook element at a time, either mail, calendar, tasks or address
books. And when migrating from Exchange 5.5 to 2003, you have to store
data in an interim format (see Figure 7) and use a second migration process
to store it in Exchange 2003 format.
|Figure 7. Using Transend Migrator. Migrator is
a tool that must be run from the client workstation. When migrating
from Exchange 5.5 to 2003, you must use an interim format to convert
files; in this case, the Eudora format is being used. Files will be
converted from Eudora to Exchange 2003 in the second step of the migration
Migrator also supports a command line mode, letting you create batch
jobs that can migrate more than one system at a time and more than one
element at a time. Since the process runs on a local PC, you must make
sure there is enough disk space local or remote to perform the migration.
You must also remove the interim data files after migration. You may choose
to archive them for future reference before doing so.
Migrator is very simple to use and may provide a good migration path
for small shops wanting to move from one e-mail system to another. In
fact, it is ideal for shops moving from disparate systems, but for Don,
this may not be the best approach.
(Click image to view larger version.)
Much to his chagrin, Don found that, in the end, his boss was right. It
was worthwhile to perform an evaluation of the different migration products.
He found some very interesting tools. He created a table (see Table 1,
Criteria for Exchange Migration) to evaluate the strengths and weaknesses
of each product. In the end, it is once again a price/feature set ratio
that wins out for him. He really liked Aelita's Exchange Migration Wizard,
but at $15 per migrated mailbox, he just can't afford it. The Quest Migrator
was also very nice, though not as easy to use for Exchange as for Active
Directory. Had Don tested all the aspects of migration in his first project,
he might have selected this tool because it covers many of his migration
needs. Don also heard that Quest has made a bid to purchase Aelita. It
will be interesting to see what they do with the two Exchange Migration
tools when the companies merge. And, in a way, it is unfortunate that
BindView insists on selling their Exchange migration tool with professional
services if only because it would have been interesting for Don to see
the product in action. As such, he has to exclude them from his findings.
|Table 1, Mixed vs. Native
Mode. Don wants to make the most of his
new Exchange organization. As such, he has to decide if he will make
the move to a native Exchange 2003 mode. To do so, he prepared the
following table listing the pros and cons of each mode. Based on his
findings, he decided to proceed with a native implementation of Exchange
2003 Server. You can also use this table to determine which mode is
best for your organization.
|Support for Exchange
|Support for Exchange
|Support for Exchange
|Routing Group Support
between Administrative Groups
|Move Servers between
of Administrative and Routing Groups
Both CompuSven Email Shuttle and Transend Migrator are tools that are
really designed to migrate from non-Microsoft e-mail systems to Exchange.
But both performed really well. Email Shuttle may have been the easiest
tool to use, but for Don's purposes, it doesn't perform enough of the
migration tasks he has set himself. The same goes for Transend Migrator.
It works well enough and has the added advantage of working from the client's
system transferring personal mail archives as well as personal address
In the end, Don decided to stay with NetIQ. He has already purchased
it so cost is no longer an issue, but he feels that this manufacturer
has let him down by not yet making this tool work on Don's platform of
choice. He has heard though that there is a new version in the works which
should support the Windows Server 2003/Outlook 2003 platform. Apparently
this new version was due early in 2004, so he will just hold off his migration
until then. After all, his users are already working with Outlook 2003
and for them, this is a major improvement even if they are still connected
to an Exchange 5.5 platform.