Section 5.5. Migrating to Active Directory in Windows Server 2003

5.5. Migrating to Active Directory in Windows Server 2003

A primary reason businesses are purchasing Windows Server 2003 is to move away from other, older operating systems. In this section, I will look at moving to Active Directory from Windows NT and Windows 2000, including steps on planning, actually moving, and then keeping your systems running smoothly.

5.5.1. Moving from Windows NT Domains

A lot of companies are finding themselves jumping the sinking Windows NT ship and considering an upgrade to the latest server product from Microsoft, Windows Server 2003. After all, the end-of-life date for the NT Workstation product was in mid-2003 and NT Server's death is fast approaching as well, so it's very possible that your organizations have some machines running NT that are worth upgrading.

Microsoft released Windows Server 2003 in late April 2003, and since then the product has matured via various updates and out-of-band releases into a server product that is more stable, reliable, and secure than any previous version of Windows. It is usually not until after the first service pack of a new Microsoft operating system ships that companies really start looking to upgrade existing systems, and Service Pack 1 for Windows Server 2003 shipped in mid-2005. So, this would be an excellent time to consider upgrading.

5.5.1.1. Items to consider before migrating

If you have an NT domain and haven't investigated Active Directory, the new directory service Microsoft introduced in Windows 2000 Server, there's a lot in store for you. Active Directory is superior to NT-style domains in many ways, not the least of which is easier management. You can divide your directory into specific domains and OUs and manage like sets of objects with ease. Active Directory is more robust and fits better into more distributed environments, particularly in organizations with branch offices in multiple locations. Active Directory is more secure for your users and is also the foundation of many newer versions of Microsoft server products, including the new Microsoft Exchange Server 2003.

Moving from NT to Windows Server 2003 and Active Directory requires several steps. First, you'll want to analyze your current NT domain environment. Specifically, you'll need to find answers to these questions:

Are you on a single domain, are you on a multiple domain model with accounts and computers located in each domain, or do you have a single master or multi-master domain model with separate domains each for user accounts and machine resources? The single domain model is the easiest to upgrade because the existing domain simply becomes the root of the Active Directory domain. However, if you have a particularly large domain or a network that might be restructured one day, you might want to consider a dedicated forest root model (sometimes called an empty root), in which you create a root domain within a forest and then create child domains off of that root, which allows you to change domains in the forest without scrapping your entire Active Directory structure. If you have a single master domain and child domains containing machines, you really don't need to continue that structure upon moving to Active Directory because you can create OUs to store specific types of objects within the directory. Multiple masters will want to use the dedicated forest root strategy because even in Active Directory, complex networks still should be broken up by domains for easier management.
What sort of trust relationships have you built up with other domains in your environment? Trust relationships can make moving to Active Directory more complicated, but they don't have to be difficult. If you have trusts among a multi-master domain model, in that every domain trusts every other domain, you don't have to do anything if you put all these domains into a single forestall of these trusts between domains are transitive automatically. If you have one-way trusts that you want to preserve for logistical reasons, you'll need to create multiple forests, which can be a headache; make sure this is the route you want to take before taking it. Figure 5-50 shows some sample trust relationships in Active Directory and how they fit together.
How many PDCs and BDCs do you have, and where are they locatedall at one location, or at separate sites? In Active Directory, the notion of the PDC and BDC has gone away (with a couple of minor exceptions). Plus, Windows Server 2003 is more robust than NT 4.0, so you can likely consolidate multiple domain controllers at a single location into a smaller number, depending on their load. Your main concern with domain controllers is their location. Part of Active Directory's technology is a replication algorithm that sends updated contents of the directory to all domain controllers within the forest, even at different sites. If you have offices in different locations with slow links, which you can define within Active Directory, this will affect your replication speed and how quickly those users at the remote offices can get authenticated and receive access to domain or forest resources. You'll want to look at how these locations will play into where you allocate domain controllers.
If you have DNS deployed internally, what namespaces are you using and how are they assigned? You'll want to catalog all these internal domain namespaces and decide how they will "map" into your new Active Directory structure. Particularly of note are how you want DNS subdomains (for example, corp.acme.com) to map to actual Active Directory domains in a forest and if you want to have external DNS services separated from internal DNS services, as I described in Chapter 4 in the split DNS section. Of course, DNS is a major component of Active Directory and entire books are written about planning and using DNS in Active Directory environments, so be sure to read up on best practices or bring someone experienced in DNS planning to assist you in your migration efforts.
Do you have any NT 4.0 servers that are running the Routing and Remote Access Service (RRAS) or the LAN Manager Replication Service? The NT RAS machines, be they domain controllers or just ordinary member servers, really don't integrate well within an Active Directory environment. If you have a member server functioning as an RAS machine, you should upgrade it to Windows Server 2003 before the last domain controller is upgraded. The RAS machine has certain security requirements that are incompatible between the different operating system versions. Also, if you have only one domain controller in your domain, you need to upgrade your RAS server before beginning any domain controller upgrades. Plus, the LAN Manager Replication Service is incompatible with the new File Replication Service found in Active Directory, so disable that as well.
Do you have any machines running versions of NT earlier than 4.0? You really need to simply rid yourself of these machines, as they're just not compatible with Windows Server 2003 or an Active Directory environment.

