Migrating from Exchange 5.5 to Exchange 2003
A variety of migration approaches
August 24, 2003
Migrating from Exchange Server 4.0 to Exchange 5.0—or from Exchange 5.0 to Exchange 5.5—is a relatively simple endeavor. However, when Exchange 2000 Server debuted, we faced a steep learning curve as we struggled to grasp the complexities of an Exchange 5.5—to—Exchange 2000 migration. You might think that a migration from Exchange 5.5 to Exchange Server 2003 would involve even more complexity, but the truth is that it's no more difficult than a migration to Exchange 2000 and, if anything, is slightly more straightforward.
The technologies and techniques we learned during an Exchange 2000 migration are just as relevant today for Exchange 2003, so now's the time to dust off your notes about the Active Directory Connector (ADC) and the Site Replication Service (SRS)—the indispensable tools for Exchange 5.5—to—Exchange 2003 interoperability. Let's look at the basic approaches you can take to move from Exchange 5.5 to Exchange 2003. I won't delve into great detail about interoperability because the interoperability model is the same as the one between Exchange 5.5 and Exchange 2000. If you need a refresher course, see "Planning an Exchange 2000 Migration Strategy," http://www.exchangeadmin.com, InstantDoc ID 8863.
Exchange 5.5 and Windows
Exchange 5.5 can operate on Windows 2000 and Windows NT 4.0 systems, whether those systems are part of a Win2K domain or a Windows Server 2003 domain. Note, however, that Windows 2003 servers don't support Exchange 5.5. Only Win2K systems—not Windows 2003 systems—support Exchange 2000, whereas both Win2K systems—with Win2K Service Pack 3 (SP3) domain controllers (DCs)—and Windows 2003 systems support Exchange 2003.
These version dependencies mandate a particular migration path for any given environment. For example, an Exchange 5.5 environment running on NT 4.0 can't move directly (and completely) to Windows 2003 because Exchange 5.5 won't run on Windows 2003 systems. Thus, moving from this combination requires a multipart process. One option is to first move to Win2K, then move Exchange directly to Exchange 2003, and finally move the infrastructure to Windows 2003. Alternatively, you could integrate the NT 4.0 environment into a Windows 2003 environment and introduce Exchange 2003 directly, then move users onto the new servers.
For correct interoperability between Exchange 2003 and Exchange 5.5, you must have at least one Exchange 5.5 SP3 server in the Exchange 5.5 site. You need this server so that the new Exchange 2003 ADC connection agreements (CAs) can function correctly. Microsoft recommends that all servers in a mixed-vintage site should be running at least Exchange 5.5 SP3. (Some production environments are running with Exchange 4.0 SP2 and Exchange 5.0 SP1 in the same site as an Exchange 2003 server, but of course Microsoft doesn't officially support such environments.) To achieve Active Directory (AD) access from an Exchange 2003 server, you should use only Windows 2003 DCs (or Global Catalog—GC—servers) or Win2K SP3 DCs (or GCs) so that you can use secure Lightweight Directory Access Protocol (LDAP).
Exchange 5.5 Migration Scenarios
You can't perform an in-place upgrade from an Exchange 5.5 server to an Exchange 2003 server. If you attempt to do so, the Exchange 2003 Setup program will instruct you that it can't proceed. In contrast, an in-place upgrade of an Exchange 5.5 server to Exchange 2000 is possible. The only supported method for migrating an Exchange 5.5 server directly to Exchange 2003 is to use the Move Mailbox approach.
Essentially, the Move Mailbox approach involves installing an Exchange 2003 server into the same Exchange 5.5 site as the Exchange 5.5 server from which you want to migrate mailboxes. You then move all mailboxes from the Exchange 5.5 server onto the Exchange 2003 server, ultimately decommissioning the Exchange 5.5 server after you've moved all mailboxes. One of the requirements that you must satisfy before installing any such Exchange 2003 servers into the Exchange 5.5 site is that an ADC environment must already be in place. You can also use this approach for an Exchange 5.5—to—Exchange 2000 migration.
You can perform a direct, in-place upgrade of Exchange 2000 servers to Exchange 2003. Therefore, if you must perform an in-place upgrade of an Exchange 5.5 server—for example, if you lack sufficient hardware to use the Move Mailbox approach—you can perform an in-place upgrade from Exchange 5.5 to Exchange 2000, followed by another in-place upgrade from Exchange 2000 to Exchange 2003. I don't recommend this approach, though, given the time necessary to perform the required series of operations and the service impact on users. However, in some cases, it might be the only approach you can take. Remember that after you perform such a series of upgrades, you absolutely must take new backups of the Exchange databases. Ideally, you would perform two backups in this scenario—one immediately after the Exchange 5.5—to—Exchange 2000 upgrade and another after the Exchange 2000—to—Exchange 2003 upgrade.
Using ExDeploy
If you need a tool to guide you through your migration from Exchange 5.5 to Exchange 2003, check out ExDeploy. This tool lays out a process for the tasks that you must perform to complete such a migration. ExDeploy defines three phases for the migration: prerequisites, preparatory processes, and installation.
You'll find the ExDeploy tool on the Exchange 2003 installation CD-ROM in the supportExDeploy directory. To start the tool's wizard, double-click the exdeploy.chm file, which is a compiled Help file that identifies the steps you must carry out. When you start ExDeploy, the tool presents the various options you have for proceeding. Choose the set of procedures for an Exchange 5.5—to—Exchange 2003 migration. Be sure not to run ExDeploy from a network share; doing so will result in improper ExDeploy function.
Before you begin, ensure that the account from which you execute ExDeploy has the necessary Domain Administrator and Exchange 5.5 Administrator permissions. You'll also need Enterprise, Schema, Domain, and Local Machine Administrator permissions to run Forestprep; Domain and Local Machine Administrator permissions to run Domainprep; Domain and Local Machine Administrator permissions to install the ADC; and Full Exchange and Local Machine Administrator permissions to install Exchange 2003.
Prerequisites. The first phase comprises several steps you need to take to meet the infrastructure prerequisites for a migration to take place, as well as a set of basic connectivity tests (DCDiag and NetDiag) that you can run to ensure proper network functionality. To perform these tests, you must connect to an existing Exchange 5.5 server and an AD GC. DCDiag and NetDiag confirm DC connectivity and functioning DNS service, respectively. Additionally, this phase contains the DSScopeScan toolset, which contains several tools that check the consistency and integrity of the Exchange 5.5 environment, particularly in regard to server names and versions, connector counts, and user counts.
Preparatory processes. The second phase runs through several standard Exchange 2003 installation processes, including Forestprep and Domainprep. Executing Domainprep won't automatically run Domainprep in all domains. You'll still have to run DomainPrep in each domain that requires it. (You can even run the ExDeploy wizard on a server in each domain to perform this step.) The second phase also includes a series of tests (beyond the functionality of Forestprep and Domainprep) that make up the OrgPrepCheck tool group. These tests ensure that schema extensions and the appropriate groups and policies are in place and that the Exchange 5.5 organization is ready for an upgrade to Exchange 2003. Before you can install any Exchange 2003 servers, you must install and configure the ADC. The second phase also facilitates this installation and directs you to the ADC Tools wizard, which eases the burden of creating and configuring CAs.
Installation. The Exchange 2003 installation takes place after ExDeploy performs some final DNS checks and sets the stage for the installation of Exchange 2003 servers. When your Exchange 2003 servers are successfully in place, you can use the Move Mailbox Wizard to move mailbox content from Exchange 5.5 servers to Exchange 2003 servers.
Remember that you don't need to use the ExDeploy tools to start an Exchange 5.5—to—Exchange 2003 migration. ExDeploy offers no more than a guiding hand through the process and is appropriate only for small organizations that have perhaps a couple of servers or sites. For larger, more complex environments, you need to develop a custom set of processes to prepare for migration.
Installing the ADC
The Exchange 2000 version of the ADC requires Enterprise Administrator permissions for the account from which you're installing the ADC. The Exchange 2003 ADC has no such requirement. The Exchange 2003 ADC requires only Domain Administrator privileges, both to create the AD Connections container in AD and to create the local Exchange Services and Exchange Administrators groups. This requirement applies not only to the initial ADC installation but also to any subsequent installations of the ADC in your environment. Note that if these groups are absent for any reason, any subsequent ADC installation will recreate the groups.
Of particular importance is that the Exchange 2003 ADC schema extensions are now identical to the general Exchange 2003 schema extensions. By contrast, in Exchange 2000, the ADC schema extensions are a subset of the general Exchange 2000 schema extensions. The problem is that in Exchange 2000, Forestprep temporarily uses the ADC during its execution, so you must install the ADC before any Forestprep activity can take place. As a result, the ADC installation performs its schema extensions, then the Forestprep activity also performs its schema extensions. The Win2K environment experiences two waves of replication—not only the Schema Naming Context additions but also a complete reload of all GCs because the schema extensions add attributes that have TRUE values for isMemberOfPartialAttributeSet (i.e., attributes that are replicated to GCs by default). Obviously, large Exchange 2000 environments experience significant replication activity.
However, Exchange 2003 uses precisely the same schema extensions for both the ADC and Exchange 2003 itself. Therefore, only one instance of Schema Naming Context replication takes place in AD. In fact, in a native Windows 2003 forest environment, no AD-wide GC reload takes place when new objects are added to the GC partial-attribute set. Furthermore, the Exchange 2003 version of Forestprep writes no Exchange 5.5 organizational information to AD. Rather, the tool creates a placeholder Exchange container. The actual configuration information from Exchange 5.5 isn't written to AD until you install the first Exchange 2003 server. Thus, the installation of ADC isn't a prerequisite for Forestprep.
ADC Tools
Although Exchange 2003 ADC functionality is basically the same as Exchange 2000 ADC functionality, the Microsoft Management Console (MMC) Active Directory Connector Manager snap-in contains a significant number of enhancements that can simplify CA configuration. The MMC snap-in now contains a series of buttons that you can use to per-form checks against the Exchange 5.5 Directory Service and AD. When you click ADC Tools in the navigation pane (on the snap-in's left side), these new options appear in the snap-in's right pane, which Figure 1 shows.
To perform these options' tests, you must first (in Step 1) specify Exchange 5.5 Directory Service connection information for at least one Exchange 5.5 server in any site; only Read access is necessary, so any site will suffice. You can then run through the tests, the first of which—Step 2—simply collects various data about the Exchange 5.5 environment. In Step 3, the Resource Mailbox Wizard performs the NTDSAttrib checks (to identify problematic Exchange 5.5 mailboxes), and in Step 4, the optional Connection Agreement Wizard checks the integrity of Exchange 5.5 Directory Service—to—AD replication, assuming you've already manually created CAs. Information that these tests gather is written to the adctools.log file, which resides in the C:ExDeploy Logs directory.
If you want to install an Exchange 2003 server into an existing Exchange 5.5 environment, you must run these tests at least once. Exchange 2003's installation process explicitly checks for these test results before it permits an installation to proceed.
Although Step 4 isn't strictly required, I recommend running the Connection Agreement Wizard. This utility analyzes your Exchange 5.5 environment in conjunction with the AD environment and automatically creates the CAs that it believes are applicable to your organization. However, proceed with caution: The Connection Agreement Wizard works in a rather rudimentary fashion. If you have an Exchange 5.5 Directory Service container hierarchy or a complex AD organizational unit (OU) hierarchy, the wizard probably won't offer the most optimal configuration. Similarly, if you want to use a temporary OU in AD and ultimately move objects in AD to a final location—say, because of a staggered NT 4.0 migration strategy—the wizard isn't a great idea. In such cases, you'll need to develop the best CA architecture on your own.
Installing Exchange 2003 with Exchange 5.5
After you carry out the initial tests and ensure that the appropriate ADC CAs are in place, you can continue with the ExDeploy tasks. Your next order of business is the SetupPrep tools. These tools include OrgNameCheck, OrgCheck, and PubFolderCheck.
OrgNameCheck—This tool searches for and identifies any illegal characters in the Exchange 5.5 organization name, site names, and server names. All characters in these constructs must conform to the Internet Engineering Task Force (IETF) Request for Comments (RFC) 821 specification. Brackets are the biggest offender in most organizations. OrgNameCheck writes its results to the orgnamecheck.log file and the exdeploy.log file.
OrgCheck—This tool validates schema extensions, verifies that domain groups exist, ensures that appropriate security descriptors are assigned, and ensures that the Exchange configuration container is in place. OrgCheck also verifies that a GC is available in the same or an adjacent site to the Exchange 2003 server.
PubFoldCheck—This tool is the Public Folder DS/IS Consistency Checker, which performs four default actions in specific scenarios. If a Public Folder entry exists in the Information Store (IS) without a preexisting Directory Service (DS) entry, the tool creates a new DS entry. If a corresponding Public Folder object doesn't exist in the IS, the tool deletes a DS entry. If the Public Folder is homed in an unknown site, the tool rehomes the Public Folder to a local Exchange 5.5 server. The PubFoldCheck tool also removes invalid users from Public Folder permissions. PubFoldCheck will perform these actions only if the detected inconsistencies are older than 1 day. Exercise caution before running PubFoldCheck because it can result in data loss.
At this point in the installation, Setup ensures that you've performed the necessary ADC Tools checks. If you haven't, the installation won't proceed. If you've successfully performed the checks but error messages appear in the log files, the Exchange 2003 installation can still proceed as usual. You can now install the Exchange 2003 server into the existing Exchange 5.5 site. After you install the server, you can begin moving mailboxes to the new server from the Exchange 5.5 server. You can also run the final set of ExDeploy post-installation tasks, which confirm that the installation has proceeded correctly.
Few Surprises
If you've migrated from Exchange 5.5 to Exchange 2000, a migration from Exchange 5.5 to Exchange 2003 will hold few surprises. Furthermore, migrating from Exchange 5.5 is straightforward because it's simply a matter of creating an interoperability environment with the ADC, then using the Move Mailbox Wizard to move data.
About the Author
You May Also Like