Migration Case Studies

One of the best ways to understand how to accomplish a migration is to look at others who have had successful migrations. Microsoft offers a number of case studies on its Web site at http://www.microsoft.com/windowsserver2003/evaluation/casestudies/default.aspx?ddiDirectoryID=65.

In this section, I have shared some migrations I've been involved with as well.

County Government Office

Although I did not get permission to use this customer's name , this is an excellent example of a very small migration. This was a small department of a county government in the western United States. The department had an existing Windows NT 4.0 domain, and a hundred or so users who were mostly at one site, although a few were at two other sites and a few were roaming users. The department had an IT staff of only three, and its DNS services were supplied by the county IT department. In addition, the department had a mission-critical application that mainly allowed the users to use templates and create reports . All of this was stored on a server, and the department wanted some redundancy. We performed the assessment and design. The namespace was designed to be a single domain with a migration strategy of starting from scratch because of the following:

• With hardware reaching end of life, and with fewer than 200 users, the department opted to purchase new hardware, create the domain infrastructure, and then just create new user accounts rather than migrate the old Windows NT users. So, this was not a migration, but a re-creation.

• With more groups than I could imagine for an organization this size , most of which were not even used anymore, the new domain structure let the department start from scratch on groups as well.

The department faced an interesting problem. Because this office was subordinate to the county government, and no other departments were ready to go to Windows 2000 at the time, they needed a strategy to move to Windows 2000, without having to tear it down when the county government moved to Windows 2000 and created a new domain structure. In addition, because they were receiving DNS services from the county IT department, they were concerned about disrupting the county's DNS structure. They wanted to be autonomous, but have the flexibility to join the county later when they migrated to Windows 2000. We proposed the solution illustrated in Figure 3.22. The key to this working was to get the county to agree to a name for the county's Windows 2000 forest when they migrated to Windows 2000. After the name was decided (and the current DNS namespace was a reasonable name to suggest), our customer could do the following:

1. Decide on the department's domain name (i.e. Dept2.County.gov).

2. The department will create the County.gov forest and County.gov root domain and simply host it on its hardware until the county moves to Windows 2000. Then, all they have to do is add DCs to the domain and decommission the two County.gov DCs that the department created.

note

Schema changes could be introduced into the forest by this department's IT staff by installing applications that make schema changes. They could also make custom changes. In both cases, these changes will be a permanent part of the schema. The forest will have to live with those changes.

3. Identify the IP address of the Windows 2000 DNS that will host the temporary County.gov domain, and then ask the county IT department for a DNS delegation for the following zones:

• _msdcs.county.gov

• _sites.county.gov

• _Tcp.county.gov

• _udp.county.gov

They would also have to ask the county IT department to create the A record for every host that will not be resolved in the root domain, which would include every DC in the root domain and any other root domain resources.

4. Create the County.gov domain.

5. On the Windows 2000 DNSs hosting County.gov, delegate the dept2.county.gov zone to DNSs hosting the department's domain. Because the county IT department controls the county.gov domain/zone, the county department would be the one to create (another) delegation for the dept1.county.gov zone ”this would not be done within the root AD domain. In addition, note that the W2K DNSs in the root do not host the county.gov zone, only subzones of that zone via the delegation in step 3.

6. Create the department's domain with DNSs.

Figure 3.22. Proposed County.gov namespace to allow Dept. 2 to join a forest and allow for expansion for other departments.

Of course the other option would have been to just create a single autonomous domain, forward out-of-domain requests to the county IT DNS, and then migrate users, computers, groups, and member servers when the county Windows 2000 forest was created. Windows Server 2003's Kerberos Trusts would now allow each of the departments to have its own forest with appropriately configured trusts to allow authentication as needed, allowing even more flexibility for this environment. This would eliminate the dependency on selecting a root domain name as well as not binding the county to any schema changes made by the departments because each would have its own autonomous forest.

