Migrating to Active Directory

Windows 2000 (Win2K--­formerly Windows NT 5.0) will initiate the largest NT server upgrade since NT launched 5 years ago. The most important aspect of your Win2K rollout is migrating your existing domain structure to Win2K's Active Directory (AD). If you have a single-domain model, your migration will be fairly simple. But if your domain model is complex, with decentralized administration, you need to study your options and prepare a migration plan. The good news is that Microsoft says you can migrate one server and workstation to AD at a time. This flexibility is possible because the new Win2K servers represent themselves as NT 4.0 servers to NT 4.0 and NT 3.51 workstations.

In this article, I'll describe the migration process from NT 4.0 or NT 3.x domain models to Win2K's AD. I'll begin by describing how Win2K's domain models are different from the domain models in NT 4.0 and NT 3.x. I'll suggest some ways you can improve on your domain models by taking advantage of AD's expanded administrative rights. Then, I'll show you how to migrate your domains to AD.

First Things First
You need to tend to an important task before you begin your migration--­planning your Win2K network. Your plan needs to cover domain structure, trees, forests, sites, organizational units (OUs), server placement, replication, Domain Name System (DNS) architecture, and group policies. Then, before you migrate your existing domains to AD, you need to upgrade your DNS services to Win2K's dynamic DNS. AD needs several records in DNS, and Win2K's dynamic DNS can add these records automatically. (For more information about dynamic DNS, as well as other features of Win2K I mention in this article, see Sean Daily, "10 Steps to Prepare for NT 5.0 Now!" February 1998.) If you don't currently have dynamic DNS, you need to implement it before you migrate to AD. BIND 8.1.2 supports dynamic updates, but older versions of BIND don't have this support.

Migrating Your Domain Models
Microsoft defined four domain models for NT 4.0 and NT 3.x: single, master, multiple master, and complete trust. If you migrate to AD from a single domain model, you likely will retain a single domain in Win2K. By creating OUs in your Win2K single domain, however, you can introduce a degree of administrative delegation that wasn't possible with the earlier model. If you migrate to AD from the master domain model, you can either dissolve your resource domains to take advantage of AD's granularity, or you can retain the resource domains.

You can migrate a multiple master domain model to either a domain tree or a forest (an AD domain tree is a group of domains, connected by trust relationships, that share a contiguous namespace--­a forest is a group of trees). If your enterprise's administration can agree on who will own and maintain the root domain, you can migrate your company's multiple master domain model to one tree. With one tree, you can implement each business unit as a second-level domain below the root domain, and each second-level domain can have child domains. You can also create the second-level domains according to geographic location. A more decentralized approach is to let each business unit create its own domain tree, and join the trees into a forest. In a forest, you have no common security policies and no common root domain to maintain. However, you can give any user access permissions to any resource in the enterprise, and the trees in your forest have a common schema and catalog.

If your NT 4.0 or NT 3.51 domain is a complete trust model, you can make a forest of your independent domains after migrating to AD. Alternatively, you can try some domain coordination and migrate the domains to one tree.

Updating Your First Server
Before you update the first server in the domain you intend to be your AD root domain, take one Backup Domain Controller (BDC) offline. If you can't spare an existing BDC, install a new one and take it offline. You'll need this BDC if something goes wrong; it serves as an NT 4.0 server you can promote to PDC and use to restore your domain. If you need this BDC, it won't, of course, include any changes such as changes in user passwords or the addition of new users. If losing these changes poses a problem, you can take a second BDC offline and bring it back online every now and then when the migration is in a stable state.

The first server you will update is the PDC of the domain that you want to be your Win2K root domain. After your OS upgrade is complete and Win2K boots, the PDC you've chosen to promote first is a standalone server. At this point, the Active Directory Installation Wizard (also known as DCPromo) launches automatically. In the promotion process, which the wizard leads you through, you designate the first PDC as the first domain controller of the first domain of the first domain tree in the first forest, as Screen 1 shows. DCPromo creates an AD tree and the necessary AD objects for the tree and the domain.

The promotion process copies the users, global groups, local groups, and computer accounts on the PDC from the Security Accounts Manager (SAM) database to the new AD directory store. These four types of accounts are security principals, and they all have security IDs (SIDs). AD places local groups in the builtin container, places users and global groups in the users container, and places computer accounts excluding domain controllers in the computers container. AD places domain controllers in the domain controllers container. The builtin, users, and computers containers are special containers, and the domain controllers container is an OU.

One difference between special containers and OUs is that special containers don't give you the option of managing group policies within them, as you can do with OUs. You can view upgraded accounts and the containers AD places them in through the Microsoft Management Console (MMC)-based administrative utility, Active Directory Manager, which Screen 2 shows.

Password and lockout properties migrate to the Default Domain Account Policy object. User rights and auditing policy migrate to the Default Domain Controllers Local Policy object. Both objects are part of AD's extensive Group Policy infrastructure, which controls numerous settings for users and computers, including security settings.

You can see the outcome of the migration by using either Active Directory Browser, which Screen 3 shows, or Active Directory Manager. You'll see more information in Active Directory Manager if you select Advanced Features from the View menu.