Migration Wonderland

Before you tread the path to Exchange migration, here's a look at where that well-worn path leads.

• By Bill Boswell
• July 01, 2004

“But I don’t want to go among mad people,” Alice remarked.
“Oh, you can’t help that,” said the Cat.
“We’re all mad here. I’m mad. You’re mad.”
“How do you know I’m mad?” said Alice.
“You must be,” said the Cat, “or you wouldn’t have come here.”

Alice would certainly understand the plight of a modern-day e-mail administrator who faces a migration from Exchange 5.5 to Exchange 2003. The piles of manuals, procedures, checklists, and references you accumulate during your pre-migration research can convince you that you’ve entered a mad, mad world.

The problem is not so much with the Exchange documentation or with people like me who try to put the documentation into a real-world context. The problem lies with the complexity of the migration itself. The road to a full, native-mode Exchange 2003 organization wends its way through multiple directory services with conflicting and often incompatible operating system interactions, a complete change in message routing, a complete rewrite of the management interface, an unprecedented level of interoperability between Exchange and Outlook, and a host of features that absolutely rely on a properly tuned DNS and Active Directory infrastructure. Getting out of Wonderland once you’ve fallen down the rabbit hole is a feat to be proud of.

House of Cards
When laying out your Exchange 2003 migration plans, the hard part is figuring out where exactly to get started. Fortunately, you don’t need to worry about AD compatibility. Yes, it’s true that Exchange 2003 Setup makes extensive changes to the AD schema, modifies the Configuration naming context to incorporate the Exchange organization, and modifies each domain to include new Exchange accounts and groups, but these changes are fully compatible with both Windows Server 2003 and Windows 2000 Server AD.

There are a couple of caveats. If you have a Win2K forest, it’s highly recommended that you run Win2K SP3 on all domain controllers. Otherwise, you’ll wait for hours—even days—while the tables in AD are re-indexed following the Exchange 2003 changes. Also, some of the high-end features in Exchange 2003, such as cross-forest Kerberos authentication for Outlook 2003 and linked value replication of individual group members, rely on a Windows 2003 forest that has been set to the highest functional level, meaning that all Win2K DCs have been upgraded or removed from service.

Also, before you deploy Windows 2003 DCs into a mixed environment of Exchange 2000 and Win2K, it’s important to correct an issue with the InetOrgPerson attributes in the schema. Check out Knowledge Base 325379, “How to upgrade Windows 2000 domain controllers to Windows Server 2003,” for details.

Now you face a more difficult decision: the choice of an operating system to use for your Exchange servers. The myriad combinations of Exchange and Windows server versions quickly start to blur. Here are the combinations that Microsoft supports: n Exchange 2003 Standard Edition on Windows 2003 Standard Edition. This combination supports four-way Xeon hyperthreaded processors, RPC over HTTP, advanced memory tuning, IIS 6 application pools, OWA compression, and shadow copy backups. You can run this configuration in a Win2K domain, if you wish.

• Exchange 2003 Enterprise Edition on Windows 2003 Enterprise Edition. This gives the additional advantage of eight-node clustering and eight-way processing. Don’t waste money loading more than 4GB RAM because Exchange 2003 can’t and won’t use it.
• Exchange 2003 Standard Edition on Win2K Standard Server. This combination is fully supported and works fine as long as you run Win2K SP3 or higher on the Exchange server and all DCs. You won’t get support for four-way Xeon multithreading because Win2K assigns a CPU license to each virtual processor, and Win2K Standard Server only supports four processors.
• Exchange 2003 Enterprise Edition on Win2K Enterprise Server. Technically, this combination is supported, but the only feature that Win2K Enterprise Server brings to the table in this situation is two-node clustering with inferior memory management compared to Windows 2003, so there’s hardly any reason to consider this as an alternative.

The following combinations aren’t supported and shouldn’t be implemented, even if you can come up with a workaround:

