Upgrading a Windows 2000 Active Directory Forest

In many cases, the Windows 2000 environment that will be migrated includes one or many Active Directory domains and forests. Because Active Directory is one of the most important portions of a Microsoft network, it is subsequently one of the most important areas to focus on in a migration process. In addition, many of the improvements made to Windows Server 2003 are directly related to Active Directory, making it even more appealing to migrate this portion of an environment.

The decision to upgrade Active Directory should focus on these key improvement areas. If one or more of the improvements to Active Directory justifies an upgrade, it should be considered. The following list details some of the many changes made to Active Directory in Windows Server 2003:

• Domain rename capability Windows Server 2003 Active Directory supports the renaming of either the NetBIOS name or the LDAP/DNS name of an Active Directory domain. The Active Directory rename tool can be used for this purpose, but only in domains that have completely upgraded to Windows Server 2003 domain controllers.

• Cross-forest transitive trusts Windows Server 2003 now supports the implementation of transitive trusts that can be established between separate Active Directory forests. Windows 2000 supported only explicit cross-forest trusts, and the trust structure did not allow for permissions to flow between separate domains in a forest. This limitation has been lifted in Windows Server 2003.

• Universal group caching One of the main structural limitations of Active Directory was the need to establish very "chatty" global catalog servers in every site established in a replication topology, or run the risk of extremely slow client login times and directory queries. Windows Server 2003 enables remote domain controllers to cache universal group memberships for users so that each login request does not require the use of a local global catalog server.

• Inter-site topology generator (ISTG) improvements The ISTG in Windows Server 2003 has been improved to support configurations with extremely large numbers of sites. In addition, the time required to determine site topology has been noticeably improved through the use of a more efficient ISTG algorithm.

• Multivalued attribute replication improvements In Windows 2000, if a universal group changed its membership from 5,000 users to 5,001 users, the entire group membership had to be re-replicated across the entire forest. Windows Server 2003 addresses this problem and allows incremental membership changes to be replicated.

• Lingering objects (zombies) detection Domain controllers that have been out of service for a longer period of time than the Time to Live (TTL) of a deleted object could theoretically "resurrect" those objects, forcing them to come back to life as zombies, or lingering objects. Windows Server 2003 properly identifies these zombies and prevents them from being replicated to other domain controllers.

• AD-integrated DNS zones in application partition Replication of DNS zones has been improved in Windows Server 2003 by storing AD-integrated zones in the application partition of a forest, thus limiting their need to be replicated to all domain controllers and reducing network traffic.

Note

For more information on the improvements to Active Directory and the ways they can be used to determine whether your organization should upgrade, refer to Chapter 4, "Active Directory Primer," Chapter 5, "Designing a Windows Server 2003 Active Directory," Chapter 6, "Designing Organizational Unit and Group Structure," and Chapter 7, "Active Directory Infrastructure."

Migrating Domain Controllers

After the decision is made to migrate the Active Directory environment, it is considered wise to make a plan to upgrade all domain controllers in an environment to Windows Server 2003. Unlike with member servers, the full benefits of the Active Directory improvements in Windows Server 2003 are not fully realized until the entire environment is "Windows Server 2003 functional," and all DCs are upgraded. With this in mind, a mixed Windows 2000/Windows Server 2003 domain controller environment can be maintained. However, upgrading all domain controllers in an environment to Windows 2000 Service Pack 2 or higher is highly recommended because an issue with replication between domain controllers was first addressed by that service pack.

There are two approaches to migrating domain controllers, similar to the logic used in the "Upgrading a Standalone Server" section. The domain controllers can either be directly upgraded to Windows Server 2003 or replaced by newly introduced Windows Server 2003 domain controllers. The decision to upgrade an existing server largely depends on the hardware of the server in question. The rule of thumb is, if the hardware will support Windows Server 2003 now and for the next two to three years, a server can be directly upgraded. If this is not the case, using new hardware for the migration is preferable.

Note

A combined approach can be and is quite commonly used, as indicated in Figure 17.3, to support a scenario in which some hardware is current but other hardware is out-of-date and will be replaced. Either way, the decisions applied to a proper project plan can help to ensure the success of the migration.

Figure 17.3. Combined approach to the upgrade process.

Upgrading the AD Schema Using adprep

