Preparing for the Migration and Active Directory

Training your administrative and design team is an important part of obtaining the technical details for implementing a new environment. For the early adopters, experienced Active Directory designers are hard to find. The best way to get up to speed is with training from Microsoft. This provides your staff with a strong foundation for moving forward with the methodology described in this book.

Revaluate Your Administrative Model

As part of preparing for Active Directory, re-evaluate your administrative model and determine how you are going to use group policies and the directory. With the flexibility of the tools and the granularity of administrative responsibilities that can be delegated, it is important to take some time to step back and determine how you want your environment administered.

Look at Current Windows NT 4.0 Groups

With your move to Active Directory, you want to take a close look at your current Windows NT 4.0 group structure and document it. Groups have changed with Active Directory and Windows 2000. There are four types of groups available in Windows 2000. The groups available in Windows 2000 is described later and depicted in Table 22.1.

It is important to understand the affect groups have when Windows is running in Native Mode or mixed-mode. You should also take the time to understand your use of local groups. After careful research, it is time take your findings into the lab, test the migration process, and validate that the proper access has been migrated or eliminated.

Upgrade Process for Windows NT 4.0

If migrating from Windows NT 4.0, several items need to be considered. They are the PDC upgrade, the resource domain upgrades, the actual upgrade steps, and the order of the domain upgrades.

When you upgrade the PDC, it becomes the first domain in the new Windows 2000 tree, and by default it is running in mixed-mode. Mixed-mode means that the system is emulating a PDC for the old domain for all the BDCs that still exist in the old domain (PDC emulation). Any changes made for a BDC on the old domain are made to the PDC just like in a Windows NT 4.0 environment.

"Mixed-mode" means that there are still Windows NT 4.0 DCs. "Native Mode" means that all DCs are Windows 2000. The PDC emulator continues to provide some services even in a Native Mode environment. For example

• Down-level client authentication

• Password changes are replicated preferentially to the PDC emulator

• Account lockouts are processed through the PDC emulator

The Windows NT 4.0 Security Account Manager (SAM) is uploaded into Active Directory. Windows NT 4.0 BDCs can be added while Active Directory is in mixed-mode. You also want to make sure that all the trusts that were in the previous environment are maintained. The mixed-mode PDC is still the account domain for the remaining Windows NT 4.0 systems.

Multiple PDCs

If you have multiple Windows NT 4.0 domains and thus multiple PDCs, the second PDC needs to be upgraded into the Windows 2000 tree. The way of accomplishing this is to upgrade the PDC into another domain in the tree. This provides for mixed-mode support while the BDCs are moved into the tree, and you eventually move to Native Mode.

Resource Domain Upgrades

If you look at the resource domains for upgrade, you need to consider why you originally created the resource domain. What was the requirement? A typical reason for the resource domain is need to avoid the possibility for a SAM size limitation violation. Another reason for the resource domain is delegation of administration. Both of these limitations have been overcome with Active Directory. Active Directory does not have the size limitations and organizational units (OUs) provide us with the ability to segment administration.

With the resource domains, you have a couple of upgrade choices. You can upgrade the resource domain in place. You can upgrade the resource domain into a new Forest and new DCs, move objects to the final Forest, and then decommission the old resource domain Forest. You can also restructure the resource domains into OUs.

Active Directory Upgrade Steps

The first step in upgrading to Active Directory is to establish the root domain. When you establish the root domain, you need to determine whether you are going to use an existing account's domain or establish a new domain. This is dependent on what your final Active Directory design is going to be. If you currently have two account domains, say one in Europe and one in North America, you might want to create a root domain and migrate the European and North American users into separate OUs in the root domain.

Accounts that are migrated to OUs have access to resources just as they had in separate domains.

After you have established the root domain, you want to upgrade the account domains first. By doing this you can quickly take advantage of some of the features of Active Directory. An example of one of the features that you can quickly put to use is the delegation of administrative control by breaking some of the Windows NT 4.0 domain limitations.

Following the account domain, you want to migrate the resource domains.

Order of Domain Upgrades

With regard to the order for upgrading the domains, you should consider the size of the domains and start out with the smaller ones first. This limits the potential impact to the end user.

If your larger domains are account domains, you should consider migrating these first. Migrating account domains first provides for easier administration.

After the size of the domains is identified, you should also consider whether a domain is going to be consolidated or just migrated and left largely intact. For those account domains that are being merged, you should wait until the end of the account domain migrations to perform those migrations.

Account domains can be merged by migrating users to a Windows 2000 Forest. The first step is to establish trusts to the Forest, so that you are able to maintain access to resource domains. Next, you need to create global groups in the new Forest for each global group that exists in the Windows NT 4.0 environment. After the trusts and global groups are set up, you migrate each user by using the ClonePrincipal to clone each user into the destination domain. You can move users from more than one domain into a single domain using this method.

With resource domains, you should migrate those domains in which the number of workstations is limited, followed by those domains that contain applications that use Active Directory. An example of this is the next generation of Microsoft Exchange. The next domains to be migrated are those resource domains that exists after the migration and finally those resource domains that are consolidated.

To migrate an Exchange resource domain to a Windows 2000 domain, you first create the trusts from the Exchange resource domain to the Windows 2000 domain. This permits users in the Windows 2000 domain to have access to the Exchange resource domain resources. You can use NetDom to identify the trusts that exist between the resource domain and the account domain. Next, you demote the application servers to member's servers and use NetDom to create computer accounts in the destination domain into which the member server is to be moved. Finally, you decommission the resource domain.

Tools for Moving Objects

There are several tools available for moving objects that are part of Active Directory. ClonePrincipal is a tool created to move users and groups between domains.

A SID history is an important part of any migration strategy. This utility is important because it enables you really move users. Remember, if you move a user between domains, you are really creating a user in the new domain and deleting the user in the old domain. This can create a problem, because when you do this you are creating a new SID, and the new SID is unable to access resources that are still in old resource domains.

To get around this, Microsoft has created a SID history for users so that the old SID can follow the user to the domain. This way, if the new user tries to access a resource in the old domain, it uses SID history to find the old SID, and it is granted access to the resource domain.

NetDom is a scripting utility used during the migration that enables you to build trusts and create computer accounts. For large organizations, this is handy when moving hundreds of resources. MoveTree is a utility to move objects between domains in a single Forest. This is used for upgrading a domain topology in place. These utilities are part of the resource kit. If the resource kit is installed, these utilities can be found in c:Program FilesResource Kit.