Today I want to write about how to use the Exchange 2003 Sp1 (hereafter called E2003 Sp1) Migration Wizard (hereafter called Mailmig). There have been some real good posts recently about how to use ExMerge for disaster recovery and migrations. Please note here that Mailmig is for migration between different Organizations only. Mailmig has some signficant advantages over Exmerge, such as persisting x500 addresses, OST preservation, account matching, etc.. and should be the tool of choice for most migrations.
So, how do I use this darn Mailmig thing? Well there are two general modes, UI based, and command line based. Both modes will take command line flags that change the behavior of the tool. I’ll look at some of the possible flags to pass in, describe what they do, and briefly describe why you might want to use them. Later I might talk about constructing control files for command line migrations, but that’s too much work for a sunny Wednesday while I wait for my XpSp2 client to spin up.
First off, the wizard is located in your exchange bin directory, in my case, I go to c:\program files\exchsrvr\bin\. The executable is called mailmig.exe, and you can get usage by typing: "Mailmig /?"
The most important switch is the /m, or clone mode, switch. When you use the /m switch, the wizard copies folder IDs and other special identifiers to ensure that your rules (among other things) can continue to work after the migration. Clone mode (/m) requires that the mailbox be un-initialized (New! Untouched!). If you run the migration wizard with the /m switch, and the destination is already initialized, MailMig will either semi-silently fall back to merge mode, or fail altogether. (There is an event or two in the EventLog if this happens, but the point is it won’t do what you wanted.)
So how do I prevent a mailbox from being unintentionally initialized? The /D flag will help here. This will cause MailMig to set an attribute on the mailbox so that mail will be bounced from this user and redirected to the original source mailbox. (This turns the mailbox into an odd mixture of a contact w/ a forwarding address and a mailbox for a time.) You’ll have to be fast to see this in action as Mailmig will remove the flag as soon as it can. The domain part of the flag should be equal to a routable SMTP domain for the user. For example, in my case I could use /d:microsoft.com, and Mailmig would stamp the attribute targetAddress with something like: someguy AT microoft.com on my mailbox.
So you’ve cloned the mailbox, but while you were doing that more mail showed up in the original mailbox! What now? Use Mailmig with out any flags, this will cause it to merge the mailboxes in much the same manner that ExMerge does; no duplicates will be produced. It should also be significantly faster the clone mode.
Then there is the /f flag for additional logging (works only for exchange to exchange migrations). This will produce some additional logging which may supplement the eventlog in case of problems.
I’m very fond of using the /S flag for command line migrations as it causes Mailmig to exit when complete instead of remaining at the summary screen. This is useful for post migration automation.
So a typical first time migration might run with a command line that looks like:
C:\exchsrvr\bin\Mailmig /m /c:<controlFile> /d:microsoft.com /s /f:c:\myMigrationLogFile.txt /a:myDomain\myAdministrator /p:*
Subsequent merges might look something like:
Mailmig /s /f:c:\myMigrationLogFile.txt /c:<controlFile> /a:myDomain\myAdministrator /p:*
- Ted Kolvoord
