What the Exchange Server Migration Wizard can do for you
You've decided to take the plunge and move your organization from Novell GroupWise to Exchange 2000 Server. You face challenges such as removing the GroupWise client, configuring the new messaging server product, and installing Outlook or another Messaging API (MAPI) email client. But after you get Exchange running, the most important tasks in the GroupWise-to-Exchange migration are moving mail and calendars. Let's discuss how to use the Exchange Server Migration Wizard, which installs with Exchange, to achieve these steps. (For a list of the tricks I've learned from working with the Migration Wizard, see the sidebar "Lessons Learned," page 2.)
Before you begin any migration, you should explain to both users and administrators how their worlds will change. If you don't take the time to convey that Outlook has a different look and feel from the GroupWise client, you'll probably hear from dissatisfied users. Moving from the GroupWise client to the Outlook client can be a life-altering change for many users. However, colleagues who use the Outlook or Outlook Express client at home might welcome the change. Regardless, you must prepare your users.
Administrators must thoroughly understand the process of migrating users' messaging data and know that during the window of coexistence (i.e., when both mail systems are running), the email infrastructure will be complex. End-user training is vital. Be sure to fully explain any new features, and for reassurance, point out any aspects of the new client that are the same as or better than what your users are used to.
The Migration Wizard
The Migration Wizard extracts user data—mail and calendars—from GroupWise. (The Migration Wizard can't migrate GroupWise archives, Personal Address Books—PABs—and contacts. To help you move these components, consider using ComAxis's UniAccess; visit http://www.comaxis.com for more information about this product.)
The Migration Wizard lets you perform your migration as either a one- or two-step process. If you choose the one-step method, you run the wizard once to extract and import data into Exchange. If you choose the two-step process, you must run the wizard twice: The first time, the wizard writes all data to a location you specify (typically, the local hard disk); the second time, the wizard imports the mail from the temporary location into Exchange. Use the two-step process if the one-step process fails or if you want to separate the migration into phases so that you can work with the data before importing it into Exchange. The one-step process doesn't always succeed with large mailboxes. In my experience, the two-step process is more reliable for migrating GroupWise mailboxes larger than 300MB. The two-step process might also be a better choice if your GroupWise server is ailing and the wizard has a hard time maintaining a connection with the server.
Migration Wizard Internals
Whichever process you choose, the extraction steps are similar. The Migration Wizard extracts data from GroupWise and writes the data to a temporary directory. The wizard uses Intermediate File Format (IFF) files for all migrations. IFF files are comma-separated value (CSV) files that you can view with any text editor. The wizard writes data to IFF files as it extracts the information from GroupWise. If you're migrating a large post office (or user) that contains gigabytes of data, your IFF files will also be gigabytes in size. You can identify the three IFF file types by their extensions:
- Packing List (.pkl)—The .pkl file is a list or inventory of all other IFF files relating to a migration session. The wizard uses this list as a reference for all the IFF files involved in the migration session. The wizard consults the .pkl file when you perform the second step of a two-step migration.
- Primary (.pri)—One .pri file exists for each user, and one .pri file exists for the directory information for all users. If, for example, you're migrating five users, you create six .pri files. Directory.pri contains a list of the exported users and their properties (e.g., display name, alias, addressing). The other .pri files contain the users' email messages and are named in numbered sequence (e.g., 00000001.pri, 00000002.pri).
- Secondary (.sec)—The wizard uses .sec files to hold large amounts of data, such as the body of a message or message attachments. The .pri files contain pointers to data in .sec files. In other words, a user's .pri file contains message properties such as To, From, Cc, Subject, Date, and Time. The file also includes a pointer that references a specific byte within a .sec file for the beginning of a message's body text. The wizard stores any message that exceeds 256 bytes in a .sec file and inserts a pointer to this data in the .pri file (some parts of messages, such as the body, are always stored in the .sec file, even if they're smaller than 256 bytes).
After successfully migrating a user, you can delete the temporary directory. Because this deletion doesn't occur automatically, you must be careful not to run out of disk space when using the Migration Wizard. Figure 1 shows a temporary directory for a migrated user.
The Migration Account
To use the Migration Wizard, you need an account that has access to Exchange, GroupWise, Novell NetWare, and user mailboxes on both messaging systems. Best practice is to create an account in both environments with the same username and password. For example, create an account called GW2EX (GroupWise to Exchange). On the Windows side, the account needs Exchange Administrator rights and Domain Administrator rights (or administrator rights to the organizational unit—OU—that holds both the GroupWise contacts and the new mailbox-enabled object). You don't have to provide full rights in NetWare and GroupWise, but if you don't, you'll spend weeks granting all the specific access required, object by object. Be sure to set a strong password for this powerful account to prevent abuse.
The Migration Server
You can run the migration utility from any workstation or server that's a member of the forest that hosts Exchange, but I recommend creating a dedicated migration server. The migration server can be either a server or a high-end workstation physically located as close to both the GroupWise and Exchange servers as possible (preferably on the same network segment). I've found that Windows 2000 Server offers better performance than Win2K Professional for this purpose. Don't use the migration server for other purposes; the server requires a complex mix of network and client access software, as Table 1 shows, and you might need to reboot the machine on occasion during extended migration projects. You can create as many migration servers as you need. Depending on the server's configuration, one subsystem might be affected more than others. In one project I worked on recently, the client chose a piece of hardware with a slow IDE disk drive, causing extremely slow migrations.
Note: You don't need to install the Novell GroupWise Connector to migrate users from GroupWise to Exchange. The Novell 32-bit client and GroupWise client software provide the communication to the GroupWise system, and Exchange System Manager (ESM) provides communication to the Exchange system.
The GroupWise client version is the most crucial piece of the migration server. The Migration Wizard uses the GroupWise client API to access mailboxes on the GroupWise Server. The API changes with most every version of the GroupWise client, but Microsoft doesn't revise the wizard every time Novell releases a new version of GroupWise. For the most reliable results, use GroupWise 5.2.0 (this is a rare exception to the rule of running the most current version—in this case 6.0). I've also had success with version 5.2.5.
The migration server connects the GroupWise and Exchange worlds, pointing to a bridgehead server on the Exchange side and, on the GroupWise side, to a Novell server that runs the API gateway and hosts the primary domain. Note that the migration server must be connected to the GroupWise Primary Domain database so that it can use the Message Transfer Agent (MTA) connectors to find the API gateway link. I suggest that you install and connect the API gateway on the primary domain MTA. If the user you're migrating is hosted in a secondary domain, you must be authenticated to the server hosting this domain. The primary concern is that the migration server is connected to the same post office on which the user being migrated resides. This would still hold true if domains and post offices exist in different trees.
Figure 2 shows an example of the error messages you receive when the migration server can't communicate with the GroupWise server. At first glance, you might assume that you're experiencing an access problem or that you lack proxy rights on the GroupWise side. However, the problem in this case is that you have the wrong version of the GroupWise client on the migration server (i.e., not version 5.2.0). Install version 5.2.0.
Running the Migration Wizard
You must take several final steps before you can run the Migration Wizard:
- Prepare any GroupWise archives that users want converted and migrated to Exchange. As I mentioned earlier, the Migration Wizard won't migrate GroupWise archives. Instruct users to import their GroupWise archives back into their mailboxes so that the wizard can convert them to Exchange during the migration. This step might not be possible for power users with gigabytes of GroupWise archives and limited disk space on the existing GroupWise server.
- Set or clear passwords on GroupWise mailboxes. During the migration, the wizard will ask you for the password for each user mailbox.
- Set the visibility of each GroupWise mailbox to system. If you don't, the wizard won't see the mailboxes when it scans the GroupWise server.
- Give the migration account proxy rights for the GroupWise mailboxes. The migration account should be the only account with proxy access. The account you run the wizard from needs Read access to the user mailboxes. The best-practice procedure is to delete all other proxy access because the wizard sometimes becomes confused when reading proxy access.
The GroupWise Bulk (GWBulk) utility, which is available from Microsoft Consulting Services (MCS), can help you automate many of these tasks. This tool is provided "as is," meaning that Microsoft doesn't formally support it. However, the source code is available if you want to make any modifications or add functionality. Be sure to test GWBulk in your environment before using the utility. Contact your local Microsoft representative to obtain the tool.
Running the Migration Wizard is a straightforward process. However, you might encounter a couple of glitches:
- You might receive a "duplicate error" after selecting the account you want to migrate. To resolve this problem, find the mail-enabled contact that the Novell GroupWise Connector created and delete it. Depending on which domain controller (DC) you're authenticating to, you might need to wait for replication to catch up before running the wizard again.
- If accounts other than the migration account have proxy access to the existing GroupWise account, a failure will result.
After the wizard finishes its work, run Outlook and verify that mail has migrated successfully. If so, delete the user from GroupWise. (If you don't delete the user—e.g., if you instead change the GroupWise account's visibility to hidden—other GroupWise users will still be able to use the migrated user's alias name to send mail to the user.) The wizard will replicate the new Exchange user to GroupWise and add the account to the GroupWise Address Book. This process should occur within a few minutes. Figure 3 shows that the Migration Wizard has imported 4 of 38 messages. When the migration is complete, the wizard should show no errors.
To move calendar information, the wizard pulls calendar entries from GroupWise, inserts them into an .sc2 (Schedule + file) attachment, then attaches the .sc2 file to an email message for the user. After the migration, you must save the .sc2 file, then use the Import utility to import the .sc2 file into Outlook. When you run Outlook for the first time, it asks whether you want to import the file.
This process might seem complicated, but I've seen migrations in which hundreds of calendar appointments have migrated to Outlook seamlessly. The wizard oversees much of this process, but the successful migration of calendar data falls ultimately on the shoulders of the users. I haven't found any helpful shortcuts for the user other than using a third-party utility, as I mentioned earlier.
The Migration Wizard has some limitations, but it's a free tool that provides valuable functionality for migration projects. You might find the wizard especially appealing if you're on a budget and can't afford third-party migration products. Just remember that as with any such project, the key to success is lab testing and good planning.