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.
Updating Remaining PDCs
To migrate your other domains, follow the pattern of updating the domain's
PDC first, one domain at a time. When DCPromo asks, you must make each
subsequent AD domain a child domain in your existing tree and provide the name of the selected parent domain, as Screen 4 shows.
When each new domain joins the AD tree, DCPromo establishes a two-way transitive Kerberos trust relationship between the domain DCPromo is upgrading and the domain's parent domain. Again, AD creates the necessary objects for the domain, and copies the existing security principals from the SAM to AD. While the domain is joining the tree, DCPromo copies the schema and configuration information (i.e., the metadata) from the parent domain and in this way learns what the tree is like.
If you decide not to put all your domains in the same tree, DCPromo gives you the option to create more than one root domain. Doing so lets you make a forest of your trees.
Life in a Mixed World
After you update the PDC, your domain works in a mixed mode. The
updated PDC represents itself as an NT 4.0 PDC to your NT 4.0 and NT 3.51 BDCs
and workstations. At the same time, the updated PDC appears as a Win2K domain
controller to other Win2K domain controllers. While your domain remains in mixed
mode, you cannot promote an NT 4.0 or NT 3.51 BDC to PDC unless all the
Win2K domain controllers are down.
After you update your PDC, you cannot retrieve the list of users and global groups from the Win2K domain to an NT 4.0 resource domain if you're logged on as the administrator of the resource domain. You can retrieve this list, however, from an NT 4.0 Service Pack 3 (SP3) domain. The reason for the discrepancy is probably because the Win2K default is to not allow anonymous access.
Users on Win2K workstations, or users on Windows 98 or Win95 workstations with AD support, can immediately access the entire AD domain tree. Users of NT 4.0 workstations must wait until you have updated all the domain's servers. If you are using the old administrative tools, you can use only the old trusts, not the whole tree.
After you've updated a domain's PDC, you can immediately start using the new AD administrative tools. For example, you can create OUs. If you put any users in newly created OUs, however, the NT 4.0 and NT 3.51 servers and workstations will see them in a straight list, without any hierarchy.
Updating BDCs
For fault tolerance, update a BDC or two in each mixed domain to AD as soon
as possible. However, you might not want to update all of a domain's BDCs at the
same time, in case something goes wrong with the migration.
In a mixed domain, two replication protocols are necessary. For the NT 4.0 and NT 3.51 servers, the PDC uses NT LAN Manager (NTLM) single-master replication. The Win2K servers use multimaster replication. Both methods let you create objects in any Win2K domain controller and replicate the objects to the other domain controllers. However, only the PDC can create security principal objects, such as users, because only the PDC can issue SIDs.
Farewell, NT 4.0
After you update all of a domain's BDCs, you can change the domain from
mixed mode to a pure AD--or native--mode. To do so, open the domain properties dialog box and choose Change Mode, as
Screen 5, page 108, shows.
Changing modes is not automatic, because doing so requires you to choose not to
install any new NT 4.0 BDCs.
After you change modes, the PDC in the now native-mode domain turns off NTLM replication support. Doing so allows multimaster replication to all servers in the domain, and therefore a distinction no longer exists between a PDC and a BDC. Now you can start nesting the groups in AD, and your NT 4.0 and NT 3.51 workstations can start using AD's transitive trusts and can access the entire domain tree.
Win2K users and groups still require SIDs, but because updated domains no longer have PDCs to issue SIDs, the domain controllers must use a Relative Identifier (RID) Pool. A user SID is a combination of a domain SID and a RID, and the Win2K server that creates a user issues the user's SID. One Win2K server at a time owns the domain RID Pool, taking RIDs for allocation to users. When another domain controller needs RIDs, ownership of the RID Pool cycles to that domain controller.
Dissolving Resource Domains
If your NT 4.0 or NT 3.51 domain model was either a master or multiple
master model, your domains likely have second-tier resource domains. Companies
usually create resource domains to decentralize resource administration. In AD,
OUs and per-server policies let you delegate resource administration within
domains more easily, and to a finer degree. Therefore, if you want to dissolve
your resource domains, you can safely do so. However, if your organization is
heavily decentralized, you can retain your resource domains and enhance their
role by moving user accounts from master domains to the pertinent resource
domains.
The idea behind dissolving resource domains is to transform the resource domains into OUs within the former master domain. You can still have decentralized administration because you can delegate administration on a per-OU basis. All users and groups stay valid in the dissolving process, but the local groups in the resource domains you dissolve need attention, because SIDs that the original resource domains issued identify local groups.
Microsoft stated that AD will support SID tracking. For example, when you move a local group from one AD domain to another, the local group receives a new SID and remembers its original SID. SID tracking keeps old access permissions valid, as long as you dissolve your resource domains in the proper sequence. However, moving objects from one domain to another is not possible in NT 5.0 Beta 2.
To dissolve your resource domains, migrate at least the PDC of the master domain to AD. This migration does not change the PDC's trusts to the resource domains but lets you administer AD. Next, create OUs that are identical to your resource domains--or if you prefer, create some other OU structure, as Figure 1 shows. It's easy to create OUs at this point, because after you migrate the master domain's PDC, all your users and groups are in the AD users container. From the users container, you move the users and groups to the appropriate OUs, and perhaps add some new OUs, depending on the structure you want to create.
After you've created your AD domain, you can migrate the PDC of each resource domain, placing each PDC in the same domain tree as the migrated master domain. This procedure lets you move users, groups, and servers from one domain to another, which was not possible in NT.
After you migrate all your resource domain PDCs, you can drag your BDCs and standalone servers from the almost-dissolved resource domains to the new AD domain. A standalone server takes its local groups wherever you move the server, so moving a standalone server does not affect that server's local group's access permissions. However, the BDCs you move need to access their local group information from the PDC until you move those local groups to the AD domain.
NT workstations are usually members of resource domains, so you need to move every workstation to the AD domain from the computers container. After taking all these steps, you can turn off your resource domain PDCs, or move them to the new AD "master" domain. In either case, in AD you have only one domain to administer.