Figure 5-50. How trust relationships can be created and used within Active Directory

5.5.1.2. Migration strategies

Of course, any migration process is risky because your environment is changing. In this section, I'll take a look at some prudent strategies to mitigate that risk and ensure that the entire move from NT domains to Windows Server 2003 and Active Directory will go smoothly.

First, you'll want to make sure that your BDC and PDC are up to date for all NT domains you're touching with the migration. If the PDC fails to upgrade for some reason, the BDC can be promoted to PDC and nothing is lost but some time. If you have two BDCs, the best strategy is to leave one online during the migration, so users more or less don't notice that anything is going on, and take the other offline during the upgrade. This way, the offline BDC isn't touched by anything happening during the upgrade and can be plugged in, should everything go haywire. Figure 5-51 shows this procedure.

Figure 5-51. Taking a synchronized BDC offline as a failure recovery strategy

Also, synchronize your BDCs with their partner PDCs before proceeding. Out-of-date replication partners don't help anything when it comes to restoring service in the event of an outage. In the course of the migration, be sure to keep track of any changes you make after you take your BDCs offlineif your migration fails and you promote your BDC to a PDC, you will lose any changes you made since you took the BDC offline, and you'll need to manually redo any changes you made in that period.

Take some time to look specifically at the PDC for each domain and figure out if it's sufficiently powerful. When I said earlier that there are virtually no distinctions between domain controllers nowadays, I also said there were a couple of exceptions: the first domain controller upgraded into Active Directory will take on some roles that others don't have that will require a bit more operational horsepower. If you're in doubt as to whether your PDC is powerful enough, a common suggestion is to buy a new machine and load it with NT 4.0 and Service Pack 6 and configure it as a BDC. Promote it to a PDC and put it on the network for a bit to let the changes settle out and to let replication finish, and then take it offline and upgrade the machine to Windows Server 2003. This is the strategy closest to a clean install and usually gives you the best results. If you have more than one domain, do this for each domain. (Do note that if you decide to use the dedicated forest root strategy, you'll need to have a native Windows Server 2003 machine with Active Directory and create the forest and root domain before upgrading any PDCs.)

5.5.1.3. Performing the move

It's remarkably easy to upgrade any type of Windows NT installation, whether a PDC, BDC, or regular member server, to Windows Server 2003. Microsoft has taken great pains to ensure the upgrade to Windows Server 2003 is as painless as possible. The installation procedure follows a normal clean install of Windows Server 2003 reasonably closely, and in fact requires less hands-on work. The program doesn't prompt you at all after the inception of the installation; little to no reconfiguration is required with an upgrade installation because existing users, settings, groups, rights, and permissions are saved and applied automatically during the upgrade process. You also don't need to remove files or reinstall applications with an operating system version upgrade. So, at the beginning, you're asked for only the CD Key and to acknowledge any compatibility issues, and then sometime later the upgrade is complete.

There are, however, a few points of which to take note:

Service pack levels

The Windows NT installation must be running Service Pack 5 or higher. You can download the most recent update, Service Pack 6a, from:

http://www.microsoft.com/ntserver/nts/downloads/recommended/SP6/allSP6.asp

Other acceptable Windows NT versions include NT Terminal Server Edition with SP5 or later, and NT Server Enterprise Edition, also with SP5 or later.

Evaluating immediate Setup issues

On a machine that's a candidate for Windows Server 2003, insert the Windows Server 2003 CD and run winnt32.exe with the /checkupgradeonly switch. This will present a report with issues that the Setup program detects might cause problems with an upgrade to Windows Server 2003. A sample report is shown in Figure 5-52.

Also, regarding storage, you might want to examine the following disk issues before upgrading.

Partition sizes

