Migrating Microsoft Mail Users and Groups to Exchange

Follow the author step by step through migrating users and shared folders from MS Mail to Exchange.

Steve Jones

August 31, 1998

14 Min Read
ITPro Today logo

Converting from Microsoft Mail (MS Mail) to Microsoft Exchange Server requires setting up the system infrastructure and migrating users. In "Migrating Microsoft Mail Gateways to Exchange Server" (July 1998), Robert O'Connell described preparing the backbone (i.e., gateways and connections) for the migration. In this article, I'll discuss moving users (user mailbox data, Personal Address Books—PABs—and schedule and calendar data), groups (distribution lists—DLs), and shared folders. The sidebar "Assess the Current Environment" presents some questions you can use to evaluate which migration options are best for your organization.

To convert users to Exchange, you need to clean up existing message files, create the user migration schedule, migrate the post office groups, and migrate users and shared folders. You will need to customize the process for your organization; for example, the location of the message files will affect your migration process.

Clean Up Existing Message Files
The first step in the migration process is to prepare the existing message files for conversion by removing any unnecessary mail. This step helps speed the migration process and eliminates wasted space on the Exchange server. Many organizations ignore this step because it can be a hassle to implement and an annoyance to users. However, many users have more than 100MB of mail in their Deleted Items folder alone, so cleaning up is a good practice. You can implement this process simply by asking users to delete any old or unnecessary mail. A more gutsy approach is to use MMFClean, an MS Mail 3.5 utility for purging mail from .mmf files based on a message's age, size, and priority. For example, you can use this utility to remove all messages that are older than 10 days and larger than 2KB. Be careful: This utility can wreak politcal havoc, especially if you don't inform users before you run it and you remove sensitive mail. Before you run this utility, be sure that you back up the entire post office and that no users are active when you run the program. The Microsoft Knowledge Base article "PC Adm: Microsoft Mail MMFCLEAN.EXE Utility" (http://support.microsoft.com/support/kb/articles/q117/6/93.asp) explains how to obtain and use MMFClean.

Users who have large .cal or .scd files need to archive old Schedule+ data. In Schedule+ 1.0, you access the function from File, Create Archive; in Schedule+ 7.0 and higher, you archive from File, Archive. This precaution might seem insignificant, but I know users with .cal files larger than 125MB.

Create the User Migration Schedule
Next, to disrupt business as little as possible, create a schedule for migrating users. First, migrate delegates and assistants with their associated partners to avoid such problems as an assistant being unable to maintain a supervisor's schedule during the migration. Second, migrate a shared folder and its users at the same time. Because Exchange users can't access MS Mail shared folders, users might lose access to shared folders if you don't migrate them at the same time you migrate the folder. Finally, because users send most of their mail to their coworkers, simultaneously migrate users who work together. Migrating these users together can eliminate potential mail transfer delays and preserve messaging client feature functionality (e.g., sharing contact lists, assigning tasks to one another) between the users.

Migrate the Post Office Groups
The next step is to migrate groups to DLs. Groups and DLs are both mechanisms for using one address list entry to send mail to a collection of users, but Exchange DLs offer many advantages over MS Mail groups. Let's examine these advantages:

  • The ability to easily create cross-server and cross-post office DLs that you can include in directory synchronization. Creating and maintaining cross-post office groups in MS Mail is a headache because you have to import external group members into the post office address list on each post office that will have a copy of the group; that is, you must re-create the group on each post office that wants to use the group.

  • Virtually unlimited membership. The ability to nest DLs means that DLs effectively have no membership limits.

  • Automatic updates. The Exchange Migration Wizard automatically updates DL membership during the migration. If you have set up directory synchronization between MS Mail and Exchange, when the Migration Wizard migrates a mailbox from MS Mail, the wizard assigns the new Exchange mailbox the same DLs in which the corresponding custom recipient (mail recipient on a foreign mail system) was a member. You must migrate groups to DLs before migrating users, however, to avoid having to manually add DLs to each mailbox on conversion.

  • Delegated list management. Administrators can delegate DL maintenance to an owner, who can maintain the list through the Outlook client.

I prefer to migrate all groups to DLs before migrating any users. That way, I have one less thing to worry about, and I can immediately take advantage of DL features. However, you can't always migrate all groups first, because you either have a large number of groups or groups are in remote sites that you can't access easily. So keep in mind that, to avoid orphaning the user from the group when you convert, you must migrate a group to a DL before you migrate any particular group member.

Migrating groups to DLs isn't easy, because you can't automate the process. If you have only a few groups, the best approach is to manually re-create the groups before you migrate the users. If you are migrating large groups or a large number of groups, you can use the Exchange Administrator program's Directory Import command to create DLs.

First, create a Comma Separated Values (.csv) file in Exchange import format (refer to 3impexp.doc in the DocsWord_DocsMigration directory on your Exchange CD-ROM for more information). You can use the header.exe tool from the Microsoft BackOffice Resource Kit to create a .csv file that contains all possible Exchange import field headings. The .csv, or import, file must contain at least the following five fields: Obj-Class, Display Name, Directory Name, Owner, and Members. Obj-Class must be the first field in the import file header. The Obj-Class field defines the type of object you are creating when you import the file; in this case, you must set the Obj-Class field to DL. The Display Name field is the name that will display in the Global Address List (GAL). Follow your DL naming convention when defining this field. The Directory Name field uniquely identifes each object within Exchange. Follow your DN naming convention when defining this field. The Owner field defines a person, not necessarily an administrator, who can update this DL's membership via the Outlook Address Book (OAB). The Members field must contain the directory names of the recipients you want to add to the DL. Screen 1 shows the import file I used to create a DL called Fun Time.

After you create this import file, choose Tools, Directory Import in Exchange Administrator to import and create the DLs. Manually creating these import files can take a long time. Remember that Microsoft Excel has a limit of 255 characters per cell, and the Members field can easily be more than 255 characters. Excel will truncate any characters after the 255th, leaving you with a potentially unusable file.

An alternative is to use the GIMPORT program with the ­x option from the MS Mail Resource Kit to export a list of groups and group membership to a file. Export a complete list of MS Mail custom recipients from Exchange. Write a program or a query in Access to match records between the two files to output a .csv file that you can import into Exchange, thereby creating the DLs. If you have many large groups, this tool saves you time.

Remember to re-create DLs in the same site as the custom recipients you are migrating. If you try to migrate a custom recipient to a DL that someone created in another site, you will receive an error (event ID 284) in the Application log. This error tells you that the Migration Wizard is trying to modify a DL that the wizard doesn't have sufficient rights to. The error occurs because the Migration Wizard is attached to a server other than the home server of the DL. In this case, you must manually re-create the DL memberships.

When you convert groups to DLs, keep in mind that message traffic will increase as messages pass back and forth between Exchange and MS Mail. DLs expanded on an Exchange server cause at least two messages to travel between Exchange and MS Mail. Exchange will send one message to each MS Mail post office that contains DL members. Be aware that Exchange DLs don't appear in bold type in the MS Mail GAL: DLs look like users on another post office.

Migrate Users and Shared Folders
The final step is to migrate users and shared folders. You can migrate user information (e.g., email messages and calendar data) to Exchange in two ways: with the Exchange Migration Wizard or with the Outlook import function.

Migration Wizard. The Migration Wizard is the best migration option if your messaging and schedule data is on the MS Mail post office. Using the wizard is the easiest method to quickly migrate many users to Exchange. As Screen 2 shows, the Migration Wizard can use existing information to create new mailboxes and to migrate email messages, shared folders, PABs, and schedule information. The wizard creates Windows NT and Exchange accounts and converts users' email messages to Exchange in bulk from a central location. This process can speed the conversion by migrating the mail and calendar data before you touch users' PCs. You can accelerate the migration even more by running the Migration Wizard on the Exchange Server you're migrating the data to and by having a local copy of the post office that you are migrating. Another Migration Wizard option is to migrate email, PABs, and schedule information to a .pst file. This option works well if you want to store mail on the users' PC or a LAN.

The Migration Wizard can perform a one-step or two-step migration. The one-step method extracts information and imports it directly into Exchange. This method is the fastest option if you don't want to modify any mailbox information and if an NT account doesn't already exist.

The two-step method first creates a user list file, in Exchange import format. You can modify this file to add information—first and last names, initials, phone numbers, or any other mailbox property. Second, the Migration Wizard uses the modified file to create mailboxes and migrate the data. The two-step method is better if you want to add information to the mailbox account before you migrate. It is also the best option if NT accounts already exist, because you can assign an NT account by using the Assoc-NT-Account field in the migration file, as you can see in Screen 3.

In either the one-step or the two-step method, selecting the Shared Folders option migrates all shared folders on the post office to a top-level public folder called MS Mail Shared Folders. During the conversion, the wizard will prompt you to set the default access permissions on the new public folders, as you see in Screen 4. Because you can't selectively migrate shared folders, open Exchange Administrator after the conversion, delete any unnecessarily migrated folders, move the correctly migrated folders into their final destination, and then set the permissions as they were in MS Mail. Because Microsoft doesn't provide a way to replicate shared folders between MS Mail and Exchange, you need to simultaneously migrate all users of a shared folder at as close to the same time as possible.

When migrating MS Mail PABs, be aware that the Migration Wizard doesn't migrate DOS personal address lists. However, it does migrate MS Mail (Windows client) PABs to a message attachment in the Exchange Inbox. You can save this attachment and add it as a PAB information service to the Messaging API (MAPI) profile. The wizard migrates personal groups to personal DLs in the Exchange PAB.

When the wizard migrates schedule information, it migrates Schedule+ 1.0 .cal files but not Schedule+ 7.0 .scd files. If you have Schedule+ 7.0 .scd files, you must use Outlook's import function. If you use the 32-bit Outlook client, migrating schedule information probably is a waste of time because the Migration Wizard converts the schedule data to Exchange in Schedule+ format. When Outlook starts, however, it must convert the data a second time from Schedule+ format into Outlook format. In either case, when you import with Outlook, you need users' Schedule+ password because Outlook will prompt the user for the old Schedule+ password the first time it starts after the migration.

One way to avoid migrating the calendar data twice and still get the job done quickly is to use the Outlook Migration Kit. This kit automates Outlook's ability to import Schedule+ .cal and .scd files in bulk to Exchange Server in Outlook format. To obtain the Outlook Migration Kit, contact the Exchange Server group of Microsoft Product Support Services.

The Migration Wizard lets you select the recipients container in which you have created the new mailboxes and a template account to use as a basis for those mailboxes. A template account lets you predefine mailbox attributes (e.g., company, address) that the wizard will copy to each new account that uses the template. You can create NT accounts based on the alias (the name that the email system uses internally) field for the new mailboxes. If you use the same name for the alias field and the NT account, you can use tools such as profgen.exe, which captures the currently logged-on username, to automatically create MAPI profiles with correct information. You can create NT account passwords randomly or make them the same as the NT account name. See the sidebar "Tips for Using the Migration Wizard," page 12, for more information about this process.

Client Import Facilities
The Outlook client provides many of the same migration functions as the Migration Wizard. However, you must use these import functions one user at a time. Outlook imports .mmf files, personal stores (.pst files), Schedule+ 1.0 and 7.0 files, Schedule+ Interchange (.sc2) files, .pab files, and many other file formats, including Lotus Organizer and Symantec's ACT!. You can migrate .mmf files to either a .pst or a server-based store. Outlook migrates PAB entries in the .mmf files directly to an existing .pab file. You must have installed the PAB information service for this conversion to work. Outlook migrates personal groups in the .mmf to personal DLs in the .pab file. To import DOS client data, you must manually install the MS Mail information service and download the messages to a .pst file or to the server store. Outlook doesn't support importing DOS personal address lists. Also, Outlook doesn't support migration of shared folders, and it won't automatically create mailboxes or NT accounts.

I use the Outlook import facilities to supplement the Migration Wizard. You must use Outlook when the .mmf, .cal, or .scd file is on the workstation. Or, if the Migration Wizard fails to migrate an .mmf file, I log on to MS Mail, create a backup copy of the .mmf, and then import it with Outlook. If you have to import data from third-party products, your best bet is to start with Outlook.

To recap, if you need to bulk import mail accounts, create mailboxes, create NT accounts, or migrate shared folders, the best option is the Migration Wizard. I generally use the Migration Wizard to migrate everything except schedule information. For schedule information, I use Outlook. The Migration Wizard-Outlook combination can handle most situations: different versions of Schedule+, migration from local or server-stored mail files, migration to local or server message stores, shared folders, and DOS and Windows mail data. The only glaring omission from the Migration Wizard is the lack of a utility to migrate groups.

You can create Exchange mailbox accounts in advance in either client migration method; however, you must create the accounts in advance, if you use the client import utilities. Creating the Exchange accounts before migration will shorten the migration time. Be sure to hide these new accounts from the GAL to prevent users from sending mail to them before they are active. Figure 1, page 11, shows a header you can use as a starting point for creating mailboxes.

You can use the information in this article as the basis for planning your migration options. However, many other questions and scenarios can affect your migration. For more information about migrating from MS Mail to Exchange, refer to "Migrating from Microsoft Mail for PC Networks," msmailpc.doc in the Migration folder of your Exchange Server CD-ROM.

Read more about:

Microsoft
Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like