In-Depth

E-Mail Central

Exchange 2003 allows for a more consolidated e-mail architecture. Here's how to pull it off.

• By Bill Boswell
• 12/01/2004

In the current IT environment, we're often forced to do more with less. Sometimes this gets painful, especially when "less" equates to "less money in your paycheck" or "less time with your family." Sometimes, though, getting by with less can result in an improvement.

For example, in the days of Exchange 5.5—days which don't exactly seem eager to see a final sunset—it was common practice to put at least one Exchange server in every office to avoid performance problems when connecting from Outlook across the WAN. This resulted in large populations of Exchange servers, even in organizations with relatively few users.

Exchange 2003 has a variety of features that allow for a dramatic increase in the number of mailboxes on any given Exchange server, especially when married with Outlook 2003 as an e-mail client. This makes server consolidation a practical reality. The challenge is getting mailboxes off of all those remote Exchange servers and onto brand new servers in a central location.

Unfortunately, legacy versions of Exchange have a small architectural compromise that complicates server consolidation during a migration. Each site forms a separate partition in the legacy Exchange directory service information base. To move a mailbox between sites in legacy Exchange, you must first dump the mailbox contents to a personal storage file (.PST), create a new mailbox in the target site, import the .PST file into the new mailbox, then delete the old mailbox. Not only does this process involve quite a bit of labor, its reliance on .PST files restricts the maximum mailbox size that can be moved between sites to 2GB.

It is possible to consolidate mailboxes once you shift an organization to Exchange Native mode; that is, once you've removed every single legacy Exchange server and disabled the capability for replicating with the legacy Exchange directory service. However, another small architectural compromise still stands in the way of a seamless consolidation.

In Exchange 2003, each legacy site is represented in Active Directory (AD) by an entity called an Administrative Group. Although mailboxes can be moved directly between servers in different Administrative Groups in a Native Mode organization, the servers themselves must remain in their assigned Administrative Group regardless of the mode setting. The only way to move an Exchange server between sites (Administrative Groups) is to remove and reinstall Exchange.

So, to consolidate servers to a central headquarters using pre-SP1 Exchange 2003, you must do the following:

• Install permanent Exchange 2003 servers in headquarters and temporary Exchange 2003 servers in each remote site.
• Move mailboxes and connectors and public folders from the legacy Exchange servers in each site to the temporary Exchange 2003 servers.
• Decommission the old servers by uninstalling Exchange.
• Shift the organization to Exchange Native mode.
• Move mailboxes and connectors and public folders yet again to the permanent Exchange 2003 servers in headquarters.
• Decommission the temporary servers by uninstalling Exchange.

Exchange 2003 SP1 simplifies this process by introducing a great new feature, the ability to move mailboxes directly between servers in different sites even while you're still in Mixed Mode, with the original mailboxes still on legacy Exchange servers. Given the number of AD and DNS dependencies in Exchange, this little trick requires some careful planning and precise execution.

Consolidation Prerequisites
If you're familiar with Exchange 2003 Setup, you'll know that it provides a lengthy help file called a "prescriptive checklist" that guides you through the installation. One of the cornerstone tools called out by the checklist is the Exchange Deployment utility, Exdeploy. The most current Exdeploy files include an updated prescriptive checklist with entries and links to tools to help with inter-site moves and server consolidation. Figure 1 shows a sample of the updated checklist entries.

Figure 1. This checklist provides a clear, step-by-step guide to server consolidation. (Click image to view larger version.)

For some inexplicable reason, though, Exchange 2003 SP1 doesn't contain the updated Exdeploy files. You can download them from Microsoft or get them as part of the comprehensive Exchange 2003 toolkit, also available online. To view the new server consolidation steps in the updated prescriptive checklist, launch Exdeploy.hta from the updated Exdeploy files then click Next until you arrive at a page that starts with a paragraph about consolidating Mixed Mode sites. Click on the hyperlink to open the updated checklist. The checklist separates the consolidation into three phases. The first phase discusses a few prerequisites.

First, if you have already begun a migration to Exchange 2003, start by applying SP1 to all existing Exchange 2003 servers and upgrading the Active Directory Connector (ADC) to the SP1 version. Exchange 2003 SP1 requires a hotfix for Windows Server 2003 that corrects an IIS issue that causes problems for Outlook Web Access (OWA) documented in Knowledge Base article 831464.

To upgrade the ADC, run the ADC Setup program from the Exchange 2003 SP1 files and select the Reinstall option. This overwrites the executables while leaving the Connection Agreements in place. The SP1 version of the ADC is 6.5.7226.0.

If you haven't already begun your Exchange migration, follow the prescriptive checklist to run forestprep and domainprep and install the ADC. Then use the ADC Tools to configure two-way Connection Agreements (CAs) between AD and an Exchange 5.5 server in each site. Two-way CAs and properly configured export containers in AD are essential for proper cross-site moves.

Another critical prerequisite involves applying the Directory Service/Information Store (DS/IS) Consistency Adjuster hotfix to your Exchange 5.5 servers. KB article 836489 contains details. In brief, the hotfix prevents Exchange from removing a directory service stub object left behind when a public folder moves from an Exchange 5.5 server to an Exchange 2000 or 2003 server. This stub object allows the ADC to replicate permissions between the public folder object in legacy Exchange and the mail-enabled public folder object in AD.

The hotfix is included in the May 2004 security rollup. The rollup requires Exchange 5.5 SP4, so if you thought you could escape the drudgery of a service pack deployment on your Exchange 5.5 servers by upgrading to Exchange 2003, think again.

