This week, I discuss the steps for upgrading a Windows NT domain to a Windows 2000 (Win2K) domain. There are several factors to consider before you start your upgrade. You need to plan your DNS namespace and consider the order in which to upgrade your PDC, the BDCs, and the member servers. You also need to decide when to switch from mixed mode to native mode and take care of some other odds and ends to finish the migration. Depending on your migration plan, you can take several approaches to upgrade your NT domain to a Win2K domain. In this column, I'll keep things simple and talk about a common scenario that will work for most organizations.
Planning a DNS Namespace
Active Directory (AD) installation requires access to a DNS server. If you don’t have DNS in place, the AD installation wizard will let you install DNS service on your domain controller during the upgrade. If you're already using DNS, you need to ensure that it will work in your Win2K environment. You can use any DNS server that supports dynamic updates and SRV resource records. The AD doesn’t require dynamic updates, but I highly recommend it. AD does require support for SRV records.
If you're using Berkeley Internet Name Domain (BIND) DNS servers, Microsoft recommends BIND 8.2.1 or later. Early Microsoft documentation implies that BIND 8.1.1 works, but the latest documentation and Microsoft developers now recommend BIND 8.2.1 because Microsoft has tested it in the Win2K environment. Check out Dynamic DNS Updates in Windows 2000 for more information about DNS and Win2K. Once you have the DNS infrastructure in place, you're ready to upgrade your first domain controller.
Upgrading an NT PDC
The first server you’ll want to upgrade is your NT PDC. But before you start the upgrade process, synchronize a BDC with the PDC and take the BDC offline. If an error occurs during the migration, you can bring the BDC online and promote it to a PDC. To keep your database current, you should consider bringing the BDC online occasionally.
During the upgrade, the AD installation wizard starts automatically on NT 4.0 PDCs and BDCs. The wizard will give you the choice of joining an existing domain tree or forest or creating a new domain tree or forest. Because this is your first domain, you’ll create a new tree in a new forest and give it a name (e.g., winntmag.com). Running the AD installation wizard will promote your PDC to a Win2K domain controller and will install all the necessary AD components. What about your existing NT accounts and groups? All existing SAM objects copy from the Registry to the AD database; the user accounts copy to the Users container; the local and global groups that administrators created also copy to the Users container; the built-in groups copy to the Builtin container; computers copy to the Computers container; and the domain controllers copy to the domain controller organizational unit (OU). Notice that the only OU that exists by default is the domain controller OU. The rest of the folders are special containers, not OUs. A major difference between a container and an OU is that you can't create additional OUs inside containers; you can within OUs. In addition, you can't move, rename, or delete default OUs and containers.
When you promote your NT PDC to a Win2K domain controller, the domain operates in a mixed mode. In mixed mode, you can add NT 4.0 BDCs to the domain (see Mixed Mode vs. Native Mode for more information). At this stage, computers running the AD client software can take advantage of AD features to query objects in the AD and gain access to resources in the forest, for example. AD services client software is available for Windows 9.x and Win2K clients only—there's no such client for NT 4.0. Nevertheless, you don't have to upgrade all NT 4.0 Workstation machines to Windows 2000 Professional (Win2K Pro). NT clients can still access resources in the Win2K domain that are available through one-way explicit NT-style trusts, whether the NT clients are using Win2K domain controllers or NT 4.0 BDCs.
This first domain controller in the Win2K tree will serve as a PDC emulator for NT 4.0 BDCs. A PDC emulator operations master supports both the Kerberos v5 and the NT LAN Manager (NTLM) authentication protocols. If the Win2K domain controller becomes unavailable at this time, you can promote an NT 4.0 BDC to a Win2K domain controller or to an NT 4.0 PDC, depending on what your backup plan calls for.
Upgrading NT BDCs
After you have upgraded the PDC, you're ready to upgrade your BDCs. The upgraded BDCs will become peers of the first Win2K domain controller and will retain a complete copy of the domain database. AD supports a multimaster replication model, so if one domain controller goes offline, you can make changes to any other available domain controller. The NT domain model supports only the single master model.
You need to ensure that you have an NT BDC available as a backup. As I mentioned earlier, you should remove a BDC from the network, and I suggest that you keep that BDC as a backup for a while even after you complete the migration.
After you have upgraded all NT domain controllers to Win2K and you have no plans to add any other BDCs to the Win2K domain, you should switch the domain from mixed to native mode. In native mode, the pass-through authentication that the domain controllers support lets clients running older Windows versions take advantage of Kerberos transitive trusts and get authenticated and access resources anywhere in the forest.
Upgrading the Member Servers
After you have upgraded the BDCs, you can upgrade the member servers. Frankly, depending on the services you're running on the member servers and on your network topology, you can upgrade member servers before you upgrade BDCs. I know what you’re wondering: What about the workstations? The order in which you upgrade the desktop clients doesn't really have any significant effect on migration. Microsoft claims that you can attain several benefits by upgrading clients to Win2K Pro before upgrading your servers, but in the January 2000 issue of Windows NT Magazine, Group Publisher Mark Smith argues that if you migrate Win2K servers first, your Win2K Pro deployment will be easier.