• Exchange 5.5 on Windows 2003. If you try to install Exchange 5.5 on a Windows 2003 server, you’ll be blocked at the outset by a warning message from the OS. If you try to upgrade a Win2K server that already has Exchange 5.5 installed, you’ll be notified by Windows 2003 Setup that Exchange 5.5 isn’t supported.
• Exchange 2000 on Windows 2003. Yes, I know that you’ll hear stories that you can upgrade a Win2K server to Windows 2003 and Exchange 2000 “works great.” You can believe those stories if you like, but do you really want to put your production Exchange servers into an unsupported configuration? I say no, and I’m sure you’ll agree.
• Exchange 2000 or Exchange 2003 on Windows 2003 Web Edition. The Web Edition of Windows 2003 was designed for Web services and doesn’t support any version of Exchange.

With all this in mind, you have a limited set of in-place upgrade options. You can’t do an in-place upgrade from Exchange 5.5 to Exchange 2003, even if you have Exchange 5.5 running on Win2K. You can upgrade from Exchange 2000 to Exchange 2003, but make sure you’re confident of your change control. You don’t want applications running on the Exchange 2000 server to cause compatibility or security problems when married to Exchange 2003.

If you run Exchange 2000 as a component of Small Business Server 2000, you can do an in-place upgrade to SBS 2003. If you run Exchange 5.5 as a component of SBS 4.5, Microsoft has a 48-page document detailing the required steps for replacing an SBS 4.5 server with an SBS 2003 server.

Playing Croquet with a Flamingo
Now you’re ready to do the upgrade. If you’re starting with an NT domain, your first job is to upgrade to Windows 2003. Don’t deploy Win2K. Why spend time deploying four-year-old technology that’s not as stable, secure, or streamlined as the current version? The roadmap for a typical single domain upgrade looks like this:

• Upgrade the current PDC to Windows 2003. Use a leapfrog upgrade by installing a new server as an NT BDC, promote it to PDC, then upgrade it to Windows 2003.
• Install additional Windows 2003 DCs. Don’t tempt fate by having any fewer than three DCs in a domain. This lets you take one DC down for maintenance and still have two up and running.
• Decommission all NT BDCs. This eliminates the need to support legacy DC replication.
• Shift the domain and forest to Windows 2003 functional level. This enables you to create Universal Security Groups, a requirement for proper Exchange operation in a multiple domain forest, and for supporting high-end Exchange features.

If you consolidate NT domains as part of your Exchange deployment, you need to first stuff AD with the user, group and computer accounts from the source domains. Then you can start your Exchange 2003 deployment. An account migration populates an AD attribute called SIDHistory, which contains the SID from the source domains to retain access to legacy resources such as their Exchange 5.5 mailboxes.

Once the domain’s been upgraded, focus on upgrading the messaging infrastructure. There’s no direct upgrade path from Exchange 5.5, so you’ll need to deploy new Exchange 2003 servers and move mailboxes and connectors to the new servers. The roadmap for the second phase looks like this: n Install SP4 and the latest security patches on all Exchange 5.5 servers. This gives each Exchange server the ability to read and write to the legacy Exchange directory service via LDAP, a critical feature to support connectivity with Exchange 2003.

