In-Depth

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.

• By Danielle Ruest and Nelson Ruest
• April 01, 2004

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 Directory.

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.

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 tasks.

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.

Quest Migrator
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 mailbox—notes, 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.

Transend Migrator
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 process.

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.)

Overall Evaluation
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.

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 books.

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.