The introduction of Windows Server 2003 domain controllers into a Windows 2000 Active Directory requires that the core AD database component, the schema, be updated to support the increased functionality. In addition, several other security changes need to be made to prepare a forest for inclusion of Windows Server 2003. The Windows Server 2003 CD includes a command-line utility called adprep that will extend the schema to include the extensions required and modify security as needed. Adprep requires that both forestprep and domainprep be run before the first Windows Server 2003 domain controller can be added.

The Active Directory schema in Windows 2000 is composed of 1,006 attributes, by default, as shown in Figure 17.4. After running adprep forestprep, the schema will be extended to include additional attributes that support Windows Server 2003 functionality.

Figure 17.4. ADSI Edit before running forestprep.

Note

Windows Server 2003 R2 contains additional schema updates, above and beyond the additions that the RTM version of Windows Server 2003 introduced. If ADPrep is run from a server running R2, the schema will be extended to include not only the 2003 enhancements but the R2 ones as well.

The Adprep utility must be run from the Windows Server 2003 CD or copied from its location in the \i386 folder. The adprep /forestprep operation can be run on the server that holds the Schema Master Operations Master (OM) role by following these steps:

1.	On the Schema Master domain controller, choose Start, Run. Then type cmd and press Enter to open a command prompt.
2.	Enter the Windows Server 2003 CD into the CD drive.
3.	Where D: is the drive letter for the CD drive, type in D:\i386\adprep/forestprep and press Enter.
4.	Upon verification that all domain controllers in the AD forest are at Windows 2000 Server Pack 2 or greater, type C at the prompt and press Enter.
5.	The forestprep procedure extends the Windows 2000 AD schema, as illustrated in Figure 17.5. After the schema is extended, it is replicated to all domain controllers in the forest. Finally, close the command-prompt window. Figure 17.5. Running the adprep forestprep procedure.

After this step is accomplished, the domainprep procedure must be run.

The adprep /domainprep operation must be run once in every domain in a forest. It must be physically invoked on the server that holds the Operations Master (OM) role. The steps for executing the domainprep procedure are as follows:

1.	On the Operations Master domain controller, open a command prompt (choose Start, Run, then type cmd, and press Enter).
2.	Enter the Windows Server 2003 CD into the CD drive.
3.	Where D:\is the CD drive, type D:\i386\adprep/ domainprep and press Enter.
4.	Type exit to close the command prompt window.

After the forestprep and domainprep operations are run, the Active Directory forest will be ready for the introduction or upgrade of domain controllers to Windows Server 2003. The schema is extended and includes support for application partitions and other enhancements. The process of upgrading the domain controllers to Windows Server 2003 can then commence.

Note

Any previous extensions made to a Windows 2000 schema, such as those made with Exchange 2000/2003, are not affected by the adprep procedure. This procedure simply adds additional attributes and does not change those that currently exist.

Upgrading Existing Domain Controllers

If the decision has been made to upgrade all or some existing hardware to Windows Server 2003, the process for accomplishing this is straightforward. However, as with the standalone server, you need to ensure that the hardware and any additional software components are compatible with Windows Server 2003. After establishing this, the actual migration can occur.

The procedure for upgrading a domain controller to Windows Server 2003 is nearly identical to the procedure outlined in the previous section "Upgrading a Single Member Server." Essentially, simply insert the CD and upgrade, and an hour or so later the machine will be updated and functioning as a Windows Server 2003 domain controller.

Replacing Existing Domain Controllers

If you need to migrate specific domain controller functionality to the new Active Directory environment but plan to use new hardware, you need to bring new domain controllers into the environment before retiring the old servers. The process for installing a new server is similar to the process in Windows 2000, and the DCPromo utility can be used to promote a server to domain controller status.

Windows Server 2003 supports an enhanced Configure Your Server Wizard, however, which allows an administrator to designate a server into multiple roles. This is the most thorough approach, and the following steps show how to accomplish this to establish a new domain controller in a Windows 2000 Active Directory domain:

1.	Open the Configure Your Server Wizard (Start, All Programs, Administrative Tools, Configure Your Server Wizard).
2.	Click Next at the Welcome screen, shown in Figure 17.6. Figure 17.6. Configure Your Server Wizard.
3.	Verify the preliminary steps and click Next.
4.	Select Domain Controller from the list and click Next.
5.	Check the settings at the Summary page and click Next.
6.	After the AD Installation Wizard is invoked, click Next to continue.
7.	At the Operating System Compatibility window, click Next to verify that old versions of Microsoft software such as Windows 95 will not be supported.
8.	Select Additional Domain Controller for an Existing Domain and click Next.
9.	Type the password of an Administrator account in the AD domain and click Next to continue.
10.	Type the domain name into the dialog box of the target AD domain and click Next to continue.
11.	Enter a location for the AD database and logs. (You can achieve the best performance if they are stored on separate volumes.) Click Next to continue.
12.	Enter a location for the SYSVOL folder. Click Next to continue.
13.	Enter a password for Directory Services Restore Mode, which can be used in the event of directory recovery. Click Next to continue.
14.	Verify the tasks indicated and click Next to continue. The server then contacts another DC in the domain and replicates domain information, as indicated in Figure 17.7. Figure 17.7. Configuring AD.
15.	Click Finish when the process is complete.
16.	Click Restart Now when prompted to reboot the domain controller and establish it in its new role in AD.

Moving Operation Master Roles

Active Directory sports a multimaster replication model, in which any one server can take over directory functionality, and each domain controller contains a read/write copy of directory objects. There are, however, a few key exceptions to this, in which certain forest-wide functionality must be held by a single domain controller. These exceptions are known as Operation Master (OM) roles, also known as Flexible Single Master Operation (FSMO) roles. There are five OM roles, as follows:

• Schema Master

• Domain Naming Master

• RID Master

• PDC Emulator

• Infrastructure Master

If the server or servers that hold the OM roles are not directly upgraded to Windows Server 2003 but will instead be retired, these OM roles will need to be moved to another server. The best tool for this type of move is the nTDsutil command-line utility. Follow these steps using nTDsutil to move all OM roles to a single Windows Server 2003 domain controller:

1.	Open a command prompt (choose Start, Run and then type cmd and press Enter).
2.	Type ntdsutil and press Enter.
3.	Type roles and press Enter.
4.	Type connections and press Enter.
5.	Type connect to server <Servername>, where <Servername> is the name of the target Windows Server 2003 domain controller that will hold the OM roles, and press Enter.
6.	Type quit and press Enter.
7.	Type transfer schema master, as shown in Figure 17.8, and press Enter. Figure 17.8. Using the ntdsutil utility to transfer OM roles.
8.	Click Yes at the prompt asking to confirm the OM change.
9.	Type transfer domain naming master and press Enter.
10.	Click Yes at the prompt asking to confirm the OM change.
11.	Type transfer pdc and press Enter.
12.	Click OK at the prompt asking to confirm the OM change.
13.	Type transfer rid master and press Enter.
14.	Click OK at the prompt asking to confirm the OM change.
15.	Type transfer infrastructure master and press Enter.
16.	Click OK at the prompt asking to confirm the OM change.
17.	Type exit to close the command-prompt window.

Retiring Existing Windows 2000 Domain Controllers

After the entire Windows 2000 domain controller infrastructure is replaced by Windows Server 2003 equivalents and the OM roles are migrated, the process of demoting and removing all down-level domain controllers can begin. The most straightforward and thorough way of removing a domain controller is by demoting them using the dcpromo utility, per the standard Windows 2000 demotion process. After you run the dcpromo command, the domain controller becomes a member server in the domain and can safely be disconnected from the network.

Retiring "Ghost" Windows 2000 Domain Controllers

As is often the case in Active Directory, domain controllers may have been removed from the forest without first being demoted. This may happen due to server failure or problems in the administrative process, but you must remove those servers from the directory before completing an upgrade to Windows Server 2003. Simply deleting the object from Active Directory Sites and Services does not work. Instead, you need to use a low-level directory tool, ADSI Edit, to remove these servers. The following steps outline how to use ADSI Edit to remove these "ghost" domain controllers:

1.	Install ADSI Edit from the Support Tools on the Windows Server 2003 CD and open it.
2.	Navigate to Configuration\CN=Configuration\CN=Sites\CN=<Sitename>\ CN=Servers\CN=<Servername>, where <Sitename> and <Servername> correspond to the location of the ghost domain controller.
3.	Right-click CN=NTDS Settings and click Delete, as shown in Figure 17.9. Figure 17.9. Deleting ghost domain controllers.
4.	At the prompt, click Yes to delete the object.
5.	Close ADSI Edit.

