Windows Server 2003 on HP ProLiant Servers : Migration Methodologies (part 1) - ProLiant Migration

Table 1 shows the migration paths for the various Windows NT and Windows 2000 OSs to the corresponding Windows Server 2003 products. Determining which OS will fit your organization's needs is an important consideration in the initial phase of the migration. In fact, you will likely use more than one OS if you have some clustered systems or a datacenter system. In addition, Microsoft has split Web services into its own product, Windows Server 2003 Web Services, meaning you can't run a Web server on Enterprise or Standard edition like you could in Windows 2000.

The options for migrating to a Windows 2003 forest haven't changed much from those available when migrating to Windows 2000. That is, the two basic methods are the in-place upgrade and restructure, which are detailed in this section. You accomplish an in-place upgrade by using a CD on each DC to upgrade the OS, or by using automated deployment methods to accomplish this. In the in-place upgrade, the OS of the server changes from Windows 2000 or Windows NT to Windows 2003. The restructure method requires that you create a new infrastructure—new server hardware—and install Windows 2003 from scratch to create a pristine environment, and then use a migration tool to move the users, groups, and computer accounts from the Windows NT or Windows 2000 forest into the new one. Each method has its advantages and disadvantages, and you might want to use a combination of methods. These methods are described in the sections “In-Place Upgrade” and “Restructure.”

ProLiant Migration

There are a number of prerequisites to upgrading the ProLiant servers. Of course, this assumes you have carefully evaluated the servers and performed necessary upgrades to meet Windows Server 2003 requirements. Table 2 shows Microsoft's minimum requirements, which technically allow the OS to run. I have Windows Server 2003 Enterprise edition running on a 233MHz workstation with 200MB RAM, but it isn't realistic to put this in any kind of production environment. Microsoft has a tool called the AD Sizer that will help determine, among other things, the memory, disk, and CPU requirements based on your input. This tool is available at http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/adsizer.asp. HP also has configuration tools, online and offline, for the ProLiant hardware options in its Active Answers Web site. You'll find a plethora of information regarding ProLiant configurations, including application recommendations for Exchange, SQL, SAP, Netware, and many others. To access this information, go to the Active Answers Web site at http://www.hp.com/solutions/activeanswers. Click the Click here for AA Configurator and Sizing Tools link to go to the Active Answers Tools page. Under Solution Sizers, select the View Available Sizers link, and then select the appropriate application. Note that DC sizing is not included in Active Answers. However, you can configure the DCs by using Microsoft's AD Sizer tool and the ProLiant site index at http://www.hp.com/servers/siteindex.

With the hardware issues addressed, now turn your attention to issues regarding migration of the OS.

In-Place Upgrade

The in-place upgrade is a good option if you have a small- or medium-sized environment. The simplistic version of this method is to put a CD in the drive of a DC and run Setup from the CD or off the menu. When you do this on a DC, after the final reboot on upgrading the OS, it runs DCPromo and allows you to create the new forest and domain on the first DC you upgrade. On subsequent DCs, it lets you add them as replica DCs in the appropriate domain. After the first DC is upgraded and DCPromo has run, you have a Windows 2003 forest. You can then upgrade the remaining DCs as time and resources permit. You won't get all the Windows Server 2003 benefits until you switch the forest to Windows Server 2003 mode, so after all the DCs in each domain are upgraded, raise the domain functional level to Windows Server 2003. When all the domains have been raised to Windows Server 2003 level, you can raise the forest functional level of the forest. The in-place upgrade's biggest advantages include

• Less expensive than the restructure method and requires no additional hardware, migration tools, SID cleanup, and so on.

• The upgrade process automatically converts users, computers, groups, services, and so on to the new domain or forest. No need to stage user migration because it's done when the first DC is upgraded for Windows NT or Windows 2000.

• Maintains trusts, services, service accounts, applications, shares, and so on, with no need to recreate or reestablish them.

• Analyzes hardware compatibility and warns you or stops the upgrade if it's critical (see Figure 1).

  Figure 1. Warning produced during system upgrade about incompatible devices.

  

• If upgrading from Windows 2000 to Windows Server 2003 forest, you do not need to change your domain structure.

Of course, in-place upgrade has drawbacks, too:

• When upgrading from Windows NT, after all the BDCs are upgraded, the old Windows NT environment is gone. The SAM database is still there, so you can rebuild the Windows NT environment, but that would take a lot of time and expense.

