Migrating Domain Controllers to Windows 2000

Upgrading your domain controllers to Win2k is easier than you think

Your Windows NT network depends on its domain controllers for managing network accounts, groups, and logon services. Ultimately, to function within the network, all other NT servers and distributed services rely on domain controllers.

Microsoft has created one of the most advanced network OSs, Windows 2000 Server (Win2K Server), and most organizations will probably want to upgrade their systems at some point. However, because domain controllers are the foundation of a good NT network, you might find migrating your domain controllers to Windows 2000 (Win2K) similar to upgrading a building's foundation while trying to leave the rest of the structure intact. Fortunately, Microsoft made this process as easy as possible, but you must execute the migration operations in a specific order. If you follow Microsoft's upgrade roadmap, you'll successfully migrate your domain controllers and complete your Win2K upgrade without a hitch.

NT Domain Models
You can divide domain controllers into two types—PDCs and BDCs. (For more information about domain controllers, see L.J. Locher, "Understanding PDCs and BDCs," January 2000.) In NT networking, you commonly find three types of configurations for domain controllers. The first configuration is a single domain model, which consists of one domain that holds both user accounts and machine resources. The single domain model is the simplest NT domain model and one of the easiest for you to upgrade.

The second configuration is the master domain model, in which trust relationships join two or more domains together. The master domain model stores all user accounts and groups for the enterprise in the master domain (sometimes referred to as the accounts domain) and stores physical resources, such as files and printers, in resource domains. Resource domains establish a one-way trust to the accounts domain, so the resource domains can trust users that are in the accounts domain. This type of NT infrastructure is common in medium-sized and large organizations.

The third configuration is the multiple-master domain model, which you typically find in large enterprises with user and group account requirements that approach NT domain limits. The multiple-master domain model contains two or more accounts domains and, typically, multiple resource domains. Each resource domain establishes a one-way trust to each accounts domain. Users whom the accounts domain defines can therefore access resources in the resource domain.

Another domain configuration type, the complete trust model, consists of domains that have two-way trusts between one another within an infrastructure. Because administrators don't commonly use the complete trust model, I concentrate on migrating a master domain model that consists of an accounts domain and a resource domain. You can apply the same principles to migrate a single or multiple-master domain model.

Pre-Upgrade Precautions
Before you begin upgrading networks, and especially before you migrate domain controllers, make sure you have a working, readable tape backup of your servers. Another precaution you can take is to install a new NT server on your network, define it as a BDC, and let it fully synchronize with the domain's PDC before you upgrade a domain to Win2K. After you completely synchronize the BDC, take it off your network and save it until you're sure that you completed your domain migration successfully. If you must revert to your pre-Win2K state, you can take your Win2K domain controllers offline, bring your spare BDC online, and promote the BDC to PDC.

Active Directory Design
Win2K's Active Directory (AD) replaces the flat, domain-based infrastructure typical of most NT networks. If you plan your AD structure before you upgrade, you'll facilitate the entire Win2K-upgrade process. (For information about AD planning, see "Related Articles in Previous Issues," page 92.) After you finalize your AD plan, you can begin to upgrade your systems.

Accounts Domain Migration
Microsoft recommends that you first migrate the PDC for your NT network's accounts domain (which is simply your PDC machine—probably the first server you installed—if you're running a single domain). After you make sure that you have a full system backup, insert your Win2K installation CD-ROM in the server's CD-ROM drive to begin the upgrade. A dialog box will ask whether you want to upgrade your existing installation of NT. Answer Yes to launch the Win2K Server setup wizard.

From the setup wizard, choose the option to upgrade your existing installation of NT to Win2K. For my new NT test PDC, the setup wizard prompted me for only a few pieces of information at the beginning of the update process and recognized that my system was a PDC. I therefore didn't need to give domain-related information. After I provided the setup wizard with the information it wanted, the wizard ran through the upgrade process. Let the installation routine proceed, and finish upgrading your version of NT to Win2K. When the upgrade is complete, Win2K restarts and logs you on to the OS to begin the rest of the migration process.

