Migration Methodologies

In planning a migration, it's important to consider hardware upgrades in addition to all the migration tasks associated with upgrading the OS. Microsoft's HCL has changed dramatically for Windows Server 2003, compared to Windows 2000, so you might be forced to consider hardware upgrades prior to a migration to Windows Server 2003, and most certainly will need to upgrade if you are coming from Windows NT. This section lists some basic points to take into consideration when upgrading ProLiant servers, whereas Chapter 7, "ProLiant Server Installation and Deployment," delves into deployment in more detail.

Table 3.4 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.

Table 3.4. Migration Paths

Current OS	Upgraded OS
Windows NT 4.0 Enterprise Server	Windows Server 2003, Enterprise Edition
Windows NT 4.0 Server	Windows Server 2003, Standard Edition
Windows 2000 Server	Windows Server 2003, Standard Edition
Windows 2000 Advanced Server	Windows Server 2003, Enterprise Edition
Windows 2000 Datacenter Server	Windows Server 2003, Datacenter Edition
(Web services not previously separated into a separate product in Windows NT and Windows 2000)	Windows Server 2003, Web Edition

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 3.5 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.

Table 3.5. ProLiant Recommended Minimum System Configuration Requirements

Parameter	Web Edition	Standard Edition	Enterprise Edition	Datacenter Edition
Processor	550MHz	550MHz	733MHz	733MHz
RAM	256MB	256MB	256MB	1GB
Monitor resolution	VGA+	VGA+	VGA+	VGA+

note

There are no magic tools or formulas that will tell you the exact specifications needed for DCs and GC servers because of dynamic variables such as groups, users, computers, Group Policies, and so on. These tools will give you a good start, but make sure that you test the hardware configuration during the pilot. Applications such as SQL and Exchange can be sized fairly accurately using the Active Answers tools.

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 3.12).

  Figure 3.12. 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.

note

A Windows 2003 DC can exist in a Windows 2000 native-mode domain or a Windows 2003 native-mode domain. However, the ADPrep utility must be run on a Windows 2000 native-mode domain to upgrade the schema before bringing a Windows 2003 DC into the domain either via an upgrade of a Windows 2000 DC or a newly installed server.

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 3.13 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.

Figure 3.13. In-place upgrade process.

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:

1. If you will be affected by the Pile On problem, decide how you will deal with it. Upgrade the PDC of the domain.

warning

Normally, if you try to upgrade a BDC first, it will fail because the PDC isn't Windows 2000 or 2003. However, if the PDC can't be contacted you will simply get a warning. If you ignore the warning and upgrade the BDC first, you will likely be calling HP or Microsoft for help in recovering.

2. Upgrade the BDCs as quickly as possible to support the domain structure and clients.

3. Raise the functionality level of the domain to Windows Server 2003.

4. When all the domains are raised to Windows Server 2003 level, raise the functionality level of the forest to Windows Server 2003.

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

1. Run ADPrep/forestprep and then ADPrep/domainprep to upgrade the schema and allow a Windows Server 2003 DC to join the domain (see the next section for details).

2. Upgrade each DC one by one to Windows Server 2003.

3. Raise the functionality level of the domain to Windows Server 2003.

