Migrating from Exchange Server 5.5 to Exchange Server 2003

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

With Microsoft Exchange Server 2003, Microsoft have made Exchange installation simpler – the Exchange Server deployment tools and documentation (ExDeploy) lead an administrator through the entire Exchange Server installation or upgrade process and it is recommended that Exchange Server 2003 Setup is run using ExDeploy. Specific tools and utilities can be used to verify that the organization is ready for the Exchange Server 2003 installation.

For a variety of reasons, the majority of organisations moving to Active Directory perform a migration rather than an upgrade. The main reason for this is that the legacy Windows NT domain structure is generally over-complicated, often having grown organically with various resource domains created to support applications, and so may be poorly matched to the current organisational structure. Implementing a totally new directory is often the simplest method of re-engineering this, allowing for domain consolidation and improved flexibility post-migration.

Messaging connectivity is fairly straightforward to provide – that is at the core of the Exchange Server product – the main issues for Exchange Server are around directory management.

Because Exchange Server 4.0-5.5 use their own directory service and Exchange Server 2000 and 2003 use Active Directory, in a mixed environment it is necessary to synchronise directories using the Active Directory Connector (ADC). Note that there are two commonly available versions of this tool – the Windows 2000 version is not suitable for Exchange and the Exchange version should always be used.

The Exchange Server directory allows one user to be linked with several mailboxes (e.g. a primary mailbox and a resource mailbox) but Active Directory has a 1:1 relationship between a user account and a mailbox; however, ADC can create a disabled user account with an associated mailbox for resource accounts (permissions on the mailbox can then be delegated to one or more users).

The NTDSNoMatch utility can assist administrators by checking for mailboxes with a duplicate primary Windows NT account and determining if the mailbox is the primary mailbox or a resource mailbox. Following this, it creates a comma-separated value (.CSV) file that can be imported into the Exchange 5.5 directory to automatically set Custom Attribute 10 to NTDSNoMatch for the resource mailboxes. The ADC uses this attribute to match a mailbox that does not have NTDSNoMatch set to the correct user account.

The ADC uses a series of connection agreements (CAs), which are set as primary (i.e. synchronise and create objects as necessary) or non-primary (synchronise only). One- or two-way CAs can be configured and if required, a CA could be primary in one direction, and non-primary in the other. This primary and non-primary arrangement prevents duplicate entries in the global address list (GAL) from being created as a result of various CAs synchronising with multiple sites.

In mixed mode, recent versions of Exchange Server provide a service called the site replication service (SRS), which makes an Exchange 2000/2003 routing group appear as a site to the Exchange 5.5 infrastructure (cf. native mode, where Exchange Server 5.5 interoperability is not supported).

The SRS acts as an endpoint for a configuration CA, created in the ADC by Exchange Setup. This allows SRS to funnel organisational changes made in Active Directory into the legacy Exchange directory service, where they propagate to the legacy servers via standard directory service replication.

Recipient and public folder CAs are created by an administrator. These should be configured to point at the SRS rather than a legacy Exchange server so that legacy servers can be decommissioned without losing synchronisation with Active Directory. When all legacy servers have been decommissioned, the SRS is no longer required. Note that even when hosting the SRS, an Exchange Server 2003 server still read directly from Active Directory (using DSAccess) and the SRS is only for the benefit of Exchange Server 4.0-5.5 servers.

If an organisation creates an Active Directory to support Exchange Server 2003, and completes the Exchange migration before all the NT domains have been migrated to Active Directory, duplicate accounts will be created. The ADClean tool can be used to merge duplicate accounts and is installed with Exchange Server 2000 and 2003.

The whole migration process from Exchange Server 5.5 to 2003 is summarised as follows:

Exchange 5.5 to 2003 migration

  1. Install Active Directory on a new Windows 2000 or Windows Server 2003 server
  2. Migrate NT objects to Active Directory using the Active Directory Migration Tool (ADMT) – this will require a trust to be in place between the legacy and new domains.
  3. ADMT manages SID history to ensure that new accounts in Active Directory still have access to resources in the NT domain (including permissions over their Exchange Server 5.5 mailboxes.
  4. Run Exchange Server setup once with the /forestprep switch to prepare the Active Directory Schema for Exchange and again with the /domainprep switch for each domain in the forest which will host Exchange Servers (ADC installation in 5 would make some changes, but not all).
  5. Install the ADC on a member server within the Active Directory forest. Create recipient CAs and use the NTDSNoMatch utility to check for mailboxes with a duplicate primary Windows NT account.
  6. Install a new Exchange Server 2003 server, ideally into the Exchange Server 2003 administrative group which corresponds to the existing Exchange server 5.5 site (i.e. same organisation). Alternatively, a new organization can be created.
  7. Use the Move Mailbox Wizard to move mailboxes from legacy Exchange servers to the new server. This is multi-threaded in Exchange Server 2003 and so much faster than in Exchange Server 2000. Outlook clients will automatically be updated via the directory referral method and so a client visit is not required. If a new Exchange organization was created in 6, it will be necessary to use the ExMerge tool to migrate data and to reconfigure each Outlook client with a new profile. The public folder migration tool can be used to migrate system and public folders.
  8. Once all of the data is migrated, the legacy Exchange Server 5.5 servers may be decommissioned and Exchange Server 2003 switched from mixed to native mode (note that this is entirely separate from the mixed and native modes for Active Directory).
  9. Optionally, ADSI Edit can be used to restructure administrative groups (unsupported by Microsoft).
  10. Finally, the ADC may be decommissioned and the SRS disabled.

One thought on “Migrating from Exchange Server 5.5 to Exchange Server 2003

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.