Over the past year, I've described techniques for making effective and efficient use of the Active Directory Connector (ADC), connection agreements (CAs), and Active Directory (AD) organizational units (OUs) to provide good interoperability between Exchange 2000 Server and Exchange Server 5.5. The "Related Articles" box, page 11, lists articles about these topics. Now, let's move on from these coexistence infrastructure foundations and discuss different approaches for moving users from Exchange 5.5 mailbox servers to Exchange 2000 mailbox servers.
You can take several approaches to moving users. This month, I discuss the most obvious approaches: in-place upgrades of Exchange 5.5 servers and introducing new Exchange 2000 servers into existing Exchange 5.5 sites. Not surprisingly, both approaches have advantages and disadvantages. Let's find out what they are.
In-Place Upgrades of Exchange 5.5 Servers
Conceptually, an in-place upgrade of an Exchange 5.5 mailbox server to an Exchange 2000 mailbox server is straightforward. You put the Exchange 2000 CD-ROM in the drive and run setup.exe. Of course, you need to facilitate this process with a little preparation.
All Exchange 2000 mailboxes must be associated with a Windows 2000 user account in a one-to-one relationship. Accordingly, these Win2K user accounts must already exist before you start the Exchange 5.5 upgrade process. You can create these accounts in several ways:
- Perform an in-place upgrade of the Windows NT 4.0 domain so that it becomes a Win2K domain.
- Migrate NT 4.0 accounts to a Win2K domain by using migration tools such as the Microsoft Active Directory Migration Tool (ADMT), NetIQ's Domain Migration Administrator, BindView's bv-Admin for Windows 2000, or Quest Software's FastLane Migrator.
- Use the ADC to create Win2K user accounts.
- Manually create Win2K accounts.
You can obtain information about how to use the ADC to create accounts from the Upgrading and Coexisting document in the Docs directory on the Exchange 2000 CD-ROM and information about creating Win2K accounts from the Win2K online Help.
The upgrading process has platform prerequisites, too. Whether or not you use the ADC to synchronize Exchange 5.5 mailbox data to create Win2K user accounts, you must have an ADC server in place, although you don't need to install the ADC on a separate hardware system. You need an ADC for three reasons. First, the Forestprep operation (which prepares the Win2K forest for Exchange 2000) uses the ADC to join the Exchange 5.5 organization. Second, upgrading the first Exchange 5.5 server to become an Exchange 2000 server creates a Configuration CA (ConfigCA) to synchronize configuration information from the Exchange 5.5 Configuration container to the AD Configuration Naming Context. Third, as you upgrade each Exchange 5.5 mailbox on the Exchange 5.5 server to Exchange 2000, attributes of the user mailbox (e.g., msExchHomeMDB) are modified to reflect the new Exchange 2000 configuration. You must have a mechanism to write these modifications back to Exchange 5.5, and accordingly you must have the appropriate CAs in place to synchronize Exchange 2000 attribute data to Exchange 5.5 mailbox attributes.
To run Exchange 2000, you must be running at least Win2K on the server you're upgrading and Exchange 5.5 Service Pack 3 (SP3). In general, you should be running the latest service packs (i.e., currently Win2K SP2 and Exchange 5.5 SP4) because they usually contain the most important and relevant fixes to products. Also bear in mind that in a multisite environment, you should have at least one Exchange 5.5 server running SP3 in each site in which you plan to perform bidirectional ADC-based directory synchronization. However, as you do with any other major change to a platform, be sure to test these combinations in your lab before you perform the operations on your production servers.
Performing the upgrade is relatively straightforward. Setup.exe detects the Exchange 5.5 components that you've installed on the system and displays the appropriate upgrade options in the UI, as Figure 1 shows.
The time required for the upgrade process depends primarily on the size of the Exchange databases—the private and public Information Stores (ISs). Figures from Microsoft and imprecise testing suggest that on well-performing systems, you can achieve upgrade rates of about 25GB per hour for the IS databases. You might expect this level of performance on a dual-processor Pentium III system with 1GB of RAM and a well-designed I/O subsystem. Obviously, this rate depends on the configuration of your I/O subsystem and the volumes dedicated to hosting your Exchange 5.5 databases. If you host a 25GB database on a 36GB drive with a basic disk controller, your upgrade time will be considerably longer than 1 hour. However, if you host the same database on a RAID 0+1 set on multiple spindles with a fast disk controller, you might expect a significantly shorter upgrade time.
The upgrade time is optimized because the upgrade process updates only the minimum amount of information in the database as the process executes. The remaining modifications to the database are deferred until Exchange 2000 subsequently mounts the database. Then, a background thread processes the database while it's available to users. This background process can have an effect on performance—resulting in longer response times for users—for the duration of the background upgrade. However, you can force the upgrade process to finish in the foreground by dismounting the database and running an Eseutil /f operation. When the upgrade is completed, you can remount the database and make it available to users. Although the upgrade to the final database format takes less time if you dismount the database, this approach makes the database unavailable to users longer.
Advantages. Performing in-place upgrades of servers is an attractive proposition for at least two reasons. The in-place upgrade to an Exchange 2000 environment uses the same hardware as an Exchange 5.5 environment; you need no additional hardware. In addition, for smaller and less sophisticated environments (e.g., in which only a handful of Exchange 5.5 servers exist in a handful of sites), an in-place upgrade is the most straightforward and obvious approach. An in-place upgrade is especially appealing if you have a reasonably small number of NT 4.0 accounts to migrate to Win2K. Performing an in-place upgrade of a domain to Win2K, coupled with an in-place Exchange 5.5 server upgrade, requires less effort in terms of migration tools and coexistence planning.
Disadvantages. In-place upgrades have some drawbacks, however. Exchange 2000 can use different hardware than Exchange 5.5, especially if you want to make use of the advanced Exchange 2000 functionality with respect to multiple databases and storage groups. For this reason alone, if you have a large Exchange 5.5 server (i.e., a server that supports many hundreds of users), you might find the existing hardware configuration, in terms of disks and I/O controllers, unsuitable for Exchange 2000. In this case, you need either to replace the hardware or to schedule significant amounts of downtime to reconfigure the I/O subsystem.
Performing an in-place upgrade means that your level of granularity for Exchange 5.5 to Exchange 2000 migration is server based. If something goes wrong during the upgrade, you must perform a complete recovery of the server—this approach is all or nothing.
For the duration of the upgrade process (and both before and after the upgrade), the Exchange server is unavailable to users. The amount of downtime depends on the size of the databases (both private and public).
In addition, in-place upgrades introduce some instability. You're substantially modifying a stable Exchange 5.5 server to make it an Exchange 2000 server. This process is fraught with dangers (although all are recoverable through restores), and you're relying on the correctness of the upgrade code to clean up old DLLs or services that are no longer required. Alternative approaches that I'll discuss later yield the same results (i.e., user mailboxes moving from Exchange 5.5 to Exchange 2000) with less inherent risk.
Restructuring with New Exchange 2000 Servers
More complex environments tend to rely on more sophisticated techniques for migrating users from Exchange 5.5 mailbox servers to Exchange 2000 mailbox servers. Before you run the Forestprep operation, you must decide whether you want your new Exchange 2000 organization to be part of the existing Exchange 5.5 environment. If you elect to create a new Exchange 2000 organization, the in-place upgrade approach and the restructuring approach that I'm about to describe are both unavailable to you. (I'll discuss how to deal with migration of a new Exchange 2000 organization in Part 2.) However, if you elect to intimately link your new Exchange 2000 organization to the existing Exchange 5.5 organization, more flexible migration options become available.
Having a single Exchange organization (albeit one that spans both Exchange 5.5 and Exchange 2000 systems) means, more or less, that all servers in an Exchange 5.5 site are peers. The interoperability capabilities of Exchange 2000 let you install an Exchange 2000 server into an existing Exchange 5.5 site as if it were any other Exchange server. To install an Exchange 2000 server in an Exchange 5.5 site, you must meet a few prerequisites:
- At least one Exchange 5.5 server in the site must be running SP3. However, you can have any mix of server versions elsewhere in the site, including other service packs and even Exchange 5.0 systems.
- An ADC server must be available to host the ConfigCA that you use to synchronize configuration information between Exchange 5.5 and Exchange 2000.
- Win2K user accounts must be available to host the Exchange 2000 mailboxes. You can create these accounts by any of the upgrade methods I described earlier.
- Appropriate CAs must be in place to synchronize Exchange 2000 mailbox attributes back to Exchange 5.5 mailboxes as mailboxes migrate to Exchange 2000 mailbox stores.
After you've established an Exchange 2000 server in an Exchange 5.5 site, you can easily migrate Exchange 5.5 mailboxes to Exchange 2000 mailboxes. You don't need a special migration tool, just an option that's available by default from the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. From a Win2K server on which the Exchange 2000 management tools have been installed, use the Active Directory Users and Computers snap-in to select the Win2K account associated with the Exchange 5.5 mailbox (either the user's logon account or the ADC-created object), select Exchange Tasks, then choose the Move Mailbox option, as Figure 2 shows.
When you choose the Move Mailbox option, you must select an appropriate target Exchange server and database. Typically, the move will be from an Exchange 5.5 database to an Exchange 2000 database, but moves in the reverse direction are equally valid—a helpful capability if you need to roll back your migration! Note that you can use this functionality to move mailboxes only between servers within an Exchange 5.5 site (or an Exchange 2000 administrative group/routing group couple): You can't move users from an Exchange 5.5 server in one site to an Exchange 2000 server (or another Exchange 5.5 server for that matter) in another site. The Move Mailbox utility doesn't preserve single-instance storage, even if you move users from the same source database to the same target database. However, for many organizations, the single-instance ratio isn't high enough to be concerned about. Tony Redmond, "Does Single-Instance Storage Matter Anymore" (September 2001), discusses the diminished importance of single-instance storage in Exchange 2000. Also, keep in mind that if you move a 100MB mailbox to the destination server, Exchange will create 100MB worth of log files.
The Move Mailbox feature uses Messaging API (MAPI) to make connections to the source Exchange 5.5 server and the target Exchange 2000 server. As a result, performance is quite slow. You can expect to be able to move about 20MB of mailbox data per minute, but this rate depends on the I/O subsystems of both the source and target systems, network connectivity, and server workload. Faster disks, faster disk controllers, and a higher disk spindle count generally improve performance characteristics. You can also improve performance by running the move operation directly on the Exchange 2000 server instead of on an administrative workstation. You don't need to move just one mailbox at a time. You can select multiple Exchange 5.5 mailboxes and move them all in one operation, perhaps moving a whole department or group of users overnight or over a weekend. Figure 3 shows the progress of such a mailbox move.
Advantages. The restructuring approach that I've described has several features that make it a valid means of migration for users:
- The migration activity has much finer granularity than the in-place upgrade. Migration takes place at the mailbox level, not the database level, so if something goes wrong, the effect of the failure isn't as great.
- Restructuring disrupts service considerably less than in-place upgrades. You don't need to take the Exchange 5.5 server offline (as you must do with the in-place upgrade) to migrate users. If you have 100 users homed on a server, only the user whose mailbox you're migrating can't access the system.
- You don't need to upgrade all your legacy Exchange servers to Exchange 5.5 SP3. The only requirement is to have at least one server in the site running Exchange 5.5 SP3; other servers can be running any Exchange version (i.e., Exchange 5.0 and later).
- If server consolidation is one of your Exchange 2000 migration goals, the restructuring technique is useful because it lets you adopt the "Pacman" approach to consolidation and migration—the single Exchange 2000 server gobbles up the Exchange 5.5 mailboxes. You can install a large Exchange 2000 server into an existing Exchange 5.5 site and migrate user mailboxes from several Exchange 5.5 servers to your single Exchange 2000 server.
- Finally, from an operations perspective, the restructuring approach just plain makes sense. The approach is akin to the concept of rolling upgrades associated with clustered systems: You install a new system into the mix and move users at a pace that suits your environment with minimal effect on users.
Disadvantages. Of course, life is not altogether pleasant with the restructuring approach. A significant drawback is that you must use new servers to host the Exchange 2000 server in the Exchange 5.5 site. In many instances, you can mitigate the effect of this requirement by reusing Exchange 5.5 servers from which you've migrated users. As you decommission an Exchange 5.5 server, you can reinitialize it with a new Win2K OS installation, then insert it into another Exchange 5.5 site as an Exchange 2000 server. In a sense, this technique is a form of server upgrade—although somewhat convoluted—that exploits the benefits of restructuring. Another significant drawback is the administration time and coordination effort required to move large numbers of mailboxes. However, this time can sometimes be beneficial because it gives organizations time to phase in new usage policies, conduct training classes, etc.
Tailor the Decision to Your Environment
The decision between in-place upgrades and restructuring is never easy. Each technique has advantages and disadvantages, and as you must do in most aspects of IT, you need to balance the distinct advantages against the associated costs. For environments with few users and a simple topology, the in-place upgrade makes sense. However, for environments with more users, more complexity, or a high need to maintain service levels or avoid risk, the obvious choice is to restructure. As the sidebar "Upgrading Exchange 5.5 Clusters," page 9, explains, upgrading clusters presents additional challenges. In a future article, I'll address some variations on the migration theme, including interorganizational migrations and scripting techniques and tools to make migration simpler.
|Related Articles in Previous Issues|
You can obtain the following articles from the Exchange & Outlook Administrator Web site at http://www.exchangeadmin.com.|
"ADC Filtering and Object-Matching," January 2001, InstantDoc ID 16139
"The Site Replication Service," October 2000, InstantDoc ID 15545
"5 Things They Never Told You About the ADC," August 2000, InstantDoc ID 9131
Windows 2000 Magazine Articles
You can obtain the following articles from the Windows 2000 Magazine Web site at http://www.win2000mag.com.
"Real Life ADC Deployment, Part 2," June 2001, InstantDoc ID 20722
"Real Life ADC Deployment, Part I," May 2001, InstantDoc ID 20395