When you upgrade an Exchange Server 5.5 organization to Exchange 2000 Server, you typically upgrade the entire organization at once. However, sometimes one Exchange 5.5 organization spans several operating companies, agencies, or divisions that need to move to Exchange 2000 in different phases. If you need an innovative and straightforward approach to upgrading your Exchange 5.5 sites to Exchange 2000 in isolation from the rest of your environment, you've come to the right place.
An Obvious Approach
An obvious approach to moving company divisions to Exchange 2000 in phases is to split a given entity from the rest of the organization, then migrate it to Exchange 2000 as usual. Splitting one site from an Exchange 5.5 organization is a relatively straightforward process: You remove the directory replication connectors (DRCs) between the site that you want to remove and the rest of the Exchange organization, then let the directory information from the other Exchange 5.5 sites disappear from the local Directory Service (DS). To do so, you identify the splitting site's bridgehead servers, identify the other sites' partner bridgehead servers that will remain in the original organization, then simply use Microsoft Exchange Administrator to delete the DRCs. Removing the DRCs removes any objects in the local Exchange 5.5 DS that aren't native to that site; therefore, objects (e.g., mailboxes, custom recipients, distribution lists—DLs) from the rest of the organization will disappear. The objects won't disappear immediately. Depending on the number of replicated objects, several hours might pass before the local directory is clean.
When the directory is purged, the local Exchange 5.5 site is effectively removed from the Exchange organization and becomes a separate Exchange 5.5 organization. However, if you split a site from your Exchange 5.5 organization before moving to Exchange 2000, you must implement a mechanism to synchronize the DS from the original Exchange 5.5 organization to the new one so that you can maintain a complete and consistent Global Address List (GAL). To do so, you might use Hewlett-Packard's (HP's)—formerly Compaq's—LDAP Directory Synchronizer Utility (LDSU) or Microsoft Metadirectory Services (MMS). Figure 1, page 2, shows the relationship between two Exchange 5.5 sites in the same organization and Figure 2, page 2, shows the relationship between the same two sites after Site B has been partitioned from the rest of the organization.
After the entity is spun off, it's completely separate from the rest of the Exchange 5.5 organization. You can now use any of the usual methods of migrating from Exchange 5.5 to Exchange 2000. Although this migration scenario is obvious, it can be time-consuming. Before you begin to upgrade the entity to Exchange 2000, you must perform significant preparation work to maintain interoperability (e.g., mail and directory synchronization) with the rest of the Exchange 5.5 environment.
By splitting the organization in this way, you run the risk that replies to old messages will fail and that invalid entries will appear in users' Personal Address Books (PABs) and Offline Address Books (OABs). To fix this problem, you need to ensure that custom recipients in each organization's Exchange 5.5 DS contain an X.500 proxy address that matches the object's distinguished name (DN) when it was in the single organization. You should also tear down the DRCs and implement the new directory-synchronization process as quickly as possible to reduce user downtime. During this transition period, users across the two organizations might experience problems sending mail to one another, so I recommend that you perform this task over a long weekend.
The Out-of-the-Box Approach
You can take several other conventional approaches to achieve the same result without first splitting the entity into a separate organization. Numerous interorganization migration tools let you leave the keen-to-move entity in its original Exchange 5.5 organization but move mailboxes and resources into a newly created Exchange 2000 organization.
You could install a brand-new Exchange 2000 server into its own native Exchange organization and use standard Microsoft tools to move users from the Exchange 5.5 server in Site A to the new Exchange 2000 organization. Doing so involves the following steps:
- Use the Active Directory Connector (ADC) with an interorganization connection agreement (CA) between the Exchange 5.5 organization and the Exchange 2000 organization to replicate Exchange 5.5 directory information. Interorganization CAs replicate Exchange 5.5 DLs as contacts in Active Directory (AD), so membership won't be displayed.
- Using the Exchange Migration Wizard from Exchange 2000 Service Pack 1 (SP1) or later, move mailbox data from servers in the Exchange 5.5 site to the Exchange 2000 server. Because the Exchange Migration Wizard doesn't remove the Exchange 5.5 mailboxes that it migrates, they require regular manual cleanup. Also, with this approach, you might need to configure Outlook Messaging API (MAPI) profiles so that they point to the new servers. Using the Exchange Migration Wizard means that you'll lose Single Instance Storage (SIS) for the moved mailboxes.
- Use the Exchange Inter-Organization Public Folder utility to replicate public-folder content from appropriate Exchange 5.5 servers to the Exchange 2000 server.
Although straightforward and relatively inexpensive to implement, the out-of-the-box approach I've described here isn't ideal because of the problems I've mentioned with DL replication, mailbox migration, and public-folder replication.
Several third-party vendors, such as NetIQ, BindView, and Aelita Software, have (or will soon have) supplementary interorganization-migration tools that provide directory-replication functionality (better DL handling), mailbox-move functionality (post-move cleanup and rollback functionality), and complete public-folder replication tools. However, although all these tools are versatile, they're most useful when multiple separate Exchange 5.5 organizations are merging into one Exchange 2000 organization. This article addresses one part of an organization moving to Exchange 5.5. Although you can use the Microsoft and third-party tools I've mentioned in such a situation, they're not necessarily required, nor do they represent the cheapest or easiest way to move a single entity from Exchange 5.5 to Exchange 2000.
The Preferred Approach
One reason intraorganization migration is desirable is that it renders directory replication, mailbox moves, and public-folder replication straightforward. Directory replication occurs simply and richly through intraorganizational CAs with the ADC; the migration of mailbox data takes place through the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in's Move Mailbox function; and public-folder replication happens automatically because all servers are part of the same mixed Exchange organization.
The first approach I outlined—breaking off a site to become a separate Exchange 5.5 organization, then performing an intraorganization migration—is useful but leaves you with the problem of Exchange 5.5toExchange 5.5 directory synchronization. You can implement a variation of this approach for a simpler migration that bypasses this directory-synchronization problem.
Suppose the entity Site A represents (as Figure 1 shows) wants to move to Exchange 2000, but the rest of the Exchange organization doesn't—or, for technical or political reasons, can't. Rather than split Site A into a separate organization, you can immediately start an intraorganization migration to Exchange 2000 in Site A. To do so, you'd follow these steps:
- Run Forestprep and elect to join the existing Exchange 5.5 organization. (Note that the ADC must be installed before you complete this step.)
- Install an Exchange 2000 server into Site A (where a configuration CA is automatically created within the site).
- Set up a recipient CA from an Exchange 5.5 server in Site A to an AD Global Catalog (GC) server, which provides the GAL to the Exchange 2000 organization.
Figure 3 shows the first steps of such a migration. An Exchange 2000 server and intraorganizational CA are in place within the site. The CA in Site A synchronizes objects (e.g., mailboxes, custom recipients, DLs) within only Site A. However, to ensure typical operation, you need to represent all other objects in the rest of the Exchange 5.5 organization in the AD so that Exchange 2000 users see a complete GAL. Ordinarily, you would simply set up other intraorganizational CAs from Site B to the AD, but remember that you don't want to migrate Site B users to Exchange 2000.
To maintain a complete Exchange 2000 GAL, you might rely on an external synchronization mechanism (e.g., Compaq's LDSU) to synchronize objects from Site B to AD. However, another option is to use another recipient CA in Site A to replicate objects from Site B into the Exchange 2000 GAL. Providing a complete GAL is important, but even more important is that you don't touch or modify objects in Site B—you'll be separating from Site B and you want no residual impact on Site B objects. (The ADC replication process modifies the source Exchange 5.5 objects that it replicates.) If you use a recipient CA in Site A to replicate objects from Site B, no modification to the Site B objects takes place because those objects are read-only in Site A. However, this approach causes problems when you finally separate Site A from Site B: Site A will have no knowledge of Site B objects and thus will be of no use as a directory-synchronization source.
The scenario that Figure 4 shows is preferable. I recommend that in the Exchange 5.5 organization you create a new site that I'll call an insulation site. You don't need to spend too much effort on this site's creation—all it requires is one server capable of hosting the Exchange 5.5 DS and running reasonably well. When you later separate Site A from the rest of the Exchange 5.5 organization, the interorganization CA with the Exchange 5.5 endpoint in the insulation site will always be a source of Exchange 5.5 directory information. And you'll use the insulation site with an intraorganization CA to the AD as a source of Exchange 5.5 directory information rather than connecting directly to a server in Site B. (If you connected directly to a server in Site B, the ADC would modify the source objects. Objects in the insulation site are read-only.)
Installing the Exchange 2000 server into Site A is the first step in the migration of Site A to a separate Exchange 2000 organization. After you've moved all the Exchange 5.5 mailboxes onto Exchange 2000 servers, as Figure 5 shows, you're ready to move Site A out of the Exchange 5.5 organization. To separate the Exchange 2000 Site A from the rest of the Exchange 5.5 organization, you remove the DRC between Site B's bridgehead server and the Site Replication Service (SRS) server in Site A. After you've removed the DRC between the two sites, Site A (or rather the Administrative Group A and Routing Group A pair) effectively becomes one mixed-mode Exchange 2000 organization.
Any public folders that should exist only for the entity represented by Site A must be homed onto a Site A server before the separation takes place, and no public-folder replicas can exist on Site B servers. (Note that the two organizations can't share public folders in this migration approach.) Be sure that no DLs that existed in Site A had membership drawn from Site B; if they did, the integrity of those DLs (not represented as groups in AD) will be compromised. Similarly, make sure that no public folders homed in Site A have associated ACLs that comprise objects from Site B. If so, when the separation takes place, access to those public folders might be blocked because the ACLs can't be resolved.
The Way to Go
You have a few options when one part of your Exchange 5.5 organization wants to move to Exchange 2000 and others don't. As long as the Exchange 5.5 sites map cleanly to the entities that want to move, you can perform either a site split followed by an intraorganization migration or an intraorganization migration followed by a site split. The latter, more flexible approach is the approach that most of this article describes. Such intraorganization migrations are highly desirable: They afford a simple mechanism for directory synchronization, especially with DLs, mailbox moves, and—most important—public-folder replication. If your environment has no clear demarcation among entities and sites, public folders, and DLs, you must resort to using third-party migration tools.