On machines upgrading from NT to Windows Server 2003, ensure that there is plenty of disk space on the system partition of each machine. This is especially true of domain controllers because converting a SAM database to an Active Directory database full of the latter's capabilities can increase the size of the SAM by as much as 10 times.

Filesystems

Domain controllers require that their system partitions be formatted with the NTFS filesystem. Although as a general procedure I recommend formatting all partitions on all server machines with NTFS, you are not required to do so unless the machine in question is a domain controller.

Volume, mirror, and stripe sets

Upgrading to Windows Server 2003 Enterprise Edition from NT on a system with volume, mirror, or stripe sets (including stripe sets with parity) that were created under NT requires some modifications of those sets. Because Windows Server 2003 includes new dynamic disk technologies, support for older enhanced disk features has been removedand this is indeed a change from Windows 2000. You will need to break any mirror sets or, for all other media sets, back up any data on the set, and then delete the set. When Setup is complete, you can replicate your existing disk configuration using native Windows Server 2003 tools and restore any data required from the backups.

Figure 5-52. Using the Check Upgrade function of Windows Server 2003's setup to look for issues to correct

5.5.1.4. Moving domains to Active Directory

The upgrade procedure for an NT domain is relatively straightforward. Initially you must choose the first server to upgrade in your Windows NT domain. As you upgrade different machines, depending on their existing role in the domain, features and capabilities become available with Windows Server 2003 on the upgraded machine. In particular, upgrading an NT PDC enables all the included Active Directory features, as well as the other capabilities inherent in any Windows Server 2003 server, such as improved RRAS features, no matter the role. Note that you can upgrade Windows NT member servers at any time during your migration plan, and most migration plans specify that member servers are last on the list to receive the upgrade. However, no matter your order, when you begin upgrading NT domain controllers to Windows Server 2003, you must upgrade the PDC before any other domain controller machines.

Here's a checklist of some steps to take immediately prior to your move to ensure that your NT-to-Server-2003 migration goes smoothly:

Make sure that all PDCs and BDCs are running Windows NT 4.0 with at least Service Pack 5, or better, Server Pack 6a.
Clean up your domain account list, for both users and computers. We all know these lists can be cluttered with inactive users, multiple accounts for the same user, and so on. Take this opportunity to eliminate excess baggage from your directories before moving these objects into Active Directory.
Remove any unused software via its uninstallation facility, and defragment the hard disk to take advantage of any unused space. Active Directory migrations can use a lot of disk spacesometimes upward of 10 times the size of the SAM database for an NT domainand contiguous free areas of the disk can speed Active Directory query response time.
Kill any trusts between domains that you don't want preserved over the migration.

By default, domain controllers in Windows Server 2003 digitally sign network communications and verify the authenticity of parties to a transaction, which helps to prevent communications between machines from being hijacked or otherwise interrupted. Certain older operating systems are not capable of meeting these security requirements, at least by default, and as a result are unable to interact with Windows Server 2003 domain controllers. Such operating systems are Windows for Workgroups, Windows 95 machines without the Directory Services client pack, and Windows NT 4.0 machines prior to Service Pack 4. You'll also find that Windows Server 2003 domain controllers by default require all clients to digitally sign their SMB communications. The SMB protocol allows Windows systems to share files and printers, and enables various remote administration functions, as well as logon authentication over a network. If your clients are running one of the operating systems mentioned previously and upgrading them to a later revision is not an option, you'll need to turn off the digital signing and SMB signing requirements by disabling the "Digitally sign communications" policy in the Default Domain Controller GPO that applies to the OU where the domain controllers are located. You certainly can turn this feature back on when the affected computers have been upgraded.

Additionally, Windows Server 2003 domain controllers similarly require that all secure channel communications be either signed or encrypted. Secure channels are encrypted "tunnels" of communication through which Windows-based machines interact with other domain members and controllers, as well as among domain controllers that have a trust relationship. Windows NT 4.0 machines prior to Service Pack 4 are not capable of signing or encrypting secure channel communications. If NT 4.0 machines at a revision earlier than SP4 must participate in a domain, or a domain must trust other domains that contain pre-SP4 domain controller machines, the secure channel signing requirement needs to be removed. This is also in the domain controllers' security policy, under the GPO setting titled "Digitally encrypt or sign secure channel data."

5.5.2. Moving from Windows 2000 Server

Although a move from Windows Server 2003's predecessor, Windows 2000, might seem simple, there are several issues that you need to address, and many strategies for doing so. In this section, I'll discuss the implications of and procedures to moving from Windows 2000 and an existing Active Directory environment to Windows Server 2003.

