Keep Your Migration From Heading South
If you’re planning on migrating users from GroupWise to Exchange, consider the Exchange Migration Wizard as a free alternative to expensive third-party options.
- By Mark England
- January 01, 2003
YOU’VE DECIDED TO take the big plunge and move your company from Novell
GroupWise to Microsoft Exchange 2000. One of the primary tasks—if not
the most important—of a GroupWise to Exchange migration is the job of
migrating mail and calendars. Some of the other challenges are maintaining
coexistence, removing the GroupWise client and installing Outlook or another
MAPI e-mail client; not to mention designing, installing and configuring
a new messaging system such as Exchange. Each of these tasks can be a
major project in itself.
The focus on this article is the Exchange Server Migration Wizard, installed
as part of Exchange. I assume you’ve already installed Exchange.
For administrators, it’s important to thoroughly understand the process
of migrating users’ messaging data and to know that when you enter a coexistence
state, your e-mail infrastructure will become more complex. Information
and expectation management are the keys to success.
The Migration Server
While you can run the migration utility from any workstation or
server that’s a member of the same forest as the Exchange servers, 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 (the same network segment
is preferred). I’ve found that running Windows 2000 Server versus Win2K
Pro on the server provided better performance. The migration server shouldn’t
be used for other purposes; at times it can be “touchy,” with the mix
of network and client access software required on it (see Table 1) and
may need to be rebooted from time to time during extended migration projects.
By dedicating the migration server to migrations only, I’ve had great
success. You can also have as many migration servers as you need. Depending
on the configuration of the migration server, one subsystem may be affected
more than others. For one project on which I recently worked, the client
chose a piece of hardware with a very slow IDE disk drive, causing extremely
slow migrations due to delayed disk drive performance.
|Table 1. Migration
|Windows 2000 server – latest
||This can be Server or Advanced
|Member of Exchange forest Exchange
System Manager – latest service pack
||ESM provides the communication
with Exchange and the ability to manage user and contact
|Novell Client version 4.8
||Needed to talk with Novell and
|GroupWise Client 5.2.0
||Needed to access GroupWise.
| NWCLIENT installed
||Even if the Netware server hosting
GroupWise is running TCP/IP, IPX/SPX is needed in order
to talk with the GroupWise server.
The GroupWise client version is the most critical piece of the migration
server. The Wizard uses the GroupWise client API to access mailboxes on
GroupWise Server. Because the API changes with almost every version of
the GroupWise client and the Wizard isn’t revised with every version of
GroupWise released by Novell, using version 5.2.0 will give the most reliable
results. This is an exception to the rule of having the most current version
running. I’ve also had good success with version 5.2.5.
Figure 1 shows an overview of where the migration server logically sits
in the big picture. The migration server connects to both the GroupWise
and Exchange worlds. In this example, the migration server points to a
bridgehead server on the Exchange side and on the GroupWise side points
to a Novell server running the API Gateway and hosting the primary domain.
|Figure 1. The migration server sits between the
GroupWise and Exchange environments (logical overview).
Note that the migration server needs to be connected to the GroupWise
Primary Domain database—allowing it to find the API gateway link via the
Message Transfer Agent (MTA) connectors. For ease of migration, it’s suggested
that the API gateway be installed to and connected via the primary domain
MTA. If the user you’re migrating is hosted in a secondary domain, you
need to 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.
Tip: Installing the Novell GroupWise Connector isn’t necessary to
migrate users from GroupWise to Exchange. While I haven’t seen a migration
done without using the Connector, it can technically be done with no problem.
Figure 2 shows an example of the error received when the migration server
is unable to talk to the GroupWise server. At first glance you might assume
this is an access issue or lack of proxy rights on the GroupWise side;
but the problem in this case is the wrong version of the GroupWise client
on the migration server. This error was caused by using a version newer
than 5.2.0. Installing version 5.2.0 fixed the problem.
|Figure 2. The migration has ended because of
errors. In this case, the errors were caused by the incorrect GroupWise
client version being installed on migration server.
The Migration Wizard
The Migration Wizard is used to extract user data—mail and calendars—from
GroupWise. It can’t migrate GroupWise archives, personal address books
or frequent contacts.
Tip: UniAccess, by ComAxis, http://comaxis.com,
is a handy utility that allows the migration of GroupWise data, including
archives, frequent contacts and personal address books. UniAccess is fully
scriptable and easy to use by administrators and/or users.
The Wizard gives you the option to perform your migration in either a
one- or two-step process. If you choose to migrate using the one-step
method, data is extracted and imported into Exchange by running the Wizard
one time. If you choose to migrate using the two-step process, you’ll
need to run the Wizard twice. The first time all data will be written
to the location specified in the Wizard (normally the local drive). You
then run the Wizard a second time to import the mail from the temporary
location into Exchange. The two-step process is often used when the one-step
process fails. The one-step process sometimes fails with large mailboxes;
in my experience, with GroupWise mailboxes over 300MB or 400MB, the two-step
process seems to work better. The two-step process may also be needed
if the GroupWise server isn’t in perfect health and the Wizard has a hard
time holding a connection to it.
Migration Wizard Internals
Whichever process you choose, the following process occurs when
data is extracted from GroupWise and written to the local drive. As mentioned
above, the Wizard extracts from GroupWise and writes the data to a temporary
directory. The Wizard uses Intermediate File Format (IFF) files in all
types of migrations it performs. IFF files are comma-separated-value (CSV)
files and can be viewed by Notepad or any text editor. Data is written
to IFF files as it’s extracted from GroupWise. If you’re extracting a
large post office (or single user) that contains gigabytes of data, your
IFF files will also be gigabytes in size. There are three types of IFF
files, identified by their file extensions:
- Packing List (.pkl): The .pkl file is a list or inventory
of all other IFF files relating to that migration session. The Wizard
uses this list as a reference for all the IFF files involved in the
migration session. When you perform the second step of a two-step migration,
the Wizard uses the .pkl file to get started.
- Primary (.pri): There’s one .pri file for each user, and one
.pri file for the directory information of all users, so if you’re migrating
five users, six .pri files are created. The Directory.pri file contains
a list of the exported users and their properties (display name, alias,
addressing and so on). The other .pri files contain the user’s mail
messages, whic are named in numbered sequence: 00000001. pri, 00000002.
pri and so on.
- Secondary (.sec): The .sec files are used to hold large amounts
of data, such as the body of a message or message attachments. The .pri
files contain pointers to data in the .sec file. In other words, a user’s
.pri file contains message properties such as To, From, Cc, Subject,
Date, Time and so on. It also has a pointer that says to look in a specific
.sec file beginning at a specific byte to get the body for this message.
Any data amount in a message that exceeds 256 bytes is put in the .sec
file, and a pointer to this data takes its place in the .pri file (some
parts of messages, such as the body, are always put in the .sec file,
even if they’re shorter than 256 bytes).
After a user’s been successfully migrated, as shown in Figure 3, the
temporary directory can be deleted. This isn’t done automatically, so
care must be taken not to run out of disk space.
|Figure 3. The Wizard has imported four out of
38 messages. When complete, the Wizard should show zero errors.
The Migration Account
To use the migration utility, you’ll need an account that has access
to Exchange, GroupWise, NetWare and the users’ mailboxes on both messaging
systems. The best practice is to create an account in both environments
that has the same username and password. An example would be to create
an account called “GW2EX” (GroupWise to Exchange). On the Windows side,
the account will need Exchange Admin rights or Domain Admin rights (or
admin rights to the Organizational Unit that holds both the GroupWise
contacts and the new Mailbox-enabled object). While you don’t have to
provide full rights in NetWare and GroupWise, if you don’t, you’ll spend
weeks granting all the specific access required—object by object. It’s
obviously easier to just grant full rights to the system as well, right
from the start.
Running the Wizard
Now that the prep work’s completed and Exchange is ready to receive
GroupWise users, it’s time to run the Wizard. Table 2 provides a checklist
of tasks that must be completed prior to running the Wizard. Here’s a
quick explanation of each item in Table 2.
|Table 2. Pre-Migration
||Import GroupWise archives that
the user would like converted and migrated to Exchange.
||Set or clear the password on
a GroupWise mailbox.
||Set the visibility of a GroupWise
mailbox to “system.”
||Give the migration account proxy
rights for the GroupWise mailbox. The migration account
should be the only account with proxy access.
|| Send a personalized mail to
the new Exchange mailbox.
- Item 1: As mentioned before, the Migration Wizard won’t migrate GroupWise
archives; thus one option is for the user to import his or her GroupWise
archives back into his or her mailbox so the Wizard will convert them
to Exchange during the migration. This might not be possible, though,
for power users with gigabytes of GroupWise archives and limited disk
space on the existing GroupWise server.
- Item 2: When running the Wizard, you’ll need to provide the password
for the user’s mailbox.
- Item 3: The visibility of the GroupWise mailbox must be set to “system”
or the migration utility won’t see the mailbox when it scans the GroupWise
- Item 4: The account running the Wizard will need Read access to the
users’ mailboxes. A best practice is to delete all other proxy access,
as the Wizard sometimes gets confused when reading proxy access.
- Item 5: Although not mandatory, a welcome message to users explaining
how to access old calendars and welcoming them to the new messaging
environment is helpful.
Tip: A utility called GroupWise Bulk (GWBulk), written by Microsoft
Consulting Services, is available to help automate many of the cumbersome
Table 2 tasks. This tool, provided “as is,” isn’t formally supported by
Microsoft; however, the source code is available should you wish to make
any modifications or add functionality yourself. While GWBulk is functional
and can save a large amount of time during preparation and migration,
it should be tested in your specific environment.
Running the Wizard is a very straightforward process. However, there
are a few catches:
- If you receive a “duplicate error” after selecting the account you’re
migrating, find the mail-enabled contact created by the Novell GroupWise
Connector and delete it. Depending on which domain controller you’re
authenticating to, you may need to wait for replication to catch up
before running the Wizard again.
- Having accounts other than the migration account with proxy access
to the existing GroupWise account will cause a failure.
- After the Wizard finishes running, use Outlook or OWA to check that
mail has migrated successfully. If so, delete the user from GroupWise.
If you don’t delete the user and only change the “visibility” to “hidden”
in GroupWise, existing GroupWise users will still be able to send mail
to the user by using the user’s alias name, which will resolve via LDAP
in GroupWise even though the user’s hidden. The newly created Exchange
user will be replicated to GroupWise and added to the GroupWise Address
Book. This should happen within a few minutes.
Note: If you choose not to delete the GroupWise user for any reason,
you may end up with a reply problem, as you’ll lose the legacyExchangeDN
from the contact object.
The Wizard will migrate users’ calendars, but it isn’t fun for
users to export the calendar entries back into Exchange. The Wizard pulls
all the calendar entries from GroupWise, inserts them into a Schedule+
file, then attach it to an e-mail for the user. This e-mail will normally
be the first one in the user’s inbox, which makes it easy for the user
to find. After the migration, the user must save the file and then use
the Import utility to import the file into Outlook. In Outlook XP, the
message is the first one in the inbox; when the user runs Outlook for
the first time it will prompt the user and ask if he or she wants it to
import the file automatically.
This is a complicated process for the user; however, I’ve seen hundreds
of calendar appointments come across and get imported into Outlook just
fine. Another positive aspect is the fact that this all happens as part
of running the Wizard. The downside to this process is that successfully
completing the task of importing calendars falls squarely on the shoulders
of the users. I haven’t found any helpful shortcuts for the user other
than using a third-party utility as mentioned earlier.
Problems to Avoid, Lessons Learned
Use the same password for all accounts. It makes using the Wizard
The migration account must be in the same GroupWise post office as the
accounts you plan to migrate. Simply create a migration account for each
post office (and try to migrate one post office at a time so you can use
the same account).
To migrate accounts, the Wizard must point to the GroupWise domain that
contains the post offices with the users who need to migrate. If the Wizard
can’t communicate with the post offices in secondary GroupWise domains—even
if the Wizard points to the primary GroupWise domain—users from these
post offices can’t be migrated.
The Wizard’s much faster when the GroupWise server is in direct-access
mode rather than client/server mode. Direct-access mode requires configuration
on both the client and server sides.
If the GroupWise user has a nickname, remove it. The Wizard incorrectly
grabs the nickname field instead of the user’s alias.
You may encounter a situation in which some accounts are still unable
to migrate, even though the migration account was granted Minimum User
Access rights on every GroupWise account. If that occurs, explicitly grant
the migration account all proxy rights to the user’s account.
Free Is Good
The Wizard has some limitations; still, it’s provided free with
Exchange and may provide enough functionality for most projects. With
the current economic environment, where saving every dime counts, you
may not be able to afford third-party migration products. In that case,
the Migration Wizard looks even better. But remember, as with any project,
the key to success is lab testing and developing a good project plan.