After Win2K Server automatically boots, it launches the domain controller promotion program dcpromo.exe, or the Active Directory Installation Wizard. If you're upgrading a PDC, don't cancel this process. This program lets you add or remove domain controller services from a Win2K machine, which you can't do in NT 4.0 without fully reinstalling the OS. DCPROMO recognizes your domain characteristics, such as name, users, and groups; asks you a few questions; then begins the process of migrating your system to AD.

DCPROMO checks your computer's compatibility with Win2K and verifies that your system has the Directory Replicator, as Screen 1 shows. If you don't use logon scripts on your network, you might not be aware that this service exists. The directory replication service is an NT process that replicates files (in most instances, logon scripts) between servers. NT servers depend on this service to replicate logon scripts between systems. Because any PDC or BDC can authenticate a user on the network, you must have a copy of the logon scripts on every machine that can authenticate the user. However, Win2K doesn't support the directory replication service, so you need an alternative approach to handle your logon scripts. (For information about how to handle logon scripts in Win2K, see the sidebar "Logon Script Replication.") To proceed to the next installation step, click Next.

In this next step, you must decide whether to create a new domain tree for your enterprise or join an existing domain tree, as Screen 2 shows, to determine how your PDC will handle AD. If you've planned your AD infrastructure, you already know how to respond when you reach this screen. For my example, I assume that you want to create a new domain tree, which you'll want to do if you're migrating from a single domain. Select the first option, then click Next.

As Screen 3 shows, the Active Directory Installation Wizard asks whether you want to create this domain tree in a new forest or place it an existing forest. As I mentioned, you need to have made organizational decisions before this point in the process. If you don't have another Win2K deployment within your organization, assume that you want to create a new forest of domain trees and that this new tree will be the first tree in the forest. Select the first option, then click Next.

The Active Directory Installation Wizard walks you through several more configuration steps for your system, including DNS configuration, which is an essential part of migrating BDCs. BDCs depend on the availability of some sort of DNS service to find the former PDC. If your enterprise doesn't have a DNS solution in place, choose the option to install and configure DNS on the PDC that you're upgrading. In the remaining configuration steps, you'll need to answer questions about file locations for storing AD and shared system volume (SYSVOL). After you complete these questions, you reach the last step of DCPROMO, in which you select permissions for user and group objects, as Screen 4 shows.

In this final step, the Active Directory Installation Wizard asks you to set permissions according to their compatibility with pre-Win2K servers or Win2K-only servers. Some applications and services in NT networks use an anonymous or NULL session to query domain controllers for user information. For example, RAS, running on an NT member server, will typically use a NULL session to query a domain controller to find out whether users can dial in to the network or whether the server needs to call them back. You can disable this NULL session capability on Win2K domain controllers to increase security. However, before you disable this capability, be certain that none of your server applications require a NULL session to query a domain controller for user information. You might want to upgrade NT RAS servers to Win2K first. If you have RAS running on a BDC, you don't need to worry about NULL sessions. In this case, the server has a local copy of the account information, so it doesn't need to use a NULL session to query a domain controller to get that information.

After you answer the Active Directory Installation Wizard's questions, Win2K begins installing AD and converting your existing data to AD. When Win2K completes this process, you'll have a functional AD domain controller running on the machine that used to be your NT 4.0 PDC.

Impersonation
Although you've installed AD on your former PDC, the other legacy domain controllers can't detect the changes you made to the PDC. Installed Win2K domain controllers operate in a mixed mode, which means they can act as AD domain controllers or emulate legacy PDCs. Therefore, your new Win2K domain controller will emulate your old PDC, and your other network BDCs won't notice the change. However, you can't enable some of the more important Win2K and AD features until you switch your systems from mixed-mode to native-mode operation. For example, you might want to enable multimaster replication, which lets domain controllers make changes to AD information and propagate those changes to the other domain controllers on the network. In contrast, if you use the legacy NT model, only PDCs can write changes to the directory, then the PDCs must notify the BDCs so that the BDCs can request the changes.