5.5.2.1. About forest and domain functional levels

The first issue to consider when moving to Windows Server 2003 is functional levels. Microsoft's Active Directory has several forest and domain functional levels that enable or disable certain features of the service depending on the makeup of the domain controllers within a domain. If you have a network mixed with Windows 2000 and Windows Server 2003 domain controllers, for example, the Active Directory forest will operate in one mode; if you have a pure Windows Server 2003 environment, the forest will function in another mode after you manually switch to a higher functional level. There are three forest functional levels:

Windows 2000 forest functional level: This mode supports all types of domain controllers (NT, 2000, and Server 2003), supports only 5,000 members to a single, individual group, and only offers improved global catalog replication benefits when all domain controllers in the domain are running Windows Server 2003.
Windows Server 2003 interim forest functional level: In this level, you lose support for Windows 2000 domain controllers, but you gain partial replication of group membership lists, complete improvements to global catalog replication (because all Active Directory domain controllers are running Windows Server 2003), and support for group membership to exceed 5,000 objects.
Windows Server 2003 forest functional level: In this level, you lose support for Windows NT and Windows 2000 domain controllers, but you gain everything in the previous two levels and you add support for renaming existing domains, more efficient Active Directory replication, and transitive forest trusts.

The Windows 2000 forest functional level is the default for new forests, regardless of where you begin the forest or from where you upgrade. This mode will support a Windows 2000 or Windows Server 2003 domain controller or one or more Windows NT 4.0 BDCs. You also can use any domain functional level. You can use the Windows Server 2003 interim functional level upon upgrade from Windows NT 4.0; it supports only NT or Windows Server 2003 domain controllersno regular Windows 2000 domain controllers are allowed. In this forest functional level, you can use only Windows Server 2003 interim domain functional levels or higher. Finally, the Windows Server 2003 forest functional level is available when every last domain controller in the forest is running Windows Server 2003 and nothing below itessentially, a pure "new" environment. This forest functional level requires the Windows Server 2003 domain functional level.

Which forest functional level should you use upon an initial migration from Windows 2000? I recommend using the Windows 2000 forest functional level, at least for 90 days or so after your migration. Because you can't revert to a previous functional level, don't throw the switch until you're sure all old servers that limit your functional level choices truly aren't needed.

Here's a list of domain functional levels and some of their primary benefits and drawbacks:

