Chapter 11: Coexisting with and Migrating from Exchange 5.5

Many companies that are installing Exchange Server 2003 will likely already have an existing messaging system in place. Many of those will be using a previous version of Exchange Server. Unless you are planning a full upgrade of all previous Exchange servers to Exchange Server 2003 and do not plan for users to access the system during the upgrade, there will be a time when Exchange Server 2003 servers and Exchange servers of previous versions need to coexist on the same network. You might choose to install an Exchange Server 2003 computer into an existing Exchange 5.5 organization, or you might choose to create a new organization for the Exchange Server 2003 computer that runs alongside the previous organization. Either way, you will have to manage the communications and the synchronization of directory information between Exchange Server 2003 and previous versions. That is what this chapter is all about.

Coexisting with Exchange Server 5.5

For any number of reasons, an organization may choose to leave existing Exchange Server 5.5 computers in operation and install new Exchange Server 2003 computers next to them. One of the most common scenarios for this type of deployment is to allow a smooth and planned out migration from Exchange Server 5.5 to Exchange Server 2003 while keeping user disruption to a minimum. In this section we will examine the benefits and drawbacks associated with coexisting with Exchange Server 5.5 as well as the benefits and drawbacks you can realize by removing all Exchange Server 5.5 computers from the Exchange organization. As well, we will examine the steps that you must complete to ensure that your new Exchange Server 2003 computers interact correctly with the Exchange Server 5.5 computers.

Note ‚

Nowhere in this chapter will we examine the first and most important part of any migration from a Windows NT environment ‚ the moving of user accounts into Active Directory. If your Exchange Server 5.5 servers are still running on Windows NT, you will need to take the time to properly install and configure your new Windows Server 2003 Active Directory forest and then migrate user accounts and other resources into it before you even think about migrating from or coexisting with Exchange Server 5.5. For more information on making this critical migration, see the whitepaper ‚“Migrating from Windows NT Server 4.0 to Windows Server 2003 ‚½ on the Microsoft website or Migrating from Microsoft Windows NT Server 4.0 to Windows Server 2003 , ISBN 0735619409.

Mixed-Mode Operations

An Exchange Server 2003 organization can operate in two modes: native and mixed. In native mode , only Exchange Server 2003 or Exchange 2000 Server is running, and the full Exchange Server 2003 functionality is present. No other previous versions of Exchange Server can communicate with the native-mode organization, except possibly via a connector or gateway as if it were a foreign system.

In mixed mode , Exchange Server 2003 can coexist and communicate with previous versions of Exchange Server in the same organization. When you first install an Exchange Server 2003 computer, it operates in mixed mode by default ‚ even if you have no previous versions running on your network. Once you switch to native mode (described later in the chapter), you cannot go back, and direct interoperability with previous Exchange versions is permanently lost.

There are two big changes between all previous versions of Exchange Server and Exchange Server 2003 (and Exchange 2000 Server):

In previous versions, Exchange Server managed its own directory of configuration and user objects. For example, mailboxes were objects in the Exchange directory that were associated with Windows NT 4.0 user accounts. In Exchange Server 2003, all directory functions have passed to Active Directory.
In previous versions, Exchange sites were used to provide routing, administrative, and namespace boundaries. In Exchange Server 2003, routing groups provide routing boundaries, administrative groups provide administrative boundaries, and Active Directory provides namespace boundaries.

In this section, we discuss the benefits and limitations of running an organization in mixed mode, provide an overview of how Exchange 5. x directories and Active Directory can coexist, and examine the interaction of Exchange 5. x sites with Exchange Server 2003 routing groups and administrative groups.

Benefits and Limitations of Mixed Mode

Before we get too deep into the mechanics of mixed-mode operations, it is helpful to examine some of the benefits and limitations of working in mixed mode. Working in mixed mode provides the following benefits:

There is interoperability between Exchange Server 2003 servers and servers running previous versions.
Exchange 5. x directory objects are replicated to Active Directory and may be managed using System Manager and Active Directory Users and Computers.
Exchange Server 2003 imports information from Exchange 5. x Gateway Address Routing Tables into its own link-state tables and thus provides access to Exchange 5. x connectors and gateways.
You can continue to install Exchange 5. x servers, should you need to do so.
Public folders can be replicated between E x change Server 2003 and E x change 5. x servers.

