Exchange Server 2007 : Migrating from Windows 2000 Server to Windows Server 2003 (part 1) - Beginning the Migration Process

1. Understanding What Needs to Be Migrated to Windows Server 2003

As you plan your migration to Windows Server 2003, it would help if you knew exactly what needs to be on Windows 2003. There are many components in a network from the server on which Exchange 2007 is installed to the Active Directory to which the Exchange server is connected. Specifically, the various components of a network with which Exchange 2007 interacts include the following:

• Server operating system

• Domain functional level

• Flexible Single Master Operations roles

• Forest functional level

Exchange Server 2007 on a Windows Server 2003 Operating System

Exchange 2007 will only run on a Windows 2003 operating system (OS)—it won’t run on Windows 2000 Server or any other version of Windows. More specifically, Exchange 2007 requires an x64-bit version of Windows 2003 to run on because Exchange 2007 is a 64-bit application. Therefore, the migration path from Exchange 2000 or 2003 to Exchange 2007 typically requires a migration between servers because most organizations run earlier versions of Exchange on a 32-bit server hardware platform and on a 32-bit version of Windows.

Beyond running on Windows 2003 x64-bit edition, Exchange 2007 requires Windows 2003 x64-bit Service Pack 1 or R2 edition as the core operating system.

Exchange Server 2007 in a Windows 2000 Server Native Functional Level Domain

In addition to running on a Windows 2003 x64-bit operating system, Exchange 2007 needs to be installed in a domain that is running at a functional level of Windows 2000 native or Windows Server 2003. This means that the domain can no longer have Windows NT 4.0 domain controllers. The domain controllers in the domain must be either Windows 2000 domain controllers or Windows 2003 domain controllers. This has confused many organizations as a Windows 2000 native functional level DOES NOT mean that all Windows NT 4.0 workstations or servers must be upgraded. A Windows 2000 native functional level domain can have Windows NT 4.0 servers and workstations as member servers and systems in the domain. The Windows NT 4.0 systems just cannot be domain controllers.

Importance of Windows Server 2003 Relative to Flexible Single Master Operation Roles

The Windows domain that Exchange 2007 is installed in needs to have specific Flexible Single Master Operations (FSMO) roles. The domain controller that is the Schema Master of the forest where Exchange 2007 will reside must be running on a system that has Windows 2003 SP1 or higher installed. This is because Exchange 2007 requires a version of the schema that is not supported by the attributes available on a Windows 2000 Schema Master domain controller. As with the domain functional level, this does not mean ALL servers must be running Windows 2003 in the environment. Simply the domain controller holding the master schema for the network, which is typically the first domain controller that was used to create the Active Directory (AD) forest, needs to be running Windows 2003 SP1 or higher.

In addition, at least one global catalog server in every Active Directory site that Exchange 2007 is installed in needs to run Windows 2003 SP1 or higher. This is a requirement because Exchange 2007 gets its directory information for routing of messages as well as user and resource lookup through Active Directory objects that can only be queried on a Windows 2003 SP1 or higher global catalog system. This does not mean that every single global catalog server needs to be running Windows 2003 SP1 or higher, nor does it mean that every site needs to have a global catalog server. What this means is that every Active Directory site that has an Exchange 2007 installed in it must have a Windows 2003 SP1 or higher global catalog server.

Forest Functional Level Requirements for Server Exchange 2007

Lastly, the forest in which Exchange 2007 will reside needs to be at a forest functional level of Windows Server 2003.

In many ways, a migration from Windows 2000 Server to Windows Server 2003 is more of a service pack upgrade than a major migration scenario. Different components can be upgraded to Windows 2003 whether it is the operating system or the functional level of the domain or forest. The differences between the operating systems are more evolutionary than revolutionary, and, consequently, there are fewer design considerations upgrading from Windows 2000 Server to Windows Server 2003 than with an upgrade from Windows NT 4.0.

2. Beginning the Migration Process

Any migration procedure should identify what needs to be upgraded (server, domain, and/or forest functional level), steps involved, fallback precautions, and other important factors that can influence the migration process. After finalizing these items, the migration can begin.

Establishing Migration Project Phases

After it is determined what needs to be upgraded to Windows 2003, a detailed plan of the resources, timeline, scope, and objectives of the project should be outlined. Part of any migration plan requires establishing either an ad hoc project plan or a professionally drawn-up project plan. The migration plan assists the project managers of the migration project to accomplish the planned objectives in a timely manner with the correct application of resources.

The following is a condensed description of the standard phases for a migration project:

• Discovery— The first portion of a design project should be a discovery, or fact-finding, portion. This section focuses on the analysis of the current environment and documentation of the analysis results. Current network diagrams, server locations, wide area network (WAN) throughputs, server application dependencies, and all other networking components should be detailed as part of the discovery phase.