4. When all the domains are raised to Windows Server 2003 level, raise the functionality level of the forest to Windows Server 2003.

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 (see http://microsoft.com/downloads/details.aspx?FamilyId=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en).

• Make sure File Replication Service (FRS) is healthy. Refer to the "File Replication Service" section in Chapter 5 for details on running the Ultrasound utility and help files to resolve FRS problems.

• 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 

warning

Don't confuse the Windows 2003 ADPrep utility with the ADPrep utility used to upgrade Microsoft Exchange. You still need to run the ADPrep utility for Exchange for an Exchange upgrade, in addition to the ADPrep for Windows Server 2003. They are different programs and are not interchangeable.

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.14. 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.

Figure 3.14. Performing an upgrade without first successfully running ADPrep results in this error message and terminates the operation.

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, whose migration is profiled later in this chapter, 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 3.15 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.

Figure 3.15. The Eastman Chemical company domain structure.

During testing, Eastman found that because a downlevel trust existed between W2K.tmp where the machine accounts existed, and the Eastman accounts domain, the clients couldn't use Kerberos to authenticate across that trust, and thus the company could upgrade the PDC without fear of a Pile On condition and without messing with the Registry keys. The upgrade was successful. We upgraded the PDC and several BDCs in the corporate hub site in one weekend and gradually upgraded the BDCs in the remote sites over the next several weeks. After they were all upgraded, the trust was converted to a Kerberos type trust and authentication switched from NTLM to Kerberos.

The "Case Studies" section later in this chapter details how Eastman Chemical used an ingenious plan to shorten the time of the upgrade and mitigate the risk of failure with an in-place upgrade.

Restructure

The restructure method is depicted in Figure 3.16. In step one in the figure, we get new servers and create a pristine Windows 2003 domain structure, including domains, OUs, Group Policies, security structure, and so on. Then, in step two, obtain a migration tool such as the Active Directory Migration Tool (ADMT) that Microsoft provides on the Windows 2003 Server CD, or one from a third-party company, and use it in step three to migrate the users and groups from the old domain structure (Windows NT or 2000) to the new. Step four shows migration of users and groups from resource domains to Windows 2002 OUs. This was not possible in the In-Place Upgrade method (that is, you had to migrate users and groups from the resource domains to Windows 2000 child domains and then migrate them to OUs in a single domain). Unlike the in-place upgrade, this method allows you to use the migration tools to stage the migration of users, groups, and computer accounts; select the destination as a particular domain or OU; migrate or change the users'passwords; and even test it to get a report of any errors encountered.

Figure 3.16. The restructure method allows movement of users, groups, and computers directly into the Windows 2003 domain structure domains or OUs.

The advantages of this method include

• Flexibility allows the collapse of many Windows NT domains into a single domain/OU structure or to any other domain structure you want to use in a single step.

• For large organizations, this method allows you to stage the migration of users over time to reduce the impact on users and calls to the help desk.

• For companies that have acquired or merged with one or more companies that also have Windows NT or Windows 2000 domain structures (or both), this is the way to merge them into a single structure.

• Very sophisticated tools exist to allow you to design the project stages, test the stages, and fix the errors before the actual migration, reducing the risk of migration considerably.

• For small organizations of 10,000 users or fewer or with only a few different sites, ADMT v2.0, is available on the Windows Server 2003 CD in the \i386\ADMT directory and as a free download from Microsoft's download Web site. Details on the new features of ADMT v2.0 are included later in this chapter. ADMT is also a handy tool for moving users, groups, and computer accounts to new domains or OUs when reorganization is required later on.

• No Pile On issues to worry about.

• No need to run ADPrep for a Windows 2000 domain structure.

• Less risk in that the original domain structure and all the users, groups, and computer accounts are left intact. The back out plan is to simply re-enable the accounts in the old domain and force the clients to authenticate back to the old domain.

The disadvantages to the restructure method include

• Higher cost than the in-place upgrade due to the investment in additional hardware and a migration tool. However, if you are upgrading from Windows NT, you likely want to get new hardware to meet the Windows Server 2003 specifications anyway, and you might be able to use the free ADMT from Microsoft.

• Takes a longer time as opposed to the in-place upgrade, where users are migrated as the upgrade runs on the server.

• Must re-establish services, re-install applications, re-establish trusts, and so on.

• Unnecessary if upgrading from Windows 2000 to Windows Server 2003. An in-place upgrade is likely all that is required. Multiple environments have to be maintained and support during the coexistence phase.

The process of restructure is pretty straightforward:

1. Install new hardware and create the new AD infrastructure.

2. Obtain a migration tool.

3. Create trusts between the old domains and the new Windows Server 2003 domains.

4. Re-establish services, service accounts, trusts, applications, and so on.

5. Plan and migrate the users, computers, and groups.

As you can see from the list of advantages and disadvantages, restructure is more appropriate when migrating from Windows NT to Windows Server 2003 than from Windows 2000 unless a restructure of the namespace is required in a case such as a merger or acquisition. In the "Case Studies" section later in this chapter, examples are given of organizations that used the restructure method and others that used the in-place upgrade method.

ProLiant Post-Upgrade Tasks

There are several points to consider in regard to the ProLiant server when upgrading to Windows Server 2003:

• Make sure you enable SNMP. SNMP is disabled in Windows Server 2003 by default and is required by the ProLiant management agents .

• Re-team any NICs that were dissolved before the upgrade.

• After the teamed NICs are re-enabled, install the latest version of the ProLiant Support Pack (PSP).

• If Multipath Software was installed, install HP Smart Array Multipath Software v2.0.

Some of the current known issues encountered during the upgrade on ProLiant servers include

• A Windows 2000 manual upgrade to Windows Server 2003 prompts a message, reporting the need for CPQTEAM.DLL. Select cancel to continue the upgrade and install PSP after upgrade completes.

• HP Smart Array Multipath Software v1.0 is not compatible with Windows Server 2003. Upgrade to v2.0.

• Software fault-tolerant volumes (dynamic disks) fail during driver upgrade or rollback. Restore from backup.

• Upgrading miniport driver for secondary device requires reboot.

• Startup and recovery server options revert back to default settings after an upgrade. Change back to the desired setting.

• ProLiant Advanced System Management Controller Driver for Microsoft Windows Server 2003 (CPQASM.SYS) will not load on the ProLiant 3000, 5500, or 6500. Use cp003476.exe.

Additional details on ProLiant deployment are provided in Chapter 7. Now let's look at migrations within a forest and between existing forests.

Intra- and Inter-Forest Migrations

In addition to changing the structure of the entire domain from Windows NT or Windows 2000 to Windows Server 2003, there is usually an ongoing need to change the structure of OUs, location of users, groups, and computers within a forest, or between domains in a forest. In the case of a merger or acquisition, you might need to perform a migration between Windows 2003 forests or from a Windows 2000 forest and a Windows Server 2003 forest. The tools noted in the previous section of this chapter are all capable of performing such migrations. In addition to those tools, other utilities are available that are native to Windows Server 2003 and in the Windows Server 2003 Support Tools that are handy for manipulating a small or large numbers of objects. These tools include

• MoveTree : Command-line utility that permits a move operation of objects between domains in a forest.

• Ldifde : Command-line utility that provides bulk migration of AD objects such as users, groups, computer accounts, and even OUs between domains in a forest and from forest to forest. Ldifde permits exporting AD objects from the AD to a flat text file, as well as importing them into the AD. Because the intermediary is a text file, you can export the objects, make modifications to them such as adding additional attribute values, and import them back into the same AD or into another. You can use filters to export or import only desired classes of objects (such as only users whose surnames begin with the letters P through Z) or only certain attributes (such as changing the address of users at an office that moved to a new location). Ldifde does not preserve the security context or password. A more descriptive treatment of Ldifde is contained in Chapter 10, "System Administration."

• CSVDE : Much the same capabilities as Ldifde, but the intermediary file is a CSV file.

• Dsadd : Adds objects to the AD such as users, groups, computer accts, and OUs.

• Dsmove : Moves a single object, or multiple objects, within a domain. Can also rename them without a move.

• Dsrm : Command-line utility to remove objects from AD.

• Dsmod : Command-line utility to modify attributes of a user, group, computer, contact, OU, DC, quota, or partition.

• Dsquery : Queries the AD to find objects, including computer, contact, group, OU, site, server, user, quota, or partition. It also allows the use of a wild card (*). For instance, you could get a list of all objects (group, OU, user, and so on) in a domain.

• Dsget : Command-line tool that displays properties of AD objects, including computer, contact, subnet, group, OU, server, site, user, quota, and partition. You can display all attributes or filter for certain ones. Use of the wild card * is permitted.

All these utilities are well documented in the Windows Server 2003 Help and Support in the Start menu, and in the command line online help by typing /? after the command. The additional power of these commands is realized by combining them in scripts. The ds* commands in the previous list are all new to Windows Server 2003.