You can't switch to native mode until you convert all the domain controllers in your entire network to AD-enabled status. After you switch to native mode, you can't switch back—the change from mixed mode to native mode is a one-way operation.

BDC Migration
The next step in the upgrade process is to migrate your BDCs. You upgrade BDCs in a way that is similar to the way you upgraded the PDCs. Before you begin your BDC upgrade, make sure that DNS services function on your network and that the BDCs can reach those services. If you added DNS services to your PDC as part of the upgrade, you can proceed with the BDC upgrade process. If you didn't add the DNS services to the PDC, or if you used another DNS server during your upgrade, you must have the IP address information before you upgrade the BDC.

When DCPROMO starts, it recognizes that your machine used to be a BDC and asks some slightly different questions than it asked for the PDC upgrade. For example, Screen 5 shows that DCPROMO gives you the option of either leaving the BDC functioning as a domain controller or removing the domain controller services from the BDC altogether. Unless you're making layout changes to your network during the upgrade process, leave this server as a domain controller—you can always remove the services later if they're unnecessary.

DCPROMO guides you through setting up this BDC as another domain controller in the domain tree you defined earlier. The program prompts you for a username, password, and domain to use for the Win2K domain you're joining. As with an NT 4.0 installation, this step is a security check for the initial synchronization process. Type an administrative account and password combination in your AD domain, then click Next.

The remaining questions that DCPROMO asks you are the same questions it asked when you migrated the PDC (e.g., where to store the AD and SYSVOL files). Type the required information, and click Next at each step in the process. After you supply all the information that DCPROMO needs to set up this domain controller, it begins the installation process to make the BDC a domain controller in your AD domain.

Resource Domain Migration
After you migrate your entire accounts domain to AD, upgrade your resource domains if you have any. If you want to upgrade your resource domains to the same AD tree as your accounts domain, you might want to first remove the local administrators from the administrative groups of your resource domain. This step is necessary because the Win2K upgrade creates a two-way transitive trust between the child domain (your resource domain) and the parent domain (the accounts domain). If you were using a master domain model in NT, the child and parent domains had only a one-way trust, from the child domain to the parent domain. When you create a two-way trust, you give users who had administrative rights only to your resource domain administrative rights to your accounts domain. If you're concerned about security, remove the administrative privileges from users in the resource domain who shouldn't have administrative privileges in the master (accounts) domain.

When you're ready to begin migrating your resource domains, you proceed with the same series of steps you went through to migrate your accounts domain—migrate PDCs first, then BDCs. You can move through your entire infrastructure one domain at a time and migrate all of your domain controllers to Win2K Server.

Going Native
After you completely migrate all your NT domain controllers, you can switch from mixed-mode to native-mode operation. Windows 2000 Professional (Win2K Pro) is AD-enabled by default, and you must install AD-client software on other OSs so that they can recognize AD. (AD clients are currently available for only Windows 9x.)

After you've migrated all of your systems, launch the AD Domains and Trusts Microsoft Management Console (MMC) snap-in and select your domain in the MMC scope pane. When you right-click your domain and select the Properties option, you'll see a properties page similar to the one Screen 6 shows. The lower portion of the properties page signals that the domain is running in mixed mode. To change the domain to native mode, click Change Mode. Again, this is a one-way operation, so be certain you're ready to change the mode before proceeding. A few dialog boxes will alert you that changing the mode is irreversible, but if you're ready to proceed, make the change. The switch to native mode might take a few minutes while the domain controllers communicate with one another, but after the change to native mode is complete, you can access all of the AD features.

Easy Migration
Although some network administrators might find migrating domain controllers to Win2K and AD intimidating, Microsoft has made the task relatively straightforward. If you follow the company's recommended procedures and have a well-planned AD infrastructure plan before you begin upgrading, your Win2K-upgrade process will be smooth sailing.