When the time comes to move users from an Exchange Server 5.5 environment to an Exchange 2000 Server environment, you can use several tools to facilitate the process. The articles in the Related Reading box, page 9, provide background information about migrating to Exchange 2000. Simple scripts let you automate the mailbox-move process. If you need to perform an interorganizational migration, Exchange 2000 Service Pack 1's (SP1's) new Exchange Migration Wizard might be just what you need.
Automating Mailbox Move Operations
In a previous life, I was a reasonable C and Visual Basic (VB) programmer, but I haven't had the patience to keep up with new languages and developments. However, Microsoft has worked hard to make Exchange 2000 management operations, among other tasks, easily accessible to even rudimentary programmers like me. You can use relatively easy coding techniques that use Collaboration Data Objects (CDO) and Collaboration Data Objects for Exchange Management (CDOEXM) to write utilities for processing Exchange 5.5 mailboxes and to move their contents to Exchange 2000 mailbox stores.
Listing 1, page 8, for example, shows a simple VBScript code extract that you can use as the basis of a program to migrate an Exchange 5.5 mailbox to Exchange 2000 (assuming that the Exchange 2000 server is in the same mixed-mode administrative group). The code in Listing 1
- passes as parameters to the function the distinguished name (DN) of the user to be moved and the DN of the target Exchange 2000 mailbox store
- instantiates the data source (i.e., the Exchange 5.5 mailbox) associated with the user
- calls the MoveMailbox method against the instantiated mailbox and specifies the target for the mailbox-move operation
This code extract works by moving one mailbox at a time—you pass the details through as parameters to the function. However, you can also use Lightweight Directory Access Protocol (LDAP) queries to process multiple mailboxes. You can use the code sample that Listing 2 shows as the basis for a function that would move multiple mailboxes from Exchange 5.5 servers to Exchange 2000 servers. The code in Listing 2
- passes as parameters to the script an LDAP search filter representing all users that will be moved and the DN of the target Exchange 2000 mailbox store
- determines the domain within which you're processing because the code needs this information to search Active Directory (AD)
- searches AD and returns those objects that match the LDAP search filter
- processes each element returned from the AD search—each element is a DN representing a user to be moved—and passes these elements to the MoveMailbox function that Listing 1 describes
The code in Listing 2 expects to have an LDAP query passed through as a parameter to the function. This LDAP query identifies the collection of objects to move from Exchange 5.5 to Exchange 2000. For example, you can use the command
MoveMailboxes.vbs "&(surname=M*) (extensionAttribute10=E55)" "Users MailBoxStore"
to let the code in Listing 2 move from Exchange 5.5 mailbox stores to Exchange 2000 mailbox stores all AD objects with a surname attribute that begins with M and an extension attribute 10 set to E55.
These code extracts are simplistic and lack robust coding techniques such as integrity checking, logging, and event handling. However, the extracts illustrate the power of CDO pro-gramming combined with Exchange 2000. When you have many users to migrate, automating the Move Mailbox functionality is a powerful technique.
When you're introducing code to automate a task, always thoroughly test the code before you use it in a production environment. In addition, move users' mailboxes only when users are logged off. The migration time varies with the number of user mailboxes.
Exchange 2000 SP1 Migration Wizard
Move Mailbox code similar to the scripts in Listing 1 and Listing 2 restricts you to moving mailboxes within one organization; you can't use these techniques for interorganizational moves. (The same restriction is true for the Move Mailbox Wizard in the Microsoft Management Console —MMC—Active Directory Users and Computers snap-in, which I described in "Moving Users to Exchange 2000, Part 1," October 2001.) In these days of company mergers, the problem of migrating from multiple and distinct Exchange 5.5 organizations to a single Exchange 2000 organization is common.
Before Exchange 2000 SP1, you could perform interorganizational migrations in two ways. You could use the Move Server Wizard to merge separate Exchange 5.5 organizations, then move servers within the merged organization. (For more information about the Move Server Wizard, see Tony Redmond's Windows 2000 Magazine article "How to Rebuild Your Exchange Organization," http://www.win2000mag.com, Instant-Doc ID 4697.) Or you could use the Exmerge utility available on the Exchange 2000 Server CD-ROM at support\utils\i386 to export user mailboxes to personal stores (PSTs), then subsequently import them into new Exchange 2000 accounts.
Although you can still use these methods, another approach is now available. Exchange 2000 SP1 automatically installs the Exchange Server Migration Wizard as a menu option from the MMC Exchange System Manager (ESM) console. The wizard facilitates straightforward migration of mailboxes from any Exchange 5.5 organization into an Exchange 2000 organization as long as the Exchange 5.5 organization name is different from the Exchange 2000 organization name. (You can't use this wizard for intraorganizational moves. To move mailboxes within a single organization, you must use the standard Move Mailbox options.)
The new wizard works in conjunction with a modified Active Directory Connector (ADC—available with Exchange 2000 SP1 as a replaced adc.exe file). As with other ADCs, you can set up interorganizational connection agreements (CAs) from an Exchange 5.5 organization to an Exchange 2000 organization. Unlike other ADCs, however, the SP1 ADC lets you create AD user objects with an interorganizational CA, as Figure 1 shows.
Shortly after you invoke the Exchange Server Migration Wizard (from Start, Menu, Programs, Microsoft Exchange, Migration Wizard) and click through the introductory screens, you can choose the Exchange 2000 server and the Exchange 2000 database to which you want to move your Exchange 5.5 mailboxes. This list is populated because the Exchange 2000 server enumerates the data from the AD Configuration naming context (NC—which holds most Exchange 2000-related information).
After selecting the target location, you must specify the source server on which the Exchange 5.5 users reside. Here's the first gotcha. When you enter the Exchange 5.5 server name, be sure to enter the NetBIOS version of the computer name. In my testing, my Exchange 5.5 server's name was Pulsar. Entering the Fully Qualified Domain Name (FDQN) pulsar.research .compaq.com didn't seem to work, despite a perfectly functioning DNS.
The second gotcha is that the wizard uses LDAP from the Exchange 5.5 Directory Service (DS) to enumerate all the users on that server who are available for migration. If you're running your Exchange 5.5 LDAP service on a nonstandard port (I was using 390 because my Exchange 5.5 server was running on a Windows 2000 domain controller—DC), you must explicitly specify the port number with the server name. Thus, after a few desperate attempts, I used the server name pulsar:390, as Figure 2 shows. As it turns out, this step is documented in the online Help, but I wish Microsoft would have automated the port selection or placed a separate data entry field on the form in which you can explicitly specify the port number.
At this point, you should be logged on to an account that's either the Exchange Site Service account or an account that has the service account's Admin privilege at the organization, site, and configuration levels of the Exchange 5.5 DS. Now, the migration wizard presents a list of Exchange 5.5 mailboxes that you can select for migration. After you select the appropriate mailboxes, you must select the AD location in which you want the wizard to create new Win2K accounts for the mailboxes or in which you want the wizard to search for Win2K accounts that already exist, as Figure 3 shows. This dialog box is similar to the one you see during a CA configuration when you select the AD target locations for the search and creation of Win2K accounts. (You probably used an interorganizational CA to create these accounts to provide a complete Global Address List—GAL.)
When you complete the configuration information, the wizard presents a summary of the Win2K account-creation or account-matching activities that it expects to perform. In the example that Figure 4 shows, my interorganizational CA has already created a Win2K account in the Users container, and the wizard has matched that account with the associated Windows NT account of the mailbox I'm moving.
The wizard's matching functionality is similar to the matching activity that the AD Cleanup Wizard and other migration tools use: To rectify or avoid creation of duplicate Win2K accounts, the tools try to match the SID of the Exchange 5.5 mailbox's associated NT account with either the object SID or the sIDHistory attribute of an existing Win2K user object. If the wizard finds a match, the wizard doesn't need to create a new Win2K user. If no NT account is associated with the Exchange 5.5 mailbox, the wizard creates a new user object.
Now, the migration process begins. Knowing the source Exchange 5.5 server, the mailboxes to migrate, and the target Exchange 2000 database to host the migrated accounts, the wizard uses remote procedure call (RPC) based Messaging API (MAPI) connections from the source server to migrate the mailbox directly to the appropriate mailbox store in Exchange 2000. Performance during this migration is roughly equivalent to the performance of the Move Mailbox Wizard from the Active Directory Users and Computers snap-in.
Migrating the 143 messages during the move operation that Figure 5 shows took 2 minutes and 26 seconds (a rate of about 18MB of data per minute); the mailbox in question contained slightly more than 40MB. This performance rate depends to a large extent on your system's hardware configuration, especially the number of spindles and the speed of the disks and controllers. I performed this migration on relatively old single-disk systems, so these figures might be conservative.
A couple of fine points about using the Exchange Server Migration Wizard caught me off guard. First, when you run the wizard and migrate mailboxes from Exchange 5.5 to Exchange 2000, you don't actually move the mailboxes. The original Exchange 5.5 mailbox remains intact on the Exchange 5.5 server, so in effect you're cloning the mailbox data. The impact of this behavior warrants some careful consideration. You might have some significant postmigration cleanup to carry out in the Exchange 5.5 environment unless you have a solid mail-routing and directory-synchronization infrastructure in place. Without a solid infrastructure, Exchange might still route SMTP mail, for example, to the old Exchange 5.5 mailbox and remain blissfully unaware of the new intended location in Exchange 2000. To minimize or avoid this problem, remove old Exchange 5.5 mailboxes after the migration, but make sure that you have good backups in case you need to revert to them.
If the Exchange 2000 Information Store service isn't running when you attempt the migration, the migration attempt will fail. However, the Exchange Server Migration Wizard doesn't prompt you to check whether the service is active or even whether the Exchange 2000 databases are mounted. The wizard lets you run through the migration exercise but does nothing. When I had this problem, I traced the reluctance of the Exchange 2000 Information Store service to start to a time skew of several hours between my Exchange 2000 server and its Global Catalog (GC) server.
You can choose from several approaches when you move users from Exchange 5.5 to Exchange 2000. Whether you take the conventional approach and opt for intraorganizational migrations—whether by in-place upgrades or restructuring—is a matter of choice and depends largely on your environment. Generally, such approaches are the most straightforward and also tend to be the most successful.
Certainly, interorganizational migrations have their place. However, in most cases you should use this approach only in environments in which diverse organizational structure mandates it. Although the mailbox migration I've described here isn't complicated, you need to consider many other factors, such as public folder interoperability, directory synchronization, mail routing, and MAPI profile integrity. In future articles, I'll explore some of these aspects in greater detail. Good luck with your migration!
EXCHANGE & OUTLOOK ADMINISTRATOR ARTICLE|
You can obtain the following article from Exchange & Outlook Administrator's Web site at http://www.exchangeadmin.com.
"Moving Users to Exchange 2000, Part 1," October 2001, InstantDoc ID 22161
EXCHANGE & OUTLOOK UPDATE ARTICLE
You can obtain the following article from Windows 2000 Magazine's Web site at http://www.win2000mag.com.
Exchange & Outlook UPDATE, "Exchange 2000 SP1 Adds New Functionality to the Migration Wizard," August 10, 2001, InstantDoc ID 22100
WINDOWS 2000 MAGAZINE ARTICLES
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com.
"20 Tips for Exchange Migration," October 2001, InstantDoc ID 22252
Getting Started with Exchange, "Keeping Things Moving," August 2001, InstantDoc ID 21521