One way to migrate from Exchange 5.5+ org to Exchange 2003 Sp1 org


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

Comments (5)
  1. Briam says:

    Can you list a sample of a Control file you might use for 5.5 to 2003 migration?

  2. Joseph R. Worrall says:

    Ted —

    We have been having problems with Mailmig that prevent IMF from working in Exchange 2003 mailboxes cloned from Exchange 2000 systems where the Exchange 2000 user’s have previously created their own mailbox folder named "Junk E-mail" using Outlook 2000 or Outlook XP. It appears that the Exchange 2003 mailbox’s Junk E-Mail folder is not initialized properly as a system folder/etc and no email is ever moved from INBOX to Junk E-mail regardless of the SCL settings. User’s are also gettings messages that the SAFE/BLOCKED senders list is full when there are NO entries in any of these lists. We have opened Case SRX040820603979 on this. Can you help?

  3. Ted Kolvoord says:

    Briam, here is a sample. (see the Exchange Server Deployment Guide for much more details, especially Appendix B.

    http://www.microsoft.com/downloads/details.aspx?FamilyId=77B6D819-C7B3-42D1-8FBB-FE6339FFA1ED&displaylang=en )

    Mode,exchange
    Accounts,c:ntstempaccounts.txt
    PostOffice,mig55
    Exch55,True
    ExchStoreDN,CN=Mailbox Store (MIG-SOURCE-EN),CN=First Storage Group,CN=InformationStore,CN=MIG-SOURCE-EN,CN=Servers,CN=First Administrative Group, CN=Administrative Groups, CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mig-source,DC=extest,DC=contoso,DC=com

    Container,OU=Test,DC=mig-source,DC=extest,DC=contoso,DC=com
    TargetDC,migDC

  4. Ted Kolvoord says:

    Joseph,

    I don’t know enough about Outlook and how it works with SCLs to help.

    I didn’t see any info in the SR about the SAFE/BLOCKED list issue, so you might want to make sure PSS knows about that.

    Ted

  5. We used solutions from Priasoft that helped with.. says:

    Cleanup, planning, migration, and all without touching a desktop and without the normal "pain" factor.. Very good solution and worth checking out if you need some real power beyond what MS offers. http://www.priasoft.com

Comments are closed.