MCSE Exchange 2000 Design Exam Cram: Exam 70-225 by William R. Baldwin

• Table of Contents
• Read an Excerpt

Table of Contents

Read an Excerpt

Chapter 11: Migrating from and Coexisting with Exchange 5.5

When confronted with deployment, it is a rare occurrence that an existing messaging system is not already in place. Some sort of messaging system exists in most organizations. When migrating from an existing messaging system to Exchange 2000, in many scenarios the existing messaging system is a previous version of Exchange 2000. This chapter will focus on migrating Exchange 5.5 organizations to Exchange 2000. In the first section, you will gain a better understanding of which components will be migrated. You will then learn how to upgrade a pre-Windows 2000 environment to Windows 2000. You will also learn how to migrate and synchronize data between Exchange 5.5 and Windows 2000. Finally, you will learn to upgrade Exchange 5.5 using either an in-place upgrade or the Exchange Server Migration Wizard.

Overview

Messaging systems using pre-Exchange 2000 servers could be running Exchange Server 4.0, 5.0, or 5.5. Microsoft does not support nor recommend migrating from Exchange versions other than 5.5. Before planning a coexistence or a migration, all pre-Exchange 2000 servers should be running Exchange Server 5.5.

Migrating the Exchange Directory

Exchange 5.5 organizations maintain their own directory for Exchange recipients. These Exchange recipients are linked to Windows NT domain users. Because Exchange 2000 uses Windows 2000 Active Directory for storing its directory information, the Windows NT directory and the Exchange 5.5 directory should be migrated to Windows 2000 Active Directory. In Figure 11.1, Windows NT domain users are migrated to Active Directory users. Windows NT domain users linked to Exchange mailboxes are migrated to Active Directory mailbox-enabled users. In this chapter, you will see several methods for migrating this data, including migrating the data before Exchange 2000 is installed.

Migrating the Exchange Messaging System

The Exchange 5.5 messaging system includes two components: messages and system data. The messages contained in the public and private information stores must be migrated to Exchange 2000 systems. These messages can be upgraded by several methods, including upgrading the servers, moving mailboxes, and using the Exchange Server Migration Wizard. Exchange 5.5 system data includes Internet connections, sites, and site connectors. This data can be migrated by upgrading Exchange 5.5 servers to Exchange 2000. This data can also be documented and duplicated in a new Exchange 2000 organization. Many organizations also find that they need to reconfigure the system data due to the added capabilities of Exchange 2000.

Coexistence

Many organizations may wish to deploy Exchange 2000 and maintain pre-Exchange 2000 servers. Exchange 2000 servers can be deployed into existing pre-Exchange 2000 organizations. Exchange 2000 servers can also be deployed as a new Exchange 2000 organization and coexist with an existing pre-Exchange 2000 organization. Later in the "Coexistence with pre-Exchange 2000 Systems" section, you will learn how Exchange 2000 can share directory information and route messages with pre-Exchange 2000 servers and organizations.

Migrating Pre-Windows 2000 Domains to Active Directory

Before Exchange 5.5 can be migrated to Exchange 2000, pre-Windows 2000 domains must be migrated to Active Directory. Pre-Windows 2000 servers can be upgraded to Windows 2000, or the Active Directory Migration Tool can be used.

Performing an In-Place Upgrade

An in-place upgrade includes upgrading the pre-Windows 2000 Primary Domain Controller (PDC) to Windows 2000. Additional pre-Windows 2000 domain controllers, known as Backup Domain Controllers (BDCs), can then be upgraded. Before performing an in-place upgrade of a pre-Windows 2000 environment, many factors must be considered:

• All users in a domain are migrated at the same time. This may be an advantage or disadvantage, depending on the organization.

• Users' passwords are maintained and all enabled accounts remain enabled.

• Active Directory inherits the pre-Windows 2000 domain structure. Many organizations may want to change their domain structure to take advantage of new features in Active Directory.

• An in-place upgrade does not require additional servers.

• Existing servers must meet Windows 2000 system requirements.

• As long as Active Directory remains in mixed mode with at least one pre-Windows 2000 domain controller, the migration can be reversed.

• Existing trust relationships are maintained and do not have to be reconfigured.

• An in-place upgrade is typically less complicated and has a lower risk factor than using the Active Directory Migration Tool.

• Microsoft recommends that you take one BDC offline during the upgrade until the entire upgrade is complete and functional and then upgrade that BDC last for safety measures.

The Active Directory Migration Tool

The Active Directory Migration Tool (ADMT) is used to migrate pre-Windows 2000 domains to Windows 2000 Active Directory. ADMT can also be used to migrate from one Windows 2000 domain to another Windows 2000 domain. Migration between Windows 2000 domains can occur in the same forest or between different forests. ADMT copies security principals (users, computers, and groups) between domains. Many factors must be considered before using ADMT:

• Users can be migrated incrementally. ADMT allows you to migrate a small number of users at a time.

• Users' passwords are not maintained after the migration. ADMT can be configured to set the passwords to the username or to a complex random password. User accounts may be disabled in the destination domain to reduce security risks.

• Active Directory can have a different structure than the pre-Windows 2000 domain structure. Many organizations may want to change their domain structure to take advantage of new features in Active Directory.

• ADMT requires additional servers.

• Existing servers are not required to meet Windows 2000 system requirements. These servers can be decommissioned or redeployed after the migration.

• Parallel systems can be maintained for a period of time; however, rolling back to the old system may require additional steps. Changes made in the new system must be manually duplicated in the old system.

• Existing trust relationships are not maintained and have to be reconfigured.

• Using ADMT is typically more complicated and has a higher risk factor than an in-place upgrade.

• A user account with administrative rights in both source and destination domains must be used with ADMT.

• Before running ADMT, a two-way trust relationship must be manually created between the source and destination domains.

  If ADMT is installed on the PDC or PDC emulator in the source domain, ADMT changes the registry and reboots the server. If ADMT is run from another computer and not installed on the PDC, the following registry change must be made on the PDC in the source domain. Add the value TcpipClientSupport to the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\LSA key. Set the data in TcpipClientSupport to 1. The PDC must be rebooted after this change is made.

SID History

Every security principal (users, computers, and groups) has a security identifier (SID). This SID is used to validate access to resources. For example, giving a user permission to read a file places that user's SID in the access control list (ACL) of the file. When that user attempts to access the file, the user's SID is compared with the ACL, and the user is either granted or denied access. SIDs are guaranteed to be unique in a domain. When a security principal is moved from one domain to another, a new SID is created. ADMT accounts for these changing SIDs by saving the security principal's old SID in its SID history. When a Windows 2000 security principal attempts to access a resource, its SID and SID history is used to determine if it can access the resource (see Figure 11.2)....