• When upgrading from Windows 2000, the schema is modified, which cannot be undone. Also, the first Windows Server 2003 DC in the domain modifies the Group Policies so you no longer have native Windows 2000 policies. This isn't necessarily bad, and the risk can be mitigated with adequate testing by pulling a DC into a lab network and testing the upgrade.

• You have to address the Pile On issue if you have Windows 2000 Professional or Windows XP clients and you upgrade from Windows NT (discussed later in this section). This is not an issue when upgrading from Windows 2000.

• Maintains the domain model; that is, if you have 14 Windows NT domains, you'll have 14 Windows Server 2003 domains. A drawback for Windows NT because you'll likely want to collapse all those Windows NT resource domains into maybe a single Windows Server 2003 domain. This is not as big a deal if you are migrating from Windows 2000 because you likely won't change the domain structure for Windows 2003.

• Hardware is likely outdated. The hardware required to run Windows NT is vastly undersized to run Windows 2003 in most cases. An in-place upgrade will not allow a hardware upgrade first unless you can change processors, and add memory, add disk, and so on. Usually, it's easier to add new hardware and install Windows Server 2003 on it fresh.

The in-place upgrade keeps the domain model, so if you start with three domains, you'll end up with three domains after the upgrade. After the migration, you can collapse them into fewer domains and some Organizational Units (OUs) in separate operations. Figure 2 shows how domains A, B, and C in the Windows NT structure are migrated to a parent /child domain structure with domains A, B, and C. In the second step, domains B and C are migrated to OUs in domain A, and domains B and C are decommissioned. Restructure allows you to move from the Windows NT structure to a single domain and OUs in a single step.

Migrating from Windows 2000 to Windows Server 2003 is considered a fairly routine upgrade, and most companies I've interviewed have used the in-place upgrade method. There is no reason to redesign the domain structure unless changes have occurred since the Windows 2000 upgrade that required a new structure. However, with the Domain Rename and DC rename features, it seems unlikely to make a case for a new design.

The In-Place Upgrade Process

To upgrade from a Windows NT domain to a Windows 2003 domain, follow this procedure:

To upgrade a Windows 2000 forest to a Windows Server 2003 forest, follow this procedure:

Preparing the Windows 2000 Forest

The first step in moving the Windows 2000 infrastructure to Windows Server 2003 is to determine the “readiness” state of the domain and forest. A pre-upgrade includes the following points:

• Ensure that all DCs are at least Windows 2000 SP3, although SP4 is recommended. If you are at SP2, several hotfixes (called QFEs by Microsoft) are required. Rather than determining which QFEs you need and applying them, just install SP3 and be done with it. There are additional features in SP4, so if possible get the DCs to SP4 to make the upgrade go smoothly. Microsoft KB 331161, “Hotfixes to install on Windows 2000 domain controllers before running Adprep/Forestprep,” lists the hotfixes to install on Windows 2000 prior to running ADPrep. You can run the Windows 2003 version of Repadmin.exe (in the Windows 2003 Support Tools) from a Windows Server 2003 server or Windows XP workstation in the Windows 2000 domain and get a listing of the OS version of all the DCs with the following command:

  repadmin /showattr company.com ncobj:domain: /filter:
  "(&(objectCategory=computer)(primaryGroupID=516))"
  /subtree
  /atts:
  operatingSystem,operatingSystemVersion,
  operatingSystemServicePack
  

• Check the HCL to make sure your hardware is on it.

• In Windows 2003, anonymous SID/name translation is disabled. This means that if the Everyone group is in the Pre-Windows 2000 Compatible Access group (default), then the Anonymous Logon and Authenticated Users groups must also be in this group. Note that when ADPrep runs in a child domain, this group membership is resolved at the parent domain. If you look at the group membership of the Pre-Windows 2000 Compatible Access Group at the client, it is empty (no members).

  tip

  If ADPrep fails and records an error in the ADPrep.log indicating that you must add the Anonymous Logon group to the Pre-Windows 2000 Compatible Access group, the Anonymous Logon group shows up in the Foreign Security Principals container (view in the Users and Computers Snap-in). If it does not exist, it can be added with the following command: C:\>NET LOCALGROUP users "nt authority\anonymous logon" /add. This will add the Anonymous Logon group to the Foreign Security Principals container and to the Pre-Windows 2000 Compatible Access Group as well.

  If you get an error in the ADPrep log stating:

  Adprep encountered a Win32 error.
   Error code: 0x534 Error
   No mapping between account names and
   security IDs was done
  

  it could mean that the Pre-Windows 2000 Compatible Access group was erroneously deleted and re-created (as I have seen happen). This group has a well-known SID—S-1-5-32-554 as documented in Microsoft KB 243330, “Well Known Security Identifiers in Windows Server Operating Systems.” Re-creating it produces a new SID and will break ADPrep because it wants to see the well-known SID. The solution requires tricking ADPrep into skipping this check and continue. It will eventually create this group with the proper SID. You will need to log a call to Microsoft to do this.

  
  