The DNS structure described is a bit unorthodox, but uses the strategy that Compaq used, as described in the next case study and in the "DNS" section of Chapter 6. Clients in the child domain find SRV records in the root by going to the county.gov BIND server and then getting referred to the Windows 2000 DNS server that hosts the four SRV zones.

When the county was ready to migrate, it could add additional DCs as needed for the existing county.gov domain (probably adding some in additional sites). It could then create the OU structure, add groups, and so on. Then, it could migrate the users and groups, computer accounts, member servers, and so on, much like a restructure plan would work. This is very similar to HP's migration into the Compaq namespace, described in the HP case study described in the next section, though on a much smaller scale. Of course, the key to this whole plan is getting the county to decide on a Windows 2000 domain name.

note

This approach could be used in other instances where one business unit ”perhaps one company whose parent is a holding company ”is ready to migrate, but the parent and peers are not.

This migration could have been helped by Windows Server 2003's Domain Rename feature, removing the dependency on getting the county to decide on a name The department could have just created a root domain with a placeholder name, handled its own DNS, and forwarded to the county DNS servers. When the county moved to Windows 2003, the department could rename its root domain and leave everything intact. Although Domain Rename could be used in this situation, it's a poor design that creates a namespace with the intention of renaming it later on. Remember that Domain Rename is not trivial. In addition, if the department had installed applications that did not support Domain Rename, then this plan would fail.

Migration from Windows 2000 to Windows Server 2003 in an infrastructure this small would require a simple in-place upgrade.

Eastman Chemical Company

Fortunately, Eastman Chemical Company, a global chemical manufacturing company (not to be confused with Eastman Kodak), gave me permission to describe its Windows 2000 migration from Windows NT. I was engaged as a consultant working for Compaq at the time to assist the design team to the point of the upgrade. Eastman's migration had several interesting facets that make its migration a good study.

Eastman Chemical Company has its world headquarters in Kingsport, TN, and has approximately 15,000 employees spread across more than 30 countries around the world. Its Windows NT configuration, depicted in Figure 3.23, was a single Windows NT master user domain with several resource domains. Although at the time, the in-place upgrade method was generally thought to be for smaller companies, Eastman decided to use it rather than a restructure. Eastman's goal was to do an in-place upgrade of the Eastman master user domain and create the Windows 2000 domain, EMN.com, shown in Figure 3.24, and then migrate the computer accounts from the W2K.tmp resource domain after all the DCs were upgraded to Windows 2000. Note that EMN.com is Eastman's internal namespace, derived from their stock ticker symbol, EMN.

Figure 3.23. Eastman Chemical Company's premigration domain structure, with user accounts in the Windows NT domain and machine accounts in the Windows 2000 "resource" domain.

Figure 3.24. Eastman Chemical's migration plan was to migrate to a single domain, EMN.com

Through diligent testing of the migration plan, Eastman Chemical found a solution to the Pile-On problem described previously in this chapter. It seemed that every time we reviewed the migration plan, we found something we hadn't seen before.

The migration plan was well thought out and worked well. The plan is illustrated in Figures 3.25 through 3.27, although these figures illustrate only a few of the 30 remote sites.

Figure 3.25. Eastman Chemical deployed a BDC for the Windows NT domain and a DC for the Windows 2000 domain in each site.

Figure 3.27. Eastman Chemical's final Windows 2000 site structure: a single DC for the EMN.com domain in each site and several DCs in the Kingston hub site.

The initial site configuration, shown in Figure 3.25, consisted of a PDC and several Windows NT BDCs in the Kingsport hub site for the Eastman domain, and a BDC in each of the major remote sites. In addition, there was a DC in each site for the Windows 2000 domain, W2K.tmp, which housed all the computer accounts. Eastman wanted to do this migration with as little downtime as possible, so the company executed the following steps:

1. The DNS and Dynamic Host Configuration Protocol (DHCP) infrastructures were configured, tested , and validated prior to the Windows migration. A number of changes were made in terms of network upgrades, DHCP lease reconfiguration, and so on. These were all completed and validated before the upgrade of the Windows environment began .

