Migrating from Exchange 2000 Server to Exchange Server 2003 is a straightforward process. Ultimately, the complexity of your environment and other factors, such as available resources and your budget, will determine the approach you take.
Exchange 2003 and Windows 2003
Because Exchange 2000 isn't supported on Windows Server 2003 servers (although you can run Exchange 2000 on a Windows 2000 member server in a Windows 2003 domain), you must upgrade to Exchange 2003 if you want to use Windows 2003. Exchange 2003 is supported on a Windows 2003 or Win2K platform. To run Exchange 2003 on a Win2K platform, the platform must
- be running Win2K Service Pack 3 (SP3) or later
- have Windows 2003 domain controllers (DCs) or Win2K SP3 (or later) DCs available
(For more information about Exchange and Windows interoperability, see "Exchange 2003 Deployment Fundamentals," September 2003, http://www.exchangeadmin.com, InstantDoc ID 39489.) These dependencies mandate that you use a specific in-place upgrade strategy for your Exchange 2003 migration.
Before you can perform an in-place upgrade, you must first upgrade the Exchange 2000 server to Exchange 2003; only then can you upgrade Win2K to Windows 2003. No other upgrade sequence will work, although you can use the Move Mailbox tool to directly migrate Exchange 2000 to Exchange 2003 on another server running either Windows 2003 or Win2K without having to perform an in-place upgrade.
After you install Exchange 2003 on a Win2K server, the process of upgrading Win2K to Windows 2003 is clear-cut, and Exchange 2003 behaves proactively during the upgrade process. For example, Exchange 2003 ensures that the Windows Web services aren't disabled during the upgrade—a valuable function because Win2K-toWindows 2003 upgrades tend to disable services by default as a security measure. In addition, Exchange 2003 makes the appropriate changes to Microsoft Internet Information Services (IIS) 6.0, such as switching to Worker Process Isolation Mode and enabling the appropriate Internet Server API (ISAPI) interfaces, including remote procedure calls (RPCs) over HTTP and Microsoft Outlook Web Access (OWA). Exchange makes these changes automatically during the OS upgrade.
The Exchange 2003 ExDeploy Tool
Although migrating from Exchange 2000 to Exchange 2003 is somewhat simpler than other Exchange migrations (i.e., from Exchange Server 5.5 to Exchange 2000 or Exchange 2003), the migration can be even more straightforward if you use the Exchange 2003 ExDeploy tool, which you can find in the \support\exdeploy directory on the Exchange 2003 installation CD-ROM. Double-click exdeploy.chm to start the wizard. Under Options, choose the Upgrade from Exchange 2000 Native Mode option. The tool will present various steps for performing the installation, as Figure 1 shows.
You don't have to use ExDeploy, however. ExDeploy is merely a set of tutorial-type Help pages designed for small environments; it guides you through the various tasks in the migration process and is useful if you have a simple environment with only a handful of Exchange 2000 servers to upgrade. If you have a broader, more complex environment, consider using the conventional upgrade approach, perhaps briefly reviewing the ExDeploy instructions to help you plan your migration.
In-Place Upgrade vs. a New Server
You can use two migration approaches to migrate to Exchange 2003. You can perform an in-place upgrade on an Exchange 2000 server, or you can install a new Exchange 2003 server in an existing Exchange 2000 administrative group and use the Move Mailbox tool to move mailboxes from the Exchange 2000 server to the new Exchange 2003 server. Your environment will determine which approach you use.
In-place upgrades work well for small environments that have few servers and restricted hardware budgets. The servers that you're upgrading must be capable of sustaining the new user load (you won't experience much change in the load unless you're adding new users onto the servers), but if you're already running Exchange 2000 on those servers, they're probably also suitable for Exchange 2003. One disadvantage of in-place migrations is their poor granularity; they migrate all users on the server at the same time. Another disadvantage is that this approach is risky because a failure during the upgrade would require you to restore the system from backups. I like the second approach—introducing new Exchange 2003 servers into an existing Exchange 2000 environment—because of its high degree of granularity. This approach also lets you move individual users or groups of users at your own pace. Such a scenario makes it easier to recover the system if something goes wrong because you have to deal only with recovering a few users, not recovering the entire server. But this type of migration requires additional hardware, so if you have a limited budget, it might not be the best alternative for you.
No matter which approach you decide to implement, you need to back up all the Exchange databases you want to migrate before you start any upgrade activity or begin to move mailboxes. You don't need to be in Exchange 2000 native mode (even though the ExDeploy tool says that you're upgrading from Exchange 2000 native mode) to perform a migration to Exchange 2003. But you need to run the new Exchange 2003 ForestPrep and DomainPrep utilities the way you would for a greenfield Exchange 2003 implementation, even though you ran the Exchange 2000 version of the utilities during the Exchange 2000 deployment.
Exchange 2003 Upgrade Restrictions
In-place upgrades work for most—but not all—Exchange 2000 servers. For example, if an Exchange 2000 server is running Instant Messaging (IM), Chat Service, or Key Management Service (KMS), you must remove those services before you perform an in-place upgrade. If you absolutely must retain the services, you can keep the servers in place and use the Move Mailbox tool to move user mailboxes onto other Exchange 2003 servers.
In addition, if you currently use the front-end/back-end server model for IMAP or OWA, you must migrate the front-end server before you attempt to migrate the back-end server. This statement holds true whether you attempt an in-place upgrade of a back-end server or attempt to install a new back-end server. If you attempt either of these actions for the back-end server before migrating the front-end server, the upgrade or installation will terminate with the error message that Figure 2 shows.
You can have the front-end server running Exchange 2003 and the back-end server running Exchange 2000. However, in this case, users will have Exchange 2000 OWA functionality rather than Exchange 2003 OWA functionality. In addition, you should be aware that Exchange handles OWA session timeouts much better if all servers involved are running Exchange 2003.
In-Place Exchange 2000 Upgrades
To upgrade Exchange 2000, simply insert the CD-ROM in the drive and run setup. If you've met all the prerequisites, you shouldn't encounter any problems. But you must consider several important points after the upgrade has finished.
During an in-place upgrade from Exchange 2000 to Exchange 2003, the Exchange database structure doesn't change. (Earlier Exchange versions altered databases during upgrades, which often resulted in long upgrade times that were directly proportional to database size.) Immediately after the upgrade, however, you'll notice significant activity from the store.exe and exschema.exe processes. This activity, which consumes only moderate amounts of CPU resources, takes place because the OLE DB schema requires some post-update changes. The overhead from these changes shouldn't significantly affect overall system performance or compromise user access; the entire process should take no more than 10 or 15 minutes. Although the database structure doesn't change during the upgrade process, I highly recommend that you make full backups of the Exchange 2003 databases immediately after the upgrade.
If you're running full-text indexing services on any Exchange 2000 servers that you're upgrading to Exchange 2003, the indexes will require a complete rebuild after the upgrade finishes. For general performance purposes, you shouldn't run the full-text index rebuild during typical system-operation hours when users are logged on to the system. You might need to perform other crucial tasks, such as backing up the databases, immediately after an Exchange 2003 upgrade. For this reason, the Exchange 2003 upgrade procedure indefinitely pauses rebuild processes of any full-text indexes and doesn't provide an interface for performing post-upgrade tasks. Schedule the full-text index rebuild as soon as possible after the upgrade when users are logged off.
Mixed Exchange 5.5 and Exchange 2000 Migrations
The processes for mixed Exchange migrations—migrating existing Exchange 5.5 and Exchange 2000 environments to Exchange 2003—are no different from individual migrations. (See "Migrating from Exchange 5.5 to Exchange 2003," October 2003, http://www.exchangeadmin.com, InstantDoc ID 39791, for information about migrating from Exchange 5.5.)
In a mixed environment, the Active Directory Connector (ADC) will already be in place to provide directory synchronization between the Exchange 5.5 Directory Service (DS) and Active Directory (AD). Remember that any existing Exchange 2000 servers will be running only on Win2K servers but that AD might or might not be implemented within the Windows 2003 forest or domain environment. Exchange 5.5 must also be running on Win2K or earlier servers. Whatever the mix of OSs in your environment, you must upgrade any existing ADC servers to the versions supplied with Exchange 2003.
After the upgraded ADC servers are in place, you can move mailboxes to the Exchange 2003 servers. For Exchange 2000 servers, you can either perform in-place upgrades as I described in this article or use the Move Mailbox tool. For Exchange 5.5 servers, you must use the Move Mailbox tool.
Why Not?
Migrating to Exchange 2003 from Exchange 2000 is a straightforward process. So why wait? Make the move to Exchange 2003 today.