• Normalize mailboxes. Spend an afternoon, maybe a long afternoon, validating that you have a one-to-one match between each legacy Exchange mailbox and an AD user. At the same time, verify that each mailbox owner actually exists in AD. The AD Connector (ADC) tools in Exchange 2003 will also perform this check, but you don’t want to wait until the middle of the deployment to find out that you have a problem.
• Verify public folder permissions. Spend another long afternoon going through the permission list for each public folder to ensure that the recipients and distribution lists actually exist. This avoids having zombies on the permission lists; that is, distinguished names that don’t point at a valid account in the legacy Exchange directory service. Exchange 2003 contains safeguards against problems caused by zombies, but you’ll have more success in your deployment if you avoid them entirely. The Pfadmin tool does a great job of identifying zombies. KB 188629, “XADM: Using PFADMIN to Remove Public Folder Permissions,” discusses how to remove invalid permission entries using Pfadmin.
• Install the AD Connector (ADC). This updates the AD schema to include all changes required by Exchange Server 2003. Fortunately, the Exchange 2003 ADC Setup makes the same schema and forest changes as Exchange 2003 Setup, so you only need to do this work once.
• Configure Recipient and Public Folder connection agreements. A Connection Agreement (CA) defines a pathway between AD and the legacy Exchange directory service. The ADC uses CAs to transfer mailbox information from legacy Exchange to mailbox-enabled users in AD and to create Distribution Groups and Contact objects in AD that match the distribution lists and custom recipients in legacy Exchange.
• Install the first Exchange 2003 server. This creates a Configuration connection agreement in the ADC that copies information about the legacy Exchange organization into AD. This server also runs an instance of the Site Replication Service (SRS) so the Exchange 2003 server can replicate directly with legacy Exchange servers in its site.
• Move Connection Agreement endpoints. An Exchange 2003 server running SRS can act as an endpoint for connection agreements. The ADC Connection Agreement Wizard initially assigns endpoints to legacy Exchange servers. You have to manually move the endpoints of Recipient and Public Folder CAs to an Exchange 2003 SRS server.

A Mad Tea Party
In the final phase, you’ll decommission your legacy Exchange servers and shift the organization to Exchange Native mode to get full access to all Exchange 2003 features. Here’s what the last mile of the roadmap looks like:

• Move mailboxes. You can move mailboxes to the new Exchange server from legacy Exchange servers in the same site. The Exchange organization is still in Mixed mode, so you can’t move mailboxes directly between servers in different legacy sites, which correspond to Exchange 2003 Administrative Groups. This requires using Exmerge or third-party utilities such as Aelita Exchange Migration Manager.
• Move connectors. The legacy Exchange server probably hosts a variety of connectors, such as the Internet Mail Service (IMS) connector, Site connector, Directory Replication connector, and possibly additional connectors for X.400 or third-party e-mail systems. (If you have an X.400 connector, you’ll need Exchange 2003 Enterprise Edition.) Create new connectors on the Exchange 2003 server and make sure that those connectors work satisfactorily before removing the legacy connectors.
• Decommission legacy servers. At this point, you no longer need the legacy Exchange servers in this particular site. De-install Exchange from those servers. This removes their objects in the legacy Exchange directory service and, thanks to the ADC, from AD.
• Repeat for other sites. During the time you’re upgrading the first Exchange site to Exchange 2003, you can start upgrading the other sites using the same steps. This invariably takes twice as long as you originally had in the schedule, but at some point, the work will be done.
• Shift to Exchange Native mode. Once all legacy servers have been removed from the organization, you can remove the Site Replication Service from all Exchange 2003 servers, then set the Native flag in the organization to release it from compatibility with legacy Exchange. This has a long list of advantages, including the ability to move mailboxes between servers in different sites, faster SMTP message transfers between routing groups and the ability to send e-mail to Query-based Distribution Groups (QDGs), which have dynamic membership based on LDAP queries.

If you’re already in the midst of an Exchange 2000 migration from Exchange 5.5, avoid deploying Exchange 2003 until you’ve finished. Microsoft refers to this as "TIPTOS," derived from the chemical symbols of the code names for the three Exchange products: Titanium for Exchange 2003, Platinum for Exchange 2000 and Osmium for Exchange 5.5.

You don’t want to get involved with a TIPTOS migration. You’d need to include multiple strategies for directory service replication, multiple strategies for message routing, and keep track of the eccentricities of each type of server with a possibly different mix of antivirus, antispam and back-up agents. Imagine diagnosing and fixing problems when you can’t get the servers to interoperate for some inexplicable reason. Then imagine what your resume might look like after you explain to your boss for the hundredth time why the CEO isn’t getting her e-mail.

You’re Late
It’s been nearly four years since the release of Exchange 2000 and a year since the release of Exchange 2003. The support clock on Exchange 5.5 is ticking and time is just about to run out. If you have specific issues holding you back from proceeding with your migration, you should contact Microsoft and get them resolved. You can also drop me a note in care of MCP Magazine.