Tuesday, 10 April 2012

Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Beginning the Migration Process

Any migration procedure should define the reasons for migration, steps involved, fallback precautions, and other important factors that can influence the migration process. After finalizing these items, the migration can begin.

Identifying Migration Objectives

Two underlying philosophies influence technology upgrades, each philosophy working against the other. The first is the expression “If it ain’t broke, don’t fix it.” Obviously, if an organization has a functional, easy-to-use, and well-designed Windows Server 2003/2008 infrastructure, popping in that Windows Server 2008 R2 DVD and upgrading might not be so appealing. The second philosophy is something along the lines of “Those who fail to upgrade their technologies perish.” Eventually, all technologies become outdated and unsupported.
Choosing a pragmatic middle ground between these two philosophies effectively depends on the factors that drive an organization to upgrade. If the organization has critical business needs that can be satisfied by an upgrade, such an upgrade might be a good idea. If, however, no critical need exists, it might be wise to wait until the next iteration of Windows or a future service pack for Windows Server 2008 R2.

Establishing Migration Project Phases

After the decision is made to upgrade, 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 2008 R2 Active Directory is not dramatically different from Windows Server 2003 or 2008, significant reengineering of an existing Active Directory environment is not necessary. However, other issues such as server placement, new feature utilization, and changes in AD DS 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 Server 2003/2008 to Windows Server 2008 R2. For Active Directory, this means creating a production domain controller (DC) and then isolating it in the lab and seizing the Flexible Single Master Operations (FSMO) roles with a 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 2008 R2 in advance of the migration of all other critical network servers. In a slow, phased migration, the Pilot phase would essentially transition into Implementation, as upgrades are performed slowly, one by one.
  • Implementation— The Implementation 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, subsequently, 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 2008 R2 can bring to an environment is essential in realizing the increased productivity and reduced administration that the OS 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

Due to the changes in Windows Server 2008 R2, the in-place upgrade path is limited to servers using the 64-bit version of Windows Server 2003 and Windows Server 2008. Depending on the type of hardware currently in use in a Windows Server 2003/2008 network, this type of migration strategy might be an option. Often, however, it is more appealing to simply introduce newer systems into an existing environment and retire the current servers from production. This technique normally has less impact on current environments and can also support fallback more easily.
Note
Because Windows Server 2008 R2 is a 64-bit only operating system, upgrades from 32-bit versions of older operating systems are not supported. Upgrades from Windows 2000 Server are also not supported.

Determining which migration strategy to use depends on one additional factor: the condition of the current hardware environment. If Windows Server 2003/2008 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 Server 2003/2008 servers. This is particularly true if the existing servers are veterans of previous upgrades, maybe transitioning from Windows 2000 Server to Windows Server 2003 to Windows Server 2008. If, however, the hardware in use for Windows Server 2003/2008 is newer and more robust, and could conceivably last for another two to three years, it might be easier to simply perform in-place upgrades of the systems in an environment.
In most cases, organizations take a hybrid approach to migration. Older hardware, 32-bit systems, or Windows Server 2003 domain controllers are replaced by new hardware running Windows Server 2008 R2. Newer Windows Server 2008 64-bit systems are instead upgraded in place to Windows Server 2008 R2. 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 Phased Coexistence

As with most technology implementations, there are essentially two approaches in regard to deployment: a quick “Big Bang” approach or a slower phased coexistence approach. The Big Bang option involves the entire Windows Server 2003/2008 infrastructure being quickly replaced, often over the course of a weekend, with the new Windows Server 2008 R2 environment; whereas the phased approach involves a slow, server-by-server replacement of Windows Server 2003/2008.
Each approach has its particular advantages and disadvantages, and key factors to Windows Server 2008 R2 should be taken into account before a decision is made. Few Windows Server 2008 R2 components require a redesign of current Windows Server 2003/2008 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 Server 2003/2008 and Windows Server 2008 R2 make many of these arguments moot. Windows Server 2008 R2 domain controllers can easily coexist with Windows Server 2003/2008 domain controllers. With this point in mind, it is more likely that most organizations will choose to ease into Windows Server 2008 R2, opting for the phased coexistence approach to the upgrade. Because Windows Server 2008 R2 readily fits into a Windows Server 2003/2008 environment, and vice versa, this option is easily supported.

Exploring Migration Options

As previously mentioned, the Windows Server 2008 R2 and Windows Server 2003/2008 Active Directory domain controllers coexist 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 such as Novell NDS/eDirectory, the migration path between these two systems is not rigid, and different approaches can be used successfully to achieve the final objectives desired.
In this article, three Windows Server 2008 R2 migration scenarios are explored:
  • Big Bang migration— This scenario upgrades all domain controllers in a short span of time. This is typically suitable only for single domain and small organizations.
  • Phased migration— This scenario takes a phased coexistence approach and upgrades the domain controllers in phases over an extended period of time. During this time, there is coexistence between the existing versions of Active Directory and the new Windows Server 2008 R2 Active Directory Domain Services. This is typically the approach used when there are multiple domains or for large organizations.
  • Multiple domain consolidation migration— A variation on the phased upgrade, the multiple domain consolidation migrates the existing domains to a new Windows Server 2008 R2 Active Directory domain. This is the typical approach when there are problems with the existing domains, too many domains, or when merging organizations.

No comments:

Post a Comment