Migrating to Active Directory in Windows Server 2003 (part 2) - Moving from Windows 2000 Server

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.

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 controllers—no 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 it—essentially, 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 allowed—only 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 levels—wait 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 around—even 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.

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.

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:

1. Take the domain controller with the schema master offline.

2. Reconnect the schema master to a private network—just an empty hub with no uplink will suffice—and log on using an account with Schema Admin and Enterprise Admin credentials.

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

   
   

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

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

6. Expand the Configuration container and ensure that CN=ForestUpdates exists. Also look in CN=ForestUpdates and make sure that CN=Windows2002Update has been created.

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

8. 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:

1. Log on to the infrastructure master using an account with Domain Admin or Enterprise Admin credentials.

2. At the command prompt, type:

       adsiedit.msc
   

   
   

3. Expand the Configuration container and ensure that CN=ForestUpdates exists. Also look in CN=ForestUpdates and make sure that CN=Windows2002Update has been created.

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

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

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:

1. From the Start menu, choose Administrative tools, and then click Active Directory Domains and Trusts.

2. Click the applicable domain, and then select Raise Domain Functional Level. The screen will match at shown in Figure 4.

3. Select the appropriate functional level from the drop-down menu, and then click the Raise button.

4. Confirm your choice when prompted by clicking OK.

Figure 4. 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 mode—for 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:

1. From the Start menu, choose Administrative tools, and then click Active Directory Domains and Trusts.

2. Click the applicable domain, and then select Raise Forest Functional Level. The screen will match that shown in Figure 5.

3. Select the appropriate functional level from the drop-down menu, and then click the Raise button.

4. Confirm your choice when prompted by clicking OK.

Figure 5. Raising the forest functional level

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 installation—that is, formatting a drive and starting fresh with an initial installation of Windows Server 2003—or 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.