• Check disk space. Windows 2003 takes 15 to 20% more space for the database and logs.

• Check for potential compatibility issues by running the winnt32 /checkupgradeonly command, using the winnt32.exe program from the /i386 directory of the Windows Server 2003 CD.

• Make sure AD replication is healthy:

  • Repadmin/showreps on each DC shows when the last successful replication occurred.

  • Repadmin /replsum /Bydest /Bysrc /sort:delta shows how long it has been since the DC replicated. This command lists all DCs in a table format so you only have to run it once.

  • Check the event logs and look for event 1311, 1722, and others that indicate replication failure. Resolve the problems. Better still, run the Directory Services version of MPS reports .

• Make sure File Replication Service (FRS) is healthy.

• Resolve any replication problems or remove the DC from the domain. You have to be able to replicate the upgrade between all DCs.

• See Microsoft KB 325379 “How to Upgrade Windows 2000 DCs to Windows Server 2003.”

The ADPrep utility to prepare the domain and the forest modifies the Windows 2000 schema, adding classes, attributes, and permissions that Windows Server 2003 requires. You can find the ADPrep.exe program on the Windows Server 2003 CD in the \i386 directory. ADPrep has two phases, domainprep and forestprep, which you execute with two different commands:

C:> ADPrep/Forestprep
C:>ADPrep/Domainprep

You must run the ADPrep/Forestprep command first on the Domain Naming Operations Master. You can easily determine which DC holds this role by installing the Windows 2000 Support Tools from the Windows 2000 Server or Advanced Server CD and executing this command:

C:> NetDom Query Fsmo
Schema owner                 ATL-DC1.Company.com

Domain role owner            ATL-DC1.Company.com
PDC role                     ATL-DC1.Company.com
RID pool manager             ATL-DC1.Company.com
Infrastructure owner         ATL-DC1.Company.com
The command completed successfully.

After that, the ADPrep/Domainprep command is run on a DC in each domain.

If ADPrep is not run successfully, an error will pop up when you attempt the upgrade, as shown in Figure 3. After ADPrep has run, it will add and populate the Forest Update container to the AD. The Distinguished Name (DN) for this object is CN=ForestUpdates, CN=Configuration, DC=Company,DC=Com. Under this object there is an operations object: CN=Operations, CN=ForestUpdates,CN=Configuration, DC=Company,DC=Com. Under the operations object, there are a number of child objects, each with a Globally Unique Identifier (GUID) for a name. These objects represent various operations performed in the schema upgrade.

There are basically three ways to determine whether ADPrep has been run:

• Try to upgrade the Windows 2000 DC. If ADPrep has not been run successfully, you'll get an error and terminate the upgrade.

• See whether the operations objects are populated in CN=Operations, CN=ForestUpdates,CN=Configuration,DC=Company,DC=Com (where DC=company,DC=com is replaced with your forest name).

• From a command prompt, run Schupgr.exe. This is a utility that is used during beta builds to upgrade the schema during development from one beta build to the next. This will yield an error, but will also report the schema version:

  C:> Schupgr
  Opened Connection to ATL-DC1
  SSPI Bind Succeeded
  Current Schema Version is 30
  Upgrading Schema to Version 30
  The Schema has already been upgraded. Rerun setup to upgrade this DC
  

The Windows 2000 schema version is version 13. The Windows 2003 schema is version 30.

The Pile On Issue

The Pile On issue has been a known issue for a couple of years now, but it still seems to be unknown to most of the Windows NT community. It affects only an upgrade with the following characteristics:

• There is an existing Windows NT 4.0 domain structure (one or more domains).