• Design— The design portion of a project is straightforward. All key components of the actual migration plan should be documented, and key data from the discovery phase should be used to draw up Design and Migration documents. The project plan itself would normally be drafted during this phase. Because Windows Server 2003 is not dramatically different from Windows 2000, significant reengineering of an existing Active Directory environment typically is not necessary. However, other issues such as server placement, new feature utilization, and changes in AD replication models should be outlined.

• Prototype— The prototype phase of a project involves the essential lab work to test the design assumptions made during the design phase. The ideal prototype would involve a mock production environment that is migrated from Windows 2000 to Windows Server 2003. For Active Directory, this means creating a production domain controller (DC) and then isolating it in the lab and promoting it to the Operations Master (OM) server in the lab. The Active Directory migration can then be performed without affecting the production environment. Step-by-step procedures for the migration can also be outlined and produced as deliverables for this phase.

• Pilot— The pilot phase, or proof-of-concept phase, involves a production “test” of the migration steps, on a limited scale. For example, a noncritical server could be upgraded to Windows Server 2003 in advance of the migration of all other critical network servers. In a slow, phased migration, the pilot phase would essentially spill into implementation, as upgrades are performed slowly, one by one.

• Production Migration/Upgrade— The production migration/upgrade portion of the project is the full-blown migration of network functionality or upgrades to the operating system. As previously mentioned, this process can be performed quickly or slowly over time, depending on an organization’s needs. It is important to make the timeline decisions in the design phase and incorporate them into the project plan.

• Training and support— Learning the ins and outs of the new functionality that Windows Server 2003 can bring to an environment is essential in realizing the increased productivity and reduced administration that the operating system can bring to the environment. Consequently, it is important to include a training portion into a migration project so that the design objectives can be fully realized.

Comparing the In-Place Upgrade Versus New Hardware Migration Methods

Because the fundamental differences between Windows 2000 and Windows Server 2003 are not significant, the possibility of simply upgrading an existing Windows 2000 infrastructure is an option for the domain or forest. Depending on the type of hardware currently in use in a Windows 2000 network, this type of migration strategy becomes an option. Often, however, it is more appealing to simply introduce newer systems into an existing environment and retire the current servers from production. For example, migrating a server that will host Exchange 2007 as a 64-bit operating system typically requires the acquisition of new hardware. This technique normally has less impact on current environments and can also support fallback more easily.

Determining which migration strategy to use depends on one major factor: the condition of the current hardware environment. If Windows 2000 is taxing the limitations of the hardware in use, it might be preferable to introduce new servers into an environment and simply retire the old Windows 2000 servers. Or if the server being upgraded will be an Exchange 2007 server that requires an x64-bit platform, then an in-place upgrade is not feasible. If, however, the hardware in use for Windows 2000 is newer and more robust, and could conceivably last for another 2–3 years, it might be easier to simply perform in-place upgrades of the systems in an environment.

In most cases, organizations take a dual approach to migration. Older hardware is replaced by new hardware running Windows Server 2003. Newer Windows 2000 systems are instead upgraded in place to Windows Server 2003. And systems that will be Exchange 2007 servers requiring 64-bit hardware are replaced. Consequently, auditing all systems to be migrated and determining which ones will be upgraded and which ones will be retired are important steps in the migration process.

Identifying Migration Strategies: “Big Bang” Versus Slow Transition

As with most technology implementations, there are essentially two approaches in regard to deployment: a quick “Big Bang” approach or a slower, phased approach. The Big Bang option involves the entire Windows 2000 infrastructure being quickly replaced, often over the course of a weekend, with the new Windows Server 2003 environment; whereas the phased approach involves a slow, server-by-server replacement of Windows 2000.

Each approach has its particular advantages and disadvantages, and key factors to Windows Server 2003 should be taken into account before a decision is made. Few Windows Server 2003 components require a redesign of current Windows 2000 design elements. Because the arguments for the Big Bang approach largely revolve around not maintaining two conflicting systems for long periods of time, the similarities between Windows 2000 and Windows Server 2003 make many of these arguments moot. With this point in mind, it is more likely that most organizations will choose to ease into Windows Server 2003, opting instead for the phased migration approach to the upgrade. Because Windows Server 2003 readily fits into a Windows 2000 environment, and vice versa, this option is easily supported.

Exploring Migration Options

As previously mentioned, Windows Server 2003 and Windows 2000 “play” together very well. The added advantage to this fact is that there is greater flexibility for different migration options. Unlike migrations from NT 4.0 or non-Microsoft environments, the migration path between these two systems is not rigid, and different approaches can be used successfully to achieve the final objectives desired.