Windows 2000 mixed domain functional level: This is useful for 20,000 accounts or less. You also get support for 300 sites per domain, multi-master replication (you're finally out of primarily NT land!), and support for Kerberos onto existing NTLM authentication support.
Windows 2000 native domain functional level: With this level, you can store millions of accounts, create nested groups (groups within groups within groups, and so on), and receive support for cross-domain administration.
Windows Server 2003 interim domain functional level: You do not have support for nested groups here, and you cannot use Windows 2000 domain controllers in this mode, but you do get the rest of the improvements discussed heretofore.
Windows Server 2003 domain functional level: This is the Holy Grail, as it were. You get increased site support, improved replication, and better desktop management capabilities, among other things.

The Windows 2000 mixed functional level is the default for any new domain. All of your Windows NT 4.0, Windows 2000, and Windows Server 2003 machines can coexist peacefully at this level. The Windows Server 2003 interim functional level is meant for networks going directly from NT and Windows Server 2003, so your Windows 2000 domain controllers aren't permitted. The Windows 2000 native functional level allows domains to have more than 40,000 accounts and removes other limitations from NT-based domains, but NT domain controllers aren't allowedonly Windows 2000 and Windows Server 2003 can participate in this mode. Finally, the Windows Server 2003 domain functional level is meant for pure Windows Server 2003 environments.

Most likely you'll find yourself using the Windows 2000 mixed domain functional level, and I recommend the same timeframe for domain levelswait 90 days before making a change. This will give you a chance to remove NT servers from your domain and find some way to allow any Samba servers you might have to connect to your domain.

Please do note that these functional modes dictate behavior between domain controllers in domains and forests in your Active Directory infrastructure: they have very little implication for client computers. Windows NT 4.0 client computers, with the appropriate security policy modifications, most certainly can operate in a Windows Server 2003 native mode, while Windows Server 2003 member servers can operate perfectly normally in Windows 2000 mixed mode domains. However, as a side note, WINS server deployment is affected by the presence of legacy clients: you definitely need WINS services for clients who need NetBIOS name resolution. Additionally, quite a few people mistake raising domain and forest functional levels as carte blanche to disable NetBIOS-over-TCP/IP traffic, but I advise against that: many, many legacy applications are still aroundeven some that you might not consider "legacy"that rely on NetBIOS to resolve names. Disable that feature and you break your programs, which users don't particularly care for.

We'll come to what you actually do with these beasts after you've performed the upgrade. The next step is to massage your forests and domains to get ready for the upgrade.

5.5.2.2. Preparing existing forests and domains

To upgrade to Windows Server 2003 using an existing Active Directory structure, you need to make changes to the existing forest and any domains within them. To prepare a Windows 2000 domain for the upgrade to Windows Server 2003, you must use the Active Directory Preparation tool, ADPREP. The utility performs the following tasks:

Updates the Active Directory schema
Enhances the existing security descriptors
Upgrades display specifiers
Refines settings in ACLs on Active Directory objects and on files in the SYSVOL shared folder, mainly to permit access for domain controllers
Creates new objects that COM+, Windows Management Instrumentation (WMI), and other such applications use regularly
Creates new containers in Active Directory to signal successful completion of the preparation process

Let's focus a bit more on the fourth point. In previous Windows versions, the Everyone SID, when present on an ACL or in group membership, allowed authenticated users, guest users, and those logged in anonymously to access many resources. Windows 2000 domain controllers also use anonymous access to control a few Active Directory objects and files. In an effort to improve security, Windows Server 2003 no longer allows anonymous access with the Everyone SID. This inherently restricts Windows 2000 domain controllers from controlling particular objects. To compensate, ADPREP adjusts the ACLs on such objects so that the domain controllers in question can still use them.

ADPREP is a command-line-only tool. The program, adprep.exe, is located on the Windows Server 2003 operating system CD. When executed, ADPREP copies the files 409.csv and dcpromo.csv from the I386 directory on the installation CD to the local computer to prepare the Active Directory forest and domain. Then the adprep.exe tool updates the current Active Directory schema with new information contained in the template the tool provides, while at the same time keeping any modifications to the schema that you already made.

You can reverse the changes ADPREP makes, but it is a difficult, time-consuming, and rather dangerous procedure that involves messing directly with the Active Directory schema. I don't recommend it, and it is too extensive to cover in this book.

Although a rare occurrence, ADPREP has corrupted the Active Directory database while preparing the forest on Windows 2000 domain controllers that are running any level of the operating system prior to Service Pack 2. Therefore, before running ADPREP, install at least SP2 on your Windows 2000 domain controllers to prevent this problem.

If you begin to encounter difficulty, note that ADPREP creates a log file each time it runs that can help you troubleshoot errors. The log file records each preparation step, as well as any errors found, while ADPREP is executing. The log files are separated into subfolders, identified by the date and time ADPREP was executed, under the \Windows\system32\debug\adprep directory.

Now that the background is out of the way, it's time to get started. To prepare Active Directory for the move, follow these steps:

Take the domain controller with the schema master offline.
Reconnect the schema master to a private networkjust an empty hub with no uplink will sufficeand log on using an account with Schema Admin and Enterprise Admin credentials.

Run the following command from the I386 directory on the Windows Server 2003 distribution CD:

     adprep /forestprep

Doing so will cause the following warning to pop up:

     ADPREP WARNING: All Windows 2000 domain controllers in the forest     should be upgraded to Windows 2000 SP2 or higher before performing     Windows .NET forest preparation. This must be completed to avoid     potential DC corruption. Type C and press Enter to continue, or     type any other key and press Enter to quit.

Enter C and press Enter to acknowledge the warning and continue with the forest preparations. After the utility has finished, a message appears stating that all operations have completed successfully.
Verify that the changes were made successfully by running the following at the command prompt:
```
     adsiedit.msc 
```
Note that ADSIEdit is one of the Windows 2000 Support Tools, and one of the Windows Server 2003 Support Tools. You should install these on the computer from which you are verifying the changes. You can find these support tools on the Windows 2000 or Windows Server 2003 distribution CD.
Expand the Configuration container and ensure that CN=ForestUpdates exists. Also look in CN=ForestUpdates and make sure that CN=Windows2002Update has been created.
Examine the Event Log for any event messages that indicate that the domain controller is not functioning properly. Note that you can ignore error events involving the disconnection of the schema operations master.
Reintroduce the schema master into the production environment. The changes will replicate.

After you have prepared the forest for the upgrade, it's time to prepare each domain for the upgrade:

Log on to the infrastructure master using an account with Domain Admin or Enterprise Admin credentials.
At the command prompt, type:
```
     adsiedit.msc 
```
Expand the Configuration container and ensure that CN=ForestUpdates exists. Also look in CN=ForestUpdates and make sure that CN=Windows2002Update has been created.
Run the following command from the I386 directory on the Windows Server 2003 distribution CD:
```
     adprep /domainprep 
```
After the utility has finished, a message appears stating that all operations have completed successfully.

To verify that ADPREP has completed all operations successfully, use one of the following procedures (it doesn't matter which):

Using ADSIEdit, look in the Domain container, and explore down to DC=yourdomain, DC=com, CN=System, and CN=DomainUpdates. Ensure that CN=-Windows2002Update is present. (You can find ADSIEdit in the Support Tools MSI file that I discussed several times in this chapter; run it by executing ADSIEDIT.MSC from the command line.)
In ADUC, select Advanced Features from the View menu. Look in the System container, and find and expand the DomainUpdates container. Make sure the Windows2002Update container exists.

5.5.2.3. Raising the forest and domain functional levels

Once you're ready to throw the switch and upgrade the forest and domain functional levels, do yourself a favor: simply unplug your legacy systems for a while and let any bugs in your network shake out. It's best to make sure you won't be disabling anything you need ready access to by increasing functional levels because, again, the upgrade is a one-way street: there is not a method to reverse the change.

When you have ensured that all legacy domain controllers are truly not necessary, log on to a domain controller with administrator privileges and do the following to change the domain functional level:

From the Start menu, choose Administrative tools, and then click Active Directory Domains and Trusts.
Click the applicable domain, and then select Raise Domain Functional Level. The screen will match at shown in Figure 5-53.
Select the appropriate functional level from the drop-down menu, and then click the Raise button.
Confirm your choice when prompted by clicking OK.

Figure 5-53. Raising the domain functional level

Windows will then upgrade the functional level of your domain. Keep in mind that switching to native mode is not reversible, so you will not be able to use any NT 4.0 domain controllers within that domain. Similarly, the move to Windows Server 2003 mode is final and will preclude the use of both NT and Windows 2000 domain controllers in the domain.

You can upgrade the forest functional level only after all the domains contained within the forest are operating in native mode. Once you upgrade the forest, you can only add domains that are living in the same mode or in a higher modefor domains that need to operate in a lower mode, you'll need to create an entirely new forest just for them.

With that in mind, to raise the forest functional level, follow these steps:

From the Start menu, choose Administrative tools, and then click Active Directory Domains and Trusts.
Click the applicable domain, and then select Raise Forest Functional Level. The screen will match that shown in Figure 5-54.
Select the appropriate functional level from the drop-down menu, and then click the Raise button.
Confirm your choice when prompted by clicking OK.

Figure 5-54. Raising the forest functional level

5.5.2.4. Tips for a smooth upgrade

Before you begin the upgrade from Windows 2000, install Windows Server 2003 on a computer and have it act as a simple member server of your domain. It doesn't matter in which domain you choose to have it participate: it can be any in the Active Directory forest. Monitor the server's event and error logs, and ensure that it runs without problems for at least 10 days before proceeding.

Then, after you prepare the forest and domain for upgrade by using the ADPREP tool as described in the previous sections, install Active Directory on the member server and choose to make that machine an additional domain controller in the same domain. When you do this, the member server is converted into the first Windows Server 2003-level domain controller in the forest. This lets all existing services run uninterrupted while you are upgrading other domain controllers to Windows Server 2003.

Finally, you might be wondering about the merits of a clean installationthat is, formatting a drive and starting fresh with an initial installation of Windows Server 2003or upgrading existing systems that are running Windows 2000. Traditionally, operating system upgrades have been rather tricky, with some settings and even possibly user data being lost in the process. However, Microsoft has expended a lot of effort to improve the reliability of the upgrade process and, as one colleague puts it, the results are "admirable." The benefits of performing an upgrade include the following:

Your localized settings are preserved, including display, network, and other configurations.
Your domain settings are preserved when upgrading a domain controller.
All user accounts and shared resource information is preserved.

However, with upgrade installs you don't get the opportunity to remove the detritus that accumulates when a Windows system runs for an extended period of time. This assorted crud tends to degrade performance and cause errors at random; this is the syndrome known as "Windows rot." Clean installs afford you that opportunity, but in the end it might require more work for you to recreate all the configuration and data from your earlier installation. It's your decision.