At this point, after the NTDS Settings are deleted, the server can be normally deleted from the Active Directory Sites and Services snap-in.

Upgrading Domain and Forest Functional Levels

Windows Server 2003 does not immediately begin functioning at a native level, even when all domain controllers have been migrated. In fact, a fresh installation of Windows Server 2003 supports domain controllers from Windows NT 4.0, Windows 2000, and Windows Server 2003. You first need to upgrade the functional level of the forest and the domain to Windows Server 2003 before you can realize the advantages of the upgrade.

Windows Server 2003 supports four functional levels. The following levels allow Active Directory to include down-level domain controllers during an upgrade process:

• Windows 2000 Mixed Domain Functional Level When Windows Server 2003 is installed into a Windows 2000 Active Directory forest that is running in Mixed mode, it essentially means that Windows Server 2003 domain controllers can communicate with Windows NT and Windows 2000 domain controllers throughout the forest. This is the most limiting of the functional levels, however, because functionality such as universal groups, group nesting, and enhanced security is absent from the domain. This is typically a temporary level to run in because it is seen more as a path toward eventual upgrade.

• Windows 2000 Native Functional Level Installed into a Windows 2000 Active Directory that is running in Windows 2000 Native mode, Windows Server 2003 runs itself at a Windows 2000 functional level. Only Windows 2000 and Windows Server 2003 domain controllers can exist in this environment.

• Interim Level Windows Server 2003 Interim mode enables the Windows Server 2003 Active Directory to interoperate with a domain composed of Windows NT 4.0 domain controllers only. Although this is a confusing concept at first, the Windows Server 2003 Interim functional level does serve a purpose. In environments that seek to upgrade directly from NT 4.0 to Windows Server 2003 Active Directory, Interim mode allows Windows Server 2003 to manage large groups more efficiently than if an existing Windows 2000 Active Directory exists. After all NT domain controllers are removed or upgraded, the functional levels can be raised.

• Windows Server 2003 Functional Level The most functional of all the various levels, Windows Server 2003 functionality is the eventual goal of all Windows Server 2003 Active Directory implementations.

After all domain controllers are upgraded or replaced with Windows Server 2003, you can raise the domain and then the forest functional levels by following these steps:

1.	Ensure that all domain controllers in the forest are upgraded to Windows Server 2003.
2.	Open Active Directory Domains and Trusts from the Administrative Tools.
3.	In the left pane, right-click Active Directory Domains and Trusts and then click Raise Domain Functional Level.
4.	In the Select an Available Domain Functional Level box, click Windows Server 2003 and then select Raise.
5.	Click OK and then OK again to complete the task.
6.	Repeat steps 15 for all domains in the forest.
7.	Perform the same steps on the forest root, except this time click Raise Forest Functional Level in step 3 and follow the prompts, as indicated in Figure 17.10. Figure 17.10. Raising the forest functional level.

Note

The decision to raise the forest or domain functional levels is final. Be sure that any Windows 2000 domain controllers do not need to be added anywhere in the forest before performing this procedure. When the forest is Windows Server 2003 functional, this also includes being unable to add any Windows 2000 Active Directory subdomains.

After each domain functional level is raised, as well as the forest functional level, the Active Directory environment is completely upgraded and fully compliant with all the AD improvements made in Windows Server 2003. Functionality on this level opens the environment to features such as schema deactivation, domain rename, domain controller rename, and cross-forest trusts.

Moving AD-Integrated DNS Zones to Application Partition

The final step in a Windows Server 2003 Active Directory upgrade is to move any AD-integrated DNS zones into the newly created application partitions that Windows Server 2003 uses to store DNS information. To accomplish this, follow these steps:

1.	Open the DNS Microsoft Management Console snap-in (Start, All Programs, Administrative Tools, DNS).
2.	Navigate to DNS\<Servername>\Forward Lookup Zones.
3.	Right-click the zone to be moved and click Properties.
4.	Click the Change button to the right of the Replication description.
5.	Select either To All DNS Servers in the Active Directory Forest or To All DNS Servers in the Active Directory Domain, depending on the level of replication you want, as shown in Figure 17.11. Click OK when finished. Figure 17.11. Moving AD-integrated zones.
6.	Repeat the process for any other AD-integrated zones.