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