Phase 1: Preparing for Site Consolidation
Before proceeding with the consolidation, you'll need to run a utility from the prescriptive checklist to verify that you've completed the prerequisites. If the verification tool gives a negative report, but you know that you've completed the work, look for replication failures. The verification tool obtains its information by querying the directory service maintained by the Site Replication Service (SRS) on the Exchange 2003 server in the central office. If you have a problem with legacy directory service replication between the remote sites and the central site, or if the SRS is not participating in replication with the legacy Exchange servers in the central site, then the verification utility will report errors. Resolve all replication issues prior to proceeding.

The checklist then prompts you to move mail connectors such as Notes, Groupwise and Calendar connectors to an Exchange server in the central site. (Exchange 2003 SP1 supports Notes R6 clients.) Also, if you use secure e-mail, configure a Windows Server 2003 Enterprise-based PKI and migrate the contents of the Key Management Service (KMS) database.

At this point, you'll run a utility called the Public Folder Migration tool (PFMigrate). It discovers each public folder hosted by Exchange servers in the remote office then makes a replica of the folders at an Exchange 2003 server in the central office.

It might seem a little premature to create public folder replicas at this point—after all, you haven't migrated mailboxes yet. But by creating the replicas first, you ensure that users have continuous access to public folders following a cross-site mailbox move without the need for referrals. You also have the luxury of creating replicas for dozens or hundreds of public folders with a single action.

Phase 2: Consolidating Remote Content
The first part of Phase 2 involves moving mailboxes from legacy Exchange servers in the remote office to new Exchange 2003 SP1 servers in the central office. The SP1 version of Exchange System Manager (ESM) has a new addition to the Move Mailbox wizard that automates these inter-site mailbox moves. You can kiss Exmerge (and its 2GB .PST file limit) goodbye.

Don't get complacent, though: Moving mailboxes between sites can cause problems for users in several ways.

The first potential problem involves the MAPI profile used by Outlook. When moving mailboxes between servers in the same site, Outlook knows what to do. It simply queries for the new mailbox location and re-homes the profile to that server. But in an inter-site move, Outlook has no intrinsic method for discovering the new site location. To correct the local MAPI profile, the user needs to run a utility call Exprofre. You can add Exprofre to a logon script. It doesn't require Administrator privileges.

The second potential user-related problem following a cross-site mailbox move concerns free/busy calendar information published into the Schedule+ Free Busy public folder. Each moved user needs to make a change to his or her calendar to initiate an update of the free/busy information from the new mailbox. You can ensure this happens by sending each user an appointment message and requiring that they respond by accepting the appointment.

Phase 2—Part Deux
The second part of Phase 2 involves re-homing Distribution Lists (DLs) and Custom Recipients (CRs) to an Exchange 2003 server in the central office. This may seem like a strange requirement, considering that neither of these object types have a mailbox. They do, however, have a legacy Distinguished Name (DN) that the ADC uses to populate an AD attribute called ADC Global Names. If this attribute isn't populated correctly, when you remove the remote site from the Exchange organization, the ADC will remove the objects from AD.

The Object Rehome Tool, a component of Exdeploy, performs the object moves in two steps. First, it builds an XML file listing the objects and their DNs in the source site. Then, when run again, it moves the objects and applies the new legacy DN attribute. This operation is one of the more confusing parts of the consolidation process. Fortunately, the explanatory notes in the prescriptive checklist do an excellent job of describing the operation.

The final step in this phase is to run the DS/IS Consistency Adjuster on each server in the legacy Exchange site. This updates the entries on the public folder permissions to reflect the new legacy DN for the objects on the list. Without this step, users could lose access to public folders. Be extremely careful when running the DS/IS Consistency Adjuster.

Phase 3: Removing the Remote Site
At this point, the prescriptive checklist walks you through removing the public folder replicas from all Exchange servers in the remote office and re-homing the folders to replica servers in the central office. You'll also run the Object Rehome Tool again to verify that all objects have been moved.

The checklist then lists the final steps for decommissioning servers in the remote office. Be absolutely, positively certain that you have moved every single mailbox and re-homed every distribution list and custom recipient, and that you have full replicas of all public folder content on Exchange 2003 servers in the central office, before removing the remote office servers. If you neglect to make this verification, you could lose data. Doing a tape restore after you've applied changes using the inter-site migration tools can get extremely complex.

Limitations and Caveats
Inter-site mailbox moves aren't completely transparent to users. Client-side rules aren't preserved, for example, and server-side rules only work if they point at mailboxes homed on Exchange 2003 SP1 servers. In general, a rule runs on the server unless it examines the body of a message, in which case it runs at the client and would have to be reconfigured by the user.

If a user delegates access to another user, it's important to move both mailboxes at the same time, or at least move the delegate's mailbox before the manager's mailbox.

During a cross-site mailbox move, any mail addressed to that mailbox which originates from an SMTP server outside the company will result in a Non-Delivery Report (NDR) unless you first move the Internet mail SMTP connector to an Exchange 2003 SP1 server.

One of the more subtle consequences of a cross-site mailbox move is its impact on the Offline Address Book (OAB). If you move a considerable number of mailboxes in a single day, you could exceed a little-known limit in Outlook, documented in KB article 867623, that forces Outlook to download the entire OAB rather than just the differential files. The KB article includes a Registry change for implementing new bandwidth throttling capabilities in Exchange 2003 SP1 that can help reduce the impact of these OAB downloads.

Finally, KB article 841659 contains additional information and precautions for cross-site moves and server consolidation. I also highly recommend listening to the webcast on cross-site mailbox migrations presented by Evan Dodds, Technical Lead in the PSS Beta Support team. Access the webcast here.

Once you practice a couple of moves in the lab, I think you'll find that setting up and performing the production consolidation should not be a problem. Let me know your results. E-mail me at windowsinsider@redmondmag.com.