note

The DC in each site for the W2K.tmp domain were new powerful machines that Eastman wanted to use as the DCs for the new EMN.com domain.

2. Installed a "helper" DC in each of the remote sites for the W2K.tmp domain, making two DCs in each site for that domain. These helper machines were mostly workstations at the remote sites that Eastman beefed up to be temporary servers (see Figure 3.26).

Figure 3.26. Eastman Chemical installed Windows 2000 helper DCs to support the Win2K.tmp domain at each site. These allowed the actual DCs to be reinstalled in preparation for promoting into the new EMN.com domain.

3. With helper machines in place and the W2K.tmp domain stable, had a local site IT contact wipe the original W2K.tmp DCs and do a fresh install of Windows 2000 with service packs , security patches, and so on, on them. All they needed to do now was wait for the PDC to be upgraded and then run DCPromo.

note

Without the helper machines, Eastman would have had to either do an in-place upgrade on the existing BDC or do a wipe and reload, causing inconvenience to the users as they would have had to authenticate to another BDC. Of course, there is always the possibility of some failure happening on the upgrade. The helper machine eliminated nearly all of the risk of the upgrade.

This method does take extra time, planning, and hardware resources. Consider the benefit of the risk reduction to the extra time and cost to determine whether it makes sense in your environment. If you are confident that the upgrade will go smoothly (that is, you've tested the hardware, drivers, and so on, on all DCs), then a weekend upgrade ”perhaps a few per weekend ”would cause little disruption to the users.

4. Performed an in-place upgrade on the PDC in Kingsport and then upgraded all BDCs in Kingsport. The Pile-On problem was avoided, as previously described in the "Pile-On" section in this chapter.

5. With several DCs establishing the new EMN.com domain in Kingsport, the IT staff used Terminal Server to connect to the remote servers and run DCPromo to join the domain. Time differences spread DCPromo out over a period of time so it didn't create a heavy load on the network or the existing DCs.

6. After the DCs for the EMN.com were built, a Windows 2000 trust was built between the EMN.com domain and the W2K.tmp domain to permit use of a migration tool to migrate the computer accounts to the EMN.com domain.

7. The old Windows NT 4 machines were decommissioned, as well as the helper DCs in the W2K.tmp domain, leaving the structure looking like Figure 3.27.

This process had a number of benefits that included the following:

• Rather than doing an in-place upgrade on each remote Windows NT 4 machine, Eastman was able to preinstall a machine in each site to Windows 2000, and then when the new domain was established, simply do a DCPromo, which saved considerable time. This is the preferred method of an in-place upgrade. Do clean installations for the replica DCs rather than an upgrade.

  note

  Eastman Chemical upgraded only a few machines in the hub site to establish the domain, and then went back, one by one, and did a wipe and reload on those upgraded machines so that they had no "upgraded" DCs left. All were fresh installs .

  One of the first things a support engineer will ask if you have a problem following a migration is, "Was this machine upgraded or a fresh install?" If the answer is "upgrade," it's a big red flag.

  
  

• Extensive testing included taking images from the PDC, using them to build a test PDC in the lab, and practicing the migration process. This helped bulletproof the migration process plan.

• New machines were easily used to replace the old Windows NT 4.0 without migrating Windows NT to the new machines.

• Avoided the Pile-On problem by putting the computer accounts in the W2K.tmp resource domain.

note

As of this writing, Eastman Chemical is considering migrating to Windows 2003, but like most companies, it anticipates a simple upgrade with no further redesign required.

Hewlett-Packard Company (HP)

To describe this migration, we have to go back prior to HP's merger with Compaq. Compaq had nearly completed its migration from Windows NT to Windows 2000 when the merger took place. HP, on the other hand, was still in a Windows NT environment in the midst of finalizing its own plans to migrate to Windows 2000. Further, Compaq wanted to draw a tighter connection between the domain infrastructure and the mail and messaging structure, and its migration included migration to Exchange 5.5.

Compaq's Windows NT environment, due to its acquisition of Digital Equipment Corp, Tandem, and others, consisted of 13 master user domains, and about 1,700 resource domains. The company spent considerable time designing the Windows migration and the infrastructure to support a Windows 2000 environment. The new domain structure was a single forest, with a single domain tree, including a single parent ”cpqcorp.net ”and three child domains ”Americas.cpqcorp.net, asiapac.cpqcorp.net, and EMEA.cpqcorp.net. Figure 3.28 shows the dramatic change from the Compaq Windows NT structure to the new Windows 2000 structure.

Figure 3.28. Compaq collapsed its 13 Windows NT master user domains and more than 1,500 Windows NT resource domains into a single placeholder domain and 3 child domains with a 3-level OU structure.

The DNS structure is an interesting study. Starting as many companies do, with a UNIX BIND DNS, Compaq decided on a couple of points for the new namespace:

• The Windows 2000 namespace was to be cpqcorp.net.

• The company would not permit dynamic registrations on the BIND server because it didn't want to maintain dynamic records on the root server.

• The BIND server would not dynamically register host records from the Win2K forest.

To accomplish these three goals, Compaq created a Windows 2000 DNS and had the BIND server delegate the _msdcs, _sites, _tcp, and _udp zones to a Windows 2000 DNS. The BIND server then delegated the Americas.cpqcorp.net, EMEA.cpqcorp.net, and AsiaPac.cpqcorp.net zones to DNSs for each of those domains, as shown in Figure 3.29.

Figure 3.29. Compaq's DNS structure delegated the _msdcs, _sites, _udp, and _tcp zones to a Windows 2000 DNS to allow Windows 2000 to use the cpqcorp.net namespace.

Compaq employed a restructure migration method. The company built the 4-domain structure, set up the OU structure, defined policies, and so on prior to any live data (users, and so on) being introduced into the domain. Using a third-party migration tool, Compaq then migrated the user accounts from the 13 Windows NT MUDs to the appropriate geographical domain.

Resource Domain Migration

The 1,700 or so resource domains were migrated with two primary goals in mind:

• All resource domains would eventually be collapsed into various OUs in the Windows 2000 forest, unless there was a critical technical or business need that dictated otherwise .

• Member servers of resource domains would be upgraded to Windows 2000 whenever possible.

The mechanisms used for migration of nearly 1,700 resource domains varied. For instance, a large number of Windows NT resource domains existed purely for improving browsing performance and providing a home domain for desktop systems. In these cases, the servers were joined to the appropriate domain in the forest and their DCs were retired. Domains that supported file and print services consisted of all DCs. In those cases, Compaq either upgraded the hardware and used the servers in the new Windows 2000 domain, or if the hardware was not worth upgrading, Compaq transferred the data and retired the server. Because all servers were DCs, to move them to the Windows 2000 domains, Compaq used the Upromote utility (a third-party utility that allowed demotion of Windows NT 4.0 DCs) to demote the DCs. They were then upgraded to Windows 2000 and joined to the appropriate Windows 2000 domain. This continued in each resource domain until no more DCs were left, destroying the domains.

Domains that hosted infrastructure servers, such as DNS and DHCP, had their servers retired as their function was taken over by other Windows 2000 servers, eventually collapsing those domains. Finally, domains that hosted application services were handled on a case-by-case basis, upgrading or retiring the servers based on the life expectancy and cost of upgrade versus cost of the new hardware, or as a natural consequence of server consolidation, application retirement, and other factors.

In this process, hundreds of servers were retired. They were distributed to other organizations that used them for departmental file and print servers, lab machines, and so on. Even if servers are at the end of useful life for your production infrastructure, they still have many years left for other organizations in the company that could use them for

• Departmental file and/or print servers

• Departmental Web servers

• Lab machines

• Test machines for developers

• Training Labs

• Help Desk labs for problem reproduction

• Work-from-home employees. Servers that have a gigabyte of memory, combined with a virtual server product, such as VMWare Workstation or Microsoft's Virtual PC, can use these machines to host multiple virtual servers on one piece of hardware, saving on space, power bills, hardware maintenance, and so on and allowing the user to build an infrastructure on one server.

tip

I successfully taught Windows Server 2003 AD training courses to HP employees using machines with 1GB RAM and a 40GB hard disk using VMWare. I configured each virtual machine with 160MB of RAM (although Microsoft says it should be 256MB). You can network them using Network Address Translation (NAT) (host becomes a NAT server, and issues 192.168.x.y addresses to the clients), Bridged (allows access to the network that the host machine is on), and Host Only so the virtual machines can see the host and each other, but no other external machines.

This configuration allowed me to run five virtual machines on each physical computer, so I could install a parent-child domain forest with two DCs in each domain and a member server we could move as a client wherever we needed it. VMWare's new release of Workstation v4.5 allows the use of more than 1GB of RAM, so you can set up a decent- sized infrastructure on a single computer. Microsoft has a competing product, Virtual PC, which permits this same functionality.

Both VMWare and Microsoft have server-based products that allow a single host to host multiple servers for production purposes and allow server consolidation. The workstation product is good for testing and training, but not for production uses.

User Migration

Compaq divided the nearly 90,000 users up into stages and developed a Web application for the users to use to do their migration. The users would get an e-mail from IT giving them a certain period of time to go to this Web site, fill out the form, and then take steps to migrate their desktop machines. The user migration took more than two years.

When HP acquired Compaq, the decision was made to migrate the HP user accounts and adopt the Compaq namespace, Cpqcorp.net, because HP was still using a Windows NT domain structure at the time. Of course, the cpqcorp.net name didn't reflect HP, so at the time of this writing HP is considering doing a Domain Rename. To make the user migration as simple as possible and realizing a huge potential for duplicate names, HP decided to append a number to the actual user account names of all the premerger HP accounts, so JBloe became JBloe-1. Resolving friendly names was as before, appending some distinguishing characteristic such as the site code, the organization the user belonged to, and so on so they could be distinguished in the Global Address List (GAL).

Compaq's Exchange 2000 organization and HP's Exchange 5.5 organizations were connected using Simple Mail Transfer Protocol (SMTP) routing, along with the necessary network routing so that the day the merger was finalized, all employees from both companies showed up in the GAL and could send and receive e-mail. After all mailboxes are moved, the premerger HP Exchange 5.5 organization will be decommissioned and all employees will be able to share calendar information, share free/busy information, delegate mailbox access, and access the same set of Public Folders.

Migration to Windows Server 2003

As a member of Microsoft's Joint Development Program (JDP), HP had been testing Windows Server 2003 and found some exciting features that were so compelling, a business justification was never performed. These features are listed in the "Technical Justification" section earlier in this chapter. Furthermore, because the AD structure and namespace were remaining intact (with the premerger HP accounts and groups merged in), all that was required to migrate to Windows Server 2003 was an in-place upgrade.

Having tested Windows Server 2003 beta and working closely with Microsoft, HP deployed Windows 2003 RC1 on production DCs in October 2002, and then RC2 (the final beta release before RTM). By February 2003, all 154 production DCs/GCs were upgraded to Windows Server 2003, and 57 member servers running VPN, Remote Access Service (RAS), Exchange, and Windows Internet Naming Service (WINS) were upgraded to 2003 for the largest Windows Server 2003 deployment outside of Microsoft. By early March 2003, all domains were raised to functional level Windows Server 2003 (native) and then the forest functional level was raised as well.

The interesting point is that HP was running Windows Server 2003 on production DCs with beta code. Keep that in mind if you wonder if Windows Server 2003 is stable or if you need to wait for the first Service Pack.

Other Migrations

Migrations from Windows 2000 to Windows Server 2003 for Reed Elsevier Corporation and the Georgia Department of Transportation (GA DOT) are described extensively throughout Chapter 5 and 6. In addition, Reed Elsevier's case study is documented on Microsoft's Web site.