• The issue occurs only within a single domain.

• Clients and servers are Windows 2000 Member Server, Windows 2000 Professional, or Windows XP.

• An in-place upgrade is performed.

The problem occurs because the default behavior of Windows 2000 Server, Windows 2000 Professional, and Windows XP is to attempt to use Kerberos for authentication. When authentication is required at startup or user logon, these clients attempt to find a Kerberos Distribution Center (KDC) to authenticate to. All Windows 2000 and Windows Server 2003 DCs are also KDCs. If a KDC is not found, authentication takes place via NTLM. After a KDC is found, a Registry change is made and the client will authenticate only via Kerberos and will not use NTLM until the client is unjoined from the domain (to a workgroup) and then rejoins the domain.

The proper upgrade procedure for upgrading Windows NT domain to Windows 2000 or Windows Server 2003 domain is to upgrade the PDC first, and then upgrade the BDCs. However, as soon as the PDC is upgraded, client authentication across the enterprise ignores current Windows NT BDCs and authenticates to that single KDC. This happens because Net Logon, on the client, sends a DNS Query as part of the DC Locator process. That query locates the DNS that is authoritative for that domain to determine whether there is a Kerberos SRV record for a KDC. After the query finds the record and successfully contacts that KDC (domain controller), the client authenticates to that DC and will never failover to NTLM again. Thus, the clients all “pile on” the first Windows 2000 or Windows Server 2003 DC. The problems this causes are primarily the following:

• Clients in sites outside the site of the PDC will go across the WAN to authenticate, possibly causing an increase in WAN traffic. However, remember that Kerberos creates a session ticket of 10 hours so that mitigates the traffic problem.

• Clients who normally authenticate to a local BDC in their site now ignore that BDC and authenticate to the new Windows 2000 or Windows Server 2003 DC.

• If you pull that first DC off the network to try to force local authentication, the clients that have attempted to authenticate to the KDC now fail to authenticate because NTLM fallback is disabled after a KDC is found.

The trick here is to upgrade all the BDCs as soon as possible to establish the local authentication as soon as possible. Microsoft attempted to help this problem with the addition of two Registry keys, documented in Microsoft KB 284937, “Windows 2000-Based Clients Connect Only to the Domain Controller that was Upgraded First in a Mixed-Mode domain:”

• The NT4 Emulation key is enabled on the PDC. This prevents that computer from advertising itself as a KDC and thus the clients can't find it to authenticate.

• The Neutralize NT4 Emulation key is employed on BDCs. During the DCPromo process, they must find a KDC to authenticate with. If the NT4 Emulation key is enabled, DCPromo won't succeed on the other BDCs. The Neutralize key allows that machine to ignore NT4 Emulation and recognize it as a KDC. This allows DCPromo to succeed.

After each BDC is upgraded, the NT4 Emulation key must be set to prevent client authentication.

After all BDCs are upgraded, you can remove these keys to let the clients authenticate. There are a few dependencies that you can take advantage of to give you time to get all the DCs upgraded before client authentication is allowed. These dependencies include

• The client uses Net Logon to contact a DNS that is authoritative for the domain and to locate a Kerberos SRV record of a DC. The client then tries to authenticate to that DC. If it cannot find a DC to satisfy the request, the authentication fails and NTLM is used.

• Another major dependency is that the client must find the KDC after it gets the SRV record. If the clients are in a different domain than the PDC, as they likely are in Windows NT, then a Windows 2000/2003 “Kerberos” type trust is required between the domains. If it's an NTLM or downlevel trust, the clients can't authenticate to a DC.

I worked with Eastman Chemical Company, on its Windows NT 4.0 to Windows 2000 migration at the time when the Pile On issue was first discovered. At the time, Microsoft could not provide us with a single customer who had used the NT4 Emulation and Neutralize keys, which made us nervous. Through its own testing, Eastman Chemical discovered it had inadvertently solved the problem. Figure 4 shows Eastman's Windows NT 4.0 domain structure: a single Windows NT 4.0 domain called “Eastman” and several resource domains. One of the resource domains was a Windows 2000 domain, W2K.tmp, originally created just so Eastman could play with Windows 2000 to help the employees learn it, and in which Eastman had placed all their clients. The company's normal PC refresh program had gradually replaced the PCs with new ones installed with Windows 2000 Professional at the time—a perfect candidate for the Pile On problem.