Approaches for Upgrading to Active Directory

Upgrading in place is taking your existing Windows NT 4.0 domain and installing Windows 2000 and Active Directory on the same machine. With this type of upgrade, you are ending up with the same type of topology that you started with. If this is true, you should be asking yourself some questions: "Am I really going to be taking advantage of the capabilities of Active Directory?" "Have you put enough time and effort into the Active Directory design to take full advantage of its capabilities?" "Are you able to do something with sites to mitigate network traffic to combine account domains?"

The next approach for upgrading to Active Directory is "upgrade and then consolidate." This approach includes upgrading the domains in place and then using tools to consolidate the domains to reflect your Active Directory domain design.

The most popular approach is to implement and then clone. This is great for organizations that want to leave their Windows NT 4.0 domain structure in place, bring in Active Directory in parallel, and then incrementally bring users into the new Active Directory domain structure. Microsoft has tools created to support this effort.

In-Place Upgrade Considerations

The in-place upgrade is the most straightforward approach for simple environments, but several items should be considered if taking on this approach. The first is the order of the account and resource domain upgrades. Typically, you want to upgrade the accounts first.

The DCs coexist so that you can make a gradual migration from Windows NT 4.0 to Active Directory and then convert from mixed-mode to Native Mode.

You should consider that all the Windows NT 4.0 objects become Active Directory objects through the migration process; therefore, it is a good idea to clean up your Windows NT 4.0 objects before the migration to prevent unnecessary clutter in the new directory.

Another consideration is the use of BDCs. You can create a BDC and keep it offline in case you need to retreat to the Windows NT 4.0 domains. With the BDC, you can promote it back to the PDC. Another approach before migrating the PDC is to create a BDC on a new box, take it offline to an isolated LAN, and promote it to a PDC. With the PDC, which is a reflection of your current Windows NT 4.0 environment, you can test the in-place migration with the real SAM.

A final note on the in-place upgrade is to review the trusts between Active Directory and Windows NT 4.0 domains to ensure that users maintain access to the resource that they need.

Consolidation

There are two ways to consolidate domains if moving to Active Directory. One way is to consolidate your domains first and then upgrade. The second way is to upgrade and then use tools to consolidate.

The problem with the first approach is that if you have multiple domains in the Windows NT 4.0 environment, there probably was a reason for it. If you had created multiple domains because of the size limit of the SAM, you probably won't be able to consolidate before migration.

If you are able to consolidate before upgrading, there are tools available from independent software vendors (ISVs) to support this. Microsoft provides the MoveTree tool for consolidating accounts into domains, based on your design.

A list of ISV tools is available at http://www.microsoft.com/windows2000/techinfo/planning/default.asp. The list of companies providing tools includes NetIQ, Entevo Corporation, FastLane Technologies Inc., Master Design and Development, Mission Critical Software, NetPro, and Full Armor Corporation.

Consolidation Considerations

When you are consolidating, you need to consider the SIDs, because without the SIDs being migrated you will have difficulty accessing the resources that are in the old Windows NT 4.0 domain. Another consideration when consolidating is the affect on network traffic. If there are fewer DCs, traffic to the DCs could become a bottleneck. DNS changes might also be required during a consolidation if multiple domains, before consolidation, were represented in different namespaces that are also consolidated.

You should consider migrating users incrementally to minimize the impact of changes, at least in the early stages of the migration.

Before starting the migration, identify and test a rollback plan. This might be something as simple as creating a BDC and keeping it offline. You should be sure to test the capability to restore functionality with the BDC so that you are not trying to recover in a panic.

Implementing and then Cloning the Account Domain

If using the "implement then clone" approach for a migration, you should start by creating a new Forest. This clean environment is based on the Active Directory design that you have created.

The first step is to create trusts between the new Forest and the user domain in the Windows NT 4.0 environment. The trusts are from the Windows NT 4.0 domain to the Active Directory tree (see Figure 22.2).

After the trusts are in place, you need to clone the Groups and Users using the ClonePrincipal and SID history utilities.

Implementing then Cloning the Resourced Domain

When you start cloning resources, you need to consider that there are users in both domains. This requires that you establish a trust from the Active Directory domain to the Windows NT 4.0 domain so that users on the Windows NT 4.0 domain side can access resources in the new Active Directory tree (see Figure 22.3).

After the trust is established, you want to clone the shared local groups using ClonePrincipal. Next, you want to move the servers into the resource domain. The tricky part is if you need to move a BDC. The way to do this is to take the BDC offline and promote it to a PDC. As a PDC, you upgrade it to Windows 2000 as part of the Forest; use DCpromo to remove the account information, and then make it a member server. Now, you can move the servers to the correct OU using NetDom. After all the servers are moved over, you can decommission the resource domain.