There are also a number of limitations imposed by working in mi x ed mode. These limitations include the following:

E x change 5. x sites are mapped directly to E x change Server 2003 administrative groups and vice versa. This gives you less fle x ibility in setting up administrative groups than when working in native mode.
You can move mailbo x es only between servers that are in the same administrative group . In native mode, you can move mailboxes between servers in different administrative groups. In short, this prevents you from moving mailboxes between Exchange Server 5.5 and Exchange Server 2003 computers ‚ except by using the Migration Wizard, which is discussed later.
You can divide servers in an administrative group into different routing groups. However, these servers must all belong to the administrative group. In native mode, routing group boundaries and administrative group boundaries can cross.

Directory Interactions

Although many components and features are upgraded in E x change Server 2003, one of the most important aspects of coe x istence is the synchronization between the E x change 5. x Directory Service and Active Directory. In order to successfully manage directory interactions, it is important that you understand the following:

How the E x change 5. x Directory Service works. This includes how it is structured, how it is replicated among E x change 5. x servers, and how it is managed. We provide a brief overview below, but for more information check out your E x change 5. x documentation or, better yet, pick up a copy of the previous edition of this book.
How Active Directory works in relation to E x change Server 2003. This includes how E x change configuration objects are stored in Active Directory and how Active Directory is replicated among domain controllers. For more information on this, see Chapter 2, ‚“Microsoft Exchange Architecture, ‚½ and refer to your Windows Server 2003 documentation.
The components that are used to allow E x change 5. x servers to synchronize directory information with Exchange Server 2003 servers that use Active Directory. These components include the Site Replication Service (SRS) and the Active Directory Connector (ADC).

A Brief Review of the Exchange 5. x Directory Service

In Exchange 5. x , the Directory Service (DS) creates and manages the storage of all information about Exchange objects, such as the organization, site, servers, mailboxes, distribution lists, and public folders. The characteristics of these objects are called properties or attributes. The DS organizes all this information into a hierarchical database called the Directory, which is contained in a database file named DIR.EDB. The Directory hierarchy is patterned after the X.500 standard.

All Exchange servers in a site contain a complete copy of the Directory information. This is accomplished by automatic directory replication between servers of a site via Remote Procedure Call (RPC) . When an Exchange object, such as a mailbox, is created on a particular Exchange server, that object ‚ s information is automatically copied to all the other servers in that site.

There can also be directory replication between sites. This is not an automatic process, and it must be configured by an administrator. Directory replication between sites occurs using SMTP messages over whatever connectors are used to connect the sites. This ability allows administrators to decide which resources to share with other sites. Directory replication between sites can be used to create an enterprise messaging environment.

The DS component supports directory access through the MAPI interface and through the LDAP (Lightweight Directory Access Protocol) interface. This enables both MAPI client software (such as Outlook) and Internet LDAP-enabled applications (such as Outlook Express) to access the Exchange Directory. Administrators access the Directory through Microsoft Exchange Administrator, which is a MAPI program.

Supporting Directory Coexistence

Two main components facilitate coexistence between the Exchange 5. x Directory and the Active Directory in mixed-mode organizations: the Site Replication Service (SRS) and the Active Directory Connector (ADC) .

SITE REPLICATION SERVICE

The SRS runs on an Exchange Server 2003 computer and actually simulates an Exchange 5. x system from the viewpoint of the Exchange 5. x servers in a site. In fact, the SRS is really the same service as the Directory Service from Exchange 5. x; it has just been disabled in a few critical areas so that clients cannot connect to it and so that it does not interfere with operations on the Exchange Server 2003 computer. Within a site, Exchange 5. x servers treat SRS as if it were just another Exchange 5. x server running the Directory Service and replicate information with it freely . The information collected by SRS is then synchronized with Active Directory via the Active Directory Connector. SRS actually provides two functions:

SRS provides a pathway for replicating configuration information between Active Directory and Exchange 5. x servers. As you ‚ ll learn in the next section, the ADC synchronizes directory information with Exchange 5. x servers directly but must go through SRS for configuration information.
SRS provides Exchange 5. x servers in the site with a means of accessing directory information concerning the Exchange Server 2003 computer on which SRS is running.

ACTIVE DIRECTORY CONNECTOR

The ADC runs on an Exchange Server 2003 computer and synchronizes directory information between Active Directory and Exchange 5. x servers in the site. ADC also synchronizes configuration information with those servers using the SRS as an intermediary (see Figure 11.1).

Figure 11.1: Active Directory Connector and Site Replication Service

There is a good reason why the SRS is used as the synchronization endpoint for configuration information instead of allowing a direct connection between Active Directory and the Directory Service. Different parts of the Exchange 5. x Directory are replicated to different areas within the Active Directory:

Configuration information, such as the configuration of servers and connectors, is replicated to the configuration-naming partition of Active Directory.
Recipient information is replicated to the domain-naming partition of Active Directory.
Namespace information is replicated to the schema-naming partition of Active Directory.

Only one instance of the ADC can run on a single Exchange server, but you can configure multiple connection agreements for an ADC. A connection agreement (CA) is something like a virtual connector that runs over the ADC. Each connection agreement is defined to replicate certain directory objects to certain parts of the Active Directory and can even be configured to replicate at certain times. Having the SRS perform as the endpoint of communication for the ADC means that you don ‚ t have to reconfigure the connection agreements each time the status of an Exchange 5. x server in your site changes (for example, when you upgrade it to Exchange Server 2003). You can configure connection agreements between Active Directory and multiple sites, and you can configure multiple agreements to a single site.

There are two basic types of connection agreements:

User connection agreements replicate recipient objects and their data between the SRS and Active Directory.
Configuration connection agreements replicate Exchange-specific configuration information, such as connectors and site information.

You ‚ ll learn how to configure the SRS, ADC, and connection agreements later in this chapter.

Note ‚

There are actually two versions of the Active Directory Connector: one that ships with Windows Server 2003 and one that ships with Exchange Server 2003. The ADC for Windows does replicate directory information between Exchange 5. x directories and Active Directory. It is intended for people who want to prepare Active Directory for Exchange during Windows deployment but before installing Exchange Server 2003. The ADC for Exchange has all the features of the ADC for Windows, but it is enhanced so that it can replicate not only the actual Exchange objects but also the configuration information about those objects. Because it includes all the features of the ADC for Windows and more, we always recommend upgrading to the ADC for Exchange.

Site and Administrative Group Interactions

In order to make Exchange 5. x and Exchange Server 2003 coexist, certain restrictions are placed on how you can configure Exchange Server 2003. When an organization is running in mixed mode, Exchange Server 2003 must follow the rules laid out by previous versions of Exchange. This means that administrative groups and routing groups must be mapped directly to Exchange 5. x sites so that, in essence, Exchange Server 2003 simulates the functionality of an Exchange 5. x site.

In an Exchange 5. x site, messages flow between Exchange 5. x Message Transfer Agents (MTAs) using RPC. When you add an Exchange Server 2003 server to the site, messages flow between the Exchange 5. x MTAs and the Exchange Server 2003 MTA using RPC. When multiple Exchange Server 2003 servers exist in the site, messages flow between Exchange 5. x and Exchange Server 2003 using RPC, but using SMTP, they flow between the Exchange Server 2003 servers.

Between Exchange 5. x sites, messages move across connectors in much the same way that connectors are used in Exchange Server 2003. The primary connector used between Exchange 5. x sites is the Site Connector , which makes use of RPC to transmit messages. In Exchange Server 2003 the Routing Group Connector (RGC) replaces the Site Connector used in previous versions. The RGC uses SMTP rather than RPC to transport messages between Exchange Server 2003 servers. For coexistence, however, the RGC uses RPC to transport messages to Exchange 5. x sites that use the Site Connector. This means you can target Exchange Server 2003 servers as bridgehead servers for Exchange 5. x sites that use the Site Connector. For all other connectors (such as X.400), Exchange Server 2003 uses its equivalent connector to communicate with Exchange 5. x sites.